Re: Fixing incorrect .orig

2018-01-27 Thread Russ Allbery
wf...@niif.hu (Ferenc Wágner) writes: > Wookey writes: >> Is there a suffix typically used for this situation of essentially >> 're-done upstream source' > $ grep "Version.*real" > /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages > > reveals some other option

Re: Fixing incorrect .orig

2018-01-27 Thread Ferenc Wágner
Wookey writes: > Is there a suffix typically used for this situation of essentially > 're-done upstream source' Hi, $ grep "Version.*real" /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages reveals some other options like +real and (+)really, and I've seen .re

Re: Fixing incorrect .orig

2018-01-26 Thread gregor herrmann
On Fri, 26 Jan 2018 22:45:38 +, Wookey wrote: > Is there a suffix typically used for this situation of essentially > 're-done upstream source' (a bit like we use ds for 'debianised > source' or somesuch when it's been repacked, usually to remove > non-free things or non-source things)? I thin

Re: Fixing incorrect .orig

2018-01-26 Thread Mattia Rizzolo
On Fri, Jan 26, 2018 at 10:45:38PM +, Wookey wrote: > Anyway, the question is, what's the best way to fix this? I can't > upload a new .orig until the upstream part of the version number is > bumped - right?, because any -n debian suffix assumes the same .orig > for the base base version IIRC.

Fixing incorrect .orig

2018-01-26 Thread Wookey
For reasons of confusion and general incompetence I've ended up uploading a package where the .orig tarball is not actually the upstream .orig. It's a) the .orig plus the set of patches that would normally be in debian/patches, and b) one subdirectory (the important one) of the upstream tarball