Bug#999598: dpkg-dev: Can we have binary package descriptions back for source uploads?

[Holger Levsen]

hi,

(leaving full context for debian-policy@l.d.o)

On Sat, Nov 13, 2021 at 06:56:24AM +0100, Petter Reinholdtsen wrote:
> Package: dpkg-dev
> Version: 1.20.9
> 
> Dear dpkg-dev developers,
> 
> One feature that is deeply missed, and which disappered when we moved to
> source only uploads, is the listing of binary package descriptions in
> the email to debian-devel-chan...@lists.debian.org.
> 
> The emails used to have a section like this, listing the short
> description of each binary package:
> 
>   Description: 
>gdm- GNOME Display Manager
> 
> I used this to see if a package I never heard about could be interesting
> to check out or not.  After we moved to source only uploads to unstable,
> there is no Description section any more in the emails, and it is a lot
> harder to guess what the odd packages are useful for.
> 
> The email content is simply the uploaded .changes file.
> 
> Would it be possible to adjust the .changes generator to include the
> description of all binary packages listed in d/control, even if none of
> them are included in the upload?

IMO this would only be a clumsy workaround (esp for packages with many binary
package) and we should rather fix the cause:
 
#963524 debian-policy: Binary and Description fields not mandatory in .changes 
on source-only uploads
#998165 debian-policy: document and allow Description in the source paragraph
#998282 Please make Section a required field for the source paragraph in 
d/control

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#19 is a nice example
how this would work in practice.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you own several guns but no guitars, you are doing life all wrong.


signature.asc
Description: PGP signature

Bug#980909: dpkg-dev: dpkg-buildpackage : gpg command uses expired key

[Holger Levsen]

On Mon, Jan 25, 2021 at 04:29:45PM +0100, Guillem Jover wrote:
> > having two variables, DEBSIGN_KEYID and DEB_SIGN_KEYID, for the same thing
> > seems wrong to me. Do you agree?
> The first is a configuration variable, the second is an environment
> variable. :)

ah, ok, then. & thanks for explaining.
 
> > (I'm not sure where the bug is, but... :)
> If there's any bug, maybe more of a feature request, at most, that
> debsign does not have an envvar, ideally the same as the dpkg one? :D

well, see above. besides that, a feature request is a bug, a wishlist bug. ;p


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Fascism is not an opinion, it's a crime. Usually a capital one.


signature.asc
Description: PGP signature

Bug#980909: dpkg-dev: dpkg-buildpackage : gpg command uses expired key

[Holger Levsen]

hi,

On Mon, Jan 25, 2021 at 01:56:02AM +0100, Guillem Jover wrote:
> I'm assuming you have this configured in ~/.devscripts with
> DEBSIGN_KEYID. You should be able to get similar results for
> dpkg-buildpackage by either setting the DEB_SIGN_KEYID environment
> variable 
 
having two variables, DEBSIGN_KEYID and DEB_SIGN_KEYID, for the same thing
seems wrong to me. Do you agree?

(I'm not sure where the bug is, but... :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

„If you don't like vaccination, try the disease.“ (Herwig Kollaritsch)


signature.asc
Description: PGP signature

Bug#892664: +1 (Re: Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages)

[Holger Levsen]

On Fri, Jan 08, 2021 at 08:54:01PM +0100, Balint Reczey wrote:
> I'm wondering if decompression support could be accepted for Bullseye,
> to let compression being enabled, too, in Bookworm.

I'd love to see this as well - and wouldn't mind having both for Bullseye ;)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

"Climate change" is an euphenism. "Global warming" as well.


signature.asc
Description: PGP signature

Bug#964111: dpkg-source: False positive 'points outside source root'

[Holger Levsen]

On Tue, Jul 07, 2020 at 03:52:08PM +0200, Guillem Jover wrote:
> Holger, as I mentioned some days ago, I consider this case a
> regression which I was planning on fixing. This fix was already
> included earlier today in the dpkg 1.20.4 upload. :)

yup, I've seen this today. Thank you!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#964111: dpkg-source: False positive 'points outside source root'

[Holger Levsen]

On Mon, Jul 06, 2020 at 09:08:43PM -0700, Felix Lechner wrote:
> > not sure if this is the same bug or just a similar one:
> > lrwxrwxrwx 1 user user 9 Jul  3 16:07 debian/munin.service -> /dev/null
> As for Holger's package, Lintian also flags that condition. Source
> packages can be unpacked anywhere. We likewise consider absolute
> symlink targets unacceptable there.
> W: munin source: absolute-symbolic-link-target-in-source
> debian/munin.service -> /dev/null

sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy
which prohibits files pointing to /dev/null. This worked for years.

