On Mon, Feb 13, 2017 at 01:56:42PM -0800, Vagrant Cascadian wrote:
> They've always been against backporting versions not present in testing,
> but I haven't seen a response like that to what I proposed, and don't
> see it listed anywhere on:
> 
>   https://backports.debian.org/Contribute/

because it's not there so explicitly, it's implied in
|Backports are packages taken from the next Debian release (called
|"testing"), adjusted and recompiled for usage on Debian stable. Because
|the package is also present in the next Debian release, you can easily
|upgrade your stable+backports system once the next Debian release comes
|out. (In a few cases, usually for security updates, backports are also
|created from the Debian unstable distribution.)
from https://backports.debian.org/


> > (capitalized, as it happens too often that somebody wants to do it, and
> > then it causes a lot of noise in debian-backports (either IRC or ML),
> > everybody gets more annoyed, etc.)
> 
> I've seen that plenty with a version not in testing, or not in unstable,
> etc. but not noticed any firestorms around packages not in
> stable...

I don't want to search for them, but I'm pretty sure that I've read
emails about
* wheezy-backports versions not being what is in jessie + ~bpo70+1
  https://backports.debian.org/wheezy-backports/older/
  https://backports.debian.org/wheezy-backports/outdated/
  => https://lists.debian.org/debian-backports/2016/05/msg00069.html
* packages in backports not being in whatever+1
  https://backports.debian.org/wheezy-backports/NA/
  luckily this last list is very short.

Same can be said of jessie.
What you were trying to propose is the very same thing that a lot of
people would like to have, like us with a jenkins package...
You can try it, and most probably if they will notice they won't act
just because both rhonda and formorer are quite busy with other stuff to
keep up with enforcing the rules they decide; but if you are unlucky and
they do, I just don't want to be around.

> If, for whatever reason, it's reasonable to continue to maintain an
> older version of diffoscope in stable, the above two points are pretty
> much moot. Just wanted to spell out all the options regarding diffoscope
> and stable, but I'm not attached to any particular strategy.

I don't think it would such a burder; after all it just works, and we
have confirmed through a very coherent check (like running it against
the entire debian archive) that works pretty well.


What I'm concerned is not about having an outdated version in stable -
after all this is what all upstreams face when their package ends up in
debian… - but how to best deal with the freeze :)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to