Packaging golang for secondary architectures, go-srpm-macros
by Jan Chaloupka
Hi,
at the moment golang packages are built only on primary architectures
(defined by %go_arches macro) due to golang compiler architecture
support. For secondary architectures gcc-go is available. In order to
provide an easy way for packagers to package golang projects for
secondary architectures as well, go-srpm-macros packages is introduced.
It provides basic macros that can be used within spec files. Currently
golang package ships /usr/lib/rpm/macros.d/macros.golang file, which
defines %gopath and %go_arches macros. As secondary architectures has no
golang package these macros are not available. Thus I am proposing to
move these macros to go-srpm-macros package and provide additional ones:
# Define arches for PA and SA
%golang_arches %{ix86} x86_64 %{arm}
%gccgo_arches %{power64} s390x aarch64
%go_arches %{golang_arches} %{gccgo_arches}
# Where to set GOPATH for builds
%gopath %{_datadir}/gocode
# Minimal version of gcc providing gcc-go
%gccgo_min_vers 5.0.0
# Define commands for building
%golang_build go build -compiler gc
%gcc_go_build go build -compiler gccgo -gccgoflags "$RPM_OPT_FLAGS"
# Define commands for testing
%golang_test go test -compiler gc
%gcc_go_test go test -compiler gccgo -gccgoflags "$RPM_OPT_FLAGS"
Meaning of %golang_arches and %gccgo_arches is obvious. %go_arches is
extended for secondary architectures. Spec files using %go_arches macros
will not get touched by this change as it takes effect only on secondary
architectures. %golang_build, resp. %golang_test and %gcc_go_build,
resp. %gcc_go_test macros provides an easy way to run go build, resp. go
test commands for golang and gcc-go compiler without typing the minimal
list of options. The reason to define %golang_build and %gcc_go_build
instead of %go_build for both compilers is to cover a case when gcc-go
and golang have a different set of options. So packagers are aware of
which compiler/command they use for building. The same holds for the 'go
test' command.
Recommended use in spec file:
1) To choose the correct compiler:
%ifarch %{golang_arches}
BuildRequires: golang
%else
BuildRequires: gcc-go >= %{gccgo_min_vers}
%endif
2) To choose the correct command for building and testing:
%ifarch %{golang_arches}
%{golang_build} -o bin/binary %{import_path}/binary
%{golang_test} %{import_path}/binary
%else
%{gcc_go_build} -o bin/binary %{import_path}/binary
%{gcc_go_test} %{import_path}/binary
%endif
At the same time packaging guidelines for golang will be extended to
provide information about secondary architectures.
What are the steps to accomplish this task?
1) finish review of go-srpm-macros [1]
2) add go-srpm-macros as a run-time dependency of redhat-rpm-config for
f21-f23 and el6
3) remove /usr/lib/rpm/macros.d/macros.golang from golang
4) update packaging guidelines
I will fill all necessary bugs/tickets if needed and update packaging
guidelines.
Florian, I would like to make go-srpm-macros a run-time dependency of
redhat-rpm-config. Thus I believe go-srpm-macros needs an extra caution
so it does not break minimal buildroot. Can you check out the
macros.go-srpm file in the package [1]? The file define only one line
macros, no %if nor %ifarch.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1241156
Any feedback and questions are welcomed and appreciated.
Thanks to all involved in helping us.
Kind Regards
Jan Chaloupka
8 years, 7 months
Bad default error policy causes printing issues and BIG usability issues
by Valent Turkovic
Hi,
currently default error policy for printers in Fedora is "Stop printer" on
any error which is a really bad default. I have run across this issue LOTS
of times with regular Fedora desktop users who don't get why has their
printer stopped working, there is no UI queue to warn users, there is no
easy way to "Start printer" with one click after it has been stopped. It is
just a big mess.
Even worse, previous versions of Gnome control panel (if I remember
correctly) had option to change default error policy, now that option is
removed and you can get to it only by installing system-config-printers
tool, something regular users have no idea about even exists, and it is not
installed by default.
There are too many examples which are simple user errors but result in
priner going offline (stopped) and this is really bad, because after any
small error users can't print any more.
For example: user trying to print while he/she is not at home so his/hers
printer is not available, user trying to print but has forgot to connect
usb priner cable, user trying to print but haven't turned it on, user
printing to wifi printer but while connected to different wifi network...
Any of these actions is simple uses error but results in permanently
disabling of priner (Stops printer) and users can't print even when they
resolve issue that was stopping them from accessing the printer.
Now Fedora is what is stopping them from printing.
Who is responsible for user experience of Fedora desktop? To whom should I
point this issue to?
8 years, 7 months
Firefox addon signing
by Michael Cronenworth
I'm sure those that need to know, know, but for those that haven't heard[1]
Mozilla's official Firefox build will enforce addons to contain a Mozilla signature
without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla
signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
[1] https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experi...
8 years, 8 months
dnf doesn't check for rpmdb lock?
by Richard Shaw
I remember frequently (to my dismay) getting messages from yum saying that
another process had a lock on the RPM database.
Due to a recent rash of issues with the akmods package I have been
investigating why the kmods are not getting installed.
Out of curiosity I tried running two dnf update instances in two different
terminals and I did not get the message, in fact it acted like nothing was
wrong!
Of course I hit "n" to not install the updates so I'm not sure what would
happen if I had hit "y"...
Am I missing something here?
Thanks,
Richard
8 years, 8 months
F23 Self Contained Change: RPM MPI Requires Provides
by Jan Kurik
= Proposed Self Contained Change: RPM MPI Requires Provides =
https://fedoraproject.org/wiki/Changes/RpmMPIReqProv
Change owner(s): Sandro Mani <manisandro at gmail dot com>
Have the rpm-build find-provides and find-requires scripts encode the MPI compiler name in the provides string of a binary to distinguish otherwise identical provides between packages $foo, $foo-openmpi and $foo-mpich.
== Detailed Description ==
Currently, the packages libfoo, libfoo-openmpi and libfoo-mpich providing the library libfoo.so all have a provides string of i.e.
libfoo.so()(64bit)
While yum used a shortest-package-name rule to choose which package to pick, dnf does not have any rules, and seems to just pick the first match it comes across. Currently the only solution would be to filter the provides from the -openmpi, -mpich packages and add explicit Requires: where needed. I'd like to propose to extend the provides string in such way that it also encodes the MPI implementation, i.e.:
$ rpm -qp --provides libfoo
libfoo.so()(64bit)
$ rpm -qp --provides libfoo-mpich
libfoo.so()(64bit)(mpich-x86_64)
$ rpm -qp --provides libfoo-openmpi
libfoo.so()(64bit)(openmpi-x86_64)
To this end, I'm proposing to adapt the find-requires and find-provides scripts as (or similarly to):
find-provides
find-requires
Discussion of these changes are tracked in bug #1232504.
This change is intended to coordinate the rebuild of all MPI related packages to ensure all such packages consistently use the new provides format.
== Scope ==
* Proposal owners:
- Work on find-provides and find-requires based on feedback.
- As soon as updated find-provides and find-requires shipped with rpm-build, do a mass-rebuild of all MPI packages.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 8 months
systemd bugs again and again
by Reindl Harald
i am tired of ignored bugs in core components like
https://bugzilla.redhat.com/show_bug.cgi?id=1226509
how to reproduce?
just use "RuntimeDirectory" and "ExecStartPost" in a systemd-unit and
stop the service every hour on each machine for backups, you will have a
few failed starts each day
Jul 4 03:18:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
spawning /usr/libexec/mysqld-wait-ready: File exists
Jul 4 03:18:54 backup-arrakis systemd: Failed to start MariaDB Database.
Jul 4 03:18:54 backup-arrakis systemd: Unit mysqld.service entered
failed state.
Jul 4 03:18:54 backup-arrakis systemd: mysqld.service failed.
Jul 4 08:17:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
spawning /usr/libexec/mysqld: File exists
Jul 4 08:17:54 backup-arrakis systemd: Failed to start MariaDB Database.
Jul 4 08:17:54 backup-arrakis systemd: Unit mysqld.service entered
failed state.
Jul 4 08:17:54 backup-arrakis systemd: mysqld.service failed.
8 years, 8 months
Boost updated to 1.58.0 in rawhide and f23
by Jonathan Wakely
Hi,
I've pushed a new version of Boost, 1.58.0, to rawhide and f23, which
will require all packages that depend on Boost to be rebuilt. The plan
was to update to 1.59.0 but that isn't going to be released in time
for the F23 schedule, so I'll update rawhide to 1.59.0 at a later
date.
For the F23 rebuilds please use the tag f23-boost e.g.
fedpkg build --target f23-boost
For the rawhide rebuilds please use the tag f24-boost e.g.
fedpkg build --target f24-boost
After all the rebuilds have been done with this tag they will be
merged back to f23 or rawhide, as appropriate..
Any problems rebuilding either open a bug or feel free to email me or
ping me on IRC (my freenode nick is 'redi') and I'll be happy to help.
Thanks,
Jonathan
Links:
https://fedoraproject.org/wiki/Changes/F23Boost159
https://fedorahosted.org/rel-eng/ticket/6197
8 years, 8 months
