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 actually
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 i
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 i
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 mo
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/crypt
1 file2 file3
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 -- de
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
ted mechanism for passing the new initramfs
measurements 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 de
these
pre-built images in order to allow them to be validated.
Any thoughts 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.o
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), that
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
> > across id
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. 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/adm
x27;m running a bunch of 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 of the box, and I think it's worth taking it.
There's still some additional work to do, such as making it 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
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
ht
erate your own 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
On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote:
> On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett 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
> >
e best case 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.fedorap
e made, and
> shouldn't have been retracted.
In context, 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
e situation certainly isn't dreadful.
--
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 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 automatical
able to boot 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
--
deve
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 e
On Tue, Jun 10, 2014 at 10:52:19PM +0100, Peter Robinson wrote:
> On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett 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 jus
27;s others I'm unaware of but it's not because of
> the ARM team but rather the packager following procedures or engaging
> us for assistance.
The quantity of the archive that's built and working on ARM so far is a
testament to the amount of effort that the ARM community have put into
this port. The question is how to finish that. All I'm saying here is
that the current approach of filing bugs doesn't appear to be resulting
in people actually fixing their packages. It's unreasonable to expect
you to do all of it. So what 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
issue. Given a lack of direct
incentive for them to care about ARM, that's not terribly surprising.
What can we do about that? Is the only realistic answer to find the
resources to have a team to hunt down and fix portability issues that
are sufficiently far from the core that the ex
e, and so I'd really prefer us to figure out a way to
fix things. Improving code portability benefits us, our 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
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 want
imary
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
to fix it. So I think we 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..
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
failure in mass builds. It can 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: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 n
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
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?
> >
>
ild something that needs 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
d or not?
It's required 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
rstanding 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
On Thu, Apr 03, 2014 at 04:57:10PM +0200, Miloslav Trmač wrote:
> 2014-04-03 16:52 GMT+02:00 Matthew Garrett :
> > 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
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 maili
gt; explicit validating 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
however.
Ah. You 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
dev
On Fri, Mar 14, 2014 at 06:24:36PM -0400, Eric H. Christensen wrote:
> On Fri, Mar 14, 2014 at 08:01:53PM +0000, 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
On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote:
> On Fri, Mar 14, 2014 at 07:45:53PM +0000, Matthew Garrett wrote:
> > The failure mode of making the wrong choice regarding an encrypted
> > partition or the default user being an administrator invo
On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote:
> On Fri, Mar 14, 2014 at 07:31:55PM +0000, Matthew Garrett wrote:
> > How does the average user make an informed decision about whether an
> > available security policy is appropriate for them?
>
>
and install something
else instead.
The job of the installer 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.u
On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote:
> On Fri, Mar 14, 2014 at 03:00:20PM +0000, 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'
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,
> >
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
should be set
to or what the associated compromises are.
> > *I*
> > don't understand the terms used in the proposed UI,
>
> Can you be more concrete which term(s) you don't understand? Maybe you are
> right and the concept needs to be better explained / presented d
ey on the number of potential users who do 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
them by default anyway. I think
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
Fe
ruggling to imagine the scenario where a user actually
wants to do 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/mailm
file. What options are presented to the user if
there's 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
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
p there. Getting rid of
32-bit 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
in performance.
[1] I mean plausibly it's a bug in this particular Cirrus video BIOS,
but it'd be nice to actually figure 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
th CSM forcibly
enabled and no UEFI boot 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
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 ma
> Also, isn't this already sort 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://a
omehow been vanquished.
>
> How does firmware find shim.efi? 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 | m
in many cases.
> 3.) On my MacBoot Pro (late 2013) I required 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.
--
M
kes 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
--
On Mon, Jan 20, 2014 at 10:54:22AM -0800, Andrew Lutomirski wrote:
> On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett 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 pre
x is supported 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
e to provide a fixed resolution on
the kernel command line" perspective.
--
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 03:58:23PM +, Richard W.M. Jones wrote:
> On Mon, Jan 20, 2014 at 02:18:22PM +0000, Matthew Garrett wrote:
> > We can probably kill -cirrus.
>
> qemu? (I know that people "should" be using QXL, but cirrus is still
> the default in plai
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 support
amd drivers?
> I 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
o implement the boot loader spec as written - the EFI
system partition 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
o needs to link against both
then libverto upstream should really work with libev 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
On Tue, Nov 19, 2013 at 01:31:20PM -0600, Chris Adams wrote:
> Once upon a time, Matthew Garrett 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&#x
and then it's a kernel bug 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 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?
--
On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote:
>
> On Oct 15, 2013, at 10:36 AM, Matthew Garrett wrote:
>
> > On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
> >
> >> Or maybe Intel would be forthcoming. It's their hardware
rt from upstream.
> https://bugzilla.redhat.com/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 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 provide
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 mail
le support.
> - Enhance aarch64 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
Fe
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 commu
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
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
> >
n this mailing list. 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.fedo
much 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
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 Garret
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
27;re
presumably 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
VESA fallback,
> although I suspect that may not suffice in some cases.
Yeah, I don't think anyone's 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
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 Gar
ure that they have a full feature set.
--
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 valid bug and should be fixed or relnoted. That's been the
intention forever, and like I said, if QA aren't 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
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.fedoraprojec
ally see who made the decision to open that pandora
> box 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.f
uot;supported" or
> "recommended".
If QA is testing 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
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 w
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 ou
th and
development of other projects 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/listi
the arm team aware 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@list
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 ca
1 - 100 of 732 matches
Mail list logo
