Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>It is also unclear that it can prevent full OOM (both >RAM and swap completely full) in all cases Kernel's killer is also cannot prevent full OOM in all cases. earlyoom prevent full OOM (and situations close to OOM) much more effective - faster (selects victim in 5-50ms, monitoring interval is 0.1-1s) and softer (sends SIGTERM first). >fail >to kill processes when it would be necessary to prevent swap thrashing OK, earlyoom does not prevent thrashing, but kernel also does not prevent it. Thrashing may be reduced with killers that supports response to PSI: oomd [1], nohang [2], psi-monitor [3] (psi-monitor is used by default in Endless OS). >I strongly believe that this kernel problem can only be solved within the >kernel, by a synchronous (hence race-free) hook on all allocations. It's already solved in the kernel: just set `vm.overcommit_memory=2` and `vm.overcommit_ratio=50`: "When this flag is 2, the kernel uses a "never overcommit" policy that attempts to prevent any overcommit of memory." [4] 1. https://github.com/facebookincubator/oomd 2. https://github.com/hakavlad/nohang 3. https://github.com/endlessm/eos-boot-helper/tree/master/psi-monitor 4. https://www.kernel.org/doc/Documentation/sysctl/vm.txt ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>it should be disabled so it doesn't kill our software What should people who suffer from the fact that the kernel's OOM killer does not work, and they are forced to hard reboot (and lose unsaved data) the computer when it freezes? This is a serious and very common problem that exists for a long time and has not been fixed out of the box. What do you suggest? Should we do nothing? Of course, we can do nothing and wait for the inclusion of the system-oomd in the systemd [7]. Just wait. Also look at these discussions: - Why are low memory conditions handled so badly? [1] - Memory management "more effective" on Windows than Linux? (in preventing total system lockup) [2] - Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure [3] [4] [5] - How do I prevent Linux from freezing when out of memory? Today I (accidentally) ran some program on my Linux box that quickly used a lot of memory. My system froze, became unresponsive and thus I was unable to kill the offender. How can I prevent this in the future? Can't it at least keep a responsive core or something running? [6] 1. https://www.reddit.com/r/linux/comments/56r4xj/why_are_low_memory_conditions_handled_so_badly/ 2. https://www.reddit.com/r/linux/comments/aqd9mh/memory_management_more_effective_on_windows_than/ 3. https://lkml.org/lkml/2019/8/4/15 4. https://www.reddit.com/r/linux/comments/cmg48b/lets_talk_about_the_elephant_in_the_room_the/ 5. https://news.ycombinator.com/item?id=20620545 6. https://serverfault.com/questions/390623/how-do-i-prevent-linux-from-freezing-when-out-of-memory 7. https://github.com/systemd/systemd/pull/15206 ___ 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: The future of legacy BIOS support in Fedora.
On Friday, July 3, 2020 9:40:34 PM MST Rahul Sundaram wrote: > Hi > > On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote: > > These "qualifiers" are important. > > > > 1) Yes, I did get a response, as I said in the first email. The response > > showed that there weren't any issues with the kernel or core packages at > > the > > time it was dropped. > > What you originally said - "I asked for a list of issues that warranted > ending 32 bit > support while it still worked, and got nothing" There was nothing. Every single bug filed against it was in a package outside of the default sets for every Spin, including the GNOME Spin. > > 2) I never said it was perfect, nothing ever is. > > What you originally said - ". When it came down to it, it was dropped while > 32 bit > Fedora still worked perfectly." It does "work perfectly". That's not the same as saying anything is perfect, it's a phrase for "Everything works". Every package that is installed in every single spin's default packages works. I confirmed this before I tried to join the x86 SIG at the last minute, as it seemed to be the only way to keep x86 from getting dropped, but it wasn't enough. I pointed out that the issues filed against x86 were mostly the same as those filed against ARMv7, and that still didn't matter. Here we are, with x86 dropped while it still works, while ARMv7 is still kicking around. -- John M. Harris, Jr. ___ 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: The future of legacy BIOS support in Fedora.
Hi On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote: > These "qualifiers" are important. > > 1) Yes, I did get a response, as I said in the first email. The response > showed that there weren't any issues with the kernel or core packages at > the > time it was dropped. > What you originally said - "I asked for a list of issues that warranted ending 32 bit support while it still worked, and got nothing" > 2) I never said it was perfect, nothing ever is. > What you originally said - ". When it came down to it, it was dropped while 32 bit Fedora still worked perfectly." We are done here Rahul ___ 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
[389-devel] 389 DS nightly 2020-07-04 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/04/report-389-ds-base-1.4.4.3-20200703git017fda0.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
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/3/20 1:41 PM, Chris Murphy wrote:
> SSDs can fail in weird ways. Some spew garbage as they're failing,
> some go read-only. I've seen both. I don't have stats on how common it
> is for an SSD to go read-only as it fails, but once it happens you
> cannot fsck it. It won't accept writes. If it won't mount, your only
> chance to recover data is some kind of offline scrape tool. And Btrfs
> does have a very very good scrape tool, in terms of its success rate -
> UX is scary. But that can and will improve.
Ok, you and Josef have both recommended the btrfs restore ("scrape")
tool as a next recovery step after fsck fails, and I figured we should
check that out, to see if that alleviates the concerns about
recoverability of user data in the face of corruption.
I also realized that mkfs of an image isn't representative of an SSD
system typical of Fedora laptops, so I added "-m single" to mkfs,
because this will be the mkfs.btrfs default on SSDs (right?). Based
on Josef's description of fsck's algorithm of throwing away any
block with a bad CRC this seemed worth testing.
I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
image, or a bit less than 1% of the filesystem blocks, at random.
This is 1/4 the fuzzing rate from the original test.
So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
mount, mount w/ recovery, and then restore ("scrape") if all that
fails, see what we get.
I ran 50 loops, and got:
46 btrfsck failures
20 mount failures
So it ran btrfs restore 20 times; of those, 11 runs lost all or
substantially all of the files; 17 runs lost at least 1/3 of the
files.
-Eric
___
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
[Bug 1850928] perl-Module-Load-Conditional-0.72 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850928 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona |l-0.72-1.fc33 |l-0.72-1.fc33 |perl-Module-Load-Conditiona |perl-Module-Load-Conditiona |l-0.72-1.fc32 |l-0.72-1.fc32 ||perl-Module-Load-Conditiona ||l-0.72-1.fc31 --- Comment #8 from Fedora Update System --- FEDORA-2020-4b43fef7c5 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 1850935] perl-Archive-Tar-2.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850935 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Archive-Tar-2.38-1.fc3 |perl-Archive-Tar-2.38-1.fc3 |3 |3 |perl-Archive-Tar-2.38-1.fc3 |perl-Archive-Tar-2.38-1.fc3 |2 |2 ||perl-Archive-Tar-2.38-1.fc3 ||1 --- Comment #7 from Fedora Update System --- FEDORA-2020-f5ed64fc47 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Review Swaps: new-session-manager
Hi all, I know I unretired non-daw, but the Linux Audio community has developed a drop-in replacement for non-session-manager as a fork called new-session-manager. I've packaged it for both Ubuntu and now Fedora. If anybody would be so kind as to review this package, the bug is at https://bugzilla.redhat.com/show_bug.cgi?id=1853780. I'd be glad to review another package in exchange, but bear in mind that if it's not a relatively simple package I might not be able to be much help. Thanks, Erich Erich Eickmeyer Fedora Jam mainainer pEpkey.asc Description: application/pgp-keys ___ 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
[Bug 1842881] Add perl-Net-Amazon-S3 to EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1842881 Bug 1842881 depends on bug 1842892, which changed state. Bug 1842892 Summary: Add perl-VM-EC2-Security-CredentialCache to EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1842892 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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 1842892] Add perl-VM-EC2-Security-CredentialCache to EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1842892 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-07-04 01:33:40 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2020-ea010f3299 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 1850928] perl-Module-Load-Conditional-0.72 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850928 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona |l-0.72-1.fc33 |l-0.72-1.fc33 ||perl-Module-Load-Conditiona ||l-0.72-1.fc32 Resolution|--- |ERRATA Last Closed||2020-07-04 01:12:09 --- Comment #7 from Fedora Update System --- FEDORA-2020-f65dea71dd has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 1850935] perl-Archive-Tar-2.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1850935 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Archive-Tar-2.38-1.fc3 |perl-Archive-Tar-2.38-1.fc3 |3 |3 ||perl-Archive-Tar-2.38-1.fc3 ||2 Resolution|--- |ERRATA Last Closed||2020-07-04 01:12:11 --- Comment #6 from Fedora Update System --- FEDORA-2020-cc8c748a17 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Re: Latest fedora on docker hub
Seems that fedora:latest is f31 at dockerhub, is this intentional? CC: cve...@fedoraproject.org, maintainer for the docker image at dockerhub Christoph Junghans 于2020年7月4日周六 上午4:49写道： > > Hi, > > it seems fedora:latest on docker hub is still F31. > $ docker run -it fedora:latest cat /etc/redhat-release > Unable to find image 'fedora:latest' locally > latest: Pulling from library/fedora > 4c69497db035: Pull complete > Digest: > sha256:ee55117b3058f2f12961184fae4b9c392586e400487626c6bd0d15b4eae94ecc > Status: Downloaded newer image for fedora:latest > Fedora release 31 (Thirty One) > > The README on docker hub (https://hub.docker.com/_/fedora) suggests it > should be F32. > > Cheers, > > Christoph > > > -- > Christoph Junghans > Web: http://www.compphys.de > ___ > 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: Latest fedora on docker hub
You can try fedora:rawhide instead...while I don't know to whom this problem should be reported. And Fedora have registry.fedoraproject.org/fedora, where fedora:latest = fedora 33(rawhide) Christoph Junghans 于2020年7月4日周六 上午4:49写道： > > Hi, > > it seems fedora:latest on docker hub is still F31. > $ docker run -it fedora:latest cat /etc/redhat-release > Unable to find image 'fedora:latest' locally > latest: Pulling from library/fedora > 4c69497db035: Pull complete > Digest: > sha256:ee55117b3058f2f12961184fae4b9c392586e400487626c6bd0d15b4eae94ecc > Status: Downloaded newer image for fedora:latest > Fedora release 31 (Thirty One) > > The README on docker hub (https://hub.docker.com/_/fedora) suggests it > should be F32. > > Cheers, > > Christoph > > > -- > Christoph Junghans > Web: http://www.compphys.de > ___ > 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
[Test-Announce] 2020-07-06 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2020-07-06 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a few weeks, so let's check in and see where things are. There's a bumper crop of proposed Fedora 33 Changes we can pick through, for one thing! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 33 status and Changes 3. Test Day / community event status 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: The future of legacy BIOS support in Fedora.
I just came from Windows 10 not too long ago, and it was the worst computer experience that I've ever had. Had it since the first week it came out, so glad that I don't see it anymore. Hope I never see it again. It was really rough getting my laptop downgraded to Windows 7, since my pc was being remote controlled to stop me from leaving 10. Had to shut my pc off and lock the BIOS with a password until I could install Windows 7. While I'm familiar with Windows 7, I would like to leave Windows behind completely. Currently have a dual booted system. Because of the way Windows 10 is, UEFI is the only thing that is accepted (no Legacy Boot). If I try any other OS on UEFI my laptop can't find the disc image. It somehow seems to be designed only for Windows 10. Legacy Boot is the only way that I can run a different OS. Despite factory reseting it and doing a clean install of Windows 7, I still can't use UEFI at all. My laptop isn't that old either, (about a year and a half) in fact it was really hard to get my intel drivers working since Intel doesn't support downgrading with newer hardware that's designed for Windows 10 from what I can see. I'm new to Linux and have only recently gotten used to Fedora, but if it goes to where only UEFI is supported I will have to unfortunately go elsewhere. While my laptop is 64 bit, I know of a lot of computers that are 32 bit and as cool as the newest software is not everyone switches over. Some people like to stay with the same configuration for years. I do feel that large companies want people to make the switch to the newer stuff, but it just isn't always practical for some. I don't know any computer programming languages, so I don't really know if there are inconvieniences to keep Legacy Boot. Anyway, this is just my take on it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1853775] New: perl-Email-Stuffer-0.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1853775 Bug ID: 1853775 Summary: perl-Email-Stuffer-0.018 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Email-Stuffer Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.018 Current version/release in rawhide: 0.017-8.fc33 URL: http://search.cpan.org/dist/Email-Stuffer/ 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/13425/ -- 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
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On 7/3/20 2:07 PM, PGNet Dev wrote: > from cmd line, > > copr-cli edit-chroot --packages git > > looks like it should work as well and it does, nicely: ==> 14:26:43 Build 1517366: succeeded ___ 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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On 7/3/20 8:24 AM, PGNet Dev wrote: > git _was_ trivially added to the local mock chroot, for its use, with obvious > success, in the local mock build of the spec. > > COPR uses mock. > > So far, I have not seen how that's to be similarly done for the COPR env. > > Is is possible to, similarly, add git to the COPR mock env? FrostyX @ irc was kind enuf to give this a try -- & found the solution. @ nav to https://copr.fedorainfracloud.org/coprs/pgfed/nginx-mainline/edit_chroot/fedora-32-x86_64/ adding 'git' to Packages: git You can add additional packages to the minimal buildroot of this chroot. These packages will be always present before the build starts. ( from UI, that's 'hidden' behind the "EDIT" button for the select chroot(s). obvious if you know it ... ) seems to solve the problem. he was able to successfully bld my spec ... from cmd line, copr-cli edit-chroot --packages git looks like it should work as well ta, FrostyX! ___ 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
Latest fedora on docker hub
Hi, it seems fedora:latest on docker hub is still F31. $ docker run -it fedora:latest cat /etc/redhat-release Unable to find image 'fedora:latest' locally latest: Pulling from library/fedora 4c69497db035: Pull complete Digest: sha256:ee55117b3058f2f12961184fae4b9c392586e400487626c6bd0d15b4eae94ecc Status: Downloaded newer image for fedora:latest Fedora release 31 (Thirty One) The README on docker hub (https://hub.docker.com/_/fedora) suggests it should be F32. Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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: The future of legacy BIOS support in Fedora.
On Friday, July 3, 2020 3:37:34 AM MST Rahul Sundaram wrote: > Hi > > On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote: > > None of those bugs were release blocking, and none of them meant that x86 > > wouldn't boot, or that core packages didn't work > > When you add so many qualifiers, you are now admitting a) you did get a > response b) that things weren't perfect as you claimed. Those were merely > examples anyway. You can find plenty more in past discussions long before > the decision was made. You cannot possibly believe that an architecture > maintenance only involves a handful of bugs. It requires substantial > resources which aren't free. If you want to reduce your claim to the "many > bugs that did exist and added additional maintenance burden didn't affect > me personally therefore I disagree with the decision made", now that would > be a more reasonable statement if one didn't keep bringing it up in > unrelated discussions. These "qualifiers" are important. 1) Yes, I did get a response, as I said in the first email. The response showed that there weren't any issues with the kernel or core packages at the time it was dropped. 2) I never said it was perfect, nothing ever is. I was involved in those past discussions. The bugs in these packages had no effect on the majority of x86 users, they could still install Fedora, download a DE of their choice, compile software, open a web browser, etc. There are currently bugs filed against x64, does that mean we should drop support for it? For a while, Firefox wasn't compiling on ARM. Does that mean we should drop that arch? It's very much related, because the same arguments that were used against x86 have been used here. See: - It's "legacy" - It has bugs filed against it -- John M. Harris, Jr. ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 3 July 2020 21:54:10 CEST, Adam Williamson wrote: >On Fri, 2020-07-03 at 21:35 +0200, Markus Larsson wrote: >> >> On 3 July 2020 21:30:26 CEST, Adam Williamson >> wrote: >> > On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: >> > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault >> > > >> > > == Summary == >> > > >> > > Let's make Fedora more approachable, by having a default editor that >> > > doesn't require specialist knowledge to use. >> > > >> > > == Owner == >> > > * Name: [[User:chrismurphy| Chris Murphy]] >> > > * Email: chrismur...@fedoraproject.org >> > >> > Hey, randomly found another thing you'll need to do as part of this >> > change - drop this patch: >> > https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch >> >> Isn't that awesome wm? >> Do we think that new users will even know it exists? >> It also will only use vi if $EDITOR isn't set. >> Am I completely missing the joke here? > >Oh, sorry, meant to send it to Chris only. it was mostly just a fun >note that I found this thing in a completely random package I was >looking at for other reasons... Phew, I was thinking my grasp on reality was slipping and/or you were on drugs :D ___ 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: The future of legacy BIOS support in Fedora.
On Friday, July 3, 2020 12:15:03 AM MST Nicolas Mailhot via devel wrote: > Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit : > > > > 5-10 years? A better estimate would be 15-20 years. People aren't > > > going to > > > throw away perfectly fine systems and jump to new "cloud" platforms > > > just > > > because the OS they were using dropped BIOS support. They'll just > > > stop > > > updating, and likely move to something that is still supporting > > > BIOS, if they > > > don't write their own installer and just continue using Fedora, > > > given that > > > this is an entirely artificial limitation. > > > > > > > While I completely hear you on the fact that people will often sweat > > assets for years longer than accounting schedules suggest they > > should, do you really think they're going to write custom > > installers??? > > > They’re going to move to forks of Fedora downstreams (as AWS and others > already did). > > (this is not an endorsement of any other position in this thread, I > hate all our bootloaders equally, they’ve been a lost cause since > someone decided to hide the bootloader menu in the default install, > making it something that does not exist… till you need it an realize > the state it’s in). Wait, what? I somehow never noticed that the bootloader menu has been hidden. It's not on my system, so maybe it didn't change upgraded systems? https://fedoraproject.org/wiki/Changes/HiddenGrubMenu This is really wild. How in the world did this Change get approved? "The grub menu with its kernel versions is another example of showing too technical info to end-users and on non multi-boot systems it normally is not necessary, so it is better to hide it." has to be the most GNOME thing I've read today. Oh, it's just Workstation. That'd explain how I never noticed, and how it got approved. This would explain the Discourse threads that popped up, asking how to rescue a system. -- John M. Harris, Jr. ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Fri, 2020-07-03 at 21:35 +0200, Markus Larsson wrote: > > On 3 July 2020 21:30:26 CEST, Adam Williamson > wrote: > > On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > > > > > == Summary == > > > > > > Let's make Fedora more approachable, by having a default editor that > > > doesn't require specialist knowledge to use. > > > > > > == Owner == > > > * Name: [[User:chrismurphy| Chris Murphy]] > > > * Email: chrismur...@fedoraproject.org > > > > Hey, randomly found another thing you'll need to do as part of this > > change - drop this patch: > > https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch > > Isn't that awesome wm? > Do we think that new users will even know it exists? > It also will only use vi if $EDITOR isn't set. > Am I completely missing the joke here? Oh, sorry, meant to send it to Chris only. it was mostly just a fun note that I found this thing in a completely random package I was looking at for other reasons... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Fri, Jul 3, 2020 at 3:44 PM Robert-André Mauchin wrote:
>
> On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> > Just wanted to provide some update on this change.
> >
> > * %__cmake_in_source_build macro has been introduced and set to 1. It
> > controls what arguments are passed to `cmake -B ...`, `cmake --build
> > ...`, `cmake --install ...` and in which directory `ctest` is executed.
> > If it is set to anything, it will use `.` as a directory so that build
> > is done in-place.
> > * %cmake now always passes -S/-B options.
> > * %cmake_build/%cmake_install/%ctest macros have been created.
> > * %cmake_kf5 changes are in progress by Neal at this moment.
> >
> > So far these changes are not breaking (it becomes breaking if you unset
> > `%__cmake_in_source_build` macro), so we plan to backport them in
> > stable Fedora releases so that spec files can stay compatible across
> > Fedora branches.
> >
> > I've ran scratch rebuilds of ~2k packages that are affected (not
> > including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
> > will be lower once we get %cmake_kf5 changes are in). The ones that
> > failed are:
> >
> > * 141 use `cd builddir; cmake ..; make` pattern
> > * 823 use `cmake; make` pattern
> > * 96 failed for irrelevant or overlooked problem
> >
> > Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
> > of-affected-packages.
> >
> > NOW: I've booked 4 hours session this Sunday with Neal to go and fix
> > broken packages. If you are interested to help - let me know and I'll
> > send you an invitation.
> >
> > Will keep you updated :)
>
>
> I'm confused by the proposal, it is named "CMake to do out-of-source builds"
> but the macros seems to do the opposite?
>
> On Rawhide (local repo):
>
> %__cmake \
> -S "%{_vpath_srcdir}" \
> -B "%{__cmake_builddir}" \
>
> __cmake_builddir
> %{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
> __cmake_in_source_build1
>
> Looks like __cmake_builddir is defined as "." so the build will happen
> in source?
>
It's being done in steps so that we can get everything building with
the new macros and then switch to out of tree and rebuild
appropriately.
--
真実はいつも一つ！/ 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
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> Just wanted to provide some update on this change.
>
> * %__cmake_in_source_build macro has been introduced and set to 1. It
> controls what arguments are passed to `cmake -B ...`, `cmake --build
> ...`, `cmake --install ...` and in which directory `ctest` is executed.
> If it is set to anything, it will use `.` as a directory so that build
> is done in-place.
> * %cmake now always passes -S/-B options.
> * %cmake_build/%cmake_install/%ctest macros have been created.
> * %cmake_kf5 changes are in progress by Neal at this moment.
>
> So far these changes are not breaking (it becomes breaking if you unset
> `%__cmake_in_source_build` macro), so we plan to backport them in
> stable Fedora releases so that spec files can stay compatible across
> Fedora branches.
>
> I've ran scratch rebuilds of ~2k packages that are affected (not
> including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
> will be lower once we get %cmake_kf5 changes are in). The ones that
> failed are:
>
> * 141 use `cd builddir; cmake ..; make` pattern
> * 823 use `cmake; make` pattern
> * 96 failed for irrelevant or overlooked problem
>
> Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
> of-affected-packages.
>
> NOW: I've booked 4 hours session this Sunday with Neal to go and fix
> broken packages. If you are interested to help - let me know and I'll
> send you an invitation.
>
> Will keep you updated :)
I'm confused by the proposal, it is named "CMake to do out-of-source builds"
but the macros seems to do the opposite?
On Rawhide (local repo):
%__cmake \
-S "%{_vpath_srcdir}" \
-B "%{__cmake_builddir}" \
__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
__cmake_in_source_build1
Looks like __cmake_builddir is defined as "." so the build will happen
in source?
> >
> > === Migration ===
> >
> >
> >
> > %cmake + %(make|ninja)_(build|install)
> >
> >
> >
> >
> > There are multiple paths to complete the migration:
> >
> >
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> >
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> >
Ok so you keep in-source building for existing package, you don't convert
to out of source?
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> >
> >
> > No changes are needed.
> >
You don't plan to update to the new macros cmake_* for consistency sake?
Best regards,
Robert-André
___
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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 3 July 2020 21:30:26 CEST, Adam Williamson wrote: >On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/UseNanoByDefault >> >> == Summary == >> >> Let's make Fedora more approachable, by having a default editor that >> doesn't require specialist knowledge to use. >> >> == Owner == >> * Name: [[User:chrismurphy| Chris Murphy]] >> * Email: chrismur...@fedoraproject.org > >Hey, randomly found another thing you'll need to do as part of this >change - drop this patch: >https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch Isn't that awesome wm? Do we think that new users will even know it exists? It also will only use vi if $EDITOR isn't set. Am I completely missing the joke here? M ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > == Summary == > > Let's make Fedora more approachable, by having a default editor that > doesn't require specialist knowledge to use. > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: chrismur...@fedoraproject.org Hey, randomly found another thing you'll need to do as part of this change - drop this patch: https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
SSDs can fail in weird ways. Some spew garbage as they're failing, some go read-only. I've seen both. I don't have stats on how common it is for an SSD to go read-only as it fails, but once it happens you cannot fsck it. It won't accept writes. If it won't mount, your only chance to recover data is some kind of offline scrape tool. And Btrfs does have a very very good scrape tool, in terms of its success rate - UX is scary. But that can and will improve. -- 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
[Bug 1853746] New: perl-DateTime-Locale-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1853746 Bug ID: 1853746 Summary: perl-DateTime-Locale-1.26 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Locale 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.26 Current version/release in rawhide: 1.25-2.fc32 URL: http://search.cpan.org/dist/DateTime-Locale/ 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/6477/ -- 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
Re: use of 'date' in rpm .spec %define concats add'l str chars?
On 7/3/20 11:22 AM, Paul Howarth wrote: > Remember ugh. well, i certainly will NOW! ;-) > that '%' introduces a macro expansion, so if that's not what > you want, you should escape the '%' as '%%': > > %define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S ) works perfectly. thx! ___ 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: use of 'date' in rpm .spec %define concats add'l str chars?
PGNet Dev wrote: > %define _build_timestamp %( date +%Y%m%d_%H%M%S ) Percent signs that are not to be interpreted as RPM syntax need to be doubled. Write this as: %define _build_timestamp %(date +%%Y%%m%%d_%%H%%M%%S) Björn Persson pgpSR1gksDcHm.pgp Description: OpenPGP digital signatur ___ 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: use of 'date' in rpm .spec %define concats add'l str chars?
On Fri, 3 Jul 2020 11:09:47 -0700
PGNet Dev wrote:
> on F32,
>
> date +FORMAT,
> date +%Y%m%d_%H%M%S
>
> returns
> 20200703_105351
>
>
>
> as expected.
>
> in an rpm .spec, if I define
>
> %define _build_timestamp %( date +%Y%m%d_%H%M%S )
>
> and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of
> any of rpmbuild/mock build/@COPR etc, it appears as
>
> '20200703_105351OURCE'
>
> ?
>
> Simply changing the define to
>
> %define _build_timestamp %( date +%Y%m%d_%H%M%S | head -c 15 )
>
> 'fixes' the problem, and use of %{_build_timestamp) correctly returns
>
> '20200703_105351'
>
>
>
> Is this a bug in rpmbuild or date? Or a problem in my usage?
Remember that '%' introduces a macro expansion, so if that's not what
you want, you should escape the '%' as '%%':
%define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S )
Paul.
___
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
use of 'date' in rpm .spec %define concats add'l str chars?
on F32,
date +FORMAT,
date +%Y%m%d_%H%M%S
returns
20200703_105351
as expected.
in an rpm .spec, if I define
%define _build_timestamp %( date +%Y%m%d_%H%M%S )
and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of any of
rpmbuild/mock build/@COPR etc, it appears as
'20200703_105351OURCE'
?
Simply changing the define to
%define _build_timestamp %( date +%Y%m%d_%H%M%S | head -c 15 )
'fixes' the problem, and use of %{_build_timestamp) correctly returns
'20200703_105351'
Is this a bug in rpmbuild or date? Or a problem in my usage?
___
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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest` is executed.
If it is set to anything, it will use `.` as a directory so that build
is done in-place.
* %cmake now always passes -S/-B options.
* %cmake_build/%cmake_install/%ctest macros have been created.
* %cmake_kf5 changes are in progress by Neal at this moment.
So far these changes are not breaking (it becomes breaking if you unset
`%__cmake_in_source_build` macro), so we plan to backport them in
stable Fedora releases so that spec files can stay compatible across
Fedora branches.
I've ran scratch rebuilds of ~2k packages that are affected (not
including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
will be lower once we get %cmake_kf5 changes are in). The ones that
failed are:
* 141 use `cd builddir; cmake ..; make` pattern
* 823 use `cmake; make` pattern
* 96 failed for irrelevant or overlooked problem
Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
of-affected-packages.
NOW: I've booked 4 hours session this Sunday with Neal to go and fix
broken packages. If you are interested to help - let me know and I'll
send you an invitation.
Will keep you updated :)
On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> == Summary ==
> %cmake macro will be adjusted (-B
> parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the
> older
> supported Fedora releases) to perform various operations that are
> commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> etc.) way.
>
> Packages that will stop building are trivial to fix and will be
> adjusted either by maintainers or change owners.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> Esser]], [[User:ngompa|Neal Gompa]]
> * Email: ignatenkobr...@fedoraproject.org,
> besse...@fedoraproject.org,
> ngomp...@gmail.com
>
> == Detailed Description ==
> Historically, software builds had a singular build configuration and
> required running the build within the project root. Nowadays, there
> are many build modes and options that can be configured in projects,
> different build settings (e.g. compiler flags) / types (release,
> debug) that can be applied and different tools that can be used to
> actually execute builds (compilers like gcc/clang, build job
> schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> discourages users of doing in-source builds and recommends doing
> out-of-source builds.
>
> From cmake.1:
>
>
> To maintain a pristine source tree, perform an out-of-source build by
> using a separate dedicated build tree. An in-source build in which
> the
> build tree is placed in the same directory as the source tree is also
> supported, but discouraged.
>
>
> The other part of the change is introduction of additional macros is
> creation of set of macro that can build, install and run tests in a
> backend-agnostic, vpath-aware (out-of-source, in-source) way.
>
> === Migration ===
>
> %cmake + %(make|ninja)_(build|install)
>
>
> There are multiple paths to complete the migration:
>
> * Add -C "%{_vpath_builddir}" to the
> %(make|ninja)_*
> * Replace %(make|ninja)_build and
> %(make|ninja)_install with %cmake_build and
> %cmake_install respectively
> * Redefine vpath builddir %global _vpath_builddir . to
> continue performing in-source builds (and optionally converting to
> the
> %cmake_*)
>
> Depending on the package, one of these options may be used to adapt
> to
> this change.
>
> %cmake -B builddir +
> %(make|ninja)_(build|install) -C builddir
>
> No changes are needed.
>
> == Benefit to Fedora ==
> * Follow CMake upstream recommendations when building packages
> * Brings Fedora package builds more in-line with how upstream
> projects
> expect them to be built
> * Improve compatibility with other RPM distributions that already do
> this
> * Support backend-agnostic way of building CMake projects
>
> == Scope ==
> * Proposal owners: Implement necessary macros, try to build packages
> that BuildRequires: cmake in a side tag, analyze
> failures
> and fix the relevant ones (introduced by this change).
> * Other developers: While proposal owners will try to fix all
> affected
> packages, there might be some cases where package is already FTBFS so
> the fix can't be performed. Other package maintainers will have to
> fix
> the issue themselves after they fix FTBFS.
> * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> * Policies and guidelines: CMake page will be adjusted to mention
> newly
Re: Preparing for ocaml 4.11
FWIW looks like OCaml 4.11 beta 1 was released earlier this week. https://discuss.ocaml.org/t/ocaml-4-11-first-beta-release/6042 So I will try a mass rebuild into a side tag soon, and see what the fallout is. I believe I've added all the new packages added recently to my list. I've no intention of making any changes to packaging standards or dependencies at this time, it would just be a simple rebuild using the new compiler. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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
[Test-Announce] Fedora-IoT 33 RC 20200703.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 33 RC 20200703.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200703.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20200703.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: User experience issue on btrfs
On Fri, Jul 3, 2020 at 10:37 AM Chris Murphy wrote: > To give the nodatacow suggestion a try: > ## shutdown the database > # mkdir /var/lib/mysql2 > # chattr +C /var/lib/mysql2 > # cp /var/lib/mysql/* /var/lib/mysql2/ > # rm /var/lib/mysql/ # rm -rf /var/lib/mysql/ > # mv /var/lib/mysql2/ /var/lib/mysql/ > ## resume operation BTW this should be proofread/sanity checked, especially because there's an rm command (that will fail in the original). -- 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: User experience issue on btrfs
On Thu, Jul 2, 2020 at 10:29 PM Scott Schmit wrote: > > On Sun, Jun 28, 2020 at 03:40:11PM -0600, Chris Murphy wrote: > > Databases and VM images are things btrfs is bad at out of the box. > > Most of this has to do with fsync dependency of other file systems. > > Btrfs is equipped to deal with an fsync heavy world out of the box, > > using treelog enabled by default. But can still be slow for some > > workloads. > > Does this also impact mariadb databases? I've noticed that since > reinstalling my machine with mediawiki installed, the performance of the > wiki has dropped noticeably when the cache is cold (just loading the > pages, not editing them). Good question. A complete answer leads to a lot more questions. Mariadb has a couple older docs on this: one suggests using 'noatime' mount option on all file systems [1] as an optimization, and additionally for Btrfs to use 'nodatacow' [2]. It can be set per directory or per file using 'chattr +C' before files are created - it won't work after the fact. 'chattr +C' will make files behave like it's on any other filesystem: all writes are overwrites instead of copy-on-write, no checksums, no compression. Is this stale information? Is there something unrelated going on in your case? Should databases setup these optimizations on behalf of users? Does storage type make a difference? I'm just going to set those aside for now. To give the nodatacow suggestion a try: ## shutdown the database # mkdir /var/lib/mysql2 # chattr +C /var/lib/mysql2 # cp /var/lib/mysql/* /var/lib/mysql2/ # rm /var/lib/mysql/ # mv /var/lib/mysql2/ /var/lib/mysql/ ## resume operation Advanced topic is what happens if you take a snapshot of a subvolume that includes files set to nodatacow. Short answer: you can, and it's fine. Long answer: initially this will cause datacow to resume but still without checksums and compression, new writes are temporarily datacow, subsequent writes are nodatacow. This behavior is the same as if the nodatacow file had been reflink copied, either on Btrfs or XFS. [1] https://mariadb.com/kb/en/filesystem-optimizations/ [2] https://mariadb.com/resources/blog/what-is-the-best-linux-filesystem-for-mariadb/ -- 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: [fedora-java] Questions on an update to javamail in ursine
Thanks for the insight and link Fabio and Mat. I'll look into the compatibility and verify if any changes need to be made and if so, contact the maintainers. Following a week or two for responses, I'll submit an update for rawhide. Regards, Jie Kang Senior Software Engineer, Red Hat Canada On Thu, Jul 2, 2020 at 5:54 AM Mat Booth wrote: > > > > On Wed, 1 Jul 2020 at 15:05, Fabio Valentini wrote: >> >> On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: >> > >> > Hi all, >> > >> > javamail ursine is using version 1.5.2 while there are some module >> > streams at 1.6.x >> > >> > The upstream project also moved to the eclipse foundation and these >> > 1.6.x releases have different exports for OSGi, making an update to >> > them potentially breaking for users. >> > >> > I'd like to update ursine to 1.6.x, but I understand packages >> > depending on them should be notified or some such. However I realized >> > I don't know what commands to run to get a list of such and then where >> > to send it. Could anyone advise? >> > >> > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail >> > so maybe a new package 'mail' can be introduced to use it? Any >> > thoughts there? >> >> I use this command to check for dependent packages: >> >> $ dnf --repo rawhide --repo rawhide-source --releasever rawhide >> repoquery --whatrequires javamail >> >> Which is enough, since there are no other subpackages except -javadoc. >> The command yielded (on July 1): >> >> ant-0:1.10.8-1.fc33.src >> ant-javamail-0:1.10.8-1.fc33.noarch >> bouncycastle-0:1.65-2.fc33.src >> httpunit-0:1.7-29.fc32.src >> log4j-0:2.13.1-1.fc33.src >> log4j12-0:1.2.17-26.fc32.src >> openas2-0:2.10.0-2.fc33.src >> openas2-lib-0:2.10.0-2.fc33.noarch >> >> So the list of affected packages seems to be: >> >> - ant (Stewardship / Java SIG will deal with this) >> - bouncycastle (?) > > > Bouncycastle is me (it is a dep of jgit). From reading the javamail "compat" > document: https://javaee.github.io/javamail/docs/COMPAT.txt it looks like I > probably will need to take no action at all. > > ___ > 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
[Bug 1853722] New: Include perl-XMLRPC-Lite in EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1853722 Bug ID: 1853722 Summary: Include perl-XMLRPC-Lite in EPEL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-XMLRPC-Lite Assignee: t.h.amund...@usit.uio.no Reporter: m...@clemson.edu QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, t.h.amund...@usit.uio.no Target Milestone: --- Classification: Fedora Description of problem: perl-XMLRPC-Lite is not in the EPEL 8 repository Version-Release number of selected component (if applicable): perl-XMLRPC-Lite-0.717 How reproducible: Always Steps to Reproduce: 1. dnf install perl-XMLRPC-Lite 2. 3. Actual results: Package not installed Expected results: Package installed Additional info: EPEL 7 RPM builds with no changes. -- 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
Re: [Fedora-legal-list] Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > > > > > On 01. 07. 20 16:24, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > > > > > == Summary == > > > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > > > library, which will set OpenBLAS as system-wide default backend, and > > > > at the same time will provide a proper switching mechanism that > > > > currently Fedora lacks. > > > > > > > > ... > > > > > > > > == Scope == > > > > * Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent > > > > packages to build against FlexiBLAS instead of the current backend > > > > they are using. > > > > > > I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether > > > this > > > means we would need to change the licenses of all non-GPL packages that > > > will be > > > linked to FlexiBLAS to GPL. > > > > > > CCing legal. > > > > Ok, let me recap here, because I wasn't subscribed to the legal list. > > Basically, FlexiBLAS is a wrapper for an API (BLAS/LAPACK) that is > > BSD. But to act as a wrapper, a program needs to link against the part > > of FlexiBLAS that replicates that API, and they just connect symbols > > to the appropriate backend (this is use 1). On the other hand, > > FlexiBLAS provides another API that allows programs to hook into the > > first API, profile, debug, switch the backend in real time... (this is > > use 2). > > > > Here we are talking about use 1, and the question is whether this can > > be considered under the exception of a "system library", as defined in > > the first section of GPLv3. If not, the program must be > > GPL-compatible? Or the program needs to change the license altogether? > > The "system library exception" is about allowing a GPL program to be > distributed without the source code for some of the libraries it links > to. But here we're talking about the opposite issue: whether we can > distribute *other* works linked to the GPLv3 library under their > original licenses. The "system library exception" is not relevant and > §5c says "You must license the entire work, as a whole, under this > License to anyone who comes into possession of a copy. This License > will therefore apply, along with any applicable section 7 additional > terms, to the whole of the work, and all its parts, regardless of how > they are packaged." > > FSF insists that dynamically linking with a GPL-covered work is making > a combined work based on the GPL-covered part, and thus the final > product may only be distributed under the GPL, as quoted above [1]. > I think this interpretation is dubious in some cases, but here, when > we're talking about compiling and linking programs against the GPLv3 > headers, it seems reasonable. > > If it would be possible to instead compile packages against some other > blas library, and only substitute flexiblas during dynamic linking at > users' systems, the GPLv3-covered work would only be created then and > we wouldn't need to care about licensing of other packages. That's the thing: this is certainly possible, but from the packaging point of view, it's more difficult, because BLAS and LAPACK are separate shared libraries. You could, for instance, duplicate yet again the BLAS/LAPACK interface into a single library that could be e.g. BSD, then build all the packages against that one, then provide that with FlexiBLAS instead. You could use the separate libraries libblas and liblapack and then have other stubs pointing to FlexiBLAS instead. All this is possible, but it's a ton of duplicated code, effort, etc., and it's ridiculous. So if the above it's perfectly possible and complies with the license, it's also ridiculous that avoiding this extra unnecessary stuff doesn't. > > [1] https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic > > > I contacted the upstream maintainer about this, and he really wants to > > permit the use case in this change proposal (I've been working with > > him 3 weeks to fix bugs and bring a suitable version to Fedora for > > this), so if this can't be considered a "system library", he is > > willing to add an exception to the license. This is what he told me: > > > > > About the linking problem I could think of an exception, similar to the > > > linking exception in gcc/glibc, which coincides with our "Free for free > > > use" idea. I could add that FlexiBLAS is allowed to be linked against > > > free software with an OSI approved license as none of the flexiblas > > > headers are used at compile-time. In this way all open-source software > > > can use FlexiBLAS no matter if it is BSD/MIT/APACHE/GPL code but those > > > who want to use the special features like switching BLAS within the > > > program or developing debug hooks like the profile hook, have to be > > > compatible to
[Bug 1853720] New: Update perl-HTML-Scrubber for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1853720 Bug ID: 1853720 Summary: Update perl-HTML-Scrubber for EPEL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-HTML-Scrubber Assignee: spo...@gmail.com Reporter: m...@clemson.edu QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Created attachment 1699869 --> https://bugzilla.redhat.com/attachment.cgi?id=1699869=edit Draft spec file for perl-HTML-Scrubber-0.19 Description of problem: Package not available for CentOS 8, latest version not available. Version-Release number of selected component (if applicable): perl-HTML-Scrubber-0.19 How reproducible: Always Steps to Reproduce: 1. dnf install perl-HTML-Scrubber 2. 3. Actual results: Package not found Expected results: Package installed Additional info: Build system has changed to Makefile.PL. Draft spec file attached for your review. (In particular, not sure if I have correctly handled perllocal.pod file.) -- 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
Fedora rawhide compose report: 20200703.n.0 changes
OLD: Fedora-Rawhide-20200702.n.0 NEW: Fedora-Rawhide-20200703.n.0 = SUMMARY = Added images:12 Dropped images: 4 Added packages: 15 Dropped packages:0 Upgraded packages: 84 Downgraded packages: 0 Size of added packages: 18.37 MiB Size of dropped packages:0 B Size of upgraded packages: 4.96 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 37.22 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20200703.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20200703.n.0.aarch64.raw.xz Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200703.n.0-sda.raw.xz Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20200703.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200703.n.0.s390x.raw.xz Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20200703.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20200703.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200703.n.0.s390x.qcow2 Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20200703.n.0-sda.raw.xz Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20200703.n.0.iso Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200703.n.0.s390x.vmdk Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200703.n.0.ppc64le.tar.xz = DROPPED IMAGES = Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200702.n.0.ppc64le.raw.xz Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200702.n.0.ppc64le.vmdk Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200702.n.0.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200702.n.0.ppc64le.qcow2 = ADDED PACKAGES = Package: chaos-client-0.1.4-2.fc33 Summary: Client to interact with the Chaos DNS API RPMs:chaos-client golang-github-projectdiscovery-chaos-client-devel Size:12.52 MiB Package: golang-github-aalpar-deheap-0-0.1.20200702git9a0c288.fc33 Summary: Doubly ended heap RPMs:golang-github-aalpar-deheap-devel Size:14.81 KiB Package: golang-github-btcsuite-btcutil-base58-1.0.2-1.fc33 Summary: API for encoding and decoding to and from the modified base58 encoding RPMs:golang-github-btcsuite-btcutil-base58-devel Size:134.17 KiB Package: golang-github-calebcase-tmpfile-1.0.2-1.fc33 Summary: Cross Platform Temporary Files RPMs:golang-github-calebcase-tmpfile-devel Size:14.64 KiB Package: golang-github-gin-contrib-cors-1.3.1-1.fc33 Summary: CORS gin's middleware RPMs:golang-github-gin-contrib-cors-devel Size:15.51 KiB Package: golang-github-gin-contrib-static-0-0.1.20200702gitf81c604.fc33 Summary: Static middleware RPMs:golang-github-gin-contrib-static-devel Size:14.18 KiB Package: golang-github-graph-gophers-graphql-0-0.1.20200702gitdae41bd.fc33 Summary: GraphQL server with a focus on ease of use RPMs:golang-github-graph-gophers-graphql-devel Size:141.46 KiB Package: golang-github-spacemonkeygo-monkit-3.0.6-1.fc33 Summary: Flexible process data collection, instrumentation, and tracing client library RPMs:golang-github-spacemonkeygo-monkit-devel Size:62.22 KiB Package: golang-github-vivint-infectious-0-0.1.20200702git25a574a.fc33 Summary: Reed-Solomon forward error correcting library RPMs:golang-github-vivint-infectious-devel Size:33.65 KiB Package: golang-github-zeebo-errs-2.0.1-1.fc33 Summary: Package for making errors friendly and easy RPMs:golang-github-zeebo-errs-devel Size:16.79 KiB Package: golang-github-zeebo-float16-0.1.0-1.fc33 Summary: 16 bit "floats" that can store numbers like 1.02e12 for exponents in [-15, 15] RPMs:golang-github-zeebo-float16-devel Size:14.90 KiB Package: python-aiohue-2.2.0-2.fc33 Summary: Python module to talk to Philips Hue RPMs:python3-aiohue Size:31.13 KiB Package: python-niapy-2.0.0-0.1rc10.fc33 Summary: Micro framework for building nature-inspired algorithms RPMs:python-niapy-doc python3-niapy Size:5.17 MiB Package: rust-bumpalo-3.4.0-1.fc33 Summary: Fast bump allocation arena for Rust RPMs:rust-bumpalo+boxed-devel rust-bumpalo+collections-devel rust-bumpalo+default-devel rust-bumpalo-devel Size:143.58 KiB Package: rust-wasm-bindgen-backend-0.2.64-1.fc33 Summary: Backend code generation of the wasm-bindgen tool RPMs:rust-wasm-bindgen-backend+default-devel rust-wasm-bindgen-backend+extra-tr
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
hi, > ... All the above^ is an interesting/informative read. On 7/3/20 2:31 AM, Nicolas Mailhot via devel wrote: > The requester is clearly attempting the second approach. Well, not explicitly. I'm not requesting any _specific_ approach. The goal is simply to 'build it here (locally, via mock), then build it there (remotely, on COPR)'. And have the results be the same. My general question is why what works in _mock_ here, locally, fails to work similarly on COPR. Not just rpmbuild, which I understand _is_ well integrated into my local env, but the supposedly _isolated_, basic mock env. And if it inherently does/can work similarly, what specifically I need to do/configure to get there. On 7/2/20 10:26 PM, Pavel Raiskup wrote: > and it needs to have the internet enabled at that time to > get the contents of %commitX. > > So the alternative local mock command would be: > > mock --buildsrpm --spec nginx.spec --enable-network in both cases, networking _is_ 'on' Here, the mock env is setup as cat /etc/mock/site-defaults.cfg ... config_opts['rpmbuild_networking'] = True config_opts['chroot_additional_packages'] = 'git' ... mock --init and the copr build as, copr-cli create \ --chroot fedora-32-x86_64 \ --multilib off \ --description "x" \ --instructions "x" \ --use-bootstrap on \ --enable-net on \ --unlisted-on-hp on \ On 7/3/20 12:01 AM, Nicolas Mailhot wrote: > You added some processing that depends on the git command (that > forgemeta does not use) but forgot to BuildRequire the package > providing that command. It's _clearly_ already added in my referenced spec: BuildRequires: git On 7/3/20 1:23 AM, Pavel Raiskup wrote: > I'm afraid that for building the src.rpm simply adding git to BuildRequires > will not help. Agreed; it does not. On 7/3/20 12:01 AM, Nicolas Mailhot wrote: > dead stupid (so stupid Let's chalk that up this time to 'lost in translation', shall we? > As stated before forgemeta does not depend on the git (or hg, or svn, > or…) command, it’s a pure URL munger, so it won’t pull in your scm of > choice in the buildroot. > > Presumably your workflow is so git oriented your local setup always has > git installed. I've been working with Fedora for < 2 weeks now; i.e., not much 'baggage' at all. There _is_ no "so oriented" or "always" workflow. ALL of what I'm attempting to do is simply based on new/fresh eyes reading the docs provided, and giving it a whirl. I'll certainly acknowledge the _hope_ that there's something similar to my prior build env's 'Source Services' capability, https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.source_service.html doable here. On 7/2/20 10:26 PM, Pavel Raiskup wrote: > So basically it needs to have the /bin/git installed in the chroot (it is > not by default), git _was_ trivially added to the local mock chroot, for its use, with obvious success, in the local mock build of the spec. COPR uses mock. So far, I have not seen how that's to be similarly done for the COPR env. Is is possible to, similarly, add git to the COPR mock env? ___ 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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/3/20 9:37 AM, Eric Sandeen wrote:
On 7/1/20 2:50 PM, Josef Bacik wrote:
On 7/1/20 2:24 PM, Matthew Miller wrote:
On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
could be good option. I know technically it is already opt-in, but it's not
very visible or popular. We could make the btrfs option more prominent and
ask people to pick it if they are ready to handle potential fallout.
I'm leaning towards recommending this as well. I feel like we don't have
good data to make a decision on -- the work that Red Hat did previously when
making a decision was 1) years ago and 2) server-focused, and the Facebook
production usage is encouraging but also not the same use case. I'm
particularly concerned about metadata corruption fragility as noted in the
Usenix paper. (It'd be nice if we could do something about that!)
There's only so much we can do about this. I've sent up patches to ignore
failed global trees to allow users to more easily recover data in case of
corruption in the case of global trees, but as they say if only 1 bit is off in
a node, we throw the whole node away. And throwing a node away means you lose
access to any of its children, which could be a large chunk of the file system.
This sounds like a "wtf, why are you doing this btrfs?" sort of thing, but this
is just the reality of using checksums. It's a checksum, not ECC. We don't know _which_
bits are fucked, we just know somethings fucked, so we throw it all away. If you have
RAID or DUP then we go read the other copy, and fix the broken copy if we find a good
copy. If we don't, well then there's nothing really we can do.
There is often a path forward when a bad metadata checksum is detected.
i.e. e2fsck:
scan_extent_node() {
...
/* Failed csum but passes checks? Ask to fix checksum. */
if (failed_csum &&
fix_problem(ctx, PR_1_EXTENT_ONLY_CSUM_INVALID, pctx)) {
pb->inode_modified = 1;
pctx->errcode = ext2fs_extent_replace(ehandle, 0, );
if (pctx->errcode)
return;
}
it does similarly for many types of metadata:
/* inode passes checks, but checksum does not match inode */
#define PR_1_INODE_ONLY_CSUM_INVALID0x010068
--
/* Inode extent block passes checks, but checksum does not match extent */
#define PR_1_EXTENT_ONLY_CSUM_INVALID 0x01006A
--
/* Inode extended attribute block passes checks, but checksum does not
* match block. */
#define PR_1_EA_BLOCK_ONLY_CSUM_INVALID 0x01006C
--
/* dir leaf node passes checks, but fails checksum */
#define PR_2_LEAF_NODE_ONLY_CSUM_INVALID0x02004D
Does btrfsck really never attempt to salvage a metadata block with a bad CRC by
validating its fields?
No, I suppose we could, I'll add it to the list. Generally speaking if there's
a bad checksum detected we just attempt to recover based on what we couldn't get
access to. However that's difficult if it's a node. If it's a leaf then
usually you just lose some metadata that can be inferred from other data. For
example if you lose a leaf in the extent tree, well we can add all that
information back once we've scanned the rest of the file system and know what
extents are missing in the extent tree.
Same goes for directory items, we detect that we are missing directory items,
but we have references for them and so we add the missing directory items that
were lost from that corrupt block.
But again, if you lose a node you lose access to many leaves, which makes it
more likely we'll lose somehting because we'll lose the other information we can
use to recover what was lost. The extent tree and checksum trees are exceptions
to this, since they can be rebuilt from scratch, provided everything else is fine.
And then if we did decide to validate nodes, we _might_ be ok, but we might end
up with old versions of leaves because it happens to point at something that
appears to be correct, but isn't really. Our metadata changes all the time, so
it's not outside the realm of possiblities that the corruption points at a
seemlingly valid piece of metadata, but isn't and thus makes us do something
_really_ wrong. Thanks,
Josef
___
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: booting successfully with read-only file system
On Fri, Jul 03, 2020 at 09:56:03AM -0400, Colin Walters wrote: > > > On Fri, Jul 3, 2020, at 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote: > > > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > It would be great if we could fairly reliably boot with a read-only > > > > root file system, > > > > > > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a > > > tmpfs). > > > > I see that this thread is one massive communication failure on my part :( > > > > I wrote about "booting successfully with a read-only file system", but I > > see that I didn't say "... when the disk cannot be mounted rw because of > > file system errors". I thought it'd be clear from the context, but it's > > clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose, > > It's really unfortunate how much confusion there is on the "read only" > topic... Yeah ;( > I know there's a fair amount of subtley here but I would hope at least > a few more people in the Fedora community take the time to actually > dive in to the ostree model and understand things. > > What I was pointing at is the Fedora CoreOS *LIVE* ISO, which is definitely > fully read only (or phased more usefully), does not support persistence > at all because physical ISOs don't - same as any other "Live" system > from Anaconda to all the others. > > But that's a totally distinct thing from merely having /usr mounted ro > by default, while still supporting persistence for /etc and /var (i.e. the > ostree model). Right, so IIUC, if /var is read-only, ostree will have the same problems. > > I was writing about traditional systems in a read-only-by-accident scenario, > > i.e. about the system behaving gracefully when the disk is > > ***unexpectedly*** > > read-only. > > That is an important detail indeed =) > > To be clear I agree with the effort! I think it's going to get really messy > to take it very far...and that's what I was getting at in arguing for > using overlayfs backed by tmpfs basically. This would be another approach. E.g. we systemd could detect that root cannot be remounted rw and insert the overlay. But I don't think this as useful as it sounds, because it would create a fake impression that the storage is rw. The patch for systemd to deal with ro /var/tmp for PrivateTmp=yes is careful to set things up so that the service actually gets a real EROFS error from the kernel when it writes to /var/tmp. It also gets the real EROFS when it uses StateDirectory=foo and /var/foo is ro. I think such real errors are good — they allow services which can do a graceful fallback to do it, and services which should fail to fail. So systemd-update-utmp.service may just write to utmp and warn about wtmp being inaccessible, but postgresql.service should fail to start and not accept any transactions that would then be lost upon reboot. An overlay would also make it hard to go back to normal operation. Maybe that's not so important since one can always reboot, but I think the current property of being able to fix the fs and remount it rw is quite nice. (Also, less risky then trying to reboot and realizing that there are more errors which have caused the fs to be mounted ro again.) > Or maybe it should be more like a "recovery shell" - rather than trying > to log in as your regular user and watch e.g. Firefox fail because it can't > write to /home and wonder just how much of the next years of your > life is going to involve patching software to make this work ;) > get enough to get the a desktop launched for a separate ephemeral > "live" user with sudo rights or so. I'm not sure if this is such a remote goal. Programs *should* already be prepared for reasonable read-only operation, because this can already happen for a few different reasons: apart from the fs being mounted read-only, the disk may be full or the user may exceed quota. For an application the effect is similar. And those conditions can happen at any point at runtime. Disks may also be remounted ro at runtime if errors are detected. So any applications which falls flat on its face if it cannot write to the disk is problematic already. Zbyszek ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote: > On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > > > On 01. 07. 20 16:24, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > > > == Summary == > > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > > library, which will set OpenBLAS as system-wide default backend, and > > > at the same time will provide a proper switching mechanism that > > > currently Fedora lacks. > > > > > > ... > > > > > > == Scope == > > > * Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent > > > packages to build against FlexiBLAS instead of the current backend > > > they are using. > > > > I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether this > > means we would need to change the licenses of all non-GPL packages that > > will be > > linked to FlexiBLAS to GPL. > > > > CCing legal. > > Ok, let me recap here, because I wasn't subscribed to the legal list. > Basically, FlexiBLAS is a wrapper for an API (BLAS/LAPACK) that is > BSD. But to act as a wrapper, a program needs to link against the part > of FlexiBLAS that replicates that API, and they just connect symbols > to the appropriate backend (this is use 1). On the other hand, > FlexiBLAS provides another API that allows programs to hook into the > first API, profile, debug, switch the backend in real time... (this is > use 2). > > Here we are talking about use 1, and the question is whether this can > be considered under the exception of a "system library", as defined in > the first section of GPLv3. If not, the program must be > GPL-compatible? Or the program needs to change the license altogether? The "system library exception" is about allowing a GPL program to be distributed without the source code for some of the libraries it links to. But here we're talking about the opposite issue: whether we can distribute *other* works linked to the GPLv3 library under their original licenses. The "system library exception" is not relevant and §5c says "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged." FSF insists that dynamically linking with a GPL-covered work is making a combined work based on the GPL-covered part, and thus the final product may only be distributed under the GPL, as quoted above [1]. I think this interpretation is dubious in some cases, but here, when we're talking about compiling and linking programs against the GPLv3 headers, it seems reasonable. If it would be possible to instead compile packages against some other blas library, and only substitute flexiblas during dynamic linking at users' systems, the GPLv3-covered work would only be created then and we wouldn't need to care about licensing of other packages. [1] https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic > I contacted the upstream maintainer about this, and he really wants to > permit the use case in this change proposal (I've been working with > him 3 weeks to fix bugs and bring a suitable version to Fedora for > this), so if this can't be considered a "system library", he is > willing to add an exception to the license. This is what he told me: > > > About the linking problem I could think of an exception, similar to the > > linking exception in gcc/glibc, which coincides with our "Free for free > > use" idea. I could add that FlexiBLAS is allowed to be linked against free > > software with an OSI approved license as none of the flexiblas headers are > > used at compile-time. In this way all open-source software can use > > FlexiBLAS no matter if it is BSD/MIT/APACHE/GPL code but those who want to > > use the special features like switching BLAS within the program or > > developing debug hooks like the profile hook, have to be compatible to GPL. Would the maintainer consider switching the whole thing to LGPLv3? This would preserve the freeness of his code and be much less hassle for everyone involved, with no interpretation of new legal texts required. Zbyszek ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, Jul 03, 2020 at 03:57:04PM +0200, Iñaki Ucar wrote: > On Fri, 3 Jul 2020 at 15:43, Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > > == Documentation == > > > See the > > > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md > > > README] of the upstream project and their > > > [https://www.mpi-magdeburg.mpg.de/projects/flexiblas homepage] for > > > further information about FlexiBLAS. > > > > Hmm, is there an actual repo with the code? > > gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release just contains > > fake history with one commit per release. > > That is the actual repo, and there is a mirror on GitHub to collect > public issues (https://github.com/mpimd-csc/flexiblas). > > This is because they develop and use this software for research in > high-performance computing, so the day-to-day development repo is > private (to have a competitive advantage for their publications), and > then they publish releases in those repos afterwards. Just... wow. People still believe that crap about competitive advantage. Zbyszek ___ 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: booting successfully with read-only file system
On Fri, Jul 3, 2020 at 9:56 AM Colin Walters wrote: > > What I was pointing at is the Fedora CoreOS *LIVE* ISO, which is definitely > fully read only (or phased more usefully), does not support persistence > at all because physical ISOs don't - same as any other "Live" system > from Anaconda to all the others. > This is actually not true. All Fedora live ISOs are supposed to support persistence, and can be configured that way on a USB stick using livecd-iso-to-disk from the livecd-iso-to-mediums package. However, this is not yet exposed in Fedora Media Writer. -- 真実はいつも一つ！/ 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
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 15:43, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > == Documentation == > > See the > > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md > > README] of the upstream project and their > > [https://www.mpi-magdeburg.mpg.de/projects/flexiblas homepage] for > > further information about FlexiBLAS. > > Hmm, is there an actual repo with the code? > gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release just contains > fake history with one commit per release. That is the actual repo, and there is a mirror on GitHub to collect public issues (https://github.com/mpimd-csc/flexiblas). This is because they develop and use this software for research in high-performance computing, so the day-to-day development repo is private (to have a competitive advantage for their publications), and then they publish releases in those repos afterwards. -- Iñaki Úcar ___ 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: booting successfully with read-only file system
On Fri, Jul 3, 2020, at 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote: > > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > It would be great if we could fairly reliably boot with a read-only > > > root file system, > > > > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a > > tmpfs). > > I see that this thread is one massive communication failure on my part :( > > I wrote about "booting successfully with a read-only file system", but I > see that I didn't say "... when the disk cannot be mounted rw because of > file system errors". I thought it'd be clear from the context, but it's > clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose, It's really unfortunate how much confusion there is on the "read only" topic... I know there's a fair amount of subtley here but I would hope at least a few more people in the Fedora community take the time to actually dive in to the ostree model and understand things. What I was pointing at is the Fedora CoreOS *LIVE* ISO, which is definitely fully read only (or phased more usefully), does not support persistence at all because physical ISOs don't - same as any other "Live" system from Anaconda to all the others. But that's a totally distinct thing from merely having /usr mounted ro by default, while still supporting persistence for /etc and /var (i.e. the ostree model). > I was writing about traditional systems in a read-only-by-accident scenario, > i.e. about the system behaving gracefully when the disk is ***unexpectedly*** > read-only. That is an important detail indeed =) To be clear I agree with the effort! I think it's going to get really messy to take it very far...and that's what I was getting at in arguing for using overlayfs backed by tmpfs basically. Or maybe it should be more like a "recovery shell" - rather than trying to log in as your regular user and watch e.g. Firefox fail because it can't write to /home and wonder just how much of the next years of your life is going to involve patching software to make this work ;) get enough to get the a desktop launched for a separate ephemeral "live" user with sudo rights or so. ___ 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: booting successfully with read-only file system
On Fri, Jul 03, 2020 at 01:32:12PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote: > > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > It would be great if we could fairly reliably boot with a read-only > > > root file system, > > > > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a > > tmpfs). > > I see that this thread is one massive communication failure on my part :( > > I wrote about "booting successfully with a read-only file system", but I > see that I didn't say "... when the disk cannot be mounted rw because of > file system errors". ...but Colin did not say that. Neither tmpfs nor overlayfs (backed by tmpfs) require any existing disk filesystems to be mounted read-write. TBH, that was my first thought when I read your original e-mail: "why would units fail if they only want to write non-persistent stuff to an area that may perfectly well be mounted as tmpfs, just as /run usually is?" > I thought it'd be clear from the context, but it's > clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose, > I was writing about traditional systems in a read-only-by-accident scenario, > i.e. about the system behaving gracefully when the disk is ***unexpectedly*** > read-only. > > Zbyszek > > PS. OK, I know I wrote about making it read-only on purpose using a > kernel commandline option, so really we're just pretending it was > unexpected for testing purposes, but you get what I mean I hope. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7/1/20 2:50 PM, Josef Bacik wrote:
> On 7/1/20 2:24 PM, Matthew Miller wrote:
>> On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
>>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for
>>> F34
>>> could be good option. I know technically it is already opt-in, but it's not
>>> very visible or popular. We could make the btrfs option more prominent and
>>> ask people to pick it if they are ready to handle potential fallout.
>>
>> I'm leaning towards recommending this as well. I feel like we don't have
>> good data to make a decision on -- the work that Red Hat did previously when
>> making a decision was 1) years ago and 2) server-focused, and the Facebook
>> production usage is encouraging but also not the same use case. I'm
>> particularly concerned about metadata corruption fragility as noted in the
>> Usenix paper. (It'd be nice if we could do something about that!)
>>
>
> There's only so much we can do about this. I've sent up patches to ignore
> failed global trees to allow users to more easily recover data in case of
> corruption in the case of global trees, but as they say if only 1 bit is off
> in a node, we throw the whole node away. And throwing a node away means you
> lose access to any of its children, which could be a large chunk of the file
> system.
>
> This sounds like a "wtf, why are you doing this btrfs?" sort of thing, but
> this is just the reality of using checksums. It's a checksum, not ECC. We
> don't know _which_ bits are fucked, we just know somethings fucked, so we
> throw it all away. If you have RAID or DUP then we go read the other copy,
> and fix the broken copy if we find a good copy. If we don't, well then
> there's nothing really we can do.
There is often a path forward when a bad metadata checksum is detected.
i.e. e2fsck:
scan_extent_node() {
...
/* Failed csum but passes checks? Ask to fix checksum. */
if (failed_csum &&
fix_problem(ctx, PR_1_EXTENT_ONLY_CSUM_INVALID, pctx)) {
pb->inode_modified = 1;
pctx->errcode = ext2fs_extent_replace(ehandle, 0, );
if (pctx->errcode)
return;
}
it does similarly for many types of metadata:
/* inode passes checks, but checksum does not match inode */
#define PR_1_INODE_ONLY_CSUM_INVALID0x010068
--
/* Inode extent block passes checks, but checksum does not match extent */
#define PR_1_EXTENT_ONLY_CSUM_INVALID 0x01006A
--
/* Inode extended attribute block passes checks, but checksum does not
* match block. */
#define PR_1_EA_BLOCK_ONLY_CSUM_INVALID 0x01006C
--
/* dir leaf node passes checks, but fails checksum */
#define PR_2_LEAF_NODE_ONLY_CSUM_INVALID0x02004D
Does btrfsck really never attempt to salvage a metadata block with a bad CRC by
validating its fields?
-Eric
___
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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > == Documentation == > See the > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md > README] of the upstream project and their > [https://www.mpi-magdeburg.mpg.de/projects/flexiblas homepage] for > further information about FlexiBLAS. Hmm, is there an actual repo with the code? gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release just contains fake history with one commit per release. Zbyszek ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 15:29, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jul 03, 2020 at 01:15:29PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > > == User Experience == > > > Users will have a new CLI tool, called flexiblas, which will allow > > > them to properly switch the BLAS/LAPACK backend without administrative > > > privileges and any compatibility issues. > > > > Based on this description, the switching is done by setting some flag > > in local configuration. Is there a way to set the configuration through > > an environment variable? Having only "global" configuration (in the sense > > of a single setting for a user) is going to make testing much harder, > > and also it doesn't work for the case of multiple programs being started > > independently when those programs require a different backend. > > To answer myself: $FLEXIBLAS envvar can be set. Maybe add to the description? Indeed. I'm on it. Thanks! -- Iñaki Úcar ___ 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: booting successfully with read-only file system
Hi, On 03/07/2020 14:18, Colin Walters wrote: On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: It would be great if we could fairly reliably boot with a read-only root file system, Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a tmpfs). That's what we do for Fedora CoreOS based live images, see https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/20live/live-generator It works. (Which we recently switched to involve a loopback-mounted xfs on tmpfs because SELinux, but that is mostly only necessary because we want to support Ignition which does system provisioning in the initramfs, which is not true on non-Ignition based systems) If there is additional support required in overlayfs, then please do file a bug and request it, Steve. ___ 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: booting successfully with read-only file system
On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote: > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > It would be great if we could fairly reliably boot with a read-only > > root file system, > > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a > tmpfs). I see that this thread is one massive communication failure on my part :( I wrote about "booting successfully with a read-only file system", but I see that I didn't say "... when the disk cannot be mounted rw because of file system errors". I thought it'd be clear from the context, but it's clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose, I was writing about traditional systems in a read-only-by-accident scenario, i.e. about the system behaving gracefully when the disk is ***unexpectedly*** read-only. Zbyszek PS. OK, I know I wrote about making it read-only on purpose using a kernel commandline option, so really we're just pretending it was unexpected for testing purposes, but you get what I mean I hope. ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 15:23, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > == User Experience == > > Users will have a new CLI tool, called flexiblas, which will allow > > them to properly switch the BLAS/LAPACK backend without administrative > > privileges and any compatibility issues. > > Based on this description, the switching is done by setting some flag > in local configuration. Is there a way to set the configuration through > an environment variable? Having only "global" configuration (in the sense > of a single setting for a user) is going to make testing much harder, > and also it doesn't work for the case of multiple programs being started > independently when those programs require a different backend. Yes, the FLEXIBLAS env variable overrides the system-wide and user-defined backends. So, e.g.: $ FLEXIBLAS=blis-openmp someprogram changes the backend to Blis with OpenMP support (provided that the flexiblas-blis-openmp subpackage is installed). -- Iñaki Úcar ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, Jul 03, 2020 at 01:15:29PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > == User Experience == > > Users will have a new CLI tool, called flexiblas, which will allow > > them to properly switch the BLAS/LAPACK backend without administrative > > privileges and any compatibility issues. > > Based on this description, the switching is done by setting some flag > in local configuration. Is there a way to set the configuration through > an environment variable? Having only "global" configuration (in the sense > of a single setting for a user) is going to make testing much harder, > and also it doesn't work for the case of multiple programs being started > independently when those programs require a different backend. To answer myself: $FLEXIBLAS envvar can be set. Maybe add to the description? Zbyszek ___ 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: booting successfully with read-only file system
On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > It would be great if we could fairly reliably boot with a read-only > root file system, Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a tmpfs). That's what we do for Fedora CoreOS based live images, see https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/20live/live-generator It works. (Which we recently switched to involve a loopback-mounted xfs on tmpfs because SELinux, but that is mostly only necessary because we want to support Ignition which does system provisioning in the initramfs, which is not true on non-Ignition based systems) ___ 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: booting successfully with read-only file system
On Thu, Jul 2, 2020, at 12:05 PM, Daniel P. Berrangé wrote: > I presume you're referring to regular Fedora here, but this description > feels like it is approx asking for what Fedora Silverblue has delivered, > only with the writable area for apps being just a ram disk with no > persistence. No no no! That's *not at all* what it is. I am actually kind of at war with the "immutable" terminology because it's more isleading than it is accurate. https://blog.verbum.org/2019/12/23/starting-from-open-and-foss/ is a bit related to this. /etc and /var are fully persistent! It's just an "image based" update system, and /usr is read-only by default, but you can still layer/override packages, and in the future I'd like to make it easier to use ostree to persist non-rpm changes. ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > == User Experience == > Users will have a new CLI tool, called flexiblas, which will allow > them to properly switch the BLAS/LAPACK backend without administrative > privileges and any compatibility issues. Based on this description, the switching is done by setting some flag in local configuration. Is there a way to set the configuration through an environment variable? Having only "global" configuration (in the sense of a single setting for a user) is going to make testing much harder, and also it doesn't work for the case of multiple programs being started independently when those programs require a different backend. Zbyszek ___ 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: out of Koji disk space
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote: > On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote: > > I will file a ticket after Spot says his opinion (or not). > > Sure. https://src.fedoraproject.org/rpms/chromium/pull-request/27 ___ 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: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Wed, Jul 01, 2020 at 10:36:59AM +0200, Benjamin Berg wrote: > On Tue, 2020-06-30 at 17:48 +0200, Vitaly Zaitsev via devel wrote: > > On 30.06.2020 15:25, Ben Cotton wrote: > > > Better thermal management and peak performance on Intel CPUs by > > > including thermald in the default install. > > > > Good, but thermald is absolutely useless without configs. Configs can be > > extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. > > But, this is not true in general and we can expect further improvements > in the near future. It will not help in all situations, but there are > situations where users will see improved performance. One example of > this is for example an improved peak-performance on pre-Kabylake > systems (I am looking into finding further examples). > > > So, it is true that thermald will throw around quite a few warnings at > startup (it seems to warn about anything it probes and cannot find). > But that does not imply that it is always useless. It does for example > use information from the PPCC tables even if it does not have any > configuration. These power limits are exported by the kernel in > /sys/bus/pci/devices/*/power_limits/. That is worrying. We already have plenty of services which spam the logs with pointless warnings, leading to bad UX. I think fixing this should be a prerequisite to enabling by default. > Also, some reverse engineering work has been happening. This means that > it is possible to improve thermald to get at least some of the benefits > of a DPTF based configuration without needing dptfxtract. This is > currently still work in progress, however, upstream is planning to > merge this work once it has been cleaned up sufficiently. > > i.e. at this point we can fully expect to get improved thermal > management based on the DPTF tables without dptfxtract. So... could we arrange it so that thermald only runs if there's actually a benefit from it running? E.g. exit quietly if it realizes it cannot do anything useful for the hardware present? > > Also Fedora cannot ship extracted by dptfextract configs due to their > > legal status. > > The idea to ship those configurations separately has been dropped from > the proposal. The proposal says "Proposal owners: - Include the thermald package in the default Workstation install". Do you want it be enabled by default? If yes, the proposal should say that. Zbyszek ___ 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: booting successfully with read-only file system
On 03.07.2020 13:42, Neal Gompa wrote: > Ubuntu's MOTD requires network connectivity to function, I think ours > would not. That would eliminate the network resource contention issues > you were seeing. The good MOTD is an empty MOTD. -- 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: booting successfully with read-only file system
On 03.07.2020 08:07, Zbigniew Jędrzejewski-Szmek wrote: > Ubuntu's MOTD are well known and people seem to like them a > lot. Fedora hasn't been making that much use of them. But I think we > should in general. Ubuntu MOTD contains ads. Most of Ubuntu users completely disable it right after the installation. -- 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: booting successfully with read-only file system
On Fri, Jul 3, 2020 at 6:50 AM Roberto Ragusa wrote: > > On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote: > > > Ubuntu's MOTD are well known and people seem to like them a > > lot. Fedora hasn't been making that much use of them. But I think we > > should in general. > > Do not follow Ubuntu on this too much. > I've had a case of a machine with many short-lived incoming ssh connections > where the performance bottleneck was the constant regeneration of > the motd on each login. Sabotaging that stuff brutally was the only way > to get back to good performance. > Ubuntu's MOTD requires network connectivity to function, I think ours would not. That would eliminate the network resource contention issues you were seeing. -- 真実はいつも一つ！/ 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
Re: out of Koji disk space
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote: > I have fixed the buildhw-x86 boxes, they all now have ~365GB now. Yes, it has built fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=46455864 > Sorry, I misunderstood you... I thought you were wanting to test a > scratch build that needed more space. You are proposing a change that > will make official chromium builds take that extra space always? Yes (I can do scratch builds on my machine faster). But I have succeeded getting buildhw-* only on the 4th time. > Our very fast a64 builders do not always have that amount of space, so > it would have to fall back to the aarch64 buildvm's in that arch. aarch64 needs 187G + BUILDROOT (which got deleted), it may be 205GB total. i686 cannot build chromium with debuginfo as linker runs out of 32-bit address space, one would have to cross-build it which is sure not worth it. > > I will file a ticket after Spot says his opinion (or not). > > Sure. Spot has not said anyway yet. Jan ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Fri, Jul 3, 2020 at 1:18 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > > So all those people are happy with vi? IMHO an argument for changing > > this would be that a lot of people are already changing EDITOR to nano, > > so it makes sense to make it a default. If this is actually not the > > case it is not very convincing to change this. > > I think people may not be happy with something, but if it's not trivial to > change > (and knowing that EDITOR may be set in bash configuration, but the > variable has to be exported, and then you need to reload the shell config > because > the change does not take effect immediately is not trivial), they will > continue to use the default as long as they are able to get by. > Or they just try Fedora and immediately mark it as a distro not for them. Because when they do "git commit" in Ubuntu, it opens up a reasonably user friendly editor (nano). When they do it in Fedora, it opens up a screen they don't even know how to exit (vi). If I were a new user to Linux, it would be clear to me which distribution is for me and which one is definitely not. ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 13:02, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 20:16:36 +0200 > Iñaki Ucar wrote: > > > No, this is exactly the wrong way around. You should use the serial > > > library for code that you want to be running in serial (this way you > > > can get several instances of the program running efficiently), and > > > the pthreads version if you want to run the BLAS/LAPACK regions in > > > parallel (but are somehow opposed to OpenMP!).. > > > > I think I'm more confused than before. :D > > > > > > The question of the default is a hard one. What happens if a > > > > multithreaded application that does not use OpenMP is linked with > > > > the OpenMP build of OpenBLAS? > > > > > > Then you get too much parallellism, i.e. every call to OpenBLAS will > > > launch several threads, and this will naturally ruin your scaling. > > > > So would you say that openblas-serial is the most sensible > > system-wide default? > > THERE SHOULD BE NO SYSTEM-WIDE DEFAULT. > > The thing is that the maintainer needs to be able to pick the correct > flavor. If you use the wrong one, you may seriously handicap > performance. I don't agree, because in many (most?) programs you never know what kind of workload is going to run. E.g., in R, octave... there may be parallelization involved, there are packages using OpenMP... Then, even if there really is a best option for a certain program, the maintainer would need to know, which I don't think is a good assumption (see Jerry's comments in this thread). Even if there is a recommendation from upstream, many times it's not the best option either. > But, if one *needs* a system-wide default, in my opinion it > should be the OpenMP version, since it plays well together with both > sequential and OpenMP parallel programs. Thanks. In my opinion, we need a system-wide default, plus we will be offering the most safe and straightforward way to change the backend. And then, if a particular package really needs a particular flavour and really there are arguments not to allow users to switch it, then an exception could be granted for that package. -- Iñaki Úcar ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Fri, Jul 03, 2020 at 11:08:01AM +0200, Till Maas wrote: > On Tue, Jun 30, 2020 at 09:01:21AM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote: > > > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote: > > > > > > > While it may be worth vim making themselves better, it really doesn't > > > > change the argument. > > > > > > > > Even a friendlier vim is still going to be far to strange and > > > > confusing to somebody just looking to quickly change a setting and get > > > > on with Fedora. > > > > > > The argument in the change proposal is that users might not know what is > > > going on when they run `git commit` and vi instead of nano is opened. It > > > does not mention "quickly changing a setting". Thinking more about this, > > > if someone has to use "git commit", they have probably changed > > > something with a tool. If this is a developer, they are probably using a > > > graphical IDE or a text editor on the console (or maybe a GUI text > > > editor). > > > > > But I guess the IDEs usually have git integration, so the user > > > would then not use "git commit". > > Plenty of people use graphical editors without git integration. But > > even if the editor has integration, people will often have been taught > > or have learnt themselves to use a git from the command line and will > > continue doing that. In many ways the cli is more convenient, so if you > > once learnt that, you're unlikely to switch away. > > IT seems that the persona that is targeted by this change is changing a > lot. Initially, it was about newcomers but someone who already learned > git from the command-line does not seem to be a newcomer. In my experience, some basic familiarity with git is nowadays fairly common. Many people do some kind of data processing as students, and it may be done using python or ipython notebook or R and open source libraries. Such people will be using the terminal for this as a tool, without spending too much time on bash or shell or other basic tools that we take for granted. Another group is people who open the terminal based on some instructions on the web. "Open a terminal, run 'systemctl edit foo.service', and add '...'." So yeah, as I understand this, there is no one well defined target, but rather various heterogeneous partially overlapping groups. > > > If they already use a console editor, > > > would it be typical that they do not set the EDITOR variable? > > In my experience, people set $EDITOR very rarely. > > So all those people are happy with vi? IMHO an argument for changing > this would be that a lot of people are already changing EDITOR to nano, > so it makes sense to make it a default. If this is actually not the > case it is not very convincing to change this. I think people may not be happy with something, but if it's not trivial to change (and knowing that EDITOR may be set in bash configuration, but the variable has to be exported, and then you need to reload the shell config because the change does not take effect immediately is not trivial), they will continue to use the default as long as they are able to get by. > > > And if they are using a graphical Editor, shouldn't maybe that one be > > > defaulted to in graphical environments? > > I replied to that earlier — short summary is that having the editor pop > > outside of the terminal window is confusing. We want the default editor > > to be in-terminal and block the terminal until the edit is done. > > There can also be some text in the console that explains that the user > should look at the window for the GUI editor and the editor helper could > block the console until the edit is done. git-mergetool works just fine > with meld, for example. Also I know people using gvimdiff instead of > vimdiff. This would be a possibility. But it's rather complicated, and requires us to change the default anyway... And we'd need to do something different for ssh connections. I like the original simple proposal better. Zbyszek ___ 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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 20:16:36 +0200 Iñaki Ucar wrote: > > No, this is exactly the wrong way around. You should use the serial > > library for code that you want to be running in serial (this way you > > can get several instances of the program running efficiently), and > > the pthreads version if you want to run the BLAS/LAPACK regions in > > parallel (but are somehow opposed to OpenMP!).. > > I think I'm more confused than before. :D > > > > The question of the default is a hard one. What happens if a > > > multithreaded application that does not use OpenMP is linked with > > > the OpenMP build of OpenBLAS? > > > > Then you get too much parallellism, i.e. every call to OpenBLAS will > > launch several threads, and this will naturally ruin your scaling. > > So would you say that openblas-serial is the most sensible > system-wide default? THERE SHOULD BE NO SYSTEM-WIDE DEFAULT. The thing is that the maintainer needs to be able to pick the correct flavor. If you use the wrong one, you may seriously handicap performance. But, if one *needs* a system-wide default, in my opinion it should be the OpenMP version, since it plays well together with both sequential and OpenMP parallel programs. -- Susi Lehtola Fedora Project Contributor jussileht...@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: booting successfully with read-only file system
On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote: Ubuntu's MOTD are well known and people seem to like them a lot. Fedora hasn't been making that much use of them. But I think we should in general. Do not follow Ubuntu on this too much. I've had a case of a machine with many short-lived incoming ssh connections where the performance bottleneck was the constant regeneration of the motd on each login. Sabotaging that stuff brutally was the only way to get back to good performance. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: The future of legacy BIOS support in Fedora.
Hi On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote: > > None of those bugs were release blocking, and none of them meant that x86 > wouldn't boot, or that core packages didn't work > When you add so many qualifiers, you are now admitting a) you did get a response b) that things weren't perfect as you claimed. Those were merely examples anyway. You can find plenty more in past discussions long before the decision was made. You cannot possibly believe that an architecture maintenance only involves a handful of bugs. It requires substantial resources which aren't free. If you want to reduce your claim to the "many bugs that did exist and added additional maintenance burden didn't affect me personally therefore I disagree with the decision made", now that would be a more reasonable statement if one didn't keep bringing it up in unrelated discussions. Rahul ___ 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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit : > > I'd appreciate the link to spectool rewrite, though. Here it is: https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit : > On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel > wrote: > > it will certainly be possible to compute a second level of sources > > during the dynamic buildrequires first pass over prep, and the > > change > > makes the forge macro code modular enough the second level will be > > auto-registered in sourcelist, but how is the buildsystem supposed > > to > > provide sources that did not exist during its first pass over the > > spec > > file? > > Possible. But I personally think that "dynamic buidlrequires" should > stay > working with BuildRequires, not Sources. > > > and Fabio’s most excellent rewrite of the spectool code (if you > > have > > not used it yet, try it, it’s good). However someone needs to add > > lookaside or buildsys integration to spectool to spectool so > > spectool > > has something to source new sources from in a restricted build > > context. > > Let me just state my opinion that I don't like this situation coming. > Packaging should be simple task, and should be made simpler, obvious. I understand. There is just this huge pressure in npm, and go and rust, and all other modern languages, and even in git itself via submodules, to create huge dependency graphs of interlinked components. You can attempt, like we (me at least) to make individual component packaging as easy and cheap as possible. That still costs you one spec file per git repo, and forces you to treat git submodules as separate projects. It is possible the pressure will continue to grow to a point that a spec needs to automate not just the top-level component but all the other bits upstreams hide bellow this component. If that happens we will need dynamic sourcing in spec files. There is huge pressure EL side at least to get this second scenario to work (in part, due to EL management putting hard constrains on introduction of new srpms, forcing EL packagers to stuff as many things as possible into existing spec files). The requester is clearly attempting the second approach. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le vendredi 03 juillet 2020 à 09:48 +0200, Pierre-Yves Chibon a écrit : > On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote: > > Nicolas Mailhot wrote: > > > The same process that commits a new state of the changelog file > > > in > > > sources, > > > commits the date that was written in the changelog in a separate > > > key = > > > value > > > file (with the components of the build evr, the last packager id, > > > etc). > > > > Do you mean that the key/value file will be committed to Git from > > inside > > Koji? Do the Koji builders have write access to Git? > > This is the part that worries me a little about this approach. > Builders currently do not have commit access to git and I'm not sure > if we want them to considering they have git installed (so they can > clone) as well as access to all the packages in dist-git from a > networking point of view (again so they can clone). > So if we were to give the builders commit access to dist-git, an > attacker could easily commit to any other packages, potentially from > something as easy as a scratch-build. From a purely architecture POW I’m convinced the proposed approach is the correct approach. Anything else proposed so far involves: – tying a low-level event like "build occurred at date XXX" to high- level Fedora infra (making our workflow non portable and incompatible with downstreams and third parties) – taking bets in git that a build will occur and succeed (before it actually occurs and succeeds, in real life builds fail for various reasons), and – attempting to munge spec file behind the packager back (unlikely to work fine the more automated and dynamic we made those). However, because it’s the correct architecture solution, it also forces to make hard architectural choices, instead of mixing unrelated things in git and pretending that makes the result fine. Mixing unrelated things in a pile of container or git poo and pretending the result is fine is exactly what I hate in contenerish build workflows and why I work on rpm packaging. From a pure high-level view, the thing in our infra that gates builds and decides whether they are official or scratched is bodhi. So if you want to push Fedora release logic to its ultimate conclusion, the thing that should be in charge of committing the new release/changelog build state to package history in git is bodhi, not koji. And you can put security related checks there, since deciding to push things to users requires security related checks anyway (that probably also involves branching while a bodhi update is in flight and not approved yet). However, that’s if you want to push the model to its ultimate conclusion and have something nice solid, automated, and future-proof. If you don’t want to touch bodhi, and it you do not want koji to commit to git (which, is not the best of things for the reasons you stated, and for the reasons I stated), you can just: – make the koji client return the URL that will contain the SRPM at the end of the build process if it succeeds. – have the person of script that called the koji client (and has, presumably, write access to the corresponding packages) consult the build results later – and have this person or script decide if he or it wants to commit the build result to history or not That’s the REST way of doing things. It’s a co-out because you push hard commit decisions to the client, but it’s a prefectly valid approach. The commit decision exists with or without my change, it’s just people have (successfully) convinced themselves git is magic and git makes release decisions go away. You could also try to filter source files to limit the back commit to specific files. But really, if you don’t trust your build process to modify files in a secure way, you should not distribute the produced RPMs in the first place. > rpmautospec relies on git tags to store the build info, could it be > considered here? As explained above, that does not solve any of the hard problems, that handwaves them away by pretending that because someone filled some metadata in git, it corresponds to the actual build state. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Tue, Jun 30, 2020 at 09:01:21AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote: > > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote: > > > > > While it may be worth vim making themselves better, it really doesn't > > > change the argument. > > > > > > Even a friendlier vim is still going to be far to strange and > > > confusing to somebody just looking to quickly change a setting and get > > > on with Fedora. > > > > The argument in the change proposal is that users might not know what is > > going on when they run `git commit` and vi instead of nano is opened. It > > does not mention "quickly changing a setting". Thinking more about this, > > if someone has to use "git commit", they have probably changed > > something with a tool. If this is a developer, they are probably using a > > graphical IDE or a text editor on the console (or maybe a GUI text > > editor). > > > But I guess the IDEs usually have git integration, so the user > > would then not use "git commit". > Plenty of people use graphical editors without git integration. But > even if the editor has integration, people will often have been taught > or have learnt themselves to use a git from the command line and will > continue doing that. In many ways the cli is more convenient, so if you > once learnt that, you're unlikely to switch away. IT seems that the persona that is targeted by this change is changing a lot. Initially, it was about newcomers but someone who already learned git from the command-line does not seem to be a newcomer. > > If they already use a console editor, > > would it be typical that they do not set the EDITOR variable? > In my experience, people set $EDITOR very rarely. So all those people are happy with vi? IMHO an argument for changing this would be that a lot of people are already changing EDITOR to nano, so it makes sense to make it a default. If this is actually not the case it is not very convincing to change this. > > And if they are using a graphical Editor, shouldn't maybe that one be > > defaulted to in graphical environments? > I replied to that earlier — short summary is that having the editor pop > outside of the terminal window is confusing. We want the default editor > to be in-terminal and block the terminal until the edit is done. There can also be some text in the console that explains that the user should look at the window for the GUI editor and the editor helper could block the console until the edit is done. git-mergetool works just fine with meld, for example. Also I know people using gvimdiff instead of vimdiff. Thanks Till ___ 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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel wrote: > it will certainly be possible to compute a second level of sources > during the dynamic buildrequires first pass over prep, and the change > makes the forge macro code modular enough the second level will be > auto-registered in sourcelist, but how is the buildsystem supposed to > provide sources that did not exist during its first pass over the spec > file? Possible. But I personally think that "dynamic buidlrequires" should stay working with BuildRequires, not Sources. > and Fabio’s most excellent rewrite of the spectool code (if you have > not used it yet, try it, it’s good). However someone needs to add > lookaside or buildsys integration to spectool to spectool so spectool > has something to source new sources from in a restricted build context. Let me just state my opinion that I don't like this situation coming. Packaging should be simple task, and should be made simpler, obvious. That said, I like that package build is just: SPEC + sources + patches + build dependencies I'd appreciate the link to spectool rewrite, though. Pavel ___ 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: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Friday, July 3, 2020 9:48:06 AM CEST Pierre-Yves Chibon wrote: > So if we were to give the builders commit access to dist-git, an attacker > could easily commit to any other packages, potentially from something as easy > as a scratch-build. Absolutely! Koji authenticates build submitters (I'm not sure it authorizes them). So technically, _something_ on backend could be allowed to commit to dist-git (in the name of build submitter). Before the SRPM build task, Koji could request "GetReleaseBumpPatch" task, the builder could then just read-only clone the git, bump the release, return the patch back for backend -- and let Koji apply it. But yeah, that's off topic a bit. This is not what the current proposal is about. Pavel ___ 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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 34 System-Wide Change proposal
Le vendredi 03 juillet 2020 à 10:06 +0200, Pierre-Yves Chibon a écrit : > On Thu, Jul 02, 2020 at 03:44:51PM +0200, Nicolas Mailhot via devel > wrote: > > Le 2020-07-02 15:11, Kamil Dudka a écrit : > > > On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via > > > devel wrote: > > > > If there is buy-in, it will be implemented by goodwill people. > > > > If there > > > > is no buy-in, it won’t, normal community development process. > > > > Put > > > > yourself in the category you want to be in, your choice, not > > > > mine. > > > > > > I believe that Change submission guidance is pretty clear on > > > this: > > > > > > "If you have improvement in mind, work to get implementers > > > committed > > > to the effort _before_ filing a Change proposal, rather than > > > expecting > > > them to show up for work once the Change is accepted." > > > > This is a F34 Change (not that it could not be done for F33 if > > people were willing). > > This is apparently something that was missed, just by seeing the > subject of this > thread. Yes, sorry, I see our dear release wrangler missed that I was crazy enough to submit both a last-day F33 change and a prospective F34 change (both dealing with essentially the same codebase). It’s a F34 change, anyone can check in the wiki history it never pretended to be anything else. Now it is doable for F33 too (at least on my side) by that may be overly ambitious infra-side. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On Friday, July 3, 2020 9:01:16 AM CEST Nicolas Mailhot wrote: > Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit : > > Hi, > > As usual for those things the reason is dead stupid (so stupid the > human brain refuses to see it) > > > submitting the _same_ spec to COPR for online build FAILS @, > > supposedly, similar Mock build > > > > Here's a diff > > > > https://www.diffchecker.com/izjQYkUF > > > > The fail log is full of > > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > sh: git: command not found > > You added some processing that depends on the git command (that > forgemeta does not use) but forgot to BuildRequire the package > providing that command. I'm afraid that for building the src.rpm simply adding git to BuildRequires will not help. Pavel > As stated before forgemeta does not depend on the git (or hg, or svn, > or…) command, it’s a pure URL munger, so it won’t pull in your scm of > choice in the buildroot. > > Presumably your workflow is so git oriented your local setup always has > git installed. > > Regards, > > ___ 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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit : Hi, As usual for those things the reason is dead stupid (so stupid the human brain refuses to see it) > submitting the _same_ spec to COPR for online build FAILS @, > supposedly, similar Mock build > > Here's a diff > > https://www.diffchecker.com/izjQYkUF > The fail log is full of sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found sh: git: command not found You added some processing that depends on the git command (that forgemeta does not use) but forgot to BuildRequire the package providing that command. As stated before forgemeta does not depend on the git (or hg, or svn, or…) command, it’s a pure URL munger, so it won’t pull in your scm of choice in the buildroot. Presumably your workflow is so git oriented your local setup always has git installed. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: List of long term FTBFS packages to be retired in August
Would you mind to follow this page to get sponsored? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Also, it would be probably good to join the Node.js SIG to coordinate and start contributing via PRs. While I could sponsor you, I don't think I'd be good mentor for node packaging. Sorry. Vít Dne 02. 07. 20 v 13:42 Alexandre de Farias napsal(a): > In fact, I am not at this time. > > On Wed, 2020-07-01 at 15:38 +0200, Vít Ondruch wrote: >> Hi Alexandre, >> >> Thank you for your offer. I just wonder, are you sponsored into >> packager group? >> >> >> >> Vít >> >> >> >> >> >> Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a): >>> I'm interested in helping with those NodeJS packages. >>> >>> -- >>> Alexandre de Farias / etinin >>> >>> On Mon, Jun 29, 2020, 12:50 Vít Ondruch >>> wrote: Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a): > js-jquery1 nodejs-sig, patches, vondruch Fedora 30 > js-jquery2 vondruchFedora 30 > js-sizzle nodejs-sig, patches, vondruch Fedora 30 I was ranting about js-jquery (and js-sizzle is dependency of js- jquery) on this list already several times. I picked it up just to keep it alive in whatever state, because bundling it everywhere won't make things better. So is there anybody who would like to give it some love? Or should I let the packages finally go and let everybody else to bundle whatever they want? Vít ___ 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 >> ___ >> 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 ___ 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: The future of legacy BIOS support in Fedora.
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit : > > 5-10 years? A better estimate would be 15-20 years. People aren't > > going to > > throw away perfectly fine systems and jump to new "cloud" platforms > > just > > because the OS they were using dropped BIOS support. They'll just > > stop > > updating, and likely move to something that is still supporting > > BIOS, if they > > don't write their own installer and just continue using Fedora, > > given that > > this is an entirely artificial limitation. > > > While I completely hear you on the fact that people will often sweat > assets for years longer than accounting schedules suggest they > should, do you really think they're going to write custom > installers??? They’re going to move to forks of Fedora downstreams (as AWS and others already did). (this is not an endorsement of any other position in this thread, I hate all our bootloaders equally, they’ve been a lost cause since someone decided to hide the bootloader menu in the default install, making it something that does not exist… till you need it an realize the state it’s in). Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Thu, Jul 02, 2020 at 03:44:51PM +0200, Nicolas Mailhot via devel wrote: > Le 2020-07-02 15:11, Kamil Dudka a écrit : > >On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via > >devel wrote: > >>If there is buy-in, it will be implemented by goodwill people. > >>If there > >>is no buy-in, it won’t, normal community development process. Put > >>yourself in the category you want to be in, your choice, not mine. > > > >I believe that Change submission guidance is pretty clear on this: > > > >"If you have improvement in mind, work to get implementers > >committed > >to the effort _before_ filing a Change proposal, rather than > >expecting > >them to show up for work once the Change is accepted." > > This is a F34 Change (not that it could not be done for F33 if > people were willing). This is apparently something that was missed, just by seeing the subject of this thread. Pierre ___ 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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le 2020-07-02 15:11, Kamil Dudka a écrit : On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via devel wrote: If there is buy-in, it will be implemented by goodwill people. If there is no buy-in, it won’t, normal community development process. Put yourself in the category you want to be in, your choice, not mine. I believe that Change submission guidance is pretty clear on this: "If you have improvement in mind, work to get implementers committed to the effort _before_ filing a Change proposal, rather than expecting them to show up for work once the Change is accepted." This is a F34 Change (not that it could not be done for F33 if people were willing). It was filled at the same time as the F33 change because it’s the logical continuation of the F33 change and people were sure to ask about it in the other change discussion (as they did). I believe a full cycle is largely enough to get people used to the idea and committed or not. It was split from the F33 change to give this cycle for things to mature. The F33 change is continuation of work I began in 2017, and has served Fedora well since, and the same objections were raised against the 2017 change, and the same empty promises were made by naysayers that they would do better someday, and 2+ years later no one has seen any part of their alternative implementation in real life (laughably, some of the naysayers complained it was not documented well enough, and blocked the documentation merge later when it was provided). Also the naysayers are not the ones that would do the implementation since no one sane would count on them to do anything anyway. The work is done, anyone can get the SRPMS in the copr and check by himself that they do autobump and auto changelog, there are minor blockers because the feature changes slightly the point at which the SRPM should be collected in the build process, but they are *minor*, not anything that requires a huge re-architecture of current tooling. Which is pretty cool because current tooling was not designed around this feature, and yet it works fine, with minor adjustments. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
Le jeudi 02 juillet 2020 à 17:44 -0400, Josef Bacik a écrit : > However just because we know something > went wrong doesn't mean we can do anything about it, it just means > that the user knows now that they need to restore from backups That’s a perfect answer for an Enterprise server setup with systematic backup/restore procedures. For workstations? Even in an Enterprise context? Not so much. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
Le vendredi 03 juillet 2020 à 07:26 +0200, Pavel Raiskup a écrit : Hi, > I'm not familiar with the %forge* macros, but I don't think it is > expected that you will add commands that need the Internet into the > macro definition. It’s neither expected nor unexpected. For a Fedora-oriented spec, of course you should never depend on Internet ability. For you own needs, both mock and copr allow enabling the internet. forge macros do not enforce a specific policy. The main showstopper will be that if the additional commands need to process files in sources, you need to run %prep first, and %prep depends on sources being set, so you’ll be in a chicken and egg situation. Now, we’ve been moving to more dynamic spec contruction in the last years, so I can see it being possible in the near feature if everyone makes a goodwill effort, but right now that is not possible. With the dynamic buildrequires part rpm upstream added, and with https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs it will certainly be possible to compute a second level of sources during the dynamic buildrequires first pass over prep, and the change makes the forge macro code modular enough the second level will be auto-registered in sourcelist, but how is the buildsystem supposed to provide sources that did not exist during its first pass over the spec file? That probably involves running spectool by default over %sourcelist at the start of %prep, which, again, should be doable easily with https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs and Fabio’s most excellent rewrite of the spectool code (if you have not used it yet, try it, it’s good). However someone needs to add lookaside or buildsys integration to spectool to spectool so spectool has something to source new sources from in a restricted build context. If anyone is interested in doing the spectool/buildsys integration part, we can fill a change for F34. It’s another example, like autobumping, of high level build features that were devilishly hard to implement before something like %auto_call was available, and is pretty simple to do with %auto_call implemented Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
Le July 2, 2020 2:47:49 PM UTC, Vitaly Zaitsev via devel a écrit : >On 02.07.2020 11:27, Nicolas Mailhot wrote: >> Why? Koji schedules a build. The build registers its own build date >in >> the produced packages. Koji decides to keep and commit the result, or >> drop it (scratch build, failed side tag, whatever). Koji is still in >> charge, the bumping is just integrated in the build process with the >> rest of the package creation. > >Koji was just an example. %changelog section should be auto-generated >from commits messages. I don't want to maintain a separate file with >the changelog. The feature is completely compatible with this workflow. It registers build events in a detached file (the only part of the rpm changelog that requires knowledge of the rpm format) You can prime this file via git hooks or any other system you like, the feature will take it as is, add the timestamp the build occurred at, and feed the result to the correct parts of the rpm build process. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote: > Nicolas Mailhot wrote: > > The same process that commits a new state of the changelog file in > > sources, > > commits the date that was written in the changelog in a separate key = > > value > > file (with the components of the build evr, the last packager id, etc). > > Do you mean that the key/value file will be committed to Git from inside > Koji? Do the Koji builders have write access to Git? This is the part that worries me a little about this approach. Builders currently do not have commit access to git and I'm not sure if we want them to considering they have git installed (so they can clone) as well as access to all the packages in dist-git from a networking point of view (again so they can clone). So if we were to give the builders commit access to dist-git, an attacker could easily commit to any other packages, potentially from something as easy as a scratch-build. rpmautospec relies on git tags to store the build info, could it be considered here? It may make things a little safer as we could then restrict the access of that user/ssh key to only git tags (or do like rpmautospec and query pagure's API to have it create the git tag, thus dropping the need for ssh key). Pierre pgpTnAYdhtGD_.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
[Bug 1708214] Upgrade perl-Net-DNS-SEC to 1.17
https://bugzilla.redhat.com/show_bug.cgi?id=1708214 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade perl-Net-DNS-SEC to |Upgrade perl-Net-DNS-SEC to |1.15|1.17 --- Comment #6 from Jitka Plesnikova --- Latest Fedora delivers 1.12 version. Upstream released 1.17. When you have free time, please upgrade it. -- 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 1853574] New: Devel::Cover produces warning about build vs runtime perl mismatch
https://bugzilla.redhat.com/show_bug.cgi?id=1853574 Bug ID: 1853574 Summary: Devel::Cover produces warning about build vs runtime perl mismatch Product: Fedora Version: 32 Status: NEW Component: perl-Devel-Cover Assignee: spo...@gmail.com Reporter: g...@cfware.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Description of problem: Using Devel::Cover in Fedora 32 produces a warning. Version-Release number of selected component (if applicable): perl-Devel-Cover-1.33-4.fc32.x86_64 perl-interpreter-5.30.3-453.fc32.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Execute `cover` Actual results: Warning/error is printed: This version of Devel::Cover was built with Perl version 5.030001. It is now being run with Perl version 5.030003. Attempting to make adjustments, but you may find that some of your modules do not have coverage data collected. You may need to alter the +-inc, +-ignore and +-select options. Expected results: No warning about version mismatches. Additional info: Actual coverage results seem to be fine. This issue was previously fixed in Fedora 30, see https://bugzilla.redhat.com/show_bug.cgi?id=1767477. Sorry if I was supposed to comment on the old ticket instead of opening a new bug. Is it possible to patch away this version check or set some sort of Fedora policy where perl-Devel-Cover automatically gets rebuilt each time a perl update is released? -- 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 1853570] New: Upgrade perl-Image-ExifTool to 12.00
https://bugzilla.redhat.com/show_bug.cgi?id=1853570 Bug ID: 1853570 Summary: Upgrade perl-Image-ExifTool to 12.00 Product: Fedora Version: rawhide Status: NEW Component: perl-Image-ExifTool Assignee: spo...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Latest Fedora delivers 11.85 version. Upstream released 12.00. When you have free time, please upgrade it. -- 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
LWN: btrfs @ Facebook (Make btrfs the default file system for desktop variants)
Hi, During 2020 Open Source Summit North America, Josef shared some details about how btrfs excels in production at Facebook. And where the problems were. I cannot find the recording, but the write up is at Linux Weekly News: https://lwn.net/SubscriberLink/824855/e601d11e157e1b4a/ I highly recomend it. Also, consider subscribing to LWN – it's an invaluable source of high quality writing. -- Tomasz Torcz “Never underestimate the bandwidth of a station to...@pipebreaker.plwagon filled with backup tapes.” — Jim Gray ___ 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
[Bug 1853569] New: Upgrade perl-File-Slurp to 9999.32
https://bugzilla.redhat.com/show_bug.cgi?id=1853569 Bug ID: 1853569 Summary: Upgrade perl-File-Slurp to .32 Product: Fedora Version: rawhide Status: NEW Component: perl-File-Slurp Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers .30 version. Upstream released .32. When you have free time, please upgrade it. -- 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 1853567] New: Upgrade perl-Calendar-Simple to 2.0.0
https://bugzilla.redhat.com/show_bug.cgi?id=1853567 Bug ID: 1853567 Summary: Upgrade perl-Calendar-Simple to 2.0.0 Product: Fedora Version: rawhide Status: NEW Component: perl-Calendar-Simple Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.23 version. Upstream released 2.0.0. When you have free time, please upgrade it. -- 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
Re: The future of legacy BIOS support in Fedora.
On Thursday, July 2, 2020 11:45:09 PM MST Christopher Engelhard wrote: > Can we maybe not restart this entire debate? i686 in Fedora has run down > the curtain and joined the choir invisible. Whether we think that was > the correct decision or not, there is absolutely no point in rehashing > all the original arguments, let alone in a thread about BIOS support. Well, it's a very similar issue. Let's not break what works, needlessly, as was done with i686. -- John M. Harris, Jr. ___ 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
