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
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 the
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 w
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 Apple
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 that
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
are
is response to me 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ðmund
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 do
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 ce
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 stated
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, fans
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
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 company
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 vendor
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 r
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 of
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
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 "Legac
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
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 deskt
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: http
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 don’t
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
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 last
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
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 us
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 be
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 use
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
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
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
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
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
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 ex
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
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 mac
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 hardw
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
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
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
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
to
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
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
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
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
it
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 to
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 not be the
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.
Rig
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
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
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
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
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 not
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 approa
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 unma
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 get
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 -- devel@l
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 fire
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 )
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 the package quality.
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
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 feat
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 that
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 systems.
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
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 o
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
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 tha
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
https://lists.fe
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 and
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 o
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 relea
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
On 05/17/2016 04:32 PM, Chris Murphy wrote:
On Tue, May 17, 2016 at 8:57 AM, Jóhann B. Guðmundsson
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 kernel for F24 would be. The
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
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. Timi
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
alternatives
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
== D
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
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 afte
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 inten
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
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 severa
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
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 of cookies, but I expect
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
On 09/15/2015 08:41 AM, Ian Malone wrote:
On 14 September 2015 at 16:47, Jóhann B. Guðmundsson 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 since developers can use the
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"
and
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 o
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 an
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
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 li
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.
>>This problem is entire
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-
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 can
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 specific examples[1].
It's
abo
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 not
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 ha
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 attempt
On Mar 5, 2015 4:53 PM, "Matthew Miller" wrote:
>
> On Thu, Mar 05, 2015 at 09:06:10AM +0000, "Jóhann B. Guðmundsson" wrote:
> > An typical outcome from a group of individuals that do not know what
> > they are doing and are making decisions based on their o
1 - 100 of 964 matches
Mail list logo