On Sat, Aug 15, 2020 at 12:37 AM Sérgio Basto <sergio@xxxxxxxxxx> wrote: > > On Fri, 2020-08-14 at 21:14 +0200, Fabio Valentini wrote: > > On Fri, Aug 14, 2020 at 8:48 PM Sérgio Basto <sergio@xxxxxxxxxx> > > wrote: > > > On Fri, 2020-08-14 at 20:30 +0200, Fabio Valentini wrote: > > > > So, I've been trying to figure out strange build failures in my > > > > Java > > > > packages when running mock with `--enablerepo local`. > > > > > > > > First I thought java-11-openjdk update might be to blame, but now > > > > I > > > > found another "unrelated" issue: > > > > > > > > OCaml packages built with dune and `--enablerepo local` right now > > > > produce packages where binaries get permissions `555` set instead > > > > of > > > > `755` despite dune explicitly setting 755. > > > > > > > > So ... Huh? > > > > > > > > The only package update other than python 3.9 beta 5 → python 3.9 > > > > rc > > > > 1 > > > > and a Java update that happened in this time frame - which might > > > > affect *both* Java *and* OCaml builds in weird ways - would be > > > > ... > > > > the > > > > first glibc 2.33 development snapshot. > > > > > > It is against the new policy rules, please only update rawhide > > > after > > > completing the first branched compose and his mirror > > > synchronization. i.e when we have a new buildroot . > > > > > > While the compose today seems successful is not yet published > > > > Sérgio, I have no idea what you're talking about here. Do you mean > > the > > new policy to wait with a rawhide compose until the first "branched" > > compose is successful and synced out? > > yes > > > If I understand correctly, that > > "policy" is enforced by bodhi not allowing any builds into "branched" > > by default, and releng not launching any rawhide composes until a > > "branched" compose finishes. > > > > I have no superpowers that allow me to circumvent those restrictions > > :) > > If I had, I would untag glibc 2.22.9000 to check if it is indeed > > broken, or if my development PC is haunted instead. (snip) > https://bodhi.fedoraproject.org/updates/?packages=glibc > > glibc-2.32.9000-1.fc34 has been submitted for stable by bodhi > a day ago ... There's a difference between bodhi pushing a rawhide update to "stable" and it being included in "rawhide" repositories. Because bodhi does not compose rawhide. It just marks packages as "to be included in the next compose". > In my view, if f33 has not yet been composed and published, all > packages that are in rawhide shouldn't have changes to what will be > f33, to allow for a smooth transaction and not make things more hard > that it is . This is exactly what's already happening. I think you're missing the "compose" step that's happening between things getting built and them actually getting included in "public" repositories. Because that step has not happened for a few days, "to allow for a smooth transaction", as you put it. > And I don't understand what is the rush of update things in rawhide , > why people can't wait one week until things calm down , is just an > exercise of coordination. And BTW, the opposite, we also should avoid > last minute changes, before mass-rebuild :) I am in no rush, but I also don't want to wait for a week twiddling my thumbs for no good reason. PS: I agree, rushing changes into rawhide before the mass rebuild is a bad idea, but that's a different problem ... > Hopefully f33 is almost published . F33 won't be "published" for another two months :) But if you're talking about a successful f33 compose, it already happened half a day ago, and the repos and mirrors should get updated soon ... https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/WATCKLQ7S3B77CT4UGBPUPN3NJQGIJWU/ Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
