for secondary arches to just disable parts of the
distribution because they won't build. This isn't platform-dependent
code, and if your architecture won't build it then your architecture
needs to make it build.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
and your panel turns off.
It could be any number of other problems as well, of course, but these
days most of the bugs like this are specific to a given
chipset/bios/panel combination rather than just being the chipset.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
ignored.
We're pretty much reached the point where we don't care about UMS for a
variety of cases, with suspend/resume being the most obvious. We're
still shipping the X drivers so I agree they shouldn't be entirely
ignored, but they're really a vere low priority.
--
Matthew Garrett | mj
some discussion about this on the FESCO
request
I submitted. I have some concerns about what was implemented. Are there bz
filed for this or more discussion about it somewhere?
We spent weeks discussing this. Where were you during the meetings?
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Aug 09, 2011 at 08:47:16AM -0400, Steve Grubb wrote:
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote:
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
This list is woefully incomplete. I would advocate a much larger list.
For example, sudo is a very
On Tue, Aug 09, 2011 at 10:17:29AM -0400, Steve Grubb wrote:
On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote:
You can't bring a policy to FESCO, fail to turn up to any of the
meetings
I didn't fail to turn up to any of the meetings. I watched the issue and
attended until
On Tue, Aug 09, 2011 at 04:53:16PM +0200, Björn Persson wrote:
Matthew Garrett wrote:
Unless the checking is part of autoqa this simply isn't
sufficient. There's a huge benefit to implementing it in the way that's
easiest for maintainers.
The earlier a problem is detected, the cheaper
be much easier fixed before the compilation.
Never, ever ship software with -Werror enabled. It's a development-only
option. You have no idea what gcc will decide is a warning in future, so
it's effectively a Please break my build in six months toggle.
--
Matthew Garrett | mj...@srcf.ucam.org
On Tue, Aug 09, 2011 at 07:34:48PM +0200, Jan Kratochvil wrote:
On Tue, 09 Aug 2011 19:16:54 +0200, Matthew Garrett wrote:
It's a development-only
option. You have no idea what gcc will decide is a warning in future, so
it's effectively a Please break my build in six months toggle.
I
that this is being discussed
in fesco meetings, and Steve's Cc:ed on all of that. It's been on the
posted agendas for months. Yet the last time he was in #fedora-meeting
appears to have been in February. That's not an impressive amount of
involvement in the Fedora process.
--
Matthew Garrett | mj
it was linked against,
which is the way Debian handle this in the absence of maintainer
overrides.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
- the problem isn't limited to
subpackages.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
It is in this situation, but there are other situations where depending
on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol,
anything built against it may fail to run against libfoo 1.0. But how
will you know that in advance if all you have in your dependencies is
the SONAME?
--
Matthew
On Fri, Aug 12, 2011 at 09:26:33AM -0700, Toshio Kuratomi wrote:
On Fri, Aug 12, 2011 at 04:40:20PM +0100, Matthew Garrett wrote:
Upstream can change the ABI as much as they want without bumping the
SONAME providing that the old interfaces are also present. It's entirely
possible to end
idea.
You'd have the same problem with any init system that supports automatic
service restarting. You can easily disable the service via systemctl.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
below the hard problems that
impact a pretty large set of people.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Aug 30, 2011 at 03:20:22PM +0200, Tomas Mraz wrote:
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote:
ACPI turned out to be full of lies. The real problem is that machines
will report a floppy controller even if they have no floppy drives
attached, and the ACPI function
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 14:26:39 +0100,
Matthew Garrett mj...@srcf.ucam.org wrote:
Or just add floppy-support and analog-joystick-support packages that
include appropriate modprobe.conf fragments, and have documentation
files to determine
what to load, only what to do if it is loaded. So it may be that udev
is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote:
Matthew Garrett (mj...@srcf.ucam.org) said:
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Is there a reason
dropped that rule in their trunk.) I don't know whether it
makes any sense though. I presume this is just testing for the presence of a
gameport without caring about what is connected, right?
Right.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
be less than ideal if there's
something other than a standard analog joystick connected.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Work on any hardware
it encounters if at all possible.
There's plenty of hardware that Fedora could work on but doesn't because
the maintainers aren't willing to make the tradeoffs.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
to the tools associated with it for no useful benefit.
Just install the grub package in the guest, and chroot into the guest if
you need to run grub-install there.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Thu, Sep 15, 2011 at 03:36:55PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
So I propose that we drop this conflicts and fix grubby instead.
No. It is not sane
On Thu, Sep 15, 2011 at 04:21:36PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 15, 2011 at 03:59:57PM +0100, Matthew Garrett wrote:
We're talking about guest creation, aren't we?
No, we're talking about fixing and resizing existing guests, where
grub-install needs to be run to fix
. The only supportable bootloader for a
specific guest is the bootloader that matches the installed OS. If you
want to support grub2 on Ubuntu, for instance, you'll need Ubuntu's
grub2 - not Fedora's. The binary interface may have changed between
them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
On Thu, Sep 15, 2011 at 11:19:24AM -0500, Ian Pilcher wrote:
On 09/15/2011 09:59 AM, Matthew Garrett wrote:
We're talking about guest creation, aren't we? Why would you ever need
to run grub-install against a guest image that already exists? And if
you do, you're already going to have
On Fri, Sep 16, 2011 at 03:01:06PM -0400, Doug Ledford wrote:
On 9/15/2011 12:01 PM, Matthew Garrett wrote:
On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote:
The most obvious case where it can fail involves grub being effectively
unmaintained, and so various vendors have
it. This
works fine for package dependencies, but I'd imagine file-based
dependencies would make things more awkward.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Sep 19, 2011 at 01:00:35PM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
Debian policy is that any virtual dependencies must also have an
explicit dependency. In your case it would be something like
Requires: phonon-backend-gstreamer | phonon-backend
Unfortunately, RPM
), as
Matthew Garrett pointed out, are the right solution, not soft dependencies
(though those would also be nice).
Kevin Kofler
Functionally speaking, what is the difference between a soft dependency
and a disjunctive dependency? How can you satisfy a soft dependency if
you don't know
be safe. If you're not, it's not guaranteed to be safe.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is already satisfied IMO. But, I didn't write
any spec around that, so it may be implemented differently in the real
(deb) world.
It is.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
we've ever
released, it is *not* guaranteed that that remains true, or even that
it's true between us and any distribution that may be installed in a
guest.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
queues.
We're in the freeze for beta. It's not reasonable to push new sonames
into the distribution at this point.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
of branching.
That does seem like pretty fair criticism. We should probably discuss
this for the F17 timeframe.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
into a distribution that's attempting to stabalise
for release. Really. Don't do that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
On 09/20/2011 04:37 PM, Matthew Garrett wrote:
What the maintainers could have done is not upload a package that breaks
binary compatibility into a distribution that's attempting to stabalise
for release.
That's a way too
On Wed, Sep 21, 2011 at 08:39:24PM +0100, Mark McLoughlin wrote:
On Wed, 2011-09-21 at 18:48 +0100, Matthew Garrett wrote:
Remember that the incompatibility isn't between libguestfs and the
guest, it's between the host grub and the guest grub. Both of those
can change without libguestfs's
is not designed to be compatible across arbitrary versions, and so using
it with that expectation is inappropriate.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
incorrect.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Sep 22, 2011 at 04:50:16PM +0100, Mark McLoughlin wrote:
On Thu, 2011-09-22 at 14:05 +0100, Matthew Garrett wrote:
The grub maintainer is telling you that the way in which you're trying
to use grub is broken. You *need* to use the grub files that are in
guest, not the host
On Thu, Sep 22, 2011 at 05:18:09PM +0100, Mark McLoughlin wrote:
On Thu, 2011-09-22 at 17:00 +0100, Matthew Garrett wrote:
grub provides no mechanism for you to know that, which means you can't
reliably know that. Which means relying on them being compatible is
incorrect.
You described
are worrying about grub and grub2?
They don't both attempt to sit in the same few bytes.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Sep 22, 2011 at 07:38:54PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 22, 2011 at 05:37:39PM +0100, Matthew Garrett wrote:
I described something that is, practically speaking, impossible.
We allow you to inspect the guest to find the OS version, and even
versions of individual
the argument is wrong.
Above all people Matthew I thought you were aware of how strawmen work and
would be against their use.
Because it means additional complexity for any tools which have to
interact with the bootloader and provides no benefit for any real
usecases.
--
Matthew Garrett | mj
On Thu, Sep 22, 2011 at 09:23:40PM +0200, Miloslav Trmač wrote:
On Thu, Sep 22, 2011 at 8:40 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, Sep 22, 2011 at 07:38:54PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 22, 2011 at 05:37:39PM +0100, Matthew Garrett wrote:
We allow you
the constraints that are being imposed,
but this approach certainly isn't a solution.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it, and you've been told that this is behaviour that you can't
depend on. If you choose to do so then fine, but any bugs filed against
grub are just going to be closed. You're trying to do something
unsupported. Depending on unsupported and undefined behaviour is bad
design.
--
Matthew Garrett | mj
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
their monitors.
Windows doesn't appear to be DPI-sensitive.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the problem you're trying to solve, and then work
out whether figuring out the real DPI would solve it. Unless your
problem statement is unrealistically narrow, the answer is that it
wouldn't.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
the decision to have gnome run at
96dpi regardless of the output is an entirely rational one and anyone
who argues otherwise gets to explain how all the difficult bits would
work. The end.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
of technical advances that
nobody's even working on right now. It's worth thinking about. It's just
not something that we're anywhere near being able to implement, and as
such it's pretty unrelated to the original observation which is that
trusting EDID right now will just get you burned.
--
Matthew
On Wed, Oct 05, 2011 at 11:11:38PM +0200, Benny Amorsen wrote:
Matthew Garrett mj...@srcf.ucam.org writes:
We have no technological solution for dealing with the fact that
applications may move from one DPI to another at runtime, and may even
be displaying on both displays at once
On Thu, Oct 06, 2011 at 01:13:21PM +0200, Nicolas Mailhot wrote:
Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit :
This... works badly. Really. Open gimp and add some text. Now double the
size of the font. Save the image and open it in image viewer, and zoom
out so the text is half
ask the typical user for information that's too cumbersome to
use, oui? Like asking them to use a physical ruler to match up against.
Like I said, that works fine right up until the point where you plug in
a monitor with a different DPI. What do we do then?
--
Matthew Garrett | mj
On Thu, Oct 06, 2011 at 09:30:50AM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
Like I said, that works fine right up until the point where you plug in
a monitor with a different DPI. What do we do then?
I would wager that the majority of Fedora
of problems doesn't seem like a worthwhile
way to spend time. The only people who are actively upset by the status
quo are the ones who have the ability to fix it for their case, anyway.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
that Operating Systems can rely on?
The specification provides everything needed to express this data
accurately, and proves the worth of specifications by virtue of
approximately nobody actually implementing it correctly.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel
On Thu, Oct 06, 2011 at 05:33:48PM +0200, Nicolas Mailhot wrote:
Le Jeu 6 octobre 2011 17:18, Matthew Garrett a écrit :
The heuristic isn't the problem. The problem is that we have no
technology that allows us to handle the complicated case of multiple
displays, and solving it purely
internal display would be a different size and possibly even in a
different place.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Oct 06, 2011 at 11:39:16AM -0400, Jon Masters wrote:
On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote:
On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote:
How about EDID as it exists today. Since you're able to so beautifully
explain what the pitfalls are, I'd
that there should be an easy mechanism to globally
change font size. But I don't think tying it to DPI is helpful.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Oct 06, 2011 at 09:22:22PM +0200, Nicolas Mailhot wrote:
Le jeudi 06 octobre 2011 à 16:41 +0100, Matthew Garrett a écrit :
What heuristic?
The one you were writing about
The heuristic I was writing about is the Trust the DPI we get from EDID
if it's within some size range. We don't
not grossly misanalysing the data, it seems that we
could drop the proventester requirement from critical path updates with
a negligable change in the quality of the updates. Thoughts?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https
use of bugzilla.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
conversation that way.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
inappropriate
gets elected.
Anyone have opinions on what we should be doing here?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, 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
update.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
(20)
* mmaslano (19)
* ajax (11)
* zodbot (9)
* gholms (4)
* lmacken (3)
* nb (2)
* abadger1999 (1)
* pjones (0)
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote:
We don't support out of tree kernel modules at all, so they're not
considered when making the determination about whether an update is
appropriate for a stable
is notorious).
The least we can do is helping third-party packagers to fix this
issue, not slamming the door on their face.
The supported way to provide a module for Fedora is to have it in the
upstream kernel source. Anything else is explicitly not supported.
--
Matthew Garrett | mj
On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 05:12:12PM +, Matthew Garrett wrote:
I don't know how much clearer I can make this. The update policy applies
to the supported ABI of the package. For instance, if I have an
application
other people to care as much as you or you
need to come up with a proposal yourself.
Does that governing body only exist to say yay or nay to others proposals?
As a body, yes. As individuals, no.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Nov 22, 2011 at 10:49:28AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote:
Consuming the output of ls is a supported way to use ls. Building third
party modules is not a supported way to use the kernel.
That's not the criteria I see
On Tue, Nov 22, 2011 at 11:44:59AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:57:30PM +, Matthew Garrett wrote:
So just to be clear on this, you believe that if a user is relying on
byte 0x9e0 of /bin/ls to be 0xdf on x86_64, then that is something that
would have
On Tue, Nov 22, 2011 at 12:09:26PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 07:53:12PM +, Matthew Garrett wrote:
No. You're simply interpreting things incorrectly.
*sigh* You miss the point. I'm perfectly willing to be interpreting it
incorrectly. The problem
On Tue, Nov 22, 2011 at 12:50:40PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 08:28:30PM +, Matthew Garrett wrote:
If you interpret The ABI as Any property of the binary that another
package could conceivably depend on then your position makes sense. But
since nobody would
On Tue, Nov 22, 2011 at 01:44:26PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 08:53:33PM +, Matthew Garrett wrote:
Really. Use common sense. You appear to be the only person who's
strongly confused on this issue.
http://lists.fedoraproject.org/pipermail/devel/2011-November
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Dec 03, 2011 at 06:19:27PM +0100, Andreas Tunek wrote:
Yes, and the question becomes, can we make this easier in F17?
Yes, we can do EFI installs.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
stops all userspace programs.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Dec 05, 2011 at 10:49:39AM -0800, Adam Williamson wrote:
On Sat, 2011-12-03 at 17:54 +, Matthew Garrett wrote:
On Sat, Dec 03, 2011 at 06:19:27PM +0100, Andreas Tunek wrote:
Yes, and the question becomes, can we make this easier in F17?
Yes, we can do EFI installs.
We
to maintain this code in Fedora then it's worth
having a discussion about it, but otherwise there simply isn't enough
manpower available to do a proper job of looking after the code. That's
not politics.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
that there's
a supportable version of the code available to use in the Fedora kernel,
or alternatively take over enough of the existing kernel work that
someone else gains enough time to take responsibility.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
that broke things in the first place.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the moment someone types in a
root password, even if they're on a different terminal. I accept that
this is a barrier, but the only real solution is to have each X session
run as a different user - and that requires Linux to gain revoke()
support.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel
of two
evils instead of no evils.
The lesser of 2 evils is no solution. Only NO evil at all will keep the
user's freedom. Users should NEVER use proprietary software, be it as
JavaScript or using a proprietary protocol.
How's your open x86 microcode coming along?
--
Matthew Garrett | mj
Install an MTA to
the list of things they have to do is entirely reasonable.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
elsewhere but would default to popping
up some sort of desktop notification.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Aug 24, 2010 at 09:46:26AM -0500, Michael Cronenworth wrote:
Matthew Garrett wrote:
The long term fix would arguably be to provide a stub /usr/sbin/sendmail
that ties into a more generic event reporting interface, which in turn
could be configured to send mail elsewhere but would
On Tue, Aug 24, 2010 at 10:53:13AM -0400, Matthew Miller wrote:
On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote:
There's certainly a set of people who want an MTA for this - in a server
environment it's obviously far more straightforward to get mailed on
failure
it with
something that's actually useful.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
badly, it's
probably worth thinking about writing code to fix the problem well.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
that we (as developers) wouldn't otherwise be able to get.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
regularly.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
with links.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1 - 100 of 691 matches
Mail list logo
