Re: master's mail backlog and upgrade time

[James Troup]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Six days ago I discovered that one of the Debian system
> administrators had made a deliberate and highly unusual
> configuration change which predictably broke mail from or via master
> to:

Err, no.  Mail was _already_ bouncing, but after reaching the retry
maximum.  The change did not change the end result, only when it
happened.

> No-one had contacted me, or anyone else affected. 

The change was made roughly less than 24 hours before your first post
to debian-devel.  There wasn't actually all that much time to contact
you in.

> but in any case immediately I found out about the situation I
> arranged matters so that master should no longer have any difficulty
> talking to chiark.

Err, no you haven't.  In
<[EMAIL PROTECTED]> posted
on Sat, 19 Nov 2005 15:39:36 +, you've asked chiark users to
individually change their config to ensure chiark won't DoS master.
Until it's confirmed that all those users have done so, it's not fair
to say master will not have any difficulty talking to chiark.

And this still relies on per-user config rather than being a global
change.  Which means the next time a chiark user gets a debian.org
account but neglects to perform the necessary incantation, master will
once again be DoSed by chiark.

> I also immediately notified debian-admin of these facts and have not had:

Err, no you didn't.  You mailed debian-devel, and THREE DAYS LATER
mailed debian-admin.  That is not immediate.

>  * Correction of the broken configuration on master

[EMAIL PROTECTED]:~$ grep chiark /etc/exim4/exim4.conf
[EMAIL PROTECTED]:~$

And it's been like that for several days.

>  * An apology for the lack of communication or a promise to do better

Speaking of doing better, could you please actually fix chiark?
Because it's STILL firewalling master

> This situation is intolerable and must be rectified forthwith.

With all due respect, your attitude is intolerable and should be
rectified forthwith.

> If the Debian system administrators are too busy to deal with this
> then I would be happy to help.

No thanks.

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: When will bash 2.01 be packaged?

[James Troup]

[EMAIL PROTECTED] (Mark Baker) writes:

> > Guy Maor is the current maintainer of the "bash" package. However,
> > he told us that he is offline for about 4 weeks. So I think
> > someone else should grab it and upload a non-maintainer (interim)
> > release.
> 
> Is that necessary just to work round a (long standing) bug in
> another program?

I don't care in the least about netrape, but one good reason for doing
a non-maintainer release of bash would be to build it against glibc.
I'm sure I'm not the only one who needs a libc6-based libreadline for
some of my packages.

Also, I'd imagine there were other bugs fixed in 2.01.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Problem: bash 2.01 dumps core!

[James Troup]

"Christian Hudon" <[EMAIL PROTECTED]> writes:

> I hit a  small problem while installing packages from
> Incoming... Bash now dumps core on startup. And one of the
> interesting side effects of this is that I can't install/remove
> packages anymore:

I suspect the problem was when you installed the new libreadline2,
somehow either ldconfig wasn't run or for some reason your bash
wouldn't work with the new libreadline even after ldconfig was run.

The critical section, as far as I can tell, is when installing the new
libc5 based libreadline from /lib into /lib/libc5-compat and keeping a
working /bin/sh (bash, understandably, doesn't like it when you move
it's libreadline to a different directory and don't tell the dynamic
linker).  The libreadline2_2.1-2.1 postinst is a C wrapper which runs
ldconfig since a shell script obviously wouldn't work.  Perhaps the
wrapper failed for some reason?  (Right now, I *really* wish dpkg kept
logs)

I've moved the new bash package out of Incoming/ and into ~troup/ on
master until I can get this sorted out.

