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? 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. 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
