Bug#1081155: ITP: openrocket -- Model Rocket Simulator

[Bdale Garbee]

Package: wnpp
Severity: wishlist
Owner: Bdale Garbee 
X-Debbugs-Cc: debian-devel@lists.debian.org

  Package name: openrocket
  Version : 23.09
  URL : https://openrocket.info
  License : GPLv3+
  Programming Lang: Java
  Description : Model Rocket Simulator

 OpenRocket is a free, fully featured model rocket simulator that allows 
 you to design and simulate your rockets before actually building and 
 flying them.
 .
 OpenRocket features a full six-degree-of-freedom simulation, realistic 
 wind modeling, a multitude of different components including free-form 
 and canted fins, clustering and staging. 


Years ago, I packaged OpenRocket for Debian main.  It's a Java app, and as
upstream embedded more and more third-party class libs in their source tree,
often in the form of binary jar files, I eventually "gave up" and replaced
the full source build with an installer for the "fat" application jar file
provided by upstream in contrib.  Then upstream development stalled, and
there were no new releases for some years.  The installer package gradually
became less useful as the release it was designed for from 2015 had a hard
dependency on Java versions no longer available in any version of Debian.

In recent times, the upstream development community around OpenRocket has
gotten healthier, and new releases have been made.  Because the existing 
installer in contrib did not work with them, I agreed with the idea in
bug #1079850 that the installer should just be removed from Debian contrib 
entirely.  

In the near term, it is possible to use upstream's distribution-agnostic 
Linux download to obtain and run the program, though that is of course
side-stepping Debian policy and the DFSG.

For some time, I've been slowly working through the issues that prevent a 
"proper" build of OpenRocket for Debian main.  A couple bugs filed upstream
and against class library packages in Debian have been responded to, but 
there's more to do.  I'm filing this ITP as a replacement for both the 
installer package just removed from contrib, and the RFP filed as bug 
#1021564 which has of course been closed with the removal of the existing
package.

To be clear, I'd *LOVE* to have help from anyone who groks Java packaging
in Debian to get the remaining embedded class libraries that aren't already
packaged taken care of, updating those that have fallen out of date, etc.
Feel free to reach out to me directly if you'd like to help get OpenRocket
back in Debian main!

Bdale

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Bdale Garbee]

[EMAIL PROTECTED] (David Schmitt) writes:

> On Monday 14 March 2005 11:10, Rene Engelhard wrote:
>> pcc is barely at 98%. I don't think that barrier should be that high. We
>> *should* at last release with the tree most important archs: i386, amd64,
>> powerpc.
>
> Please, 98% is not high. It is just a call to porters to get their act 
> together.

When I was actively running the ia64 and hppa buildd systems, which I am not
doing today, it was my observation that completion percentage was "noisy" and
depended a lot on what was happening in the upload queue on a given day.  So,
while I agree that 98% seems like a reasonable goal, there are some things I
think it is worth keeping in mind if you try to look at the raw numbers.

The number of uploads per day varies a lot.  Some days it's fairly quiet, some
days it's not... and a really productive bug-squash weekend can run the upload
rate *way* up and depress the completion percentages a bit until everyone
catches up.

If there's a buildability problem in an upload that's at the base of a build 
dependency tree, the completion percentage can droop quite a bit until that 
issue gets resolved, then it may bounce back up more or less immediately when 
it gets fixed.  If you happen to look at the numbers in the middle of one of
these events, you'll get unexpected results.

A transient infrastructure problem at a "sensitive" time of day can cause a
droop in completion percentage because of email being backed up, etc.  Easily
enough to cross any "magic threshold" depending on which day you look.

The admins of the various buildds have different patterns of behavior in terms
of how often they review and sign uploads.  If they're on it all the time day
and night, the visible completion percentage is likely to be higher than if
they do this once a day... and the time of day relative to when katie runs
can make a difference, too!

My point is that I would expect any rational application of this sort of 
criteria to look at more than a single instant in time...  I don't think it
is very useful to fret over the "noise" on the signal day to day.  Some
buildd admins treat this as a real game, and work hard to be at the top of 
completion graphs every day... some don't.  

The real question on the day of release is what the build percentage of 
'testing' is for each architecture, and that's a pretty easy place to drive 
the numbers near or to 100% if we think it's important enough!

Bdale


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

Re: Package flow scenarios

[Bdale Garbee]

[EMAIL PROTECTED] (David Schmitt) writes:

>> 4.2) the package fails to build. This used to be a RC critical FTBFS,
>> but is not so anymore. The porter are responsible for fixing the bug and
>> uploading a fixed package to unstable, as they do now.
>
> Wouldn't it be better: "The porter are responsible for fixing the bug and 
> supplying a patch?" Of course, in the case of unresponsive maintainers, there
> is always the possibility of an NMU, but this shouldn't be the norm - not 
> even with tier-2 arches.

While porters can often serve up a patch for a truly architecture-specific 
build problem, sometimes a porter and the maintainer of a package need to 
collaborate to bring a build problem to closure.  This can be particularly
true if the package is complex, or the upstream change is substantial.  In
those cases, the package maintainer and upstream may be able to understand
the issue and deliver a fix much faster than "a porter" who might know nothing
about that application.

My point is simply that portability and quality are shared responsibilities 
for all of us, not something we can arbitrarily assign to "someone else" and 
still expect to achieve our goals as a community.

Bdale


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

Re: points on future installation disks development

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: - new features
:   - installation via serial terminal

An additional reason to do this is that non-PC platforms (Sparc, Alpha, HP
coming eventuall...) often run "headless" with onl a serial console and a
network interface for servers.  Getting it right in general would help with
porting to these other platforms.

Bdale


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

Re: RFC: Deb 2.0 testing process

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: This list can be added to by anyone.  What I'd like to ask for now is any
: comments on this.

A checklist like this is a good idea, particularly if it eventually provides
the list of things that initially need to be part of a regression suite for
the package.

The downer is that if you don't get working on a regression suite for each
package, testing a couple thousand packages against non-null checklists seems
like it could take a wickedly long time... particularly if, as I suspect, many
packages need to get revisioned during the testing interval to fix bugs.

Bdale


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

Re: predepends on libc6?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: -BEGIN PGP SIGNED MESSAGE-

: On Fri, 21 Nov 1997, Bdale Garbee wrote:

:> In bug report 15091, Christian Meder suggests to me that I make gzip 
predepend
:> on libc6.  It is not clear to me that this is a good thing to do.

: [ I think it is a good thing to do, so I have changed the severity to
: "grave" ].

There has been an apparent lack of interest in whether gzip should pre-depend
on libc6.  My most recent reading of the policy docs about such things suggest
that it might be a good idea, "but I'm not sure".  If anyone cares greatly
about this, now would be a good time to say so.

Unless convinced otherwise in a couple of days, I'll upload a gzip that 
pre-depends on libc6.

Bdale


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

intent to package nmap

[Bdale Garbee]

For the record:

I have need of a port scanner tonight, I don't see one packaged, I happen
to like nmap, and I see no record that anyone else has indicated they are
packaging it... 

Expect a package upload shortly... I've got the sources reworked for libc6,
and am finishing up the package now.

For the impatient and/or curious, nmap is documented at 

http://www.dhp.com/~fyodor/nmap/

Bdale


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

ytalk up for adoption

[Bdale Garbee]

I've been maintaining 'ytalk'.  I don't actually use it any more, and it's
the only X-based thing I maintain except xtrkcad, which is a binary-only 
package that I don't have to futz with much.  Therefore, I'd like to stop
maintaining ytalk...

Anyone want it?  There are a couple of open bugs, but I'm really not
motivated to put any more time into it.

Bdale


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

Re: Summary of Package Overlaps -- preliminary

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Overlap between amanda-client_2.3.0.4-2 and amanda_2.3.0.4-2:
:usr/lib/amanda/amcat.awk
:usr/lib/amanda/amplot.awk
:usr/lib/amanda/amplot.g
:usr/lib/amanda/amplot.gp
:usr/lib/amanda/versionsuffix
:usr/man/man8/amplot.8.gz
:usr/man/man8/amrecover.8.gz
:usr/man/man8/amrestore.8.gz
:usr/sbin/amplot
:usr/sbin/amrecover
:usr/sbin/amrestore
: The debian/rules file copies these from the amanda tree to the
: amanda-client tree, so the overlap is probably not a mistake.  If
: these are really needed by both the server and client packages, then
: perhaps there should be an amanda-common as well.
: Reported as bug #11046 and #11943 to amanda.


I've exchanged email with Christian Meder (the current amanda maintainer).  I
am working on a non-maintainer release of amanda/amanda-client this weekend to
try and close this and some of the other bugs.

Stay tuned.

Bdale


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

Re: New official mirrors

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

Neat idea (a mirror in space), but unlikely to happen.

: Hey, doesn't Bdale build satellites? :)

Yep.  See www.amsat.org for more details... specifically, what I'm working on
today (literally) is documented at:

http://www.amsat.org/amsat/sats/phase3d/rudak-u/

I've been too busy to update the web page recently, but if you're dying to 
see a couple of pictures of my basement, have at it...

The P3D Rudak subsystem will be the most capable digital communications 
package yet flown on an amateur satellite.  However, each CPU will "only" 
have 15meg of semiconductor file storage medium.  So, a mirror is, er, out of 
the question...  :-)

Most of the software developers for this project live at least part-time on
Debian systems, and much of the Phase-3D ground control software may end up 
on Debian systems by the time we launch... 

Amateur radio has been granted a permanent home on the international space
station, but the focus, again, will be on communications and scientific
experiments... I'd be surprised if a disk big enough for a mirror flew.  And
I'm confident we wouldn't be able to keep it current!  :-)

Bdale


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

Re: bo-updates coordination

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Given the creation of a bo-updates directory for those of us who wish to
: provide backported versions of hamm packages for bo (thanks Guy!), we now
: have the possibility to do this. 

I'd encourage the packaging and release of a fresher xntp3/xntp3-doc pair.  I
get frequent bug reports about the version that was released with 'bo'.  We've
gone way beyond that rev in unstable.

I don't have either a libc5 system around any more, or the time and inclination
to do this myself, but if someone tries and has trouble, I'll be glad to 
advise...

Bdale


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

Re: NPR piece on Linux

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: Anyone have a digitized copy of this?  :)

Look on www.npr.org later tonight.  The 'current' page still has the pieces
from the 7th...  All the interesting stuff on NPR becomes available via
RealAudio shortly after broadcast.

Bdale


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

intent to package jstation

[Bdale Garbee]

I intend to package 'jstation' for Debian.  This is a suite of Java-based 
software that implements a full-featured ground station for amateur radio 
satellites using the Pacsat protocols.  

Because jstation depends on JDK 1.1, it will go to contrib despite being
GPL'ed itself.  This might change if a free Java implementation for Debian
can replace the JDK dependency.  This is my first foray into the Java
universe, so I'm a little out of touch on the details of what's available.

For more info on jstation, see:  http://www.qsl.net/n6lyt/