I really don't understand what went wrong, I upgraded a machine from
unstable to bash-2.01 without problems, as did "netgod".  And from the
fact that two developers uploaded libreadlineg2 dependent packages, I
assume that it didn't hose their machine either.  I'm truly sorry it
did for you :-(

I'll have a look at the info you've written here, and ask anything
else I need in private mail.

-- 
James :(


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: [klee@mit.edu: Bug#10795: makefiles for nethack are i386-specific]

[James Troup]

Paul Haggart <[EMAIL PROTECTED]> writes:

> Okay, what's the recommended solution for this .. other than porting
> nethack over to use libc6 (which can't be done at the moment because
> of the lack of a libc6 xpm library).  How does one detect the
> architecture of the machine being used?

Cut and pasted from bash_2.01-0's debian/rules, but enough to get the
idea? :-

ARCH = $(shell dpkg --print-gnu-build-architecture)

make [ ... ] CC=$(ARCH)-linuxlibc1-gcc [ ... ]

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libreadlineg2 missing

[James Troup]

Michael Meskes <[EMAIL PROTECTED]> writes:

> How on earth is it possible to get packages depending on
> libreadlineg2 into hamm when there is no package libreadlineg2 in
> the archive or in Incoming?

I removed libreadlineg2 and all other bash_2.01-0 related files from
Incoming/ after they appeared to trash Christian Hudon's computer.

I still don't know why, and am waiting on him to test something for
me.

At the moment I'm between the devil and the deep blue sea, I don't
want to install a package which could trash people's computers into
the distribution, but if I don't there are two packages with
unsatisfied dependencies.
 
> At least I couldn't find the readline package.

It's in ~troup/ on master for now.  Caveat; Use at your own risk, the
package worked fine for me and someone else but not for Christian.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dc and bc in Important?

[James Troup]

John Goerzen <[EMAIL PROTECTED]> writes:

> It seems to me that dc and bc aren't vital to the workings of a
> system (when I deselect them, dselect doesn't warn about any
> dependencies), yet they are in Important.  Why?

Because they match the first definition of Important in Policy (see
below).  When I released my first version of bc/dc I downgraded them
to Optional by mistake and someone complained; that's obviously one
person who agrees with me.  Does anyone else think bc/dc should be
downgraded? (If so, why?)

``Important programs, including those which one would expect to find
on any Unix-like system. If the expectation is that an experienced
Unix person who found it missing would go `What the F*!@<+ is going
on, where is foo', it should be in important. This is an important
criterion because we are trying to produce, amongst other things, a
free Unix.'' (3.1.4.1 of debian-policy 2.1.3.3)

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Policy wrt Important (was Re: dc and bc in Important?)

[James Troup]

John Goerzen <[EMAIL PROTECTED]> writes:

> By the current definition of Important:
>  * Sendmail should be there instead of smail since people expect
>sendmail

People expect a mailer.  Debian's default mailer is exim^H^H^H^Hsmail;
that's a deliberate decision to override the commonly expected tool,
in favour of something which Debian considers better. (AIUI)

>  * dpkg-dev should not be there since no experienced user of another
>Unix would expect it
>  * lilo should not be there because lilo is not part of UNIX

Did you actually read the definition of important in Policy or just
the part I included in my response?  Here's the rest of it :-

``Other packages without which the system will not run well or be
useable should also be here. This does not include Emacs or X11 or TeX
or any other large applications. The important packages are just a
bare minimum of commonly-expected and necessary tools.''

Now correct me if I'm wrong (I don't own an i386, and don't boot the
ones I use) but lilo or some other booter seems pretty Important to
me.

>  * gcc should be in Important because everybody expects a C compiler
>  * libc5-dev should be there because everybody expects working
>header files
>  * make should be there, I expect a working make in any Unix

"bare minimum" doesn't extend to a compilation environment.

>  * lpr should be there, it is standard with just about any Unix

or to printing, IMO.

>  * netbase and netstd should both be there, they are standard
>on Unix

That's much more valid, perhaps they should be important, I don't
know.

>  * csh/tcsh should be there (again, standard on various Unices)

the "bare minimum" is provided by sh.  Adding csh/tcsh would be
overkill, IMO.

> Basically, it seems that this policy doesn't quite apply correctly.

I totally agree with what Galen said: the policy is a guide not
something to be applied to the letter, and IMO a good one and on the
whole most maintainers have got it right.  If you don't think so bring
it up with the individual packages.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: be careful with Replaces, please

[James Troup]

Yann Dirson <[EMAIL PROTECTED]> writes:

> > BTW, is there a particular reason that e2fsprogs got renamed to
> > e2fsprogsg?  This seems to be the biggest chance to completely
> > screw over someone's system in all of Debian now.
> 
> Yes: e2fsprogs used to contain shared libs, on which dump and quota
> depend. Thus, e2fsprogs was assumed to be a package with libc5 libs,
> and I could not keep the name, without breaking dump and quota on a
> hamm upgrade.

Uhh, why not just conflict with suitable versions of dump and quota?
Changing the name is an absolutely *stunningly* bad idea IMHO.

This really should have been discussed before you implemented it
(apart from anything else you've made a new package essential so
discussion is required by policy).

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: master's Incoming and 2.0 release date

[James Troup]

"Eloy A. Paris" <[EMAIL PROTECTED]> writes:

> I know Guy is having problems with his Internet connection but
> wouldn't it be nice if we had more people taking care of Incoming?

Guy is back in some form, at least he just dealt with a whole host of
bugs filed against ftp.debian.org.

Martin and I have offered to help Guy with Incoming and he's
indicated[1] that when he gets back, he'll take us up on that offer.
(We {c,w}ouldn't just start barging in there and start doing stuff
for, hopefully, self-evident reasons)

[1] http://www.debian.org/Lists-Archives/debian-devel-9711/msg00919.html>

-- 
James - {,}.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: predepends on libc6?

[James Troup]

[EMAIL PROTECTED] (Richard Braakman) writes:

> However, chapter 12 of the packaging manual says:
> 
>  Secondly, your package should include the symlink that ldconfig
>  would create for the shared libraries.
>
> and:
> 
>  If you do the above your package does not need to call ldconfig in
>  its maintainer scripts.

The packaging manual is wrong; this is a long standing bug.
 
> Why is it calling ldconfig?

Because it's the Right thing to do.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: predepends on libc6?

[James Troup]

[EMAIL PROTECTED] (Richard Braakman) writes:

> > The packaging manual is wrong; this is a long standing bug.
> 
> Can you explain, or refer to a bug number that explains it?

No.  I have neither the time nor the inclination to trawl through the
hundreds of bugs filed against dpkg.

> It's not very good to have incorrect instructions for shared
> libraries at a time when we're doing a massive shared-library
> upgrade.

Most of the libraries have done long ago, and the packaging manual has
been wrong since before the release of bo.
 
> > > Why is it calling ldconfig?
> > 
> > Because it's the Right thing to do.
> 
> Heh.  That argument only convinces me if I already know why it's
> Right :-)

Take a look at the postinsts for every package with a shared library.
You seem fond of statistics, how many *don't* run ldconfig?

> What does the ldconfig do, if the symlinks are already there?

RTFM.  Also, try it and see.  I dare you to take a bo machine, rebuild
hamm's bash and remove the C postinst which runs ldconfig and then
install the resultant debs.

(Hint: it tells the dynamic linker that the library is there)

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: predepends on libc6?

[James Troup]

[EMAIL PROTECTED] (Richard Braakman) writes:

> > Take a look at the postinsts for every package with a shared
> > library.
> 
> I did.  But why assume they are correct?  Someone reports a bug and
> says "package should run ldconfig", maintainer says "okey I'll do
> that".

I maintain and have done non-maintainer release for several shared
library packages, and I *know* it did not happen that way.

And please don't judge other maintainers by your own standards, I for
one, won't add gratuitous program calls to my postinsts just because
someone said I should.  Perhaps you would, that doesn't mean that 90%
of the shared library maintainers would.

I also think someone might have noticed by know if this vast majority
of shared libraries were doing it wrong; don't you?

> > You seem fond of statistics, how many *don't* run ldconfig?
> 
> Of the library packages installed on my system, eight.  They are
> comerr2g, e2fslibsg, fakeroot, ftplib, libgtk1, libmpeg1, libpaperg,
> and procps.

IIRC, Che's knows about libgtk1 and libmpeg1 and will fix them.
e2fsprogs is broken in so many ways at the moment, it doesn't
surprises me in the slightest that it also fails to run ldconfig.

> If these packages are doing something wrong, then we have a problem.

A bug, dear, the word is a bug.

> So far I have not had any problems with them.

Others have. RTFBA (#14212). BTW, even David, the ld.so author &
maintainer, says the packaging manual is wrong; are you *so* confident
you're right and everybody else is wrong that you're going to tell him
he's wrong too?

I give up.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: predepends on libc6?

[James Troup]

[EMAIL PROTECTED] (Richard Braakman) writes:

> So why did you add the call to ldconfig?

Because it's necessary.  Duh.  As I say, try removing it from
libreadline2's postinst.  Why do you think the upgrade of bo -> hamm
is still so problematic?  It's because we don't have a method for
selective immediate configuration, so during upgrade of libreadline2
and libgdbm1 until ldconfig is run perl and bash are fubar.  If you
were right, the upgrade to bo -> hamm would be much easier (and Scott
would be out of a job ;-).

> So far you have not given any reasons.  In fact, you seem to expect
> me to take your word for it, which is exactly what you object to
> here.

I expect you to take the word of David Engel on it, yes.  I also
expect you to take into consideration the bug reports filed against
packages which didn't do it.  Am I lieing?  Are they all lieing?  Did
they make those bug reports up in some big conspiracy against your
precious packaging manual?

> > I also think someone might have noticed by know if this vast
> > majority of shared libraries were doing it wrong; don't you?
> 
> Not if the call is merely unnecessary.

Oh for god sakes' if you think it is, please prove me wrong.
Categorically show that it is *never* necessary to run ldconfig.

I dare you.

> > BTW, even David, the ld.so author & maintainer, says the packaging
> > manual is wrong; are you *so* confident you're right and everybody
> > else is wrong that you're going to tell him he's wrong too?
> 
> I am not confident that I am right. 

Woo woo.

> I am not confident that the packaging manual is wrong. 

Why is it you are so obsessed with the packaging manual?  Are you so
convinced it's never wrong?

> Confidence is what one has after examining the arguments, of which
> you have not provided any.

Oh, FFS, neither have you.  What I have done is pointed you to the
fact that over 90% of shared libraries do it, that many bugs have been
filed against packages which didn't do it, and that the damn ld.so
author and maintainer says it's the right thing to do. *You* have
whined about the packaging manual saying it's not right.  Now tell me,
who has presented less in the way of evidence?

> David Engel said: (#14212)
> | The policy manual is wrong.  ldconfig should be called from the
> | postinst script.  This is the only way to get the new library listed
> | in /etc/ld.so.cache, which is a must if the library isn't in /lib or
> | /usr/lib.
> 
> Obviously, this does not apply to libraries which install in /lib or
> /usr/lib, such as libc6.

hilfy|18:48:39 ~ $dpkg -c 
/debian/hamm/hamm/binary-i386/interpreters/libguile2_1.2-3.deb
[...]
lrwxrwxrwx root/root 0 1997-10-30 06:48 usr/lib/libguile.so.2 -> 
libguile.so.2.0.0
-rw-r--r-- root/root396892 1997-10-30 06:48 usr/lib/libguile.so.2.0.0   


Oh really?  (#14212 is against libguile2)

> > I give up.
> 
> So soon?  We have strayed quite a way from my original question:
> what is it that the libc6 postinst does, that makes it necessary for
> gzip to pre-depend on it?

I wasn't responding to that, I was responding to your bogus defence of
the packaging manual.   

> If libc6 could be restructured so that this is not necessary, then
> we can lose a whole lot of predependencies in one swoop.

You're drastically missing the point (but hey, what's new).  If gzip
only depends on libc6 it's entirely possible for a libc6-based gzip to
be unpacked *before* libc6.  dpkg will then move on to the next deb to
install, try to spawn gzip and fail miserably (gzip is linked with a
non-existent libc6), everything falls apart rapidly from there.  gzip
*MUST* pre-depend on libc6.
 
(To be more explicit (since that seems to be the order of the day),
I'm imagining a situation of a person upgrading from bo to hamm doing
something like this:

dpkg -iEGOB gzip_1.2.4-18.deb ae_962_15.deb bc_1.04-2.deb  
libc6_2.0.5c-0.1.deb

When dpkg tries to fork gzip -dc to unpack ae, it fails because libc6
isn't even unpacked yet.  With a Pre-Depends this wouldn't happen,
because gzip wouldn't even be unpacked before libc6 is installed (and
configured, *but that's irrelevant here*)

[dpkg does ordering on configuration and removal, not install]

> I do agree that gzip should get the predependency, since it doesn't
> make sense for it to be inconsistent with all those other packages.

Now that is the single most lame reason I've yet to hear for a package
to have a Pre-Depends:.

> Of course, we still need new text for the packaging manual.  Try as
> I might, I can not find a bug report to dpkg that addresses this.

Maybe there never was one, I said it was a long standing bug, not bug
report.  (Something you apparently missed).

-- 
James 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Midnight Commander orphaned?

[James Troup]

Paul Seelig <[EMAIL PROTECTED]> writes:

> If nobody objects (i've cc'ed this message to the original
> maintainer "Fernando Alegre <[EMAIL PROTECTED]>") i'd happily like
> to take over maintenance of this package.

Do you have a libc6 setup?  A package with a maintainer who can't do
uploads for unstable is about as good as a package which is orphaned.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: predepends on libc6?

[James Troup]

[EMAIL PROTECTED] (Kai Henningsen) writes:

[ Deleted the part where the doubters once again fail to bother to
yprove that ldconfig isn't necessary (Hint: the onus isn't on me; I
don't care anymore, I *know* the policy manual is wrong, if you think
otherwise, do something about it, either way I'm not going to waste
more time discussing it) ]

> > [dpkg does ordering on configuration and removal, not install]
> 
> Aah. Now _this_ is a good (and probably sufficient) point.

[Just out of curiosity, why do you believe me about that? No, never
mind, forget I asked]

> From this, I'd say that everything needed by dpkg -i MUST pre-depend
> on any other package that it needs for that functionality used by
> dpkg -i.

I don't think so.  Once gzip Pre-Depends on libc6, it shouldn't be
possible for dpkg to get into a mess because it's unable to fork
programs again.  The packages you mention below are all essential,
dpkg can validly assume they'll be installed.  And because of their
Pre-Depends gzip, tar and fileutils won't ever be in an unpacked but
unusable state.  I think the same applies to ldso too.

(If someone's forced the removal of an essential package all bets are
off, so the only valid issue here is upgrading, as far as I can see)

> By the way, shouldn't Pre-Depends: only be used for Essential: yes
> packages?

No; I think there are valid uses of Pre-Depends for non-essential
packages.

> I see Pre-Depends: without Essential: in the following packages:
> libc5, libc6, libreadline2

You can't make shared library packages essential (Policy 2.3.7).
(libreadline2 being Essential would have made the upgrade to
libreadlineg2... interesting)

Actually libreadline2's Pre-Depends may well be bogus, certainly when
I added it, it was for the wrong reasons (I was confused as to what
was responsible for ensuring {/usr,}/lib/libc5-compat was in
/etc/ld.so.conf), maybe Guy has another reason for keeping it; I'm not
sure.  Guy?
 
> perl

The version I can see (5.004.04-2) has only a Depends.  Perl-base is
Essential and it's Pre-Depends are definitely a good thing, for, I
hope, obvious reasons.

> netstd, elvis-tiny

I'm not sure why elvis-tiny has Pre-Depends, I'm not convinced it
should.  I don't know enough about netstd to know if it's Pre-Depends
is valid.  One other package that certainly shouldn't have Pre-Depends
but does is e2compr.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Amiga port of Debian

[James Troup]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:

> I (and a couple of friends) are using Debian on a A1200 without
> prob, so I guess that it's 'finnished'... :)

It most certainly is not.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Amiga port of Debian

[James Troup]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:

> > It most certainly is not.
> 
> Hmmm? What's missing then, since we are running a perfectly working
> 1.2.17 system...

Any sane Amiga installation disks; a non-buggy-pseudo-1.3 base set.
And as of 12/12/1997, 246 packages have yet to be compiled and a
further 204 are out of date.  Debian/m68k is not finished and it is
not released.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Is "cp -a" allowed in debian/rules?

[James Troup]

Douglas Bates <[EMAIL PROTECTED]> writes:

> But consider the recent discussion of porting dpkg to other systems.
> If you were using dpkg on Solaris or HP-UX or ... you may not be
> able to count on cp understanding the -a flag.

Fooblah.  Debian is about systems integration; GNU fileutils is an
Essential part of that system.  Do you want to ban the use of install
-p, features of GNU Make, $() in shell scripts etc.?  debian/rules not
only can but should assume it's running on a Debian system.

Unless someone wants to advocate the use of BSD cp because of it's
streamlined and feature free implementation?

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: unstripped stuff in /usr/lib

[James Troup]

Christian Schwarz <[EMAIL PROTECTED]> writes:

> I'm not sure if we should treat static libraries the same way, since
> some people might need the symbols for debugging. Could someone
> comment on that?

Static libraries should be stripped with --strip-debug.  If you want
stuff with debug symbols put it in a libfoo-dbg.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp & pam (was: Re: ppp's ip-{up,down} and possible utilization of 'run-parts')

[James Troup]

[ Brokenly-long lines wrapped ]

Philip Hands <[EMAIL PROTECTED]> writes:

> ppp is needed for doing an install from the internet via a dialup
> link.  PAM is not needed until you want people to log into the
> system, so libpam is a waste of space on the install disks.
>
> I'm not certain it's worth the effort either, since libpam is only
> 21k and binary is almost exactly the same size (112 bytes bigger)
> --- opinions ?

libpam0g is 103k; libpam0g-util is 625k; libpwdb0g is a further 135k.
That's 863k.  My complaints about pam and ppp are this:

o When I filed the bug you were linking a libc6 application with a
  libc5 library.  That's not good.

 There is now a libc6-based pam in Incoming, once this gets processed,
 this objection, obviously disappears.

o I've heard[1] that the pam support in ppp is badly broken. 

 I don't know if this is still the case with 2.3.2, I don't do ppp and
 can't test it.  If someone who can test it does so and says it's
 okay, then this objection goes away too.

o By linking ppp with pam you are dragging libpam0g, libpam0g-util and
  libpwdb0g into base.  

 This is fine, *as long as* it's been discussed and agreed first, I
 don't like 3 shared library packages being silently dragged into
 base.  If we're going to do PAM for 2.0, then this will have to be
 done anyway.  But have really got the time to PAM-ify critical
 applications like the shadow suite and have them working and debugged
 and have 2.0 released before the next millennium?

> BTW does libpam0 need to be recompiled for libc6 before I can use it
> in ppp ?

Yes; linking with both libc5-based and libc6-based libraries is plain
Evil.  (At least, I sincerely hope no one is going to dispute that)

[1] According to Michael Johnson on the pam list, which,
unfortunately, doesn't seem to be archived.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Questions about emacs20 file system layout.

[James Troup]

"Adam P. Harris" <[EMAIL PROTECTED]> writes:

> BTW, are .elc files arch-dependant or arch-indep?  I've always
> wondered about this.

They're architecture independent.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

["Gonzalo A. Diethelm" ] Re: Moving topics from debian-private (was Re: SPI money out)

[James Troup]

--- Start of forwarded message ---
Resent-Date: 16 Dec 1997 22:24:45 -
Resent-Cc: recipient list not shown: ;
Date: Tue, 16 Dec 1997 15:38:16 -0300
Message-Id: <[EMAIL PROTECTED]>
From: "Gonzalo A. Diethelm" <[EMAIL PROTECTED]>
To: Ian Jackson <[EMAIL PROTECTED]>
Cc: Debian developers list 

[ ... ]

--- End of forwarded message ---

[Note the Cc: to iwj, despite the fact he's obviously on debian-devel]

Interesting to note that those whining about duplicate mails and
advocating the Reply-To munging are themselves creating duplicates.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ["Gonzalo A. Diethelm" ] Re: Moving topics from debian-private (was Re: SPI money out)

[James Troup]

Alex Yukhimets <[EMAIL PROTECTED]> writes:

> When doing 'g'roup reply in elm, the e-mail of the person goes into
> the "To:" header and list address (along with all other thread
> participant's adresses) to "Cc:" header.

So, umm, fix elm?

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[James Troup]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> This is part of an email exchange Sven and I had.  Simply put, I put
> in a new alpha binary of dpkg-1.4.0.19 that represented nothing but
> a recompile to pick up new libg++, ncurses, etc.  Sven suggested
> that this warranted a non-maintainer-release number, whereas I had
> gotten the idea that non-maintainer-releases suggested code changes.

I hope Guy will reject that.  If the binary changes, the version
number should change.  Things break if you don't increase the version
number (e.g. automatic upgrade and bug reporting) and you don't have
to a source release to do a non-maintainer release, just add a new
entry to the changelog before you recompile.

What advantage do you see in *not* changing the version number?

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> This is that way because our package system does not allow several
> binary packages for the same source package. But it should.

[...]

> Again this is a limitation of our current source|binary packaging
> scheme.  Does not mean it has to be that way.

[...]

I was talking about reality and not about what might/should/could be.
If you want to talk about whatever, fine, I don't care, but please
don't confuse this issue.  The fact of the matter is *currently*,
uploading a new version of a .deb with the same version number is
wrong, IMO.  What you think our packaging system should be doing at
some unspecified time in the future has nothing to do with it.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp & pam (was: Re: ppp's ip-{up,down} and possible utilization of 'run-parts')

[James Troup]

Herbert Xu <[EMAIL PROTECTED]> writes:

> > I thought that, until I noticed that libpam depends upon
> > libpam-util, which depends upon libpwdb0, which together come to
> > about 180k compressed.
> 
> I think you should file a bug report against libpam so it doesn't
> depend on libpam-util.  I don't see why a library package should
> depend on a binary one.

I think you should look at pam before making statements like that.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

gone for a week

[James Troup]

Hi,

I'm going home for a week or more, if any serious[1] bugs in my
packages come up, please feel free to do non-maintainer uploads of
them.

Happy Christmas and all that larky.

[1] And, please, I do mean serious, i.e. not whether /x/y/z should or
shouldn't be a conffile.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: debian 2.0 - any dates?

[James Troup]

"Boris D. Beletsky" <[EMAIL PROTECTED]> writes:

> If not, shouldn't we schedule one already. What are we waiting for?

Gee, I dunno, maybe it's, at least in part, for the developers who
still haven't upgraded their packages to libc6, despite it being
available since April.

-- 
James - xinted anyone?


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: debian 2.0 - any dates?

[James Troup]

"Boris D. Beletsky" <[EMAIL PROTECTED]> writes:

> > Gee, I dunno, maybe it's, at least in part, for the developers who
> > still haven't upgraded their packages to libc6, despite it being
> > available since April.
> 
> It will be available in the next few days,

Like Jed was going to be done "this weekend" several weeks ago?

> come on, you are not waiting for me and not for others who didn't
> convert the packages to libc6, all the essentials are converted.

Oh really? What about such inessentials and trivialities such as our
default MTA?

> And if there was a deadline for me to convert my packages I would of
> made it.

Ah of course; it's our fault for not setting a deadline.  Silly me.

I don't have a problem with people who don't have time to deal with
their packages properly; I do however have a problem with those same
people asking questions like "What are we waiting for?"

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: debian 2.0 - any dates?

[James Troup]

Martin Schulze <[EMAIL PROTECTED]> writes:

> > Oh really? What about such inessentials and trivialities such as
> > our default MTA?
> 
> Well...  Please take a look at
> ftp://ftp.infodrom.north.de/pub/people/soenke/debian-beta/ and
> test the smail inside.

Wouldn't that be better tested if it were uploaded to unstable?

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Intent to package mrtg & nntpcache...

[James Troup]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> If I've missed something, someone please let me know.

from hamm/contrib/Packages:

Package: mrtg
Version: 2.5.1-1
Priority: extra
Section: contrib/net
Maintainer: Joey Hess <[EMAIL PROTECTED]>
Depends: libc6, libgd1g, perl (>= 5.003)
Recommends: httpd
Architecture: i386
Filename: dists/unstable/contrib/binary-i386/net/mrtg_2.5.1-1.deb
Size: 182634
MD5sum: 58862a90f6ea3c18c02531317a894f04
Description: Multi Router Traffic Grapher
 The Multi Router Traffic Grapher is a tool to monitor the traffic load on
 network links using SNMP. MRTG generates HTML pages containing GIF images
 which provide a LIVE visual representation of this traffic. MRTG typically
 produces daily, weekly, monthly, and yearly graphs.
installed-size: 418

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Question/request concerning master

[James Troup]

[EMAIL PROTECTED] writes:

> Heiko, can dupload be changed to upload all files with one "scp"
> when using SSH to upload?

See #13383.

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[James Troup]

Christian Schwarz <[EMAIL PROTECTED]> writes:

>``Whenever the source package is changed WRT to the last uploaded
>version, its version number has to be incremented. In addition,
>if the source package is not changed but the binary package
>changed (because it has been recompiled in another environment),
>the version number has to be incremented too (this is, the source
   ^^^
>package has to be changed and uploaded again) to make sure
 
>dpkg/dselect recognizes the changed package.''

I completely disagree with the last sentence.  If I compile xfree for
m68k and because of a broken ldd, it has hosed dependencies (this is
not so fictional an example, it actually happened with ncurses), I
should be able to recompile X with a different version number and
*only upload binaries*.  What would redoing and uploading the source
get me or anyone else?

o it takes 5 days to compile X on my machine, I don't even want to
  think how long it would take dpkg-source to work on a 42 Mb source
  tree.

o it would spark off 100% pointless recompiles on other architectures.  

o it serves no purpose.  The only source change is to the changelog,
  and that is included in the deb.  And it doesn't help the rational
  of this policy (that is: source, or no source, dpkg/dselect will
  still recognise foo_1.2-1.0.1 to be newer than fo_1.2-1).

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Re^2: uploaded dhelp (i386 source)

[James Troup]

[EMAIL PROTECTED] (Marco Budde) writes:

> Am 05.01.98 schrieb leutloff # sundancer.oche.de ...
> 
> > Btw.: Shouldn't we switch the priority for bug to a higher one,
> > i.e. standard or essential!? It's a small but very useful program
> > that

Definitely not essential.  It by no means matches the definition of
it.  It probably could be raised to a higher priority though.

> CL> should be found on *every* Debian system.
> 
> Done :).

Christian was talking about the bug package not yours.

> This package uses standard.

Uh, why?  How is it ``standard''?

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc5 to libc6 auto-upgrade script

[James Troup]

Craig Sanders <[EMAIL PROTECTED]> writes:

> cd /debian/dists/unstable/main/binary-i386

Grr.

cd /debian/dists/unstable/main/binary-$(dpkg --print-installation-architecture)

-- 
James - Hardcoded-i[345]86 detection alarm triggered


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dpkg's version comparison algorithm?

[James Troup]

David Frey <[EMAIL PROTECTED]> writes:

> Why is 1.15 > 1.2 ?

Because 1 = 1 and 15 is > 2; dpkg breaks the version number into
chunks (in this case delimited by '.').

See verrevcmp() in lib/vercmp.c from the dpkg source for more details.

> Is it necessary to fill in trailing zeroes?

Yes.  20 > 15 -> 1.20 > 1.15

-- 
James


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Intent to package: Quinn Diff

[James Troup]

Hi,

I plan on packaging up Quinn Diff despite reservations I have, because
enough people have asked me to.  Quinn Diff is a program for comparing
the Packages files of two architectures to see what needs recompiled
on the secondary architecture.  See

http://thor.lib.chalmers.se/~jamest/quinn-diff/>

for more details.  My reservations are basically that the basic
functionality of Quinn Diff can be done very easily in
perl/python/whatever (Quinn Diff is written in C), as proved by at
least three other people.  However no one has extended their perl
versions as much as I have done with quinn diff (which says more about
my lack of life than anything else), or packaged theirs, so I'll
upload mine.  It'll be section devel, I guess, and priority extra
(it's main use is for people with exotic (i.e. non-i386) hardware,).

Any objections? 

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: sleep contains crypto stuff?

[James Troup]

Vincent Renardias <[EMAIL PROTECTED]> writes:

[ sleep is linked with libcrypt ]

> That's weird since it's in fact linked with libcrypt, but doesn't
> seem to use _any_ function/symbols from this lib:

Everything in shellutils is linked with libcrpyt, build it from source
and see.
 
-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is the `scsh' licence DFSG compliant? Please advise.

[James Troup]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:

> Attached is the COPYING file from `scsh-0.5.1'.  May this program go
> into "main"?

As already stated by myself and others: no.

> That would be wonderful.  I would like to package `guile-scsh' as
> well.  It bears the similar licence.

It bears the *same* license; it's a port of scsh, how could it be
arbitrarily relicensed?

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#21009: rvplayer: Namespace conflict

[James Troup]

Joey Hess <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED]:/ftp/debian/dists/frozen/contrib/binary-i386/web# dpkg -i
> > netscape4_4.0-7.deb 
> > Selecting previously deselected package netscape4.
> > (Reading database ... 61341 files and directories currently installed.)
> > Unpacking netscape4 (from netscape4_4.0-7.deb) ...
> > dpkg: error processing netscape4_4.0-7.deb (--install):
> >  trying to overwrite /usr/lib/netscape', which is also in package rvplayer
> > Errors were encountered while processing:
> >  netscape4_4.0-7.deb
> 
> I'm very confused by this, since I have netscape4 and rvplayer both
> installed, with no problems. rvplayer.deb contains a /usr/lib/netscape/
> directory. So's netscape.deb. That's fine, no conflict, right?

Right.  There seems to be an obscure bug in dpkg (?) which causes
directories to not be noticed as directories but as files, creating
false overwrite problems.  See #20250 for more details (including a
-D2773 log)

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packages which are in frozen which are libc5 based (and shouldn't be)

[James Troup]

Hi,

On i386, the following packages are still libc5-based or have
dependencies on libc5 based packages:

dotfile-1:2.2-1   Igor Grobman <[EMAIL PROTECTED]>
 -- depends on libc5 versions of tcl/tk
gnats-tk-3.104-4  Brian White <[EMAIL PROTECTED]>
 -- ditto
ilu-base-2.0.0.8-2Klee Dienes <[EMAIL PROTECTED]>
 -- Needs to be in non-free too
lapack-2.0.1-1Sue Campbell <[EMAIL PROTECTED]>
 -- Personally I think this should be orphaned, the maintainer appears to be MIA
objpak-dev-1.1.1-1(orphan) 
 -- #21037 (Important) [Wasn't orphaned properly]
p3nfs-5.1-2(extra)Billy C.-M. Chow <[EMAIL PROTECTED]>
 -- Personally I think this should be orphaned, the maintainer appears to be MIA
termcap-compat-1.1.1(extra)   Christian Hudon <[EMAIL PROTECTED]>
 -- ?
userv-0.58-1(extra)   Ian Jackson <[EMAIL PROTECTED]>
 -- Ian: any objection to a NMU of userv?
wm2-3-2   joost witteveen <[EMAIL PROTECTED]>
 -- #12717
xmailtool-3.1.2b-1.2  (orphan)
 -- Not really libc5, just some super lame hardcoded depends. YANMU uploaded to 
master

I'm going to promote #12717 to important and report important bugs on
all the others.  Any objections?  (I hope no one thinks
non-libc5-compat libc5 packages should be in hamm when it's released).

The script used to obtain the above information is of course,
Richard's, kudos to him [it's done in awk too].

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-maintainer release of info-3.12

[James Troup]

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:

> I just made a non-maintainer release of info_3.12-1 as Octave now
> needs a version of info that is greater or equal to 3.11. [1]

You called it 3.12-1.0 but it should be 3.12-0.1.  Also you'll need to
ensure (-sa to dpkg-buildpackage) that the .orig.tar.gz is included in
the upload.  (It's not in Incoming at the moment so dinstall will
reject your upload)
 
> There were three files outside the debian/ that were patched in
> info-3.9. The patch didn't apply properly, and I didn't investigate
> further.

Their functionality has been integrated into the upstream source so
they are obsolete.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: elvis package

[James Troup]

Martin Schulze <[EMAIL PROTECTED]> writes:

> It's free as it seems from the first view.  The second view tells
> you it's non-free, unfortunately.
> 
> Nevertheless I'm packaging it right now.

You ask Martin not to work on elvis because it's non-free but then
announce you're working on the non-free vile?  I'm confused.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: deb + tar + bzip2 suggestion

[James Troup]

Stephan Kulow <[EMAIL PROTECTED]> writes:

> > I think it would be a good idea to teach tar to unpack bzip2 files
> > via the -z option, just as if it would be gzip. Alternativly one
> > could teach gzip to use bzip2 for .bz2 archives or teach dpkg to
> > distinguish between the two.
> > 
> > The main advantage would be that one could use tar.bz2 for deb
> > packages without altering dpkg and thereby save a lot of space.
> > 
> > Whats the general opinion about this and is maybe somebody already
> > working on it?
>  
> I think, you could save some space, but the installation time of
> Debian would increase dramaticly.

And Debian would become unviable on low memory machines - bzip2 hogs
memory and is deadly slow compared to gzip - and, what's more, you
wouldn't actually see a significant benefit on 90% of the debs because
they are not the size where bzip2's savings really kick in.  So for
the vast majority of cases you'd do nothing but slow installation down
and increase the already heavy cost in memory of installation.

> BTW: tar can handle bz2 files. you can use
> --use-compress-program=bzip2.

or the -I option with tar (>= 1.12-3).

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bzip2 for source packages?

[James Troup]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> Might I suggest that using it for source packaging would be
> appropriate, though?

By recompressing things in bzip2, you lose the ability to use pristine
upstream source (since the vast majority of source stills comes in
.tar.gz form).
 
Having said that, I'm a lot less opposed to this idea than I am to the
idea of using bzip2 for debs.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Intent to package: debian-keyring

[James Troup]

Hi,

Santiago approached us (pgp-update) about splitting the debian-keyring
from doc-debian because a) the keyring tar ball is currently 256Kb
(36% of doc-debian's installed size) and growing (it may eventually
double in size when I get round to adding a debian-keyring.gpg) and b)
the keyring is updated much more frequently than doc-debian needs to
be (doc-debian wasn't updated for 7 months at one point).

So we intend to create a debian-keyring package which will be uploaded
weekly (if there are no changes, there'll be no upload, but given the
last couple of months I don't anticipate that RSN).  It'll be
maintained by "Igor Grobman and James Troup <[EMAIL PROTECTED]>".
I know this is controversial, but quite frankly, I don't care.  The
current ``policy'' was invented by Christian with zero consultation
(he ``thought it was already policy''[1]) and until it's ratified by
the developers I will ignore it as much as I ignored the bogus
no-ldconfig FUD in the packaging manual prior to 2.4.0.1.

Personally I think this package could go into hamm since it is a) not
really new but is a derivative of a package already in hamm, b) Arch:
all, c) very simple, it's hard to imagine release-critical errors one
could make in packaging it.  But if Brian disagrees I won't argue the
point and it'll go to slink.

