Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 11:58 PM, Adam Williamson wrote:
In the interests of general public enlightenment, it would've been nice
if you'd answered KK's question what am I missing, i.e., where's the
magic bit which makes llvmpipe the default? Knowledge is always a good
thing :)
The specfile contains this stanza, after it has built OSMesa:
# now build the rest of mesa
%configure %{common_flags} \
--disable-glw \
--disable-glut \
--disable-gl-osmesa \
--with-driver=dri \
--with-dri-driverdir=%{_libdir}/dri \
--with-state-trackers=dri,glx \
--enable-egl \
--enable-gles1 \
--enable-gles2 \
--disable-gallium-intel \
--disable-gallium-svga \
--disable-gallium-egl \
%if %{with_hardware}
--enable-gallium-llvm \
--enable-gallium-radeon \
--enable-gallium-r600 \
--enable-gallium-nouveau \
%else
--disable-gallium-llvm \
--disable-gallium-radeon \
--disable-gallium-r600 \
--disable-gallium-nouveau \
%endif
%{?dri_drivers}
The --enable-gallium-llvm bit, in particular, is key. There's some
small magic later where it renames swrastg_dri.so to be swrast_dri.so
because that's the name the X server and libGL are expecting, and that's
not perfect yet in that the debuginfo search gets a little confused, but
in the main I've tried to be pretty clear in the operation of the Mesa
spec, despite the utter malignancy of the Mesa buildsystem (any of them,
take your pick, there's like five now). If I've failed in any way to
document sufficiently our work in the specfile, please, do let me know.
But - as an aside - you're right. I was a little irked at being asked
whether I'd actually done the thing I'd said I'd done, had tested that
I'd done, had documented that I'd done, had claimed in public that I'd
done, and had been doubted of without any evidence of the inquisitor
having made even cursory investigation into the matter. It was wrong of
me to assume that someone reading the spec would look for the string
/llvm/i when looking for how to enable the LLVM support in Mesa, to
assume that someone would read the spec to learn how the package was
built, or to assume that someone would try to test a software GL path
like Xvfb or vesa to see if I was in fact telling the truth before
doubting my honesty. I was unnecessarily short in my reply, and for
that, I apologize. In the future I'll be less succinct.
(No, I won't.)
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Andreas Schwab sch...@redhat.com: Michał Piotrowski mkkp...@gmail.com writes: After turning system on I noticed that repo is totally broken. How do you define totally broken? All files in repo looks like added to commit, but not commited. # # Initial commit # # Changes to be committed: # (use git rm --cached file... to unstage) # list of over 5000 files to commit... Also git log says fatal: bad default revision 'HEAD' Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski mkkp...@gmail.com writes: Also git log says fatal: bad default revision 'HEAD' Looks like the only issue is that .git/refs/heads/master has been lost. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 10:29 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: Also git log says fatal: bad default revision 'HEAD' Looks like the only issue is that .git/refs/heads/master has been lost. Indeed, the file is empty. But I don't have this file in the repo that I restored from the backup. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski mkkp...@gmail.com writes: But I don't have this file in the repo that I restored from the backup. You do, in .git/packed-refs. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 10:42 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: But I don't have this file in the repo that I restored from the backup. You do, in .git/packed-refs. You're right. But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski mkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Hi,
I have similar question (sorry for stealing this thread). I have package
that has 3 services (they somehow depend on each other). Based on
configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
handled by init script, but I don't know how to do it in systemd service
file.
AFAIK:
a)
EnvironmentFile=...
ExecStart=[ -n $DRIVER ] /start/driver/...
ExecStart=[ -n $BACKEND ] /start/backend/...
ExecStart=[ -n $MONITOR ] /start/monitor/...
won't work, because ExecStart must be path, not shell command
b)
ExecStart=/usr/libexec/%{name}/startifset $DRIVER /start/driver
ExecStart=/usr/libexec/%{name}/startifset $BACKEND /start/backend
ExecStart=/usr/libexec/%{name}/startifset $MONITOR /start/monitor
won't work, because there ExecStart can't be used more than once,
except with type=oneshot, which does not work here
c)
ExecStart=/usr/libexec/nut/startthemall
this is only workable solution I know (for now), but I don't know if it's the
best one
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because
dependency can change with configuration
Is there a good solution for this?
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? I have no problems with doing backups and restoring from them, but if it's a git problem, then someone in the future may be less fortunate. It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Michał Piotrowski mkkp...@gmail.com writes: W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? Looking closer it seems like git already does the right thing (open(master.lock), write(sha1), rename(master.lock, master)), so it appears to be a barriers issue. It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. gitrepository-layout(5) Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning irda-utils
As I have neither hardware to test nor time to give the package the needed love (i.e. init scripts) I've given up ownership of the irda-utils package. It's a package with 5 open bugs, two of them man page fixes, the other three initscript stuff that needs some work/testing. Karsten -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. I can imagine a %triggerun script looking at the old configuration file and then enabling the new services as required. because dependency can change with configuration Can you elaborate on this? What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? Can they be patched to use socket activation? Because then you could simply stop thinking about expressing the dependencies manually. Also note that there are two distinct kinds of dependencies: requirements and ordering. I don't think ordering dependencies change depending on the configuration, or do they? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 05:19 AM, Andreas Schwab wrote: Michał Piotrowskimkkp...@gmail.com writes: W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowskimkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? Looking closer it seems like git already does the right thing (open(master.lock), write(sha1), rename(master.lock, master)), so it appears to be a barriers issue. If the files exist, but do not have newly written data, you will still need an fsync() in there somewhere I think Barriers are responsible for meta-data, apps still need fsync() or fdatasync() to commit the new user data. Ric It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. gitrepository-layout(5) Andreas. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 15 Virtualization Test Day -- Thu. April 14th
This is just a reminder that today, April 14 is Fedora Virtualization test day. Test plans and more information for the event can be found on the Fedora Project Wiki at: https://fedoraproject.org/wiki/Test_Day:2011-04-14_Virtualization IRC for the event on freenode in #fedora-test-day. Please come lend a hand, we can use as many testers as possible. If you cannot make it on Thursday, please feel free to run through test plans as you have time,the feedback is still relevant and helps to make Fedora a better platform for virtualization. Thanks, Justin ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Virtualization Test Day -- Thu. April 14th
On Thu, Apr 14, 2011 at 14:00, Justin M. Forbes jmfor...@linuxtx.org wrote: This is just a reminder that today, April 14 is Fedora Virtualization test day. Test plans and more information for the event can be found on the Fedora Project Wiki at: https://fedoraproject.org/wiki/Test_Day:2011-04-14_Virtualization IRC for the event on freenode in #fedora-test-day. Please come lend a hand, we can use as many testers as possible. If you cannot make it on Thursday, please feel free to run through test plans as you have time,the feedback is still relevant and helps to make Fedora a better platform for virtualization. The testcase pages for Spice seem to be empty. See for example: https://fedoraproject.org/wiki/QA:Testcase_Virtualization_Spice_VirtManager_Setup Maxim Burgerhout ma...@wzzrd.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 09:14 AM, Michal Hlavinka wrote: Is there a good solution for this? The right solution is to split this into three service files as I have done in bug 696611 then simply run systemctl start/stop/restart/reload/enable upsd-master.service # for master ( which start the upsd-master and the upsd-driver service as was being done in the init script it will conflict with upsd-slave if it's running ) systemct start/stop/restart/reload/enable upsd-slave.service # for slave ( which will not start the upsd-driver service as was being done in the init script ) The upsd-driver should have been a seperate sysv service from the start from my pov but this is not the worst oddball I've come across... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. Upstream has their cross-distribution packaging guidelines / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. because dependency can change with configuration Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine. Can they be patched to use socket activation? Because then you could simply stop thinking about expressing the dependencies manually. Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver manualy without upsmon. And as I said above, this must be done the way that won't break existing configuration. Also note that there are two distinct kinds of dependencies: requirements and ordering. I don't think ordering dependencies change depending on the configuration, or do they? Somehow. Upsmon can require upsd or not based on configuration, but it does not say anything whether upsd should run or not (if it is not required). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 11:14, Michal Hlavinka (mhlav...@redhat.com) wrote:
Hi,
I have similar question (sorry for stealing this thread). I have package
that has 3 services (they somehow depend on each other). Based on
configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
handled by init script, but I don't know how to do it in systemd service
file.
AFAIK:
a)
EnvironmentFile=...
ExecStart=[ -n $DRIVER ] /start/driver/...
ExecStart=[ -n $BACKEND ] /start/backend/...
ExecStart=[ -n $MONITOR ] /start/monitor/...
In a systemd world we try to normalize how services are maintained and
managed. Ideally that means that you have a 1:1 mapping between service
files and actual daemons. So instead of having three daemons spawned
from a single sysv init script I'd encourage you to have three unit
files spawning three daemons.
This normalizes behaviour in many ways, for example the user can
individually enable/disable them, without an extra layer of enabling in
an extra config file.
We want a single place where services can be enabled/disabled, not
multiple at different layers.
Also, stuff like automatic restart and so on can only work correctly if
you maintain each daemon in a seperate systemd service.
won't work, because ExecStart must be path, not shell command
b)
ExecStart=/usr/libexec/%{name}/startifset $DRIVER /start/driver
ExecStart=/usr/libexec/%{name}/startifset $BACKEND /start/backend
ExecStart=/usr/libexec/%{name}/startifset $MONITOR /start/monitor
won't work, because there ExecStart can't be used more than once,
except with type=oneshot, which does not work here
Yes, ExecStart= is for the main process of a service, the one which
determines the lifetime of it.
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because
dependency can change with configuration
Yes, d)!
Our primary goal with systemd is to get things right and
normalized. Support the exact same behaviour as in SysV is not our top
goal, because well, we aren't sysvinit and to sport 100% identical
behaviour you'd have to be sysvinit.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 12:55, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: Is there a good solution for this? Which service ( file ) is this. I can take a look at to see which way is best to approach it. It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works). I think it is a good idea to enable/disable services only at once place, the init system, instead of adding additional per-service layers of disabling. An admin should not have to know how each service is specifically configured in detail just to enable or disable it. That means: if the admin enabels a service in systemd, the startup script should not refuse starting just because it is disabled in another config layer. That would be very confusing. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 4/14/11 4:27 AM, Michał Piotrowski wrote: W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? Looking closer it seems like git already does the right thing (open(master.lock), write(sha1), rename(master.lock, master)), so it appears to be a barriers issue. Do you see something unusual here? [3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem [3.926084] EXT4-fs (sda1): write access will be enabled during recovery [4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs [4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 269578 [4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 131130 [4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 13 [4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 271833 [4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 271832 [4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 269763 [4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 131082 [4.656696] EXT4-fs (sda1): 7 orphan inodes deleted [4.656701] EXT4-fs (sda1): recovery complete [4.667494] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) No, that's all normal recovery. What kind of SSD is it? SSDs being rather new beasts, with various different firmware implementations it's also possible that a barrier was ignored, etc... but hard to say. -Eric It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. gitrepository-layout(5) Thanks for the pointer Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. Upstream has their cross-distribution packaging guidelines / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. I presume their guidelines just cover SysV-style bootups? Ideally the systemd unit files are shipped with the upstream packages. In this case if upstream is interested in keeping things identical among distributions it might be easy to convince them to integrate such a patch which gets things right? because dependency can change with configuration Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine. If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea. Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver manualy without upsmon. Levae that to the user by invoking systemctl enable on either both or just one of the units. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependencies on mod_perl-devel in rawhide
On 11/04/11 22:28, Michael Schwendt wrote: On Mon, 11 Apr 2011 11:00:07 +0200, Marcela wrote: mod_perl-devel erroneously provides perl(warnings), which means that anything containing a perl script with use warnings; in it is liable to pull it in. Should be easily fixable - I'll get on it. Paul. Fixed in mod_perl-2.0.5-3.fc16 Not the only one: perl-CPAN - 'perl(base)' - libgtk-java-devel libgtk-java-devel also provides tons of 'perl(...)' stuff. Fixed in libgtk-java-2.10.2-5.fc15. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen sand...@redhat.com napisał: On 4/14/11 4:27 AM, Michał Piotrowski wrote: W dniu 14 kwietnia 2011 11:19 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: W dniu 14 kwietnia 2011 11:04 użytkownik Andreas Schwab sch...@redhat.com napisał: Michał Piotrowski mkkp...@gmail.com writes: But the question remains - should enabled barriers protect against such data loss/breakage? Or I just had a big bad luck? It could also be a bug in git, perhaps it needs to take more care to create the ref file atomically. Should I report it to upstream or in bugzilla.redhat.com? Looking closer it seems like git already does the right thing (open(master.lock), write(sha1), rename(master.lock, master)), so it appears to be a barriers issue. Do you see something unusual here? [ 3.926076] EXT4-fs (sda1): INFO: recovery required on readonly filesystem [ 3.926084] EXT4-fs (sda1): write access will be enabled during recovery [ 4.655780] EXT4-fs (sda1): orphan cleanup on readonly fs [ 4.655813] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 269578 [ 4.656046] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 131130 [ 4.656179] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 13 [ 4.656250] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 271833 [ 4.656380] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 271832 [ 4.656455] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 269763 [ 4.656633] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 131082 [ 4.656696] EXT4-fs (sda1): 7 orphan inodes deleted [ 4.656701] EXT4-fs (sda1): recovery complete [ 4.667494] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) No, that's all normal recovery. What kind of SSD is it? OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I did not have too much courage to update it :)) [1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133 [1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32) [1.586184] ata3.00: configured for UDMA/133 [1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.25 PQ: 0 ANSI: 5 [1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0 [1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks: (50.0 GB/46.5 GiB) [1.587835] sd 2:0:0:0: [sda] Write Protect is off [1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 So far, I have not any problems with this drive (not counting not working S.M.A.R.T. log). SSDs being rather new beasts, with various different firmware implementations it's also possible that a barrier was ignored, etc... but hard to say. Do the barriers are somehow dependent on the hardware? Maybe I need to look in the SSD documentation to find out if proper commands are supported? -Eric It seems to me that the repairing git repo without a deep knowledge of it can be rather difficult. gitrepository-layout(5) Thanks for the pointer Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14 Apr 2011 15:28:28 +0200 Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 14.04.11 12:55, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: Is there a good solution for this? Which service ( file ) is this. I can take a look at to see which way is best to approach it. It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works). I think it is a good idea to enable/disable services only at once place, the init system, instead of adding additional per-service layers of disabling. An admin should not have to know how each service is specifically configured in detail just to enable or disable it. While this make sense in abstract, it may fall short when it comes to specific cases. It really comes down to defining service. For an admin service is generally a (set of) program(s) that performs a function. Whether the service requires one or three daemons is generally not really interesting for the admin unless he wants to dig the details. In particular having to know which of three daemons to enable given a specific configuration is burdensome, as the admin now have to learn which one is required depending on the configuration. For some services this may be straightforward, for others not. And being forced to learn that is not really nice, esp. if it was not necessary before. It is particularly obnoxious if you have to remember to change a different configuration (the init system) if you are just changing your service configuration. That means: if the admin enabels a service in systemd, the startup script should not refuse starting just because it is disabled in another config layer. That would be very confusing. And yet the contrary is also true, see above. Systemd needs to offer a way to handle these situation until most distributions decide to adopt systemd. Because upstream has to deal primarily with sysvinit, and many will not care about systemd until it is widespread. You cannot expect package maintainers to heavily patch software and even change how it behaves or how it is configured just because Fedora decided to use systemd. Where it is possible to easily switch to systmed, I am all for providing specific configuration and adaptation, but systemd needs to cater for the needs of software that is developed primarily on sysvinit based systems. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 09:51, Simo Sorce (sso...@redhat.com) wrote: Systemd needs to offer a way to handle these situation until most distributions decide to adopt systemd. Because upstream has to deal primarily with sysvinit, and many will not care about systemd until it is widespread. The way it looks from the big names only Ubuntu ist left which is not working on systemd adoption in their distro. You cannot expect package maintainers to heavily patch software and even change how it behaves or how it is configured just because Fedora decided to use systemd. Well, you can always continue to use sysv scripts if you want sysv behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 4/14/11 8:50 AM, Michał Piotrowski wrote: W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen sand...@redhat.com napisał: ... What kind of SSD is it? OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I did not have too much courage to update it :)) Ok. We (the ext4 list) had a report a year ago or so where someone had really debugged some odd behavior with one ssd and its firmware, but not this one :) So not the same thing exactly, at least. [1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133 [1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32) [1.586184] ata3.00: configured for UDMA/133 [1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.25 PQ: 0 ANSI: 5 [1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0 [1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks: (50.0 GB/46.5 GiB) [1.587835] sd 2:0:0:0: [sda] Write Protect is off [1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 So far, I have not any problems with this drive (not counting not working S.M.A.R.T. log). SSDs being rather new beasts, with various different firmware implementations it's also possible that a barrier was ignored, etc... but hard to say. Do the barriers are somehow dependent on the hardware? Maybe I need to look in the SSD documentation to find out if proper commands are supported? I don't think you'll find that sort of thing; it's a question of implementing the spec properly, really. All I meant is that it is -possible- for hardware to be broken or noncompliant, so it's -possible- that that's what you're seeing. I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that the hardware needs to exhibit proper behavior as much as the application needs to issue the right data integrity syscalls. :) -Eric -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [perl] Filter *.so at the start of spec.
When you do an update for F-15, please add the following builds to it, which remove the bogus perl(UNIVERSAL) provides: perl-UNIVERSAL-exports-0.05-11.fc15 perl-UNIVERSAL-moniker-0.08-14.fc15 perl-UNIVERSAL-require-0.13-6.fc15 If they were pushed before the perl update, there'd be nothing left to provide perl(UNIVERSAL). Paul. https://admin.fedoraproject.org/updates/perl-UNIVERSAL-require-0.13-6.fc15,perl-UNIVERSAL-moniker-0.08-14.fc15,perl-UNIVERSAL-exports-0.05-11.fc15,perl-5.12.3-157.fc15 -- Marcela Mašláňová BaseOS team Brno -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. Upstream has their cross-distribution packaging guidelines / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. I presume their guidelines just cover SysV-style bootups? It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option In old script one just say he wants to use mode foo and script starts required services (one of the free). Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and master script will solve this. What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine. If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea. If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 12:51 PM, Michal Hlavinka wrote:
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host
b) upsd - runs when you have ups attached to that host
c) upsmon (master/slave mode) - usualy runs on machine where you have ups,
but it can run
on machine without ups or work with different ups than the attached one
Looking at the old sysv it only does 2 things...
if the $SERVER = yes in /etc/sysconfig/ups then start upsd driver upsd
and upsd monitor.
If the $SERVER != yes in /etc/sysconfig/ups then only start the monitor
service
start() {
if [ $SERVER = yes ]; then
echo -n $Starting UPS driver controller:
daemon /sbin/upsdrvctl start /dev/null 21
success || failure
RETVAL=$?
echo
prog=upsd
echo -n $Starting $prog:
daemon /usr/sbin/upsd $UPSD_OPTIONS /dev/null 21
success || failure
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
echo
echo -n $Starting UPS monitor (master):
daemon --pidfile /var/run/nut/upsmon.pid
/usr/sbin/upsmon /dev/null 21 success || failure
if [ $RETVAL = 0 ]; then
RETVAL=$?
fi
echo
else
echo -n $Starting UPS monitor (slave):
daemon --pidfile /var/run/nut/upsmon.pid
/usr/sbin/upsmon /dev/null 21 success || failure
echo
fi
[ $RETVAL = 0 ] touch /var/lock/subsys/ups
}
The only difference between usps-monitor in master mode and slave mode
is the echo (master)/echo (slave)
Now I've splitted this into three systemd services upsd.service
upsd-driver.service and upsd-monitor
upsd.service which if run will start uspd upsd-driver and the
upsd-monitor this is the same behavior as if $SERVER = yes
upsd-driver.service is stand alone and can be started stopped etc all by
it self
upsd-monitor.service is stand alone and can be started stopped etc all
by it self.
Starting this service on it's own is the exact same behaviour if $SERVER
!= yes
This is as close and as correct transfer to systemd as it gets.
The $SERVER variable in /etc/sysconfig/ups is obsoleted
If end users wants the uspd server ( which by the way defaulted to yes
so this even is not a breakage in default behaviour ) they only need to run
service upsd start or systemctl start upsd.service just ast they did before.
If they just want to use the monitor they just start the UPS Monitor
service
And now they can even start the UPS driver controller only which they
could not before.
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 15:59 użytkownik Eric Sandeen sand...@redhat.com napisał: On 4/14/11 8:50 AM, Michał Piotrowski wrote: W dniu 14 kwietnia 2011 15:42 użytkownik Eric Sandeen sand...@redhat.com napisał: ... What kind of SSD is it? OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I did not have too much courage to update it :)) Ok. We (the ext4 list) had a report a year ago or so where someone had really debugged some odd behavior with one ssd and its firmware, but not this one :) So not the same thing exactly, at least. [ 1.548188] ata3.00: ATA-8: OCZ-VERTEX2, 1.25, max UDMA/133 [ 1.548196] ata3.00: 97696368 sectors, multi 16: LBA48 NCQ (depth 0/32) [ 1.586184] ata3.00: configured for UDMA/133 [ 1.586599] scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.25 PQ: 0 ANSI: 5 [ 1.587295] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 1.587354] sd 2:0:0:0: [sda] 97696368 512-byte logical blocks: (50.0 GB/46.5 GiB) [ 1.587835] sd 2:0:0:0: [sda] Write Protect is off [ 1.587844] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 So far, I have not any problems with this drive (not counting not working S.M.A.R.T. log). SSDs being rather new beasts, with various different firmware implementations it's also possible that a barrier was ignored, etc... but hard to say. Do the barriers are somehow dependent on the hardware? Maybe I need to look in the SSD documentation to find out if proper commands are supported? I don't think you'll find that sort of thing; it's a question of implementing the spec properly, really. All I meant is that it is -possible- for hardware to be broken or noncompliant, so it's -possible- that that's what you're seeing. I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that the hardware needs to exhibit proper behavior as much as the application needs to issue the right data integrity syscalls. :) I think I'll try to update firmware on this drive over the weekend. When I read things like that in firmware release notes Fixed rare corner case that could cause the drive to reset and clear user data Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal -Eric -Eric -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 02:35 PM, Michal Hlavinka wrote: If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? I think that you would use BindTo= instead of Requires= in upsd.service ( that is if uspd is depend upon them being running = ) along with ExecStop= In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote: On 04/14/2011 12:51 PM, Michal Hlavinka wrote: Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one Looking at the old sysv it only does 2 things... As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Hi, 2011/4/14 Michal Hlavinka mhlav...@redhat.com: On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote: On 04/14/2011 12:51 PM, Michal Hlavinka wrote: Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one Looking at the old sysv it only does 2 things... As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all I had such situation when I worked on shorewall scripts conversion. I just didn't converted main shorewall-init script. At that time, I just did not have idea how to run bash loop in systemd service :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Bruno Wolff III br...@wolff.to On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ All the compacting firmwares on all SSD's do this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 16:35, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. Upstream has their cross-distribution packaging guidelines / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. I presume their guidelines just cover SysV-style bootups? It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and master script will solve this. Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-) If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea. If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? Yes, as was pointed out BindTo= can do that for you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 14:57, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/14/2011 02:35 PM, Michal Hlavinka wrote: If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? I think that you would use BindTo= instead of Requires= in upsd.service ( that is if uspd is depend upon them being running = ) along with ExecStop= In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service Why ExecStop= here? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Jason D. Clinton m...@jasonclinton.com: 2011/4/14 Bruno Wolff III br...@wolff.to On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ All the compacting firmwares on all SSD's do this. I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: Hi, I experienced a small loss of power during commiting to a git repo. I can't resist...how does a 'small' loss of power differ from a 'large' loss of power? :) -- 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: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Michał Piotrowski wrote: 2011/4/14 Jason D. Clinton m...@jasonclinton.com: 2011/4/14 Bruno Wolff III br...@wolff.to On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ All the compacting firmwares on all SSD's do this. I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) Dan Berrangé and I were just wondering how it knows it's NTFS; what happens for e.g. if you put an image of an NTFS volume inside an ext4 volume on one of these things? Kinda brings back memories of reiserfsck fun. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Adam Williamson wrote: On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: Hi, I experienced a small loss of power during commiting to a git repo. I can't resist...how does a 'small' loss of power differ from a 'large' loss of power? :) Haha only-serious but in my (probably outdated dead-tree :) book: Small loss of power: Enough to get the smoothing caps draining and kick up some wobble on the rails (might make your DRAMs go nuts). Aka a brownout. Large loss of power: Fetch the candles! (a blackout!). ;) Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Adam Williamson awill...@redhat.com: On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: Hi, I experienced a small loss of power during commiting to a git repo. I can't resist...how does a 'small' loss of power differ from a 'large' loss of power? :) 'small' is for a few milliseconds/seconds 'large' is for a few minutes/hours :) -- 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 -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
Am 14.04.2011 17:38, schrieb Michał Piotrowski: I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) why should the FS matter for the physical layer under the FS? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
2011/4/14 Bryn M. Reeves b...@redhat.com: On 04/14/2011 04:38 PM, Michał Piotrowski wrote: 2011/4/14 Jason D. Clinton m...@jasonclinton.com: 2011/4/14 Bruno Wolff III br...@wolff.to On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ All the compacting firmwares on all SSD's do this. I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) Dan Berrangé and I were just wondering how it knows it's NTFS; what happens for e.g. if you put an image of an NTFS volume inside an ext4 volume on one of these things? Good question. It would be good if it was possible to disable such feature. Kinda brings back memories of reiserfsck fun. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
W dniu 14 kwietnia 2011 17:53 użytkownik Reindl Harald h.rei...@thelounge.net napisał: Am 14.04.2011 17:38, schrieb Michał Piotrowski: I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) why should the FS matter for the physical layer under the FS? How you want to know which block can be freed without the knowledge about blocks allocated by file system? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 03:36 PM, Lennart Poettering wrote: In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service Why ExecStop= here? It was meant as an either or. The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop. The man page only states that if any of the service bound to it for one reason or another fails the service will be stopped at least that's the meaning I get when reading the BindTo= section in systemd.unit JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, Apr 14, 2011 at 05:31:35PM +0200, Lennart Poettering wrote: On Thu, 14.04.11 16:35, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: On 04/14/2011 11:14 AM, Michal Hlavinka wrote: d) split it to more service files and make dependency there this would be incompatible change in configuration and hard to do, Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. Upstream has their cross-distribution packaging guidelines / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. I presume their guidelines just cover SysV-style bootups? It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. Debian has mostly identical /etc/default/xxx. Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and master script will solve this. Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-) I'm using F15 dovecot package on F14. Works perfectly. (F14 dovecot package omits unit files). -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On 04/14/2011 04:19 PM, Tomasz Torcz wrote: /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. Debian has mostly identical /etc/default/xxx. Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
2011/4/14 Jóhann B. Guðmundsson johan...@gmail.com: On 04/14/2011 04:19 PM, Tomasz Torcz wrote: /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. Debian has mostly identical /etc/default/xxx. Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly... I am afraid that something like that will not be possible in this case - I expect much resistance from the users :) Of course, one common directory i.e /etc/services_config (or anything else with a better name) in all major distributions would be nice thing. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 18:40, Michał Piotrowski (mkkp...@gmail.com) wrote: 2011/4/14 Jóhann B. Guðmundsson johan...@gmail.com: On 04/14/2011 04:19 PM, Tomasz Torcz wrote: /etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request. Debian has mostly identical /etc/default/xxx. Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly... I am afraid that something like that will not be possible in this case - I expect much resistance from the users :) Of course, one common directory i.e /etc/services_config (or anything else with a better name) in all major distributions would be nice thing. The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything. I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer. So yeah, I'd push for phasing /etc/sysconfig out for most services, not standardize it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 16:15, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/14/2011 03:36 PM, Lennart Poettering wrote: In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service Why ExecStop= here? It was meant as an either or. The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop. Requires= and BindTo= both do that. The difference between the two switches is mostly an ordering issue: Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say: Requires=A After=A now, if you shut down A with systemctl stop A, this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running systemctl stop A: should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't. So where is this interesting? If A is a device and B is a service, then normally B should start after A is plugged in and be killed before A is unplugged. By using BindTo= you can also make it be killed if A is unplugged with B still running. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 696725] New: RPM doesn't create /var/run/amavisd
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RPM doesn't create /var/run/amavisd https://bugzilla.redhat.com/show_bug.cgi?id=696725 Summary: RPM doesn't create /var/run/amavisd Product: Fedora Version: 15 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: unspecified Component: amavisd-new AssignedTo: st...@silug.org ReportedBy: night...@hotmail.com QAContact: extras...@fedoraproject.org CC: st...@silug.org, fedora-perl-devel-l...@redhat.com, kana...@kanarip.com Classification: Fedora Story Points: --- Description of problem: The RPM doesn't create /var/run/amavisd, the amvaisd.pid file gets created here at runtime. This directory needs to be created with g+w permissions with group amavis for this package to work correctly. Version-Release number of selected component (if applicable): amavisd-new-2.6.4-3.fc15.noarch -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Systemd unit file implementation questions (ypbind)
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything. /etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves. I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the regular daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior. I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer. I've used a bunch of them to change the ways various daemons run, so I would definately say they are not pretty much unnecessary. They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors. Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either. So yeah, I'd push for phasing /etc/sysconfig out for most services, not standardize it. I'd be 180 degrees from that. -- 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: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything. /etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves. Yes, but all of that can be configured in a much nicer way in systemd: Copy /lib/systemd/system/foobar.service to /etc/systemd/system/foobar.service, and edit it there. You will have a short, easy to understand, super-flexible, very well documented way to edit service defaults. You can edit command lines, you may set a specific user id to run something as, you may set the CPU affinity or you can adjust the capability bounding set as you wish (among a lot of other stuff). You have the full range of configuration options systemd offers you, all in a very simple ini file. Now, let's look at /etc/sysconfig/xxx. What you see is that only options that the init script explicitly supports you can change. On one service you might be able to change the command line arguments with this, on a different one you may change the user id, on a third one you may change the CPU affinity and a fourht one might allow you to the caps bounding set. But you do not find a single sysconfig file where you could actually configure all of these options. Also, the options tend to have different names even if they do the same, and slightly different behaviour. systemd streamlines this. If you want to change the configuration of a specific service, you can do so with very minimal effort and great flexibility, and all of that without creating a completely new configuration language for it, or without needing specific support in the service startup logic. The configuration language for the admin and for upstream is the *same*. Looking at the history of this: the reason /etc/sysconfig/xxx was created in the first place is that while /etc/init.d/xxx was initially more like configuration (and thus located in /etc) it ended up being more like actual code (which it is after all). So in order to avoid having to edit code to make configuration changes, and to not confuse the package manager /etc/sysconfig/xxx was split out of the actual sysv init scripts. In systemd that split is not necessary, and we should just embrace that instead of keeping /etc/sysconfig/xxx alive without need. I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the regular daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior. I have trouble seeing in which way /etc/nsswitch.conf was in any way more regular than /etc/nsswitch.conf, I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer. I've used a bunch of them to change the ways various daemons run, so I would definately say they are not pretty much unnecessary. They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors. Yeah, and that's the nice thing in systemd, if you want to make a change to a service file, just take it, edit it and enjoy the full power that systemd puts in your hands! Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either. Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager. And if you want to return to the default settings you can just remove your file from /etc again and voila! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves),
changing them doesn't leave you with RPM wanting to replace them on
every package update either.
Yupp, and this is much much prettier in systemd. After you copied the
service file from /lib to /etc they are out of the package manager
territory and will always override what has been configured by the
distro packager.
Separating the program that integrates software into the distribution
(/etc/init.d/*) and user's configuration that is managed via
.rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora
packager updates /etc/init.d/*, this change is transparent to users,
as long as the chang doesn't affect the specifics of user's
configuration in /etc/sysconfig - and even if it does, the user has
.rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file hides the /lib file, the service will just break
with no indication that something needs to be updated. Or does
systemd support inheritance of configuration from /lib to /etc so
that the user can only make the minimal changes necessary?
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14 Apr 2011 20:35:07 +0200
Miloslav Trmač m...@volny.cz wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves),
changing them doesn't leave you with RPM wanting to replace them on
every package update either.
Yupp, and this is much much prettier in systemd. After you copied
the service file from /lib to /etc they are out of the package
manager territory and will always override what has been configured
by the distro packager.
Separating the program that integrates software into the distribution
(/etc/init.d/*) and user's configuration that is managed via
.rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora
packager updates /etc/init.d/*, this change is transparent to users,
as long as the chang doesn't affect the specifics of user's
configuration in /etc/sysconfig - and even if it does, the user has
.rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file hides the /lib file, the service will just break
with no indication that something needs to be updated. Or does
systemd support inheritance of configuration from /lib to /etc so
that the user can only make the minimal changes necessary?
Mirek
I was going to make exactly the same objection.
Now rpm scripts will have to check and possibly have to muck with the
copies in /etc or risk that the service in question will fail to work
after a major update.
Sounds like trading one set of issues for another set of
potentially bigger issues.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 20:35, Miloslav Trmač (m...@volny.cz) wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves),
changing them doesn't leave you with RPM wanting to replace them on
every package update either.
Yupp, and this is much much prettier in systemd. After you copied the
service file from /lib to /etc they are out of the package manager
territory and will always override what has been configured by the
distro packager.
Separating the program that integrates software into the distribution
(/etc/init.d/*) and user's configuration that is managed via
.rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora
packager updates /etc/init.d/*, this change is transparent to users,
as long as the chang doesn't affect the specifics of user's
configuration in /etc/sysconfig - and even if it does, the user has
.rpm{save,new} and can figure out what has happened.
Well, the simple fact is that systemd unit files aren't really
code. They are just config. So doing code updates on a sysv init script
does not really translate to systemd, because there is nothing to
update.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file hides the /lib file, the service will just break
with no indication that something needs to be updated. Or does
systemd support inheritance of configuration from /lib to /etc so
that the user can only make the minimal changes necessary?
Yes, you can use .include /lib/systemd/system/foo.service to import
another file, and then override selected settings.
Note however that while some settings override others some act as
additions. Example: A later User=foo will override an earlier User=bar,
but a later Requires=foo will be added to an earlier Requires=bar, so
that you effectively have Requires=foo bar. But I think it's kinda
obvious in most cases which settings are those with work as an addition
and which ones override.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thu, 14.04.11 15:48, Simo Sorce (sso...@redhat.com) wrote:
On Thu, 14 Apr 2011 20:35:07 +0200
Miloslav Trmač m...@volny.cz wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmad...@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves),
changing them doesn't leave you with RPM wanting to replace them on
every package update either.
Yupp, and this is much much prettier in systemd. After you copied
the service file from /lib to /etc they are out of the package
manager territory and will always override what has been configured
by the distro packager.
Separating the program that integrates software into the distribution
(/etc/init.d/*) and user's configuration that is managed via
.rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora
packager updates /etc/init.d/*, this change is transparent to users,
as long as the chang doesn't affect the specifics of user's
configuration in /etc/sysconfig - and even if it does, the user has
.rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file hides the /lib file, the service will just break
with no indication that something needs to be updated. Or does
systemd support inheritance of configuration from /lib to /etc so
that the user can only make the minimal changes necessary?
Mirek
I was going to make exactly the same objection.
Now rpm scripts will have to check and possibly have to muck with the
copies in /etc or risk that the service in question will fail to work
after a major update.
Sounds like trading one set of issues for another set of
potentially bigger issues.
Well, it's quite a bit different. Because an init script is a complex
fragile beast you probably end up updating it quite often. OTOH a
systemd unit file is just a few lines usually, which means there is much
less to update. And due to magic stuff like socket and bus activation
most deps don't have to be configured, so things are much more robus anyway...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110414 changes
Compose started at Thu Apr 14 13:15:51 UTC 2011 Broken deps for x86_64 -- collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16()(64bit) collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16(libmysqlclient_16)(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-0.10.so.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog) glom-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glom-libs-1.16.1-2.fc15.i686 requires libgdamm-4.0.so.12 glom-libs-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(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 gnome-themes-2.32.0-5.fc15.noarch requires gtk-theme-engine-clearlooks gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64
Re: Systemd unit file implementation questions (ypbind)
On Fri, 2011-04-15 at 00:23 +0200, Lennart Poettering wrote: Note however that while some settings override others some act as additions. Example: A later User=foo will override an earlier User=bar, but a later Requires=foo will be added to an earlier Requires=bar, so that you effectively have Requires=foo bar. But I think it's kinda obvious in most cases which settings are those with work as an addition and which ones override. Is that as obvious as: 1. If the parameter can be used only once (single value), a later usage will override it 2. If the parameter can be used multiple times (list of values), a later usage will be appended Or is there some special inclusion/inheritance magic? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] F-15 Beta RC2 Validation Test Recap
Greetings testers, As you've known that Beta has been declared gold, validation tests were being executed to guarantee that Beta RC2 could finally meet the beta release criteria[1]. During the tests, as expected, no beta blockers were found and the results were summarized as below: Installation * F15Beta-NTH(657619): 692135 ON_QA - Image failed media check * F15Blocker(617261): 695280 NEW - Installer unable to find correct dvd from nfsiso repository containing a set of images 696320 NEW - After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console * Warnings: 695054 NEW - Fail to exercise the addition of a FTP-based package repository during installation. 585006 NEW - syslinux's isohybrid utility creates ISOs with incorrect ISO size in their header (affects Fedora's netinst and live images) Desktop Bug 265350[*] - Can't extend panel to full screen size when multiple monitors are different sizes In addition, special thanks to robatino for his great leadership and the ones who participated in Beta testing, I hereby listed individual test contributions(aka the number of submit results and the contributor's ID) which we really appreciated: * Beta_TC1+RC1+RC2_Install: 120 robatino 9 redwolfe 6 ajwerkman 5 bsfmig 1 cpuobsessed * Beta_TC1_RC1+RC2_Desktop: 20 cra 9 vhumpa 1 jreiser If your bug(or name btw:)) is not listed, next time please remember to mark your results onto the result page so that we can collect your data and keep tracking your issues. See ya in pre-final tests! Thanks, Hurry [1] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria [*] https://bugs.kde.org/show_bug.cgi?id=265350 -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 19:54:36 Lennart Poettering wrote: On Thu, 14.04.11 16:15, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/14/2011 03:36 PM, Lennart Poettering wrote: In man systemd.unit BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd. ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service Why ExecStop= here? It was meant as an either or. The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop. Requires= and BindTo= both do that. The difference between the two switches is mostly an ordering issue: Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say: Requires=A After=A Why is After= required here? If B Requires A it seem obvious that B should be started After A (if there is no socket magic). now, if you shut down A with systemctl stop A, this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running systemctl stop A: should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't. That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-UNIVERSAL-require] Minor tidy-up
commit 1ad1faa0a73102ecf3522d4b6ea1aecb79383561
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 09:40:07 2011 +0100
Minor tidy-up
perl-UNIVERSAL-require.spec |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
---
diff --git a/perl-UNIVERSAL-require.spec b/perl-UNIVERSAL-require.spec
index abe6a32..dc43f3b 100644
--- a/perl-UNIVERSAL-require.spec
+++ b/perl-UNIVERSAL-require.spec
@@ -7,10 +7,9 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/UNIVERSAL-require/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/UNIVERSAL-require-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
%{summary}.
@@ -46,8 +45,8 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes
-%{perl_vendorlib}/UNIVERSAL
-%{_mandir}/man3/*.3*
+%{perl_vendorlib}/UNIVERSAL/
+%{_mandir}/man3/UNIVERSAL::require.3pm*
%changelog
@@ -55,7 +54,7 @@ rm -rf $RPM_BUILD_ROOT
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-4
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-3
- Mass rebuild with perl-5.12.0
--
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-UNIVERSAL-require] Tweak provides filter to work with rpm = 4.9 too
commit cc75fdef348f35d45b0d872e9badaf5e6e369edf
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 09:43:29 2011 +0100
Tweak provides filter to work with rpm = 4.9 too
perl-UNIVERSAL-require.spec | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
---
diff --git a/perl-UNIVERSAL-require.spec b/perl-UNIVERSAL-require.spec
index dc43f3b..d774b53 100644
--- a/perl-UNIVERSAL-require.spec
+++ b/perl-UNIVERSAL-require.spec
@@ -1,6 +1,6 @@
Name: perl-UNIVERSAL-require
Version:0.13
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Require() modules from a variable
Group: Development/Libraries
License:GPL+ or Artistic
@@ -11,19 +11,18 @@ BuildArch: noarch
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Filter bogus provide for perl(UNIVERSAL) (rpm 4.9 onwards)
+%global __provides_exclude ^perl\\(UNIVERSAL\\)
+
%description
%{summary}.
%prep
%setup -q -n UNIVERSAL-require-%{version}
-cat \EOF %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
-sed -e '/^perl(UNIVERSAL)$/d'
-EOF
-%define __perl_provides %{_builddir}/UNIVERSAL-require-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
+# Filter bogus provide for perl(UNIVERSAL) (prior to rpm 4.9)
+%global provfilt /bin/sh -c %{__perl_provides} | sed -e
'/^perl(UNIVERSAL)$/d'
+%define __perl_provides %{provfilt}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -50,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Apr 14 2011 Paul Howarth p...@city-fan.org - 0.13-6
+- Tweak provides filter to work with rpm = 4.9 too
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.13-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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-UNIVERSAL-require/f15/master] (2 commits) ...Tweak provides filter to work with rpm = 4.9 too
Summary of changes: 1ad1faa... Minor tidy-up (*) cc75fde... Tweak provides filter to work with rpm = 4.9 too (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-UNIVERSAL-exports] Minor tidy-up
commit 3267478428cad6f3d2a0fc808b95f70c3c74af11
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 10:10:37 2011 +0100
Minor tidy-up
perl-UNIVERSAL-exports.spec | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
---
diff --git a/perl-UNIVERSAL-exports.spec b/perl-UNIVERSAL-exports.spec
index e9a4d64..f92a591 100644
--- a/perl-UNIVERSAL-exports.spec
+++ b/perl-UNIVERSAL-exports.spec
@@ -5,13 +5,12 @@ Summary:Lightweight, universal exporting of variables
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/UNIVERSAL-exports/
-Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/UNIVERSAL-exports-%{version}.tar.gz
+Source0:
http://backpan.perl.org/authors/id/M/MS/MSCHWERN/UNIVERSAL-exports-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
BuildRequires: perl(Test::More)
BuildRequires: perl(Exporter::Lite)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
%{summary}.
@@ -47,8 +46,8 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes
-%{perl_vendorlib}/UNIVERSAL
-%{_mandir}/man3/*.3*
+%{perl_vendorlib}/UNIVERSAL/
+%{_mandir}/man3/UNIVERSAL::exports.3pm*
%changelog
@@ -56,7 +55,7 @@ rm -rf $RPM_BUILD_ROOT
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-9
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-8
- Mass rebuild with perl-5.12.0
--
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-UNIVERSAL-exports] Tweak provides filter to work with rpm = 4.9 too
commit 01ed28fea4546123a996c2b65d1421b1ff17bac4
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 10:17:46 2011 +0100
Tweak provides filter to work with rpm = 4.9 too
perl-UNIVERSAL-exports.spec | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
---
diff --git a/perl-UNIVERSAL-exports.spec b/perl-UNIVERSAL-exports.spec
index f92a591..2762f39 100644
--- a/perl-UNIVERSAL-exports.spec
+++ b/perl-UNIVERSAL-exports.spec
@@ -1,6 +1,6 @@
Name: perl-UNIVERSAL-exports
Version:0.05
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Lightweight, universal exporting of variables
Group: Development/Libraries
License:GPL+ or Artistic
@@ -12,19 +12,18 @@ BuildRequires: perl(Test::More)
BuildRequires: perl(Exporter::Lite)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Filter bogus provide for perl(UNIVERSAL) (rpm 4.9 onwards)
+%global __provides_exclude ^perl\\(UNIVERSAL\\)
+
%description
%{summary}.
%prep
%setup -q -n UNIVERSAL-exports-%{version}
-cat \EOF %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
-sed -e '/^perl(UNIVERSAL)$/d'
-EOF
-%define __perl_provides %{_builddir}/UNIVERSAL-exports-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
+# Filter bogus provide for perl(UNIVERSAL) (prior to rpm 4.9)
+%global provfilt /bin/sh -c %{__perl_provides} | sed -e
'/^perl(UNIVERSAL)$/d'
+%define __perl_provides %{provfilt}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -51,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Apr 14 2011 Paul Howarth p...@city-fan.org - 0.05-11
+- Tweak provides filter to work with rpm = 4.9 too
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.05-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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-UNIVERSAL-require] Created tag perl-UNIVERSAL-require-0.13-6.fc15
The lightweight tag 'perl-UNIVERSAL-require-0.13-6.fc15' was created pointing to: cc75fde... Tweak provides filter to work with rpm = 4.9 too -- 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-UNIVERSAL-require] Created tag perl-UNIVERSAL-require-0.13-6.fc16
The lightweight tag 'perl-UNIVERSAL-require-0.13-6.fc16' was created pointing to: cc75fde... Tweak provides filter to work with rpm = 4.9 too -- 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-UNIVERSAL-exports/f15/master] (2 commits) ...Tweak provides filter to work with rpm = 4.9 too
Summary of changes: 3267478... Minor tidy-up (*) 01ed28f... Tweak provides filter to work with rpm = 4.9 too (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-UNIVERSAL-exports] Created tag perl-UNIVERSAL-exports-0.05-11.fc15
The lightweight tag 'perl-UNIVERSAL-exports-0.05-11.fc15' was created pointing to: 01ed28f... Tweak provides filter to work with rpm = 4.9 too -- 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-UNIVERSAL-exports] Created tag perl-UNIVERSAL-exports-0.05-11.fc16
The lightweight tag 'perl-UNIVERSAL-exports-0.05-11.fc16' was created pointing to: 01ed28f... Tweak provides filter to work with rpm = 4.9 too -- 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-UNIVERSAL-moniker] Minor tidy-up
commit 639fec2f7b819b4e2066c9f7243c859304e61865
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 10:44:02 2011 +0100
Minor tidy-up
perl-UNIVERSAL-moniker.spec | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
---
diff --git a/perl-UNIVERSAL-moniker.spec b/perl-UNIVERSAL-moniker.spec
index c283b23..a40a690 100644
--- a/perl-UNIVERSAL-moniker.spec
+++ b/perl-UNIVERSAL-moniker.spec
@@ -7,10 +7,9 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/UNIVERSAL-moniker/
Source0:
http://search.cpan.org/CPAN/authors/id/K/KA/KASEI/UNIVERSAL-moniker-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
BuildRequires: perl(Test::More), perl(Lingua::EN::Inflect)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
UNIVERSAL::moniker enables classes to make a good
@@ -47,8 +46,8 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/UNIVERSAL
-%{_mandir}/man3/*.3*
+%{perl_vendorlib}/UNIVERSAL/
+%{_mandir}/man3/UNIVERSAL::moniker.3pm*
%changelog
@@ -56,7 +55,7 @@ rm -rf $RPM_BUILD_ROOT
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-12
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-11
- Mass rebuild with perl-5.12.0
@@ -84,7 +83,7 @@ rm -rf $RPM_BUILD_ROOT
* Fri Aug 5 2005 Tom spot Callaway tcall...@redhat.com 0.08-3
- add BR: perl(Lingua::EN::Inflect) to improve test coverage
-- add README to %doc
+- add README to %%doc
* Fri Jul 8 2005 Tom spot Callaway tcall...@redhat.com 0.08-2
- cleanups
--
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-UNIVERSAL-moniker] Tweak provides filter to work with rpm = 4.9 too
commit 6f88362fe592d3b869ed898ef822d20f47f11b1d
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 14 10:52:14 2011 +0100
Tweak provides filter to work with rpm = 4.9 too
perl-UNIVERSAL-moniker.spec | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
---
diff --git a/perl-UNIVERSAL-moniker.spec b/perl-UNIVERSAL-moniker.spec
index a40a690..3627b39 100644
--- a/perl-UNIVERSAL-moniker.spec
+++ b/perl-UNIVERSAL-moniker.spec
@@ -1,6 +1,6 @@
Name: perl-UNIVERSAL-moniker
Version:0.08
-Release:13%{?dist}
+Release:14%{?dist}
Summary:Real world naming for classes
Group: Development/Libraries
License:GPL+ or Artistic
@@ -11,6 +11,9 @@ BuildArch: noarch
BuildRequires: perl(Test::More), perl(Lingua::EN::Inflect)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Filter bogus provide for perl(UNIVERSAL) (rpm 4.9 onwards)
+%global __provides_exclude ^perl\\(UNIVERSAL\\)
+
%description
UNIVERSAL::moniker enables classes to make a good
guess at what they would be called in the real world.
@@ -18,13 +21,9 @@ guess at what they would be called in the real world.
%prep
%setup -q -n UNIVERSAL-moniker-%{version}
-cat \EOF %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
-sed -e '/^perl(UNIVERSAL)$/d'
-EOF
-%define __perl_provides %{_builddir}/UNIVERSAL-moniker-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
+# Filter bogus provide for perl(UNIVERSAL) (prior to rpm 4.9)
+%global provfilt /bin/sh -c %{__perl_provides} | sed -e
'/^perl(UNIVERSAL)$/d'
+%define __perl_provides %{provfilt}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -51,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Apr 14 2011 Paul Howarth p...@city-fan.org - 0.08-14
+- Tweak provides filter to work with rpm = 4.9 too
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.08-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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-UNIVERSAL-moniker/f15/master] (2 commits) ...Tweak provides filter to work with rpm = 4.9 too
Summary of changes: 639fec2... Minor tidy-up (*) 6f88362... Tweak provides filter to work with rpm = 4.9 too (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-UNIVERSAL-moniker] Created tag perl-UNIVERSAL-moniker-0.08-14.fc15
The lightweight tag 'perl-UNIVERSAL-moniker-0.08-14.fc15' was created pointing to: 6f88362... Tweak provides filter to work with rpm = 4.9 too -- 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-UNIVERSAL-moniker] Created tag perl-UNIVERSAL-moniker-0.08-14.fc16
The lightweight tag 'perl-UNIVERSAL-moniker-0.08-14.fc16' was created pointing to: 6f88362... Tweak provides filter to work with rpm = 4.9 too -- 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
Re: [perl] Filter *.so at the start of spec.
On 13/04/11 21:18, Paul Howarth wrote:
On Wed, 13 Apr 2011 15:38:21 +0200
Marcela Mašláňovámmasl...@redhat.com wrote:
On 04/13/2011 03:07 PM, Paul Howarth wrote:
On 01/10/10 09:26, Marcela Mašláňová wrote:
commit 29e9c5e6c9749506b3718757acf3069d1f7bab33
Author: Marcela Mašláňovámmasl...@redhat.com
Date: Fri Oct 1 09:25:49 2010 +0200
Filter *.so at the start of spec.
perl.spec | 68
+--- 1
files changed, 11 insertions(+), 57 deletions(-) ---
diff --git a/perl.spec b/perl.spec
index b73be39..3aa9bcc 100644
--- a/perl.spec
+++ b/perl.spec
@@ -6,6 +6,17 @@
%define multilib_64_archs x86_64 s390x ppc64 sparc64
%define parallel_tests 1
+# internal filter just for this spec
+%define %perl_default_filter %{?filter_setup: %{expand: \
+%filter_provides_in %{perl_vendorarch}/.*\\.so$ \
+%filter_provides_in %{archlib}/.*\\.so$ \
+%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ \
+%filter_from_provides /perl(UNIVERSAL)/d; /perl(DB)/d \
perl(UNIVERSAL) and perl(DB) shouldn't be filtered from the
provides of the main perl package since it actually *does* provide
these modules. We currently have the situation in F-15 and Rawhide
where various packages claim to provide these but the one that
actually does doesn't advertise the fact:
Thanks, they will be provided in next update.
Thanks; don't forget to fix F-15 too though.
When you do an update for F-15, please add the following builds to it,
which remove the bogus perl(UNIVERSAL) provides:
perl-UNIVERSAL-exports-0.05-11.fc15
perl-UNIVERSAL-moniker-0.08-14.fc15
perl-UNIVERSAL-require-0.13-6.fc15
If they were pushed before the perl update, there'd be nothing left to
provide perl(UNIVERSAL).
Paul.
--
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
[Bug 692060] perl-Crypt-OpenSSL-X509-1.8 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=692060 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Crypt-OpenSSL-X509-1.7 |perl-Crypt-OpenSSL-X509-1.8 |.1 is available |is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-04-14 06:51:18 EDT --- Latest upstream release: 1.8 Current version in Fedora Rawhide: 1.4 URL: http://search.cpan.org/dist/Crypt-OpenSSL-X509/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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
[Bug 696795] CVE-2011-1685 rt3: several security flaws fixed in 3.6.11, 3.8.10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=696795 Vincent Danen vda...@redhat.com changed: What|Removed |Added CC||fedora-perl-devel-list@redh ||at.com, mma...@redhat.com, ||rc040...@freenet.de, ||trem...@tremble.org.uk, ||xav...@bachelot.org -- 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
[Bug 696795] CVE-2011-1685 CVE-2011-1686 CVE-2011-1687 CVE-2011-1688 CVE-2011-1689 CVE-2011-1690 rt3: several security flaws fixed in 3.6.11, 3.8.10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=696795 Vincent Danen vda...@redhat.com changed: What|Removed |Added Summary|CVE-2011-1685 rt3: several |CVE-2011-1685 CVE-2011-1686 |security flaws fixed in |CVE-2011-1687 CVE-2011-1688 |3.6.11, 3.8.10 |CVE-2011-1689 CVE-2011-1690 ||rt3: several security flaws ||fixed in 3.6.11, 3.8.10 Alias||CVE-2011-1686, ||CVE-2011-1687, ||CVE-2011-1688, ||CVE-2011-1689, ||CVE-2011-1690 -- 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
[Bug 681755] RFE: Please upgrade Test::Simple
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=681755 --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2011-04-14 16:52:17 EDT --- perl-Test-Simple-0.98-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- 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
Broken dependencies: perl-Math-Random-MT-Auto
perl-Math-Random-MT-Auto has broken dependencies in the F-15 tree: On x86_64: perl-Math-Random-MT-Auto-6.16-2.fc15.x86_64 requires perl(Object::InsideOut) = 0:2.06 On i386: perl-Math-Random-MT-Auto-6.16-2.fc15.i686 requires perl(Object::InsideOut) = 0:2.06 Please resolve this as soon as possible. -- 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
