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
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
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
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.
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
5 matches
Mail list logo