Re: source-only builds and .buildinfo
Daniel Kahn Gillmor writes ("Re: source-only builds and .buildinfo"):
> On Wed 2017-06-21 13:38:42 +0100, Ian Jackson wrote:
> > Certainly `dgit push' will not do anything to any .buildinfo you may
> > have. I think maybe that your use case should be supported by having
> > a version of dgit push which drops the .debs from the .changes, but
> > leaves the .buildinfo ? Is that how you construct these uploads now ?
>
> I really don't have to do anything manually. The standard
> dpkg-buildpackage toolchain does it for me if i pass
> --changes-option=-S -- it all works as i expect, and kudos to the dpkg
> developers for that :)
Then I think `dgit ... sbuild ...' (a binaryful build) followed by
`dgit --ch:-S push' (a binaryless upload) will probably do the same
thing.
Definitely in this case, dgit ought not to mess with the .buildinfo.
(Ie I think it will be included in the .changes, and dgit ought to
leave it there.)
> c) given this explicit set of build dependencies, here are the digests
> of the binary packages that were produced on my system.
>
> You say "verify my assertions about the .debs", i think you're talking
> about part (c), but there's nothing specifically to verify there. I'm
> saying to the world what *i* found when i built them. You want to tell
> me you found something different? fine! Now we have something to
> investigate. You found the same thing? Great, but that's a
> corroboration, not a verification.
Well, (c) is only useful if the build "is" reproducible. (That is,
"is reproducible in some plausible scenario".)
> But i don't think that we need to officially "close the loop" in any
> fancy (or strict) way to warrant shipping .buildinfo files from
> developers. The fancy console i propose above (or anything like it) can
> only be built and used across the archive once we have shipped the
> .buildinfo files. Unnecessarily stripping .buildinfo files that we know
> about only delays that process.
My comments here are more of an aside. I'm certainly not suggesting
that theis line of reasoning suggests any .buildinfos should be
stripped; merely that if I were you I would want to see about closing
this loop so because right now you are perhaps generating .buildinfos
which are going to be difficult to use this way in the future.
If some routine consumer of these .buildinfos comes into being, then
it would definitely be a good idea for dgit to gain convenient and
meaningful option(s) to generate such uploads. More convenient than
`--ch:-S' (which is using an escape hatch, and hence undesirable for
routine use).
However, `dgit push-source' is a different case. That is a command
where the dgit user asks dgit to upload their package source code to
Debian, but without doing any kind of binary package build at all.
(Probably the user has done some kind of pre-upload test to check that
the source does generate working binaries, but perhaps of a source
package with a different version in the changelog, or something.)
In that case, dpkg-buildpackage currently does still generate a
.buildinfo. That .buildinfo does not contain any information about
binary package builds - since there were no binary package builds.
Nor is the build-dependency information in the .buildinfo particularly
useful even for figuring out in what circumstances the uploader was
able to successfully run `debian/rules clean'. The experienced [d]git
user will probably be cleaning their working trees with git clean, not
rules clean. And, regardless, even if the uploader did run rules
clean, this has no bearing on the source package that gets uploaded,
since dgit verifies that the source package is identical to the
uploader's git tree.
Part of the confusion in this thread is, I think, due to the
overloading of the term "source-only upload" for your hybrid upload
which did _build_ binaries, and describes them in the .buildinfo, but
does not actually _ship_ them.
This is a very useful concept but I suggest you give it a new name.
"binaries-attested upload" perhaps ?
To me "source-only upload" means that there were no binaries built,
and therefore no information about binaries included in the upload.
Regards,
Ian.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
Sean Whitton writes ("Re: source-only builds and .buildinfo"):
> Dear Guillem,
>
> On Thu, May 25, 2017 at 03:03:51AM +0200, Guillem Jover wrote:
> > [ Just a very quick reply, will go over the other mails during the week. ]
>
> Have you had more time to think about this one? I'd like to make
> progress on my patch series to dgit, if possible. Thanks.
In the absence of objections to my analysis, I suggest we proceed on
the following basis:
A .buildinfo file is not useful for a source-only upload which is
veried to be identical to the intended source as present in the
uploader's version control (eg, by the use of dgit).
Therefore, dgit should not include .buildinfos in source-only uploads
it performs. If dgit sees that a lower-layer tool like
dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit
should strip it out of .changes.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: source-only builds and .buildinfo
Hi, Ximin. Thanks for your attention.
Ximin Luo writes ("Re: source-only builds and .buildinfo"):
> Also the man page for dpkg-buildpackage is out-of-date:
I think maybe you should file a bug about these ?
> >> So I think for `dgit push-source', there should be no .buildinfo ?
> >> At least, unless dgit ran the clean target.
...
> >> Alternatively dgit could strip out the .buildinfo, depending on
> >> whether it ran rules clean.
> >
> > What do you think ?
> >
> > (The background here is that `dgit push-source' wants to verify for
> > itself that the .changes file it is uploading is really source-only.
> > Because of the possible presence of extraneous (eg BY-HAND) build
> > artefacts in .changes, Guillem suggested comparing the .changes to the
> > .dsc. But of course the .changes contains not only the .dsc and the
> > files named in it, but also the .buildinfo.)
>
> There are a few other options for you:
>
> - Add a --no-buildinfo flag to dpkg-genchanges, then call dpkg-buildpackage
> --changes-option=--no-buildinfo
dgit would have to work around the lack of the flag anyway.
> - Ignore the buildinfo entry in the .changes file.
> - Verify that the buildinfo file contains only ".dsc" entries and that they
> match up with the ones in the changes file.
I did an experimental dpkg-buildpackage -S and I got a .buildinfo
containing the following fields:
Format
Source
Binary
Architecture
Version
Checksums-Md5
Checksums-Sha1
Checksums-Sha256
Build-Origin
Build-Architecture
Build-Date
Installed-Build-Depends
Environment
Because of the weirdness with `debian/rules clean', it is logically
possible for things like the build depends and the environment to
affect the generated source package.
But, I'm not sure what this buildinfo means in the context of
reproducible builds. Is it an assertion that if the b-deps etc. are
as specified, this source package will reproduce itself (ie, will be a
fixed point) ?
That doesn't seem very useful. Sane build machinery which consumes
Debian sources will transport (and, if necessary, modify) those
sources without invoking them to regenerate themselves, so will not
mind source packges which are not a fixed point under
dpkg-buildpackage -S. (By this definition of `sane' many of our
normal tools are not; but I think any tool that is trying to do build
reproduction must be sane by this definition because otherwise it will
be constantly tripping over buggy packages.)
And of course only pretty bad packages are not a fixed point with any
reasonable combination of the build-deps. In practice bugs where the
package is simply broken will far outweigh situationns where rules
clean works properly only with certain versions of the depndencies.
Nothing normally actually verifies the fixed-point-ness. So if the
.buildinfo is such an assertion, it will be a lie in any situation
where the information in it might be useful.
Finally in the context of dgit, the information seems even less likely
to be useful. Much of the time the person generating the source
package will have avoided the use of rules clean at all. In such a
situation the build-deps were not involved in generating the source
package. And dgit does check that the .dsc being uploaded corresponds
to the source the maintainer intended; so with dgit a situation cannot
arise where what is Uploaded = S(Intended) != Intended (where S is the
transformation "unpack, run dpkg-buildpackage -S, grab out the
resulting source package"). With dgit, if S(Intended) != Intended,
either dgit will upload Intended, oblivious to the bug because it
never runs rules clean; or it will run rules clean, discover the
discrepancy, and bomb out.
> I'm actually not sure what your main problem is.
Well, we tripped over this anomaly while trying to decide what dgit
push-source should do.
dgit push-source definitely needs to verify that the .changes file it
is uploading is a source-only upload. That is a safety catch against
unintended binaryful uploads (for example caused due to some
miscommunication in the stacks of build machinery, or the user
manually specifying the wrong .changes file). That means dgit
push-source needs to account for every file in the .changes.
The obvious algorithm is to check that every file in the .changes is
either the .dsc itself, or named in the .dsc. But we discover that
there's a .buildinfo there too. So we need to decide what to do about
it.
Ignoring the .buildinfo seems like an easy workaround but 1. I don't
understand the implications 2. this seems like it's leaving a bug (the
.buildinfo generation) unfixed and unreported 3. the .buildinfo
contains information which ought not to be disseminated (and
published!) unless necessary (or at least, useful).
Particularly (3) means I'm leaning towards arranging for the
.buildinfo to be stripped out (or not generated). But then I am
dismantling Chesterton's fence.
Is there a downside to having dgit make source-only uploads which do
Re: source-only builds and .buildinfo
Sean Whitton writes ("Re: source-only builds and .buildinfo"):
> On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > [Ian:]
> > > Alternatively dgit could strip out the .buildinfo, depending on
> > > whether it ran rules clean.
>
> While a plain `dgit push-source` will prepare a fresh .dsc and .changes,
> we also want it to work with -C, which allows the user to supply an
> existing .dsc and .changes. So even if we use dpkg-source and
> dpkg-genchanges directly, we still need a validation function that says
> whether a .changes is source-only.
Ah, yes.
> Alternatively we could have dgit not accept -C with push-source. This
> would be to think of push-source as a command to /do/ a source-only
> upload, rather than a variant on `dgit push` that /ensures/ a
> source-only upload. This is probably fine.
(For others reading: -C is the dgit option to specify an existing
changes file. Normally `dgit push-source' would generate one.)
I think that would be suboptimal, though. If you say -C you should
get the .buildinfo that's in the .changes, I guess. So that means
that dgit needs a validator, and it needs to accept .buildinfo at
least in this case.
I still think `dgit push-source' (without -C) probably shouldn't
include a buildinfo in the upload unless it ran (or caused
dpkg-buildpackage to run) `debian/rules clean'.
Ian.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
source-only builds and .buildinfo
(Resending with the right CC for reproducible-builds@lists.a.d.o) Hi. I'm widening the scope of this thread because I think the reproducible builds folks might have an opinion. (Holger said on IRC that they'd welcome a CC.) So, I'm going to recap. dpkg-buildpackage -S (which is the conventional way to build a source-only upload) generates a .buildinfo file, which ends up appearing in the .changes. (I don't know what dak does with it.) Sean tripped over this in the context of developing a new dgit operation mode `dgit push-source'. I found the generation of a .buildinfo questionable so we asked debian-dpkg. Guillem pointed me to this FAQ entry: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F As I wrote to Guillem, quoting the FAQ: > By default dpkg-buildpackage does active tasks such as cleaning via > debian/rules, and makes sure that the dependencies from Build-Depends > are satisfied as these are needed by the clean target. In addition the > clean target can perform any kind of action that will affect the > source package, which is also part of the build, and should be by > default also reproducible > > I think what you mean here is that one might have a source package > which is not a fixed point under `debian/rules clean' for all > reasonable combinations of the build-deps. I think this is a buggy > package but in practice it seems that many packages are buggy in this > way. > > Indeed IMO it is a defect of our overall design that it the concept of > a `non-reproducible source package' even exists. Sources are the > input to builds, not an output, so the question of reproducing them > does not arise. That our system as a whole can sometimes mutate the > source package all by itself is a bug. > > However, these are not considerations for dgit in this context, since > what dgit uploads is always guaranteed to be equal to the input. > Often the user will have dgit use `git clean' rather than rules clean; > and even if they don't, dgit will check that the results were the > same. > > That is, even with the .buildinfo, someone who gets the .dsc cannot > know whether the rules clean target is correct (or to put it another > way, under what conditions the source tree is a fixed point under > rules clean), because dgit has not necessarily run rules clean at all. > I'm sure there are other vcsish tools which have the same property. > > (Also, and I hesitate to make this argument because of course I > support reproducible builds, but: if the .buildinfo is not useful, > then it's an unwarranted privacy violation.) > > So I think for `dgit push-source', there should be no .buildinfo ? > At least, unless dgit ran the clean target. > > This suggests to me that dgit push-source should use dpkg-source > rather than dpkg-buildpackage, as you note in later in the FAQ entry: > > If the intention is to just produce a source package instead of an > actual build to upload, then using dpkg-source is always the better > option. > > This wording is a bit unclear. It conflates `build' and `for upload'. > I think regarding `dgit push-source' as a build is perverse. > > dgit would have to run dpkg-genchanges. > > Alternatively dgit could strip out the .buildinfo, depending on > whether it ran rules clean. What do you think ? (The background here is that `dgit push-source' wants to verify for itself that the .changes file it is uploading is really source-only. Because of the possible presence of extraneous (eg BY-HAND) build artefacts in .changes, Guillem suggested comparing the .changes to the .dsc. But of course the .changes contains not only the .dsc and the files named in it, but also the .buildinfo.) Thanks, Ian. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: misleading timestamps in binnmus
Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> (2016-11-09):
> > What version of sbuild do buildds run ? Ie, supposing that this is
> > fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
> > we need to update jessie, or what ?
>
> sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> going to summarize. The base version is close to what's in jessie (see the
> first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
...
> Repository seems to live under:
> https://apt.buildd.debian.org/
Thanks. When Johannes has decided exactly what the sbuild patch looks
like in sid, I will take a look at the repo there and backport the
change. In what form should I supply mhy update ? As an source+all
upload of sbuild, as if I were being sponsored ? As a
git-format-patch against a git import of what I find there (or a
dgitish git branch) ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: sbuild should use build date as binnmu changelog date
Johannes Schauer writes ("Re: sbuild should use build date as binnmu changelog
date"):
> While "Pkg Start Time" might be a good default, I guess for to be able to
> reproduce a binNMU it would be necessary to also allow the user to pass a
> custom timestamp.
Not only a custom timestamp (although I can see situations where that
might be useful), but a whole custom binnmu changelog entry.
Is there already a command line option to provide the binnmu changelog
entry ? I think srebuild and/or derebuild wants to use the binnmu
changelog entry from the .buildinfo file and pass it to sbuild.
Imagine, for example, that a new version of sbuild changes some minor
detail of the text in its binnmu changelog entries. That new version
of sbuild would generate different .debs - unless it used the one from
the .buildinfo. (And it is no answer to say "use the old sbuild",
because sbuild runs outside the build chroot and there might be very
good reasons for wanting a new one.)
> I propose to add the command line option --binNMU-date and use that
> or, if the command line option is not given, the value from the
> environment variable SOURCE_DATE_EPOCH.
I think this is a good option to have, just for flexibility's sake,
but I don't think debrebuild.pl should use it.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#843776: dpkg-buildpackage should set LC_COLLATE=C.UTF-8
Package: dpkg-dev Version: 1.18.12 According to POSIX, the meaning of glob patterns is unspecified in locales other than `the POSIX locale'. [1] It's not easy to see from the spec, but the relevant env var is LC_COLLATE. Many package build rules, dh rules, etc., rely on shell globbing. This shell globbing needs to be predictable. The output of a package build ought not to depend on the locale at all, really. (This is one of the things that the reproducible builds people are trying to ensure.) But we don't want to set LC_MESSAGES, at least, because we want people to be able to debug builds in their native language, as far as possible. It is difficult to imagine a situation where a honouring a user's LC_COLLATE during a package build would be beneficial. In practice, nonstandard LC_COLLATE values can break perfectly sensible looking build code. For example, chiark-utils 5.0.0+exp1 FTBFS in current stretch when LC_COLLATE=fr_CH.UTF-8 because of this: $ touch 11 pp qq $ LC_COLLATE=fr_CH.UTF-8 bash -c 'echo [!A-Z]*[!~]' 11 $ (Interestingly, many of these FTBFS problems will be hidden if /bin/sh is dash, because dash does not honour locales for globbing. This is clearly legal according to the spec, and probably a good decision.) In principle this bug might be fixable by asking (almost) every package to set LC_COLLATE in debian/rules. But ISTM that it would be much better to fix this in dpkg-buildpackage. I suggest that dpkg-buildpackage should do as follows: * Unconditionally set one of the following LC_COLLATE=C.UTF-8 LC_COLLATE=C Colin Watson tells me that C.UTF-8 has been in libc since approximately squeeze. C is theoretically UB (!) for high-bit set octets but in practice works just fine (and it would be intolerable if it didn't). * Check the effective LC_COLLATE using locale(1), and produce a warning if the result is not m/^C(?=\.|$)/. (This is useful because some misguided user might set LC_ALL.) In the meantime the reproducible builds folks may want to consider explicitly setting LC_COLLATE to something sane in their 2nd build. Thanks for your attention. Regards, Ian. [1] Shell path glob patterns are mostly like normal glob patterns: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03 Glob patterns' bracketed [] character sets are mostly like regexp ones: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02 Regexp bracketed character sets with ranges depend on locale. Point 7 of: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05 -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: misleading timestamps in binnmus
Thanks to everyone who has provided information. I have summarised it in #843773, against sbuild. What version of sbuild do buildds run ? Ie, supposing that this is fixed in sbuild in stretch, will this be fixed on the buildds ? Or do we need to update jessie, or what ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: misleading timestamps in binnmus
(CCing reproducible-builds again:)
Sven Joachim writes ("Re: misleading timestamps in binnmus"):
> I'm afraid I don't really have a good suggestion. Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.
I don't understand why using the current date would break
reproducibility.
How does one reproduce a binnmu ?
Clearly one needs a copy of the binnmu changelog stanza, because that
(a) determines the version numbers of the generated .debs and (b) is
actually included in the generated .debs.
There is no updated .dsc in the archive, but the .deb one is trying to
reproduce contains the very changelog fragment in question. So the
procedure has to be to combine the archive's .dsc with the .deb's
binnmu changelog stanza into a new source package.
This ought to be be reproducible regardless of what date is in the
.deb's binnmu changelog stanza. So I think the .deb's binnmu
changelog stanza can be the date of the build (or the date of the
binnmu request, or whatever is convenient).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
misleading timestamps in binnmus
I have just had my backups fail due to the following chain of events: * I had python2.7-stdlib:amd64 2.7.12-3 installed * I did a backup * I upgraded to python2.7-stdlib:amd64 2.7.12-3+b1 was built * I did another backup, during which: * Many files were not copied to the backup volume because their mtimes had not changed * However, the contents of these files had changed because of the rebuild * My backup system is clever enough to spot that there is a problem I see the python2.7 source package does this: LAST_CHANGE := $(shell dpkg-parsechangelog -S Date) export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d '$(LAST_CHANGE)') export BUILD_TIME := $(shell LC_ALL=C date -u +'%H:%M:%S' -d '$(LAST_CHANGE)') Is this a recommended recipe ? AIUI a buildd doing a binnmu will not modify the debian/changelog file. The result is that the file timestamps will be lies after a binnmu. I think this is quite undesirable. Less careful backup programs than mine wouldn't notice. The results would then be a corrupted backup, which would break when restored. There are probably other bad consequences. Can we come up with a better recipe ? For example perhaps DEBIAN_LAST_CHANGE ?= $(shell dpkg-parsechangelog -S Date) which would make it possible for a buildd to override the value. Thanks for your attention. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducible Builds — proo f of concept successful for 83% of all sources in main
Reproducible builds folks writes (Reproducible Builds — proo f of concept successful for 83% of all sources in main): Progress Thanks for the update and keep up the good work. Regards, Ian. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main
Daniel Kahn Gillmor writes (Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main): However, for packages that don't use a framework we can fix, or which use a tool that has no plans to adopt these kinds of modes upstream, I think that if tool upstreams reject (or stall) our requests for reproducible-compatible modes of operation, we should apply such patches ourselves. But I hope this will be very rare. Certainly we should be willing to backport patches from upstreams' development versions to testing (when testing isn't frozen). Your concerns about bit-rot are legitimate, though; if a piece of the toolchain is where a proper fix belongs, and all the dependent packages are working around it now, perhaps we could (a) make sure that the proper fix bug report is filed in the bts against the piece of the toolchain, and that it is marked as affects: with all the packages that are currently working around it. I would generally very much prefer to fix things at the root. That is less effort overall. It may mean that this specific goal is achieved less quickly, but if we spend less effort achieving this goal we can spend that effort on other goals that are also important. We ought to be able in any case to get very far within a single Debian release cycle. Basically, i think the BTS has the semantics to support keeping track of these dependent issues so that we end up with clean long-term fixes, while we can use our packager's discretion to implement the shorter-term workarounds, annoying though they may be. what do you think? Also, less involvement with annoying workarounds means less annoyance and therefore more fun and therefore more work and faster progress. This does depend of course on the interactions between different maintainers on these subjects also being fun and constructive. If they aren't then a workaround may be better. (IMO such maintainers ought to be replaced. We have too many who are hard to work with. But the only sensible way to get rid of them, or even just to get a needed patch accepted, is to ask the Technical Committee; and the TC has shown itself to be extremely reluctant to intervene.) Ian. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
