Fedora rawhide compose report: 20180620.n.0 changes
OLD: Fedora-Rawhide-20180619.n.0 NEW: Fedora-Rawhide-20180620.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 3 Dropped packages:206 Upgraded packages: 131 Downgraded packages: 0 Size of added packages: 184.35 KiB Size of dropped packages:236.93 MiB Size of upgraded packages: 2.13 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -40.44 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20180620.n.0.iso = DROPPED IMAGES = Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20180619.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20180619.n.0.iso = ADDED PACKAGES = Package: beakerlib-libraries-0.2-1.fc29 Summary: Beakerlib libraries RPMs:beakerlib-libraries Size:142.10 KiB Package: perl-Crypt-OpenSSL-Guess-0.11-1.fc29 Summary: Guess OpenSSL include path RPMs:perl-Crypt-OpenSSL-Guess Size:20.01 KiB Package: perl-Syntax-Keyword-Gather-1.003002-1.fc29 Summary: Implements the Perl 6 'gather/take' control structure in Perl 5 RPMs:perl-Syntax-Keyword-Gather Size:22.25 KiB = DROPPED PACKAGES = Package: ant-1.10.3-1.module_1645+699d05f3 Summary: Java build tool RPMs:ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-log4j ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 ant-commons-logging ant-commons-net ant-javadoc ant-javamail ant-jdepend ant-jmf ant-jsch ant-junit ant-lib ant-manual ant-swing ant-testutil ant-xz Size:11.04 MiB Package: ant-contrib-1.0-0.32.b3.module_1645+699d05f3 Summary: Collection of tasks for Ant RPMs:ant-contrib ant-contrib-javadoc Size:849.52 KiB Package: antlr-2.7.7-53.module_1618+34521b72 Summary: ANother Tool for Language Recognition RPMs:antlr-C++ antlr-javadoc antlr-manual antlr-tool Size:4.30 MiB Package: aopalliance-1.0-17.module_1618+34521b72 Summary: Java/J2EE AOP standards RPMs:aopalliance aopalliance-javadoc Size:123.88 KiB Package: apache-commons-beanutils-1.9.3-4.module_1618+34521b72 Summary: Java utility methods for accessing and modifying the properties of arbitrary JavaBeans RPMs:apache-commons-beanutils apache-commons-beanutils-javadoc Size:1014.92 KiB Package: apache-commons-cli-1.4-4.module_1645+699d05f3 Summary: Command Line Interface Library for Java RPMs:apache-commons-cli apache-commons-cli-javadoc Size:290.13 KiB Package: apache-commons-codec-1.11-3.module_1645+699d05f3 Summary: Implementations of common encoders and decoders RPMs:apache-commons-codec apache-commons-codec-javadoc Size:894.08 KiB Package: apache-commons-collections-3.2.2-7.module_1618+34521b72 Summary: Provides new interfaces, implementations and utilities for Java Collections RPMs:apache-commons-collections apache-commons-collections-javadoc apache-commons-collections-testframework Size:1.27 MiB Package: apache-commons-collections4-4.1-2.module_1618+34521b72 Summary: Extension of the Java Collections Framework RPMs:apache-commons-collections4 apache-commons-collections4-javadoc Size:2.81 MiB Package: apache-commons-compress-1.16.1-1.module_1618+34521b72 Summary: Java API for working with compressed files and archivers RPMs:apache-commons-compress apache-commons-compress-javadoc Size:2.56 MiB Package: apache-commons-configuration-1.10-11.module_1645+699d05f3 Summary: Commons Configuration Package RPMs:apache-commons-configuration Size:715.68 KiB Package: apache-commons-digester-2.1-10.module_1645+699d05f3 Summary: XML to Java object mapping module RPMs:apache-commons-digester apache-commons-digester-javadoc Size:889.62 KiB Package: apache-commons-exec-1.3-8.module_1618+34521b72 Summary: Java library to reliably execute external processes from within the JVM RPMs:apache-commons-exec apache-commons-exec-javadoc Size:289.88 KiB Package: apache-commons-io-1:2.6-3.module_1618+34521b72 Summary: Utilities to assist with developing IO functionality RPMs:apache-commons-io apache-commons-io-javadoc Size:994.96 KiB Package: apache-commons-jexl-2.1.1-20.module_1645+699d05f3 Summary: Java Expression Language (JEXL) RPMs:apache-commons-jexl apache-commons-jexl-javadoc Size:1.05 MiB Package: apache-commons-jxpath-1.3-29.module_1645+699d05f3 Summary: Simple XPath interpreter RPMs:apache-commons-jxpath apache-commons-jxpath-javadoc Size:1.22 MiB Package: apache-commons-lang-2.6-21.module_1618+34521b72 Summary: Provides a host of helper utilities for the java.lang API RPMs:apache-commons-lang apache-commons-lang-javadoc Size:1.21 MiB Package: apache-commons-lang3-3.7-3.module_1645+699d05f3 Summary: Provides a host of helper utilities for the java.lang API RPMs:apache-commons-lang3 apache
Schedule for Thursday's FPC Meeting (2018-06-21 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-06-21 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2018-06-21 09:00 PDT US/Pacific 2018-06-21 12:00 EDT --> US/Eastern <-- 2018-06-21 16:00 UTC UTC 2018- 06-21 17:00 BST Europe/London 2018-06-21 18:00 CEST Europe/Berlin 2018-06-21 18:00 CEST Europe/Paris 2018-06-21 21:30 IST Asia/Calcutta New Day: Friday - 2018-06-22 00:00 HKT Asia/Hong_Kong 201 8-06-22 00:00 +08 Asia/Singapore 2018-06-22 01:00 JST Asia/Tokyo 2018-06-22 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followups = #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 #topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config .fpc 743 https://pagure.io/packaging-committee/issue/743 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=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, or bring it up at the end of the meeting, during the open floor topic. Note that 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/message/ST6MDX2T7KNOWPO2FEWXJGNW2WX7STQQ/
Re: Heads up: Python 3.7 rebuild in progress
On Wed, Jun 20, 2018 at 1:36 AM Miro Hrončok wrote: > Unfortunately this is blocked by failing: > > python-manuel > https://koji.fedoraproject.org/koji/taskinfo?taskID=27740145 > https://bugzilla.redhat.com/show_bug.cgi?id=1593132 I had planned to look at that tonight. However, just as I arrived home from work tonight, as I was pulling into my driveway, my neighbor's propane grill exploded, catching his deck and then his house on fire. Fortunately there were no serious injuries. It's been a busy night. I will try to look at python-manuel tomorrow night. Is there a way to do a mock build against the packages currently in f29-python? -- 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/VSLXBTJIV3DL4F66BSHFXUTPPAH3SKOX/
Re: FESCo Elections - May 2018 : Results announcement
On Thu, Jun 14, 2018 at 11:13 AM, Matthew Miller wrote: There's another aspect of burnout: two years is a big commitment. In the past, we've bad people who really were getting burned out or busy with other commitments but who felt they couldn't really step down without abandoning their responsibilities. If we did go to two year terms, I'd rather see one year + automatic re-up if you want. Semi-concrete-ish proposal: let's either do that, or do something really similar. Premise: we currently have too many open positions in too many elections. Under your proposal, we'll have one FESCo election per year, electing 4 or 5 seats at minimum, plus extra seats for any members who have decided not to re-up. So there would be between four and nine seats open in each yearly election, but generally I'd guess it would probably be between five and seven. On the whole, I think this would be a positive change, because decreasing election frequency will increase the importance of the elections. There is a sweet spot between too frequent and too rare, and my intuition says we are too frequent right now. But there will probably be more open positions per election than we have now, and that seems negative to me. 5-7 spots (up from 4-5 currently) is kind of a lot. We'll have reduced the frequency of elections (good), but the elections we do have will be busier and more complicated and harder to vote for (bad). I think it would still be a net win, but I'll propose one more change to reduce open spots: FESCo members get *two* automatic re-ups. This way, a FESCo member could serve up to three years between elections if desired, but there are still annual elections, and there is never any expectation of serving more than one year: that's just something each member would decide at the end of the year when it's time for new elections. Instead of 5-7 open seats, my guess is we'd probably have more like 3-5, depending on how many candidates decide to re-up, which is more in line with today's elections. This should make the elections more significant, and hopefully also easier for voters. I could even support more re-ups than that, but I'll only propose two. It seems like the sweet spot to me. We don't want to overcorrect and wind up with too few open positions and too few elections. And we don't want terms to be *too* long, because FESCo members should still be responsive to the Fedora developer community. Aside: we might also want to align elections to calendar years instead of Fedora releases, since otherwise the schedule could get screwy if we ever wind up getting too far off of the target May/October cycle. Michael ___ 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/VOFMJ5XQ6CTYR3QH3SLD3GUFGQJQELVG/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Wed, Jun 20, 2018 at 8:46 AM, Lennart Poettering wrote: > On Do, 14.06.18 12:06, Jan Kurik (jku...@redhat.com) wrote: > >> The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ >> Boot Loader Specification (BLS)] defines a scheme and file format to > > So, it appears the suggested implementation of this uses > /EFI/fedora/loader/entries/ instead of the mandated /loader/entries/ > directory to place the drop-ins. > > What's the rationale for that? The idea of the boot loader spec is > that multiple OSes or OS versions on the same medium won't fight for > the boot loader and instead can drop-in their own boot entries easily > in a non-conflicting way and make them available in the same boot menu > that way. The strict idea is that *sharing* a drop-in dir is a good > thing, and that exclusive ownership of the boot loader is a major > problem. > > By using a fedora specific directory for the drop-ins you defeat the > whole idea of the boot loader spec, as then suddenly the boot loaders > will conflict again, because they can't share the directory anymore. > > What's going on? What is this? Why is this called "Boot loader spec" > if it implements an entirely different logic, and misses the entire > point of the boot loader spec? > > Quite frankly, I am really surprised by this and this makes me wonder > what the whole point of this feature is at all, and very sure we > shouldn't have it like this. I agree. But I also think there is some incremental risk of namespace collision with /loader/entries as mentioned in Matthew Garrett's derivative of the spec, if it's not located in /EFI/fedora/ Could $BOOT/org/freedesktop/bls/entries instead be $BOOT/org.freedesktop.bls/entries ? -- 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/message/ZC22JUNN4JOWILG7A64XAC5SQEAXMVRC/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Wed, Jun 20, 2018 at 8:35 AM, Lennart Poettering wrote: > On Di, 19.06.18 11:17, Chris Murphy (li...@colorremedies.com) wrote: > >> > Today, systemd has this generator that will automatically find the ESP >> > for you and mount it to /efi or /boot. The idea behind that is that >> > installers can choose whether they want to merge $BOOT and the ESP or >> > not: >> > >> > 1. If they are merged, then the ESP (and thus also $BOOT) is mounted >> >to /boot, automatically by the generator. No other preparation is >> >needed, and /efi does not exist. (Distros could even make /efi a >> >symlink → /boot, but I personally wouldn't bother). >> > >> > 2. If they are not merged, then the ESP is mounted to /efi, >> >automatically by the generator. And /boot would be mounted as $BOOT >> >via an /etc/fstab entry added by the installer. >> > >> > And as mentioned, I'd generally recommend everybody to go for option >> > #1 because it is a lot simpler, and EFI has trivial access to all >> > kernels and such. >> >> Except, it's not simple for installers to migrate to a new bigger ESP >> in the dual boot case. And having different layouts for UEFI and BIOS >> and whether there's dual boot or single boot, isn't simpler. > > Again, if you don't want to resize the ESP, then go for option #2 > above. But if the ESP is usable, then go for option #1. In 100% of the cases where the ESP already exists, it is too small to share. No one. Not Apple, not Microsoft, not Windows OEMs, not Fedora, not any distro, creates an ESP bigger than 550MB. Typical is 99MB for the Microsoft installer (I have a laptop partitioned by Microsoft's install, not an OEM installer, and it's 99MB), and 128MB for Apple, and 200MB for Linux distros. None of these are big enough to share. And the ESP partition is wedged in, again in 100% of cases. It can't be resized in place. Therefore, Option #2 will be extremely common. What percent of Fedora users dual boot? I have no empirical data. I'd guess 1/2. And in my opinion, it's not simple to say: OK if you have this size ESP to start, you get this layout, and if it's bigger you get this other layout, and if it's BIOS you have this 3rd layout. And now we have to document all of this, and train the installer, and openqa, and all the people who help others out with their problems on #fedora and Ask Fedora and users@. I understand it, and I think it's a clusterfuck of complication. I can only imagine the end user confusion, people who actually just want to get shit done. It is possible to just ignore the ESP by treating it pretty much the same as the MBR gap and BIOS Boot. And have one layout for all three cases. That's simple. > >> If $BOOT is defined as where non-static bootloader config + kernel + >> initramfs goes, and if shared $BOOT is a good thing for Linux distros, >> then the $BOOT to always create is type 0xEA / bc13c2ff... and not >> conflate it with the location for the bootloader binaries: the ESP on >> UEFI, and either MBR gap or BIOSBoot on BIOS. > > Well, I am pretty sure legacy-free systems should not be bothered by > having two partitions for that. That just complicates stuff. No, it really doesn't. The *standard* Fedora installation today already has two partitions for that, ESP and /boot. You have to decide which is more important. Broad adoption, which will require equal doses of compromise and simplicity. Or narrow adoption. The BLS, as it is today, is barely even narrowly adopted, let alone broadly adopted. And in my opinion it's because it's neither simple, nor does it compromise. And as Fedora is right now looking to implement BLS, what did they actually do? Adopt the BLS file format and drop in concept, and abandon the other 90% of the spec by punting. I'll tell you what. Maybe consider a general purpose layout and a simplified layout. The typical layout represents a compromise no matter the firmware, and no matter what OS is already present - your option 2. This would be used for workstations, and any case where dual or multiboot is expected. And for things like Fedora VM images, IoT, possibly server, possibly ARM - where the sharing aspect of $BOOT is not expected or a consideration, go with the simplified layout - your option 1. *shrug* >I mean, > adding some minimal kludges to support Windows-cross-boot is fine, but > adjusting everything with that case in the center of everything is > quite wrong. It isn't just Windows. It's macOS. It's all other Linux distros. > Also note that we put together the boot loader spec with systemd-boot > as our implementation of it, as a reference implementation if you so > will. systemd-boot is a very simple, straight-forward boot loader, > that adds a few things missing in UEFI itself, and doesn't contain > code for parsing partition tables or file systems, for searching for > devices and so on, like grub does. It implements the spec, but > explicitly doesn't support splitting $BOOT and the ESP. I am pretty > sure we as
[389-devel] 389 DS nightly 2018-06-21 - 65% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/21/report-389-ds-base-1.4.0.11-20180620gitd590a1c.fc28.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/SPSFERVTDLFVED5TD24OD2DV5VA6XLPA/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Wed, Jun 20, 2018 at 3:26 PM, Adam Williamson wrote: > On Wed, 2018-06-20 at 13:15 -0400, Stephen Gallagher wrote: > > On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox wrote: > > > > The proper behavior here would be for these services not to be marked as > > "failed" when the appropriate hardware is not present. When possible, we > > should be using systemd's Condition* features to skip attempting to start > > it at all, but for things where we can't know it ahead of time, we should > > modify the start script to look for appropriate error codes/messages and > > treat the service as "success" if it's skipped because it's not supported > > on the current hardware. > > Well, for rngd, the maintainer actually argued that he does *not* think > this is the "proper" behaviour. See > https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree > with him (as you can, er, tell from the subsequent discussion), but it > seemed worth noting it's not a universally agreed truth. > > (I don't *think* he'd object to a Condition-type fix, though, if we > could come up with a reliable one). > > I believe we're missing something fundamental here. If a program/service etc. requires specific hardware to work and it can't gracefully handle situations where that hardware is not present - it shouldn't be a default. The way to handle this (and other similar situations) is to take away the default status until it can handle situations where the hardware doesn't exist. This is systems programming 101 - and frankly I am a bit surprised it's a matter of debate. ___ 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/GH3XMTT527D4ZETSFC2VLUTG4AKLESVX/
[Bug 1593482] New: perl-App-Cme-1.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593482 Bug ID: 1593482 Summary: perl-App-Cme-1.028 is available Product: Fedora Version: rawhide Component: perl-App-Cme Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.028 Current version/release in rawhide: 1.027-1.fc29 URL: http://search.cpan.org/dist/App-Cme/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9059/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MSMOYFFYO4FBM4JPL64KVM7YS7V4OB4W/
Re: upcoming systemd-239 release — call for testing
On Wed, 2018-06-20 at 13:17 +0200, Lennart Poettering wrote: > On Di, 19.06.18 22:22, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > On Mon, 2018-06-18 at 12:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi all, > > > > > > we plan to release systemd-239 wednesday-ish and it will be landing in > > > rawhide. There's a bunch of new functionality, see > > > https://github.com/systemd/systemd/blob/master/NEWS. As always, the > > > majority of commits is cleanups and bugfixes and the polishing of > > > existing functionality. A big new feature is "portable services", > > > currently in preview mode. There are man pages, but an introductory > > > blog story is planned around the time of the release, so you might > > > want to wait for that. > > > > > > Please give it a try and report any bugs either in bugzilla [1] or > > > upstream [2]. For testing, rpms are available from copr: > > > https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768345/. > > > > Thanks for the heads up on this. I built a test Rawhide netinst image > > with the updated systemd and ran it through openQA. It mostly worked, > > but several of the tests failed with this error in anaconda: > > > > 22:13:42,713 INF threading: Thread Failed: AnaInstallThread > > (140332673541888) > > 22:13:42,713 DBG exception: running handleException > > 22:13:42,716 CRT exception: Traceback (most recent call last): > > > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > > 843, in wrapped > > ret = orig_obj(*args, **kwargs) > > > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > > 465, in lvm_vgcreate > > return _lvm_vgcreate(name, pv_list, pe_size, extra) > > > > GLib.GError: g-dbus-error-quark: Waiting for 'VgCreate' method of the > > '/com/redhat/lvmdbus1/Manager' object to finish failed: Failed to get > > Complete property of the / object: > > GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with > > signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist > > (19) > > > > it seems like an intermittent error, as not all the tests that create > > LVM VGs failed, and restarting the failed tests mostly resulted in > > passes...but I don't think we've seen this particular error, even as an > > intermittent one, in recent Rawhide tests with systemd 238, so it seems > > like it *could* be caused by the update. Any idea where this may be > > coming from? > > Hmm, this doesn't look like a systemd issue to me. This is a dbus > method call failure of some form. The dbus client and the dbus service > in this case are not provided by systemd, and neither is the dbus > message bus in between. Hence systemd doesn't really insert itself in > any form in the ongoing communication between this IPC client and > server. > > That said, systemd is involved in service activation if the service > isn't around yet at the time the client asks for the service. However, > judging by the provided logs > (https://openqa.stg.fedoraproject.org/tests/318564/file/_do_install_and_reboot-syslog) > the activation of the lvmdbus1 service actually completes fine. > > Hence, this is somewhere between the message bus, and the LVM client > and server. Thanks...so to try and confirm I did a run of the same set of tests (the 'universal' tests) with a regular Rawhide netinst image (one with systemd 238), and indeed the same bug occurred at least once: https://openqa.stg.fedoraproject.org/tests/318862 so it does indeed not appear to be to do with systemd 239. Wonder what is causing it, though. Hum. -- 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/message/EQTG7EV745VFCTL2HSOA7KAVSAIB5TMD/
Fwd: [CentOS-devel] CFP for Dojo @ DevConf.us closes this weekend
Anyone interested in bringing Fedora topics that may be of interest to the CentOS community to this conference? - Forwarded message from Rich Bowen - > Date: Tue, 19 Jun 2018 09:21:41 -0400 > From: Rich Bowen > To: "The CentOS developers mailing list." > Cc: "centos-pr...@centos.org" > Subject: [CentOS-devel] CFP for Dojo @ DevConf.us closes this weekend > X-Bogo25: H 3.14881e-09 > > The CentOS Dojo at DevConf.us is rushing up on us, and I'd like to > have a speaker schedule published by early next week. > > If you are considering submitting a talk, please do it NOW, so that > we don't have to consider canceling this event. Thank you. > > Event details: https://wiki.centos.org/Events/Dojo/DevConfUS2018 > Call for papers: https://goo.gl/forms/kKta9IasJGNxIVR53 > DevConf information: http://devconf.us/ > > Thanks. > > -- > Rich Bowen - rbo...@redhat.com > @CentOSProject // @rbowen > 859 351 9166 > ___ > CentOS-devel mailing list > centos-de...@centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > - End forwarded message - -- Matthew Miller Fedora Project Leader ___ 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/QC7S2ZB5KYGR2YLRDUQXD52CDQT2X7FT/
[389-devel] Reminder: please review: Ticket 49751 - passwordMustChange attribute is not honored by a RO consumer if using "Chain on Update"
Forwarded Message Subject: [389-devel] please review: Ticket 49751 - passwordMustChange attribute is not honored by a RO consumer if using "Chain on Update" Date: Tue, 5 Jun 2018 13:34:09 -0400 From: Mark Reynolds Reply-To: 389 Directory server developer discussion. <389-devel@lists.fedoraproject.org> To: 389-devel@lists.fedoraproject.org https://pagure.io/389-ds-base/issue/49751 https://pagure.io/389-ds-base/pull-request/49755 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/NWRYFI2YFXCYK5LTHUNVP6IQFGR3ECXF/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/GIYRMDW7O3SJK7APX5N5I65ELP77RLT6/
[389-devel] Reminder: please review: Ticket 49734 - Fix various issues with Disk Monitoring
Forwarded Message Subject: [389-devel] please review: Ticket 49734 - Fix various issues with Disk Monitoring Date: Wed, 6 Jun 2018 14:57:42 -0400 From: Mark Reynolds Reply-To: 389 Directory server developer discussion. <389-devel@lists.fedoraproject.org> To: 389-devel@lists.fedoraproject.org https://pagure.io/389-ds-base/issue/49734 https://pagure.io/389-ds-base/pull-request/49759 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/D4RPQUGB4MLMECCLW3A2WDCATEIQIAFY/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/CCIFAJQLSJ2MTJSUWUKXQSV4MT7ZQ6V5/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Wed, 2018-06-20 at 13:15 -0400, Stephen Gallagher wrote: > On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox wrote: > > > This isn't related to a service, but is throwing out an spurious error > > message. There is a patch but it hasn't made it's way > > yet into the Fedora kernel: > > > > rt_cmos registration error: rhbz#1568276 > > Basically an error is being thrown because your system doesn't have > > battery backup. To their credit, it was quickly identified > > and patched. We now just have to wait for the patch to be applied. > > > > However these: > > > > The mcelog.service message is associated with rhbz#1166978 > > The dbxtool.service message is associated with rhbz#1508808 > > The rngd.service message is associated with rhbz#1490632 > > > > At least for me are the result of services being enabled by default, that > > should never have been enabled for my > > environment. > > > > mcelog: I am using an AMD processor. This service only applies to Intel. > > dbxtool: I am not using SecureBoot. This service only applies to > > machines using SecureBoot. > > rngd: I am not using a machine that has a hardware RNG generator > > > > Again, if we are apparently so concerned about a streamlined user > > experience, why are we > > starting processes that aren't needed - and in fact are not appropriate > > for a particular environment, > > and then throwing out error messages which are spurious and confusing? > > > > In my case, this caused me to spend hours individually tracking down all > > these error messages > > to find out that there is nothing wrong with my environment. Instead the > > issue is these services > > are inappropriately started for EVERYBODY - and in one case have been > > languishing for years. > > > > Last time I checked, Fedora wasn't an Intel only, SecureBoot only, > > mandatory hardware RNG generator > > environment. > > > > If we truly are concerned about end user experience - this isn't the way > > to go about it. > > > > > > The proper behavior here would be for these services not to be marked as > "failed" when the appropriate hardware is not present. When possible, we > should be using systemd's Condition* features to skip attempting to start > it at all, but for things where we can't know it ahead of time, we should > modify the start script to look for appropriate error codes/messages and > treat the service as "success" if it's skipped because it's not supported > on the current hardware. Well, for rngd, the maintainer actually argued that he does *not* think this is the "proper" behaviour. See https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree with him (as you can, er, tell from the subsequent discussion), but it seemed worth noting it's not a universally agreed truth. (I don't *think* he'd object to a Condition-type fix, though, if we could come up with a reliable one). -- 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/message/2DUGDLLLUTXTHFDWWOTMADJM3WS42RAC/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Wed, Jun 20, 2018 at 12:35 PM, Lennart Poettering wrote: > On Mi, 20.06.18 13:15, Stephen Gallagher (sgall...@redhat.com) wrote: > > > The proper behavior here would be for these services not to be marked as > > "failed" when the appropriate hardware is not present. When possible, we > > should be using systemd's Condition* features to skip attempting to start > > it at all, … > > Just to mention this: triggered by this mail I posted this PR: > > https://github.com/systemd/systemd/pull/9360 > > This adds ConditionSecurity=uefi-secureboot, which could be nice and > accurate way to condition out that secureboot service. > > That said, it'll probably be a while before that propagates into > fedora. > > Lennart > Thanks... For mcelog and rngd if you don't want to rely on the fact the the cpu is AMD: mcelog has an option --is-cpu-supported and rngd has an option --list Either way, it's absolutely doable. No reason to burden users with misleading, unneeded error messages. ___ 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/XMHZLZVLNJXZGTMOLELD6AZ2ZVIJHUBH/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 5:12 PM Josh Boyer wrote: > > On Wed, Jun 20, 2018 at 4:12 PM Matthew Miller > wrote: > > > > On Wed, Jun 20, 2018 at 03:59:06PM -0400, Josh Boyer wrote: > > > No. A hybrid repository is a repository that has both regular RPMs > > > and modules, with repo metadata that describes both. It avoids having > > > a separate repository for each and allows a natural transition from > > > normal RPM to modules without users having to go hunt for their > > > content as it migrates. There are other benefits to it, but it's > > > basically an end user simplification. > > > > If I have both repositories enabled, why would I have to hunt? > > If you have both repositories always enabled, why do you need two > repositories? If you don't have them always enabled, off you go > hunting. Also, to be clear, there *are* reasons why one might want to split content into different repositories. However, I don't think the way that content is packaged should be one of those reasons. Those kinds of decisions should be around the purpose of the content itself, or intended uses, or common lifecycles. Whether it's a module or a regular RPM should be fairly immaterial. josh > If we believe modularity to be a technology that we can really > leverage and start making a fundamental piece of how Fedora is built > and offered, why would we want to segregate modules to their own > repository? What does it buy you? How do those advantages outweigh > the perception that modules are different and scary and need to be > separated from the rest of what is Fedora? > > FWIW, I'm not insisting we have a hybrid approach. However, I think > over time it's actually going to cause more problems for Fedora and > other producers and consumers of modules if they remain separated. > > josh ___ 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/MGVYE6OLOPRSQJT5WTJLWWFAXFNKN2ZB/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 4:12 PM Matthew Miller wrote: > > On Wed, Jun 20, 2018 at 03:59:06PM -0400, Josh Boyer wrote: > > No. A hybrid repository is a repository that has both regular RPMs > > and modules, with repo metadata that describes both. It avoids having > > a separate repository for each and allows a natural transition from > > normal RPM to modules without users having to go hunt for their > > content as it migrates. There are other benefits to it, but it's > > basically an end user simplification. > > If I have both repositories enabled, why would I have to hunt? If you have both repositories always enabled, why do you need two repositories? If you don't have them always enabled, off you go hunting. If we believe modularity to be a technology that we can really leverage and start making a fundamental piece of how Fedora is built and offered, why would we want to segregate modules to their own repository? What does it buy you? How do those advantages outweigh the perception that modules are different and scary and need to be separated from the rest of what is Fedora? FWIW, I'm not insisting we have a hybrid approach. However, I think over time it's actually going to cause more problems for Fedora and other producers and consumers of modules if they remain separated. josh ___ 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/6YC5A4IH5FNZTNJ5Z2MO3FBRSR6ZZJBS/
[Bug 1590332] Upgrade perl-Devel-CheckLib to 1.13
https://bugzilla.redhat.com/show_bug.cgi?id=1590332 --- Comment #1 from Fedora Update System --- perl-Devel-CheckLib-1.13-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-554065c5ca -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TZLXLOM7BW4OOCYPIDTMJZAH5A6OZISZ/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 03:59:06PM -0400, Josh Boyer wrote: > No. A hybrid repository is a repository that has both regular RPMs > and modules, with repo metadata that describes both. It avoids having > a separate repository for each and allows a natural transition from > normal RPM to modules without users having to go hunt for their > content as it migrates. There are other benefits to it, but it's > basically an end user simplification. If I have both repositories enabled, why would I have to hunt? -- Matthew Miller Fedora Project Leader ___ 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/6S3XV5CVYXZUODKVN6U2TO6WYK2WCJRA/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 3:58 PM Stephen Gallagher wrote: > > > > On Wed, Jun 20, 2018 at 3:50 PM Matthew Miller > wrote: >> >> On Wed, Jun 20, 2018 at 03:02:47PM -0400, Josh Boyer wrote: >> > > Correct, this is about ensuring that all Fedora installations have >> > > access to the modules we build, but there's no change to how >> > > they're stored on mirrors, etc. >> > Ok. Do we ever foresee the hybrid repository approach happening in Fedora? >> >> The hybrid approach is "things can be built as modules, but tagged into >> the base", right? What problems does this solve vs. allowing modules to >> be used as dependencies and build deps? >> > > I think the "hybrid approach" he's referring to is having modular and > non-modular RPMs living in the same directory structure. I don't see that > being needed in Fedora at this point. That's what I was referring to. I would agree it isn't *required* in Fedora. I think it's still worth exploring though. > If he *does* mean the above, I think that's going to be solved by Ursa Major > (long explanation available on request), but that's probably an F30+ feature. > And yeah, that will basically be allowing modules to be a dep for non-modular > content. I think we need this too, but it's separate from what I was asking about. josh ___ 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/NYPBT6E3KIUUFUQXE4RQ7VOUJC4ZMKX6/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 3:49 PM Matthew Miller wrote: > > On Wed, Jun 20, 2018 at 03:02:47PM -0400, Josh Boyer wrote: > > > Correct, this is about ensuring that all Fedora installations have > > > access to the modules we build, but there's no change to how > > > they're stored on mirrors, etc. > > Ok. Do we ever foresee the hybrid repository approach happening in Fedora? > > The hybrid approach is "things can be built as modules, but tagged into > the base", right? What problems does this solve vs. allowing modules to No. A hybrid repository is a repository that has both regular RPMs and modules, with repo metadata that describes both. It avoids having a separate repository for each and allows a natural transition from normal RPM to modules without users having to go hunt for their content as it migrates. There are other benefits to it, but it's basically an end user simplification. > be used as dependencies and build deps? That's a different problem. That's something in brew itself, using modules via a different service that talks to MBS. That has utility but needs careful management but it's more centered around developers. josh ___ 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/EQNRJYCZ7EUGZ7CIYZ4TBX2KPFUNJXK4/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 3:50 PM Matthew Miller wrote: > On Wed, Jun 20, 2018 at 03:02:47PM -0400, Josh Boyer wrote: > > > Correct, this is about ensuring that all Fedora installations have > > > access to the modules we build, but there's no change to how > > > they're stored on mirrors, etc. > > Ok. Do we ever foresee the hybrid repository approach happening in > Fedora? > > The hybrid approach is "things can be built as modules, but tagged into > the base", right? What problems does this solve vs. allowing modules to > be used as dependencies and build deps? > > I think the "hybrid approach" he's referring to is having modular and non-modular RPMs living in the same directory structure. I don't see that being needed in Fedora at this point. If he *does* mean the above, I think that's going to be solved by Ursa Major (long explanation available on request), but that's probably an F30+ feature. And yeah, that will basically be allowing modules to be a dep for non-modular content. ___ 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/MDYU7HZLVD6GUDKZKIE7Z4PNKXXEZD6K/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 03:23:02PM -0400, Owen Taylor wrote: > * There are no plans to add any user interface to enable/disable modules > in the GNOME Software user interface. I think this is _probably_ okay, because Software only shows a selection of GUI applications anyway. At least assuming we get the rpm->flatpack pipeline going. Flatpak will then be the way to install alternate versions of, say, Gimp. -- Matthew Miller Fedora Project Leader ___ 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/PBYMCLKMFDN7SR23Y2CNGSBDUKN4KKBZ/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 03:02:47PM -0400, Josh Boyer wrote: > > Correct, this is about ensuring that all Fedora installations have > > access to the modules we build, but there's no change to how > > they're stored on mirrors, etc. > Ok. Do we ever foresee the hybrid repository approach happening in Fedora? The hybrid approach is "things can be built as modules, but tagged into the base", right? What problems does this solve vs. allowing modules to be used as dependencies and build deps? -- Matthew Miller Fedora Project Leader ___ 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/XF42Q4C7FADZG4PXVGEMEVUJRY6TL4Q7/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Mi, 20.06.18 13:15, Stephen Gallagher (sgall...@redhat.com) wrote: > The proper behavior here would be for these services not to be marked as > "failed" when the appropriate hardware is not present. When possible, we > should be using systemd's Condition* features to skip attempting to start > it at all, … Just to mention this: triggered by this mail I posted this PR: https://github.com/systemd/systemd/pull/9360 This adds ConditionSecurity=uefi-secureboot, which could be nice and accurate way to condition out that secureboot service. That said, it'll probably be a while before that propagates into fedora. 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/FEMQIUE3P7ETC4L2RWJSVS2IHMOM5WP2/
Re: F29 System Wide Change: Modules for Everyone
I'm not sure it needs to be mentioned in the change proposal - but there are some caveats to this as it applies to the workstation: * There are no plans to add any user interface to enable/disable modules in the GNOME Software user interface. * If we even want graphical applications from enabled modules to appear in GNOME Software, someone is going to have to put work into appstream enabling modules, and into filtering the appstream data based on enabled modules. * For Fedora Silverblue, if we want users to be able to layer rpms from modules, then rpm-ostree will likely need work. For the Workstation in general we want to move to a model where the system install set is stable and enables basic functionality, and containers are where you do sysadmin experimentation and development. Silverblue is the long-term version of this, but we encourage this way of working even for RPM-based installations. So ideally documentation about trying out modularity on Fedora Workstation for something like a different version of nodejs would show doing that inside a container. (With the caveat that we're still figuring out what the recommended best practices are for pet containers.) Owen On Wed, Jun 20, 2018 at 1:14 PM, Jan Kurik wrote: > = Proposed System Wide Change: Modules for Everyone = > https://fedoraproject.org/wiki/Changes/ModulesForEveryone > > > Owner(s): > * Stephen Gallagher > * Langdon White > > > All Fedora installations will have modular repositories enabled by > default, previously available, by default, only to Server Edition. > > > == Detailed description == > In Fedora 28, the Server Edition debuted new modular functionality, > allowing end-users access to alternative versions of popular software. Due > to technical limitations with package-management software, it was not > available for non-Server deployments of Fedora. Beginning with Fedora 29, > all installations of Fedora will have modules available for installation > and update. This will be done by merging the `fedora-repos-modular` > sub-package back into the `fedora-repos` package. > > > == Scope == > * Proposal owners: > The proposal owners need to coordinate the work of the DNF team and > release-engineering to make sure that the repo subpackage merge only > happens once the libdnf enhancements are stable. We will also need to > prepare and run a Fedora Test Day with the QA team. > > * Other developers: > The DNF team is already committed to providing the necessary changes for > libdnf in Fedora 29. > > * Release engineering: > #7561 [https://pagure.io/releng/issue/7561] > > ** List of deliverables: > All Fedora installations > > * Policies and guidelines: > No alterations to packaging guidelines are required specifically for this > change > > * Trademark approval: > N/A (not needed for this Change) > -- > Jan Kuřík > JBoss EAP Program Manager > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/ > > ___ 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/OJ5Q3B7OAU5TAUBJPG3FGALEYZCJNVMM/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 2:22 PM Stephen Gallagher wrote: > > > > On Wed, Jun 20, 2018 at 1:49 PM Josh Boyer wrote: >> >> On Wed, Jun 20, 2018 at 1:14 PM Jan Kurik wrote: >> > >> > = Proposed System Wide Change: Modules for Everyone = >> > https://fedoraproject.org/wiki/Changes/ModulesForEveryone >> > >> > >> > Owner(s): >> > * Stephen Gallagher >> > * Langdon White >> > >> > >> > All Fedora installations will have modular repositories enabled by >> > default, previously available, by default, only to Server Edition. >> > >> > >> > == Detailed description == >> > In Fedora 28, the Server Edition debuted new modular functionality, >> > allowing end-users access to alternative versions of popular software. Due >> > to technical limitations with package-management software, it was not >> > available for non-Server deployments of Fedora. Beginning with Fedora 29, >> > all installations of Fedora will have modules available for installation >> > and update. This will be done by merging the `fedora-repos-modular` >> > sub-package back into the `fedora-repos` package. >> >> To be clear, this is only about merging the .repo file back into the >> package. It is NOT about creating a hybrid repository with RPMs and >> modules combined, and the modular repository remains a separate >> repository. Correct? > > > Correct, this is about ensuring that all Fedora installations have access to > the modules we build, but there's no change to how they're stored on mirrors, > etc. Ok. Do we ever foresee the hybrid repository approach happening in Fedora? > It also carries with it the implication that the supported package managers > must handle module updates correctly. (It does *not* require that they all be > able to handle selecting/switching module streams, but it must honor > whichever stream was set via DNF). A good clarification. Thanks. josh ___ 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/7SDYRJP27MOS25GT44QZRGVURZM47P7G/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 1:49 PM Josh Boyer wrote: > On Wed, Jun 20, 2018 at 1:14 PM Jan Kurik wrote: > > > > = Proposed System Wide Change: Modules for Everyone = > > https://fedoraproject.org/wiki/Changes/ModulesForEveryone > > > > > > Owner(s): > > * Stephen Gallagher > > * Langdon White > > > > > > All Fedora installations will have modular repositories enabled by > default, previously available, by default, only to Server Edition. > > > > > > == Detailed description == > > In Fedora 28, the Server Edition debuted new modular functionality, > allowing end-users access to alternative versions of popular software. Due > to technical limitations with package-management software, it was not > available for non-Server deployments of Fedora. Beginning with Fedora 29, > all installations of Fedora will have modules available for installation > and update. This will be done by merging the `fedora-repos-modular` > sub-package back into the `fedora-repos` package. > > To be clear, this is only about merging the .repo file back into the > package. It is NOT about creating a hybrid repository with RPMs and > modules combined, and the modular repository remains a separate > repository. Correct? > Correct, this is about ensuring that all Fedora installations have access to the modules we build, but there's no change to how they're stored on mirrors, etc. It also carries with it the implication that the supported package managers must handle module updates correctly. (It does *not* require that they all be able to handle selecting/switching module streams, but it must honor whichever stream was set via DNF). ___ 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/YJWYD4JKZXRU2LZSA3RJA4LGPBBBRSSJ/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Wed, Jun 20, 2018 at 10:15 AM, Stephen Gallagher wrote: > > > On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox wrote: > >> This isn't related to a service, but is throwing out an spurious error >> message. There is a patch but it hasn't made it's way >> yet into the Fedora kernel: >> >> rt_cmos registration error: rhbz#1568276 >> Basically an error is being thrown because your system doesn't have >> battery backup. To their credit, it was quickly identified >> and patched. We now just have to wait for the patch to be applied. >> >> However these: >> >> The mcelog.service message is associated with rhbz#1166978 >> The dbxtool.service message is associated with rhbz#1508808 >> The rngd.service message is associated with rhbz#1490632 >> >> At least for me are the result of services being enabled by default, that >> should never have been enabled for my >> environment. >> >> mcelog: I am using an AMD processor. This service only applies to Intel. >> dbxtool: I am not using SecureBoot. This service only applies to >> machines using SecureBoot. >> rngd: I am not using a machine that has a hardware RNG generator >> >> The proper behavior here would be for these services not to be marked as > "failed" when the appropriate hardware is not present. When possible, we > should be using systemd's Condition* features to skip attempting to start > it at all, but for things where we can't know it ahead of time, we should > modify the start script to look for appropriate error codes/messages and > treat the service as "success" if it's skipped because it's not supported > on the current hardware. > > This would be the ideal situation, because it means that if the situation > changes (e.g. mcelog gains AMD support in an update, someone plugs in an > hardware RNG device, etc.), the service will start working without > additional intervention. > Agreed - there are commands which provide this information... for CPU (Intel or AMD) and for querying whether or not one is using SecureBoot. Can we please get the people who are responsible for the creation of these services to fix them? The issue regarding battery backup (rhbz#1568276) already has a patch created - we are just waiting for to be incorporated into the kernel. We always seem to be chasing the next shiny object, but ignore things that have been broken for years. ___ 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/U7ZNCR6T2P7363TNZAALQLOUFW5BMXD7/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jun 20, 2018 at 1:14 PM Jan Kurik wrote: > > = Proposed System Wide Change: Modules for Everyone = > https://fedoraproject.org/wiki/Changes/ModulesForEveryone > > > Owner(s): > * Stephen Gallagher > * Langdon White > > > All Fedora installations will have modular repositories enabled by default, > previously available, by default, only to Server Edition. > > > == Detailed description == > In Fedora 28, the Server Edition debuted new modular functionality, allowing > end-users access to alternative versions of popular software. Due to > technical limitations with package-management software, it was not available > for non-Server deployments of Fedora. Beginning with Fedora 29, all > installations of Fedora will have modules available for installation and > update. This will be done by merging the `fedora-repos-modular` sub-package > back into the `fedora-repos` package. To be clear, this is only about merging the .repo file back into the package. It is NOT about creating a hybrid repository with RPMs and modules combined, and the modular repository remains a separate repository. Correct? josh ___ 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/V63X27S66YATVS2ASHFNDQRIMDZ765QO/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
Hi, On 20-06-18 18:33, Gerald B. Cox wrote: This isn't related to a service, but is throwing out an spurious error message. There is a patch but it hasn't made it's way yet into the Fedora kernel: rt_cmos registration error: rhbz#1568276 Basically an error is being thrown because your system doesn't have battery backup. To their credit, it was quickly identified and patched. We now just have to wait for the patch to be applied. However these: The mcelog.service message is associated with rhbz#1166978 The dbxtool.service message is associated with rhbz#1508808 The rngd.service message is associated with rhbz#1490632 At least for me are the result of services being enabled by default, that should never have been enabled for my environment. mcelog: I am using an AMD processor. This service only applies to Intel. dbxtool: I am not using SecureBoot. This service only applies to machines using SecureBoot. rngd: I am not using a machine that has a hardware RNG generator Again, if we are apparently so concerned about a streamlined user experience, why are we starting processes that aren't needed - and in fact are not appropriate for a particular environment, and then throwing out error messages which are spurious and confusing? In my case, this caused me to spend hours individually tracking down all these error messages to find out that there is nothing wrong with my environment. Instead the issue is these services are inappropriately started for EVERYBODY - and in one case have been languishing for years. Last time I checked, Fedora wasn't an Intel only, SecureBoot only, mandatory hardware RNG generator environment. If we truly are concerned about end user experience - this isn't the way to go about it. Note that any service failing will change things over from the silent boot we want to have to showing details, starting with the: Starting foo... [FAILED] message, so I fully agree with you. I've put looking into the 3 service bugs you refer to above at the end of my silent boot todo list. I first want to get al the other bits involved working, but once that is done making sure false-positive failures like this don't break the experience definitely is something which we should work on. 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/3LVW5ZBXPNF3DD2SNE5CCNND2ARJFMYI/
Re: Heads up: Python 3.7 rebuild in progress
Hi Miro, there are new releases of upstream for python-jep, py4j and jpype. Unfortunately, me as the maintainer of these packages did not find any time to update those. There's not much sense actually to rebuild the outdated packages. https://bugzilla.redhat.com/show_bug.cgi?id=1592995 https://bugzilla.redhat.com/show_bug.cgi?id=1574046 https://bugzilla.redhat.com/show_bug.cgi?id=1563207 FTBFS of jep. There's some ongoing work to implement official support for Python 3.7: https://github.com/ninia/jep/commit/f1ae0672cf8ceea8c22576d910d1aae7b0bfd081 https://github.com/ninia/jep/issues/142 FTBFS of jpype. Please be aware of PEP 432. No idea if upstream needs to provide a fix. https://github.com/python/cpython/pull/1729 ___ 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/ARUOCC774DUSGAC2GPGCTGGYQGQJBU53/
Re: Services that shouldn't be started in the first place: Was F29... hide.. grub
On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox wrote: > This isn't related to a service, but is throwing out an spurious error > message. There is a patch but it hasn't made it's way > yet into the Fedora kernel: > > rt_cmos registration error: rhbz#1568276 > Basically an error is being thrown because your system doesn't have > battery backup. To their credit, it was quickly identified > and patched. We now just have to wait for the patch to be applied. > > However these: > > The mcelog.service message is associated with rhbz#1166978 > The dbxtool.service message is associated with rhbz#1508808 > The rngd.service message is associated with rhbz#1490632 > > At least for me are the result of services being enabled by default, that > should never have been enabled for my > environment. > > mcelog: I am using an AMD processor. This service only applies to Intel. > dbxtool: I am not using SecureBoot. This service only applies to > machines using SecureBoot. > rngd: I am not using a machine that has a hardware RNG generator > > Again, if we are apparently so concerned about a streamlined user > experience, why are we > starting processes that aren't needed - and in fact are not appropriate > for a particular environment, > and then throwing out error messages which are spurious and confusing? > > In my case, this caused me to spend hours individually tracking down all > these error messages > to find out that there is nothing wrong with my environment. Instead the > issue is these services > are inappropriately started for EVERYBODY - and in one case have been > languishing for years. > > Last time I checked, Fedora wasn't an Intel only, SecureBoot only, > mandatory hardware RNG generator > environment. > > If we truly are concerned about end user experience - this isn't the way > to go about it. > > The proper behavior here would be for these services not to be marked as "failed" when the appropriate hardware is not present. When possible, we should be using systemd's Condition* features to skip attempting to start it at all, but for things where we can't know it ahead of time, we should modify the start script to look for appropriate error codes/messages and treat the service as "success" if it's skipped because it's not supported on the current hardware. This would be the ideal situation, because it means that if the situation changes (e.g. mcelog gains AMD support in an update, someone plugs in an hardware RNG device, etc.), the service will start working without additional intervention. ___ 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/65FEOGRTZJL32XMQE7RZOJN4X3EMPNZN/
F29 System Wide Change: Modules for Everyone
= Proposed System Wide Change: Modules for Everyone = https://fedoraproject.org/wiki/Changes/ModulesForEveryone Owner(s): * Stephen Gallagher * Langdon White All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition. == Detailed description == In Fedora 28, the Server Edition debuted new modular functionality, allowing end-users access to alternative versions of popular software. Due to technical limitations with package-management software, it was not available for non-Server deployments of Fedora. Beginning with Fedora 29, all installations of Fedora will have modules available for installation and update. This will be done by merging the `fedora-repos-modular` sub-package back into the `fedora-repos` package. == Scope == * Proposal owners: The proposal owners need to coordinate the work of the DNF team and release-engineering to make sure that the repo subpackage merge only happens once the libdnf enhancements are stable. We will also need to prepare and run a Fedora Test Day with the QA team. * Other developers: The DNF team is already committed to providing the necessary changes for libdnf in Fedora 29. * Release engineering: #7561 [https://pagure.io/releng/issue/7561] ** List of deliverables: All Fedora installations * Policies and guidelines: No alterations to packaging guidelines are required specifically for this change * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/
Services that shouldn't be started in the first place: Was F29... hide.. grub
This isn't related to a service, but is throwing out an spurious error message. There is a patch but it hasn't made it's way yet into the Fedora kernel: rt_cmos registration error: rhbz#1568276 Basically an error is being thrown because your system doesn't have battery backup. To their credit, it was quickly identified and patched. We now just have to wait for the patch to be applied. However these: The mcelog.service message is associated with rhbz#1166978 The dbxtool.service message is associated with rhbz#1508808 The rngd.service message is associated with rhbz#1490632 At least for me are the result of services being enabled by default, that should never have been enabled for my environment. mcelog: I am using an AMD processor. This service only applies to Intel. dbxtool: I am not using SecureBoot. This service only applies to machines using SecureBoot. rngd: I am not using a machine that has a hardware RNG generator Again, if we are apparently so concerned about a streamlined user experience, why are we starting processes that aren't needed - and in fact are not appropriate for a particular environment, and then throwing out error messages which are spurious and confusing? In my case, this caused me to spend hours individually tracking down all these error messages to find out that there is nothing wrong with my environment. Instead the issue is these services are inappropriately started for EVERYBODY - and in one case have been languishing for years. Last time I checked, Fedora wasn't an Intel only, SecureBoot only, mandatory hardware RNG generator environment. If we truly are concerned about end user experience - this isn't the way to go about it. On Tue, Jun 19, 2018 at 10:54 PM, Gerald B. Cox wrote: > Here is another bug that was opened in 2014 and closed "WONTFIX because it > was directly tied to F24. Here we are with F28 > and it still exists: https://bugzilla.redhat.com/show_bug.cgi?id=1166978 > > Again, if we're concerned about the cleaning up of the boot process, why > are we apparently ignoring bugs that are associated > with processes that fail and throw out spurious messages? > > If I issue: systemctl status, it tells me my system is "degraded" because > of the following: > > systemctl list-units --state=failed > UNITLOAD ACTIVE SUBDESCRIPTION > > ● dbxtool.service loaded failed failed Secure Boot DBX (blacklist) > updater > ● mcelog.service loaded failed failed Machine Check Exception Logging > Daemon > ● rngd.serviceloaded failed failed Hardware RNG Entropy Gatherer Daemon > > The mcelog.service message is associated with rhbz#1166978 > The dbxtool.service message is associated with rhbz#1508808 > The rngd.service message is associated with rhbz#1490632 > > > > > > > On Sun, Jun 10, 2018 at 10:02 AM, Gerald B. Cox wrote: > >> On Thu, Jun 7, 2018 at 2:07 AM, Hans de Goede >> wrote: >> >>> Hi, >>> >>> On 04-06-18 21:17, Adam Williamson wrote: >>> On Thu, 2018-05-31 at 12:43 +0200, Jan Kurik wrote: > = Proposed System Wide Change: Hide the grub menu = > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu > >> I've updated this bug: https://bugzilla.redhat.com/sh >> ow_bug.cgi?id=1406844 >> >> Basically, since at least F24 - maybe longer my boot has been interrupted >> by this message: >> >> > sp5100-tco sp5100-tco: I/O address 0x0cd6 already in use >> >> The bug was closed, and then cloned and reopened. >> >> As I mentioned before, I have no problem with the grub change as long as >> there is documentation >> that shows people how to reverse it if they wish - and Hans (thank you >> very much) has agreed to this. >> >> However, seems to me that having this bug (which appears to affect all >> AMD users) languishing >> for years seems to negate the reasoning behind this change. If we're >> wanting to implement >> a more or less cosmetic change which saves a few seconds, having spurious >> messages >> interrupting and slowing down the boot process should also be resolved. >> >> >> > ___ 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/UZ6LSQ4UG6VNBZII4KUXQ6635YR5K7JE/
[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1592742 --- Comment #8 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8ce749bf40 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/X5LR5L2EPHK7OGAF5E7OYC7TSWZTVQT5/
[Bug 1593043] perl-CPAN-Perl-Releases-3.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593043 --- Comment #4 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8ce749bf40 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TO66AZSM7M7EJJCVPIEWC4TVZ4FWDMAT/
[Bug 1591047] perl-BSON-v1.6.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1591047 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-BSON-1.6.5-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9f7f72ec78 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QPJ64HAVDOPMHABULGA5SW4ISNQT63KK/
[Bug 1593041] perl-BSON-v1.6.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593041 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-BSON-1.6.5-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9f7f72ec78 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/SGJWGZHGUW23CHOSL46MVJKCKWPOTCWK/
Re: F29 System Wide Change: Hide the grub menu
Actually, that is the error I am receiving... is your SecureBoot enabled or disabled? You can check by: mokutil --sb-state On Wed, Jun 20, 2018 at 4:56 AM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Wednesday, 20 June 2018 at 07:54, Gerald B. Cox wrote: > [...] > > The dbxtool.service message is associated with rhbz#1508808 > > Thanks to this, I checked my machine and filed: > https://bugzilla.redhat.com/show_bug.cgi?id=1593258 > because I'm seeing a different variation of yours. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPMFusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > 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/AKOEZXPL237BSSSTAGN6B3476T7IOW4W/ > ___ 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/4HI2ITR2YAAKEEE5HI6TJL6GVJZXTK5X/
[Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method
https://bugzilla.redhat.com/show_bug.cgi?id=1593318 Andrej Nemec changed: What|Removed |Added Blocks||1593323 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7PBQNTS2U7SXUDZ4MXMVP3EBAZ3IGMZX/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Do, 14.06.18 12:06, Jan Kurik (jku...@redhat.com) wrote: > The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ > Boot Loader Specification (BLS)] defines a scheme and file format to So, it appears the suggested implementation of this uses /EFI/fedora/loader/entries/ instead of the mandated /loader/entries/ directory to place the drop-ins. What's the rationale for that? The idea of the boot loader spec is that multiple OSes or OS versions on the same medium won't fight for the boot loader and instead can drop-in their own boot entries easily in a non-conflicting way and make them available in the same boot menu that way. The strict idea is that *sharing* a drop-in dir is a good thing, and that exclusive ownership of the boot loader is a major problem. By using a fedora specific directory for the drop-ins you defeat the whole idea of the boot loader spec, as then suddenly the boot loaders will conflict again, because they can't share the directory anymore. What's going on? What is this? Why is this called "Boot loader spec" if it implements an entirely different logic, and misses the entire point of the boot loader spec? Quite frankly, I am really surprised by this and this makes me wonder what the whole point of this feature is at all, and very sure we shouldn't have it like this. 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/OTJ3WNYXTFOOCMZ6V7PRKYICVIYDZWS2/
[Bug 1589473] perl-MooX-Struct-0.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1589473 --- Comment #7 from Fedora Update System --- perl-MooX-Struct-0.017-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TV55KLMYQ4A6DLEA4LDIRQMMPBKPSXQD/
[Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method
https://bugzilla.redhat.com/show_bug.cgi?id=1593318 Andrej Nemec changed: What|Removed |Added Depends On||1593319, 1593320, 1593321 --- Comment #1 from Andrej Nemec --- Created perl-Email-Address tracking bugs for this issue: Affects: epel-6 [bug 1593320] Affects: fedora-all [bug 1593319] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1593319 [Bug 1593319] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1593320 [Bug 1593320] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [epel-6] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/4ZT55PF6UHKB6FMSUMRSXBVCD4YX2KEP/
[Bug 1593320] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1593320 Andrej Nemec changed: What|Removed |Added Blocks||1593318 (CVE-2018-12558) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1593318 [Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/LGE6PUKM2DZIJ75CA3RUAXQ5A3TQLU2V/
[Bug 1593319] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1593319 Andrej Nemec changed: What|Removed |Added Blocks||1593318 (CVE-2018-12558) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1593318 [Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/PYG566P2OU5ZNE7KUCS52EBNELKWJLS3/
[Bug 1593320] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1593320 --- Comment #1 from Andrej Nemec --- Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1593318,1593320 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/HX2OCHO4BBQFQGXJYV2VIOENBPDBVGMW/
[Bug 1593319] New: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1593319 Bug ID: 1593319 Summary: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [fedora-all] Product: Fedora Version: 28 Component: perl-Email-Address Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: tcall...@redhat.com Reporter: ane...@redhat.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, rob.my...@gtri.gatech.edu, tcall...@redhat.com This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QKBDLKE5LBTX7WKV2PKMLLWNWRKF32FX/
[Bug 1593320] New: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1593320 Bug ID: 1593320 Summary: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [epel-6] Product: Fedora EPEL Version: el6 Component: perl-Email-Address Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: rob.my...@gtri.gatech.edu Reporter: ane...@redhat.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, rob.my...@gtri.gatech.edu, tcall...@redhat.com This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of epel-6. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/LPEIRGSE3V6HODZ6O4MYBFSUANZ4NEL5/
[Bug 1593319] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1593319 --- Comment #1 from Andrej Nemec --- Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. = # bugfix, security, enhancement, newpackage (required) type=security # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1593318,1593319 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False == Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/AV7Z56NUP4PFCS2GVCGRTDB4TL35UB4Q/
[Bug 1593318] New: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse () method
https://bugzilla.redhat.com/show_bug.cgi?id=1593318
Bug ID: 1593318
Summary: CVE-2018-12558 perl-Email-Address: Specially crafted
input could cause Denial of Service due to complex
parse() method
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-t...@redhat.com
Reporter: ane...@redhat.com
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
perl-maint-l...@redhat.com, rob.my...@gtri.gatech.edu,
tcall...@redhat.com
The parse() method in the Email::Address module through 1.909 for Perl can
consume a large amount of resources on specially prepared input, leading to
Denial of Service. Prepared special input that caused this problem contained 30
form-field characters ("\f").
References:
http://seclists.org/oss-sec/2018/q2/211
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901873
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/5J5HWMQWAJWBPZHWNOI5PYWKLSUNAEDR/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Di, 19.06.18 11:17, Chris Murphy (li...@colorremedies.com) wrote: > > Today, systemd has this generator that will automatically find the ESP > > for you and mount it to /efi or /boot. The idea behind that is that > > installers can choose whether they want to merge $BOOT and the ESP or > > not: > > > > 1. If they are merged, then the ESP (and thus also $BOOT) is mounted > >to /boot, automatically by the generator. No other preparation is > >needed, and /efi does not exist. (Distros could even make /efi a > >symlink → /boot, but I personally wouldn't bother). > > > > 2. If they are not merged, then the ESP is mounted to /efi, > >automatically by the generator. And /boot would be mounted as $BOOT > >via an /etc/fstab entry added by the installer. > > > > And as mentioned, I'd generally recommend everybody to go for option > > #1 because it is a lot simpler, and EFI has trivial access to all > > kernels and such. > > Except, it's not simple for installers to migrate to a new bigger ESP > in the dual boot case. And having different layouts for UEFI and BIOS > and whether there's dual boot or single boot, isn't simpler. Again, if you don't want to resize the ESP, then go for option #2 above. But if the ESP is usable, then go for option #1. > If $BOOT is defined as where non-static bootloader config + kernel + > initramfs goes, and if shared $BOOT is a good thing for Linux distros, > then the $BOOT to always create is type 0xEA / bc13c2ff... and not > conflate it with the location for the bootloader binaries: the ESP on > UEFI, and either MBR gap or BIOSBoot on BIOS. Well, I am pretty sure legacy-free systems should not be bothered by having two partitions for that. That just complicates stuff. I mean, adding some minimal kludges to support Windows-cross-boot is fine, but adjusting everything with that case in the center of everything is quite wrong. Note that ESP and $BOOT have the same semantics, life-cycles and requirements, hence they should really be the same if possible, and only be split if they can't. Also note that we put together the boot loader spec with systemd-boot as our implementation of it, as a reference implementation if you so will. systemd-boot is a very simple, straight-forward boot loader, that adds a few things missing in UEFI itself, and doesn't contain code for parsing partition tables or file systems, for searching for devices and so on, like grub does. It implements the spec, but explicitly doesn't support splitting $BOOT and the ESP. I am pretty sure we as the spec authors should keep our implementation and the spec aligned. That said, it's of course up to Fedora to implement the spec in Fedora. If it always wants to split the two partitions, by all means, go for it, but I think it's needless complication except if you actually dual boot with Windows. > Windows, macOS, the various distros - they all have substantial > differences in how they boot. But the one commonality I most > consistently see? The bootloader teaches the pre-boot environment, > right off the bat, how to read a real file system, and from that real > file system the kernel and initramfs are loaded. MacOS has native apple file system read support in their firmware, they rely on the firmware to read the stuff they need directly from the final disk. We don't have that luxury. The good thing about using VFAT for $BOOT is that it is the common ground pretty much everything involved in booting groks, if they grok a file system at all. UEFI knows it, and so does the Raspberry Pi boot protocol. The Linux initrd knows it and so does the Linux host OS, Windows knows it. MacOS knows it. Grub knows it. 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/NBA5TJT5PKLLIJJYVJSMKWAB2P4D4SZO/
Re: gdbm reabase question
On 20/06/18 15:17, Jerry James wrote: There was a successful clisp build for f28, which depends on gdbm rather than compat-gdbm, so I don't know why the F26 build should matter. Clisp is again failing to build in Rawhide, though. I've got it on my list of Fedora Things To Do. I will try updating to a more recent version soon and see if that fixes the build failure. (Fingers crossed; clisp is a very finicky package.) I guess because 2.49-22.20170224hg.fc26 is the version currently in rawhide, which is indeed older than the version in F28 which suggests that it wasn't built in rawhide first as is supposed to happen. As you say it looks like the new version was built simultaneously in f28 and rawhide and the rawhide build failed and was never fixed so it still has the f26 one. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2XGNSXO5QEJSSXXKQVXY4QC5AEQB63WL/
Re: gdbm reabase question
On Wed, Jun 20, 2018 at 3:50 AM wrote: > clisp-0:2.49-22.20170224hg.fc26.i686 > clisp-0:2.49-22.20170224hg.fc26.x86_64 There was a successful clisp build for f28, which depends on gdbm rather than compat-gdbm, so I don't know why the F26 build should matter. Clisp is again failing to build in Rawhide, though. I've got it on my list of Fedora Things To Do. I will try updating to a more recent version soon and see if that fixes the build failure. (Fingers crossed; clisp is a very finicky package.) -- 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/M6R3KZ5F2KCVNOCIE4A5PUTNJKA6NXWE/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski wrote: > On 06/20/2018 02:30 PM, Petr Šabata wrote: > > Parallel installation of streams on a single system indeed > > isn't supported at this point and isn't planned anytime in the > > near future. In general it's a more complicated problem than > > it might seem at first. > > Could you elaborate and explain what's so complicated about it? > The short answer is that there exists no generic solution for parallel-installation. Many packages rely on well-known resources[1] and cannot be parallel-installed at all. Other packages *may* support parallel-installation but consumers must take special steps to enable support for it. I don't have a good link right now, but folks at Red Hat did a number of customer studies and determined that in real-world deployments, parallel-installation was very rarely used. Generally, the OS was established with a standard set of packages and then anything that needed an alternate version was deployed as a VM or container. So, when we started looking at ways to provide alternative software, we determined that parallel-installation was a non-goal. Not needing to solve an unsolvable problem meant that we could focus on the parts that really matter: allowing people to select which single version of the software meets their needs. [1] I can't install two packages that try to serve the same well-known D-BUS name or both provide a local DNS cache, for example. I can't install two packages that both own the same executable name without using the "alternatives" system. I can't install two versions of a package that provide a shared object plugin with the same name. And so on and so forth. All of these have possible solutions, but no single generic solution exists. In the general case, we figure that the triumvirate of modules, containers and VMs solves this problem for 99% of cases. The remaining exception cases have to be dealt with individually. ___ 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/QPBLGCRRG2XRV4GRKUGTL35CGM7KSYFX/
Fwd: Welcome to Fedora CoreOS
In case you missed this on the annouce list. Or also, read at https://fedoramagazine.org/announcing-fedora-coreos/ in glorious technicolor. - Forwarded message from Matthew Miller - > Date: Wed, 20 Jun 2018 10:00:00 -0400 > From: Matthew Miller > To: annou...@lists.fedoraproject.org > CC: cor...@lists.fedoraproject.org > Subject: Welcome to Fedora CoreOS > > > Hi everyone. If you saw my talk at DevConf.cz this year > (https://www.youtube.com/watch?v=CiCTTHoxv5c=890s), you’ll > remember I discussed the Fedora / Red Hat relationship, and > specifically how Fedora has historically worked with new > technologies that come our way through acquisitions made by our > primary sponsor. > > Little did I know, but at that very moment, something huge was in > the works, and when my plane landed back in Boston my phone blew up > with messages about CoreOS joining Red Hat. > > That’s obviously gigantic news, directly relevant to Fedora, since > we are the project Red Hat depends on for operating-system level > integration and innovation. Now, most of the news is about > Kubernetes, OpenShift, Tectonic, and Quay — but there’s also > Container Linux (the operating system formerly known just as > “CoreOS”). At Red Hat Summit, the company announced and clarified a > bunch of things around product and corporate plans. Now, it’s time > for us to figure out how we can welcome and include the Container > Linux community in the circle of Fedora Friends. > > > What does this mean for Fedora Atomic Host and other deliverables? > -- > > This isn’t the place for technical details — see “what next?” at > the bottom of this message for more. I expect that over the next > year or so, Fedora Atomic Host will be replaced by a new thing > combining the best from Container Linux and Project Atomic. This > new thing will be “Fedora CoreOS” and serve as the upstream to Red > Hat CoreOS. > > > What does this mean for the Fedora community? > - > > Good things! Container Linux is exciting, innovative, and has a > passionate user and developer community. The people who built it > are awesome and well-aligned with the Fedora community foundations. > > The “Fedora Editions” strategy intentionally makes space for > exploring emerging areas in operating system distributions. CoreOS > will help us push that even further and bring new ways of doing > things to the project as a whole. > > > What does this mean for Container Linux users? > -- > > More good things! I know this is kind of scary. Fedora CoreOS is > going to be built from Fedora content rather than in the way it’s > made now. It won’t necessarily be made in the same way we make > Fedora OS deliverables today, though. No matter what, we absolutely > want the CoreOS user experience of “container cluster host OS that > keeps itself up-to-date and you just don’t worry about it”. Again, > technical details are a discussion for elsewhere, but the goal is > for existing Container Linux users to be as happy as — or happier > than! — you are with the OS today. > > And here’s the super-important thing: Fedora really is a > community-driven project, and this means that you can get involved > and directly influence how the future Fedora CoreOS works to meet > your needs. If you’re interested and need help getting involved, > don’t hesitate to talk to me, to the Join Fedora team, or to the > developers and community people already working on the project. > > > Hey, so… “Fedora Core”! > --- > > Everything’s a circle, right? But, this has nothing to do with the > Red Hat vs. external split that was Fedora Core and Extras back in > the day. We absolutely do not want to regress to that kind of > community divide. “Core” just happens to be a pretty catchy name > component for an OS that fits the “small, focused base” concept. > This concept is powerful and useful for today’s information > technology and computing world, and we want to give it proper focus > in Fedora. > > > Okay, so, what next? > > > Visit the new website at https://coreos.fedoraproject.org/. > The project is just getting started, so there's not much there yet, > but we have an initial FAQ. > > If you have questions that aren't answered, or just want to get > involved, join in discussion on the new Discourse board > https://discussion.fedoraproject.org/c/coreos, sign up for the the > development mailing list at > https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/, > and chat on Freenode IRC in #fedora-coreos. > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > announce mailing list -- annou...@lists.fedoraproject.org > To unsubscribe send an email to announce-le...@lists.fedoraproject.org > Fedora Code of Conduct:
Re: F29 System Wide Change: Hide the grub menu
On Tue, Jun 19, 2018 at 11:55 PM Gerald B. Cox wrote: > The mcelog.service message is associated with rhbz#1166978 > The dbxtool.service message is associated with rhbz#1508808 > The rngd.service message is associated with rhbz#1490632 And abrt-xorg.service fails in some cases; see rhbz #1482230. -- 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/QP77WQ6VPAOE4D3EBUJPSG3NYS5UPLL6/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
On 06/20/2018 02:30 PM, Petr Šabata wrote: > Parallel installation of streams on a single system indeed > isn't supported at this point and isn't planned anytime in the > near future. In general it's a more complicated problem than > it might seem at first. Could you elaborate and explain what's so complicated about it? -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ 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/ZLLYSBTZSAFZP2YR4VYUPTVEKFZRQNY7/
[Bug 1590333] Upgrade perl-Image-ExifTool to 11.01
https://bugzilla.redhat.com/show_bug.cgi?id=1590333 --- Comment #1 from Fedora Update System --- perl-Image-ExifTool-11.01-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-42211e0a5b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7CB7Y7EDQ3GTT77344YXEEBF6ECASQL5/
[Bug 1590333] Upgrade perl-Image-ExifTool to 11.01
https://bugzilla.redhat.com/show_bug.cgi?id=1590333 --- Comment #2 from Fedora Update System --- perl-Image-ExifTool-11.01-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-42211e0a5b -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/DHRKTKRYSPIEU5RP6NC2SPNLKVLEBIIK/
[Bug 1589473] perl-MooX-Struct-0.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1589473 --- Comment #6 from Fedora Update System --- perl-MooX-Struct-0.017-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/V3KXYJLP5RSWUA65TADZMRHU7ISU46AY/
Re: F29 Self Contained Change: Origin 3.10
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Cc: devel-annou...@lists.fedoraproject.org > Sent: Wednesday, June 20, 2018 2:05:38 PM > Subject: Re: F29 Self Contained Change: Origin 3.10 > > > > On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik < jku...@redhat.com > wrote: > > > = Proposed Self Contained Change: Origin 3.10 = > https://fedoraproject.org/wiki/Changes/origin3.10 > > > Owner(s): > * Jakub Čajka > > > Rebase of the Openshift Origin package to the latest upstream version, > along with introduction of necessary infrastructure container images. > > > == Detailed description == > Rebase of the Origin package to the latest upstream release. To note > upgrade path from previous version (3.9) will not be covered by this > change(dnf update origin, will most certainly be unable to cleanly > update Origin cluster), any one interested in helping out with the > supportable update path please reach out to the change owner or any > origin maintainer. Upstream provided update ansible playbooks are > located at > https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades > > This sounds like a perfect use-case for a module. If `dnf update` cannot be > made safe on its own, then it might be best if it wasn't attempted as part > of the system upgrade, but was instead made into a module stream that users > could switch to at their convenience. > I think, with my rather limited knowledge of cluster migration, that it wouldn't make much difference in regards to the migration. You still need to migrate each node do the conversions, etc., but I haven't yet looked at in depth. I'm currently more focused on delivering bits that would actually enable us to run the cluster(solely on top of Fedora based images). I plan to focus more on this topic in F30 when we will have actually something to migrate. 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/message/BFRU5A36X64KURR3L6YAPNZS3FYFNLCV/ > ___ 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/QGMYZ7SWHRJOQLS7UQM3VS53KO3VF3YW/
[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80
https://bugzilla.redhat.com/show_bug.cgi?id=1550526 --- Comment #13 from Fedora Update System --- perl-Image-ExifTool-11.01-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f9bc440553 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JEDQU6AZPTRFBCOAPZTHQPRIFD36JXE6/
[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1592742 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #7 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2865b630c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/WIQK7W6WSI6PIMX67JWYEYLYG7AY74NR/
[Bug 1593043] perl-CPAN-Perl-Releases-3.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593043 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2865b630c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TJRI4IMBW5QJKSN7X4EKRBWMI6PQS4CK/
Re: F29 Self Contained Change: Origin 3.10
On Wed, Jun 20, 2018 at 8:44 AM Stephen Gallagher wrote: > > > > On Wed, Jun 20, 2018 at 8:21 AM Neal Gompa wrote: >> >> On Wed, Jun 20, 2018 at 8:07 AM Stephen Gallagher >> wrote: >> > >> > >> > >> > On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik wrote: >> >> >> >> = Proposed Self Contained Change: Origin 3.10 = >> >> https://fedoraproject.org/wiki/Changes/origin3.10 >> >> >> >> >> >> Owner(s): >> >> * Jakub Čajka >> >> >> >> >> >> Rebase of the Openshift Origin package to the latest upstream version, >> >> along with introduction of necessary infrastructure container images. >> >> >> >> >> >> == Detailed description == >> >> Rebase of the Origin package to the latest upstream release. To note >> >> upgrade path from previous version (3.9) will not be covered by this >> >> change(dnf update origin, will most certainly be unable to cleanly >> >> update Origin cluster), any one interested in helping out with the >> >> supportable update path please reach out to the change owner or any >> >> origin maintainer. Upstream provided update ansible playbooks are >> >> located at >> >> https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades >> > >> > >> > This sounds like a perfect use-case for a module. If `dnf update` cannot >> > be made safe on its own, then it might be best if it wasn't attempted as >> > part of the system upgrade, but was instead made into a module stream that >> > users could switch to at their convenience. >> >> You're making a huge assumption there. These days, I can generally >> assume it's a matter of not wanting to try in the first place. And >> modules don't improve the UX at all for this. The fact that no one has >> attempted to make this a safe upgrade process is irrespective of >> whether it's a normal RPM usable by all package managers or a module >> that's usable only by DNF. > > > The assumption that I'm making is that users won't necessarily want to remain > stuck on an older platform (such as an EOL Fedora) because the upgrade would > break their cluster. Modules provide an opportunity to at least provide a > stream of their current version and a stream of the newer version so that > they can update the platform without breaking their cluster. > I think in this case, parallel installable packages would actually make sense here. If the old system needs to be around for a data migration (and it can't do it automatically upon start of the OpenShift cluster services), then parallel installable packages need to be made so that users can do the transition while still being able to access the old version's data. > Of course, I may have been reading the original comment differently than > intended; it sounded like "upgrading with these packages installed may break > your cluster". If instead it was "after upgrading these packages, you must > run these ansible playbooks to update your cluster", that's a slightly > different story. But I'd want to know for sure that a simple `dnf update` > wouldn't break things. Sure, with this I agree too. I just wish people wouldn't cop out on handling upgrades, though... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2BSTLN4NRUPQCG4TDQFFJQ3W6URJU64F/
Re: F29 Self Contained Change: Origin 3.10
On Wed, Jun 20, 2018 at 8:21 AM Neal Gompa wrote: > On Wed, Jun 20, 2018 at 8:07 AM Stephen Gallagher > wrote: > > > > > > > > On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik wrote: > >> > >> = Proposed Self Contained Change: Origin 3.10 = > >> https://fedoraproject.org/wiki/Changes/origin3.10 > >> > >> > >> Owner(s): > >> * Jakub Čajka > >> > >> > >> Rebase of the Openshift Origin package to the latest upstream version, > >> along with introduction of necessary infrastructure container images. > >> > >> > >> == Detailed description == > >> Rebase of the Origin package to the latest upstream release. To note > >> upgrade path from previous version (3.9) will not be covered by this > >> change(dnf update origin, will most certainly be unable to cleanly > >> update Origin cluster), any one interested in helping out with the > >> supportable update path please reach out to the change owner or any > >> origin maintainer. Upstream provided update ansible playbooks are > >> located at > https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades > > > > > > This sounds like a perfect use-case for a module. If `dnf update` cannot > be made safe on its own, then it might be best if it wasn't attempted as > part of the system upgrade, but was instead made into a module stream that > users could switch to at their convenience. > > You're making a huge assumption there. These days, I can generally > assume it's a matter of not wanting to try in the first place. And > modules don't improve the UX at all for this. The fact that no one has > attempted to make this a safe upgrade process is irrespective of > whether it's a normal RPM usable by all package managers or a module > that's usable only by DNF. > The assumption that I'm making is that users won't necessarily want to remain stuck on an older platform (such as an EOL Fedora) because the upgrade would break their cluster. Modules provide an opportunity to at least provide a stream of their current version and a stream of the newer version so that they can update the platform without breaking their cluster. Of course, I may have been reading the original comment differently than intended; it sounded like "upgrading with these packages installed may break your cluster". If instead it was "after upgrading these packages, you must run these ansible playbooks to update your cluster", that's a slightly different story. But I'd want to know for sure that a simple `dnf update` wouldn't break things. ___ 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/MPSA5QHNYA2OJEEGKILAPIUQKEZS2LPU/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
On Wed, Jun 20, 2018 at 02:15:00PM +0200, Severin Gehwolf wrote:
> On Wed, 2018-06-20 at 07:59 -0400, Josh Boyer wrote:
> > On Wed, Jun 20, 2018 at 7:52 AM Severin Gehwolf wrote:
> > >
> > > Hi,
> > >
> > > I'm exploring the Fedora Modularity world and would like to know
> > > whether it's possible to have two different module streams install two
> > > different sets of packages? If that's possible, would installing one
> > > stream remove the packages from the other stream even though the set of
> > > packages don't overlap? I'm aware that it's not a goal of modularity to
> > > support parallel installability. But what if the packages themselves
> > > already allow parallel installability?
> > >
> > > Example:
> > >
> > > Module name: jdk
> > > Streams: 8, 11
> > >
> > > 1) "dnf module install jdk:8/default" installs these packages:
> > >
> > > java-1.8.0-openjdk
> > > java-1.8.0-openjdk-devel
> > > java-1.8.0-openjdk-headless
> > >
> > > 2) "dnf module install jdk:11/default" installs these packages:
> > >
> > > java-11-openjdk
> > > java-11-openjdk-headless
> > > java-11-openjdk-devel
> > >
> > > After 1) *and* 2) would I have both module streams' packages on my
> > > system? Would I have only the set from 2) with 1) removed?
> >
> > I think you would only have the set from 2.
> >
> > Parallel installation can't be done via streams, so it must be done at
> > the module level. So you'd have jdk8 and jdk11 modules, each with a
> > default stream. Given the default is specified, an installation would
> > look something like:
> >
> > "dnf module install jdk8; dnf module install jdk11"
>
> That's interesting, thanks!
>
> FWIW, I've tried the reverse :) I had jdk10 and jdk11 both specifying
> packages java-openjdk{,-devel,-headless} and the install of jdk11
> *upgraded* packages from the other (jdk10) module.
You could still do it with streams and simply encourage users
who need both to use containers, one with each stream stream
enabled :)
Parallel installation of streams on a single system indeed
isn't supported at this point and isn't planned anytime in the
near future. In general it's a more complicated problem than
it might seem at first.
P
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JUTS2VOQDBTNT4FDTPD6U4PIBSQDQ4QV/
Re: F29 Self Contained Change: Origin 3.10
On Wed, Jun 20, 2018 at 8:07 AM Stephen Gallagher wrote: > > > > On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik wrote: >> >> = Proposed Self Contained Change: Origin 3.10 = >> https://fedoraproject.org/wiki/Changes/origin3.10 >> >> >> Owner(s): >> * Jakub Čajka >> >> >> Rebase of the Openshift Origin package to the latest upstream version, >> along with introduction of necessary infrastructure container images. >> >> >> == Detailed description == >> Rebase of the Origin package to the latest upstream release. To note >> upgrade path from previous version (3.9) will not be covered by this >> change(dnf update origin, will most certainly be unable to cleanly >> update Origin cluster), any one interested in helping out with the >> supportable update path please reach out to the change owner or any >> origin maintainer. Upstream provided update ansible playbooks are >> located at >> https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades > > > This sounds like a perfect use-case for a module. If `dnf update` cannot be > made safe on its own, then it might be best if it wasn't attempted as part of > the system upgrade, but was instead made into a module stream that users > could switch to at their convenience. You're making a huge assumption there. These days, I can generally assume it's a matter of not wanting to try in the first place. And modules don't improve the UX at all for this. The fact that no one has attempted to make this a safe upgrade process is irrespective of whether it's a normal RPM usable by all package managers or a module that's usable only by DNF. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KKOSACJTYGLRDHW3LIFNJNQ6PKAPAASO/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
On Wed, 2018-06-20 at 07:59 -0400, Josh Boyer wrote:
> On Wed, Jun 20, 2018 at 7:52 AM Severin Gehwolf wrote:
> >
> > Hi,
> >
> > I'm exploring the Fedora Modularity world and would like to know
> > whether it's possible to have two different module streams install two
> > different sets of packages? If that's possible, would installing one
> > stream remove the packages from the other stream even though the set of
> > packages don't overlap? I'm aware that it's not a goal of modularity to
> > support parallel installability. But what if the packages themselves
> > already allow parallel installability?
> >
> > Example:
> >
> > Module name: jdk
> > Streams: 8, 11
> >
> > 1) "dnf module install jdk:8/default" installs these packages:
> >
> > java-1.8.0-openjdk
> > java-1.8.0-openjdk-devel
> > java-1.8.0-openjdk-headless
> >
> > 2) "dnf module install jdk:11/default" installs these packages:
> >
> > java-11-openjdk
> > java-11-openjdk-headless
> > java-11-openjdk-devel
> >
> > After 1) *and* 2) would I have both module streams' packages on my
> > system? Would I have only the set from 2) with 1) removed?
>
> I think you would only have the set from 2.
>
> Parallel installation can't be done via streams, so it must be done at
> the module level. So you'd have jdk8 and jdk11 modules, each with a
> default stream. Given the default is specified, an installation would
> look something like:
>
> "dnf module install jdk8; dnf module install jdk11"
That's interesting, thanks!
FWIW, I've tried the reverse :) I had jdk10 and jdk11 both specifying
packages java-openjdk{,-devel,-headless} and the install of jdk11
*upgraded* packages from the other (jdk10) module.
Cheers,
Severin
___
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/LZUNXJWVE5IUS2EULNZ7FXTKVBFJYWFT/
Re: F29 Self Contained Change: Origin 3.10
On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik wrote: > = Proposed Self Contained Change: Origin 3.10 = > https://fedoraproject.org/wiki/Changes/origin3.10 > > > Owner(s): > * Jakub Čajka > > > Rebase of the Openshift Origin package to the latest upstream version, > along with introduction of necessary infrastructure container images. > > > == Detailed description == > Rebase of the Origin package to the latest upstream release. To note > upgrade path from previous version (3.9) will not be covered by this > change(dnf update origin, will most certainly be unable to cleanly > update Origin cluster), any one interested in helping out with the > supportable update path please reach out to the change owner or any > origin maintainer. Upstream provided update ansible playbooks are > located at > https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades This sounds like a perfect use-case for a module. If `dnf update` cannot be made safe on its own, then it might be best if it wasn't attempted as part of the system upgrade, but was instead made into a module stream that users could switch to at their convenience. ___ 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/BFRU5A36X64KURR3L6YAPNZS3FYFNLCV/
F29 Self Contained Change: Origin 3.10
= Proposed Self Contained Change: Origin 3.10 = https://fedoraproject.org/wiki/Changes/origin3.10 Owner(s): * Jakub Čajka Rebase of the Openshift Origin package to the latest upstream version, along with introduction of necessary infrastructure container images. == Detailed description == Rebase of the Origin package to the latest upstream release. To note upgrade path from previous version (3.9) will not be covered by this change(dnf update origin, will most certainly be unable to cleanly update Origin cluster), any one interested in helping out with the supportable update path please reach out to the change owner or any origin maintainer. Upstream provided update ansible playbooks are located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades == Scope == * Proposal owners: rebase of the package, creation of the missing infrastructure container images * Other developers: N/A (not a System Wide Change) * Release engineering: None https://pagure.io/releng/issue/7581 ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: None (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/JWVK5CLUDKH43PMQIGPDCNCPX6BIOWHJ/
F29 Self Contained Change: Origin 3.10
= Proposed Self Contained Change: Origin 3.10 = https://fedoraproject.org/wiki/Changes/origin3.10 Owner(s): * Jakub Čajka Rebase of the Openshift Origin package to the latest upstream version, along with introduction of necessary infrastructure container images. == Detailed description == Rebase of the Origin package to the latest upstream release. To note upgrade path from previous version (3.9) will not be covered by this change(dnf update origin, will most certainly be unable to cleanly update Origin cluster), any one interested in helping out with the supportable update path please reach out to the change owner or any origin maintainer. Upstream provided update ansible playbooks are located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades == Scope == * Proposal owners: rebase of the package, creation of the missing infrastructure container images * Other developers: N/A (not a System Wide Change) * Release engineering: None https://pagure.io/releng/issue/7581 ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: None (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JWVK5CLUDKH43PMQIGPDCNCPX6BIOWHJ/
Re: [Modularity] Module streams with two different, non-overlapping, package sets?
On Wed, Jun 20, 2018 at 7:52 AM Severin Gehwolf wrote: > > Hi, > > I'm exploring the Fedora Modularity world and would like to know > whether it's possible to have two different module streams install two > different sets of packages? If that's possible, would installing one > stream remove the packages from the other stream even though the set of > packages don't overlap? I'm aware that it's not a goal of modularity to > support parallel installability. But what if the packages themselves > already allow parallel installability? > > Example: > > Module name: jdk > Streams: 8, 11 > > 1) "dnf module install jdk:8/default" installs these packages: > > java-1.8.0-openjdk > java-1.8.0-openjdk-devel > java-1.8.0-openjdk-headless > > 2) "dnf module install jdk:11/default" installs these packages: > > java-11-openjdk > java-11-openjdk-headless > java-11-openjdk-devel > > After 1) *and* 2) would I have both module streams' packages on my > system? Would I have only the set from 2) with 1) removed? I think you would only have the set from 2. Parallel installation can't be done via streams, so it must be done at the module level. So you'd have jdk8 and jdk11 modules, each with a default stream. Given the default is specified, an installation would look something like: "dnf module install jdk8; dnf module install jdk11" josh ___ 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/GOP2JOA6SE7YG4K3JV75VKT537ZZRP3Y/
Re: F29 System Wide Change: Hide the grub menu
On Wednesday, 20 June 2018 at 07:54, Gerald B. Cox wrote: [...] > The dbxtool.service message is associated with rhbz#1508808 Thanks to this, I checked my machine and filed: https://bugzilla.redhat.com/show_bug.cgi?id=1593258 because I'm seeing a different variation of yours. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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/AKOEZXPL237BSSSTAGN6B3476T7IOW4W/
[Modularity] Module streams with two different, non-overlapping, package sets?
Hi, I'm exploring the Fedora Modularity world and would like to know whether it's possible to have two different module streams install two different sets of packages? If that's possible, would installing one stream remove the packages from the other stream even though the set of packages don't overlap? I'm aware that it's not a goal of modularity to support parallel installability. But what if the packages themselves already allow parallel installability? Example: Module name: jdk Streams: 8, 11 1) "dnf module install jdk:8/default" installs these packages: java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless 2) "dnf module install jdk:11/default" installs these packages: java-11-openjdk java-11-openjdk-headless java-11-openjdk-devel After 1) *and* 2) would I have both module streams' packages on my system? Would I have only the set from 2) with 1) removed? Thanks for your help! Cheers, Severin ___ 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/HVNIBUTNINZM3E2TDZHJP2NGMVCYX6JJ/
Re: upcoming systemd-239 release — call for testing
On Di, 19.06.18 22:22, Adam Williamson (adamw...@fedoraproject.org) wrote: > On Mon, 2018-06-18 at 12:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi all, > > > > we plan to release systemd-239 wednesday-ish and it will be landing in > > rawhide. There's a bunch of new functionality, see > > https://github.com/systemd/systemd/blob/master/NEWS. As always, the > > majority of commits is cleanups and bugfixes and the polishing of > > existing functionality. A big new feature is "portable services", > > currently in preview mode. There are man pages, but an introductory > > blog story is planned around the time of the release, so you might > > want to wait for that. > > > > Please give it a try and report any bugs either in bugzilla [1] or > > upstream [2]. For testing, rpms are available from copr: > > https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768345/. > > Thanks for the heads up on this. I built a test Rawhide netinst image > with the updated systemd and ran it through openQA. It mostly worked, > but several of the tests failed with this error in anaconda: > > 22:13:42,713 INF threading: Thread Failed: AnaInstallThread (140332673541888) > 22:13:42,713 DBG exception: running handleException > 22:13:42,716 CRT exception: Traceback (most recent call last): > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > 843, in wrapped > ret = orig_obj(*args, **kwargs) > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > 465, in lvm_vgcreate > return _lvm_vgcreate(name, pv_list, pe_size, extra) > > GLib.GError: g-dbus-error-quark: Waiting for 'VgCreate' method of the > '/com/redhat/lvmdbus1/Manager' object to finish failed: Failed to get > Complete property of the / object: > GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with > signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist > (19) > > it seems like an intermittent error, as not all the tests that create > LVM VGs failed, and restarting the failed tests mostly resulted in > passes...but I don't think we've seen this particular error, even as an > intermittent one, in recent Rawhide tests with systemd 238, so it seems > like it *could* be caused by the update. Any idea where this may be > coming from? Hmm, this doesn't look like a systemd issue to me. This is a dbus method call failure of some form. The dbus client and the dbus service in this case are not provided by systemd, and neither is the dbus message bus in between. Hence systemd doesn't really insert itself in any form in the ongoing communication between this IPC client and server. That said, systemd is involved in service activation if the service isn't around yet at the time the client asks for the service. However, judging by the provided logs (https://openqa.stg.fedoraproject.org/tests/318564/file/_do_install_and_reboot-syslog) the activation of the lvmdbus1 service actually completes fine. Hence, this is somewhere between the message bus, and the LVM client and server. 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/QL7GBBIIF3C3E72G273DQHGFQRHTK2CI/
Re: gdbm reabase question
On Wed, Jun 20, 2018 at 11:49:38AM +0200, mskal...@redhat.com wrote: > Hi, > a new version of gdbm is out. So I would like to update gdbm in > Rawhide. > (Important note to my question is that gdbm is in minimal buildroot.) > > I've planned to do following (please correct me if I'm wrong it would > result in disaster): > 1. build compat-gdbm package with current content of gdbm package > 2. rebase gdbm package in rawhide (soname is changed!) and wait for > MassRebuild to rebuild other packages to rely back on gdbm instead > compat-gdbm > > > Question is: > Gdbm was also updated before F28 rebuild. But some packages failed to > build. So they still require compat-gdbm. > > $ dnf repoquery --alldeps --whatrequires compat-gdbm > clisp-0:2.49-22.20170224hg.fc26.i686 > clisp-0:2.49-22.20170224hg.fc26.x86_64 > compat-gdbm-devel-0:1.14-5.fc28.i686 > compat-gdbm-devel-0:1.14-5.fc28.x86_64 > ntop-0:5.0.1-15.fc28.x86_64 > perdition-0:2.1-7.fc26.i686 > perdition-0:2.1-7.fc26.x86_64 > > What to do? Is it fine to left these three packages as broken and > normally update gdbm? To just answer this part: yes, it is fine to ignore packages which FTBFS and are not critically important. We'll probably be retiring them if they continue to be unbuildable anyway. 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/message/VQJSBODZ7SO3JF53AR2AEO36IKHBDH3R/
gdbm reabase question
Hi, a new version of gdbm is out. So I would like to update gdbm in Rawhide. (Important note to my question is that gdbm is in minimal buildroot.) I've planned to do following (please correct me if I'm wrong it would result in disaster): 1. build compat-gdbm package with current content of gdbm package 2. rebase gdbm package in rawhide (soname is changed!) and wait for MassRebuild to rebuild other packages to rely back on gdbm instead compat-gdbm Question is: Gdbm was also updated before F28 rebuild. But some packages failed to build. So they still require compat-gdbm. $ dnf repoquery --alldeps --whatrequires compat-gdbm clisp-0:2.49-22.20170224hg.fc26.i686 clisp-0:2.49-22.20170224hg.fc26.x86_64 compat-gdbm-devel-0:1.14-5.fc28.i686 compat-gdbm-devel-0:1.14-5.fc28.x86_64 ntop-0:5.0.1-15.fc28.x86_64 perdition-0:2.1-7.fc26.i686 perdition-0:2.1-7.fc26.x86_64 What to do? Is it fine to left these three packages as broken and normally update gdbm? Thanks, Marek ___ 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/4N4TDMOPCJZO4UBGEFHA5UH5EAJKQG4R/
[Bug 1593045] perl-File-Find-Object-Rule-0.0309 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593045 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-File-Find-Object-Rule- ||0.0309-1.fc29 Resolution|--- |RAWHIDE Last Closed||2018-06-20 05:40:23 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=27747481 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/Q6QY5CBDHSGGPMG2WILJKXKPP6KAGF64/
Re: upcoming systemd-239 release — call for testing
On Tue, 2018-06-19 at 22:22 -0700, Adam Williamson wrote: > On Mon, 2018-06-18 at 12:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi all, > > > > we plan to release systemd-239 wednesday-ish and it will be landing in > > rawhide. There's a bunch of new functionality, see > > https://github.com/systemd/systemd/blob/master/NEWS. As always, the > > majority of commits is cleanups and bugfixes and the polishing of > > existing functionality. A big new feature is "portable services", > > currently in preview mode. There are man pages, but an introductory > > blog story is planned around the time of the release, so you might > > want to wait for that. > > > > Please give it a try and report any bugs either in bugzilla [1] or > > upstream [2]. For testing, rpms are available from copr: > > https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768345/. > > Thanks for the heads up on this. I built a test Rawhide netinst image > with the updated systemd and ran it through openQA. It mostly worked, > but several of the tests failed with this error in anaconda: > > 22:13:42,713 INF threading: Thread Failed: AnaInstallThread (140332673541888) > 22:13:42,713 DBG exception: running handleException > 22:13:42,716 CRT exception: Traceback (most recent call last): > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > 843, in wrapped > ret = orig_obj(*args, **kwargs) > > File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line > 465, in lvm_vgcreate > return _lvm_vgcreate(name, pv_list, pe_size, extra) > > GLib.GError: g-dbus-error-quark: Waiting for 'VgCreate' method of the > '/com/redhat/lvmdbus1/Manager' object to finish > failed: Failed to get Complete property of the / object: > GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method > "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" > doesn't exist > (19) > > it seems like an intermittent error, as not all the tests that create > LVM VGs failed, and restarting the failed tests mostly resulted in > passes...but I don't think we've seen this particular error, even as an > intermittent one, in recent Rawhide tests with systemd 238, so it seems > like it *could* be caused by the update. Any idea where this may be > coming from? Adding Vojta and Dave to CC to take a look at this. > > Here's one of the failed tests: > > https://openqa.stg.fedoraproject.org/tests/318564 > > all log files etc. can be found on the "Logs & Assets" tab. ___ 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/U6NTJFCZMHBSRYD5GKHX53W53S2WUL3G/
Re: F29 System Wide Change: Strong crypto settings: phase 2
On Wed, Jun 20, 2018 at 9:53 AM, Tom Hughes wrote: > On 20/06/18 09:46, Peter Robinson wrote: > >> There's also requirements by PCI (Payment Card Industry, not the >> interconnect tech) for sites doing financial transactions to be >> HTTP/1.1 and TLS 1.2 by June 30 too so no doubt that'll spur some >> sites forward too >> >> https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ > > > That appears to be incorrect though - only TLS 1.1 is required > from June 30 although 1.2 is strongly encouraged. See: > > https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls Maybe it's Paypal that's enforcing 1.2, it's purely a FYI, I don't care that much (more don't have the time to care that much because thankfully I don't currently have to deal with PCI-DSS) ___ 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/2SKLI63CUNBCMNPD4QW3KM4D3J7Q3SQA/
Re: F29 System Wide Change: Strong crypto settings: phase 2
On 20/06/18 09:46, Peter Robinson wrote: There's also requirements by PCI (Payment Card Industry, not the interconnect tech) for sites doing financial transactions to be HTTP/1.1 and TLS 1.2 by June 30 too so no doubt that'll spur some sites forward too https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ That appears to be incorrect though - only TLS 1.1 is required from June 30 although 1.2 is strongly encouraged. See: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J6FZVJ7OUOJJQ46ITTVPL5UXOKSEEW5L/
Re: F29 System Wide Change: Strong crypto settings: phase 2
>>> I don't think TLS 1.3 will see a wide deployment immediately. Sure, >>> the >>> famous top websites and top browsers will, but enterprises will not. >>> And >>> especially those with any kind of loggin/auditing requirements cannot >>> even allow TLS 1.3 with ephemeral DH on their network. >>> >>> I would personally first try and disable TLS 1.0 in f29 and see how >>> much >>> problems that generates. Then in f30 or f31 disable TLS 1.1. >> >> >> Except from the internet website statistics the TLS-1.1 only or as >> maximum TLS version is not deployed. The sites are either TLS-1.0 max >> version or they support also TLS-1.2. So this will not make almost any >> difference and the impact on compatibility will be practically the same >> as disabling even TLS-1.1. > > > Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1: > > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > > I guess it all depends on the lifetime of old cheap android devices :P There's also requirements by PCI (Payment Card Industry, not the interconnect tech) for sites doing financial transactions to be HTTP/1.1 and TLS 1.2 by June 30 too so no doubt that'll spur some sites forward too https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ ___ 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/BUCE6MPMCDQ6XBZX7UDWPV24X3PGL7YB/
[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1592742 --- Comment #6 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2865b630c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/W6KZGR6C3GTOCLXGE2JO6XOODZE4KD5V/
[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1592742 --- Comment #5 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8ce749bf40 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ECA5PXROKRLSZEOBUBP2KRZGKBR3PGKG/
[Bug 1593043] perl-CPAN-Perl-Releases-3.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593043 --- Comment #2 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2865b630c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/R5267V7QQUL4BPNWTXSSCLB2IUQEKE33/
[Bug 1593043] perl-CPAN-Perl-Releases-3.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593043 --- Comment #1 from Fedora Update System --- perl-CPAN-Perl-Releases-3.64-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8ce749bf40 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/EBXOVD2NJCAO34DKBZZGJOP7YPPQA6SV/
[Bug 1593043] perl-CPAN-Perl-Releases-3.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593043 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-CPAN-Perl-Releases-3.6 ||4-1.fc29 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/24WY4GKYJD3YHPX4ZQXUZRHB7OY2NO4G/
Re: Heads up: Python 3.7 rebuild in progress
On 20.6.2018 05:55, Jerry James wrote: fedpkg build --target=f29-python I have fixed python-pybtex, python-pybtex-docutils, python-latexcodec, python-sphinx-testing, and started a build of python-sphinxcontrib-bibtex which I think has a high chance of succeeding. Thank You. That should unblock the python-BTrees build, which in turn should unblock the rest of the ZODB/ZEO stack. Unfortunately this is blocked by failing: python-manuel https://koji.fedoraproject.org/koji/taskinfo?taskID=27740145 https://bugzilla.redhat.com/show_bug.cgi?id=1593132 python-trollius https://koji.fedoraproject.org/koji/taskinfo?taskID=27740570 https://bugzilla.redhat.com/show_bug.cgi?id=1593133 python-uvloop https://koji.fedoraproject.org/koji/taskinfo?taskID=27740603 https://bugzilla.redhat.com/show_bug.cgi?id=1556279 Or stuff that depends on those. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/XCZZRS3APHHD6FR4GLYKSJQQ7QAXTRW5/
Re: Heads up: Python 3.7 rebuild in progress
On 20.6.2018 05:55, Jerry James wrote: fedpkg build --target=f29-python I have fixed python-pybtex, python-pybtex-docutils, python-latexcodec, python-sphinx-testing, and started a build of python-sphinxcontrib-bibtex which I think has a high chance of succeeding. Thank You. That should unblock the python-BTrees build, which in turn should unblock the rest of the ZODB/ZEO stack. Unfortunately this is blocked by failing: python-manuel https://koji.fedoraproject.org/koji/taskinfo?taskID=27740145 https://bugzilla.redhat.com/show_bug.cgi?id=1593132 python-trollius https://koji.fedoraproject.org/koji/taskinfo?taskID=27740570 https://bugzilla.redhat.com/show_bug.cgi?id=1593133 python-uvloop https://koji.fedoraproject.org/koji/taskinfo?taskID=27740603 https://bugzilla.redhat.com/show_bug.cgi?id=1556279 Or stuff that depends on those. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XCZZRS3APHHD6FR4GLYKSJQQ7QAXTRW5/
[Bug 1593041] perl-BSON-v1.6.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593041 --- Comment #2 from Fedora Update System --- perl-BSON-1.6.5-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9f7f72ec78 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/3IJMDQRYF6YCQ3YU35RR3TFDMQCKNWIT/
[Bug 1591047] perl-BSON-v1.6.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1591047 --- Comment #4 from Fedora Update System --- perl-BSON-1.6.5-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9f7f72ec78 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ACXSWM2EBMF7AWREMO665B3BKENOTECZ/
[Bug 1593041] perl-BSON-v1.6.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1593041 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-BSON-1.6.5-1.fc29 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for Fedora ≥ 28. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/B46DYTZ6XPMPGGXIP2O5LKQUMC7URRSW/
F29 System Wide Change: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE
= Proposed System Wide Change: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE = https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition Owner(s): * Carlos O'Donell Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI. == Detailed description == IBM has designed a new long double ABI that adheres to the 128-bit IEEE format. This format is more standard than the existing AIX double-double or IBM long double (2 grouped 64-bit doubles) which has discontinuous mantissas and is difficult for developers to use. In Fedora 29 the plan is to switch to the new ABI for long double, while still supporting old applications via compatibility symbols. Newly compiled applications use either the old or new ABI but not a mix of both. Changes are required in the core C libraries, and the compiler and the compiler runtimes including the C++ standard libraries. Therefore there is coordination required across the core toolchain componenents e.g. gcc, binutils, glibc, gdb (to debug the new types). == Scope == The change is relatively limited in that not many packages use the long double floating point ABI. The double floating point ABI is much more used, but not long double. It is estimated that few packages use long double directly, and those packages will need to be rebuilt in order to use the new ABI. This rebuilding can be targetted by analyzing which packages have long double usage in their debug information and rebuilding just those packages. However, we plan to just use the existing mass rebuild for glibc 2.28 to handle this issue. * Proposal owners: Transition glibc to float128 format for long double for IBM ppc64le. Transition gcc to the default for long double. Ensure gdb can handle the new types. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 29 branch. * Release engineering: A mass rebuild request has been filed for the parent system-wide change to upgrade glibc to 2.28 #7475 [https://pagure.io/releng/issue/7475] ** List of deliverables [https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora29]: * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D6OUSOCG3T7TTGIF2NLAGZZJ6YXFLW7Q/
F29 System Wide Change: The GNU C Library version 2.28
= Proposed System Wide Change: The GNU C Library version 2.28 = https://fedoraproject.org/wiki/Changes/GLIBC228 Owner(s): * Carlos O'Donell Switch glibc in Fedora 29 to glibc version 2.28. == Detailed description == The GNU C Library version 2.28 will be released at the beginning of August 2018; we have started closely tracking the glibc 2.28 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 29 will branch after the GLIBC 2.28 upstream release. However, the mass rebuild schedule means Fedora 29 will mass rebuild (if required) just after GLIBC 2.28 upstream freezes ABI for release, so careful attention must be paid to any last minute ABI changes. This change also includes the following changes: * IBM POWER LE transition to Float128 for long double. [https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition] == Scope == * Proposal owners: Update glibc to 2.28 from tested upstream release. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 29 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated. * Release engineering: #7475 [https://pagure.io/releng/issue/7475]: The Fedora Toolchain team is responsible for ensuring that Fedora Rawhide stabilizes ABI before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by glibc or other components, the Fedora Toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of glibc to fix any last minute ABI changes. A mass rebuild is not required and this is communicated to release engineering. ** List of deliverables: * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XOFGJVTX3RSJALZ7HYATRIPPWCQQWLGA/
