Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)

[Jakub Cajka]

- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek" 
> To: "Jakub Cajka" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 6, 2021 11:10:58 AM
> Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
> 
> On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
> > 
> > 
> > 
> > 
> > - Original Message -
> > > From: "Josh Boyer" 
> > > To: "Development discussions related to Fedora"
> > > 
> > > Cc: "Zbigniew Jędrzejewski-Szmek" 
> > > Sent: Tuesday, January 5, 2021 9:45:28 PM
> > > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
> > > 
> > > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood 
> > > wrote:
> > > >
> > > > Zbigniew Jędrzejewski-Szmek  writes:
> > > >
> > > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
> > > > >> https://fedoraproject.org/wiki/Changes/golang1.16
> > > > >>
> > > > >> == Summary ==
> > > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
> > > > >
> > > > > No complaint about the Change, but...
> > > > > can we please stop saying "rebase"?
> > > > >
> > > > > That verb made sense when packaging was about a stack of patches and
> > > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
> > > > > and another 9% have patches backported from git that will be dropped
> > > > > on the update to the next upstream version. Talking about a "rebase"
> > > > > is mostly confusing.
> > > >
> > > > Not really a defense, but this is what we call it internally for RHEL.
> > > > So even if we officially change the name, most of us are likely to keep
> > > > calling it rebase out of habit.
> > > 
> > > I agree with you, Robbie.  It'll hang around and we'll have to deal
> > > with it for a long time.
> > > 
> > > However, even internally in RHEL we're starting to see "rebase" be
> > > really hard to understand.  One team will mean "grab a new tarball
> > > that only contains a limited set of bug fixes" and another team will
> > > mean "grab an entirely new major version release that breaks ABI and
> > > on-disk format".  We should honestly look at how to articulate these
> > > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
> > > quickly becoming meaningless.
> > > 
> > > josh
> > 
> > I kind of agree with all that have been said and will add my point of view.
> > First I think that any term the we will invent or choose will eventually
> > drift in way that we might not agree with or want with little that anyone
> > can do about it.
> > 
> > I would argue that in this case it is the most that rebase can be,
> > especially with the need to actually rebuild "all" the Go packages to pick
> > up the changes in the compiler and standard Go library. Not much on the
> > compiler side as all the Fedora patches doesn't really need much
> > re-basing(mostly just setting some more saner defaults), but the other
> > packages are rebased in a sense on top of the new version of compiler.
> 
> So... the compiler is *updated** and the packages are **rebuilt**?
> """
>  The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
>  and all golang packages are rebuilt. (The pre-release version of Go will
>  be used for the rebuild if released version will not be available at the
>  time of the mass rebuild).
> """
> ?

Yes, thank you. Applied in to the wiki.

> 
> > I'm open to any improvement in the wording of the change, feel free to
> > propose something here or just edit the proposal, but please let me know
> > as the wiki AFAIK doesn't allow continuous notification on changes(or I
> > haven't been able to find it and enable it for myself).
> 
> There's a "watch" button topright, and also when editing, you are asked
> if you want to be notified about changes. I think I always get an email
> when somebody changes a page I'm watching.

This is in my experience reset with first edit after mine(both the top watch 
button or via the edit submit screen), as in watch is still on, but I don't get 
any further notifications.

JC

> 
> > > > (And it does make sense for RHEL where backporting more patches is the
> > > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
> > > > have no downstream-only packages, but that might just be my bias in the
> > > > opposite direction, since I maintain a couple that do.)
> 
> Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
> some real data.
> 
> Zbyszek
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)

[Jakub Cajka]

- Original Message -
> From: "Josh Boyer" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Zbigniew Jędrzejewski-Szmek" 
> Sent: Tuesday, January 5, 2021 9:45:28 PM
> Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
> 
> On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood  wrote:
> >
> > Zbigniew Jędrzejewski-Szmek  writes:
> >
> > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
> > >> https://fedoraproject.org/wiki/Changes/golang1.16
> > >>
> > >> == Summary ==
> > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
> > >
> > > No complaint about the Change, but...
> > > can we please stop saying "rebase"?
> > >
> > > That verb made sense when packaging was about a stack of patches and
> > > hacks. Nowadays maybe 90% of packages are just the upstream version,
> > > and another 9% have patches backported from git that will be dropped
> > > on the update to the next upstream version. Talking about a "rebase"
> > > is mostly confusing.
> >
> > Not really a defense, but this is what we call it internally for RHEL.
> > So even if we officially change the name, most of us are likely to keep
> > calling it rebase out of habit.
> 
> I agree with you, Robbie.  It'll hang around and we'll have to deal
> with it for a long time.
> 
> However, even internally in RHEL we're starting to see "rebase" be
> really hard to understand.  One team will mean "grab a new tarball
> that only contains a limited set of bug fixes" and another team will
> mean "grab an entirely new major version release that breaks ABI and
> on-disk format".  We should honestly look at how to articulate these
> kinds of things better, both in Fedora and in RHEL.  "Rebase" is
> quickly becoming meaningless.
> 
> josh

I kind of agree with all that have been said and will add my point of view. 
First I think that any term the we will invent or choose will eventually drift 
in way that we might not agree with or want with little that anyone can do 
about it.

I would argue that in this case it is the most that rebase can be, especially 
with the need to actually rebuild "all" the Go packages to pick up the changes 
in the compiler and standard Go library. Not much on the compiler side as all 
the Fedora patches doesn't really need much re-basing(mostly just setting some 
more saner defaults), but the other packages are rebased in a sense on top of 
the new version of compiler.

I'm open to any improvement in the wording of the change, feel free to propose 
something here or just edit the proposal, but please let me know as the wiki 
AFAIK doesn't allow continuous notification on changes(or I haven't been able 
to find it and enable it for myself).

JC

> 
> > (And it does make sense for RHEL where backporting more patches is the
> > norm.  I'm uncomfortable with the assertion that ~99% of all packages
> > have no downstream-only packages, but that might just be my bias in the
> > opposite direction, since I maintain a couple that do.)
> >
> > Thanks,
> > --Robbie
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: AArch64 support for container and flatpak builds

[Jakub Cajka]

- Original Message -
> From: "Clement Verna" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, December 10, 2020 2:16:26 PM
> Subject: Re: AArch64 support for container and flatpak builds
> 
> 
> 
> On Thu, 10 Dec 2020 at 14:12, Jakub Cajka < jca...@redhat.com > wrote:
> 
> 
> 
> 
> 
> 
> - Original Message -
> > From: "Mark O'Brien" < marko...@redhat.com >
> > To: devel-annou...@lists.fedoraproject.org , devel@lists.fedoraproject.org
> > Sent: Thursday, December 10, 2020 11:44:14 AM
> > Subject: AArch64 support for container and flatpak builds
> > 
> > All,
> > We are very happy to announce that we now have AArch64 support for flatpak
> > and container fedpkg builds in production!
> > 
> > By default all flatpak and container builds will be built on both
> > architectures from now on.
> > 
> > Thanks,
> > Fedora OSBS initiative
> > 
> 
> Awesome. Thank you and all involved. :)
> 
> Is there plan to rebuild containers even for f32(I assume that they got
> rebuild for f33 and rawhide.)? It seems from brief check that some are
> missing for aarch64 and so are breaking further container builds.
> 
> I think that will be a case by case thing, there is no automated way to
> rebuild all the containers.
> 
> 
> 
> $ fedpkg container-build
> Created task: 57187318
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57187318
> Watching tasks (this may be safely interrupted)...
> 57187318 buildContainer (noarch): free
> 57187318 buildContainer (noarch): free -> FAILED: Fault:  build failed. Error in plugin pull_base_image: Base image
> registry.fedoraproject.org/f32/s2i-base:latest not available for arches:
> arm64. OSBS build id: golang-f32-8074d-3'>
> 0 free 0 open 0 done 1 failed
> 
> Is there anything that I can do to help with that?
> 
> If you have a failure you should be able to build any container, so in that
> case you can rebuild s2i-base in f32 before doing your other builds.
> 
> Hope that helps :)
> 

Yes. I will start some builds! :)
Good to know that I will not directly step on your or others toes.

JC

> 
> 
> JC
> 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: AArch64 support for container and flatpak builds

[Jakub Cajka]

- Original Message -
> From: "Mark O'Brien" 
> To: devel-annou...@lists.fedoraproject.org, devel@lists.fedoraproject.org
> Sent: Thursday, December 10, 2020 11:44:14 AM
> Subject: AArch64 support for container and flatpak builds
> 
> All,
> We are very happy to announce that we now have AArch64 support for flatpak
> and container fedpkg builds in production!
> 
> By default all flatpak and container builds will be built on both
> architectures from now on.
> 
> Thanks,
> Fedora OSBS initiative
> 

Awesome. Thank you and all involved. :)

Is there plan to rebuild containers even for f32(I assume that they got rebuild 
for f33 and rawhide.)? It seems from brief check that some are missing for 
aarch64 and so are breaking further container builds.

$ fedpkg container-build
Created task: 57187318
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57187318
Watching tasks (this may be safely interrupted)...
57187318 buildContainer (noarch): free
57187318 buildContainer (noarch): free -> FAILED: Fault: 
  0 free  0 open  0 done  1 failed

Is there anything that I can do to help with that?

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [ELN] Cannot build a package in mock on F32

[Jakub Cajka]

- Original Message -
> From: "Pavel Raiskup" 
> To: devel@lists.fedoraproject.org
> Cc: "Ondrej Budai" 
> Sent: Tuesday, October 13, 2020 11:00:31 AM
> Subject: Re: [ELN] Cannot build a package in mock on F32
> 
> On Tuesday, October 13, 2020 9:07:18 AM CEST Ondrej Budai wrote:
> > Hello,
> > 
> > I'm trying to build RPM from SRPM for ELN on F32 host using this command:
> > 
> > mock -r fedora-eln-x86_64 --resultdir results --rebuild PATH_TO_SRPM
> > 
> > However, I get the following error message when mock tries to bootstrap
> > Fedora ELN buildroot using dnf:
> 
> Can you try to update distribution-gpg-keys to the updates-testing version?
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-867d08764a
> 
> Pavel
> 

This doesn't seem to solve the gpg issue for me. And with disabled gpgcheck in 
the eln mock template I still hit:

.
.
.
No matches found for the following disable plugin patterns: local, spacewalk
Fedora ELN - Developmental modular packages for the next Enterprise Linux 
release 
1.3 MB/s |  19 MB 00:14 
   
Last metadata expiration check: 0:00:12 ago on Tue Oct 13 12:23:20 2020.
Module or Group 'buildsys-build' is not available.
Error: Nothing to do.

JC

> > GPG key at
> > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> > (0x9570FF31) is already installed
> > The GPG keys listed for the "Fedora ELN - Developmental modular packages
> > for the next Enterprise Linux release" repository are already installed but
> > they are not correct for this package.
> > Check that the correct key URLs are configured for this repository..
> > Failing package is: dnf-4.4.0-1.eln104.noarch
> >  GPG Keys are configured as:
> > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> > 
> > and many more GPG failures for all the installed packages...
> > 
> > Is it somehow possible to build packages for ELN using mock on Fedora 32?
> > 
> > Thanks
> > 
> > Ondřej
> > 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Include non-RPM content in buildroot

[Jakub Cajka]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, February 21, 2020 4:46:52 PM
> Subject: Re: Include non-RPM content in buildroot
> 
> On Fri, Feb 21, 2020 at 3:58 PM Martin Sehnoutka  wrote:
> >
> > Hi,
> 
> Hi!
> 
> I think several of your assumptions are not necessarily correct, which
> might lead to wrong conclusions.
> My responses are inline below.

I second that ;).

> 
> > before I write the proposal itself I just want to stress the fact that
> > it isn’t my intention to change the current packaging workflow and
> > definitely not the user experience. Also if you have C or Python
> > packages it would not affect your work at all (I’m not familiar with all
> > interpreted languages in Fedora, but I guess it is similar to Python and
> > therefore it is not affected by the problems I am going to describe).
> 
> (snip)
> 
> > First of all, let me describe the problem I see in our Fedora ecosystem
> > with relation to Go and Rust language ecosystems. More specifically in
> > the relation between RPM buildroot and packages in these ecosystems.
> > Both of these languages follow the idea that packages should be small
> > and only have a limited set of features. Developers then use a lot of
> > these packages to write the final executable that is meant for end-users
> > [1]. Also both of these languages use static linking of the final
> > binaries meaning that Fedora users don’t install RPM packages of these
> > libraries as they are already baked inside of the binary [2].
> 
> One big difference between Go and Rust is that Go only namespaces
> libraries by their import path (with some exceptions, like gopkg.in),
> whereas Rust/cargo namespaces everything by name *and* version, which
> makes some things a lot easier. Then there's also the fact that a lot
> of Go libraries don't even *have* versions, and most only reference
> dependencies by "this git repository". There's some effort to make
> this better, but Go modules are not ready yet.

With Go modules("upstream ones") you are getting that name + version/tag(and 
rules what to use). Definitively many packages will not move to the 
modules/best practices, if that happen, we should try to move them to 
modules/best practices or move depending package to different package that is 
still maintained or in worst case scenario take over the maintenance -> fork.

> 
> > The 1st problem is that if we want to build RPMs of the final
> > executables the way we do now, we need to package all these small
> > libraries into RPM even though they are just build dependencies and
> > users never install RPMs of these libraries. Many of these RPMs are
> > automatically generated from the upstream packages meaning that we don’t
> > do anything except for unpacking the upstream package (e.g. plain
> > tarball in case of crates.io)  and then we package the same into RPM.
> > This process is unfortunately not fully automated and therefore requires
> > a certain amount of human effort.
> >
> >
> > To sum up the previous paragraph, I don’t think it is necessary to
> > repackage upstream tarball into a downstream RPM.
> 
> Of course this requires a certain amount of human effort - because
> that's where the packager does their work. This includes:
> 
> - verifying that the specified license is correct and suitable for
> (re)distribution in fedora
> - verify that the package builds and doesn't do crazy things
> - fix upstream and integration issues with patches
> 
> And none of these three things is 100% automatable.

Seconding that.

> 
> > The 2nd problem is present only in the Rust ecosystem (as far as my
> > knowledge goes). Cargo, the official package manager for Rust, can
> > handle the scenario where an executable depends on a single library in
> > two different versions [3]. Dnf, on the other hand, will not install two
> > versions of the same RPM package. What we do now is, that we patch the
> > affected executables and libraries to only use the newest versions
> > everywhere. This is again an additional maintenance cost and we create
> > differences from upstream, because these patches are not necessarily
> > merged. See this as an example:
> > https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17
> > https://github.com/BurntSushi/bstr/pull/23

 (snip)

> 
> > It is fair to say, that my first motivation was the current state of
> > packaging in RHEL but I’d prefer to discuss this in Fedora first.
> >
> >
> > The proposal itself is fairly simple: Let’s stop packaging all Go and
> > Rust libraries into RPM and install them to the buildroot in the
> > upstream format instead.
> 
> As I said (and others have pointed out as well), this is not possible
> right now, primarily because automation cannot verify licensing and
> write and apply necessary patches without human intervention. And when
> you start curating your own Cargo registry, you might as well just
> package them 

Re: Fedora 32 System-Wide Change proposal: Golang 1.14

[Jakub Cajka]

- Original Message -
> From: "Igor Gnatenko" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, January 2, 2020 4:24:44 PM
> Subject: Re: Fedora 32 System-Wide Change proposal: Golang 1.14
> 
> Do we really need to rebuild all thousand of packages given that most
> of them are providing only noarch devel packages with sources? Don't
> we need to rebuild only those which provide binaries?
> 

I don't disagree, but if the rebuild will be facilitated as part of the regular 
mass-rebuild it will be "free". Other technical challenge is to find packages 
that truly need rebuild(use Go compiler during the build, for tests and/or 
building binaries) as that information is no longer present in the SRPM 
metadata with the new Go packaging scheme(although even source only packages 
should have their tests suites run, ideally, thus needing the compiler), 
compiler is always pulled in to the build root via the new macros package.

JC

> On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/golang1.14
> >
> > == Summary ==
> > Rebase of Golang package to upcoming version 1.14 in Fedora 32,
> > including rebuild of all dependent packages(pre-release version of Go
> > will be used for rebuild, if released version will not be available at
> > the time of the mass rebuild).
> >
> > == Owner ==
> > * Name: [[User:Jcajka| Jakub Čajka]]
> > * Email: jca...@redhat.com
> >
> > == Detailed Description ==
> >
> > Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
> > 1.14 is schedule to be released in Feb 2020.
> > Due to current nature and state of Go packages, rebuild of dependent
> > package will be required to pick up the changes.
> >
> > == Benefit to Fedora ==
> >
> > Staying closely behind upstream by providing latest release of golang,
> > which includes performance improvements and improvements in support
> > for currently supported platforms among other bug fixes and new
> > features. For complete list of changes see upstream change notes at
> > https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
> > solid development platform for Go language.
> >
> > == Scope ==
> > * Proposal owners: Rebase golang package in f32, help with resolving
> > possible issues found during package rebuilds.
> >
> > * Other developers: Fix possible issues, with help from golang maintainers.
> > * Release engineering: Rebuild of dependent packages as part of
> > planned mass-rebuild. Tracking ticket
> > https://pagure.io/releng/issue/9136
> > * Policies and guidelines: N/A
> > * Trademark approval: N/A
> >
> > == Upgrade/compatibility impact ==
> > None
> >
> > == How To Test ==
> > ;0.
> > :a)Install golang 1.14 from rawhide and use it to build your
> > application(s)/package(s).
> > :b)Scratch build against rawhide.
> > ;1.
> > :Your application/package built using golang 1.14 should work as expected.
> >
> > == User Experience ==
> > None
> >
> > == Dependencies ==
> > 
> > dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'golang'
> > dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'compiler(go-compiler)'
> > dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'compiler(golang)'
> > dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'go-rpm-macros'
> > 
> > 
> > Omitted due to the number of packages listed ~1100.
> > 
> >
> > Not all of listed require re-build as they might not ship binaries
> > and/or do not use golang compiler during build, but only use Go rpm
> > macros that pull it in to every build root.
> >
> > == Contingency Plan ==
> > * Contingency mechanism:Reverting to  golang version 1.13.X if
> > significatnt issues are discovered.
> > * Contingency deadline: Beta Freeze(?)
> > * Blocks release? No
> > * Blocks product? No
> >
> > == Documentation ==
> > https://tip.golang.org/doc/go1.14
> >
> >
> > --
> > Ben Cotton
> > He / Him / His
> > Fedora Program Manager
> > Red Hat
> > TZ=America/Indiana/Indianapolis
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> > devel-announce-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > 

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Jakub Cajka]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, October 17, 2019 2:41:28 AM
> Subject: Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular 
> Buildroot
> 
> > > (And how would restricting default streams to only be able to depend on
> > > default streams change things?)
> >
> > It would solve the version conflicts issue, so it makes a lot of sense, but
> > at that point, why not require the default versions to just be non-modular
> > instead? The main argument for using default streams was that they can
> > depend on non-default streams of other modules. So if we disallow this
> > (which I think makes sense), we may as well disallow default streams
> > entirely and simplify things for everyone. (We would just need a short-term
> > workaround for the default streams that exist now. The problem would be
> > gone
> > in the long run.)
> >
> 
> There's still a case that you haven't considered, which is things that
> work at runtime as a default but cannot *build* against the default
> set of packages. For example, we might have packages whose buildsystem
> still relies on Python 2 (WAF?) but doesn't require it at runtime.
> There might be packages that haven't yet migrated to a new,
> backwards-incompatible change to Docbook for generating documentation.
> Or packages that only build properly with a newer version of golang
> than shipped in that release, or any of a thousand other examples that
> are easily solved by build-time-only content and dependencies in
> module streams.