Any objections?  (To the package itself, only please; take any
comments about the multiple-maintainership to debian-policy)

[1] 
http://www.nl.debian.org/Lists-Archives/debian-policy-9802/msg00053.html>

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: l3 - MPEG Layer 3 encoder

[James Troup]

[EMAIL PROTECTED] (Marco Budde) writes:

> Who maintains frozen? l3 (non-free) has expired. The author
> (Fraunhofer Institut IIS) has released a new version called
> mp3encdemo, but this version is limited to 30s of music (so it#s not
> longer useful) :(((.
> 
> So please remove my l3 package from frozen. Thanks.

File a bug against ftp.debian.org.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package moxa radius

[James Troup]

Igor Grobman <[EMAIL PROTECTED]> writes:

> Anyway, could you explain to me how this advertising clause is so
> harmful?

http://www.oryxsoft.com/rms/rms-bsd-license.html>

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package moxa radius

[James Troup]

Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:

> Urk!  It's the Obnoxious BSD Advertising Clause, back to haunt us.
> 
> Including the OBSDAC would make Moxa non-free.

Say _what_?  I do *not* think so.  (Hint: look at glibc's copyright
file)

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package moxa radius

[James Troup]

Igor Grobman <[EMAIL PROTECTED]> writes:

> Am I correct that this clause doesn't make software really non-free
> (DFSG definition)?

Yes.  To quote from the DFSG itself:

|   10. Example Licenses
|The "GPL", "BSD", and "Artistic" licenses are examples of licenses
|that we consider "free".

Let's please end this FUD now; the advertising clause is extremely
obnoxious but it doesn't make software non-free.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 21164 must be fixed before 2.0.34 comes out!

[James Troup]

[EMAIL PROTECTED] writes:

> On Sat, Apr 25, 1998 at 08:25:06AM +0200, [EMAIL PROTECTED] wrote:
> > On Sat, 25 Apr 1998, Herbert Xu wrote:
> > > FWIW, I just tried it on my Debian 2.0 2.0.32 machine:
> > what means FWIW ?
> 
> For what it's worth.
> 
> Note: there are several useful acronym lists / search systems on the
> web [ ... ]

and the `jargon' package in doc/

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Intent to package: uedit

[James Troup]

Hi,

I intend to package uedit.  I've always bemoaned the lack of a decent
editor on Linux, but I've finally found one.  For all those of you
who, like me, have long detested the bloated pig that is X11, you will
rejoice to know that this editor is console based.

This editor bypasses the bloated, useless and inefficient ncurses
library and uses it's own highly optimized textmode library for
improved performance.  To do it's funky stuff the library does require
uedit to be setuid, but please, don't let these security fascists put
you off, this is functionality well worth the so-called security risk.

uedit disables consoles switching, but don't fear this is not a bug,
but rather a feature.  To get maximum speed uedit will disable the
wasteful multi-tasking behaviour of Linux and make it do the Right
thing, DOS-style single-tasking.  Obviously neither X nor networking
survive, yay!  Network users should stop wasting bandwidth and use a
local machine.

As to placement within the Debian archive, it will have to go to
non-free as due to the haranguing and harassment of inhabitants of
comp.os.linux.* the author is loathed to reveal his secrets in case
sicko Linux-leechers try to steal his ideas, so there is no source.
People using non-i386 architectures should get a grip, get a life and
buy some real hardware.

Alas all is not good and great, there are several known bugs which
cause the editor to randomly segfault, but rest assured the author is
working on these and hopes to have them stamped out soon.

I hope you'll be as glad as I am to know that this is only the first
of many console-based tools planned by the author.  I look forward to
packaging them all!

More information about this exciting program and future plans for
others like it is available at:

http://home.att.net/~SAMIGWE>

I'll take it as read that there are no objections.  How could there
be?

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to take mawk and gawk

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> If nobody objects, I intent to take mawk and gawk.

I object.  I've talked with Christopher and I'm taking the packages on
a temporary basis (but as the real maintainer).  Christopher still
wants to maintain mawk & gawk and is still around, he anticipates the
possibility of being able to work on them again RSN, but if that
doesn't work out, I will actively maintain them until he is ready.

I'll try and work on both packages tonight or tomorrow (YAWN süger)
and fix whatever outstanding issues prompted Santiago to try and
hijack the packages.

Any objections?

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to take mawk and gawk

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> > > If nobody objects, I intent to take mawk and gawk.
> > 
> > I object.  I've talked with Christopher and I'm taking the
> > packages on a temporary basis (but as the real maintainer).
> 
> I object to taking a package in secret without announcing it here first,
> as I did.
> 
> Do we have the rules for taking an orphaned package?

Uh, first and foremost, mawk and gawk are *not* orphaned.  And what's
being done in secret?  I'm announced my intent in my previous message
to debian-devel (which you quote here).  Talking of doing things in
``secret'', did you communicate with the current maintainer of mawk
and gawk before announcing your intent to hijack them?

Also since when did we have restrictions on who maintainers passed
packages onto?  If I want to give ed to Martin Mitchell[1], I don't
expect for anyone to complain without extremely good reasons.  What
objections have you got to me maintaining mawk and gawk?

[1] Just an example, Martin doesn't want it, and I don't plan to give
it up RSN.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)

[James Troup]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> [ ... ] ld.so doesn't apply [ ... ]

Upgrade your quinn-diff :-)  From 0.31's ChangeLog.main :-

| Sun Apr 12 21:33:14 1998  James Troup  <[EMAIL PROTECTED]>
| 
| * Packages-arch-specific (ldso): exclude alpha.

(Maybe it should also be excluded for the other glibc only
architectures too? I always welcome input on Packages-arch-specific as
I'm only qualified to speak for m68k (and then only barely))

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: first proposal for a new maintainer policy

[James Troup]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> OK. I give. And, on the principle that if you can't beat 'em, join
> 'em, I now agree with Jame Troup and Dale Scheetz and formally
> declare that Policy does not govern may packages from this point on,
> and shall close any policy related Bugs ASAP.

Are you being nasty to me because I FUBARed kernel-package or what?  I
said I'm sorry about that, and don't know what more I can do. :-(

In any event I refer you to:

http://www.nl.debian.org/Lists-Archives/debian-policy-9804/msg00291.html>

where I said (among other things) ``For the record I don't really
think it's a good idea to flout policy and I regret suggesting that.''

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian 2.0

[James Troup]

Raul Miller <[EMAIL PROTECTED]> writes:

> >  - pam login doesn't use pam. passwd doesn't use pam. telnet doesn't use it.
> > unless most programs are unseing pam, it's useless.

Oh, foo.  Integration of pam was dropped as a release goal of 2.0
because it is quite simply not tenable if you want to release hamm
before 1999.  You can not simply recompile core applications like
shadow and net{base,std} with pam and "hope they work", especially not
a month+ into freeze.
 
> Not good.  [Sounds like a significant bug, too.]

The non-use of pam is not a "significant bug" and I have no idea what
makes you think it is.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Conflicts between developers and policy

[James Troup]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Well, it was gfetting frustating, what with being in the middle of
> two conversations, one with Dale and James, who are of the opinion
> that policy is a guideline, and not a set of rules adopted by the
> project

Again, please don't misrepresent my position like this.  I made one
rash comment which I later retracted (see previous message), and I
haven't been actively involved in this ``conversation'' since I posted
my retraction on 1998-04-23.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian 2.0

[James Troup]

Raul Miller <[EMAIL PROTECTED]> writes:

> > Oh, foo. Integration of pam was dropped as a release goal of 2.0
> > because it is quite simply not tenable if you want to release hamm
> > before 1999. You can not simply recompile core applications like
> > shadow and net{base,std} with pam and "hope they work", especially
> > not a month+ into freeze.
> 
> I didn't realize that pam was this unstable.

I never said it was unstable and it isn't.  But we haven't used it
before and I don't care how stable it is, we should not and will not
start recompiling core applications with a previously unused (*in
Debian*) library, one month into a freeze.  The decision to postpone
PAM integration till 2.1 was made a long time ago (see the list
archives).

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[James Troup]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> Retrieval of source from archives is usually done "by hand" but any such
> bulk retrieval should be easy to manage with a script. I take the lack of
> a script to indicate the current relative lack of need. Anyone is welcome
> to prove me wrong by writing such a script ;-)

Actually there is such a script and it is indeed trivial, nothing more
than a couple of lines of shell script.  Lars Wirzenius's excellent
dbuild does it (among other things):

http://www.cs.helsinki.fi/~wirzeniu/debian/index.html>

Not really wanting to get involved in this discussion, but since I'm
here anyway... I've seen some scary references to people wanting
RPM-style single tar balls for source.  Umm, please, good God, no.
That would suck most hard, and I and any of the people who maintain
multi-megabyte source packages (I'm thinking, X, *Emacs*, gcc,
binutils etc.) over a 28.8 would scream bloody murder.  Please think
very hard about the benefits of our current system before advocating a
replacement for it.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package: debian-keyring

[James Troup]

[ Gratuitous Cc to maintainers who already read debian-devel removed;
  please respect the Reply-To ]

Christian Schwarz <[EMAIL PROTECTED]> writes:

> > > It'll be maintained by "Igor Grobman and James Troup
> > > <[EMAIL PROTECTED]>".  I know this is controversial, but
> > > quite frankly, I don't care.  The current ``policy'' was
> > > invented by Christian with zero consultation (he ``thought it
> > > was already policy''[1]) and until it's ratified by the
> > > developers I will ignore it as much as I ignored the bogus
> > > no-ldconfig FUD in the packaging manual prior to 2.4.0.1.
   ^^^ <- should be 
2.4.1.0
 
> As I wrote to debian-policy a few months ago, section 2.3.2 of the
> Policy Manual _is_ official policy.

Which you yourself admit you invented yourself; no consultation, no
questions asked.  Let's please not forget this; it's central to the
discussion.  

> There is a currently a discussion on debian-policy about this
> section--but until we have a result from the discussion, this
> section applies _as_ _is_.

Sorry, but if you invent a policy which says "packages must call `rm'
with the arguments `-fr' in postrms'", I *will* ignore you.  Neither
you nor policy deserve blind faith or obedience; nobody in the project
does.
 
> If we leave it up to the maintainers to either follow policy or to
> reject it, we wouldn't need a policy at all!

Policy is not infallible.  Just look at the ldconfig episode; had
maintainers blindly followed that policy how much breakage would we
have had?  As it was the vast majority of maintainers with shared
library packages simply ignored broken policy, because they knew it
was wrong and to do the things the Right way and try to get policy
fixed did nothing but generate distinctly unpleasant flame wars (been
there, done that, bought the T shirt).

If I hadn't been so... annoyed by the way this particular policy was
created, and the so-called justification for it's continued existence,
I would have probably done what I did with the ldconfig FUD; ignored
it.  In retrospect, maybe I should have.

> I'm very disappointed that you've choosen this way to issue your
> opinion. It would have been much better if we had discussed the
> situation of the debian-keyring package in detail on debian-policy
> before.

I already mentioned my intentions in my posts to debian-policy; read
back and see for yourself.  You had every opportunity to discuss the
situation.

> (BTW, what's the `bogus no-ldconfig FUD' you are referring to?
> [...])

Chapter 12 of the packaging manual prior to 2.4.1.0 (going by the
changelog at least) tells you not to run ldconfig.

> > As for the Policy violation:  Go for it!
>
> It's up to you which guidelines you want to follow--but if you want
> to maintain packages for our distribution, you'll have to follow our
> guidelines!

I think you might want to look up the word `guideline' and the word
`rule'.

> Our policy applies to all packages in the distribution. Any package
> failing current policy in a severe way will be removed from the
> distribution.

Oh really?  Why haven't you removed dpkg then?  It's been failing your
personal policy for a long time.  And please define severe; unless you
do so carefully you'll find you just promised to remove a large
proportion of the distribution with your fiat power.

> Guy, please don't install the debian-keyring package into hamm or
> slink until we've resolved this issue.

Guy doesn't support this policy either Christian; fiat power or not,
how long are you willing to flout that power and go against the view
of the majority of people participating in the discussion?

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> > Please think very hard about the benefits of our current system
> > before advocating a replacement for it.
> 
> The pine-src package will not replace the already existing pine
> source in the "source" directory.

I was not talking about pine-src, as I made clear in the parts of my
message you cut out.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[James Troup]

[ Still not wanting to get into the discussion, honest, just making
  random points ]

Raul Miller <[EMAIL PROTECTED]> writes:

> > What is your point? The .deb packaging of source doesn't deal with
> > source dependencies any better than the current source package.
> 
> Sure it does.  You put the dependencies on the Depends: line of the
> control file.

You can do that in the .dsc file too, but it suffers from the same
problem, i.e. what to do with source dependencies like svgalibg1-dev,
which are arch-specific when .dsc files (or source debs, whatever) are
arch-independent.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[James Troup]

Raul Miller <[EMAIL PROTECTED]> writes:

> More specifically, I don't think that late in the frozen stage is
> the right time to introduce a new package format requirement for
> hamm.

Nor do I, which is why I've been avoiding this discussion.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages marked as Obsolete

[James Troup]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>  *** interpre Opt blt2 2.1-6
>   

Superseded by blt4.2, presumably.

>  *** non-free Xtr ckermit  192-5
>   

In project/orphaned, don't know why.  Seems to be missing a .tar.gz
though.

>  *** soundOpt chord3.6.1-1.1
>   
>  *** graphics Opt picon-usenix 1995.04.13-  
>   
>  *** gamesOpt xinvaders2.0-8
>   

Moved to project/oprhaned/ due to unanswered copyright problems.

>  *** non-free Opt dmalloc1 3.2.1-2  
>   
>  *** non-free Opt dmalloc1-dev 3.2.1-2  
>   

Superseded by dmalloc.

>  *** net  Opt epic4pre1.041-1   
>   
>  *** x11  Opt gnome0.12-1   
>   
>  *** x11  Opt gnome-icons  0.12-1   
>   
>  *** develOpt gnome-dev0.12-1   
>   
>  *** net  Xtr iproute  980119-1 
>   
>  *** oldlibs  Opt mesa22.5-2
>   
>  *** contrib/ Opt xephem-smoti 3.0-1
>   
>  *** contrib/ Opt wdb  1.5dm-b5.4-  
>   

Removed, orphaned or moved to unstable at the request of the
maintainer for various reasons.

>  *** math Opt freelip  1.0-3
>   
>  *** interpre Opt gcl-doc  2.2.1-2  
>   
>  *** libs Opt gstep-base0  0.2.12-2 
>   
>  *** misc Opt lee  1.1-3
>   

Old Karl Sackett packages, in project/orphaned/.

>  *** soundOpt gom-x0.29.10-1.1  
>   
>  *** develOpt libp2c1  1.20-2.3 
>   
>  *** libs Opt libfcgi2 2.0b2-1  
>   
>  *** libs Opt libtclobjc1  1.1b6-1  
>   
>  *** non-free Opt pari 1.39.03-7
>   
>  *** non-free Opt paridoc  1.39.03-7
>   
>  *** non-free Opt povray-lib   3.0.20-5 
>   
>  *** non-free Opt scilabdoc2.2-4
>   
>  *** x11  Opt tkdesk   1.0b4-2.1
>   
>  *** utilsOpt wordnet  1.5-3
>   
>  *** utilsOpt wordnetbase  1.5-1
>   
>  *** utilsOpt wordnetdoc   1.5-3
>   

Moved to project/orphaned by Brian, probably due to copyright file
absences.  A lot of these were orphaned badly, i.e. only one package
of a multi-binary source packages was removed.

>  *** adminXtr grub 0.4-1
>   

Moved to experimental.

>  *** ??   libpng1  0.89c-6  
>   

Obsolete, superseded by libpng0 (sic), which in turn is superseded by
libpng2.

>  *** contrib/ Opt picon-news   1998.02.24-  
>   
>  *** contrib/ Opt picon-unknow 1998.02.06-  
>   
>  *** contrib/ Opt picon-weathe 1998.01.11-  
>   
>  *** contrib/ Xtr picon-misc   1998.02.06-  
>   

Removed by Brian, I think.  Should be in non-free anyway, if they
reappear in contrib, an `important' bug will follow.

>  *** libs Opt regex0g  0.12-5   
>   
>  *** develOpt regex0g-dev  0.12-5   
>   

200% obsolete.  libc6 already includes regex, regex0g is superfluous.

>  *** oldlibs  Opt regex0   0.12-5   
>   

Renamed to libregex0.

>  *** ??   sambades 1.9.17p2-1

Replaced by samba, IIRC.

>  *** gamesOpt xtet42   2.02-8   
>   

Moved to some `Dead' directory in master, I can't remember the
location of offhand.  Copyright renders it undistributable IIRC.

>  *** tex  Opt latex2rtf1.1-6
>   
>  *** web  Opt cgiemail 1.2-3
>   

No idea.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[James Troup]

Brederlow <[EMAIL PROTECTED]> writes:

> Apart from that, you could also crosscompile.

Uh, no.  Please do not upload untested cross-compiled code.  Untested
stuff is the most likely to break and cross compilation is often
dodgy.  There are maintainers for the non-i386 architectures who will
compile all packages, which can be compiled, sooner or later.  If you
want to help us, a) ensure your package builds from a fresh source
tree, and b) fix the bugs we file about packages which won't build
from source[2].  People who don't own and can't access non-i386
machines producing non-i386 debs are in general, going to cause
trouble[1], not help.  Even on the slowest architectures, it's the
broken packages holding us back, not the number of compilable
packages.

