date:20101124

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.

 snip
 d /var/run/screens 1777 root root 10d
 d /var/run/uscreens 0755 root root 10d12h
 /snip

 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

2010-11-24 Thread Radek Vokál

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 rvo...@redhat.com
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

2010-11-24 Thread Rawhide Report

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)

Re: The new Update Acceptance Criteria are broken

2010-11-24 Thread Ralf Corsepius

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

2010-11-24 Thread Matej Cepl

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

2010-11-24 Thread Roberto Ragusa

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 mzerq...@0pointer.de:
 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

2010-11-24 Thread Tomasz Torcz

On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
  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)

2010-11-24 Thread Steven Parrish

On Tue, Nov 23, 2010 at 8:37 PM, Bill Nottingham nott...@redhat.com 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

2010-11-24 Thread Marcela Mašláňová

On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 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 to...@pipebreaker.pl:
 On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
  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á mmasl...@redhat.com:
 On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 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

2010-11-24 Thread Pádraig Brady

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

2010-11-24 Thread Daniel J Walsh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/23/2010 08:54 PM, Ben Boeckel wrote:
 Jan Vcelak jvce...@redhat.com 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

2010-11-24 Thread Matthew Miller

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 mat...@mattdm.org
Senior Systems Architect -- Instructional  Research Computing Services
Harvard School of Engineering  Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Passing ownership of mingetty

2010-11-24 Thread Chris Adams

Once upon a time, Paul Wouters p...@xelerance.com 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 cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 15, new and exciting plans

2010-11-24 Thread Matthew Garrett

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 copyingpasting 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))

2010-11-24 Thread Genes MailLists

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

2010-11-24 Thread Pádraig Brady

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

2010-11-24 Thread Petr Lautrbach

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

2010-11-24 Thread Peter Lemenkov

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

2010-11-24 Thread Paul Wouters

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

2010-11-24 Thread Paul Wouters

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

2010-11-24 Thread Nathanael D. Noblet

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)

2010-11-24 Thread Kevin Fenzi

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 nirik #startmeeting FESCO (2010-11-24)
18:30:04 zodbot 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 zodbot Useful Commands: #action #agreed #halp #info #idea #link
#topic.
18:30:04 nirik #meetingname fesco
18:30:04 zodbot The meeting name has been set to 'fesco'
18:30:04 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones
cwickert mjg59
18:30:04 nirik #topic init process
18:30:04 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59
nirik notting pjones
18:30:57 nirik #info ajax notting SMParrish all unable to attend today due to
holidays.
18:31:05 nirik So, do we have quorum?
18:31:07 * kylem waves.
18:31:17 pjones I'm here, I guess.
18:31:47 pjones I'm going to go use the bathroom while we count the crickets
chirping.
18:32:09 nirik yeah, lets wait a few minutes and see if we get 2 more folks
arriving.
18:33:07 kylem ok.
18:33:53 nirik 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 pjones I thought we made a decision about glibc v flash last week?
18:36:52 pjones Am I mis-remembering, or is there something else about it we
need to cover?
18:37:24 nirik 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 nirik
http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-11-17-18.30.log.html#l-416
18:38:17 nirik yeah, we didn't really vote on an outcome there.
18:39:21 pjones oh, right, we wait-and-seed it.
18:39:22 nirik but FWIW I agree with your proposal.
18:39:58 pjones yeah, I stick with that same proposal.
18:40:10 nirik oh, cwickert also mailed me that he will be unable to attend.
18:40:10 pjones anyway, we're 10 minutes in and we don't have a quorum.
18:40:24 nirik yeah, looks like we just regroup next week after the holiday.
18:40:28 pjones yep.
18:40:35 kylem bummer.
18:40:37 kylem ok.
18:40:54 nirik Oh, if you guys have any ideas on how I could organize the
updates changes ideas, let me know.
18:41:19 nirik 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 nirik anyhow, will regroup next week.
18:42:11 nirik #info No quorum due to holiday, will meet next week
18:42:12 kylem wiki is probably easiest
18:42:47 nirik oh, and elections end on the 28th, does that mean next meeting
is the new fesco?
18:43:05 pjones I think it does.
18:43:29 pjones no reason to introduce lame duck sessions.
18:44:05 nirik ok.
18:44:15 nirik ok, thanks for coming kylem and pjones. :)
18:44:18 nirik #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

2010-11-24 Thread Callum Lerwick

On Tue, Nov 23, 2010 at 5:15 PM, Nicholas Miell nmi...@gmail.com 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

