Bug#894217: reprotest: robust mode to make it usuable in CI pipelines

control: retitle -1 "reprotest: robust mode to make it usuable in CI pipelines" control: severity -1 wishlist # trying to summarize this feature request # thanks hi, maybe there could be a robust mode using "safe" locales and another mode, thoroughly testing stuff... -- cheers, Holger

Bug#894217: Info received (reprotest: robust mode to make it usuable in CI pipelines)

control: retitle -1 "reprotest: robust mode to make it more usuable in CI pipelines" # thanks -- cheers, Holger signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://

Re: distributing .buildinfo files (Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master)

On Thu, Apr 05, 2018 at 10:43:04AM +0200, Philipp Kern wrote: > So what would be needed to make at least a simple export of the data > happen? I think the requirements I'd have are these: that's a good question! :) maybe we can sit together with some ftp-team and reproducible builds folks in Hamb

Re: [rb-general] Please review the draft for week 156's blog post

On Sun, Apr 22, 2018 at 08:32:18AM +0100, Chris Lamb wrote: > Please review the draft for week 156's blog post: > https://reproducible.alioth.debian.org/blog/drafts/156/ I get a 404 here. the old url should still be working :) -- cheers, Holger signature.asc Description: PGP signat

Bug#802241: please store the hash of the installed .deb and allow to query it

- Forwarded message from Drew Parsons - Date: Tue, 24 Apr 2018 16:43:48 +0800 From: Drew Parsons To: 802...@bugs.debian.org Subject: Bug#802241: please store the hash of the installed .deb and allow to query it Reply-To: dpars...@debian.org, 802...@bugs.debian.org List-Id: I got caugh

Bug#897442: reprotest timeouts while installing the build-dependencies

Hi Paride, thanks for your bug report! (I'll let others comment on it's content...) On Wed, May 02, 2018 at 06:59:53PM +0200, Paride Legovini wrote: > This is how it fails: > https://paste.debian.net/1022959/ this is nice on IRC but not so good in the BTS where we rather want to archive things f

Re: Please review the draft for week 158's blog post

On Sun, May 06, 2018 at 04:37:22PM +0100, Chris Lamb wrote: > Please review the draft for week 158's blog post: > https://reproducible-builds.org/blog/posts/158/ looks good to me, though suprisingly short. (and I would like to get back the word "draft" into the url, but enotime atm unfortunatly

Re: Please review the draft for week 158's blog post

On Mon, May 07, 2018 at 07:55:39PM +0100, Chris Lamb wrote: > > looks good to me, though suprisingly short. > Well, alas, there's not much I can do about that at report-writing > time… sure. > > and now I wonder whether we should mention again that we lack funding > > atm, which hugely contribut

Re: Please review the draft for week 158's blog post

On Tue, May 08, 2018 at 05:01:59PM +0100, Chris Lamb wrote: > That's how I originally interepreted your query. I feel the trade-off > between it being accidentally intepreted a "sulk" and it attracting > meaningful results (not mere community support) means we should err > on the side of omitting i

Re: packages which have not been rebuild since December 2016

Hi, On Thu, May 31, 2018 at 05:33:10PM +0200, Guillem Jover wrote: > > We have the "upload_history" relation but that will only give us an > > upper limit (roughly 50% of the archive). > > I think this should be relatively easy to compute: yes, that's the easy part, once you have the data :) >

Re: packages which have not been rebuild since December 2016

Hi Chris, On Fri, Jun 01, 2018 at 10:40:18AM +0100, Chris Lamb wrote: > > I think this should be relatively easy to compute: > Indeed — 9182/33705 packages need a rebuild in sid. > (Full output of following script attached.) hehe, very nice. Just the numbers strike me as odd: we currently have

re: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Hi Guillem, ping on this bug, you haven't replied to it yet and it's a blocker for "#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds" which is a rather important one to give users the means to easily reproduce Debian packages, which is a core feature of reproducible build

Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Guillem, josch: thanks for your feedback, much appreciated. On Fri, Jun 08, 2018 at 08:38:49AM +0200, Johannes Schauer wrote: > > I say it's an artificial blocker, because it is based on the problem > > faced while implementing the srebuild script to use the current > > snapshot.d.o API. And I th

Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Hi josch, adding #774415 to to: and reply-to:… On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote: > > as I'm not an sbuild user (yet) myself, I was hesistant to try this > > myself, so I'm confused now: does it work as it is now? (or does it need > > changes to snapshot.d.o?) > >

