Bug#1038980: ITP: guile-avahi -- guile bindings for avahi
Package: wnpp Owner: Vagrant Cascadian X-Debbugs-Cc: debian-devel@lists.debian.org, vagr...@debian.org, l...@gnu.org Severity: wishlist * Package name: guile-avahi Version : 0.4.1 Upstream Contact: l...@gnu.org, guile-avahi-b...@nongnu.org * URL : https://www.nongnu.org/guile-avahi/ * License : LGPL, GPL, permissive Programming Lang: guile, C Description : guile bindings for avahi This package provides bindings for Avahi. It allows programmers to use functionalities of the Avahi client library from Guile Scheme programs. Avahi itself is an implementation of multicast DNS (mDNS) and DNS Service Discovery (DNS-SD). guile-avahi is a build-dependency for guix, although it can technically be built without it and does not use avahi by default, if enabled at runtime, it errors out in non-obvious ways: https://lists.gnu.org/archive/html/help-guix/2023-06/msg00083.html https://bugs.debian.org/1038916 Draft packaging available: https://salsa.debian.org/vagrant/guile-avahi Currently, guix and related guile packages are primarily maintained by me alone, but would welcome help! live well, vagrant
Re: FTBFS on all recent uploads
On 2023-06-22, Boyuan Yang wrote: > 在 2023-06-20星期二的 06:31 +0200，Joachim Zobel写道： >> I have a FTBFS on all uploads after the end of the freeze. Example: >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gap-aclib.html >> >> All these packages had been changed to compat 13. Unfortunately I have >> no idea why I get these. I can see two logs of successful builds and a >> diff for them. At the end of each log I find reproducible ➤ FTBFS, so >> this probably is because my build fails to be reproducible. However the >> only diff I see is the diff between the build logs. >> >> Any hints on what to do about these would be helpful. > > In the link above, when clicking "build2" under amd64 1.3.2-3--build2, the log > shows that the build machine raised an error before your source code > actually got built. It might be a machine configuration error. Forwarding > your email to Debian reproducible-builds mailing list since they may know > more about it. We had a few glitches after the bookworm released, but I *think* they should be sorted out by now... FTBFS do get rescheduled fairly often, and if you really need, they can be manually rescheduled (if you are a debian developer, you should be able to click on the triangle of arrows to reschedule). live well, vagrant signature.asc Description: PGP signature
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On 2023-02-08, Stéphane Glondu wrote: > Thank you all for your answers! > > Using: > >DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath > > makes the package unreproducible in another way that seems difficult to fix. Most likely reintroducing the things that the -ffile-prefix-map and -fdebug-prefix-map was effectively removing... We track these kinds of issues with the "records build flags" issue, which has a description of the problem and links to more information: https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html There are some potential fixes to the issue more fundamentally, but they are currently stalled out... one of which I should probably spend some time on after bookworm release... You had earlier asked when this was enabled, this can mostly be found in the dpkg changelog: fixfilepath (a.k.a. -ffile-prefix-map) Enabled by default: dpkg (1.20.6) unstable; urgency=medium ... * dpkg-buildflags: Enable reproducible=fixfilepath by default. Thanks to Vagrant Cascadian . See https://lists.debian.org/debian-devel/2020/10/msg00222.html. Closes: #974087 ... -- Guillem Jover Fri, 08 Jan 2021 04:39:40 +0100 fixfilepath (a.k.a. -ffile-prefix-map) feature added, and enabled in reproducible builds infrastructure soon after: dpkg (1.19.1) unstable; urgency=medium ... - Dpkg::Vendor::Debian: Add fixfilepath support to reproducible feature. ... -- Guillem Jover Wed, 26 Sep 2018 15:13:22 +0200 fixdebugpath (a.k.a. -fdebug-prefix-map) enabled by default: dpkg (1.18.10) unstable; urgency=medium ... - Enable fixdebugpath build flag feature by default. Thanks to Mattia Rizzolo . Closes: #832179 ... -- Guillem Jover Sun, 31 Jul 2016 12:57:02 +0200 fixdebugpath (a.k.a. -fdebug-prefix-map) feature added, and presumably enabled in reproducible builds infrastructure soon after: dpkg (1.18.5) unstable; urgency=medium ... - Add fixdebugpath to reproducible feature in Dpkg::Vendor::Debian. Thanks to Daniel Kahn Gillmor . Closes: #819194 ... -- Guillem Jover Mon, 02 May 2016 04:14:57 +0200 Of course, this is only for packages respecting dpkg-buildflags. > Le 07/02/2023 à 19:12, Mattia Rizzolo a écrit : >> I actually propose to you to filter out the whole option from being >> saved. [...] > > I've gone this way, and managed to make the package reproducible, at > least with the build path variation. Glad that works! > I will upload the fixed ocaml package when the current batch of related > packages waiting in unstable migrates to testing, hopefully in 4 days. Thanks! live well, vagrant signature.asc Description: PGP signature
Bug#1025776: O: amavisd-milter -- amavisd-new interface for milter-capable MTAs
Package: wnpp Severity: normal Description: amavisd-new interface for milter-capable MTAs This package provides a milter for amavisd-new that works with Sendmail or Postfix, using the AM.PDP protocol. . Replacing the older amavisd-new-milter program, amavisd-milter makes use of the full functionality of amavisd-new. It supports using spam and virus information header fields, rewriting message subjects, adding address extensions, and selectively removing recipients. signature.asc Description: PGP signature
Re: Including build metadata in packages
On 2022-02-16, Simon McVittie wrote: > On Sun, 13 Feb 2022 at 14:13:10 -0800, Vagrant Cascadian wrote: >> Obviously, this would interfere with any meaningful reproducible builds >> testing for any package that did something like this. Ideally metadata >> like this about a build should *not* be included in the .deb files >> themselves. > > Relatedly, I would like to be able to capture some information about > builds even if (perhaps especially if) the build fails. It might make > sense to combine that with what you're looking at. It doesn't seem > ideal that for a successful build, the maintainer can recover detailed > results via a .deb (at a significant reproducibility cost), but for a > failing build - perhaps one that fails as a result of test regressions > - they get no information other than what's in the log. If anything, > these artifacts seem *more* important for failing builds. Yes, thanks for bringing up the potential for getting better information out of failed builds; that is a valueable angle to consider! >> * Split build metadata into a separate file or archive >> >> Some of the debian-installer packages generate tarballs that are not >> .deb files and are included in the .changes files when uploading to the >> archive; making a similar generalized option for other packages to put >> build metadata into a separate artifact might be workable approach, >> although this would presumably require toolchain changes in dpkg and dak >> at the very least, and might take a couple release cycles, which >> is... well, debian. >> >> The possibility of bundling up .buildinfo files into this metadata too, >> while taking some changes in relevent dpkg, dak, etc. tooling, might in >> the long term be worth exploring. >> >> There was a relevent bug report in launchpad: >> >> https://bugs.launchpad.net/launchpad/+bug/1845159 >> >> This seems like the best long-term approach, but pretty much *only* a >> long-term approach... > > I think even if we do one of the other approaches as a stopgap, we'll > want this in the long term. > > There are two approaches that could be taken to this. One is to use > BYHAND, as Paul Wise already discussed. This would require action from the > ftp team and dak (I think), but nothing special in sbuild or the buildd > infrastructure. > > However, I'd prefer it if this was output from the build alongside the log, > instead of being exported via the .changes file, so that failing builds > can also produce artifacts, to help the maintainer and/or porters to > figure out why the build failed. This would require action in sbuild and > the buildd infrastructure, but not in dak, because handling build logs is > not dak's job (and I don't think handling things like the binutils test > results should be dak's job either). > > Here's a straw-man spec, which I have already prototyped in > <https://salsa.debian.org/debian/sbuild/-/merge_requests/14>: > > Each whitespace-separated token in the Build-Artifacts field represents > a filename pattern in the same simplified shell glob syntax used in > "Machine-readable debian/copyright file", version 1.0. > > If the pattern matches a directory, its contents are included in > the artifacts, recursively. If a pattern matches another file type, > it is included in the artifacts as-is. If a pattern does not match > anything, nothing is included in the artifacts: this may be diagnosed > with a warning, but is not an error. > > If a pattern matches files outside the build directory, is an absolute > path or contains ".." segments, build tools may exclude those files > from the artifacts. > > Build tools should collect the artifacts that match the specified > patterns, for example in a compressed tar archive, and make them > available alongside the build log for inspection. The artifacts should > usually be collected regardless of whether the build succeeds or fails. > > The Build-Artifacts field is not copied into the source package control > file (dsc(5)), binary package control file (deb-control(5)), > changes file (deb-changes(5)) or any other build results. > > (To prototype this without dpkg supporting it, X-Build-Artifacts would be > appropriate, with none of the XS-, XB-, XC- prefixes.) > > For example, a package using Meson with recent debhelper versions would > typically use: > > Build-Artifacts: obj-*/meson-logs > > or a package using recursive Automake might use: > > Build-Artifacts: > config.log > tests/*.log > tests/
Re: Including build metadata in packages
On 2022-02-14, Paul Wise wrote: > On Sun, 2022-02-13 at 14:13 -0800, Vagrant Cascadian wrote: > >> * Split build metadata into a separate file or archive >> >> Some of the debian-installer packages generate tarballs that are not >> .deb files and are included in the .changes files when uploading to >> the archive; making a similar generalized option for other packages to >> put build metadata into a separate artifact might be workable approach, >> although this would presumably require toolchain changes in dpkg and >> dak at the very least, and might take a couple release cycles, which >> is... well, debian. > > I already sent a mail like this in the past, but... > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950585#30 > > This approach is already in use in the archive, but not > yet for the kind of artefacts that you are talking about: > > https://codesearch.debian.net/search?perpkg=1&q=dpkg-distaddfile > https://salsa.debian.org/ftp-team/dak/raw/master/config/debian/dak.conf > (search for AutomaticByHandPackages) > https://salsa.debian.org/ftp-team/dak/raw/master/daklib/upload.py (search for > byhand_files) > https://salsa.debian.org/ftp-team/dak/tree/master/scripts/debian/ > > I think this would not require anything except a new dak config stanza > for AutomaticByHandPackage and potentially a patch to dak code or a > script. Seems unlikely it would require changes to anything other than > dak plus the packages that want to opt in to using it, so should be > completely doable within the bookworm release cycle. I took a peek at this approach finally, and it looks like binutils would be relatively trivial to support, but things like gcc-11, gcc-N would need regular intervention from ftpmasters (unless some sort of pattern matching rules were added). At least, one more step for the NEW processing to consider... > If you want to have some way to automatically download the data, then > something like apt-file and Contents files could be done, I expect that > would also be able to be done for the bookworm release and also be > possible to put in bullseye-backports. > > You could even include all the build logs and build info in the same > data set, and potentially modify the package build process so that > build logs for maintainer built binaries end up there too. > > Something like this would be my suggested archive structure: > > Release -> Builds-amd64 -> foo_amd64.build > \ \-> foo_amd64.buildinfo > \--> foo_amd64.buildmeta.tar.xz > > Or since the buildinfo files are similar to Packages/Sources stanzas: > > Release -> BuildLogs-amd64 -> foo_amd64.build.xz > \ \-> BuildInfo-amd64 > \--> BuildMeta-amd64 -> foo_amd64.buildmeta.tar.xz > > This could be in the main archive, or a separate debian-builds archive. For reproducible builds, this doesn't actually end up being very different from just shipping a FOO-unreproducible.deb, as reproducible builds tests would still have to exclude FOO_ARCH.buildmeta.tar.xz from the comparisons anyways, if they end up being listed in the .changes (and .buildinfo?) files. Though, it does open the door to other possibilities. Putting all the .buildinfo files in this buildmeta.tar.xz would finally get in-archive distribution of .buildinfo files, which would be very nice... live well, vagrant signature.asc Description: PGP signature
Re: Embedded buildpath via rpath using cmake
On 2022-02-03, Vagrant Cascadian wrote: > Over the last several months, I and others have found quite a few > packages that embed build paths via rpath when building with cmake. I > found myself slowly edging into a mass bug filing, one bug report at a > time... > > I ended up submitting a few patches and noting some affected packages: > > > https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html > > There are almost certainly packages missing from that list, as it is > generated by human confirmation... So in the last couple months I kept finding more packages affected by this; the above URL now has confirmed 380+ packages affected by this issue, a few of which are are now fixed, thanks! On those I've tested and confirmed, I've either submitted a patch and/or mentioned in comments for the package in the reproducible builds notes, which you can see by clicking on the referenced package in the above URL, or searching for the relevent package in: https://salsa.debian.org/reproducible-builds/reproducible-notes/-/blob/master/packages.yml I don't know for sure that this is a comprehensive list of affected packages; I've mostly identified packages that fail to build with build path variations and had otherwise no known cause, or used other identified issues that apparently had a direct correlation to this issue. Doing a systematic search for all packages that use cmake to build and fail to build reproducibly in unstable or experimental would probably be the next step to identify any remaining packages... > In many cases I've tested so far, passing an argument via a > dh_auto_configure override in debian/rules fixes the issue: > >override_dh_auto_configure: >dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON > > > Alternately, the experimental debhelper compat level v14 does include a > fix for these embedded rpaths, though in the current state, passing both > -DCMAKE_SKIP_RPATH=ON and -DCMAKE_RPATH_USE_ORIGIN=ON, it triggers build > failures 263 packages, according to a test run by Lucas Nussbaum in > October: > > http://qa-logs.debian.net/2021/10/25/diff.dcsr.txt > > > Since debhelper v14 is not finalized yet, I just sent a request to > debhelper to only pass one of the arguments, > -DCMAKE_RPATH_USE_ORIGIN=ON, which should significantly reduce the > number of build failures while still making many packages reproducible > with debhelper compat v14: > > https://bugs.debian.org/1004939 Haven't gotten any comment on this from the debhelper maintainers yet... There are a few where -DCMAKE_RPATH_USE_ORIGIN=ON does trigger test failures or otherwise causes build failures (some had test suite failures without changes), but my off the cuff guess is ~2% of the ~380 noted packges; less than I could count on both hands using very simple methods. This should be significantly less that -DCMAKE_SKIP_RPATH=ON... It seems like it is not possible to actually create something like a lintian warning for this, as the actual build path is stripped out before creating the .deb package; the only result is for the most part a different build id and a few small changes in the binaries. Would, of course, be happy to be proven wrong! I've added a new list of affected maintainers produced with dd-list with the packages marked with the "cmake_rpath_contains_build_path" issue that haven't yet been fixed in some way according to tests.reproducible-builds.org. Thanks everyone! live well, vagrant "Adam C. Powell, IV" oce (U) A. Maitland Bottoms airspyone-host codec2 gr-fosphor gr-funcube (U) gr-hpsdr (U) gr-iqbal gr-osmosdr gr-radar gr-rds hackrf libfreesrp rtl-sdr volk Adam Borowski pmdk-convert pmemkv Adrian Knoth libdrumstick (U) Alastair McKinstry ecflow mathgl (U) Alberto Garcia cog Alberto Luaces Fernández openscenegraph Alessio Treglia fluidsynth (U) libdrumstick (U) Alf Gaida libqtxdg (U) lxqt-config (U) lxqt-globalkeys (U) nomacs (U) screengrab (U) Andrea Capriotti userbindmount (U) vdeplug4 (U) Andreas Bombe soapyosmo (U) soapysdr (U) Andreas Cord-Landwehr kdevelop-python (U) Andreas Metzler hugin (U) libpano13 (U) Andreas Rönnquist allegro5 (U) Andreas Tille bamtools (U) civetweb (U) libminc (U) openmm (U) prime-phylo (U) spoa (U) Andrew Lee (李健秋) libqtxdg (U) lxqt-config (U) lxqt-globalkeys (U) nomacs (U) screengrab (U) Andrey Rahmatullin librsync Andrius Merkys libemf2svg (U) macromoleculebuilder (U) openmm (U) Antoine Beaupré slop Anton Gladky libopenshot (U) liggghts (U) metis (U) tetgen (U) Antonio Ospite libam7xxx Apollon Oikonomopoulos leatherman (U) A
Including build metadata in packages
A while ago I noticed binutils had some embedded logs in one of it's packages, which included timing information about the test suite runs which will almost certainly have differences between the different builds, even on the exact same machine: https://bugs.debian.org/950585 My proposed patch removed the timing information and various other things, but was exactly the information wanted from these files, so was not an appropriate patch. It also became known that other key toolchain packages (e.g. gcc) also embed similar log files in the .deb packages... I have since found a few other packages that do similar things: https://tests.reproducible-builds.org/debian/issues/unstable/test_suite_logs_issue.html Obviously, this would interfere with any meaningful reproducible builds testing for any package that did something like this. Ideally metadata like this about a build should *not* be included in the .deb files themselves. I'll try to summarize and detail a bit some of the proposed strategies for resolving this issue: * output plaintext data to the build log Some of these log files are large (>13MB? per architecture, per package build) and would greatly benefit from compression... How large is too large for this approach to work? Relatively simple to implement (at least for plain text logs), but potentially stores a lot of data on the buildd infrastructure... * Selectively filter out known unreproducible files This adds complexity to the process of verification; you can't beat the simplicty of comparing checksums on two .deb files. With increased complexity comes increased opportunity for errors, as well as maintenance overhead. RPM packages, for example, embed signatures in the packages, and these need to be excluded for comparison. I vaguely recall at least one case where attempting something like this in the past and resulting in packages incorrectly being reported as reproducible when the filter was overly broad... Some nasty corner cases probably lurk down this approach... * Split build metadata into a separate .deb file Some of the similar problems of the previous, though maybe a little easier to get a reliable exclusion pattern? Wouldn't require huge toolchain changes. I would expect that such packages be not actually dependend on by any other packages, and *only* contain build metadata. Maybe named SOURCEPACKAGE-buildmetadata-unreproducible.deb ... or ? Not beautiful or elegant, but maybe actually achievable for bookworm release cycle? * Split build metadata into a separate file or archive Some of the debian-installer packages generate tarballs that are not .deb files and are included in the .changes files when uploading to the archive; making a similar generalized option for other packages to put build metadata into a separate artifact might be workable approach, although this would presumably require toolchain changes in dpkg and dak at the very least, and might take a couple release cycles, which is... well, debian. The possibility of bundling up .buildinfo files into this metadata too, while taking some changes in relevent dpkg, dak, etc. tooling, might in the long term be worth exploring. There was a relevent bug report in launchpad: https://bugs.launchpad.net/launchpad/+bug/1845159 This seems like the best long-term approach, but pretty much *only* a long-term approach... I'd really like to remove this hurdle to reproducible builds from some key packages like binutils and gcc, but also curious about a generalizable approach so each package needing something like this doesn't reinvent the wheel in incompatible ways... Curious to hear your thoughts! live well, vagrant p.s. please consider CCing me and/or reproducible-bui...@lists.alioth.debian.org, as I'm not subscribed to debian-devel. signature.asc Description: PGP signature
Re: Embedded buildpath via rpath using cmake
On 2022-02-04, Simon McVittie wrote: > On Fri, 04 Feb 2022 at 13:07:53 +0800, Paul Wise wrote: >> Vagrant Cascadian wrote: >> > Over the last several months, I and others have found quite a few >> > packages that embed build paths via rpath when building with cmake. >> >> This seems like the sort of thing that will be an ongoing problem, so >> if it is detectable statically then a lintian warning might be good. > > For packages that (intentionally or unintentionally) still have a RPATH > or RUNPATH in their installed files, > https://lintian.debian.org/tags/custom-library-search-path detects it. > You'll see that many of them are overridden as being necessary and > intentional. I was hoping to find a few of the cmake packages on there (e.g. /build/PACKAGE-*/PACKAGE-VERSION), but it appears the only ones on that list do not use cmake to build... > For packages where the RPATH or RUNPATH is temporarily set during build > (to be able to run unit tests without setting LD_LIBRARY_PATH) but then > removed before installation with `chrpath -d` or equivalent code in CMake, > I don't think this is going to be detectable statically, because the > only traces left in the final binary are: > > - the build-ID will be different, because the RPATH/RUNPATH was part of > the data that gets hashed to create the build-ID > - if the length of the build directory changes, then the block of zero > bytes that previously contained the RPATH/RUNPATH (before it was > overwritten) will have a different length But clearly some of the above is happening... > This is the sort of thing that can probably only be detected by literally > doing two builds (in different directories) and comparing them with > diffoscope Yeah, that's pretty much the conclusion I came to. > or possibly by screen-scraping build logs like blhc does. That could be an interesting approach, though relies on fairly verbose build logs. Thanks! live well, vagrant p.s. please CC me and/or reproducible-bui...@lists.alioth.debian.org, I'm not subscribed to debian-devel. signature.asc Description: PGP signature
Re: Embedded buildpath via rpath using cmake
On 2022-02-04, David Prévot wrote: > Le 04/02/2022 à 08:58, Andreas Ronnquist a écrit : >> On Thu, 03 Feb 2022 16:41:21 -0800, >> Vagrant Cascadian wrote: > >>> If you're on the list, would love if you could check if your package >>> still builds correctly when passing only >>> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON. For a few of the packages, there >>> are already patches in the Debian bug tracking system waiting for you! >> >> allegro5 builds fine here when adding -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON. > > Ditto for cmocka. Thanks for testing! > Is there a better place than this debian-devel thread to document what > works or not? The developer's reference suggests mailing debian-devel with a list of affected packages/maintainers instead of mass filing bugs, so that's what I did (well, after filing lots of bugs/patches already)... :) If we want to track the issues, to me it seems like the best way to track these issues are bugs with usertags... So I guess I'm a bit confused as to the goal of not mass filing bugs! Maybe the goal is to have as many maintainers address the issue before getting bugs.debian.org involved, and only once some time passes, proceed to filing actual bugs? Another option is to add a comment to the package in: https://salsa.debian.org/reproducible-builds/reproducible-notes I'll do this for the two mentioned so far. live well, vagrant p.s. Please Cc me and/or reproducible-bui...@lists.alioth.debian.org on this thread, as I'm not subscribed to debian-devel. signature.asc Description: PGP signature
Re: Embedded buildpath via rpath using cmake
On 2022-02-04, Seth Arnold wrote:
> On Thu, Feb 03, 2022 at 04:41:21PM -0800, Vagrant Cascadian wrote:
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake. I
>> found myself slowly edging into a mass bug filing, one bug report at a
>> time...
>
> Hello Vagrant, does this represent a security problem?
Other than reproducible builds in general providing some security
properties, I would say not really.
> I tried to give this a look myself but didn't know what to look for; I
> grabbed a few recent versions of packages:
>
> http://ftp.debian.org/debian/pool/main/n/nfs-ganesha/nfs-ganesha_3.4-1_amd64.deb
One thing is checking the reproducible builds results:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nfs-ganesha.html
Which appear to have reproducibility issues in the unstable tests, where
build paths are varied, but not in bookworm, where build paths are not
varied.
Unfortunately, the diffoscope output linked above does not obviously
show the build path embedded in the binaries (other than some .py files,
which may be a separate issue).
There are a few lines which are non-obvious, but are in my experience a
sign of different build paths:
0x000a·(STRSZ)··2327·(bytes)
vs.
0x000a·(STRSZ)··2329·(bytes)
My going theory is that the length of the build path is embedded in a
padded value, even though the build path itself is actually stripped,
perhaps via -ffile-prefix-map=BUILDPATH=. or similar.
> http://ftp.debian.org/debian/pool/main/v/vmemcache/libvmemcache0_0.8.1-4_amd64.deb
> http://ftp.debian.org/debian/pool/main/f/fontforge/fontforge_20201107~dfsg-4_amd64.deb
>
> $ find . -type f -exec eu-readelf -d {} \; 2>/dev/null | grep RUNPATH
> RUNPATH Library runpath: [/usr/lib/ganesha]
> RUNPATH Library runpath: [/usr/lib/ganesha]
> RUNPATH Library runpath: [/usr/lib/ganesha]
> RUNPATH Library runpath: [/usr/lib/ganesha]
>
> Am I on the wrong track?
Because it doesn't often leave obvious traces of the build path in the
binaries, it is a bit tricky to test simply by examining the binaries
directly... Instead, experimentation seems to be the best way.
I use reprotest for this, first running a build with reprotest without
the patch, confirming that it builds at all, and does not build
reproducibly. Then running reprotest with the patch applied to add
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON in debian/rules, and seeing if it
builds reproducibly.
From the source directory, with the build dependencies installed:
reprotest --verbose --store-dir=$(mktemp -d $HOME/buildresults-XX)
--vary=-all,+build_path -- null
This should normalize the build as much as possible so that the only
thing different between the two builds is the build path.
Then compare the resulting buildresults-*/*.out to see if the second
build produces significantly less diffoscope output...
live well,
vagrant
signature.asc
Description: PGP signature
Re: Embedded buildpath via rpath using cmake
On 2022-02-04, Paul Wise wrote: > Vagrant Cascadian wrote: > >> Over the last several months, I and others have found quite a few >> packages that embed build paths via rpath when building with cmake. > > This seems like the sort of thing that will be an ongoing problem, so > if it is detectable statically then a lintian warning might be good. So far I have only figured out how to detect it by building packages and checking if they're reproducible, but if someone can figure out how to make it work from lintian, so much the better! I believe there is a lintian check for build paths embedded in binaries, at least, which will catch this and other issues, but maybe it could be extended to check for this more explicitly... live well, vagrant signature.asc Description: PGP signature
Embedded buildpath via rpath using cmake
Over the last several months, I and others have found quite a few packages that embed build paths via rpath when building with cmake. I found myself slowly edging into a mass bug filing, one bug report at a time... I ended up submitting a few patches and noting some affected packages: https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html There are almost certainly packages missing from that list, as it is generated by human confirmation... In many cases I've tested so far, passing an argument via a dh_auto_configure override in debian/rules fixes the issue: override_dh_auto_configure: dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON Alternately, the experimental debhelper compat level v14 does include a fix for these embedded rpaths, though in the current state, passing both -DCMAKE_SKIP_RPATH=ON and -DCMAKE_RPATH_USE_ORIGIN=ON, it triggers build failures 263 packages, according to a test run by Lucas Nussbaum in October: http://qa-logs.debian.net/2021/10/25/diff.dcsr.txt Since debhelper v14 is not finalized yet, I just sent a request to debhelper to only pass one of the arguments, -DCMAKE_RPATH_USE_ORIGIN=ON, which should significantly reduce the number of build failures while still making many packages reproducible with debhelper compat v14: https://bugs.debian.org/1004939 I've attached a list of the maintainers of affected packages produced with dd-list, getting the list of packages from the above-mentioned reproducible builds issue and diff.dcsr.txt from archive rebuild. If you're on the list, would love if you could check if your package still builds correctly when passing only -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON. For a few of the packages, there are already patches in the Debian bug tracking system waiting for you! Thanks everyone! live well, vagrant "Adam C. Powell, IV" oce (U) A. Maitland Bottoms gr-funcube (U) gr-gsm (U) gr-hpsdr (U) gr-iqbal gr-limesdr (U) gr-satellites (U) libad9361 Adam Borowski pmemkv vmemcache Aigars Mahinovs dlt-daemon Alastair McKinstry libtool mathgl (U) Alberto Luaces Fernández openscenegraph Alessio Di Mauro yubico-piv-tool (U) Alessio Treglia leveldb (U) libsoxr (U) Alexander GQ Gerasiov croaring Alexandre Marie ufo-core (U) Alf Gaida juffed (U) screengrab (U) Andrea Capriotti userbindmount (U) vdeplug4 (U) Andreas Beckmann pocl (U) Andreas Bombe gr-limesdr (U) soapyosmo (U) soapysdr (U) Andreas Rönnquist allegro5 (U) Andreas Tille libbpp-seq (U) libbpp-seq-omics (U) liblemon (U) libminc (U) libvbz-hdf-plugin (U) libzeep (U) openmm (U) spoa (U) Andrew Lee (李健秋) screengrab (U) Andrew Pollock log4cplus Andrey Rahmatullin librsync Andrius Merkys openmm (U) openstructure (U) Ansgar dune-common (U) dune-geometry (U) dune-grid (U) dune-grid-glue (U) dune-uggrid (U) Anthony Fok fontforge (U) Anton Gladky alglib (U) benchmark (U) cctz (U) kim-api (U) libopenshot (U) liggghts (U) metis (U) tetgen (U) vtk9 (U) Apollon Oikonomopoulos leatherman (U) Arne Bernin libfreenect (U) Aron Xu fcitx (U) libgooglepinyin (U) Aurelien Jarno libftdi libftdi1 Aurélien COUDERC analitza (U) artikulate (U) elisa-player (U) kdebugsettings (U) keditbookmarks (U) kget (U) libkeduvocdocument (U) okteta (U) Ayatana Packagers qmenumodel Barak A. Pearlmutter cppad (U) mlpack (U) Bartosz Fenski supertux (U) Bas Couwenberg geos (U) qgis (U) sfcgal (U) Ben Burton regina-normal Benjamin Barenblat abseil Benjamin Drung libsoxr (U) Bjoern Ricks grantlee5 (U) Boian Bonev gammu Boris Pek eiskaltdcpp Boyuan Yang cjson fcitx5 (U) fcitx5-gtk (U) fcitx5-qt (U) go-for-it libavif (U) libime (U) libxlsxwriter (U) qevercloud tidy-html5 (U) xcb-imdkit (U) zxing-cpp Bret Curtis recastnavigation (U) Carlos Donizete Froes surgescript (U) CESNET libyang (U) ChangZhuo Chen (陳昌倬) juffed (U) screengrab (U) Chow Loong Jin tinyxml2 Christoph Berg gr-limesdr (U) gr-satellites (U) libcm256cc (U) Christoph Junghans votca-csg (U) votca-tools (U) Christoph Martin nfs-ganesha (U) Connor Imes powercap Cristian Greco poco (U) Dain Nilsson yubico-piv-tool (U) Daniel Kahn Gillmor fontforge (U) Daniel Schepler kpat (U) libkdegames (U) David Bremner ledger David Lamparter libyang David Prévot cmocka Davide Viti fontforge (U) Debian Astro Team purify sopt Debian Authentication Maintainers yubico-piv-tool Debian Bridges Team libcork libcorkipset Debian Deep Learning Team pthreadpool Debian Deepin Packaging Team libxlsxwriter (U) Debian Fonts Task Force fontforge
Re: merged /usr
On 2021-08-17, Holger Levsen wrote: > On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: >> The failure mode we have sometimes seen is packages that were built in >> a merged-/usr chroot not working on a non-merged-/usr system, although >> that's detected by the reproducible-builds infrastructure and is already >> considered to be a bug since buster (AIUI it's considered a non-RC bug >> in buster and bullseye, as a result of things like #914897 mitigating it). > > FWIW i'm preparing a commit right now which will change the > reproducible-builds > infrastructure in so far as: > > - bullseye will not be tested anymore for differences of building with or > without the usrmerge package installed (just like stretch and buster were > and are not). > - bookworn and unstable will be tested for differences of building with or > without the usrmerge package installed. Given: TC decision on "Merged /usr" https://bugs.debian.org/914897 The short of it, as I read it, is that non-usrmerge systems will be unsupported for bookworm, or did I misread that? I would almost think it makes more sense to *not* test usrmerge for bookworm, but continue to test it for bullseye and unstable (and experimental) in the reproducible builds infrastructure. This is my quick rationale for why I think that: * bullseye has been doing usrmerge variations for it's entire development cycle, it seems odd to change now. * Keeping unstable/sid with usrmerge variations is good for QA, as it does occasionally catch deeper issues. * Not doing usrmerge variations for bookworm is consistent with the plan for the next release (though we should have usrmerge always enabled then, as opposed to only building with non-usrmerge). It is also similar to build paths (which are not tested in the "testing" suite), a lower bar for the "testing" suite, as it is a relatively easy thing to workaround for reproducibility. But, I've only caught a small part of this thread, so maybe there's more to it. :) live well, vagrant signature.asc Description: PGP signature
Re: Need help with getting a package to build reproducibly on arm*
On 2021-01-08, Vagrant Cascadian wrote:
> On 2021-01-08, Vagrant Cascadian wrote:
>> On 2021-01-07, Vagrant Cascadian wrote:
>>> On 2021-01-07, Michael Biebl wrote:
>>>> Am 07.01.21 um 18:24 schrieb Michael Biebl:
>>>>> as can be seen at [1], systemd does not build reproducibly on armhf and
>>>>> arm64 (while there is no problem on amd64 and i386).
>>>>>
>>>>> The problem is, I have no idea what the diffoscope diff [2] means and
>>>>> how I can make the package build reproducibly everywhere or how I can
>>>>> further investigate this.
>>>>>
>>>>> Any help here is greatly appreciated as I think reproducible-builds are
>>>>> a great effort and I'd like to support that as much as I can.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> [1]
>>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html
>>>>> [2]
>>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/systemd.html
>>>
>>> My best wild guesses would be parallelism, filesystem ordering or locale
>>> differences causing various sort ordering differences.
>>>
>>> I'm running a local build on arm64 with "reprotest --auto-build" to see
>>> if it can help give us any better leads, will see if that shows anything
>>> more useful... it could take some time on not particularly fast
>>> hardware.
>>
>> First attempt was reproducible for me (two normalized builds and one
>> varied build), though I couldn't vary the clock with reprotest
>> (libfaketime appears to trigger issues with building systemd)... or
>> fileordering, user, group or hostname due to some limitations my my
>> typical test environment. The command I ran was:
>>
>> reprotest --verbose --min-cpus=1
>> --vary=-user_group,-domain_host,-fileordering,-time auto -- null
> ...
>
> But the second attempt for some reason did produce some interesting
> results... why it didn't happen the first time suggests it is not
> deterministic.
>
> │ │ │ ├── ./usr/bin/bootctl
> ...
> │ │ │ │ ├── strings --all --bytes=8 {}
> │ │ │ │ │ @@ -250,15 +250,15 @@
> │ │ │ │ │ SystemdOptions
> │ │ │ │ │ Failed to set SystemdOptions EFI variable: %m
> │ │ │ │ │ supported
> │ │ │ │ │ not supported
> │ │ │ │ │ Failed to query reboot-to-firmware state: %m
> │ │ │ │ │ Failed to parse argument: %s
> │ │ │ │ │ Failed to set reboot-to-firmware option: %m
> │ │ │ │ │ -/EFI/systemd/systemd-bootaa64.efi
> │ │ │ │ │ +/EFI/systemd/systemd-bootarm.efi
> │ │ │ │ │ Failed to access EFI variables. Is the "efivarfs" filesystem
> mounted?
> │ │ │ │ │ Failed to determine current boot order: %m
>
> This suggests to me that the running kernel is somehow used to determine
> the userspace architecture, effectively similar to:
>
>
> https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html
>
>
> The armhf builders on tests.reproducible-builds.org for Debian do not
> systematically test this. I'm not sure about the arm64 builders, but I
> think they run the same kernel, so it seems unlikely to be the only
> issue. Also surprised the i386 builder doesn't catch this. Then again,
> it only happened on my second try, which suggests this is
> non-deterministic in some way; maybe the slower armhf/aarch64
> architectures trigger it more often?
>
> I'll later post the results of the diffoscope output somewhere and give
> a closer look.
And those results I promised:
https://people.debian.org/~vagrant/reproducible/systemd.20210108.dE8pOx/
Nothing terribly obvious to me, though as mentioned, the running kernel
may be a factor for the arm64 and armhf platforms.
live well,
vagrant
signature.asc
Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote: > Note: in case we do not agree on this topic this will be the text I'll > send to the > tech-ctte. Thanks for taking the time to draft some text. If we can come closer to agreement on the proposed text, that would probably take a bit of the load off of the tech-ctte. Hopefully some of my comments move in that direction, although I also have added some counterpoint text as well... > Let me start by noting that I have nothing against reproducibility. In fact > quite the opposite: I love the idea... as long as it's properly implemented. It is even "recommended" in Debian Policy policy to build reproducibly with different build paths. > The problem here is that __FILE__ is a public, well defined API with very > valid > use cases (more on this below), even if the current implementation of all the > major compilers go against reproducibility. At least two major compilers, GCC and Clang provide the -ffile-prefix-map feature to do exactly that(which is what dpkg is enabling), so it seems a bit overstated to say that all major compilers "go against" reproducibility. They do not enable reproducibility by default. > So if we want to mangle __FILE__ > (thus breaking API) this should be done by an opt-in, and **never** by opting > out. Else we risk breaking a valid implementation, be it already on the > archive > any new package added afterwards. While I understand that may be how you feel, it would be appreciated if we could use something a little less loaded than "mangle". perhaps: So if we want to enable features using __FILE__ in a way which arguably breaks API > Even more: we library maintainers continuously ask our upstreams to keep their > API as stable as possible, and if not possible following some rules > (SONAME change, for example). I will present an option to do the same > ourselves > without breaking API/ABI. > > # __FILE__ is a public, well defined API > > During the course of #876901 many reasons were used to both say that __FILE__ > is or not a well defined API. In fact one of the evidences used where the > compiler's documentation. For example > https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html > (enphasis mine): > > This macro expands to the name of the current input file, in the form of a C > string constant. **This is the path by which the preprocessor opened > the file**, > not the short name specified in ‘#include’ or as the input file name > argument. > For example, "/usr/local/include/myheader.h" is a possible expansion of this > macro. > > This definition says that it's up to the preprocessor to define the path. So, > what has been the behaviour of all major compilers during all these years? > Using > the full path. The proof of this is Qt itself. Check > https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-2/src/testlib/qtestcase.h/#L216 > > This code has been working on **every** platform Qt works without any change. > Qt is compiled in a myriad of OSs, using a myriad of compilers. They all do > the exact same thing. So developers depend on a very stable definition > of an API. > > And we all know that breaking API is bad, except if done carefully (read > below). > > # Doing the right thing > > This is just an idea of "doing the right thing", like bumping SONAME > on a library. > It definitely doesn't have to be the only one. I understand your position is fundamentally about "Doing the right thing" but I would say that we are all trying to do the right thing. > I understand that the reproducibility people do not want to consider > providing the > same build path. While this is arguable I do understand that > reproducibility without > depending on the build path is a good thing. So I've tried to come up with a > path to achieve this. > ## New macro and warning (if they do not exist already) > > This would be the first step. The idea is to provide a new macro that, > by definition > and documentation, it can be mangled with the help of the build > system, much as you > are currently doing with __FILE__ now. > > The second step in this is to make compilers create a reproducibility warning > if > some code uses __FILE__. This will have three effects effects: We haven't proposed an alternate macro, which would surely take years at best, possibly decades. That doesn't seem too realistic. > - discouraging it's use > - creating awareness on reproducibility. We've discouraged the use of __FILE__ for years, have done plenty of outreach on the subject of reproducibility, and gotten traction with various upstream projects. > - making other distros jump into reproducibility in a much easier way. Arguably some distros (e.g. archlinux) are passing us by when it comes to real-world reproducibility; I'm not sure Debian is the example by which all other distros should be measured anymore. Which is good in some ways, but somewhat disappointing to see Debian start something great
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote: > Oh, I have sadly forgotten to mention another thing. > > On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer > wrote: >> # __FILE__ is a public, well defined API > > According to: > Adrian Bunks mentions it in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#10 > Holger Levsen in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#42 > Mattia Rizzolo on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#192 > > The ability of gcc to change __FILE__ was a patch that, at the time of > those writings, wasn't yet accepted. That is no longer the case. The fixfilepath feature enabled in dpkg only uses features (e.g. -ffile-prefix-map) available in both upstream GCC (>=9? or 8? ~2018) and Clang (>= 10), possibly other compilers as well. There are no special patches to toolchains needed to enable this feature. > Even more, Ximion Luo wrote on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#212 > > The GCC patch (neither the previous nor the planned version) does > not change the default behaviour of __FILE__, and was never intended > to. Instead, it gives users the ability to rewrite __FILE__, more > specifically a prefix of it. > > makes it clear that the default behaviour is not changed. So if the > patch got accepted (did it get accepted?) it was only to allow > reproducible people to break API in order to get reproducibility. Since then an alternate implementation was implemented that the reproducible=+fixfilepath feature in dpkg takes advantage of, in order to implement this feature in another distribution, if I recall correctly. It didn't address all the cases of the old GCC patches that Ximin submitted, but the Reproducible Builds team decided in 2018 to make use of upstream supported features only and dropped all of our patches to GCC. The notable difference is that it not longer makes use of an environment variable; it requires passing the -ffile-prefix-map option to the compiler. The dpkg patch simply adds this to the default relevent *FLAGS variables. (For historical completeness, though somewhat an aside to the topic at hand, the -ffile-prefix-map approach does not address all the cases of the former patches to GCC as the compiler flags sometimes end up in various shipped artifacts in *some* cases, though certainly not all.) > This in itself, if something has not changed in the meantime, marks > another reference that __FILE__ is a public, well defined API. I think reading #876901 demonstrates that the case can be made either way; it not as well defined as you make it out to be. live well, vagrant signature.asc Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote: > On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer > wrote: > In fact most of those packages would not be unreproducible if the > environment would be the same as the original build. That includes the > build path. True, that is a fairly simple workaround. Which is why we do not vary the build path when testing bullseye for tests.reproducible-builds.org. But we do vary build paths when testing experimental and unstable on tests.reproducible-builds.org, as it helps identify cases where build paths are an issue. It would also help greatly as we move towards verification builds of packages in the archive to not have to worry about build paths as much. > I do understand that it is *desirable* to be able to reproducibly > build a package no matter the build path, but that's just desirable. According to Debian Policy it is recommended: "It is recommended that packages produce bit-for-bit identical binaries even if most environment variables and build paths are varied. It is intended for this stricter standard to replace the above when it is easier for packages to meet it." > The real fix here is to do the right thing, ie, provide the very same > environment as the original build, including the build path. That does sound like a workaround more than a real fix. > So again, mangling __FILE__ should not be a default. I'll agree to disagree. I will admit that a change of defaults in dpkg this close to freeze does seem a bit on the late side of things. Still, The process has been going on for months, announced in accordance with the process for getting defaults changes into dpkg. Bugs with trivial patches were filed in October. Unfortunately, most of the affected packages seem to disproportionately affect packages maintained by the KDE team. I did what I could to mitigate that impact by actually building each and every one of the affected packages to ensure that the opt-out patches worked correctly. Most of those have been applied already. live well, vagrant signature.asc Description: PGP signature
Re: Need help with getting a package to build reproducibly on arm*
On 2021-01-08, Vagrant Cascadian wrote:
> On 2021-01-07, Vagrant Cascadian wrote:
>> On 2021-01-07, Michael Biebl wrote:
>>> Am 07.01.21 um 18:24 schrieb Michael Biebl:
>>>> as can be seen at [1], systemd does not build reproducibly on armhf and
>>>> arm64 (while there is no problem on amd64 and i386).
>>>>
>>>> The problem is, I have no idea what the diffoscope diff [2] means and
>>>> how I can make the package build reproducibly everywhere or how I can
>>>> further investigate this.
>>>>
>>>> Any help here is greatly appreciated as I think reproducible-builds are
>>>> a great effort and I'd like to support that as much as I can.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> [1]
>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html
>>>> [2]
>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/systemd.html
>>
>> My best wild guesses would be parallelism, filesystem ordering or locale
>> differences causing various sort ordering differences.
>>
>> I'm running a local build on arm64 with "reprotest --auto-build" to see
>> if it can help give us any better leads, will see if that shows anything
>> more useful... it could take some time on not particularly fast
>> hardware.
>
> First attempt was reproducible for me (two normalized builds and one
> varied build), though I couldn't vary the clock with reprotest
> (libfaketime appears to trigger issues with building systemd)... or
> fileordering, user, group or hostname due to some limitations my my
> typical test environment. The command I ran was:
>
> reprotest --verbose --min-cpus=1
> --vary=-user_group,-domain_host,-fileordering,-time auto -- null
...
But the second attempt for some reason did produce some interesting
results... why it didn't happen the first time suggests it is not
deterministic.
│ │ │ ├── ./usr/bin/bootctl
...
│ │ │ │ ├── strings --all --bytes=8 {}
│ │ │ │ │ @@ -250,15 +250,15 @@
│ │ │ │ │ SystemdOptions
│ │ │ │ │ Failed to set SystemdOptions EFI variable: %m
│ │ │ │ │ supported
│ │ │ │ │ not supported
│ │ │ │ │ Failed to query reboot-to-firmware state: %m
│ │ │ │ │ Failed to parse argument: %s
│ │ │ │ │ Failed to set reboot-to-firmware option: %m
│ │ │ │ │ -/EFI/systemd/systemd-bootaa64.efi
│ │ │ │ │ +/EFI/systemd/systemd-bootarm.efi
│ │ │ │ │ Failed to access EFI variables. Is the "efivarfs" filesystem mounted?
│ │ │ │ │ Failed to determine current boot order: %m
This suggests to me that the running kernel is somehow used to determine
the userspace architecture, effectively similar to:
https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html
The armhf builders on tests.reproducible-builds.org for Debian do not
systematically test this. I'm not sure about the arm64 builders, but I
think they run the same kernel, so it seems unlikely to be the only
issue. Also surprised the i386 builder doesn't catch this. Then again,
it only happened on my second try, which suggests this is
non-deterministic in some way; maybe the slower armhf/aarch64
architectures trigger it more often?
I'll later post the results of the diffoscope output somewhere and give
a closer look.
live well,
vagrant
signature.asc
Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote: > On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian > wrote: >> >> On 2020-11-13, Sune Vuorela wrote: >> > On 2020-10-27, Vagrant Cascadian wrote: >> >> Though, of course, identifying the exact reproducibility problem would >> >> be preferable. One of the common issues is test suites relying on the >> >> behavior of __FILE__ returning a full path to find fixtures or other >> >> test data. >> > >> > has QFIND_TESTDATA been adapted to work with this, or are we just >> > "lucky" that most packages don't actually build and run test suites? >> >> Yes, QFINDTESTDATA is one of the primary (only?) issues with test suites >> found in about 20-30 packages in the archive, according to the >> archive-wide rebuild that was performed. For most of those packages >> patches have been submitted, and some are already either fixed or marked >> as pending. > > But QFINDTESTDATA is using __FILE__ in a valid way. It might not be > what you are expecting, but still a valid usage. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901 We have > discussed this before. > > >> If it could be fixed at the core for QFINDTESTDATA, that would be nicer >> than fixing 20-30 packages individually, though we're not there right >> now. > > In that case I would expect a valid patch from the people interested > in enabling this. In the meantime the dpkg change broke a very valid > usage. Inconvenient for reproducibility? yes, probably, but still very > valid. We did a full archive rebuild testing this change, and I provided patches to all known affected packages several months ago. It is a one-line change in debian/rules in most cases: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org&tag=fixfilepath It seems there are less than 10 packages left that have not applied the patch. Longer-term, it would be nice to be able to fix QFINDTESTDATA to be compatible, sure. live well, vagrant signature.asc Description: PGP signature
Re: Need help with getting a package to build reproducibly on arm*
On 2021-01-07, Vagrant Cascadian wrote: > On 2021-01-07, Michael Biebl wrote: >> Am 07.01.21 um 18:24 schrieb Michael Biebl: >>> as can be seen at [1], systemd does not build reproducibly on armhf and >>> arm64 (while there is no problem on amd64 and i386). >>> >>> The problem is, I have no idea what the diffoscope diff [2] means and >>> how I can make the package build reproducibly everywhere or how I can >>> further investigate this. >>> >>> Any help here is greatly appreciated as I think reproducible-builds are >>> a great effort and I'd like to support that as much as I can. >>> >>> Regards, >>> Michael >>> >>> >>> [1] >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html >>> [2] >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/systemd.html > > My best wild guesses would be parallelism, filesystem ordering or locale > differences causing various sort ordering differences. > > I'm running a local build on arm64 with "reprotest --auto-build" to see > if it can help give us any better leads, will see if that shows anything > more useful... it could take some time on not particularly fast > hardware. First attempt was reproducible for me (two normalized builds and one varied build), though I couldn't vary the clock with reprotest (libfaketime appears to trigger issues with building systemd)... or fileordering, user, group or hostname due to some limitations my my typical test environment. The command I ran was: reprotest --verbose --min-cpus=1 --vary=-user_group,-domain_host,-fileordering,-time auto -- null So maybe one of those disabled variations, but all those are also varied on all the platforms that tests.reproducible-builds.org tests for Debian, so... hrm. Another possibility is the locale used... reprotest picks more or less at random, while: https://tests.reproducible-builds.org/debian/index_variations.html amd64: LANG="et_EE.UTF-8" i386: LANG="de_CH.UTF-8" arm64: LANG="nl_BE.UTF-8" armhf: LANG="it_CH.UTF-8" Similar for LC_ALL and LANGUAGE. But I somewhat doubt both nl_BE and it_CH would break in the same way... The other thing that's maybe a bit different is parallelism: XXX on amd64: 16 or 15 XXX on i386: 10 or 9 XXX on armhf: 5 or 3 But the difference between 3-5 cores and 9-10 or 15-16 doesn't seem very likely to trigger issues either... Was hoping reprotest would at least point us in a clearer direction for what to test for ... but not today. I'll chew on it a bit more and possibly try to stir up some more possibilities. live well, vagrant signature.asc Description: PGP signature
Re: Need help with getting a package to build reproducibly on arm*
On 2021-01-07, Michael Biebl wrote: > Am 07.01.21 um 18:24 schrieb Michael Biebl: >> as can be seen at [1], systemd does not build reproducibly on armhf and >> arm64 (while there is no problem on amd64 and i386). >> >> The problem is, I have no idea what the diffoscope diff [2] means and >> how I can make the package build reproducibly everywhere or how I can >> further investigate this. >> >> Any help here is greatly appreciated as I think reproducible-builds are >> a great effort and I'd like to support that as much as I can. >> >> Regards, >> Michael >> >> >> [1] >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd.html >> [2] >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/systemd.html My best wild guesses would be parallelism, filesystem ordering or locale differences causing various sort ordering differences. I'm running a local build on arm64 with "reprotest --auto-build" to see if it can help give us any better leads, will see if that shows anything more useful... it could take some time on not particularly fast hardware. live well, vagrant signature.asc Description: PGP signature
Re: Porter roll call for Debian Bullseye
On 2020-11-20, Graham Inggs wrote: > A friendly reminder about the porter roll call for bullseye. > > On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote: >> We are doing a roll call for porters of all release architectures. If >> you are an active porter behind one of the release architectures [1] >> for the entire lifetime of Debian Bullseye (est. end of 2024), please >> respond with a signed email containing the following before Friday, >> November 27: > > Please note we don't automatically assume that porters for previous > releases will continue to do so. > If you were a porter for a previous release, we'd like you to sign up > again for bullseye. I know I'm a bit late to the party now... I do run both arm64 and armhf on numerous machines, mostly as part of the reproducible builds zoo. We mostly stick to stable for the main OS, but do run unstable and testing in chroots. I also sometimes run testing or individual packages from unstable on various other armhf and arm64 machines I use and make efforts to report and ideally fix bugs when encountered. I maintain u-boot and arm-trusted-firmware, used primarily on armhf and arm64. I do occasional debian-installer work and linux related work for both arm64 and armhf. I can most likely continue doing the above for the forseeable future. Not likely to fix deeply complicated toolchain issues. If all that qualifies for a porter hat, ok, if not, also ok. :) live well, vagrant signature.asc Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2020-11-14, Sune Vuorela wrote: > On 2020-11-13, Vagrant Cascadian wrote: >> If it could be fixed at the core for QFINDTESTDATA, that would be nicer >> than fixing 20-30 packages individually, though we're not there right >> now. > > Unfortunately, only like 10% of the relevant packages have test suites > enabled and run, because gettings things to work reliable is sometimes > hard. That is a a bit of a surprise! So, based on your estimate and the current packages known to be affected, Debian might have an additional 300 packages that might someday enable test suites. That is ~1% of the archive that would need to make a one-line change in debian/rules if the maintainers enable test suites for those packages. Are there any templates or documentation used for such packages that might be able to facilitate the process? > Adding more hurdles does not help. > I think this is a hurdle we do not need. To me, a one-line change in packaging seems like a quite small hurdle in the short-term, but clearly you do not agree. So it really comes down to applying opt-in patches for hundreds (maybe thousands) of packages, or an opt-out change for somewhere in the ballpark of tens or hundreds of packages. Long-term, of course it would be more ideal to fix QFINDTESTDATA to be compatible with -ffile-prefix-map/-fmacro-prefix-map compiler flags being used to strip the build path from the compiled outputs; this would solve the issue for potentially hundreds of packages and would make the issue essentially moot. live well, vagrant signature.asc Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2020-11-13, Sune Vuorela wrote: > On 2020-10-27, Vagrant Cascadian wrote: >> Though, of course, identifying the exact reproducibility problem would >> be preferable. One of the common issues is test suites relying on the >> behavior of __FILE__ returning a full path to find fixtures or other >> test data. > > has QFIND_TESTDATA been adapted to work with this, or are we just > "lucky" that most packages don't actually build and run test suites? Yes, QFINDTESTDATA is one of the primary (only?) issues with test suites found in about 20-30 packages in the archive, according to the archive-wide rebuild that was performed. For most of those packages patches have been submitted, and some are already either fixed or marked as pending. If it could be fixed at the core for QFINDTESTDATA, that would be nicer than fixing 20-30 packages individually, though we're not there right now. > I don't think that we should make it harder for maintainers to enable > test suites on their packages Similarly, I don't think we should make it harder to make hundreds of packages more reproducible just to avoid a trivial workaround. We're talking about a one-line change in debian/rules in a small number of packages, as opposed to the 3 packages that need no changes. > when we can just record the filepath in > the build info and still have things reproducible. Sure, rebuilding packages in the same path is a relatively easy workaround to the build path issue. It does have some drawbacks: * More complicated infrastructure to recreate the build environment. * The .buildinfo files need to include the build path by default, which I believe is enabled for most buildd machines, but not the default for dpkg-genbuildinfo (and there may be some privacy concerns to making it the default). So, it will take some work to make this change in Debian and because it seems to affect QT related test suites, it affects the teams working with QT more than the rest of Debian. Because of that, I did individual builds for all the affected packages, and submitted patches to workaround this issue to try and minimize the extra work needed by any affected maintainers or teams. I still would like for Debian to move forward with this change. live well, vagrant signature.asc Description: PGP signature
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On 2020-10-27, Vagrant Cascadian wrote: > The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg > in 2018. ... > The result of enabling this feature by default will be to make several > hundred packages reproducible with varying build-path and reduce the > differences in many other packages, making it easier to identify other > more nuanced reproducibility issues. > > It would be great to see the reproducible=+fixfilepath feature enabled > by default in dpkg-buildflags, and we would like to proceed forward with > this soon unless we hear any major concerns or other outstanding issues. Given no objections or concerns of any kind raised in the last two weeks, I've submitted a bug against dpkg: https://bugs.debian.org/974087 live well, vagrant signature.asc Description: PGP signature
Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg in 2018. ## What does this feature do exactly? From the dpkg-buildflags(1) manpage: fixfilepath This setting (disabled by default) adds -ffile-prefix-map=BUILDPATH=. to CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and FCFLAGS where BUILDPATH is set to the top-level directory of the package being built. This has the effect of removing the build path from any generated file. The result of enabling this feature by default will be to make several hundred packages reproducible with varying build-path and reduce the differences in many other packages, making it easier to identify other more nuanced reproducibility issues. It would be great to see the reproducible=+fixfilepath feature enabled by default in dpkg-buildflags, and we would like to proceed forward with this soon unless we hear any major concerns or other outstanding issues. ## Process regarding updating dpkg-buildflags defaults Following the dpkg FAQ on how to add default build flags to dpkg-buildflags: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F We do not expect any significant change in memory or build-times, or any changes in run-time semantics (other than the issues noted below regarding test suites). An archive-wide rebuild has been performed (more below). ## Possible updates required to your packages Minor updates to a small number of packages in the archive are needead, although patches for most od them have already been sent. The simplest workaround is a one-line change in debian/rules to disable the feature: DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath Though, of course, identifying the exact reproducibility problem would be preferable. One of the common issues is test suites relying on the behavior of __FILE__ returning a full path to find fixtures or other test data. A small number of packages manually filter out -fdebug-prefix-map=/build/dir when recording CFLAGS (etc.) into binary packages, in order to make the build reproducible. Depending on the implementation of this filter (specifically, whether it also filters out -ffile-prefix-map as well), these packages may, ironically, actually become unreproducible with reproducible=+fixfilepath -- they will not catch this additional flag. In these situations, please broaden the regular expression (or similar) to make the build reproducible again or avoid recording any CFLAGS whatsover depending on the circumstances. ## Background We have been performing builds with DEB_BUILD_OPTIONS=reproducible=+all (which includes +fixfilepath) at https://tests.reproducible-builds.org since 2018. Currently we only enable this feature in sid and experimental. Lucas Nussbaum kindly performed an archive-wide rebuild and identified a small number of packages that failed to build with this flag enabled: http://qa-logs.debian.net/2020/09/26.fixfilepath/00res.fixfilepath.only-failures.txt Huge thanks to Lucas for that! The failing packages have been marked in the reproducible builds infrastructure: https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html https://tests.reproducible-builds.org/debian/issues/unstable/ffile_prefix_map_passed_to_clang_issue.html And I have filed patches for most of the affected packages: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org&tag=fixfilepath The few remaining packages FTBFS regardless of whether they use reproducible=+fixfilepath, or are built with the default clang compiler, version 9, which does not support this feature. I expect most of these packages to build correctly once llvm-toolchain-defaults updates to 10 or 11, which is expected for bullseye: https://alioth-lists.debian.net/pipermail/pkg-llvm-team/2020-September/010784.html We would like to move forward with this change soon, so please raise any concerns or issues not covered already. Thanks for reading this far! live well, vagrant On behalf of the Reproducible Builds team signature.asc Description: PGP signature
Re: Co-maintaining some packages
On 2020-10-10, Brett Gilio wrote: > It is Brett Gilio. I pinged you on IRC last evening regarding advice for > joining Debian in helping maintain some packages. Below I have Paul > Wise's response to my inquiry, and was wondering if you would be willing > to sponsor my work on some orphaned packages, as well as assistance with > packaging Guix. Regarding guix packaging, it still needs test suite fixes and/or workarounds and eventually various other packages updated to guile 3.0: https://bugs.debian.org/850644 My packaging branch, based on the last release which was guile 2.2 based: https://salsa.debian.org/vagrant/guix I've made a couple attempts at updating to a newer git snapshot, and there's talk of a new guix release in the near future, so it might make sense to wait for a release-candidate of guix before diving in too deeply. I'm a little hesitant at the moment to take on sponsoring other arbitrary packages that I'm not directly involved in, though I would be more able to make the time if it also fixes reproducible builds issues. The Request-For-Sponsor (RFS) process that pabs pointed to will hopefully find some other people who can help! Thanks for getting yourself even more invovled in Debian. :) live well, vagrant signature.asc Description: PGP signature
Bug#950315: ITP: m4api -- access Mini-Box M4-ATX power supplies
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: m4api Version : 0.3~ Upstream Author : Ken Tossell * URL or Web page : https://github.com/ktossell/m4api * License : LGPL-2.1 Description : access Mini-Box M4-ATX power supplies Utility and library to access monitoring and configuration functions of mini-box power supplies produced by http://www.mini-box.com/site/index.html Initial packaging work: https://salsa.debian.org/vagrant/m4api/ live well, vagrant signature.asc Description: PGP signature
Bug#929095: ITP: scheme-bytestructures -- Structured access to bytevector contents
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: scheme-bytestructures or guile-bytestructures Version : 1.0.5 Upstream Author : Taylan Ulrich Bayırlı/Kammer * URL or Web page : https://github.com/TaylanUB/scheme-bytestructures/ * License : GPL-3+, LGPL-3+ Description : Structured access to bytevector contents This library offers a system imitating the type system of the C programming language, to be used on bytevectors. C's type system works on raw memory, and ours works on bytevectors which are an abstraction over raw memory in Scheme. The system is in fact more powerful than the C type system, elevating types to first-class status. First draft of packaging: https://salsa.debian.org/vagrant/scheme-bytestructures This is a dependency to package guile-git: https://bugs.debian.org/929094 live well, vagrant signature.asc Description: PGP signature
Bug#929094: ITP: guile-git -- guile bindings for git
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-git Version : 0.2.0 Upstream Author : Amirouche Boubekki * URL or Web page : https://gitlab.com/guile-git/guile-git/ * License : GPL-3+, LGPL-3+, GFDL-1.3+ (with exceptions), others Description : guile bindings for git Guile-Git is a GNU Guile library providing bindings to libgit2. First draft of packaging: https://salsa.debian.org/vagrant/guile-git This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929093: ITP: guile-ssh -- guile bindings to ssh
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-ssh Version : 0.11.3 Upstream Author : Artyom V. Poptsov * URL or Web page : https://github.com/artyom-poptsov/guile-ssh/ * License : GPL-3+, Expat, LGPL-3+, and more! Description : guile bindings to ssh Guile-SSH is a library that provides access to the SSH protocol for programs written in GNU Guile interpreter. It is built upon the libssh library. First draft of packaging: https://salsa.debian.org/vagrant/guile-ssh This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929092: ITP: guile-sqlite3 -- guile bindings for sqlite3
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-sqlite3 Version : 0.1.0 Upstream Author : Andy Wingo * URL or Web page : https://notabug.org/guile-sqlite3/guile-sqlite3 * License : LGPL-3+, GPL-3+ Description : guile bindings for sqlite3 Guile bindings for the SQLite3 database engine. First draft of packaging: https://salsa.debian.org/vagrant/guile-sqlite3 This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929091: ITP: guile-gcrypt -- gcrypt bindings for guile
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-gcrypt Version : 0.1.0 Upstream Author : Christopher Allan Webber and others * URL or Web page : https://notabug.org/cwebber/guile-gcrypt * License : GPL-3+, Expat, GFDL-1.3+ (with exceptions) Description : gcrypt bindings for guile Guile-Gcrypt provides a Guile 2.x interface to a subset of the GNU Libgcrypt crytographic library, which is itself used by the GNU Privacy Guard (GPG). Guile-Gcrypt provides modules for cryptographic hash functions, message authentication codes (MAC), public-key crytography, strong randomness, and more. It is implemented using the foreign function interface (FFI) of Guile. First draft of packaging: https://salsa.debian.org/vagrant/guile-gcrypt This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#928724: ITP: opensbi -- RISC-V Open Source Supervisor Binary Interface
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian X-Debbugs-Cc: debian-devel@lists.debian.org, mer...@debian.org, debian-ri...@lists.debian.org * Package name: opensbi Version : 0.3+ Upstream Author : Anup Patel/Western Digital, other contributors * URL : https://github.com/riscv/opensbi * License : BSD-2, Apache 2.0, GPL-2+ Programming Lang: C Description : RISC-V Open Source Supervisor Binary Interface The **RISC-V Supervisor Binary Interface (SBI)** is the recommended interface between: 1. A platform-specific firmware running in M-mode and a bootloader, a hypervisor or a general-purpose OS executing in S-mode or HS-mode. 2. A hypervisor running in HS-mode and a bootloader or a general-purpose OS executing in VS-mode. The *RISC-V SBI specification* is maintained as an independent project by the RISC-V Foundation on [Github] (https://github.com/riscv/riscv-sbi-doc). The goal of the OpenSBI project is to provide an open-source reference implementation of the RISC-V SBI specifications for platform-specific firmwares executing in M-mode (case 1 mentioned above). An OpenSBI implementation can be easily extended by RISC-V platform and system-on-chip vendors to fit a particular hardware configuration. ... An SBI implementation is needed in order to boot RISC-V systems. This package initially will at least enable loading u-boot in qemu sufficient to boot a linux kernel and initramfs. A similar project is the RISC-V Proxy Kernel and Boot Loader (a.k.a. BBL): https://github.com/riscv/riscv-pk But BBL requires a compilation step to embed the bootloader and/or kernel into a payload every time you upgrade the kernel and/or bootloader. It is possible with OpenSBI to load an arbitrary payload without requiring a compilation step in some cases (e.g. qemu). Karsten Merker has offered to co-maintain (who has also been contributing upstream); not sure if we'll need a team just yet. Initial rough cut of packaging: https://salsa.debian.org/vagrant/opensbi It cross-compiles an arch:all firmware image usable with qemu+u-boot. Help with improving the package description and a few remaining lintian issues would be great! live well, vagrant signature.asc Description: PGP signature
Re: Nix and non-standard-toplevel-dir
Luke Faraone wrote: > On Wed, 2 Jan 2019 at 20:28, Russ Allbery wrote: > > If anything, they probably already know > > how Nix works and are expecting it to use those paths. There doesn't seem > > to be much drawback in this carefully-chosen lack of compliance with the > > FHS. > > > > I don't think it's worth writing an explicit Policy exception for this, > > since it's a single edge case. Instead, I think it's a good use of a > > Lintian override documenting what's going on. Obviously, if Nix becomes > > really popular in the long run, we can then go back and write this into > > Policy. > This also is the case with snapd, which uses `/snap` in all other > distributions. We currently override it, but the issue was brought up > in a bug report.[1] I think the same arguments apply to both Nix and > snapd; but perhaps two is not yet numerous enough to warrant > documenting in policy. > [1]: http://bugs.debian.org/852199 How about three? Guix is basically a re-implementation of Nix in scheme. I took a quick stab at packaging it a while back... https://bugs.debian.org/850644 So the same logic that would apply for /nix and /snap would also apply to /gnu (Guix uses /gnu/store, like Nix's /nix/store). live well, vagrant signature.asc Description: PGP signature
Bug#895057: RFH: ltsp -- network booted thin and fat clients
Package: wnpp Severity: normal It has been several years since I've actually maintained a real-world deployment of LTSP, and there are very few other active developers of the project upstream. I have continued to maintain it in Debian as best I can, and would love to see it continue to be supported in Debian, but would really need some active co-maintainers to keep it viable long-term. Right now there is an RC bug regarding support for the transition to FreeRDP2 (which I've never used): https://bugs.debian.org/892626 Of course there are a few other bugs in Debian and upstream. The main source packages affected are ltsp, ldm, ltspfs and the much-neglected ltsp-docs. There's also ltsp-manager, currently only in experimental, which is an attempt to simplify installation and management of LTSP environments. Another source package is libpam-sshauth, which is a major piece of an attempt to replace the deficiencies of LDM with a regular display manager using PAM... this has long been on the plans for a next generation LTSP, but hasn't gotten beyond the proof of concept phase. I've CCed debian-edu in the bug report, as that project has some of the largest active users of ltsp in Debian that I'm aware of. live well, vagrant signature.asc Description: PGP signature
Bug#881620: ITP: arm-trusted-firmware -- reference implementation of secure world software for ARMv8-A
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: arm-trusted-firmware Version : 1.4 Upstream Author : ARM Limited and Contributors * URL or Web page : https://github.com/ARM-software/arm-trusted-firmware/ * License : BSD-2-Clause, BSD-3-Clause, Expat, ISC Description : reference implementation of secure world software for ARMv8-A ARM Trusted Firmware provides a reference implementation of secure world software for `ARMv8-A`_, including a `Secure Monitor`_ executing at Exception Level 3 (EL3). It implements various ARM interface standards, such as: - The `Power State Coordination Interface (PSCI)`_ - Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1) - `SMC Calling Convention`_ - `System Control and Management Interface`_ As far as possible the code is designed for reuse or porting to other ARMv8-A model and hardware platforms. ARM will continue development in collaboration with interested parties to provide a full reference implementation of Secure Monitor code and ARM standards to the benefit of all developers working with ARMv8-A TrustZone technology. -- This is needed to boot various arm64 boards (pine64, firefly-rk3399) that may not have built-in firmware shipped with them, possibly in conjunction with an EFI implementation or u-boot. Some considerations when packaging this: - Not all vendors are merged upstream; there are several vendor-specific forks that are needed in order to support specific hardware, such as support for allwinner A64: https://github.com/apritzel/arm-trusted-firmware I would definitely need some help with initial and long-term maintenance to make this a reality... live well, vagrant signature.asc Description: PGP signature
Re: Summary of the Arm ports BoF at DC17
On 2017-09-15, Ben Hutchings wrote: > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > [...] >> There is optional kernel support to trap the exceptions here >> and emulate the instructions, but it's really not recommended for >> serious use (e.g. on a build machine!). > [...] > > Why is it not recommended? Terrible performance, or known bugs? On arm64 kernels building armhf packages for the reproducible builds builders, I'm seeing hundreds or even thousands of kernel log warnings per second when building anything that makes use of CP15_BARRIER_EMULATION (e.g. anything using ghc): [85740.553537] cp15barrier_handler: 115316 callbacks suppressed [85740.559358] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction at 0xf5beaa7c [85740.567344] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction at 0xf5beaa9c That *might* be sufficient to actually impact performance; it certainly makes it hard to read other kernel log messages on those machines... There was a bug reported on ghc related to this: https://bugs.debian.org/864847 live well, vagrant signature.asc Description: PGP signature
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On 2016-12-16, Roger Shimizu wrote: > On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl > wrote: >>> Is it possible to put a bootloader like u-boot in the flash partitions >>> and have it load the Linux kernel and initrd from elsewhere? There's no technical reason this wouldn't be possible, just a matter of getting patches in upstream u-boot for that platform adding support for loading from other media (SD, USB, sata, etc.), filesystem support and so on, and staying withint the size constraints for that platform. You might be able to use an SPL loader as a first-stage loader early in the boot process to load a more capable u-boot from other flash partitions and/or other media and/or filesystems. With the space reserved for a linux kernel on flash media, that would presumably give quite a bit of space for a full-featured u-boot. >> That how I've been running my Dockstars through all the years. As as >> far as I know this worked with the Debian kernels as well (I use my >> own kernels for reasons). > > If I understand correctly, it means boot like: > u-boot shipped by original vendor => self built u-boot => kernel > (Debian's or your own customized one) While technically possible, u-boot upstream discourages chainloaded u-boot. So while you could maybe make patches to get it working for a particular board and set of vendor and upstream u-boot versions, I'm not sure if patches would be accepted for upstream u-boot. live well, vagrant signature.asc Description: PGP signature
Bug#760314: RFH: zoneminder
Package: wnpp Severity: normal Zoneminder maintenance has fallen behind; neither myself nor Peter Howard seem to have enough time to maintain it properly. I no longer use zoneminder at work. Another maintainer, ideally one who actively uses zoneminder, is probably long overdue... Homepage: http://www.zoneminder.com/ Description: Linux video camera security and surveillance solution ZoneMinder is intended for use in single or multi-camera video security applications, including commercial or home CCTV, theft prevention and child or family member or home monitoring and other care scenarios. It supports capture, analysis, recording, and monitoring of video data coming from one or more video or network cameras attached to a Linux system. ZoneMinder also support web and semi-automatic control of Pan/Tilt/Zoom cameras using a variety of protocols. It is suitable for use as a home video security system and for commercial or professional video security and surveillance. It can also be integrated into a home automation system via X.10 or other protocols. It's written in Perl, C (maybe C++?), PHP and javascript. It's got a web frontend, and stores events in a database backend. There are at least two RC bugs fixed in VCS/experimental; haven't had the time to do an upload or a good setup to test with, and another that might be fixable with a newer upstream version, or at least downgraded with some testing to verify it only applies to specific cameras. VCS is in collab-maint: http://hg.debian.org/hg/collab-maint/zoneminder Upstream has recently (well, the last year or so) gotten new developers, and has been commenting on several of the bugs in Debian's bug tracking system. Upstream VCS: https://github.com/zoneminder/zoneminder live well, vagrant pgpiy4sray08F.pgp Description: PGP signature
Re: Arm64 port live on debian-ports
On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote: > On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote: > > Given that, it seems like a good time to add arm64 to src:linux with a > > configuration that will run on at least a typical QEMU ARM64 emulation. > > AIUI qemu 2.0 only does qemu-aarch64-user, with the system emulation > portion slated to be merged shortly[0]. Not sure if it works, but qemu-system-aarch64 is in the 2.0 packages in sid: https://packages.debian.org/search?suite=sid&searchon=contents&keywords=qemu-system-aarch64 live well, vagrant signature.asc Description: Digital signature
Bug#646971: ITP: epoptes -- Computer lab management tool
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian * Package name: epoptes Version : 0.3.0 Upstream Author : Alkis Georgopoulos , Fotis Tsamis * URL : http://www.epoptes.org/ * License : GPL Programming Lang: Python, bash Description : Computer lab management tool It allows for screen broadcasting and monitoring, remote command execution, message sending, imposing restrictions like screen locking or sound muting the clients and much more! live well, vagrant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111028192208.GH26987@talon.fglan
Bug#616466: ITP: xul-ext-perspectives -- verify HTTPS sites through notary servers
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian * Package name: xul-ext-perspectives Version : 4.1 Upstream Author : Dan Wendlandt and others * URL : http://www.cs.cmu.edu/~perspectives * License : GPL VCS : git://github.com/danwent/Perspectives.git Description : verify HTTPS sites through notary servers Perspectives is an approach to help clients securely identify Internet servers in order to avoid "man-in-the-middle" attacks, by querying "network notaries" located in multiple vantage points across the Internet. . This extension enables bypassing HTTPS security warnings when appropriate. perspectives uses multiple network notary servers to track sites over time and from different networks to establish additional information about the consistancy of certificates presented to the browser, and can be used to override security exceptions in some cases. projects such as monkeysphere allow somewhat similar functionality, although monkeysphere requires the user to be well connected in the GPG web of trust in order to be useful, whereas perspectives uses trusted notaries which require little to no configuration to the end user. i'd like to package the firefox extension which seems to be straightforward, and eventually the notary servers as well. live well, vagrant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304174653.GQ10855@talon.fglan
Re: Accepted sdm 0.4.1-2 (source all)
On Sat, Jun 26, 2010 at 02:40:37PM +0100, Julien Cristau wrote: > On Sat, Jun 26, 2010 at 12:57:45 +0000, Vagrant Cascadian wrote: > > > sdm (0.4.1-2) unstable; urgency=low > > . > [...] > >* No longer include dash as a dependency; it is included in essential. > >* Add lintian overrides for missing-dep-for-interpreter dash, as dash > > is now essential. > > My understanding was that dash was only in the Essential set as the > default provider of /bin/sh, and that /bin/dash was explicitly *not* > guaranteed to stay in Essential, and thus packages using that need to > keep their dependencies. Did I misunderstand, or is the above change > wrong? well, lintian warns either way you do it, hence the override: http://bugs.debian.org/587209 some clarity on how to handle that would be nice, yes. since dash *is* marked essential, and based on my reading of policy 3.8: "Maintainers should take great care in adding any programs, interfaces, or functionality to `essential' packages. Packages may assume that functionality provided by `essential' packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an `essential' package therefore creates an obligation to support that capability as part of the Essential set in perpetuity." seemed like the override was the appropriate thing to do, but i'm not terribly attached if it's deemed better to handle it differently. live well, vagrant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100626175910.gl9...@claws.fglan
Bug#543423: ITP: ltsp-docs -- LTSP Documentation
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian * Package name: ltsp-docs Version : 0.99+bzr87 Upstream Author : Scott Balneaves * URL : http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspDocumentationUpstream * License : GPL2 Description : LTSP Documentation VCS (bzr) : https://code.launchpad.net/~ltsp-docwriters/ltsp/ltsp-docs-trunk i would like to package "Linux Terminal Server Project Administrator's Reference" as a supplement to the ltsp, ltspfs and ldm packages in Debian. it is the most comprehensive documentation for LTSP, and currently generates a PDF and HTML version, as well as a manpage for lts.conf, a commonly used LTSP configuration file. it seems important to have as a package, so the version of the documentation that ships with a given Debian release will be able to document the versions of LTSP shipped in that same release, as online documentation may diverge, which can be confusing for users. live well, vagrant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
BSP October 26th, Portland, Oregon, USA
Freegeek, a Debian GNU/Linux using organization since 2001 or thereabouts, would like to a host a Bug Squashing Party: October 26th, 2008, 10am-whenever Portland, Oregon, USA directions: http://freegeek.org/map please bring your fine bug squashing skills and maybe a potluck dish. pleny of computers available for debian-installer testing! maybe even some of those off-beat architectures... please contact me if you're interested in attending! also, if enough folks express interest, i might be able to get the space saturday evening (7pm-whenever) or monday all day. live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