In current context(1.X) package that doesn't build with new version of Go has 
usually serious issue(s) on the side of the package/upstream. Fortunately this 
is really uncommon in my experience(even for packages/upstreams that fear/think 
that they will break with newer version of Go).

> 
> Also there are yet other packages (such as in the Go and Rust
> ecosystems) that could simply be built once on Rawhide with the latest
> compiler and shipped to each of the other releases without needing a
> rebuild because they are statically linked. Modules allow this, basic
> RPMs not so much.

For Go this is oversimplification and common misconception(go built binaries 
are not uncommonly dynamically linked in the "C/ELF" sense(glibc,...) and 
statically linked in Go sense). It might work for some selected(maybe even 
most) Go based packages, but not always(new glibc,...) and not universally. 

JC

> 
> So even if we eliminate the version conflicts issue by restricting
> what comprises a default stream, there are other benefits to module
> default streams.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Christophe de Dinechin" , "Development discussions 
> related to Fedora"
> 
> Cc: "Robin Lee" , "nicolas mailhot" 
> 
> Sent: Saturday, July 6, 2019 8:39:12 AM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
> écrit :
> > 
> > Also, would anybody mind if I add a note on the guideline page
> > stating
> > that this is from F31 on, since the go-rpm-macros package does not
> > exist before. Unless there is a plan to create branches for earlier
> > releases?
> 
> It could be done for previous releases, if someone was motivated
> enough. The macro code itself works, with trivial adjustments, on
> ancient releases like EL7. But, it depends on things in redhat-rpm-
> config, so backporting would demand to convince redhat-rpm-config
> maintainers to backport too.
> 
> Anyway this is pretty academic right now, I doubt anyone would accept a
> backport without synchronized backport of the whole Go packageset, and
> that can not happen before eclipso finishes to update the stack in
> devel.
> 
> Regards,
> 
> --
> Nicolas Mailhot

You have omitted that the new macros stack is not fully backwards compatible, 
so it would require more work on fixing the packages that are affected by the 
breakage(AFAIK a bit under ~100). IMHO it is not a good idea to back-port this 
to any stable Fedora release.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek" 
> To: "Development discussions related to Fedora" 
> 
> Cc: gol...@lists.fedoraproject.org
> Sent: Wednesday, June 12, 2019 4:20:40 PM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> On Wed, Jun 12, 2019 at 04:39:07AM -0400, Jakub Cajka wrote:
> > > F31 change page:
> > > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
> > > and approval: https://pagure.io/fesco/issue/2120
> >
> > It seems that this change has been accepted as Self Contained Change
> > but IMHO it is System Wide Change as it seems to affect (nearly) all
> > Go based packages in distribution(and will require work/attention of
> > people that are not change owners, actually not accounted for in
> > change proposal). For past several releases I have been doing rebase
> > of Go compiler change(yet to be filed for F31) that is IMHO
> > comparable(maybe a bit smaller) in scope and they were always deemed
> > by FESCO as System Wide Changes. This really leaves me
> > confused. Could someone from FESCO clarify?
> 
> https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says
> > Examples include [...] a coordinated effort within a SIG with
> > limited impact outside the SIG's functional area
> 
> So in this case, even though the change affects so many packages, it
> falls into the "self contained change" category.
> 
> That said, the difference between "system-wide" and "self-contained"
> boils down to two things: some additional data required in the change
> page, and filing the change a bit earlier. In this case the additional
> data is mostly there in the change page, and the change was filed early,
> so even if we were to change the Change to "system-wide", the effect
> would be cosmetic.
> 
> Zbyszek

Thank you for clarification :). IMO it would be great if that has been recorded 
in https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes, this 
approach can't be really inferred from it(at least I don't see it there).

With that popped on my mind that may be calling it "early/late window change" 
would fit better along with recording the complexity of the change, rather then 
system wide, contained change. But this is really just my brain storm.

Unfortunately no early changes for me as Golang release are aligned late in to 
the Fedora devel cycle.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Jakub Cajka" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" 
> Sent: Wednesday, June 12, 2019 11:23:34 AM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> Le 2019-06-12 10:39, Jakub Cajka a écrit :
> 
> >> Fedora’s new Go packaging macros landed in rawhide (koji) today.
> >> 
> > 
> > I thought that we have agreed on Go SIG meeting with eclipseo to do
> > this in side tag along with golang rebase(to avoid 2 rebuilds),
> 
> https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines#Summary
> 
> “ This proposal consists of:
>  Packaging the new Go macros: go-rpm-macros
>  Getting the Guidelines approved by the FPC
>  Updating all Go libraries with the new macros
>  Mass-rebuilding all the Go package in a side tag ”
> 
> You complain that step 3 and 4 are separate, but that’s how it was
> planed from the start up and approved in the change page.
> 
> You're conflating merging two mass Go package rebuilds (one for the new
> Go compiler, and another for the new, and first, Go packaging
> guidelines) with merging step 3 and 4 (which would have had other
> drawbacks, that were never discussed, because that's not how we planed
> things).
> 
> And BTW it was already so in
> https://pagure.io/GoSIG/go-sig/issue/20 6 months ago (though this page
> is obsolete, you made us rewrite the plan in so many formats over time
> I've lost track or what is up to date or not. The change page is up to
> date, it’s the most recent rewrite)

I guess that we have not agreed on the SIG meeting then. I don't complain and 
this is not in any ways personal, keep it on mind please. The change proposal 
predates that SIG discussion as other bit predates the change proposal. I'm 
pointing out that we could have avoided any breakage if we did few thing 
slightly differently. Currently by your actions there are several FTBFS 
packages, it is not really a serious issues(as I'm sure that eclipso will fix 
up all the packages that need it in time for Fedora 31, kudos for committing 
for that work :)) but it is unnecessary and avoidable inconvenience that I(and 
I guess others too) will have to account for(spend some time on). In my case 
preparing for Go rebase(I do scratch rebuilds). One of the points been also 
possibility to fit in the Go rebase in to that side tag, but after further 
discussion with eclipseo on Wednesday it will make more sense to use regular 
mass-rebuild for that(as I usually do) assuming that the side tag rebuild will 
conclude 1-2w prior to it(so I will be able to observe dist git in coherent 
shape).

JC

> 
> Sincerely,
> 
> --
> Nicolas Mailhot
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: gol...@lists.fedoraproject.org
> Cc: devel@lists.fedoraproject.org, annou...@lists.fedoraproject.org, "Nicolas 
> Mailhot" 
> Sent: Saturday, June 8, 2019 3:45:20 PM
> Subject: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> Hi,
> 
> Fedora’s new Go packaging macros landed in rawhide (koji) today.
> 

I thought that we have agreed on Go SIG meeting with eclipseo to do this in 
side tag along with golang rebase(to avoid 2 rebuilds), so there is no 
observable breakage(if any would occur) for package builds and all packages 
"just" pop in using new macros and following new guidelines. Currently 
following packages are FTBFS due to this change 
https://apps.fedoraproject.org/koschei/affected-by/go-srpm-macros?epoch1=0=2=19.fc30=0=3.0.8=3.fc31=f31
 (thanks to qulogic for this query). And still we will have to do the side tag 
rebuild(for this change). We could have done that in one pass without causing 
any observable breakage for anyone.

> The corresponding Fedora Go packaging conventions are therefore
> EFFECTIVE for new rawhide builds. For the first time in Fedora’s
> history, we will be able to perform Go package builds conforming to an
> approved Fedora Packaging Guideline.
> 
> Packaging documentation:
> https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
> and approval: https://pagure.io/packaging-committee/issue/382
> The go-rpm-templates package provides more complete info.
> 
> F31 change page:
> https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
> and approval: https://pagure.io/fesco/issue/2120

It seems that this change has been accepted as Self Contained Change but IMHO 
it is System Wide Change as it seems to affect (nearly) all Go based packages 
in distribution(and will require work/attention of people that are not change 
owners, actually not accounted for in change proposal). For past several 
releases I have been doing rebase of Go compiler change(yet to be filed for 
F31) that is IMHO comparable(maybe a bit smaller) in scope and they were always 
deemed by FESCO as System Wide Changes. This really leaves me confused. Could 
someone from FESCO clarify? 

> 
> While the guidelines will feel familiar to anyone who created a Fedora
> Go packages in the last two years, they DO include a backwards-
> incompatible change. Making GOPATH manipulation robust required moving
> the corresponding logic to %prep with a new %goprep macro.
> 
> Therefore, existing specs are expected to fail without the addition of
> the %goprep call.

When this has been discussed, new macros have been presented to me as backwards 
compatible(i.e. current packages will work and build as is, although requiring 
refresh to adopt new features), so it has not been concern for me. Other issue 
that I have is that you have not communicated this change(landing the new macro 
package) prior it happening here or elsewhere. I'm a Go SIG member(and 
maintainer of the previous macros packages, which by the way are still out 
there) and I have not been aware of this pending change landing now.

> 
> This is of course not the end of the road, just a key step.

I would much appreciate if you would communicate a bit more before landing such 
a big changes(go-rpm-package) in future, it would made possible to avoid some 
breakages, collect feedback and improve overall packagers experience. I think 
that communication is not easy, at least not for me, and I don't think that it 
is my strong skill, but we shouldn't resign on it as it is IMO crucial part of 
the Fedora community. Is there something that can I do to improve the 
information flow from my side?

JC

> 
> It opens the way to a mass cleanup and refresh of the Fedora Go stack.
> https://pagure.io/packaging-committee/issue/901
> 
> A preview of this refresh is available here:
> https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/
> 
> Enormous thanks to
> – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing
> updating and cleaning-up all those packages, and to
> – Elliott Sales de Andrade (Qulogic), that picked up maintenance of
> golist and fixed many of its long-standing bugs and limitations.
> 
> Many thanks to the mock, rpm and redhat-rpm-config maintainers,
> that integrated the changes, we built upon (Igor Gnatenko, Florian
> Festi, Miroslav Suchý, Panu Matilainen)
> 
> The macro set supports Go DynamicBuildRequires
> https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
> 
> They will be usable in mock as soon as rpm 4.15 lands
> https://fedoraproject.org/wiki/Changes/RPM-4.15
> 
> Use in koji or copr will have to wait for the corresponding refresh
> buldsystem-side. So this part of the change is a technology preview for
> now.
> 
> Best regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email 

Re: Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines

[Jakub Cajka]

- Original Message -
> From: "Ben Cotton" 
> To: devel-annou...@lists.fedoraproject.org, "Development discussions related 
> to Fedora"
> 
> Sent: Friday, April 12, 2019 10:11:51 PM
> Subject: Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging 
> Guidelines
> 
> https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
> 
> == Summary ==
> 
> The [[PackagingDrafts/Go| current Go packaging guidelines]] have been in a
> draft
> state for several years now, and they do not reflect the
> [[ More_Go_packaging|current practices ]] from the Go SIG. As a result of new
> RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to
> formally adopt new Go Packaging Guidelines, which aim at automation,
> reliability
> and simplicity.
> 
> == Owner ==
> * Name: [[User:eclipseo| Robert-André Mauchin]]
> * Name: [[User:jcajka| Jakub Cajka]]

Hello, as much as this change proposal excites me and I'm looking forward to 
it. I'm unfortunately currently not able to own this change, regardless as much 
I would really like to. 

I would also like to note that I have been added as owner arbitrarily, without 
notice and without my consent and therefore I would like to be removed from the 
owner list.

Thanks.


> * Name: [[User:nim| Nicolas Mailhot]]
> * Name: [[User:qulogic| Elliott Sales de Andrade]]
> 
> * Email: 
> 
> 
> == Detailed Description ==
> 
> Over 775 Go packages are currently residing in Fedora's repositories, yet no
> formal guidelines have ever been approved. As a result, the various Go SPECs
> are
> inconsistent and most often outdated. Moreover, the next version of Go, 1.13,
> will introduce the concept of modules by default, which will completely
> change
> how Go libraries are distributed. With the current state of our tooling, the
> Go
> SIG is not prepared to face such a drastic change.
> 
> [[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which
> will allow us to disconnect the upstream Go tooling from the downstream
> integration inside RPM. This will allow us to adapt easily to future upstream
> changes without the need to rewrite our SPEC catalogue.
> 
> == Benefit to Fedora ==
> 
> * Simplicity: SPEC files are simpler, less error-prone
> * Automation: the new macros computes packages definition, Requires,
> Provides and has provision for the new automated BuildRequires
> * Standardization of SPEC files across the Go library
> * Drastic reduction of boilerplate and SPEC size
> * Automatic removal of vendored code
> * Ease of testing: all units tests are detected and run
> * Ease of upkeep
> * Ease of adaptation to upstream changes
> 
> == Scope ==
> 
> * Proposal owners:
> ** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
> Get the last macros approved in ''redhat-rpm-config'']
> ** Get ''[https://pagure.io/golist golist]'', the tool detecting
> dependencies, updated and split from the
> ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
> package
> ** Release ''GOPATH'' directory ownership from the
> ''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it
> can be  managed by the ''[https://pagure.io/go-rpm-macros
> go-rpm-macros]'' package
> ** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and
> reviewed
> ** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros
> go-srpm-macros]'' and
> ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
> ** Port existing Go packages to the new macros (it probably won't be
> finished by [[Releases/31 | Fedora 31]])
> 
> * Other developers: N/A (not a System Wide Change)
> 

I believe this affects all packagers maintaining Go based packages as they 
should update their packages up to the new standard, so we don't fragment the 
package base. So IMO this should be system wide change.

JC

> 
> * Policies and guidelines:
> [https://pagure.io/packaging-committee/pull-request/883 Get the Go
> packaging guidelines approved by the Packaging Committee]
> 
> == Upgrade/compatibility impact ==
> 
> No compatibility impact is expected. All the new macros are backward
> compatible
> with the old ones.
> 
> == How To Test ==
> 
> The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/
> nim/macros-ng]
> can be used to test the new macros on Rawhide. Sample SPEC files are
> available
> in the FPC Guidelines proposal.
> 
> == User Experience ==
> 
> The user impact is minimal or nil. As a result of the simplification of SPEC
> files, we may ship updated libraries more quickly, and it may be easier for
> new
> contributors to package Go applications.
> 
> == Depen

Re: New Golang Packaging Guidelines: Feedback needed and appreciated

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Cc: "nicolas mailhot" , 
> gol...@lists.fedoraproject.org, jca...@redhat.com, "Discussion
> of RPM packaging standards and practices for Fedora" 
> 
> Sent: Friday, March 22, 2019 7:46:23 PM
> Subject: New Golang Packaging Guidelines: Feedback needed and appreciated
> 
> Hello Fedora people,
> 
> As you may or may not know, currently applied Golang packaging guidelines
> have always been simply a « draft ». Part of the new Go SIG mission is to
> update ours best practices and tooling. As such, Nicolas Mailhot designed  a
> new set of macros based on lua script to improve our current situation. As a
> result, we needed to draft new guidelines to reflect the future
> implementation
> of these macros.
> 
> I have written these new guidelines and I'd like to ask for your help in
> order to review them: both from current Go SIG packagers point of view and
> from novices in the matter, in order to make sure they are clear and
> understandable enough for everyone.
> 
> I have uploaded a mirror of the Guidelines on my FedoraPeople space:
> https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
> 
> Please, if you have 10 mn to spare, read them and send me feedback. If
> you
> wish you can also directly send me a Merge Request on Pagure:
> https://pagure.io/fork/eclipseo/packaging-committee/  (branch
> implement_golang_guidelines).
> 
> Best regards,
> 
> Robert-André
> 

Thanks, great work.

I unfortunately I have managed to just go trough roughly half of them, but they 
look great so far. There some parts that needs minor fix up, some a bit of 
expanding and IMO there are some that can be omitted with just pointer to the 
general guidelines.

I hope that I will be able to send some PRs and open some issue/enhancement 
requests by the next week. Also I will try to ask someone from the Fedora docs 
team to take a look at the non-technical side of the things.

Thanks again for writing the new guidelines draft,

JC

> 
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Deciding on Fedora Go (Golang) packaging future

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Development discussions related to Fedora" 
> , gol...@lists.fedoraproject.org
> Sent: Monday, March 18, 2019 8:58:39 PM
> Subject: Re: Deciding on Fedora Go (Golang) packaging future
> 
> Le lundi 18 mars 2019 à 04:55 -0400, Jakub Cajka a écrit :
> 
> Hi,
> 
> >  Golist exist based
> > on Nicolas's initial requests and requirements(created based on them
> > by jchaloupka in his free time over one year ago),
> 
> This is quite a simplistic way to present things, which is injust to
> Jan and to me.
> 
> I wished to make Go packaging in Fedora less a manual shore. I wrote
> some shell and lua code to do it. You (and Jan) objected to this code
> and asked me to restructure it around golist. Jan had already written
> most of golist to analyse the Go code he dealt with (not just in an rpm
> context).
> 
> golist is very much Jan's project and design. We collaborated: Jan
> adapted his code so I could plug it within my rpm automation, just like
> I adapted my code around the golist design.
> 
> Some things were indeed added to golist at my request. But, there are
> lots of things in golist I never asked for: some I didn't think of,
> some I had no need of, some I disagreed with, some that made my life a
> lot harder than it should have been rpm macro-side.
> 
> And, Jan could probably say the same things about my rpm shell+lua
> macro code.
> 
> So, to give everyone's his due, the Fedora rpm macro code is my work
> and design, with some collaboration by Jan, and the golist code is
> Jan's work and design, with some collaboration by me.
> 
> We definitely didn't always agree or approve the design decisions the
> other made. We made do with those disagreements, which is how things
> can move forward in a team.
> 
> Best regards,
> 
> --
> Nicolas Mailhot

