Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Anthony Towns]

On Tue, Oct 19, 1999 at 09:56:39PM +, Alexander Koch wrote:
> On Mon, 18 October 1999 13:15:36 -0500, Chris Lawrence wrote:
> > On Oct 18, Anthony Towns wrote:
> > > Another possibility would be someone adding bzip2 support to dpkg et al,
> > > and having .orig.tar.bz2's, and data.tar.bz2. (This actually doesn't look
> > > like it'd be all /that/ difficult, either, just a matter of conditionally
> > > using /usr/bin/bzip2 instead of /bin/gzip. Hmmm.)
> > There's a pending policy proposal to permit the use of bz2 source
> > packages and diffs.  I think dpkg-source is a bit ugly, but it
> > probably wouldn't be too hard for a perl hacker (i.e. not me) to add
> > the support.
> Now, who of the ones that *can* change policy is going to do
> anything on it? Please, can some of those give the many of
> us an idea of what is the problem or (possibly) what I am
> getting wrong?

(a) There's not much point changing policy when the code's not written.
(b) IIRC the policy proposal *requires* .bz2 compression for all sources,
rather than just allowing it, which isn't ideal.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgp2mIP9Gys13.pgp
Description: PGP signature

Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Chris Lawrence]

On Oct 20, Anthony Towns wrote:
> > Now, who of the ones that *can* change policy is going to do
> > anything on it? Please, can some of those give the many of
> > us an idea of what is the problem or (possibly) what I am
> > getting wrong?
> 
> (a) There's not much point changing policy when the code's not written.
> (b) IIRC the policy proposal *requires* .bz2 compression for all sources,
> rather than just allowing it, which isn't ideal.

When the proposal was being discussed, we reached a consensus that it
ought to be allowed but not required.  So the only real issue is (a),
writing the code.


Chris
-- 
=
|  Chris Lawrence |   Get Debian GNU/Linux CDROMs   |
| <[EMAIL PROTECTED]>|  http://www.lordsutch.com/cds/  |
| | |
| Grad Student, Pol. Sci. | Your site belongs here. |
|University of Mississippi| [Commercialize your sig today!] |
=

Re: bitmap and pixmap location

[Branden Robinson]

On Tue, Oct 19, 1999 at 01:01:26PM +0100, Julian Gilbey wrote:
> I've just been looking at Contents-i386 to get an idea of where
> bitmaps and pixmaps are currently stored so that I can set up the new
> system.fvwm2rc file correctly, and I found a mess.  The locations of
> public (as opposed to application-specific) bitmaps and pixmaps are
> currently:
> 
> bitmaps: /usr/X11R6/include/bitmaps
This is wrong.

>  /usr/X11R6/include/X11/bitmaps
This is correct.

> pixmaps: /usr/X11R6/include/X11/pixmaps
This is correct.

>  /usr/share/pixmaps
This is wrong.

> Is there any reason why we can't try to standardise the choice of
> location?  I've brought this topic up before, but hadn't noticed the
> bitmaps situation at the time.

I think we should standardize around /usr/include/X11/{bitmap,pixmap}.

/usr/include/X11 is currently a symlink to /usr/X11R6/include/X11.

Packages should install files in the latter path and refer to the former.

-- 
G. Branden Robinson  |   You live and learn.
Debian GNU/Linux |   Or you don't live long.
[EMAIL PROTECTED]   |   -- Robert Heinlein
cartoon.ecn.purdue.edu/~branden/ |


pgpxcOTdoOXMA.pgp
Description: PGP signature

Bug#39299: dpkg-source patch (Re: #39299 (bz2 format for source packages))

[Chris Lawrence]

Following the .signature is a patch for dpkg that implements bzip2
support in dpkg-source and dpkg-buildpackage.  For example:

dpkg-buildpackage -bz2 -rfakeroot

Note that dpkg-source -x will detect bz2 archives automatically; you
just need to tell it to use bz2 when building.  Also, diffs are not
bz2'ed, since few are over 20k (and thus the extra compression is not
really needed), although they could be.

I freely admit the code sucks, so please improve as needed.


Chris
-- 
=
|Chris Lawrence   |  Your source for almost nothing of value:   |
|   <[EMAIL PROTECTED]>  |  http://www.lordsutch.com/  |
| | |
|   Grad Student, Pol. Sci.   |   Visit the Lurker's Guide to Babylon 5:|
|  University of Mississippi  |   <*> http://www.midwinter.com/lurk/ <*>|
=

