Search Results: "ghedo"

15 September 2017

Chris Lamb: Which packages on my system are reproducible?

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users. The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced either maliciously or accidentally during this compilation process. As part of this project I wrote a script to determine which packages installed on your system are "reproducible" or not:
$ apt install devscripts
[ ]
$ reproducible-check
[ ]
W: subversion (1.9.7-2) is unreproducible (libsvn-perl, libsvn1, subversion) <https://tests.reproducible-builds.org/debian/subversion>
W: taglib (1.11.1+dfsg.1-0.1) is unreproducible (libtag1v5, libtag1v5-vanilla) <https://tests.reproducible-builds.org/debian/taglib>
W: tcltk-defaults (8.6.0+9) is unreproducible (tcl, tk) <https://tests.reproducible-builds.org/debian/tcltk-defaults>
W: tk8.6 (8.6.7-1) is unreproducible (libtk8.6, tk8.6) <https://tests.reproducible-builds.org/debian/tk8.6>
W: valgrind (1:3.13.0-1) is unreproducible <https://tests.reproducible-builds.org/debian/valgrind>
W: wavpack (5.1.0-2) is unreproducible (libwavpack1) <https://tests.reproducible-builds.org/debian/wavpack>
W: x265 (2.5-2) is unreproducible (libx265-130) <https://tests.reproducible-builds.org/debian/x265>
W: xen (4.8.1-1+deb9u1) is unreproducible (libxen-4.8, libxenstore3.0) <https://tests.reproducible-builds.org/debian/xen>
W: xmlstarlet (1.6.1-2) is unreproducible <https://tests.reproducible-builds.org/debian/xmlstarlet>
W: xorg-server (2:1.19.3-2) is unreproducible (xserver-xephyr, xserver-xorg-core) <https://tests.reproducible-builds.org/debian/xorg-server>
282/4494 (6.28%) of installed binary packages are unreproducible.
Whether a package is "reproducible" or not is determined by querying the Debian Reproducible Builds testing framework.


The --raw command-line argument lets you play with the data in more detail. For example, you can see who maintains your unreproducible packages:
$ reproducible-check --raw   dd-list --stdin
Alec Leamas <leamas.alec@gmail.com>
   lirc (U)
Alessandro Ghedini <ghedo@debian.org>
   valgrind
Alessio Treglia <alessio@debian.org>
   fluidsynth (U)
   libsoxr (U)
[ ]


reproducible-check is available in devscripts since version 2.17.10, which landed in Debian unstable on 14th September 2017.

15 December 2013

Alessandro Ghedini: Building Debian packages using Linux namespaces

In the past few days I have been messing around with Linux namespaces, and developed a little tool (pflask) that automates the creation of simple Linux containers based on them (a sort of chroot(8) on steroids if you will). While the whole raison d' tre behind this project was "just because", and many more mature solutions exist, I decided that it'd be nice to find an actual use case for this (otherwise I tend to lose interest pretty quickly) so I wrote a lil (and rather dumb) pbuilder clone that uses pflask instead of chroot. The nice thing about pflask is that, differently from e.g. LXC, it doesn't need any pre-configuration and can be used directly on a vanilla debootstrap(8)ed Debian system:
$ sudo mkdir -p /var/cache/pflask
$ sudo debootstrap --variant=buildd $DIST /var/cache/pflask/base-$DIST-$ARCH
Where $DIST and $ARCH are e.g. unstable and amd64. Once that's done just run pflask-debuild on the package sources:
$ apt-get source somepackage
$ cd somepackage-XYX
$ pflask-debuild
The script will take care of creating a new container, chroot(2)ing into it, installing all the required dependencies, building and signing the package (it also runs lintian!). The main difference from pbuilder is that pflask will mount a copy-on-write filesystem (using AuFS) on the / of the container so that any modification (e.g. installation of packages) can be easily discarded once the container terminates (similarly to what cowbuilder(8) does, modulo the hardlinks hack). Additionally, thanks to the mount namespace created inside the container, all of this will be isolated from the host system and other containers, so that multiple packages can be built simultaneously on the same base debootstrapped directory. Another possibility would be that of disabling the network inside the container using a network namespace, in order to prevent the package build system from downloading stuff from Internet while at the same time maintaining the network active on the host system, but I haven't done any experiment in this direction yet. Note though that all of this is rather crude and experimental, but as a little hack it seems to work rather well (YMMV).

23 October 2011

Gregor Herrmann: RC bugs 2011/42

this week my activities were split between some freshly-reported pkg-perl bugs, & looking at some of the older RC bugs. for most of the ones in the latter category I found again ready-to-be-applied patches, many of them from Ubuntu again. details:

2 October 2011

Gregor Herrmann: RC bugs 2011/39

another weekly report about RC bugs I've fixed, this time mostly by applying patches from ubuntu:

3 September 2011

Gregor Herrmann: RC bugs 2011/21 - 2011/35

over 3 months without a posting about my RC bug squashing activities. that also means I hardly looked at any bugs in packages I'm not (co-)maintaining. anyway, here's the list of fixed RC bugs:

24 July 2011

Dominique Dumont: Perl6 (aka rakudo) is available on Debian

Hello I m happy to announce that Perl6 (as rakudo) is now available on Debian unstable. Thanks also to Gabor Szabo for the Perl6 talk he gave at FOSDEM. His talk made me think: Why the hell don t we have rakudo on Debian ? . So I stepped up, pushed to get a recent parrot package, ghedo and I created a pkg-rakudo team on Alioth, and we updated the old rakudo package done by ryan52. Enjoy

23 May 2011

Gregor Herrmann: RC bugs 2011/11 - 2011/20

long time no post about my RC bug fixing activities. & indeed, I haven't been very active during the last weeks. here's a quick update; it includes two NMUs done for the perl 5.12 transition, the rest is just "normal" maintainance work (interesting to see how much stuff can break behind our backs ...). I still hope to find some more time in the future to look at other RC bugs; after all we want to have a not-too-long freeze for wheezy, don't we?