Hi!
On Thu, 2025-04-24 at 13:16:02 +0200, Guillem Jover wrote:
> On Tue, 2025-03-18 at 07:28:11 +0100, Sebastian Krzyszkowiak wrote:
> > PureOS is currently carrying this as its only patch to dpkg package.
> > Moving it upstream would make things so much more convenient, so I'm
> > putting it here
Hi!
On Mon, 2025-07-21 at 11:41:51 +0200, Guillem Jover wrote:
> On Sun, 2025-07-20 at 09:45:37 +0200, Niels Thykier wrote:
> > I have cloned and reassign a bug for `dpkg` to make it announce
> > postinst abort-upgrade, so this becomes less of a problem in the
> > future. @Guillem: Concretely, the
Hi!
On Fri, 2025-07-11 at 23:58:45 +0200, Helmut Grohne wrote:
> Hi Guillem (and Raphaël),
>
> On Wed, Jul 09, 2025 at 02:11:06PM +0200, Helmut Grohne wrote:
> > https://debusine.debian.net/debian/developers/work-request/119889/ is a
> > dpkg workflow and a gcc one shall go later.
>
> The gcc-1
Hi!
On Sun, 2025-07-20 at 09:45:37 +0200, Niels Thykier wrote:
> I have cloned and reassign a bug for `dpkg` to make it announce
> postinst abort-upgrade, so this becomes less of a problem in the
> future. @Guillem: Concretely, the issue is we were only informed
> about `preinst` failing but in re
clone 1109499 -1
clone 1109499 -2
retitle 1109499 bacula-common: preinst intentionally breaks upgrade
retitle -1 dpkg: Silent on invoking postinst abort-upgrade
reassign -1 dpkg
# Annoying to debug but not RC in itself
severity -1 important
retitle -2 bacula-common: Silent when aborting the upgrad
On Sat, Jul 19, 2025 at 11:06:17AM +0200, Niels Thykier wrote:
> FWIW, I checked the stable version of bacula-common and it has the same
> story. The `systemd-tmpfiles` call only appears in the `postinst`, so there
> is no way I can find that a `bacula-common.preinst` call would trigger
> `systemd-
Chris Hofstaedtler:
[...]
The preinst script should be this:
https://binarycontrol.debian.net/cache/unstable/bacula-common/preinst
which does not invoke systemd-tmpfiles.
I wonder whats really happening. Is dpkg invoking the new postinst
(at postinst time), but putting "pre-installation" into
On Sat, Jul 19, 2025 at 10:10:22AM +0200, Lucas Nussbaum wrote:
> The error is:
> > Preparing to unpack .../bacula-common_15.0.3-3_amd64.deb ...
> > dpkg: error processing archive
> > /var/cache/apt/archives/bacula-common_15.0.3-3_amd64.deb (--unpack):
> > new bacula-common package pre-installati
Hi Guillem (and Raphaël),
On Wed, Jul 09, 2025 at 02:11:06PM +0200, Helmut Grohne wrote:
> https://debusine.debian.net/debian/developers/work-request/119889/ is a
> dpkg workflow and a gcc one shall go later.
The gcc-14-cross workflow is:
https://debusine.debian.net/debian/developers/work-reque
Hi Guillem and Raphaël,
thank you two for jumping into it right away.
On Wed, Jul 09, 2025 at 01:26:27PM +0200, Guillem Jover wrote:
> On Wed, 2025-07-09 at 12:39:12 +0200, Raphael Hertzog wrote:
> > On Wed, 09 Jul 2025, Helmut Grohne wrote:
> > So this part was added as part of the discussion in
Hi!
On Wed, 2025-07-09 at 12:39:12 +0200, Raphael Hertzog wrote:
> On Wed, 09 Jul 2025, Helmut Grohne wrote:
> > In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following
> > code:
> [...]
> > It is not clear to us, why that first branch exists. It was originally
> > added by Raphaël
Hi Helmut,
On Wed, 09 Jul 2025, Helmut Grohne wrote:
> In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following
> code:
[...]
> It is not clear to us, why that first branch exists. It was originally
> added by Raphaël in support of cross compilation and later changed a
> couple of t
Hi!
On Mon, 2025-05-19 at 09:58:07 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-05-19 at 09:49 +0200, Guillem Jover wrote:
> > sqv is not available on all ports, so that would make it fail on all
> > those ports then. I think a versioned build-conflicts would have been
> > better (but I
Hi
what can I do to fix this on linux mint?
Re: dpkg was interrupted, you must MANUALLY run dpkg configure _a to
correct the problem
Samuel Thibault, le lun. 19 mai 2025 10:35:18 +0200, a ecrit:
> Guillem Jover, le lun. 19 mai 2025 10:20:06 +0200, a ecrit:
> > On Mon, 2025-05-19 at 10:03:02 +0200, Samuel Thibault wrote:
> > > John Paul Adrian Glaubitz, le lun. 19 mai 2025 09:58:07 +0200, a ecrit:
> > > > > If getting a new sqv v
Guillem Jover, le lun. 19 mai 2025 10:20:06 +0200, a ecrit:
> On Mon, 2025-05-19 at 10:03:02 +0200, Samuel Thibault wrote:
> > John Paul Adrian Glaubitz, le lun. 19 mai 2025 09:58:07 +0200, a ecrit:
> > > > If getting a new sqv version built is going to be too hard or time
> > > > consuming for now
Hello,
John Paul Adrian Glaubitz, le lun. 19 mai 2025 09:58:07 +0200, a ecrit:
> > If getting a new sqv version built is going to be too hard or time
> > consuming for now, then perhaps removing the sqv binary packages from
> > the port (like it's the state for several other ports) is the quickest
Hi,
On Mon, 2025-05-19 at 09:49 +0200, Guillem Jover wrote:
> sqv is not available on all ports, so that would make it fail on all
> those ports then. I think a versioned build-conflicts would have been
> better (but I didn't think there would be outdated versions), but that
> would then make it u
Hi!
On Mon, 2025-05-19 at 09:28:04 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-05-19 at 08:31 +0200, Guillem Jover wrote:
> > The just uploaded dpkg, got support for sqv, which is now installed by
> > default on minimal chroots due to apt pulling it in on some
> > architectures (instead
Hi Guillem,
On Mon, 2025-05-19 at 08:31 +0200, Guillem Jover wrote:
> The just uploaded dpkg, got support for sqv, which is now installed by
> default on minimal chroots due to apt pulling it in on some
> architectures (instead of gpgv). But this support relies on new interfaces
> added in sqv 1.3
Hi!
On Tue, 2025-03-18 at 07:28:11 +0100, Sebastian Krzyszkowiak wrote:
> PureOS is currently carrying this as its only patch to dpkg package.
> Moving it upstream would make things so much more convenient, so I'm
> putting it here for your consideration :-)
Thanks! I queued this some patch some
Hi!
On Thu, 2025-04-24 at 10:44:41 +0900, Simon Richter wrote:
> ---
> lib/compat/getent.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/compat/getent.c b/lib/compat/getent.c
> index e5c55a5f9..a7bb06328 100644
> --- a/lib/compat/getent.c
> +++ b/lib/compat/getent.c
> @@ -212,6
Hi,
I'm always more in favor of removing old cruft than adding complicated wording
to document old cruft forever.
Here there could be a compromise that (some of...) the existing usage
are grandfathered,
like the provision in Policy 4.7.2 for /usr/games/{thing} that
conflicts with /usr/games/{thin
like a good
idea to someone in the past.
The fact that it's surprising is why the team has been phasing out this
practice, in favour of maintaining the Uploaders list by hand like most
other packages do. But I'm reasonably confident that not every package
that had the generated U
Hello Simon,
thank you for the insights.
(I've tried to trim some context, not sure how successful I was.)
* Simon McVittie [250408 11:33]:
On Mon, 07 Apr 2025 at 14:08:23 +0200, Chris Hofstaedtler wrote:
[1] https://ftp-master.debian.org/REJECT-FAQ.html "debian/control breakage #2"
I am n
On Mon, 07 Apr 2025 at 14:08:23 +0200, Chris Hofstaedtler wrote:
it appears that currently there is no requirement for d/control to
stay the same before and after a build. However, many things require
this to be the case, and ftp-master also requires this in their
reject-faq [1].
[1] https://
On Sun, Mar 09, 2025 at 01:18:21PM +0100, Niels Thykier wrote:
>Hi,
>
>Here is one final update as the freeze is about to start.
>
> * First and foremost, I consider the transition as over, since there
> are no more packages left that are actionable by me nor is there
> any pending reason to re
Hi,
Here is one final update as the freeze is about to start.
* First and foremost, I consider the transition as over, since there
are no more packages left that are actionable by me nor is there
any pending reason to revert the change.
* Only three known issues remain as affecting tes
Paul Gevers:
Hi Niels,
On 14-01-2025 10:46, Niels Thykier wrote:
Another update on the transition
One month further. What's the current status?
Paul
Hi,
Key package-wise, we are down to 5 packages affecting testing:
* d-i + shim + its helper: All which are not actionable to me as
st
Hi Niels,
On 14-01-2025 10:46, Niels Thykier wrote:
Another update on the transition
One month further. What's the current status?
Paul
PS: I happen to track wordpress, which happened to be dropped from
trixie because of this transition (it's on its way back). It's exactly
those kind of re
Paul Gevers:
Hi Niels,
Hi Paul
Thanks for the feedback.
On 29-12-2024 11:12, Niels Thykier wrote:
* Do you think it is feasible for us to do this change in Trixie and,
if so, do you have any preferences for timing or bug counts that we
should keep in mind?
If you are committing
Hi Niels,
On 29-12-2024 11:12, Niels Thykier wrote:
* Do you think it is feasible for us to do this change in Trixie and,
if so, do you have any preferences for timing or bug counts that we
should keep in mind?
If you are committing yourself to solve the issues (as you say, one line
Hi!
On Sun, 2024-12-15 at 09:27:06 +0100, Niels Thykier wrote:
> Historically, if you omitted `Priority` and `Section` from your
> package, `dpkg` would warn and use `-` or `unknown` as placeholder
> when it absolutely needed a value for these fields in the `.dsc` and
> the `.changes` file. The re
Niels Thykier:
Hi Release team,
Hi,
Please CC me OR debian-dpkg@l.d.o on replies. I am not subscribed to
d-release.
[...]
With this in mind:
* Do you think it is feasible for us to do this change in Trixie and,
if so, do you have any preferences for timing or bug counts that we
Hi!
On Sun, 2024-12-08 at 13:59:53 +0900, Simon Richter wrote:
> Also, while the entire thing is not yet ready for merging, getting feedback
> on some commits might be useful still to see if I'm going the right way at
> all here.
I've not looked into the branch, because I'm assuming this is still
Hi!
On Fri, 2024-12-13 at 11:22:59 +0100, jspri...@debian.org wrote:
> We found a unit test in the gcc package that killed dpkg-buildpackage
> (#1089007). The error message was non obvious, so this adds a warning in
> case someone stumbles of over this again.
As discussed on IRC when this was sen
Daniel Baumann:
Hi,
both sound good (dropping mandatory priority is nice and consistent,
fixing unknown section behaviour too), thanks!
Thanks for the feedback. :)
ideally these changes would be in dpkg in trixie, but maintainers would
start dropping priority fields *after* trixie so that f
Hi,
both sound good (dropping mandatory priority is nice and consistent,
fixing unknown section behaviour too), thanks!
ideally these changes would be in dpkg in trixie, but maintainers would
start dropping priority fields *after* trixie so that for backports we
woudn't need to add it back en mas
Hi,
On 12/13/24 19:22, jspri...@debian.org wrote:
+use sigtrap 'handler' => \&sig_handler, 'normal-signals';
This only handles HUP, INT, PIPE, TERM -- signals that I would expect do
not indicate a problem in the package itself in most of the cases, and
that I *do* want to abort the package
Hi,
Let me plop in right into this discussion with no general solution and
more things to think about. For the context I'm packaging Java things,
and Java has historically been notoriously bad at guessing how much
memory it could actually use on a given system. I'm not sure things are
much be
Hi!
On Thu, 2024-12-05 at 09:23:24 +0100, Helmut Grohne wrote:
> On Wed, Dec 04, 2024 at 02:03:29PM +0100, Guillem Jover wrote:
> > On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote:
> > > For one thing, I propose extending debhelper to provide
> > > --min-ram-per-parallel-core as that see
Hi Guillem and others,
Thanks for your extensive reply and the followup clarifying the
inside-out and outside-in distinction.
On Wed, Dec 04, 2024 at 02:03:29PM +0100, Guillem Jover wrote:
> On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote:
> > I think this demonstrates that we probably
Hi!
On Wed, 2024-12-04 at 14:37:45 +, Stefano Rivera wrote:
> Hi Guillem (2024.12.04_13:03:29_+)
> > > Are there other layers that could reasonably be used to implement a more
> > > general form of parallelism limiting based on system RAM? Ideally, we'd
> > > consolidate these implementati
Hi Guillem (2024.12.04_13:03:29_+)
> > Are there other layers that could reasonably be used to implement a more
> > general form of parallelism limiting based on system RAM? Ideally, we'd
> > consolidate these implementations into fewer places.
>
> I think adding this in dpkg-buildpackage itse
Hi!
On Wed, 2024-12-04 at 14:03:30 +0100, Guillem Jover wrote:
> On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote:
> > Are there other layers that could reasonably be used to implement a more
> > general form of parallelism limiting based on system RAM? Ideally, we'd
> > consolidate these
Hi!
On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote:
> I am one of those who builds a lot of different packages with different
> requirements and found that picking a good parallel=... value in
> DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go
> too high and you
Niels Thykier writes:
> # The bug template used
>
> Severity: important
> User: ni...@thykier.net
> Usertags: rrr-no-as-default-issue
>
> Dear maintainer,
>
> During a test rebuild for building packages "Rules-Requires-Root: no" as
^
minor point, but a
On 2024-11-29 11:08 +0100, Niels Thykier wrote:
Lots of good stuff...
My minor contribution is to note a typo/grammaro in the default bug
text/template:
>The primary reason why this was such a small issue where:
Should be:
The primary reasons why this was such a small issue were:
(or may
Helmut Grohne:
Hi Guillem and other developers,
I am one of those who builds a lot of different packages with different
requirements and found that picking a good parallel=... value in
DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go
too high and you swap until the OOM ki
On Mon, Nov 25, 2024 at 06:59:49PM -0800, Otto Kekäläinen wrote:
> Source: python-apt
> Version: 2.9.1
> Severity: serious
>
> Seems the latest version of python-apt has some serious regressions as
> https://tracker.debian.org/pkg/python-apt shows wide-spread
> autopkgtest failures.
>
> In a clea
Le mardi 26 novembre 2024, 00:29:40 UTC Guillem Jover a écrit :
> Hi!
>
> On Sun, 2024-11-24 at 16:09:42 +, Bastien Roucariès wrote:
> > Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :
> > > I plan to implement freestanding architecture specification.
> > > Following Tou
Hi!
On Sun, 2024-11-24 at 16:09:42 +, Bastien Roucariès wrote:
> Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :
> > I plan to implement freestanding architecture specification.
> > Following Toulouse debian mini debconf and javascript presentation it will
> > be really
Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :
Hi
This the patch I plan to debian arch
Could you cross check then I will add arch to config.guess
> Hi,
>
> I plan to implement freestanding architecture specification.
> Following Toulouse debian mini debconf and javascript
Chris,
Thanks for including me in this.
On Sat, Nov 16, 2024 at 03:06:32PM +0100, Chris Hofstaedtler wrote:
> It is still unclear to me how to tell dpkg that the files moved
> between packages and it should not just delete them.
Nor me. AFAIK it is not possible at the moment. But it would be a u
Hi Guillem,
Did you actually ever apply this patch? I assumed it would appear in a
new dpkg release given your previous email but looking at the dpkg git
branch it seems it was never applied? This is rather unfortunate as I
was hoping to have this issue fixed by now.
Cheers,
Daan
On Sat, 8 Apr
Hi,
Sebastian Ramacher (2024-11-02):
> Dear toolchain, debian-installer, and image maintainers,
>
> We, as the release team, are aware that we are late with the
> announcement of the freeze timeline for trixie. After some internal
> discussions on how we want to handle the freeze for trixie base
Stefano Rivera writes:
> Should we expand this to include some of these new mechanisms?
> Things brought up in the debian-python thread include:
> 1. sigstore https://docs.sigstore.dev/
> 2. ssh signatures
> 3. signify https://man.openbsd.org/signify.1
+1
I believe all signatures we trust shoul
On 2024-10-05 03:32, Guillem Jover wrote:
> For an example of the activity that is going on in the OpenPGP ecosystem,
> here's a list of some of the non-GnuPG implementations already present
> in Debian, by programming language:
Thanks for the list! I was aware of some of them, but not all.
> *
default.
> (Not to mention that these are not even yet in Debian. :)
We can take a slower approach and not include support in build-essential
chroots for these newer schemes. Re-evaluate later, if one of them
really blows up in popularity.
And of course, we should probably just start with uscan,
Hi!
On Fri, 2024-10-04 at 18:21:01 +, Stefano Rivera wrote:
> Picking up a thread that started on debian-pyt...@lists.debian.org:
> https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea
>
> Upstreams that care about supply chain security have been building
> mechanisms to authenti
* Stefano Rivera: " Alternative signature mechanisms for upstream source
verification" (Fri, 4 Oct 2024 18:21:01 +):
[...]
> Should we expand this to include some of these new mechanisms?
> Things brought up in the debian-python thread include:
> 1. sigstore https://docs.sigstore.dev/
> 2.
On Sat, 2024-09-28 at 08:22 +0200, John Paul Adrian Glaubitz wrote:
> > > Is there a way to tune lzma such that it reduces memory consumption in
> > > this case?
> >
> > You should be able to globally reduce the amount of threads used with
> > the DPKG_DEB_THREADS_MAX envvar (as the --threads-max
Hi Guillem,
On Thu, 2024-09-26 at 13:20 +0200, Guillem Jover wrote:
> On Thu, 2024-09-26 at 10:31:55 +0200, John Paul Adrian Glaubitz wrote:
> > I'm using qemu-user with a Debian unstable sh4 chroot on a 40-core Xeon
> > machine
> > and running dpkg-deb fails with the same issue reported in #8465
Hi Guillem,
On Thu, 2024-09-26 at 13:20 +0200, Guillem Jover wrote:
> > dpkg-deb: building package 'gcc-snapshot' in
> > '../gcc-snapshot_20240922-1+sh4.1_sh4.deb'.
> > dpkg-deb: building package 'gcc-snapshot-dbgsym' in
> > '../gcc-snapshot-dbgsym_20240922-1+sh4.1_sh4.deb'.
> > dpkg-deb (subpro
Hi!
On Thu, 2024-09-26 at 10:31:55 +0200, John Paul Adrian Glaubitz wrote:
> I'm using qemu-user with a Debian unstable sh4 chroot on a 40-core Xeon
> machine
> and running dpkg-deb fails with the same issue reported in #846564 [1]:
>
> dpkg-deb: building package 'gcc-snapshot' in
> '../gcc-sna
Hi!
On Fri, 2024-09-13 at 09:34:17 +0800, Mix wrote:
> This commit introduces a new `close_all_fds` function in s-s-d to close all
> file
> descriptors prior to starting a new process. The function leverages the
> `close_range` system call if it is supported (available in glibc >= 2.34 and
> kern
Guillem Jover:
Hi!
On Thu, 2024-02-22 at 12:10:06 +0100, Niels Thykier wrote:
Package: debian-policy
Severity: wishlist
While the parser is technically correct given the Policy description above,
I cannot see any case where this is a desirable outcome. Instead, I think we
should classify thi
Hi!
On Thu, 2024-02-22 at 12:10:06 +0100, Niels Thykier wrote:
> Package: debian-policy
> Severity: wishlist
> While the parser is technically correct given the Policy description above,
> I cannot see any case where this is a desirable outcome. Instead, I think we
> should classify this as a syn
reassign 1076924 dpkg-dev
affects 1076924 + src:sendip
thanks
Hello Guillem et al.
El 8/8/24 a las 11:54, Jonathan McDowell escribió:
On Wed, Jul 24, 2024 at 12:49:47PM +0200, Santiago Vila wrote:
Package: src:sendip
Version: 2.6-1
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebu
Hi,
[moving to our discussions list]
Le mercredi 31 juillet 2024, 07:02:40 CEST nicolas.bouleng...@free.fr a écrit :
> Hello.
>
> Several KDE packages expand the dpkg_late_eval macro defined in
> /usr/share/dpkg/*.mk.
>
> https://codesearch.debian.net/search?q=dpkg_late_eval+file%3Adebian%2Frul
Hello Guilllem,
Am Tue, Jul 30, 2024 at 07:10:57AM +0200 schrieb Guillem Jover:
> On Mon, 2024-07-29 at 10:29:05 +, Helge Kreutzmann wrote:
> > while working on the German translation, I spotted some potential
> > errors, could you review them?
> >
> > scripts/dpkg-gencontrol.pl
> > " -O[]
Hi!
On Mon, 2024-07-29 at 10:29:05 +, Helge Kreutzmann wrote:
> while working on the German translation, I spotted some potential
> errors, could you review them?
>
> scripts/dpkg-gencontrol.pl
> " -O[] write to stdout (or ), not .../DEBIAN/"
> reall 3 (three) dots?
Yes, this
Hi,
On 7/29/24 17:27, Simon Richter wrote:
Do I need to do anything special to get the current view, or should
libdpkg provide a current view in any case?
Nevermind, the modstatdb_open() call got lost in a rebase. Oof.
Simon
Hi James,
Quoting James McCoy (2024-07-26 19:48:52)
> Nothing has changed in the packaging since it last successfully built, so I
> used debbisect to narrow down the problem to the dpkg 1.22.7 upload.
you are now (to my knowledge) the second user of debbisect. Could you share
your debbisect invoc
On Wed, Jul 24, 2024 at 12:50:20PM GMT, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [...]
> debian/rules binary
> dh binary
>dh_update_autotools_config
onceptually thorny. I'm vaguely aware of the different
supported source package formats, from having read the man page numerous
times, and also how dpkg-source can integrate with Git in some
workflows. But I never thought any of that would be relevant for this
contribution.
>> To recap,
nded up never being delivered.
(Also source package formats have become something of a contentious
topic, and it feels sometimes a bit demotivating to work on these.)
> To recap, this option enables (re)building a source package without cross-
> checking against the orig tarball, in scenarios
Hi!
On Sun, 2024-07-07 at 14:34:11 +0200, Bernhard R. Link wrote:
> Without this patch The C function pkg_name_is_illegal still allows
> upper case characters und underscores in packages names.
>
> This especially causes dpkg-deb to still be able to create packages
> with upper case characters in
Hi,
On 6/12/24 11:54, Guillem Jover wrote:
This is needed to run the tests during an out-of-tree build
I guess this is for the functional test suite? What runes are you
using to run it out-of-tree?
$ make installtest DPKG_BUILDTREE=/tmp/dpkg
I also have an evil bash script that sets up a
Hi!
On Sat, 2024-06-08 at 11:21:36 +0200, Simon Richter wrote:
> This is needed to run the tests during an out-of-tree build
I guess this is for the functional test suite? What runes are you
using to run it out-of-tree?
Thanks,
Guillem
Hi!
On Fri, 2024-06-07 at 11:40:17 +0900, Simon Richter wrote:
> Builds on Salsa terminate with
>
> PO4A man.stamp
> Undefined subroutine &Locale::Po4a::Pod::dgettext called at
> /usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21.
>
> I might investigate later, but if someone
Hi!
On Tue, 2024-04-23 at 07:51:36 +0200, Helmut Grohne wrote:
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > Is the only workaround dropping Ma:same here ?
>
> I see very little alternatives. We must choose:
>
> * Do not combine M-A:same + Provides: foo + Breaks: foo.
>
Hi!
On Fri, 2024-06-07 at 02:01:34 +0900, Simon Richter wrote:
> ---
> lib/dpkg/varbuf.h | 1 +
Ah, thanks! I've gone over all other headers and added missing
stdbool.h to avoid implicit inclusions via implementation details.
Thanks,
Guillem
"J.J. Martzki" writes:
> Package 'libnuma1' is built from numactl, and there seems no 'libnuma'
> exists. Why does it named as 'libnuma1' rather than 'libnuma'?
Shared library packages should be named after the library SONAME, which
generally includes a version (as it does here). See:
https://
On Tue, 7 May 2024 at 01:20, Guillem Jover wrote:
> On Sat, 2024-05-04 at 01:07:59 +0200, Matthias Klose wrote:
> > On 03.05.24 11:27, Julian Andres Klode wrote:
> > > On Wed, Sep 06, 2023 at 11:27:02AM +0200, Guillem Jover wrote:
> > > > Some of the above problems could perhaps be avoided if we
On Sat, 2024-05-04 at 01:07:59 +0200, Matthias Klose wrote:
> On 03.05.24 11:27, Julian Andres Klode wrote:
> > On Wed, Sep 06, 2023 at 11:27:02AM +0200, Guillem Jover wrote:
> > > Some of the above problems could perhaps be avoided if we introduced
> > > a concept of architecture aliases/ISAs (sim
On 03.05.24 11:27, Julian Andres Klode wrote:
On Wed, Sep 06, 2023 at 11:27:02AM +0200, Guillem Jover wrote:
Hi!
On Fri, 2023-09-01 at 08:43:55 +1200, Michael Hudson-Doyle wrote:
Recently the topic of exploiting newer instructions without dropping
support for older machines has come up several
On Wed, Sep 06, 2023 at 11:27:02AM +0200, Guillem Jover wrote:
> Hi!
>
> On Fri, 2023-09-01 at 08:43:55 +1200, Michael Hudson-Doyle wrote:
> > Recently the topic of exploiting newer instructions without dropping
> > support for older machines has come up several times inside Ubuntu
> > engineering
Hi!
* Guillem Jover [Fri Apr 26, 2024 at 09:57:09AM +0200]:
> On Thu, 2024-03-14 at 00:19:09 +0100, Alexandre Detiste wrote:
> > Le sam. 9 mars 2024 à 18:29, Guillem Jover a écrit :
> > > The grml.org project has been hosting Jenkins jobs for dpkg for a long
> > > time now, as the very initial C
Hi!
On Thu, 2024-03-14 at 00:19:09 +0100, Alexandre Detiste wrote:
> Le sam. 9 mars 2024 à 18:29, Guillem Jover a écrit :
> > The grml.org project has been hosting Jenkins jobs for dpkg for a long
> > time now, as the very initial CI we had. The jobs also generate a repo
> > so that people can ru
On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote:
> Hi Matthias,
>
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > This is the same situation as in #1040477. This is an issue wrt how we
> > generate the semvers. I image rust-proc-macro-crate-1 would pose the sam
Hi Matthias,
On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> This is the same situation as in #1040477. This is an issue wrt how we
> generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> problem. Quoting you from 1040477:
Right!
> Is the only workaround
Hi Guillem,
On 3/20/24 08:59, Guillem Jover wrote:
Thanks! I ended up including this unconditionally (also because we are
not explicitly checking for this header which should always be there,
and if something else is checking for it, that would be an internal
implementation detail that might ch
Hi!
Thanks for the patch!
I was playing with this the other day, and slightly simplified the patch
as the one attached. But then I wondered whether this makes sense at all,
given that the test suite should be able to run with the leak sanitizer
support, which I've just fixed so that it does not a
Hi!
On Mon, 2024-03-18 at 13:14:14 +0900, Simon Richter wrote:
> On 3/18/24 01:28, Guillem Jover wrote:
> > Attached is what I had, which I've polished a bit more now. Will
> > include in my next push.
>
> Nice, will rebase my branch on top of that. The new file probably needs to
> be added to po
Hi!
On Tue, 2024-03-19 at 23:48:00 +0900, Simon Richter wrote:
> diff --git a/lib/compat/strnlen.c b/lib/compat/strnlen.c
> index d02bb4bbd..6a7eb0454 100644
> --- a/lib/compat/strnlen.c
> +++ b/lib/compat/strnlen.c
> @@ -22,6 +22,10 @@
>
> #include "compat.h"
>
> +#ifdef HAVE_STRING_H
> +# i
Hi!
Thanks! I ended up just removing the check for this function. Now in
git main.
Regards,
Guillem
Hi Guillem,
On 3/18/24 01:28, Guillem Jover wrote:
Attached is what I had, which I've polished a bit more now. Will
include in my next push.
Nice, will rebase my branch on top of that. The new file probably needs
to be added to po/POTFILES.in as well, since it contains translatable
strings.
Hi Simon and Simon,
On Sun, Mar 17, 2024 at 12:08:21PM +, Simon McVittie wrote:
> On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote:
> > When /bin is a symlink to usr/bin,
> > and I install two packages, where one installs /bin/foo and the other
> > installs /usr/bin/foo
>
> My readi
ction that takes care of the
(re)loading.
Based-on-patch-by: Simon Richter
---
lib/dpkg/Makefile.am| 1 +
lib/dpkg/db-fsys-divert.c | 63 ++---
lib/dpkg/db-fsys-load.c | 91 +
lib/dpkg/db-fsys-override.c
1 - 100 of 8122 matches
Mail list logo
