How to debug live CD image?
My desktop PC is happily running Fedora for years. Its on Fedora 32 now. It also has Windows 10 dual boot via Grub. But I cannot boot a live CD image as it gets stuck in "Monitoring of LVM2 mirrors, ...". This is not a new problem I have seen this for a couple of Fedora releases, but not reported it before. I have tested with both the Workstation image and the KDE spin image. Both get stuck at the same place. How do I go about debugging what is going on? Barry ___ 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
Re: Self-Introduction of Tanveer Salim and Notice on Implementation of KangarooTwelve
tsalim--- via devel wrote: > Hello! I am Tanveer Salim and am a Computer Engineering Student from Texas > Tech University. I am currently writing a standard user-space > implementation of KangarooTwelve. What is missing in this introduction is: what is KangarooTwelve? A search engine points me to: https://keccak.team/kangarootwelve.html which explains: | KangarooTwelve is a fast and secure extendable-output function (XOF), the | generalization of hash functions to arbitrary output lengths. Derived from | Keccak, it aims at higher speeds than FIPS 202's SHA-3 and SHAKE | functions, while retaining their flexibility and basis of security. Please keep in mind that you are talking here to a community of mostly distribution packagers, where not everybody is a crypto expert. Kevin Kofler ___ 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
Fedora-Cloud-31-20200524.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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://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
Fedora-Cloud-32-20200524.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 604095 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/604095 -- 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://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
user services run during system-upgrade
I raise this https://bugzilla.redhat.com/show_bug.cgi?id=1829799 with details that show that users sessions are started up and user services run during the dnf system-upgrade. This is clearly not a good idea. It has been triaged, but its not a RPM script issues as suggested. I'm not sure who should look at this, but feel that it should not be ignored. Barry ___ 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
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 24.05.20 um 11:49 schrieb Antonio Trande: > Can i include all dependent packages without related permissions? (i'm > not the maintainer of `R-argon2` `borgbackup` `gtkhash`) > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 Yes. Submitting an update does not require git-level permissions to commit changes. Here is what I'd like to see: 1. unpush the update 2. create tracking bugs for maintainers of dependent projects a) wait maybe a week or so for maintainers to submit a new build) b) if you don't get any response from a maintainer, please ask here for some provenpackager to trigger a build 3. create an update for libb2 + all dependent packages borgbackup: - EPEL 7 build is ready - In F31 I experienced strange test failures which only happen when doing "real" builds (all scratch builds work fine). I believe this is due to a flaky test suite but I will need some more days to investigate this. Maybe I will just disable the tests but I'm not yet sure. Felix ___ 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
Re: late generation of assemble code
Paul Dufresne via devel wrote: > Is there some technical problems for not packaging LLVM code rather than > CPU specific code? First of all, we would have to use LLVM to begin with. The preferred compiler in Fedora is GCC, not Clang. There are other technical concerns, but this one is the most obvious one. Kevin Kofler ___ 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
new packages review tickets
Hi all, now that we have new detailed statistics about new package review tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like to make some cleanings... at the time I'm writing, there are 517 tickets listed as new, many of them are older than 5 years! The first steps I would like to do, if FESCO and community agree, are: - some of these tickets are marked as "dependency rejected"; that means they depend on other package review tickets that were rejected, for whichever reason, so they will never get approved either. I would like to just close these (there are 3 tickets in this state) - following the Policy for stalled package reviews [1], I would like to mass comment on tickets submitted before 1/1/2017 (more than 3 years old) asking the submitter if they're still interested in continue with the review process and mark the ticket as NEEDINFO. After one month without reply I will close the ticket, as per policy. Then there are 352 tickets listed as "review in progress", but that's also not true. Here we have tickets with review-flag set to ? (review in progress) or + (package approved) since 2013. There are even some tickets for which the git repo as been generated. These tickets probably need a manual check to choose the best course of action. Some of those packages have been approved and imported in Fedora, some of these have been later retired also from repositories... but the review ticket has never been closed. I would propose to: - if the package got approved and it's still in repos, just close the review ticket as CURRENTRELEASE - if the package got approved and was later removed from repos, just close the review ticket as NOTABUG - if the package got approved before 1/1/2019, but never imported in repos, clear the review-flag and assignee and mark as NEEDINFO from the submitter asking if they're still interested in this (we probably need to decide what to do if the git repo has been already set up) - if the package got approved before 1/1/2020, but never imported in repos, do not clear the approval and mark as NEEDINFO from the submitter asking if they're still interested in this - for tickets with last change marked before 1/1/2019, if the review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from either the submitter or the reviewer Let me know if you agree (or disagree) with this proposal. Mattia [1] https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding ___ 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
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Can i include all dependent packages without related permissions? (i'm not the maintainer of `R-argon2` `borgbackup` `gtkhash`) https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Re: New package review tickets page last update on 2020-04-06
On Sun, May 24, 2020 at 2:17 PM Guido Aulisi wrote: > > Hi, > > the new package review tickets page [0] was last updated on 2020-04-06. > New tickets are not displayed, I made a new review request on April 19 > and it never appeared on that page > > Is there anything not working on auto updating that page? I think you're looking at the URL for the "old" page. It was recently rewritten: Overview: https://fedoraproject.org/PackageReviewStatus/ New tickets: https://fedoraproject.org/PackageReviewStatus/reviewable.html Fabio > Ciao > Guido > FAS: tartina > > [0]: https://fedoraproject.org/PackageReviewStatus/NEW.html > ___ > 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 ___ 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
New package review tickets page last update on 2020-04-06
Hi, the new package review tickets page [0] was last updated on 2020-04-06. New tickets are not displayed, I made a new review request on April 19 and it never appeared on that page Is there anything not working on auto updating that page? Ciao Guido FAS: tartina [0]: https://fedoraproject.org/PackageReviewStatus/NEW.html signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Re: How to debug live CD image?
On 24.05.2020 11:47, Barry Scott wrote: > I have tested with both the Workstation image and > the KDE spin image. Both get stuck at the same place. Can you check latest respins[1]? [1]: https://dl.fedoraproject.org/pub/alt/live-respins/ -- 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://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
Re: new packages review tickets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-05-24 at 08:02 +, Mattia Verga via devel wrote: > Hi all, Hey, > now that we have new detailed statistics about new package review > tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would > like > to make some cleanings... at the time I'm writing, there are 517 > tickets > listed as new, many of them are older than 5 years! > > The first steps I would like to do, if FESCO and community agree, > are: > > - some of these tickets are marked as "dependency rejected"; that > means > they depend on other package review tickets that were rejected, for > whichever reason, so they will never get approved either. I would > like > to just close these (there are 3 tickets in this state) > - following the Policy for stalled package reviews [1], I would like > to > mass comment on tickets submitted before 1/1/2017 (more than 3 years > old) asking the submitter if they're still interested in continue > with > the review process and mark the ticket as NEEDINFO. After one month > without reply I will close the ticket, as per policy. > > Then there are 352 tickets listed as "review in progress", but > that's > also not true. Here we have tickets with review-flag set to ? (review > in > progress) or + (package approved) since 2013. There are even some > tickets for which the git repo as been generated. > These tickets probably need a manual check to choose the best course > of > action. Some of those packages have been approved and imported in > Fedora, some of these have been later retired also from > repositories... > but the review ticket has never been closed. > I would propose to: > > - if the package got approved and it's still in repos, just close > the > review ticket as CURRENTRELEASE > - if the package got approved and was later removed from repos, just > close the review ticket as NOTABUG > - if the package got approved before 1/1/2019, but never imported in > repos, clear the review-flag and assignee and mark as NEEDINFO from > the > submitter asking if they're still interested in this (we probably > need > to decide what to do if the git repo has been already set up) > - if the package got approved before 1/1/2020, but never imported in > repos, do not clear the approval and mark as NEEDINFO from the > submitter > asking if they're still interested in this > - for tickets with last change marked before 1/1/2019, if the > review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO > from > either the submitter or the reviewer > > Let me know if you agree (or disagree) with this proposal. This is great idea! If you need any help with bugzilla API or anything like that - let me know. > Mattia > > [1] > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7KeaAACgkQEV1auJxc Hh7O/A/8DPCzwNG6prT4/As94YOYPLrwBcS7qjC0FZZlB3Edw/8MifqqNJHSzk2W 032w3eHxpUuHkgBW+tl6cAC2YdypaxkApwRHCQE/jJMUNDG3Xb7tg3qr8HNeHeho kdeVIkt8mBhGIPWT57EBXwAUm5Erl6nqrcqTpyTdh3QMGmB4KxNymzOY8I3NZpZA OKLZL2zgq2/0YN6jcgZoRSp+eLM3Nvtq/lyDRn2/zaXb6G7OT4XnCa4H1W9wMBYa IZmEB0n+LZFKnE7ypi7NWZnNaXzwhRMllEaO96H1f188NJoEsSIfFgZZpJQCfzXc 8LF0Gkqz5E+6Qw0vaQrfuLkWiGvsmdSMG3MduSNWkt2ts1qvgZFbr1YAnC7Znawd muycIFOgGhH8RK68ojmUrdbTHF3jzsbW6Uusjt9k5bwmYfLtYSGSWfpE8VAxLOyy HVBjM6AEWSVupcZSeTuDKIGvWX6l2jyjJY+6ltIEg5DrIAnm+7u49hkwGeX1KOws xmbQ1ZP6WoWc8cffH6xaQJgy+Eosfnm0bxtXHU/ZsbIv01aAa9KiCuBquGP5evOf EwEAXY78/V2SwVVCSOsq6kAPqx0+r81+dTIAWU6iIPB4VJJeiwAAV+h+kOn7VuQL NpEPzO9GOxPYhSy+x0UXIjx+LKLAD4Oi772YHr3iTfpkxEy2QKg= =itvp -END 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
Fedora-Cloud-30-20200524.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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://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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 5:07 PM Paul Dufresne via devel wrote: > > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, it > must, on a new disk formatted in GPT, end up with an entry in fstab for an > ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. This > placeholder file system shall be determined during installation time, and an > fstab entry for it shall be created mounting it to /boot." In practice, Fedora's implementation is closer in some respects to this variant of the spec: https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ > "if the OS is installed on a disk with GPT disk label, and no ESP partition > exists yet, a new suitably sized (let's say 500MB) ESP should be created and > should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific /boot/efi that > it make ESP. To follow BLS, it should be /boot that is the ESP partition... > and I see no point to define an other /boot/efi partition to be mounted on > /boot. Correct. Fedora went with a hybrid approach, rather than fully conforming to (either) spec. So in practice, it's an implementation without a spec. But that happens with web standards and various other specs too so it's not remarkable in that sense, even if it's confusing. > "$BOOT must be a VFAT (16 or 32) file system. Other file system types should > not be used. Applications accessing $BOOT should hence not assume that > fancier file system features such as symlinks, hardlinks, access control or > case sensitivity are supported." Yeah it's difficult to cover all possible use cases this way, and the spec itself doesn't try to cover them. One of those that is still worse on UEFI, is the inability to support redundant boot with two drives. There needs to be some service or daemon that syncs the EFI System partitions on each drive, and software raid inadequately addresses the concerns, and creates new ones and for that md/mdadm upstream folks have consistently opposed such implementations and yet they exist and are as fragile as expected. Another problem is FAT isn't atomic so while it's possible to do rename atomically at the VFS level, it's not atomic on FAT so if you need such a guarantee when modifying the ESP, FAT leaves the door open (however small) to boot failure following a crash during an update of the ESP. I'm not sure how Windows solves this, or even if it does. Apple solves it by not not using the ESP for booting at all, they use an EFI file system driver so that the pre-boot environment can read APFS, and as that's a COW file system, all kernel and boot related updates happen atomically by design. -- 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://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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 7:48 PM James Cassell wrote: > > > On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > > wrote: > > > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > > > The change record for this states that we are not following the BLS at > > > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > > > the proposed update at > > > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > > > > > Thanks for remembering me this alternative specification! > > > > > > That said, Fedora does not seems to follow this alternative spec, > > > because we use: > > > > > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > > > indicated in this standard. > > > > > > The point is that as the $BOOT is shared among distributions, there must > > > be a way to detect if it is already there, to be able to re-use it. For > > > that, the specification (whatever the exact version if chosen) must be > > > relatively well followed. > > > > Yep. > > > > But an additional difficulty to fully implementing the spec is so far > > upstream GRUB don't want to follow it. So that means Fedora has to > > carry patches for GRUB to support it. And it's just yet another of > > 100+ patches Fedora carries for GRUB, and makes it difficult for the > > Fedora and RH boot teams. The resources so far implement some of the > > parts of BLS that help make things better on Fedora, but it's not a > > complete implementation. Drop-in snippets to add new kernels is crash > > safe, worst case the previous kernel is booted and you just reinstall > > the kernel; but writing out a new grub.cfg or modifying it, wasn't > > ever crash safe. Also, modifying the snippets is easier, they're just > > a few lines and fairly self-describing compared to what users often > > did, which was wade neck deep into editing grub.cfg. Or the Rube > > Goldberg machine that is editing /etc/default/grub, running a script > > (grub-mkconfig), which then runs 20 other scripts to create a > > configuration file that is actually a script. > > > > Even so, isn't the canonical way of persistently updating kernel args, still, > to edit /etc/default/grub and run the script? (If not, are there docs for the > new way?) It does still work, but by indirection. You set it in /etc/default/grub but grub2-mkconfig puts it into grub.cfg first and then it goes into grubenv. The grubenv variables are loaded by GRUB at boot time, and the BLS snippets reference those variables. I've resorted to using 'grub2-editenv' to directly modify grubenv. But as grubenv is fragile, using it will be abandoned. -- 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://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
Re: Does the installer detects when a distro have already created BLS?
The change record for this states that we are not following the BLS at https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but the proposed update at https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . It is not clear however if everyone has moved to the new spec or whether they are now competing specs. On Mon, 25 May 2020 at 00:27, James Cassell wrote: > > On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote: > > Well... I will try to repeat more clearly my claim: > > > > If Fedora want to pretend to implement the Boot Loader Specification, > > it must, on a new disk formatted in GPT, end up with an entry in fstab > > for an ESP partition mounted on /boot: > > > > "These directories are defined below the placeholder file system $BOOT. > > This placeholder file system shall be determined during installation > > time, and an fstab entry for it shall be created mounting it to /boot." > > > > ... > > > > "if the OS is installed on a disk with GPT disk label, and no ESP > > partition exists yet, a new suitably sized (let's say 500MB) ESP should > > be created and should be used as $BOOT" > > > > This is the rule you are supposed end up to follow for an empty GPT > partition. > > > > And for now, the installer seems to make you define a specific > > /boot/efi that it make ESP. To follow BLS, it should be /boot that is > > the ESP partition... and I see no point to define an other /boot/efi > > partition to be mounted on /boot. > > > > I agree with your assessment and am also confused about the discrepancy > between BLS documentation and Fedora's implementation. > > > V/r, > James Cassell > > > ... > > > > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types > > should not be used. Applications accessing `$BOOT` should hence not > > assume that fancier file system features such as symlinks, hardlinks, > > access control or case sensitivity are supported." > > > > > > > ___ > 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 > ___ 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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote: > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, > it must, on a new disk formatted in GPT, end up with an entry in fstab > for an ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. > This placeholder file system shall be determined during installation > time, and an fstab entry for it shall be created mounting it to /boot." > > ... > > "if the OS is installed on a disk with GPT disk label, and no ESP > partition exists yet, a new suitably sized (let's say 500MB) ESP should > be created and should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific > /boot/efi that it make ESP. To follow BLS, it should be /boot that is > the ESP partition... and I see no point to define an other /boot/efi > partition to be mounted on /boot. > I agree with your assessment and am also confused about the discrepancy between BLS documentation and Fedora's implementation. V/r, James Cassell > ... > > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types > should not be used. Applications accessing `$BOOT` should hence not > assume that fancier file system features such as symlinks, hardlinks, > access control or case sensitivity are supported." > > > ___ 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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 11:21 AM Paul Dufresne via devel wrote: > > Well... it take time to me to get used to the Boot Loader Specification. > > I am being lazy here... asking people on the mailing list rather than trying > to determine it myself. > > After making an installation of Fedora, I begin to think: > > Hey, I don't remember having seen the installer like detecting the use of a > previously installed /boot and/or /boot/efi partition, and tells me that it > will automatically use it by default. Fedora isn't following the Boot Loader Spec exactly in all ways. The installer doesn't support BLS with respect to $BOOT type codes: either EFI System partition or the Extended Boot partition. > But since with Boot Loader Specification, these are supposed to be shared > among distribution (maybe more likely a recent Fedora version with an older > Fedora version), it make sense that it should happens. Maybe I did not seen > it because I tend to erase the disk and begin from scratch. You didn't miss it. Fedora hasn't committed to it fully. What it's mostly committed to are the BLS snippets, those are the individual drop-in files that describe a boot entry to be displayed by GRUB. There is also currently the use of variables stored in grubenv, referenced by the BLS snippets, which isn't in the actual spec. That's going away in F33, such that the BLS snippets completely describe the boot entry details, i.e. are self-contained. > "These directories are defined below the placeholder file system $BOOT. This > placeholder file system shall be determined during installation time, and an > fstab entry for it shall be created mounting it to /boot. The installer > program should pick $BOOT according to the following rules: > > If the OS is installed on a disk with MBR disk label, and a partition with > the MBR type id of 0xEA already exists it should be used as $BOOT. > Otherwise, if the the OS is installed on a disk with MBR disk label, a new > partition with MBR type id of 0xEA shall be created, of a suitable size > (let's say 500MB), and it should be used as $BOOT. > If the OS is installed on a disk with GPT disk label, and a partition with > the GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 already exists, it > should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP > partition (i.e. with the GPT type UID of > c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough > (let's say 250MB) and otherwise qualifies, it should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and if the > ESP partition already exists but is too small, a new suitably sized (let's > say 500MB) partition with GPT type GUID of > bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should be used > as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP > partition exists yet, a new suitably sized (let's say 500MB) ESP should be > created and should be used as $BOOT. > > " > > So the question is basically, does the installer make the check for > preexisting $BOOT ? No. It also does not set any of those type codes such that they could be identified subsequently. -- 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://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
Re: Does the installer detects when a distro have already created BLS?
Well... I will try to repeat more clearly my claim: If Fedora want to pretend to implement the Boot Loader Specification, it must, on a new disk formatted in GPT, end up with an entry in fstab for an ESP partition mounted on /boot: "These directories are defined below the placeholder file system $BOOT. This placeholder file system shall be determined during installation time, and an fstab entry for it shall be created mounting it to /boot." ... "if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as $BOOT" This is the rule you are supposed end up to follow for an empty GPT partition. And for now, the installer seems to make you define a specific /boot/efi that it make ESP. To follow BLS, it should be /boot that is the ESP partition... and I see no point to define an other /boot/efi partition to be mounted on /boot. ... "|$BOOT| must be a VFAT (16 or 32) file system. Other file system types should not be used. Applications accessing |$BOOT| should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported." ___ 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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel wrote: > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > The change record for this states that we are not following the BLS at > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > the proposed update at > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > Thanks for remembering me this alternative specification! > > That said, Fedora does not seems to follow this alternative spec, > because we use: > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > indicated in this standard. > > The point is that as the $BOOT is shared among distributions, there must > be a way to detect if it is already there, to be able to re-use it. For > that, the specification (whatever the exact version if chosen) must be > relatively well followed. Yep. But an additional difficulty to fully implementing the spec is so far upstream GRUB don't want to follow it. So that means Fedora has to carry patches for GRUB to support it. And it's just yet another of 100+ patches Fedora carries for GRUB, and makes it difficult for the Fedora and RH boot teams. The resources so far implement some of the parts of BLS that help make things better on Fedora, but it's not a complete implementation. Drop-in snippets to add new kernels is crash safe, worst case the previous kernel is booted and you just reinstall the kernel; but writing out a new grub.cfg or modifying it, wasn't ever crash safe. Also, modifying the snippets is easier, they're just a few lines and fairly self-describing compared to what users often did, which was wade neck deep into editing grub.cfg. Or the Rube Goldberg machine that is editing /etc/default/grub, running a script (grub-mkconfig), which then runs 20 other scripts to create a configuration file that is actually a script. -- 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://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
Re: new packages review tickets
On Sun, May 24, 2020 at 08:02:09AM +, Mattia Verga via devel wrote: > Hi all, > > now that we have new detailed statistics about new package review > tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like > to make some cleanings... at the time I'm writing, there are 517 tickets > listed as new, many of them are older than 5 years! > > The first steps I would like to do, if FESCO and community agree, are: > > - some of these tickets are marked as "dependency rejected"; that means > they depend on other package review tickets that were rejected, for > whichever reason, so they will never get approved either. I would like > to just close these (there are 3 tickets in this state) > - following the Policy for stalled package reviews [1], I would like to > mass comment on tickets submitted before 1/1/2017 (more than 3 years > old) asking the submitter if they're still interested in continue with > the review process and mark the ticket as NEEDINFO. After one month > without reply I will close the ticket, as per policy. > > Then there are 352 tickets listed as "review in progress", but that's > also not true. Here we have tickets with review-flag set to ? (review in > progress) or + (package approved) since 2013. There are even some > tickets for which the git repo as been generated. > These tickets probably need a manual check to choose the best course of > action. Some of those packages have been approved and imported in > Fedora, some of these have been later retired also from repositories... > but the review ticket has never been closed. > I would propose to: > > - if the package got approved and it's still in repos, just close the > review ticket as CURRENTRELEASE > - if the package got approved and was later removed from repos, just > close the review ticket as NOTABUG > - if the package got approved before 1/1/2019, but never imported in > repos, clear the review-flag and assignee and mark as NEEDINFO from the > submitter asking if they're still interested in this (we probably need > to decide what to do if the git repo has been already set up) Likely mark it dead.package if it never got imported... > - if the package got approved before 1/1/2020, but never imported in > repos, do not clear the approval and mark as NEEDINFO from the submitter > asking if they're still interested in this > - for tickets with last change marked before 1/1/2019, if the > review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from > either the submitter or the reviewer > > Let me know if you agree (or disagree) with this proposal. Sounds good to me! Thanks for working on this. kevin 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
Re: Does the installer detects when a distro have already created BLS?
Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : The change record for this states that we are not following the BLS at https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but the proposed update at https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . Thanks for remembering me this alternative specification! That said, Fedora does not seems to follow this alternative spec, because we use: $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as indicated in this standard. The point is that as the $BOOT is shared among distributions, there must be a way to detect if it is already there, to be able to re-use it. For that, the specification (whatever the exact version if chosen) must be relatively well followed. ___ 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
Re: New package review tickets page last update on 2020-04-06
On Sun, May 24, 2020 at 03:29:47PM +0200, Fabio Valentini wrote: > On Sun, May 24, 2020 at 2:17 PM Guido Aulisi wrote: > > > > Hi, > > > > the new package review tickets page [0] was last updated on 2020-04-06. > > New tickets are not displayed, I made a new review request on April 19 > > and it never appeared on that page > > > > Is there anything not working on auto updating that page? > > I think you're looking at the URL for the "old" page. It was recently > rewritten: > > Overview: https://fedoraproject.org/PackageReviewStatus/ > New tickets: https://fedoraproject.org/PackageReviewStatus/reviewable.html It looks like the new content was just synced over the old. I have removed all the old pages now. I don't know if we want to put in redirects or something, or just assume when someone gets a 404 they will look at the index again... kevin 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
Re: Sundials upgrade on Rawhide
On 5/22/20 6:26 AM, Antonio Trande wrote: Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285 I rebuilt octave with it and it seems no more broken than it already is, so I'm fine with the update. Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > wrote: > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > > The change record for this states that we are not following the BLS at > > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > > the proposed update at > > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > > > Thanks for remembering me this alternative specification! > > > > That said, Fedora does not seems to follow this alternative spec, > > because we use: > > > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > > indicated in this standard. > > > > The point is that as the $BOOT is shared among distributions, there must > > be a way to detect if it is already there, to be able to re-use it. For > > that, the specification (whatever the exact version if chosen) must be > > relatively well followed. > > Yep. > > But an additional difficulty to fully implementing the spec is so far > upstream GRUB don't want to follow it. So that means Fedora has to > carry patches for GRUB to support it. And it's just yet another of > 100+ patches Fedora carries for GRUB, and makes it difficult for the > Fedora and RH boot teams. The resources so far implement some of the > parts of BLS that help make things better on Fedora, but it's not a > complete implementation. Drop-in snippets to add new kernels is crash > safe, worst case the previous kernel is booted and you just reinstall > the kernel; but writing out a new grub.cfg or modifying it, wasn't > ever crash safe. Also, modifying the snippets is easier, they're just > a few lines and fairly self-describing compared to what users often > did, which was wade neck deep into editing grub.cfg. Or the Rube > Goldberg machine that is editing /etc/default/grub, running a script > (grub-mkconfig), which then runs 20 other scripts to create a > configuration file that is actually a script. > Even so, isn't the canonical way of persistently updating kernel args, still, to edit /etc/default/grub and run the script? (If not, are there docs for the new way?) V/r, James Cassell ___ 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
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
This mail for asking to the maintainers of `R-argon2` `borgbackup` `gtkhash` how we want to rebuild the packages against latest `libb2` update as required by rhbz#1836534 and rhbz#1836535. By buildroot override? By a side-tag method? (https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/) On 24/05/20 12:49, Felix Schwarz wrote: > > Am 24.05.20 um 11:49 schrieb Antonio Trande: >> Can i include all dependent packages without related permissions? (i'm >> not the maintainer of `R-argon2` `borgbackup` `gtkhash`) >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 > King regards -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Re: Sundials upgrade on Rawhide
On 5/23/20 6:42 AM, David Schwörer wrote: On 5/22/20 2:26 PM, Antonio Trande wrote: Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285 My initial try of rebuilding in copr for easier testing failed. I had to add export OMPI_MCA_rmaps_base_oversubscribe=yes to the %check section, to get it working on copr. Would it be better to put that flag in each spec file, or should I open a bug against openmpi, to set this flag in %_openmpi_load? That's an interesting idea - please file the bug to discuss it further. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
Does the installer detects when a distro have already created BLS?
Well... it take time to me to get used to the Boot Loader Specification. I am being lazy here... asking people on the mailing list rather than trying to determine it myself. After making an installation of Fedora, I begin to think: Hey, I don't remember having seen the installer like detecting the use of a previously installed /boot and/or /boot/efi partition, and tells me that it will automatically use it by default. But since with Boot Loader Specification, these are supposed to be shared among distribution (maybe more likely a recent Fedora version with an older Fedora version), it make sense that it should happens. Maybe I did not seen it because I tend to erase the disk and begin from scratch. Still, rereading the specs, at: https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ I see these at the beginning: "These directories are defined below the placeholder file system |$BOOT|. This placeholder file system shall be determined during /installation time/, and an fstab entry for it shall be created mounting it to /boot. The installer program should pick |$BOOT| according to the following rules: * If the OS is installed on a disk with MBR disk label, and a partition with the MBR type id of 0xEA already exists it should be used as $BOOT. * Otherwise, if the the OS is installed on a disk with MBR disk label, a new partition with MBR type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as $BOOT. * If the OS is installed on a disk with GPT disk label, and a partition with the GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 already exists, it should be used as $BOOT. * Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP partition (i.e. with the GPT type UID of c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough (let's say 250MB) and otherwise qualifies, it should be used as $BOOT. * Otherwise, if the OS is installed on a disk with GPT disk label, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) partition with GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should be used as $BOOT. * Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as $BOOT. " So the question is basically, does the installer make the check for preexisting $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
Re: Does the installer detects when a distro have already created BLS?
I have installed the May 22 Rawhide on a disk today, and I am now realizing that the installer did not helped me enough to create valid Boot Loader Specification partitions. So I wanted (still want) to make this disk dual boot (Fedora and NixOS). Because NixOS does not follows BLS (I think... thought... I should verify)... well I decided to create two boot partitions, one for the Fedora BLS partition, and an other for NixOS. And my idea was to create a big LVM(2) partition for more normal partition: / and Swap... which I did. I have chosen ext4 for my Fedora /boot, which is illegal according to BLS: "$BOOT must be a VFAT (16 or 32) file system.". The installer, then forced my hand to add a /boot/efi partition, which I had not tought previously to add. So I removed my LVM(2) partiton, add the /boot/efi partition, then added back my LVM(2) partition. It finally installed... One of the first problem I have, is /boot have not the correct GUID for BLS: [paul@localhost /]$ cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun May 24 11:48:45 2020 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # /dev/mapper/myLVM-fedoraMain / ext4 defaults 1 1 UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4 defaults 1 2 UUID=62BD-AFFC /boot/efi vfat umask=0077,shortname=winnt 0 2 /dev/mapper/myLVM-fedoraSwap none swap defaults 0 0 [paul@localhost /]$ Reading the BLS, it seems the installer did not generated a valid entry /boot... not the valid type (vfat, EFS)... nor a valid UUID. Oh well, the other way of saying it is the installer did not force me to generate a valid /boot partition. I have: [paul@localhost /]$ sudo parted /dev/sda -- print [sudo] Mot de passe de paul : Modèle : ATA ST500LM021-1KJ15 (scsi) Disque /dev/sda : 500GB Taille des secteurs (logiques/physiques) : 512B/4096B Table de partitions : gpt Drapeaux de disque : Numéro Début Fin Taille Système de fichiers Nom Drapeaux 1 1049kB 268MB 267MB ext4 2 269MB 479MB 210MB fat16 démarrage, esp 3 479MB 701MB 222MB fat16 EFI System Partition démarrage, esp 4 701MB 194GB 193GB lvm [paul@localhost /]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk ├─sda1 8:1 0 255M 0 part /boot ├─sda2 8:2 0 200M 0 part ├─sda3 8:3 0 212M 0 part /boot/efi └─sda4 8:4 0 180G 0 part ├─myLVM-fedoraMain 253:0 0 80G 0 lvm / └─myLVM-fedoraSwap 253:1 0 9G 0 lvm [SWAP] sr0 11:0 1 6,6G 0 rom /run/media/paul/090130_0113 [paul@localhost /]$ ___ 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
Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 24.05.20 um 18:47 schrieb Antonio Trande: > This mail for asking to the maintainers of `R-argon2` `borgbackup` > `gtkhash` how we want to rebuild the packages against latest `libb2` > update as required by rhbz#1836534 and rhbz#1836535. > > By buildroot override? > By a side-tag method? > (https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/) My buildroot overrides are still active so feel free to use these: https://bodhi.fedoraproject.org/overrides/libb2-0.98.1-2.fc31 https://bodhi.fedoraproject.org/overrides/libb2-0.98.1-2.el7 Felix ___ 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
Re: Does the installer detects when a distro have already created BLS?
On Sun, 24 May 2020 14:56:34 -0400 Paul Dufresne via devel wrote: > I have installed the May 22 Rawhide on a disk today, and I am now > realizing that the installer did not helped me enough to create valid > Boot Loader Specification partitions. > > So I wanted (still want) to make this disk dual boot (Fedora and > NixOS). > > Because NixOS does not follows BLS (I think... thought... I should > verify)... well I decided to create two boot partitions, one for the > Fedora BLS partition, and an other for NixOS. Good thought. Does NixOS allow the use of uefi? If it doesn't, it will definitely need a separate partition for /boot. > And my idea was to create a big LVM(2) partition for more normal > partition: / and Swap... which I did. > > I have chosen ext4 for my Fedora /boot, which is illegal according to > BLS: "$BOOT must be a VFAT (16 or 32) file system.". I think $BOOT will be /boot/efi, and that is required to be vfat. /boot does *not* have to be vfat. > The installer, then forced my hand to add a /boot/efi partition, > which I had not tought previously to add. > > So I removed my LVM(2) partiton, add the /boot/efi partition, then > added back my LVM(2) partition. > > It finally installed... > > One of the first problem I have, is /boot have not the correct GUID > for BLS: > > [paul@localhost /]$ cat /etc/fstab > > # > # /etc/fstab > # Created by anaconda on Sun May 24 11:48:45 2020 > # > # Accessible filesystems, by reference, are maintained under > '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or > blkid(8) for more info. # > # After editing this file, run 'systemctl daemon-reload' to update > systemd # units generated from this file. > # > /dev/mapper/myLVM-fedoraMain / ext4 > defaults 1 1 > UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4 defaults > 1 2 UUID=62BD-AFFC /boot/efi vfat > umask=0077,shortname=winnt 0 2 > /dev/mapper/myLVM-fedoraSwap none swap > defaults 0 0 > [paul@localhost /]$ > > Reading the BLS, it seems the installer did not generated a valid > entry /boot... not the valid type (vfat, EFS)... nor a valid UUID. > > Oh well, the other way of saying it is the installer did not force me > to generate a valid /boot partition. Because it is under / in the lvm. /boot does not have to be vfat, it is /boot/efi that has to be vfat. If you want a separate /boot for the / in the lvm you will have to create a separate partition for it during install (custom), but it is *not* required, thus why you did not get a prompt. > I have: > > [paul@localhost /]$ sudo parted /dev/sda -- print > [sudo] Mot de passe de paul : > Modèle : ATA ST500LM021-1KJ15 (scsi) > Disque /dev/sda : 500GB > Taille des secteurs (logiques/physiques) : 512B/4096B > Table de partitions : gpt > Drapeaux de disque : > > Numéro Début Fin Taille Système de fichiers Nom > Drapeaux > 1 1049kB 268MB 267MB ext4 > 2 269MB 479MB 210MB fat16 > démarrage, esp > 3 479MB 701MB 222MB fat16 EFI System > Partition démarrage, esp > 4 701MB 194GB > 193GB lvm > > [paul@localhost /]$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 465,8G 0 disk > ├─sda1 8:1 0 255M 0 part /boot > ├─sda2 8:2 0 200M 0 part > ├─sda3 8:3 0 212M 0 part /boot/efi > └─sda4 8:4 0 180G 0 part > ├─myLVM-fedoraMain 253:0 0 80G 0 lvm / > └─myLVM-fedoraSwap 253:1 0 9G 0 lvm [SWAP] > sr0 11:0 1 6,6G 0 rom > /run/media/paul/090130_0113 [paul@localhost /]$ Fedora can't run without a / partition, usually defaults to ext4, but many other fs types available /boot, ext? usually, but I *think* can be *some* other types. Can be under /, then no separate /boot needed. /boot under the / partition the default now. Is there not a /boot under the / in the lvm partition after install? Are there not entries in /boot/loader/entries/ of the /boot in the lvm partition? /boot/efi required to be vfat by the uefi standard Is there no /boot/efi/EFI/fedora directory with entries corresponding to the lvm partition? ___ 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
Re: How to debug live CD image?
Le 20-05-24 à 05 h 47, Barry Scott a écrit : ... But I cannot boot a live CD image as it gets stuck in "Monitoring of LVM2 mirrors, ...". This is not a new problem I have seen this for a couple of Fedora releases, but not reported it before. Is it possible you don't wait enough, that is about 8 minutes by boot? Look https://bugzilla.redhat.com/show_bug.cgi?id=1830896 I was introduced to this from eugine in: https://ask.fedoraproject.org/t/boot-loading-time-is-very-high/6076/8 ___ 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
Fedora rawhide compose report: 20200524.n.0 changes
OLD: Fedora-Rawhide-20200522.n.0 NEW: Fedora-Rawhide-20200524.n.0 = SUMMARY = Added images:1 Dropped images: 4 Added packages: 4 Dropped packages:0 Upgraded packages: 153 Downgraded packages: 0 Size of added packages: 53.17 MiB Size of dropped packages:0 B Size of upgraded packages: 4.54 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 13.85 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20200524.n.0.iso = DROPPED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200522.n.0.iso Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200522.n.0.ppc64le.tar.xz Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20200522.n.0-sda.raw.xz Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20200522.n.0.iso = ADDED PACKAGES = Package: lpcnetfreedv-0.2-2.fc33 Summary: LPCNet for FreeDV RPMs:lpcnetfreedv lpcnetfreedv-devel Size:43.90 MiB Package: mingw-hamlib-3.3-1.fc33 Summary: Run-time library to control radio transceivers and receivers RPMs:mingw32-hamlib mingw64-hamlib Size:952.66 KiB Package: mingw-protobuf-3.11.4-1.fc33 Summary: MinGW Windows protobuf library RPMs:mingw32-protobuf mingw32-protobuf-static mingw32-protobuf-tools mingw64-protobuf mingw64-protobuf-static mingw64-protobuf-tools Size:8.28 MiB Package: rust-tinyvec-0.3.3-1.fc33 Summary: Just, really the littlest Vec you could need RPMs:rust-tinyvec+alloc-devel rust-tinyvec+default-devel rust-tinyvec+experimental_write_impl-devel rust-tinyvec+grab_spare_slice-devel rust-tinyvec+nightly_const_generics-devel rust-tinyvec+nightly_slice_partition_dedup-devel rust-tinyvec-devel Size:66.33 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 0ad-0.0.23b-15.fc33 Old package: 0ad-0.0.23b-14.fc33 Summary: Cross-Platform RTS Game of Ancient Warfare RPMs: 0ad Size: 24.55 MiB Size change: -563 B Changelog: * Sat May 23 2020 Kalev Lember - 0.0.23b-15 - Backport workaround for Ryzen 3000 CPU support (#1822835) Package: GMT-6.0.0-4.fc33 Old package: GMT-6.0.0-3.fc33 Summary: Generic Mapping Tools RPMs: GMT GMT-common GMT-devel GMT-doc Size: 54.80 MiB Size change: 7.00 KiB Changelog: * Thu May 21 2020 Sandro Mani - 6.0.0-4 - Rebuild (gdal) Package: OpenSceneGraph-3.4.1-17.fc33 Old package: OpenSceneGraph-3.4.1-16.fc33 Summary: High performance real-time graphics toolkit RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk OpenSceneGraph-examples-qt OpenSceneGraph-gdal OpenSceneGraph-gstreamer OpenSceneGraph-libs OpenSceneGraph-qt OpenSceneGraph-qt-devel OpenThreads OpenThreads-devel Size: 63.46 MiB Size change: 119.43 KiB Changelog: * Thu May 21 2020 Sandro Mani - 3.4.1-17 - Rebuild (gdal) Package: R-broom-0.5.6-1.fc33 Old package: R-broom-0.5.5-1.fc33 Summary: Convert Statistical Analysis Objects into Tidy Tibbles RPMs: R-broom Size: 1.89 MiB Size change: -9.44 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 0.5.6-1 - Update to latest version Package: R-callr-3.4.3-1.fc33 Old package: R-callr-3.4.2-1.fc33 Summary: Call R from R RPMs: R-callr Size: 391.38 KiB Size change: 2.36 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 3.4.3-1 - Update to latest version Package: R-dbplyr-1.4.3-1.fc33 Old package: R-dbplyr-1.4.2-2.fc32 Summary: A 'dplyr' Back End for Databases RPMs: R-dbplyr Size: 611.73 KiB Size change: 25.14 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 1.4.3-1 - Update to latest version Package: R-ellipsis-0.3.1-1.fc33 Old package: R-ellipsis-0.3.0-2.fc32 Summary: Tools for Working with ... RPMs: R-ellipsis Size: 221.50 KiB Size change: 8.20 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 0.3.1-1 - Update to latest version Package: R-future-1.17.0-1.fc33 Old package: R-future-1.16.0-2.fc33 Summary: Unified Parallel and Distributed Processing in R for Everyone RPMs: R-future Size: 655.92 KiB Size change: 7.80 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 1.17.0-1 - Update to latest version Package: R-gargle-0.5.0-1.fc33 Old package: R-gargle-0.4.0-2.fc32 Summary: Utilities for Working with Google APIs RPMs: R-gargle Size: 354.09 KiB Size change: 38.09 KiB Changelog: * Thu May 21 2020 Elliott Sales de Andrade - 0.5.0-1
[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
Am 24.05.20 um 11:49 schrieb Antonio Trande: > Can i include all dependent packages without related permissions? (i'm > not the maintainer of `R-argon2` `borgbackup` `gtkhash`) > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 Yes. Submitting an update does not require git-level permissions to commit changes. Here is what I'd like to see: 1. unpush the update 2. create tracking bugs for maintainers of dependent projects a) wait maybe a week or so for maintainers to submit a new build) b) if you don't get any response from a maintainer, please ask here for some provenpackager to trigger a build 3. create an update for libb2 + all dependent packages borgbackup: - EPEL 7 build is ready - In F31 I experienced strange test failures which only happen when doing "real" builds (all scratch builds work fine). I believe this is due to a flaky test suite but I will need some more days to investigate this. Maybe I will just disable the tests but I'm not yet sure. Felix ___ 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://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/epel-devel@lists.fedoraproject.org
[Bug 1839251] perl-Regexp-Grammars-1.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839251 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2020-9e10617fef has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9e10617fef -- 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://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
[Bug 1839536] New: perl-Devel-PatchPerl-1.94 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839536 Bug ID: 1839536 Summary: perl-Devel-PatchPerl-1.94 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-PatchPerl Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.94 Current version/release in rawhide: 1.92-1.fc33 URL: http://search.cpan.org/dist/Devel-PatchPerl/ 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://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6561/ -- 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://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
[Bug 1839515] New: perl-CPAN-Perl-Releases-5.20200524 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839515 Bug ID: 1839515 Summary: perl-CPAN-Perl-Releases-5.20200524 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200524 Current version/release in rawhide: 5.20200428-1.fc33 URL: http://search.cpan.org/dist/CPAN-Perl-Releases/ 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://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5881/ -- 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://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
[Bug 1839251] perl-Regexp-Grammars-1.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839251 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-9e10617fef has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9e10617fef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9e10617fef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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://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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 649 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 391 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 389 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 98 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 38 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ff94ccbdec openssl11-1.1.1c-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-624f38e579 qbittorrent-3.3.16-2.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-235a51a239 clamav-0.102.3-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ae83e43288 log4net-2.0.8-10.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-567eda5296 exim-4.93-3.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-134c471656 json-c12-0.12.1-4.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ff11142989 netdata-1.22.1-3.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e7814b7723 transmission-2.94-9.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19de895038 knot-resolver-5.1.1-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ed6bc3c8d4 golang-1.13.11-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing geany-1.36-2.el7 geany-plugins-1.36-1.el7 sympa-6.2.56-1.el7 Details about builds: geany-1.36-2.el7 (FEDORA-EPEL-2020-3a85ca9e73) A fast and lightweight IDE using GTK3 Update Information: This update brings the latest Geany and Geany-Plugins in version 1.36 to an RHEL7-based box near you. This is mainly intended to fix some bugs previously present, feedback if those bugs are fixed for you will be highly appreciated! ChangeLog: * Sun Apr 5 2020 Dominic Hopf - 1.36-2 - Release bump * Sun Nov 10 2019 Dominic Hopf - 1.36-1 - New upstream release: Geany 1.36 * Sat May 4 2019 Dominic Hopf - 1.35-1 - New upstream release: Geany 1.35 * Sat Mar 9 2019 Dominic Hopf - 1.34.1-1 - New upstream release: Geany 1.34 (RHBZ#1669352) * Mon Nov 27 2017 Dominic Hopf - 1.32-1 - New upstream release: Geany 1.32 * Wed Aug 2 2017 Fedora Release Engineering - 1.31-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Mon Jul 31 2017 Florian Weimer - 1.31-4 - Rebuild with binutils fix for ppc64le (#1475636) References: [ 1 ] Bug #1485735 - Geany-plugins under Mate desktop and CentOS 7 loses menubar and tool icons https://bugzilla.redhat.com/show_bug.cgi?id=1485735 [ 2 ] Bug #1659250 - geany-plugins-git-changebar-1.31-3.el7 errored on installation attempt https://bugzilla.redhat.com/show_bug.cgi?id=1659250 [ 3 ] Bug #1669352 - Release geany 1.34 for RHEL 7/Centos 7 https://bugzilla.redhat.com/show_bug.cgi?id=1669352 geany-plugins-1.36-1.el7 (FEDORA-EPEL-2020-3a85ca9e73) Plugins for Geany Update Information: This update brings the latest Geany and Geany-Plugins in version 1.36 to an RHEL7-based box near you. This is mainly intended to fix some bugs previously present, feedback if those bugs are fixed for you will be highly appreciated! ChangeLog: * Sun May 24 2020 Dominic Hopf 1.36-1 - New upstream release: Geany-Plugins 1.36 - Re-enabled plugins: debugger * Sat May 4 2019 Dominic Hopf 1.35-1 - New upstream release: Geany-Plugins 1.35 * Tue Mar 12 2019 Dominic Hopf - 1.34-3 - Add provides to geany-plugins-markdown and geany-plugins-scope * Thu Jan 31 2019 Fedora Release Engineering - 1.34-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Mon Dec 31 2018 Dominic Hopf 1.34-1 - New upstream release: Geany-Plugins 1.34 - New plugin: vimode - Re-enabled plugins which now support GTK3: Markdown, Scope * Fri Aug 10 2018 Igor Gnatenko - 1.33-3 - Rebuild for libgit2 0.27.x * Fri Jul 13 2018 Fedora Release Engineering - 1.33-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Sat Mar 3 2018 Dominic Hopf 1.33-1 - New upstream release: Geany-Plugins 1.33 -
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-765ceaa306 clamav-0.102.3-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-30aba92944 log4net-2.0.8-10.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2056b1c4a9 exim-4.93-3.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5660594875 python-markdown2-2.3.9-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c3fca161ee netdata-1.22.1-3.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-38309f9f6f transmission-2.94-9.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-06e970da9c knot-resolver-5.1.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing gloox-1.0.23-1.el8 nagios-plugins-2.3.3-3.el8 perl-Email-MIME-1.949-1.el8 perl-Email-MIME-ContentType-1.024-1.el8 python-oletools-0.55-2.el8 rancid-3.11-1.el8 testdisk-7.1-3.el8 Details about builds: gloox-1.0.23-1.el8 (FEDORA-EPEL-2020-65f631d3ca) A rock-solid, full-featured Jabber/XMPP client C++ library Update Information: Build gloox for EPEL 8 ChangeLog: nagios-plugins-2.3.3-3.el8 (FEDORA-EPEL-2020-fda19f40be) Host/service/network monitoring program plugins for Nagios Update Information: Obsolete check_ssl_validity. To be reinstated when CentOS 8.2 is released. BZ#1837397 Remove ssl_validity as perl-Convert-ASN1 has been retired. BZ#1837397 ChangeLog: * Mon Oct 13 2003 Martin Jackson - 2.3.3-3 - Obsolete check_ssl_validity. To be reinstated when CentOS 8.2 is released. BZ#1837397 * Wed Oct 8 2003 Martin Jackson - 2.3.3-2 - Remove ssl_validity as perl-Convert-ASN1 has been retired. BZ#1837397 References: [ 1 ] Bug #1837397 - Can't install "nagios-plugins-all" because "perl-Convert-ASN1" is missing for RHEL 8 / CentOS 8 https://bugzilla.redhat.com/show_bug.cgi?id=1837397 perl-Email-MIME-1.949-1.el8 (FEDORA-EPEL-2020-383149ca50) Easy MIME message parsing Update Information: This update limits the number of nested MIME parts to 10 (by default), to avoid a possible memory exhaustion issue with lots of tiny MIME parts. ChangeLog: * Sun May 24 2020 Paul Howarth - 1.949-1 - Update to 1.949 - Add $Email::MIME::MAX_DEPTH and refuse to parse deeper than that many parts; current default: 10 - Fixes to handling of content-type parameters References: [ 1 ] Bug #1835353 - rubygem-mail: Out of memory issue through nested MIME parts https://bugzilla.redhat.com/show_bug.cgi?id=1835353 perl-Email-MIME-ContentType-1.024-1.el8 (FEDORA-EPEL-2020-383149ca50) Parse a MIME Content-Type Header Update Information: This update limits the number of nested MIME parts to 10 (by default), to avoid a possible memory exhaustion issue with lots of tiny MIME parts. ChangeLog: * Sun May 24 2020 Paul Howarth - 1.024-1 - Update to 1.024 - Silence an uninitialized value warning - Avoid allowing non-Latin digits in numbers - Add new functions build_content_type() and build_content_disposition() * Wed Jan 29 2020 Fedora Release Engineering - 1.022-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1835353 - rubygem-mail: Out of memory issue through nested MIME parts https://bugzilla.redhat.com/show_bug.cgi?id=1835353
[Bug 1835360] perl-Email-MIME: rubygem-mail: Out of memory issue through nested MIME parts [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1835360 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2020-383149ca50 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-383149ca50 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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://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
[Bug 1835355] perl-Email-MIME-ContentType: rubygem-mail: Out of memory issue through nested MIME parts [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1835355 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2020-383149ca50 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-383149ca50 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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://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
[389-devel] 389 DS nightly 2020-05-25 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/25/report-389-ds-base-1.4.4.2-20200524gitc350ddc.fc32.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://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/389-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-db3d7a1399 exim-4.92.3-2.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d5bbc97415 json-c12-0.12.1-4.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fe619e5492 golang-1.13.11-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing sympa-6.2.56-1.el6 Details about builds: sympa-6.2.56-1.el6 (FEDORA-EPEL-2020-ffaa79c364) Powerful multilingual List Manager Update Information: Update to sympa 6.2.56. Fixes CVE-2020-10936. For details, see: - https://github.com/sympa-community/sympa/releases/tag/6.2.56 - https://sympa- community.github.io/security/2020-002.html ChangeLog: * Sun May 24 2020 Xavier Bachelot 6.2.56-1 - Update to 6.2.56 (Fixes CVE-2020-10936) - Fix typo in url and also socket location in lighttpd configuration (RHBZ#1812325) References: [ 1 ] Bug #1770783 - multicomponent wwsympa_url with mod_proxy_fcgi is broken https://bugzilla.redhat.com/show_bug.cgi?id=1770783 [ 2 ] Bug #1812325 - Migration with lighttpd is broken https://bugzilla.redhat.com/show_bug.cgi?id=1812325 ___ 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://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/epel-devel@lists.fedoraproject.org
[Bug 1839623] perl-TeX-Encode-2.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839623 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1691688 --> https://bugzilla.redhat.com/attachment.cgi?id=1691688=edit [patch] Update to 2.009 (#1839623) -- 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://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
[Bug 1839623] perl-TeX-Encode-2.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839623 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-TeX-Encode-2.009-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=44938823 -- 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://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
[Bug 1839623] New: perl-TeX-Encode-2.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1839623 Bug ID: 1839623 Summary: perl-TeX-Encode-2.009 is available Product: Fedora Version: rawhide Status: NEW Component: perl-TeX-Encode Keywords: FutureFeature, Triaged Assignee: tcall...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.009 Current version/release in rawhide: 2.008-1.fc33 URL: http://search.cpan.org/dist/TeX-Encode/ 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://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/12560/ -- 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://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
[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7
This mail for asking to the maintainers of `R-argon2` `borgbackup` `gtkhash` how we want to rebuild the packages against latest `libb2` update as required by rhbz#1836534 and rhbz#1836535. By buildroot override? By a side-tag method? (https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/) On 24/05/20 12:49, Felix Schwarz wrote: > > Am 24.05.20 um 11:49 schrieb Antonio Trande: >> Can i include all dependent packages without related permissions? (i'm >> not the maintainer of `R-argon2` `borgbackup` `gtkhash`) >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812 > King regards -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ 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://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/epel-devel@lists.fedoraproject.org
[Bug 1835355] perl-Email-MIME-ContentType: rubygem-mail: Out of memory issue through nested MIME parts [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1835355 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2020-383149ca50 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-383149ca50 -- 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://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
[Bug 1835360] perl-Email-MIME: rubygem-mail: Out of memory issue through nested MIME parts [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1835360 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2020-383149ca50 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-383149ca50 -- 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://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