[1] There are of course, some exceptions to this, e.g. non-free
pre-compiled binaries.

[2] There was until recently still #3xxx era bugs filed by previous
m68k maintainers about source packages being unbuildable from source.
I think Dirk may have fixed the last with his upload of autopgp, I
can't check right now though (nameserver problems).

-- 
James 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking other archs to build packages on

[James Troup]

Shaleh <[EMAIL PROTECTED]> writes:

> I do not believe that imlib/fnlib/E works on m68k -- correct me
> anyone if I am wrong.

Unless it broke recently, you are; certainly I've seen imlib based
stuff work on m68k IIRC.  m68k is usually the least problematic port
(sparc & powerpc are using dodgy glibc betas, alpha has a less stable
compiler (& libc?) and is 64bit), and I doubt imlib & friends suddenly
became big endian unfriendly.  Of course if E was even packaged, I
could make sure...

> I never received a bug from an alpha maintainer -- I stumbled across
> it in the bug list.

You've certainly received 2 from me WRT to *imlib.

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#22206: Some package uses psmisc without a dependency

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> Anyway, since psmisc is not essential (and this is what really
> matters), it would be interesting to know which package uses killall
> (if any) and where, to add the appropriate Dependency.

Maintainer scripts (and most everything else) should not use killall,
killall is Evil[1].  Packages using killall should be fixed not to use
it rather than depend on psmisc.