(I haven't cloned the dpkg bug yet, as I believed Guillem would upload a
fix quickly and thus I wanted to prevent busy paperwork. IMO the bug
should be cloned and the severity raised to serious for the clone.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#964111: dpkg-source: False positive 'points outside source root'

[Holger Levsen]

Hi,

not sure if this is the same bug or just a similar one:

[...]
dpkg-source: info: extracting munin in munin-2.0.63
dpkg-source: info: unpacking munin_2.0.63.orig.tar.gz
dpkg-source: info: unpacking munin_2.0.63-1.debian.tar.xz
dpkg-source: error: pathname 'munin-2.0.63/debian/munin.service' points outside 
source root
E: pbuilder: Failed extracting the source

$ ls debian/munin.service -lart
lrwxrwxrwx 1 user user 9 Jul  3 16:07 debian/munin.service -> /dev/null

Full log at 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/munin_2.0.63-1.rbuild.log.gz


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

hi Guillem,

On Fri, Nov 09, 2018 at 11:55:38AM +0100, Guillem Jover wrote:
> Actually, I guess the other option that might be an option for stable is
> to make dpkg-buildpackage generate the buildinfo file itself, and on
> source-only uploads force the name to be _source.buildinfo regardless
> of the options passed down to dpkg-genbuildinfo (even if the contents
> will end up not matching the name).
> 
> This would seem rather less intrusive, as that only changes the
> behavior in a "corner-case" (even though documented and recommended
> one), when using «dpkg-buildpackage --changes-option=-S». And while it
> could be considered to produce confusing filenames, it sticks to the
> current pattern. It would also fix the other bug where running
> dpkg-genbuildinfo leaves debian/files around, even on source only
> builds.
> 
> So, I might go with that instead.
 
any update on this?

the security team people still have to workaround this manually regularily, eg
today, and would really like to see this fixed...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


signature.asc
Description: PGP signature

Bug#942087: dpkg-source and dpkg-genchanges disagree how .dsc should be named if version ends with +b1

[Holger Levsen]

On Sat, Oct 12, 2019 at 09:29:18AM +0200, Ansgar wrote:
> > Why should it generate a new source?
> Because sourceful uploads need a new source package.
[...] 
> > This is using the version suffix
> > for binNMUs, using this convention for something that is not a binNMU
> > seems just wrong.

I agree with this.

> (I don't care about using ".b1" instead of "+b1".)

So how about using .s1 or +s1 instead, to make it clear this no binNMU?

Or am I misunderstanding something?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#931135: German translation made me laugh during a meeting

[Holger Levsen]

Hi Helge,

On Thu, Aug 01, 2019 at 05:56:28PM +0200, Helge Kreutzmann wrote:
> I would suggest discussing this on debian-l10n-german so everybody
> interested from the German team notices and can join.

ack

> On Wed, Jul 31, 2019 at 09:05:35PM +0000, Holger Levsen wrote:
> > On Wed, Jul 31, 2019 at 10:23:21PM +0200, Helge Kreutzmann wrote:
> > > The translation only changed one word, namely canary. You can find it
> > > in the upstream git repository.
> > > 
> > > The remaining translation is only in the latest version in sid (and
> > > most of it in earlier version, e.g. in stable, as well).
> > 
> > 'die sich fortpflanzenden Bauschalter' were also quite absurd to me.
> > maybe better use 'vererb(t)en' instead of 'fortpflanzen'?
> 
> I'm switching to German as this is quite tough to describe in English.

indeed

> Signale pflanzen sich fort, Informationen pflanzen sich fort. 

well, ja, aber, irgendwann passt das nicht mehr. Fortpflanzungsrituale
von Signalen sind nicht nur sprachlich unsinnig :)

> In den deutschen Handbuchseiten verwenden wir »übertragen« (bei
> Systemd), ausbreiten, weiterreichen. 

passt

> Übertragen würde ich aber mit »transmit« zurückübersetzen, daher würde
> ich, falls wir es ändern, eher für »ausbreiten« plädieren.

'weiterreichen' find ich deutlich besser. 'ausbreiten' klingt so nach
Virus oder Krankheit... (und auch passiv, während 'weiterreichen' aktiv
ist.)

Thanks! :)

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931135: German translation made me laugh during a meeting

[Holger Levsen]

On Wed, Jul 31, 2019 at 10:23:21PM +0200, Helge Kreutzmann wrote:
> The translation only changed one word, namely canary. You can find it
> in the upstream git repository.
> 
> The remaining translation is only in the latest version in sid (and
> most of it in earlier version, e.g. in stable, as well).

'die sich fortpflanzenden Bauschalter' were also quite absurd to me.
maybe better use 'vererb(t)en' instead of 'fortpflanzen'?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931135: German translation made me laugh during a meeting

[Holger Levsen]

On Wed, Jul 31, 2019 at 09:13:51PM +0200, Helge Kreutzmann wrote:
> [...] I appreciate getting feedback for the
> translation.

where can one find the updated translation?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:
> > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote:
> > > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > > wrote:
> > > > > 
> > > > >Perhaps the simplest and more correct might be to name it using
> > > > >something like source+amd64 as the arch name, which seems like a
> > > > >dubious arch, but at least is accurate and might be trivial to
> > > > >implement, taking care of not ending up with such fake arch in
> > > > >unexpected places…
> > > > > 
> > > > > and I cannot find anything wrong with this simple solution and have
> > > > > already asked Guillem in August to implement this ;)
> > > > 
> > > > So, as I mentioned at the time this would require modifing the internal
> > > > filtering of the debian/files entries to cover this case in several of
> > > > the tools. It also modifies the documented filename pattern in
> > > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > > But this breaks previous public filename "interfaces", seems rather
> > > > intrusive, and entirely inappropriate for a stable update, which means
> > > > it would not fix your immediate problems anyway, only starting with
> > > > Buster. :/
> > > Although this would not help us for stretch-security uploads, such a
> > > move starting from buster would be very appreciated!

Guillem, back in November Salvatore said they would appreciate this
"source+amd64 as the arch name" solution for this bug (see above), while
now (because nothing happened I believe) he suggests disabling source
all uploads for security builds, which IMO would be a *very* bad and sad
outcome, as I believe source only security uploads are even more desired
than regular source only uploads...

> We regularly get biten by this issue when contributors to security
> uploads, most recently with the bind9 upload but as well others.
> 
> Would it be possible to at least workaround this on dak's side?
> Disabling source-only uploads completely would seem to be a step back
> on that regards.
> 
> Though if that's the only way  out of having to regularly fetch the
> rejected builds, do manual renamings and resigning and reuploading of
> files, then we should then just disable source-only uploads for the
> security suites again.
> 
> So I think we pretty much would prefer to be able to continue so.
> 
> Just to be clear, thanks a lot for your work, this is not meant as
> critique, just hilighting that we have recurring issues due to this
> bug when people perform uploads for security.

sigh, understandable...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#922039: dpkg-buildpackage: error: short OpenPGP key IDs are broken; please use key fingerprints instead

[Holger Levsen]

control: severity -1 wishlist
thanks

On Tue, Oct 30, 2018 at 01:14:00PM +0200, Martin-Éric Racine wrote:
> Package: dpkg-dev
> Version: 1.19.2
> Severity: important
> 
> The above error message is useless. It doesn't tell what needs to be fixed or 
> where.

while I agree that the location should be indicated, this bug is by no
means important.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> We were again biten by this issue for some security-updates (most
> recent one nginx). Do any involved parties know, was there any
> progress in adressing this problem? 

in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
wrote:

   Perhaps the simplest and more correct might be to name it using
   something like source+amd64 as the arch name, which seems like a
   dubious arch, but at least is accurate and might be trivial to
   implement, taking care of not ending up with such fake arch in
   unexpected places…

and I cannot find anything wrong with this simple solution and have
already asked Guillem in August to implement this ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#910819: dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed

[Holger Levsen]

Hi Guillem,

thanks for your feedback! However I'm not sure what to do with it...

On Sun, Oct 14, 2018 at 01:20:22AM +0200, Guillem Jover wrote:
> Just in case this is helpful in the future, I've reproduced this now,
> by using in addition:
[...]

interesting, thanks for sharing!

