On Fri, 09 Jun 2023, Marco d'Itri wrote:
> On Jun 08, Raphael Hertzog wrote:
>
> > In the same spirit, I'd like to throw an idea... could we decide that
> > base-files is the first package to be configured as part of the bootstrap
> > protocol and change base-fi
Hi,
On Wed, 17 May 2023, Helmut Grohne wrote:
> For completeness sake, there is one more entry in category 3: We can run
> the dynamic loader from its canonical location explicitly, so we'd
> modify maintainer scripts to start with:
>
> #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Hello,
On Tue, 02 May 2023, Helmut Grohne wrote:
> I think there is a caveat (whose severity I am unsure about): In order
> to rely on this (and on DEP 17), we will likely have versioned
> Pre-Depends on dpkg. Can we reasonably rule out the case where and old
> dpkg is running, unpacking a fixed
Hello,
On Wed, 26 Apr 2023, Simon Richter wrote:
> > This and /bin/sh is the kind of files I'd consider important. And then
> > upon thinking further it became more and more difficult for me to make
> > sense of the objection. On a merged system, we can just move that file
> > to its canonical
On Tue, 25 Apr 2023, Luca Boccassi wrote:
> Brilliant! Would never have thought of using divert like that.
+1 Nice trick.
> So, what work would need to happen to make this reality? Do we need
> tooling/scripts/build changes to support the divert scheme, or is it
> "simply" a matter of
Hello,
On Sat, 22 Apr 2023, Helmut Grohne wrote:
> This is looking at it from a performance point of view. Guillem also
> raised that this is changing the source of truth from the dpkg database
> to the actual filesystem, which Guillem considers wrong and I find that
> vaguely agreeable.
smcv
Hello,
I'd like to offer some food for thoughts on this issue.
>From what I have understood, Guillem would rather avoid committing
to a new public interface for this specific use-case, i.e. the
fact that the DEP is suggesting "dpkg --add-alias" is problematic
because that feature will be useless
Hello,
On Mon, 03 Apr 2023, Helmut Grohne wrote:
> Please consider it to be a piece of best
> intentions at reconciling feedback wherever I could. At the time of this
> writing it certainly is not consensus, but consensus is what I seek
> here. Without further ado, the full DEP text follows
On Thu, 03 Sep 2020, Niko Tyni wrote:
> > The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
> > code should fallback to Dpkg::Vendor::Debian and this works a few times
> > but after multiples calls, at some point it no longer works and the
> > require statement in the eval
On Thu, 03 Sep 2020, Niko Tyni wrote:
> > The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
> > code should fallback to Dpkg::Vendor::Debian and this works a few times
> > but after multiples calls, at some point it no longer works and the
> > require statement in the eval
On Sat, 02 May 2020, Scott Kitterman wrote:
> Personally, I don't see any real benefit of standardizing on (making up an
> example here) debian/.build over debian/build.
Same here. The arguments against debian/build are very weak. If we care
about a source package building a binary package named
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
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
>
Hello,
On Fri, 27 Apr 2018, Guillem Jover wrote:
> But in any case, I'm still open to data and opinions given that this
> is in the end a matter of trade-offs, so → request for comments. :)
I believe that the "zstd" compression format is providing an interesting
trade-off compared to other
On Tue, 13 Feb 2018, Julien Cristau wrote:
> On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> > I believe that we have had quite some testing already last time and I
> > would be surprised if we got many more RC bugs on dpkg that had to be fixed
> > on a short timeframe. I
On Mon, 12 Feb 2018, Ansgar Burchardt wrote:
> Guillem Jover writes:
> > In any case, I looked the other day into implementing the
> > --map-pathname option for dpkg-query, and I've got most of the code
> > ready. The problem is that this requires adding support for config
> > files and config
Hi,
sorry for the delay. I rarely look into this mailbox.
On Tue, 15 Aug 2017, Guillem Jover wrote:
> them quickly after that. Listing the amount of bouncing would also
> be nice, in a similar way how list.d.o does it, or even also sending
> the pre-warnings about possibly imminent
Hi Guillem,
On Fri, 04 Aug 2017, Guillem Jover wrote:
> On Fri, 2017-08-04 at 02:19:59 -, ow...@tracker.debian.org wrote:
> > The email debian-dpkg@lists.debian.org bounces too much, it has been
> > unsubscribed from the
> > Debian Package Tracker.
> > Here's the list of subscriptions which
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):
>
>
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
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
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
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,
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
>
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, 16 Sep 2015, Guillem Jover wrote:
> Thanks all! I'm going to push the attached patch. Hope the S-o-b are
> fine.
Sure, fine for me.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian:
Hello dear maintainer(s),
the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of dpkg:
https://security-tracker.debian.org/tracker/CVE-2015-0840
I had a quick look. The squeeze version of dpkg has a much more lax
parser, so the issue might
Hello everybody,
it's time to acknowledge that I don't have enough time and motivation for
dpkg (in particular since Guillem is still very upset about me, multiple
years afther the development of multiarch).
I unsubscribed from everything related to dpkg (including this list and
the PTS) and
Hello Michael,
I stepped down from dpkg development and
http://jenkins.grml.org/view/Debian/job/dpkg-test-binaries/
http://jenkins.grml.org/view/Debian/job/dpkg-test-source/
were mostly my playground.
They are now useless, feel free to remove everything
related to them.
Cheers,
--
Raphaël
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 Thu, 04 Dec 2014, Simon McVittie wrote:
On Thu, 04 Dec 2014 at 16:39:31 +0100, Niels Thykier wrote:
On 2014-12-04 09:11, Simon McVittie wrote:
[see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770627#70 for full
analysis]
If your interpretation is correct, then I am certainly not
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 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
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, 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
Hi,
On Mon, 03 Nov 2014, Sébastien POHER wrote:
- I think Weblate will fit for smaller translations (Debian Security
Annoucement and such), but dpkg is huge (+22K lines for man/po/fr.po)
and I don't see myself going from an untranslated chain to another by
clicking a hundred times;
There
Hi Guillem,
it would be nice if you could behave in a way so that I don't have the
feeling that I don't exist in the dpkg landscape for you.
FWIW (to the lurkers here) I approved Sébastien on the alioth project, I
recruited him as a French translator, and I informed Guillem about the
fact that I
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
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 Guillem,
On Fri, 15 Aug 2014, Guillem Jover wrote:
commit 59e6e1563a88f47d0011ee62bc3c7b763fb9ab4f
Author: Guillem Jover guil...@debian.org
Date: Fri Aug 15 15:26:53 2014 +0200
dpkg-shlibdeps: Do not unnecessarily interpolate strings
This mostly reverts commit
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 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 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 Mon, 02 Jun 2014, Aurelien Jarno wrote:
Alternatively, we can create an empty package called for example
multiarch-no-foreign, which is arch:any and Multi-arch: none. That way
all packages which should not be installed as foreign architecture can
depend on this one.
What do
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
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 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
Hi,
On Sun, 16 Mar 2014, Guillem Jover wrote:
@dpkg/apt maintainers: I thought triggers should be run *after* the
package is fully installed and only the order of the triggers is not
guaranteed?
W/o having looked into the details, this just seems like another
instance of #671711.
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 Thomas,
On Thu, 13 Feb 2014, Thomas Goirand wrote:
So I wonder, could dpkg-maintscript-helper be in another source package
than dpkg, so that it could be easily backported?
Even if it was part of another package, it would have strong versioned
dependencies against dpkg because this script
Hi,
On Fri, 14 Feb 2014, Thomas Goirand wrote:
Looking at the script, it seems *very* complicated and hard to get it
directly right. I believe I could write a much simpler version for my
own needs (with less features, probably), reading what's been done in
dpkg-maintscript-helper.
So,
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
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
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
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
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
Hi,
On Thu, 05 Dec 2013, Roland Stigge wrote:
To implement a correct fix, Ben asked for a decision by dpkg
maintainers, FTP team and policy. Basically, the question is if
I think Guillem's position is rather clear, since he filed #718330
requesting support of data.tar in APT. I also agree with
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
Hi,
On Wed, 04 Dec 2013, Guillem Jover wrote:
There's a thing I'm not entirely sold on yet, and will probably rethink
it once I wake up, that's the name of the output field, currently
Build-Profiles, but I'm pondering on Built-For-Profiles for example.
+1 for something else than
Hi Guillem,
I was about to file a bug against clang-3.3 but what I discovered looked
like more a bug in dpkg. It's probably related to the recent optimizations
that concerns management of file lists.
In today's dist-upgrade:
Unpacking llvm-3.3 (1:3.3-13) over (1:3.3-12) ...
Preparing to unpack
On Thu, 21 Nov 2013, Raphael Hertzog wrote:
I was about to file a bug against clang-3.3 but what I discovered looked
like more a bug in dpkg. It's probably related to the recent optimizations
that concerns management of file lists.
[...]
I have created a minimal test case for this, it's
Hi,
I just tried dpkg --verify as normal user and I got this:
$ LANG=C dpkg --verify
dpkg: warning: exim4-config: unable to open /etc/exim4/passwd.client for hash:
Permission denied
Erreur de segmentation
(That's a segfault in French)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover
On Thu, 21 Nov 2013, Guillem Jover wrote:
Ok, problem due to variables declared in the wrong scope, fixed
locally, will push later today.
Thanks, will you also push the test I created or shall I do it?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's
On Sun, 27 Oct 2013, Niels Thykier wrote:
On 2013-10-27 05:22, Guillem Jover wrote:
dpkg-buildpackage: Honor new DEB_SIGN_KEYID environment variable
Could you be convinced to change this to DEBSIGN_KEYID, which is the
name that e.g. debsign uses? I have a feeling that if debsign and
Hi,
I just saw this on my system where the package cpputest is installed:
$ LANG=C dpkg -l /dev/null
dpkg-query: error: cannot convert multibyte sequence '— main package
CppUTest is a C/C++ based unit xUnit test framework for unit testing and
for test-driving your code. It is written in C++
Hi,
On Sat, 21 Sep 2013, Guillem Jover wrote:
I guess there are no mirrors of those mboxes on non-restricted hosts?
Otherwise having access to those would be very helpful.
I should have them locally via the PTS. Let me know when things are fixed
and what's the commit interval that I should
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
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 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
Hello,
On Sun, 11 Aug 2013, Bastien ROUCARIES wrote:
I wish to contribute to dpkg particularly contributing to #583585
Where should I begin ?
I think that you have found the required answers yourself. As a general
rule, we have documented everything that is important on this page:
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
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 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
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
Hello,
FYI I have switched the script that generates commit notices to something
better: https://github.com/mhagger/git-multimail
- One thread per refchange per push
- Commit mails have the short description in the subject and they are
numbered (within the push)
For now, it runs out of my
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
On Mon, 22 Jul 2013, Charles Plessy wrote:
Nevertheless, please let me try to refocus on the question of whether
the Policy can be updated or not.
I believe we can update the policy whatever the status of this specific
bug.
Here is what is written in the Policy about postinst configure:
On Sat, 20 Jul 2013, Charles Plessy wrote:
Can you explain what the bug is and what the correction will be ? Because I
The bug is that triggers are run while the dependencies of the triggered
package are not satisfied. The fix is not to do that and wait until those
dependencies are satisfied
Hi,
On Thu, 18 Jul 2013, Charles Plessy wrote:
After reading #671711 and /usr/share/doc/dpkg-dev/triggers.txt.gz, my
impression is that a package can not become Unpacked and keep a list of
pending triggers, because of the following statements in triggers.txt:
1) Pending triggers are marked
Hi,
On Wed, 17 Jul 2013, Charles Plessy wrote:
About the problem of triggers being called with Depends not satisfied, can you
give more explanations or suggest some text for the warning ? Would it be
enough to add a notice that the triggered postinst script may be called when
the package is
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 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
Hi,
On Thu, 16 May 2013, Charles Plessy wrote:
Guillem recently posted on debian-devel about noawait triggers, and I would
like to send a link to the patch to the Policy once it gets futher
proof-reading and seconds. Or if it takes time, shall I point to this bug log
on -devel ?
I don't see
Hi,
On Wed, 15 May 2013, Helmut Grohne wrote:
This new Extends field would imply that all meta-data (including other
missing control fields) is shared with the bar package and at build-time
it transparently gets a supplementary Depends: bar (= foo-version) but
the .deb would not have any
Hi,
On Mon, 13 May 2013, Guillem Jover wrote:
The binNMU issue entails two “sub-problems”. The first is the one
introduced by different entries in binNMUs on multiple architectures.
The other is the unmatched versions for possible out-of-step binNMU
versions.
Personally I see very clearly
Hi,
On Tue, 14 May 2013, Игорь Пашев wrote:
2013/5/14 Raphael Hertzog hert...@debian.org:
But ansgar's objection about the duplication of the changelog in multiple
.deb when it used to be shared via a symlink also makes sense. As does the
fact that there's currently no way to not install
Hi,
On Sun, 12 May 2013, Charles Plessy wrote:
p
The tt*-noawait/tt directives should be used unless the
packages awaiting triggers can not satisfy ttDepends/tt
relationships until the triggers have been processed.
In that case,
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
On Tue, 23 Apr 2013, Johannes Schauer wrote:
Raphael, your argument is very convincing and I am now even more in favour of
Ian's proposal, thanks! Can you list some of those other use cases you said
you
can imagine? Maybe that helps to better decide upon the following:
I gave two already. I
On Fri, 19 Apr 2013, Guillem Jover wrote:
The following commit has been merged in the master branch:
commit 26a4d1df1119da0a8601b27198086086f9f3249f
Author: Guillem Jover guil...@debian.org
Date: Sat Dec 29 23:59:06 2012 +0100
Use just 'return' instead of 'return undef' in perl code
On Tue, 16 Apr 2013, Wookey wrote:
So in general it seems like a good idea to me for dpkg shlibs to check
multiarch paths at build time if it doesn't already, because it'll
need to soon. I am of course happy to hear of reasons why that will
break things and we should not do it yet.
All of
Hi Charles,
On Fri, 15 Mar 2013, Charles Plessy wrote:
I am still seeking comments for the attached patch, that describes Dpkg
triggers.
Here are my comments. There's quite a bit of work left.
From 6a7fd0e49cb8dbd025771feb95c2dcafb408c1b8 Mon Sep 17 00:00:00 2001
From: Charles Plessy
1 - 100 of 1794 matches
Mail list logo
