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
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
On Thu, Nov 23, 2023 at 10:45:33AM +0100, Matthias Klose wrote:
> Hi,
>
> it looks like enabling this flag on armel/armhf is a little bit premature.
>
> Apparently it's not completely supported upstream, and might cause
> regressions, according to
> https://bugzilla.redhat.com/show_bug.cgi?id=152
On Fri, Nov 03, 2023 at 02:02:37PM +0100, Guillem Jover wrote:
> Hi!
>
> On Thu, 2023-11-02 at 15:27:54 +, Michael Hudson-Doyle wrote:
> > On Tue, 31 Oct 2023 at 09:21, Guillem Jover wrote:
> > > This can be used among other things to set up foreign chroots, by
> > > running the host tools, so
On Mon, Sep 18, 2023 at 12:24:20PM +0200, Guillem Jover wrote:
> While dpkg on systems using systemd _could_ by default take an
> system inhibitor lock, and could provide a good enough reason like say
> "Packaging system upgrade" or whatever, my concern has been with the
> added dependency chain, a
On Wed, Jun 14, 2023 at 06:00:42PM +0200, Julian Andres Klode wrote:
> Hi,
>
> based on some discussion on IRC I want to propose install
> profiles.
>
> Recommends: foo
> Suggests: foo
>
> The syntax is the same as for build profiles, and it is
> allowed in Recom
Hi,
based on some discussion on IRC I want to propose install
profiles.
Recommends: foo
Suggests: foo
The syntax is the same as for build profiles, and it is
allowed in Recommends and Suggests fields only (maybe
Enhances?).
dpkg changes needed:
- Introduce /var/lib/dpkg/profiles with one pro
On Sun, Jan 29, 2023 at 06:00:51AM +0100, Guillem Jover wrote:
> Hi!
>
> I'd like to move away from the master/slave terminology used in
> update-alternatives for both the external interfaces (CLI options,
> output fields) obviously preserving backwards compatibility, docs
> and for all the intern
On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote:
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintainer
Guillem Jover schrieb am Di., 23. Nov. 2021, 22:14:
> Hi!
>
> On Tue, 2021-11-23 at 18:16:30 +0100, Helge Kreutzmann wrote:
> > while updating the translation of the man pages, I stumbled over one
> > sentence I could not make sense of:
> >
> > "The file mode check failed (since dpkg 1.21.0). Th
On Wed, May 19, 2021 at 04:03:16PM +0200, Laurent Bigonville wrote:
> reopen 910377
> reassign dpkg 1.20.9
> thanks
>
> On Sat, 31 Aug 2019 00:34:32 +0200 Michael Biebl wrote:
>
> > On Fri, 5 Oct 2018 21:30:43 +0200 Michael Biebl wrote:
> > > Am 05.10.18 um 21:28 schrieb Michael Biebl:
> > > >
On Mon, May 17, 2021 at 10:14:24PM +0200, Fabrice Bauzac-Stehly wrote:
> Hello,
>
> I am puzzled.
>
> dpkg/man/dpkg.pod:
> The primary and more user-friendly
> front-end for B is B(8).
>
> dpkg/README:
> The primary interface for the dpkg suite is the ‘dselect’ program;
> a more
Control: clone -1 -2
Control: reassign -2 dpkg
Control: retitle -2 dpkg: normalize description fields
On Mon, Apr 12, 2021 at 08:14:07PM +0200, Julian Andres Klode wrote:
> Package: apt-listchanges
> Version: 3.23
> Severity: normal
> X-Debbugs-Cc: j...@debian.org
>
> As re
On Thu, Jul 16, 2020 at 06:56:56PM +0100, Steve McIntyre wrote:
>
> On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote:
>
> ...
>
> >Rationales:
> >
> >
> >1. You can start optionally build-depending on stuff available
> > only
On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote:
> Not liked proposals:
>
> Build-Depends-Optional field - it would just be ignored by tools,
> silently, and we'd find about it onyl when it is too late.
>
> Build-Recommends field - same as
Hi,
we were just talking in #debian-dpkg about optional build-deps. guillem
believes that the release team is in the best position to specify if this
is reasonable or not, so here we go:
We have came up with a syntax, one goal being to break parsers and not
silently ignore optional deps:
Build
On Mon, May 11, 2020 at 07:33:00AM +1200, Darren Hale wrote:
> Hi Guillem,
>
> I have been advised that the problem is with the behavior of su
> changed when they moved it to a different source package and a fix is
> to old behavior is to put ALWAYS_SET_PATH yes in /etc/default/su.
> (create the f
On Thu, Apr 16, 2020 at 11:04:02PM +0200, Jiri Palecek wrote:
>
>
>
> Forwarded Message
> Subject: Bug#956931: autopkgtest: Build profiles support for autopkgtest
> Resent-Date: Thu, 16 Apr 2020 20:42:01 +
> Resent-From: Jiri Palecek
> Resent-To:debian-bugs-d...
On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. [...]
[...]
> The use of a hidden directory is to reduce clutter and stomping over any
Love the hidden directory.
--
debian developer - deb
On Thu, Jan 17, 2019 at 11:03:01AM +0800, Allen wrote:
> Package: apt
> Version: 1.2.19
> Severity: normal
>
> Dear Maintainer,
>
>
> I am creating a deb packages which will replace another package. And before
> the
> old package are removed, I want to check whether the package is remove due to
This is an advanced proposal for integrating deltas into the archive. It has
been designed after some feedback and some more research.
Criteria
* We don't want to have Deltas indexes like Packages files
-> we are unlikely to need most of the deltas
-> about same size as Packages file
On Mon, Jun 18, 2018 at 08:19:17PM +0200, Julian Andres Klode wrote:
> Hi folks,
>
> With frontend locking in dpkg git, I think it's time I clear up
> some potential confusion as to how this is supposed to work in the
> APT world.
>
> The idea is that
Hi folks,
With frontend locking in dpkg git, I think it's time I clear up
some potential confusion as to how this is supposed to work in the
APT world.
The idea is that the current _system->Lock() / apt_pkg.SystemLock
/ apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
and lock,
On Tue, May 01, 2018 at 10:36:34AM +0200, Marco d'Itri wrote:
> On Apr 27, Julian Andres Klode wrote:
>
> > Our major use case is cloud initial setup, image building, CI, buildds, all
> > of which do not require any syncs, and can safely use eatmydata, for
> > ex
On Fri, Apr 27, 2018 at 01:45:07PM +0200, Adam Borowski wrote:
> (ZSTD)
>
> On Fri, Apr 27, 2018 at 07:02:12AM +0200, Guillem Jover wrote:
> > Recently Julian mentioned it again on IRC, and we each started
> > implementing support in dpkg and apt respectively, to allow easier
> > evaluation. I sto
On Fri, Apr 27, 2018 at 02:01:44PM +0200, Adam Borowski wrote:
> On Fri, Apr 27, 2018 at 01:45:07PM +0200, Adam Borowski wrote:
> > Don't. For .debs, that is.
>
> Scratch that.
>
> apt Depends: libapt-pkg5.0 Depends: libzstd1
>
> While apt is "merely" priority:required rather than fully essenti
On Thu, Jan 18, 2018 at 08:38:02PM +0100, Julian Andres Klode wrote:
> On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> > control: reassign -1 apt,dpkg
> > control: affects -1 libc6
> > control: affects -1 libexpat1
> >
> > On 2018-01
On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> control: reassign -1 apt,dpkg
> control: affects -1 libc6
> control: affects -1 libexpat1
>
> On 2018-01-18 15:53, Andreas Beckmann wrote:
> > Package: libc6
> > Version: 2.26-2
> > Severity: serious
> > User: debian...@lists.debian
On Tue, Aug 22, 2017 at 10:53:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-08-16 00:21:09 [+0200], Julian Andres Klode wrote:
> > libreoffice-core (size only):
> >
> > -rw-r--r-- 1 jak jak 29M Jul 22 20:02
> > libreoffice-core_5.3.5~rc1-3_amd64.deb
> &g
On Wed, Aug 16, 2017 at 12:21:09AM +0200, Julian Andres Klode wrote:
> firefox (size & performance):
>
> -rw-r--r-- 1 jak jak 2.3M Aug 15 20:59 firefox_55.0-1_55.0-2_amd64.debdelta
> -rw-r--r-- 1 jak jak 2.4M Aug 15 22:13 firefox_55.0-1_55.0-2_amd64.pdeb
> -rw-r--r-- 1 jak
On Tue, Aug 15, 2017 at 08:51:23PM +0200, Julian Andres Klode wrote:
> On Tue, Aug 15, 2017 at 09:26:24AM +0200, Christian Seiler wrote:
> > Hi there,
> >
> > I've come to believe that binary diff packages are not the best way of
> > solving this issue. Intea
On Sun, Aug 13, 2017 at 12:38:56PM +0300, Adrian Bunk wrote:
> On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
> >...
> > I think delta debs are generally a thing we should aim to have,
> >...
>
> It sounds like something that would have been a
On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote:
> You are assuming the savings are substantial. That's not clear. When
> files are compressed, if you then start doing binary diffs, well it
> isn't clear that they will consistently be much smaller than plain new
> files. it also isn'
On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote:
> Hi everyone,
>
> (I CCed -devel and deity, but we probably should just discuss
> that on -dpkg)
>
> while breakfast here at DebConf, the topic of delta upgrades
> came up. I think delta debs are genera
On Tue, Aug 15, 2017 at 09:26:24AM +0200, Christian Seiler wrote:
> Hi there,
>
> I've come to believe that binary diff packages are not the best way of
> solving this issue. Intead I'd like to propse a radically different
> solution to this issue.
>
> The gist of it: instead of adding a format f
On Sun, Aug 13, 2017 at 08:24:27PM -0400, Peter Silva wrote:
> o in spite of being the *default*, it isn't that universal, and in
> any event, we can just decide to change the default, no? One can say
> to people with bandwidth limitations, that their apt settings should
> not delete packages after
On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote:
> You are assuming the savings are substantial. That's not clear. When
> files are compressed, if you then start doing binary diffs, well it
> isn't clear that they will consistently be much smaller than plain new
> files. it also isn'
Hi everyone,
(I CCed -devel and deity, but we probably should just discuss
that on -dpkg)
while breakfast here at DebConf, the topic of delta upgrades
came up. I think delta debs are generally a thing we should
aim to have, but debdelta is not the implementation we want:
* It is not integrated
Hi everyone,
I talked with guillem about this idea on IRC, but I decided to
write this down in an email for further discussion.
Currently, APT and other dpkg frontends have to acquire the dpkg
database lock at the start of their process and then have to release
the dlock before invoking dpkg and
On Sun, Jan 08, 2017 at 01:33:08AM +, James Clarke wrote:
> On Mon, Feb 01, 2016 at 12:05:18AM +0100, David Kalnischkies wrote:
> > On Wed, Jan 20, 2016 at 01:39:45PM +, Colin Watson wrote:
> > > On Wed, Jan 20, 2016 at 12:31:52PM +0100, Balint Reczey wrote:
> > > > On 06/04/2014 03:41 AM,
On Wed, Mar 09, 2016 at 05:36:56PM +, Ian Jackson wrote:
> Julian Andres Klode writes ("Re: [RFC/dpkg PATCH] Introducing an
> relaxed-Essential-like "Important" field"):
> > Are there any better proposals?
>
> Do we want this field to be ignored by old
On Wed, Mar 09, 2016 at 12:15:47PM +0100, Guillem Jover wrote:
> Hi!
>
> On Wed, 2016-03-09 at 07:10:25 +, Niels Thykier wrote:
> > Julian Andres Klode:
> > > Since a few years, APT supports an "Important" field that is similar
> > > to Essen
r - deb.li/jak | jak-linux.org - free software dev
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
>From 141931815cdf663aab5ecccf6b4fdd517f99cbd4 Mon Sep 17 00:00:00 2001
From: Julian Andres Klode
Date: Sun, 6 Mar
ow on the multiarch branch, and as you pointed out already
> something that will definitely cause problems with essential or
> pseudo-essential packages.
>
> So it's something that should either be not supported at all, or
> supported fully, I don't think removal and install
clashes with the view APT has on the universe; pkg:a and
pkg:b are distinct packages of a group "pkg". So for that to work
correctly, APT would need to add some kind of implicit
Replaces: pkg:other
to the packages. At least IIRC.
--
Julian Andres Klode - Debian Developer, Ub
On Sun, 2010-12-05 at 17:44 +0100, Julian Andres Klode wrote:
> Package: packagekit
> Version: 0.6.8-2
> Severity: normal
>
> In addition to the debconf support, PackageKit must also
> support conffiles.
Dear dpkg maintainers,
for PackageKit support we need a way to handle con
his behavior is correct.
The following steps seem to be needed to change this:
1. Change Policy 5.6.3 to ignore multiple whitespace after newline
2. Strip the whitespace in dpkg
But as this is not an APT bug, I am reassigning it to dpkg-dev and let
them decide what to do next.
--
Juli
(/etc/apt/sources.list present, but not submitted) --
>
>
> -- System Information:
> Debian Release: 5.0.5
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_DE.UT
as automatically installed (or maybe they
are currently, as APT::Never-MarkAuto-Sections:: is empty [#431737]).
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@list
reassign 542843 dpkg-dev
thanks
Am Dienstag, den 02.02.2010, 17:38 +0100 schrieb Philipp Kern:
> On Tue, Feb 02, 2010 at 05:23:07PM +0100, Julian Andres Klode wrote:
> > On Sun, Sep 13, 2009 at 11:05:33AM -0400, Andres Mejia wrote:
> > > Just tested 'sbuild -As' and co
md64 ppc]".
When the package is added to the Packages file, the field gets changed to
"Architecture: all". This would be the easiest way.
Regards,
Julian
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436733
[2] http://lists.debian.org/debian-devel/2008/02/msg00045.html
[
51 matches
Mail list logo
