m2crypto FTBFS, can we get the PR merged?
Hey, can we please get this fixed? https://bugzilla.redhat.com/show_bug.cgi?id=1606827 https://src.fedoraproject.org/rpms/m2crypto/pull-request/2 Neal Gompa volunteered to maintain the package. I've already tried to contact mitr privately a week ago, but no response. -- 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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bd4638e5a3 libmediainfo-18.12-3.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-009f5f140b php-horde-horde-5.2.21-1.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b9ea566899 php-horde-turba-4.2.24-1.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e406623fec bird-1.6.6-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dc3342b950 drupal7-7.66-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing libbgpdump-1.6.0-2.el6 Details about builds: libbgpdump-1.6.0-2.el6 (FEDORA-EPEL-2019-277ae80627) C library for analyzing BGP related dump files Update Information: Libbgpdump is a C library designed to help with analyzing BGP related dump files in Zebra/Quagga or MRT RIB (Multi-Threaded Routing Toolkit Routing Information Base) format, e.g. produced by Zebra/Quagga, BIRD, OpenBGPD or PyRT. References: [ 1 ] Bug #1702017 - Review Request: libbgpdump - C library for analyzing BGP related dump files https://bugzilla.redhat.com/show_bug.cgi?id=1702017 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-05-06 - 90% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/06/report-389-ds-base-1.4.1.2-20190505git8046842.fc29.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
Re: Enable dmarc mitigations
On Sunday, May 5, 2019 3:43:02 PM EDT stan via devel wrote: > On Sun, 5 May 2019 14:19:59 +0200 > Vitaly Zaitsev via devel wrote: > > Hello, qrsBRWN. > > > > Sun, 05 May 2019 10:57:06 +0200 you wrote: > > > > > Exactly what platform did you have in mind? > > > > Discourse[1] for example. GTK developers already testing it[2] as > > mailing lists replacement. > > > > 1: https://github.com/discourse/discourse > > 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/ [snip] > If forced to, I could probably use it, but I prefer the push model > to the pull model. That is, it isn't an improvement for me, it > doesn't buy me anything I want. +1 -- Garry T. Williams ___ 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
On GCL and libselinux
Awhile back, I mentioned that GCL was building in mock on my local machine, but was segfaulting on the koji builders. By dint of much experimentation, I now know what is going on. For the enlightenment of anybody who cares: - GCL is linked with libtirpc. - libtirpc is linked with libselinux. - libselinux has a "constructor" function, init_lib(), that runs before main(). - init_lib() calls init_selinuxmnt() - init_selinuxmnt() checks that /sys/fs/selinux exists, has type SELINUX_MAGIC (see statfs(2)), and is not read-only. In mock on my home machine, all of this is true, so execution stops there; the library is initialized. - On the koji builders, /sys/fs/selinux does exist, but is read-only, so it fails the test. The code then does the same check on /selinux, but that doesn't exist. Due to both failures, selinuxfs_exists() is called to see if the running kernel even knows about selinuxfs. - selinuxfs_exists() walks through the contents of /proc/filesystems. That walk involves calls to getline(), which calls malloc(), and free(). - GCL has its own definitions of malloc() and free(), but those definitions require that address randomization be turned off. GCL accomplishes this with a call to personality() early in main(), but the libselinux initializer runs before main(), resulting in GCL segfaulting in free(). So the issue isn't really mock on my machine vs. koji: it is systems where /sys/fs/selinux is mounted read-write versus those where it is mounted read-only or not mounted at all. One workaround is to invoke GCL at build time with setarch -R gcl , but that means any GCL users who do not have /sys/fs/selinux mounted read-write will have to do the same. I can't help but think that one should be very careful about what code is executed in an __attribute__((constructor)) function in a library, though. In particular, invoking malloc() and free() just doesn't seem like a great idea; there are lots of executables that use alternate malloc()/free() functions, so perturbing the heap before they have a chance to be set up can cause problems. In the case of libselinux, it seems to me that such invocations are not necessary, although I have not yet made the effort to code up a replacement. I will try to do that when I have a little free time. Sadly, even with the setarch workaround, gcl still fails to build due to a ppc64le-specific issue, which I have reported upstream. Hopefully a fix will be available soon. Regards, -- 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
Re: Upgrade to F30 gone wrong
Chris Murphy writes: In that case I expect that the rescue kernel+initramfs feature first appeared in dracut in Fedora 19, so that's the first time it would have noticed the pair are missing, and it would have created them at that time. But that's just a guess. This seems to be it. Two of my older BIOS systems, one still on F29, and one that's now on F30, both have a rescue image referencing Fedora 19 (the upgraded one referenced the rescue image in grub.cfg.rpmsave, pretty sure it still appears in the grub menu at boot time). pgp6bZcmMOYII.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 5:08 PM Sam Varshavchik wrote:
>
> Chris Murphy writes:
>
> > If you see the rescue kernel+initramfs menu entry though, you do not
> > have the bug under discussion, and you don't need to run
> > 'grub2-install' - your GRUB is by definition functioning fine if you
> > see this menu entry.
>
> I just inventoried my bricks. One, which has not been updated to F30 yet,
> features this in its default.cfg:
>
> menuentry 'Fedora 19 Rescue 929d17a456bf4083a935b6209da2ef46
> (3.9.8-300.fc19.x86_64)' --class fedora --class gnu-linux --class gnu --
> class os $menuentry_id_option 'gnulinux-simple-6a70e79b-78da-487a-acfe-
> dfba88996747' {
>
> So, it's a rescue from Fedora 19, which, from what I understand, is covered
> by the bug.
Only if all three are true:
a. It has BIOS firmware
b. grub2-install from Fedora 21 or newer has never been run on it
c. It has been upgraded to Fedora 30
That you can see this menu entry means one of those things is not
true; because the bug causes failure prior to menu entry parsing and
display.
>
> I have executed grub2-install manually on this machine, though, but I
> wouldn't expect it to figure out which release originally installed this
> kernel. And this machine was initially installed much, much earlier.
In that case I expect that the rescue kernel+initramfs feature first
appeared in dracut in Fedora 19, so that's the first time it would
have noticed the pair are missing, and it would have created them at
that time. But that's just a guess.
--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Chris Murphy writes:
If you see the rescue kernel+initramfs menu entry though, you do not
have the bug under discussion, and you don't need to run
'grub2-install' - your GRUB is by definition functioning fine if you
see this menu entry.
I just inventoried my bricks. One, which has not been updated to F30 yet,
features this in its default.cfg:
menuentry 'Fedora 19 Rescue 929d17a456bf4083a935b6209da2ef46
(3.9.8-300.fc19.x86_64)' --class fedora --class gnu-linux --class gnu --
class os $menuentry_id_option 'gnulinux-simple-6a70e79b-78da-487a-acfe-
dfba88996747' {
So, it's a rescue from Fedora 19, which, from what I understand, is covered
by the bug.
I have executed grub2-install manually on this machine, though, but I
wouldn't expect it to figure out which release originally installed this
kernel. And this machine was initially installed much, much earlier.
pgpCVcpxLpG8Y.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On Sun, May 5, 2019 at 8:22 AM Steven A. Falco wrote: > > I just upgraded my machine from F29 to F30. Now, whenever I install a new > kernel, the new kernel does not automatically become the default. In other > words, when I reboot, the previous kernel is still chosen by grub2. > > I can manually choose the new kernel in the grub2 menu, at which point it > _does_ become the new default. I don't wind up at the "grub>" prompt, so I > think grub2 itself is fine. It is just that the grubenv is not updated when > the new kernel is installed. > > The machine has UEFI, but the system boots using the legacy BIOS > compatibility layer. I know that the boot mechanism changed a bit for F30, > but I'm not sure where to look to identify the cause of this problem. It > doesn't seem to be the same issue as described in BZ 1652806. Post your /etc/default/grub file I'm willing to bet there's a line GRUB_SAVEDEFAULT=true If so, delete that line or comment it out and then run the usual grub2-mkconfig and directing the output to the proper grub.cfg path for your firmware type. The default that should be honored is found in the grubenv file, which (curiously) is found at the same path no matter your firmware type: /boot/efi/EFI/fedora/grubenv You can list its contents # grub2-editenv list And you can change it with #grub2-set-default The title of the kernel is found in the /boot/loader/entries/*conf files - there is one file for each kernel. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 10:45 AM Sam Varshavchik wrote: > > Steve Grubb writes: > > > Rescue mode? I couldn't find it. All references I could find to a rescue > > mode > > date back to 2013 or later. I would have liked a rescue mode because makes > > it > > easy to just chroot into your actual system from the livecd. Seems like > > we've > > lost something nice if its really been dropped. > > Somewhere around that era, installing Fedora added a grub menu entry for > "Rescue" mode. I don't remember exactly what it was supposed to rescue, and > how. > > It's been sitting in the grub menu ever since. > > I have a /boot/vmlinuz-0-rescue-f0fe67c2a80d43d2947358968ab5277e with a 2013 > timestamp. No idea which kernel it is. It appears to be immune to > installonly_limit. If you see the rescue kernel+initramfs menu entry though, you do not have the bug under discussion, and you don't need to run 'grub2-install' - your GRUB is by definition functioning fine if you see this menu entry. As for what it is, this is a copy of the original kernel installed at the time Fedora was installed by Anaconda. What makes it "rescue" is actually the "no host only" initramfs which is a kitchen sink initramfs that in theory will boot any hardware. The idea is, if you add new hardware and suddenly can't boot, it's likely because the normal "host only" initramfs doesn't have a kernel module for that new hardware; and you can use the "rescue" option as a fall back to boot, and then build a new initramfs for one of your newer kernels. And you're correct, it is never updated. I filed a bug/rfe for dnf system-upgrade about this some time ago, but got some push back on where such function really belongs. And actually it shouldn't be just any arbitrary kernel, ideally it'd be a reasonably well tested kernel perhaps the same one we actually release with. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 10:33 AM Steve Grubb wrote: > > I am thinking that something could have been put into dnf system-upgrade Impractical. That is a code change, it would need buy off from dnf folks, it would need translations (probably), it would need a freeze exception, it does not address the much more common upgrade path of GNOME Software (graphical upgrades). Keep in mind this bug was actually found rather late in the testing process. I only stumbled into it because someone said on #fedora-qa that ppc64le installs weren't booting in Open QA. And then we got suspicious that it might be an issue that could happen on x86/x86_64 if the GRUB core.img (stage 2) was too old, and then Javier narrowed it down. So there's a case where alternate architecture helped us catch a bug. There really aren't many users with very old installation that are doing beta testing, a lot of the tests and release requirements are in fact predicated on clean installs of the most recent two Fedora versions. > where it could have warned about the problem or did a workaround. Actually, > this could still be put into system-upgrade because not everyone switches > first week or two because they are waiting to see what problems people hit > before doing it themselves. Right and that's the same with beta testing, which is how bugs like this can sometimes not even get found until after release. A lot of tests are done on pristine systems that are throw away. It's entirely understandable few people want to test Fedora pre-release on their rock solid 5+ year old Fedora system, but we actually stumbled on this in some sense by luck of alternate arch acting like a canary. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 9:40 AM Nicolas Mailhot wrote: > Baring that, just having a reinstall bootloader option in rescue mode would > go a long way to make this all less a PITA. Fedora has been doing > incompatible bootloader changes every few years for as long as I remember GRUB 2 does not support bootloader reinstallation from the pre-boot environment. The GRUB rescue code is in the stage 2 bootloader. If you're at GRUB rescue, it means it can't read or can't find normal.mod which means it can't read anything else it would need to construct a stage 2 bootloader from scratch and install it. So this ship sailed with GRUB Legacy a very long time ago. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 5:45 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, May 04, 2019 at 01:35:32PM -0600, Chris Murphy wrote: > > The reason why this bug exists in my opinion is because we're being > > too accommodating to the technical users who want linux multiboot, and > > want Fedora to not step on their bootloader. I'm not convinced that's > > a very good policy anymore. I personally would flip it around and > > forcibly update the bootloader by assuming we own it, and if it turns > > out that's the wrong assumption the injured party is a technical user > > who should be familiar with linux mulit-boot madness and its esoteric > > work arounds. > > This makes the assumption, which was also made earlier in the thread, > that it's somehow impossible to check what bootloader is installed. > Why? My bootloader is happy to tell me its version: > $ bootctl Yes but this is out of scop for the conversation because your bootloader is UEFI, and the bug under discussion is BIOS. On BIOS, there are *three* common stage 1 bootloaders in common use on Linux distros, and there's no room for versioning or signatures in the 440 bytes available for this bootloader. The only way to know what we're dealing with, is to read and parse those 440 bytes, and find out where and what they jump to and then parse that stage 2 code. As an example of common: openSUSE uses (or at least used to, it's been a couple years since I checked this) the syslinux mbr.bin as their stage 1 bootloader, and they use GRUB as their stage 2 bootloader. As for version, GRUB has a version.mod but you have to be running GRUB in the pre-boot environment to run it. There is no checker for what is actually installed or who installed it. The facility doesn't exist. I don't know why. Considering there's maybe one downstream that provides an unmodified upstream, and everyone else provides heavily modified GRUB such that referencing an upstream version is pointless, you'd need a facility to inject a version+signature for the distribution's naming scheme to know what the installed binary actually is. And that includes Fedora, whose GRUB has hundreds of patches on top of upstream. > ... > Current Boot Loader: > Product: systemd-boot 241-565-g43d51bb > Features: ✓ Boot counting >✓ Menu timeout control >✓ One-shot menu timeout control >✓ Default entry control >✓ One-shot entry control > File: /EFI/systemd/systemd-bootx64.efi > ... > Nowadays it's gives the exact git commit it's built from, in the past > it was just the release version, but either is enough. Therefore > 'bootctl update' can fairly reliably *update*, i.e. do the installation > if the thing we have is newer than the version already installed. There's definitely no room for this in stage 1 bootloaders. There might be (I'm not sure) enough room to reference a package in the stage 2 bootloader, so that we know what distro and their version of the bootloader it is, at least know that it's not ours. But the ship has sailed. This capability needed to be in Fedora 5 years ago. > In case of grub and MBR things are a bit more involved, but I don't > think there's any significant technical limitation to doing the same > check and conditional installation. It is insufficient to check the stage 2 bootloader. You have to start at the beginning, LBA 0, and follow it just like the computer does. You can't work backwards. Both the 1MB MBR gap, and 1MB GPT BIOSBoot partition are big enough to contain multiple stage 2 bootloaders, and grub-install has a facility to avoid stepping on stage 2 bootloader in those locations if it can. So that stage 2 is written, and then it writes out a custom stage 1 bootloader in LBA 0 that tells the computer specifically what LBA to jump to in either the MBA gap or BIOS Boot partition. If you have a checker to look in those two locations, and it finds two or more stage 2 bootloaders, which one is the currently use one? You don't know. You have to read LBA 0 and parse it. Multiboot on BIOS was always this much of a clusterfuck. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, 05 May 2019 12:45:00 -0400 Sam Varshavchik wrote: > It's been sitting in the grub menu ever since. > > I have a /boot/vmlinuz-0-rescue-f0fe67c2a80d43d2947358968ab5277e with > a 2013 timestamp. No idea which kernel it is. It appears to be immune > to installonly_limit. From an old message thread, here are two ways to update to a current rescue kernel. > What's the proper way to get an appropriate F27 rescue kernel instead > of an F25 rescue kernel ? """ Delete (or move out of "/boot" the rescue kernel and initramfs. Run /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh f27_kern_ver /boot/f27_kern_img """ """ You delete the rescue initramfs from /boot. Then the next time you install a new kernel, it will create a new one. Possibly reinstalling the existing kernel would work as well. """ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable dmarc mitigations
On Sun, 5 May 2019 14:19:59 +0200 Vitaly Zaitsev via devel wrote: > Hello, qrsBRWN. > > Sun, 05 May 2019 10:57:06 +0200 you wrote: > > > Exactly what platform did you have in mind? > > Discourse[1] for example. GTK developers already testing it[2] as > mailing lists replacement. > > 1: https://github.com/discourse/discourse > 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/ To each their own, of course, but there was a long discussion of discourse here a while ago. I tried it out, but it was like a bad version of a mailing list. It sent me a mail informing me that there were messages to read. Then I had to go there and read the messages on the web, using their interface. So much better than just getting the message directly into my chosen mail client! (/sarcasm) It probably works well for those who are addicted to the web, and check their phone every few minutes; it fits with their work style, plus they get affirmation. But I don't fit that template, so I wasn't enamored. If forced to, I could probably use it, but I prefer the push model to the pull model. That is, it isn't an improvement for me, it doesn't buy me anything I want. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On 5/5/19 2:04 PM, Nico Kadel-Garcia wrote: > On Sun, May 5, 2019 at 10:22 AM Steven A. Falco wrote: >> >> I just upgraded my machine from F29 to F30. Now, whenever I install a new >> kernel, the new kernel does not automatically become the default. In other >> words, when I reboot, the previous kernel is still chosen by grub2. >> >> I can manually choose the new kernel in the grub2 menu, at which point it >> _does_ become the new default. I don't wind up at the "grub>" prompt, so I >> think grub2 itself is fine. It is just that the grubenv is not updated when >> the new kernel is installed. >> >> The machine has UEFI, but the system boots using the legacy BIOS >> compatibility layer. I know that the boot mechanism changed a bit for F30, >> but I'm not sure where to look to identify the cause of this problem. It >> doesn't seem to be the same issue as described in BZ 1652806. >> >> Steve > > It can be tricky for the grubby scripts to deduce which kernel was > *really* the last one, especially if you've been hand-editing kernel > entries or adding them manually, well, there might be debris. > > /boog/grub/ has gotten *fascinating* Perhaps you can back up the > system, and then delete *all* the extraneous kernels, to reset any > confused default tracking mechanism in place?. "Fascinating" is a good word for it. I tried reading through the various scripts. They are a twisty little maze of passages. :-) The problem has suddenly gone away. I just installed kernel 5.0.11, and this time it correctly became the default. I'm not sure what fixed my issue, but I can think of two possibilities. 1) Prior to installing 5.0.11, I did run the grub2-install command, as mentioned in the Common_F30_bugs wiki page. Perhaps that helped, even though my symptoms were very different. 2) Also, installing 5.0.11 obsoleted the last of the F29 kernels on my machine. Now there are only F30 kernels in /boot. I'll keep an eye on it, but for now I'm good. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1520948] Upgrade perl-Test-WWW-Mechanize-PSGI to 0.38
https://bugzilla.redhat.com/show_bug.cgi?id=1520948 Emmanuel Seyman changed: What|Removed |Added CC||emman...@seyman.fr External Bug ID||Github ||acme/test-www-mechanize-psg ||i/issues/7 --- Comment #5 from Emmanuel Seyman --- I submitted the issue upstream and the verdict is that this is not an error but a diagnostic message from the test. https://github.com/acme/test-www-mechanize-psgi/issues/7 -- 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
Re: Kernel upgrades
On Sun, May 5, 2019 at 10:22 AM Steven A. Falco wrote: > > I just upgraded my machine from F29 to F30. Now, whenever I install a new > kernel, the new kernel does not automatically become the default. In other > words, when I reboot, the previous kernel is still chosen by grub2. > > I can manually choose the new kernel in the grub2 menu, at which point it > _does_ become the new default. I don't wind up at the "grub>" prompt, so I > think grub2 itself is fine. It is just that the grubenv is not updated when > the new kernel is installed. > > The machine has UEFI, but the system boots using the legacy BIOS > compatibility layer. I know that the boot mechanism changed a bit for F30, > but I'm not sure where to look to identify the cause of this problem. It > doesn't seem to be the same issue as described in BZ 1652806. > > Steve It can be tricky for the grubby scripts to deduce which kernel was *really* the last one, especially if you've been hand-editing kernel entries or adding them manually, well, there might be debris. /boog/grub/ has gotten *fascinating* Perhaps you can back up the system, and then delete *all* the extraneous kernels, to reset any confused default tracking mechanism in place?. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sun, May 5, 2019 at 7:49 AM Roberto Ragusa wrote: > > On 5/4/19 10:50 PM, Sam Varshavchik wrote: > > One of my bricks that will soon get Fedora 30 was originally installed > with Fedora Core 4. > > > > Obviously a minority; but you'll be surprised to learn how many systems > there are which have been running Fedora for a very long time. Fedora 20 is > what, about five years old? There are many, many systems which are at least > five years old. People don't really swap hardware every 2-3 years, any more. > My contribution to the surprise: > > [root@localhost ~]# grep fedora-release /root/install.log > Installing fedora-release-3-8.i386. > [root@localhost ~]# uname -a > Linux localhost 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 > x86_64 x86_64 x86_64 GNU/Linux You're kind of begging for pain, at this point. Thee have been enough subtle, fundamental, and functionally incompatible updates to filesysems such as ext4 and xfs that a surprise at upgrade should not shock you too much. > This system was upgraded from Fedora 3 up to 29. > Also note it started as i386, but at Fedora 16 got transformed into x86_64, a > kind of (manual) upgrade never > officially considered possible. *Ouch*. OK, now you're just hurting yourself. Definitely time to back up your old system and do a fresh install. > I don't understand the consideration about old or new hardware. > Why would I have to reinstall the system when getting new hardware? > My Fedora system has jumped across 4 machines and who knows how many HDD/SDD > replacements. It Depends(tm). One issue I've encountered is with disk controllers. Anaconda is pretty good about detecting disk controllers at boot time and loading up initrd appropriately. on the new OS. Deducing the disk controller, the order of discovery of such controllers, and the tuning necessary to upgrade the OS reliably is an adventure. It also used to be worse when the file systems were referred to in /etc/fstab by their partition numbers, such as "/dev/sda1" which became "/dev/sde1" on the old Promise RAID controllers depending on which support patch they had applied. Ye *ghods*, I hated those controllers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Steve Grubb writes: Rescue mode? I couldn't find it. All references I could find to a rescue mode date back to 2013 or later. I would have liked a rescue mode because makes it easy to just chroot into your actual system from the livecd. Seems like we've lost something nice if its really been dropped. Somewhere around that era, installing Fedora added a grub menu entry for "Rescue" mode. I don't remember exactly what it was supposed to rescue, and how. It's been sitting in the grub menu ever since. I have a /boot/vmlinuz-0-rescue-f0fe67c2a80d43d2947358968ab5277e with a 2013 timestamp. No idea which kernel it is. It appears to be immune to installonly_limit. I wound up solving the problem by using the workstation livecd, mounting the /boot partition, and issuing the grub2-install command. This worked, but the https://fedoraproject.org/wiki/Common_F30_bugs#GRUB_boot_menu_is_not_populated_after_an_upgrade offers a more simple bandaid. Checking a "Common Fxx bugs" page before every upgrade has been a well- established ritual for quite some time. I am thinking that something could have been put into dnf system-upgrade where it could have warned about the problem or did a workaround. Actually, this could still be put into system-upgrade because not everyone switches first week or two because they are waiting to see what problems people hit before doing it themselves. That's what I suggested yesterday. pgp6Qzv2pHNvw.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sunday, May 5, 2019 11:39:50 AM EDT Nicolas Mailhot via devel wrote: > It would be nice to have a robust upgradeable bootloader setup. I'm pretty > sure that ranks before having a pretty flicker-free boot to Fedora users. > Pretty boot has been a workstation priority for how many releases now? > Baring that, just having a reinstall bootloader option in rescue mode would > go a long way to make this all less a PITA. Fedora has been doing > incompatible bootloader changes every few years for as long as I remember Rescue mode? I couldn't find it. All references I could find to a rescue mode date back to 2013 or later. I would have liked a rescue mode because makes it easy to just chroot into your actual system from the livecd. Seems like we've lost something nice if its really been dropped. I wound up solving the problem by using the workstation livecd, mounting the /boot partition, and issuing the grub2-install command. This worked, but the instructions are completely undocumented (searching from Google) as best as I can tell. There are docs for grub but not grub2. There are docs for Ubuntu which has a different boot disk layout but not for Fedora. Following the Ubuntu docs will not work. And speaking of which, seems like they have a disk boot repair iso. No idea how robust it is, but it is something. I am thinking that something could have been put into dnf system-upgrade where it could have warned about the problem or did a workaround. Actually, this could still be put into system-upgrade because not everyone switches first week or two because they are waiting to see what problems people hit before doing it themselves. Best Regards, -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
It would be nice to have a robust upgradeable bootloader setup. I'm pretty sure that ranks before having a pretty flicker-free boot to Fedora users. Pretty boot has been a workstation priority for how many releases now? Baring that, just having a reinstall bootloader option in rescue mode would go a long way to make this all less a PITA. Fedora has been doing incompatible bootloader changes every few years for as long as I remember -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help wanted to convert Archmage to Python 3
On Fri, May 3, 2019 at 11:36 PM Robert-André Mauchin
wrote:
> Hello,
>
> patool FTBFS depends on Archmage, which is Python 2 only.
> I'm trying to convert it to Python 3.
>
> So far I have the dependency pychm converted:
> https://copr.fedorainfracloud.org/coprs/eclipseo/pythontests/build/903162/
>
> Here's my Py3 port with 2to3 and minor fixes:
> https://github.com/eclipseo/archmage/tree/python3_port
>
> The problem is it doesn't work as expected:
>
> $ archmage -x t.chm
>
> Traceback (most recent call last):
> File "/usr/bin/archmage", line 11, in
> load_entry_point('archmage==0.3.1', 'console_scripts', 'archmage')()
> File "/usr/lib/python3.7/site-packages/archmod/cli.py", line 161, in main
> CHMFile(options.chmfile) or CHMDir(options.chmfile)
> File "/usr/lib/python3.7/site-packages/archmod/Cached.py", line 34, in
> __new__
> __instance = object.__new__(classtype, *args, **kwargs)
> TypeError: object.__new__() takes exactly one argument (the type to
> instantiate)
>
> I haven't touched archmod/Cached.py code, and as far as I know the
> object.__new__()
> method has not changed from Python 2 to Python 3 so I don't get why it's
> not
> working anymore.
> Can anyone with more Python chops help me?
>
I took a quick look:
- You'll probably have to update to beautifullsoup4 (shouldn't be too hard).
- Depends on python2-chm, we don't have a python3-chm in Fedora (Haven't
checked if it is supported).
Piotr
___
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
Fedora Rawhide-20190505.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 9/146 (x86_64), 1/2 (arm) ID: 396417 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/396417 ID: 396418 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/396418 ID: 396422 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/396422 ID: 396439 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/396439 ID: 396452 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/396452 ID: 396465 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/396465 ID: 396477 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/396477 ID: 396505 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/396505 ID: 396525 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/396525 ID: 396534 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/396534 Soft failed openQA tests: 3/24 (i386), 5/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 396425 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/396425 ID: 396426 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/396426 ID: 396437 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/396437 ID: 396444 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/396444 ID: 396445 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/396445 ID: 396449 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/396449 ID: 396533 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/396533 ID: 396535 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/396535 Passed openQA tests: 132/146 (x86_64), 21/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org 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
Kernel upgrades
I just upgraded my machine from F29 to F30. Now, whenever I install a new kernel, the new kernel does not automatically become the default. In other words, when I reboot, the previous kernel is still chosen by grub2. I can manually choose the new kernel in the grub2 menu, at which point it _does_ become the new default. I don't wind up at the "grub>" prompt, so I think grub2 itself is fine. It is just that the grubenv is not updated when the new kernel is installed. The machine has UEFI, but the system boots using the legacy BIOS compatibility layer. I know that the boot mechanism changed a bit for F30, but I'm not sure where to look to identify the cause of this problem. It doesn't seem to be the same issue as described in BZ 1652806. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable dmarc mitigations
On 5/4/19 11:04 PM, Vitaly Zaitsev via devel wrote: That's why it's time to deprecate all mailing lists and switch to modern Web 2.0 platforms. I swear I've intended this as a joke, before reading replies and realizing it was supposed to be serious. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190505.n.0 changes
OLD: Fedora-Rawhide-20190504.n.0 NEW: Fedora-Rawhide-20190505.n.0 = SUMMARY = Added images:8 Dropped images: 8 Added packages: 1 Dropped packages:0 Upgraded packages: 53 Downgraded packages: 0 Size of added packages: 426.45 KiB Size of dropped packages:0 B Size of upgraded packages: 1.22 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 4.81 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190505.n.0.iso Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190505.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190505.n.0.s390x.tar.xz Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20190505.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20190505.n.0.x86_64.vagrant-virtualbox.box Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20190505.n.0.iso Image: Games live i386 Path: Labs/i386/iso/Fedora-Games-Live-i386-Rawhide-20190505.n.0.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20190505.n.0.iso = DROPPED IMAGES = Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20190504.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190504.n.0-sda.raw.xz Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20190504.n.0.aarch64.raw.xz Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20190504.n.0.iso Image: Design_suite live i386 Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20190504.n.0.iso Image: Python_Classroom live i386 Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-Rawhide-20190504.n.0.iso Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190504.n.0-sda.raw.xz Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20190504.n.0.iso = ADDED PACKAGES = Package: libbgpdump-1.6.0-2.fc31 Summary: C library for analyzing BGP related dump files RPMs:bgpdump libbgpdump libbgpdump-devel Size:426.45 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: OpenImageIO-2.0.8-1.fc31 Old package: OpenImageIO-2.0.7-3.fc31 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 35.19 MiB Size change: 709.55 KiB Changelog: * Sat May 04 2019 Richard Shaw - 2.0.8-1 - Update to 2.0.8. Package: armadillo-9.400.3-1.fc31 Old package: armadillo-9.400.2-1.fc31 Summary: Fast C++ matrix library with syntax similar to MATLAB and Octave RPMs: armadillo armadillo-devel Size: 8.70 MiB Size change: 5.24 KiB Changelog: * Sat May 04 2019 Jos?? Matos - 9.400.3-1 - update to 9.400.3 Package: criu-3.12-7.fc31 Old package: criu-3.12-4.fc31 Summary: Tool for Checkpoint/Restore in User-space RPMs: crit criu criu-devel criu-libs python3-criu Size: 3.21 MiB Size change: 5.80 KiB Changelog: * Sat May 04 2019 Adrian Reber - 3.12-7 - Patch for socket labelling has changed upstream Package: device-mapper-persistent-data-0.8.1-1.fc31 Old package: device-mapper-persistent-data-0.8.0-1.fc31 Summary: Device-mapper Persistent Data Tools RPMs: device-mapper-persistent-data Size: 2.59 MiB Size change: 5.14 KiB Changelog: * Sat May 04 2019 Marian Csontos - 0.8.1-1 - Fix thin_repair should not require --repair option. Package: dhcp-12:4.4.1-12.fc31 Old package: dhcp-12:4.4.1-11.fc31 Summary: Dynamic host configuration protocol software RPMs: dhcp-client dhcp-common dhcp-compat dhcp-devel dhcp-devel-doc dhcp-libs-static dhcp-relay dhcp-server Size: 31.55 MiB Size change: 798.77 KiB Changelog: * Sat May 04 2019 Bj??rn Esser - 12:4.4.1-12 - rebuilt (bind) Package: fedpkg-1.37-1.fc31 Old package: fedpkg-1.36-2.fc30 Summary: Fedora utility for working with dist-git RPMs: fedpkg fedpkg-stage Size: 101.48 KiB Size change: 1.55 KiB Changelog: * Mon Apr 29 2019 Ondrej Nosek - 1.37-1 - Ignore files in a cloned repository - patterns (onosek) - Create env without --system-site-packages enabled to run flake8 (cqi) - Include possible distprefix in --define dist for Forge-based packages (zebob.m) - Revise shell completion for module scratch builds to require SRPMs to be specified individually using multiple '--srpm SRPM' options, and enable completion of modulemd file path by yaml
Re: Enable dmarc mitigations
Hello, qrsBRWN. Sun, 05 May 2019 10:57:06 +0200 you wrote: > Exactly what platform did you have in mind? Discourse[1] for example. GTK developers already testing it[2] as mailing lists replacement. 1: https://github.com/discourse/discourse 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On 5/4/19 10:50 PM, Sam Varshavchik wrote: > One of my bricks that will soon get Fedora 30 was originally installed with Fedora Core 4. > > Obviously a minority; but you'll be surprised to learn how many systems there are which have been running Fedora for a very long time. Fedora 20 is what, about five years old? There are many, many systems which are at least five years old. People don't really swap hardware every 2-3 years, any more. > My contribution to the surprise: [root@localhost ~]# grep fedora-release /root/install.log Installing fedora-release-3-8.i386. [root@localhost ~]# uname -a Linux localhost 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux This system was upgraded from Fedora 3 up to 29. Also note it started as i386, but at Fedora 16 got transformed into x86_64, a kind of (manual) upgrade never officially considered possible. I don't understand the consideration about old or new hardware. Why would I have to reinstall the system when getting new hardware? My Fedora system has jumped across 4 machines and who knows how many HDD/SDD replacements. Regards. -- Roberto Ragusamail at robertoragusa.it ___ 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
[Test-Announce] Fedora 31 Rawhide 20190505.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 31 Rawhide 20190505.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20190502.n.0: anaconda-31.10-1.fc31.src, 20190505.n.0: anaconda-31.11-1.fc31.src lorax - 20190502.n.0: lorax-31.3-1.fc31.src, 20190505.n.0: lorax-31.4-1.fc31.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/31 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190505.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sat, May 04, 2019 at 01:35:32PM -0600, Chris Murphy wrote: > On Sat, May 4, 2019 at 12:31 PM Sam Varshavchik wrote: > > > > Chris Murphy writes: > > > > > Actually, that's a problem too. The stale bootloader problem goes back > > > to an era where it was possible to install the bootloader into the > > > first sector of the boot partition, and in those cases, /dev/sda1 is > > > actually valid. And again, no practical way to discover this > > > automatically in advance. > > > > It would be useful to have dnf system-upgrade emit a "say, you may need to > > X first" message, before initiating a reboot, with an opportunity to bail > > out. Just like the existing message that tells you to update the current > > system first, before initiating an upgrade. > > The reminder to update the current system applies to everyone. Whereas > the mitigation for this bug is for specific configurations that the > plug-in can't test for, and for other configurations it's not good > advice. Suggesting UEFI users run 'grub2-install' will have two > possible outcomes: non-standard GRUB behavior if the command works; > and confusion if 'grub2-install' doesn't work because it isn't > present. Either way, it's bad advice because that's a bad UX. > > While handling this bug with a Common Bugs report is suboptimal, it > has long been expected that users should read Common Bugs before > installing or upgrading their systems. Making that advice more > prominent might be reasonable. > > > And, making this more generic, each new Fedora release could have a brief > > upgrade message tucked away in it, somewhere, that dnf system-upgrade could > > grab and show up front. > > As simple as it sounds, someone has to build that and maintain it, > from upstream down to Fedora. And Fedora also supports two upgrade > mechanisms, dnf system-upgrade, and GNOME Software. And I think it's > reasonable that such messages to user space need to follow > localization guidelines, so now those messages need translation. > That's a lot of work to do when, again, we're all supposed to read > Common Bugs. It's not any different on Windows or macOS who publish > release notes, if you're very lucky they report some gotchas, but they > never do that notification in the actual upgrade tool. There was the pre-upgrade tool (https://fedoraproject.org/wiki/How_to_use_PreUpgrade), but I don't think it ever went anywhere. IMHO, we just don't have the manpower to maintain such a tool in the face of the frequent releases and the myriad of possible installation styles and combinations of upgrade paths. For something more stable and limited and predictable like RHEL this might be possible, but I don't see it ever happening for Fedora. > The reason why this bug exists in my opinion is because we're being > too accommodating to the technical users who want linux multiboot, and > want Fedora to not step on their bootloader. I'm not convinced that's > a very good policy anymore. I personally would flip it around and > forcibly update the bootloader by assuming we own it, and if it turns > out that's the wrong assumption the injured party is a technical user > who should be familiar with linux mulit-boot madness and its esoteric > work arounds. This makes the assumption, which was also made earlier in the thread, that it's somehow impossible to check what bootloader is installed. Why? My bootloader is happy to tell me its version: $ bootctl ... Current Boot Loader: Product: systemd-boot 241-565-g43d51bb Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control File: /EFI/systemd/systemd-bootx64.efi ... Nowadays it's gives the exact git commit it's built from, in the past it was just the release version, but either is enough. Therefore 'bootctl update' can fairly reliably *update*, i.e. do the installation if the thing we have is newer than the version already installed. In case of grub and MBR things are a bit more involved, but I don't think there's any significant technical limitation to doing the same check and conditional installation. 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
[Bug 1706016] perl-Future-0.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1706016 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Future-0.40-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-05-05 08:58:23 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1262558 -- 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
[Bug 1705273] perl-Graphics-ColorNames-WWW-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1705273 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Graphics-ColorNames-WW ||W-1.14-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-05-05 08:57:38 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1262545 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Re: Enable dmarc mitigations
On May 4, 2019 11:04:51 PM GMT+02:00, Vitaly Zaitsev via devel wrote: >Hello, Stephen J. Turnbull. > >Sun, 5 May 2019 05:58:48 +0900 you wrote: > >> As a Mailman developer, I >> will strongly oppose turning on user choice by default because my >> constituents are list owners, not subscribers. But that implies it >> would be rarely available. > >That's why it's time to deprecate all mailing lists and switch to >modern >Web 2.0 platforms. Exactly what platform did you have in mind? While mailing lists aren't sexy they work very well and shuffle data like few other services. Br Q > >-- >Sincerely, > Vitaly Zaitsev (vit...@easycoding.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 ___ 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