Yes this is what I have been trying to convey, sorry that is wasn't 
obvious(although I have consciously omitted that something similar is part of 
Gofed as it is IMHO not relevant in this context). As you wrote golist that is 
part of the Fedora is there based on your request and requirements. If you have 
not requested it, it wouldn't been there/here.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Deciding on Fedora Go (Golang) packaging future

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: gol...@lists.fedoraproject.org
> Sent: Sunday, March 17, 2019 3:36:47 PM
> Subject: Re: Deciding on Fedora Go (Golang) packaging future
> 
> On dimanche 17 mars 2019 09:29:28 CET Nicolas Mailhot wrote:
> > Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit :
> > Hi,
> > 
> > > 
> > > Numerous Golang packages are plagued with an issue caused when
> > > jchaloup uploaded Glide files. In a lot of case he has doubled the
> > > glide.yaml instead of adding the qlide.lock:
> > > 
> > > Source1:glide.yaml
> > > Source2:glide.yaml
> > > 
> > > The problem is that when goinstall doesn't find the glide.lock file:
> > > 
> > > 
> > >  %goinstall glide.lock glide.yaml
> > 
> > 
> > The fix to avoid creating things that do not exist just because the
> > packager specified them explicitly in its spec has been written for a
> > month¹:
> > https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
> > 
> > Like all the fixes that accumulated in golist and in go macros for a
> > year, it is waiting for the Go SIG to decide what it wants to do with
> > its packaging tooling. Waiting for jchaloup to change things on his own
> > authority without asking anyone does not work anymore².
> > 
> > ***
> > It would be really nice if a sufficient number of Fedora Go packagers
> > attended the next SIG meeting so we have the quorum to decide what to
> > do, find volunteers to do the necessary work, and mandate them to do
> > this work.
> > ***
> > 
> > The  next meeting is scheduled in three days on 2019-03-20 from
> > 16:00:00 to 17:00:00 UTC at fedora-gol...@irc.freenode.net
> > 
> > Of course some packagers are more equal than others, so whatever the
> > quorum I can't imagine anything going forward without the approval and
> > support of the Fedora golang maintainer.
> > 
> > Right now we have one proposal on the table:
> > https://pagure.io/GoSIG/go-sig/issue/20
> > 
> > People are free to write up their own alternative, either a variation
> > on this plan or something else entirely. Remember, any plan is
> > worthless if no one volonteers to implement it. So "someone (else)
> > should do things" and no one wants to do it won't take us anywhere.
> > 
> > The key weakness of my plan is that it only considers short-term
> > existing problems, upstream has stated it will switch on Go modules by
> > default in August, and that will change Go packaging a lot. My
> > preference would be to fix what we have before engaging in a Go module
> > journey, but an alternative would be keep things as they are (bugs
> > included) and just dump the existing packaging code to replace it with
> > *something else* at Go module time (big bang approach).
> > 
> > However, if the *something else* is written by me, it is likely to
> > require pretty much the same tooling setup and spec syntax as proposed
> > in my plan (replacing golist with something module-oriented).
> > 
> > Regards,
> > 
> > 
> > ¹ Of course it will not fix the consequences of past errors, just
> > prevent new ones
> > 
> > ² And, jchaloup had facilities others do not have (working @rh, trusted
> > by the Fedora golang maintainer, owning many key packages).
> > 
> > --
> > Nicolas Mailhot
> 
> 
> The issue seems to hinge or writing new Go guidelines for the new macros, he
> example SPECs could be a part of that but not the only source.

Precisely, that is my main issue. Whenever I have brought this up with Nicolas, 
I have been told that he is not going to do such a thing as it is useless and 
it will require significant effort. I can agree only with the latter. As long 
there is no (draft of) policy and user/packager facing documentation and 
Nicolas is effectively only person that understands how the new macros work and 
he doesn't want to share this knowledge with wide public. I can't endorse them 
in anyway and I will dare to say they are not fit for Fedora in anyway until 
this crucial part is added.

And as Nicolas is pointing out he will probably have to take ownership of all 
the dependencies of his macros. Golist exist based on Nicolas's initial 
requests and requirements(created based on them by jchaloupka in his free time 
over one year ago), if they have shifted he will probably need to 
change/implement the tools that he needs as unfortunately Jan doesn't have free 
time that he could dedicate to Fedora anymore(or at least it seems so).

Lastly I believe that this official change of macros will require official 
"System wide change proposal" filed as it affects literally every Go package in 
Fedora, regardless if it will get SIG's(or anyone's) endorsement.

Looking forward to see you all on the next SIG meeting.

JC

PS: CC'ed also Fedora's devel as the initial post did

> 
> 

Re: Ursa Major (modules in buildroot) enablement

[Jakub Cajka]

