[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Hamlib package



Hi Ervin,

On Tue, Jul 17, 2018 at 10:55:50PM +0200, Ervin Hegedüs wrote:
> Anyway, I think it would be enough to build for only 3.6 XOR 3.7
> - which is also very hard; that's what I asked once, who made it
> before.

I have managed to get all the python3.x bindings packaged, but the
python3 test fail the 3.6, not the 3.7.

> > > W: libhamlib2++c2: package-name-doesnt-match-sonames libhamlib++2
> > > I don't know why and where comes this name conventions to Hamlib,
> > > but didn't wanted to change them.
> > I think it's the Debian policy regarding lib's naming convention.
> yes, I mean why is these are the names, that lintian drops the
> warnings for the names...

yes that's name is strange, maybe someone knows why it is not:
libhamlib2++ or python-hamlib2 etc.

> > Anyway, I think hamlib has the precedence here, if it's ok for you I
> > will continue to spend sometime on it?
> yes - the question is what sould we do?

Now all this need to be committed and checked.

> I wrote e-mail to @aeb, who asked me, don't push anything to
> salsa. But salsa is "just" an SCV, I think we can upload the
> Hamlib 3.2 to FTP - what I also can't do, because I'm in
> uploaders field (once @colin said me that I can put myself to
> there), therefore I can't upload the package as "team-upload",
> and I can't upload it as @airween, because I don't have
> permission for that package as uploader.
> We can align the state of salsa after we upload the new Hamlib
> version.

IMO the opposite, we fix and work in salsa until everything is ok, then
we tag it and deploy it (maybe in the future it will only need to tag
it: https://debconf18.debconf.org/talks/71-autodeploy-from-salsa/ )

Bye
E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi <e.rossi@tecnobrain.com>


Reply to: