they themselves made up, which is not a reason).
There is no reason they could not use libexec for the helper binaries.
Well, from a practical perspective, there is - it'd break existing user
configurations.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Thu, Dec 20, 2012 at 07:05:52PM -0700, Orion Poplawski wrote:
Shouldn't they be in /usr/share/systemd?
The helper binaries? No. The unit files? They need to be in / rather
than /usr, which obviously isn't a problem for Fedora but would be on
some other distributions.
--
Matthew Garrett
doesn't exist in any published version of the FHS, and even the
draft of 3.0 makes it clear that it's optional. Our use of libexec is
non-standard, not systemd's use of lib.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
components.
I'd love to see this changed/fixed down the road, but it's a lot of
documentation and moving around.
The situation right now is that it's impossible to write good
cross-distribution documentation. We should just do it for the sake of
future ease.
--
Matthew Garrett | mj
On Fri, Dec 21, 2012 at 06:09:10AM +0100, Ralf Corsepius wrote:
On 12/21/2012 05:54 AM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
I disagree. systemd simply hasn't taken libexecdir into account in
its design and now is trying to propagate
On Fri, Dec 21, 2012 at 07:16:12AM +0100, Ralf Corsepius wrote:
On 12/21/2012 06:36 AM, Matthew Garrett wrote:
So?
Next the FHS, it is one of the fundamental standards, which define
the basis of all packaging works on Linux/GNU and thus also the FPG.
No, it defines the GNU project's
an exception to
install binaries in libexec, it shouldn't need an exception install
binaries in lib.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
in modifying systemd?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, Dec 16, 2012 at 07:34:17PM -0500, Rahul Sundaram wrote:
Hi
fedup is supposed to support media upgrades yes.
At this point, fedup doesn't
--iso ISO[TODO] installation image file
Media upgrades are --device. --iso is for local ISO files.
--
Matthew Garrett
On Fri, Dec 07, 2012 at 12:02:52AM +0530, narendr...@dell.com wrote:
There is a request to disable to PIRQ (PCI Irq Routing Table) fallback in
upstream biosdevname.
Why?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Dec 03, 2012 at 07:25:16AM -0800, John Reiser wrote:
On 12/03/2012 05:44 AM, Matthew Garrett wrote:
It's part of the filesystem format, there's no way to change it.
This may be true, but not a priori. extN has feature flags which can
be used to enable leaving more space, or other
a discussion we need to have here.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
developer contribution
would be useful and because I actually want us to release Fedora 18.
We're not obliged to sit here pointing at a sinking ship when we could
do something to avoid that ship from sinking.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
teams responsible for core (
installation/boot/network handling ) functionality within the
project?
What kind of structure would you imagine such a SIG having? Who would be
taking overall responsibility?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Thu, Nov 08, 2012 at 02:48:26PM +, Jóhann B. Guðmundsson wrote:
On 11/08/2012 02:31 PM, Matthew Garrett wrote:
What kind of structure would you imagine such a SIG having?
Sorry not following?
I assume this ( and related mailinglist ) would be the place where
they manage
work in F18?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and is something that should be corrected (
from my pov ).
Patches that cleanly decouple Anaconda from the entire software stack
that it runs on top of would probably be received with open arms, but
nobody who works on it has any idea how to implement them.
--
Matthew Garrett | mj
everything
else under images.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Nov 08, 2012 at 03:48:31PM -0700, Tim Flink wrote:
On Thu, 8 Nov 2012 20:14:05 +
Matthew Garrett mj...@srcf.ucam.org wrote:
we are? I see approximately nobody offering assistance in that
respect.
If it would make you feel better, I can stop building test images,
updating
for
shim to get sorted out by legal), though I don't know whether FESCo yet
absolutely decided that has to be in for Beta.
And Restricted Boot support just needs to go away!
Sure, who wants new computers.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
undesirable release slips are does
nothing to help improve that situation. We know they're undesirable, but
so far nobody has proposed a workable solution that actually makes them
less likely to happen in future without massively compromising other
parts of the project.
--
Matthew Garrett | mj
UsrMove.
Well, /bin/perl would immediately fail on Debian or Ubuntu, so it seems
pretty unlikely that any upstream is doing it. There are reasons why
using env can be a bad idea and I don't think it's universal, but
/bin/perl is certainly wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
indication that those lockups occur only if secure boot is
set in the uefi firmware. They just lock out the user space regardless of
what the uefi says...
The capability is only masked off if the firmware reports that secure
boot is enabled.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
However I have absolutely no idea if iasl has an upstream as such,
or where else to send the patches ...
https://acpica.org/bugzilla/ or de...@acpica.org .
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
with installer issues because they're lazy, they're
failing to deal with them because there aren't enough hours in the day
for them to fix all of the issues that they're expected to handle.
You're in a position to make things better, so why not do so?
--
Matthew Garrett | mj...@srcf.ucam.org
changed, so this entire discussion is flawed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-inheritence behaviour. It's unsurprising that people end up with
different opinions of the right thing to do here.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Sep 07, 2012 at 02:42:20PM -0700, Jesse Keating wrote:
On 09/07/2012 02:36 PM, Matthew Garrett wrote:
This makes sense, but it runs directly against the current
auto-inheritence behaviour. It's unsurprising that people end up with
different opinions of the right thing to do here
On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote:
Sure, and that's clearly the behaviour that Lennart wanted as well. But
instead there was a mass rebuild that bumped his rawhide nvr and now he
needs to do rawhide work manually. If development should be happening in
rawhide
, nothing will make everyone happy.
Inheriting from updates-testing means rawhide can and will 'go
backwards' as updates get unpushed/dropped. Dropping inheritance
entirely means more work for maintainers.
Add a flag to bodhi to let maintainers re-enable inheritance?
--
Matthew Garrett | mj
not previously discussed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to raise it with the Community Working Group at
c...@lists.fedoraproject.org, or cwg-priv...@lists.fedoraproject.org if
you'd prefer the discussion to be private.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
be?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
fallback.
There's not really a lot that can be done to improve vesa, what with
vesa having no features.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jul 30, 2012 at 05:54:46PM +0300, Pasi Kärkkäinen wrote:
nomodeset doesn't help or change anything unfortunately..
Try with noapic?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote:
.. and it's stuck there. I need to press Reset button to continue.
It did read the CD for a while until it got frozen.
Yeah, that's definitely a bug then. We'll see if we can reproduce it.
--
Matthew Garrett | mj
/ resolution changes, and then there's just blank
screen and a cursor blinking..
If you see a resoution change then try booting with nomodeset.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote:
On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote:
The feature was +1ed on the assumption that the feature owner, as a
maintainer of relevant code, is in a better position to judge the impact
on the packages
that should be discussed. If there's no more reasonable solution then it
should be reverted. But at present procedure is working pretty much
exactly as expected.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
maintainers simply don't get to make that choice on behalf of others.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jul 10, 2012 at 05:45:15PM +0200, Michael Schwendt wrote:
On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote:
Saying things like:
and arbitrary other people, who get their patch contributions merged,
don't gain any copyright protection on the file or the proper parts
. No, they are
not significant and this is all a waste of time.
But Google are not permitted to redistribute that code. If a work is
relicensed without the assent of all copyright holders then the work is
undistributable, no matter how small any damages might be.
--
Matthew Garrett | mj...@srcf.ucam.org
On Mon, Jul 09, 2012 at 09:17:02PM +0200, Michael Schwendt wrote:
and arbitrary other people, who get their patch contributions merged,
don't gain any copyright protection on the file or the proper parts of it,
I don't think this is true.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
the
project's responsibility, not the copyright holder's.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
a work is sufficiently substantial to be
copyrightable is not straightforward. Don't try it without competent
legal advice. If you haven't received competent legal advice, you've
probably made a mistake at some point.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Mon, Jul 09, 2012 at 10:27:37PM +0200, Michael Schwendt wrote:
On Mon, 9 Jul 2012 20:52:23 +0100, Matthew Garrett wrote:
Revision control or some sort of out-of-band tracking. It's the
project's responsibility, not the copyright holder's.
That's hardly feasible and not accurate enough
operating
systems that write the same file.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is EFI/BOOT/BOOT(machine type).efi. It seems to conform to the spec
perfectly.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is not a sensible
thing to do. Even Apple don't do that. Install Linux (only) on a Mac,
zap the PRAM, see what happens - it'll boot if there's a blessed
bootloader on an HFS+ partition, not otherwise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
the firmware to do here?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jun 28, 2012 at 03:03:55PM -0600, Chris Murphy wrote:
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious
choice? Maybe a future spec could
, because HFS+ lets you put a pointer to a bootloader in the
superblock and FAT doesn't. If you don't have a suggestion for how to
make this work better with FAT then I don't think this thread is useful.
Serialising nvram contents isn't an especially good suggestion.
--
Matthew Garrett | mj
in the unlikely case they need to change
back to 'xterm' for example.
Unlikely Pffft!!What else do you resort to every time
gnome-terminal won't start because dbus has crashed?
Unclear what that has to do with the contents of your TERM variable.
--
Matthew Garrett | mj
said it would be impossible to get a key. It's just
msasively unlikely that such a key will be useful for any length of
time, and so it's not something that solves any of the problems we're
interested in solving.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
the binaries that a user may have installed. It's a little
more work, although not a great deal - by the looks of it vte sets this
itself, so a single patch would handle most of the GTK cases.
Thoughts?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
of authenticated
variables.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
if profile automagically turns xterm into xterm-256color?
The proposal actually handles that by parsing the output of the who
command, but I'm not sure I'm morally in favour of that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
for it not to be the default. We're only going to
audit one set of code for secure boot purposes, and it's not going to be
something that lacks required functionality like PXE support.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
trustworthy hardware, that hopefully will tell the truth to
the user about security for the owner of the device, and make
installing free operating systems non-scary.
To the best of my knowledge, their UEFI implementation isn't free
software.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
on life support, and that plug is going to be
pulled sooner than later.
F18 is already using grub2 for EFI. I think we can remove grub-legacy
now.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Tue, Jun 19, 2012 at 02:12:06PM -0400, Jared K. Smith wrote:
On Tue, Jun 19, 2012 at 1:55 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
F18 is already using grub2 for EFI. I think we can remove grub-legacy
now.
What about the Fedora images for Amazon EC2? I seem to recall that
because
be
fine now. I'm not sure what Amazons host systems use but hopefully they run
a relatively modern version of pvgrub.
Ok, so we need to be able to write a grub config file. We don't need to
ship grub, though, right?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
be on its own hardware.
The features you wanted in a free software UEFI are present in existing
UEFI implementations, so I'm not sure what you're asking for.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Mon, Jun 18, 2012 at 08:45:07AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
The features you wanted in a free software UEFI are present in existing
UEFI implementations, so I'm not sure what you're asking for.
No need for a shim
disable Secure Boot or use your own chain of trust, it isn't a
platform we can or should support.
To emphasise this point - Microsoft will sign EBC objects, so it's not
obvious that there's any way they *could* block a bootloader for ARM
devices. We're just choosing not to.
--
Matthew Garrett
refuses to grant
Fedora a special key?
As far as I can tell, Jay did say we currently cannot get an ARM key?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jun 18, 2012 at 09:43:27AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 9:37 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Like I said before, the existing UEFI implementations on the existing
hardware will support Disable Secure Boot or use your own chain of
trust. If you're
On Mon, Jun 18, 2012 at 10:04:38AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 9:56 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Ok so what you mean is I want a UEFI implementation that doesn't
require a Microsoft signature to boot? The options there are currently
(1) have a Fedora
On Mon, Jun 18, 2012 at 10:14:04AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
So you want Fedora to boot on all hardware sold?
I want Red Hat, Fedora, and the free software community to come to
terms with what they must do
key in?
What about the PK?
No, Windows 8 ARM devices will not permit the user to install their own
keys or disable secure boot. That's why we're not going to support them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
think the vendors would be breaking, but I'm not a lawyer.
Microsoft may have started this movement, but they're not the only
relevant entity in favour of it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
You're asserting that dbus-daemon etc cannot be restarted, but without
saying why.
Because designing an asynchronous messaging bus that can be restarted
without losing any messages is a difficult problem.
--
Matthew Garrett
hardware with
different firmware. Sales of Linux-specific PC hardware haven't been
massively successful so far.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
with a Fedora
key installed then our key security would be relevant to everyone, and
we'd be a much more attractive target than we currently are.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
need all of them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
implementations we're aware of will be shipping with support
for replacing all the secure boot keys, including Pk. UEFI itself is
also entirely free software, although specific implementations may not
be.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
On Mon, Jun 18, 2012 at 12:56:54AM -0400, Jay Sulzberger wrote:
We just need hardware we can install Fedora on, as once we did,
without asking Microsoft for permission.
System76 have committed to providing hardware without pre-enabled secure
boot.
--
Matthew Garrett | mj...@srcf.ucam.org
On Mon, Jun 18, 2012 at 01:00:33AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 12:58 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Mon, Jun 18, 2012 at 12:54:56AM -0400, Seth Johnson wrote:
But the best thing is that a free software UEFI would let anybody put
their own key
?
Microsoft has not refused to grant Fedora a key for ARM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jun 18, 2012 at 01:16:37AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 1:14 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
The machine will have a functional UEFI implementation. Why would we
want to replace it?
Um, because you're not asking permission?
I'm sorry, I
On Mon, Jun 18, 2012 at 01:17:19AM -0400, Seth Johnson wrote:
On Mon, Jun 18, 2012 at 1:15 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Mon, Jun 18, 2012 at 01:09:52AM -0400, Jay Sulzberger wrote:
The game is now just about over. What if one day, Microsoft
makes it even harder
On Thu, Jun 14, 2012 at 01:56:01PM -0400, Jay Sulzberger wrote:
If Fedora appears to accept that Microsoft should have the
Hardware Root Key, our side's arguments, in several arenas, are
weakened.
I don't think we've argued that they should, merely that they do.
--
Matthew Garrett | mj
the specifics. But if it's not, then why do you expect it to get any
worse if it becomes a primary architecture?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
their willingness to do anything that would
have been useful for the wider community.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
And you won't be able to run Fedora on them unless you can install your
own keys. I think everything that could usefully be said in this thread
has already been said.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
the current Fedora/RedHat stance,
as explained by Matthew Garrett, is to obtain a MS certificate
covering x86 and presumably ARM kernels from Fedora, but this
doesn't help respins and mods and even custom kernels---more likely
on ARM because of the its relative newness and faster pace
have to do that. But, as I said, I'm not in favour of
doing something that results in a platform where the user is unable to
run the software they choose.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
,
but we have the freedom to remove that restriction and therefore it's
not an issue as far as free software is concerned.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
. Note that added topics may be deferred until
the following meeting.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to chair next meeting (mjg59, 17:52:05)
Meeting ended at 17:52:16 UTC.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
boot, but
that's not really the point. We've done huge amounts of work to make
Fedora (and Linux in general) work without requiring any firmware
tweaking and people have recognised the value for that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
to that from a philosophical
perspective, but this is not an unprecedented decision.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
. An implementation may provide some feedback that
that's the case, but there's no requirement for it to do so, so it's
perfectly valid for it to just fall back to booting Windows with no
notification.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
to
prevent my packages from working on systems with it enabled then yes,
that's clearly a thing you could do. I don't think it's worth discussing
whether it's something that you should do or something that would be
treated as a bug unless someone actually wants to do it.
--
Matthew Garrett | mj
at all.
But you're happy to sacrifice the freedom for people to modify the error
text that's provided? What's your threshold?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
201 - 300 of 691 matches
Mail list logo
