Bug#906967: diffoscope fails on dumb terminals with 'bytes' object has no attribute 'format'
Package: diffoscope
Version: 99
Severity: normal
Tags: patch
The new eraser bar seems to break things when diffoscope is run on a
dumb terminal (or other similar weird environments, such as an emacs
M-x shell buffer).
The attached patches also clean up the spelling of "eraser" :)
--dkg
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'),
(200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages diffoscope depends on:
ii libpython3.6-stdlib3.6.6-1
ii python33.6.5-3
ii python3-distro 1.0.1-2
ii python3-distutils 3.6.6-1
ii python3-libarchive-c 2.1-3.1
ii python3-magic 2:0.4.15-2
ii python3-pkg-resources 39.2.0-1
Versions of packages diffoscope recommends:
pn abootimg
ii acl 2.2.52-3+b1
pn apktool
pn binutils-multiarch
ii bzip21.0.6-9
ii caca-utils 0.99.beta19-2+b3
pn colord
ii db-util 5.3.1
ii default-jdk [java-sdk] 2:1.10-68
ii default-jdk-headless 2:1.10-68
pn device-tree-compiler
pn docx2txt
ii e2fsprogs1.44.3-1
pn enjarify
ii fontforge-extras 0.3-4
pn fp-utils
ii genisoimage 9:1.1.11-3+b2
ii gettext 0.19.8.1-7
ii ghc 8.2.2-4
ii ghostscript 9.22~dfsg-2.1
pn giflib-tools
ii gnumeric 1.12.41-1
ii gnupg2.2.9-1
ii imagemagick 8:6.9.10.8+dfsg-1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1
pn jsbeautifier
pn libarchive-tools
pn llvm
pn lz4
ii mono-utils 4.6.2.7+dfsg-1
ii odt2txt 0.5-1+b2
ii oggvideotools0.9.1-4
ii openjdk-10-jdk [java-sdk]10.0.2+13-1
ii openssh-client 1:7.7p1-4
ii pgpdump 0.33-1
ii poppler-utils0.63.0-2
pn procyon-decompiler
pn python3-argcomplete
pn python3-binwalk
ii python3-debian 0.1.33
pn python3-defusedxml
pn python3-guestfs
pn python3-jsondiff
ii python3-progressbar 2.3-4
ii python3-pyxattr 0.6.0-2+b2
ii python3-tlsh 3.4.4+20151206-1+b4
ii r-base-core 3.5.1-1+b1
ii rpm2cpio 4.14.1+dfsg1-4
ii sng 1.1.0-1+b1
ii sqlite3 3.24.0-1
pn squashfs-tools
ii tcpdump 4.9.2-3
ii unzip6.0-21
ii vim-common 2:8.1.0229-1
pn xmlbeans
ii xxd 2:8.1.0229-1
ii xz-utils 5.2.2-1.3
Versions of packages diffoscope suggests:
ii libjs-jquery 3.2.1-1
-- no debconf information
>From 4e55793aa550e3e3d9fe84f41967c72689a4ca45 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 22 Aug 2018 14:31:03 -0400
Subject: [PATCH 1/2] correct spelling of ereser to eraser
---
diffoscope/comparators/__init__.py | 4 ++--
diffoscope/logging.py | 14 +++---
diffoscope/main.py | 4 ++--
diffoscope/progress.py | 4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/diffoscope/comparators/__init__.py
b/diffoscope/comparators/__init__.py
index 9098006..e885ccb 100644
--- a/diffoscope/comparators/__init__.py
+++ b/diffoscope/comparators/__init__.py
@@ -24,7 +24,7 @@ import logging
import importlib
import traceback
-from ..logging import line_ereser
+from ..logging import line_eraser
logger = logging.getLogger(__name__)
@@ -134,7 +134,7 @@ class ComparatorManager(object):
))
for x in errors:
logger.error("Original error for %s:", x[0])
-sys.stderr.buffer.write(line_ereser())
+sys.stderr.buffer.write
Re: Empty build-id to make package reproducible
On Thu 2018-08-30 21:08:51 +, Holger Levsen wrote: > (replying to the list with Otto's permission..) > > On Sun, Aug 05, 2018 at 02:51:16AM +0800, Otto Kekäläinen wrote: >> This is what we talked about today: >> https://salsa.debian.org/mariadb-team/galera-3/commit/1460cfa128fb457b5b5c60fcc5cac6faf5a216d5 > > I'm wondering, is this really a good approach? (to set build-id=none) > > I'm somewhat sceptical but then also a bit clueless here... ;) i'm also pretty ignorant about these details, but wouldn't that make it hard to find/match the debugging symbols? aiui, the build-id is used by gdb to find the symbols for debugging. for example: 0 dkg@alice:~$ file $(which notmuch) /usr/bin/notmuch: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ef8fab73e1088840f0c5abe7dcbdc5a1246272cd, stripped 0 dkg@alice:~$ dpkg -L notmuch-dbgsym | grep build-id.*debug$ /usr/lib/debug/.build-id/ef/8fab73e1088840f0c5abe7dcbdc5a1246272cd.debug 0 dkg@alice:~$ does this mean that galera-3 debugging symbols won't be easily findable? then again, the debugging symbols for galera-3 look like they're being generated in a way that is pretty out-of-date, and hasn't been touched in at least 3 years, so maybe the maintainers don't care about these symbols very much: https://salsa.debian.org/mariadb-team/galera-3/blame/master/debian/rules#L51 just my 2¢, --dkg ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Empty build-id to make package reproducible
Hi Otto-- On Fri 2018-08-31 09:44:18 +0300, Otto Kekäläinen wrote: > pe 31. elok. 2018 klo 0.46 Daniel Kahn Gillmor (d...@fifthhorseman.net) > kirjoitti: > .. >> does this mean that galera-3 debugging symbols won't be easily findable? > > Perhaps, but we decided that responsibility is important and the > package should pass the new CI pipeline we set up at > https://salsa.debian.org/mariadb-team/galera-3/pipelines/15700 > Note that this still just a commit on sitting on the master branch, > and it hasn't yet been uploaded anywhere and this might not be the > final solution. I'm not sure what you mean by "responsibility" here. Do you mean "reproducibility"? I agree that reproducibility is important! thanks for setting up this pipeline and pointing to it. I'll look into how to do that for other debian packages. :) That said, my experience with the build-id is that it becomes reproducible once everything else in the package is reproducible -- so it's typically a symptom of some other unreproducibility. If that's not the case for galera-3, that's an interesting outcome, and one that suggests that either (a) there is some other non-reproducible thing that the build process repairs *after* build-id is generated, or (b) my mental model of how the build-id is created is wrong. Do you know which one it is? if it's (a), can you point to any details? >> then again, the debugging symbols for galera-3 look like they're being >> generated in a way that is pretty out-of-date, and hasn't been touched >> in at least 3 years, so maybe the maintainers don't care about these >> symbols very much: >> >> >> https://salsa.debian.org/mariadb-team/galera-3/blame/master/debian/rules#L51 > > This package is actively maintained and everything should be up to > date. If you are an expert on debug package rules stanzas, we are > happy to take any suggestions (or merge requests on Salsa) to make > that section not so "pretty out-of-date". i'm not an expert on this stuff either, but i think the the changeover should be pretty simple. I've just filed an (untested) changeset as a merge request here: https://salsa.debian.org/mariadb-team/galera-3/merge_requests/1 My knowledge of debug symbols in debian derives in large part from the Debian wiki: https://wiki.debian.org/DebugPackage Thanks very much for your active work maintaining this project in debian, and for your attention to reproducibility! All the best, --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#908994: diffoscope: extract information from OpenPGP keys and signatures
Please remember to supply --batch whenever you invoke gpg from a script or other automated tooling! On Mon 2018-09-17 16:06:40 +0800, Paul Wise wrote: > For keys only: > > gpg --home $(mktemp -d) file Please don't use this form, it's broken and unsupported by upstream. There is no explicit command given, and gpg requires exactly one command. Until recently, there was no supported command, but with modern GnuPG there is: gpg --batch --show-keys < file for machine-parseable stuff or automated processing, you should also probably supply --with-colons. regards, --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Build ID & reproducible build
On Sun 2018-12-02 11:25:47 +0100, Domenico Andreoli wrote: > in working at making dwarves [0] build reproducible I stumbled upon > the Build ID, which is just the root of tons of other diffs. > > diffoscope highlights: > > │ │ │ │ Displaying notes found in: .note.gnu.build-id > │ │ │ │Owner Data size Description > │ │ │ │GNU 0x0014 NT_GNU_BUILD_ID (unique build > ID bitstring) > │ │ │ │ -Build ID: 6f3f14da239d0b68ba179ee7a2f2570c4d970db0 > │ │ │ │ +Build ID: c68caf4dba0ea46c05dddf9405bda4290c6ceaa6 The build ID is for associating debug files with their active binaries. They are deterministically generated from the binaries themselves. So while it may look like a "root cause", i think you've got the causality reversed -- this is a symptom, and not a cause. As long as any variation exists in the binaries, the build ID will differ. Once the binaries are concretely reproducible, the build ID will become reproducible too. i agree with you that this should be documented someplace. i don't know whether it already is written up someplace though (i haven't really searched). --dkg ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote: > As "--changes-option=-S" creates an upload that is broken from the point of > view of the archive, it might make sense not to recommend (or even allow) this > for now. Just building with "-S" instead should create a buildinfo file with > _source, which won't trigger this issue. For the rest of the regular archive, --changes-option=-S is definitely *not* broken. I use that regularly, and strongly prefer it. It allows me to document what i managed to build, while still ensuring that the distributed binaries are created by debian's buildd network, and not my own machinery. I would be pretty sad if --changes-option=-S was explicitly deprecated in any part of the debian archive. --dkg signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
