Builds failing with connection refused error
I don't see anything but green on status.fedoraproject.org, but the
last two builds I have submitted have both failed on s390x only with
an error that looks like this:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1244, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 307, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 209, in
call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 1195, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 477, in localPath
fsrc = six.moves.urllib.request.urlopen(url)
File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
File "/usr/lib64/python2.7/urllib2.py", line 447, in _open
'_open', req)
File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/usr/lib64/python2.7/urllib2.py", line 1230, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib64/python2.7/urllib2.py", line 1200, in do_open
raise URLError(err)
URLError:
Are the s390x builders offline? The host for the most recent build is
buildvm-s390x-07.s390.fedoraproject.org.
Thanks,
--
Jerry James
http://www.jamezone.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/message/Z6WI66QQOOSHDK2MZS7NGAOCPVVTSV46/
Question about a package I might update
Brotli 1.0.5 is out and I might update it in Rawhide, but the tool I used to check ABI differences seems to have stopped working on both Arch and Fedora. So I'm not sure if Brolti included any ABI/API breaking changes. Should I push an update anyway? -- GPG Keys: https://keybase.io/pouar Tox ID: 2EA7A6D5494C10B2E0F32004A1E9CBD971777E551A902059E5EA7E73E5A299272F29D9FF5F6A Matrix ID: @Pouar:matrix.org Social Links: https://www.pouar.net/social.php BEGIN:VCARD VERSION:4.0 CLASS:public N:Dragon;Pouar;;; X-EVOLUTION-FILE-AS:Pouar Dragon FN:Pouar Dragon EMAIL:po...@pouar.net NICKNAME:Pouar GENDER:M URL:https://www.pouar.net X-TWITTER:https://twitter.com/the_pouar X-MOZILLA-HTML:FALSE X-EVOLUTION-BLOG-URL:https://drupal.pouar.net X-KADDRESSBOOK-BlogFeed:https://drupal.pouar.net X-KADDRESSBOOK-OPENPGPFP:E107AB5293597577A88AB4AF725BA94668AECE69 X-KADDRESSBOOK-CRYPTOPROTOPREF:openpgp/mime X-KADDRESSBOOK-CRYPTOSIGNPREF:alwaysIfPossible NOTE:PGP Keys: https://keybase.io/pouar REV:2017-04-17T14:58:50Z(8) END:VCARD pgpkYve7v0auk.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/message/WEDEE25MRRUQULYIIMSXJRZDEZYDTEXS/
Orphaning python-pyopengl
Hi, I have just gotten the python-pyopengl package to a state where it builds in the f29-python side tag, but will have to orphan the package from this point on, as I just don't have the spare cycles to work on it moving forward. The package is pretty dead upstream, with the last proper release being 2014. The package was largely inactive since, apart a brief flurry of activity on github in February of this year[0]. At this point, folks should consider migrating to using the ModernGL[1] bindings instead, as these are much easier to use, and upstream is very active, and support for later OpenGL versions is present. In order to get the package to build for Python 3.7 I had to: 1. Rebuild all Cython generated .c files 2. (1) above required adding some .pxd files missing from the tarball release 3. Rename two modules that were called "async.py" to "async_.py" since async became a keyword in Python 3.7. So, at this point the Fedora package has even had to diverge from the (dormant) upstream API. In addition, the scripts used to generate the python bindings have bit rotted over the years and will only run with Python 2.7. So, if you're interested in maintaining this package, please do grab it. Cheers, Jonathan [0] https://github.com/mcfletch/pyopengl [1] https://github.com/cprogrammer1994/ModernGL ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6Q366GL4ZOOP2IV546VKEPJXMH4DZYAY/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
On Sat, Jun 30, 2018 at 01:22:46PM +0200, Nicolas Mailhot wrote: > Le samedi 30 juin 2018 à 12:46 +0200, Nicolas Mailhot a écrit : > > Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit : > > > FWIW, a fun read from the debian pkg-go list about packaging docker > > > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian. > > > ne > > > t/msg00032.html > > > > And so what? I hit this problem months ago (and I have the github > > tickets to prove it, with the Debian maintainers me-too-ing a few > > weeks later). > > And, to follow on your example, just in case someone thinks it was smart > to vendor blindly whatever code upstream was stuck at, and leave > dependency checking to someone else. > > Updating the Azure component Debian people complain about in their > message was necessary to update the Azure component dealing with > authentification and resource management, and the changelog of *this* > component states: > > /Fixed a race condition in token refresh./ > > Race condition in auth management on one of the three big clouds? No > biggie! Sleep well everyone. Please help me understand, was this a runtime dependency or a build dependency? Thanks, > > -- > Nicolas Mailhot -- Lokesh IRC: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XRW47VLYJSGMBQPNERIO2DNHWNQGPEXB/
Re: Fwd: gcompris-qt: help needed
Hi! On Sat, Jun 30, 2018 at 6:02 PM, Robert-André Mauchin wrote: > I've Searched for bugs at our ArchLinux fellows and they mentioned this: > > https://bugs.archlinux.org/task/57542?project=0&order=id&sort=desc&status > %5B0%5D=closed&string=gcompris-qt > > It seems caused by this change: > https://bugreports.qt.io/browse/QTBUG-65789 > > It is fixed by this commit which should then be backported to f28 > https://github.com/qt/qtdeclarative/commit/602a6589 > > See result of patch: https://imgpile.com/images/nE8RpM.md.png > > Then as you can see the first icon is the wrong size, it is too small: > this > another bug that is affecting the SVG images once the first one is solved: > https://bugreports.qt.io/browse/QTBUG-67019 > > This is fixed by > https://github.com/qt/qtdeclarative/commit/b1243b8c > > Here we go, with both patches, we have the full UI: > https://imgpile.com/images/nE8bb4.md.png > > Now let's make a pull request: > https://src.fedoraproject.org/rpms/qt5-qtdeclarative/pull-request/2 > > I'm CCing Rex Dieter, hoping he can merge this PR soon. > Thank you very much for your precious help! Andrea. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LLRRH6RLTZFCEJI5J2N4UCE7GZA6VUD2/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
On Sat, Jun 30, 2018 at 12:46:28PM +0200, Nicolas Mailhot wrote: > Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit : > > FWIW, a fun read from the debian pkg-go list about packaging docker > > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian.ne > > t/msg00032.html > > And so what? I hit this problem months ago (and I have the github > tickets to prove it, with the Debian maintainers me-too-ing a few weeks > later). And some of those have been fixed since thanks to the reporting. > > The problem is not this message, that's upstream software needing > fixing, we handle tons of those in Fedora all year round, the problem is > that you seem to find normal *others* identified it, you seem to find > normal *not* *involving* yourself in the reporting and the fixing, you > seem to find normal functioning in some sort of fourth dimension where > FLOSS community fixing and collaborating happens to someone else. > > Go upstream state is a hard problem. But it needs to be solved because > no matter how you look at it there is a ton of go software that wants to > integrate with either kubernetes or docker. Stuff that is usually > *useful* for container users BTW. Stuff *you* could pull on for future > openshift enhancements if you made a minimum effort to nurture its > packaging in Fedora. Could you please give details on *stuff*, *integration* and *enhancements* you're talking about, and how exactly would unbundling help achieve that? Thanks, > > Making temporary exceptions for bits of bundling because they're too > broken to integrate right now is one thing. Passing on entirely and > letting the whole thing rot for years is something else entirely. > > There is maybe 95% of Go packages that kubernetes need that present no > technical challenge to package as rpm and use as rpm (some of this code > has not been changed upstream for years!). The 5% remaining problem > stuff could be bundled and then chipped at years after year till it's > not a problem anymore. It *needs* chipping at to improve the codebase > and the maintainability of it all. > > But you use this 5% as the reason not to play the game at all. > > Why ? > > -- > Nicolas Mailhot -- Lokesh IRC: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TPJGTCCLH5MSZOZS6CEVSC6OYO6HWDG4/
Fedora Rawhide-20180630.n.0 compose check report
No missing expected images. Failed openQA tests: 4/138 (x86_64), 23/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180629.n.0): ID: 253878 Test: x86_64 Server-dvd-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/253878 ID: 253915 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/253915 ID: 253984 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/253984 ID: 254008 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/254008 Old failures (same test failed in Rawhide-20180629.n.0): ID: 253887 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/253887 ID: 253888 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/253888 ID: 253891 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/253891 ID: 253908 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/253908 ID: 253909 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/253909 ID: 253910 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/253910 ID: 253924 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/253924 ID: 253925 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/253925 ID: 254011 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/254011 ID: 254013 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/254013 ID: 254014 Test: i386 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/254014 ID: 254015 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/254015 ID: 254016 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/254016 ID: 254017 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/254017 ID: 254018 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/254018 ID: 254019 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/254019 ID: 254020 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/254020 ID: 254021 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/254021 ID: 254022 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/254022 ID: 254023 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/254023 ID: 254024 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/254024 ID: 254025 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/254025 ID: 254026 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/254026 ID: 254027 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/254027 Soft failed openQA tests: 5/138 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20180629.n.0): ID: 253990 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/253990 ID: 253991 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/253991 ID: 254005 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/254005 Old soft failures (same test soft failed in Rawhide-20180629.n.0): ID: 253886 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/253886 ID: 253912 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/253912 Passed openQA tests: 129/138 (x86_64), 1/24 (i386) New passes (same test did not pass in Rawhide-20180629.n.0): ID: 253913 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/253913 ID: 253927 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/253927 ID: 253929 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/253929 ID: 253942 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/253942 ID: 253985 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/253985 Skipped openQA tests: 1 of 164 Installed system changes in test x86_64 Server-boot-iso instal
Re: F29 System Wide Change: Make BootLoaderSpec the default
On 06/30/2018 10:11 AM, Lennart Poettering wrote: > On Fr, 29.06.18 17:26, Kyle Marek (pspps...@gmail.com) wrote: > >> Kernel updates are different. You *have* to reboot in order to run the >> new kernel (except for security updates applied with kpatch) and a >> broken kernel has the potential to simply lock up without even launching >> /sbin/init, for example. In these situations, administrators have to >> manually reboot the machine. > That's not true. UEFI provides interfaces to configure the system > watchdog. This means the boot loader can set up the watchdog right > before starting the kernel, and if userspace doesn't take possesion of > the watchdog in time the system will reboot automatically, triggered > by hardware. > >> No amount of unattended failed-boot-check logic in the bootloader can >> run without user intervention when a broken kernel is still running/just >> sitting there. > That's simply not true. UEFI provides everything to make kernel > updates mostly safe. And when either of these things themselves have bugs, or aren't on an EFI system...? Or kernel does take possession of the watchdog but something important crashes immediately afterwards (initrd drops to shell)? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WCJGHCBJQMREG2RH667GNVDPUBYBBBCT/
Fedora rawhide compose report: 20180630.n.0 changes
OLD: Fedora-Rawhide-20180629.n.0 NEW: Fedora-Rawhide-20180630.n.0 = SUMMARY = Added images:8 Dropped images: 2 Added packages: 1 Dropped packages:1 Upgraded packages: 166 Downgraded packages: 0 Size of added packages: 103.00 KiB Size of dropped packages:294.89 KiB Size of upgraded packages: 2.78 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -22.85 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20180630.n.0.iso Image: Scientific vagrant-virtualbox i386 Path: Labs/i386/images/Fedora-Scientific-Vagrant-Rawhide-20180630.n.0.i386.vagrant-virtualbox.box Image: Scientific vagrant-libvirt i386 Path: Labs/i386/images/Fedora-Scientific-Vagrant-Rawhide-20180630.n.0.i386.vagrant-libvirt.box Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20180630.n.0.s390x.tar.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180630.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180630.n.0.s390x.qcow2 Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180630.n.0.s390x.raw.xz Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20180630.n.0.iso = DROPPED IMAGES = Image: Python_Classroom vagrant-virtualbox i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180629.n.0.i386.vagrant-virtualbox.box Image: Python_Classroom vagrant-libvirt i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180629.n.0.i386.vagrant-libvirt.box = ADDED PACKAGES = Package: piper-0.2.900-1.20180214git5f6ed20.fc29 Summary: GTK application to configure gaming mice RPMs:piper Size:103.00 KiB = DROPPED PACKAGES = Package: keybinder-3.0-0.3.2-1.fc29 Summary: A library for registering global keyboard shortcuts RPMs:keybinder-3.0 keybinder-3.0-devel Size:294.89 KiB = UPGRADED PACKAGES = Package: NetworkManager-1:1.12.0-1.fc29 Old package: NetworkManager-1:1.12.0-0.1.fc29 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 29.89 MiB Size change: -9.23 MiB Changelog: * Fri Jun 29 2018 Thomas Haller - 1:1.12.0-1 - Update to 1.12.0 release Package: RBTools-1.0-1.fc29 Old package: RBTools-0.7.11-2.fc28 Summary: Tools for use with ReviewBoard RPMs: RBTools Size: 359.25 KiB Size change: 19.89 KiB Changelog: * Fri Jun 29 2018 Stephen Gallagher - 1.0-1 - Update to RBTools 1.0 - https://www.reviewboard.org/docs/releasenotes/rbtools/1.0/ Package: ant-1.10.4-1.module_1886+ece9a977 Old package: ant-1.10.3-1.module_1647+a6ce00f6 Summary: Java build tool RPMs: ant ant-lib Size: 2.19 MiB Size change: 14.01 KiB Changelog: * Wed Apr 18 2018 Mikolaj Izdebski - 0:1.10.3-2 - Remove legacy Obsoletes/Provides * Tue Jun 26 2018 Michael Simacek - 0:1.10.4-1 - Update to upstream version 1.10.4 - Resolves: rhbz#1584407 Package: anthy-9100h-35.fc29 Old package: anthy-9100h-34.fc28 Summary: Japanese character set input library RPMs: anthy anthy-devel Size: 42.56 MiB Size change: -131.82 KiB Changelog: * Fri Jun 29 2018 Akira TAGOH - 9100h-35 - Use ldconfig rpm macro. Package: aopalliance-1.0-17.module_1885+a6f9b3e6 Old package: aopalliance-1.0-17.module_1646+a96ec35f Summary: Java/J2EE AOP standards RPMs: aopalliance Size: 16.04 KiB Size change: 20 B Package: apache-commons-cli-1.4-4.module_1885+a6f9b3e6 Old package: apache-commons-cli-1.4-4.module_1646+a96ec35f Summary: Command Line Interface Library for Java RPMs: apache-commons-cli Size: 72.75 KiB Size change: -16 B Package: apache-commons-codec-1.11-3.module_1885+a6f9b3e6 Old package: apache-commons-codec-1.11-3.module_1646+a96ec35f Summary: Implementations of common encoders and decoders RPMs: apache-commons-codec Size: 287.46 KiB Size change: 244 B Package: apache-commons-io-1:2.6-3.module_1885+a6f9b3e6 Old package: apache-commons-io-1:2.6-3.module_1646+a96ec35f Summary: Utilities to assist with developing IO functionality RPMs: apache-commons-io Size: 222.46 KiB Size change: 12 B Package: apache-commons-lang3-3.7-3.module_1885+a6f9b3e6 Old package: apache-commons-lang3-3.7-3.module_1646+a96ec35f Summary: Provides a
Re: Fwd: gcompris-qt: help needed
On samedi 30 juin 2018 13:25:50 CEST Andrea Musuruane wrote: > Hi! > I'm forwarding this request for help here since it seems there is no > one available on Fedora games. > > The strange thing about this issue is that on F27 everything is fine (the > spec file is the same). > > Thanks in advance, > > Andrea > I've Searched for bugs at our ArchLinux fellows and they mentioned this: https://bugs.archlinux.org/task/57542?project=0&order=id&sort=desc&status %5B0%5D=closed&string=gcompris-qt It seems caused by this change: https://bugreports.qt.io/browse/QTBUG-65789 It is fixed by this commit which should then be backported to f28 https://github.com/qt/qtdeclarative/commit/602a6589 See result of patch: https://imgpile.com/images/nE8RpM.md.png Then as you can see the first icon is the wrong size, it is too small: this another bug that is affecting the SVG images once the first one is solved: https://bugreports.qt.io/browse/QTBUG-67019 This is fixed by https://github.com/qt/qtdeclarative/commit/b1243b8c Here we go, with both patches, we have the full UI: https://imgpile.com/images/nE8bb4.md.png Now let's make a pull request: https://src.fedoraproject.org/rpms/qt5-qtdeclarative/pull-request/2 I'm CCing Rex Dieter, hoping he can merge this PR soon. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CCOE7I2XHTT7ZMAOJA7ZWDADFGJZZYCA/
Re: Hiding the grub menu by default on single OS installs
Le samedi 30 juin 2018 à 14:32 +0200, Hans de Goede a écrit : Hi > > 4. you check every single bit needed to use them works before > > declaring a boot successful > > A boot is declared successful if a user logs in (or the > user session starts if autologin is enabled) and the > usersession lasts at least 2 minutes. So even if login > works, but then for some reason the session crashes immediately > afterwards, that still will NOT count as a boot success. It'd be nice if there was a way to check grub2-editenv works (some dummy action that is tested on boot). I've lost the number of times I had to re-run anaconda on a system just to reinstall the boot stack, because it tends to bork itself on hardware or selinux changes and there is no clear way to reinit it. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O23PNWENZ4H7FH6W5PE6QK34B4DBHKT2/
copr nomenclature
Hello,
lots of times, I see name "copr", "Copr", or "COPR" used somewhere but it's
almost never used correctly for the given context. So I would like to make
it clear, what's the correct way to write it down to get the meaning right.
"Copr" or "COPR" = service providing space for community projects
"copr" or "Copr project" = a single community project
So there are two variants how to refer to service ("Copr" and "COPR").
And there are two variants how to refer to a singular project ("copr" and
"Copr project").
- (minor additional notes to be ignored) -
When referring to a singular project, just saying "copr" is enough. "co"
stands for "community", "pr" stands for "project".
When you write down "Copr project", it literally means "Community projects
project" so it's a bit redundant to write it down that way.
If you liked to refer to the Fedora instance of Copr service, you would
write "Fedora Copr".
If you liked to ignore the previous rule or made it nice for typography,
you would write "fedora copr" like our logo does. This is also good for IRC.
I don't really mind how people write it down but I think it's good to
provide at least some guide in case somebody needs to think about this :).
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MCTEFU4H7QFUXEFQLPRREGD5RJPE4PPM/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
Le samedi 30 juin 2018 à 14:22 +0200, Tomasz Torcz a écrit : > > BTW, kubernetes package is quite pathological. Installing it brings > kubernetes-master, which contains following four binaries: > > -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/hyperkube > -rwxr-xr--. 1 root kube 128M 04-26 11:34 /usr/bin/kube-apiserver > -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/kube-controller- > manager > -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/kube-scheduler > > That's almost 600 MiB (!!!) in 4 binary files. We can forget about > trying to create minimal fedora install image for cloud, if > installing > single component of k8s triples the installation size. Yes, Go as a whole is hitting the limits of the "pile lots of third party code, hide it in vendored tree, think about modularising and APIs later" But, the code itself is nice and without major problems, it just needs a major injection of release engineering to split what needs splitting and stabilise what needs stabilising. The core problem is that people got used to accumulating technical debt and hoping someone else will take care of it later, and no self- respecting Go dev wants to tackle this if he can avoid it. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G4Z3FFJ45VRZ6QQ53QCNXEWMEFT3LK4W/
[Test-Announce] Fedora 29 Rawhide 20180630.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 29 Rawhide 20180630.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: parted - 20180627.n.0: parted-3.2-33.fc29.src, 20180630.n.0: parted-3.2-34.fc29.src lorax - 20180627.n.0: lorax-29.8-1.fc29.1.src, 20180630.n.0: lorax-29.9-1.fc29.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/29 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_29_Rawhide_20180630.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_29_Rawhide_20180630.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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/message/PHBNHVD2OWPAVGS3IALTJ3O5CVWQMZ7M/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PHBNHVD2OWPAVGS3IALTJ3O5CVWQMZ7M/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Fr, 29.06.18 17:26, Kyle Marek (pspps...@gmail.com) wrote: > Kernel updates are different. You *have* to reboot in order to run the > new kernel (except for security updates applied with kpatch) and a > broken kernel has the potential to simply lock up without even launching > /sbin/init, for example. In these situations, administrators have to > manually reboot the machine. That's not true. UEFI provides interfaces to configure the system watchdog. This means the boot loader can set up the watchdog right before starting the kernel, and if userspace doesn't take possesion of the watchdog in time the system will reboot automatically, triggered by hardware. > No amount of unattended failed-boot-check logic in the bootloader can > run without user intervention when a broken kernel is still running/just > sitting there. That's simply not true. UEFI provides everything to make kernel updates mostly safe. Lennart -- Lennart Poettering, 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2IC2OV7SHOMMUUT6K3U4JFXU4AJEMQC/
Re: macro for /usr/lib/java
Fantastic! Thanks Antonio!
On Sat, Jun 30, 2018 at 10:26 AM, Antonio Trande wrote:
> See
>
> $ cat /usr/lib/rpm/macros.d/macros.jpackage
>
> %_jnidir --> %{_prefix}/lib/java
>
> On 30/06/2018 15:15, Ricardo Martinelli Oliveira wrote:
>> Hello,
>>
>> I'm upgrading sbt and scala packages to 0.13.13 and 2.11.11
>> respectively. I am looking for a way to point to a jar file for
>> jansi-native without hard-coding the path (/usr/lib/java).
>>
>> Is there a macro available that points to that path? what is the best
>> option to avoid hard-code this specific path?
>>
>>
>> Regards,
>>
>> Ricardo Martinelli
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DQIJEBYRFKBGSENXO5B67AX5PCMGLXT6/
>>
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.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/message/MU2NXO6WDVJFEEV6DGHYFFK5IJNZQCNP/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W44Q5QNT7ZNJR26ENPRHZRNXBPAQXYT3/
Re: macro for /usr/lib/java
See
$ cat /usr/lib/rpm/macros.d/macros.jpackage
%_jnidir --> %{_prefix}/lib/java
On 30/06/2018 15:15, Ricardo Martinelli Oliveira wrote:
> Hello,
>
> I'm upgrading sbt and scala packages to 0.13.13 and 2.11.11
> respectively. I am looking for a way to point to a jar file for
> jansi-native without hard-coding the path (/usr/lib/java).
>
> Is there a macro available that points to that path? what is the best
> option to avoid hard-code this specific path?
>
>
> Regards,
>
> Ricardo Martinelli
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DQIJEBYRFKBGSENXO5B67AX5PCMGLXT6/
>
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MU2NXO6WDVJFEEV6DGHYFFK5IJNZQCNP/
macro for /usr/lib/java
Hello, I'm upgrading sbt and scala packages to 0.13.13 and 2.11.11 respectively. I am looking for a way to point to a jar file for jansi-native without hard-coding the path (/usr/lib/java). Is there a macro available that points to that path? what is the best option to avoid hard-code this specific path? Regards, Ricardo Martinelli ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DQIJEBYRFKBGSENXO5B67AX5PCMGLXT6/
Re: Hiding the grub menu by default on single OS installs
Hi, On 29-06-18 17:46, Nicolas Mailhot wrote: Le 2018-05-31 14:25, Hans de Goede a écrit : Originally I was planning on doing the failed-boot detect only for F30, but I agree it makes sense to have it for F29 and this will also give us some field testing of this while we still have a fallback in the form of the 1 sec wait for ESC / F8. Do please make sure that: So there are 2 components involved in fastboot, the firmware and grub, if the firmware sucks, there is nothing we can do (and that already is the case today). E.g. I've several machines where if I enable the fastboot option to not scan the USB bus, the USB bus will not be scanned once grub makes a text input EFI protocol "read key stroke" call. IOW if I enable that fastboot option today, with grub as is in F28, I cannot navigate the grub menu, I believe that the firmware should delay scanning the USB bus until the first "read key stroke" call in this case, but in practice on some systems it seems to simply not bother to scan the USB bus *ever* if this fastboot option is enabled. Now let me answer your questions, with the caveat that my answers are only valid assuming sane firmware, if things are already broken with F28 grub, we cannot fix them. 1. there is a way to demand the next boot will provide the full boot menu with working display and keyboard sudo grub2-set-bootflag menu_show_once Will do this in (F29+) the plan is to also change the "Restart" option in the GNOME3 shutdown modal dialog to "Boot Options" when alt is pressed and then set that flag before rebooting if the user clicks the "Restart/Boot Options" button with alt pressed (similar to how the poweroff icon which gives this menu changes to a pause icon / suspend button when alt is pressed). This will all be documented in the the admin guide and a link to that part of the admin guide will be added to the release-notes. 2. there is a way to demand all boots provide the full boot menu with working display and keyboard This requires running this command *once* : sudo grub2-editenv - unset menu_auto_hide This will also be documented in the admin guide. 3. those ways are easily discoverable by laymen (typically, a notice on the default gfx or cli login screen) See above for the plans to make this discoverable, we believe these are advanced options which should not be visible by default. 4. you check every single bit needed to use them works before declaring a boot successful A boot is declared successful if a user logs in (or the user session starts if autologin is enabled) and the usersession lasts at least 2 minutes. So even if login works, but then for some reason the session crashes immediately afterwards, that still will NOT count as a boot success. This means that we may get a few false positive failed boot detects (e.g. reboot/shutdown within 2 minutes), but the side-effects of that are harmless (menu shown for 5 seconds) where as a false-negative could be troublesome. IOW I agree with you that we need to be careful when we mark a boot successful. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5T6A7DXYD4RO7BZPENTUQ6SYSF6YXAVW/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
On Sat, Jun 30, 2018 at 12:46:28PM +0200, Nicolas Mailhot wrote: > Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit : > > FWIW, a fun read from the debian pkg-go list about packaging docker > > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian.ne > > t/msg00032.html > > And so what? I hit this problem months ago (and I have the github > tickets to prove it, with the Debian maintainers me-too-ing a few weeks > later). And some of those have been fixed since thanks to the reporting. > > The problem is not this message, that's upstream software needing > fixing, we handle tons of those in Fedora all year round, the problem is > that you seem to find normal *others* identified it, you seem to find > normal *not* *involving* yourself in the reporting and the fixing, you > seem to find normal functioning in some sort of fourth dimension where > FLOSS community fixing and collaborating happens to someone else. > > Go upstream state is a hard problem. But it needs to be solved because > no matter how you look at it there is a ton of go software that wants to > integrate with either kubernetes or docker. Stuff that is usually > *useful* for container users BTW. Stuff *you* could pull on for future > openshift enhancements if you made a minimum effort to nurture its > packaging in Fedora. BTW, kubernetes package is quite pathological. Installing it brings kubernetes-master, which contains following four binaries: -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/hyperkube -rwxr-xr--. 1 root kube 128M 04-26 11:34 /usr/bin/kube-apiserver -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/kube-controller-manager -rwxr-xr-x. 3 root root 152M 04-26 11:34 /usr/bin/kube-scheduler That's almost 600 MiB (!!!) in 4 binary files. We can forget about trying to create minimal fedora install image for cloud, if installing single component of k8s triples the installation size. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O73QB2U2SZ4DVMMTSQRSAGP6EY7TLOCF/
Fwd: gcompris-qt: help needed
Hi! I'm forwarding this request for help here since it seems there is no one available on Fedora games. The strange thing about this issue is that on F27 everything is fine (the spec file is the same). Thanks in advance, Andrea -- Forwarded message -- From: Andrea Musuruane Date: Sat, Jun 23, 2018 at 9:27 PM Subject: gcompris-qt: help needed To: Fedora Games Hi all! I'm gcompris-qt maintainer. gcompris-qt was fine until I upgraded to F28. After that, it seems the program is no longer able to shows some graphics. Even a fresh install on a VM shows the same behaviour. Activity menu icons are not shown even though you can select a group blindly clicking on an empty box in upper part of the screen. Then related activities are shown but again without icons and with an textual description. Even inside an activity some graphics are not shown. The program shows no error and it seems it does not complain about anything missing. Any help is really appreciated. Thanks, Andrea ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PSYB66PFPF5UIMV7POW23JCB5GLKON2P/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
Le samedi 30 juin 2018 à 12:46 +0200, Nicolas Mailhot a écrit : > Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit : > > FWIW, a fun read from the debian pkg-go list about packaging docker > > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian. > > ne > > t/msg00032.html > > And so what? I hit this problem months ago (and I have the github > tickets to prove it, with the Debian maintainers me-too-ing a few > weeks later). And, to follow on your example, just in case someone thinks it was smart to vendor blindly whatever code upstream was stuck at, and leave dependency checking to someone else. Updating the Azure component Debian people complain about in their message was necessary to update the Azure component dealing with authentification and resource management, and the changelog of *this* component states: /Fixed a race condition in token refresh./ Race condition in auth management on one of the three big clouds? No biggie! Sleep well everyone. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GYJWJ7ZNHV7HJOZ226LHTGAOGRCKNUYV/
Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit : > FWIW, a fun read from the debian pkg-go list about packaging docker > https://www.mail-archive.com/pkg-go-maintainers@alioth-lists.debian.ne > t/msg00032.html And so what? I hit this problem months ago (and I have the github tickets to prove it, with the Debian maintainers me-too-ing a few weeks later). And some of those have been fixed since thanks to the reporting. The problem is not this message, that's upstream software needing fixing, we handle tons of those in Fedora all year round, the problem is that you seem to find normal *others* identified it, you seem to find normal *not* *involving* yourself in the reporting and the fixing, you seem to find normal functioning in some sort of fourth dimension where FLOSS community fixing and collaborating happens to someone else. Go upstream state is a hard problem. But it needs to be solved because no matter how you look at it there is a ton of go software that wants to integrate with either kubernetes or docker. Stuff that is usually *useful* for container users BTW. Stuff *you* could pull on for future openshift enhancements if you made a minimum effort to nurture its packaging in Fedora. Making temporary exceptions for bits of bundling because they're too broken to integrate right now is one thing. Passing on entirely and letting the whole thing rot for years is something else entirely. There is maybe 95% of Go packages that kubernetes need that present no technical challenge to package as rpm and use as rpm (some of this code has not been changed upstream for years!). The 5% remaining problem stuff could be bundled and then chipped at years after year till it's not a problem anymore. It *needs* chipping at to improve the codebase and the maintainability of it all. But you use this 5% as the reason not to play the game at all. Why ? -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LYEGUB45XVQMDKLRYEHOJ3DPO3ULGQ44/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
Le jeudi 21 juin 2018 à 18:55 +0200, Mikolaj Izdebski a écrit : > > Allowing parallel installation of two distinct package sets, provided > that they don't conflict in any way - how is that impossible? I get > that it's not a goal for modularity to support this, but I don't see > any technical reason not to allow it. It's the usual leaf vs trunk dilemma. Everyone wants to be treated as a leaf (top of the ecosystem), but free software is deeply interlinked, and you get complexity explosion as soon as you allow alternative links. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2S4AIZXIOLF3GAUMJGN664SHK3MUSKTA/
