Re: sphinx* packages
Hello, Paul Gevers, on ven. 03 nov. 2017 11:35:06 +0100, wrote: > The current package of python-sphinxbase contains¹ a (unstripped!) > static library. Is that on purpose? No. > If not, do you see a good reason to keep it (stripped or unstripped)? For python bindings, nope :) > I suggest we remove it from the package, but I must admit I don't know > if that breaks the binding. I don't think it will break the binding, bindings will use the .so file. Paul Gevers, on ven. 03 nov. 2017 22:22:40 +0100, wrote: > Another question. In Ubuntu they switched from asound to pulseaudio. Do > you think we should do the same? (I have no idea how to judge this, so > without your consent, I'd leave it as is). Well, I see the whole Debian moving to pulseaudio, so I guess it makes sense to follow, even if I personally don't like pulseaudio. Samuel
Re: sphinx* packages
Hi Samuel On 03-11-17 11:35, Paul Gevers wrote: > The current package of python-sphinxbase contains¹ a (unstripped!) > static library. Is that on purpose? If not, do you see a good reason to > keep it (stripped or unstripped)? I suggest we remove it from the > package, but I must admit I don't know if that breaks the binding. > > Paul > > ¹ https://packages.debian.org/sid/amd64/python-sphinxbase/filelist Another question. In Ubuntu they switched from asound to pulseaudio. Do you think we should do the same? (I have no idea how to judge this, so without your consent, I'd leave it as is). Paul signature.asc Description: OpenPGP digital signature
Re: sphinx* packages
Hi Samuel, The current package of python-sphinxbase contains¹ a (unstripped!) static library. Is that on purpose? If not, do you see a good reason to keep it (stripped or unstripped)? I suggest we remove it from the package, but I must admit I don't know if that breaks the binding. Paul ¹ https://packages.debian.org/sid/amd64/python-sphinxbase/filelist signature.asc Description: OpenPGP digital signature
Re: sphinx* packages
Paul Gevers, on ven. 03 nov. 2017 10:45:46 +0100, wrote: > Other than ENOTIME, is there a reason why you never added a symbols file > to the sphinxbase package? No other reason :) Samuel
Re: sphinx* packages
Hi Samuel, Other than ENOTIME, is there a reason why you never added a symbols file to the sphinxbase package? Paul signature.asc Description: OpenPGP digital signature
Re: sphinx* packages
Hi, On 03-11-17 09:45, Samuel Thibault wrote: > I'd say call them 0.8+5prealpha+1 and 1.0.8+5prealpha+1 I'll do that then. Paul signature.asc Description: OpenPGP digital signature
Re: sphinx* packages
Hi Samuel, On 03-11-17 09:41, Samuel Thibault wrote: > Hello, > > Paul Gevers, on ven. 03 nov. 2017 09:28:25 +0100, wrote: >> Current versions: >> sphinxbase 0.8+5prealpha >> sphinxtrain 1.0.8+5prealpha >> >> New versions: >> both 5prealpha > > IIRC, that 5prealpha version is what I packaged as 0.8+5prealpha and > 1.0.8+5prealpha, i.e. I considered that that "5prealpha" thing was a > one-shot mistake from upstream when they named their tarballs, so I kept > the previous version number and just appended +5prealpha. That is exactly what I suspected for a long time, so I wanted to at least fix the watch file. Then I discovered that the 5prealpha release happened AFTER you packaged those versions AND the tar ball is really different, so I concluded that upstream had a version like you had for a while. So how to name the current 5prealpha release? 0.8+5prealph+secondversion? Paul signature.asc Description: OpenPGP digital signature
Re: sphinx* packages
Samuel Thibault, on ven. 03 nov. 2017 09:41:27 +0100, wrote: > Paul Gevers, on ven. 03 nov. 2017 09:28:25 +0100, wrote: > > Current versions: > > sphinxbase 0.8+5prealpha > > sphinxtrain 1.0.8+5prealpha > > > > New versions: > > both5prealpha > > IIRC, that 5prealpha version is what I packaged as 0.8+5prealpha and > 1.0.8+5prealpha, So it seems they have released "another" 5prealpha under the same file name... I'd say call them 0.8+5prealpha+1 and 1.0.8+5prealpha+1 for now (if you look at the NEWS file the latest entry is still called 0.8, and it'd look weird to bump directly to 5, so I really guess it's a transitory versioning) Samuel
Re: sphinx* packages
Hello, Paul Gevers, on ven. 03 nov. 2017 09:28:25 +0100, wrote: > Current versions: > sphinxbase0.8+5prealpha > sphinxtrain 1.0.8+5prealpha > > New versions: > both 5prealpha IIRC, that 5prealpha version is what I packaged as 0.8+5prealpha and 1.0.8+5prealpha, i.e. I considered that that "5prealpha" thing was a one-shot mistake from upstream when they named their tarballs, so I kept the previous version number and just appended +5prealpha. Samuel
sphinx* packages
Hi, I am working on providing new upstream releases in Debian of sphinxbase and sphinxtrain. However, the upstream version looks weird to me, and I wonder if it is smart to just take it over. I won't like it if the next upstream version requires us to add an epoch. Current versions: sphinxbase 0.8+5prealpha sphinxtrain 1.0.8+5prealpha New versions: both5prealpha Luckily, 5prealpha sorts below 5.0 Debian version wise, but not below 5 (without a decimal point). paul@testavoira ~ $ dpkg --compare-versions 5prealpha lt 5 && echo 1 paul@testavoira ~ $ dpkg --compare-versions 5prealpha lt 5. && echo 1 1 paul@testavoira ~ $ dpkg --compare-versions 5prealpha lt 5.0 && echo 1 1 I could mangle the upstream version to 5~prealpha, but I don't think it is worth it, and also I am not sure if that is what upstream intended (jumping from 0.8/1.0 to 5). Does anybody have advise and/or an opinion on this? Paul signature.asc Description: OpenPGP digital signature
