to be using gmail at this point. Any
solution needs to account for them as well.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
that your behaviour is
acceptable. If you're going to tell someone to leave a community, make
sure that you're meeting that community's norms yourself.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
at all.
The short version of that is no, because kdump needs to build some code
at runtime. Upstream have refused to revisit that design decision.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
completely up to date, sorry but the
last couple of days have been some what hectic for me in other realms.
For instance, it seems to be missing both the stack protector and
llvmpipe issues.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote:
On 07/16/2013 07:16 PM, Matthew Garrett wrote:
For instance, it seems to be missing both the stack protector and
llvmpipe issues.
Finishing scope of stack protector issue- it'll be there in a day or
so. Idea is to get
On Mon, Jul 15, 2013 at 12:21:57PM -0400, Martin Langhoff wrote:
Would you run tuned on a server?
It was written with that in mind.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
almost-but-not-quite Fedora to be treated as if it's Fedora, and
I don't think that benefits the public perception of the project.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
means
we don't make the same guarantees to users.
From a practical point of view: how many of the proposed new features
for F20 would be absent from the ARM release? How are we going to
communicate that?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
That's the point. You don't get to be a primary architecture until
you've demonstrated that doing so won't slow down the other
architectures
On Thu, Jul 11, 2013 at 05:02:27PM +0200, Miloslav Trmač wrote:
On Thu, Jul 11, 2013 at 4:33 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
Yes, but that is _net_ benefit (benefit - cost). Requiring zero cost
On Thu, Jul 11, 2013 at 08:50:05AM -0700, Brendan Conoboy wrote:
On 07/11/2013 07:33 AM, Matthew Garrett wrote:
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
And you think it would not benefit Fedora.
On the contrary, I think a solid ARM port benefits Fedora
On Thu, Jul 11, 2013 at 09:25:43AM -0700, Brendan Conoboy wrote:
On 07/11/2013 08:34 AM, Matthew Garrett wrote:
That's why I'd like to see all of these things fixed *before* promotion.
Yes, you've been very consistent, it can be summarized in 3 points:
1. Provide a list of every ARM
drivers - they should be able to
reconfigure the device. Or just pass the framebuffer offset, size,
stride and pixel format to the kdump kernel and have it treat it as an
unaccelerated linear framebuffer.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
be a software versus hardware console and so data sent to it went
through a lot of corruptible stacks :/. [Ah for a nice old x86 with UART.]
There's USB debug cables, but last I heard they're currently impossible
to get hold of.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
environments, but there's certainly arguments in favour of (say)
dropping most of the 32-bit x86 package set and turning it into a
specialised subset of the overall distribution.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
. If ARM merely wants to be
able to produce something that's similar to Fedora then we should figure
out what a spin-based PA would look like, but that's not what's
currently being proposed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
of
the distribution for years.
| Fedora
|
|
| Your architecture must be at least this competent
|
|
| stack protector
|
|
|
| m68k
|
|
|
|
| --- elks
|
|
| --- minix
---
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
of desktop
environments, defaulting to the GNOME desktop environment. An OS that
supports headless servers but not desktop environments might be based on
Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
being a Fedora PA.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
a secondary architecture you
get to take responsibility for making stuff work yourself. If a package
maintainer is willing to volunteer time and effort to making things work
then that's a bonus, but if they're not then someone who cares about ARM
has to take responsibility.
--
Matthew Garrett | mj
involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring that we don't
end up in a situation where other architectures are held up because
there's nobody who can fix ARM-specific bugs.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
architecture until
you've demonstrated that doing so won't slow down the other
architectures, and that requires you to fix all of these problems
yourself first.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Tue, Jul 09, 2013 at 10:53:39AM -0700, Gregory Maxwell wrote:
Does the secureboot situation on arm mean that this primary architecture
will eventually be un-bootable for people running a non-redhat signed kernel?
That's unsupported hardware, in the same way that ipads are.
--
Matthew
On Tue, Jul 09, 2013 at 02:54:53PM -0400, Jonathan Masters wrote:
Matthew Garrett wrote:
This doesn't make it seem like the ARM port currently has sufficient
developer expertise involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring
On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
Fedora ARM has all the features of the primary architectures
Is this really accurate?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Tue, Jul 02, 2013 at 03:00:43PM -0500, Dennis Gilmore wrote:
On Tue, 2 Jul 2013 20:18:06 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
Fedora ARM has all the features of the primary architectures
Is this really accurate
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, but the llvmpipe code that
makes that possible segfaults on ARM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jul 02, 2013 at 10:28:03PM +0100, Peter Robinson wrote:
On Tue, Jul 2, 2013 at 10:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
GNOME runs fine without hardware 3D support, but the llvmpipe code that
makes that possible segfaults on ARM.
gnome runs fine on ARM as well without
' responsibility to deal with it. I don't think
it's excessive to say that you really need someone with the ability to
maintain something that's such a system-critical component.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
mean
it's likely to be you that gets to fix it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to be the kind of thing designed to turn any
small slip into weeks.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
that that's true.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
this point the release will only be delayed if an issue is
discovered that is deemed of exceptional importance is a perfectly
reasonable thing to document.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
probably kind of make it work if you try hard enough'.
Since F17 we've had a track record of It'll work fine, as long as you
don't hit a kernel bug. Which is exactly where we are with every other
platform.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
thanks to those who made this
possible.
Congratulations on getting this far! Is there documentation of the delta
between ARM and primary architectures? I'm thinking things like no
llvmpipe/clang or limited interactive Anaconda support.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
On Fri, Jun 28, 2013 at 10:43:33AM -0700, Adam Williamson wrote:
With all respect, the bug reports and blogs I've read would not lead me
to support that assertion.
With all respect, bug numbers.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
figuring out
whether we can integrate the Firefox plugin finder with Packagekit in
some meaningful way.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Jun 15, 2013 at 08:24:33AM -0700, John Reiser wrote:
How can I force the system not to recognize a USB2.0 flash memory device at
USB1.1 speed?
You can't - it's negotiated at the host controller level, the OS isn't
involved.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing
for packages to flag that such accesses are genuine
and uninteresting.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to know for certain
whether you're going to be able to open or unlink a file is to attempt
to open or unlink that file, and we shouldn't encourage people to think
otherwise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
that works
under all circumstances, not just the ones where we can add a stat() in
front and call it done.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Jun 08, 2013 at 09:53:39AM -0400, Steve Grubb wrote:
No real difference between them.
Make sure that you're testing this on a partition mounted with
strictatime.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
in the first place or to provide a mechanism so that legitimate accesses
don't generate audit records.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
by audit?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Jun 07, 2013 at 08:38:56PM +0200, Miloslav Trmač wrote:
On Fri, Jun 7, 2013 at 8:29 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
So why not add a mechanism to permit applications to indicate that
certain accesses they make should be ignored by audit?
Because it would be primarily
?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rather than strict atime for years.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
was not privileged (CAP_FOWNER).
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote:
On 7 June 2013 12:29, Matthew Garrett mj...@srcf.ucam.org wrote:
So why not add a mechanism to permit applications to indicate that
certain accesses they make should be ignored by audit?
Just so people know, this is like
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
in the field they're talking about and able to communicate
that competence. It's vital information for making a realistic judgement
of whether a proposal should be in the final program or not.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
an actualy crash happens, so that
by default nobody has to have this serice running.
This specific one is scraping previous kernel crash reports out of
pstore, so it should really only be doing something if there's anything
there.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
of that application.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, May 03, 2013 at 10:53:35PM -0600, Pete Zaitcev wrote:
On Sat, 4 May 2013 05:32:18 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a
forum that's read by the people who made that decision.
This is a perfectly
On Fri, May 03, 2013 at 09:41:39PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 9:32 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a
forum that's read by the people who made that decision.
Anaconda developers don't
On Sat, May 04, 2013 at 09:42:22AM -0700, Adam Williamson wrote:
On Sat, 2013-05-04 at 04:58 +0100, Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion -
anaconda-devel-list is a better choice if you want to interact with the
people who actually work
if I was crazy or
stupid.
I have reopened this. Clearly, this is a unprecedented decision and
it should be reconsidered.
It's unprecedented for maintainers to make UI decisions about the
software they develop and maintain?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote:
On 05/03/2013 10:31 PM, Matthew Garrett wrote:
It's unprecedented for maintainers to make UI decisions about the
software they develop and maintain?
Is that a rhetorical question? I was referring to the decision to
show
On Fri, May 03, 2013 at 11:11:56PM -0400, Rahul Sundaram wrote:
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
Many UI decisions are unprecedented. That doesn't justify
reopening bugs that the maintainer has closed. If you want to have
a discussion about whether or not this is a reasonable UI
On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
And if the maintainers feel more than justified in closing it again?
Bugzilla isn't a discussion forum. If disagree with a deliberate policy
decision
On Fri, May 03, 2013 at 11:55:24PM -0400, Rahul Sundaram wrote:
On 05/03/2013 11:51 PM, Matthew Garrett wrote:
And if the maintainers feel more than justified in closing it again?
Hopefully, they will reconsider their decision before doing that.
You seem to be claiming that once the maintainer
On Fri, May 03, 2013 at 08:59:11PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
No, this isn't the most appropriate mailing list for the discussion
anaconda-devel-list is a better choice if you want to interact with the
people who
On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
On 5/3/13 10:58 PM, Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion -
anaconda-devel-list is a better choice if you want to interact with the
people who actually work on that code
On Sat, May 04, 2013 at 12:11:21AM -0400, Felix Miata wrote:
On 2013-05-04 04:58 (GMT+0100) Matthew Garrett composed:
this isn't the most appropriate mailing list for the discussion -
anaconda-devel-list is a better choice if you want to interact with the
people who actually work
On Sat, May 04, 2013 at 12:07:30AM -0400, Rahul Sundaram wrote:
On Sat, May 4, 2013 at 12:01 AM, Matthew Garrett wrote:
I'm saying that if a bug report has been closed due to the change being
a deliberate design decision, reopening the bug isn't going to change
the fact
to the thermal limits provided by the
platform. If the platform doesn't provide any thermal limits then you
can write a value to the passive file in the ACPI thermal zone and it'll
limit the frequency when it reaches that temperature.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
. The code's available and you can attach patches in
bugzilla.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and then reboot.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Mar 13, 2013 at 01:28:36PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
Worse than that, having grub check for a held key will significantly
slow down the boot process even if there's no key being held.
How long is significantly? How hard
On Wed, Mar 13, 2013 at 02:52:23PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
How long is significantly? How hard is it to check for a keypress?
On the order of a second or two.
That doesn't seem all that significant to me; I guess we have
On Mon, Mar 11, 2013 at 11:03:24AM +0100, Dario Lesca wrote:
Question: there is some way to resolve the high CPU usage of gnome-shell
and change the video resolution when projector is connect?
No. The gma500 devices have no worthwhile free driver support.
--
Matthew Garrett | mj
. Moving in this direction shouldn't happen until
there's worthwhile support in the desktop UI for using the boot
indicators spec.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
for your hardware.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
maintainers
aren't enthusiastic about removing their existing aliases, it's probably
going to have to be resolved as a policy issue via FESCO.
--
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 Fri, Feb 01, 2013 at 08:19:30PM -0500, Paul Wouters wrote:
On Fri, 1 Feb 2013, Matthew Garrett wrote:
other than providing other sources of entropy, and long-term this is
going to be fixed once everyone's moved to Ivy Bridge and has an
unprivileged instruction to hand out entropy.
uhm
On Fri, Feb 01, 2013 at 08:17:26PM -0500, Paul Wouters wrote:
The guests can always run their own rngd type tool?
Yeah, this just makes host randomness available to the guest - it
doesn't directly feed it to /dev/random. The guest still gets to define
its own policy.
--
Matthew Garrett | mj
On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
as legal has said we cannot pregenerate initramfses i think this should
be a non-starter.
We already ship several pre-generated initramfses.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
machines.
Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs should have all the information you need
without name-based heuristics.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Tue, Jan 29, 2013 at 12:13:37PM -0600, Andrew McNabb wrote:
On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote:
Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs should have all the information you need
without name-based
- if my primary
network connection is via a USB device there's a reasonable chance that
it'll be called usb0 anyway. The name isn't providing extra information
here.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
On Tue, 29 Jan 2013 16:32:12 +
Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
as legal has said we cannot pregenerate initramfses i think this
should be a non
, if you prefer) as it currently does.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
before reboot, so presumably you're
talking about some upgrade system other than the currently supported
one?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
for that aren't properly aligned to make that
happen...
If you don't like what we produce, you're not obliged to use it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
have physical access to your system then I can just write my own
keys directly into flash with an SPI programmer. That's never been the
threat model.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
on the installation
media, and they will be installed.
Yes, if you boot an installer that doesn't verify signatures, you won't
verify signatures.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Jan 09, 2013 at 03:20:16PM +0100, Tomas Mraz wrote:
On Wed, 2013-01-09 at 14:15 +, Matthew Garrett wrote:
Yes, if you boot an installer that doesn't verify signatures, you won't
verify signatures.
But then what's the difference from distrusting the contents
On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
cp /boot/efi/EFI/fedora/grubx64.efi
/boot/efi/EFI/System/Library/CoreServices/boot.efi
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Make sure that the config is using linuxefi and initrdefi, not linux and
initrd.
--
Matthew
into Fedora
as well...
Why? syslinux fits a specific niche, but gummiboot doesn't seem to.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Jan 05, 2013 at 03:08:29PM -0500, Matthew Miller wrote:
What about making this an optional bootloader in F19 (in kickstart and via a
hidden option)?
I don't think there'd be any objection to that - it makes sense for
appliance-type scenarios.
--
Matthew Garrett | mj...@srcf.ucam.org
the guidelines force people to use libexec.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
have input on the
best format for the PA discussions during the FUDCon event in January.
Are you looking at F19 or F20 for PA?
--
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 04:37:59PM +, Richard W.M. Jones wrote:
On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
fyi: libexec has been critical to virtualization for quite some time...
I think Don is referring
On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote:
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote:
Is the path user visible in any way?
If used, /usr/libexec/qemu-bridge-helper is encoded directly in the
libvirt XML. So is libvirt_lxc. (So is /usr/libexec
On Fri, Dec 21, 2012 at 09:06:07AM -0800, Brendan Conoboy wrote:
On 12/21/2012 08:53 AM, Matthew Garrett wrote:
Are you looking at F19 or F20 for PA?
This will be a very engaging topic at FUDCon next month. Current
logistics make the following likely:
F19: Transition to enterprise ARM
though because it isn't a
binary
end users will ever directly invoke.
That seems fine. libexec is a perfectly reasonable place for it to be on
Fedora, and other distributions can stick them in lib/libvirt. Where
they're this opaque there's no problem.
--
Matthew Garrett | mj...@srcf.ucam.org
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
101 - 200 of 691 matches
Mail list logo
