On Fri, Oct 19, 2018, 10:58 Jakub Cajka <jcajka@xxxxxxxxxx> wrote:
----- Original Message -----
> From: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "Fabio Valentini" <nicolas.mailhot@xxxxxxxxxxx>
> 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.
By the way, with the latest update to redhat-rpm-config in rawhide (122-1.fc30), *all* packages using the new go macros are now broken. With that, I now have about 40 broken golang packages.
I have neither the time nor the patience to fix them.
Fabio
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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