2010-11-24 Thread Michael Schwendt

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

2010-11-24 Thread Jesse Keating

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 Vcelakjvce...@redhat.com  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

2010-11-24 Thread Adam Williamson

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: 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 to...@pipebreaker.pl:
  On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
  2010/11/24 Lennart Poettering mzerq...@0pointer.de:
   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

2010-11-24 Thread 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) ?

 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..

2010-11-24 Thread Nathanael D. Noblet

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 mzerq...@0pointer.de:
 On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp...@gmail.com) wrote:


 2010/11/24 Tomasz Torcz to...@pipebreaker.pl:
  On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
  2010/11/24 Lennart Poettering mzerq...@0pointer.de:
   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

2010-11-24 Thread Chris Adams

Once upon a time, Lennart Poettering mzerq...@0pointer.de 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 cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

2010-11-24 Thread James Antill

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 mkkp...@gmail.com wrote:
  W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
  mkkp...@gmail.com 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 p...@xelerance.com:
 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

2010-11-24 Thread Tomasz Torcz

On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
 2010/11/24 Paul Wouters p...@xelerance.com:
  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..

2010-11-24 Thread Michael Schwendt

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
to...@pipebreaker.pl napisał:
 On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
 2010/11/24 Paul Wouters p...@xelerance.com:
  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

2010-11-24 Thread João Neto

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 Disabled

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 mzerq...@0pointer.de 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 p...@xelerance.com:
  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 emmanuel.sey...@club-internet.fr
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 emmanuel.sey...@club-internet.fr - 2.0-1
+- Remove perl(lib) from the Provides set. (#657015)
+
 * Thu May 06 2010 Marcela Maslanova mmasl...@redhat.com - 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

2010-11-24 Thread Ville Skyttä

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 mzerq...@0pointer.de:
 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 mzerq...@0pointer.de:
 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 emmanuel.sey...@club-internet.fr
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 emmanuel.sey...@club-internet.fr - 1.31-2
+- Remove perl(lib) from the Provides set (#657015).
+
 * Wed Feb 10 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 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

2010-11-24 Thread Kevin Kofler

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 emmanuel.sey...@club-internet.fr
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

2010-11-24 Thread James Antill

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 Thread João Neto

2010/11/24 João Neto joao.gsn...@gmail.com

 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

2010-11-24 Thread Till Maas

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

2010-11-24 Thread Dominik 'Rathann' Mierzejewski

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?

2010-11-24 Thread Jerry James

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 KeyDown, refresh action that takes a really long time,
KeyUp.

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))

2010-11-24 Thread Genes MailLists

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))

2010-11-24 Thread Genes MailLists

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

2010-11-24 Thread Tomas Mraz

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

2010-11-24 Thread Thomas Spura

On Wed, 24 Nov 2010 19:23:31 -0300
João Neto wrote:

 2010/11/24 João Neto joao.gsn...@gmail.com
 
  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

[Bug 657015] New: perl-Sub-WrapPackages should not provide local override perl(lib)

2010-11-24 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-Sub-WrapPackages should not provide local override perl(lib)

https://bugzilla.redhat.com/show_bug.cgi?id=657015

   Summary: perl-Sub-WrapPackages should not provide local
override perl(lib)
   Product: Fedora
   Version: 14
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: medium
  Priority: low
 Component: perl-Sub-WrapPackages
AssignedTo: emmanuel.sey...@club-internet.fr
ReportedBy: ppi...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: emmanuel.sey...@club-internet.fr,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
Target Release: ---


$ repoquery --repoid=dist-f15 --whatprovides 'perl(lib)'
perl-Sub-WrapPackages-0:2.0-2.fc14.noarch
perl-4:5.12.2-143.fc15.x86_64

$ perldoc lib/Sub/WrapPackages.pm

   Deferred wrapping of subs in packages that aren't yet loaded works
   via a subroutine inserted in @INC.  This means that if you mess
   around with @INC, eg by inserting a directoy at the beginning of
   the path, the magic might not get a chance to run.  If you use
   lib to mess with @INC though, it should work, as I've over-ridden
   lib's import() method.  That said, code this funky has no right to
   work.  Use with caution!

perl-Sub-WrapPackages Provides set clashes with perl(lib) which is currently in
perl package, however it can be masked by standalone dual-live packge perl-lib
in the future (http://search.cpan.org/~smueller/lib/).

Please filter perl(lib) out of Provides set in this package.

This bug is observed in F-14 and F-15.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sub-WrapPackages/f14/master] Remove perl(lib) from the Provides set. (#657015)