[1]  
http://www.nl.debian.org/Lists-Archives/debian-devel-9801/msg01205.html>

-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Hamm for other architectures

[James Troup]

Brandon Mitchell <[EMAIL PROTECTED]> writes:

> Now about that hard one, what are we releasing this time[?]

m68k is certainly going to if I have anything to say about it.

-- 
James
~Yawn And Walk North~


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can w3-el be precompiled?

[James Troup]

[ QP brain-damage reversed ]

"Rev. Joseph Carter" <[EMAIL PROTECTED]> writes:

> On Thu, May 28, 1998 at 01:12:25AM -0400, Gregory S. Stark wrote:

> > Oh, one gotcha to watch for. If you package Custom you really
> > ought to package Gnus as well and build it against the same
> > version of Custom. Otherwise a user who loads the new custom will
> > break the Gnus built with the old Custom.
> >
> > In fact Custom should probably Recommend both W3 and Gnus, since
> > it will break the ones that shipped with Emacs 19.
> 
> Uh, you realize that anyone using dselect and installing custom will
> be FORCED to install both gnus and w3...?

Yes.

> Having these packages depend on a certain version of custom would be
> wiser.

You can't.  There is *no* way round this other than to upgrade gnus if
you install custom.

-- 
James
~Yawn And Walk North~


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can w3-el be precompiled?

