Re: Chromium
On 03/18/2012 02:39 PM, Mike Chambers wrote: Are you by chance using a proxy? If so there is a bug in google-chrome/chromium which happened when KDE proxy changed output to have white space separated port number - if so make just edit the file ~/.kde4/share/config/kioslaverc and make it URL:portnumber and restart chrome. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with yum
On 02/27/2012 11:44 AM, Sandro Mani wrote: will leave your system in a state where manual cleanup is likely required. One scenario which I often hit is forgetting to change the proxy settings in yum.conf and then trying to update. Yum will clearly fail to download repodata, but it will keep trying for all mirrors it knows. Pressing ctrl+c there almost never works since yum only reacts to the signal when it is sent exactely in the instant between when it gave up downloading from one mirror due to timeout and beginning attempting to download from the next. Control-Z bg kill -9 %1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 09:45 AM, Jóhann B. Guðmundsson wrote: Experienced admins dont use service iptables blah anyway ( they use iptables commands directly ) so it hardly matters to them documentation should however be updated for those that actually use service iptables blah to point this out so you should file a DOC bug for it. Actually, many experienced users directly create and put their rules file wherever the iptables service reads it from (historically it is /etc/sysconfig/iptables). Not sure if that has changed - if not JBG is essentially right For those still using iptables command instead, to install the rules in the kernel one at a time, they can then use the iptables-save command to create rules file from already running firewall. But, note that installing rules into the kernel via iptables command one rule at a time is 2-3 orders of magnitude slower than creating the rules file and installing all the rules in one shot. Either way, all you need to do is put them where the iptables service expects to read them from when its started - I would think - all it does it invoke iptables-restore on the rules file - or at least thats the way it used to work :-) gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/15/2012 10:38 PM, Matthew Garrett wrote: We're already building at least one package (hfsplus-tools) with llvm because it relies on non-standard C extensions that gcc doesn't support, and I believe the current software rasteriser in mesa depends on it. In terms of it being the general compiler - it needs to work on all the architectures we care about, it needs to have a level of maintenance in Fedora at least as good as gcc, it needs to build better code than gcc and (most importantly) it needs somebody to actually take responsibility for proving all of that and making the transition happen. Not to mention that the kernel devs use gcc to compile the kernel - and it most certainly puts a lot of pressure on the compiler. I suspect unless linus drops gcc as well, we'll at a minimum need to keep it to build the kernel itself. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux Questions Desktop Environment of the Year - interesting result
On 02/13/2012 03:47 PM, Chris Murphy wrote: Fedora DE vs KDE spin download ratio compared to past release ratios would be more suggestive of a trend, if it exists. Not necessarily - I always used the standard DVD to install and use KDE and frankly never used the KDE spin - not once. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux Questions Desktop Environment of the Year - interesting result
On 02/12/2012 06:19 AM, mike cloaked wrote: http://www.linuxquestions.org/questions/2011-linuxquestions-org-members-choice-awards-95/desktop-environment-of-the-year-919888/ Shows an interesting result in terms of DE popularity - though given the many discussions not only on Fedora lists but on other lists for other distros also I am not really that surprised to see which are the top few in the poll. Interesting poll - of course some will jump on it as a non-scientific and why it's inadequate because it either is too broad an audience or too narrow .. :-) Or perhaps with only 600+ participants the std error may be too high (what is it anyway if one makes reasonable distributional assumptions for the poll takers .. stats quiz :-) ) .. however it jives exactly with my own experience where everyone I know dropped gnome shell and moved to either KDE or xfce (not without grumbling) .. of course my experience is def too small a sample size :-) While it may make sense to make KDE the default DE for fedora - I suspect that this cannot happen in fedora due to pressures from the large number of gnome devs associated with Fedora - or could it? Should it? I wonder if moving Gnome shell as a tablet spin and making KDE the default laptop/desktop DE would have been a really smart move. Is it too late? Perhaps we all really want a phone DE on our 42 inch desktops with a touch screen that somehow doesn't cause muscle strain ... g -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 07:07 AM, Josh Boyer wrote: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. True - however many of us look to fedora as the future RHEL as well. At best, FESCo can tell people no. However, they'd have to know about something bad before it happened, and there are far too many packages to monitor in that fashion under today's setup. josh As a lowly user, there is the impression that creating a sense of urgency late in the cycle and being loud and pushy are good ways to get features in. Sadly, none of those adjectives imply good design or well written software - only claims to same, oftentimes the truth is less so. While I do believe many of the features (as discussed here) have a lot of merit, the way they are arriving in fedora (esp the last year or so) is very disappointing. What can be done? (i) May I suggest new features require a review and comment period with Fesco having the final say. Features that are 'core' - should require substantial review and broader community engagement before being accepted. (ii) Limit major features to 1 per release is also crucial - if that slows dev down too much, then switch to rolling release where testing only allows major feature at a time until that one is solid and moved to production. Only then allow the next major feature into testing. I have watched with some dismay and sadness what is happening to fedora. It can be great again ... however it needs work. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/08/2012 12:37 AM, Kevin Kofler wrote: Adam Williamson wrote: Note that this has not actually been implemented in anaconda yet, so if you do an anaconda upgrade at this time, it will explode horribly. The bug requesting this support be added to anaconda is http://bugzilla.redhat.com/show_bug.cgi?id=787893 . It's totally unacceptable that this feature has been merged in this incomplete state. Working upgrades should have been a prerequisite for merging it! Anaconda upgrades are even part of our release criteria! This affects both the DVD upgrades and preupgrade, which are the 2 upgrade methods Fedora claims to support. Kevin Kofler There seems to have been a recent pattern (last year or so) of pushing premature pet projects rapidly without broader fedora engagement. I know this little issue will get sorted out and its still rawhide/pre-f17. But its part of the pattern. I suspect the pushers feel they are breaking ground and doing good things. I fervently believe many if not all of them are indeed good ideas - just often very premature and the process is poorly managed. All are well intended. For many of us its a bad trend to see - and creates an impression that a few pushy folks are wresting control - rather than things being accepted based on merit and good work. Its a very disappointing thing to see fedora spiraling in this way. I don't know what changed for this to happen but it is not a net positive. Just a personal perspective from a long time fedora user (since about Redhat 3 or so). I don't know what it means for RHEL but I sincerely hope it can learn from these missteps when its facing the decision what to include from fedora .. but I fear its not practical for RHEL to take anything but all of fedora - so if there's a way to improve this, its at the fedora level. That said, extra kudos to the kernel team who have made things better, more stable and still managed to keep pace with current kernel development providing solid, frequent and timely builds all the while contributing to kernel dev itself. Thank you. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Let it go kevin ... I know there are a bunch of gnome happy users (and of course the devs), but there are probably less now than earlier ... A limited sample but everyone I know - all of whom were gnome users - no longer use gnome - they have all switched to either kde or xfce (each with its own issues to be sure). gnome may just kill itself off ... leave it in peace to die or grow in a direction that people will follow. So then the only question that remains is how those useful gnome apps will integrate on the popular DE's ... Market pressure will ensure that useful apps play nice on the dominant DE's ... whether its gnome or something else. so ... don't worry about it ... the market will dictate the right outcome ... :-) I think you might be consider working with app developers / library integrators instead on how to make their apps integrate better ... thunderbird for example could use a little help better integrating with kde desktop. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 09:41 AM, Chris Adams wrote: Once upon a time, Emanuel Rietveld codehot...@gmail.com said: On 02/01/2012 01:32 PM, Panu Matilainen wrote: To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those fake compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - Would it be possible to leave out these provides and fix each individual package to require in the new path instead? It isn't practical to fix every package that requires /bin/sh. There sure seems to be a lot of uncertainty for a feature that is supposedly ready to land. Just asking - does a bind mount of /bin instead of a soft link help? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
What would be the pros/cons of a bind mount instead of a soft link for /bin et al? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/30/2012 05:17 PM, Przemek Klosowski wrote: The argument against rolling upgrades is that it's a wonderful idea early on, but then you run into a morass as time goes on, because of: - difficulty of handling wanted vs. unwanted updates, which in turn creates combinatorially growing number of config permutations (Gnome 3 yes, GCC 4.7 no, KDE 3 no , kernel 3.x yes, etc.) - cruft resulting from rolling upgrades trying to preserve old customizations and 'old way of doing things', as opposed to installing latest shiny stuff from scratch In other words, you have to wait a while and think long term to truly evaluate a rolling upgrade. You have just started, and things are going swimmingly for now, but the clouds are gathering. To some extent yes - on the other hand, one can always re-install a rolling release using the latest install snapshot - so in that sense a rolling release contains a periodic release as a special case anyway ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 12:23 PM, Kevin Fenzi wrote: On Sat, 28 Jan 2012 11:15:11 -0600 Andrew Wyatt and...@fuduntu.org wrote: ...snip... ... I think the way forward is the one I outlined in: http://lists.fedoraproject.org/pipermail/devel/2012-January/161632.html Until those interested can organize and present a compelling case, I fear threads like this one aren't too much use. Possibly - but without the support from at least some of the Fedora core team (fesco, board, key redhatters etc) and possibly some on the RH business side recognizing some potential benefit in the enterprise setting, this is quite likely not to go too far .. and so far I'm not aware of much support for this .. This can of course be because these key folk, after careful consideration, do not see it as a viable choice to make for Fedora and/or ultimately its impact on RHEL. They are, after all, key players for good reason(s) ... I cannot imagine they are not familiar with the pros/cons of such an approach. The benefits/drawbacks of a rolling release are rather well known these days (notwithstanding those that somehow still believe rawhide is a rolling release .. :-) )... Given that, do folks still believe it could be worthwhile for the rolling-releasers to build a case in a wiki somewhere? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 01/27/2012 12:09 PM, Reindl Harald wrote: why in the world is a currently useless feature much more forced than the change of the init-system? perhaps this change is wanted/needed by the new init system for some reason that may not be apparent at the moment ... resource usage aside, even if its not a 'good idea' it doesn't seem like a 'bad idea' does it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/25/2012 10:01 PM, Josh Boyer wrote: On Wed, Jan 25, 2012 at 9:17 PM, Bryan Quigley gqu...@gmail.com wrote: It's pretty simple, really. Basically, if we don't keep the kernel on at least a somewhat recent release the amount of work required to support that release grows beyond what we can realistically maintain. ... Hopefully that helps explain what we're thinking when we go about doing what we do. As usual, sorry for being overly verbose. josh A great explanation - and a nice summary of why a rolling release makes sense for many of the same reasons .. :-) thanks josh! PS - special thanks to you and the kernel team for doing a great job keeping the kernel up to date and purring nicely ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/24/2012 07:24 AM, Richard W.M. Jones wrote: On Tue, Jan 24, 2012 at 11:23:14AM +, mike cloaked wrote: Fedora would appear to be out of line in not taking on board the potential user base for a rolling release version. For servers there would be huge advantages in management of systems. I doubt your claims here. Fedora already has a perfectly good rolling release. It's called Rawhide, and I run it on my laptop. I'd be nuts to run it on a server. exactly - rawhide is not a rolling release as everyone uses the phrase. A rolling release typically has 3 repos - stable, testing and development. rawhide is really on the 'devel' part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/24/2012 07:13 AM, Josh Boyer wrote: How is rawhide not a rolling release? Or perhaps better asked, what about rawhide makes it unsuitable for use as a rolling Fedora release? Actually it is totally unsuitable for a stable rolling release. A rolling release, as most mean it these days, is a stable release - with testing and development repos (rawhide is just the latter). A key point of a rolling release is that it offers a continuous series of smaller changes rather than 1 big change every 6 -9 months (or 2 years in case of enterprise). Once you've installed a rolling release there are no more 'big annoying upgrades' ... really ideal for servers and brilliant for the desktop. For the enterprise - many may prefer quarterly updates rather than huge updates every few years. Further, for those bigger changes (initd, gnome-shell whatever) - one only has to deal with a single thing changing - which can easily be backed out if its a problem (think systemd) - and not the compound impact of multiple large changes. In my view, a rolling release model is the way forward - for foss and enterprise both. It is the standard model for much if not most software devel in the commercial world - as well as the linux kernel, mozilla, google chrome etc). It makes a lot of sense ... and offers a great business opportunity on the enterprise side as well - switching to a rolling release model for fedora could be a really huge win. imho of course :- Fedora suffers an additional problem it seems - not only are there large changes as part of many releases, but lately some of them immediately stop being supported until the 'next big release' - which makes fedora far less reliable and desirable - examples of this are systemd and pulse audio - there may be others. gene - user since RH3. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/24/2012 09:08 AM, Michal Schmidt wrote: On 01/24/2012 02:13 PM, Genes MailLists wrote: Fedora suffers an additional problem it seems - not only are there large changes as part of many releases, but lately some of them immediately stop being supported until the 'next big release' - which makes fedora far less reliable and desirable - examples of this are systemd and pulse audio - there may be others. What the ...? systemd 26 vs 37/38 ... tho you're right yes there were/are some damage control fixes ... which is the point - in a rolling release model things like this would (should) get the proper attention they need, instead of moving focus on to the 'next release' ... The 'old school' approach is/was to delay systemd (as happened in F14 as we all recall) - a rolling release would allow it to evolve in testing until its properly ready - without the constraints of making F14 or F15 ... just allow it to grow up until it is adult enough to slide into stable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/24/2012 02:59 PM, Kevin Kofler wrote: But a fully rolling release just cannot work (and this is also why all those just use Rawhide if you want the latest, usable Rawhide etc. suggestions are fundamentally flawed). Yes, there are distros doing this, but they all have one thing in common: doing a migration like the KDE 4 migration is a big PITA in them. Moving any large change has challenges - whether periodic or rolling. In that sense, they are no different - both can be a PITA. However, in a rolling model you have the advantage of it being the -only- change you need to do .. which is far less an issue than the compound change impact .. and many more people can explore the testing repo with only that one single change, which allows kinks to be worked out sooner. I know you've held this view a while however - when you guys created kde-redhat to allow fedora stable users to explore the 'new kde stuff' - that is exactly how a rolling release works. You've actually been doing it already .. .. :-) Now if Adam W. would just step up again and offer to drive this forward .. Adam? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service and user-agent disclosure - please consider privacy
On 01/11/2012 09:21 AM, Emanuel Rietveld wrote: On 01/11/2012 12:43 PM, Richard wrote: On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote: Fonts are a bigger threat to privacy, see here: http://panopticlick.eff.org/ Maybe I am missing something, but isn't this only relevant if your IP is not visible to the web server? Otherwise, you can trivially be tracked by your IP address. You're probably missing something ... at least pre IP6 world ... IP6 makes you more easily identifiable of course because there is no NAT anymore and thus every machine is identifiable even if not routable. Odd as it is, IP6 reduces privacy - it was not designed with privacy in mind. this scheme identifies you whether or not your IP changes and whether or not there are multiple users behind same IP (imagine a household with 4 users, or a corporation with 5,000 users behind same IP) where NAT is being used. In any case it allows them to identify you - even if you're on a laptop changing IP's all the time ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service and user-agent disclosure - please consider privacy
On 01/11/2012 10:11 AM, Tomasz Torcz wrote: On Wed, Jan 11, 2012 at 10:03:39AM -0500, Genes MailLists wrote: Odd as it is, IP6 reduces privacy - it was not designed with privacy in mind. http://ipv6int.net/systems/linux-ipv6.html#privacy Good point thank you - indeed that helps IP6 not use the MAC address as part of your IP6 address and is very useful - is it on by default now? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.1 being phased out, time for 3.2 in F-16?
On 01/09/2012 07:24 AM, Josh Boyer wrote: a concern over the debug opt Alternatively - just build it without debugging - download the source rpm(s). After installing/setting up the rpm tools, unpack (rpm -iv) the source rpm in ~/rpmbuild/SRPMS dir - then go to ~/rpmbuild/SPEC and do: rpmbuild -bb --without debug --without debuginfo --target=$(uname -m) kernel.spec gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.1 being phased out, time for 3.2 in F-16?
On 01/09/2012 09:38 AM, Genes MailLists wrote: On 01/09/2012 07:24 AM, Josh Boyer wrote: a concern over the debug opt Alternatively - just build it without debugging - download the source rpm(s). ... Of course (should go without saying ... but) the obvious downside to the speed benefit, is the reduction of useful information if there is a problem - so it can be helpful to keep a debug kernel around. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On 01/03/2012 09:16 AM, Denys Vlasenko wrote: # cat /proc/meminfo /tmp/1; killall tracker-store; sleep 1; cat /proc/meminfo /tmp/2; cat /tmp/1 /tmp/2 | grep MemFree MemFree: 1940372 kB MemFree: 1963860 kB As you see, killing it on my machine freed over 23 megs worth of pages. As far as I know tracker is a feature of Gnome 3 - there may be a way to turn it off tho it may need a gnome registry tweak ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd and fstab
On 12/14/2011 07:25 AM, Andrew Price wrote: Hi, From the systemd.mount(5) man page: Mount units may either be configured via unit files, or via /etc/fstab This makes me wonder - to what extent will systemd replace fstab in future Fedoras? Will fstab disappear in favour of systemd mount units? Andy I think that would be a enormous design flaw and abuse of the initd daemon. So, I certainly hope not. init should do one thing and do it well ... the fact that it -can- do something else is a terrible reason to do it. Geez, the kernel can do a lot more user-space stuff - doesn't make it sensible design ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On 11/22/2011 12:13 PM, Matthew Garrett wrote: On Tue, Nov 22, 2011 at 06:00:43PM +0100, 80 wrote: The failure is due to Fedora *non-upstream* versionning scheme, VirtualBox has *already* fixes the API/ABI issue upstream relying on the kernel version (since 3.2 RC). It has nothing to do with the kernel non-stable ABI policy (which is notorious). The least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. The supported way to provide a module for Fedora is to have it in the upstream kernel source. Anything else is explicitly not supported. For those having trouble - one pragmatic way is just to download the f16 3.1.x source rpm and rebuild it on F15 - VB will now work fine. Of course - caution drove the renaming of this kernel to 2.6.41 so it could break ... that said it does work fine for me ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Announcing the release of Fedora 16.
On 11/16/2011 06:21 AM, Gerd Hoffmann wrote: On 11/16/11 11:31, Mathieu Bridon wrote: On Wed, 2011-11-16 at 10:33 +0100, Gerd Hoffmann wrote: On 11/15/11 19:03, Genes MailLists wrote: Its easy enough to build an iso using mock/pungi which will take advantage of all your local packages ... I really don't know that jigdo added anything to that - in fact using pungi you always get a fully updated build without waiting for a jigdo list. jigdo gives you the very same dvd image you can download. Pungi should do the same, if you use only the release repo and the kickstart from the spin-kickstarts package. Perhaps its useful - but about 4 minutes after installing noone has the virgin install anyway ... so the usefulness is short-lived from a bug reproducing / fixing stand ... so it value seems very limited to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Announcing the release of Fedora 16.
Its easy enough to build an iso using mock/pungi which will take advantage of all your local packages ... I really don't know that jigdo added anything to that - in fact using pungi you always get a fully updated build without waiting for a jigdo list. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit vice shell
Also, FYI, you you can disable it (as alternative to deleting): unset -f command_not_found_handle in your .bashrc ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PA 1.0 for FC16?
On 10/08/2011 04:44 PM, Reindl Harald wrote: if there would be much more care by introducing new features/replacements my understanding for the fear of update thmen after that would be much higher as long fedora is shooting out new features without any care if they are really ready fdora should also update them - systemd as best example and no - this is not flaming - this is simply the wish if i get new software which is not really ready but seems good anough for a GA-release i expect updates of this software are more than good enough to be push ASAP This argument makes some sense (if a bit overblown) - we do seem more concerned about not updating than not releasing in the first place - e.g. while its true we delayed systemd - the general noise level suggests it was still not solid enough ... once its released 'core' components get less love coz making changes is bad ... This seems a bit odd ... we're cutting edge - but if the cut smells then its too bad ... I still strongly advocate for a rolling release - where single large core changes can be serialized if need be into the testing repo for as long as it takes to stabilize them (or pulled back out as a unit) - and smaller improvements and bug fixes can continue unimpeded ... now we could be truly leading edge. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/16/2011 05:01 AM, Olav Vitters wrote: On Thu, Sep 15, 2011 at 05:17:43PM -0700, Adam Williamson wrote: True. As far as GNOME goes, though, whenever you suggest 'bulletproof session management', they say 'that's what suspend is for'... I'd like to see proper session management. However, the existing X protocol is terrible (a KDE'er talked about the horrors @ Desktop Summit), and session management itself is really difficult. Temptinh as it might be, just please keep session management away from the init daemon and let it do its one important job properly, robustly and well and not suffer the path to sure death of trying to be all things - just coz it can coz its PID 1,2, 3 etc. :-) Let the Wayland, KDE, LXDE, Gnome etc daemons each deal with their own things. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/16/2011 05:05 AM, Nils Philippsen wrote: On Thu, 2011-09-15 at 14:32 -0400, Genes MailLists wrote: -- (i) Server. -- These run all the time - reboots are most often in maintenance window (or evenings / weekends for home servers) primarily if not soely for kernel updates. *** boot time pain more occasional fsck costs and not service startup Pain caused by O/S updates - rolling release model would be ideal for these. When I was dabbling with HA clustering (which was admittedly a long time ago), there were environments with cold standby nodes (cold as in off). If the hot node went down, the cluster management software switched these standby nodes on, which booted normally then. In that case, a small boot time would have been very appreciated. I'm not sure if such scenarios are used nowadays. Nils Tho for that use case, would not a sleep/awake, as Adam suggested, have been far superior to a cold boot in that case? It could even work to quiesce a system and restore to running state for those processes doing real work without requiring the apps to manage their own restarts ... I assume it was power consumption being lowered here. Fast boot is of course desirable - I don't think anyone is against it obviously, I am merely suggesting it importance is somewhat limited in scope .. I also forgot marketing .. as in .. Fedora boots faster than WingleBuntuDos/X running on same hardware in the MoronIX speed test :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/15/2011 02:14 PM, Bernd Stramm wrote: On Thu, 15 Sep 2011 18:27:29 +0100 Many computers are booted very rarely, once a day or so, and then sit idle for very long periods of time. This is very wasteful. The reason people do this is because booting takes a long time compared to starting the set of applications they use. If you could boot and start applications in say, 1/2 second, usage patterns would be completely different. Possibly for some. I think we need to divide things up into 4 categories (maybe there are more). In my view, for most scenarios startup time is not terribly important at all - for testers and developers it probably can be far more significant. Any speedups are great to have for most, but if the choice was speedup boot/start times or speedup the GUI, or fix bugs or just about anything else ... probably best to spend resources elsewhere ... (assuming resources are fungible, which of course they aren't :-) ) -- (i) Server. -- These run all the time - reboots are most often in maintenance window (or evenings / weekends for home servers) primarily if not soely for kernel updates. *** boot time pain more occasional fsck costs and not service startup Pain caused by O/S updates - rolling release model would be ideal for these. -- (ii) Desktop. -- Often left on, but reboots may happen a little sooner on kernel update. Some turn them off for power consumption or other reasons - not sure what fraction. *** Startup time not too important except possibly for developers - esp kernel devs. -- (iii) laptop. -- typically put into sleep mode for transportation (i.e. close lid). Restart time is extremely fast. Reboots as for (ii). *** Similar to (ii) -- (iv) Virtual Machines -- (a) Server *** Rarely rebooted - otherwise same as (ii) (b) specific needs (e.g. program a remote which needs windows ** boot time not too significant. (c) Testing and development on VM's - *** boot time probably could be important -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 01:42 AM, Adam Williamson wrote: Honestly, if systemd updates has 5% of users failing on an update to the software - we should dump the thing immediately and go back to upstart. That is insanely high bug rate for core code which is (or should be) pretty simple. Rahul was presenting a theoretical example, not an *expectation* that a systemd update would break things for 5% of users. I realize, but that was indeed part of the point of my reply - lets avoid making up things (with or without hyperbole) - and best we can, stick to facts and real issues. More helpful would be people who have tested the newer systemd on F15 to give us a better sample of what, if anything, got worse and/or better as a consequence. Also, I'd be curious if LP felt the risk was high or negligible - since his thoughts should carry more weight on this topic. I assume he would not think 5% of users would have un-bootable systems. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/13/2011 05:58 PM, Rahul Sundaram wrote: On 09/14/2011 02:59 AM, Sérgio Basto wrote: So Fedora guys what you are waiting for ? update systemd please , should I open a report in bugzilla ? I can explain each of your examples but since systemd upstream developer is also the Fedora maintainer, I think he is in a better position to judge when to update.Fedora follows http://fedoraproject.org/wiki/Updates_Policy Not sure what your point is above .. The kernel has undergone more updates than systemd ... all for very good reasons - making it better and solving problems. Sure the same would apply to systemd. Don't the updates look pretty sensible? Perhaps it is a resource problem? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/13/2011 08:34 PM, Jef Spaleta wrote: On Tue, Sep 13, 2011 at 4:13 PM, Genes MailLists li...@sapience.com mailto:li...@sapience.com wrote: The kernel has undergone more updates than systemd ... all for very good reasons - making it better and solving problems. Sure the same would apply to systemd. We also go to some lengths to make sure that there is a fall back kernel on the system by making sure the update kernel is _installed_ in parallel with the running kernel and not _updated_ in the rpm packaging sense. And optionally you can configure your system to hold N older kernels (I have N=6 for testing purposes currently cuz I'm that sort of crazy) ,,, Good points - up to a point - but lets go slow and think for a few minutes - unlike the kernel which is very hardware dependent and therefore may run on many machines but not all, systemd is no - or should not be for its core functionality. Its a piece of software that should run exactly the same way for all hardware - this is certainly true for its core functionality - it does indeed take on additional roles and I have not looked at the source code to see how well / robustly it handles exceptions ... The chances of it failing for a subset of users after being decently tested is way lower than for kernel code - assuming the code is well written and will perform is core functionality even if faced with exceptions in its peripheral functionality (which in my view should be a separate daemon(s) .. never mind that for now .. ) If the code such crap that it cannot handle its core functionality then perhaps we should dump it, and go back to something more robust. but it seems to be handling it ok on F16 ... so far. So, while the argument by analogy to kernel (a dangerous road to take almost always) has some merits, it is not by any means convincing ... And actually if indeed systemd was hardware sensitive - then of course we should have multiple fall backs just like we do for the kernel - but it isn't and it definitely should -not- be hardware dependent ... so having one version should be fine .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/13/2011 09:48 PM, Rahul Sundaram wrote: On 09/14/2011 06:47 AM, Genes MailLists wrote: Good points - up to a point - but lets go slow and think for a few minutes - unlike the kernel which is very hardware dependent and therefore may run on many machines but not all, systemd is no - or should not be for its core functionality. Its a piece of software that should run exactly the same way for all hardware - this is certainly true for its core functionality - it does indeed take on additional roles and I have not looked at the source code to see how well / robustly it handles exceptions ... The chances of it failing for a subset of users after being decently tested is way lower than for kernel code You may very well be right but there is a very high risk involved if it fails for say 5% of the users. I don't see anything in the newer version that justifies taking that risk overriding the upstream developers judgement. Rahul Honestly, if systemd updates has 5% of users failing on an update to the software - we should dump the thing immediately and go back to upstart. That is insanely high bug rate for core code which is (or should be) pretty simple. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/07/2011 09:57 AM, Josh Boyer wrote: %changelog isn't for developers. It's for users to see what the developers changed in the package. Would a git-shortlog suffice for %changelog ? Assuming appropriate comments are required for fedora's git repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/07/2011 12:42 PM, Josh Boyer wrote: Unless of course you meant have fedpkg automatically stick a git-shortlog into the %changelog section of the spec file on commit or something. Then.. maybe. Yah I meant this one .. :-) And yes, this assumes in all cases that developers are actually putting useful information in both %changelog and commit logs. Indeed .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
On 09/07/2011 01:50 PM, Michael Cronenworth wrote: Rich Megginson on 09/07/2011 12:44 PM wrote: git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat the | cat (or | more) is needed because git log will truncate lines This is not what I meant. Upstream may have had 20-30 commits inbetween tags. I wouldn't want to see 20-30 lines of RPM changelog. Seems pretty useful for users to see what changed - curious why not? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 12:00 PM, Miloslav Trmač wrote: On Thu, Aug 25, 2011 at 5:58 PM, Genes MailLists li...@sapience.com wrote: On 08/25/2011 10:28 AM, Nils Philippsen wrote: As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course I really wish developers would not do that - every app should be installable in path/app-name-version - and then we use something like the alternates system (soft links) to get the version we want to run ... we should require this of every app in my view ... That only helps if you are the system administrator of the system and if you know about alternatives. Ordinary users are at mercy of either their system administrator, or the distribution author. Mirek If an app is installable in its own area - it can just as well be /home/foo/ ... just put link (or script or whatever is needed) to have the app know where its base is). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 01:18 PM, Nils Philippsen wrote: Side-by-side means into the same prefix. You can only have one gimp version installed into the /usr prefix, you're free to install a different one into /opt/gimp-x.y or somewhere into your home if you're an ordinary user. Nils Ah thats better .. thanks :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
It could be built to be installed in parallel with 2.6 - which would allow those who want to test/play with it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gimp
Are there any plans to bring gimp 2.7.x - 2.8 into F16 ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 08/22/2011 07:07 PM, Adam Williamson wrote: On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: -Steve Obviously a lot on this list value boot up speed over security! You're making a false assumption, which is that socket activation is only about speed. It's also about resource usage. (There may be other advantages I haven't considered, this is not to be considered an exclusive list.) Mmmm Adam - not sure I'd give up security for a little resource saving either ... if indeed that is the trade-off ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 08/21/2011 05:09 PM, Steve Clark wrote: http://0pointer.de/blog/projects/systemd.html Read the part about Parallelizing Socket Services. It explains why socket actviation is interesting, I find a secure OS interesting. Bootup speed does not matter much to me. -Steve Obviously a lot on this list value boot up speed over security! Obviously, anyone who values security over bootup speed has the right values. I share those values as should everyone who is clueful :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need Little IT advice Here...
On 08/11/2011 11:58 PM, Manuel Escudero wrote: Hi, I was Wondering if there was a tool for Linux in general that let me undo the system changes at reboot or something like that, For example: I want to set a standard configuration in a machine and then let that machine to be used by many users, but as soon as the user Log Out (preferably in that moment) I want the machine to undo all the possible changes the user may have done while he/she was using it. I've seen this behavior on Windows Machines in Schools and Offices, and I know it has something to do about a server controlling all the individual computers but I want to apply that behavior to a Single Linux computer without having the server in the middle... If there's not a General Linux Tool I would like to Know wich distro and desktop enviroment are the best choice to get this done, using what tools, P.S. it's like... Having a customized LiveCD Behavior but with the system installed, so if I need to do changes, I can ensure I can do them without many problems, and then Lock the system again... Hope somebody knows, Sounds like kiosk mode - you may be able to do this with virtualbox - since I've not used linux in kiosk mode - I'll leave it for others who actually know how to explain the way ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Btrfs status for F16
On 08/08/2011 08:55 AM, Josef Bacik wrote: On Mon, Aug 8, 2011 at 8:53 AM, Matej Cepl mc...@redhat.com wrote: On 8.8.2011 14:44, Josef Bacik wrote: I appreciate those who will continue to use it and report bugs, we are working very hard on trying to get everything more stable and it is a slow going process. With your help we will be in a better situation for F17. Thanks, Sounds good ... can you give us an update and ballpark timeline of RAID-5 on btrfs as well if you don't mind? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power and brightness issue
On 08/02/2011 02:41 PM, Adam Williamson wrote: On Sun, 2011-07-31 at 15:37 -0300, Sergio Belkin wrote: I've read http://fedoraproject.org/wiki/Bugs/Common#Laptop_screen_dims_when_switching_to_battery_power_or_idle_mode_but_never_brightens_again My system suffers the same symptoms but I use KDE. So it seems that is not GNOME restricted. Using F15 on x86_64 cat /sys/module/pcie_aspm/parameters/policy default performance [powersave] any ideas? That bug certainly was GNOME specific: it was a bug in gnome-power-manager 's logic. There's no way that specific bug could affect KDE, unless somehow you're running g-p-m in KDE. If you're seeing a similar issue in KDE, it must track down to a different bug, so please file it. Be aware, though, that the display dimming somewhat when you disconnect the AC power is 'normal': both KDE and GNOME do this to save battery power. The bug in this case was that when you re-connected to AC the brightness did not increase again, but if you then disconnected from AC once more the brightness would decrease further - so you got stuck in a descending spiral of darkness until the screen was stuck at its lowest possible brightness setting until you adjusted it manually or rebooted. If the screen dims somewhat (to, say, 50%) when you unplug, goes back up to 100% when you plug back in, then dims back to 50% when you unplug again, that's intended behaviour and not a bug (though if you don't like it, it's configurable). I've seen a different bug on KDE - specifically - after a sleep/resume cycle (I think) - going to battery off A/C - the applet says its in powersave mode but the screen is NOT dimmed - using the applet to switch to performance and then back to powersave mode - dims the screen. This is (as far as I know) specific to KDE but I could be wrong ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On 07/31/2011 12:35 AM, Chuck Anderson wrote: On Sat, Jul 30, 2011 at 11:30:30PM -0400, Genes MailLists wrote: On 07/30/2011 06:49 PM, Dan Williams wrote: ... So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal .. Probably best not to do this - as it can lead to duplicate IP's on the .. No, it cannot lead to duplicate IPs *if the lease is still valid*. If the client has a cached lease, and the lease has not yet reached expiry, then the promise that the DHCP server has made to that client Okidok sure - I read the 'presumptively configure' .. 'if ..server .. rejects renewal' differently ... thanks for correcting. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On 07/30/2011 04:48 AM, Ryan Rix wrote: ... Reading the hackernews comments on it makes me wonder if this is a very good idea. It may work for people in certain usecases, but in the case of Fedora probably not so much http://news.ycombinator.com/item?id=2756952 http://news.ycombinator.com/item?id=2757785 -- Forwarded message -- ... http://cafbit.com/entry/rapid_dhcp_or_how_do Hmm ... the complaint of changing IP does not seem to make sense - as I read the article - the MAC simply remembers server info and instead of a blind dhcp (which causes delays if you are now on a new network as the dhcp server will not NAK a network for which is not authoritative), it ARP's the remembered server first which is very fast - hard to see how this would cause problems (shy of bugs of course)... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On 07/30/2011 10:37 AM, Lennart Poettering wrote: On Sat, 30.07.11 10:31, Genes MailLists (li...@sapience.com) wrote: http://cafbit.com/entry/rapid_dhcp_or_how_do IIRC connman (i.e. NM's competition) can do the ARP magic, too. Lennart Seems like a pretty reasonable thing to do - surely better than just waiting for a timeout to decide if the server is not there ... are you aware of any gotcha's ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji: kernel-2.6.40-3.fc15
On 07/30/2011 12:52 AM, Reindl Harald wrote: Am 30.07.2011 04:29, schrieb Genes MailLists: wasn't there some kind of issue in vm's ? Maybe I'm not remembering correctly no - performance sucks if the VM is stored on a BTRFS formatted disk this is a completly other problem and it must not make a differnece if a FS is used inside or outside a virtual machine, not in 2011 the BTRFS-FS in this VM survived two dist-upgrades until now :-) Ah right - that rings a bell now :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On 07/30/2011 06:49 PM, Dan Williams wrote: NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient is Cool - so is NM already pretty optimal for the case when one sleeps a laptop - and wakes it up in a new wireless domain? How does it know the dhcp server is still there when the laptop has moved on? What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal. Probably best not to do this - as it can lead to duplicate IP's on the network - even if briefly - wasn't something like this an issue with some smartphones and princeton univ wifi - and led to them banning android for whatever version had the problem ? http://code.google.com/p/android/issues/detail?id=11236 Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location. I tend to wake mine up in new locations a lot ... NM doesn't seem to take very long to latch onto the new one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji: kernel-2.6.40-3.fc15
On 07/29/2011 10:16 PM, Dave Jones wrote: On Sat, Jul 30, 2011 at 01:16:43AM +0200, Reindl Harald wrote: i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since some minutes, boot looked fine, after a minute a got a btrfs-stack-trace hope this helps (no i do not tend use btrfs in production *gg*) hmm, doesn't look like that one has been reported before. Can you file this in bugzilla please ? I expect Josef will want to take a look at it next week. thanks, Dave wasn't there some kind of issue in vm's ? Maybe I'm not remembering correctly. Dave - how is the 2.6.40 code different or not from 3.0.0-2 ? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji: kernel-2.6.40-3.fc15
On 07/29/2011 10:41 PM, Dave Jones wrote: On Fri, Jul 29, 2011 at 10:29:58PM -0400, Genes MailLists wrote: wasn't there some kind of issue in vm's ? Maybe I'm not remembering correctly. too vague to comment. there are always 'issues in vm's :) Ha ha .. actually I have a feeling now it was a performance issue w btrfs in vm's ... but that is a vague thought ... :-) Dave - how is the 2.6.40 code different or not from 3.0.0-2 ? pretty much the same thing. Josh added a udl patch to f16 after I kicked off the f15 build. Likewise I added a scsi patch to f15 but didn't get around to adding it to 16. they'll sync up soon. Dave Cool thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 06:17 AM, David Sommerseth wrote: However, I find ~/.local an odd name. To whom or what is it 'local'? If you have home directories mounted via NFS and log into two different remote hosts via SSH - the only base is local to, is the user. But if you start a program which is installed on server but lacks global libraries on the other server, then this program is suddenly local to a particular server in addition. My point is that local is very ambiguous and its name is poorly chosen. But I realise it's way too late to change ~/.local to anything now. This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: On 07/28/2011 12:46 PM, Genes MailLists wrote: This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). Currently Fedora only separates out the /lib* directories in multilib installations - you'll find a mix of 32 and 64 bit binaries in the system binary paths on these systems. which is fine for a 'system' which is 64 bit and may support 32 bit as well - its not fine for a 'user' who logs in to a 32 bit machine from a 64 bit machine and now his binaries wont work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 08:41 AM, Genes MailLists wrote: On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: On 07/28/2011 12:46 PM, Genes MailLists wrote: This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). Currently Fedora only separates out the /lib* directories in multilib installations - you'll find a mix of 32 and 64 bit binaries in the system binary paths on these systems. which is fine for a 'system' which is 64 bit and may support 32 bit as well - its not fine for a 'user' who logs in to a 32 bit machine from a 64 bit machine and now his binaries wont work. In the same way as an NFS mounted /usr/local/bin which only had 64 bit binaries would not be a lot of use on a 32 bit machine. It can be dealth with of course - what I've seen in this case, is either 2 different mounts or making both available and having the PATH adjust as needed. Add to that different architectures and the PATH way gets nasty fast. My preference is for the machine to mount the right one under /usr/local (or /usr/share or whatever. For user level .local/bin[64] there are different approaches I imagine - for one its not hard to adjust the PATH in this case based on uname -m or similar. However, having .local/bin under NFS home is a more complicated case for sure and probably is just plain wrong without some architecture recognition - so the standard looks ill conceived from this regard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 09:09 AM, Bryn M. Reeves wrote: On 07/28/2011 01:41 PM, Genes MailLists wrote: On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: On 07/28/2011 12:46 PM, Genes MailLists wrote: This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). Currently Fedora only separates out the /lib* directories in multilib installations - you'll find a mix of 32 and 64 bit binaries in the system binary paths on these systems. which is fine for a 'system' which is 64 bit and may support 32 bit as well - its not fine for a 'user' who logs in to a 32 bit machine from a 64 bit machine and now his binaries wont work. Separating bin paths like this would not solve the problem; anything that's only present in one path or the other would still fail in the scenario you suggest. You could equally install foo/foo64 or vice versa into the same directory. I don't follow your thought here - if you have a bin64/ and a bin/ etc and you have your shell initscripts decide (e.g. using uname -m) which of those to include in your PATH I think it does work ... provided you have (obviously) both (all) populated with whats needed... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 12:36 PM, David Sommerseth wrote: I don't follow your thought here - if you have a bin64/ and a bin/ etc and you have your shell initscripts decide (e.g. using uname -m) which of those to include in your PATH I think it does work ... provided you have (obviously) both (all) populated with whats needed... But that is still going to be a convoluted mess. For those poor users who then have access to arm, ia32, ppc64, s390x and x86_64, you suddenly need 5 different ~/.local/bin directories ... And I've probably forgotten some arches. I concur - I voted against this proposal :-) - the arch stuff just reinforces why its not a good design whenever there are any binaries involved .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/27/2011 12:19 PM, Lennart Poettering wrote: On Wed, 27.07.11 17:40, Roman Rakus (rra...@redhat.com) wrote: Hi all, from the discussion here, I'm tempted to revert the change. Any objections? Yes. I am for keeping it in, and have prepped a patch for XDG basedir to make it official. What actually is the benefit of doing this? Why does xdg need the shell have the PATH env include this - if xdg wants to use a fixed path - then should it not use a fixed path and not require specific PATH environment anyway? There seem to be 2 issues here which are being mixed up it seems to me ... (i) merits of putting binaries in a .local/bin area for xdg convenience (or whatever) (ii) need to have that same area be in the default PATH. (i) does not imply (ii) at all. So I vote to remove it from the default shell path. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/27/2011 05:00 PM, Jesse Keating wrote: On 7/27/11 1:09 PM, Reindl Harald wrote: Depends on the PATH-Order if something is intended to be first in PATH and any attacker is able to write there his ls would win against /bin/ls So, the attacker can write a compromised ls into .local/bin/, but isn't able to modify your .bash_profile ? Seems like a stretch. Yeh its a bit of a stretch - but it is a little bit easier for a blackhat to drop a file somewhere than to edit/replace a specific existing file (which could/should be rx not rwx) ... (think phishing) .. but still getting it to a damaging place can be more tricky ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 01:23 AM, Adam Williamson wrote: What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. Be a little wary. This is not really fine - systemd should do one thing and do it well ... when it starts to bleed off and try do too many things (with little to zero rationale or benefit) then the chances of things going wrong increase. Just because something 'can' do something does not make it a sensible design. Since systemd is running daemon it could take over any daemon - it could even do everything pulse does :-) Hell any rooted capable daemon process can do the same - autofs could just as easily start other services for that matter ... doesn't make it a good design. Just coz it is doing some mount stuff doesn't mean it should do all mount stuff ... autofs should be left alone to do what it does best. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On 07/26/2011 08:03 AM, Misha Shnurapet wrote: 26.07.2011, 18:34, Andrew Haley a...@redhat.com: On 26/07/11 10:22, Misha Shnurapet wrote: Since F15 ~/bin has been added to PATH, and commands that are supposed to run user scripts will work without changing into that directory. Meanwhile, ~/.local/bin isn't used. I'd like to propose that it is also added because technically it is ~/bin's brother. I've never heard of ~/.local/bin . Are there many people who use this? ~/bin is common. ~/.local/bin has been there by default. Unlike ~/bin, which is in PATH though not even created. Where in the path do the user 'bin' elements appear in the path? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On 07/26/2011 09:15 AM, Robert Marcano wrote: In /etc/skel/.bash_profile they are added to the end and I think that is ok PATH=$PATH:$HOME/.local/bin:$HOME/bin Never knew about ~/.local/bin my .bash_profile is really old from the time where the default was only ~/bin Mmm ok ... Can I assume root is excepted from this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On 07/26/2011 09:34 AM, Emmanuel Seyman wrote: * Genes MailLists [26/07/2011 15:32] : Mmm ok ... Can I assume root is excepted from this? You can. That is the case. Emmanuel :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/26/2011 03:34 PM, Lennart Poettering wrote: I don't think it makes a lot of sense to have a visible directory for binaries. People will see that, and be annoyed. Perhaps, but hiding things annoys many people more ... not a huge deal as .config is not too hidden anyway ... Note that there are a number of 3rd party projects making use of ~/.config/bin afaik, including jhbuild which installs its executable to that dir. At the moment we have apps writing to both .config and .local/share which seems ugly to me ... should these be merged ? There def seems to be a lot of stuff in .config ... but slightly better would be ~/config/bin (not .config) and it would only contain links to ~/config/app/bin/foo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15: ugly behavior of df
On 07/21/2011 07:09 AM, Steve Clark wrote: Well what benefit(s) does the new 'df' provide, is it worth all the pain it brings? I concur - the current df behavior is well .. goofy :-) - however this may be tricky to fix in the new world - but should be fixed. If this behavior is somehow desirable it would be preferable to make it an option (like df --full or whatever) and make the default something more sensible. That said, it may be tricky in the new world; where can you retrieve the info about a mount being a bind mount ? How can you push the chrooted bind mounts into being less obtrusive (or even optional, --show-chrooted-mounts) /proc/mounts does not seem to distinguish bind mounts - so this may have to be a kernel change and perhaps adding /proc/mounts/bind and moving bind mounts 1 level down - this is not an area I know a lot about however, so I'll leave this to the real experts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
I think RAID-5 support would be reasonably important to have too ... I dont think we want to have raid on top of btrfs ... right? Ric - what is the current status of RAID-5 ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/14/2011 10:17 AM, Ric Wheeler wrote: On 07/14/2011 02:54 PM, Josef Bacik wrote: On Thu, Jul 14, 2011 at 9:08 AM, Genes MailListsli...@sapience.com wrote: I think RAID-5 support would be reasonably important to have too ... I dont think we want to have raid on top of btrfs ... right? Ric - what is the current status of RAID-5 ? This requires some other big changes that are disk format changes. It seems like the big block support will go into 3.1, so after that it should be relatively shortly after that, possibly 3.2 or 3.3. Thanks, Josef And just to add in here, you can run btrfs on top of MD devices although that is not the most popular thing to do currently. Ric Thanks Josef/Ric - Another (Q) - once the format changes, will there be tools to change the online format of existing filesystems - or will we need to delete and start fresh ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/14/2011 10:59 AM, Josef Bacik wrote: Another (Q) - once the format changes, will there be tools to change the online format of existing filesystems - or will we need to delete and start fresh ? All format changes happen automatically (usually with a mount option so as not to surprise users) online so there's nothing that needs to be done beyond giving the special mount option. Thanks, Josef Hah - excellent - thank you! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/14/2011 11:12 AM, Eric Sandeen wrote: Something tells me if btrfs had been called ext5 people would just nod their heads and move on. ;) Heh ... like this ... Its not too late is it :-) How about ext5-btrfs - and high level user space tools can shorten it to ext5 :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/10/2011 07:08 PM, Jóhann B. Guðmundsson wrote: ell variables has always had a default value of the empty string.) It achieves afaict the behavior the maintainer wanted if it was up to me I would have done this ( whole nfs ) completly differently Dropped ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT ExecStartPre=/sbin/sysctl -w $LOCKD_UDPPORT Completely and having administrators add and to set these values manually in /etc/sysctl.conf as I mentioned in comment 30. I don't agree with this approach actually. Doing it this way means that we now have dependencies for the daemon spread into non-obvious places not directly associated with starting the daemon. It is much better to do this in a single place that associated with the daemon in question - and not have a somewhat hidden dependency in a generic config file. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/10/2011 07:31 PM, Jóhann B. Guðmundsson wrote: Let's just aggree on disagreeing about this approach anyway the last unit file I submitted does what Steve and you and perhaps many others want's it to do afaik... To be clear - I have as yet no views on systemd unit files et al here - just saying its healthy to keep things coherent. So my comment is limited to your specific suggestion of breaking things apart. In fact I'd prefer a world where every app config file belonged directly with the app and not elsewhere - for one thing this supports having multiple versions of apps whereas if there is a single config (/etc/app.conf) this does not cleanly support multiple app versions. Compare with: /usr/lib/app-v1/ etc/app.conf bin/app ... etc /usr/lib/app-v2/app.conf etc/app.conf and one can eve make a default versions via soft links much as the alternates scheme does: /etc/app.conf - /usr/lib/app-v1/etc/app.conf etc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/10/2011 09:39 PM, Steve Dickson wrote: Completely and having administrators add and to set these values manually in /etc/sysctl.conf as I mentioned in comment 30. I don't agree with this approach actually. Doing it this way means that we now have dependencies for the daemon spread into non-obvious places not directly associated with starting the daemon. I do to agree with this... Instead of simply editing one file /etc/sysconfig/nfs, they know have to edit multiple files which goes back to my easy-of-use argument... Something that seems to be ignored... steved. I think you're agreeing with me not disagreeing ... :-) - I a saying separating things into multiple places is not ideal .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
On 07/08/2011 04:47 AM, Paul F. Johnson wrote: Hi, Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. .. Any ideas? Probably should be users list not dev (unless you're running rawhide) - but see if yum clean packages does anything. Also take a look in /tmp and /var/tmp if that doesn't take care of it. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/08/2011 10:06 AM, JB wrote: This entry is passed to systemd for execution, as is ! It is the responsibility of systemd to parse it, determine what entry it is (you could put in there any garbage, perhaps a virus, rootkit, etc), then if a valid executable entry then it should validate its syntax and arguments (are you still here, Johann ... ?!), and if not valid the entry should not be executed, that is aborted or error completion code returned to calling env. That sounds extraordinarily unreasonable to me. If the unit file is broken with bad input it is broken - it is not systemd's job to detect/fix bad input to an application - it should do what it is being asked to do and run it as per the inputs in the file. If the application fails due to bad input then systemd should (and presumably does) report the failure that the application itself reports to systemd. Systemd cannot possibly know what valid arguments and syntax are/might be for every application existing and not yet written - and should not. Thats the job of each application itself - to exit with an error if the inputs are bad and then systemd should report that error information. systemd does enough - leave it alone :-) gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On 06/30/2011 12:16 PM, Jeff Spaleta wrote: On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmosk...@redhat.com wrote: - I was afraid, that it would be against some Fedora policy ;) Then just the rawhide.. Okay if this isn't coming to F15, can you provide the sufficient instructions on how to revert the libreport packages from F15 updates testing so that the packages that require report-gtk will work properly again. I'm not pointing fingers. I just want to know, from you, the package maintainer, how to back out of the semi brokenness introduced by the malformed obsoletes in the updates-testing package that is now a dead end if this isn't going to firm up as an official update. Actually I'd prefer to know how to move forward to the new way ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On 06/30/2011 12:16 PM, Jeff Spaleta wrote: On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmosk...@redhat.com wrote: - I was afraid, that it would be against some Fedora policy ;) Then just the rawhide.. Okay if this isn't coming to F15, can you provide the sufficient instructions on how to revert the libreport packages from F15 updates testing so that the packages that require report-gtk will work properly again. I'm not pointing fingers. I just want to know, from you, the package maintainer, how to back out of the semi brokenness introduced by the malformed obsoletes in the updates-testing package that is now a dead end if this isn't going to firm up as an official update. Am I misremembering? I recall an official update which broke sealert - the libreport fix from updates testing never installed as it was broken and never was pushed stable. So now F15 stock with official stable updates only, has a broken sealert (maybe other things). Whats the way forward from here in F15? gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On 06/30/2011 08:26 PM, Adam Williamson wrote: Well, updates-testing is 'you get to keep both halves' territory. wasn't it stable that broke things (sealert stopped working for example after a stable update) - and then something from updates testing was supposed to fix it? But it never made it to stable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] replacing report with libreport
On 06/30/2011 10:44 PM, Adam Williamson wrote: On Thu, 2011-06-30 at 22:04 -0400, Genes MailLists wrote: On 06/30/2011 08:26 PM, Adam Williamson wrote: Well, updates-testing is 'you get to keep both halves' territory. wasn't it stable that broke things (sealert stopped working for example after a stable update) - and then something from updates testing was supposed to fix it? But it never made it to stable. I dunno, I kinda lost track. You might be right! hah ... :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
i915 errors from 3.0 kernel
I am getting a lot of these in kernel 3.0-0.rc5.git0.1.fc16.x86_64 testing on F15 - i915 - happens on wake from sleep I think. Is this advisory/benign or a problem ? thanks gene/. -- /var/log/messages -- Jun 29 08:37:25 lap3 kernel: [72538.407300] [ cut here ] Jun 29 08:37:25 lap3 kernel: [72538.407305] WARNING: at drivers/gpu/drm/i915/i915_drv.c:322 gen6_gt_force_wake_ge t+0x2a/0xa3 [i915]() Jun 29 08:37:25 lap3 kernel: [72538.407306] Hardware name: 4270CTO Jun 29 08:37:25 lap3 kernel: [72538.407307] Modules linked in: tcp_lp fuse ebtable_nat ebtables ipt_MASQUERADE ip table_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc hidp sunrpc cpufreq_ondemand acpi_cpufreq freq_table m perf capi kernelcapi rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_connt rack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xts gf128mul dm_crypt arc4 uvcvideo videodev media v4l2_compat_ioc tl32 microcode btusb bluetooth snd_hda_codec_conexant joydev xhci_hcd iwlagn mac80211 snd_hda_intel snd_hda_codec iTCO_wdt i2c_i801 snd_hwdep cfg80211 snd_seq snd_seq_device iTCO_vendor_support snd_pcm snd_timer e1000e snd_pag e_alloc thinkpad_acpi rfkill snd soundcore virtio_net kvm_intel kvm sdhci_pci firewire_ohci sdhci firewire_core m mc_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Jun 29 08:37:25 lap3 kernel: [72538.407334] Pid: 24420, comm: kworker/u:15 Tainted: GW 3.0-0.rc5.git0.1 .fc16.x86_64 #1 Jun 29 08:37:25 lap3 kernel: [72538.407335] Call Trace: Jun 29 08:37:25 lap3 kernel: [72538.407337] [81057b0c] warn_slowpath_common+0x83/0x9b Jun 29 08:37:25 lap3 kernel: [72538.407339] [81057b3e] warn_slowpath_null+0x1a/0x1c Jun 29 08:37:25 lap3 kernel: [72538.407345] [a006b4d7] gen6_gt_force_wake_get+0x2a/0xa3 [i915] Jun 29 08:37:25 lap3 kernel: [72538.407351] [a0075a54] i915_read32+0x34/0x6b [i915] Jun 29 08:37:25 lap3 kernel: [72538.407358] [a0077f7c] i915_save_state+0x170/0x1e9 [i915] Jun 29 08:37:25 lap3 kernel: [72538.407364] [a006b07b] i915_drm_freeze+0x7b/0x95 [i915] Jun 29 08:37:25 lap3 kernel: [72538.407370] [a006b25e] i915_pm_suspend+0x55/0x77 [i915] Jun 29 08:37:25 lap3 kernel: [72538.407372] [812763dd] pci_pm_suspend+0x7d/0x100 Jun 29 08:37:25 lap3 kernel: [72538.407373] [813278d1] pm_op+0x8b/0x149 Jun 29 08:37:25 lap3 kernel: [72538.407375] [81327b3d] __device_suspend+0x150/0x1cc Jun 29 08:37:25 lap3 kernel: [72538.407376] [81327bd8] async_suspend+0x1f/0x47 Jun 29 08:37:25 lap3 kernel: [72538.407378] [8107b928] async_run_entry_fn+0x9e/0x132 Jun 29 08:37:25 lap3 kernel: [72538.407380] [8107b88a] ? async_schedule+0x17/0x17 Jun 29 08:37:25 lap3 kernel: [72538.407382] [8106ff45] process_one_work+0x1ce/0x379 Jun 29 08:37:25 lap3 kernel: [72538.407384] [8106fec4] ? process_one_work+0x14d/0x379 Jun 29 08:37:25 lap3 kernel: [72538.407386] [81070c45] worker_thread+0xda/0x15d Jun 29 08:37:25 lap3 kernel: [72538.407388] [81070b6b] ? manage_workers+0x175/0x175 Jun 29 08:37:25 lap3 kernel: [72538.407390] [81070b6b] ? manage_workers+0x175/0x175 Jun 29 08:37:25 lap3 kernel: [72538.407392] [810745e1] kthread+0xa8/0xb0 Jun 29 08:37:25 lap3 kernel: [72538.407394] [814fb324] kernel_thread_helper+0x4/0x10 Jun 29 08:37:25 lap3 kernel: [72538.407396] [814f39d4] ? retint_restore_args+0x13/0x13 Jun 29 08:37:25 lap3 kernel: [72538.407398] [81074539] ? __init_kthread_worker+0x5a/0x5a Jun 29 08:37:25 lap3 kernel: [72538.407400] [814fb320] ? gs_change+0x13/0x13 Jun 29 08:37:25 lap3 kernel: [72538.407401] ---[ end trace 33a887dd07d385e2 ]--- Jun 29 08:37:25 lap3 kernel: [72538.407675] [ cut here ] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i915 errors from 3.0 kernel
On 06/29/2011 01:22 PM, Adam Williamson wrote: On Wed, 2011-06-29 at 12:58 -0400, Genes MailLists wrote: I am getting a lot of these in kernel 3.0-0.rc5.git0.1.fc16.x86_64 testing on F15 - i915 - happens on wake from sleep I think. Is this advisory/benign or a problem ? It's benign. We go through this every time we go from a release kernel to a development kernel: these warnings are enabled in development kernels. It is just a warning about sub-optimal behaviour, useful to kernel developers, not at all fatal or particularly problematic to your use of the system. I thought so - glad its benign ... I assume the messages will sometimes be useful to the kernel team ... so should I keep mentioning new ones or only if its an actual OOPS? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i915 errors from 3.0 kernel
On 06/29/2011 01:48 PM, Dave Jones wrote: On Wed, Jun 29, 2011 at 01:40:06PM -0400, Genes MailLists wrote: I thought so - glad its benign ... I assume the messages will sometimes be useful to the kernel team ... so should I keep mentioning new ones or only if its an actual OOPS? If you have abrt installed it will file bugs where necessary, (and also take care of dupes so you won't have to search for them first). Dave Okidok .. thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On 06/24/2011 04:07 AM, Rahul Sundaram wrote: On 06/24/2011 12:55 PM, JB wrote: JB jb.1234abcd at gmail.com writes: http://en.wikipedia.org/wiki/Trusted_computing TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around trusted computing. If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that His point is rather obvious really not sure why you're picking on him - many may be unfamiliar with this and he spent time finding out and sharing what others, who have thought about this topic, have to say. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/20/2011 01:22 PM, Paul Wouters wrote: ... gnome3 was not driven by user feedbak. It was driven by getting vendors to install it on factory shipped netbooks. Perhaps, tho I suspect Android won that market already ... but perhaps its worth a shot, things can change. Again, I'm skipping F15 in the hopes that F16 corrects most of these shortcomings and provides a useful interface again to do more then a single task out of a selection of 3 common tasks. Not sure why people would want to fiddle with 3rd party extensions especially when the API has no guarantees of stability and the extensions live outside the core ... you keep the pieces when it breaks. Did you try some of the other DE's? I am finding KDE surprisingly decent as an upgrade from Gnome-2 ... and others seem to be happy with xfce or lxde ... was a shortish learning curve but I am finding no lack of functionality in KDE that I had in Gnome 2. Many Ubuntu folk are not happy with Unity either .. so perhaps the needs will be more clear and things will improve to make things better for you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/17/2011 11:36 PM, Evandro Giovanini wrote: those who are want to rewrite/modify GNOME3. No, I'm not. There are several working extensions *today*, I'm simply suggesting that people not 100% satisfied with the default GNOME 3 experience go out there and experiment with them. It's definitely easier to install an extension even today than to migrate to an entirely different distribution with a completely different desktop environment and default set of applications. I don't agree with this at all - and you don't need to switch distros unless systemd drives you up the wall - its way easier to switch from Gnome 2 to KDE than it is to switch to Gnome 3/Shell + fiddling with extensions. You have no choice but to change DE's now - Gnome 3 is just one choice - the others may offer more functionality and be a simpler transition - as a Gnome user thats what I am finding. I'd say its definitely easier to change to KDE or XFCE than to Gnome 3hell (speaking as an F14 gnome 2 user). 3rd party extension stuff - who is checking the code for privacy/security issues anyway? From my perspective so far changing from Gnome-2 to KDE is an easier and less obstructive change than to Gnome 3hell. I have installed and plan to try LXDE and XFCE as well ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :) = vnc
On 06/14/2011 02:32 PM, Nathanael D. Noblet wrote: On 06/14/2011 11:24 AM, Genes MailLists wrote: Its worked super well for me (though less well with GNOME3's effects etc)... Can you point me to what you mean by the usual info into xorg.conf? to be clear, I don't want to run *my* session over VNC. I want to be able to connect to a remote users *current* session to see and control their computer (while they see what I'm doing)... Does your message still apply? Yes it does - you'll need the vnc server package on the end you want to view/control ... # # Minimal xorg.conf for vnc on root display # Section Screen Identifier Screen0 Option passwordfile /usr/local/etc/vnc/password EndSection Section Module Load vnc EndSection Password file is created using vncpassword if I remember correctly. I assume its either local intranet - or you've ssh tunneled port 5900 to be visible on your client machine where you're running vncviewer if your doing this over the internet. regards gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics = systemd
On 06/13/2011 03:13 AM, Lennart Poettering wrote: ... systemd surpasses Upstart in every way. It's not in an early state. Upstart is much more limited and hence in a much earlier state feature-wise. ... Lennart Superior design - yes I like it - but in practice there are still some issues like these which remain quite problematic - for example: 2011-03-30: NFS Status unresolved https://bugzilla.redhat.com/show_bug.cgi?id=692008 2010-09-14 - Sendmail Some Network Dependent Daemons not started at boot: Status - unresolved. https://bugzilla.redhat.com/show_bug.cgi?id=633774 I assume these will get resolved and its not surprising at all that problems occur - but the sendmail one seems to have been hanging around for nearly 9 months ... worrisome and a bit long for a core service don't you think. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On 06/13/2011 11:39 AM, Stephen John Smoogen wrote: . At this point I am going to ask for someone from the Community Working Group to step in and see how we can better get along here. If you have a problem with that, I think it would be better if you took some time off and did something else for a couple of hours/days. I agree - we can disagree on issues (technical, design or whatever) but lets keep this discourse professional. Sure, there are issues - there are and always will be - but tone it down and try be constructive not destructive in communicating your thoughts and concerns. We all understand the emotions that hit you when things don't work they way you want ... so contribute and help make it better - just yelling and complaining about how -you- are impacted is not the way. Be polite - be respectful ... be a partner with all the other Fedorians (Fedorans? Fedoronians ? Fedoras ? Fedorafolks?) You've had polite responses in varying degrees - take the cue - be constructive even when being critical which is healthy if done right. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On 06/13/2011 08:54 PM, Scott Schmit wrote: Not addressing specifically the issue with the kernel updates, but at least in part, the answer is simple: * Within a release, updates should try very hard to avoid breaking things. * Between releases, upgrades can change a lot. These changes are advertised so that users can decide if/when they want to upgrade. and the kernel is really not a big deal because the updates are normally not invasive Not in my experience--I have had on occasion crippling kernel bugs that come and go from update to update (hangs with no oops recorded to the log, for example). Thankfully, that's rare, but I'd argue that it's *because of* that conservatism, not in spite of it. The upstream kernel is a rolling release with Linus' law of protect users as much as possible. While a fresh released kernel in stable often gets a few updates and fixes the .1 or .2 stable kernels are generally remarkably solid. This is in large part attributable to the rolling release model. Fedora could well benefit from switching to a rolling release model as well (no not rawhide - a controlled rolling release much as the kernel development follows). gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
On 06/12/2011 12:00 PM, Reindl Harald wrote: is there any clean way to get newer intel-graphics drivers on fedora 14? performance is horrible and under kde the desktop often hangs for some seconds this is nothing i would expect with http://ark.intel.com/Product.aspx?id=52213 I have done this and its working - I've used rawhide with 2.6.39 kernel and also F15. See my comments below. I'll describe what you need to do using subset of F15. You need newer kernel, xorg* and mesa*. If you pull these from f15 you'll find that the compiler has changed - and you will need a newer compiler - which is fine. You'll also need - as you discovered newer glibc - which is also fine. Back up your system - and then do this: yum --releasever=15 install kernel* xorg* mesa* perf* You'll need to so something like: yum --releasever=15 update kernel* xorg* mesa* perf* yum update to do your updates so you keep picking up just the F15 pieces you need. For me I could not boot the F14 install DVD at all - so I made my own DVD using F14 plus all the pieces frmo F15 which yum tells you you need to satisfy the above. The F15 kernel still seems to have a problem with the rhgb for me using i915 (hardware has nvidia optiumus with nvidia turned off) - a bug which has popped up now and again since 2007 - it seems not to be a problem with 2.6.39 and later kernels - but you wont find a 2.6.39 in koji or rawhide at the moment. (Bug is in rhgb best I can tell) So remove the rhgb out of the kernel line in /boot/grub/grub.conf for the new f15 kernel you installed. The sympton if you dont is machine hangs when it flips rhgb after plymouth has done its thing ... if you look in you /var/log/Xorg.0.log you'll see something like: Xf860OpenConsole: VT_WAITINACTIVE_FAILED: Interrupted system call THe work around is avoidning rhgb for now ... Once kernel-3.0 has settled - that is likely your best bet. I have this working using F15 but am planning to move to 3.0 kernel as soon as its settled down a bit - you'll find the fedora team working hard to get a decent 3.0 kernel in koji. regards gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
On 06/12/2011 07:59 PM, Reindl Harald wrote: I have done this and its working - I've used rawhide with 2.6.39 kernel and also F15. See my comments below. I'll describe what you need to do using subset of F15. this forces a GLIBC-Upgrade, see my others posts Yes - I said the same thing below and its needed for good reason - and the newer glibc provides everything needed by the older other f14 binaries - and its fine. You need newer kernel, xorg* and mesa*. and GLIBC from F15 on F14 this does not work It is working for me .. sorry it isn't for you. this means change the whole core-system to an undefined state in the worst case this will damage your whole setup or future-security-updates are not possible if dependencies are changing again It is a perfectly defined state - don't be confused - it is F14 plus some updates. I also showed exactly how to do all updates on an ongoing basis to keep it updated and get all security updates - and keep things in a perfectly defined state ... it is working for me .. Perhaps this is not the way for you if you find it confusing ... my suggestion then is deal with systemd and its bugs/quirks or perhaps install F15 and replace systemd with upstart - that should work the same as f14 + a few f15 packages. Do whatever works for you ... you could try even the new ubuntu if its mesa and xorg are enough up to date. good luck! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
On 06/12/2011 08:40 PM, Reindl Harald wrote: Am 13.06.2011 02:29, schrieb Genes MailLists: Perhaps this is not the way for you if you find it confusing ... my suggestion then is deal with systemd and its bugs/quirks or perhaps install F15 and replace systemd with upstart - that should work the same as f14 + a few f15 packages. you should read the thread! I read the thread - you did not do what I suggested - you did something different ... be that as it may ... I have done this both as an update as an install from a DVD built using mock/pungi which contains F14 fully updated + all the f15 rpm's needed to satisfy the packages I put in my first email. I hear your pain - there is a reason many I know have moved away from F15 - anyway - I have sandy bridge running, as I said,using fully updated F14 + selected packages from F15. YYour hardware may be different - so you may need different things. Good luck. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 06/09/2011 06:37 PM, Dave Jones wrote: On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: Long list already from others but a couple of other things that are nice (dont know if qemu has these today, but didn't used to) (i) Variable size image for the VM - it grows to accommodate need (ii) Easy to duplicate VM image (with UUID change) So its easy to deploy images on same or different computers (iii) All VM data is stored in user home This means installing a new OS does not negatively impact VM's (iv) Control over the network There are some cons - I have had it go crazy and exhaust memory - I have had problems deleting an intermediate snapshot causing troubles for later snapshots - but overall its easy to use and generally works. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:13 PM, Rahul Sundaram wrote: what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul Beg to differ - rather vehemently too - politely but vehemently. systemd is only available in fedora[1] - we are the test pigs for better or for worse - and there are most certainly bugs in fedora's systemd. Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for systemd. Some bugs like sendmail failing to start have been there since September 2010 ( almost 9 months ... ) - people are reporting the same issue on F15 in the fedora lists ... who is fixing this stuff ? e.g. https://bugzilla.redhat.com/show_bug.cgi?id=692008 https://bugzilla.redhat.com/show_bug.cgi?id=633774 Ok so he's on vacation - this is a very core part of the OS - who is backing him up I wonder? Who else is on the project? Surely you're not saying there is no-one else working on systemd... and when LP is away/busy nothing will get done ... otherwise I strongly urge it be replaced by upstart asap. gene/ [1] Yes he spoke with another distro - but no-one is using it. So its a fedora only project until its picked up somewhere else - which has not happened yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
On 06/02/2011 04:44 AM, Jaroslav Skarvada wrote: - Original Message - 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav Thanks - I did file a bug and see that you replied to the bug too - so thanks. (my bugzilla account name is a bit diffderent :-)) gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
On 06/02/2011 10:32 AM, Michael Cronenworth wrote: On 06/02/2011 09:07 AM, seth vidal wrote: +1 - I've found the impact of bash completion on disconnected machines to be negative. I don't install it anymore for that reason. Sounds like a bug instead of a con. +1 : Due to horrible performance issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
