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

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

On 01/01/16 23:51, Mattia Rizzolo wrote:
> On Fri, Jan 01, 2016 at 04:32:03PM +0000, Jose M Calhariz wrote:
>> On 31/12/15 12:42, Mattia Rizzolo wrote:
>>> * d/control:
>>>   + bump standards-version to the last policy release, 3.9.6
>>>     - this also requires adding stuff to d/rules.  maybe just use dh?
>>>   + canonicalize Vcs-* (for -Browser please use https)
>> Canonicalize?  Ha, I found an example on google.
>> Done.
> eheh.  btw, I actually find this a bit annoying.  The current alioth
> admin set up a bunch of redirects, but some are missing, and he said
> he's not going to add more, since there are already something like more
> then hundreds rewrite rules already in place...
> He's right, though.
>> Done
>>>   + please use dh-autoreconf (aka, #744619, you even have a patch!)
>> Modified the patch, but follow most of it.
> ok, but please add a DEP-3 header to the patch
> 0002-guess-stack-direction you added.


>>>   + can you use the short dh format?  (I can even live without, it's
>>>     just I prefer quite more dh over plain debhelper)
>> I have learned to use debhelper and dh does too many magic things for
>> me.  Until I
>> understand better how packaging works I will give priority to debhelper
>> over dh.
> ok, fine.
> I understand the point, that's the reason for which I kinda hate cdbs :)
> maybe I like dh because I read its sources and learned how to deal with
> it.
> If something particular concers you, please ask!

I decided to bite the bullet.  Upstream already have packaging work for
dh.  As his work is GPL2
I decided to merge it.

>>>   + for the 'version' variable, please use `dpkg-parsechangelog -S`
>>>     instead of sed
>> I don like sed too.  But the replacement is different because that
>> variable name "version"
>> is a misnomer.
> oh, I see.  I didn't notice you were sedding d/control and not
> d/changelog.  usually something similar (but more complex, really) it's
> used to get the current version of the package.
> Well, dh_listpackages is nicer than sed, yeah! :)
>> I am stuck on the next changes.  I will read documentation to understand
>> what better what I  need to do.
> please read and try to search and understand things, but if you're stuck
> just ask, if you're lucky you'll get directions, worst case somebody
> will drop you URLs ;)
>> Meanwhile I am publishing my changes to collab-maint
>> so anyone can review it.
> yeah, thanks, nice.
>>>   + I didn't really check, but do you really need to do such mess by
>>>     generating the .install files at build time?  seems, well... doesn't
>>>     *look* needed, at least.
>> It is an inheritante from the past.
> yeah, figured.  well, if you can understand what it really does maybe
> you can replace it by something nicer..

Done with the merge of packaging work from upstream.

>>> * you have a librep9.symbols, probably you should rename it, and update
>>>   to have the newer symbols, and remove the old ones.
>>> * please bump to debhelper compat 9
>>>   + this will also make (or at least help) make the lib multiarch-able
>>>     - for this to work you need to start using dh_auto_configure instead
>>>       of manual calling ./configure, though
>>>     - note that with this several .install will need an update
>>>     - I see you already had troubles with --host and --build configure
>>>       flags: 1) I wonder why you need --host at all, we are not
>>>       cross-compiling... 2) dh_auto_configure takes care of --build.
>>>     - suggestion: stop fiddling so much, and use dh + dh_auto_configure.
> multiarchifying a lib can be hard.  But I don't think this is going to
> be that hard.  If I were you I'd just try to use dh_auto_configure
> instead of plain ./configure call, and bump the debhelper compat.
> See https://wiki.debian.org/Multiarch/Implementation for some hints,
> note that that page has some outdated bits (but we all hate keeping docs
> up to date :( )

Did I get it right?

>>> * librep-dev.links => no, please.  linking /usr/share/doc/<pkg>
>>>   directory ain't nice at all, why is that in first place?

The file  librep-dev.links is gone, but the links are still present. I
don't know why :-(
>>>   + but if you don't want to change it now it's fine, note that just
>>>     removing it and let dh take care of it isn't enough, you need a
>>>     maintscript for that
>>>   + I see there already are preinst snippet to remove the directory.  my
>>>     reaction to this is: wtf?  it does so quite unconditionally and -.-'

I changed the maintscripts to something I think is more sane.

>>> * d/copyright:
>>>   + I'd appreciate a DEP-5 copyright format (but I can live without)
>>> * trailing whitespaces:
>>>   + d/rules:46
>>> it seems that this upload is going to start a library transition.
>>> If so, then you need to upload to experimental, and follow
>>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions or, am I missing
>>> something?
>> The only revert depends are the sawfish and rep-gtk.  But lets follow
>> the transitions guidelines and start by
>> uploading it to experimental.
> yes please.

Another iteration, can you please review it?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: