Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On Wed, Nov 24, 2010 at 8:32 AM, Hans de Goede wrote: > Hi, > > On 11/24/2010 12:45 AM, Jesse Keating wrote: >> On 10/5/10 3:27 PM, Jesse Keating wrote: > > > >> >> Here is a list of the current known potentially bad builds and what >> action could be or has been taken: >> >> wildmidi - my rebuild can be tagged >> tecnoballz - my build can be tagged > > These 2 are mine and FWIW, I'm ok with directly tagging > the rebuilds into updates Actually tecnoballz is mine. But I'm ok with the tagging anyway. Bye, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
This may be not a question for you but just wonder.. > On Tue, 23 Nov 2010 21:48:30 +0100, > "LP" == Lennart Poettering wrote: LP> http://0pointer.de/public/systemd-man/tmpfiles.d.html That sounds like creating a directory at the boot time though, does this mean rebooting are required to get it working anyway? even though it worked without rebooting before, isn't it a kind of regression? or am I missing something I can do in the scriptlet to create the directory immediately? -- Akira TAGOH pgp2ZHHkLQzEx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
> Here is a list of the current known potentially bad builds and what > action could be or has been taken: The below I either maintain or co-maintain. Ignore, I have another build that needs to be pushed: > syncevolution - update in testing Fine to tag for F-14, its obsolete in F-15 (I thought it was blocked - will check): > mutter-moblin - my build can be tagged (and tag into dist-f15) Happy for all the below to be tagged: > moblin-panel-status - my build can be tagged > moblin-panel-people - my build can be tagged > moblin-panel-myzone - my build can be tagged > moblin-panel-applications - my build can be tagged > jana - my build can be tagged > clutter - my build can be tagged > celt - my build can be tagged Should be in updates or nearly there: > meego-panel-datetime - update in testing > clutter-gtk - fixed build in updates Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
Dne 24.11.2010 03:28, Ralf Corsepius napsal(a): > No, it's not your fault (Or at least only partially). A functional QA > would catch such kind of breakages. Yes, but functional QA would require more manpower than Fedora QA currently has. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On 11/24/2010 10:45 AM, Matej Cepl wrote: > Dne 24.11.2010 03:28, Ralf Corsepius napsal(a): >> No, it's not your fault (Or at least only partially). A functional QA >> would catch such kind of breakages. > > Yes, but functional QA would require more manpower than Fedora QA > currently has. That's one perspective. Another one is: The approach having been taken is non-feasible/impractiable/unsuiteable. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, Nov 24, 2010 at 12:01:45AM +0100, Lennart Poettering wrote: > On Tue, 23.11.10 23:02, Till Maas (opensou...@till.name) wrote: > > > The release notes section contains this: > > | /var/run and /var/lock are now mounted from tmpfs, and hence emptied on > > | reboot. Applications must ensure to recreate their own files/dirs on > > | startup, and cannot rely that doing this at package installtion will > > | suffice > > > > But this does not mention tmpfiles.d which you wrote can be used instead > > of creating files or dirs on startup. > > Added a comment about this now. > > > > c) YOU need to edit your .spec file and place a %ghost where > > > appropriate. > > > > > > c) YOU need to test if you package still works, and if necessary file > > > AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch > > > it so that it is able to recreate these directories beneath /var/run on > > > its own. > > > > Imho there should be a packaging guideline to make it clear what needs > > to be done in which cases. E.g. when to %ghost files and when not. > > I guess extending the guidelines with a line or two about this is a good idea. > I see you've already filed some bugs but in the future it would be best to get the packaging guidelines worked out before you do that. Most notably because it seems like you're going to have to now file an update to all of those bugs due to: > > > > For more details consult the man page: > > > > > > http://0pointer.de/public/systemd-man/tmpfiles.d.html > > > > Here it says: > > | If a file or directory is older than the current time minus the age > > | field it is deleted. > > > > And when are the files and dirs created? Only when the system is > > booted? > > Yes. > > > But then after installing an package that requires files to be created > > by tmpfiles.d the system needs to be rebooted before it can be used. Or > > will rpm call something that parses the appropriate tmpfiles.d file when > > the package is installed / updated? > > Hmm, it has been suggested that we should make it possible to create > these dirs in the .spec files by invoking the systemd-tmpfiles tool > directly from the scriptlets. I guess we should add a nice interface for > that. In the meantime it should be sufficient to simply place th right > "mkdir -p -m ..." in the scriptlet. Of course it would be desirable if > we have a single place where the dirs to create are encoded. > A question I'd have when looking over a proposed packaging guideline would be: why %ghost the directories? Why not include the directories as normal but add the tmpfiles.d step in addition? -Toshio pgp0h697NTPXD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 23/11/10 23:01, Lennart Poettering wrote: > On Tue, 23.11.10 23:02, Till Maas (opensou...@till.name) wrote: > >> The release notes section contains this: >> | /var/run and /var/lock are now mounted from tmpfs, and hence emptied on >> | reboot. Applications must ensure to recreate their own files/dirs on >> | startup, and cannot rely that doing this at package installtion will >> | suffice >> >> But this does not mention tmpfiles.d which you wrote can be used instead >> of creating files or dirs on startup. > > Added a comment about this now. > >>> c) YOU need to edit your .spec file and place a %ghost where >>> appropriate. >>> >>> c) YOU need to test if you package still works, and if necessary file >>> AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch >>> it so that it is able to recreate these directories beneath /var/run on >>> its own. >> >> Imho there should be a packaging guideline to make it clear what needs >> to be done in which cases. E.g. when to %ghost files and when not. > > I guess extending the guidelines with a line or two about this is a good idea. > >>> >>> d /var/run/screens 1777 root root 10d >>> d /var/run/uscreens 0755 root root 10d12h >>> >>> >>> This encodes that two directories are created under the listed names, with >>> automatic clean up after 10 days resp. 10 days and 12h. >> >> Removing /var/run/screens after 10 days sounds wrong. Even removing the >> sockets inside /var/run/screens sounds wrong. Is this just a bad example >> am I not understanding the age means. > > Sorry, it's not necessarily a great example. > > The aging stuff is mostly useful for things like /tmp itself. > >>> For more details consult the man page: >>> >>> http://0pointer.de/public/systemd-man/tmpfiles.d.html >> >> Here it says: >> | If a file or directory is older than the current time minus the age >> | field it is deleted. >> >> And when are the files and dirs created? Only when the system is >> booted? > > Yes. > >> But then after installing an package that requires files to be created >> by tmpfiles.d the system needs to be rebooted before it can be used. Or >> will rpm call something that parses the appropriate tmpfiles.d file when >> the package is installed / updated? > > Hmm, it has been suggested that we should make it possible to create > these dirs in the .spec files by invoking the systemd-tmpfiles tool > directly from the scriptlets. I guess we should add a nice interface for > that. In the meantime it should be sufficient to simply place th right > "mkdir -p -m ..." in the scriptlet. Of course it would be desirable if > we have a single place where the dirs to create are encoded. Why not create the directories in the initscript/systemd equivalent? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Tue, Nov 23, 2010 at 05:51:06AM +0100, Miloslav Trmač wrote: > Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800: > > Also security updates should not have any other changes mixed in. > In the early days of Fedora, it was explicitly decided that (contra > Debian) maintainers are not required to backport patches and that > rebases (fixing a bug by updating to a new upstream release) are the > most expected kind of update. > > It seems the consensus on this decision is not as strong as it used to > be, nevertheless - with the number of package maintainers that admit > they can't fix bugs in their packages on their own, is overturning this > policy even possible? > Mirek Thanks, Mirek, for pointing out the first issue with this idea. The second issue is that Fedora doesn't have a security team which fixes security issues. We have package maintainers and the people they can/will ping to come up with solutions for security issues. The security team was just there for keeping track of when security issues are reported in other venues and seeing that we addressed them in Fedora (I'm not sure how active it still is either.) -Toshio pgpxuED8oDbFf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Tue, Nov 23, 2010 at 08:31:15AM +, "Jóhann B. Guðmundsson" wrote: > On 11/23/2010 06:51 AM, Ralf Corsepius wrote: > > IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs", > > it's bugs not getting fixed in Fedora, for a variety of reasons. > > > > Therefore, I consider trying to apply any such simple "policy" to be > > impossible and naive. > > Agreeable logical conclusion. > > The underlying problem needs to get address and fixed first. > > I proposed this as a possible long term solution in one rough possible > way a bit back on a different list to try to address the underlying > issue but I did not receive any feedback on that proposal. > > 1. Improve the general standard of packagers ( need to at least have > upstream bugzilla account and are part of or in good communication with > the upstream community ) > 2 Allow for a adjusting period when it's over revoke the rights from > those that already have but do not full fill this requirements. Package > goes up for grabs or gets dropped. I don't agree with the combination of the above two. The first is a nice to have but we also have to realize that requiring that will require lots more manpower. Step #2 is basically the enforcement phase for making #1 a requiement. I think that at some point maintaining a package becomes too much effort and as the number of packages that were too much effort build up, the utility of Fedora goes down. > 2. Allow all maintainers to touch every component in Fedora note that > maintainer that brought the component to Fedora is still responsible for > his components. > I like this idea. > 3. Gather what information from all those maintainers we have in the > community what their code skill are and in which language and what skill > level their expertise is. > 4. Assemble a "bug fixing task force" ( can be per language ) to target > component ( including testers if needed ). I like this idea as well however... > 5. Assign a component to the "bug fixing task force" and assign a time > period they should spend looking at the bugs on that component and > fixing them could be a day a week a month starting from critical path > and onwards. We have a tiny version of this in the FES tickets for fixing bundled libraries. I note that the python sub-ticket of that is the only one that's been closed. The C and php ones have hardly been touched. I'm not sure what would make this experience more productive. -Toshio pgpCbzZtkRQZP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update for openldap available
On 11/23/2010 06:51 PM, Jan Vcelak wrote: > Just submitted to updates-testing. Please, test. > > 656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd > 655899 - outdated list of overlays in slapd.conf > 652822 - ldapsearch -Z hangs server if starttls fails > > Jan Honzo, dik za rychlou reakci a perfektni komunikaci na f-develu! :) Radek -- Radek Vokál Engineering Manager - Base Operating Systems Brno Office: +420 532 294 111 Mobile: +420 608 437 507 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 10:39:27PM +0100, Björn Persson wrote: > Toshio Kuratomi wrote: > > There's one easy but deeply flawed way to do this -- automatically create > > a usern...@fedoraproject.org bugzilla account for the user with the > > password used in FAS. Deeply flawed in this case because the passwords > > can get out of sync, we're creating accounts when people sometimes want to > > use a different address in bugzilla and fas, etc. > > Hmm, but it says here that we should use the same address in Bugzilla and FAS: > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > Yes, you should. When you don't the infrastructure admins get spammed until someone either fixes the mismatch or alerts me and I get time to put in a mapping for the bugzilla email address. > > We don't control RH > > bugzilla so changing bugzilla to be able to use fas to login would be > > problematic. > > That solution seems backwards anyway. I think most new contributors probably > report bugs long before they become packagers, so they need Bugzilla accounts > before they need FAS accounts. > > How about changing Bodhi to allow login with either a FAS account or a > Bugzilla account? Would that be difficult to do? > Yes. Everything in Fedora uses the FAS account. So, for instance, bodhi needs to know whether the person pushing an update has permission which means that they need to enter their fas account to match up with what's in the pkgdb. Implementing a separate login just for comments would also be a lot of extra work although it would be more segregated from the rest of the code so it might be doable. -Toshio pgpgCjFyutE0l.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101124 changes
Compose started at Wed Nov 24 08:15:05 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) ibus-sunpinyin-2.0.2-2.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) kde-plasma-yawp-0.3.5-4.fc15.x86_64 requires libweather_ion.so.5()(64bit) 3:koffice-krita-2.2.84-1.fc15.x86_64 requires libkdcraw.so.8()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 mars-sim-2.84-6.fc14.noarch requires commons-collections meego-panel-devices-0.2.4-4.fc15.x86_64 requires libdevkit-power-gobject.so.1()(64bit) meego-panel-devices-0.2.4-4.fc15.x86_64 requires libnotify.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires libnetsnmp.so.20()(64bit) 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 network-manager-netbook-1.7.1-0.1.fc14.x86_64 requires libnotify.so.1()(64bit) nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit) padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires libnotify.so.1()(64bit) pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1 pcmanx-gtk2-0.3.9-6.20100618svn.fc14.x86_64 requires libnotify.so.1()(64bit) pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit) qgis-grass-1.6.0-2.fc15.i
Re: The new Update Acceptance Criteria are broken
On 11/24/2010 12:22 PM, Toshio Kuratomi wrote: > On Tue, Nov 23, 2010 at 08:31:15AM +, "Jóhann B. Guðmundsson" wrote: >> On 11/23/2010 06:51 AM, Ralf Corsepius wrote: >>> IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs", >>> it's bugs not getting fixed in Fedora, for a variety of reasons. >>> >>> Therefore, I consider trying to apply any such simple "policy" to be >>> impossible and naive. >> >> Agreeable logical conclusion. >> >> The underlying problem needs to get address and fixed first. >> >> I proposed this as a possible long term solution in one rough possible >> way a bit back on a different list to try to address the underlying >> issue but I did not receive any feedback on that proposal. >> >> 1. Improve the general standard of packagers ( need to at least have >> upstream bugzilla account and are part of or in good communication with >> the upstream community ) "One size doesn't fit everybody" This is applicable in some occasions, but is non-applicable in many. >> 2. Allow all maintainers to touch every component in Fedora note that >> maintainer that brought the component to Fedora is still responsible for >> his components. >> > I like this idea. Hmm, we already have the proven-packagers group and we already have the concept of co-maintainers. >> 4. Assemble a "bug fixing task force" ( can be per language ) to target >> component ( including testers if needed ). > > I like this idea as well however... Again, proven-packagers already can do this. At least I occasionally applied my proven-packagers' privileges to troubleshoot critical situations. However, having done so, one lesson learnt from this, was this kind of help often only to be a short-term relief, but not to be a long term cure, because packages which are suffering from issues a "trouble-shooting group" is able to help often suffer from much deeper issues. Also, it's this kind of situations, where Fedora's QA's "delays" have shown to be counter-productive. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update for openldap available
Dne 24.11.2010 12:24, Radek Vokál napsal(a): > On 11/23/2010 06:51 PM, Jan Vcelak wrote: >> Just submitted to updates-testing. Please, test. >> >> 656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd >> 655899 - outdated list of overlays in slapd.conf >> 652822 - ldapsearch -Z hangs server if starttls fails >> > Honzo, dik za rychlou reakci a perfektni komunikaci na f-develu! :) Just a preliminary warning that Czech is going to be an official language of the Fedora project. :) Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Kevin Fenzi wrote: > * Change FN-1 to just security and major bugfix. Nothing else allowed. So, if: 1) a package is updated because of a security problem 2) next day, FN+1 is released 3) next day, it is found that the fix in 1) has a very minor bug (e.g. typo in a string) 4) the string is not fixable anymore: no minor bugfixes for FN-1 If the regression is cosmetic/performance etc. it will be left unfixed, and we can't really describe this distro as "Linux, you know, that wonderful world where problems are rapidly fixes by lots of people around the world". We should more honestly say that Fedora as two level of support: - 6 months (any bug) - additional 7 months (serious bugs only) Next, the Fn-2 -> Fn upgrade process can be sacrificed. I personally like all kind of updates in a stable distro. Even major ones (such as KDE). I, as a user, will not be so stupid to update my presentation software a few minutes before the important meeting with the boss. I also trust the maintainers to not frequently push crap at me. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Lennart Poettering : > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: > >> Hi, >> >> I would like to help with scripts conversion. IMO the conversion >> action should be coordinated. >> >> Comments, thoughts? > > I would certainly welcome any work in this direction! Could you look at the crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 and atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 and see if I did not do any fundamental error? Seems to me that these are simple enough at the beginning :) For both I used Type=forking - it works fine, but it seems to me that Type=simple might be a better choice. Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote: > 2010/11/24 Lennart Poettering : > > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: > > > >> Hi, > >> > >> I would like to help with scripts conversion. IMO the conversion > >> action should be coordinated. > >> > >> Comments, thoughts? > > > > I would certainly welcome any work in this direction! > > Could you look at the > crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 > and > atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 > and see if I did not do any fundamental error? > > Seems to me that these are simple enough at the beginning :) > > For both I used Type=forking - it works fine, but it seems to me that > Type=simple might be a better choice. For type=simple you would like “-n” switch in crond invocation. I suggest trimming Description, it is printed during bootup and should be short. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-24)
On Tue, Nov 23, 2010 at 8:37 PM, Bill Nottingham wrote: > Adam Jackson (a...@redhat.com) said: >> On Tue, 2010-11-23 at 13:05 -0700, Kevin Fenzi wrote: >> > Following is the list of topics that will be discussed in the FESCo >> > meeting tomorrow at 18:30UTC (1:30pm EDT) in #fedora-meeting on >> > irc.freenode.net. >> >> I'm not going to be able to make this, I'll be on the road for >> Thanksgiving. > > I am highly unlikely to make it, for similar reasons. > > Bill > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I will be on the road as well. Steven -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On 11/24/2010 01:41 PM, Michał Piotrowski wrote: > 2010/11/24 Lennart Poettering : >> On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: >> >>> Hi, >>> >>> I would like to help with scripts conversion. IMO the conversion >>> action should be coordinated. >>> >>> Comments, thoughts? >> I would certainly welcome any work in this direction! > Could you look at the > crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 > and > atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 > and see if I did not do any fundamental error? > > Seems to me that these are simple enough at the beginning :) > > For both I used Type=forking - it works fine, but it seems to me that > Type=simple might be a better choice. > > Best regards, > Michal Could you explain, what's the difference between https://bugzilla.redhat.com/show_bug.cgi?id=656864 and https://bugzilla.redhat.com/show_bug.cgi?id=617324 ? In the older bug was the correct script at least discussed. Why are you mass opening new bugs, when the old weren't solved and they could contain reasonable information as in this case? Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Tomasz Torcz : > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote: >> 2010/11/24 Lennart Poettering : >> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: >> > >> >> Hi, >> >> >> >> I would like to help with scripts conversion. IMO the conversion >> >> action should be coordinated. >> >> >> >> Comments, thoughts? >> > >> > I would certainly welcome any work in this direction! >> >> Could you look at the >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 >> and >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 >> and see if I did not do any fundamental error? >> >> Seems to me that these are simple enough at the beginning :) >> >> For both I used Type=forking - it works fine, but it seems to me that >> Type=simple might be a better choice. > > For type=simple you would like "-n" switch in crond invocation. Ah, ok, I'll keep forking. > I suggest trimming Description, it is printed during bootup and should be > short. I didn't noticed it - I guess "quiet" kernel param is also interpreted by SystemD. > > -- > Tomasz Torcz ,,If you try to upissue this patchset I shall be > seeking > xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton > (LKML) > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Marcela Mašláňová : > On 11/24/2010 01:41 PM, Michał Piotrowski wrote: >> 2010/11/24 Lennart Poettering : >>> On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: >>> Hi, I would like to help with scripts conversion. IMO the conversion action should be coordinated. Comments, thoughts? >>> I would certainly welcome any work in this direction! >> Could you look at the >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 >> and >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 >> and see if I did not do any fundamental error? >> >> Seems to me that these are simple enough at the beginning :) >> >> For both I used Type=forking - it works fine, but it seems to me that >> Type=simple might be a better choice. >> >> Best regards, >> Michal > Could you explain, what's the difference between > https://bugzilla.redhat.com/show_bug.cgi?id=656864 and > https://bugzilla.redhat.com/show_bug.cgi?id=617324 ? > > In the older bug was the correct script at least discussed. Why are you > mass opening new bugs, when the old weren't solved and they could contain > reasonable information as in this case? Sorry, I was not aware that Jóhann opened bugs for all this scripts. > > Marcela > > -- > Marcela Mašláňová > BaseOS team Brno > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 23/11/10 20:48, Lennart Poettering wrote: > Heya! > > I hereby want to let everybody know that in the next days I will turn on > /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance > with the following accepted F15 feature: We run stateless systems here and both of the above directories are listed in the default /etc/rwtab. We've not noticed any issues with that (note we disable selinux). cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2010 08:54 PM, Ben Boeckel wrote: > Jan Vcelak wrote: >> This is the problem: The database migration could take a really long time. I >> have testing data with 56 entries (nodes) - exporting (slapcat) is quite >> fast, >> but importing (slapadd) takes around 10 seconds. > > Hmm. I've seen selinux-policy-targeted take longer than this on > upgrades. SELinux is a little more obvious that it's doing something on > upgrade (and after looking at the spec file[1], I'd not sure whether I'd > have rather not known ;) ), but I don't think it'd be unheard of. > > --Ben > > [1]http://pkgs.fedoraproject.org/gitweb/?p=selinux-policy.git;a=blob;f=selinux-policy.spec > SELinux is just relabeling the labels that have changed between the previous and next release. It attempts to find the least common denominator. But sometimes it could end up doing the equivalent of restorecon -R -v /usr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztD7sACgkQrlYvE4MpobNjlwCfai5eeCkhtcJzMQi+R6YUkWzF uQ8AnAmGOiLAzErBDHEv7NvTVyaif5I7 =b/aB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 10:09:25PM -0800, Adam Williamson wrote:
> > Meanwhile, NetworkManager is doing absolutely nothing for me, and is
> > taking up a USS of 65.3M. If we're gonna tilt at memory consumption
> > windmills, how about we take a look at that one?
> Are you sure that's right? According to htop, it only uses 3MB, here.
> (nm-applet is another 10MB).
I'm not sure it's *right*, but I'm sure it's *accurate* -- that's what I'm
seeing. (No nm-applet currently running, btw.)
On my (F13) laptop, it seems to be using only a reasonable 1.9M USS, while
nm-applet is 14.4M.
Anyway, even at 3M, that's an order of magnitude more than the amount we're
talking about with /var/{run,lock}. And while NetworkManager is fun to pick
on, I'm sure there's dozens of other places where we've consumed a meg of
memory without blinking. I've apparently got deja-dup-monitor running, for
example, even though I do my backups a different way.
--
Matthew Miller
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: Passing ownership of mingetty
Once upon a time, Paul Wouters said: > Bonus points for anaconda configuring a working agetty login if the install > console was serial. That is, run agetty using the same linespeed as the > install and add the serial device to securetty. This is handled automatically now; if the kernel console is serial, a getty is run on the console and added to securetty automatically (in recent Fedora and RHEL 6). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Tue, Nov 23, 2010 at 09:51:13PM +0100, Kevin Kofler wrote: > Well, what's unfortunate is that HAL got deprecated long before replacements > for all its parts were ready. KDE already waited for quite some time before > implementing the replacements for HAL and was heavily criticized for that > out of some circles. And STILL, the replacement isn't ready? It's been repeatedly pointed out that you still need HAL (or a workalike) if you want backlight control. The replacement isn't ready because the upstream kernel maintainer went AWOL for an extended period of time. > Surely copying&pasting HAL code into a helper which runs as root as gnome- > power-manager does isn't a long-term-viable solution! You're right! It's not! Which is why nobody has claimed it is. > Is there a hope that radeon and nouveau get fixed to support XRandR > backlight control by F15? (I don't give a darn about Catalyst/fglrx and > nvidia.) There is a hope, but it's going to have to happen at the server level rather than the driver level - otherwise we're going to leave behind various other drivers as well. Not all the world is nvidia, intel or radeon despite how much easier that'd make things. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Fatal/f13/master] Initial import of perl-Test-Fatal 0.003-1
Summary of changes: 781ff92... Initial import of perl-Test-Fatal 0.003-1 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Fatal/f14/master] Initial import of perl-Test-Fatal 0.003-1
Summary of changes: 781ff92... Initial import of perl-Test-Fatal 0.003-1 (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 09:44 AM, Genes MailLists wrote: > On 11/22/2010 04:21 AM, Hans de Goede wrote: >> Hi, >> >> On 11/22/2010 12:59 AM, Adam Williamson wrote: > > >>> It seems like what you want is actually not to have three releases at a >>> time at all but to have one and update it constantly. And I actually >>> rather suspect that would be a model that would work well for Fedora, >>> and I'd like to look into adopting it. > > I agree with the idea of a rolling release model - however I think we > need to tune it for our needs - I think of it more closely to the kernel > development model but not the same - we have a distro not a kernel. > > >(ii) Staging (or updates testing :-) * Also - seems staging may want/need a appropriate time limited freeze period for final testing before the updates get moved to stable. .. I see Ubuntu is moving this way as well http://www.theregister.co.uk/2010/11/23/darily_ubuntu_updates/ Not that we should do what they do ... :-) But this may be a more resource efficient model for fedora. I think it would be really good for the experienced here to help flush this out and come up with a solid model ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 24/11/10 01:41, Matthew Miller wrote: > On Tue, Nov 23, 2010 at 11:54:47PM +0100, Lennart Poettering wrote: >> I think the fact that we get less disks accesses (just think noatime and >> stuff for the files dropped there) is more interesting than using the >> absolute minimal amount of memory. > > Less disk access at startup, or in general somehow? Optimizing for startup > performance over general performance does not seem so good. But this is > really about elegance rather than resource usage, right? > > Currently, /var/run and /var/lock on my rawhide desktop system take up 364K. > 385K on another rawhide system. (Blocksize of 4k.) I think we can spare that > in this day and age if we get a reasonable benefit in return. > > Meanwhile, NetworkManager is doing absolutely nothing for me, and is taking > up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how > about we take a look at that one? > > (NetworkManager is awesome on my _laptop_, by the way. Wouldn't dream of > living without it.) Here is the RAM usage on my 11 day uptime F14 laptop $ sudo ps_mem.py¹ Private + Shared = RAM used Program 1.9 MiB + 252.5 KiB = 2.1 MiB NetworkManager [updated] 7.0 MiB + 1.6 MiB = 8.6 MiB nm-applet [updated] I notice both were updated so restarting gives: $ sudo ps_mem.py 1.4 MiB + 290.0 KiB = 1.7 MiB NetworkManager 2.6 MiB + 1.3 MiB = 3.9 MiB nm-applet [1] http://www.pixelbeat.org/scripts/ps_mem.py -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24.11.10 11:13, Paul Howarth (p...@city-fan.org) wrote: > > Hmm, it has been suggested that we should make it possible to create > > these dirs in the .spec files by invoking the systemd-tmpfiles tool > > directly from the scriptlets. I guess we should add a nice interface for > > that. In the meantime it should be sufficient to simply place th right > > "mkdir -p -m ..." in the scriptlet. Of course it would be desirable if > > we have a single place where the dirs to create are encoded. > > Why not create the directories in the initscript/systemd equivalent? Because it's cumbersome and you need at least three invocations to get things right, to do mkdir, chown and restorecon. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24.11.10 03:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > Imho there should be a packaging guideline to make it clear what needs > > > to be done in which cases. E.g. when to %ghost files and when not. > > > > I guess extending the guidelines with a line or two about this is a good > > idea. > > > I see you've already filed some bugs but in the future it would be best to > get the packaging guidelines worked out before you do that. Most notably > because it seems like you're going to have to now file an update to all of > those bugs due to: I don't think this will be necessary since only a small subset of services will need this treatment. I have mentioned it a couple of times, but I will do so here again: OpenSUSE and Ubuntu have been shipping their systems like this since quite some time, as do we apparently with the stateless stuff. Most software has already been fixed to properly create those subdirs on its own. That's why adding tmpfiles drop-ins will be necessary only in exceptions. > > Hmm, it has been suggested that we should make it possible to create > > these dirs in the .spec files by invoking the systemd-tmpfiles tool > > directly from the scriptlets. I guess we should add a nice interface for > > that. In the meantime it should be sufficient to simply place th right > > "mkdir -p -m ..." in the scriptlet. Of course it would be desirable if > > we have a single place where the dirs to create are encoded. > > > A question I'd have when looking over a proposed packaging guideline would > be: why %ghost the directories? Why not include the directories as normal > but add the tmpfiles.d step in addition? Well, because rpm has introduced %ghost for cases like this, and everybody else uses it for that. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 16:56, Nathanael D. Noblet (nathan...@gnat.ca) wrote: > > Imho there should be a packaging guideline to make it clear what needs > > to be done in which cases. E.g. when to %ghost files and when not. > > I'm curious, one of my packages has /var/run/dspam in the specfile and > /var/lock/subsystem/dspam used in the initscript... I added a %ghost for > the second and now I'm wondering if I even need to.. Should I revert > that change? and just %ghost /var/run/dspam ? You probably should %ghost all dirs/files beneath those two directories. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 09:48 PM, Lennart Poettering wrote:
> Heya!
>
...
> - Many .spec files currently own subdirs of /var/run. These need to be
>updated to %ghost those dirs only, so that the automatic removal of
>these files/dirs on boot doesnt cause rpm to complain. The list of packages
>which own such files/subdir you find on the aforementioned feature
>page. I will mass-file bugs against these packages later tonight,
>requesting the %ghosting of these entries. For more information on the
>%ghost directive in .spec files see this page:
>
>
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE
I think this is not needed. Files in /var/lock and /var/run are already cleaned
by
rc.sysinit during boot process hence they should be already %ghost-ed now.
rpm doesn't complain on re-created directories:
# rpm -qf /var/run/abrt/
abrt-1.1.14-1.fc15.x86_64
# rm -rf /var/run/abrt/
# rpm -qV abrt
missing /var/run/abrt
# mkdir /var/run/abrt/
# rpm -qV abrt
#
So it should be sufficient to include them in /etc/tmpfiles.d/...conf and leave
them as regular dirs in package.
This would have minimal impact to changes in .spec files (no new scriplets
needed) and also to configurations
without tmpfs on /var/{run,lock}
Petr
--
Petr Lautrbach, Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps again
Hello All! I would like to exchange reviews - here is my wish-list (all these packages are Erlang-related): * https://bugzilla.redhat.com/638909 * https://bugzilla.redhat.com/648023 * https://bugzilla.redhat.com/652585 * https://bugzilla.redhat.com/652616 * https://bugzilla.redhat.com/652648 Feel free to pick any of them and send me a link(s) to your review request(s). -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24 Nov 2010, Petr Lautrbach wrote: >> - Many .spec files currently own subdirs of /var/run. These need to be >>updated to %ghost those dirs only, so that the automatic removal of >>these files/dirs on boot doesnt cause rpm to complain. The list of >> packages >>which own such files/subdir you find on the aforementioned feature >>page. I will mass-file bugs against these packages later tonight, >>requesting the %ghosting of these entries. For more information on the >>%ghost directive in .spec files see this page: >> >> >> http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE > > I think this is not needed. Files in /var/lock and /var/run are already > cleaned by > rc.sysinit during boot process hence they should be already %ghost-ed now. This remark makes no sense? If they "already" needed ghosting, then the mass-file should be needed? It would be helpful if we got a clear signal what to do with our initscripts/spec files to minimize package changes Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 24/11/10 16:07, Paul Wouters wrote: > On Wed, 24 Nov 2010, Petr Lautrbach wrote: > >>> - Many .spec files currently own subdirs of /var/run. These need to be >>> updated to %ghost those dirs only, so that the automatic removal of >>> these files/dirs on boot doesnt cause rpm to complain. The list of >>> packages >>> which own such files/subdir you find on the aforementioned feature >>> page. I will mass-file bugs against these packages later tonight, >>> requesting the %ghosting of these entries. For more information on the >>> %ghost directive in .spec files see this page: >>> >>> >>> http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE >> >> I think this is not needed. Files in /var/lock and /var/run are already >> cleaned by >> rc.sysinit during boot process hence they should be already %ghost-ed now. > > This remark makes no sense? If they "already" needed ghosting, then the > mass-file should > be needed? Files are directories are currently treated differently. The initscripts clean out files from /var/lock and /var/run but leave directories alone. So any package containing a file in these directories should already have it marked as %ghost as it will already disappear at boot time. However, most affected packages probably have directories rather than files here, and *those* shouldn't need %ghost-ing because re-creating them using a tmpfiles.d/*.conf file should be enough to keep rpm happy. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24 Nov 2010, Paul Howarth wrote: >> This remark makes no sense? If they "already" needed ghosting, then the >> mass-file should >> be needed? > > Files are directories are currently treated differently. The initscripts > clean out files from /var/lock and /var/run but leave directories alone. > > So any package containing a file in these directories should already > have it marked as %ghost as it will already disappear at boot time. Thanks for the clarification. > However, most affected packages probably have directories rather than > files here, and *those* shouldn't need %ghost-ing because re-creating > them using a tmpfiles.d/*.conf file should be enough to keep rpm happy. Is that needed if the package init script deals with this already? (eg xl2tpd will create /var/run/xl2tpd if it does not exist) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 24/11/10 16:39, Paul Wouters wrote: > On Wed, 24 Nov 2010, Paul Howarth wrote: >> However, most affected packages probably have directories rather than >> files here, and *those* shouldn't need %ghost-ing because re-creating >> them using a tmpfiles.d/*.conf file should be enough to keep rpm happy. > > Is that needed if the package init script deals with this already? > (eg xl2tpd will create /var/run/xl2tpd if it does not exist) If the initscript already does it then that should be fine. But Lennart prefers the tmpfiles.d approach as it's less cumbersome: http://lists.fedoraproject.org/pipermail/devel/2010-November/146230.html Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/24/2010 08:00 AM, Lennart Poettering wrote: > On Tue, 23.11.10 16:56, Nathanael D. Noblet (nathan...@gnat.ca) wrote: > >>> Imho there should be a packaging guideline to make it clear what needs >>> to be done in which cases. E.g. when to %ghost files and when not. >> >> I'm curious, one of my packages has /var/run/dspam in the specfile and >> /var/lock/subsystem/dspam used in the initscript... I added a %ghost for >> the second and now I'm wondering if I even need to.. Should I revert >> that change? and just %ghost /var/run/dspam ? > > You probably should %ghost all dirs/files beneath those two directories. So... %ghost /var/run %ghost /var/run/dspam %ghost /var/lock %ghost /var/lock/subsystem %ghost /var/lock/subsystem/dspam ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary from today's FESCo meeting (2010-11-24)
Due to folks traveling for the holiday, we didn't have quorum today. === #fedora-meeting: FESCO (2010-11-24) === Meeting started by nirik at 18:30:04 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-11-24/fesco.2010-11-24-18.30.log.html Meeting summary --- * init process (nirik, 18:30:04) * ajax notting SMParrish all unable to attend today due to holidays. (nirik, 18:30:57) * LINK: http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-11-17-18.30.log.html#l-416 (nirik, 18:38:10) * No quorum due to holiday, will meet next week (nirik, 18:42:11) Meeting ended at 18:44:18 UTC People Present (lines said) --- * nirik (23) * pjones (10) * kylem (5) * zodbot (4) * SMParrish (0) * ajax (0) * notting (0) * mclasen (0) * cwickert (0) * mjg59 (0) -- 18:30:04 #startmeeting FESCO (2010-11-24) 18:30:04 Meeting started Wed Nov 24 18:30:04 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:04 #meetingname fesco 18:30:04 The meeting name has been set to 'fesco' 18:30:04 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 18:30:04 #topic init process 18:30:04 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 18:30:57 #info ajax notting SMParrish all unable to attend today due to holidays. 18:31:05 So, do we have quorum? 18:31:07 * kylem waves. 18:31:17 I'm here, I guess. 18:31:47 I'm going to go use the bathroom while we count the crickets chirping. 18:32:09 yeah, lets wait a few minutes and see if we get 2 more folks arriving. 18:33:07 ok. 18:33:53 The 3 items we had today were: updates tweaking ideas, the robotics guys wanting to know about spins, and the glibc vs flash (which I forgot to put on the agenda when I mailed it yesterday) 18:36:36 I thought we made a decision about glibc v flash last week? 18:36:52 Am I mis-remembering, or is there something else about it we need to cover? 18:37:24 I think we discussed it at the end of the last meeting perhaps, but I don't think we came to a decision.. 18:37:26 * nirik looks at logs. 18:38:10 http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-11-17-18.30.log.html#l-416 18:38:17 yeah, we didn't really vote on an outcome there. 18:39:21 oh, right, we wait-and-seed it. 18:39:22 but FWIW I agree with your proposal. 18:39:58 yeah, I stick with that same proposal. 18:40:10 oh, cwickert also mailed me that he will be unable to attend. 18:40:10 anyway, we're 10 minutes in and we don't have a quorum. 18:40:24 yeah, looks like we just regroup next week after the holiday. 18:40:28 yep. 18:40:35 bummer. 18:40:37 ok. 18:40:54 Oh, if you guys have any ideas on how I could organize the updates changes ideas, let me know. 18:41:19 perhaps I can dump them in a wiki page and we can get everyone to vote them up or down so we know what to even discuss. 18:42:00 anyhow, will regroup next week. 18:42:11 #info No quorum due to holiday, will meet next week 18:42:12 wiki is probably easiest 18:42:47 oh, and elections end on the 28th, does that mean next meeting is the new fesco? 18:43:05 I think it does. 18:43:29 no reason to introduce lame duck sessions. 18:44:05 ok. 18:44:15 ok, thanks for coming kylem and pjones. :) 18:44:18 #endmeeting signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 5:15 PM, Nicholas Miell wrote:
> On 11/23/2010 02:54 PM, Lennart Poettering wrote:
>> On Tue, 23.11.10 13:41, Nicholas Miell (nmi...@gmail.com) wrote:
>>> On 11/23/2010 12:48 PM, Lennart Poettering wrote:
Heya!
I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:
https://fedoraproject.org/wiki/Features/var-run-tmpfs
>>>
>>> Is this actually an improvement?
>>
>> See the spec page.
>
> The spec page says it'll be better, but is very vague as to why.
>
> Basically, I'm looking for a "Doing this will keep $X kilobytes
> permanently pinned in RAM (in the form of dentry and inode structs) and
> $Y bytes in RAM or swap (in the form of file data pages), of which $Z
> bytes is wasted (due to the fixed page size) and this is {worth it, not
> worth it} due to the $N millisecond improvement in boot times."
>
> i.e. an acknowledgment that somebody thought about the trade-offs and
> decided it is the right thing to do.
How about "Less un-necessary crap scribbled all over the filesystem"?
In an age of Live CD/DVD/USB, and flash-based storage devices, cheap
and free filesystem writes can no longer be taken for granted. Its
amazing how much state is spread around the filesystem. Persistent
network rules in /etc/udev/rules.d/, and dhcp client state in
/var/lib/dhclient/ are just a few examples of what has caused me
endless trouble swapping a HD between a few different systems while I
evaluate which works best as a MythTV system. I end up having to clear
the persistent net rules, the client-side lease state, AND the lease
in my router just to get a different motherboard to take the same
fixed IP address lease on eth0. (Which MythTV gets angry if it doesn't
have) State, state saved everywhere...
In an age where "Live" systems are a major use case, why are we saving
all this random state all over that necessitates complexity like
filesystem overlays (how much ram does THAT all eat on a running Live
system?) when its all just going to get tossed out anyway?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On Wed, 24 Nov 2010 11:03:41 +0100, Ralf wrote: > On 11/24/2010 10:45 AM, Matej Cepl wrote: > > Dne 24.11.2010 03:28, Ralf Corsepius napsal(a): > >> No, it's not your fault (Or at least only partially). A functional QA > >> would catch such kind of breakages. > > > > Yes, but functional QA would require more manpower than Fedora QA > > currently has. > > That's one perspective. > > Another one is: The approach having been taken is > non-feasible/impractiable/unsuiteable. True. The appropriate action now would be to move the openldap package onto a special QA list, which restricts the update acceptance criteria further, so the openldap-servers must be tested, too. Especially if the updates trigger database maintenance jobs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24.11.10 10:45, Nathanael D. Noblet (nathan...@gnat.ca) wrote: > > On 11/24/2010 08:00 AM, Lennart Poettering wrote: > > On Tue, 23.11.10 16:56, Nathanael D. Noblet (nathan...@gnat.ca) wrote: > > > >>> Imho there should be a packaging guideline to make it clear what needs > >>> to be done in which cases. E.g. when to %ghost files and when not. > >> > >> I'm curious, one of my packages has /var/run/dspam in the specfile and > >> /var/lock/subsystem/dspam used in the initscript... I added a %ghost for > >> the second and now I'm wondering if I even need to.. Should I revert > >> that change? and just %ghost /var/run/dspam ? > > > > You probably should %ghost all dirs/files beneath those two directories. > > > So... > > %ghost /var/run > %ghost /var/run/dspam > %ghost /var/lock > %ghost /var/lock/subsystem > %ghost /var/lock/subsystem/dspam No. /var/run and /var/lock and /var/lock/subsystem is not owned by you. Don't add those three to the spec file! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Urgent: today's F14 catastrophe with openldap-servers update
On 11/23/2010 06:28 PM, Ralf Corsepius wrote: > On 11/23/2010 07:36 PM, Jan Vcelak wrote: >> On Tuesday 23 November 2010 19:13:09, Panu Matilainen wrote: >>> Another related thing is that Berkeley DB which openldap uses is >>> notoriously picky about getting updated. I'm fairly certain openldap does >>> not update their bundled BDB version to prevent issues like this on minor >>> updates, and AFAICT (based on a quick lookaround at the changelogs etc) in >>> this case it was this fix to comply with our own policies (no bundled >>> libraries) that bit us when synced with rawhide version: >>> >>> * Fri Aug 27 2010 Jan Vcelak 2.4.23-1 >>> - rebase to 2.4.23 >>> - embeded db4 library removed >>> >>> - Panu - >> >> You are right. My fault. :-( > > No, it's not your fault (Or at least only partially). A functional QA > would catch such kind of breakages. > > Ralf > > > Fedora(.us) has never had what you would call a "functional QA". Efforts are underway, and have been for a while. Until in place, we rely upon humans, first line of humans we rely upon is the maintainer. Mistakes happen, and the approaches thus far are trying to provide a window of opportunity to discover such mistakes, until such time as the automated QA system can discover them for us, or at least provide hints that there might be a mistake. My original question was not an attempt to place blame, rather an attempt to discover the scenario in which this mistake made it through, so that we can use this info in further design attempts for QA. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Wed, 24.11.10 00:06, Paul Wouters (p...@xelerance.com) wrote: > > On Thu, 11 Nov 2010, Lennart Poettering wrote: > > > That way most distros would only have to install one getty implementation, > > and can use it for both serial consoles and VCs. > > Yes please. > > Bonus points for anaconda configuring a working agetty login if the install > console was serial. That is, run agetty using the same linespeed as the > install and add the serial device to securetty. systemd implicitly adds a serial getty on the console configured on the kernel cmdline with console= and also one on hvc0 if that device exists. That means simply by using console= on the kernel cmdline you should get a getty on it. We currently still use the old securetty tool to patch those terminals into /etc/securetty on demand. I have submitted a patch to pam_securetty however, to make it look for console= on the kernel cmdline internally, which when merged allows us to get rid of the tool and have this work on r/o root fine as well. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Wed, 2010-11-24 at 13:07 +0100, Ralf Corsepius wrote: > Also, it's this kind of situations, where Fedora's QA's "delays" have > shown to be counter-productive. To be clear, they are not QA's delays. The initial proposal to FESCo was by mjg, the revised proposal was by notting, and it was FESCo which voted to adopt the policy requiring karma or a 7-day delay for updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, 22 Nov 2010 16:01:49 +0100, Kevin wrote: > I think it's a big mistake to provide only second-class support for > Fn-1. The assertion that that's what the people on Fn-1 want is just > unfounded, based on a misunderstanding of why people use Fn-1. There are not enough [human] resources to update Fn-1 in any way it would be close[r] to the current release. You can observe it everywhere (even by drawing conclusions about ABRT reports) that Fn-2 is abandoned by our users months before its EOL date. Anybody who disagrees is welcome to sign up as a proventester and focus on Fn-2, particularly the base packages (ex-"Core"). Same applies to Fn-1. Where are its users? Some perform an upgrade to Fn-1 very late, because they are overly pessimistic and think the current release is not ready yet. Those are not users, who would enjoy taking a look at updates-testing. If they did, they would abandon Fn-1 and upgrade to the latest greatest, which is the [only] way forward. > > this could help, but it's not always possible to add these test cases. One > > example: imap server package - new bug that can corrupt mail folders in > > some circumstances. Maintainer updates package and sets 'type=bugfix' in > > bodhi, but not always it's possible to write down any test case. It's > > still a bug fix and it's better to be delivered sooner than wait if anyone > > out there get's his mail folders corrupted. Actual policy does not help > > proactivity. > > Right, and the big point there should be that a bug which can corrupt mail > folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY > testing requirement there is a failure. True. > >> Other concrete ideas? > > > > let maintainer decide, punish (enforce any policy) only those maintainers > > who breaks something, not all innocent group > > +1! Nothing I would back up without learning about the _details_, please. How to determine when to blame the package maintainer? What would your rule set look like? -- If a nightmare bug affects a significant number of users, it should be easier to find at least _one_ such user, who would block the update while it's in updates-testing, right? But how long to wait for that user to allocate time for the testing? What piece of the puzzle am I missing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp...@gmail.com) wrote: > > 2010/11/24 Tomasz Torcz : > > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote: > >> 2010/11/24 Lennart Poettering : > >> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: > >> > > >> >> Hi, > >> >> > >> >> I would like to help with scripts conversion. IMO the conversion > >> >> action should be coordinated. > >> >> > >> >> Comments, thoughts? > >> > > >> > I would certainly welcome any work in this direction! > >> > >> Could you look at the > >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 > >> and > >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 > >> and see if I did not do any fundamental error? > >> > >> Seems to me that these are simple enough at the beginning :) > >> > >> For both I used Type=forking - it works fine, but it seems to me that > >> Type=simple might be a better choice. > > > > For type=simple you would like "-n" switch in crond invocation. > > Ah, ok, I'll keep forking. It's generally nicer to use "simple" wherever possible, unless you have a really good reason to assume that your service might be needed to be up by something else, and that something else might want synchronize to it. Since at/cron don't really offer any live protocols to other processes I think Type=simple is a good idea here. BTW, regarding at and cron: what I was thinking of but never check ehwther it is feasible is to make cron/at autostart a soon as some job is scheduled. I.e. use .path trigger to check whether /etc/crontab and user jobs exist, and start cron only then. Similarly for at. That way we could support cron and at just fine, and wouldn't even have to run it by default. I haven't looked into this in detail however, to see if the file triggers systemd offers in .path units are already sufficient to make this work. (And /etc/cron.daily and stuff would then be managed by systemd natively, in a .timer unit) > > I suggest trimming Description, it is printed during bootup and should be > > short. > > I didn't noticed it - I guess "quiet" kernel param is also interpreted > by SystemD. Yes, systemd honours "quiet": Btw, it's written "systemd", not "SystemD". I even added a section about the spelling now to the systemd homepage ;-) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24 Nov 2010, Lennart Poettering wrote: > BTW, regarding at and cron: what I was thinking of but never check > ehwther it is feasible is to make cron/at autostart a soon as some job > is scheduled. I.e. use .path trigger to check whether /etc/crontab and > user jobs exist, and start cron only then. Similarly for at. That way we > could support cron and at just fine, and wouldn't even have to run it by > default. I haven't looked into this in detail however, to see if the > file triggers systemd offers in .path units are already sufficient to > make this work. What if no jobs are there and a non-root user adds a crontab later on? Who will start cron (as root) ? > Btw, it's written "systemd", not "SystemD". I even added a section about > the spelling now to the systemd homepage ;-) At Openswan, we never wrote OpenSWAN and we're still telling people every week to not use that. It's a lost battle :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 update issue..
Hello, My aunt has F13 installed.. I got the following from her. Is this a known bug ?? I can't make heads or tails of the error message or what to tell her to do to resolve it. ERROR with rpm_check_debug vs depsolve: perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 Please report this error at http://yum.baseurl.org/report Something worth reporting to bugzilla? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Lennart Poettering : > On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp...@gmail.com) wrote: > >> >> 2010/11/24 Tomasz Torcz : >> > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote: >> >> 2010/11/24 Lennart Poettering : >> >> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> I would like to help with scripts conversion. IMO the conversion >> >> >> action should be coordinated. >> >> >> >> >> >> Comments, thoughts? >> >> > >> >> > I would certainly welcome any work in this direction! >> >> >> >> Could you look at the >> >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864 >> >> and >> >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869 >> >> and see if I did not do any fundamental error? >> >> >> >> Seems to me that these are simple enough at the beginning :) >> >> >> >> For both I used Type=forking - it works fine, but it seems to me that >> >> Type=simple might be a better choice. >> > >> > For type=simple you would like "-n" switch in crond invocation. >> >> Ah, ok, I'll keep forking. > > It's generally nicer to use "simple" wherever possible, unless you have > a really good reason to assume that your service might be needed to be > up by something else, and that something else might want synchronize to > it. Since at/cron don't really offer any live protocols to other > processes I think Type=simple is a good idea here. Ok I checked your atd.service and crond.service and voted for them in 617320 and 617324 > > BTW, regarding at and cron: what I was thinking of but never check > ehwther it is feasible is to make cron/at autostart a soon as some job > is scheduled. I.e. use .path trigger to check whether /etc/crontab and > user jobs exist, and start cron only then. Similarly for at. That way we > could support cron and at just fine, and wouldn't even have to run it by > default. I haven't looked into this in detail however, to see if the > file triggers systemd offers in .path units are already sufficient to > make this work. IMHO good idea. It should look something like this ListenStream=/etc/cron.hourly/* ListenStream=/etc/cron.daily/* ListenStream=/etc/cron.weekly/* ListenStream=/etc/cron.monthly/* (more or less) > > (And /etc/cron.daily and stuff would then be managed by systemd > natively, in a .timer unit) > >> > I suggest trimming Description, it is printed during bootup and should be >> > short. >> >> I didn't noticed it - I guess "quiet" kernel param is also interpreted >> by SystemD. > > Yes, systemd honours "quiet": > > Btw, it's written "systemd", not "SystemD". I even added a section about > the spelling now to the systemd homepage ;-) I have not read all the documentation yet ;) > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
Once upon a time, Lennart Poettering said: > We currently still use the old securetty tool to patch those terminals > into /etc/securetty on demand. I have submitted a patch to pam_securetty > however, to make it look for console= on the kernel cmdline internally, > which when merged allows us to get rid of the tool and have this work on > r/o root fine as well. Please don't do that. Not all serial consoles are necessarily secure. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Tue, 2010-11-23 at 10:19 -0600, Bruno Wolff III wrote: > On Tue, Nov 23, 2010 at 17:18:44 +0100, > Michał Piotrowski wrote: > > W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski > > napisał: > > > We can create a list of all scripts in wiki and > > > maintainers of individual packages would indicate that they want to > > > convert scripts themselves. > > > > How can I get information about all packages that provides init scripts? > > > > When I do > > rpm -qf /etc/init.d/* > > I get only information about already installed packages. Any magic > > switch to get informations about all packages from rpm database? > > I believe rpm only knows about packages available locally. You either need > to have the packages installed or a local mirror. (You can use urls to > refer to remote packages with rpm, but that isn't likely to be workable.) > If you have a local mirror you can use the p option and name the rpms. > > Otherwise yum is probably a better choice for this, since it can use meta > data to get information. One of the yum utilities may be better than yum > itself, but I am not sure offhand. You can use: repoquery -qf '/etc/init.d/*' '/etc/rc.d/init.d/*' ...note that unlike "rpm -qf" you need both of the above paths. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Paul Wouters : > On Wed, 24 Nov 2010, Lennart Poettering wrote: > >> BTW, regarding at and cron: what I was thinking of but never check >> ehwther it is feasible is to make cron/at autostart a soon as some job >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and >> user jobs exist, and start cron only then. Similarly for at. That way we >> could support cron and at just fine, and wouldn't even have to run it by >> default. I haven't looked into this in detail however, to see if the >> file triggers systemd offers in .path units are already sufficient to >> make this work. > > What if no jobs are there and a non-root user adds a crontab later on? Who > will start cron (as root) ? I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure how systemd interprets wildcards and multiple ListenStream) > >> Btw, it's written "systemd", not "SystemD". I even added a section about >> the spelling now to the systemd homepage ;-) > > At Openswan, we never wrote OpenSWAN and we're still telling people every week > to not use that. It's a lost battle :P > > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote: > 2010/11/24 Paul Wouters : > > On Wed, 24 Nov 2010, Lennart Poettering wrote: > > > >> BTW, regarding at and cron: what I was thinking of but never check > >> ehwther it is feasible is to make cron/at autostart a soon as some job > >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and > >> user jobs exist, and start cron only then. Similarly for at. That way we > >> could support cron and at just fine, and wouldn't even have to run it by > >> default. I haven't looked into this in detail however, to see if the > >> file triggers systemd offers in .path units are already sufficient to > >> make this work. > > > > What if no jobs are there and a non-root user adds a crontab later on? Who > > will start cron (as root) ? > > I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure > how systemd interprets wildcards and multiple ListenStream) Uhm, you meant path type unit, described in systemd.path surely. Listen* directives are for sockets. > > > >> Btw, it's written "systemd", not "SystemD". I even added a section about > >> the spelling now to the systemd homepage ;-) > > > > At Openswan, we never wrote OpenSWAN and we're still telling people every > > week > > to not use that. It's a lost battle :P And Paul surely meant OpenS/WAN ;) -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 update issue..
On Wed, 24 Nov 2010 13:25:15 -0700, Nathanael wrote: > Hello, > >My aunt has F13 installed.. I got the following from her. Is this a > known bug ?? I can't make heads or tails of the error message or what to > tell her to do to resolve it. > > ERROR with rpm_check_debug vs depsolve: > perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 > perl-libs = 4:5.10.1-112.fc13 is needed by perl-4:5.10.1-112.fc13.i686 > Please report this error at http://yum.baseurl.org/report > > Something worth reporting to bugzilla? On x86_64? If so, get her to erase perl.i686 in favour of perl.x86_64. An update changed the multiarch dependencies in Perl, so there is a newer perl-libs.i686 in the x86_64 repo, but no update for the old perl.i686 in Fedora 13 release. This is multiarch breakage, which has been found and reported long ago, but won't be fixed. It's in the broken deps report, but ignore (= maintainers don't receive private mail about it anymore): http://lists.fedoraproject.org/pipermail/test/2010-November/095670.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
W dniu 24 listopada 2010 21:34 użytkownik Tomasz Torcz napisał: > On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote: >> 2010/11/24 Paul Wouters : >> > On Wed, 24 Nov 2010, Lennart Poettering wrote: >> > >> >> BTW, regarding at and cron: what I was thinking of but never check >> >> ehwther it is feasible is to make cron/at autostart a soon as some job >> >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and >> >> user jobs exist, and start cron only then. Similarly for at. That way we >> >> could support cron and at just fine, and wouldn't even have to run it by >> >> default. I haven't looked into this in detail however, to see if the >> >> file triggers systemd offers in .path units are already sufficient to >> >> make this work. >> > >> > What if no jobs are there and a non-root user adds a crontab later on? Who >> > will start cron (as root) ? >> >> I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure >> how systemd interprets wildcards and multiple ListenStream) > > Uhm, you meant path type unit, described in systemd.path surely. Listen* > directives are for sockets. Probably yes :) > > >> > >> >> Btw, it's written "systemd", not "SystemD". I even added a section about >> >> the spelling now to the systemd homepage ;-) >> > >> > At Openswan, we never wrote OpenSWAN and we're still telling people every >> > week >> > to not use that. It's a lost battle :P > > And Paul surely meant OpenS/WAN ;) > > -- > Tomasz Torcz "God, root, what's the difference?" > xmpp: zdzich...@chrome.pl "God is more forgiving." > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Help]/proc/acpi/fan empty and CPUFan never Stop
Hello. I Have a HP g42 series notebook, in Fedora 14 x64 the CPU Fan never stop. In notebook bios have a option: FAN AWAYS On But the Fan Never stop, on Fedora. The directory /proc/acpi/fan is empty, the chipset driver do not discovery my cpufan driver? I Running Fedora 14 x64 on HP G42 250Br ( Intel 5 Series/3400Series Chipset Family ) on Core i3 330M; Anyone can help me to solve this problem? Thanks! -- Atenciosamente, João Gomes da Silva Neto PeixeWeb - Marketing para a Internet | www.peixeweb.com.br +55 85 88664963 Skype: joao.gsneto Gtalk: joao.gsneto[at]gmail.com @joao_neto | http://www.joaoneto.blog.br -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Wed, 24.11.10 14:29, Chris Adams (cmad...@hiwaay.net) wrote: > > Once upon a time, Lennart Poettering said: > > We currently still use the old securetty tool to patch those terminals > > into /etc/securetty on demand. I have submitted a patch to pam_securetty > > however, to make it look for console= on the kernel cmdline internally, > > which when merged allows us to get rid of the tool and have this work on > > r/o root fine as well. > > Please don't do that. Not all serial consoles are necessarily secure. This behaviour has been the default sicne quite some time. I am not the one who's going to change that. As soon as the patch i posted is merged into pam-securetty you can easily disable this behaviour by passing noconsole on the PAM config line. I think pam_securetty is mostly snake oil anyway. An admin should be smart enough to choose a safe root password instead of relying on this kind of snake oil. Note that with that pam_securetty patch in place thins become safe anyway, since booting with console on ttyS0 once won't change /etc/securetty for all the future, but only for this one boot. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 15:22, Paul Wouters (p...@xelerance.com) wrote: > > On Wed, 24 Nov 2010, Lennart Poettering wrote: > > > BTW, regarding at and cron: what I was thinking of but never check > > ehwther it is feasible is to make cron/at autostart a soon as some job > > is scheduled. I.e. use .path trigger to check whether /etc/crontab and > > user jobs exist, and start cron only then. Similarly for at. That way we > > could support cron and at just fine, and wouldn't even have to run it by > > default. I haven't looked into this in detail however, to see if the > > file triggers systemd offers in .path units are already sufficient to > > make this work. > > What if no jobs are there and a non-root user adds a crontab later on? Who > will start cron (as root) ? That's the point of the .path unit. i.e. you can list dirs to watch. If a user then drop a file into one of those dirs cron gets automatically started. Basically, in your .path unit you'd write something like this: [Path] PathExists=/etc/crontab DirectoryNotEmpty=/etc/cron.d DirectoryNotEmpty=/var/spool/cron And the moment where /etc/crontab starts to exist, or somebody drops a file into /etc/cron.d or /var/spool/cron crond would be automatically started. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 21:30, Michał Piotrowski (mkkp...@gmail.com) wrote: > > 2010/11/24 Paul Wouters : > > On Wed, 24 Nov 2010, Lennart Poettering wrote: > > > >> BTW, regarding at and cron: what I was thinking of but never check > >> ehwther it is feasible is to make cron/at autostart a soon as some job > >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and > >> user jobs exist, and start cron only then. Similarly for at. That way we > >> could support cron and at just fine, and wouldn't even have to run it by > >> default. I haven't looked into this in detail however, to see if the > >> file triggers systemd offers in .path units are already sufficient to > >> make this work. > > > > What if no jobs are there and a non-root user adds a crontab later on? Who > > will start cron (as root) ? > > I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure > how systemd interprets wildcards and multiple ListenStream) Almost. This is a .path unit, the syntax is: DirectoryNotEmpty=/var/spool/cron Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Someone uses cherokee web server? Please check this service https://bugzilla.redhat.com/show_bug.cgi?id=657085 Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Sub-WrapPackages] Remove perl(lib) from the Provides set. (#657015)
commit 14a4e7818e99173c8577b8f05f66ee8127f406fc
Author: Emmanuel Seyman
Date: Wed Nov 24 22:25:06 2010 +0100
Remove perl(lib) from the Provides set. (#657015)
perl-Sub-WrapPackages.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Sub-WrapPackages.spec b/perl-Sub-WrapPackages.spec
index 8192f96..b2dcfd3 100644
--- a/perl-Sub-WrapPackages.spec
+++ b/perl-Sub-WrapPackages.spec
@@ -1,6 +1,6 @@
Name: perl-Sub-WrapPackages
Version:2.0
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Add wrappers around all the subroutines in packages
License:GPL+ or Artistic
Group: Development/Libraries
@@ -16,6 +16,7 @@ BuildRequires: perl(Devel::Caller::IgnoreNamespaces)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%{?perl_default_filter}
+%filter_from_provides /perl(lib)/d;
%description
This is mostly a wrapper around Damian Conway's Hook::LexWrap module. This
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Nov 24 2010 Emmanuel Seyman - 2.0-1
+- Remove perl(lib) from the Provides set. (#657015)
+
* Thu May 06 2010 Marcela Maslanova - 2.0-2
- Mass rebuild with perl-5.12.0
--
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: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp...@gmail.com) wrote: > > Someone uses cherokee web server? Please check this service > https://bugzilla.redhat.com/show_bug.cgi?id=657085 Looks good (haven't tested it though, and don't really know cherokee). In this case however, I think it would actually make sense to use Type=forking and pass "-d". Why? Because another service might want to access cherokee over HTTP or so and if you don't use Type=forking then that other service is using After=cherokee.service it might access it before the server is actually up. BTW, is the -C /etc/cherokee/cherokee.conf really necessary? Independently of systemd i Actually believe we should simplify the command lines as much as possible, and if /etc/cherokee/cherokee.conf is the default config file anyway I think it would be nice to drop that argument. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
I wanted to convert httpd, and I saw that it's already converted and it uses socket httpd.socket ListenStream=80 What if administrator want to change port to other? Let's say, that I've got configured three servers: 80 - cherokee 81 - apache 82 - nginx In this enviroment httpd.socket should trigger cherokee not apache. Parameter to ListenStream should be taken from server config somehow. Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf | cut -d " " -f 2 in ListenStream? Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, Nov 24, 2010 at 03:58:26PM +0100, Lennart Poettering wrote: > On Wed, 24.11.10 03:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > > > Imho there should be a packaging guideline to make it clear what needs > > > > to be done in which cases. E.g. when to %ghost files and when not. > > > > > > I guess extending the guidelines with a line or two about this is a good > > > idea. > > > > > I see you've already filed some bugs but in the future it would be best to > > get the packaging guidelines worked out before you do that. Most notably > > because it seems like you're going to have to now file an update to all of > > those bugs due to: > > I don't think this will be necessary since only a small subset of > services will need this treatment. > > I have mentioned it a couple of times, but I will do so here again: > OpenSUSE and Ubuntu have been shipping their systems like this since > quite some time, as do we apparently with the stateless stuff. Most > software has already been fixed to properly create those subdirs on its > own. That's why adding tmpfiles drop-ins will be necessary only in > exceptions. > Except that you're arguing over whether we should do this at all and I'm just saying that your implementation is flawed. > > > Hmm, it has been suggested that we should make it possible to create > > > these dirs in the .spec files by invoking the systemd-tmpfiles tool > > > directly from the scriptlets. I guess we should add a nice interface for > > > that. In the meantime it should be sufficient to simply place th right > > > "mkdir -p -m ..." in the scriptlet. Of course it would be desirable if > > > we have a single place where the dirs to create are encoded. > > > > > A question I'd have when looking over a proposed packaging guideline would > > be: why %ghost the directories? Why not include the directories as normal > > but add the tmpfiles.d step in addition? > > Well, because rpm has introduced %ghost for cases like this, and everybody > else uses it for that. > %ghost is definitely suitable for files but I'm not so sure it's suitable for directories. It certainly leads to more complex spec files to use %ghost on the directory for really no gain that I'm aware of. %ghost does %two things with a file: It tells rpm that it doesn't need to install the file. It tells rpm to not track the contents of the file while still tracking the permissions and ownerhsip of the file. With directories that are created by systemd at boottime, we still have to create the directories at install time somehow using so using rpm's standard method of file installation seems less complex then tesching everyone to put mkdir into their spec files. With directories, we do not have content that changes, only permissions and ownership so that reason for using %ghost also doesn't seem to make a difference. SUSe may have realized that too as they stopped %ghosting the /var/run/httpd directory (but I can't see the bug that is referenced there ( 498490 ) so I don't know for sure. OTOH, they didn't make the change across their packageset as avahi still has the directory %ghosted. -Toshio pgpSYLwfDcMcx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On Wednesday 24 November 2010, Jesse Keating wrote: > ccache - my build can be tagged I'll most likely push an update to ccache soon so no need to tag this one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp...@gmail.com) wrote: > I wanted to convert httpd, and I saw that it's already converted and > it uses socket > > httpd.socket > ListenStream=80 Where do I find this? Its not in the pkg git tree nor in bugzilla? > What if administrator want to change port to other? Let's say, that > I've got configured three servers: > 80 - cherokee > 81 - apache > 82 - nginx The recommended way to modify the default configuration is to copy /lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and then edit it there. That way you can easily drop back to the default setup by deleting this file again. Files in /etc/systemd/system take precedence over those equally named in /lib/systemd/system. > In this enviroment httpd.socket should trigger cherokee not apache. > Parameter to ListenStream should be taken from server config somehow. > Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf | > cut -d " " -f 2 in ListenStream? No, we don't support that really. And I am not convinced we should. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Lennart Poettering : > On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp...@gmail.com) wrote: > >> >> Someone uses cherokee web server? Please check this service >> https://bugzilla.redhat.com/show_bug.cgi?id=657085 > > Looks good (haven't tested it though, and don't really know > cherokee). In this case however, I think it would actually make sense to > use Type=forking and pass "-d". Why? Because another service might want > to access cherokee over HTTP or so and if you don't use Type=forking > then that other service is using After=cherokee.service it might access > it before the server is actually up. Ok, I changed it to forking (I tried it before and it didn't worked after reboot - I think that the httpd.socket had something to do with that) > > BTW, is the -C /etc/cherokee/cherokee.conf really necessary? > Independently of systemd i Actually believe we should simplify the > command lines as much as possible, and if /etc/cherokee/cherokee.conf is > the default config file anyway I think it would be nice to drop that > argument. Ok, agree. I created second version without "-C /path/to/config" - let maintainer choose the right version in his opinion. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/24 Lennart Poettering : > On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp...@gmail.com) wrote: > >> I wanted to convert httpd, and I saw that it's already converted and >> it uses socket >> >> httpd.socket >> ListenStream=80 > > Where do I find this? Its not in the pkg git tree nor in bugzilla? O LOL sorry for the noise :) I created it six days ego :) > >> What if administrator want to change port to other? Let's say, that >> I've got configured three servers: >> 80 - cherokee >> 81 - apache >> 82 - nginx > > The recommended way to modify the default configuration is to copy > /lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and > then edit it there. That way you can easily drop back to the default > setup by deleting this file again. Files in /etc/systemd/system take > precedence over those equally named in /lib/systemd/system. Ok > >> In this enviroment httpd.socket should trigger cherokee not apache. >> Parameter to ListenStream should be taken from server config somehow. >> Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf | >> cut -d " " -f 2 in ListenStream? > > No, we don't support that really. And I am not convinced we should. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Sub-WrapPackages/f13/master] Remove perl(lib) from the Provides set (#657015).
commit 9694106fbc075cd020f6f0acc11510a1c7b57d36
Author: Emmanuel Seyman
Date: Wed Nov 24 22:59:02 2010 +0100
Remove perl(lib) from the Provides set (#657015).
perl-Sub-WrapPackages.spec |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl-Sub-WrapPackages.spec b/perl-Sub-WrapPackages.spec
index bec5337..429ea7c 100644
--- a/perl-Sub-WrapPackages.spec
+++ b/perl-Sub-WrapPackages.spec
@@ -13,6 +13,8 @@ BuildRequires: perl(Hook::LexWrap)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+%filter_from_provides /perl(lib)/d;
+
%description
This is mostly a wrapper around Damian Conway's Hook::LexWrap module. This
module allows you to wrap function calls and exits with functions of your
@@ -48,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Nov 24 2010 Emmanuel Seyman - 1.31-2
+- Remove perl(lib) from the Provides set (#657015).
+
* Wed Feb 10 2010 Emmanuel Seyman - 1.31-1
- Update to 1.31
--
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: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 24.11.10 21:25, Michał Piotrowski (mkkp...@gmail.com) wrote:
> > BTW, regarding at and cron: what I was thinking of but never check
> > ehwther it is feasible is to make cron/at autostart a soon as some job
> > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
> > user jobs exist, and start cron only then. Similarly for at. That way we
> > could support cron and at just fine, and wouldn't even have to run it by
> > default. I haven't looked into this in detail however, to see if the
> > file triggers systemd offers in .path units are already sufficient to
> > make this work.
>
> IMHO good idea. It should look something like this
> ListenStream=/etc/cron.hourly/*
> ListenStream=/etc/cron.daily/*
> ListenStream=/etc/cron.weekly/*
> ListenStream=/etc/cron.monthly/*
> (more or less)
(As mentioned elsewhere, DirectoryNotEmpty= is the right option here)
I think /etc/cron.{hourly, daily, weelkly, monthtly}/ should be handled
by a systemd timer, instead of a cron job in future. After all they
aren't handle by cron really either these days, but indirectly via run-parts.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Michael Schwendt wrote: > There are not enough [human] resources to update Fn-1 in any way it would > be close[r] to the current release. You can observe it everywhere (even by > drawing conclusions about ABRT reports) that Fn-2 is abandoned by our > users months before its EOL date. Uh, we'd have the resources to push KDE upgrades to Fn-1 just fine (see 4.2 for F9, 4.3 for F10 and 4.4 for F11). It's not that much work to build the stuff we're building for Fn anyway also for Fn-1. It's the new unnecessarily paranoid QA we don't seem to have the resources for. We already test our KDE upgrades very hard. But most of that testing will be on Fn (and Fn+1). The packages we push to Fn-1 would be the exact same ones, just rebuilt! > Nothing I would back up without learning about the _details_, please. > How to determine when to blame the package maintainer? What would your > rule set look like? Common sense! But that seems to be lacking in Fedora circles lately. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Sub-WrapPackages/f13/master] Bump the release tag
commit a59a03ea62a0b129098f94e6300d2885766d5bcd
Author: Emmanuel Seyman
Date: Wed Nov 24 23:05:17 2010 +0100
Bump the release tag
perl-Sub-WrapPackages.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Sub-WrapPackages.spec b/perl-Sub-WrapPackages.spec
index 429ea7c..f9ac5e3 100644
--- a/perl-Sub-WrapPackages.spec
+++ b/perl-Sub-WrapPackages.spec
@@ -1,6 +1,6 @@
Name: perl-Sub-WrapPackages
Version:1.31
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Add wrappers around all the subroutines in packages
License:GPL+ or Artistic
Group: Development/Libraries
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 2010-11-24 at 13:39 -0800, Toshio Kuratomi wrote: > On Wed, Nov 24, 2010 at 03:58:26PM +0100, Lennart Poettering wrote: > > On Wed, 24.11.10 03:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > > > A question I'd have when looking over a proposed packaging guideline would > > > be: why %ghost the directories? Why not include the directories as normal > > > but add the tmpfiles.d step in addition? > > > > Well, because rpm has introduced %ghost for cases like this, and everybody > > else uses it for that. > > > %ghost is definitely suitable for files but I'm not so sure it's suitable > for directories. It certainly leads to more complex spec files to use > %ghost on the directory for really no gain that I'm aware of. %ghost does > %two things with a file: It tells rpm that it doesn't need to install the > file. It tells rpm to not track the contents of the file while still > tracking the permissions and ownerhsip of the file. It's also worth noting that %ghost tells rpm -V that it's ok if the file/dir. is missing (or changes type) ... which we _don't_ want to happen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Help]/proc/acpi/fan empty and CPUFan never Stop
2010/11/24 João Neto > I Running Fedora 14 x64 on HP G42 250Br ( Intel 5 Series/3400Series Chipset > Family ) on Core i3 330M; > After boot, the CPU temp is 58º C, after 1 or 2 minutes, without any operation, the CPU tem is 78º C, this is a kernel bug? A Have a friend with some problem with other Linux ou core i3 notebook. -- Atenciosamente, João Gomes da Silva Neto PeixeWeb - Marketing para a Internet | www.peixeweb.com.br +55 85 88664963 Skype: joao.gsneto Gtalk: joao.gsneto[at]gmail.com @joao_neto | http://www.joaoneto.blog.br -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 03:04:30PM -0800, Mike Fedyk wrote: > This still builds a reactive system instead of a preventative system. > An only reactive system will not help prevent bad updates from getting > out in the first place. > > That said, adding a reactive component to a preventative system would > be a good thing. If a maintainer releases one package that puts > regressions into the stable updates repo, then the minimum karma > doubles on all of their packages doubles for 2 months or something > like that. > > So feel free to push directly to stable as often as you want, but once > you introduce one regression, you have to satisfy 10 karma on every > package you update. The second time, you have to satisfy 20 karma on > every package you update and so on. Fedora could as well just stop published updates at all, then no bad updates will hit stable ever. > Simply because we can't trust that maintainer anymore. How is it the fault of the maintainer when ten testers certified that the update is ok even when it was not? > Really, allowing regressions to make it to stable is so costly simply > because it has to be fixed several magnitudes more times than if it is > caught by people actually testing packages before they're released to > the masses. In general I have to more often experience the same bugs that others already found because of old package than I have to fix regressions. At least during a release, when I have to update to a new Fedora release, bugs tend to come back. But to prevent this I would like to have automatic tested instead of lots of error prone manual testing. Regards Till pgpZoosXHBRO0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
HEADS-UP: openbabel ABI version bump in rawhide
Dear fellow maintainers, I'm building a new version of openbabel in rawhide and it comes with an ABI version bump. The affected packages needing a rebuild are: avogadro ghemical gnome-chemistry-utils kdeedu xdrawchem Please don't hesitate to contact me if you encounter any problems. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New gtk-vnc slower?
I have a collection of virtual machines that I use to test cross-platform compatibility of some code I'm developing. Today, the virtual machine I was working on kept getting slower and slower whenever a window refresh was needed. It got to the point that refreshing a terminal window was taking nearly half a second per line. My eyes could easily track the refresh going on. Moving a window was impossible, as I could see the entire window being redrawn, pixel by pixel, and it would just keep going long after I had released the mouse. Keys were repeating right and left, probably because of a sequence like . I shut everything down, logged out, and even rebooted, to see if it was some weird behavior caused by a recent update that had only partly taken effect. When I started my VM back up, it was very snappy. But then, over time, it got a little slower and a little slower, until eventually I was back to watching refreshes happen line by line again. This never happened before today. I looked through the recent updates my machine has received. All I can see that might be relevant was an update to gtk-vnc-0.4.2-1.fc14.x86_64. The machine in question is a quad-core Intel with 8GB of RAM and an Nvidia video card of some kind. (Sorry, should have checked which one before leaving work.) The host is fine; it's just the virtual machines I open with virt-manager that are affected. I tried several, and they're all behaving like this today, which argues for the problem being on the host side. Is anybody else seeing this? Is there any other component besides gtk-vnc that I should examine as a possible source of the slowdown? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/22/2010 01:23 PM, Genes MailLists wrote: > On 11/22/2010 09:44 AM, Genes MailLists wrote: > > ... rolling releases ... Interesting website - may be useful in thinking about the release cycle ... or not :-) http://oswatershed.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
On 11/25/2010 01:13 AM, Genes MailLists wrote: > On 11/22/2010 01:23 PM, Genes MailLists wrote: >> On 11/22/2010 09:44 AM, Genes MailLists wrote: >> >> ... rolling releases ... > > > > Interesting website - may be useful in thinking about the release > cycle ... or not :-) > > http://oswatershed.org/ Hmm some interesting data there and some looks wrong to me: I see openssh at 5.5p1 not 5.0p1. but some like apache ours is lagging by quite a bit ... Current (14) Package Version RevisionUpstream VersionNumber NewerLag NetworkManager 0.8.1 0.8.2 4 8w alsa-utils 1.0.23 1.0.23 0 ✔ cups1.4.4 1.4.5 1 1w emacs 2 3.2 23.20 ✔ firefox 4.0 4.0b7 14 21w gcc 4.5.1 4.5.1 0 ✔ ghostscript 9.009.000 ✔ gimp2.6.11 2.7.1 0 ✔ glibc 2.12.90 2.12.1 0 ✔ gnome-desktop 2.32.0 2.91.2 4 7w gnupg 2.0.16 2.0.16 0 ✔ httpd 2.2.17 2.3.6 1 22w kdebase 4.5.3 4.5.77svn11987041 5d linux 2.6.36 2.6.37-rc3 4 3w openssh 5.0p1 5.6 6 122w pidgin 2.7.5 2.7.7 2 2d postgresql 8.4.5 9.0.1 2 7w python 3.2 3.2a4 4 16w ruby1.8.7.302 1.9.2-p01 14w xorg-server 1.9.1 1.9.2.901 2 3w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: > On Wed, 24.11.10 15:22, Paul Wouters (p...@xelerance.com) wrote: > > > > > On Wed, 24 Nov 2010, Lennart Poettering wrote: > > > > > BTW, regarding at and cron: what I was thinking of but never check > > > ehwther it is feasible is to make cron/at autostart a soon as some job > > > is scheduled. I.e. use .path trigger to check whether /etc/crontab and > > > user jobs exist, and start cron only then. Similarly for at. That way we > > > could support cron and at just fine, and wouldn't even have to run it by > > > default. I haven't looked into this in detail however, to see if the > > > file triggers systemd offers in .path units are already sufficient to > > > make this work. > > > > What if no jobs are there and a non-root user adds a crontab later on? Who > > will start cron (as root) ? > > That's the point of the .path unit. i.e. you can list dirs to watch. If > a user then drop a file into one of those dirs cron gets automatically > started. > > Basically, in your .path unit you'd write something like this: > > [Path] > PathExists=/etc/crontab > DirectoryNotEmpty=/etc/cron.d > DirectoryNotEmpty=/var/spool/cron > > And the moment where /etc/crontab starts to exist, or somebody drops a > file into /etc/cron.d or /var/spool/cron crond would be automatically > started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Help]/proc/acpi/fan empty and CPUFan never Stop
On Wed, 24 Nov 2010 19:23:31 -0300 João Neto wrote: > 2010/11/24 João Neto > > > I Running Fedora 14 x64 on HP G42 250Br ( Intel 5 Series/3400Series > > Chipset Family ) on Core i3 330M; > > > > After boot, the CPU temp is 58º C, after 1 or 2 minutes, without any > operation, the CPU tem is 78º C, this is a kernel bug? > A Have a friend with some problem with other Linux ou core i3 > notebook. > Nice, I have similar problems on a touchsmart tx2 (AMD Turion 64 X2 RM-77 2.3GHz). Don't know if it's related to fc14, because currently I use an older notebook again, but since you have a similar problem, it seems to... Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
