update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
Hi,
On Wed, 20 Jun 2012 02:22:26 + (UTC)
Ben Boeckel maths...@gmail.com wrote:
On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote:
I wonder if it would be possible to do it on shutdown instead of
during start up? I usually do not care if shutdown takes ten
seconds or five minutes, but when I start my computer I do so
because I want to use it and not wait several minutes before its
ready.
Hmm. I usually have the other problem, especially with laptops.
Shutting down due to low battery only to have it wait to do updates
while there's a chance the updates won't matter because it's going to
crash soon is scarier than booting up and doing updates (presumably
you have juice available when booting). There's also the I need to
be somewhere case where shutting down fast is more important than
booting fast (airplane take off, losing track of time before class,
etc.).
Either way, it certainly isn't an obvious either-or issue. The obvious
solution, to me, is to have mind-reading computers, but I think that
may have one or two other consequences with it.
I agree that mind reading computers may not be the final answer, but I
do have a data point that might be helpful: we locally implemented
updates-at-reboot for a few years now. At first we had them on startup,
but now we do it at shutdown -- we made this change due to user
complaints as they did not mind the computer doing stuff when they went
away, but did mind longer wait times at the start of the {day,week,...}.
Note though that we only implemented this policy for desktop computers,
not for laptops. I agree that for a laptop, shutting down fast can be
necessary as well -- so maybe distinguishing on on AC power would be
a good substitute for mind reading as to when to run the actual updates?
--Stijn
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
Hi, Which is one of a number of reasons why I then suggested that instead of replacing grubby entirely, we could simply patch grubby to call grub2-mkconfig if the bootloader is grub2. That would accomplish everything I wanted to achieve (compliance with /etc/grub.d and /etc/default/grub, which means consistent boot menus), but not break environments where another bootloader like grub-legacy, or simply legacy grub-style configuration, is needed. +1 Having two completely different ways (grubby fiddling with it directly vs. grub2-mkconfig) to update the grub2 configuration sucks big time IMHO. It's inconsistent once both tools touched the config. It also asks for trouble, for example if there are any grub2-mkconfig changes which generate config files grubby can't parse correctly. With grub2 config essentially being a script language this can easily happen I suspect. Just have grubby call grub2-mkconfig to update grub2.conf and be done with it. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/19/2012 08:23 PM, Stephen John Smoogen wrote: Would it be helpful, if there was a list of extensively used options so that DNF knew what high notes it needed to hit sooner rather than later? Absolutely, I created a wiki page for it: https://github.com/akozumpl/dnf/wiki/Features-backlog Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
Angus Salkeld asalk...@redhat.com writes: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? nice one, sir -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
2012/6/20 Nikola Pajkovsky npajk...@redhat.com: Angus Salkeld asalk...@redhat.com writes: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? nice one, sir Indeed. But this should be done on a RPM database copy - bisection should not leave any traces in the history. May be something like yum and git merge? # yum upgrade [...] # yum tag -a my_latest_stable_system # yum upgrade --enablerepo=updates-testing [..] something went wrong? # yum checkout my_latest_stable_system or # yum bisect start -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - On Tue, 2012-06-19 at 22:14 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 09:03 PM, Kevin Fenzi wrote: I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. Which should have been added to the release blocker process when it got added there. From my point of view any handed out media at various events etc and what's on it should be considered release blocker. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. There is no such thing as added burden on QA + Me and James had already solved that problem long ago but never found the time to implement it like so many other things because we both where a bit busy with our $dayjobs. The solution was more or less this way If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. And thank you very much for this email notification! We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. The main issue here is - the TC/RC images are released too fast to be able to fill in the matrix for all DE and all TCs/RCs. The idea could be - fill in the Matrix when first TC/RC is created, then follow closely the changes (to test only stuff that could be affected - hah, could be tricky) - not to fill the whole matrix and go through the all tests that even do not test the real change and then we can have one full matrix test for last one in the series of images and let some amount of time to do it (to mark it - done). Otherwise we will never have all DEs filled in as it's impossible in a time we have. And I have to thank you Fedora QA guys for helping us to cover KDE test, I always try my maximum but sometimes... R. -- 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: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - It's worth noting that we certainly have shipped non-blocking spins in completely broken states in past releases, and there is at present nothing to prevent this happening. There is zero guarantee of testing for non-blocking spins. QA did no formal validation of any spins besides Desktop, KDE, LXDE, Xfce and Sugar for F17. In Milan we talked a little bit about this - to require ack for every spin for every release (even the default one) - to prove, the spin is in a good shape, it's working etc to avoid this situation. Question is, if we can make it (especially in timely manner)... R. 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: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - As far as QA is concerned it's entirely your decision (as a personal note to self, I'll have to update the Deliverables SOP draft). We just need to know so we know what limit to check against in testing. As a personal comment, though, doesn't this seem a little fast to make the decision? Wouldn't it at least make sense to wait for minidebuginfo to be implemented, then spin a test KDE image and see exactly how big it turns out with the current package set? Note that spins are not absolutely required to hit their target size at Alpha; it becomes a hard requirement at Beta stage. So you have up until Beta release to make the decision, really. The reason why we start *talking* about it now is that we are quite sure it's going to a problem for the KDE spin. As QA you know that we are on the edge of current size limit with every release - we already did a lot of compromises and with every release more and more stuff is pulled into the image :( So MiniDebugInfos aren't the only problem, just a kick off to move on :) R. -- 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: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On 20 June 2012 08:08, Stijn Hoop st...@sandcat.nl wrote: I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNF Any testing time-frame?
Would it not be better to work with yum upstream to make the current yum depsolver more modular so you could plugin another libsolv based depsolver, instead of making a fork of yum and starts trashing the current API. There is a lot more to yum, that just solving dependencies. And making a fork there is not fully compatible will put a lot of work on your shoulders :) without the benefit on the work done by yum upstream :) like parallel download etc. Tim On Tue, Jun 19, 2012 at 6:05 PM, Ales Kozumplik akozu...@redhat.com wrote: On 06/19/2012 03:50 PM, Frank Murphy wrote: Current status Targeted release: Fedora 18 Last updated: 2012-6-19 Percentage of completion: 40% When would it hit rawhide, ballpark? I can't give a date yet, but following the FESCo approval of the feature I made review requests today: https://bugzilla.redhat.com/**show_bug.cgi?id=833462https://bugzilla.redhat.com/show_bug.cgi?id=833462 https://bugzilla.redhat.com/**show_bug.cgi?id=833511https://bugzilla.redhat.com/show_bug.cgi?id=833511 Just don't hold your fingers crossed that anyone can use this to replace yum with. Not only that a subset of the full yum functionality is supported (see the thread about 'yum history'), but the plugins API etc. is not ready either. ATM it is just what it is: an experimental fork of Yum using libsolv inside. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On Wed, 20 Jun 2012 10:22:22 +0100 Richard Hughes hughsi...@gmail.com wrote: On 20 June 2012 08:08, Stijn Hoop st...@sandcat.nl wrote: I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Good to know, thanks -- although I wonder, in what capacity is this supported then? Would you / others be willing to deal with both update timings in this Feature? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot chaining works, then? (Re: Replacing grubby with grub2-mkconfig in kernel install process)
So, ... On Tue, Jun 19, 2012 at 2:32 AM, Chris Murphy li...@colorremedies.com wrote: On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: Chris Murphy wrote: Grubby does not work fine with GRUB 2, it creates sloppy menu lists that eventually break the advanced menu entries, as well as totally departing from any user customization of /etc/default/grub. … vs. grub2-mkconfig, which totally departs from any user customization in grub.cfg. It does not totally depart. It is merely (highly) not recommended to directly edit that file. There is indirect customization, which actually in many ways exceeds that of Grub Legacy. But this is an old argument, that ship has sailed. You gain flexibility in one place and lose it in another. I'm not convinced it's an improvement. Though on the other hand, running grub2-mkconfig is how upstream intends things to work. I've already been on this hill pulling my hair out over GRUB2's complexity and lack of well written documentation. However, I feel like I've passed this particularly large stone, the pain has subsided, and except during pre-release grub-mkconfig hasn't failed to produce a correct grub.cfg and bootable system. Not even once. So, with grub-mkconfig, I can expect to be able to chain safely to Debian from a Fedora-installed grub2 in the MBR? Not have mk-config find Debian's kernel and initrd, etc., like Debian's update-grub, but actually chainm, so that Debian can keep track of its latest kernel and Fedora can keep track of its latest kernel and I don't have to deliberately boot and update in both to make sure the the boot process calls the latest kernel no matter which I boot which from? (Not to mention that grub2 doesn't find my 3rd drive for boot purposes.) So. While grubby may do other things, even for GRUB2 dependent systems, the part where it comes up with the new entry should, in my view, just call grub-mkconfig to cause a new grub.cfg to be created. If grub-mkconfig isn't working reliably for some reason, it's a bug that needs to be fixed anyway. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 9:57 AM, Chris Murphy li...@colorremedies.com wrote: On Jun 18, 2012, at 6:36 PM, Kevin Kofler wrote: Chris Murphy wrote: On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: Chris Murphy wrote: Grubby does not work fine with GRUB 2, it creates sloppy menu lists that eventually break the advanced menu entries, as well as totally departing from any user customization of /etc/default/grub. … vs. grub2-mkconfig, which totally departs from any user customization in grub.cfg. It does not totally depart. It is merely (highly) not recommended to directly edit that file. Running grub2-mkconfig automatically makes it not just (highly) not recommended, but basically impossible: Any edits will be trashed at the next kernel update! Which is why if grub-mkconfig is going to be used, the upstream prescribed editing procedure needs to be used. If inadequate, the inadequacy needs to addressed. As far as I'm aware, there is in fact no reason why you can't remove grub2 and replace it with grub (legacy) if it has the exact behaviors you prefer and require. Unfortunately, the original grub does not seem to find my other boots. I prefer GRUB2's self-produced grub.cfg's and I don't find it overly difficult to get the customization I want – except for the fact grubby steps on this, meaning I have to manually run grub-mkconfig to fix the grub.cfg at each kernel update. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, Jun 20, 2012 at 2:49 AM, Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 04:32 AM, Reindl Harald wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. C) Maintain grub1 ourselves (not that I'm volunteering.) D) Invent our own substitute (again, I'm not volunteeing.) You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 11:57 PM, Adam Williamson wrote: On Tue, 2012-06-19 at 23:28 -0400, Ben Rosser wrote: So far, the only actual arguments against this (specifically, the above solution to the problem) I've heard is that it breaks being able to configure /boot/grub2/grub.cfg by hand. But that's the idea behind grub2, for better or worse. The documentation specifically tells you NOT to edit that file, but to instead edit configuration in /etc. Most of the other arguments raised in response to this seem to have really been about grub2 itself, and if Fedora has to use it, so.. are there any other thoughts on the actual matter at hand? grub2-mkconfig is inherently a more 'destructive' operation than grubby, is really my only thought. But I wouldn't mind the change much at all. pjones' opinion would be the most valuable to have, I guess. I really don't see what the point would be. We're going to have to keep grubby for various reasons, not least pvgrub. So switching to using grub2-mkconfig to update grub2 config files has numerous downsides, most obviously: 1) it means new-kernel-pkg would need to be even more complex 2) it means per-kernel command line changes aren't a thing we can really support, which means if for some reason you need a command line option to boot with one kernel that's installed and it needs to /not/ be there for another, we'll be writing a wrong config every time. It seems to me that a lot of people are advocating to switch from one thing they don't understand to another thing they don't understand. I think what's actually needed is a small patch to grubby to make it keep track of the bounding block the current default is in and add the new bounding block there, so that we don't accidentally change the cosmetic properties of the grub2 config file, which seems to be what's causing the most aggravation here. It probably wouldn't be difficult, but if you're waiting for me to do it, cosmetics are currently pretty low on my priority list. So I'd be really glad to see a grubby patch from anybody who's commented on this list. It shouldn't be a lot of code or particularly difficult. If somebody wants to work on it, I'd be glad to help them out with any difficulties they come across. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations... Yeah, I won't be adding any checkboxes to have people pick their /tmp style. - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Weekly ARM status meeting - Wed 2012/06/20
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday June 20th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Cleaning up the wiki - moving dated items to an archive section. - refreshing where needed 2) On to F18 - How do we be more like PA? - Anaconda, livemedia-creator - linker path 3) F18 build status - problem packages 4) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Wed, 20 Jun 2012 13:40:14 +0900, you wrote: On Mon, 18 Jun 2012 14:56:20 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: System76 (and possibly others) will be supplying systems that provide (2), so that choice is available to you. Matthew, I often read you referring to System76, since the UEFI discussion. System76 products are limited to the US market (only), and not all Fedora users are US residents. They do ship to other countries, Japan included: https://www.system76.com/home/shippinginformation/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 03:35 PM, Chris Lumens wrote: Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations... Yeah, I won't be adding any checkboxes to have people pick their /tmp style. Then putting not putting /tmp on tmpfs is the only applicable default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
I think I got this fixed in doxygen-1.8.1.1-2.fc18 : http://koji.fedoraproject.org/koji/buildinfo?buildID=325050 I'll talk to than about getting a fixed build for f17 too -- rex Thanks for all the answers and thanks for the fixed doxygen. I'll try to build the package I have issue with for F18 asap. it doesn't effect doxygen-1.8.0 in f17 and i don't plan to update new version in f17 yet So the newer doxygen doesn't help with the pdf file. I think the issue is the default header and footer when no LATEX_HEADER and LATEX_FOOTER are provided in the doxygen-config contain the timestamp. Should that be considered as a doxygen bug ? could you please provide a reproduce for this issue? Thanks Than -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. one reason more why the cuurent behavior re-starting services on updates is simply wrong: * it breaks running services on dist-upgrades * it breaks coordinated updates/restarts of admins action with 10,20,30 instances of fedora at the same time * it breaks security if a depending library is updated after the service in the transaction whileyou imply for users that they do no longer need to use their own brain - t is generallya bad direction giving the user a sign that is own brain is longter useful * it forces coordinated working admin to re-build every server package and pacth out the restart-part from SPEC signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
Am 20.06.2012 14:33, schrieb Joel Rees: A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. C) Maintain grub1 ourselves (not that I'm volunteering.) D) Invent our own substitute (again, I'm not volunteeing.) god beware, you can do this only if there is a living upstream :-) http://fedoraproject.org/wiki/Features/DNF DNF is a fork of Yum 3.4 that uses libsolv via hawkey for a backed. The main goals of the project are: signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 20.06.2012 16:11, schrieb Ralf Corsepius: On 06/20/2012 03:35 PM, Chris Lumens wrote: Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations... Yeah, I won't be adding any checkboxes to have people pick their /tmp style. Then putting not putting /tmp on tmpfs is the only applicable default. +100 a default has to be soemthing which is OK on EVERY setup /tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Wed, 2012-06-20 at 08:28 +1000, Angus Salkeld wrote: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? I thought about implementing this, when I did yum history rollback the problem is that you can only go forwards. So say you have: # yum history list 4 up 3 up blah 2 up bar 1 up foo ...then a bisect looks like: # yum history list 5 rollback to 2 4 up 3 up blah 2 up bar 1 up foo # yum history list 6 2=1 or 2=3 5 rollback to 2 4 up 3 up blah 2 up bar 1 up foo ...etc. and it seemed like it'd be too horrible to live with that in the history. In theory we could add a feature so that when you are finished with the bisect you can remove or merge the history for all the transactions where the end rpmdb versions are the same. But it's not obvious that adding features to remove things from history is a good idea, in general. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Tue, Jun 5, 2012 at 12:28 AM, Olav Vitters o...@vitters.nl wrote: On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote: Matthias Clasen wrote: Its not his ignorance - he's on vacation for the next two weeks... Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post. Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel If Puttering really went on vacation after dropping a bombshell like that, well, I'm thinking he should recuse himself. Yeah. I'm getting personal here. Lennart has put a lot of edits into Fedora that are all about copying a design philosophy that has been disasterous where it has been used. (Or perhaps getting the Fedora community to do the grunt work on his Master's thesis on things that shouldn't be done in an OS?) Edits that will have to be rolled back if Fedora is to survive as the testbed for an enterprise class OS. Very costly edits. Edits that have been eating my sack time, which is why I've been taking it personal. But, as has been danced around in this thread several times already, allowing /tmp to consume half of a system's putative RAM is really, really perverse. (Unless you have stock in a company that sells RAM and CPUs with 32 bit addressing.) No, you can declaim how the system will auto-swap the RAM and adjust things for you, but that is adding to the cycles the CPUs have to waste doing things that are just plain unnecessary. tmpfs is there precisely because /tmp is not fast enough for certain applications. Those applications should know who they are. Leave it like that. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, Jun 20, 2012 at 9:21 AM, Peter Jones pjo...@redhat.com wrote: I think what's actually needed is a small patch to grubby to make it keep track of the bounding block the current default is in and add the new bounding block there, so that we don't accidentally change the cosmetic properties of the grub2 config file, which seems to be what's causing the most aggravation here. It probably wouldn't be difficult, but if you're waiting for me to do it, cosmetics are currently pretty low on my priority list. So I'd be really glad to see a grubby patch from anybody who's commented on this list. It shouldn't be a lot of code or particularly difficult. If somebody wants to work on it, I'd be glad to help them out with any difficulties they come across. The thing is, while I agree this would be a better solution (modifying grubby to play nicer with grub.cfg), I'm not sure how practical an idea it is. Adding a new kernel entry to the submenu rather than the top of the parent menu sounds simple enough, but then we'd also have to replace the default Fedora Linux entry at the top of the parent menu with one for the new kernel, so the default is the new kernel rather than the old kernel, right? And that sounds like it could be done as well, but my concern is that it should only be done if that's how grub.cfg is set up in the first place. Which means grubby would need to detect or map the layout of grub.cfg and then figure out where new kernel entries would need to be inserted into that layout, and if any older kernel entries would need to be removed (like the default one in the setup I explained above). And that sounds like it's a bit more work than a small patch... maybe it's not, I don't know. But it seems to me like it'd be harder to do than you make it sound. Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Wed, 20 Jun 2012 09:57:58 -0400 Gerald Henriksen ghenr...@gmail.com wrote: On Wed, 20 Jun 2012 13:40:14 +0900, you wrote: On Mon, 18 Jun 2012 14:56:20 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: System76 (and possibly others) will be supplying systems that provide (2), so that choice is available to you. Matthew, I often read you referring to System76, since the UEFI discussion. System76 products are limited to the US market (only), and not all Fedora users are US residents. They do ship to other countries, Japan included: https://www.system76.com/home/shippinginformation/ Effectively. I am looking at their page right now. There's been quite a change since the last direct email exchange, about a year ago, when they said they weren't delivering overseas, and they had no plan to be represented in Asia. Things have changed. That's a good news (for once). Thanks for the update. -- nomnex nom...@gmail.com Freenode: nomnex Registered Linux user #505281. Be counted at: http://linuxcounter.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Glib-1.260.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Glib: faa052bdf6e9b87ea30b630c2806e71e Glib-1.260.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib] 1.260 bump
commit b680de6aa6a8bc3f2aa2920809fc1d3f537350df
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 17:06:16 2012 +0200
1.260 bump
Required by perl-Gtk3-0.006.
.gitignore |1 +
perl-Glib.spec | 37 ++---
sources|2 +-
3 files changed, 32 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1e1bb5e..9cbcb06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Glib-1.223.tar.gz
/Glib-1.240.tar.gz
/Glib-1.241.tar.gz
+/Glib-1.260.tar.gz
diff --git a/perl-Glib.spec b/perl-Glib.spec
index adccdb1..dbe58a0 100644
--- a/perl-Glib.spec
+++ b/perl-Glib.spec
@@ -1,16 +1,31 @@
Name: perl-Glib
-Version:1.241
-Release:4%{?dist}
+Version:1.260
+Release:1%{?dist}
Summary:Perl interface to GLib
Group: Development/Libraries
License:LGPLv2+
URL:http://search.cpan.org/dist/Glib/
-Source0:http://www.cpan.org/authors/id/T/TS/TSCH/Glib-%{version}.tar.gz
+Source0:http://www.cpan.org/authors/id/X/XA/XAOC/Glib-%{version}.tar.gz
BuildRequires: perl = 2:5.8.0
BuildRequires: glib2-devel
-BuildRequires: perl(ExtUtils::Depends), perl(ExtUtils::PkgConfig)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::Depends) = 0.300
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::PkgConfig) = 1.00
+BuildRequires: perl(File::Spec)
+# Run-time
+BuildRequires: perl(base)
+BuildRequires: perl(constant)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(DynaLoader)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(IO::File)
+BuildRequires: perl(Storable)
+# Tests
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
+BuildRequires: perl(Tie::Hash)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# Do not export private modules and libraries
@@ -26,9 +41,9 @@ that make up the Gnome environment, and are used in many
unrelated
projects.
%package devel
-Summary: Development part of Perl interface to GLib
-Group: Development/Libraries
-Requires: %{name} = %{version}-%{release}
+Summary:Development part of Perl interface to GLib
+Group: Development/Libraries
+Requires: %{name} = %{version}-%{release}
%description devel
Development part of package perl-Glib, the Perl module providing interface
@@ -36,6 +51,11 @@ to GLib and GObject libraries.
%prep
%setup -q -n Glib-%{version}
+for F in AUTHORS; do
+iconv -f ISO-8859-1 -t UTF-8 $F ${F}.utf8
+touch -r $F ${F}.utf8
+mv ${F}.utf8 $F
+done
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -76,6 +96,9 @@ make test
%{_mandir}/man3/Glib::xsapi.3pm.gz
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1.260-1
+- 1.260 bump
+
* Tue Jun 12 2012 Petr Pisar ppi...@redhat.com - 1.241-4
- Perl 5.16 rebuild
diff --git a/sources b/sources
index 98dedb4..81fb882 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-412118238a372041b130c27d7992f5c3 Glib-1.241.tar.gz
+faa052bdf6e9b87ea30b630c2806e71e Glib-1.260.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Thu, 21.06.12 00:01, Joel Rees (joel.r...@gmail.com) wrote: If Puttering really went on vacation after dropping a bombshell like My name is Poettering, not Puttering. community to do the grunt work on his Master's thesis on things that My master's thesis? Nah, no thanks, already got a good old german Diplom, no interest in a Master. (The Bologna process is evil anyway!) Please be more careful with the facts when insulting somebody, thank you! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/20/2012 11:04 AM, Ben Rosser wrote: On Wed, Jun 20, 2012 at 9:21 AM, Peter Jones pjo...@redhat.com mailto:pjo...@redhat.com wrote: I think what's actually needed is a small patch to grubby to make it keep track of the bounding block the current default is in and add the new bounding block there, so that we don't accidentally change the cosmetic properties of the grub2 config file, which seems to be what's causing the most aggravation here. It probably wouldn't be difficult, but if you're waiting for me to do it, cosmetics are currently pretty low on my priority list. So I'd be really glad to see a grubby patch from anybody who's commented on this list. It shouldn't be a lot of code or particularly difficult. If somebody wants to work on it, I'd be glad to help them out with any difficulties they come across. The thing is, while I agree this would be a better solution (modifying grubby to play nicer with grub.cfg), I'm not sure how practical an idea it is. Adding a new kernel entry to the submenu rather than the top of the parent menu sounds simple enough, but then we'd also have to replace the default Fedora Linux entry at the top of the parent menu with one for the new kernel, so the default is the new kernel rather than the old kernel, right? And that sounds like it could be done as well, but my concern is that it should only be done if that's how grub.cfg is set up in the first place. Which means grubby would need to detect or map the layout of grub.cfg and then figure out where new kernel entries would need to be inserted into that layout, and if any older kernel entries would need to be removed (like the default one in the setup I explained above). And that sounds like it's a bit more work than a small patch... maybe it's not, I don't know. But it seems to me like it'd be harder to do than you make it sound. I still don't think that's very difficult. It's another line entry type, but that's not much code either. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On 20 June 2012 12:51, Stijn Hoop st...@sandcat.nl wrote: Good to know, thanks -- although I wonder, in what capacity is this supported then? Well, I've got no idea if it works at all, let alone if it works well ;) Would you / others be willing to deal with both update timings in this Feature? It's not something I want to include in this feature, but I'd be happy to accept patches for PackageKit if required. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Escalation - better desktop printing policy (over two years old issue)
Hi, On 06/15/2012 09:30 AM, valent.turko...@gmail.com wrote: Hi, Fedora still has quite strict printing policies even if users choose to be a part of Administrator group during installation still need to input passwords while changing even the minor printer settings (like unpausing). This is still an issue on Fedora 16 and 17, is has been in bugzilla for over 2 years: https://bugzilla.redhat.com/show_bug.cgi?id=596711 Why are Administrator users being asked for root pasword when editing printer options? There is a fix from Fedora wiki page: http://fedoraproject.org/wiki/Printing/ConfigurationTool Please make this fix permanent and enabled by default in Fedora. If I'm not mistaken this is the same issue that Linus Torvalds vented regarding same issue on OpenSuse - https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5 Thanks, Valent. I'll review the bug as soon as I'll finish the 2 things I'm working on right now. Regards Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On 06/20/2012 03:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. one reason more why the cuurent behavior re-starting services on updates is simply wrong: It's also not true. If new dovecot requires new version of libfoo, that new libfoo with all its files is guaranteed [*] to be installed before the new dovecot, ditto for all their dependencies recursively. Reverse for the erasure phase, eg the older libfoo version is only removed after everything depending on it has been removed. If you think about it a little, not a single upgrade involving soname bumps and the like would work properly if it wasn't like that. Doesn't mean there aren't windows where things can get broken while a transaction is in progress, eg you can atomically rename multiple files. [*] Guaranteed except in presence of dependency loops, in which case rpm tries to break up the loop(s) in the least disruptive way, but there can be no guarantees in such situations. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On 06/20/2012 06:42 PM, Panu Matilainen wrote: On 06/20/2012 03:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. one reason more why the cuurent behavior re-starting services on updates is simply wrong: It's also not true. If new dovecot requires new version of libfoo, that new libfoo with all its files is guaranteed [*] to be installed before the new dovecot, ditto for all their dependencies recursively. Reverse for the erasure phase, eg the older libfoo version is only removed after everything depending on it has been removed. If you think about it a little, not a single upgrade involving soname bumps and the like would work properly if it wasn't like that. Doesn't mean there aren't windows where things can get broken while a transaction is in progress, eg you can atomically rename multiple files. Argh... can NOT atomically rename multiple files. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 10:16 AM, Reindl Harald wrote: Am 20.06.2012 16:11, schrieb Ralf Corsepius: On 06/20/2012 03:35 PM, Chris Lumens wrote: Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations... Yeah, I won't be adding any checkboxes to have people pick their /tmp style. Then putting not putting /tmp on tmpfs is the only applicable default. +100 a default has to be soemthing which is OK on EVERY setup /tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload That's pretty specious. You're not going to see a machine that doesn't boot immediately after installation because /tmp is on tmpfs, so there's no reason you can't frame /not/ having it on tmpfs to be a possible tuning depending on environment and workload. Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp . -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
default DNS caching name server on Fedora ?
Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. The first case is already in the works, and the reason it needs a caching DNS name server is the complexity of dealing with DNSSEC verification. I won't spend time on that except for saying this effort should be part of a unified solution. The second case is what is really hurting me. I have my own DNS server at home that resolves address only for my private network, and forwards any other request. When I connect to my employer VPN however I need to use their DNS server to resolve their internal machines, the same happens to pretty much any other VPN service I have used. Also I do not need to route all DNS traffic in the VPN for all web sites, mostly for performance reasons, but also for privacy reasons. This could be easily solved if we have a caching DNS server that can be dynamically change to forward DNS requests to the proper DNS server only for the private domains they provide. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket 328 - make sure all internal search filters are properly escaped
https://fedorahosted.org/389/ticket/328 https://fedorahosted.org/389/attachment/ticket/328/0001-Ticket-328-make-sure-all-internal-search-filters-are.patch Thanks, Mark -- Mark Reynolds Senior Software Engineer Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp . Given a choice between works for everyone and works well for most, but fails in obscure ways for some, I'll choose the former. I find it amusing that this argument is going for the screw some of the users so others are happy way, but the reboot-to-update argument is going the opposite, the must always work for everyone no matter how painful way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012 11:47:17 -0400 Simo Sorce s...@redhat.com wrote: Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. ...snip... Discuss. You can already (all be it somewhat manually) do this with dnssec-trigger. yum install dnssec-trigger reboot or: /bin/systemctl restart dnssec-triggerd.service /bin/systemctl restart dnssec-triggerd-keygen.service Connect your vpn, etc. Then tell unbound what you want it to do: unbound-control forward_add redhat.com x.x.x.x y.y.y.y unbound-control forward_add yourdomain z.z.z.z (unbound-control gives you a lot of control, you can flush cache, setup forward, see it's man page or help for all the options). I'm not sure how hard/possible it is for dnssec-trigger to get this info from the vpn/NM and just set it for you. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
Am 20.06.2012 17:42, schrieb Panu Matilainen: On 06/20/2012 03:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. one reason more why the cuurent behavior re-starting services on updates is simply wrong: It's also not true. If new dovecot requires new version of libfoo, that new libfoo with all its files is guaranteed [*] to be installed before the new dovecot, ditto for all their dependencies recursively. Reverse for the erasure phase, eg the older libfoo version is only removed after everything depending on it has been removed. boah and if it does NOT require a new version because it is not a new version of a library since new releae-version with patches is not uncommon and if one of the patches is security relevant there is NO gurantee that the service itslef would not be restarted BEFORE the pacth is applied If you think about it a little, not a single upgrade involving soname bumps and the like would work properly if it wasn't like that i do not need to think i was there, i saw was happened on dist-upgrades, i fixed them i saw a dist-upgrade on the fist-testmachine restart httpd which failed for some reason and AFTER some time you could start httpd again * i rebuilt the httpd package * i removed the dumb restart from the SPEC file * i rolled out the dist-upgrade on 20 production machines * no second downtime of httpd except the usual reboot don't get me wrong, but i am not interested in theory i am intersted in stable update-processes whch were painless years ago and now can only be achievd be rebuilt a lot of pakcages signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 10:01 -0600, Kevin Fenzi wrote: On Wed, 20 Jun 2012 11:47:17 -0400 Simo Sorce s...@redhat.com wrote: Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. ...snip... Discuss. You can already (all be it somewhat manually) do this with dnssec-trigger. yum install dnssec-trigger reboot or: /bin/systemctl restart dnssec-triggerd.service /bin/systemctl restart dnssec-triggerd-keygen.service Connect your vpn, etc. Then tell unbound what you want it to do: unbound-control forward_add redhat.com x.x.x.x y.y.y.y unbound-control forward_add yourdomain z.z.z.z (unbound-control gives you a lot of control, you can flush cache, setup forward, see it's man page or help for all the options). I'm not sure how hard/possible it is for dnssec-trigger to get this info from the vpn/NM and just set it for you. Yes this is all good 'n' nice. The point is, can we/should we/want we make this the default ? (And work on integrating NM - unbound automatic configuration ?) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012 12:05:57 -0400 Simo Sorce s...@redhat.com wrote: Yes this is all good 'n' nice. The point is, can we/should we/want we make this the default ? (And work on integrating NM - unbound automatic configuration ?) I'd be in favor of that. ;) I don't want to speak for the feature owner/unbound/dnssec maintainer tho. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On 06/20/2012 06:59 PM, Reindl Harald wrote: Am 20.06.2012 17:42, schrieb Panu Matilainen: On 06/20/2012 03:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. one reason more why the cuurent behavior re-starting services on updates is simply wrong: It's also not true. If new dovecot requires new version of libfoo, that new libfoo with all its files is guaranteed [*] to be installed before the new dovecot, ditto for all their dependencies recursively. Reverse for the erasure phase, eg the older libfoo version is only removed after everything depending on it has been removed. boah and if it does NOT require a new version because it is not a new version of a library since new releae-version with patches is not uncommon and if one of the patches is security relevant there is NO gurantee that the service itslef would not be restarted BEFORE the pacth is applied Rpm always orders by dependencies within a transaction, so if library and the service depending on the library are updated in the same transaction the library will be updated first. If you think about it a little, not a single upgrade involving soname bumps and the like would work properly if it wasn't like that i do not need to think i was there, i saw was happened on dist-upgrades, i fixed them i saw a dist-upgrade on the fist-testmachine restart httpd which failed for some reason and AFTER some time you could start httpd again * i rebuilt the httpd package * i removed the dumb restart from the SPEC file * i rolled out the dist-upgrade on 20 production machines * no second downtime of httpd except the usual reboot don't get me wrong, but i am not interested in theory i am intersted in stable update-processes whch were painless years ago and now can only be achievd be rebuilt a lot of pakcages Some reason can't be analyzed... but like said, there certainly are all sorts of gaps and holes where things can be temporarily broken while a transaction is running, including file-renames, old files from previous version still being around, dependencies (such as service inter-dependencies) which rpm does not know about, dlopen()'ed libraries etc. Most of the time things work well enough that nobody notices, but an assumption that the system stays in a fully consistent state throughout an online update is simply bogus, service restarts or not. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, 2012-06-20 at 09:21 -0400, Peter Jones wrote: On 06/19/2012 11:57 PM, Adam Williamson wrote: On Tue, 2012-06-19 at 23:28 -0400, Ben Rosser wrote: So far, the only actual arguments against this (specifically, the above solution to the problem) I've heard is that it breaks being able to configure /boot/grub2/grub.cfg by hand. But that's the idea behind grub2, for better or worse. The documentation specifically tells you NOT to edit that file, but to instead edit configuration in /etc. Most of the other arguments raised in response to this seem to have really been about grub2 itself, and if Fedora has to use it, so.. are there any other thoughts on the actual matter at hand? grub2-mkconfig is inherently a more 'destructive' operation than grubby, is really my only thought. But I wouldn't mind the change much at all. pjones' opinion would be the most valuable to have, I guess. I really don't see what the point would be. We're going to have to keep grubby for various reasons, not least pvgrub. So switching to using grub2-mkconfig to update grub2 config files has numerous downsides, most obviously: 1) it means new-kernel-pkg would need to be even more complex As I understood it, the latest version of the proposal involves having grubby simply call grub2-mkconfig when it is dealing with grub2. So the rest of the 'stack' doesn't change at all. 2) it means per-kernel command line changes aren't a thing we can really support, which means if for some reason you need a command line option to boot with one kernel that's installed and it needs to /not/ be there for another, we'll be writing a wrong config every time. It's not possible to do this through grub2's own mechanisms? It seems to me that a lot of people are advocating to switch from one thing they don't understand to another thing they don't understand. I think what's actually needed is a small patch to grubby to make it keep track of the bounding block the current default is in and add the new bounding block there, so that we don't accidentally change the cosmetic properties of the grub2 config file, which seems to be what's causing the most aggravation here. It probably wouldn't be difficult, but if you're waiting for me to do it, cosmetics are currently pretty low on my priority list. Well, the way I see it, that's the solution to the _current_ biggest problem we have with grubby/grub2 (it completely nerfing the nested format that mkconfig prefers to generate at present). But I see that specific problem as only a symptom of a bigger issue, which is that upstream currently feels perfectly free to make drastic changes to the grub config file format at any time, in stark contrast to how things were with grub-legacy, where there was a very stable format we could rely on. I feel like, if we stick with grubby, we're kind of stuck in a game of whack-a-mole at least until upstream stabilizes the config format. We solve this problem, they'll throw us another curveball sooner or later... So I'd be really glad to see a grubby patch from anybody who's commented on this list. It shouldn't be a lot of code or particularly difficult. If somebody wants to work on it, I'd be glad to help them out with any difficulties they come across. I guess Mads might be able to do 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: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 05:45 PM, Peter Jones wrote: On 06/20/2012 10:16 AM, Reindl Harald wrote: Am 20.06.2012 16:11, schrieb Ralf Corsepius: On 06/20/2012 03:35 PM, Chris Lumens wrote: Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations... Yeah, I won't be adding any checkboxes to have people pick their /tmp style. Then putting not putting /tmp on tmpfs is the only applicable default. +100 a default has to be soemthing which is OK on EVERY setup /tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload That's pretty specious. You're not going to see a machine that doesn't boot immediately after installation because /tmp is on tmpfs, so there's no reason you can't frame /not/ having it on tmpfs to be a possible tuning depending on environment and workload. Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp . Again: It is not reasonable, it's generally and basically unreliable and cause of instabilities and unreliablities. Whether it's close to being usable depends on a user's use-case. It might be usable on a 32GB RAM single-user laptop, but it's complete non-sense otherwise. Just have your fellow co-worker dump an arbitrary 100GB file to /tmp and watch your system to start misbehaving. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/20/2012 12:42 PM, Adam Williamson wrote: On Wed, 2012-06-20 at 09:21 -0400, Peter Jones wrote: On 06/19/2012 11:57 PM, Adam Williamson wrote: On Tue, 2012-06-19 at 23:28 -0400, Ben Rosser wrote: So far, the only actual arguments against this (specifically, the above solution to the problem) I've heard is that it breaks being able to configure /boot/grub2/grub.cfg by hand. But that's the idea behind grub2, for better or worse. The documentation specifically tells you NOT to edit that file, but to instead edit configuration in /etc. Most of the other arguments raised in response to this seem to have really been about grub2 itself, and if Fedora has to use it, so.. are there any other thoughts on the actual matter at hand? grub2-mkconfig is inherently a more 'destructive' operation than grubby, is really my only thought. But I wouldn't mind the change much at all. pjones' opinion would be the most valuable to have, I guess. I really don't see what the point would be. We're going to have to keep grubby for various reasons, not least pvgrub. So switching to using grub2-mkconfig to update grub2 config files has numerous downsides, most obviously: 1) it means new-kernel-pkg would need to be even more complex As I understood it, the latest version of the proposal involves having grubby simply call grub2-mkconfig when it is dealing with grub2. So the rest of the 'stack' doesn't change at all. This is hardly a substantive difference from what I said; either way, you're effectively asking me to make something with less features and more complexity. In fact making grubby call out to another program is /more/ complex than making new-kernel-pkg do it. 2) it means per-kernel command line changes aren't a thing we can really support, which means if for some reason you need a command line option to boot with one kernel that's installed and it needs to /not/ be there for another, we'll be writing a wrong config every time. It's not possible to do this through grub2's own mechanisms? No; it only gives you the same command line for every kernel. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) See also: http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ Been there since 2010. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, 2012-06-20 at 21:33 +0900, Joel Rees wrote: You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. C) Maintain grub1 ourselves (not that I'm volunteering.) That's option a). It's what we've been doing for several years already. pjones more or less reached the end of his tether with attempting to single-handedly maintain a dead codebase. D) Invent our own substitute (again, I'm not volunteeing.) Well, someone already pointed to http://people.freedesktop.org/~kay/loader/ , which seems intriguing. I haven't read anything Kay's said publicly about it, though. Of course, it's UEFI-specific. -- 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
FSF address fix and timestamps
Hi Fedora community, I know that I can fix the new address of sources files with sed (http://fedoraproject.org/wiki/Packaging_tricks#Wrong_FSF_address). I think that timestamp should not be preserved because it's a change, a really small change, but a change after all , what do you think? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Wed, 2012-06-20 at 04:46 -0400, Jaroslav Reznik wrote: We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. The main issue here is - the TC/RC images are released too fast to be able to fill in the matrix for all DE and all TCs/RCs. The idea could be - fill in the Matrix when first TC/RC is created, then follow closely the changes (to test only stuff that could be affected - hah, could be tricky) - not to fill the whole matrix and go through the all tests that even do not test the real change and then we can have one full matrix test for last one in the series of images and let some amount of time to do it (to mark it - done). Otherwise we will never have all DEs filled in as it's impossible in a time we have. And I have to thank you Fedora QA guys for helping us to cover KDE test, I always try my maximum but sometimes... I know they iterate fast :/ When a candidate doesn't likely change anything significant wrt. a desktop I try to say so, but the thing is, it's possible for really weird stuff to happen, and we have to try and exclude that possibility as much as possible. So instead of trying to do something like you propose above and run the risk of dropping the ball somewhere and declaring that a test has passed which actually fails for the latest compose, I'd prefer to always have a fresh matrix for each compose. What we can do when we're *almost* sure the results for, say, TC2 will hold for TC3 so far as KDE is concerned, is copy the results across; we do do that sometimes. It has the advantage that it's clear we're relying on a previous candidate test, rather than giving the false assurance that we've actually tested it directly with the latest build. Unfortunately the fast iteration is a fact of life on the release cycle we use, there's no possible other way to do it so far as I can see :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, Jun 20, 2012 at 09:59:33AM -0700, Adam Williamson wrote: Well, someone already pointed to http://people.freedesktop.org/~kay/loader/ , which seems intriguing. I haven't read anything Kay's said publicly about it, though. Of course, it's UEFI-specific. Which is a good reason for it not to be the default. We're only going to audit one set of code for secure boot purposes, and it's not going to be something that lacks required functionality like PXE support. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On 06/20/2012 09:57 AM, Adam Williamson wrote: On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) See also: http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ Been there since 2010. So I just gave this a try. Already had dnsmasq installed so I just edited the config file and restarted the NetworkManager service. Then connected to my VPN. It. Just. Works. Amazing! Not only does it just work for resolution, but it also works for multiple search domains. I can ping name and it'll try name.localdomain and I can also do name.subname and it'll find it at name.subname.workdomain. A+ -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
Am 20.06.2012 18:26, schrieb Panu Matilainen: i was there, i saw was happened on dist-upgrades, i fixed them i saw a dist-upgrade on the fist-testmachine restart httpd which failed for some reason and AFTER some time you could start httpd again * i rebuilt the httpd package * i removed the dumb restart from the SPEC file * i rolled out the dist-upgrade on 20 production machines * no second downtime of httpd except the usual reboot don't get me wrong, but i am not interested in theory i am intersted in stable update-processes whch were painless years ago and now can only be achievd be rebuilt a lot of pakcages Some reason can't be analyzed... but like said, there certainly are all sorts of gaps and holes where things can be temporarily broken while a transaction is running, including file-renames, old files from previous version still being around, dependencies (such as service inter-dependencies) which rpm does not know about, dlopen()'ed libraries etc. Most of the time things work well enough that nobody notices, but an assumption that the system stays in a fully consistent state throughout an online update is simply bogus, service restarts or not i know that a dist-upgrade takes usually 5 minutes on a virtual server there is nearly zero chance httpd would crash in this time there is much more chance it goes down by the restart services like mysql as example MUST NEVER get automatically restarted because the package-maintainer can not know what implicatons this have as for postfix having configuration mysql based rejecting incoming messages so in the case of a mysqld upgrade on our mailsevrer i MUST use the follwoing steps and i MUST prevent mysqld package from restarting and that is why automatic restart of services without a GLOBAL option to DISABLE THIS bogus and naive and es the order of this stop/start is VERY IMPORTANT [root@mail:~]$ cat /scripts/dbmail-stop-all.sh #!/bin/bash /sbin/service crond stop /sbin/service postfix stop /sbin/service dovecot stop /sbin/service dbmail-imapd stop /sbin/service dbmail-lmtpd stop /sbin/service dbmail-pop3d stop /sbin/service dbmail-timsieved stop /sbin/service mysqld stop [root@mail:~]$ cat /scripts/dbmail-start-all.sh #!/bin/bash /sbin/service mysqld start /sbin/service dbmail-lmtpd start /sbin/service dovecot start /sbin/service postfix start /sbin/service dbmail-imapd start /sbin/service dbmail-pop3d start /sbin/service dbmail-timsieved start /sbin/service crond start _ i restart services by hand i know what i am doing i do not need any helping hand restarting anything magically i do not want it because it is not consistent since it is not consistent it is wrong to do it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 20.06.2012 18:49, schrieb Ralf Corsepius: Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp . Again: It is not reasonable, it's generally and basically unreliable and cause of instabilities and unreliablities. Whether it's close to being usable depends on a user's use-case. It might be usable on a 32GB RAM single-user laptop, but it's complete non-sense otherwise. Just have your fellow co-worker dump an arbitrary 100GB file to /tmp and watch your system to start misbehaving. i fear people here are getting more and more ignorant fro teh reality what is the topic of this dicussion? someone (Lennart?) is thinking tmpfs is cool to few people knowing REAL workloads and saying it's ok for me i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp this is the wrong perspective the right one is the system must not crash if someone does if the system crashs the reason has tobe found and fixed and the reason for this will be /tmp on tmpfs there is nothing to think and calculate it is simply a fact that drop a 100 or 200 Gb file into tmpfs will bring down each machine existing currently and in the next 5-10 years and making a deafult behave this way is terrible wrong, especially sell it as improvement signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.rei...@thelounge.net wrote: i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp this is the wrong perspective the right one is the system must not crash if someone does Good thing it doesn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Wed, Jun 20, 2012 at 11:04 AM, nomnex nom...@gmail.com wrote: Things have changed. That's a good news (for once). Thanks for the update. Bravo, so apparently there is a leader on this, a free software UEFI on its own trustworthy hardware, that hopefully will tell the truth to the user about security for the owner of the device, and make installing free operating systems non-scary. However, more need to follow in the same market (and in providing infrastructure for boxes over which owners have root control) so System76 does not become a target. Then big shots won't be able to turn a practice of holding root on their devices and granting signing services to their hardware, into a bogus norm either of a kind that says you must have a license to compute, or of a kind that says copyright means you can't parse and process published information, that turns it into a prior restraint. You might have to pay extra at first, but this will make it apparent to the world at large that this is the way things should be, rather than either of those bogus norms. Then we will have won the entire information freedom battle, for us and our grandchildren. No need for a shim. Use your own chain of trust. No implication that anybody must be *forced* to provide devices without Secure Boot turned on. The Secure Boot technology is a useful facility. You need to come to terms with what this new technology means for freedom. That does not mean boot on all hardware sold. It does mean make sure free software has and supports hardware with UEFIs that cater to freedom, and that gives you control over boxes you own. Seth On Wed, Jun 20, 2012 at 11:04 AM, nomnex nom...@gmail.com wrote: On Wed, 20 Jun 2012 09:57:58 -0400 Gerald Henriksen ghenr...@gmail.com wrote: On Wed, 20 Jun 2012 13:40:14 +0900, you wrote: On Mon, 18 Jun 2012 14:56:20 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: System76 (and possibly others) will be supplying systems that provide (2), so that choice is available to you. Matthew, I often read you referring to System76, since the UEFI discussion. System76 products are limited to the US market (only), and not all Fedora users are US residents. They do ship to other countries, Japan included: https://www.system76.com/home/shippinginformation/ Effectively. I am looking at their page right now. There's been quite a change since the last direct email exchange, about a year ago, when they said they weren't delivering overseas, and they had no plan to be represented in Asia. Things have changed. That's a good news (for once). Thanks for the update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Wed, Jun 20, 2012 at 01:19:22PM -0400, Seth Johnson wrote: On Wed, Jun 20, 2012 at 11:04 AM, nomnex nom...@gmail.com wrote: Things have changed. That's a good news (for once). Thanks for the update. Bravo, so apparently there is a leader on this, a free software UEFI on its own trustworthy hardware, that hopefully will tell the truth to the user about security for the owner of the device, and make installing free operating systems non-scary. To the best of my knowledge, their UEFI implementation isn't free software. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 7:05 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. I am _very_ concerned about large files in conjunction with tmpfs usage for general purpose /tmp by default. Especially on multi-user capable systems. As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size? Does swap backed tmpfs as /tmp currently jeopardize my system's health by making swap backup for in-memory processes compete with tmp files? If my users clog up /tmp will that reach a point where the kernel's oom process killer decided to start killing off running processes instead of throwing crap out of /tmp? What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the Open in facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown? Without more information about how gracefully /tmp spill over into swap is handled, I'm inclined to say this really looks problematic as a default. And that's not even getting into the more complex issues of virtual machine configurations which typically run under heavier ram constraints than disk constraints. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Proceed to the next paragraph then. ;-) Seth On Wed, Jun 20, 2012 at 1:21 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Jun 20, 2012 at 01:19:22PM -0400, Seth Johnson wrote: On Wed, Jun 20, 2012 at 11:04 AM, nomnex nom...@gmail.com wrote: Things have changed. That's a good news (for once). Thanks for the update. Bravo, so apparently there is a leader on this, a free software UEFI on its own trustworthy hardware, that hopefully will tell the truth to the user about security for the owner of the device, and make installing free operating systems non-scary. To the best of my knowledge, their UEFI implementation isn't free software. -- Matthew Garrett | mj...@srcf.ucam.org However, more need to follow in the same market (and in providing infrastructure for boxes over which owners have root control) so System76 does not become a target. Then big shots won't be able to turn a practice of holding root on their devices and granting signing services to their hardware, into a bogus norm either of a kind that says you must have a license to compute, or of a kind that says copyright means you can't parse and process published information, that turns it into a prior restraint. You might have to pay extra at first, but this will make it apparent to the world at large that this is the way things should be, rather than either of those bogus norms. Then we will have won the entire information freedom battle, for us and our grandchildren. No need for a shim. Use your own chain of trust. No implication that anybody must be *forced* to provide devices without Secure Boot turned on. The Secure Boot technology is a useful facility. You need to come to terms with what this new technology means for freedom. That does not mean boot on all hardware sold. It does mean make sure free software has and supports hardware with UEFIs that cater to freedom, and that gives you control over boxes you own. Seth 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: Replacing grubby with grub2-mkconfig in kernel install process
would fixing this also fix the bug where installing a new kernel changes the default boot OS even when the default is non Linux? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/20/2012 01:32 PM, Naheem Zaffar wrote: would fixing this also fix the bug where installing a new kernel changes the default boot OS even when the default is non Linux? What's the bugzilla number for that? -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FSF address fix and timestamps
On 06/20/2012 06:59 PM, Sergio Belkin wrote: Hi Fedora community, I know that I can fix the new address of sources files with sed (http://fedoraproject.org/wiki/Packaging_tricks#Wrong_FSF_address). I think that timestamp should not be preserved because it's a change, a really small change, but a change after all , what do you think? Thanks in advance! I don't know what to say about the timestamps, but perhaps script below is helpful. Beware, those are long source lines which will be split by the email software... it fixes most of it, if not all :) --alec #!/bin/sh for f in $@; do sed -i -e 's/59 Temple Place.*USA/51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA/' \ -e 's/675 Mass Ave.*USA/51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA/'\ -e 's/59 Temple Place[ ,-]*Suite 330/51 Franklin Street, Fifth Floor/' \ -e 's/MA[ ]*02111-1307/MA 02110-1301/' \ $f done -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
So, how does this scenario work? * The machine has 4G of RAM, * 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other 50% is pagecache * The machine has 4G of swap, none of which is active. So then a user drops a 8.5G DVD image into /tmp. On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root. With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? As I understand it, the program gets ENOSPC and there is NO free RAM: pagecache is full of that dvd data. swap is full of that dvd data. The rest of the RAM is program data that has nowhere to page out to. The system may not have crashed, but it is fubar: welcome to OOM killer territory The answers of don't do that, use /var/tmp or allocate more swap are crap. The software isn't broken if it writes to /tmp, regardless of how many bugzilla entries get filed. Allocating more swap is a cop out because you've only pushed the problem to some file size that is larger, and you've tied up disk for a worst case scenario that may never come. This introduces behavior that is highly dependent not only on the memory configuration of the machine, but the usage at the time the allocation happened, making this impossible to troubleshoot. What are the benefits of this change again? Clearing /tmp at shutdown is interesting, but can be accomplished in other ways (although not as cleanly), and I have yet to see any hard numbers on I/O even though I have asked repeatedly. Brian On 06/20/2012 01:18 PM, Gregory Maxwell wrote: On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.rei...@thelounge.net wrote: i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp this is the wrong perspective the right one is the system must not crash if someone does Good thing it doesn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta jspal...@gmail.com wrote: As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size? This is an issue you have independent of tmpfs. How big does / need to be? (or if /tmp is on another volume due to the fragmentation mess it creates, how big does that volume need to be). Does swap backed tmpfs as /tmp currently jeopardize my system's health by making swap backup for in-memory processes compete with tmp files? If my users clog up /tmp will that reach a point where the kernel's oom process killer decided to start killing off running processes instead of throwing crap out of /tmp? Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem If you set it high enough that you could fill swap and physical ram with tmpfs plus your workload, then yes, I believe you'd then see the OOM killer run. I've never had this happen because I've never set my tmpfs size larger than the available swap I had— so any OOM event always was due to applications using up too much core. What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the Open in facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown? Yes, Firefox saves to /tmp by default. Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems. Without more information about how gracefully /tmp spill over into swap is handled, I'm inclined to say this really looks problematic as a default. And that's not even getting into the more complex issues of virtual machine configurations which typically run under heavier ram constraints than disk constraints. It really sounds to me that you're using a ramdisk as a mental model for tmpfs. That isn't what tmpfs is. Tmpfs is a filesystem backed by the kernel's buffer cache, and it can use whatever resources it likes to back it up. In practice small short lived things are purely in ram, while larger long lived data ends up on disk— but it does so at the kernel's leisure and in a manner which minimizes writes and latency critical operations. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default. Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: So, how does this scenario work? * The machine has 4G of RAM, * 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other 50% is pagecache * The machine has 4G of swap, none of which is active. So then a user drops a 8.5G DVD image into /tmp. On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root. With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? 2G gets written and then -ENOSPC. 2G gets pushed to swap. The default for tmpfs mounts is an fs that is sized to RAM/2. -- Chris Adams cmad...@hiwaay.net 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: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 01:41 PM, Gregory Maxwell wrote: What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the Open in facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown? Yes, Firefox saves to /tmp by default. Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems. I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation. With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure. Its not just writing out the data that needs to be measured, but any case where the threshold of memory-used-for-software crosses the tmpfs limit: loading libreoffice when the machine has more than 50% ram used by software is going to generate a bunch of writes as well as a ton of reads at the same time, rather than having them spaced out over time (potentially, at least) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 20/06/12 18:55, Chris Adams wrote: 2G gets written and then -ENOSPC. 2G gets pushed to swap. The default for tmpfs mounts is an fs that is sized to RAM/2. What is the scenario, where it's a KVM host and 3/4 physical ram is assigned to Guests? -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 01:55 PM, Chris Adams wrote: Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: So, how does this scenario work? * The machine has 4G of RAM, * 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other 50% is pagecache * The machine has 4G of swap, none of which is active. So then a user drops a 8.5G DVD image into /tmp. On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root. With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? 2G gets written and then -ENOSPC. 2G gets pushed to swap. The default for tmpfs mounts is an fs that is sized to RAM/2. So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Once upon a time, Reindl Harald h.rei...@thelounge.net said: it is simply a fact that drop a 100 or 200 Gb file into tmpfs will bring down each machine existing currently and in the next No, it won't. Also, the default partitioning scheme for the existing Fedora setup (with /tmp on /) also won't support dupming a 100G file in /tmp, because / doesn't end up with 100G free. -- Chris Adams cmad...@hiwaay.net 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: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta jspal...@gmail.com wrote: On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default. Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up? It's 50% available at bootup by default (e.g. this is what you get when you provide no size option while mounting). I'm not sure what the systemd stuff is doing, I had the impression it was leaving this as a default. I don't know if this is a good thing or not. On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler bdwhe...@indiana.edu wrote: I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation. With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure. An anticdote is not data, but I've never personally experienced negative thrashing behavior from high tmpfs usage. I suppose thrashing only really happens when there is latency sensitive competition for the IO, and the kernel must be aggressive enough to avoid that. When data is written to file systems normally the bulk will also remain in the buffer cache for a some span of time until there is memory pressure. The difference is how long it can remain (tmpfs has no mandatory flush) before being backed by disk, how much extra overhead there is from maintaining metadata (less for tmpfs than persistent file systems), and how much must be written right away to keep the fs consistent (none for tmpfs). On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler bdwhe...@indiana.edu wrote: So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram? On systems where tmpfs is provisioned for /tmp in fstab you change a setting to get more space (provide size=fooG mount option). This is easier than adding more space to tmp when tmp is on root or some other file system. I don't know how it will be set in systemd. Regardless of what systemd offers you could still toss in an option to remount it with more space after bootup. Buying more ram to increase /tmp is silly of course. The default behavior is just a default it doesn't imply some kind of cosmic relationship between your tmpfs size and the amount of physical ram. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Simo, For the VPN scenario I've been happily using dnrd for some time. I use it to steer DNS requests for mycompany.com to the company's DNS servers, and all other DNS requests to the external servers. Unlike just adding the company DNS servers to /etc/resolv.conf, this never uses the company's DNS for external domain resolution, even if the primary ISP's DNS servers are down. I also use routing to steer company traffic to the VPN, and the rest to my default route. John On 06/20/2012 11:47 AM, Simo Sorce wrote: Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. The first case is already in the works, and the reason it needs a caching DNS name server is the complexity of dealing with DNSSEC verification. I won't spend time on that except for saying this effort should be part of a unified solution. The second case is what is really hurting me. I have my own DNS server at home that resolves address only for my private network, and forwards any other request. When I connect to my employer VPN however I need to use their DNS server to resolve their internal machines, the same happens to pretty much any other VPN service I have used. Also I do not need to route all DNS traffic in the VPN for all web sites, mostly for performance reasons, but also for privacy reasons. This could be easily solved if we have a caching DNS server that can be dynamically change to forward DNS requests to the proper DNS server only for the private domains they provide. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. Simo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 20.06.2012 19:18, schrieb Gregory Maxwell: On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.rei...@thelounge.net wrote: i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp this is the wrong perspective the right one is the system must not crash if someone does Good thing it doesn't no it does not CRASH but it starts crawling around because the system starts to swap and i have never seen any linux system not get unuseable for my taste while heavily swapping _ what is so difficulty to undersatnd: a application has the choice: * holding data in memory * writing data to a file if the application thinks the data of the current workload is too big for memory why would it be a godd design for a operating system-default to say does not bother me? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 20.06.2012 19:41, schrieb Gregory Maxwell: On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta jspal...@gmail.com wrote: As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size? This is an issue you have independent of tmpfs. How big does / need to be? (or if /tmp is on another volume due to the fragmentation mess it creates, how big does that volume need to be) the huge difference between swapping and the size of swap or have /tmp on the normal file-system is that SWAP is dead space allocation and mostly useless on modern machines a reserve on / for installed new applications, logfiles, /tmp and whatever will there be stored can be used in a mixed workload for EVERYTHING (data, tmp, logs...) normally you know how much space you need for your target-setup and allocate around 2xneeded space for rootfs your /tmp on tmpfs is only wasting space allocations and/or memory or your system simply crashs - you are also missing that if /tmp get's full and is on rootfs there are 5% reserved for root, so NOTHING happens to your system you can not repair easily if you system starts to swap because a large file in tmpfs and swap is full your machine crashs, you have no way to do anything and in the worst c ase you will lose data until now NOBODY was able to explain a real-world benefit for /tmp on tmpfs as argument for make it a default and i more and more refuse to undrsatnd how decisions are made in Fedora _ this all feels like: * one person has a idea late at night * the person makes a proposal * some people do not understand anything and says why not * the feature is approved signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012, Simo Sorce wrote: There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. This already works out of the box using unbound, dnssec-trigger and openswan. I use it every day to connect to the red hat vpn, even if I'm at a hotspot place. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. openswan does this based on the XAUTH informationn received. It receives the domain (redhat.com) and the name server IPs, and reconfigured unbound on the fly to forward those. When the tunnel is brought down, the DNS records are flushed so the external view becomes visible again. Please give it a shot, or ping me if you want to check your configuration. But it should be out of the box (apart from the openswan ipsec.conf) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012, Kevin Fenzi wrote:
Connect your vpn, etc.
Then tell unbound what you want it to do:
unbound-control forward_add redhat.com x.x.x.x y.y.y.y
unbound-control forward_add yourdomain z.z.z.z
(unbound-control gives you a lot of control, you can flush cache, setup
forward, see it's man page or help for all the options).
I'm not sure how hard/possible it is for dnssec-trigger to get this
info from the vpn/NM and just set it for you.
You need to do a little more, see /usr/lib/ipsec/_updown.netkey which
is where openswan handles this:
updateresolvconf() {
if [ -n $PLUTO_CISCO_DNS_INFO ]; then
if [ -n `pidof unbound` -a -n $PLUTO_CISCO_DOMAIN_INFO ];
then
echo updating local nameserver for $PLUTO_CISCO_DOMAIN_INFO with
$PLUTO_CISCO_DNS_INFO
/usr/sbin/unbound-control forward_add $PLUTO_CISCO_DOMAIN_INFO
$PLUTO_CISCO_DNS_INFO
/usr/sbin/unbound-control flush_zone $PLUTO_CISCO_DOMAIN_INFO
return
fi
fi
restoreresolvconf() {
if [ -n $PLUTO_CISCO_DNS_INFO ]; then
if [ -n `pidof unbound` ]; then
echo flushing local nameserver of $PLUTO_CISCO_DOMAIN_INFO
/usr/sbin/unbound-control forward_remove
$PLUTO_CISCO_DOMAIN_INFO
/usr/sbin/unbound-control flush_zone
$PLUTO_CISCO_DOMAIN_INFO
fi
return
fi
The flush_zone is needed so you can access the domain again using the
public view DNS.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
DNS handling was Re: default DNS caching name server on Fedora ?
People have might missed it before, but Fedora does a lot now with handling the various DNS manglings it can encounter in the wild. If you install dnssec-trigger from rawhide, then your DNS will be automatically configured using DNSSEC and with as much security as possible, while detecting hotspots and telling you when you are temporarilly using insecure DNS (eg to authenticate a hotspot) dnssec-trigger uses two web pages run by the fedora infrastructure team to do this. One page to trigger redirects on port 80, and one page to detect port 80 mangling. Upon connecting to a new network, dnssec-trigger performs a full test of the DNS server supplied by the DHCP server. If it supports DNSSEC, it is used to forward all queries. If not, then a free port 53 is probed to see if unbound should do all recursing itself. If that is broken or blocked, it will attempt to talk raw DNS over port 80, or DNS wrapped in SSL over port 443 to three DNS resolvers run by Fedora (you can see these configurations in /etc/dnssec-trigger/dnssec-triggerd.conf). If that also fails, then it will warn you and give you a choice between going insecure or only using already cached DNS. It will also try to connect to fedoraproject.org/static/hotspot.html and detect if you are hotspotted. It will popup a warning for you to login to the hotspot with a new browser window. Once the hotspot.html page looks normal, we know you authenticated (clicked OK, or paid) and DNS is reprobed to see if we now can do DNSSEC. We are trying to work under a lot of different scenario's, including hotspots that break DNS, hotspots intercepting all port 53, hotspots counting in you doing port 80 traffic to do an http redirect, etc etc. This is currently mostly done by dnssec-triggerd, which reconfigures unbound on the fly. When going insecure, it rewrites resolv.conf to point to the DHCP obtained DNS, but when it is secure, it will point DNS to 127.0.0.1 where unbound will answer. And as I said in my previous email, when you bring up a VPN using openswan, it deals with the specific domain and its name servers for you dynamically as well. But vpnc does not yet support this. What I would like to do next is to tie network manager and dnssec-trigger more closely together, so we don't have to do tricks like making resolv.conf immutable to prevent others from bypassing DNSSEC security by rewriting that file. Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On Tue, Jun 19, 2012 at 11:17 PM, Adam Williamson awill...@redhat.com wrote I just tested a fresh install from F17 desktop live; the /home/user directory created after firstboot is 700. /home/user created by s-c-u is 700. /home/user created by useradd is 700. /home/user created by GNOME account tool is 700. So I can't recreate a 755 user dir in any way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net maybe you're not trying hard enough. btw, kde install gave me a 755 ~, and a mix of modes on sub-directories. charles zeitler -- Do what thou wilt shall be the whole of the Law. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 02:16 PM, Gregory Maxwell wrote: On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta jspal...@gmail.com wrote: On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default. Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up? It's 50% available at bootup by default (e.g. this is what you get when you provide no size option while mounting). I'm not sure what the systemd stuff is doing, I had the impression it was leaving this as a default. I don't know if this is a good thing or not. On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler bdwhe...@indiana.edu wrote: I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation. With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure. An anticdote is not data, but I've never personally experienced negative thrashing behavior from high tmpfs usage. I suppose thrashing only really happens when there is latency sensitive competition for the IO, and the kernel must be aggressive enough to avoid that. I was pretty sure that on the internet an anecdote == data. :) When data is written to file systems normally the bulk will also remain in the buffer cache for a some span of time until there is memory pressure. The difference is how long it can remain (tmpfs has no mandatory flush) before being backed by disk, how much extra overhead there is from maintaining metadata (less for tmpfs than persistent file systems), and how much must be written right away to keep the fs consistent (none for tmpfs). Perhaps, but if you've dumped a big file to /tmp on a real filesystem and then a minute or two later you startup something large, its probable that the kernel has flushed the data to disk and the pagecache has easily discardable pages to use for new data coming in. Under tmpfs the flush would be forced on page discard which would also be when things were being read into the system. But in any case the I/O advantages have never been shown, despite multiple requests by myself and others. On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler bdwhe...@indiana.edu wrote: So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram? On systems where tmpfs is provisioned for /tmp in fstab you change a setting to get more space (provide size=fooG mount option). This is easier than adding more space to tmp when tmp is on root or some other file system. Well, yes and no. You also have to make sure you have enough backing swap or you're screwing yourself out of usable ram. The problem here is that the amount of /tmp by default is small by default so the tinkering with sizes is actually more likely to be required that it was before. And moving the requirement for large files (for some value of 'large' which depends on your memory configuration) to /var/tmp is just moving goalposts and not actually solving anything. I don't know how it will be set in systemd. Regardless of what systemd offers you could still toss in an option to remount it with more space after bootup. Buying more ram to increase /tmp is silly of course. The default behavior is just a default it doesn't imply some kind of cosmic relationship between your tmpfs size and the amount of physical ram. Ah, but it is the default. Because of this, there are going to be dumbass howto sites out there saying that Fedora is broken because it requires you to buy more RAM to get increased swap space -- no matter how many times it is refuted here. So I built a rawhide vm just now with 2G of ram and while it didn't move /tmp to tmpfs (maybe because it was an upgrade?), /run is in tmpfs and I did some experiments. Yes, it did limit me to 1G when writing a file which is fine -- except that as a user that is substantially smaller than the (disk size - 6G) size that one would have had on /tmp if it was on /. Which means that many users are going to have to mess with that setting in order to preserve their current workflow and/or solve
[perl-Test-YAML-Valid] Perl 5.16 rebuild
commit 4ae6dbd2a14d7bb7afa360937c34d4cf10efe896
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:02:00 2012 +0200
Perl 5.16 rebuild
perl-Test-YAML-Valid.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-YAML-Valid.spec b/perl-Test-YAML-Valid.spec
index 4a1830e..9d871d5 100644
--- a/perl-Test-YAML-Valid.spec
+++ b/perl-Test-YAML-Valid.spec
@@ -1,6 +1,6 @@
Name: perl-Test-YAML-Valid
Version:0.04
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Lets you test the validity of YAML files in unit tests
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*3pm*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 0.04-8
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.04-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Oracle] Perl 5.16 rebuild
commit 8bd30f03664d32ca48170b3b0b4e7d2be77863de
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:02:02 2012 +0200
Perl 5.16 rebuild
perl-DateTime-Format-Oracle.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-Oracle.spec b/perl-DateTime-Format-Oracle.spec
index e7a923b..845eddc 100644
--- a/perl-DateTime-Format-Oracle.spec
+++ b/perl-DateTime-Format-Oracle.spec
@@ -1,6 +1,6 @@
Name: perl-DateTime-Format-Oracle
Version:0.06
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Parse and format Oracle dates and timestamps
License:GPL+ or Artistic
Group: Development/Libraries
@@ -42,6 +42,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 0.06-2
+- Perl 5.16 rebuild
+
* Fri Jan 27 2012 Petr Šabata con...@redhat.com - 0.06-1
- 0.06 bump
- Spec cleanup
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-XQL] Perl 5.16 rebuild
commit 7d10dea09b7d746986f4616712ffa71a0cb70e4a
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:02:18 2012 +0200
Perl 5.16 rebuild
perl-XML-XQL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-XQL.spec b/perl-XML-XQL.spec
index bd482fa..f9cb3d1 100644
--- a/perl-XML-XQL.spec
+++ b/perl-XML-XQL.spec
@@ -1,6 +1,6 @@
Name: perl-XML-XQL
Version:0.68
-Release:15%{?dist}
+Release:16%{?dist}
Summary:Perl module for querying XML tree structures with XQL
License:GPL+ or Artistic
Group: Development/Libraries
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT %{__perl_provides}
%{_mandir}/man3/XML::XQL*.3*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 0.68-16
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.68-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Inspector] Perl 5.16 rebuild
commit eb4899e677d45cecf89c9647d37a94ff0f001478
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:02:46 2012 +0200
Perl 5.16 rebuild
perl-Module-Inspector.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Inspector.spec b/perl-Module-Inspector.spec
index 94f91b3..1c40f45 100644
--- a/perl-Module-Inspector.spec
+++ b/perl-Module-Inspector.spec
@@ -1,6 +1,6 @@
Name: perl-Module-Inspector
Version:1.05
-Release:11%{?dist}
+Release:12%{?dist}
Summary:Integrated API for inspecting Perl distributions
License:GPL+ or Artistic
Group: Development/Libraries
@@ -69,6 +69,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1.05-12
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.05-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Pg] Perl 5.16 rebuild
commit f219f305e10fcf847ed1c76e8afb9e52541672e9
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:02:47 2012 +0200
Perl 5.16 rebuild
perl-DateTime-Format-Pg.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-Pg.spec b/perl-DateTime-Format-Pg.spec
index 74c6b7a..e7a61cb 100644
--- a/perl-DateTime-Format-Pg.spec
+++ b/perl-DateTime-Format-Pg.spec
@@ -1,6 +1,6 @@
Name: perl-DateTime-Format-Pg
Version:0.16007
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Parse and format PostgreSQL dates and times
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 0.16007-3
+- Perl 5.16 rebuild
+
* Tue Jan 17 2012 Iain Arnell iarn...@gmail.com - 0.16007-2
- rebuilt again for F17 mass rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Jun 19, 2012, at 9:57 PM, Adam Williamson wrote: grub2-mkconfig is inherently a more 'destructive' operation than grubby, is really my only thought. But I wouldn't mind the change much at all. pjones' opinion would be the most valuable to have, I guess. FWIW, grub-mkconfig writes out a grub.cfg.new file which is only renamed to replace grub.cfg upon successful completion of all scripts. So there is a fallback position if grub-mkconfig is interrupted. While I like the current GRUB2 behavior in F17 vastly better than F16, I kinda wonder if it makes sense to change the default behavior to save last chosen option and by default use that the next time around, rather than always defaulting to the most recent Fedora kernel. This allows dual-boot users to choose Windows (or Mac OS) once, and consistently get that as their default boot option, rather than having to manually edit GRUB's configuration files to get such behavior. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Starter-PBP] Perl 5.16 rebuild
commit 733652197f0c60ea910498f3fd815786206b3cf9
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:08:29 2012 +0200
Perl 5.16 rebuild
perl-Module-Starter-PBP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Starter-PBP.spec b/perl-Module-Starter-PBP.spec
index 95272f2..8c8e59e 100644
--- a/perl-Module-Starter-PBP.spec
+++ b/perl-Module-Starter-PBP.spec
@@ -8,7 +8,7 @@
Name: perl-Module-Starter-PBP
Version:0.03
-Release:14%{?dist}
+Release:15%{?dist}
Summary:Create a module as recommended in Perl Best Practices
Group: Development/Libraries
@@ -78,6 +78,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 0.03-15
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.03-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Database] Perl 5.16 rebuild
commit 09c7d5107a433b403576d24f43d48d84f0b22694
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 23:09:15 2012 +0200
Perl 5.16 rebuild
perl-Test-Database.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Database.spec b/perl-Test-Database.spec
index 02235a9..e934606 100644
--- a/perl-Test-Database.spec
+++ b/perl-Test-Database.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Database
Version:1.11
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Database handles ready for testing
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1.11-4
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.11-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FSF address fix and timestamps
On Wed, 20 Jun 2012 13:59:26 -0300, Sergio Belkin wrote: Hi Fedora community, I know that I can fix the new address of sources files with sed (http://fedoraproject.org/wiki/Packaging_tricks#Wrong_FSF_address). I think that timestamp should not be preserved because it's a change, a really small change, but a change after all , what do you think? I think Fab who added that to the Wiki page should revert the edit. Read this: https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address -- Fedora release 17 (Beefy Miracle) - Linux 3.4.2-4.fc17.x86_64 loadavg: 0.52 0.27 0.42 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Wed, Jun 20, 2012 at 4:57 PM, Brian Wheeler bdwhe...@indiana.edu wrote: But in any case the I/O advantages have never been shown, despite multiple requests by myself and others. I posted some example numbers earlier in this thread. e.g. make on an already compiled firefox source was half the time on tmpfs compared to ext4— even though the workload was all hot cache. Also its easy to observe the write activity on tmp that happens even for short lived files and reducing write load on SSDs was one of the main arguments advanced for this change. Well, yes and no. You also have to make sure you have enough backing swap or you're screwing yourself out of usable ram. Yes, and the installer does this IIRC. The problem here is that the amount of /tmp by default is small by default so the tinkering with sizes is actually more likely to be required that it was before. Yes, this was why I said I didn't know if it was a good idea that systemd leaves the default alone or not. I don't run any of my systems that way. If this change turns out to be problematic then I think this would be why. sarcasm Maybe for F19 I'll submit a feature that requires all X apps have to use 8-bit color (oooh, and private colormaps) since its will make network rendering 3x faster and that what solaris used to do! Don't ask any questions, though, because you can't possibly understand and I know it just works for me. You should just remove network transparency from the window system entirely. No one needs that and besides VNC/Spice is good enough for everyone! /sarcasm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 833723] perltidy-20120619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=833723 Ville Skyttä ville.sky...@iki.fi changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||20120619-1 Resolution|--- |RAWHIDE Last Closed||2012-06-20 17:25:32 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora ARM status meeting minutes 2012-06-20
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-20/fedora-meeting-1.2012-06-20-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-20/fedora-meeting-1.2012-06-20-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-20/fedora-meeting-1.2012-06-20-20.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 19 Jun 2012 16:25:50 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 06/19/2012 03:59 PM, Jef Spaleta wrote: On Tue, Jun 19, 2012 at 2:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. At what point in the process would you place the go-no-go as to the release of a specific deliverable as an official spin? In an effort to not beatup an existing subgroup that is perhaps shorthanded I'll talk about a hypthetical situation. For the sake of argument lets assume I and a small group of heroic people were able to beat CDE into shape as a new fedora spin. Retro is the new hotness right... We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? -jef We already have a go/ no go line built into the schedule. It's the Feature Freeze line. Things are supposed to be in a testable state by that point. If your desktop is so broken as to not even be testable, that's reason to drop it. I believe that's the transition from Alpha to Beta. Feature freeze is at Alpha, it has to be testable in the Alpha release. it doesnt have to be complete until Beta though. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/iR0QACgkQkSxm47BaWfdSYwCdEQwc1tbbn5YJcnxEmMwiQx4A IBkAn1eoQkfYSatDbAIkBeeTzsuIw2QC =M1u/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 19 Jun 2012 12:19:35 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com escribió: As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. from Relengs perspective it doesnt matter what size it is. so long as it meets the release criteria then its ok. Personally i have a serious concern over dropping cd sized media. One big issue is that the OLPC XO-1 only has 1gb storage for both the OS and user data. any size increase in the OS reduces the room for user data. http://en.wikipedia.org/wiki/One_Laptop_Per_Child#Deployment_of_XO_laptops lists over 2.5 million XOs deployed a large number of which a xo-1 most of which run fedora. my other concer is for portions of the world without great internet access. making everything bigger slows down download time and increases costs of getting fedora. im honestly not sure what kind of numbers this would effect Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/iSkAACgkQkSxm47BaWfesggCdFn1tL0G4yeeU9rbDoTupnkfC YHQAnRTnJGq2qTOoq1IH0wZeuDC0Zgcj =qmNI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FSF address fix and timestamps
2012/6/20 Michael Schwendt mschwe...@gmail.com: On Wed, 20 Jun 2012 13:59:26 -0300, Sergio Belkin wrote: Hi Fedora community, I know that I can fix the new address of sources files with sed (http://fedoraproject.org/wiki/Packaging_tricks#Wrong_FSF_address). I think that timestamp should not be preserved because it's a change, a really small change, but a change after all , what do you think? I think Fab who added that to the Wiki page should revert the edit. Read this: https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address -- So I will informe upstream about it... -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Introduction regarding VirtualGL and bumblebee review requests
Hello, As per the instructions at the web page at http://fedoraproject.org/wiki/Join_the_package_collection_maintainers I wanted to give a brief introduction. My name is Gary Gatling and I work at North Carolina State University supporting Linux in the college of engineering. I mainly work with Red Hat Enterprise Linux. I recently I bought a laptop that ended up having optimus hybrid graphics. This means it has both a discrete and a integrated GPU. I learned that the people who made a solution for such laptops with nvidia GPUs did not have packages for fedora or rhel. This made me sad so I decided to try to learn how to package their software. Am open to making any changes you guys would need. I know the current instructions at: https://fedoraproject.org/wiki/Bumblebee could be made much easier if the software existed in the form of rpm packages. The packages review requests are at: https://bugzilla.redhat.com/show_bug.cgi?id=834127 https://bugzilla.redhat.com/show_bug.cgi?id=827167 Thanks for your consideration, esp considering Linus' remarks lately to NVidia on this very topic... :) Also, sorry if this is a duplicate. I had to change some of my email settings. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote: On Wed, 20 Jun 2012 12:05:57 -0400 Simo Sorce s...@redhat.com wrote: Yes this is all good 'n' nice. The point is, can we/should we/want we make this the default ? (And work on integrating NM - unbound automatic configuration ?) I'd be in favor of that. ;) I don't want to speak for the feature owner/unbound/dnssec maintainer tho. I spent some time looking at this today. NM already has plugins for dnsmasq and a long-since-dead one for bind. We can certainly add a plugin for dnssec-trigger or even unbound itself as well. The mechanism by which dnssec-trigger currently interfaces with NM (dispatcher script) is not optimal for a DNS plugin, and it requires setting resolv.conf immutable which is a hack. NM also has a priority for these plugins, so one gets asked to set up DNS first, and if that fails for whatever reason, we go on to the second one. That's all done by editing NetworkManager.conf (see the manpage). The plugins attempt to be robust to failure, such that if dnsmasq quits or the configuration is invalid (which happened once when a new version of dnsmasq came out), NM will either respawn the plugin or fall back to writing resolv.conf to ensure that there is some network connectivity. You can envision a system where NM just sends out dbus signals that registered handlers like dnsmasq or dnssec-trigger would listen for, or a script-based system like the dispatcher scripts but specifically for DNS, but both these have some robustness concerns. The situation I do *not* want to get into at any point is where DNS is broken. That's what we currently run into with various hacks like openresolv/resolvconf, immutable /etc/resolv.conf, etc. That's why NM attempts to monitor these services and takes a very hands-on approach. The more processes we run, the more possibilities there are for things to get misconfigured or fall through cracks. Which is why I'm a bit concerned about the chain of NM - dnssec-trigger - unbound... (also, an aside: why the heck do resolvconf and dnssec-trigger require an interface name??? DNS information has nothing do with network interfaces, despite some DNS info coming from interface-specific sources like DHCP...) Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 16:24 -0400, Paul Wouters wrote: On Wed, 20 Jun 2012, Simo Sorce wrote: There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. This already works out of the box using unbound, dnssec-trigger and openswan. I use it every day to connect to the red hat vpn, even if I'm at a hotspot place. NM has also done this for a couple years when you use the dnsmasq DNS plugin for NM. It'll also set up the reverse address mappings so that reverse lookups work, which I found necessary for some stuff (krb5 I think?). It's not hard to create a new plugin, one could be created for dnssec-trigger and even for unbound by itself. NM will ask plugins to handle DNS from any source it receives the information from, be that static configuration, DHCP, VPNs, PPP, mobile broadband, etc. If no plugin is registered, or if those plugins fail to handle it, NM falls back to writing /etc/resolv.conf, where, of course, you don't get nice split DNS because glibc is simple. Dan A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. openswan does this based on the XAUTH informationn received. It receives the domain (redhat.com) and the name server IPs, and reconfigured unbound on the fly to forward those. When the tunnel is brought down, the DNS records are flushed so the external view becomes visible again. Please give it a shot, or ping me if you want to check your configuration. But it should be out of the box (apart from the openswan ipsec.conf) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
