Re: Proven packager help needed to merge libevent 2.1.12 side tag
Zbigniew Jędrzejewski-Szmek writes: > On Thu, Oct 01, 2020 at 01:25:13PM +0200, Ondřej Lysoněk wrote: >> Fabio Valentini writes: >> >> > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: >> >> >> >> Fabio Valentini writes: >> >> >> >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> >> >> done now in the side tag. I've tried to merge the side tag by creating >> >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> >> >> does not have commit access rights to ...'. So I guess I'll need proven >> >> >> packager help again. >> >> >> >> >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> >> >> >> >> Thanks! >> >> > >> >> > Done! >> >> > >> >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update >> >> > libevent to version 2.1.12. This update includes a rebuild of >> >> > dependent packages due to an soname bump." >> >> > >> >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 >> >> >> >> Thanks, Fabio. >> >> >> >> I just noticed that it says in the update that it cannot be pushed: >> >> "This update cannot be pushed to stable. These builds >> >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 >> >> tag." >> >> >> >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 >> >> after it has been rebuilt in the libevent side tag. >> >> >> >> Not sure what we should do about it. Should we perhaps pull in the new >> >> protobuf into the libevent side tag and rebuild community-mysql again? >> > >> > Ugh. Has the new protobuf been merged into rawhide yet, or is it still >> > in its own side tag? >> >> It has been merged as far as I can tell. >> >> > If it's already merged to rawhide, you can just submit another rebuild >> > of community-mysql for your own side tag, and I can hopefully refresh >> > the bodhi update. >> >> Oh, right. The new protobuf will appear in my side tag by inheritance, >> correct? Great. >> >> community-mysql owners, please rebuild your package once more in the >> side tag: >> >> fedpkg build --target=f34-build-side-30069 > > It's building. I see that the update is stable now. Thank you all. Ondrej ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
Fabio Valentini writes: > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk wrote: >> >> Fabio Valentini writes: >> >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: >> >> >> >> Hi, >> >> >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> >> done now in the side tag. I've tried to merge the side tag by creating >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> >> does not have commit access rights to ...'. So I guess I'll need proven >> >> packager help again. >> >> >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> >> >> Thanks! >> > >> > Done! >> > >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update >> > libevent to version 2.1.12. This update includes a rebuild of >> > dependent packages due to an soname bump." >> > >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 >> >> Thanks, Fabio. >> >> I just noticed that it says in the update that it cannot be pushed: >> "This update cannot be pushed to stable. These builds >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 >> tag." >> >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 >> after it has been rebuilt in the libevent side tag. >> >> Not sure what we should do about it. Should we perhaps pull in the new >> protobuf into the libevent side tag and rebuild community-mysql again? > > Ugh. Has the new protobuf been merged into rawhide yet, or is it still > in its own side tag? It has been merged as far as I can tell. > If it's already merged to rawhide, you can just submit another rebuild > of community-mysql for your own side tag, and I can hopefully refresh > the bodhi update. Oh, right. The new protobuf will appear in my side tag by inheritance, correct? Great. community-mysql owners, please rebuild your package once more in the side tag: fedpkg build --target=f34-build-side-30069 Thanks! Ondrej ___ 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: Proven packager help needed to merge libevent 2.1.12 side tag
Fabio Valentini writes: > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk wrote: >> >> Hi, >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be >> done now in the side tag. I've tried to merge the side tag by creating >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek >> does not have commit access rights to ...'. So I guess I'll need proven >> packager help again. >> >> Can someone please merge the f34-build-side-30069 side tag? >> >> Thanks! > > Done! > > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update > libevent to version 2.1.12. This update includes a rebuild of > dependent packages due to an soname bump." > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2 Thanks, Fabio. I just noticed that it says in the update that it cannot be pushed: "This update cannot be pushed to stable. These builds community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34 tag." And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34 after it has been rebuilt in the libevent side tag. Not sure what we should do about it. Should we perhaps pull in the new protobuf into the libevent side tag and rebuild community-mysql again? Ondrej ___ 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
Proven packager help needed to merge libevent 2.1.12 side tag
Hi, So all the required rebuilds for the libevent 2.1.12 rebase should be done now in the side tag. I've tried to merge the side tag by creating an update in Bodhi as described in [1], but Bodhi tells me 'olysonek does not have commit access rights to ...'. So I guess I'll need proven packager help again. Can someone please merge the f34-build-side-30069 side tag? Thanks! [1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/#_how_does_gating_multi_builds_updates_work Ondrej Lysonek ___ 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: Proven packager help needed to rebuild packages
Zbigniew Jędrzejewski-Szmek writes: > On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote: >> Zbigniew Jędrzejewski-Szmek writes: >> >> > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek >> > wrote: >> >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote: >> >> > Hi, >> >> > >> >> > I'm coordinating rebuilds of packages due to the libevent rebase [1] >> >> > and I'm having trouble reaching owners of some of the packages. Is >> >> > there a proven packager willing to help me with the rebuilds? >> >> > >> >> > The rebuilds should be done using the following command: >> >> > >> >> > fedpkg build --target=f34-build-side-30069 >> >> >> >> I started the builds now. Unfortunately quite a few have failed. >> >> In general fedpkg build --target=f34-build-side-30069 --nowait >> >> seems to take a lot of time, sometimes maybe a minute. >> >> >> >> > The following packages need to be rebuilt. Note that it is expected >> >> > that 'sems' will fail to build, however I think we should try anyway. >> >> > >> >> > 389-ds-base >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed >> >> BuildError: Error running GIT command "git clone -n >> >> https://src.fedoraproject.org/rpms/389-ds-base.git >> >> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base", >> >> see checkout.log for details >> >> >> >> I restarted the build, let's see how it does: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545 >> >> >> >> > ccnet >> >> > groonga >> >> failed with error: >> >> attempt to use unversioned python, define %__python to /usr/bin/python2 >> >> or /usr/bin/python3 explicitly >> >> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to >> >> expand >> >> error: query of specfile groonga.spec failed, can't parse >> >> >> >> > links >> >> > lldpd >> >> > mpris-scrobbler >> >> > nbd-runner >> >> > netatalk >> >> > nsd >> >> > perl-Event-Lib >> >> > pgbouncer >> >> After starting the build I saw that it was already rebuilt: >> >> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek >> >> - 1.14.0-5 >> >> - Rebuilt for libevent 2.1.12 >> >> >> >> * Tue Sep 15 2020 Devrim Gündüz - 1.14.0-4 >> >> - Rebuild against new libevent >> >> >> >> An additional build probably doesn't hurt. >> >> >> >> > remctl >> >> > seafile >> >> > sems >> >> > sslsplit >> >> > sstp-client >> >> > tmate >> >> > trickle >> > >> > They all built after some pushing and prodding, with the exception of sems: >> >> Thank you very much, Zbyszek! Can you please also rebuild scanssh? It >> was not on my original list, but it looks like I'll need help with it >> too. > > It's building now. > > What next: is the side tag ready to merge? Will you do it or should I? We're still working on rebuilding libreswan and transmission. I expect it to be ready within a couple of days, possibly even today. If I have the necessary rights to merge it, I'll do it myself. I'll reach out if I need any more help. Thanks a lot. Ondrej ___ 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: Proven packager help needed to rebuild packages
Zbigniew Jędrzejewski-Szmek writes: > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote: >> > Hi, >> > >> > I'm coordinating rebuilds of packages due to the libevent rebase [1] >> > and I'm having trouble reaching owners of some of the packages. Is >> > there a proven packager willing to help me with the rebuilds? >> > >> > The rebuilds should be done using the following command: >> > >> > fedpkg build --target=f34-build-side-30069 >> >> I started the builds now. Unfortunately quite a few have failed. >> In general fedpkg build --target=f34-build-side-30069 --nowait >> seems to take a lot of time, sometimes maybe a minute. >> >> > The following packages need to be rebuilt. Note that it is expected >> > that 'sems' will fail to build, however I think we should try anyway. >> > >> > 389-ds-base >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed >> BuildError: Error running GIT command "git clone -n >> https://src.fedoraproject.org/rpms/389-ds-base.git >> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base", >> see checkout.log for details >> >> I restarted the build, let's see how it does: >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545 >> >> > ccnet >> > groonga >> failed with error: >> attempt to use unversioned python, define %__python to /usr/bin/python2 or >> /usr/bin/python3 explicitly >> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to expand >> error: query of specfile groonga.spec failed, can't parse >> >> > links >> > lldpd >> > mpris-scrobbler >> > nbd-runner >> > netatalk >> > nsd >> > perl-Event-Lib >> > pgbouncer >> After starting the build I saw that it was already rebuilt: >> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek >> - 1.14.0-5 >> - Rebuilt for libevent 2.1.12 >> >> * Tue Sep 15 2020 Devrim Gündüz - 1.14.0-4 >> - Rebuild against new libevent >> >> An additional build probably doesn't hurt. >> >> > remctl >> > seafile >> > sems >> > sslsplit >> > sstp-client >> > tmate >> > trickle > > They all built after some pushing and prodding, with the exception of sems: Thank you very much, Zbyszek! Can you please also rebuild scanssh? It was not on my original list, but it looks like I'll need help with it too. Thanks. Ondrej ___ 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
Proven packager help needed to rebuild packages
Hi, I'm coordinating rebuilds of packages due to the libevent rebase [1] and I'm having trouble reaching owners of some of the packages. Is there a proven packager willing to help me with the rebuilds? The rebuilds should be done using the following command: fedpkg build --target=f34-build-side-30069 The following packages need to be rebuilt. Note that it is expected that 'sems' will fail to build, however I think we should try anyway. 389-ds-base ccnet groonga links lldpd mpris-scrobbler nbd-runner netatalk nsd perl-Event-Lib pgbouncer remctl seafile sems sslsplit sstp-client tmate trickle Thanks! [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QOQW2BJBYMTIEUQIAYVEIX2L5IIOHDZL/ Ondrej Lysonek ___ 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: [HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide
olyso...@redhat.com (Ondřej Lysoněk) writes: > - some of the packages (libreswan, perl-Event-Lib, sems) fail to build > for unrelated reasons. Unless these are fixed, they'll become > uninstallable. I've notified their owners. Thanks to Petr Písař, perl-Event-Lib now builds, event with the new libevent. Ondrej ___ 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
[HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide
(maintainers of dependent packages in BCC) Hi, libevent will be rebased to 2.1.12 in Rawhide. The new version includes a soname bump. Rebuilds of libevent and dependent packages will happen in side tag 'f34-build-side-30069'. Due to the nature of the dependency tree, we can't simply build all dependent packages at the same time. We'll have to build in batches. See my plan at the bottom of the email. I'll reach out to individual maintainers when it's time to rebuild their package. However, the new libevent is already built in the tag, so if you own a package from the "Initial set", you don't have to wait for me and you can start the rebuild right away using the following command. fedpkg build --target=f34-build-side-30069 I've performed test rebuilds of the dependent packages in COPR and it went mostly well, so I don't expect any big issues. Some notable things I found during the test rebuilds: - some of the packages (libreswan, perl-Event-Lib, sems) fail to build for unrelated reasons. Unless these are fixed, they'll become uninstallable. I've notified their owners. - libreswan should hopefully get fixed soon by its own rebase - perl-Event-Lib will likely get orphaned - no response about sems - I wasn't able to rebuild community-mysql, because for some reason, it fails to build in COPR (but builds fine in Koji). I guess we'll have to build this one with our fingers crossed. - the new libevent breaks transmission slightly. Hopefully this will get fixed soon. Worst-case scenario, we'll temporarily revert the problematic libevent change, or come up with some temporary quick fix for transmission. Reported upstream: https://github.com/transmission/transmission/issues/1437 - due to a build dep loop, avahi will need to be bootstrapped - I'm not sure if chromium really utilizes the system libevent - it seems to bundle it's own version. Nevertheless, it has BuildRequires for libevent-devel, so it's included in my list. List of dependent packages: - 389-ds-base - addrwatch - avahi - ccnet - chromium - community-mysql - coturn - fragments - fstrm - gearmand - getdns - groonga - icecat - Io-language - ladvd - libasr - libcouchbase - libmemcached - libreswan - libverto - links - lldpd - lua-event - mediaconch - memcached - mpris-scrobbler - nbd-runner - netatalk - nfs-utils - nsd - ntp - ocproxy - openmpi - opensmtpd - perl-Event-Lib - pgbouncer - php-pecl-event - php-pecl-http - php-pecl-memcached - pmix - qt5-qtwebengine - remctl - scanssh - seafile - sems - sslsplit - sstp-client - suricata - thrift - tmate - tmux - tor - transmission - trickle - unbound - uwsgi - zabbix Here is my plan for the rebuild process. Note that the "After ... is rebuilt" paragraphs can be executed in any order - just their respective dependencies must be met. Initial set: - avahi - needs to be bootstrapped - packages that I haven't been able to rebuild: - community-mysql, libreswan, perl-Event-Lib, sems - other: addrwatch, ccnet, coturn, groonga, ladvd, libasr, libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner, nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event, php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit, sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix After avahi is rebuilt, we can rebuild: 389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event, netatalk, qt5-qtwebengine, thrift, tor, transmission After unbound and avahi is rebuilt, we can rebuild: chromium, getdns After memcached is rebuilt, we can rebuild: libmemcached After memcached and libmemcached is rebuilt, we can rebuild: gearmand, Io-language, php-pecl-memcached After qt5-qtwebengine is rebuilt, we can rebuild: mediaconch After pmix and avahi is rebuilt, we can rebuild: openmpi Best regards Ondřej Lysoněk ___ 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: Is dist-git a good place for work?
clime writes: > On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk wrote: >> >> Hunor Csomortáni writes: >> >> > On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote: >> >> Well, a way to allow force pushes would be to have a git hook that >> >> branches the tree before the force push. (creating a branch named >> >> something like audit-force-push-) >> >> That way you can retain data for legal/auditing reasons, while allowing >> >> every day history to be rewritten. >> > >> > Wouldn't it be easier to approach this from a build system perspective >> > and let for example the build system (or tools) tag the commits which >> > were built from with some for-ever-living tags? This would still >> > ensure a complete audit trail for whatever was built and shipped, but >> > could eliminate the need for a complete lock down of dist/source-git. >> > >> >> Not sure how "nice" that would be for an auditor that has to >> >> reconstruct what happened over multiple force pushes that way, it also >> >> will generate quite an amount of noisy metadata (branches), but it >> >> could work. >> > >> > Refs created for auditing purposes could be kept in a separate git >> > namespace so they don't create noise in everyday workflows. >> >> As someone who works with git history all the time, I cannot imagine how >> I would work in such an environment. Consider the simple task of finding >> the commit that first introduced a downstream change. Currently with >> dist-git, I can just do 'git log patch-file', scroll to the very end and >> be done with it. >> > > It's a good point that this operation would be harder but it could be > solved, I think. > > I mean it could have beneficial features for maybe not all packages > but at least some. I think that source-git could make sense for packages that have historically *not* had many patches - be that downstream or cherry-picked patches. (And I realize that is quite the opposite of what others have said here.) With such packages, I could just git-pull new upstream releases, review the changes and git-push them to Fedora, instead of having to juggle with tarballs. That's a very appealing proposition to me. And with such packages, you wouldn't run into the downside of accumulating a history that is hard to understand. So my opinion is that for simple packages that have no patches and where the conversion between source-git and dist-git is relatively straightforward, source-git could be a great option. For other packages, not really. > > I suspect on such scale as Fedora operates, it might be quite hard to > do something which improves things for everybody. Agreed. Ondřej > >> If what you're proposing was implemented, then I'd have to manually try >> all the tags until I found the "right history" where the change was >> first introduced. >> >> In an email in this thread clime suggested a similar approach, only >> instead of tags there would be a separate branch for each upstream >> release. While that eliminates the need to allow force-pushes, for the >> purposes of digging through the history it's the same thing. The only >> difference is that instead of iterating over tags, I'd be iterating over >> branches. >> >> The only other approach to source-git that I can think of is merging new >> upstream releases instead of git-rebasing on top of them. That is the >> approach that I originally thought would work, but one of Neal's >> responses made me realize that this approach also has a significant >> drawback - it makes distinguishing between downstream changes and >> cherry-picked upstream changes hard. >> >> I was originally excited about source-git, however currently I don't see >> an approach to source-git that would work for me and I don't think I'd >> use it if it became available. And frankly, I think I wouldn't want >> other people using it either because it would make understanding their >> packages hard. >> >> I completely agree that dist-git is difficult to work with, but perhaps >> instead of inventing something completely new, we could focus on making >> working with dist-git easier by dropping the changlog and Release from >> the specfiles and on creating tools for ourselves to make working with >> patches easier? I'm currently looking into Quilt, mentioned by several >> people here, to see if it could make my life easier at all. Just a >> suggestion. >> >> Thanks everyone for this enlightening thread. >> >> Ondřej Lysoněk ___ 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: Is dist-git a good place for work?
Hunor Csomortáni writes: > On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote: >> Well, a way to allow force pushes would be to have a git hook that >> branches the tree before the force push. (creating a branch named >> something like audit-force-push-) >> That way you can retain data for legal/auditing reasons, while allowing >> every day history to be rewritten. > > Wouldn't it be easier to approach this from a build system perspective > and let for example the build system (or tools) tag the commits which > were built from with some for-ever-living tags? This would still > ensure a complete audit trail for whatever was built and shipped, but > could eliminate the need for a complete lock down of dist/source-git. > >> Not sure how "nice" that would be for an auditor that has to >> reconstruct what happened over multiple force pushes that way, it also >> will generate quite an amount of noisy metadata (branches), but it >> could work. > > Refs created for auditing purposes could be kept in a separate git > namespace so they don't create noise in everyday workflows. As someone who works with git history all the time, I cannot imagine how I would work in such an environment. Consider the simple task of finding the commit that first introduced a downstream change. Currently with dist-git, I can just do 'git log patch-file', scroll to the very end and be done with it. If what you're proposing was implemented, then I'd have to manually try all the tags until I found the "right history" where the change was first introduced. In an email in this thread clime suggested a similar approach, only instead of tags there would be a separate branch for each upstream release. While that eliminates the need to allow force-pushes, for the purposes of digging through the history it's the same thing. The only difference is that instead of iterating over tags, I'd be iterating over branches. The only other approach to source-git that I can think of is merging new upstream releases instead of git-rebasing on top of them. That is the approach that I originally thought would work, but one of Neal's responses made me realize that this approach also has a significant drawback - it makes distinguishing between downstream changes and cherry-picked upstream changes hard. I was originally excited about source-git, however currently I don't see an approach to source-git that would work for me and I don't think I'd use it if it became available. And frankly, I think I wouldn't want other people using it either because it would make understanding their packages hard. I completely agree that dist-git is difficult to work with, but perhaps instead of inventing something completely new, we could focus on making working with dist-git easier by dropping the changlog and Release from the specfiles and on creating tools for ourselves to make working with patches easier? I'm currently looking into Quilt, mentioned by several people here, to see if it could make my life easier at all. Just a suggestion. Thanks everyone for this enlightening thread. Ondřej Lysoněk ___ 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: Is dist-git a good place for work?
Thanks for sharing that, Simo. I respect your opinion. Believe me, I do like my git history clean and I go to great lengths to keep it clean. I certainly don't think I'm lazy when it comes to that. However, I don't think that maintaining a linear history helps with readability and understandability of the history. Quite the opposite - keeping the branching helps to see which changes are related and in what context a certain change was made. Just to be clear, when I say "rebase", I literally mean the act of changing the merge base. On the other hand, squashing commits and similar things to have a nice series of logical changes is a must for me. But I don't want to veer too much off topic here. I believe this was discussed at length in a LWN article (which just happens to be centered around the Linux kernel ;)). https://lwn.net/Articles/791284/ Ondřej Simo Sorce writes: > Sorry little reant ahead: > > In general, merge commits are hideous, they can conceal merge conflict > resolution that can a) introduce bugs, b) make it hard to figure out > when bugs were introduced by preventing use of git bisect and c) > generally make it very hard to understand the history of changes. > > In general rebase and squash requirement tend to generate much cleaner > changes, and catches errors before they are merged. > > Merge commits are useful for gigantic projects like the Linux kernel > where A) the maintainers are extremely knowledgeable and can properly > resolve merge conflicts B) the people proposing the merge may not > actually know how to properly resolve a merge conflict as it is > happening outside of their area of expertise C) the feedback loop would > be excessive and dwarf the history linearity benefits. > > Those projects are rare, using merge commits on small projects is just > lazyness that you pay later. It's accruing technical debts > unnecessarily. > > That said, for non-code projects history may no matter that much, as > you do not need to resolve "bugs", and introducing "bugs" via merge > commits conflict resolution is rare, so for those it may not matter > what do you use to merge in stuff, you are using the SCM just as a > central repository and "merge tool" and sometimes as a way to apply > release tags. > > Whenever using the history is useful I find I *really* hate merge > commits as they muddy everything, and make the work of figuring out > what happened after the fact (and sometimes *during the fact*) very > hard. > > Simo. > > On Tue, 2020-05-05 at 15:29 +0200, Ondřej Lysoněk wrote: >> Tomas Tomecek writes: >> >> > Thank you all for raising all the questions and concerns. >> > >> > Before I reply, I'd like to stress that we are still in a prototype >> > phase - not everything is solved (clearly) and at this point, we >> > experiment with the workflow mostly. >> > >> > Luckily, force-pushes are not allowed in dist-git, which makes the >> > update/sync process easier (knowing that history cannot be changed). >> > Therefore when a new commit lands in dist-git, we'd just "transform" >> > it to source-git and pushed it to the source-git repo. We could even >> > ask all the contributors to rebase their PRs when this happens. >> >> This "rebase all PRs" thing seems to be a recurring theme... What is the >> reason to ask contributors to rebase? (I mean, are we trying to go back >> to the days of centralized version control systems?) >> >> In my experience, there is rarely a good reason to rebase (rebasing >> because the CI system tests the contributor's branch rather than the >> resulting merge is not a good reason; the CI system should be fixed >> instead) and asking everyone to rebase just slows things down. Please >> let's not go down that road, if possible. >> >> Other than that, I like the idea of source git and I'm looking forward >> to using it, once the synchronization issues are resolved. Thanks for >> working on it. >> >> Ondřej Lysoněk >> >> > On the other hand, when a new commit lands in the source-git repo, we >> > could either transform and push to dist-git directly or open a PR. The >> > maintainer should be in control of this process. >> > I understand the synchronisation adds friction to the overall >> > architecture and may be the cause of many problems in the future - >> > hence we are starting this discussion and using the technology >> > ourselves to catch these issues asap. Víťo, does this answer your >> > question? >> > >> > Miro, you are talking abo
Re: Is dist-git a good place for work?
Tomas Tomecek writes: > Thank you all for raising all the questions and concerns. > > Before I reply, I'd like to stress that we are still in a prototype > phase - not everything is solved (clearly) and at this point, we > experiment with the workflow mostly. > > Luckily, force-pushes are not allowed in dist-git, which makes the > update/sync process easier (knowing that history cannot be changed). > Therefore when a new commit lands in dist-git, we'd just "transform" > it to source-git and pushed it to the source-git repo. We could even > ask all the contributors to rebase their PRs when this happens. This "rebase all PRs" thing seems to be a recurring theme... What is the reason to ask contributors to rebase? (I mean, are we trying to go back to the days of centralized version control systems?) In my experience, there is rarely a good reason to rebase (rebasing because the CI system tests the contributor's branch rather than the resulting merge is not a good reason; the CI system should be fixed instead) and asking everyone to rebase just slows things down. Please let's not go down that road, if possible. Other than that, I like the idea of source git and I'm looking forward to using it, once the synchronization issues are resolved. Thanks for working on it. Ondřej Lysoněk > On the other hand, when a new commit lands in the source-git repo, we > could either transform and push to dist-git directly or open a PR. The > maintainer should be in control of this process. > I understand the synchronisation adds friction to the overall > architecture and may be the cause of many problems in the future - > hence we are starting this discussion and using the technology > ourselves to catch these issues asap. Víťo, does this answer your > question? > > Miro, you are talking about conflicts: I'd say that conflicts on the > git level are normal and git has solid tools to resolve them. For the > use case of 2 different people changes the same thing, we would treat > dist-git as the authoritative place and let the person in source-git > know about the conflict. But this can happen nowadays easily as well: > 2 different people can open the same PR or even push to dist-git > directly while only one would succeed. > > Petr, I should have probably stressed that our target is Fedora (or > even all Red Hat operating systems). Yes, there are hundreds of > distributions and we cannot solve their problems. We are open for > collaboration though - we cannot drive changes in distributions which > we don't know or use. > > > Tomas > > On Tue, May 5, 2020 at 8:56 AM Petr Pisar wrote: >> >> On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote: >> > Over the years there have been multiple tools created to improve the >> > development experience: >> > rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g. >> > the way Fedora kernel developers work on kernel [k]). >> > >> > In the packit project, we work in source-git repositories. These are >> > pretty much upstream repositories combined with Fedora downstream >> > packaging files. >> >> And then come another distribution with a request to combine its dist-git >> into >> the upstream. Fedora is not the only distribution. Do you know how many >> distributions exist? From my point of view as a upstream it's one big NO. >> >> From point of view of a Fedora packager, it's just moving Fedora bits into >> another repository with the burden of synchronizing that repository with >> dist-git (and back because of what an authoritative source for Fedora is). >> >> If you want to introduce an intermediary third repository between the >> upstream >> and the distribution, a repository that would normalize (read git-ify) the >> upstream and overlay downstream patches and metadata, then, ehm, it's a nice >> project for exploration how far we go with unification among the >> distributions. But I'm quite sceptical regarding it's adoption. But don't >> take >> my prognosis seriously. I can be mistaken. There are some positive prior arts >> like release-monitoring.org. >> >> -- Petr >> ___ >> 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@l
Re: Guile exception caught in /usr/lib/rpm/find-debuginfo.sh
Dan Čermák writes: > Hi list, > > I've just ran a mockbuild in Rawhide and the following output from > /usr/lib/rpm/find-debuginfo.sh caught my attention: > > --8<---cut here---start->8--- > /usr/lib/rpm/find-debuginfo.sh -j2 --strict-build-id -m -i --build-id-seed > 1.3-1.fc32 --unique-debug-suffix -1.3-1.fc32.x86_64 --unique-debug-src-base > ocaml-ppxfind-1.3-1.fc32.x86_64 --run-dwz --dwz-low-mem-die-limit 1000 > --dwz-max-die-limit 11000 -S debugsourcefiles.list > /builddir/build/BUILD/ppxfind-1.3 > explicitly decompress any DWARF compressed ELF sections in > /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind > extracting debug info from > /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind > Exception caught while booting Guile. > > /usr/bin/gdb.minimal: warning: Could not complete Guile gdb module > initialization from: > /usr/share/gdb/guile/gdb/boot.scm. > Limited Guile support is available. > Suggest passing --data-directory=/path/to/gdb/data-directory. > --8<---cut here---end--->8--- > > Is this known/an issue? Cross-referencing a bugzilla that has been filed for this: https://bugzilla.redhat.com/show_bug.cgi?id=1801144 Ondrej > > > Thanks in advance, > > Dan > > P.S.: I really hope this isn't my fault, as I've re-enabled Guile > support in gdb :-( > ___ > 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: psutter pushed to iproute (master). "iproute-5.3.0-2 (..more)"
Hi,
Phil Sutter writes:
> Hi,
>
> On Tue, Oct 08, 2019 at 01:23:01PM +0100, Tomasz Kłoczko wrote:
>> On Tue, 8 Oct 2019 at 12:58, wrote:
>>
>> > Notification time stamped 2019-10-08 11:54:56 UTC
>> >
>> > From 26d638db91fa316f706ea947ab076bce216ec8cc Mon Sep 17 00:00:00 2001
>> > From: Phil Sutter
>> > Date: Oct 08 2019 11:51:27 +
>> > Subject: iproute-5.3.0-2
>> >
>> >
>> > - ifcfg script uses killall, therefore requires psmisc package
>> >
>>
>> IMO that fix is fundamentally wrong.
>
> Thanks for the heads-up. Maybe Ondřej might tell us the reason for the
> new dependency (it was his pull-request I merged).
I just happened to run ifcfg on a system that did not have killall
installed and noticed an error message about killall missing. I don't
really have a use case for ifcfg; I just noticed a bug and fixed it.
ifcfg uses killall, so the iproute package must Require it. The fix is
obviously correct, not fundamentally wrong. Tomasz appears to be arguing
that systemctl should be used instead of killall, which is of course a
completely separate issue. Feel free to fix that upstream, Tomasz.
Regards,
Ondra
>
>> Instead using killall it should be used systemd to reload service
>> ("systenctrl reload rdisc").
>
> I guess users preferring to use ifcfg for interface configuration over
> NetworkManager also don't care about rdisc systemd unit.
>
>> Why? In case of using LXC or other containerisation ifcfg which will be
>> using killal and used from global zone/namespace will cause to reload
>> all rdisc (those running in containers as well).
>
> Is this a theoretical point or to you know of any real use-case where
> ifcfg is used? If so, what's the reason for not using nmcli?
>
>> Next is that rdisc is part of the iputils which is not listed in list of
>> iproure dependencies (I'm not sure is it correct to add that dependency but
>> seems it is legit).
>>
>> Other thing is that ifcfg script is bash dependent because
>>
>> $ grep -w local /usr/sbin/ifcfg
>> local sbase fwd
>> local class;
>
> So sounds like even more dependencies are required to be formally
> correct. Maybe this even justifies putting ifcfg (and probably other
> shell scripts as well) into a dedicated sub-package to not impose too
> many dependencies onto the core iproute package.
>
>> Those two lines can be removed without harming anything to make that script
>> full POSIX sh compliant (and still working correctly with bash as
>> /usr/bin/sh).
>
> Feel free to submit a patch upstream. Sadly these scripts are not very
> well maintained, probably just because hardly anyone uses them.
>
>> BTW. Looks like no one in Fedora have been looking on all cases like above
>> to have proper separation between zones/container/namespaces.
>
> Not just in Fedora, it seems. ;)
>
> Cheers, Phil
> ___
> 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: RFE: fedpkgdiff?
On 15. 02. 19 23:19, Richard Shaw wrote: > So in the case of all the FTBFS packages I'm working on instead of > having to manually download packages to some temporary directory from > koji or dnf command I could just do a "fedpkg mockbuild" on my proposed > fix and then "fedpkgdiff /path/to/new/package --dist fc30" and let it do > all the other steps for me, thus saving me a not insignificant amount of > work/time which I don't have a lot of since packaging isn't my dayjob. This would be really great. It's tedious to do it manually. Ondřej Lysoněk ___ 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: Brainstorming about kernel updates with low disk space
On 6.9.2018 16:44, Jason L Tibbitts III wrote: > * The kernel could "pre-allocate" space in /var/tmp (by %ghosting a > dummy nonzero-length file there) so that the package simply won't > install if there isn't space sufficient to generate the initramfs. > Would that be something we could reasonably do? > > This would result in the kernel package "owning" a file in /var/tmp > that doesn't exist. The name doesn't actually matter and the file > wouldn't actually be in the package. RPM would just ensure that > enough space would exist in /var/tmp before allowing the installation > to begin. FWIW, the name does matter. You'd have to ensure the name is as unlikely to collide with whatever anyone puts there as possible. Otherwise you could get a user file removed when the kernel is removed, right? Ondřej Lysoněk ___ 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
libevent License tags corrected
Hi, I reviewed the licensing of libevent and found the License tags to be incorrect. The License tag of libevent was changed from "BSD" to "BSD and ISC". The License tag of libevent-doc was changed from "BSD" to "BSD and MIT". Best regards Ondřej Lysoněk ___ 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: Making Fedora secure - Package exit policy for security
On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote: > I would like to propose the following: > > > 1. If a CRITICAL or IMPORTANT security issue is open against a package > in Fedora-X and by the time X is EOL and the issue is not addressed, > proactively remove the package from X+1 > 2. If a MODERATE or LOW security issue is open against a package in > Fedora -X and by the time X+! is EOL, the issue is not addressed, remove > it from X+2 > > Note: > 1. Once pkg is patches, it can be rebuild and re-introduced into the distro > 2. X/X+1 is the best boundary to remove the insecure packages imo, since > inbetween removals are not possible due to the way mirrors work. > 3. Maintain a list somewhere (automated maybe) of the list of packages > removed and why. > 4. Have a list of critical pkg, which cannot be removed which will break > the distro. Please make sure the process takes into account the fact that packages may be affected by CVEs in certain Fedora releases only. For example an older version of a package in F27 is affected by a CVE, but a new (rewritten) version in F28 is not. It seems the summary of CVE bugs accordingly contains either the string "[fedora-all]", or "[fedora-27]", "[fedora-28]" etc. Hopefully that is a reliable source of information. Best regards Ondřej Lysoněk ___ 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/JXQVT55SMOKIMYT6T5BX3CDAXORNQLLG/
License tags of i2c-tools corrected
I reviewed the licensing of i2c-tools and found the License tags to be inaccurate. I changed the tags as follows. i2c-tools-eepromer subpackage: License tag changed from GPLv2+ to GPLv2+ and Public Domain python3-i2c-tools subpackage: License tag changed from GPLv2+ to GPLv2 Best regards Ondřej Lysoněk ___ 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/DJBOQODKASLQMKN5SFPCOEADBM52AGFX/
License tag of minicom corrected
I've reviewed the licensing of minicom and found the License tag to be inaccurate. I changed the License tag from: GPL+ and GPLv2+ and GPLv2 and LGPLv2+ Public Domain and Copyright only to: GPLv2+ and LGPLv2+ and Public Domain The license tag was only made less strict, so it shouldn't cause any problems. -- Ondřej Lysoněk ___ 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/ZWQW4VQH53FJXUVKAEWHNN4PMWACIHQZ/
License tags of lm_sensors corrected
Hi, I've reviewed the licensing of lm_sensors and found the License tags to be incorrect, so I corrected it. Previously the License tags of all the subpackages was: LGPLv2+ and GPLv3+ and GPLv2+ and Verbatim and Public Domain Now the License tags read as follows. lm_sensors: GPLv2+ and Verbatim and MIT lm_sensors-devel: LGPLv2+ and Verbatim lm_sensors-libs: LGPLv2+ lm_sensors-sensord: GPLv2+ and Verbatim and MIT The actual license of the package did not change in the recent past, only the License tags were corrected. Best regards Ondřej Lysoněk ___ 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/IP5TCABYTHHNRCSESVUDW4X6FQ3WUKBB/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, On 18.6.2018 15:27, Lennart Poettering wrote: > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote: > >> The cited BLS spec is the original one, not the more thoroughly >> discussed and thought through variant by Matthew Garrett [1] some >> years ago. > > Quite frankly, as one of the authors of the original BLS spec, I can'd > say Matthew's version was much discussed with me... > > I mean, I am open to extending the spec, but we should do this bit by > bit. > > Zbigniew suggested to move the spec into docbook or markdown format, > and then accept changes via usual github PRs. If there's interest > still in extending the spec with some of Matthew's ideas we can > certainly look into that, but in general I'd actually prefer to reduce > the size of the spec if possible, and drop as many bits of it as we > can, i.e. the stuff noone implements anyway. It would be great if we could extend the spec with optional support for multiple initrd images (the Tuned daemon depends on that). Fedora's GRUB2 already supports multiple initrd images (it allows specifying multiple lines with the "initrd" key), but I'd like to make sure that whoever implements BLS in the future and decides to support multiple initrds will not choose a different syntax for it. Would you be open to extending the spec with that? Thanks. Best regards Ondřej Lysoněk ___ 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/UPTBATX3EUGUJFEDQS4DDHB7GSVI5BA5/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, On 14.6.2018 12:06, Jan Kurik wrote: > = Proposed System Wide Change: Make BootLoaderSpec the default = > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault > > > Owner(s): > * Javier Martinez Canillas > * Peter Jones > > > Use BootLoaderSpec fragment files by default to populate the > bootloaders boot menu entries. > > > > == Detailed description == > The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ > Boot Loader Specification (BLS)] defines a scheme and file format to > manage boot loader configuration for each boot option in a drop-in > directory, without the need to manipulate bootloader configuration > files. These drop-in directories are the standard on Linux nowadays, > so the goal is to also extend this concept for boot menu entries. > This is especially important in Fedora because the same bootloader is > not used in all architectures. GRUB 2 is used in most of them, but > there are others such as zipl for s390x and Petitboot for ppc64le. Not > all bootloaders have the same configuration file format, so there is a > need for an indirection level and per bootloader specific logic to > edit these configuration files, when adding or removing a boot entry. > The current component that does this work is grubby, that has support > for all the different bootloader configuration file formats and > manipulates them on kernel installation or uninstallation. Besides > manipulating the bootloader configuration files, grubby also does > other things like running dracut to create an initial ramdisk image. > Fedora already has a lot of infrastructure in place to not require > modifying bootloader configuration files for boot menu entries. The > BootLoaderSpec and drop-in BLS fragments can be used instead, and the > kernel-install script can do any additional task that is currently > done by grubby. The kernel-install script has a pluggable design that > uses a drop-in directory for scripts to extend its functionality. So > if needed, any bootloader specific logic can be implemented as > kernel-install scripts. > With this setup the bootloader configuration could be static and not > modified after installation. > The missing piece was the lack of BLS support on all the supported > bootloaders, but all of them have support to parse BLS fragments now. > So we can default to install BLS files on kernel installation and drop > grubby. I noticed the official spec defines a field named "machine-id". AFAICS, GRUB2 doesn't implement that option, but it supports a field named "id". Are these used for the same thing? If they are, why are they named differently? I also have a question regarding interoperability with distros which do not support BLS. Suppose I install Fedora with BLS enabled and then beside that install some distro which doesn't support BLS. The second distro will probably install its own bootloader. Will I be able to boot Fedora from the bootloader installed by the second OS? Thanks. Best regards Ondřej Lysoněk ___ 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/JA5JQNKSVKMP5ECYSGVTN656IA3VC67C/
Re: Summary/Minutes from today's FESCo Meeting (2018-06-01)
On 1.6.2018 22:35, Dennis Gilmore wrote: > Meeting summary > --- > * init process (dgilmore, 15:01:00) > > * #1901 F29 System Wide Change: Perl Move to MetaCPAN (tyll, 15:06:28) > * LINK: https://pagure.io/fesco/issue/19011 (tyll, 15:06:34) > * AGREED: accept F29 System Wide Change: Perl Move to MetaCPAN (+6, > 0, > -0) (tyll, 15:10:00) > > * #1899 F29 System Wide Change: Move /usr/bin/python into a separate > package (tyll, 15:10:54) > * LINK: https://pagure.io/fesco/issue/18999 (tyll, 15:10:59) > * AGREED: accept F29 System Wide Change: Move /usr/bin/python into a > separate package (+7, 0, -0) (tyll, 15:29:55) > > * #1898 F29 System Wide Change: The tzdata transition to (dgilmore, > 15:30:50) > * LINK: https://pagure.io/fesco/issue/18988 (dgilmore, 15:30:57) > * AGREED: accept F29 System Wide Change: The tzdata transition to > 'vanguard' format (+7, 0, -0) (dgilmore, 15:32:45) > > * #1897 F29 System Wide Change: Perl 5.28 (dgilmore, 15:32:53) > * LINK: https://pagure.io/fesco/issue/18977 (dgilmore, 15:32:58) > * AGREED: accept F29 System Wide Change: Perl 5.28 (+7, 0, -0) > (dgilmore, 15:35:56) > > * #1893 Non-responsive maintainer for libinvm-i18n,libinvm-cli, > (dgilmore, 15:36:16) > * LINK: https://pagure.io/fesco/issue/18933 (dgilmore, 15:36:22) > * ACTION: bowlofeggs to follow up on devel@ (dgilmore, 15:37:12) > * AGREED: bowlofeggs to buy everyone 🍩, followup on devel@ and then > look at again next week (dgilmore, 15:38:26) > * AGREED: bowlofeggs to buy everyone 🍩, followup on devel@ and then > look at again next week (+7, 0, -0) (dgilmore, 15:38:54) > * AGREED: bowlofeggs to buy everyone 🍩, followup on devel@ and then > look at again next week (+7, 0, -0) (dgilmore, 15:39:10) All the links are broken. The last digit is doubled in each of them for some reason. Best regards Ondřej Lysoněk ___ 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/5AXQR2SFJLLX6HGBSXWQPZZJ5TNRO63W/
Re: Kernel updates breaking grub configuration with tuned
On 28.3.2018 20:58, Christopher wrote: > So, I've been seeing this problem recently where every time I update the > Fedora kernel (currently F27), my grub configuration gets mangled. > > I have tuned installed, so it has installed /etc/grub.d/00_tuned, which > executes /etc/tuned/bootcmdline, which in turn spits out when > grub2-mkconfig is run. > > ### BEGIN /etc/grub.d/00_tuned ### > set tuned_initrd="" > set tuned_params="skew_tick=1" > ### END /etc/grub.d/00_tuned ### > > However, every time I update the F27 kernel, it mangles the params line, > to something like: > > set tuned_params="skew_tick=1"=1"=1"=1"=1" Thanks for bringing this up. The issue has already been reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1509515 Best regards Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Configuration file migration without scriptlets
Hi, is there any mechanism in Fedora for config file migration? How would you make changes to a configuration file (maybe after some config option has been renamed), or move a config file to a new location, during upgrade? Is there a better way than running 'sed' and 'cp' in a scriptlet? Thanks. Best regards Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Dropping i2c-tools-devel, introducing libi2c and libi2c-devel
On 27.11.2017 15:47, Ondřej Lysoněk wrote: > According to dnf (dnf repoquery --enablerepo=rawhide --alldeps > --whatrequires i2c-tools-devel), there are currently no packages > requiring the removed i2c-tools-devel. Yeah, so I just realized that the repoquery was wrong, I should have queried for BuildRequires, because it's a header-only library. But the following gives nothing nonetheless: dnf repoquery --repo=rawhide --arch src --alldeps --whatrequires i2c-tools-devel Ondra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Dropping i2c-tools-devel, introducing libi2c and libi2c-devel
Hi,
I'm rebasing i2c-tools to 4.0 in Rawhide (F28) and the rebase involves
dropping the i2c-tools-devel subpackage and introducing libi2c and
libi2c-devel. The change will happen only in F28.
For a long time, i2c-tools bundled their own version of
/usr/include/linux/i2c-dev.h which, compared to the kernel version of
the file, additionally contained definitions from and
inline functions i2c_smbus_*() taken from the kernel.
Until recently, i2c-tools in Fedora did not include the i2c-dev.h file,
probably because of the name collision. Recently, upon request, I
included the header file in a new i2c-tools-devel subpackage in a
separate subdirectory /usr/include/i2c-tools. However upstream now came
with their own solution of the problem: they eliminated the differences
between the different versions of and put the
i2c-tools specific stuff to a proper shared library libi2c.so and
header file.
So in order to follow upstream, I'm now dropping the i2c-tools-devel
package containing the i2c-dev.h file and introducing libi2c{,-devel}
containing libi2c.so and .
Applications using libi2c in Fedora should now use:
#include
#include
instead of:
#include
and link with '-li2c'. The API remains compatible however.
More information at
https://i2c.wiki.kernel.org/index.php/Plans_for_I2C_Tools_4
According to dnf (dnf repoquery --enablerepo=rawhide --alldeps
--whatrequires i2c-tools-devel), there are currently no packages
requiring the removed i2c-tools-devel. I already pushed the rebased
i2c-tools to dist-git and I'll build it on Monday 2017-12-04.
Best regards
Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildError: src.fedoraproject.org:/git/rpms/mingw-gdal is not in the list of allowed SCMs
On 24.10.2017 18:38, Sandro Mani wrote: > Any ideas about this one? > > $ fedpkg build > Building mingw-gdal-2.2.2-3.fc28 for rawhide > Created task: 22673795 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=22673795 > Watching tasks (this may be safely interrupted)... > 22673795 build (rawhide, > /git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open > (buildvm-armv7-13.arm.fedoraproject.org) > 22673796 buildSRPMFromSCM > (/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): free > 22673795 build (rawhide, > /git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open > (buildvm-armv7-13.arm.fedoraproject.org) -> FAILED: BuildError: > src.fedoraproject.org:/git/rpms/mingw-gdal is not in the list of allowed > SCMs > 1 free 0 open 0 done 1 failed > 22673796 buildSRPMFromSCM > (/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): free -> > FAILED: BuildError: src.fedoraproject.org:/git/rpms/mingw-gdal is not in > the list of allowed SCMs > 0 free 0 open 0 done 2 failed > > Also happens if a do a fresh fedpkg clone of mingw-gdal. So this was caused by an update of fedpkg available in updates-testing. See: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9cac2b8b4a https://bugzilla.redhat.com/show_bug.cgi?id=1188634 Downgrading fedpkg should fix the problem. Best regards Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildError: src.fedoraproject.org:/git/rpms/mingw-gdal is not in the list of allowed SCMs
On 24.10.2017 18:38, Sandro Mani wrote: > Any ideas about this one? > > $ fedpkg build > Building mingw-gdal-2.2.2-3.fc28 for rawhide > Created task: 22673795 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=22673795 > Watching tasks (this may be safely interrupted)... > 22673795 build (rawhide, > /git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open > (buildvm-armv7-13.arm.fedoraproject.org) > 22673796 buildSRPMFromSCM > (/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): free > 22673795 build (rawhide, > /git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open > (buildvm-armv7-13.arm.fedoraproject.org) -> FAILED: BuildError: > src.fedoraproject.org:/git/rpms/mingw-gdal is not in the list of allowed > SCMs > 1 free 0 open 0 done 1 failed > 22673796 buildSRPMFromSCM > (/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): free -> > FAILED: BuildError: src.fedoraproject.org:/git/rpms/mingw-gdal is not in > the list of allowed SCMs > 0 free 0 open 0 done 2 failed > > Also happens if a do a fresh fedpkg clone of mingw-gdal. Anybody? I have the same problem with vsftpd. Thanks Ondra ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer: jcapik
On 9.10.2017 09:24, Ondřej Lysoněk wrote: > I'd like to start the non-responsive maintainer process for Jaromir > Capik (jcapik). I filed a FESCO ticket: https://pagure.io/fesco/issue/1786 Best regards Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Non-responsive maintainer: jcapik
Hi, I'd like to start the non-responsive maintainer process for Jaromir Capik (jcapik). I've been trying to contact him through a bugzilla, but haven't received a reply in over two weeks: https://bugzilla.redhat.com/show_bug.cgi?id=1494142 I also attempted to contact him directly using email on 2017-09-01 and then on 2017-09-13, but I didn't receive a reply. It appears he hasn't been active in Fedora in a while. According to fedora-active-user [1], the last time he updated any of his packages was 2016-08-21. Anyone knows how to contact him? Thanks. [1] https://github.com/pypingou/fedora-active-user -- Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] sendmail-devel will be renamed to sendmail-milter-devel
Hi,
after some investigation, I think you are right :). Thanks! I fixed it
and a new version sendmail-8.15.2-9.fc26 is currently being built.
Regards
Ondra
On 08/05/2016 12:14 PM, Paul Howarth wrote:
Hi,
On 29/07/16 14:26, Ondřej Lysoněk wrote:
Hi,
on Friday, August 5, I will rebuild the sendmail package for rawhide,
because of a rename of sendmail-devel to sendmail-milter-devel. This is
due to [1]. Please change BuildRequires and Requires of your packages
accordingly.
List of know affected packages:
clamav
milter-greylist
milter-regex
mimedefang
opendkim
opendmarc
python-pymilter
spamass-milter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=891288
I think you may have made a mistake with the obsoletes/provides for the
upgrade path.
You have:
Provides: sendmail-devel%{?_isa} = %{version}-%{release}
Obsoletes: sendmail-devel%{?_isa} < 8.15.2-8
I think it should be:
Obsoletes: sendmail-devel < 8.15.2-8
Provides: sendmail-devel = %{version}-%{release}
Provides: sendmail-devel%{?_isa} = %{version}-%{release}
Obsoletes: works on package names, not the virtual provides that include
%{?_isa}. And the provides should include the version with and without
the %{?_isa}, since that's what the original package provided and either
might be used by existing packages.
Cheers, Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] sendmail-devel will be renamed to sendmail-milter-devel
Hi,
this change is indeed happening only in F26 and later. There are no
plans to do the rename in earlier releases.
However, I'm not sure where the "0%{?rhel} > 7" condition in your spec
sample came from. I have no idea when the rename will get to RHEL, and I
would definitely warn about such a change.
Ondřej Lysoněk
On 08/05/2016 04:53 PM, Paul Howarth wrote:
Hi Steve,
On 05/08/16 15:37, Steve Jenkins wrote:
On Fri, Jul 29, 2016 at 6:26 AM, Ondřej Lysoněk mailto:olyso...@redhat.com>> wrote:
Hi,
on Friday, August 5, I will rebuild the sendmail package for
rawhide, because of a rename of sendmail-devel to
sendmail-milter-devel. This is due to [1]. Please change
BuildRequires and Requires of your packages accordingly.
List of know affected packages:
clamav
milter-greylist
milter-regex
mimedefang
opendkim
opendmarc
python-pymilter
spamass-milter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=891288
<https://bugzilla.redhat.com/show_bug.cgi?id=891288>
Hi, Ondrej. I package both opendkim and opendmarc, which are on your
list. I maintain both packages for all current Fedora and EPEL distros
(F23+, EL5-7)
To confirm, which versions of Fedora / RHEL will this rename affect?
Only F25+? Just trying to figure out how to re-write my BuildRequires
lines properly.
Only Rawhide (F26) has changed (Ondřej, please let us know if there are
any plans to make this change anywhere else).
I have updated milter-greylist, milter-regex and spamass-milter using
something like this:
# Milter header files package name
%if 0%{?fedora} > 25 || 0%{?rhel} > 7
%global milter_devel_package sendmail-milter-devel
%else
%global milter_devel_package sendmail-devel
%endif
BuildRequires: %milter_devel_package
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[HEADS UP] sendmail-devel will be renamed to sendmail-milter-devel
Hi, on Friday, August 5, I will rebuild the sendmail package for rawhide, because of a rename of sendmail-devel to sendmail-milter-devel. This is due to [1]. Please change BuildRequires and Requires of your packages accordingly. List of know affected packages: clamav milter-greylist milter-regex mimedefang opendkim opendmarc python-pymilter spamass-milter [1] https://bugzilla.redhat.com/show_bug.cgi?id=891288 -- Ondřej Lysoněk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Ondřej Lysoněk
Hi, my name is Ondřej Lysoněk and I am a new intern in the development team at Red Hat in Brno, Czech Republic. I'm 21 and I'm currently studying at the Faculty of Informatics, Masaryk University. Formerly I worked in a QA team, also at Red Hat. Ondřej Lysoněk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