> Please do not drag Go into this if you want to handwave Go away
> problems. Yes modules will be useful in Go but only to blow away in EPEL
> the rotten Go codebase RHEL ships.
> 
> But anyway, since you referred to GO.
> 
> Go is the perfect example of why bundling as a general approach does not
> work and does not scale. In case you haven't noticed years of bundling
> Go side has resulted in such a deep widespread rot Google is scrambling
> to write a Go v2 language version that will force Go projects to version
> and update.
> 
> All the people that claim bundling allows “using a slightly older
> version” (implying it's a good safe maintained older version) are lying
> through their teeth. Yes it allows doing that but that's not how people
> use it. And it does not matter if you bundle via self-provided windows
> DLLS, containers, flatpacks, modules or rhel versions.
> 
> Bundling basically allows reusing third party code blindly without any
> form of audit or maintenance. You take third party code, you adapt your
> code to its current API, and you forget about it.
> 
> You definitely *not* check it for security legal or other problems, you
> definitely *not* check regularly if CVEs or updates have been released,
> you definitely *not* try to maintain it yourself. Any bundler dev that
> tells you otherwise lies. The average bundler dev will tell you “Look at
> my wonderful up to date award-wining modern code, security problems? Ah,
> that, not my code, I bundle it, not my problem”.
> 
> It is however a *huge* problem for the people on the receiving end of
> the resulting software, static builds or not. Static builds do not add
> missing new features or fix security holes. They just remove the shared
> libs that could  be used by the sysadmin use to track them. And since
> malware authors do not bother identifying how software was compiled,
> before attempting to exploit it, static builds do not hinder them the
> slightest.
> 
> While trying to improve Go packaging in Fedora by myself I found serious
> old security issues in first-class Go code. First-class as in benefiting
> from huge publicised ongoing dev investments from major companies like
> Google, Red Hat or Microsoft. It’s not hard, you do not even need to
> write Go code, just take the bundled pile of components those bundle,
> and read the upstream changelog of those components for later versions.
> You will hit pearls like “emergency release because of *** CVE”. Or
> “need to change the API to fix a race in auth token processing”. And the
> answer of the projects that bundled a previous state of this code was
> never “we have a problem” or “we have fixed it some other way” but “go
> away, we haven’t planned to look or touch this code before  future>”.
> 
> And, again, I’m no Go dev, or dev in general, I didn’t even try any form
> of systematic audit, that was just the bits jumping to attention when I
> hit API changes and had to look at the code history to try to figure
> when they occurred. The day any bundled codebase is subjected to the
> kind of herd security research java was some years ago and CPUs are
> today sparks are going to fly all over the place.
> 
> And this is a natural phenomenon trivial to explain. Maintaining old
> code versions is hard. Upstreams are not interested in supporting you.
> You have to redo their work by yourself, while forbidding yourself API
> changes (if you were ready to accept them you wouldn't have bundled in
> the first place). And modern code is so deeply interdependent, freeze
> one link in the dependency web and you get cascading effects all other
> the place. You quickly end up maintaining old versions of every single
> link in this web. If you try to do it seriously, you effectively have to
> fork and maintain the whole codebase. IE all the no-support problems of
> barebones free software, with none of the community friends help that
> should come with it.
> 
> That's what RH tries to do for EL versions. It takes a *huge* dev
> investment to do in a semi-secure no-new features way. And after a
> decade, RH just dumps the result, because even with all those efforts,
> it reaches terminal state and has no future.
> 
> There is only one way to maintain cheaply lots of software components
> that call each other all over the place. That’s to standardise on the
> latest stable release of each of them (and when upstream does not
> release, the latest commit). And aggressively port everything to the
> updates of those versions when they occur. If you are rich, maintain a
> couple of those baselines, maximum. flatpackers do not say otherwise
> with their frameworks (except I think they deeply underestimate the
> required framework scope).
> 
> And sure, every once in a while, porting takes consequent effort, it can
> not be done instantaneously, devs are mobilized elsewhere, etc. That's
> when you use targeted compat packages, to organise the porting effort,
> to push the bits already ported while keeping 

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Robert-André Mauchin" , jca...@redhat.com
> Sent: Monday, October 22, 2018 5:32:55 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-22 16:52, Nicolas Mailhot a écrit :
> 
> >> -rpm.define("gosetup(a:b:cDn:Tq) %forgesetup %{?**}")
> >> +rpm.define("gosetup %forgesetup")
> > 
> > Rhaa that's an old leftover of the time when Jan pulled a copy of the
> > forge macros in go macro copy, because he thought redhat-rpm-config
> > maintainers would take ages to review stuff. I thought every trace of
> > this had been eradicated long time ago. %gosetup is certainly not part
> > the use pattern documented in the wiki since march.
> 
> Anyway Jan removed every trace of his attempt to internalise the the
> forge macros a week after the commit you point to, *except* for this
> stray line. Don't know if leaving this line was an afterthought, or if
> he didn't want to fix some specs that had been created in the weeks when
> he experimented with the internal forge macro implementation. The thing
> is done now.
> 
> And what this line does is awfully dangerous and brittle. I could not
> put anything like this in redhat-rpm-config, it would be rejected
> directly.
> 
> So, we probably need to spin another go-macros build with a normal
> gosetup declaration not hidden within another macro. And then live
> unhappily afterwards with the messup set in stone. Not exactly the kind
> of thing you want to do in the middle of a sig reorg.
> 
> No chance to remove the problem call from the specs I suppose?

Bringing this back to devel as I don't understand why this discussion should be 
held in private.

AFAIK unless you are volunteering to fix and rebuild all the affected packages, 
it is not going away on its own. I don't think that playing the blame game will 
move us anywhere. It has been there for some time so it got some considerate 
adoption.

I don't understand why are you not following process for system wide changes 
for such disruptive change. It seems to me that you are not realizing possible 
impacts of your changes and are actively downplaying testing(IMO integral part 
of the development) before pushing it in to the production(rawhide). I perceive 
this kind of practices as extremely dangerous for sustainability of Fedora 
packaging. Could we please revert the change(Igor?) and stop pushing it until 
it is formalized(including docs, so it is outright obvious what is intended as 
supported) as System Wide Change proposal and approved by FESCO(for F30)?

JC

> 
> --
> Nicolas Mailhot
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Jakub Cajka" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Monday, October 22, 2018 1:55:02 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-22 13:09, Jakub Cajka a écrit :
> 
> > I think that it would be reasonable to test the changes against the
> > Fedora package base before even pushing the change in to the rawhide.
> > This kind of unnecessary breakage is easily avoidable if you would
> > spent sometime on testing this by scratch rebuilding the Fedora
> > packages locally, prior pushing this.
> 
> There's certainly many things that could be done better if someone took
> the time to do it. But, everyone's time is limited including mine. I
> already rebuild hundreds of Go packages regularly to QA the changes. It
> takes days. Those 40 packages were not part of the set.

In my experience this doesn't require that much time as this is fully 
scriptable from getting all the dependent(Go based packages) and rebuilding 
them locally(even using something dumb as mockchain, it takes under 1 day to 
complete for Go, without needing any babysitting(in VM on i7/ssd laptop)). One 
day(of computation power) seems like reasonable trade-off for not wasting time 
of significant number of (Go) packagers by breaking macros. Or AFAIK it should 
be possible to do such change in the koji side tag(ideally with formal change 
proposal) not affecting the main tag.

> 
> So, if we want more things to be done with the existing manpower, we
> need to fix all the thousands of little things that waste the available
> contributor time:
>   * rehost things cleanly on pagure
>   * clean up the maze of repurposed Go infra specs so any change or fix
> can be QAed and pushed quickly
>   * contribute the fixes we want or need to the Fedora packages that ship
> the corresponding code, instead of 'saving' time by doing messy
> ill-thought workarounds in a private spec file generator

I'm sure that we all want to advance Fedora, but could you be more specific? 
What needs to be done in your opinion? Would you mind opening issues in Go SIG 
for those specific changes(or better PRs in respective packages)?

JC

> 
> And then when things are clearly in one place this place can be used to
> sync the reviews, QA runs and Koji/copr mass rebuilds. Which is clearly
> not the case today.
> 
> Call that purism if you like
> 
> --
> Nicolas Mailhot
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Robert-André Mauchin" , "Development 
> discussions related to Fedora"
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, October 22, 2018 10:00:40 AM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
> > Yeah all "gosetup -q" (which is gofed default) are broken because of
> > your commit:
> 
> Well I know no such a thing, there was never any gosetup macro in the
> macro set, and I think I told you a year ago I would not define a
> gosetup macro just to avoid typing forgesetup, unless it actually added
> some processing over the forgesetup macro. That would obfuscate specs
> for no good reason and increase gratuituously the maintenance surface
> (as we see *now*).
> 
> And I doubt -q is your problem, since (*precisely for backwards
> compatible reasons) it is still accepted by forgesetup (even though it's
> ignored, because it’s the default behaviour now).
> 
> Oh, I see, I forgot to add a phantom -q to forgeautosetup as it already
> was already its default behaviour. So you're forcing somewhere a -q that
> I don't think was ever needed. I will add the -q to the macro definition
> if that makes you feel better.
> 
> So, no biggie. Easy to fix. That's why such changes hit -devel before
> anyone dreams of queuing them to stable.

I think that it would be reasonable to test the changes against the Fedora 
package base before even pushing the change in to the rawhide. This kind of 
unnecessary breakage is easily avoidable if you would spent sometime on testing 
this by scratch rebuilding the Fedora packages locally, prior pushing this.

Could we avoid any such kind of regressions in the future?

JC

> 
> What package exactly installs your gosetup macro in /usr/lib/rpm so I
> can see what other things it tries to do? I see no macro file in the
> Fedora gofed package manifests.
> 
> If you could PR your changes to the official Fedora packages that
> coordinate Fedora go macros (the go-macros repository on github, that
> will be rehosted in pagure as soon as the @rh contributors ok the move)
> instead of doing it in other places, that would be a tad easier to
> coordinate.
> 
> > Please revert this, we should be able to use whatever flag supported
> > by %setup and
> >  %autosetup, not a small subset.  How do you even pass the basic -n
> > flags now?
> 
> So basically, you have a macro, which sole purpose is to pass
> precomputed -n values to *setup, and you want to use it with manual -n
> flags. Why? Could you tell us what exactly is the point of
> 
> 1. wrapping a Fedora macro in another name just because you do not like
> the official macro name in Fedora
> 2. overriding the only thing this macro does over autosetup
> 3. and then complaining all the argument passing to autosetup does not
> work as you wish it does
> 
> So all this complexity, because what you really want is to use autosetup
> directly. Then just do. What's the problem exactly with typing autosetup
> in your spec? No one stops you from doing it.
> 
> One reason I removed the -n in forgeautosetup and forgesetup precisely
> to stop packagers confusing themselves the way you are confusing
> yourself.
> 
> The other being -n is incompatible with the processing of multiple
> archives that many people asked me to add to the macros. Which is
> finally implemented after months of work. And which just hit rawhide
> after more than a month of review.
> 
> So, do you have actual spec files in Fedora with this use of the redhat-
> rpm-config macros? If that is the case, I can put those flags in the
> macros so you can continue shooting yourself in the foot using undefined
> known-broken use patterns. If not, I'd rather remove the possibility
> altogether before someone harms himself.
> 
> > With you mods, we have to edit hundreds of specs to remove
> > the -q flags.
> 
> And that concretely, if why pre-generating specs instead of making the
> effort to include default processing in the macro code Fedora ships is
> wrong.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Fabio Valentini" 
> Sent: Monday, October 15, 2018 11:56:45 AM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-15 09:09, Fabio Valentini a écrit :
> 
> > Because right now, package builds prepared on fedora 27-29 will result
> > in failing koji builds for rawhide - and nobody should have to install
> > rawhide to be able to build packages.
> 
> Well basically you can
> 1. use a rawhide vm on container of whatever to prepare your rawhide
> srpms (but, as you noted, not cheap to setup)
> 2. use mock --shell to get a cheap rawhide buildroot srpm env (in theory
> that works – not tested)
> 3. use a local rebuild of the rawhide redhat-rpm-config to match rawhide
> behaviour (only takes changing dist definition in
> /etc/macros.d/macros.dist to %{?distprefix}.fcxx
> 4. use a local backport of the code. You basicaly just need to insert
> the following at line 251 or 252 of the macros.forge rawhide file
>-- Workaround releases where distprefix is not used by default
>local dist = rpm.expand("%{?dist}")
>local edistprefix = rpm.expand(distprefix)
>if (edistprefix ~= "") and (string.sub(dist, 1, #edistprefix) ~=
> edistprefix) then
>  rpmmacros.explicitset("dist", "%{?distprefix}" .. dist,verbose)
>end
> 5. ask to accelerate the backport to stable. I can prepare the backport
> PR, but applying the PR is out of my hands
> 6. ask redhat-rpm-config maintainers to process
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
> since I have a backport already prepared and tested for this one
> 7. all of the above

And what about backing up the breaking change in Rawhide? At least until there 
is a backward compatible way of doing that(or it is backported in to the stable 
releases)?

To be honest we should not introduce deliberately backwards incompatible 
changes without at least publicly announcing them way ahead(and in general 
avoid them). This creates really bad experience for all and waste lot of time 
of the packagers.

JC

> 
> I don’t know which solution best matches your workflow
> 
> And normally, you do stuff in and for rawhide first, and then backport,
> but this is kind of a special case since the rawhide bit does not
> usually extend to the srpm part, and Go packaging in Fedora is so
> immature every release is pretty much a devel release from Go's POW, so
> I understand where you're coming from.
> 
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Golang SIG primary goals?

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: devel@lists.fedoraproject.org
> Sent: Tuesday, August 28, 2018 10:37:06 AM
> Subject: Re: Golang SIG primary goals?
> 
> Hi,
> 
> Just to get people thinking before the meet…
> 
> IMHO, the core objective of the SIG should be to maintain a consistent
> self-hosting up-to-date baseline of Go software in rpm form, that can
> then be used to build other forms of Fedora deliverables (flatpacks,
> coreos images, etc)
> 
> That implies:
> — continuing to improve the go/rpm plumbing
>(packager time should be spent on fixing project-specific problems,
> not writing lots of generic automatable declarations)
> – getting one form of Go packaging guidelines approved by FPC
> – producing a package set that conforms to the above
> – refreshing periodically the set (at least one mass rebuild/version
> refresh per Fedora release).
> – reporting upstream everything that fails in the set to raise the bar
> on the bits we package, gain legitimacy and provide value to upstream –
> ideally also work on fixes but just identifying and reporting problems
> regularly would be a huge first step
> – scrapping all the Fedora Go packages that do not comply. Not a fan of
> zero defect approaches but there is a point where keeping lots of
> obsolete/non conformant packages discourages old and new packagers alike
> 
> I don't really see the point of producing another set of
> bundled/containerized/imaged Go software, there are lots of them on the
> market, the drawbacks are increasingly well known (lots of rotting
> insecure third party code squirreled away inside the bundled sets), I'd
> rather have a smaller breadth of software that can demonstrate a
> software engineering approach than lots of half-assed packages that
> muddle waters and satisfy no one. Though given how Go software in
> massively reusing other code even focusing on a small set of apps will
> require a huge number of packages.
> 
> The areas that need work short term are:
> 
> A packaging
> 
> B cleaning up and consolidating guidelines (need to spread the load as
> it is quite soul crushing work).
> 
> C defining an org to import sets of Go packages within the SIG. Get
> approval to whatever changes in the Fedora process necessary to review
> and import easily apps spread over hundreds of packages (the Fedora
> process is really not geared towards apps that reuse hundreds of other
> projects and require hundreds of packages imported as a set)
> 
> D investigate vgo:
>1. get POC support in go-macros (go-compiler & go-srpm-macros)
>2. test if the result can be used :
>   — are the module definitions written upstream forward-facing or
> locking specific version we can not use
>   – Go devs could not write a dep engine that worked like the rest of
> the software world, rpm included, does it matter in practice if
> dependency declarations written for the Go dep engine are dumped in the
> rpm dep engine, that follows differing resolution rules
>3. decide if we adopt vgo or not. If yes, probably easier to define
> how to write Fedora-friendly module definitions for projects that lack
> them than try to support an hybrid set of packages (with and without
> module defs). Module defs can be upstreamed as part of the packaging
> 
> E investigate automation of build requires (other SIGs did it but
> there's no support in rpm syntax for it, you need to talk to mock over a
> socket ie code a specific utility)
> 
> D. finishing a working baseline for Fedora Next, then rebase EPEL on it
> and forget about the past (the Go non compiler parts in EPEL have rotten
> to much for anyone to use, and I don't see anyone willing to invest the
> effort that would be required to salvage them in an evolutionary way,
> just accept it, get an exemption, and reboot from working Fedora state)

Could you please turn those in to issue in 
pagure(https://pagure.io/GoSIG/go-sig/issues)? I don't believe that these ML 
will be best for keeping track of those and I'm afraid that they might stay 
rotting here.

> 
> I could spend some time on most of those (though I'd rather pass on B,
> already done my part, and D/E would be the most fun and probably the
> most useful for the rest of the SIG).

For B I would much appreciate if you would mark which parts of your proposals 
got implemented and in which way. It would greatly help anyone picking this 
topic after you. If you really do not plan to finish all the work that you have 
started.

Thanks,

JC

> 
> However, my initial objectives were to produce clean prometheus and
> grafana Fedora packages, I finished the Go part a few months ago, but
> they both include a javascript layer, so I'll probably have to spend
> part of my packaging time on the js front. I'd really prefer if someone
> started a javascript SIG I could offload those to, I really don't have
> the cycles to progress quickly on packaging rules and tooling for two
> 

Re: Golang SIG primary goals?

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: gol...@lists.fedoraproject.org, devel@lists.fedoraproject.org
> Sent: Friday, August 24, 2018 4:42:03 PM
> Subject: Golang SIG primary goals?
> 
> Hey guys and gals,
> 
> Can we start to discuss this SIG goals? What each of you are expecting

IMO meeting would be best so we can introduce ourselves. See my other email :)

I have taken liberty and have created pagure group 
https://pagure.io/group/GoSIG for the SIG and tracking project 
https://pagure.io/GoSIG/go-sig for all the ideas and work. I have added all 
folks listed in the wiki page to the group. Also there is issue for adding new 
members(or those that I have forgotten to add) 
https://pagure.io/GoSIG/go-sig/issue/1.

> A few ideas:
> 
>  - Making https://fedoraproject.org/wiki/More_Go_packaging official and
> working on bringing them to EPEL7

Don't forget about EPEL6, too. ;)

I have created issue for the guidelines at the tracker. Along with some other 
that popped on my mind.

> 
>  - Assigning current Go packages to the SIG so each member of the SIG can
>  work
> on them, similar to https://src.fedoraproject.org/group/rust-sig
> Many Google packages are inter-dependent, this would ease synchronising them.
> 
>  - Working toward packaging more: I'm thinking about unbundling kubernetes
>  and
> docker.
> 
>  - Developing tools to maintain up-to-date our current set of Go packages,
> some of which are left outdated since their creation.
> 
> Any other ideas? I'd like to move forward as soon as possible.

Would you please create tracking 
issues(https://pagure.io/GoSIG/go-sig/new_issue) for the above ideas(or any 
other you might have) in the pagure project so we can discuss it there with 
better tracking/threading?

JC

> 
> Best regards,
> 
> Robert-André
> 
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/message/JII4CSPFA4PNTE6TCR477U7RDSU4Y3Z3/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Golang SIG for Fedora

[Jakub Cajka]

- Original Message -
> From: "Michael Cronenworth" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, August 10, 2018 8:11:07 PM
> Subject: Re: Golang SIG for Fedora
> 
> On 08/09/2018 05:12 AM, Jakub Cajka wrote:
> > I have create the SIG page in the
> > wikihttps://fedoraproject.org/wiki/SIGs/Go.
> > Please add yourself in to the members list if you are interested to
> > participate.
> > If you have any comments or improvements to the SIG page please bring it up
> > or just do it:).
> >
> > I believe that next step should be meeting where we will share our
> > expectations, etc. Please let me know what would suite you.
> 
> Random Go question: Will you be working to use the Go plugin system instead
> of
> statically compiling end-user binaries?
> 
> It seems against Fedora principals to allow Go into Fedora with the way all
> Go
> programs are compiled today.

I believe that the Go ecosystem is not against the guidelines since like 3y 
ago(same time I'm around Go). I plugins IMO doesn't make sense in the Fedora 
for something like equivalent to dynamic linking. I'm for like 2y considering 
dynamic liking, which unfortunately dosn't make much sense for regular 
libraries/binaries as most of the projects do not have stable API, but it might 
make sense for the stdlib as it is fairly stable.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MZB4SYIPKUYY4RSC5HXHYKHQM2423LIS/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GT643GIGSS6ZYVERUGU57IFSWUZGGXYF/

Re: Golang SIG for Fedora

[Jakub Cajka]

- Original Message -
> From: "Ricardo Martinelli Oliveira" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 6, 2018 3:47:44 PM
> Subject: Re: Golang SIG for Fedora
> 
> I think we already have tools for that. What I expect with the SIG is
> something that could improve the Go Packaging best practices listed in
> https://fedoraproject.org/wiki/PackagingDrafts/Go
> 

Yeah, I believe that is one of the most important tasks, but I envision that 
SIG will be place to kind of pool and share our resources/time/experiences and 
some issue/work(in addition to the BugZilla and other Fedora standart tools) 
tacking system could be really helpful. Place where we could put our ideas and 
nice to have things that we don't have time to work on currently, but not only 
those. It would also make more apparent to the outside progress of some bigger 
scope projects like the packaging guidelines.

JC

> 
> On Mon, Aug 6, 2018 at 9:10 AM, Vitor Ramos  wrote:
> > I think that we can mature in the first moment the SIG, and in other
> > moment, channels, groups, and subjects in another moment. An approach
> > about the taiga is about the development of Tools that contemplate the
> > Golang in Fedora Project?
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSY4GJ36T6LSVEWLOWHE5QP2BP4Q2HVZ/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TF6NM4E6DHHW6NO6TUGDF44IPHFW3VG4/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3AKM7XV5KWL5RAB74URA5DJ3NTMNR3WA/

Re: Golang SIG for Fedora

[Jakub Cajka]

- Original Message -
> From: "Jakub Cajka" 
> To: "nicolas mailhot" , "zebob m" 
> , "ricardo martinelli oliveira"
> , "Jan Chaloupka" 
> , "Derek Parker"
> , "Paul Gier" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" 
> Sent: Friday, August 3, 2018 1:05:22 PM
> Subject: Re: Golang SIG for Fedora
> 
> Thank you very much for your interest.
> 
>   I will now create SIG wiki page(and let you know to add yourself there),
>   IRC channel(#fedora-golang, making it official). I believe we can use
>   gol...@lists.fedoraproject.org as the mailing list. And as it has been
>   suggested to the container SIG I will create Go group at
>   https://discussion.fedoraproject.org/ for more user faced discussions.
>   Also I have been thinking about having
>   taiga(https://taiga.fedorainfracloud.org), pagure project or alike for
>   issues, idea and work tracking, but I would postpone creating and working
>   on it until after we can meet and discuss it.
> 
>   With Flock next week, if you will be there please let me know as it would
>   be great to meet up there.
> 
>   After the Flock I would like to organize meeting of us all. I'm not sure
>   where IRC/or some other platform and when. Could you reply to me off the
>   list with days(ideally between 13-31 of Aug) and time that would best
>   suite you and your preferred way of the meeting(IRC, hangouts, jitsi,...).
>   I think that it would be best to meet on jitsi or other video chat/meeting
>   platform.
> 
> JC

I have create the SIG page in the wiki https://fedoraproject.org/wiki/SIGs/Go.
Please add yourself in to the members list if you are interested to participate.
If you have any comments or improvements to the SIG page please bring it up or 
just do it :).

I believe that next step should be meeting where we will share our 
expectations, etc. Please let me know what would suite you.

JC

> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/message/RN7MWWZR3V2SWAZB3XZ36LPMVZKCPYQH/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FTTNALB6QOUOZBAKWI2MMFYHF426HOJJ/

Re: Golang SIG for Fedora

[Jakub Cajka]

  Thank you very much for your interest.

  I will now create SIG wiki page(and let you know to add yourself there), IRC 
channel(#fedora-golang, making it official). I believe we can use 
gol...@lists.fedoraproject.org as the mailing list. And as it has been 
suggested to the container SIG I will create Go group at 
https://discussion.fedoraproject.org/ for more user faced discussions. Also I 
have been thinking about having taiga(https://taiga.fedorainfracloud.org), 
pagure project or alike for issues, idea and work tracking, but I would 
postpone creating and working on it until after we can meet and discuss it.

  With Flock next week, if you will be there please let me know as it would be 
great to meet up there.

  After the Flock I would like to organize meeting of us all. I'm not sure 
where IRC/or some other platform and when. Could you reply to me off the list 
with days(ideally between 13-31 of Aug) and time that would best suite you and 
your preferred way of the meeting(IRC, hangouts, jitsi,...). I think that it 
would be best to meet on jitsi or other video chat/meeting platform.

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RN7MWWZR3V2SWAZB3XZ36LPMVZKCPYQH/

Re: Golang SIG for Fedora

[Jakub Cajka]

- Original Message -
> From: "Athos Ribeiro" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, August 2, 2018 11:14:51 PM
> Subject: Re: Golang SIG for Fedora
> 
> On Thu, Aug 02, 2018 at 02:45:54PM -0500, Michael Cronenworth wrote:
> > On 07/27/2018 08:28 AM, Jakub Cajka wrote:
> > >There are few big outstanding issues that needs to be solved that need
> > >more than individual work, most notably the Go packaging guidelines
> > >and tooling. I think that should be one of the first tasks for the
> > >SIG.
> > 
> > I'm not looking to join the SIG, but I will share my experience with golang
> > in Fedora.
> > 
> > It appears that packages are being dumped into Fedora and forgotten about.
> > I'm trying to package "Packer"[1] and ran into multiple dependencies that
> > were committed once and never updated. This has to change.
> 
> In my experience, the tough parts about these dependencies that got
> forgot about are:
> 
> 1) they are only dependencies, nobody uses them for anything else;

Afaik this only reason that we have so many golang-* package they are "only 
de-bundled dependencies" for other golang base packages they are not meant to 
be used as devel packages(for developing application for Fedora). One solution 
to this would be going back to the bundling which is IMHO much worse. For the 
record not all packages are debundled, though. Maybe other solution might be if 
we will be able to drive more people to do the Go packaging, because I don't 
believe that packagers with 100s of packages will baby sit each of them, they 
will thereat them more as cattle only looking at then when it is really 
necessary. Maybe the best solution would be to continue with work that jchaloup 
has started making the Go packaging in Fedora mostly automated.

> 2) many of them are not versioned upstream (we just have references to
> commits)

Afaik also commonly not maintaining API stability...

> 3) different applications that depend on them may need different
> revisions of them.
> 
> while solving 3 is part of our duty as packagers (making sure to port the
> dependencies to use the latest versions of their dependencies), 2 seems
> to be quite common in the golang community...

Hopefully with upstream work on vgo and other dependency managers will be 
improvement for this.

JC

> 
> --
> Athos Ribeiro
> 
> http://www.ime.usp.br/~athoscr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AID5NXKVSVTU55E4GRUK6LE2XZRL5YPL/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ARWI62INSJCGN4LIAI7IR6LL3IV3IMQ3/

Golang SIG for Fedora

[Jakub Cajka]

Hello,

  it seems that lately there has been more people maintaining Go package in the 
Fedora. I would like to propose to join up and form Go SIG so we could better 
co-ordinate and collaborate on the packaging issues and general developer 
experience.

  There are few big outstanding issues that needs to be solved that need more 
than individual work, most notably the Go packaging guidelines and tooling. I 
think that should be one of the first tasks for the SIG.

  To introduce myself. I'm for some while golang (co-)maintainer and recently 
started co-maintaining origin package. I'm mostly interested in the compiler 
and developer experience.

  Please reply if you would like to participate. 

JC

  PS: Also I will be at Flock this year and would like to meet up with anyone 
interested there.
  
  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XVYPQH2WNMT4X3NYIKYPTRFOUITWADC7/

Re: [CoreOS] Starting a Container SIG

[Jakub Cajka]

- Original Message -
> From: "Clement Verna" 
> To: "atomic-devel" , "Development discussions 
> related to Fedora"
> , cor...@lists.fedoraproject.org
> Sent: Wednesday, July 25, 2018 7:09:39 PM
> Subject: [CoreOS] Starting a Container SIG
> 
> Greeting all,
> 
> The container effort in Fedora has until now been looked after by the
> Atomic WG, since this Working Group is now going to focus mostly on
> Fedora CoreOS, I propose to create a new container SIG to regroup
> people interested in the maintenance of application containers in
> Fedora.
> 
> This SIG would look after the container guidelines [0], the container
> review process [1] and also the release process and tooling.
> 
> Please Reply if you're interested with helping out making the
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.
> 
> Regards,
> Clément
> 
> [0] - https://fedoraproject.org/wiki/Container:Guidelines
> [1] - https://fedoraproject.org/wiki/Container:Review_Process

Count me in. I would like to help and contribute especially in areas of 
Multi-Arch, Go and OpenShift Origin.

Also I would like to propose to meet up at this year Flock, if you are coming 
there.

What do you think?

JC

> ___
> CoreOS mailing list -- cor...@lists.fedoraproject.org
> To unsubscribe send an email to coreos-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/message/55QK4AYKBFGLFXCGAVJSXLEVEMC5NJQ2/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E2RG7DGINXXEX4QW6JQJ4PD7NESUXME7/

Re: Mass rebuild, mass Golang packages failures

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, July 17, 2018 2:52:05 PM
> Subject: Re: Mass rebuild, mass Golang packages failures
> 
> On mardi 17 juillet 2018 14:34:49 CEST you wrote:
> > Hello,
> > 
> > 
> > Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the
> > Golang package containing a binary fail because the debuginfo are not
> > generated:
> > 
> > RPM build errors:
> > error: Empty %files file /builddir/build/BUILD/rclone-1.42/
> > debugsourcefiles.list
> > Empty %files file
> > /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list Child return code
> > was: 1
> > 
> >  whereas it was working correctly before.
> > 
> > Has anyone any idea what is causing this and how it can be fixed?
> > 
> > 
> > Best regards,
> > 
> > Robert-André
> 
> The problem seems to be caused by the compressing of debug info:
> https://github.com/golang/go/issues/11799
> 
> Disabling the compression with -ldflags=-compressdwarf=false seems to solve
> the issue.
> 
> I don't know if this should be made default in %gobuild or if we ned to find
> a
> way to extract compressed debuginfo.
> 
For the record.

I have patched Golang to not output compressed DWARF information by default 
until the underlying issue in the rpm/debuginfo is 
resolved(https://bugzilla.redhat.com/show_bug.cgi?id=1602096). You can enable 
it, if you wish to use it outside of RPM, by using the 
-ldflags=-compressdwarf=true.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EEF5P4JS5HE25ISRQWAVIYAVRAB4PTLJ/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NOVNHHLKC3V356MPVF5LSQVZN4GXL4D4/

Re: Mass rebuild, mass Golang packages failures

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org, jca...@redhat.com
> Cc: jchal...@redhat.com
> Sent: Tuesday, July 17, 2018 2:34:49 PM
> Subject: Mass rebuild, mass Golang packages failures
> 
> Hello,
> 
> 
> Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the
> Golang
> package containing a binary fail because the debuginfo are not generated:
> 
> RPM build errors:
> error: Empty %files file /builddir/build/BUILD/rclone-1.42/
> debugsourcefiles.list
> Empty %files file /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list
> Child return code was: 1
> 
>  whereas it was working correctly before.
> 
> Has anyone any idea what is causing this and how it can be fixed?

We have been just discussing this at fedora-devel IRC. It seems that it is most 
probably caused by compress debug information that Go1.11 is now generating and 
rpm/debuginfo not understanding them. Adding -compressdwarf=false to the 
ldflags should workaround this. I will add it in to the gobuild macros so all 
packages that use it will pick it up automatically. ETA tomorrow. 

Thanks to sgallagh, mjw and most notably eclipseo who narrowed that down to the 
debug info compression and came up with the workaround.

JC

> 
> 
> Best regards,
> 
> Robert-André
> 
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SD5VRKOZZJC276PAUIFYB5VE2ZK2B7Q5/

Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Cc: dwa...@redhat.com, mpa...@redhat.com, run...@redhat.com
> Sent: Saturday, June 30, 2018 12:46:28 PM
> Subject: Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a 
> dilemma.
> 
> Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > FWIW, a fun read from the debian pkg-go list about packaging docker
> > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian.ne
> > t/msg00032.html
> 
> And so what? I hit this problem months ago (and I have the github
> tickets to prove it, with the Debian maintainers me-too-ing a few weeks
> later). And some of those have been fixed since thanks to the reporting.
> 
> The problem is not this message, that's upstream software needing
> fixing, we handle tons of those in Fedora all year round, the problem is
> that you seem to find normal *others* identified it, you seem to find
> normal *not* *involving* yourself in the reporting and the fixing, you
> seem to find normal functioning in some sort of fourth dimension where
> FLOSS community fixing and collaborating happens to someone else.
> 
> Go upstream state is a hard problem. But it needs to be solved because
> no matter how you look at it there is a ton of go software that wants to
> integrate with either kubernetes or docker. Stuff that is usually
> *useful* for container users BTW. Stuff *you* could pull on for future
> openshift enhancements if you made a minimum effort to nurture its
> packaging in Fedora.
> 
> Making temporary exceptions for bits of bundling because they're too
> broken to integrate right now is one thing. Passing on entirely and
> letting the whole thing rot for years is something else entirely.
> 
> There is maybe 95% of Go packages that kubernetes need that present no
> technical challenge to package as rpm and use as rpm (some of this code
> has not been changed upstream for years!). The 5% remaining problem
> stuff could be bundled and then chipped at years after year till it's
> not a problem anymore. It *needs* chipping at to improve the codebase
> and the maintainability of it all.
> 
> But you use this 5% as the reason not to play the game at all.
> 
> Why ?

Menpower? Do you know how many active packagers are in Go part of Fedora? In my 
experience there is less than 10, more like 5 or less for like ~600 packages.

For the record what you find as "new and surprising" we(me and jchaloup) have 
discovered roughly over 2y ago and have been working(mostly Jan, guidelines and 
gofed) on resolving it in Fedora in our spare time. Can I read your e-mail in a 
way that you are volunteering to commit for full time ground work on 
de-bundling and stabilizing the Go world(in Fedora)? We will be excited to 
guide you through as anyone else interested. 

I would be really happy to see you all at flock so we can discuss it and work 
on solutions, especially if you are interested in actually working on fixing it 
not only discussing it. I think it would be cool if we would be able to start 
Fedora's Go SIG there and start systematically addressing the issues.

JC

PS: I have opened talk proposal at flock 
https://pagure.io/flock/issue/24(co-speakers are welcomed), but I would love to 
meet there even if it won't make it.

> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LYEGUB45XVQMDKLRYEHOJ3DPO3ULGQ44/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H2AP2TYGN2BTGBV45DU6DJGHYE7LFSW4/

Re: F29 Self Contained Change: Origin 3.10

[Jakub Cajka]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Cc: devel-annou...@lists.fedoraproject.org
> Sent: Wednesday, June 20, 2018 2:05:38 PM
> Subject: Re: F29 Self Contained Change: Origin 3.10
> 
> 
> 
> On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik < jku...@redhat.com > wrote:
> 
> 
> = Proposed Self Contained Change: Origin 3.10 =
> https://fedoraproject.org/wiki/Changes/origin3.10
> 
> 
> Owner(s):
> * Jakub Čajka 
> 
> 
> Rebase of the Openshift Origin package to the latest upstream version,
> along with introduction of necessary infrastructure container images.
> 
> 
> == Detailed description ==
> Rebase of the Origin package to the latest upstream release. To note
> upgrade path from previous version (3.9) will not be covered by this
> change(dnf update origin, will most certainly be unable to cleanly
> update Origin cluster), any one interested in helping out with the
> supportable update path please reach out to the change owner or any
> origin maintainer. Upstream provided update ansible playbooks are
> located at
> https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades
> 
> This sounds like a perfect use-case for a module. If `dnf update` cannot be
> made safe on its own, then it might be best if it wasn't attempted as part
> of the system upgrade, but was instead made into a module stream that users
> could switch to at their convenience.
> 

I think, with my rather limited knowledge of cluster migration, that it 
wouldn't make much difference in regards to the migration. You still need to 
migrate each node do the conversions, etc., but I haven't yet looked at in 
depth. I'm currently more focused on delivering bits that would actually enable 
us to run the cluster(solely on top of Fedora based images). I plan to focus 
more on this topic in F30 when we will have actually something to migrate.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BFRU5A36X64KURR3L6YAPNZS3FYFNLCV/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QGMYZ7SWHRJOQLS7UQM3VS53KO3VF3YW/

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Tuesday, February 6, 2018 7:34:03 PM
> Subject: Re: Proposed Fedora packaging guideline:  More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> Hi Jakub,
> 
> >> And I'm sure any
> >> attempt to strip the WIP bits from my side will be met with energetic
> >> protests.
> 
> > Have you tried that? What make you assume that? I'm sure that if you do it
> > in constructive way, they will be accepted.
> 
> My experience with humans is that they get attached to their bits of text
> even when they have no time to finish them. But yes, I haven't tried, I
> don't want to see a wiki page for a month after writing and formatting and
> revising two separate packaging drafts.
> 
> > I believe that technically exhausting document is needed as Go packaging is
> > far from trivial. Sure it would be great to have
> > (trivial) quick start guide. I think that your proposal fits that bill more
> > than full documentation.
> 
> IMHO that's exactly what FPC expects: a quick start document, not an in-depth
> encyclopædia. In-depth is too hardcore to be validated by domain laymen, is
> useless to onboard new packagers (which is the primary objective of Fedora
> guidelines), is never finished because the state of the art changes, and
> can't be applied to check whether a spec is good or not because in-depth
> concerns *complex* cases where the "right" choice is not obvious, depends on
> many factors that change over time, and usually requires asking the domain
> experts directly.
> 
> So you have the simple common cases, which are sufficient for most packagers,
> and can be addressed by a formal document FPC can review and enforce, and
> "other things" which are valuable but can not ever attain the formalness and
> strictness level expected of Fedora guidelines, require continuous freedom
> to edit, and are hosted in other Fedora wiki pages. At least that's how
> real-life law is written (law text + expert commentaries) and how other
> Fedora packaging SIGs function and got their guidelines approved.
> 
> > They are used primarily to minimize build root size, by reducing the deps
> > size and code size.
> 
> Stripping example material from gopath installation filelists achieves the
> same objective without all the complexity of managing packages that share
> directories Go considers indivisible.

??, I have been talking about tests. From Go perspective source files and test 
source file, testdata are two distinctive sets.
From my POV if your code depends for regular builds on tests code it means that 
there is something horribly wrong with your project(regardless of language 
used).

Docs and examples would be great too, it should be in guidelines that packager 
must use reasonable effort to create subpackages with them.

> 
> >> 7. even core Go people refuse to touch the subject with a 10 foot pole.
> >> Sam
> >> Boyer tried to demo a very small part of what would be necessary this week
> >> end at FOSDEM and this part of his demo *failed*. I don't have the level
> >> of
> >> Go understanding Sam Boyer Has.
> 
> > What has been demoed?? Unfortunately I could not make it there
> 
> Sam Boyer presented the current state of his go dep prototype, and explained
> his design choices (for example no nested projects which means the go import
> path root becomes a core concept and it's useless to invest in splitting
> projects as that usually requires nesting). He ended up stating go dep will
> ignore tests by default, tried to demo optional test handling, and that
> failed. He had another conference the next day I couldn't get to as I was
> stuck in another part of the campus.

Cool, there is recording for anyone interested 
https://fosdem.org/2018/schedule/event/dep/.

> 
> > Have you met with Jan there?
> 
> Unfortunately FOSDEM was its usual crazy stuff with multiple interesting
> conferences at any given time and no hope of being admitted in a room if
> you're late. So I've just been running from conf room to conf room without
> any hope of meeting anyone :(
> 
> > Your packaging proposal seems fairly monolithic and disregarding any prior
> > art, so extensions will be very painful.
> 
> Well, the creation of the proposal was a long suite of extending to cover
> m

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> <packag...@lists.fedoraproject.org>
> Sent: Monday, February 5, 2018 3:27:01 PM
> Subject: Re: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> > Our as Fedora or yours company/org? I believe that your contribution of
> > those in to Fedora will be much
> > appreciated.
> 
> Our was meaning the set of specs we are preparing for inclusion. Can't really
> share them before the macros they depend on are merged in rawhide.
> 
> You can grab most of those from
> https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging
> 
> before I nuke it to launch a new build from scratch (if seems a bit of grpc
> bootstraping failed this run so that's back to build log analysis, add
> constrains, scratch, retry, wait 3 days for the result. I s hate the yum
> version in copr, every time there is a dumb decision to make it will make
> it, it manages to make yum in EL7 look smart)

You have to explicit about the specs, TBH I have had more fun with dnf, when it 
fist came out.

I believe that you can already open pull requests and review requests stating 
the dependency(so it doesn't get merger too soon) as it will take it some time 
to merge and details can get ironed out during merging/review. As IMHO your 
guidelines will require whole distro change/rebuild to make it compliant. I 
feel like you haven't been engaging with current maintainers much.

JC

> 
> > But IMHO even your changes will not change this, if you don't have few
> > dedicated packager around to
> > do all the bidding.
> 
> Sure, the changes will only remove some barriers to new Go packagers, they
> can't replace those packagers, or the people who take care of the baseline
> core.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Monday, February 5, 2018 4:48:31 PM
> Subject: Re: Proposed Fedora packaging guideline:  More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> Hi Jakub
> 
> > I think that it would be best if Nicolas could fold his proposal in to the
> > original draft as
> > optional part for simple library/binary packages.
> 
> Frankly, that's a lot of work and churn, I don't want the new parts to be
> refused because of something in the old parts, and I certainly do not want
> to spend weeks replacing bits only to put them back in and so on while
> people made up their mind on the things they want replaced or not. The new
> parts are pretty much autonomous and complete, they are sufficient to create
> working Fedora Go packages, they are ready for FPC review.
> 
> If someone wants to extract the ready non discussion parts of the old page
> and get them approved I can work with him to merge both elements
> 
> I didn't want to write about the old page, but since you put it on the table.
> 
> It is full of digressions and elements of no evident applied value while
> packaging Go software. It's not an operational "how to do stuff" document
> it's a "here are various things you may like to know about Go that may or
> may not help you create Fedora Go packages, if they do not help you forget
> about it and run gofed". There are too many WIP non operational bits in the
> old pages to allow merging while in an approval process. And I'm sure any
> attempt to strip the WIP bits from my side will be met with energetic
> protests.

Have you tried that? What make you assume that? I'm sure that if you do it in 
constructive way, they will be accepted.

> 
> People, if you want that page to be ever approved by FPC make it more focused
> and accurate. Remove anything that does not explain to a Fedora Go packager
> how to write a Fedora Go spec file and what to ask upstream Go projects in a
> Fedora packager role. And make sure what remains is succinct, easy to read,
> and applicable without undocumented holes or gofed magic.

I believe that technically exhausting document is needed as Go packaging is far 
from trivial. Sure it would be great to have (trivial) quick start guide. I 
think that your proposal fits that bill more than full documentation.

> 
> I know that's a lot of non-fun work. I did this work on the new page. I don't
> particularly *like* writing documentation. For every line I put in the new
> page, I had to ask myself "is the value to the Fedora packager sufficient to
> justify the time spend writing the text, formatting it, linking in the right
> place, proofing the result". I didn't put in stuff I could not justify
> cleaning up myself. If it was too much work to document it was either of
> insufficient value or better automated rather than explained in a manual
> process.
> 
> Any part of the text that can not be finished or serves another role has no
> place in a guideline submitted to FPC. It should be nuked or moved to a
> separate wiki page. All the half-finished and non operational stuff in there
> is the reason the draft has been stuck in pre-approval stage for four years.
> Just put yourself in FPC's place, its mission is to confirm a guideline is
> ready to be used by the average Fedora packager, not to produce it from
> half-finished half-related messy notes of the domain experts.

I believe I can see myself in their shoes(sure not 100% accurately) and I don't 
see anything that you are describing from their POV, it would be good to have 
the guidelines sooner, but I will have, as you, rather something complete than 
something half baked and semi broken. Please note that they are WIP and 
everybody is welcomed to contribute in constructive way. I don't think that 
there is any request for FPC to create the guidelines on their own and honestly 
it would rather bad idea IMHO.

> 
> > As his proposal doesn't cover at least two major use cases, i.e. separate
> > packaging of tests(they
> > have no place in devel package as they artificially inflate build root
> > size)
> 
> At this point of time my mind is pretty much set. I won't do separate
> packaging of tests because:
> 1. that raises complex dependency handling questions
> 2. the average Go project test code is full of crufty junk
> 3. the average Go test depends on assets not tracked 

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Monday, February 5, 2018 12:16:14 PM
> Subject: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> > I think one of the main responsibilities of Fedora packager is to work with
> > upstreams, help them
> > mature and generally improve their projects.
> 
> Sure but expecting everything to be perfect and consistent before shipping
> anything just DOES NOT WORK. Reality is not black and white, it's messy with
> shades of gray
> 
> Even the C/C++ guys do not manage to ship a compat-free package ecosystem,
> and their projects had a few more decades than Go projects to mature, and
> rpm was pretty much built around C/C++ expectations.
> 
> Compat packages are a fact of life in any large software ecosystem, where you
> can't achieve perfect cohesion. Go is getting *very* large. It needs compat
> packages. That does not mean there will be hundreds of them because,
> creating packages is *work*, that does not need they will need maintaining
> for years, because the aim of each compat package is to get obsoleted as
> fast as possible, but there will always be some of them at any given time.
> We are not building a cathedral. Bazaars are messy when full of life.
> 
> > Do you have any evidence supporting this claim? From my point of view Jan
> > and other packages has
> > been spending lot of time on on boarding packagers and working on tooling.
> 
> No one (and certainly not me) is accusing you or Jan not to spend a crazy
> amount of time and energy trying to make things work. But you did not
> achieve a satisfactory Go state in Fedora, read again what Owen wrote, I
> didn't put any word in his mouth, even though I could have written pretty
> much the same message a few months ago.
> 
> Again, no one (and certainly not me) disputes your level of dedication to the
> "cause". You just made some choices in the past (trying to avoid working
> within rpm via godep, refusing to include different states of the same Go
> code in the distro when major Go apps *disagree* on the correct state to
> include) that didn't work out in practice, with the hindsight of several
> years of Fedora Go packaging and the Go package state achieved in Fedora
> after those years.
> 
> It's time to adjust those choices a bit.
> 
> > From my perspective distribution will end up with crazy amount of
> > bitrotting, backport, constant
> > attention requiring package crud..., IMHO basically same as now, apart of
> > it we will have few 1000s
> > of Go based packages with compat names nobody cares about, instead of
> > current 500 or so packages.
> 
> Fedora has lots of Go packages no one cares about because they do not permit
> building the apps people *do* care about.
> 
> Building the apps people care about requires a more aggressive update policy,
> and accepting people will work in parallel on apps, that demand different
> code states, of common dependencies. And there are not so many of those, I
> count 18 of them in our repo out of 476 Go packages, even though the work is
> not completely finished, and finalizing the build of complex tip apps is
> almost certain to increase the proportion a little. That's awfully *good*
> and *nice* given the "no Go API compatibility" scarecrows people like to
> invoke.
> 
> You won't *ever* attract a large pool of packagers, to work on a package
> baseline, that will eventually in some years permit building apps, but never
> this year, because upstream state is not conflict and compat-free yet.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> 

Our as Fedora or yours company/org? I believe that your contribution of those 
in to Fedora will be much appreciated.
But IMHO even your changes will not change this, if you don't have few 
dedicated packager around to do all the bidding.

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> 
> Sent: Friday, February 2, 2018 4:54:10 PM
> Subject: Re: Proposed Fedora packaging guideline:  More Go packaging
> 
> On mardi 30 janvier 2018 16:11:49 CET nicolas.mail...@laposte.net wrote:
> > Hi,
> > 
> > Now the technical PR is submitted
> > https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
> > 
> > and waiting for action from the go-srpm-macros maintainers, I took (quite a
> > long) time to refresh and flesh out the corresponding packaging guidelines
> > proposal. It should be fairly complete now:
>  
> > https://fedoraproject.org/wiki/More_Go_packaging
> > 
> > I'd appreciate review to check if I have forgotten an important case, if
> > people understand the text, if they have enhancements or corrections to
> > propose, and so on.
>  
> > Then I will push it FPC side again.
> > 
> > Actual practice should be fairly simple and self-explanatory, the proposal
> > length can be scary but that's because it documents all kinds of corner
> > cases that required digging through specs and mailing lists to find
> > resolution examples before. The basic Go packaging skeleton will be
> > sufficient is most cases without requiring to read any documentation.
>  
> > Regards,
> > 
> > --
> > Nicolas Mailhot
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Hello Nicolas,
> 
> Could you add two full examples, one for binary package, one for library
> package, like in https://fedoraproject.org/wiki/PackagingDrafts/
> Go#Sample_RPM_Spec
> 
> Putting it all together (https://fedoraproject.org/wiki/
> More_Go_packaging#Putting_it_all_together) is nice but don't understand if it
> is for a binary or a library.
> 
> Also, is there any plan to update Gofed with these new guidelines? If it's
> not
> automated like today, we will lose time instead of gaining some in the end.
> 
> Best regards,
> 
> Robert-André
> 

I think that it would be best if Nicolas could fold his proposal in to the 
original draft as optional part for simple library/binary packages.

As his proposal doesn't cover at least two major use cases, i.e. separate 
packaging of tests(they have no place in devel package as they artificially 
inflate build root size) and shipping pre-built shared libraries.

Just my opinion,

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Saturday, February 3, 2018 4:27:36 PM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> De: "Jakub Cajka"
> 
> Hi Jakub
> 
> > I'm strongly against general unrestricted practice of compat packages as
> > proposed. If you need compat package you
> > need to work with usptreams on stabilizing the API/project, fork it, or
> > just use COPR as your projects(or its
> > dependencies) are not yet mature enough for Fedora.
> 
> I appreciate the sentiment, and I quite hate compat packages, but the
> restrictions you want did not work in practice for Fedora.
> 
> Making compat package creation hard does not result in faster fixing to use
> new code. What it actually does is to block the packaging of all the
> projects that need a more recent package state, because packagers that need
> the old state for one of their packages, will drag their feet on updating
> common dependencies till the code of their packages is fixed upstream, or
> they have the time to fix it themselves.
> 

I think one of the main responsibilities of Fedora packager is to work with 
upstreams, help them mature and generally improve their projects.

> And blocking packaging of new part means you do not get the new packagers
> that would join because they're interested in the new parts, and would
> contribute to the maintenance of common deps (not all of which need
> compat-ing), and would relieve part of the pressure on the existing
> packagers, that prevents them from working as much a they'd like to on
> updating their packages. It's a death spiral. It results in a massively
> obsolete Go package baselines, full of holes, because all the energy is
> poured in making existing stuff work, at the expense of onboarding new
> packages and packagers.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 

Do you have any evidence supporting this claim? From my point of view Jan and 
other packages has been spending lot of time on on boarding packagers and 
working on tooling.
From my perspective distribution will end up with crazy amount of bitrotting, 
backport, constant attention requiring package crud..., IMHO basically same as 
now, apart of it we will have few 1000s of Go based packages with compat names 
nobody cares about, instead of current 500 or so packages.

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Thursday, February 1, 2018 4:24:52 PM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> De: "Jakub Cajka"
> 
> >> Filling upstream holes is pretty much the definition of an
> >> integrator/distributor role. In Go they are particularly numerous and
> >> deep,
> >> but Fedora users do want their docker and kubernetes (and Kubernetes, BTW,
> >> is astonishingly free of the problems that plague many Go projects,
> >> proving
> >> it *is* possible to do good release engineering in Go).
> 
> > ??
> 
> Just sending some kuddos Kubernetes-side. All the Kubernetes parts we had to
> work with so far were astonishingly free of API breakage and dependency
> cycles because Kubernetes people chose their deps carefully and do version
> their code states. It was a vacation from packaging other Go code.

Yes kubernetes is kind of better than most projects, but IMHO still uses lots 
of not so good practices, although getting bit better over the years.

> 
> > > Pain will not be eased in any significant way as you will still have to
> > > carefully evaluate every
> > > change so you don't break any dependent package.
> > 
> >> Pain *will* be eased in a significant way because we will have the tooling
> >> to
> >> detect breakage automatically, and because fixes once they're done will be
> >> packaged and shared.
> 
> > Your proposal doesn't provide this kind of tooling, if I'm not mistaken.
> 
> Not directly. It does provide the means to easily rev a spec to a new code
> state (version tag or commit), and it makes deps systematic (so Fedora
> tooling can accurately detect what is likely to be impacted by a change).
> Together, those open the way to use generic Fedora testing tools to automate
> build tests.

It makes it bit easier in some cases, but I wouldn't call it and revolution(as 
you are trying to sell it) rather than evolution(and omission of some currently 
mentioned parts), building on top of current practice.

> 
> >> If it's minor let's do it. I'm quite sure you will be pleasantly surprised
> >> by
> >> the level of pain those minor changes remove.
> 
> > ?? I'm in no way opposing your proposal per se.
> 
> Thank you
> 
> >> Fedora can detect the breakage which is the first step to fix it. It does
> >> not
> >> take an army of Go experts, just unbundled packages that can be rebuilt
> >> automatically to identify incompatibilities. Go experts are better
> >> employed
> >> working on fixes than doing rebuild checks that can be automated.
> 
> > Rebuilds could be automated, analysis of them not easily.
> 
> Sure, but at that point
> 1. you know if the new API is compatible or not with other packages
> 2. you've saved human packagers the time and effort to do the same rebuild
> check manually
> 
> So that's still a net win, no ?

No really, or not much, until you determine why the builds have failed(I can 
rebuild of whole distro each day, still I don't have enough spare time to 
determine and fix all FTBFS issues). You still have to have someone who would 
analyze those failures.

> 
> >> And nothing stops you for continuing to use those. Except, the golden test
> >> will always be to actually try to build the code, which is something that
> >> can be automated reliably once the dependencies exported to Fedora tools
> >> are
> >> themselves complete and reliable, and Go packages are exported as rpm
> >> packages, not hidden in private vendor trees.
> 
> > ?? I bit don't understand you. If you can, please help Jan to improve them.
> 
> What I meant is that:
> 1. there are many ways to try to divine if a code state will build, but the
> final arbiter is the Go compiler
> 2. to use Fedora-wide QA tools, code objects need to be exported as packages.
> Every missing test dependency, which is not packaged as a separate Go rpm,
> is something Fedora QA won't be able to run.

I think that I'm still missing your point. Of course you need to package all 
your dependencies.

> 
> >> When you do not unbundle you are still shipping the vendored code, you are
> >> still responsible for its bugs (security  or not). Compat packages do not
> &

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Thursday, February 1, 2018 2:51:13 PM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> De: "Jakub Cajka"
> 
> Hi Jakub,
> 
> > It depends (as everything) on available manpower, if you are willing to own
> > your dependencies
> > you can package anything and everything debundled.
> 
> Sure, but available manpower depends on how high the bar you put for people
> wanting to join, and right now this bar is pretty high.
> 
> > On contrary, to this state you dislike(or seems to) Fedora got because of
> > effort of many to de
> > bundle Go based projects.
> 
> I'm *not* disparaging the past efforts of many. They did a lot of good.
> Unfortunately, the result still falls short of the mark. The baseline is not
> complete enough, the baseline is old and aging fast, would-be Go packagers
> like Owen are ready to give up when they start getting an idea of the Go
> state in Fedora.
> 
> It's time to invest in tooling and simplification so the few Go Fedora
> packagers there is, can do more with less, so casual Go packagers can
> contribute their little bit instead of being repulsed by complexity that can
> be avoided and factored out, so people already familiar with Fedora
> packaging can package the Go bits they need without needing a lengthy
> formation on Go specifics.
> 
> There *are* lots of people that would like to do Go packaging. Many Go
> software projects currently make headlines. That there are so few Go
> packagers in Fedora, at the time Go is in the limelight, is a pretty good
> indicator we are making it too hard.
> 
> > I don't see way how it makes it less painful(you have still the whole
> > distro issue). It makes specs
> > more abstract and streamlined when it works, but more opaque and hard to
> > read when its not(and you
> > have to debug some arcane srpm/lua macros).
> 
> It makes it less painful because there is no package-specific magic in each
> and every Go spec file.
> 
> You do not need to debug code in each spec because code that already just
> works for hundreds of  packages is unlikely to not work on the next spec
> file.
> 
> You do not need to comb each and every line of a Go spec file wondering if
> the line is cut and pasting of a common template (multiply by all past
> revisions of common templates) or if it is package-specific. The common
> parts are in common macros not spread right and left.
> 
> You do not need to worry wether common code is complete or not because
> factoring out common code removes the temptation to document 90% of what's
> needed, leaving others to fill in the missing 10%. 10% amounts to an
> astonishing level of work when you multiply it by the number of Go packagers
> and the number of Go packages we would ideally need.
> 
> Plus, when you do find a bug in common code, the fix is shared with the whole
> distribution, not hidden in a single spec file.
> 
> That's what successful factoring of common code earns you.
> 
> And given I have more than 470 Go spec files that just work with the proposed
> macros with no special package-specific adjustment needed, and most time I
> compare one of those to the Fedora equivalent I'm executing more unit tests
> and building more binaries, with drastically shorter spec code, I'm pretty
> sure the factoring out *is* successful.
> 
> >> This step is going to be painful I'm afraid, Fedora dug itself a
> >> deep hole, leaving it is going to be hard.
> 
> > On contrary Fedora is trying to fill the hole that upstream Go projects dug
> > them selves in to.
> 
> Filling upstream holes is pretty much the definition of an
> integrator/distributor role. In Go they are particularly numerous and deep,
> but Fedora users do want their docker and kubernetes (and Kubernetes, BTW,
> is astonishingly free of the problems that plague many Go projects, proving
> it *is* possible to do good release engineering in Go).

??

> 
> Fedora did dug itself a hole by trying the bundling shortcut around EL7 time.
> Where are the EL7 Go packages? Why are Fedora Atomic people not spearheading
> Go packaging in Fedora? Waiting for bundling to be solved upstream-side made
> Fedora worse not better.

I'm not sure that Fedora. Go ask them don't ask me or other regular Fedora 
maintainers. 

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> , "Discussion of RPM packaging
> standards and practices for Fedora" 
> Sent: Thursday, February 1, 2018 11:21:59 AM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Owen Taylor"
> 
> Hi Owen,
> 
> > Is there a guide for Fedora packagers about how to handle unbundling for
> > golang packages? The draft guidelines don't seem to go into any details.
> 
> I don't think there is, nor that it is necessarily needed. The posted
> guidelines should be sufficient technically, there are no magic I know of I
> didn't document, the rest is just a lot of work (but see ↓)
> 
> > I've looked at packaging a few golang packages unbundled, and have
> > immediately run into:
> >
> > A) lots of unpackaged dependencies
> > B) dependencies that are packaged in Fedora with different, often much
> > older versions
> 
> Yes the state of Go packages in Fedora is pretty sad right now. I wouldn't
> expect anyone to be able to package anything but the most trivial app in
> unbundled mode. Too many common parts are missing, when they are not missing
> they are too old, trying to update an existing Go package is an exercise in
> frustration (too much package-specific shell code, that is difficult to
> understand and does not really work with new code versions), and trying to
> update or add missing parts just reveals more breakage and work to be done.

It depends (as everything) on available manpower, if you are willing to own 
your dependencies you can package anything and everything debundled.

> 
> However, accepting to package complex Go apps in bundled mode is how Fedora
> got to this state in the first place. In plain speak, bundling (vendoring in
> Go linguo) just does not scale. You need an awful lot of manpower to audit
> the hundreds of other projects each app bundles, bundling removes all the
> package tooling that may help you to do so, and the result is not shared
> with any other package, or with other versions of the same package, so you
> get zero positive network effects. Worse, big bundled apps that do not
> actually try to work in unbundled mode, do not actually test the code they
> export (they are bundling, remember) so the result is toxic to small Go
> packages that try to work with them.

On contrary, to this state you dislike(or seems to) Fedora got because of 
effort of many to de-bundle Go based projects.

> 
> So bundling parts is a direct road to bundling everything, bundling
> everything is a direct road to bundling everything blindly, bundling
> everything blindly is error-prone and dangerous (because upstreams are only
> human and do make lots of mistakes), and pretty much removes any value
> Fedora can add to end users, to other parts of Fedora that would like to
> integrate with Go software, or to the upstream projects themselves (no
> Fedora QA, no stream of Fedora-originated fixes, no Fedora pressure to
> stabilize parts when upstream is lost in tunnel effect mode and does not
> realize that it is wasting everyone's time starting with its own).
> 
> Therefore, trying to get all this it a better state, requires the following
> steps IMHO:
> 
> 1. completely refactor our Go packaging style it's less painful to update Go
> packages and they do not need a packager with deep knowledge of
> package-specific shell glue. That takes documentation, and factoring out
> common Go packaging functions in shared rpm code (macros and autodeps) →
> that's what I posted

I don't see way how it makes it less painful(you have still the whole distro 
issue). It makes specs more abstract and streamlined when it works, but more 
opaque and hard to read when its not(and you have to debug some arcane srpm/lua 
macros).

> 
> 2. using the new documentation and tooling to clean up years of Fedora
> technical debt, and create a new set of up-to-date Go packages that can
> serve as new baseline → I have hundreds of specs that I'm waiting for step 1
> to complete to submit. They won't constitute a full baseline by themselves,
> they're not all 100% done, it's too much work to do alone but working with
> others requires the common macros and documentation to be merged and
> adopted. This step is going to be painful I'm afraid, Fedora dug itself a
> deep hole, leaving it is going to be hard.

On contrary Fedora is trying to fill the hole that upstream Go projects dug 
them selves in to. IMNHO Go have traded any subjectively perceived "RPM/deb 
hell" for even deeper levels of "Go (vendor) hell".

> 
> 3. hopefully, the result will be streamlined enough it won't be too painful
> to keep up to date, having an up to date baseline will help attract new Go
> packagers like you, everyone will benefit and be 

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Owen Taylor" 
> To: "Development discussions related to Fedora" 
> 
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> 
> Sent: Wednesday, January 31, 2018 6:50:21 PM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> Hi Nicolas,
> 
> Is there a guide for Fedora packagers about how to handle unbundling for
> golang packages? The draft guidelines don't seem to go into any details.
> I've looked at packaging a few golang packages unbundled, and have
> immediately run into:
> 
> A) lots of unpackaged dependencies
> B) dependencies that are packaged in Fedora with different, often much older
> versions
> 
> A) is a pretty known quantity for any type of package, but I found B) more
> intimidating. It seems like to package the new package, I have to get the
> maintainer of the library to upgrade the version, and someone needs to
> rebuild everything that depends on the rebuilt library and test that the
> rebuilt packages work.
> 
> Some tutorial showing a practical example of packaging a golang package for
> the first time I think would be very helpful.
> 
> Owen
> 