> Then, first, there's a bug (normal probably) in dpkg with the
> assert/internal-error, which should be a proper error message, this
> needs to be fixed, and I think there's one or two bugs about just that.
> Then, the current reporting in the buster internal error message still
> sucks, so I'll try to improve that too, to:
> 
>   - Print the current processed package and in the ones in the queue.
>   - Print the command-line options used to invoke dpkg, or at least
> the state of the --[no-]triggers option, and whether we were
> called with a --pending or an explicit list of packages.
>   - Recommend running «dpkg --audit» and attaching that too, while
> reporting the problem.

cool!

> But in any case the real cause for this seem to be just the usual trigger
> cycle problem (serious, for the offending cycle introducer), that gets
> abandoned and resets the state of dbus, which is never tried to get
> configure again, as specified.
> 
> The trigger happens with this:

hm. I'm surprised we dont find any trigger cycles using
https://jenkins.debian.net/job/dpkg_buster_find_trigger_cycles/ nor
https://jenkins.debian.net/job/dpkg_sid_find_trigger_cycles/ nor

cc:ing Josch who wrote
https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/find_dpkg_trigger_cycles.sh
(on which those jobs are based) for input.

> And dbus as seen from «dpkg --audit» is half-configured, and was not
> in the processing queue, so dpkg was unable to make progress.
> 
> After the assert/internerr, if you just run «dpkg --configure --pending»
> dpkg will be able to make normal progress.

well, that's nice for actual users but not helpful for CI jobs :)

So I guess what's currently still missing is a serious bug against the
package causing the reported behaviour in the first place, probably by
just cloning this bug and reassigning it. Just to where to reassign is
still unclear to me.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#910819: dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed

[Holger Levsen]

Package: dpkg
Version: 1.18.25
Severity: important

Dear Guillem,

on June 28th 2018 was the last successful test of
https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/
which tests the installation of the education-mathmatics meta-package on
a clean stretch install (in a chroot) and then upgrades this chroot to
buster. Since July 7th 2018 this test is failing...

As I read
https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/35/consoleFull
the upgrade is done using dpkg 1.8.25, however I'm not fully sure the
bug is coming from dpkg...

The failure is (happening when upgrading packages to buster):

Setting up kalgebra (4:17.08.3-2) ...
dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' 
failed.
E: Sub-process /usr/bin/dpkg exited unexpectedly

Feedback much appreciated as I'm lost here. Also maybe this bug should
have severity 'serious' as it breaks upgrades to Buster?!?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#909754: dpkg -l now always pipes to less and ignores $COLUMNS

[Holger Levsen]

hi,

On Tue, Oct 02, 2018 at 04:48:30AM +0200, Guillem Jover wrote:
> This includes the following
> changes which I've started coding:
> 
>   * DPKG_PAGER (equivalent to PAGER, so it will accept arguments).
>   * Set LESS (if unset) to something along the lines of -FRSXMQ, which
> sould fix the clear-screen-problem, the ugly-output, and
> blocking-on-pager-when-unnecessary.
>   * New --no-pager option (that can be set in the config file, for
> dpkg, although dpkq-query does not currently honor any config,
> but I might need to implement something for the path mapping
> options anyway in the future).
>   * I could see perhaps a mode where the Description is omitted?
>   * If you still want the truncating behavior, I could introduce it
> back under a new option such as --width=fit-to-screen vs =auto vs
> = or similar.

these all seem pretty useful/nice to me, thanks for your work & feedback
here.

> On Fri, 2018-09-28 at 11:40:38 +, Holger Levsen wrote:
> > also, running eg 'dpkg -l dpkg' and then ending up in less is confusing
> > and breaking >20y old habbits, and then I press 'q' and get exit code 1.
> Ah! That's actually a bug, the process dies from a SIGPIPE, I'll fix
> that.

ah! thanks! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#909754: dpkg -l now always pipes to less and ignores $COLUMNS

[Holger Levsen]

On Fri, Sep 28, 2018 at 02:42:19AM +1000, Craig Sanders wrote:
> I upgraded dpkg today and noticed that 'dpkg -l' now always pipes its output
> through less, even if $PAGER is unset.  The only way to get the output to go
> to the tty is to explicitly pipe it to cat.
> 
> This is exactly the opposite of how unix programs should behave - stdout
> goes to a tty unless redirected.  If a user **wants** to view the output of
> a program in a pager, then they can pipe it to less or whatever themselves.
> That's standard usage of the unix shell.  Hard-coding a program to always use
> a pager is wrong.
> 
> It also prevents dpkg's output from appearing in the scrollback buffer of
> terminal emulators because less (by default) switches to the alternate screen.
> 
> 
> dpkg now also ignore the COLUMNS variable, which is set by default in bash
> and other shells, and can be overidden on the command line as needed. With
> this change, flexibility and customisation has been replaced with a single
> hard-coded output format.  Previous versions of dpkg used $COLUMNS, and were
> documented to do so in the man page.
> 
> This makes the output ugly and difficult to read on standard 80 column
> terminals because the output will now typically be longer than 80 columns
> wide.  In fact, it's ugly and difficult to read on any terminal width
> less than the widest possible output line - it's no longer an easily read
> one-line-per-entry table, but a jumbled multiple-lines-per-entry mess.
[...]
 
I fully agree. (& thanks for writing this precice bug report, Craig.)

also, running eg 'dpkg -l dpkg' and then ending up in less is confusing
and breaking >20y old habbits, and then I press 'q' and get exit code 1.

> Please revert this change.

Yes, please.

And thanks for maintaining dpkg! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi Guillem,

people are still affected by this bug...

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote:
> Perhaps the simplest and more correct might be to name it using
> something like source+amd64 as the arch name, which seems like a
> dubious arch, but at least is accurate and might be trivial to
> implement, taking care of not ending up with such fake arch in
> unexpected places…

could we have this simple migation for now, please? 


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Hi josch,

adding #774415 to to: and reply-to:…

