On Sat, Aug 12, 2023 at 12:07:05PM +0200, Leon Fauster via devel wrote:
> Please do not clutter the user experience with such _additional_
> informations. The user on such workstations are not always the
> administrator and such informations would not help/change the
> situation either. I
On Sat, Jul 22, 2023 at 10:32:01AM +0200, drago01 wrote:
> Which file systems are considered uncommon in that context? And aren't most
> attacks based on file systems used by windows, which makes them "common" ?
> (Extfat, NTFS, VFAT)
Any attack here is going to be OS-specific - a vulnerability
On Sat, Jul 22, 2023 at 10:12:33AM -0400, Neal Gompa wrote:
> Several years ago, SUSE distributions moved to disabling the modules
> by default for a number of filesystems, but making it pretty easy to
> turn them back on:
> https://github.com/openSUSE/suse-module-tools/pull/5
The problem there
A discussion within Debian again brought up the problem that:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
2) Kernel upstream are not terribly concerned with ensuring that kernel
filesystems are resilient against deliberately malformed filesystems so
are
On Tue, Jan 21, 2020 at 12:43:47PM +, Matthew Garrett wrote:
> configinitrd file1 file2 file3
> initrd initramfs1.img initramfs2.img CONFIG
Huh - it seems like grub may already support this? It looks like:
initrd initramfs.img newc:/etc/crypttab:/boot/crypttab
will add /boot/cr
le3
initrd initramfs1.img initramfs2.img CONFIG
where the first command generates the image and the second command
causes it to be placed at the end of the final cpio blob?
--
Matthew Garrett | mj...@srcf.ucam.org
___
devel mailing list -- devel@lis
On Tue, Jan 21, 2020 at 09:09:16AM +0100, Petr Pisar wrote:
> On Tue, Jan 21, 2020 at 12:57:50AM +0000, Matthew Garrett wrote:
> > Any thoughts on this?
> >
> Properly measured system must measure all inputs. If you move the varying
> bits from initramfs to another file, a
ements to whatever's verifying the measurements. That's not easy.
--
Matthew Garrett | mj...@srcf.ucam.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https:
on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code
On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Measured boot is a process whereby each component in the boot chain
> > "measures" the next component. In the TPM 1.x world (which is where most
> > of us still are),
On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote:
> On 08.04.2016 18:56, Matthew Garrett wrote:
> > initrd is certainly a more difficult one. One thing we can do is work on
> > making dracut builds reproducible - that way they should be consistent
> > acro
On Fri, Apr 08, 2016 at 11:36:33AM +0200, Florian Weimer wrote:
> On 04/08/2016 10:28 AM, Matthew Garrett wrote:
> > With what we now know about malicious actors targeting the system boot
> > chain (even down to the firmware), this kind of TPM-based work is a
> > vital par
One thing we can do is work on
making dracut builds reproducible - that way they should be consistent
across identical machines in a cluster.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/li
servers and I want to know
that they're trustworthy before I give them access to resources".
Rearchitecting a large number of apps into a more SGXy world is a far
from trivial task.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
t possible to
assign local policy to which things get logged into which PCR. But I
think we're in a great position to start developing well-integrated
features that take advantage of this kind of hardware-level security.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedorap
On Tue, Apr 14, 2015 at 12:39:04AM +, Zbigniew Jędrzejewski-Szmek wrote:
Yeah, hibernation is automatically invoked when battery runs low
Is this actually the default behaviour?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
key, enroll it with mokutil and
then sign the modules with that key.
--
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
scenario would certainly be
for Google to update their packages, but if they don't then how does
rendering the package uninstallable benefit our users who want to
install it?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote:
On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Maintaining software in general is a burden, but we do it for the
benefit of our users anyway. The best case scenario would certainly be
for Google
.
--
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
, there was absolutely an impolite tone - it confounded there
being no interest in making a single package work on ARM with the Fedora
ARM community having no interest in feature parity. These are not
actually the same thing, and the fact that I equated them was
inappropriate.
--
Matthew Garrett | mj
on every aarch64 machine, even ones that have not been
seen before.
UEFI should be an improvement in this respect, but there's really no
fundamental benefit to using ACPI rather than DTB for hardware
description.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Tue, Jun 10, 2014 at 11:29:41PM +0100, Matthew Garrett wrote:
Ok, I was entirely unaware of that, and it does change things. Thanks
for letting me know. I'll look into whether it's practical to generate a
list of all the existing ExcludeArch packages and automatically check
whether
On Tue, Jun 10, 2014 at 07:54:26AM +0100, Richard W.M. Jones wrote:
On Mon, Jun 09, 2014 at 10:20:46PM +0100, Matthew Garrett wrote:
On Mon, Jun 09, 2014 at 08:43:07PM +0100, Richard W.M. Jones wrote:
Can we excludearch %{arm} for this one?
Why? It's a bug that it doesn't build
On Tue, Jun 10, 2014 at 05:23:01PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 03:45:57PM +0100, Matthew Garrett wrote:
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse
On Tue, Jun 10, 2014 at 06:14:03PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 06:00:05PM +0100, Matthew Garrett wrote:
ExcludeArch implies that it's acceptable that it doesn't build on ARM
and removes the incentive for anyone to fix it. It's not.
There's a process
be restored if we
actually need to make any code changes.
--
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
On Tue, Jun 10, 2014 at 06:44:06PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 10, 2014 at 06:39:52PM +0100, Matthew Garrett wrote:
Ok. Once the build's done let's remove the ExcludeArch so it continues
to show up as a failure in mass builds. It can be restored if we
actually need
should just drop it on ARM, and let anyone
who wants it, fix it later (or reenable %{arm} if clang gets fixed).
If the Fedora/ARM community don't care about feature parity with x86,
then we should just drop them back to secondary status.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
architectures. Having a subset of our packages fail to build on ARM
means that's not true, and the current state of affairs clearly violates
point 8 of the architecture promotion requirements. How can we fix this?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Tue, Jun 10, 2014 at 07:11:53PM +0100, Matthew Garrett wrote:
On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
In this case however I don't think much productive came from this
discussion we had about hfsplus-tools. Obviously no one wants
hfsplus-tools and/or clang
users and the
ecosystem as a whole.
--
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
a team to hunt down and fix portability issues that
are sufficiently far from the core that the existing ARM community can't
justify the time? And if so, is there any way we can make that happen?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
do we do?
--
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
On Tue, Jun 10, 2014 at 10:52:19PM +0100, Peter Robinson wrote:
On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
In the past 6 months, 6 bugs added, 2 bugs closed -
https://bugzilla.redhat.com/show_activity.cgi?id=485251 .
If you're going on just the bug tracker
On Wed, Jun 11, 2014 at 01:53:12AM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
Eh. We're constrained by our own policies here, not by anything
fundamental - LLVM being broken on ARM ought to mean that our ARM
product is worse, not that everything else is dragged down to the same
in order to build x86 install images, so not really.
--
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
llvm.
--
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
On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote:
Did any of your gnome-shell extensions break ?
Isn't this inevitable? If any extensions only claim to support 3.10 then
they'll stop working until updated.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Thu, Apr 03, 2014 at 04:57:10PM +0200, Miloslav Trmač wrote:
2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org:
Isn't this inevitable? If any extensions only claim to support 3.10 then
they'll stop working until updated.
One, at least theoretical, way to resolve this would
was that there was no mechanism for automatically
updating extensions at present.
--
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
and testing is risky and unreasonable. At best, it
would complicate problem reporting, reproduction, analysis and
correction.
The suggestion is to replace the tool, not the library.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
mean MGA, not MCA. It's entirely possible that there's a bug in
the mgag200 driver that's resulting in a failure to get the correct
EDID, but that's a kernel bug rather than an anaconda one.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
we should concentrate on finding a way to make this possible without
compromising the common case.
--
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
being pretty close to
statistically indistinguishable from 0.
--
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
you be more concrete which term(s) you don't understand? Maybe you are
right and the concept needs to be better explained / presented differently
prior wider adoption [**].
What is a Data stream? What is a Checklist? How do I know which ones
to pick?
--
Matthew Garrett | mj...@srcf.ucam.org
On Fri, Mar 14, 2014 at 02:51:10PM -0400, Steve Grubb wrote:
On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote:
If there's a default policy that would make sense for most workstation
users, we should just make that the default.
Right now there is just one policy. In there future
On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote:
On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote:
Having separate server, workstation and cloud products means we can
apply separate defaults without requiring user interaction. Beyond that,
why would an end user want
On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote:
On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote:
If there's a default policy that would make sense for most workstation
users, we should just make that the default. If there isn't, how are we
going
is to make it as easy as possible for the user
to end up with a working system. Adding options that make it
straightforward for the user to end up with a non-working system is a
backwards step.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote:
On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote:
How does the average user make an informed decision about whether an
available security policy is appropriate for them?
I guess we'll have to describe
On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote:
On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote:
The failure mode of making the wrong choice regarding an encrypted
partition or the default user being an administrator involves the system
*continuing
On Fri, Mar 14, 2014 at 06:24:36PM -0400, Eric H. Christensen wrote:
On Fri, Mar 14, 2014 at 08:01:53PM +, Matthew Garrett wrote:
If an incorrect choice means that the software the user wants to run
won't run, that's going to be a problem for the user. And we presumably
expect
How would this alter the default user installation experience?
--
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
no oscap entry in Kickstart? Is the user expected to provide a
path to download a policy?
--
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
that. What's the use-case for providing UI rather than
limiting deployment to Kickstart?
--
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
build systems is.
[1] On x86, anyway. I don't know what the ARM VM split is.
--
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 out.
--
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
On Tue, Feb 04, 2014 at 04:18:27PM -0700, Chris Murphy wrote:
Does anyone know why the convention is to create the ESP as the first
partition?
Because that's the only configuration anyone's likely to have tested.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
option which was much of the market between
2009 and 2011. These implementations will frequently understand GPT well
enough to decide that a disk isn't BIOS bootable, but won't let you
perform a UEFI boot instead.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
the usage of the
linux16/initrd16 commands instead of linux/initrd commands for
the BIOS-mode boot.
Yeah it's really a mistake for us to be using the linux/initrd commands
under any circumstances.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
? Is it installed as bootx64.efi?
IIRC that approach used to be frowned upon.
It installs a fallback loader as bootx64.efi which then creates new boot
entries for any installed operating systems it can find.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
of necessary on large disks?
There's not really anything else we can do in that case, so we make a
best effort and if it doesn't work then, well.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it much easier to exploit null pointer
vulnerabilities in the kernel. Recent (within the past few years…)
kernels will refuse to let you mmap stuff below 64K or so regardless of
selinux policy, so this may break on other distributions as well.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
would like to not break the vesa driver, while still killing the suid bit on
the X server.
It's probably worth considering whether porting uvesafb to kms would be
worthwhile, and then just using -modesetting.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote:
Hi,
On 01/20/2014 03:18 PM, Matthew Garrett wrote:
-mga is probably also still relevant in some small number of cases.
Don't we've a kms driver for those? Or you mean for mga cards not supported by
the kms driver?
The KMS
On Mon, Jan 20, 2014 at 03:58:23PM +, Richard W.M. Jones wrote:
On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote:
We can probably kill -cirrus.
qemu? (I know that people should be using QXL, but cirrus is still
the default in plain qemu, and IMHO simpler and more secure
straightforward to re-implement the helper if it's
vanished entirely - we haven't retired libx86, and the rest is pretty
trivial.
Or do you mean the older pre-uvesafb driver?
That's problematic from the You have to provide a fixed resolution on
the kernel command line perspective.
--
Matthew
by
mgag200 and doesn't the vmwgfx driver cover vmware?
--
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
On Mon, Jan 20, 2014 at 10:54:22AM -0800, Andrew Lutomirski wrote:
On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
It'd be pretty straightforward to re-implement the helper if it's
vanished entirely - we haven't retired libx86, and the rest is pretty
trivial
is always going to remain at /boot/efi, not /boot. This
is a situation that's already allowed by the spec, so fixing it would
just be a matter of deleting the section about using the ESP as $BOOT.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
and libevent
upstream to find a solution that'll work for all distributions, rather
than being limited to Fedora hacks.
--
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
that they're not being exported. If they
don't, you shouldn't use them.
--
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
On Tue, Nov 19, 2013 at 01:31:20PM -0600, Chris Adams wrote:
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
If the headers describe a stable interface that should be used by
userland then it's a kernel bug that they're not being exported. If they
don't, you shouldn't use them
On Wed, Oct 30, 2013 at 09:01:52AM -0400, Josh Boyer wrote:
The Fedora Workstation Work Group has nine voting members, with one
member selected by the Fedora Engineering Steering Committee as the
liaison to FESCo.
Is the FESCo appointed member one of the nine voting members?
--
Matthew
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target display mode is a vendor extension, and
switching it will be vendor specific.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support provides stack guard value in global
/show_bug.cgi?id=1019452
Great. Thanks, Carlos!
--
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
On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote:
On Oct 15, 2013, at 10:36 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target
to support the same set of features.
Did the arm32 portions of this end up being completed for F20?
--
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
for the working group to set their own
priorities. I don't see any role for FESCo in making that decision.
--
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
. The
community representatives on FESCo and the board discussed it. All of
this happened in public. Which community do you feel was given no
opportunity to represent their opinions?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Fri, Oct 11, 2013 at 04:19:00PM +, Jóhann B. Guðmundsson wrote:
On 10/11/2013 03:59 PM, Matthew Garrett wrote:
community representatives on FESCo and the board discussed it. All of
this happened in public. Which community do you feel was given no
opportunity to represent their opinions
On Fri, Oct 11, 2013 at 04:33:24PM +, Jóhann B. Guðmundsson wrote:
On 10/11/2013 04:27 PM, Matthew Garrett wrote:
Was there any attempt to reach out to the relevant sub-community was
there a mail or discussion held on the server list even if only to
see who where active on it?
Given
On Fri, Oct 11, 2013 at 04:47:34PM +, Jóhann B. Guðmundsson wrote:
On 10/11/2013 04:41 PM, Matthew Garrett wrote:
Because there's no active server sub-community. The people interested in
server work are working within the general Fedora development community,
which means devel
On Thu, Sep 12, 2013 at 05:39:29PM -0500, Dennis Gilmore wrote:
I really do not think we can integrate this into our release processes
right now.
What work would need to be done in order to make it possible to
integrate this into the release process?
--
Matthew Garrett | mj...@srcf.ucam.org
a developer. In which case, perhaps you'd be willing to spend
the time that you're currently using to send angry mails to the list to
improve grub's support for Unicode characters when using VGA text mode?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
Maybe something like (the incredibly ugly)
http://www.codon.org.uk/~mjg59/tmp/mapping.diff
--
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
planning on dropping VESA support. It's
just that supporting it at the moment means that we continue to support
some UMS drivers, which makes it difficult to stick to a KMS or
nothing approach.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Tue, Aug 27, 2013 at 02:54:46PM +, Jóhann B. Guðmundsson wrote:
From this point forward only graphics driver that have kms support
will be allow to be packaged and shipped in the distribution
Only if you want to drop VESA support.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
.
--
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
testing that then QA
should be testing that.
--
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
On Thu, Aug 15, 2013 at 09:40:01AM -0400, Paul Wouters wrote:
On Thu, 15 Aug 2013, Matthew Garrett wrote:
I want increased participation in the creation of Fedora, which is a
product with a defined set of software shipped as default. I'm also
happy with people working to make it practical
something other than the supported upgrade mechanism,
then QA should rectify that. The communication has been very clear -
if fedup fails to upgrade then that's considered a bug, and if any other
approach fails then it may not be.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
and why?
Preupgrade was accepted into Fedora 8, so you'd probably need to go back
and review the feature discussion from then.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Oh, and to clarify - upgrades were supported even before then, but
required booting Anaconda from new install media. That's been true since
the Red Hat Linux days, so years before Fedora even existed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
that don't make things better for our
users, and so it's inappropriate to provide equivalent promotion.
--
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
On Wed, Aug 14, 2013 at 06:49:17PM -0400, Jóhann B. Guðmundsson wrote:
On 08/14/2013 06:04 PM, Matthew Garrett wrote:
Some projects are objectively better than other projects. Some projects
may not be objectively better but are more closely aligned with our
release schedule and support cycles
of the issue, as well as FESCo to track what items
are missing for full primary promotion.
Did this get set on packages that had ExcludeArch added while Arm was
still secondary?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote:
On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote:
Really? I'd expect most users to be using gmail at this point. Any
solution needs to account for them as well.
1. By the same logic we can ship just a browser, why bother
1 - 100 of 691 matches
Mail list logo