#774415: devscripts: please add the srebuild wrapper for reproducible builds

control: reassign -1 devscripts control: retitle -1 devscripts: please add the srebuild wrapper for reproducible builds thanks On Sat, Jun 09, 2018 at 10:33:16PM +0200, Johannes Schauer wrote: > Quoting Holger Levsen (2018-06-09 22:12:33) > > As it sounds, I now believe this script wou

Re: koji_1.16.0-2_source.changes ACCEPTED into unstable

On Wed, Jul 18, 2018 at 11:41:25PM -0400, Sergio Durigan Junior wrote: > Secondly, I would like to propose renaming the current "koji-common" > package to "python{,3}-koji" (IOW, we'd also build it for Python 3), > which would make it be have the same name as in Fedora. WDYT? I think you should f

Re: RFC: dpkg patch to using -ffile-prefix-map

On Tue, Jul 31, 2018 at 04:54:09AM +0200, Guillem Jover wrote: > > > --- a/scripts/Dpkg/Vendor/Debian.pm > > > +++ b/scripts/Dpkg/Vendor/Debian.pm [...] thanks for your work on this, Guillem! (and Vagrant of course too!) Not sure we attributed Guillem corrently on this in https://reproducible-bui

dpkg/gcc-8 regressions

hi, from irc: [14:52] < h01ger> | vgrntc: moin :) https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png looks like we are regressing. havent looked closer though. also visible on other archs, eg arm64 (amd armhf and i386 to a lesser degree)

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

Hi Guillem, people are still affected by this bug... On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote: > Perhaps the simplest and more correct might be to name it using > something like source+amd64 as the arch name, which seems like a > dubious arch, but at least is accurate and mig

Re: Empty build-id to make package reproducible

Hi, (replying to the list with Otto's permission..) On Sun, Aug 05, 2018 at 02:51:16AM +0800, Otto Kekäläinen wrote: > This is what we talked about today: > https://salsa.debian.org/mariadb-team/galera-3/commit/1460cfa128fb457b5b5c60fcc5cac6faf5a216d5 I'm wondering, is this really a good approac

Bug#905885: diffoscope: skipping tests on ci.debian.net is perhaps wrong?

Control: retitle -1 'allow to override @skip_unless_tools_exist during tests and fail the test if the tool is missing' -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org

Bug#909694: reprotest: please export DEB_BUILD_OPTIONS=reproducible=+all

Package: reprotest Version: 0.7.8 Severity: important Dear Maintainer, < KGB-1> | Mattia Rizzolo master 4860753 jenkins.debian.net bin/reproducible_build.sh * https://deb.li/v57l < KGB-1> reproducible debian: enable all the reproducible-related build flags from dpkg, by export

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

Package: diffoscope Severity: important Hi, I just gave a small presentation about diffoscope at the mirage.io hackretreat (which was well received) which resulted in people wanting to file bugs against diffoscope, which turned out to be "complicated": - the project on salsa has issues disabled

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

On Mon, Oct 08, 2018 at 10:22:56AM +0200, Mattia Rizzolo wrote: > On Mon, Oct 08, 2018 at 12:15:36AM +0200, Marek Marczykowski-Górecki wrote: > > Filling bugs in web browser is indeed something many people expect. > (grumpy person here that don't understand those people…!) I think you're just offi

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

Dear Chris, On Sun, Oct 07, 2018 at 10:33:49PM +0100, Chris Lamb wrote: > (Adjusting severity only because important severity bugs are treated > somewhat different in some interfaces, but agree this is more > severe than "just another" wishlist entry.) I agree, was thinking the same when filing t

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

On Mon, Oct 08, 2018 at 03:21:41PM +0100, Chris Lamb wrote: > Oh sure, we are all in agreement here but users of diffoscope in Debian > are likely to file their generic issues in the Debian bug tracker, > resulting in duplication. I dont think this is a problem, or rather a problem with diffoscope

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

Dear Chris, On Mon, Oct 08, 2018 at 03:36:55PM +0100, Chris Lamb wrote: > I'm sorry this appears to have upset you so much I'm afraid I'm > somewhat struggling to see the full extent why. and > Naturally, if I thought this would have been a problem I would not have > pushed the button. sure, I

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

Hi Chris, On Mon, Oct 08, 2018 at 08:15:59PM +0100, Chris Lamb wrote: > > But I think we want to move something distro agnostic, and salsa.d.o > > is very much Debian centric, so I think we should look for something > > else. I'd be fine to using github.com or gitlab.com or foobar. > Let's try and

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

On Wed, Oct 10, 2018 at 04:34:39PM +0200, Marek Marczykowski-Górecki wrote: > > I'd like to hear what potential bug reporters would like to see, rather > > than us trying to guess what they might think; therefore, I believe this > > bug should (well, could) be deferred to in-person discussion in Pa

Bug#910542: better support for OCaml object files via ocamlobjinfo

On Tue, Oct 16, 2018 at 05:00:35PM -0400, Chris Lamb wrote: > Thanks for the report. I've implemented this in Git, now pending upload: > > https://salsa.debian.org/reproducible-builds/diffoscope/commit/bc92ac311960b43abd1067df83ddee1729dc38bd awesome, thank you! -- cheers, Holger --

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

Hi, On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote: > We were again biten by this issue for some security-updates (most > recent one nginx). Do any involved parties know, was there any > progress in adressing this problem? in https://bugs.debian.org/cgi-bin/bugreport.cgi?bu

Bug#910541: salsa is fine

On Fri, Dec 14, 2018 at 05:11:30PM +0100, Marek Marczykowski-Górecki wrote: > This is all fine, but issues on salsa diffoscope project are still > disabled. any objections to me enabling them? :) -- cheers, Holger

Bug#910541: [rb-general] salsa is fine

On Fri, Dec 14, 2018 at 07:05:49PM +0100, Chris Lamb wrote: > > any objections to me enabling them? :) > Yes and no. :) :) > As in; I have nothing against moving to salsa (!) if we go that route, > we should just first firmly decide whether the BTS or salsa is the > canonical source of truth. I