Unfortunately this is how the situation stand thanks to the wide spread use of 
vendoring and generally no release and API stability in Go projects. You have 
to package all not packaged deps and work with other maintainers(which mostly 
means with Jan Chaloupka, cc'ed) to get other already packaged deps to commonly 
acceptable version/commit level, although it might not be even possible thanks 
to API breaks between commits. So you have to stick to bundling in some cases, 
if you really want to package that project.

JC

> 
> On Wed, Jan 31, 2018 at 5:30 AM, < nicolas.mail...@laposte.net > wrote:
> 
> 
> >De: "Neal Gompa"
> 
> > The only thing I see that might be missing is autogenerating
> > bundled(golang()) Provides when a vendor tree exists (with the
> > appropriate automatic filters on Requires).
> 
> I had though a little about doing it but first, as many Go elements,
> vendoring relies on conventions not standards. The nasty thing about
> conventions is that they are not applied 100% the same way by everyone,
> making automation a PITA. And second interactions with autodeps can be
> nasty: you can filter out provides, but do you filter out requires? What
> about all the junk code many projects ship as testing and examples and which
> is vendored with the rest?
> 
> I don't say it can't be done, or that it would be difficult to do once the
> rest is merged, but I'll live it to someone that absolutely want to ship a
> Go package with vendored parts.
> 
> Right now we sidestep the issue in our packages by rm -fr ing anything that
> looks like vendored code in %prep. Unbundling takes time but it has a
> positive cumulative effect: the more you unbundle the less you need to worry
> about in other packages with the same requirements. And unbundling reveals
> code/legal problems that it would take about as much work to solve by
> auditing the vendored code manually.
> 
> Regards,
> 
> --
> Nicolas mAilhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 23, 2018 7:45:06 PM
> Subject: Re:  Re: Proposed Fedora packaging guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Mátyás Selmeci"
> 
> Hi,
> 
> > This looks pretty cool!
> 
> Thanks for the feedback!
> 
> > One thing I notice in the limitations section of
> > your draft is a lot of "we can't do XXX due to lack of release
> > discipline..."
> 
> > Do you have any recommendations for Go programmers on how to structure
> > their software so that it is easy to package?
> 
> If there is an interest I can add a section on how to make a Go project
> easier to package, sure.
> 
> It won't be earth-shattering, just the Go declination of basic common sense
> rules that are needed in any coding language, that many Go projects already
> apply (unfortunately not all of them):
> 
> — do not change your import path every other month
> — do not make your code accessible through multiple import paths
> – only use smallcaps in your import path (I know some systems are case
> insensitive. Many others are NOT)
> – communicate clearly the canonical import path of the project at the top of
> your README.md
> — if you absolutely need to change your import path fix your code to use the
> new import path do not rely on http redirections
> – that includes testing and example code
> — do not add a .git suffix to your import path
> 
> — use _testdata for all the material needed by unit test

- make sure that all tests and exclusive test dependencies are really only in 
_test.go files

> – put your example code in _examples (with subdirectories if you ship several
> examples). Do not use creative unusual names such as tutorial.
> – do not pepper your subdirectories with .md files. Keep documentation in the
> project root or in a docs root subdirectory if there is too much of it
> — add a one-line summary and a least a § describing what your project does at
> the top of your README.md
> 
> — choose licenses already vetted by Fedora or Debian
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
> – add a licensing file named LICENSE
> — use unmodified plaintext canonical licensing texts, that state the LICENSE
> name at the top of the file
> — if you absolutely want to add an extension to make Windows happy, use
> LICENSE.txt
> — if you absolutely want to name your licensing file something else, please
> do not use something.md
> — do not hide your licensing terms in README.md, do not refer to a license by
> name without providing its text
> 
> – do releases
> — do releases, even for minor fixes. If you haven't felt the need to touch a
> project for months its latest state should be released!
> — do releases, even for projects that can only be called through another
> project. Do not rely on this other project to set code state through
> vendoring (that's easy to do, just propagate the tip project version to the
> ancillary projects at release time, like kubernetes does)
> – use semver for your releases https://semver.org/ Distributors and godep
> will thank you
> – if your project is in git, use a different branch for every major version
> of your project
> — if your project is in git, tag your release x.y.z as x.y.z, or vx.y.z,
> never as vx.y.zprettybeta. Versions and version tags are not the right place
> to document a project maturity.
> — numbers are cheap, never reuse the same number for a pre-release and a
> final release, increase the minor version!
> – please version your import paths with each major release (gopkg.in is good
> for that)

- ideally do major releases in separate branches, so you can do minor 
fixes/releases easily even for older major releases(look at GC) 
- do release whenever you alter your API, extending it, modifying it, removing 
some and document it in the release notes

> 
> – use releases of the projects you depend on
> — never depend on a project that already depends on you (otherwise software
> dependencies stop being a nice directed acyclic graph and you get into
> dependency loop hell. That's a nasic software engineering golden rule, not
> respecting it will bite you sooner or later with or without linux distros,
> despite vendoring)
> – if for some reason, one of the projects you depend on does not release,
> please ask nicely it to do so
> – if for some reason you need a code state in tip which is not in a release,
> please inform the origin you'd like it to do a release, and switch to this
> release as soon as it is available
> – never depend on a commit state somewhere between two releases
> — document the major versions of the stuff you depend on somewhere easy to
> find. If a major version is only usable past as specific minor version,
> document it
> – add a unit test that detects if the project you depend on is missing the
> part that requires being 

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Jason L Tibbitts III" 
> To: "nicolas mailhot" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" ,
> "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Sent: Tuesday, January 23, 2018 6:00:24 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
> 
> I wish this message wasn't crossposted everywhere, but I don't want to
> lose any discussion by trimming the CC list.  Sorry if replies generate
> bounces for some.
> 
> > "nm" == nicolas mailhot  writes:
> 
> nm> And the forge macros are now available since
> nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
> nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> 
> Please don't forget to let me know when it's time to start thinking
> about pushing this down to F27.  And maybe F26.  And as far as I can
> tell it should work with only minor modification in EPEL7 (via
> epel-rpm-macros).  I don't know about EPEL6, but we really should look
> at it given some of the other discussions about specfile compatibility.
> Some packagers wouldn't ever use it if it doesn't work everywhere.
> 

I think that it would be great to land it also in the EPEL6/7.

JC


> Finally, we should also talk about whether there is any integration or
> automation possible between fedpkg and specfiles configured with these
> macros.
> 
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: "Jason L Tibbitts III" 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" ,
> "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Sent: Tuesday, January 23, 2018 9:28:15 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jason L Tibbitts III"
> 
> > "nm" == nicolas mailhot  writes:
> 
> >nm> And the forge macros are now available since
> >nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
> >nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> 
> > Please don't forget to let me know when it's time to start thinking
> > about pushing this down to F27.  And maybe F26.  And as far as I can
> > tell it should work with only minor modification in EPEL7 (via
> > epel-rpm-macros).
> 
> I don't know about EPEL6, but we use it as-is in EL7 and it works just as
> well (except maybe for the %autosetup bits but IIRC that's autosetup which
> is broken in EL7). In fact it has probably been used more heavily in EL7
> than in fedora-devel so far. Maybe it also works in EPEL 6 but I've never
> tried it. I guess it depends mostly on the level of lua support in EL6 rpm
> and rpm-related tools now the forge macro code is lua only. I'm pretty sure
> many of the problems in the early versions of the macro were due to non-lua
> code and its interactions with lua code once the lua-ification started.
> 
> It's a good idea to let people play with it in fedora-devel maybe a month, in
> case I missed something, but from a technical POW I'm prety sure it could be
> merged up to EL7 now. I'll submit fedora-devel specific tweaks later (just
> like I submitted bitkeeper.org support today), right now the code is
> distro-agnostic. For my part I doubt I'll ever use it in EL6 since I did it
> for Go and the EL6 Go stack is really too old for a merge to be interesting.
> Anyway I'll certainly let you know when I feel the time is right (but do not
> block on me!)

