Bug#963600: critcl: please make the teapot.txt files reproducible
On 2023-01-10, Chris Lamb wrote:
>> critcl: please make the teapot.txt files reproducible
>
> My previous patch no longer makes this package reproducible; there is
> an additional variation within:
>
> /usr/lib/tcltk/x86_64-linux-gnu/critcl_callback1/linux-x86_64/callback.so
I tracked down the other issues! They are due to source code including
the pid and the epoch timestamp:
././debian/.cache/.critcl/pkg2360103.1717554676/v3118_0033.c:1211
vs.
././debian/.cache/.critcl/pkg1294786.1751964911/v3118_0033.c:1211
This is introduced in the source code at:
https://sources.debian.org/src/critcl/3.1.18.1%2Bdfsg-3/lib/app-critcl/critcl.tcl/#L177
proc ::critcl::app::PackageCache {} {
if {$v::cache ne {}} {
return $v::cache
}
return [file join ~ .critcl pkg[pid].[clock seconds]]
}
If we can figure out where to set "$v::cache" to some value
deterministically during the build, I think we could fix this for critcl
itself, although not for things built using critcl (if I am
understanding critcl correctly).
Alternately patching it to use the value of SOURCE_DATE_EPOCH in lieu of
clock seconds and ignore the pid altogether when SOURCE_DATE_EPOCH is
set, although I am a bit at a loss how to handle that in Tcl itself...
I was able to build reproducibly by applying your original patch to
debian/rules and by mangling critcl to use:
return [file join ~ .critcl pkgPID.CLOCKSECONDS]
Though I would guess this is not appropriate for typical runtime use.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#963688: neovim-qt: please make the build reproducible
On 2020-06-25, Chris Lamb wrote: > This is because it embeds the CFLAGS (via CMAKE_CXX_FLAGS) in an > "About" dialogue, and this environment variable contains the build > path via -ffile-prefix-map etc. This is still relevent, although tests.reproducible-builds.org no longer tests varied build paths. The patch needs a trivial refresh, but I can confirm that it still fixes the issue. I would like to perform an NMU fixing this in the near future, unless there are outstanding objections. live well, vagrant signature.asc Description: PGP signature
Bug#961942: mono: mono-source: Embeds time, user, group, etc. in mono-source.tar.xz
Control: severity 961942 normal On 2024-03-31, James Addison wrote: > Currently, Debian's buildd and also the Reproducible Builds team's testing > infrastructure[1] both use a fixed build path when building binary packages. > > This means that your package will pass current reproducibility tests; however > we believe that varying the build path still produces undesirable changes in > the binary package output, making it more difficult than necessary for > independent consumers to check the integrity of those packages by rebuilding > them themselves. Since this bug report was also caused by numerous other issues (timestamps, locale and username), not just build paths, I have switched the severity back to normal ... it still does not build reproducibly and would be nice to get this at least partially fixed. Again, it does not solve all reproducibility issues, but significantly reducing the diff would be really helpful to resolve the remaining issues. Given the lack of comment the last four years, I propose to NMU this soon. live well, vagrant signature.asc Description: PGP signature
Bug#1072172: ltsp-server: ltsp-build-client fails
Control: fixed 1072172 19.10-1 On 2024-05-29, Vagrant Cascadian wrote: > Version: 19.08-1 ... > Marking as done in the version that switched to the new-style LTSP. Actually, the first version actually uploaded to debian was 19.10-1, marking appropriately. live well, vagrant signature.asc Description: PGP signature
Bug#1072172: ltsp-server: ltsp-build-client fails
On 2024-05-29, Jim Mintha wrote: > Package: ltsp-server > Version: 5.18.12-3 > Severity: normal > > After installing the ltsp-server (and -standalone) packages I ran: > ltsp-build-client. > First time it failed with: ltsp-server, ltsp-build-client, and all ltsp 5.x components were last present two stable releases ago and are no longer part of Debian. While you *might* be able to get it to work by adding buster (a.k.a. oldoldstable) sources and various manual tweaks, I would not recommend it at this point... it receives no real attention or maintenance upstream or in any distro. The current LTSP support is available in Debian as the "ltsp" package, see: https://ltsp.org/docs/ live well, vagrant signature.asc Description: PGP signature
Bug#1044559: guile-lzlib: Fails to build source after successful build
Control: tag 1044559 pending On 2023-08-13, Lucas Nussbaum wrote: > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). ... >> dpkg-source -b . >> dpkg-source: error: unwanted binary file: debian/build/guile-3.0/lzlib.go >> dpkg-source: error: unwanted binary file: >> debian/build/guile-3.0/lzlib/config.go >> dpkg-source: error: detected 2 unwanted binary files (add them in >> debian/source/include-binaries to allow their inclusion). >> dpkg-source: info: using source format '3.0 (quilt)' >> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status >> 255 >> >> E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage >> --sanitize-env -us -uc -rfakeroot -S' failed to run. Fixed in git: https://salsa.debian.org/debian/guile-lzlib/-/commit/206654cca36977e64e97ef12096c3a86a5338835 live well, vagrant signature.asc Description: PGP signature
Bug#1070235: Guix fails to pull channel with SSL error
On 2024-05-02, Tomas Volf wrote: > Package: guix > Version: 1.4.0-3 > > When I invoke `guix pull' against my channel, it fails with a SSL error: > > # /usr/bin/guix pull --url=https://git.wolfsden.cz/.git/guix > Updating channel 'guix' from Git repository at > 'https://git.wolfsden.cz/.git/guix'... > guix pull: error: Git error: SSL error: 0x8880 - SSL - A fatal alert > message was received from our peer > > No special configuration is needed, just booting the system and installing > guix > via apt-get. Does guix pull with the default channels work? What certificate authority does your https server for your channel use? > This seems to be a problem specific to Guix from the debian package. When I > try > to access the channel by other means (from the same system as above), it works > fine. `git clone' works just fine, and even Guix installed in non-debian way > works fine, for example via time-machine: > > guix time-machine -q --commit=v1.4.0 -- pull > --url=https://git.wolfsden.cz/.git/guix > > I am using Debian 12 on 6.7.4 kernel and 2.36-9 libc, running on physical > server > machine. You seem to also be lacking the recent security update for guix (e.g. 1.4.0-3+deb12u1), please test that version also, just in case there is some weird hidden versioned dependency conflict (e.g. if guile-gnutls was built against a different version of gnutls than when guix was initially built). live well, vagrant signature.asc Description: PGP signature
Bug#1021470: xsok: reproducible-builds: build path embedded in /usr/games/xsok
On 2024-05-02, Petter Reinholdtsen wrote: > [Vagrant Cascadian] >> Still appears to be an issue, though tests.reproducible-builds.org is no >> longer testing build path variations. Downgrading the severity >> accordingly. > > Hm, then I do not understand the fix. As far as I can tell, the default > build flags are used. Perhaps you can take a look at this orphaned > package in https://salsa.debian.org/debian/xsok > and commit a fix > that really solve the issue. There are two things; even if CFLAGS is actually available, the upstream build system uses CCOPTIONS instead. CFLAGS was not exported, maybe due to being classing debhelper rather than modern dh style? I took the liberty of converting the rules file to dh (although I struggled getting dh_auto_install to do the right thing and mostly left that alone)... which appears to do the right thing and allows replacing the manual calls to dpkg-buildflags with their corresponding variables... not to mention considerably less boilerplate! I did not do any significant testing, although debdiff showed no difference after the conversion. > I plan a new upload tomorrow to push the latest git changes into > unstable. Thanks! live well, vagrant signature.asc Description: PGP signature
Bug#1021470: xsok: reproducible-builds: build path embedded in /usr/games/xsok
Control: found 1021470 1.02-20 Control: severity 1021470 minor On 2024-05-01, Debian Bug Tracking System wrote: > From: Petter Reinholdtsen > Subject: Accepted xsok 1.02-20 (source) into unstable ... > As far as I can tell, the latest changes to the package build system > made the build reproducible. I suspect it was the switching to level 13 > with default compiler flags. Still appears to be an issue, though tests.reproducible-builds.org is no longer testing build path variations. Downgrading the severity accordingly. It can be reproduced using reprotest manually, or possibly by enabling salsa-ci pipelines, or building twice with sbuild, which currently randomizes the build path by default. live well, vagrant signature.asc Description: PGP signature
Bug#1069262: bookworm-pu: package u-boot/2023.01+dfsg-2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: u-b...@packages.debian.org, vagr...@debian.org Control: affects -1 + src:u-boot [ Reason ] Fixes the timer clock used by various "orion" based platforms, such as Sheevaplug. [ Impact ] This fixes booting on Sheevaplug and other similar platforms, which are currently entirely broken in bookworm. [ Tests ] The original reporter of the bug confirmed that it worked on their Sheevaplug. [ Risks ] Should be low risk; changes are small and isolated to the currently broken platforms. [ Checklist ] [?] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] A single patch is pulled from upstream that fixes booting on the sheevaplug and related platforms. Unfortunately, the debdiff revealed an un-used patch (u-boot-2023.01+dfsg/debian/0001-u-boot-qemu-Add-malta64el-and-maltael.patch) in the old source package that was never intended to be included, not in revision control and is not present in the new source package. I did not detect the un-used crufty patch until I had performed the upload, so neglected mentioning it in debian/changelog, but it never should have been included in bookworm in the first place... hopefully this "removal" is tolerable. It should have no real effect on the resulting package. [ Other info ] Thanks! live well, vagrant signature.asc Description: PGP signature
Bug#1068890: diffoscope: --hard-timeout option
On 2024-04-16, Chris Lamb wrote: > However, I think this first iteration of --hard-timeout time has a few > things that would need ironing out first, and potentially make it not > worth implementing: > > (1) You suggest it should start again with "--max-container-depth 3", > but it would surely need some syntax (or another option?) to control > that "3" (but for the second time only). What about going the other direction ... starting with a very small value for max-container-depth, and incrementally increasing it, generating a report (or at least storing sufficient data to generate one) in between each increment, so you always get some information, but essentially incrementally increase the resolution? Or would that approach just be too inefficient? > (2) In fact, its easy to imagine that one would want to restart with > other restrictions as well: not just --max-container-depth. For > instance, excluding external commands like readelf and objdump that > you know to be slow. Ah, yes, knowing the common time sinks would be tremendously helpful! live well, vagrant signature.asc Description: PGP signature
Bug#1038845: reprotest: transition from /etc/timezone to /etc/localtime
Control: block 1038845 by 1001250 On 2023-06-21, bl...@debian.org wrote: > reprotest is currently referencing /etc/timezone without support for > /etc/localtime. /etc/timezone is a legacy interface that is Debian > specific. The cross-distro standard /etc/localtime (as a symlink to > the appropriate timezone file), so please switch your package to > /etc/localtime. tzsetup will stop creating /etc/timezone soon. Note > that the list of affected source packages was compiled with > codesearch, so false positives are possible. Thank you. This is only in the code running in a qemu virtual machine, although that is currently broken, so needs to be fixed somehow to remove /etc/timezone. live well, vagrant signature.asc Description: PGP signature
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
On 2024-04-12, Fay Stegerman wrote:
> * Vagrant Cascadian [2024-04-12 19:29]:
>> On 2024-04-12, Holger Levsen wrote:
>> > when installing reprotest 0.7.27:
>> >
>> > SyntaxWarning: invalid escape sequence '\;'
>> > Setting up reprotest (0.7.27) ...
>> > /usr/lib/python3/dist-packages/reprotest/__init__.py:360: SyntaxWarning:
>> > invalid escape sequence '\;'
>> > run_or_tee(['sh', '-ec', 'find %s -type f -exec sha256sum "{}" \;' %
>> > self.artifact_pattern],
> [...]
>> How exactly did you get this error?
>>
>> I installed locally, but did not encounter any such issues on package
>> installation just now, and also nothing when manually running a simple
>> test:
>>
>> reprotest 'date > date' date
>> WARNING:reprotest:The control build runs on 1 CPU by default, give
>> --min-cpus to increase this.
>> WARNING:reprotest.build:IGNORING user_group variation; supply more
>> usergroups with --variations=user_group.available+=USER1:GROUP1;USER2:GROUP2
>> or alternatively, suppress this warning with --variations=-user_group
>> WARNING:reprotest.build:Not using sudo for domain_host; your build may fail.
>> See man page for other options.
>> WARNING:reprotest.build:Be sure to `echo 1 >
>> /proc/sys/kernel/unprivileged_userns_clone` if on a Debian system.
>> --- /tmp/tmp4vqq6736/control
>> +++ /tmp/tmp4vqq6736/experiment-1
>> │ --- /tmp/tmp4vqq6736/control/source-root
>> ├── +++ /tmp/tmp4vqq6736/experiment-1/source-root
>> │ │ --- /tmp/tmp4vqq6736/control/source-root/date
>> │ ├── +++ /tmp/tmp4vqq6736/experiment-1/source-root/date
>> │ │ @@ -1 +1 @@
>> │ │ +L 13 apr 2024 07:27:01 GMT
>> │ │ -Fri Apr 12 05:27:01 GMT 2024
>
> That syntax warning is new in Python 3.12. And it's correct, one should use
> raw
> strings (r'...') or two backslashes for escape sequences intended for e.g.
> regexes or shell commands like here, not Python itself.
Ok, finally able to reproduce this by installing python3.12 in the
environment, which is not yet the default python or installed by
default, but obviously will be before too long...
That at least gives me enough to poke at this going forward!
Thanks!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1068853: reprotest: SyntaxWarning: invalid escape sequence '\;'
On 2024-04-12, Holger Levsen wrote:
> when installing reprotest 0.7.27:
>
> SyntaxWarning: invalid escape sequence '\;'
> Setting up reprotest (0.7.27) ...
> /usr/lib/python3/dist-packages/reprotest/__init__.py:360: SyntaxWarning:
> invalid escape sequence '\;'
> run_or_tee(['sh', '-ec', 'find %s -type f -exec sha256sum "{}" \;' %
> self.artifact_pattern],
> /usr/lib/python3/dist-packages/reprotest/build.py:315: SyntaxWarning: invalid
> escape sequence '\$'
> _ = _.append_setup_exec_raw('DROP_ARCH="-v -e ^$(uname -m)\$"')
> /usr/lib/python3/dist-packages/reprotest/build.py:317: SyntaxWarning: invalid
> escape sequence '\$'
> _ = _.append_setup_exec_raw('if [ $WORDSIZE -eq 64 ]; then \
> /usr/lib/python3/dist-packages/reprotest/environ.py:10: SyntaxWarning:
> invalid escape sequence '\w'
> "path": "(/\w{1,12}){1,4}",
> /usr/lib/python3/dist-packages/reprotest/environ.py:11: SyntaxWarning:
> invalid escape sequence '\d'
> "port": "([1-9]\d{0,3}|[1-5]\d{4})",
> /usr/lib/python3/dist-packages/reprotest/environ.py:12: SyntaxWarning:
> invalid escape sequence '\w'
> "domain": "\w{1,10}(\.\w{1,10}){0,3}",
> /usr/lib/python3/dist-packages/reprotest/environ.py:13: SyntaxWarning:
> invalid escape sequence '\w'
> "password": "\w{1,40}",
> /usr/lib/python3/dist-packages/reprotest/environ.py:14: SyntaxWarning:
> invalid escape sequence '\w'
> "username": "\w{2,20}",
> /usr/lib/python3/dist-packages/reprotest/environ.py:113: SyntaxWarning:
> invalid escape sequence '\w'
> "REPROTEST_CAPTURE_ENVIRONMENT_UNKNOWN_\w+"]
> /usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:305:
> SyntaxWarning: invalid escape sequence '\['
> script = '''sed -rn 's/^(deb|deb-src) +(\[.*\] *)?([^
> ]*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)[^ ]*) +([^
> -]+) +(.*)$/\\1 \\2\\3 \\5-%s \\6/p' /etc/apt/sources.list `ls
> /etc/apt/sources.list.d/*.list 2>/dev/null|| true` >
> /etc/apt/sources.list.d/%s.list; for retry in 1 2 3; do apt-get
> --no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/%s.list -o
> Dir::Etc::sourceparts=/dev/null update 2>&1 && break || sleep 15; done''' %
> (pocket, pocket, pocket)
> /usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:320:
> SyntaxWarning: invalid escape sequence '\/'
> 'for d in %s; do [ ! -d $d ] || touch -r $d %s/${d//\//_}.stamp; done' % (
> /usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:342:
> SyntaxWarning: invalid escape sequence '\/'
> 'for d in %s; do s=%s/${d//\//_}.stamp;'
> /usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:724:
> SyntaxWarning: invalid escape sequence '\('
> script = '''d=%(t)s/deps
> /usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py:1211:
> SyntaxWarning: invalid escape sequence '\/'
> script += '''REL=$(sed -rn '/^(deb|deb-src)
> .*(ubuntu.com|debian.org|ftpmaster|file:\/\/\/tmp\/testarchive)/ { s/^[^ ]+
> +(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\\2/p}' $SRCS | head -n1); '''
How exactly did you get this error?
I installed locally, but did not encounter any such issues on package
installation just now, and also nothing when manually running a simple
test:
reprotest 'date > date' date
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
WARNING:reprotest.build:IGNORING user_group variation; supply more usergroups
with --variations=user_group.available+=USER1:GROUP1;USER2:GROUP2 or
alternatively, suppress this warning with --variations=-user_group
WARNING:reprotest.build:Not using sudo for domain_host; your build may fail.
See man page for other options.
WARNING:reprotest.build:Be sure to `echo 1 >
/proc/sys/kernel/unprivileged_userns_clone` if on a Debian system.
--- /tmp/tmp4vqq6736/control
+++ /tmp/tmp4vqq6736/experiment-1
│ --- /tmp/tmp4vqq6736/control/source-root
├── +++ /tmp/tmp4vqq6736/experiment-1/source-root
│ │ --- /tmp/tmp4vqq6736/control/source-root/date
│ ├── +++ /tmp/tmp4vqq6736/experiment-1/source-root/date
│ │ @@ -1 +1 @@
│ │ +L 13 apr 2024 07:27:01 GMT
│ │ -Fri Apr 12 05:27:01 GMT 2024
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1061137: Doesn't work on SheevaPlug
On 2024-04-12, Martin Michlmayr wrote: > * Vagrant Cascadian [2024-01-18 20:07]: >> > So we need a stable update with this change. >> >> Thanks everyone! >> >> This is a pretty trivial fix, so including in the next bookworm/stable >> point release should work! > > Is this still planned? Yes ... I think. :) Thanks for the reminder! live well, vagrant signature.asc Description: PGP signature
Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)
On 2024-03-08, Vagrant Cascadian wrote: > On 2023-04-12, Holger Levsen wrote: >> i guess reprotest maybe should grow an option to do >> --control-build /path/to/packages/ >> --vary=build_path=/use/this/build/path ... >>to make it easier to use reprotest to compare against an existing >> build >>YES >> e.g. there is no way to disable buidl path variations when >> comparing >> against an arbitrary build >>i'm reporting this as a bug to the bts, quoting your words here. >> (ok?) >> reprotest can control it's own builds ... but if i want to use >> reprotest >>against the archive packages or an sbuild >>or pbuilder build package ... it will always have a different >> build path > > Forgot about this bug, but I have since implemented a proof-of-concept > of this: > > > https://salsa.debian.org/reproducible-builds/reprotest/-/commits/wip-specify-build-path?ref_type=heads And merged in 0.7.27 ... which resolves the one specific issue mentioned ... are there any other must-haves we need to consider this bug closed? Better documentation of how to actually do this? :) live well, vagrant signature.asc Description: PGP signature
Bug#847805: reprotest: document/support simple reproducibility test with sbuild
On 2016-12-11, Sean Whitton wrote: > On Sun, Dec 11, 2016 at 03:12:57PM -0700, Sean Whitton wrote: >> I have sbuild properly set up on my machine, and I want to use it to >> test package reproducibility. Something like this, where PWD is an >> unpacked source package: >> >> 1) sbuild >> 2) record .deb checksums from .changes file >> 3) sbuild >> 4) compare .deb checksums in new .changes file >> 5) run diffoscope if the checksums differ > > Thanks to #debian-reproducible, this is mostly what I wanted: > > reprotest auto . -- schroot unstable-amd64-sbuild > > This doesn't actually invoke sbuild, but it does perform the builds > inside the schroot I already have set up, and compare the results. > > This is useful, but it would also be good if reprotest could invoke > sbuild(1) itself. That is because sbuild has lots of useful options. > > For example, suppose that foo depends on dh_bar, and I am hacking on > dh_bar in the hope of making foo reproducible. Then I want to build foo > against my local version of dh_bar. With sbuild, I can do this using > --extra-package and --add-depends. reprotest with a pure schroot > backend can't do that kind of thing, so far as I can tell. A while back I did work on a simple wrapper for sbuild that calls reprotest as part of a --finished-build-commands hook: https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest It is definitely quite rough around the edges and there are some caveats that limit the functionality, but can do some of what you were looking for. live well, vagrant signature.asc Description: PGP signature
Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo
On 2024-04-09, Guillem Jover wrote: > I've now finished the change I had in that branch, which implements > support so that dpkg-buildpackage can be passed a .dsc or a source-dir, > and in the former will first extract it, and for both then it will > change directory to the source tree. If it got passed a .dsc then it > will instruct dpkg-genbuildinfo to include a ref to it. > > Which I think accomplishes the requested behavior in a safe way? I've > attached what I've got, which I'm planning on merging for 1.22.7. I'll > probably split that into two commits though before merging. Had a chance to take this for a test run, and it appears to work, though with a few surprises... dpkg-buildpackage -- hello_2.10-3.dsc Ends up regenerating the .dsc, as --build=any,all,source by default ... which may end up with a different .dsc checksum in the .buildinfo than .dsc that was passed on the commandline. Which makes some sense, but maybe would be better to error out? I would not expect to regenerate the .dsc if you're passing dpkg-buildpackage a .dsc! dpkg-buildpackage --build=any,all -- /path/to/hello_2.10-3.dsc Fails to find the .dsc file, as it appears to extract the sources to hello-2.10 and then expects to find ../hello_2.10-3.dsc All that said ... this seemed to work for me: dpkg-buildpackage --build=any,all -- hello_2.10-3.dsc So yay, progress! Thanks! All of the above cases do not clean up the hello-2.10 extracted from the .dsc file, so re-running any of the above need to manually clean that or run from a clean directory or experience various failure modes with the existing hellp-2.10 directory. So a few little glitches, but overall this seems close to something we have really wanted for reproducible builds! And just for good measure, thanks! live well, vagrant signature.asc Description: PGP signature
Bug#962021: forwarded upstream
Control: fixed 962021 10.0.1-1 On 2022-04-19, Vagrant Cascadian wrote: > On 2020-07-04, Bernhard M. Wiedemann wrote: >> https://gitlab.com/graphviz/graphviz/-/merge_requests/1454 >> was easy, because I had the forked repo still around > > This was merged upstream: > > > https://gitlab.com/graphviz/graphviz/-/commit/9b758128c20f7a1d3bb2332327269c7d490ef055 > > Which was included in 2.46.0. This appears to be fixed in experimental, yay! live well, vagrant signature.asc Description: PGP signature
Bug#1067952: mes: FTBFS on armhf
Control: forwarded 1067952 https://lists.gnu.org/archive/html/bug-mes/2024-01/msg8.html On 2024-03-29, Kentaro HAYASHI wrote: > mes 0.26-1 fails to build on armhf. > > FYI: > > https://buildd.debian.org/status/fetch.php?pkg=mes=armhf=0.26-1=1704511792=0 Yeah, forwarded this upstream in January, but have not yet found a fix. live well, vagrant signature.asc Description: PGP signature
Bug#1067850: src:kget: possible Salsa-CI reprotest misconfiguration.
On 2024-03-27, James Addison wrote: > I'd recommend removing the SALSA_CI_REPROTEST_ARGS line entirely -- which > in isolation could cause Salsa-CI reprotest to fail, due to a build-path > bug reported in #1003914 -- but also then applying the patch from that > bugreport to confirm and solve the problem. > > If that is undesirable, then as an alternative I could suggest configuring: > > SALSA_CI_REPROTEST_ARGS: '--variations=all,-build_path' I would recommend following the recently updated documentation: https://salsa.debian.org/salsa-ci-team/pipeline/#adding-extra-arguments-to-reprotest In short, switching to: SALSA_CI_REPROTEST_ARGS: '--vary=-build_path' I think this behaves more like people would expect, e.g. disabling build path variations and not anything else. live well, vagrant signature.asc Description: PGP signature
Bug#1067098: mpl-sphinx-theme: please make the build reproducible
On 2024-03-27, Andreas Tille wrote: > sorry about your work was lost. I confirm the new upstream > version in Git contains the patch. Unfortunately it needs > new dependencies. If it might help you I could upload your > NMU again. Not urgent, glad to see it is pending again! live well, vagrant signature.asc Description: PGP signature
Bug#1064059: U-Boot: secure boot support
On 2024-02-16, Heinrich Schuchardt wrote: > debian/patches/qemu/efi-secure-boot.patch is not a good approach to > enabling secure boot with U-Boot. Variables entered via the command line > containing the security database will be stored on file but will not be > loaded into U-Boot on the next boot. > > If you want a version of U-Boot that supports secure boot properly, use > CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security > database which will be built into U-Boot. tools/efivar.py can be used to > build that file. > > Separate U-Boot binaries for secure and non-secure would have to be > provided. Are you saying that individuals needing this support should build their own custom u-boot binaries to eanble secure boot ... or that we should provide separate packages in Debian with secure boot enabled? > Existing EDK II packages provide secure boot. Hence I suggest to simply > drop patch debian/patches/qemu/efi-secure-boot.patch. Any thoughts on this, Luca, as the provider of the original merge request: https://salsa.debian.org/debian/u-boot/-/merge_requests/24 Thanks! live well, vagrant signature.asc Description: PGP signature
Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations
On 2024-03-24, nicolas.bouleng...@free.fr wrote:
> Hello.
> I failed to reproduce the issue on a porterbox.
>
> On arm64:
> # dpkg-source -x u-boot_2024.01+dfsg-3.dsc
> # cd u-boot_2024.01+dfsg
> # patch -p1 < ../b8d394100d6f858c0e80786f7087f96c11d698c3.diff
> # DEB_BUILD_PROFILES='pkg.uboot.notools
> pkg.uboot.platform.a64-olinuxino' fake\
> root debian/rules binary-arch
> dpkg-gencontrol writes no warning
> debian/u-boot-{rockchip,sunxi}/DEBIAN/control contain the expected
> Built-Using\
> fields
>
> On armel, the control files correctly contain no Built-Using field.
I have not noticed the issues on armel, just armhf (with 0.0.5 or 0.0.6)
and arm64 (with 0.0.6).
> Could you please describe your build environment?
I use sbuild with unshare chroot mode...
Essentially, I build a tarball using a script like this:
https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest/-/blob/main/mm-sbuild
Then call sbuild from the source directory:
sbuild --chroot-mode=unshare -d UNRELEASED -c sid-armhf --arch=armhf \
--no-arch-all --arch-any --source --no-run-lintian --no-clean-source \
--profiles=pkg.uboot.notools,pkg.uboot.subarch.rockchip,pkg.uboot.subarch.sunxi
Seems to behave the same with or without the build profiles, but using
the build profiles reduces the set of built packages to ones that
trigger the issue...
I use the u-boot git repository and cherry-pick
b8d394100d6f858c0e80786f7087f96c11d698c3 into current debian/latest
commit b09ea5f73b440d9f78e1de2b9b9e583ba4bc2541 tag
debian/2024.01+dfsg-3 and then bump debian/changelog appropriately.
I am running these builds on a honeycomb lx2 (arm64), which has support
for running armhf natively as well.
Just re-ran the tests again, and they still fail for me:
https://people.debian.org/~vagrant/dh-builtusing-issues/u-boot_2024.01+dfsg-4~0~20240324~0_arm64-2024-03-24T20:22:28Z.build.zst
https://people.debian.org/~vagrant/dh-builtusing-issues/u-boot_2024.01+dfsg-4~0~20240324~0_armhf-2024-03-24T20:21:58Z.build.zst
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1051098: suggestion: dh-builtusing may simplify the packaging
Control: tags 1051098 - patch On 2024-03-21, Vagrant Cascadian wrote: > On 2024-03-21, Nicolas Boulenguez wrote: >>> Also filed a bug on dh-builtusing about this: >>> >>> https://bugs.debian.org/1067242 >>> >>> I look forward to an improved dh-builtusing and patch for u-boot! :) >> >> Thanks for reporting. >> >> Dh-builtusing/0.0.6 adds a regression test reporting this bug, and >> fixes it. >> >> Variables disabled by a restriction now receive a dummy but valid >> value, so that dpkg-gencontrol can parse the expansion (then ignore >> the dummy value). > > Tested and seems to work! Apparently I tested the wrong thing(or something else changed in the archive?), as it now fails on both arm64 and armhf with this patch applied using dh-builtusing 0.0.6... No idea what went wrong. live well, vagrant signature.asc Description: PGP signature
Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations
Control: found 1067242 0.0.6
I daresay 0.0.6 is even worse, it now fails to build u-boot on both
arm64 (which should have dh-builtusing variables defined) and armhf
(which does not have any dh-builtusing variables defined).
arm64.build:dpkg-gencontrol: warning: Built-Using field of package
u-boot-sunxi: substitution variable ${dh-builtusing:arm-trusted-firmware} used,
but is not defined
arm64.build:dpkg-gencontrol: warning: Built-Using field of package
u-boot-sunxi: substitution variable ${dh-builtusing:crust-firmware} used, but
is not defined
arm64.build-dpkg-gencontrol: warning: can't parse dependency [arm64]
arm64.build-dpkg-gencontrol: error: parsing package 'u-boot-sunxi' Built-Using
field: [arm64],
arm64.build- [arm64],
armhf.build:dpkg-gencontrol: warning: Built-Using field of package
u-boot-sunxi: sub
stitution variable ${dh-builtusing:arm-trusted-firmware} used, but is not
defined
armhf.build:dpkg-gencontrol: warning: Built-Using field of package
u-boot-sunxi: sub
stitution variable ${dh-builtusing:crust-firmware} used, but is not defined
armhf.build-dpkg-gencontrol: warning: can't parse dependency [arm64]
armhf.build-dpkg-gencontrol: error: parsing package 'u-boot-sunxi' Built-Using
field: [arm64],
armhf.build- [arm64],
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1066113: guix: CVE-2024-27297
Control: severity 1066113 serious On 2024-03-16, Vagrant Cascadian wrote: > On 2024-03-15, Salvatore Bonaccorso wrote: >> On Fri, Mar 15, 2024 at 11:22:52AM -0700, Vagrant Cascadian wrote: >>> On 2024-03-13, Vagrant Cascadian wrote: >>> > On 2024-03-12, Vagrant Cascadian wrote: >>> >> On 2024-03-12, Salvatore Bonaccorso wrote: >> We had a look, and as per >> https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/b11b98d89550ce201b0de31401e822c55f4fa2a1 >> we think that it does not require a DSA, but a fix in the upcoming >> point releases would be good. > > Oh my! I am a bit shocked by this honestly ... why is it treated as a > minor security issue? > > I realize Guix is pretty niche in Debian... Nix is perhaps a little more > widely used... > > For anyone with Guix or Nix installed, if I understand correctly, it > basically allows arbitrarily replacing the source code for anything that > you might build using Guix or Nix. > > >> So can you submit it for the point releases? (make sure to adjust the >> target distribution to bullseye respetively bookworm instead of >> *-security). > > I can... although, I would like to make a kind and freindly nudge to > reconsider a DSA if at all possible. :) Thinking more on this... I worry that this issue is maybe more serious than the Debian Security Team realizes? If issues like this do not warrant a security update in Debian, I feel the better course of action may be to remove Guix from Debian. I say this reluctantly, with a heavy heart... Marking as serious severity to reflect my opinion as the maintainer. live well, vagrant signature.asc Description: PGP signature
Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory
Control: fixed 1064748 1.4.0-6 Marking this as fixed in 1.4.0-6, although strictly speaking, this is only worked around by disabling the tests, so the bug should remain open. live well, vagrant signature.asc Description: PGP signature
Bug#1051098: suggestion: dh-builtusing may simplify the packaging
Control: tags 1051098 +patch On 2024-03-21, Nicolas Boulenguez wrote: >> Also filed a bug on dh-builtusing about this: >> >> https://bugs.debian.org/1067242 >> >> I look forward to an improved dh-builtusing and patch for u-boot! :) > > Thanks for reporting. > > Dh-builtusing/0.0.6 adds a regression test reporting this bug, and > fixes it. > > Variables disabled by a restriction now receive a dummy but valid > value, so that dpkg-gencontrol can parse the expansion (then ignore > the dummy value). Tested and seems to work! > For u-boot, no patch is necessary. Just revert the reversal :-) Re-added the patch tag, although strictly speaking it should now have a versioned dependency... :) Will probably wait till u-boot migrates to testing to re-apply the patch... but will do so eventually. live well, vagrant signature.asc Description: PGP signature
Bug#1051098: suggestion: dh-builtusing may simplify the packaging
Control: reopen 1051098
Control: tags 1051098 -patch
On 2024-03-19, Vagrant Cascadian wrote:
> On 2024-02-29, Nicolas Boulenguez wrote:
>> diff --git a/debian/control b/debian/control
>> index 7a6bbc31cc..c6aec92cf6 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -186,7 +187,8 @@ Description: A boot loader for omap systems
>> Package: u-boot-sunxi
>> Architecture: armhf arm64
>> Multi-Arch: same
>> -Built-Using: ${u-boot-sunxi:Built-Using}
>> +Built-Using: ${dh-builtusing:arm-trusted-firmware} [arm64],
>> + ${dh-builtusing:crust-firmware} [arm64],
>> Depends: ${misc:Depends}
>> Recommends: u-boot-tools [arm64]
>> Suggests: arm-trusted-firmware [arm64]
>
> Looks like this triggered build failures on armhf, as it ends up with:
>
> Built-Using: [arm64], [arm64]
>
> So this needs some special-casing which might make it not quite as
> simple :/
>
>
> https://buildd.debian.org/status/fetch.php?pkg=u-boot=armhf=2024.01%2Bdfsg-2=1710912003=0
>
> Although looking at the dh-builtusing manpage, looks like it *should*
> work ... so an inconsistency between documentation and implementation.
About to upload a version reverting this change to fix build failure on
armhf.
Removing the patch flag, as the patch does not quite work correctly.
Also filed a bug on dh-builtusing about this:
https://bugs.debian.org/1067242
I look forward to an improved dh-builtusing and patch for u-boot! :)
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations
Package: dh-builtusing
Version: 0.0.5
Severity: normal
Control: affects -1 u-boot
X-Debbugs-Cc: vagr...@debian.org
u-boot recently switched to dh-builtusing, but it fails with
architecture-specific Built-Using entries in packages that do not have
the same Built-Using dependencies across architectures, e.g. for an
armhf build with arm64 specific Built-Using entries:
dpkg-gencontrol: warning: Built-Using field of package u-boot-rockchip:
substitution variable ${dh-builtusing:arm-trusted-firmware} used, but is not
defined
dpkg-gencontrol: warning: can't parse dependency [arm64]
dpkg-gencontrol: error: parsing package 'u-boot-rockchip' Built-Using field:
[arm64]
...
dpkg-gencontrol: warning: Built-Using field of package u-boot-sunxi:
substitution variable ${dh-builtusing:arm-trusted-firmware} used, but is not
defined
dpkg-gencontrol: warning: Built-Using field of package u-boot-sunxi:
substitution variable ${dh-builtusing:crust-firmware} used, but is not defined
dpkg-gencontrol: warning: can't parse dependency [arm64]
dpkg-gencontrol: error: parsing package 'u-boot-sunxi' Built-Using field:
[arm64],
[arm64],
The dh-builtusing manpage suggests this should work, but results in an
invalid Built-Using field:
Built-Using: [arm64]
It seems the substitution variable is correctly empty, but still
leaves the architecture qualifier in the result...
I tried working around this by leaving out the architecture qualifier,
but then failed differently:
dpkg-query: no packages found matching arm-trusted-firmware
dh_builtusing: error: dpkg-query -Wf
"\${source:Package},\${source:Version},\${Architecture}\" arm-trusted-firmware
returned exit code 1
make: *** [debian/rules:63: binary-arch] Error 25
Leaving out the architecture qualifiers worked before switching to
dh-builtusing, though it did issue warnings in the build log about empty
variables.
Thanks for dh-builtusing, despite this hopefully small bump along the
road!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1051098: suggestion: dh-builtusing may simplify the packaging
On 2024-02-29, Nicolas Boulenguez wrote:
> From 27ec150b506234e1a3e24688ed400627133ab5e2 Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez
> Date: Sat, 2 Sep 2023 23:24:10 +0200
> Subject: Delegate the Built-Using field to the dh-builtusing debhelper tool
>
>
> diff --git a/debian/control b/debian/control
> index 7a6bbc31cc..c6aec92cf6 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -186,7 +187,8 @@ Description: A boot loader for omap systems
> Package: u-boot-sunxi
> Architecture: armhf arm64
> Multi-Arch: same
> -Built-Using: ${u-boot-sunxi:Built-Using}
> +Built-Using: ${dh-builtusing:arm-trusted-firmware} [arm64],
> + ${dh-builtusing:crust-firmware} [arm64],
> Depends: ${misc:Depends}
> Recommends: u-boot-tools [arm64]
> Suggests: arm-trusted-firmware [arm64]
Looks like this triggered build failures on armhf, as it ends up with:
Built-Using: [arm64], [arm64]
So this needs some special-casing which might make it not quite as
simple :/
https://buildd.debian.org/status/fetch.php?pkg=u-boot=armhf=2024.01%2Bdfsg-2=1710912003=0
Although looking at the dh-builtusing manpage, looks like it *should*
work ... so an inconsistency between documentation and implementation.
live well,
vagrant
Bug#1064863: u-boot for riscv64 as included does not work in qemu
Control: tags 1064863 - patch On 2024-02-26, Martin Cracauer wrote: > Package: u-boot-qemu > Version: 2021.01+dfsg-5 > Severity: important > Tags: patch No patch was included, removing from tags. > /usr/lib/u-boot/qemu-riscv64/u-boot.bin as included in this debian > release does not work for booting in qemu for RISCV64, when combined > with /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf (also from > this debian version). See below for qemu command line. ... > Example qemu line showing the problem and solution. Just exchange the > two u-boot.bin's. Note that the FreeBSD image is irrelevant here, the > booting never reaches it. I run this on Debian/amd64. > > qemu-system-riscv64 \ > -M virt \ > -smp 8 \ > -m 32G \ > -nographic \ > -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \ > -kernel u-boot.bin \ > -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -nographic \ > -netdev user,id=net0,ipv6=off,hostfwd=tcp::3234-:22 \ > -device virtio-net-device,netdev=net0 \ > -device virtio-rng-pci Does this work with current versions of u-boot in Debian, e.g. u-boot 2023.01+dfsg-2 from debian bookworm/stable or 2024.01+dfsg-1 from debian trixie/testing? live well, vagrant signature.asc Description: PGP signature
Bug#1067098: mpl-sphinx-theme: please make the build reproducible
On 2024-03-18, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed that
> mpl-sphinx-theme could not be built reproducibly.
>
> This is because it embedded the build date in the documentation:
...
> --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
> +0100
> --- b/debian/patches/reproducible-build.patch 2024-03-18 12:59:19.650123651
> +
> @@ -0,0 +1,28 @@
> +Description: Make the build reproducible
> +Author: Chris Lamb
> +Last-Update: 2024-03-18
> +
> +--- mpl-sphinx-theme-3.5.0.orig/docs/conf.py
> mpl-sphinx-theme-3.5.0/docs/conf.py
> +@@ -1,5 +1,12 @@
> ++import os
> ++import time
> + import datetime
> +
> ++build_date = datetime.datetime.fromtimestamp(
> ++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
> ++tz=datetime.timezone.utc,
> ++)
> ++
> + # Configuration file for the Sphinx documentation builder for
> + # matplotlib projects.
> +
> +@@ -10,7 +17,7 @@ is_release_build = tags.has('release')
> +
> + project = "Matplotlib Sphinx Theme"
> + copyright = (
> +-f"2012 - {datetime.datetime.now().year} The Matplotlib development team"
> ++f"2012 - {build_date.year} The Matplotlib development team"
> + )
> + author = "Matplotlib Developers"
> +
> --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
> --- b/debian/patches/series 2024-03-18 12:59:16.218124536 +
> @@ -0,0 +1 @@
> +reproducible-build.patch
FWIW, I uploaded an NMU fixing this based on your earlier patch, but it
was reverted when the maintainer attempted to orphan the package without
incorporating the NMU...
https://bugs.debian.org/1005826
https://bugs.debian.org/1065042
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1063097: /usr/bin/mkimage: opens image and device trees (-d, -b) O_RDONLY, then O_RDWR, and fails if they're read-only (it doesn't write to them)
On 2024-02-05, наб wrote:
> From a strace:
> 1390 openat(AT_FDCWD, "/tmp/tmp.j2DX6x1MgV/Image-6.6.11.lz4", O_RDONLY) = 3
> 1390 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12611929, ...},
> AT_EMPTY_PATH) = 0
> 1390 close(3) = 0
> 1390 openat(AT_FDCWD, "mt8173-elm-hana-6.6.11.dtb", O_RDONLY) = 3
> 1390 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=43853, ...},
> AT_EMPTY_PATH) = 0
> 1390 close(3) = 0
> 1390 mmap(NULL, 12660736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xafecd000
> 1390 openat(AT_FDCWD, "/tmp/tmp.j2DX6x1MgV/Image-6.6.11.lz4", O_RDWR) = 3
> 1390 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12611929, ...},
> AT_EMPTY_PATH) = 0
> 1390 read(3, "\4\"M\30dp\271\361K!\0\225\37 \3\325'\360X\24\0\1\0
> \243\1\6\0/\n\0\1"..., 12611929) = 12611929
> 1390 close(3) = 0
> 1390 openat(AT_FDCWD, "mt8173-elm-hana-6.6.11.dtb", O_RDWR) = -1 EACCES
> (Permission denied)
> 1390 write(2, "mkimage: Can't open mt8173-elm-h"..., 66) = 66
> 1390 write(2, "mkimage: Failed to build FIT ima"..., 35) = 35
> 1390 munmap(0xafecd000, 12660736) = 0
> here, the dtb is unwritable.
>
> An analogous error happens if the Image is unwritable,
> but as we can see here, it doesn't write to it anyway.
> (Nor should it, given this is an input file.)
>
> Please turn this into an O_RDONLY.
It would be helpful to list the exact command you are running, although
best to take this upstream.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1066113: guix: CVE-2024-27297
On 2024-03-15, Salvatore Bonaccorso wrote: > On Fri, Mar 15, 2024 at 11:22:52AM -0700, Vagrant Cascadian wrote: >> On 2024-03-13, Vagrant Cascadian wrote: >> > On 2024-03-12, Vagrant Cascadian wrote: >> >> On 2024-03-12, Salvatore Bonaccorso wrote: >> > I have now tested an updated 1.4.x package on bookworm and a 1.2.x >> > package on bullseye, and the reproducer (with a small change for 1.2.x) >> > was able to reproduce the problem before upgrading to the patched >> > versions, but not after upgrading to a patched version. >> > >> > I've pushed fixes to various branches; debian/latest (for unstable), >> > debian/bookworm and debian/bullseye: >> > >> > https://salsa.debian.org/debian/guix/ >> >> Attached should be debdiffs for updates for bookworm and bullseye. Let >> me know if I should upload them or if someone from the security team >> will! ... > We had a look, and as per > https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/b11b98d89550ce201b0de31401e822c55f4fa2a1 > we think that it does not require a DSA, but a fix in the upcoming > point releases would be good. Oh my! I am a bit shocked by this honestly ... why is it treated as a minor security issue? I realize Guix is pretty niche in Debian... Nix is perhaps a little more widely used... For anyone with Guix or Nix installed, if I understand correctly, it basically allows arbitrarily replacing the source code for anything that you might build using Guix or Nix. > So can you submit it for the point releases? (make sure to adjust the > target distribution to bullseye respetively bookworm instead of > *-security). I can... although, I would like to make a kind and freindly nudge to reconsider a DSA if at all possible. :) > Thanks a lot for your work! Likewise! live well, vagrant signature.asc Description: PGP signature
Bug#1066113: guix: CVE-2024-27297
On 2024-03-13, Vagrant Cascadian wrote: > On 2024-03-12, Vagrant Cascadian wrote: >> On 2024-03-12, Salvatore Bonaccorso wrote: > I have now tested an updated 1.4.x package on bookworm and a 1.2.x > package on bullseye, and the reproducer (with a small change for 1.2.x) > was able to reproduce the problem before upgrading to the patched > versions, but not after upgrading to a patched version. > > I've pushed fixes to various branches; debian/latest (for unstable), > debian/bookworm and debian/bullseye: > > https://salsa.debian.org/debian/guix/ Attached should be debdiffs for updates for bookworm and bullseye. Let me know if I should upload them or if someone from the security team will! Guix did make a good blog post, and I am wondering if just referencing it is sufficient, or if we should provide some of the instructions directly in the secucity announcement? https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/ The main things we might want to highlight are checking for corrupt items in the store (which may be expensive, depending on how big of an installation) and maybe also running the reproducer script (which needs changes mentioned previously in order to work with 1.2.x from bullseye). Hrm. The upgrading instructions from the blog post are not really relevent, as they are simply handled with "apt upgrade", so that might be a little confusing. live well, vagrant guix_1.2.0-4+deb11u2.debdiff Description: Binary data guix-1.4.0-3+deb12u1.debdiff Description: Binary data signature.asc Description: PGP signature
Bug#1066113: guix: CVE-2024-27297
On 2024-03-12, Vagrant Cascadian wrote: > On 2024-03-12, Salvatore Bonaccorso wrote: >> The following vulnerability was published for guix. >> >> CVE-2024-27297[0]: >> | Nix is a package manager for Linux and other Unix systems. A fixed- >> | output derivations on Linux can send file descriptors to files in >> | the Nix store to another program running on the host (or another >> | fixed-output derivation) via Unix domain sockets in the abstract >> | namespace. This allows to modify the output of the derivation, after >> | Nix has registered the path as "valid" and immutable in the Nix >> | database. In particular, this allows the output of fixed-output >> | derivations to be modified from their expected content. This issue >> | has been addressed in versions 2.3.18 2.18.2 2.19.4 and 2.20.5. >> | Users are advised to upgrade. There are no known workarounds for >> | this vulnerability. ... > A summary from the guix perspective, including code to verify the issue > was posted: > > > https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/ > > I have not yet had a chance to actually verify the fix on locally built > Debian packages, but all three releases do successfully build with the > patches applied. I have now tested an updated 1.4.x package on bookworm and a 1.2.x package on bullseye, and the reproducer (with a small change for 1.2.x) was able to reproduce the problem before upgrading to the patched versions, but not after upgrading to a patched version. I've pushed fixes to various branches; debian/latest (for unstable), debian/bookworm and debian/bullseye: https://salsa.debian.org/debian/guix/ Attached is the reproducer used on 1.2.x from bullseye, which should also work on 1.4.x in bookworm/trixie/sid. live well, vagrant guix-cve-2024-27297-patched Description: Binary data signature.asc Description: PGP signature
Bug#1066113: guix: CVE-2024-27297
Control: found 1066113 1.4.0-3 Control: tags 1066113 pending On 2024-03-12, Salvatore Bonaccorso wrote: > The following vulnerability was published for guix. > > CVE-2024-27297[0]: > | Nix is a package manager for Linux and other Unix systems. A fixed- > | output derivations on Linux can send file descriptors to files in > | the Nix store to another program running on the host (or another > | fixed-output derivation) via Unix domain sockets in the abstract > | namespace. This allows to modify the output of the derivation, after > | Nix has registered the path as "valid" and immutable in the Nix > | database. In particular, this allows the output of fixed-output > | derivations to be modified from their expected content. This issue > | has been addressed in versions 2.3.18 2.18.2 2.19.4 and 2.20.5. > | Users are advised to upgrade. There are no known workarounds for > | this vulnerability. Technically, it was published for Nix (CCed the listed maintainer)! Guix just happens to share some of the same code history. :) Should the bug be cloned for nix, or a separate bug filed? > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2024-27297 > https://www.cve.org/CVERecord?id=CVE-2024-27297 > [1] > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8f4ffb3fae133bb21d7991e97c2f19a7108b1143 > Please adjust the affected versions in the BTS as needed. There was another followup fix committed in upstream guix, which I already merged into the Debian packaging: https://salsa.debian.org/debian/guix/-/commit/03eeedaddbdded880743461cbca0261b96737319 This commit can be trivially cherry-picked for bookworm (1.4.0-3) and for bullseye (with some easily resolved conflicts in debian/patches/series). A summary from the guix perspective, including code to verify the issue was posted: https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/ I have not yet had a chance to actually verify the fix on locally built Debian packages, but all three releases do successfully build with the patches applied. live well, vagrant signature.asc Description: PGP signature
Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)
On 2023-04-12, Holger Levsen wrote: > i guess reprotest maybe should grow an option to do > --control-build /path/to/packages/ > --vary=build_path=/use/this/build/path ... >to make it easier to use reprotest to compare against an existing > build >YES > e.g. there is no way to disable buidl path variations when > comparing > against an arbitrary build >i'm reporting this as a bug to the bts, quoting your words here. > (ok?) > reprotest can control it's own builds ... but if i want to use > reprotest >against the archive packages or an sbuild >or pbuilder build package ... it will always have a different > build path Forgot about this bug, but I have since implemented a proof-of-concept of this: https://salsa.debian.org/reproducible-builds/reprotest/-/commits/wip-specify-build-path?ref_type=heads :) live well, vagrant signature.asc Description: PGP signature
Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory
Control: forwarded 1064748 https://debbugs.gnu.org/69518 Control: tags 1064748 confirmed The actual failed tests are: test-name: fold-available-packages with/without cache test-name: find-packages-by-name with cache test-name: find-packages-by-name + version, with cache test-name: find-package-locations with cache live well, vagrant signature.asc Description: PGP signature
Bug#1064998: guile-lib: broken package when cross building
On 2024-02-28, Helmut Grohne wrote:
> guile-lib actually does cross build, but we still track it as cross
> build failure, because the resulting package contains a build
> architecture multiarch tuple and that trips post-build sanity checks.
I am surprised that it actually cross builds at all... for me with or
without your patch, it still fails on configure:
configure: exit 1
dh_auto_configure: error: cd debian/build/guile-3.0 && ../../../configure
--build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}
/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --disable-option-checking
--disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu
--runstatedir=/run --disable-maintainer-mode --disable-dependency-track
ing --host=aarch64-linux-gnu --with-guile-site=yes
GUILE_EFFECTIVE_VERSION=3.0 GUILE=/usr/bin/guile-3.0 GUILD=/usr/bin/guild-3.0
returne
d exit code 1
live well,
vagrant
>
> The root cause of the failure lies in the way the ccache directory is
> determined. There are actually several ways this is being done during
> configure - some of which work correctly - and ultimately, the last
> attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly.
> Surprisingly, there already is a more complete and working
> implementation GUILE_SITE_DIR and simply reusing that makes it compute
> the ccache directory correctly. Is the attached patch acceptable?
>
> Helmut
> --- guile-lib-0.2.7.orig/m4/guile-ext.m4
> +++ guile-lib-0.2.7/m4/guile-ext.m4
> @@ -63,12 +63,4 @@
> # The variable is marked for substitution, as by @code{AC_SUBST}.
> #
> AC_DEFUN([GUILE_SITE_CCACHE_DIR],
> - [AC_REQUIRE([GUILE_PROGS])
> - AC_MSG_CHECKING(for Guile site ccache directory)
> - GUILE_SITE_CCACHE=`$GUILE -c "(display (%site-ccache-dir))"`
> - if test "$GUILE_SITE_CCACHE" = ""; then
> - AC_MSG_FAILURE(site ccache dir not found)
> - fi
> - AC_MSG_RESULT($GUILE_SITE_CCACHE)
> - AC_SUBST(GUILE_SITE_CCACHE)
> - ])
> + [AC_REQUIRE([GUILE_SITE_DIR])])
signature.asc
Description: PGP signature
Bug#1064998: guile-lib: broken package when cross building
Forwarding this upstream, originally submitted in the Debian bug
tracking system at:
https://bugs.debian.org/1064998
On 2024-02-28, Helmut Grohne wrote:
> guile-lib actually does cross build, but we still track it as cross
> build failure, because the resulting package contains a build
> architecture multiarch tuple and that trips post-build sanity checks.
>
> The root cause of the failure lies in the way the ccache directory is
> determined. There are actually several ways this is being done during
> configure - some of which work correctly - and ultimately, the last
> attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly.
> Surprisingly, there already is a more complete and working
> implementation GUILE_SITE_DIR and simply reusing that makes it compute
> the ccache directory correctly. Is the attached patch acceptable?
>
> Helmut
> --- guile-lib-0.2.7.orig/m4/guile-ext.m4
> +++ guile-lib-0.2.7/m4/guile-ext.m4
> @@ -63,12 +63,4 @@
> # The variable is marked for substitution, as by @code{AC_SUBST}.
> #
> AC_DEFUN([GUILE_SITE_CCACHE_DIR],
> - [AC_REQUIRE([GUILE_PROGS])
> - AC_MSG_CHECKING(for Guile site ccache directory)
> - GUILE_SITE_CCACHE=`$GUILE -c "(display (%site-ccache-dir))"`
> - if test "$GUILE_SITE_CCACHE" = ""; then
> - AC_MSG_FAILURE(site ccache dir not found)
> - fi
> - AC_MSG_RESULT($GUILE_SITE_CCACHE)
> - AC_SUBST(GUILE_SITE_CCACHE)
> - ])
> + [AC_REQUIRE([GUILE_SITE_DIR])])
Would the guile-lib developers consider merging this? Are there any
use-cases where this is inappropriate?
Thanks!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1065042: O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library
On 2024-02-29, Sandro Tosi wrote: > I intend to orphan the mpl-sphinx-theme package. > > The package description is: > This is the official Sphinx theme for Matplotlib documentation. It extends > the > pydata-sphinx-theme project, but adds custom styling and a navigation bar. > . > This package provides documentation for mpl-sphinx-theme It looks like you attempted to orphan it, but switched the Maintainer to the python team rather than the Debian QA team ... Was your intention to orphan it, or just leave it up to the python team? I only noticed because I am subscribed due to the previous NMU for reproducible builds, and those changes do not appear to be included... live well, vagrant signature.asc Description: PGP signature
Bug#1063488: openssh-server: unable to override sshd_config defined options with sshd_config.d snippets
Package: openssh-server Version: 1:9.2p1-2+deb12u2 Severity: normal X-Debbugs-Cc: Vagrant Cascadian The default sshd_config sources configuration snippets from /etc/ssh/sshd_config.d/*.conf in the earliest entry in the configuration, but then defines some Debian defaults after this, which makes the Debian defaults hard to override with sshd_config.d/*.conf snippets, such as X11Forwarding. I see two fairly simple general fixes: 1) Specify /etc/ssh/sshd_config.d/*.conf as the last line in the file. A possible minor downside is people might be more inclined to uncomment some of the default entries, rather than adding a snippet in the .d directory. 2) Define all debian-specific configuration options in /etc/ssh/sshd_config.d/debian.conf or similar, and leave all options in /etc/ssh/sshd_config commented out. Alternately, a separate file for each overridden option might be specifyable, e.g. /etc/ssh/sshd_config.d/x11forwarding.conf live well, vagrant signature.asc Description: PGP signature
Bug#1034327: nmodl: reproducible-builds: Embedded build path in /usr/bin/nmodl
On 2024-01-27, Nilesh Patra wrote: > On Sat, Jan 27, 2024 at 09:09:12PM +0530, Nilesh Patra wrote: >> > The build path is embedded in /usr/bin/nmodl: >> > >> > >> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nmodl.html >> > >> > /build/1st/nmodl-0.5/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib >> > vs. >> > /build/2/nmodl-0.5/2nd/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib >> >> Thanks for the patch, I have applied it. can I ask you to forward it >> upstream as well? > > Seems this patch causes the package to FTBFS so I dropped it. Curious. It definitely worked for me back when I submitted it... > However, I see salsa CI > as green even w/o this patch so I'm keeping this bug as closed. I think the defaults for salsa-ci do not test build paths, so strictly speaking, the bug may still be there, though maybe lower priority, as tests.reproducible-builds.org also stopped testing build paths. live well, vagrant signature.asc Description: PGP signature
Bug#1061432: Add OrangePI PC Plus to sunxi platforms
On 2024-01-24, Лухнов Андрей Олегович wrote: > please consider adding OrangePI PC Plus to sunxi platforms. Changes > are trivial, proposed platform is buildable without errors and tested > bootable on target hardware. > > Required changes attached. Would you or someone else be willing to regularly test new versions of u-boot as they land in the archive? https://wiki.debian.org/U-boot/Status I prefer to list at least one person with contact information in the debian/targets.mk file so we know who to ask if problems arise. Because it supports over a thousand boards, board-specific regressions are unfortunately all too common in u-boot and it is helpful to find those regressions early. live well, vagrant signature.asc Description: PGP signature
Bug#1061298: u-boot: refresh patches
On 2024-01-22, Лухнов Андрей Олегович wrote: > I've quilt-refreshed patches in u-boot 2024.01+dfsg-1 to apply them > without fuzzyness. > > Please find, ahem, a patch for that attached. :) (I'm not sure, if it > is a correct method to propose a fix, though, or you could just run > quilt refresh yourself) Since the patches apply with "quilt push --fuzz=0 -a" I do not think this is currently needed. Is there something I am missing? live well, vagrant signature.asc Description: PGP signature
Bug#1061300: lcm: Update to version 1.5.0
On 2024-01-22, Jose Luis Rivero wrote: > lcm upstream released the version 1.5.0 on April 2023. It would be great to > have it packaged and available on Debian Sid. > > I canhelp with code changes if the maintainer or the team are willing to > sponsor and review them. Well the "team" is the Debian QA Group, which effectively means it needs an actual maintainer: https://bugs.debian.org/965945 On the positive side, any Debian Developer can make changes to the package, so your pool of potential sponsors is quite large! If you want to prepare an upload for someone to sponsor, this has some helpful information and infrastructure: https://mentors.debian.net/ live well, vagrant signature.asc Description: PGP signature
Bug#1061137: Doesn't work on SheevaPlug
Control: fixed 1061137 2023.04~rc2+dfsg-1 On 2024-01-19, Martin Michlmayr wrote: > Guido Lehwalder and Markus Krebs reported off-list that u-boot in > Debian stable is broken on SheevaPlug. > > Markus Krebs bisected the DENX source and reported: > >> last working commit: 3aa14d76182dbbaf9fed4deeaf362f083b9d2f5b >> >> next commit, which doesn't work on Sheevaplug: >> 5387b093cb7914b3c0404da928fa4bafdffac291 > > Vagrant Cascadian pointed out that this issue has been fixed in: > > commit 9a13a76e6256c51d04f41139733dbb31755e8d30 > Author: Stefan Roese > Date: Mon Jan 16 09:01:48 2023 +0100 > > timer: orion-timer: Fix problem in early_init_done() This commit was included in v2023.04-rc1, marking 2023.04~rc2+dfsg-1 as fixing the issue as it was the first fixed version uploaded to Debian. For the record, the upstream version currently in sid/unstable and trixie/testing (2024.01) has the issue fixed as well, as well as the previous 2023.07 version. > and prepared a test package: > >> I've pushed a work-in-progress branch to: >> >> https://salsa.debian.org/debian/u-boot/-/tree/debian/bookworm-wip?ref_type=heads > > Guido Lehwalder tested a binary with this change and reported > that it fixes the issue. > > So we need a stable update with this change. Thanks everyone! This is a pretty trivial fix, so including in the next bookworm/stable point release should work! live well, vagrant signature.asc Description: PGP signature
Bug#1044403: epoptes: Fails to build source after successful build
Control: tags 1044403 pending On 2023-08-13, Lucas Nussbaum wrote: > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). ... > More information about this class of issues, included common problems and > solutions, is available at > https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild ... >> dpkg-source -b . >> dpkg-source: info: using source format '3.0 (quilt)' >> dpkg-source: info: building epoptes using existing >> ./epoptes_23.01.orig.tar.gz >> dpkg-source: warning: file epoptes-23.01/epoptes.egg-info/SOURCES.txt has no >> final newline (either original or modified version) >> dpkg-source: info: local changes detected, the modified files are: >> epoptes-23.01/epoptes.egg-info/PKG-INFO >> epoptes-23.01/epoptes.egg-info/SOURCES.txt >> epoptes-23.01/epoptes.egg-info/dependency_links.txt >> epoptes-23.01/epoptes.egg-info/top_level.txt >> epoptes-23.01/po/epoptes.pot >> dpkg-source: error: aborting due to unexpected upstream changes, see >> /tmp/epoptes_23.01-1.diff.KKkbyp >> dpkg-source: info: Hint: make sure the version in debian/changelog matches >> the unpacked source tree >> dpkg-source: info: you can integrate the local changes with dpkg-source >> --commit >> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 >> >> E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage >> --sanitize-env -us -uc -rfakeroot -S' failed to run. Pushed a fix to git: https://github.com/epoptes/epoptes/commit/57e25218637dd9d2264fd876c50dacdd10778e51 live well, vagrant signature.asc Description: PGP signature
Bug#1027899: u-boot-menu: menu is not created by kernel-install command
On 2023-01-04, Manuel Traut wrote: > if kernel-install is called manualy the extlinux.conf file is not > generated. > > This can be resolved with an .install file in /usr/lib/kernel/install.d I uploaded a fix which calls u-boot-update from a hook in that directory, but it does not support the newly added feature to sync DTB files. # FIXME support U_BOOT_SYNC_DTBS on "add" and "remove" events This almost makes me wonder if u-boot-update shouldn't take some arguments so we do not have to duplicate the functionality across /usr/lib/kernel/install.d/ and /etc/kernel/post*.d/ hooks. live well, vagrant signature.asc Description: PGP signature
Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition
On 2022-12-12, Arnaud Ferraris wrote: > It is common practice for /boot to be on a separate partition, requiring DTBs > to be synced to this partition for u-boot to be able to access them. Thanks for working on this! > From: Arnaud Ferraris > Date: Mon, 12 Dec 2022 13:57:47 +0100 > Subject: [PATCH 1/2] u-boot-update: split config file reading to a separate > script > > The logic of reading the configuration file and determining whether > `/boot` is on a separate partition can be useful to other scripts, such > as the kernel postinst/postrm ones. This commit moves this code to a > separate, source-able script to make it more easily reusable. ... > debian/u-boot-menu.install | 1 + > read-config| 70 ++ > u-boot-update | 70 +- > 3 files changed, 72 insertions(+), 69 deletions(-) > create mode 100644 read-config Conceptually this change looks fine to me, though needs a bit of a refresh. > From: Arnaud Ferraris > Date: Mon, 12 Dec 2022 14:14:27 +0100 > Subject: [PATCH 2/2] Allow to automatically sync DTBs when /boot is on a > separate partition > > Having `/boot` on a separate partition is a very common use-case, > requiring device tree binary files to be copied over to this partition > as `u-boot` won't be searching other partitions for those. > > Up until now, users had to manually copy (and potentially edit) the > provided `zz-sync-dtb` example script if their system was using a > separate `/boot` partition, which isn't practical. > > This patch implements a way to automate this synchronization process > in such cases, and remove the synchronized files when the corresponding > kernel is removed as well. Yay! > In order to maintain the current behaviour, this feature is disabled by > default and must be enabled by setting the `U_BOOT_SYNC_DTBS` > configuration variable to `true`. Mixed feelings on weather it should be guarded in the long-term, but that makes sense at least at when first introducing this... > diff --git a/debian/u-boot-menu.install b/debian/u-boot-menu.install > index 695129f..4816e32 100644 > --- a/debian/u-boot-menu.install > +++ b/debian/u-boot-menu.install > @@ -1,4 +1,4 @@ > -read-config usr/share/u-boot-menu > -u-boot-update usr/sbin > -zz-u-boot-menu etc/kernel/postinst.d > -zz-u-boot-menu etc/kernel/postrm.d > +read-config usr/share/u-boot-menu > +u-boot-update usr/sbin > +postinst/zz-u-boot-menu etc/kernel/postinst.d > +postrm/zz-u-boot-menu etc/kernel/postrm.d As mentioned, please minimize the whitespace differences on a rebase or refresh of this patch. > diff --git a/default b/default > index 2e29c83..21801b4 100644 > --- a/default > +++ b/default > @@ -13,4 +13,4 @@ > #U_BOOT_FDT_DIR="/usr/lib/linux-image-" > #U_BOOT_FDT_OVERLAYS="" > #U_BOOT_FDT_OVERLAYS_DIR="/boot/dtbo/" > - > +#U_BOOT_SYNC_DTBS="false" I almost wish to kill off /etc/default/u-boot entirely... all of the defaults are commented out and could instead be shipped in /usr/share/u-boot-menu/conf.d/default.conf rather than embedded in the u-boot-update script (or the new read-config snippet). > diff --git a/postinst/zz-u-boot-menu b/postinst/zz-u-boot-menu ... > diff --git a/postrm/zz-u-boot-menu b/postrm/zz-u-boot-menu Those looked reasonable at a quick glance. > diff --git a/u-boot-update.8 b/u-boot-update.8 > index 12852ee..3f47c1b 100644 > --- a/u-boot-update.8 > +++ b/u-boot-update.8 > @@ -111,7 +111,8 @@ The default is 50. > .IP "U_BOOT_FDT_DIR=""\fB/usr/lib/linux-image-\fR""" 4 > This variable specifies the unversioned stem of paths > where U\-BOOT should look for the flattened device tree binaries. > -Default is '/usr/lib/linux-image-'. > +Default is '/usr/lib/linux-image-', or '/dtb-' when u\-boot\-update > +detects /boot is on a separate partition. ... and the configuration has U_BOOT_SYNC_DTBS=true (described later)? E.g. it does not detect a /boot partition unless U_BOOT_SYNC_DTBS=true? So it seems at the very least it needs a refresh, but looking over it all it looks conceptually good. live well, vagrant signature.asc Description: PGP signature
Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition
On 2023-11-13, Arnaud Ferraris wrote: > Le 18/05/2023 à 17:42, Vagrant Cascadian a écrit : >> >> Unfortunately, this will have to wait till after bookworm release, >> currently scheduled for June. > > Gentle ping with the hope that you (or Jonas) have some bandwidth to > take a look at this patch ;) Sorry it has taken so long to get a look at these ... especially because the patches no longer apply. :( I noticed a few whitespace changes in the original patch that almost hide some of the changes; this patch is involved enough that it would be nice to reduce these to make it easier to review, for example: diff --git a/debian/u-boot-menu.install b/debian/u-boot-menu.install index 695129f..4816e32 100644 --- a/debian/u-boot-menu.install +++ b/debian/u-boot-menu.install @@ -1,4 +1,4 @@ -read-config usr/share/u-boot-menu -u-boot-update usr/sbin -zz-u-boot-menu etc/kernel/postinst.d -zz-u-boot-menu etc/kernel/postrm.d +read-config usr/share/u-boot-menu +u-boot-update usr/sbin +postinst/zz-u-boot-menu etc/kernel/postinst.d +postrm/zz-u-boot-menu etc/kernel/postrm.d My guess is this was to align with the longer lines, but I'd personally rather see just the two lines of diff rather than rewriting the whole file. live well, vagrant signature.asc Description: PGP signature
Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B
On 2024-01-12, Vagrant Cascadian wrote: > On 2024-01-12, Vagrant Cascadian wrote: >> On 2024-01-12, Michael Fladischer wrote: >>> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with >>> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no >>> longer able to see any NVME drives: > ... >> I am getting this too. I had tested with a local build of >> 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of >> the very few commits between v2024.01-rc6 and v2024.01 seem relevent. > > I should also note that I am testing with u-boot on microSD, so it is > not specific to u-boot from SPI. > >> I also wonder about opensbi, which was fairly recently upgraded, >> although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had >> done... > > I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental) > works, which was built with the same opensbi version. In fact, the only > difference in the installed build-dependencies were perl related: > > - libperl5.36 (= 5.36.0-10+b1), > + libperl5.38 (= 5.38.2-2), > - perl (= 5.36.0-10+b1), > - perl-base (= 5.36.0-10+b1), > - perl-modules-5.36 (= 5.36.0-10), > + perl (= 5.38.2-2), > + perl-base (= 5.38.2-2), > + perl-modules-5.38 (= 5.38.2-2), > > I am attempting a local rebuild, will see how that goes... Well, rebuilding and just adding a new debian/changelog entry... worked. both from a reboot and from a cold start. That does not leave much to investigate, so is a bit worrying, but perhaps a binNMU would "fix" it? live well, vagrant signature.asc Description: PGP signature
Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B
On 2024-01-12, Vagrant Cascadian wrote: > On 2024-01-12, Michael Fladischer wrote: >> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with >> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no >> longer able to see any NVME drives: ... > I am getting this too. I had tested with a local build of > 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of > the very few commits between v2024.01-rc6 and v2024.01 seem relevent. I should also note that I am testing with u-boot on microSD, so it is not specific to u-boot from SPI. > I also wonder about opensbi, which was fairly recently upgraded, > although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had > done... I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental) works, which was built with the same opensbi version. In fact, the only difference in the installed build-dependencies were perl related: - libperl5.36 (= 5.36.0-10+b1), + libperl5.38 (= 5.38.2-2), - perl (= 5.36.0-10+b1), - perl-base (= 5.36.0-10+b1), - perl-modules-5.36 (= 5.36.0-10), + perl (= 5.38.2-2), + perl-base (= 5.38.2-2), + perl-modules-5.38 (= 5.38.2-2), I am attempting a local rebuild, will see how that goes... live well, vagrant signature.asc Description: PGP signature
Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B
On 2024-01-12, Michael Fladischer wrote: > I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with > u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no > longer able to see any NVME drives: ... >U-Boot 2024.01+dfsg-1 (Jan 10 2024 - 21:34:04 +) > >CPU: rv64imafdc >Model: SiFive HiFive Unmatched A00 >DRAM: 16 GiB >Core: 34 devices, 21 uclasses, devicetree: separate >MMC: spi@1005:mmc@0: 0 >Loading Environment from SPIFlash... SF: Detected is25wp256 with page size > 256 Bytes, erase size 4 KiB, total 32 MiB >*** Warning - bad CRC, using default environment > >EEPROM: SiFive PCB EEPROM format v1 >Product ID: 0002 (HiFive Unmatched) >PCB revision: 4 >BOM revision: B >BOM variant: 0 >Serial number: SF105SZ233800886 >Ethernet MAC address: 70:b3:d5:92:fe:ea >CRC: d2ac1d5b >pwren_gpio is invalid >In:serial@1001 >Out: serial@1001 >Err: serial@1001 >Model: SiFive HiFive Unmatched A00 >Net: eth0: ethernet@1009 >Working FDT set to ff72f630 >Hit any key to stop autoboot: 0 >pwren_gpio is invalid > >Device 0: unknown device >pwren_gpio is invalid > >Device 1: unknown device >starting USB... >No working controllers found >USB is stopped. Please issue 'usb start' first. >pwren_gpio is invalid >scanning bus for devices... I am getting this too. I had tested with a local build of 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of the very few commits between v2024.01-rc6 and v2024.01 seem relevent. I also wonder about opensbi, which was fairly recently upgraded, although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had done... Hrm. Will look a little deeper. I doubt it ws the removed unmatched-prevent-relocating-initrd-and-fdt.patch, as it is not even detecting the NVMe device... and the symptoms that necessitated that patch are after extlinux.conf is already loaded and the kernel attempts to boot... live well, vagrant signature.asc Description: PGP signature
Bug#1037281: Please add support for MediaTek MT7986 in U-Boot
On 2023-08-29, Diederik de Haas wrote: > On 10 Jun 2023-06-10 Vagrant Cascadian wrote: >> On 2023-06-10, Bernhard wrote: >> > I'm interested in the Router BANANA Pi R3 from Sinovoip: >> > https://wiki.banana-pi.org/Banana_Pi_BPI-R3 >> > >> > This Banana Pi has MediaTek MT7986 (Filogic 830). There are now two board configs in u-boot 2024.01 that might be relevent: configs/mt7986a_bpir3_emmc_defconfig configs/mt7986a_bpir3_sd_defconfig >> I cannot say what it will take to support it in debian for sure... >> ... >> The other main thing is to check what support is needed in the linux >> kernel... > > The good news is that it appears to be supported in the upstream kernel. ... > I have a script which helps with identifying which kernel modules would be > needed based on the "compatible" strings in the dts file and running it on > the > mt7986a-bananapi-bpi-r3.dts revealed 1 missing component ... but a rather > important one, which AFAICT is related to ARCH_MEDIATEK not being enabled. CONFIG_ARCH_MEDIATEK is now enabled in the Debian kernel configuration, although there are probably still other kernel configurations needed. Is this script available anywhere? :) Still outstanding is arm-trusted-firmwawre, only mediatek 81xx platforms so far: plat/mediatek/mt8173/ plat/mediatek/mt8186/ plat/mediatek/mt8192/ plat/mediatek/mt8183/ plat/mediatek/mt8188/ plat/mediatek/mt8195/ live well, vagrant signature.asc Description: PGP signature
Bug#1033497: u-boot-imx: cubox-i does not reboot after installation
Control: tags 1033497 confirmed On 2023-03-26, Rainer Dorsch wrote: > I installed bookworm on a cubox-i. After the installation was > finished, the installed reported that it reboots now. The reboot did > never complete tough. After I unplugged the power supply and replugged > it, it booted normally, therefore the functionality of the system is > not affected and it is a minor issue. I have also seen this on several occasions as well, marking as confirmed. live well, vagrant signature.asc Description: PGP signature
Bug#977177: mm-common: reproducible builds: Generated tarball includes user, group and file mode
Control: found 977177 1.0.6-1 Hi, it seems the changes in the 1.0.5-1.1 NMU were not included in the most recent upload... would you please consider including them? live well, vagrant On 2023-12-05, Vagrant Cascadian wrote: > On 2023-11-29, Vagrant Cascadian wrote: >> On 2020-12-12, Simon McVittie wrote: >>> On Fri, 11 Dec 2020 at 20:45:09 -0800, Vagrant Cascadian wrote: >> With the patch, I managed to produce a bit-for-bit identical >> skeletonmm.tar.xz with the patch applied, both in a test environment >> where the umask was varied, and with a fairly "normal" umask which was >> bit-for-bit identical to the skeletonmm.tar.xz in the mm-common package >> in the Debian archive. So it should not cause regressions! >> >> With this patch applied, mm-common should become reproducible on >> tests.reproducible-builds.org infrastructure! >> >> Would an upload including this patch be considered soon, or would the >> maintainers be open to an NMU in the near future? > > Uploaded to DELAYED/10 using dgit, debdiff follows: > > diff -Nru mm-common-1.0.5/debian/changelog mm-common-1.0.5/debian/changelog > --- mm-common-1.0.5/debian/changelog 2022-12-15 12:25:29.0 -0800 > +++ mm-common-1.0.5/debian/changelog 2023-12-05 15:03:37.0 -0800 > @@ -1,3 +1,14 @@ > +mm-common (1.0.5-1.1) unstable; urgency=medium > + > + [ Vagrant Cascadian ] > + * Non-maintainer upload. > + > + [ Simon McVittie ] > + * util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files in > +the generated tarball. (Closes: #977177) > + > + -- Vagrant Cascadian Tue, 05 Dec 2023 15:03:37 -0800 > + > mm-common (1.0.5-1) unstable; urgency=medium > >[ Jeremy Bicha ] > diff -Nru mm-common-1.0.5/debian/patches/series > mm-common-1.0.5/debian/patches/series > --- mm-common-1.0.5/debian/patches/series 2022-12-15 12:25:29.0 > -0800 > +++ mm-common-1.0.5/debian/patches/series 2023-12-05 15:03:37.0 > -0800 > @@ -0,0 +1 @@ > +utilmeson_auxskeletonmm-tarball.py-use-c.patch > diff -Nru > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > --- > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > 1969-12-31 16:00:00.0 -0800 > +++ > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > 2023-12-05 15:03:37.0 -0800 > @@ -0,0 +1,34 @@ > +From: Simon McVittie > +Date: Tue, 28 Nov 2023 16:57:13 -0800 > +X-Dgit-Generated: 1.0.5-1.1 77d8a907867d87eb56f57cfd5d3226aba19355d8 > +Subject: util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files > in > + > +the generated tarball. (Closes: #977177) > + > +Signed-off-by: Vagrant Cascadian > + > +--- > + > +diff --git a/util/meson_aux/skeletonmm-tarball.py > b/util/meson_aux/skeletonmm-tarball.py > +index 138184c..a87590e 100755 > +--- a/util/meson_aux/skeletonmm-tarball.py > b/util/meson_aux/skeletonmm-tarball.py > +@@ -10,6 +10,7 @@ import os > + import sys > + import shutil > + import tarfile > ++import stat > + > + if sys.argv[1] == 'check': > + # Called from run_command() during setup or configuration. > +@@ -42,6 +43,10 @@ else: > + def reset(tarinfo): > + tarinfo.uid = tarinfo.gid = 0 > + tarinfo.uname = tarinfo.gname = "root" > ++if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0: > ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755 > ++else: > ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644 > + return tarinfo > + > + > > > live well, > vagrant signature.asc Description: PGP signature
Bug#1053359: U-Boot debian/2024.01-rcX: u-boot-starfve
On 2024-01-06, Heinrich Schuchardt wrote: > I have built U-Boot from > > https://salsa.debian.org/debian/u-boot/-/commit/e182a8eb13eb6d1990a3d79740b71b0cc52f9f5a > Merge branch 'debian/2024.01-rcX' into debian/latest > > and deployed it to these boards: > > StarFive VisionFive 2 v1.3B, 4 GiB > StarFive VisionFive 2 v1.3B, 8 GiB > StarFive VisionFive 2 v1.2A, 4 GiB > > They boot fine via UEFI into Ubuntu. Thanks for testing! I plan to include them in an upload shortly... and then it should wait in ftp-master NEW queue... who knows how long that will take. That's why I merged the changes and then reverted them, as it is easier to deal with NEW when the upstream tarball is already present in the official repository... > It may be preferable to upgrade the dependency OpenSBI to v1.4 before > the new U-Boot release. I debated weather to bump the dependency, as OpenSBI is now v1.4 in unstable, so it should default to that version going forward... live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2024-01-05, Vagrant Cascadian wrote: > On 2023-11-23, Andreas Henriksson wrote: >> On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote: >>> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: >>> > On 2023-11-23, Andreas Henriksson wrote: > ... >>> > > 3/ do we include patches? >>> > > 3.1/ No patches. If this is the desired path I can volunteer >>> > > to test that it boots on my M1 machine. Other machines >>> > > should probably be considered unsupported for now, >>> > > even though they might have limited usefulness. >>> > > 3.2/ Minimal set of patches. We identify what we consider >>> > > crutial only patches and recruit volunteers to test. >>> > > M2 keyboard? USB? etc... >>> > > 3.3/ All asahi patches. We consider it simpler to just sync all patches >>> > > with the asahi fork (even though some are even unused, like the >>> > > devicetree patches). We trust the Asahi Linux project in their >>> > > quest to upstream all their work and that they will rebase on newer >>> > > releases and make our job easy. >>> > >>> > I am inclined towards starting with no patches or a minimal set of >>> > patches. The asashi folks do seem to generally do a good job of >>> > upstreaming, so support should improve over time. >> >> I'm not against going this route, my only concern is using the asahi >> name while shipping an "inferior" variant (no patches). The Asahi Linux >> people have been very good at being end-user focused, fixing all kind of >> bugs and really go above and beyond to not compromise on end user >> experience. Not sure they'd appreciate us shipping it under their name >> while exposing "already fixed" bugs but what do I know. >> We can always add patches later I guess. The Trixie freeze is not >> happening soon and we're not providing any installer yet, so it should >> just be a few #debian-bananas people trying this out for a while still >> I guess. > > This seems like the main blocker at this point; I am hoping to upload at > least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once > it releases), and it would be nice to include a u-boot variant > supporting these boards, but I am nervous about shipping patches. As > you pointed out an unpatched version with asashi in the name might not > be appreciated... but ... uh, er. Hrm. I would really like to get this > in! I guess we could include a note in the description? Something like: This package does not include all patches shipped by the asahi project, only patches that have been merged in mainline u-boot. live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2023-11-23, Andreas Henriksson wrote: > On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote: >> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: >> > On 2023-11-23, Andreas Henriksson wrote: ... >> > > 3/ do we include patches? >> > > 3.1/ No patches. If this is the desired path I can volunteer >> > > to test that it boots on my M1 machine. Other machines >> > > should probably be considered unsupported for now, >> > > even though they might have limited usefulness. >> > > 3.2/ Minimal set of patches. We identify what we consider >> > > crutial only patches and recruit volunteers to test. >> > > M2 keyboard? USB? etc... >> > > 3.3/ All asahi patches. We consider it simpler to just sync all patches >> > > with the asahi fork (even though some are even unused, like the >> > > devicetree patches). We trust the Asahi Linux project in their >> > > quest to upstream all their work and that they will rebase on newer >> > > releases and make our job easy. >> > >> > I am inclined towards starting with no patches or a minimal set of >> > patches. The asashi folks do seem to generally do a good job of >> > upstreaming, so support should improve over time. > > I'm not against going this route, my only concern is using the asahi > name while shipping an "inferior" variant (no patches). The Asahi Linux > people have been very good at being end-user focused, fixing all kind of > bugs and really go above and beyond to not compromise on end user > experience. Not sure they'd appreciate us shipping it under their name > while exposing "already fixed" bugs but what do I know. > We can always add patches later I guess. The Trixie freeze is not > happening soon and we're not providing any installer yet, so it should > just be a few #debian-bananas people trying this out for a while still > I guess. This seems like the main blocker at this point; I am hoping to upload at least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once it releases), and it would be nice to include a u-boot variant supporting these boards, but I am nervous about shipping patches. As you pointed out an unpatched version with asashi in the name might not be appreciated... but ... uh, er. Hrm. I would really like to get this in! live well, vagrant signature.asc Description: PGP signature
Bug#1020878: NMU reproducible builds patches for dustmite
On 2023-12-06, Vagrant Cascadian wrote:
> I would like to submit an NMU in the near future to apply the two
> patches submitted for dustmite to fix reproducibility issues, which are
> both essentially one-line patches:
>
> #1020878: dustmite: reproducible-builds: build path embedded in
> /usr/bin/dustmite
>
> debian/rules:
>
> +EXTRA_DFLAGS += -ffile-prefix-map=$(CURDIR)=.
>
> #1020879: dustmite: reproducible-builds: timezone/locale dependent date in
> /usr/bin/dustmite
>
> dustmite.d:
>
> - stdout.writeln("DustMite build ", __DATE__, " (", source, "),
> built with ", __VENDOR__, " ", __VERSION__);
> + stdout.writeln("DustMite build (", source, "), built with ",
> __VENDOR__, " ", __VERSION__);
I have uploaded an NMU to DELAYED/10 using dgit, with the following
changes:
diff -Nru dustmite-0.0.430/debian/changelog dustmite-0.0.430/debian/changelog
--- dustmite-0.0.430/debian/changelog 2022-08-03 16:05:44.0 -0700
+++ dustmite-0.0.430/debian/changelog 2023-12-19 16:10:14.0 -0800
@@ -1,3 +1,13 @@
+dustmite (0.0.430-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/rules: Add -ffile-prefix-map in EXTRA_DFLAGS to avoid embedding
+build paths. (Closes: #1020878)
+ * dustmite.d: Avoid embedding timezone and locale-specific build date in
+the binary. (Closes: #1020879)
+
+ -- Vagrant Cascadian Tue, 19 Dec 2023
16:10:14 -0800
+
dustmite (0.0.430-2) unstable; urgency=medium
* Add workaround for DMD frontend bug that has hit GDC as well
diff -Nru
dustmite-0.0.430/debian/patches/dustmite.d-avoid-embedding-timezone-and-.patch
dustmite-0.0.430/debian/patches/dustmite.d-avoid-embedding-timezone-and-.patch
---
dustmite-0.0.430/debian/patches/dustmite.d-avoid-embedding-timezone-and-.patch
1969-12-31 16:00:00.0 -0800
+++
dustmite-0.0.430/debian/patches/dustmite.d-avoid-embedding-timezone-and-.patch
2023-12-19 16:10:14.0 -0800
@@ -0,0 +1,24 @@
+From: Vagrant Cascadian
+Date: Tue, 27 Sep 2022 21:05:55 +
+X-Dgit-Generated: 0.0.430-2.1 4eff64636ff1acdf1b211ae89af3b2cf07ff4df0
+Subject: dustmite.d: Avoid embedding timezone and locale-specific build date in
+
+the binary. (Closes: #1020879)
+
+https://reproducible-builds.org/docs/timestamps/
+
+---
+
+diff --git a/dustmite.d b/dustmite.d
+index 3177cbe..918f49e 100644
+--- a/dustmite.d
b/dustmite.d
+@@ -209,7 +209,7 @@ int main(string[] args)
+ enum source = import("source");
+ else
+ enum source = "upstream";
+- stdout.writeln("DustMite build ", __DATE__, " (", source, "),
built with ", __VENDOR__, " ", __VERSION__);
++ stdout.writeln("DustMite build (", source, "), built with ",
__VENDOR__, " ", __VERSION__);
+ if (args.length == 1)
+ return 0;
+ }
diff -Nru dustmite-0.0.430/debian/patches/series
dustmite-0.0.430/debian/patches/series
--- dustmite-0.0.430/debian/patches/series 1969-12-31 16:00:00.0
-0800
+++ dustmite-0.0.430/debian/patches/series 2023-12-19 16:10:14.0
-0800
@@ -0,0 +1 @@
+dustmite.d-avoid-embedding-timezone-and-.patch
diff -Nru dustmite-0.0.430/debian/rules dustmite-0.0.430/debian/rules
--- dustmite-0.0.430/debian/rules 2022-08-03 15:53:24.0 -0700
+++ dustmite-0.0.430/debian/rules 2023-12-19 16:10:14.0 -0800
@@ -8,6 +8,7 @@
# workaround for DMD frontend bug
# first found via LDC: https://github.com/ldc-developers/ldc/issues/4000
EXTRA_DFLAGS += -fall-instantiations
+EXTRA_DFLAGS += -ffile-prefix-map=$(CURDIR)=.
override_dh_auto_build:
gdc -odustmite \
signature.asc
Description: PGP signature
Bug#1021522: NMU fixing reproducible builds and cross building
I have uploaded an NMU to DELAYED/10 using dgit containing the following
changes:
diff -Nru crack-5.0a/debian/changelog crack-5.0a/debian/changelog
--- crack-5.0a/debian/changelog 2021-02-03 13:09:40.0 -0800
+++ crack-5.0a/debian/changelog 2023-12-19 15:43:43.0 -0800
@@ -1,3 +1,17 @@
+crack (5.0a-13.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Vagrant Cascadian ]
+ * debian/Crack.make: Use dpkg-buildflags to set default CFLAGS.
+(Closes: #1021521)
+ * src/util/Makefile: Remove embedded timestamps. (Closes: #1021522)
+
+ [ Helmut Grohne ]
+ * Fix FTCBFS: Let dpkg's buildtools.mk seed CC. (Closes: #952791)
+
+ -- Vagrant Cascadian Tue, 19 Dec 2023
15:43:43 -0800
+
crack (5.0a-13) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru crack-5.0a/debian/Crack.make crack-5.0a/debian/Crack.make
--- crack-5.0a/debian/Crack.make2021-02-03 13:09:40.0 -0800
+++ crack-5.0a/debian/Crack.make2023-12-19 15:43:43.0 -0800
@@ -42,7 +42,7 @@
# - redhat linux 4.0
# - digital unix v4.0
-C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H
-DUSE_UNISTD_H -DUSE_PWD_H"
+C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H
-DUSE_UNISTD_H -DUSE_PWD_H $(dpkg-buildflags --get CFLAGS)"
#
# now pick your compiler
@@ -54,7 +54,7 @@
#LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD
MD5
# gcc 2.7.2
-CC=gcc
+: "${CC:=gcc}"
CFLAGS="-g -O2 -Wall -fstack-protector-strong -Wformat -Werror=format-security
$C5FLAGS"
LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD
MD5
diff -Nru crack-5.0a/debian/patches/series crack-5.0a/debian/patches/series
--- crack-5.0a/debian/patches/series2021-02-03 13:09:40.0 -0800
+++ crack-5.0a/debian/patches/series2023-12-19 15:43:43.0 -0800
@@ -9,3 +9,4 @@
src___libdes___stcmuMmo.patch
b64_shebang.patch
fix-spelling.patch
+srcutilmakefile-remove-embedded-timestam.patch
diff -Nru
crack-5.0a/debian/patches/srcutilmakefile-remove-embedded-timestam.patch
crack-5.0a/debian/patches/srcutilmakefile-remove-embedded-timestam.patch
--- crack-5.0a/debian/patches/srcutilmakefile-remove-embedded-timestam.patch
1969-12-31 16:00:00.0 -0800
+++ crack-5.0a/debian/patches/srcutilmakefile-remove-embedded-timestam.patch
2023-12-19 15:43:43.00000 -0800
@@ -0,0 +1,41 @@
+From: Vagrant Cascadian
+Date: Mon, 10 Oct 2022 00:10:18 +
+X-Dgit-Generated: 5.0a-13.1 4b5ff2399a1e1918a708e8dca0b5548db398b24a
+Subject: src/util/Makefile: Remove embedded timestamps.
+
+(Closes: #1021522)
+
+https://reproducible-builds.org/docs/timestamps/
+
+---
+
+diff --git a/src/util/Makefile b/src/util/Makefile
+index b2a96c3..f09bb9f 100644
+--- a/src/util/Makefile
b/src/util/Makefile
+@@ -42,25 +42,21 @@ $(XDIR)/stdlib-cracker: cracker.c $(XLIB)
+ $(CC) $(CFLAGS) -c elcid.c
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o
$(XLIB)
+- date > $@
+
+ $(XDIR)/libdes-cracker: cracker.c $(XLIB)
+ $(CC) $(CFLAGS) -c elcid.c
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
../libdes/libdes.a
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o
$(XLIB) ../libdes/libdes.a
+- date > $@
+
+ $(XDIR)/ufc-cracker: cracker.c $(XLIB)
+ $(CC) $(CFLAGS) -DINITDES -DFCRYPT -c elcid.c
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
../ufc-crypt/libufc.a
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o
$(XLIB) ../ufc-crypt/libufc.a
+- date > $@
+
+ $(XDIR)/gnu-cracker: cracker.c $(XLIB)
+ $(CC) $(CFLAGS) -c elcid.c
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/cracker cracker.c elcid.o $(XLIB)
../crypt/libufc.a
+ $(CC) $(CFLAGS) $(LDFLAGS) -o $(XDIR)/dictfilt dictfilt.c elcid.o
$(XLIB) ../crypt/libufc.a
+- date > $@
+
+ #--
+
diff -Nru crack-5.0a/debian/rules crack-5.0a/debian/rules
--- crack-5.0a/debian/rules 2021-02-03 13:09:40.0 -0800
+++ crack-5.0a/debian/rules 2023-12-19 15:43:43.0 -0800
@@ -2,6 +2,8 @@
#export DH_VERBOSE=1
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
%:
dh $@
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1031829: gawk: please make the build reproducible
On 2023-02-23, Chris Lamb wrote: > This is because the gawkbug script contained the contents of the CFLAGS > environment variable, and this can contain the full build path via/by > embedding -ffile-prefix-map. ... > --- a/debian/rules2023-02-23 10:40:16.745966821 -0800 > --- b/debian/rules2023-02-23 10:58:04.377850011 -0800 > @@ -34,6 +34,8 @@ > rm -f debian/gawk/usr/bin/awk > # Remove fake info files (see README.source). > rm -rf debian/gawk/usr/share/info > + # Make gawkbug reproducible > + sed -i -e 's@$(CURDIR)@/build/dir@g' debian/gawk/usr/bin/gawkbug > > override_dh_auto_clean: > dh_auto_clean I can confirm the issue is still present, and the suggeste patch works around the issue. We are no longer testing build paths on tests.reproducible-builds.org, though other tooling such as reprotest or sbuild still do out of the box, so it would be nice to get fixed regardless. live well, vagrant signature.asc Description: PGP signature
Bug#1009934: openssl: reproducible-builds: Embeded compiler flags contain build paths
On 2022-05-01, Vagrant Cascadian wrote: > On 2022-05-01, Sebastian Andrzej Siewior wrote: >> control: forwarded -1 https://github.com/openssl/openssl/pull/11545 >> >> On 2022-04-20 15:46:41 [-0700], Vagrant Cascadian wrote: >>> The compiler flags usually contain the build path on Debian package >>> builds, and openssl embeds the compiler flags used in various binaries: >> … >>> Unfortunately, there are other outstanding issues affecting the >>> reproducibility of openssl, but applying this patch should reduce the >>> differences, making it easier to debug the remaining issues. >> >> so this report looked awkwardly familiar. The pull request >> https://github.com/openssl/openssl/pull/11545 >> >> should work for you, right? > > That looks great, glad it is in progress! > > It should be updated to also handle -fmacro-prefix-map and > -ffile-prefix-map (basically combining both -fmacro-prefix-map and > -fdebug-prefix-map), which were more recently added to various > compilers. > > Fairly recently -ffile-prefix-map became the default dpkg-buildflags. > > I'll comment on the pull request... This seems to have stalled out upstream. Tha main blocking concern appears to have been regarding finding debug symbols if this were enabled by default. Since debian has other more reliable mechanisms to find the debug symbols, would the maintainers of the Debian packages consider applying the patches? From what I recall, other than making sure it worked with all three permutations, (fdebug|fmacro|ffile)-prefix-map, the patches looked workable to me! We are no longer testing build paths on tests.reproducible-builds.org, though other tooling such as reprotest or sbuild still do out of the box, so it would be nice to get fixed regardless. live well, vagrant signature.asc Description: PGP signature
Bug#1050727: zlib: please make the build reproducible
Version: 1:1.3.dfsg-3 On 2023-08-28, Chris Lamb wrote: > This is because it embeds the absolute build path in the minizip and > miniunzip scripts. > > A patch attached that uses sed to remove these, (although there might > be a cleaner way to inform autotools/libtool to not do this code > injection). I am unable to locally reproduce the issue with the current version in Debian, marking as done. While tests.reproducible-builds.org also confirms no unreproducibility results for this version, it no longer tests for build path related issues. live well, vagrant signature.asc Description: PGP signature
Bug#1017473: psi: please make the build reproducible
On 2022-08-16, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> psi could not be built reproducibly.
>
> This is because that it embeds a build date that varies depending on
> the current timezone. Patch attached that ensures that UTC is used.
Yesterday I Uploaded an NMU to DELAYED/10 using dgit with the following
changes:
diff -Nru psi-1.5+dfsg1/debian/changelog psi-1.5+dfsg1/debian/changelog
--- psi-1.5+dfsg1/debian/changelog 2019-12-31 16:00:01.0 -0800
+++ psi-1.5+dfsg1/debian/changelog 2023-12-07 13:16:09.0 -0800
@@ -1,3 +1,12 @@
+psi (1.5+dfsg1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Chris Lamb ]
+ * Make the build reproducible (Closes: #1017473)
+
+ -- Vagrant Cascadian Thu, 07 Dec 2023
13:16:09 -0800
+
psi (1.5+dfsg1-1) unstable; urgency=medium
* New upstream release.
diff -Nru
psi-1.5+dfsg1/debian/patches/make-the-build-reproducible-closes-10174.patch
psi-1.5+dfsg1/debian/patches/make-the-build-reproducible-closes-10174.patch
--- psi-1.5+dfsg1/debian/patches/make-the-build-reproducible-closes-10174.patch
1969-12-31 16:00:00.0 -0800
+++ psi-1.5+dfsg1/debian/patches/make-the-build-reproducible-closes-10174.patch
2023-12-07 13:16:09.0 -0800
@@ -0,0 +1,23 @@
+From: Chris Lamb
+Date: Tue, 16 Aug 2022 13:53:48 -0700
+X-Dgit-Generated: 1.5+dfsg1-1.1 dd0f9f00250fd9aae2920dd7898d4e08e7307666
+Subject: Make the build reproducible (Closes: #1017473)
+
+
+---
+
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index 020c68e..5954ab1 100644
+--- a/src/CMakeLists.txt
b/src/CMakeLists.txt
+@@ -179,8 +179,8 @@ else()
+ include_directories(${Iris_INCLUDE_DIR})
+ endif()
+
+-string(TIMESTAMP PSI_COMPILATION_DATE "%Y-%m-%d")
+-string(TIMESTAMP PSI_COMPILATION_TIME "%H:%M:%S")
++string(TIMESTAMP PSI_COMPILATION_DATE "%Y-%m-%d" UTC)
++string(TIMESTAMP PSI_COMPILATION_TIME "%H:%M:%S" UTC)
+
+ if(ENABLE_WEBKIT)
+ if(NOT USE_WEBENGINE)
diff -Nru psi-1.5+dfsg1/debian/patches/series
psi-1.5+dfsg1/debian/patches/series
--- psi-1.5+dfsg1/debian/patches/series 2019-12-31 16:00:01.0 -0800
+++ psi-1.5+dfsg1/debian/patches/series 2023-12-07 13:16:09.0 -0800
@@ -1 +1,2 @@
01_install-hicolor-icons.patch
+make-the-build-reproducible-closes-10174.patch
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1020877: edid-decode: reproducible builds: timezone dependent timestamps embedded in /usr/bin/edid-decode
On 2022-09-27, Vagrant Cascadian wrote: > A timezone-dependent timestamp is embedded in /usr/games/edid-decode: > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/edid-decode.html > > 2022-03-29·21:29:27 > vs. > 2022-03-30·23:29:27 > > The attached patch to debian/rules fixes this by ensuring the date is > output in the UTC timezone. Yesterday I uploaded an NMU to DELAYED/10 and pushed the changes to git, as well as uploaded with dgit. The following changes were in included: diff -Nru edid-decode-0.1~git20220315.cb74358c2896/debian/changelog edid-decode-0.1~git20220315.cb74358c2896/debian/changelog --- edid-decode-0.1~git20220315.cb74358c2896/debian/changelog 2022-03-30 02:29:27.0 -0700 +++ edid-decode-0.1~git20220315.cb74358c2896/debian/changelog 2023-12-07 12:32:06.0 -0800 @@ -1,3 +1,11 @@ +edid-decode (0.1~git20220315.cb74358c2896-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Use UTC date to ensure reproducible builds regardless of +timezone. (Closes: #1020877) + + -- Vagrant Cascadian Thu, 07 Dec 2023 12:32:06 -0800 + edid-decode (0.1~git20220315.cb74358c2896-1) unstable; urgency=medium * New upstream snapshot. diff -Nru edid-decode-0.1~git20220315.cb74358c2896/debian/rules edid-decode-0.1~git20220315.cb74358c2896/debian/rules --- edid-decode-0.1~git20220315.cb74358c2896/debian/rules 2022-03-30 02:29:27.0 -0700 +++ edid-decode-0.1~git20220315.cb74358c2896/debian/rules 2023-12-07 12:32:06.0 -0800 @@ -7,4 +7,4 @@ dh $@ override_dh_auto_build: - dh_auto_build -- sha=-DSHA=$(lastword $(subst ., ,$(DEB_VERSION_UPSTREAM))) date=-DDATE=\""$(shell date -d@$(SOURCE_DATE_EPOCH) '+%F %T')"\" + dh_auto_build -- sha=-DSHA=$(lastword $(subst ., ,$(DEB_VERSION_UPSTREAM))) date=-DDATE=\""$(shell date -u -d@$(SOURCE_DATE_EPOCH) '+%F %T')"\" live well, vagrant signature.asc Description: PGP signature
Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH
On 2021-12-17, Ryan Pavlik wrote: > Oh wow, thanks! I was trying to figure out why it wasn't reproducible even > though it "should have" been. I'll apply this soon. > > On Fri, Dec 17, 2021, 6:09 PM Vagrant Cascadian < > vagr...@reproducible-builds.org> wrote: ... >> The RPATH contains the build path resulting in different buildid: ... >> The attached patch to debian/rules passes >> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override, >> which should use a relative path for RPATH. I see this was committed to git over a year ago: https://salsa.debian.org/science-team/meshlab/-/commit/3ceca5b00a27414fecc489cd6d55483a61fe2d80 ... but a new upload has not landed in the archive! I could sponsor an upload or perform an NMU, if that would be helpful? live well, vagrant signature.asc Description: PGP signature
Bug#1002671: python-parse-type: reproducible builds: Timestamps, timing and hostname in result.xml
On 2021-12-26, Vagrant Cascadian wrote: > There are two result.xml files shipped in the .deb package which contain > timestamp, timing, and hostname information about the build environment: > > ./usr/lib/python3/dist-packages/build/testing/report.xml > > -tests="218" time="0.660" timestamp="2021-12-26T13:32:24.664241" > hostname="osuosl174-amd64"> > > vs. > > +tests="218" time="0.654" timestamp="2022-10-18T19:37:34.113136" > hostname="osuosl174-amd64"> > > > The attached patch fixes this by removing these files from debian/rules > in a dh_install override. I have uploaded an NMU to DELAYED/10 using dgit containing the following changes: diff -Nru python-parse-type-0.5.6/debian/changelog python-parse-type-0.5.6/debian/changelog --- python-parse-type-0.5.6/debian/changelog2021-12-14 02:54:59.0 -0800 +++ python-parse-type-0.5.6/debian/changelog2023-12-06 17:24:19.0 -0800 @@ -1,3 +1,11 @@ +python-parse-type (0.5.6-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Delete test suite log from dh_install override. +(Closes: #1002671) + + -- Vagrant Cascadian Wed, 06 Dec 2023 17:24:19 -0800 + python-parse-type (0.5.6-1) unstable; urgency=medium * Team upload. diff -Nru python-parse-type-0.5.6/debian/rules python-parse-type-0.5.6/debian/rules --- python-parse-type-0.5.6/debian/rules2021-12-11 09:18:57.0 -0800 +++ python-parse-type-0.5.6/debian/rules2023-12-06 17:24:19.0 -0800 @@ -4,3 +4,10 @@ %: dh $@ --with python3 --buildsystem=pybuild + +override_dh_install: + # Delete log of test suite which contains dates and timing + # information for reproducible builds. + find debian/python3-parse-type/usr/lib/python*/dist-packages/build/testing/ \ + -name report.xml -delete -print + dh_install live well, vagrant signature.asc Description: PGP signature
Bug#1020878: NMU reproducible builds patches for dustmite
I would like to submit an NMU in the near future to apply the two
patches submitted for dustmite to fix reproducibility issues, which are
both essentially one-line patches:
#1020878: dustmite: reproducible-builds: build path embedded in
/usr/bin/dustmite
debian/rules:
+EXTRA_DFLAGS += -ffile-prefix-map=$(CURDIR)=.
#1020879: dustmite: reproducible-builds: timezone/locale dependent date in
/usr/bin/dustmite
dustmite.d:
- stdout.writeln("DustMite build ", __DATE__, " (", source, "),
built with ", __VENDOR__, " ", __VERSION__);
+ stdout.writeln("DustMite build (", source, "), built with ",
__VENDOR__, " ", __VERSION__);
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1035375: mtools: interprets SOURCE_DATE_EPOCH in system timezone instead of UTC
On 2023-05-02, Chris Lamb wrote: >> I came across timestamp differences in FAT filesystem images while >> trying to build debian-installer with debrepro (among many other >> things), and tracked it down to mmd/mcopy calls. Here's a short reproducer: > > Ah, interesting! And your reproducer is extremely helpful, and > I've managed to put together a proof-of-concept patch: > > --- a/directory.c > +++ b/directory.c > @@ -104,7 +104,7 @@ struct directory *mk_entry(const dos_name_t *dn, > unsigned char attr, > uint8_t hour, min_hi, min_low, sec; > uint8_t year, month_hi, month_low, day; > > - now = localtime(); > + now = gmtime(); > dosnameToDirentry(dn, ndir); > ndir->attr = attr; > ndir->ctime_ms = 0; > -- > 2.40.1 > > I've gone ahead and forwarded this to the mtools mailing list here: > > https://lists.gnu.org/archive/html/info-mtools/2023-05/msg0.html Did that get a response from upstream? Seems like a simple patch with limited chance of introducing problems... maybe a slightly more complicated veresion that only does this when SOURCE_DATE_EPOCH is set. Maybe it could be applied to the debian mtools package to at least give it some real-world testing? :) live well, vagrant signature.asc Description: PGP signature
Bug#1005826: mpl-sphinx-theme: please make the build reproducible
On 2022-02-15, Chris Lamb wrote:
> This is because the documentation embedded the current build year. A
> patch is attached that optionally uses SOURCE_DATE_EPOCH [1] as the
> source of this value instead.
I have uploaded an NMU to DELAYED/10 using dgit, applying the fix that
was merged upstream, with the following changes:
diff -Nru mpl-sphinx-theme-3.5.0/debian/changelog
mpl-sphinx-theme-3.5.0/debian/changelog
--- mpl-sphinx-theme-3.5.0/debian/changelog 2022-06-21 20:36:30.0
-0700
+++ mpl-sphinx-theme-3.5.0/debian/changelog 2023-12-06 15:59:56.0
-0800
@@ -1,3 +1,12 @@
+mpl-sphinx-theme (3.5.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Chris Lamb ]
+ * Make the documentation build reproducibly (Closes: #1005826)
+
+ -- Vagrant Cascadian Wed, 06 Dec 2023
15:59:56 -0800
+
mpl-sphinx-theme (3.5.0-1) unstable; urgency=medium
* New upstream release
diff -Nru
mpl-sphinx-theme-3.5.0/debian/patches/make-the-documentation-build-reproducibl.patch
mpl-sphinx-theme-3.5.0/debian/patches/make-the-documentation-build-reproducibl.patch
---
mpl-sphinx-theme-3.5.0/debian/patches/make-the-documentation-build-reproducibl.patch
1969-12-31 16:00:00.0 -0800
+++
mpl-sphinx-theme-3.5.0/debian/patches/make-the-documentation-build-reproducibl.patch
2023-12-06 15:59:56.0 -0800
@@ -0,0 +1,52 @@
+From: Chris Lamb
+Date: Tue, 15 Feb 2022 13:49:50 -0800
+X-Dgit-Generated: 3.5.0-1.1 671e8647bfcbc3f8fccec0ef82441394d23240d6
+Subject: Make the documentation build reproducibly (Closes: #1005826)
+
+Whilst working on the Reproducible Builds effort [0], I noticed that
+mpl-sphinx-theme could not be built reproducibly.
+
+This is because the documentation embedded the current build year. This patch
+changes the behaviour of the Sphinx documentation so that it can that
+optionally use SOURCE_DATE_EPOCH [1] as the source of this value instead.
+
+I originally filed this in Debian as bug #1005826 [2].
+
+ [0] https://reproducible-builds.org/
+ [1] https://reproducible-builds.org/specs/source-date-epoch/
+ [2] https://bugs.debian.org/1005826
+
+Bug-Upstream: https://github.com/matplotlib/mpl-sphinx-theme/pull/25
+Origin:
https://github.com/matplotlib/mpl-sphinx-theme/commit/5467339267c874338c41364965a99b2dadb8d7cd
+
+---
+
+diff --git a/docs/conf.py b/docs/conf.py
+index d77eefc..9dbf3dd 100644
+--- a/docs/conf.py
b/docs/conf.py
+@@ -1,3 +1,5 @@
++import os
++import time
+ import datetime
+
+ # Configuration file for the Sphinx documentation builder for
+@@ -6,11 +8,17 @@ import datetime
+ # Release mode enables optimizations and other related options.
+ is_release_build = tags.has('release') # noqa
+
++# Parse year using SOURCE_DATE_EPOCH, falling back to current time.
++# https://reproducible-builds.org/specs/source-date-epoch/
++build_date = datetime.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++
+ # -- Project information -
+
+ project = "Matplotlib Sphinx Theme"
+ copyright = (
+-f"2012 - {datetime.datetime.now().year} The Matplotlib development team"
++f"2012 - {build_date.year} The Matplotlib development team"
+ )
+ author = "Matplotlib Developers"
+
diff -Nru mpl-sphinx-theme-3.5.0/debian/patches/series
mpl-sphinx-theme-3.5.0/debian/patches/series
--- mpl-sphinx-theme-3.5.0/debian/patches/series1969-12-31
16:00:00.0 -0800
+++ mpl-sphinx-theme-3.5.0/debian/patches/series2023-12-06
15:59:56.0 -0800
@@ -0,0 +1 @@
+make-the-documentation-build-reproducibl.patch
live well,
vagrant
signature.asc
Description: PGP signature
Bug#995809: libinput: please make the build reproducible
On 2023-12-01, Vagrant Cascadian wrote:
> On 2021-10-06, Chris Lamb wrote:
>> This is due to the use of the LIBINPUT_QUIRKS_DIR macro which includes
>> the absolute build path.
>>
>> It is not entirely clear (during a very brief look) when/where this
>> value is even used — the testsuite still passes even if this is set to
>> a dummy value (see attached dummy patch). And, of course, the build
>> path cannot be relied upon at runtime.
>
> The attached patch is an alternate approach by removing the code that
> actually references the build path from various source files. It also
> makes the build reproducible and the package still builds (so I presume
> the test suite passes).
>
> As Chris pointed out, the build path is not something one can rely on at
> runtime, so the installed package cannot rely on it anyways.
>
> I would like to perform an NMU in the near future, unless there are
> objections?
I have uploaded an NMU to DELAYED/10 using dgit with the following
changes:
diff -Nru libinput-1.23.0/debian/changelog libinput-1.23.0/debian/changelog
--- libinput-1.23.0/debian/changelog2023-06-13 17:30:14.0 -0700
+++ libinput-1.23.0/debian/changelog2023-12-06 15:10:33.0 -0800
@@ -1,3 +1,10 @@
+libinput (1.23.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * tools: Remove references to LIBINPUT_QUIRKS_SRCDIR. (Closes: #995809)
+
+ -- Vagrant Cascadian Wed, 06 Dec 2023
15:10:33 -0800
+
libinput (1.23.0-2) unstable; urgency=medium
* debian/control:
diff -Nru libinput-1.23.0/debian/patches/series
libinput-1.23.0/debian/patches/series
--- libinput-1.23.0/debian/patches/series 2023-05-29 16:50:56.0
-0700
+++ libinput-1.23.0/debian/patches/series 2023-12-06 15:10:33.0
-0800
@@ -1 +1,2 @@
#placeholder
+tools-remove-references-to-libinput_quir.patch
diff -Nru
libinput-1.23.0/debian/patches/tools-remove-references-to-libinput_quir.patch
libinput-1.23.0/debian/patches/tools-remove-references-to-libinput_quir.patch
---
libinput-1.23.0/debian/patches/tools-remove-references-to-libinput_quir.patch
1969-12-31 16:00:00.0 -0800
+++
libinput-1.23.0/debian/patches/tools-remove-references-to-libinput_quir.patch
2023-12-06 15:10:33.0 -0800
@@ -0,0 +1,87 @@
+From: Vagrant Cascadian
+Date: Fri, 1 Dec 2023 14:17:20 -0800
+X-Dgit-Generated: 1.23.0-2.1 8d72c3fd82d3eb08e28adc552aaeb93df83f9d3a
+Subject: tools: Remove references to LIBINPUT_QUIRKS_SRCDIR. (Closes: #995809)
+
+This embeds the build path which is not generally available at runtime and
+makes it more difficult to reproduce the build.
+
+https://reproducible-builds.org/docs/build-path/
+
+---
+
+diff --git a/tools/libinput-quirks.c b/tools/libinput-quirks.c
+index e97eff6..7f3e26f 100644
+--- a/tools/libinput-quirks.c
b/tools/libinput-quirks.c
+@@ -166,14 +166,8 @@ main(int argc, char **argv)
+
+ /* Overriding the data dir means no custom override file */
+ if (!data_path) {
+- char *builddir = builddir_lookup();
+- if (builddir) {
+- data_path = LIBINPUT_QUIRKS_SRCDIR;
+- free(builddir);
+- } else {
+- data_path = LIBINPUT_QUIRKS_DIR;
+- override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
+- }
++ data_path = LIBINPUT_QUIRKS_DIR;
++ override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
+ }
+
+ quirks = quirks_init_subsystem(data_path,
+diff --git a/tools/libinput-record.c b/tools/libinput-record.c
+index 30b2900..1de63bc 100644
+--- a/tools/libinput-record.c
b/tools/libinput-record.c
+@@ -1762,19 +1762,10 @@ print_device_quirks(struct record_device *dev)
+ struct quirks_context *quirks;
+ const char *data_path = LIBINPUT_QUIRKS_DIR;
+ const char *override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
+- char *builddir = NULL;
+
+ if (stat(dev->devnode, ) < 0)
+ return;
+
+- if ((builddir = builddir_lookup())) {
+- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
+- data_path = LIBINPUT_QUIRKS_SRCDIR;
+- override_file = NULL;
+- }
+-
+- free(builddir);
+-
+ quirks = quirks_init_subsystem(data_path,
+ override_file,
+ quirks_log_handler,
+diff --git a/tools/shared.c b/tools/shared.c
+index 7a73027..fcacb03 100644
+--- a/tools/shared.c
b/tools/shared.c
+@@ -411,16 +411,6 @@ tools_open_device(const char **paths, bool verbose, bool
*grab)
+ return li;
+ }
+
+-static void
+-tools_setenv_quirks_dir(void)
+-{
+- char *builddir = builddir_lookup();
+- if (builddir) {
+- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
+- free(builddir);
+- }
Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so
On 2023-11-30, Vagrant Cascadian wrote:
> On 2021-07-09, Vagrant Cascadian wrote:
>> From 88b66063c5f02ba48f2fc9cfa2ae6cc42c950cc8 Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian
>> Date: Fri, 9 Jul 2021 15:13:24 +
>> Subject: [PATCH] Use the build date from SOURCE_DATE_EPOCH if set, falling
>> back to current time.
>>
>> https://reproducible-builds.org/docs/source-date-epoch/
>> ---
>> Makefile | 2 +-
>> buildflags.mak | 8
>> ipath/Makefile | 2 +-
>> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> I would like to propose an NMU with this patch applied in the near
> future. Please let me know if there are objections.
I have uploaded an NMU to DELAYED/10 with the following changes:
diff -Nru infinipath-psm-3.3+20.604758e7/debian/changelog
infinipath-psm-3.3+20.604758e7/debian/changelog
--- infinipath-psm-3.3+20.604758e7/debian/changelog 2022-10-16
04:18:17.0 -0700
+++ infinipath-psm-3.3+20.604758e7/debian/changelog 2023-12-06
14:25:32.0 -0800
@@ -1,3 +1,11 @@
+infinipath-psm (3.3+20.604758e7-6.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use the build date from SOURCE_DATE_EPOCH if set, falling back to
+current time. (Closes: #990862)
+
+ -- Vagrant Cascadian Wed, 06 Dec 2023
14:25:32 -0800
+
infinipath-psm (3.3+20.604758e7-6.2) unstable; urgency=medium
* Non-maintainer upload
diff -Nru infinipath-psm-3.3+20.604758e7/debian/patches/series
infinipath-psm-3.3+20.604758e7/debian/patches/series
--- infinipath-psm-3.3+20.604758e7/debian/patches/series2022-10-16
04:18:17.0 -0700
+++ infinipath-psm-3.3+20.604758e7/debian/patches/series2023-12-06
14:25:32.0 -0800
@@ -2,3 +2,4 @@
0002-Include-sys-sysmacros.h-to-avoid-warning-about-minor.patch
0003-gcc8.patch
0004-gcc-11-warning.patch
+use-the-build-date-from-source_date_epoc.patch
diff -Nru
infinipath-psm-3.3+20.604758e7/debian/patches/use-the-build-date-from-source_date_epoc.patch
infinipath-psm-3.3+20.604758e7/debian/patches/use-the-build-date-from-source_date_epoc.patch
---
infinipath-psm-3.3+20.604758e7/debian/patches/use-the-build-date-from-source_date_epoc.patch
1969-12-31 16:00:00.0 -0800
+++
infinipath-psm-3.3+20.604758e7/debian/patches/use-the-build-date-from-source_date_epoc.patch
2023-12-06 14:25:32.0 -0800
@@ -0,0 +1,53 @@
+From: Vagrant Cascadian
+Date: Fri, 9 Jul 2021 15:13:24 +
+X-Dgit-Generated: 3.3+20.604758e7-6.3 b8d331f9a8fd602863fd5b749cd0f26411889da4
+Subject: Use the build date from SOURCE_DATE_EPOCH if set, falling back to
+
+current time. (Closes: #990862)
+
+https://reproducible-builds.org/docs/source-date-epoch/
+
+---
+
+diff --git a/Makefile b/Makefile
+index d79c4bd..64d6f6b 100644
+--- a/Makefile
b/Makefile
+@@ -270,7 +270,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
+ # file around. Generate it such that the ident command can find it
+ # and strings -a | grep InfiniPath does a reasonable job as well.
+ ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
+- date +'char psmi_infinipath_revision[] ="$$""Date: %F %R
${rpm_extra_description}InfiniPath $$";' > ${lib_build_dir}/_revision.c
++ printf 'char psmi_infinipath_revision[] ="$$""Date: %s
${rpm_extra_description} InfiniPath $$";\n' "$(BUILD_DATE)" >
${lib_build_dir}/_revision.c
+ $(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
+ $(CC) $(LDFLAGS) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared
-Wl,--unique='*fastpath*' \
+ ${${TARGLIB}-objs} _revision.o -L$(build_dir)/ipath $(LDLIBS)
+diff --git a/buildflags.mak b/buildflags.mak
+index 34fdf1c..be40c40 100644
+--- a/buildflags.mak
b/buildflags.mak
+@@ -96,3 +96,11 @@ endif
+ CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
+ $(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
+
++# Use SOURCE_DATE_EPOCH for build date, falling back to current time
++# https://reproducible-builds.org/docs/source-date-epoch/
++DATE_FMT="+'%F %R'"
++ifdef SOURCE_DATE_EPOCH
++BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null ||
date -u "$(DATE_FMT)")
++else
++BUILD_DATE ?= $(shell date "$(DATE_FMT)")
++endif
+diff --git a/ipath/Makefile b/ipath/Makefile
+index 8c2cc6e..e627b3d 100644
+--- a/ipath/Makefile
b/ipath/Makefile
+@@ -70,7 +70,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
+ # file around. Generate it such that the ident command can find it
+ # and strings -a | grep InfiniPath does a reasonable job as well.
+ ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
+- date +'static __attribute__ ((unused)) char __psc_infinipath_
Bug#983138: ypserv: /bin/sh symlink triggers differences in pwupdate
On 2023-11-30, Vagrant Cascadian wrote: > On 2022-08-05, Vagrant Cascadian wrote: >> On 2022-08-05, Vagrant Cascadian wrote: >>> On 2022-08-05, Francesco P. Lovergine wrote: >>>> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote: >>>>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote: >>>>>> The configure script sets the BASH variable to /bin/sh when run on a >>>>>> usrmerge system, resulting in the pwupdate script differing between >>>>>> builds: >>>>>> >>>>>> >>>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html >>>>>> >>>>>> ./usr/lib/yp/pwupdate >>>>>> >>>>>> #!/bin/bash >>>>>> vs. >>>>>> #!/bin/sh ... >> Regardless, the patch would make the package build reproducibly, and >> would be great to apply. > > I would like to perform an NMU fixing this in the near future, barring > any strong objections. I uploaded an NMU to DELAYED/10 with the following changes: diff -Nru ypserv-4.2/debian/changelog ypserv-4.2/debian/changelog --- ypserv-4.2/debian/changelog 2022-08-04 08:39:48.0 -0700 +++ ypserv-4.2/debian/changelog 2023-12-06 13:56:54.0 -0800 @@ -1,3 +1,10 @@ +ypserv (4.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Pass BASH variable to configure. (Closes: #983138) + + -- Vagrant Cascadian Wed, 06 Dec 2023 13:56:54 -0800 + ypserv (4.2-1) unstable; urgency=medium * New upstream version. diff -Nru ypserv-4.2/debian/rules ypserv-4.2/debian/rules --- ypserv-4.2/debian/rules 2022-08-04 08:39:48.0 -0700 +++ ypserv-4.2/debian/rules 2023-12-06 13:56:54.0 -0800 @@ -28,7 +28,8 @@ dh $@ override_dh_auto_configure: - dh_auto_configure + # Ensure BASH variable consistently is /bin/bash + dh_auto_configure -- BASH=/bin/bash for f in `find $(CURDIR) -name '*.8.xml'`; \ do d=`dirname $$f`; n=`basename $$f .xml`; [ -f $(CURDIR)/$$d/$$n ] || cp -f $(CURDIR)/debian/man/$$n $$d/.; done live well, vagrant signature.asc Description: PGP signature
Bug#1024286: lcm: reproducible-builds: Embedded build path and usrmerge paths in Makefile
Control: notfixed 1024286 1.3.1+repack1-6
On 2022-11-16, Vagrant Cascadian wrote:
> The build path and binary paths are embedded in
> /usr/share/doc/lcm-doc/examples/Makefile:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/lcm.html
>
> ACLOCAL·=·${SHELL}·'/build/1st/lcm-1.3.1+repack1/missing'·aclocal-1.16
> vs.
> ACLOCAL·=·${SHELL}·'/build/2/lcm-1.3.1+repack1/2nd/missing'·aclocal-1.16
>
> EGREP·=·/bin/grep·-E
> vs.
> EGREP·=·/usr/bin/grep·-E
>
> The attached patch fixes this by removing the example Makefile, which
> would have to be regenerated anyways to match the system to run it on.
... but the switch to debhelper-compat 13 moved the location of the
shipped Makefile, and was not actually removed in debian/rules... fixed
upload incoming...
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1052309: NMU fixing FTBFS, cross-building and reproducible builds bugs
I've uploaded an NMU fixing several cross building and reproducible
builds bugs and an RC bug to DELAYED/10. The changes should also be
available via dgit.
debdiff follows:
diff -Nru lirc-0.10.1/debian/changelog lirc-0.10.1/debian/changelog
--- lirc-0.10.1/debian/changelog2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/changelog2023-12-05 15:52:45.0 -0800
@@ -1,3 +1,28 @@
+lirc (0.10.1-7.3) unstable; urgency=medium
+
+ [ Vagrant Cascadian ]
+ * Non-maintainer upload.
+ * tools: Do not embed build date and kernel version in various files.
+(Closes: #979019)
+ * debian/rules: Run build in the C.UTF-8 locale. (Closes: #979023)
+
+ [ Helmut Grohne ]
+ * Build verbosely by default. (Closes: #988907)
+
+ [ Vagrant Cascadian ]
+ * debian/rules: Normalize shipped tarball of python source code.
+(Closes: #979024)
+
+ [ Helmut Grohne ]
+ * Fix FTBFS when systemdsystemunitdir changes in systemd.pc.
+(Closes: #1052309)
+ * Fix build vs host confusion. (Closes: #1052309)
+ * Check for /dev/input using AC_CHECK_FILE. (Closes: #989304)
+ * Multiarchify python Build-Depends. (Closes: #989304)
+ * Export _PYTHON_SYSCONFIGDATA_NAME for setup.py. (Closes: #989304)
+
+ -- Vagrant Cascadian Tue, 05 Dec 2023
15:52:45 -0800
+
lirc (0.10.1-7.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru lirc-0.10.1/debian/control lirc-0.10.1/debian/control
--- lirc-0.10.1/debian/control 2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/control 2023-12-05 15:52:45.0 -0800
@@ -18,6 +18,7 @@
kmod [linux-any],
libasound2-dev [linux-any kfreebsd-any],
libftdi1-dev,
+ libpython3-dev (>= 3.5),
libsystemd-dev [linux-any],
libudev-dev [linux-any],
libusb-1.0-0-dev [!kfreebsd-any],
@@ -26,9 +27,9 @@
man2html-base,
pkg-config,
portaudio19-dev,
- python3-dev (>= 3.5),
+ python3-dev:any (>= 3.5),
python3-setuptools,
- python3-yaml,
+ python3-yaml:native,
socat [!hurd-any],
systemd [linux-any],
xsltproc
diff -Nru lirc-0.10.1/debian/install lirc-0.10.1/debian/install
--- lirc-0.10.1/debian/install 2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/install 2023-12-05 15:52:45.0 -0800
@@ -1,7 +1,7 @@
#! /usr/bin/dh-exec
etc/lirc
-[linux-any] lib/systemd/*
+[linux-any] ${systemdsystemunitdir}
[linux-any] usr/lib/tmpfiles.d/*
[linux-any] usr/bin/lirc-make-devinput
[linux-any] usr/bin/irpipe
diff -Nru
lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch
lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch
--- lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch
1969-12-31 16:00:00.0 -0800
+++ lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch
2023-12-05 15:52:45.0 -0800
@@ -0,0 +1,44 @@
+From: Helmut Grohne
+Date: Mon, 31 May 2021 13:09:56 +0200
+X-Dgit-Generated: 0.10.1-7.3 54cb42673c340f60f85764753d13da093aad4baf
+Subject: Check for /dev/input using AC_CHECK_FILE.
+
+(Closes: #989304)
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 1d910b0..66f96aa 100644
+--- a/configure.ac
b/configure.ac
+@@ -289,29 +289,12 @@ else
+ fi
+
+ AC_MSG_CHECKING(for devinput)
+-AC_RUN_IFELSE([AC_LANG_PROGRAM([[
+- #include
+-]],[[
+- return access("/dev/input", R_OK) == 0 ? 0 : 1;
+-]])],[
++AC_CHECK_FILE([/dev/input],[
+ have_devinput="yes"
+ AC_MSG_RESULT(yes)
+ ],[
+ AC_MSG_RESULT(no)
+ have_devinput="no"
+-],[
+- AS_IF([test x$DEVINPUT_HEADER = x -a x$enable_devinput = xyes], [
+-AC_MSG_ERROR([
+- cannot cross-compile with devinput without DEVINPUT_HEADER
+- defined, giving up
+-])
+- ])
+- if test -n "$DEVINPUT_HEADER" ; then
+-have_devinput="yes"
+- else
+-have_devinput="no"
+- fi
+- AC_MSG_RESULT(yes)
+ ])
+
+
diff -Nru lirc-0.10.1/debian/patches/series lirc-0.10.1/debian/patches/series
--- lirc-0.10.1/debian/patches/series 2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/patches/series 2023-12-05 15:52:45.0 -0800
@@ -9,3 +9,5 @@
0009-Replace-the-obsolete-get_event_loop-with-get_running.patch
0010-Patch-configure.ac-to-support-passing-MODINFO.patch
0011-yaml.load.diff
+tools-do-not-embed-build-date-and-kernel.patch
+check-for-devinput-using-ac_check_file.patch
diff -Nru
lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch
lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch
--- lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch
1969-12-31 16:00:00.0 -0800
+++ lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch
2023-12-05 15:52:45.0 -0800
@@ -0,0 +1,59 @@
+From: Vagrant Cascadian
+Date: Sat, 2 Jan 2021 00:01:20 +
+X-Dgit-Generated: 0.10.1-7.3 1f430917c5ab786478d575d9714dd4e19defd8e1
+Subject: tools: Do not embed build date and kernel version in variou
Bug#977177: mm-common: reproducible builds: Generated tarball includes user, group and file mode
On 2023-11-29, Vagrant Cascadian wrote: > On 2020-12-12, Simon McVittie wrote: >> On Fri, 11 Dec 2020 at 20:45:09 -0800, Vagrant Cascadian wrote: > With the patch, I managed to produce a bit-for-bit identical > skeletonmm.tar.xz with the patch applied, both in a test environment > where the umask was varied, and with a fairly "normal" umask which was > bit-for-bit identical to the skeletonmm.tar.xz in the mm-common package > in the Debian archive. So it should not cause regressions! > > With this patch applied, mm-common should become reproducible on > tests.reproducible-builds.org infrastructure! > > Would an upload including this patch be considered soon, or would the > maintainers be open to an NMU in the near future? Uploaded to DELAYED/10 using dgit, debdiff follows: diff -Nru mm-common-1.0.5/debian/changelog mm-common-1.0.5/debian/changelog --- mm-common-1.0.5/debian/changelog2022-12-15 12:25:29.0 -0800 +++ mm-common-1.0.5/debian/changelog2023-12-05 15:03:37.0 -0800 @@ -1,3 +1,14 @@ +mm-common (1.0.5-1.1) unstable; urgency=medium + + [ Vagrant Cascadian ] + * Non-maintainer upload. + + [ Simon McVittie ] + * util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files in +the generated tarball. (Closes: #977177) + + -- Vagrant Cascadian Tue, 05 Dec 2023 15:03:37 -0800 + mm-common (1.0.5-1) unstable; urgency=medium [ Jeremy Bicha ] diff -Nru mm-common-1.0.5/debian/patches/series mm-common-1.0.5/debian/patches/series --- mm-common-1.0.5/debian/patches/series 2022-12-15 12:25:29.0 -0800 +++ mm-common-1.0.5/debian/patches/series 2023-12-05 15:03:37.0 -0800 @@ -0,0 +1 @@ +utilmeson_auxskeletonmm-tarball.py-use-c.patch diff -Nru mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch --- mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch 1969-12-31 16:00:00.0 -0800 +++ mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch 2023-12-05 15:03:37.0 -0800 @@ -0,0 +1,34 @@ +From: Simon McVittie +Date: Tue, 28 Nov 2023 16:57:13 -0800 +X-Dgit-Generated: 1.0.5-1.1 77d8a907867d87eb56f57cfd5d3226aba19355d8 +Subject: util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files in + +the generated tarball. (Closes: #977177) + +Signed-off-by: Vagrant Cascadian + +--- + +diff --git a/util/meson_aux/skeletonmm-tarball.py b/util/meson_aux/skeletonmm-tarball.py +index 138184c..a87590e 100755 +--- a/util/meson_aux/skeletonmm-tarball.py b/util/meson_aux/skeletonmm-tarball.py +@@ -10,6 +10,7 @@ import os + import sys + import shutil + import tarfile ++import stat + + if sys.argv[1] == 'check': + # Called from run_command() during setup or configuration. +@@ -42,6 +43,10 @@ else: + def reset(tarinfo): + tarinfo.uid = tarinfo.gid = 0 + tarinfo.uname = tarinfo.gname = "root" ++if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0: ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755 ++else: ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644 + return tarinfo + + live well, vagrant signature.asc Description: PGP signature
Bug#860470: libccrtp: please make the build reproducible
On 2023-11-28, Vagrant Cascadian wrote: > On 2017-04-17, Chris Lamb wrote: >> This is due to it capturing the buildpath in some automatically >> generated documentation. It appears safe to simply delete the manpages >> in question as they are a) private APIs and b) kinda terse/useless >> anyway. > ... >> --- a/debian/rules 2017-04-17 13:16:14.337050334 +0100 >> --- b/debian/rules 2017-04-17 13:38:53.662578698 +0100 >> @@ -15,3 +15,7 @@ >> override_dh_clean: >> rm -f doc/latex/* doc/html/* doc/man/man3/* doc/doxy >> dh_clean >> + >> +override_dh_installman: >> +dh_installman >> +rm -rf debian/libccrtp-doc/usr/share/man/man2 > > It seems exactly which directory these files are placed in is > non-deterministic; updated patch attached. > > For example, libccrtp-doc_2.0.9-2.3_all.deb currently in the archive > contains these files: > > > usr/share/man/man9/_build_libccrtp-eppWJD_libccrtp-2.0.9_src_ccrtp_.9_src_ccrtp_.3.gz > usr/share/man/man9/_build_libccrtp-eppWJD_libccrtp-2.0.9_src_.9_src_.3.gz > > I intend to NMU this package in the near future to fix this issue if I > do not hear otherwise. I have uploaded an NMU to DELAYED/10, using dgit so you can get the diff from there, or the following debdiff: diff -Nru libccrtp-2.0.9/debian/changelog libccrtp-2.0.9/debian/changelog --- libccrtp-2.0.9/debian/changelog 2018-10-27 02:46:51.0 -0700 +++ libccrtp-2.0.9/debian/changelog 2023-12-05 14:11:43.0 -0800 @@ -1,3 +1,11 @@ +libccrtp (2.0.9-2.4) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Remove low-content manpages with filenames based on +build path. (Closes: #860470) + + -- Vagrant Cascadian Tue, 05 Dec 2023 14:11:43 -0800 + libccrtp (2.0.9-2.3) unstable; urgency=low * Non-maintainer upload. diff -Nru libccrtp-2.0.9/debian/rules libccrtp-2.0.9/debian/rules --- libccrtp-2.0.9/debian/rules 2015-08-31 06:53:06.0 -0700 +++ libccrtp-2.0.9/debian/rules 2023-12-05 14:11:43.0 -0800 @@ -15,3 +15,9 @@ override_dh_clean: rm -f doc/latex/* doc/html/* doc/man/man3/* doc/doxy dh_clean + +override_dh_installman: + dh_installman + # Remove files with low content and filenames based on the build path. + # https://bugs.debian.org/860470 + rm -vf debian/libccrtp-doc/usr/share/man/man*/_* live well, vagrant signature.asc Description: PGP signature
Bug#995809: libinput: please make the build reproducible
On 2021-10-06, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> libinput could not be built reproducibly.
>
> This is due to the use of the LIBINPUT_QUIRKS_DIR macro which includes
> the absolute build path.
>
> It is not entirely clear (during a very brief look) when/where this
> value is even used — the testsuite still passes even if this is set to
> a dummy value (see attached dummy patch). And, of course, the build
> path cannot be relied upon at runtime.
The attached patch is an alternate approach by removing the code that
actually references the build path from various source files. It also
makes the build reproducible and the package still builds (so I presume
the test suite passes).
As Chris pointed out, the build path is not something one can rely on at
runtime, so the installed package cannot rely on it anyways.
I would like to perform an NMU in the near future, unless there are
objections?
live well,
vagrant
From 6b78d6697661c497ae4ff2a3bbf1eea53ae60ccc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 1 Dec 2023 14:17:20 -0800
Subject: [PATCH] tools: Remove references to LIBINPUT_QUIRKS_SRCDIR. (Closes:
#995809)
This embeds the build path which is not generally available at runtime and
makes it more difficult to reproduce the build.
https://reproducible-builds.org/docs/build-path/
---
tools/libinput-quirks.c | 10 ++
tools/libinput-record.c | 9 -
tools/shared.c | 12
3 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/tools/libinput-quirks.c b/tools/libinput-quirks.c
index e97eff6..7f3e26f 100644
--- a/tools/libinput-quirks.c
+++ b/tools/libinput-quirks.c
@@ -166,14 +166,8 @@ main(int argc, char **argv)
/* Overriding the data dir means no custom override file */
if (!data_path) {
- char *builddir = builddir_lookup();
- if (builddir) {
- data_path = LIBINPUT_QUIRKS_SRCDIR;
- free(builddir);
- } else {
- data_path = LIBINPUT_QUIRKS_DIR;
- override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
- }
+ data_path = LIBINPUT_QUIRKS_DIR;
+ override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
}
quirks = quirks_init_subsystem(data_path,
diff --git a/tools/libinput-record.c b/tools/libinput-record.c
index 30b2900..1de63bc 100644
--- a/tools/libinput-record.c
+++ b/tools/libinput-record.c
@@ -1762,19 +1762,10 @@ print_device_quirks(struct record_device *dev)
struct quirks_context *quirks;
const char *data_path = LIBINPUT_QUIRKS_DIR;
const char *override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
- char *builddir = NULL;
if (stat(dev->devnode, ) < 0)
return;
- if ((builddir = builddir_lookup())) {
- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
- data_path = LIBINPUT_QUIRKS_SRCDIR;
- override_file = NULL;
- }
-
- free(builddir);
-
quirks = quirks_init_subsystem(data_path,
override_file,
quirks_log_handler,
diff --git a/tools/shared.c b/tools/shared.c
index 7a73027..fcacb03 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -411,16 +411,6 @@ tools_open_device(const char **paths, bool verbose, bool *grab)
return li;
}
-static void
-tools_setenv_quirks_dir(void)
-{
- char *builddir = builddir_lookup();
- if (builddir) {
- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
- free(builddir);
- }
-}
-
struct libinput *
tools_open_backend(enum tools_backend which,
const char **seat_or_device,
@@ -429,8 +419,6 @@ tools_open_backend(enum tools_backend which,
{
struct libinput *li;
- tools_setenv_quirks_dir();
-
switch (which) {
case BACKEND_UDEV:
li = tools_open_udev(seat_or_device[0], verbose, grab);
--
2.39.2
signature.asc
Description: PGP signature
Bug#983852: python-scrapy: please make the build reproducible
On 2021-03-02, Chris Lamb wrote: > Whilst working on the Reproducible Builds effort [0] we noticed that > python-scrapy could not be built reproducibly. > > This is because it uses the current build year when building the > documentation which, of course, changes depending which year you > build the software. > > Patch attached that uses SOURCE_DATE_EPOCH [1] instead. In the upstream pull request: https://github.com/scrapy/scrapy/pull/5019 It was suggested drop the practice of using the build year at all and manually updating the year... though upstream did not go so far as to actually do that as far as I can tell. Perhaps a really simple patch with the most recent copyright year hard-coded that needs to be updated alongside debian/copyright would be acceptible? It could also check to make sure the most recent year mentioned in debian/copyright matches the patch year, if you really wanted to make sure they stayed in sync. Alternately, going with the SOURCE_DATE_EPOCH patch for now until upstream decides how to fix it? live well, vagrant signature.asc Description: PGP signature
Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so
On 2021-07-09, Vagrant Cascadian wrote:
> From 88b66063c5f02ba48f2fc9cfa2ae6cc42c950cc8 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian
> Date: Fri, 9 Jul 2021 15:13:24 +
> Subject: [PATCH] Use the build date from SOURCE_DATE_EPOCH if set, falling
> back to current time.
>
> https://reproducible-builds.org/docs/source-date-epoch/
> ---
> Makefile | 2 +-
> buildflags.mak | 8
> ipath/Makefile | 2 +-
> 3 files changed, 10 insertions(+), 2 deletions(-)
I would like to propose an NMU with this patch applied in the near
future. Please let me know if there are objections.
live well,
vagrant
> diff --git a/Makefile b/Makefile
> index d79c4bd..64d6f6b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -270,7 +270,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
> # file around. Generate it such that the ident command can find it
> # and strings -a | grep InfiniPath does a reasonable job as well.
> ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
> - date +'char psmi_infinipath_revision[] ="$$""Date: %F %R
> ${rpm_extra_description}InfiniPath $$";' > ${lib_build_dir}/_revision.c
> + printf 'char psmi_infinipath_revision[] ="$$""Date: %s
> ${rpm_extra_description} InfiniPath $$";\n' "$(BUILD_DATE)" >
> ${lib_build_dir}/_revision.c
> $(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
> $(CC) $(LDFLAGS) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared
> -Wl,--unique='*fastpath*' \
> ${${TARGLIB}-objs} _revision.o -L$(build_dir)/ipath $(LDLIBS)
> diff --git a/buildflags.mak b/buildflags.mak
> index 34fdf1c..be40c40 100644
> --- a/buildflags.mak
> +++ b/buildflags.mak
> @@ -96,3 +96,11 @@ endif
> CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
> $(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
>
> +# Use SOURCE_DATE_EPOCH for build date, falling back to current time
> +# https://reproducible-builds.org/docs/source-date-epoch/
> +DATE_FMT="+'%F %R'"
> +ifdef SOURCE_DATE_EPOCH
> +BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
> 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null ||
> date -u "$(DATE_FMT)")
> +else
> +BUILD_DATE ?= $(shell date "$(DATE_FMT)")
> +endif
> diff --git a/ipath/Makefile b/ipath/Makefile
> index 8c2cc6e..e627b3d 100644
> --- a/ipath/Makefile
> +++ b/ipath/Makefile
> @@ -70,7 +70,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
> # file around. Generate it such that the ident command can find it
> # and strings -a | grep InfiniPath does a reasonable job as well.
> ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
> - date +'static __attribute__ ((unused)) char __psc_infinipath_revision[]
> ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > _revision.c
> + printf 'static __attribute__ ((unused)) char
> __psc_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description}InfiniPath
> $$";\n' "$(BUILD_DATE)" > _revision.c
> $(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
> $(CC) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared \
> -Wl,--unique='*fastpath*' \
> --
> 2.32.0
signature.asc
Description: PGP signature
Bug#751341: Acknowledgement (debian/control missing VCS tags)
Control: tags 751341 - patch On 2014-06-11, Hans-Christoph Steiner wrote: > diff --git a/debian/control b/debian/control > index 60be58a..11c718a 100644 > --- a/debian/control > +++ b/debian/control > @@ -4,6 +4,8 @@ Priority: optional > Maintainer: Bastian Blank > Build-Depends: debhelper (>> 7), libdebian-installer4-dev (>= 0.81~), > libdebconfclient0-dev (>= 0.40), autotools-dev, libbz2-dev, liblzma-dev, > zlib1g-dev > Standards-Version: 3.9.0 > +Vcs-Git: git://git.debian.org/users/waldi/cdebootstrap.git > +Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/waldi/cdebootstrap.git > > Package: cdebootstrap > Architecture: any While cdeboostrap still lacks Vcs-* headers, git.debian.org and anonscm.debian.org no longer exist in the nine or so years that this bug has gone unresolved... the patch no longer contains relevent information. :( live well, vagrant signature.asc Description: PGP signature
Bug#983138: ypserv: /bin/sh symlink triggers differences in pwupdate
Control: retitle 983138 ypserv: /bin/sh symlink triggers differences in pwupdate On 2022-08-05, Vagrant Cascadian wrote: > On 2022-08-05, Vagrant Cascadian wrote: >> On 2022-08-05, Francesco P. Lovergine wrote: >>> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote: >>>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote: >>>>> The configure script sets the BASH variable to /bin/sh when run on a >>>>> usrmerge system, resulting in the pwupdate script differing between >>>>> builds: >>>>> >>>>> >>>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html >>>>> >>>>> ./usr/lib/yp/pwupdate >>>>> >>>>> #!/bin/bash >>>>> vs. >>>>> #!/bin/sh ... >>>>Regardless of whether this is RC or not, it would be great to have it fixed >>>>for Debian 12. Vagrant's patch looks appropriate. >>>> >>>>Thanks, >>>>smcv >>> >>> The patch looks good enough to fix the pwupdate generation. In any case, the >>> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks >>> indifferent. >> >> Given that it's the BASH variable, I figured using /bin/bash would make >> more sense and allow consistent builds. ... > From some local testing, this doesn't actually appear to be a usrmerge > issue, but a /bin/sh -> /bin/bash vs. /bin/sh -> /bin/dash issue. Updated bug title accordingly. > I'm not sure why the reproducible builds infrastructure doesn't catch > this, will look into it... Apparently we had some misconfiguration that did not catch this, but it is fixed now, and ypserv is again showing as unreproducible due to this issue: https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/ypserv.html > Regardless, the patch would make the package build reproducibly, and > would be great to apply. I would like to perform an NMU fixing this in the near future, barring any strong objections. Apparently either BASH=/bin/sh or BASH=/bin/bash work, though the current shipped package uses /bin/bash in /usr/lib/yp/pwupdate, so my proposed patch to pass BASH=/bin/bash would result in the same behavior as currently in the archive. live well, vagrant signature.asc Description: PGP signature
Bug#979024: lirc: reproducible builds: ships tarball of python sources
On 2021-01-01, Vagrant Cascadian wrote: > The lirc package ships a /usr/share/lirc/lirc-VERSION.tar.gz tarball. > > This tarball contains timestamps produced during the build, can be > affected by the umask of the build environment. > > > https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/lirc.html > > /usr/share/lirc/lirc-0.10.1.tar.gz > > > -rw-r--r--···0·root···(0)·root···(0)··1667·2017-09-10·08:52:19.00·lirc-0.10.1/README.rst > vs. > > -rw-rw-r--···0·root···(0)·root···(0)··1667·2017-09-10·08:52:19.00·lirc-0.10.1/README.rst > > > I do not know enough about lirc to know if this tarball needed to be > shipped in the package, or could they be shipped as files in the > filesystem instead? > > > If it is ok to remove the tarball entirely, the attached patch fixes > these issues by removing the tarball from debian/rules. The attached patch instead normalizes the timestamps, umask and user/group information rather than deleting the tarball. I would like to upload an NMU to fix this in the near future, as well as the proposed fixes for: #988907 lirc should build verbosely by default #979023 lirc: reproducible builds: File contents may vary depending on locale #979019 lirc: reproducible builds: Embeds timestamps and kernel version in various files live well, vagrant From cc118d68518f93f6c3918b56a6c90e0b8ffefc55 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Wed, 29 Nov 2023 16:42:57 -0800 Subject: [PATCH 4/4] debian/rules: Normalize shipped tarball of python source code. (Closes: #979024) The tarball includes timestamps and various other things that may vary between builds. https://reproducible-builds.org/docs/archives/ --- debian/rules | 13 + 1 file changed, 13 insertions(+) diff --git a/debian/rules b/debian/rules index cb7b70a..4bad31b 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,7 @@ #!/usr/bin/make -f include /usr/share/dpkg/architecture.mk +include /usr/share/dpkg/pkg-info.mk export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed @@ -77,6 +78,18 @@ endif override_dh_install: dh_install --fail-missing + # Normalize python tarball + tar --extract --file debian/lirc/usr/share/lirc/lirc-$(DEB_VERSION_UPSTREAM).tar.gz + rm -v debian/lirc/usr/share/lirc/lirc-$(DEB_VERSION_UPSTREAM).tar.gz + tar --sort=name \ + --mtime="@$(SOURCE_DATE_EPOCH)" \ + --owner=0 --group=0 --numeric-owner \ + --mode=u=rwX,go=rX \ + --create \ + --file debian/lirc/usr/share/lirc/lirc-$(DEB_VERSION_UPSTREAM).tar \ + lirc-$(DEB_VERSION_UPSTREAM) + gzip --best --no-name debian/lirc/usr/share/lirc/lirc-$(DEB_VERSION_UPSTREAM).tar + rm -rvf lirc-$(DEB_VERSION_UPSTREAM) override_dh_installinit: dh_installinit --package=lirc --name=lircd -- 2.39.2 signature.asc Description: PGP signature
Bug#977177: mm-common: reproducible builds: Generated tarball includes user, group and file mode
On 2020-12-12, Simon McVittie wrote: > On Fri, 11 Dec 2020 at 20:45:09 -0800, Vagrant Cascadian wrote: >> If anyone has a better handle on python's tarfile mode handling code, it >> might be worth taking a closer look. I'm not entirely sure how the file >> modes work in this code (they don't appear to use modes similar to those >> used by umask, chmod or python's file functions) > > It looks like they're encoded in the same way as st_mode in a struct > stat_buf: the low bits are Unix permissions (which start making sense > if you print them in octal) and the high bits are file type. See the > documentation for the stat Python module, and in particular stat.S_IMODE > and stat.S_IFMT. > > I think the correct normalization would be something like this (untested!): > > if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0: > tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755 > else: > tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644 > > (that's the same as chmod a+rX,og-w). Upstream has since fixed the user/uid/group/gid issues, but the umask issues still remain. Updated patch attached based on Simon McVittie's suggestion (only adding "import stat"). With the patch, I managed to produce a bit-for-bit identical skeletonmm.tar.xz with the patch applied, both in a test environment where the umask was varied, and with a fairly "normal" umask which was bit-for-bit identical to the skeletonmm.tar.xz in the mm-common package in the Debian archive. So it should not cause regressions! With this patch applied, mm-common should become reproducible on tests.reproducible-builds.org infrastructure! Would an upload including this patch be considered soon, or would the maintainers be open to an NMU in the near future? Thanks! live well, vagrant From 22b81b93905fa0c3a8516bd4feb612110f0965f8 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 28 Nov 2023 16:57:13 -0800 Subject: [PATCH] util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files in the generated tarball. Signed-off-by: Vagrant Cascadian --- util/meson_aux/skeletonmm-tarball.py | 5 + 1 file changed, 5 insertions(+) diff --git a/util/meson_aux/skeletonmm-tarball.py b/util/meson_aux/skeletonmm-tarball.py index 138184c..a87590e 100755 --- a/util/meson_aux/skeletonmm-tarball.py +++ b/util/meson_aux/skeletonmm-tarball.py @@ -10,6 +10,7 @@ import os import sys import shutil import tarfile +import stat if sys.argv[1] == 'check': # Called from run_command() during setup or configuration. @@ -42,6 +43,10 @@ else: def reset(tarinfo): tarinfo.uid = tarinfo.gid = 0 tarinfo.uname = tarinfo.gname = "root" +if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0: +tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755 +else: +tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644 return tarinfo -- 2.39.2 signature.asc Description: PGP signature
Bug#860470: libccrtp: please make the build reproducible
On 2017-04-17, Chris Lamb wrote: > This is due to it capturing the buildpath in some automatically > generated documentation. It appears safe to simply delete the manpages > in question as they are a) private APIs and b) kinda terse/useless > anyway. ... > --- a/debian/rules2017-04-17 13:16:14.337050334 +0100 > --- b/debian/rules2017-04-17 13:38:53.662578698 +0100 > @@ -15,3 +15,7 @@ > override_dh_clean: > rm -f doc/latex/* doc/html/* doc/man/man3/* doc/doxy > dh_clean > + > +override_dh_installman: > + dh_installman > + rm -rf debian/libccrtp-doc/usr/share/man/man2 It seems exactly which directory these files are placed in is non-deterministic; updated patch attached. For example, libccrtp-doc_2.0.9-2.3_all.deb currently in the archive contains these files: usr/share/man/man9/_build_libccrtp-eppWJD_libccrtp-2.0.9_src_ccrtp_.9_src_ccrtp_.3.gz usr/share/man/man9/_build_libccrtp-eppWJD_libccrtp-2.0.9_src_.9_src_.3.gz I intend to NMU this package in the near future to fix this issue if I do not hear otherwise. live well, vagrant From ffa35c9ca2ac9dcc0c78b7d604011a2faee25db0 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 28 Nov 2023 15:31:58 -0800 Subject: [PATCH] debian/rules: Remove low-content manpages with filenames based on build path. (Closes: #860470) Some manpage names are generated based on the build path, e.g. the package built in the directory /build/libccrtp-eppWJD/libccrtp-2.0.9 produces the manpage filename "_build_libccrtp-eppWJD_libccrtp-2.0.9_src_.9_src_.3.gz". These manpages have very little meaningful content, so remove them. --- debian/rules | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/rules b/debian/rules index 5b7fd06..4622347 100755 --- a/debian/rules +++ b/debian/rules @@ -15,3 +15,9 @@ override_dh_install: override_dh_clean: rm -f doc/latex/* doc/html/* doc/man/man3/* doc/doxy dh_clean + +override_dh_installman: + dh_installman + # Remove files with low content and filenames based on the build path. + # https://bugs.debian.org/860470 + rm -vf debian/libccrtp-doc/usr/share/man/man*/_* -- 2.39.2 signature.asc Description: PGP signature
Bug#979688: Simplifying the list of image files for arm64 sunxi boards
On 2023-11-28, harr...@gmx.ph wrote: > On 27/11/2023 20:12, Vagrant Cascadian (@vagrant) wrote on salsa: >>Thanks! Looks good to me, could you add (Closes: #XXX) on the first line of >>the commit? ... > Thanks for agreeing to the merge request. I've added the Closes: note. Thanks! > I just wanted to note while the bug is still open, that I was originally > aiming to simplify the list of files for each arm64 sunxi board in targets.mk, > and from my point of view u-boot-sunxi-with-spl.bin is the only one still > needed. Understood. > I know that you said earlier (on 25/07/2023 17:39 in the bug report): > >> I am also a bit inclined to adding u-boot-sunxi-with-spl.bin rather than >> replacing all the other parts, as there are some use-cases (e.g. an >> image capable of booting both sunxi and rockchip systems at different >> offsets) where the individual parts are still needed. > > but I'm not sure that's right, because I believe sunxi-spl.bin and > u-boot-sunxi-with-spl.fit.itb always need to be concatenated to work, > because the SPL is hard-coded to look for U-Boot proper immediately after > itself, as determined by spl_mmc_get_uboot_raw_sector() in > arch/arm/mach-sunxi/board.c. So I think any "One image to rule them all" > that arranged the parts differently would need a custom build, not the > files currently in the Debian u-boot binary packages. I had managed to successfully build a bootable image doing it "the old way" that worked on both pinebook (allwinner A64) and pinebook pro (rockchip rk3399) at "alternate offsets" that required no changes to the u-boot binaries... but that was with older versions. I would hate to break that ability, although it would be reasonable to test it sometime to make sure it still works! In the meantime, I would like to leave the builds shipping more than strictly necessary for booting each board. > That said, I'm happy to see u-boot-sunxi-with-spl.bin included, so thank you > very much for doing that and all the other things that came up in this > sprawling bug report. Likewise! live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2023-11-23, Andreas Henriksson wrote: > I'm opening this bug report to discuss the potential of building another > u-boot variant in a new binary package from src:u-boot for "Apple > Silicon" machines. Thanks! I am guessing this class of hardware may represent a much larger community than many other boards already supported in u-boot. > # The overall picture of booting Linux on apple silicon > > A normal users boot procedure would look something like: > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) > -> generic distro EFI boot managers (grub, systemd-boot, etc) > > > m1n1 stage1 is installed by the Asahi Linux installer. > m1n1 stage2 + u-boot + dtbs are bundled together and installed > as boot.bin on the EFI partition. From u-boot 2023.10 doc/board/apple/m1.rst: $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho So, this suggests to me one has to pick exactly which .dtb to use which is presumably device-specific? Or is there some other process? I am guessing we would not be able to provide all the possible "u-boot.macho" permutations out of the box (unless it is a very small number of variants), but can probably ship all the relevent components as long as they are in debian main. If the .dtb files come from somewhere other than debian main, we would probably have to build it as a contrib package. > m1n1 stage2 is already in debian, see: > https://tracker.debian.org/m1n1 Great! > I've looked over the 43 patches and here's my *perception* > of the current status: > > The current upstream apple_m1_defconfig should be usable > for booting (from internal storage) on M1 machines. > > The M2 can possibly boot, but keyboard driver is not yet > upstream - so no interaction with u-boot possible. Ok, so worst case, there is at least one supported working platform even without patches? > Some of the patches updates devicetree files (dts) which are > completely apple-specific and should not have any chance to affect > anything else, but these are also completely unused so does not > neccessarily need to be included. > The asahi tools to update the EFI boot.bin that combines m1n1, > u-boot and dtbs uses the dtbs from the installed kernel, see: > https://tracker.debian.org/asahi-fwextract > https://tracker.debian.org/asahi-scripts Here is the crux of the question ... can it use the .dtb files from debian main or does it need .dtb files from some sources outside of debian? > # considerations > > 1/ are we willing to add another binary package to src:u-boot >building apple_m1_defconfig? I think that makes sense. > 2/ should we name the binary package u-boot-apple or -asahi? >The existing third-party packages of the asahi fork calls >theirs u-boot-asahi. I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the sunxi community port of allwinner hardware), but with src:u-boot-asashi already in NEW, that makes it a more confusing situation. > 3/ do we include patches? > 3.1/ No patches. If this is the desired path I can volunteer > to test that it boots on my M1 machine. Other machines > should probably be considered unsupported for now, > even though they might have limited usefulness. > 3.2/ Minimal set of patches. We identify what we consider > crutial only patches and recruit volunteers to test. > M2 keyboard? USB? etc... > 3.3/ All asahi patches. We consider it simpler to just sync all patches > with the asahi fork (even though some are even unused, like the > devicetree patches). We trust the Asahi Linux project in their > quest to upstream all their work and that they will rebase on newer > releases and make our job easy. I am inclined towards starting with no patches or a minimal set of patches. The asashi folks do seem to generally do a good job of upstreaming, so support should improve over time. I have been working on getting 2023.10 into unstable, and before too long 2024.01~rc variants should land in experimental, presumably with more upstreamed patches. > Debian has a bananas-team that can take responsibility for testing > and maintaining software, see: > https://wiki.debian.org/Teams/Bananas Glad to know! > Also worth noting is that the asahi fork of u-boot has been uploaded > and currently sitting in NEW as src:u-boot-asahi. > https://ftp-master.debian.org/new.html > As mentioned already on the ITP, I think it's excessive to duplicate all > of u-boot over 43 patches (and hopefully shrinking): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471 Yes, it does seem a shame to duplicate all of u-boot, although it really depends on how the upstreaming progress goes. I can personally tell you reviewing the copyright and licesning information for a project with 2+ files is... arduous. And it would be somewhat ridiculous to do that twice. live well, vagrant signature.asc Description: PGP signature
Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10
On 2023-10-02, Heinrich Schuchardt wrote:
> U-Boot v2023.10 has been released. It provides sufficient support for
> the StarFive Visionfive 2 board.
Thanks!
> I would suggest to package it as u-boot-starfive.
I will probably wait until u-boot 2023.10 lands in Debian before
uploading a new binary package that requires NEW review, but probably
not long after.
> 64fd30d367a1 ("tools: mkimage: Add StarFive SPL image support")
> 90602e779d3a ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
> ad4b1bc39eef ("configs: NVMe/USB target boot devices on VisionFive 2")
> 98d17450cd4b ("starfive: visionfive2: add mmc0 and nvme boot targets")
I presume the above commits have now landed in upstream u-boot git?
> [PATCH v2] i2c: designware_i2c: adjust timing calculation
> https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/
Did this land upstream yet?
Anything else needed?
live well,
vagrant
signature.asc
Description: PGP signature
Bug#1052724: u-boot: FTBFS: cc1: error: ‘-fcf-protection=full’ is not supported for this target
On 2023-09-26, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): ... >> cc1: error: ‘-fcf-protection=full’ is not supported for this target >> make[3]: *** [/<>/Makefile:1816: include/generated/env.in] >> Error 1 Because several of the qemu targets for the u-boot-qemu arch:all are cross-built, when dpkg-buildflags enabled the hardening=+branch feature by default, this broke some of the cross builds which do not support the resulting -fcf-protection=full feature added to the default compiler flags. I have disabled this feature in git for now, although a better fix might be preferred allowing this to be used on other targets where it did not cause an issue. live well, vagrant signature.asc Description: PGP signature
Bug#1055969: kuttypy: reproducible-builds: shell-dependent use of echo
Source: kuttypy Version: 2.1.1-2 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: shell X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Newlines are handled differently depending on which shell implementation is in use, resulting in differences dependent on the build environment: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/kuttypy.html /usr/share/kuttypy/utilities/build_details.py QT_VERSION·=·'PyQt5'\nPY_VERSION·=·3\n vs. QT_VERSION·=·'PyQt5' PY_VERSION·=·3 The attached patch fixes this in the upstream Makefile by making multiple echo calls rather than relying on the shell-dependent echo handling of "\n". With this patch applied to kutty 2.1.1-4, based on my local tests, kuttypy should build reproducibly on tests.reproducible-builds.org! Thanks for maintaining kuttypy! live well, vagrant From 25b7eeb2072424c31b21ceea5ae95d583faa5bcd Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 14 Nov 2023 15:34:37 -0800 Subject: [PATCH] Makefile: Split echo call into multiple lines to avoid shell-dependent handling of "\n". https://tests.reproducible-builds.org/debian/issues/unstable/bin_sh_is_bash_issue.html --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 68839f1..4927281 100644 --- a/Makefile +++ b/Makefile @@ -27,7 +27,8 @@ all: recursive_all recursive_all: @echo '?. Using QT Version:' $(QT_VERSION) $(PYUIC) $(PYRCC) $(PYLUPDATE) $(PY_VERSION) - @echo "QT_VERSION = '$(QT_VERSION)'\nPY_VERSION = $(PY_VERSION)\n" > utilities/build_details.py + @echo "QT_VERSION = '$(QT_VERSION)'" > utilities/build_details.py + @echo "PY_VERSION = $(PY_VERSION)" >> utilities/build_details.py for d in $(SUBDIRS); do $(MAKE) PYUIC=$(PYUIC) PYRCC=$(PYRCC) PYLUPDATE=$(PYLUPDATE) PY_VERSION=$(PY_VERSION) -C $$d all; done clean: recursive_clean -- 2.39.2 signature.asc Description: PGP signature
Bug#1029801: tbox: reproducible builds: timestamp embedded in tbox.config.h
Control: fixed 1029801 1.7.4-1
On 2023-10-26, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:tbox package:
>
> #1029801: tbox: reproducible builds: timestamp embedded in tbox.config.h
>
> It has been closed by Lin Qigang .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Lin Qigang
> by
> replying to this email.
>
>
> --
> 1029801: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029801
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Lin Qigang
> Subject: tbox: reproducible builds: timestamp embedded in tbox.config.h
> To: 1029801-d...@bugs.debian.org
> Date: Thu, 26 Oct 2023 19:53:53 +0700
>
> Thank you, this patch was applied upstream [1].
>
> [1] https://github.com/tboox/tbox/pull/219
>
> --
> Lance Lin
> GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7
> From: Vagrant Cascadian
> Subject: tbox: reproducible builds: timestamp embedded in tbox.config.h
> To: sub...@bugs.debian.org
> Date: Fri, 27 Jan 2023 14:57:29 -0800
>
> Source: tbox
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The build time is embedded in /usr/include/tbox/tbox.config.h:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tbox.html
>
> /usr/include/tbox/tbox.config.h
>
> #define·TB_CONFIG_VERSION_BUILD·20240228
> vs.
> #define·TB_CONFIG_VERSION_BUILD·20230127
>
> The attached patch to configure fixes this by calling date with
> arguments to ensure a deterministic timestamp, falling back to the
> default behavior.
>
> According to my local tests, with this patch applied, tbox should
> build reproducibly on tests.reproducible-builds.org!
>
> Thanks for maintaining tbox!
>
> live well,
> vagrant
> From 83994f9a353d7ebb0c61cf426aeaa033a5042a07 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian
> Date: Fri, 27 Jan 2023 22:42:17 +
> Subject: [PATCH] configure: Use determistic timestamp from SOURCE_DATE_EPOCH
> if available.
>
> This supports multiple date implementations, falling back to the
> current behavior on failure.
> ---
> configure | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index a0f42ae..9c9163a 100755
> --- a/configure
> +++ b/configure
> @@ -253,8 +253,10 @@ _os_find() {
> }
>
> # get date, "%Y%m%d%H%M" -> 20221207
> +# Use deterministic timestamp from SOURCE_DATE_EPOCH if available
> +# https://reproducible-builds.org/docs/source-date-epoch/
> _os_date() {
> -_ret=$(date +"${1}")
> +_ret=$(date -u -d "@$SOURCE_DATE_EPOCH" +"${1}" || date -u -r
> "$SOURCE_DATE_EPOCH" +"${1}" || date +"${1}")
> }
>
> # we avoid use `basename`, because it's slow
> --
> 2.39.1
Bug#1053814: extlinux.conf is not generated on initial installation
On 2023-10-11, Johannes Schauer Marin Rodrigues wrote: > installing u-boot-menu does not create /boot/extlinux/extlinux.conf. Is > there a reason for that? It gets triggered as expected when kernels get > installed or upgraded but the postinst does not contain a codepath that > gets triggered just on installation. So right now, after installing > u-boot-menu I have to manually run u-boot-update. I shouldn't have to do > that, right? I agree that it seems reasonable to expect it to run on package installation or upgrade, sure! It would be nice to avoid running it multiple times in a single apt run, e.g. upgrading the kernel and/or initramfs-tools and u-boot-menu at the same time... but it also is not hugely resource intensive to occasionally run it multiple times if that is too complicated to implement. That might end up causing any backup files to get obliterated, though. live well, vagrant signature.asc Description: PGP signature
Bug#1024851: Regression with 2022.10+dfsg-1 on Pinebook pro : broken keyboard
On 2023-10-11, Hubert Tonneau wrote: > Diederik de Haas wrote: >> Did the situation improve with version 2023.01 as released with Bookworm? ... > I upgraded the Pinebook pro to Debian Bookworm, and it means > u-boot-rockchip package version 2023.01+dfsg-2 (january 18 2023). Did you manually upgrade u-boot as well? Upgrading the package does not upgrade the installed bootloader. > The keyboard is still unreliable (if typing a lot, it will miss some > keystrokes and end repeating the same key forever), but it is usable > for a few keystrokes to select the expected boot menu item. I've experienced similar behavior on occasion still. It really is time to try and revert that patch, and see if things work at all. Last time I tried it broke USB keyboard entirely, but we are at least fairly early in the release cycle for debian trixie... There is also 2023.07 in sid and trixie, and 2023.04 you could pull from snapshots.debian.org... but I do not have high hopes for either. I will make sure to experiment with removing the patch before working on 2023.10, which was released a week or so ago... this keeps falling off my plate because it works well enough ... I will be using my pinebook pro more again as it moves towards winter solstice, as I have less available solar power... :) live well, vagrant signature.asc Description: PGP signature
Bug#1052257: diffoscope crashes(?) comparing some i386 debs (and others)
On 2023-09-27, Holger Levsen wrote: > On Wed, Sep 20, 2023 at 12:25:36PM +, Holger Levsen wrote: >> so I've powercycled the machine and also disabled the armhf workers now. >> (under the (weak) assumption that this bug is mostly trigged when running >> diffoscope on 32bit .debs...) Most frustrating! > so on Sep 23rd I made diffoscope run under ionice -n6, and so far the machine > has gone down on its knees yet. > > and on Sep 25th I said this on #debian-reproducible: > > when i made diffoscope run under ionice i was wondering if there were changes > in the linux > scheduler causing the probs we saw... now not seeing the machine go down to > its knees > within 60h uptime i'm saying this to "provoke" the problem coming back > however, looking at > jenkins.debian.net/munin/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph_name=debian.net/jenkins.debian.net/uptime_x=800_y=400_epoch=1661108749_epoch=1695668749 > I can that the highest uptime was 15 days.. > (since upgrading to bookworm which is when the probs started) > it could also be kernel related, with switching to bookworm > we switched from 5.10.0 to 6.1.0... > so my next stabs c/would be: > a.) increase swap > b.) upgrade to kernel 6.4.0 from bpo > c.) something else Maybe try using a bullseye 5.10.x kernel for a while? Obviously better if the issue is fixed in a newer kernel version ... but if 5.10.x consistently works with bookworm userspace that ever so slightly narrows down the issue? live well, vagrant signature.asc Description: PGP signature
Bug#1051732: apt: download content from unauthenticated repository if matching authenticated repository
Package: apt Version: 2.6.1 Severity: wishlist X-Debbugs-Cc: vagr...@reproducible-builds.org Thanks for maintaining apt! I use it all the time! No idea how difficult this would be to implement, but... It would be nice to be able to download content (e.g. .deb or .dsc) normally downloadable via apt from an unauthenticated repository if the checksums on the content match another repository that is authenticated. Something like in sources.list: deb [UnsignedContent=true] https://unauthenticated-mirror.net/debian sid main deb https://deb.debian.org/debian sid main And then something like: $ apt update Hit:1 https://unauthenticated-mirror.example.net/debian sid Release Note: Unsigned Content repository http://unauthenticated-mirror.example.net ... Hit:6 https://deb.debian.org/debian sid InRelease ... apt download bash Note: checksums for bash matched http://deb.debian.org/debian... Get:1 http://unauthenticated-mirror.example.net/debian sid/main amd64 bash amd64 5.2.15-2+b2 [1,491 kB] This would make it much easier to host partial mirrors or snapshots without needing to mess around with signing keys (both on the mirror side, and on the client side), by relying on the checksum information from a trusted signed repository. live well, vagrant signature.asc Description: PGP signature
