[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-7ff32fc746 podman-tui-0.15.0-2.el9 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b698d8c031 proftpd-1.3.8b-1.el9 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b300e89045 chromium-120.0.6099.129-1.el9 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-75bf3d635e xerces-c-3.2.5-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing latexmk-4.82-1.el9 rust-anyhow-1.0.77-1.el9 rust-clap_complete-4.4.5-1.el9 rust-crossbeam-0.8.3-1.el9 rust-crossbeam-channel-0.5.10-1.el9 rust-crossbeam-deque-0.8.4-1.el9 rust-crossbeam-epoch-0.9.17-1.el9 rust-crossbeam-queue-0.3.10-1.el9 rust-crossbeam-utils-0.8.18-1.el9 rust-ctrlc-3.4.2-1.el9 rust-fdeflate-0.3.3-1.el9 rust-futures-0.3.30-1.el9 rust-futures-channel-0.3.30-1.el9 rust-futures-core-0.3.30-1.el9 rust-futures-executor-0.3.30-1.el9 rust-futures-io-0.3.30-1.el9 rust-futures-macro-0.3.30-1.el9 rust-futures-sink-0.3.30-1.el9 rust-futures-task-0.3.30-1.el9 rust-futures-test-0.3.30-1.el9 rust-futures-util-0.3.30-1.el9 rust-minus-5.5.3-1.el9 rust-object-0.32.2-1.el9 rust-openssl-0.10.62-1.el9 rust-openssl-sys-0.9.98-1.el9 rust-proc-macro2-1.0.71-1.el9 rust-serde_bytes-0.11.13-1.el9 rust-serde_yaml-0.9.29-1.el9 rust-thiserror-1.0.52-1.el9 rust-thiserror-impl-1.0.52-1.el9 rust-unsafe-libyaml-0.2.10-1.el9 rust-winnow-0.5.31-1.el9 tomcli-0.5.0-2.el9 Details about builds: latexmk-4.82-1.el9 (FEDORA-EPEL-2023-3cc63cce5f) A make-like utility for LaTeX files Update Information: Changes in version 4.82: - Fixed various anomalies in working with biber, especially under error conditions. - Fixed various anomalies with use of `-bibtex-` and `-bibtex-cond` options. - Fixed problem that `-Werror` worked only with bibtex and not biber. (This is the option that causes latexmk to return a non-zero exit code to flag an error when there are missing-citation messages in the .log file.) - Added `-dir-report-only` option. - Fixed lack of quoting on command line to kpsewhich. - Implemented support for hilatex (`-hnt option`, `$hnt_mode` configuration variable). - Allow sleep times of under a second. (That gives very responsive performance on fast computers.) - Support `^^` format in .log file for non-ASCII bytes/characters. - Document `$filetime_causality_threshold` configuration variable. - Other documentation improvements. ChangeLog: * Tue Dec 26 2023 Jerry James - 4.82-1 - Version 4.82 References: [ 1 ] Bug #2255682 - latexmk-482 is available https://bugzilla.redhat.com/show_bug.cgi?id=2255682 rust-anyhow-1.0.77-1.el9 (FEDORA-EPEL-2023-9d32ce4b35) Flexible concrete Error type built on std::error::Error Update Information: Update to version 1.0.77. Update to version 1.0.76. ChangeLog: * Wed Dec 27 2023 Fabio Valentini - 1.0.77-1 - Update to version 1.0.77; Fixes RHBZ#2255941 * Thu Dec 21 2023 Fabio Valentini - 1.0.76-1 - Update to version 1.0.76; Fixes RHBZ#2255475 rust-clap_complete-4.4.5-1.el9 (FEDORA-EPEL-2023-e9ba7e3cb6) Generate shell completion scripts for your clap::Command Update Information: Update to version 4.4.5. ChangeLog: * Wed Dec 27 2023 Fabio Valentini - 4.4.5-1 - Update to version 4.4.5; Fixes RHBZ#2256013 rust-crossbeam-0.8.3-1.el9 (FEDORA-EPEL-2023-d0a2a4bb2b) Tools for concurrent programming Update Information: - Update the crossbeam crate to version 0.8.3. - Update the crossbeam-channel crate to version 0.5.10. - Update the crossbeam-deque crate to version 0.8.4. - Update the crossbeam-epoch
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/28/23 00:04, Samuel Sieb wrote: On 12/27/23 08:20, Sandro wrote: I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. You need to also update the initramfs using dracut or the modified mdadm.conf won't be available at boot. Ah, good point. I'll give that a shot tomorrow. For now I will have a good rest knowing that there's still something I haven't tried (correctly). ;) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 15:12, Samuel Sieb wrote:
On 12/27/23 06:05, Sandro wrote:
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
I have a similar issue that happened when I upgraded to F38.
I was wrong about the version. It must have started with F36 or F37
because it's currently on F38 and I was hoping the upgrade to F38 would
fix it. So probably not related to the issue of this thread.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 06:05, Sandro wrote:
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
I have a similar issue that happened when I upgraded to F38.
I have a mixed raid10 which is a 2 drive raid0 joined using raid1 with
an nvme partition. For some reason, only one of the raid0 partitions
gets put in the array automatically, so the boot fails. I have to
manually re-assemble the raid0 and then the rest gets automatically
assembled. There's also another raid1 array that doesn't have any issues.
I don't want to hijack this thread, so I'm not really asking for a
solution at this point. I'm just wondering if there was some change
starting in F38 that is causing weird raid issues like this. Maybe some
sort of timing or ordering issue?
My metadata is all 1.2, so it's not that.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 08:20, Sandro wrote: I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. You need to also update the initramfs using dracut or the modified mdadm.conf won't be available at boot. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 22:48, pgnd wrote: without seeing all the details, unfound superblocks aren't good. But isn't the information `mdadm --examine` prints coming from the superblock stored on the device? The magic number, that this command reports, matches what was expected (a92b4efc). I can access that information for each and every of the component devices. if you were assembling with the wrong metadata format, that'd be unsurprising. but, it sounds like these_were_ working for you at some point. Yes, they were working right until I upgraded from f37 to f39, which was mostly (actually only) hammering the SSD, which holds the root volume. if you're hoping to explore/identify/repair any damage, there's this for a good start, https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID this too, https://wiki.archlinux.org/title/RAID i'd recommend subscribing asking at, https://raid.wiki.kernel.org/index.php/Asking_for_help before guessing. a much better place to ask than here. even with good help from the list, i've had mixed luck with superblock recovery -- best, when able to find multiple clean copies of backup superblocks on the array/drives. -- worst, lost it all Thanks. I will ask for help on the mailing list. I actually got good hope since I'm able to manually assemble and access the data. But first I will do some reading up. given the change in behavior, and the older metadata, i'd consider starting fresh. wiping the array & disks, scanning/mapping bad blocks, reformatting & repartitioning, creating new arrays with lastest metadata, and restoring from backup. if you've still got good harwdare, should be good -- better than the uncertainty. yup, it'll take awhile. but, so might the hunt & repair process. Yeah. It's currently still on the bottom of my list. If all else fails, I will have no other option I guess. At moment I'm a bit torn apart between wanting to understand what's going and wanting to be able to use my system again. Going through all the information, I just discovered that the oldest of the arrays is close to ten years old and one of the disks has been part of the setup right from the start (Power_On_Hours: 80952). I've replaced disks whenever the need arose, never ran into trouble until now... Thanks for sparring! Whatever the outcome, I'll report here and on discussion. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
intent to hand over or orphan several scientific packages and their build requirements
Hello! I intend to hand over primary maintainership of the following packages or orphan them if nobody steps up: arpack chemtool cp2k elpa inchi python-colorspacious python-fypp python-GridDataFormats python-gsd python-kaitaistruct python-mmtf python-mrcfile python-Pympler tachyon wxmacmolplt xdrawchem I don't use them anymore, so I'm not a good maintainer for them. Most, if not all above, are co-maintained by SciTech SIG already. Please contact me if you want to take over one of these. Otherwise, I will orphan them in the first week of the new year. The packages are mostly in good shape, with the notable exceptions of cp2k and elpa, but there's an open PR for cp2k to update and fix current FTBFS. Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:36, Sandro wrote: I'll try with a F39 live ISO as well. If nothing else, it could confirm the issue to be with/in F39. I did that. Right after boot only one of the arrays was assembled. In /proc/mdstat is was listed as "active (auto-read-only)" and the component devices matched with what is known on my system as md54. No entry in the journal regarding any of the other arrays. No attempted assembly. Nothing. I stopped the array and ran `mdadm --assemble --verbose --scan --no-degraded` and all arrays were assembled without any issues. In the verbose output of the command `mdadm` told me: mdadm: No super block found on /dev/sda2 (Expected magic a92b4efc, got 6d746962) That was repeated for all the component devices of md1 and md5. For drives / partitions not being component devices it reported: mdadm: No super block found on /dev/sda1 (Expected magic a92b4efc, got ) instead. In contrast, about the component devices of md54, `mdadm` had the following to report: mdadm: /dev/sda4 is identified as a member of /dev/md/urras.penguinpee.nl:54, slot 0. This smells very much like something is off with the version 1.1 superblock. This being the only notable difference between arrays md1 and md5 and array md54. Yet, I have no clue as to what or what to do about it. :-\ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255994] perl-YAML-1.31 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255994 --- Comment #2 from Upstream Release Monitoring --- Created attachment 2006122 --> https://bugzilla.redhat.com/attachment.cgi?id=2006122=edit Update to 1.31 (#2255994) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255994 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255994%23c2 -- ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255994] New: perl-YAML-1.31 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255994 Bug ID: 2255994 Summary: perl-YAML-1.31 is available Product: Fedora Version: rawhide Status: NEW Component: perl-YAML Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.31 Upstream release that is considered latest: 1.31 Current version/release in rawhide: 1.30-16.fc39 URL: http://search.cpan.org/dist/YAML/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/3547/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-YAML -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255994 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255994%23c0 -- ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255994] perl-YAML-1.31 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255994 --- Comment #1 from Upstream Release Monitoring --- Scratch build failed. Details below: BuilderException: Build failed: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-t5efr8_l/perl-YAML.spec']' returned non-zero exit status 1. StdOut: setting SOURCE_DATE_EPOCH=1703635200 error: Bad file: ./YAML-free-1.31.tar.gz: No such file or directory RPM build errors: Bad file: ./YAML-free-1.31.tar.gz: No such file or directory Traceback: File "/usr/local/lib/python3.11/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) ^ File "/usr/local/lib/python3.11/site-packages/hotness/builders/koji.py", line 229, in build raise BuilderException( If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255994 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255994%23c1 -- ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:28, pgnd wrote: WAG? https://www.urbandictionary.com/define.php?term=wild%20ass%20guess ;) I should have guessed... I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. hm (1) are the mods explicitly in the initrd? Yes, they are. (2) can you boot from a usb key with a f39 live-iso and see if the arrays assemble? if they do, it's likely your config if they don't, the probs in the array itself (bad metadata, out of sync, etc ...) Well, I booted from a F38 USB everything ISO. It didn't assemble any of the arrays. But I was able to do so manually and subsequently mount one of the logical volumes on it readonly. I'd say that pretty much rules out a failure on the arrays. Two at the same time while a third is unaffected seems unlikely as well since they all share the same spinning metal underneath. It's not impossible. But, if so, I'd better buy myself a lottery ticket. ;) I'll try with a F39 live ISO as well. If nothing else, it could confirm the issue to be with/in F39. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:03, pgnd wrote: also make sure your drivers are in the initrd lsinitrd | grep -Ei "kernel/drivers/md/raid" -rw-r--r-- 1 root root10228 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid0.ko.xz -rw-r--r-- 1 root root35376 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid10.ko.xz -rw-r--r-- 1 root root26912 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid1.ko.xz -rw-r--r-- 1 root root90144 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid456.ko.xz I have raid0.ko.xz and raid456.ko.xz present in initrd. where, here, grep -i raid /etc/dracut.conf.d/99-local.conf add_dracutmodules+=" mdraid " add_drivers+=" raid0 raid1 raid10 raid456 " On my system /etc/dracut.conf.d/ is empty and /etc/dracut.conf only contains comments. Seeing that the required modules are in initrd, I suppose I don't need to spell them out explicitly. I suppose without the modules loaded I wouldn't be able to perform any MD operations at all. Thanks for the pointers, anyway. It helps in understanding how all these pieces fit together. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:10, pgnd wrote: If it works, I'd still wonder why md54 comes up fine. That entry is also missing `level` and `num-devices`. 1st WAG ? WAG? /dev/md/54 is 'just' raid1, without an atypical spare It's not. It's a raid5 without any spare just like md5. Only difference between the two is the metadata version, 1.1 vs. 1.2. And the partitions making up md54 have a bunch of additional entries like UUID_SUB as reported by `blkid`. More details in the discussion post. raid5 & raid1+spare are less common. whether autoassembly is smart enough to pick up the diffs without the explicit spec in /etc/mdadm.conf? again, dunno without trying. I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 16:47, pgnd wrote: i explicitly add the level= num-devices i've had issues long ago with mis-assembly that that cured. whether it's STILL a problem, i don't know; all my array spec contain contain these, and don't cause harm. it's now SOP here. i'd at least consider checking ... Sure. It's worth a try. Although, I've read that /etc/mdadm.conf is kinda obsolete. If it works, I'd still wonder why md54 comes up fine. That entry is also missing `level` and `num-devices`. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 15:14, pgnd wrote: what's the output of: mdadm -Es cat /etc/mdadm.conf # mdadm -Es ARRAY /dev/md/5 metadata=1.1 UUID=39295d93:e5a75797:b72287f3:51563755 name=urras.penguinpee.nl:5 ARRAY /dev/md/1 metadata=1.1 UUID=4a2c44b5:25f2a6c9:0e7f6cae:37a8a9cc name=urras.penguinpee.nl:1 spares=1 ARRAY /dev/md/54 metadata=1.2 UUID=fb919273:c6bfb891:ea1ca83c:0a8b3ad7 name=urras.penguinpee.nl:54 # cat /etc/mdadm.conf ARRAY /dev/md/5 metadata=1.1 name=urras.penguinpee.nl:5 UUID=39295d93:e5a75797:b72287f3:51563755 ARRAY /dev/md/54 metadata=1.2 name=urras.penguinpee.nl:54 UUID=fb919273:c6bfb891:ea1ca83c:0a8b3ad7 ARRAY /dev/md/1 metadata=1.1 spares=1 name=urras.penguinpee.nl:1 UUID=4a2c44b5:25f2a6c9:0e7f6cae:37a8a9cc MAILADDR root PROGRAM /usr/share/doc/mdadm/syslog-events -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 15:05, Sandro wrote:
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
The missing link:
[1]
https://discussion.fedoraproject.org/t/system-fails-to-boot-after-dnf-system-upgrade-due-to-missing-md-raid-devices/100218
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
Once upon a time, Beniamino Galvani said: > In practice, it's a bit more complex than that. network-online.target > is emitted after all NM connections succeed. The meaning of "success" > depends on properties "ipv4.may-fail" and "ipv6.may-fail" of the > connection profile. Normally they are both set to "yes" and this means > that just one of IPv4 and IPv6 is enough to reach the activated state. > > If the connection has static IPv4 addresses and "auto" IPv6 > (i.e. SLAAC plus optionally DHCPv6), before enabling ACD it was > guaranteed that IPv4 addresses were added before reaching > network-online. After enabling ACD, both IPv4 ACD and IPv6 SLAAC are > started in parallel and the first that completes will make the > connection succeed. However, in practice IPv6 also requires DAD and > the timeout is longer than the IPv4 ACD timeout; so, services that > bind to static IPv4 addresses can still rely on the addresses being > present after network-online.target is reached. > > Of course, in case of services that bind IPv4 to addresses, the best > solution is to set "ipv4.may-fail=no" (or for IPv6 addresses, > "ipv6.may-fail=no") in the connection profile. That is required when > using "auto" methods, in order to avoid the situation where the > connection succeeds after the "other" address family completes. Thanks for that detailed explanation! I had't seen that level of what network-online.target actually means. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Troubleshooting MD RAID assembly not working after upgrade to F39
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
Thank you,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255972] New: perl-Math-BigInt-GMP-1.6014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Bug ID: 2255972 Summary: perl-Math-BigInt-GMP-1.6014 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Math-BigInt-GMP Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.6014 Upstream release that is considered latest: 1.6014 Current version/release in rawhide: 1.6013-1.fc40 URL: https://metacpan.org/dist/Math-BigInt-GMP/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7529/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Math-BigInt-GMP -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255972%23c0 -- ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20231227.n.0 changes
OLD: Fedora-Rawhide-20231226.n.0 NEW: Fedora-Rawhide-20231227.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 5 Dropped packages:0 Upgraded packages: 34 Downgraded packages: 0 Size of added packages: 167.59 KiB Size of dropped packages:0 B Size of upgraded packages: 1.36 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 23.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231227.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231226.n.0.iso = ADDED PACKAGES = Package: python-argparse-dataclass-2.0.0-3.fc40 Summary: Declarative CLIs with argparse and dataclasses RPMs:python3-argparse-dataclass Size:19.53 KiB Package: python-conda-inject-1.3.1-1.fc40 Summary: Inject a conda environment into the current python environment RPMs:python3-conda-inject Size:18.03 KiB Package: python-snakemake-interface-common-1.15.0-1.fc40 Summary: Common functions and classes for Snakemake and its plugins RPMs:python3-snakemake-interface-common Size:47.44 KiB Package: rust-sscanf-0.4.1-1.fc40 Summary: Sscanf (inverse of format!()) Macro based on Regex RPMs:rust-sscanf+default-devel rust-sscanf-devel Size:74.61 KiB Package: zig-srpm-macros-1-1.fc40 Summary: SRPM macros required for Zig packages RPMs:zig-srpm-macros Size:7.98 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: accounts-qml-module-0.7^20231216.05e79eb-1.fc40 Old package: accounts-qml-module-0.7-10.fc39 Summary: QML bindings for libaccounts-qt + libsignon-qt RPMs: accounts-qml-module-doc accounts-qml-module-qt5 accounts-qml-module-qt6 Added RPMs: accounts-qml-module-qt5 accounts-qml-module-qt6 Dropped RPMs: accounts-qml-module Size: 759.91 KiB Size change: 309.80 KiB Changelog: * Tue Dec 26 2023 Alessandro Astone - 0.7^20231216.05e79eb-1 - Build git snapshot for both qt5 and qt6 - QML module renamed to SSO.OnlineAccounts Package: ark-24.01.85-1.fc40 Old package: ark-23.08.2-2.fc40 Summary: Archive manager RPMs: ark ark-libs Size: 6.90 MiB Size change: -124.44 KiB Changelog: * Mon Dec 25 2023 Marie Loise Nolden - 24.01.85-1 - 24.01.85 Package: bigloo-4.5b-1.fc40 Old package: bigloo-4.5a-4.1.fc40 Summary: A compiler for the Scheme programming language RPMs: bigloo bigloo-doc bigloo-libs Size: 71.49 MiB Size change: 18.94 MiB Changelog: * Tue Dec 26 2023 Jerry James - 4.5b-1 - Version 4.5b - Drop upstreamed configure-c99 and emacs29 patches Package: buildbot-3.10.1-1.fc40 Old package: buildbot-3.10.0-1.fc40 Summary: Build/test automation system RPMs: buildbot buildbot-master buildbot-master-container buildbot-master-ec2 buildbot-master-libvirt buildbot-master-openstack buildbot-worker buildbot-www Size: 4.78 MiB Size change: 1.56 KiB Changelog: * Tue Dec 26 2023 Gwyn Ciesla - 3.10.1-1 - 3.10.1 Package: dialect-2.2.0-1.fc40 Old package: dialect-2.1.1-5.fc40 Summary: A translation app for GNOME based on Google Translate RPMs: dialect Size: 524.12 KiB Size change: 280.39 KiB Changelog: * Tue Dec 26 2023 Lyes Saadi - 2.2.0-1 - Updating to 2.2.0 Package: doublecmd-1.1.8-1.fc40 Old package: doublecmd-1.1.7-1.fc40 Summary: Cross platform open source file manager with two panels RPMs: doublecmd-common doublecmd-gtk doublecmd-qt Size: 14.55 MiB Size change: 9.75 KiB Changelog: * Tue Dec 26 2023 Vasiliy N. Glazov - 1.1.8-1 - Update to 1.1.8 Package: doxygen-2:1.10.0-1.fc40 Old package: doxygen-2:1.9.8-1.fc40 Summary: A documentation system for C/C++ RPMs: doxygen doxygen-doxywizard doxygen-latex Size: 23.24 MiB Size change: 357.35 KiB Changelog: * Tue Dec 26 2023 Than Ngo - 1.10.0-1 - bz#2255826, update to 1.10 Package: dropbox-api-command-2.13-13.fc40 Old package: dropbox-api-command-2.13-11.fc38 Summary: Dropbox API wrapper command RPMs: dropbox-api-command Size: 26.24 KiB Size change: -422 B Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 2.13-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Dec 26 2023 Ben Boeckel - 2.13-13 - Fix manpages in filelists (rhbz#2189098) Package: functionalplus-0.2.22-1.fc40 Old package: functionalplus-0.2.20.p0-1.fc40 Summary: Functional Programming Library for C++ RPMs: functionalplus-devel Size: 104.19 KiB Size change: 431 B Changelog: * Tue Dec 26 2023 Pavel Solovev - 0.2.22-1 - Update to 0.2.22 Package: groonga-13.1.0-1.fc40 Old package: groonga-13.0.9-1.fc40 Summary: An Embeddable Fulltext
[Bug 2255963] New: perl-Math-BigInt-FastCalc-0.5016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255963 Bug ID: 2255963 Summary: perl-Math-BigInt-FastCalc-0.5016 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Math-BigInt-FastCalc Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.5016 Upstream release that is considered latest: 0.5016 Current version/release in rawhide: 0.501.500-1.fc40 URL: https://metacpan.org/dist/Math-BigInt-FastCalc/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/12782/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Math-BigInt-FastCalc -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255963 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255963%23c0 -- ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
On Thu, Dec 21, 2023 at 10:35:45AM -0600, Chris Adams wrote:
> Once upon a time, Beniamino Galvani said:
> > network-scripts do [1]:
> >
> > /sbin/arping -c 2 -w ${ARPING_WAIT:-3} -D -I ${REALDEVICE} ${ipaddr[$idx]}
> >
> > which waits 2 seconds by default.
>
> Ahh, sorry, that's what I get for depending on memory. :)
>
> > In the original RFC, the duration of the ACD process is between 4 and
> > 7 seconds (depending on randomization), which is clearly too long on
> > modern hardware.
>
> Definitely agree.
>
> > In the Fedora change proposal, the default ACD interval in NM is set
> > to up to 3 seconds and is subject to the same randomization; in
> > practice it would be between ~1.7 and 3 seconds. Perhaps that's still
> > too much, and we can safely decrease it to e.g. 1 second max to reduce
> > the activation delay.
>
> Yeah, I think sending 2-3 requests separated by maybe 0.2 seconds, and
> waiting another 0.2 seconds for a reply (so a total of 0.8 seconds) is
> sufficient for modern networks.
Right, by setting a maximum duration of e.g. 0.8 seconds, we get 3
probes spaced between 90ms and 270ms and a final wait time of 180ms,
according to the algorithm from RFC 5227.
> A number of DHCP servers do a ping
> before issue as well (although there's no good way for a DHCP client to
> tell), so it's just adding to the amount of time before the network
> becomes usable.
> DAD/ACD is a good thing, I'd just like to see the impact minimized. The
> time taken at boot is not a big deal (as users have to log in and start
> applications and such), but the time taken on resume from sleep is more
> noticable (open the notebook lid, unlock, then... wait).
>
> Thinking about servers... this would happen before network-online.target
> is triggered, right? Any services that try to bind to configured IPs or
> the like need to still work.
The short answer is: enabling ACD will not affect services that bind
to configured IPs, because ACD is done before the connection becomes
activated, which is a pre-requisite for network-online.target.
In practice, it's a bit more complex than that. network-online.target
is emitted after all NM connections succeed. The meaning of "success"
depends on properties "ipv4.may-fail" and "ipv6.may-fail" of the
connection profile. Normally they are both set to "yes" and this means
that just one of IPv4 and IPv6 is enough to reach the activated state.
If the connection has static IPv4 addresses and "auto" IPv6
(i.e. SLAAC plus optionally DHCPv6), before enabling ACD it was
guaranteed that IPv4 addresses were added before reaching
network-online. After enabling ACD, both IPv4 ACD and IPv6 SLAAC are
started in parallel and the first that completes will make the
connection succeed. However, in practice IPv6 also requires DAD and
the timeout is longer than the IPv4 ACD timeout; so, services that
bind to static IPv4 addresses can still rely on the addresses being
present after network-online.target is reached.
Of course, in case of services that bind IPv4 to addresses, the best
solution is to set "ipv4.may-fail=no" (or for IPv6 addresses,
"ipv6.may-fail=no") in the connection profile. That is required when
using "auto" methods, in order to avoid the situation where the
connection succeeds after the "other" address family completes.
Beniamino
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
