Schedule for Thursday's FPC Meeting (2019-04-18 16:00 UTC)
Following is the list of topics that will be discussed in the FPCmeeting Thursday at 2019-04-18 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday ==2019-04-18 09:00 PDT US/Pacific2019-04-18 12:00 EDT --> US/Eastern <--2019-04-18 16:00 UTC UTC 2019- 04-18 17:00 BST Europe/London 2019-04-18 18:00 CEST Europe/Berlin 2019-04-18 18:00 CEST Europe/Paris 2019-04-18 21:30 IST Asia/Calcutta New Day: Friday - 2019-04-19 00:00 HKT Asia/Hong_Kong2019-04-19 00:00 +08 Asia/Singapore2019-04-19 01:00 JST Asia/Tokyo2019-04-19 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #382 Go Packaging Guidelines Draft.fpc 382 https://pagure.io/packaging-committee/issue/382 #topic #845 Wiki deprecation status.fpc 845 https://pagure.io/packaging-committee/issue/845 #topic #859 Scriptlet to replace a directory: try delete first? .fpc 859https://pagure.io/packaging-committee/issue/859 #topic #876 Mass Python 2 Package Removal - policies and exceptions .fpc 876https://pagure.io/packaging-committee/issue/876 = Open Floor = For more complete details, please visit each individual ticket. Thereport of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Notethat added topics may be deferred until the following meeting. ___ 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
libqalculate soname change
libqalculate soname bump is happening with update to v3.1. The following packages are affected - plasma-workspace step cantor qalculate-kde I will rebuild these in the coming days.Note that qalculate-kde is FTBFS right now. 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
review swap: ibsim
hi, https://bugzilla.redhat.com/show_bug.cgi?id=1701070 https://github.com/linux-rdma/ibsim ibsim emulates the fabric behavior by using MAD communication with the SM/SA and the PerfMgr. This simple tool is ideally suitable for various research, development, debug and testing tasks where IB subnet management is involved. I can review package wrote in C/bash as review swap. thanks ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering wrote: > > Yeah, all that stuff is stuff the kernel could do better on its > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.0.6-300.fc30.x86_64 CONFIG_HW_RANDOM_TPM=y I've got no idea if this is for TPM 1.x or 2.x or both. > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. /usr/lib/systemd/system/rngd.service contains WantedBy=multi-user.target I'm gonna guess Steve Grubb is wondering whether it could be wanted by an earlier target, possibly cryptsetup-pre.target? I don't see a service file in the upstream project so this may have been selected by the Fedora packager as a known to work option. -- Chris Murphy ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 16, 2019 at 09:06:02AM -0700, Adam Williamson wrote: > On Tue, 2019-04-16 at 11:48 -0400, Matthias Clasen wrote: > > On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering > > wrote: > > > > > Heya, > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > crashed five times or so on me, always kicking me out of anaconda > > > again, just because I wanted to undo something). But I don't really > > > want to discuss that. What I do want to discuss is this: > > > > > > > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > > the first two at least on the systems which do not need them). But if > > > that's not in the cards, it would be great to at least not enable > > > these services anymore in the default boot so that they are only a > > > "systemctl enable" away for people who need them? > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a nice > > highlevel goal to shoot for. > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > time when I reboot and something like rngd or conmon holds up my reboot > > for several minutes for no reason at all. > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > more urgent fires keep showing up :/ I opened a bug a while back, but it hasn't cropped up since I enabled additional logging: https://bugzilla.redhat.com/show_bug.cgi?id=1690364 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 17 Apr 2019 15:14:54 -0400 Steve Grubb wrote: > Ah...the devil is in the details. It does not credit entropy. This > can easily be tested. systemctl stop rngd. Then open 2 terminal > windows. In one terminal start this shell script: > > #!/bin/sh > > while [ 1 ] > do > /bin/cat /proc/sys/kernel/random/entropy_avail > sleep 1 > done > > Then in another: > > cat /dev/random >/dev/null > > After a couple seconds, hit ctl-c to kill cat. Watch what happens to > the entropy. > > I have a Kabylake system idling. It takes 3 minutes for entropy to > get back to 3k after stopping the consumer. At that point its losing > about as much as its gaining. If I start rngd and do the same test, > my entropy bounces back to over 3k in less than a second. As it > stands today, rngd has a dramatic effect on entropy. I run a daemon that harvests entropy from the atmosphere via an rtl2832 and feeds it into the kernel via /dev/random. And, yes it makes a big difference to feed the entropy pool. When random.c was rewritten to use chacha instead of the modified mersenne twister (4.xx?), the way entropy was used changed. It used to bleed constantly across from the pool that is /dev/random into /dev/urandom when it was above the threshold set in write_wakeup_threshold. Now, it only checks when the kernel routine for get_random is called and reseeds if enough entropy is present. It always has decremented and still decrements entropy available when it uses some. Under mersenne it used to be possible to set a timer as well, but that went away with chacha. I patch to enable that feature in the new random.c, so I can reseed the chacha on a periodic interval. The rationale for chacha was that server farms were starving for entropy, and it is considered more robust for low entropy conditions, at least that is what I understand from my reading. As far as the CPU hardware entropy generators, those are not open source, so it is not possible to determine if they have a backdoor. Research has shown, however, that if any true entropy is fed into a stream with compromised entropy, it results in a stream with better entropy. That is, a system using a compromised hardware generator will have more robust entropy when combined with other sources of entropy. The kernel does this via a hash to smear the mix. An attacker can no longer utilize an attack knowing the bits came from the compromised generator. Things like the bit bubbler are reasonably cheap (~100 dollars US) and provide enough entropy for a small server farm. Even the rtl2832 (~10 dollars US) provides about 90 Kbytes of entropy per second (the kernel entropy pool is 4kB). Not enough for monte carlo simulations, but plenty for a home system or a few servers. ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 15:14 -0400, Steve Grubb wrote: > Many have tried to convince upstream about this. If anyone here has > influence, > please try. If upstream is currently resistant, what about turning rngd into a loadable kernel module and then insure it is in the initramfs and loaded at kernel boot time ? Would this be a way to show upstream that this works and perhaps allow inclusion later on ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Stewardship SIG packages looking for permanent maintainer(s)
Hi everybody,
The initial fallout of the recent mass-orphanings has been dealt with,
and almost no packages should still have broken dependencies.
At this point, we'd like to start distributing some packages we took
to maintainers whose packages actively (and directly) depend on things
we maintain.
The list of packages that are "leaf packages" as far as the
Stewardship SIG is concerned, is:
- apache-commons-discovery
- json_simple
- nodejs-array-union
- nodejs-arrify
- nodejs-set-immediate-shim
Owners of directly dependent packages have been added to CC. Please
consider adopting some of these packages, otherwise they'll probably
end up orphaned and/or retired in the forseeable future. To claim a
package, simply submit a ticket with us, and we will gladly give the
package a new home.
See: https://www.pagure.io/stewardship-sig/new_issue
("package_adoption_request" template)
At the end of this E-Mail, all packages that directly depend on our
"leaf packages" are listed.
A more detailed report with complete dependency information can be viewed at:
https://decathorpe.fedorapeople.org/stewardship-sig.html
Thanks,
Fabio - for the Stewardship SIG
# Reverse package dependencies
apache-commons-discovery:
- eclipse-webtools
- jenkins
- stapler
- mx4j
json_simple:
- azureus
- cassandra
- eclipse-webtools
- hadoop
- jts
- ldaptive
- tika
- derby
- zookeeper
nodejs-array-union:
- nodejs-globby
- nodejs-multimatch
nodejs-arrify:
- nodejs-globby
- nodejs-load-grunt-tasks
- nodejs-minimist-options
- nodejs-multimatch
- nodejs-test-exclude
nodejs-set-immediate-shim:
- nodejs-each-async
- nodejs-readdirp
___
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 30 Final blocker status email #2
Final freeze begins on Tuesday, 16 April. Fedora 30 release is currently scheduled for 30 April. Action summary Accepted blockers - 1. https://bugzilla.redhat.com/show_bug.cgi?id=1683197 ACTION: halfline to remove problematic patch 2. https://bugzilla.redhat.com/show_bug.cgi?id=1691909 ACTION: halfline to investigate 3. https://bugzilla.redhat.com/show_bug.cgi?id=1690429 ACTION: Upstream gnome-shell developers to identify and fix issue 4. https://bugzilla.redhat.com/show_bug.cgi?id=1688462 ACTION: dnf team to implement proposed fix 6. https://bugzilla.redhat.com/show_bug.cgi?id=1666920 ACTION: systemd maintainers to merge the patch for F30 and verify if it fixes the issue Proposed blockers - 1. https://bugzilla.redhat.com/show_bug.cgi?id=1699179 ACTION: QA to verify with new compose 2. https://bugzilla.redhat.com/show_bug.cgi?id=1693409 ACTION: Further investigation of issue 3. https://bugzilla.redhat.com/show_bug.cgi?id=1698200 ACTION: lvrabec to clarify status of fix 4. https://bugzilla.redhat.com/show_bug.cgi?id=1699099 NEEDINFO: adamw ACTION: Further investigation of issue 5. https://bugzilla.redhat.com/show_bug.cgi?id=1698550 ACTION: Further investigation of issue 6. https://bugzilla.redhat.com/show_bug.cgi?id=1697591 ACTION: x11 maintainers to identify and implement a fix Bug-by-bug detail = Accepted blockers - 1. https://bugzilla.redhat.com/show_bug.cgi?id=1683197 - gdm - ASSIGNED gdm Fails to load with "nomodeset" Halfline will remove or modify a patch that causes gdm to wait for a seat to report CanGraphical. This is not yet accepted upstream and we don’t have a clear record of why this was added. 2. https://bugzilla.redhat.com/show_bug.cgi?id=1691909 - gdm - NEW GDM fallback from Wayland to X11 no longer works because it takes too long to start gnome-shell (affects 'basic graphics mode' / nomodeset, maybe other cases) The three second timeout in gdm is too short to catch gnome-shell failure. We need to figure out a more robust way of detecting failure (or kick the can down the road by extending the timeout). Halfline is going to investigate today or Monday 3. https://bugzilla.redhat.com/show_bug.cgi?id=1690429 - gnome-shell - NEW sometimes icon not showing for eg firefox in gnome-shell overview dash Problem is not Fedora-specific, it also occurs on Arch. An issue is open upstream (https://gitlab.gnome.org/GNOME/gnome-shell/issues/1053) 4. https://bugzilla.redhat.com/show_bug.cgi?id=1688462 - libdnf - NEW System upgrades involving modular content require explicit --setopt=module_platform_id to work correctly Updated fedora-release packages are pushed, which partially address the issue. The dnf maintainers have been authorized by FESCo to implement the remaining fix on F29+. 6. https://bugzilla.redhat.com/show_bug.cgi?id=1666920 - iscsi-initiator-utils - POST iSCSI installs fail to boot since systemd-240 (Fedora-Rawhide-20181222.n.1) A patch exists (https://github.com/systemd/systemd/commit/30fdb8962a) in rawhide that may fix the issue, but it is not in F30. Proposed blockers - 1. https://bugzilla.redhat.com/show_bug.cgi?id=1699179 - anaconda - ASSIGNED "Installation Source" spoke not configuring automatically When the graphical installer starts up and shows the hub, the "Installation Source" shows the following: "Error setting up base repository". This may already be fixed in a recent compose. 2. https://bugzilla.redhat.com/show_bug.cgi?id=1693409 - gdm -NEW gdm/X start fails on 'nomodeset' UEFI boot on multiple bare metal systems: "Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices" Testing done by QA team and community members shows this behavior across multiple hardware configurations. ‘nomodeset’ does not appear to work on any hardware. Further investigation is needed. 3. https://bugzilla.redhat.com/show_bug.cgi?id=1698200 - selinux-policy - NEW selinux-policy-3.14.3-27.fc30 broke systemd-modules-load.service loading (denials for modules.softdep and modules.dep.bin) selinux-policy-3.14.3-27.fc30 - seems to have broken systemd-modules-load.service. Maintainer included a commit comment, but it’s not clear if this is a fix and what the status is. 4. https://bugzilla.redhat.com/show_bug.cgi?id=1699099 - selinux-policy - NEW gnome-initial-setup 3.32.0+ crashes due to SELinux denials GNOME 3.32.0 triggers SELinux denials when gnome-initial-setup tries to execute /etc/ld.so.cache and /usr/lib/locale/locale-archive. It’s not yet clear why this is happening. 5. https://bugzilla.redhat.com/show_bug.cgi?id=1698550 - shim - NEW Fedora install media error out with SecureBoot or Grub error in UEFI-only mode on T450s With the latest firmware, booting fails with SecureBoot and CSM off. 6. https://bugzilla.redhat.com/show_bug.cgi?id=1697591 - xorg-x11-server - NEW modesetting driver on some Intel hardware fails to start after kernel 4.20.13 update
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote: > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > > What's the story anyway for rngd? Why would userspace be better at > > > providing entropy to the kernel than the kernel itself? Why do we > > > enable it on desktops at all, such systems should not be > > > entropy-starved. Do we need this at all now that the kernel can use > > > RDRAND itself? > > > > The kernel uses RDRAND/SEED but it does not increment the entropy > > estimate based on it. Another interesting thing is that TPM chips also > > have entropy > > That's not true anymore. There's a kernel compile time option now for > that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets > that since a while. Ah...the devil is in the details. It does not credit entropy. This can easily be tested. systemctl stop rngd. Then open 2 terminal windows. In one terminal start this shell script: #!/bin/sh while [ 1 ] do /bin/cat /proc/sys/kernel/random/entropy_avail sleep 1 done Then in another: cat /dev/random >/dev/null After a couple seconds, hit ctl-c to kill cat. Watch what happens to the entropy. I have a Kabylake system idling. It takes 3 minutes for entropy to get back to 3k after stopping the consumer. At that point its losing about as much as its gaining. If I start rngd and do the same test, my entropy bounces back to over 3k in less than a second. As it stands today, rngd has a dramatic effect on entropy. > > available, but the kernel does not use it. So, if you have a hardware > > based entropy source such as TPM, you need rngd to move the entropy to > > the kernel. And it also can mine CPU jitter to create some entropy on > > its own. And it also supports the NIST beacon if you want that kind of > > entropy. Rngd greatly helps system recover from low entropy situations. > > Yeah, all that stuff is stuff the kernel could do better on its > own. Many have tried to convince upstream about this. If anyone here has influence, please try. > If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? I agree. :-) > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. And credit entropy! > > > rngd runs as regular system service, hence what's the point of that > > > altogether? I mean, it runs so late during boot, at a point where the > > > entropy pool is full anyway, > > > > I'd really like to see it start much earlier. Any way to make that > > happen? > > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. > > > > RNG, and it does that super early). So, why run a service that is > > > supposed to fill up the entropy pool at a point where we don't need it > > > anymore, and if the kernel can do what it does most likely already on > > > its own? > > > > The kernel cannot recover quickly when stressed for continued entropy > > depletion. For example, we are required to be able to supply all guest > > VM's with entropy from the host. They draw down the entropy pools which > > need replenishment. The kernel is constantly starved for entropy. > > That's not how the entropy pool works. Once it is full it's full, and > it doesn't run empty anymore. Empirical evidence suggests otherwise. See the test above. > > I think you're being harsh without really looking deeply into the > > problem. If we could set a sysctl to tell the kernel to use a TPM or > > increment entropy estimate when RDSEED is used, I'd agree we should > > consider this. And to be > > OK, so I guess that point in time is now. Though it's not a sysctl, > but a compile time option (see above). It looks as though it may be controlled as a boot commandline option, too. But that is likely intended to disable the effect it has. -Steve ___ 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: Updating/rebuilding of coin-or packages
> "AT" == Antonio Trande writes: AT> Is it correct tagging an absolute path with %doc? Yes, it's fine; that just sets the flag that tells RPM "this file/directory contains documentation". That's not really any different than, say, using %config to set the "this is a configuration file" flag. It's when you use %doc on a relative path that the magic bit of copying things from %_builddir into %buildroot/%_docdir occurs. - J< ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On 4/17/2019 10:36 AM, Lennart Poettering wrote: On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: rngd runs as regular system service, hence what's the point of that altogether? I mean, it runs so late during boot, at a point where the entropy pool is full anyway, I'd really like to see it start much earlier. Any way to make that happen? Well, no. I mean, the only way you can do that is by turning rngd into its own init system, if you want it to run before the init system. This seems like a false dichotomy, no? Surely, things like this are a possibility: https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html But beyond that, is there really no way to lift this earlier in the boot logic? -jc ___ 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: Sphinx and xindy
> "JJ" == Jerry James writes:
JJ> Somebody out there has been involved with past attempts to build
JJ> xindy. Please, I would like to make progress on this so I can get
JJ> back to building the coq stack's new versions. Which package used
JJ> to contain xindy?
It is/was part of texlive-base. Look at line 20 of the texlive-base
spec:
# Not ppc64, not s390x, not aarch64 due to lack of clisp
# code SIGSEGV's on armv7hl
%global xindy_arches empty
JJ> How does one attempt to build it?
Just set that define appropriately. It was disabled in
ac0adc86c6ee1f2559e4313f210b828778388999 because I guess there's some
sort of circular build dependency and I guess it never got turned back
on again. Before that it was set to:
%global xindy_arches %{ix86} x86_64
And before acf14dee9c90d6f8b775adc0c1c5151d7df28642 that included arm:
%global xindy_arches %{arm} %{ix86} x86_64
To go back further you have to go back to the texlive package before
-base was split out.
My suggestion? Package it as an entirely separate package to avoid any
kind of circular build dependency. Call it xindy or texlive-xindy; I've
no preference.
- J<
___
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
Bigger packages (Was: Re: Fedora rawhide compose report: 20190417.n.0 changes)
On Wed, 17 Apr 2019 at 17:00, Fedora Rawhide Report < rawh...@fedoraproject.org> wrote: [..] > Package: at-spi2-core-2.32.1-2.fc31 > Old package: at-spi2-core-2.32.1-1.fc30 > Summary: Protocol definitions and daemon for D-Bus at-spi > RPMs: at-spi2-core at-spi2-core-devel > Size: 1.77 MiB > Size change: 42.01 KiB > Changelog: > * Tue Apr 16 2019 Adam Williamson - 2.32.1-2 > - Rebuild with Meson fix for #1699099 > > > Package: atomix-3.32.1-2.fc31 > Old package: atomix-3.32.1-1.fc30 > Summary: Puzzle game: Build molecules out of isolated atoms > RPMs: atomix > Size: 2.85 MiB > Size change: 20.33 KiB > Changelog: > * Tue Apr 16 2019 Adam Williamson - 3.32.1-2 > - Rebuild with Meson fix for #1699099 > I'm not sure did anyone noticed that but despite fact that fixing #1699099 should introduce relatively small change each rebuild recently introduces bigger packages. I'm still investigating this but looks like that change (ELF files length increase) is not related to the meson or #1699099 but to binutils. Tomasz -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Can we maybe reduce the set of packages we install by default a bit?
> "LP" == Lennart Poettering writes: LP> That's not true anymore. There's a kernel compile time option now LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel LP> sets that since a while. Isn't this arch-dependent? config RANDOM_TRUST_CPU bool "Trust the CPU manufacturer to initialize Linux's CRNG" depends on X86 || S390 || PPC default n Not sure what happens on ARM but I think it would need to be considered. - J< ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 19:36 +0200, Lennart Poettering wrote: > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > > nice > > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > > single > > > > > time when I reboot and something like rngd or conmon holds up my > > > > > reboot > > > > > for several minutes for no reason at all. > > > > > > > > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > > more urgent fires keep showing up :/ > > > > > > What's the story anyway for rngd? Why would userspace be better at > > > providing entropy to the kernel than the kernel itself? Why do we > > > enable it on desktops at all, such systems should not be > > > entropy-starved. Do we need this at all now that the kernel can use > > > RDRAND itself? > > > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > > based on it. Another interesting thing is that TPM chips also have > > entropy > > That's not true anymore. There's a kernel compile time option now for > that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets > that since a while. > > > available, but the kernel does not use it. So, if you have a hardware based > > entropy source such as TPM, you need rngd to move the entropy to the kernel. > > And it also can mine CPU jitter to create some entropy on its own. And it > > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > > helps system recover from low entropy situations. > > Yeah, all that stuff is stuff the kernel could do better on its > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why > not add that to the kernel natively, why involve userspace with that? > i.e. if the TPM and the CPU jitter stuff can be trusted, then the same > thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random > data into the pool directly inside in the kernel. Big +1, I've been saying this for ages as well ... > > > rngd runs as regular system service, hence what's the point of that > > > altogether? I mean, it runs so late during boot, at a point where the > > > entropy pool is full anyway, > > > > I'd really like to see it start much earlier. Any way to make that > > happen? > > Well, no. I mean, the only way you can do that is by turning rngd into > its own init system, if you want it to run before the init > system. > > > > RNG, and it does that super early). So, why run a service that is supposed > > > to fill up the entropy pool at a point where we don't need it anymore, and > > > if the kernel can do what it does most likely already on its own? > > > > The kernel cannot recover quickly when stressed for continued entropy > > depletion. For example, we are required to be able to supply all guest VM's > > with entropy from the host. They draw down the entropy pools which need > > replenishment. The kernel is constantly starved for entropy. > > That's not how the entropy pool works. Once it is full it's full, and > it doesn't run empty anymore. > > > I think you're being harsh without really looking deeply into the problem. > > If > > we could set a sysctl to tell the kernel to use a TPM or increment entropy > > estimate when RDSEED is used, I'd agree we should consider this. And > > to be > > OK, so I guess that point in time is now. Though it's not a sysctl, > but a compile time option (see above). I concur, I would really like to see rngd become a thing of the past as well. The kernel has all the tools and access needed to reseed itself, *requiring* a racy userspace tool to do the kernel's job is a bit ridiculous. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote: > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > nice > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > single > > > > time when I reboot and something like rngd or conmon holds up my > > > > reboot > > > > for several minutes for no reason at all. > > > > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > more urgent fires keep showing up :/ > > > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. Do we need this at all now that the kernel can use > > RDRAND itself? > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > based on it. Another interesting thing is that TPM chips also have > entropy That's not true anymore. There's a kernel compile time option now for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets that since a while. > available, but the kernel does not use it. So, if you have a hardware based > entropy source such as TPM, you need rngd to move the entropy to the kernel. > And it also can mine CPU jitter to create some entropy on its own. And it > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > helps system recover from low entropy situations. Yeah, all that stuff is stuff the kernel could do better on its own. If the CPU jitter stuff or the TPM stuff is a good idea, then why not add that to the kernel natively, why involve userspace with that? i.e. if the TPM and the CPU jitter stuff can be trusted, then the same thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random data into the pool directly inside in the kernel. > > rngd runs as regular system service, hence what's the point of that > > altogether? I mean, it runs so late during boot, at a point where the > > entropy pool is full anyway, > > I'd really like to see it start much earlier. Any way to make that > happen? Well, no. I mean, the only way you can do that is by turning rngd into its own init system, if you want it to run before the init system. > > RNG, and it does that super early). So, why run a service that is supposed > > to fill up the entropy pool at a point where we don't need it anymore, and > > if the kernel can do what it does most likely already on its own? > > The kernel cannot recover quickly when stressed for continued entropy > depletion. For example, we are required to be able to supply all guest VM's > with entropy from the host. They draw down the entropy pools which need > replenishment. The kernel is constantly starved for entropy. That's not how the entropy pool works. Once it is full it's full, and it doesn't run empty anymore. > I think you're being harsh without really looking deeply into the problem. If > we could set a sysctl to tell the kernel to use a TPM or increment entropy > estimate when RDSEED is used, I'd agree we should consider this. And > to be OK, so I guess that point in time is now. Though it's not a sysctl, but a compile time option (see above). 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
Re: Python 3.7 setuptools
On Wed, 2019-04-17 at 17:54 +0100, Luke Hinds wrote: > On Wed, Apr 17, 2019 at 5:34 PM Luke Hinds wrote: > > > Apologies if not the correct, list , I was not sure if I should post here > > or to python-devel > > > > I would like to use setuptools within a python3.7 project. > > > > I install ptyhon3.7 using dnf > > > > I then install python3-setuptools > > > > Using python3.7 I get an import error: > > > > # python3.7 > > Python 3.7.2 (default, Jan 19 2019, 10:24:44) > > [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > > > > import setuptools > > Traceback (most recent call last): > > File "", line 1, in > > ModuleNotFoundError: No module named 'setuptools' > > > > It works for 3.6 > > > > # python3 > > Python 3.6.5 (default, Mar 29 2018, 18:20:46) > > [GCC 8.0.1 20180317 (Red Hat 8.0.1-0.19)] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > > > > import setuptools > > > > > > > > > This is expected, as set up tools resides in > > `/usr/lib/python3.6/site-packages/setuptools` > > > > What would be the tidy / recommended way of using a module for 3.7 with > > dnf managing the packages (rather than pip / virtual-envs). > > > > > > > To answer myself, I omitted to state I was using Fedora 29. > > Fedora 30 resolves this for me, as 3.7 is the default. > > I would still however, be interested in what the recommended approach is > for users on Fedora 29. There kind of isn't one. The alternative-versioned Python interpreter packages exist for specific purposes like doing CI; we don't ship a complete library environment for those versions. Whatever you're doing with them is actually expected to get libraries and stuff some other way...probably pip and virtualenvs. :P This is AIUI, anyway. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Python 3.7 setuptools
On Wed, Apr 17, 2019 at 5:34 PM Luke Hinds wrote: > Apologies if not the correct, list , I was not sure if I should post here > or to python-devel > > I would like to use setuptools within a python3.7 project. > > I install ptyhon3.7 using dnf > > I then install python3-setuptools > > Using python3.7 I get an import error: > > # python3.7 > Python 3.7.2 (default, Jan 19 2019, 10:24:44) > [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import setuptools > Traceback (most recent call last): > File "", line 1, in > ModuleNotFoundError: No module named 'setuptools' > > It works for 3.6 > > # python3 > Python 3.6.5 (default, Mar 29 2018, 18:20:46) > [GCC 8.0.1 20180317 (Red Hat 8.0.1-0.19)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import setuptools > >>> > > This is expected, as set up tools resides in > `/usr/lib/python3.6/site-packages/setuptools` > > What would be the tidy / recommended way of using a module for 3.7 with > dnf managing the packages (rather than pip / virtual-envs). > > > To answer myself, I omitted to state I was using Fedora 29. Fedora 30 resolves this for me, as 3.7 is the default. I would still however, be interested in what the recommended approach is for users on Fedora 29. ___ 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-20190417.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 7 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 23/146 (x86_64), 6/24 (i386), 1/2 (arm) ID: 385915 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/385915 ID: 385918 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/385918 ID: 385920 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/385920 ID: 385922 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/385922 ID: 385924 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/385924 ID: 385925 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/385925 ID: 385927 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/385927 ID: 385929 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/385929 ID: 385938 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/385938 ID: 385940 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/385940 ID: 385944 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/385944 ID: 385947 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/385947 ID: 385948 Test: x86_64 Workstation-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/385948 ID: 385949 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/385949 ID: 385950 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/385950 ID: 385951 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/385951 ID: 385953 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/385953 ID: 385954 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/385954 ID: 385967 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/385967 ID: 385970 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/385970 ID: 385993 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/385993 ID: 385994 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/385994 ID: 386005 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/386005 ID: 386009 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/386009 ID: 386010 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/386010 ID: 386049 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/386049 ID: 386055 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/386055 ID: 386056 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/386056 ID: 386057 Test: i386 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/386057 ID: 386067 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/386067 Soft failed openQA tests: 2/24 (i386), 4/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 385930 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/385930 ID: 385931 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/385931 ID: 385990 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/385990 ID: 385992 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/385992 ID: 386029 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/386029 ID: 386050 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/386050 Passed openQA tests: 119/146 (x86_64), 16/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org T
Python 3.7 setuptools
Apologies if not the correct, list , I was not sure if I should post here or to python-devel I would like to use setuptools within a python3.7 project. I install ptyhon3.7 using dnf I then install python3-setuptools Using python3.7 I get an import error: # python3.7 Python 3.7.2 (default, Jan 19 2019, 10:24:44) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import setuptools Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'setuptools' It works for 3.6 # python3 Python 3.6.5 (default, Mar 29 2018, 18:20:46) [GCC 8.0.1 20180317 (Red Hat 8.0.1-0.19)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import setuptools >>> This is expected, as set up tools resides in `/usr/lib/python3.6/site-packages/setuptools` What would be the tidy / recommended way of using a module for 3.7 with dnf managing the packages (rather than pip / virtual-envs). ___ 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: openmpi breakage on Rawhide
Am Mittwoch, den 17.04.2019, 18:09 +0200 schrieb Björn 'besser82' Esser: > Am Mittwoch, den 17.04.2019, 09:59 -0600 schrieb Christoph Junghans: > > I think a rebuild will fix the problem: > > https://src.fedoraproject.org/rpms/openmpi/pull-request/5 > > > > On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans < > > jungh...@votca.org > > > wrote: > > > Hi all, > > > > > > Some of my packages failed to build due to a openmpi breakage > > > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > > DEBUG util.py:554: BUILDSTDERR: Problem: package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers > > > can > > > be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none > > > of > > > the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, > > > but > > > none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 > > Merged and building. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=34241927 Unfortunately the build failed on S390X arch for some infrastructural reason. I've resubmitted the task: https://koji.fedoraproject.org/koji/taskinfo?taskID=34242038 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: openmpi breakage on Rawhide
Am Mittwoch, den 17.04.2019, 09:59 -0600 schrieb Christoph Junghans: > I think a rebuild will fix the problem: > https://src.fedoraproject.org/rpms/openmpi/pull-request/5 > > On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans > wrote: > > Hi all, > > > > Some of my packages failed to build due to a openmpi breakage > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > DEBUG util.py:554: BUILDSTDERR: Problem: package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can > > be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the > > providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > > providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of > > the providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the > > providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, > > but > > none of the providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 Merged and building. https://koji.fedoraproject.org/koji/taskinfo?taskID=34241927 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: openmpi breakage on Rawhide
I think a rebuild will fix the problem: https://src.fedoraproject.org/rpms/openmpi/pull-request/5 On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans wrote: > > Hi all, > > Some of my packages failed to build due to a openmpi breakage > > DEBUG util.py:554: BUILDSTDERR: Error: > DEBUG util.py:554: BUILDSTDERR: Problem: package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can > be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > providers can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of > the providers can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, but > none of the providers can be installed > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > DEBUG util.py:554: BUILDSTDERR: - nothing provides > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 > > Christoph > > -- > Christoph Junghans > Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ 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
openmpi breakage on Rawhide
Hi all, Some of my packages failed to build due to a openmpi breakage DEBUG util.py:554: BUILDSTDERR: Error: DEBUG util.py:554: BUILDSTDERR: Problem: package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - conflicting requests DEBUG util.py:554: BUILDSTDERR: - nothing provides libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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: 20190417.n.0 changes
OLD: Fedora-Rawhide-20190416.n.0 NEW: Fedora-Rawhide-20190417.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 47 Dropped packages:1 Upgraded packages: 227 Downgraded packages: 0 Size of added packages: 27.83 MiB Size of dropped packages:24.88 KiB Size of upgraded packages: 5.10 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -81.34 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190417.n.0-sda.raw.xz = DROPPED IMAGES = Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190416.n.0-sda.raw.xz = ADDED PACKAGES = Package: aopalliance-1.0-17.module_f28+3939+dc18cd75 Summary: Java/J2EE AOP standards RPMs:aopalliance Size:16.06 KiB Package: apache-commons-cli-1.4-4.module_f28+3939+dc18cd75 Summary: Command Line Interface Library for Java RPMs:apache-commons-cli Size:72.81 KiB Package: apache-commons-codec-1.11-3.module_f28+3939+dc18cd75 Summary: Implementations of common encoders and decoders RPMs:apache-commons-codec Size:287.44 KiB Package: apache-commons-io-1:2.6-3.module_f28+3939+dc18cd75 Summary: Utilities to assist with developing IO functionality RPMs:apache-commons-io Size:222.54 KiB Package: apache-commons-lang3-3.7-3.module_f28+3939+dc18cd75 Summary: Provides a host of helper utilities for the java.lang API RPMs:apache-commons-lang3 Size:481.69 KiB Package: apache-commons-logging-1.2-13.module_f28+3939+dc18cd75 Summary: Apache Commons Logging RPMs:apache-commons-logging Size:84.02 KiB Package: atinject-1-28.20100611svn86.module_f28+3939+dc18cd75 Summary: Dependency injection specification for Java (JSR-330) RPMs:atinject Size:19.03 KiB Package: cdi-api-1.2-8.module_f28+3939+dc18cd75 Summary: CDI API RPMs:cdi-api Size:68.52 KiB Package: geronimo-annotation-1.0-23.module_f28+3939+dc18cd75 Summary: Java EE: Annotation API v1.3 RPMs:geronimo-annotation Size:24.16 KiB Package: glassfish-el-3.0.1-0.7.b08.module_f28+3939+dc18cd75 Summary: J2EE Expression Language Implementation RPMs:glassfish-el-api Size:103.92 KiB Package: google-guice-4.1-11.module_f28+3939+dc18cd75 Summary: Lightweight dependency injection framework for Java 5 and above RPMs:google-guice Size:469.03 KiB Package: guava20-20.0-8.module_f28+3939+dc18cd75 Summary: Google Core Libraries for Java RPMs:guava20 Size:2.06 MiB Package: hawtjni-1.16-2.module_f28+3939+dc18cd75 Summary: Code generator that produces the JNI code RPMs:hawtjni-runtime Size:41.92 KiB Package: httpcomponents-client-4.5.5-4.module_f28+3939+dc18cd75 Summary: HTTP agent implementation based on httpcomponents HttpCore RPMs:httpcomponents-client httpcomponents-client-cache Size:868.07 KiB Package: httpcomponents-core-4.4.10-3.module_f28+3939+dc18cd75 Summary: Set of low level Java HTTP transport components for HTTP services RPMs:httpcomponents-core Size:636.32 KiB Package: jansi-1.17.1-1.module_f28+3939+dc18cd75 Summary: Jansi is a java library for generating and interpreting ANSI escape sequences RPMs:jansi Size:77.76 KiB Package: jansi-native-1.7-7.module_f28+3939+dc18cd75 Summary: Jansi Native implements the JNI Libraries used by the Jansi project RPMs:jansi-native Size:438.54 KiB Package: jboss-interceptors-1.2-api-1.0.0-8.module_f28+3939+dc18cd75 Summary: Java EE Interceptors 1.2 API RPMs:jboss-interceptors-1.2-api Size:32.13 KiB Package: jsoup-1.11.3-3.module_f28+3939+dc18cd75 Summary: Java library for working with real-world HTML RPMs:jsoup Size:384.86 KiB Package: kiwix-lib-4.1.0-1.fc31 Summary: Common code base for all Kiwix ports RPMs:kiwix-lib kiwix-lib-devel Size:1.13 MiB Package: lua-basexx-0.4.0-2.fc31 Summary: BaseXX encoding and decoding library for Lua RPMs:lua-basexx lua5.1-basexx Size:22.38 KiB Package: lua-binaryheap-0.4-1.fc31 Summary: Binary heap implementation for Lua RPMs:lua-binaryheap lua5.1-binaryheap Size:31.24 KiB Package: lua-bitop-1.0.2-4.fc31 Summary: C extension module for Lua which adds bit-wise operations on numbers RPMs:lua5.1-bitop Size:71.92 KiB Package: lua-compat53-0.7-1.fc31 Summary: Compatibility module providing Lua-5.3-style APIs for Lua 5.1 RPMs:lua5.1-compat53 Size:220.90 KiB Package: lua-fifo-0.2-1.fc31 Summary: FIFO library for Lua RPMs:lua-fifo lua5.1-fifo Size:19.65 KiB Package: lua-lpeg-patterns-0.5-1.fc31 Summary: A collection of LPEG patterns RPMs:lua-lpeg-patterns lua5.1-lpeg-patterns Size:46.29 KiB Package: lua-luaossl-20181207-1.fc31 Summary: Most comprehensive OpenSSL module in the Lua universe RPMs:lua-luaossl lua-luaossl-doc lua5.1-luaossl Size:1.15 MiB Package: lua-mmdb-0.2-1.fc31 Summary: MaxMind database parser for Lua
Re: fedora-img-dl: a tool for downloading Fedora iso's and images
On Wed, 2019-04-17 at 08:56 +0100, Richard W.M. Jones wrote: > There are some sites which let you PXE boot Linux distros over the > internet (https://netboot.xyz/ being the most notable). Surely the most notable for Fedora is https://boot.fedoraproject.org/ ? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Can we maybe reduce the set of packages we install by default a bit?
On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > nice > > > highlevel goal to shoot for. > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > single > > > time when I reboot and something like rngd or conmon holds up my > > > reboot > > > for several minutes for no reason at all. > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > more urgent fires keep showing up :/ > > What's the story anyway for rngd? Why would userspace be better at > providing entropy to the kernel than the kernel itself? Why do we > enable it on desktops at all, such systems should not be > entropy-starved. Do we need this at all now that the kernel can use > RDRAND itself? The kernel uses RDRAND/SEED but it does not increment the entropy estimate based on it. Another interesting thing is that TPM chips also have entropy available, but the kernel does not use it. So, if you have a hardware based entropy source such as TPM, you need rngd to move the entropy to the kernel. And it also can mine CPU jitter to create some entropy on its own. And it also supports the NIST beacon if you want that kind of entropy. Rngd greatly helps system recover from low entropy situations. > rngd runs as regular system service, hence what's the point of that > altogether? I mean, it runs so late during boot, at a point where the > entropy pool is full anyway, I'd really like to see it start much earlier. Any way to make that happen? > and we need the kernel's RNG much much earlier already (already because > systemd assigns a uuid to each service invocation that derives from kernel > RNG, and it does that super early). So, why run a service that is supposed > to fill up the entropy pool at a point where we don't need it anymore, and > if the kernel can do what it does most likely already on its own? The kernel cannot recover quickly when stressed for continued entropy depletion. For example, we are required to be able to supply all guest VM's with entropy from the host. They draw down the entropy pools which need replenishment. The kernel is constantly starved for entropy. > Isn't it time to kick rngd out of the default install, in particular > on the workstation image? Isn't keeping it around just cargo culting? I think you're being harsh without really looking deeply into the problem. If we could set a sysctl to tell the kernel to use a TPM or increment entropy estimate when RDSEED is used, I'd agree we should consider this. And to be honest, it should be running during an anaconda or kickstart install in order to safely setup an encrypted disk. Also, livecd uses are starved for entropy and must use rngd to be responsive and safe. If you have a TPM, the best use you'll get out of it is providing random numbers via rngd. :-) -Steve ___ 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
fedmsg is deprecated - Fedora infrastructure messages now available via AMQP
Hello folks, Over the last several months, Fedora Infrastructure has been working towards migrating away from fedmsg (ZeroMQ, on which it is based). As of last week, the Fedora AMQP message broker is available outside the infrastructure network. If you're currently consuming the ZeroMQ messages published by Fedora via fedmsg or any other ZeroMQ client, please look into migrating to AMQP as the ZeroMQ endpoint will eventually be shut down. Until that occurs, all messages are available via both AMQP and ZeroMQ. For folks using Python, a fedmsg replacement library and command-line interface have been written called "fedora-messaging". This package is available on PyPI, in Fedora 29+, and is also available in the Fedora Infrastructure repositories for EPEL7 and Fedora 28. Library and CLI documentation is available online[0]. Documentation specifically for consuming messages from the public AMQP broker is available at https://fedora-messaging.readthedocs.io/en/stable/fedora-broker.html If you are *not* using Python, or if re-inventing wheels is something you enjoy, you can receive these messages using the AMQP client library of your choice: https://www.rabbitmq.com/devtools.html has a number of clients in various languages listed. This is a new service and library, so there are bound to be a few hiccups along the way. Please report any issues you encounter with the broker on the infrastructure list, and any issues with the library or the documentation on the issue tracker[1] (or the infrastructure list if you don't have a GitHub account) and we'll make sure they're addressed as soon as possible. [0] https://fedora-messaging.readthedocs.io/en/stable/index.html [1] https://github.com/fedora-infra/fedora-messaging/issues Regards, Jeremy ___ 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: Module's package branch name to be aligned?
I think the rules for module branches should be stricter. After several
back and forth in discussions with Jun about stream branches for Ruby, I
believe that the concept of "using upstream major versions as branches"
[1] is not enough and can work just for the simplest cases.
We should use ${module}-${stream} branches everywhere (the "stream-"
prefix would be useful as well, because it would explain the semantics
use after the prefix).
For example, if we have "foo" module with "1.0" and "2.0" streams and it
ships "bar" and "baz" components, the components should have appropriate
"(stream-)foo-1.0" and "(stream-)foo-2.0" branches.
We could also utilize `git symbolic-ref` to link the branches if needed
Vít
Dne 16. 04. 19 v 15:25 Jun Aruga napsal(a):
> Hi,
>
> I like to see "package branch name" of each modules to be aligned more.
>
> Here is a list of the current module, the module stream name, the
> package branch name, another package name. There are some patterns on
> the list.
>
> # module, the module stream name (module/foo's branch), the package
> branch name (rpms/foo's branch), another package name (rpms/bar's
> branch)
> mongodb3.6 3.6 None
> nodejs8 8 None
> perl5.24 fXX fXX
> python3 3.6 None None
> python36 3.6 None master
> ruby 2.5 ruby-2.5 master
> scala 2.10 javapackages javapackages
> varnish 6 stream-6 stream-6
>
> See more detail at https://pagure.io/jaruga-modules-branches
> I think "None" is same with "master" technically.
>
> In case of modules/ruby, we ruby team decided "the package branch
> name" as "ruby-X.Y" with a module name prefix against "X.Y" documented
> in the naming guideline.
> Because a package of a module A (ex. modules/ruby) can be used also in
> a module B (ex. modules/rubygem-rails, modules/vagrant and etc.
> In this case, a package branch name needs to have "ruby-X.Y",
> "rubygem-rails-X.Y", "vargrant-X.Y".
>
> Do you like to see some alignments for the naming?
> Hopefully after the discussion here in this thread, below page will be
> updated.
> https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_package_branch_name
>
> Regards,
> Jun
> ___
> 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: fedora-img-dl: a tool for downloading Fedora iso's and images
On Mon, Apr 15, 2019 at 5:55 PM Dan Čermák wrote: > cool project! I see a certain overlap with fedora-mediawriter though, as > that one can download ISOs too. > Okay, thanks, my own use-case is more downloading Live images for local testing. I've skimmed the sources (is this upstream: > https://github.com/juhp/fedora-img-dl?) to take a look whether you > verify the GPG signatures of the downloaded images, but couldn't find > anything like that (although I can barely read Haskell). If your tool > would do that, I'd consider that a killer feature. Okay, I implemented it yesterday in version 0.3 along with support for Spins. Available now in https://copr.fedorainfracloud.org/coprs/petersen/fedora-img-dl/. Cheers, Jens ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 17, 2019 at 10:38:18AM +0200, Lennart Poettering wrote: > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > I think all of these are good ideas. "No udev-settle" seems like a nice > > > highlevel goal to shoot for. > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > > time when I reboot and something like rngd or conmon holds up my reboot > > > for several minutes for no reason at all. > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > more urgent fires keep showing up :/ > > What's the story anyway for rngd? Why would userspace be better at > providing entropy to the kernel than the kernel itself? Why do we > enable it on desktops at all, such systems should not be > entropy-starved. Do we need this at all now that the kernel can use > RDRAND itself? IIUC, RDRAND exists from IvyBridge generation CPUs onwards for Intel or EPYC CPUs for AMD. I've no idea what the story is for non-x86 CPUs & RDRAND equivalent. Anyway, whether we can rely on RDRAND depends on what we consider the minimum targetted CPU models & architectures. I'm guessing that we do intend Fedora to work correctly in CPUs predating/lacking RDRAND. KVM guests can have a virtio-rng device provided on any architecture, which feeds from host's /dev/urandom, but it is unfortunately fairly rare for public cloud providers to enable it :-( rngd includes support for the "jitter entropy" source which uses CPU jitter to feed the RNG. At least in RHEL, this is the recommended option when the CPUs lack RDRAND or equivalent and is why rngd is enabled by default there. IIUC it is reading the jitter entropy from the kernel's crypto APIs, optionally applying AES to data, and then feeding it back into the kernel's rng pool. > rngd runs as regular system service, hence what's the point of that > altogether? I mean, it runs so late during boot, at a point where the > entropy pool is full anyway, and we need the kernel's RNG much much > earlier already (already because systemd assigns a uuid to each > service invocation that derives from kernel RNG, and it does that > super early). So, why run a service that is supposed to fill up the > entropy pool at a point where we don't need it anymore, and if the > kernel can do what it does most likely already on its own? /dev/random can get depleted after boot. Though modern recommendation is for apps to use /dev/urandom by default (or getrandom/getentropy syscalls), some probably still uses /dev/random for historical baggage reasons. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > I think all of these are good ideas. "No udev-settle" seems like a nice > > highlevel goal to shoot for. > > > > Another one I might add: "No stuck stop jobs" - it annoys me every single > > time when I reboot and something like rngd or conmon holds up my reboot > > for several minutes for no reason at all. > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > more urgent fires keep showing up :/ What's the story anyway for rngd? Why would userspace be better at providing entropy to the kernel than the kernel itself? Why do we enable it on desktops at all, such systems should not be entropy-starved. Do we need this at all now that the kernel can use RDRAND itself? rngd runs as regular system service, hence what's the point of that altogether? I mean, it runs so late during boot, at a point where the entropy pool is full anyway, and we need the kernel's RNG much much earlier already (already because systemd assigns a uuid to each service invocation that derives from kernel RNG, and it does that super early). So, why run a service that is supposed to fill up the entropy pool at a point where we don't need it anymore, and if the kernel can do what it does most likely already on its own? Isn't it time to kick rngd out of the default install, in particular on the workstation image? Isn't keeping it around just cargo culting? 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
Re: fedora-img-dl: a tool for downloading Fedora iso's and images
On Tue, Apr 16, 2019 at 02:05:40PM -0700, Adam Williamson wrote: > On Tue, 2019-04-16 at 21:55 +0100, Richard W.M. Jones wrote: > > On Mon, Apr 15, 2019 at 09:57:26AM -0700, Adam Williamson wrote: > > > On Mon, 2019-04-15 at 17:22 +0800, Jens-Ulrik Petersen wrote: > > > > Hi, I made a small cli tool for downloading Fedora iso's etc. > > > > > > > > It can download rawhide, branched, beta, and released isos (eg > > > > Workstation > > > > Live etc), and even WS Live respins (support for spins coming later). > > > > > > > > You can try it now from < > > > > https://copr.fedorainfracloud.org/coprs/petersen/fedora-img-dl/>;;. > > > > > > > > Feedback is welcome. > > > > > > I already basically wrote this: > > > > > > https://pagure.io/fedora-qa/fedfind > > > > > > it has a lot more capabilities, and is used quite heavily in various > > > tools and processes the QA team uses. > > > > Well I can go one better here and say there's a way to *not* download > > the ISOs :-) > > > > https://rwmj.wordpress.com/2019/04/13/virt-install-nbdkit-live-install/#content > > But you still need to know where the ISO you want to use *is*, which > fedfind can help you with ;) Absolutely :-) There's also the question Chris Murphy asked on that posting about whether in fact it actually downloads the whole ISO anyway (because of the way our ISOs contain a squashfs containing an ext4 image[1]). If we did go for lazy downloading this would be an opportunity to use a format which is more attuned to this purpose. And it could also contain much more content, since it would only be downloaded on demand. There are some sites which let you PXE boot Linux distros over the internet (https://netboot.xyz/ being the most notable). I have a vision that we could do this officially for Fedora one day, so you could entirely try out Fedora without any download or local install (until you decided you want to perform the local install). Of course I have already written the nbdkit plugin for this too ... https://rwmj.wordpress.com/2019/02/19/nbdkit-linuxdisk-plugin/#content Rich. [1] https://rwmj.wordpress.com/2009/07/15/unpack-the-russian-doll-of-a-f11-live-cd/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: FF v dnf needs-restarting
On Tue, Apr 16, 2019 at 4:56 PM Bojan Smojver wrote: > I'm guessing most of you here probably observed this behaviour with dnf > when FF is upgraded. Even after FF restarted, dnf needs-restarting reports > that it needs restarting. Does that sound like a bug or is this somehow > intentional? > > I'm seeing this in f29 and previous releases are the same. Once I upgrade > to f30, I'm planning to open a bug on this if it's still the same, unless > someone tells me this is how it's supposed to work. > I see the same behavior (F29). However, "sudo tracer -ea" doesn't complain about Firefox. The question is which tool is correct. My current guess is tracer. ___ 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
