ro
that should be fixed, I wouldn't bother disabling polling.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ale derivatives do, which means that
they need to work directly on Fedora. And, obviously, what it's
appropriate to do to the Fedora package set depends on who we want
Fedora to be for.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
r development efforts on a specific
goal. Xubuntu is worse than Debian because they're forced to cope with
architectural changes made without reference to them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
r QA efforts instead of potentially against them?
If a spin wants to use a modified kernel package, what's the procedure
for ensuring that it receives the same level of QA as the normal kernel?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedora
On Tue, Feb 02, 2010 at 02:19:35PM -0600, Adam Miller wrote:
> On Tue, Feb 2, 2010 at 2:01 PM, Matthew Garrett wrote:
>
> >Ubuntu is better than Debian
>
>
> If you honestly believe that, I have pitty on you.
For the market they're aiming at? I don't
On Tue, Feb 02, 2010 at 02:32:19PM -0600, Adam Miller wrote:
> On Tue, Feb 2, 2010 at 2:27 PM, Matthew Garrett wrote:
> > If a spin wants to use a modified kernel package, what's the procedure
> > for ensuring that it receives the same level of QA as the normal kernel
anything
> about it.
If it's not good enough for upstream, why is it good enough for us?
Who's committing to maintaining these patches? What's their turnaround
speed if a security issue forces an update tht breaks them?
--
Matthew Garrett | mj...@srcf.ucam.org
-
ing a Linux
filesystem who wants 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
-
se impacted should do the work necessary to ensure 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 |
anything other
than revert the change 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
to "Running code as X gives you root 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()
Script or using a proprietary protocol.
How's your open x86 microcode coming along?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
onfiguration for server admins, so adding "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
ide 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 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 se
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 g
untrue we should stop doing it and replace 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
more code to fix a problem 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
ves us debug
information 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
e do fairly regularly.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Lynx with 80×25 characters.
Works absolutely fine with links.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
w it's relevant.
>
> You suggested `gnome-display-properties`, which is a gnome tool with
> gnome package dependencies.
system-config-display depends on gtk, so it's all a matter of degree.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraprojec
On Thu, Aug 26, 2010 at 05:28:31PM -0400, Arthur Pemberton wrote:
> On Thu, Aug 26, 2010 at 4:11 PM, Matthew Garrett wrote:
> > system-config-display depends on gtk, so it's all a matter of degree.
>
> No, I would never mention Gtk as a dep.
So, like I said, it's a matt
ime, if you guys plan a move like that, then please do it
> a couple of weeks earlier, so that I can find funnier things to do then
> make you folks happy, since that's apparently not possible.
I absolutely agree with your criticism. We should do better, and I hope
that in future we will.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rregardless' would mean 'not regardless'. =)
The OED disagrees.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Sep 15, 2010 at 03:04:31PM +0100, Adam Williamson wrote:
> On Wed, 2010-09-15 at 14:57 +0100, Matthew Garrett wrote:
> > On Wed, Sep 15, 2010 at 12:48:26PM +0100, Adam Williamson wrote:
> > > 'regardless'. 'irregardless' would mean 'not regardles
lize it's
> a failure?
"Some packages were pushed to stable before they should have been,
therefore we need to make it easier to push packages to stable"?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Oct 02, 2010 at 12:45:14AM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > "Some packages were pushed to stable before they should have been,
> > therefore we need to make it easier to push packages to stable"?
>
> Yes! Sure, this sounds paradox
o want the
> latest firefox, they just download it and install it. No bullshit
> required.
Software distribution mechanisms are an entirely separate issue from a
distribution's (effectively required) update policy.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
but still have the
> internal system's display turned on?
No, but there is a use case where you'd want to have an external monitor
connected and the system report that the lid is closed, but still have
the internal system's display turned on. Hardware lies.
--
Matthew Garrett | m
.
>
> *shrug* those are separate bugs we can fix once we make the actual
> behaviour correct.
Bugs where we turn off people's displays when they're trying to use them
are things that we should address at the start of the development
process, not the end.
--
Matthew Garrett
On Tue, Oct 05, 2010 at 11:16:44AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote:
> > No, but there is a use case where you'd want to have an external monitor
> > connected and the system report that the lid is closed, but still ha
> are we suspending people's systems at random, if those systems have
> lying lid switches?
Because we only do that on lid state transitions.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
can't always be there
to shield userspace from reality.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Oct 05, 2010 at 02:27:27PM -0400, Nathaniel McCallum wrote:
> On 10/05/2010 02:25 PM, Matthew Garrett wrote:
> > The range of ways that lid switches can be broken is large. One machine
> > I've seen tries to read from a GPIO that's off by 16, because Intel
; the problem case is booting with the lid closed and an external monitor
> > connected.
>
> The BIOS generally manages to get that one correct, can we not query
> and keep the current state on boot?
It really doesn't.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing
On Tue, Oct 05, 2010 at 07:53:25PM +0100, Peter Robinson wrote:
> On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett wrote:
> >> The BIOS generally manages to get that one correct, can we not query
> >> and keep the current state on boot?
> >
> > It really doesn
On Wed, Oct 06, 2010 at 02:46:28PM +0200, Harald Hoyer wrote:
> But I cannot list all the RHEL6 bugs.
Why not? Strip partner names if necessary, but please make it possible
for people to decide whether a given update is a benefit to them.
--
Matthew Garrett | mj...@srcf.ucam.org
--
de
uch better way to handle this.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Oct 11, 2010 at 05:53:20PM +0200, Michał Piotrowski wrote:
> Does it support text based minimal install?
debian-installer? Yes.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
provide a software update without
any risk of breaking something that a user currently depends on is
either naive or lying.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Oct 12, 2010 at 12:12:35AM +0200, Emmanuel Seyman wrote:
> * Matthew Garrett [11/10/2010 19:57] :
> >
> > debian-installer? Yes.
>
> Shipping 2 different installers is a recipe for disaster from a user and
> QA perspective.Choose one between Ubiquity, Debia
areas, not all of them make
> packages or write code.
I should point out that my degrees are in biology and biology, and the
one that I haven't quite got yet is in biology.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ly* want to head this way, ignoring bugs resulting from
> having /usr on a different partition such as
> http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
--
Matthew Garrett | mj...@srcf.ucam.
t think we gain anything from following the FHS on this point
other than the ability to have /usr as a separate partition, and think
that's a pretty circular argument.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it as a separate
partition. So far nobody's come up with a terribly plausible reason for
why /usr should be separate.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
that benefits from being
encrypted? Logfiles, some stuff in /etc?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote:
> On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote:
>
> > > /usr is frequently given different mount options (like noatime, for
> > > example) or mounted readonly to prevent unnecessary writes to the
>
On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote:
> On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote:
> > On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
> >
> > > another benefit (not yet mentioned) is for filesystem encryption. I have
On Tue, Oct 19, 2010 at 11:15:02AM -0400, seth vidal wrote:
> On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote:
> > It doesn't. You can make it a read-only bind mount.
>
> If the files are still read-write at another location then something
> iterating over disks/l
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
> What I am concerned about is that the volume is mounted for _every_ user
> on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it
won't be.
--
Matthew Garrett | mj...@srcf.ucam.or
'how do I get there from here'?
>It would have to be on the video interface/card(s) right?
Right. Your GPU will typically have a per-output i2c bus, and EDID is in
an eeprom stored at a well-defined address on that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
dev
nel support, but otherwise dig through the i2c
code in the X server.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
7;s
nobody currently working on making those. We didn't think it was vital
that that be implemenetd before changing the default filesystem, but if
the work does land before release then so much the better.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedorap
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
* mmaslano (13)
* abadger1999 (9)
* adamw (4)
* Slower (3)
* rbergeron (3)
* dvlasenk (3)
* gholms (1)
* sgallagh (0)
* cwickert (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedorapr
The upstream website says that right now it's only tested and working
with the binary nvidia drivers. Does this actually work with xrandr?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
sy to parse (grep /proc/cmdline) ..
> >
>
> Any comments about this way of doing it?
I don't think introducing two separate codepaths is helpful here. One's
inevitably going to end up less well tested.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedo
mple.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=713609
It's not reasonable 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
o program
link training, fail 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.uca
ers so I agree they shouldn't be entirely
ignored, but they're really a vere low priority.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
there should have been 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 Gar
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.
> >
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 wa
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.
>
&
eep in which would 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.
--
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 "
d makes it clear 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 t
ersion of any libraries 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
against 1.0.1 won't run on 1.0.0 - 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
he SONAME?
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 en
quires inspection before
> attempting a new restart. Having to battle with socket activation while
> in a critical situation is not a good idea.
You'd have the same problem with any init system that supports automatic
service restarting. You can easily disable the
more specialised input
device. It's a hard problem that only impacts a pretty tiny set of
people, so it's prioritised somewhere 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
> > a
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 wrote:
> >
> > Or just add floppy-support and analog-joystick-support packages that
> > include appropriate modprobe.conf fragments, and
n and it doesn't seem like it uses those 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.
--
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&#
"/lib/udev/load-modules.sh analog"
> (They have since 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.
--
tick itself. In theory we could have the driver probe for a
connected device and request_module("analog") if it finds something, but
(a) that'd only work at boot, and (b) it'd 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
t the principle that Fedora should Just 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 mai
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/mail
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
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
> gr
l grub1 guests, only on RHEL 5 era
> grub1).
You're asking for the impossible. 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 b
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
> >
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
> > unmaint
thing happens,
but if not phonon-backend-gstreamer would be used to satisfy 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
think disjunctive dependencies (default | virtual), 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 de
the stage 1.5/stage 2 along
with the mbr, I don't see where compatibility issues come into it. If
you're using the code as you're meant to use the code then you'll always
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
> one when the dependency 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
gs that are manifestly true as "not true". And while it is the case
that grub *is* binary compatible between every version 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 ins
ate these changes to f16 and where caught by the delay 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
ng at the
> time 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
ve done is not upload a package that breaks
binary compatibility 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
On Wed, Sep 21, 2011 at 06:30:58PM +0100, Mark McLoughlin wrote:
> On Mon, 2011-09-19 at 20:11 +0100, Matthew Garrett wrote:
> > The grub package (as provided in Fedora) is not designed for that. This
> > would be a much easier discussion to have if you stopped describing
>
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 tho
e filesystems that will work with
arbitrary kernels, so it's possible to use it in appropriate ways. grub
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
1 - 100 of 732 matches
Mail list logo