Bdale, N3EUA


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

Re: deb + tar + bzip2 suggestion

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

I'm the tar maintainer for Debian, among other things.

: -z filter through gzip, bzip, bzip2 as appropriate

: That would be a nice thing. 

But really hard to get right for compression.  :-)  For decompression, it is
conceivable that you could pick the right executable based on magic number or
something, but I'm pretty sure the upstream tar maintainer wouldn't go for it.

I'm satisfied with the current situation where both gzip and bzip2 are 
supported by their own command-line options.  Heck, you can even call 
'compress' if you have it with the Z option...

: If tar would behave like that, one could
: make gzip or bzip2 deb files depending on once likeing.

Not without changing the definition of and standards associated with .deb 
files.  That's far more significant than just changing tar's behaviour.

The bzip2 tool is vastly less well deployed than gzip, so you'd be making
it much harder for folks not running Debian boxes to play.  You would also have
to add bzip2 to the base/essential list in Debian, and it's not clear to me
that having two compression engines in base is a good use of floppy space.

Put me on record as not being thrilled about this proposal.

Bdale


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

Re: deb + tar + bzip2 suggestion

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

:> Debian tar has a patch which hands off files to bzip2 if the -I option is
:> passed to it.

: Why wasn't the -z option expanded to recognize the bzip2 signature?
: That would seem to be a better solution to me.

Because the options are used both on compress and decompress, and it's not
obvious how to pick a compression engine on the compression side.  It's also
not clear that changing an existing option's definition without the upstream
maintainer's involvement is a good idea.

Bdale


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

Re: bzip2 X

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Hmm... it's actually probably a good idea to bzip2 the X sources.
: They're monstrous.

Probably a good idea.  However...

The right way to handle this is for someone to broach the subject of using
compressors other than gzip for source packages over on debian-policy.  At
the same time, take up the issue with the dpkg maintainers since dpkg-source
will need to be updated.

As maintainer of gzip for Debian, I do not agree that having gzip fork a 
bzip2 when it sees a bzip2 magic number is a good idea.  If we want to support 
multiple compression engines, I believe this should be handled in dpkg-source.

Bdale


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

Re: cruft : great program ! everyone should use it !

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: with MAKEDEV -I you can create device files in the local directory,
: even within fakeroot. what about adding a list of the normal devices to cruft,
: and report obsolete devices, strange permissions, etc. this would require
: some cooperation with the makedev maintainer, but would be realy good.

WARNING WARNING WARNING

The makedev maintainer (that's me) intends to change upstream code bases in
a significant way for slink.  Any work on device file consistency in cruft
would be well-advised to wait a month or three, until this gets done.  I'd hate
to see a lot of work go into whacking around with the current MAKEDEV since I
can't guarantee that the options will all be the same, etc...

Bdale


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

Re: Bug#21726 (tar: doesn't dump files to /dev/null)

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Yes, I know it may be too late to be changed, but are there any hints whom
: to contact to get this "fixed"?

The upstream maintainer, of course.  Read the /usr/doc/tar/README.Debian file.

Also, note that if you pipe tar's output through cat or dd on the way to 
/dev/null, you won't trip the test for the special handling of /dev/null. 

: Am I the only one who dislikes this behavior?

I have no idea.  It doesn't bother me at all. 

Bdale


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

Re: Only m68k and i386 in hamm?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Finally, realize that packages-wise, we probably rival RedHat's Alpha
: port---something on the order of 800+ packages are available on the
: Alpha.  However, that's *half* of the number available in Debian/i386.

That raises an interesting question, that I've thought about quite a bit...

What constitutes a "port" that is complete enough for distribution?  

I personally think that if all of the packages marked as 'standard' or higher
are there and working, it's good enough for me to think we should release it.
That is obviously a far cry from "everything", but my guess is we'll never 
have 100% occupancy of all packages on all platforms, even if for such reasons
as MILO only being used on Alpha, LILO on i386, and SILO on Sparc.  So, where
is it ok to draw the line?

One of the questions we ask ourselves at my place of daytime employment goes
something like:  "At what point is our drive for perfection no longer helping 
our customers, but in fact hurting them by causing the stuff we've done that 
does work to not be available to the folks who could use it and don't care 
about details at the margin?"  I think we should ask ourselves that here.  In
fact, it's a good question for the 2.0 release process overall.

I'd like to propose that if a non-i386 architecture has a reasonable 
installation process and base archive, plus .deb's for all packages marked 
as 'standard' or higher in the i386 tree (modulo obvious exceptions like lilo),
that it be considered ready for inclusion in a release.  

Thoughts?

Given the current state of the Alpha port, this objective may or may not be
attainable for a 2.0 release.  I don't currently have (much) time to help, 
though I have put a fair amount of time into the Alpha port personally in 
the past.  But on the debian-alpha list, I see some flailing since we don't 
have a solid definition of what needs to be present for a release to be 
considered ready, and without such a goal, it's hard to focus and concentrate 
effort on what needs to be done.

Bdale


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

Re: bzip2 X

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: fast. Its not agood solution, so thats why I asked here about
: integrating bzip2 support into gzip. 

Points well taken.  You're just asking in the wrong place.  You should take
this up with the gzip upstream maintainer.  It is not a Debian packaging 
issue, it is a request for a fundamental change in the functionality provided
by gzip.  If bzip2 algorithm support were to show up in a future gzip release
I'd be as happy as the next guy. 

If the gzip upstream maintainer doesn't fold in bzip2, then the right solution
is for this to be handled by applications like dpkg-source... not by having 
the Debian gzip functionality diverge from the FSF gzip.

Bdale


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

new tar behavior and --wildcards

[Bdale Garbee]

The new tar behavior with respect to wildcards is not a change I
introduced just for Debian, it's a new upstream change that appears to
be quite intentional and well documented, as per this text from the tar
info docs:

   The following table summarizes pattern-matching default values:

   MembersDefault settings
   --
   Inclusion  `--no-wildcards --anchored
   --no-wildcards-match-slash'
   Exclusion  `--wildcards --no-anchored
   --wildcards-match-slash'

   -- Footnotes --

   (1) Notice that earlier GNU `tar' versions used globbing for
   inclusion members, which contradicted to UNIX98 specification 
   and was not documented.

Obviously, the problems reported with various Debian utilities are due
to the default now being --no-wildcards for inclusion combined with a
dependency on the footnoted "feature" of previous versions of GNU tar.

Since this seems to have been an intentional behavior change by
upstream to better align with a published standard, I'm uninclined to
fight it, and think our best response is to update our utilities to
include the --wildcards option, with a suitable versioned dependency on
tar.

Bdale


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

Re: Another weird tar issue (100 character filenames)

[Bdale Garbee]

On Tue, 2006-06-27 at 13:09 +0200, Jeroen van Wolffelaar wrote:

> But on the other hand, according to the 'be strict in what you send,
> liberal in what you accept' mantra, it makes sense for tar to not create
> tarfiles which in the past have caused issues for certain programs while
> there's a perfectly fine way to create tarfiles which cannot trigger
> such bugs.

Might the patch in #230910 need to be re-crafted and re-applied?  The
code has changed enough that it wasn't obvious to me when moving to the
new upstream that we still needed this change, but perhaps we do.

If you have time to try the attached patch and let me know if it solves
your problem, I'd appreciate it...  I *think* this is a relatively
equivalent set of changes for the current version of tar.

Bdale

Index: create.c
===
RCS file: /cvs/bdale/debian/tar/src/create.c,v
retrieving revision 1.22
diff -u -u -r1.22 create.c
--- create.c	22 Jun 2006 21:06:13 -	1.22
+++ create.c	28 Jun 2006 23:22:15 -
@@ -633,7 +633,7 @@
   return write_short_name (st);
 }
   else if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT)
-	   < strlen (st->file_name))
+	   <= strlen (st->file_name))
 return write_long_name (st);
   else
 return write_short_name (st);
@@ -1310,7 +1310,7 @@
 	  block_ordinal = current_block_ordinal ();
 	  assign_string (&st->link_name, link_name);
 	  if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT)
-	  < strlen (link_name))
+	  <= strlen (link_name))
 	write_long_link (st);
 
 	  st->stat.st_size = 0;
@@ -1595,7 +1595,7 @@
 	}
   buffer[size] = '\0';
   assign_string (&st->link_name, buffer);
-  if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) < size)
+  if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) <= size)
 	write_long_link (st);
 
   block_ordinal = current_block_ordinal ();

Re: new tar behavior and --wildcards

[Bdale Garbee]

On Wed, 2006-06-28 at 10:36 +0200, Bill Allombert wrote:

> > Here, the only way seems to be putting an entry in NEWS.Debian (for
> > users script, ie things not under our control).

Good idea, Christian.

> In addition, I would suggest we reinstate the previous behaviour, but
> display a warning when wildcards are used but --wildcards is not set.

The problem with this is that generating a new warning can also cause
people to need to update scripts, since lots of people seem to parse the
output of commands like tar in wrapper scripts.  So, I'm not convinced
that this is really a good idea.  I'm also always hesitant to deviate
Debian default behavior for utilities like tar from upstream.

All in all, I'm not yet convinced that reverting to the old wildcard
behavior is the right thing to do.  I've only heard about problems in a
few (four?) packages so far, and all of them are Debian-specific
programs that should be easy for us to update.  I see no need for panic,
though it's obviously and clearly regrettable that the packages in
questions are ones that affect processes like building and testing
Debian packages.

Bdale


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

Re: new tar behavior and --wildcards (proposed middle ground)

[Bdale Garbee]

[EMAIL PROTECTED] (Barak A. Pearlmutter) writes:

> As a compromise that addresses some of the issues I would suggest the
> following: go with upstream, but add some convenience code, to whit:
>
> (1) Hot-wire tar to check an environment variable TAR_WILDCARD_DEFAULT
> and activate the --wildcard option if set.

I'm not sure I see the point of this.  The warnings/errors generated seem
reasonably obvious, and inventing an additional, less-obvious mechanism 
instead of just assuming people will try --wildcard when tar suggests it 
seems like a step in the wrong direction.

> (2) Hot-wire tar to print a warning message to stderr if it
> (a) is defaulting to the --no-wildcard behaviour and,
> (b) it notices a filename that, had tar instead been
> in --wildcards mode, would have been expanded.

Actually, tar already does this.  I realize now that you must not have actually
seen the warning in question, which helps explain to me why you were suggesting
(1) above.  

Bdale


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

where to put packages?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: ... and the expected destination of those files.

That raises an interesting question for me, my apologies if it's docuemented
somewhere that I haven't found yet.

What's the protocol for picking a directory to dump a new package in?  

It was pretty easy for the 'watch' utility I packaged as my first attempt to
choose 'misc', but if I submit to Bruce's arm-twisting and package some of 
my 29k cross-development tools, it almost seems like they'd deserve a new 
subdirectory like 'cross', or maybe 'embedded' (since they're for doing 
software for embedded systems?), and if I chose to package up the latest 
cut of dosemu which I just got working (fairly trivially, I might add), 
then it's not at all clear to me where to put it?  Maybe "games", since DOS 
is just a toy?  :-)

Bdale

Bug#1750: tar doesn't handle default remote arguments

[Bdale Garbee]

Package: tar
Version: 1.11.8

When attemping to do remote tar operations using the archive name systax
specified in the info file, which is "[EMAIL PROTECTED]:file", if user is not
specified, tar core dumps, when it should use the current username as the
default.

This is probably part of the same problem that resulted in bug report
#1110, but the problem is sufficiently different from what was reported
before that I decided to elaborate.  Feel free to attach this to bug #1110
if that seems appropriate.

You can duplicate this by doing

tar tvf winfree:/dev/nrst0

when logged into hipshack as 'bdale', which will generation a segmentation
violation core dump, while using

tar tvf [EMAIL PROTECTED]:/dev/nrst0

works fine.  Blech.

Bug#1752: inewsinn recommends trn

[Bdale Garbee]

Package: inewsinn
Version: 1.4sec-7

I find it *really* annoying that inewsinn recommends trn, since I want tin,
which requires inewsinn or inn, but don't want trn.  This makes me have to
go through conflict resolution every time.

Isn't it sufficient that trn and tin require inn or inewsinn?

Bdale

Bug#1753: trn recommends, instead of depends

[Bdale Garbee]

Package: trn
Version: 3.6-2

It's not clear to me why trn uses 'recommends' for a mail transport
and a news article injector, while tin uses 'depends'.  I think that depends
makes more sense, so I'm filing this against trn.

Bdale

Re: inverse of `adduser'?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: *   delete mail spool file (what if it's nonempty?)