On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote:
> > as I'm not an sbuild user (yet) myself, I was hesistant to try this
> > myself, so I'm confused now: does it work as it is now? (or does it need
> > changes to snapshot.d.o?)
> 
> yes, it does work as it is now.
> 
> Just supply the script with a buildinfo file to see it in action.
> 
> It does not require superuser privileges.
> 
> The script will query snapshot.debian.org to retrieve the right snapshot
> timestamp that contains all the package versions specified in the buildinfo
> file.
> 
> At the end of execution the script will print how to either reproduce the
> buildinfo manually via dpkg-buildpackage or how to run sbuild such that it 
> does
> it for you.
> 
> People who know how to use pbuilder could easily add a section that outputs 
> how
> to run pbuilder to do the same.
> 
> Naturally, instead of just printing how to use sbuild or pbuilder, the script
> could also be made actually run either.
> 
> The main two limitations of the script are:
> 
>  1. it will fail if there is not a single snapshot that contains all the right
> package versions
> 
>  2. it will instruct sbuild/pbuilder to use the last stable release as the 
> base
> which might not allow upgrading to the right package versions
> 
> Both issues can be fixed by manually downloading exactly the required binary
> package set and creating a completely new chroot with exactly the required
> packages. But I didn't get around to doing that yet.

thank you very much for this nice summary!

As it sounds, I now believe this script would better live in
src:devscripts and as such I would like to reassign #774415 to
devscripts - or do you see any issue with that?


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Guillem, josch:

thanks for your feedback, much appreciated.

On Fri, Jun 08, 2018 at 08:38:49AM +0200, Johannes Schauer wrote:
> > I say it's an artificial blocker, because it is based on the problem
> > faced while implementing the srebuild script to use the current
> > snapshot.d.o API. And I think that's your actual blocker. Fixing that
> > API would also mean you can use it right away independently of what's
> > already installed on the system and might be useful for other users
> > too. I think the fix would imply adding an API entry point based on
> > the name-version-arch tuple.
> 
> yes, that would also solve the problem.
 
as I'm not an sbuild user (yet) myself, I was hesistant to try this
myself, so I'm confused now: does it work as it is now? (or does it need
changes to snapshot.d.o?)

> I unblocked the bug, because it's not a hard blocker but just an 
> inconvenience.

thanks

> The bigger blocker of #774415 is, that the script needs somebody who feels
> responsible for it and who is willing to maintain it. I only wrote it but I
> have no intention of being its maintainer.

I'd be happy to maintain it, once I'm a user of it :) (which might
happen quite soon via tests.r-b.o…)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Hi Guillem,

ping on this bug, you haven't replied to it yet and it's a blocker for
"#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds"
which is a rather important one to give users the means to easily
reproduce Debian packages, which is a core feature of reproducible
builds and which we would love to see for Buster…! 

