Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Goswin von Brederlow 
Andreas Metzler  writes:

> In gmane.linux.debian.devel.general Joey Hess  wrote:
>> Steve McIntyre wrote:
>>> There are uses I've heard about, including (apparently quite common)
>>> using CDs and DVDs to seed a mirror on a Windows server.
>
>> If I had to chose between that working, and not needing to worry about
>> filename lengths, I'd choose the latter.
>
>>> >Is it possible to provide Joliet filenames for only a subset of files?
>
>>> It is, yes. But not something I'd like to do if we can avoid it.
>
>> One approach then would be to omit joliet filenames for the few long
>> packages. This would not even impact your use case above much, since
>> any mirror seeded from files from CDs needs a further sync step.
>
> Hello,
> An alternative approach would be to use a different *filename* while
> keeping the package name unchanged (This could be done on both mirrors
> and CD.) Iirc apt/dpkg have absolutely no problem with "foo.deb"
> containing version 1:3.2.1-11+squeeze2 of the 
> openoffice.org-report-builder-bin i386 package. I do not know about
> dak, though.
>
> cu andreas

Doesn't work for sources as the dsc files are signed and therefore
unalterable. Unless you want to teach dpkg about the renaming rules too.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y63xxbl1.fsf@frosties.localnet

Re: Debian 6.0.1 ia64 DVD release looks strange

2011-03-30 Thread Steve McIntyre 
On Wed, Mar 23, 2011 at 12:00:53AM +1100, Andrew McGlashan wrote:
>Hi Steve,
>
>Steve McIntyre wrote:
>>Apologies, you've just found a bug in the CD/DVD creation run from
>>last weekend. I'm working on it now, expect a new release (6.0.1a)
>>shortly.
>
>How about an announcement for this when it is fixed and also one for
>the "small CDs" that were effected by an [same|different?] issue.
>
>Anybody whom downloaded 6.0.1 netinst and business card versions
>(perhaps others), need to download 6.0.1a as per this page:
>
>http://cdimage.debian.org/debian-cd/6.0.1/

There's an announcement at

  http://www.debian.org/News/2011/20110329a

It's based on my analysis of the problems we've found. I'll forward it
separately too.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330103658.gc7...@einval.com

FWD: Fixed ISO images for Debian 6.0.1 released

2011-03-30 Thread Steve McIntyre 
[ Reply-To: set to debian-cd in case people want to ask for more
  information... ]

As promised, here's an update about the 6.0.1 CD builds.


The Debian Projecthttp://www.debian.org/
Fixed ISO images for Debian 6.0.1 released  pr...@debian.org
March 29th, 2011   http://www.debian.org/News/2011/20110329a


Fixed ISO images for Debian 6.0.1 released

Post-release testing showed up a variety of bugs in the images produced
for the 6.0.1 update release [1]:

 1. Wrong installer code used for the "small" CDs

The script used to build the netinst and businesscard CDs was
misconfigured, and was using the testing (Wheezy) version of
Debian Installer instead of the correct Squeeze version.

 2. Incorrectly sized DVD images for some architectures

During the original 6.0.0 Squeeze release, we encountered problems
in making some of the CD images fit; once the Squeeze release notes
were added, the alternate KDE installation CD for several of the
architectures grew too large. A number of last-minute tweaks were
made on that release day to try to fix this, and the problem was
mitigated. Unfortunately, (as is often the case with quick hacks in
these situations) these tweaks did not work well in the next
release and caused unforeseen problems. Various of the 6.0.1 images
that should have been sized to fill a DVD were instead limited to
approximately 700 MiB.

 3. Update CDs and DVDs missing Packages and Sources files

In between the Lenny and Squeeze releases, a fair amount of the
code in the debian-cd package was refactored for clarity and to
aid in maintenance.  This also included deleting some older helper
scripts that seemed to be redundant. Unfortunately, that conclusion
was incorrect; two scripts were removed that were necessary for the
correct operation of the "update-cd" script that generates the
update CD and DVD images. Due to this oversight, on the day of the
point release those images were created wrongly. They contained
package and source data, but the meta data files Packages.gz and
Sources.gz were missing.


