Re: It’s time to transform the Fedora devel list into something new

On 4/26/23 16:04, Vitaly Zaitsev via devel wrote: On 20/04/2023 23:20, Matthew Miller wrote: It’s time to transform the Fedora devel list into something new I think such serious questions should be put to a vote. Not a FESCo vote, but a vote for all Fedora contributors (can be combined with

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On 12/22/22 15:39, Lennart Poettering wrote: Well, the thing is: a chain of trust is a*chain*, hence you must ultimately hook validation to what the firmware provides you with as root. And that ultimately is the SecureBoot db on commodity hardware. Well, the thing with a chain of trust is

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On 12/20/22 21:27, Simo Sorce wrote: Finally, unless this proposal harms Fedora I do not see why oppose it. If, as you fear, it won't work ... then it won't and we'll try something else. You do realize that the day that Lenovo started to sell it's hardware with Fedora pre-installed ( as it

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 15.4.2022 00:44, Kevin Kofler via devel wrote: One of the reasons people use GNU/Linux is exactly to escape the hardware manufacturers' planned obsolescence treadmill. True but that does not mean Fedora is the best distro for that + it looks like hw vendors are taking lessons from the

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 23:25, Nikolay Nikolov wrote: On 4/15/22 01:53, Jóhann B. Guðmundsson wrote: On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 15.4.2022 00:38, Kevin Kofler via devel wrote: Jóhann B. Guðmundsson wrote: Trying to support that legacy scenario where certain hw may or may not work is a nightmare for developers, support teams and Fedora since Fedora is not a distribution with a long term support, LTS distributions

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

in private when I exposed him last time here on devel. "little idiot: the Fedora COC don't apply for pruvate mails just because the topic is fedora relevant" On 14.4.2022 21:46, Reindl Harald (privat) wrote: Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmundsson: "In the bios,

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 22:24, Nikolay Nikolov wrote: On 4/14/22 23:49, Jóhann B. Guðmundsson wrote: On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 18:29, Peter Boy wrote: Maybe "legacy BIOS on physical hardware" is on its way out, but it doesn't seem that it is true across the board in VM environments. That’s maybe true for desktops, but in the server world any server needs to be able to do bios boot, because of the data

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 18:20, Chris Adams wrote: Once upon a time, Robbie Harwood said: Given there is consensus that legacy BIOS is on its way out I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 16:38, Ben Beasley wrote: I’m not talking about refurbished parts or new old stock. I’m talking about the brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other components that are backwards-compatible in systems pushing twenty years old (SATA) or older (PSUs,

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 15:53, Peter Boy wrote: Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson : It should be quite apparent prevent the hw support lifecycle dialog from ever occurring again we need a rigid planned supported hw lifecycle. Again, the legacy BIOS discussion is not about hardware

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 14:07, Martin Jackson wrote: In many industrial and retail use cases, 10 years is the low end. 3-5 years is an accounting timeline (for depreciation) not necessarily the useful life of the asset. If the asset can be used after it’s done depreciating that is a bonus for the

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 13:09, Ben Beasley wrote: For desktop-class hardware, the parts that are most likely to fail around the decade mark are storage drives, power supplies, and perhaps fans. All of these are fully standardized and in plentiful supply; there is no reason that first-party hardware

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 12:18, JadoNena via devel wrote: But for here we deal with the real world where budgets require plans and hardware exists for years. If you are dealing with the real world with real businesses then you should be aware of the fact that businesses are usually on a 3 - 5 year hw

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 11:42, Kevin Kofler via devel wrote: Jóhann B. Guðmundsson wrote: For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade from the date

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 11:53, Peter Boy wrote: Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson : For example EU has regulation that requires vendors to have spare parts available for 7–10 years after date of manufacturing so it makes sense for the project to support hw no longer than a decade

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On 14.4.2022 09:17, Tomasz Torcz wrote: On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote: Am 13.04.22 um 20:05 schrieb David Cantrell: The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in Fedora. I do not agree with this statement. Like previous

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On 14.4.2022 02:23, Demi Marie Obenour wrote: On 4/13/22 17:11, Jóhann B. Guðmundsson wrote: On 13.4.2022 08:04, David Bold wrote: It seems I must be missing something? Why should we not care about a significant number of our users, just because other OSs have more users? Could you explain

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On 13.4.2022 08:04, David Bold wrote: It seems I must be missing something? Why should we not care about a significant number of our users, just because other OSs have more users? Could you explain that? First of all this is not significant number of Fedora's users ( or in the overall

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On 12.4.2022 20:44, Mark Otaris wrote: Your calculations have to be off; I’m pretty sure there are way more than 100 Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard minimum:

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On 12.4.2022 00:24, Mark Otaris wrote: However, the majority of Linux PC users *must* step out of the happy path to get their hardware working for two cases: * NVIDIA graphics * Broadcom wireless In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5% other. I

Re: The future of legacy BIOS support in Fedora.

On 19.10.2020 17:25, Michael Catanzaro wrote: On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis wrote: I'am also have Thikpads and MSI running BIOS and some of those machines  still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to

Re: The future of legacy BIOS support in Fedora.

On 6.7.2020 12:07, Tomasz Torcz wrote: On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote: The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the

Re: The future of legacy BIOS support in Fedora.

On 6.7.2020 18:39, Javier Martinez Canillas wrote: On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson wrote: On 5.7.2020 18:34, Javier Martinez Canillas wrote: On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote: [snip] Please submit additions to the spec as PRs to systemd github

Re: The future of legacy BIOS support in Fedora.

On 5.7.2020 19:31, Solomon Peachy wrote: On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote: In terms of physical x86 systems, you are right that UEFI is the overwhelming majority. But as stated elsewhere in this thread, a lot of cloud providers and virtualization software default to

Re: The future of legacy BIOS support in Fedora.

On 5.7.2020 18:34, Javier Martinez Canillas wrote: On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote: [snip] Please submit additions to the spec as PRs to systemd github. We added a number of new keys in the past that sd-boot itself doesn't make use of (devicetree and such), and we'd

Re: The future of legacy BIOS support in Fedora.

On 2.7.2020 10:16, nick...@gmail.com wrote: On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote: Solomon Peachy writes: Even putting that aside, for the past several years CSM/BIOS has been slowly bitrotting due to a lack of real testing, as the last few Windows releases have mandated

Re: The future of legacy BIOS support in Fedora.

On 2.7.2020 01:42, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson wrote: On 2.7.2020 01:06, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote

Re: The future of legacy BIOS support in Fedora.

On 2.7.2020 01:06, Neal Gompa wrote: On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 23:28, Neal Gompa wrote: On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 23:18, Björn Persson wrote: Jóhann B. Guðmundsson wrote: More user friendly than Grub ( has lilo like interface easier to change kernel entry, which goes nicely with the default editor change ) This made me go "What?!". I used Lilo back in the day. Its user interface w

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 21:50, Neal Gompa wrote: On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 21:00, Neal Gompa wrote: On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 16:10, Solomon Peachy wrote: On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 21:39, Ricky Zhang wrote: I second your point. I don't see any upside to discontinue support of legacy BIOS. Even my latest machine support legacy BIOS. UEFI caused more headache to me than bringing in any real positive user experiences. What headache exactly? You had bad user

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 20:31, Ralf Corsepius wrote: On 6/30/20 3:34 PM, Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 21:00, Neal Gompa wrote: On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson wrote: On 1.7.2020 16:10, Solomon Peachy wrote: On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote: I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new machines

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 17:17, Peter Robinson wrote: The use of legacy or uefi are changes that users have to manually change themselves in their bios from manufactures default settings. There is no tool that can do that for them or migrate those settings however users should be able to change this for

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 16:10, Solomon Peachy wrote: On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote: I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new machines, This won't be the case for much longer; Intel will finally drop CSM ("BIOS") support this year. Even

Re: The future of legacy BIOS support in Fedora.

On 1.7.2020 09:36, Lennart Poettering wrote: On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) wrote: Hi, So I can't say I'm thrilled about a future that depends on EFI for virt, but I'm resigned to the fact this is the direction the world is taking. So we're not likely to have any

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 22:38, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: sd-boot is already installed on end users system, is light weight compared to Grub ( sd-boot only supports uefi,smaller code size, easier to maintain ). And that is exactly the problem, systemd-boot has only a small fraction

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 22:31, nick...@gmail.com wrote: On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote: On 30.6.2020 21:14, nick...@gmail.com wrote: On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: Grub discourages users who have tried sd-boot from coming/returning

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 21:14, nick...@gmail.com wrote: On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote: Grub discourages users who have tried sd-boot from coming/returning to Fedora [1]. Bottom line I think this will be a good move for the distribution and a good time to start looking

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 19:22, Robbie Harwood wrote: Jóhann B. Guðmundsson writes: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 18:32, John M. Harris Jr wrote: On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 18:45, Reindl Harald (privat) wrote: Am 30.06.20 um 20:29 schrieb Jóhann B. Guðmundsson: On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 17:49, John M. Harris Jr wrote: On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 17:47, Robbie Harwood wrote: Jóhann B. Guðmundsson writes: On 30.6.2020 13:56, Igor Raits wrote: On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 17:15, Gerd Hoffmann wrote: Hi, So I can't say I'm thrilled about a future that depends on EFI for virt, but I'm resigned to the fact this is the direction the world is taking. So we're not likely to have any choice and will have to work to mitigate any downsides it brings.

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 14:27, Daniel P. Berrangé wrote: On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote: * Jóhann B. Guðmundsson: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 14:18, Tom Hughes via devel wrote: On 30/06/2020 14:56, Igor Raits wrote: I think there are many people still install OS in the legacy mode, but I don't really have numbers. One thing we should definitely do if we deprecate legacy BIOS is to properly warn users that still use this

Re: The future of legacy BIOS support in Fedora.

On 30.6.2020 13:56, Igor Raits wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting

The future of legacy BIOS support in Fedora.

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

On 16.6.2020 21:44, Solomon Peachy wrote: "retired" tells you nothing more than "no longer packaged". "packaged" does not mean "maintained by fedora". It certianly doesn't mean "kept up to date with upstream releases" or "kept updated with security fixes" And "broken" in this context means

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

On 16.6.2020 20:22, Gerald Henriksen wrote: Given the number of cases of evil people getting access to computer systems, and the fallout of said attacks, any package left on a system after it no longer is being maintained is not only broken but a security risk. Unless the process and the

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

On 16.6.2020 12:21, Kamil Paral wrote: I'd like Fedora systems to be transparent and honest. If some packages need to be removed, tell me about it, and ideally also tell me why (e.g. no longer maintained). If possible, tell me how to avoid it temporarily (it might be months or years, but

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 10/06/2016 03:27 PM, Adam Williamson wrote: On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote: So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

On 09/18/2016 10:16 PM, Jeff Fearn wrote: Hi, we might be able to extend the External Trackers extension in RH Bugzilla to be able to create as well as sync bugs. Between which issue trackers is that supported? JBG ___ devel mailing list --

Re: F24, small backward steps

On 09/13/2016 04:41 PM, Bastien Nocera wrote: - Original Message - - Original Message - I'm seeing 24 bugs at: https://apps.fedoraproject.org/packages/fprintd/bugs/all including a potential security one: https://bugzilla.redhat.com/1333882 Fedora's bugzilla is a garbage

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

On 09/14/2016 05:46 PM, Matthew Miller wrote: What I'd_really_ love to see is a layer separating bug trackers from end users. That layer already exist in the form of irc forum and askbot does it not? ( someone from the support sub-community can provide information how successful these are )

Re: Triaging RH Bugzilla and forwarding bugs upstream

On 09/14/2016 05:03 PM, Jason L Tibbitts III wrote: "RC" == Ralf Corsepius writes: RC> - A package triggering too many BZs. RC> IMO, this should question the package's quality. A package with a million users is going to get more bugs than a package with ten regardless of

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

On 09/14/2016 02:44 PM, Jason L Tibbitts III wrote: I disagree in general; when the bug volume exceeds a certain amount bugzilla basically becomes useless. However, it would be really nice if _someone_ looked at RH bugzilla for those packages and did something with them. This responsibility

Re: My experiences with KillUserProcesses=yes on F24

On 08/31/2016 02:25 PM, Jason L Tibbitts III wrote: More appropriate place would be to post this upstream either on the mailinglist and or as an bug/rfs in the tracker so this issues can be addressed properly. Lingering is a per-user thing so it probably ends up being an per user opt in

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

On 08/02/2016 10:23 AM, Simo Sorce wrote: I do not actually have to prove anything, in a welcoming community you give the beneit of the doubt that people researched and know what they are talking about and you stick to actual fact in whatever they produce, not to some badge of credentials

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote: It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

On 08/02/2016 09:24 AM, Simo Sorce wrote: On Tue, 2016-08-02 at 09:11 +, Jóhann B. Guðmundsson wrote: On 07/31/2016 06:29 AM, Parag Nemade wrote: Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

On 07/31/2016 03:18 AM, Sérgio Basto wrote: why such hurry ? There has been a more than enough time for this migration to happen already and now it's existence has started to hinder other changes and adoptions in the distribution. The initial target was for the feature completion was F20

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

On 07/31/2016 06:29 AM, Parag Nemade wrote: Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/ Take that article with a grain of salt since it's written by somebody that has

Re: Summary/Minutes from today's FESCo Meeting (2016-07-15)

On 07/15/2016 05:19 PM, Josh Boyer wrote: * AGREED: FESCo approves KillUserProcess=yes by default with the steps sgallagh has proposed in the ticket (+7, 0, 0) (jwb, 17:04:58) "Tier 1 packages must be ported to support operation under KillUserProcesses=yes" Is it safe to assume

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/06/2016 03:56 PM, Benjamin Kreuter wrote: It took me three days to find the problem the last time systemd caused unexpected behavior on my system. What was this hard to find unexpected behaviour you encountered? JBG -- devel mailing list devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/02/2016 03:13 PM, Stephen Gallagher wrote: I don't think we need to change Fedora 24 for this. Unless I misunderstood, this systemd change has not been pushed to Fedora 24 (nor proposed for it). We're prepping for how to deal with things in Fedora 25. You should not so easily dismiss

Re: systemd 230 change - KillUserProcesses defaults to yes

On 06/01/2016 02:01 PM, Josh Boyer wrote: Given the principle of least surprise, it would make more sense to default with this being disabled out of the box. I have to disagree with this statement. Upstream should always reflect how things should be while downstream reflects how things are

Re: Kernel plans for Fedora 24

On 05/17/2016 05:25 PM, Chris Murphy wrote: I refuse the premise that the kernel team is going to release a 4.6.x kernel that isn't ready as a 0 day update. There is more extensive testing performed before GA release then there is in the update process hence what get's shipped in the GA

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

On 05/17/2016 04:32 PM, Till Maas wrote: Your argument sounds like yum.repos.d would be the best name for the repo definitions that are recognised by the yum parser and other implementations for this format. More accurate and more distro agnostic would be system like rpm or npm etc >.repos.d

Re: Kernel plans for Fedora 24

On 05/17/2016 04:32 PM, Chris Murphy wrote: On Tue, May 17, 2016 at 8:57 AM, Jóhann B. Guðmundsson <johan...@gmail.com> wrote: On 03/16/2016 04:01 PM, Justin Forbes wrote: With the 4.5 kernel out and the merge window for 4.6 opened up, we had to make a decision on what the release

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

On 05/17/2016 02:48 PM, Lukas Zapletal wrote: With a symlink /etc/yum.repos.d to it. And for other type repository's -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Kernel plans for Fedora 24

On 03/16/2016 04:01 PM, Justin Forbes wrote: With the 4.5 kernel out and the merge window for 4.6 opened up, we had to make a decision on what the release kernel for F24 would be. The decision has been made to ship F24 with the 4.5 kernel with 4.6 available as an update once it is ready.

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

On 05/17/2016 02:14 PM, Honza Šilhan wrote: there are a lot of good suggestions about the path name in the discussion. `/etc/distro.repos.d` probably wasn't the best chosen path so we've changed it to `/etc/repos.d` in the proposal. Moreover I've mentioned there possible path name

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

On 05/12/2016 08:07 AM, Tomasz Torcz wrote: On Thu, May 12, 2016 at 09:36:32AM +0200, Jan Kurik wrote: = Proposed System Wide Change: Use /etc/distro.repos.d as default reposdir = https://fedoraproject.org/wiki/Changes/ReposInEtcDistroReposD Change owner(s): * Neal Gompa * Jan Silhan ==

Re: No mass rebuild in Fedora 25

On 05/02/2016 01:24 PM, Stephen Gallagher wrote: There is strong engineering value in having two releases per year: release early, release often. There are many projects that develop through Fedora that get thrown into disarray when our cycle gets too far out of whack (prominent examples being

Re: 4.4 rebase coming to F23 soon

On 02/24/2016 05:22 PM, Laura Abbott wrote: On 02/18/2016 05:51 PM, Laura Abbott wrote: Hi, 4.4.2 is currently building and should be in updates-testing soon. As usual, please test and give karma appropriately (negative karma for new issues, not existing issues). Thanks, Laura A use

Re: Unexpected NIC naming f23 firewall implications

On 11/10/2015 06:06 AM, Tomasz Torcz wrote: On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote: em* and p?p? come from biosdevname, which should not be used and is deprecated. I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't

Re: Unexpected NIC naming f23 firewall implications

On 11/08/2015 07:29 PM, Richard W.M. Jones wrote: On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote: I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1. Is this something that

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On 10/09/2015 02:16 PM, Adam Jackson wrote: On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote: >I agree - the new wording does appear to give in to poor programming >practices. Bundling is_not_ intrinsically poor practice. Firefox is a good example of this, there have been

Re: Proposal to reduce anti-bundling requirements

On 10/08/2015 12:31 AM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: >Badges was supposed to be that carrot for the mule's so perhaps there's >just missing new set of badges for this... > >1.https://badges.fedoraproject.org/ Those "badges" are completely useless

Re: Proposal to reduce anti-bundling requirements

On 10/07/2015 11:21 PM, Stephen John Smoogen wrote: On 7 October 2015 at 16:41, Kevin Kofler wrote: >Stephen John Smoogen wrote: >>So the next step after that is that we reward people who lower a >>package's point. Good idea Kevin. > >"Reward" how? > I was thinking

Re: Proposal to reduce anti-bundling requirements

On 09/15/2015 08:41 AM, Ian Malone wrote: On 14 September 2015 at 16:47, Jóhann B. Guðmundsson <johan...@gmail.com> wrote: They simply have welcomed their new container overlords and are using only the recommended upstream method for installing for their application ( pip,gem etc

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/14/2015 02:18 PM, Stephen Gallagher wrote: Also, I'd like to be clear on this: whatever the outcome of this discussion, I want Fedora packagers to continue to work with their packages and upstreams to unbundle as much as possible. I think that this*does* lead to significant improvements

Re: Proposal to reduce anti-bundling requirements

On 09/14/2015 07:08 AM, Josef Stribny wrote: On 09/12/2015 12:41 AM, Jóhann B. Guðmundsson wrote: On 09/11/2015 09:09 PM, Orion Poplawski wrote: What does Fedora users gain with "dnf install rails" or "dnf install ipython" versus "gem install rails&qu

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 05:51 PM, Adam Williamson wrote: On Fri, 2015-09-11 at 13:35 -0400, Stephen Gallagher wrote: As for which components, it's not about specific examples[1]. It's about solving the question in a generic way. We have quite a lot of software that isn't packaged for Fedora (either

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 06:10 PM, Adam Williamson wrote: On Fri, 2015-09-11 at 12:06 -0600, Kevin Fenzi wrote: On Fri, 11 Sep 2015 10:51:42 -0700 Adam Williamson wrote: On Fri, 2015-09-11 at 13:35 -0400, Stephen Gallagher wrote: As for which components, it's not about

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/10/2015 01:53 PM, Stephen Gallagher wrote: I assume that subject line got your attention. I know this is a long-standing debate and that this thread is likely to turn into an incomprehensible flamewar filled with the same tired arguments, but I'm going to make a proposal and then

Re: Proposal to reduce anti-bundling requirements

On 09/10/2015 07:10 PM, Przemek Klosowski wrote: On 09/10/2015 09:53 AM, Stephen Gallagher wrote: The point of software is to provide a service to an end-user. Users don't run software because it has good packaging policies, they run software because it meets a need that they have. If they

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 07:25 PM, Adam Williamson wrote: In a world where bundling was allowed, the package would likely have been approved on initial review; the only significant issues found in review were bundling-related. There are a couple of trivial issues noted in #c7, but those would have been

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 07:16 PM, Haïkel wrote: 2015-09-11 21:09 GMT+02:00 Josh Stone: >On 09/11/2015 10:35 AM, Stephen Gallagher wrote: >>Actually, the opposite is true. RHEL has fewer limitations in this >>space. Red Hat's layered projects ship a fair amount of bundled stuff.

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 07:59 PM, Adam Williamson wrote: On Fri, 2015-09-11 at 19:32 +, Jóhann B. Guðmundsson wrote: On 09/11/2015 07:25 PM, Adam Williamson wrote: In a world where bundling was allowed, the package would likely have been approved on initial review; the only significant issues

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 06:40 PM, Adam Williamson wrote: On Fri, 2015-09-11 at 18:27 +, Jóhann B. Guðmundsson wrote: I agree that the discussion here needs to be more broad-based; see the other thread fork. I was just providing support for Stephen's contention that this is not some airy-fairy

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 08:31 PM, Adam Williamson wrote: We certainly agree on that. > which has already been >answered by the board. >( people will first debate where to draw the line if that discussion >wont be killed in birth but in the end they end up with the same >question as has already been

Re: Proposal to reduce anti-bundling requirements

On 09/11/2015 09:09 PM, Orion Poplawski wrote: What does Fedora users gain with "dnf install rails" or "dnf install ipython" versus "gem install rails" and "pip install ipython"? This indeed is very good question. I'm not sure how things are elsewhere in the world but in the case of gem's

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 05:35 PM, Stephen Gallagher wrote: To me (speaking as a user of Fedora, maintainer of Fedora software and developer of both Fedora and upstream projects), the current situation is not ideal. In many cases, we're holding so rigidly to the "no bundling" policy that it is actively

Re: FESCo Meeting Minutes (2015-03-04)

On 03/05/2015 02:44 PM, Zbigniew Jędrzejewski-Szmek wrote: While I would love to see 100% migration, the benefits for leaf packages aren't that big. We have fairly good compatibility support, and only a small number of people are using each package. Nobody can use those leaf packages unless

  1   2   3   4   5   6   7   8   9   10   >