Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: > if things are working fine they do not need to be reinvented > and developed forever - the problem i see the last years is > that way to often are wroking things replaced because people > can not life with the fact that things sometimes are finished > and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates. If you leave this as it is, and just use and reboot the system as normal, there is a small but not insignificant chance that you will eventually wind up with a completely broken system, when you happen to reboot just as PK is halfway through updating glibc or something. So no, things are clearly not good 'as they are'. One obvious 'fix' for the above bug was not to automatically install security updates any more, and that's the band-aid we used for F17, but obviously once you come across that issue and start thinking in broader terms about how we _ought_ to handle updates on the desktop, it's reasonable to wind up thinking up the plan encapsulated by this feature. I can't find the bug # for the above bug, unfortunately, but hughsie probably has it handy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 12:47 +0100, Richard W.M. Jones wrote: > On Mon, Jun 18, 2012 at 12:22:16PM +0100, Richard Hughes wrote: > > On 18 June 2012 12:03, Benny Amorsen wrote: > > > Why testing the daemons? Any daemon which cannot be restarted by > > > systemctl restart foo.daemon is broken already. > > > > Try booting a few VMs and then doing "systemctl restart > > libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the > > clients are disconnected and all the VMs are no longer running. > > This is not true for any libvirtd since ca. 2009. In fact it was Well, it was broken for a time during the F17 cycle, which may be where the other Richard got his mistaken impression. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 07:04 AM, Matej Cepl wrote: > On 18/06/12 21:18, Jesse Keating wrote: >> On 06/18/2012 01:43 AM, Reindl Harald wrote: >>> what competition damned? >>> grub is the best example for things which did not reinvented >>> >>> grub1 was easy to understand and configure >> >> And grub1 would get left behind as new filesystems come out and new >> firmwares come out, and potentially new whole architectures come out. > > And what does it have to do with abhorrent configuration files. I am all > for fancy new filesystems, but we do have to have new front-end as well? The problem in cases like this, is that we don't really have a choice. GRUB legacy is unmaintained and increasingly lacking in functionality that is in GRUB2. Since we have made a decision to switch to GRUB2, we have to deal with the configuration format provided by upstream. There are only limited number of components where Fedora or Red Hat has a significant influence and can change this. GRUB2 isn't one of them. So we live with the less than ideal choices at the distribution level. Rahu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 18/06/12 21:18, Jesse Keating wrote: On 06/18/2012 01:43 AM, Reindl Harald wrote: what competition damned? grub is the best example for things which did not reinvented grub1 was easy to understand and configure And grub1 would get left behind as new filesystems come out and new firmwares come out, and potentially new whole architectures come out. And what does it have to do with abhorrent configuration files. I am all for fancy new filesystems, but we do have to have new front-end as well? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 18, 2012, at 4:08 PM, Chris Murphy wrote: > If I don't agree to the license, then I'm not to use the software. The iOS license says if I don't agree to the license, then I'm not to use the *hardware*. Haha. The most specious aspect of SLA's, however, is the phrasing "by using the device/software you agree to the terms of this license." The fact courts appear to be supporting such significant contracts without any evidence whatsoever the end user is even aware the contract exists is a way bigger problem than this Secure Boot hoopla. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Mon, 2012-06-18 at 18:57 -0600, Chris Murphy wrote: > As far as I'm aware, there is in fact no reason why you can't remove > grub2 and replace it with grub (legacy) if it has the exact behaviors > you prefer and require. This is broadly true, but I'd say it's fairly inevitable it'll get more difficult and buggy over time; not due to any sinister action on anyone's part, but simply inaction. No-one will be maintaining grub-legacy any more once it's superseded for EFI purposes, and fewer and fewer people will be using and testing it over time, making it less and less likely that any bugs which creep into grub itself or grubby or the kernel scripts or any other bit of the whole infrastructure will be found and fixed wrt grub-legacy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Jun 18, 2012, at 6:36 PM, Kevin Kofler wrote: > Chris Murphy wrote: > >> >> On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: >> >>> Chris Murphy wrote: Grubby does not work fine with GRUB 2, it creates sloppy menu lists that eventually break the advanced menu entries, as well as totally departing from any user customization of /etc/default/grub. >>> >>> … vs. grub2-mkconfig, which totally departs from any user customization >>> in grub.cfg. >> >> It does not totally depart. It is merely (highly) not recommended to >> directly edit that file. > > Running grub2-mkconfig automatically makes it not just "(highly) not > recommended", but basically impossible: Any edits will be trashed at the > next kernel update! Which is why if grub-mkconfig is going to be used, the upstream prescribed editing procedure needs to be used. If inadequate, the inadequacy needs to addressed. As far as I'm aware, there is in fact no reason why you can't remove grub2 and replace it with grub (legacy) if it has the exact behaviors you prefer and require. I prefer GRUB2's self-produced grub.cfg's and I don't find it overly difficult to get the customization I want – except for the fact grubby steps on this, meaning I have to manually run grub-mkconfig to fix the grub.cfg at each kernel update. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
Chris Murphy wrote: > > On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: > >> Chris Murphy wrote: >>> Grubby does not work fine with GRUB 2, it creates sloppy menu lists that >>> eventually break the advanced menu entries, as well as totally departing >>> from any user customization of /etc/default/grub. >> >> … vs. grub2-mkconfig, which totally departs from any user customization >> in grub.cfg. > > It does not totally depart. It is merely (highly) not recommended to > directly edit that file. Running grub2-mkconfig automatically makes it not just "(highly) not recommended", but basically impossible: Any edits will be trashed at the next kernel update! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
> I wonder if it would be possible to do it on shutdown instead of during > start up? Perhaps on shutdown, the default shutdown target gets replaced with the "system update" target, so that this doesn't affect start up speed. My issue with this is not the concept or the technical merits, but the user experience. I have spent many hours twiddling my thumbs at windows and OSX updates for desktop systems that I need to support. I think there are ways that the updates could be prepared ondisk to make this process as fast as possible. I think another idea, is that if the system has btrfs (which will be default in fedora soon), make /usr and /var subvolumes. Then, when updates come along, snapshot /usr and /var (maybe even /etc) and do the updates into the new snapshots since btrfs snapshots are writable. Once the update is complete, just make the new default subvol for /usr and /var the newly updated volumes. If people want to roll back, each update we add a new kernel menu entry that points at different subvolumes (Similar to a solaris boot environment) This way, Your reboot is extremely fast and you gain all the benefits of the "offline" updates. This is similar to yum-fs-snapshot. -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Mon, 2012-06-18 at 09:30 +0200, drago01 wrote: > >That is to stop reinventing the wheel. > > This would just result into stagnation while the competition invents > much better wheels and leave us behind. Right. The phrase 'reinventing the wheel' is easy to misunderstand. The practice it skewers is the one of going into an area and coming up with your best effort at it from first principles, without looking at what others have achieved first. Essentially, if you're 'reinventing the wheel', the mistake you're making is that you are failing to stand on the shoulders of any handy giants that are around. You should always look around for some giants before you start out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 4:45 PM, Adam Williamson wrote: > What I should have said is that we have no God-given right to demand > that any computing device offered for sale must be explicitly designed > to accommodate the retrofitting of other operating systems or software, > or indeed to demand that any device available not be designed expressly > to prevent it. What I was trying to correct was an impulse to assume > that the x86/BIOS world where systems are explicitly designed to make > execution of arbitrary code easy is the One True Way for things to be, > rather than an accident of history, and anyone doing anything different > must inevitably be guilty of some kind of crime or immorality and must > be fought to the last ditch. Indeed the laws and norms of our societies do not currently mandate a right for devices to be easily modified by the users. But the copyleft licenses that free software are distributed under do require that kind of freedom be not removed via copyright as a condition for distribution of the copylefted work because the freedom to modify the software we use is something important and worth investing resources into maintaining for everyone, even if it doesn't quite rise to the level of a recognized human right. It's also the case that making sure all the users have good access to become authors keeps the ecosystem viable and that the participants have standing which is legally equal makes it fair (well, as fair as anything can be... not always very). And with the trend of software systems mediating an increasingly large portion of our public and private lives, I think we will be fools if we don't recognize some degree of software freedom as a human right someday— at least if there is any remaining question of it being denied. We can split hairs over the current technicalities, but copyleft licenses were created so that people could give away software without downstream users enhancing it and locking it up again using copyright. If, practically, technologies like secureboot and trusted boot produce the same result through cryptographic lockdown instead of the threat of copyright litigation then anyone who rationally choses to use copyleft would choose to prohibit those things too. After all, cryptographic signing that actively prohibits users is a far more practical issue then the threat of copyright violation litigation. It will be unfortunate to see Fedora and Redhat in a position of arguing against licensing that allows authors to ensure that their work isn't used as a part of systems that deny their recipients the intended freedoms, simply because fedora has become invested in working with the freedom denying infrastructure— or even profits directly from it if 'competition' with radically open development practices find that they're structurally or philosophically unable to comply with the requirements for obtaining an automatically accepted signing key. And keep in mind: Fedora 18 with the signed bootloader will work fine on systems which do not permit the owner of the system to change the keys— while this might not be the world that exists when UEFI initially ships there is no assurance that it won't be later, and the decision to sign now is one less argument (if only a small one) against removing the option, and as was noted by others here at least some of the OEMs would apparently really like to do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)
Kevin Fenzi wrote: > 18:23:37 #topic ticket 868 F18 Feature: MiniDebugInfo - > https://fedoraproject.org/wiki/Features/MiniDebugInfo > 18:23:37 .fesco 868 > 18:23:42 nirik: #868 (F18 Feature: MiniDebugInfo - > https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - > https://fedorahosted.org/fesco/ticket/868 > 18:24:03 mmaslano was 0 in ticket. > 18:24:24 I'm -1. First of all, thank you Kevin for having been the only one stepping up against this nonsense! > 18:24:28 Seemed. . .mildly contentious. . . > 18:24:34 I think the only technical objection was that spins won't > fit on a CD, The "only" technical objection which is a blocker as far as we're concerned. Image sizes are even a release blocker! Nobody decided that spins should NOT be CD-sized. There was also the additional objection that the feature brings no practical gain, because -debuginfo is already available and the Retrace Server is available. Later in the discussion, you also pointed out that ABRT probably won't even use this information! So why ship it? Bloat just for the sake of bloat? > but when repeatedly asked nobody came up with an example user/ambassador > saying that CDs are needed Huh? Examples have been given in the mailing list threads. There's also the constraint that all the spins in both 32-bit and 64-bit editions need to fit on one DVD (the Multi DVD), which very much does matter to the ambassadors. > 18:24:54 nirik: out of curiosity, why do you say -1? > 18:25:17 i am +1. obviously would need to be coordinated with > any dmz-related rebuilding > 18:25:21 * pjones is also +1 > 18:25:33 I don't think the extra size is worth the gain. I think > we can/should work on making abrt better. Right. > 18:25:34 i don't know if i should comment, but from my role as > an upstream maintainer, this would be really useful for real life > debugging from end users... That's what -debuginfo packages are for! > 18:25:44 mitr: Would dwarf compression help that? > 18:25:48 i'm marginally +1 > 18:25:55 limburgher: no - different set of fields Even if it were affecting the mini-debuginfo fields (it doesn't), compression wouldn't help at all because the live images are already compressed. Even special-case compression has at best a very small effect after xz is run on it. > 18:25:56 limburgher: jakub said above that it is orthogonal > 18:25:57 as long as it does not replace full backtraces reported in > ABRT I'm ok with it so marginally +1 > 18:26:11 AFAICS this "only" benefits developers and reading crashes > in unexpected components, but given Fedora's target arudence, +21 > 18:26:14 +1 that is > 18:26:16 mitr, pjones: Missed that, thanks. > 18:26:22 Ok. +1 > 18:26:24 I lean +1 > 18:26:43 nirik: My best guess is that abrt will just ignore this. So just useless bloat. > 18:26:57 #agreed Feature is approved. (+7/-1/0) > 18:27:01 <_jakub_> I don't see what minidebuginfo gives us as advantage > for bugreporting, in theory all you need is addresses (relative to start > of DSOs) and their build-ids, everything can be recomputed from that So there, THE expert on the domain tells you the bloat is totally useless, but it's too late, you already rushed out a vote of a bunch of "marginal" +1s. :-/ > 18:27:03 I wish spins could stay on CDs, but then I still > want CD and floppy install media. Floppies are clearly too small. CDs are not. They'd fit all we need if it weren't for the completely useless bloat added by "features" such as this. I also object to the fact that the feature owners have spun the feature proposal in a deliberately misleading way: * "increase quality of bug reports"? – ABRT won't even use this! * "allow easier support for profiling and user space tracing"? – Why wouldn't one just install -debuginfo for those tasks? It's not what a user needs to do every day. * misleading percentages – see Talk page * Also note that for shared objects, we already HAVE symbols for the exported functions (for free!), which is often enough! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 18, 2012, at 2:45 PM, Adam Williamson wrote: > Re-reading my paragraph above, I admit I phrased it somewhat badly. A > convincing case could at least be made, under the first sale doctrine, > that you have the right to _try_ and retrofit alternative operating > systems onto any device you purchase. I don't see how first sale doctrine applies. The doctrine applies to copyright IP, not physical hardware. And the doctrine applies only if you purchased/own a copy of the copyrighted work. If you own it, you can sell that particular instance. If you licensed or rented it, you can't. Modification/retrofitting isn't indicated in the doctrine. > As I said later in my mail, the > question of whether doing it when the manufacturer has made no provision > to let you do it or has actively tried to prevent you doing it can ever > be illegal is really kind of a side issue to the main debate in this > thread, and I'm trying to avoid it. I understand the desire to avoid, but it's not so easy because everything comes with EULAs or SLAs these days. And that even includes UEFI. The EULA can of worms escaped over a decade ago and no one really bothered to care. I haven't read other vendors' SLAs for EFI, but Apple has one and it asserts the software is licensed, not owned. Therefore if I agree to the license, first sale doctrine definitely doesn't apply, and presently established case law supports this contention. The agreement expressly defines the terms of how I can make a one time permanent transfer of all of the software and hardware together as a bundle - without that, having previously agreed to the SLA, I wouldn't be able to sell the hardware because I wouldn't be able to sell the EFI software or OS which I do not own, but merely license. If I agree to the license, further I can't decompile, reverse engineer, disassemble, decrypt or modify the software at all. If I don't agree to the license, then I'm not to use the software. So on the face without further investigation, it seems like wholesale removal of their EFI is permissible. Whether it's possible or practical, for this or non-Apple hardware, I have no idea. This ideology is a problem for ebooks also because publishers are asserting these are not sold copies, but either rental or licensed copies. They are asserting you cannot give away purchased ebooks, to a library, to your mom, anyway. Some have borrowing terms, which are time limited, and frequently a one time deal for life. So this paradigm is quite dangerous compared to physical books under which first sale doctrine absolutely did (and does) apply. > > What I should have said is that we have no God-given right to demand > that any computing device offered for sale must be explicitly designed > to accommodate the retrofitting of other operating systems or software, > or indeed to demand that any device available not be designed expressly > to prevent it. What I was trying to correct was an impulse to assume > that the x86/BIOS world where systems are explicitly designed to make > execution of arbitrary code easy is the One True Way for things to be, > rather than an accident of history, and anyone doing anything different > must inevitably be guilty of some kind of crime or immorality and must > be fought to the last ditch. That is how I understood the original text. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Jay Sulzberger writes: > If I understand correctly, Fedora has now formally allowed > Microsoft to lock Fedora out of many coming ARM devices. As I understand it, you have the freedom to purchase a $99 key from Microsoft which you can then use to install Fedora on those locked ARM devices designed for Windows 8. The current proposal is that Fedora does NOT spend the $99 on an ARM key, but any Fedora user could circumvent that. Admittedly most likely with a bit of annoying paperwork and key juggling. Hopefully the technical part would be made quite easy because it would be like the process for running self-signed on x86. Fedora also has the ability to change its collective mind at any time; if it is discovered that it makes more sense to sign Fedora ARM with a key from Microsoft, then Fedora has that option open. This whole business is leaving an awfully bad taste in my mouth but I have no ideas which are better than the original proposal. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 17:04 -0400, Gerald Henriksen wrote: > On Mon, 18 Jun 2012 19:21:40 +0200, you wrote: > > > > > > >Am 18.06.2012 19:18, schrieb Adam Williamson: > > > >> I hesitate to put words in people's mouths, and correct me if I'm wrong, > >> but it reads to me as if Jay and others are arguing from an incorrect > >> That premise is to assume that there is a God-given right for > >> people who own computing devices to retrofit alternative operating > >> systems onto those devices. > >> > >> I want to put it out there that this is _not true_ > > > >it is true > > > >i buy a computer > >i do not rent it > >i pay money, i own teh device after giving my money > > Many things you buy come with restrictions on ownership. > > If you buy a car, you accept that there are restrictions on it. You > cannot drive it anywhere you want, you must obey certain rules when > operating it, you are forbidden from making certain modifications to > it, etc. > > You buy a house, and you can't do anything you want. You must > following building codes, community bylaws, HOH/condo rules, etc. > > A computer is nothing different. If it has limitations when you buy > it, your are implicitely accepting those limitations when you complete > the transaction. In some cases you may be able to get around those > limitations, but it is not a right to be able to. I don't think that's a terribly good analogy. In the examples you cite, you buy the item from one party and the restrictions on its use are imposed by another party (the government). They aren't imposed for the convenience of the business that sold you the item, but for the general good of society. And we're still down the side alley of whether one should be _legally allowed_ to use a device for arbitrary purposes, which _still_ isn't really what's at issue in the case of Secure Boot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012 19:21:40 +0200, you wrote: > > >Am 18.06.2012 19:18, schrieb Adam Williamson: > >> I hesitate to put words in people's mouths, and correct me if I'm wrong, >> but it reads to me as if Jay and others are arguing from an incorrect >> That premise is to assume that there is a God-given right for >> people who own computing devices to retrofit alternative operating >> systems onto those devices. >> >> I want to put it out there that this is _not true_ > >it is true > >i buy a computer >i do not rent it >i pay money, i own teh device after giving my money Many things you buy come with restrictions on ownership. If you buy a car, you accept that there are restrictions on it. You cannot drive it anywhere you want, you must obey certain rules when operating it, you are forbidden from making certain modifications to it, etc. You buy a house, and you can't do anything you want. You must following building codes, community bylaws, HOH/condo rules, etc. A computer is nothing different. If it has limitations when you buy it, your are implicitely accepting those limitations when you complete the transaction. In some cases you may be able to get around those limitations, but it is not a right to be able to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 01:21 PM, Reindl Harald wrote: Am 18.06.2012 19:18, schrieb Adam Williamson: I hesitate to put words in people's mouths, and correct me if I'm wrong, but it reads to me as if Jay and others are arguing from an incorrect That premise is to assume that there is a God-given right for people who own computing devices to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_ it is true i buy a computer i do not rent it i pay money, i own teh device after giving my money You have to realize that the ease of installing alternative software is a historical accident resulting from the fact that you buy the computer from one company and the software is provided by another company. Certainly in cases when both hardware and software come from the same company, the expectation is that you cannot freely replace the software. Do you own it? Yes. Can you break it? Yes. Do they have to make it easy or at all possible to replace the software? No!. As Adam said, there is no legal doctrine guaranteeing the right to replace such software, and unfortunately there may be laws forbidding you from circumventing technical obstacles to replace the original software, if the manufacturer can claim that they protect some copyrighted material. Please understand that I am not saying that this is how it should be; I am just saying this is how things are now, in my personal opinion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 4:53 PM, Lennart Poettering wrote: > Well, even if Mozilla "fixed" that, such a solution wouldn't work for OS > updates, already due to privilege reasons. i.e. "pre-staging" changes as > root which are applied when a user does something simply cannot work if > you care about security or supporting multi-user systems. Cannot is a strong word. For example, an update process can hang around and watch for all instances process to go away while some notification facility nags users to restarted. Or on close the DE can signal the staged upgrade to go through, or just automatic on reboot. Reboots on triggered from the desktop environment certainly no more multi-user hostile than that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 18.06.12 15:25, Gregory Maxwell (gmaxw...@gmail.com) wrote: > On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating > wrote: > > On 06/18/2012 09:24 AM, Gregory Maxwell wrote: > >> I run Mozilla's nightly builds and receive updates every day. They > >> disrupt nothing because Mozilla has built infrastructure to make that > >> possible. Firefox must be restarted for the updates to take effect, > >> which is when it does the actual swapout of the staged files, but the > >> restart is basically just a window flickering— tabs retain their > >> state, including forms— in fact to prove the point I manually > >> triggered it while writing this email. > > Your anecdata does not match my anecdata. Both Firefox and Thunderbird will > > malfunction in strange and subtle ways if the package is while the > > application is running. A restart of the application is required before > > things start behaving as expected. There are enough people out there > > experiencing this that one cannot wave it off as hallucinations. It is a > > real problem that exists despite your experience to the opposite. > > I'm not waving it off. It's something which Mozilla has fixed in > their nightly update process which is not addressed in Fedora updates > for Firefox. Mozilla nightly pre-stages the update and then does the > update on startup. When combined with persisting the application > state across restarts it makes the whole thing painless. Otherwise, > yes, it can be problematic, as firefox does runtime dlopening and such > and can end up inconsistent if you swap out files out from under it. Well, even if Mozilla "fixed" that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. "pre-staging" changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 14:27 -0600, Chris Murphy wrote: > On Jun 18, 2012, at 11:21 AM, Reindl Harald wrote: > > > > > > > Am 18.06.2012 19:18, schrieb Adam Williamson: > > > >> I hesitate to put words in people's mouths, and correct me if I'm wrong, > >> but it reads to me as if Jay and others are arguing from an incorrect > >> That premise is to assume that there is a God-given right for > >> people who own computing devices to retrofit alternative operating > >> systems onto those devices. > >> > >> I want to put it out there that this is _not true_ > > > > it is true > > > > i buy a computer > > i do not rent it > > i pay money, i own teh device after giving my money > > Yes but you might own a device that disallows by design applying an > alternative OS. You don't have a right to own a device that allows by > design applying an alternative OS. If you agree to terms of use that > proscribe the means by which you'd apply or use an alternative OS, > then you're violating the agreement. So you kinda need to know what > you're buying before you own it. I think we're headed off down the side alley again. Re-reading my paragraph above, I admit I phrased it somewhat badly. A convincing case could at least be made, under the first sale doctrine, that you have the right to _try_ and retrofit alternative operating systems onto any device you purchase. As I said later in my mail, the question of whether doing it when the manufacturer has made no provision to let you do it or has actively tried to prevent you doing it can ever be illegal is really kind of a side issue to the main debate in this thread, and I'm trying to avoid it. What I should have said is that we have no God-given right to demand that any computing device offered for sale must be explicitly designed to accommodate the retrofitting of other operating systems or software, or indeed to demand that any device available not be designed expressly to prevent it. What I was trying to correct was an impulse to assume that the x86/BIOS world where systems are explicitly designed to make execution of arbitrary code easy is the One True Way for things to be, rather than an accident of history, and anyone doing anything different must inevitably be guilty of some kind of crime or immorality and must be fought to the last ditch. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 18, 2012, at 11:21 AM, Reindl Harald wrote: > > > Am 18.06.2012 19:18, schrieb Adam Williamson: > >> I hesitate to put words in people's mouths, and correct me if I'm wrong, >> but it reads to me as if Jay and others are arguing from an incorrect >> That premise is to assume that there is a God-given right for >> people who own computing devices to retrofit alternative operating >> systems onto those devices. >> >> I want to put it out there that this is _not true_ > > it is true > > i buy a computer > i do not rent it > i pay money, i own teh device after giving my money Yes but you might own a device that disallows by design applying an alternative OS. You don't have a right to own a device that allows by design applying an alternative OS. If you agree to terms of use that proscribe the means by which you'd apply or use an alternative OS, then you're violating the agreement. So you kinda need to know what you're buying before you own it. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: .so's in devel packages...
Adam, Thanks, this helps a lot understanding a bit more around shared libraries; NM 2012/6/18 Adam Williamson > On Mon, 2012-06-18 at 18:23 +0100, Nelson Marques wrote: >> Hi all, >> >> >> I have a doubt regarding the '.so's' in devel packages... From my >> understanding they go in devel packages to allow the installation of >> several packages with different versioning > > Not really, no. They go in -devel packages because the only time it's > actually appropriate to use a library by referring to its unversioned > name is when you're compiling another application against it. It's never > safe for anything to access a library at runtime via an unversioned name > because there is no guarantee of stability; you can't be at all sure > that the version of the library you're calling is actually capable of > doing what you're asking it to do. Since the only use of the unversioned > 'instance' (symlink, in Fedora...) of a library is in development, > naturally it goes in the devel package. We can take advantage of this in > generating dependencies, and we do, which is why it's important not to > put the .so file in a runtime package, or that runtime package will get > a bunch of automatically generated dependencies on -devel packages. > > The whole system of naming and versioning of shared libraries, and the > appropriate way of packaging them, is somewhat complex but very neat and > makes a lot of sense. It's worth reading up and understanding exactly > how it works and what it achieves. I don't know if there's a 'canonical' > reference for this, but a bit of Googling produces: > > http://static.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ > > Which seems like a rather good overview. > >> Who defined this? Is this part of some standards (ex: LSB, etc) ? >> >> Is there some written documentation about this ? > > See above. Also > https://www.ibm.com/developerworks/linux/library/l-shlibs/index.html has > some good stuff. > http://netwinder.osuosl.org/pub/netwinder/docs/misc/GCC-HOWTO-html/GCC-HOWTO-6.html > has more of the same, and explains the wrinkle of the 'soname' that's > actually embedded in the library file quite well. > > This isn't Linux-specific, note. Most *nixes use the same format (ELF) > and the same conventions with regard to linking and versioning shared > libraries. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Nelson Marques // I've stopped trying to understand sandwiches with a third piece of bread in the middle... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 19:03 +0200, Reindl Harald wrote: > currently here are much more problems that firefox needs SIGKILL > without any firefox update - so many of this 0.01% coming > from users only updated extensions, confirmed restart and nothing > happend > > i still can't count how often this happened in the last few months > > interesting that after rpm-updates there is mostly no single problem You misspelled "irrelevant". - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 3:15 PM, Chris Murphy wrote: > On Jun 18, 2012, at 10:05 AM, Matthew Garrett wrote: >> 2) Government. If a large enough set of national governments required >> that secure boot be disabled by default then we could assume that >> arbitrary hardware would work out of the box. It's unclear to me which >> laws you think the vendors would be breaking, but I'm not a lawyer. > > In the current U.S. (and likely EU as well) political climate, i.e. extreme > ignorance of computing, fear of real and imaginary infrastructure > vulnerabilities, and desire to make out with all things with the word > security, there is in my estimation no chance Secure Boot nor the Windows 8 > hardware requirements will be perceived as being anti-competitive. Certainly if you subtract Microsoft's desktop monopoly from the equation the more likely legislative direction would be towards _mandating_ secure boot, without user installable keys, in products sold or marketed in the US just like we see with video recorders and macrovision. Or at least, that probably wouldn't be a tremendously uphill battle for someone who wanted to lobby for it, precisely because of the climate you've outlined. The implication that such legislation was a bought and paid for outright land-grab market over to monopolists would probably be the only effective argument against it— because everyone is blinded by words like "cybersecurity", so arguing that we don't need to take user's control of their computers away for cybersecurity won't work, and varrious narrow exceptions for "research" and "education" will silence the majority of the special interests who would otherwise complain. Part of the reasons that emotions can run high here is that this is all happening in the context of a general change in computing devices with long term human right implications, issues far beyond the ease of installing a single distribution. As software mediation becomes more critical in people's lives control over that software is being further restricted. Can free software survive as something that preserves individual rights as it becomes increasingly beholden to large publicly traded companies for basic usability? As technically skilled people we're all taking part in building the future— but what future will it be? Hopefully not this one: http://www.gnu.org/philosophy/right-to-read.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Am 18.06.2012 19:18, schrieb Adam Williamson: > I hesitate to put words in people's mouths, and correct me if I'm wrong, > but it reads to me as if Jay and others are arguing from an incorrect > That premise is to assume that there is a God-given right for > people who own computing devices to retrofit alternative operating > systems onto those devices. > > I want to put it out there that this is _not true_ it is true i buy a computer i do not rent it i pay money, i own teh device after giving my money signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 18:58, schrieb Richard Hughes: > On 18 June 2012 17:36, Reindl Harald wrote: >> and now you come the road and thell us firefox can not be >> updated while it is running? strange that i apply FF updates >> since years in my daily workload and after all are finished the >> browser get's restarted or even at the next day if the update >> happens 1 or 2 hours before i go home > > No, I'm telling you that it works 99.99%[1] of the time quite well. > When it fails, it fails hard, and the user creates an angry bugzilla > pointing at me that i have to read and try to explain to the user why > their bookmarks are lost or why firefox needs to be kill-9'd before it > can be launched again from a launcher. > > Richard. > > [1] 0.01% x installed userbase = lots of bugzilla spam in my inbox. currently here are much more problems that firefox needs SIGKILL without any firefox update - so many of this 0.01% coming from users only updated extensions, confirmed restart and nothing happend i still can't count how often this happened in the last few months interesting that after rpm-updates there is mostly no single problem signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Maintainers with bugzilla issues. (Please read and help contact)
Greetings. We have some users who are owners or initialcc on Fedora packages, but have no bugzilla account that matches up with the email they have listed in the Fedora account system. See: https://fedorahosted.org/fesco/ticket/861 for more details. If anyone knows any way to contact the following people, please do so and ask them to resolve this issue or ask for help from ad...@fedoraproject.org to do so. fas name / real-name (if public) / email: aleksey2005 'Popkov Aleksey' bernie 'Bernie Innocenti' caillon 'Christopher Aillon' caniszczyk 'Chris Aniszczyk' choeger 'Christoph Höger' chreide 'Christian Eide' cmaiolino '' svahl 'Sebastian Vahl' arbiter '' lashar 'Mostafa Daneshvar' gljohn 'Gareth John' dageek 'Gavin Spurgeon' mmcgrath 'Mike McGrath' jfch 'Jan F. Chadima' mchua 'Mel Chua' peterscheie 'Peter Scheie' pnasrat 'Paul Nasrat' rhe 'Rui He' viji 'Viji V Nair' zmc '' We will be orphaning packages owned by people in this state on 2012-07-02, so if you know of a way to contact them, please do so before then. Packages with owners in the above list that will be orphaned: aleksey2005 lightsquid aleksey2005 openscada bernie devtodo bernie monkeysphere caillon drwright caillon fedora-bookmarks caillon gnome-hearts caillon gnuchess caillon iso-codes caillon mozilla-filesystem caillon xboard caillon xchat choeger offlineimap svahl devilspie svahl kcoloredit svahl kgrab svahl kiconedit svahl konq-plugins svahl koverartist svahl ksig svahl libzip svahl polyester svahl polyester3 svahl stalonetray gljohn gtkmm-utils gljohn paperbox mmcgrath ytalk mchua education-bookmarks peterscheie k12linux-quick-start-guide zmc dogtail thanks, kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating wrote: > On 06/18/2012 09:24 AM, Gregory Maxwell wrote: >> I run Mozilla's nightly builds and receive updates every day. They >> disrupt nothing because Mozilla has built infrastructure to make that >> possible. Firefox must be restarted for the updates to take effect, >> which is when it does the actual swapout of the staged files, but the >> restart is basically just a window flickering— tabs retain their >> state, including forms— in fact to prove the point I manually >> triggered it while writing this email. > Your anecdata does not match my anecdata. Both Firefox and Thunderbird will > malfunction in strange and subtle ways if the package is while the > application is running. A restart of the application is required before > things start behaving as expected. There are enough people out there > experiencing this that one cannot wave it off as hallucinations. It is a > real problem that exists despite your experience to the opposite. I'm not waving it off. It's something which Mozilla has fixed in their nightly update process which is not addressed in Fedora updates for Firefox. Mozilla nightly pre-stages the update and then does the update on startup. When combined with persisting the application state across restarts it makes the whole thing painless. Otherwise, yes, it can be problematic, as firefox does runtime dlopening and such and can end up inconsistent if you swap out files out from under it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: .so's in devel packages...
On Mon, 2012-06-18 at 18:23 +0100, Nelson Marques wrote: > Hi all, > > > I have a doubt regarding the '.so's' in devel packages... From my > understanding they go in devel packages to allow the installation of > several packages with different versioning Not really, no. They go in -devel packages because the only time it's actually appropriate to use a library by referring to its unversioned name is when you're compiling another application against it. It's never safe for anything to access a library at runtime via an unversioned name because there is no guarantee of stability; you can't be at all sure that the version of the library you're calling is actually capable of doing what you're asking it to do. Since the only use of the unversioned 'instance' (symlink, in Fedora...) of a library is in development, naturally it goes in the devel package. We can take advantage of this in generating dependencies, and we do, which is why it's important not to put the .so file in a runtime package, or that runtime package will get a bunch of automatically generated dependencies on -devel packages. The whole system of naming and versioning of shared libraries, and the appropriate way of packaging them, is somewhat complex but very neat and makes a lot of sense. It's worth reading up and understanding exactly how it works and what it achieves. I don't know if there's a 'canonical' reference for this, but a bit of Googling produces: http://static.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ Which seems like a rather good overview. > Who defined this? Is this part of some standards (ex: LSB, etc) ? > > Is there some written documentation about this ? See above. Also https://www.ibm.com/developerworks/linux/library/l-shlibs/index.html has some good stuff. http://netwinder.osuosl.org/pub/netwinder/docs/misc/GCC-HOWTO-html/GCC-HOWTO-6.html has more of the same, and explains the wrinkle of the 'soname' that's actually embedded in the library file quite well. This isn't Linux-specific, note. Most *nixes use the same format (ELF) and the same conventions with regard to linking and versioning shared libraries. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 18, 2012, at 10:05 AM, Matthew Garrett wrote: > 2) Government. If a large enough set of national governments required > that secure boot be disabled by default then we could assume that > arbitrary hardware would work out of the box. It's unclear to me which > laws you think the vendors would be breaking, but I'm not a lawyer. In the current U.S. (and likely EU as well) political climate, i.e. extreme ignorance of computing, fear of real and imaginary infrastructure vulnerabilities, and desire to make out with all things with the word security, there is in my estimation no chance Secure Boot nor the Windows 8 hardware requirements will be perceived as being anti-competitive. It would be easier to find government money to retrofit older hardware with UEFI Secure Boot capability than to find the money to even explore the possibility of Microsoft (or vendor) anti-competitive behavior, in this context. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 14:42 -0400, Seth Johnson wrote: > In this connection, the claim is that if we actually purchase > something (and do not contract the transaction otherwise), then as our > property we can do with it as we see fit. The notion that there's > another kind of transaction where nobody actually owns the devices is > part of how the content cabal sometimes frames their conception. > > 1) This does not mean someone cannot sell a palladiated device to you. > 2) This does not mean you cannot crack it, though the DMCA apparently > says you cannot without risk of imprisonment -- yet at the recent DMCA You're arguing the point I specifically stated was a side issue. I fully acknowledged that the question of what can be done by third parties to circumvent a manufacturer's attempt to restrict the capabilities of a product is a rather thorny one. But we don't need to argue about it, because it's really not relevant here. I think _everyone_ arguing in the thread is happy to keep in mind the caveat that, in many cases (not all; un-cracked devices exist), enthusiasts will be able to circumvent protections. We don't really need to argue about how often this will be the case or whether such cracking should be legally protected or not. It's a huge side alley. It doesn't actually affect the key points we've been debating. For all intents and purposes we can assume that any device which requires more than a single keypress to 'crack' will not be 'cracked' by the vast majority of users. > Exemptions hearings we seemed to register the dawning awareness in the > Copyright Office that circumvention to put in a new operating system > is not the same thing as a copyright infringement; and more > astoundingly, the content cabal advocates specifically stated that the > act of circumvention to put in another operating system on your own > device has nothing to do with copyright; what will be made of this > development by the Office is hard to say yet. They seem to recognize > the pertinence of the point (the point being, what about using my > property with whatever operating system I please on it?). They say > they may ask for more input and are presently trying to figure out how > they will proceed. Irrelevant. (FWIW, I've already stated elsewhere in the thread that I'd be very surprised if anyone could succeed in arguing in a court that any future circumvention of Secure Boot which turns out to be possible constitutes a breach of the DMCA). > 3) The claim that Microsoft or anybody must be *forced* to provide > devices without Secure Boot turned on is not Jay's position (or mine); > that's Matthew Garrett's frustrated characterization of the options. > (Though I believe Jay would hold for the particular case of Microsoft, > inasmuch as they possess or come to possess a monopoly, they would > appropriately be forced to do various things.) Indeed, the Secure > Boot technology is a useful facility. We can create a market in > devices over which owners can hold root control; that market may cost > a little more, and it may cater to an elite, but inasmuch as that > elite does not eventually endorse a "license to compute" the fact that > they are using devices that give them full root rights and capacity to > parse and process whatever information they receive can make the very > existence of those devices a desirable feature for the public at > large. If I can be allowed to nitpick, I don't think Fedora can 'create' such a market. We aren't hardware manufacturers and don't intend to be. (Somewhat) happily such a market is inevitable and you could perfectly reasonably argue that it already exists. What are Raspberry Pis and Beagleboards and even Nexus cellphones but these 'elite' enthusiast/developer devices? On the other hand, the Nexus example is a salutary one. The cellphone market has been around for decades; the smartphone market, arguably, ten years or so; a major player has provided a very credible series of devices with 'openness' as an explicit selling point; and those devices certainly haven't wiped the floor with all the others. They've sold in respectable numbers to enthusiasts. All indications are that the vast majority of cellphone purchasers don't even consider it a minor factor in their purchase. Nothing I said was based on an assumption that such devices won't exist. On the contrary, it's inevitable that they will (and do). Really, what I'm foreseeing is exactly this Balkanization of the 'computer market'. The key point is that it has been entirely an accident of history that for a couple of decades, the _same devices_ have, broadly speaking, served the needs of simple consumers and of enthusiasts. The vast majority of end users buy, and will continue to buy, 'computers' (or however they eventually come to conceive of such devices; it's an area undergoing an intriguing shift at present) on the same basis as they buy cars, washing machines, game consoles, cellphones and e-book readers (all
Re: *countable infinities only
On Mon, Jun 18, 2012 at 1:18 PM, Adam Williamson wrote: > On Mon, 2012-06-18 at 09:35 -0700, Adam Williamson wrote: > I hesitate to put words in people's mouths, and correct me if I'm wrong, > but it reads to me as if Jay and others are arguing from an incorrect > premise. That premise is to assume that there is a God-given right for > people who own computing devices to retrofit alternative operating > systems onto those devices. > > I want to put it out there that this is _not true_. It is perfectly > possible, of course, for one to aspire to a world in which it is true. > Many of us would want to live in such a world. We have been lucky enough > to live in a world for some time where it _so happened_ that the > 'computing devices' we cared about almost always allowed us to do this. > > However, in the boring practical world where such 'rights' are granted > by process of law, no such right exists. This is your error. There are many statutory rights (early on they were called civil rights and political rights), but there are also rights possessed prior to government. Those who articulated these rights in the process of the English Revolutions said they were natural rights, and some of those called them God-given. Indeed, this is a key premise of the American Revolution. Among these now-mostly-called-"fundamental" rights, but originally termed "natural rights" was the right of property which the government could not take from a free man without severe due process and just compensation. This was part of the checks and balances, and why owning property was so key to the political philosophy at the founding in the States. In this connection, the claim is that if we actually purchase something (and do not contract the transaction otherwise), then as our property we can do with it as we see fit. The notion that there's another kind of transaction where nobody actually owns the devices is part of how the content cabal sometimes frames their conception. 1) This does not mean someone cannot sell a palladiated device to you. 2) This does not mean you cannot crack it, though the DMCA apparently says you cannot without risk of imprisonment -- yet at the recent DMCA Exemptions hearings we seemed to register the dawning awareness in the Copyright Office that circumvention to put in a new operating system is not the same thing as a copyright infringement; and more astoundingly, the content cabal advocates specifically stated that the act of circumvention to put in another operating system on your own device has nothing to do with copyright; what will be made of this development by the Office is hard to say yet. They seem to recognize the pertinence of the point (the point being, what about using my property with whatever operating system I please on it?). They say they may ask for more input and are presently trying to figure out how they will proceed. 3) The claim that Microsoft or anybody must be *forced* to provide devices without Secure Boot turned on is not Jay's position (or mine); that's Matthew Garrett's frustrated characterization of the options. (Though I believe Jay would hold for the particular case of Microsoft, inasmuch as they possess or come to possess a monopoly, they would appropriately be forced to do various things.) Indeed, the Secure Boot technology is a useful facility. We can create a market in devices over which owners can hold root control; that market may cost a little more, and it may cater to an elite, but inasmuch as that elite does not eventually endorse a "license to compute" the fact that they are using devices that give them full root rights and capacity to parse and process whatever information they receive can make the very existence of those devices a desirable feature for the public at large. Inasmuch as such a market exists, the folks who want the world to confuse "prior restraint" versions of copyright with security features, will be unable to rationalize the norms they want to establish, and people will demand, both for their kids and for their personal professional advancement, the right to do the same with the same kind of devices with UEFIs that cater to freedom. Seth > As a practical matter, people > have been manufacturing, advertising and selling computing devices to > the public, all over the world, for decades, which do not intend to > allow the end user of the device to retrofit alternative software - > operating system software, firmware, bootloader, or application. This is -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 18, 2012, at 8:33 AM, Seth Johnson wrote: > I will say: A political campaign > that rebukes Microsoft. For what? Come up with three example picket sign messages for your campaign, and *briefly* elaborate on each one using less than 60 words each. > A stand that does not accommodate Microsoft > before we see a technical path forward and a realistic future for free > software. Microsoft is concerned about boot loader malware. And they have a solution to this problem in the form of Secure Boot and the Windows 8 hardware requirements. No accommodation by a 3rd part is possible You have three choices: produce a compelling thesis and explanation why their concern is unwarranted; prove a Secure Boot vulnerability exists ideally with an example exploit which cannot easily be fixed within the present specification (i.e. it's a fundamental flaw, not merely a bug); or an alternative to Secure Boot and/or Windows 8 hardware requirements that meets Microsoft and OEMs UX goals. More than convincing Fedora decision makers, or Red Hat, your argument for an alternative must be compelling to Microsoft. Those insisting on a foundation that's adversarial will 100% fail to come up with an alternative to the solution Microsoft and OEMs have already satisfactorily arrived at for their concern. > Technically, I'll say only this for now: a UEFI that tells > the truth to the user and makes things non-scary, on trustworthy > hardware -- plus all the infrastructure needed to render the use of > these systems viable for free software. So you're saying hardware vendors should not be free to create a crap UEFI UX? How do you propose enforcing this? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012 10:18:35 -0700, you wrote: >On Mon, 2012-06-18 at 09:35 -0700, Adam Williamson wrote: Much good stuff deleted. >Fedora can deplore the situation; Fedora can state its support for >computing devices which allow the user the freedom to install >alternative operating system software, with reasoned arguments in >support; Fedora can work together with manufacturers of computing >devices which allow such freedom. But I believe it's true, and I think >it's vitally important to keep in mind when debating this topic, that >there is no way in which Fedora can possibly forcibly impose its >position on anyone. It appears to be legally fine for companies to ship >computers you can't (aren't intended to be able to) put other operating >systems on; it is trivially demonstrable that some companies consider it >desirable to do so in some markets; therefore said devices are going to >exist. Fedora can take any one of several approaches to their existence, >but simply deploring the fact and acting, in all respects, either as if >such devices will magically cease to exist at some point or as if we can >pressure them out of existence both seem to be losing strategies in all >regards, to me. I also think any argument which seems to be rooted on >the assumption that such devices are Wrong, Evil and/or Illegal _and >that All-Right Thinking People Will Agree if we can only motivate them >enough_ is doomed to fail. Zillions of people buy locked devices. They >understand, in a vague way, just what it is they are buying. They are >not outraged. They won't be outraged no matter how outraged we try to >make them. Very well said. I think a lot of the trouble here is that people have become obsessed with hating Microsoft for past issues, and need to move on. If people are happy with Linux returning to its roots as a hobbyist system where you have to consult online lists of what hardware is okay to buy, and more importantly what to avoid buying, and then searching for and reading through howto's to get things working, then sticking a foot down and saying we will not participate in the secure boot issue is a valid choice. It just isn't a choice I would make. For Linux in general, and Fedora in particular, to continue to have the influence it does, where essentially all but a couple of hardware makers have provided what is necessary for open source drivers, it is necessary to both have developers and users in sufficient enough numbers. And despite what people here seem to think Microsoft is not the biggest threat to that. Ironically, both Microsoft and Fedora are in the same situation where the younger generation are more interested in Android and iOS than they are in Linux or Windows. Making it harder for those who do have an interest in trying Linux, who might become the next user, or better developer/packager, by not supporting secure boot will in my opinion be self defeating in the long run. Secure boot is not the biggest danger, a lack of new blood into the Linux community is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: .so's in devel packages...
On Mon, 18 Jun 2012 18:23:16 +0100, Nelson Marques wrote: > Hi all, > > > I have a doubt regarding the '.so's' in devel packages... From my > understanding they go in devel packages to allow the installation of > several packages with different versioning > Who defined this? Is this part of some standards (ex: LSB, etc) ? > > Is there some written documentation about this ? Please be *much* more verbose. https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages Thanks in advance! -- Fedora release 17 (Beefy Miracle) - Linux 3.4.2-4.fc17.x86_64 loadavg: 0.52 0.44 0.45 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: > Chris Murphy wrote: >> Grubby does not work fine with GRUB 2, it creates sloppy menu lists that >> eventually break the advanced menu entries, as well as totally departing >> from any user customization of /etc/default/grub. > > … vs. grub2-mkconfig, which totally departs from any user customization in > grub.cfg. It does not totally depart. It is merely (highly) not recommended to directly edit that file. There is indirect customization, which actually in many ways exceeds that of Grub Legacy. But this is an old argument, that ship has sailed. > > You gain flexibility in one place and lose it in another. I'm not convinced > it's an improvement. Though on the other hand, running grub2-mkconfig is how > upstream intends things to work. I've already been on this hill pulling my hair out over GRUB2's complexity and lack of well written documentation. However, I feel like I've passed this particularly large stone, the pain has subsided, and except during pre-release grub-mkconfig hasn't failed to produce a correct grub.cfg and bootable system. Not even once. So. While grubby may do other things, even for GRUB2 dependent systems, the part where it comes up with the new entry should, in my view, just call grub-mkconfig to cause a new grub.cfg to be created. If grub-mkconfig isn't working reliably for some reason, it's a bug that needs to be fixed anyway. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 10:18 AM, Adam Williamson wrote: Sorry for the self-reply, but just in case it's not brutally clear yet, I wanted to explicitly state this: [snip] Bravo! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012 11:23:53 -0400 (EDT), you wrote: > > >On Mon, 18 Jun 2012, Gerald Henriksen wrote: > >> > On Mon, 18 Jun 2012 01:09:52 -0400 (EDT), you wrote: >> >> >On Mon, 18 Jun 2012, Matthew Garrett wrote: >> > >> >> > On Sun, Jun 17, 2012 at 11:21:14PM -0400, Jay Sulzberger wrote: >> >> >> >> > I think 50 million dollars toward buying, and properly arranging >> >> > the UEFI, of several lots of x86 computers would indeed solve >> >> > part of the problem you point out. >> >> > >> >> > Why not? >> >> >> >> Because said machines would cost more than identical hardware with >> >> different firmware. Sales of Linux-specific PC hardware haven't been >> >> massively successful so far. >> >> >> >> -- >> >> Matthew Garrett | mj...@srcf.ucam.org >> > >> >Why should they cost more? >> > >> >And suppose they cost $20 more. Let Red Hat pay this, and/or run >> >an ad campaign explaining that with this motherboard, you can >> >actually know what is running on the machine. >> >> So now your solution to the problem is to have Red Hat subsidize the >> hardware (aka lose money). That is a good way to go out of business >> in a hurry. >> >> >ad previous lack of success of sales of GNU/Linux machines: In >> >every case I know, Microsoft just bribed/threatened the vendor to >> >stop selling the machines. >> >> Of course it could have nothing to do with the Linux community failing >> to provide what the customers wanted, everything has to be a >> conspiracy. >> >> >If Red Hat accedes to Microsoft's demands here, there will be no, >> >let me repeat, no hardware that Fedora can be easily installed >> >on. Here is why: >> > >> >By your own explanation, you think that without the special key, >> >controlled by Microsoft, Fedora would be too hard for some people >> >to install. OK, so you agree that Fedora must get permission >> >from Microsoft to allow easy installs of Fedora. >> > >> >The game is now just about over. What if one day, Microsoft >> >makes it even harder to install Fedora without a Microsoft >> >controlled key? What if, as has already happened with ARM, >> >Microsoft refuses to grant Fedora a special key? >> > >> >No. Let Red Hat tell the truth. Let Red Hat design a better >> >UEFI motherboard. >> >> So now the target has moved from Red Hat buying some hardware with >> secure boot disabled to Red Hat hiring a design team (at signficant >> cost) and developing their own motherboard. > >Yes. That has always been part of one of my short list of >suggestions. > >Why not? > >ad design team at significant cost: Yes, of course. As has been >mentioned, all prototype UEFIs seen by the Red Hat team have bad >interfaces. Why not make a better one? > >> >> It is so nice that you are so willing to spend Red Hat's money, though >> I suspect the shareholders would have other ideas about entering into >> the world of spending lots of money to design a motherboard that you >> then intend to sell at a loss. > >Gerald, I will not respond in detail to your post. I will say >two things: > >Red Hat, before its initial public offering, arranged to lose >money, so that the company would appear more attractive to >investors. > >By the incorrect theory of business explicit in your post, every >cost borne by Red Hat, every investment made by Red Hat, must >necessarily result in Red Hat going broke. I never said that. What I said was selling hardware at a loss (ie. lose money on the hardware sale) is not something that makes sense for a software company like Red Hat. There are some markets where selling at a loss makes sense - the proverbial razor blade example - because you make up the difference and then some in selling an add on. But because Fedora is free, there is no way to make up the money lost on the hardware sale. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Audacious 3.3-alpha1 in Rawhide
Audacious 3.3-alpha1 will be landing in Rawhide. Compared with previous releases in F-17 (and older) it is API/ABI-incompatible once again. I've had a look at what will be necessary to patch dependencies and will take care of patching and rebuilding in the Fedora package collection as necessary. http://audacious-media-player.org/news/12-audacious-3-3-alpha1-released -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
.so's in devel packages...
Hi all, I have a doubt regarding the '.so's' in devel packages... From my understanding they go in devel packages to allow the installation of several packages with different versioning Who defined this? Is this part of some standards (ex: LSB, etc) ? Is there some written documentation about this ? NM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012 11:54:20 -0400 (EDT), you wrote: > > >On Mon, 18 Jun 2012, Matthew Garrett wrote: > >> > On Mon, Jun 18, 2012 at 11:03:23AM -0400, Jay Sulzberger wrote: >> >> > This I do not understand. By reports in the admittedly >> > incompetent magazines dealing with home computers, Microsoft's >> > policy is to keep Fedora, and any other OSes, except for >> > Microsoft OSes, off all Microsoft Certified ARM devices. >> >> I think you've answered your own question there. >> >> > Further questions ad ARM: According to Microsoft, can, in future, >> > "SecureBoot" be disabled on Microsoft Certified ARM devices? >> > Will the person who walks out of the store with a Microsoft >> > Certified ARM device be able to put their own signing key in? >> > What about the PK? >> >> No, Windows 8 ARM devices will not permit the user to install their own >> keys or disable secure boot. That's why we're not going to support them. >> >> -- >> Matthew Garrett | mj...@srcf.ucam.org > >Thanks, Matthew. > >Just one word before I break off, if I can ;), engagement for today: > >If I understand correctly, Fedora has now formally allowed >Microsoft to lock Fedora out of many coming ARM devices. Fedora (or any other Linux) won't run on most of the ARM devices out there already, so what is your point? Apple certainly isn't allowing Fedora to run on the iPad or iPhone. Samsung isn't allow Fedora to run on their tablets. And even if they didn't prevent it, there is no open source drivers for much of the hardware in those devices anyway, and no documentation to write any. The only place Linux like Fedora can run on ARM are a handful of developer devices like BeagleBoard, PandaBoard, Raspberry PI, etc. and even that will often require a binary blob. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 09:35 -0700, Adam Williamson wrote: > A couple of concerned Red Hat / Fedora developers - Peter and Matthew - > have stated that they are unhappy that the certification requirements > for Windows ARM client devices don't state that the user should be able > to disable Secure Boot or install their own signing keys, and stated > that because of this, they don't intend at present to pursue the > approach of having Microsoft sign Fedora ARM releases for use on > Microsoft-certified ARM client devices. I don't think we can formally > characterize this as 'Fedora's' position on the issue, as AFAIK it > hasn't come up before any kind of Fedora representative body, but in > practice, I suspect it's highly likely to hold as Fedora policy if that > were to happen. > > This is the entirety of the situation with regards to ARM client > devices. I am not sure what you think would constitute us 'disallowing' > Microsoft from making things we don't like part of their certification > requirements. Sending them a strongly-worded letter? Making a complaint > to some body that Microsoft had...done what? Sorry for the self-reply, but just in case it's not brutally clear yet, I wanted to explicitly state this: I hesitate to put words in people's mouths, and correct me if I'm wrong, but it reads to me as if Jay and others are arguing from an incorrect premise. That premise is to assume that there is a God-given right for people who own computing devices to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_. It is perfectly possible, of course, for one to aspire to a world in which it is true. Many of us would want to live in such a world. We have been lucky enough to live in a world for some time where it _so happened_ that the 'computing devices' we cared about almost always allowed us to do this. However, in the boring practical world where such 'rights' are granted by process of law, no such right exists. As a practical matter, people have been manufacturing, advertising and selling computing devices to the public, all over the world, for decades, which do not intend to allow the end user of the device to retrofit alternative software - operating system software, firmware, bootloader, or application. It is _already demonstrably the case_ that over the last few years and over the next decade or so, the trend has been and will be for reduced user freedom on typical client computing devices. A smartphone is a 'typical client computing device'. A tablet is a 'typical client computing device'. The vast majority of such devices sold today are designed to preclude the user from installing alternative operating systems and to impose restrictions on the user's ability to execute arbitrary code: virtually all cellphones and tablets are sold with locked bootloaders and without user root access. This has not been challenged in a court of law and I am not aware of any basis on which a challenge to this could plausibly be launched. (As an aside, of course _in practice_ many of these devices are hacked, and the question of whether such hacking can be illegal in a given case is a complex legal one. I don't think it should detain us here, though; the key point is that it's fine for the manufacturers to take steps to _try_ and prevent the installation of alternative software. The question of what happens if their mechanisms are defeated is besides the point.) Fedora can deplore the situation; Fedora can state its support for computing devices which allow the user the freedom to install alternative operating system software, with reasoned arguments in support; Fedora can work together with manufacturers of computing devices which allow such freedom. But I believe it's true, and I think it's vitally important to keep in mind when debating this topic, that there is no way in which Fedora can possibly forcibly impose its position on anyone. It appears to be legally fine for companies to ship computers you can't (aren't intended to be able to) put other operating systems on; it is trivially demonstrable that some companies consider it desirable to do so in some markets; therefore said devices are going to exist. Fedora can take any one of several approaches to their existence, but simply deploring the fact and acting, in all respects, either as if such devices will magically cease to exist at some point or as if we can pressure them out of existence both seem to be losing strategies in all regards, to me. I also think any argument which seems to be rooted on the assumption that such devices are Wrong, Evil and/or Illegal _and that All-Right Thinking People Will Agree if we can only motivate them enough_ is doomed to fail. Zillions of people buy locked devices. They understand, in a vague way, just what it is they are buying. They are not outraged. They won't be outraged no matter how outraged we try to make them. There will always be some people who believe
Re: *countable infinities only
On Mon, 18 Jun 2012 11:14:11 -0400 (EDT), you wrote: > > >On Mon, 18 Jun 2012, Matthew Garrett wrote: > >> > On Mon, Jun 18, 2012 at 12:56:54AM -0400, Jay Sulzberger wrote: >> > >> > We just need hardware we can install Fedora on, as once we did, >> > without asking Microsoft for permission. >> >> System76 have committed to providing hardware without pre-enabled secure >> boot. >> >> -- >> Matthew Garrett | mj...@srcf.ucam.org > >Matthew, I am delighted to hear this. > >Note that this contradicts the claim, made more than once in >this thread, that such an arrangement is, in practice, impossible. No one said it was impossible. What was said was the big outfits, who rely on selling hardware in big volumes, will ship with secure boot enabled. Dell, HP, Asus, Acer, etc all rely on the Windows market to stay in business and thus cannot ship with secure boot disabled. But also note that is the ability to disable secure boot that Fedora/Red Hat got from Microsoft that will allow small builders like System76 to ship systems without it enabled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] color man-pages, bash history, clear console
On Wed, 13.06.12 15:00, Petr Pisar (ppi...@redhat.com) wrote: > On 2012-06-13, Xose Vazquez Perez wrote: > > > >== https://bugzilla.redhat.com/815790 == > > clear_console: New helper program to clear the *console*, > > including the _scrollback buffer_. > > > > DESCRIPTION > > > > clear_console clears your console if this is possible. It looks in > > the environment for the terminal type and then in the terminfo > > database to figure out how to clear the screen. To clear the buffer, > > it then changes the foreground virtual terminal to another > > terminal and then back to the original terminal. > > > I added new escape sequence into Linux to clear the scroll-back buffer > directly. I think enhancing `clear' utility is the right option. BTW, as a side note, systemd makes use of the new escape sequence before and after running gettys. That means on systemd systems output of the previous users is not leaked to you and your data not leaked to the next one using the tty. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 17:36, Reindl Harald wrote: > and now you come the road and thell us firefox can not be > updated while it is running? strange that i apply FF updates > since years in my daily workload and after all are finished the > browser get's restarted or even at the next day if the update > happens 1 or 2 hours before i go home No, I'm telling you that it works 99.99%[1] of the time quite well. When it fails, it fails hard, and the user creates an angry bugzilla pointing at me that i have to read and try to explain to the user why their bookmarks are lost or why firefox needs to be kill-9'd before it can be launched again from a launcher. Richard. [1] 0.01% x installed userbase = lots of bugzilla spam in my inbox. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 18:09, schrieb Lennart Poettering: > I mean, have you ever tried to upgrade firefox while running firefox? If > you did, you know how awfully wrong that goes... [1] > > So, you have three problems: a) you cannot safely determine what to > restart. b) you cannot restart many components of the OS at all c) > upgrades cannot be atomic. i even did DIST-UPGRADES while Firefox, Thunderbird, the whole KDE and Eclipse where up and running without issues only while KDE parts get updated the start of a NEW instamce of a kde-app (as example kate) fails but there was never a problem with running applications and now you come the road and thell us firefox can not be updated while it is running? strange that i apply FF updates since years in my daily workload and after all are finished the browser get's restarted or even at the next day if the update happens 1 or 2 hours before i go home signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 11:54 -0400, Jay Sulzberger wrote: > Just one word before I break off, if I can ;), engagement for today: > > If I understand correctly, Fedora has now formally allowed > Microsoft to lock Fedora out of many coming ARM devices. The use of the term 'allowed' implies that we have any kind of standing to 'allow' or 'disallow' it. Microsoft has published its certification requirements for ARM client devices. They don't have any kind of obligation to ask Fedora, Red Hat or anyone else who isn't actually building ARM client hardware what we think of those requirements. We are not a party to them. A couple of concerned Red Hat / Fedora developers - Peter and Matthew - have stated that they are unhappy that the certification requirements for Windows ARM client devices don't state that the user should be able to disable Secure Boot or install their own signing keys, and stated that because of this, they don't intend at present to pursue the approach of having Microsoft sign Fedora ARM releases for use on Microsoft-certified ARM client devices. I don't think we can formally characterize this as 'Fedora's' position on the issue, as AFAIK it hasn't come up before any kind of Fedora representative body, but in practice, I suspect it's highly likely to hold as Fedora policy if that were to happen. This is the entirety of the situation with regards to ARM client devices. I am not sure what you think would constitute us 'disallowing' Microsoft from making things we don't like part of their certification requirements. Sending them a strongly-worded letter? Making a complaint to some body that Microsoft had...done what? It seems prima facie the case that this is not monopoly abuse, because Microsoft does not hold anything resembling a monopoly in the ARM client device market (if anyone does, Apple does). Remember that when we talk about Microsoft-certified ARM client devices it is a very long-winded way of saying 'tablets and tablet/laptop hybrids running Windows RT', and right now, Microsoft's presence in that space is virtually non-existent. It seems unlikely that it can be characterized as anti-competitive behavior, or one of the many manufacturers who _already_ ship ARM client devices with locked firmware intended to be inaccessible to the user and a signed bootloader requirement - including but not limited to Apple, Samsung, Motorola (Google), and HTC - would have gotten into trouble already. So, again, exactly - what is it that you are proposing should be done? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-18 at 11:14 -0400, Jay Sulzberger wrote: > > On Mon, 18 Jun 2012, Matthew Garrett wrote: > > > > On Mon, Jun 18, 2012 at 12:56:54AM -0400, Jay Sulzberger wrote: > > > > > > We just need hardware we can install Fedora on, as once we did, > > > without asking Microsoft for permission. > > > > System76 have committed to providing hardware without pre-enabled secure > > boot. > > > > -- > > Matthew Garrett | mj...@srcf.ucam.org > > Matthew, I am delighted to hear this. > > Note that this contradicts the claim, made more than once in > this thread, that such an arrangement is, in practice, impossible. That claim is made in relation to the main vendors of mainstream systems - your Dells, Acers and the like - who want to preload Windows. Of course, if you don't want to preload Windows, Microsoft certification requirements mean nothing to you. If you read carefully, no-one has ever stated otherwise. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 12:09 PM, Lennart Poettering wrote: > I mean, have you ever tried to upgrade firefox while running firefox? If > you did, you know how awfully wrong that goes... [1] I run Mozilla's nightly builds and receive updates every day. They disrupt nothing because Mozilla has built infrastructure to make that possible. Firefox must be restarted for the updates to take effect, which is when it does the actual swapout of the staged files, but the restart is basically just a window flickering— tabs retain their state, including forms— in fact to prove the point I manually triggered it while writing this email. This is the direction Fedora should be heading in, if not quite as non-disruptive as what firefox does... and it's not that far off because with the exception of the recently written desktop infrastructure the system largely already support non-disruptive updates. By making updates regularly require reboots the incentive to bridge the gap is reduced and the expectations of a clean enviroment will increase until a rebootless update is as inconceivable in Fedora as it is in Windows. By making updates regularly require reboots you put users in an adversarial relationship with updates. Rather than being seen as something that helps them, updates will be seen as something that get in their way. Many will turn them off completely if you give them an option to do so. We don't have to speculate about the long term consequences of this path because we can already see it in the Windows world: e.g. On several occasions I have seen windows update disrupt presentations because the speaker was talking to the audience and didn't react fast enough to the snooze button on the mandatory updates they've been deferring. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 18/06/12 15:56, Ben Rosser wrote: ould seem like a better idea to me. Hmm, okay. In that case, would it be possible (or at least, a better idea) to modify *grubby* to call grub2-mkconfig when the bootloader is grub2? Then we'd still have all the other abstractions for other bootloaders but new kernel entries would be added in a way that respects the configurations in /etc/default/grub and /etc/grub.d. Ben Provided those who don't want a sub-menu. Have clear docs how to keep all kernels without extra steps for each kernel update. -- Regards, Frank "Jack of all, fubars" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Sun, Jun 17, 2012 at 4:40 PM, Andre Robatino wrote: > Ben Rosser gmail.com> writes: > >> It seems to me that we should make the boot menu more consistent somehow. I > feel like the simplest solution is just to run grub2-mkconfig at every kernel > update, and stop using grubby for this. Then everything would look > consistent- the "Fedora Linux" boot option would have the latest kernel > and all > kernels would always be listed under the submenu. (As far as I know, this > would > just be a change to the kernel specfile, right?). > > +1 > > The present system is especially ugly with multiboot. I tend to run > grub2-mkconfig by hand after each kernel update just to keep the menu clean. /+100 I found that yum update && grub-mkconfig ... makes my life *far* easier. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, 17.06.12 10:53, Richard W.M. Jones (rjo...@redhat.com) wrote: > On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote: > > Hi. > > > > On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote > > > > > One of the most inportant advance of Linux over Windows is the > > > fact, that there are only a few situations - like kernel updates - > > > which requires a reboot of your system. > > > > Linux has, in principle, the same problem as Windows, that while > > you can replace files that are in use running processes will (of course) > > not pick up the changes until restarted. Most daemons do so when updated > > themselves, but, for example, updating zlib because of an exploit will > > not restart all daemons using the exploitable library, so unless the > > admin restarts those manually or the system is rebooted you might > > still be vulnerable. > > So this is a problem that needs to be solved, but does it require a > reboot? Not really ... it's possible to list all processes using > zlib, convert that back into a list of packages, then instruct those > packages to restart themselves. Job done, BETTER than Windows / OS X. Well, if you are referring to doing "lsof" do figure out mapped libraries, than this is simply not sufficient, since there are many more ways how pieces of code we run interface than just shared library interfaces. Sure, with lsof you can find link time shared libs deps of running core. But there are so much other deps you'd need to follow to fully determine the set of things to restart: local socket protocols, bus interfaces or just data files (in /usr/share or so) that are used by code, that when upgraded also need its users restarted. And then there is the huge amount of code we cannot restart at all within a running system. Like the kernel, or dbus. But even more this is true for user applications: how would you go forward and ensure that firefox is restarted if the SSL libs have a vulnerability? And then, upgrades cannot be atomic, that means that there's a time where a process has not been restarted yet where it partially uses old deps/data files and where it partially uses new deps/data files, which is just doomed to go wrong. I mean, have you ever tried to upgrade firefox while running firefox? If you did, you know how awfully wrong that goes... [1] So, you have three problems: a) you cannot safely determine what to restart. b) you cannot restart many components of the OS at all c) upgrades cannot be atomic. Altogether this means, that in-system updates are something that is highly likely to break, and it does all the time. Sure, often enough you get away with doing in-system upgrades, but if we write our programs in a way that things work corretly only "often enough", then we'd bad bad programmers. But anyway, nobody is taking "yum upgrade" away from you. It makes a ton of sense to use this, especially if you are a developer. I for one will always continue to use it, simply because I can deal with the fallout. But that doesn't mean we should implement the safe, technically correct way for the majority of users. Lennart Footnotes: [1] it's actually fun to try, in many cases firefox throws a tonload of JS errors, and even refuses to be shut down at all, unless SIGKILL is used... -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 11:40:01AM -0400, Jay Sulzberger wrote: > But here are two headers of my argument: If we do not defend the > ground on which free software lives and grows, we will shortly > have no free software. Part of the ground is that we need ask no > permission of Microsoft, nor anybody else, to convenienetly use > any services provided by the hardware, services which under your > proposed plan will only be conveniently available to Microsoft. The only way to avoid asking permission of anyone is for secure boot to be disabled by default on all hardware. The problem with that is that vendors *want* secure boot. Some vendors are unhappy that Microsoft required that users be able to disable it on x86. So this isn't a Microsoft problem - it's an industry problem. So what would a solution look like? Since vendors want secure boot, we would obviously need to force the vendors to change their mind. There are two entities that are capable of doing so: 1) Microsoft. If Microsoft changed the Windows 8 requirements such that vendors *must* leave secure boot disabled by default we'd be fine. But then we'd be beholden to Microsoft again, and they could change their mind in future. Given what you've said, it sounds like you don't like this option. 2) Government. If a large enough set of national governments required that secure boot be disabled by default then we could assume that arbitrary hardware would work out of the box. It's unclear to me which laws you think the vendors would be breaking, but I'm not a lawyer. Microsoft may have started this movement, but they're not the only relevant entity in favour of it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 11:54 AM, Jay Sulzberger wrote: If I understand correctly, Fedora has now formally allowed Microsoft to lock Fedora out of many coming ARM devices. Well, no. At this point it's still just a proposal. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 11:03:23AM -0400, Jay Sulzberger wrote: > This I do not understand. By reports in the admittedly > incompetent magazines dealing with home computers, Microsoft's > policy is to keep Fedora, and any other OSes, except for > Microsoft OSes, off all Microsoft Certified ARM devices. I think you've answered your own question there. > Further questions ad ARM: According to Microsoft, can, in future, > "SecureBoot" be disabled on Microsoft Certified ARM devices? > Will the person who walks out of the store with a Microsoft > Certified ARM device be able to put their own signing key in? > What about the PK? No, Windows 8 ARM devices will not permit the user to install their own keys or disable secure boot. That's why we're not going to support them. -- Matthew Garrett | mj...@srcf.ucam.org Thanks, Matthew. Just one word before I break off, if I can ;), engagement for today: If I understand correctly, Fedora has now formally allowed Microsoft to lock Fedora out of many coming ARM devices. I will read all responses either late this evening or tomorrow. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Peter Jones wrote: > On 06/18/2012 11:03 AM, Jay Sulzberger wrote: > >>> Microsoft has not refused to grant Fedora a key for ARM. >> >> This I do not understand. By reports in the admittedly >> incompetent magazines dealing with home computers, Microsoft's >> policy is to keep Fedora, and any other OSes, except for >> Microsoft OSes, off all Microsoft Certified ARM devices. >> >> Perhaps you mean that Fedora has not asked Microsoft for a signing key. > > Signing on ARM would use the same key and signing service as x86. We have > chosen not to pursue this usage due to the inability to disable Secure Boot > or install your own chain of trust on ARM given the rules they've put > forward. > >> Further questions ad ARM: According to Microsoft, can, in future, >> "SecureBoot" be disabled on Microsoft Certified ARM devices? > > On ARM client devices, no, the current requirements do not allow you to > disable Secure Boot. I don't think the behavior on server hardware is > specified yet whatsoever. > >> Will the person who walks out of the store with a Microsoft >> Certified ARM device be able to put their own signing key in? >> What about the PK? > > No, not either. > > -- >Peter Thanks very much Peter. I am sorry not to have in hand today a proper exposition of my position. Heaven forwarding, I will get one out soon. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 10:14:04AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett wrote: > > So you want Fedora to boot on all hardware sold? > > I want Red Hat, Fedora, and the free software community to come to > terms with what they must do in the context created by this new > technology. That does not mean boot on all hardware sold. Could you please give a concrete description of what you want because I have absolutely no idea what you're talking about at this point. -- Matthew Garrett | mj...@srcf.ucam.org Matthew this is near to the heart of our disagreement. That you cannot see the main issue, and its scale, makes this conversation, at certain junctures of argument, difficult. I am attempting to write something that will make the main issue clear. But here are two headers of my argument: If we do not defend the ground on which free software lives and grows, we will shortly have no free software. Part of the ground is that we need ask no permission of Microsoft, nor anybody else, to convenienetly use any services provided by the hardware, services which under your proposed plan will only be conveniently available to Microsoft. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Gerald Henriksen wrote: > On Mon, 18 Jun 2012 01:09:52 -0400 (EDT), you wrote: >On Mon, 18 Jun 2012, Matthew Garrett wrote: > >> > On Sun, Jun 17, 2012 at 11:21:14PM -0400, Jay Sulzberger wrote: >> >> > I think 50 million dollars toward buying, and properly arranging >> > the UEFI, of several lots of x86 computers would indeed solve >> > part of the problem you point out. >> > >> > Why not? >> >> Because said machines would cost more than identical hardware with >> different firmware. Sales of Linux-specific PC hardware haven't been >> massively successful so far. >> >> -- >> Matthew Garrett | mj...@srcf.ucam.org > >Why should they cost more? > >And suppose they cost $20 more. Let Red Hat pay this, and/or run >an ad campaign explaining that with this motherboard, you can >actually know what is running on the machine. So now your solution to the problem is to have Red Hat subsidize the hardware (aka lose money). That is a good way to go out of business in a hurry. >ad previous lack of success of sales of GNU/Linux machines: In >every case I know, Microsoft just bribed/threatened the vendor to >stop selling the machines. Of course it could have nothing to do with the Linux community failing to provide what the customers wanted, everything has to be a conspiracy. >If Red Hat accedes to Microsoft's demands here, there will be no, >let me repeat, no hardware that Fedora can be easily installed >on. Here is why: > >By your own explanation, you think that without the special key, >controlled by Microsoft, Fedora would be too hard for some people >to install. OK, so you agree that Fedora must get permission >from Microsoft to allow easy installs of Fedora. > >The game is now just about over. What if one day, Microsoft >makes it even harder to install Fedora without a Microsoft >controlled key? What if, as has already happened with ARM, >Microsoft refuses to grant Fedora a special key? > >No. Let Red Hat tell the truth. Let Red Hat design a better >UEFI motherboard. So now the target has moved from Red Hat buying some hardware with secure boot disabled to Red Hat hiring a design team (at signficant cost) and developing their own motherboard. Yes. That has always been part of one of my short list of suggestions. Why not? ad design team at significant cost: Yes, of course. As has been mentioned, all prototype UEFIs seen by the Red Hat team have bad interfaces. Why not make a better one? It is so nice that you are so willing to spend Red Hat's money, though I suspect the shareholders would have other ideas about entering into the world of spending lots of money to design a motherboard that you then intend to sell at a loss. Gerald, I will not respond in detail to your post. I will say two things: Red Hat, before its initial public offering, arranged to lose money, so that the company would appear more attractive to investors. By the incorrect theory of business explicit in your post, every cost borne by Red Hat, every investment made by Red Hat, must necessarily result in Red Hat going broke. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 11:14 AM, Jay Sulzberger wrote: System76 have committed to providing hardware without pre-enabled secure boot. Matthew, I am delighted to hear this. Note that this contradicts the claim, made more than once in this thread, that such an arrangement is, in practice, impossible. Not to dwell on this too much, but I think you're conflating it not being possible with it not being something /we're/ going to do. The latter has been stated; I don't think the former has been stated by anybody directly involved with the plan for supporting Secure Boot. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 12:56:54AM -0400, Jay Sulzberger wrote: > > We just need hardware we can install Fedora on, as once we did, > without asking Microsoft for permission. System76 have committed to providing hardware without pre-enabled secure boot. -- Matthew Garrett | mj...@srcf.ucam.org Matthew, I am delighted to hear this. Note that this contradicts the claim, made more than once in this thread, that such an arrangement is, in practice, impossible. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 11:03:23AM -0400, Jay Sulzberger wrote: > This I do not understand. By reports in the admittedly > incompetent magazines dealing with home computers, Microsoft's > policy is to keep Fedora, and any other OSes, except for > Microsoft OSes, off all Microsoft Certified ARM devices. I think you've answered your own question there. > Further questions ad ARM: According to Microsoft, can, in future, > "SecureBoot" be disabled on Microsoft Certified ARM devices? > Will the person who walks out of the store with a Microsoft > Certified ARM device be able to put their own signing key in? > What about the PK? No, Windows 8 ARM devices will not permit the user to install their own keys or disable secure boot. That's why we're not going to support them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 11:03 AM, Jay Sulzberger wrote: Microsoft has not refused to grant Fedora a key for ARM. This I do not understand. By reports in the admittedly incompetent magazines dealing with home computers, Microsoft's policy is to keep Fedora, and any other OSes, except for Microsoft OSes, off all Microsoft Certified ARM devices. Perhaps you mean that Fedora has not asked Microsoft for a signing key. Signing on ARM would use the same key and signing service as x86. We have chosen not to pursue this usage due to the inability to disable Secure Boot or install your own chain of trust on ARM given the rules they've put forward. Further questions ad ARM: According to Microsoft, can, in future, "SecureBoot" be disabled on Microsoft Certified ARM devices? On ARM client devices, no, the current requirements do not allow you to disable Secure Boot. I don't think the behavior on server hardware is specified yet whatsoever. Will the person who walks out of the store with a Microsoft Certified ARM device be able to put their own signing key in? What about the PK? No, not either. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 10:48 AM, Kevin Fenzi wrote: > On Mon, 18 Jun 2012 15:35:40 +0200 > > We really can't know whats going to happen down the road, we can only > act on it as we know it. LOL -- by all the signs we have available to know it. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012, Matthew Garrett wrote: On Mon, Jun 18, 2012 at 01:09:52AM -0400, Jay Sulzberger wrote: The game is now just about over. What if one day, Microsoft makes it even harder to install Fedora without a Microsoft controlled key? What if, as has already happened with ARM, Microsoft refuses to grant Fedora a special key? Microsoft has not refused to grant Fedora a key for ARM. This I do not understand. By reports in the admittedly incompetent magazines dealing with home computers, Microsoft's policy is to keep Fedora, and any other OSes, except for Microsoft OSes, off all Microsoft Certified ARM devices. Perhaps you mean that Fedora has not asked Microsoft for a signing key. Further questions ad ARM: According to Microsoft, can, in future, "SecureBoot" be disabled on Microsoft Certified ARM devices? Will the person who walks out of the store with a Microsoft Certified ARM device be able to put their own signing key in? What about the PK? Thanks, Matthew. oo--JS. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 16:27, schrieb Jared K. Smith: > On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald wrote: >> if this is what you call "development" then YES we should >> stop development now until we have ideas for real >> improvements instead wasting time by making steps backward > > Language like this isn't helpful. Might I suggest that if you're > going to make comments like this, you back them up with technical > details on how to improve the situation? you refused to understand waht i am saying if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 16:20, schrieb Richard Hughes: > On 18 June 2012 00:38, Reindl Harald wrote: >> the point is that it was perfectly possible in 2005 to make a fedora >> dist-upgrade at friday night while http, netatalk or samba was >> fully up and running until saturday sometimes at evening where >> you rebootet the machine and now EIGHT years later we discuss about >> making updates at reboot/offline like windows? > > Well, if you're running a headless server with just http, netatalk and > samba then you can of course update now live using yum, restarting > services when convenient. I'm not going to change that. boah this was changed long ago with implement a braindead "restart on update" in each fedora server-package instead define a global config-setting to disable this crap signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 15:32, Seth Vidal wrote: > As dbus is required for various things like networkmanager - does this mean > that if a server happens to be using nm for network setup that in order to > apply a security patch to dbus, for example, that the server will require a > reboot? Well, if we take down NetworkManager, then it's going to disappear from the bus and come back (hopefully) a few seconds later. Apps / daemons can cope with this by watching the name-owner-changed signals, but a *lot* of apps and services don't bother and just go boom with critical warnings when the connection changes. > Since more and more we're relying on dbus for server-y processes it feels > like we'll be adding one more component that requires a reboot for updates > to take effect. That eats up real time and causes real pain later on for > admins maintaining systems. Any self-respecting admin isn't going to be clicking hundreds of little buttons in a shell GUI on the client machines, and is probably using RHN or yum and ssh. If they're installing updates on the server itself, they probably aren't using the auto-download and click-button-in-shell method either, but yum on the command line and restarting services at the weekend. > Either we need to make dbus something we can sensibly restart or we need to > rely on it less for server-y tasks (or both). Look at the process list of the daemons we boot by default on a Fedora 17 desktop install. On my system more than half are using DBus for IPC. Using DBus "less" just isn't going to happen. > I understand you're not working on PK for servers but the packaging > expectations I don't think any expectations are changing now. There are certainly no planned changes to the Fedora packaging guidelines at all. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Sun, Jun 17, 2012 at 10:15 PM, Josh Boyer wrote: > I'm not willing to change the kernel spec file for this. > > The kernel calls 'new-kernel-pkg', which today is provided by grubby. > Despite the similar name, grubby actually works with more than just > grub and grub2. It also supports bootloaders found on other > architectures, such as yaboot, elilo, silo, zipl, and U-Boot. So, > rather than conditionalize all of this junk in the kernel spec file, > we call our nice purposeful abstraction script and whatever provides > that does the bootloader stuff for us. > > If someone wants to make something else provide 'new-kernel-pkg' and > do similar magic, great. If it's pushed into a per-bootloader thing > that would work too (though I would find it wasteful and suboptimal). > However, the abstraction grubby provides is actually _useful_ and > beneficial overall, so fixing any deficiencies because of the grub -> > grub2 transition would seem like a better idea to me. > Hmm, okay. In that case, would it be possible (or at least, a better idea) to modify *grubby* to call grub2-mkconfig when the bootloader is grub2? Then we'd still have all the other abstractions for other bootloaders but new kernel entries would be added in a way that respects the configurations in /etc/default/grub and /etc/grub.d. Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 18 Jun 2012 15:35:40 +0200 Reindl Harald wrote: > Am 18.06.2012 15:30, schrieb Seth Johnson: > > > > I stand corrected. Jay's point is that Microsoft will be in a > > position to change policy, on either platform. That could happen > > once it is in a position to do so. > > EXACTLY this is the problem > > and wre are playing them in the hands > > * NOW secure boot is optional on x86 > * we support it with the MS keys > * the next HW generation my have it mandatory > * the argument for make it mandatory may be "see, even free OS has no > problem" > > who can make sure that we get forever keys from MS? Nothing in life is sure or forever. ;) > if we take opensource and free software seriously we should not do > anything to bring MS or any other single company in a position > making us depending on their goodwill over the long I don't understand this argument, as if/when MS changed their certification (say for windows 9, as I think it's pretty much impossible for them to change the windows 8 client certification at this point), to require secure boot not be disable-able or disallow client keys to be enrolled, we could simply at that point stop signing our bootloader shim with MS'es key. This is what some would prefer we do now, but right now since you CAN disable secure boot and you CAN enroll your own keys, I think the gains in supporting secure boot outweigh the small (and easily workaroundable) loss in redistribution rights. Additionally, I can't see what MS would gain by making the above changes you posit, and in fact, it would be likely bad for them. IMHO (IANAL), if secure boot was non disableable folks would have a much better case for a class action suit. "This general purpose hardware I bought doesn't work for general purpose computing". As it is now, they could just say "disable secureboot". We really can't know whats going to happen down the road, we can only act on it as we know it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 18 Jun 2012, Richard Hughes wrote: On 18 June 2012 00:38, Reindl Harald wrote: the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? Well, if you're running a headless server with just http, netatalk and samba then you can of course update now live using yum, restarting services when convenient. I'm not going to change that. What I want to change is for the case of updating a fully functioning desktop with ~30 session processes per user talking to each other over session DBus, ~20 doing IPC with system DBus, and ~15 processes in the system context, ~3 of which do DBus IPC with each other. That's about as far removed from a simple server with three non-connected daemons that do one thing each as you can get. something must have gone terrible wrong in the meantime If your goal is to just run three simple daemons, I agree. As dbus is required for various things like networkmanager - does this mean that if a server happens to be using nm for network setup that in order to apply a security patch to dbus, for example, that the server will require a reboot? Since more and more we're relying on dbus for server-y processes it feels like we'll be adding one more component that requires a reboot for updates to take effect. That eats up real time and causes real pain later on for admins maintaining systems. Either we need to make dbus something we can sensibly restart or we need to rely on it less for server-y tasks (or both). I understand you're not working on PK for servers but the packaging expectations will trickle down to our slower-changing server installations and this will cause real pain and irritation. The implications for servers are fairly serious. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 10:21 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 10:14:04AM -0400, Seth Johnson wrote: >> On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett >> wrote: >> > So you want Fedora to boot on all hardware sold? >> >> I want Red Hat, Fedora, and the free software community to come to >> terms with what they must do in the context created by this new >> technology. That does not mean boot on all hardware sold. > > Could you please give a concrete description of what you want because I > have absolutely no idea what you're talking about at this point. I can't now. Jay would certainly engage fruitfully in a discussion based on the parameters described. I will say: A political campaign that rebukes Microsoft. A stand that does not accommodate Microsoft before we see a technical path forward and a realistic future for free software. Technically, I'll say only this for now: a UEFI that tells the truth to the user and makes things non-scary, on trustworthy hardware -- plus all the infrastructure needed to render the use of these systems viable for free software. But Jay can address these things better than I. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald wrote: > if this is what you call "development" then YES we should > stop development now until we have ideas for real > improvements instead wasting time by making steps backward Language like this isn't helpful. Might I suggest that if you're going to make comments like this, you back them up with technical details on how to improve the situation? Early in my career (when I was still doing electrical engineering), the company I was working for was big on technical design reviews". Essentially, any time you designed something, you'd get your work reviewed by a room full of engineers. The rule was that you could criticize any part of someone else's review, but if you did, you had to offer a better *realistic* alternative, and be willing to take over the design of the alternative. While I'm not suggesting we get the formal in Fedora, I am growing increasingly tired of people saying "You're doing it wrong" without offering technical details on how to come up with realistic alternatives. Also please note that I'm not just picking on you here -- your comments just happened to trigger me into taking the time to write something I've been thinking about for a while. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 10:14:04AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett wrote: > > So you want Fedora to boot on all hardware sold? > > I want Red Hat, Fedora, and the free software community to come to > terms with what they must do in the context created by this new > technology. That does not mean boot on all hardware sold. Could you please give a concrete description of what you want because I have absolutely no idea what you're talking about at this point. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 00:38, Reindl Harald wrote: > the point is that it was perfectly possible in 2005 to make a fedora > dist-upgrade at friday night while http, netatalk or samba was > fully up and running until saturday sometimes at evening where > you rebootet the machine and now EIGHT years later we discuss about > making updates at reboot/offline like windows? Well, if you're running a headless server with just http, netatalk and samba then you can of course update now live using yum, restarting services when convenient. I'm not going to change that. What I want to change is for the case of updating a fully functioning desktop with ~30 session processes per user talking to each other over session DBus, ~20 doing IPC with system DBus, and ~15 processes in the system context, ~3 of which do DBus IPC with each other. That's about as far removed from a simple server with three non-connected daemons that do one thing each as you can get. > something must have gone terrible wrong in the meantime If your goal is to just run three simple daemons, I agree. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 05:08 AM, Reindl Harald wrote: > that is not the point because every admin is dong this all the time > > the point is that it was perfectly possible in 2005 to make a fedora > dist-upgrade at friday night while http, netatalk or samba was > fully up and running until saturday sometimes at evening where > you rebootet the machine and now EIGHT years later we discuss about > making updates at reboot/offline like windows? Since admins you are referring to are not managing desktop systems, how the updates are done in desktop systems is irrelevant to them. You are free to continue using yum on them as always. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 10:10 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 10:04:38AM -0400, Seth Johnson wrote: >> On Mon, Jun 18, 2012 at 9:56 AM, Matthew Garrett wrote: >> > Ok so what you mean is "I want a UEFI implementation that doesn't >> > require a Microsoft signature to boot"? The options there are currently >> > (1) have a Fedora specific key (which we're not doing because it would >> > fragment the community) and (2) ship systems without secure boot enabled >> > by default. System76 (and possibly others) will be supplying systems >> > that provide (2), so that choice is available to you. >> >> To me. We all -- and this notably includes Red Hat -- need to work to >> make those other systems viable. That goes beyond my own choices. > > So you want Fedora to boot on all hardware sold? I want Red Hat, Fedora, and the free software community to come to terms with what they must do in the context created by this new technology. That does not mean boot on all hardware sold. Seth > There are two options > there - we can sign Fedora with the Microsoft key or we can force > Microsoft to change the Windows 8 requirements to forbid secure boot. > The second of these is impossible, which leaves signing with Microsoft. > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 10:04:38AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 9:56 AM, Matthew Garrett wrote: > > Ok so what you mean is "I want a UEFI implementation that doesn't > > require a Microsoft signature to boot"? The options there are currently > > (1) have a Fedora specific key (which we're not doing because it would > > fragment the community) and (2) ship systems without secure boot enabled > > by default. System76 (and possibly others) will be supplying systems > > that provide (2), so that choice is available to you. > > To me. We all -- and this notably includes Red Hat -- need to work to > make those other systems viable. That goes beyond my own choices. So you want Fedora to boot on all hardware sold? There are two options there - we can sign Fedora with the Microsoft key or we can force Microsoft to change the Windows 8 requirements to forbid secure boot. The second of these is impossible, which leaves signing with Microsoft. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 9:56 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 09:43:27AM -0400, Seth Johnson wrote: >> On Mon, Jun 18, 2012 at 9:37 AM, Matthew Garrett wrote: >> > Like I said before, the existing UEFI implementations on the existing >> > hardware will support "Disable Secure Boot or use your own chain of >> > trust". If you're asking for the ability to install Linux without >> > requiring signed binaries then presumably you just want a UEFI >> > implementation that doesn't enforce secure boot by default? Those exist >> > already, without needing to write a new implementation. >> >> I defer to Jay for now. It seems to me you are seeking permission >> from Microsoft or you would not be writing a shim. > > Ok so what you mean is "I want a UEFI implementation that doesn't > require a Microsoft signature to boot"? The options there are currently > (1) have a Fedora specific key (which we're not doing because it would > fragment the community) and (2) ship systems without secure boot enabled > by default. System76 (and possibly others) will be supplying systems > that provide (2), so that choice is available to you. To me. We all -- and this notably includes Red Hat -- need to work to make those other systems viable. That goes beyond my own choices. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 09:43:27AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 9:37 AM, Matthew Garrett wrote: > > Like I said before, the existing UEFI implementations on the existing > > hardware will support "Disable Secure Boot or use your own chain of > > trust". If you're asking for the ability to install Linux without > > requiring signed binaries then presumably you just want a UEFI > > implementation that doesn't enforce secure boot by default? Those exist > > already, without needing to write a new implementation. > > I defer to Jay for now. It seems to me you are seeking permission > from Microsoft or you would not be writing a shim. Ok so what you mean is "I want a UEFI implementation that doesn't require a Microsoft signature to boot"? The options there are currently (1) have a Fedora specific key (which we're not doing because it would fragment the community) and (2) ship systems without secure boot enabled by default. System76 (and possibly others) will be supplying systems that provide (2), so that choice is available to you. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Am 18.06.2012 15:30, schrieb Seth Johnson: > On Mon, Jun 18, 2012 at 9:23 AM, Matthew Garrett wrote: >> On Mon, Jun 18, 2012 at 09:20:05AM -0400, Seth Johnson wrote:> >>> It's apparently difficult to recognize Jay's argument, immediately >>> above. Jay did not say you currently cannot get an ARM key. I did >>> not present an argument in my comment. >> >> "What if, as has already happened with ARM, Microsoft refuses to grant >> Fedora a special key?" >> >> As far as I can tell, Jay did say we currently cannot get an ARM key? > > > I stand corrected. Jay's point is that Microsoft will be in a > position to change policy, on either platform. That could happen once > it is in a position to do so. EXACTLY this is the problem and wre are playing them in the hands * NOW secure boot is optional on x86 * we support it with the MS keys * the next HW generation my have it mandatory * the argument for make it mandatory may be "see, even free OS has no problem" who can make sure that we get forever keys from MS? if we take opensource and free software seriously we should not do anything to bring MS or any other single company in a position making us depending on their goodwill over the long signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
Am 18.06.2012 09:30, schrieb drago01: > On Mon, Jun 18, 2012 at 12:16 AM, Matej Cepl wrote: >> On 17/06/12 20:15, drago01 wrote: >>> >>> By that logic we could just stop development today. >> >> >> Yes, and there are places where we should. > > No. yes >> That is to stop reinventing the wheel. > > This would just result into stagnation while the competition invents > much better wheels and leave us behind. what competition damned? grub is the best example for things which did not reinvented grub1 was easy to understand and configure grub2 is simply a lot of crappy scripts, even the damned config file is a script and only 1 out of 1000 people will ever understand what this crap is supposed to do the goal of a bootloader is starting different operating systems well, grub1 has done this for many years and would also these days if some people wpuld have not decided to kill it by dependencies signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 01:09, schrieb drago01: > On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen > wrote: >> Richard Hughes writes: >> >>> It takes me 4 seconds to POST, boot the kernel, get into >>> system-update.service, and then reboot. Using a new rpm version, >>> applying several dozen test updates takes another 20 seconds. >> >> Your hardware is too cheap. BIOS boot time is proportional to price when >> the hardware was introduced. >> >> More generally, the fact that your hardware happens to boot fast does >> not mean that extra reboots are not a problem. > > If boot time is your concern we can make it (after BIOS) way faster by > simply not enable lots of stuff that sits there > unused after boot. that is not the point because every admin is dong this all the time the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? something must have gone terrible wrong in the meantime if this is what you call "development" then YES we should stop development now until we have ideas for real improvements instead wasting time by making steps backward signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 9:37 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 09:26:23AM -0400, Seth Johnson wrote: >> On Mon, Jun 18, 2012 at 8:59 AM, Matthew Garrett wrote: >> > You're still not making it clear what you want. Hardware without secure >> > boot? Hardware with secure boot but a different default policy? Hardware >> > with free firmware that may or may not have secure boot enabled by >> > default? >> >> Write a new UEFI. No need for a shim. Peter stated what the free >> software UEFI on its own hardware should support: "disable Secure Boot >> or use your own chain of trust." Plus, because you appear to be >> motivated to buy a shim for this reason, write the UEFI so it does not >> make it scary to install in any configuration you use as the empowered >> owner of the device. > > Like I said before, the existing UEFI implementations on the existing > hardware will support "Disable Secure Boot or use your own chain of > trust". If you're asking for the ability to install Linux without > requiring signed binaries then presumably you just want a UEFI > implementation that doesn't enforce secure boot by default? Those exist > already, without needing to write a new implementation. I defer to Jay for now. It seems to me you are seeking permission from Microsoft or you would not be writing a shim. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:22 PM, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing "systemctl restart libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. Restarting a daemon really means "pause, dump all in-process-stuff-to-disk, exit-cleaning-up, load-and-detect-saved-state-and-convert-if-required, un-pause" -- that's a different thing entirely to "reload". Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. Although I agree with your last statement, if you have more than one user logged in (or use fast-user-switching), the premise of a session re-login allowing all the open applications to relink against new library versions breaks down. How is the above different from restarting a computer? If you can "aggressively" reboot computer with daemons or (different user) sessions running, you can also restart (or even stop-update-start) them all with the same effect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 09:26:23AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 8:59 AM, Matthew Garrett wrote: > > You're still not making it clear what you want. Hardware without secure > > boot? Hardware with secure boot but a different default policy? Hardware > > with free firmware that may or may not have secure boot enabled by > > default? > > Write a new UEFI. No need for a shim. Peter stated what the free > software UEFI on its own hardware should support: "disable Secure Boot > or use your own chain of trust." Plus, because you appear to be > motivated to buy a shim for this reason, write the UEFI so it does not > make it scary to install in any configuration you use as the empowered > owner of the device. Like I said before, the existing UEFI implementations on the existing hardware will support "Disable Secure Boot or use your own chain of trust". If you're asking for the ability to install Linux without requiring signed binaries then presumably you just want a UEFI implementation that doesn't enforce secure boot by default? Those exist already, without needing to write a new implementation. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 09:26 AM, Seth Johnson wrote: On Mon, Jun 18, 2012 at 8:59 AM, Matthew Garrett wrote: On Mon, Jun 18, 2012 at 08:45:07AM -0400, Seth Johnson wrote: On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett wrote: The features you wanted in a free software UEFI are present in existing UEFI implementations, so I'm not sure what you're asking for. No need for a shim. Not having to ask permission. It's my understanding that you are buying a signed key so the installation of Fedora is not scary. You're still not making it clear what you want. Hardware without secure boot? Hardware with secure boot but a different default policy? Hardware with free firmware that may or may not have secure boot enabled by default? Write a new UEFI. No need for a shim. Peter stated what the free software UEFI on its own hardware should support: "disable Secure Boot or use your own chain of trust." This is what current x86 UEFI implementations give us. Plus, because you appear to be motivated to buy a shim for this reason, write the UEFI so it does not make it scary to install in any configuration you use as the empowered owner of the device. Buy a what now? shim is a piece of software Matthew has been writing. We're not talking about buying any software. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:09 AM, drago01 wrote: On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen wrote: Richard Hughes writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. If boot time is your concern we can make it (after BIOS) way faster by simply not enable lots of stuff that sits there unused after boot. Another concern is that this type of update is not always completely automatic - some users have different default options in grub like windows or different linux distro. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 9:23 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 09:20:05AM -0400, Seth Johnson wrote:> >> It's apparently difficult to recognize Jay's argument, immediately >> above. Jay did not say you currently cannot get an ARM key. I did >> not present an argument in my comment. > > "What if, as has already happened with ARM, Microsoft refuses to grant > Fedora a special key?" > > As far as I can tell, Jay did say we currently cannot get an ARM key? I stand corrected. Jay's point is that Microsoft will be in a position to change policy, on either platform. That could happen once it is in a position to do so. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 8:59 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 08:45:07AM -0400, Seth Johnson wrote: >> On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett wrote: >> > The features you wanted in a free software UEFI are present in existing >> > UEFI implementations, so I'm not sure what you're asking for. >> >> No need for a shim. Not having to ask permission. It's my >> understanding that you are buying a signed key so the installation of >> Fedora is not scary. > > You're still not making it clear what you want. Hardware without secure > boot? Hardware with secure boot but a different default policy? Hardware > with free firmware that may or may not have secure boot enabled by > default? Write a new UEFI. No need for a shim. Peter stated what the free software UEFI on its own hardware should support: "disable Secure Boot or use your own chain of trust." Plus, because you appear to be motivated to buy a shim for this reason, write the UEFI so it does not make it scary to install in any configuration you use as the empowered owner of the device. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTML-Template] Specify all dependencies
commit 89807bf61ec98140f9060862e4ab074923c5e6fa
Author: Jitka Plesnikova
Date: Mon Jun 18 14:28:46 2012 +0200
Specify all dependencies
perl-HTML-Template.spec | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-Template.spec b/perl-HTML-Template.spec
index c44084b..2b84336 100644
--- a/perl-HTML-Template.spec
+++ b/perl-HTML-Template.spec
@@ -7,11 +7,24 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/HTML-Template/
Source0:
http://www.cpan.org/authors/id/W/WO/WONKO/HTML-Template-%{version}.tar.gz
BuildArch: noarch
+
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
BuildRequires: perl(CGI)
+BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Digest::MD5)
-BuildRequires: perl(Test::More)
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(GTop)
BuildRequires: perl(IPC::SharedCache)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Storable)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%description
@@ -55,6 +68,7 @@ TEST_SHARED_MEMORY=1 make test
%changelog
* Sun Jun 17 2012 Petr Pisar - 2.91-2
- Perl 5.16 rebuild
+- Specify all dependencies
* Mon Apr 2 2012 Tom Callaway - 2.91-1
- update to 2.91
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 09:20:05AM -0400, Seth Johnson wrote:> > It's apparently difficult to recognize Jay's argument, immediately > above. Jay did not say you currently cannot get an ARM key. I did > not present an argument in my comment. "What if, as has already happened with ARM, Microsoft refuses to grant Fedora a special key?" As far as I can tell, Jay did say we currently cannot get an ARM key? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 8:54 AM, Peter Jones wrote: > On 06/18/2012 01:17 AM, Seth Johnson wrote: >> >> On Mon, Jun 18, 2012 at 1:15 AM, Matthew Garrett >> wrote: >>> >>> On Mon, Jun 18, 2012 at 01:09:52AM -0400, Jay Sulzberger wrote: Bob Young, a master of propaganda^Hsales, had a wonderful spiel in favor of free software which included the line "Why would you buy a car with the hood welded shut?". ad previous lack of success of sales of GNU/Linux machines: In every case I know, Microsoft just bribed/threatened the vendor to stop selling the machines. If Red Hat accedes to Microsoft's demands here, there will be no, let me repeat, no hardware that Fedora can be easily installed on. Here is why: By your own explanation, you think that without the special key, controlled by Microsoft, Fedora would be too hard for some people to install. OK, so you agree that Fedora must get permission from Microsoft to allow easy installs of Fedora. The game is now just about over. What if one day, Microsoft makes it even harder to install Fedora without a Microsoft controlled key? What if, as has already happened with ARM, Microsoft refuses to grant Fedora a special key? >>> >>> >>> Microsoft has not refused to grant Fedora a key for ARM. >> >> >> Oh please. > > > It's very difficult to see what your argument is from those two words. It's apparently difficult to recognize Jay's argument, immediately above. Jay did not say you currently cannot get an ARM key. I did not present an argument in my comment. > Just to be clear, and to expand on Matthew's (quoted) response, at this time > there's no reason to believe the ability to get a signed bootloader on ARM > will be any different than on x86. *We*, Matthew and I, have chosen to > extend a proposal which excludes Fedora from this process on ARM machines > due to our belief that users should have ultimate control of their systems. > That control must include replacing all of the Secure Boot keys - PK, KEK, > DB, and DBX. We don't believe we can reasonably support a Free Software > platform on machines without that functionality, and so we've opted not to > bring a proposal which would include supporting that platform. > > There's every indication that were we to so choose, Microsoft would happily > sign our binaries and allow us to boot on Secure Boot constrained ARM > machines at no additional cost. Exactly. Microsoft would happily give you permission if you ask. You recognize that this is rendering you vulnerable, as Jay said. > We believe that without the guarantee that > you can disable Secure Boot or use your own chain of trust, it isn't a > platform we can or should support. Exactly correct. Except the word "guarantee" is of equivocal meaning, potentially allowing for a course of action that renders you vulnerable. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Structure-Util] Specify all dependencies
commit 244467456f18d644024095d19ffe03dc82aede1e
Author: Jitka Plesnikova
Date: Mon Jun 18 13:58:26 2012 +0200
Specify all dependencies
perl-Data-Structure-Util.spec | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
---
diff --git a/perl-Data-Structure-Util.spec b/perl-Data-Structure-Util.spec
index aefdf90..e13102b 100644
--- a/perl-Data-Structure-Util.spec
+++ b/perl-Data-Structure-Util.spec
@@ -8,11 +8,21 @@ URL:
http://search.cpan.org/dist/Data-Structure-Util/
Source0:
http://www.cpan.org/authors/id/A/AN/ANDYA/Data-Structure-Util-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(File::Find::Rule)
-BuildRequires: perl(Devel::CheckLib)
+
+BuildRequires: perl(AutoLoader)
BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Devel::CheckLib)
BuildRequires: perl(Digest::MD5)
+BuildRequires: perl(DynaLoader)
+BuildRequires: perl(Encode)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Find::Rule)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Storable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(XML::Simple)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%description
@@ -59,6 +69,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Sun Jun 17 2012 Petr Pisar - 0.15-11
- Perl 5.16 rebuild
+- Specify all dependencies
* Thu Mar 22 2012 Tom Callaway - 0.15-10
- fix missing BR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/17/2012 06:06 PM, Richard Hughes wrote: On 17 June 2012 10:53, Richard W.M. Jones wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. It's a complete fallacy to believe you can update core libraries on a modern Linux system without rebooting. Add btrfs snapshotting to the mix (to be able to do updates safely) and doing updates in-situ becomes impossible. If Fedora wants to statically link everything, then it's certainly possible to workaround, but that's not acceptable to Fedora for perfectly understandable reasons. I wonder if it would be possible to do it on shutdown instead of during start up? I usually do not care if shutdown takes ten seconds or five minutes, but when I start my computer I do so because I want to use it and not wait several minutes before its ready. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 08:54:08AM -0400, Peter Jones wrote: > There's every indication that were we to so choose, Microsoft would happily > sign our binaries and allow us to boot on Secure Boot constrained ARM > machines at no additional cost. We believe that without the guarantee that > you can disable Secure Boot or use your own chain of trust, it isn't a > platform we can or should support. To emphasise this point - Microsoft will sign EBC objects, so it's not obvious that there's any way they *could* block a bootloader for ARM devices. We're just choosing not to. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 08:45:07AM -0400, Seth Johnson wrote: > On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett wrote: > > The features you wanted in a free software UEFI are present in existing > > UEFI implementations, so I'm not sure what you're asking for. > > No need for a shim. Not having to ask permission. It's my > understanding that you are buying a signed key so the installation of > Fedora is not scary. You're still not making it clear what you want. Hardware without secure boot? Hardware with secure boot but a different default policy? Hardware with free firmware that may or may not have secure boot enabled by default? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 01:17 AM, Seth Johnson wrote: On Mon, Jun 18, 2012 at 1:15 AM, Matthew Garrett wrote: On Mon, Jun 18, 2012 at 01:09:52AM -0400, Jay Sulzberger wrote: The game is now just about over. What if one day, Microsoft makes it even harder to install Fedora without a Microsoft controlled key? What if, as has already happened with ARM, Microsoft refuses to grant Fedora a special key? Microsoft has not refused to grant Fedora a key for ARM. Oh please. It's very difficult to see what your argument is from those two words. Just to be clear, and to expand on Matthew's (quoted) response, at this time there's no reason to believe the ability to get a signed bootloader on ARM will be any different than on x86. *We*, Matthew and I, have chosen to extend a proposal which excludes Fedora from this process on ARM machines due to our belief that users should have ultimate control of their systems. That control must include replacing all of the Secure Boot keys - PK, KEK, DB, and DBX. We don't believe we can reasonably support a Free Software platform on machines without that functionality, and so we've opted not to bring a proposal which would include supporting that platform. There's every indication that were we to so choose, Microsoft would happily sign our binaries and allow us to boot on Secure Boot constrained ARM machines at no additional cost. We believe that without the guarantee that you can disable Secure Boot or use your own chain of trust, it isn't a platform we can or should support. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 18, 2012 at 7:43 AM, Matthew Garrett wrote: > On Mon, Jun 18, 2012 at 01:47:34AM -0400, Seth Johnson wrote: >> >On Mon, Jun 18, 2012 at 1:16 AM, Seth Johnson >> >wrote: >> > I'm sorry, I really don't understand what you're suggesting here. It's >> > not possible to simply replace a system's firmware with another >> > implementation. You could chainboot from one UEFI implementation into >> > another, but if the first implements secure boot then you'd have the >> > same set of bootstrapping problems as you would with just booting an OS. >> >> >> See the fuller thread, reconstructed in nested fashion above. A free >> software UEFI would be on its own hardware. > > The features you wanted in a free software UEFI are present in existing > UEFI implementations, so I'm not sure what you're asking for. No need for a shim. Not having to ask permission. It's my understanding that you are buying a signed key so the installation of Fedora is not scary. Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 02:57:12PM +0300, Alek Paunov wrote: > However, I never tried to update qemu-system with live VMs. The update will work, but the VMs will still be running the old code. You can actually solve that problem using VM migration: live migrate the VM from the old qemu to the new qemu. Downtime should be minimal (a fraction of a second). Like a good daemon, qemu is able to serialize its internal state and reproduce it in another instance. So there is definitely a path to make this work if, for example, qemu was found to have a serious security bug. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 12:53 AM, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 11:52:48PM -0400, Jay Sulzberger wrote: So why does the "SecureBoot" private key require a so much higher cost of administration? Fedora's keys are currently only relevant on hardware where users have voluntarialy installed Fedora. If all x86 machines shipped with a Fedora key installed then our key security would be relevant to everyone, and we'd be a much more attractive target than we currently are. In addition to Matthew's point, we must keep in mind, as has previously been pointed out, that giving a Fedora (or RH) specific key to hardware vendors for them to ship would be very difficult to justify to the greater community. Instead of requiring anybody who wants to make their own linux distro for general computing pay $99, we'd be supporting a system wherein it's impossible to do so without cultivating your own relationship with every hardware vendor for years on end. This would be a catch 22, because the difficulty in establishing the market presence required before hardware vendors want to talk to you would be *significantly greater* than it is today. It would also result in a significantly fragmented compatibility matrix, as getting hardware vendors to add a key represents what they'd consider a significant expense (system flash real estate is still a critical resource), and it's most likely any vendor addoption of a new distro key would happen on an incremental basis. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
