Hi Craig,
On Wed, 01 Feb 2012, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
reassign 658222 dpkg
Bug #658222 [dlocate] dlocate: messes with dpkg's internal files, will break
with multiarch
Bug reassigned from package 'dlocate' to 'dpkg'.
You know
reassign 658222 dlocate
thanks
On Wed, 01 Feb 2012, Craig Sanders wrote:
it makes perfect sense. a useful function provided by dpkg for the
last 15+ years is being taken away. that's a bug. If dpkg can no
longer provide access to the raw files (and I still don't have a clear
understanding of
reopen 564955
severity 564955 wishlist
thanks
Hello Stéphane,
On Wed, 01 Feb 2012, Stéphane Aulery wrote:
close 564955 1.15.8
stop
You should not close a bug that way. Instead you send a mail to
564955-d...@bugs.debian.org and you put a Version: 1.15.8 pseudo-header
as the first line of your
Hi,
On Thu, 02 Feb 2012, Stéphane Aulery wrote:
I can try my hand at a patch then. I noticed how update-alternatives
uses the logs is almost identical to that of dpkg except that it has
no configuration file and it does not share the code of dpkg/log.c.
We could reuse the lib dpkg for that.
Hello,
On Mon, 06 Feb 2012, Sam Morris wrote:
And the conffile will not be removed.
Is the user in the wrong here? debian-faq says no, as it specifically
advises the user of dch -l when performing a local build. The user
cannot know when he's rebuilding the package that a subsequent version
On Sat, 11 Feb 2012, Guillem Jover wrote:
The general policy regarding dpkg output is that the architecture is
only significant for M-A:same packages, which need to be disambiguated.
For the others either the user explicitly specified them on the
command line or through apt.
That might be
On Mon, 27 Feb 2012, Wookey wrote:
The subject is covered in some detail here:
http://wiki.debian.org/DebianBootstrap
and was covered at Debconf in Baja Luka.
This little patch allows Build-Depends-Stage1 to be added to package
control files, for rules files to use DEB_BUILD_OPTIONS=STAGEN,
Hi,
the idea seems good, in particular since we had to remove this
from dpkg-buildpackage because the information outputted there could
not be accurate (i.e. no access to DEB_*_MAINT_* variables).
Here's a review so that you can bring your patch in a state where I can
merge it.
On Thu, 15 Mar
On Fri, 16 Mar 2012, Bernhard R. Link wrote:
IMO this is not the proper way to extract it automatically. If you want
this feature, you should add a unique (and fixed) start/end marker.
Maybe something like this ?
--- BEGIN DPKG-BUILDFLAGS STATUS ---
[…]
--- END DPKG-BUILDFLAGS
On Mon, 19 Mar 2012, Bernhard R. Link wrote:
I undestand that since 1.16.2 was released in between, I need
to change the version? Attached are new versions of this patches
with the version changed.
Yes, thank you.
Guillem, what's your opinion on the output of the --status command?
Bernhard
Hi,
On Thu, 29 Mar 2012, Matus UHLAR - fantomas wrote:
the dpkg's force-confmiss option, given as commandline parameter, or
as an config option, has no effect when configuration file is
maintained by ucf. that requires users to dig about the reason their
config file is missing.
The ucf
On Thu, 29 Mar 2012, Matus UHLAR - fantomas wrote:
What could be done is for dpkg to export its command line options
in a new environment variable DPKG_CMDLINE_OPTS, and then ucf could
inspect that new variable and verify if --force-confmiss is there.
what if someone puts the option to dpkg
Hello,
On Tue, 03 Apr 2012, Miguel Colon wrote:
I would guess the DEB_BUILD_OPTIONS=noopt problem should be reported
against the package that suffer from this case
Yes, definitely.
but should not the user options in DEB_flag_* (or
$XDG_CONFIG_HOME/dpkg/buildflags.conf) override the
On Tue, 03 Apr 2012, Miguel Colon wrote:
Well any flag not only optimization levels are affected but -OX is
probably the most common case.
Any flag that allow overriding a previous value of the same flag
and that maintainers are likely to change... wich doesn't make many.
Also some packages
retitle 667008 dpkg-dev: dpkg-gencontrol does not use the control file
specified with option -c for the lock-file
thanks
Hi,
On Tue, 03 Apr 2012, Mats Danielsson wrote:
Dear Maintainer,
The solution to Bug #642608 introduced another problem. The lock on the
control
file always uses the
On Tue, 03 Apr 2012, Josh Triplett wrote:
As a more optimal solution, packages could register file triggers on
appropriate paths in /usr/local
Some packages already do (man-db for example).
and dpkg could provide a means for an
administrator to manually trigger those triggers after running
On Wed, 04 Apr 2012, Josh Triplett wrote:
In some way we already do:
$ sudo dpkg-trigger --no-await /usr/local/man
$ sudo dpkg --configure -a
Processing triggers for man-db ...
But there's easy way to find out all the file triggers that match
/usr/local/something.
I meant there's
Hi,
On Wed, 18 Apr 2012, Guo Yixuan wrote:
This bug seems to be fixed, as I tried what Timo has done:
$ dget http://people.debian.org/~hertzog/packages/debsrc3.0/sample7_1.0-1.dsc
$ dpkg-source -x sample*.dsc
$ cd sample7-1.0
Here you need to modify upstream/README to actually match the
On Mon, 23 Apr 2012, jaalto wrote:
| Hmm, well quilt just makes use of patch. And yes, patch seems to
| assume that when there's a '\t' or '\n' on the first line character
| the space got eaten, in pch.c (another_hunk():1646), so given this I
| guess I'll be adding support for these kinds of
reassign 670805 dpkg-dev
forcemerge 485330 670805
thanks
On Sun, 29 Apr 2012, Jari Aalto wrote:
These patches work fine with quilt(1) and patch(1).
Any patch that patch can apply will be automatically supported by quilt.
But 3.0 (quilt) requires unified patch and what you attached is a
context
Hi,
On Fri, 04 May 2012, Marc Haber wrote:
in dpkg-maintscript-helper's rm_conffile function, the code goes to
lengths to set the PACKAGE variable correctly, but the debug output
Executing $0 rm_conffile ... still refers to
DPKG_MAINTSCRIPT_PACKAGE which may not be set. PACKAGE, however,
Hi,
On Mon, 28 May 2012, shawn wrote:
I was working on a ftbfs on armel/armhf
and b/c bzip2 is so slow on a slow armel I decompressed the .orig.bz2,
only to learn that I had to recompress it .gz in order for dpkg-source to
recognize it.
As Guillem said, do your test builds with debuild -b
Hello,
On Thu, 31 May 2012, Debian Bug Tracking System wrote:
reopen 644193
If you reopen a bug, the least you can do is to give some justification
of why you're doing this...
The behaviour change has been made on purpose. If your packages fails to
build due to this, then your package is
On Mon, 04 Jun 2012, Dominic Hargreaves wrote:
I wasn't sure if the small amount of code which could be factored out
justified a new file (and couldn't see an exisiting one), so I left it
in the scripts. Happy to refactor into a new or existing file if you
let me know your preference.
I think
Hi,
On Thu, 07 Jun 2012, P. J. McDermott wrote:
Generalization
==
[...]
Rather than modifying a lot of dpkg code to handle field patterns or
the like, I propose a simple dynamic definition of Build-Depends-
StageN and Build-Depends-Indep-StageN hash elements in %FIELDS:
On Tue, 12 Jun 2012, P. J. McDermott wrote:
And the subroutines in Dpkg::Control::Fields that get values from
%FIELDS can call the following new subroutine to do so:
sub field_get($) {
my ($field) = @_;
foreach my $key (keys %FIELDS) {
return $FIELDS{$key}
On Wed, 13 Jun 2012, P. J. McDermott wrote:
Fair enough. I think a separate hash could address both of these points:
sub field_get($) {
my ($field) = @_;
return $FIELDS{$field} if exists $FIELDS{$field};
foreach my $key (keys %FIELDS_RE) {
return
Hi,
On Sat, 16 Jun 2012, Benjamin Drung wrote:
debchange uses dpkg-vendor to query the vendor. «dch -e ''» takes 1.3 s
with the query to dpkg-vendor and 1.1 s without that query. That's 15 %
of the total execution time. Having a slow debchange is annoying. The
time is accumulating if
Hi,
On Sun, 17 Jun 2012, Julien Cristau wrote:
On Sun, Jun 17, 2012 at 19:46:50 +0200, Guillem Jover wrote:
But you can silence it yourself, by installing libfile-fcntllock-perl,
or is that a problem?
I'm not installing anything I don't have to in any build chroot, no.
The only reason why
Hi,
On Tue, 03 Jul 2012, David Bremner wrote:
If the first patch in a 3.0 (quilt) series is reverted by later
patches in the series, then the heuristic used by dpkg-source to
detect if patches are applied fails. This might sound contrived, but
it can arise if e.g. patches are generated from
Hi,
On Thu, 08 Mar 2012, Andreas Beckmann wrote:
(regarding the original problem:)
I'm seeing a lot of owned directories remaining in the piuparts tests for sid
(they are treated as error for sid and warning for other distributions):
Package: dpkg-dev
Version: 1.16.4
Severity: normal
User: d...@packages.debian.org
Usertags: dpkg-shlibdeps
dpkg 1.16.4 introduced the Build-Depends-Arch field but dpkg-shlibdeps has
not been updated to deal with this field.
Build dependencies are sometimes scanned to find out minimal versions to
Package: dpkg-dev
Version: 1.16.7
Severity: wishlist
User: d...@packages.debian.org
Usertags: dpkg-vendor
The --derives-from command works but when you have multiple levels of
derivatives, it imposes you to order your checks in the correct order
to have the expected behaviour. It's also not
retitle 595112 dpkg-maintscript-helper: new helper for moving a conffile
between packages
thanks
On Tue, 31 Aug 2010, Josh Triplett wrote:
Moving a conffile from one package to another seems to prove even more
difficult than renaming it or removing it. Please consider providing
support for
Hi,
On Fri, 13 Jul 2012, Josh Triplett wrote:
On Fri, Jul 13, 2012 at 05:26:28PM +0200, Raphael Hertzog wrote:
Michael Biebl reported in the thread at
http://lists.debian.org/4f31c323.9090...@debian.org
that the difficulty was to handle the case where the target
package has no guaranty
On Tue, 31 Jul 2012, Josh Triplett wrote:
Consider the original motivation for this. You have a package A, which
contains a daemon B and an init script /etc/init.d/B. You split B and
its init script (and any other configuration files for it) into its own
package, which A does not depend on.
Control: tag 683547 + patch
On Wed, 01 Aug 2012, Thomas Koch wrote:
It might not be a good idea in the first place to have such a patch series.
But
dpkg-source --after-build fails on it. It can not copy the original file
because
the parent directory of the original file does not exist
Hi,
On Fri, 08 Jun 2012, Guillem Jover wrote:
Hmmm, so I had prepared a patch which basically checks if the package
has its dependencies fulfilled before calling the postinst script with
triggered, and otherwise defers the trigger processing for later (but
only as long as it is not running
On Sat, 25 Aug 2012, Guillem Jover wrote:
I'm not sure I understand what the problem being reported here is, but
from the mail subject I'd guess you typed:
$ dpkg --print-foreign-architecture
and that didn't work (due to missing trailing ‘s‘)?
If so then you just need to type the
Control: submitter -1 guillaumese...@gmail.com
On Mon, 03 Sep 2012, Guillaume Seren wrote:
I just released that my mail, was misspelled, in my .reportbugrc, the
good one is : guillaumese...@gmail.com .
Fixing in the BTS.
I patch the source, (from the git diff) and install it again,
but, the
Control: reassign -1 debsums
Control: retitle -1 ignore obsolete conffiles which are not owned by the package
On Wed, 03 Oct 2012, Andreas Beckmann wrote:
seems to work, also if the conffile gets replaced by an updated version
on the way, but it leaves an old md5sum entry in the Conffiles entry
Hi,
On Sat, 27 Oct 2012, Guillem Jover wrote:
Control: tag -1 wontfix
*shrug*
I filed it because I did not found the time to implement it in a
reasonable delay. But I might still want to implement it at some point.
On Fri, 2012-07-13 at 15:44:22 +0200, Raphael Hertzog wrote:
To be able
On Sun, 28 Oct 2012, Jonathan Nieder wrote:
Raphael Hertzog wrote:
Why would it be better to deploy a
dpkg-specific file over a generic file even if dpkg is the only software
making use of that generic file?
Because it makes the purpose of the file
On Mon, 29 Oct 2012, Jonathan Nieder wrote:
Raphael Hertzog wrote:
In both cases the purpose of the file is to provide identification
information about the OS.
Identification for what purpose? So I know which programmer to
complain to when running into compatibility bugs, like the HTTP
Control: reassign -1 apt
Control: forcemerge 626599 -1
On Sun, 11 Nov 2012, Kurt Roeckx wrote:
dpkg processes the same trigger several times during 1 upgrade or
install.
I mostly see for triggers on the man-db and initramfs-tools
package. I would like to avoid all those processed triggers,
Control: forcemerge 636352 -1
On Wed, 12 Dec 2012, Matthias Klose wrote:
dpkg --print-architecture currently can be used to get the name of the current
architecture, however nothing does exist for getting the current multiarch.
I guess you mean the multiarch tuple exported as
Hi,
On Fri, 28 Dec 2012, Harald Dunkel wrote:
Would it be possible to support a command line argument
-C somedir to run dpkg-checkbuilddeps in another
directory without pushd and popd and a temporary variable
to safe the exit value?
This would be very similar to make -C somedir.
Hi,
On Sun, 27 Jan 2013, Nick Andrik wrote:
I am packaging a library implemented in C++ .
During my effort to generate sane symbol files for it, I saw that C++ symbols
differ among architectures.
One way to avoid having different symbols files for each architecture is to
use
the
Hi,
On Sat, 09 Feb 2013, Bernhard R. Link wrote:
Please ensure that the package version matches its nativity state
in 3.0 (quilt/native) packages. Having dpkg-source allow to create
native packages with non-native versions and non-native packages with
native versions can be quite confusing,
Hi,
sorry for the big delay in my answer.
On Sat, 01 Dec 2012, Gregor Jasny wrote:
There are some open questions on my side:
1) Do you see a demand to also require a LASTVERSION argument?
Yes. We always want to restrict such code to be only executed when really
needed. Think for example when
Control: tag -1 patch
On Tue, 19 Feb 2013, Niels Thykier wrote:
$ perl -w -MDpkg::Source::Package -MDpkg::Source::Archive -e ''
Subroutine Dpkg::Source::Archive::getcwd redefined at
/usr/share/perl/5.14/Exporter.pm line 67.
at /usr/share/perl5/Dpkg/Source/Archive.pm line 32
In fact
Hi,
On Wed, 10 Apr 2013, Jonathan Nieder wrote:
It might look harmless, but we do *NOT* want to release Debian
with a dpkg that is broken with respect to all the descriptions
floating around how to clone a system.
I agree that this is a problem, but I cannot convince myself it breaks
On Wed, 10 Apr 2013, Raphael Hertzog wrote:
The impact was perfectly known. I was also concerned by the change but
Guillem did not want to change his mind.
See https://lists.debian.org/debian-dpkg/2012/03/msg00065.html and
Guillem's reply in
https://lists.debian.org/debian-dpkg/2012/03
Hi Yaroslav,
On Tue, 07 May 2013, Yaroslav Halchenko wrote:
now the same couldn't find library message could be warning or error,
e.g.
dpkg-shlibdeps: warning: couldn't find library libmat.so needed by
debian/matlab-psychtoolbox-3-nonfree/usr/lib/matlab/site/psychtoolbox-3/WaitSecs.mexa64
Hi,
On Thu, 16 May 2013, Lincoln Myers wrote:
Apparently, in this situation the build was being done in a filesystem
where flock() fails to lock. I believe libdpkg-perl was unable to
report the real error properly because it is translating the error
message using nonexistent subroutine _. I
Hello,
On Mon, 20 May 2013, Hans-Juergen Becker wrote:
The missing files are existing, but doesn't have the :arch in
there filenames:
Somehow it means that you have /var/lib/dpkg/info/format with a content
of 1 when you shouldn't have it yet (you certainly shouldn't have it
before you upgraded
Hi,
On Mon, 15 Jul 2013, Steve Langasek wrote:
Attached is a tested patch for this. I'm not thrilled about invoking
dpkg-query -S here, but I don't see any other way to get this information.
As suggested by Guillem, it's better to use dpkg-query -L pkg | grep -q
-x /path as you only have to
Hi,
On Mon, 29 Jul 2013, Guillem Jover wrote:
The linux maintainers chose to pass -Zgzip -z0 to dpkg-deb to retain
backwards compatibility.
To retain compatibility they should either not have specified -z at all
or used -z9. dpkg-deb(1) is pretty clear that -z0 for gzip is equivalent
to
Hi,
On Wed, 07 Aug 2013, Guillem Jover wrote:
I've just tested, and dpkg-source 1.15.x shows the same behavior.
Not saying it's desirable, just that I don't see how this breaks
stuff that used to work in the past?
Which 1.15.x have you tested? Because commit
On Wed, 14 Aug 2013, Guillem Jover wrote:
Definitely, and planned (#476221) to be fixed pretty soon. But the
problem is that this can not be enabled by default (only through an
option initially, until the upper layers rely on a dpkg-buildpackage
with such option and use it) because the
Hi,
On Tue, 20 Aug 2013, Guillem Jover wrote:
Although, as I've said before, I consider dpkg-maintscript-helper a
dead-end and in a way a waste of time, I've also said I'd merge
patches for it if they look more or less ok.
For reference, I'm happy to waste my time on dpkg-maintscript-helper
Hi,
On Tue, 20 Aug 2013, Guillem Jover wrote:
I could not test I get problem about
pkg-tests/t-normal/../dpkgdb/info/format-new running pkg-test could
not create file
If you could send the output and how you run it, I could take a look.
I have pushed a fix already. The issue is simply
Hi,
On Tue, 20 Aug 2013, Bastien ROUCARIES wrote:
Now that symlink to dir is implemented, how can we implement the
reverse operation ?
Note that you still have to update man/dpkg-maintscript-helper.1 AFAIK.
We don't want to ship undocumented features.
I suppose checking that the:
- path is
Hi,
On Tue, 20 Aug 2013, Bastien ROUCARIES wrote:
A possible way to do this could be:
* Move the directory away in preinst (dir.dpkg-backup), put in place a
symlink
pointing to the renamed directory
ok this is easy
* In postinst, move remaining files from the temporary directory to
On Fri, 23 Aug 2013, Bastien ROUCARIES wrote:
Find -print0
And replacing read by read -r -d $'\0' is safer but I do not know if it is
portable.
Or xargs but we need to fork for each file and we get the portability
problem of find print0.
What do you prefer ?
find -print0 is fine,
Hi,
On Mon, 26 Aug 2013, Guillem Jover wrote:
The files must not be moved from the old dir to the new symlink-to-dir,
otherwise dpkg will lose track of them wrt to their canonical path, and
And what about files which are not managed by dpkg?
And files of other packages which are not upgraded
Hi,
On Thu, 05 Dec 2013, Daniel Kahn Gillmor wrote:
dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/libstdc++.so.6 (used by debian/wpagui/usr/sbin/wpa_gui)
dh_shlibdeps: dpkg-shlibdeps -Tdebian/wpagui.substvars
debian/wpagui/usr/sbin/wpa_gui returned
On Mon, 23 Dec 2013, Guillem Jover wrote:
Doing this via a status fd would be nice[1] since we could then
implement more nice things like progress information (we'd then be able
to detect easily which dpkg-buildpackage's steps failed) without parsing
the full build output.
[1] The
On Mon, 23 Dec 2013, Guillem Jover wrote:
The problem is that something messes with dpkg's standard output and
error, and it fails when doing the fflush() and ferror() check on it
in m_output() I think. But this seems to be coming from something
lower than dpkg or apt, perhaps a change in
On Mon, 30 Dec 2013, Jakub Wilk wrote:
* Guillem Jover guil...@debian.org, 2013-12-30, 12:27:
I guess it's probably a good idea to switch the default, becuse I
assume most maintainers do more test builds than final ones.
ACK
And also, it should be friendly to non-maintainers who are just
Control: reassign -1 tiger 1:3.2.3-10
Control: retitle -1 /usr/lib/tiger/systems/Linux/2/deb_checkmd5sums hardcodes
path to dpkg-divert
On Mon, 13 Jan 2014, Yoric Kotchukov wrote:
Hello!
After upgrade dpkg-divert migrate from /usr/sbin to /usr/bin, tiger complain
about
Control: retitle -1 document how to un-ignore files ignored by default in 3.0
(native) and 3.0 (quilt)
On Wed, 15 Jan 2014, peter green wrote:
When attempting to build such a package using the 3.0 native format
the source package build and binary package builds will succeed, but
the source
Hi,
On Sat, 18 Jan 2014, peter green wrote:
Raphael Hertzog wrote:
So yes, *.a, *.la, *.o and *.so are ignored by default in native source
package
and this is is so for as long as I can remember.
Afaict if I leave a .so or similar file in the source tree (and
don't override anything
On Fri, 21 Feb 2014, Eugen Dedu wrote:
Sorry to ask again: why do these commands fail if no env var is set?
Because they need to know in which maintainer script they are called and
they need to know the package that they are acting on. Without this, they
can't do the work they're supposed to
Hi,
On Wed, 30 Apr 2014, Manoj Srivastava wrote:
Of the 73 packages that failed, 10 were due to a known
incompatibility, which has been fixed. About 20 or so were due to
various issues i the package, unrelated to this report. However, 40
packages failed to build due to the new make
Control: reassign -1 python-appdirs 1.3.0-1
Control: severity -1 serious
On Tue, 06 May 2014, Benjamin Drung wrote:
Uninstalling the package (and everything that depends on it :( ) and
reinstalling does work around the problem, and now the .egg-info item is a
directory.
This looks like a
Hi,
On Tue, 13 May 2014, Gerfried Fuchs wrote:
This also affects a cowbuilder chroot and ends up in its build logs.
Either it is needed, then it should be a Depends, or not, then it
shouldn't blabber about it and end up in build logs.
Yes, installing something in a pbuilder/cowbuilder
Hi,
On Mon, 04 Aug 2014, Norbert Preining wrote:
Umpf, not very convenient. Is there any particular reason for that?
Standardization. As you say it's a convenience feature that just makes it
more complicated to everybody else that righfully expects -p1 patches.
I often cherry pick from
Hi,
On Sat, 09 Aug 2014, Joey Hess wrote:
An added wrinkle is that -S doesn't build arch specific debs at all, of
course, but a responsible user of this new DAK feature will want to
build debs, lintian and test the locally, but not upload them.
I think this calls for more than a generic
Hi,
On Sat, 12 Jul 2014, Felix Berlakovich wrote:
I applied the patch from Vasily i. Redkin to version 1.17.10 (and moved
a redundant part into an own function). BTW his patch works great. I
did this in preparation for a possible threeway merge improvement. Is
there still any interest in
Hi,
On Thu, 28 Aug 2014, Niko Tyni wrote:
In the scope of just the source package, it seems possible for dpkg-source
to remember the latest timestamp it has extracted and notice if that's
newer than the debian/changelog timestamp.
dpkg-source delegates most of the extraction to tar so it
Hi,
On Thu, 18 Sep 2014, Joseph Herlant wrote:
I think the DpkgConffileHandling of the wiki would also be great as
it currently don't even mention that debian/package.maintscript file.
It's a wiki, you should have fixed it yourself. But in this case, it
already had a mention, I just extended
On Fri, 07 Nov 2014, Guillem Jover wrote:
I'm going to revert the commit above (only in 1.17.x, it will be kept
in 1.18.x), because it is very minimal, just reintroduces again an
unnecessary package queue stage, and such regression is acceptable if
it makes buggy bootstrappers work again. But
On Fri, 14 Nov 2014, Faheem Mitha wrote:
The subject line says it all. I noticed today that if the patches in
debian/patches are not applied, then
debuild clean
does not apply them, and if a patch is required to run clean
successfully, then clean fails. Included is the clean section
On Fri, 14 Nov 2014, Faheem Mitha wrote:
Hi Raphael,
Ok, if you don't think it is a bug, please close it.
I'll let Guillem do that if he agrees with me.
If you can take a moment, can you advise me what the correct approach to
handling this should be? Just make sure to push the patches
Hi,
On Fri, 21 Nov 2014, Stefan Fritsch wrote:
On Monday 17 November 2014 01:43:46, Guillem Jover wrote:
I've fixed this now locally by bumping the version for both symlink
commands to just 1.17.14, which avoids translation work, and
targetting 1.17.22.
Thanks. It seems a build-depends
On Sun, 11 Jan 2015, Andreas Beckmann wrote:
another case where a corruption could be left after removal is
* preinst/postinst creates a user and a statoverride
* prerm/postrm removes the user but leaves the statoverride
= statoverride file will be corrupted only after removal (purge?) of
On Tue, 26 Apr 2016, Holger Levsen wrote:
> Having done this, I checked my ~/.devscripts and found this:
>
> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us -I -i"
>
> Is this why?
Yes. -I and --tar-ignore in debian/source/options are cumulative.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support
Hi,
On Wed, 31 Aug 2016, Felipe Sateler wrote:
> I don't know what the correct workaround should be.
Just for the record, the attached patch is what we use in Kali
to work-around this problem. It works but it's not going to be merged in
Debian because we really want a fix at the overlayfs level
Hi,
On Wed, 31 Aug 2016, Felipe Sateler wrote:
> overlayfs does not support renaming directories when the directories
> live in the lower filesystem:
[...]
> Unfortunately this means that dpkg fails at least in the case where a
> directory is converted into a file: apt 1.3~rc2 moves
>
Control: tag -1 + patch
Control: severity -1 serious
Hi Guillem,
On Sun, 13 Nov 2016, Guillem Jover wrote:
> > The /usr merge violates core assumptions in dpkg-shlibdeps. The reason
> > that amd64 isn't broken is sheer luck.
> > /etc/ld.so.conf.d/x86_64-linux-gnu.conf lists /lib before /usr/lib,
Hello Guillem,
On Mon, 14 Nov 2016, Michael Biebl wrote:
> Just for the record: I can confirm it fixes the problem in dpkg-shlibdeps.
[...]
> Guillem, it would be great if you can upload a fixed dpkg soon.
A full week went by already. What's your plan?
I can offer to upload dpkg 1.18.15.1 to
On Mon, 21 Nov 2016, Guillem Jover wrote:
> Oh, and forgot to mention, this issue has been known for over 8
> months, and now there's this need to be pushy and rush things, etc.
> I certainly do not appreciate that.
I have not been involved in this project so I don't know its history
but #843073
Hi,
Now that some users enabled "usrmerge" it has become more important
that "dpkg -S" deals sensibly with symlinks. I have thus raised the
severity of this bug to important (following the discussion
with Helmut in #843073).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS:
Control: tag -1 + patch
Control: severity 134758 + important
I add the patch tag back because this bug is about "dpkg-shlibdeps" being
broken by usrmerge. Not about dpkg -S being broken. I agree that dpkg -S
ought to be fixed too... but this corresponds to bug #134758. I'm thus
raising the
Hi Helmut,
On Tue, 03 Jan 2017, Helmut Grohne wrote:
> No, because using binutils-multiarch is broken. Whenever a new
> architecture is brought up, binutils-multiarch lacks support for it.
Ok, that makes sense.
> > That would let us use objdump to inspect any library and let
> > dpkg-shlibdeps
Hi Helmut,
On Mon, 02 Jan 2017, Helmut Grohne wrote:
> while working on #843073, we agreed to merge Raphaël's patch on the
> provision that we would revert it if it causes breakage. Unfortunately,
> that actually happened. It breaks build cross compilers (stage3):
>
>
On Fri, 22 Nov 2019, Guillem Jover wrote:
> That still does not explain why this needs to be done outside the dpkg's
> execution context, though?
I don't know any point in dpkg's execution context where we are sure that
we will not install/remove other packages later on.
> Triggers right now
Hi,
On Wed, 20 Nov 2019, Guillem Jover wrote:
> > To achieve this in a more elegant way, could you possibly implement some
> > "dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or
> > something similar ?
>
> I'm not sure I understand why this is not done say via a trigger
>
On Wed, 18 Dec 2019, Guillem Jover wrote:
> > We could add hundreds of path-based triggers, one for each binary that we
> > reference in our desktop files but we would likely miss any path
> > change... and it would be a bit tedious to maintain.
>
> I checked the kali package, and the solutions
701 - 800 of 801 matches
Mail list logo