In each of the cases listed above, the failure case has been analysed
and is understood. Fixes for all of the problems have been developed,
and replacement images have been produced and tested. Following our
normal naming scheme, the new images are versioned 6.0.1a to denote the
bugfix rebuild.

There is no need to download these new images for user who have already
downloaded previous images versioned as 6.0.1, if they are not affected
by one of the bugs listed above.  The easiest way to create fixed
images for users who are affected by these bugs, is to use jigdo and
scan the previous images for already downloaded files.

We offer apologies for any inconvenience caused by these errors. The
very next task for the Debian CD team will be to integrate more
extensive automated QA for our CD images, in the hope that we will
significantly reduce the likelihood of bugs like these in the future.

  1: http://www.debian.org/News/2011/20110319
  2: http://www.debian.org/CD/jigdo-cd/#how


About Debian


The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential open source projects.  Over three thousand
volunteers from all over the world work together to create and maintain
Debian software. Translated into over 70 languages, and supporting a
huge range of computer types, Debian calls itself the "universal
operating system".


Contact Information
---

For further information, please visit the Debian web pages at 
http://www.debian.org/ or send mail to .

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330104104.gd7...@einval.com

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Steve McIntyre 
On Sat, Mar 26, 2011 at 08:56:14AM +0100, Raphael Hertzog wrote:
>On Fri, 25 Mar 2011, Steve McIntyre wrote:
>> On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
>> >Steve McIntyre wrote:
>> >> There are uses I've heard about, including (apparently quite common)
>> >> using CDs and DVDs to seed a mirror on a Windows server.
>> >
>> >If I had to chose between that working, and not needing to worry about
>> >filename lengths, I'd choose the latter.
>> 
>> We already have arbitrary limits on filename length (~200 bytes or so
>> on RockRidge), even before this. I'm just proposing to lower them for
>> a common use case. Do we really care about supporting *very* long
>> names here?
>
>I think so. The package with long names tend to follow a naming policy
>that sort of imposes the long name... so if we put a too-short limit
>then we're asking them to make an exception in the naming policy.

So what's a reasonable name length limit then? 80? 150? 2000?

>> >One approach then would be to omit joliet filenames for the few long
>> >packages. This would not even impact your use case above much, since
>> >any mirror seeded from files from CDs needs a further sync step.
>> 
>> I'd be much happier to not have to special case yet another thing in
>> the CD scripts. That way potentially leads to unforeseen bugs in the
>> future, for very little gain.
>
>What happens if you try to put too-long filenames on the CD with Joliet
>enabled?
>
>Does it fail to build? Are there options to rename the files
>automatically?

It will fail to build. I don't want to rename the files, I'd like to
get some agreement on how to fix the problem properly.

>If it means we have some unexpected filenames for long filenames on
>Windows, it's not a big deal IMO. 

For people who may want to verify the files on their CDs it might be.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330105139.gg7...@einval.com

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Steve McIntyre 
On Sat, Mar 26, 2011 at 03:18:12PM +0100, gregor herrmann wrote:
>On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote:
>
>> > We already have arbitrary limits on filename length (~200 bytes or so
>> > on RockRidge), even before this. I'm just proposing to lower them for
>> > a common use case. Do we really care about supporting *very* long
>> > names here?
>> I think so. The package with long names tend to follow a naming policy
>> that sort of imposes the long name... so if we put a too-short limit
>> then we're asking them to make an exception in the naming policy.
>
>Right, that's certainly true for the lib.*-perl packages, and I
>wouldn't know how we should rename them in a sane way.

In the worst case that I'm looking at, I'm a little surprised by the
names here on two fronts:

libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz

1. Why the "bundle" ?

2. Why such a silly long name? What will happen if somebody comes
   along with another perl module to add to this bundle, but with a
   name twice as long? Does the source name for this tarball have to
   contain the whole of the bundle name?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330105622.gh7...@einval.com

Bug#619211: debian-cd: Add hurd-i386 support

2011-03-30 Thread Steve McIntyre 
tags 619211 +pending
thanks

On Mon, Mar 28, 2011 at 11:45:02PM +0200, Samuel Thibault wrote:
>Samuel Thibault, le Tue 22 Mar 2011 02:08:09 +0100, a écrit :
>> The attached patch adds hurd-i386 support to debian-cd, could you please
>> apply it?
>
>and please don't forget to
>
>chmod +x tools/boot/sid/boot-hurd-i386