If we are talking about EPEL6 stack, it is fairly fresh(1.9.2) and stable(it 
will be on 1.9 for whole of its upstream support), although Go packaging macros 
are missing.

JC

> 
> > Finally, we should also talk about whether there is any integration or
> > automation possible between fedpkg and specfiles configured with these
> > macros.
> 
> I'm afraid my knowledge of recent fedpkg enhancements is too sparse to be of
> any use there. Though I'm not opposed to the idea at all.
> 
> Thanks again!
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Marcin Dulak" 
> To: "Discussion of RPM packaging standards and practices for Fedora" 
> 
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" 
> Sent: Monday, January 22, 2018 4:04:19 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More 
> Go packaging
> 
> 
> 
> On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa < ngomp...@gmail.com > wrote:
> 
> 
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> < dridi.boukelmo...@gmail.com > wrote:
> >> I really do like this. There are only two issues I have with it:
> >> 
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (snapd) is not, intentionally so. I
> >> don't want to change this.
> >> 
> >> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> >> people who release Go code as tarballs (it's rare, but it happens).
> >> How do you deal with that?
> > 
> > By not using the macros for packages not fitting the model?
> > 
> 
> The issue is that the new Go macros are tightly wound into the forge
> macros. I just want to be sure that we can leverage things like the
> dependency generators without all the other stuff.
> 
> > I think this is very helpful especially when it's the common practice,
> > and I certainly won't blame anyone doing proper releases and not
> > just a git tag with github releases notes ;)
> > 
> > Regarding naming, I think python packages must be prefixed with
> > python[23]- and can Provides: the upstream project name.
> 
> I'm not sure if this matters in this discussion but an example Python3 part
> of a spec file https://fedoraproject.org/wiki/Packaging:Python
> to accommodate also EPEL (which on CentOS7 prefixes Python3 packages with
> python34 and not python3) would look like:
> 
> %package -n python%{python3_pkgversion}-%{pname}
> %{?python_provide:%python_provide python%{python3_pkgversion}-%{pname}}
> 
> Macin
> 

