Bug#1051801: document DEB_BUILD_OPTIONS value nopgo

On 11/09/2023 09.25, Helmut Grohne wrote: It also is unclear how it affects reproducible builds since such builds depend on the performance characteristics of the system performing the build. It is worth noting that the performance (execution time) of a build-system does not matter for

Bug#969084: buildd.d.o: please don't use a tainted buildenv

> I think ideally > this would be using a system pathname and be part of a package that gets > then listed in the .buildinfo files. This is how openSUSE does it as well, e.g with https://github.com/openSUSE/post-build-checks/ and https://github.com/openSUSE/brp-check-suse/ that get pulled into

Bug#962021: forwarded upstream

https://gitlab.com/graphviz/graphviz/-/merge_requests/1454 was easy, because I had the forked repo still around

Bug#831587: merged upstream

https://github.com/stressapptest/stressapptest/pull/65 was merged yesterday

Bug#942767: submitted upstream

I submitted lamby's patch upstream at https://review.opendev.org/693327 I also tested it on our openSUSE package and found that it is only needed with python-oslo.reports 1.30, but not 1.29.2

Bug#940571: LTO/PGO and reproducible builds

LTO: ensure you have that gcc patch https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 There might be few other related patches that our (SUSE's) Martin Liska probably knows, but if you already have the -flto=auto, you probably got the others, too. PGO: > The only thing it would do is to

Bug#930351: linux-image-4.9.0-9-amd64: soft lockup / stuck in pid_revalidate

On 11/06/2019 22.28, Ben Hutchings wrote: > On Tue, 2019-06-11 at 10:13 +0200, Bernhard M. Wiedemann wrote: > [...] >> kernel:[1616241.072680] NMI watchdog: BUG: soft lockup - CPU#5 stuck for >> 22s! [ps:28525] >> >> [1626796.848128] CPU: 5 PID: 28525 Comm: ps Taint

Bug#930351: linux-image-4.9.0-9-amd64: soft lockup / stuck in pid_revalidate

On 11/06/2019 22.28, Ben Hutchings wrote: > On Tue, 2019-06-11 at 10:13 +0200, Bernhard M. Wiedemann wrote: > [...] >> kernel:[1616241.072680] NMI watchdog: BUG: soft lockup - CPU#5 stuck for >> 22s! [ps:28525] >> >> [1626796.848128] CPU: 5 PID: 28525 Comm: ps Taint

Bug#930351: linux-image-4.9.0-9-amd64: soft lockup / stuck in pid_revalidate

Package: src:linux Version: 4.9.168-1+deb9u2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? ran the server for some days with KVM VMs on top * What exactly did you do (or not do) that

Bug#929609: different fix upstream

This was solved with a different patch that is already merged upstream: https://github.com/ntop/nDPI/pull/662 -- Bernhard M. Wiedemann openSUSE Developer and Cloud Software Developer and Sysadmin SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton

Bug#917407: related issues

On 28/12/2018 07.53, Johannes Schauer wrote: > I don't think that's likely because: > > - the hashes are reproducible across multiple runs if the same method was > used If you run all your tests on the same filesystem, you will get the same filesystem readdir order, which can make results

Bug#917407: related issues

https://bugzilla.opensuse.org/show_bug.cgi?id=1049186 and https://bugs.python.org/issue34033 could be related. Would be interesting to see a hex diff of indeterministic .pyc files.

Bug#833603: cross-distro

One aspect to consider: even if you found that all Debian packages do not need a handler anymore, there may be other distributions that still needed it. So please be conservative in what you drop. One such example is the ar handler where --deterministic is not the upstream binutils default and

Bug#911281: disorderfs: can not update only mtime

Package: disorderfs Version: 0.5.4 Severity: normal Dear Maintainer, * I found that files extracted by tar into a disorderfs did not have their original mtime restored by futimens / utimensat syscalls * Same effect for touch -m -d@123 $FILE or touch -a that left mtime and atime

Bug#831587: filed upstream

submitted my patch at https://github.com/stressapptest/stressapptest/pull/65 -- Bernhard M. Wiedemann openSUSE Developer and Cloud Software Developer and Sysadmin SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5

Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

> That's sadly something we can only "fix" by making packages have the right > value set. As per Qt policy the environment variable needs to be prefixed > with QT, so no chance of directly using SOURCE_DATE_EPOCH. I added a downstream patch to a test-version [1] in openSUSE with +static

Bug#894476: qt upstream

Is this the same as this upstream bug? https://bugreports.qt.io/browse/QTBUG-62511 that had this patch merged https://codereview.qt-project.org/#/c/202999/5/src/tools/rcc/rcc.cpp with a renamed SOURCE_DATE_EPOCH env var

Bug#881664: QT RCC

in my testing /usr/bin/chessx has diffs like - 23a810 015fe3c5 de19 ._.. + 23a810 0167f7b5 5087 .g..P... coming from QT5's rcc tool tracked in https://bugreports.qt.io/browse/QTBUG-62511 with an upstream patch merged in

Bug#881231: chasen-dictutils: writes uninitialized memory to .dat files

=1067269 [3]: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ipadic.html Author: Bernhard M. Wiedemann Date: 2017-11-08 Problem: when building the ipadic package it differed for every build because its chadic.dat contains uninitialized memory from the da_dat_t structure's padding

Bug#865554: bug in patch

There seems to be a bug in the patch, because [test -n "x$SOURCE_DATE_EPOCH"] is always true, because "x" will always be a non-empty string Discussing a fixed patch with upstream at https://github.com/meetecho/janus-gateway/pull/943

Bug#861948: RFP: libarchive-cpio-perl -- Perl module for manipulation of cpio archives

Package: wnpp Severity: wishlist * Package name: libarchive-cpio-perl Version : 0.10 Upstream Author : Pascal Rigaux * URL : http://search.cpan.org/dist/Archive-Cpio/ * License : unknown Programming Lang: Perl Description : Perl

Bug#115767: I see this too on x86 user-mode-linux on etch

On 2016-02-29 15:12, Sebastian Andrzej Siewior wrote: > the year 2016 arrived and with it new kernel, openssl among other packages. > Can anyone of the reporters here reproduce the bug on current unstable or > atleast stable distro? I have switched from UML to KVM and have not seen this bug

Bug#812103: libapache2-mod-passenger: redmine regression after mod-passenger upgrade

Package: libapache2-mod-passenger Version: 2.2.11debian-2+deb6u1 Severity: normal I recently upgraded libapache2-mod-passenger from 2.2.11debian-2 to 2.2.11debian-2+deb6u1 and found that our redmine 1.2.0.stable (which is not installed from packages and likely obsolete) would no more start with

Bug#780438: fortunes: Please add quotes from Terry Pratchett

On Fri, 13 Mar 2015 22:32:00 +0100 =?utf-8?q?Javier_Fern=C3=A1ndez-Sanguino_Pe=C3=B1a?= j...@debian.org wrote: The patch add these quotes to the several files: humorists, people and magic. note, that the patch contains two dups which differ in line-wrapping: It is said that your life flashes

Bug#738863:

We hit the same bug with a Linux-3.12 kernel and openvswitch in SLES-12 and I built a reproducer without openvswitch with just two network interfaces, one VLAN and one DNAT+SNAT rule. Also some more analysis of what goes wrong http://www.spinics.net/lists/netdev/msg287640.html = this is

Bug#115767: I see this too on x86 user-mode-linux on etch

Hi, I am running several virtual machines (currently using 2.6.24.2) with user-mode-linux (UML) and am seeing the very same problem repeatedly. Mar 25 06:00:05 uml12d sshd[28619]: fatal: Couldn't obtain random bytes (error 604389476) after a dictionary attack with 5 tries per second. I straced

Bug#393295: translucency-source: Doesn't build with 2.6.18

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi The current releases are intended for 2.4.x kernels only I never ported translucency to 2.6.18 mostly for the reason that the fundamental design of translucency is just a hack (which btw was really great to study how applications interact with