Re: dpkg-source cause gap-atlasrep to FTBFS for no reason
severity 971203 important quit > > root (to '/tmp/gap-atlasrep-2.1.0') > > E: Unpack command 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc' > > failed. > > > > There is no rationale to reject such a symlink which does not point > > _outside_ the source root, but _to_ the source root. > > This leads to a spurious FTBFS. I lowered the severity to important because gap-atlasrep has been updated to avoid this FTBFS and according to Lucas there are no other packages affected in unstable. Cheers, -- Bill. Imagine a large red swirl here.
dpkg-source cause gap-atlasrep to FTBFS for no reason
reassign 971203 dpkg-dev severity grave retitle dpkg-source cause gap-atlasrep to FTBFS quit On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote: > Source: gap-atlasrep > Version: 2.1.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200926 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' > > points outside source root (to '/<>') Dear Dpkg developers, $ apt-get source gap-atlasrep Fetched 1351 kB in 2s (722 kB/s) dpkg-source: info: extracting gap-atlasrep in gap-atlasrep-2.1.0 dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2 dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying doc-makefile dpkg-source: info: applying default-dir dpkg-source: error: pathname 'gap-atlasrep-2.1.0/debian/gaproot/pkg/AtlasRep' points outside source root (to '/tmp/gap-atlasrep-2.1.0') E: Unpack command 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc' failed. There is no rationale to reject such a symlink which does not point _outside_ the source root, but _to_ the source root. This leads to a spurious FTBFS. Also I am concerned that developers might need to unpack old packages with symlinks in them. There should be a way to do it, if only to fix the packaging. Cheers, Bill
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 01:39:45PM +, Colin Watson wrote: > On Wed, Jan 20, 2016 at 12:31:52PM +0100, Balint Reczey wrote: > > On 06/04/2014 03:41 AM, Guillem Jover wrote: > > > * Other programs could “easily” use dpkg-architecture to check for > > >identity or a match. (This poses problems for programs that do not > > > > I think making apt call dpkg-architecture for matching would be a good > > way of ensuring consistency with dpkg. Caching the results in a hash > > table would make matching even faster than it is currently. > > dpkg-architecture is in dpkg-dev, so not reliably usable at run-time. > dpkg doesn't currently provide a way to make this kind of query without > development tools installed. It's also probably not trivial to move it > because its current implementation relies on dpkg's Perl modules, which > also aren't part of the core dpkg binary package. > > I think this is somewhat unfortunate, but it is the reality right now. > Perhaps a good thing for somebody to work on would be reimplementing > dpkg-architecture in C so that it could be moved to the dpkg binary > package? As I understand, dpkg-architecture query the C compiler which is not always avalaible. Cheers, -- Bill. Imagine a large red swirl here.
Re: Bug#680626: Squeeze->Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0
On Wed, Aug 01, 2012 at 12:22:22AM +0200, Julien Cristau wrote: > On Mon, Jul 16, 2012 at 14:19:03 +0200, Julien Cristau wrote: > > > On Sun, Jul 15, 2012 at 18:26:50 +0200, Guillem Jover wrote: > > > > > W/o having looked yet at the details I'd say this *seems* like #671711, > > > which I'm not planning on fixing for wheezy as it would introduce > > > regressions on other situations, and given that this behaviour has > > > been around since the introduction of triggers, and while quite > > > unfortunate it's something that will have to be worked around on the > > > affected packages because older dpkg will not be able to handle this > > > correctly anyway. > > > > > > Going to look now, to make sure the above is the case. > > > > > That seems likely. What is the recommended workaround here? Should > > package postinsts just ignore failures when called with 'triggered', or > > is there a better way? > > > Ping? Any ideas? The current behaviour of triggers is well documented. Packagers should not use triggers in situation when they need more than what the trigger interface offer. This is why menu do not use triggers (see #556104). Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120803090425.GD17827@yellowpig
Re: [Popcon-developers] Bug#660712: popularity-contest broken with Multi-Arsch
On Tue, Apr 03, 2012 at 10:13:53PM +0200, Raphael Hertzog wrote: > Hi, > > On Tue, 03 Apr 2012, Bill Allombert wrote: > > > /etc/cron.daily/popularity-contest: > > > dpkg-query: error: --listfiles needs a valid package name but > > > 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more > > > than one installed instance > > > > I think dpkg should just report the list of files in both packages to > > preserve the API. > > It's not going to happen. This interface choice has been discussed at > length. I don't want to rehash the discussion. Why not ? This provides backward compatibility without affecting the new interfaces. You required popcon to use dpkg -L because you said this is the stable interface, but now some month later, this interface is broken even though it can be easily kept compatible. If it does not provide a stable interface, then I should revert to direct file access since this is significantly faster. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120415193536.GA21761@yellowpig
Re: popularity-contest broken with Multi-Arsch
On Wed, Apr 04, 2012 at 01:14:34AM +0200, Raphael Hertzog wrote: > On Tue, 03 Apr 2012, Jonathan Nieder wrote: > > Forgive my ignorance: could you explain the rationale for the choice > > that was made for the meaning of "dpkg-query -L " when > > is multiarch:same? > > (Unless of course you wanted to merge the 2 blocks for bar, but then we're > needlessly complicating the code to create a fake view that doesn't match > dpkg's own view of the system) Yes, this it what we need. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403232658.GD32630@yellowpig
Re: [Popcon-developers] Bug#660712: popularity-contest broken with Multi-Arsch
On Tue, Apr 03, 2012 at 03:27:47PM +, Thorsten Glaser wrote: > ping? > -- Forwarded message -- > From: Cron Daemon > Message-ID: <201204030625.q336pfbx002...@zigo.mirbsd.org> > X-Spam-Status: No, hits=0.00 required=0.90 > To: r...@zigo.mirbsd.org > Date: Tue, 3 Apr 2012 06:25:41 GMT > Subject: Cron test -x /usr/sbin/anacron || ( cd / && run-parts > --report /etc/cron.daily ) > > /etc/cron.daily/popularity-contest: > dpkg-query: error: --listfiles needs a valid package name but 'gcc-4.7-base' > is not: ambiguous package name 'gcc-4.7-base' with more than one installed > instance I think dpkg should just report the list of files in both packages to preserve the API. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403182946.GB32630@yellowpig
Re: [Popcon-developers] Bug#659782: does not cope with multiarch packages being installed
reassign 659782 dpkg
found 659782
retitle 659782 dpkg -L does not work for multi-arch foreign packages.
tags 659782 + experimental
quit
On Tue, Feb 14, 2012 at 09:21:47AM +0100, Raphael Hertzog wrote:
> Hi,
>
> On Mon, 13 Feb 2012, Philipp Kern wrote:
> > > So are you suggesting that dpkg should use ${binary:Package} ?
> > > Could you patch /usr/sbin/popularity-contest line 161 to add binary: and
> > > check whether
> > > it works correctly ?
> > >
> > > Or did I misunderstand something ?
> >
> > This only helps for the libc6-i686:i386 m-a same case (but it does
> > help there). It doesn't for the mksh:i386 m-a foreign case.
> >
> > dpkg devs cc'ed in the hope that they can contribute why -L behaves
> > differently and how one should solve this…
>
> This is definitely a bug in dpkg (for "dpkg -L mksh"). The default naming
> of foreign non-"multi-arch: same" packages changed and the input side was
> not adapted to cope with it.
>
> Thanks for reporting. I will look into it later.
So I am reassigning this bug to dpkg.
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Pre-order a copy of the Debian Administrator's Handbook and help
> liberate it: http://debian-handbook.info/liberation/
Using Debian ressource for commercial advertising ? Tsk,Tsk.
Cheers,
--
Bill.
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214212420.GA30798@yellowpig
Re: The trigger in your Debian packages
On Fri, Jun 03, 2011 at 10:24:23AM +0200, Raphael Hertzog wrote: > Hello, > > Russ Allbery >lintian (U) >nvidia-graphics-drivers (U) > > Bill Allombert >gap >menu I do not think this would be a problem for theses two. However in both case, the ability to run the trigger only after the triggering packages are configured would be a plus. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110604151938.GE2994@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Sun, May 08, 2011 at 09:01:12PM +0200, Raphael Hertzog wrote: > On Sun, 08 May 2011, Bill Allombert wrote: > > > Thanks, seems to work fine, I have no error/warning at least. > > > > > OK, so you get comparable results. It is very odd that there so much a > > difference between > > batch of 1 package and batch of 2 packages. Maybe this is a dpkg issue ? > > Actually it's a bug in your script... replace "length @pkglist" > with "scalar @pkglist" and you'll get entirely different results... > which are much more logical. > > batch of 5: 0m37.426s > batch of 10: 0m20.974s > batch of 50: 0m7.722s > batch of 200: 0m5.090s > batch of 1000: 0m4.437s Ah thanks for spotting that mistake! Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509154842.GR6897@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Sat, May 07, 2011 at 06:45:03PM +0200, Raphael Hertzog wrote: > On Sat, 07 May 2011, Bill Allombert wrote: > > Thanks, please find a popularity-contest script that uses dpkg -L by batch. > > The size of the batch is $dpkg_batch_size at the start of the script. > > > > Below are timings on my laptop (with a fast solid-state disk): > > > > Direct access : 2.214 s > > batch of 1 pkg : 31.446 s > > batch of 2 pkgs: 5.218 s > > batch of 3 pkgs: 2.652 s > > batch of 4 pkgs: 2.405 s > > batch of 5 pkgs: 2.395 s > > batch of 8 pkgs: 2.380 s > > batch of 10 pkgs: 2.370 s > > batch of >=10 pkgs: about 2.370 s > > > > Please test with multiarch. > > Thanks, seems to work fine, I have no error/warning at least. > > batch of 1 pkg: 3m10.789s > batch of 2 pkgs: 0m21.769s > batch of 3 pkgs: 0m6.362s > batch of 4 pkgs: 0m4.763s > batch of 5 pkgs: 0m4.714s > batch of 10 pkgs: 0m4.670s > Direct access: 0m4.637s OK, so you get comparable results. It is very odd that there so much a difference between batch of 1 package and batch of 2 packages. Maybe this is a dpkg issue ? Also, how does dpkg -L handles the dpkg lock ? Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508102631.GF6897@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Wed, Apr 20, 2011 at 11:45:08PM +0200, Guillem Jover wrote:
> On Wed, 2011-04-20 at 23:08:51 +0200, Bill Allombert wrote:
> > On Wed, Apr 20, 2011 at 10:51:57PM +0200, Raphael Hertzog wrote:
> > > On Wed, 20 Apr 2011, Bill Allombert wrote:
> > > > On Wed, Apr 20, 2011 at 09:11:59PM +0200, Raphael Hertzog wrote:
> > > > > You can invoke "dpkg -L" less often by giving multiple packages as
> > > > > parameters. Each set of files will be separated by an empty line.
> > > >
> > > > Good, is that behaviour documented somewhere ?
> > >
> > > man dpkg-query shows that multiple parameters are allowed, it does not
> > > explain that an empty line is the separator though.
> >
> > Well, surely we cannot rely on such undocumented behaviour.
>
> <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=e6b6ff088>
Thanks, please find a popularity-contest script that uses dpkg -L by batch.
The size of the batch is $dpkg_batch_size at the start of the script.
Below are timings on my laptop (with a fast solid-state disk):
Direct access : 2.214 s
batch of 1 pkg : 31.446 s
batch of 2 pkgs: 5.218 s
batch of 3 pkgs: 2.652 s
batch of 4 pkgs: 2.405 s
batch of 5 pkgs: 2.395 s
batch of 8 pkgs: 2.380 s
batch of 10 pkgs: 2.370 s
batch of >=10 pkgs: about 2.370 s
Please test with multiarch.
Cheers,
--
Bill.
Imagine a large red swirl here.
#!/usr/bin/perl -w
#
# Copyright (C) 2003 by Bill Allombert
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
# based on a design and a bash/gawk script
#
# Copyright (C) 1998,2000 by Avery Pennarun, for the Debian Project.
# Use, modify, and redistribute modified or unmodified versions in any
# way you wish.
use strict;
use 5.6.0;
my $dpkg_batch_size=10;
my $popcon_conf="/etc/popularity-contest.conf";
my %opts=();
# $popcon_conf is in shell-script format
my $HOSTID = qx(unset MY_HOSTID; . $popcon_conf; echo \$MY_HOSTID );
chomp $HOSTID;
if ( $HOSTID eq "")
{
print STDERR "You must set MY_HOSTID in $popcon_conf!\n";
exit 1;
}
if ( $HOSTID eq "d41d8cd98f00b204e9800998ecf8427e")
{
print STDERR "Warning: MY_HOSTID is the md5sum of the empty file!\n";
print STDERR "Please change it to the md5sum of a random file in
$popcon_conf!\n";
}
if ( $HOSTID !~ /^([a-f0-9]{32})$/)
{
print STDERR "Error: MY_HOSTID does not match ^([a-f0-9]{32})\$\n";
print STDERR "Please edit $popcon_conf to use a valid md5sum value\n";
exit 1;
}
# Architecture.
my $debarch = `dpkg --print-architecture`;
chomp $debarch;
# Popcon release
my $popconver=`dpkg-query --showformat='\${version}' --show popularity-contest`;
# Initialise time computations
my $now = time;
my $daylen = 24 * 60 * 60;
my $monthlen = $daylen * 30;
my $lastmonth = $now - $monthlen;
my %popcon=();
# List all mapped files
my %mapped;
if (opendir(PROC, "/proc"))
{
my @procfiles = readdir(PROC);
closedir(PROC);
foreach (@procfiles)
{
-d "/proc/$_" or next;
m{^[0-9]+$} or next;
open MAPS, "/proc/$_/maps" or next;
while ()
{
m{(/.*)} or next;
$mapped{$1} = 1;
}
close MAPS;
}
}
#process the file list of a package
sub proc_pkg
{
my ($pkg,@list)=@_;
$popcon{$pkg}=[0,0,$pkg,""];
my $bestatime = undef;
for (@list)
{
my($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
$atime,$mtime,$ctime,$blksize,$blocks)
= stat;
if (defined $mapped{$_}) {
# It's currently being accessed by a process
$atime = time();
}
print STDERR if (!defined($atime));
if (!defined($bestatime) || $atime >= $bestatime)
{
$bestatime=$atime;
if ($atime < $lastmonth)
{
# Not accessed since more than 30 days.
$popcon{$pkg}=[$atime,$ctime,$pkg,$_,""];
}
elsif ($ctime > $lastmonth && $atime-$ctime < $daylen)
{
# Installed/upgraded less than a month ago and not used after
# install/upgrade day.
$popcon{$pkg}=[$atime,$ctime,$pkg,$_,""];
}
else
{
# Else w
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Wed, Apr 20, 2011 at 04:10:58PM -0500, Jonathan Nieder wrote: > Hi, > > Bill Allombert wrote: > > > This is not possible: forking dpkg for all installed packages would be way > > to slow and > > resource intensive. We need a better option. > > Bonus points if this interface has an option to point to the file on > disk rather than asking the caller to take care of tracking down > diversions. > > Of course alternative methods might be possible; I ask the above > because I am worried about the memory usage from > "dpkg-query -L $(list-all-packages)". Another issue with 'dpkg-query -L $(list-all-packages)' is that it is not portable to system with a command-line length limit. I suppose popcon will have to process packages by chunk of 100, say. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110421205411.GK13243@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Wed, Apr 20, 2011 at 10:51:57PM +0200, Raphael Hertzog wrote: > On Wed, 20 Apr 2011, Bill Allombert wrote: > > On Wed, Apr 20, 2011 at 09:11:59PM +0200, Raphael Hertzog wrote: > > > On Wed, 20 Apr 2011, Bill Allombert wrote: > > > > On my system with 1200 packages (far below the average popcon > > > > submitter), > > > > traditional popcon take 2s. Once patched with the attached patch to > > > > use dpkg -L, > > > > it take 30s. Slowing down 15 times popcon is not acceptable. > > > > > > You can invoke "dpkg -L" less often by giving multiple packages as > > > parameters. Each set of files will be separated by an empty line. > > > > Good, is that behaviour documented somewhere ? > > man dpkg-query shows that multiple parameters are allowed, it does not > explain that an empty line is the separator though. Well, surely we cannot rely on such undocumented behaviour. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420210851.GE13243@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Wed, Apr 20, 2011 at 09:11:59PM +0200, Raphael Hertzog wrote: > On Wed, 20 Apr 2011, Bill Allombert wrote: > > On my system with 1200 packages (far below the average popcon submitter), > > traditional popcon take 2s. Once patched with the attached patch to use > > dpkg -L, > > it take 30s. Slowing down 15 times popcon is not acceptable. > > You can invoke "dpkg -L" less often by giving multiple packages as > parameters. Each set of files will be separated by an empty line. Good, is that behaviour documented somewhere ? > This will greatly improve the performance. Great, send me a patch and I will benchmark it. > (BTW, popcon is mainly run from cron so interactive performance is not so > critical.) The issue is not interactive performances but waste of system resource. Users will complain. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420192928.GC13243@yellowpig
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Tue, Apr 12, 2011 at 11:06:26PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Tue, 12 Apr 2011, Bill Allombert wrote:
> > > We deliberately skip .list as we don't guarantee that we're always going
> > > to use .list and there's no guaranty that the format of the file won't be
> > > extended to store more information. You should not read those files
> > > directly.
> >
> > Hello Raphael,
> > I have a hard time identifying what you mean by 'we' and 'you' in the above
> > sentences.
>
> we = the dpkg developers
> you = popcon / the popcon maintainer who controls the code in popcon
>
> > I do not read these file. This is what the script popularity-contest do and
> > have
> > done since well before I was the maintainer of popcon or you the maintainer
> > of dpkg.
>
> This doesn't make it any less wrong.
But that means I did not do anything wrong, and also that maybe it was not
wrong by the standard of the dpkg maintainers of the time.
And saying that it is wrong does not provide any help.
On my system with 1200 packages (far below the average popcon submitter),
traditional popcon take 2s. Once patched with the attached patch to use dpkg
-L,
it take 30s. Slowing down 15 times popcon is not acceptable.
Cheers,
--
Bill.
Imagine a large red swirl here.
Index: popularity-contest
===
--- popularity-contest (révision 641)
+++ popularity-contest (copie de travail)
@@ -99,7 +99,7 @@
/^.*installed *(.+)$/ or next;
my $pkg=$1;
$popcon{$pkg}=[0,0,$pkg,""];
- open FILES, "$dpkg_db/$pkg.list" or
+ open FILES, "-|", "dpkg -L $pkg" or
do { print STDERR "popcon: file $dpkg_db/$pkg.list is missing\n"; next; };
my $bestatime = undef;
while ()
Re: Bug#622322: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso
On Tue, Apr 12, 2011 at 12:46:59PM +0200, Raphael Hertzog wrote: > Hi Bill, > > On Tue, 12 Apr 2011, Bill Allombert wrote: > > > I get errors from cron because of popcon: > > > /etc/cron.daily/popularity-contest: > > > popcon: file /var/lib/dpkg/info/liblouis2.list is missing > > > > > > That file doesn't exist, it's really > > > /var/lib/dpkg/info/liblouis2:i386.list > > > due to the multiarch-enabled dpkg that I'm running. > > > > > > You should not access those files, the proper interface is dpkg-query -L > > > . > > > > Hello Raphaël, > > > > This is not possible: forking dpkg for all installed packages would be way > > to slow and > > resource intensive. We need a better option. > > There's no better alternative. You can use dpkg-query --control-path to > get the path of other non-internal control files there: > $ dpkg-query --control-path liblouis2 > /var/lib/dpkg/info/liblouis2:i386.md5sums > /var/lib/dpkg/info/liblouis2:i386.postrm > /var/lib/dpkg/info/liblouis2:i386.shlibs > /var/lib/dpkg/info/liblouis2:i386.postinst > > We deliberately skip .list as we don't guarantee that we're always going > to use .list and there's no guaranty that the format of the file won't be > extended to store more information. You should not read those files > directly. Hello Raphael, I have a hard time identifying what you mean by 'we' and 'you' in the above sentences. I do not read these file. This is what the script popularity-contest do and have done since well before I was the maintainer of popcon or you the maintainer of dpkg. There is a single project, Debian, and Debian developers need to figure out a way to get popularity-contest and dpkg to work together nicely, and set up a transition period to allow partial upgrades. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110412123245.GL6352@yellowpig
Re: Names of Fields in Control Files
On Sun, Sep 26, 2010 at 01:35:00AM -0700, Russ Allbery wrote: > Raphael Hertzog writes: > > On Sat, 25 Sep 2010, Jonathan Yu wrote: > > >> 22:02:40 < rra> jawnsy: I don't think we say that explicitly, but RFC > >> 5322 requires it and I can't imagine ever not enforcing that. > >> Although you should check with the dpkg maintainers to be sure. > >> > >> Could we/should we make the Debian Policy more restrictive, and > >> specify explicitly that field names must only be ASCII-encoded? > > [...] > >> Your comments and feedback on this would be much appreciated. > > > I think this discussion is theoretical and useless. I hope nobody will > > suggest a field name containing non-ascii characters... > > I suspect there might be a communication problem that made this come > across harsher than it was intended. But I'll mention that one of the > things that's sometimes frustrating about trying to nail down the > specification and standards around Debian's package format is that aspects > of standardization that would be considered completely routine in, say, > IETF work are considered theoretical and useless. > > If we were standardizing things in any other context, one of the very > first things we'd do is write an ABNF grammar for Debian control fields, > which would immediately and unambiguously state the allowed characters for > each component. Ideally, there should be a proper dpkg interface documentation, and the policy document would only need to specify the subset that is mandated by policy. The current situation when the policy team is in charge of maintaining the dpkg interface documentation is awkward, especially since policy does not maintain the dpkg interface. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929150556.gb10...@yellowpig
Re: Bug#594167: menu update regression, does not recognize entries
On Tue, Aug 24, 2010 at 05:37:49PM +0900, Norbert Preining wrote:
> Package: menu
> Version: 2.1.43
> Severity: normal
>
> Since some time the menu trigger produces more and more warnings of the
> type:
> warning, in file '/var/lib/dpkg/updates/' near line 5 package
> 'python-cupshelpers':
>missing description
>
> warning, in file '/var/lib/dpkg/updates/' near line 5 package
> 'python-cupshelpers':
>missing maintainer
>
> and so on.
>
> Interestingly these packages do NOT ship any menu file ... so I have no
> idea where this is coming from, but it looks quite wrong.
>
> Esp. since it happened with one of my packages, too (afair) and I didn't
> change anything in the menu file since ages.
>
> Can the maintainers please enlighten me, thanks.
Assuming this is indeed caused by update-menus, then I would assume that the
warning is output by the call to dpkg-query:
dpkg-query --show --showformat="\${status} \${provides} \${package}\n"
Maybe there is a bad interaction with some other triggers that cause dpkg-query
to report a warning.
I CCed the dpkg maintainers.
Cheers,
--
Bill.
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831134931.gb2...@yellowpig
Re: Bug#504880: Disambiguate "installed" for packages
On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote: > Jonathan Nieder writes: > > Russ Allbery wrote: > > >> I think we should hopefully be close to a final wording now. > > > Indeed! All I have left are copy-edits (patch below). > > Thanks! Applied to my copy. > > >> @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent > >> Conflicts: mail-transport-agent > >> Replaces: mail-transport-agent > >> > >> - ensuring that only one MTA can be installed at any one > >> + ensuring that only one MTA can be unpacked at any one > >>time. See for more information about this > >>example. > >> > > > Aside: is this advice right? Maybe we should be encouraging > > > Provides: mail-transport-agent > > Breaks: mail-transport-agent > > Replaces: mail-transport-agent > > > instead. > > Policy 11.6 requires that any package providing mail-transport-agent > install /usr/sbin/sendmail and provide a program called newaliases, and > hence they really do need Conflicts: > > /etc/aliases is the source file for the system mail aliases (e.g., > postmaster, usenet, etc.), it is the one which the sysadmin and > postinst scripts may edit. After /etc/aliases is edited the program or > human editing it must call newaliases. All MTA packages must come with > a newaliases program, even if it does nothing, but older MTA packages > did not do this so programs should not fail if newaliases cannot be > found. Note that because of this, all MTA packages must have Provides, > Conflicts and Replaces: mail-transport-agent control fields. > > The problem with using alternatives here is that the sendmail and > newaliases programs have to match whatever MTA is actually being used, > since bad things could happen (like losing data) if the alternative points > to one MTA but a different MTA is actually running. Alternatives don't > really provide a good way of making those things line up, so what we've > historically done is make all the mail-transport-agent providers just ship > those binaries in those paths and conflict with each other. That prevents > installing more than one MTA at the same time, which could occasionally be > useful, but ensures that everything installed is consistent and works > together. Another issue is that only one MTA can be listening on port 25 at any time, and Debian does not provide a way to prevent two packages to be configured to listen on the same port. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727131222.gq15...@yellowpig
Re: dpkg GIT repos does not build [patch]
On Tue, May 25, 2010 at 01:36:41AM +0200, Raphael Hertzog wrote: > Hi, > > On Mon, 24 May 2010, Bill Allombert wrote: > > Dear Dpkg developers, > > > > There is a small typo in dpkg GIT repository that prevent it to build. > > Please see the attached patch. > > Thanks applied. I did not notice it because here dpkg gets built with > HAVE_MMAP unset. Were you building it in some special environment? I doubt you would call sid special. Maybe this is because I reran autoreconf before compiling or because I do not use the same version of autoconf/automake as you. In any case, we certainly have mmap support, so it seems like a bug if it was not detected on your system. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525173629.gd21...@yellowpig
dpkg GIT repos does not build [patch]
Dear Dpkg developers,
There is a small typo in dpkg GIT repository that prevent it to build.
Please see the attached patch.
Cheers,
--
Bill.
Imagine a large red swirl here.
diff --git a/lib/dpkg/parse.c b/lib/dpkg/parse.c
index 325e9a1..c439a7f 100644
--- a/lib/dpkg/parse.c
+++ b/lib/dpkg/parse.c
@@ -387,7 +387,7 @@ int parsedb(const char *filename, enum parsedbflags flags,
}
if (data != NULL) {
#ifdef HAVE_MMAP
-munmap(data, stat.st_size);
+munmap(data, st.st_size);
#else
free(data);
#endif
dpkg git does not build due to broken l10n
Dear Dpkg developers and Christian, dpkg git repository does not build due to a problem with one of the translations: debuild ... po4a --no-backups --variable srcdir=../../man \ ../../man/po/po4a.cfg ../../man/dpkg-shlibdeps.1:238: (po4a::man) Unbalanced '<' and '>' in font modifier. Faulty message: IB< enth�lt eine nicht\-aufl�sbare Referenz auf Symbol \fISym\fP\fB: wahrscheinlich eine Erweiterung\fP. make[3]: *** [man.stamp] Error 255 Cheers, Bill -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#528892: please add info-dir-section to your info files
On Sun, May 17, 2009 at 04:50:32PM +0200, Raphael Hertzog wrote: > On Sun, 17 May 2009, Bill Allombert wrote: > > > So there's several options that come to mind for that: > > > > > > * We don't care, and expect users might miss docs on the dir file in > > > some cases or need to upgrade dpkg or any of the info-readers. > > > * Make info providing packages depend on install-info. > > > * Make info providing packages Break old dpkgs. > > > * Not remove calls to install-info from packages until squeeze+1 > > > (and make install-info wrappers not warn in some conditions). > > > > > > Probably the sanest and safest is the last one, but slowest and with > > > less immediate benefits. OTOH not registering some docs on the dir > > > file is not that grave, as they will get readded whe upgrading. > > > So I'd go for the "we don't care", but would not mind being more > > > conservative. > > > > Since all packages that use install-info need to be changed, options 2) > > seems doable, and since install-info used to be provided by dpkg it even > > makes sense. I do not have experience with the behaviour of Break during > > upgrade (with aprt or aptitude) to comment on 3) > > And then people would file bugs to demote it to Recommends/Suggests > because it's not necessary for the application to work. These will be invalid bugs: install-info currently part of a package "Essential: yes" so it is not a regression. Such dependency can be removed in squeeze+1. Arguably, this is a bug to remove install-info from the base system without prior notice to the user. > The best solution is to depend on the version of dpkg that breaks the > non-updated info browsers. That way people are forced to upgrade dpkg and > the info browsers at the same time (and install-info is installed). > > On the downside, it will make backports painful (unless those dependencies > are manually removed in the backport). Let's make upgrade work correctly before thinking about backports. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#528892: please add info-dir-section to your info files
On Sun, May 17, 2009 at 05:30:39AM +0200, Guillem Jover wrote: > On Sun, 2009-05-17 at 04:26:02 +0200, Guillem Jover wrote: > > On Sat, 2009-05-16 at 22:24:43 +0200, Bill Allombert wrote: > > > On Sat, May 16, 2009 at 09:54:35PM +0200, Norbert Preining wrote: > > > > On Sat, 16 May 2009, Bill Allombert wrote: > > > > > Does Lenny includes this trigger ? > > > > > > > > > Did you consider what will when a partial lenny to squeeze update is > > > > > made ? > > > > Yes, most of the plan has been drafted with the idea of inflicting > > minimal disruption. > > > > > > Yes. If the new texinfo/install-info is installed it will work on the > > > > triggers. Packages that are old will call install-info which is a > > > > wrapper > > > > and will do nothing. If the old install-info/texinfo is installed then > > > > the normal install-info procedure is called. > > > > > > What happens if a new package is installed but not the new install-info ? > > > > The info files are not usually ‘readable’ w/o an info-reader. The new > > info-reader Providing packages will Depend on the install-info package, > > so they will get a generated dir when installed. And the first dpkg > > version to stop shipping the real install-info will Break all old > > info-readers versions not Depending on the install-info package. Does > > this resolve your concerns? > > Actually, no, I guess it does not. In case the user has no upgraded > dpkg nor any of the info-readers, the user could upgrade a info > providing package and that would not call install-info anymore (in > this particular case things would probably just work, as the info dir > section is already on the dir file, but not for new info files, or > renamed files). Yes this was my point. > So there's several options that come to mind for that: > > * We don't care, and expect users might miss docs on the dir file in > some cases or need to upgrade dpkg or any of the info-readers. > * Make info providing packages depend on install-info. > * Make info providing packages Break old dpkgs. > * Not remove calls to install-info from packages until squeeze+1 > (and make install-info wrappers not warn in some conditions). > > Probably the sanest and safest is the last one, but slowest and with > less immediate benefits. OTOH not registering some docs on the dir > file is not that grave, as they will get readded whe upgrading. > So I'd go for the "we don't care", but would not mind being more > conservative. Since all packages that use install-info need to be changed, options 2) seems doable, and since install-info used to be provided by dpkg it even makes sense. I do not have experience with the behaviour of Break during upgrade (with aprt or aptitude) to comment on 3) The point is that we are introducing a potential breakage during upgrade. In this instance it is rather trivial, but when triggers are used for more critical things like boot-loaders, this should be documented and prevented. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#528892: please add info-dir-section to your info files
On Sat, May 16, 2009 at 09:54:35PM +0200, Norbert Preining wrote: > Hi Bill, > > On Sat, 16 May 2009, Bill Allombert wrote: > > Does Lenny includes this trigger ? > > No. > > > Did you consider what will when a partial lenny to squeeze update is made ? > > Yes. If the new texinfo/install-info is installed it will work on the > triggers. Packages that are old will call install-info which is a wrapper > and will do nothing. If the old install-info/texinfo is installed then > the normal install-info procedure is called. What happens if a new package is installed but not the new install-info ? > No, I checked the source code just now, and it does not produce any > dir entries. I will file a bug against that, but that is somehow > bad. Thanks for that. > There is an option to postprocess the .texi file and simply sed-in the > direntry, but that is not the optimal solution, definitely. Agreed! Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dpkg git repo does not build
Hello, I am trying to build dpkg from git source but that fails. 1) origins/Makefile should be removed from configure.ac 2) ChangeLog is not generated, and dh_installchangelogs -a ChangeLog ChangeLog.old fails. 3) Maybe a build-dep on git-core is warranted, due to the use of git log. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#489771: New Build-Options field and build-arch option, please review
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. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: > Russ Allbery <[EMAIL PROTECTED]> writes: > > > Raphael Hertzog <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Build-Options field and build-arch option, please review
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote: > Raphael Hertzog <[EMAIL PROTECTED]> writes: > > > I think we're already on that path for quite some time. If your package > > uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting > > them for you (with dpkg-architecture). > > I most certainly do not rely on dpkg-buildpackage setting anything. I > call dpkg-architecture directly, which is also what's in our best practice > documents. > > DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) > DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) > > I would consider packages that didn't do that and just assumed that those > variables were already set to be buggy. > > > The same is expected with default values of builder/linker flags now > > that dpkg-buildpackage provides reasonable defaults. > > Yeah, that bothered me too. I made a perhaps poor tactical decision to > not fight about it since it seemed that it had a lot of momentum and I > couldn't think of specific problems other than the one that we ran into. > But this is going beyond setting some defaults that are already set in > nearly all of our packages. > > > So yes, I'm somehow building on this model where dpkg-buildpackage can > > simplify the work of packager by providing some distribution-wide > > reasonable defaults. > > > > People have noticed that and already requested that we can call arbitrary > > targets of debian/rules with all the proper initialization done precisely > > for test purpose during packaging work (see #477916). > > I must say, I really do not like this direction. debhelper and cdbs and > similar sytsems are the places to provide this help where people want to > use it, in my opinion. We have a lot of past experience with that and we > have the compatibility level to handle smoothing transitions. (And to > provide a way for people to never transition, I admit, and I see where > that's the problem that you're solving, but I prefer that problem to the > problems introduced by the instability of having the package build > infrastructure change the input to the builds without coordination with > the package.) 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. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Build-Options field and build-arch option, please review
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote: > El 10/07/08 18:02 Raphael Hertzog escribió: > > Hello, > > > > in order to fix #229357 I decided to add a new Build-Options field. > > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. > > And I added support for a build-arch option, that if present, will let > > dpkg-buildpackage call debian/rules build-arch and build-indep. > > > > It's not obvious that this was the right choice when you think of the Maybe it is not obvious, but since noone proposed another working solution in the ten years this issue exists, there is no alternative. > > currently existing build options but once you start thinking of possible > > additions (as requested in #489771), it becomes more evident that it makes > > sense. Even if some build options should really only be used in > > the field while others should only be used in the environment variable, > > the possibility to override the former with the latter is nice. > > I'm not really sure this is right. There are two things that we want to do > here: declare that a package supports something, and asking the package to do > something. This difference is blurred now, and I think it is confusing. > OTOH, it gives the benefit of being able to ignore the package capabilities > via the environment (ie, unset a given option). > I fear it will give rise to abuses such as setting parallel=n in the control > file. I concur. This also create a namespace problem by conflating the 'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace. Since a developer can put virtually anything in DEB_BUILD_OPTIONS (and check for it in debian/rules) even if it is not mentionned in policy, this is a real issue. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages rename and conffiles
On Mon, Dec 11, 2006 at 11:28:34AM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: Packages rename and conffiles"):
> > What position do you think we should take on this issue? If there's no
> > known solution that avoids conffile prompts with both the old and new
> > versions, and given that there's no good systematic way to arrange for one
> > version of dpkg or the other to be installed at the time of upgrade,
> > perhaps it's best to favor the new dpkg?
>
> The ideal solution would be a general arrangement that ensured that
> upgrades from release A to B were always done with the package
> management system from B (backported, presumably).
So are you planning to provide such a backport ? Without it we will have
to investigate others solutions.
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages rename and conffiles
On Sun, Nov 26, 2006 at 09:03:06PM +0100, Bill Allombert wrote: > So we have to take a position on this issue. I can provide the list > of affected packages. There is at least openssh, vim and openoffice. The following packages trigger useless confile handling, but there are others: tiger (3.2.1-34)file `/etc/tiger/tigerrc' cyphesis-cpp (0.5.8-1+b1) file `/etc/cyphesis/cyphesis.vconf' localepurge (0.5.7) ... file `/etc/locale.nopurge' moinmoin-common (1.5.3-1.1) file `/etc/moin/mywiki.py' wdm (1.28-2.2) file `/etc/X11/wdm/wdm-config' gnump3d (2.9.9.9-2) file `/etc/gnump3d/gnump3d.conf' libnet-perl (1.19-3)file `/etc/libnet.cfg' netmrg (0.18.2-14) file `/etc/netmrg/netmrg.xml' Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages rename and conffiles
Hello Release and DPKG teams, A fair number of conffiles have changed of packages. The issue: dpkg handling of this situation has changed between Sarge and Etch, see bug#346282. However, unless we ask the user to upgrade dpkg before anything else, there is a fair chance half of the system is upgraded with Sarge dpkg and the other half with Etch dpkg. Unfortunately, I know how to avoid spurious dpkg conffiles handling with either of them separately, but not with both of them at once. So we have to take a position on this issue. I can provide the list of affected packages. There is at least openssh, vim and openoffice. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. PS: in 3 years, I never get a single answer from the debian-dpkg mailing list, so if you meet dpkg maintainers on IRC, please raise the issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: dpkg-buildpackage: support for Build-Options: build-arch
Package: dpkg
Version: 1.10.18
Severity: wishlist
Tags: patch
Hello dpkg developers,
As discussed in #218893,
here a patch that implement support in dpkg-buildpackage
for `Build-Options: build-arch' in debian/control as
defined in the matching patch to debian-policy.
When a package specify the Build-Options 'build-arch', dpkg-buildpackage
will assume that build-arch and build-indep are implemented in
debian/rules and act accordingly.
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Imagine a large red swirl here.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux seventeen 2.4.24 #1 Mon Jan 5 19:10:08 CET 2004 i686
Locale: LANG=français, LC_CTYPE=français
Versions of packages dpkg depends on:
ii dselect 1.10.18 a user tool to manage Debian packa
ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an
-- no debconf information
--- dpkg-1.10.18/scripts/controllib.pl 2003-09-19 19:29:09.0 +0200
+++ dpkg-1.10.18.new/scripts/controllib.pl 2003-11-17 18:03:25.0
+0100
@@ -15,7 +15,8 @@
grep($capit{lc $_}=$_, qw(Pre-Depends Standards-Version Installed-Size
Build-Depends Build-Depends-Indep
- Build-Conflicts Build-Conflicts-Indep));
+ Build-Conflicts Build-Conflicts-Indep
+ Build-Options));
@pkg_dep_fields = qw(Replaces Provides Depends Pre-Depends Recommends Suggests
Conflicts Enhances);
@src_dep_fields = qw(Build-Depends Build-Depends-Indep
@@ -300,6 +301,15 @@
$index || &syntax("empty file");
return $index;
}
+sub parsebuildoption
+{
+ $controlfile=$_[0];
+ &parsecontrolfile;
+ my $opts=$fi{'C Build-Options'};
+ return if (!defined($opts));
+ $opts=~ s/ //;
+ return split(',',$opts);
+}
sub unknown {
&warn("unknown information field " . $fi{"o:$_"} . " in input data in
$_[0]");
@@ -328,4 +338,8 @@
}
}
+if ($0 =~ /controllib\.pl$/ )
+{
+ eval join(' ',@ARGV);
+}
1;
--- dpkg-1.10.18/scripts/dpkg-buildpackage.sh 2003-09-20 02:57:39.0
+0200
+++ dpkg-1.10.18.new/scripts/dpkg-buildpackage.sh 2003-11-17
18:18:17.0 +0100
@@ -2,7 +2,8 @@
set -e
-version="1.10.10"; # This line modified by Makefile
+version="1.10.18"; # This line modified by Makefile
+dpkglibdir=".";# This line modified by Makefile
progname="`basename \"$0\"`"
usageversion () {
@@ -61,6 +62,7 @@
checkbuilddep=true
checkbuilddep_args=''
binarytarget=binary
+buildtarget=build
sourcestyle=''
version=''
since=''
@@ -156,6 +158,16 @@
sversion=`echo "$version" | perl -pe 's/^\d+://'`
pv="${package}_${sversion}"
pva="${package}_${sversion}_${arch}"
+buildoptions=(`perl $dpkglibdir/controllib.pl \
+'print parsebuildoption("debian/control")'`)
+
+if [ $binarytarget = binary-arch ] ; then
+ for opt in $buildoptions; do
+if [ $opt = build-arch ] ; then
+ buildtarget='build-arch'
+fi
+ done
+fi
signfile () {
if test "$signinterface" = "gpg" ; then
@@ -196,7 +208,7 @@
cd ..; withecho dpkg-source $passopts $diffignore $tarignore -b
"$dirn"; cd "$dirn"
fi
if [ x$sourceonly = x ]; then
- withecho debian/rules build
+ withecho debian/rules $buildtarget
withecho $rootcommand debian/rules $binarytarget
fi
if [ "$usepause" = "true" ] && \
--- dpkg-1.10.18/scripts/Makefile.in2002-05-20 06:40:27.0 +0200
+++ dpkg-1.10.18.new/scripts/Makefile.in2003-11-16 21:01:09.0
+0100
@@ -108,3 +108,5 @@
%: %.sh
$(SED) -e "s:version=\"[^\"]*\":version=\"$(VERSION)\":" \
< $< > $@
+ $(SED) -e "s:dpkglibdir=\"[^\"]*\":dpkglibdir=\"$(dpkglibdir)\":" \
+ < $< > $@
signature.asc
Description: Digital signature
Bug#148932: dpkg-dev: dpkg-buildpackage -B should try build-arch target
On Mon, Apr 07, 2003 at 08:59:25PM +0200, Josip Rodin wrote: > On Mon, Apr 07, 2003 at 08:03:18PM +0200, Bill Allombert wrote: > > > > Firstly, a test to see if something is a makefile can be as simple as > > > > reading the first line of the file -- does it contain #!/usr/bin/make > > > > -f (as policy dictates in 5.2) > > > > > > Wrong. Debian policy is just that, Debian policy. dpkg does not demand > > > that debian/rules is a makefile and will not rely on make specific > > > behaviour. > > > > So make this patch Debian specific. > > Even if it's only a Debian Policy thing, it's still wrong from dpkg's point > of view, was not intended to be done that way, and Debian doesn't need dpkg > to enforce this wrong policy. What is needed is a way to tell dpkg-buildpackage which interface we support. The current debian/rules specification does not describe such interface, so we need to design it. AFAIU, the current debian/rules interface supposed by dpkg-buildpackage is 1) must be executable 2) must support the following argument: clean build binary-arch binary-indep binary 3) must act suitably when called with this argument, 'suitably' not defined for brievity. Unfortunately, no provision has been made for extension. Suppose, in the mathematical sense of the term, we add a new argument: support with the specification: when debian/rules is called with argument support, it must output the list of supported argument. Once all debian/rules support this, we can easily add new argument like build-arch/build-indep. Unfortunately, before that point we have a problem: we cannot discriminate which debian/rules support this and which do not. Unless we relie on assumption, like debian/rules is a makefile, or 'debian/rules support' do nothing and exit with an error if support is not implemented. For the purpose of Debian development, we need backward compatibility, so we are stuck with making assumption. On the other hand, I do not the point of view of dpkg developers as upstream maintainers: do they want such backward compatibility. If not the backward compatibility stuff can be in a debian specific patch. Cheers, -- Bill. <[EMAIL PROTECTED]>
Bug#148932: dpkg-dev: dpkg-buildpackage -B should try build-arch target
Package: dpkg-dev Version: 1.10.9 Followup-For: Bug #148932 Wichert wrote: > Previously Duncan Findlay wrote: > > Firstly, a test to see if something is a makefile can be as simple as > > reading the first line of the file -- does it contain #!/usr/bin/make > > -f (as policy dictates in 5.2) > > Wrong. Debian policy is just that, Debian policy. dpkg does not demand > that debian/rules is a makefile and will not rely on make specific > behaviour. So make this patch Debian specific. You are both the upstream dpkg maintainer and the Debian maintainer. The upstream maintainer has a valid reason not to include this patch but has the Debian maintainer? You can add the patch in the debian directory and apply it at build-time. Cheers, -- Bill. <[EMAIL PROTECTED]> -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux seventeen 2.4.20 #1 Wed Mar 5 16:16:52 CET 2003 i686 Locale: LANG=french, LC_CTYPE=french Versions of packages dpkg-dev depends on: ii binutils2.13.90.0.18-1.3 The GNU assembler, linker and bina ii cpio2.5-1GNU cpio -- a program to manage ar ii make3.80-1 The GNU version of the "make" util ii patch 2.5.4-11 Apply a diff file to an original ii perl [perl5]5.8.0-17 Larry Wall's Practical Extraction ii perl-modules5.8.0-17 Core Perl modules. -- no debconf information
Re: on merulo: dpkg-deb a b -->SEGV
On Mon, Oct 14, 2002 at 11:07:33AM -0600, Bdale Garbee wrote:
> [EMAIL PROTECTED] (Bill Allombert) writes:
>
> > merulo% dpkg-deb a b
> > zsh: segmentation fault dpkg-deb a b
>
> Filed a bug against dpkg yet? The latest build log on buildd.debian.org shows
> a number of warnings about pointer casts that are probably worth
> investigating.
The warning do not seem to be related.
The SEGV occurs just after a longjump() from
void badusage(const char *fmt, ...) {
...
longjmp(*econtext->jbufp,1);
}
to
void standard_startup(jmp_buf *ejbuf, int argc, const char *const **argv, const
char *prog, int loadcfg, const struct cmdinfo cmdinfos[]) {
...
if (setjmp(*ejbuf)) { /* expect warning about possible clobbering of argv */
error_unwind(ehflag_bombout); exit(2);
}
the SEGV occurs at the start of error_unwind.
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Q: Does Debian has LSB support ?
A: Yes! But we also have MSB support.
Bug#111562: #111562: dpkg-checkbuilddeps: incorrect parsing of empty Build-Depends
reopen 115562 thanks, On Fri, May 24, 2002 at 09:00:58PM -0500, Adam Heath wrote: > This was fixed in dpkg 1.9.8, which was uploaded on June 2, 2001. > > == > [EMAIL PROTECTED]:~/debian/mine/dpkg/HEAD/cvs$ dpkg-checkbuilddeps ; echo $? > 0 > [EMAIL PROTECTED]:~/debian/mine/dpkg/HEAD/cvs$ grep -i build-depends > debian/control > Build-Depends: debiandoc-sgml, sgmltools-lite, libncurses-dev, gettext (>= > 0.10.36), zlib1g-dev > Build-Depends-Indep: > == Original bug report read: = 1.1.17),tetex-bin,tetex-extra,libreadline4-dev,xlib debian/control < Standards-Version: 3.5.5.0 EOF dpkg-checkbuilddeps and the output is dpkg-checkbuilddeps: Unmet build dependencies: Section: math Cheers, -- Bill. <[EMAIL PROTECTED]> FHS 5.3: As of the date of this release of the standard, system crash were not supported under Linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#137351: dpkg -l cut versions and make false bug report info
On Sat, Mar 09, 2002 at 10:00:38PM +0100, Wichert Akkerman wrote: > Previously Bill Allombert wrote: > > If you really want dpkg -l to cut important fields like package name or > > version number, please use a ">" terminator to make it clear it is not > > finished, like in > > Three options: > 1. use a wider tty > 2. set the COLUMN environment to make dpkg thing your tty is wider > 3. wait for dpkg 1.10 to be release which has a dpkg-query command with >customizable output formats So please explain that to every people that report bugs with wrong packages version numbers, using reportbug or manually. Regards, -- Bill. <[EMAIL PROTECTED]> FHS 5.3: As of the date of this release of the standard, system crash were not supported under Linux.
Bug#137351: dpkg -l cut versions and make false bug report info
Package: dpkg Version: 1.9.19 Severity: normal Hello dpkg developers, The way dpkg -l cut columns may generated wrong versions in bug reports: An example yellowpig% COLUMNS=80 dpkg -l libopenal0 | grep libopenal0 ii libopenal0 0.2001061600-2 OpenAL is a portable library for 3D spatiali So I have version 0.2001061600-2 ? Wrong: yellowpig% COLUMNS=130 dpkg -l libopenal0 | grep libopenal0 ii libopenal0 0.2001061600-2.1 OpenAL is a portable library for 3D spatialized audio. In fact I have version 0.2001061600-2.1 ! There is a similar problem in potato with proftpd, it loks like version 1.2.0pre10-2.0 yellowpig% COLUMNS=80 dpkg -l proftpd | grep proftpd ii proftpd1.2.0pre10-2.0 Versatile, virtual-hosting FTP daemon But in fact I have yellowpig% COLUMNS=130 dpkg -l proftpd | grep proftpd ii proftpd1.2.0pre10-2.0potato1 Versatile, virtual-hosting FTP daemon If you really want dpkg -l to cut important fields like package name or version number, please use a ">" terminator to make it clear it is not finished, like in i proftpd1.2.0pre10-2.0>Versatile, virtual-hosting FTP daemon Kind regards, -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux yellowpig 2.2.19 #1 Tue Apr 24 20:02:21 CEST 2001 i686 Locale: LANG=french, LC_CTYPE=french Versions of packages dpkg depends on: ii libc62.2.5-3 GNU C Library: Shared libraries an ii libncurses5 5.2.20020112a-3 Shared libraries for terminal hand ii libstdc++2.10-glibc2.2 1:2.95.4-1 The GNU stdc++ library -- Bill. <[EMAIL PROTECTED]> FHS 5.3: As of the date of this release of the standard, system crash were not supported under Linux.