Tell the person running the script it's non-empty, and ask if they want it
deleted, anyway.

: *   delete home directory.  What do we do about saving
: files?

Sometimes we want it nuked, sometimes we want it saved.  How about a "do you
want me to remove the users home directory and all its contents?" query?

: *   maybe clean up files owned by the user or their group
: under /tmp and /var/tmp?

I wouldn't bother.  Trimming the contents of tmp directories is a religious
issue.

: *   what about files owned by this user in other
: directories?  (Shared projects, etc.)

We tend to leave them as-is, which I'm not sure is smart.  On the other hand,
a find from / is expensive on a system with lots of disk...

: *   what if the user has processes running?  Or a print
: job queued?  Or mail queued?

Life is too short to worry about this.

: *   there should be a man page ;-)

Of course!

: Maybe it should be possible to delete everything from the home
: directory except a .forward file.

Actually, in my shop we don't allow .forward files to remain for folks who 
have left.  We have a whacked up copy of 'vacation' that is designed to return
the entire message to the sender with a prepended explaination that the person
has left, and where to find them now.  By forcing the originator of the mail
to update their distribution lists and handle the message themselves, we've
discovered that we can get the mail traffic for someone to tail off and get
switched to the new address very quickly.  Subtle, but behavioural engineering
really works...  :-)

Bdale

ps:  I should probably explain that, by day, I'm the Technical Computing
 Manager for HP Colorado Springs, and my staff and I babysit several 
 hundred HP-UX and Sun systems, plus a like number of networked PC's.  
 I'll probably slip into the use of 'we' from time to time, this is the
 context in which 'we' applies, most of the time... :-)

Bug#1780: mh looks in the wrong place for 'more'

[Bdale Garbee]

Package: mh
Version: 6.8.3-2

The 0.93R6 MH mail user interface package causes it to be impossible to
read any mail, since the default moreproc is '/usr/bin/more', and the current
Debian release appears to put more in '/bin/more' instead.  You end up with
errors like:

[EMAIL PROTECTED]:~: show
(Message inbox:386)
show: unable to exec /usr/bin/more: No such file or directory
[EMAIL PROTECTED]:~:

The fix is probably to change the file conf/MH in the source tree, whacking
the line

options SYS5 MORE='"/usr/bin/more"' RENAME SYS5DIR UNISTD SVR4 MIME

to point to the right location for more.

It is possible to work around this defect by specifying an explicit path for
more in the user's .mh_profile:

moreproc: /bin/more

But this shouldn't be necessary.

Bdale

filesystem question for cross-devel tools

[Bdale Garbee]

This is sort of long.  Don't bother unless you care about what /usr's contents
look like, and/or you're desperate for reading material...

I've alluded in the past to my intention to package for Debian the cross
development tools we're using for AMD 29200 embedded systems development.  I
care about this stuff because I'm working on an experimental payload module
for the AMSAT Phase-3D amateur satellite project.  I am motivated, in part, 
to do Debian packaging because most of the rest of my team is running one or 
another version of Linux, and most are willing to switch to Debian if I do 
this and it gets easier for them to track my tools work and stay up to date.

Historically, I've always built the gcc/binutils/gdb/ pieces with a
'--prefix' of something like /usr/gnu or more recently /usr/cross, so that
the whole cross-development "mess" ends up in a tidy subtree.  This, in part,
was because it was easy to clip the tree and hand it to someone else to 
install... partly becuase there used to be naming conflicts before the Cygnus
and FSF folk got the cross-development prefixes working well... and partly 
because it just seemed "messy" to interleave the pieces into the rest of the
filesystem.  Besides, my cross-development tree is bigger than /usr/X11R6, 
even with both the XFree86 *and* X-Inside servers loaded!

On the other hand, I'm trying to be a "good" Debian developer, and follow the
FSSTND.  But, I hit the same "ugliness snag" that the /usr/i486-linuxaout 
(sp?) discussion hits... I can either push the whole tree under something like
/usr/cross, or I can prefix to /usr and end up with a set of directories with
names like "/usr/a29k-amd-coff", "/usr/a29k-amd-udi", "/usr/go32", and so on.
This is because of the way the GNU tools form target-specific directores when
building cross-compilation tools.

For reference, here's what it looks like with two AMD 29k targets built with
a prefix of /usr/cross:

[EMAIL PROTECTED]:~: du /usr/cross
7035/usr/cross/a29k-amd-coff/bin
6   /usr/cross/a29k-amd-coff/lib/ldscripts
1849/usr/cross/a29k-amd-coff/lib
11  /usr/cross/a29k-amd-coff/include/machine
36  /usr/cross/a29k-amd-coff/include/sys
119 /usr/cross/a29k-amd-coff/include
9004/usr/cross/a29k-amd-coff
57  /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0/include/objc
127 /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0/include
12900   /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0
12901   /usr/cross/lib/gcc-lib/a29k-amd-coff
57  /usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0/include/objc
127 /usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0/include
4411/usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0
4412/usr/cross/lib/gcc-lib/a29k-amd-udi
17314   /usr/cross/lib/gcc-lib
18593   /usr/cross/lib
104 /usr/cross/include
16420   /usr/cross/bin
404 /usr/cross/man/man1
405 /usr/cross/man
2443/usr/cross/info
377 /usr/cross/a29k-amd-udi/bin
6   /usr/cross/a29k-amd-udi/lib/ldscripts
1844/usr/cross/a29k-amd-udi/lib
11  /usr/cross/a29k-amd-udi/include/machine
225 /usr/cross/a29k-amd-udi/include/sys
308 /usr/cross/a29k-amd-udi/include
2530/usr/cross/a29k-amd-udi
49500   /usr/cross
[EMAIL PROTECTED]:~: 


So, is this better or worse than if the above had the '/cross' token taken
out, and I set the prefix to '/usr'?

There are no longer any naming conflicts.  The current contents of the
/usr/cross/bin directory, which would end up in /usr/bin if I use a /usr
prefix, are (other cross targets would create similar sets of files/links):

[EMAIL PROTECTED]:~: ls /usr/cross/bin
a29k-amd-coff-ar*   a29k-amd-coff-objdump*  a29k-amd-udi-ld*
a29k-amd-coff-as*   a29k-amd-coff-ranlib*   a29k-amd-udi-nm*
a29k-amd-coff-c++*  a29k-amd-coff-size* a29k-amd-udi-objcopy*
a29k-amd-coff-c++filt*  a29k-amd-coff-strings*  a29k-amd-udi-objdump*
a29k-amd-coff-g++*  a29k-amd-coff-strip*a29k-amd-udi-ranlib*
a29k-amd-coff-gasp* a29k-amd-udi-ar*a29k-amd-udi-size*
a29k-amd-coff-gcc*  a29k-amd-udi-as*a29k-amd-udi-strings*
a29k-amd-coff-ld*   a29k-amd-udi-c++filt*   a29k-amd-udi-strip*
a29k-amd-coff-nm*   a29k-amd-udi-gasp*  protoize*
a29k-amd-coff-objcopy*  a29k-amd-udi-gcc*   unprotoize*
[EMAIL PROTECTED]:~: 


What I'm currently contemplating is one source package (all targets are built
in different object trees from one source tree), and a separate binary package
for each target.  The uncompressed size of each binary package is going to be
on the order of 25-30meg, the uncompressed size of the source tree is about
50meg.  I hope that doesn't cause anyone to panic...

Someone interested in other targets could grab just the source package, and
follow the "Notebook" file instructions I keep there to built a cross-gcc
environment for any supported target... the hard part (getting all the FSF
and Cygnus newlib pieces in one place, and forming the unified source tree) 
would already be done.

Bruce also mentioned the notion that a 'cross-deve

Re: Bug#1887: cfengine 1.2.14-2: documentation errors

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: > We should document what we ship as we ship it.

: No argument, but that implies lots of work for maintainers
: when initially building packages and when upgrading to new
: upstream releases.  I'm not sure that it's practical.

I think it's necessary.  If the package maintainer thinks about it and takes
the necessary action before initial release, that's great.  If someone finds
the discrepancy, reports it as a bug, and it gets fixed, that's ok.  If it
gets reported as a bug and isn't fixed, then I'd get frustrated...

I freely admit that this level of work has kept me from finishing the
packaging of a couple of things I'd like to release to the community.  I
suppose I could relax my own standards and put the bits out since they'd
probably be considered useful even if the docs and post installation config
automation aren't perfect, but I suspect I'll just try to make time to get
them right before universal entropy is maximized...

Bdale

Re: antisocial X11 apps: xtet42, chimera

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: Kenny Wickstrom writes:
: > My X server is 
: > on my Win 95 machine.  So to get xtet42 to install I needed to add the 
: > --force-depends to the dpkg command line.

: xtet42 depends on X11R6 and recommends xserver. This is what Ian Murdoch
: said all X packages should do.

I don't understand why this makes sense, for two reasons.  Ian M, was there
some other good reason for this suggestion that I've missed?

First, in general, I'm not aware of any case (yet) in which a recommends line
has caused me to do anything in an install that I wouldn't have done otherwise,
and in several cases (this one, the inewsnn recommending trn which I don't 
care about problem, etc) it's been a royal pain, and continues to be every time
I update.  Ergo, I think recommends is, at best, too strong.

