Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 23:38 -0800, M. Edward (Ed) Borasky wrote: > On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius wrote: > > On 11/10/2012 01:30 AM, Adam Williamson wrote: > >> > >> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: > >>> > >>> Adam Williamson wrote: > > > > > >>> So, since Fedora has existed, Anaconda's memory requirements have > >>> increased > >>> by at least an order of magnitude! How's that NOT "skyrocketing"? > > > > > >> You're being pretty absurd comparing 2003 requirements to 2012 > >> requirements without allowing at all for hardware inflation. > > > > > > You seem to be missing the increasing amount of aging netbooks, laptops and > > tablets. > > > > Also you seem to be ignoring the fact of Windows XP being about to be > > discontinued, for which at least some users will be looking for a substitute > > OS, when they realize Win 8's HW requirements are too demanding for their HW > > or when they realize Win 8 doesn't meet their personal needs. > > > > Some of them certainly will consider switching to Linux, but will it be > > Fedora? Provided this discussion, my guess is no. > > > > Ralf > > Here in Portland, Oregon, "obsolete" computers end up at a recycling / > reuse outfit called FreeGeek. They do in fact rebuild them with Linux, > and IIRC it's Ubuntu. Same outfit here, and they also use Ubuntu, but it's nothing to do with system requirements, just broader hardware support through non-free drivers and the simple fact that it's the most popular desktop general-user distro. Ubuntu 12.04 cites 384MB minimum for a 32-bit install and 512MB minimum for a 64-bit install: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_requirements so they're very close to us. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius wrote: > On 11/10/2012 01:30 AM, Adam Williamson wrote: >> >> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: >>> >>> Adam Williamson wrote: > > >>> So, since Fedora has existed, Anaconda's memory requirements have >>> increased >>> by at least an order of magnitude! How's that NOT "skyrocketing"? > > >> You're being pretty absurd comparing 2003 requirements to 2012 >> requirements without allowing at all for hardware inflation. > > > You seem to be missing the increasing amount of aging netbooks, laptops and > tablets. > > Also you seem to be ignoring the fact of Windows XP being about to be > discontinued, for which at least some users will be looking for a substitute > OS, when they realize Win 8's HW requirements are too demanding for their HW > or when they realize Win 8 doesn't meet their personal needs. > > Some of them certainly will consider switching to Linux, but will it be > Fedora? Provided this discussion, my guess is no. > > Ralf Here in Portland, Oregon, "obsolete" computers end up at a recycling / reuse outfit called FreeGeek. They do in fact rebuild them with Linux, and IIRC it's Ubuntu. -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 22:17 -0800, Adam Williamson wrote: > So right now, we are doing substantially *better* at supporting old > systems than we were in 2003. Oh, god, I'm pulling a Kevin with this list spamming, but this is just too glorious not to post. I couldn't resist taking a trip in the wayback machine. Here we are in Fedoraland, 2003: https://lists.fedoraproject.org/pipermail/devel/2003-December . What do we find? Well, we find someone complaining that everything's just too bloated: https://lists.fedoraproject.org/pipermail/devel/2003-December/047891.html "curious that 3 of these 4 things have to do with reducing code footprint. I guess you can infer that either I have too much old hardware, or bloat has become an issue, or I suppose that I'm just totally off-base here" This provokes a huge thread which goes firing off in all sorts of directions, during which people including Seth Vidal and Jesse Keating have a passionate debate about exactly what ought to be included in a minimal install: https://lists.fedoraproject.org/pipermail/devel/2003-December/048318.html "Ah but the barebones system won't include yum. The absolute must include stuff will be a command line rpm capable of installing rpms from a CD or such. Barebones means barebones." The same thread - such a damn goldmine! - also features a debate about whether we really want to support all these pesky legacy systems with 386 CPUs. Bill Nottingham seems to have been firmly on my side all these years: https://lists.fedoraproject.org/pipermail/devel/2003-December/047967.html "I'm not sure that scaling back the requirements that much is something that fits the model of always moving forward with new technology." And - diving back in the thread, but I saved the very best for last - someone complaining about how damn bloated our memory requirements have gotten, and why can't they install on their perfectly good old hardware: https://lists.fedoraproject.org/pipermail/devel/2003-December/047907.html "Why must I waste min 64 megs ram on an old gateway box, I like the idea of able to bare bones install on 32 megs ram or less, i have a 486 gw box ran for years, no need to upgrade it for what it does, still runs a VERY ancient version of RH because it has 8 megs ram and nothing since rh6 will install, to put a modern OS on it i could put slackware, but why slackware, when RH should do this as it used to, a text install should use SFA as it doesnt need gui.." Well, you know, it's all about memory usage in the package installation process, as Seth points out: https://lists.fedoraproject.org/pipermail/devel/2003-December/048089.html Meanwhile, our trusty European punctuation-less shit-stirrer (sound familiar, anyone?) is still saying we suck if we can't support minimal memory installs, and we should be better than 'winbloze': https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html "But what about the main point in question, if we can do it with upto RH6, we can do it now with current slackware, so why cant we do a basic text install in fedora with piddly amount of ram, I mean, this is linux afterall, not winbloze :)" And someone is making Kevin's argument, although not accusing anyone of being the cause of environmental devastation in China: https://lists.fedoraproject.org/pipermail/devel/2003-December/047977.html "Moving technology forward doesn't HAVE to mean being in a race with memory, cpu, and disk producing companies. We want to scale small as well as large, and I'm not strictly opposed to making this available if we can figure out how to do it without making life significantly harder for us." Justin Forbes - Justin! - is around, and being as forward thinking as usual: https://lists.fedoraproject.org/pipermail/devel/2003-December/047892.html "Concurrent FC2 releases for x86_64 and i386." Fedora: plus ca change, plus c'est la meme fucking chose. And the same people, even. Truly, Ralf, Fedora is "going down the drain". This is gonna keep me amused for the next week easy. :) -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 05:12 AM, Adam Williamson wrote: But it's not_helping_ anything. It's not signal. It's just noise. I didn't say 'you need 6GB of RAM to install Fedora'. I said to Kevin 'you're comparing the minimum requirements from a time when 256MB of RAM was a standard desktop configuration to a time when 6GB is a standard desktop configuration'. Replies that just look at a number and go 'haha I have this other number!' are not helping anyone with anything. It's just more of the noise that plagues this list. Keep the wider topic in mind and make sure your arguments contribute to it. You mean like you say old hw is not relevant and all new hw has gigs of ram failing to realize that we have actually gone a full circle and now the market is filled with arm devices with small memory? How much memory did the devices we just gave to contributors in selective states and country's? Heck this spring I took an farmers laptop from 2003 which had 192 mb of ram tor out the disk because I could not install Fedora directly to it put it into another laptop that had more memory, installed Fedora LXDE ( which ran just fine once installed ) put it back in the old laptop hooked it up to an Ethernet cable ( from his home to his barn ) configured it to bootup, auto login and open a specific web page so the farmer could use his old laptop to go to the nations sheep registry and register how much each lamb weighted. He could not afford a tabled even if he could he would never have taken it in the filth in the barn, had this old laptop laying around that still worked hence it was reused to serve one specific task to make his life easier. And if memory servers me correct there were people in the community that work with refurbishing old hardware and shipping it third world country's to be reused with Fedora on it. So there is actually valid strong point in shrinking the anaconda's memory usage but you are right I dont have time to "shrink" anaconda's memory usage I doubt that you have it either and neither do the anaconda developers themselves hence no point in debating this any further and those that can help shrink anaconda's memory usage should rather spent their time on helping them or wwoods beating anaconda or fedup in usable state hence there is no point in continuing this discussion any further... JBG JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: itext 5.x
On Fri, Nov 9, 2012 at 1:26 PM, Jerry James wrote: > Does anybody know if there are licensing issues with itext 5.x? I'd like to > package some software that needs a fairly recent version of itext, but I > know we've had license issues with that package in the past. > > Also, FWIW, bouncycastle hasn't been updated because of itext > (https://bugzilla.redhat.com/show_bug.cgi?id=806262), but the most recent > version of itext, at least, requires the newest bouncycastle. Yeah, we can't have itext-5 in Fedora. Please see [1] and the references therein. We could not update bouncycastle either, lately, due to its incompatibility with itext-2. I have some patches that give partial success with building itext-2 against the latest bouncycastle API, but the build fails during the AOT bits compilation step. I am not a java programmer and I eventually gave up working on it. Meanwhile, I dropped the maintainership for both bouncycastle and itext-2 a couple months ago. To my knowledge, these packages are still up for grabs. Best, Orcan [1] http://lists.fedoraproject.org/pipermail/legal/2011-June/001653.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote: > > Look, I like a good argument as much as anyone else, but this is > > ludicrous. Are you just replying to me for the sake of scoring a point? > No. I feel Fedora is going down the drain, with the installer's demands > and Fedora's upgrade mechanisms being a major factor contributing to this. BTW, here's an interesting note on the '9 years' angle. So we know a mid-high end system in 2003 had 512MB of RAM. We know that RHL in 2003 required 128MB of RAM for graphical installation. Right now - 9 years later - we know that our current stable Fedora requires 512MB; in other words, it can still install to that mid-high end system from 2003 (a Pentium 4 with 512MB of RAM) and probably run fine, using say LXDE. Now let's rewind time to 2003. Our current stable Red Hat Linux release, RHL 9, requires 128MB of RAM for graphical installation. Can it install on a mid-high end system from 9 years ago, 1994? It's a bit hard to find references, but a post at http://www.quartertothree.com/game-talk/showthread.php?t=11638 suggests the following specs for a 'Midrange 1994' system: 40MHz Intel 486DX2 8MB RAM (whatever type was used back then) 500MB hard drive 1MB SVGA-capable graphics card 3.5" floppy drive (although I'll probably cheat and add a CD-ROM drive) Windows 3.11 That more or less accords with my memory. I recall that when Doom came out, which was in 1993, my father had recently purchased a very high-end system, which was a 33MHz 486DX with a whopping 16MB of RAM; I'm fairly sure I recall that a more standard config at that time was 4MB. So let's be generous and say that a mid-high end config in 1994 was 16MB of RAM. So could our 2003 stable release, Red Hat Linux 9, install on a system from nine years previously? It could not. It required eight times more memory than a nine year old system had. So right now, we are doing substantially *better* at supporting old systems than we were in 2003. How's that? -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote: > I am pointing out that what you are calling "9 year old" hardware is not > unlike the hardware to be found on 4-2 year old netbooks/laptops/tablets > etc. and consider ignoring this hardware to be a mistake. BTW, for the factual record, only the very first generation of the very first netbook ever created - the Eee 700-701 - had 512MB of RAM. The 702 G and then the 900 series onwards all had 1GB of RAM or more. So our current, completely unoptimized, 'bloated' anaconda in a pre-Beta build can safely and happily install on every extant netbook except the very first, famously underpowered generation. Our current stable release can install on any netbook ever shipped. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote: > > Is this really what you would like us to > > do, or are you just compulsively contradicting whatever you can? > Neither. I am simply deeply convinced that one of Linux traditional > domains and key feature had been "not being as resource demanding" as > competing OSes and that loosing it "just because that's the way it is" > is a severe long term mistake. It's a good thing that I didn't actually suggest that then, isn't it? Linux still performs far better than Windows on low resource machines. The fact that all hardware marches on over time doesn't change that. I'm running four server boxes on a VM host which has 4GB of RAM. I used to fit them in 1.5GB, and still could if I had to. I wouldn't want to try that with Windows. I'm not saying we should just design to whatever the latest Alienware state of the art box is. All I said was that Kevin was taking things to extremes by citing the requirements of a nine year old release. Unless you think Kevin's post was a perfectly sensible one and I was wrong to call BS on it... -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Once upon a time, "Jóhann B. Guðmundsson" said: > *cough* tmpfs *cough* > > Not that I have been bitten by or explicitly looking at it but depending > how close to upstream systemd Anaconda is an % percentage of that ram is > being reserved else where ;) Where is it being "reserved"? Hint: not tmpfs. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 05:36 AM, Adam Williamson wrote: On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote: On 11/10/2012 01:30 AM, Adam Williamson wrote: On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: Adam Williamson wrote: So, since Fedora has existed, Anaconda's memory requirements have increased by at least an order of magnitude! How's that NOT "skyrocketing"? You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. You seem to be missing the increasing amount of aging netbooks, laptops and tablets. Also you seem to be ignoring the fact of Windows XP being about to be discontinued, for which at least some users will be looking for a substitute OS, when they realize Win 8's HW requirements are too demanding for their HW or when they realize Win 8 doesn't meet their personal needs. Some of them certainly will consider switching to Linux, but will it be Fedora? Provided this discussion, my guess is no. Look, I like a good argument as much as anyone else, but this is ludicrous. Are you just replying to me for the sake of scoring a point? No. I feel Fedora is going down the drain, with the installer's demands and Fedora's upgrade mechanisms being a major factor contributing to this. Or are you seriously suggesting that a sensible direction for Fedora is to consider the requirements of nine year old hardware and attempt to adjust our software to match? No. I am pointing out that what you are calling "9 year old" hardware is not unlike the hardware to be found on 4-2 year old netbooks/laptops/tablets etc. and consider ignoring this hardware to be a mistake. I am also pointing out, that there is a larger group of potential future Linux users out there (Win XP users), to whom Fedora has not much to offer. Is this really what you would like us to do, or are you just compulsively contradicting whatever you can? Neither. I am simply deeply convinced that one of Linux traditional domains and key feature had been "not being as resource demanding" as competing OSes and that loosing it "just because that's the way it is" is a severe long term mistake. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Migrating old hardware
On Sat, 2012-11-10 at 06:13 +, Vincenzo Virgilio wrote: > Finally, there are a lot of people here that can choose fedora, and > many more if Anaconda will put its install memory requirement to 512 > mbyte so i can choose Xfce or Lxde without doing more tricky > workaround. > > On 22-23 of March 2013 we will organize our annual Linux Meeting, in > Palermo, you are wellcome. We made a specific effort with our current stable and supported release of Fedora, Fedora 17, to ensure it could install on systems with 512MB of RAM. It is a viable OS choice for such systems. -- 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
Migrating old hardware
Usually I'm a lurker here, but now I have two things to say, and maybe make two of you return to working with renewed responsability. First of all, i work as network manager at the University of Palermo, Italy, and we have a lug and jug named Sputnix. I spent last three years of my life pushing the migration of our desktop system to Fedora, becouse i found how make our java (oracle based) program, work. Libreoffice is our best friend for all the other things. In 2011 i was able to buy 25 new pc for our office, but i'm not to buy 45 pc in 2012. Could be we will in 2013, but right now we are using 52 old Ibm original pc built in 2004, many with 512 Mb of ram, just like the Android smartphone i'm using to write this mail. Finally in Italy the govern realized a law in August, here called Spending Review in which Free Software became the first choice for pubblic administration. to make everything work i choose Xfce on fedora and used Clonezilla to make speedy migration of machine, just 15 minutes on old Ibm, 7 minutes on new Acer. Finally, there are a lot of people here that can choose fedora, and many more if Anaconda will put its install memory requirement to 512 mbyte so i can choose Xfce or Lxde without doing more tricky workaround. On 22-23 of March 2013 we will organize our annual Linux Meeting, in Palermo, you are wellcome. Vincenzo Virgilio -- Inviato dal mio cellulare Android con K-9 Mail.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 04:56 +, "Jóhann B. Guðmundsson" wrote: > On 11/10/2012 04:46 AM, Adam Williamson wrote: > > On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote: > >> On 11/10/2012 12:30 AM, Adam Williamson wrote: > >>> You're being pretty absurd comparing 2003 requirements to 2012 > >>> requirements without allowing at all for hardware inflation. > >> My hp pavilion came out of the box with 2GB ram bought last year ago and > >> tablets and various other devices aren't that high on memory... > > That's 1.2GB more than it needs. So what's your point? We support 2GB > > devices. Just fine. We support 1GB devices. > > *cough* tmpfs *cough* > > Not that I have been bitten by or explicitly looking at it but depending > how close to upstream systemd Anaconda is an % percentage of that ram is > being reserved else where ;) dude, seriously. you of anyone should know how many install tests I run per cycle. I run most of them in a 1GB VM. I went to 2GB for alpha because debug kernels chew RAM, but I've been using 1GB ever since. I'm not throwing around numbers like 6GB because I think our installer should require 6GB of RAM, I was making a specific point to kevin. I recognize the contradiction impulse because I'm guilty of it myself too sometimes. it's fun to read a mail, see '6GB', cut out all the context and point and yell HAHA I HAVE A SYSTEM WITH 2GB SO YOU'RE WRONG! But it's not _helping_ anything. It's not signal. It's just noise. I didn't say 'you need 6GB of RAM to install Fedora'. I said to Kevin 'you're comparing the minimum requirements from a time when 256MB of RAM was a standard desktop configuration to a time when 6GB is a standard desktop configuration'. Replies that just look at a number and go 'haha I have this other number!' are not helping anyone with anything. It's just more of the noise that plagues this list. Keep the wider topic in mind and make sure your arguments contribute to it. It is also not helping to say 'hey I vaguely remember this other topic that came up which was something to do with memory so I'll make an assertion I can't actually back up'. If you think tmpfs-by-default might be affecting anaconda's memory use, you know what you can do? Go run an anaconda install, check if it actually uses a tmpfs, and check how much RAM that uses. This is not beyond your capabilities. You could do that, and report your results, and that would be signal, not noise. Saying 'oh hey but tmpfs!' is not signal, it is noise. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 04:46 AM, Adam Williamson wrote: On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote: On 11/10/2012 12:30 AM, Adam Williamson wrote: You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. My hp pavilion came out of the box with 2GB ram bought last year ago and tablets and various other devices aren't that high on memory... That's 1.2GB more than it needs. So what's your point? We support 2GB devices. Just fine. We support 1GB devices. *cough* tmpfs *cough* Not that I have been bitten by or explicitly looking at it but depending how close to upstream systemd Anaconda is an % percentage of that ram is being reserved else where ;) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 02:01 AM, Adam Williamson wrote: On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote: Adam Williamson wrote: You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. People thinking like you are the reason why entire villages in China and Africa are huge heavily-polluted landfills of electronic scrap material. Kevin manufactures today don't built hardware to last more then 3 years tops and actually the industry is moving towards to make them unfixable as well ( cheaper to jus throw it away and give you a new one ) I think Germany is actually the only country that holds high standards in that regards ( as in requiring manufactures to build appliance that lasts ) That's so stupid it barely merits a response. But I'll humour you. We improve the ability of our hardware so we can improve the ability of our software. When designing modern software it does not make sense to design to the capabilities of a Commodore PET. A PC from nine years ago really is not a terribly different case. We are not designing an OS to be used to extend the life of ancient hardware for re-use in the developing world. That is a fine goal, but it is not really Fedora's goal. Our goal includes Features and First - i.e. we are pushing the envelope of what is possible. In doing this it is clearly appropriate to target the capabilities of contemporary hardware, not hardware built before George W. Bush's second term in office began. Modern software does not use more resources than old software because it's 'bloated' or because modern coders are lazy. It just uses the greater resources available to do better stuff. This is why hardware engineers work to make more resources available in the _first_ place. We could now list all the capabilities of modern code that code from 2003 didn't have, but I really, really don't see the point. Adam You seem to be failing to realize we have gone full circle now ;) ( think arm devices ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 01:19 AM, Carl G wrote: Could you provide a link to that discussion? pick a release cycle and go through the mailinglist archives. It's one of those topics that resurface on each of them so you should not have a hard time finding something in each of them... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote: > On 11/10/2012 12:30 AM, Adam Williamson wrote: > > You're being pretty absurd comparing 2003 requirements to 2012 > > requirements without allowing at all for hardware inflation. > > My hp pavilion came out of the box with 2GB ram bought last year ago and > tablets and various other devices aren't that high on memory... That's 1.2GB more than it needs. So what's your point? We support 2GB devices. Just fine. We support 1GB devices. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 12:30 AM, Adam Williamson wrote: You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. My hp pavilion came out of the box with 2GB ram bought last year ago and tablets and various other devices aren't that high on memory... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 12:12 AM, Kevin Kofler wrote: Adam Williamson wrote: >It's not one of our supported upgrade mechanisms, and there appears to >be no chance of that changing. That's the whole problem. Why is our most reliable upgrade mechanism not "supported"? For the first QA got completely bypass in that decision if we should "officially support" upgrades in the first place but left with cleaning up that mess ( its no way we could have covered every package installed combination in the project ) when that pandora box was open, we actual have testers that do yum upgrades and report any mistakes and it's thanks to them that it works as smooth as it does and this release cycle we even discussed adjusted the criteria to cover either or ( yum upgrade/preupgrade or fedup ). The fact remains however that we cant "properly" support it until we default to btrfs and implement the ability for our userbase to fall back to an snapshot that was taken before upgrade for our users to fallback on encase shit hits the fan. ( despite whom ever made that decision to official support it ) I however neither upgrade nor recommend upgrades because I have better things to do with my time than spending hours cleaning up after the upgrades and rather choose to have my /home on separated partitions and do fresh install and reuse it once I have fixed Gnome not being able to properly handle upgrades within Gnome itself for my user account ( which takes half an hour hour tops to fix ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote: > On 11/10/2012 01:30 AM, Adam Williamson wrote: > > On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: > >> Adam Williamson wrote: > > >> So, since Fedora has existed, Anaconda's memory requirements have increased > >> by at least an order of magnitude! How's that NOT "skyrocketing"? > > > You're being pretty absurd comparing 2003 requirements to 2012 > > requirements without allowing at all for hardware inflation. > > You seem to be missing the increasing amount of aging netbooks, laptops > and tablets. > > Also you seem to be ignoring the fact of Windows XP being about to be > discontinued, for which at least some users will be looking for a > substitute OS, when they realize Win 8's HW requirements are too > demanding for their HW or when they realize Win 8 doesn't meet their > personal needs. > > Some of them certainly will consider switching to Linux, but will it be > Fedora? Provided this discussion, my guess is no. Look, I like a good argument as much as anyone else, but this is ludicrous. Are you just replying to me for the sake of scoring a point? Or are you seriously suggesting that a sensible direction for Fedora is to consider the requirements of nine year old hardware and attempt to adjust our software to match? Is this really what you would like us to do, or are you just compulsively contradicting whatever you can? Because I'm not interested in a back and forth point scoring match. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 01:30 AM, Adam Williamson wrote: On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: Adam Williamson wrote: So, since Fedora has existed, Anaconda's memory requirements have increased by at least an order of magnitude! How's that NOT "skyrocketing"? You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. You seem to be missing the increasing amount of aging netbooks, laptops and tablets. Also you seem to be ignoring the fact of Windows XP being about to be discontinued, for which at least some users will be looking for a substitute OS, when they realize Win 8's HW requirements are too demanding for their HW or when they realize Win 8 doesn't meet their personal needs. Some of them certainly will consider switching to Linux, but will it be Fedora? Provided this discussion, my guess is no. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:26:44PM -0500, Matthew Miller wrote: > This perplexing to me. In my %post section, I tried both writing > "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set > timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the > config file after doing those things. > > But on boot, grub.cfg file always contains timeout=5. Why / how is this > happening? > > I'm using appliance-creator, in case that's doing anything silly. I think appliance-creator is pretty much unsupported at this point, isn't it? livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package. livecd-creator can also make images instead of iso's so you may have better luck with that. Call image-creator instead of livecd-creator. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpVb6XVhJRDu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Matthew Miller wrote: > On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote: >> > However, I'm not sure that we can solve this kind of disconnect by a >> > process change. >> How about a general policy that planned regressions are not acceptable >> unless explicitly approved by FESCo? Any feature that you want to remove >> (temporarily or permanently) MUST be spelled out on the feature page. > > Here's the problem: if this is the requirement for a feature, then > regressions will just be done as "it's not a feature, it's just the new > version of upstream project X!" > > That doesn't buy anyone anything. But they wouldn't be able to claim a misunderstanding as now and FESCo would have a standing for requesting a reversion. Plus, in this case, Anaconda isn't an "upstream project" in the first place, we are upstream. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > You're being pretty absurd comparing 2003 requirements to 2012 > > requirements without allowing at all for hardware inflation. > > People thinking like you are the reason why entire villages in China and > Africa are huge heavily-polluted landfills of electronic scrap material. That's so stupid it barely merits a response. But I'll humour you. We improve the ability of our hardware so we can improve the ability of our software. When designing modern software it does not make sense to design to the capabilities of a Commodore PET. A PC from nine years ago really is not a terribly different case. We are not designing an OS to be used to extend the life of ancient hardware for re-use in the developing world. That is a fine goal, but it is not really Fedora's goal. Our goal includes Features and First - i.e. we are pushing the envelope of what is possible. In doing this it is clearly appropriate to target the capabilities of contemporary hardware, not hardware built before George W. Bush's second term in office began. Modern software does not use more resources than old software because it's 'bloated' or because modern coders are lazy. It just uses the greater resources available to do better stuff. This is why hardware engineers work to make more resources available in the _first_ place. We could now list all the capabilities of modern code that code from 2003 didn't have, but I really, really don't see the point. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote: > You're being pretty absurd comparing 2003 requirements to 2012 > requirements without allowing at all for hardware inflation. People thinking like you are the reason why entire villages in China and Africa are huge heavily-polluted landfills of electronic scrap material. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, 2012-11-09 at 20:39 -0500, Matthew Miller wrote: > On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote: > > it maybe doesn't actually need to be). So perhaps we should change > > firewalld to default to opening port 22. > > +1, even having read the rest of this message. > > > Same with iptables if firewalld is not installed by default. Somehow it took me 45 minutes to notice the giant logic fail in my thinking: if what we're trying to achieve is 'don't install firewalld in a minimal install', obviously firewalld's default firewall configuration is entirely irrelevant. To achieve the above, we don't need to make sure that the default configuration leaves port 22 open when firewalld is installed, but that the default configuration leaves port 22 open when firewalld is *not* installed. D'oh. We can still not bother poking the firewall configuration by default in anaconda if firewalld's package default leaves port 22 open and firewalld is being installed, which would still be a valuable simplification of what anaconda has to do and is still a sensible change, but obviously, we can't use that as a reason not to install firewalld in a minimal install. -- 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: remove polkit from core?
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: > Of course, the real question is why the heck PolicyKit needs a Turing- > complete rule language (which also forced everyone to port their existing > rules) when the previously-used simple INI-style pkla rule format did the > job just fine! Since policykit was designed from the begining to support multiple authorities, it does seems like it might have been nicer to continue to support the ini-style local authority and add the js one as an extra option. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 01:19 +, Carl G wrote: > Could you provide a link to that discussion? Oh, god, it's been dragged up at least three times that I remember. I don't really want to spend my afternoon dredging my archives to find the precise links, but I'd recommend browsing the results of the search string "yum upgrade kofler site:https://lists.fedoraproject.org/pipermail/devel/";. One result of this is https://lists.fedoraproject.org/pipermail/devel/2012-January/161819.html , which was probably the last time Kevin brought it up. If you go back further I'm sure you'll find many more. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote: > > However, I'm not sure that we can solve this kind of disconnect by a > > process change. > How about a general policy that planned regressions are not acceptable > unless explicitly approved by FESCo? Any feature that you want to remove > (temporarily or permanently) MUST be spelled out on the feature page. Here's the problem: if this is the requirement for a feature, then regressions will just be done as "it's not a feature, it's just the new version of upstream project X!" That doesn't buy anyone anything. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote: > it maybe doesn't actually need to be). So perhaps we should change > firewalld to default to opening port 22. +1, even having read the rest of this message. Same with iptables if firewalld is not installed by default. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Matthew Miller wrote: > Apparently the new version of polkit brings in javascript. The js package > is 6.5MB. I think anything that uses polkit will depend on it -- can we > remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Could you provide a link to that discussion? Thanks 2012/11/9 Adam Williamson > On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote: > > Adam Williamson wrote: > > > It's not one of our supported upgrade mechanisms, and there appears to > > > be no chance of that changing. > > > > That's the whole problem. Why is our most reliable upgrade mechanism not > > "supported"? > > > > > Please don't warm over that argument again. > > > > Why not? > > Because it's a complete and utter waste of time to keep reanimating the > argument without making any different points. You make your points > again, the other side makes its points again, nothing changes and you > have all wasted your time. Why bother? > -- > 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 > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
Kevin Fenzi wrote: > On Fri, 09 Nov 2012 20:16:50 +0100 > Roberto Ragusa wrote: > >> Serious question: why usrmove is not doable? >> If you have all the dirs in your path, and move executable files from >> one place to another, why should this fail? > > All your dynamic libraries move? If you do the move with a single C/C++ program rather than a shell script, the libraries are already loaded in memory when they move, so it wouldn't be an issue at all. Doing it with a shell script is trickier, but the UsrMove folks actually had that working (with LD_PRELOAD tricks), before it was decided that doing it in dracut was somehow "safer" (which sucks, because it makes the process much less convenient than a simple script or binary to run). > You need selinux relabling? SELinux is evil… > I have been using yum upgrades on some of my machines here for many > years, but there's often a weird broken dep or something I need to > tweak for it to work right, for example: > > * Every release there are a few packages that were removed, so when you > upgrade to the new release you have to remove them yourself. Same with the "supported" upgrade types. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 10.11.2012 01:12, schrieb Kevin Kofler: > Adam Williamson wrote: >> It's not one of our supported upgrade mechanisms, and there appears to >> be no chance of that changing. > > That's the whole problem. Why is our most reliable upgrade mechanism not > "supported"? > >> Please don't warm over that argument again. > > Why not? i too do not understand why YUM is not the primary supported method * it works much more relieable in most acses * it gives better control the arguments "after released updates you do not have a tested migration path" is invalid - two months after the release you also do NOT have a tested migration path because you got updates for the previews version - this affects preupgrade also as update with DVD with the DVD method you even have NO WAY to fix issues because the ISO images keep static and the installed OS gets updates instead waste time for preupgrade or whatever replacemanet the time could be spent for improvements in the yum upgrade-howto signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > It's not one of our supported upgrade mechanisms, and there appears to > > be no chance of that changing. > > That's the whole problem. Why is our most reliable upgrade mechanism not > "supported"? > > > Please don't warm over that argument again. > > Why not? Because it's a complete and utter waste of time to keep reanimating the argument without making any different points. You make your points again, the other side makes its points again, nothing changes and you have all wasted your time. Why bother? -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > It hasn't really 'skyrocketed'. We cited 512MB for several releases, > > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for > > F17, and it's back up to 768MB or 1GB for F18 atm because everyone has > > more important stuff to do than optimize the RAM usage right now. But > > it's not been rising crazily or anything. > > These were the numbers for RHL 9: > http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html > | Memory: > | - Minimum for text-mode: 64MB > | - Minimum for graphical: 128MB > | - Recommended for graphical: 192MB > So, since Fedora has existed, Anaconda's memory requirements have increased > by at least an order of magnitude! How's that NOT "skyrocketing"? RHL 9 came out in 2003. That's *nine years ago*. In 2003, an expensive system from Dell - cost price UKP 1314, that's nearly $2k in U.S. money - came with 512MB of RAM. http://www.trustedreviews.com/Dell-Dimension-8300-3-0GHz-Ultimate-Christmas-Bundle_Desktop-PC_review A U.S. model with 1GB of RAM cost $3,600: http://www.pcmag.com/article2/0,2817,1135791,00.asp I can't find any reviews of more modest configs on the front page of Google, but it seems reasonable to assume a 'typical' system shipped in 2003 would've had maybe 256MB-512MB of RAM. The most expensive stock config I can find from Dell today - comparable to the two systems listed above - is http://configure.us.dell.com/dellstore/config.aspx?oc=dddapy1&model_id=xps-8500&c=us&l=en&s=dhs&cs=19 (interestingly, model 8500 - has Dell had a single model line all this time?), which costs $1050 - half as much as the 2003 system, not even adjusted for inflation - and comes with 24GB of RAM. That's 48 times as much, for those keeping score at home. That blows our measly 5-or-7 times increase in RAM requirements out of the water. We appear to be effectively reducing our memory requirements over time, considered as a percentage of the typical RAM allocation of an off-the-shelf system. Even a more modest 'typical' Dell desktop - https://www.dell.com/us/p/inspiron-660/pd - comes with 6GB at the most basic configuration (comparable to 256MB for a 2003 basic desktop, I'd guess - so a 24x ratio), or 8GB (32x ratio) at a moderate config (only $599). You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Miloslav Trmač wrote: > However, I'm not sure that we can solve this kind of disconnect by a > process change. How about a general policy that planned regressions are not acceptable unless explicitly approved by FESCo? Any feature that you want to remove (temporarily or permanently) MUST be spelled out on the feature page. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
Am 09.11.2012 23:57, schrieb drago01: > On Fri, Nov 9, 2012 at 10:23 PM, Reindl Harald wrote: >> >> >> Am 09.11.2012 22:14, schrieb Kevin Fenzi: >>> I think the thing people are missing here is that yum dist upgrades are >>> perfectly fine for advanced users who know how to work around problems >>> and use the tools, but aren't very good for well, everyone else. >> >> yes and no >> >> one real benefit of the yum upgrade is that you get >> the latest updates which are often fixing many bugs >> realized AFTER the release > > So do upgrades done with preupgrade and fedup preupgrade is a blackbox and failed at the one try resulting after retry it only have preupgrade in the boot-menu - this day i learned how to write grub-config by hand and it was the last time touch preupgrade additionally you have NO way to verify grub-config, initramdisk ect. at all becasue you have no control like you have after a yum-upgrade where you can do any cleanups before reboot last but not least: on servers it is unusebale to run a upgrade OFFLINE after 160 upgrades on production servers and around 300 on test-systems the last few years i really do not need anybody explain me again that fedora is not for servers - i know what i am doing, i do not suggest anybody should use it for this, i only suggest "please keep in mind that there is a userbase which is happy and having the knowledge to deal with yum dist-upgrades, please do not break it in future releases" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote: > It's not one of our supported upgrade mechanisms, and there appears to > be no chance of that changing. That's the whole problem. Why is our most reliable upgrade mechanism not "supported"? > Please don't warm over that argument again. Why not? > The messaging and optics of saying 'yum is a supported upgrade mechanism, > but just for F18 beta! We'll have a new mechanism for F18 final! Which > won't have been tested much at all! And yum will be evil again! So use it > now! But don't use it again ever!' really suck. Which is why no-one wants > to do it. Which is why we shouldn't do it. Instead, we should say that yum is the supported upgrade mechanism for F18 (postponing fedup to F19 or releasing it as a tech preview for F18 depending on how things go) and that it will remain a supported alternative in the future if it works out. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Toshio Kuratomi wrote: > Being stricter about having viable contingency plans for features like > this (ones that require coordination and can potentially block us if they > aren't done/done correctly) is one possible way to address this type of > situation in the future. And it's the right way. I'd go as far as saying that features with no (viable) contingency plan should be blanket-rejected. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote: > It hasn't really 'skyrocketed'. We cited 512MB for several releases, > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for > F17, and it's back up to 768MB or 1GB for F18 atm because everyone has > more important stuff to do than optimize the RAM usage right now. But > it's not been rising crazily or anything. These were the numbers for RHL 9: http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html | Memory: | - Minimum for text-mode: 64MB | - Minimum for graphical: 128MB | - Recommended for graphical: 192MB So, since Fedora has existed, Anaconda's memory requirements have increased by at least an order of magnitude! How's that NOT "skyrocketing"? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network interface renaming, where does INTERFACE_NAME get applied?
On Fri, 09.11.12 11:42, Daniel Drake (d...@laptop.org) wrote:
> Hi Bill
>
> I see that initscripts in F18 ships this udev rule:
>
> ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
> RESULT=="?*", ENV{INTERFACE_NAME}="$result"
>
> I'm trying to tackle some problems related to interface renaming, and
> understanding how this works would be useful.
>
> But I can't find which software component *applies* the INTERFACE_NAME
> variable set by the above rule, actually performing the interface
> rename. Can you explain?
>
> FYI, I would imagine this area will also be susceptible to a current
> udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
IIRC support INTERFACE_NAME is gone for quite a while since udev stopped
to provide implicit permenanet naming since it was a trainwreck. People
should use biosdevname instead.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 10.11.12 00:12, Paolo Bonzini (pbonz...@redhat.com) wrote: > > Il 09/11/2012 18:26, Lennart Poettering ha scritto: > > 1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org) > > wrote: > > > >> On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: > >>> deserved. Just today I made a minor fix to systemd git to deal nicely > >>> with PK-less systems. > >> > >> Right now, I get: > >> > >> $ reboot > >> Failed to issue method call: The name org.freedesktop.PolicyKit1 was not > >> provided by any .service files > >> Must be root. > >> > >> Which is fine except that I don't want to see the message. :) Does your fix > >> handle this or should I bug report? > > > > Yes, that's the one that should be fixed with this: > > > > http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e000255d07f6b3cc777f15b > > > > Would probably make sense to test things with this applied as it should > > solve most (but probably not all) issues related to PK-less systems. > > Isn't that the other way round? It fixes problems with uid=0, but > Matthew is testing with uid!=0. Ah, right. Yeah. In that case the code already does the right thing, except that the error message is a bit misleading. It kinda suggests that PK was needed, but actually it just means "I denied because you weren't root, and you can't get permission without PK either". I'll make sure the error message is corrected to just become a normal authentication denied message Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, 2012-11-09 at 15:06 -0800, Adam Williamson wrote: > Right now it seems like anaconda actually just throws firewalld into the > target package set in absolutely all cases, like it does with > authconfig, which I think is wrong. As the above makes clear, it only > really makes sense to use anaconda's mechanism for adding packages to > the to-be-installed set when they may or may not need to be installed > depending on the path taken through installation. If we really want > these to be in all installs, unconditionally, we should just put them in > the @core group in comps. For authconfig, this may be the correct way to > go. But for firewalld, it seems to me that so far as anaconda is > concerned, it only needs to go into the installed system if the user has > requested firewall configuration as part of the install, which I don't > believe is the default and in fact is only available through kickstarts > (so it's probably an uncommon case). It should be made conditional in > anaconda, anaconda should not be forcing it into the to-be-installed > package set in all cases. > > We already have firewalld in the 'standard' set in comps, which seems > like about the right place for it - it'll be in most installs, but not > minimal ones, if anaconda gets fixed up. So I just followed this up in IRC. It turns out that right now, anaconda always (or at least by default) *does* touch the firewall: it opens up port 22. So that's why firewalld is getting added to the to-be-installed package set unconditionally. Given the current behaviour, that's correct. However, it seems like somewhat silly behaviour. If our default firewall configuration is supposed to be 'port 22 open' we should express that in our firewall package, not set a default in the firewall package then have the installer change it. That's just needless complexity (and results in the problem of firewalld being in the minimal install, where it maybe doesn't actually need to be). So perhaps we should change firewalld to default to opening port 22. Jesse points out that this kind of discussion usually gets derailed in spectacularly unhelpful directions: right this usually gets us into an argument with the "community" and people suggesting, then arguing against, packages shipping their own firewall config so whether ssh is open or not depends on if you install ssh then somebody mentions German privacy laws and the whole thread goes nowhere. So if you're going to follow up on this - there are fun discussions to be had about the pros and cons of letting packages ship firewall configs, but please don't do it in this thread, start a new one if you must. Having firewalld ship a 'port 22 open' default may not be the best way to do things in the best of all possible worlds, but it is at least _more_ sensible than having the installer set the default firewall policy. And for the love of God, please don't bring up German privacy laws. -- 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: Attention, dependency fighters
On Fri, 2012-11-09 at 07:12 -0500, Matthias Clasen wrote: > On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote: > > > FYI, re: firewalld & minimal install. > > > > firewalld isn't in the minimal comps groups. However, it's pulled in > > by anaconda, see pyanaconda/install.py: > > > > # anaconda requires storage packages in order to make sure the target > > # system is bootable and configurable, and some other packages in order > > # to finish setting up the system. > > packages = storage.packages + ["authconfig", "firewalld"] > > Why do anaconda dependencies end up in the minimal install ? That > shouldn't really be necessary, right ? It has always bugged me the we > end up with anaconda on the installed system when installing from a live > cd. This is a different thing. It's a somewhat complex area, actually. We have: * things that anaconda needs in its own environment * things that anaconda needs or *may* need in the installed system Things that anaconda needs in its own environment are specified as dependencies of the anaconda package, generally. These are not transferred to the installed system as a matter of course. If you install from DVD or netinst, you don't get the anaconda package or any of its dependencies installed. This only happens when you install from live, simply because of how live installs work: they take the live environment and image it to the target system's hard disk. You need anaconda to be in the live image to do the install, obviously, so it also winds up in the installed system. When doing a live install anaconda can tweak the installed system after writing it, so I think it'd be theoretically possible for someone to contribute a bit for anaconda's post-install code that would remove the anaconda package and its dependencies after the installed system has been written, but someone needs to write that code. I may be missing some reason why this is impossible, in which case someone on the anaconda team will surely let us know. Moving on, we have things that anaconda actually knows need to be in the deployed package set - either always, or sometimes. firewalld is one of these. This is a different case to the 'why is anaconda on my installed system' case, these things are actually being intentionally put into the installed system. There is a comps group named 'anaconda-tools' which lists all these. The DVD compose pulls this group so anaconda will definitely have them available to add to the to-be-installed package set if necessary. Most live spins also include them for the same reason, though I think the minimal spin (and therefore SoaS, which is based on minimal) doesn't include the group but instead specifies just a few of the packages directly; this means that live spins based on the minimal spin are actually lacking some capabilities. Not all these packages actually get installed in all cases, however. anaconda internally maintains a list of the packages it thinks need to _actually_ get added to the to-be-installed package set, and throws things onto the list according to circumstances. So if you're doing an x86 BIOS install, it adds 'grub2' to the list; if you're doing an x86 EFI install, it adds 'grub2-efi' to the list; if you're doing a PPC or s390 install, it'd add a different bootloader. If you're doing a multipath install, it adds device-mapper-multipath to the list. And so on. Right now it seems like anaconda actually just throws firewalld into the target package set in absolutely all cases, like it does with authconfig, which I think is wrong. As the above makes clear, it only really makes sense to use anaconda's mechanism for adding packages to the to-be-installed set when they may or may not need to be installed depending on the path taken through installation. If we really want these to be in all installs, unconditionally, we should just put them in the @core group in comps. For authconfig, this may be the correct way to go. But for firewalld, it seems to me that so far as anaconda is concerned, it only needs to go into the installed system if the user has requested firewall configuration as part of the install, which I don't believe is the default and in fact is only available through kickstarts (so it's probably an uncommon case). It should be made conditional in anaconda, anaconda should not be forcing it into the to-be-installed package set in all cases. We already have firewalld in the 'standard' set in comps, which seems like about the right place for it - it'll be in most installs, but not minimal ones, if anaconda gets fixed up. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 19:45 GMT, Jesse Keating wrote: > I don't think I'm necessarily disagreeing with you. I don't think > anybody on the Anaconda team is happy with the current memory usage. > That said, we've had very very very little time to pursue fixing this > particular issue. I said in my first post in this thread that I completely understand that anaconda team is busy with something more important. Just to make it clear. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On Fri, Nov 9, 2012 at 10:23 PM, Reindl Harald wrote: > > > Am 09.11.2012 22:14, schrieb Kevin Fenzi: >> I think the thing people are missing here is that yum dist upgrades are >> perfectly fine for advanced users who know how to work around problems >> and use the tools, but aren't very good for well, everyone else. > > yes and no > > one real benefit of the yum upgrade is that you get > the latest updates which are often fixing many bugs > realized AFTER the release So do upgrades done with preupgrade and fedup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On Fri, 2012-11-09 at 14:14 -0700, Kevin Fenzi wrote: > On Fri, 09 Nov 2012 20:16:50 +0100 > Roberto Ragusa wrote: > > > Serious question: why usrmove is not doable? > > If you have all the dirs in your path, and move executable files from > > one place to another, why should this fail? > > All your dynamic libraries move? You need selinux relabling? > > > I managed to do a 32 bit -> 64 bit transition (you know, the > > "absolutely unsupported" upgrade) on a system which was running an > > entire KDE session. My upgrade commands (rpm, yum, bash, everything > > else) started 32 bit, then were mixed, then ended to be 64 bit. > > Usrmove appears simpler. Am I missing something? > > Would you advise all your friends to do one too? :) > > I think the thing people are missing here is that yum dist upgrades are > perfectly fine for advanced users who know how to work around problems > and use the tools, but aren't very good for well, everyone else. > So, please try and think beyond your personal experiences and out to > all our users? I think having the option of a yum dist-upgrade is > excellent, but I don't think we should officially support it or ask > all our users to do it. I pretty much agree with this, and would go further to say I don't quite see the use case for such a script. I think the kinds of people who ought to be doing yum upgrades are probably going to be happier knowing what each step of the process is going to be, rather than just firing off a Magic Script. I upgrade all my systems using yum all the time, following the instructions on the wiki page, and I'm quite happy with that and would not use a script to do it. But that's just my $0.02 :) -- 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: yum upgrade from F17 to F18
Am 09.11.2012 22:14, schrieb Kevin Fenzi: > I think the thing people are missing here is that yum dist upgrades are > perfectly fine for advanced users who know how to work around problems > and use the tools, but aren't very good for well, everyone else. yes and no one real benefit of the yum upgrade is that you get the latest updates which are often fixing many bugs realized AFTER the release depending on the hardware/software-combination they may save you while the release version would not boot at all on your hardware that said: "officially supported" is the one thing but keep in mind that it is very important for advanced users to have it working so whatever features are coming in future releases: keep in mind the yum-upgrade with a howto for special steps is needed for many users and setups or you would lose the users at all because they can simply not reinstall/re-configure 10,20,30,40 fedora instances twice each year while i am as exmaple did any fedora upgrade since FC3 with YUM on a lot of setups signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:21 PM, Adam Williamson wrote: We just just have feature submission deadline, feature approval >deadline, then we work on approved features until they are done and then >give releng/marketing x time to prepare for release. that means we can >have 5 month release cycle or 7 or 9 month release cycle which gives us >the flexibility to integrate features properly into the release before >delivering into the hands of our end users and we don't have to worry >about "contingency plans" anymore Well, both models have been in use in the software industry for decades, and there are generally agreed pros and cons to both. The biggest cons of feature-based schedules are that the release cycles tend to get longer and longer because no-one feels any urgency to ship and instead just start packing in more and more features, and that users don't have a reliable schedule to follow in planning their deployments. Of course, if we delay our supposedly-time-based-releases too much and too often, we can wind up with all the cons of both approaches and none of the pros... I'm pretty sure we can bring fourth the whip if that turns out to be the case or simply say that an release can be no longer then X months or a full year and the only one way we can find out is to take the leap for 3 releases and if feature-based release is not the case we scrap it and return back to the time-based one or merge the experience from both and come up with some kind of hybrid between both of these JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 21:11 +, "Jóhann B. Guðmundsson" wrote: > On 11/09/2012 05:35 PM, Toshio Kuratomi wrote: > > On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: > >> As far as Anaconda reverted in the future, I'm confused as to > >> when/where this became a requirement. > >> > > I think he's saying this because: > > > > 1) Features have a section for contingency plans. > > 2) In this particular case, we're slipping schedule because the NewUI > > feature has a point where there stopped being a contingency plan. We > > passed that point before being aware of all of these issues that need to > > be fixed in order to release Fedora. > > > > Being stricter about having viable contingency plans for features like > > this (ones that require coordination and can potentially block us if they > > aren't done/done correctly) is one possible way to address this type of > > situation in the future. > > > > Others are to alter the "time-based" release philosophy for certain > > features (We are going to have Feature X in Fedora 19. If it isn't ready, > > we're going to slip the release date until it is done.) To only let in > > a feature with no contingency plan only when it is code complete and can be > > evaluated outside of the Fedora tree first (anaconda devs state that they do > > not actually have the manpower to implement this style of solution). > > > > -Toshio > > > > - Note: I considered adding "have a longer release cycle" to the list of > >alternatives but it's not clear that we wouldn't still get into this > >situation (FESCo/releng/QA finding out at beta freeze that Feature X > > lacks > >certain capabilities that are considered essential while the team > >responsible for the feature had considered that it was something that > >could safely be put off until the next release. Being unable to revert > >the feature at that point and so having to code the missing capabilities > >on a rushed schedule at that point.) > > Actually the more I think about it the more I come to the conclusion > that "time-based" release is not the right way for the project but a > "feature-based" release is. > > We just just have feature submission deadline, feature approval > deadline, then we work on approved features until they are done and then > give releng/marketing x time to prepare for release. that means we can > have 5 month release cycle or 7 or 9 month release cycle which gives us > the flexibility to integrate features properly into the release before > delivering into the hands of our end users and we don't have to worry > about "contingency plans" anymore Well, both models have been in use in the software industry for decades, and there are generally agreed pros and cons to both. The biggest cons of feature-based schedules are that the release cycles tend to get longer and longer because no-one feels any urgency to ship and instead just start packing in more and more features, and that users don't have a reliable schedule to follow in planning their deployments. Of course, if we delay our supposedly-time-based-releases too much and too often, we can wind up with all the cons of both approaches and none of the pros... -- 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: yum upgrade from F17 to F18
Juan Rodriguez writes: > I did it on a live system, too. The only thing that failed during that time > was postgres (Which managed to stay borked after it was done and f18 > booted, the pg_upgrade method didn't work properly) BZ? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On Fri, 09 Nov 2012 20:16:50 +0100 Roberto Ragusa wrote: > Serious question: why usrmove is not doable? > If you have all the dirs in your path, and move executable files from > one place to another, why should this fail? All your dynamic libraries move? You need selinux relabling? > I managed to do a 32 bit -> 64 bit transition (you know, the > "absolutely unsupported" upgrade) on a system which was running an > entire KDE session. My upgrade commands (rpm, yum, bash, everything > else) started 32 bit, then were mixed, then ended to be 64 bit. > Usrmove appears simpler. Am I missing something? Would you advise all your friends to do one too? :) I think the thing people are missing here is that yum dist upgrades are perfectly fine for advanced users who know how to work around problems and use the tools, but aren't very good for well, everyone else. I have been using yum upgrades on some of my machines here for many years, but there's often a weird broken dep or something I need to tweak for it to work right, for example: * Every release there are a few packages that were removed, so when you upgrade to the new release you have to remove them yourself. * The Fedora release that switched to grub2 meant you had to re-install grub, and in the case of /boot on raid, had to repartition it to allow enough space for grub2 to fit. (I managed to do this fine, but I don't think many people would have wanted to). * The display manager re-work meant to you needed to set which DM you wanted etc. Many of these things are covered by the yum upgrade wiki page, but this is not a process many of our users will want to muck with. So, please try and think beyond your personal experiences and out to all our users? I think having the option of a yum dist-upgrade is excellent, but I don't think we should officially support it or ask all our users to do it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 12:33 -0800, Jesse Keating wrote: > On 11/09/2012 12:24 PM, Adam Williamson wrote: > > On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote: > > > >>> But if we continue to look at minimal install which post-install > >>> configuration files is Anaconda explicitly touching? > >> > >> root auth and firewall config are the main ones. Note that we don't > >> have any UI for firewall config either, so not really a lot of code > >> duplication. > > > > Also bootloader configuration and network configuration, no? > > > > Network yes. Bootloader config isn't necessarily something you can > delay until after the install :) Sorry, I may have lost some context. I thought the question was just 'what does anaconda touch', not 'what does anaconda touch that we could possibly move to post-install'. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:35 PM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the "time-based" release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding "have a longer release cycle" to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) Actually the more I think about it the more I come to the conclusion that "time-based" release is not the right way for the project but a "feature-based" release is. We just just have feature submission deadline, feature approval deadline, then we work on approved features until they are done and then give releng/marketing x time to prepare for release. that means we can have 5 month release cycle or 7 or 9 month release cycle which gives us the flexibility to integrate features properly into the release before delivering into the hands of our end users and we don't have to worry about "contingency plans" anymore JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
I can't comment on UsrMove because I'm quite unfamiliar with it, but I did manage to upgrade from f17 to f18 using the totally unsupported yum update --releasever --enablerepo="*testing" --nogpgcheck method. Computer booted and everything's exactly as it used to (Though I did have to remove some packages like Calibre because of file conflicts, no big deal). I did it on a live system, too. The only thing that failed during that time was postgres (Which managed to stay borked after it was done and f18 booted, the pg_upgrade method didn't work properly) but other than that and a much more responsive KDE, I can't see any side effects to this method. YMMV, -Nushio On Fri, Nov 9, 2012 at 1:16 PM, Roberto Ragusa wrote: > On 11/09/2012 10:19 AM, drago01 wrote: > > On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý > wrote: > >> On 11/08/2012 03:10 PM, Roberto Ragusa wrote: > >>> > >>> Hmm, I now see there is a "set -e" at the beginning. > >>> Still a little scary.:-) > >> > >> > >> Scary is only the idea. And only because we are not used to do rolling > >> upgrades. Ask somebody from Debian experiance if this is scary ;) > > > > There are some upgrade tasks that you simply cannot do from within a > > running system (ex: usermove). > > Serious question: why usrmove is not doable? > If you have all the dirs in your path, and move executable files from one > place to another, why should this fail? > > I managed to do a 32 bit -> 64 bit transition (you know, the "absolutely > unsupported" upgrade) on a system which was running an entire KDE session. > My upgrade commands (rpm, yum, bash, everything else) started 32 bit, > then were mixed, then ended to be 64 bit. > Usrmove appears simpler. Am I missing something? > > -- >Roberto Ragusamail at robertoragusa.it > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 12:05 PM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote: On 11/08/2012 11:31 AM, Adam Williamson wrote: Yes. This is_absolutely_ a feature. A complete rewrite of a core and non-optional component cannot be done ad hoc without planning. One blindingly obvious reason for this in the current situation is that we're still thrashing around trying to figure out how to build and ship the initramfs that fedup needs. This is exactly the kind of thing that needs to go through the feature process so that the relevant groups - releng, infra - know about it. I don't believe they even knew about the problem until about two weeks ago. I think the unfortunate thing here is that we're trying to use "Feature" to handle cross team coordination. Why unfortunate? That is one of the two issues the Feature Process was created to address. If it's unfortunate because the two issues the feature process attempts to solve don't really have as much in common as once thought, that's cool and probably the number one thing that everyone would like to fix -- I'm just checking that you don't have some other idea in mind. Don't have anything else in mind. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote: > > But if we continue to look at minimal install which post-install > > configuration files is Anaconda explicitly touching? > > root auth and firewall config are the main ones. Note that we don't > have any UI for firewall config either, so not really a lot of code > duplication. Also bootloader configuration and network configuration, no? -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:35 -0800, Jesse Keating wrote: > On 11/08/2012 11:31 AM, Adam Williamson wrote: > > Yes. This is_absolutely_ a feature. A complete rewrite of a core and > > non-optional component cannot be done ad hoc without planning. One > > blindingly obvious reason for this in the current situation is that > > we're still thrashing around trying to figure out how to build and ship > > the initramfs that fedup needs. This is exactly the kind of thing that > > needs to go through the feature process so that the relevant groups - > > releng, infra - know about it. I don't believe they even knew about the > > problem until about two weeks ago. > > I think the unfortunate thing here is that we're trying to use "Feature" > to handle cross team coordination. It may not be the best possible system, but I'm fairly confident it would have worked better than what we actually did. Which, for fedup, appears to have been 'nothing'. Until Tim started trying to actually test fedup, I believe there had no attempt by any party to consider what work other parties might have to do to make fedup fly. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 14:47 +, Matthew Garrett wrote: > On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote: > > > Aside from that - I can understand your frustration that you think > > people are chinwagging and not helping, but my point is kind of that you > > (anaconda team) have brought that on yourselves. > > I'm not on the Anaconda team. That's my point. When bugs threaten the > release of the distribution then *everyone* involved in the distribution > should be willing to work on them, not just insist that it's up to the > developers currently working on it. I've just spent two days of vacation > working on this because it's clear that more developer contribution > would be useful and because I actually want us to release Fedora 18. > We're not obliged to sit here pointing at a sinking ship when we could > do something to avoid that ship from sinking. Correction accepted - I tend to think of you as an honorary member because you always pop up in #anaconda :) But my point stands too: there would have been much more co-operation and contribution if fedup had gone through the feature process correctly, as that is one thing the feature process achieves. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote: > On 11/08/2012 11:31 AM, Adam Williamson wrote: > >Yes. This is_absolutely_ a feature. A complete rewrite of a core and > >non-optional component cannot be done ad hoc without planning. One > >blindingly obvious reason for this in the current situation is that > >we're still thrashing around trying to figure out how to build and ship > >the initramfs that fedup needs. This is exactly the kind of thing that > >needs to go through the feature process so that the relevant groups - > >releng, infra - know about it. I don't believe they even knew about the > >problem until about two weeks ago. > > I think the unfortunate thing here is that we're trying to use > "Feature" to handle cross team coordination. > Why unfortunate? That is one of the two issues the Feature Process was created to address. If it's unfortunate because the two issues the feature process attempts to solve don't really have as much in common as once thought, that's cool and probably the number one thing that everyone would like to fix -- I'm just checking that you don't have some other idea in mind. -Toshio pgpddXPKmjxMr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 11:32 AM, Matej Cepl wrote: On 2012-11-09, 17:06 GMT, Jesse Keating wrote: Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. Right, that looks possible. I still wonder why installer needs MORE memory than running server with couple of servers, Apache, MySQL, and some application servers (Zarafa, Status.net, dspam, wordpress)? But following in this argument would probably require more detailed analysis than I am willing and able to provide, so let me close this argument here. Matěj I don't think I'm necessarily disagreeing with you. I don't think anybody on the Anaconda team is happy with the current memory usage. That said, we've had very very very little time to pursue fixing this particular issue. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:15 GMT, Peter Jones wrote: > The installer's memory footprint is largely bound by the size of the > package set. So, for example, a yum "upgrade" will take more ram - > because there are effectively twice as many packages involved. I see that. Couldn’t be there a way how to somehow overcome this problem? Just a bit of brainstorming, don’t shoot me too much for being silly. a) it could be that anaconda could just provide some kind of profiles instead of exact selection of individual packages and the lists of required packages for such profiles could be then precompiled in advance and provided on the installation medium (and for kickstart you could precompile it on a separate machine)? b) installation could be done just from a limited set of packages (something similar to what we used to have in Fedora Core, for example) and the final installation of packages would be done post-installation from the full set? We do that effectively with LiveCD installations anyway, don’t we? Well, at least mostly ... certainly people can download additional packages from Internet. Do users do that or do they typically install just what’s on CD/USB? Do people typically do detailed selection of packages (including obscure ones) in anaconda, or do they do (what I do, so I am biased) detailed final selection of packages on the already installed system? > Actually, yeah, when you question our competence and the utility of > what we're doing, that is a bit offensive. Did I say a word about your competence? I really didn’t mean to do that. For one, I am quite sure that you are way better programmers than I am, so I have not much to say about anybody’s competence. I just wondered (and I still wonder a little, see above) about the necessity of using 2-4 times more RAM for what me (yes, that could be part of the problem, I don’t need/use most of the advanced/enterprise functionality in anaconda) seems like doing exactly the same as before. From the user’s point of view, it is just cost/benefit ratio ... what I've got for the cost of increased hardware requirements. But yes, it could be because I just don’t need advanced functionality. So I was just trying to get to the bottom of it. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:06 GMT, Jesse Keating wrote: > Because anaconda links into a large amount of runtime stuff, that > normally runs isloated and so it /looks/ like our memory usage is > balooned, when in reality the entire system has balooned, we're just > getting the blame. Right, that looks possible. I still wonder why installer needs MORE memory than running server with couple of servers, Apache, MySQL, and some application servers (Zarafa, Status.net, dspam, wordpress)? But following in this argument would probably require more detailed analysis than I am willing and able to provide, so let me close this argument here. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 09.11.2012 19:08, schrieb Jesse Keating: > On 11/09/2012 09:57 AM, Panu Matilainen wrote: >> >> Except that rpm (and yum) use a lot LESS memory these days than they did >> in the RHEL-5 era, which I think was used as a comparison here. That's >> not where all the memory has gone, quite the contrary. > > While that may be true, the amount of ram (free -m) used during an install > *triples* when we get to the desolve and > package install phase. In my most recent test the "used" number went from > roughly 550m just before the packages > step to 1645 during NO i did a lot of yum-upgrades F16->F17 in the last weeks on a lot of VM's with exactly 512 MB RAM without any single problem so no, there is no reason anaconda needs more ressources because all of this machines was full operating while the upgrade was running (httpd, mysqld, asterisk, hlyfax) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 11/09/2012 10:19 AM, drago01 wrote: > On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý wrote: >> On 11/08/2012 03:10 PM, Roberto Ragusa wrote: >>> >>> Hmm, I now see there is a "set -e" at the beginning. >>> Still a little scary.:-) >> >> >> Scary is only the idea. And only because we are not used to do rolling >> upgrades. Ask somebody from Debian experiance if this is scary ;) > > There are some upgrade tasks that you simply cannot do from within a > running system (ex: usermove). Serious question: why usrmove is not doable? If you have all the dirs in your path, and move executable files from one place to another, why should this fail? I managed to do a 32 bit -> 64 bit transition (you know, the "absolutely unsupported" upgrade) on a system which was running an entire KDE session. My upgrade commands (rpm, yum, bash, everything else) started 32 bit, then were mixed, then ended to be 64 bit. Usrmove appears simpler. Am I missing something? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote: Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator I've got https://github.com/katzj/ami-creator :) Jeremy's is older last time I checked - the one from euca is modified by andy grimm and, well, works and stuff. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Am 09.11.2012 17:45, schrieb Thomas Woerner: > On 11/09/2012 05:24 PM, Eric H. Christensen wrote: > Please have a look at the feature list for F-18. > > firewalld replaces system-config-firewall/lokkit, and the iptables and > ip6tables services, not the iptables package > and command. > > The ip*tables services and also system-config-firewall/lokkit are still > available and also usable after > deactivation of the firewalld serice. With the latest request to move the > services of iptables and ip6tables in a > sub package, I will add a requirement to system-config-firewall for this PLEASE do not "Require: system-config-firewall" this would pull useless dependencies what we (users) really need is "iptables.service" as it was and working "/sbin/iptables-save > /etc/sysconfig/iptables" to lod the with whatever shell script generated "/etc/sysconfig/iptables" so satisfy over many years perfect working setups for (the same for iptables6.service) * firewalls * NAT * routing as example i have a large shellscript with the following start $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -F $IPTABLES -X CHAINS=`cat /proc/net/ip_tables_names 2>/dev/null` for i in $CHAINS; do $IPTABLES -t $i -F; done && echo "Flush OK" || echo "Flush FAILED" for i in $CHAINS; do $IPTABLES -t $i -X; done && echo "Clear OK" || echo "Clear FAILED" for i in $CHAINS; do $IPTABLES -t $i -Z; done and ending with "/sbin/iptables-save > /etc/sysconfig/iptables" after that any needed rules are added with iptables-command this script is distributed to a LOT of machines of any type at the begin it has basic rules for any machine (accept, block, reject) followed by a lot of if [ "$HOSTNAME" == "hostname" ]; then fi this is maintained on a staging server, distributed to any amchine and called with "ssh root@host '/scirpts/iptables.sh" for other networks / routers / nat-gateways outside the main network a fork of this thing exists, using over years grown knowledge and adds specific rules, mostly controlled by a lot of variables at the begin call this script does NOt interrupt connections it handles really a lot of specific filters it works like a charme these setups does not need firewalld at all nor do they need any dependency of GUI/TUI tools signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote: > Not sure these two QUITE do the same thing - but they use the > installer similarly, I think. > > here's what I've been using: > > https://github.com/eucalyptus/ami-creator I've got https://github.com/katzj/ami-creator :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote: > >>in your kickstart can you do: > >>bootloader --timeout=1 > >Forgot to mention: this is already there and does not have any effect > >_either_. > hmmm - seems to work for me using ami-creator. I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote: > in your kickstart can you do: > bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
Am 09.11.2012 17:35, schrieb Kevin Fenzi: > On Fri, 9 Nov 2012 11:20:08 -0500 > Matthew Miller wrote: > >> On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote: Yes probably. Anyone know why it's there? >>> IIRC, even if you 'disable' it, plymouth is still the thing handing >>> the text mode output. Perhaps some plymouth folks would chime in >>> here... >> >> I removed it from my test vm with no apparent ill effects > > Does a kernel upgrade work as expected? (dracut might want plymouth to > put in the initramfs?) kernel-line: rd.plymouth=0 plymouth.enable=0 [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+="plymouth" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. in your kickstart can you do: bootloader --timeout=1 -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
appliance-creator: how can I shorten the grub timeout in kickstart?
This perplexing to me. In my %post section, I tried both writing "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
itext 5.x
Does anybody know if there are licensing issues with itext 5.x? I'd like to package some software that needs a fairly recent version of itext, but I know we've had license issues with that package in the past. Also, FWIW, bouncycastle hasn't been updated because of itext ( https://bugzilla.redhat.com/show_bug.cgi?id=806262), but the most recent version of itext, at least, requires the newest bouncycastle. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:57 AM, Panu Matilainen wrote: Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. While that may be true, the amount of ram (free -m) used during an install *triples* when we get to the desolve and package install phase. In my most recent test the "used" number went from roughly 550m just before the packages step to 1645 during. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 08:57:05AM -0800, Jesse Keating wrote: > >>Just to cite similar complaints I see from time to time... It irritates > >>me that people think it's a problem that in 2012 they can't install in a > >>VM that is allocated with 256M of RAM. Allocate a reasonable amount, > >>start over. Your host system for multiple VMs in 2012 should not have 1G > >>of memory. > >What about my host system for 500 VMs? > Use elastic allocation. It takes a lot of ram to say "please > depsolve these 40 packages" which turns into "install these 250 > (minimal) packages". So in order to handle that kind of task > (once), allocate a large amount of ram. Once that task is complete, > the actual work the image will be doing may require a lot less ram, > so you can scale down what you allocate to that guest. Which is of course what everyone is doing. I was replying to the broader theme (small VMs are useless) out of context, probably because it was early in the morning. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 PM, Peter Jones wrote: On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote: On 2012-11-09, 14:30 GMT, David Cantrell wrote: Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. Does it really irritate you? Those are strong words ... anyway. I will risk your irritation, anger, maybe even rage (after all, their impact is limited over IRC) and let me ask: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? The installer's memory footprint is largely bound by the size of the package set. So, for example, a yum "upgrade" will take more ram - because there are effectively twice as many packages involved. There may be ways to reduce how much of that needs to be kept in ram at a time, but those are things for yum/rpmlib - they're not anaconda changes. Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:49:00AM -0800, Jesse Keating wrote: > On 11/09/2012 09:35 AM, Toshio Kuratomi wrote: > >On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: > >> > >>As far as Anaconda reverted in the future, I'm confused as to > >>when/where this became a requirement. > >> > >I think he's saying this because: > > > >1) Features have a section for contingency plans. > >2) In this particular case, we're slipping schedule because the NewUI > >feature has a point where there stopped being a contingency plan. We > >passed that point before being aware of all of these issues that need to > >be fixed in order to release Fedora. > > > >Being stricter about having viable contingency plans for features like > >this (ones that require coordination and can potentially block us if they > >aren't done/done correctly) is one possible way to address this type of > >situation in the future. > > > >Others are to alter the "time-based" release philosophy for certain > >features (We are going to have Feature X in Fedora 19. If it isn't ready, > >we're going to slip the release date until it is done.) To only let in > >a feature with no contingency plan only when it is code complete and can be > >evaluated outside of the Fedora tree first (anaconda devs state that they do > >not actually have the manpower to implement this style of solution). > > > >-Toshio > > > >- Note: I considered adding "have a longer release cycle" to the list of > > alternatives but it's not clear that we wouldn't still get into this > > situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks > > certain capabilities that are considered essential while the team > > responsible for the feature had considered that it was something that > > could safely be put off until the next release. Being unable to revert > > the feature at that point and so having to code the missing capabilities > > on a rushed schedule at that point.) > > > > > > > > In that context the plan would have had to be do all the "bring the > code base forward into the next Fedora environment" work twice. > Correct. But while this is a problem for the anaconda team, it may be the least-bad for Fedora overall. Then again, there might be an alternative that is even better. -Toshio pgptwVnwzfGBC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the "time-based" release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding "have a longer release cycle" to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) In that context the plan would have had to be do all the "bring the code base forward into the next Fedora environment" work twice. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:11 AM, "Jóhann B. Guðmundsson" wrote: Well the argue can be made that If you are doing a minimal install it kinda indicates you actually know what you are doing ( which means you will probably change whatever was set afterwards ) so the system should just default to use sane working defaults which should come with the relevant package when it's installed even set some default password. Pretty sure having a default root password in some package in Fedora is a non-starter. The point of doing an (automated) install (which can be minimal, or at least start with minimal and build upon that with only exactly the needed functionality) is so that you can do the install unattended, reboot the machine and put it into production, unattended. But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? root auth and firewall config are the main ones. Note that we don't have any UI for firewall config either, so not really a lot of code duplication. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 12:55:30PM +0100, Vratislav Podzimek wrote: > On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote: > > > > I've been told that the F18 Anaconda work was for some time done on a > > single rawhide snapshot; after ~2 months the snapshot was updated - > > and it took weeks to get Anaconda working again against the new one. > > > > That sounds rather bad. Yes, anaconda is special, but it is not > > _that_ special; if updating for core platform changes (without any > > major known change happening in the mean time) requires weeks of work > > on anaconda, there will be other software that will require weeks of > > work to update. > I'm afraid anaconda _is that_ special. AFAICT there is no other piece of > code that directly interacts with dracut, systemd, Network Manager, gtk3 > (and GObject introspection) and many other components that change quite > often. If there is such code, I'd be happy to look at how its developers > handle such changes and take a lecture from them. > Other projects would handle something like this by having a subset of people working on a branch that kept the existing UI but was updating to fix issues with dependencies. The NewUI feature work would be done by a different subset of people on a separate branch and be merged in only when it was ready. David Cantrell has mentioned the reasons that he doesn't think that would work for anaconda -- I'll list them here so no one reads my message without that information as well: * Doing it this way would slow down anaconda development * Anaconda lacks the manpower to maintain two separate development heads -Toshio pgpqxuuszzi2x.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Network interface renaming, where does INTERFACE_NAME get applied?
Hi Bill
I see that initscripts in F18 ships this udev rule:
ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
RESULT=="?*", ENV{INTERFACE_NAME}="$result"
I'm trying to tackle some problems related to interface renaming, and
understanding how this works would be useful.
But I can't find which software component *applies* the INTERFACE_NAME
variable set by the above rule, actually performing the interface
rename. Can you explain?
FYI, I would imagine this area will also be susceptible to a current
udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
Thanks
Daniel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 09.11.12 08:53, Matthew Miller (mat...@fedoraproject.org) wrote: > On Fri, Nov 09, 2012 at 01:41:08PM +, "Jóhann B. Guðmundsson" wrote: > > You might want to remove plymouth from the minimal install since it > > does not make sense having it there anyway > > Yes probably. Anyone know why it's there? In rc.sysinit-times ply was the only way how LUKS passwords and suchlike could be prompted during boot. Hence rc.sysinit in a way relied on plymouth to be around to fully function. In systemd we have a non-ply fallback in place however, so prompting passwords on the text console without ply around should work fine nowadays. We regularly test systemd upstream with and without plymouth, to make sure both ways to boot is well supported. Dropping plymouth from the minimal install set should hence be unproblematic and well supported. Note that even on systemd without a display plymouth used to be highly useful since it collected the boot status output from the console and stored it away in log files. With systemd we now connect all boot services (that means stdout/stderr and syslog() of all services in the initrd and early boot) to the journal anyway, so this really useful functionality of plymouth is not necessary anymore. (In case you wonder, to get these boot outputs just run "journalctl -b"). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: > > As far as Anaconda reverted in the future, I'm confused as to > when/where this became a requirement. > I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the "time-based" release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding "have a longer release cycle" to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) pgpnpzwv48BiP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 08.11.2012 15:10, Miroslav Suchý wrote: [1] https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Nice start, Thank you! I like the scripting (ifs) or even better a rule based (make-like) approach. I will test your script on few instances. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 11:21 +0100, Matej Cepl wrote: > On 2012-11-09, 07:43 GMT, Adam Williamson wrote: > > It hasn't really 'skyrocketed'. We cited 512MB for several releases, > > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for > > F17, and it's back up to 768MB or 1GB for F18 atm because everyone has > > more important stuff to do than optimize the RAM usage right now. But > > it's not been rising crazily or anything. I think the last time someone > > took a deep look at RAM use during install - during F17 cycle when we > > got it back down to 512MB - it turned out a lot of the usage happened > > during package install and wasn't really to do with anaconda at all. > > I understand and accept that now everybody in the anaconda-land is busy > with something else, but let it not slip our attention how absolutely > crazy it is when the installation program requires twice as much (or > more) of the resources than all programs running on the computer > combined. I have here a server with RHEL-6 which I had to upgrade to > 512MB just to be able to install a system on it. Now it has plenty of > free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted. > With the spread of virtual machines, it seems to be even more obvious. > Wasn’t one of the advantages of VMs the fact that you can slice more > small machines on one computer? If you're doing that, it's pretty trivial to use pre-built images. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:17 PM, Jesse Keating wrote: I can keep going, but is it really necessary? I argue yes maybe not here but having a wikipage under the anaconda name space which mention all the package and configuration files change that can directly affect the installer and how would be necessary for Feature wranglers/Fesco/QA to look at. Having a page like that might have prevented fesco from approving [1] which I'm pretty sure put added a bit of load on top of your guys work 1.http://fedoraproject.org/wiki/Features/ReworkPackageGroups -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 03:27 AM, Miloslav Trmač wrote: Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. You won't find much disagreement in the installer team. Fedora changes, and it changes fast, and it changes without a lot of notice, cooperation, or coordination. Anaconda suffers a lot because of this, and Fedora users/testers suffer a lot because Anaconda breaks a lot. We are often the advanced scout who first encounters a major change. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org) wrote: > On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: > > deserved. Just today I made a minor fix to systemd git to deal nicely > > with PK-less systems. > > Right now, I get: > > $ reboot > Failed to issue method call: The name org.freedesktop.PolicyKit1 was not > provided by any .service files > Must be root. > > Which is fine except that I don't want to see the message. :) Does your fix > handle this or should I bug report? Yes, that's the one that should be fixed with this: http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e000255d07f6b3cc777f15b Would probably make sense to test things with this applied as it should solve most (but probably not all) issues related to PK-less systems. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > >The storage packages are going to be needed for the system to boot. > > > >Anaconda could probably add some smarts to remove authconfig if it wasn't > >pulled in by anything in the selected comps, but I'm not sure it'd be worth > >the special logic -- we might as well just put it in @core (even though it's > >not super-tiny). > > > >Firwealld I don't know about, though. If anaconda sets up the firewall using > >firewalld but then doesn't install it, will the old iptables scripts load > >the configuration? It'd be nice if it could, because firewalld is *another* > >big change that it'd be nice to have a reasonable back-out plan for. The point here is that both authconfig and firewalld are used by anaconda to configure the installed system, via either the old code (pre-F18) or the kickstart code (older releases, and F18+). anaconda would need to grow more complicated checks to ensure that certain things weren't set in the install before laying them down. > You might want to remove plymouth from the minimal install since it > does not make sense having it there anyway You filed a bug about that, actually... I'll respond here and paste there. plymouth was added to the minimal install as a consistent method for handling encrypted passphrases and boot-time logs at the time. Since this has moved out into other components since then, it can be reconsidered. There's something to be said for having a consistent boot-time interface though, rather than one that changes whether or not plymouth is installed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: > deserved. Just today I made a minor fix to systemd git to deal nicely > with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:47 PM, "Jóhann B. Guðmundsson" wrote: On 11/08/2012 08:40 PM, David Lehman wrote: No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? I'm all for magic but I would expect specific configuration package(s) and or a configuration template tailored for the component being install which the installer might use or the package himself would simply do it post install. Are there any specific use case where that would not suffice? JBG You're focused on packages. How about filesystems? That stuff changes way more often than one would like. LVM? How often do we have to update the command line arguments we pass to do things? --force --force --noIreallymeanit BTRFS? That's all still in development so the tools are changing rapidly. What about actually getting packages into the filesystem. yum api changes with time, and our use of yum means we have to change our code to work with the API as well. Boot loaders? yeah, go ahead and install the grub package, see what it does in the %post scripts. Oh, you actually want to /configure/ the machine to boot? Well that takes work, work that has to change because /grub/ changes. I can keep going, but is it really necessary? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:13 PM, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. It never was up to this point you know the usual attitude of "let's cross that bridge when we get there" and this release cycle has proven that it's necessary JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote: > On 2012-11-09, 14:30 GMT, David Cantrell wrote: > > Just to cite similar complaints I see from time to time... It > > irritates me that people think it's a problem that in 2012 they can't > > install in a VM that is allocated with 256M of RAM. Allocate > > a reasonable amount, start over. Your host system for multiple VMs in > > 2012 should not have 1G of memory. > > Does it really irritate you? Those are strong words ... anyway. > > I will risk your irritation, anger, maybe even rage (after all, their > impact is limited over IRC) and let me ask: > > a) Why installer requires 2-4 times more memory than any other program > running on my computer (and the software you use on it could be a good > example of SOHO server)? The installer's memory footprint is largely bound by the size of the package set. So, for example, a yum "upgrade" will take more ram - because there are effectively twice as many packages involved. There may be ways to reduce how much of that needs to be kept in ram at a time, but those are things for yum/rpmlib - they're not anaconda changes. > b) What awesome and breathtaking functionality I've got in anaconda > since EL-5 that I have to pay for it with this increase of hardware > requirements? (and let me remind you again about those 500 VMs) Most of the "increase of hardware requirements" has been related to the package set, rather than by anaconda getting significantly bigger. There are some cases where we've grown the install images, and despite your implication they tend to be directly related to additional functionality. As a matter of fact, recently we've worked hard to make the install image and working set of the installer *smaller*. As for what functionality you've gotten since, say, the last time we had a major UI change, here's a small sample just off the top of my head: - BIOS-RAID boot - encrypted boot - uefi support on x86 - iscsi boot support - multipath support - using NetworkManager - wireless networking support - ssh support in the installer - "kickstart generation" mode - jlk's new improved non-graphical mode - 3TB disk support There's a full(er) list of what our team has been doing here: http://fedoraproject.org/wiki/Anaconda/Features > I don't think these question are in any way inappropriate or too > offensive, are they? Actually, yeah, when you question our competence and the utility of what we're doing, that is a bit offensive. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: > Of course, it should be clear that making PK optional if a desktop is > installed is not desirable, but other than that I think for head-less > systems such as servers or embedded making PK optional would be > desirable goal and worthwile to spend a bit of work on. Cool, thanks for the input. There's little risk of it becoming optional on the desktop, because a large number of desktop packages sensibly have it as a requirement -- including gnome-shell and kde-runtime. (Xfce doesn't seem to have anything that directly requires it except for xfce4-power-manager, but other collatoral deps lead back to xfce-session.) I'm going to build some images without it and can start filing bugs on anything that comes up. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:01 PM, Jesse Keating wrote: On 11/09/2012 05:48 AM, Matthias Clasen wrote: I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Because when you are only installing the minimal package set (which means no x) then the post-install configuration tools don't really exist to do those necessary steps, nor do people want to have an automated install, which then halts at first boot to prompt a user to configure a bunch of stuff necessary to make the machine work right. Well the argue can be made that If you are doing a minimal install it kinda indicates you actually know what you are doing ( which means you will probably change whatever was set afterwards ) so the system should just default to use sane working defaults which should come with the relevant package when it's installed even set some default password. But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:57 AM, "Jóhann B. Guðmundsson" wrote: On 11/09/2012 04:43 PM, Jesse Keating wrote: While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., It's not like it always works in that area anyway Right, computers don't always work, so lets give up, and go shopping right? there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. Last time I checked the configuration of those files have remained the same for years if we put that aside how is Anaconda supposed to be reverted in the future what's the plan you guys have here, which direction are you guys taking in regards to that? JBG The inputs to the tools doing the configuration of those tools has changed over time. We don't want to duplicate code by having our own pile of config parsers and writers, we want to rely on the same tools that userlands are using. As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
