Nabble - debian-dpkg

Ubuntu dpkg 1.14.20ubuntu6

2008-10-07T10:41:01Z

This e-mail has been sent due to an upload to Ubuntu that contains Ubuntu
changes. It contains the difference between the new version and the
previous version of the same source package in Ubuntu.
Format: 1.7
Date: Wed, 03 Sep 2008 12:50:49 +0100
Source: dpkg
Binary: dpkg dselect dpkg-dev
Architecture: source
Version: 1.14.20ubuntu6
Distribution: intrepid
Urgency: low
Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@...>
Changed-By: Colin Watson <cjwatson@...>
Description:
dpkg - Debian package management system
dpkg-dev - Debian package development tools
dselect - Debian package management front-end
Changes:
dpkg (1.14.20ubuntu6) intrepid; urgency=low
.
* Be more liberal when checking for an Ubuntu Maintainer field; a
case-insensitive check is good enough, and copes e.g. with mplayer's
"Maintainer: Ubuntu MOTU Media Team <motumedia@...>".
Files:
dbf6be4cf4c956e9161d0de592e2dfff 1383 admin required dpkg_1.14.20ubuntu6.dsc
c287a5063e226164e00b1bf620094020 6670557 admin required dpkg_1.14.20ubuntu6.tar.gz
Original-Maintainer: Dpkg Developers <debian-dpkg@...>

diff -pruN 1.14.20ubuntu5/debian/changelog 1.14.20ubuntu6/debian/changelog
--- 1.14.20ubuntu5/debian/changelog 2008-08-19 17:29:31.000000000 +0100
+++ 1.14.20ubuntu6/debian/changelog 2008-09-03 12:50:51.000000000 +0100
@@ -1,3 +1,11 @@
+dpkg (1.14.20ubuntu6) intrepid; urgency=low
+
+ * Be more liberal when checking for an Ubuntu Maintainer field; a
+ case-insensitive check is good enough, and copes e.g. with mplayer's
+ "Maintainer: Ubuntu MOTU Media Team <motumedia@...>".
+
+ -- Colin Watson <cjwatson@...> Wed, 03 Sep 2008 12:50:49 +0100
+
dpkg (1.14.20ubuntu5) intrepid; urgency=low