Second, the whole point of X, to me, is that you can run clients on one machine
and a server somewhere else.  We build products at work that include X clients
in embedded systems, and I've got a variety of systems in my basement that
have networking and X client code but no video hardware at all.  Ergo, I think
that any sort of explicit relationship in the package file between clients 
and servers is counter to the whole point of X, and should be abandoned...  

Bdale

readline and bfd libraries?

[Bdale Garbee]

We're working on code for ground support of the AMSAT Phase-3D satellite that
needs to use the readline and bfd libraries.  We in this context is one other
member of the development team I support cross-development tools for, and 
myself.  John's running 0.93R6, I'm running something closer to in sync with
the development tree.

We're a bit confused.  For readline, it looks as though there are three 
packages on the ftp server under the development tree.  These are devel/librl,
devel/libreadline, and devel/aout-librl.  I presume from this that the librl
package is the one we want for ELF development?  If so, it appears to me that
only a shared library is being provided, which both shared and archive libs
are present for aout-librl.  Am I correct, and if so, why?  I gather that we
need to use a static link to get debugging to work?  I get the feeling here
that we're victims of work in progress, since I don't understand why both
libreadline and librl packages are out there.

For libbfd, it appears that a shared library is provided as part of the
devel/binutils package.  However, the info pages are not provide, nor is an
archive lib.  Why not?  Are we just the first folks to write code outside the
binutils package that cries out for the bfd library?  I can (and have already)
pull the required pieces from one of my cross-development build trees, but
that seems like a bogus approach.

If we're missing something simple, I hope someone "in the know" can help
clarify the situation.  We'd really like to see the readline and bfd libraries
available as useful pieces of the devel set, since we have strong 
dependencies on both.

Bdale

Re: One question upon INN (and syslogd)

[Bdale Garbee]

I accidentally sent this to just Ian the first time, here it is again...

In article <[EMAIL PROTECTED]> you wrote:
: Martin Schulze writes ("One question upon INN (and syslogd)"):
: > These logfiles are not turned with savelog by cron.sysklogd. Are they
: > turned by cron.inn? If not I might have to include this in the
: > cron.sysklogd file.

: They ought to be rotated by the INN package - but the INN package is
: broken, orphaned and withdrawn.

The *must* be rotated by an INN package, since the server needs to be 
manipulated during the rotation to get things right and not lose articles 
if you're using nntplink in logfile mode to drive downstream sites.

Please don't touch these in the sysklogd package.

I manage a large Usenet site inside HP, and need to get INN working on Debian
to convert my last machine at home from BSD/OS... ergo, I'm close to biting
the bullet and building/packaging INN and nntplink, even though I don't really
want to spend the time right now.

Bdale

Re: Bug#1978: man: default pager should be less

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: >Something ought to be done though, since more(1) can't be made to go
: >backwards through manpages.  This is rather a serious deficiency.

: HP-UX's more(1) doesn't allow you to go back at all. Ever. :)

Until HP-UX 10.X, at which point it has very less-ish behaviour.  Check the
man page, or just hit 'b' by accident thinking you're in less, and be amazed.

It's the little things that make you so happy sometimes...  :-)

Bdale

Re: solving some of our FTP problems

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: I think we should arrive at a happy medium - uploads
: are verified against their .changes file and moved into an accessable
: area that is not their final resting place. Ian can then move them, with
: the confidence that their integrity has been checked, to their place in
: the archive.

Boy, this makes lots of sense.  I'd suggest a 'Pending' directory at the same
level as 'Incoming'.

This solves the problem, since Pending wouldn't allow uploads, and only things
that look like packages with changes files for which all the pieces look 
intact would be copied.  Scripting this doesn't seem hard, either... wake up
once in a while, look for changes files, for each one confirm the presence and
integrity of the pieces mentioned in the changes file, if all matches mv the
files...  then delete anything older than some threshold to keep Incoming from
filling up with aborted attempts, etc.

Bdale

Re: solving some of our FTP problems

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: 
: I'd love that feature too. But that either requires a damn good script, or
: that everybody uses the same .changes format. 

"Obviously", everyone should use the same .changes format... but I don't care
what that is, which is why I stayed out of the discussion the last time it was
underway.

: Given that we had that a rather use- and resultless discussion about a "human
: readable" vs "machine parsable" format, I am not sure whether we can arrive
: there.

I never saw the conflict as unresolvable, and I bet that if some useful
automation (like what is proposed here) would result, everyone might feel
differently about the value of coming to concensus.  If we're just arguing 
about what do or don't like to read on the list, and some hypothetical 
automation, it's less real than when there's a specific result we're trying
to achieve.

: I like Bill's "dchanges" and use it. Do I dream when I think we could
: establish the use of posting PGP signed dchanges output?

I've thought about this a bit, and I wouldn't classify adding PGP signatures
to the posted dchanges output as something that's really important to do really
soon.  However, if we were to open up dchanges for some work, and built some
automation around the package upload process, then it would certainly seem
reasonable to consider adding this while we're at it.

I'm too busy right now (got other folks arriving here tonight and tomorrow to
integrate pieces of the satellite payload I'm working on... as a hobby!), but
if there's any sense of a concensus that the Pending directory concept is
worthwhile, I'm willing to work on the tools, say, in the Jan/Feb timeframe.

Bdale

Re: Announce: new libgdbm, libdb and libreadline

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Here are new versions of libgdbm, libdb and libreadline.

I can't find these anywhere, and it's been a couple of days since the 
announcement?  I really, really, want to install libreadline-2.0-9 ASAP.

Bdale

Bug#2058: showpicture requires csh

[Bdale Garbee]

Package: metamail
Version: 2.7-1

The script /usr/bin/showpicture provided with the metamail package, which is
used by Netscape, et al, to launch xv or xloadimage to display graphical
objects, is a csh script.  There is no dependency specified by the metamail
package, and csh is not part of the base system.

My preference would be to see showpicture rewritten to use something other
than csh, since I have no other reason right now to care about csh.  However,
an acceptable fix would be to update the dependency information in the
metamail package so that csh gets loaded too.

Bdale

Bug#2063: scsi driver sequence unreasonable

[Bdale Garbee]

Package: source
Version: 1.3.43

The file drivers/scsi/hosts.c defines the sequence in which different SCSI
controller cards are identified.  The AHA152X driver appears early in the list,
which is unreasonable if there is another, smarter, SCSI controller in the
system... since it will result in the 1510/1522/1522/etc card assuming the role
of the 0th SCSI channel.

It seems to me that the "smartest" or "fastest" cards should be listed first,
since it seems obvious that if there are multiple cards in a system, that the
fastest one should be the default for the first SCSI channel.  In my case, I
have systems with 1542B and 1740A cards which also sometimes get a 1510 card
when I need a long cable run to an external box, or more devices, or something.
I've just moved the AHA152X driver to near the end of the list, but it seems
that a more general review of the sequencing of SCSI card discovery is in
order.

Bdale

Bug#2064: aha1740 driver only supports one card

[Bdale Garbee]

Package: source
Version: 1.3.43

The SCSI device driver for the AHA1740 only supports one card in a system at
one time.  This is annoying.

Bdale

Bug#2065: single user isn't

[Bdale Garbee]

Package: base
Version: 0.93.6-13

It is utterly unreasonable for the system to try and do fsck's when the
system is booted with 'linux single'.  The whole point of a single user boot
is that something is wrong that needs reasoned attention from a system
adminitrator.  A single-user boot should do absolutely *nothing* that isn't
required to drop the system admin into a shell.

This caused me considerable grief when one of the disks on my system was
starting to fail, and I was desperately trying to extract a few critical
files that had been updated since the last backup.  The cycle was to boot,
snag a few files before the disk warmed up and failed, then power down to let
things cool off, then repeat.  The insistence of the system on doing fsck's
at every boot made this a much less productive process per unit time than it
could/should have been.

Bdale

tar-1.11.8-3

[Bdale Garbee]

This release fixes the problem with specifying a null username when a remote
tape is specified to the 'f' argument.  Previously, unless the fully qualified
form of

[EMAIL PROTECTED]:/dev/tapename

was used, a segmentation violation and core dump would result before anything
else happened.  It turns out that a null pointer was being dereferenced when
the username was not specified.  With this release, the user defaults to the
current user, so the form

host:/dev/tapename

works fine.  There were several essentially duplicate bug reports that this
release allows me to close.

I've made contact with the upstream maintainer, and his changelogs indicate
that I may be able to close some other open Debian tar bugs once I get a fresh
code snapshot to work from.  We'll see.

Bdale


Date: 27 Dec 95 07:46 UT
Source: tar
Binary: tar 
Version: 1.11.8-3
Description: 
 tar: GNU tar.
Priority: Low
Changes: fix problem with null username in remote tape path specification
Files:
 -rw-r--r--   1 root bdale  688876 Dec 27 00:41 tar-1.11.8-3.tar.gz
 -rw-rw-r--   1 bdalebdale2850 Dec 27 00:42 tar-1.11.8-3.diff.gz
 -rw-r--r--   1 root bdale  144332 Dec 27 00:40 tar-1.11.8-3.deb
 cce6ed804da368246270903bce6174dd  tar-1.11.8-3.tar.gz
 0bac95ca8e4fc91be3b043825739f46e  tar-1.11.8-3.diff.gz
 12e9daa8f03172b6bc6af7686c98e8a1  tar-1.11.8-3.deb

Re: Bug#2063: scsi driver sequence unreasonable

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: It doesn't really matter if a 152X gets detected before a high-power
: whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root
: on any SCSI controller you like.

You are correct, of course, Jeff, but the problem with having a card like
a 15[12]X recognized first is that if you have machines like mine, which all
have one fast controller that's always there and has the root on it, and you
then stick 1510's in from time to time when you need to temporarily hang
an external disk chassis on, or put a tape drive on, or something else that
is transitory, you have to go through contortions to boot because what 
normally would be the 0th SCSI controller isn't any more, though it may be
again shortly.

This seems unfortunate.  The other OS's I've had experience with (and there
are many on the list) always made it possible to either nail down hard where
the root disk was going to be, physically, or they sequenced driver discovery
"correctly" to handle this case.  None have been perfect for all cases, but
all treated my needs better than Linux currently does.

I'm not going to get upset no matter what Simon decides to do, because I
suspect I'll be building custom kernels for most of my machines no matter
what, but I wanted to make sure that the "silliness" of the current approach
in my eyes got registered someewhere and fed back upstream.

Bdale

Bug#4057: compress package install additional zcat

[Bdale Garbee]

> Hmmm. This is somewhat more complex than it looks like. I cannot just
> remove /usr/bin/zcat because it is intimately linked with compress.

I disagree.  The job of a package maintainer includes the process of doing
things like this to a package.  I have to do the same thing for the tar 
package, for example, where we've agreed that the tar package will not 
provide the 'rmt' executable, even though the GNU tar upstream sources makes
it easy to include and annoying to remove.

The complexity of handling alternatives just isn't worth it for silly stuff
like this.