Hopefully something like this will never happen as generally I'm strongly 
against shipping multiple versions(of one implementation) of Go concurrently.

JC

> 
> On the
> > other hand we have packages like docker that are clearly named
> > after upstream's name, so I don't think that would be a problem for
> > snapd. (and maybe an exception needs to be granted?)
> > 
> 
> This rule only applies to Python packages that have modules that are
> designed to be imported by other Python code. Otherwise, this is not
> necessary.
> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Golang 1.10a

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: "Jakub Cajka" <jca...@redhat.com>
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" <devel@lists.fedoraproject.org>
> Sent: Monday, January 15, 2018 2:22:26 PM
> Subject: Re: F28 System Wide Change: Golang 1.10a
> 
> Hi,
> 
> So, to be more scientific, I did a complete rebuild from scratch of my Go
> spec stash in rawhide, both with Go 1.10 and forcing the previous Go 1.9.2
> (about 300 packages, some of which are not supposed to build yet because I
> still need to finish the unbundling and bootstraping of docker in addition
> to consul, etcd, cobra and runc)
> 
> I have 58 more packages failing with Go 1.10 (though some are probably
> fallouts that depend on a packages Go 1.10 does not like). Starting with
> Google’s own golang.og/x/debug!
> 
> Maybe Go 1.10 is not ready for use yet?

Have you investigated the build failures to have such strong claim?

I'm finishing going through distro wide rebuild(all ~500 packages) and roughly 
74 packages are failing to build. Nearly all build failures are caused by 
errors(inefficiencies) in the packages code or stale/inactive packagers, with 
no direct  relation to the go compiler itself. I see less than 1% of packages 
that look like candidates for golang bugs.

I will post results when I finish(in ~1-2 days).

JC