* scripts/Dpkg/Source/Package.pm: Point gpg at
diff -pruN 1.14.20ubuntu5/scripts/dpkg-source.pl 1.14.20ubuntu6/scripts/dpkg-source.pl
--- 1.14.20ubuntu5/scripts/dpkg-source.pl 2008-07-29 21:12:48.000000000 +0100
+++ 1.14.20ubuntu6/scripts/dpkg-source.pl 2008-09-03 12:45:25.000000000 +0100
@@ -252,7 +252,7 @@ if ($options{'opmode'} eq 'build') {
# https://wiki.ubuntu.com/DebianMaintainerField
if (defined($fields->{Version}) and defined($fields->{Maintainer}) and
$fields->{Version} =~ /ubuntu/) {
- if ($fields->{'Maintainer'} !~ /ubuntu/) {
+ if ($fields->{'Maintainer'} !~ /ubuntu/i) {
if (defined ($ENV{'DEBEMAIL'}) and $ENV{'DEBEMAIL'} =~ /\@ubuntu\.com/) {
error(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
} else {

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-10-07T08:47:52Z

On Tue, 07 Oct 2008, Guillem Jover wrote:
> > Any progress ?
>
> Yeah got the code the day after that mail, but I've not found the time
> to test it. I guess the easiest is to change one of the function
> return values to the output of rand() or similar and see from there.
> I'll try to get to it this week.

Just share it, others might have the time to test (using quota on a openvz
virtual environment for example).

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#501456: dpkg: parallel compression and decompression

2008-10-07T08:08:08Z

Package: dpkg
Version: 1.14.22
Severity: wishlist

For those with systems with multiple CPUs, it would be nice if dpkg
could support multi-threaded decompression and compression. Here are
some implementations and possible hints to implementations of these:

gzip:

http://www.c10n.info/archives/505
http://zlib.net/pigz17.c.gz

bzip2:

http://packages.debian.org/pbzip2

lzma:

Seems there is multi-threading in the windows version, needs porting to
pthread though:

http://groups.google.co.id/group/comp.os.linux.development.apps/browse_thread/thread/f8523eeeeb423fee

--
bye,
pabs

http://wiki.debian.org/PaulWise

signature.asc (204 bytes) Download Attachment

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-10-07T07:14:27Z

Hey!

On Tue, 2008-10-07 at 09:02:54 +0200, Raphael Hertzog wrote:
> On Thu, 18 Sep 2008, Guillem Jover wrote:
> > > The other is that when onerr_abort is signaled dpkg should not
> > > continue processing anything anymore, it should just do whatever cleanup
> > > is required and exit. But that can wait probably post-lenny.
> >
> > So this is the proper fix, and it should not be that big, probably less
> > than 10 lines? Will cook something today or tomorrow...
>
> Any progress ?

Yeah got the code the day after that mail, but I've not found the time
to test it. I guess the easiest is to change one of the function
return values to the output of rand() or similar and see from there.
I'll try to get to it this week.

And it ended up being a 7 lines patch, although I think I'll be
changing part of that error recovery logic for squeeze.

regards,
guillem

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-10-07T00:02:54Z

On Thu, 18 Sep 2008, Guillem Jover wrote:
> > The other is that when onerr_abort is signaled dpkg should not
> > continue processing anything anymore, it should just do whatever cleanup
> > is required and exit. But that can wait probably post-lenny.
>
> So this is the proper fix, and it should not be that big, probably less
> than 10 lines? Will cook something today or tomorrow...

Any progress ?

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#501243: dpkg-source: should ignore .gbp.conf files

2008-10-06T04:44:33Z

reassign 501243 git-buildpackage
found 501243 0.4.40
retitle 501243 git-buildpackage: please support `git config` options instead of .gbp.conf
severity 501243 wishlist
thanks

Hi there!

On Mon, 06 Oct 2008 02:43:16 +0200, Guillem Jover wrote:
> On Sun, 2008-10-05 at 23:18:33 +0200, Luca Capello wrote:
>> Git-buildpackage can be configured in a per-repository .gbp.conf, which
>> must not be included in the package sources.
>>
>> Can .gbp.conf be added to the default -i/-I values, please?
>
> I think it would be way better for git-buildpackage to use "git config"
> instead of polluting the source directory with yet another dot file.

While I fully agree on this (that's why I reassigned the bug), adding
one more file is not really a burden, at least until git-buildpackage
will support plain `git config` options.

The real problem is that AFAIK you cannot append new filter options to
-i/-I, but only completely substitute the default values.

Thx, bye,
Gismo / Luca

attachment0 (322 bytes) Download Attachment

Bug#501243: dpkg-source: should ignore .gbp.conf files

2008-10-05T17:43:16Z

On Sun, 2008-10-05 at 23:18:33 +0200, Luca Capello wrote:
> Package: dpkg-dev
> Version: 1.14.22
> Severity: minor
> User: pkg-fso-maint@...
> Usertag: package-creation

> Git-buildpackage can be configured in a per-repository .gbp.conf, which
> must not be included in the package sources.
>
> Can .gbp.conf be added to the default -i/-I values, please?

I think it would be way better for git-buildpackage to use "git config"
instead of polluting the source directory with yet another dot file.

Feel free to reassign.

regards,
guillem

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#501243: dpkg-source: should ignore .gbp.conf files

2008-10-05T14:18:33Z

Package: dpkg-dev
Version: 1.14.22
Severity: minor
User: pkg-fso-maint@...
Usertag: package-creation

Hi there!

Git-buildpackage can be configured in a per-repository .gbp.conf, which
must not be included in the package sources.

Can .gbp.conf be added to the default -i/-I values, please?

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii binutils 2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii bzip2 1.0.5-1 high-quality block-sorting file co
ii cpio 2.9-14 GNU cpio -- a program to manage ar
ii dpkg 1.14.22 Debian package management system
ii libtimedate-perl 1.1600-9 Time and date functions for Perl
ii lzma 4.43-14 Compression method of 7z format in
ii make 3.81-5 The GNU version of the "make" util
ii patch 2.5.9-5 Apply a diff file to an original
ii perl [perl5] 5.10.0-15 Larry Wall's Practical Extraction
ii perl-modules 5.10.0-15 Core Perl modules

Versions of packages dpkg-dev recommends:
ii build-essential 11.4 Informational list of build-essent
ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-23 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.2-1 The GNU C compiler

Versions of packages dpkg-dev suggests:
ii debian-keyring 2008.09.23 GnuPG (and obsolete PGP) keys of D
ii gnupg 1.4.9-3 GNU privacy guard - a free PGP rep

-- no debconf information

attachment0 (322 bytes) Download Attachment

Bug#141325: Fix for lenny possible?? : Bug#141325: [u-a] simple fix for single manual choice under dangling link and --config

2008-10-04T11:31:07Z

Hi dpkg folks,

I think this old update-alternatives bug needs to be fixed for lenny.
I merged many bug reports. Many of which were reassigned from other
packages. So impact to annoyance of users exists.

If you want to be very conservative patch for lenny, you should use just
following parts of my patch reported:

- if ($#versions == 0) {
+ if ($#versions == 0 && $mode eq 'auto' && $best eq readlink("$altdir/$name")) {

Without this patch, --config does not run even if it has broken symlink
if choice is single. That is wrong.

This does not require manpage update. (But this lacks intuitiveness for --config)

If you are considering applying this for squeeze, please consider
attached newer version which add "--skip" option to skip configuring
auto mode packages which are configured correctly. This is intended to
inspect whole alternative system quickly with --all option (--all was my
patch).

# update-alternatives --skip --all

As far as fixing bad symlink situation created in interrupted upgrade
etc., my previously reported patch works fine.

But how robust update-alternatives are against broken package upload and
subsequent correction is still needs to be investigated for the latest
script. This is separate issue. With this patch, we can recover.

Osamu

--- update-alternatives.orig 2008-09-28 21:43:51.000000000 +0900 +++ update-alternatives 2008-10-04 00:05:31.000000000 +0900 @@ -23,6 +23,7 @@ my $action = ''; # Action to perform (display / install / remove / display / auto / config) my $mode = 'auto'; # Update mode for alternative (manual / auto) +my $skip = ''; # Skip correct auto mode condition for --config my $state; # State of alternative: # expected: alternative with highest priority is the active alternative # expected-inprogress: busy selecting alternative with highest priority @@ -100,6 +101,7 @@ Options: --altdir <directory> change the alternatives directory. --admindir <directory> change the administrative directory. + --skip skip prompt for correct auto mode choice (--config) --verbose verbose operation, more output. --quiet quiet operation, minimal output. --help show this help message. @@ -253,7 +255,7 @@ { my ($spath, $preferred) = (@_); - printf STDOUT _g("Using '%s' to provide '%s'.") . "\n", $spath, $name; + printf STDOUT _g("Using '%s' to provide '%s' in mode=%s.") . "\n", $spath, $name, $mode; checked_symlink("$spath","$altdir/$name.dpkg-tmp"); checked_mv("$altdir/$name.dpkg-tmp", "$altdir/$name"); @@ -336,6 +338,8 @@ } elsif (m/^--admindir$/) { @ARGV || &badusage(sprintf(_g("--%s needs a <directory> argument"), "admindir")); $admindir= shift(@ARGV); + } elsif (m/^--skip$/) { + $skip = '--skip'; } elsif (m/^--all$/) { $action = 'all'; } else { @@ -630,24 +634,29 @@ "Nothing to configure.\n"), $name; return -1; } - if ($#versions == 0) { + if ($skip eq '--skip' && $mode eq 'auto' && $best eq readlink("$altdir/$name")) { print "\n"; - printf _g("There is only 1 program which provides %s\n". + display_link_group(); + return -1; + } + if ($#versions == 0 && $mode eq 'auto' && $best eq readlink("$altdir/$name")) { + print "\n"; + printf _g("There is only 1 program which provides %s properly in auto mode\n". "(%s). Nothing to configure.\n"), $name, $versions[0]; return -1; } print STDOUT "\n"; printf(STDOUT _g("There are %s alternatives which provide \`%s'.\n\n". - " Selection Alternative\n". + " Selection Alternative\n". "-----------------------------------------------\n"), $#versions+1, $name); + printf(STDOUT "%s 0 %s (auto mode)\n", ($mode eq "auto" && readlink("$altdir/$name") eq $best) ? '*' : ' ', $best); for (my $i = 0; $i <= $#versions; $i++) { - printf(STDOUT "%s%s %8s %s\n", - (readlink("$altdir/$name") eq $versions[$i]) ? '*' : ' ', - ($best eq $versions[$i]) ? '+' : ' ', - $i+1, $versions[$i]); + printf(STDOUT "%s %8s %s (manual mode) priority=%s\n", + (readlink("$altdir/$name") eq $versions[$i] && $mode eq "manual") ? '*' : ' ', + $i+1, $versions[$i], $priorities[$i]); } - printf(STDOUT "\n"._g("Press enter to keep the default[*], or type selection number: ")); + printf(STDOUT "\n"._g("Press select number (type enter for the current selection[*]): ")); return 0; } @@ -657,14 +666,19 @@ return if config_message() < 0; $preferred=<STDIN>; chop($preferred); - } until $preferred eq '' || $preferred>=1 && $preferred<=$#versions+1 && + } until $preferred eq '' || $preferred>=0 && $preferred<=$#versions+1 && ($preferred =~ m/[0-9]*/); if ($preferred ne '') { - $mode = "manual"; - $preferred--; - my $spath = $versions[$preferred]; + if ($preferred == 0) { + $action = "auto"; + $mode = "auto"; + } else { + $mode = "manual"; + $preferred--; + my $spath = $versions[$preferred]; - set_links($spath, $preferred); + set_links($spath, $preferred); + } } } @@ -717,7 +731,7 @@ my @filenames = grep !/^\.\.?$/, readdir ADMINDIR; close ADMINDIR; foreach my $name (@filenames) { - system "$0 --config $name"; + system "$0 $skip --config $name"; exit $? if $?; } }

reassign 500401 to dpkg

2008-10-04T10:37:43Z

reassign 500401 dpkg

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#141325: [u-a] simple fix for single manual choice under dangling link and --config

2008-10-01T11:04:13Z

severity 141325 important
tags 141325 patch
forcemerge 141325 199426 203582 282290 285686 311288 311288
thanks

Hi,

When alternative system has broken link for some reason and only one
package uses that alternative system in manual mode, update-alternative
does not update link properly and exits without action.

This seems to be the root cause of many bug reports. We know that there
are many bad uploads of packages. In many cases, their packagers are
convinced to have been fixed those bugs in later upload but those bugs
haunts some user for ever. (but may not be easily reproduced since few
uses manual mode and this is usually set by --cinfig.)

(I did not merge some packages: 87677, if this is with the same root
cause, I am talking 6-7 year old bug.)

Also the output and behavior of --config is so cryptic even though it is
meant for interactive use for quick and easy inspection and
reconfiguration. Assuming no sane person will write script based on
--config output, I redesigned --config to enable support not only for
original --set but also for --auto and --display in one command.

Since this bug is causing broken configurations for some machines, I
made this as "important" bug but not critical for RC. I really wish
some expert to look into this and get it fixed by lenny release.

For dpkg 1.14.22, I hereby attach patch to fix these issues.:
-------------
--- /usr/sbin/update-alternatives.orig 2008-09-28 21:43:51.000000000 +0900
+++ /usr/sbin/update-alternatives 2008-10-02 02:02:30.000000000 +0900
@@ -253,7 +253,7 @@
{
my ($spath, $preferred) = (@_);

- printf STDOUT _g("Using '%s' to provide '%s'.") . "\n", $spath, $name;
+ printf STDOUT _g("Using '%s' to provide '%s' in mode=%s.") . "\n", $spath, $name, $mode;
checked_symlink("$spath","$altdir/$name.dpkg-tmp");
checked_mv("$altdir/$name.dpkg-tmp", "$altdir/$name");

@@ -630,24 +630,24 @@
"Nothing to configure.\n"), $name;
return -1;
}
- if ($#versions == 0) {
+ if ($#versions == 0 && $mode eq 'auto' && $best eq readlink("$altdir/$name")) {
print "\n";
- printf _g("There is only 1 program which provides %s\n".
+ printf _g("There is only 1 program which provides %s properly in auto mode\n".
"(%s). Nothing to configure.\n"), $name, $versions[0];
return -1;
}
print STDOUT "\n";
printf(STDOUT _g("There are %s alternatives which provide \`%s'.\n\n".
- " Selection Alternative\n".
+ " Selection Alternative\n".
"-----------------------------------------------\n"),
$#versions+1, $name);
+ printf(STDOUT "%s 0 %s (auto mode)\n", ($mode eq "auto" && readlink("$altdir/$name") eq $best) ? '*' : ' ', $best);
for (my $i = 0; $i <= $#versions; $i++) {
- printf(STDOUT "%s%s %8s %s\n",
- (readlink("$altdir/$name") eq $versions[$i]) ? '*' : ' ',
- ($best eq $versions[$i]) ? '+' : ' ',
- $i+1, $versions[$i]);
+ printf(STDOUT "%s %8s %s (manual mode) priority=%s\n",
+ (readlink("$altdir/$name") eq $versions[$i] && $mode eq "manual") ? '*' : ' ',
+ $i+1, $versions[$i], $priorities[$i]);
}
- printf(STDOUT "\n"._g("Press enter to keep the default[*], or type selection number: "));
+ printf(STDOUT "\n"._g("Press select number (type enter for the current selection[*]): "));
return 0;
}

@@ -657,14 +657,19 @@
return if config_message() < 0;
$preferred=<STDIN>;
chop($preferred);
- } until $preferred eq '' || $preferred>=1 && $preferred<=$#versions+1 &&
+ } until $preferred eq '' || $preferred>=0 && $preferred<=$#versions+1 &&
($preferred =~ m/[0-9]*/);
if ($preferred ne '') {
- $mode = "manual";
- $preferred--;
- my $spath = $versions[$preferred];
+ if ($preferred == 0) {
+ $action = "auto";
+ $mode = "auto";
+ } else {
+ $mode = "manual";
+ $preferred--;
+ my $spath = $versions[$preferred];

- set_links($spath, $preferred);
+ set_links($spath, $preferred);
+ }
}
}
-------

Please note
$#versions == 0 && $mode eq 'auto' && $best eq readlink("$altdir/$name)) ...
is the part which let this command not to skip processing if symlink
does not match reality.

I have to confess I have not tested for complicated upgrade situation
yet whrere *.dpkg files in such situation may interfare. But so far it
looks close to fixing long standing bugs of sinple but essential Debian
tool called update-alyernative :=)

Osamu

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#500188: Blacklist __gnu_local_gp

2008-09-25T13:36:13Z

Package: dpkg-dev
Version: 1.14.22
Tags: patch

Gcc's -mno-shared support on mips/mipsel introduces a new magic
internally used symbol named __gnu_local_gp. Since gcc-4.3 the
-mno-shared option is default, and dpkg-shlibdeps thows a warning
in many build logs. The appended blacklists the symbol.

Thiemo

--- dpkg-1.14.22/scripts/Dpkg/Shlibs/SymbolFile.pm~ 2008-07-01 18:07:54.000000000 +0100
+++ dpkg-1.14.22/scripts/Dpkg/Shlibs/SymbolFile.pm 2008-09-25 20:49:05.000000000 +0100
@@ -44,6 +44,7 @@ my %blacklist = (
'_GLOBAL_OFFSET_TABLE_' => 1, # hppa, mips, mipsel
'__gmon_start__' => 1, # hppa
'_gp' => 1, # mips, mipsel
+ '__gnu_local_gp' => 1, # mips, mipsel
'_init' => 1, # ALL
'_PROCEDURE_LINKAGE_TABLE_' => 1, # sparc, alpha
'_SDA2_BASE_' => 1, # powerpc

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499924: dpkg-dev: please add support for finding bugs closed in launchpad from changelog

2008-09-23T10:29:36Z

Package: dpkg-dev
Version: 1.14.20
Severity: wishlist
Tags: patch
User: ubuntu-devel@...
Usertags: origin-ubuntu intrepid ubuntu-patch

Hi,

In Ubuntu we have a scheme similar to "Closes: #12345" that allows
us to close Launchpad bugs from the changelog using "LP: #12345"
notation. I would like Debian to include the patch to allow other
packages to find these bugs if they wish. I propose the following
patch to do this. Please consider applying it.

Thanks,

James

--- 1.14.20/scripts/Dpkg/Changelog.pm 2008-05-05 18:07:01.000000000 +0100
+++ 1.14.20ubuntu5/scripts/Dpkg/Changelog.pm 2008-06-26 13:06:51.000000000 +0100
@@ -47,6 +47,7 @@ use base qw(Exporter);

our %EXPORT_TAGS = ( 'util' => [ qw(
find_closes
+ find_launchpad_closes
data2rfc822
data2rfc822_mult
get_dpkg_changes
@@ -646,6 +652,29 @@ sub find_closes {

=pod

+=head3 find_launchpad_closes
+
+Takes one string as argument and finds "LP: #123456, #654321" statements,
+which are references to bugs on Launchpad. Returns all closed bug numbers
+in an array reference.
+
+=cut
+
+sub find_launchpad_closes {
+ my $changes = shift;
+ my @launchpad_closes = ();
+
+ while ($changes &&
+ ($changes =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/ig)) {
+ push(@launchpad_closes, $& =~ /\#?\s?(\d+)/g);
+ }
+
+ @launchpad_closes = sort { $a <=> $b } @launchpad_closes;
+ return \@launchpad_closes;
+}
+
+=pod
+
=head3 data2rfc822

Takes a single argument, either a Dpkg::Changelog::Entry object

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499736: (forw) Bug#499736: [dpkg-dev] No space in russian translate

2008-09-22T11:33:43Z

2008/9/22 Christian Perrier <bubulle@...>:

Updated file is attached. (-1 fuzzy and another missing space)

--
Regards,
Yuri Kozlov

ru.po.gz (37K) Download Attachment

Bug#499736: (forw) Bug#499736: [dpkg-dev] No space in russian translate

2008-09-22T04:23:49Z

Christian Perrier wrote:

> Guys, do you confirm?
>
> ----- Forwarded message from ivan <ivan1986@...> -----
>
> Subject: Bug#499736: [dpkg-dev] No space in russian translate
> Reply-To: ivan <ivan1986@...>, 499736@...
> From: ivan <ivan1986@...>
> To: submit@...
> Date: Sun, 21 Sep 2008 22:30:58 +0400
> X-Mailing-List: <debian-dpkg-bugs@...> archive/latest/8868
> X-CRM114-Status: Good ( pR: 33.0975 )
>
> Package: dpkg-dev
> Version: 1.14.22
> Severity: normal
> Tags: l10n
>
> --- Please enter the report below this line. ---
> dpkg-shlibdeps: предупреждение: зависимости от ??? можно избежать, если ??? не
> будет бесполезно слинкована сней (не используется ни одного её символа).
>
> сней => с ней
>
> --- System information. ---
> Architecture: i386
> Kernel: Linux 2.6.26
>
> Debian Release: lenny/sid
> 500 testing www.debian-multimedia.org
> 500 testing lug32.b-metro.net
> 500 testing lug.bstu.b-metro.net
> 500 testing ftp.ru.debian.org
> 500 stable wine.budgetdedicated.com
> 500 stable download.webmin.com
> 500 lenny rusxmms.sourceforge.net
> 500 lenny 192.168.2.2
>
> --- Package information. ---
> Depends (Version) | Installed
> =================================-+-=============
> dpkg (>= 1.14.6) | 1.14.22
> perl5 |
> perl-modules | 5.10.0-13
> cpio (>= 2.4.2-2) | 2.9-13
> bzip2 | 1.0.5-1
> lzma | 4.43-14
> patch (>= 2.2-1) | 2.5.9-5
> make | 3.81-5
> binutils | 2.18.1~cvs20080103-7
> libtimedate-perl | 1.1600-9
>
>
>
> ----- End forwarded message -----
>

I am not a member of Russian l10n team, but I am russian native speaker

and I confirm this change.

--
Eugene V. Lyubimkin aka JackYF

signature.asc (268 bytes) Download Attachment

Bug#499736: [Fwd: Re: (forw) Bug#499736: [dpkg-dev] No space in russian translate]

2008-09-22T01:28:23Z

-------- Message original --------
Sujet: Re: (forw) Bug#499736: [dpkg-dev] No space in russian translate
Date: Mon, 22 Sep 2008 12:23:48 +0400
De: Sergey Alyoshin <alyoshin.s@...>
Pour :: Christian Perrier <bubulle@...>
Références: <20080922052455.GD3816@...>

On Mon, Sep 22, 2008 at 9:24 AM, Christian Perrier <bubulle@...>
wrote:
> Guys, do you confirm?
> сней => с ней

Yes

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499736: (forw) Bug#499736: [dpkg-dev] No space in russian translate

2008-09-21T22:24:55Z

Guys, do you confirm?

----- Forwarded message from ivan <ivan1986@...> -----

Subject: Bug#499736: [dpkg-dev] No space in russian translate
Reply-To: ivan <ivan1986@...>, 499736@...
From: ivan <ivan1986@...>
To: submit@...
Date: Sun, 21 Sep 2008 22:30:58 +0400
X-Mailing-List: <debian-dpkg-bugs@...> archive/latest/8868
X-CRM114-Status: Good ( pR: 33.0975 )

Package: dpkg-dev
Version: 1.14.22
Severity: normal
Tags: l10n

--- Please enter the report below this line. ---
dpkg-shlibdeps: предупреждение: зависимости от ??? можно избежать, если ??? не
будет бесполезно слинкована сней (не используется ни одного её символа).

сней => с ней

--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26

Debian Release: lenny/sid
500 testing www.debian-multimedia.org
500 testing lug32.b-metro.net
500 testing lug.bstu.b-metro.net
500 testing ftp.ru.debian.org
500 stable wine.budgetdedicated.com
500 stable download.webmin.com
500 lenny rusxmms.sourceforge.net
500 lenny 192.168.2.2

--- Package information. ---
Depends (Version) | Installed
=================================-+-=============
dpkg (>= 1.14.6) | 1.14.22
perl5 |
perl-modules | 5.10.0-13
cpio (>= 2.4.2-2) | 2.9-13
bzip2 | 1.0.5-1
lzma | 4.43-14
patch (>= 2.2-1) | 2.5.9-5
make | 3.81-5
binutils | 2.18.1~cvs20080103-7
libtimedate-perl | 1.1600-9

----- End forwarded message -----

--

signature.asc (204 bytes) Download Attachment

Bug#499736: [dpkg-dev] No space in russian translate

2008-09-21T11:30:58Z

Package: dpkg-dev
Version: 1.14.22
Severity: normal
Tags: l10n

--- Please enter the report below this line. ---
dpkg-shlibdeps: предупреждение: зависимости от ??? можно избежать, если ??? не
будет бесполезно слинкована сней (не используется ни одного её символа).

сней => с ней

--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26

Debian Release: lenny/sid
500 testing www.debian-multimedia.org
500 testing lug32.b-metro.net
500 testing lug.bstu.b-metro.net
500 testing ftp.ru.debian.org
500 stable wine.budgetdedicated.com
500 stable download.webmin.com
500 lenny rusxmms.sourceforge.net
500 lenny 192.168.2.2

--- Package information. ---
Depends (Version) | Installed
=================================-+-=============
dpkg (>= 1.14.6) | 1.14.22
perl5 |
perl-modules | 5.10.0-13
cpio (>= 2.4.2-2) | 2.9-13
bzip2 | 1.0.5-1
lzma | 4.43-14
patch (>= 2.2-1) | 2.5.9-5
make | 3.81-5
binutils | 2.18.1~cvs20080103-7
libtimedate-perl | 1.1600-9

Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T12:23:22Z

On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote:
> On Thu, 18 Sep 2008, Bill Allombert wrote:
> > > I have to say i verry rarely do not use debuild. And 99% of the
> > > exceptions are calling debian/rules clean.
> >
> > Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> > directly.
>
> This has been fixed already. It calls dpkg-buildpackage now (except if you use
> its hook features).

So it still call debian/rules directly in some case.

> (And I don't see why one way would be more Debianish than the other)

Neither I do, but then I do not attempt to kill one way in favour of the other.

I would object to a proposal policy making dpkg-buildpackage mandatory
to build packages.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T12:08:21Z

Goswin von Brederlow <goswin-v-b@...> writes:

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

Right. If you want to make this a rule, then we should discuss it, reach
a consensus, document and publicize the change, and so forth.

Right now, I feel like this change is being made as part of dpkg
development, without general recognition of what's happening and without
the corresponding changes to Policy so that DDs know what to expect. (I
don't think this is *intentional* on your part, more a case of a set of
decisions that all seemed like a good idea at the time but which
cumulatively have a significant impact.)

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

The hard part of standards isn't the common case. Currently, debian/rules
is defined as the package build interface, and while most people don't
normally rely on that, we don't know what might break; one of the points
of a standard is to let people rely on it without having to tell you first
what they're doing.

Personally, I use debian/rules build all the time for testing, and would
never have thought to mention it to anyone.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#497893: marked as done (dpkg: [INTL:vi] Vietnamese program translation update)

2008-09-18T10:07:37Z

notfixed apt/0.7.15~exp1
thanks

Hi Michael,

On Tue, 2008-09-16 at 22:10:16 +0000, Debian Bug Tracking System wrote:
[...]

> Package: dpkg
> Tags: l10n patch
> Severity: wishlist
>
> The updated Vietnamese translation for the program file: dpkg
>
> translated and submitted by:
>
> Clytie Siddall
> Vietnamese Free-Software Translation Team
> http://vnoss.net/dokuwiki/doku.php?id=projects:l10n

> Date: Tue, 16 Sep 2008 21:32:06 +0000
> From: Michael Vogt <mvo@...>
> To: 497893-close@...
> Subject: Bug#497893: fixed in apt 0.7.15~exp1
> X-Spam-Status: No, score=-14.7 required=4.0 tests=BAYES_00,FROMDEVELOPER,
> FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,HEADER_X_KATIE,IMPRONONCABLE_2,
> MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2,PGPSIGNATURE
> autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
>
> Source: apt
> Source-Version: 0.7.15~exp1
>
> We believe that the bug you reported is fixed in the latest version of
> apt, which is due to be installed in the Debian FTP archive:

[...]
> Changes:
> apt (0.7.15~exp1) experimental; urgency=low
[...]
> [ Program translations ]
> * Vietnamese updated. Closes: #497893

Seems you closed the wrong bug, no big deal though as this was
already closed, but you might want to correct the changelog and close
the relevant bug in apt.

regards,
guillem

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-09-18T09:59:21Z

Hey,

On Tue, 2008-09-16 at 23:14:04 +0300, Guillem Jover wrote:

> So I think there's two things to fix here, one is that the fseek() in
> createimptmp() should be done just before the fwrite() in
> modstatdb_note_core() to guarantee that we are going to be always at the
> beginning, and we make proper use of the reserved space allocated
> previously with those '#padding' lines to avoid the out of space
> condition. That's a 4-liner patch, which should be fine for lenny, and
> prevents this bogus condition were the user most probably is going to
> remove that file to be able to continue, which might produce an
> inconsistent state in the dpkg db. And the real problem is that there
> might not be an easy manual fix by the users if the status data could
> not be completely written to the update file.

I take this back, the fseek() needs to be there to guarantee that the
data has been written. So moving it would only help partially, as we
would always be writting at the beginning but the fwrite() might not
have enough space from the reserved padding, and the data might get
truncated.

> The other is that when onerr_abort is signaled dpkg should not
> continue processing anything anymore, it should just do whatever cleanup
> is required and exit. But that can wait probably post-lenny.

So this is the proper fix, and it should not be that big, probably less
than 10 lines? Will cook something today or tomorrow...

regards,
guillem

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T08:36:46Z

On Thu, 18 Sep 2008, Bill Allombert wrote:
> > I have to say i verry rarely do not use debuild. And 99% of the
> > exceptions are calling debian/rules clean.
>
> Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> directly.

This has been fixed already. It calls dpkg-buildpackage now (except if you use
its hook features).

(And I don't see why one way would be more Debianish than the other)

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T07:48:25Z

On Thu, Sep 18 2008, Goswin von Brederlow wrote:

>>Russ Allbery <rra@...> writes:
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
>
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
>
> The bugreports relevant for this have 2 solutions:
>
> 1) make dpkg-buildpackage use (or tool with equivalent environment
> setting up capabilities) mandatory
>
> 2) have debian/rules call something to set DEB_VENDOR and possibly
> more
>
> E.g. 'include /usr/share/dpkg/Makefile.dpkg'
> or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
> DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
>
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

But you need to modify the rules file anyway to take advantage
of the DEB_VENDOR variable, no? Currently, setting it does nothing for
any package. So if people are changing the rules file, they can also
add in those two lines.

>> My objection is specifically to having dpkg-buildpackage set a
>> variety of environment variables *by default*, and then telling
>> package maintainers that they should rely on those environment
>> variables being set in the default case. That breaks the
>> debian/rules interface and requires that all package builds go
>> through dpkg-buildpackage. Having dpkg-buildpackage set environment
>> variables in the non-default case like Emdebian is not a problem,
>> since for Emdebian builds (for example) Emdebian can decide that
>> using dpkg-buildpackage or setting the environment variables manually
>> is required. There is no existing precedent, and they can make that
>> rule from scratch.

I tend to agree.

> Then you have one interface for Debian and one interface for every
> other vendor including ubuntu (or option 2 above).

>> My concern is for the default build where there *is* an existing
>> precedent that debian/rules build should work sanely, not for support
>> for special cases like that where the existing debian/rules interface
>> already doesn't do the right thing without additional help.

>> If you are going to go down this path of having dpkg-buildpackage set
>> up an environment that package maintainers should rely on, you or
>> someone else on the dpkg team needs to make a debian-devel-announce
>> post making it clear that debian/rules build is no longer a supported
>> interface for building packages and using dpkg-buildpackage is
>> required for consistent behavior.

I see that as a serious degradation in the quality of the
distribution.

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

No. Debian is a member of the free software community, and being
able to just do a configure, or a build, or build a single binary, by
end users, is a feature that should not be given up easily. And
certainly not without some significant rationale; degrating features
for most of our users to cater to other distributions does not actually
cut it.

>> Right now, I don't think most Debian Developers have any idea what the
>> implications of these changes are.

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

I have never ever used debuild. So there is another anecdote,
which may or may not mean anything.

manoj
--
"Nothing can stop him. Not even common sense." Mark Komarinski
Manoj Srivastava <srivasta@...> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T06:35:26Z

On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote:

> Russ Allbery <rra@...> writes:
>
> > Raphael Hertzog <hertzog@...> writes:
> >> On Wed, 10 Sep 2008, Bill Allombert wrote:
> >
> >>> I like to say I concurr with Russ. There are some much difference
> >>> between packages that distributions wide default does not make sense.
> >>> Such change would rather lead me to hardcode values of
> >>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >>
> >> But more and more people want to be able to change distribution wide
> >> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> >> other want to be able to enable hardening options by default and I agree
> >> with them that official support for such a facility is desirable.
> >
> > So they should set DEB_BUILD_OPTIONS in the environment. That's what it's
> > for. I don't have any objections to that, or even to doing it via
> > dpkg-buildpackage.
>
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
>
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
>
> The bugreports relevant for this have 2 solutions:
>
> 1) make dpkg-buildpackage use (or tool with equivalent environment
> setting up capabilities) mandatory
>
> 2) have debian/rules call something to set DEB_VENDOR and possibly
> more
>
> E.g. 'include /usr/share/dpkg/Makefile.dpkg'
> or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
> DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
>
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

2) is the right way to proceed for _Debian_. People in a hurry can use 1,
but not us.

2) imply that packages will not have DEB_VENDOR support unless some
check they support it.

> > Right now, I don't think most Debian Developers have any idea what the
> > implications of these changes are.
>
> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
directly.

Cheers,
Bill.

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#489771: New Build-Options field and build-arch option, please review

2008-09-18T06:03:20Z

Russ Allbery <rra@...> writes:

> Raphael Hertzog <hertzog@...> writes:
>> On Wed, 10 Sep 2008, Bill Allombert wrote:
>
>>> I like to say I concurr with Russ. There are some much difference
>>> between packages that distributions wide default does not make sense.
>>> Such change would rather lead me to hardcode values of
>>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>>
>> But more and more people want to be able to change distribution wide
>> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
>> other want to be able to enable hardening options by default and I agree
>> with them that official support for such a facility is desirable.
>
> So they should set DEB_BUILD_OPTIONS in the environment. That's what it's
> for. I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

Setting the environment on a distribution wide level is ugly and
fragile. Too many users will reset the environment in their .bashrc.

Instead the idea was to have a vendor (set in
/etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.

The bugreports relevant for this have 2 solutions:

1) make dpkg-buildpackage use (or tool with equivalent environment
setting up capabilities) mandatory

2) have debian/rules call something to set DEB_VENDOR and possibly
more

E.g. 'include /usr/share/dpkg/Makefile.dpkg'
or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)

The argument against 2 is that is requires every source to be modified
if they want to support vendors whereas 1 only needs some small
modification to dpkg-buildpackage to support calling arbitrary targets
in debian/rules and a change in policy making its use mandatory.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case. That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage. Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required. There is no existing precedent, and they can make that rule
> from scratch.

Then you have one interface for Debian and one interface for every
other vendor including ubuntu (or option 2 above).

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
>
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.

Plus a note in policy clarifying that debian/rules is only an
interface for dpkg-buildpackage but not users.

> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

I have to say i verry rarely do not use debuild. And 99% of the
exceptions are calling debian/rules clean.

MfG
Goswin

PS: with dpkg-buildpackage setting env vars like it does now you
already have a verry confusing situation.

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499088: dpkg-dev: Should do chmod +x debian/rules

2008-09-17T15:27:00Z

Hello Raphael,

Raphael Hertzog schrieb am Wed 17. Sep, 08:12 (+0200):

> On Tue, 16 Sep 2008, Russell Coker wrote:
> > On Tuesday 16 September 2008 16:38, Raphael Hertzog <hertzog@...>
> > wrote:
> > > Could you instead explain why you didn't use dpkg-source in the first
> > > place ?
> >
> > If dpkg-source could take just an orig.tar.gz file and a diff.gz then I would.
> >
> > But according to the man page I need a dsc file as well.
>
> And in which situation do you lack a .dsc ?

If you try a new upstream release with the diff.gz from the last version
in Debian.

/me stumbled over this problem, too

Bye, Jörg.
--
Wir leben zwar unter dem gleichen Himmel,
müssen aber nicht zwangsläufig den gleichen Horizont haben.

signature.asc (204 bytes) Download Attachment

Bug#498585: setting package to dselect dpkg-dev dpkg, tagging 498585, tagging 499028

2008-09-17T07:59:06Z

# Automatically generated email from bts, devscripts version 2.10.35
# via tagpending
#
# dpkg (1.14.23) UNRELEASED; urgency=low
#
# * Greek (Emmanuel Galatoulas). Closes: #498585
# * Russian (Yuri Kozlov). Closes: #499028
#

package dselect dpkg-dev dpkg
tags 498585 + pending
tags 499028 + pending

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Friend, Check these Inspirational Videos!

2008-09-16T23:54:03Z

Hi Friend,
I recently happen to see these Free inspirational Videos and i loved them, they are Amazing! take a look at them at the Link below!

Also, there is a nice Mind Power Course(1Book + 2CDs) you might be interested in.

http://www.myi.goldeninspiration.com?a=tr&cid=77067

Regards,
Shalini Sharma

If you do not want to get an invitation from our site ever again, please click here.
http://207.45.191.26/invite/myivi/unsubscribe.php?a=bl&e=ZGViaWFuLWRwa2dAbGlzdHMuZGViaWFuLm9yZw==

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499088: dpkg-dev: Should do chmod +x debian/rules

2008-09-16T23:12:07Z

On Tue, 16 Sep 2008, Russell Coker wrote:
> On Tuesday 16 September 2008 16:38, Raphael Hertzog <hertzog@...>
> wrote:
> > Could you instead explain why you didn't use dpkg-source in the first
> > place ?
>
> If dpkg-source could take just an orig.tar.gz file and a diff.gz then I would.
>
> But according to the man page I need a dsc file as well.

And in which situation do you lack a .dsc ?

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-09-16T13:14:04Z

forcemerge 499070 497041
thanks

On Tue, 2008-09-16 at 01:06:05 +0200, Alexander Prinsier wrote:
> Package: dpkg
> Version: 1.14.22
> Severity: serious
>
> I was installing php5 while my system ran out of disk space. dpkg
> breaks, and leaves the system in a state where I can no longer use dpkg.
> To find out the version number of dpkg I used /var/log/dpkg.log, as I
> couldn't use dpkg to find it's own version number... Hope it's the
> correct one.

> This is what happened:
>
> [...]
> Selecting previously deselected package libjpeg62.
> Unpacking libjpeg62 (from .../libjpeg62_6b-14_i386.deb) ...
> dpkg: error processing /var/cache/apt/archives/libjpeg62_6b-14_i386.deb
> (--unpack):
> failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during
> `./usr/share/doc/libjpeg62/copyright': Disk quota exceeded
> Selecting previously deselected package libdjvulibre21.
> Unpacking libdjvulibre21 (from .../libdjvulibre21_3.5.20-8_i386.deb) ...
> dpkg: error processing
> /var/cache/apt/archives/libdjvulibre21_3.5.20-8_i386.deb (--unpack):
> failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during
> `./usr/lib/libdjvulibre.so.21.0.0': Disk quota exceeded
> dpkg-deb: subprocess paste killed by signal (Broken pipe)
> Selecting previously deselected package libxpm4.
> Unpacking libxpm4 (from .../libxpm4_1%3a3.5.7-1_i386.deb) ...
> Selecting previously deselected package libgd2-xpm.
> Unpacking libgd2-xpm (from .../libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb) ...
> dpkg: error processing
> /var/cache/apt/archives/libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb (--unpack):
> unable to flush /var/lib/dpkg/updates/tmp.i after padding: Disk quota exceeded

Here's where the problem starts. That «tmp.i» file is the one that has
been filled with '#padding' lines, the fflush() in createimptmp() fails,
and it ohshite()s, but just before it has been able to rewind the file to
the beginning.

> Processing triggers for man-db ...
> /usr/bin/mandb: can't write to /var/cache/man/19933: Disk quota exceeded
> gdbm fatal: read error
> dpkg: failed to write status record about `libcairo2' to
> `/var/lib/dpkg/status': Disk quota exceeded
> E: Sub-process /usr/bin/dpkg returned an error code (2)
> A package failed to install. Trying to recover:
> dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1:
> newline in field name `#padding'
> Press return to continue.

The second problem is that even if the ohshite() called from
createimptmp() is protected inside an onerr_abort section, the execution
continues in archivefiles(), out of process_archive() but into
process_queue(), which at some point calls a modstatdb_note(), moving
the «tmp.i» file into the «0119» one, then another ohshite() is called
and the onerr_abort is sensed again, making process_queue() terminate
its loop.

> # dpkg --configure -a
> dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1:
> newline in field name `#padding'
> #

But at the point that modstat_note() was called the function wrote at
the end of it, preserving all the '#padding' lines, and making dpkg
barf subsequently.

So I think there's two things to fix here, one is that the fseek() in
createimptmp() should be done just before the fwrite() in
modstatdb_note_core() to guarantee that we are going to be always at the
beginning, and we make proper use of the reserved space allocated
previously with those '#padding' lines to avoid the out of space
condition. That's a 4-liner patch, which should be fine for lenny, and
prevents this bogus condition were the user most probably is going to
remove that file to be able to continue, which might produce an
inconsistent state in the dpkg db. And the real problem is that there
might not be an easy manual fix by the users if the status data could
not be completely written to the update file.

The other is that when onerr_abort is signaled dpkg should not
continue processing anything anymore, it should just do whatever cleanup
is required and exit. But that can wait probably post-lenny.

regards,
guillem

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499173: dpkg - depends against optional package

2008-09-16T12:55:37Z

reassign 499173 ftp.debian.org
retitle 499173 ftp.debian.org: lzma must be of priority required
severity 499173 serious
thanks

On 2008-09-16 21:04 +0200, Bastian Blank wrote:

> dpkg pre-depends on lzma which is still optional. See §2.5 Policy.

Which means that the priority of lzma needs to be adjusted.

Reassigning to ftp.debian.org for that,
Sven

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499173: dpkg - depends against optional package

2008-09-16T12:04:39Z

Package: dpkg
Version: 1.14.22
Severity: grave

dpkg pre-depends on lzma which is still optional. See §2.5 Policy.

Bastian

--
Oh, that sound of male ego. You travel halfway across the galaxy and
it's still the same song.
-- Eve McHuron, "Mudd's Women", stardate 1330.1

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#499070: dpkg leaves system in unusable state after running out of diskspace

2008-09-16T04:54:31Z

Alexander Prinsier wrote:

> Luk Claes schreef:
>> Alexander Prinsier wrote:
>>> Package: dpkg
>>> Version: 1.14.22
>>> Severity: serious
>>>
>>> I was installing php5 while my system ran out of disk space. dpkg
>>> breaks, and leaves the system in a state where I can no longer use dpkg.
>>> To find out the version number of dpkg I used /var/log/dpkg.log, as I
>>> couldn't use dpkg to find it's own version number... Hope it's the
>>> correct one.
>>
>> Did you try to 'rm -rf /tmp/*' or 'rm /var/cache/apt/archives/*' or
>> similar to see if you really cannot use dpkg anymore?
>
> Actually it's a virtual environment (from the openvz.org project).
> That's why I got a disk quota exceeded instead of disk full. (But that
> shouldn't matter much). After I got the error I told openvz to increase
> the disk quota, and I tried dpkg --configure -a again. I got the same
> error. In a non-virtual environment it's a little less trivial to
> increase the size of your disk :)
>
> So yes, I couldn't use dpkg anymore.
>>
>> This doesn't feel like an RC bug to me, though it would be nice if dpkg
>> would warn before trying to fill the disk space.
>
> I had to remove /var/lib/dpkg/updates/0119 (which seemed to contain
> bogus data), and then dpkg could continue. I hope I didn't damage the
> consistency of my system by doing that.
>
> Well suppose someone low on disk space upgrades to lenny and the
> installation just breaks in the middle of the upgrade... Wouldn't be
> much fun.
>
> Considering the criteria for grave: "makes the package in question
> unusable or mostly so", I think it matches that.

Well, the package does not behave that way by default, only when you run
out of disk space... anyway it would be good to get some maintainer
reaction.

Cheers

Luk

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...