> If you say 'man compress' for example you'll get the synopsis for zcat
> too and if the corresponding zcat would not be provided then I think
> users can be confused.

By definition, a Debian system will have 'zcat' from the gzip package, since
gzip is an essential base package.  I don't see a problem here.

> In addition I have no control about what programs will be built by
> make-cpkg.

Why not?  I haven't looked at your compress package, but I can't see what the
problem would be, offhand.

> My opinion is that gzip should *not* provide /bin/zcat but rather
> /bin/gzcat (and the same for other z* tools).

I disagree.  Prefixing stuff with the 'g' isn't particularly useful.  In this
case, the 'zcat' provided by gzip is a *superset* of the functionality provided
by the 'zcat' in the compress package, and I can see no rational explaination
for preferring the version that comes with compress over the version that
comes with gzip.

> people should refrain from using zcat in scripts when the
> intent is to gunzip something...

Why?

>   If gzcat was provided and /usr/bin/zcat a symbolic link to it, the
> zcat link would correctly be diverted by any compress-package
> generated package and nobody would have two semantically different
> zcat commands installed by installing these packages.

Why don't you just make your compress package *not* provide the 'zcat'
command, since any Debian system by definition has the gzip package 
installed (since it's an essential base package), and the 'zcat' provided with
gzip is a superset that will always do the expected thing with a compressed
file?

I continue to be willing to convinced that I'm wrong about all this, but so
far, all you've done is to say that "gzip's zcat does more than the one that
compress provides", which I already knew... and then whine about how it's 
hard to make your package do what it should given what's already provided by
gzip. 

Bdale

tar_1.11.11-2

[Bdale Garbee]

This is a new upstream release of tar.  Thanks to Erick Branderhorst, we've
now got NLS enabled, and a few other tweaks.  

Erick uploaded a -1 version that included /bin/rmt, which we had agreed would
not be provided by the tar package.  This -2 version fixes that, and makes a
few other small tweaks to the documentation, etc.  If you installed the -1
version, please upgrade to this version ASAP.  

Much bug-fix work has been done to tar since the version that is included with
1.1, but this rev hasn't been very thoroughly tested, so caveat emptor!

Bdale

-BEGIN PGP SIGNED MESSAGE-

Date: 08 Aug 96 04:00 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
Source: tar
Version: 1.11.11-2
Binary:  tar
Architecture:  i386 source
Description: 
 tar: GNU tar.
Changes: new upstream version - don't install the 1.11.11-1 package!
Files:
 5f0b154ba71762e0e6a95e40229bc514  861943  base  -  tar_1.11.11-2.tar.gz
 6696add7db9de1ca9952da1a29125b68  5702  base  -  tar_1.11.11-2.diff.gz
 0f5bdd3298e810cc741a18e3a75ea275  254164  base required tar_1.11.11-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQCVAwUBMglmp+qS7YWdYhDJAQE4mgQAhc2tSOSyqg9N2BKB66q+JNFI0/lifvUd
tm3wPfAkmIeIrN256weWQiYR6I1FAJ1E6UVE28PtdhZAYX3VassJi/kZijBKwj+K
5831hSKvawq6EjbD7A6yLjiPP7UGA22O//+soX61/iCzx53mKMPt2vHkdyGuDJ5Q
PEtnA/wOXkg=
=bGwb
-END PGP SIGNATURE-

Re: Releases other than by the package maintainert

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: > When mainstream is updated, hello-1.3 -> hello-1.4
: > Non-usual-maintainer updates, hello-1.3-8 -> hello-1.4-0.1
: > Usual-maintainer updates, hello-1.3-8 -> hello-1.4-1
: > 
: > Usual-maintainer should never use -0 for revisions.
: 
: I think this seems reasonable.  I propose to mandate it.

Do it.

Bdale

Bug#4259: files in wrong directories?

[Bdale Garbee]

Package: ftp.debian.org

It appears to me that some files are incorrectly placed directly in the
buzz-fixed tree, instead of being in buzz-updates with appropriate
symlinks in buzz-fixed... all on master.debian.org.

The files in question:

buzz-fixed/source/manpages-de_0.1-4.tar.gz
buzz-fixed/source/mount_2.5k-1.diff.gz
buzz-fixed/source/mount_2.5k-1.tar.gz
buzz-fixed/source/manpages-de_0.1-4.diff.gz

Bdale

Re: BSD lpr vs. LPRng

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: 
: The only incompatibility is that you might have to add a :bk: entry to
: the printcap in order to print to a BSD-lpd-based network printer. 

I care a lot about compatibility with other BSD'ish lpd-based systems.  I 
could live with this easily.

Bdale

Re: Bug#4378: incomplete Packages files and incomplete distributions

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: I don't know of a longterm solution short of
: duplicating the contrib and non-free trees into stable and unstable
: versions.

During the time when I was "master of master", I was working on a proposal for
restructuring the hierarchy... and this is the same conclusion that I came
to.  Right now, the contrib and non-free trees are, by definition, "unstable"
since they aren't frozen at release time.  I don't think this is very nice
for folks who are trying to run "latest stable" bits all the time.

As an aside...

Another way of looking at it that I spent some time on one weekend is that 
what you really want on the FTP server is something like a versioned filesystem
effect, where you could have an "object pool" of packages with potentially
multiple revisions per package present.  Each "release", and indeed the
"unstable" tree, would just be symlink trees pointing to the appropriate
revisions in the object pool.  If you picked a reasonably sized amount of disk
for the object pool, you could then treat it sort of like a cache, ensuring
at all times that any object which is the target of a currently-maintained
symlink stays around, and all other versions of objects get tossed out using
an LRU strategy as new objects are uploaded.  It's a very neat idea, and 
solves a handful of problems, but it presents a problem for mirror sites or
users who want to get just the objects associated with a given revision.  It's
not clear to me how you'd train an ftpd to know when it should return a tree
of symlinks, and when it should return a tree populated with the objects that
the tree of symlinks on the server point to.  Oh well, next time I'm resting
I'll think about it some more...

: Our ftp hierarchy is already too complicated.

Flexibility often drags complexity along.  I thought it would be easy to make
'contrib' and 'non-free' be directories at the same level as 'base', 'devel',
and so forth... but met some reluctance about "making it harder" for CD-ROM 
folk to do the right things by having these trees exist inside a release tree.

: > An older version of gs, which is in /buzz and which would do with
: > the existing gsfonts package, cannot be installed, because dselect
: > picks only the newest version.
: 
: It seems overloading the gs name is causing problems.  Joost, the
: maintainer of both gs's, offered several times to rename them to gnu-gs
: and alladin-gs and let them conflict.  Perhaps this needs to be done.
: Ian?

It'd be nice, in my mind, if they were 'gs-gnu' and 'gs-alladin' so they sort
together, etc...

: > and to automatically check whether all the packages
: > others depend on are really there.
: 
: An automatic dependency check would be useful.

Yep.  Seems like a report to the owners of packages in question indicating
issues with the dependency tree for files installed in the stable/unstable
hierarchies would be generally useful.  I don't have time right now, or I'd
offer to write it.  A release criteria should certainly be that all of the
dependencies specified by packages in the stable tree can be resolved by
packages in the stable tree.  Our recent discussions about dependencies
crossing the boundaries between normal/contrib/non-free trees indicate that
some checking up on what's really being done is probably a good idea...

Bdale

Re: Bug#4378: incomplete Packages files and incomplete distributions

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: Why not just have rex-non-free rex-contrib and rex, etc.

I suppose this would be ok, but my own reasonableness trigger would jitter
less if it were something more like

rex/free
rex/non-free
rex/contrib

You end up with fewer symlinks for the 'stable' and 'unstable' pseudo-trees,
too.

Bdale

Bug#4391: gzip -cd gives incorrect output

[Bdale Garbee]

> Package: gzip
> Version: 1.2.4-11
> 
> Execute these commands on the gzip file attached:
>   gzip -cd a.gz
>   gunzip a.gz; cat a
> 
> The output of the former is clearly incorrect.

I can't seem to duplicate your problem.

> Note that
> if the output is redirected or piped then the errors
> disappear.  This occurs in both xterms and virtual consoles.

I played various games with and without redirection.  I don't see any obvious
differences between the output of 'gzip -cd a.gz' in an xterm using ctrl/s to
stop the flow, and a cat of the previously uncompressed file.

Can you cut&paste the output of the above two command strings to a file and
mail it to me, or something, so I can see what you're seeing?  I'd also 
suggest you verify the md5sum of /bin/gzip:

a10f552f8e26d5c23e61a6a5415e3427  /bin/gzip

Bdale

Bug#4391: gzip -cd gives incorrect output

[Bdale Garbee]

> What happens is that the first page is displayed over and over again.
> The effect should be obvious if you are able to reproduce it.

Aha.  Nothing like that here.

> Some more info about my system:
> 
> kernel: 2.0.13
> libc5: 5.2.18-10
> 
> I've tried this on a 1.2.8 machine with the same gzip and it doesn't
> happen.  Although the problem exists for 2.0.12 on an alpha.  And gzip
> on SunOS 5.5 doesn't have this problem.
> 
> So which kernel did you use?

Kernel is 2.0.6, libc5 is 5.2.18-9.

>From what you say and what I've seen, this sounds like it's not a gzip 
problem to me...

Bdale

Bug#4405: z*grep don't understand grep options

[Bdale Garbee]

The problem appears to be that the z*grep wrappers don't handle 
arguments which have multiple tokens.  In other words, something like
'-i' works, but '-B 10' does not, since it can't distinguish that '10'
is part of the '-B' argument and not part of a pattern or filename.  If
you can skip the space, as in '-B10', all is well, but that's not a
good general solution.

I don't see any easy way to fix this, short of trying to replicate and
then track the options parser in grep.  I'll forward this on to the
upstream maintainer of gzip, since the script in question is part of
the upstream package.

Bdale

Bug#4618: lyx libraries have wrong permissions

[Bdale Garbee]

Package: lyx
Version: 0.10.3-1

This package installs /usr/X11R6/lib/X11/lyx/ and all child directories with
permissions 750, which prevents lyx from being able to read its own config
files at startup.

My quick hack fix was to run

find /usr/X11R6/lib/X11/lyx -type d -exec chmod 755 {} \;

at which point all appears to be working well.  

Bdale

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

Re: New Source Formats and Source Package Verification

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: BTW:  Do you know anybody who really needs to put all the tools needed 
: to build source packages onto floppies?  :-)

Yes, I do.  A friend has an older laptop that has a floppy drive, and that's
his only current path of getting bits in and out.  He may someday have
something better, but that's it for now.  

The argument holds just as well for folks using slower dialup connections to
pull files, and/or for those who get to pay per-packet for their network
connections.

Bdale


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

Re: a question about BTS severities

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> What do other think, and have you seen seeing the same runaway bug severity
> inflation I have?

Yes.  Submitters seem to think that if they crank up the severity, the bug
will get more/quicker attention.  At least in my case, that just isn't true.

I'm not at all shy about lowering the severity of bugs submitted against my
packages that are reported with excessive severity.