diff --exclude=*~ -ru dpkg-1.4.1.16/debian/changelog dpkg-bz2/debian/changelog
--- dpkg-1.4.1.16/debian/changelog  Thu Oct 14 21:04:13 1999
+++ dpkg-bz2/debian/changelog   Tue Oct 19 21:13:57 1999
@@ -1,3 +1,10 @@
+dpkg (1.4.1.17) unstable; urgency=low
+
+  * Non-maintainer release.
+  * Adds bzip2 support to dpkg-source.
+
+ -- Chris Lawrence <[EMAIL PROTECTED]>  Tue, 19 Oct 1999 21:01:46 -0500
+
 dpkg (1.4.1.16) unstable; urgency=medium
 
   * Hardcode ENOENT again since the errno-part of the POSIX module
diff --exclude=*~ -ru dpkg-1.4.1.16/scripts/dpkg-buildpackage.sh 
dpkg-bz2/scripts/dpkg-buildpackage.sh
--- dpkg-1.4.1.16/scripts/dpkg-buildpackage.sh  Mon Sep 27 18:19:11 1999
+++ dpkg-bz2/scripts/dpkg-buildpackage.sh   Tue Oct 19 21:06:31 1999
@@ -30,6 +30,7 @@
  -sd   uploaded src is diff and .dsc only   }
  -nc   do not clean source tree (implies -b)
  -tc   clean source tree when finished
+ -bz2  use bzip2 instead of gzip compression
  -hprint this message
 END
 }
@@ -49,6 +50,7 @@
 since=''
 maint=''
 desc=''
+bz2=''
 noclean=false
 
 while [ $# != 0 ]
@@ -72,6 +74,7 @@
-nc)noclean=true; binaryonly=-b ;;
-b) binaryonly=-b ;;
-B) binaryonly=-B; binarytarget=binary-arch ;;
+-bz2)   bz2=-bz2 ;;
-v*)since="$value" ;;
-m*)maint="$value" ;;
-C*)descfile="$value" ;;
@@ -140,7 +143,7 @@
withecho $rootcommand debian/rules clean $archlist
 fi
 if [ x$binaryonly = x ]; then
-   cd ..; withecho dpkg-source -b "$dirn"; cd "$dirn"
+   cd ..; withecho dpkg-source $bz2 -b "$dirn"; cd "$dirn"
 fi
 withecho debian/rules build $archlist
 withecho $rootcommand debian/rules $binarytarget $archlist
diff --exclude=*~ -ru dpkg-1.4.1.16/scripts/dpkg-source.1 
dpkg-bz2/scripts/dpkg-source.1
--- dpkg-1.4.1.16/scripts/dpkg-source.1 Sun Sep 26 20:17:04 1999
+++ dpkg-bz2/scripts/dpkg-source.1  Tue Oct 19 21:15:23 1999
@@ -265,6 +265,16 @@
 or the empty string (no original source, and so no diff) depending on
 the arguments.
 .TP
+.B -bz2
+Create a source tar file compressed using bzip2 format, rather than gzip.
+Source packages built this way are only compatible with dpkg-dev
+versions 1.4.1.17 and above.  (This option will be passed through from
+dpkg-buildpackage if specified on its command line.)  Note that the
+.B diff
+file will still be compressed with
+.B gzip
+and have a .gz extension.
+.TP
 .BR -sa , -sp , -su , -sk , -sA , -sP , -sU , -sK , -ss " with " -b
 If
 .BR -sk " or " -sp
diff --exclude=*~ -ru dpkg-1.4.1.16/scripts/dpkg-source.pl 
dpkg-bz2/scripts/dpkg-source.pl
--- dpkg-1.4.1.16/scripts/dpkg-source.plTue Sep 28 22:36:29 1999
+++ dpkg-bz2/scripts/dpkg-source.pl Tue Oct 19 21:09:54 1999
@@ -9,6 +9,7 @@
 my $fn;
 
 $sourcestyle = 'X';
+$bz2mode = 0;
 
 use POSIX;
 use POSIX qw (:errno_h :signal_h);
@@ -34,6 +35,7 @@
  -T read variables here, not debian/substvars
  -D=   override or add a .dsc field and value
  -U   remove a field
+ -bz2use bzip2 instead of gzip compression
  -sa auto select orig source (-sA is default)
  -sk use packed orig source (unpack & keep)
  -sp use packed orig source (unpack & remove)