Bug#910541: [rb-general] salsa is fine

On Fri, Dec 14, 2018 at 07:19:46PM +0100, Chris Lamb wrote: > My reading of this is that (ignoring Debian-specific issues as they > are an "easy" case IMHO) salsa becomes the single source of truth; ie. > we both encourage and at least aim to forward/refile all "upstream" > bugs to Salsa. absolutl

Bug#920732: strip-nondeterminism should normalize file ownerships in epubs too

Package: strip-nondeterminism Version: 1.1.0-1 Severity: wishlist Hi, debian-edu-doc 2.10.11 when tested on tests.r-b.o shows this: │ │ │ ├── ./usr/share/doc/debian-edu-doc-da/debian-edu-buster-manual.epub │ │ │ │ ├── bsdtar -tvf {} │ │ │ │ │ @@ -1,54 +1,54 @@ │ │ │ │ │ drwxr-xr-x 0 0 0

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

Hi Sune, thanks for reaching out to us! On Sat, Feb 09, 2019 at 07:54:16PM +0100, Sune Vuorela wrote: > (Please keep me CC'ed. Not subscribed) done. > The latest incarnations of the reproducible build autobuilder setup passes > some options to gcc to not let __FILE__ actualy be the full file

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

On Sun, Feb 10, 2019 at 03:58:15PM +0100, Sune Vuorela wrote: > On Sunday, February 10, 2019 3:34:27 PM CET Holger Levsen wrote: > > On Sat, Feb 09, 2019 at 07:54:16PM +0100, Sune Vuorela wrote: > > > (Please keep me CC'ed. Not subscribed) > > done. > thanks. and

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

On Sun, Feb 10, 2019 at 04:41:10PM +0100, Sune Vuorela wrote: > (Please keep me CC'ed. Not subscribed) ack. > If you have magic regexes to auto tag issues, lines matching > /WARNING: .* testdata .* could not be located!/ > would probably find those where it applies to current test cases, at leas

Bug#926065: unblock: diffoscope/113

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package diffoscope, it has been in sid for 26 days without any regressions reported (compared to 112 in buster currently) and has been used to compare all unreproducible packa

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

Hi, On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote: > > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote: > > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote: > > > > On Thu, 2018-11-08 at 20:28:57 +, Holger

Bug#929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master

Package: ftp.debian.org Severity: wishlist hi, from #-security today: * | h01ger wonders how to tackle #862538 zwiebelbot | (#debian-security) Debian#862538: security.debian.org: Please POST .buildinfo files to buildinfo.debian.net - https://bugs.debian.org

Re: what to do with stretch?

Hi, Mattia, thanks for bringing this up! On Sat, Jul 06, 2019 at 10:42:50AM +0200, Mattia Rizzolo wrote: > Today buster is being released, and I think we will do some shuffling to > copy the buster data into the new bullseye shortly after, so we can > start test for that as well. yup. (though i'

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: > Shortly before the end of the 6th July, we released Debian 10, "buster". *yay* *yay* & *yay*! > No binary maintainer uploads for bullseye > = > > The release of buster also means th

Re: testing migration aging and reproducible builds

On Sun, Jul 21, 2019 at 05:35:53PM -0300, Jonathan Wiltshire wrote: > On Sun, Jul 21, 2019 at 11:55:59AM -0300, Vagrant Cascadian wrote: > > This makes me think to decrease the delay for reproducible packages > > rather than increase the delay for unreproducible ones? Though then > > you'd want it

Re: testing migration aging and reproducible builds

On Mon, Jul 22, 2019 at 10:46:37AM -0300, Chris Lamb wrote: > One question: Does your proposal also imply a source package being > strictly reproducible in unstable or, alternatively, did you mean to > imply it "not regressing" from being previously reproducible in > unstable? > > This latter idea

Re: "Reproducible Builds - aiming for bullseye" comments and a purpose

hi Jathan, fun fact: if you don't cc: me, you usually get a faster reply from me. On Sun, Jul 21, 2019 at 08:47:46PM -0500, jathan wrote: > Today I attended the talk "Reproducible Builds - aiming for bullseye" at > DebConf19 and I want to share some comments since some things I consider > we are

Bug#932849: ftp.debian.org: NEW process looses .buildinfo files

Package: ftp.debian.org Severity: normal hi, https://tracker.debian.org/news/1027072/accepted-liblogger-simple-perl-20-1-source-all-into-unstable-unstable/ says this upload was made with a .buildinfo file, yet this .buildinfo file isnt available this was on 2019-02-04 any idea why this coul

Re: Second build of kronosnet fails on i386

On Thu, Jul 25, 2019 at 06:17:23PM -0300, wf...@niif.hu wrote: > As > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/kronosnet.html > shows, the first build succeeds, but the second one hits a failure in > the build time unit tests. This has been rather consistent for several >

[ty...@mit.edu: Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?]

FYI, (I guess we know already :) - Forwarded message from "Theodore Y. Ts'o" - Date: Sun, 28 Jul 2019 19:44:34 -0400 From: "Theodore Y. Ts'o" To: Steffen Möller Cc: debian-de...@lists.debian.org Subject: Re: And in 2019? Re: -flto to become more of a routine - any change in opinion s

Re: [Git][qa/jenkins.debian.net] reproducible: vary BUILDDIR for 2nd build so that the path length also

Hi, I've deployed the following change now. If this causes significantly more breakage than before we should probably/maybe revert it again... On Sun, Aug 04, 2019 at 03:13:56PM +, Vagrant Cascadian wrote: > Vagrant Cascadian pushed to branch master at Debian QA / jenkins.debian.net > > Comm

Re: Bug#934405: debhelper: Please ignore binNMUs in get_source_date_epoch() function

Hi, thanks for filing a bug report about this issue. However... On Sat, Aug 10, 2019 at 09:24:37PM +0300, Dmitry Shachnev wrote: > I figured out that these timestamps are coming from binNMU changelogs. yes, binNMUs change the sources, despite their name. they are a hack. see #894441: 'binNMUs s

Bug#936806: koji: Python2 removal in sid/bullseye

On Fri, Aug 30, 2019 at 07:22:19AM +, Matthias Klose wrote: > Package: src:koji > Version: 1.16.2-1 [...] > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. koji 1.18

Re: pipeline | WIP: Integrate atomic reprotest into salsa-ci pipeline (!168)

On Tue, Sep 03, 2019 at 05:11:16PM +0200, Santiago Ruano Rincón wrote: > To give you an example of atomic results, see the current salsa ci > pipeline of konsole: > > https://salsa.debian.org/qt-kde-team/kde/konsole/-/jobs/279499 > > and debugging it with atomic-reprotest > > https://salsa.debia

Re: Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes

On Thu, Sep 05, 2019 at 10:07:26AM +0200, Stéphane Glondu wrote: > I see this is a native package. Why don't you use the version in > debian/changelog to generate diffoscope/__init__.py? If this was not a > native package, or if the version number would otherwise naturally split > in two parts, I w

#763822: ftp.debian.org: please include .buildinfo files in the archive

Dear ftp team, it would be very cool if you could comment on this bug, even though there is https://buildinfos.debian.net/ftp-master.debian.org/ and https://buildinfos.debian.net/buildinfo-pool/ now. Distributing .buildinfo files is one requirement for making reproducible builds a reality for our

re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

hi, so I thought I'd be bold and add the srebuild wrapper to src:devscripts in git this weekend... So I re-read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415 rather completly and noticed, that - the branch devscripts-srebuild from https://salsa.debian.org/yadd/devscripts for a long

bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

Hi, this just went by on debian-devel@l.d.o: On Mon, Oct 07, 2019 at 01:43:18PM +0200, Johannes Schauer wrote: [...] > Downloading "random binary from the internet" is less of a problem if we can > create images which are bit-by-bit identical to checksums that we can verify > through a trusted se

Re: bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

Hi josch, On Tue, Oct 08, 2019 at 10:49:50AM +0200, Johannes Schauer wrote: > > And, does this work for mmdebstrap'ing buster too? (whether using > > mmdebstrap from unstable or buster...) > lets find out! hehe, thanks! > $ sudo mmdebstrap --include=mmdebstrap,debootstrap,diffutils buster >

Re: bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

Hi josch, On Tue, Oct 08, 2019 at 11:34:23AM +0200, Johannes Schauer wrote: > the sha256sums are the sums computed from the output of mmdebstrap on stdout > (notice the pipe character in front of the sha256sum command). ah, thanks. Seems i got tricked into the thinking mmdebstrap would output it

Re: Cloning reproducible-builds environment

Hi Jeff, thanks for caring about reproducible builds and getting back to us! On Thu, Oct 24, 2019 at 06:35:15PM +0200, Jeff wrote: > I'm trying to fix the FTBFS that is reported here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gscan2pdf.html > > Having fixed the test

Bug#944882: diffoscope: please (at least) include hint in html that text version has no max report size

Package: diffoscope Version: 1.30 Severity: minor Dear diffoscope maintainers, (some aspects of) the current behavior of diffoscope and 'max report size' is as: - only considered for html output, but not for text (where it is unlimited), default is 400kb max. I'd like to suggest: - increase

Re: Cloning reproducible-builds environment

Hi Jeff, sorry for the delay in responding... On Tue, Dec 03, 2019 at 07:05:22PM +0100, Jeff wrote: > On 24/10/2019 20:24, Holger Levsen wrote: > > it wont be exactly the same but reprotest (from the package with that > > name) should let you test more variations than just usi

Re: notes repository shared with all DDs

On Sat, Jan 11, 2020 at 03:33:08PM +0100, Mattia Rizzolo wrote: > I just shared the notes repository¹ with the "Debian" group, therefore > giving all DDs write access to it. > It's my attempt to invite more direct contributions instead of MRs :) neato, very & many thanks for doing this too! (and

Bug#942146: koji: CVE-2019-17109

Hi Salvatore, On Sun, Jan 05, 2020 at 09:02:20PM +0100, Salvatore Bonaccorso wrote: > Any news on this issue? AFAICT, the issue is fixed as well in 1.16.3, > so the smaller jump should be possible. Once fixed in unstable, can > you adress the issue as well via point release? I think it's pointles

Bug#942146: koji: CVE-2019-17109

On Thu, Jan 23, 2020 at 08:42:03PM +0100, Moritz Muehlenhoff wrote: > Let's remove it in the upcoming stretch/buster point releases, then? seems reasonable to me. -- cheers, Holger --- holger@(de

Re: Bug#936806: koji: Python2 removal in sid/bullseye

On Tue, Jan 28, 2020 at 11:21:46PM -0500, Sandro Tosi wrote: > ok, whos of the maintainers is working on packaging 1.18? i see > there's even 1.20 released. noone, I believe. Also because it needs dnf, which is not packaged for Debian at all. I was just going to remove myself from uploaders in gi

Re: Bug#936806: koji: Python2 removal in sid/bullseye

On Thu, Jan 30, 2020 at 01:36:33AM -0500, Sandro Tosi wrote: > yep i came across all of them starting from python-lzma -- do you know > what's the status of the "RedHat infrastructure" in debian? many (if > not all) of those tools are relatively old, not maintained (or just in > life support mode)

Re: Bug#936806: koji: Python2 removal in sid/bullseye

On Thu, Jan 30, 2020 at 09:55:58AM -0500, Sandro Tosi wrote: > i was mostly querying the status of it, i cant even find an ITP for dnf. exactly. > i was talking about removing koji entirely from debian, an RM to > ftp.d.o; is that not what you mean? right, this is also in order. -- cheers,

Re: Bug#936806: koji: Python2 removal in sid/bullseye

On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote: > thanks! I'm gonna go ahead and file an RM bug for the following pkgs > too: yum createrepo python-lzma yum-metadata-parser mock yum-utils > dtc-xen deltarpm > > they are a closed set thank you for cleaning up after all of us, now that

Re: Bug#936806: koji: Python2 removal in sid/bullseye

Hi, On Fri, Feb 14, 2020 at 03:12:20AM +0100, Marek Marczykowski-Górecki wrote: > > I mean, rpm is definitly still useful to have on Debian, but yum and > > friends??? > They are also useful in some cases. For example if you want to use > Debian-based VM to download updates for your Qubes dom0...

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

hi Guillem, On Fri, Nov 09, 2018 at 11:55:38AM +0100, Guillem Jover wrote: > Actually, I guess the other option that might be an option for stable is > to make dpkg-buildpackage generate the buildinfo file itself, and on > source-only uploads force the name to be _source.buildinfo regardless > of

Re: Bug#936806: koji: Python2 removal in sid/bullseye

On Sun, Feb 23, 2020 at 04:06:23PM +0100, Marek Marczykowski-Górecki wrote: > > so for the record: while I can easily workaround the above problem by using > > a > > Fedora based VM to download updates for my Qubes dom0, I'd be glad to help > > people to get yum, dnf and rpm back into Debian, eg b

Bug#955049: debrebuild: no manpage and no --help option

Package: devscripts Version: 2.20.2 Severity: normal x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, debrebuild has no manpage and no --help option, so it's a bit hard to get started using it. Please add both. -- cheers, Holger -

Bug#955050: debrebuild: please accepted signed .buildinfo files

Package: devscripts Version: 2.20.2 Severity: normal Dear Maintainer, please make debrebuild not fail on signed .buildinfo files: $ debrebuild bash_5.0-6_amd64.buildinfo debrebuild: error: syntax error in bash_5.0-6_amd64.buildinfo at line 1: OpenPGP signature not allowed here -- cheers,

Bug#955051: debrebuild: Build-Architecture fields are optional but debrebuild mandates them

Package: devscripts Version: 2.20.2 Severity: normal Dear Maintainer, $ debrebuild bash_5.0-6_amd64.buildinfo Use of uninitialized value in split at /usr/bin/debrebuild line 55. need Build-Architecture field at /usr/bin/debrebuild line 70. $ It seems that debrebuild needs a Build-Architecture fi

Bug#955123: debrebuild: please provide --sbuild-output-only option

Package: devscripts Version: 2.20.2 Severity: wishlist Dear Maintainer, when running debrebuild it produces output, first instructions how to rebuild manually and second, how to rebuild using sbuild. For automating this it would be very useful to have a --sbuild-output-only switch, which would j

Bug#955280: debrebuild: please stop using the reproducible-builds.org apt repo

Package: devscripts Version: 2.20.2 Severity: normal Dear Maintainer, $ grep reproducible /usr/bin/debrebuild my $armored_key = "$tempdir/etc/apt/trusted.gpg.d/reproducible.asc"; my $dearmored_key = "$tempdir/etc/apt/trusted.gpg.d/reproducible.gpg"; "https://tests.reproducible-builds.org/d

Bug#955298: debrebuild: please switch from httpredir.d.o to deb.d.o

Package: devscripts Version: 2.19.5+deb10u1 Severity: wishlist x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, please switch from using httpredir.debian.org to deb.debian.org: $ grep httpredir /usr/bin/debrebuild deb http://httpredir.debian.org/debian/ $base_dist main

Bug#955304: debrebuild: suggested sbuild command should use --no-run-lintian

Package: devscripts Version: 2.19.5+deb10u1 Severity: wishlist Dear Maintainer, Subject says it all: debrebuild should suggest (or run, see #955123) to use the --no-run-lintian switch for sbuild. -- cheers, Holger ---

Bug#955307: debrebuild: should avoid downgrades

Package: devscripts Version: 2.20.2 Severity: normal Dear Maintainer, this bug report is a bit premature, as currently debrebuild does not setup the chroot debrebuild (or rather the sbuild command generated by debrebuild), but anyway, let's file a bug to track this problem and improve upon: I ju

Bug#955308: debrebuild: also explain *how* to use snapshot.d.o

Package: devscripts Version: 2.20.2 Severity: wishlist Dear Maintainer, debrebuild uses snapshot.d.o to install packages and it also gives some hints how to set up sbuild. However it doesn't tell that apt has to be instructured to ignored expires signatures, as else snapshot.d.o is not usuable as

Bug#955434: tracker.d.o: please integrate information from buildinfos.debian.net

Package: tracker.debian.org Severity: wishlist Dear Maintainer, please integrate information from buildinfos.debian.net into tracker.d.o, which is a different view/aspect of reproducible builds of Debian packages than the one currently integrated. The current one is about the results from tests.

Bug#958666: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning

package: lintian version: 2.67.0 x-debbugs-cc: Debian Med Project List , Debian Developers , Debian Lintian Maintainers , reproducible-bui...@lists.alioth.debian.org On Fri, Apr 24, 2020 at 09:56:24AM +0200, Andreas Tille wrote: > today I've seen the first time this new lintian warning: > >

Bug#958750: debrebuild: please add --standalone mode or --one-shot-mode

Package: devscripts Version: 2.20.2 Severity: wishlist x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, debrebuild expects a working sbuild setup, which is a sensible expectation. It would however also be nice if it had a --standalone mode or --one-shot-mode which would

Re: Update blacklist for armhf

Hi Vagrant, On Tue, Apr 28, 2020 at 03:38:40PM -0700, Vagrant Cascadian wrote: > As mentioned on irc to holger and mattia, I reviewed packages that ought > to get blacklisted on armhf, as they almost always timeout on builds, so > they consume CPU, RAM and disk that could be better used testing ot

Re: Update blacklist for armhf

hi, On Wed, Apr 29, 2020 at 11:15:11AM -0700, Vagrant Cascadian wrote: > Thanks! Should be able to handle future updates myself now! :) great. feel free to also blacklist some big packages on i386, which is also lagging quite a bit behind. > Running as the "jenkins" user was what I was missing.

Re: M2-Planet v1.6.0 and mescc-tools v1.0.0 released

On Sat, May 02, 2020 at 08:58:47AM +0200, Jan Nieuwenhuizen wrote: > > A K+R C equivalent C compiler, assembler, linker, dwarf stub generator > > and shell able to produce fully standards compliant ELF binaries for > > Knight, x86, AMD64, armv7l and aarch64 and be bootstrapped from a sub > > 250byt

Bug#961064: reprotest: use of faketime causes newly created file to have very old modified time

control: retitle -1 reprotest: should not default to vary time and date thanks Hi James, thanks for your bug report! On Tue, May 19, 2020 at 02:49:58PM -0400, James Valleroy wrote: > time(): 1631998736 > touch($cacheFile); > clearstatcache(); // has no effect > filemtime($cacheFile): 1589907896

Re: [announce] diffoscope 144 released

Dear Chris, On Thu, May 14, 2020 at 10:58:03PM -, Chris Lamb wrote: > The diffoscope maintainers are please to announce the release of > version 145 of diffoscope. \o/ > diffoscope tries to get to the bottom of what makes files or > directories different. [...] > Version 145 includes the fo

Bug#961857: reproducible-check: incomprehensive and too good results

Package: devscripts Version: 2.20.3 x-debbugs-cc: reproducible-builds@alioth-lists.debian.net Hi, on a sid system I get this when running reproducible-check from devscripts: $ reproducible-check alsa-lib (1.2.2-2.1) is unreproducible (libasound2)

Bug#961858: reproducible-check: should be explicit about just showing CI results

Package: devscripts Version: 2.20.3 Severity: normal hi, reproducible-check shows how many of the installed binary packages are (un)reproducible in our current CI framework, that is these results only show the theoretical reproducibility of these Debian pacakges, they *do not* however show any r

Bug#961859: reproducible-check: should not show results on Ubuntu and other distros != Debian

Package: devscripts Version: 2.20.3 Severity: normal x-debbugs-cc: reproducible-builds@alioth-lists.debian.net hi, reproducible-check should not show any results on Ubuntu as Ubuntu is not involved in Reproducible Builds and not doing any efforts. TTBOMK they also don't publish their .buildinfo

Bug#961861: debrebuild: should (optionally) download the source too

Package: devscripts Version: 2.20.3 Severity: normal Dear Maintainer, even though current .buildinfo files in Debian don't contain the hashes of the source package (as we mandated in our original design) it would be great if debrebuild could, at least optionally also download the source packages.

Bug#961862: debrebuild: should assemble the source for binNMUs

package: devscripts Version: 2.20.3 Severity: normal x-debbugs-cc: reproducible-builds@alioth-lists.debian.net Dear Maintainer, TTBOMK currently there is no tool to assemble the source for a binNMU. The source for a binNMU has do be assembled like this: - take the normal source package and unpa

Bug#961864: debrebuild: creates wrong commandline for binNMUs

Package: devscripts Version: 2.20.3 Severity: normal Dear Maintainer, debrebuild creates wrong commandlines for binNMU, because the source field in .buildinfo files looks different for binNMUs than normal uploads. Normal uploads have these entries: Source: libqcow Version: 20181227-1.1 binNMUs

Re: Enabling -ffile-prefix-map by default

Hi, I'm very glad to see this moving forward! On Sat, Jun 06, 2020 at 03:21:06PM -0700, Vagrant Cascadian wrote: > We'd be able to get more accurate data if we remove the flag for > bullseye and manually schedule all of those packages, at least > temporarily... anyone have concerns with doing tha

Re: Enabling -ffile-prefix-map by default

On Fri, Jun 12, 2020 at 02:27:50PM -0700, Vagrant Cascadian wrote: > I've pushed to git: > > https://salsa.debian.org/qa/jenkins.debian.net/-/commit/f2a447eacfe375951476f369c8b61f02891d97c7 cool, thanks. > Refreshing my memory on how to deploy it by reading the docs... once > that's done, we

Re: Enabling -ffile-prefix-map by default

Hi Vagrant, interesting findings! On Tue, Jun 16, 2020 at 10:03:24PM -0700, Vagrant Cascadian wrote: > > Many of them appear to go from FTBFS to reproducible, FWIW. nice. what is your general recommendation/plan for the next action item here? > The packages that seem to have been "fixed" were r

Re: Enabling -ffile-prefix-map by default

On Mon, Jun 22, 2020 at 05:04:54PM -0700, Vagrant Cascadian wrote: > On 2020-06-17, Holger Levsen wrote: > > interesting findings! > > > > On Tue, Jun 16, 2020 at 10:03:24PM -0700, Vagrant Cascadian wrote: > >> > Many of them appear to go from FTBFS to reproduc

Re: Debonf20 Online talk proposal?

On Sat, Jul 04, 2020 at 04:16:37PM -0700, Vagrant Cascadian wrote: > Has anyone already submitted a Reproducible Builds talk proposal for > Debconf20 (which is now, unsurprisingly, scheduled to take place > online)? [...] > There is a dealine of July 5th! not yet, but I will within the next 4h. >

  1   2   3   >