Checked in and ready to use on pettersson. I assume you'd like me to
plumb into the normal daily/weekly build infrastructure too? :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/




-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330103043.gb7...@einval.com

Processed: Re: Bug#619211: debian-cd: Add hurd-i386 support

2011-03-30 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tags 619211 +pending
Bug #619211 [debian-cd] debian-cd: Add hurd-i386 support
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
619211: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619211
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130148320910527.transcr...@bugs.debian.org

Bug#619211: debian-cd: Add hurd-i386 support

2011-03-30 Thread Steve McIntyre 
On Wed, Mar 30, 2011 at 01:21:40PM +0200, Samuel Thibault wrote:
>Steve McIntyre, le Wed 30 Mar 2011 11:30:43 +0100, a écrit :
>> On Mon, Mar 28, 2011 at 11:45:02PM +0200, Samuel Thibault wrote:
>> >Samuel Thibault, le Tue 22 Mar 2011 02:08:09 +0100, a écrit :
>> >> The attached patch adds hurd-i386 support to debian-cd, could you please
>> >> apply it?
>> >
>> >and please don't forget to
>> >
>> >chmod +x tools/boot/sid/boot-hurd-i386
>> 
>> Checked in and ready to use on pettersson.
>
>Thanks.
>
>> I assume you'd like me to plumb into the normal daily/weekly build
>> infrastructure too? :-)
>
>Well, it won't be useful yet, because I still have to fix a bug with
>cdrom unmount/remount on hurd-i386, and the debian-installer package
>can't be built without a testing distribution.

OK. Just let me know.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds




-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330112919.gj7...@einval.com

Bug#619211: debian-cd: Add hurd-i386 support

2011-03-30 Thread Samuel Thibault 
Steve McIntyre, le Wed 30 Mar 2011 11:30:43 +0100, a écrit :
> On Mon, Mar 28, 2011 at 11:45:02PM +0200, Samuel Thibault wrote:
> >Samuel Thibault, le Tue 22 Mar 2011 02:08:09 +0100, a écrit :
> >> The attached patch adds hurd-i386 support to debian-cd, could you please
> >> apply it?
> >
> >and please don't forget to
> >
> >chmod +x tools/boot/sid/boot-hurd-i386
> 
> Checked in and ready to use on pettersson.

Thanks.

> I assume you'd like me to plumb into the normal daily/weekly build
> infrastructure too? :-)

Well, it won't be useful yet, because I still have to fix a bug with
cdrom unmount/remount on hurd-i386, and the debian-installer package
can't be built without a testing distribution.

Samuel



-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330112140.gn5...@const.bordeaux.inria.fr

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Henrique de Moraes Holschuh 
On Wed, 30 Mar 2011, Steve McIntyre wrote:
> >I think so. The package with long names tend to follow a naming policy
> >that sort of imposes the long name... so if we put a too-short limit
> >then we're asking them to make an exception in the naming policy.
> 
> So what's a reasonable name length limit then? 80? 150? 2000?

Do you want it to actually work worth a damn (i.e. not croak on ext2-4, xfs
and btrfs at the very least)?

Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...).

We really need to curb the long name insanity in the head.  And might as
well do it in a way that does not hinder our hability to get data where it
is needed, i.e. keep it under 100 chars.

There really is no excuse for such long deb names.  If a naming convention
"requires" it, fix the buggy naming convention.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330125449.ga28...@khazad-dum.debian.net

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread gregor herrmann 
On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote:

> >Right, that's certainly true for the lib.*-perl packages, and I
> >wouldn't know how we should rename them in a sane way.
> In the worst case that I'm looking at, I'm a little surprised by the
> names here on two fronts:
> libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz
> 1. Why the "bundle" ?

Because the ftp-masters don't (or at least didn't) want small
packages in the archive.
From the packaging point of view we'd split them up immediately if
that was ok for them. Cf. #606411.
 
> 2. Why such a silly long name? What will happen if somebody comes
>along with another perl module to add to this bundle, but with a
>name twice as long? Does the source name for this tarball have to
>contain the whole of the bundle name?