@@ -77,6 +79,8 @@
 $varlistfile= $';
 } elsif (m/^-h$/) {
 &usageversion; exit(0);
+} elsif (m/^-bz2/) {
+$bz2mode = 1;
 } elsif (m/^--$/) {
 last;
 } else {
@@ -192,7 +196,11 @@
 #print STDERR ">$basedirname<\n";
 
 $origdir= "$dir.orig";
-$origtargz= "$basename.orig.tar.gz";
+if ($bz2mode) {
+$origtargz= "$basename.orig.tar.bz2";
+} else {
+$origtargz= "$basename.orig.tar.gz";
+}
 if (@ARGV) {
 $origarg= shift(@ARGV);
  

Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Alexander Koch]

Hi Anthony.

On Wed, 20 October 1999 11:07:47 +1000, Anthony Towns wrote:
> > Now, who of the ones that *can* change policy is going to do
> > anything on it? Please, can some of those give the many of
> > us an idea of what is the problem or (possibly) what I am
> > getting wrong?
> 
> (a) There's not much point changing policy when the code's not written.
> (b) IIRC the policy proposal *requires* .bz2 compression for all sources,
> rather than just allowing it, which isn't ideal.

The consensus was a different one, mind you. You would be
right here, if not that point (iirc!) was discussed.

Besides, this proposal turns out to be useful and Chris
wrote some code that hopefully makes it into dpkg soon,
if there are no objections from Wichert.

And I was thinking of the rather numerous (increasingly)
proposals that are waiting to be included and do not need
code. There is a general policy document update pending...

Alexander

-- 
"Video killed the radio star ... then the Spice Girls killed the rest."
-- Alan Braverman
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE

Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Anthony Towns]

On Wed, Oct 20, 1999 at 05:47:13AM +, Alexander Koch wrote:
> On Wed, 20 October 1999 11:07:47 +1000, Anthony Towns wrote:
> > > Now, who of the ones that *can* change policy is going to do
> > > anything on it? Please, can some of those give the many of
> > > us an idea of what is the problem or (possibly) what I am
> > > getting wrong?
> > (a) There's not much point changing policy when the code's not written.
> > (b) IIRC the policy proposal *requires* .bz2 compression for all sources,
> > rather than just allowing it, which isn't ideal.
> The consensus was a different one, mind you. You would be
> right here, if not that point (iirc!) was discussed.

