Re: GenericError: srpm mismatch for [debuginfo file]
On Wed, May 29, 2024 at 05:27:18PM +0200, Michal Domonkos wrote: > I might have missed some so apologies to those folks, please resubmit them at > your discretion. Just a note: For one, I skipped over those build that were done against a side tag, to avoid messing up somebody's work-in-progress. -- Michal Domonkos / RPM / Red Hat, Inc. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On Wed, May 29, 2024 at 02:38:59PM +, Zbigniew Jędrzejewski-Szmek wrote: > Do you plan to submit rebuilds for the failed packages are should > packagers do that individually? Yes, I just went through the failed builds from today and restarted those that were "almost" successful (i.e. were actually built) but just failed in Koji with the known "GenericError: srpm mismatch ..." error, namely: composefs https://koji.fedoraproject.org/koji/taskinfo?taskID=118243204 boost https://koji.fedoraproject.org/koji/taskinfo?taskID=118243374 xpdfhttps://koji.fedoraproject.org/koji/taskinfo?taskID=118243422 initscripts https://koji.fedoraproject.org/koji/taskinfo?taskID=118243434 glibc https://koji.fedoraproject.org/koji/taskinfo?taskID=118243459 scipy https://koji.fedoraproject.org/koji/taskinfo?taskID=118243758 I might have missed some so apologies to those folks, please resubmit them at your discretion. Thanks, -- Michal Domonkos / RPM / Red Hat, Inc. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On Wed, May 29, 2024 at 12:38:31PM +0100, Richard W.M. Jones wrote: > It failed right at the end with this mysterious error: > > GenericError: srpm mismatch for > /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: > (none) (expected ocaml-5.2.0-1.fc41.src.rpm) OK, this should be fixed now: https://bodhi.fedoraproject.org/updates/FEDORA-2024-0cdd01deef We've been anxiously counting every minute here while the Fedora CI was taking its time to progress through the large test-suite. Sorry for the inconvenience again! Cheers, -- Michal Domonkos / RPM / Red Hat, Inc. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 05:10:24PM +0100, Aoife Moloney wrote: > == Summary == > > The Red Hat Display Systems Team (which develops the desktop) proposes > to enable limited data collection of anonymous Fedora Workstation > usage metrics. One thing to realize here is that, no matter what collection method will be used and how well it will be secured against potential malicious actors, the reputation of Fedora *will* be harmed or at least tainted. And it won't be easy to undo that. Even if we end up using mathematically sound techniques as per Differential Privacy (as I suggested in my other reply), most user won't know/realize that and will only see the words "telemetry" and "Fedora" alongside each other in all those discussions and articles that will inevitably pop up as a result of this change. I think the reputation of Fedora as a project shouldn't be taken lightly, regardless of the actual implementation, and should be weighted against the benefits that it would bring to the project. I'd say a huge portion of the user base in Fedora consists of technical people who actively despise the notion of any kind of "phone home" mechanism on their system (me included), and for good reason. It's also evidenced by this thread so far. The problem, as noted in this thread multiple times, is that if we make this opt-in, the usefulness would decrease to almost it being irrelevant. If we make it opt-out, all the above applies (IMHO). Consider that even those big software companies couldn't prevent their products from getting the bad reputation, despite some of them reportedly using Differential Privacy (!). -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 08:08:05PM -0500, Michael Catanzaro wrote: > ... that would be sad since it would mean more work for me, but > we're still at the point where that's possible. (I'd *much* rather make > changes to the existing system to adapt it to our needs, though. :) Oh, and I didn't mean to suggest adding more work or reworking your existing plans, don't get me wrong :) And absolutely, using an *existing* (and tried) system and adapting that to our needs sounds like a much better idea than scratching all your plans and looking for something else, especially if that *something* isn't even that obvious. -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 08:08:05PM -0500, Michael Catanzaro wrote: > But remember we do not want to keep information about individuals in the > data set in the first place. It's easier to dodge privacy concerns if we > just don't store such associations at all. Sure, but the data still needs to leave a user's system at some point and that's where you have to trust the aggregator (the Fedora project in this case, I suppose) that it's not stored verbatim. Or, apply a DP technique locally, before it leaves the system. Randomized response, which you mentioned, is actually one such technique. In a way, you already trust the distribution by the very nature of it, e.g. the signatures in packages you install. DP just provides a framework in which you can formally quantify the risk of de-masking an individual user from a given data set, and concrete strategies to employ to minimize that risk. Actually this exact problem is discussed in the blog post series I shared, specifically in this part: https://desfontain.es/privacy/local-global-differential-privacy.html > As for differential privacy, I'm quite unfamiliar with this topic so I don't > know to what extent it could be useful, but Endless is interested in adding > randomized response [1], where say 50% of the data sent is fake and the > other half is accurate. This only works for boolean and possibly integer > data, but it would make it even harder to deanonymize reporterd data. But > that is not supported yet. Indeed, randomized response is one of the DP-aware techniques (it's also mentioned in that blog series) :) And RAPPOR is basically just randomized response but generalized to arbitrary strings (using this fancy thing called Bloom filters [1]). > I will add that to my reading list. Certainly it seems a lot less > intimidating than the Wikipedia article. ;) Yup, the Wikipedia article isn't very helpful. There are much better resources, including a bunch of talks on YouTube from the researchers themselves (e.g. Cynthia Dwork). > Wow. I'll add this to my reading list too, although remains to be seen > whether I'll be able to understand it. :D Yeah, the RAPPOR paper is an interesting read but pretty dense and math-heavy (although not as much as it might seem at first glance). I did *try* to read it at some point and actually managed to understand the key concepts which aren't *that* complicated. But I can't blame anybody for not wanting to go down that path after they skim through it and see those formulas and charts, really :D I went into this DP rabbit hole myself when I was working on the DNF Countme [2] implementation a few years back, and even if it wasn't directly applicable in the end, it did inspire me to add a form of "randomized response" there, to spread the countme events from a single system randomly across a week's time window so that no usage patterns of that particular system (e.g. the typical uptime hours) could emerge if someone were to inspect the HTTP requests with the countme flag coming from the same system aggregated over a long period of time. Pretty theoretical and, in retrospect, rather unlikely and paranoid, but it was easy to add that logic so I did, just for the peace of mind :) I haven't kept up with the latest developments in DP since then, though, and have blissfully forgotten most of it, too. But it sparked my interest back then and I certainly thought that if Fedora ever decides that it wants some kind of "telemetry", *this* is the (only acceptable) way to do it. Which doesn't mean there aren't other ways, or that the approach taken by Endless (which you'd like to adopt) is wrong, of course. These were just my 2 cents :) FWIW, it seems like various tech companies and software project make use of DP (at least that's what the Wikipedia article claims). Google Chrome and MS Windows are among those, amusingly, despite their reputation. [1] https://en.wikipedia.org/wiki/Bloom_filter [2] https://fedoraproject.org/wiki/Changes/DNF_Better_Counting -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 11:33:03PM +0200, Michal Domonkos wrote: > changes, but there's a formal research area called Differential Privacy [1] Oops, forgot the link: [1] https://en.wikipedia.org/wiki/Differential_privacy -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 05:10:24PM +0100, Aoife Moloney wrote: > == Summary == > > The Red Hat Display Systems Team (which develops the desktop) proposes > to enable limited data collection of anonymous Fedora Workstation > usage metrics. Given the detailed proposal, it's probably too late now for any fundamental changes, but there's a formal research area called Differential Privacy [1] that deals with the collection of user data in such a way that it preserves the privacy of each participating individual. Have you guys, by any chance, considered looking into that for some inspiration? Either way, if anyone is curious, there's a nice and easy-to-read write up on the key concepts: https://desfontain.es/privacy/differential-privacy-awesomeness.html A specific set of algorithms (RAPPOR) for collecting arbitrary user strings that preserves Differential Privacy has been proposed (and implemented) by Google a while back, too: http://arxiv.org/abs/1407.6981 https://github.com/google/rappor -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Towards enabling rpm sysusers integration
On Sat, Jun 24, 2023 at 01:22:22AM +, Zbigniew Jędrzejewski-Szmek wrote: > I don't think so. Either way, the actual implementation is going to be a call > to > systemd-sysusers. But the rpm-internal approach is quite different in how the > call is constructed from the macro-based approach, so the failure modes are > likely to be different. If were to switch to the macro-based approach > temporarily, we'd create quite a lot of churn and _different_ failure modes. > So > I think that if we're switching to sysusers as the implementation, we should > go > for the intended final approach immediately. My thinking was that the failure modes would then be limited to the switch to systemd-sysusers only so we wouldn't have to debug two new implementations (systemd-sysusers and RPM's integration) but just one (systemd-sysusers). That said, having slept on it, I agree that such a two-staged approach would just make things needlessly more chaotic. Just switching the whole thing as proposed is going to be simpler, yup :) -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Towards enabling rpm sysusers integration
On Thu, Jun 22, 2023 at 01:18:27PM +0300, Panu Matilainen wrote: > Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's > time to start looking towards enabling the sysusers integration: > https://rpm-software-management.github.io/rpm/manual/users_and_groups.html [...] > 3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased > out. As it'll be a long time before the sysusers feature is in all Fedora > versions, it needs a longer term plan. One simple possibility is do what was > done with all those ldconfig from %post back then: change the %sysusers_() > macros to no-ops in rawhide to let rpm handle it, and only actually bother > updating packages once all relevant versions have the sysusers feature. This proposal would effectively move all existing packages that create users or groups from useradd/groupadd (called by those %sysuser* macros underneath) to systemd-sysusers(8). I wonder if we shouldn't first just move those macros over to systemd-sysusers to test-drive this utility at a larger scale and catch any potential bugs or issues before actually proceeding with the remaining steps as outlined in the email. That's a lower-risk first step that should be fairly easy to implement right away, as mentioned in: https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Thu, May 25, 2023 at 09:43:30PM +0200, Michal Domonkos wrote: > It did show up on my original list, I just omitted it from the email because I > was going to ask my team to do the rebuild (as I thought we owned it). We also completely forgot about it (that, and scl-utils) before pushing the side-tag to stable, which is why it just wasn't rebuilt in the first place :) -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Thu, May 25, 2023 at 10:18:25AM -0700, Adam Williamson wrote: > I've no idea why it didn't show up in either version of the list, but > deltarpm should have been on there: It did show up on my original list, I just omitted it from the email because I was going to ask my team to do the rebuild (as I thought we owned it). Earlier today, I checked and it turned out I was wrong about the ownership so I went ahead and asked Petr Pisar to do that (he's a provenpackager and handled most of the other rebuilds already). > I'm rebuilding it... Thank you, I'm going to tell Petr to skip that one then :) -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 10:59:17PM +0200, Michal Domonkos wrote: > shows a couple of additional packages that weren't covered in this thread so > far: > > fastfetch > gcc > gdb > grub2 > grubby > javapackages-bootstrap > ocaml-dose3 > sblim-cmpi-rpm > xmvn-generator Looking briefly at some of these packages, they do BuildRequire rpm-devel but then not actually produce any binary or library that would link to RPM libs. This can be due to missing SPEC conditionals or some niche use case in the respective SPEC. Nevertheless, I just did scratch builds of all of these packages except GCC against the f39-build-side-67564 target and they built successfully. GCC seems to be a rather long build so I cancelled that one, to avoid needlessly straining the infrastructure. -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 10:05:54PM -, Reon Beon via devel wrote: > Will we see this in Fedora 38 or the next version? Fedora 39: https://fedoraproject.org/wiki/Changes/RPM-4.19 -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 05:37:06PM +0100, Richard W.M. Jones wrote: > Nevertheless I do believe if the librpm changed its API then every > package which _BuildRequires_ rpm-devel should be rebuilt, just to > check the change doesn't affect them. Yes, we were primarily focusing on runtime dependencies now so that Rawhide isn't broken when the side-tag is pushed, however any API incompatibility in the packages that BuildRequire rpm-devel would just be pushed back to the earliest moment they're rebuilt in Rawhide by their maintainers. So I also think that ideally we should try rebuilding those ourselves to identify potential issues while 4.19 is not yet in Rawhide. I'll talk to my team on Monday, we'll perhaps do just that. A quick check with dnf repoquery --release=rawhide --disablerepo="*" --enablerepo="*-source" \ --arch=src --whatrequires rpm-devel shows a couple of additional packages that weren't covered in this thread so far: fastfetch gcc gdb grub2 grubby javapackages-bootstrap ocaml-dose3 sblim-cmpi-rpm xmvn-generator -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 06:44:16PM +0200, Petr Pisar wrote:
> I rebuild most of the packages
> <https://fedoraproject.org/wiki/Changes/RPM-4.19#Current_status>
Thank you! Much appreciated.
> I left out:
>
> freeipa - upstream confirmed that no ebuild is needed
Yup, nice find.
> rust-rpm-sequoia - I believe there is no dependency on rpm and no rebuild
>is needed. Can Michal explain why it is on his list?
This one got there by accident, please ignore it. Our original query consisted
of --qf '%{sourcerpm}' --whatrequires 'librpm*.so.*' which obviously matches
librpm_sequoia.so, too, and that one's required by rpm-sequoia-devel, which in
turn is a binary package built from rust-rpm-sequoia, hence showing on the
original list.
> rpm-git-tag-sort-1.0-12.fc39 - fails to build for in unrelated reaon.
>I have developed a fix and proposed it the
>package maintainer and to the upstream.
>I can apply it if there will be no action.
OK, sounds good. Yeah, I noticed the failure too when doing a scratch build
but didn't have the capacity to investigate further, hoping the maintainer
would eventually get it sorted. If we could speed that up by proposing a fix,
that's great, of course, so thank you!
> annobin - a racing update: annobin-12.10-2.fc39
> gnome-software - a racing update: gnome-software-44.1-2.fc39
> systemtap - a racing update: systemtap-4.9-1.fc39
Actually, gnome-software has been rebuilt for our side-tag:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2203034
--
Michal Domonkos / RPM dev team / Red Hat, Inc.
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 02:14:31PM +0200, Miro Hrončok wrote: > That is correct, I assumed folks on the packaging-team would be > provenpackagers already, but apparently not so much. Too many (false) assumptions were made when I was starting this thread. One learns by doing, I guess. > > I think I even tried that with the koji CLI tool at some point and got an > > error, however now that you asked, I tried again with fedpkg, and indeed, it > > looks like I'm able to build others' packages. > > You are. > > > Still not sure if I can in fact push to dist-git... > > You cannot. You need a provenpackager. Thanks. This was also confirmed by Petr Pisar in the meantime. > If you don't have any, I suggest you contact one (e.g. me). It's quite faster > and easier when the rebuild is swift rather than waiting (for how long?) for > everybody to do the builds themselves. Thanks for the offer, it seems like Petr has volunteered to do this for us, though, so the rebuilds are already on the way. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 01:03:43PM +0100, Richard W.M. Jones wrote: > I think you should also consider packages that build require > rpm-devel. libguestfs consumes the librpm API, so I'm not sure why it > didn't make the list. Correct, our original query was anything but comprehensible, as it turns out. Sigh. It didn't include the non-x86_64 arches and it didn't include rpm-libs, as you noted (also not sure why it libguestfs wasn't picked up by the soname-based query, though). Doing all the above yields 3 additional packages: freeipa libguestfs s390utils > Anyway I will rebuild supermin & libguestfs into the side tag shortly. Thanks! ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 12:28:30PM +0200, Dan Horák wrote: > I guess the list comes from an x86 system, thus it is incomplete. > Please add s390utils there as well. Indeed. I'm going to sent a separate email to s390utils-maintain...@fedoraproject.org. I've just ran the same DNF query for the other arches (s390x, aarch64 and ppc64le) to double-check, and there are no additional packages besides this one. I guess we should check all the arches next time. Noted. Thanks for noticing, Dan! -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 12:33:41PM +0200, Miro Hrončok wrote: > > rust-rpm-sequoia > > This has a circular dependency on rpm? Yup, this shouldn't have been on the list, it was an error on my side, addressed in another reply to this thread. > > We already did scratch builds ourselves and the packages passing against the > > rawhide target also passed against the side-tag. > > Could you please submit the real builds yourselves as well? We assumed we wouldn't be able to push & build packages that we don't own, and thought you'd have to a Proven Packager to be able to do that. I think I even tried that with the koji CLI tool at some point and got an error, however now that you asked, I tried again with fedpkg, and indeed, it looks like I'm able to build others' packages. Still not sure if I can in fact push to dist-git - is there a way to verify that without actually pushing anything? I've tried doing a "git push --dry-run" and that seemed to pass just fine... -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 01:05:51PM +0200, Fabio Valentini wrote: > Thanks for the clarification! No problem, and again, thanks for bringing it up. I should've included the whole list from the start to avoid confusion :) -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 01:00:28PM +0200, Michal Domonkos wrote: > Yup, I omitted the DNF stack deliberately from the original list as those > packages we've rebuilt ourselves already in the side-tag. Same goes for some > other packages on the list like drpm which we also own. Oh, and as for abrt* and rpminspect, those actually needed patching in order to adapt them to the API/ABI changes in RPM 4.19 which we also already did (submitted upstream) so those are also intentionally left out of the list. -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri, May 19, 2023 at 12:46:08PM +0200, Fabio Valentini wrote:
> Notably, this list includes things like libdnf and dnf5, and does
> *not* include rust-rpm-sequoia.
Yup, I omitted the DNF stack deliberately from the original list as those
packages we've rebuilt ourselves already in the side-tag. Same goes for some
other packages on the list like drpm which we also own.
As for rust-rpm-sequoia, indeed, that one got onto the list by accident. In
fact, the query we used was similar to yours, it just incorporated globs and
some additional sed filtering:
$ repoquery --whatrequires "librpm*.so*" --qf "%{source_name}" \
| sed -e 's/-[^-]*-[^-]*[.]rpm//' | sort -u
I guess the wildcards in there caused rpm-sequoia to show up too.
Thanks for noticing!
--
Michal Domonkos / RPM dev team / Red Hat, Inc.
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
HEADS UP: RPM 4.19 soname bump in Rawhide
Hi all, We're currently preparing an update to RPM 4.19 ALPHA for Rawhide in a side-tag. The new version features a soname bump: librpm.so.9 -> librpm.so.10 librpmio.so.9 -> librpmio.so.10 The following packages link against the above libraries and thus will need to be rebuilt: anaconda annobin fapolicyd frr gnome-software libappstream-glib libdnf-plugin-swidtags libextractor libzypp net-snmp openscap PackageKit perl-RPM2 perl-RPM-VersionCompare php-pecl-rpminfo rpm-git-tag-sort rpm-ostree rpmreaper rust-blsctl rust-rpm-sequoia satyr supermin systemtap transactional-update We would like to kindly ask the owners to issue a rebuild against our side-tag. The command to do this is: fedpkg build --target f39-build-side-67564 We already did scratch builds ourselves and the packages passing against the rawhide target also passed against the side-tag. Please let us know if we can help with that or with any unexpected build failures. Thank you! -- Michal Domonkos / RPM dev team / Red Hat, Inc. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for new urlgrabber maintainer
On Thu, Feb 13, 2020 at 4:37 PM Neal Gompa wrote: > Nothing stops you from writing tools to use it. :) Can't argue with that :) ___ 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: Looking for new urlgrabber maintainer
On Thu, Feb 13, 2020 at 3:59 PM Neal Gompa wrote: > Cobbler uses it still, as does Spacewalk/Uyuni. Some of my software > does as well, though admittedly I could replace if I wanted to (I > don't, I like urlgrabber's handling semantics :) ). Okay, fair enough :) FWIW, I have to admit I've also secretly liked urlgrabber's semantics. (I just don't happen to have a use-case for it anymore, with YUM being gone now.) ___ 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: Looking for new urlgrabber maintainer
On Thu, Feb 13, 2020 at 2:19 PM Neal Gompa wrote: > Sure. Let's make it official. Though I'd love to still have you as > co-maintainer and other co-maintainers are welcome! :) OK, I just made a request: https://pagure.io/releng/issue/9257 As for co-maintenance, it still is "maintenance" and defeats the purpose of us trying to "get rid of it" :) BTW, since koji-containerbuild no longer depends on python-urlgrabber (see above in this thread), do we have any motivation for keeping the package in the distro at all? I understand that SUSE actually uses it (so the upstream should live on), but not sure about the Fedora downstream package. ___ 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: Looking for new urlgrabber maintainer
On Wed, Feb 12, 2020 at 6:01 PM Martin Basti wrote: > > > On 12. 2. 2020 17:06, Neal Gompa wrote: > > On Wed, Feb 12, 2020 at 10:52 AM Michal Domonkos > > wrote: > >> Hi, > >> > >> I'd like to ask around if anyone would be willing to take ownership of > >> the python3-urlgrabber package and its upstream repository[1]? > >> > >> For historical reasons, the project is de facto maintained by us, the > >> DNF team (with the upstream repo hosted in our GitHub namespace). > >> However, with the community's departure from YUM (which depended on > >> urlgrabber) a few years back, we no longer have the incentive or > >> capacity to keep the project alive, and are considering deprecating it > >> in the near future, unless someone takes over. > >> > >> Now, urlgrabber has recently[2] been ported to Python 3, in an effort > >> to maintain its legacy as a standalone general-purpose URL library, > >> authored[3] by Jochen Breuer of SUSE in November, 2018. It's the only > >> component of the legacy YUM stack that wasn't dropped[4] from the > >> distro in Fedora 31. In addition to that, there currently is one last > >> component in Fedora that requires the package; koji-containerbuild. > >> > >> That said, I'd like to address this request especially to Jochen and > >> the maintainers of koji-containerbuild. Please, let us know if you > >> (or anyone, really) would be interested in the transfer. > >> > > Umm, don't I already own python-urlgrabber in Fedora and upstream? Not > > that I would mind co-maintainers, but I thought we already did this > > switchover during Fedora 31 development... > > > > > Ehm sorry, > > it seems that somebody forgot to remove that dependency from > koji-contianerbuild. At least it is not used in upstream I opened PR to > drop it. > > https://github.com/containerbuildsystem/koji-containerbuild/pull/159 Oh, and I can see the PR has been merged in the meantime, which is great! Thank you, Martin! ___ 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: Looking for new urlgrabber maintainer
On Wed, Feb 12, 2020 at 5:07 PM Neal Gompa wrote: > Umm, don't I already own python-urlgrabber in Fedora and upstream? Not > that I would mind co-maintainers, but I thought we already did this > switchover during Fedora 31 development... Oh, I almost forgot, of course. We did talk about it. After all, you made the release 4.0 happen, as a result of the discussion we had back then. We never made it "official", though, since "packaging-team-maint" is still listed as the primary maintainer on Pagure, which is basically what we're trying to change. If you're interested, more power to you, just let me know :) ___ 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
Looking for new urlgrabber maintainer
Hi, I'd like to ask around if anyone would be willing to take ownership of the python3-urlgrabber package and its upstream repository[1]? For historical reasons, the project is de facto maintained by us, the DNF team (with the upstream repo hosted in our GitHub namespace). However, with the community's departure from YUM (which depended on urlgrabber) a few years back, we no longer have the incentive or capacity to keep the project alive, and are considering deprecating it in the near future, unless someone takes over. Now, urlgrabber has recently[2] been ported to Python 3, in an effort to maintain its legacy as a standalone general-purpose URL library, authored[3] by Jochen Breuer of SUSE in November, 2018. It's the only component of the legacy YUM stack that wasn't dropped[4] from the distro in Fedora 31. In addition to that, there currently is one last component in Fedora that requires the package; koji-containerbuild. That said, I'd like to address this request especially to Jochen and the maintainers of koji-containerbuild. Please, let us know if you (or anyone, really) would be interested in the transfer. Thank you! Michal [1] https://github.com/rpm-software-management/urlgrabber [2] https://github.com/rpm-software-management/urlgrabber/releases/tag/urlgrabber-4-0-0 [3] https://github.com/rpm-software-management/urlgrabber/pull/8 [4] https://fedoraproject.org/wiki/Changes/Retire_YUM_3 ___ 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: /etc/yum.repos.d -> /etc/distro.repos.d
On Fri, Mar 15, 2019 at 3:39 PM John M. Harris, Jr. wrote: > > `rpm` does not care what repositories your system has available, it doesn't > work with them directly. That name would make no sense. I guess the rationale behind that was more of a "repositories of rpm packages" than "repositories used by rpm(8)". -- Michal Domonkos Software Engineer, DNF stack Red Hat, Inc. ___ 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: /etc/yum.repos.d -> /etc/distro.repos.d
On Fri, Mar 15, 2019 at 11:32 AM Samuel Rakitničan wrote: > Please don't tie the name with the particular software to avoid this issue in > the future. If you must then I think rpm.repos.d is less likely to avoid this > issue in the future. +1 Just like a few others have mentioned in this thread, I too consider the choice of "dnf" for a package manager quite unfortunate. It does not really stand for anything (except for the notorious Did Not Finish). For the same reasons why "systemd" or any other basic system utilities are not named after some random spur-of-the-moment sequence of characters or words, *the* package manager on a UNIX-like system, something that's really at the core of system administration, should also prefer a sensible name such as "pkg" or similar. In case of "dnf", I understand that one of the reasons was to make it easy to touch-type, which it is (as opposed to "yum"), but that quality is not in contradiction with the choice of a more descriptive (yet short and simple) name. The name is fine for an experimental project but those days are long gone and dnf is now the de-facto successor of yum. That said, if we should pick a different name today, "yum" seems like the most sensible choice. While still far from ideal, it has stickiness within the Fedora/RHEL community, and is a "trademark", really. -- Michal Domonkos Software Engineer, DNF stack Red Hat, Inc. ___ 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: /etc/yum.repos.d -> /etc/distro.repos.d
On Thu, Mar 14, 2019 at 11:56 AM Roberto Ragusa wrote: > Renaming dnf to yum is IMHO the best option. > I constantly use the wrong tool when switching between Fedora and Centos, > and the painful "yum.repos.d" string issue (code + docs) would disappear. Actually, we're planning [1] to rename the "dnf-yum" subpackage to "yum" in Fedora 31, to stay more consistent with the RHEL/CentOS world. That way, once Fedora 31 is out, those who have the original "yum" installed would just seamlessly upgrade to the new major version 4 (the former "dnf-yum"). That's about as close as we can get to renaming dnf to yum in Fedora at this moment. Note that the original yum config files would not be automatically migrated or merged into their dnf counterparts (except for /etc/yum.repos.d which is used by dnf already), but that's not the goal here either, as it would be quite complex and error-prone (at a minimum, we would have to incorporate a pretrans scriptlet using Lua [2] to take care of some of the symlinks). Instead, we just want to provide a smooth upgrade path for yum in Fedora for those who happen to still be using it for one reason or another, however the actual config migration (if needed) would have to be done manually by each user. IOW, the plan is that the "yum" package will continue to live on both distros, although the compatibility level of this package will differ between the two; on Fedora, it will only ship the /usr/bin/yum symlink and the yum(8) man page, just like the former "dnf-yum". The whole situation may seem complicated right now, but using the same package name for the yum compatibility layer on both Fedora and RHEL/CentOS should simplify things a little bit. [1] https://github.com/rpm-software-management/dnf/pull/1337 [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ -- Michal Domonkos Software Engineer, DNF stack Red Hat, Inc. ___ 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: F30 Self-Contained Change proposal: Retire YUM 3
On Fri, Mar 1, 2019 at 2:24 AM Dennis Gregorovic wrote: > > I have an update on the koji end. The 1.17 release will not only drop the > yum dependency, it will also have full python 3 support (except for image > building that uses oz / imagefactory). Unfortunately, there is only medium > confidence that the 1.17 release will be ready by the F30 devel freeze on > Tuesday. It depends on whether QE uncovers any issues in its final testing. > If we're not able to land the release on Tuesday, what is the backup plan? I suppose you're concerned about the Python 3 support part and not about the DNF port, but in case it's the latter -- please note the YUM deprecation has been approved for F31 (and is already happening in Rawhide now) as opposed to F30, to give everyone a bit more time to finish their porting efforts. -- Michal Domonkos Software Engineer, Packaging Tools in Fedora/RHEL Red Hat, Inc. ___ 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: F30 Self-Contained Change proposal: Retire YUM 3
On Mon, Jan 28, 2019 at 6:29 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Retire_YUM_3 > > == Summary == > Remove yum (v3) and all related packages from Fedora. Just a heads-up that I have updated the proposal so that it does *not*[2] include python2-urlgrabber, given how much it is still used within our infra. This should make it easier to consider the whole change proposal self-contained and thus more realistic towards Fedora 30. However, note that we still need that koji DNF port merged. [1] https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Detailed_Description [2] https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Dependencies -- Michal Domonkos Software Engineer, Software Mgmt Subsystem Red Hat, Inc. ___ 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: F30 Self-Contained Change proposal: Retire YUM 3
On Wed, Jan 30, 2019 at 6:46 PM Miro Hrončok wrote: > Based on the entire discussion so far, here's my proposal: > > - we change this to a system wide change > - we move it to Fedora 31 > - we retire the packages from rawhide as soon as f30 is branched regardless > of > the dependent packages > - packages with broken deps / FTBFS due to this will be retired if not fixed > by beta freeze > > Contingency mechanism: > > - if some process (releng or similar) needs the packages in order to ship > Fedora 31, the packages are added into a designated copr repo maintained by > the > person/team responsible for the tool that needs yum (or other packages > retired) > > - if the above is not possible and the packages are indeed needed in the > actual f31 repos, packages are unretired but the person/team responsible for > the > tool that needs yum maintains them as long as they need them and retires them > once that is no longer true +1 As an alternative solution, based on a discussion with Neal Gompa today on IRC, I propose the following: - we remove python-urlgrabber from the original change proposal (i.e. keeping it in F30) - we proceed with the retirement of the rest of the YUM stack in F30 - we make sure the kojid PR[1] is merged in time for F30 This is based on the following two facts: - python-urlgrabber seems to be the last component of the YUM stack that turns this proposal into a "system-wide" change, due to a number of infra bits that require it (sigul, koji-containerbuild, osc or imagefactory). Therefore, if we just postpone the removal of python-urlgrabber to F31 and merge that kojid PR, we could perhaps agree on re-qualifying the change as "self-contained" (plus, there's also the possibility of porting[2] python-urlgrabber to Python 3, but that's for a separate discussion) - the kojid PR[1] is also in-line with another F30 change[3], so there should be enough incentive to have it merged Before I go ahead and edit the proposal: Does this variant make sense to you? [1] https://pagure.io/koji/pull-request/1117 [2] https://github.com/rpm-software-management/urlgrabber/pull/8 [3] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal -- Michal Domonkos Software Engineer, Software Mgmt Subsystem Red Hat, Inc. ___ 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