[James Troup]

Shaya Potter <[EMAIL PROTECTED]> writes:

> > You can't.  There is *no* way round this other than to upgrade
> > gnus if you install custom.
> 
> why not have custom conflict with older versions of gnus.

Because gnus is embedded in emacs19, not a separate package; shurely
you don't want custom to conflict with something it depends on?

-- 
James 
~Yawn And Walk North~


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to fix base-passwd

[James Troup]

Christian Meder <[EMAIL PROTECTED]> writes:

> while testing the base packages I hit the critical bugs surrounding
> the update-passwd binary contained in base-passwd.

Uh, which critical bugs?  --sanity-check now works as expected, is run
by default and update-passwd is no longer run automatically, it has to
be run by the user if it is to be used.

> The postinst should be changed to something along the lines:
> 
> update-passwd --sanity-check
> update-passwd -n
> Ask user if changes are ok.
> If yes
> update-passwd 

No, please don't do this.  Even if you do fix all the known bugs, it's
_way_ too late in the game to put an automatic call of update-passwd
back in the postinst.

-- 
James
~Yawn And Walk North~


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

sphor (aka bugs.debian.org) going down twice due to power maintenance

[James Troup]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

A UPS upgrade is being performed this week in the machine room that
houses sphor.debian.org (aka bugs.debian.org) hosted at the Oregon
State University's Open Source Lab.  Part of this upgrade will require
2 complete power outages for that room.  These outages are currently
scheduled as follows:

0900 UTC Wednesday, June 29th
0900 UTC Sunday, July 3rd

The expected downtime is about an hour each time.  Sorry for the late
notice and any inconvenience.

- -- 
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iQIVAwUBQsJbE9fD8TGrKpH1AQJU7g//aaMvP2zxmxOKTwhOcRkl881JYCSVMybm
b/LUBNIP2dABbCb1aYEylZHPo5OKV5deVEQj1jkS5AixEju+nJH/TD6Z0X1+lxU9
ZOePEx0M4PRrmR41pZVrKTgRTD5EO8gRKHLv/hAYvpqnNw6wIh/wBnIHI+uVBVHP
45InuZNliOJmu4RScko8Gn6uuZME0trHfHiVKxWpAgxcU3qdz1MqGVRUNE35y4O9
nm9M+qxxSeMP4b7ItzdeGlnis6uXshFBllNDcD4CgcmSYzYCAlJrICeS4a4RTnXe
7YU69yweUMnSsrubZHV7hJGIhH3i26hXlQAGSQOFjIov6exKjMpHkSAiao4FjlRP
WgUAr/9pg86xNX5WbuC01Fqrj7h8SCLBev2QbHdnx8NSxru/H/uJEdvi3frft6Ju
r0Doi93zw/O53cSMY/lTfj/SV0jIAkDRSpG6NdGMV/z9Ol3A4twQdOuUgQIYv95g
ovlUznrGKS39pWQGDWF1qgZZh5RvsFk08L1AKoExop6wmGjnCAg9crFjDoquDkpG
V2ugTggMc7raHcK09RM8ipwg+oiUgoGEpU8Sq7Qsf7IAugym4YQHXONuHWzsJfl4
NyChbCcbEgbRxg4f/D6GaE6oxAfIlJk7TPmndJY3mstOz8H0pksRSdyb6kGnwj26
Dfd5nHYbUr4=
=1Mcj
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[James Troup]

Joey Hess <[EMAIL PROTECTED]> writes:

> My memory is horrible, but IIRC James Troup (ie, our keymaster..) did
> some similar study at the DebConf5 KSP and ended up with a list of
> people whose GPG signtures he didn't trust anymore because of whatever
> trick they fell for.

Err, for the record, no I didn't.  I didn't attend or (AFAICR) even
submit my key for the KSP at DC5.

My key was part of the DC4 KSP materials, but I didn't manage to
attend in the end.  A couple of people signed my key despite my lack
of attendance and one of them an NM applicant, IIRC.  Again from
memory, Martin talked to the NM in question who was very apologetic,
claimed it was an honest mistake, he'd ticked the wrong person in the
list, etc. or something similar.

I don't recall anything further happening about that or any previous
incidents to which you might be referring.

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dak changes (names, version control, mail headers)

[James Troup]

Hi,

I've just updated ftp-master.debian.org to use a new version of dak
which no longer uses the silly names at all.  

This is something I've wanted to do for a long time now (I remember
discussing it with people at least 2-3 years ago), but I never found a
contiguous chunk of time to work on it until DC6.  It wasn't
inspired/requested/etc. by anyone or anything in particular, the
original names were just a mistake and my bad choice.

Anyway, the way dak works now is that all the scripts are invoked by
running a top level 'dak' command with the name of the script as the
argument, e.g. 'madison' becomes 'dak ls'.  dak --help will give you a
list of the possible commands.

This has a couple of less obvious knock on effects, one of which is
mail.  (1) mail now comes from '[EMAIL PROTECTED]' rather than
'[EMAIL PROTECTED]'.  (2) Mails from dak now have an 'X-DAK'
header.  The 'X-Katie' header will remain for a time to allow for
transitioning, but you should expect it to go away at some point.

merkel (DD accessible mirror of spohr) and klecker (security, non-US)
have yet to be updated to this new dak codebase, but I expect/hope to
do klecker at least either today or tomorrow.

One other thing is that the dak source code is now managed in bzr
which is available from:

  http://ftp-master.debian.org/bzr/

[This is a bzr 'knits' tree and correspondingly requires bzr >= 0.8,
 i.e. from sid (or etch after the next archive pulse).]

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Hosed potato/main/Packages...

[James Troup]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> On 30 Sep 1999, Michael Alan Dorman wrote:
> 
> > Philippe Troin <[EMAIL PROTECTED]> writes:
> > > Yeah, just uploaded some new packages which fix the typo.
> > 
> > I just hand-edited my available file. :-)
> > 
> > > Maybe it should be trapped by dinstall
> > 
> > I tend to agree.  I wonder how that can be done using the tools
> > themselves, so we don't end up with implementations that differ.
> 
> If the "installing programs" go belly up because of typos in individual
> packages, it is the responsibility of the build program to validate those

[ etc. etc. ...]

Okay, people are over-reacting a little here.  It's not a bug in the
package, it's a bug in me.  I added `optionnal' to the override file
(carelessly cut'n'waste from the package).  The override file is what
matters, not the package (that is, after all, why it's there... to
override).

Yes, dinstall probably should validate the priority field.  However,
the build tools should not.  Apt should definitely not die on invalid
priorities, and indeed, Jason has already fixed it not to and it won't
do so in future versions.  Dselect, AFAIK, doesn't die, nor does dpkg.
This breakage, was fixed within hours of being first reported (at
least on master, propagation not included), and only affects apt
weanies^H^H^H^H^Husers [;)].  The End.  (I hope?)

-- 
James

{R,I[INEW]}TP: free ssh [non-US]

[James Troup]

Hi,

OpenBSD have started working on the last free SSH (1.2.12 was under a
DFSG free license AFAICT[1]), they also, (again AFAICT [I'm going by
the CVS commits]), are ripping out the patented algrothims (IDEA,
etc.).  Unfortunately, I'm chronically busy with work and haven't had
time to look into it, but all the signs look very good (they appear to
have added it as part of their base system, for example).

