Re: Qt 5.14.2 coming to rawhide
On Wed, Apr 08, 2020 at 10:45:40AM +0800, Robin Lee wrote:
> On Sun, Apr 5, 2020 at 6:58 AM Rex Dieter wrote:
> >
> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> > progress being done in side tag f33-build-side-21031
> >
> > I figure it'll take at least a few days to get the core bits and all
> > dependencies rebuilt. Will provide status updates as warranted.
> >
> > -- Rex
> I built deepin-qt5integration-5.0.0-5.fc33 in the side tag.
> But when I build deepin-file-manager, the new build of deepin-qt5integration
> is not found.
> What should I do to fix this?
It doesn't look to me like thats the cause of the failed build?
https://koji.fedoraproject.org/koji/taskinfo?taskID=43111751
...
./shutil/dsqlitehandle.h:29:8: error: redefinition of 'struct
std::hash'
29 | struct hash
|^
In file included from /usr/include/qt5/QtCore/qlist.h:47,
from /usr/include/qt5/QtCore/qurl.h:47,
from /usr/include/qt5/QtCore/QUrl:1,
from ./interfaces/durl.h:28,
from tag/tagmanager.h:15,
from tag/tagmanager.cpp:7:
/usr/include/qt5/QtCore/qhashfunctions.h:180:16: note: previous definition of
'struct std::hash'
180 | struct hash< QT_PREPEND_NAMESPACE(Class) > {\
|^~~
/usr/include/qt5/QtCore/qhashfunctions.h:200:5: note: in expansion of macro
'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH'
200 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH(Class, const argument_type &)
| ^~~~
/usr/include/qt5/QtCore/qhashfunctions.h:204:1: note: in expansion of macro
'QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF'
204 | QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH_BY_CREF(QString)
| ^~~~
make[1]: *** [Makefile:3680: tagmanager.o] Error 1
...
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
[389-devel] 389 DS nightly 2020-04-08 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/04/08/report-389-ds-base-1.4.3.5-20200407gitc868a41.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: v4l2loopback kernel module in Fedora?
On Tue, Apr 7, 2020 at 6:06 AM Iñaki Ucar wrote: > > On Tue, 7 Apr 2020 at 05:58, Christopher wrote: > > > > If I get the motivation, I'll file a bug against the RPMFusion package. > > Here's the bug tracker: https://bugzilla.rpmfusion.org/ Thanks. > > > As for the original issue regarding packaging: there is a ticket being > > tracked to get it upstream into the kernel: > > https://github.com/umlaeute/v4l2loopback/issues/268 > > Yeap, I saw this, and that's why I said that upstream doesn't seem to > be willing to push this forward, because the maintainer's message is > basically "I'm totally open, but I'm not going to move a finger > besides merging PRs". > My interpretation of their message was more "I tried a little, but don't know where to go from here". They might just need help... but I don't really know. :) One more thing: can anybody point me to good docs on how to automatically sign DKMS on build/install in Fedora? I tried editing /etc/dkms/framework.conf to add SIGN_TOOL and also POST_INST, but nothing seemed to work. I can't even get my script to run. I can sign it manually after I `dkms install` but that's kind of annoying to do after every dnf update that updates the kernel. All the docs out there seem to be written for Ubuntu, and the instructions don't seem to work on Fedora. If I can't get good docs, I'm going to have to start ripping apart /usr/sbin/dkms and filling it with print debug statements. :) ___ 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
[Bug 1817061] perl-Gnome2-Vte is missing in Fedora V32?
https://bugzilla.redhat.com/show_bug.cgi?id=1817061 Bug 1817061 depends on bug 1817875, which changed state. Bug 1817875 Summary: Review Request: perl-Gnome2-Vte - Perl interface to the Gtk2 Virtual Terminal Emulation library https://bugzilla.redhat.com/show_bug.cgi?id=1817875 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1817061] perl-Gnome2-Vte is missing in Fedora V32?
https://bugzilla.redhat.com/show_bug.cgi?id=1817061 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-Vte-0.11-15.fc3 |perl-Gnome2-Vte-0.11-15.fc3 |3 |3 ||perl-Gnome2-Vte-0.11-15.fc3 ||2 Resolution|--- |ERRATA Last Closed|2020-03-25 14:48:46 |2020-04-08 02:53:16 --- Comment #6 from Fedora Update System --- FEDORA-2020-64662fe4c1 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a5eb3ef5 librabbitmq-0.5.2-2.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-22ba261c73 drupal7-ckeditor-1.19-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-082ab81e5f php-robrichards-xmlseclibs1-1.4.3-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing nrpe-4.0.2-1.el6 Details about builds: nrpe-4.0.2-1.el6 (FEDORA-EPEL-2020-fc983d39e7) Host/service/network monitoring agent for Nagios Update Information: New upstream version fixes CVEs ChangeLog: * Tue Apr 7 2020 Martin Jackson - 4.0.2-1 - New upstream version - Update patch for indlude_dir - Fix BZ#1816816 - CVE-2020-6582 nrpe: heap-based buffer overflow due to a wrong integer type conversion - Fix BZ#1816805 - CVE-2020-6581 nrpe: insufficient filtering and incorrect parsing of the configuration file may lead to command injection References: [ 1 ] Bug #1816805 - CVE-2020-6581 nrpe: insufficient filtering and incorrect parsing of the configuration file may lead to command injection [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1816805 [ 2 ] Bug #1816816 - CVE-2020-6582 nrpe: heap-based buffer overflow due to a wrong integer type conversion [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1816816 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 --- Comment #7 from Fedora Update System --- FEDORA-2020-7349370cc7 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7349370cc7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7349370cc7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Qt 5.14.2 coming to rawhide
On Sun, Apr 5, 2020 at 6:58 AM Rex Dieter wrote: > > FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in- > progress being done in side tag f33-build-side-21031 > > I figure it'll take at least a few days to get the core bits and all > dependencies rebuilt. Will provide status updates as warranted. > > -- Rex I built deepin-qt5integration-5.0.0-5.fc33 in the side tag. But when I build deepin-file-manager, the new build of deepin-qt5integration is not found. What should I do to fix this? -robin > ___ > 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
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 --- Comment #6 from Fedora Update System --- FEDORA-2020-4a5245e2df has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4a5245e2df` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a5245e2df See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[ANN] python-hypothesis 5.8.0 in fc33, fc32
Hi all, I just updated python-hypothesis to the latest 5.8.0 version. It should be fine for Rawhide, but for Fedora 32 it's probably worth testing (since the previous version we have in the repo is a bit behind -- 4.23.8). I'm putting it as a buildroot override in case maintainers for the dependent packages want to verify this works as expected: https://bodhi.fedoraproject.org/overrides/python-hypothesis-5.8.0-2.fc32 $ sudo dnf repoquery --whatrequires python3-hypothesis python3-argon2-cffi-0:19.2.0-2.fc32.x86_64 python3-hs-dbus-signature-0:0.06-6.fc32.noarch python3-hypothesis-fspaths-0:0.1-5.fc32.noarch Best regards, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2020-0426ac59f0 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0426ac59f0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0426ac59f0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Nvidia 440.82 came out today
On Tue, 2020-04-07 at 20:55 -0400, Paul Dufresne via devel wrote: > I saw that Nvidia published version 440.82 of their drivers today. > > Last one was 440.62 released on February 28. That is offtopic here, as Fedora does not ship or support proprietary software. There are third-party repositories that do ship this driver, you could discuss it on their mailing lists etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Nvidia 440.82 came out today
I saw that Nvidia published version 440.82 of their drivers today. Last one was 440.62 released on February 28. ___ 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 32 FTBFS packages to be orphaned in 1 week
On Mon, Apr 6, 2020 at 1:00 PM Miro Hrončok wrote: > > On 29. 03. 20 13:13, Miro Hrončok wrote: > > According to the Fedora's Fails To Build From Source policy: > > > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > > > > > The following packages will be orphaned on Monday 2020-04-06. > > > > Their F32FTBFS Bugzillas are in NEW state for the defined period of time and > > they have the necessary reminders. They were not successfully rebuilt in > > Fedora > > 32 since the Bugzillas were opened. > > > > If you can fix your package to build, perform a build in koji, and either > > create > > an update in bodhi, or close the relevant bug without creating an update, if > > updating is not appropriate. If you are working on a fix, set the status to > > ASSIGNED to acknowledge this and prevent the orphaning. > > > > Oprhaning is a easily revertible nondesctructiove action. > > Only packages orphaned for 6+ weeks will be retired (removed from) Fedora > > rawhide (i.e. not form Fedora 32). > > Done. (snip) > Orphaned: > graphite2 > libaccounts-glib I've taken these two, since my packages transitively depend on them. The build failures don't look too difficult, I'll try to resolve them tomorrow. Fabio > -- > 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 ___ 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: Rawhide update from side tag pending for 2 days
On Tue, Apr 7, 2020 at 8:34 AM Fabio Valentini wrote: > > On Tue, Apr 7, 2020 at 8:56 AM Richard W.M. Jones wrote: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > > > This one is a Rawhide update from a side tag, submitted on Sunday > > morning which has been in pending for 2 days. (As it's Rawhide it's > > supposed to spend 0 days in testing.) Is there any problem with it, > > or do we just have to wait longer? It is blocking builds of other > > packages. > > Yeah, this update looks stuck ... the koji builds aren't even tagged > into the right tags yet, neither are they signed (from what I can > see). > > I seem to have the same - or at least a similar - issue with three > updates that are also stuck in pending for two days already (and the > builds are not even signed yet, either): > > - https://bodhi.fedoraproject.org/updates/FEDORA-2020-460f0f4d48 > - https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ea279079e > - https://bodhi.fedoraproject.org/updates/FEDORA-2020-755f442b4c This is a different case, can you file a ticket at https://pagure.io/releng/new_issue. I am guessing this is caused by the recent release of enabling side tags in now rawhide releases. > > Those three were also made from side tags, but for stable releases, so > I'm not sure whether it's the same issue or not. > > Fabio > > > Rich. > > > > -- > > Richard Jones, Virtualization Group, Red Hat > > http://people.redhat.com/~rjones > > Read my programming and virtualization blog: http://rwmj.wordpress.com > > virt-df lists disk usage of guests without needing to install any > > software inside the virtual machine. Supports Linux and Windows. > > http://people.redhat.com/~rjones/virt-df/ > > ___ > > 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 ___ 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: Rawhide update from side tag pending for 2 days
I guess it should be a fixed in bodhi. But for now you can remove the builds that it's complaining about in the update. https://github.com/fedora-infra/bodhi/issues/3991 On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones wrote: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > This one is a Rawhide update from a side tag, submitted on Sunday > morning which has been in pending for 2 days. (As it's Rawhide it's > supposed to spend 0 days in testing.) Is there any problem with it, > or do we just have to wait longer? It is blocking builds of other > packages. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > 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: CPE Weekly: 2020-04-04
On 4/6/20 5:19 AM, Alex Scheel wrote: It'd be interesting to see if the FESCo election system could be repurposed to get a sense of all packagers' opinions, rather than make assumptions on how the community as a whole feels based on a few vocal members and their participation in the mailing lists. I tend to think that a survey would be less useful than a list of dist-git integrations that will need to be rebuilt in order to move that service and an estimate of man-hours required, vs a list of feature gap and estimated cost to close it. ___ 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 33 System-Wide Change proposal: OpenSSL 3.0
https://fedoraproject.org/wiki/Changes/OpenSSL3.0 == Summary == The OpenSSL package is rebased to version 3.0 and the dependent packages are rebuilt. == Owner == * Name: [[User:Tmraz| Tomáš Mráz]] * Email: == Detailed Description == The OpenSSL 3.0 release is going to be a significantly new release with changed ABI however with minimal API changes. That means most of the dependent packages will need just a rebuild to work with the new OpenSSL package. However (at least temporarily) a compat-openssl11 package will be provided along the base package so the operation of the Rawhide is not disrupted. The OpenSSL 3.0 is still in development now but a first beta release should be done in June. After that time the work on the rebase will start and it should be possible to finish it still with a beta releases. Later releases up to the final one should not be disruptive and they should not break API/ABI. == Benefit to Fedora == This change introduces OpenSSL 3.0 with its significantly reworked internals which allow for better replacement of the crypto implementations via the [https://www.openssl.org/docs/OpenSSL300Design.html Crypto Providers] concept. == Scope == * Proposal owners: Provide a compat-openssl11 package, identify dependent packages, provide the rebased openssl package, work with dependent package owners on rebuilds. * Other developers: Dependent package owners rebuild their packages. Most of the dependencies will not require code changes but for some more fragile dependencies (mostly language bindings) there might be changes needed especially in the test cases which depend on some legacy behavior. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] If compat package is provided a mass rebuild should not be necessary. * Policies and guidelines: No update of packaging guidelines or other policies should be needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If compat-openssl11 package is provided there should be no issues with upgrades. == How To Test == If your application uses OpenSSL to communicate via TLS or perform other tasks that use cryptographic algorithms from OpenSSL, please test whether it continues to work properly. This should be covered by the comprehensive upstream testsuite of OpenSSL. However many dependent packages also provide good test coverage of OpenSSL functionality. == User Experience == There should be no impact on end-user experience. == Dependencies == There are many packages which depend on libssl or libcrypto from OpenSSL. Most of them should just work after rebuild with the new openssl package. However it is also not critically needed to rebuild everything at once if compat library compat-openssl11 package is provided. == Contingency Plan == If the openssl-3.0 is too unstable before the branching point of Fedora 33 we will not update the package and delay the change to Fedora 34. If the openssl is already updated but it is found out to be too unstable later we can revert to previous version however a rebuild of all dependencies that were already rebuilt will be needed. * Contingency mechanism: Revert package, rebuild updated dependencies. * Contingency deadline: Before release * Blocks release? No * Blocks product? No == Documentation == [https://www.openssl.org/docs/OpenSSL300Design.html OpenSSL 3.0 upstream design document] [https://www.openssl.org/policies/releasestrat.html OpenSSL 3.0 release schedule] == Release Notes == Fedora 33 comes with OpenSSL 3.0 as the primary OpenSSL package. It brings support for Crypto Providers interface. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: OpenSSL 3.0
https://fedoraproject.org/wiki/Changes/OpenSSL3.0 == Summary == The OpenSSL package is rebased to version 3.0 and the dependent packages are rebuilt. == Owner == * Name: [[User:Tmraz| Tomáš Mráz]] * Email: == Detailed Description == The OpenSSL 3.0 release is going to be a significantly new release with changed ABI however with minimal API changes. That means most of the dependent packages will need just a rebuild to work with the new OpenSSL package. However (at least temporarily) a compat-openssl11 package will be provided along the base package so the operation of the Rawhide is not disrupted. The OpenSSL 3.0 is still in development now but a first beta release should be done in June. After that time the work on the rebase will start and it should be possible to finish it still with a beta releases. Later releases up to the final one should not be disruptive and they should not break API/ABI. == Benefit to Fedora == This change introduces OpenSSL 3.0 with its significantly reworked internals which allow for better replacement of the crypto implementations via the [https://www.openssl.org/docs/OpenSSL300Design.html Crypto Providers] concept. == Scope == * Proposal owners: Provide a compat-openssl11 package, identify dependent packages, provide the rebased openssl package, work with dependent package owners on rebuilds. * Other developers: Dependent package owners rebuild their packages. Most of the dependencies will not require code changes but for some more fragile dependencies (mostly language bindings) there might be changes needed especially in the test cases which depend on some legacy behavior. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] If compat package is provided a mass rebuild should not be necessary. * Policies and guidelines: No update of packaging guidelines or other policies should be needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If compat-openssl11 package is provided there should be no issues with upgrades. == How To Test == If your application uses OpenSSL to communicate via TLS or perform other tasks that use cryptographic algorithms from OpenSSL, please test whether it continues to work properly. This should be covered by the comprehensive upstream testsuite of OpenSSL. However many dependent packages also provide good test coverage of OpenSSL functionality. == User Experience == There should be no impact on end-user experience. == Dependencies == There are many packages which depend on libssl or libcrypto from OpenSSL. Most of them should just work after rebuild with the new openssl package. However it is also not critically needed to rebuild everything at once if compat library compat-openssl11 package is provided. == Contingency Plan == If the openssl-3.0 is too unstable before the branching point of Fedora 33 we will not update the package and delay the change to Fedora 34. If the openssl is already updated but it is found out to be too unstable later we can revert to previous version however a rebuild of all dependencies that were already rebuilt will be needed. * Contingency mechanism: Revert package, rebuild updated dependencies. * Contingency deadline: Before release * Blocks release? No * Blocks product? No == Documentation == [https://www.openssl.org/docs/OpenSSL300Design.html OpenSSL 3.0 upstream design document] [https://www.openssl.org/policies/releasestrat.html OpenSSL 3.0 release schedule] == Release Notes == Fedora 33 comes with OpenSSL 3.0 as the primary OpenSSL package. It brings support for Crypto Providers interface. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: Rawhide update from side tag pending for 2 days
On Tue, Apr 7, 2020 at 8:57 AM Rex Dieter wrote: > > Richard W.M. Jones wrote: > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > > > This one is a Rawhide update from a side tag, submitted on Sunday > > morning which has been in pending for 2 days. (As it's Rawhide it's > > supposed to spend 0 days in testing.) Is there any problem with it, > > or do we just have to wait longer? It is blocking builds of other > > packages. > > I saw the same thing, and submitted a infra ticket about it, > https://pagure.io/fedora-infrastructure/issue/8819 In https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c, I can see that qt-creator-4.12.0-0.3.rc1.fc33 is the latest version and the latest build compared to the qt-creator-4.12.0-0.2.beta1.fc33 build in the update. You can remove the build from the update to move it to stable. > > -- Rex > ___ > 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: Replace buildroot overrides with user side tags?
This is a great idea, but I wouldn't recommend removing buildroot overrides totally for one more reason than the others that are already mentioned here. Side tags are resource intensive compared to buildroot override as each side tag needs its own buildroot. On Sat, Apr 4, 2020 at 5:02 PM Richard Shaw wrote: > > On Sat, Apr 4, 2020 at 3:52 PM Neal Gompa wrote: >> >> On Sat, Apr 4, 2020 at 4:50 PM Richard Shaw wrote: >> > >> > To be clear, I've only used them for rawhide, but can they be used in >> > other branches? >> > >> >> As of last Monday, yes. There are still some quirks to iron out, though... > > > Awesome! Not only are they easier to use but being able to choose the side > tag in the Bodhi web interface makes pushing the updates painless! > > Thanks, > Richard > ___ > 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: koji wait-repo (newRepo) is really taking a long time
Things should be getting better now https://pagure.io/koji/issue/2119#comment-640757 On Sat, Apr 4, 2020 at 5:13 AM Richard W.M. Jones wrote: > > On Sat, Apr 04, 2020 at 12:42:29AM +0200, Miro Hrončok wrote: > > On 03. 04. 20 13:03, Richard W.M. Jones wrote: > > > > > >I've been waiting on: > > > > > >$ koji wait-repo f33-build-side-20855 --build=ocaml-lacaml-9.3.2-17.fc33 > > > > > >for hours now. Seems like newRepo generation is again taking a very > > >long time? > > > > > >Also it'd be nice if this command didn't time out after 2 hours > > >(seems like a very odd and arbitrary choice - why not wait forever?) > > >and also coped with transient network failures. > > > > For timeout, there is: > > > > --timeout=TIMEOUT Amount of time to wait (in minutes) before giving up > > (default: 120) > > > > For network issues, I've been using: > > > > while ! koji wait-repo ...; do sleep 15; done > > > > ...quite successfully. > > Thanks, hopefully with this change it'll be more robust: > > http://git.annexia.org/?p=goals.git;a=commitdiff;h=cda1f0160b96e57a0037085f33aa2d440453a30b > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > 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: Fedora 33 Self-Contained Change proposal: Network Time Security
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: > On 4/6/20 4:08 PM, Ben Cotton wrote: > > [snip] > > > > > > It doesn't make much sense to me for this to default to on if we still > "trust" the DNS servers provided over DHCP. Additionally, it's not clear to > me from the proposal what it would take for an NTP server provided over DHCP > to be "trusted", or what a "trusted network" is. Are only NTS-enabled > sources to be trusted? > > What becomes of the old default fedora.pool.ntp.org? > > Finally, from a purely personal standpoint, I don't like seeing yet more > infrastructure being handed over to a hyperscaler like Cloudflare (see also > DoH in Firefox). I would be less opposed to this being default if > pool.ntp.org found a way to support it. I don't know the answers to your questions on the change, but just FYI, firefox in Fedora is not using DoH. 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
- Original Message - > From: "Stephen Gallagher" > To: devel-annou...@lists.fedoraproject.org > Sent: Monday, April 6, 2020 11:53:47 PM > Subject: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I've just published a fourth version[1] of the ELN proposal. With a > lot of input from Miro Hrončok, I think I've finally been able to > clarify some of the points that we were getting hung up on. > > Changes in this version of the proposal[2]: > > * Improve our explanation of why we are doing ELN in the first place > * Clarify the relationship with Rawhide > * Better describe what happens if packages don't build on ELN > * Explain our plan for when to use conditionals (this was getting a > larger share of the conversation than it warranted because we didn't > do a good job of explaining that they should be the exception and not > the rule) > * Clarify that the time limit on PRs is only for determining if the > maintainer is responsive. If they reply, the timer is cleared. > * Fixed the question about upstream features to make it clear that > what we meant is that new features should go upstream first, not be > implemented as a fork in ELN > * Added a section explaining how we will deal with side-tags > * Make it clear that we don't want to diverge wherever possible and > that any planned divergence should be discussed with the ELN SIG ahead > of time > * Cleaned up the contingency plan section. > > I hope that these changes will make our position more clear. Thank you > to everyone who has contributed to this discussion. I think the > feedback has been very valuable and I sincerely appreciate it. > > > > [1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > [2] > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=570854=570256 > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo > bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp > eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn > EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk > 3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/ > f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq > rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW > IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY > Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI > 8ShPIeos > =+lwN > -END PGP SIGNATURE- > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel-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 > I've glanced briefly through the changes, and while I didn't have time to properly solicit feedback on the info, I would like to say a big thank you for hearing our feedback and working with that. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher wrote: > I've just published a fourth version[1] of the ELN proposal. With a > lot of input from Miro Hrončok, I think I've finally been able to > clarify some of the points that we were getting hung up on. Up to this point, we've been a little vague on what "there will eventually be a way to maintain a fork of your package that will go into RHEL" actually means. I can finally make this clearer: - From now until RHEL 9 Alpha ships, work that is intended for inclusion in RHEL 9 should be contributed to Fedora Rawhide (later, F34 branch). After Alpha ships, a branch of CentOS Stream will open that will accept contributions towards RHEL 9 Beta. I'm pretty excited about this, myself. -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6MzJQACgkQRduFpWgo bRHp0Av9G5HQD5rdP9JQOtmk2bWfCIXLF0fabZrjPZogIyDVEeEfNQdyledQQnDQ RQWpwVP9nYeAjYAOSSAasSnN3jJ71uc08IOYQbHs1hSW+FSM06RNraan4r2rhYOj /fWBtwZGABDMLzNrwZqmD6xDtk93yFTo4TWIUWiOwjr02TIIL8A/xiat7TsMHJtS 90INry2rQ3qi5OeTTTHQf6bQPHP8FRNTIcgmispObJchHtAPbUKcn6n45b/L5mB6 94GVpYf56J3MLoJp2r5TbIdxuJMQSpVwPpk2AbjbWdAQA2SR8LSLU9+HAINiTKQV qBmOpHFGTK4e8+VE5W7pqo/sswDminRlCrXd/VQcx6C0jg/AWEQ21JG/DcRvDquP n8rMyMf7SKkpj2os3y63MfNXvbm3BHs1BT7znaLbopZG0GxorPsSE/MvwQX9HVka nXEGZn7pqXaUhOLWT8+hp0MSQUhkb2j0CVxESsM6AE6u/HGonBR8+T6cDpvP8/EO V1QcdQ6M =nb+r -END PGP SIGNATURE- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher wrote: > I've just published a fourth version[1] of the ELN proposal. With a > lot of input from Miro Hrončok, I think I've finally been able to > clarify some of the points that we were getting hung up on. Up to this point, we've been a little vague on what "there will eventually be a way to maintain a fork of your package that will go into RHEL" actually means. I can finally make this clearer: - From now until RHEL 9 Alpha ships, work that is intended for inclusion in RHEL 9 should be contributed to Fedora Rawhide (later, F34 branch). After Alpha ships, a branch of CentOS Stream will open that will accept contributions towards RHEL 9 Beta. I'm pretty excited about this, myself. -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6MzJQACgkQRduFpWgo bRHp0Av9G5HQD5rdP9JQOtmk2bWfCIXLF0fabZrjPZogIyDVEeEfNQdyledQQnDQ RQWpwVP9nYeAjYAOSSAasSnN3jJ71uc08IOYQbHs1hSW+FSM06RNraan4r2rhYOj /fWBtwZGABDMLzNrwZqmD6xDtk93yFTo4TWIUWiOwjr02TIIL8A/xiat7TsMHJtS 90INry2rQ3qi5OeTTTHQf6bQPHP8FRNTIcgmispObJchHtAPbUKcn6n45b/L5mB6 94GVpYf56J3MLoJp2r5TbIdxuJMQSpVwPpk2AbjbWdAQA2SR8LSLU9+HAINiTKQV qBmOpHFGTK4e8+VE5W7pqo/sswDminRlCrXd/VQcx6C0jg/AWEQ21JG/DcRvDquP n8rMyMf7SKkpj2os3y63MfNXvbm3BHs1BT7znaLbopZG0GxorPsSE/MvwQX9HVka nXEGZn7pqXaUhOLWT8+hp0MSQUhkb2j0CVxESsM6AE6u/HGonBR8+T6cDpvP8/EO V1QcdQ6M =nb+r -END PGP SIGNATURE- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:49 PM James Cassell wrote: > eln9.100.0 makes the relation to RHEL cycle obvious without looking like a > RHEL tag. Is dot allowed here? Do we need eln9_100_1? The dots would be permissible here. That said, can you describe what value you see in having the RHEL cycle represented in the RPM name? (Because that's basically the only practical effect here.) Particularly if you consider that we do not plan to have mass-rebuilds scheduled around RHEL releases, so a package that isn't updated for a long time after ELN starts tracking towards RHEL 10 is going to start confusing people the same way that having ".fc30" packages in Fedora 31 continues to do. I'm not saying "no", I'd just like to hear a clear value justification for carrying that number in the package name. ___ 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: Detecting when building under mock?
On Tue, 7 Apr 2020, Paul Howarth wrote: Is there a recommended way for detecting when a package is being built under mock? I have a package where some tests fail due to various things not being present in a mock container, e.g, /dev/log doesn't exist. I can just disable these tests downstream, but upstream might take a change if I can wrap them in a "if !mock" condition. Why not test for the presence of /dev/log before running such tests? Well, in the particular case of that test, checking whether /dev/log exists *is* the test. 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote: > On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa wrote: > > > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > > > understand why we want to disconnect the ELN version from the upcoming > > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > > > separate when we all know this is about building the next RHEL major, > > > > > and we all know what the next version is, and we all know the > > > > > timelines. > > > > > > > > Don't get me wrong, I am not trying to hide the fact that we are > > > > building RHEL type of packages. > > > > > > > > But > > > > 1) aligning those versions is a more complex task than it looks. > > > > > > > > Historically we had this %rhel macro to map to next release version > > > > working, because we were building Fedora content for RHEL only during > > > > the specific phase of RHEL development, where this number is known and > > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > > > it is not that clear when exactly the jump of this version will > > > > happen. Because of the continuity the mapping between eln packages and > > > > RHEL packages is less obvious: It depends on which phase internal RHEL > > > > development is. but more to that, it can depend on which phase the > > > > development of a specific package is, as some packages can diverge > > > > from upstream earlier than others. > > > > > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > > > EPEL to RHEL for example. And we probably will have to rethink it > > > > several times in the next couple of years. > > > > > > > > 2) we may need to bump version of the eln buildroot much more often > > > > than RHEL does major releases. > > > > > > > > As it comes from the use cases and the problem you have described, we > > > > want to actively experiment with the buildroot setup. So it makes > > > > sense to track it through versioning. > > > > > > > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > > > sense. With that adjustment, at least from my perspective I think this > > > is okay. > > > > The other piece of it is that there's a UX/psychological piece to it. > > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > > and confuse themselves into thinking it's a RHEL 9.1.0 package. That > > way lies a support nightmare. We absolutely agree with your assessment > > that the dist tag needs to be versioned (see my earlier mail), but we > > want to disambiguate it so it doesn't look like a real RHEL package. > > (I'm debating starting with a higher number like 100 so it doesn't get > > confused with Fedora or RHEL versions that we're likely to see any day > > soon.) > > I appreciate the amount of thought that went into that. It's not > something most people even consider, and I think your concerns are > well founded. Thanks for thinking that through! > eln9.100.0 makes the relation to RHEL cycle obvious without looking like a RHEL tag. Is dot allowed here? Do we need eln9_100_1? V/r, James Cassell ___ 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
[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1821881 --- Comment #1 from Guilherme de Almeida Suckevicz --- Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1821879,1821881 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1821881 Guilherme de Almeida Suckevicz changed: What|Removed |Added Blocks||1821879 (CVE-2013-7488) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1821879 [Bug 1821879] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821882] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8]
https://bugzilla.redhat.com/show_bug.cgi?id=1821882 --- Comment #1 from Guilherme de Almeida Suckevicz --- Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1821879,1821882 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821881] New: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1821881 Bug ID: 1821881 Summary: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all] Product: Fedora Version: 31 Status: NEW Component: perl-Convert-ASN1 Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: gsuck...@redhat.com QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821879] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input
https://bugzilla.redhat.com/show_bug.cgi?id=1821879 Guilherme de Almeida Suckevicz changed: What|Removed |Added Blocks||1821880 Depends On||1821881, 1821882 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1821881 [Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1821882 [Bug 1821882] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821882] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8]
https://bugzilla.redhat.com/show_bug.cgi?id=1821882 Guilherme de Almeida Suckevicz changed: What|Removed |Added Blocks||1821879 (CVE-2013-7488) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1821879 [Bug 1821879] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821879] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input
https://bugzilla.redhat.com/show_bug.cgi?id=1821879 --- Comment #1 from Guilherme de Almeida Suckevicz --- Created perl-Convert-ASN1 tracking bugs for this issue: Affects: epel-8 [bug 1821882] Affects: fedora-all [bug 1821881] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821882] New: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8]
https://bugzilla.redhat.com/show_bug.cgi?id=1821882 Bug ID: 1821882 Summary: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8] Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Convert-ASN1 Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: gsuck...@redhat.com QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of epel-8. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821879] New: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input
https://bugzilla.redhat.com/show_bug.cgi?id=1821879 Bug ID: 1821879 Summary: CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input Product: Security Response Hardware: All OS: Linux Status: NEW Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-t...@redhat.com Reporter: gsuck...@redhat.com CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, perl-maint-l...@redhat.com, ppi...@redhat.com, psab...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Other perl-Convert-ASN1 (aka the Convert::ASN1 module for Perl) through 0.27 allows remote attackers to cause an infinite loop via unexpected input. Reference: https://github.com/gbarr/perl-Convert-ASN1/issues/14 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Detecting when building under mock?
On Tue, 7 Apr 2020 11:43:26 -0400 (EDT) Scott Talbert wrote: > Is there a recommended way for detecting when a package is being > built under mock? I have a package where some tests fail due to > various things not being present in a mock container, e.g, /dev/log > doesn't exist. I can just disable these tests downstream, but > upstream might take a change if I can wrap them in a "if !mock" > condition. Why not test for the presence of /dev/log before running such tests? Paul. ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa wrote: > > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > > understand why we want to disconnect the ELN version from the upcoming > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > > separate when we all know this is about building the next RHEL major, > > > > and we all know what the next version is, and we all know the > > > > timelines. > > > > > > Don't get me wrong, I am not trying to hide the fact that we are > > > building RHEL type of packages. > > > > > > But > > > 1) aligning those versions is a more complex task than it looks. > > > > > > Historically we had this %rhel macro to map to next release version > > > working, because we were building Fedora content for RHEL only during > > > the specific phase of RHEL development, where this number is known and > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > > it is not that clear when exactly the jump of this version will > > > happen. Because of the continuity the mapping between eln packages and > > > RHEL packages is less obvious: It depends on which phase internal RHEL > > > development is. but more to that, it can depend on which phase the > > > development of a specific package is, as some packages can diverge > > > from upstream earlier than others. > > > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > > EPEL to RHEL for example. And we probably will have to rethink it > > > several times in the next couple of years. > > > > > > 2) we may need to bump version of the eln buildroot much more often > > > than RHEL does major releases. > > > > > > As it comes from the use cases and the problem you have described, we > > > want to actively experiment with the buildroot setup. So it makes > > > sense to track it through versioning. > > > > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > > sense. With that adjustment, at least from my perspective I think this > > is okay. > > The other piece of it is that there's a UX/psychological piece to it. > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > and confuse themselves into thinking it's a RHEL 9.1.0 package. That > way lies a support nightmare. We absolutely agree with your assessment > that the dist tag needs to be versioned (see my earlier mail), but we > want to disambiguate it so it doesn't look like a real RHEL package. > (I'm debating starting with a higher number like 100 so it doesn't get > confused with Fedora or RHEL versions that we're likely to see any day > soon.) I appreciate the amount of thought that went into that. It's not something most people even consider, and I think your concerns are well founded. Thanks for thinking that through! josh ___ 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 33 Self-Contained Change proposal: Network Time Security
On 4/6/20 4:08 PM, Ben Cotton wrote: [snip] It doesn't make much sense to me for this to default to on if we still "trust" the DNS servers provided over DHCP. Additionally, it's not clear to me from the proposal what it would take for an NTP server provided over DHCP to be "trusted", or what a "trusted network" is. Are only NTS-enabled sources to be trusted? What becomes of the old default fedora.pool.ntp.org? Finally, from a purely personal standpoint, I don't like seeing yet more infrastructure being handed over to a hyperscaler like Cloudflare (see also DoH in Firefox). I would be less opposed to this being default if pool.ntp.org found a way to support it. ___ 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: @core install picking up desktop packages
On Tue, Apr 07, 2020 at 11:46:20AM -0400, Steve Grubb wrote: > I think out of this whole experience, there might need to be a rule that any > weak depency added to a package in @Core should not result in pulling is a > nearly working desktop. Maybe that should also be extended to @Base? That's pretty much what the reporting produced by Minimization Objective [1] is looking at. There is no automatic enforcement though. [1] https://docs.fedoraproject.org/en-US/minimization/ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa wrote: > > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > > understand why we want to disconnect the ELN version from the upcoming > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > > separate when we all know this is about building the next RHEL major, > > > > and we all know what the next version is, and we all know the > > > > timelines. > > > > > > Don't get me wrong, I am not trying to hide the fact that we are > > > building RHEL type of packages. > > > > > > But > > > 1) aligning those versions is a more complex task than it looks. > > > > > > Historically we had this %rhel macro to map to next release version > > > working, because we were building Fedora content for RHEL only during > > > the specific phase of RHEL development, where this number is known and > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > > it is not that clear when exactly the jump of this version will > > > happen. Because of the continuity the mapping between eln packages and > > > RHEL packages is less obvious: It depends on which phase internal RHEL > > > development is. but more to that, it can depend on which phase the > > > development of a specific package is, as some packages can diverge > > > from upstream earlier than others. > > > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > > EPEL to RHEL for example. And we probably will have to rethink it > > > several times in the next couple of years. > > > > > > 2) we may need to bump version of the eln buildroot much more often > > > than RHEL does major releases. > > > > > > As it comes from the use cases and the problem you have described, we > > > want to actively experiment with the buildroot setup. So it makes > > > sense to track it through versioning. > > > > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > > sense. With that adjustment, at least from my perspective I think this > > is okay. > > The other piece of it is that there's a UX/psychological piece to it. > If we call it .eln9.1.0, people are quite likely to skim over the 'n' > and confuse themselves into thinking it's a RHEL 9.1.0 package. That > way lies a support nightmare. We absolutely agree with your assessment > that the dist tag needs to be versioned (see my earlier mail), but we > want to disambiguate it so it doesn't look like a real RHEL package. > (I'm debating starting with a higher number like 100 so it doesn't get > confused with Fedora or RHEL versions that we're likely to see any day > soon.) Okay then. :) -- 真実はいつも一つ！/ 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa wrote: > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > understand why we want to disconnect the ELN version from the upcoming > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > separate when we all know this is about building the next RHEL major, > > > and we all know what the next version is, and we all know the > > > timelines. > > > > Don't get me wrong, I am not trying to hide the fact that we are > > building RHEL type of packages. > > > > But > > 1) aligning those versions is a more complex task than it looks. > > > > Historically we had this %rhel macro to map to next release version > > working, because we were building Fedora content for RHEL only during > > the specific phase of RHEL development, where this number is known and > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > it is not that clear when exactly the jump of this version will > > happen. Because of the continuity the mapping between eln packages and > > RHEL packages is less obvious: It depends on which phase internal RHEL > > development is. but more to that, it can depend on which phase the > > development of a specific package is, as some packages can diverge > > from upstream earlier than others. > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > EPEL to RHEL for example. And we probably will have to rethink it > > several times in the next couple of years. > > > > 2) we may need to bump version of the eln buildroot much more often > > than RHEL does major releases. > > > > As it comes from the use cases and the problem you have described, we > > want to actively experiment with the buildroot setup. So it makes > > sense to track it through versioning. > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > sense. With that adjustment, at least from my perspective I think this > is okay. The other piece of it is that there's a UX/psychological piece to it. If we call it .eln9.1.0, people are quite likely to skim over the 'n' and confuse themselves into thinking it's a RHEL 9.1.0 package. That way lies a support nightmare. We absolutely agree with your assessment that the dist tag needs to be versioned (see my earlier mail), but we want to disambiguate it so it doesn't look like a real RHEL package. (I'm debating starting with a higher number like 100 so it doesn't get confused with Fedora or RHEL versions that we're likely to see any day soon.) ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:11 PM Aleksandra Fedorova wrote:
>
> On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa wrote:
> >
> > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok wrote:
> > > >
> > > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > > > >> What I'm confused about is the hangup with versioning the ELN tree.
> > > > >> Why is this a problem?
> > > > > I explained it in one of the previous threads:
> > > > >
> > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > > >
> > > > > But I guess we need to extend this conversion by answering:
> > > > > 1) versioning of what exactly?
> > > > > 2) versioning by which number?
> > > > >
> > > > > From the problem you describe, it looks like the solution for it is
> > > > > to
> > > > > have %{?dist} resolved to a versioned data. But the versioning here
> > > > > should be independent from both RHEL and Fedora versioning. It should
> > > > > be based on changes in eln buildroot configuration itself: As soon as
> > > > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > > > And this action is not linked to Fedora or RHEL releases. This number
> > > > > may as well be the date, or a simple counter.
> > > > >
> > > > > If we do versioning in this way, then it resolves both concerns I had
> > > > > in my reply there:
> > > > > 1) we don't try to link to particular RHEL release;
> > > > > 2) we don't version the koji tag and target, and we don't need to
> > > > > update Koji configuration every time Fedora creates a branch. Thus the
> > > > > pipelines we create for building eln packages can still be
> > > > > unversioned.
> > > >
> > > >
> > > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > > > particular "the versioning here should be independent from RHEL" and
> > > > "we don't
> > > > try to link to particular RHEL release" is very weird considering that
> > > > %{eln}
> > > > and %{rhel} will evaluate to "next RHEL version".
> > >
> > > You are right. Originally we were thinking of %{eln} as a boolean,
> > > rather than a meaningful data. So the important part was that we set
> > > it to something, so that in those very rare cases where we may want to
> > > have a condition based on eln, we can use it.
> > > We defined %{eln} to be "something", and that something just happened
> > > to be %{rhel}.
> > >
> > > But since we are talking about versioning for eln now, it makes sense
> > > to use this macro to store the actual data about eln buildroot.
> > >
> > > So I am thinking of adjusting the change in the following form:
> > >
> > >
> > > * %{rhel} will be set and will return a number one higher than the
> > > most recent major release of Red Hat Enterprise Linux (at present,
> > > that will be 9).
> > > * %{eln} will be set and will expand to the ELN version (independent
> > > of Fedora and RHEL) in a format "X.Y". X will be bumped for mass
> > > rebuilds, Y - for other changes.
> > > * %{dist} will be set to "eln%{eln}"
> > >
> > > Explicit usage of %{eln} macro in spec files should be discouraged. As
> > > its main purpose is the versioning of the build environment, not
> > > adjusting the sources.
> > >
> > >
> > > This way we can experiment with the configuration ELN-buildroot
> > > without bumping package sources.
> > >
> > > And we will have RHEL versioning available, but not directly, which
> > > adds some flexibility in relation between ELN and RHEL.
> > >
> >
> > This definitely solves the issue I've been thinking of. I'm not sure I
> > understand why we want to disconnect the ELN version from the upcoming
> > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > separate when we all know this is about building the next RHEL major,
> > and we all know what the next version is, and we all know the
> > timelines.
>
> Don't get me wrong, I am not trying to hide the fact that we are
> building RHEL type of packages.
>
> But
> 1) aligning those versions is a more complex task than it looks.
>
> Historically we had this %rhel macro to map to next release version
> working, because we were building Fedora content for RHEL only during
> the specific phase of RHEL development, where this number is known and
> fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
> it is not that clear when exactly the jump of this version will
> happen. Because of the continuity the mapping between eln packages and
> RHEL packages is less obvious: It depends on which phase internal RHEL
> development is. but more to that, it can depend on which phase the
> development of a specific package is, as some packages can diverge
> from upstream earlier than others.
>
> So this eln to rhel mapping is a more complicated topic, then mapping
> EPEL to
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa wrote:
>
> On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova wrote:
> >
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok wrote:
> > >
> > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > > >> What I'm confused about is the hangup with versioning the ELN tree.
> > > >> Why is this a problem?
> > > > I explained it in one of the previous threads:
> > > >
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > >
> > > > But I guess we need to extend this conversion by answering:
> > > > 1) versioning of what exactly?
> > > > 2) versioning by which number?
> > > >
> > > > From the problem you describe, it looks like the solution for it is to
> > > > have %{?dist} resolved to a versioned data. But the versioning here
> > > > should be independent from both RHEL and Fedora versioning. It should
> > > > be based on changes in eln buildroot configuration itself: As soon as
> > > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > > And this action is not linked to Fedora or RHEL releases. This number
> > > > may as well be the date, or a simple counter.
> > > >
> > > > If we do versioning in this way, then it resolves both concerns I had
> > > > in my reply there:
> > > > 1) we don't try to link to particular RHEL release;
> > > > 2) we don't version the koji tag and target, and we don't need to
> > > > update Koji configuration every time Fedora creates a branch. Thus the
> > > > pipelines we create for building eln packages can still be
> > > > unversioned.
> > >
> > >
> > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > > particular "the versioning here should be independent from RHEL" and "we
> > > don't
> > > try to link to particular RHEL release" is very weird considering that
> > > %{eln}
> > > and %{rhel} will evaluate to "next RHEL version".
> >
> > You are right. Originally we were thinking of %{eln} as a boolean,
> > rather than a meaningful data. So the important part was that we set
> > it to something, so that in those very rare cases where we may want to
> > have a condition based on eln, we can use it.
> > We defined %{eln} to be "something", and that something just happened
> > to be %{rhel}.
> >
> > But since we are talking about versioning for eln now, it makes sense
> > to use this macro to store the actual data about eln buildroot.
> >
> > So I am thinking of adjusting the change in the following form:
> >
> >
> > * %{rhel} will be set and will return a number one higher than the
> > most recent major release of Red Hat Enterprise Linux (at present,
> > that will be 9).
> > * %{eln} will be set and will expand to the ELN version (independent
> > of Fedora and RHEL) in a format "X.Y". X will be bumped for mass
> > rebuilds, Y - for other changes.
> > * %{dist} will be set to "eln%{eln}"
> >
> > Explicit usage of %{eln} macro in spec files should be discouraged. As
> > its main purpose is the versioning of the build environment, not
> > adjusting the sources.
> >
> >
> > This way we can experiment with the configuration ELN-buildroot
> > without bumping package sources.
> >
> > And we will have RHEL versioning available, but not directly, which
> > adds some flexibility in relation between ELN and RHEL.
> >
>
> This definitely solves the issue I've been thinking of. I'm not sure I
> understand why we want to disconnect the ELN version from the upcoming
> RHEL version, even in the DistTag? It seems to be a weird hoop to
> separate when we all know this is about building the next RHEL major,
> and we all know what the next version is, and we all know the
> timelines.
Don't get me wrong, I am not trying to hide the fact that we are
building RHEL type of packages.
But
1) aligning those versions is a more complex task than it looks.
Historically we had this %rhel macro to map to next release version
working, because we were building Fedora content for RHEL only during
the specific phase of RHEL development, where this number is known and
fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
it is not that clear when exactly the jump of this version will
happen. Because of the continuity the mapping between eln packages and
RHEL packages is less obvious: It depends on which phase internal RHEL
development is. but more to that, it can depend on which phase the
development of a specific package is, as some packages can diverge
from upstream earlier than others.
So this eln to rhel mapping is a more complicated topic, then mapping
EPEL to RHEL for example. And we probably will have to rethink it
several times in the next couple of years.
2) we may need to bump version of the eln buildroot much more often
than RHEL does major releases.
As it comes from the use cases and the problem you have described, we
want
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:02 PM Stephen Gallagher wrote:
>
> On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa wrote:
> > This definitely solves the issue I've been thinking of. I'm not sure I
> > understand why we want to disconnect the ELN version from the upcoming
> > RHEL version, even in the DistTag? It seems to be a weird hoop to
> > separate when we all know this is about building the next RHEL major,
> > and we all know what the next version is, and we all know the
> > timelines.
>
> It's not about being cagey about the release, it's actually about us
> retaining the ability to perform a rebuild without needing to push a
> release-bump into the Fedora dist-git for issues that are
> ELN-specific. (For example, ELN might carry a link-time-optimization
> flag that we discover causes bugs to appear on certain packages. That
> flag isn't used on Fedora, so we wouldn't want to bother the
> maintainer with a version bump. We'd just bump the Y value of %{eln}
> and resubmit it to Koji, which would then not have a duplicate NEVRA
> appearing.
That part I get... I mean, why not eln%{rhel}.X.Y?
--
真実はいつも一つ！/ 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa wrote:
> This definitely solves the issue I've been thinking of. I'm not sure I
> understand why we want to disconnect the ELN version from the upcoming
> RHEL version, even in the DistTag? It seems to be a weird hoop to
> separate when we all know this is about building the next RHEL major,
> and we all know what the next version is, and we all know the
> timelines.
It's not about being cagey about the release, it's actually about us
retaining the ability to perform a rebuild without needing to push a
release-bump into the Fedora dist-git for issues that are
ELN-specific. (For example, ELN might carry a link-time-optimization
flag that we discover causes bugs to appear on certain packages. That
flag isn't used on Fedora, so we wouldn't want to bother the
maintainer with a version bump. We'd just bump the Y value of %{eln}
and resubmit it to Koji, which would then not have a duplicate NEVRA
appearing.
___
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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova wrote:
>
> Hi,
>
> On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok wrote:
> >
> > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > >> What I'm confused about is the hangup with versioning the ELN tree.
> > >> Why is this a problem?
> > > I explained it in one of the previous threads:
> > >
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > >
> > > But I guess we need to extend this conversion by answering:
> > > 1) versioning of what exactly?
> > > 2) versioning by which number?
> > >
> > > From the problem you describe, it looks like the solution for it is to
> > > have %{?dist} resolved to a versioned data. But the versioning here
> > > should be independent from both RHEL and Fedora versioning. It should
> > > be based on changes in eln buildroot configuration itself: As soon as
> > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > And this action is not linked to Fedora or RHEL releases. This number
> > > may as well be the date, or a simple counter.
> > >
> > > If we do versioning in this way, then it resolves both concerns I had
> > > in my reply there:
> > > 1) we don't try to link to particular RHEL release;
> > > 2) we don't version the koji tag and target, and we don't need to
> > > update Koji configuration every time Fedora creates a branch. Thus the
> > > pipelines we create for building eln packages can still be
> > > unversioned.
> >
> >
> > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > particular "the versioning here should be independent from RHEL" and "we
> > don't
> > try to link to particular RHEL release" is very weird considering that
> > %{eln}
> > and %{rhel} will evaluate to "next RHEL version".
>
> You are right. Originally we were thinking of %{eln} as a boolean,
> rather than a meaningful data. So the important part was that we set
> it to something, so that in those very rare cases where we may want to
> have a condition based on eln, we can use it.
> We defined %{eln} to be "something", and that something just happened
> to be %{rhel}.
>
> But since we are talking about versioning for eln now, it makes sense
> to use this macro to store the actual data about eln buildroot.
>
> So I am thinking of adjusting the change in the following form:
>
>
> * %{rhel} will be set and will return a number one higher than the
> most recent major release of Red Hat Enterprise Linux (at present,
> that will be 9).
> * %{eln} will be set and will expand to the ELN version (independent
> of Fedora and RHEL) in a format "X.Y". X will be bumped for mass
> rebuilds, Y - for other changes.
> * %{dist} will be set to "eln%{eln}"
>
> Explicit usage of %{eln} macro in spec files should be discouraged. As
> its main purpose is the versioning of the build environment, not
> adjusting the sources.
>
>
> This way we can experiment with the configuration ELN-buildroot
> without bumping package sources.
>
> And we will have RHEL versioning available, but not directly, which
> adds some flexibility in relation between ELN and RHEL.
>
This definitely solves the issue I've been thinking of. I'm not sure I
understand why we want to disconnect the ELN version from the upcoming
RHEL version, even in the DistTag? It seems to be a weird hoop to
separate when we all know this is about building the next RHEL major,
and we all know what the next version is, and we all know the
timelines.
--
真実はいつも一つ！/ 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
Hi,
On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok wrote:
>
> On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> >> What I'm confused about is the hangup with versioning the ELN tree.
> >> Why is this a problem?
> > I explained it in one of the previous threads:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> >
> > But I guess we need to extend this conversion by answering:
> > 1) versioning of what exactly?
> > 2) versioning by which number?
> >
> > From the problem you describe, it looks like the solution for it is to
> > have %{?dist} resolved to a versioned data. But the versioning here
> > should be independent from both RHEL and Fedora versioning. It should
> > be based on changes in eln buildroot configuration itself: As soon as
> > we want to have a non-disruptive rebuild in eln buildroot, we
> > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > And this action is not linked to Fedora or RHEL releases. This number
> > may as well be the date, or a simple counter.
> >
> > If we do versioning in this way, then it resolves both concerns I had
> > in my reply there:
> > 1) we don't try to link to particular RHEL release;
> > 2) we don't version the koji tag and target, and we don't need to
> > update Koji configuration every time Fedora creates a branch. Thus the
> > pipelines we create for building eln packages can still be
> > unversioned.
>
>
> What you say here is very inconsistent with %{eln} and %{rhel} value. In
> particular "the versioning here should be independent from RHEL" and "we don't
> try to link to particular RHEL release" is very weird considering that %{eln}
> and %{rhel} will evaluate to "next RHEL version".
You are right. Originally we were thinking of %{eln} as a boolean,
rather than a meaningful data. So the important part was that we set
it to something, so that in those very rare cases where we may want to
have a condition based on eln, we can use it.
We defined %{eln} to be "something", and that something just happened
to be %{rhel}.
But since we are talking about versioning for eln now, it makes sense
to use this macro to store the actual data about eln buildroot.
So I am thinking of adjusting the change in the following form:
* %{rhel} will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be 9).
* %{eln} will be set and will expand to the ELN version (independent
of Fedora and RHEL) in a format "X.Y". X will be bumped for mass
rebuilds, Y - for other changes.
* %{dist} will be set to "eln%{eln}"
Explicit usage of %{eln} macro in spec files should be discouraged. As
its main purpose is the versioning of the build environment, not
adjusting the sources.
This way we can experiment with the configuration ELN-buildroot
without bumping package sources.
And we will have RHEL versioning available, but not directly, which
adds some flexibility in relation between ELN and RHEL.
>
> --
> 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
--
--
Aleksandra Fedorova
bookwar
___
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 32 compose report: 20200407.n.0 changes
OLD: Fedora-32-20200406.n.0 NEW: Fedora-32-20200407.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 2 Dropped packages:1 Upgraded packages: 46 Downgraded packages: 0 Size of added packages: 1.72 MiB Size of dropped packages:17.30 MiB Size of upgraded packages: 3.11 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -212.80 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-32-20200406.n.0.iso = ADDED PACKAGES = Package: ghc-path-io-1.4.2-1.fc32 Summary: Interface to ???directory??? package for users of ???path??? RPMs:ghc-path-io ghc-path-io-devel ghc-path-io-doc ghc-path-io-prof Size:1.36 MiB Package: python-pysmt-0.8.0-2.fc32 Summary: Solver-agnostic library for SMT Formulae manipulation and solving RPMs:python3-pysmt Size:370.49 KiB = DROPPED PACKAGES = Package: mutter328-3.28.4-7.fc32 Summary: Window and compositing manager based on Clutter RPMs:mutter328 mutter328-devel mutter328-libs mutter328-tests Size:17.30 MiB = UPGRADED PACKAGES = Package: Zim-0.72.1-1.fc32 Old package: Zim-0.72.0-2.fc32 Summary: Desktop wiki & notekeeper RPMs: Zim Size: 1.70 MiB Size change: 2.33 KiB Changelog: * Sun Mar 29 2020 Robin Lee - 0.72.1-1 - Update to 0.72.1 Package: aircrack-ng-1.6-1.fc32 Old package: aircrack-ng-1.5.2-8.fc32 Summary: 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker RPMs: aircrack-ng aircrack-ng-devel aircrack-ng-doc Added RPMs: aircrack-ng-devel aircrack-ng-doc Size: 6.01 MiB Size change: -9.17 MiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 1.5.2-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Mon Apr 06 2020 Vitaly Zaitsev - 1.6-1 - Resurrected package. - Updated to version 1.6. - Performed SPEC cleanup. Package: anaconda-32.24.5-1.fc32 Old package: anaconda-32.24.4-1.fc32 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 19.26 MiB Size change: 8.98 KiB Changelog: * Fri Apr 03 2020 Martin Kolman - 32.24.5-1 - Don't clear errors by expanding pages in the custom spoke (vponcova) - Fix the permission for changing a mount point (#1818500) (vponcova) - Allow to use an existing unlocked LUKS in one special case (#1772902) (vponcova) - Fix the encryption checkbox in the custom spoke (#1819360) (vponcova) - Don't manually trigger a device encryption change (vponcova) - Rename _test_dbus_property to _check_dbus_property (jkonecny) Package: astrometry-0.78-6.fc32 Old package: astrometry-0.78-5.fc32 Summary: Blind astrometric calibration of arbitrary astronomical images RPMs: astrometry astrometry-data astrometry-data-4204 astrometry-data-4205 astrometry-data-4206 astrometry-data-4207 astrometry-devel astrometry-libs python3-astrometry Size: 1.77 GiB Size change: -57.43 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 0.78-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild Package: astrometry-tycho2-2.0-8.fc32 Old package: astrometry-tycho2-2.0-6.fc31 Summary: Tycho-2 catalogue for astrometry.net RPMs: astrometry-tycho2 Size: 812.71 MiB Size change: -205.05 MiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 2.0-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sun Mar 29 2020 Mattia Verga - 2.0-8 - Temporarily disable s390 due to astrometry dependency Package: atk-2.36.0-1.fc32 Old package: atk-2.35.1-2.fc32 Summary: Interfaces for accessibility support RPMs: atk atk-devel Size: 2.61 MiB Size change: 25.60 KiB Changelog: * Thu Apr 02 2020 Kalev Lember - 2.36.0-1 - Update to 2.36.0 Package: boost-1.69.0-15.fc32 Old package: boost-1.69.0-14.fc32 Summary: The free peer-reviewed portable C++ source libraries RPMs: boost boost-atomic boost-build boost-chrono boost-container boost-context boost-contract boost-coroutine boost-date-time boost-devel boost-doc boost-doctools boost-examples boost-fiber boost-filesystem boost-graph boost-graph-mpich boost-graph-openmpi boost-iostreams boost-jam boost-locale boost-log boost-math boost-mpich boost-mpich-devel boost-mpich-python3 boost-mpich-python3-devel boost-numpy3 boost-openmpi boost-openmpi-devel boost-openmpi-python3 boost-openmpi-python3-devel boost-program-options boost-python3 boost-python3-devel boost-random boost-regex boost-serialization boost-stacktrace boost-static boost-system boost-test boost-thread boost-timer boost-type_erasure boost-wave Size: 310.18 MiB Size change: -18
Logs for the Open NeuroFedora Meeting: 1600 UTC on Tuesday, 4th April
Hello people Thanks for attending the meeting. We shall meet in two weeks' time. I will share a whenisgood to the NeuroFedora ML to schedule a suitable time for the next meeting. Links to the logs from today's meeting: - https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.log.html - https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.html Minutes of the meeting in text: === #fedora-neuro: NeuroFedora - 2020-04-07 === Meeting started by MeWjOr at 16:02:30 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.log.html . Meeting summary --- * Agenda for today's meeting (MeWjOr, 16:05:47) * Intros/roll call (MeWjOr, 16:05:56) * Tasks from last meeting: https://meetbot.fedoraproject.org/fedora-neuro/2020-03-24/neurofedora.2020-03-24-16.00.html (MeWjOr, 16:06:07) * Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting (MeWjOr, 16:06:14) * Bugzilla tickets: https://tinyurl.com/neurofedora-bugs (MeWjOr, 16:06:20) * (neuro)science query of the week (MeWjOr, 16:06:30) * Next meeting, time, date, chair (MeWjOr, 16:06:37) * Open floor (MeWjOr, 16:06:43) * Intros/Roll call (MeWjOr, 16:07:01) * Tasks from last meeting: https://meetbot.fedoraproject.org/fedora-neuro/2020-03-24/neurofedora.2020-03-24-16.00.html (MeWjOr, 16:12:21) * FranciscoD submit 3 banner candidates to websites - Done (MeWjOr, 16:12:58) * FranciscoD submit apps and logos to websites - Done (MeWjOr, 16:13:36) * FranciscoD submit all the content to websites - Done (MeWjOr, 16:13:47) * https://pagure.io/fedora-websites/issue/1010 (MeWjOr, 16:13:55) * FranciscoD include open position call for: social media manager, package maintainers, testers in next blog post --- The tracker for the post is up: https://pagure.io/neuro-sig/NeuroFedora/issue/348 (MeWjOr, 16:14:40) * mhough write a blog post about the neurotecx online meetings - status: pending (MeWjOr, 16:15:18) * Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting (MeWjOr, 16:17:15) * NeuroFedora Brochure: https://pagure.io/neuro-sig/NeuroFedora/issue/301 (MeWjOr, 16:18:33) * ACTION: FranciscoD Comment on the ticket to provide feedback on the neurofedora brochure within the next week (MeWjOr, 16:23:34) * ACTION: MeWjOr Send a mail to the members so that they can provide feedback on the neurofedora brochure within the next week (MeWjOr, 16:24:09) * Next blog post: https://pagure.io/neuro-sig/NeuroFedora/issue/348 (MeWjOr, 16:24:57) * Bugzilla bugs: https://tinyurl.com/neurofedora-bugs (MeWjOr, 16:32:08) * Next meeting: time, date, chair (MeWjOr, 16:37:13) * ACTION: MeWjOr set up a new whenisgood and inform ML (FranciscoD, 16:49:08) * ACTION: lbazan to work on pending review tickets (FranciscoD, 16:49:28) * (neuro)science query of the week (MeWjOr, 16:51:23) * LINK: https://alleninstitute.org/what-we-do/brain-science/news-press/press-releases/allen-institute-announces-new-phase-neuroscience-research (FranciscoD, 16:51:34) * https://pagure.io/neuro-sig/NeuroFedora/issue/318 (MeWjOr, 16:52:46) * LINK: https://sourceforge.net/projects/genesis-sim/lists/genesis-sim-users -> I'll go subscribe to that too (FranciscoD, 16:56:32) * ACTION: MeWjOr send out the meeting logs to the ML (MeWjOr, 16:57:08) Meeting ended at 16:57:17 UTC. Action Items * FranciscoD Comment on the ticket to provide feedback on the neurofedora brochure within the next week * MeWjOr Send a mail to the members so that they can provide feedback on the neurofedora brochure within the next week * MeWjOr set up a new whenisgood and inform ML * lbazan to work on pending review tickets * MeWjOr send out the meeting logs to the ML Action Items, by person --- * FranciscoD * FranciscoD Comment on the ticket to provide feedback on the neurofedora brochure within the next week * lbazan * lbazan to work on pending review tickets * MeWjOr * MeWjOr Send a mail to the members so that they can provide feedback on the neurofedora brochure within the next week * MeWjOr set up a new whenisgood and inform ML * MeWjOr send out the meeting logs to the ML * **UNASSIGNED** * (none) People Present (lines said) --- * MeWjOr (98) * FranciscoD (76) * mhough (16) * zodbot (13) * lbazan (13) * tg-fedneuro (11) * fm-neuro (7) * gicmo (2) * alciregi (0) * bt0 (0) * zbyszek (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Thanks Regards Aniket Pradhan http://home.iiitd.edu.in/~aniket17133/ Aliases: MeWjOr/major () ascii ribbon campaign - against html e-mail /\
Re: Modularity Survey
On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote: > I'm sure we can trust that Red Hat did its > > due diligence and Google isn't using responses to a customer's form to > > track those taking the survey. I don't really know why you'd think anyone can trust that. Google tracks everyone everywhere as hard as it can. It's what Google *does*. But I didn't actually suggest it's Terribly Awful to run this survey through Google. I just said the privacy declaration seems to be wrong. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Modularity Survey
- Original Message - > From: "Xavier Bachelot" > To: "Development discussions related to Fedora" > , "Kevin Kofler" > > Sent: Tuesday, April 7, 2020 12:15:37 PM > Subject: Re: Modularity Survey > > Le 07/04/2020 à 12:29, Kevin Kofler a écrit : > > Adam Williamson wrote: > >> Well. Uh. Clearly it's being provided to *Google*. > > > > Indeed. Once again, Fedora is depending on third-party, proprietary, > > privacy-invading SaaS. > > > > Meets exactly my thoughts... > This is yet again another disappointing choice of tool. > > I'm not going to give anything to Google, hence I can _not_ answer the > survey. > Too bad, there is much to be said about modularity, as the lengthy > threads have already shown. > > Unfortunately, Fedora is drifting more and more away from the Libre > Software philosophy that over time made me a Linux-only user and a > Fedora packager. At some point, I will have to put my money where my > mouth is and find another ship. > Yes, I'm bitter... (I'm not on the modularity team). Look folks. This isn't a Fedora-only survey. It is a survey run by Red Hat members who are looking to engage with a community that includes Fedora, Red Hat, CentOS and a bunch of other stakeholders as well. I think we can all recognize that Google Apps usage is high among businesses. Yeah, if this were a Fedora-only survey, we all would've hoped they'd go for an open source tool. But it isn't Fedora-only. And pretending like it matters for this IMO, isn't a legitimate complaint. This is a business backed Google Apps account. I'm sure we can trust that Red Hat did its due diligence and Google isn't using responses to a customer's form to track those taking the survey. But by definition, they need to hold a copy of that data. Someone, somewhere would. That's how the internet works. I sit on the new Modularity meetings now. I'll be the first to admit I'm not a strong supporter of Modularity. I've been very vocal against it in the past. But I do think that this new team is honestly trying to do the right thing and engage with the community. They aren't trying to push features top-down and they're trying to understand what is wrong and are trying their best to fix it. Part of that is collecting data and stories from people. If we, as a community, push them away now, we'll never see any much-needed improvements to modularity. And tbh, I'm not even sure we're in a place now where we could remove it if we truly needed to, without a lot of pain in the upgrade path. Let's try and be reasonable here. I'm willing to pass along any comments people have individually. Thanks, - Alex > Regards, > Xavier > ___ > 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
[Bug 1821832] New: perl-Dancer2-0.300002 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821832 Bug ID: 1821832 Summary: perl-Dancer2-0.32 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Dancer2 Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.32 Current version/release in rawhide: 0.31-1.fc33 URL: http://search.cpan.org/dist/Dancer2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5847/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Modularity Survey
Le 07/04/2020 à 12:29, Kevin Kofler a écrit : Adam Williamson wrote: Well. Uh. Clearly it's being provided to *Google*. Indeed. Once again, Fedora is depending on third-party, proprietary, privacy-invading SaaS. Meets exactly my thoughts... This is yet again another disappointing choice of tool. I'm not going to give anything to Google, hence I can _not_ answer the survey. Too bad, there is much to be said about modularity, as the lengthy threads have already shown. Unfortunately, Fedora is drifting more and more away from the Libre Software philosophy that over time made me a Linux-only user and a Fedora packager. At some point, I will have to put my money where my mouth is and find another ship. Yes, I'm bitter... Regards, Xavier ___ 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: libcdio soname bump in rawhide
On Mon, Mar 30, 2020 at 09:27:56AM +0200, Adrian Reber wrote: > I will update libcdio to 2.1.0 next week in rawhide. As always, libcdio > comes with a new SO version. > > The following packages have to be rebuilt and I will do the necessary > rebuilds: > > cantata > cdw > clementine > gstreamer1-plugins-ugly-free > gvfs > kover > libcddb > libcdio-0:2.0.0-6.fc32.src > libcdio-paranoia > pcsxr > pragha > python-pycdio > qmmp > strawberry > tellico > whipper > xmms2 libcdio, libcdio-paranoia and python-pycdio have been updated and all dependencies have been rebuilt. Only pcsxr failed rebuilding but it was already FTBFS before the libcdio upgrade. Adrian 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
[Bug 1821789] New: perl-Data-Dmp-0.240 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821789 Bug ID: 1821789 Summary: perl-Data-Dmp-0.240 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Data-Dmp Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.240 Current version/release in rawhide: 0.23-8.fc32 URL: http://search.cpan.org/dist/Data-Dmp/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/15736/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Test-Announce] Fedora 32 Branched 20200407.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 32 Branched 20200407.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 - 20200404.n.0: anaconda-32.24.4-1.fc32.src, 20200407.n.0: anaconda-32.24.5-1.fc32.src lorax - 20200404.n.0: lorax-32.5-2.fc32.src, 20200407.n.0: lorax-32.8-1.fc32.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/32 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_32_Branched_20200407.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200407.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: @core install picking up desktop packages
On Tuesday, April 7, 2020 11:24:28 AM EDT Adam Williamson wrote: > On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote: > > On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote: > > > Maybe libsecret spec could provide an empty libsecret-never-fail > > > subpackage that would hard-require a libsecret server and the > > > applications like geary would require that subpackage. (Alternatively > > > libsecret-devel could provide a RPM macro that the applications use to > > > add a direct dependency on a server.) But this abstractions is quite > > > academic provided the only libsecret server in Fedora is > > > gnome-keyring. > > > > I wouldn't focus on a particular package because the situation can > > repeat with any other package in the future, and would make the question > > more generic. > > > > Is it expected, are we OK with the fact, that with default settings > > of weak dependencies enabled in dnf and anaconda, installing @group > > can eventually pull in way more packages than originally listed > > in the group, beyond the hard dependencies? Should following the weak > > dependencies be a boolean yes/no setting, or should it be a score and > > should the resolver have an option to favour weak dependencies when > > resolving the first level of depenencies from the original package > > list but decrease (perhaps radically) favouring them in next and > > next-next-levels, potentially even taking into account if the > > intermediate dependencies were explicit ones or implicit libraries? > > > > In other words, if I list packages A, B, C in transaction, I might > > want to have their weak dependencies thrown onto the system as well. > > But if A requires libX.so and libY.so, and package X requires G and > > that has weak dependency on K, I might not care about K. > > > > If I explicitly say I want G, then again, sure, give me K as well. > > Boy, I don't know about you but I sure am looking forward to taking a > degree in math to understand why packages are or are not installed! I think out of this whole experience, there might need to be a rule that any weak depency added to a package in @Core should not result in pulling is a nearly working desktop. Maybe that should also be extended to @Base? -Steve ___ 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
Detecting when building under mock?
Is there a recommended way for detecting when a package is being built under mock? I have a package where some tests fail due to various things not being present in a mock container, e.g, /dev/log doesn't exist. I can just disable these tests downstream, but upstream might take a change if I can wrap them in a "if !mock" condition. Thanks, 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: Updated review trackers pages
On 4/7/20 9:21 AM, Mattia Verga via devel wrote:
> we have updated the script which provides the cached review trackers
> pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to
> cverna for the assistance).
It looks like 1821497 [1] is displayed incorrectly (currently at the
bottom of the page), maybe bccause of the unusual title ("Review
Request: - ")?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1821497
___
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: @core install picking up desktop packages
On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote: > On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote: > > Maybe libsecret spec could provide an empty libsecret-never-fail subpackage > > that would hard-require a libsecret server and the applications like geary > > would > > require that subpackage. (Alternatively libsecret-devel could provide a RPM > > macro that the applications use to add a direct dependency on a server.) But > > this abstractions is quite academic provided the only libsecret server in > > Fedora is gnome-keyring. > > I wouldn't focus on a particular package because the situation can > repeat with any other package in the future, and would make the question > more generic. > > Is it expected, are we OK with the fact, that with default settings > of weak dependencies enabled in dnf and anaconda, installing @group > can eventually pull in way more packages than originally listed > in the group, beyond the hard dependencies? Should following the weak > dependencies be a boolean yes/no setting, or should it be a score and > should the resolver have an option to favour weak dependencies when > resolving the first level of depenencies from the original package > list but decrease (perhaps radically) favouring them in next and > next-next-levels, potentially even taking into account if the > intermediate dependencies were explicit ones or implicit libraries? > > In other words, if I list packages A, B, C in transaction, I might > want to have their weak dependencies thrown onto the system as well. > But if A requires libX.so and libY.so, and package X requires G and > that has weak dependency on K, I might not care about K. > > If I explicitly say I want G, then again, sure, give me K as well. Boy, I don't know about you but I sure am looking forward to taking a degree in math to understand why packages are or are not installed! (you know, as opposed to the whole thing with the rubber chicken and the pulley that I do right now) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel
On Tue, 2020-04-07 at 14:01 +0200, Nicolas Mailhot via devel wrote: > Le mardi 07 avril 2020 à 06:31 -0400, Paul Dufresne via devel a écrit : > > Le 20-04-06 à 21 h 01, Paul Dufresne a écrit : > > > BTW, thanks I was searching for an example of package using a git > > version rather than a released archive! > > Just for the record, *I think* the current package is a bad example > > of a package using a forge like git. > > > > Current > > https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec > > does not seems to use the %forgemeta or %forgesetup macros as > > suggested in > > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > > (that I just read) > > While documented and official %forge macro use is not mandatory in > Fedora (of course, if you do things some other way, and the result > breaks, you ’ve no excuse for the breakage) Remember, xorg-x11-drv-intel is (obviously) quite an old package. New packaging stuff gets invented in Fedora *all the time*, and if you're a maintainer of existing packages you're not necessarily going to want to spend large chunks of time reading up on the latest FPC deliberations and updating all your spec files to implement the Cool New Shiny. Especially if the package works just fine as-is. None of my packages use this stuff either, because I hadn't heard of it until right now, it didn't exist when I started packaging stuff from Github and so on, and I tend to just cargo cult the basic frameworks of packages around from package to package for stuff I maintain (as I think many packagers do). I might use it now, because it looks helpful, but if this thread hadn't happened I might not have noticed it for another year or two. So: you can't really accuse any package that doesn't use something *optional* in the guidelines of being "bad" for that reason. You even have to accept that older packages may miss some stuff that is now *mandatory* in the guidelines if no-one took the trouble to go out and file mass bug reports and so on, because when the guidelines change there isn't always a process put in place to require or help packagers to adjust their packages to the change. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Updated review trackers pages
Il 07/04/20 16:01, Ankur Sinha ha scritto: > > The list says that there aren't any trivial tickets, but easyfix does > show one (only one): > https://fedoraproject.org/PackageReviewStatus/trivial.html > vs > https://fedoraproject.org/easyfix/ > > Could you check this please? > Yeah, that's because it's listed in the "in progress" page... that ticket has the review flag set and the assignee field is populated, but it's state is NEW. I will add a page to list all tickets in inconsistent state like that one. 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
env inside .desktop file
The Audacity package is currently getting desktop lint errors on x86_64 and armv7hl saying: "diag" : "Exec file /usr/bin/env not found, even in noarch", when it uses the exec line: "Exec=env UBUNTU_MENUPROXY=0 audacity %F" inside its .desktop file. To me, I don't see anything wrong with this syntax, and it works on user machines. Is there something else that needs to be included in the package to make the linter not throw an error on this line? Here is the full desktop linter log: https://taskotron.fedoraproject.org/artifacts/all/dba65002-7821-11ea-97e5-525400364adf/tests.yml/rpmgrill.json ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 3:10 AM Tom Hughes via devel wrote: > > On 06/04/2020 22:53, Stephen Gallagher wrote: > > > Changes in this version of the proposal[2]: > > > > * Improve our explanation of why we are doing ELN in the first place > > I agree that the proposal is now a lot clearer and I certainly see > how it furthers the first goral of seeing how Fedora trunk comes > together asn an EL build, modulo one concern below. > > I don't understand how it helps evaluate something like a new > higher CPU baseline - nobody disputes that packages can be built > to a new baseline which is what this would prove. The argument > is about the effect on consumers of such a baseline and about > what proportion of users/machines would be cut off from further > upgrades and this proposal does nothing to help with that. As to what proportion of users/machines would be cut off, we don't care about the exact number. It was already established that the number is an unacceptable amount. The real question is, how much of a performance advantage do modern machines get from running things built for such a baseline. If there is a significant advantage, then it becomes worthwhile to explore methods to make relevant packages built to such a baseline available in standard Fedora. There have been various ideas on how to make them available without making them a required minimum, but all of them involve a non-trivial amount of work. It would be a waste of time and energy if the real world advantage turns out to be minimal. ___ 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: Open NeuroFedora Meeting: 1600 UTC on Tuesday, 7th February
Hello there We would be starting the meeting in about 2 hours. Would love to see you all there. ;D On Mon, Apr 6, 2020 at 2:45 PM Aniket Pradhan wrote: > > Hello world > > You are invited to attend the next Open NeuroFedora team meeting this > week on Tuesday at 1600UTC in #fedora-neuro on IRC (Freenode): > > https://webchat.freenode.net/?channels=#fedora-neuro > > You can convert the meeting time to your local time using: > $ date --date='TZ="UTC" 1600 next Tue' > > or use this link: > https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Team+Meeting=20200407T16=%3A > > The meeting will be chaired by @major. The agenda for the meeting is: > > - Introductions and roll call. > - Tasks from last week's meeting: NA > - Pagure tickets: > https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting > - Neuroscience query of the week. > - Next meeting day, and chair. > - Open floor. > > In the "Neuroscience query of the week" section, attendees can ask > about/discuss a neuroscience topic that they are curious about. > > > We hope to see you there! :D > > -- > Thanks > Regards > > Aniket Pradhan > http://home.iiitd.edu.in/~aniket17133/ > Aliases: MeWjOr/major > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments -- Thanks Regards Aniket Pradhan http://home.iiitd.edu.in/~aniket17133/ Aliases: MeWjOr/major () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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: Updated review trackers pages
On Tue, Apr 07, 2020 07:21:14 +, Mattia Verga via devel wrote: > Hi all, Hi Mattia, Thanks very much for this! > > > BTW, since we have a 'trivial' ticket list for new reviewers, it would > be nice to have this populated: just add the 'trivial' tag in the ticket > whiteboard field on bugzilla. The list says that there aren't any trivial tickets, but easyfix does show one (only one): https://fedoraproject.org/PackageReviewStatus/trivial.html vs https://fedoraproject.org/easyfix/ Could you check this please? +1 to marking more package reviews as trivial. It'll really help the newcomers coming to us in the Join SIG to get started with packaging :) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[Bug 987118] perl-5.18: File handles modified with binmode ':unix' leak
https://bugzilla.redhat.com/show_bug.cgi?id=987118 --- Comment #34 from Fedora Update System --- FEDORA-2020-3472d53a15 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Fedora-IoT-32-20200407.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (x86_64) Old failures (same test failed in Fedora-IoT-32-20200406.0): ID: 569478 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/569478 Passed openQA tests: 7/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
Re: Rawhide update from side tag pending for 2 days
Richard W.M. Jones wrote: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > This one is a Rawhide update from a side tag, submitted on Sunday > morning which has been in pending for 2 days. (As it's Rawhide it's > supposed to spend 0 days in testing.) Is there any problem with it, > or do we just have to wait longer? It is blocking builds of other > packages. I saw the same thing, and submitted a infra ticket about it, https://pagure.io/fedora-infrastructure/issue/8819 -- Rex ___ 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: Rawhide update from side tag pending for 2 days
For each of these stuck builds could you open up tickets in https://pagure.io/releng/new_issue so we can track them down and fix them. Currently there are 1.5 sysadmins and 1.5 release engineer and we are not going to be able to track what and where we are doing things from mailing list posts. On Tue, 7 Apr 2020 at 08:41, Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote: > There is a problem right now with the part of koji that tags builds and > adds them to the various repos koji uses for new builds. So you can > build new packages, but can not rely on further builds seeing your > just-built packages. > > -- > 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 > -- Stephen J Smoogen. ___ 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: @core install picking up desktop packages
On 4/4/20 09:21, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote: I added the libsecret -> gnome-keyring recommends due to https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best to revert this change Yes, please. OK, I went ahead and did that: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bec4522056 Thanks everybody! -- Kalev ___ 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: Qt 5.14.2 coming to rawhide
Richard Shaw wrote: > On Mon, Apr 6, 2020 at 11:13 PM Rex Dieter wrote: > >> Rex Dieter wrote: >> >> > FYI, Started work on importing Qt 5.14.2 into rawhide today, with >> work-in- >> > progress being done in side tag f33-build-side-21031 >> > >> > I figure it'll take at least a few days to get the core bits and all >> > dependencies rebuilt. Will provide status updates as warranted. >> >> Fist batch of builds completed, bodhi update: >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c > > > Ahh, wish I had known, I would have built python-PySide2 into the side > tag. I suppose I still can but it wouldn't be in the update. You still can, the side tag still exists... or just wait until it gets pushed. If python-PySide2 uses Qt private api's so that it requires rebuilding for every Qt5 point release, make sure that it includes: BuildRequires: qt5-qtbase-private-devel that's the set of packages I always include in these sort of Qt mass updates. -- Rex ___ 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: Rawhide update from side tag pending for 2 days
There is a problem right now with the part of koji that tags builds and adds them to the various repos koji uses for new builds. So you can build new packages, but can not rely on further builds seeing your just-built packages. -- 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
Re: Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)
On 07. 04. 20 14:25, Petr Viktorin wrote: On 2020-04-07 12:40, Miro Hrončok wrote: On 07. 04. 20 11:06, Petr Viktorin wrote: On 2020-04-03 20:44, Miro Hrončok wrote: Hello Python packagers. I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to older releases. The python(abi) requirement is now added from a RPM Lua macro, instead of by executing a Shell script. This is a bit faster especially for packages with a lot of files. For 10 000 files in one package, the speedup is roughly from ~80 to ~2 seconds (time of the entire package build incl. creating the files from a Python script). That is a lot, but most of the real packages have much less files, so I am afraid you won't feel it. Hi, One thing I'm wondering about is: why is python(abi) provided by a generator, anyway? It's provided by a very small set of packages (python2 and python3 in Fedora). Couldn't it just be listed in those specfiles? Just to put this into more context: The time overhead is for the requires. The provides are filtered on a certain path and even if we are automating stuff for 2 packages which indeed might not be needed, it doesn't really hurt anything. See also https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/UFKUM5UKCTNGIT3KJVYEI5VXPI23QMBN/ for me trying to figure out when this provides are useful -- depending on the answer there, we might want to keep the automated provides of python(abi) only and remove the manual ones. The part I don't get is: why keep the automated provides over manual ones. Compared to a line in the relevant spec files, the macro looks like it adds complexity for no benefit. I get the automatic *requires* on python(abi) -- that's used by thousands of packages and easy to forget. But the provides will only ever be in CPython. I see your point and I don't disagree necessarily. I was just trying to provide more context. One reason to keep this is robustness. Once the python(abi) generator is enabled, it makes sure that both provides and requires are present. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)
On Tue, Apr 7, 2020 at 8:26 AM Petr Viktorin wrote: > > On 2020-04-07 12:40, Miro Hrončok wrote: > > On 07. 04. 20 11:06, Petr Viktorin wrote: > >> On 2020-04-03 20:44, Miro Hrončok wrote: > >>> Hello Python packagers. > >>> > >>> I have just updated python-rpm-generators to > >>> python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff > >>> from RPM 4.16 and will not be backported to older releases. > >>> > >>> > >>> The python(abi) requirement is now added from a RPM Lua macro, > >>> instead of by executing a Shell script. This is a bit faster > >>> especially for packages with a lot of files. For 10 000 files in one > >>> package, the speedup is roughly from ~80 to ~2 seconds (time of the > >>> entire package build incl. creating the files from a Python script). > >>> That is a lot, but most of the real packages have much less files, so > >>> I am afraid you won't feel it. > >> > >> Hi, > >> One thing I'm wondering about is: why is python(abi) provided by a > >> generator, anyway? > >> It's provided by a very small set of packages (python2 and python3 in > >> Fedora). Couldn't it just be listed in those specfiles? > > > > Just to put this into more context: The time overhead is for the > > requires. The provides are filtered on a certain path and even if we are > > automating stuff for 2 packages which indeed might not be needed, it > > doesn't really hurt anything. > > > > See also > > https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/UFKUM5UKCTNGIT3KJVYEI5VXPI23QMBN/ > > for me trying to figure out when this provides are useful -- depending > > on the answer there, we might want to keep the automated provides of > > python(abi) only and remove the manual ones. > > The part I don't get is: why keep the automated provides over manual > ones. Compared to a line in the relevant spec files, the macro looks > like it adds complexity for no benefit. > > I get the automatic *requires* on python(abi) -- that's used by > thousands of packages and easy to forget. But the provides will only > ever be in CPython. I'd use the same argument to get rid of the manual Provides, but the reason for why they exist in both manual and generated form is simple: to prevent human error. There have been cases in the past where the python RPM was being built in places where generators are disabled or not going to work properly (e.g. in this multi-python case), then the manual Provides would ensure things came out as intended. The automatic Provides generation is used to ensure that if things are using the generator, that everything is _ensured_ to be consistent. It's a very bad idea to have generated requires without generated provides, because you cannot guarantee the names will match up. -- 真実はいつも一つ！/ Always, there's only one truth! ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: Rawhide update from side tag pending for 2 days
On Tue, Apr 7, 2020 at 8:56 AM Richard W.M. Jones wrote: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > This one is a Rawhide update from a side tag, submitted on Sunday > morning which has been in pending for 2 days. (As it's Rawhide it's > supposed to spend 0 days in testing.) Is there any problem with it, > or do we just have to wait longer? It is blocking builds of other > packages. Yeah, this update looks stuck ... the koji builds aren't even tagged into the right tags yet, neither are they signed (from what I can see). I seem to have the same - or at least a similar - issue with three updates that are also stuck in pending for two days already (and the builds are not even signed yet, either): - https://bodhi.fedoraproject.org/updates/FEDORA-2020-460f0f4d48 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ea279079e - https://bodhi.fedoraproject.org/updates/FEDORA-2020-755f442b4c Those three were also made from side tags, but for stable releases, so I'm not sure whether it's the same issue or not. Fabio > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 7:33 AM Petr Pisar wrote:
>
> On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> > On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher
> > wrote:
> > > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa wrote:
> > >> I've personally been burned enough times by not having versioned
> > >> DistTags for personal rebuilds that I would strongly suggest you
> > >> reconsider having unversioned ones.
> > >
> > > Would you mind explaining some of the situations in which you were burned?
> > > I’m not ruling this out, but I’d like a clear justification if we were to
> > > change something.
> > >
> > So, prior to me building my packages in OBS and getting auto-bumping
> > Releases, I used to bump into issues all the time with building openSUSE
> > packages in an environment like Koji's, where the NVR is the key for
> > a unique package. openSUSE does *not* define a DistTag or the %dist
> > variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
> > packages with no source changes from one release of openSUSE to the next, or
> > rebuilding for new Tumbleweed snapshots, you're going to get collisions all
> > the time, and builds will just fail because the NVR already exists.
> >
> I think ELN won't have this problem (at large scale) because it will inherit
> sources from Fedora where any new Fedora build has a bumped release for the
> reason you described. It will resemble more a shadow Koji for the secondary
> architectures.
>
> But you are right that funny times can come when an ELN build screws things
> and
> ELN people will have to not only untag it but also delete it from the NVR
> index so
> that it can be rebuilt again with the same NVR. Fedora people weren't happy if
> they had to add a dummy release bumps just only because of ELN.
>
If the goal is to minimize impact on everyone else by ELN work, having
this versioned makes sense because it prevents very annoying
disruptions later on.
> > This is utter chaos and you *really* don't want that problem on your
> > hands. Having the freedom to do a rebuild cycle for ELN whenever you
> > want to rebootstrap to a new major without changing sources is a
> > hugely valuable thing to be able to do.
> >
> I think they will just throw it away and start from the scratch. At the end
> they would like to rebuild all the packages with the new configuration.
>
I'm pretty sure that nobody is going to let them delete everything
from Koji to redo it. Unless they were spinning this up in a shadow
Koji rather than the main one, which I don't think is the intent here.
--
真実はいつも一つ！/ 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
Re: Updated review trackers pages
On Tue, Apr 7, 2020 at 2:22 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Hi all, > > we have updated the script which provides the cached review trackers > pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to > cverna for the assistance). > Can we assume the one from 2006 is stale? :) Thanks, Richard ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 3:46 AM Vít Ondruch wrote: ... > > * Added a section explaining how we will deal with side-tags > > > Thank you for addressing this. > > However, could you please elaborate what will be the actual trigger to > do rebuild of some package in ELN? It can't be `git push` if you take > side-tags into account. So will it be tagging into 'rawhide' (f33 ATM)? > Will it be mixture? How are you going to determine what is the > appropriate commit hash? You possibly don't know yet ... I need to investigate how much of it will be net-new work, but we intend to rely on fedora-messaging notifications to trigger the rebuilds. Tagging into F33 is probably our best bet; we do actually have the ability to query Koji for which commit hash was used to run the build, so we can rely on that. The exact mechanism here is TBD, but I wanted to make sure the intent of the design was covered in the Change Proposal. ___ 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: Qt 5.14.2 coming to rawhide
On Mon, Apr 6, 2020 at 11:13 PM Rex Dieter wrote: > Rex Dieter wrote: > > > FYI, Started work on importing Qt 5.14.2 into rawhide today, with > work-in- > > progress being done in side tag f33-build-side-21031 > > > > I figure it'll take at least a few days to get the core bits and all > > dependencies rebuilt. Will provide status updates as warranted. > > Fist batch of builds completed, bodhi update: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c Ahh, wish I had known, I would have built python-PySide2 into the side tag. I suppose I still can but it wouldn't be in the update. Thanks, Richard ___ 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: Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)
On 2020-04-07 12:40, Miro Hrončok wrote: On 07. 04. 20 11:06, Petr Viktorin wrote: On 2020-04-03 20:44, Miro Hrončok wrote: Hello Python packagers. I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to older releases. The python(abi) requirement is now added from a RPM Lua macro, instead of by executing a Shell script. This is a bit faster especially for packages with a lot of files. For 10 000 files in one package, the speedup is roughly from ~80 to ~2 seconds (time of the entire package build incl. creating the files from a Python script). That is a lot, but most of the real packages have much less files, so I am afraid you won't feel it. Hi, One thing I'm wondering about is: why is python(abi) provided by a generator, anyway? It's provided by a very small set of packages (python2 and python3 in Fedora). Couldn't it just be listed in those specfiles? Just to put this into more context: The time overhead is for the requires. The provides are filtered on a certain path and even if we are automating stuff for 2 packages which indeed might not be needed, it doesn't really hurt anything. See also https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/UFKUM5UKCTNGIT3KJVYEI5VXPI23QMBN/ for me trying to figure out when this provides are useful -- depending on the answer there, we might want to keep the automated provides of python(abi) only and remove the manual ones. The part I don't get is: why keep the automated provides over manual ones. Compared to a line in the relevant spec files, the macro looks like it adds complexity for no benefit. I get the automatic *requires* on python(abi) -- that's used by thousands of packages and easy to forget. But the provides will only ever be in CPython. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 --- Comment #4 from Fedora Update System --- FEDORA-2020-7349370cc7 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7349370cc7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 --- Comment #3 from Fedora Update System --- FEDORA-2020-0426ac59f0 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0426ac59f0 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 --- Comment #2 from Fedora Update System --- FEDORA-2020-4a5245e2df has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a5245e2df -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel
Le mardi 07 avril 2020 à 06:31 -0400, Paul Dufresne via devel a écrit : > Le 20-04-06 à 21 h 01, Paul Dufresne a écrit : > > BTW, thanks I was searching for an example of package using a git > version rather than a released archive! > Just for the record, *I think* the current package is a bad example > of a package using a forge like git. > > Current > https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec > does not seems to use the %forgemeta or %forgesetup macros as > suggested in > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > (that I just read) While documented and official %forge macro use is not mandatory in Fedora (of course, if you do things some other way, and the result breaks, you ’ve no excuse for the breakage) 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
Re: Updating MUMPS/Sundials/PETSc
On 06/04/20 16:19, David Schwörer wrote: > On 4/5/20 6:06 PM, Antonio Trande wrote: >> On 04/04/20 19:23, David S wrote: >>> On 4/4/20 4:38 PM, Antonio Trande wrote: Hi all. `MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming on Rawhide; these updates will need rebuilds of dependent packages: >>> [:snip:] >>> >>> >>> Thanks a lot for updating PETSc, I know PETSc is quite challenging to >>> package. >>> >>> I tried to build BOUT++ against PETSc, using pkg-config. >>> the pkg-config files are installed to petsc/ subdirectory, but it seems >>> the pc files are not adjusted for this. >>> >>> Further, I have been using petsc --with superludist without issues, can >>> you tell why this was disabled, so I can test whether this was fixed in >>> the mean time? >> >> `superludist` support is reactivated; please, test petsc-3.13.0 again: >> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1328023/ >> > > In the PETSc.pc files, the $MPI_INCLUDE are not expanded, which also > doesn't happen at evaluation time: > pkg-config PETSc --cflags > -I$MPI_INCLUDE/petsc > > which isn't further evaluated. I guess replacing the ' with " in the > spec should ensure it gets evaluated. > > PETSc is injecting -L/usr/lib which will cause linking issues if there > is e.g. a libhdf5.so in /usr/lib because the MPI lib is needed. > > Besides these two issues, everything seems to be fine. Last build on Copr should fix these issues. Please, test it again: https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1329534/ > > Thanks, > David > -- --- 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
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Net-DAVTalk-0.18-1.fc3 ||3 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: F32: System hangs when using mock
On Tue, Apr 07, 2020 09:53:18 +0100, Ankur Sinha wrote: > > On Mon, Apr 06, 2020 09:37:01 +0200, Pavel Raiskup wrote: > > On Sunday, April 5, 2020 12:44:38 PM CEST Ankur Sinha wrote: > > > On Sat, Apr 04, 2020 21:37:05 -, Artem Tim wrote: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1754807 > > > > > > That does look like it. I'll go through the comments and see if I can > > > help with more info. > > > > Note also this bug [1] where's kernel traceback in bfq kernel code. > > I have never reproduced the problem on my box (ssd nvme disk), so I can't > > tell.. but those are possible workarounds for those who use bfq scheduler: > > > > - per Zbyszek, switching back to deadline > > - per Vitaly, systemd.unified_cgroup_hierarchy=0 kernel parameter > > Thanks Pavel, > > Would someone have instructions on how to make these changes? I can test > both of these out. For the scheduler, the steps here work: https://wiki.archlinux.org/index.php/improving_performance#Input/output_schedulers Testing it out now. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[Bug 1821573] perl-Net-DAVTalk-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1821573 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher wrote:
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa wrote:
> >> I've personally been burned enough times by not having versioned
> >> DistTags for personal rebuilds that I would strongly suggest you
> >> reconsider having unversioned ones.
> >
> > Would you mind explaining some of the situations in which you were burned?
> > I’m not ruling this out, but I’d like a clear justification if we were to
> > change something.
> >
> So, prior to me building my packages in OBS and getting auto-bumping
> Releases, I used to bump into issues all the time with building openSUSE
> packages in an environment like Koji's, where the NVR is the key for
> a unique package. openSUSE does *not* define a DistTag or the %dist
> variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
> packages with no source changes from one release of openSUSE to the next, or
> rebuilding for new Tumbleweed snapshots, you're going to get collisions all
> the time, and builds will just fail because the NVR already exists.
>
I think ELN won't have this problem (at large scale) because it will inherit
sources from Fedora where any new Fedora build has a bumped release for the
reason you described. It will resemble more a shadow Koji for the secondary
architectures.
But you are right that funny times can come when an ELN build screws things and
ELN people will have to not only untag it but also delete it from the NVR index
so
that it can be rebuilt again with the same NVR. Fedora people weren't happy if
they had to add a dummy release bumps just only because of ELN.
> This is utter chaos and you *really* don't want that problem on your
> hands. Having the freedom to do a rebuild cycle for ELN whenever you
> want to rebootstrap to a new major without changing sources is a
> hugely valuable thing to be able to do.
>
I think they will just throw it away and start from the scratch. At the end
they would like to rebuild all the packages with the new configuration.
-- 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
What I'm confused about is the hangup with versioning the ELN tree.
Why is this a problem?
I explained it in one of the previous threads:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?
From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.
If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.
What you say here is very inconsistent with %{eln} and %{rhel} value. In
particular "the versioning here should be independent from RHEL" and "we don't
try to link to particular RHEL release" is very weird considering that %{eln}
and %{rhel} will evaluate to "next RHEL version".
--
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: CPE Weekly: 2020-04-04
Dominik 'Rathann' Mierzejewski wrote: > The majority here is telling you to hold off execution of that > "decision" and revisit it, but you're ignoring those voices entirely and > offering useless "apologies" instead. You cannot pretend to be part of a > community if you just ignore its other members and do your own thing. […] > You cannot wish for meaningful engagement in the future if you don't fix > your past mistakes and reverse bad decisions. +1 Kevin Kofler ___ 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: Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)
On 07. 04. 20 11:06, Petr Viktorin wrote: On 2020-04-03 20:44, Miro Hrončok wrote: Hello Python packagers. I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to older releases. The python(abi) requirement is now added from a RPM Lua macro, instead of by executing a Shell script. This is a bit faster especially for packages with a lot of files. For 10 000 files in one package, the speedup is roughly from ~80 to ~2 seconds (time of the entire package build incl. creating the files from a Python script). That is a lot, but most of the real packages have much less files, so I am afraid you won't feel it. Hi, One thing I'm wondering about is: why is python(abi) provided by a generator, anyway? It's provided by a very small set of packages (python2 and python3 in Fedora). Couldn't it just be listed in those specfiles? Just to put this into more context: The time overhead is for the requires. The provides are filtered on a certain path and even if we are automating stuff for 2 packages which indeed might not be needed, it doesn't really hurt anything. See also https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/UFKUM5UKCTNGIT3KJVYEI5VXPI23QMBN/ for me trying to figure out when this provides are useful -- depending on the answer there, we might want to keep the automated provides of python(abi) only and remove the manual ones. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Fedora-Cloud-31-20200407.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
bad exemple of package using a forge Was: Re: Urgently downgrade xorg-x11-drv-intel
|Le 20-04-06 à 21 h 01, Paul Dufresne a écrit :> BTW, thanks I was searching for an example of package using a git||version rather than a released archive!|| | |Just for the record, *I think* the current package is a bad example of a package using a forge like git.||| || |Current https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/f32/f/xorg-x11-drv-intel.spec does not seems to use the %forgemeta or %forgesetup macros as suggested in https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ (that I just read) | || ___ 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: Modularity Survey
Adam Williamson wrote: > Well. Uh. Clearly it's being provided to *Google*. Indeed. Once again, Fedora is depending on third-party, proprietary, privacy-invading SaaS. Kevin Kofler ___ 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: Rawhide python-rpm-generators news: small speedup + %python_provide not needed in most cases
On 03. 04. 20 20:44, Miro Hrončok wrote:
Hello Python packagers.
I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in
Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to
older releases.
The python(abi) requirement is now added from a RPM Lua macro, instead of by
executing a Shell script. This is a bit faster especially for packages with a
lot of files. For 10 000 files in one package, the speedup is roughly from ~80
to ~2 seconds (time of the entire package build incl. creating the files from a
Python script). That is a lot, but most of the real packages have much less
files, so I am afraid you won't feel it.
More importantly, %python_provide is not needed for package names.
Until now, we needed to this:
%package -n python3-foo
...
%{?python_provide:%python_provide python3-foo}
This adds automatic provides "python-foo" (and since recently, also
"python38-foo" for forwards/backwards compatibility with EL). This now happens
automagically. Any package called "python3-..." will have those provides added
implicitly by the Python generators when they are in the buildroot
(python3-devel brings those in, so for Python packages this means always).
This automation was possible due to the speedup mentioned above, doing it the
pre-RPM.16 way would be very slow, because the generator is called for every
packaged file (which is still the case now, but it can now be a Lua macro). The
~2 seconds from above include this new feature.
There are 2 cases where manual %python_provide calls are still needed:
1. Metapackages without files
No files => no dependency generator. (I recommend to %ghost the
dist-info/egg-info directory in such packages to workaround this -- we plan to
add more good stuff regarding Python [extras] that will require this anyway.)
2. Virtual provides
The dependency generator can see the (sub)package's name, but not any other
virtual provides. When you do:
%package -n python3-%{pypi_name}
Provides: python3-%{legacy_name} = %{version}-%{release}
You are still supposed to add:
%{?python_provide:%python_provide python3-%{legacy_name}}
(Also note that %python_provide adds obsoletes for older python-foo versions,
that was useful when we renamed everything from python-foo to python2-foo and
when we changed the "default" from python2- to python3-. We are keeping the
Obsoletes in the macro (for now), but I have decided to not automatically
generate the Obsoletes based on the package name. A) I don't consider them
really needed in Fedora 33 any more and B) an idea of implicit obsoletes doesn'T
sound very intriguing to me. This is a decision that may be revisited later if
it's bringing unforeseen trouble.)
You don't need to to actively remove the macro from your spec files, it does no
harm. If you prefer to maintain a single spec, keep it there until Fedora 32
goes EOL (and EPEL 8 if that's your target). The guidelines always recommended
using it the safe way (%{?python_provide:...}), so even if it ceases to exist in
the future, it can remain in specs. There is no plan to remove it in any near or
distant future, as it is still needed for the virtual provides. The generators
also use it internally (for DRY and consistent results).
If you'll get into trouble because of this, let us know and we'll fix it.
First problem:
When you sue %python_provide and when you build the package with the new
generator, the provides are listed twice:
$ rpm -qp --provides python3-double-provides-0-0.fc33.noarch.rpm
python-double-provides = 0-0.fc33
python-double-provides = 0-0.fc33
python3-double-provides = 0-0.fc33
python38-double-provides = 0-0.fc33
python38-double-provides = 0-0.fc33
$ rpmlint python3-double-provides-0-0.fc33.noarch.rpm
...
python3-double-provides.noarch: E: useless-provides python-double-provides
python3-double-provides.noarch: E: useless-provides python38-double-provides
...
I've reported that as a bug in RPM:
https://github.com/rpm-software-management/rpm/issues/1166
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
