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. Done > >>> + 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