So, I tentatively announce a preliminary ITP, pending confirming that
their hacked version is indeed DSFG free.  _But_, I'd much rather
someone with more free time would do it instead.  So, please, someone
else (who doesn't live in the USA) have a look/go...

Source is, of course, available from OpenBSD.  CVS or FTP, see
www.openbsd.org for a mirror near you.

[Yes, I know about lsh, but from what I've heard from people who track
it, it's not ready for prime time.]

-- 
James

[1] Please, don't bring up the red herring of that being v. old and
that there have been security fixes... this is OpenBSD, they've
fixed/are fixing them :)

Re: bash package removing /bin/sh on upgrade

[James Troup]

Torsten Landschoff <[EMAIL PROTECTED]> writes:

> If somebody could come up with a better method of handling this it would be
> most welcome.

Don't do it (muck around with /bin/sh links).  Guy made a comment in
the bug report about this and AFAIK didn't do it yet in case of
breakages like this.

-- 
James

Re: {R,I[INEW]}TP: free ssh [non-US]

[James Troup]

Joel Klecker <[EMAIL PROTECTED]> writes:

> At 09:55 +0100 1999-10-01, Philip Hands wrote:
> >James Troup <[EMAIL PROTECTED]> writes:
> >> OpenBSD have started working on the last free SSH (1.2.12 was under a
> >> DFSG free license AFAICT[1]), they also, (again AFAICT [I'm going by
> >> the CVS commits]), are ripping out the patented algrothims (IDEA,
> >> etc.).  Unfortunately, I'm chronically busy with work and haven't had
> >> time to look into it, but all the signs look very good (they appear to
> >> have added it as part of their base system, for example).
> >
> >Damn, I thought I knew ssh had been free at one point, but when I
> >noticed the non-free license in the late teens, I obviously failed
> >to go back far enough to find the free version.  I'll probably end
> >up calling the new package ssh-free
> 
> Note that OpenBSD is also ripping out support for pretty much any
> other other OS as they go, and using library functions that are
> OpenBSD-specific.

That's a slight over-exaggeration, but they are ripping out for
ancient non-POSIX OSes.  I doubt it'll be too much work to get it too
work on Linux...

-- 
James

Re: SSH never free

[James Troup]

Richard Stallman <[EMAIL PROTECTED]> writes:

> I am pretty sure that SSH was never free software.  Could you show
> me the license on the version that they started with?

-&<-&<-&<-&<-&<
This file is part of the ssh software, Copyright (c) 1995 Tatu Ylonen, Finland


COPYING POLICY AND OTHER LEGAL ISSUES

As far as I am concerned, the code I have written for this software
can be used freely for any purpose.  Any derived versions of this
software must be clearly marked as such, and if the derived work is
incompatible with the protocol description in the RFC file, it must be
called by a name other than "ssh" or "Secure Shell".

However, I am not implying to give any licenses to any patents or
copyrights held by third parties, and the software includes parts that
are not under my direct control.  As far as I know, all included
source code is used in accordance with the relevant license agreements
and can be used freely for any purpose (the GNU license being the most
restrictive); see below for details.

[ RSA is no longer included. ]
[ IDEA is no longer included. ]
[ DES is now external. ]
[ GMP is now external. No more GNU licence. ]
[ Zlib is now external. ]
[ The make-ssh-known-hosts script is no longer included. ]
[ TSS has been removed. ]

The MD5 implementation in md5.c was taken from PGP and is due to Colin
Plumb.  Comments in the file indicate that it is in the public domain.

The 32-bit CRC implementation in crc32.c is due to Gary S. Brown.
Comments in the file indicate it may be used for any purpose without
restrictions.

Note that any information and cryptographic algorithms used in this
software are publicly available on the Internet and at any major
bookstore, scientific library, and patent office worldwide.  More
information can be found e.g. at "http://www.cs.hut.fi/crypto";.

The legal status of this program is some combination of all these
permissions and restrictions.  Use only at your own responsibility.
You will be responsible for any legal consequences yourself; I am not
making any claims whether possessing or using this is legal or not in
your country, and I am not taking any responsibility on your behalf.


NO WARRANTY

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
-&<-&<-&<-&<-&<
 
> Is there any chance that you could put me in touch with the OpenBSD
> people who are working on this?

Theo de Raadt <[EMAIL PROTECTED]> is the head of OpenBSD, and as far
as I can see, he is the person who initiated the project they have now
dubbed OpenSSH (1.0).

Hope this helps...  

-- 
James

Re: SSH never free

[James Troup]

Herbert Xu <[EMAIL PROTECTED]> writes:

> They use libssl, which begs the question why isn't libssl in non-US/non-free?

Uh, because I keep forgetting.  I've been meaning to do that since Guy
split non-US up...  I guess I'll go file a bug against ftp.debian.org.

-- 
James

Re: whence netcomics?

[James Troup]

Roderick Schertler <[EMAIL PROTECTED]> writes:

> Does anybody know what happened to netcomics?  I'd been assuming it
> was pulled from potato but left in woody, but I just looked and that
> doesn't seem to be the case.  The only normal or archived bug on it
> doesn't say anything about pulling the package.  What happened?

The maintainer asked ftpmaster to remove it eons ago due to
unspecified legal reasons...

-- 
James

new-maintainer and delays (was Re: [some idiot troll who should have been ignored])

[James Troup]

"Christopher C. Chimelis" <[EMAIL PROTECTED]> writes:

> Looks like quite a backlog has been created by NM being shut down
> for so long.

Actually, no, way less than half the current backlog are applicants
from the shut down period.

> But, after picking a few people to look at that are currently
> in-process, some have experienced some unbelievably ridiculous
> delays (see http://nm.debian.org/[EMAIL PROTECTED]
> for a good example  does it really take a month or more to make
> a phone call?).

If that's all I had to do in my life, no, of course it wouldn't.
Unfortunately it's not.  Granted, DAM is becoming a problem, but a)
it's not the main problem (lack of contributing AMs is much more of a
problem), b) DAM appears worse than it actually is because my work on
it is sporadic and c) I am looking into fixing it (by taking on
mini-DAMers) in any event.

However, there is no longer any excuse for just whining about delays
in the new-maintainer process... if you don't like the delays, Chris,
feel to actually make a difference and sign up as an Application
Manager.

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: new bug tags

[James Troup]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Sun, Jun 01, 2003 at 12:52:02AM +0200, Guido Guenther wrote:
>> On Sat, May 31, 2003 at 04:23:49PM +0100, Colin Watson wrote:
>> > The BTS now has "lfs" (large file support) and "ipv6" tags.
>> > http://bugs.debian.org/tag:lfs and http://bugs.debian.org/tag:ipv6 will
>> > search for matching bugs.
>> Since we're using bug tags for such specific things now wouldn't it make
>> sense to add per architecture tags so one can search via
>>  http://bugs.debian.org/tag:hppa
>> for hppa related issues (not that there are any of course!). It would
>> help porters to identify arch related issues much more easily.
>
> I strongly second this.

I don't; it's silly.  At best you'll get an architecture tag for the
arch that the buildd maintainer reported the bug on, but that's it.
An inaccurate architecture tag is worse than useless, it's misleading.
Just parse wanna-build's failed logs; it's trivial.

-- 
James

Re: new bug tags

[James Troup]

Rene Engelhard <[EMAIL PROTECTED]> writes:

> Sure, but the architecture tags can be used n ot only for buildd
> failures?

No, that's my point, IMO they shouldn't be used _at all_ for FTBFS
bugs, because they'd be useless and misleading - and if these tags are
available people will try to use them for FTBFS bugs.

> What if an app just fails on one specific archs during startup or
> during execution?

Sure, fine, whatever, but if you compare arch-specific runtime bugs to
FTBFS bugs, you'll find that the vast & overwhelming majority are
FTBFS not runtime.

-- 
James

samosa (aka db.debian.org) problems

[James Troup]

Hi,

As many of you will have already noticed samosa is down and has been
for a while.  Unfortunately the machine is in a bad way - the
motherboard just beeps constantly when the machine's powered on.

The local admin has taken it out of it's rack and home with him to try
and fix it.  However even if samosa is completely dead, it's not a
major problem since, as it happens, this coincides nicely with a
planned upgrade of the hardware and the new box was due to be sent out
shortly anyway.

-- 
James

[I'll send something like this to d-d-a when I can get hold of a
 listmaster; bit of a chicken/egg problem trying to post to d-d-a
 about db.d.o being down... ;)]

Re: but I want the GNU versions of packages

[James Troup]

Mathieu Roy <[EMAIL PROTECTED]> writes:

> Having bugs not fixed in 4 years (3 years even with a patch
> provided)

Don't be such a disingenuous troll.  The patch for that _wishlist_ bug
has been there since April.  Not for 3 years.

-- 
James

Re: but I want the GNU versions of packages

[James Troup]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Mon, 30 Jun 2003 00:36:10 +0200, Michael Banck <[EMAIL PROTECTED]>
> wrote:
>>On Sat, Jun 28, 2003 at 07:57:55AM +0800, Dan Jacobson wrote:
>>> So what is the single command to apt-get install all the GNU versions
>>> of everything?
>>
>>Just create and maintain a meta-package that Conflicts/Depends on the
>>stuff you want.
>
> Given the current state of affairs, I am pretty sure that such a
> package will be rejected by ftpmaster. They pretty sure reject almost
> everything I upload.

Since you didn't bother with specifics, I can only guess you're
referring to clamav-data and eicar-testfile.  I encourage anyone to
check out

auric:/org/ftp.debian.org/queue/reject/{clamav-data,eicar-testfile}*

and judge this troll for themselves...

-- 
James

Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]

[James Troup]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> What didn't work about anonymous FTP?

The queue daemon can no longer handle PGP 2.x keys; I don't know why
and since a) the number of developers still using these kind of keys
for uploads can be counted on the fingers of a mutilated hand, b)
there are alternative methods of uploads available to the few who do,
c) queued is in perl and d) has plenty of other more vicious bugs, I
haven't done anything about it.  If anyone else cares to fix it, feel
free to send me a tested patch.

-- 
James

update on binary upload restrictions

[James Troup]

Hi,

   Summary
   ===

I've done some work in dak to improve the binary upload restrictions
that are currently in place to hopefully reduce some of the collateral
damage that resulted from the initial implementation.  Binary upload
restrictions are now per-suite/component/architecture which means that
uploads to experimental and/or non-free should no longer be affected.
The current restrictions are listed below[1] for reference.


 Why restrictions on binary uploads?
 ===

So there are several reasons why these restrictions have been put in
place:

(o) reproducibility

It's vitally important that packages in our archive can be rebuilt on
our buildds and not require a custom environment or source
modifications or other special treatment.  When they can't, scaled
across as many packages and architectures as we have, it makes the job
of the security team nearly impossible.

The best (and IMO, only) pragmatic way of doing this is to actually
have built them on a real buildd.

(o) logging 

The build logs at buildd.debian.org are invaluable in trying to debug
problematic builds.  Byhand builds and other unofficial builds often
don't send an associated log to buildd.debian.org.

(o) build effort coordination

There's a reason the buildd suite is called 'wanna-build'.  The core
of it, both when Roman first wrote it all those years ago and now, is
the sensible and efficient coordination of builds amongst multiple
build daemons.  Having a random additional build daemon that's not
part of the 'wanna-build' system breaks this and all the advantages it
brings.

(o) emulated/cross-compiled buildd-ing considered potentially harmful

The idea of emulated buildds or cross compiling has been around for a
long time.  Personally I don't think it's a good idea, but that's not
really the point.  The point is that one person should not
unilaterally make the decision that they are or are not OK.  If it's
the consensus of the release managers and the architecture porting
team that they want to use emulated buildds and/or cross compiling, I
absolutely will not stop them from doing so.

---

(Now if at this point, you're thinking about source only uploads,
 please see [*].)


  Why are the current set of restrictions in place?
  =

arm has had restrictions in place ever since Aurelien decided to
unilaterally turn on emulated buildd(s) for arm with no consensus from
the arm porting team or the release managers.  This was problematic
for all the reasons listed above.  Also, fundamentally, arm was not in
trouble release-wise because it lacked build power, but because it
lacked _humans_ willing and able to deal with the failing builds.

alpha has recently had restrictions added because the main alpha
buildd has been down due to relocation[2] for some time now and so, as
a result, the number of byhand builds on random machines has shot up.
Once Goedel is back (tomorrow - apparently) and if the byhand builds
stop, these restrictions could be relaxed.

-- 
James

[1]


