Re: Packages BuildRequiring python2-sphinx AND python3-devel
On Mon, Apr 29, 2019 at 10:58:45PM +0200, Miro Hrončok wrote: > python-case mrunge Thank you for pointing this out, it is fixed in rawhide. Matthias -- Matthias Runge ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
Dne 28. 04. 19 v 22:55 Zbigniew Jędrzejewski-Szmek napsal(a): > Hi everyone, > > currently, we autogenerate a dependency on pkg-config for all rpms > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > returns 4632 entries on my laptop. > > This has always felt backward to me: those packages *provide* something > that is used by pkg-config, they don't *require* pkg-config for anything. > As an analogy, packages with headers are read by a C compiler, but > we don't make them require gcc, and if a package ships an .so file, we > don't add a dependency on the linker to it. Instead, anything which wants > to consume .pc files should simply depend on the tools that consume those > files (pkg-config, pkgconf, or a custom re-implementation). I don't think that this is completely wrong. However that dependency should not be "Requires" but probably "Suggests". Not that we can really benefit from "Suggests". Vít > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > part of this proposal. > > Advantages: > - less entries in the dependency graph > - removal of illogical dependency > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > (Those packages are small, maybe 200k together so this isn't a strong >reason.) > > Disadvantages: > - stuff that uses pkg-config or pkgconf will need to grow a dependency > (e.g. meson which invokes /usr/bin/pkg-config internally). > so there will be some churn. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-04-30 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
white_dune reached version 1.0 (need sponsoring)
Hi, white_dune (3D modeler and animation-tool) reached version 1 cause it could render any visible node of VRML87/X3D 3.3. It needs fedora sponsoring. https://bugzilla.redhat.com/show_bug.cgi?id=1658153 Petr Mensik wrote | find anyone to sponsor your account on devel list. I think this package is | quite good and would be nice to have, especially to Games developers. I would | sponsor you myself, but not yet able to sponsor. vcglib https://bugzilla.redhat.com/show_bug.cgi?id=1677989 (nedded by white_dune) also needs fedora sponsoring. so long MUFTI ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages BuildRequiring python2-sphinx AND python3-devel
python-requests-cache has already been fixed in rawhide... 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Monday, April 29 2019, Miro Hrončok wrote: > On 29. 04. 19 8:26, Igor Gnatenko wrote: >> This is what wiki says: >> >> * |/usr/bin/gdb.minimal| — GDB executable built without optional unneeded >> features >> * |/usr/bin/gdb-add-index| — Executable script shared with gdb-headless >> package (modified to fallback to gdb.minimal if exists) >> >> gdb-add-index is in both gdb-minimal and gdb-headless. > > Except: > > - that's not currently true > - proper conflicts for lower versions need to be added then (not there now) I've uploaded gdb-8.3.50.20190425-10.fc31 which should address these issues. > Can we please figure the plan and **approve the change** before doing it? > > https://src.fedoraproject.org/rpms/gdb/c/cc7695234a0fb5d5e1357d9e30354aecc3fdc4e5?branch=master Doing this doesn't impact the buildroot at all; things will only be effective when rpm-build is changed to depend/suggest on gdb-minimal. I decided to go ahead and perform the split because I wanted to make sure everything was in place before implementing the change. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages BuildRequiring python2-sphinx AND python3-devel
On 29. 04. 19 23:06, Miro Hrončok wrote: On 29. 04. 19 23:05, Peter Robinson wrote: There are 2 Python related changes in Fedora 31 that unfortunately interact with each other. https://fedoraproject.org/wiki/Changes/Python3.8 https://fedoraproject.org/wiki/Changes/Sphinx2 The following packages (owners bcc'ed) BuildRequire both python2-sphinx AND python3-devel. Hence the package won't be able to be rebuilt for the Python 3.8 update. I'd appreciate if you could drop the dependency on python2-sphinx to make the Python 3.8 transition possible. For packages that are needed by other packages, I might eventually do it myself. (Note that this information is from repoquery, if you already fixed this in git only, sorry for the noise.) I have an issue with xapian-bindings which appears to be broken when building python3 with sphinx2, are they an incompatible update? With Fedora 30 release activities I've not had time to investigate and I wasn't aware of the major bump of sphnix2 would impact me. It's going to be a few weeks or more due to other commitments before I might get a chance to look at this again. Yes, they've removed a lot of deprecated things. I'll put xapian-bindings to my TODO. Here's a very dirty PR that makes it work: https://src.fedoraproject.org/rpms/xapian-bindings/pull-request/3 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages BuildRequiring python2-sphinx AND python3-devel
On 29. 04. 19 23:05, Peter Robinson wrote: There are 2 Python related changes in Fedora 31 that unfortunately interact with each other. https://fedoraproject.org/wiki/Changes/Python3.8 https://fedoraproject.org/wiki/Changes/Sphinx2 The following packages (owners bcc'ed) BuildRequire both python2-sphinx AND python3-devel. Hence the package won't be able to be rebuilt for the Python 3.8 update. I'd appreciate if you could drop the dependency on python2-sphinx to make the Python 3.8 transition possible. For packages that are needed by other packages, I might eventually do it myself. (Note that this information is from repoquery, if you already fixed this in git only, sorry for the noise.) I have an issue with xapian-bindings which appears to be broken when building python3 with sphinx2, are they an incompatible update? With Fedora 30 release activities I've not had time to investigate and I wasn't aware of the major bump of sphnix2 would impact me. It's going to be a few weeks or more due to other commitments before I might get a chance to look at this again. Yes, they've removed a lot of deprecated things. I'll put xapian-bindings to my TODO. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packages BuildRequiring python2-sphinx AND python3-devel
> There are 2 Python related changes in Fedora 31 that unfortunately interact > with > each other. > > https://fedoraproject.org/wiki/Changes/Python3.8 > https://fedoraproject.org/wiki/Changes/Sphinx2 > > The following packages (owners bcc'ed) BuildRequire both python2-sphinx AND > python3-devel. Hence the package won't be able to be rebuilt for the Python > 3.8 > update. I'd appreciate if you could drop the dependency on python2-sphinx to > make the Python 3.8 transition possible. > > For packages that are needed by other packages, I might eventually do it > myself. > > (Note that this information is from repoquery, if you already fixed this in > git > only, sorry for the noise.) I have an issue with xapian-bindings which appears to be broken when building python3 with sphinx2, are they an incompatible update? With Fedora 30 release activities I've not had time to investigate and I wasn't aware of the major bump of sphnix2 would impact me. It's going to be a few weeks or more due to other commitments before I might get a chance to look at this again. > Thank You! > > Maintainers by package: > mellowplayer martinkg > python-Bottleneckbesser82 > python-case mrunge > python-dulwich fab > python-feedparserhguemar lmacken louizatakk mcepl > python-gunicorn dcallagh > python-hardware flepied > python-htmlmin jujens > python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger > python-jsonpath-rw-ext apevec hguemar pkilambi > python-kazoo apevec nsaje > python-ngram besser82 > python-oauth2client mbaldessari ralph > python-plaster bowlofeggs > python-pycares fantom > python-pypumpralph > python-requests-cache codeblock hobbes1069 > python-rosdepcottsay rmattes thofmann > python-rosinstallrmattes > python-slixmpp fantom louizatakk > python-vcstools cottsay rmattes > python-wrapt chandankumar ralph > python-wsgi_intercept apevec chandankumar > python-wstoolankursinha cottsay rmattes > python-yaql mflobo > waf salimma thm > xapian-bindings denisarnaud drago01 pbrobinson sdz > > Packages by maintainer: > ankursinha python-wstool > apevec python-jsonpath-rw-ext python-kazoo python-wsgi_intercept > besser82 python-Bottleneck python-ngram > bowlofeggs python-plaster > chandankumar python-wrapt python-wsgi_intercept > codeblock python-requests-cache > cottsaypython-rosdep python-vcstools python-wstool > dcallagh python-gunicorn > denisarnaud xapian-bindings > drago01xapian-bindings > fabpython-dulwich > fantom python-pycares python-slixmpp > flepiedpython-hardware > hguemarpython-feedparser python-jsonpath-rw-ext > hobbes1069 python-requests-cache > ignatenkobrain python-jenkins-job-builder > jujens python-htmlmin > ktdreyer python-jenkins-job-builder > lmackenpython-feedparser > louizatakk python-feedparser python-slixmpp > martinkg mellowplayer > mbaldessari python-oauth2client > mcepl python-feedparser > mflobo python-yaql > mrunge python-case > nsaje python-kazoo > pabelanger python-jenkins-job-builder > pbrobinson xapian-bindings > pkilambi python-jsonpath-rw-ext > ralph python-oauth2client python-pypump python-wrapt > rmattespython-rosdep python-rosinstall python-vcstools python-wstool > salimmawaf > sdzxapian-bindings > thmwaf > thofmann python-rosdep > -- > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Packages BuildRequiring python2-sphinx AND python3-devel
Hey! There are 2 Python related changes in Fedora 31 that unfortunately interact with each other. https://fedoraproject.org/wiki/Changes/Python3.8 https://fedoraproject.org/wiki/Changes/Sphinx2 The following packages (owners bcc'ed) BuildRequire both python2-sphinx AND python3-devel. Hence the package won't be able to be rebuilt for the Python 3.8 update. I'd appreciate if you could drop the dependency on python2-sphinx to make the Python 3.8 transition possible. For packages that are needed by other packages, I might eventually do it myself. (Note that this information is from repoquery, if you already fixed this in git only, sorry for the noise.) Thank You! Maintainers by package: mellowplayer martinkg python-Bottleneckbesser82 python-case mrunge python-dulwich fab python-feedparserhguemar lmacken louizatakk mcepl python-gunicorn dcallagh python-hardware flepied python-htmlmin jujens python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger python-jsonpath-rw-ext apevec hguemar pkilambi python-kazoo apevec nsaje python-ngram besser82 python-oauth2client mbaldessari ralph python-plaster bowlofeggs python-pycares fantom python-pypumpralph python-requests-cache codeblock hobbes1069 python-rosdepcottsay rmattes thofmann python-rosinstallrmattes python-slixmpp fantom louizatakk python-vcstools cottsay rmattes python-wrapt chandankumar ralph python-wsgi_intercept apevec chandankumar python-wstoolankursinha cottsay rmattes python-yaql mflobo waf salimma thm xapian-bindings denisarnaud drago01 pbrobinson sdz Packages by maintainer: ankursinha python-wstool apevec python-jsonpath-rw-ext python-kazoo python-wsgi_intercept besser82 python-Bottleneck python-ngram bowlofeggs python-plaster chandankumar python-wrapt python-wsgi_intercept codeblock python-requests-cache cottsaypython-rosdep python-vcstools python-wstool dcallagh python-gunicorn denisarnaud xapian-bindings drago01xapian-bindings fabpython-dulwich fantom python-pycares python-slixmpp flepiedpython-hardware hguemarpython-feedparser python-jsonpath-rw-ext hobbes1069 python-requests-cache ignatenkobrain python-jenkins-job-builder jujens python-htmlmin ktdreyer python-jenkins-job-builder lmackenpython-feedparser louizatakk python-feedparser python-slixmpp martinkg mellowplayer mbaldessari python-oauth2client mcepl python-feedparser mflobo python-yaql mrunge python-case nsaje python-kazoo pabelanger python-jenkins-job-builder pbrobinson xapian-bindings pkilambi python-jsonpath-rw-ext ralph python-oauth2client python-pypump python-wrapt rmattespython-rosdep python-rosinstall python-vcstools python-wstool salimmawaf sdzxapian-bindings thmwaf thofmann python-rosdep -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Atomic Host Two Week Release Announcement: 29.20190429.0
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20190429.0 Commit(x86_64): 50310e46520cd08a28634d575fd78db9629c15263b4491d1b6cd20e141c25c17 Commit(aarch64): ca5a00b8558b6cec0a791a3788799c475c36b817e569e53a4bf975c124c5608c Commit(ppc64le): 83e2f74648b7bc41b232f3ec6c0ffbdac6e06042fc2fea806c4074d2be341bf7 We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time. Existing systems can be upgraded in place via e.g. `atomic host upgrade`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Alternatively, image artifacts can be found at the following links: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190429.0.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190429.0.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190429.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190429.0.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190429.0.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190429.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190429.0.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190429.0.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190429.0.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190429.0.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190429.0.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190429.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190429.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190429.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190429.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190429.0-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190429.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190429.0-x86_64-CHECKSUM For direct download, the "latest" targets are always available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest https://getfedora.org/atomic_raw_x86_64_latest https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest https://getfedora.org/atomic_dvd_ostree_x86_64_latest aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest https://getfedora.org/atomic_raw_aarch64_latest https://getfedora.org/atomic_dvd_ostree_aarch64_latest ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest https://getfedora.org/atomic_raw_ppc64le_latest https://getfedora.org/atomic_dvd_ostree_ppc64le_latest Filename fetching URLs are available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest_filename https://getfedora.org/atomic_raw_x86_64_latest_filename https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest_filename https://getfedora.org/atomic_raw_aarch64_latest_filename https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest_filename https://getfedora.org/atomic_raw_ppc64le_latest_filename https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam
Re: dropping autogenerated dependency on pkg-config
On Mon, Apr 29, 2019 at 3:20 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote: > > Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > > > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > > > > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > > > part of this proposal. > > > > > > Advantages: > > > - less entries in the dependency graph > > > - removal of illogical dependency > > > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > > > libpkgconf) > > > (Those packages are small, maybe 200k together so this isn't a strong > > >reason.) > > > > > > Disadvantages: > > > - stuff that uses pkg-config or pkgconf will need to grow a dependency > > > (e.g. meson which invokes /usr/bin/pkg-config internally). > > > so there will be some churn. > > > > The work required to fix packages affected by this disadvantage > > (potentially) far outweighs any advantage > > > > Now, if the proposal includes offering to help do a some/most of the work to > > fix all these, then I withdraw the objection. > > Obviously. I would do most of the work myself. > I'm not convinced that this is worth it. There's nothing appreciably saved by doing this, and it creates an annoying inconvenience for people who are trying to package software in Fedora. You're spending a ton of effort for 200KB that will have outsized negative impact on the ecosystem by making it non-intuitively harder to package and use software. Beyond "removal of illogical dependency", which frankly only applies to how systemd is packaged, why do you want to do this? This doesn't save us an unwanted dep like the GCC removal does. This doesn't remove a massive buildroot dependency like the GDB one does. If you want the pkgconf-m4 package to not be auto-installed with pkgconf-pkg-config, I'm happy to make that change. But past that? What does anyone get from this? Basically nothing. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fuse/fuse3 - repos and moving forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 2019-04-29 at 20:17 +0100, Phil Wyett wrote: > Hi all, > > We have a fuse repo on pagure at 2.99 and a PR regarding fuse3 from 'dwd'. We > also have a fuse3 repo that has been created on pagure. What is the situation > at > present and how we will be moving forward with fuse 3? > > Regards > > Phil > Should have mentioned. This came to my attention as the latest gvfs has a dep on fuse3. Regards Phil - -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Twitter: kathenasorg IRC: kathenas Web: https://kathenas.org Github: https://github.com/kathenas GitLab: https://gitlab.com/kathenas GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJcx06nAAoJEDM/YNywubt3X5AQAMWHrQuQ8kHlZzBKWrgx4bM4 eKclW4cITFF7PvLLlQSxzY3NYZtTKbtyeJ3sz/7unrnqmis9QIMCh+Mnf0tSeSbX oAYXkCDtuACH8EWS5nk395tdtg+Of1eFbuKlNJzZ0DQikxQXpag3hqQBP8JO9vxO rFHveNyTSHtfiuYJ37DEIX67TkJsjKp86Guzy5ezChVgvgrjYy9tfewx1fLc/CmK RCrA8JTa7SjdkJ3nU0VcDXKOLV5txd6BJhxCFEBJv2hfq/Et5QfV4AEzy0UKdCBH kk0Gxev/J9kQIYJGtclbOwd8zEuBfXZr2D/+uk9UYgYh9MGh2mPUYXiyS9r8A5cf 5nnIMBea0CSeciWt6bbLBRKC6c5avV/eNOTC5akp7RPGj2DhXOuE4cnhVFQ9CJIO 1P1TUfCJ6IjSW0v3h9xYADuRhMqecTCunBhFER2x3i4fU7c01MqZ1ed/m/feSdCB ANqptQXn/i4Hew3j2NqNnipnVP3hqrW6vFfiQGQwXiwV/JBctTJubhd2T9areJfG O8FPROtPy+F6csomQZCKcPuJdppf3BnBdvf3CcQKH0wmCuPWuT0RSFGQg6pJJ3PF EDXknRFC8WIZLUBq4q4Zz8lNrDx1ZyDkzwoe/QIbC95Akk+9o3wuY+bgr6J5hsgI 2lqIq/nsgiDPWTfEMicU =RMgC -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > > part of this proposal. > > > > Advantages: > > - less entries in the dependency graph > > - removal of illogical dependency > > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > > libpkgconf) > > (Those packages are small, maybe 200k together so this isn't a strong > >reason.) > > > > Disadvantages: > > - stuff that uses pkg-config or pkgconf will need to grow a dependency > > (e.g. meson which invokes /usr/bin/pkg-config internally). > > so there will be some churn. > > The work required to fix packages affected by this disadvantage > (potentially) far outweighs any advantage > > Now, if the proposal includes offering to help do a some/most of the work to > fix all these, then I withdraw the objection. Obviously. I would do most of the work myself. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fuse/fuse3 - repos and moving forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We have a fuse repo on pagure at 2.99 and a PR regarding fuse3 from 'dwd'. We also have a fuse3 repo that has been created on pagure. What is the situation at present and how we will be moving forward with fuse 3? Regards Phil - -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Twitter: kathenasorg IRC: kathenas Web: https://kathenas.org Github: https://github.com/kathenas GitLab: https://gitlab.com/kathenas GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJcx03nAAoJEDM/YNywubt3MegQAKAzd6f/3b38acNEXYU/edZe W6BRRTPEsrv0i0i/3XOsJxuMUlSEBfIYB97WOhWvWDCEMxq3uFwrKZ4Eoqk7I89j kVLoD3SWQ/xJgKqeiOpuJr3vj9hepDJm+WtfU390eJxmHxwFoi7nDIGI/BoCI/ZG nyNnprSWuiV0PKYuX/wMMR9fIwjg7VisMrVspPR5ddKNBrO5KTmlZO0pBEVt49PU XgKGCmE/GyWzaWTkBjcJvxm5tK04Kpkk6HY1DNygvQjk6/nlOk5b00/V8UQqV7d9 7EV+brFBPGDWiEbjYtgwZS6hXj2BKA+hzy3pA/XT0z/MHkkKAt/y2gKmcSut7zbX MHm7pQ/YXTQHqDCW0NUPYcrlUpcHIeVI4OjEWeIL70MRFulf92/kltF5SGcFaIgo 5noYMnKbQT8IjAOaixlvX73jwmhYXg6EEe5vvmcYWRdpK1ALAsujUC3+zcgX3pPF UVmn99/jQagxwKU9JUeM08MdgAvG/2AVKykxftiApRVI3JKvf+NRpFKH9L9mh/LQ 99Ed+Bj3iGvsILJ3cu+RIHiFokeKyfGiaikL9t/h8p/MHZK0RYLI6liTYYdFYnAv BzeH/NrSUdMZf9fOS2BEDKq9TSBQegnzCPjqmqlFdZyXmpZrSxKUWZBgr/tGLi7J +JquPRvQLqreg3wG9fhd =btir -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (lot of nodejs deps will be retired next week)
Miro Hrončok wrote: > The following packages are orphaned and will be retired when they ... > Request package ownership via releng ticket: > https://pagure.io/releng/issues > lightdm-gtk cwickert, dbenoit, orphan, 3 weeks https://pagure.io/releng/issue/8315 -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
Zbigniew Jędrzejewski-Szmek wrote: > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > part of this proposal. > > Advantages: > - less entries in the dependency graph > - removal of illogical dependency > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > (Those packages are small, maybe 200k together so this isn't a strong >reason.) > > Disadvantages: > - stuff that uses pkg-config or pkgconf will need to grow a dependency > (e.g. meson which invokes /usr/bin/pkg-config internally). > so there will be some churn. The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage Now, if the proposal includes offering to help do a some/most of the work to fix all these, then I withdraw the objection. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages need new maintainers (lot of nodejs deps will be retired next week)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-04-29.txt Request package ownership via releng ticket: https://pagure.io/releng/issues Packages retired today: rubygem-fog rubygem-fog-atmos rubygem-fog-brightbox rubygem-fog-ecloud rubygem-fog-profitbricks rubygem-fog-radosgw rubygem-fog-riakcs rubygem-fog-sakuracloud rubygem-fog-serverlove rubygem-fog-softlayer rubygem-fog-storm_on_demand rubygem-fog-terremark rubygem-fog-vmfusion rubygem-fog-voxel rubygem-multipart Package (co)maintainers Status Change PyMca orphan 4 weeks ago Ray orphan 4 weeks ago aeskulap orphan 2 weeks ago ahkab orphan 3 weeks ago cwiid orphan 4 weeks ago dvdbackup cicku, orphan2 weeks ago emacs-pymacs orphan 2 weeks ago gnome-dvb-daemon orphan 2 weeks ago gnome-shell-extension-orphan 2 weeks ago openweather gnome-shell-extension-panel-osd orphan 2 weeks ago gnue-common orphan 4 weeks ago jam-control orphan 4 weeks ago lightdm-gtk cwickert, dbenoit, orphan, 3 weeks ago rdieter ltspfsenslaver, orphan 1 weeks ago ninja-ide echevemaster, orphan 1 weeks ago nodejs-after nodejs-sig, orphan 6 weeks ago nodejs-alter nodejs-sig, orphan 6 weeks ago nodejs-ansi-font nodejs-sig, orphan 6 weeks ago nodejs-ansidiff nodejs-sig, orphan 6 weeks ago nodejs-archiver nodejs-sig, orphan 6 weeks ago nodejs-archiver-utils nodejs-sig, orphan 6 weeks ago nodejs-ast-traverse nodejs-sig, orphan 6 weeks ago nodejs-ast-types nodejs-sig, orphan 6 weeks ago nodejs-astral nodejs-sig, orphan 6 weeks ago nodejs-astral-angular-annotatenodejs-sig, orphan 6 weeks ago nodejs-astral-passnodejs-sig, orphan 6 weeks ago nodejs-async-cachenodejs-sig, orphan 6 weeks ago nodejs-async-each nodejs-sig, orphan 6 weeks ago nodejs-aws-sign2 nodejs-sig, orphan 6 weeks ago nodejs-base64-js nodejs-sig, orphan 6 weeks ago nodejs-basic-auth-parser nodejs-sig, orphan 6 weeks ago nodejs-bl nodejs-sig, orphan 6 weeks ago nodejs-breakable nodejs-sig, orphan 6 weeks ago nodejs-camel-case nodejs-sig, orphan 6 weeks ago nodejs-caniuse-db nodejs-sig, orphan 6 weeks ago nodejs-change-casenodejs-sig, orphan 6 weeks ago nodejs-clone nodejs-sig, orphan 6 weeks ago nodejs-clsnodejs-sig, orphan 6 weeks ago nodejs-co nodejs-sig, orphan 6 weeks ago nodejs-commoner nodejs-sig, orphan 6 weeks ago nodejs-compress-commons nodejs-sig, orphan 6 weeks ago nodejs-console-browserify nodejs-sig, orphan 6 weeks ago nodejs-constant-case nodejs-sig, orphan 6 weeks ago nodejs-crc32-stream nodejs-sig, orphan 6 weeks ago nodejs-dashdash nodejs-sig, orphan 6 weeks ago nodejs-date-now nodejs-sig, orphan 6 weeks ago nodejs-deferred
Re: rpmlint whitelisting broken in taskotron?
On Fri, 26 Apr 2019 20:33:43 +0200 Fabio Valentini wrote: > On Fri, Apr 26, 2019, 20:24 Tim Flink wrote: > > > On Fri, 26 Apr 2019 16:42:30 +0200 > > Fabio Valentini wrote: > > > > > Hi, > > > > > > I've noticed that my bodhi updates started showing rpmlint errors > > > for my packages again, where they were previously silent because > > > I supply a $SRCNAME.rpmlintrc file in my dist-git repos. > > > > > > It looks like taskotron is broken and/or ignores this file again. > > > Is this a known issue? > > > > > > For example, this build from today shows rpmlint issues that are > > > explicitly whitelisted (using the file locally suppresses the > > > warnings/errors as intended): > > > > > > update: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecaba1eef1 in > > > repo: > > https://src.fedoraproject.org/rpms/elementary-greeter/blob/f30/f/elementary-greeter.rpmlintrc > > > > This was not a known issue, no. It stems from us depending on the > > cgit interface which was taken down a few days ago - we're getting > > 404s when we try to grab the rpmlintrc file > > > > I'm still looking into this but have filed an issue track it: > > > > https://pagure.io/taskotron/libtaskotron/issue/429 > > > > Thanks for the report and sorry for the bother. > > > > Tim > > > > Great, thanks for looking into it! > > pagure provides really simple URLs to fetch raw files, so it > shouldn't be hard to adapt the code from cgit, for example: > > https://src.fedoraproject.org/rpms/elementary-photos/raw/47e73b7ac14dea07b5fcbd39b5f2aff67fea4fbc/f/elementary-photos.rpmlintrc The freeze break request I needed to update the packages was approved over the weekend and libtaskotron has been updated in production. This issue with finding package-specific rpmlintrc files should be fixed. Please let us know if you continue to see the issue. Thanks, Tim pgpwZidTguql8.pgp 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote: > John Reiser writes: [..] > > What is the nature of the incompatibilities, and what are specific > > examples? > > We switched to from the POSIX regex library to as it should be > provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does > not properly implement and it made a lot of tests fail. We have > therefore switched to using the SCL gcc & clang compiler for now. Yes, at least GCC 4.8/4.9 (with the then current libstdc++) featured a severely broken (e.g. also on Fedora 19). If it's just an alternative is to fallback to Boost regex - e.g. like this: #ifdef SOME_MACRO_THAT_SIGNALS_PROPER_REGEX_AVAILABILITY #include namespace re = std; #else #include namespace re = boost; #endif And then use re::regex re::regex_match etc. in your code. Best regards Georg -- 'Embrace change' (Barack Ob^W^WKent Beck) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190429.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 3 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 10/137 (x86_64), 1/2 (arm), 2/24 (i386) ID: 393350 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/393350 ID: 393370 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/393370 ID: 393382 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/393382 ID: 393383 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/393383 ID: 393397 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/393397 ID: 393399 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/393399 ID: 393402 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/393402 ID: 393422 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/393422 ID: 393452 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/393452 ID: 393465 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/393465 ID: 393469 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/393469 ID: 393480 Test: i386 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/393480 ID: 393490 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/393490 Soft failed openQA tests: 3/24 (i386), 7/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 393362 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/393362 ID: 393363 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/393363 ID: 393372 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/393372 ID: 393381 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/393381 ID: 393386 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/393386 ID: 393413 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/393413 ID: 393415 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/393415 ID: 393416 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/393416 ID: 393417 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/393417 ID: 393473 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/393473 Passed openQA tests: 120/137 (x86_64), 19/24 (i386) Skipped non-gating openQA tests: 1 of 163 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning rubygem-jquery-ui-rails
$SUBJ, as I have no use for it. -- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity UX Questions
Hello, please could you tell me if any decisions have been made on how this thread is going to be handled? Is it defined somewhere, where I could read, what the behaviour will be like? Thanks. On Tue, Apr 2, 2019 at 3:19 PM Adam Samalik wrote: > > > On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher > wrote: > >> On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik wrote: >> >> > When a packager doesn't provide the YAML defaults file at all, I'd >> assume it could have been unintentional and notified them about that fact. >> However, I wouldn't prevent the module to get to the compose or anything — >> just let them know so they can decide. >> > >> > How DNF should behave? Considering there is no default stream nor >> default profile, I'd suggest the following command to fail with an >> appropriate error message: >> > >> > $ dnf module install modulename:stream >> > >> > I'd strongly encourage DNF to suggest how to move forward, notifying >> the user there is no default profile defined for this module and that they >> either need to specify one in the install command: >> > >> > $ dnf module install modulename:stream/profile >> > >> > ... or to enable the module in order to consume the packages directly >> by the following command: >> > >> > $ dnf module enable modulename:stream >> > $ dnf install packagename >> > >> > As Modularity is a new technology, I personally wouldn't be afraid of >> longer error messages — within reason of course — giving the user guidance. >> > >> >> Yeah, I think if no default object exists in the metadata, `dnf module >> install modulename:stream` should probably not install anything and >> instead prompt them to select a profile explicitly (ideally listing >> the available options or suggesting `dnf enable modulename:stream`). >> >> >> >> >> >> >> >> >> === A module has explicitly set one or more of its streams to have no >> >> default profiles === >> >> >> >> This is a similar case to the above, except that a conscious choice >> >> was made by the module maintainer to say that this module has no >> >> reasonable default packages that could be selected. (For example, it >> >> could be a collection of popular libraries that extend a particular >> >> programming language, but there’s no obvious subset of them that makes >> >> sense to install. It may exist and have streams solely because it >> >> needs to be kept in sync with the interpreter version.) >> >> >> >> The open question is the same as the previous one: how should dnf >> >> module install handle this case? In this particular example, it might >> >> be more acceptable that it follows the enable fallback, since the >> >> maintainer selected the lack of a profile explicitly. However, having >> >> context-sensitive differences can be difficult for people to process. >> > >> > >> > I assume the difference here is that the packager has provided the YAML >> defaults file, but haven't specified a default profile as opposed to not >> providing that file at all? >> > >> >> No, this is "the packager has provided a YAML defaults file like: >> >> ``` >> document: modulemd-defaults >> version: 1 >> data: >> modified: 20190402 >> module: somemodule >> stream: 1.0 >> profiles: >> 1.0: [ ] >> ``` >> >> See that the '1.0' stream is listed as having an empty set of default >> profiles. Thus, a conscious decision has been made that no default >> makes sense for this stream. What do we do here? >> >> I'm leaning towards treating it like the above. DNF should provide a >> helpful error suggesting available profiles or `dnf enable >> module:stream` >> > > Ah, got it! > > Still strongly prefer consistent behaviour of this and the above — failing > and giving the user a guidance. > > >> >> >> > If that's true, I would strongly prefer consistency and fail on an >> install command without having a stream specified, and give the user >> guidance in an error message as above. >> > >> >> >> >> >> >> >> >> === A module has a profile that contains zero RPMs === >> >> >> >> In this case, a profile definition has been made in the module >> >> metadata and it explicitly contains zero RPMs within it. Such an >> >> example might be for compatibility: the module previously provided a >> >> profile with that name that contained content, but it is no longer >> >> doing so. Retaining the name may have been done to allow existing >> >> scripts to avoid breaking. If we have a profile that contains zero >> >> packages, should it be an error if we attempt to install it? If not, >> >> what should the UX look like? >> > >> > >> > This seams as a strange, yet possible choice for the packager to make. >> > >> > I do not have a strong opinion on this one. I'd probably suggest to not >> be too clever and let them have that choice, and make the install command >> work without installing any RPMs, and possibly emit a warning to the user >> about the fact. >> >> Yeah, I'm leaning towards making a zero-package profile be a >> validation error in libmodu
Re: Fedora 32 System-Wide Change proposal: Retire Python 2
On Thu, 2019-04-25 at 21:13 +0200, Miro Hrončok wrote: > On 25. 04. 19 20:33, Adam Jackson wrote: > > On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote: > > > On 25. 04. 19 18:38, Nico Kadel-Garcia wrote: > > > > How much is going to be needed for "mock" to still work for older > > > > operating systems? > > > > > > I'm confused. How is the change relevant for mock? I think I'm missing > > > some > > > pieces of the thought process here, could you please elaborate on that? > > > > mock defaults to setting up buildroots for older OSes with yum, from > > the containing OS' side. yum is python2-only. So a py2-less host OS > > can't build for older OSes, without some finagling. In fact currently > > mock _defaults_ to yum, even for newer OSes, so removing python2 breaks > > mock's default invocation. > > yum was already removed from Fedora 31. So removal of python2 doesn't change > this, or does it? I suppose removing python2 does not make it any _more_ broken, no. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
John Reiser writes: > It would be useful for posts to be specific, and/or to include a link > to a detailed explanation. Such information might attract the interest > of others, and tend to encourage the discovery of multiple approaches > towards dealing with the underlying problems. > > > On 4/29/19 1210 UTC, Jonathan Wakely wrote: >> On 29/04/19 07:52 -0400, Neal Gompa wrote: >>> On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák >>> wrote: Hi list, I'm co-maintaining a C++ library that has been continuously updated in > > Which library in which package? libexiv2 in the exiv2 package. > CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7. > > What is the nature of the incompatibilities, and what are specific > examples? We switched to from the POSIX regex library to as it should be provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does not properly implement and it made a lot of tests fail. We have therefore switched to using the SCL gcc & clang compiler for now. > Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too. >>> >>> Software Collections GCC is configured to follow C++ ABI from system >>> GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, > > For example, or a link to an explanation? > >>> but allows us to avoid that problem entirely. >> >> If you're talking about the devtoolset version of GCC, that's not >> strictly true. There are limitations on what is supported, so the > > For example; or a link to an explanation? > >> problem isn't avoided entirely. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Un-orphaned NodeJS packages upgrades in rawhide
On 2019-04-29 10:31 a.m., Tom Hughes wrote: > On 29/04/2019 15:21, Jan Staněk wrote: > >> Only other option I can think of is going the Rust route (packages only >> in rawhide, anything depending on them must be a module), which I'm not >> a fan of. > > Module don't work for Node.js though. > > They work for rust and go because of static linking, so different > packages can pull in the library versions (from parallel available > modules) at build time and then those libraries are statically > linked into the resulting program. > > Node.js is totally different though - there the node modules are > needed at run time by the installed packages not just at build time > so you would need parallel installability not just availability. Right. For major versions the only way is to resort to the good olde versioned packages. nodejs-xxx for the latest and nodejs-xxxN for the legacy one needed In the case of node I wonder if all packages should not be versioned with the major version anyway. Besides that, we'd have to relax dependencies with '^' around. But to do that we'd need to have some basic tests for the modules we meddle with the dependencies. Fernando > > Tom > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
It would be useful for posts to be specific, and/or to include a link to a detailed explanation. Such information might attract the interest of others, and tend to encourage the discovery of multiple approaches towards dealing with the underlying problems. On 4/29/19 1210 UTC, Jonathan Wakely wrote: On 29/04/19 07:52 -0400, Neal Gompa wrote: On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák wrote: Hi list, I'm co-maintaining a C++ library that has been continuously updated in Which library in which package? CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7. What is the nature of the incompatibilities, and what are specific examples? Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too. Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, For example, or a link to an explanation? but allows us to avoid that problem entirely. If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the For example; or a link to an explanation? problem isn't avoided entirely. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190429.n.0 changes
OLD: Fedora-Rawhide-20190428.n.0 NEW: Fedora-Rawhide-20190429.n.0 = SUMMARY = Added images:14 Dropped images: 5 Added packages: 24 Dropped packages:0 Upgraded packages: 78 Downgraded packages: 1 Size of added packages: 8.85 MiB Size of dropped packages:0 B Size of upgraded packages: 4.19 GiB Size of downgraded packages: 416.29 MiB Size change of upgraded packages: 104.17 MiB Size change of downgraded packages: -17.99 KiB = ADDED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190429.n.0.s390x.tar.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190429.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.ppc64le.qcow2 Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.s390x.raw.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.s390x.vmdk Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190429.n.0.x86_64.vagrant-libvirt.box Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190429.n.0.iso Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.ppc64le.vmdk Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190429.n.0.iso Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190429.n.0.s390x.qcow2 Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20190429.n.0.ppc64le.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20190429.n.0.ppc64le.tar.xz Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20190429.n.0.iso = DROPPED IMAGES = Image: Xfce live i386 Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20190428.n.0.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20190428.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190428.n.0-sda.raw.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20190428.n.0.x86_64.tar.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20190428.n.0.iso = ADDED PACKAGES = Package: rust-aes-soft-0.3.3-1.fc31 Summary: AES (Rijndael) block ciphers bit-sliced implementation RPMs:rust-aes-soft+default-devel rust-aes-soft-devel Size:94.82 KiB Package: rust-afterburn-4.1.0-1.fc31 Summary: Simple cloud provider agent RPMs:afterburn Size:7.81 MiB Package: rust-atk-0.6.0-1.fc31 Summary: Rust bindings for the ATK library RPMs:rust-atk+default-devel rust-atk+dox-devel rust-atk+embed-lgpl-docs-devel rust-atk+gtk-rs-lgpl-docs-devel rust-atk+purge-lgpl-docs-devel rust-atk+v2_30-devel rust-atk-devel Size:85.13 KiB Package: rust-block-cipher-trait-0.6.2-1.fc31 Summary: Traits for description of block ciphers RPMs:rust-block-cipher-trait+blobby-devel rust-block-cipher-trait+default-devel rust-block-cipher-trait+dev-devel rust-block-cipher-trait+std-devel rust-block-cipher-trait-devel Size:44.04 KiB Package: rust-block-modes-0.3.2-1.fc31 Summary: Block cipher modes of operation RPMs:rust-block-modes+default-devel rust-block-modes+std-devel rust-block-modes-devel Size:29.50 KiB Package: rust-defmac-0.2.0-1.fc31 Summary: Macro to define lambda-like macros inline RPMs:rust-defmac+default-devel rust-defmac-devel Size:22.44 KiB Package: rust-hex-literal-0.2.0-1.fc31 Summary: Procedural macro for converting hexadecimal string RPMs:rust-hex-literal+default-devel rust-hex-literal-devel Size:21.12 KiB Package: rust-hex-literal-impl-0.2.0-1.fc31 Summary: Internal implementation of the hex-literal crate RPMs:rust-hex-literal-impl+default-devel rust-hex-literal-impl-devel Size:21.07 KiB Package: rust-iter-read-0.2.0-1.fc31 Summary: Read implementation for iterators over u8 and related types RPMs:rust-iter-read+default-devel rust-iter-read+unstable-devel rust-iter-read-devel Size:30.94 KiB Package: rust-lmdb-0.8.0-1.fc31 Summary: Idiomatic and safe LMDB wrapper RPMs:rust-lmdb+default-devel rust-lmdb-devel Size:36.89 KiB Package: rust-lmdb-sys-0.8.0-1.fc31 Summary: Rust bindings for liblmdb RPMs:rust-lmdb-sys+default-devel rust-lmdb-sys-devel Size:18.98 KiB Package: rust-mdl-1.0.4-1.fc31 Summary: Data model library to share app state between threads and process RPMs
Orphaning system-config-firewall
Hi, I am orphaning system-config-firewall. It currently FTBFS and is unmaintained upstream. Migration to firewalld can be done with # firewall-offline-cmd --migrate-system-config-firewall=file Thanks. Eric. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Un-orphaned NodeJS packages upgrades in rawhide
On 29/04/2019 15:21, Jan Staněk wrote: Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of. Module don't work for Node.js though. They work for rust and go because of static linking, so different packages can pull in the library versions (from parallel available modules) at build time and then those libraries are statically linked into the resulting program. Node.js is totally different though - there the node modules are needed at run time by the installed packages not just at build time so you would need parallel installability not just availability. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Un-orphaned NodeJS packages upgrades in rawhide
On 29. 04. 19 15:42, Jared K. Smith wrote: > One of the frustrating things with NodeJS packaging in Fedora is that > because of the crazy number of dependencies between NodeJS packages, a > simple version bump in one package could cause a whole cascade of other > packages that need to be updated to newer versions to support that > dependency here. That's why I'm only doing this in Rawhide (and I would love to have something akin to Rawhide-testing). > The right thing to do in this case is to look at each of those packages, > find anything that's dependent upon those packages, and make sure each > one will still work with the newer version of the package. That will never work (long-term) without the cooperation with the maintainers of the affected packages. I'm happy to help with any issues caused by the update, but I would leave finding these issues to koschei. Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of. Best regards, -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Un-orphaned NodeJS packages upgrades in rawhide
On Mon, Apr 29, 2019 at 7:49 AM Jan Staněk wrote: > Hello, > I have recently (last week) taken on maintenance of several to-be > orphaned nodejs packages. Since the packages were not upgraded for a > while, they are usually a major version behind the upstream release. > I have started to remedy this, but given the relatively large jump in > version numbers, there might be issues. > One of the frustrating things with NodeJS packaging in Fedora is that because of the crazy number of dependencies between NodeJS packages, a simple version bump in one package could cause a whole cascade of other packages that need to be updated to newer versions to support that dependency here. The right thing to do in this case is to look at each of those packages, find anything that's dependent upon those packages, and make sure each one will still work with the newer version of the package. It's tiresome, thankless work -- and you often end up getting three or four levels down the dependency tree before realizing things aren't going to work -- which is why I've stepped away from packaging up new NodeJS packages for a while... -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
On 29/04/19 07:52 -0400, Neal Gompa wrote: On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák wrote: Hi list, I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7. Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too. Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, but allows us to avoid that problem entirely. If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the problem isn't avoided entirely. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Mon, Apr 29, 2019 at 06:29:06AM -0400, Neal Gompa wrote: > On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering > wrote: > > > > On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > Hi everyone, > > > > > > currently, we autogenerate a dependency on pkg-config for all rpms > > > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > > > returns 4632 entries on my laptop. > > > > You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, > > which is currently owned by pkgconf-pkg-config, no? > > > > Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content. Or simply co-own the directory from all packages that put files there. Systemd does this already, and explicitly skips the dependency on pkg-config. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Mon, Apr 29, 2019 at 8:05 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Apr 29, 2019 at 06:29:06AM -0400, Neal Gompa wrote: > > On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering > > wrote: > > > > > > On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > > wrote: > > > > > > > Hi everyone, > > > > > > > > currently, we autogenerate a dependency on pkg-config for all rpms > > > > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > > > > returns 4632 entries on my laptop. > > > > > > You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, > > > which is currently owned by pkgconf-pkg-config, no? > > > > > > > Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content. > > Or simply co-own the directory from all packages that put files there. > Systemd does this already, and explicitly skips the dependency on pkg-config. > It does this specifically because a pc file is shipped in the main package. That's a pretty rare circumstance. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
On Mon, 29 Apr 2019 at 07:51, Dan Čermák wrote: > Hi list, > > I'm co-maintaining a C++ library that has been continuously updated in > CentOS 7 but a recent change made it incompatible with the default GCC > version available in el7. I.e. the next release (scheduled for the end > of 2019) will FTBFS in CentOS/RHEL 7. > > I think this question should be more aimed at the epel-devel list versus the fedora devel list.. EPEL does allow for SCL's to be used for building packages but not for requiring it to be installed. > Would it be fine to require a gcc version from a SCL to build this > library? I'm afraid that due to the nature of C++'s non-standardized ABI > it would require all dependent packages to be rebuild with gcc from the > SCL too. > > Will bow to what Neal and others say on this part. > > Cheers, > > Dan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using SCLs to build a C++ library for EL 7?
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák wrote: > > Hi list, > > I'm co-maintaining a C++ library that has been continuously updated in > CentOS 7 but a recent change made it incompatible with the default GCC > version available in el7. I.e. the next release (scheduled for the end > of 2019) will FTBFS in CentOS/RHEL 7. > > Would it be fine to require a gcc version from a SCL to build this > library? I'm afraid that due to the nature of C++'s non-standardized ABI > it would require all dependent packages to be rebuild with gcc from the > SCL too. > Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, but allows us to avoid that problem entirely. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Using SCLs to build a C++ library for EL 7?
Hi list, I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7. Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too. Cheers, Dan 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Un-orphaned NodeJS packages upgrades in rawhide
Hello, I have recently (last week) taken on maintenance of several to-be orphaned nodejs packages. Since the packages were not upgraded for a while, they are usually a major version behind the upstream release. I have started to remedy this, but given the relatively large jump in version numbers, there might be issues. If your node package stops building in rawhide suddenly, check the dependencies for updates; feel free to reach to me with related issues. The upgraded (or soon to be upgraded) packages in question: - nodejs-bluebird - nodejs-clean-css - nodejs-grunt-known-options - nodejs-path-exists Keep in mind that the above list might expand in the near future, given the current situation with many nodejs-* orphans. -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering wrote: > > On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > Hi everyone, > > > > currently, we autogenerate a dependency on pkg-config for all rpms > > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > > returns 4632 entries on my laptop. > > You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, > which is currently owned by pkgconf-pkg-config, no? > Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers
On Mon, Apr 29, 2019, 11:47 Jan Staněk wrote: > On 27. 04. 19 10:51, Miro Hrončok wrote: > > Zuzka, Jan, I've seen you requested soem nodejs packages recently. Would > > you be able to take some more? > > If needed to keep them from orphaning, yes; but I cannot promise any > really active maintenance. The best I can promise is that I will *try* > to keep them up to date with upstream; any bugs will likely go unfixed > (unless included in upstream update, OFC). > This sounds a lot like what the Stewardship SIG is aiming for. Feel free to apply for membership if you're interested in sharing the maintenance burden with like-minded, responsible packagers, until a permanent maintainer can be found for these packages. Fabio -- > Jan Staněk > Associate Software Engineer, Core Services > Red Hat Czech > jsta...@redhat.com IM: jstanek > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers
On 27. 04. 19 10:51, Miro Hrončok wrote: > Zuzka, Jan, I've seen you requested soem nodejs packages recently. Would > you be able to take some more? If needed to keep them from orphaning, yes; but I cannot promise any really active maintenance. The best I can promise is that I will *try* to keep them up to date with upstream; any bugs will likely go unfixed (unless included in upstream update, OFC). -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Mon, Apr 29, 2019 at 8:44 AM Miro Hrončok wrote: > On 29. 04. 19 8:26, Igor Gnatenko wrote: > > This is what wiki says: > > > > * |/usr/bin/gdb.minimal| — GDB executable built without optional > unneeded features > > * |/usr/bin/gdb-add-index| — Executable script shared with gdb-headless > > package (modified to fallback to gdb.minimal if exists) > > > > gdb-add-index is in both gdb-minimal and gdb-headless. > > Except: > > - that's not currently true - proper conflicts for lower versions need to be added then (not there now) > > Can we please figure the plan and **approve the change** before doing it? > > > https://src.fedoraproject.org/rpms/gdb/c/cc7695234a0fb5d5e1357d9e30354aecc3fdc4e5?branch=master This specific commit does not break anything, it is preparation. It does not break anything or so. This is the change we actually need to do for implementing change: https://src.fedoraproject.org/rpms/gdb/pull-request/2 > > > -- > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dropping autogenerated dependency on pkg-config
On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > Hi everyone, > > currently, we autogenerate a dependency on pkg-config for all rpms > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > returns 4632 entries on my laptop. You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, which is currently owned by pkgconf-pkg-config, no? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Informal Review Request
Hi all, since backintime released a new, major update we need to transition away from Qt4 to Qt5. I would like to ask for an informal review on the newly created spec file. https://bugzilla.redhat.com/show_bug.cgi?id=1703680 Additionally, I would like to ask if we should get rid of the -common subpackage. Originally this was needed, because backintime offered several GUI options, but nowadays only one (Qt) is left, so actually there is no advantage of a -common package, because there aren't any GUIs, which share anything. Also please check if the Provides, Obsoletes stuff works, I've tested it on fedora 29 and all seems to be working. Thanks in advance Johannes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