As far as I understand source format v3 with multiple upstream
tarballs, the first part (up to .orig) can't be changed as it needs
to be the same as for the "main" package. [0] The second part (the
component) name is free-form, and as I said earlier, here's a bit of
room for us to shorten it (in this case e.g. from
CGI-Application-Plugin-ValidateRM-2-3 to ValidateRM).


Cheers,
gregor

[0] Although in this case the package name itself is made up and
could be shortend from libcgi-application-basic-plugin-bundle-perl to
something like libcgi-application-plugins-perl.

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: David Bowie: Tvc 15


signature.asc
Description: Digital signature

Splitting large game data packages?

2011-03-30 Thread Simon McVittie 
Hi,
I've been considering splitting up openarena-data (currently 314MB source,
345MB binary) into multiple source packages. openarena would still have to
depend on all of them (you need the complete set for network compatibility),
but they'd be easier to fit on CDs, and I wouldn't have to upload so much data
for each version. Does that sound good to the ftpmasters?

I propose to split it up like this:

 81M openarena-data-0.8.5 (pak0 + mp-pak0 + pak6-patch085)
 or if preferred it could be split further:
 44M -data-0.8.1 (pak0 + mp-pak0)
 37M -data-0.8.5 (pak6-patch085)

 67M openarena-data (pak1-maps + pak5-TA + pak6-misc)
 or if preferred it could be split further:
 39M -maps (pak1-maps)
 28M -data (pak5-TA + pak6-misc)

101M openarena-players (pak2-players + pak2-players-mature)
 or if preferred it could be split further:
 74M -players
 27M -players-mature

 95M openarena-textures (pak4-textures)

and in future,

???M openarena-data-0.8.6 etc. (extra files for future versions)

Relationships:
openarena Depends: x | openarena-data (<< first split version) for each x
openarena-server also Depends: x | openarena-data (<< ...) for each x
x Replaces: openarena-data (<< first split version) for each x
openarena-data Breaks: openarena (<< version depending on split packages)



Background on why it's split like that:

The binary package consists of large PK3 (i.e. zip) files, currently looking
like this:

  /usr/share/games/openarena/baseoa:
  total 335M
  *38M pak0.pk3  74M pak2-players.pk325M pak6-misc.pk3
   39M pak1-maps.pk3 95M pak4-textures.pk3  *37M pak6-patch085.pk3
   27M pak2-players-mature.pk3  2.9M pak5-TA.pk3

  /usr/share/games/openarena/missionpack:
  total 5.8M
 *5.8M mp-pak0.pk3

The files marked * are not the same as distributed by upstream (bytecode
produced by a non-Free compiler has been removed and replaced with stub files
which cause equivalent native code to be loaded), so they're most likely to
need uploads.

Due to the way Quake III-based games achieve network compatibility, all files
except pak6-patch085.pk3 were present with the same contents in OpenArena
0.8.1, and Openarena 0.8.6 is likely to consist of a pak7-patch086.pk3 (or
something) which is appended to the search order while leaving the other
pk3 files identical. Yes, this means openarena/0.8.6 would have a Depends on
openarena-data-0.8.1, openarena-data-0.8.5 *and* openarena-data-0.8.6; that's
how the Quake III engine works.

S


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110330175854.ga24...@reptile.pseudorandom.co.uk

Bug#619691: Provide lists of CD etc. contents

2011-03-30 Thread Steve McIntyre 
On Sat, Mar 26, 2011 at 04:19:12AM +, Ben Hutchings wrote:
>Package: cdimage.debian.org
>Severity: wishlist
>
>Richard Atterer no longer maintains Jigdo or the search engine for
>files on Debian CDs.  Please provide content lists in some form that
>can be linked from  (now
>deleted; all links were dead) and 
>(see #619680).

Hmmm. This has been discussed ages ago, but I guess nobody has had the
time or the inclination to get things working. To be honest, I'm not
convinced that Richard's old scripts to look through jigdo files is
the best approach. We've been generating gzipped list files to go with
all the ISO images for quite a while now, and simply using those would
probably be better I think. I'm looking into it now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...




-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330183916.gb13...@einval.com