Binary-Upload-Restrictions
{
 Components
 {
   main;
   contrib;
 };
 unstable
 {
   arm
   {
 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
 70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
 F849E2025D1C194DE62BC6C829BE5D2268FD549F;
   };
   alpha 
   {
 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
 70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
   };   
  };
};


[2] Unfortunately there was very little notice of goedel's move and it
was originally scheduled only to take a couple of days but was
unavoidably delayed by external factors.




[*]

 Why not move to source only uploads?
 

A question that often comes up when this subject is discussed is 'hey,
I agree about the logging and reproducibility points above, so why not
move to source only uploads so you get those for all binaries?'

So, again, this is not something I personally think is a good idea but
I won't stand in the way of consensus of the Release Managers and the
developer community as a whole.  I think it's a bad idea for two
reasons:

 (a) we don't currently have the buildd infrastructure for this - it
 would require a minimum of 2 (preferably 3) machines dedicated to
 being i386 buildds.  It would also make i386 uploads much more
 sensitive to delays and really require better coverage than one
 human could provide.

 (b) source only uploads are in my experience very often badly tested
 if they're even tested at a

packages up for adoption

[James Troup]

Hi,

The following packages are up for adoption:

 * gawk
 * gdbm
 * gimp-dimage-color
 * gnupg-doc
 * gnus
 * mawk
 * p0f
 * quinn-diff
 * xloadimage
 * gawk-doc (non-free)

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages up for adoption

[James Troup]

James Troup <[EMAIL PROTECTED]> writes: 

> The following packages are up for adoption:

Please note I said adoption, not orphaned.
 
>  * gawk
>  * mawk
>  * gawk-doc (non-free)

Steve Langasek is taking these 3.

>  * quinn-diff

Luk Claes is taking this.  

(Roger, I'm afraid I don't have a version control repository for
 quinn-diff.  Honestly, I'd love to see the package be superseded by
 something new & better.  It's my first C project from almost 10 years
 ago, and it shows.)

>  * gnupg-doc

Don Armstrong is taking this.

>  * p0f

Pierre Chifflier is taking this.

>  * gdbm

Anibal Monsalve Salazar is taking this.

Thanks to all of them.

These 3 are still up for adoption:

>  * gnus
>  * gimp-dimage-color
>  * xloadimage

If no one wants gimp-dimage-color, I'll ask for it's removal.  It's
dead upstream and Konica Minolta don't even make cameras any more.

-- 
James


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: some packages from incoming are not going into sid

[James Troup]

Noèl Köthe <[EMAIL PROTECTED]> writes:

> is there any reason why packages, which are already accepted and now are
> in incoming.d.o are not moving to the archives?
>
> for example http://incoming.debian.org/wget_1.9-1_m68k.deb is there
> since 2003-11-04.
> Other packages like xmule or webmin are having the same "problem".

It was a bug in 'kelly' triggered by a recent scsh upload.  Anything
alphabetically after that wasn't being processed.  The bug has been
fixed and everything should be processed as normal tonight.

-- 
James

Re: ftpmaster accepts packages that have been rejected a few days ago

[James Troup]

Marc Haber <[EMAIL PROTECTED]> writes:

> I had to wait almost three weeks to have the package REJECTED by
> ftpmaster

20031023144719~jennifer~Moving to new~linux-atm_2.4.1-10_i386.changes
20031103144602~lisa~rejected~linux-atm_2.4.1-10_i386.changes

Hmm, that doesn't even look like 2 weeks to me... but hey, who needs
facts when you're flaming, right?

> Any comments will be appeciated.

In the series of mails that followed the initial REJECT, I said (in
<[EMAIL PROTECTED]>):

| If you disagree with that, you can either try your luck with another
| ftp-master or get rough consensus on debian-devel that I'm wrong.

-- 
James

Re: Suspicious reply from katie

[James Troup]

Marcin Owsiany <[EMAIL PROTECTED]> writes:

> I have just uploaded another version, which resulted in receiving
> the attached message. Note the NEW status, and the warning. Is this
> a katie bug? Or did I do something wrong?

It's a James-is-a-moron problem.  I broke (read: deleted)
experimental's overrides by mistake.  I hope to fix it over the next
couple of days.

-- 
James

Re: file format for debian/copyright

[James Troup]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Sun, Dec 08, 2002 at 01:04:40AM +0100, Luca - De Whiskey's - De Vitis 
> wrote:
> > copyright-should-refer-to-common-license-file-for-gpl may fail to
> > understand that GPL is only mentioned in the copyright notice, and is not
> > the type of the license
> 
> Ehm. If GPL isn't used, don't mention it. How much simpler can it get? :)

Err, because there are licenses (e.g. openssl) which mention the GPL
themselves (in contexts like: "you can't just GPL it")?

-- 
James

Re: private debian pools

[James Troup]

Brian May <[EMAIL PROTECTED]> writes:

> I looked at katie; it seemed to be a complicated and undocumented
> mess that was a total overkill for my purpose (eg. I don't need a
> database).

That "complicated and undocumented mess" has been running the Debian
archives successfully and without major incident for over 2 years now;
it must be doing something right.

> I couldn't even guess where I was suppost to start.

You could try reading the "non-existent" documentation...

> [...] but these names mean absolutely nothing to be when I am trying
> to get a given task done.

like doc/README.names maybe.

*plonk*

-- 
James

Re: DAK (2)

[James Troup]

Brian May <[EMAIL PROTECTED]> writes:

> If I were to clean things up and make DAK easier to use for private
> archives (eg. by isolating all Debian specific stuff, ideally into
> a limited number *.conf files), would somebody be willing
> to commit the changes to CVS?

No one sane agrees to pre-commit changes sight-unseen to CVS.  Show me
the changes, and we'll talk.

> I suspect even though I might have write access to CVS,

Err, no you don't and I have no idea what would made you suspect you
might.

> > like doc/README.names maybe.
> 
> I found that very brief and vague. It is not made clear for instance,
> what programs must be run before, what CWD must be in order to
> run the program, etc.

Duh.  That's not the purpose of that document.  You were whining about
not being able to translate task to script name and vice versa;
doc/README.names does that and that's why I mentioned it.

> Command line parameters are simply not documented anywhere.

Err, bullshit, there's doc/*.1.sgml and --help for most of the key
scripts.

> Some questions:
> 
> 1. For package installations, DAK will inform both the uploader and the
>maintainer.

No, that's just the default.  It's possible to override it through the
config file.  (Think about security.d.o: when was the last time you
got notification for a security upload of your package?)

> 2. Where is the code that moves unstable to testing? That does not
>appear to be here?

It's in the same CVS module in the 'testing' directory.  You could
have found that out yourself, had you bothered to look.

> 3. Could the information in apt.conf be automatically generated from
>kate.conf?

Not all of it, no.  Some of it, yes.

> 4. When installing a new package (with lisa I think), how do you specify
>with component {main,contrib,non-free} it will go into?

You don't; the section field specifies that.  That's not a katie
question, that's a general Debian knowledge question and again
something you could have found out yourself, had you bothered to look.

> 5. Debian packaging.

There is debian packaging.  Do you actually bother looking at
_anything_ before posting?  I mean if you'd said "Improve the Debian
packaging" it might not be so offensive but you seem to have a serious
post-first-think/act-later problem.

> Anyway, just some ideas. I am not sure if there is a dedicated
> mailing list for this or not.

There will be shortly.

-- 
James

Re: dinstall/debian-installer

[James Troup]

Brian May <[EMAIL PROTECTED]> writes:

> - Change paths to config files in utils.py.

Sigh, you don't need to do that.  See /etc/katie/katie.cnf on
e.g. auric.

> - rose creates initial directories (actually some where missing; I can't
>   remember which onces were missing and which ones were misconfigured
>   though now).

rose uses the provided config file; it'd be hard for her to "misconfigure" a
directory

>   (melanie complains that it cannot delete the files from buildd/*,
>   but I can't see why, I deleted the same files mentioned manually
>   without any problems).

Huh?  I don't think you mean melanie, she doesn't delete files.

You seem to be making a fundamental mistake: cron.daily, katie.conf,
apt.conf etc. are all not the best files to start from, they're
ftp-master's real config file.  I know that's non-intuitive but that's
just how it is always been hysterically.  Don't start from them and
don't assume they're some kind of example to build from.  If anything
the security ones are a far better example in many ways.

> - cron.buildd is for buildd, I don't know where to get wanna-build from
>   so I don't use it.

Again, you obviously didn't look it's utterly trivial to find.

> - cron.hourly doesn't appear to be required.

WTH are you talking about?  required for what?  cron.hourly simply
runs julia which syncs postgresql ideas of users and the systems which
is useful if you're using postgresql's 'peer sameuser' (or whatever
it's called these days) access control on a multi-user system.  If
you're not, then it's not "required".

> - cron.weekly might be important, but I don't understand what it does.

Dude, it's 8 or so lines of shell script with comments.  Where's the
difficulty?

| # Purge empty directories
| 
| [...]
| 
| # Clean up apt-ftparchive's databases

> - turn off BXA notifications in katie.conf. Or change the template.

No, don't use auric's katie.conf as a starting point.  Write your own.
BXA Notification defaults to off if it's not mentioned for this very
reason.

> - turn off auto closing bugs in katie.conf. Or at least change
>   the template.

Likewise.

> - when new package is accepted it will inform uploader and package
>   maintainer; the maintainer might confuse this E-Mail as an
>   unauthorised upload to the Debian archive. I am not sure what the best
>   solution is here.

See other mail; this can be overriden.

> - some templates in templates/* have E-Mail addresses hardcoded (From
>   and To E-Mail addresses).

Err, amber.advisory and lisa.bxa-notification, neither of which anyone
would want to use unedited if at all.

> - cron.* have E-Mail addresses hardcoded.

Duh.

>   kelly -pa *.changes | tee REPORT | \ mail -s "Install for $(date +%D)"
>   [EMAIL PROTECTED]
> 
>   This comes up with lots of errors if *.changes doesn't exist.

This is simpy because katie's designed for real archives which
invariably have new uploads every day; it's trivial to fix.
 
> - No way to override component eg. (main,contrib,non-free) without
>   changing source; I have a patch that will let you override it in lisa.
>   I have also patched/hacked jennifer to use existing overide component
>   if one already exists.

You've grossly misunderstood how components work.  See other mail.

> - cron.daily is pretty verbose.

IT'S NOT AN EXAMPLE FILE, IT'S AURIC'S AND WE LIKE IT TO BE VERBOSE.

damn it.

> - cron.daily generates override.potato.all3 and override.sid.all3, but I
>   can't see what use these files are.

They're used for legacy-mixed style directories; if you don't have any
of those and/or don't know what they are you don't need to care about
it.

> - Not sure how to move files between components, this might require a
>   delete operation followed by a new upload.

No, it doesn't.  It's automatic; you simply change the section.
Again, learn how components work in Debian.

> - Where is the check to ensure files aren't uploaded to stable?

There isn't any, they go to proposed-updates and are installed into
stable manually or rejected from proposed-updates.

> - nothing except mkmaintainers seems to use the ftpdir/indices
>   directory???

Err, overrides are installed there by copyoverrides.

-- 
James

Re: DAK (2)

[James Troup]

Brian May <[EMAIL PROTECTED]> writes:

> 5. What is the dsync-flist used by mkchecksums, and where can I get it
> from? Google search returns nothing.

http://cvs.debian.org/?cvsroot=dsync

-- 
James