Hi,
On Tue, 01 Jun 2010, Russ Allbery wrote:
If this is still a supported feature, could you take over this
documentation and add it to dpkg-parsechangelog or a new deb-changelog
man page? If it is not a supported feature, please let me know and I'll
just delete the information from Policy.
On Tue, 01 Jun 2010, Ryan Niebur wrote:
Preparing to replace midori 0.2.2-1 (using midori_0.2.6-1_i386.deb) ...
Moving obsolete conffile /etc/midori/extensions/libadblock.so/config out of
the way...
Unpacking replacement midori ...
dpkg: warning: unable to delete old directory
Hi,
On Sat, 29 May 2010, Michael Tautschnig wrote:
(Severity might even be upgraded as this can cause packages to FTBFS.) I just
added arch=!armel to some of the symbols of libdiagnostics0 and found
dpkg-gensymbols to fail in a strange way:
# dpkg-gensymbols -plibdiagnostics0 -d -c4
Using
On Mon, 14 Jun 2010, Christian Kastner wrote:
According to dpkg-maintscript-helper(1), the current implementation of
rm_conffile preserves locally modified conffiles by renaming them to
conffile.dpkg-bak.
This does not work in certain cases where the (modified) conffile should
continue to
Hi,
On Tue, 15 Jun 2010, Loïc Minier wrote:
- how are diverts handled, that is what if a package tries to
dpkg-divert an ultimately excluded file, will that be excluded and
skipped?
No time to check right now but I guess it should not be a problem, you can
dpkg-divert a file that is
forcemerge 560070 586691
thanks
Hi,
On Mon, 21 Jun 2010, Ian Jackson wrote:
However, there is no way to get a complete list of these flags
variables, future versions of dpkg-dev may set more of them, and all
of this is not at all under the control of the package maintainer.
We have
On Tue, 22 Jun 2010, Guillem Jover wrote:
Unfortunately I don't think that would be acceptable for a stable
update, as some maintainers started relying on dpkg-buildpackage's
behaviour of setting those flags and stopped setting them in their
rules files. So there's a chance of regressions. If
On Mon, 05 Jul 2010, Christoph Pleger wrote:
I want to build to build a debian package for my amd64-architecture. The
resulting package contains 32-bit libraries and executables which are part
of the orig.tar.gz from upstream.
These libraries and executables need 32-bit libraries which are
On Tue, 06 Jul 2010, Christoph Pleger wrote:
What does dpkg -S /emul/ia32-linux/usr/lib/libidn.so.11 return?
It returns not found.
So that's your problem. It can't find the packages associated to the
library that the binary will use and thus can't find the associated shlibs
file.
How is the
On Tue, 06 Jul 2010, Christoph Pleger wrote:
Probably, the problem occurs because the library is located in /usr/lib32,
but /usr/lib32 is a symbolic link to /emul/ia32-linux/usr/lib.
In my opinion, dpkg-shlibdeps/dpkg should handle symbolic links correctly.
It does do its best already. If
Hi,
On Tue, 06 Jul 2010, Raphael Hertzog wrote:
On Tue, 06 Jul 2010, Christoph Pleger wrote:
Probably, the problem occurs because the library is located in /usr/lib32,
but /usr/lib32 is a symbolic link to /emul/ia32-linux/usr/lib.
In my opinion, dpkg-shlibdeps/dpkg should handle
On Wed, 07 Jul 2010, Christoph Pleger wrote:
Do you have LD_LIBRARY_PATH set during the build process?
I did not explicitly set LD_LIBRARY_PATH, I just appended a directory to
it by using the -l parameter of dh_shlibdeps.
That's the same... what's this directory and why did you do that?
Hi,
On Wed, 07 Jul 2010, Andreas Beckmann wrote:
Version: 1.15.7.2
I attach a patch that stops dpkg-divert --rename doing useless checking
(and emitting useless errors) if the source file of the rename does not
exist.
dpkg-divert has been rewritten in C in the master branch of the git
On Tue, 06 Jul 2010, Andreas Beckmann wrote:
the command
dpkg-source -b foobar-1.0~
fails to create a valid tarball for a native package (did not try
non-native) because the directory name ends with a tilde. If I
uncompress the 45 bytes .tar.gz, I get a file that consists of
10240
On Mon, 26 Jul 2010, Karl Goetz wrote:
this appears to happen if an incorrect number of parameters are passed
too.
Thanks, but I fixed that too when I got the initial report. It will be
fine in the upcoming 1.15.8.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my
Hi,
On Tue, 27 Jul 2010, Matthias Klose wrote:
A C++ library like libstdc++ built for 32bit and 64bit in the same
source can have different symbol names in the 32bit and 64bit
builds, and different symbol names on different architectures. The
current `arch' attribute only allows selection of
On Wed, 28 Jul 2010, Modestas Vainius wrote:
Maybe you want to be able use the same symbol file for both libstdc++6 on
i386
and lib32stdc++6 on amd64 (because in theory their symbol sets should be
identical AFAIU) and that's what is this bug actually about?
AFAIU, that's right. He has a
Hi,
On Wed, 28 Jul 2010, Modestas Vainius wrote:
Why do you believe that? I don't know of many cases where the name of an
ELF binary format got changed... but I haven't studied the question. That
said we have no official mapping between ELF format and Debian
architecture and the mapping
Hi,
On Thu, 29 Jul 2010, Sven Joachim wrote:
with current dpkg I have a strage problem - during install of some
packages i.e. fakeroot or heirloom-mailx, update-alternatives
starts to write very large files in /var/lib/dpkg/alternatives,
only stopping after the disk is filled up.
Hi Guillem,
On Fri, 30 Jul 2010, Guillem Jover wrote:
I'll consider whether to do something about these bug reports for
tomorrow's upload, mostly because this is a regression from the point
of view of the user, that had a working dpkg before the upgrade and
it suddenly stopped working. But
Hi,
On Sat, 31 Jul 2010, Jonathan Nieder wrote:
Philipp Kern wrote:
Your package failed to build from source when scheduled as a binNMU. Is it
possible that it cannot cope with that fact and the + in the testcase
harness
is actually messing things up?
Makes sense to me.
Confirmed,
On Tue, 03 Aug 2010, Simon Richter wrote:
while using the target objdump is a Good Thing(tm), it uncovered another
bug: for dependent libraries, the host's version is passed to the target
objdump.
That's not really accurate, it's passed to objdump -a only to verify if
the binary has the same
tag 591858 + wontfix
thanks
On Thu, 05 Aug 2010, Guido Günther wrote:
Package: dpkg-dev
Version: 1.15.8.1
Severity: wishlist
Hi,
it'd be great if the very useful --unapply-patches option would also do
away with the .pc/ directory to give a clean source tree without any
modifications at
forcemerge 590885 591885
thanks
On Sat, 07 Aug 2010, Christian Marillat wrote:
Because uscan had a bug (it quoted version numbers), and APT has no bug;
it only outputs the records found in the repositories (and the
virtualbox.org version numbers are invalid).
You might want to reopen
Package: dpkg-dev
Version: 1.15.8
Severity: wishlist
As suggested by Ian on -devel (see attachment), it would be nice to have
a way to remove files during unpack of a source package to hide non-free
files from our users without stripping them from the original tarball.
I also prefer this
On Wed, 18 Aug 2010, Russ Allbery wrote:
Yann Dirson ydir...@mygale.org writes:
Richard Braakman writes:
Yesterday I noticed that Debian policy is incorrect on this:
Only packages that are tagged *conflicting* with each other may
specify the same file as `conffile'. A
Hi,
On Fri, 20 Aug 2010, Steffen Moeller wrote:
I moved the debian folder of an otherwise workign package into a separate
directory
and then symlinked to it. This is helpful as a preparation for
svn-buildpackage
with propset mergeWithUpstream 1 debian .
Where was the target directory?
On Fri, 20 Aug 2010, Russ Allbery wrote:
Objections or seconds?
Looks mostly good except:
@@ -8014,6 +7998,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
and which manages the shared configuration files. (The
ttsgml-base/tt package is a good example.)
/p
Hi,
On Wed, 18 Aug 2010, Colin Watson wrote:
A fix for this is to insert:
binmode($fh, :encoding(UTF-8));
... just before the call to $self-parse in
Dpkg::Interface::Storable::load(); this causes Perl to assume character
semantics on the data read from that file, which causes sprintf
On Sat, 21 Aug 2010, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
On Fri, 20 Aug 2010, Russ Allbery wrote:
+p
+ A package that declares the same ttconffile/tt as another,
+ conflicting package may see left-over configuration files from
+ that other
Package: dpkg-dev
Version: 1.15.8.4
Severity: wishlist
It would be nice if the debian.tar.gz tarball of a 3.0 (quilt) source
package could contain symlinks setup in the uptsream files.
A useful case would be for example to provide a non-versioned name
when a supplementary tarball embeds a
Hi,
On Sat, 11 Sep 2010, Lionel Elie Mamane wrote:
$ dpkg-source -x tzdata_2010l-1.dsc apt
Can't locate Dpkg.pm in @INC (@INC contains: /etc/perl
/usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10
severity 596841 wishlist
thanks
On Tue, 14 Sep 2010, Goswin von Brederlow wrote:
So the respective library needs to be added and fetched and everything
build again, a somewhat lengthy process.
You know you can call dpkg-shlibdeps/dh_shlibdeps on the command line without
rebuilding everything?
On Sun, 19 Sep 2010, Steve McIntyre wrote:
CCing -devel and Joey Hess to have some input on this idea. Do you think
it would be useful ? Do you have comments and suggestions ?
I'm uncomfortable with the idea of (even more?) build-time package
settings being hidden away outside of
On Sun, 19 Sep 2010, Christian Perrier wrote:
When documenting the debian/suorce/patch-header file, this manpage
still mentions that never used source format.
Yes, the source format 2.0 is documented in dpkg-source(1). It's also
said:
Format: 2.0
Also known as wigpen. This format is
On Tue, 21 Sep 2010, James Vega wrote:
The problem boils down to Dpkg::Version not handling a version string
with only a revision the same way that dpkg does. The attached patches
add a test for this scenario and make Dpkg::Version behave the same way
dpkg does.
Thanks for the analysis and
On Tue, 28 Sep 2010, André Neves wrote:
dpkg --clear-avail doesn't solve the problem here. Subsequent upgrades will
still display the warning.
It means the offending package might still be installed. Try purging it.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my
Hi,
On Wed, 29 Sep 2010, Michal Suchanek wrote:
I tried to genereate packages file with dpkg-scanpackages but it would
not include the kernel package.
What command line do you use?
Can you put the offending package online so that we can try to reproduce
the problem?
I'm afraid there's
On Wed, 06 Oct 2010, Martin Godisch wrote:
On Wed, Oct 06, 2010 at 11:03:26 +0200, Raphael Hertzog wrote:
When applying patches in dpkg source format 3.0 (quilt) with -p0 in
debian/patches/series, files in top level directory (without /) let
dpkg-source print the following error
Hi,
On Wed, 20 Oct 2010, Modestas Vainius wrote:
On trečiadienis 20 Spalis 2010 22:33:34 Julien Cristau wrote:
On Wed, Oct 20, 2010 at 22:20:31 +0300, Modestas Vainius wrote:
Btw, how will I be able to enable --force-unsafe-io for dpkg when it's
run under apt/aptitude? Maybe environment
Package: dpkg-dev
Version: 1.15.8.5
Severity: wishlist
1/ When looking up the series file, it should also try series files of
parent distributions before falling back to debian/patches/series.
Say if mint is derived from ubuntu, the lack of debian/patches/mint.series
should result in
On Thu, 28 Oct 2010, Raphael Hertzog wrote:
2/ When extracting the source package, quilt should automatically point to
the series files of the current distribution (and not debian/patches/series
unconditionnaly as it currently does). i.e. it should put ubuntu.series in
.pc/.quilt_series
Hi,
On Wed, 20 Oct 2010, Eduard Bloch wrote:
Just create th debian/source/format file with an empty line, and you
get:
Actually an empty file and not an empty line.
dpkg-source: error: invalid Format field `'
Now this message is misleading, because there is NO format field (ask
grep ;-)
On Sat, 13 Nov 2010, Jonathan Nieder wrote:
Hi Matthias,
Matthias Klose wrote:
Currently dpkg-architecture and dpkg-parsechangelogs allow printing
all key/value pairs with one invocation, while dpkg-buildflags just
gives an error message without parameters. Please provide a mode
retitle 603435 dpkg-buildflags without parameters should default to a
reasonable action
severity 603435 wishlist
thanks
On Tue, 16 Nov 2010, Matthias Klose wrote:
thanks for the pointer, I'll use this, but dpkg-buildflags working
without parameters would be nice. Please close the report if you
On Tue, 16 Nov 2010, Matthias Klose wrote:
dpkg-buildflags provides all the logic allowing the user to override the
value generated, the makefile doesn't need to use ?=. And even in a
typical debian/rules, you first get the values from dpkg-buildflags and
then you tweak it if needed.
my
reassign 552688 tech-ctte
retitle 552688 Please decide how Debian should enable hardening build flags
tag 552688 - wontfix
thanks
I think none of the discussions up to now have resulted in a consensus
among all the parties. Most people are in favor of changing the defaults
in GCC, except the gcc
Hello,
On Sun, 21 Nov 2010, Juergen Kosel wrote:
yesterday I have upgraded an old computer from Lenny to Squeeze.
This machine has a long history. Debian Woody was installed on it 2005.
Now dpkg gives the following complaints on packages which were installed long
ago:
Yes, and?
We have
On Sun, 21 Nov 2010, Jonathan Nieder wrote:
Yes, and?
We have added those warnings, it's not to drop them when someone sees
them. :-)
It does sound like a bug to me. Would it make sense to automatically update
the available file somehow on upgrade?
With what information? We can't
reassign 604919 dpkg-dev 1.15.8.6
forcemerge 229357 604919
thanks
(Yay for yet another duplicate on this one...)
On Thu, 25 Nov 2010, Roger Leigh wrote:
In order to allow full use of Build-Depends-Indep, and to allow
autobuilding of arch-indep packages on our buildds, as well as
more
Hi,
On Thu, 25 Nov 2010, Roger Leigh wrote:
I don't see why we can't just mandate it in Policy, and then
enable it unconditionally if the Standards-Version is = that
policy version. The package maintainer is declaring that their
package conforms to that policy version, which requires that
Hi,
adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC
because I'm fed up with this problem. Sorry for the massive crosspost, you
might want to follow up only on -devel and on the bug report.
Some clones/reassign should probably result from this discussion anyway.
On
Hi,
On Fri, 26 Nov 2010, Mathias Behrle wrote:
* Betr.: Re: Bug#605009: serious performance regression with ext4 (Fri, 26
Nov 2010 15:53:27 +0100):
That was ok everywhere except on ext4.
JFTR: I am experiencing those problems as well on XFS.
Can you give us figures to quantify the
On Sat, 27 Nov 2010, Jonathan Nieder wrote:
c) extract(a.dpkg-new);
extract(b.dpkg-new);
extract(c.dpkg-new);
fsync(a.dpkg-new);
fsync(b.dpkg-new);
fsync(c.dpkg-new);
rename(a.dpkg-new, a);
rename(b.dpkg-new, b);
rename(c.dpkg-new, c);
(c)
On Mon, 29 Nov 2010, Jonathan Nieder wrote:
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Probably a silly
, Raphael Hertzog wrote:
2/ d-i should be modified to use --force-unsafe-io if it detects a dpkg
version = 1.15.8.6.
dpkg has become slower due to the usage of fsync() to ensure data
consistency in case of crashes/power failures.
In the context of d-i, a crash means restarting the installation
Hi,
On Tue, 30 Nov 2010, Michael Biebl wrote:
Something interesting I noticed:
I created the ext4 file system on a spare partition and installed a chroot.
After running the test, I exited the chroot, immediately unmounted the
partition
and measured how long it took:
1.15.8.5: 0.4s
reassign 607544 libsvn1 1.6.12dfsg-2
retitle 607544 libsvn1 symbols file is not complete
thanks
On Sun, 19 Dec 2010, Matthias Klose wrote:
from the build log
https://buildd.debian.org/fetch.cgi?pkg=rapidsvnarch=i386ver=0.12.0dfsg-3stamp=1292776183file=logas=raw
dpkg-shlibdeps: warning:
Hi,
On Wed, 29 Dec 2010, Lars Wirzenius wrote:
The dpkg-source manpage says:
--before-build directory
This command should be called before any build of the package
What is the directory argument to the option? Should it be command
instead?
No, it's really
On Wed, 29 Dec 2010, Jonathan Nieder wrote:
Package: dpkg-dev
Version: 1.15.9
Severity: wishlist
Thorsten Glaser wrote:
dpkg-architecture appears to be called rather often.
It’s slow though…
r...@ara0:~/T # time dpkg-architecture
DEB_BUILD_ARCH=m68k
[...]
0m7.49s real
On Wed, 29 Dec 2010, Thorsten Glaser wrote:
I never meant this as bug report, just a sort of heads-up. If it is
unfixable, unless things are rewritten in non-Perl, that’s the way
it is.
Well, obviously Jonathan thought something else.
But he provides patches from time to time so I have some
On Wed, 29 Dec 2010, Lars Wirzenius wrote:
On ke, 2010-12-29 at 14:06 +0100, Raphael Hertzog wrote:
Hi,
On Wed, 29 Dec 2010, Lars Wirzenius wrote:
The dpkg-source manpage says:
--before-build directory
This command should be called before any build
On Thu, 30 Dec 2010, Lars Wirzenius wrote:
dpkg-source --before-build foo is the command. You (can) call it. And it
does whatever the source format decided to do in this hook.
In practice, those commands are called by dpkg-buildpackage and it's
their main purpose. Prepare the source
reassign 608674 debconf
retitle 608674 debconf calls .config script with bad arguments when postinst
triggered is run
severity 608674 important
clone 608674 -1
reassign -1 cdebconf
thanks
On Sun, 02 Jan 2011, Debian Bug Tracking System wrote:
reassign -1 dpkg 1.15.8.7
Bug #608674
severity 608829 normal
thanks
On Mon, 03 Jan 2011, Bastian Blank wrote:
Severity: important
It's not a major usability problem... dropping to normal.
dpkg-source rejects valid patch files:
| dpkg-source: error: diff
`xen/debian/patches/upstream-21334:993458f6c5a0+21405:ae381a864b4f'
On Mon, 03 Jan 2011, Bastian Blank wrote:
It is a crafted file. It consists of two appended diffs.
Why not use two diffs instead?
diff.gz is never hand-generated, the contents of debian/patches are. If
they may not, you have to document it.
True.
quilt and patch applies this patch
Hi,
On Tue, 04 Jan 2011, Sandro Tosi wrote:
On Tue, Jan 4, 2011 at 18:23, Mike Hommey m...@glandium.org wrote:
On Tue, Jan 04, 2011 at 06:20:46PM +0100, Sandro Tosi wrote:
On Tue, Jan 4, 2011 at 18:15, Mike Hommey m...@glandium.org wrote:
Maybe a helper that the maintainer could ask the
On Wed, 05 Jan 2011, Mike Hommey wrote:
Except if we make all users have apt-xapian-index installed, this is not
going to be helpful to maintainers.
It's a recommends of aptitude and is installed by default.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶
Hi,
On Mon, 24 Jan 2011, Trent W. Buck wrote:
I wanted to run logcheck on my centralized logging server, to which
syslog messages are sent. Further, I wanted to see this with the
logcheck exclusions provided by individual packages. To this end, I
fetched the relevant packages and from them
Hi,
On Mon, 24 Jan 2011, Peter van Dijk wrote:
in short: removing a package that has requested File triggers, does not
remove those triggers from /var/lib/dpkg/triggers/File. Is this intended
behaviour?
I also noticed this recently (with some test-suite work), and it's true
for named triggers
On Mon, 24 Jan 2011, Julien Cristau wrote:
In other words, how about something like this patch?
I don't think that's a good idea at this point. A year ago, maybe.
One issue Sven mentioned on irc is that an unknown number of packages
would start shipping /usr/share/info/dir.gz on rebuild
On Thu, 27 Jan 2011, Manoj Srivastava wrote:
The preinst scripts generated by kernel-package are generally
not 424 lines long in recent versions of kernel-package. It does,
however, seem like a kernel-package generated package (10.00.Custom
part points to that); so it would be
Hi,
On Sat, 12 Feb 2011, Stéphane Glondu wrote:
After dpkg-source applies patches in a 3.0 (quilt) format, I end up
with files like this:
File: « src/findlib/findlib_config.mlp »
Size: 628 Blocks: 8 IO Block: 65536 fichier
Device: 16h/22d Inode: 1756876
On Sat, 12 Feb 2011, Jonathan Nieder wrote:
2. Raphaël, maybe dpkg-source could do something like this?
utime does not return ENOENT unless all its arguments do not
exist.
What's the point? I don't see how it matters...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian
On Sun, 13 Feb 2011, Jonathan Nieder wrote:
Raphael Hertzog wrote:
On Sat, 12 Feb 2011, Jonathan Nieder wrote:
2. Raphaël, maybe dpkg-source could do something like this?
utime does not return ENOENT unless all its arguments do not
exist.
What's the point? I don't see how
Hi,
On Mon, 14 Feb 2011, Guillem Jover wrote:
LANG=de = '\ Kein Zeilenumbruch am Dateiende.'
That's weird, the code sets LC_ALL and LANG to C before invoking diff.
Do you have a reproducible test case?
I think we're speaking of a diff put by the user in debian/patches/
on which dpkg-source
On Mon, 14 Feb 2011, Jonathan Nieder wrote:
Missing keys. Some other typos. The following might actually work.
Thoughts?
You should also update the code for the source package formats
because both 1.0 and 3.0 (quilt) pass an explicit value
for the timestamp.
And your patch is heavy on the
Hi,
On Mon, 14 Feb 2011, Mike Hommey wrote:
The manual page says:
unsafe-io: Do not perform safe I/O operations when unpacking. Currently
this implies not performing file system syncs before file renames, (...)
While this is stricly true, there are still two fsync()s occuring on each
Package: dpkg
Version: 1.15.8.10
Severity: wishlist
Pascal Dupuis submitted us (privately) the attached patch with this request:
I have access to a machine where I can develop, compile, install
locally and run programs in my $HOME dir, but not install packages.
After fiddling a bit inside
On Mon, 28 Feb 2011, Michal Suchanek wrote:
That won't break any packages. Packages that don't build with -j 1 are
broken to start with. This may at most expose the bugs which is only
a good thing. If the package is broken and hard to fix otherwise the
flag can be disabled for the package
Package: dpkg-dev
Version: 1.15.8.10
Severity: wishlist
On Mon, 28 Feb 2011, Jakub Wilk wrote:
* Raphael Hertzog hert...@debian.org, 2011-02-28, 16:01:
symbols which should not be used can either be not listed in the
symbols file (and be auto-added at build time with a strict
dependency
On Tue, 08 Feb 2011, Colin Watson wrote:
Hi,
We're considering bringing up a ppc64 port of the Ubuntu server, and it
appears to be best to build it with -O3 rather than -O2. (I realise
that this would be unusual in Debian and that there are more obstacles
to this than just dpkg-buildflags,
Hi,
On Tue, 01 Mar 2011, Patrick Schoenfeld wrote:
Well, I've written DPKG::Log because I had a need for it and thought
it could be useful for others. Merging it into the dpkg codebase is
probably a good idea and so I'm revisiting that idea with this mail.
I see one problem, however.
My
Hi,
On Sat, 05 Mar 2011, Josh Triplett wrote:
dpkg-deb --fsys-tarfile /dev/stdin seems to work, but it would help to
have some guarantee in the documentation that it will always work, and
dpkg-deb will never seek on the input.
Help for what? What's your use case?
I don't really see the
On Sat, 12 Mar 2011, Roger Leigh wrote:
Patch attached which fixes it for me. Note that I don't quite
get why you're skipping whitespace--I'm not sure why there would
be whitespace before the PGP signature, so I'm not sure if the
whitespace skipping is necessarily related to the PGP part.
Hi,
On Tue, 22 Mar 2011, Mark Hymers wrote:
Please consider merging it. Note that dpkg-deb still complains that it's a
user-defined field although it gets added to the binary control file anyways.
I looked at patching it into lib/dpkg/parse.c as well but wasn't sure how far
down this road to
On Mon, 21 Mar 2011, Joerg Jaspert wrote:
buxy mentioned to optimize this by leaving out all the binary entries
that are using the default overrides. I don't much like this for two
reasons: First you would need to add two more fields, section/priority
to show what those defaults are, they
Hi,
On Thu, 24 Mar 2011, Wookey wrote:
It is probably not hard to enforce this at a slightly higher level.
Indeed, it may make sense to just parse any string after the :, then
have higher-level checks for valid values. The multiarch spec
explicitly says to reject anything other than :any (in
Hi,
On Thu, 24 Mar 2011, Bernhard R. Link wrote:
Do I understand this correction correctly that dpkg-source -b will
generate that when generating a source package.
Yes.
This is put in the .dsc but everything that makes a Sources out of it
will need to remove it again (or have an unnecessary
On Thu, 24 Mar 2011, Wookey wrote:
OK. I realised after posting this that there was already some very
similar code in dpkg 1.16.0 in natty. So I did a patch against that
here: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/741433
which is probably very close to what you are asking for.
tag 556637 - patch
thanks
On Tue, 17 Nov 2009, Jussi Hakala wrote:
The dpkg determines the architecture in which it's in from a build
time constant. This makes things difficult if we use host's dpkg to
operate on packages non-native to host, for example, with
scratchbox2.
It would be nice
Hello,
On Thu, 24 Mar 2011, Niels Thykier wrote:
We got a report in Lintian that dpkg 1.16.0 causes test failures in
Lintian; so I checked out dpkg 1.16.0 (commit: 893a04ba) and I
noticed that one of the failures are caused by dpkg-source choking
on our empty-diff test (see the log).
Thanks
:
On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
It looks like this:
Package-List:
src:dpkg admin required
Is there a reason for not listing the type explicit for every entry?
Something like this:
dpkg source admin required
dpkg deb admin required
dselect udeb admin
On Sat, 26 Mar 2011, Bastian Blank wrote:
On Thu, Mar 24, 2011 at 04:25:46PM +0100, Raphael Hertzog wrote:
First line is always
the source entry.
Do you want this constraint part of the definition or a implementation
detail?
I don't
Hi Guillem,
On Fri, 01 Apr 2011, Guillem Jover wrote:
I'd like us to agree to avoid in general doing design work for public
interfaces directly on git master while there's no clear consensus yet,
because I think it's more costly than pondering for a bit longer.
Sure, I just tried to please
On Mon, 04 Apr 2011, Craig Sanders wrote:
any chance of dpkg being less spammy about it? i guess some kind of
notification is required but it's not a major problem, so doesn't need
a couple of lines of output per package. perhaps a single summary line
mentioning the problem and listing the
On Mon, 04 Apr 2011, Gordon Haverland wrote:
In terms of the kernels I compiled myself, they were named
according to the instructions that were present at one time for
kernel-package. The README.gz in /usr/share/doc/kernel-package
still shows version strings that are not strictly numeric.
On Mon, 04 Apr 2011, jida...@jidanni.org wrote:
What do you want me to do, remove my precious obsolete mysql-doc
package?
That or face the rest of my life with those warnings?
Yes. Or get that documentation properly packaged.
(Or edit /var/lib/dpkg/status to add the missing field if you
On Mon, 04 Apr 2011, Jonathan Nieder wrote:
Wait a second. I'm not up to speed on the exact design, but such
widelands versions really _were_ in the archive once (according to
snapshot.debian.org). And this is about dpkg-query looking through
the available file, not dpkg -i. Are you sure
On Tue, 05 Apr 2011, Guillem Jover wrote:
The strict parser should only take effect on anything that's not the
status or the available files and --compare-versions.
Not sure I parse your sentence correctly, but
--compare-versions uses the strict parser:
$ dpkg --compare-versions foo2 eq foo2
501 - 600 of 801 matches
Mail list logo