> 
> Build logs of both runs by PM, they take around 100 MiB each uncompressed
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Golang 1.10a

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org, "Jakub Cajka" <jca...@redhat.com>, 
> "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Friday, January 12, 2018 4:32:22 PM
> Subject: Re: F28 System Wide Change: Golang 1.10a
> 
> Hi,
> 
> With the new Go 1.10 I get
> 
> + echo
> /usr/share/gocode/src/github.com/hashicorp/go-discover/cmd/discover/main.go
> + install -m 0755 -vd
> /builddir/build/BUILDROOT/golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64/usr/bin
> install: creating directory
> '/builddir/build/BUILDROOT/golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64/usr/bin'
> + install -m 0755 -vp _bin/discover
> /builddir/build/BUILDROOT/golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64/usr/bin/
> '_bin/discover' ->
> '/builddir/build/BUILDROOT/golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64/usr/bin/discover'
> + /usr/lib/rpm/find-debuginfo.sh -j4 --strict-build-id -m -i --build-id-seed
> 0-0.5.0.20180108git7642001.fc28.llt --unique-debug-suffix
> -0-0.5.0.20180108git7642001.fc28.llt.x86_64 --unique-debug-src-base
> golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64
> --run-dwz --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
> debugsourcefiles.list
> /builddir/build/BUILD/go-discover-7642001b443a3723e2aba277054f16d1df172d97
> extracting debug info from
> /builddir/build/BUILDROOT/golang-github-hashicorp-discover-0-0.5.0.20180108git7642001.fc28.llt.x86_64/usr/bin/discover
> dwz: dwz.c:8790: write_die: Assertion `refd != NULL' failed.
> /usr/lib/rpm/find-debuginfo.sh: line 518:  1870 Aborted (core
> dumped) dwz $dwz_opts ${dwz_files[@]}
> /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 1 CRC32s did match.
> 
> 
> in golang-github-hashicorp-discover
> 
> Any idea if it's due to Go 1.10 or another fedora-devel change?
> 
> Regards,
> 
> --
> Nicolas Mailhot
> 

I would suspect debug info extraction based on the log, turning off debug 
package should workaround the issue. Other question if debug info extraction 
fails due to bug in it or if it is broken by broken debug info in golang 
binaries. I haven't stumbled on this while rebuilding distro with 1.10 
beta1(does the build pass in f27?), this package is not on the list of failed 
builds(still processing them).

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Golang update

[Jakub Cajka]

Hello,

  I have just submitted bodhi update for CVE-2017-15041 and CVE-2017-15042, 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f7e4cbd529. If you 
maintain any package or application using "net/smtp" stdlib package, rebuild of 
your package/application is strongly recommended using the fixed version of 
golang. 

  I plan, after this update hits stable, to update the golang package to 
upstream version go1.9(.1)(or any other point release available at that time). 
If you have any concerns please rise them now.

  Testing and karma is much appreciated,

JC
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Any plans for completing the go 1.9 rebase (to stable 1.9)?

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, October 3, 2017 11:41:09 AM
> Subject: Re: Any plans for completing the go 1.9 rebase (to stable 1.9)?
> 
> Hi,
> 
> BTW I have a set of Go packages I was preparing for inclusion that build fine
> with Go 1.8 in Epel 7 but not with Go 1.9 in rawhide.
> 
> Is there a way to check if it's a problem with the future Go 1.9 toolchain or
> a problem in the upstream code? I haven't have the time to investigate yet.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

It could be literaly anything as EPEL(read also as RHEL 7) and 
Fedora(27/Rawhide) are quite different distributions(looking at packages 
available and their versions).
If you can share build output (and spec file), we should be able to tell more. 
From big GC changes(that should be observable at build time) only parallel 
compilation pops on my mind as significant change between 1.8 and 1.9, apart of 
move to Power8+ as minimum supported(more at https://tip.golang.org/doc/go1.9), 
but it shouldn't have significant side effects.

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Any plans for completing the go 1.9 rebase (to stable 1.9)?

[Jakub Cajka]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, September 13, 2017 8:29:24 PM
> Subject: Any plans for completing the go 1.9 rebase (to stable 1.9)?
> 
> According to the Change for F27 [0], all golang packages have been rebuilt
> against golang 1.9beta2. In the meantime, go 1.9 stable has been released
> upstream (Aug. 24, 2017) [1].
> 
> I suspect that some of the issues I am having with go / my golang packages in
> fedora would be fixed by the update to the final release, since upstream
> test suites targeting go 1.9 stable in travis aren't hitting any of those
> issues.

Please report those with more details in to BZ or to this list directly, with 
out report we can't find the causes and fixed them and anybody hitting them in 
future will not be able to avoid or quickly fix them.

> 
> What's the plan for rebasing golang to the stable release? The src.fd.org
> repository of golang [2] hasn't been touched since the F27 Mass Rebuilds,
> and the final update to 1.9 stable isn't mentioned in the Change page at all
> ... additionally, the F27 release cycle is progressing more quickly than I
> realized (and I suspect some people might not have realized yet either).
> 
> Fabio

As basically it hangs on me and I have been out for over a month it stalled.

It is done by now(actually in middle of Sep).

JC

> 
> [0]: https://fedoraproject.org/wiki/Changes/golang1.9
> [1]: https://golang.org/doc/devel/release.html#go1.9
> [2]: https://src.fedoraproject.org/rpms/golang/commits/master
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Golang in PPC64

[Jakub Cajka]

- Original Message -
> From: "Gianluca Sforna" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, July 31, 2017 10:02:55 AM
> Subject: Golang in PPC64
> 
> So I am getting the following becasue arduino-builder is a golang
> project and apparently Go is not in ppc64 repos. Do anyone know if
> golang will eventually be available on this arch?

Unfortunately realistically(maybe more pessimistically?) speaking never.
In more details it will be available(via packaging macros/guidelines) in two 
cases, either Fedora ppc64 support becomes Power8+ and someone implements Cgo 
support for Power ABIv1 in GC (aka Golang) or in second case someone will 
volunteer to do initial push for switch to gcc-go(read porting,...) and will 
commit to do whole distro support(resolving build failures,...) for it 
in-definitively.
Of course you can on your own switch to gcc-go explicitly on ppc64, it should 
work in its way(but I haven't checked on it in a while).

> 
> If not, is it correct to put BOTH BuildArch: noarch and ExclusiveArch:
> %{go_arches} in the arduino spec file so it will not be built for
> arches where golang is not available?

I believe this is only reasonable way Exclude/ExclusiveArch. Jan correct me if 
I'm wrong.

JC

> 
> 
> -- Forwarded message --
> From:  
> Date: Sun, Jul 30, 2017 at 9:18 AM
> Subject: Broken dependencies: arduino
> To: arduino-ow...@fedoraproject.org
> 
> 
> 
> 
> arduino has broken dependencies in the rawhide tree:
> On ppc64:
> 1:arduino-1.6.7-2.fc27.noarch requires arduino-builder
> Please resolve this as soon as possible.
> 
> 
> 
> 
> --
> Gianluca Sforna
> 
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
> Tinker Garage - http://tinkergarage.it
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 mass rebuild at risk

[Jakub Cajka]

- Original Message -
> From: "Carlos O'Donell" <car...@redhat.com>
> To: "Florian Weimer" <fwei...@redhat.com>, "Development discussions related 
> to Fedora"
> <devel@lists.fedoraproject.org>, "Jakub Jelinek" <ja...@redhat.com>, "Jakub 
> Cajka" <jca...@redhat.com>
> Cc: "Jeff Law" <l...@redhat.com>, "Stephen Gallagher" <sgall...@redhat.com>
> Sent: Thursday, July 13, 2017 1:01:03 PM
> Subject: Re: Fedora 27 mass rebuild at risk
> 
> On 07/12/2017 08:10 PM, Carlos O'Donell wrote:
> > On 07/11/2017 09:48 PM, Carlos O'Donell wrote:
> >> On 07/11/2017 12:37 AM, Carlos O'Donell wrote:
> >>> If we're lucky we can get everything ready for the 12th, but we might
> >>> need another day or two given how long it takes to build gcc on all
> >>> the arches.
> >>
> >> We are getting more luck. We'll see how tomorrow goes.
> > 
> > ETA for mass rebuild readiness tomorrow morning EDT after jcajka finishes
> > the final golang rebuild with a fixed glibc (ppc64le failures fixed).
> 
> Status update:
> 
> * Get the gcc trunk patch into F27 gcc. [Done]
> 
> * Rebuild glibc [Done]
> 
> * Fix Go 1.9.0 [In progress... | jcajka]
> 
>   * Build in progress.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20494275

Built, https://koji.fedoraproject.org/koji/taskinfo?taskID=20494945

JC

> 
> --
> Cheers,
> Carlos.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Golang 1.9

[Jakub Cajka]

- Original Message -
> From: "Dominik 'Rathann' Mierzejewski" <domi...@greysector.net>
> To: devel@lists.fedoraproject.org
> Sent: Thursday, June 22, 2017 1:40:35 PM
> Subject: Re: F27 System Wide Change: Golang 1.9
> 
> On Thursday, 22 June 2017 at 13:17, Jakub Cajka wrote:
> > - Original Message -
> > > From: "Tony Breeds" <t...@bakeyournoodle.com>
> > > To: devel@lists.fedoraproject.org
> > > Sent: Thursday, June 22, 2017 2:03:44 AM
> > > Subject: Re: F27 System Wide Change: Golang 1.9
> > > 
> > > On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote:
> > > 
> > > 
> > > 
> > > > Along with the rebase I do propose to drop ppc64 from Go
> > > > architectures(effectively disabling build of all packages adhering to
> > > > draft Go packaging guidelines) as ppc64 port of "GC" is not feature
> > > > complete(never were) and with Go 1.9 "GC" will be supporting only
> > > > Power 8 and up.
> > > 
> > > Just for clarity, you're ppc64le would remain supported.  Correct?
> > 
> > Yes. That is correct,
> 
> Can you make sure that the Go packaging guidelines draft makes it into
> the official guidelines?
> 
> Regards,
> Dominik

I have spoke about it with jchaloupka(main driver/author of guidelines) and we 
should be set to go, after I adjust them for the ppc64 change.

JC

> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Golang 1.9

[Jakub Cajka]

- Original Message -
> From: "Tony Breeds" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, June 22, 2017 2:03:44 AM
> Subject: Re: F27 System Wide Change: Golang 1.9
> 
> On Wed, Jun 21, 2017 at 10:06:17AM +0200, Jan Kurik wrote:
> 
> 
> 
> > Along with the rebase I do propose to drop ppc64 from Go
> > architectures(effectively disabling build of all packages adhering to
> > draft Go packaging guidelines) as ppc64 port of "GC" is not feature
> > complete(never were) and with Go 1.9 "GC" will be supporting only
> > Power 8 and up.
> 
> Just for clarity, you're ppc64le would remain supported.  Correct?

Yes. That is correct,

JC

> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Developer Portal release

[Jakub Cajka]

- Original Message -
> From: "Jakub Cajka" <jca...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Wednesday, March 1, 2017 11:56:02 AM
> Subject: Re: Fedora Developer Portal release
> 
> 
> 
> 
> 
> - Original Message -
> > From: "Petr Hracek" <phra...@redhat.com>
> > To: "Development discussions related to Fedora"
> > <devel@lists.fedoraproject.org>
> > Sent: Wednesday, March 1, 2017 10:37:09 AM
> > Subject: Fwd: Fedora Developer Portal release
> > 
> > Hi Fedora developers,
> > 
> > we released new and updated contents in Fedora Developer Portal.
> > 
> > What's new in Fedora Developer Portal?
> > - OpenShift section added[1]
> > - Go section expanded[2] and subsection added[3]
> 
> I'm already working on corrections and clarifications for the Go ones, I hope
> that I will open PR today.
> 
> Got bug opened against them on Mon
> https://bugzilla.redhat.com/show_bug.cgi?id=1426790 ;).

Actually last Fri.

> 
> IMO it would be cool, if they would get reviewed by golang and golang based
> package maintainers before publishing them in the future. :)
> 
> JC

Oh... darn they have changed since Mon, more to review. And I will have to 
re-base all of my changes... :/
I guess PR will be there in few days.

JC

> 
> > - MongoDB section added[4]
> > 
> > Something is missing from your point of view? Create a content.
> > Do you think you are expert in an area? Create a content.
> > List of known issues [5].
> > 
> > [1] https://developer.fedoraproject.org/deployment/openshift/about.html
> > [2]
> > https://developer.fedoraproject.org/tech/languages/go/go-installation.html
> > [3] https://developer.fedoraproject.org/tech/languages/go/go-programs.html
> > [4] https://developer.fedoraproject.org/tech/database/mongodb/about.html
> > [5] https://github.com/developer-portal/content/issues
> > 
> > Regards,
> > 
> > --
> > Petr Hracek
> > Software Engineer
> > EMEA ENG Mainstream RHEL
> > Red Hat, Inc.
> > email: phra...@redhat.com
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Developer Portal release

[Jakub Cajka]

- Original Message -
> From: "Petr Hracek" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, March 1, 2017 10:37:09 AM
> Subject: Fwd: Fedora Developer Portal release
> 
> Hi Fedora developers,
> 
> we released new and updated contents in Fedora Developer Portal.
> 
> What's new in Fedora Developer Portal?
> - OpenShift section added[1]
> - Go section expanded[2] and subsection added[3]

I'm already working on corrections and clarifications for the Go ones, I hope 
that I will open PR today. 

Got bug opened against them on Mon 
https://bugzilla.redhat.com/show_bug.cgi?id=1426790 ;).

IMO it would be cool, if they would get reviewed by golang and golang based 
package maintainers before publishing them in the future. :)

JC

> - MongoDB section added[4]
> 
> Something is missing from your point of view? Create a content.
> Do you think you are expert in an area? Create a content.
> List of known issues [5].
> 
> [1] https://developer.fedoraproject.org/deployment/openshift/about.html
> [2]
> https://developer.fedoraproject.org/tech/languages/go/go-installation.html
> [3] https://developer.fedoraproject.org/tech/languages/go/go-programs.html
> [4] https://developer.fedoraproject.org/tech/database/mongodb/about.html
> [5] https://github.com/developer-portal/content/issues
> 
> Regards,
> 
> --
> Petr Hracek
> Software Engineer
> EMEA ENG Mainstream RHEL
> Red Hat, Inc.
> email: phra...@redhat.com
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[Jakub Cajka]

- Original Message -
> From: jfi...@fedoraproject.org
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Wednesday, December 14, 2016 7:18:32 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> I agree with Zbyzsek on this.
> 
> What about to carry a tiny down-stream patch until this issue is fixed:
> https://github.com/golang/go/issues/18304
> 
> 
> Jakub
> 
> 

Suggestion by Brad Fitzpatrick in the upstream issue seems as reasonable 
implementation to me. Also it make possible opt-out/opt-in, if there will be 
need for it.
I will work on implementing/testing it along with the re-base(including update 
to packaging macros and Go guidelines draft) and I will update the change 
proposal to reflect it ASAP.

Sorry for longer notice I have been offline though the end of the year,

JC

> 
> 
> -- Původní zpráva --
> Od: Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl>
> Komu: Development discussions related to Fedora
> <devel@lists.fedoraproject.org>
> Datum: 13. 12. 2016 19:35:01
> Předmět: Re: F26 System Wide Change: Golang 1.8
> 
> 
> On Tue, Dec 13, 2016 at 01:06:29PM -0500, Jakub Cajka wrote:
> > > can we enable coredumping for Go programs by default - i.e. set
> > > GOTRACEBACK=
> > > crash?
> > > 
> > > Currently, Go terminate a process that panic and prints out an error
> > > message on stderr.
> > > 
> > > This approach does not provide much room for automatic Go panic
> > > detection.
> > 
> > It should be possible without any significant side effects apart from
> > generating cores and traces. But to enable this, I believe, it would need
> > alteration to the default system env.
> 
> Would it be possible? What is the package providing the default env vars?
> 
> systemd has DefaultEnvironment= in /etc/systemd/system.conf, but it is
> supposed to be used to create local overrides, and doesn't work well
> for this case (it's %config(noreplace) among other problems). In general
> setting global env vars does not work.
> 
> Instead, it would be nicer to modify the go runtime to default to a coredump
> if GOTRACEBACK= is not set. This would cover more cases and would not pollute
> the environment for users who are not using go.
> 
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[Jakub Cajka]

- Original Message -
> From: jfi...@fedoraproject.org
> To: jca...@redhat.com
> Cc: devel-annou...@lists.fedoraproject.org, "Development discussions related 
> to Fedora"
> 
> Sent: Tuesday, December 13, 2016 6:17:23 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> 
> Jakub,
> 
> 
> 
> 
> can we enable coredumping for Go programs by default - i.e. set GOTRACEBACK=
> crash?
> 
> 
> 
> 
> Currently, Go terminate  a process that panic and prints out an error
> message on stderr.
> 
> This approach does not provide much room for automatic Go panic detection.
> 
> 

It should be possible without any significant side effects apart from 
generating cores and traces. But to enable this, I believe, it would need 
alteration to the default system env. Would it be possible? What is the package 
providing the default env vars?

JC

> 
> 
> 
> 
> 
> 
> 
> 
> Regards,
> 
> Jakub
> 
> ABRT
> 
> 
> 
> 
> 
> -- Původní zpráva --
> Od: Jan Kurik 
> Komu: Development discussions related to Fedora  org>, devel-annou...@lists.fedoraproject.org
> Datum: 12. 12. 2016 12:32:15
> Předmět: F26 System Wide Change: Golang 1.8
> 
> "= Proposed System Wide Change: Golang 1.8 =
> https://fedoraproject.org/wiki/Changes/golang1.8
> 
> Change owner(s):
> * Jakub Čajka 
> 
> Rebase of Golang package to upcoming version 1.8 in Fedora 26,
> including rebuild of all dependent packages.
> 
> 
> == Detailed Description ==
> Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang
> 1.8 is schedule to be released in Feb. Due to current nature of Go
> packages, rebuild of dependent package will be required to pick up the
> changes.
> 
> 
> == Scope ==
> * Proposal owners:
> Rebase golang package in f26, help with resolving possible issues
> found during package rebuilds.
> 
> * Other developers:
> fix possible issues
> 
> * Release engineering:
> As there is scheduled mass-rebuild, nothing should be required.
> 
> * List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> "
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[Jakub Cajka]

- Original Message -
> From: "Stephen Gallagher" <sgall...@redhat.com>
> To: devel@lists.fedoraproject.org
> Sent: Monday, December 12, 2016 4:09:41 PM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> On 12/12/2016 10:03 AM, Jakub Cajka wrote:
> >> 
> >> The mass-rebuild is currently scheduled to begin on February 1st. Will
> >> there be a release-candidate available for Golang 1.8 by that time? If it
> >> is not, how will the contingency plan work?
> > 
> > There should be, if there would be serious issues(which I believe are
> > highly
> > unlikely as even with current beta release I haven't hit any considerate
> > issue while rebuilding Fedora locally), I assume we will stick to the
> > previous version of Go as stated in contingency plan. Should I expand that
> > section in any direction?
> > 
> 
> Mostly I'm just concerned that any issue discovered during the mass-rebuild
> that
> would require a downgrade to Go 1.7 would require another mass-rebuild to
> accomplish it. Which really means that once this process starts, we're
> committed
> to finishing it (and fixing whatever comes up). Thus, it seems like there
> isn't
> a realistic contingency strategy (and we should make that clear in the
> proposal
> for FESCo to judge the risk).

I believe it is the same as in other issues found at the mass-rebuild time, 
backing the change and rebuilding affected packages. Or am I missing something?

As the Betas and RC of golang are coming out I do my local "scratch rebuilds" 
and I'm confident even at current moment with Beta1 mass re-buld would be 
successful(from Go side).

JC

> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[Jakub Cajka]

- Original Message -
> From: "Stephen Gallagher" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, December 12, 2016 3:29:09 PM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> On 12/12/2016 06:27 AM, Jan Kurik wrote:
> > = Proposed System Wide Change: Golang 1.8 =
> > https://fedoraproject.org/wiki/Changes/golang1.8
> > 
> > Change owner(s):
> > * Jakub Čajka 
> > 
> > Rebase of Golang package to upcoming version 1.8 in Fedora 26,
> > including rebuild of all dependent packages.
> > 
> > 
> > == Detailed Description ==
> > Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang
> > 1.8 is schedule to be released in Feb. Due to current nature of Go
> > packages, rebuild of dependent package will be required to pick up the
> > changes.
> 
> 
> The mass-rebuild is currently scheduled to begin on February 1st. Will there
> be
> a release-candidate available for Golang 1.8 by that time? If it is not, how
> will the contingency plan work?

There should be, if there would be serious issues(which I believe are highly 
unlikely as even with current beta release I haven't hit any considerate issue 
while rebuilding Fedora locally), I assume we will stick to the previous 
version of Go as stated in contingency plan. Should I expand that section in 
any direction?

JC

> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Golang 1.7 in el6

[Jakub Cajka]

Hello,

  I have updated golang to version go1.7.1 in el6. As there were several 
outstanding issues with the old version(and it is no longer supported by 
upstream) and go1.7 brings several improvements(see 
https://tip.golang.org/doc/go1.7). It is now submitted as update in bodhi(no 
build-root override) https://bodhi.fedoraproject.org/updates/golang-1.7.1-1.el6.

  Karma and testing is welcomed,

Jakub Čajka
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: F24 System Wide Change: Golang 1.6

[Jakub Cajka]

- Original Message -
> From: "Florian Weimer" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, January 13, 2016 9:46:15 AM
> Subject: Re: F24 System Wide Change: Golang 1.6
> 
> On 01/13/2016 12:56 AM, Peter Robinson wrote:
> > On Tue, Jan 12, 2016 at 5:30 PM, Matthew Miller
> >  wrote:
> >> On Tue, Jan 12, 2016 at 01:31:30AM +, Peter Robinson wrote:
> >>> Will there be an ABI guaranteed beta or RC so that this can be
> >>> complete before branching as per the schedule [1]? All major rebases
> >>> should be complete prior to branching.
> >>> [1] https://fedoraproject.org/wiki/Releases/24/Schedule
> >>
> >> Since everything is statically linked, the ABI isn't really a factor.
> > 
> > It is if it changes between say beta and GA because it'll still all
> > then need another rebuild, hence the question.
> 
> Go library packages do not actually contain compiled code, right? So
> the ABI really should not matter, it's like Perl in this regard.
>

Basically yes, at the moment.

Peter Robinson proposed to me "merging" the golang re-build with scheduled mass 
rebuild. I think it should work.
Golang have pre-releases and they should be good enough for the re-build and I 
don't expect any API/ABI breakages.
I will update the change proposal accordingly also added link to the COPR witch 
will contain pre-release builds.

Jakub

> 
> Florian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: packaging golang guidelines (like etcd, consul)

[Jakub Cajka]

- Original Message -
> From: "Adam Goode" 
> To: devel@lists.fedoraproject.org
> Cc: "Matthew Miller" 
> Sent: Friday, November 6, 2015 3:47:42 PM
> Subject: Re: packaging golang guidelines (like etcd, consul)
> 
> On Mon, Nov 02, 2015 at 09:05:09AM -0500, Matthew Miller wrote:
> > On Sun, Nov 01, 2015 at 05:44:42PM +0100, Jan Chaloupka wrote:
> > > >are there some fedora guidelines for golang apps?
> > > >are there macros and helpers for rpm?
> > > https://fedoraproject.org/wiki/PackagingDrafts/Go
> > 
> > This needs help in going from a draft to real guidelines.
> > 
> 
> I am also trying to figure this out. Looking at actual
> packaged golang things in Fedora, I see quite a difference
> between the drafts and what I see in specfiles. There
> are a lot of macros copied everywhere.
>

Could you please elaborate. 

> 
> Is there any more up to date guidance? It would be an
> improvement to even just copy/paste emails of discussions
> into the bottom of the wiki draft.
>

This(https://fedoraproject.org/wiki/PackagingDrafts/Go) 
should be most up to date. For discussion see FPC ticket
https://fedorahosted.org/fpc/ticket/382.

Any input will be welcomed.

Jakub

> 
> 
> Adam
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Docker and gcc-go

[Jakub Cajka]

- Original Message -
 From: Jakub Cajka jca...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org, p...@lists.fedoraproject.org,
 s3...@lists.fedoraproject.org
 Sent: Thursday, April 2, 2015 4:50:15 PM
 Subject: Docker and gcc-go
 
 Hello,
as gcc5 is in Fedora22+ it is possible to build docker and its BRs using
gcc-go with small changes to the spec files. Not only on x86_64, but also
on ppc64le, even on s390x(sharkcz tried) and ppc64. It crashes/hangs
sometimes(I'm looking in to it) but works on x86_64 and ppc64(le) most of
the time :) (haven't done any extensive testing yet) and haven't tried
s390x yet.
  
 Github repo with modified spec files of docker and its BRs:
 
   https://github.com/jcajka/fedora-docker-gccgo
 
 SRPMS:
 
   https://jcajka.fedorapeople.org/srpms/
 
 x86_64 COPR repo(f22/f23):
 
   https://copr.fedoraproject.org/coprs/jcajka/docker-gccgo/
 
 ppc64(le) fedorapeople.org repo(f22):
 
   https://repos.fedorapeople.org/repos/jcajka/docker-gccgo/
 
 ppc64(le) base images(just to test it ;) ):
  
   docker pull jcajka/fedora22-ppc64[le] (I hope images are there as they are
   not showing up in webUI)
 
   (were generated using
   https://github.com/docker/docker/blob/master/contrib/mkimage-yum.sh
   modified to install also dnf(yum), would be great to have base images
   available same way as on primary)
 
 s390x coming soon :)

docker works on s390x, but sometimes crashes/hangs too(the issue seems to be 
common to all platforms, looking in to it)  

ppc64(le)/s390x fedorapeople.org repo(f22):

  https://repos.fedorapeople.org/repos/jcajka/docker-gccgo/

s390x base image):

  docker pull jcajka/fedora22-s390x
  (generated the same way as ppc images)

 
 It is definitely not production ready and needs lots of testing/debugging.
 Looking forward for any feedback.
 
 Jakub Čajka
 
 
 
 


 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Docker and gcc-go

[Jakub Cajka]

Hello,
   as gcc5 is in Fedora22+ it is possible to build docker and its BRs using 
gcc-go with small changes to the spec files. Not only on x86_64, but also on 
ppc64le, even on s390x(sharkcz tried) and ppc64. It crashes/hangs sometimes(I'm 
looking in to it) but works on x86_64 and ppc64(le) most of the time :) 
(haven't done any extensive testing yet) and haven't tried s390x yet.
 
Github repo with modified spec files of docker and its BRs:

  https://github.com/jcajka/fedora-docker-gccgo

SRPMS:

  https://jcajka.fedorapeople.org/srpms/

x86_64 COPR repo(f22/f23):

  https://copr.fedoraproject.org/coprs/jcajka/docker-gccgo/

ppc64(le) fedorapeople.org repo(f22):

  https://repos.fedorapeople.org/repos/jcajka/docker-gccgo/

ppc64(le) base images(just to test it ;) ):
 
  docker pull jcajka/fedora22-ppc64[le] (I hope images are there as they are 
not showing up in webUI)

  (were generated using 
https://github.com/docker/docker/blob/master/contrib/mkimage-yum.sh modified to 
install also dnf(yum), would be great to have base images available same way as 
on primary)

s390x coming soon :)

It is definitely not production ready and needs lots of testing/debugging. 
Looking forward for any feedback.

Jakub Čajka




   
   
  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I wrote small script to list FTBFS koji entries

[Jakub Cajka]

 As my work usually is around fixing packages which failed to build on
 AArch64 I spend lot of time with Koji.
 
 Today I started writing script which has to list all current FTBFS
 entries from selected Koji instance - kind like [1] does but with few
 extras:
 
 - no packages which got built later
 - no repeated entries
 
 I plan to make something like Ubuntu has [2] which was great help when I
 was working on fixing packages while working for Canonical.
 
 No idea how far I will go with it but something like generator for such
 page is on my to do list.
 
 Current version of script is on [3]. My Python skills maybe are not the
 greatest ones but script works for me.
 
 Patches, ideas, bugs are welcome.

Hello,

I am probably working on solving this already :), may be in a bit different 
way. (I'm around s390 and ppc kojis.)

http://185.8.164.10/[package/tag] (location will change in about a week)

Initial ideas belong to sharkcz :). It can for now just show overview of tags 
and package in tag across all Fedora's kojis. It is still heavy WIP. I'm now 
overcoming slowness of koji responsiveness using local DB synced with kojis by 
watching fedmsg. 

Overview of FTBFS is my next top priority, later with some sort of task 
tracking and comment system, as lot of FTBFS have common cause and affects 
multiple (secondary) kojis, and generally to help coordinate our 
resources/manpower on fixing stuff(to avoid fixing the same/similar bug up to 4 
times).

I will soon upload sources on github.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct