Re: Mass spec file change: Adding BuildRequires: make
On 11/30/20 2:06 PM, Tom Stellard wrote: Hi, As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed. If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update. I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes: Dec 14: Update first 50 packages. The 50 packages I'll update on Dec. 14 are listed here: https://fedorapeople.org/~tstellar/br_make_day1.txt -Tom Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages. The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20). Thanks, Tom [1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.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
Fedora-Cloud-33-20201212.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201211.0): ID: 739284 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/739284 ID: 739291 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/739291 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python-pytest-randomly changing license from BSD to MIT
Starting from version 3.5.0 the python-pytest-randomly package has changed license from BSD to MIT. I will build this update for rawhide shortly. -- Dan Callaghan ___ 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: End of CentOS Linux: What about Fedora?
On Fri, Dec 11, 2020 at 06:39:52PM -0500, Matthew Miller wrote: > On Sat, Dec 12, 2020 at 12:21:02AM +0100, Kevin Kofler via devel wrote: > > It is still a form of a rolling release though, just one with branches. I > > think it was actually clear to most of the readers that CentOS Stream is > > not > > Rawhide directly (because then it would be Rawhide, not CentOS Stream), but > > that CentOS Stream 8 is the RHEL 8 branch that was branched from Rawhide at > > some point early in RHEL 8 development and that of course no longer tracks > > Rawhide, but only gets what is intended to land in RHEL 8 at some point. > > (At > > least to me, this was always clear.) > > I'm glad to hear it, because it definitely was not clear to many, and I was > starting to feel like "many" might be "everyone". :) It's confusing if you aren't inside this baseball game I would imagine... The diagram on https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/ I think might help? https://blog.centos.org/wp-content/uploads/2020/12/fedora-centos-stream-rhel-high-level.v4.png > > But even though each CentOS Stream "release" is a stable branch of > > Rawhide, it still in many ways behaves like Rawhide or another rolling > > release rather than like a release. Here in Fedora, we are used to getting > > lots of updates to packages, so we may be fine with such a rolling branch > > (though from the description, I would expect CentOS Stream to be more like > > Fedora updates- testing than like Fedora stable updates, or is there > > already strict RHEL QA before something reaches even CentOS Stream?), but > > There is already RHEL QA before it reaches Stream. I can't honestly speak to > how strict it is, and of course people's standards for that will vary. https://blog.centos.org/2020/12/how-rhel-is-made/ has some more details. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 06:21:50PM -0500, Neal Gompa wrote: > > In the interest of me being lazy more successfully, can I glom my "change > > the menu" proposal onto this new Change you are spearheading? :) :) :) > Oi, oi! I have enough changes for this cycle. If you want to spearhead > this, I can help, though. :) I just saw that the strings are all hard-coded in livecd-creator, and while I know how to Python enough to do something about it, it'd be even more awesome if someone in the top, say, 5 contributors https://github.com/livecd-tools/livecd-tools/graphs/contributors would help, yes. :) -- Matthew Miller Fedora Project Leader ___ 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: Koji Offline - Infrastruture Status page says : all fine ?
On Fri, Dec 11, 2020 at 09:49:12PM +, Richard W.M. Jones wrote: > I think package signing is still broken? > > Someone reported on that nothing has been signed for the past 7 hours, > and I've certainly got one package which has remained unsigned for > several hours: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1657566 It's not broken... it's signing the 8000+ packages that landed in eln-signing-pending. ;( Ideally it would have some way to process them other than the order in which the fedora-message arrives, but currently it just processes them as it gets them. ;( it's down to about 3500 now... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: End of CentOS Linux: What about Fedora?
On Sat, Dec 12, 2020 at 12:21:02AM +0100, Kevin Kofler via devel wrote: > It is still a form of a rolling release though, just one with branches. I > think it was actually clear to most of the readers that CentOS Stream is not > Rawhide directly (because then it would be Rawhide, not CentOS Stream), but > that CentOS Stream 8 is the RHEL 8 branch that was branched from Rawhide at > some point early in RHEL 8 development and that of course no longer tracks > Rawhide, but only gets what is intended to land in RHEL 8 at some point. (At > least to me, this was always clear.) I'm glad to hear it, because it definitely was not clear to many, and I was starting to feel like "many" might be "everyone". :) > But even though each CentOS Stream "release" is a stable branch of > Rawhide, it still in many ways behaves like Rawhide or another rolling > release rather than like a release. Here in Fedora, we are used to getting > lots of updates to packages, so we may be fine with such a rolling branch > (though from the description, I would expect CentOS Stream to be more like > Fedora updates- testing than like Fedora stable updates, or is there > already strict RHEL QA before something reaches even CentOS Stream?), but There is already RHEL QA before it reaches Stream. I can't honestly speak to how strict it is, and of course people's standards for that will vary. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 3:09 PM Matthew Miller wrote: > > On Fri, Dec 11, 2020 at 02:22:28PM -0500, Neal Gompa wrote: > > > I'm not horribly opposed. I just don't want scope creep to mean we can't > > > make a pretty easy change. > > Well, we have to change it in both places anyway. :) > > Dropping isolinux just means we have one less menu to maintain. > > In the interest of me being lazy more successfully, can I glom my "change > the menu" proposal onto this new Change you are spearheading? :) :) :) > Oi, oi! I have enough changes for this cycle. If you want to spearhead this, I can help, though. :) -- 真実はいつも一つ！/ 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: End of CentOS Linux: What about Fedora?
Gordon Messmer wrote: > The release announcement was confusing, in that it used "rolling > release" to describe something that doesn't resemble the common > definition of that term. > > CentOS Stream isn't a rolling release. It will have distinct major > releases. It just won't have point releases within those cycles. > CentOS Stream 8 will just be CentOS Stream 8 for 5 years, and never > CentOS Stream 8.1, etc. It is still a form of a rolling release though, just one with branches. I think it was actually clear to most of the readers that CentOS Stream is not Rawhide directly (because then it would be Rawhide, not CentOS Stream), but that CentOS Stream 8 is the RHEL 8 branch that was branched from Rawhide at some point early in RHEL 8 development and that of course no longer tracks Rawhide, but only gets what is intended to land in RHEL 8 at some point. (At least to me, this was always clear.) But even though each CentOS Stream "release" is a stable branch of Rawhide, it still in many ways behaves like Rawhide or another rolling release rather than like a release. Here in Fedora, we are used to getting lots of updates to packages, so we may be fine with such a rolling branch (though from the description, I would expect CentOS Stream to be more like Fedora updates- testing than like Fedora stable updates, or is there already strict RHEL QA before something reaches even CentOS Stream?), but many current CentOS users have chosen CentOS (rather than Fedora or even a true rolling-release distribution such as Arch) exactly because it does NOT work like that. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On Sat, Dec 12, 2020 at 12:40:15AM +0200, Nikolay Nikolov wrote: > So, how can I experience a corrupt install, due to media failure, > since I specifically run the media check to ensure this doesn't > happen, before I attempt an install? Just because I haven't > experienced it, since I always run the test, doesn't mean it won't > happen when people skip the media test. What I'm saying is: yes, people might experience errors, but in the case they do, it's almost always very obvious. So we're adding extra steps and confusion for most people who won't experience errors, and not adding much value to people who do. But I'm happy with the proposal to move the check to troubleshooting. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On 12/12/20 12:20 AM, Matthew Miller wrote: On Sat, Dec 12, 2020 at 12:15:07AM +0200, Nikolay Nikolov wrote: there's even less reason to skip it. Which really begs the question, why do we even assume the media test is only useful for DVD and not for USB flash? I gave those reasons in my initial message? Have you experienced a specific case where bad USB media caused a corrupt install? No, but I have the habit to always run the media check, before attempting install, so it's unlikely that I've encountered an error like that, since I don't attempt to install from media that fails the test. I only skip the media test in two cases: a) installing in a VM b) installing from a media I've already verified (e.g. when installing on several computers from the same USB flash or DVD, I only verify it the first time for USB, and for DVD, I use the "verify" option in the DVD burning software, so I skip the option even during the first install) So, how can I experience a corrupt install, due to media failure, since I specifically run the media check to ensure this doesn't happen, before I attempt an install? Just because I haven't experienced it, since I always run the test, doesn't mean it won't happen when people skip the media test. Nikolay ___ 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: Proposal: drop "Test installation media" from live media
On Sat, Dec 12, 2020 at 12:15:07AM +0200, Nikolay Nikolov wrote: > there's even less reason to skip it. Which really begs the question, > why do we even assume the media test is only useful for DVD and not > for USB flash? I gave those reasons in my initial message? Have you experienced a specific case where bad USB media caused a corrupt install? -- Matthew Miller Fedora Project Leader ___ 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: End of CentOS Linux: What about Fedora?
On Fri, Dec 11, 2020 at 12:49:23PM -0800, Gordon Messmer wrote: > The release announcement was confusing, in that it used "rolling > release" to describe something that doesn't resemble the common > definition of that term. Yeah, that was accidental — written in good faith by someone who doesn't live and breathe enthusiast Linux distros and didn't anticipate what it would mean to many people. As I understand it that's actually been edited, but the damage is done so we're hearing it a lot and it got picked up in the press. Everything you say is exactly true. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On 12/11/20 8:55 PM, Vitaly Zaitsev via devel wrote: On 11.12.2020 19:07, Matthew Miller wrote: I think since burning spinning optical media is no longer the normal way to do this, we should drop this and just go straight to booting (unless of course a key is hit to stop things and enter boot parameters). USB flash drive can be broken too. I suggest moving it to the Troubleshooting sub-menu instead of completely removing it. I agree. I like to run the test even from USB flash. In fact, strange as it may sound, I've found flash drives to be less reliable in that tools that people use to dump the image to a flash drive don't always do the right thing. DVD burner software always writes the image correctly to a DVD-R or DVD+R disc and usually has an option to verify the burn, which I always use. USB writers often contain bugs or don't verify the written data, so I don't trust any install that haven't booted and run the media self test, regardless of whether it's USB flash or DVD (it's mostly USB flash these days, but I still use DVD for certain systems, where I have trouble booting from USB, due to BIOS bugs). And if I skip the test, it's usually for optical media, not for USB, where I trust the USB writer tools less. And if an install fails, due to failure in the optical media, I usually get useful feedback from the drive (characteristic sound), which makes it clear that the failure is due to unreliable disc or drive, while on USB you usually get nothing, except broken data. Also, the media test is actually faster on USB flash, so there's even less reason to skip it. Which really begs the question, why do we even assume the media test is only useful for DVD and not for USB flash? Nikolay ___ 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: Koji Offline - Infrastruture Status page says : all fine ?
I think package signing is still broken? Someone reported on that nothing has been signed for the past 7 hours, and I've certainly got one package which has remained unsigned for several hours: https://koji.fedoraproject.org/koji/buildinfo?buildID=1657566 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))
On Thu, Dec 10, 2020 at 12:52 PM Matthew Miller wrote: > Thanks for filing this, and I'll highlight it for the modularity team's > attention. Thanks. I also filed https://pagure.io/fm-orchestrator/issue/1629 a while back. I think this could help users understand MBS a bit better. - Ken ___ 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: Working recovery with locked root user (rescue.service)
On Thu, Dec 10, 2020, at 5:56 PM, Chris Murphy wrote: > I personally am gravitating toward the idea of not updating the > currently running OS (sometimes called transactional system updates) > where if we had a way to test the out-of-band updated OS, like in a > container or VM, We've been doing that for over 3 years now in rpm-ostree: https://github.com/coreos/rpm-ostree/pull/892 Yeah there's obviously *more* we could do than run just /bin/true, including running systemd-in-container but that escalates quickly in scope. (I was going to write more here about how the real problem composes should be tested/promoted but we're already doing that in FCOS by entangling our build and test system, and we can take up the discussion of the relationship between that and traditional Fedora in the edition discussions) ___ 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: End of CentOS Linux: What about Fedora?
On 12/9/20 5:07 AM, Jaroslav Prokop wrote: Instead I would like LTS system that I comfortable with, which is from the RHEL ecosystem. ... If I understood the announcement, it would be a kind of CentOS streams is rolling release or a release with short release interval. The release announcement was confusing, in that it used "rolling release" to describe something that doesn't resemble the common definition of that term. CentOS Stream isn't a rolling release. It will have distinct major releases. It just won't have point releases within those cycles. CentOS Stream 8 will just be CentOS Stream 8 for 5 years, and never CentOS Stream 8.1, etc. It's also not going to have short release intervals. It will be released every three years, and maintained for five years. CentOS Stream has all of the aspects of an "LTS" release, but you will not hear Red Hat use that term with respect to CentOS Stream, because "support" is the product that Red Hat sells, and there isn't any for CentOS Stream. If you're looking for an rpm-based distribution that's self-supported and maintained for longer than a Fedora release, then CentOS Stream might be a really good option. ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 02:22:28PM -0500, Neal Gompa wrote: > > I'm not horribly opposed. I just don't want scope creep to mean we can't > > make a pretty easy change. > Well, we have to change it in both places anyway. :) > Dropping isolinux just means we have one less menu to maintain. In the interest of me being lazy more successfully, can I glom my "change the menu" proposal onto this new Change you are spearheading? :) :) :) -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On 11.12.2020 20:18, Neal Gompa wrote: This would probably be easier if we dropped isolinux and used grub2 for BIOS ISO boot just like we do for UEFI ISO boot. +1 for this. -- 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: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On 09.12.2020 19:44, Ben Cotton wrote: The nodejs libraries have been approved to be bundled, and there is infrastructure in place for the bundling to work properly. And what about adding Provides: bundled(nodejs-foo) = version? There were many nodejs packages with backdoors in npm. That's why versions need to be tracked. I think Fedora can reuse the flatpak-node-generator from Flatpak: https://github.com/flatpak/flatpak-builder-tools/tree/master/node -- 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: Pre-made live image with actual functioning persistent storage?
On 12/11/20 1:48 PM, Matthew Miller wrote: We're going to spend some of our remaining budget on a swag refresh, and as part of that, we're getting some shiny new USB sticks, and partly considering the recent discussion about making it easy for new users to try without committing, we're getting ones with decent speed and quality and room for a persistent overlay. It has been approximately a decade since I made such an image. Does anyone have a recipe for creating one with persistent storage (and possibly a separate home filesystem, or however that should be set up on btrfs?) I'm going to be less than helpful with specifics, but btrfs has this feature called "seed devices" that allows you to generate a btrfs device that is read only. The mechanical steps are here https://btrfs.wiki.kernel.org/index.php/Seed-device This is actually what we use for all of our network switches inside FB, we generate a seed image that is dd'ed onto the devices. On bootup they find the other partition on the device and add it to the boot up device (which is the seed device) before the remount rw step, which gives you the scratch space. This scratch space is cleared on reboot because the seed device is the boot target and since it's RO it can't be modified to know anything about the scratch device. This provides a kind neat/clean way to make the live environment permanent. Simply btrfs device add /dev/whatever /, btrfs device delete /dev/seed /, btrfs device delete /dev/scratch-partition /. This copies all of the data we need from the seed device to the local drive and then you're good to go. Obviously the boot loader needs to do its boot loader thing and such, but the copy is nice and efficient. There's no tooling for this, but if one wanted to build tooling around it then this would be the way to do it generally. Not super helpful for you right now, but in case anybody is bored and looking for something to do, this is how I would do it. 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 2:21 PM Matthew Miller wrote: > > On Fri, Dec 11, 2020 at 02:18:38PM -0500, Neal Gompa wrote: > > This would probably be easier if we dropped isolinux and used grub2 > > for BIOS ISO boot just like we do for UEFI ISO boot. > > I'm not horribly opposed. I just don't want scope creep to mean we can't > make a pretty easy change. > Well, we have to change it in both places anyway. :) Dropping isolinux just means we have one less menu to maintain. -- 真実はいつも一つ！/ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 02:18:38PM -0500, Neal Gompa wrote: > This would probably be easier if we dropped isolinux and used grub2 > for BIOS ISO boot just like we do for UEFI ISO boot. I'm not horribly opposed. I just don't want scope creep to mean we can't make a pretty easy change. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 2:06 PM Matthew Miller wrote: > > On Fri, Dec 11, 2020 at 10:37:01AM -0800, Adam Williamson wrote: > > > Let's just go ahead and get people started faster. > > > > Could we maybe just bump it down to the 'troubleshooting' menu or > > whatever it's labelled there and have it not be the default, rather > > than remove it entirely? > > Sure, that seems okay too. In doing that, I suggest we change from: > > _S_tart Fedora-Worksation-Live 33 > Test this _m_edia & start Fedora-Workstation-Live 33 > > Troubleshooting > > to > > _1_. Start Fedora Workstation Live 33 > _2_. Troubleshooting options... > > ...where previously S and m are a slightly different color, which is Secret > DOS Application UI Code for "if you wanted, you could press this letter > instead of using the arrow keys" -- let's use numbers instead, which both > make it more obvious that this is menu of options and are logical easy > things to press. > > The troubleshooting menu currently has help text which appears for some of > the options. We could add some friendly text like: > > "Press Enter to start a live environment which you can experiment with > without making any permanent changes, or use to easily install Fedora > Workstation to your hard drive." > > I'd also like to reduce the timeout from 60 seconds to 15 or something, but > I won't fight anyone on that. > This would probably be easier if we dropped isolinux and used grub2 for BIOS ISO boot just like we do for UEFI ISO boot. -- 真実はいつも一つ！/ 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: Introduction
On Fri, Dec 11, 2020 at 01:51:29PM -0500, LinuxGeek46 wrote: > Hello - my name is David Both and I want to introduce myself. Ankur > Sinha "FranciscoD" is mentoring me as I start with Fedora Fusion package > maintenance. Awesome, welcome! -- Matthew Miller Fedora Project Leader ___ 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: Pre-made live image with actual functioning persistent storage?
On Fri, Dec 11, 2020 at 10:57:30AM -0800, Adam Williamson wrote: > su -c "livecd-iso-to-disk --home-size-mb 2048 > Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" My complication is: we need to have an image that has all of this pre-made to give to the vendor. If I do the above to a loopback device, will that result in a file I can just give them? -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 10:37:01AM -0800, Adam Williamson wrote: > > Let's just go ahead and get people started faster. > > Could we maybe just bump it down to the 'troubleshooting' menu or > whatever it's labelled there and have it not be the default, rather > than remove it entirely? Sure, that seems okay too. In doing that, I suggest we change from: _S_tart Fedora-Worksation-Live 33 Test this _m_edia & start Fedora-Workstation-Live 33 Troubleshooting to _1_. Start Fedora Workstation Live 33 _2_. Troubleshooting options... ...where previously S and m are a slightly different color, which is Secret DOS Application UI Code for "if you wanted, you could press this letter instead of using the arrow keys" -- let's use numbers instead, which both make it more obvious that this is menu of options and are logical easy things to press. The troubleshooting menu currently has help text which appears for some of the options. We could add some friendly text like: "Press Enter to start a live environment which you can experiment with without making any permanent changes, or use to easily install Fedora Workstation to your hard drive." I'd also like to reduce the timeout from 60 seconds to 15 or something, but I won't fight anyone on that. -- Matthew Miller Fedora Project Leader ___ 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: Koji Offline - Infrastruture Status page says : all fine ?
Am 11.12.20 um 19:37 schrieb Kevin Fenzi: It's back up. There is some power work being done at the datacenter and one virthost (The one that has the koji database vm of course) lost power. :( I can't comment on the mirrors, those should be all over the world, so perhaps you are just hitting a slow one near you? I tried it several times over, getting different mirrors ( i hope ) and they all failed, while i got 10mb/s from stable mirros for F33. atm it's ftp.rrze.uni-erlangen.de. So no connection to the koji datacenter. best regards, Marius ___ 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: Pre-made live image with actual functioning persistent storage?
On Fri, 2020-12-11 at 13:48 -0500, Matthew Miller wrote: > We're going to spend some of our remaining budget on a swag refresh, and as > part of that, we're getting some shiny new USB sticks, and partly > considering the recent discussion about making it easy for new users to try > without committing, we're getting ones with decent speed and quality and > room for a persistent overlay. > > It has been approximately a decade since I made such an image. Does anyone > have a recipe for creating one with persistent storage (and possibly a > separate home filesystem, or however that should be set up on btrfs?) AFAIK it *should* still work as documented on the old wiki page: https://fedoraproject.org/w/index.php?title=How_to_create_and_use_Live_USB&oldid=504045#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29 "To include a persistent filesystem for /home, use the --home-size-mb parameter. For example: su -c "livecd-iso-to-disk --home-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" This will create a 2 GiB filesystem that will be mounted as /home each time the stick is booted, allowing you to preserve data in /home across boots. To enable 'data persistence' support - so changes you make to the entire live environment will persist across boots - add the --overlay- size-mb parameter to add a persistent data storage area to the target stick. For example: su -c "livecd-iso-to-disk --overlay-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" where 2048 is the desired size (in megabytes) of the overlay. The livecd-iso-to-disk tool will not accept an overlay size value greater than 4095 for VFAT, but for ext[234] filesystems it is only limited by the available space." I have no idea when is the last time anyone tested this. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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: Proposal: drop "Test installation media" from live media
On 11.12.2020 19:07, Matthew Miller wrote: I think since burning spinning optical media is no longer the normal way to do this, we should drop this and just go straight to booting (unless of course a key is hit to stop things and enter boot parameters). USB flash drive can be broken too. I suggest moving it to the Troubleshooting sub-menu instead of completely removing it. -- 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: Pre-made live image with actual functioning persistent storage?
On 11.12.2020 19:48, Matthew Miller wrote: It has been approximately a decade since I made such an image. Does anyone have a recipe for creating one with persistent storage (and possibly a separate home filesystem, or however that should be set up on btrfs?) sudo livecd-iso-to-disk --efi --format --overlay-size-mb 2048 --home-size-mb 2048 --label Fedora /path/to/Fedora-Workstation-Live-x86_64-32-1.6.iso /dev/sdX -- 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
Introduction
Hello - my name is David Both and I want to introduce myself. Ankur Sinha "FranciscoD" is mentoring me as I start with Fedora Fusion package maintenance. I have been working with computers for just a bit over 50 years now, and almost 25 with Linux, most of which is Red Hat (old), RHEL, CentOS, and Fedora. I am not going to give you my life story - at least as it relates to computers - because you can get that from my web site. http://www.both.org/?page_id=2 Suffice it to say that I have never used Windows as a primary OS on any of my own computers. Ever. DOS=>TopView=>OS/2=>Linux. I am honored to be part of this team and I look forward to contributing in a more active way. Thanks! -- * David P. Both, RHCE linuxgee...@both.org @LinuxGeek46 He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * ___ 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
Pre-made live image with actual functioning persistent storage?
We're going to spend some of our remaining budget on a swag refresh, and as part of that, we're getting some shiny new USB sticks, and partly considering the recent discussion about making it easy for new users to try without committing, we're getting ones with decent speed and quality and room for a persistent overlay. It has been approximately a decade since I made such an image. Does anyone have a recipe for creating one with persistent storage (and possibly a separate home filesystem, or however that should be set up on btrfs?) -- Matthew Miller Fedora Project Leader ___ 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
Mobility SIG meeting - 2020-12-14 16:30UTC
Greetings everyone. I'd like to announce the next Mobility SIG meeting for next monday (2020-12-14) at 16:30UTC in #fedora-meeting. A tenative agenda: * introductions * status / plans on current remix * status / plans for next step remix with fedora kernel + patches and images built on copr * status / plans for official kickstart/images * All other business Our current efforts are focused on the pine64 pinephone, but other devices welcome. Please add / suggest topics at: https://pagure.io/fedora-mobility/issue/1 We plan to meet monthly on the second monday of the month moving foward. Please join us! More information at: https://fedoraproject.org/wiki/Mobility https://fedoraproject.org/wiki/Architectures/ARM/PinePhone Lets ramp up our pinephone efforts! kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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: Koji Offline - Infrastruture Status page says : all fine ?
On Fri, Dec 11, 2020 at 07:21:37PM +0100, Marius Schwarz wrote: > Am 11.12.20 um 19:16 schrieb Marius Schwarz: > > > > Hi, > > > > Koji has an Outtage. No Idea it it's planned or a failure. According to > > https://status.fedoraproject.org/ ist should work. > > > > > > Now it's marked down. Also, AARCH64 Rawhide mirros are slow as snakes were > in 1999. It's back up. There is some power work being done at the datacenter and one virthost (The one that has the koji database vm of course) lost power. :( I can't comment on the mirrors, those should be all over the world, so perhaps you are just hitting a slow one near you? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: drop "Test installation media" from live media
On Fri, 2020-12-11 at 13:07 -0500, Matthew Miller wrote: > Right now, when you start Fedora live media to install Workstation or KDE or > etc., you get an ugly text prompt which defaults to doing a media test > (although it's not actually even clear from the highlighting that that's the > default). > > I think since burning spinning optical media is no longer the normal way to > do this, we should drop this and just go straight to booting (unless of > course a key is hit to stop things and enter boot parameters). > > In my experience with USB sticks (and i've probably made over 500 of 'em in > the last few years), the most likely failure modes are like this: > > 1) Doesn't even write properly. > 2) Doesn't boot after you created it. > 3) Fails hard and it's definitely done > 4) Random transient errors > > The test media option doesn't actually help with any of these except maybe > making #3 happen slightly sooner. With #4, it actually means that in some > cases you'd be fine just doing the install and the test fails. > > Let's just go ahead and get people started faster. Could we maybe just bump it down to the 'troubleshooting' menu or whatever it's labelled there and have it not be the default, rather than remove it entirely? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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: Koji Offline - Infrastruture Status page says : all fine ?
On Fri, 11 Dec 2020 at 13:18, Marius Schwarz wrote: > > Hi, > > Koji has an Outtage. No Idea it it's planned or a failure. According to > https://status.fedoraproject.org/ ist should work. > > The page also says that things are manually done to that page. We have to stop working on fires to change that page and most of the time it is back working before the aws push happens. > best regards, > Marius > ___ > 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 > -- Stephen J Smoogen. ___ 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: Koji Offline - Infrastruture Status page says : all fine ?
Am 11.12.20 um 19:16 schrieb Marius Schwarz: Hi, Koji has an Outtage. No Idea it it's planned or a failure. According to https://status.fedoraproject.org/ ist should work. Now it's marked down. Also, AARCH64 Rawhide mirros are slow as snakes were in 1999. Best regards, Marius ___ 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
Koji Offline - Infrastruture Status page says : all fine ?
Hi, Koji has an Outtage. No Idea it it's planned or a failure. According to https://status.fedoraproject.org/ ist should work. best regards, Marius ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 01:12:05PM -0500, Mauricio Tavares wrote: > I thought you could either bypass or cancel the installation media test. You can, but: 1) it's the default 2) skipping it isn't clearly obvious, especially if you've never used a pre-VGA DOS appliation (*) 3) just having the text mode thing show up signals complexity * I mean, seriously! -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop "Test installation media" from live media
On Fri, Dec 11, 2020 at 1:08 PM Matthew Miller wrote: > > Right now, when you start Fedora live media to install Workstation or KDE or > etc., you get an ugly text prompt which defaults to doing a media test > (although it's not actually even clear from the highlighting that that's the > default). > > I think since burning spinning optical media is no longer the normal way to > do this, we should drop this and just go straight to booting (unless of > course a key is hit to stop things and enter boot parameters). > > In my experience with USB sticks (and i've probably made over 500 of 'em in > the last few years), the most likely failure modes are like this: > > 1) Doesn't even write properly. > 2) Doesn't boot after you created it. > 3) Fails hard and it's definitely done > 4) Random transient errors > > The test media option doesn't actually help with any of these except maybe > making #3 happen slightly sooner. With #4, it actually means that in some > cases you'd be fine just doing the install and the test fails. > > Let's just go ahead and get people started faster. > I thought you could either bypass or cancel the installation media test. > -- > Matthew Miller > > Fedora Project Leader > ___ > 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
Proposal: drop "Test installation media" from live media
Right now, when you start Fedora live media to install Workstation or KDE or etc., you get an ugly text prompt which defaults to doing a media test (although it's not actually even clear from the highlighting that that's the default). I think since burning spinning optical media is no longer the normal way to do this, we should drop this and just go straight to booting (unless of course a key is hit to stop things and enter boot parameters). In my experience with USB sticks (and i've probably made over 500 of 'em in the last few years), the most likely failure modes are like this: 1) Doesn't even write properly. 2) Doesn't boot after you created it. 3) Fails hard and it's definitely done 4) Random transient errors The test media option doesn't actually help with any of these except maybe making #3 happen slightly sooner. With #4, it actually means that in some cases you'd be fine just doing the install and the test fails. Let's just go ahead and get people started faster. -- Matthew Miller Fedora Project Leader ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Fri, Dec 11, 2020 at 3:18 AM Till Maas wrote: > > Hi, > > this does not seem to be self-contained, since it seems to affect people > outside the SIG (it states that this is also affecting packages that are > not owned by the SIG). > > On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > == Summary == > > > > For Nodejs, Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > > > == Owner == > > > > * Name: [[User:tdawson| Troy Dawson]] > > * Email: tdaw...@redhat.com > > * Name: [[User:sgallagh| Stephen Gallagher]] > > * Email: sgall...@redhat.com > > * Name: > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] > > * Email: nod...@lists.fedoraproject.org > > > > > > == Detailed Description == > > > > The nodejs libraries have been approved to be bundled, and there is > > infrastructure in place for the bundling to work properly. Currently, > > What does this infrastructure look like? How does it help with > addressing security issues in the bundles components effectivly? > > > it is recommended that packagers should create individual nodejs > > library packages instead of bundling all of the libraries into the > > package requiring them. > > The subject says "Stop Shipping Individual Nodejs Library Packages", > therefore it would be more clear to block all Nodejs libraries in Fedora > instead of only recommending this. Otherwise it will be some half-baked > solution that is probably confusing (Why are some libraries packaged and > others bundled?). > > > This change is to make it default to bundle the nodejs libraries with > > the package that needs them, and retire the vast majority of nodejs > > library packages. > > In summary, for Nodejs Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > This should also include the tooling that is needed to manage the > bundling. > > > > == Feedback == > > > > There has been a discussion on the fedora nodejs mailing list about > > what to do with the extreme dependency problem of the nodejs library > > packages. Because of the extreme inter-dependency, upgrading almost > > any package causes others to break. It has caused most packages to > > rot, remaining on unsupported versions for years. Many of the nodejs > > packagers are giving up and orphaning their packages, which has caused > > even more problems. > > > > An initial proposal was to find all of the important nodejs library > > packages and bundle those, making them easier to upgrade and maintain. > > But there was problems with figuring out what was important, and what > > versions should those have. During that discussion, this rather > > extreme solution of getting rid of all nodejs libraries was proposed. > > To our surprise, it has been the best received suggestion and fixes > > the most problems. > > What problems remain? > > > > > == Benefit to Fedora == > > > > * In Fedora 33, there are many nodejs libraries that are > > uninstallable, thus causing other programs based off them to also be > > uninstallable. This gets rid of that problem. > > * Packages in Fedora that use nodejs libraries will be able to use the > > library versions that upstream has tested and approved. > > * If a package in Fedora uses a nodejs library, the packager will not > > have to also package extra individual nodejs library packages. There > > have been times this has led to over 100 extra packages, each with > > their own package reviews and maintenance problems. This change will > > lower the workload on that packager, and possibly get more packages > > into Fedora. > > * The nodejs maintainers can concentrate on nodejs itself, instead of > > the whole nodejs library infrastructure. > > * Nodejs developers using Fedora will no longer have to worry about > > Fedora's global nodejs libraries causing conflicts or inconsistencies. > > > > == Scope == > > * Proposal owners: > > We will go through the Fedora release and determine what nodejs > > packages Fedora should package. We will implement nodejs library > > bundling on those we already own. For those that we do not own, we > > will work with their owners to implement nodejs library bundling. > > What about future packagers? How will they learn/be enabled to do it the > right way? > > > As packages implement nodejs library bundling, we will monitor the > > nodejs libraries and note which ones are no longer required. When > > they are no longer re
Re: Fedora 34 Change proposal: Boost 1.75 upgrade (System-Wide Change)
Il 10/12/20 19:21, Kevin Fenzi ha scritto: > > A self-managed side-tag: > * Easy to create, has random name > * Needs provenpackager or commit to all builds in tag to merge > FYI Starting from Bodhi 5.6.0 whoever owns (creates) the side-tag can push the update even if they don't have commit rights to all packages. Mattia ___ 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 34 Change proposal: Boost 1.75 upgrade (System-Wide Change)
On 12/10/20 7:21 PM, Kevin Fenzi wrote: On Thu, Dec 10, 2020 at 08:01:31AM +, Zbigniew Jędrzejewski-Szmek wrote: I wonder: is it necessary to request a tag, or would just self-managed side-tag be enough? A releng made side-tag: * has a specific name * requires releng ticket to create * requires releng to merge builds back in Also: * builds are merged directly to rawhide, no CI (broken stuff can be pushed in) A self-managed side-tag: * Easy to create, has random name * Needs provenpackager or commit to all builds in tag to merge Also: * builds go trough bodhi, where they can be stuck on gating on tests that refuse to start or gating on tests that don't even exist, or gating on tests that reveal that one package is broken for (un)related reasons and block the entire update (is very tedious to work with with large updates) Since trodgers isn't a provenpackager, probibly the releng one would be best? But also I guess fixing and rebuilding the other packages will need commit or provenpackager... Even for bumping the release a provenpackager will be needed. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
20/12/3 03:39(e)an, Dusty Mabe igorleak idatzi zuen: I 100% would like to get to a point where we rebase to the latest Fedora major soon after release. As jlebon mentioned earlier this does mean working harder to get ahead of the curve by adopting a rawhide development stream (not exposed to users) and taking more part in the Changes process. Why should we hide coreos rawhide stream? coreos rawhide should have standard rawhide's same exposition level imo. We don't public links on getfedora.org, but we allow anyone to use it just changing your repos, or directly installing it. Why not allow the same behaviour for coreos rawhide allowing to everyone to rebase to it? What's the benefit of hiding it from the public? ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
Hi, this does not seem to be self-contained, since it seems to affect people outside the SIG (it states that this is also affecting packages that are not owned by the SIG). On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > == Summary == > > For Nodejs, Fedora should only package: > * The interpreter, development headers/libraries, and the assorted > tools to manage project-level installations (NPM, yarn, etc.). > * Packages that provide binaries that users would want to use in their shell. > * compiled/binary nodejs modules (for now) > > == Owner == > > * Name: [[User:tdawson| Troy Dawson]] > * Email: tdaw...@redhat.com > * Name: [[User:sgallagh| Stephen Gallagher]] > * Email: sgall...@redhat.com > * Name: [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > Nodejs SIG]] > * Email: nod...@lists.fedoraproject.org > > > == Detailed Description == > > The nodejs libraries have been approved to be bundled, and there is > infrastructure in place for the bundling to work properly. Currently, What does this infrastructure look like? How does it help with addressing security issues in the bundles components effectivly? > it is recommended that packagers should create individual nodejs > library packages instead of bundling all of the libraries into the > package requiring them. The subject says "Stop Shipping Individual Nodejs Library Packages", therefore it would be more clear to block all Nodejs libraries in Fedora instead of only recommending this. Otherwise it will be some half-baked solution that is probably confusing (Why are some libraries packaged and others bundled?). > This change is to make it default to bundle the nodejs libraries with > the package that needs them, and retire the vast majority of nodejs > library packages. > In summary, for Nodejs Fedora should only package: > * The interpreter, development headers/libraries, and the assorted > tools to manage project-level installations (NPM, yarn, etc.). > * Packages that provide binaries that users would want to use in their shell. > * compiled/binary nodejs modules (for now) This should also include the tooling that is needed to manage the bundling. > == Feedback == > > There has been a discussion on the fedora nodejs mailing list about > what to do with the extreme dependency problem of the nodejs library > packages. Because of the extreme inter-dependency, upgrading almost > any package causes others to break. It has caused most packages to > rot, remaining on unsupported versions for years. Many of the nodejs > packagers are giving up and orphaning their packages, which has caused > even more problems. > > An initial proposal was to find all of the important nodejs library > packages and bundle those, making them easier to upgrade and maintain. > But there was problems with figuring out what was important, and what > versions should those have. During that discussion, this rather > extreme solution of getting rid of all nodejs libraries was proposed. > To our surprise, it has been the best received suggestion and fixes > the most problems. What problems remain? > > == Benefit to Fedora == > > * In Fedora 33, there are many nodejs libraries that are > uninstallable, thus causing other programs based off them to also be > uninstallable. This gets rid of that problem. > * Packages in Fedora that use nodejs libraries will be able to use the > library versions that upstream has tested and approved. > * If a package in Fedora uses a nodejs library, the packager will not > have to also package extra individual nodejs library packages. There > have been times this has led to over 100 extra packages, each with > their own package reviews and maintenance problems. This change will > lower the workload on that packager, and possibly get more packages > into Fedora. > * The nodejs maintainers can concentrate on nodejs itself, instead of > the whole nodejs library infrastructure. > * Nodejs developers using Fedora will no longer have to worry about > Fedora's global nodejs libraries causing conflicts or inconsistencies. > > == Scope == > * Proposal owners: > We will go through the Fedora release and determine what nodejs > packages Fedora should package. We will implement nodejs library > bundling on those we already own. For those that we do not own, we > will work with their owners to implement nodejs library bundling. What about future packagers? How will they learn/be enabled to do it the right way? > As packages implement nodejs library bundling, we will monitor the > nodejs libraries and note which ones are no longer required. When > they are no longer required, we will retire them, if we own them. If > we do not own them, we will work with the owners to retire them, if > they wish. > > * Other developers: > For Fedora packagers whose package rely on nodejs libraries, please > contact the > [[https://developer.
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Hi, On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote: > I don't think you can make branches completely descripive by themselves, > unless possibly you make them really long. > > flatpak_branch_where_stable_flatpaks_are_made_from That it is about flatpaks is already described in the namespace, that it is a branch is clear from git. This only leaves "stable" as the one information in the long name that would be missing. > rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide It is fair to assume that someone who needs to use this already knows what rawhide is. Otherwise they did not have any use for the branch, even if it is called "main", so this long explanation does not make sense, there. > I suppose it's ok to make 'rawhide' a symref to main, or 'stable' in the > flatpak case... "main" as a symref might help people that are used to using main. Assuming that the symrefs are not visible, it makes more sense to use the descriptive names for the branches such as rawhide/stable. Then they 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: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Thursday, 10 December 2020 at 17:55, Troy Dawson wrote: > On Thu, Dec 10, 2020 at 2:07 AM Dominik 'Rathann' Mierzejewski > wrote: > > On Thursday, 10 December 2020 at 00:49, Miro Hrončok wrote: > > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > > > ... > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > > Should there be an update of: > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ > > > > > > ? > > > > Same question. I wanted to try packaging web-ext and even started > > a list of required dependencies[1]. What do I do now if NodeJS > > ecosystem is going away? This feels like a total failure of distro > > packaging principles. > > > > [1] https://fedoraproject.org/wiki/Web-ext > > You do just what we say, you bundle those nodejs libraries, instead of > using nodejs- packages. > > For you, that saves you having to make at least 45 new nodejs library > packages. But, the reality is closer to 500 packages once you add in > all the runtime and build-time dependencies. That may be so, but it's the right way to go about it. > If you don't already have one, we have a script that makes the > bundling easier. I've been using this one. > https://github.com/tdawson/tdawson-misc-scripts/tree/master/npm-bundler > It still needs a few tweeks, but it does the bundling part just fine. > > I ran that script for web-ext and it took about 10 minutes. Think of > how much time you've already spent looking up what packages are in > Fedora, and how many months it would take to get all the nodejs > library packages made, and reviewed. > It once took me over a year to get a nodejs based package in. Yes, doing things right is sometimes hard and slow. I think it's acceptable to revert to bundling temporarily, but while that's done, the NodeJS SIG should go out looking for more members and more automation to make NodeJS packaging as quick and easy as possible. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20201211.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201204.0): ID: 738864 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/738864 ID: 738871 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/738871 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: f33: systemd-resolved hang on ip query
On 12/10/20 7:16 PM, Paul Wouters wrote: On Wed, 9 Dec 2020, Dridi Boukelmoune wrote: This again leads to a required architecture change. We really need to have a captive portal namespace, that handles all of this while the applications still consider the network is down. Once the captive portal has passed and our internet link is "clean", should this be bridged into the regular network namespace so applications see the network as "active". Any state of DNS/browser that was used inside the captive portal namespace is then destroyed (it is untrusted and unverifiable data) That is how Android manages captive portals. Whoever created this captive portals concept should be slapped each day for ever, but that's where the world has gone. -- 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: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On src.fp.o, could we inject a custom message when someone trys to fetch/clone a master branch via pagure-dist-git ? Something like "this branch is deprecated, more info on https://foo.bar"; 20/12/11 08:15(e)an, Pierre-Yves Chibon igorleak idatzi zuen: On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote: On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote: On 12/3/20 4:02 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main == Summary == This Change will move Fedora git repositories to use "main" as the default git branch instead of "master". Specific repositories will be manually moved and default git branch for new projects will be set to use "main". The Fedora Community strives to be open and welcoming. Some language around our git repositories is dated and could be more inclusive. Many git repositories currently use "master" as the default branch. This Change will move many repositories (see below) to use a "main" branch as default. This small bit of naming adjustment is in-line with Fedora's vision for free and open source software built by inclusive, welcoming, and open-minded communities. How does it work for the enduser? I have thousand of git repos locally with the master branch, will it rename automatically master to main when I git pull or do I need to run a special command? You will need to reclone or run some commands in those existing checkouts. If you have a clone that has 'master' branch and we delete that, and you 'git pull' you will get: Fetching origin Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched. So you will need to do: git checkout main git branch --set-upstream-to=origin/main main Since the main branch will exist on the remote, you may be able to do: git fetch git checkout main and I think the git branch --set-upstream-to is no longer needed then then git pull. I don't think there's anything we can do on the server side to make that easier. Pingou any ideas? Not at the moment > 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 ___ 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
