Re: SYSTEMD: Give us a option for upstart
Orcan Ogetbil wrote: Having a quick look at the link and at the steps to reproduce the bug gave me shivers. Are we really sure that systemd is ready? I mean, I don't even call my code alpha if it can't parse a slash correctly. How is it systemd's fault that the user's fstab is invalid? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
On Sun, 12.06.11 18:59, Reindl Harald (h.rei...@thelounge.net) wrote: Am 12.06.2011 18:56, schrieb drago01: On Sun, Jun 12, 2011 at 6:55 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.06.2011 18:53, schrieb drago01: On Sun, Jun 12, 2011 at 6:45 PM, Reindl Harald h.rei...@thelounge.net wrote: upstart is still maintained and shipped, you should be able to install and use it. and why in the world is systemd forced after a upgrade via yum where upstart was in use before - upgrades should left core configurations in peace! Upgrade usually means progress not stagnation, if you want to stay in the past don't upgrade. you said upstart is still maintained and shipped, you should be able to install and use it - so how and why damned must be a init-replace in a early state forced on a existing system? 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. normally this should be systemd is also available for upgraded systems and you should be able to install and use it Yes, it was in F14. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
WTF - Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
Am 13.06.2011 05:58, schrieb Kevin Kofler: Reindl Harald wrote: and even on a new setup this should be a decision of the user at the very beginning what init-system he wants to us No, the choice of this kind of core under-the-hood system components should be a decision of the distribution. thats freedom? To the user, it should be only an implementation detail. To the software on the distribution, it should matter that they can rely on the core system components being what they are and not have a user replace something as central as the init system. and usually HE CAN NOT with the most new technologies introduced in Fedora the first two releases (PulseAudio, KDE 4.0...) I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are doing. I don't see any valid reason why you'd use it over systemd. https://bugzilla.redhat.com/show_bug.cgi?id=709681 because your fukcing holy cow is not well tested and stable enough and that it was planned for Fedora 14 and reverted at the last moment and now a version later /run was introduced and discussed not long ago shows that there are some peopole in the fedora community with the only interest getting their stuff to as many users as possible without a real interest if they can live with it You complain about some bugs in systemd, those should be reported as bugs and fixed. AND THAT IIS WHY YOZ SHOULD INSTALL SYSTEMD ONLY FOR NEW INSTALLATIONS TO GET A USERBASE FOR BUGREPORTS AND LAVE SINCE YEARS LUCKY USERS FUCK IN PEACE signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, 13 Jun 2011 09:08:02 +0200 Kevin Kofler wrote: How is it systemd's fault that the user's fstab is invalid? A trailing slash in the mountpoint is not too common, but valid. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am 13.06.2011 08:48, schrieb Michal Schmidt: On Sun, 12 Jun 2011 22:14:27 -0400 Orcan Ogetbil wrote: Having a quick look at the link and at the steps to reproduce the bug gave me shivers. Are we really sure that systemd is ready? I mean, I don't even call my code alpha if it can't parse a slash correctly. Strictly speaking, it parses the slash correctly and it's a bug in /bin/mount. But I understand that's hardly a consolation for those who are affected by this bug. this is not a point of understand mount /mnt/storage works and finds /mnt/storage/ in /etc/fstab before upstart it worked for years, i even did not know that the slash must not be at the end signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to push to stable?
Chuck Anderson wrote: https://admin.fedoraproject.org/updates/ocp-0.1.20-8.fc15 bodhi says of my update: bodhi - 2011-06-10 05:03:46 This update has reached 3 days in testing and can be pushed to stable now if the maintainer wishes But clicking the mark as stable button says: This update has not yet met the minimum testing requirements defined in the Package Update Acceptance Criteria Reading the linked to document Package Update Acceptance Criteria is completely unhelpful. How do I push this update to stable? Thanks. I guess they bumped the minimum testing time to 7 days now that Fedora 15 is stable. :-( IMHO, 3 days was much better. Due to pushing delays, it effectively means ~7 days between filing and the push to stable anyway. One of the arguments for setting the interval to 7 days was that people might not be able to test the update in less time because of pushing delays, but pushing delays are already explicitly NOT counted in the 7 days, the time measured is the time between effective availability in testing and request of the stable push. I fail to see how 3 days for that would not be sufficient to get people to test updates. (Well, gnome-packagekit stupidly does not notify about all updates in a timely manner anymore, but that's a regression in gnome- packagekit and must be fixed there. We really need to notify users of available updates at least once a day! I personally have KPackageKit set to check for updates hourly.) This 7-day timeout effectively turns into 7 days + TWO push delays, which is often 10+ days. (And of course, I still don't understand why we can't let the maintainer decide with his/her own brain when his/her update has received sufficient testing. Thinking is what brains are for, computers suck at it.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
Am 13.06.2011 09:13, schrieb Lennart Poettering: 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. in theory the problem is that you are frcing bringing your baby to the users in a braindead way it happended before with PulseAudio which also made more troubles for 2-3 fedora releases as it solved https://bugzilla.redhat.com/show_bug.cgi?id=707507 laughable that such things are happening in the year 2011 and not fixed in a hurry! normally this should be systemd is also available for upgraded systems and you should be able to install and use it Yes, it was in F14 And it should be minimum for F15/F16 for existing installations get your beta userbase with new setups and not existing happy users! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to push to stable?
On Monday 13 June 2011 08:09:48 Honza Horak wrote: I think bodhi behaves correctly, but this auto-generated message is a failure, while according https://fedoraproject.org/wiki/Updates_Policy a non critical package must spend at least one week in updates-testing. I've reported the same issue before a couple of days: https://fedorahosted.org/bodhi/ticket/614 After one week a package can be submitted for stable without any problems. Cheers, Honza That is probably a leftover from the development stage of F15 where the threshold time was three days. Now that F15 was released this does not hold any more, it goes back to one week but it seems that the timer was not set accordingly. -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
PLEASE give us a option for systems upgraded with yum NOT USING systemd and force upstart as before * the system is running since years * every dist-upgrade via yum was no problem * now see screenshot * WTF is there to relabel if started with selinux=0-kernel-param WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER ON UPDATES I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS My opinion: You know what was wrong, sir - you put on your 20 servers Fedora - free software. And that means that you can't get personal support, because most of real developers are employees of Redhat. Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new things on it. Developers do not count it like anything serious - it is a toy for them. Today they decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use something different for your server or solve your problems by your self. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am 13.06.2011 09:25, schrieb Michal Schmidt: Stop the profanities and insults, or stop posting to this mailing list. sorry but for a answer like below form Kevin Kofler i have no other words as idiot, really! where is defined taht it is invalid and why only for systemd if it is so well designed and production ready like some cowboys are thinking which decides for the rest of the users too? it is ALPHA software and some are not realizing that we are not speaking about a sound-daemon stopping you hear music we are speaking about the most important component of the system! Am 13.06.2011 09:08, schrieb Kevin Kofler: Orcan Ogetbil wrote: Having a quick look at the link and at the steps to reproduce the bug gave me shivers. Are we really sure that systemd is ready? I mean, I don't even call my code alpha if it can't parse a slash correctly. How is it systemd's fault that the user's fstab is invalid? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, 13 Jun 2011 11:26:46 +0400 Lucas wrote: Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new things on it. Developers do not count it like anything serious - it is a toy for them. Today they decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use something different for your server or solve your problems by your self. I disagree. Fedora is much more than a toy to me. I use it every day for work. I hope it is the same for the most of the developers. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WTF - Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
Reindl Harald wrote: Am 13.06.2011 05:58, schrieb Kevin Kofler: No, the choice of this kind of core under-the-hood system components should be a decision of the distribution. thats freedom? You have the freedom to fork Fedora. Good luck! A distribution is about integration of different components, not about a random hodegepodge of stuff which doesn't work together. You should not expect all the software to cooperate with an obsolete init system. (In particular, why should services have to ship legacy initscripts (or native upstart configuration) along with the native systemd modules (which are required for efficiency)? systemd is also going to take up more and more roles in the very near future, e.g. replacing ConsoleKit.) and usually HE CAN NOT with the most new technologies introduced in Fedora the first two releases (PulseAudio, KDE 4.0...) PulseAudio was actually replaceable when it was initially introduced. It even still is to some extent. IMHO that only makes it harder to make things just work. For KDE, it was just plain impossible to support both 3.5 and 4.0 in the same distribution without violating the FHS. All the other distributions which offer both versions of KDE are installing at least one to a non-FHS prefix. Supporting only 4.0 also meant we could tweak kdelibs3 to integrate better into a KDE 4 environment, e.g. we use the KDE 4 KHelpCenter for help, the KDE 4 DrKonqi if a kdelibs3 app crashes etc. https://bugzilla.redhat.com/show_bug.cgi?id=709681 As I said in another message, it's not systemd's fault if your fstab is invalid. Fix your fstab. (And systemd is even getting a workaround to accept such broken fstab files.) and that it was planned for Fedora 14 and reverted at the last moment I also consider that a mistake. The issues found during testing were all fixed in time for the Fedora 14 release. Reverting the feature achieved exactly nothing. and now a version later /run was introduced and discussed not long ago shows that there are some peopole in the fedora community with the only interest getting their stuff to as many users as possible without a real interest if they can live with it How would you not be able to live with /run? Kevin Kofler -- 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:40 AM, Reindl Harald wrote: Am 13.06.2011 09:37, schrieb Michal Schmidt: On Mon, 13 Jun 2011 11:26:46 +0400 Lucas wrote: Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new things on it. Developers do not count it like anything serious - it is a toy for them. Today they decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use something different for your server or solve your problems by your self. I disagree. Fedora is much more than a toy to me. I use it every day for work. I hope it is the same for the most of the developers. and if not they should be quickly sorted out before shortly after systemd will get stable sooner or later the next one comes out with a new replacement and all peopole forget how long sysvinit worked very well and that this should be the measure for quality Also, be prepared - Fedora 13 end of life on 2011-06-24, next is yours Fedora 14 and it will be very soon. After that time no one will talk to you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
On Sun, Jun 12, 2011 at 07:24:38PM +0100, José Matos wrote: On Sunday 12 June 2011 18:26:25 Pasi Kärkkäinen wrote: What is the graphics card? It's ATI radeon RV635. Do you have the same graphics card? I think so (but I think that are mixing the references :-) ): # lspci | grep ATI 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series] so I think that the 365 here refers to the digital sound part. Doh, of course :) Thanks for the reply! Glad to help. :-) -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
On Sun, Jun 12, 2011 at 08:54:40PM +0200, Andreas Tunek wrote: 2011/6/12 José Matos jama...@fc.up.pt: On Sunday 12 June 2011 18:26:25 Pasi Kärkkäinen wrote: What is the graphics card? It's ATI radeon RV635. Do you have the same graphics card? I think so (but I think that are mixing the references :-) ): # lspci | grep ATI 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series] so I think that the 365 here refers to the digital sound part. Thanks for the reply! Glad to help. :-) -- Pasi -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You are probably hitting https://bugzilla.redhat.com/show_bug.cgi?id=702953 That could be it.. I'll try if echo mid /sys/class/drm/card0/device/power_profile helps. Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Reindl Harald wrote: and some are not realizing that we are not speaking about a sound-daemon stopping you hear music we are speaking about the most important component of the system! That's exactly why we shouldn't let users replace it at random. Kevin Kofler -- 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 Fri, 10.06.11 15:07, Denys Vlasenko (dvlas...@redhat.com) wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. As pointed out elsewhere, this is mostly the SELinux policy, and definitely something we can optimize in one way or another. I understand your desire to replace everything by systemd. I have no such desire. I really do. syslogd, klogd, mount, fsck, and a dozen other things We don't replace syslogd, klogd, mount, fsck and dozen of other things. Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Yes, systemd as a platform will include a tiny daemon which takes over the role of CK. Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? libaudit? What systemd has in common with audit? Michal already answered these questions, so I am not going to repeat this here. libwrap? systemd is a network application now too? Yupp, Google for socket activation systemd. libdbus?... this is a lost battle I guess... Yupp, since Upstart used that already since ages. I propose to stop for a second and optimize systemd down instead of trying to add even more bells and whistles to it. Or else you'll soon end up linking against every /lib/lib*.so* I think systemd is much more optimized that what existed previously. (what else is parallelization but optimization?) I bet with you that a systemd system (modulo SELinux) can be built in a way that uses much less resources and boot time than one built on Upstart. (How? We simply spawn shell (or even zero) shells and other interpretors, and start a number of seldom-things only when needed and the rest in parallel). It is an *init replacement*, not the replacement for everything. I like to see it as a modular platform to build an OS from. It includes an init system and a few auxiliary tools (readahead for example, and C implementations of the basic boot scripts). Every new feature you add and library you link against works against that goal. Nah, don't think so. We have fewer deps, and less dependencies than the equivalent Upstart- and shell based boot. It is my intention to minimize the minimum set of packages you need to bootstrap a Linux system. While the systemd package might get a bit bigger than sysvinit through that -- *overall* you get a much smaller and simpler system, build from a much smaller number of source packages. That saves resources, makes things simpler and faster. To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. No, that would complicate things for little reason. I find a system whose PID after boot is in the 500 range much simpler and leaner than one that is in the 5000 range. Then, if service manager would crash, at least it doesn't take system down with it... If systemd crashes it will freeze, but not take the system down. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Fri, 10.06.11 18:58, Denys Vlasenko (dvlas...@redhat.com) wrote: On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: On 06/10/2011 03:59 PM, Steve Clark wrote: On 06/10/2011 09:36 AM, Michal Schmidt wrote: systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system No, only systemd freezes itself. Other processes continue running. systemd-26/src/main.c::crash() is the function which does it. Assuming it will not recurse by crashing again, of course. It calls log_error and assert_se, which go into log_dispatch(), which logs to syslog, may try to write to klog, and whatnot... this doesn't look too robust to me. But anyway. Assuming it successfully froze. Does it help? Yes. How much? Well, it's better than instant oops which happens when PID 1 exits, but reaping of processes reparented to init will stop, which, for example, makes the hang from pid exhaustion just a question of time. Ultimately, this stems from the decision to make systemd to run as PID 1 process. Are there technical reasons for this? Yupp, if we oops the kernel all processes are aborted at the same time. If we just freeze systemd they can still be shutdown cleanly and everything synced to disk. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WTF - Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On 01:59:43 PM Monday, June 13, 2011 Reindl Harald wrote: Am 13.06.2011 05:58, schrieb Kevin Kofler: Reindl Harald wrote: and even on a new setup this should be a decision of the user at the very beginning what init-system he wants to us No, the choice of this kind of core under-the-hood system components should be a decision of the distribution. thats freedom? Yes, this is the freedom of the people that do the work to take some decisions. Freedom is one of the rights for people that work on the distribution too, don't you think so ? To the user, it should be only an implementation detail. To the software on the distribution, it should matter that they can rely on the core system components being what they are and not have a user replace something as central as the init system. and usually HE CAN NOT with the most new technologies introduced in Fedora the first two releases (PulseAudio, KDE 4.0...) I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are doing. I don't see any valid reason why you'd use it over systemd. https://bugzilla.redhat.com/show_bug.cgi?id=709681 because your fukcing holy cow is not well tested and stable enough and that it was planned for Fedora 14 and reverted at the last moment and now a version later /run was introduced and discussed not long ago shows that there are some peopole in the fedora community with the only interest getting their stuff to as many users as possible without a real interest if they can live with it You complain about some bugs in systemd, those should be reported as bugs and fixed. AND THAT IIS WHY YOZ SHOULD INSTALL SYSTEMD ONLY FOR NEW INSTALLATIONS TO GET A USERBASE FOR BUGREPORTS AND LAVE SINCE YEARS LUCKY USERS FUCK IN PEACE And who is gonna do the testing of 2 distributions? Because testing 2 different init systems is like testing 2 different distributions. Fedora QA are already overloaded enough so we can't make that on them. And who is gonna do the work on all the patches for working with and making use of the features of the 2 different init systems? I would not do such thing for my packages for sure. As soon as some core component changes I'll support it only whenever I'm involved. YES, THIS IS MY FREEDOM TO DECIDE WHAT TO DO! Though I'll let everyone that wants to comaintain smth to do the work to support alternatives but I'm still failing to see the army of contributors just sitting and waiting for what to do. Until this happens people should remember that the one that do the works has freedom too and if they don't like smth they are free to come with better implementation and offer it. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110613 changes
Compose started at Mon Jun 13 08:15:26 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.16-1.fc16.i686 requires libadmsslutil.so.1 389-admin-1.1.16-1.fc16.i686 requires libadminutil.so.1 389-admin-1.1.16-1.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-admin-1.1.16-1.fc16.x86_64 requires libadminutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadminutil.so.1()(64bit) CGSI-gSOAP-1.3.4.0-2.fc15.i686 requires libvomsapi.so.0 CGSI-gSOAP-1.3.4.0-2.fc15.x86_64 requires libvomsapi.so.0()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk.so.1.1()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk_gl.so.1.1()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ed2k_hash-gui-0.4.0-10.fc13.x86_64 requires libfltk.so.1.1()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flpsed-0.5.2-2.fc15.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk_images.so.1.1()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk.so.1.1()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet = 0:2.16 gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal) gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1 gnome-device-manager-libs-0.2-6.fc15.i686 requires hal = 0:0.5.10 gnome-device-manager-libs-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal = 0:0.5.10 gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-eds-2.91.92-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-schedule-2.0.2-6.fc15.noarch requires gnome-python2-applet gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties) gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-gui.so.0.19 gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-base.so.1.21
Re: SYSTEMD: Give us a option for upstart
On 02:12:43 PM Monday, June 13, 2011 Lucas wrote: PLEASE give us a option for systems upgraded with yum NOT USING systemd and force upstart as before * the system is running since years * every dist-upgrade via yum was no problem * now see screenshot * WTF is there to relabel if started with selinux=0-kernel-param WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER ON UPDATES I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS My opinion: You know what was wrong, sir - you put on your 20 servers Fedora - free software. And that means that you can't get personal support, because most of real developers are employees of Redhat. Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new things on it. Developers do not count it like anything serious - it is a toy for them. Today they decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use something different for your server or solve your problems by your self. The generalization that we(Red Hat associates) see Fedora as a toy is INSULTING. Do you know how many of us are spending their free time to get Fedora better? Do you know how many of us have worked on Fedora(or related things) before working for Red Hat? Do you know how big part of the Red Hat work is available in Fedora without being available in RHEL? Yes, we have opinions and we stick to them - most of the time without our managers even know - because it's smth we do on our own. Speaking personally everyone can accuse me of not fullfilling some user's wishes (which I'm not oblided to do) but someone saying that I(we) look at Fedora as a toy is really hurting a lot of feelings. Alexander Kurtakov Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Thursday 09 June 2011 15:54:14 Clément David wrote: Hi, My name is Clément DAVID (aka davidcl) and I'm a french software developer. I'm currently working on Scilab [1]. Welcome to Fedora. :-) I'm interested to become a packager for Scientific application or just software toys :). My first package has been approved (thanks to Alexander Kurtakov) [2] and build by koji [3]. Just curious, what is the scientific software that you interested to see packaged in Fedora other than naturally scilab? :-) My FAS name is davidcl. -- davidcl -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Welcome to fedora, I am glad that you managed to get jlatexmath into fedora. If you are interested in mind-mapping there is a nice freemind plugin [1] to include LaTeX formulas into mind-maps which makes use of jlatexmath. If you are interested in packaging this little piece of software. I would be glad to help out if possible/necessary. ;-) johannes (irc-nick: hannes|) [1] https://github.com/Alxa/LaTeXMath-Freemind-Plugin On 06/13/2011 01:37 PM, José Matos wrote: On Thursday 09 June 2011 15:54:14 Clément David wrote: Hi, My name is Clément DAVID (aka davidcl) and I'm a french software developer. I'm currently working on Scilab [1]. Welcome to Fedora. :-) I'm interested to become a packager for Scientific application or just software toys :). My first package has been approved (thanks to Alexander Kurtakov) [2] and build by koji [3]. Just curious, what is the scientific software that you interested to see packaged in Fedora other than naturally scilab? :-) My FAS name is davidcl. -- davidcl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
* Steve Clark [13/06/2011 14:04] : Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff. Linus has no such thing. Google the min/max incident and the amount of drivers that were removed from the kernel tree before 2.4.0's release if you want proof. Emmanuel -- 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 03:27 PM, Alexander Kurtakov wrote: On 02:12:43 PM Monday, June 13, 2011 Lucas wrote: PLEASE give us a option for systems upgraded with yum NOT USING systemd and force upstart as before * the system is running since years * every dist-upgrade via yum was no problem * now see screenshot * WTF is there to relabel if started with selinux=0-kernel-param WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER ON UPDATES I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS My opinion: You know what was wrong, sir - you put on your 20 servers Fedora - free software. And that means that you can't get personal support, because most of real developers are employees of Redhat. Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new things on it. Developers do not count it like anything serious - it is a toy for them. Today they decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use something different for your server or solve your problems by your self. The generalization that we(Red Hat associates) see Fedora as a toy is INSULTING. Do you know how many of us are spending their free time to get Fedora better? Do you know how many of us have worked on Fedora(or related things) before working for Red Hat? Do you know how big part of the Red Hat work is available in Fedora without being available in RHEL? Yes, we have opinions and we stick to them - most of the time without our managers even know - because it's smth we do on our own. Speaking personally everyone can accuse me of not fullfilling some user's wishes (which I'm not oblided to do) but someone saying that I(we) look at Fedora as a toy is really hurting a lot of feelings. Alexander Kurtakov Thanks. What do you think I thought when found that udev was compiled: * Fri May 20 2011 Harald Hoyer har...@redhat.com 170-1 - version 170 - removed /sbin/start_udev REMOVED /sbin/start_udev - this means that upstart wont be able to start udev without manual tweak. Upstart reads rc.sysinit and there is still /sbin/start_udev. And also this means that any one who will try to use upstart in Fedora 16 (now rawhide) wont get udev works. What do you think I thought about all of this? I wont be really upset if I'll lose upstart, I can clean systemd as I need, but the idea is wrong. Systemd is just a project, project which may tomorrow be changed, so why all others have to follow. It should be like selinux, which can be easily disabled selinux=0. That is what I think. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On 06/13/2011 04:33 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2011 03:11 PM, Lucas wrote: On 06/11/2011 11:00 PM, Andre Robatino wrote: Lucasmacachutoat gmail.com writes: I use systemd-28-3.fc16.i686 and updated it when it became available, but still have real problems with boot. If it stops it happens definitely in systemd job - when it is starting services. And I can't find any errors. More important that I have changed selinux to permissive - there is no difference. I can boot only with selinux=0. I have tried upstart - it works without any problems. If you've been using selinux=0, try doing a relabeling. I did touch /.autorelabel and rebooted without selinux=0, but got dropped to single-user mode. I then did restorecon -R -v / and rebooted successfully without selinux=0. After that, I did touch /.autorelabel again and was able to successfully reboot without selinux=0, without getting dropped to single-user mode, and booting has been normal since. (This is all after updating to the latest systemd.) Actually it does relabel by it self after boot with option selinux=0, and of course I did relabel. It manages to stop anyway. But not always, sometime I can boot, sometime not. Does booting with enforcing=0 work? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk32A5UACgkQrlYvE4MpobOh1QCgmZ3uYWh4KY58Z4460HQrzmrX PTMAnj6bM8Xla6SDEun9p41IogiksPsz =MCU1 -END PGP SIGNATURE- I have not tried to boot with enforcing=0, because I solved this problem removing b43 driver (blacklist) and I also removed some systemd services (md and something else - I do not remember exactly, as rawhide on different HDD) So now rawhide boots properly. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SUMMARY - [Fwd: Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY]
On Mon, Jun 13, 2011 at 1:29 PM, Richard W.M. Jones rjo...@redhat.comwrote: Now you need to persuade Red Hat to fund a bigger ARM build server than the one Canonical are building :-) http://thetanktheory.squarespace.com/this-8-bit-life/2011/6/10/ubuntu-linux-pandabuilder.html https://dmtechtalk.wordpress.com/ I think our ARM build farm might actually already be bigger. We currently have (AFAICT): - 21 guru plugs - 1 BeagleBoard XM - 1 open RD - 15 panda boards - 10 genesi smarttops - 2 marvell dev boards with 3G RAM And we're working to get some ARMv7 hosts with more than 1Gb RAM. Peter -- 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 05:28 PM, Steve Clark wrote: Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff. I get the impression Fedora doesn't care about users and is only interested in pushing the agenda of the developers. It is too bad that Fedora doesn't have a reasonable benevolent dictator like Linus. Linux kernel routinely has many regressions that affect end users. Kernel developers try to solve known regressions before the release and so does Fedora. The problem with have distribution level dictators is the potential for abuse of power. I don't think you want that. Atleast in this case, the bug was actually filed long after the release and hence wasn't a known regression that was ignored. I don't think you can blame Fedora here. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system-config-keyboard needs some loving, any takers?
Hi, It seems that Debian has solved this by offering layouts from xkeyboard-config during installation and then generating corresponding console keymap based on the selection on the fly with console-setup [3]. This is the correct way to go, non xkeyboard-config layout databases need to die, it's already horrible enough to specify a good xkb layout without needing to rewrite it manually in another language. since there weren't any additional comments on the list about this, I filed an RFE, let's see what happens: https://bugzilla.redhat.com/show_bug.cgi?id=712877 Cheers, -- Marko Myllynen -- 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 06:10 PM, Steve Clark wrote: On 06/13/2011 08:23 AM, Emmanuel Seyman wrote: * Steve Clark [13/06/2011 14:04] : Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff. Linus has no such thing. Google the min/max incident and the amount of drivers that were removed from the kernel tree before 2.4.0's release if you want proof. Emmanuel http://apcmag.com/linus_torvalds_on_regression_laziness_and_having_his_code_rejected.htm This article doesn't really justify your point. Reading LKML would show you the reality. If you actually believe that any one person can stop kernel regressions, that is remarkably naive and avoiding regressions at the distribution level is many times more impossible because of the number of components. We can make reasonable attempts to avoid them. That's all. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlas...@redhat.com) wrote:
I understand your desire to replace everything by systemd.
I have no such desire.
What is this then?
int main(int argc, char *argv[]) {
...
if (arg_running_as == MANAGER_SYSTEM !serialization) {
locale_setup();
if (arg_show_status || plymouth_running()) == ??
status_welcome();
kmod_setup(); === ???
hostname_setup(); === ???
machine_id_setup(); === ???
loopback_setup();
test_mtab();
test_usr();
test_cgroups();
}
plymouth_running()? Plymouth? Systemd knows about plymouth? Why?
This is an antithesis to modular, Unix way of doing things.
It starts to have shadows of monolithic Windows-like
we know better than you what you need approach.
hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.
For one, I had no /etc/machine-id on machines I was administering
for decades, with no ill effects. I don't want init to know better
than me what I want to have.
kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?
systemd will force me to do so?
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
We don't replace syslogd, klogd, mount, fsck and dozen of other things.
What is /lib/systemd/systemd-fsck then?
/lib/systemd/systemd-logger?
(Also, most of them don't emit useful info on --help...)
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).
Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.
That's what I was referring to by taking over the world.
Today I can remove CK from my Fedora install if I want to.
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.
I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.
(How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).
Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.
It is an *init replacement*, not the replacement for everything.
I like to see it as a modular platform to build an OS from.
That's what I was referring to by taking over the world.
It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).
Readahead is a band aid for stuff which is bloated enough
to affect boot by sheer amount of necessary reading.
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)
As I said, freedom to do things as admin wants
is important trait of Unix way.
C implementation of shell scripts tends to be too rigid.
I don't see why you are trying to do that.
If it because bash startup time is too long, I have
a few faster shells for you...
Every new feature you add and library you link against
works against that goal.
Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot.
Competing with Upstart is easy :)
It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.
Everyone who likes coding thinks that his favorite package is great.
I have no doubt that you are proud of systemd. It actually isn't
a bad software.
However, allow me to have a not completely rosy view of it either.
Saves resources is not exactly true, as I see it,
on memory consumption front.
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no
Re: WTF - Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 3:14 AM, Reindl Harald h.rei...@thelounge.net wrote: because your fukcing holy cow This type of language is inappropriate for a Fedora mailing list. Please tone down the language. -- Jared Smith Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Mojolicious-1.43.tar.gz uploaded to lookaside cache by yaneti
A file has been added to the lookaside cache for perl-Mojolicious: ec34749aae9fe2c23dc10504a0476655 Mojolicious-1.43.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] Upstream update 1.43
commit c3a0bda9514b77669a41b2c0ea95bc7626d9930b
Author: Yanko Kaneti yan...@declera.com
Date: Mon Jun 13 18:06:41 2011 +0300
Upstream update 1.43
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 13985fc..5432ae6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-1.34.tar.gz
/Mojolicious-1.41.tar.gz
/Mojolicious-1.42.tar.gz
+/Mojolicious-1.43.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index da1207d..57e08db 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:1.42
+Version:1.43
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -52,6 +52,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jun 13 2011 Yanko Kaneti yan...@declera.com 1.43-1
+- Upstream update 1.43.
+
* Fri Jun 10 2011 Yanko Kaneti yan...@declera.com 1.42-1
- Upstream update 1.42.
diff --git a/sources b/sources
index 542268b..76c999c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5432fa78163e8726d7655292e2d8c4b2 Mojolicious-1.42.tar.gz
+ec34749aae9fe2c23dc10504a0476655 Mojolicious-1.43.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 02:27:55PM +0100, Matthew Garrett wrote: On Mon, Jun 13, 2011 at 03:16:45PM +0200, Lennart Poettering wrote: On Mon, 13.06.11 13:41, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote: What is the benefit of a separate libexecdir? I guess because binaries shouldn't go in the library directory. But it isn't a library directory. It's a directory for arch-depndendant stuff, which includes (but is not limited to) libraries. It's a directory for arch-dependent stuff that should only exist once on a system, whereas lib is for arch-dependent stuff that may exist for multiple architectures on one system. I have no opinion on whether that distinction is important. nod See the thread I linked to previously for people working out the nuances and reasons behind that. -Toshio pgpcsGOz4p2gB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am Montag, den 13.06.2011, 01:47 +0200 schrieb Reindl Harald: Am 13.06.2011 00:54, schrieb Christoph Wickert: Am Sonntag, den 12.06.2011, 23:23 +0200 schrieb Reindl Harald: PLEASE give us a option for systems upgraded with yum NOT USING systemd and force upstart as before systems upgraded with yum still have upstart installed (I did it myself) and you can select the init as a kernel parameter, so obviously nobody is forced. my first test-setup had no upstart after upgrade You did read the instructions about upgrading with yum and ran 'yum distrosync', right? this is a bad user experience and shows my that systemd had been better delayed again for Fedora 16 to not repeat the bad things happended with the way too early incldunfig of pulseaudio and KDE4.0 AND we are speaking here about the absolutely core-system and not a sound-daemon or a desktop environment Please keep in mind that that one of Fedora's foundation is to be first. Please read https://fedoraproject.org/wiki/Foundations Both KDE 4 and pulseaudio were ready for inclusion when we first had them in our distribution. Software is always changing, development never stops. If you want to move on, you need to draw a line at some point and put it into production in order to get wider feedback. Without this feedback neither pulseaudio nor KDE would be where they are right now. Fedora is a distribution for early adopters. If you really need the latest kernel for your new hardware but also long term stability please get an enterprise distribution. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
But it isn't a library directory. It's a directory for arch-depndendant
stuff, which includes (but is not limited to) libraries.
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 03:30, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2011 09:25, schrieb Michal Schmidt: Stop the profanities and insults, or stop posting to this mailing list. sorry but for a answer like below form Kevin Kofler i have no other words as idiot, really! where is defined taht it is invalid and why only for systemd if it is so well designed and production ready like some cowboys are thinking which decides for the rest of the users too? I do not regularly agree with Kevin Kofler, but you can call him what you want in private email til the days are done. 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. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Guide to setting karma thresholds?
I'm working on pushing my first bugfix to F15 (#711261), using the guides I found in the wiki[1][2]. For a non-critical-path package, the Update Policy says that it needs to meet the positive karma threshold set by the submitter, but does not indicate what that threshold should be or guidance for determining appropriate values. The default is 3; I'm assuming that leaving it there is a reasonable thing to do (and I won't be surprised if the 7-day criteria will be hit first for this package). However, I am still wondering: is there any guidance or policy published on how to determine appropriate karma thresholds? What justifies increasing or decreasing the thresholds? Userbase? Impact of change? Thank you, - Michael 1. https://fedoraproject.org/wiki/Updates_Policy 2. https://fedoraproject.org/wiki/Package_update_HOWTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 11:39:02AM -0400, Stephen John Smoogen wrote: I do not regularly agree with Kevin Kofler, but you can call him what you want in private email til the days are done. 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've emailed Reindl privately to remind him of the standards of behaviour we expect on mailing lists. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WTF - Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 10:55:02AM -0400, Jared K. Smith wrote: On Mon, Jun 13, 2011 at 3:14 AM, Reindl Harald h.rei...@thelounge.net wrote: because your fukcing holy cow This type of language is inappropriate for a Fedora mailing list. Please tone down the language. I'd go further than that. Swearing is not inherently an issue. The problem is abusive and aggressive behaviour. We expect participants in the community to demonstrate appropriate levels of respect for one another. Not agreeing with the rationale for a decision does not inherently mean that the decision was inappropriate, and is certainly not grounds for abusing those who made that decision. Let's remember that these lists are one of the public faces of the project and try to make sure we don't alienate potential contributors through our behaviour, swearing or otherwise. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
But this is wasteful, it means that:
A) You cannot use the same packages on a 32bit system and a 64bit
system. You have to compile additional 32bit packages for installation
on 64bit systems, or do some fancy relocation within rpm.
B) you cannot easily convert a system from 32 - 64 bit as you would
have to move everything around.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, 13 Jun 2011 16:45:57 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Jun 13, 2011 at 11:39:02AM -0400, Stephen John Smoogen wrote: I do not regularly agree with Kevin Kofler, but you can call him what you want in private email til the days are done. 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've emailed Reindl privately to remind him of the standards of behaviour we expect on mailing lists. As have I. kevin signature.asc Description: PGP signature -- 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 Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering mzerq...@0pointer.de wrote: plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. The long-term question here is what happens when Plymouth is replaced by something different, first in one specialist distribution, later by one major distribution (perhaps Fedora), and only much later by most distributions?. Will systemd only support the new thing, forcing the slower distributions to backport patches? Will systemd support both systems, and over time become burdened with compatibility code? Something else? Historically, each distribution had its own system integration scripts that supported only the tools the distribution cared about, so there never was a single project fighting with the matrix of N distributions x M implementations of major features. What is /lib/systemd/systemd-fsck then? A wrapper, which handles the exit code and reacts properly to it. (Also, most of them don't emit useful info on --help...) They aren't user binaries. They are in /lib/systemd, not /usr/bin... But they do implement user-visible functionality, and have user-visible /proc/cmdline options. Yes, old initscripts didn't document the behavior either, but the sysadmin (who, for better or worse, pretty much has to be able to read shell code) could find them and could understand and debug the boot process by reading /etc/rc.*. I think that asking the sysadmin to read the C code of systemd to understand the boot process and how it can be configured is rather excessive. Mirek -- 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 Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: On Mon, 13.06.11 15:27, Denys Vlasenko (dvlas...@redhat.com) wrote: kmod_setup(); === ??? We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. hostname_setup(); === ??? We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? machine_id_setup(); === ??? Similar to the hostname we ensure that the machine id is always initialized, and has the same lifetime and validity guarantees as the hostname. i.e. that it is simply usable by *every* process started, regardless when. Point me at one program which uses machine id. I never saw one. And anyway, why do you set up stuff no one asked you to? plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. Plymouth is not a part of Unix. Init process has no business knowing about distro specific stuff like that. This is an antithesis to modular, Unix way of doing things. Just because you can turn each trivial operation into a separate binary you shouldn't necessarily do that. Where did I propose turning everything into a separate binary? It is what makes your system slow and heavy-weight. Insisting that we invoke sethostname() in a separate process is just stupid. I am mean, come on, think about it. It is *ONE* system call to the the hostname with sethostname(). Invoking /bin/hostname instead is at least 40 or so (and many of those quite heavy weight). And really, why are we even discussing the frickin hostname like this? Because it's a perfect example of a thing init process has no business doing. Ever. The lightness of the syscall is irrelevant. For example, you also do modprobing of various things, which is far from being just one syscall, so this argument is moot. Do you know what mono means? It's greek and means one. And lithic means stone. And if systemd communicates with Plymouth, then this is not monolothic at all, since systemd and ply are two processes, not one. Init process should not have intrinsic knowledge about splash screens! This is basic idea of modularity. This is how Unix always worked. Things should not be *too* interconnected. Things should be modular. In your presentation, you have Integration as slide 17 and Modularization as slide 18. Do you realize that these are the opposite things? More integration means less modularization. You can't have both. systemd is not running Plymouth stuff in the same process, is it merely communicating with it. Thanks that at least for now you don't have plans to incorporate Plymouth. No, systemd tries to load those modules but if you are into retro computing you can still blacklist them using the usual modprobe blacklisting, and systemd will honour that (i.e. by passing -b to modprobe). Why it (a *program*) took upon itself to decide what modules should be running? There decisions are traditionally up to *humans* in Unix world. Nah. udev loads modules automatically. udev loads modules according to config file, not by hard-coding stuff in C code. IOW: udev does not load modules which *udev developer* wants, it loads modules which *admin* wants. (Of course, admin might choose to use standard config, but he does this on his own volition). In fact on almost all systems there should be no need to ever load a module manually. Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Yes, systemd as a platform will include a tiny daemon which takes over the role of CK. That's what I was referring to by taking over the world. Well, we simplify things a lot
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. -- Matthew Garrett | mj...@srcf.ucam.org -- 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 Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
On Mon, Jun 13, 2011 at 11:48:40 +, Petr Pisar ppi...@redhat.com wrote: On 2011-06-10, Luke Macken lmac...@redhat.com wrote: * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides I mean, I know what's buildroot in Koji and that it can be used to prepare set of binary packages apart of standard buildroot and then merge them back to main buildroot. Based on the caution given, it looks like this feature allows you to change the builds used for the standard buildroot for a particular release. -- 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 Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote: On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html I'd assumed that Dennis was talking about non-Fedora environments, since ipv6 hasn't been meaningfully optional in Fedora for ages. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
On Mon, 13 Jun 2011 11:48:40 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2011-06-10, Luke Macken lmac...@redhat.com wrote: * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides Excuse me for my low knowledge, what is good for? I mean, I know what's buildroot in Koji and that it can be used to prepare set of binary packages apart of standard buildroot and then merge them back to main buildroot. Provided this is the same thing, I have no idea why it is part of bodhi. I guess it should be part of koji client instead. Also I cannot see how I can specify inheritance for the new buildroot. Also the bodhi(1) from bodhi-client-0.8.0-1.fc15.noarch does not describe the option at all. Could somebody enlighten me? This is a automated replacement for a formerly manual process. Say you have packages libfoo and bar and baz. bar and baz build against/depend on libfoo. When you update libfoo you want to also update bar and baz. Koji doesn't add packages to the build root (the collection of packages that is used to build other packages) until the package is in the stable updates repo. This is to prevent issues like an accidental or broken package from being added and breaking things for others. So, you build the new libfoo. Then test locally against that build. When you are ready and are sure it's in a good state, you request a build root override to add it to the build root. Then you build your bar and baz and submit all of libfoo, bar and baz in a single update. In the past this process was: - Submit a ticket to rel-eng in their trac - Wait for someone to process it. - Use the override, build things. - Remember to go back to the ticket and say you were done with it. - Wait for someone to process that and close the ticket. Now this can be done in bodhi without needing to wait on people or remember to go back and do things. It's in bodhi instead of koji because bodhi already has the interfaces and ability to move tags and packages around. koji would need a additional layer of interface and adding another tool would be a bad idea. kevin signature.asc Description: PGP signature -- 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 Sun, 2011-06-12 at 23:39 +0200, Reindl Harald wrote: Am 12.06.2011 23:35, schrieb Josh Boyer: On Sun, Jun 12, 2011 at 5:23 PM, Reindl Harald h.rei...@thelounge.net wrote: PLEASE give us a option for systems upgraded with yum NOT USING systemd and force upstart as before * the system is running since years * every dist-upgrade via yum was no problem * now see screenshot * WTF is there to relabel if started with selinux=0-kernel-param WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER ON UPDATES I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS BULL***, I CAN'T HEAR YOU! SOUND OFF LIKE YOU GOT A PAIR! there is nothing bullshit why are users of running systems are forced to change their init-system to systemd? upstart is in the repos but ignored WTF every three years a new pig is forced to run through the city and if any subsystem is runnign well and debugged some idiot comes out of his hole and try replace and force everybody to use it I totally disagree with the way you phrase your arguments. It is inappropriate, and actually hurts the point you are trying to make. However, I partially agree with the argument itself. Gnome 3 Shell is an example of a far worse surprise, IMO, than systemd. It's a disaster, especially for those poor souls which convinced some firm or school or university to use Fedora, and now have to face angry mobs of users pissed off by abrupt switch to a different desktop manager. Talk about ruined reputations... But at least there F15 has an alternative. Now I use XFCE. -- vda -- 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 Mon, Jun 13, 2011 at 6:18 PM, Denys Vlasenko dvlas...@redhat.com wrote: ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) Maybe if you send me the money first ;) (Sorry for private spam, hit wrong button) -- 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 Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. What's the problem of having a specific hostname set up at boot time ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: Guide to setting karma thresholds?
On Mon, 13 Jun 2011 10:43:42 -0500 Michael Ekstrand mich...@elehack.net wrote: I'm working on pushing my first bugfix to F15 (#711261), using the guides I found in the wiki[1][2]. For a non-critical-path package, the Update Policy says that it needs to meet the positive karma threshold set by the submitter, but does not indicate what that threshold should be or guidance for determining appropriate values. The default is 3; I'm assuming that leaving it there is a reasonable thing to do (and I won't be surprised if the 7-day criteria will be hit first for this package). However, I am still wondering: is there any guidance or policy published on how to determine appropriate karma thresholds? What justifies increasing or decreasing the thresholds? Userbase? Impact of change? There isn't that I know of. ;) Perhaps this would be a good chance to try and draft one. In the end it's up to the maintainer, but there could be some ideas to help along. Off the top of my head: * Are the changes small/well contained (less karma) * Is this a security update with a single security change (less karma) * Is this a popular package with lots of testers (more karma) * Is this something that has been tested already by upstream or another distro? (less karma) * Is this a bug that only affects a small number of users? (more karma) * Is there likely to be another update soon? (less if you want to try and get this fix out now, more if you just wanted testing on this, to be obsoleted by another update when ready). kevin signature.asc Description: PGP signature -- 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 Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
On Mon, 2011-06-13 at 10:21 -0600, Kevin Fenzi wrote: On Mon, 13 Jun 2011 11:48:40 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2011-06-10, Luke Macken lmac...@redhat.com wrote: * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides Excuse me for my low knowledge, what is good for? I mean, I know what's buildroot in Koji and that it can be used to prepare set of binary packages apart of standard buildroot and then merge them back to main buildroot. Provided this is the same thing, I have no idea why it is part of bodhi. I guess it should be part of koji client instead. Also I cannot see how I can specify inheritance for the new buildroot. Also the bodhi(1) from bodhi-client-0.8.0-1.fc15.noarch does not describe the option at all. Could somebody enlighten me? This is a automated replacement for a formerly manual process. Say you have packages libfoo and bar and baz. bar and baz build against/depend on libfoo. When you update libfoo you want to also update bar and baz. Koji doesn't add packages to the build root (the collection of packages that is used to build other packages) until the package is in the stable updates repo. This is to prevent issues like an accidental or broken package from being added and breaking things for others. So, you build the new libfoo. Then test locally against that build. When you are ready and are sure it's in a good state, you request a build root override to add it to the build root. Then you build your bar and baz and submit all of libfoo, bar and baz in a single update. In the past this process was: - Submit a ticket to rel-eng in their trac - Wait for someone to process it. - Use the override, build things. - Remember to go back to the ticket and say you were done with it. - Wait for someone to process that and close the ticket. Now this can be done in bodhi without needing to wait on people or remember to go back and do things. It's in bodhi instead of koji because bodhi already has the interfaces and ability to move tags and packages around. koji would need a additional layer of interface and adding another tool would be a bad idea. kevin This is a great feature. Is there a guide somewhere on how to use it? If not, can you point me at the relevant upstream documentation and I'll write up an SOP for doing this. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 711261] Missing dependency ocaml-curl-devel - libcurl-devel
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711261 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_DEV |MODIFIED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Bodhi v0.8 in production
Excerpts from Stephen Gallagher's message of Mon Jun 13 13:02:29 -0400 2011: This is a great feature. Is there a guide somewhere on how to use it? If not, can you point me at the relevant upstream documentation and I'll write up an SOP for doing this. This is the closest thing to a guide that we have at the moment, which could definitely use some improvements: http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides The old SOP can be found here, and I added a little deprecation message at the top: http://fedoraproject.org/wiki/Buildroot_override_SOP luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 711261] Missing dependency ocaml-curl-devel - libcurl-devel
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711261 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-06-13 13:08:07 EDT --- ocaml-curl-0.5.3-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ocaml-curl-0.5.3-3.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Guide to setting karma thresholds?
Excerpts from Kevin Fenzi's message of Mon Jun 13 12:49:43 -0400 2011: On Mon, 13 Jun 2011 10:43:42 -0500 Michael Ekstrand mich...@elehack.net wrote: I'm working on pushing my first bugfix to F15 (#711261), using the guides I found in the wiki[1][2]. For a non-critical-path package, the Update Policy says that it needs to meet the positive karma threshold set by the submitter, but does not indicate what that threshold should be or guidance for determining appropriate values. The default is 3; I'm assuming that leaving it there is a reasonable thing to do (and I won't be surprised if the 7-day criteria will be hit first for this package). However, I am still wondering: is there any guidance or policy published on how to determine appropriate karma thresholds? What justifies increasing or decreasing the thresholds? Userbase? Impact of change? There isn't that I know of. ;) Perhaps this would be a good chance to try and draft one. In the end it's up to the maintainer, but there could be some ideas to help along. Off the top of my head: Yeah, we have yet to step back and really think about the defaults for the karma thresholds, after having the +3/-3 defaults for so long. Some maintainers set the values very low to decrease the amount of time their update spends in testing, and some set the values really high (or disable them) to ensure that their update doesn't change state without mantainer intervention. It's designed to fit both maintainer styles. * Are the changes small/well contained (less karma) * Is this a security update with a single security change (less karma) * Is this a popular package with lots of testers (more karma) * Is this something that has been tested already by upstream or another distro? (less karma) * Is this a bug that only affects a small number of users? (more karma) * Is there likely to be another update soon? (less if you want to try and get this fix out now, more if you just wanted testing on this, to be obsoleted by another update when ready). These are all sound suggestions, but it seems like they refer to the stable karma threshold only. There are still a variety of scenarios for setting different unstable threshold values. For example, for updates that shouldn't cause *any* problems/regressions, setting an unstable threshold to -1 would cause the update to back-out as soon as anyone encounters a single issue. On the other hand, some updates, like the kernel, are inevitably going to get a bunch of negative karma no matter what so this wouldn't be ideal for that case. Hopefully we can come up with and document some best-practices for this based on maintainer experience. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
On Mon, Jun 13, 2011 at 13:02:29 -0400, Stephen Gallagher sgall...@redhat.com wrote: If not, can you point me at the relevant upstream documentation and I'll write up an SOP for doing this. If you do something for this, you might want to point to it from https://fedoraproject.org/wiki/Package_update_HOWTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 05:36:00PM +0200, Lennart Poettering wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Errr, what?
Fedora has the same confusion.
--
Matthew Miller mat...@mattdm.org
Senior Systems Architect -- Instructional Research Computing Services
Harvard School of Engineering Applied Sciences
--
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 Mon, 2011-06-13 at 19:02 +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. But until you can get the real one you basically are. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
On Sun, 2011-06-12 at 20:02 +0200, Reindl Harald wrote: Am 12.06.2011 19:28, schrieb Lucas: Strange, I did exactly the same thing with Fedora 14, I add new kernel, changed xorg and intel driver. But I have i686. mhh - strange - an trying to update glibc results in chaos Datei oder Verzeichnis nicht gefunden means file not found in english yes as advanced user i was able to repair this with some luck updating only the kernel/kernel-headers/kernel-devel results in no longer able to build kernel-modules (vmware-workstation) and this all for a graphics-driver? i remember times where feodra updated the kernel in the lifetime of a supported release and now you can do nothing if you do not want replace of upstart by systemd, if systemd would not be hardly activated in F15 a dist-upgrade would be no problem BULLSHIT BULLSHIT BULLSHIT This kind of language is inappropriate on Fedora mailing lists. More than the language, though, the tone of this thread is also unfortunate. It appears that you are unhappy and frustrated at the moment - I've seen a few emails from you so far today in which you've used all-capitals text. All-capitals text is perceived by most tech people as rude. One of Fedora's goals is to be a fast-moving distribution: systemd offers significant improvements compared to previous init systems (for me the integration with cgroups is particularly appealing). The drawback with having features first, is that arguably we're the first into the minefield. There will always be bugs and unexpected interactions in something as complicated as software. FWIW, systemd was held back from being in Fedora 14 to give it more time to mature. Another core foundation of Fedora is Friends We want our community to be a pleasant place to be. Your initial question in this thread asked is there any clean way to get newer intel-graphics drivers on fedora 14? Gene provided an answer to that question, providing a recipe that may provide a hybrid of parts of F14 and F15. This may or may not work (I'm wary of such hybrid approaches) - but I understood that Gene was trying to be helpful. This is the development mailing list for Fedora so the standard for a simple fix may be different from the Fedora user mailing lists. It may be that there's no good way to make this hybrid work (for some definition of good e.g. minimizing the number of steps, being maintainable etc), and that the best way to make this hardware work is to upgrade to Fedora 15. It seems that you are unhappy with that, and your unhappiness with that seems to stem from unhappiness with systemd. Please try to redirect that into non-emotional statements of what is wrong with the software, in a form that can be acted on, and turned into patches. In particular, read: http://fedoraproject.org/wiki/BugsAndFeatureRequests http://www.chiark.greenend.org.uk/~sgtatham/bugs.html http://www.softwaretestinghelp.com/how-to-write-good-bug-report/ It may also help to take a break from using the computer if it is making you unhappy. [snip rest of mail] I hope this is helpful Dave (borrowing from Smooge's sig) Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: effective communication and effective free software
On 6/13/11 12:18 PM, Denys Vlasenko wrote: Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. I'd have more empathy for your position if you'd made even a cursory investigation into what that memory was being used for. To be clear, this is an observation about how you're presenting your argument. The original post reads mostly as this looks like it's doing too much, because of these things that I don't understand but I just _know_ they're not necessary, so obviously this is all crap and everyone who's working on it should be ashamed. Even if you were right, that's not a tone of voice that makes people want to listen to you. Would you rather make a good OS, or have internet arguments about why we're making a bad OS? If you approach a project by saying I've found that we're burning a lot of memory here, and I don't quite understand why, but it seems to be related to the frobnitz component, that's productive. It shows that you're concerned with quality, and that you've put some effort into understanding how things are already structured, even if you don't have a solution. It's a sign that you have some skin in the game (apologies if that idiom doesn't translate well). Instead, when you say things like: It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. ... the message is that you're not, in fact, invested, that you're perfectly happy to just switch back to twm because you don't need all that fancy stuff. That's an individual choice you are perfectly free to make, of course, but this is not the list for here's the choices I've made to set up my Fedora machine just the way I like it. This is the list for solutions, not configurations, and not complaints. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 08:43:46AM -0400, Simo Sorce wrote:
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Shooting multilib in the head and just using 64 bit everywhere?
The only reason to have support for 32 bit is because of closed source
software, and I don't have any of that on all but two of my (dozens of)
machines.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guide to setting karma thresholds?
On Mon, Jun 13, 2011 at 10:43:42AM -0500, Michael Ekstrand wrote: I'm working on pushing my first bugfix to F15 (#711261), using the guides I found in the wiki[1][2]. For a non-critical-path package, the Update Policy says that it needs to meet the positive karma threshold set by the submitter, but does not indicate what that threshold should be or guidance for determining appropriate values. The default is 3; I'm assuming that leaving it there is a reasonable thing to do (and I won't be surprised if the 7-day criteria will be hit first for this package). However, I am still wondering: is there any guidance or policy published on how to determine appropriate karma thresholds? What justifies increasing or decreasing the thresholds? Userbase? Impact of change? I always leave them as the defaults. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Mon, 2011-06-13 at 10:25 +0200, Vít Ondruch wrote: Dne 11.6.2011 16:21, Gilboa Davara napsal(a): On Fri, 2011-06-10 at 16:25 +0100, Tom Hughes wrote: On 10/06/11 16:12, Michael Cronenworth wrote: Richard W.M. Jones wrote: They are available, but I think you have to build them yourself from source. All the information is here: 2. Make guest additions dead simple to install. Having to compile them with a Windows DDK is not dead simple. Actually building the driver (once I'd downloaded the 620Mb DDK) was quite easy. I'm still scratching my head over how to actually install it though ;-) Actually, even if you build the driver and get it to work, you're still stuck with the Windows' driver signature enforcement which makes installing unsigned drivers (such as one that you build yourself) more-or-less impossible (I tried every possible software / hack-ware to disable it and failed; ended up getting used to manual F8/Disable signature enforcement boot sequence). I fear that as long as RH doesn't MS the (protection) fees required to sign the QXL driver, I fear that this issue will remain unresolved. (On the other hand, nothing stops -me- from doing it and yet I don't see me running to do it :)) May be this can help: http://www.reactos.org/wiki/Driver_Signing Thanks. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
On Sun, Jun 12, 2011 at 02:06, Petrus de Calguarium pguec...@gmail.com wrote: John5342 wrote: I forget which one exactly contains the mp3 plugin gstreamer-plugins-ugly, I believe i just install all of them and then i don't have to worry about any other format i may one day come across. ditto The same plugins are also used by just about every other form of KDE based audio/video. That includes everything from video players like Dragon to audio players like Amarok to System Notifications etc. Curious. I thought Dragon must use xine-lib, since both kdemultimedia and kdebase-runtime require it in F15. At least in kdemultimedia, wine-lib seems to be required for dvd support (which is usable within Fedora assuming they are not encrypted and usable on encrypted dvds with libdvdcss) which is a little more advanced than phonon can handle (complex and separate videos, menu navigation etc) and therefore handled separately. I don't know about kdebase-runtime but i imagine that has it's own independent purpose. Dragon does seem to use phonon for most of it's stuff though. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
conclusion: F15 / systemd / user-experience
first sorry for some bad words from mine, but this is how i feel in a situation not knowing how to act since upgraded short ago to F14 in the hope get my energy refreshed staying there for some months and now realizing i will newer get new intel hardware well supportd on it __ please respect that some people are having really troubles with their health (what is happening to me this time in a way i wish not for my worst enemy), trying to make a great job at the same time as far as it is possible many of them (as i) have taken responsible for a lot of systems running really well with F14 and are having simply not the mental and physical energy to switch their whole setup in an invasive way but they are forced to do this because they needed new hardware and if you buy hardware now which should work 5 years or longer you will take the latest generation :-( __ REALLY: Fedora should consider a not so invasive way like KDE4, GNOME3, systemd in an early release especially for updated systems because what sometimes happens here is that features are included at a time some people are hoping they are ready and on the other hand kernel-updates like for F6/F7/F8 are stopped in the latest releases - 2.6.38 would support new intel-network cards what after that happens with power-users which are not only insert a CD and taking all as pre-configured is anger, frustration, fear try to fully support their configurations for two releases and only install KDE4, GNOME3, systemd on new setups as default will bring you a real userbase to optimize things without destroy the experience of users which are loving Fedora since Fedora Core 3 and showing their wish to have a little time to get warm with new features without the feeling take it or leave it is respected as said: i love the idea of systemd and i am sure this will finally be a great thing, but we all know there are bugs in new and complex software - so if Fedora would try not be so invasive to existing setups peopole with more than one machine have the option to wait some weeks/months before the first after-release bugs are fixed while they can update on new hardware for several reasons (Sandy Brdige network/graphics) without Am 13.06.2011 09:47, schrieb Kevin Kofler: For KDE, it was just plain impossible to support both 3.5 and 4.0 and so it was the wrong decision ship KDE4.0 which was really unusable and upstream declared only for developers! before 4.2 KDE4 was buggy like hell and missing a lot of options nearly the same happens now with GNOME3 and is a spit in the face for many users which are switched from KDE4.0 to GNOME because KDE4.0 was not useable for them in the same distribution without violating the FHS. interesting argument where do you find /run in the FHS anger oh i frgot this is for systemd and tech reasons needed which are more important as the users which have to live with your decisions /anger signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 07:57:46PM +0200, drago01 wrote:
On Mon, Jun 13, 2011 at 7:44 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Jun 13, 2011 at 08:43:46AM -0400, Simo Sorce wrote:
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Shooting multilib in the head and just using 64 bit everywhere?
You only getting 32bit libs / apps when you install them so no reason
to get rid of them and make life harder for those who need them.
Obviously I was being deliberately provocative by my original
statement.
Nevertheless, multilib is a broken hack which imposes a burden on me
as a packager, even though I rarely if ever enjoy the fruits of it. I
still have to deal with multilib packaging bugs as they come up.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
so now i have the options of a upgrade to F15 while much work, hughe health troubles and 2 weeks holidays are priority one in my life this time Maybe if you complained less on mailing lists you would have time to try out F15. I have problems on my hardware as well (https://bugzilla.redhat.com/show_bug.cgi?id=711489), but I do not whine about it on this mailing list. Every moment the devs spend reading and aswering pointless rants there is less time to do actual development and fix real bugs. You seem to want that the Fedora devs provide newer Linux packages for F14. I would like that to. But that takes a lot of resources that are much better spent elsewhere, like fixing reported bugs! (Please fedora devs, fix my bugs :) ) /Andreas Tunek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
but they are forced to do this because they needed new hardware and if you buy hardware now which should work 5 years or longer you will take the latest generation :-( You always have a choice which hw to buy. Sometimes you have to buy hw to support the sw you want to run. If you want to run F14 you should buy hw that supports F14 (or hw that F14 supports, whichever you want to put it). /Andreas Tunek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On Mon, 2011-06-13 at 20:36 +0200, Reindl Harald wrote: first sorry for some bad words from mine, but this is how i feel in a situation not knowing how to act since upgraded short ago to F14 in the hope get my energy refreshed staying there for some months and now realizing i will newer get new intel hardware well supportd on it __ please respect that some people are having really troubles with their health (what is happening to me this time in a way i wish not for my worst enemy), trying to make a great job at the same time as far as it is possible many of them (as i) have taken responsible for a lot of systems running really well with F14 and are having simply not the mental and physical energy to switch their whole setup in an invasive way but they are forced to do this because they needed new hardware and if you buy hardware now which should work 5 years or longer you will take the latest generation :-( __ As others have said: you chose the wrong tool for the job. Fedora isn't for running on anything you want to keep stable in service for a long time. Heck, even the http://fedoraproject.org/en/about-fedora page explicitly says that fedora devs don't mind shaking up the status quo, when it means we can more effectively move free software forward So maybe you should consider switching your servers to a RHEL 6 (or clone) so they'll be stable and have new hardware support. Heck, even for my home servers I don't run fedora because shaking it up every 6 months or so is a pain...I can't imagine trying it on production servers. Brian [For the record, I like systemd, but I couldn't stomach Gnome3. So the F15 upgrade was a mixed bag for me. Switched to XFCE and I'm happy again] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
Petrus de Calguarium wrote: Curious. I thought Dragon must use xine-lib, since both kdemultimedia and kdebase-runtime require it in F15. It used xine-lib directly, only because phonon lacked support for DVD menus (until recently). kde-4.7 will (should!) fix that. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
mån 2011-06-13 klockan 11:52 -0400 skrev Simo Sorce:
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
Don't think of it as primary and secondary. Think of it as the arch
that got its hands on /usr/lib first and the arch that had to make do
with another directory for its conflicting files.
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
I don't think that's what Lennart means...
The difference between libraries and binaries is that with libraries you
sometimes need both the primary and the secondary, but with binaries you
only need one, so those binaries can go in the same directory /usr/lib
regardless of their arch. (Just like there's no bin64.)
To put it another way:
Sure, /usr/libexec could be removed, but there's no need to then split
its content into /usr/lib and /usr/lib64. Only use lib64 in the cases
where there would be a conflict between the two arches.
/abo
--
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 Mon, Jun 13, 2011 at 10:33:19AM +0200, Lennart Poettering wrote: Uh, and even much healthier than Upstart, which you seem to be a big fan of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it cannot be that low) I'm guessing its just ohloh having as much trouble operating launchpad as humans do. I know I have quite a large branch somewhere in there, but it usually takes me a good while to find evidence of it too. In general, though, someone else would have to understand what Upstart is supposed to be in order to contribute code. Since that is explicitly and by choice only documented in Scott's head, its kinda hard to do. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 713001] EPEL override bug
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=713001 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Flag||fedora-cvs? --- Comment #1 from Tom spot Callaway tcall...@redhat.com 2011-06-13 16:55:14 EDT --- Package Change Request == Package Name: perl-Gtk2 New Branches: el6 Owners: spot -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 713001] New: EPEL override bug
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: EPEL override bug https://bugzilla.redhat.com/show_bug.cgi?id=713001 Summary: EPEL override bug Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-Gtk2 AssignedTo: tcall...@redhat.com ReportedBy: tcall...@redhat.com QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- perl-Gtk2 has no Review Request ticket, so I'm creating this to process an EPEL branch. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. I think this is the crux of the argument. It seemed to me one of the goals of systemd was to stop having a wide variety of possible mechanisms to do similar things. To intentionally remove the ability to swap out components. Part of that was to make things faster, part of it was to make them simpler (for uses of simpler meaning fewer options). The trick is whether or not you agree with that as a set of goals. If you do not then systemd is not fun and not for you. If you do then you are happy with it. I think the problem I've heard repeatedly is that a fair number of people are surprised how the decisions about those goals were made. I also think that as it becomes more well known: the lack of flexibility in specific places in systemd will be patched out/around. So, the items you're complaining about will become options or configuration items when people with significant-enough clout demand they change. It happens all the time. Some folks adapt to how things are and work with what their given. Others take out a baseball bat and beat things until they work and send their patches along. Others still take out a checkbook and start writing checks or alternatively, refrain from writing those checks. -sv -- 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/13/2011 02:10 PM, seth vidal wrote: On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. I think this is the crux of the argument. It seemed to me one of the goals of systemd was to stop having a wide variety of possible mechanisms to do similar things. To intentionally remove the ability to swap out components. Part of that was to make things faster, part of it was to make them simpler (for uses of simpler meaning fewer options). The trick is whether or not you agree with that as a set of goals. If you do not then systemd is not fun and not for you. If you do then you are happy with it. I think the problem I've heard repeatedly is that a fair number of people are surprised how the decisions about those goals were made. I also think that as it becomes more well known: the lack of flexibility in specific places in systemd will be patched out/around. So, the items you're complaining about will become options or configuration items when people with significant-enough clout demand they change. -sv Coming out of pure lurk mode - I think Seth's observations here are true for a many of the things that have gone on in Fedora recently (at the risk of opening wounds... eg. gnome3). Your options are: 1) Complain 2) Get involved in the development to the point where you are one of those with enough clout to 'demand change' - or at least do 1) with some concrete technical observations as devoid as possible of vitriol and anger, at which point Complain would no longer really be the correct term. 3) Quietly move on to something more suited to your needs. For my part I've chosen 3). My servers have always run Scientific Linux and I've migrated my laptop to SL6 rather than F15. My desktops and those of my users have been updated to F14, though I'll 'support' F15 for those who want to pursue that upgrade path. In the F14 EOL time frame, I'll re-evaluate F16 wrt whether some of my issues with F15 have been patched out/around and make a decision as to whether to fully migrate away from Fedora at that point. As a pure consumer of the product without the time to get involved with 2), I don't think it's my place to pursue 1), nor would it be very productive. If you choose to pursue 1), I think you'd have more success and have a more productive hearing if you were to also engage in 2). To pursue only 1), as many seem to, will only lead to bad blood and a sore head as you continue to bang it into that tree. To emphasize, this is not intended as a complaint or a flame towards those working on Fedora development - just an observation on where time might be more productively spent for those who have a problem with certain components/development directions in Fedora. Returning to lurk mode, -Karl -- | Karl A. Misselt Office: Steward 254 | | Steward Observatory Phone: 520-626-0196 | | University of Arizona FAX: 520-621-9555 | | Tucson, AZ 85721-0065 miss...@as.arizona.edu | |Malo Periculosam Libertatem Quam Quietum Servitium| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
The distinction between stuff which belongs into %{_libdir}, which is
different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
place and where only one copy should be installed.
Now it's possible to hardcode /usr/lib (and some stuff notoriously does
this), but IMHO this is all broken. Everything installed by an x86_64 RPM
into /usr/lib is in the wrong place. It should be in /usr/libexec,
/usr/share, /usr/bin or /usr/lib64.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
Rex Dieter wrote: It used xine-lib directly, only because phonon lacked support for DVD menus (until recently). kde-4.7 will (should!) fix that. Also note that the DVD menu hack in Dragon Player only works with phonon- backend-xine. Hopefully we'll soon have code which uses the new Phonon interfaces, which work with phonon-backend-gstreamer (the new default). As for kdebase-runtime, it has a System Settings module to configure Phonon- Xine. That stuff needs to go away in Rawhide along with phonon-backend-xine. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
Coming out of pure lurk mode - I think Seth's observations here are true for a many of the things that have gone on in Fedora recently (at the risk of opening wounds... eg. gnome3). Your options are: 1) Complain 2) Get involved in the development to the point where you are one of those with enough clout to 'demand change' - or at least do 1) with some concrete technical observations as devoid as possible of vitriol and anger, at which point Complain would no longer really be the correct term. 3) Quietly move on to something more suited to your needs. Coming out of pure lurk mode here as well. I have been with this distro since RH4 and have had a great time doing so. Almost every upgrade has been really smooth with only a few minor setbacks like an odd broken dependency that was easily fixed, but F15 is the end for me. I think Karl summed it up pretty well. We can't always agree with every decision, but as our license fees are less than substantial :) we have to live with (semi-)democratic decisions. I have chosen 3), not because of systemd (which I like), but GNOME3 (which I would love on a pad device or a 10 foot device, but can't stand on a laptop/workstation), but reading Karls comments made me think one more step. I don't think it is beneficial for me, or for the distro, if I _quietly_ move on to something else. I didn't go for 2) as I don't have time to be an active contributor, but the least I can do is to share the rationale behind my decision to leave. So here is a quick highlight of my personal thoughts on GNOME3: 1) I miss having a bar where I have an overview of my work/life. 2) Why do I get to activities first when I move my mouse to the hot spot? I'm trying to start a new application 3) When switching to Applications the default show all applications, which on a phone works great but on a workstation just floods my screen. I do have more than 16 applications. 4) Luckily I can still select a group of applications to narrow my search, but why is the hot spot in the top left corner and my list of groups on the far right side? A lot of mouse movement for a trivial, and commonly used, task. 5) The default icon size in the application menu would work great on my TV when I'm sitting in the sofa, but on my laptop they are gigantic. 6) Favorites are a great idea. A quick bar for access to my most commonly used applications. So I added terminal immediately, but why don't I get a new terminal when I click it the second time? Yeah, I know you can use a two-finger approach, but first of all I open new terminals/OpenOffice/FireFix/... all the time so it's a common task, second it's duplicating the activities window, which is the first to show when you move to the hotspot anyway. 7) Shutdown has been mentioned enough already 8) My impression is that GNOME3 is trying to compete with Android and FrontRow, but have forgotten all of us who still uses desktops/laptops. We don't have touch screens yet And yes, I know a lot of things are configurable and you can always create an extension to fix things to your likings, it's all software, right? But I'm a fairly experienced user and I spent a full working week trying to get around my (and my peers) complaints and failed and I, personally, don't think you should need to spend 40 hours to understand a user interface in 2011. GNOME3 might be the right decision for Fedora, but it is not the right decision for me and my users. //Sincerely Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guide to setting karma thresholds?
Luke Macken wrote: Yeah, we have yet to step back and really think about the defaults for the karma thresholds, after having the +3/-3 defaults for so long. Some maintainers set the values very low to decrease the amount of time their update spends in testing, and some set the values really high (or disable them) to ensure that their update doesn't change state without mantainer intervention. It's designed to fit both maintainer styles. I think we should stop enabling autokarma by default, and instead let maintainers push stuff manually as soon as the karma is at +1, no matter what the autokarma is set to (or whether it's even enabled). (This doesn't give any more power to the maintainers than the current system, because the threshold is settable by the maintainer! All it'd do is remove the incentive to set a too low autokarma.) (Now I actually think we should kill this whole karma concept entirely and let the maintainers decide, but that isn't going to be acceptable to FESCo, unfortunately. The proposal in the previous paragraph, on the other hand, should be consistent with FESCo's requirements.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Karl Misselt wrote: Coming out of pure lurk mode - I think Seth's observations here are true for a many of the things that have gone on in Fedora recently (at the risk of opening wounds... eg. gnome3). If GNOME 3 is your problem, try KDE Plasma or Xfce. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
José Matos wrote: I am sorry not to have replied before but in the place (local network) where I have been I had access to imap but not smtp (weird I know) and it is klunky to answer using a webmail interface. :-( And NNTP(S)? This list is gatewayed as gmane.linux.redhat.fedora.devel on news.gmane.org (NNTP) and snews.gmane.org (NNTPS), you can use any Usenet News client (e.g. KNode) to read and post to this list. Kevin Kofler (who is using KNode to post this message) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
Am 14.06.2011 01:49, schrieb Kevin Kofler: I also miss those kernel upgrades. I think we've become much too conservative. and the combination is which i really not understand * kernel - conservative * kde4/gnome3/systemd - go ahead with all consquences and the kernel is really not a big deal because the updates are normally not invasive All this 4.0 is only for developers messaging came way too late. We had already worked hard on making everything work with 4.0 in pre-F9 Rawhide at that point. the mistake happended long before! as KDE4.0 was anounced for F9 nobody did know if they are ready and which state kde4 would have in the first release We also worked really hard to make 4.0 work as well as possible. I made several (completely unpaid!) 30+ hour days to build bugfix releases, fix showstoppers etc. The other KDE SIG developers also worked for many hours on that stuff. We were able to ship Fedora 9 with no true showstopper and we fixed the most annoying bugs in updates before or within days of the release. nobod said that there was no hard work but is it really needed to decide major upgrades without knwoing what state the software finally would have instead take a breath and fixing existing bugs since every 6 months is a new release and no reason to hurry it would be really a godd idea to take every second release only for bugfixing and kernel-upgrades for hardware-support and only every econd release to bring new stuff - there are so many small bugs and edges everywhere that there is no need for such a hurry signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
about language packs in fedora we do yum -y groupinstall development tools but in portuguese yum -y groupinstall ferramentas de desenvolvimento and in spanish is another thing its possible to change yum to accept both english and internacionalized language ? - Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
Reindl Harald wrote: as KDE4.0 was anounced for F9 nobody did know if they are ready and which state kde4 would have in the first release We need to do some advance planning and development to provide a polished release to our users, so we have to start importing prereleases of new upstream software very early in the cycle, especially for a big change like KDE 3→4. We have neither the infrastructure nor the human resources to do this work on a separate development branch, so we have to do it in Rawhide, at which point everything in Rawhide gets ported to the new technologies and it's very hard to go back. It is upstream's failure to not have communicated upfront that 4.0 would not be a release they'd want shipped to end users. There were some developers claiming it'd be a great new release with lots of new features they were working on, and a few others merely cautioning that it'd be for early adopters (whom Fedora users are expected to be). That only for application developers claim came only later, when Rawhide was already upgraded to 4.0. If the upstream developers had been less optimistic about their new release right from the start, we might have taken a different decision. That said, I actually think Fedora 9 turned out as a great release, KDE 4.0.3 wasn't quite as broken as some people (including some upstream developers) were claiming, and KDE got better and better in updates. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On Tue, Jun 14, 2011 at 02:19:38AM +0200, Reindl Harald wrote: Am 14.06.2011 01:49, schrieb Kevin Kofler: I also miss those kernel upgrades. I think we've become much too conservative. and the combination is which i really not understand * kernel - conservative * kde4/gnome3/systemd - go ahead with all consquences 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. -- Scott Schmit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
Itamar Reis Peixoto wrote: about language packs in fedora we do yum -y groupinstall development tools but in portuguese yum -y groupinstall ferramentas de desenvolvimento and in spanish is another thing its possible to change yum to accept both english and internacionalized language ? You can use the internal identifier (which is never translated), i.e.: yum groupinstall development-tools Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 2:48 AM, Michal Schmidt wrote: On Sun, 12 Jun 2011 22:14:27 -0400 Orcan Ogetbil wrote: Having a quick look at the link and at the steps to reproduce the bug gave me shivers. Are we really sure that systemd is ready? I mean, I don't even call my code alpha if it can't parse a slash correctly. Strictly speaking, it parses the slash correctly and it's a bug in /bin/mount. But I understand that's hardly a consolation for those who are affected by this bug. Right, if it was working before and stopped working now, pointing fingers at this point will not help the situation. Such a trivial scenario could have been tested and fixed by the author of the code before it was released to public. I hope this will stay as worst bug in systemd (or triggered by systemd, however you want to put it). Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
On Mon, Jun 13, 2011 at 9:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Itamar Reis Peixoto wrote: about language packs in fedora we do yum -y groupinstall development tools but in portuguese yum -y groupinstall ferramentas de desenvolvimento and in spanish is another thing its possible to change yum to accept both english and internacionalized language ? You can use the internal identifier (which is never translated), i.e.: yum groupinstall development-tools Kevin Kofler where I can get a list of internal identifiers -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- 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 Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 13:30 -0400, Simo Sorce wrote: What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. But until you can get the real one you basically are. Yes, and as far as it is a temporary condition for a few seconds at boot, it's not a problem. So why the rush to set it as soon as possible via systemd? Seriously, what are you arguing about ? It is so simple to set it via systemd and it *is* an init task that it just fine to set it in there so all process will just have the right answer from the get go. Unless there is a *problem* with doing it early I really don't want to get int the bike shedding here. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! Because it *is* a system initialization task, and systemd can do it better than a shell script called in a random order later on, without, as far as I can see, any side effects in this case. I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago, unless you want to argue for getting rid of it completely and reverting back to the previous init mechanism. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
