Re: Unretirement: tachyon
On Fri, Jan 17, 2025 at 5:20 PM Dominik 'Rathann' Mierzejewski wrote: > > Hello! > > I want to unretire tachyon: > https://src.fedoraproject.org/rpms/tachyon > > It was previously maintained by myself. I orphaned it when I thought I > had no users for it, but it turns out I need it again. > > Unretirement review request: > https://bugzilla.redhat.com/show_bug.cgi?id=2338688 > You should be good to go! :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: PQ [post-quantum] algorithms in Fedora 41 - improvements
Post quantum, I assume. https://en.wikipedia.org/wiki/Post-quantum_cryptography Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- ___ 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
Unretirement: tachyon
Hello! I want to unretire tachyon: https://src.fedoraproject.org/rpms/tachyon It was previously maintained by myself. I orphaned it when I thought I had no users for it, but it turns out I need it again. Unretirement review request: https://bugzilla.redhat.com/show_bug.cgi?id=2338688 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: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)
On Fri, Jan 17, 2025 at 2:17 AM Phillip Lougher wrote: > > Neal Gompa wrote: > > > > Thank you, I appreciate whatever you can do to make things better for > > our use-cases. :) > > Well it is obvious where your bias lies. Well, I appreciate your work too! Nowhere have I said you aren't doing good work with SquashFS. SquashFS has worked fairly well for Fedora's live media for a long time. It's still the default for live media creation in kiwi too. I have a lot of sympathy for you as SquashFS has been the technology used for this sort of thing for 15 years and in that time frame, you haven't gotten much help from anyone. Heck, I've experienced what you're feeling fairly recently with some of my other projects. But taking this out on me isn't going to make any of this better. It might even make things worse. This all started because OCI's usage of tarballs to make "images" turned out to be a poor choice (which is no real surprise), and they started looking at integrating some kind of read-only filesystem for the layers. I don't even know why SquashFS wasn't considered for OCI. Go talk to them and ask what it would take to add support for SquashFS to OCI. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)
On 2025/1/17 17:40, Neal Gompa wrote: On Fri, Jan 17, 2025 at 2:17 AM Phillip Lougher wrote: Neal Gompa wrote: Thank you, I appreciate whatever you can do to make things better for our use-cases. :) Well it is obvious where your bias lies. Well, I appreciate your work too! Nowhere have I said you aren't doing good work with SquashFS. SquashFS has worked fairly well for Fedora's live media for a long time. It's still the default for live media creation in kiwi too. I have a lot of sympathy for you as SquashFS has been the technology used for this sort of thing for 15 years and in that time frame, you haven't gotten much help from anyone. I don't think that is fair, take a small enhancement UUID and LABEL request https://github.com/plougher/squashfs-tools/issues/59 as an example, it was formally raised in 2019 (with 13 likes) and even some PR raised in 2023: https://github.com/plougher/squashfs-tools/pull/264 until now it has no upstream response. Another small enhancement: folks would like to add POSIX ACL support (another small change) to SquashFS: v1: https://lore.kernel.org/r/af77c1f80e2725c4cf1bf106d6add820b3b0eed5.1523276963.git.geliangt...@gmail.com v2: https://lore.kernel.org/r/975b0f7acbb65445551ee374a2dd38d553ac2e6a.1523326310.git.geliangt...@gmail.com v3: https://lore.kernel.org/r/cover.1533630854.git.geliangt...@gmail.com v4: https://lore.kernel.org/r/cover.1548403955.git.geliangt...@gmail.com v5: https://lore.kernel.org/r/cover.1548406694.git.geliangt...@gmail.com None of them got response. If digging into more in the kernel mailing list, Android team also tried to improve SquashFS first rather than use EROFS at first. So obviously SquashFS gets more community development resource (even enterprise resources) rather than EROFS. Honestly, our team also considered improving SquashFS format in 2017 to address its performance issue especially for smaller chunks (-b <= 16384) for our high-performance devices. but those are not minor changes, and the previous feedback status scared us. I didn't want to say too much in this reply (as I said, currently I don't even care Fedora LiveCD case since some feature people may care is missing like metadata compression and multi-threaded CDC), but "By doing this they deliberately reduce the compression and speed of Squashfs in their tests. This IMHO is biased and unethical. " really sounds unpleasant to me: https://erofs.docs.kernel.org/en/latest/comparsion/dedupe.html just would like to express the benefits of the compressed data deduplication feature (like two version wikipedia texts). Since EROFS doesn't support metadata compression, so I turned it off and explicitly drop a comment below. As even don't consider our previous paper, for 3rd-party comparsion of these two FSes, there are many other online materials, e.g.: https://youtu.be/kLxM4FyiVpQ?t=2024 and https://sigma-star.at/blog/2022/07/squashfs-erofs Thanks, Gao Xiang -- ___ 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
PQ algorithms in Fedora 41 - improvements
Dear colleagues, I'd like to encourage you to test and upvote the following updates to Fedora 41: https://bodhi.fedoraproject.org/updates/FEDORA-2025-cc4e64ede9 This update adds the latest version of liboqs/oqsprovider packages and GnuTLS. This update provides the final NIST-approved versions of the post-quantum algorithms ML-KEM and ML-DSA (instead of preliminary versions, Dilithium and Kyber that are basically out of use now). https://bodhi.fedoraproject.org/updates/FEDORA-2025-800d4e4a95 This update updates OpenSSH to version 9.9p1 that brings a PQ-safe key exchange based on ML-KEM. Many thanks! -- Dmitry Belyavskiy -- ___ 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: F42 Change Proposal: Switch to EROFS for Live Media (self-contained)
Gao Xiang wrote: > On 2025/1/17 17:40, Neal Gompa wrote: > > On Fri, Jan 17, 2025 at 2:17 AM Phillip Lougher > > phillip.loug...@gmail.com wrote: > > Neal Gompa wrote: > > Thank you, I appreciate whatever you can do to make things better for > > our use-cases. :) > > Well it is obvious where your bias lies. > > Well, I appreciate your work too! Nowhere have I said you aren't doing > > good work with SquashFS. SquashFS has worked fairly well for Fedora's > > live media for a long time. It's still the default for live media > > creation in kiwi too. I have a lot of sympathy for you as SquashFS has > > been the technology used for this sort of thing for 15 years and in > > that time frame, you haven't gotten much help from anyone. > > I don't think that is fair, take a small enhancement I think you are deliberately trying to provoke an even bigger argument than present. I'm not interested in that, and I have said what I wanted to say. Phillip -- ___ 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: forwarding aliases (was: Non-responsive maintainer sham1)
Kevin Fenzi venit, vidit, dixit 2025-01-16 23:30:34: > Note: we are talking about @fedoraproject.org aliases here. > mailing lists already mitigate this as you note. Indeed. One might wonder what fpo aliases are good for - after all, you have to have a mailbox to forward your alias to, and sending "from" (with) that alias reveals which hosts you're sending through. For organisational purposes, people also use plus-adresses (name+fed...@bigprovider.com) or special personal addresses (fed...@myowndomain.net). But maybe we shouldn't underestimate the value of "corporate/community identity" which the aliases convey - first, to new members that they "belong" to the project, but also externally whenever someone contributes insights (forums) or code using an fpo alias. I think some RH employes use it to separate corporate work (even for Fedora) from off-work contributions. That being said, we might be at a point where pure aliases stop working universally enough to fulfill their purpose, even if for a good reason (DMARC/SPF/...). Michael -- ___ 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: rpmlint+readelf corrupted interpreter on generated binaries
Hi Mark, But I also think this is a bug in binutils readelf (CCing nickc). It really should not even try to print the "interpreter" of a separate debuginfo file. Well yes and no. One of the main uses of readelf is to inspect potentially broken or corrupt ELF files, so displaying the contents of the interpreter field even when it is not expected to be meaningful could still be of use to someone. What I have done however is to update readelf's sources so that it sanitizes the interpreter string before displaying it. Where "sanitizes" == "converts any non displaying characters into hex values". Cheers Nick -- ___ 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: rpmlint+readelf corrupted interpreter on generated binaries
Hi Nick, On Fri, Jan 17, 2025 at 10:31:49AM +, Nick Clifton wrote: > >But I also think this is a bug in binutils readelf (CCing nickc). > > > >It really should not even try to print the "interpreter" of a separate > >debuginfo file. > > Well yes and no. One of the main uses of readelf is to inspect potentially > broken or corrupt ELF files, so displaying the contents of the interpreter > field even when it is not expected to be meaningful could still be of use > to someone. > > What I have done however is to update readelf's sources so that it sanitizes > the interpreter string before displaying it. Where "sanitizes" == "converts > any non displaying characters into hex values". Nice solution! Nicer than what elfutils eu-readelf does, so I might steal it :) The real problem is what you say above. There is no way to distinguish between a real separate debuginfo file (where the interpreter doesn't make sense) and a (slightly) corrupted ELF file. Thanks, Mark -- ___ 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