:)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> So, during compilation:
> SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> because it breaks Multi-Arch:same on bin-nmu.
> 
> During dpkg-deb (:
> SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> because it would break software relying on files mtime.
> 
> Doh!

different ways of parsing debian/changelog to determine S_D_E is a road
to desaster, sorry.

> In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a 
> BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over 
> SOURCE_DATE_EPOCH by dpkg-deb.
> 
> That would work, wouldn't it?

I'm also not convinced this would be a good solution.

Sadly I also don't have another idea than changing the way binNMUs are
done :( Them being no-source-changes-rebuilds with changes to
debian/changelog, which is part of the source, (IMNSHO) is poor design
and the root of this and other problems.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> Any news regarding this proposal from Ansgar? We were biten now
> several times already by this (e.g. php update, curl via
> security.d.o).

Guilem, what's your stance on this bug?

We (reproducible builds) really dont want "our" tools (=.buildinfo files)
to cause grief to other teams in Debian, and especially not on a regular
basis... so as a first step to fix this, I'd like to collect opinions
how to best fix this issue here.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#888546: gnome-chrom-shell: After purging files have disappeared: /etc/opt/ owned by: chrome-gnome-shell

[Holger Levsen]

Package: base,chrome-gnome-shell
Severity: important

hi,

from #debian-edu and #-release just now:

 
https://piuparts.debian.org/sid/fail/education-desktop-gnome_2.10.14.log fails 
with
 17m25.6s ERROR: FAIL: After purging files have disappeared:
   /etc/opt/ owned by: chrome-gnome-shell
 hmm. thats not coming from src:debian-edu 
 yeah, https://piuparts.debian.org/sid/fail/chrome-gnome-shell_9-2.log 
is to blame
 h01ger: I don't think it's chrome-gnome-shell's fault
 FAIL: After purging files have disappeared: /etc/opt/ owned by: 
chrome-gnome-shell
 that directory is created by base-files but chrome-gnome-shell is the 
first Debian package to include something there
 I don't know enough about this situation to know how to fix the issue
 we should probably file a bug against base,chrome-gnome-shell
 chrome-gnome-shell uses that directory because that's where the 
official Google Chrome looks for overrides
 maybe dpkg? I don't know
 I'm fine with you filing a chrome-gnome-shell bug. I'm guessing that 
the ultimate fix will be somewhere else

Filing this with severity important as this introduces a piuparts
regression which becomes a britney migration blocker.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#873937: in package dpkg marked as pending

[Holger Levsen]

On Tue, Oct 17, 2017 at 01:13:09AM +, Guillem Jover wrote:
> Bug #873937 in package dpkg reported by you has been fixed in
> the dpkg/dpkg.git Git repository. You can see the changelog below, and
> you can check the diff of the fix at:
> https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=d920305

thank you very much for this (and all your other dpkg work!), Guillem!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Holger Levsen]

Source: dpkg
Version: 1.8.24
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi Guillem,

during discussing #844431 it became clear, that some information about the
running kernel should be included in .buildinfo files, as this can affect the
build.

For a start, including the output of "uname -s -r -v -m -i -o" (so basically
uname -a without the hostname) would be better than the current status quo,
though it would probably be even nicer to also include a hash of
/proc/config.gz or maybe even the whole thing.

Filing a bug now so that we can discuss the best implementation.

Thanks for maintaining dpkg!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#802241: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

hi,

while I very much like this idea, please don't store md5sums, but rather
sha256sums.

Thank you!


-- 
cheers,
Holger (wondering why I seem to have to write this in 2017)



signature.asc
Description: Digital signature

Bug#845436: dpkg-dev: dpkg-buildpackage leaves spurious debian/files in source tree

[Holger Levsen]

On Wed, Feb 08, 2017 at 06:28:27AM +0100, Guillem Jover wrote:
> Sure, and I question the wisdom of doing a pure source-only upload w/o
> building the binaries at the same time. 
 
I do this all the time:

#1 debuild -S
#2 sudo pbuilder $thatnewdsc
#3 do tests & compare whats in the archive with what I intend to upload
#4 sign+upload the source package build in #1
#5 throw away the source+binary packages build in #2

AFAICS there is nothing unwise with this approach :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#845556: dpkg: should not generate .buildinfo files for source only uploads

[Holger Levsen]

Package: dpkg
Version: 1.18.15
Severity: normal

Hi Guillem,

the subject basically says it all, dpkg should not generate .buildinfo
files for source only uploads, as they are totally pointless for those.

(I'm also not even sure whether you had implemented in most recent
uploads, but I thought I better file this is a bug which you can easily
close, instead of risking to loose this patch, which floated around on
irc:


>From e774e1e19a0aa3ed21603949385bf1f0ac1452e9 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Fri, 11 Nov 2016 00:55:43 +
Subject: [PATCH] dpkg-buildpackage: Don't generate .buildinfo for source-only
 builds

---
 scripts/dpkg-buildpackage.pl | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index b1d644d..32e1028 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -561,13 +561,15 @@ if (build_has_any(BUILD_BINARY)) {
 withecho(@rootcommand, @debian_rules, $binarytarget);
 }
 
-run_hook('buildinfo', 1);
+run_hook('buildinfo', build_has_any(BUILD_BINARY));
 
-push @buildinfo_opts, "--build=$build_types" if build_has_none(BUILD_DEFAULT);
-push @buildinfo_opts, "--buildinfo-id=$buildinfo_id" if $buildinfo_id;
-push @buildinfo_opts, "--admindir=$admindir" if $admindir;
+if (build_has_any(BUILD_BINARY)) {
+push @buildinfo_opts, "--build=$build_types" if 
build_has_none(BUILD_DEFAULT);
+push @buildinfo_opts, "--buildinfo-id=$buildinfo_id" if $buildinfo_id;
+push @buildinfo_opts, "--admindir=$admindir" if $admindir;
 
-withecho('dpkg-genbuildinfo', @buildinfo_opts);
+withecho('dpkg-genbuildinfo', @buildinfo_opts);
+}
 
 run_hook('changes', 1);
 
-- 
2.10.2


Thanks for maintaining dpkg!

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

[Holger Levsen]

Hi Michael,

On Wed, Nov 09, 2016 at 07:16:53PM +0100, Michael Biebl wrote:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html
> Do you also have builds for i386? (which this issue is about, amd64 is fine)

yes, they are linked from that url as well, though you can also go
directly to
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/systemd.html

I've just checked
https://jenkins.debian.net/view/reproducible/view/Debian_setup_i386/job/reproducible_setup_pbuilder_unstable_i386_profitbricks2/257/console
and found nothing of usrmerge in there, which makes sense, as we use
debootstrap from stable…

what we could maybe do, is to use debootstrap from jessie-backports and vary 
this
regularily, so we would setup half of our pbuilders with merged /usr and the 
other
half without. cc:ing the reproducible builds list for feedback.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

[Holger Levsen]

Hi,

On Sat, Nov 05, 2016 at 08:58:06PM +0100, Michael Biebl wrote:
> As this breaks packages to build successfully, I'm bumping this to RC.
> E.g. I'm unable to successfully build systemd in a freshly created
> chroot on i386. I suspect once the buildds update their chroot, it will
> affect a lot more packages.

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html
shows that we could build systemd on sid. The builds are being done in
recently created pbuilder setups though.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#126505: reopen, closed by spam, please cleanup (was Re: Bug#126505: marked as done (dpkg-statoverride : add 'recursive', 'dirs', and 'files' options in rules-file))

[Holger Levsen]

control: reopen -1

On Wed, Oct 05, 2016 at 06:33:05PM +, Debian Bug Tracking System wrote:
> Date: Wed, 5 Oct 2016 20:30:35 +0200
> From: "FedEx 2Day A.M." 
> To: 126505-cl...@bugs.debian.org

closed by spam…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#787980: status: normalize file permissions when creating control.tar ?

[Holger Levsen]

Hi Guillem,

(sorry for the late reply…)

On Thu, Jul 07, 2016 at 12:20:44AM +0200, Guillem Jover wrote:
> > could you please comment briefly on
> > your take on this bug and it's status?
> 
> I've had my qualms about the need for this patch, but in any
> case the provided patch has not been correct now for a while as
> I pointed out on IRC some time ago. Which is why Mattia reworked
> it temporarily so that the dpkg in the reproducible repo works and
> does not mess with the data.tar files.
> 
> As I also mentioned on IRC, I'm planning on coming up with something
> for this for the next upload. And left it out as it's certainly not
> in the critical path to reproducible binaries, as the control member
> has a more controlled environment.

thanks for this information and your work on this. (I agree with your
assessment its not that critical…)

> > It's in the BTS since 13 months without a maintainer comment.
> So it's certainly true that the bug report has had no comment for
> that long, and I should have probably updated it for the benefit
> of others, but I was actually quite surprised by this mail from you
> given that I've been keeping at least Mattia and others on the IRC
> channel informed of the progress and bugs status, which I had the
> impression were getting relayed to the reproducible IRC channel,
> and which he confirms he has been doing all along… so claiming no
> maintainer comment seems a bit unfair TBH.

right.

what I ment indeed where "maintainer comments in the BTS" as comments on
IRC (or mailinglists or RL) get lost/forgotten/cannot be found… 

which is precisely what had happened here: I was really lost at the
status of this bug, the patch was in our repo since a long time yet I
had no idea whether you considered it ready, useless or in need of some
work. (I'm not on the #debian-dpkg IRC channel and while I do read
dpkg's bugs I wouldn't say that I follow it's development closely.)

so long story short: I ment comments in the BTS & I'm sorry to have
given the impression I think you don't care about dpkg's bugs. That's
definitly the opposite of what I think! :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#787980: status: normalize file permissions when creating control.tar ?

[Holger Levsen]

Hi,

Guillem, (kudos and thanks for the recent dpkg upload(s)! Glad to see
progress with reproducible bits!) could you please comment briefly on
your take on this bug and it's status?

It's in the BTS since 13 months without a maintainer comment.

Thanks! ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#735377: 3.0 (native) silently ignores many binary files by default.

[Holger Levsen]

Hi,

On Tue, Apr 26, 2016 at 10:54:15AM +0200, Guillem Jover wrote:
> That's weird, it does work fine here, just checked with git master to
> make sure there's been no regressions:

we've been seeing the same behavior when uploading diffoscope. When I
build it, tests/data/test(1|2).(o|a) are not part of the source package,
when Rainer or Mattia build it, they are there as they should be…

.../diffoscope$ cat debian/source/options 
# Default ignore patterns contains *.o and *.a. So we need to define our
# own
# patterns to get them included.
--tar-ignore=.*.sw?
--tar-ignore=*/*~
--tar-ignore=,,*
--tar-ignore=.[#~]*
--tar-ignore=.deps
--tar-ignore=.git
--tar-ignore=.gitattributes
--tar-ignore=.gitignore
--tar-ignore=.gitmodules
.../diffoscope$ ls tests/data/*.o
tests/data/test1.o  tests/data/test2.o
.../diffoscope$ ls tests/data/*.a
tests/data/test1.a  tests/data/test2.a

I'm building with plain "debuild -S" and just confirmed this in sid and
jessie. 

Having done this, I checked my ~/.devscripts and found this:

DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us -I -i"

Is this why?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Holger Levsen]

Hi,

On Wed, Mar 30, 2016 at 02:19:02AM -0400, Daniel Kahn Gillmor wrote:
> No one is arguing for dropping the build path from .buildinfo files.

ok, cool. Thanks (to you both) for clarifying!

 
-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#759886: [patch #8925] Support --clamp-mtime for binary reproducibility]

[Holger Levsen]

Hey!

On Wed, Mar 30, 2016 at 10:32:08AM +0200, Guillem Jover wrote:
> Yes, I was notified on IRC, and also saw your private mail. :) 

hehe, lol. Too much travelling and a new mail client… so I forgot :)

but then, it's also good to have that in the BTS, as a matter of proper
workflows… 

> In any
> case there's not been a release yet AFAIK. Given that upstream said
> that would happen in 7-10 days, I'll wait before commiting any change,
> so that dpkg depends on released features that other downstreams can
> use. And in any case there's still few things I want to wrap up before
> the next dpkg release so that should give enough time.

cool! very :) +thanks for the update…!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Holger Levsen]

Hi,

On Tue, Mar 29, 2016 at 09:36:00PM -0400, Daniel Kahn Gillmor wrote:
> This isn't fun-spoiling, it's a useful reality check.  But if we were
> required to get all the way to 100% before we made any progress, then
> reproducible builds wouldn't have gotten off the ground at all.

it's surely progress on the gcc/clang side of things but dropping the
build path from the .buildinfo files would be a huge step *backwards*
for reproducibility…

> The changes proposed in this bug report are a good step that should
> handle a very large proportion of the debian archive.  The fact that
> there will remain corners of the archive that need additional work is
> fine: we can turn our attention to the remaining 20% once we get 80% of
> the buildpaths resolved.

true. 

my point was: I think we still need the build path in the .buildinfo files.

(And btw, this (build path in buildinfo files) is not what *this* bug report 
is about. but it's related.)

Also, c/c++ packages today only make up a small portion of the archive.
Probably this famous someone should do a rebuild of the archive, using
our toolchain (and this patch), using arbitrary build pathes.


-- 
cheers,
Holger




signature.asc
Description: Digital signature

Bug#759886: [patch #8925] Support --clamp-mtime for binary reproducibility]

[Holger Levsen]

Hi Guillem,

FYI, GNU tar's upstream has accepted our patch! :-)


cheers,
Holger

- Forwarded message from Sergey Poznyakoff  -

Date: Thu, 24 Mar 2016 05:33:34 +
From: Sergey Poznyakoff 
To: Sergey Poznyakoff , Ximin Luo , 
816...@bugs.debian.org, g...@gnu.org
Subject: [patch #8925] Support --clamp-mtime for binary reproducibility
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0

Update of patch #8925 (project tar):

  Status:None => Done   
 Assigned to:None => gray   

___

Follow-up Comment #1:

The patch is incorporated into Git repository (commit
13d04fe6ae5a343415299359944382f7a6d37816). It will appear in the next stable
release of GNU tar (v.1.29). Thank you!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



- End forwarded message -




signature.asc
Description: Digital signature

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Holger Levsen]

Hi,

not wanting to spoil the fun, but…

On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote:
> > Ah great! And one less way to leak local information.
> yep :)

I *believe* it's not enough (for reproducible builds in arbitrary
pathes) if gcc+clang can now cope. IIRC there are other compilers that
have the same behaviour, eg ocaml and erlang, but probably others too.

Someone shoulds to check this and confirm or deny though.


-- 
cheers,
Holger

P.S.: besides that, truely nice work!


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Lunar, 

also:

< josch> personally i'd be happy with Lunar's suggestion: Installed-Build-
Depends
< josch> i think the natural understanding of that term implies the 
transitivity as well as that it's not the closure that is meant
* h01ger likes Installed-Build-Depends too
< h01ger> | [12:14] < josch> i think the natural understanding of that term 
implies the transitivity as well as that it's not the closure that is meant
< h01ger> | agreed on that as well

and, yes, finding a proper name takes time, but is no bike shedding, instead 
it helps avoiding to understanding future confusions. If you don't like 
naming, don't participate, but don't dismiss other peoples work.


Holger


signature.asc
Description: This is a digitally signed message part.

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Hi Josch,

On Donnerstag, 4. Februar 2016, Johannes Schauer wrote:
> maybe we can merge Lunar's original suggestion Installed-Build-Depends (a
> name which is missing the transitive/recursive-ness) with the new
> suggestion and make it:
> 
> Installed-Transitive-Build-Depends
> 
> This way it would not be confused with the *actual* transitive build
> depends

I'm sorry, but I think the opposite will be the case, this will cause *more* 
confusion: what are "installed transitive build depends" vs "actual transitive 
build depends"? 

I know that *you* have grasped the concept of transitive build depends very 
well, but I'm pretty sure that 97% of the DD population have no idea what 
transitive build depends are, especially compared to build-depends or 
alternative build-depends. And even 70% were too many.
 (AFAIK transitive build-depends are all possible build depends, so if a 
package build depends on python2 || python3 both python versions will be part 
of the transitive build depends. (Is that even correct?)

Also see $(torsocks dict transitive) - what does this word even mean? ;-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

no thanks for totally dismissing what I said…

and making funny signs about the crap I said. very funny.


signature.asc
Description: This is a digitally signed message part.

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Hi,

On Donnerstag, 4. Februar 2016, Guillem Jover wrote:
> I asked for more suggestions on #debian-dpkg, and Johannes Schauer
> suggested Transitive-Build-Depends, which is something I had in mind
> too (that or «Recursive-»), but kind of softly discarded in trying to
> have a consistently namespaced «Build-» field name. :) Some of the
> reasons Johannes put forward are that this name is better because it
> clearly describes what's the exact purpose of the field, and gives
> no room for misinterpretation. And if we had to change the algorithm
> we could just use a new name. All of which I concur with.

I don't think "Transitive-Build-Depends" is a good name here, first, because  
I think 97% of the people will have no idea what it means. And second, because 
I think it's wrong, as the field would only list the installed build depends, 
but not all transitive ones. (Or maybe my second point is moot, but then I 
fall under the 97% too, which would strengthen my first point ;)

Build-packages-installed: ?


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

+many thanks for your thorough review! :-)


signature.asc
Description: This is a digitally signed message part.

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Hi,

On Freitag, 29. Januar 2016, Guillem Jover wrote:
> > (I'd be in favor of naming the first accepted buildinfo
> > file of the archive just "" so that it's predictable…
> I'm not sure how we'd use a sequential number in a distributed manner
> starting with 0s though? :9

we can't :) but dak could do it. (in the Debian use case.)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Holger Levsen]

Hi Guillem,

just quickly commenting on two sub topics…

On Donnerstag, 28. Januar 2016, Guillem Jover wrote:
> > One of the main change is that `.buildinfo` should now be named with an
> > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> > but can be set to an arbitrary value by the `--buildinfo-identifier`
> > command line flag.
> Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> information therein is not relevant I'd rather use something like an
> UUID (although that would require increasing the pseudo-build-essential
> set), or just hashing the hostname-timestamp with something like md5
> or sha1 or similar.

yeah, "something / anything" is fine. dak / the archive software can rename it 
anyway, as it likes. (I'd be in favor of naming the first accepted buildinfo 
file of the archive just "" so that it's predictable…
 
> I've some pending changes I'll be committing to master or a separate
> branch, that I'd like to be tested on the reproducible setup (ideally
> against the already generated and pre-existing reproducible binaries),
> if that's possible, I'll ask about that when those land, I just need
> to finish up fewm more unit tests.

That's possible, though not (yet nor in near future) against pre-existing 
binaries. (We lack the code for that.)

What we can do easily, is build and upload dpkg to our repo and use it to 
build the whole Debian archive on amd64, which roughly takes 8 days for both 
sid+stretch, and thus roughly 4 days for one suite, if we disable building the 
other. (Which we can definitly do, especially if we don't disable building of 
new versions in that other suite…)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#804018: dpkg: provide options to avoid service startup on package installation

[Holger Levsen]

reassign -1 debian-policy
thanks


signature.asc
Description: This is a digitally signed message part.

Bug#804018: dpkg: provide options to avoid service startup on package installation

[Holger Levsen]

Hi Patrick,

you are aware of

echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d

to implement exactly this?


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#770448: reassigning to dpkg (Setting up libpam-modules-bin (1.1.8-3.1) hangs forever with dpkg using 100% cpu)

[Holger Levsen]

On Sonntag, 7. Dezember 2014, Niels Thykier wrote:
 For reference, dpkg is upgraded to 1.17.21 before the problem occurs.
 It is possible that this is fixed in dpkg 1.17.22 (which is not in Jessie).

FWIW,
https://jenkins.debian.net/view/d-i_manual/job/chroot-installation_jessie_install_education-thin-client-server_upgrade_to_sid/
doesnt show this bug.


signature.asc
Description: This is a digitally signed message part.

Bug#768466: [pkg-php-pear] Bug#768466: php-htmlpurifier: fails to install

[Holger Levsen]

Hi David,

On Freitag, 7. November 2014, David Prévot wrote:
 I’m not able to get the dpkg version out of the provided log, but given
 the date, (2014-11-01 21:29:50 UTC), I’d expect it to be still
 dpkg/1.17.13 (while 1.17.21 migrated to Jessie on 2014-11-03). Can you
 please update the chroot and verify the issue still exist before opening
 yet another duplicate of this dpkg issue?

I've rescheduled these yesterday but forgot to recreate the base.tgzs first, 
doing so now. Should hopefully have results for the 14-1500 UTC piuparts pages 
updates...


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.

Bug#768598: font-config: cycle found while processing triggers

[Holger Levsen]

package: font-config
severity: serious
x-debbugs-cc: debian-d...@lists.debian.org

Hi,

I'm not 100% sure the following issue is caused by font-config, please 
reassign appropriatly if it is not.

https://jenkins.debian.net/job/chroot-installation_wheezy_install_education-
desktop-kde_upgrade_to_jessie/2//console

Setting up libgl1-mesa-glx:amd64 (10.3.2-1) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  fontconfig - fontconfig
 packages' pending triggers which are or may be unresolvable:
  fontconfig: /usr/share/fonts
  shared-mime-info: /usr/share/mime/packages
  libc-bin: ldconfig
  gconf2: /usr/share/gconf/schemas
dpkg: error processing package fontconfig (--configure):
 triggers looping, abandoned
Setting up fontconfig-config (2.11.0-6.1) ...


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#768599: man-db: cycle found while processing triggers:

[Holger Levsen]

package: man-db
severity: serious
x-debbugs-cc: debian-d...@lists.debian.org

Hi,

I'm not 100% sure the following issue is caused by man-db, please reassign 
appropriatly if it is not.

https://jenkins.debian.net/job/chroot-installation_wheezy_install_education-
networked_upgrade_to_jessie/2/console

Setting up startpar (0.59-3) ...
Installing new version of config file /etc/init/startpar-bridge.conf ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  man-db - man-db
 packages' pending triggers which are or may be unresolvable:
  man-db: /usr/share/man
dpkg: error processing package man-db (--configure):
 triggers looping, abandoned
Setting up sysvinit-utils (2.88dsf-57) ...
Errors were encountered while processing:
 man-db
E: Sub-process /usr/bin/dpkg returned an error code (1)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#768600: readahead-fedora: cycle found while processing triggers

[Holger Levsen]

package: readahead-fedora
severity: serious
x-debbugs-cc: debian-d...@lists.debian.org

Hi,

I'm not 100% sure the following issue is caused by readahead-fedora, please 
reassign appropriatly if it is not. (eg or is it man-db?)

https://jenkins.debian.net/job/chroot-installation_wheezy_install_education-
standalone_upgrade_to_jessie/2/console found the following problem:

Processing triggers for man-db (2.7.0.2-2) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  readahead-fedora - readahead-fedora
 packages' pending triggers which are or may be unresolvable:
  fontconfig: /usr/share/fonts
  readahead-fedora: /etc/init.d
dpkg: error processing package fontconfig (--configure):
 triggers looping, abandoned
dpkg: ../../src/packages.c:226: process_queue: Assertion `dependtry = 4' 
failed.
sh: 1: /usr/sbin/update-alternatives: not found
E: Sub-process /usr/bin/dpkg exited unexpectedly

https://jenkins.debian.net/job/chroot-installation_wheezy_install_education-
desktop-gnome_upgrade_to_jessie/2//console shows a very similar error:

Processing triggers for man-db (2.7.0.2-2) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  readahead-fedora - readahead-fedora
 packages' pending triggers which are or may be unresolvable:
  gnome-menus: /usr/share/applications
  readahead-fedora: /etc/init.d
  gconf2: /usr/share/gconf/defaults
dpkg: error processing package gnome-menus (--configure):
 triggers looping, abandoned
dpkg: ../../src/packages.c:226: process_queue: Assertion `dependtry = 4' 
failed.
sh: 1: /usr/sbin/update-alternatives: not found

https://jenkins.debian.net/job/chroot-installation_wheezy_install_education-
common_upgrade_to_jessie/2//console shows another error:

Processing triggers for man-db (2.7.0.2-2) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  readahead-fedora - readahead-fedora
 packages' pending triggers which are or may be unresolvable:
  readahead-fedora: /etc/init.d
dpkg: error processing package readahead-fedora (--configure):
 triggers looping, abandoned
[...]
Errors were encountered while processing:
 readahead-fedora
E: Sub-process /usr/bin/dpkg returned an error code (1)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#659129: using pbzip2 or pigz when building packages

[Holger Levsen]

Hi Guillem,

thanks for following up on these bugs! And for maintaining dpkg in the first 
place! :-)

On Samstag, 14. Juni 2014, Guillem Jover wrote:
 I'm merging with the already filed bug report, because the request
 seems confused. The time spent when building kernel packages rests in
 dpkg-deb not dpkg-source, and native source packages or *.(debian|diff).*
 source packaging do not tend to be huge, so I'll assume the request was
 for binary and not source packages. Thus merging the requests.

actually this was about source+binary packages, the kernel sources are 
sufficiently large that it does make a difference whether to compress with one 
or many cores.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#746354: closed by Guillem Jover guil...@debian.org (Bug#746354: fixed in dpkg 1.17.9)

[Holger Levsen]

Hi Guillem,

thanks for fixing this bug so fast!


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#659129: using pbzip2 or pigz when building packages

[Holger Levsen]

package: dpkg-dev
severity: wishlist

Hi,

it would be awesome if dpkg-dev would support this nativly.


cheers,
Holger


--  Forwarded Message  --

Betreff: using pbzip2 or pigz when building packages
Datum: Mittwoch, 11. Januar 2012
Von: Holger Levsen hol...@layer-acht.org
An: debian-de...@lists.debian.org, cont...@bugs.debian.org

merge 513742 517249
thanks

Hi,

I'm currently regularly building kernels on a 24core machine which is really 
nice as it's fast but then it's not as fast as it could be as most of the time 
is spent tar'ing and zip'ing the resulting debian packages.

So I would like to use pbzip2 or pigz to make use of all the cores for this 
too. But this doesnt seem to be straightforward. #517249 would be one way to 
achieve this, another would be make dpkg-source use it directly. I'd prefer 
the latter.

Any other approaches I'm missing? 


cheers,
Holger

---



-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#609327: unpacking of 3.0 format creates files with perms 000

[Holger Levsen]

package: dpkg
version: 1.14.31

Hi,

I'm sponsoring the typo3-src packages into Debian and when a new request for 
sponsoring arrives I usually compare the new version with the old version 
with either debdiff or meld. 

Recently the package switched it source format to 3.0 and now some files have 
000 permissions after unpacking.

Steps to reproduce:

$ dget 
http://ftp.debian.org/debian/pool/main/t/typo3-src/typo3-src_4.5.0+dfsg1~beta2-3.dsc
[output ommitted]
$ cd typo3-src-4.5.0+dfsg1~beta2/
$ find . -perm 000
./.pc/05-add-source-for-mediaplayer-swfs.patch/typo3/contrib/flashmedia/src/flvplayer.as
./.pc/05-add-source-for-mediaplayer-swfs.patch/typo3/contrib/flashmedia/src/player/audio-player.flp
./.pc/05-add-source-for-mediaplayer-swfs.patch/typo3/contrib/flashmedia/src/player/control.as
./.pc/05-add-source-for-mediaplayer-swfs.patch/typo3/contrib/flashmedia/src/player/emff.as
./.pc/03-dummy-addindexpages.patch/dummy/uploads/tf/index.html
./.pc/03-dummy-addindexpages.patch/dummy/uploads/pics/index.html
./.pc/03-dummy-addindexpages.patch/dummy/uploads/media/index.html
./.pc/03-dummy-addindexpages.patch/dummy/fileadmin/index.html
./.pc/03-dummy-addindexpages.patch/dummy/fileadmin/user_upload/_temp_/index.html
./.pc/03-dummy-addindexpages.patch/dummy/fileadmin/user_upload/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3conf/ext/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3conf/l10n/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/temp/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/llxml/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/GB/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/pics/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/index.html
./.pc/03-dummy-addindexpages.patch/dummy/typo3temp/cs/index.html

That's a bummer for using meld...

(I'm in the process of uploading the next version, so if the above doesnt 
work, use typo3-src_4.5.0+dfsg1~beta3-1.dsc instead.)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#523745: please log sha1sum of installed debs

[Holger Levsen]

package: dpkg
severity: wishlist
tags: security
version: 1.14.25

Hi,

during a discussion about how to compromise the security of a Debian system I 
noticed that /var/log/dpkg.log just logs the version number of the packages 
installed, thus one can inject a on-the-fly-modified .deb with the same 
version number (provided the user ignores an apt authentication warning), 
which does harmful things and cleans up after itself with no trace on the 
machine, even if /var/log/dpkg.log is stored securily, ie with capabilities.

Please add an option to log the sha1sum of installed binary packgaes 
in /var/log/dpkg.log.

Thanks.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#523745: please log sha1sum of installed debs

[Holger Levsen]

Hi,

On Sonntag, 12. April 2009, Raphael Hertzog wrote:
 How can you tag this security while saying provided that the user doesn't
 care of the security. 

I was waking up (finishing my mental backlog from yesterday) and thought of a 
different meaning of security: affecting security, not causing a security 
isusue like what tag:security means in Debian. Sorry about that.

 And if the package is doing nasty things, it can also edit
 /var/log/dpkg.log.

Not if the file has the immutable, only append bit set.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.