On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> On 12/20/2012 11:54 PM, Matthew Garrett wrote:
> >libexec 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-sta
ns - if a package wouldn't require 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
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,
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
> &
gs in lib makes sense, since
there's absolutely no good reason for multilibing those 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-distri
distro's demands.
libexec 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 m
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.
--
Ma
not
> > the de-facto standard 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
).
Because libexec doesn't exist on most other distributions, and systemd
aims to offer consistent interfaces across distributions.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
problems.
What benefit do you see in modifying systemd?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rades are --device. --iso is for local ISO files.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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 e
, there's no way to change it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
may care due to distributions with different policies, but I don't know
that that's 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
because it's clear that more 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...@src
On Thu, Nov 08, 2012 at 03:48:31PM -0700, Tim Flink wrote:
> On Thu, 8 Nov 2012 20:14:05 +
> Matthew Garrett wrote:
> > "we" are? I see approximately nobody offering assistance in that
> > respect.
>
> If it would make you feel better, I can stop building
built by Lorax, just like everything
else under images.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t; install is a design flaw 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.
ly tied to various
system components.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
unity did the work to make the F17 Anaconda
work in F18?
--
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 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 b
e "proper"
> communication of changes between 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
ecure boot support is also not done yet (waiting on the signature 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 com
's
unfortunate, but talking about how 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
/bin/env python),
> long before 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.
--
t; cannot see any 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 Garret
/show_bug.cgi?id=856856
>
> 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.o
ren't
failing to deal 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
ll.
The default isn't being 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
> It's a balancing act I fear, 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
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 b
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
ectly against the current
auto-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
ibe issues not previously discussed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
l
free 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.fedoraproj
We had one time we all said we could make it.
18:21:49 And it was?
18:22:39 Sorry, fetching. :)
18:22:54 1700 UTC.
18:22:59 On wednesdays
18:23:29 so that would be the day after all our deadlines instead of
the day before... but sure.
18:23:38 So 1300 EDT?
18:23:44 yes
18:23:57 Well, okay.
-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
not triggering 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
What would a KMS vesafb even be?
--
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
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.
--
a
workaround in grub.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> and then the display mode / 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 imp
le then that's something
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
to you my precious butterfly. 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.
ring is to tell you that it's dangerous to tell
people things about copyright law when you don't appear to understand
copyright law.
--
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
s *before* a copyright holder wants to enforce rights.
It boils down to copyright law. Nothing more. Nothing less. Project
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 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.
>
> Tha
is not credited for patches.
Determining whether 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 Ga
me sort of out-of-band tracking. It's 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
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.uc
al behaviors.
Yes, 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 sugge
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
#x27;re
not doing that. What do you actually want 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
FI executable you find on a drive 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
--
ice, and the only spec-defined boot location
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
d to find a way to co-exist with other 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
can always override TERM in their
> >startup files 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 crashe
> what happens 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@li
erview of authenticated
variables.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
g
things about 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@lis
utes concurrently.
We never 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.
UEFI
> on its own 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 Garr
Which is a good reason 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 lis
hese should 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.or
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 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 tha
into GRUB 2.
> Red Hat has kept GRUB legacy 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
h
k out of the box. It's unclear to me which
laws you 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@
ertified ARM device be able to put their own signing 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
-
On Mon, Jun 18, 2012 at 10:14:04AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett 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
On Mon, Jun 18, 2012 at 10:04:38AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 9:56 AM, Matthew Garrett 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
On Mon, Jun 18, 2012 at 09:43:27AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 9:37 AM, Matthew Garrett wrote:
> > Like I said before, the existing UEFI implementations on the existing
> > hardware will support "Disable Secure Boot or use your own chain of
> >
On Mon, Jun 18, 2012 at 09:26:23AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 8:59 AM, Matthew Garrett wrote:
> > You're still not making it clear what you want. Hardware without secure
> > boot? Hardware with secure boot but a different default policy? Hardware
&g
appened with ARM, Microsoft 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
that
> you can 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&#x
On Mon, Jun 18, 2012 at 08:45:07AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett 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.
>
hread, reconstructed in nested fashion above. A free
> software UEFI would 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
--
dev
On Mon, Jun 18, 2012 at 01:17:19AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 1:15 AM, Matthew Garrett 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 ev
On Mon, Jun 18, 2012 at 01:16:37AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 1:14 AM, Matthew Garrett wrote:
> > The machine will have a functional UEFI implementation. Why would we
> > want to replace it?
>
>
> Um, because you're not asking permissio
ra a special 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:00:33AM -0400, Seth Johnson wrote:
> On Mon, Jun 18, 2012 at 12:58 AM, Matthew Garrett 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
> &
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 Gar
e.
All UEFI 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 m
one motherboard. We need all of them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
chines shipped 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
cost more than identical 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
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.
These suggestions boil down to:
1) Do nothing
2) Become a hardware vendor
3) Use a Fedora key
None of these solve the problem of getting Fedora onto arbitrary x86
hardware bought towards the end of this year.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
blems then please do point out
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
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.
#x27;t think this lets you
draw any conclusions about 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
rgets-pcs-takes-aim-intels-ultrabooks
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
deve
$99. Problem solved.
We wouldn't even 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.o
ng it off. I guess 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 rel
even require that they be reverted,
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
er 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
. 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
201 - 300 of 732 matches
Mail list logo
