Re: Packages depending on Yelp
On 25 May 2010 20:22, Matthew Garrett mj...@srcf.ucam.org wrote: Long-term, it would be nice for this to integrate with PackageKit somehow. Short-term, the simplest solution would seem to be to provide a stub package that provides: yelp and a yelp binary, and then have that binary do nothing other than tell the user that they need to install yelp. Spins would then be at liberty to choose whether to provide the real yelp or the stub version. Once that's implemented dependencies can be added. I could easily provide a simple binary to call in this instance to automatically install it if it's not found. It probably needs to be a little more generic than just the yelp case tho. Maybe this belongs in the toolkit (e.g. the toolkit calls to PackageKit so the the help type functions just work). If we can do this without patching applications then that would be best obviously. I don't think just providing a note help is not available is particularly useful. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Errors in packaging kupfer
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Errors in packaging kupfer
2010/5/26 Chen Lei supercyp...@gmail.com:
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
Chen Lei
s/not needed/needed/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi,
A merge is the most appropriate here. After all libjpeg-turbo just
offers a set of x86 specific SSE/MMX routines such as IDCT (maybe
huffman, but I didn't check that) that would be easily plugged into
ijg, but doesn't change the foundations (architecture and exposed
public API) of libjpeg.
Also, one has to think about the applications that depend on it: what
if they break and/or require changes.
-Ilyes Gouta
On Wed, May 26, 2010 at 1:45 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Ilyes Gouta wrote:
There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw
decodes.
This kind of arguments doesn't really make sense for Fedora. We should ship
the best implementation, not the most tried and true one. Fedora is about
advancing Free Software, not being conservative. If you see any concrete
issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it
just because it's not the same old stuff.
Something which is IMHO more important to consider is whether libjpeg-turbo
is missing any improvements which are in the current IJG codebase, e.g. new
APIs apps may start relying on at some point. (In that case, we need to
either decide which to ship or ship both.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 04:02, Casey Dahlin wrote:
On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
On 05/23/2010 04:19 AM, Kevin Kofler wrote:
Lennart Poettering wrote:
So far response from the community has been very positive, but we didn't
have a fedora-devel discussion about this yet, so we'll have to see
whether we can somehow make the broader community as enthusiastic about
the whole idea as I am. ;-)
I, for one, think systemd should be the default ASAP.
Perhaps the first time I can recall that we have agreed. ;)
~spot
Any particular reason on either of your parts?
Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).
Oh, is that so?
Have you actually read the blog story I put together?
Yes, but I'm going to go read it again just to be sure.
Why do you say cgroups are a dead end? Sure, Scott claims that, but
uh, it's not the only place where he is simply wrong and his claims
baseless. In fact it works really well, and is one of the strong points
in systemd. I simply see no alternative for it. The points Scott raised
kinda showed that he never really played around with them.
Please read up on cgroups, before you just dismiss technology like that
as dead end.
I did. When upstart was about to use them. 2 years ago. We chucked them by the
following LPC.
The problem we've found is that cgroups are too aggressive. They don't have a
notion of sessions and count too much as being part of your service, so you
end
up with your screen session being counted as part of gdm.
This is why setsid was added to the netlink connector.
The assumption that just because its new means its more advanced is in this
case a bit misguided.
Well, please read the blog story. I know it's long, but it should be an
interesting read. The whole point of the blog story is to make clear the
reason systemd exists is purely technical, and that we think our design
is simply the better one.
So you have:
1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence the
rest of Upstart, but a socket activation subsystem that could reach as far as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.
2) Bus activation. Missed opportunity here to actually become the launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying to
bludgeon Marcel Holtmann into turning over to the public for a year now.
3) Cutting down on the forking by replacing some of the shell scripts... cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about. But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
Modern systems just don't take very long to spawn awk. Or sed. Or cut.
Or bash. IMO this sort of tradeoff between speed and ease of use hasn't
been appropriate in 20 years.
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
The rest of systemd looks great to me - and the sooner we can switch the
lesser the pain in some respects (as the longer we wait, the more used
people become to upstart, and then we have to switch again, causing user
frustration).
-siXy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
James Findley wrote: Modern systems just don't take very long to spawn awk. Or sed. Or cut. Or bash. IMO this sort of tradeoff between speed and ease of use hasn't been appropriate in 20 years. It's really not at all uncommon for me to need to modify an init script. There would be much rage if in order to do this I had to download the SRPM, extract the init code, figure out what I needed to change, modify it, recompile then install. Absolutely. I remember something similar with hal-disk-something, related to mount options. One day everything got switched to compiled code and manageability approached zero. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 596103] New: perl-Net-Patricia-1.17_03 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Net-Patricia-1.17_03 is available https://bugzilla.redhat.com/show_bug.cgi?id=596103 Summary: perl-Net-Patricia-1.17_03 is available Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: ASSIGNED Keywords: FutureFeature Severity: medium Priority: low Component: perl-Net-Patricia AssignedTo: or...@cora.nwra.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: or...@cora.nwra.com, fedora-perl-devel-l...@redhat.com, phil...@redfish-solutions.com Classification: Fedora Latest upstream release: 1.17_03 Current version in Fedora Rawhide: 1.17 URL: http://search.cpan.org/dist/Net-Patricia/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 11:12, Bastien Nocera wrote:
On Wed, 2010-05-26 at 10:01 +0100, James Findley wrote:
On 26/05/10 04:02, Casey Dahlin wrote:
On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
On 05/23/2010 04:19 AM, Kevin Kofler wrote:
Lennart Poettering wrote:
So far response from the community has been very positive, but we
didn't
have a fedora-devel discussion about this yet, so we'll have to see
whether we can somehow make the broader community as enthusiastic about
the whole idea as I am. ;-)
I, for one, think systemd should be the default ASAP.
Perhaps the first time I can recall that we have agreed. ;)
~spot
Any particular reason on either of your parts?
Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).
Oh, is that so?
Have you actually read the blog story I put together?
Yes, but I'm going to go read it again just to be sure.
Why do you say cgroups are a dead end? Sure, Scott claims that, but
uh, it's not the only place where he is simply wrong and his claims
baseless. In fact it works really well, and is one of the strong points
in systemd. I simply see no alternative for it. The points Scott raised
kinda showed that he never really played around with them.
Please read up on cgroups, before you just dismiss technology like that
as dead end.
I did. When upstart was about to use them. 2 years ago. We chucked them by
the
following LPC.
The problem we've found is that cgroups are too aggressive. They don't have
a
notion of sessions and count too much as being part of your service, so you
end
up with your screen session being counted as part of gdm.
This is why setsid was added to the netlink connector.
The assumption that just because its new means its more advanced is in
this
case a bit misguided.
Well, please read the blog story. I know it's long, but it should be an
interesting read. The whole point of the blog story is to make clear the
reason systemd exists is purely technical, and that we think our design
is simply the better one.
So you have:
1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence
the
rest of Upstart, but a socket activation subsystem that could reach as far
as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.
2) Bus activation. Missed opportunity here to actually become the
launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying
to
bludgeon Marcel Holtmann into turning over to the public for a year now.
3) Cutting down on the forking by replacing some of the shell scripts...
cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about.
Now run a loop, in C, which does the same thing.
$ time ./foo /dev/null
real 0m0.002s
user 0m0.001s
sys 0m0.001s
You're comparing the wrong thing here - I was demonstrating that it
doesn't take noticeably longer to spawn awk than a small C app on modern
systems.
thus using:
for i in {1..1000}; do awk 'BEGIN{print Hello World}' /dev/null; done
for i in {1..1000}; do ./helloworld /dev/null; done
we compare how long it takes to start a trivial C program 1000 times to
a trivial awk program 1000 times.
The bash for loop overhead is present in both cases, and since we are
only interested in the difference in speed, we can ignore it. (I
actually ran this comparison a number of times, and used the mean value)
You're comparing how long it takes to launch an awk program 1000 times
to how long it takes to run 1000 iterations of a loop in C. This is not
an especially useful thing to do.
But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
There's no compiling of startup
Re: Remove 1507 Package(s) ?
Tomasz Torcz to...@pipebreaker.pl writes: On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote: ... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box. That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer .6 .4 In F11 nss-softokn-freebl is a subpackage of nss, thus always updated together with it. In F12+ nss-softokn-freebl is a subpackage of nss-softokn, which stayed at 3.12.4. 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
preupgrade / anaconda's final stage
Hi, I ran a couple of preupgrades to go from F12 to F13 last night and it all went very smoothly. I have only one slight criticism and that is that the final stage of the upgrade takes a subjectively long time, during which the progress indication is a frantic bouncing progress bar. What is actually happening at this point? I looked in the shell and did strace of the processes running - they were making a lot of system calls although I'm not sure how useful they were. vmstat showed activity, some disk reads and mostly disk writes. Is there a better way to show progress at this point? -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 25.05.10 23:02, Casey Dahlin (cdah...@redhat.com) wrote: Why do you say cgroups are a dead end? Sure, Scott claims that, but uh, it's not the only place where he is simply wrong and his claims baseless. In fact it works really well, and is one of the strong points in systemd. I simply see no alternative for it. The points Scott raised kinda showed that he never really played around with them. Please read up on cgroups, before you just dismiss technology like that as dead end. I did. When upstart was about to use them. 2 years ago. We chucked them by the following LPC. Who is we? The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. Well, how exactly you set up the groups is up to you, but the way we do it in systemd is stick every service in a seperate cgroup, plus every user in a seperate one, too. Some examples: /systemd-1/avahi.service /systemd-1/ge...@tty1.service /systemd-1/gdm.service /systemd-1/apache.service /user/lennart /user/cjd The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. In addition we can easily set all kinds of cgroup-based resource enforcement to these groups, i.e. force user lennart to CPU 1, and say that apache and all the cgi scripts it creates can only get up to 20% CPU. And avahi-daemon could be forced to get a quarter of the available RAM at max -- with all its processes summed up, regardless how often it might fork. And the whole thing is even recursive. If you run a per-user systemd as user lennart, you will end up with a sub-hierarchy like this: /user/lennart/systemd-4711/dbus-daemon.service /user/lennart/systemd-4711/dconfd.service And so on. And the nice thing is that these cgroups are shown when you do ps -eo cgroup, You can always figure out from ps to which service a process belongs, even if if it fork()ed a gazillions of times. And all the keeping track is done by the kernel, basically for free. No involvement from userspace. This is why setsid was added to the netlink connector. Well, this is just flawed, on so many levels, that it hurts. Asynchronously trying to follow how daemons fork/exit is just inherently broken because they can do an exponential amount of forks in the time you can (realisticly) collect them linearly only. Also, if a daemon forks too often, netlink willl drop your messages, which makes an easy-peasy way for processes to escape your supervision, using only inprivileged operations. You have constant userspace wakeups. Everything you apply on the processes is done asynchronously and hence is racy (killing, renice, yadda yadda). The problem is simply that your grip on the processes can never work, because you are scheduled at the same priority as the daemons you supervise and you get all notifications asynchronously. You *really* want to leave process tracking to the kernel, and not try to emulate that in userspace. Everything else is just unsafe and hence a joke in the context of process baby sitting. It's like if you'd employ a babysitter and give the kid a bike it can escape on while chaining your babysitter to the couch. So, it's just not safe, processes can *easily* escape your supervision. On top of that it is just ugly. And finally, you cannot nicely show the service something belongs to in ps the way cgroups give it to you for free. Then, you cannot set cgroup resource enforcement for your services, since you simply have no cgroups. And no nice interfacing with the other libcgroup tools either. Meh, and this lists gets on like this. People should not use cn_proc. It's evil. And if you are using for anything except logging you are doomed. And even for logging it isnt really useful. 1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you cared to submit the patch. We don't think its good enough by itself, hence the rest of Upstart, but a socket activation subsystem that could reach as far as systemd and even work standalone in settings where systemd can work is perfectly within Upstart's scope. I'd be happy to firm up the design details with you if you wanted to contribute patches. Well, for once, it would be nice to judge things due to actually existign features, not of big plans nobody is working on as you apparently admit outright. And then, the socket activtion is nice for various reasons, and lazy-loading is just one of them. The bigger advantage is that it does automatic dependency handling -- which of course is nothign that really fits into upstart's design, since that is based on events not dependencies -- events are just broken, as I might note. And adding dependency would turn around upstart's design, making it a completely different
Re: Remove 1507 Package(s) ?
On Wed, May 26, 2010 at 01:04:31PM +0200, Andreas Schwab wrote: Tomasz Torcz to...@pipebreaker.pl writes: On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote: ... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box. That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer .6 .4 In F11 nss-softokn-freebl is a subpackage of nss, thus always updated together with it. In F12+ nss-softokn-freebl is a subpackage of nss-softokn, which stayed at 3.12.4. Even subpackages can have different version and/or release from the src.rpm, but the nss-softokn maintainers unfortunately haven't done that. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-05-25 at 17:24 +0200, Lennart Poettering wrote: Can you point us to where any background discussion has taken place with Upstart folks? No, I cannot. Kay and I and a couple of others sat down at various LPC and GUADEC and discussed what we would like to see in an init system. And we had long discussions, but ultimately most of our ideas were outright rejected by Scott, such as the launchd-style activation and the cgroup stuff, two of the most awesome features in systemd now. (That said, we actually managed to convince him on other points, i.e. I believe we played a role in turning him from a D-Bus-hater into a D-Bus-lover). Sorry, but that's complete bullshit. We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. And it was Ryan Lortie who convinced me that D-Bus was the right way to go very early on, the conversion of Upstart to D-Bus happened years ago (Fedora is lagging behind on versions so only just got that). So we have discussed this with Scott in much detail, and we have followed his development for a longer time. But in the end I just don't think Upstart is the right thing, and fundamentally flawed and unlikely to change direction, which is why we chose to start anew, and not just fix Upstart. For more about that just read my blog story. Given that I have changed direction a couple of times with Upstart, and have been swayed to different courses by a good argument, I refuse that it's unlikely to change direction ;-) I'm certainly more interested in getting Upstart *right* than in rushing to get it finished by a certain date. To be clear, I believe the reason you implemented systemd instead of contributing help to Upstart is: a) your personal distaste for Ubuntu and Canonical b) your personal distaste for the copyright assignment policy (RedHat have signed this agreement for Upstart fwiw) c) your personal love of nih ;-) I don't think that's a bad thing, I certainly share (c) in equal measures g. I'm also not going to argue that Fedora shouldn't chose a different init system to mine, that's not really my place to do so. However I do dispute that I haven't been flexible wrt Upstart's design; indeed I would claim that part of the reason development is slower than the rapid against-the-wall pace of other projects, is that I'm too flexible with its design ;-) Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Errors in packaging kupfer
On Wed, May 26, 2010 at 2:05 PM, Chen Lei supercyp...@gmail.com wrote:
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
That does not answer the current topic.
Also, the checking is done by the waf script, not by the rpm packaging method.
The question is :
Why waf is not able to detect the gtk python module during rpmbuild?
pygtk and concerned gtk packages are installed.
Thanks,
rtnpro
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev pgpk2nMEotNvB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010 12:42:13 +0200 drago01 drag...@gmail.com wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100526 changes
Compose started at Wed May 26 08:15:13 UTC 2010 Broken deps for i386 -- almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12 1:anerley-0.1.8-4.fc14.i686 requires libedataserver-1.2.so.12 anjal-0.3.2-2.fc14.i686 requires libedataserver-1.2.so.11 anjal-0.3.2-2.fc14.i686 requires libcamel-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libcamel-provider-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libedataserverui-1.2.so.8 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 contact-lookup-applet-0.17-3.1.fc14.i686 requires libedataserver-1.2.so.12 dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 ekiga-3.2.6-3.fc14.i686 requires libedataserver-1.2.so.12 empathy-2.31.1-1.fc14.i686 requires libedataserver-1.2.so.12 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-provider-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libedataserver-1.2.so.11 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 evolution-sharp-0.21.1-6.fc14.i686 requires libedataserver-1.2.so.12 giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12 gnome-launch-box-0.4-17.fc14.i686 requires libedataserver-1.2.so.12 gnome-panel-2.30.0-2.fc14.i686 requires libedataserver-1.2.so.12 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-python2-evolution-2.30.0-5.fc14.i686 requires libedataserver-1.2.so.12 jana-0.4.5-0.4.20090622gitb416a41.fc14.i686 requires libedataserver-1.2.so.12 kdebase-workspace-python-applet-4.4.80-2.fc14.i686 requires PyKDE4 = 0:4.4.80 kobby-1.0-0.3.b4.fc13.i686 requires libinfinity-0.3.so.0 kobby-1.0-0.3.b4.fc13.i686 requires libinftext-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0 mail-notification-evolution-plugin-5.4-19.fc14.i686 requires libcamel-provider-1.2.so.15 mail-notification-evolution-plugin-5.4-19.fc14.i686 requires libcamel-1.2.so.15 mail-notification-evolution-plugin-5.4-19.fc14.i686 requires libedataserver-1.2.so.12 moblin-panel-myzone-0.0.13-3.fc14.i686 requires libedataserver-1.2.so.12 moblin-panel-people-0.0.10-5.fc14.i686 requires libedataserver-1.2.so.12 nautilus-sendto-2.28.4-2.fc14.i686 requires libedataserver-1.2.so.12 plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 sepostgresql-8.4.3-2582.fc14.i686 requires postgresql-server = 0:8.4.3 syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12 tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-provider-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libedataserver-1.2.so.12 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.91-3.fc13.i686 requires libgps.so.18 Broken deps for x86_64 -- almanah-0.7.3-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) 1:anerley-0.1.8-4.fc14.i686 requires libedataserver-1.2.so.12 1:anerley-0.1.8-4.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-provider-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) contact-lookup-applet-0.17-3.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) ekiga-3.2.6-3.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) empathy-2.31.1-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-provider-1.2.so.14()(64bit)
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 12:35 +0100, Scott James Remnant wrote: We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. If you want to add socket passing to upstart as well, we can turn this into a win-win situation instead of flaming each other. If both upstart systemd support this in the same way, it will will be much easier to get the patches for the various services upstream. That is great. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
* Ola Thoresen [26/05/2010 14:39] : Would it not be more fruitful to discuss _why_ you (we?) need to edit the initscripts? Describe what functionality is missing or wrong in the default ones? Editing environnement variables and indicating which specific interfaces I want the daemon to listen on for requests are the only real-world cases that come to my mind straight away. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove 1507 Package(s) ?
On Wed, 26 May 2010, Klaus Grue wrote: Hi, I just upgraded to F13. It's nice. But look at this: http://fedoraproject.org/wiki/PreUpgrade says Common post-upgrade tasks ... Some packages may no longer be supported by the new release ... These can be identified with the following command: package-cleanup --orphans So I did this: package-cleanup --orphans ... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 ... yum remove nss-softokn-freebl ... Remove 1507 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Is this ok [y/N]: N 1507 packages is about all I have. Is there a problem in wiki/PreUpgrade or package-cleanup or dependencies? a package orphan is any pkg you have installed which no longer appears in any repo you have. If you had upgraded to the new repos for f13 but not upgraded all pkgs then nss-softokn-freebl might have been an orphan but also required. if you try to update it, do you get anything? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 08:54:23AM -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove 1507 Package(s) ?
On Wed, 26 May 2010, Tomasz Torcz wrote: On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote: ... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box. That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer .6 .4 you're absolutely right. Try doing a yum downgrade to the nss-softokn-freebl in f13. And then file a bug on it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Chuck Anderson wrote: -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. And given my experience dealing with actual real-world designed daemons and other such things, I'd say we've shown no ability to 'properly' design them and won't be showing that anytime soon. So since we have to live in the world, let's not go shooting our feet off. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010 09:08:09 -0400 (EDT) Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 26 May 2010, Chuck Anderson wrote: -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. And given my experience dealing with actual real-world designed daemons and other such things, I'd say we've shown no ability to 'properly' design them and won't be showing that anytime soon. So since we have to live in the world, let's not go shooting our feet off. -sv If people are really keen on C init scripts, then a compromise could be to make it optional to use a bash script when the admin wants to do something. It would be a change and require re-training to understand how to do that, but it will be at least possible. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Requirements for a -devel package: are these written down?
I got a BZ for a package I maintain from someone who needs multilib support without using Mock: https://bugzilla.redhat.com/show_bug.cgi?id=595923 I found myself asking what the requirements are for a -devel package. In general, do we support this in -devel libs or not? On IRC, I think I've learned that the answer is yes, but this also made me realize that I really don't know what other requirements we may have for -devel packages, I wondered if everyone building -devel packages is providing multilib support, and I wondered if we need some way to detect conflicts among headers for multiple architectures. In this case, the problem was a conflict in the size of a long: #define XERCES_SIZEOF_LONG 4 vs. #define XERCES_SIZEOF_LONG 8 Are there other requirements for -devel packages that I should be aware of? Is there something I should read? Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 02:01:35PM +0200, Tomasz Torcz wrote: On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. Precisely my point. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 14:24, Simo Sorce wrote:
On Wed, 26 May 2010 09:08:09 -0400 (EDT)
Seth Vidalskvi...@fedoraproject.org wrote:
On Wed, 26 May 2010, Chuck Anderson wrote:
-21 million.
Scripts are a crutch to avoid properly designed daemons and
configuration systems. I never edit initscripts to configure
daemons, because they would just be overwritten at the next package
upgrade. Configuration should be separate from code.
And given my experience dealing with actual real-world designed
daemons and other such things, I'd say we've shown no ability to
'properly' design them and won't be showing that anytime soon. So
since we have to live in the world, let's not go shooting our feet
off.
-sv
If people are really keen on C init scripts, then a compromise could
be to make it optional to use a bash script when the admin wants to do
something. It would be a change and require re-training to understand
how to do that, but it will be at least possible.
Simo.
I think a better compromise, if people care about speed (which is the
only reason given for using C in the first place), is to clean up the
bash code in our initscripts.
As I demonstrated in another post, you can get virtually all of the
speed of C initscripts by getting rid of basic coding errors.
For example, I have one initscript here that does:
family=`grep ^cpu family /proc/cpuinfo | head -n1 | awk -F : '{
print $2 }'`
this much slower (on this system about 3 times slower) than simply writing:
family=$(awk -F: '/^cpu family/{print $2;exit}' /proc/cpuinfo)
Unfortunately, for some reason, fixing bad bash is often perceived as
nitpicking rather than usefully contributing. Not sure why this is as
the same isn't really true of any other language.
-siXy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 9:04 AM, Chuck Anderson c...@wpi.edu wrote: On Wed, May 26, 2010 at 08:54:23AM -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. I don't edit them, but I do frequently look at them to see what they're doing/why they aren't doing something/what config files i can add/edit to change behaviour etc. actually, i do edit them sometimes to add a temporary -x to them. sure as heck beats gdb. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 14:01, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. Well, that depends on configuration. Many admins will probably like it if they have an easy control that allows them to enforce that a user doesn't continue running processes after he is logged out. For example, in an university network it is probably a good idea to enforce something like that on workstation machines. And in other cases (i.e. central login servier) you might want to allow screen and suchlike, i.e. processes continuing to run after the user logged out. But then, when you delete a user you still want a nice way to kill all his processes. And in both cases you still might want to enforce resources limitations on the various users. Hence grouping user processes in proper cgroups is really useful, even if you ultimately don't enable the kil user group on last logout checkbox. So, the cgroups stuff allows you to do a lot of stuff we couldn't do before. But that doesn't mean all of it is useful in all cases. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Seth Vidal wrote: +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. Absolutely. I have no idea why you shouldn't use a small and light interpreted language rather than C. You would have a standard library of useful init related functions, so you wouldn't have to fork awk, etc. The actual init scripts would be very small then. C is also missing useful datatypes such as maps, which would require libraries to load. Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). -- 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 (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Matthias Clasen wrote: On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. great - then I'm happy to be mistaken. thanks for clearing it up. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 4:07 PM, Jeremy Sanders jer...@jeremysanders.net wrote: Seth Vidal wrote: +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. Absolutely. I have no idea why you shouldn't use a small and light interpreted language rather than C. You would have a standard library of useful init related functions, so you wouldn't have to fork awk, etc. The actual init scripts would be very small then. C is also missing useful datatypes such as maps, which would require libraries to load. Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. Well spawing your logic further means we should avoid compiled programs at all, what if I want configure $app by editing its source code? Oh wait it is written in C ... If it goes down to want to edit scripts for configuration reasons (which isn't sane anyway) compared to a faster an cleaner boot process I'd opt for the later. Seriously source code is NOT and never was intended to be a configuration system period. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 4:16 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). They are flawed, simply spawning awk multiple times and measure the time is not a test to compare bash to C. And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). Which would be faster than spawing random process but still orders of magnitudes slower than a C program. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Once upon a time, drago01 drag...@gmail.com said: On Wed, May 26, 2010 at 4:16 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). They are flawed, simply spawning awk multiple times and measure the time is not a test to compare bash to C. And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). Which would be faster than spawing random process but still orders of magnitudes slower than a C program. Where are your numbers proving this is a measurable impact? -- 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: Font rendering in F13
On Sun, May 23, 2010 at 09:51:53PM +0200, drago01 wrote: The patents for the former expired but apparently some fonts look worse with it so we decided to disable it. (I have been running with it enabled for years and for me stuff does look _way_ better with the bci ... but well this is a subjective thing). Take a look at the two screenshots I attached to bug https://bugzilla.redhat.com/show_bug.cgi?id=547532. I think that, while it might be subjective, it's pretty clear that the without bytecode version is much, much better for Inconsolata -- which I spend my day using. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 15:20, Matthias Clasen wrote: On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. Actually the blog post is proposing exactly that, as I read it. And it seems not only that lots of other people read it the same way, but some even agree with it. So I'm not sure I see how this is going off into the weeds - if transitioning some/all initscripts to C is a genuine goal of the author of the project, on which he is not prepared to budge, then that is likely to have bearing on its adoption into fedora, and rightly so. -siXy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 08:43 -0400, Matthias Clasen wrote: On Wed, 2010-05-26 at 12:35 +0100, Scott James Remnant wrote: We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. If you want to add socket passing to upstart as well, we can turn this into a win-win situation instead of flaming each other. If both upstart systemd support this in the same way, it will will be much easier to get the patches for the various services upstream. That is great. I don't see any reason not to at least pass the LISTEN_FDS environment variable (though I can't figure out what LISTEN_PID is for?) Upstart will support a different mechanism as well though, because for the services we want to activate this way in Ubuntu, there are benefits to having the services phone back to Upstart to pick up the socket. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100525 changes
2010/5/26 Yanko Kaneti yan...@declera.com: On Tue, 2010-05-25 at 14:26 +, Rawhide Report wrote: llvm-2.7-2.fc14 --- * Mon May 24 2010 Michel Salim sali...@fedoraproject.org - 2.7-2 - Exclude llm-gcc manpages - Turn on apidoc generation - Build with srcdir=objdir, otherwise clang doxygen build fails 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm Please reconsider :/. This is big, even compared to the other doxygen monstrosities out there. Easily avoidable by removing graphviz from the build deps. 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm 308665052 kdelibs-apidocs-4.4.80-1.fc14.noarch.rpm 183951176 texlive-texmf-doc-2007-35.fc13.noarch.rpm 159398728 asterisk-apidoc-1.6.2.8-0.1.rc1.fc14.x86_64.rpm 143864764 mrpt-doc-0.8.0-0.3.20100102svn1398.fc14.x86_64.rpm 118899072 cloudy-devel-doc-08.00-1.fc14.noarch.rpm 115558504 qt-doc-4.7.0-0.14.beta1.fc14.noarch.rpm 90590052 lilypond-doc-2.12.3-1.fc13.noarch.rpm 66853332 libdap-doc-3.9.3-2.fc12.x86_64.rpm 61305644 antlr3-C-docs-3.2-6.fc14.noarch.rpm 52820224 bes-doc-3.7.2-3.fc12.x86_64.rpm Roughly 10% of a particular arch tree footprint on the mirrors. Yanko -- I suggest not to ship apidocs for all applications, very few people actually need them. Most developers only need apidocs for some paticular libraries. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Adam Williamson wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? What about a compromise? The initscripts are plain text files that get compiled after you edit them. Solution 1 Example: viinit postgresql Make your changes :wq viinit compiles your script into a binary. Solution 2: Give Bash JIT. OTOH, why is this even a sub-topic in this sub-topic of a thread? I'd love to see some numbers from the complainers about scripting being slow. I have a normal Fedora 13 x86_64 system that boots through initscripts in under 10 seconds. Normal services are starting as I have not tweaked my service list. Unless Fedora needs a 1 second boot time (hey I wouldn't complain) do we really need to spend time on 100+ email threads and jump through multiple init systems to find that perfect solution? I've read similar claims of salvation when upstart was being marketed to replace SysVinit. Everyone will switch to native scripts and everything will be better! Has everyone switched to native upstart scripts? AFAIK - No. Will everyone switch to systemd native scripts? I'm betting - no. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 10:01, James Findley (s...@gmx.com) wrote:
3) Cutting down on the forking by replacing some of the shell scripts...
cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
Maybe individually its not a problem. But doing that all the time ( 1000x
or so during boot) is just slow.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
It's no only about launching it. Take a couple of tools, pipe them
together, and actually execute some code with it.
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about. But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
Dude, this is not what I am suggesting, I want no compiled startup
scripts.
All I am saying that the majority of stuff should just be done in the
init system or the daemons themselves. And if there is something to
configure then do so in the .service file or in the daemon
configuration. But there is no point in keeping all in shell.
Also 2.24s is already quite a bit, if I may say so.
Modern systems just don't take very long to spawn awk. Or sed. Or cut.
Or bash. IMO this sort of tradeoff between speed and ease of use hasn't
been appropriate in 20 years.
Well, they actually do if you do that a thousand times.
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
We are not taking control away from you: you can still configure the
.service file to your needs, and you have much more high-level controls
in there, and if you really want to you can still plug in a shell script
instead of the daemon binary itself and things will work just fine.
Also, much the code in the init scripts simply goes away without any
need for replacement if the init system is just smarter. You will have
to debug less, you will have to fix less, because there is less code,
and less buggy code, and less fragile shell code. You also will have
less duplication in each and every init script.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 6:07 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. Again the sysadmin case just implies that something *else* is broken. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. Why don't people try to configure lets say X by editing its code'? Does this sound wrong to you? If yes than why would initscripts be different? If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C Well if you want to write and modify something you have to know the language it is written in, in case you don't it isn't a problem either just ask for help. It is not rocket science or something that would required hundreds of man hours. What about people who write apps that need initscripts in some other language? See above. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 12:27, seth vidal (skvi...@fedoraproject.org) wrote: Right, would be good if you could elaborate about that. I alead asked you a couple of times about this. Would love to hear about the reasoning. Scott, Lennart, A Proposal: maybe the two of you should continue this discussion off-list, in private. Well, just to point out, Scott and I and Kay had a private email exchange just about this yesterday and the day before yesterday. Was kinda one-sided, the public discussion is sometimes helpful to actually force those involved to make real points, instead of wishy-washy comments... But anyway, I see no point on continuing that here either. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
I've made some benchmarks starting a dummy service (do not call any programs
or kill) and a samba server on my notebook. I run those tests 4 times and
discarded the first one. Each test execute 100 times the command:
service dummy restart = 0,023ms
service smb restart = 0,158ms
c application = 0,016ms
After I made this change:
--- /etc/init.d/functions2010-05-26 13:26:00.0 -0300
+++ /etc/init.d/functions2010-05-26 13:03:01.0 -0300
@@ -305,12 +305,13 @@
if checkpid $pid 21; then
# TERM first, then KILL if not dead
kill -TERM $pid /dev/null 21
- usleep 10
- if checkpid $pid sleep 1
+ usleep 1000
+ if checkpid $pid usleep 10
+ checkpid $pid sleep 1
checkpid $pid sleep $delay
checkpid $pid ; then
kill -KILL $pid /dev/null 21
-usleep 10
+usleep 5
fi
fi
checkpid $pid
After this, the time dropped 60%:
service smb restart = 0,051ms
And finally I wrote this C application:
#include unistd.h
#include stdlib.h
#include sys/wait.h
int main(int argc,char *argv[]) {
int pid,ret,a;
for(a=0;a100;a++) {
if((pid=fork())==0) {
execlp(smbd,smbd,-D,NULL);
exit(-1);
}
waitpid(pid,ret,0);
kill(pid,9);
}
exit(0);
}
This is the final result:
service dummy restart = 0,023ms
service smb restart = 0,158ms
service smb restart (after hack) = 0,051ms
c application = 0,016ms
We are talking about to gain 0.035ms per process on init using C (service
restart) in my notebook.
Gustavo Junior Alves
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote: Again the sysadmin case just implies that something *else* is broken. Sure. As a distribution, we don't have control over upstream projects and their assumptions for daemon startup, shutdown, status, etc. Sometimes, they want odd things. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. If you think you can get every open source / free software project to agree on completely consistent behavior, or if you can create a text-format config file for your compiled daemon handler which handles every unanticipated case, well, okay. But it seems unlikely. (And that's not even considering running non-free software, which, while something I try to avoid, is a reasonable real-world use.) Why don't people try to configure lets say X by editing its code'? X is one program produced by one project, with a text-mode config file that handles all of its possible options. That's easy. Does this sound wrong to you? If yes than why would initscripts be different? Because the initscripts system needs to flexibly handle and make pretty any random mess thrown at it. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: http://0pointer.de/public/dbus.service. Note the ExecStartPre here, like most daemons, is conceptually busted. There's no reason we shouldn't lay that file down once when the OS is installed, and not check it every boot. Or alternatively, just move the uuid generation into the daemon itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100525 changes
On Wed, May 26, 2010 at 5:43 PM, Chen Lei supercyp...@gmail.com wrote: 2010/5/26 Yanko Kaneti yan...@declera.com: On Tue, 2010-05-25 at 14:26 +, Rawhide Report wrote: llvm-2.7-2.fc14 --- * Mon May 24 2010 Michel Salim sali...@fedoraproject.org - 2.7-2 - Exclude llm-gcc manpages - Turn on apidoc generation - Build with srcdir=objdir, otherwise clang doxygen build fails 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm Please reconsider :/. This is big, even compared to the other doxygen monstrosities out there. Easily avoidable by removing graphviz from the build deps. apidoc generation was actually disabled until this release; someone asked for it on the mailing list. I'll revert it to being a build-time option and suggests the requester rebuild it himself. Regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering mzerq...@0pointer.de wrote: Well, that depends on configuration. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Do you have a service file example yet in systemd git that can be used to get an understanding of the various configuration options which determine what gets killed and what doesn't? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote: Oh come on. Thanks for turning this into something personal. You did that last week - I got forwarded logs from #systemd. That's probably why I wasn't in a great mood with you this morning ;-) I'd prefer it we would keep this discussion purely technical. Everything else does not help at all in this matter. I think you're wrong, you think I'm wrong; let's go shopping :-) I only jumped in to refute your comment that you'd talked to me, and I hadn't listened, because that was incorrect. I'm not sure there's any point in technical discussion about the relative merits of our two approaches at this point, since you've already *written* systemd and you're already pushing for inclusion in distributions, and I'm continuing to develop Upstart and already have it in distributions. So what we've ended up with is two different systems, and one can assume that roughly half the distributions will end up with one, and another half with the other. At least we have the common standard of the LSB Init Scripts that both will support. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 26.05.10 09:07, Adam Williamson (awill...@redhat.com) wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT! The plan is to reduce what is currenlty done in files like /etc/init.d/messagebus to files like http://0pointer.de/public/dbus.service. Also: Description=D-Bus System Bus This seems unnecessary. Can we default to the name of the script? If this isn't translated, I don't see how it's more interesting than just dbus. Requires=basic.target sockets.target dbus.socket After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 12:07 PM, Adam Williamson wrote: It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? It could work out if systemd provided access to a system() equivalent which could then execute an arbitrary script. I think one good argument for redoing initscripts is that they are so repetitive: most of the content is fairly standard: initialization, argument parsing, case $1 in start) stop), etc etc. ; stuff that might as well be done in the common framework. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
Various ways to deal with that:
1. Change the Exec=/usr/libexec/food to
ExecStart=/usr/local/sbin/foodwrapper
2. Add some hook support in the systemd config files.
3. Add support for switching specific services back to using the
initscript even when booting with systemd.
But on the other hand, shell scripts can be optimised too. Maybe the awk
call is redundant anyway? Maybe something like foo=${bar%.conf} would
be enough?
/Alexander
PS.
Someday I should go on a rampage and submit patches that add set -e;
set -o pipefail to the start of every shell script in the distro. Or
maybe not...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Le dimanche 23 mai 2010 à 00:34 +0200, Lennart Poettering a écrit : ATM everything looks rosy. I just finished porting over all F13 installed-by-default daemons to socket activation, and a few more (and the patches are good enough to be upstreamable). For this kind of stuff I strongly suggest you do not limit yourself to F13 installed-by-default daemons (which are mostly well-behaved C/C++ desktop-oriented code) but pass the reality check of converting important server daemons (postfix, apache, bind...) and non C/C++ services (jboss or tomcat in java, amavisd-new or something else in perl, etc) Otherwise you'll replay the networkmanager drama with part of the Fedora users going the new laptop way, part refusing to even look at it because it can not translate in the server stuff they need at work, and everyone being very sad, unhappy, and angry at others. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
On Wed, 2010-05-26 at 10:29 -0400, Matthew Miller wrote: On Sun, May 23, 2010 at 09:51:53PM +0200, drago01 wrote: The patents for the former expired but apparently some fonts look worse with it so we decided to disable it. (I have been running with it enabled for years and for me stuff does look _way_ better with the bci ... but well this is a subjective thing). Take a look at the two screenshots I attached to bug https://bugzilla.redhat.com/show_bug.cgi?id=547532. I think that, while it might be subjective, it's pretty clear that the without bytecode version is much, much better for Inconsolata -- which I spend my day using. Depends on the criteria you use. The with bytecode version has better kerning, better shapes, better flow, but is blurry (yeah, without subpixel hintinting the fonts just are blurry and that's the main cause why people say they look ugly). The with bytecode on the other hand is perfectly crisp, but the shapes are worse, the flow is not so smooth, some letters look a little deformed... With that said I use subpixel hinting and I usually personally prefer the autohinter (but this one depends on the font, some look better to me autohinted, some using BCI...). But generally, if font looks bad hinted when using BCI, it's most likely a bug in font, but when BCI is not present we need to fall back to autohinter, not just turn off the hinting. Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Le mercredi 26 mai 2010 à 19:39 +0200, Alexander Boström a écrit : ons 2010-05-26 klockan 10:01 +0100 skrev James Findley: It's really not at all uncommon for me to need to modify an init script. There would be much rage if in order to do this I had to download the SRPM, extract the init code, figure out what I needed to change, modify it, recompile then install. Various ways to deal with that: 1. Change the Exec=/usr/libexec/food to ExecStart=/usr/local/sbin/foodwrapper Won't work since one of the main things current scripts do is run some code as root, and some other code as the target user. Here you are forcing all the shell part to run as either the target user (in which case the root parts won't work) or as root (in which case you have to reimplement all the shell user changing logic systemd is supposed to deprecate) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
+1 On Wed, May 26, 2010 at 6:30 PM, Martin Sourada martin.sour...@gmail.com wrote: On Wed, 2010-05-26 at 10:29 -0400, Matthew Miller wrote: On Sun, May 23, 2010 at 09:51:53PM +0200, drago01 wrote: The patents for the former expired but apparently some fonts look worse with it so we decided to disable it. (I have been running with it enabled for years and for me stuff does look _way_ better with the bci ... but well this is a subjective thing). Take a look at the two screenshots I attached to bug https://bugzilla.redhat.com/show_bug.cgi?id=547532. I think that, while it might be subjective, it's pretty clear that the without bytecode version is much, much better for Inconsolata -- which I spend my day using. Depends on the criteria you use. The with bytecode version has better kerning, better shapes, better flow, but is blurry (yeah, without subpixel hintinting the fonts just are blurry and that's the main cause why people say they look ugly). The with bytecode on the other hand is perfectly crisp, but the shapes are worse, the flow is not so smooth, some letters look a little deformed... With that said I use subpixel hinting and I usually personally prefer the autohinter (but this one depends on the font, some look better to me autohinted, some using BCI...). But generally, if font looks bad hinted when using BCI, it's most likely a bug in font, but when BCI is not present we need to fall back to autohinter, not just turn off the hinting. Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. I *very* strongly agree also. I do change init scripts, but even more than this, I see a growing trend for Linux systems to be less friendly to user modification. We are not so smart that we should do this. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
On Wed, May 26, 2010 at 07:30:56PM +0200, Martin Sourada wrote: Depends on the criteria you use. The with bytecode version has better kerning, better shapes, better flow, but is blurry (yeah, without Not just blurry, though -- awkwardly blurry. At screen resolution, in fact, I think it's pushing it to even say that the blurriness makes better shapes -- there's not enough pixels to make that work. The font has no bytecode, so it's not being hinted. But generally, if font looks bad hinted when using BCI, it's most likely a bug in font, but when BCI is not present we need to fall back to autohinter, not just turn off the hinting. Absolutely. I'm not opposed to the BCI, just opposed to failing to autohint non-bytecoded glyphs when the feature is enabled. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 14:08 -0400, Jon Masters wrote: On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. I *very* strongly agree also. I do change init scripts, but even more than this, I see a growing trend for Linux systems to be less friendly to user modification. We are not so smart that we should do this. Jon. So everybody seems to keep assuming that if more of the start up is done in the daemon itself that you'll lose the ability to configure it. I don't think that's the desired case, just that configuration will move to the configuration files, and not in the startup script. Separation of config from code seems smart to me, particularly come rpm update time. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi all, On 05/22/2010 05:55 PM, Xose Vazquez Perez wrote: hi there, Can it be updated to upstream version in rawhide ? The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on: Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/ May I point out that libjpeg version 7 and later add support for the patented (and optional) arithmetic coding part of the JPEG spec. So before we go any further in discussing whether or not to switch to a newer libjpeg we first need to investigate what the legal status of these newer versions is. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010 18:20:08 +0200 Lennart Poettering mzerq...@0pointer.de wrote: Regarding the LISTEN_PID env var: environment variables are normally inherited when forking/execing. We want to make sure that only the process we actually start ourselves parses and handles LISTEN_FDS. We want to avoid that if this daemon might spawn some other process, it might get confused into handling LISTEN_FDS, although that env var wasn't actually intended for it. And hence we say that LISTEN_PID should be verified first, and only if it matches LISTEN_FDS should be handled. If you are mandating behavior in daemons, wouldn't it be simpler to mandate the daemon unsets LISTEN_FDS ? If I replace the process with a script, or the dameon runs other processes LISTEN_PID is going to be wrong anyway, not sure how useful it really is. You are assuming that the process you run is always going to be *the* daemon. I think it is an unrealistic assumption to make. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 18:50 +0200, Lennart Poettering wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT! The plan is to reduce what is currenlty done in files like /etc/init.d/messagebus to files like http://0pointer.de/public/dbus.service. And those files you can edit just fine, and reconfigure. There's no need to yell, you only explained that a couple of minutes ago, before I wrote the above mail. From your blog post, it sounded very much like compiled initscripts were what you were proposing. This seems perfectly reasonable, but at the same time, when you explain it this way, it doesn't seem like anything that needs a new init system to happen. You can move stuff into the daemons themselves no matter what init system you're using, and it seems like upstart would be open to moving appropriate things into the init system. That does seem like a perfectly sensible thing to do, though, so I hope it happens, whatever init system we wind up with. -- 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: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 11:32 -0500, Michael Cronenworth wrote: OTOH, why is this even a sub-topic in this sub-topic of a thread? I'd love to see some numbers from the complainers about scripting being slow. I have a normal Fedora 13 x86_64 system that boots through initscripts in under 10 seconds. Normal services are starting as I have not tweaked my service list. Unless Fedora needs a 1 second boot time (hey I wouldn't complain) do we really need to spend time on 100+ email threads and jump through multiple init systems to find that perfect solution? I've read similar claims of salvation when upstart was being marketed to replace SysVinit. Everyone will switch to native scripts and everything will be better! Has everyone switched to native upstart scripts? AFAIK - No. Will everyone switch to systemd native scripts? I'm betting - no. My anecdotal evidence is up the same alley, FWIW - I have a system with a rather fast SSD in it and it completes the entire boot process, on F13, in 13 seconds or so. Which rather indicates that scripts aren't wasting a significant amount of time, and a lot of the time lost on more conventional systems is waiting for disk access. Has anyone run bootchart on Fedora lately? I remember we did something of a co-ordinated effort on it in F11, but I don't think it's happened on F12 or F13. That would give us an indication of where our startup bottlenecks *actually* are. Maybe I'll throw up a blog post on that later today, I have three rather different F13 systems to do it on now. -- 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: Errors in packaging kupfer
On Wed, May 26, 2010 at 8:43 AM, Mamoru Tasaka
mtas...@ioa.s.u-tokyo.ac.jp wrote:
Ratnadeep Debnath wrote, at 05/26/2010 08:46 PM +9:00:
On Wed, May 26, 2010 at 2:05 PM, Chen Leisupercyp...@gmail.com wrote:
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
That does not answer the current topic.
Also, the checking is done by the waf script, not by the rpm packaging
method.
The question is :
Why waf is not able to detect the gtk python module during rpmbuild?
pygtk and concerned gtk packages are installed.
Thanks,
rtnpro
With Fedora's pygtk2, import gtk fails if DISPLAY environment is
not set, and DISPLAY environment is always unset during rpmbuild
process. You see;
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.sxcUp9
+ umask 022
+ cd /home/rtnpro/rpmbuild/BUILD
+ cd kupfer-v200
+ LANG=C
+ export LANG
+ unset DISPLAY
Note that why I said Fedora's pygtk2 is that with Fedora's pygtk2
the following patch is applied:
http://cvs.fedoraproject.org/viewvc/rpms/pygtk2/devel/pygtk-nodisplay-exception.patch?view=log
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I've actually done a bit of work packaging this, and submitted a patch
for this problem upstream. It's two releases old, but it you can get
the idea from the patch, which I've added it in this email.
--- kupfer-pandoras-box-1.1.orig/wscript 2010-02-08 06:26:24.0 -0500
+++ kupfer-pandoras-box-1.1/wscript 2010-03-13 01:05:42.924787364 -0500
@@ -103,14 +103,10 @@
if not Options.options.check_deps:
return
- python_modules =
- gio
- gtk
- xdg
- dbus
-
- for module in python_modules.split():
- conf.check_python_module(module)
+ conf.check_python_module(gtk)
+ conf.check_python_module(gio)
+ conf.check_python_module(xdg)
+ conf.check_python_module(dbus)
Utils.pprint(NORMAL, Checking optional dependencies:)
Since you're doing this now, could you separate out kupfer-provider
into a second binary package, as I'm working with a package that
requires it, but not kupfer, so it'd be helpful to be able to install
them separately.
Best,
Patrick Dignan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: Regarding the LISTEN_PID env var: environment variables are normally inherited when forking/execing. We want to make sure that only the process we actually start ourselves parses and handles LISTEN_FDS. We want to avoid that if this daemon might spawn some other process, it might get confused into handling LISTEN_FDS, although that env var wasn't actually intended for it. And hence we say that LISTEN_PID should be verified first, and only if it matches LISTEN_FDS should be handled. This suggests to me that environment variables isn't the right way to do this. Environment variables are good for parameters that should be available to many processes. Command line parameters are better when the parameter is only meant for one specific process. I can see how looking up two environment variables may be a smaller patch than adding a parameter to the program's command line parser, but I still think it should be done with command line parameters. LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the original daemon is restarted but its children live on, then later some descendant process may get the same PID as the original daemon, and may try to handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is guaranteed to work over one that mostly works. Once a lot of programs start using this it will be difficult to change it, so it would be good to get it right early on. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
James Findley wrote:
You're comparing the wrong thing here - I was demonstrating that it
doesn't take noticeably longer to spawn awk than a small C app on modern
systems.
thus using:
for i in {1..1000}; do awk 'BEGIN{print Hello World}' /dev/null; done
for i in {1..1000}; do ./helloworld /dev/null; done
we compare how long it takes to start a trivial C program 1000 times to
a trivial awk program 1000 times.
The bash for loop overhead is present in both cases, and since we are
only interested in the difference in speed, we can ignore it. (I
actually ran this comparison a number of times, and used the mean value)
You're comparing how long it takes to launch an awk program 1000 times
to how long it takes to run 1000 iterations of a loop in C. This is not
an especially useful thing to do.
Your comparison is the flawed one. The point of porting the shell code to C
is to invoke ONE C program instead of many awk, grep etc. subprocesses. All
the operations done by awk etc. would be done by native C code. So doing the
loop in C is very much consistent with what we want to accomplish.
IMHO replacing slow interpreted code by fast compiled code is always a good
idea, especially so if the interpreted code is shell code with its massive
abuse of process spawning.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
What happened to this sssd update?
http://admin.fedoraproject.org/updates/sssd-1.2.0-12.fc13 Appears to be in limbo. Status: pending sgallagh - 2010-05-07 21:51:09 This update has been submitted for testing. bodhi - 2010-05-08 16:09:51 This update has been pushed to testing sgallagh - 2010-05-18 18:34:06 This update has been submitted for testing. bodhi - 2010-05-19 19:15:03 This update has been pushed to testing I don't see it in http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/13/i386 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What happened to this sssd update?
On Wed, 2010-05-26 at 15:03 -0600, Orion Poplawski wrote: http://admin.fedoraproject.org/updates/sssd-1.2.0-12.fc13 Appears to be in limbo. Status: pending sgallagh - 2010-05-07 21:51:09 This update has been submitted for testing. bodhi - 2010-05-08 16:09:51 This update has been pushed to testing sgallagh - 2010-05-18 18:34:06 This update has been submitted for testing. bodhi - 2010-05-19 19:15:03 This update has been pushed to testing I don't see it in http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/13/i386 There's no way those push comments could be referring to ssd-1.2.0-12.fc13, since it wasn't built until May 24. See: https://koji.fedoraproject.org/koji/buildinfo?buildID=174916 I think the update was edited and not submitted again. I filed a bodhi ticket about obsolete comments appearing in this case: https://fedorahosted.org/bodhi/ticket/413 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requirements for a -devel package: are these written down?
Jonathan Robie wrote: I got a BZ for a package I maintain from someone who needs multilib support without using Mock: https://bugzilla.redhat.com/show_bug.cgi?id=595923 Please send a new message instead of replying to an unrelated one. It matters for mail clients which support proper threading. See e.g.: http://en.wikipedia.org/wiki/User:DonDiego/Thread_hijacking Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Jeremy Sanders (jer...@jeremysanders.net) said: Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. If you're going to want them to be editable to pass the lowest-common-denominator test of whatever admins might be editing them, I think bash is probably the only reasonable choice. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
seth vidal wrote: It appears this subject has been picked up on lwn - so I'm certain there will be a fruitful, productive and constructive discussion there. Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and their comments are infested by trolls like no other place! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 592209] BerkeleyDB needs compatible versions of libdb db.h - binary mismatch
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=592209 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|NEW |ON_QA --- Comment #8 from Fedora Update System upda...@fedoraproject.org 2010-05-26 17:40:05 EDT --- perl-BerkeleyDB-0.41-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-BerkeleyDB'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-BerkeleyDB-0.41-2.fc13 -- 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 (Was Re: tmpfs for strategic directories)
James Findley (s...@gmx.com) said: Actually the blog post is proposing exactly that, as I read it. And it seems not only that lots of other people read it the same way, but some even agree with it. So I'm not sure I see how this is going off into the weeds - if transitioning some/all initscripts to C is a genuine goal of the author of the project, on which he is not prepared to budge, then that is likely to have bearing on its adoption into fedora, and rightly so. What I took from it is that code like this from rc.sysinit: ... if [ ! -e /proc/mounts ]; then mount -n -t proc /proc /proc mount -n -t sysfs /sys /sys /dev/null 21 fi ... really doesn't need to be there. If you're redesigning the init system, rather than keeping compatibility with ancient stupid sysvinit, there's no reason that shell code is needed for this; init should Just Do It when it starts. In fact, I'm pretty sure recent upstart releases do the same thing. I'm sure we can find more examples if we look. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What happened to this sssd update?
On 26/05/10 22:03, Orion Poplawski wrote: http://admin.fedoraproject.org/updates/sssd-1.2.0-12.fc13 Appears to be in limbo. Needs cuddles and kisses. If you are using it leave a comment. If not: http://koji.fedoraproject.org/koji/buildinfo?buildID=174916 Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 23:39 +0200, Kevin Kofler wrote: seth vidal wrote: It appears this subject has been picked up on lwn - so I'm certain there will be a fruitful, productive and constructive discussion there. Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and their comments are infested by trolls like no other place! I believe Seth was displaying that common Fedorian trait generally referred to as 'sarcasm' =) -- 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
gcc 4.4 vs. 4.5 (was: Re: rawhide report: 20100526 changes)
Rawhide Report wrote: gcc-4.4.4-5.fc14 * Tue May 25 2010 Jakub Jelinek ja...@redhat.com 4.4.4-5 - update from gcc-4_4-branch Can we get 4.5 for F14? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
wqy-microhei-fonts (was: Re: rawhide report: 20100526 changes)
Rawhide Report wrote: In order to keep the WenQuanYi Zen Hei as default Simplified Chinese font, the fontconfig file of this WenQuanYi Micro Hei font is removed. I think this is wrong. It'll break if somebody only has Micro Hei installed, for space reasons (e.g. the F13 KDE spin ships wqy-microhei-fonts as the only CJK font). IMHO wqy-microhei-fonts should ship a fontconfig file claiming all of zh-cn, zh-tw, ja and ko (it also contains glyphs for Katakana, Hiragana and Hangul), but with lower priority than the default fonts. (But FWIW, qt is picking up the Japanese and Korean glyphs even if the fontconfig file only claims Chinese as it does in F13 GA. I haven't tested what happens with no fontconfig file at all.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 23:39 +0200, Kevin Kofler wrote: seth vidal wrote: It appears this subject has been picked up on lwn - so I'm certain there will be a fruitful, productive and constructive discussion there. Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and their comments are infested by trolls like no other place! Kevin Kofler May I introduce you to sarcasm? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 23:39:49 +0200, Kevin Kofler kevin.kof...@chello.at wrote: seth vidal wrote: It appears this subject has been picked up on lwn - so I'm certain there will be a fruitful, productive and constructive discussion there. Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and What's interesting is that Fedora's development / user list discussions get so much press on LWN. their comments are infested by trolls like no other place! You must not read slashdot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pkg-config in rawhide
There has been some instability in rawhide pkg-config in the last few days. The reason is that I've built the long-overdue 0.24, which turned out to have a few small issues. One remaining problem that is still causing some build problems is https://bugzilla.redhat.com/show_bug.cgi?id=596433 where we need to update find-requires.pkgconfig to match the behavior change that our --print-requires patch underwent on its way upstream. Sorry for the inconvenience, Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: banshee-1 hang during playing video overnight
On Wed, May 26, 2010 at 2:45 PM, Luming Yu luming...@gmail.com wrote: On Wed, May 26, 2010 at 11:48 AM, Rakesh Pandit rakesh.pan...@gmail.com wrote: On 26 May 2010 08:16, Luming Yu wrote: Hi there, I happen to see a banshee-1 hang after it was accidentally left repeatedly playing two videos (big-buck-bunny.ogv and kittens.ogv) overnight. Any insight and suggestions to the hang will be very appreciated. Please report it on bugzilla (if not already done) with all information and follow up with maintainer. https://bugzilla.redhat.com/show_bug.cgi?id=595997 Hmmm no responses ? Anyone knows what's going on from the back trace? Please let me know what you need to proceed further.. if nobody cares about it, please suggest me an alternative to banshee-1.. /l -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nautilus-pastebin disappeared!
hey, I recently packaged nautilus-pastebin. I tested it successfully, so did Rahul [1] A few days ago, it stopped functioning. That is, a right click no longer shows a send to pastebin option. I'm sure this isn't an error in the nautilus-pastebin package since it's the same package that functioned properly a few days back and Rahul and me tested. How do I find out what update to what package caused this? regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-BerkeleyDB/F-13 perl-BerkeleyDB.spec,1.27,1.28
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-BerkeleyDB/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv17430/F-13
Modified Files:
perl-BerkeleyDB.spec
Log Message:
* Tue May 25 2010 Paul Howarth p...@city-fan.org
- Rebuild for Berkeley DB 4.8.30 in F-13 and Rawhide (#592209)
- Hard-code Berkeley DB requirement to avoid problems like #592209
- Add %{?perl_default_filter}
Index: perl-BerkeleyDB.spec
===
RCS file: /cvs/pkgs/rpms/perl-BerkeleyDB/F-13/perl-BerkeleyDB.spec,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -p -r1.27 -r1.28
--- perl-BerkeleyDB.spec13 Feb 2010 20:00:58 - 1.27
+++ perl-BerkeleyDB.spec26 May 2010 07:06:51 - 1.28
@@ -1,6 +1,9 @@
+# Need to know the exact DB version we're built against
+%global db_ver %(sed '/DB_VERSION_STRING/!d;s/.*Berkeley
DB[[:space:]]*\\([^:]*\\):.*/\\1/' /usr/include/db4/db.h 2/dev/null || echo
4.0.0)
+
Name: perl-BerkeleyDB
Version:0.41
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl extension for Berkeley DB version 2, 3 or 4
License:GPL+ or Artistic
Group: Development/Libraries
@@ -14,6 +17,11 @@ BuildRequires: perl(MLDBM)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Hard-code Berkeley DB requirement to avoid problems like #592209
+Requires: db4 = %{db_ver}
+
+# Don't provide private Perl libs
+%{?perl_default_filter}
%description
BerkeleyDB is a module that allows Perl programs to make use of the
@@ -59,6 +67,11 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/*
%changelog
+* Tue May 25 2010 Paul Howarth p...@city-fan.org - 0.41-2
+- Rebuild for Berkeley DB 4.8.30 in F-13 and Rawhide (#592209)
+- Hard-code Berkeley DB requirement to avoid problems like #592209
+- Add %%{?perl_default_filter}
+
* Sat Feb 13 2010 Steven Pritchard st...@kspei.com 0.41-1
- Update to 0.41.
--
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 595831] Rebuild for db4 4.8.30 update
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=595831 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Resolution||DUPLICATE --- Comment #1 from Paul Howarth p...@city-fan.org 2010-05-26 03:14:19 EDT --- *** This bug has been marked as a duplicate of bug 592209 *** -- 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 592209] BerkeleyDB needs compatible versions of libdb db.h - binary mismatch
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=592209 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||nicolas.mail...@laposte.net --- Comment #6 from Paul Howarth p...@city-fan.org 2010-05-26 03:14:19 EDT --- *** Bug 595831 has been marked as a duplicate of this bug. *** -- 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 595834] Insufficient db4 requires
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=595834 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Resolution||DUPLICATE --- Comment #1 from Paul Howarth p...@city-fan.org 2010-05-26 03:14:33 EDT --- *** This bug has been marked as a duplicate of bug 592209 *** -- 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
