The deadline for proposing GSOC projects is close!

[Ana Guerrero]

Hi!

Next Monday, the submission of student proposals opens for this year's GSOC.
>From Debian we are expecting to have something like 10 students
working, so we are still missing proposals. Most of students
are reviewing this weekend the different websites of the participating
organizations to decide where to apply, so if you are planning to propose
and mentor a project, the sooner you do it, the higher chances to get
a motivated student!

The student application deadline is 8th April, do not expect good
students proposals if you suggest your project after the 4-5th April.

It is not clear for prospective mentors what projects are suitable and what
are they supposed to do. I hope the following ideas will help:

* What kind of project is a suitable one for GSoC?

A project that:
- should be done for the student in 12 weeks with help/support from a mentor
- produces *code*
- gets the student started to contribute into some area of Debian
- does not focus on improving or introducing specific upstream software in 
Debian but instead improve core aspects of Debian 
- will allow the student learn. Repetitive and/or boring tasks are not OK. 
(For example, it would not be OK a project "clean spam from lists")

'Package foo' projects will only be considered if they can make significant 
contribution to common Debian packaging frameworks and tools. And only when 
they are expected to take the 12 weeks of the GSoC.
   
The difficulty of the project is very hard to measure because what is hard 
for some students is easy for others, and vice versa.

You can take look at the list of projects from the last 2 years at
http://wiki.debian.org/SummerOfCode2009#SelectedProjects
http://wiki.debian.org/SummerOfCode2010#SelectedProjects


* What mentors are expected to do?

- Get the student introduced into Debian.
- Interact with the student 3-4 times per week, via email and IM/IRC.
- Follow the progress of the student weekly and remind the student to
write an email (or blog) about their progress every 2 weeks. 
- Answer the Mid-term and final evaluations questionnaires.


Ana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326004051.ga31...@pryan.ekaia.org

Re: ddebs

[Emilio Pozuelo Monfort]

On 25/03/11 23:13, Philipp Kern wrote:
> Are there dependencies from the -ddeb to the binary?  Because you'd want to
> update/upgrade your ddeb when you update the library, otherwise it becomes
> useless.  I imagine there can't be given that the binaries of our source
> package might not be co-installable.

This is handled by

# If the ddeb appears in the control file, we let the
# packager override our defaults there.
my $arch=package_arch($package);
my $srcpackage=sourcepackage();

