Re: For those who care about stable updates
On Saturday 11 March 2006 03:27, Kevin Mark wrote: [DPL as mediator] The DPL already could do that. The DPL probably in the past *did* step in in some cases behind the scenese. There's no reason for the technical overhead of a mediator@ email alias - there's leader, and people who trust the DPL to be able to mediate conflicts can reach him there. Mediation can only work if all parties accept the mediator as a person of respect/authority who is capabable of working out a fair solution and accept that a mediator will help. Otherwise, it'll be just an additional party in the debate - no win. > After the meeting everyone would agree to not discuss anything in public > and only redress furthur problems by arranging another private irc > session. Hmm. I agree with you that solving these problems is behind the scenes work. But I think a solution worked out by a mediator ought to be published, because often enough the problem is also the subject of frequent discussions and flamewars, often also between people not actually involved in the problem (and thus the mediation.) Mediation is about finding a solution, not about blaming anybody, so publication of the mediation's result should be constructive instead of 'he was guilty'. cheers -- vbi -- Tapferkeit ist die Fähigkeit, von der eigenen Furcht keine Notiz zu nehmen. -- George Patton pgp2ZA7P8SPSv.pgp Description: PGP signature
Re: question for all candidates
On Fri, Mar 10, 2006 at 02:14:01AM +1000, Anthony Towns wrote: > On Thu, Mar 09, 2006 at 03:47:35PM +0200, Kalle Kivimaa wrote: > > Could these mails be required to have a valid GPG signature (either > > for a key in a public keyserver or a DD key)? This would eliminate the > > spam problem (almost) entirely. > keyring-maint is the address for problems with your key -- not being > able to mail it when you have problems with your key seems a bad idea. :) AFAICT, the only reasons a developer should need to contact the keyring-maint role address are: 1) needing to have a key removed from the ring 2) needing to get a replacement key accepted If the developer is contacting keyring-maint due to 1), I guess it means the key is no longer in their control, or else they could just publish their own revocation certificate and upload it to keyring.debian.org. However, you're still left with a question of verifying the authenticity of the request; perhaps having developers proxy such requests through some other developer for signing isn't a bad idea? Well, or maybe it is... 2) seems pretty easy to handle anyway, since getting a replacement key into the keyring does require new signatures from other DDs, so making "signed mail to keyring-maint" part of the process doesn't seem too onerous. Though as an additional practical consideration, doing gpg checks against a keyring is probably heavier than all other spam filtering rules combined... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Re: Re: Implicition declarations of functions and bugs
Hi,
David Mosberger-Tang, le Fri 10 Mar 2006 19:47:10 -0700, a écrit :
> Its purposes is not to "grep for warnings" but instead to
> look for pairs of warnings that are *guaranteed* to cause crashes on
> 64-bit machines.
I did understand that. And my abs() example shows that gcc-4.0 doesn't
complain is such case.
> enum e_t { a, b };
>
> enum e_t
> bar (char *str)
> {
> return strlen (str);
> }
> $ gcc-3.3 -c -g -O -Wall t.c
> t.c: In function `bar':
> t.c:12: warning: implicit declaration of function `strlen'
> $ gcc-4.0 -c -g -O -Wall t.c
> t.c: In function 'bar':
> t.c:12: warning: implicit declaration of function 'strlen'
> t.c:12: warning: incompatible implicit declaration of built-in function
> 'strlen'
That one may cause crashes too because of the str argument. It happens
that with pointers, on amd64, the compiler seems to correctly fill up
registers. But I don't know how this is and will always be true on all
64bits backends (it is not true for longs on amd64).
Well, submit the bug, and gcc people will tell us.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
Samuel,
You're missing the point of the check-implicit-pointer-functions
script. Its purposes is not to "grep for warnings" but instead to
look for pairs of warnings that are *guaranteed* to cause crashes on
64-bit machines. gcc -Wall normally spits out tons of spurious
warnings for 64-bit dirty code, but most of those warnings are just
noise. The problem with gcc-4.0 warnings is that you can't
distinguish between harmless implicit function declarations and ones
that need to be flagged. Example:
$ cat t.c
char *
foo (char *str)
{
return strdup (str);
}
enum e_t { a, b };
enum e_t
bar (char *str)
{
return strlen (str);
}
$ gcc-3.3 -c -g -O -Wall t.c
t.c: In function `foo':
t.c:4: warning: implicit declaration of function `strdup'
t.c:4: warning: return makes pointer from integer without a cast
t.c: In function `bar':
t.c:12: warning: implicit declaration of function `strlen'
$ gcc-4.0 -c -g -O -Wall t.c
t.c: In function 'foo':
t.c:4: warning: implicit declaration of function 'strdup'
t.c:4: warning: incompatible implicit declaration of built-in function 'strdup'
t.c: In function 'bar':
t.c:12: warning: implicit declaration of function 'strlen'
t.c:12: warning: incompatible implicit declaration of built-in function 'strlen'
As you can see, the gcc-4.0 warnings are inferior because they
provides no way to distinguish the "foo" vs. "bar" case, even though
they are qualitatively different.
--david
On 3/10/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> David Mosberger-Tang, le Fri 10 Mar 2006 17:06:22 -0700, a écrit :
> > I'm inclined to treat this as a gcc-4 bug.
>
> It is not.
>
> > $ cat t.c
> > char *
> > foo (char *str)
> > {
> > return strdup(str);
> > }
> > $ gcc-3.3 -c -g -O -Wall t.c
> > t.c: In function `foo':
> > t.c:4: warning: implicit declaration of function `strdup'
> > t.c:4: warning: return makes pointer from integer without a cast
>
> Because strdup() here gets an implicit
> int strdup(int str)
> declaration, hence the warnings.
>
> > gcc-4.0 -c -g -O -Wall t.c
> > t.c: In function 'foo':
> > t.c:4: warning: implicit declaration of function 'strdup'
> > t.c:4: warning: incompatible implicit declaration of built-in function
> > 'strdup'
>
> Same story, except that gcc has additionnal knowledge of which prototype
> the strdup function should have: char *strdup(const char *str); . And
> char * and int are not compatible types.
>
> > The gcc-3.3 warnings makes perfect sense. The gcc-4.0 warnings are
> > useless.
>
> gcc-4.0 warnings are actually just more precise: not only there is a
> missing declaration, but gcc has strong conviction that the implicit
> prototype is really wrong (strdup() should really take char * and return
> char *, not int).
>
> > There is no hint on how the "implicit declaration of built-in function
> > `strdup'" is incompatible.
>
> Implicit declarations are in the form
> int foo(int bar, int baz, etc.)
> and the built-in strdup function has
> char *strdup(const char *str)
> as prototype. This is incompatible. gcc could even say "int is
> incompatible with char*", but I guess gcc people consider this as too
> verbose.
>
> This is a warning and not an error, because using one's own strdup()
> function (that would take ints) is perfectly legal. gcc-4.0 emits the
> warning to let the programmer know that he should disambiguate this by
> either #including the usual C header, or by giving the prototype of his
> own strdup() function.
>
> Anyway, such warnings deserve grepping, since they are evidence of a
> potential binary break.
>
> Regards,
> Samuel
>
--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
Re: For those who care about stable updates
On Fri, Mar 10, 2006 at 09:43:22PM +0100, Adrian von Bidder wrote: > It's sad, yes, but I think it's just the way people work. Debian is a city > now, not a village anymore - lots of people know lots of other people not > very well or not at all. This probably includes people in important > functions, although the various face to face meetings have improved this in > some areas. Right now we're trying to cope with city problems using > village methods - has not worked in the Real World, won't work in an online > community. Hi Adrian, if there is technical committee for arbitrating technical difference, I'd suggest a duty added to the DPL position: social mediator. Someone would email [EMAIL PROTECTED] which would be a special address forwarded to the DPL([EMAIL PROTECTED]) that would be encrypted with a DPL public key as to provide privacy. One party would email the problem and the mediator would send an encrypted email to (a leader of a group or the particular person) asking for a conference on a private irc channel with no logging and such. Each party would represent their side and the DPL would try to workout something. After the meeting everyone would agree to not discuss anything in public and only redress furthur problems by arranging another private irc session. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Re: Re: Implicition declarations of functions and bugs
Samuel Thibault, le Sat 11 Mar 2006 01:43:34 +0100, a écrit :
> > $ gcc-3.3 -c -g -O -Wall t.c
> > t.c: In function `foo':
> > t.c:4: warning: implicit declaration of function `strdup'
> > t.c:4: warning: return makes pointer from integer without a cast
>
> Because strdup() here gets an implicit
> int strdup(int str)
> declaration, hence the warnings.
>
> > gcc-4.0 -c -g -O -Wall t.c
> > t.c: In function 'foo':
> > t.c:4: warning: implicit declaration of function 'strdup'
> > t.c:4: warning: incompatible implicit declaration of built-in function
> > 'strdup'
>
> Same story, except that gcc has additionnal knowledge of which prototype
> the strdup function should have: char *strdup(const char *str); . And
> char * and int are not compatible types.
Another example:
int main(void) {
return abs(-1);
}
$ gcc-3.3 test.c -o test -Wall
test.c: In function `main':
test.c:3: warning: implicit declaration of function `abs'
$ gcc-4.0 test.c -o test -Wall
test.c: In function 'main':
test.c:3: warning: implicit declaration of function 'abs'
Here gcc 4.0 doesn't complain so much, because even if the abs()
function was not declared, the implicit prototypes matches the actual
prototype of the built-in abs() function, hence no potential binary
break if the programmer is really using the libc's abs() function.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
David Mosberger-Tang, le Fri 10 Mar 2006 17:06:22 -0700, a écrit :
> I'm inclined to treat this as a gcc-4 bug.
It is not.
> $ cat t.c
> char *
> foo (char *str)
> {
> return strdup(str);
> }
> $ gcc-3.3 -c -g -O -Wall t.c
> t.c: In function `foo':
> t.c:4: warning: implicit declaration of function `strdup'
> t.c:4: warning: return makes pointer from integer without a cast
Because strdup() here gets an implicit
int strdup(int str)
declaration, hence the warnings.
> gcc-4.0 -c -g -O -Wall t.c
> t.c: In function 'foo':
> t.c:4: warning: implicit declaration of function 'strdup'
> t.c:4: warning: incompatible implicit declaration of built-in function
> 'strdup'
Same story, except that gcc has additionnal knowledge of which prototype
the strdup function should have: char *strdup(const char *str); . And
char * and int are not compatible types.
> The gcc-3.3 warnings makes perfect sense. The gcc-4.0 warnings are
> useless.
gcc-4.0 warnings are actually just more precise: not only there is a
missing declaration, but gcc has strong conviction that the implicit
prototype is really wrong (strdup() should really take char * and return
char *, not int).
> There is no hint on how the "implicit declaration of built-in function
> `strdup'" is incompatible.
Implicit declarations are in the form
int foo(int bar, int baz, etc.)
and the built-in strdup function has
char *strdup(const char *str)
as prototype. This is incompatible. gcc could even say "int is
incompatible with char*", but I guess gcc people consider this as too
verbose.
This is a warning and not an error, because using one's own strdup()
function (that would take ints) is perfectly legal. gcc-4.0 emits the
warning to let the programmer know that he should disambiguate this by
either #including the usual C header, or by giving the prototype of his
own strdup() function.
Anyway, such warnings deserve grepping, since they are evidence of a
potential binary break.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
I'm inclined to treat this as a gcc-4 bug. To witness:
$ cat t.c
char *
foo (char *str)
{
return strdup(str);
}
$ gcc-3.3 -c -g -O -Wall t.c
t.c: In function `foo':
t.c:4: warning: implicit declaration of function `strdup'
t.c:4: warning: return makes pointer from integer without a cast
gcc-4.0 -c -g -O -Wall t.c
t.c: In function 'foo':
t.c:4: warning: implicit declaration of function 'strdup'
t.c:4: warning: incompatible implicit declaration of built-in function 'strdup'
The gcc-3.3 warnings makes perfect sense. The gcc-4.0 warnings are
useless. There is no hint on how the "implicit declaration of
built-in function `strdup'" is incompatible.
--david
On 3/10/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> dann frazier, le Fri 10 Mar 2006 15:46:58 -0700, a écrit :
> > On Fri, 2006-03-10 at 00:30 +0100, [EMAIL PROTECTED] wrote:
> > > Hi,
> > >
> > > Ah, good. But your script misses some warnings:
> > >
> > > oss.c:83: warning: incompatible implicit declaration of built-in function
> > > 'strdu
> > >
> > > because of "incompatible" and "built-in". Please fix ;)
> >
> > Thanks Samuel,
> > Can you point us to the log file this is from? David & I aren't
> > subscribed, so please CC.
>
> This is from the speech-dispatch package:
> http://buildd.debian.org/fetch.php?&pkg=speech-dispatcher&ver=0.6-1&arch=ia64&stamp=1141941237&file=log&as=raw
>
> Regards,
> Samuel
>
--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
Re: For those who care about stable updates
pe, 2006-03-10 kello 20:31 -0300, Henrique de Moraes Holschuh kirjoitti: > On Fri, 10 Mar 2006, Lars Wirzenius wrote: > > pe, 2006-03-10 kello 21:49 +0100, Adrian von Bidder kirjoitti: > > > /me is trying to imagine the Debian project's members trying to agree on > > > an > > > enemy... > > > > Open RC bugs. Go to http://bts.turmzimmer.net/details.php, pick one, > > hate it to death. Sleep well. > > Can use that as a quote? It's brilliant! Sure. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
On Fri, 10 Mar 2006, Lars Wirzenius wrote: > pe, 2006-03-10 kello 21:49 +0100, Adrian von Bidder kirjoitti: > > /me is trying to imagine the Debian project's members trying to agree on an > > enemy... > > Open RC bugs. Go to http://bts.turmzimmer.net/details.php, pick one, > hate it to death. Sleep well. Can use that as a quote? It's brilliant! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
dann frazier, le Fri 10 Mar 2006 15:46:58 -0700, a écrit : > On Fri, 2006-03-10 at 00:30 +0100, [EMAIL PROTECTED] wrote: > > Hi, > > > > Ah, good. But your script misses some warnings: > > > > oss.c:83: warning: incompatible implicit declaration of built-in function > > 'strdu > > > > because of "incompatible" and "built-in". Please fix ;) > > Thanks Samuel, > Can you point us to the log file this is from? David & I aren't > subscribed, so please CC. This is from the speech-dispatch package: http://buildd.debian.org/fetch.php?&pkg=speech-dispatcher&ver=0.6-1&arch=ia64&stamp=1141941237&file=log&as=raw Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Fri, 10 Mar 2006, Andreas Tille wrote: > Are there any more hints what might stop the computer from doing > cleeen halt / reboot than apm/acpi or sysvinit. I just tried Yes, check for changes in /sbin/halt. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
On Thu, 09 Mar 2006, Peter Kourzanov wrote: > For most of the packages, what is so different in cross-compilation in > comparison to native? On my limited cross-compiling knowledge (and nearly zero experience), you have three classes of packages: 1. Those that just compile, link and ship -- these should crosscompile automatically if using up-to-date, correctly setup autoconf/automake/libtool build machinery, etc. 2. Those that also need build-time utilities (prime example: the Linux kernel) -- these need to know they must use the host CC for building local tools, and not the cross-compiler. Interestingly enough, I can't find a proper way to get access to the correct host compiler... Don't tell me I am supposed to run two configure scripts, one in "force non-crosscompiling mode, but somehow tell the built tools the will-cross-compile-for arch" to build the compile-time tools, and another to do the actual app cross-compilation. Yuck, this is stupid. 3. Those packages that modify the build depending on data gathered from the host system, or that use tools in the host system that generate non architecture-agnostic data but are not cross-compiling aware -- these often need to be extensively modified to cross-compile. autoconf can be your enemy re. (3). Tests that are not just a "locate lib" or "test compile but do NOT run" will often kill cross-compilation. > is to just issue a 'dpkg-buildpackage -aHOST ' on every single one of > them and get a .deb file(s) Interestingly, the notion of BUILD and HOST in dpkg-buildpackage(1) is opposite to that on up-to-date autotools. Oh well. They should have just called it host, target and target-of-target instead of host, build and target. > As I've indicated earlier, Debian is in fact quite close to this wet > dream of mine, it just misses on a Is it really? I'd be pleasantly (and very) surprised if that worked for a high percentage of our packages given (2) and (3) above. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
On Fri, 2006-03-10 at 00:30 +0100, [EMAIL PROTECTED] wrote: > Hi, > > Ah, good. But your script misses some warnings: > > oss.c:83: warning: incompatible implicit declaration of built-in function > 'strdu > > because of "incompatible" and "built-in". Please fix ;) Thanks Samuel, Can you point us to the log file this is from? David & I aren't subscribed, so please CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356289: ITP: listen -- a music management and playback for GNOME
Package: wnpp Severity: wishlist Owner: Julien Valroff <[EMAIL PROTECTED]> * Package name: listen Version : 0.3.1 Upstream Author : Mehdi Abaakouk <[EMAIL PROTECTED]> * URL : http://listengnome.free.fr/ * License : GPL Description : a music management and playback for GNOME Listen is a GNOME music player that support mp3, ogg, mpc, ape, mp4 with Media library support, full drag & drop, playlist management. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
pe, 2006-03-10 kello 21:49 +0100, Adrian von Bidder kirjoitti: > /me is trying to imagine the Debian project's members trying to agree on an > enemy... Open RC bugs. Go to http://bts.turmzimmer.net/details.php, pick one, hate it to death. Sleep well. -- C is the *wrong* language for your application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
On Thursday 09 March 2006 18:41, Amaya wrote: > ... focus on attacking Ubuntu Ah, yes, we need an enemy so we can unite against it. Old-fashioned tactics, proved to work. -- vbi /me is trying to imagine the Debian project's members trying to agree on an enemy... -- One picture is worth 128K words. pgpJBIKWBa8ay.pgp Description: PGP signature
Re: For those who care about stable updates
ObIntro: I add my thanks to all the others' On Thursday 09 March 2006 14:38, Gustavo Franco wrote: > What's wrong with us ? I just read some messages with a "no Martin, > can we revert it?", it seems that the default reply is "ok Martin, see > you, thanks.". > > It's volunteer work, he's free to do whatever he wants and spend his > time with more pleasant tasks, but when will we try to solve some of > the real problems we have instead going through the easy way that is > "ok, who's going to take that task?". It's clear that the new stable > maintainer or group will have at least some of the current problems. > Don't you care ? I feel the 'when are we going to solve the real problems' have been discussed so many times before (ftpmasters, DSA, RM, security team perhaps, NEW queue processing, probably at least the last 4 DPL elections, ...). Always, at least some of the people involved have not joined the discussion. As somebody who was involved in trying to solve such a problem without involving the affected people, I ask you to think again: what do you think would really change anything? A solution that will work needs to involve the affected people. A "solution" being worked out By The Masses(tm), involving heated flamewars etc. etc. will most certainly not work. It's sad, yes, but I think it's just the way people work. Debian is a city now, not a village anymore - lots of people know lots of other people not very well or not at all. This probably includes people in important functions, although the various face to face meetings have improved this in some areas. Right now we're trying to cope with city problems using village methods - has not worked in the Real World, won't work in an online community. cheers -- vbi (I don't have sociological, economical or historical background at all, so the above is pure pub-level opinion utterance. YMMV.) -- This bug is quite subtle and only happens in a very interesting situation where a real-time threaded process is in the middle of a coredump when someone whacks it with a SIGKILL. -- Bhavesh P. Davda, describing a Linux kernel bug pgp7krqWJcz40.pgp Description: PGP signature
Re: For those who care about stable updates
On 3/10/06, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, Mar 09, 2006 at 10:38:51AM -0300, Gustavo Franco wrote: > > What's wrong with us ? I just read some messages with a "no Martin, > > can we revert it?", it seems that the default reply is "ok Martin, see > > you, thanks.". > > > It's volunteer work, he's free to do whatever he wants and spend his > > time with more pleasant tasks, but when will we try to solve some of > > the real problems we have instead going through the easy way that is > > "ok, who's going to take that task?". It's clear that the new stable > > maintainer or group will have at least some of the current problems. > > Don't you care ? > > Which problems? The problem where they ignore the ftpmaster trying to > coordinate certain archive changes with the point release to make future > point releases easier, the problem where they ignore the critical bugs that > have been filed on the security NMU of sudo that was done with a patch that > the maintainer disagrees with, the problem where they repeatedly make a very > public stink whenever they were unable to resolve a conflict with other > ftp/DSA members...? Maybe the problem where the ftpmasters failed to communicate their reasons and even when they're right it seems that they're wrong?! Please Steve, i don't want to take your time and discuss with you, my opinion is clear and it would be better if a ftpmaster or ftp assistant spend some minutes replying Joey here. If it was already done, i think i missed the message. > Well, no, those seem to all be problems specific to Joey and his approach to > the situation. I don't see any reason at all why we should assume that a > new SRM will fall victim to the same destructive cycle. I guess maybe if > you buy the idea that this is an ftpmaster conspiracy, then you might think > that any new SRM will have the exact same problems being able to get a point > release out; but the truth is always more complicated than that. Joey does > a lot of great work for Debian, but that doesn't make him a saint; and when > a group of people are having problems working together as a team, sometimes > the best answer really is for one of them to move on. Don't you see that the people that are moving on, are always from the same side of the discussion (the side that speaks) ? By the way if Joey isn't a saint (i'm almost sure he isn't), the ftpmasters aren't too. There's no conspiracy, it's just the way the things and decisions are handled that isn't always clear, i'm against a yet another formal procedure but when a Debian developer in a position listed in our organizational structure page resigns sending a announce criticising the work of a group listed there too, that group should came with a response. The "we don't care" approach can't be the default response IMHO. Isn't it strange that a ftp master or assistant never (or at least for quite some time) resigned upset by the critics or being blocked by someone else? -- stratus
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
On Thursday 02 March 2006 04:46, Jaldhar H. Vyas wrote: > Package: libacme-brainfck-perl > Provides: libacme-brainfuck-perl Ah, and back to the time when some words where magic and caused burn marks on the paper around the ink. I never have and probably never will see why some people find 'f*ck' less offensive than they find 'fuck'. Or - on air - beep. Language is mostly about transporting content, and a beep sound or written f*ck conveys exactly the same meaning as a plain 'fuck' (or, in the case of sound, a beep stresses the fact that a dirty magic word was said all the more.) But back to business, don't mind me -- vbi (.sig moderated to avoid dirty filters, of course.) -- featured product: Spam*ss*ssin - http://spam*ss*ssin.org pgpJ8QTpG447O.pgp Description: PGP signature
Improving keyring maintenance (was Re: question for all candidates)
If you don't want to read the rant, skip to the bottom where I volunteer to help Anthony Towns wrote: >In the mail to the DPL I mentioned above, James outlined three fairly >significant technical changes that could be implemented to make the >job easier, and could be done by anyone, without requiring any special >priveleges; Why on EARTH didn't he outline these needed changes to *debian-devel*, or put them on the Debian wiki, or in some other way let *everyone* know what needed to be done? Nobody's going to volunteer to do them if nobody knows *what they are*. On the other hand, if he publicized what he needed, I promise he'd get volunteers writing code almost immediately. *This* is what's wrong with James's communication skills. Apparently it's also a problem with the *DPL*, who could equally well have publicized the same needed changes. --- Anyway, thank you for finally describing the issues (in http://lists.debian.org/debian-vote/2006/03/msg00275.html). If I could be pointed to the existing scripts for managing debian-keyring.gpg, I can start work on making them componentised, simple, obviously correct and secure, and fast. That sort of work is what I'm especially good at. I could start an alioth project for "keyring-manangement-scripts" if anyone else is interested in working on this. Hmm, this is going off topic for -vote Replies to -devel please. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: conffile purging and maintainer scripts
Thomas Hood <[EMAIL PROTECTED]> writes:
> Roger Leigh wrote:
>> Until last month, dpkg "forgot" about conffiles which were removed or
>> moved on package upgrade. As a consequence, maintainers had to
>> remember to purge these conffiles "by hand" in the package postrm
>> script.
>
> I just want to highlight the word "these" above in order to reduce the
> possibility of confusion.
>
> Postrms should not delete files that are currently conffiles of the package.
> dpkg takes care of deleting such files at the right time.
>
> If a file /etc/foo was formerly a conffile of the package but no
> longer is so then /etc/foo should be dealt with in the preinst or
> postinst. ("Dealing with it" has to take into account both the old
> and the new behavior of dpkg with respect to disappearing conffiles.
> I speak vaguely here because I haven't looked into the new
> behavior.) If it isn't dealt with there then it might be
> appropriate to delete it in the postrm, but not if there is reason
> to suspect that some other package is now using /etc/foo.
How about this as a start?
This should be "safe" in that it won't remove a conffile if another
package (or itself) takes ownership of it. It also handles removal of
the dpkg cruft, but I'm not sure that's always appropriate, since dpkg
should handle it, at least for the new dpkg behaviour; this only
caters for the old.
Call in a postrm like this:
rm_conffile("/etc/my/conffile")
# Remove a conffile which has been forgotten by dpkg
# If the file does not exist, or is owned by any package, do not remove it.
rm_conffile() {
CONFFILE="$1"
if [ -f "$CONFFILE" ]; then
if dpkg -S "$CONFFILE" >/dev/null 2>&1; then
:
else
rm -f "$CONFFILE"
rm -f "${CONFFILE}.dpkg-old"
rm -f "${CONFFILE}.dpkg-new"
rm -f "${CONFFILE}.dpkg-dist"
fi
fi
}
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
pgp9Yl1PKaetr.pgp
Description: PGP signature
Re: conffile purging and maintainer scripts
Roger Leigh wrote:
> Until last month, dpkg "forgot" about conffiles which were removed or
> moved on package upgrade. As a consequence, maintainers had to
> remember to purge these conffiles "by hand" in the package postrm
> script.
I just want to highlight the word "these" above in order to reduce the
possibility of confusion.
Postrms should not delete files that are currently conffiles of the package.
dpkg takes care of deleting such files at the right time.
If a file /etc/foo was formerly a conffile of the package but no longer is so
then /etc/foo should be dealt with in the preinst or postinst. ("Dealing with
it" has to take into account both the old and the new behavior of dpkg with
respect to disappearing conffiles. I speak vaguely here because I haven't
looked into the new behavior.) If it isn't dealt with there then it might be
appropriate to delete it in the postrm, but not if there is reason to suspect
that some other package is now using /etc/foo.
> 1) sarge -> etch upgrades
> -
>
> In order to handle upgrades from sarge correctly, maintainers will
> still have to manually remove conffiles in their maintainer scripts
> until at least etch+1 by my reckoning. Is this correct?
Again, postrms should not remove files that are currently conffiles.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian developer
On Friday, 10 March 2006 15:41, Lars Roland wrote: > You could subscribe to debian-mentors and start crafting a package. > Even though Debian has a impressiv amount of packages there are still > some major ones left (mpich2, pvfs2, trac...). trac is in -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: <[EMAIL PROTECTED]> | Debian: <[EMAIL PROTECTED]> pgpNqSaBkDnq9.pgp Description: PGP signature
Re: debian developer
Hi, > Jump in and start doing something for Debian. Whether that is finding > fixes for open bugs in our BTS that do not have patches yet, writing > documentation, translating stuff that needs to be translated, or > packaging software that needs to be packaged (or help package software > where the maintainer asks for help), is up to you. You can ask on > debian-mentors if you need more help (this isn't really a mailinglist > for beginner-level questions relating to debian development; > debian-mentors is) > > If you do this well enough, people you cooperate with (your sponsor, > other translators, etc) will most likely be willing to advocate you. ok, I understand this is the wrong list and I have now a good one, which is debian-mentors. There's also a IRC channel so I will cope now on my own. Thank's for you statement's I was subscribed to debian-devel and I thought it's the right place to ask the question. Sorry for being offtopic ! -- Best Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian developer
Hi, Mark... On Friday 10 March 2006 15:27, Mark Walter wrote: > I want to step in to be a debian developer. Great to hear that. > While processing the new maintainer's guide I need to cross checked > boxes to apply. > > Two of them are not true for me at all and I can't apply as a developer > :-( > > Here are the two point's: > > *** > If you intend to package software, do you have a Debian package in the > archive through a sponsor? And if you intend to do other things (e.g. > port Debian to other architectures, help with documentation, Quality > Assurance or Security), do you have experience in those things and have > already participated in such activities for Debian? > > *** > Has an existing Debian developer agreed to be an advocate and verify > your application > > Here is my question: > > Can anybody help to me to satisfy the demand for the two point's as I'am > interested to be a debian developer ? Bear with me but your question sounds to me like "I have not yet contributed to Debian but rather have been a user and now want to become a DD as soon as possible". If you want to become a Debian Developer it's helpful (if not mandatory) that you are already "part of the community" in some way. Contributing to Debian doesn't necessarily mean you need to be a Debian Developer. You can maintain your own packages through a sponsor, provide help on alioth projects, provide patches for documentation, provide translations to further languages you may know or proofread translations, ... At some point you may want to do the uploads yourself (without the help of a sponsor), participate in votings and get access to Debian's machine park for testing. Then it's a good time to apply for developership. But it's not mandatory for contributions. The more you already do for Debian the easier it is for you to become a Debian Developer. Even if you enter the so called "new maintainer's process" you will still need to show that you can e.g. maintain packages and have a good understanding of the gears inside. If you already have proof of such contributions - great. It will take time one way or the other. The second question about getting an advocate will probably be trivial once you work with a few people because they can easily decide that your skills are welcome to Debian. The advocate can only be someone who knows you (virtually). So you better ask them then. I still mean that your contribution is mostly welcome. Just that the contribution and the fun of contributing itself should perhaps be more the center of attention than wearing fancy "I'm a DD" pants. If you get me. :) Kindly Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
conffile purging and maintainer scripts
Until last month, dpkg "forgot" about conffiles which were removed or moved on package upgrade. As a consequence, maintainers had to remember to purge these conffiles "by hand" in the package postrm script. 1) sarge -> etch upgrades - In order to handle upgrades from sarge correctly, maintainers will still have to manually remove conffiles in their maintainer scripts until at least etch+1 by my reckoning. Is this correct? 2) dpkg cruft - In addition to the conffiles, there may also be $conffile.dpkg-old, $conffile.dpkg-new and $conffile.dpkg-dist (and other?) files as well. Should these be purged along with their conffile? Who bears the responsibility for purging these? Does the new dpkg handle this? (It didn't seem to when I tried it.) Should it? Should maintainer scripts remove these in addition to the conffile itself? Currently, most maintainer scripts do not, with some removing perhaps .dpkg-old only. This is inconsistent, and it would be nice to have some guidelines or recommendations about how maintainers should handle conffile cleanup, so that maintainer scripts could do it more reliably and uniformly. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgptdpkIsdG6D.pgp Description: PGP signature
Re: debian developer
On Fri, Mar 10, 2006 at 03:27:23PM +0100, Mark Walter wrote: > Hi all, Hello. > I want to step in to be a debian developer. That's rather question for debian-mentors mailing list. > While processing the new maintainer's guide I need to cross checked > boxes to apply. > > Two of them are not true for me at all and I can't apply as a developer :-( > > Here are the two point's: > > *** > If you intend to package software, do you have a Debian package in the > archive through a sponsor? And if you intend to do other things (e.g. > port Debian to other architectures, help with documentation, Quality > Assurance or Security), do you have experience in those things and have > already participated in such activities for Debian? > > *** > Has an existing Debian developer agreed to be an advocate and verify > your application > > Here is my question: > > Can anybody help to me to satisfy the demand for the two point's as I'am > interested to be a debian developer ? > > What can I do to arrive the point's mentioned above ? Point 1. Find some useful software that isn't already packaged for Debian and package it. Or adopt some unmaintain one. You can take a look at http://www.debian.org/devel/wnpp/ for that. Then ask on debian-mentors mailing list for upload of it to the archive. Point 2. Assuming you'll be doing your job well maybe your sponsor will agree to be your advocate. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: debian developer
On 3/10/06, Mark Walter <[EMAIL PROTECTED]> wrote: > Here is my question: > > Can anybody help to me to satisfy the demand for the two point's as I'am > interested to be a debian developer ? Ahh the the cool factor of having a Debian email address (not that i have one). > > What can I do to arrive the point's mentioned above ? > You could subscribe to debian-mentors and start crafting a package. Even though Debian has a impressiv amount of packages there are still some major ones left (mpich2, pvfs2, trac...). Also check this article: http://programming.newsforge.com/article.pl?sid=05/01/28/1618201 it has some extended info
Re: debian developer
On Fri, Mar 10, 2006 at 03:27:23PM +0100, Mark Walter wrote: > Hi all, > > I want to step in to be a debian developer. > > While processing the new maintainer's guide I need to cross checked > boxes to apply. > > Two of them are not true for me at all and I can't apply as a developer :-( > > Here are the two point's: > > *** > If you intend to package software, do you have a Debian package in the > archive through a sponsor? And if you intend to do other things (e.g. > port Debian to other architectures, help with documentation, Quality > Assurance or Security), do you have experience in those things and have > already participated in such activities for Debian? > > *** > Has an existing Debian developer agreed to be an advocate and verify > your application > > Here is my question: > > Can anybody help to me to satisfy the demand for the two point's as I'am > interested to be a debian developer ? > > What can I do to arrive the point's mentioned above ? Jump in and start doing something for Debian. Whether that is finding fixes for open bugs in our BTS that do not have patches yet, writing documentation, translating stuff that needs to be translated, or packaging software that needs to be packaged (or help package software where the maintainer asks for help), is up to you. You can ask on debian-mentors if you need more help (this isn't really a mailinglist for beginner-level questions relating to debian development; debian-mentors is) If you do this well enough, people you cooperate with (your sponsor, other translators, etc) will most likely be willing to advocate you. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian developer
Hi all, I want to step in to be a debian developer. While processing the new maintainer's guide I need to cross checked boxes to apply. Two of them are not true for me at all and I can't apply as a developer :-( Here are the two point's: *** If you intend to package software, do you have a Debian package in the archive through a sponsor? And if you intend to do other things (e.g. port Debian to other architectures, help with documentation, Quality Assurance or Security), do you have experience in those things and have already participated in such activities for Debian? *** Has an existing Debian developer agreed to be an advocate and verify your application Here is my question: Can anybody help to me to satisfy the demand for the two point's as I'am interested to be a debian developer ? What can I do to arrive the point's mentioned above ? -- Best Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sitebar package is stalled
Hello list, Any of you know about the sitebar package? The upstream version has evolved and the debian package seems to be stalled since a year ago. I tried contacting the maintainer. Does anybody know him? Thanks, Josep SERRANO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question for all candidates
[Ways to improve keyring maintenance] On Thu, 2006-03-09 at 23:25 +1000, Anthony Towns wrote: > The second was to get rt setup to, uh, track requests -- it's waiting > on the first thing (since rt sends auto-replies, and auto-replies to > spam is bad, mmmkay), and possibly also lacks a debian.org machine > that can be its host. I might be missing something obvious, but why do we need a separate rt installation, with a debian.org machine to be found, and a spam problem to be tackled? We have the BTS, using that would eliminate point two entirely and alleviate most of point one, since spam fighting can be done in one place. There could be some feature missing from the BTS, but I can't think of one that's required for this task. And if there is one, wouldn't it be a better investment to add that possibility to our current BTS than to implement a parallel infrastructure? Thijs signature.asc Description: This is a digitally signed message part
Re: Question for all candidates: handle debian-admin more openly
Let's move this to elsewhere than -vote for technical discussion, d-ppc and d-ppc64 are good places for this. On Fri, Mar 10, 2006 at 02:21:12AM -0800, Steve Langasek wrote: > On Thu, Mar 09, 2006 at 01:03:47PM +0100, Sven Luther wrote: > > > Are bruckner and voltaire overloaded or do they lack services the > > > developers > > > need? > > > The release team has called for a multi-arch implementation to support > > powerpc64 userland over the biarch situation. This calls for a machine > > capable > > of building *and running* powerpc 64 code, which is not the case of existing > > powerpc 32bit machines. > > Er, the demand for powerpc64 userland support did not come from the release I stand corrected. It is a pre-requisite of having a multi-arch powerpc64 userland. The release team ruled against a biarch powerpc64 userland though, which would not have needed an extra machine. So, if we want a powerpc64 userland for etch, then having a 64bit powerpc buildd is needed. I know though that you ruled this only as a tentative optional release goal, not a strong one. > team; and the problems with building powerpc64 binary packages on a powerpc > system aren't specific to multiarch (obviously -- since multiarch hasn't Well, conceptually, there is no real difference between biarch and multiarch, despite the claims of the multiarch proponent who believe in moving libs around and everything. The real issue here is if you build a the packages for both bitness in a single arch, thus disabling the 64bit specific test runs when built on a 32bit machine, or putting all the 64bit stuff in its own arch. > actually happened yet, and we've been having problems building glibc on > voltaire since last year). Multiarch just happens to be (IMHO) the best /me builds glibc fine on my powerbook, so i wonder about this one, haven't done so in a long time though. Where is glibc built then ? > technical approach to building extra packages for targets such as ppc64. I agree with you that being able to install powerpc-arch packages on 32bit and both powerpc and powerpc64 arch packages on 64bit, and build all 64bit stuff in a 64bit arch is easier on the packaging work. Not sure if we should allow to install powerpc64 packages on 32bit powerpc, in order to be able to build 64bit packages on 32bit machines, or just build 64bit non-packaged apps on 32bit machines though. This kind of defeats the benefits of the multi-arch proposal though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
On Wed, 8 Mar 2006, Andreas Tille wrote: Thanks fo the foreward but I'm afraid we might be on the wrong track. I downgraded sysvinit on one of the machines (by chance the apm based) to apt-cache policy sysvinit sysvinit: Installed: 2.86.ds1-4 Candidate: 2.86.ds1-12 Version table: 2.86.ds1-12 0 499 http://ftp.de.debian.org testing/main Packages 50 http://ftp.de.debian.org unstable/main Packages *** 2.86.ds1-4 0 100 /var/lib/dpkg/status The behaviour is the same as for 2.86.ds1-12. :-( Are there any more hints what might stop the computer from doing cleeen halt / reboot than apm/acpi or sysvinit. I just tried linux-image-2.6.15-1-686 version 2.6.15-7 this morning - no change. I' can't imagine that every of my boxes with the current testing shows the same behaviour but nobody els has this problem and there is no way to fix this. If I would have at least a hint what package might be guilty for the problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problem with ISA SB16 sound card
sarge's default kernel can't use my SB16! I have used my SB16 ever since kernel 2.0, 2.2, and 2.4 in woody. They all work. But with sarge's kernel 2.4, it can't work. When I modprobe sb, it complains no such device. Does sarge's kernel 2.4 support non-PNP ISA card? Why does sarge always try to use ISA-PnP before loading sb? sb16 can be nonPNP! I guess my SB16 maybe is a clone. but kernel 2.4 of woody can use my SB16! What's the problem??? Thanks!!! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
Le jeudi 09 mars 2006 à 23:51 +0100, Wouter Verhelst a écrit : > Yeah yeah, the project sucks. Whatever. Say, Josselin, why aren't you a > DPL candidate? Given the list of known candidates, I considered being a candidate myself, just like Bill, but I don't have the time to assume such a position. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
