(Resending as i got a bounce from the list)
On 29/09/14 11:04 -0700, Richard Henderson wrote:
>I'm working on enabling Go on systems without golang support, but for which the
>gccgo compiler works.
>But in order for this to work, there needs to be some amount of coordination
>with the regular golang package, the spec files of binaries written in go, and
>the golang-*-devel packages.
>(0) I start with a "go" driver program that is built with, and defaults to
>building with, the gccgo compiler. I.e. -compiler gccgo is the default. I've
>called this package "go-gccgo", for lack of a better name.
cool. DO you have this published somewhere?
>(1) I was disappointed to discover that all of the -devel packages depend on
>golang. That meant that when I wanted to uninstall golang on my test system
>and install my go-gccgo package, all of the development libraries were
>uninstalled too. This seems silly, because the -devel packages don't *really*
>depend on golang, any more than glib2-devel depends on having gcc installed.
This discussion has gone around a bit. Some of the rpms have
BuildRequires of 'golang' because they run `go test` in their %check
But otherwise, the -devel that is landing source code only, does not
require golang. Perhaps we could make this a meta for go API
>I think that removing this unnecessary dependency can happen independent of any
>other change we can make.
>(2) We need some rpm token to coordinate the version of the Go language that
>the installed compiler. Currently the packages check "golang >= version", but...
Right, so for go api this is where we should mimic the rpm spec of
packages like python or ruby. They need _a_ compiler that can do '>=
1.2' or similar. Make sense?
>(3) The golang and go-gccgo packages probably ought to conflict, since both
>contain a /usr/bin/go. I don't see using alternates as terribly useful here,
>and anyway there may well be a Go language version conflict from (2) between
>the two compilers. Certainly for f21, golang is v1.3.1, but gcc 4.9 supports
do that have to conflict? I wouldn't think that is a requirement.
>(4) For packages that build binaries written in go, like docker, we need an rpm
>macro to say whether we expect to build with gccgo or gc. The command line
>options for the two compilers are not compatible, and so the %build section of
>the spec file needs to be adjusted (sometimes trivially, sometimes not).
is there precedent of macros like this or is this something we'd need to
craft up ourselves?
>I'm currently defining %use_gccgo in the /usr/lib/rpm/macros.d/macros.golang
>file installed with my go-gccgo package.
>(5) There's currently a %go_arches macro that specifies those arches to which
>golang is ported. If go-gccgo exists, is this macro actually useful anymore?
I think so, but it may need to be adjusted for the gccgo vs gc macro
(resending, as i got a bounce from the list)
On 29/09/14 20:54 +0200, Haïkel wrote:
>Currently, there is *no* golang packaging guidelines approved, so we
>shouldn't have accepted golang packages in the first place.
>The most urgent issue is to complete the current draft and champion it
>to the FPC.
>Without guidelines, we're just increasing packaging entropy.
the increasing entropy is worriesome, but i'm glad topics like this are
coming up to help us get the guidelines robust
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2014-08-21 16:00 UTC in #fedora-meeting-1 on
Local time information (via. rktime):
2014-08-28 09:00 Thu US/Pacific PDT
2014-08-28 12:00 Thu US/Eastern EDT
2014-08-28 16:00 Thu UTC <-
2014-08-28 17:00 Thu Europe/London BST
2014-08-28 18:00 Thu Europe/Paris CEST
2014-08-28 18:00 Thu Europe/Berlin CEST
2014-08-28 21:30 Thu Asia/Calcutta IST
2014-08-29 00:00 Fri Asia/Singapore SGT
2014-08-29 00:00 Fri Asia/Hong_Kong HKT
2014-08-29 01:00 Fri Asia/Tokyo JST
2014-08-29 02:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
= Followups =
(approval and retirement sections already passed, /opt exception passed,
#topic #339 software collections in Fedora
(comment #16 is the current winner)
#topic #341 How to replace "docker" package with an entirely
different package of the same name?
#topic #382 Go Packaging Guidelines Draft
(more votes needed, or defer to FESCO?)
#topic #444 Officially recommend to releng that SCLs be placed in
separate packages rather than separate branches in git
= New business =
#topic #447 Bundling exception for axmail
#topic #448 Copylib exception for fastlz
#topic #450 Temporary jsquery packing exception for kimchi
#topic #452 Crypto policies packaging guideline
#topic #453 Changes/SystemdSysusers updates for
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
Testers wanted immediately for:
For Fedora 21 and Fedora 20 we will be disabling Intel TSX
support in POSIX threads effective immediately. This disabling
of TSX support in POSIX threads is in order to prevent users
from crashing their systems when they upgrade microcode_ctl.
The upgrade to the new microcode_ctl applies the microcode
update for the Intel errata HSW136 and makes all TSX instructions
invalid opcodes. This means that any process on your system
already using POSIX threads, and already using TSX, will fault
with invalid opcode errors when it tries to execute TSX
The best solution is for the microcode update to be done before
userspace starts as part of a single-threaded init process or
Until we support updating microcode in early bootup we won't
enable TSX in POSIX threads. The glibc maintainers have decided
not add code to detect which devices the errata applies to, nor
will code be added to re-read the cpuid values at every TSX usage.
We are going with the simples approach which is to disable TSX
for POSIX threads.
I'm trying to build a 32bit library on my 64bit system with cmake. The
first part is easy, pass -m32 to the C/CXX flags, but this library includes
a code generator and if the target and host parameters don't 100% match,
cmake assumes it's cross-compiling and then requires import executables for
the "host" system.
When I build a package using rpmbuild --target i686 everything works as
expected so I assume rpmbuild is setting up some stuff in the background to
make this happen.
I was trying to see if I could get verbose output from rpmbuild but I built
the package 3 times, once without verbose, once, with, and one with -vv.
Other than the expected differences (tmp dirs, etc) all the logs are
identical which would indicate to me that the verbose options aren't doing