Bdale

Re: couple of nits/warnings

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> tar -zxf control.tar.gz control ./control

You can also use 

tar -zxf control.tar.gz *control

which does not produce an error, and extracts either one.  This is the fix I
supplied for lintian when the tar upstream changed the way pathname whacking
happens in tar... which our tools depended on.  Given that we know what's in
a control.tar.gz, the wildcard is not problematic.

Bdale

Re: Release-critical Bugreport for March 10, 2000

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
> Bug stamp-out list for Mar 10 03:04 (CST)

> Package: dump (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   59935  dump: dump segfaults

A number of bugs have been fixed since the 0.4b12 snapshot that's in potato
now.  I agree with the submitter of this bug that a fresher snapshot should
be released with potato.  I am building 0.4b16, and if it tests cleanly, I'll
upload it for potato before the end of the weekend... should close 8-10 open
bugs total.

> Package: makedev (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   59502  raw ftape devices wrong

I have reviewed Documentation/devices.txt from kernel version 2.3.51, and it
still agrees with makedev on the naming of these devices.  Further, the naming
there seems completely self-consistent.  Since I consider the kernel 
devices.txt file authoritative, and see no evidence that this is a typo, I 
am going to reassign this bug to ftape, and assume that the ftape maintainer 
will fix the device references there as needed.

> Package: ntp (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   59090  slink->potato upgrade (probably) delete config file

This is the problem with the xntp3 meta-package being created from the ntp
sources which have a lower version number than the xntp3 package had in 
slink.  I have had several excellant suggestions about how to fix this, and
expect to upload a fresh set of ntp/xntp3 packages sometime this weekend
which will close this and a few other misc bugs.

Bdale

Re: 14 days till bug horizon

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> Package: sawmill (debian/main).
> Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]>
>   59760 sawmill: Sawmill fails to load -- missing file 
> /usr/lib/rep/0.11/i686-pc-linux-gnu/timers.so

This is filed against version 0.25-1.  The version in potato is 0.20.1-2.1,
which I am using on several machines quite happily.  I use essentially all of
gnome with it except session management... and see none of the symptoms 
described.

I assume this means this is a bug against woody, not potato, and that this
bug should not affect the release of sawmill with potato?

Bdale

Re: 14 days till bug horizon

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> Package: pilot-manager (debian/main).
> Maintainer: Darren Stalder <[EMAIL PROTECTED]>
>   59202 pilot-manager: Method "GetRecord" missing in SyncPlan

The pilot-manager package is quite useful even if SyncPlan doesn't work, which
I can neither confirm nor deny.  If there's a problem and it can be fixed,
great, but don't remove this from potato just for this!  It really isn't
release-critical in that sense.

Bdale

Re: Embedded(/RT) Debian? Embeddian GNU/Linux?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> does anybody know, wether there are ideas or plans to make
> an Debian GNU/Linux especially for embedded and/or realtime
> systems, i.e. "Embedian GNU/Linux"? 

The problem is that "embedded" covers such a huge range these days.  I've
built several embedded systems using Pentium motherboards and smallish units
of compact flash for disk... but I've seen systems with large disks described
as embedded based on what they were doing.

The way I've handled this, and the way I think others I've talked with on IRC
have been handling it, is to in effect build a subsetting tool.  You install
into a spare partition or something the packages you want, then selectively
copy out of that tree the pieces you need for the actual embedded system.  It
would be neat to have such a tool packaged and available as a standard part
of Debian instead of reinventing the wheel each time.

> - packages have to be even more fine-grained, or one does
>   need some options to install packages partially.

Nah, this is far enough from the Debian primary target that I think the right
thing to do is leave the current packaging structure alone, and post-process
an installed system to extract the subset of files needed for the embedded
target.  Even something as simple as a selective copy with configurable 
exclusion lists will do.

> - superior package management;

You really, really, don't want /var/lib/dpkg on an embedded target... it gets
huge quickly.  The trick is to get the benefits of a packaging scheme like
Debian's without having to carry that baggage into the actual embedded system.

Bdale

Re: A "progressive" distribution

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> After reading this nice diskussion with all it's aspects, I want to
> complete the mess and suggest a "distribution" called
> e.g. "progressive" beetween stable(frozen) and unstable.

I gather you haven't read the discussion of package pools in the archive?

First things first.  Let's get potato released, and then get pools and 
flavors implemented before we try to release woody.

Bdale

Re: A "progressive" distribution

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

You know, the whole concept of 'a release' is orthogonal to the way I think
about Debian.  We've been through that before, too, and I understand the
various reasons that it's important for us to "make a release" from time to
time... but I doubt any of my machines will ever run "a release".  The beauty
of the Debian development model in the presence of sufficient network 
bandwidth is that you don't have to wait until some release happens to get
new functionality or bug fixes...  The "package pool" concept on some level 
is just an efficiency hack for managing the master archive site better, but
it is also fundamental enabling technology for supporting the idea of having
multiple simultaneous "flavors" of Debian.

> this is the workhorse of the package pools/rolling release idea, this is
> where there will be the most work to be done, fine-tuning the criteria
> (and probably the source of the loudest and longest debates).

Absolutely.  What I realized after talking to Manoj at some length face-to-face
at the Usenix Tech conference in New Orleans a couple of years ago is that we
will need to have different "snapshots" (I actually don't like that name) 
with different criteria.  He and I had a fundamental difference of opinion
about how automated the package promotion to stability should be.  I think we
both had reasonable approaches, and there's no reason not to implement both
if people want them.

The beauty of the package pool concept is that the cost of each "flavor" is 
pretty low, so there's no reason we can't have a number of them.  Some might
be different levels of stability towards "a release", some might be proper
subsets like Debian Jr.  There are a number of secondary issues, like how 
many versions of each package you can afford to have in the pool before you 
run out of disk space, but those are all manageable... and we'll learn by 
doing.

I gathered from Guy's email a while back that a prototype might be underway
on a Debian machine somewhere.  I have spent a bunch of time talking with the
other developers at work, one of whom gets paid to do revison control and
release management for a living, about this.  I believe there are enough
interested people willing to work that we *will* have something in place 
before woody, but I've promised myself that I won't personally do any more 
work on package pools until potato releases.

Bdale

Re: Single architecture on -announce lists

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> It might be he wants to talk about -changes ? There he's right (and I do
> totally agree with him).

I'm not excited about a list per architecture, but I've often wondered if
only posting to the lists messages for uploads that include source might not
be the right thing... the lists of things uploaded from the autobuilders aren't
particularly interesting, which seeing the changelogs for each new source
upload are.

Bdale

Re: Release-critical Bugreport for March 24, 2000

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> Package: bind (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   59649  bind: Gives core dump

Closed by 8.2.2p5-9, now in potato.

> Package: inn2 (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61030  inn2: fresh potato install won't start

Closed by 2.2.2.2000.01.31-2, now in potato.

> Package: tar (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   60824  tar: doesn't build from source (src/Makefile.in not up to date)

Closed by 1.13.17-2, now in potato.

Bdale

Re: 100Mb/Full Duplex

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> I'm having some trouble, actually with a Cisco 6509 switch, but getting
> it to talk to 20 VALinux machines. My story:

Some folks at work saw similar weirdness with the negotiation on some HP
switch products, their solution was to configure the switch to not do the
auto discovery protocol, but instead have each port on the switch hard
configured, as 100/full for the machines that could take it, and less for
the ones that can't.  Ugly, but functional.

I've never personally seen the problem, and don't know the Cisco switch
products, so your mileage may vary.

Bdale

ITP: pcrd

[Bdale Garbee]

I have packaged 'pcrd', which is a utility for controlling an Icom PCR-1000
radio receiver.  It is probably mostly of interest to amateur radio folk,
and so will go in the hamradio section.

The upstream site for this package is

http://www.mv.net/ipusers/cdwalker/pcrd.html

The PCR-1000 itself is sold by Icom, who have a sales-oriented web page for it
at

http://www.icomamerica.com/receivers/pc/

The package is done, and I'm playing with it now.  I'll probably upload it
sometime tomorrow.

Bdale

RFP: bidwatcher

[Bdale Garbee]

I've built a package of bidwatcher, which is a tool for users of eBay, that
assists in placing and monitoring bids.  I don't really want to maintain the
package, though, so I'm calling for a volunteer to package this for real and
upload it.  I'm happy to provide what I've done so far, but it's just a
dh_make in the root of the package source tree, and a few trivial edits to
the debian/* files.

The original author has abdicated, and a fork has occurred.  I'm currently
using the version from Wayne Schlitt <[EMAIL PROTECTED]>, which can be
found at http://www.midwestcs.com/bidwatcher/.  There is another version
at SourceForge, and the good news is the two folks didn't know they were
working in parallel, and have now agreed to work towards a merge using the
SourceForge site in the future.  The code is GPL'ed, and does not include
the extra wording needed for GPL'ed code linking with QT.  That needs to be
resolved before an upload.

Any takers?  

Bdale

Re: Release-critical Bugreport for March 31, 2000

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
> Bug stamp-out list for Mar 31 03:06 (CST)

> Package: bind (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61129  base: bind upgrade leaves two named's running

I see how this can happen in some odd cases.  Should have a fix uploaded in 
a day or two.

> Package: inn2 (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61077  inn2: apparently all sorts of directory permissions are trash in inn2

> Package: inn2-inews (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61409  inn2-inews: rnews permissions break mail2news gateway setup

I apparently did something moderately stupid in a recent version that broke
a variety of permissions in the inn2 packages.  Should have them fixed and a
new upload in a day or two.

> Package: ntpdate (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61333  ntpdate should replace xntp3

Easy fix, upload tomorrow.

Bdale

Re: Debian bind chroot option?

[Bdale Garbee]

[EMAIL PROTECTED] (Nicholas Lee) writes:

> Are there any thoughts to a chroot install option for bind??  Its not
> that hard to setup, but I wonder how it would fit into the debian
> policy.

I've been thinking about it after 9.1.0 releases, and after I add debconf
support.  I don't run chroot'ed, and I'm not sure how best to set it up despite
having given people pointers numerous times...

Bdale

Re: holding back the tide

[Bdale Garbee]

[EMAIL PROTECTED] (Adam Heath) writes:

> Bdale hates dbs, doesn't know what it is

I don't hate dbs.  I just get annoyed when packages with complicated build-time
patching schemes won't build.  My sense is that each of these schemes increases
the probability of build-time failures by deferring work that is done for most
packages at the source package construction time to the build time... but if
the packages are competently constructed and tested, I don't really care how
they're structured.

Bdale

BIND 9.X package status

[Bdale Garbee]

It was just pointed out to me that there is a new RFP for bind9 packages 
filed to the wnpp part of the BTS.

As the BIND package maintainer, I indicated many months ago my intention to
package BIND 9.X for Debian.  

Unfortunately, the BIND 9.0.0 and 9.0.1 releases contained sources for 
required elements that were not compliant with the DFSG, and so would at best 
have been made available in non-US/non-free.  After the firestorm that resulted
from my putting the 8.X BIND bits in non-free, I decided to try and get the
problem resolved before packaging BIND 9.X.

As a result of discussion with key contacts at the ISC, this issue has been
completely resolved for the upcoming BIND 9.1.0 release, currently in beta.  I
have done quite a bit of work on packages in preparation for this release, and
will be ready to upload shortly after 9.1.0 is finally released.  Note that
unless we change Debian crypto code policy in the meantime, bind9 will show up
in non-US since it includes required crypto-based authentication components.
The ISC happily makes this available for export from the US, so I'm sure we
could too... but until the DPL and FTP admins indicate it is ok to do so, I
will direct the packages to non-US.

Getting this right has two major components that are worth my commenting on
here.  First, the package 'bind' will continue to be 8.X to avoid violating
the principle of least astonishment for our users, and there will be a new
'bind9' package and friends delivering 9.X.  For new installs, the dns server
task package will install bind9 packages.  Second, the 'dnsutils' package
which is priority standard and delivers various DNS related client progrems 
is being restructured both so that I can deliver pristine upstream BIND 9.X 
sources into the archive, and so that future updates to the independent 
components are easier.

In summary, here's what I currently plan to deliver once 9.1.0 is released:

BIND 8 source package including only BIND, producing binary packages

bind- daemon, config files, man pages

bind-dev- static libraries and header files

bind-doc- full HTML documentation tree


BIND 9 source package in non-US because it's DFSG-free but has crypto
code, including only BIND, producing binary packages

bind9   - replaces 'bind' package

dnsutils- the portion of dnsutils provided
  from the BIND sources, plus depends
  on host and rblcheck packages

bind9-lib (?)   - shared libraries ?  these may just
  end up in package bind9, I'm still
  working on the details

bind9-dev   - static libraries and include files

bind9-doc   - full HTML documentation tree

task-dns-server - meta package - task selection system

host source package producing binary package

host

rblcheck source package producing binary package

rblcheck

If there are any questions or discussion, please direct them to the mailing
list debian-devel only... not to the CC list on this message.

Bdale

Re: BIND 9.X, shared libraries, and package pools

[Bdale Garbee]

[EMAIL PROTECTED] (Brian May) writes:

> Does bind come with multiple libraries?

Yes.  Four, I think.

Ok, I haven't looked at our policies for shared libs for a while, and I 
obviously have some reading to do.  Thanks for the warnings.

Bdale

Re: Solving the compression dilema when rsync-ing Debian versions

[Bdale Garbee]

[EMAIL PROTECTED] (Wichert Akkerman) writes:

> gzip --rsyncable, aloready implemented, ask Rusty Russell.

I have a copy of Rusty's patch, but have not applied it since I don't like
diverging Debian packages from upstream this way.  Wichert, have you or Rusty
or anyone taken this up with the gzip upstream maintainer?

Bdale

Re: Solving the compression dilema when rsync-ing Debian versions

[Bdale Garbee]

[EMAIL PROTECTED] (Matt Zimmerman) writes:

> As you know, it's been eons since the last upstream gzip release.

On advice of the current FSF upstream, we moved to 1.3 in November 2000.  

I think it is entirely reasonable to talk to upstream about this before 
contemplating forking.

Bdale

resolution of the tar -I issue

[Bdale Garbee]

I'm satisfied with this solution, and will work with Paul to deliver an
implementation for Debian as soon as possible.

Bdale

--- Forwarded Message

Date: Tue, 9 Jan 2001 12:49:43 -0800 (PST)
From: Paul Eggert <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: can we get rid of -I entirely, please?

> From: Bdale Garbee <[EMAIL PROTECTED]>
> Date: Mon, 08 Jan 2001 09:18:51 -0700
> 
> After lots of discussion on the Debian developer mailing lists, the
> solution that I think makes the most sense is:
> 
> the -I option be removed from the documentation and usage messages
> 
> use of -I becomes an error that communicates that -j is the right 
> option for bzip2, and -T is the equivalent of -I in Solaris tar
> 
> I think this meets everyone's needs.

OK, you talked me into this for the next tar version.  This will give
people time to switch.  We can then reintroduce -I as an alias for -T
in a later version of GNU tar.

--- End of Forwarded Message

Re: News about Debian Conference... and have an happy new year !

[Bdale Garbee]

[EMAIL PROTECTED] (Roland Bauerschmidt) writes:

> Speaking of IA-64: Do we have a machine yet? AFAIK not.

Several Debian folk have acces of one kind or another to IA-64 hardware.  I
am not aware of any IA-64 systems fully dedicated to Debian development.

I am in possession of an IA-64 box from HP on loan to Agilent for evaluation.
Not surprisingly, what I want to evaluate is Debian on IA-64, so we've been
working to build packages, and have a few dozen done, working in a chroot on
top of a TurboLinux installation.

This particular machine has not been very stable, but we just went through a 
processor upgrade to a fresher stepping, and are about to freshen the BIOS.
I am hopeful that this will improve things.

This, of course, is no substitute for someone like Intel or HP explicitly 
making a machine available for dedicated Debian use.  Hopefully Bruce can 
join our other friends in HP to help make this happen soon...

Bdale

help wanted with 'ntp' packages

[Bdale Garbee]

I am unable to spend as much time updating the 'ntp' packages as they deserve,
and so I would like to find someone suitable to either join me in working on 
them, or take them over outright.

There are a number of open bugs that need to be addressed, and I'm completely
unhappy with the current default configuration and debconf utilization.  I
think the resources are all now in place to have a question-free install of
a working default configuration and I'd like to see the packages move in that
direction.  There's a kernel patchset that can help turn Linux into a high-
quality stratum one timeserver that I'm using personally on the system that
my radio clock is attached to, but have never packaged, that might deserve 
more attention.  And so on...

To successfully maintain these packages, you need to understand the NTP
protocol a bit, and it would be helpful to have experience managing a non-
trivial NTP environment.  You need to be willing to deal with an upstream 
that doesn't release very often, and doesn't always care if the software 
is broken on Linux.  And upstream has moved to using BK for their source 
repository, so to be effective in doing more than just keeping up with stable 
releases (which is what I've fallen back to recently), you need to be willing 
to use a non-free revision control system.

If you aren't scared away yet, then send me some email, and/or find me at
Debconf3 and we can talk.

Bdale

Re: mass bug filing on packages that are blocking use of cdebconf

[Bdale Garbee]

On Mon, 2005-09-26 at 19:57 +0200, Joey Hess wrote:

> This is your third and final reminder. I count 542 packages remaining,
> down only 9 from last month. I assume most of the people below do not
> read debian-devel, so I've taken the librerty of BCCing you all. :-P

Yep, debian-devel is not high on my list right now.

> Bdale Garbee <[EMAIL PROTECTED]>
>amanda
>dump

Change made to both packages in my CVS for the next upload.

Bdale


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

Re: Bug#559761: ITP: release -- provides information about the current releases

[Bdale Garbee]

On Thu, 2009-12-10 at 23:59 +0100, Benjamin Drung wrote:
> Am Mittwoch, den 09.12.2009, 09:34 +0800 schrieb Paul Wise:
> > On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung  wrote:
> > > Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
> > >> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
> > >> > For Debian I need some informations: Until when were following
> > >> > releases supported: buzz, rex, bo, hamm, slink, and potato?
> > >>
> > >> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
> > >> information for bo/rex/buzz. Anyone ?
> > >
> > > I found that page, too. The wikipedia page of Debian did not contain
> > > more information.
> > 
> > Try the debian-history package or its maintainer.
> 
> I could not find information about the support period in this package.
> Bdale, do you have more information?

Not offhand.  I welcome patches to improve this part of the content in
debian-history, however.

> Am Mittwoch, den 09.12.2009, 15:05 +0100 schrieb Javier Fernandez-Sanguino: 
> > The proper source for this information is the Project History
> > document, available online at
> > http://www.debian.org/doc/manuals/project-history/ch-releases.en.html
> > or in the debian-history package.
> 
> I could not find end of live dates on this website.

Bdale




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: I hereby resign as secretary

[Bdale Garbee]

Manoj,

As one of the few people around who has been part of the Debian project
as long as you have, please accept my sincere appreciation for your long
history of meaningful contributions... and in particular your lengthy
and honorable service as our secretary!  

You have earned and retain my immense respect, and I look forward to
continuing to work with you to advance our shared interest in Free
Software.

Pursuant to section 7.2 of the Debian Constitution, I acknowledge that
as the current Chairman of the Technical Committee I now also serve as
Acting Secretary until such time as our DPL delegates a new Secretary.

Bdale


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: I hereby resign as secretary

[Bdale Garbee]

> Now if only we could say positive things about people BEFORE they
> resign, wouldn't this be a better place?

+1E6

John, thank you for taking the time to write and post that note.  I couldn't 
agree more.

When Manoj and I joined the Debian project, there were only a couple dozen of 
us, and 
we indeed had a very different and more positive atmosphere.  That was a 
different time,
and in some senses a very different place.  It might therefore be easy to 
accept the idea 
that "things have changed" and that as a result we just have to live with the 
current 
situation.

I don't believe that.  Those of you who know me know that I've never believed 
that.  
There is a quote from Margaret Mead that I often include in the presentation 
materials
when I've giving public talks that I think deserves repeating here:

Never doubt that a small group of thoughtful, committed citizens can 
change the world; indeed, it's the only thing that ever has.

I've often used this quote to help explain why Free Software has been as 
successful
as it has been to date.  I think it also applies here.  Each of us, 
individually, must 
accept personal responsibility for the contribution we make to the overall 
Debian 
project atmosphere.  The only way we can "get things back on track" and 
re-focus our
energy on the real reason we are all here... to create a free operating 
system... is
to assume that each of us has the power to change things and make them better!

In hockey, there is a statistic kept about each player.  If they are on the ice 
when 
a goal is scored by their team, they get a plus one.  If they are on the ice 
when a 
goal is scored against their team, they get a minus one.  In this way, there is 
a 
rough measure of whether having that player on the ice was an overall benefit or
detriment to the team.  Players with a big positive number are highly valued, 
players
with a big negative number are likely to get traded or not have their contracts
renewed for another season.

We don't really have metrics as crisp as goals scored by and against us in the 
Debian
project.  But I believe that each of us has the responsibility to keep a 
personal
"plus/minus" tally in our heads about our own participation in the project.  If 
we
all do that, and all work hard to make sure our personal participation is a net 
benefit to the project, then I honestly believe we can and will achieve better 
results.

Bdale


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: SPI Board Candidates Debate

[Bdale Garbee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Vince Mulhollon" <[EMAIL PROTECTED]> writes:

> I can't participate in the debate at that time and date.  Will a log of
> the debate be available via http and if so, where?

Yes, I'm sure a log of the debate will be made available online after the
event.  I'm not sure where it will be posted, and so I promise that we will
post an announcement with URL to debian-devel-announce and spi-announce as
soon as the log becomes available online.

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

iD8DBQE/tODcZKfAp/LPAagRAnlcAJ9yAR8lyx/mTBCqjuiP4lQwUu31yQCaAiZX
Jr5ZWpoUHPk96MuNjrQks8Q=
=/pi8
-END PGP SIGNATURE-

Re: Shared library defines a RPATH

[Bdale Garbee]

[EMAIL PROTECTED] (Colin Watson) writes:

> Generally speaking, Debian packages aren't relocatable anyway. Many of
> them (unavoidably) end up with paths compiled into binaries.

We may have to deal with this for things like allowing ia32 binaries to run
on ia64 systems... though so far, all of the ia32 libs I've repacked to drop
into the /emul/ia32-linux tree have been fine.

Bdale

Re: MAKEDEV Replacement status

[Bdale Garbee]

[EMAIL PROTECTED] (Don Armstrong) writes:

> If not, I'll just file a bug w/ patch.

That's the right thing to do for now, regardless.

Bdale

Re: testing script

[Bdale Garbee]

aj@azure.humbug.org.au (Anthony Towns) writes:

> On Tue, Aug 27, 2002 at 01:40:09PM +0200, Michael Meskes wrote:
> > I was just told the script updating testing doesn't run at the moment.
> > Is that true? If so, is there a reason? Are we already in freeze? :-)
> 
> It's running, but it's not doing any good. 

Actually, I'd like to point out that I think it *is* doing good... in that
it is providing exactly the distinction between unstable and testing that
it was designed to provide...

I'm sure most of you realize exactly what Anthony was really saying, which 
is that many things aren't promoting from unstable to testing right now 
because glibc is hung up... but I want to make sure his casual use of "not 
doing any good" is taken in appropriate context... :-)

Bdale

Re: account on IA-64 sought.

[Bdale Garbee]

[EMAIL PROTECTED] (Martin Schulze) writes:

>12. http://testdrive.hp.com/

Yes, this can be a good resource.  I also invite anyone working on ia64 
porting issues to the #debian-ia64 channel on irc.debian.org.  There is very 
little activity visible there, but people who can help are often lurking...

Bdale

Re: Referring what kernel-images to build to the technical committee?

[Bdale Garbee]

[EMAIL PROTECTED] (Herbert Xu) writes:

> > kernel where all options were compiled into separate modules so simply
> > choosing the right modules constructs the optimal kernel.
> 
> Guess what, that's how the current 2.4 kernel images are constructed.

Well, not really.  All of the drivers and other pieces which can be delivered
as modules, perhaps... but you're still having to deliver N different
kernel-image packages to handle options that are *not* modular, which is the
root of this whole discussion.

If we step back from the details for a moment, it could be argued that the
presence of so many compile-time-only options in the ia32 support is a kernel
design fault.  However, which options are configurable at compile time only
and which are configurable at run time in the Linux kernel is beyond Debian's
control.

Personally, the combination of a single precompiled binary kernel package for
ia32 and an improved toolset for assisting users with the process of 
configuring and compiling a kernel that is truly optimized for their situation
seems like a better approach than lots of prebuilt kernels...

Bdale

Re: Are build-dependancies mandatory?

[Bdale Garbee]

[EMAIL PROTECTED] (Bas Zoetekouw) writes:

>   If a package requires any binary package in order to be build from
>   source, it must declare a dependency on that package. 

It isn't *quite* that simple.  Explicit build dependencies should only be 
for packages that are neither essential nor build-essential.

Bdale

Re: Are build-dependancies mandatory?

[Bdale Garbee]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> Bdale Garbee <[EMAIL PROTECTED]> writes:
> 
> > It isn't *quite* that simple.  Explicit build dependencies should only be 
> > for packages that are neither essential nor build-essential.
> 
> But it's entirely harmless to mention them; this is an area where it's
> better to err on the side of liberality than frugality.

I'd be tempted to agree with you, except...

I've spent quite a bit of time recently dealing with packages that include an
explicit build dependency on "libstdc++2.10-dev".  This is not necessary since
it is a dependency for an item in build-essential, and is in fact called out 
explicitly in the build-essential documentation.  It breaks the ability to 
build the package with gcc-3.0.  That will matter to everyone eventually, and 
matters to hppa and ia64 right now.

Admittedly, a dependency on, say, 'gzip' is less likely to cause problems in 
the future than the libstdc++ thing... but I'd rather see people craft 
Build-Depends correctly and minimally.

Bdale

Re: Are build-dependancies mandatory?

[Bdale Garbee]

[EMAIL PROTECTED] (Rahul Jain) writes:

> maybe there should be meta-packages for packages that have embedded version
> numbers like that.

In the general case, yes.  In this case, there is no need for one, since the
package in question is build-essential, and so need not be listed in a build
dependency.

I've run into a number of cases where the build dependency for some other
library that is not build-essential is tied to a specific version.  It is hard
to tell quickly if those are "mistakes", or if the package really depends on
a particular version.  So, for now, such packages get marked as 'failed' and
left to rot until/unless they are needed to fill some dependency...

> Or maybe the build-dep on libstdc++2.10-dev indicates that
> the package relies on some g++ brokenness ;)

Heh.  That would be frightening.  So far, the fix for all the packages I have
tried is to just ignore that build dependency and build against a current
version of libstdc++.

Bdale

build dependency alternatives sequencing

[Bdale Garbee]

Fellow Debian folk.

Those of us who run autobuilders have started seeing more cases of a new
class of problem showing up in our buildd email that we'd like your help 
resolving.

It is possible in the Build-Depends specification of a package to give
alternatives using syntax like:

libltdl0-dev | libltdl3-dev

On the surface, this seems like a reasonable thing to use, since it offers
more choice for the person building a package.  However, the sbuild tool that
most Debian autobuilders are using will only try the first alternative without
manual intervention.  The tool probably can and should be augmented to handle
the full Build-Depends syntax, but while doing so would increase our build
percentages slightly, it would also mask what may be some underlying problems.

In many cases, like the one above, the problem may really be that the -dev
version of a library should always be unversioned, like libltdl-dev, with only
one version typically installable at any time for building new programs even
if multiple versions of the runtime are still around.  Sometimes this has been
handled by creating a virtual package for each alternative of a development
library to provide, but I postulate that in most cases that's not necessary.
In any case, when listing alternatives, please always list the newest and most
likely to work with sid one first!

In some cases, it may be that a package changed names or structuring between 
potato and sid, and you're trying to make it possible to build the package on 
more than one version of Debian.  That's fine, but again, please try to put
the package that will work with sid first!

There are a couple of other oddball cases, like 

svgalibg1-dev | svgalib-dummyg1

where svgalib isn't relevant for all architectures.  And, I'm sure there are
other valid and seemingly-valid reasons for using the alternatives syntax in
a Build-Depends specification.

What I'd like to ask is that you realize that there is a "preference" implied
by the alternatives syntax, with the first alternative listed being the one 
that will be tried first (and perhaps only!) by the autobuilders.  Thus, it 
would help a lot if everyone would try to put the package most likely to allow
building on the most architectures in sid first.

Thanks.

Bdale

Re: bind9-chroot (was: questions on ITP)

[Bdale Garbee]

[EMAIL PROTECTED] (Martin F Krafft) writes:

> i don't think a global solution is a good choice here. if i install
> bind9-chroot (hypothetically speaking), then bind9 should not possibly
> ever run non-chrooted again. this should be done via diversions.

Eee.  Diversions are so, well, messy.  I think the obvious right way to 
handle this is to add debconf support to the bind9 package asking whether to
run in a chroot or not, and if the answer is yes, just do it.  As has been
pointed out by Marco and others, bind9 is substantially easier to chroot than
previous versions, so this shouldn't be a big deal.

Having said that, since I don't personally run bind9 in a chroot, I continue 
to be willing to accept a clueful patch to the current bind9 source in non-US
to implement this... but am in no big rush to implement it myself.

Bdale

Re: dpkg logging

[Bdale Garbee]

[EMAIL PROTECTED] (Wichert Akkerman) writes:

> Previously Steve Greenland wrote:
> > Stdout and stderr from the maintainer scripts. (This may be obvious, but
>> you didn't explicitly list it.)
>
> No, they should use debconf.

Regardless of whether packages are using debconf, I have wondered for *years*
why we didn't at least have the option of logging stdout and stderr from
everything in the install/update process.  I think it's a good idea.

Bdale

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Bdale Garbee]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug

While that's an interesting assertion, the real question is what it means to
"address" a bug.  There are packages with many bugs open against them which
are nevertheless very useful, even essential, packages.  Artificially cranking
up the severity isn't going to make them any better... 

Bdale

Re: orphaned packages in DWN?

[Bdale Garbee]

[EMAIL PROTECTED] (Adam Olsen) writes:

> http://lists.debian.org/debian-devel/2000/debian-devel-23/msg01353.html,
> which says there's a lintian error/warning called
> "ancient-standard-version", which I believe can detect when a debian
> package is far behind the upstream version.

Nope, it tells you when the control file claims the package complies with an
ancient version of debian-policy, which is completely unrelated to the package
version.

Bdale

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Bdale Garbee]

[EMAIL PROTECTED] (Brian Wolfe) writes:

> Actualy, I believe that the mkisofs maintainer should have seen that a 
> new option was created and notified the maintainers of anything that 
> depended on mkisofs ...

That's pushing it, I think.  I've had several experiences as a maintainer
where something in an upstream package changed that seemed insignificant to
me, but which broke some other package that depended on mine.  These events
aren't a big deal if everyone is "engaged" and bugs are getting addressed as
they are reported.

Let's stick to the main problem.

Bdale

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Bdale Garbee]

[EMAIL PROTECTED] (Lenart Janos) writes:

> On Sat, Dec 29, 2001 at 03:30:28PM +0100, Bas Zoetekouw wrote:
> > You wrote:
> > > As you might already have noticed Debian begun to bloat - so many
> > > unneeded, unused, unmaintained(!) packages.
> > > My opinion is that one DD alone couldn't upload NEW package, but he
> > > needs 2 proponent DD who are willing to "give his signature for it".
> > > Just to make it a little more complicated a minimum of 50 word long
> > > justification needed from all the 3 guys (e.g. two proponent DD and the
> > > future maintainer).
> > unneeded and unused? A package that may be not useful for you may be
> > very useful for many others.
> True. But, if you can't find 3 people out of 900 (so 1 out of 300) who
> see interest in a package, then that package is most probably very
> rarely used.

I can't think of any package, offhand, for which I couldn't find two people
in Debian to say yes.  Therefore, I don't see this porposal as providing any
real utility... it just adds process overhead and makes the jobs of people
who are already overworked harder.

> Other thing: there might be a need for a new Priority (or re-arrange the
> current ones). I mean, something like 'Priority: zero' or something like
> that, so they won't even go to the official set of the CDs, etc.

I've thought about this before, too.  It's not entirely clear to me why we
want packages in the distribution we're not willing to see released on CD's
other than for legitimate release-critical bugs, though.

Bdale