Re: git branch help?
On 08/03/2010 11:49 PM, Ben Boeckel wrote:
Björn Perssonbj...@xn--rombobjrn-67a.se wrote:
Adam Williamson wrote:
Would it be nice to stick this customization into fedora-packager, or
would it just confuse/surprise people?
Is it fast enough to not delay the prompt noticeably even on old computers?
I use zsh's vcs_info and the only one I've found (out of git, hg, darcs,
svn, and cvs) that doesn't feel like a no-op is bzr support.
What's the worst thing that could happen if it were to break? If Git were to
enter an infinite loop for example, would it render my shell useless?
Yes, it would. The shell will wait until the process gets back (hence my
non-support of bzr in my zsh config).
That's somewhat misleading - the user can use ctrl-c to interrupt it and
get a shell immediately.
Björn Persson
--Ben
If you want this, you might be better off using a function like:
showgittree() {
tree=$(git symbolic-ref HEAD 2/dev/null)
echo ${tree:11}
}
But I agree - please don't make this the default.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On 08/02/2010 01:41 PM, Michael Schwendt wrote: On Mon, 02 Aug 2010 12:31:22 +0100, James wrote: Remember that some packages get very little activity because they need very little. And these are not a problem at all. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. [snipped the rest here] Uh, come on, ... that's not helpful. There are ideas how to detect absent maintainers early by collecting and *combining* information available in the Fedora intrastructure. Not by having a single old stable pkg trigger an AWOL alarm. [snip] Really? So imagine this scenario. Packager foo has two packages, bar and baz. bar is a package much like ed, which needs very little attention, and goes for a year without anything needing doing to it, no koji activity happens. This increases the hidden little AWOLness counter. foo then goes on holiday for a week, and forgets to mention this on his fp.o page. A bug is found in package baz. Bug reports are filed - users are impatient. It's noticed that foo has a very high AWOLness counter due to foo's other package. He is surprised to learn that he's been declared AWOL and had his packages removed when he returns from holiday. As I read the initial proposal, this is entirely plausible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On 07/30/2010 10:31 PM, Kevin Fenzi wrote: On Fri, 30 Jul 2010 16:28:11 +0200 Sven Lankess...@lank.es wrote: On Fri, Jul 30, 2010 at 03:28:42PM +0200, Michael Schwendt wrote: I think we should add some policy to address those unmaintained packages, There is the non-responsive maintainer policy already. That policy isn't the easiest one to follow though. I understand that taking someones packages away should never be easy but maybe we could develop some metrics for the awolness of a maintainer and use that to possibly speed up the process. I would love a better policy. It's hard to balance tho... between someone who is just busy and someone who is really missing. ;( I think one thing that would help is perhaps to form a group that looks for these people (possibly using what you are talking about below), tries to contact them and if that fails marks them as missing. I know that seth worked on something similar based on commit frequency. What I could think of is: * Look at the FAS activity If a maintainer has multiple request for commit rights to his package which have not been answered in a long time that would increase his awolness counter. (This would mean that we need to encourage people to actually deny requests that they don't want to approve - currently it seems to be accepted that denying a request is rude and the more polite way to not approve a commit request is to just ignore it). I'm not sure just not acting on a request there is a sign of awol. They could just be waiting for the person to prove themselves, or some other reason. But if there is no pkgdb activity at all, I think thats an indicator perhaps. * Check if he actually has a current certificate to interface with koji Good idea. * Look at koji activity Yep. If a maintainer hasn't done any build in koji for three months or more that would increase his awolness counter. yeah, or any git commits, etc. Remember that some packages get very little activity because they need very little. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. If a package is no longer under heavy development, and is in a stage where releases happen very rarely if ever, and bugfixes are similarly rare, then what do you expect people to do? Reformat the spec file every three months so as to avoid the AWOL counter? Unless there are open bugs against a package with no activity from a maintainer, or it's way behind upstream (in which case there should probably be a bug open), the fact that nothing has happened in koji for three months isn't a problem. Lots of packages in Fedora are not bleeding edge GUI apps needing constant TLC. Please remember this when creating policies. -siXy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 11:13 PM, Bruno Wolff III wrote: On Wed, Jul 28, 2010 at 17:00:01 -0500, Conan Kudo (ニール・ゴンパ)ngomp...@gmail.com wrote: On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamsonawill...@redhat.comwrote: That is assuming that the other repo uses the same name as Fedora's. Fedora could call it ffmpeg-free, and the other repo could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think. conflicts would probably be more appropriate than obsoletes. You could also relocate and rename the fedora one and use alternatives. This is probably slightly cleaner, and means that The Other Repo(s) don't need to change their packages at all for it to work. But, as others have noted, this is the easy part. Splitting out the free parts and maintaining them is the hard bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: source url when upstream disappears (geocities)
On 07/18/2010 06:32 PM, Michael Schwendt wrote: On Sun, 18 Jul 2010 10:41:42 -0600, Kevin wrote: On Sat, 17 Jul 2010 12:09:01 +1000 David Timms wrote: ...snip... Should I update the URL ? No. Drop it if it gives 404 Not Found. rpmlint will occasionally complain that a url is invalid even when it isn't. google code projects, for example, often have this issue. If the url actually is valid but rpmlint doesn't like it, I tend to ignore rpmlint. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: in f13 =~ no longer working in bash
On 06/08/2010 08:05 PM, Richard W.M. Jones wrote: On Tue, Jun 08, 2010 at 02:14:12PM +0200, Farkas Levente wrote: hi, =~ no longer working in bash. just try this little line: - if [[ abc =~ abc.* ]]; then echo inside; else echo outside; fi - this give inside up to fedora-12, but it gives outside in fedora-13. imho it's a serious changes since all shell script will fail which use =~ :-( is there any reason for this? or any quick fixes? This bit us in libguestfs too, where we'd used the bash extension without thinking that they'd break it on us. The full fix is *not* just quote removal. cf. our first fix: http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=457fccae1b665347f81045e8c7a3309d8328c4fc and out later, complete fix: http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=4891ff9945177e8666af8381d1e0a54b8ce363e2 Huge pain in the neck .. bash should retain backwards compatibility, even for non-POSIX extensions. Rich. This actually stems from using poor bash syntax in the first place. Inside [[ foo ]] (as opposed to [ foo ]) you should not quote parameters. No wordsplitting or glob expansion is done inside [[ ]], so there is no need for those quotes. Get rid of them, and woosh! it works! For example, from your script, you had: [[ $path =~ '^\./etc' || $path =~ '^./dev' || $path =~ '^\./var' ]] If you had written this properly as: [[ $path =~ ^\./etc || $path =~ ^\./dev || $path =~ ^\./var ]] It would have continued to work just fine. The old behaviour may have worked on older bash versions, but it was always undefined, and relying on undefined behaviour in any programming language is a great way to get bitten on the butt later on. -siXy -- 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)
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: 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 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: Orphaning my packages
perl-Config-Simple -- Simple configuration file class I can take this, if you orphan it. siXy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