The policy weekly summary includes ``I further propose that the use
of bzip2 be mandatory for newly uploaded source files''. This has been
both seconded and objected to (its Bug#39299). I wouldn't say any sort
of consensus has been reached personally. It needs to be rewritten and
put forward again. (The README.Debian proposal (Bug#42554) has similar
problems)

And for some reason I hadn't noticed Chris' code. How embarrasment.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpZ3Nj4DpL3H.pgp
Description: PGP signature

Re: bitmap and pixmap location

[Edward Betts]

Branden Robinson <[EMAIL PROTECTED]> wrote:
> > bitmaps: /usr/X11R6/include/bitmaps
>   This is wrong.
> 
> >  /usr/X11R6/include/X11/bitmaps
>   This is correct.
> 
> > pixmaps: /usr/X11R6/include/X11/pixmaps
>   This is correct.
> 
> >  /usr/share/pixmaps
>   This is wrong.
> 
> I think we should standardize around /usr/include/X11/{bitmap,pixmap}.

I thought that include was a place for storing C header files. Yes I have
looked at an xpm before, but even so, it is still an odd place to store them.


-- 
I consume, therefore I am

Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Chris Lawrence]

On Oct 20, Anthony Towns wrote:
> The policy weekly summary includes ``I further propose that the use
> of bzip2 be mandatory for newly uploaded source files''. This has been
> both seconded and objected to (its Bug#39299). I wouldn't say any sort
> of consensus has been reached personally. It needs to be rewritten and
> put forward again. (The README.Debian proposal (Bug#42554) has similar
> problems)

OK, so what needs to be done?  Can I (as the proposer) simply amend
the proposal, or do we need to close the existing proposal and start a
new one?

(I think we *do* have consensus on the "permit" part... but I could be
wrong.)

> And for some reason I hadn't noticed Chris' code. How embarrasment.

In fairness, I hadn't gotten off my butt and written it until last
night.  And it probably sucks (but it seems to work).


Chris
-- 
=
|Chris Lawrence |Get Debian GNU/Linux CDROMs|
|   <[EMAIL PROTECTED]>|   http://www.lordsutch.com/cds/   |
|   |   |
| Open Directory Editor |Are you tired of politics as usual?|
|   http://dmoz.org/| http://www.lp.org/|
=

Bug#47438: copyright statement needs updating?

[Julian Gilbey]

> On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
> > /usr/doc/debian-policy/policy.html/index.html:
> > 
> > Copyright (c)1996,1997,1998 Ian Jackson and Christian Schwarz.
> > 
> > Yet the manual has been modified by others since. Should the copyright
> > be updated?
> 
> Briefly: yes.

So what should it say?  Would an extra line:
Copyright (c)1998,1999 Debian Policy List Members
be appropriate?

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Re: bitmap and pixmap location

[Chris Waters]

Edward Betts <[EMAIL PROTECTED]> writes:
> Branden Robinson <[EMAIL PROTECTED]> wrote:

> > I think we should standardize around /usr/include/X11/{bitmap,pixmap}.

> I thought that include was a place for storing C header files. Yes I
> have looked at an xpm before, but even so, it is still an odd place
> to store them.

Yes, and with all due respect to our X maintainer, but X is allowed to
do things for historical reasons that the rest of us should avoid
doing at all costs.  Bitmaps and pixmaps are *not necessarily* X
related -- it's quite possible that other graphical systems will use
them, e.g. svgalib games or maybe something like berlin.  Thus,
/usr/include/X11 is very much the wrong place for pixmaps and bitmaps.

Also, do we really want to keep pixmaps and bitmaps separate from
other graphics formats?  I would prefer not -- that's much too
confusing.  But /usr/include/X11/jpeg *really* makes no sense! :-)

Quite honestly, I believe (and I think the FHS backs me up on this)
that the X11/X11R6 directories should be reserved for X11 itself, and
that if your package is not part of X11 directly, it shouldn't use,
e.g. /usr/X11R6/bin.  (Of course, you couldn't prove that I believe
this from my packages, but that's a separate issue.:-)

The FHS saith: "This hierarchy is reserved for the X Window System,
version 11 release 6, and related files."  Now, what exactly
constitutes a "related" file is not spelled out.  Perhaps the binaries
that use X11 *do* qualify.  But as I pointed out, pixmaps and bitmaps
are not *necessarily* X-related, and therefore, IMO, should most
definitely NOT be in /usr/include/X11 (aka some random link to
/usr/X11R6/include).

By my reading, the proper place for graphics files of whatever format
is, indeed, /usr/share.
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Re: Bug#47438: copyright statement needs updating?

[Chris Waters]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> So what should it say?  Would an extra line:
> Copyright (c)1998,1999 Debian Policy List Members
> be appropriate?

IANAL, but I believe that only a legally recognized entity (person,
organization, whatever) can assert copyright.

When Manoj asked me to assign copyright of my just-accepted proposal,
I responded, "sure, just tell me how."  I'm still waiting to hear. :-)

Note that the FSF, which has more experience (and better lawyers) than
most of us, requires formal transfer of copyright to all patches and
whatnot.  I'd *hope* that we wouldn't have to go that far, but I think
we're wading into murky waters here.  (Murky is a cousin of mine.:-)

Perhaps we could a) arrange for the policy copyright to be transferred
to SPI, and (or) b) state in the proposal-policy that making a formal
proposal implies assignment of copyright.  I dunno if it would hold up
in court, but with luck, it'll never come to that.
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Bug#47438: copyright statement needs updating?

[Joost Kooij]

Hi,

On Wed, 20 Oct 1999, Julian Gilbey wrote:

> > On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
> > > /usr/doc/debian-policy/policy.html/index.html:
> > > 
> > > Copyright (c)1996,1997,1998 Ian Jackson and Christian Schwarz.
> > > 
> > > Yet the manual has been modified by others since. Should the copyright
> > > be updated?
> > 
> > Briefly: yes.
> 
> So what should it say?  Would an extra line:
> Copyright (c)1998,1999 Debian Policy List Members
> be appropriate?

That looks very nice at first glance.  On second thought, I wonder if
"Debian Policy List Members" is an entity that you can legally assign a
copyright to.  Will the copyright be enforcable?  Does it still make any
sense to have such a copyright notice if not?

Perhaps you should consult debian-legal and maybe debian-policy too.

Cheers,


Joost

Re: Bug#47438: copyright statement needs updating?

[Daniel Quinlan]

Julian Gilbey <[EMAIL PROTECTED]> writes:

>> So what should it say?  Would an extra line: Copyright (c)1998,1999
>> Debian Policy List Members be appropriate?

Chris Waters <[EMAIL PROTECTED]> writes:

> IANAL, but I believe that only a legally recognized entity (person,
> organization, whatever) can assert copyright.

I think you're right about needing a legally recognized entity.  I would
suggest assigning the copyright to SPI using an assignment similar to
the FSF one:

  http://egcs.cygnus.com/fsf-forms/assignment-instructions.html

It really only needs to be signed by people who have made major
contributions.  I wouldn't worry about small patches and minor changes.

Dan