Guillem Jover writes ("Re: Bug#1014476: /usr/bin/dpkg: dpkg --skip-same-version
should look at arch too"):
> On Wed, 2022-07-06 at 18:50:08 +0100, Ian Jackson wrote:
> Thanks for the patch! So while I think the new behavior makes more
> sense, my main concern has been mostly ab
-- no debconf information
>From bae0373d9672cae241a06530bb50b935976149b3 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Wed, 6 Jul 2022 18:44:21 +0100
Subject: [PATCH] dpkg --skip-same-version looks at the architecture too, so -E
can be used for an idempotent crossgrade.
---
debian/changelog
ry feature(s) to GNU diffutils, or by ad-hoc perl code.
Ian.
[1] I think these goals make it difficult to provide the otherwise
desirable objective of being able to represent a patch series. IMO
that objective is less important now that more and more people are
working purely in git and treatin
I want to fix this without having to manually restart the
autoremoval clock and/or ask for help from the release team, I should
have NMU'd dpkg at least a week ago.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that
something. Do we have a
plausible way of doing that ? Possibly we could look for the
combination of new binutils and old dpkg-dev, in buildinfo files.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @eva
ping?
Once again I have a user who tripped over this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998394
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Guillem Jover writes ("Re: Bug#996959: Revert (or document) 9d3ec0f5 (prerm
fallback version test)"):
> No, I've just reverted this locally and will be included in the next
> upload. Thanks for the digging and analysis.
Cool, thanks, you're welcome.
--
Ian JacksonThese opi
be kept, then
policy ought to be changed. And probably, a message about skipping
the fallback would be helpful - both for un-confusing someone
debugging dpkg, and for the user/developer who is afflicted by a
broken pre-rm: it would tell them what they need to do (a bodge like I
just did).
Thanks,
Ian.
-
Guillem Jover writes ("Re: Bug#964017: grep-excuses"):
> On Tue, 2020-06-30 at 14:15:13 +0100, Ian Jackson wrote:
> > The string "failed to verify signature" is not generated by code in
> > dgit. Looking at the code in dgit, I think the error happens here:
>
control: retitle -1 Dpkg::Source::Package:new require_valid_signature => 0
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
t has
its own idea of the public keys to use for signature verifications.
But this test case should not involve any of that.)
FYI this is currently preventing the migration of the new dpkg.
>From the above it seems to me that that migration block is correct
because src:dpkg has a regression here
Package: libdpkg-perl
Version: 1.18.25
Severity: normal
$ perl -we 'use Data::Dumper; print Dumper($SIG{INT})'
$VAR1 = undef;
$ perl -we 'use Data::Dumper; use Dpkg::Source::Package; print
Dumper($SIG{INT})'
$VAR1 = sub { "DUMMY" };
$
This is a problem because when a SIGINT handler is
theoretical. And someone with this workflow
has other options.
I hope this makes sense.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
g-query -f'${Version}\n' -W libdpkg-perl
1.18.25
$ ./t.pl ../bpd/dgit_8.3.dsc
ok
$
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
and I am confident that dpkg-source would actually reject
those.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian Jackson writes ("Default -I and -i option should not exclude .ignore"):
> Changing this has compatibility implications. Many tools assume the
> existing behaviour. I suggest the following transition plan:
Ping?
In particular, (i) do you agree that this should be changed
and
Guillem Jover writes ("Re: Bug#910737: dpkg-source -b /path/to/somewhere should
not delete somewhere.orig"):
> Well, this is the documented behavior for source format 1.0 (it does
> not apply to newer source formats) which has acted like this since its
> introduction in dpkg 1.3.0:
>
>
>
binary-package-in-preparation permissions (which need to be those
intended for the output package).
Does that make sense ?
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
asily cherry-pick
> what to extract...
It could search the tree for bad links after extraction but before
exiting status 0.
Or we could request that tar grow an option like rsync's --safe-links.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evad
cannot access '../mason.orig': No such file or directory
zealot:bpd>
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
he maintainer's debian/source/options and the implied
tar-ignore.
> I think both options, never-add-tar-ignore-defaults-even-if-specified
> and clear-all-tar-ignore are valid, and I might add both, just wanted
> to make sure I understand which one you are requesting here.
So I think I want
Julian Andres Klode writes ("Re: Bug#908747: Default -I and -i option should
not exclude .ignore"):
> On Thu, Sep 13, 2018 at 12:26:27PM +0100, Ian Jackson wrote:
> > The result of this default is that many source packages in the Debian
> > archive are incomplete. [...
not):
.shelf
_MTN
_darcs
{arch}
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
and
everything would work right.
So, please could you provide such an option.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Simon McVittie writes ("Bug#850156: Please firmly deprecate vendor-specific
series files"):
> On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote:
> > On Wed, 4 Jan 2017 13:41:53 + Ian Jackson
> > <ijack...@chiark.greenend.org.uk> wrote:
> > > But
or Sources.gz; and
- not invite semantically mistaken uses.
Sorry.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Iain Lane writes ("Re: Bug#852820: Testsuite-Restrictions field is hard to
use"):
> I don't, or not really - see below. I plan on using this field
> externally to choose between a couple of available backends to dispatch
> to when constructing autopkgtest invocations
Yes, I understand that. But
for many years.
Thanks,
Ian.
https://manpages.debian.org/testing/dgit/dgit-user.7.en.html
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Guillem Jover writes ("Re: Bug#852820: Testsuite-Restrictions field is hard to
use"):
> On Fri, 2017-01-27 at 15:58:28 +, Ian Jackson wrote:
> > If not interpreted very carefully, this would give a test suite runner
> > the erroneous impression that none of the tests
Guillem Jover writes ("Re: Bug#852821: Dropping Built-For-Profiles is risky"):
> On Fri, 2017-01-27 at 15:58:30 +, Ian Jackson wrote:
> > This significantly reduces the amount of information available to
> > understand why a .deb might be the way it is. It also
way -uc is sufficient.
Thanks for your attention.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
uld be
discussed on autopkgtest-devel (or other DEP-8 related places).
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
hem is a
second-best solution.
This kind of thing is an inevitable consequence of 1. the way that the
implementation of `3.0 (quilt)' simply invokes patch on whatever
appears in the source package, without any kind of further checking;
combined with 2. patch not having a proper (formal) approach to
pro
Control: reassign -1 devscripts
Control: found -1 2.16.10
Ian Jackson writes ("dpkg-source fails to extract samba_3.6.5-2.dsc but exits
status 0"):
> zealot:d> dget
> 'http://snapshot.debian.org/archive/debian/20120513T033831Z/pool/main/s/samba/samba_3.6.5-2.dsc'
> dg
L=C patch -t -F 0 -N -p1 -u -V never -E -b -B
.pc/waf-as-source.patch/ --reject-file=- <
samba-3.6.5/debian/patches/waf-as-source.patch gave error exit status 1
zealot:d> echo $?
0
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you
=
ii dpkg-dev 1.15.11 Debian package
development tools
$
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
okmark-plugin: /debian/patches/ubuntu.series
zlib: /debian/patches/debian.series
`---
Not sure if this is more widespread in other derivatives.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that
, which is why I think this is dpkg-buildpackage's
fault.
I think setting SOURCE_DATE_EPOCH to the empty string is always
wrong, so I think the bug is in dpkg-buildpackage, not dpkg-deb.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I email
Package: dpkg-dev
Version: 1.18.18
$ dpkg-buildpackage -uc -b -j8
...
dh_gencontrol --
dpkg-gencontrol: warning: debian/changelog(l49): badly formatted trailer
line
LINE: --
dpkg-gencontrol: warning: debian/changelog(l51): found start of entry where
expected more change data or
s from glibc-2.23/debian/source/options:
--compression=xz
dpkg-source: error: diff
'glibc-2.23/debian/patches/hurd-i386/cvs-IPV6_PKTINFO.diff' patches files
multiple times; split the diff in multiple files or merge the hunks into a
single one
zealot:glibc-2.23>
--
Ian Jackson <i
:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02
Regexp bracketed character sets with ranges depend on locale.
Point 7 of:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
--
Ian Jackson <ij
y-intended fallback to not work.
Thanks,
Ian.
>From dd832d939be64011bba7e9a846fa52ea125fdc2d Mon Sep 17 00:00:00 2001
From: Ian Jackson <ijack...@chiark.greenend.org.uk>
Date: Sat, 5 Nov 2016 13:39:29 +
Subject: [PATCH] dpkg-parsechangelog: Tolerate, once more, unfinalised
changelogs.
In 2009 it seems I attached the wrong file to my email. Here is the
right file.
diff -r --exclude=Makefile --exclude=available --exclude=status --exclude='*~'
--exclude='config.*' --exclude='*.in' -u orig/dpkg-1.14.25/src/depcon.c
edit/dpkg-1.14.25/src/depcon.c
---
Johannes Schauer writes (Bug#744246: We'll be waiting for Jessie release with
build profiles):
As agreed with Guillem, the changed build profile functionality will
be in dpkg soon, a patch for apt is ready and patches for other
tools will be prepared as well. But having in mind that it is not
Guillem writes, on the bug but not on debian-devel:
Part of the definition of what's and what's not a native package is
the version scheme, and I've never considered that a Debian specific
thing specified by its policy. The fact that dpkg-source has been
sloppy in the past for format 1.0 does
Dimitri John Ledkov writes (Re: dpkg-dev: please reject native/non-native
version when building native/non-native source packages):
Patch is attached to the new bug filed about this issue
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
Proposed patch adds --force-native dpkg-source
Guillem Jover writes (Re: Bug#735975: Dpkg::Control::Hash: would like more
subtle pgp check):
Yes, you could rely on this, but there's actually another option, in
this case you could use Dpkg::Source::Package instead which has a
is_signed() method since its inception (it only got documented as
Guillem Jover writes (Re: Bug#735975: Dpkg::Control::Hash: would like more
subtle pgp check):
...
Starting with version 1.17.0 the Dpkg::Control::Hash module records
that fact in the is_pgp_signed option. This is not documented, so you
might not want to rely on it, expecting to be an internal
Olaf van der Spek writes (Re: Bug#605009: serious performance regression with
ext4):
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o ty...@mit.edu wrote:
I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
would be best.
Are there any plans to provide an API for atomic
Olaf van der Spek writes (Re: Bug#605009: serious performance regression with
ext4):
Probably not an issue for dpkg, but in general:
Don't you reset meta-data that way?
Yes. If you want to keep the metadata you must copy it.
Require a second file (name), permission to write to it and assume
Raphael Hertzog writes (Re: Bug#586691: dpkg-buildpackage and LDFLAGS etc.):
forcemerge 560070 586691
thanks
...
We have dpkg-buildflags nowadays for this.
Thanks. I have just read #560070. Can I request that #560070 be
fixed in a stable release update ?
We're migrating to a situation
Package: dpkg-dev
Version: 1.14.29
dpkg-dev nowadays sets various *FLAGS variables in the environment.
However some upstream build systems (eg, the one in xen-unstable.hg)
break if these variables are set eg because they do stuff like
LDFLAGS ?= -Lsomething_we_really need
Arguably those upstream
+0100
@@ -1,3 +1,11 @@
+jigit (1.15-2ubuntu4) gutsy; urgency=low
+
+ * debian/rules: use build-stamp-debian instead of build-stamp
+as the .orig.tar.gz contains build-stamp which makes it not actually
+build mkimage, causing the package to be FTBFS (!)
+
+ -- Ian Jackson i...@ubuntu.com Tue
Package: dpkg
Version: 1.15.0
/usr/share/man/man5/deb-triggers.5.gz has just come to my attention.
I can see why someone wanted to add it but I think the inclusion of
this file in this form was a mistake.
If everything about the triggers machinery was done in manpages then
absolutely, there
Colin Watson writes (Re: Bug#426752: Ubuntu-specific Maintainer: field
processing, safety check):
I've attached an updated version of the patch Ian sent, adjusted for the
changes in dpkg-source in the intervening time and with a stricter check
on DEBEMAIL before promoting this from a warning
Holger Levsen writes (Bug#437118: reassign + close ;-) (not fully sure if this
is right)):
I'm reassigning this to dpkg, even though I'm not sure if this is right.
Apologies for that.
I don't think it is, probably.
This is based on popcon data. How does popcon read the dpkg
database ? Does
Package: dpkg
Version: 1.14.20
Tags: patch
When I designed the way dselect [U]pdate works, I assumed that `more
trustworthy' repositories, ie ones which in the ftp method's [A]ccess
come later, would always have better information. So when the ftp
method loads a sequence of Packages files, later
Raphael Hertzog writes (Re: Bug#143307: triggers-related dependtry assertion
fix):
Can you expand on why you decided to create a msdbrw_simulate status then
as opposed to using modstatdb_note_ifwrite() in the problematic cases
in the trigger code ?
Various other bits of the code need to know
Raphael Hertzog writes (Re: Bug#476899: dpkg: Leaves new conffiles as
file.dpkg-new if the conffile is diverted):
But the content of the conffile gets real only after configuration and any
trigger recorded during unpack might have already been processed (at the
end of a dpkg --unpack run
Raphael Hertzog writes (Re: Bug#487637: config of triggers-awaited packages):
(Switching from bug 143307 to 487637)
...
I tried to come up with a patch, see below. The nicest solution I found
was to detect packages in triggerawaited status if we were asked to
configure them, and to add to the
tags 483655 + patch
severity 483655 minor
Raphael Hertzog writes (Re: Bug#483655: queue.length assertion failure):
Ping. (Yes I believe one should always upload relevant information
immediately, it's a pain to have to remember to ping people later on)
Yes, sorry, but I really didn't have time
Raphael Hertzog writes (Re: Bug#143307: triggers-related dependtry assertion
fix):
So it's exactly the same situation as in #487637, #489068. Looks like both
are correlated after all.
I think #487637 is something else, as I said.
Do you have a /var/lib/dpkg/ for #489068 ?
Then the --no-act
tags 143307 + patch
thanks
I've reproduced the problem from #143307 and attached is a fix.
The core of the problem was that if dpkg is interrupted, you can have
the following situation:
Package: a
Triggers-Awaited: b
Package: b
Status: ... installed
This is as expected but I
Raphael Hertzog writes ([EMAIL PROTECTED]: Bug#487637: Unable to configure
dpkg after disk full during its trigger execution]):
another trigger-related bug that might be vaguely related to the other one
that I already forwarded you. At least, it seems to confirm that dpkg
--configure -a is
I have reproduced this bug in the course of a routine upgrade to my
main not really very unusual lenny box. I have a reproduceable test
case for a /var/lib/dpkg. I'm not attaching that to this bug because
I intend to fix it but if I haven't done so soon please ping me and I
will upload the
Raphael Hertzog writes (About triggers):
On this topic, I'd like to get your opinion on #143307. It looks like
that the the trigger handling leads to more cycles in dependencies
since some packages must be triggered before being configured.
I think this explanation is a red herring.
I
2008-02-22 Ian Jackson [EMAIL PROTECTED] INBOX
I think the right answer is for dpkg -L to sort its output (perhaps
with an option to suppress this if desired).
The other way round. Please make the sorted listing the default, and
add separate option to list the RAW order[*]
I think you must
DPeter Gervai writes (Re: Bug#467024: dpkg: control directory has bad
permissions message could be more helpful):
On Sun, Feb 24, 2008 at 2:56 PM, Ian Jackson
[EMAIL PROTECTED] wrote:
The package has a bug if this message happens just because you build
it in a setgid directory.
It's
Raphael Hertzog writes (Re: Bug#467024: dpkg: control directory has bad
permissions message could be more helpful):
On Fri, 22 Feb 2008, Ian Jackson wrote:
Someone building a package should know that the problem with an actual
mode of 2755 when compared with a maximum of 0775 is that 2755
Natanael Copa writes (Bug#465420: [PATCH] dpkg-1.14.16.6 does not compile on
non-nls systems):
Package: dpkg
Version: 1.14.16.6
dpkg fails to compile if there are no gettext and libintl.h even with
the --disable-nls compile flag.
There are some nice defines in lib/dpkg.h that defines
Raphael Hertzog writes (Bug#466971: dpkg [dpkg] lists output of option -L in
alphabetical order):
Rather the rest of the man pages are detached from the one marked with
!... and they are detached because they are symlinks. Symlinks always
appear at the end of dpkg -L. I don't know if there's
Raphael Hertzog writes ([EMAIL PROTECTED]: Re: Bug#464907: dpkg seems not to
check for broken versioned dependencies when upgrading]):
since you wrote the patch that Joey has been testing, can you look what's
wrong with it ?
Yes, I should investigate.
Ian.
--
To UNSUBSCRIBE,
Raphael Hertzog writes (Re: Bug#456332: dpkg could use an elevated pre-depends
or depends on lzma):
I'm still not convinced that this is the right approach, Pre-Depends are
supposed to not be used lightly. Does the package need to be configured,
isn't a simple dependency enough ?
Yes,
Ian Jackson writes (Re: Bug#456332: dpkg could use an elevated pre-depends or
depends on lzma):
by dpkg-gencontrol and into an appropriate -Z option by
dpkg-buildpackage, then ?
Oh, no, not dpkg-buildpackage. Hrm. It really has to be in dpkg-deb,
which ought to strip out the special header
Raphael Hertzog writes (Bug#456332: dpkg could use an elevated pre-depends or
depends on lzma):
The debian/control field is the only viable option IMO. It would be
somewhat similar to the Package-Type: header which has no real use except
influencing the behaviour of another tool during the
Raphael Hertzog writes (Re: Bug#456332: dpkg could use an elevated pre-depends
or depends on lzma):
On Thu, 24 Jan 2008, Ian Jackson wrote:
How about if we arrange to pass -Zsomething to dpkg-gencontrol, and
have a table in dpkg-dev to map something to
deb-decompressor-something
Raphael Hertzog writes (Bug#456332: dpkg could use an elevated pre-depends or
depends on lzma):
On Tue, 18 Dec 2007, Ian Jackson wrote:
IMO the lzma binary package should Provide a new virtual package name,
lzma-deb-support or some such. Packages could Pre-Depend on that.
What does
Sorry, I have just been prompted to look what happened here and it
seems that my message to 432893@ was misaddressed and bounced.
I wrote:
Following discussions on debian-dpkg and debian-policy and in #443334,
we seem to have concluded that the correct behaviour for dpkg is to
not run the
Chris Cheney writes (Bug#456332: dpkg could use an elevated pre-depends or
depends on lzma):
dpkg supports using lzma for compression of debs however it only
suggests the lzma binary package which is what is _currently_ used for
decompressing the debs. In the future it would be preferable if a
Manuel Prinz writes (Re: Can anybody *please* fix #220044 - broken slave files
(link)):
I spent some time on trying to fix it myself but failed because I lacked
of time to dive into u-a. I'd like to do some documentation or even
several changes to make the u-a code more readable, if this work
Egmont Koblinger writes (Bug#281057: ...):
I can't remember what I did when I updated the patch, but a simple
text merging sounds more probable than performing all the tests again.
Right.
Please note that I no longer work for the company where we maintained
a dpkg-based Linux distro and kept
martin f krafft writes (Bug#391818: --force-confnew and existing unchanged
conffiles):
Look at the size; the contents are different.
Oh, yes, I see.
Hmm. Did this happen to you only once or can you reproduce it ? Does
it happen only to this package ?
I have to admit to never using
Simon Richter writes (Bug#398625: adapted patch against current dpkg):
I have written a new implementation of the patch proposed earlier,
against the current shell script.
As discussed on debian-devel, I think this approach is fundamentally
wrong.
Failure of a rules target should not be
Bill Allombert writes (Bug#229357: closed by Ian Jackson [EMAIL PROTECTED]
(Re: Bug#398625: adapted patch against current dpkg)):
This report seems to have been closed in error: 229357 is my patch, not Simon
which is 398625.
The two bug reports are merged and I was responding to Simon
Sven Joachim writes (Re: Bug#421792: /var/lib/dpkg/info/*.md5sums inherits
from package):
Ian Jackson [EMAIL PROTECTED] writes:
These files are generated during package building as DEBIAN/md5sums,
and that file's permissions and ownership are inherited by the
installed file. (I have just
Raphael Hertzog writes (Re: Bug#20471: patch to check rdepends on unpack):
I just did that locally and attached is the corresponding patch (created
by git-format-patch for easy inclusion). I adjusted the commit log, the
changelog and fixed some trailing spaces (that the pre-commit hook
forbid
I've looked at the situation here and I think I agree with Egmont's
analysis in his original report in November 2004. In particular, I
agree with his assertion about the memory leak due to failed lstats in
the code in 1.10.24:
cfile-namenode-filestat = (struct stat *) nfmalloc(sizeof(struct
Raphael Hertzog writes (Re: Bug#20471: patch to check rdepends on unpack):
bug20471 branch in git://git.debian.org/~rhertzog/dpkg.git
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=bug20471
For the record, while I think trailing whitespace is hardly a big
crime :-), that commit
Package: dpkg
Version: 1.14.7
I have made the (very small!) changes which I think will be correct
for dselects to handle Breaks correctly.
The results are here:
http://git.debian.org/?p=users/iwj/dpkg.git
git://git.debian.org/git/users/iwj/dpkg.git
etc. as the branch
dselectbreaks
Ian.
Raphael Hertzog writes (Bug#20471: patch to check rdepends on unpack):
Please either attach a copy of the patch or use git.debian.org so that we
can browse the changes via gitweb.
It's now at
http://git.debian.org/?p=users/iwj/dpkg.git
git://git.debian.org/git/users/iwj/dpkg.git
etc. as the
found 432893 1.14.5
found 432893 1.10.28
tags 432893 + patch
thanks
A patch to implement this behaviour is now at
http://git.debian.org/?p=users/iwj/dpkg.git
git://git.debian.org/git/users/iwj/dpkg.git
etc. as the branch
bug432893
It will be necessary to merge the triggers branch first to
tags 170825 - patch
severity 170825 normal
thanks
I have checked the supposed patch for this bug, which is in #170825,
and I'm afraid it's not right at all. It changes dependencies_ok in
packages.c which is used during configure and remove. What is needed
is to enhance the checks which happen
Package: dpkg
Version: 1.14.7
In processarc.c:
if (!depisok(dsearch,depprobwhy,0,1)) {
varbufaddc(depprobwhy,0);
fprintf(stderr, _(dpkg: regarding %s containing %s, pre-dependency
problem:\n%s),
pfilename, pkg-name, depprobwhy.buf);
if
retitle 192981 unchanged permissions of conffile should be updated
severity 192981 wishlist
thanks
I don't think it would be correct to overwrite the on-disk permissions
of a conffile from the permissions in the package, just because
neither the user nor package maintainer had changed the
severity 330256 normal
retitle 330256 delete obsolescent not-locally-changed conffiles
thanks
I'm inclined to agree with Anton Zinoviev's view. However, I don't
think this change should be made without more careful consideration as
it's a substantial and possibly destructive change to the
severity 391818 normal
thanks
Looking at the information provided in this bug report it's not clear
to me that there's any evidence that the contents of the file is
wrong.
martin: Is your complaint is that the permissions weren't updated ?
Or the timestamp ? Or are the contents really different
Package: dpkg
Version: 1.9.11
While checking something else I saw this in dpkg-source.pl:
$SIG{'PIPE'} = 'DEFAULT';
...
local $SIG{PIPE} = 'DEFAULT';
This appears to correspond to some of the following changelog entries:
dpkg (1.9.11) unstable; urgency=low
* Apply patch from
unmerge 421792
severity 421792 normal
thanks
In this bug report the user reports that they had a non-world-readable
/var/lib/dpkg/info/binutils.md5sums
These files are generated during package building as DEBIAN/md5sums,
and that file's permissions and ownership are inherited by the
installed
Frank Lichtenheld writes ([PATCH/RFC] deb-version.5: Add an own manpage for
Dpkg's version format):
1) If I would copy this text, who to credit for it? For now I just
copied the copyright notice from Policy but I suspect that might not be
the whole truth given how old it is.
I haven't
Raphael Hertzog writes (Accepted dpkg 1.14.7~newshlib (source i386
all)):
[stuff]
I'm very pleased to see all of this work being done on the Perl
scripts - I'm hoping for big compatibility improvements from Raphael's
shared library management changes.
But I did want to comment on this:
*
1 - 100 of 131 matches
Mail list logo
