Fedora-Cloud-30-20200511.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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?
On Fri, May 08, 2020 at 09:39:58AM -0600, Ken Dreyer wrote: > In Ceph we do this at a slightly different point of time. We use > "rdopkg tag-patches" to save each of the "patches" refs that we've > translated into patch series in dist-git. Each Git tag is the NVR of > the package. > > We rebase and force-push our "patches" branches frequently, so a > patches branch is one "history", and dist-git becomes a "history of > histories". > > It's critical to have this flexibility + auditability so we can move > fast and still go back and reproduce everything. > How do you backport fixes? Do apply the fixes directly to dist-git? Or do you apply the fixes to a corresponding patches branch that you occur to have around till needed (e.g. till the hitorical code is supported) for the purpose of backporting? -- Petr signature.asc Description: PGP signature ___ 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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)
On Saturday, May 9, 2020 11:58:43 PM MST Miro Hrončok wrote: > On 10. 05. 20 0:09, John M. Harris Jr wrote: > > > On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote: > > > >> On 09. 05. 20 22:56, John M. Harris Jr wrote: > >> > >> > >> > >>> On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote: > >>> > >>> > >>> > The command that the user executes is "python3.9", not "python39". > >>> > >>> > >>> > >>> > >>> Let's be realistic. The command they run is 'python', 'python2' or > >>> 'python3'. Sure, it's a symlink, but that's what users actually type to > >>> be executed. > >> > >> > >> > >> The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to > >> support users who need to be that explicit. The fact that you don't > >> consider this use case dos not justify the "let's be realistic" comment. > >> Please, don't. > > > > > > In every environment I've seen a specific version used, the primary > > symlink is updated to point to the version that's supported or being > > used. For example, at work engineers asked for Python 2.7 to be installed > > on all of the systems in a given department, so my team installed the > > SCL, created a wrapper and updated the symlink 'python' to point to it. > > > Good for you. How does that support your argument? The first sentence was the supporting statement, the rest was providing an anecdote as supporting context. -- John M. Harris, Jr. signature.asc Description: This is a digitally signed message part. ___ 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: Fedora 31->32 dnf system-update experience
On 08. 05. 20 16:24, Richard Shaw wrote: There were a bunch of python2 packages that needed to be removed which necessitated --allowerasing which I've never had to do before. Do you still have that list? Maybe in `dnf history`? If so, we can make the experience nicer, but I cannot help without the list. The idea was that all problematic packages are obsoleted, but this data is extremely hard to collect without users reporting in with the actual lists. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Fedora 31->32 dnf system-update experience
On 09. 05. 20 22:58, John M. Harris Jr wrote: On Friday, May 8, 2020 7:24:14 AM MST Richard Shaw wrote: Not that it's a huge deal for me but I wouldn't call the upgrade smooth. There were a bunch of python2 packages that needed to be removed which necessitated --allowerasing which I've never had to do before. I noticed this as well, and it's a damned shame. It would have been nice if these packages could have been kept. They still work, even now, and are still widely used. Could you please provide the list of packages you have noticed needed --allowerasing? Could you please provide a list of packages that have been removed but are still widely used? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Fedora 31->32 dnf system-update experience
On 08. 05. 20 17:02, Michael Catanzaro wrote: On Fri, May 8, 2020 at 10:55 am, Scott Talbert wrote: Speaking of fedora-obsolete-packages, that package got removed from my system on upgrade from F31->F32. Is that expected? Without fedora-obsolete-packages installed, maintaining an upgrade path becomes impossible. I just want to clarify what others have said in this thread. This statement is not correct, the package does not need to be installed in order to help with the upgrade path. It only needs to be in the repository and obsolete the problematic packages. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Fedora 31->32 dnf system-update experience
On 08. 05. 20 16:55, Scott Talbert wrote: On Fri, 8 May 2020, Zbigniew Jędrzejewski-Szmek wrote: Not that it's a huge deal for me but I wouldn't call the upgrade smooth. There were a bunch of python2 packages that needed to be removed which necessitated --allowerasing which I've never had to do before. This should not be the case. If you have any such packages, please always report it as a bug against fedora-obsolete-packages. This should be done even after GA, since we can always fix the upgrade path for people who didn't upgrade immediately. Speaking of fedora-obsolete-packages, that package got removed from my system on upgrade from F31->F32. Is that expected? Yes. See https://bugzilla.redhat.com/show_bug.cgi?id=1827398 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: What is force erasing python 2 packages like moin?
On 10. 05. 20 20:48, Kevin Fenzi wrote: Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'. As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'. Is this ideal? No. But it has not been changed. (The changed part is fedora-obsolete-packages does not get installed in the process.) A better solution to the problem fedora-obsolete-packages is trying to solve would be to use allowerasing on system-upgrade, but that is another can of worms, because it also removes packages that have broken dependencies, but were not intentionally removed. The idea solution IMHO would be to allow erasing only the packages that do not belong to a distupgrade repository. Possibly to have that option only for the Fedora repos, so packages installed from a thrid-party would not get erased. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Fedora rawhide compose report: 20200510.n.0 changes
OLD: Fedora-Rawhide-20200509.n.0 NEW: Fedora-Rawhide-20200510.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:1 Upgraded packages: 37 Downgraded packages: 0 Size of added packages: 224.84 KiB Size of dropped packages:31.67 MiB Size of upgraded packages: 1.29 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.73 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: samurai-1.1-1.fc33 Summary: ninja-compatible build tool written in C RPMs:samurai Size:224.84 KiB = DROPPED PACKAGES = Package: deepin-help-15.4.8-6.fc32 Summary: Help files for DDE RPMs:deepin-help Size:31.67 MiB = UPGRADED PACKAGES = Package: IPAddress-5.2.1-3.fc33 Old package: IPAddress-5.2.1-2.fc33 Summary: Library for handling IP addresses and subnets, both IPv4 and IPv6 RPMs: IPAddress Size: 2.04 MiB Size change: 943.37 KiB Changelog: * Fri May 08 2020 Jiri Vanek - 5.2.1-3 - hack with LANG did not worked, pathcing out non asci chars Package: YafaRay-3.4.4-1.fc33 Old package: YafaRay-3.4.0-1.fc33 Summary: A free open-source ray-tracing render engine RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib Size: 5.19 MiB Size change: 16.93 KiB Changelog: * Sat Apr 11 2020 Luya Tshimbalanga - 3.4.1-1 - Update to 3.4.1 (#1822412) * Sat May 09 2020 Luya Tshimbalanga - 3.4.4-1 - Update to 3.4.4 (#1822412) Package: bashtop-0.8.27-2.fc33 Old package: bashtop-0.8.22-1.fc33 Summary: Linux resource monitor RPMs: bashtop Size: 55.54 KiB Size change: 1.66 KiB Changelog: * Sat May 09 2020 Alessio - 0.8.27-2 - 0.8.27 release Package: condor-8.8.8-1.fc33 Old package: condor-8.8.4-3.fc32 Summary: HTCondor: High Throughput Computing RPMs: condor condor-annex-ec2 condor-classads condor-classads-devel condor-kbdd condor-openstack-gahp condor-procd condor-vm-gahp minicondor python3-condor Size: 29.20 MiB Size change: 311.03 KiB Changelog: * Thu Apr 09 2020 Tim Theisen - 8.8.8-1 - Update to latest upstream 8.8.8 Package: cros-guest-tools-1.0-0.32.20200509gitfce526e.fc33 Old package: cros-guest-tools-1.0-0.31.20200427git6968d7b.fc33 Summary: Chromium OS integration meta package RPMs: cros-adapta cros-garcon cros-guest-tools cros-host-fonts cros-notificationd cros-pulse-config cros-sftp cros-sommelier cros-sommelier-config cros-sudo-config cros-systemd-overrides cros-ui-config cros-wayland Size: 170.91 KiB Size change: 1.76 KiB Changelog: * Sat May 09 2020 Jason Montleon jmont...@redhat.com - 1.0-0.32.20200509gitfce526e - Update to master fce526e Package: dl-0.17.1-9.fc33 Old package: dl-0.17.1-8.fc32 Summary: Download Ticket Service RPMs: dl Size: 1.50 MiB Size change: 2.19 KiB Changelog: * Sat May 09 2020 Greg Bailey - 0.17.1-9 - Revert unbundling of php-phpass (removed from repo) (#1832436) Package: dummy-test-package-crested-0-450.fc33 Old package: dummy-test-package-crested-0-439.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 36.21 KiB Size change: 625 B Changelog: * Sat May 09 2020 packagerbot - 0-440 - rebuilt * Sat May 09 2020 packagerbot - 0-441 - rebuilt * Sat May 09 2020 packagerbot - 0-442 - rebuilt * Sat May 09 2020 packagerbot - 0-443 - rebuilt * Sat May 09 2020 packagerbot - 0-444 - rebuilt * Sat May 09 2020 packagerbot - 0-445 - rebuilt * Sat May 09 2020 packagerbot - 0-446 - rebuilt * Sat May 09 2020 packagerbot - 0-447 - rebuilt * Sat May 09 2020 packagerbot - 0-448 - rebuilt * Sun May 10 2020 packagerbot - 0-449 - rebuilt * Sun May 10 2020 packagerbot - 0-450 - rebuilt Package: dummy-test-package-gloster-0-473.fc33 Old package: dummy-test-package-gloster-0-462.fc33 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 37.52 KiB Size change: 659 B Changelog: * Sat May 09 2020 packagerbot - 0-463 - rebuilt * Sat May 09 2020 packagerbot - 0-464 - rebuilt * Sat May 09 2020 packagerbot - 0-465 - rebuilt * Sat May 09 2020 packagerbot - 0-466 - rebuilt * Sat May 09 2020 packagerbot - 0-467 - rebuilt * Sat May 09 2020 packagerbot - 0-468 - rebuilt * Sat May 09 2020 packagerbot - 0-469 - rebuilt * Sat May 09 2020 packagerbot - 0-470 - rebuilt * Sat May 09 2020 packagerbot - 0-471 - rebuilt * Sun May 10 2020 packagerbot - 0-472 - rebuilt * Sun May 10 2020 packagerbot - 0-473 - rebuilt Package: dummy-test-package-rubino-0-450.fc33 Old package: dummy-test-package-rubino-0-439.fc33 Summary: Dummy Test Package called Rubino RPMs: dummy-test-package
Re: What is force erasing python 2 packages like moin?
On Sun, May 10, 2020 at 09:30:26PM +0200, Fabio Valentini wrote: > On Sun, May 10, 2020 at 8:49 PM Kevin Fenzi wrote: > > > > On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote: > > > On 10. 05. 20 18:37, Scott Talbert wrote: > > > > On Sun, 10 May 2020, Barry Scott wrote: > > > > > > > > > I know that python2 is a dead language, but I have a need to use > > > > > some python 2 code > > > > > on one of my servers. It's clearly on me to maintain the old code if > > > > > I choose to use it. > > > > > > > > > > I use MoinMoin via mon_wsgi. > > > > > > > > > > After upgrading to fedora 32 I took the trouble to install moin > > > > > using the F31 package. > > > > > And all was good. > > > > > > > > > > But I just did my first dnf update and was surprised to find these > > > > > lines in the log of > > > > > the dnf update: > > > > > > > > > > ---> Package moin.noarch 1.9.10-3.fc31 will be erased > > > > > ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased > > > > > > > > > > What is forcing the erase? I need to workaround this. > > > > > > > > Probably fedora-obsolete-packages: > > > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedora-obsolete-packages.spec > > > > > > > > > > > > I don't know how to workaround it though as the f-o-p package doesn't > > > > actually get installed anymore - it's work happens through some dnf > > > > tricks now. > > > > > > You should still be able to exclude the package in the dnf config: > > > > > > $ cat /etc/dnf/dnf.conf > > > [main] > > > ... > > > exclude=fedora-obsolete-packages > > > > We really should have made this better announced/documented. > > > > Basically we are switching from 'I go and install > > fedora-obsolete-packages and have opted in to it' to 'I have to go > > explictly exclude it to keep my obsolete packges'. > > Huh? I don't think how fedora-obsolete-packages works, at least not > for a while ... > I have never manually installed fedora-obsolete-packages, it was only > ever automatically pulled in and installed because it "Obsoletes: > something-I-had-installed" before a system upgrade. Yeah, it wasn't necessary to request f-o-p explictly. Packages that were added to f-o-p in the past were added when they broke upgrades. So without f-o-p, the upgrade wouldn't go through because of broken deps, and dnf would pull in f-o-p automatically to make the transaction viable. We now add some packages more proactively, even when they don't block an upgrade, but f-o-p is still used for many packages that would block an upgrade and f-o-p would still be required to satisfy deps for any fedora-version upgrade and would still be pulled in. So the magic trick that makes f-o-p non-installable doesn't change much. Zbyszek ___ 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: What is force erasing python 2 packages like moin?
On Sun, May 10, 2020 at 8:49 PM Kevin Fenzi wrote: > > On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote: > > On 10. 05. 20 18:37, Scott Talbert wrote: > > > On Sun, 10 May 2020, Barry Scott wrote: > > > > > > > I know that python2 is a dead language, but I have a need to use > > > > some python 2 code > > > > on one of my servers. It's clearly on me to maintain the old code if > > > > I choose to use it. > > > > > > > > I use MoinMoin via mon_wsgi. > > > > > > > > After upgrading to fedora 32 I took the trouble to install moin > > > > using the F31 package. > > > > And all was good. > > > > > > > > But I just did my first dnf update and was surprised to find these > > > > lines in the log of > > > > the dnf update: > > > > > > > > ---> Package moin.noarch 1.9.10-3.fc31 will be erased > > > > ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased > > > > > > > > What is forcing the erase? I need to workaround this. > > > > > > Probably fedora-obsolete-packages: > > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedora-obsolete-packages.spec > > > > > > > > > I don't know how to workaround it though as the f-o-p package doesn't > > > actually get installed anymore - it's work happens through some dnf > > > tricks now. > > > > You should still be able to exclude the package in the dnf config: > > > > $ cat /etc/dnf/dnf.conf > > [main] > > ... > > exclude=fedora-obsolete-packages > > We really should have made this better announced/documented. > > Basically we are switching from 'I go and install > fedora-obsolete-packages and have opted in to it' to 'I have to go > explictly exclude it to keep my obsolete packges'. Huh? I don't think how fedora-obsolete-packages works, at least not for a while ... I have never manually installed fedora-obsolete-packages, it was only ever automatically pulled in and installed because it "Obsoletes: something-I-had-installed" before a system upgrade. Fabio > :( > > Oh well, can we at least common bugs it? > > kevin > ___ > 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: What is force erasing python 2 packages like moin?
On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote: > On 10. 05. 20 18:37, Scott Talbert wrote: > > On Sun, 10 May 2020, Barry Scott wrote: > > > > > I know that python2 is a dead language, but I have a need to use > > > some python 2 code > > > on one of my servers. It's clearly on me to maintain the old code if > > > I choose to use it. > > > > > > I use MoinMoin via mon_wsgi. > > > > > > After upgrading to fedora 32 I took the trouble to install moin > > > using the F31 package. > > > And all was good. > > > > > > But I just did my first dnf update and was surprised to find these > > > lines in the log of > > > the dnf update: > > > > > > ---> Package moin.noarch 1.9.10-3.fc31 will be erased > > > ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased > > > > > > What is forcing the erase? I need to workaround this. > > > > Probably fedora-obsolete-packages: > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedora-obsolete-packages.spec > > > > > > I don't know how to workaround it though as the f-o-p package doesn't > > actually get installed anymore - it's work happens through some dnf > > tricks now. > > You should still be able to exclude the package in the dnf config: > > $ cat /etc/dnf/dnf.conf > [main] > ... > exclude=fedora-obsolete-packages We really should have made this better announced/documented. Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'. :( Oh well, can we at least common bugs it? kevin signature.asc Description: PGP signature ___ 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: QtCreator armv7hl build failure, gcc bug?
Hi I couldn't reproduce the issue anymore, so I suppose it was some transient issue. Thanks Sandro On 08.05.20 12:04, Jakub Jelinek wrote: On Fri, May 08, 2020 at 11:54:07AM +0200, Sandro Mani wrote: Hi I'm hitting the following error (and other similar ones) with this qt-creator build [1] on armv7hl and armv7hl only: Code snippets like that aren't useful for analyzing what's going on, as they can't be compiled. Please send (off-list) full preprocessed source and g++ command line used to compile that TU. Thanks. Jakub ___ 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: What is force erasing python 2 packages like moin?
On 10. 05. 20 18:37, Scott Talbert wrote: On Sun, 10 May 2020, Barry Scott wrote: I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it. I use MoinMoin via mon_wsgi. After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good. But I just did my first dnf update and was surprised to find these lines in the log of the dnf update: ---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased What is forcing the erase? I need to workaround this. Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedora-obsolete-packages.spec I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now. You should still be able to exclude the package in the dnf config: $ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-obsolete-packages -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: What is force erasing python 2 packages like moin?
> On 10 May 2020, at 17:45, Igor Raits wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Sun, 2020-05-10 at 17:31 +0100, Barry Scott wrote: >> I know that python2 is a dead language, but I have a need to use some >> python 2 code >> on one of my servers. It's clearly on me to maintain the old code if >> I choose to use it. >> >> I use MoinMoin via mon_wsgi. >> >> After upgrading to fedora 32 I took the trouble to install moin using >> the F31 package. >> And all was good. >> >> But I just did my first dnf update and was surprised to find these >> lines in the log of >> the dnf update: >> >> ---> Package moin.noarch 1.9.10-3.fc31 will be erased >> ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased >> >> What is forcing the erase? I need to workaround this. > > fedora-obsolete-packages I guess. > > Just build the packages you need with newer version/release. Then > python3 subpackage or fedora-obsolete-packages won't remove them. Thanks for the explanation. I'll package as barry-XXX to avoid the problem. Barry > >> Barry >> ___ >> 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 > - -- > Igor Raits > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl64L48ACgkQEV1auJxc > Hh678xAAo/orxcpLxsOaAAmusa/THRWnHbt8/DTcjZXOB04WzL7gd/jb6HqO/bgg > bihxGGyzDiFSGi/cIiZ7X9Tweiq2IynjSep2fhVlNUBKcIKKmPaJkDWIlqTaPt+n > hRpDzKaowwFLHs2N9N9rsQQPm5NLbIIhEH00aWg5KqZ1OErMT2cqM9MS7nLLOakP > nRqkC+9dbUx8kFdVMDedWQlH1tW2SDi+9mpX6TXqizJuOGHBAIGqhILcrUB8suJl > vM5XElvHEObmtRksglCjJ+Ogou57SDN0jOik7nwhCvxDgxbC+/DIMPWNXyykWCON > mkasRJMmhpbSx8JJ5aNnbeCnn9d6NrQv4T9TxriQjzZTs+NUvbYGHmJxQHExEUmP > A0Ix7V5t8SgKuZ6P9cwlQqEagwntjIr8vyxs6YZscT0L5CGXL1LEKETQRI61JhdG > /dMIB47qU78HJn/MQmYjyBic5wp7+PrGqPaTtdxxX0Jr/U0HgqLL4JVuN9EVKypb > rY4ucKqVW4MCHGY2IxLXIbdcoeFtypqwoJagXbf1kBV9fMpVUcPcJqhfNAC29yt1 > I0a2qGlBC9PatWQ6TKPhobVfWFJA//RAvFiRVKnupe6+0aynaT+j377tJoGu9Cdj > rkatM+zxroo2WjcDkgBvbcjuD1t42y3J46rfn78l1+aHrMPwXgY= > =Rukt > -END PGP SIGNATURE- > ___ > 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: What is force erasing python 2 packages like moin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-05-10 at 17:31 +0100, Barry Scott wrote: > I know that python2 is a dead language, but I have a need to use some > python 2 code > on one of my servers. It's clearly on me to maintain the old code if > I choose to use it. > > I use MoinMoin via mon_wsgi. > > After upgrading to fedora 32 I took the trouble to install moin using > the F31 package. > And all was good. > > But I just did my first dnf update and was surprised to find these > lines in the log of > the dnf update: > > ---> Package moin.noarch 1.9.10-3.fc31 will be erased > ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased > > What is forcing the erase? I need to workaround this. fedora-obsolete-packages I guess. Just build the packages you need with newer version/release. Then python3 subpackage or fedora-obsolete-packages won't remove them. > Barry > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl64L48ACgkQEV1auJxc Hh678xAAo/orxcpLxsOaAAmusa/THRWnHbt8/DTcjZXOB04WzL7gd/jb6HqO/bgg bihxGGyzDiFSGi/cIiZ7X9Tweiq2IynjSep2fhVlNUBKcIKKmPaJkDWIlqTaPt+n hRpDzKaowwFLHs2N9N9rsQQPm5NLbIIhEH00aWg5KqZ1OErMT2cqM9MS7nLLOakP nRqkC+9dbUx8kFdVMDedWQlH1tW2SDi+9mpX6TXqizJuOGHBAIGqhILcrUB8suJl vM5XElvHEObmtRksglCjJ+Ogou57SDN0jOik7nwhCvxDgxbC+/DIMPWNXyykWCON mkasRJMmhpbSx8JJ5aNnbeCnn9d6NrQv4T9TxriQjzZTs+NUvbYGHmJxQHExEUmP A0Ix7V5t8SgKuZ6P9cwlQqEagwntjIr8vyxs6YZscT0L5CGXL1LEKETQRI61JhdG /dMIB47qU78HJn/MQmYjyBic5wp7+PrGqPaTtdxxX0Jr/U0HgqLL4JVuN9EVKypb rY4ucKqVW4MCHGY2IxLXIbdcoeFtypqwoJagXbf1kBV9fMpVUcPcJqhfNAC29yt1 I0a2qGlBC9PatWQ6TKPhobVfWFJA//RAvFiRVKnupe6+0aynaT+j377tJoGu9Cdj rkatM+zxroo2WjcDkgBvbcjuD1t42y3J46rfn78l1+aHrMPwXgY= =Rukt -END PGP SIGNATURE- ___ 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: What is force erasing python 2 packages like moin?
On Sun, 10 May 2020, Barry Scott wrote: I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it. I use MoinMoin via mon_wsgi. After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good. But I just did my first dnf update and was surprised to find these lines in the log of the dnf update: ---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased What is forcing the erase? I need to workaround this. Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedora-obsolete-packages.spec I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now. Scott ___ 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: What is force erasing python 2 packages like moin?
On Sun, May 10, 2020 at 12:32 PM Barry Scott wrote: > > I know that python2 is a dead language, but I have a need to use some python > 2 code > on one of my servers. It's clearly on me to maintain the old code if I choose > to use it. > > I use MoinMoin via mon_wsgi. > > After upgrading to fedora 32 I took the trouble to install moin using the F31 > package. > And all was good. > > But I just did my first dnf update and was surprised to find these lines in > the log of > the dnf update: > > ---> Package moin.noarch 1.9.10-3.fc31 will be erased > ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased > > What is forcing the erase? I need to workaround this. > fedora-obsolete-packages is going to keep doing that. There are two options for you: * Package moin2 and switch to that: https://github.com/moinwiki/moin * Rebuild those packages and bump the release number so that they don't get obsoleted automatically -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
What is force erasing python 2 packages like moin?
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it. I use MoinMoin via mon_wsgi. After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good. But I just did my first dnf update and was surprised to find these lines in the log of the dnf update: ---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased What is forcing the erase? I need to workaround this. Barry ___ 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
Fedora-IoT-33-20200510.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Passed openQA tests: 8/8 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Orphaned felix-framework, felix-osgi-obr-resolver
Hi everybody, I have just orphaned both felix-framework and felix-osgi-obr-resolver, since none of the packages maintained by the Stewardship SIG depend on them any longer. We transitioned onto OSGi 7.0.0 / osgi-core where possible, and other users of those APIs should probably do that too. Fabio ___ 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
[Test-Announce] Fedora 33 Rawhide 20200510.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 33 Rawhide 20200510.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20200507.n.0: anaconda-33.12-1.fc33.src, 20200510.n.0: anaconda-33.13-1.fc33.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200510.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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: Announce soname bump of zipper library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-05-10 at 14:39 +0200, Antonio Trande wrote: > On 10/05/20 14:28, Igor Raits wrote: > > On Sun, 2020-05-10 at 14:14 +0200, Antonio Trande wrote: > > > Hi all. > > > > Hi Antonio, > > > > > `zipper` library will be upgraded to the release 1.0.1 with a > > > soname > > > bump in a week. > > > > Thanks a lot for announcing this. > > > > > Dependent packages: > > > COPASI > > > libCombine > > > > I assume you will rebuild those or you need some help with that? > > No, really. > > > Will > > you make this happen in a side tag¹? > > > > ¹https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ > > > > Can you make an example about how to use this process, please? $ cf zipper $ fedpkg request-side-tag --base f33-build $ # push changes to affected dist-gits $ fedpkg build --target f33-build-side-$id $ # Submit upda via bodhi UI (it is also possible from CLI, but I never did that) $id is something what request-side-tag will give you So basically same as you would do it in rawhide, but with creation of side tag and building all packages in it and then submitting all builds at once. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl639tUACgkQEV1auJxc Hh7F5Q/+Okf+16HEhveQqE/PCZoFxIMe6TMUNyfGxUNXjQDWpMkk7kt19IeZDlDT ER+6/aS4kJU0a8PelqvdtP99n685Rohqh/ZmkzF/iIJ916EVYSByMeSQRaajmDY7 VSSKMpfEriRr6xSyd53LB7n+5miyW2jcbyEeSjpJ96Vhwoxw48Tsl7JJrE+hkq+G 3F8W4ddW54f8Gt5DkDo8fU+mmEcg92FVXG3CM7td8gxaD2duEMKwUU77CUkPmdIQ 36auKubQZLF6G0mdwO2TGS2zSIxYmjJGz6gQTzC4cqkJHSUCrywCRe+nSvS51Is1 4VLK/utLdySFAYmyscX8DlVMHe3Q9PEoChVY+PhDWXWiws4oETFhbhmyK6FroQGg fyTUfgxcdw6T2g71/QdbErXPo3NYGIZ/4MZeRwHh5kaz049u8SGC1EJ9dzAAqB/C zK+C5rsPSVW+K3BzcN7UO8lD3J6bF2Asudr8FdN34lk+90+vf2IMqhPlOQpoVhrd 5sOokwMy0hEAyvk52fcrAkEjqFfGIWPLilO6/YvKRYhdkuNDXYfeB4JfFIqr0KR6 lCqGaSJUsjfN/tIerf/yKPyfEbd+vk+AiOlL/LiiFGo/61vfwAWpLEpX4pDkd2wd YUCViSIU+C71Y/NxdBZSDd09MtxgvF36nYMl8bU11ggPFdLKlXk= =erOS -END PGP SIGNATURE- ___ 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: Announce soname bump of zipper library
On 10/05/20 14:28, Igor Raits wrote: > On Sun, 2020-05-10 at 14:14 +0200, Antonio Trande wrote: >> Hi all. > > Hi Antonio, > >> `zipper` library will be upgraded to the release 1.0.1 with a soname >> bump in a week. > > Thanks a lot for announcing this. > >> Dependent packages: >> COPASI >> libCombine > > I assume you will rebuild those or you need some help with that? No, really. > Will > you make this happen in a side tag¹? > > ¹https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ > Can you make an example about how to use this process, please? -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ 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: Announce soname bump of zipper library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-05-10 at 14:14 +0200, Antonio Trande wrote: > Hi all. Hi Antonio, > `zipper` library will be upgraded to the release 1.0.1 with a soname > bump in a week. Thanks a lot for announcing this. > Dependent packages: > COPASI > libCombine I assume you will rebuild those or you need some help with that? Will you make this happen in a side tag¹? ¹https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl63810ACgkQEV1auJxc Hh4SGxAAuEc3fP3yj67j4GHqB3JRmBNTv0toaIITia8oNP3EY0lDd9LzMhwpQDIM pOlB+vwwzaregmL81l0A/vPAs2TmMx5DCe16DUwt56/n9VANZ10EkaqJVnyYW898 v9+4Di9WTzKmX2kVkGTRWiqNS5VD5wXW5xZo8ufCBhInalYzAX6WfhmoOLVXDwRj bPfYvqGSZRcMwy0tRES4T7d4qv5ziqlEkMva9O85MyynHGR3+qdEWw3Zz9lg2BJf R68/jNvsYZku6DF7TLwQ/3AMofCiDQvazf7JyeEV84fB9wfkFjVYlUlwzIA+dnfO Ha9REyzr0xL7Cxil4iaQtLkYkL+1gXRccp/Aibi2jLaTO+RxXhOf2GAJCyk8lvHI 7qed40DP5x22fARNa+I51E6lBZbiB7n88rXw8NES5K+SJyqDRG6t3jtK839SdP7M P+0zChrYJLvp4mwHLnwSxoSg6xqS8p+GojZ/x2FA8oSDRFhZf//G/X+RVX2002yK bV5vjkoTktDtXynWAZq22AljcjES4LuabmVBNGdJpH+pj7WZVLVKxz1H48c+qSdc L7W6+adyhSFVqwwNVY6m/gxnqtv1O1kqp4JhRLsOTGpHLuF6HoN/JSCqtyVAjA/3 WKZuJNY8UQHKUDG4Gztn7Kb1WOKdGpeOq0yKgtNjOPF3HpFov0U= =Dy90 -END PGP SIGNATURE- ___ 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
Announce soname bump of zipper library
Hi all. `zipper` library will be upgraded to the release 1.0.1 with a soname bump in a week. Dependent packages: COPASI libCombine -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ 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
Fedora-Cloud-31-20200510.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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?
Hi,
Well, *my* packaging workflow is pretty simple:
1. point to the upstream git repo in my spec file with %{forgeurl} and
the rest of the forge macros
2. point to the target upstream tag or commit with the associated
variable
3. spectool (or co from lookaside if already there)
4. build
If I need changes in upstream code I fork the upstream git repo, make
the changes there and point %{forgeurl} to my fork till the changes got
merged upstream (sometimes I am the upstream).
If upstreaming stalls I export the corresponding git patches and apply
them manually. This is painless enough I’ve not bothered yet to code a
per-forgeurl %{patchlist} in forge macros. Someday I will spend the
time here and I’ll have a safe %autoforgesetup that does not assume all
the patches belong to archive 0.
Step 3 is a bit annoying in practice *but* absolutely necessary. WIP
fixing can rely a lot on ephemeral multi-rebased topic branches. I
*need* to cut the link to upstream git in my spec files by exporting
the state the spec packages, without polluting other git repos with
transient topic branches.
I don’t waste time modifying my Sources, %forgemeta produces a
%{forgesourceX} that I declare as SourceX once and for all. I will,
eventually, code a %forgesources that can be dropped in %sourcelist so
it just works in multi-source specs, but those are few and frowned upon
in Fedora.
Sometimes upstream is itself a galaxy of forked repos, again, being
able to point the spec file to one of those (and change the pointer ar
need) without assuming upstream is a monolithic monotonic ethernal repo
is a godsend.
So, I *definitely* do not think making the Fedora git repo
a clone or extension of some upstream git repo is a good idea, not that
it is needed.
Better autobumping and auto changeloging would be appreciated, but not
if it introduces adherences to specific Fedora git objects.
Like others wrote, the correct data model is to make the buildsys
record real official Fedora build events in Fedora git, not invent
esotheric rules to workaround the fact the git can not guess accurately
what was actually build in what order. That can never work reliably.
Just bite the bullet, builds are controlled by the build system, no one
*but* the build system can record them accurately in Fedora git.
Regards
--
Nicolas Mailhot
___
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
Fedora-Cloud-32-20200510.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 595139 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/595139 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)
On 10. 05. 20 0:09, John M. Harris Jr wrote: On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote: On 09. 05. 20 22:56, John M. Harris Jr wrote: On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote: The command that the user executes is "python3.9", not "python39". Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed. The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't. In every environment I've seen a specific version used, the primary symlink is updated to point to the version that's supported or being used. For example, at work engineers asked for Python 2.7 to be installed on all of the systems in a given department, so my team installed the SCL, created a wrapper and updated the symlink 'python' to point to it. Good for you. How does that support your argument? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