my $depends="";
foreach my $pkg (getpackages("same")) {
if ($pkg ne $package) {
addsubstvar($package,"ddeb:Conflicts","$pkg","<< 
\${binary:Version}");
addsubstvar($package,"ddeb:Conflicts","$pkg",">> 
\${binary:Version}");
$depends="$depends | $pkg (= \${binary:Version})";
}
}
$depends=~s/^ \| //;
addsubstvar($package,"ddeb:Depends","$depends","");

> Is there a rationale why this was done differently from Ubuntu?

There probably was, though I don't remember it. You can search in the
debian-devel archives on July and August 2009.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8d26d3.6080...@debian.org

Re: ddebs

[Philipp Kern]

On 2011-03-25, Emilio Pozuelo Monfort  wrote:
> On 25/03/11 22:24, Torsten Werner wrote:
>> On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort
>>  wrote:
>>> http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb
>> Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on
>> that schema or is there another way to find the name of a deb package
>> from its ddeb package? Rationale: whenever a ddeb gets uploaded we
>> need to check if there is already a matching deb in the archive (or at
>> least in the same upload). If not we will reject the upload.
> The way I did it was one .ddeb per source package, not per binary. So it is
> $src-ddeb. You can reject them if they are not for $src package (or if $src
> package doesn't exist in the archive).

Are there dependencies from the -ddeb to the binary?  Because you'd want to
update/upgrade your ddeb when you update the library, otherwise it becomes
useless.  I imagine there can't be given that the binaries of our source
package might not be co-installable.

Is there a rationale why this was done differently from Ubuntu?

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnioq8dg.2ji.tr...@kelgar.0x539.de

Re: ddebs

[Emilio Pozuelo Monfort]

On 25/03/11 22:24, Torsten Werner wrote:
> On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort
>  wrote:
>> http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb
> 
> Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on
> that schema or is there another way to find the name of a deb package
> from its ddeb package? Rationale: whenever a ddeb gets uploaded we
> need to check if there is already a matching deb in the archive (or at
> least in the same upload). If not we will reject the upload.

The way I did it was one .ddeb per source package, not per binary. So it is
$src-ddeb. You can reject them if they are not for $src package (or if $src
package doesn't exist in the archive).

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8d1a9f.5030...@debian.org

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

[Steve McIntyre]

John H. Robinson, IV wrote:
>Olaf van der Spek wrote:
>> On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre  wrote:
>> >>Why's that? Isn't UDF widely supported?
>> >
>> > Implementations often widely differ in their limitations - see the
>> > Wikipedia page for more details. The suggested way to make a safe UDF
>> > DVD is often along the lines of "use the ISO9660 bridge format". :-(
>> 
>> That's not our problem, is it?
>
>It is, if we are trying to be as compatible as possible.

Absolutely, yes.

>What about keeping the first cd/dvd/bd as compatible as possible, and
>not worrying about the subsequent ones? As mentioned, and mirror seeding
>would have to be synced anyway.

Ewww, special casing...!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1q3f7p-0008oe...@jack.mossbank.org.uk

Re: ddebs

[Torsten Werner]

On Fri, Mar 25, 2011 at 10:54 PM, Emilio Pozuelo Monfort
 wrote:
> http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb

Thanks. The name of the ddeb for gzip is gzip-ddeb. Can we rely on
that schema or is there another way to find the name of a deb package
from its ddeb package? Rationale: whenever a ddeb gets uploaded we
need to check if there is already a matching deb in the archive (or at
least in the same upload). If not we will reject the upload.

Torsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTimoQQoD6M5qT8CFU908fJF4st=rtpygmcznk...@mail.gmail.com

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

[Steve McIntyre]

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?

>> >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.

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.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra


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

Re: ddebs

[Emilio Pozuelo Monfort]

On 25/03/11 21:46, Torsten Werner wrote:
> Thanks for the explaination.
> 
> On Fri, Mar 25, 2011 at 10:38 PM, Emilio Pozuelo Monfort
>  wrote:
>> Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2).
> 
> May I download a pre-built debhelper from somewhere?

http://people.debian.org/~pochu/debhelper_8.1.2+nmu1_all.deb

And you'll also need

http://people.debian.org/~pochu/ptools/ptools_0.1-1_amd64.deb

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8d0ef9.7090...@debian.org

Re: ddebs

[Torsten Werner]

Thanks for the explaination.

On Fri, Mar 25, 2011 at 10:38 PM, Emilio Pozuelo Monfort
 wrote:
> Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2).

May I download a pre-built debhelper from somewhere?

Thanks,
Torsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikc_stw4rkp6etvqqomzyh-o+6phf8z1j6ax...@mail.gmail.com

Re: ddebs

[Emilio Pozuelo Monfort]

On 25/03/11 18:22, Torsten Werner wrote:
> are there any example packages that build ddebs? That we can use for
> testing dak?

It should happen automatically if you patch debhelper (and CDBS to automatically
get .ddebs out of CDBS-using packages) with my patches. I have just refreshed my
debhelper patch so it applies cleanly again, and I've tested it.

What you need:

ptools (for build-id support, should be easy to remove that part from my patch,
see the pbuildid call in dh_strip). I've put it in [1].

Apply the attached patch to debhelper (applies cleanly on debhelper 8.1.2).

Install the resulting debhelper and build any package that
- produces at least one arch:any package
- doesn't have a -dbg package

E.g. I've tested it with gzip. Just dpkg-buildpackage it with the new debhelper
installed and you'll get:

[...]
dpkg-deb: building package `gzip-ddeb' in `../gzip-ddeb_1.3.12-9_amd64.ddeb'.

$ dpkg --contents gzip-ddeb_1.3.12-9_amd64.ddeb
drwxr-xr-x root/root 0 2011-03-25 21:21 ./
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/doc/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/share/doc/gzip-ddeb/
-rw-r--r-- root/root 24028 2007-04-13 22:41
./usr/share/doc/gzip-ddeb/changelog.gz
-rw-r--r-- root/root  1101 2011-03-25 20:54 
./usr/share/doc/gzip-ddeb/copyright
-rw-r--r-- root/root  6637 2011-03-25 20:54
./usr/share/doc/gzip-ddeb/changelog.Debian.gz
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/.build-id/
drwxr-xr-x root/root 0 2011-03-25 21:21 ./usr/lib/debug/.build-id/93/
-rw-r--r-- root/root151197 2011-03-25 21:21
./usr/lib/debug/.build-id/93/6c3dda20627d866fd42cb8a7b05247d7707367.debug

FWIW, build-id and .ddebs don't need to be done at the same time. The only
problem with build-id is that we could get file conflicts if two packages have
*exactly* the same ELF binary. May happen if you build two flavours of the same
package and one binary isn't affected by the different build flags / options. We
could solve this by making dpkg not complain if this happens, ref-counting the
files so it doesn't remove it until all the packages that shipped that file are
removed. Note that this is hypothetical, and if it happened, it would be the
exception.

Also see http://wiki.debian.org/AutomaticDebugPackages

Let me know if you any questions.

Cheers,
Emilio

[1] http://people.debian.org/~pochu/ptools/ptools_0.1-1.dsc
diff -Nru debhelper-8.1.2/debian/changelog debhelper-8.1.2+nmu1/debian/changelog
--- debhelper-8.1.2/debian/changelog2011-02-14 18:22:19.0 +
+++ debhelper-8.1.2+nmu1/debian/changelog   2011-03-25 20:52:21.0 
+
@@ -1,3 +1,10 @@
+debhelper (8.1.2+nmu1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Add ddebs support.
+
+ -- Emilio Pozuelo Monfort   Fri, 25 Mar 2011 20:52:10 +
+
 debhelper (8.1.2) unstable; urgency=low
 
   * Fix logging at end of an override target that never actually runs
diff -Nru debhelper-8.1.2/debian/control debhelper-8.1.2+nmu1/debian/control
--- debhelper-8.1.2/debian/control  2011-02-10 23:51:37.0 +
+++ debhelper-8.1.2+nmu1/debian/control 2011-03-25 20:50:47.0 +
@@ -10,7 +10,7 @@
 
 Package: debhelper
 Architecture: all
-Depends: ${perl:Depends}, ${misc:Depends}, perl-base (>= 5.10), file (>= 
3.23), dpkg-dev (>= 1.14.19), html2text, binutils, po-debconf, man-db (>= 
2.5.1-1)
+Depends: ${perl:Depends}, ${misc:Depends}, perl-base (>= 5.10), file (>= 
3.23), dpkg-dev (>= 1.14.19), html2text, binutils, po-debconf, man-db (>= 
2.5.1-1), ptools
 Suggests: dh-make
 Conflicts: dpkg-cross (<< 1.18), python-support (<< 0.5.3), python-central (<< 
0.5.6)
 Description: helper programs for debian/rules
diff -Nru debhelper-8.1.2/Debian/Debhelper/Dh_Lib.pm 
debhelper-8.1.2+nmu1/Debian/Debhelper/Dh_Lib.pm
--- debhelper-8.1.2/Debian/Debhelper/Dh_Lib.pm  2011-02-10 23:53:58.0 
+
+++ debhelper-8.1.2+nmu1/Debian/Debhelper/Dh_Lib.pm 2011-03-25 
20:50:12.0 +
@@ -18,7 +18,8 @@
&inhibit_log &load_log &write_log &commit_override_log
&dpkg_architecture_value &sourcepackage
&is_make_jobserver_unavailable &clean_jobserver_makeflags
-   &cross_command);
+   &cross_command &is_ddeb &ddeb_filename &ddeb_in_control
+   &ddeb_is_empty &ddebpackage);
 
 my $max_compat=8;
 
@@ -749,6 +750,9 @@
my $package="";
my $arch="";
my $package_type;
+   my $has_arch_dep=0;
+   my $has_ddeb_pkg=0;
+   my $has_dbg_pkg=0;
my @list=();
my %seen;
open (CONTROL, 'debian/control') ||
@@ -756,6 +760,12 @@
while () {
chomp;
s/\s+$//;
+   if (/^Maintainer:\s

Krajowe PRZESYLKI KURIERSKIE

[AM Logistic]

Witamy serdecznie,
 
Jesteśmy firmą zajmującą się pośrednictwem usług kurierskich w Polsce.
Szanując Państwa prywatność i zarazem przestrzegając obowiązujących przepisów 
(Ustawa z dnia 18 lipca 2002 roku o świadczeniu usług drogą elektroniczną - Dz. 
U Nr 144, poz.1204) zwracamy się z prośbą o wyrażenie zgody na przysłanie 
Państwu informacji handlowej o świadczonych przez naszą firmę usługach.
 
Wyrażenie zgody następuje przez kliknięcie słowa TAK. 
Tak, jestem zainteresowany (a) ofertą.
 
 
Jeżeli nie są Państwo zainteresowani  uzyskaniem informacji handlowej 
dotyczącej usług świadczonych przez naszą firmę, serdecznie przepraszamy.
  
Z wyrazami szacunku
Dział Handlowy
AM Logistic Wolniewicz i S-ka S.J.
Ludwika Rydygiera 8/24
01-793 Warszawa
 
Telefony stacjonarne:
(22) 663 01 32, (22) 663 01 37
(22) 663 01 41, (22) 663 01 46
Telefony komórkowe:
724 222 211, 667 222 211
 

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

[Rene Engelhard]

Hi,

On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote:
> On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote:
> > Hi,
> > 
> > On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
> > > The longest is:
> > > 
> > > libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb
> > > 
> > > at 71.
> > 
> > Good, then any bug against openoffice.org is not needed, as that obviously
> > will be + wontfix wheezy-ignore, because it simply can't be fixed as we need
> > the transitional packages :)
> 
> It still can have a version number much shorter than 1.0.3+LibO3.3.1-1.

And there's no package out of openoffice.org which has that style of version.

And no, it cannot have a shorter version in libreoffice (e.g. you simply can't 
remov
the +LibO3.3.1-1 unless you get problems in versioning as the version before 
the +
doesn't necessarily change between releases)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325205931.gd...@rene-engelhard.de

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

[Adam Borowski]

On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote:
> Hi,
> 
> On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
> > The longest is:
> > 
> > libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb
> > 
> > at 71.
> 
> Good, then any bug against openoffice.org is not needed, as that obviously
> will be + wontfix wheezy-ignore, because it simply can't be fixed as we need
> the transitional packages :)

It still can have a version number much shorter than 1.0.3+LibO3.3.1-1.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325204815.ga32...@angband.pl

ddebs (was: Upcoming FTPMaster meeting)

[Torsten Werner]

Hi Josselin,

Am -10.01.-28163 20:59, schrieb Josselin Mouette:
> Would it be possible to add support for ddebs?

are there any example packages that build ddebs? That we can use for
testing dak?

Cheers,
Torsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8cdd7d.1000...@debian.org

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

[John H. Robinson, IV]

Olaf van der Spek wrote:
> On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre  wrote:
> >>Why's that? Isn't UDF widely supported?
> >
> > Implementations often widely differ in their limitations - see the
> > Wikipedia page for more details. The suggested way to make a safe UDF
> > DVD is often along the lines of "use the ISO9660 bridge format". :-(
> 
> That's not our problem, is it?

It is, if we are trying to be as compatible as possible.

What about keeping the first cd/dvd/bd as compatible as possible, and
not worrying about the subsequent ones? As mentioned, and mirror seeding
would have to be synced anyway.

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325165515.ga30...@a.mx.sbih.org

Re: Bug#619396: ITP: geant321 -- Particle detector description and simulation tool

[Kevin B. McCarty]

Hi,

(sorry to break the thread, I'm not subscribed to debian-devel)

Original CERNLIB maintainer here, the debian/copyright files for the
original CERNLIB packages (for now, still available in oldstable) may
be useful to answer some of Mika's and others' questions regarding
licensing issues.

http://packages.debian.org/changelogs/pool/main/c/cernlib/cernlib_2006.dfsg.2-13.2/cernlib.copyright
http://packages.debian.org/changelogs/pool/main/p/paw/paw_2.14.04.dfsg.2-6/paw.copyright
http://packages.debian.org/changelogs/pool/main/g/geant321/geant321_3.21.14.dfsg-8/geant321.copyright
http://packages.debian.org/changelogs/pool/main/m/mclibs/mclibs_2006.dfsg.2-5/montecarlo-base.copyright

best regards,

-- 
Kevin B. McCarty 
WWW: http://www.starplot.org/
GPG: public key ID 4F83C751


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim0xkd+swglu0lyfjlyhxkjy70pvfhqudq2u...@mail.gmail.com

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

[Philipp Kern]

On 2011-03-25, Joey Hess  wrote:
>> >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.

And on that Windows you get your own share of fun on an OS that's
case-insensitive, I guess.

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniopi0n.1j7.tr...@kelgar.0x539.de

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

[Olaf van der Spek]

On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre  wrote:
>>Why's that? Isn't UDF widely supported?
>
> Implementations often widely differ in their limitations - see the
> Wikipedia page for more details. The suggested way to make a safe UDF
> DVD is often along the lines of "use the ISO9660 bridge format". :-(

That's not our problem, is it?

-- 
Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=vxP9uJ8PdnuMQ3HKK=R5d05S+RD-jcfcNO5=q...@mail.gmail.com

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

[Steve McIntyre]

On Fri, Mar 25, 2011 at 05:13:03PM +0100, Olaf van der Spek wrote:
>On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre  wrote:
>>>64 is quite low. Is there no way to use longer filenames that still
>>>works on all required platforms?
>>
>> To do that, we'll have to switch to a different filesystem. That's a
>> possibility (maybe UDF), but there's probably even more of a chance of
>> compatibility problems then.
>
>Why's that? Isn't UDF widely supported?

Implementations often widely differ in their limitations - see the
Wikipedia page for more details. The suggested way to make a safe UDF
DVD is often along the lines of "use the ISO9660 bridge format". :-(

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


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

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

[Joey Hess]

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.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Steve McIntyre]

On Fri, Mar 25, 2011 at 04:48:12PM +0100, Olaf van der Spek wrote:
>On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre  wrote:
>> users. The problem is that Joliet has a limit for filename length (64
>> characters), and technically we're already past that length. From
>> genisoimage.1:
>
>64 is quite low. Is there no way to use longer filenames that still
>works on all required platforms?

To do that, we'll have to switch to a different filesystem. That's a
possibility (maybe UDF), but there's probably even more of a chance of
compatibility problems then.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back


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

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

[Steve McIntyre]

On Fri, Mar 25, 2011 at 11:52:35AM -0400, Joey Hess wrote:
>Steve McIntyre wrote:
>> I've noticed a problem recently in the archive when building CDs,
>> aggravated to a certain extent by the newer source formats. Some of
>> the filenames in the archive are getting *very* long, and this is
>> causing issues. As a matter of course, we build CDs with RockRidge and
>> Joliet support so that we have long filenames for Linux and Windows
>> users.
>
>What is the use case for accessing long filenames from the CD in
>Windows? The files needed by win32-loader need to be 
>accessible, and documentation too, but it should not matter if
>deb files cannot be looked up from within Windows.

There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.

>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.

-- 
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325160115.gb23...@einval.com

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

[Olaf van der Spek]

On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre  wrote:
>>64 is quite low. Is there no way to use longer filenames that still
>>works on all required platforms?
>
> To do that, we'll have to switch to a different filesystem. That's a
> possibility (maybe UDF), but there's probably even more of a chance of
> compatibility problems then.

Why's that? Isn't UDF widely supported?


-- 
Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikog-er7p3d2azypdf4vwbffgep78i+t9m2r...@mail.gmail.com

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

[Rene Engelhard]

Hi,

On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
> The longest is:
> 
> libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb
> 
> at 71.

Good, then any bug against openoffice.org is not needed, as that obviously
will be + wontfix wheezy-ignore, because it simply can't be fixed as we need
the transitional packages :)

Grüße/Regards,

René


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325160954.gb...@rene-engelhard.de

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

[Joey Hess]

Steve McIntyre wrote:
> I've noticed a problem recently in the archive when building CDs,
> aggravated to a certain extent by the newer source formats. Some of
> the filenames in the archive are getting *very* long, and this is
> causing issues. As a matter of course, we build CDs with RockRidge and
> Joliet support so that we have long filenames for Linux and Windows
> users.

What is the use case for accessing long filenames from the CD in
Windows? The files needed by win32-loader need to be 
accessible, and documentation too, but it should not matter if
deb files cannot be looked up from within Windows.

If these files could be dealt with, using Rock Ridge alone would be an
alternative to consider:

/README.html
/README.mirrors.html
/README.mirrors.txt
/README.source
/win32-loader.ini
/css/debinstall-print.css
/css/debinstall.css
/doc/bug-log-access.txt
/doc/bug-log-mailserver.txt
/doc/bug-mailserver-refcard.txt
/doc/bug-maint-info.txt
/doc/bug-maint-mailcontrol.txt
/doc/bug-reporting.txt
/doc/constitution.txt
/doc/debian-manifesto
/doc/dedication
/doc/mailing-lists.txt
/doc/social-contract.txt
/doc/source-unpack.txt
/pics/blue-lowerleft.png
/pics/blue-lowerright.png
/pics/blue-upperleft.png
/pics/blue-upperright.png
/pics/debian-61.png
/pics/logo-50.jpg
/pics/openlogo-nd-50.png
/pics/red-lowerleft.png
/pics/red-lowerright.png
/pics/red-upperleft.png
/pics/red-upperright.png
/doc/FAQ/debian-faq.en.html.tar.gz
/doc/FAQ/debian-faq.en.pdf.gz
/doc/FAQ/debian-faq.en.ps.gz
/doc/FAQ/debian-faq.en.txt.gz

Is it possible to provide Joliet filenames for only a subset of files?

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Olaf van der Spek]

On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre  wrote:
> users. The problem is that Joliet has a limit for filename length (64
> characters), and technically we're already past that length. From
> genisoimage.1:

64 is quite low. Is there no way to use longer filenames that still
works on all required platforms?

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikn-bvcodvxp6hhhz-n9qr+we7edt7avsub1...@mail.gmail.com

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

[Steve McIntyre]

On Fri, Mar 25, 2011 at 03:50:32PM +0100, Rene Engelhard wrote:
>Hi,
>
>On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
>> Debian LibreOffice Maintainers 
>>openoffice.org
>
>Dead. Any anything there is just transitional packages you need tor
>squeeze->wheezy upgrades, so need to stay. Is libreoffice also affected?
>From your list it appears not...

The longest is:

libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb

at 71.

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


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

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

[Rene Engelhard]

Hi,

On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
> Debian LibreOffice Maintainers 
>openoffice.org

Dead. Any anything there is just transitional packages you need tor
squeeze->wheezy upgrades, so need to stay. Is libreoffice also affected?
>From your list it appears not...

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325145032.ga...@rene-engelhard.de

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

[Steve McIntyre]

On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
>Hey folks,
>
>I've noticed a problem recently in the archive when building CDs,
>aggravated to a certain extent by the newer source formats. Some of
>the filenames in the archive are getting *very* long, and this is
>causing issues. As a matter of course, we build CDs with RockRidge and
>Joliet support so that we have long filenames for Linux and Windows
>users. The problem is that Joliet has a limit for filename length (64
>characters), and technically we're already past that length. From
>genisoimage.1:
>
>   -joliet-long
>  Allow Joliet filenames to be up to 103 Unicode characters,
>  instead of 64. This breaks the Joliet specification, but appears
>  to work. Use with caution.
>
>I've been using -joliet-long as an option to the CD build scripts for
>a while without any noticeable issues, however we may be able to hit a

   about

>brick wall. There are a few packages that are close to the (already

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



signature.asc
Description: Digital signature

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

[Steve McIntyre]

Hey folks,

I've noticed a problem recently in the archive when building CDs,
aggravated to a certain extent by the newer source formats. Some of
the filenames in the archive are getting *very* long, and this is
causing issues. As a matter of course, we build CDs with RockRidge and
Joliet support so that we have long filenames for Linux and Windows
users. The problem is that Joliet has a limit for filename length (64
characters), and technically we're already past that length. From
genisoimage.1:

   -joliet-long
  Allow Joliet filenames to be up to 103 Unicode characters,
  instead of 64. This breaks the Joliet specification, but appears
  to work. Use with caution.

I've been using -joliet-long as an option to the CD build scripts for
a while without any noticeable issues, however we may be able to hit a
brick wall. There are a few packages that are close to the (already
over-spec) limit now, and if (for example) we end up with a security
upload which adds a few characters to the filename then these files
simply will not fit on our CDs any more.

Therefore, I'm proposing a maximum limit of 80 characters on uploaded
source / deb files to give us some headroom. With help from a friendly
local ftpmaster, I've found the following packages that are currently
over that limit (with a run through dd-list):

Ying-Chun Liu (PaulLiu) 
   libomxil-bellagio

Nicholas Bamber 
   libcgi-application-plugin-authorization-perl (U)

Debian Firebird Group 
   firebird2.5

Debian LibreOffice Maintainers 
   openoffice.org

Debian Perl Group 
   libcgi-application-plugin-authorization-perl

Debian X Strike Force 
   compiz-fusion-plugins-unsupported

Rene Engelhard 
   openoffice.org (U)

Sean Finney 
   compiz-fusion-plugins-unsupported (U)

Damyan Ivanov 
   firebird2.5 (U)

Jaldhar H. Vyas 
   libcgi-application-basic-plugin-bundle-perl
   libcgi-application-plugin-authorization-perl (U)

If we really want to meet the spec, we should be aiming for < 64
characters, but that affects 98 packages and I'm not *too* bothered
about it since testing shows no issues thus far. I'm tempted to file:

 * serious bugs on the packages over 90 characters
 * normal bugs on those over 80
 * wishlist bugs on those over 64

Thoughts?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."  [ seen in ucam.chat ]


signature.asc
Description: Digital signature

Bug#619593: ITP: lv2-extensions-good -- LV2 extensions from the "good" set

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: lv2-extensions-good
  Version : 1
  Upstream Author : David Robillard  and others
* URL : http://lv2plug.in/docs/index.php?title=External_Extensions
* License : GPL
  Programming Lang: C
  Description : LV2 extensions from the "good" set

 LV2 is a simple but extensible successor of LADSPA plugins,
 intended to address the limitations of LADSPA which many
 applications have outgrown.
 .
 The following extensions are provided:
  * http://lv2plug.in/ns/ext/data-access/ - Defines a method for
plugin UIs to have (possibly marshalled) access to the
extension_data function on a plugin instance.
  * http://lv2plug.in/ns/ext/dyn-manifest - An LV2-based
specification for dynamic data generation.
  * http://lv2plug.in/ns/ext/event/ - Defines a generic
time-stamped event port type, which can be used to create
plugins that read and write real-time events
  * http://lv2plug.in/ns/ext/instance-access - Defines a method
for plugin UIs to get a direct handle to an LV2 plugin
instance (LV2_Handle), if possible.
  * http://lv2plug.in/ns/ext/midi - Defines an LV2 event type
for standard raw MIDI.
  * http://lv2plug.in/ns/ext/presets - Defines presets (e.g.
named sets of control values) for LV2 plugins.
  * http://lv2plug.in/ns/ext/uri-map/ - Defines a simple
mechanism for plugins to map URIs to integers, usually for
performance reasons.
  * http://lv2plug.in/ns/extensions/ui - Defines an interface
that can be used in LV2 plugins and hosts to create UIs
for plugins.
  * http://lv2plug.in/ns/extensions/units - Defines a number
of units for use in audio processing.
 .
 This package provides the LV2 extensions from the "good" set,
 a set of extensions which have been discussed and reviewed by
 the LV2 community and implemented in released software.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110325134154.6524.38588.reportbug@alessio-laptop

Ieguusti savu davanu karti!...

[Asnina Olga]

i-virtuve (virtualaa) ienak, saprotams, ari tavaas majaas -

izcep burgerus sev pieejamajaa datoraa , bet apeed tos iistaa bistro!
 
http://www.rigasburgers.info - tur buus pilns info!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325120047.81c64144...@suslik.itm.net.ua

Re: enable/disable support in /usr/sbin/service

[Olaf van der Spek]

On Fri, Mar 4, 2011 at 12:35 PM, Stefano Zacchiroli  wrote:
> On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote:
>> At present there *is* no reliable sysadmin interface for enabling/disabling
>> services.  update-rc.d is not it; many admins have been using 'update-rc.d
>> -f remove' for years, but this is /wrong/ and it is /documented/ that this
>> will cause the links to be readded on package upgrade.  policy-rc.d is not
>> it; the spec for this is bloated and I've never heard of an admin who's ever
>> bothered implementing anything more than a "don't start any services in a
>> chroot" policy using this.  And /etc/default/* isn't it; no consistent
>> variable naming, not implemented for all services (and shouldn't be), so
>> it's not scriptable, so it requires vi.
>>
>> So the mv command above *is* the current method.  And we're in desperate
>> need of a better one.
>
> Right, this is the technical problem to solve: find one (handy) method
> to enable/disable services and "bless" it as the recommended one.

http://packages.debian.org/squeeze/chkconfig

...


-- 
Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTin1+=xxs7ezab+apt2vgrzq7rttan5b5roym...@mail.gmail.com

Live Instructor Led Online Training on ExtJS!

[tulsanamarketing]

Dear Developers,

Your interest and zeal towards learning ExtJS inspired us
to arrange another session on ExtJS Simplified.

Please join us in a 60-minute walk-through of proven unconventional Extjs  
Training

about how it works, to work on and make widgets in Extjs.

ExtJS - Simplified

on

Saturday, April 2, 2011 9:30 AM - 11:30 AM PST

Enjoy the Live Instructor Led Online Training!


Click here to Book your Seat : http://bit.ly/facBjS

We also offer you our Free Beginner's Guide on ExtJS


Get the Download link on the training page here : http://bit.ly/facBjS


Mark the date and time into your calendar now!

We look forward to meeting you!
eZdia Inc.
Arena Place One
7322 Southwest FWY, Suite 1100
Houston, TX 77074

Apple iPod touch (32 GB) 4 GEN NEWEST MODEL WIFI CAMERA :  
http://bit.ly/fj4aGL


--

To unsubscribe from this mailing list, mail to ezdiaunsubscr...@gmail.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0022152d69edcc8f87049f4cd...@google.com

Bug#619586: apt: [apt-transport-mirror] what(): std::bad_alloc (was: Re: cdn.debian.net as a project service?)

[Luca Capello]

Package: apt
Version: 0.8.13
Severity: normal

Hi there!

The discussion started on debian-devel@l.d.o, specifically:

  


On Thu, 10 Mar 2011 20:55:47 +0100, Michael Vogt wrote:
> On Thu, Mar 10, 2011 at 10:22:29AM +0100, Peter Palfrader wrote:
>> On Thu, 10 Mar 2011, Lars Wirzenius wrote:
>> > What would it take to get cdn.debian.net become a service provided by
>> > the project? In other words, cdn.debian.org, instead of cdn.debian.net.
> [..] 
>> I'd really like to see support for sane mirror selection in apt itself,
>> possibly with archive support (i.e. list of mirrors somewhere on
>> ftp.d.o).  That would allow apt to for instance retry on a different
>> server if the first one it tried does not work for some reason, and
>> maybe even report the problem to a central mirror.
>
> There is a "mirror" method in apt since some time that is a bit of a
> combined cdn/README.mirrors approach. Its not much used and probably
> has some rough edges but should be a good starting point.
>
> The idea is that you have a sources.list entry like: 
> deb mirrors://mirrors.debian.org/mirror sid main
  ^^^
The method is singular and mirros.debian.org does not exist.  Anyway, my
sid freezes when trying to use it (top shows 3.1g VIRT and 1.6g RES
memory) and then apt dies:
=
root@gismo:~# echo "deb mirrors://mirrors.debian.org/mirror sid main" 
>/etc/apt/sources.list
root@gismo:~# apt-get update
E: The method driver /usr/lib/apt/methods/mirrors could not be found.

root@gismo:~# echo "deb mirror://mirrors.debian.org/mirror sid main" 
>/etc/apt/sources.list
root@gismo:~# apt-get update
0% [Working]terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
E: Method mirror has died unexpectedly!
E: Sub-process mirror received signal 6.

root@gismo:~# echo "deb mirror://mirror.debian.org/mirror sid main" 
>/etc/apt/sources.list
root@gismo:~# apt-get update
0% [Working]terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
E: Method mirror has died unexpectedly!
E: Sub-process mirror received signal 6.

root@gismo:~# find /var/lib/apt/mirrors/
/var/lib/apt/mirrors/
/var/lib/apt/mirrors/partial

root@gismo:~#
=

This is on an updated sid with 2GB RAM plus 2GB swap, on an Intel X25-M
80GB SSD partitioned as cryptsetup/LVM/ext4.

Thx, bye,
Gismo / Luca

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "0";
APT::Acquire "";
APT::Acquire::Translation "environment";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image.*";
APT::NeverAutoRemove:: "^kfreebsd-image.*";
APT::NeverAutoRemove:: "^linux-restricted-modules.*";
APT::NeverAutoRemove:: "^linux-ubuntu-modules-.*";
APT::NeverAutoRemove:: "^gnumach$";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Default-Release "sid";
APT::Languages "none";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::mirrors "mirrors/";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt/";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt/";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::vendorlist "vendors.list";
Dir::Etc::vendorparts "vendors.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::dpkg "/usr/bin/dpkg";
Dir::Media "";
Dir::Media::MountPath "/media/apt";
Dir::Log "var/log/apt";
Dir::Log::Terminal "term.log";
Dir::Log::History "history.log";
Dir::Ignore-Files-Silently "";
Dir::Ignore-Files-Silently:: "~$";
Dir::Ignore-Files-Silently:: "\.disabled$";
Dir::Ignore-Files-Silently:: "\.bak$";
Dir::Ignore-Files-Silently:: "\.dpkg-[a-z]+$";
Acquire "";
Acquire::cdrom "";
Acquire::cdrom::mount "/media/cdrom/";
Acquire::PDiffs "false";
DPkg "";
DPkg::Pre-Invoke "";
DPkg::Pre-Invoke:: "if [ -x /usr/bin/etckeeper ]; then etckeeper p

Processed: Re: Processed: reassign 619520 to general

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 619520 guessnet
Bug #619520 [general] eth0 is not activated early enough, causing a delay in 
the Ethernet detection
Bug reassigned from package 'general' to 'guessnet'.
> thanks
Stopping processing here.

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


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

Bug#619520: linux-image-2.6.37-2-amd64: some Ethernet cables are not detected

[Vincent Lefevre]

On 2011-03-25 01:15:54 +0100, Vincent Lefevre wrote:
> > It is your responsibility to set an appropriate time limit for
> > guessnet.
> 
> This doesn't solve the problem: it makes the boot longer. By

longer and unreliable. The 4-second maximum delay is still not
sufficient. So, to have some margin, I should probably set a
10-second delay. But this means that in the current situation,
the boot time will always be 10 seconds longer when no Ethernet
cable is plugged in, and for a laptop, this happens quite often.

> bringing up the interface earlier, the time needed by guessnet
> could be spent while other things are done in parallel.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325074403.ga13...@xvii.vinc17.org

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):
> Hello,
> 
> I need some help from Australian people.

I finally settled for listing states. That seems to be the most
unnderstandable option (including for foreigners who happen to arrive
in AU).


This will also be consistent with some other countries where I intend
to do the same (done for Brazil for instance and I'm thinking about it
for federal countriel such as Argentina where last minute changes in
DST choices often tend to "create" more and more "timezones" (indeed
tzdata entries).

Listing states also has an advantage: I can reuse translations from
iso-codes (countries subdivisions are included in the package as
iso-3166-2).




-- 




signature.asc
Description: Digital signature