Re: burning an iso with gnome defaults -> confusing
On Thu, Jan 14, 2010 at 01:46:52PM +0100, Rudolf Kastl wrote: > thats exactly what i am "complaining" about. it states that burning > failed. id expect it to tell me that polling failed. thats not really > "randomly" but a common way to tune systems for maximized battery > lifetime. powertop e.g. recommends it, i guess that makes it less > random. i do understand though that not every single possible setting > can be tested before release, thats basically why i wrote that email. The power savings are minimal. While it's certainly a bug in Brasero 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
Re: Board efforts: scope, concept, and permission?
On Tue, Feb 02, 2010 at 01:05:22PM -0500, Toshio Kuratomi wrote: > I think that the Fedora Project's target audience needs to be people who > want to work on open source operating systems. If you want to market the > Fedora Project, that's the audience that needs to be addressed. I don't think this works. Treating Fedora in this way effectively means that the Fedora project exists in order to facilitate derivatives. This is clearly workable (see the relationship between Debian and Ubuntu, for instance), but you then go on to say: > If you want to market a physical product, like the Fedora Desktop Spin, then > that should be a decision made below the Board level. Making a decision > about the target audience of the various distributions that we have limits > the choices of the people who want to work on open source operating systems. > Making a target audience decision at the SIG level widens the choices as > marketing/artistic/documentation/etc people can choose which audiences they > want to address via which medium. And this doesn't work. Spins don't have the freedom to customise packages in the way that full-scale 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
Re: Board efforts: scope, concept, and permission?
On Tue, Feb 02, 2010 at 01:15:29PM -0600, Adam Miller wrote:
> Your example doesn't work, Xubuntu is still bound to the package set
> in the Ubuntu repositories in the same sense that the Xfce Spin is
> bound to the package set in the Fedora repositories. The difference is
> that we understand that the Xfce Spin isn't a fork and shouldn't be
> presented as a completely separate project. The "silos of community"
> that have spawned out of the "Lets make a ${foo}buntu for every
> possible value of $foo" in my opinion has divided the Ubuntu project
> from a contributor stand point.
And Xubuntu and Kubuntu are both of woeful quality because the entire
focus of the core Ubuntu developer base is on Ubuntu, with no concern
about the effects of that on derivatives. Ubuntu is better than Debian
because they were able to focus their 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
Re: Board efforts: scope, concept, and permission?
On Tue, Feb 02, 2010 at 02:22:37PM -0600, Adam Miller wrote: > I think the responsibility of these things should be placed upon the > SIG members who perform the functions from within these different > groups. Why not have a QA person from each SIG work together with the > larger 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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Board efforts: scope, concept, and permission?
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 think there's any doubt at all. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Board efforts: scope, concept, and permission?
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? > > > That's not something I think would be in the scope of a SIG, nor do I > think something like that would make it past Spin review. This would > also take the current SIG/Spin outside the scope of being part of the > Fedora Project as it is no longer using Fedora packages, this (in my > opinion at least) would be a situation where a fork would be needed. But beyond that, it's a matter of degree rather than principle. If we refuse to allow conflicting kernels to be included in the distribution, we're preventing some people from producing the spins that they want to work on. By only supporting a single kernel, we're implicitly stating that the focus of Fedora is limited to the people catered for by that kernel. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
On Fri, Aug 13, 2010 at 04:51:40PM +0200, Kevin Kofler wrote: > * This policy of sticking religiously to upstream means we are not shipping > KDE integration for Firefox, despite patches from openSUSE existing. This > makes Firefox suck under KDE. Our Firefox maintainers refuse to do 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 07:16:36AM +0200, Kevin Kofler wrote: > Basically, we're missing out on an important new feature and shipping less > featureful live images than we could for purely political reasons. :-( The reasons are purely practical. If upstream development is targeting upstream kernels then we're either stuck with whatever version of the patchset happened to apply to the kernel version that we're shipping or we have to backport the upstream code. The former means that someone has to spend time backporting upstream fixes, the latter means that someone has to spend time backporting the entire code. Couple that with Squashfs's traditionally pretty dreadful userspace compatibility and you've got a large quantity of work that would be the responsibility of the kernel team. If there's someone with extensive experience in maintaining 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 05:51:57PM +0200, Kevin Kofler wrote: > Chris Adams wrote: > > Again, proof? They have enough patches to sort through every release as > > it is, and they don't want to add more. > > This doesn't strike me as a strong enough TECHNICAL reason to reject a > feature which would make all our live images better. Both the GNOME and the > KDE live image had to remove useful packages due to size constraints, > improving the compression would allow us to ship more software while still > keeping the ISOs CD-sized. Then those 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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
On Sat, Aug 14, 2010 at 08:25:46PM -0700, Matt McCutchen wrote: > I am aware of that. But FESCo has the authority to override the > maintainer, and in their recent discussion of the SELinux patch, they > decided not to move forward on the basis of the trademarks: > > https://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html#l-66 > > Maybe the maintenance burden alone would also be enough to block further > consideration of the patch, but there is no way to tell that from their > discussion. We have the authority to do that, and the decision you're referring to effectively *did* override the maintainer by saying that the selinux policy change should be reverted. If a package is generally well-maintained and then broken by a change introduced by another maintainer, there has to be a very strong argument to do 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
Re: Why does X run as root?
On Thu, Aug 19, 2010 at 12:28:23PM -0400, Chris Ball wrote: > I think "run X as user Xorg if you're on KMS" would be a fine > F15Feature to aim for. Ubuntu's been working on it too: Of course, doing so just turns it from "Running code as X gives you root" 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() support. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote: > Michael Cronenworth wrote: > > Kevin, if you took off your FSF blindfold you would see that it's better > > for web sites to use JavaScript. If they complied to /your/ wishes we > > would have a thousand proprietary protocols, probably all /closed/ > > source, to communicate in between /closed/ source applications. Most > > likely Microsoft or another Closed Source vendor would create a protocol > > standard that applications would adopt, and you yourself would probably > > have to write to! In this situation we have to choose the lesser 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...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Mon, Aug 23, 2010 at 03:15:11PM -0400, Jon Masters wrote: > What's the benefit of having no default MTA at all? Is it that Desktop > users don't care about MTAs being installed? what about those of us who > care more about server installations than Desktop? Given the degree to which sysadmins are religious about MTA choice, I'd suspect that a large proportion of people who run an MTA on Fedora are probably already swapping it out with their own preference. I don't think it's realistic to expect us to provide a product that requires no further configuration 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
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 08:56:21AM -0500, Chris Adams wrote:
> They can't be configured that way; they don't implement SMTP. It is a
> de-facto standard for Unix programs to send mail by piping the message
> to either /bin/mail or /usr/{sbin,lib}/sendmail. That has the advantage
> of queueing for later delivery (what if I'm off-line when mdmonitor
> detects a failure?) and such.
The problem with delivering this to a user's mailbox via an MTA is that
in the typical case it doesn't result in the user noticing anything
until they've logged in as root and find out that the "you have new
mail" message actually means "Your RAID is fucked" and not just "Here's
some random syslog spew that something you installed and forgot about
keeps generating". If the question is "How do I ensure that important
system messages get delivered to someone who can do something about them
in a timely manner", a local MTA isn't a great answer.
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, and that's something that you'll probably configure when
setting up the machine in the first place. But we're talking about the
default install case, and right now the situation is that anything that
pipes directly to sendmail is almost certainly never being read by the
user. Having an MTA installed doesn't solve the problem that we want to
solve, and so dropping an MTA from the default install means a reduction
in the quantity of privileged code running on the system without any
significant reduction in functionality.
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 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
Re: drop default MTA for Fedora 15
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 default to popping > > up some sort of desktop notification. > > Already works that way. Sendmail/logwatch deliver e-mail and DeviceKit > displays desktop notifications (without requiring an MTA). That's limited to disk and power notifications, isn't it? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
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, and that's something that you'll probably configure when > > This isn't server-only -- it's also the case in an enterprise desktop > environment. Sorry, yeah - wherever I say "Server" read it as "Machine with a remote sysadmin". > > 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 default to popping > > up some sort of desktop notification. > > +1. C'mon, prolific desktop code guys. :) I'll take a look at what would be involved. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 11:52:45AM -0700, Adam Williamson wrote: > FWIW, I'm with Jon and Adam on this one. I just don't see how not having > an MTA by default is a win, except in disk space terms, and it takes up > a tiny amount of disk space (especially if we pick a lighter-weight one > than sendmail to be the default). I think it makes sense to keep one, > for all the good reasons they cited. Shipping an MTA by default just gives developers the expectation that if they pass something to sendmail then it'll be read by a human. Since that's plainly 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
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 08:27:04PM +0100, Adam Huffman wrote: > Not really related to the original discussion, but perhaps firstboot > could be amended to add an alias when the first user is created such > that they receive root's mail? At the point where you're writing 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
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 05:43:49PM -0400, seth vidal wrote: > that seems like a bit of odd logic. The logs are emitted to syslog with > the same thought in mind - that someone will read them - but that is > also not necessarily true. But I would not want to see us discarding > syslog, either. We have a range of utilities that perform useful syslog parsing. The fact that most of them then seem to pass that output to sendmail leaves me a little less convinced that anyone pays the slightest bit of attention to them. More realistically, we install syslog because it gives 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
Re: systemd or why will user fall away from fedora?
On Wed, Aug 25, 2010 at 09:31:30AM -0400, Jon Masters wrote: > [...@constitution ~]$ uptime > 09:28:22 up 24 days, 16:32, 9 users, load average: 1.17, 0.50, 0.37 So you're running an insecure kernel? Our security churn is bad enough right now that rebooting is something people do fairly regularly. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Thu, Aug 26, 2010 at 09:20:23PM +0200, Björn Persson wrote: > Michael Cronenworth wrote: > > Kevin Kofler wrote: > > > 3. What if you can't bring up X in the first place? > > > > That's an X bug. File a bug. > > I wonder how usable Bugzilla is in 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
Re: Orphaned package: system-config-display
On Thu, Aug 26, 2010 at 03:59:06PM -0400, Arthur Pemberton wrote: > On Thu, Aug 26, 2010 at 3:49 PM, Adam Jackson wrote: > > On Thu, 2010-08-26 at 19:59 +0200, Kevin Kofler wrote: > >> 1. Not everyone uses GNOME. > > > > Demonstrably true, but I don't see how 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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
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 matter of degree. This is all just software, right? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 01:05:34AM +0200, Lennart Poettering wrote: > So, we closed all blocker bugs, we worked through the vast majority of > other bugs. I dealt with almost all issues raised in Bill's list, only > few small issues left. While there are some bugs open, we did our > homework. I was kept in the impression during the last week that these > are the criteria to get systemd into F14. But what happens? Out of > nowhere completely new criteria are created, and used to bring this > project down. The criteria primarily flowed from Notting's discussion of systemd acceptance criteria. Was that well communicated beforehand? No. Did all of those criteria get translated into appropriate bugzilla entries? No. Should we have handled this case better? Absolutely yes. With hindsight it was entirely inappropriate of us to make this decision without attempting to involve you in the discussion. I'm genuinely sorry about that. But since this is the situation that we're in now, I think what we're left with is the opportunity to identify what went wrong with our process and how to avoid this kind of thing in future. Systemd was a relatively unusual feature, in that it's core functionality that impacts every spin, it exposes aspects of its functionality in multiple areas and it didn't exist during our previous release cycle. It's not obvious in advance what criteria we should be using for determining whether this kind of feature is acceptable or not. The right time for doing so would probably have been at the initial feature acceptance stage, and in future I'd like to suggest that for features of a similar scale to systemd we ensure that that's done. It makes the feature acceptance process significantly more difficult and longer, but it's time that will almost certainly otherwise be spent in mailing list discussion of the same thing. Having it presented in a structured manner beforehand is proably a net reduction in difficulty. As an aside, it's also obvious that the degree of scruitiny placed on systemd is grossly disproportionate to features in previous releases. I can see why this is frustrating, but I think it's a necessary part of the development of the distribution. NetworkManager was a disruptive piece of core infrastructure that didn't initially provide feature parity with the nfrastructure it replaced, but NetworkManager was necessary to make Fedora a usable desktop operating system in a large number of use cases. In contrast, we're now at the point where we *have* most of the infrastructure to provide a usable desktop operating system. I think it's entirely justified that our tolerance for churn has diminished, and I think being a little more conservative with new features is entirely in line with modifying our udpate policy to ensure that users have a more consistent experience. > This is a really unfriendly move: I cannot win a game where the moment the > game nears it ends completely new rules are created. Quite frankly, this > is a recipe to piss people off, not to make people love developing for > Fedora. Yes, I am very disappointed, Fedora. > > It's also nice to not even bother to ping me for the FESCO > discussion. This all reads like a page from the book "How to piss people > off and scare them away in 7 days". You make up new rules, and then > don't bother to invite the folks mostky affected when you apply them. > > Oh, and next time, 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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 12:48:26PM +0100, Adam Williamson wrote: > On Tue, 2010-09-14 at 20:48 -0400, Máirín Duffy wrote: > > > Is anyone else feeling a little uncomfortable about the voting process, > > irregardless of its conclusion? > > 'regardless'. 'irregardless' 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
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
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 regardless'. =) > > > > The OED disagrees. > > Not really. It lists 'irregardless' as 'colloquial', IIRC (I don't have > my login handy right now, my library card is in Canada...), which is the > OED equivalent of a ten-poot barge pole. :) You can argue over whether it's accepted as "correct" English, but it has a well-defined meaning even if that meaning is contrary to what normal word construction rules would lead you to accept. In any case, quibbling about language usage generally serves to belittle the person you're criticising - it doesn't encourage an attitude of mutual respect and does nothing to foster an atmosphere in which we can have a civilised and productive discussion. Let's be more excellent and less prescriptive? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
On Fri, Oct 01, 2010 at 12:36:13PM +0200, Kevin Kofler wrote: > I CANNOT push the firstboot update which UNBREAKS those 2 spins because of > the update policy. So instead of preventing breakage, the policy CAUSES > breakage! How can it fail more spectacularly for you to finally realize 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
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
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 paradoxical, but my premise is that NO MATTER how > strict you make the requirement for pushes to stable, there will ALWAYS be > the possibility that "sh*t happens" and thus a need to be able to rush out > fixes to stable as quickly as possible. And my premise is that we should be making harder for shit to happen, and the cases where it *does* should be examined carefully to determine the best way forwards. "Force this untested package into stable" isn't the best way to do things. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, Oct 02, 2010 at 08:56:21PM -0400, Brandon Lozza wrote: > I'm not a developer at all. I'm a hardened power user and I got sick > and tired of not having the latest version of a particular application > and that led me to Fedora Linux. I'm a quick learner and these > disruptive changes often work out increasing my productivity. I > understand this profile doesn't fit everyone but Fedora will end up > losing the more advanced end users in its effort to grab more of the > less advanced end users who are fearful of change and/or gave up their > pursuit of knowledge. It turns out to be remarkably difficult to develop software for Fedora if a moderate part of the week ends up being spent wondering why something that previously worked no longer works. This isn't about "less advanced end users". It's about providing stability in order to provide an operating system that people can actually use without. > Fedora is just going to end up having a million repos for all the > software that will not be updated for six months. And that makes us > look silly. Windows doesn't have repositories for users who 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
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote: > Maybe just 'lid closed and external monitor connected' would be close > enough? Is there a use case where you'd want to have an external monitor > connected and the internal system's lid closed, 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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote: > On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote: > > I think the fun will come from systems that don't properly report their lid > > status. I think this is one of the complaints from the X developers. > > *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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
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 have > > the internal system's display turned on. Hardware lies. > > that is a hardware/kernel/acpi bug. The appropriate way to fix it, IMHO, > is to have the sensor report the correct information if it's at all > possible to fix it in the kernel/acpi layer, or if not, blacklist that > specific system so that its lid sensor is completely ignored. I wholeheartedly agree, providing that we can obtain a list of every piece of hardware that has this issue, along with a list of every piece of hardware that will have it in future. If that's not available then userspace is just going to have to deal. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: > don't we already have default behaviours based on the lid switch, > anyway? So why don't we have this problem with those? IIRC, we default > to suspending the system when the lid is closed on battery power - so > 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
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote: > Agreed, the hardware may lie, but the kernel is the arbiter of truth, at > least in this case. 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's GPIO/GPE numbering is complicated. Another generates an event on lid close and generates a different event on lid open, but there's no handler for the open event and so the state variable never gets updated. The world is full of bad hardware and the kernel 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
Re: Making Fedora work with laptops on docking station with external monitor
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's > > GPIO/GPE numbering is complicated. Another generates an event on lid > > close and generates a different event on lid open, but there's no > > handler for the open event and so the state variable never gets updated. > > The world is full of bad hardware and the kernel can't always be there > > to shield userspace from reality. > > Of course, but where possible it should sanitize. Userspace is like a > teenager, you expose them to just enough reality to know what's out > there, but in general they have no idea just how scary it really is. :) And it's not possible to sanitise in 100% of cases here, so userspace has to cope with the breakage. And if userspace has to cope, there's no point in sanitising any of it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote: > On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson wrote: > > So we could at least cover the case where you plug in an external > > monitor, then close the lid? That would be better than nothing. I assume > > 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 list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
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't. > > Seems to work just fine from a user perspective. Not that I ever use > it like that as I use my laptop as a second screen but of an office of > 100% laptops I would think about 50% of the 100 or so people on my > floor use it as such. There's a *lot* of machines that consistently report an incorrect state. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 03:21:40PM +0100, Richard W.M. Jones wrote: > Proving what? You can just imagine what a rebranded Ubuntu installer > that installed Fedora would look like. My point anyway is that we > could look at Ubuntu for ideas, because the first point of contact > with users is now very smooth and (maybe) first impressions matter. Maybe the virt-manager developers could spend some more time looking at vmware? This isn't a good way to have a worthwhile discussion. A description of the factors that you feel make Ubiquity better than Anaconda would be a much 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
Re: Ubuntu 10.10's installer looks rather nice
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
Re: Git commit in all available branches
On Tue, Oct 12, 2010 at 09:32:15AM +1000, Jeffrey Fearn wrote: > What do you mean "leave it alone"? The people using it WANT the changes. > Why are you telling them how they can use their system? Because by pushing updates you're also potentially making it impossible for people who don't want new bugs to use Fedora. The board have decided that that's a class of user that we want to support. > They want the changes, it's trivial for me to give them the changes, why > wouldn't I give them the changes? Because anyone who says that they can 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
Re: Ubuntu 10.10's installer looks rather nice
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, Debian-installer and Anaconda. Ubiquity is a graphical interface built on top of the debian-installer framework. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Thu, Oct 14, 2010 at 10:51:08AM -0400, Brandon Lozza wrote: > It doesn't help when a majority of voting FESCo members are biased > Firefox users who seem to hate the idea of Iceweasel (based on what I > gather from their meeting notes). There seem to be some preconceptions > about what happens when you remove the branding. No conclusive data > can be provided to indicate how much users Firefox brings the distro. Actually, I generally use epiphany. > I also don't appreciate the comment at the meeting about "non > contributing" members on the mailing list complaining about this > issue. It's an argument often used to ignore people with valid > arguments who also don't happen to have a computer science degree. > Some of us advocate Fedora and that in itself is a contribution. > Fedora consists of volunteers in many 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
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: > This despite the FHS says (right at the top of Chapter 3, the Root > Filesystem): > >/usr, /opt, and /var are designed such that they may be located on other >partitions or filesystems. > > Do we *really* 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.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 09:24:10AM -0500, Chris Adams wrote: > A smaller / that is written to less often is less susceptible to errors. > If you don't allocate enough space for / up front, you can move /usr and > /opt to separate filesystems later. /opt can be completely > unpredictable in space usage, due to vendor RPMs dumping stuff in /opt > (see Dell's OMSA, that puts everything, including logs, under /opt). So, LVM? > I personally don't use a separate /usr on desktops, only on servers. On > my servers, /usr is mounted read-only, as an extra protection against > accidental (or even intentional) screw-ups. It also means that I don't > waste I/O cycles on updating atimes on often-used binaries and libraries > (which of course could also be done with noatime). mount --bind /usr /usr mount -o ro,remount /usr > I've seen some boot-from-flash setups with /usr on a hard drive. The rational thing there is for the flash to be /boot, not /. > Basically, if Fedora is going to follow the FHS at all, bugs like 626007 > should be fixed, not ignored because somebody doesn't like a separate > /usr. I don'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
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 10:38:13AM -0400, seth vidal wrote: > /opt is a location filled with vendor detritus on a lot of systems - > sometimes managed by rpms, sometimes not. It's not uncommon to have /opt > automounted via nfs. Additionally, on some workstastion systems /opt is > a separate drive managed by the 'local admin' of the machine and filled > with whatever 3rd party software they need for their instance. /opt being network shared seems like a reasonable thing to support. > /usr is frequently given different mount options (like noatime, for > example) or mounted readonly to prevent unnecessary writes to the > system. That doesn't require it to be a separate partition. > Additionally, since our software in fedora has a trickle down impact on > users in rhel-land I think you'll find that this will have to be done, > eventually for them. "We have to support it because users want it" is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting 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
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: > another benefit (not yet mentioned) is for filesystem encryption. I have / > and > /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / 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
Re: rawhide report: 20101019 changes
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 > > > system. > > > > That doesn't require it to be a separate partition. > > Mounting the location meaningfully as a readonly does. If you're doing > it for security reasons. It doesn't. You can make it a read-only bind mount. > > "We have to support it because users want it" is a poor argument. We > > have to understand why people want it to be a separate partition and > > then decide whether the simplest way (in terms of overall engineering > > effort) to support those desires is by supporting it as a separate > > partition. So far nobody's come up with a terribly plausible reason for > > why /usr should be separate. > > I'm confused here - why is it we have to come up with a plausible > reason? Why is the burden of proof on KEEPING /usr as a separatable > partition? Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. > If I said tomorrow "yum will not support feature foo or bar" that have > been in rpm and yum since the dawn of time I'd have to defend my > rationale for that change. If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that. > So it seems like you need to explain why you think /usr should NOT be on > a separate partition. Because it adds additional complexity for no obvious gain. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
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 > > > / and > > > /home encrypted and /usr not encrypted (for better performance of my > > > laptop) > > > > I'm kind of curious about this. What's on / that benefits from being > > encrypted? Logfiles, some stuff in /etc? > > Yes to both of those. Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
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/locations can still find it. > > That's what I meant by meaningfully. So do this at the top of init. It's still better than having /usr be entirely separate. > > Because it takes more engineering effort to keep it as a separate > > partition, as evidenced by the number of bugs that keep appearing that > > are only triggered by this niche usecase. > > > Hmm, So when this was broken a lot of bugs were triggered? > > Sure seems like if a lot of bugs are being triggered then it is NOT a > niche usecase. > > You can't have it both ways. Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work. > > If yum removed features that provided functionality that could be > > achieved via other means, and in return various other features worked > > better, I'd be fine with that. > > It's not clear to me that other features work better in the case you're > describing and it will mean retooling for what sounds like a good number > of users. Every Fedora update requires significant retooling. The fact that these bugs exist indicates that there would be advantages to not supporting this, providing that in return we can satisfy all the existing user requirements. "/usr is a separate partition" is *not* a meaningful user requirement, any more than "Fedora release names must start with a consonant". If we can provide better and more generalisable solutions for their requirements then that's a win for everyone. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
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.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Wed, Oct 27, 2010 at 01:37:41PM -0400, Fulko Hew wrote: >But thats (unfortunately) exactly what I have to do because the device >isn't running Linux. :-( Yeah, this probably isn't the right place to be asking, then. >I knew it was I2C, but on what bus and '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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Wed, Oct 27, 2010 at 02:18:16PM -0400, Fulko Hew wrote: >I thought I'd try to ask, because if some Linux developer could tell me >how/where >some app like xrandr gets the data, then I could figure out how to >accomplish >it on my equivalent system. xrandr gets it from the X server, and on modern systems the X server gets it from sysfs. On pre-KMS hardware it's handled by the device-specific code in the X server knowing how to bang the gpu registers to do i2c. If you've got control of your kernel then the sane thing to do is to add kernel 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
Re: BTRFS: The Good, The Bad and The Ugly
On Thu, Jul 14, 2011 at 10:22:17AM +0100, Richard W.M. Jones wrote: > Is this how F16 will be set up? The Feature page[1] suggests that LVM > will be turned off by default, in which case it should look more like: That would involve changes to Anaconda, and as far as I know there'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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Agenda for today's FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #608 F16Feature: Trusted Boot - .fesco 608 #topic #563 suggested policy: all daemons must set RELRO and PIE flags .fesco 563 #topic #615 Strategy for services that do not have systemd native unit files .fesco 615 = New business = #topic #647 Consider 14 features in FeatureReadyForFesco despite the Submission Date passing. .fesco 647 #topic #634 F16Feature: EclipseIndigo .fesco 634 #topic #635 F16Feature: 1000 System Accounts .fesco 635 #topic #636 F16Feature: Chrony default NTP client - .fesco 636 #topic #637 F16Feature: Condor Cloud - .fesco 637 #topic #638 F16Feature: Unified Problem Reporting UI .fesco 638 #topic #639 F16Feature: GCC Python Plugins .fesco 639 #topic #640 F16Feature: Static Analysis of CPython Extensions .fesco 640 #topic #641 F16Feature: GNOME Input Integration .fesco 641 #topic #642 F16Feature: Sugar 0.94 .fesco 642 #topic #644 F16Feature: Spice 0.10 .fesco 644 #topic #645 F16Feature: New mkdumprd for for kdump .fesco 645 #topic #646 F16 Feature: Use Ext4 driver for Ext3 and Ext2 filesystems .fesco 646 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Agenda for today's FESCo meeting
=== #fedora-meeting: FESCO (2011-07-18) === Meeting started by mjg59 at 17:01:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-07-18/fesco.2011-07-18-17.01.log.html . Meeting summary --- * init process (mjg59, 17:02:52) * #608 F16Feature: Trusted Boot (mjg59, 17:03:53) * AGREED: , Trusted boot is approved as an optional F16 feature (mjg59, 17:13:20) * #563 suggested policy: all daemons must set RELRO and PIE flags (mjg59, 17:13:48) * AGREED: Work on tuning the criteria and revisit next week (mjg59, 17:25:49) * #615 Strategy for services that do not have systemd native unit files (mjg59, 17:25:57) * LINK: https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd (Viking-Ice, 17:28:09) * LINK: http://fpaste.org/ErRL/ (Viking-Ice, 17:28:32) * #647 Consider 14 features in FeatureReadyForFesco despite the Submission Date passing. (mjg59, 17:35:14) * AGREED: Fesco will consider these features (mjg59, 17:36:25) * #634 F16Feature: EclipseIndigo (mjg59, 17:36:35) * AGREED: Eclipse Indigo is approved as an F16 feature (mjg59, 17:37:32) * #635 F16Feature: 1000 System Accounts (mjg59, 17:37:37) * AGREED: 1000 System Accounts is approved as a Fedora feature (mjg59, 17:38:43) * #636 F16Feature: Chrony default NTP client (mjg59, 17:38:47) * AGREED: Chrony approved as the default NTP client (mjg59, 17:39:51) * #637 F16Feature: Condor Cloud (mjg59, 17:40:50) * AGREED: Condor Cloud is approved as an F16 feature (mjg59, 17:42:18) * #638 F16Feature: Unified Problem Reporting UI (mjg59, 17:42:31) * AGREED: Unified Problem Reporting UI is approved as an F16 feature (mjg59, 17:43:54) * #639 F16Feature: GCC Python Plugins (mjg59, 17:44:55) * AGREED: GCC Python Plugins are an approved F16 feature (mjg59, 17:45:58) * #639 F16Feature: GCC Python Plugins (mjg59, 17:46:08) * #640 F16Feature: Static Analysis of CPython Extensions (mjg59, 17:46:37) * AGREED: Static Analysis of CPython Extensions is an approved F16 features (mjg59, 17:47:19) * #641 F16Feature: GNOME Input Integration (mjg59, 17:47:32) * AGREED: Gnome Input Integration is an approved F16 feature (mjg59, 17:50:12) * #642 F16Feature: Sugar 0.94 (mjg59, 17:50:17) * AGREED: Sugar 0.94 is an approved F16 feature (mjg59, 17:51:30) * #644 F16Feature: Spice 0.10 (mjg59, 17:51:34) * AGREED: Spice 0.10 is an approved F16 feature (mjg59, 17:53:08) * #645 F16Feature: New mkdumprd for for kdump (mjg59, 17:53:16) * AGREED: New mkdumprd for kdump is an approved F16 feature (mjg59, 17:56:18) * #646 F16 Feature: Use Ext4 driver for Ext3 and Ext2 filesystems (mjg59, 17:56:24) * AGREED: Use Ext4 driver for Ext3 and Ext2 filesystems is an approved F16 feature (mjg59, 17:57:14) * Next week's chair (mjg59, 17:57:38) * AGREED: notting to chair next week's meeting (mjg59, 17:57:57) * Open Floor (mjg59, 18:01:38) * LINK: http://lists.fedoraproject.org/pipermail/devel/2011-July/154345.html , in case anyone didn't see it (adamw, 18:02:31) Meeting ended at 18:05:25 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mjg59 (144) * nirik (59) * pjones (55) * ajax (38) * t8m (32) * notting (29) * zodbot (21) * Viking-Ice (13) * 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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disper review request - On-the-fly display switch utility
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
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 19, 2011 at 01:42:30PM +0300, Pasi Kärkkäinen wrote: > On Thu, Jul 14, 2011 at 10:37:51AM +0300, Pasi Kärkkäinen wrote: > > Would something like "use_acpi_lid_status" kernel cmdline option be too > > ugly? :) > > At least it would be easy 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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110803 changes
On Wed, Aug 03, 2011 at 02:48:24PM +0100, Peter Robinson wrote: > > mesa-7.11-1.fc17 > > > > * Tue Aug 02 2011 Adam Jackson 7.11-1 > > - Mesa 7.11 > > - Redo the driver arch exclusion, yet again. Dear secondary arches: unless > > it's an on-motherboard driver like i915, all PCI drivers are to be built > > for all PCI arches. > > > > > Dear X maintainers, > > We would love to build all PCI drivers for all platforms if the drivers > compiled for all secondary arches :-) See bug 713609 as an example. > > 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 needs to make it build. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel HD 3000 video & blank screen during install of F15
On Wed, Aug 03, 2011 at 10:34:01AM -0400, Ric Wheeler wrote: > Thanks, I will work through collecting that information and post it for us. > > If you do need access to this particular chipset, let me know :) It's typically not the chipset that's the problem. The move from LVDS to embedded DisplayPort means that it's now the driver's job to make sure there's a trained link between the chipset and the panel, and it turns out that panels are often very particular about the setup they want for anything to work. The typical outcome of this is that we try to 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.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel HD 3000 video & blank screen during install of F15
On Wed, Aug 03, 2011 at 06:01:44PM -0400, Felix Miata wrote: > On 2011/08/03 14:04 (GMT-0700) Adam Williamson composed: > > >> > >> http://fedoraproject.org/wiki/How_to_debug_Xorg_problems#KMS-related_issues > > > I know you're busy, but do feel free to update that page if you get a > > minute - I haven't touched it for a bit and it probably needs a spring > > clean to really de-emphasize the UMS stuff. AIUI, only radeon can > > possibly work UMS now, and only with a restricted range of hardware. > > MGA, R128 and some other old stuff still quite usable have no KMS support, so > UMS shouldn't be entirely 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...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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 important program that we make security claims about. > It is not on that list. Because it's SUID. > I think 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 Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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 important program that we make security > > > claims about. It is not on that list. > > > > Because it's SUID. > > ? Its one in the target group. Yes. The list isn't intended to be exhaustive - it's already been made clear above that SUID applications should be covered. > > > I think 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? > > Taking RHEL6 through common criteria and FIPS-140, filing dozens of security > bugs after studying some problems and sending patches. I am monitoring the > FESCO ticket, but I don't monitor fedora-devel all the time because there are > way too many arguments for my taste. Regardless, should there not have been > some hint about anything on the ticket? I responded to any review request for > the wiki page and such. You can't bring a policy to FESCO, fail to turn up to any of the meetings and then be surprised if the enacted proposal doesn't perfectly match yours. The ticket was flagged "meeting" up until the point where it was closed which means it's under active consideration, and the meeting summaries posted to fedora-devel contained the various proposals and action items that we worked through. > My main concern is that the macro will be misapplied and overall performance > will take a hit. I don't know how a macro can tell the intent of an > application as it links it. There has not been a chmod so that it knows this > is setuid and needs more protection. For example, if coreutils was built with > this (and coreutils seems to be correct as is) because it has setuid > programs, > then would all apps get the PIE/Full RELRO treatment? If so, many of > coreutils > apps are called constantly by shell scripts. If this were used on tcpdump, > would full relro leak to the libpcap? I suppose I could test this as soon as > I > set up a rawhide vm...but this is what concerns me about the approach. The aim was to come up with a policy that is straightforward for maintainers to implement. Making it more complex for small performance benefits (coreutils applications may be called often, but they're also pretty tiny - have you actually measured a significant difference in real world cases?) increases the risk that someone will make a mistake and we'll ship code that's less secure than it was supposed to be. Like anything, it's a tradeoff. If it causes problems then we can tweak the implementation, and if you'd prefer you can think of this as a starting point. Nothing FESCO comes up with is set in stone. We'll be happy to modify the policy in response to technical feedback. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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 it was approved. I then turned my attention to other things > like how to scan a distribution to find packages that need updating. I posted > a > link to my script on the ticket. Just adding a global LDFLAGS accomplishes > most of what is needed. The only issue left is when you have a > daemon/setuid/setgid/setcap or something parsing untrusted media. Those are > all the kind of packages that the maintainer should be skilled enough that > they ought to know how to add flags since they would be attack vectors. Which means I'm very unclear on what you're unhappy about. The implementation Adam provided is what we agreed on in the meetings. > > and then be surprised if the enacted proposal doesn't perfectly > > match yours. The ticket was flagged "meeting" up until the point where > > it was closed which means it's under active consideration, and the > > meeting summaries posted to fedora-devel contained the various proposals > > and action items that we worked through. > > I would rather have seen a macro added to auto tools to detect gcc support > for > this so that upstream developers can more easily add the support natively for > all distributions. We have a huge number of packages that aren't built with autotools. > > The aim was to come up with a policy that is straightforward for > > maintainers to implement. Making it more complex for small performance > > benefits (coreutils applications may be called often, but they're also > > pretty tiny - have you actually measured a significant difference in > > real world cases?) > > The compiler folks objected to enable full relro/pie across the board, so I > assume they know there is a penalty and we should heed their advice. And that's why we're not enabling it across the board. The impact it has on any given package will depend on the size of the binaries and the way they're called. If imposing it upon coreutils results in a real increase in execution time then coreutils should adopt a different approach to implementing this, but if there are no benchmarks showing that it's a problem then it's really not worth caring about. > > increases the risk that someone will make a mistake > > and we'll ship code that's less secure than it was supposed to be. > > That is why I developed a lot of test scripts...so that we check the > distribution for security issues. All you need to do is get an install > everything setup, and run ./rpm-chksec --all it will grade all the installed > packages to see if the comply (with the exception of the parses untrusted > media use case). Which is fine, and then someone does a build just before release and screws it up. 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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
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 it is to fix. If I have > understood AutoQA right, it gets involved only after I submit a package to > updates-testing. Even better, when possible, is to detect problems during the > build, so that I notice them when I test-build locally and can fix them > before > I even commit the changes to Git. Some checks are already done at build time, > and Steve's points 1, 2 and 4 look like they should be possible to detect at > build time too. Checking at build time is a developer aid, but doesn't prevent mistakes from slipping into the distribution. Having both would certainly be helpful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, Aug 09, 2011 at 06:56:21PM +0200, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: > > the goal being that they see warnings more easily. > > You should make -Werror default instead, by compiling packages without -Werror > various bugs creep 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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
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 believe -Werror is appropriate for .src.rpm as only .arch.rpm is what is > being shipped to the real users. -Werror is only of concern to the package > maintainer who should keep warnings under control. -Werror is probably the > most easy way to keep them non-regressing. Adding an additional warning to gcc that triggers for a specific application doesn't make that application any more broken than it was before the warning was added. If a package fails to build in a mass rebuild because -Werror was enabled then that's additional work for several people to fix something that may not have ever actually been broken. Warnings are appropriate during development. -Werror may even make sense when packagers are performing local builds before upload. I just don't think there's any way that the improvement in quality it'd bring to the distribution outweighs the extra effort involved in maintaining it whenever the toolchain changes. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Wed, Aug 10, 2011 at 02:46:17PM +0100, Richard W.M. Jones wrote: > This clearly needs to be extended to changes in policy. Flagging a > ticket as "meeting" is an obscure bit of wonkishness. A courtesy > email should be sent before the meeting instead. It's helpful to mail feature owners directly because the trac ticket will typically be in the name of the feature wrangler rather than the feature owner. https://fedorahosted.org/fesco/ticket/563 shows active discussion of the fact that we've been talking about this, links to the draft policy documents and 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 the Fedora process. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 04:18:34PM +0200, Miloslav Trmač wrote: > On Fri, Aug 12, 2011 at 4:15 PM, Andreas Schwab wrote: > > Your whole argument is just void. There is not a single difference > > between "external" packages and (sub-)packages. > There is one difference: with subpackages it is trivial to write a > Requires: that 1) is always strict enough and 2) is always satisfied. > For external packages achieving both requires non-trivial human > effort. Not at all. The simplest thing to do is to ensure that any binary depends on at least the version 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
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: > Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that > access the PrivateData. Because the utilities are built from the libfoo > source, they can include the fooprivate.h header file and do this. When > libfoo goes to 1.0.1, upstream changes the definition of PrivateData and > updates the utilities to work with the new datastructure. Since the public > ABI stayed the same, the SONAME doesn't change and external programs > compiled against libfoo-1.0 continue to work but the utilities built as > a subpackage would be broken without stricter versioning. 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 up with a situation where external binaries built 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
Re: To Require or not to Require?
On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: > Third party code built against -devel and depending only on the SONAME is fine > in this situation as it sticks to the published ABI. In-tree code that plays > with non-ABI symbols will break and so may need a stricter dep. 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 Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
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 up with a situation where external binaries built > > against 1.0.1 won't run on 1.0.0 - the problem isn't limited to > > subpackages. > > > Sure. But in this case, upstream isn't changing the public ABI. > > It's a different level of mistake that's being practiced here. What difference does it make? Even if you stick to the public ABI you can't guarantee that a matching SONAME is sufficient. You need to depend on the package version you build against. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: > On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: > > Why not? > > > > If the service is enabled but the daemon not currently running, is it so > > terrible for a connection test to cause the daemon to start? Remember, > > in systemd logic 'service enabled with socket activation, daemon not > > currently running' is effectively an 'on' state, not an 'off' state. If > > you wanted the database to be 'off' you should have the service > > disabled, and in that case, the ping test wouldn't cause the daemon to > > start. > > It generally is a bad idea to automatically restart a database based on > a random connection. There many reasons why you may have stopped the db > (or it may have stopped itself) and requires 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 service via systemctl. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote: > On Tue, Aug 30, 2011 at 03:33:04 +0200, > Kevin Kofler wrote: > > > > No, it means that (unless this was recently fixed) you have to modprobe it > > manually (e.g. from rc.local) because nothing bothers trying to modprobe it > > for you anymore. IMHO, this is really broken, but the bug reports about it > > were ignored or declared NOTABUG. > > There was significant discussion about this issue on the mailing lists > and Kyle thought he had a good solution to having the floppy drive > recognized when it was there and not adding long delays to the boot up > for people with incorrectly configured (your supposed to disable the floppy > drive in the bios when you don't have one) or broken bios. I am not sure > what happened with the implementation of the solution. 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 that's supposed to return a list of drives usually returns a mixture of falsehoods and untruths. Merely havig a floppy controller is enough to get the floppy driver loaded, which then hangs for ages looking for a drive. The "easiest" solution would be to fix the floppy driver to probe in the background but I suspect most people would prefer to empty biohazard containers full of used needles by hand than touch floppy.c. > > > > Similarily, analog joystick support (yes, those joysticks you plug on the > > MIDI ports of those old sound cards) also has to be modprobed manually. > > I also have a gamepad which is like a joystick and need to do > modprobe analog to get it recognized. There's no way to get any feedback from the gameport driver as to (a) whether there's anything plugged in, or (b) what is plugged in. We could have the gameport driver automatically pull in analog but that'd probably break people doing midi or using some 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
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 that's supposed to return a list of > > drives usually returns a mixture of falsehoods and untruths. Merely > > havig a floppy controller is enough to get the floppy driver loaded, > > which then hangs for ages looking for a drive. > > That seems like a clear opportunity to add a simple "configure legacy > hardware" button to anaconda, that would do the modprobe floppy/gameport > etc. stuff so it is loaded. Perhaps there could be switches: I have > these legacy hardware: > Floppy disk > Analog joystick > whatever Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
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 have documentation that > > instructs the user to install them. > > To make this more precise, woulf the appropriate way to do this would be to > perhaps put floppy.conf or joystick.conf in /etc/modprode.d? > With a post install script to run modprobe manually? That seems like it'd work. > Are pretty much all joysticks handled by analog or is that situation more > complicated? Most are. There are some devices that need their own drivers, and as far as I know there's no defined PNP protocol for joysticks. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote: > On 30/08/11 14:23, Bruno Wolff III wrote: > > >I'll need to test it. Right now I use explicit modprobe commands in > >rc.local, which isn't good for packages. I looked at modprobe.conf > >documentation 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. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
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 that (at least for the one case) this wouldn't just > go in the joystick package? Joystick seems to be part of the default install (it handles USB devices as well as legacy ones), and we probably wouldn't want this by default. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 06:30:30PM +0200, Kevin Kofler wrote:
> An Arch Linux user once pointed out to me that Arch (at the time) probed for
> analog joysticks using this udev rule:
> SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f",
> RUN+="/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.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 07:18:40PM +0200, Lennart Poettering wrote:
> On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kof...@chello.at) wrote:
> > An Arch Linux user once pointed out to me that Arch (at the time) probed
> > for
> > analog joysticks using this udev rule:
> > SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f",
> > RUN+="/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?
>
> If the PNP device with the ID "PNPb02f" is an analog joystick port then
> instead of hacking userspace rules like this the analog.ko kernel module
> should just gain a modinfo alias for it like for example parport_pc has
> for its PNP device ids. See "modinfo parport_pc" as an example.
The id is already present in ns558, which is the driver for the typical
PC game port. However, this is only the driver for the controller, not
for the joystick 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
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 09:13:05PM +0200, Kevin Kofler wrote: > Simo Sorce wrote: > > It seem much more intelligent to add a package owners of floppies can > > install, so that 99.9% of the others do not have to wait forever for no > > reason. > > This goes against 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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 to have multiple bootloaders installed on one machine. Requiring the ability to do so adds a significant amount of extra complexity 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/listinfo/devel
Re: grub / grub2 conflicts
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 to have multiple bootloaders installed on one > > machine. > > There's an interesting verbal trick there. "multiple bootloaders" are > not installed. Multiple versions of the grub RPM package are > installed. Only one bootloader would be installed on the host. grub and grub2 are different packages with approximately no code in common. They're different bootloaders. We don't support having multiple different bootloaders installed. > > Just install the grub package in the guest, and chroot into the guest if > > you need to run grub-install there. > > Running tools from out of the guest is insecure. There are several > ways in which a guest could exploit the host if we did this. See > "Security" here for some issues: > > http://libguestfs.org/guestfs.3.html#running_commands 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 problems come F17. It's likely that grub will no longer exist, but F15 guests will still need it rather than grub2. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 bootloader. So how do you ensure that the version you run is the same version as the package installed in the guest? Having those not match is an invitation for bizarre failure down the line. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote: > For grub1 guests, it has turned out not to matter which specific > version of grub [as long as it was grub1] was used, as apparently > grub-install updates all files needed in /boot/grub as appropriate. > Or at least we haven't come across a guest where this hasn't worked > (yet -- we could be in for a surprise). The most obvious case where it can fail involves grub being effectively unmaintained, and so various vendors have extended it in different ways. You may end up with valid configuration files for one distribution that can't be parsed by the grub for another. The assumption you're making is fragile. It's even worse for grub2, since it has a built-in module loader. Modules built for one version of grub aren't guaranteed (or even really expected) to work when loaded into another. > I'm very interested in how to reinstall bootloaders *without* invoking > guest code. Also in how to not break the bootloader when moving or > aligning the boot partition, which sometimes happens for reasons we > don't understand (but not on all 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 binary interface may have changed between them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 problems come F17. It's likely that > > grub will no longer exist, but F15 guests will still need it rather than > > grub2. > > Ugh. This sound like it will make it pretty difficult to maintain a > system that dual-boots Fedora and RHEL/CentOS/SL (or any other grub 1- > only distro). > > Am I reading this wrong? grub1 can be installed in a partition from the older OS and then chainbooted by grub 2, if that's you're preferred way of doing things. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 extended it in different ways. > > You may end up with valid configuration files for one distribution that > > can't be parsed by the grub for another. The assumption you're making is > > fragile. It's even worse for grub2, since it has a built-in module > > loader. Modules built for one version of grub aren't guaranteed (or even > > really expected) to work when loaded into another. > > No it's not. Grub doesn't install the 1.5 stage or the 2nd stage > loaders, it uses the ones present in the root filesystem defined by the > install command. In this case, that's going to be the modules in the > guest vm filesystem. As such, anything valid in the guest vm's copy of > grub will work in the guest vm even if the grub used to install the > master boot record comes from the host. grub-install *does* install the 1.5 and 2nd stage loaders. Even if it didn't, I'm not convinced it's guaranteed that an arbitrary grub stage 1 can launch an arbitrary grub stage 1.5 since there are assumptions about register and stack state - see start.S. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 02:40:30AM +0200, Kevin Kofler wrote:
> We really need a way to be able to specify an explicit default which is used
> independently of what the user has installed, even if we don't always use it
> (I can see the case of gnome-* vs. kde-*); the version number of the
> Provides would be one solution. ("Shortest name" or "first in the alphabet"
> is just a hack, which forces silly things like using "phonon-bknd-gst", so I
> don't think that's a good way to make the decision, though even that was
> better than what we have now, which is almost unpredictable.)
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
If the virtual dependency is already satisfied then nothing 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
Re: how to have yum prefer one dependency over others
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 does not support this idiom. I know. I'm just pointing out that this is a problem that's been solved in the past. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote: > Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: > > Michael Schroeder wrote: > > > Sounds like you want weak dependencies (i.e. "Suggests" et al). > > > > In this case, I 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 dependency > and a disjunctive dependency? How can you satisfy a soft dependency if > you don't know what virtual dependency it is being used to provide? If we have: Requires: phonon-backend Suggests: phonon-backend-gstreamer What would you expect the outcome to be on a system that has phonon-backend-xine? I'd have thought that phonon-backend-gstreamer would get installed, even if you can later remove it. That's not the desired outcome. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Mon, Sep 19, 2011 at 12:44:58PM -0400, Doug Ledford wrote: > OK, technically it install the 1.5 or the 2.0 if you don't use a 1.5 > (if you install both the 1.5 and 2.0, then it patches the name of the > 2.0 into the 1.5 that it installs and the 1.5 reads the filesystem to > find the 2.0 so that it isn't subject to breaking boot if the 2.0 > moves due to an updated version or some such). However, it installs > them from the files you list to the install command as I listed in my > previous email. So, they are still compatible with the guest vm grub > if you follow a procedure like I listed. I haven't looked to see if > the 512 byte MBR is hard coded in grub or if it grabs it from > /boot/grub and installs what it finds there, so I can't speak to that. Sure. If you're installing the files from the guest then there's no problem. But in that case you only need enough code in the host to be able to write the new images, whereas what Richard's been telling us is that the host-side grub binaries are required. > > Even if it > > didn't, I'm not convinced it's guaranteed that an arbitrary grub > > stage 1 > > can launch an arbitrary grub stage 1.5 since there are assumptions > > about > > register and stack state - see start.S. > > And I'm sure those assumptions haven't changed probably in the last 5 > years or more. But, I can look through the old grub CVS versions if > it would help settle your concerns. Those sorts of hard coded > constants tend not to change much, especially if the coders have any > sort of clue what so ever about compatibility issues. Given that you're always supposed to install 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
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 12:51:29PM -0400, Doug Ledford wrote: > I wouldn't have thought that. I would have thought that if the > Requires was already satisfied by phonon-backend-xine, that processing > would stop there. You have no need for suggests or recommends either > 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
Re: grub / grub2 conflicts
On Mon, Sep 19, 2011 at 02:53:11PM -0400, Doug Ledford wrote: > This is incorrect. The whole reason the stage1.5 portion is an fs > compatible reader is so that you can update the stage2 file and it > will pick the changes up without needing to be reinstalled. This is > also born out by the fact that on package update, there is no %post > action in the spec to reinstall the mbr and stage 1.5 files even > though the stage2 file likely just changed. We never update the stage 2 file without reinstalling the mbr and stage 1.5. The output of rpm -qf grub may be instructive. > > 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. > > Like I said, not true. The grub package is designed to be updateable > without requiring an mbr reinstall. What's more is I had a look at > the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just > like I said, they are indeed binary compatible. So even if the grub > user space application pulls its MBR from a statically linked copy of > the MBR, it will still work with pretty much any stage1.5 or stage2 > you find in a guest. 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 things 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 installed in a guest. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, Sep 20, 2011 at 04:13:27PM +0200, Ralf Corsepius wrote: > On 09/20/2011 04:03 PM, Adam Jackson wrote: > > I'd like to see a rationale for jamming a soname-changing update into > > the OS so close to a release. > Maintainers on vacation, non-trivial changes? > > In my case, a major change was introduced into rawhide many weeks ago, > which had caused breakage in rawhide. One maintainer being involved was > in vacation, another one was non-responsive. > > Ca. 4 weeks later the issues were resolved in rawhide and we started to > propagate 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
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, Sep 20, 2011 at 10:21:52AM -0400, Matthias Clasen wrote: > We've set our freezes as if we expect all major development to be done > at that point, but we've aligned our schedules in a way that guarantees > that (at least for GNOME) major development is still happening 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
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote: > That said, a reasonable QA would cherry-pick such "solution > candidates" from *-testing and integrate them. Simply flooding > maintainers "with complaint mails" about broken deps, maintainers > believe to already have fixed doesn't help anybody. Neither the > testers (who can't test because of these broken deps), nor the > maintainers (who believe to have done everything possible), nor the > users (who will end up with low-quality distros). 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. 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
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
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 simplistic view - It's simply that other processes > (upstream release cycles, upstream release processes, package > maintainer's time slots, etc.) are not in sync with Fedora's cycles > and that Fedora's wanna-be QA's delay slots are severely adding to > the already existing problems. You're not obliged to upload the latest upstream. It's very practical to simply not do so. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 > > things 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 installed in a > > guest. > > If libguestfs had code to detect that the guest version was incompatible > and failed gracefully with a nice explanation for the user, then there's > no problem right? To be reliable you'd need to support disassembling the binaries installed and working out what the arguments are meant to look like. This doesn't seem like a great way to spend time. 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 knowledge. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
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 knowledge. > > Sounds like we need a 'Conflicts: libguestfs' in both grub and grub2 > then? I don't think so. Nothing they do or install conflicts with libguestfs. libguestfs is simply trying to use them inappropriately. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Wed, Sep 21, 2011 at 09:10:06PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 21, 2011 at 03:54:28PM -0400, Peter Jones wrote: > > Yes, but this will hardly help the situation, which right now is that the > > distro pulls in grub 2, because that's what we've collectively chosen to do, > > and libguestfs pulls in grub on the host, even though it isn't really using > > it there. So effectively your solution is to keep the problem we've got > > right now. > > Tools on the host are often useful in guest situations. > > If I created a filesystem using mke2fs: > > lvcreate /dev/vg/foo > mke2fs /dev/vg/foo > > and attached this to a guest, is that an inappropriate use of host > tools for a guest? Yes, if the guest is running a sufficiently old kernel. But mke2fs is designed to allow you to create 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
