Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
One more interation. On 08/02/16 21:57, Mattia Rizzolo wrote: > On Mon, Feb 08, 2016 at 09:29:55PM +0000, Jose M Calhariz wrote: >> Today I didn't review all yours remarks. But in the spirit of release >> early and release often here goes my today effort. > yay, I definitely approve this ;) > I hadn't gone deeper, just commented on your last changes here. > >> On 07/02/16 22:01, Mattia Rizzolo wrote: >>> On Sun, Feb 07, 2016 at 08:40:10PM +, Jose M Calhariz wrote: >>>> On 06/02/16 23:41, Mattia Rizzolo wrote: >>>>> Umh, couldn't you turn d/rules to use the dh sequencer? >>>> I don't know enough and lintian show many problems with upstream d/rules. >>> well, let's fix them, then :) >>> Attached there is a d/rules using short dh, may you try it and bend it >>> better to the needs of this package? >> I managed to make it compile, but for a reason I don't know I needed to >> add the following lines: >> >> override_dh_auto_configure: >> cp /usr/share/misc/config.guess . >> cp /usr/share/misc/config.sub . >> dh_auto_configure --parallel > that's so weird. > > even more in light of the new dh_update_autotools_config which is run > automatically by dh >= 9.20160114 and do exactly that. > Are you testing your package in an update sid chroot? > >> I have tried many ideas but was only this way that it build > also, it did build here without them. As you may see in d/rules, I found another workaround. This time I believe that is correct. >>>>> * d/copyright: consider write a copyright-format 1.0 one? at a first >>>>> sight doesn't look too much work. >>>> Done >>> though it's not compliant, and indeed lintian is noisy on it, please try >>> to figure out what's wrong with it and fix it. >>> I believe blindly following lintian here is enough, though it would be >>> nice if you could understand what's the problem by yourself :) >> I fix it, but I don't understand why :-) > ok, I'm going to assume you read all of > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and > somehow did not understand it. > > DEP-5 copyright is RFC 822-compliant file where there are basically 3 > types of paragraphs: > * the header paragraph => you know it > * the file paragraphs > * the stand alone license paragraphs > > the file paragraph is composed by at least > * Files: > * Copyright: > * License: > > in your earlier attempt at it you put a blank line between Copyright and > License, and de-facto created a separated pargraph, totally disconnected > from the previous one. That one by itself was a compliant stand alone > license paragraph, but > 1) it was repeated by another one later > 2) it was not refereced by a License: line from a file paragraph. > > > I hope I made the thing at least clearer. > >>>>> * please try to get a reproducible buildable package, from what I see it >>>>> wouldn't be difficult at all. > ♥ THANK YOU! :D > >>>>> there are 57 open bugs, are you telling me none of them get closed by >>>>> this upload? :\ > ok, I saw you added some closes: to the bug, and added a line to the > changelog saying that you closed those bugs. meh. > you should explicitly list what you are closing, briefly; probably the > best way is in a indented list, something like > * New upstream version. > + Fix blabla due to fofo. Closes: #x > + Fix ciaciaaicegow. Closes: #y > And adding to the changelog a sentence like "I closed bugs" is totally > useless, just remove it :) > I have reviewed all the bugs, so I am closing what I more certain that is fixed by 1.11. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
Hi, sorry for the long time. But I went to my home country.
In the usual palce there is my lastest interaction.
On 23/02/16 11:09, Mattia Rizzolo wrote:
> On Wed, Feb 17, 2016 at 11:43:14AM +, Mattia Rizzolo wrote:
>> On Wed, Feb 10, 2016 at 09:44:09PM +0000, Jose M Calhariz wrote:
>>> One more interation.
>> uops!
>>
>> This slipped off my sight, sorry for the delay! :|
>>
>>> On 08/02/16 21:57, Mattia Rizzolo wrote:
>>>> On Mon, Feb 08, 2016 at 09:29:55PM +, Jose M Calhariz wrote:
>>>>> Today I didn't review all yours remarks. But in the spirit of release
>>>>> early and release often here goes my today effort.
>>>> yay, I definitely approve this ;)
>>>> I hadn't gone deeper, just commented on your last changes here.
>>>>
>>>>> On 07/02/16 22:01, Mattia Rizzolo wrote:
>>>>>> On Sun, Feb 07, 2016 at 08:40:10PM +, Jose M Calhariz wrote:
>>>>>>> On 06/02/16 23:41, Mattia Rizzolo wrote:
>>>>>>>> Umh, couldn't you turn d/rules to use the dh sequencer?
>>>>>>> I don't know enough and lintian show many problems with upstream
>>>>>>> d/rules.
>>>>>> well, let's fix them, then :)
>>>>>> Attached there is a d/rules using short dh, may you try it and bend it
>>>>>> better to the needs of this package?
>>>>> I managed to make it compile, but for a reason I don't know I needed to
>>>>> add the following lines:
>>>>>
>>>>> override_dh_auto_configure:
>>>>> cp /usr/share/misc/config.guess .
>>>>> cp /usr/share/misc/config.sub .
>>>>> dh_auto_configure --parallel
>>>> that's so weird.
>>>>
>>>> even more in light of the new dh_update_autotools_config which is run
>>>> automatically by dh >= 9.20160114 and do exactly that.
>>>> Are you testing your package in an update sid chroot?
>>>>
>>>>> I have tried many ideas but was only this way that it build
>>>> also, it did build here without them.
>>> As you may see in d/rules, I found another workaround. This time I
>>> believe that is correct.
>> umh, that is so tautological and useless :)
>> So, you are telling dh_clean to remove those files in debian/clean, just
>> to leter tell it telling to *not* remove those 2 in debian/rules!
>>
>> Just remove those config.{sub,guess} from debian/clean, and it should be
>> just fine.
>> And while on it also remove 'configure' and 'libtool' from d/clean, no
>> need to remove them.
>> d/clean is to remove files created a build time and not cleaned up by
>> the build system, this is not the case here. And I have the impression
>> there are several other useless entries there.
>>
>> And while you are cleaning useless files up, now the
>> override_dh_auto_configure is useless too.
>>
>>
>> Then sawfish-lisp-source.dirs is empty, remove it;
>> and please check whether all the entries on sawfish.dirs are needed or
>> not; I can count on a single hand the occasions where a debian/*.dirs
>> file was really needed, remember that files copied by dh tools don't
>> need it.
>>
>>> I have reviewed all the bugs, so I am closing what I more certain that
>>> is fixed by 1.11.
>> cool!
>>
>>
>> In nearly 10 days of pause I forgot almose everything I wrote here…
>> I hope later today to be able to review everything again and provide you
>> with a list of stuff.
> actually, scratch these last lines.
> For me, just another thing (other than the above) and them I'm happy:
> please rename debian/manpages to debian/sawfish.manpages, for clarity.
>
>> I also saw you tried to do the symlink_to_dir thinghy, I'll check if
>> more is needed.
> the symlink_to_dir versions lack the epoch (the leading '1:' of the
> version).
>
> It seems otherwise fine to me.
>
signature.asc
Description: OpenPGP digital signature
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
On 29/02/16 23:09, Mattia Rizzolo wrote:
> sorry, this took awfully long.
>
> On Fri, Feb 05, 2016 at 11:09:20PM +0000, Jose M Calhariz wrote:
>> Amanda have release a new upstream version. My main sponsor is too
>> busy for helping me. So I am searching for someone that can help
>> sponsor the new release.
> Ok, I can do it.
Thank you.
> Should I use the git repository?
Yes. I just have upload one more patch to fix a nasty bug in amanda 3.3.8.
In the next days I will work through your task list.
> Just looking through cgit, I can ask you the following things:
>
> * https in Vcs-Git please
> * standards-version to 3.9.7
> * version restriction on tar can go away, and tar being essential:yes
> the whole dep can go away
> * are you sure the perl dep is needed? ${perl:Depends} ought to do it
> * guessing you are using git-buildpackage, why didn't you just
> `gbp import-dsc` to import the NMU?
> * please push the tag for the upstream part
> * you have a build-dep on debhelper version >= 9, but you use compat 5.
> please bump the compat, after checking the differences in debhelper(7)
> * the *.dirs files don't need to list directories for files installed by
> other dh_* things, so I'm confident at least line 3,4,5 of
> amanda-server.dirs are useless, haven't looked at the others
> * I'm not happy with the old style rules file, but guess I can't ask
> that much in this case, and I can live well with it anyway :)
>
> ↑ that's the kind of things I want to see changed for me to sponsor it.
> If you confirm I should look at the git repository and you're ok with me
> as a sponsor please confirm so (and fix the already reported problems,
> please ;))
>
Kind regards
Jose M Calhariz
signature.asc
Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
On 28/02/16 23:00, Mattia Rizzolo wrote: > On Wed, Feb 24, 2016 at 09:41:32PM +0000, Jose M Calhariz wrote: >> In the usual palce there is my lastest interaction. > ok. > > Today I had a look at the symlink_to_dir things closer. > The one for sawfish-lisp-source doesn't seem to work. the file is named > .maintscripts instead of .maintscript > After that all the upgrades I tested worked correctly. Corrected. > > more: > > * sawfish-list-source.postinst is a nop, please remove it Done > * sawfish-lisp-source.dirs : empty, please remove it Done > * I just noticed sawfish.preinst removes /var/lib/sawfish that you are > creating in sawfish.dirs. ??? I believe the directory /var/lib/sawfish is necessary. So cleaning sawfish.preinst > * d/clean still contains libtool, please drop that line from d/clean Done > * in d/rules, is the ACLOCAL variable still needed? if not get rid of > it (test building without works) I tried to used automake instead of automake1.11 and worked for my machine (i386). > > after this, back to what lintian knows: > > * spelling-error-in-changelog unusuable unusable This is a misspell on the bug report title, so preserving the error and add an lintian-override for it. I will work on the following tomorrow. > * non-empty-dependency_libs-in-la-file + incorrect-libdir-in-la-file > these are caused just because of a typo in the target name of > override_dh_auto_install; I'll let you discover the typo and fix it. > * sawfish: maintainer-script-without-set-e (all the maintscripts) > * sawfish-lisp-source: script-not-executable > usr/share/sawfish/lisp/sawfish/cfg/main.jl > there actually is an override, but the file is named wrongly and so > not picked up by dh_lintian. maybe you also want to add an override > for the sawfish-data one. > > I'd ignore the rest of the complains from lintian and blhc for now, tbh. > > > signature.asc Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
One more iteration. On 01/03/16 22:35, Mattia Rizzolo wrote: > On Tue, Mar 01, 2016 at 09:11:58PM +0000, Jose M Calhariz wrote: >> On 28/02/16 23:00, Mattia Rizzolo wrote: >>> On Wed, Feb 24, 2016 at 09:41:32PM +0000, Jose M Calhariz wrote: >>> * I just noticed sawfish.preinst removes /var/lib/sawfish that you are >>> creating in sawfish.dirs. ??? >> I believe the directory /var/lib/sawfish is necessary. So cleaning >> sawfish.preinst > ok. > >>> * in d/rules, is the ACLOCAL variable still needed? if not get rid of >>> it (test building without works) >> I tried to used automake instead of automake1.11 and worked for my >> machine (i386). > As a QA guy I like when I see old stuff being dropped from the archive, > so also avoiding hardcoding and fixing with automake1.11 will also help > remove automake1.11 when the time will come :) > >>> after this, back to what lintian knows: >>> >>> * spelling-error-in-changelog unusuable unusable >> This is a misspell on the bug report title, so preserving the error and >> add an lintian-override for it. > brr, how ugly! > > no, please revert that commit, retitle the bug report if you care and > fix the typo in the changelog. Also, there is no need at all that the > changelog entries for bug fix are the same of the bug reports... > Surely the most nice thing would be to retitle the bug report and fix > the changelog, adding a lintian override is just plain wrong here. I misread the title of the bug report, so you are right. >> I will work on the following tomorrow. > Thanks for showing the progress, appreciated as usual :) > >>> * non-empty-dependency_libs-in-la-file + incorrect-libdir-in-la-file >>> these are caused just because of a typo in the target name of >>> override_dh_auto_install; I'll let you discover the typo and fix it. Done. >>> * sawfish: maintainer-script-without-set-e (all the maintscripts) I don't get that error and my lintian is updated. >>> * sawfish-lisp-source: script-not-executable >>> usr/share/sawfish/lisp/sawfish/cfg/main.jl >>> there actually is an override, but the file is named wrongly and so >>> not picked up by dh_lintian. maybe you also want to add an override >>> for the sawfish-data one. Done > > signature.asc Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
One more iteraction. This time I centred on cleaning or overriding lintian messages. On 04/03/16 16:07, Mattia Rizzolo wrote: > On Thu, Mar 03, 2016 at 08:37:37PM +0000, Jose M Calhariz wrote: >>>>> * sawfish: maintainer-script-without-set-e (all the maintscripts) >> I don't get that error and my lintian is updated. > That's maybe because you don't ask lintian to show you pedantic tags > too. I personally have this ~/.lintianrc (to avoid having to type the > flags every time): > info=yes > display-info=yes > display-experimental=yes > pedantic=yes > show-overrides=no > color=always > equivalent flags are "-EIi --pedantic --color always" > > anyway, just try > lintian-info -t maintainer-script-without-set-e > to see what you should do, it's fairly simple to understand and action. > signature.asc Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
Ok, this time I overdo it. On 05/03/16 15:13, Mattia Rizzolo wrote: > On Fri, Mar 04, 2016 at 09:17:45PM +0000, Jose M Calhariz wrote: >> One more iteraction. This time I centred on cleaning or overriding >> lintian messages. > umh 3cb664996f1694f8b72eb42c45ef4ef970f4998c > > 1) "Don't know where is the public key." — you of course you can find it > in any keyserver…, so it should be > https://sks-keyservers.net/pks/lookup?op=get&search=0xB60C068FC61670EE > Then there is always the trouble of trusting that's really theirs, but > this is another story The key I am looking is 0x2BF6893F36C73306. > 2) 'opts="pgpsigurlmangle=s%$%.sha256.sig%"' is not going to work > anyway, since uscan expects the signature to sign the tarball, while > that's the signature of the sha256 hash of the tarball Once I have the key, I will ask upstream to sign the tarball and the checksum. > 3) this is not a thing to override since >a) somebody says overriding lower than warning tags is excessive (I > personally don't agree here, just bringing a datapoint) >b) you override wrong tags (false positive) or tags that for some > reason could never be fixed, not just to hide them >the correct action here is really to leave it as it is, maybe asking >upstream to start signing the tarballs instead of checksum. > Is now OK? Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
On 29/02/16 23:09, Mattia Rizzolo wrote:
> sorry, this took awfully long.
>
> On Fri, Feb 05, 2016 at 11:09:20PM +0000, Jose M Calhariz wrote:
>> Amanda have release a new upstream version. My main sponsor is too
>> busy for helping me. So I am searching for someone that can help
>> sponsor the new release.
> Ok, I can do it.
> Should I use the git repository?
Yes please.
> Just looking through cgit, I can ask you the following things:
>
> * https in Vcs-Git please
Done
> * standards-version to 3.9.7
Done
> * version restriction on tar can go away, and tar being essential:yes
> the whole dep can go away
Done
> * are you sure the perl dep is needed? ${perl:Depends} ought to do it
Done
> * guessing you are using git-buildpackage, why didn't you just
> `gbp import-dsc` to import the NMU?
My changes are older than the NMU. So I did not tried to import the NMU.
> * please push the tag for the upstream part
Done
> * you have a build-dep on debhelper version >= 9, but you use compat 5.
> please bump the compat, after checking the differences in debhelper(7)
Done
> * the *.dirs files don't need to list directories for files installed by
> other dh_* things, so I'm confident at least line 3,4,5 of
> amanda-server.dirs are useless, haven't looked at the others
The debian/rules relies on cp and install to copy the files into the
directories listed in *.dirs
I don't like, I would prefer the format:
mkdir $dir && cp $file $dir
What you recomend?
> * I'm not happy with the old style rules file, but guess I can't ask
> that much in this case, and I can live well with it anyway :)
Thank you. This package is being tested on my backup server for some
weeks. I don't want
to make changes that may invalidate my tests. The version 3.3.9 is all
ready available and I
can change the rules style for amanda 3.3.9.
>
> ↑ that's the kind of things I want to see changed for me to sponsor it.
> If you confirm I should look at the git repository and you're ok with me
> as a sponsor please confirm so (and fix the already reported problems,
> please ;))
>
This is for today.
Tomorrow I will look into "lintian -I --pedantic"
KInd regards
Jose M Calhariz
signature.asc
Description: OpenPGP digital signature
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
One more iteration.
On 09/03/16 20:11, Mattia Rizzolo wrote:
> On Mon, Mar 07, 2016 at 09:27:20PM +0000, Jose M Calhariz wrote:
>> On 29/02/16 23:09, Mattia Rizzolo wrote:
>>> * guessing you are using git-buildpackage, why didn't you just
>>> `gbp import-dsc` to import the NMU?
>> My changes are older than the NMU. So I did not tried to import the NMU.
> umh, yes, otherwise you'd have needed to the re-apply the commits on top
> of the import.
>
>>> * the *.dirs files don't need to list directories for files installed by
>>> other dh_* things, so I'm confident at least line 3,4,5 of
>>> amanda-server.dirs are useless, haven't looked at the others
>> The debian/rules relies on cp and install to copy the files into the
>> directories listed in *.dirs
>> I don't like, I would prefer the format:
>> mkdir $dir && cp $file $dir
>>
>> What you recomend?
> there are several reasons to prefer using dh_* tools to do that.
> for the basic example of `mkdir $dir && cp $file $dir` the better way to
> do it is to add a .install file with just '$file $dir' and it'll just do
> the work.
>
> That said, I'm now sure that you don't need those lines (as in, I
> removed them and it just works, after moving to dh_lintian(1)).
>
> please try to have a look at all of the things in *.dirs and see if
> really them all are needed. there are not many install(1) or cp(1) or
> mv(1) calls that needs them (sure, there are other things that do,
> though).
I managed to remove some lines from *.dirs.
>
>>> * I'm not happy with the old style rules file, but guess I can't ask
>>> that much in this case, and I can live well with it anyway :)
>> Thank you. This package is being tested on my backup server for some
>> weeks. I don't want
>> to make changes that may invalidate my tests. The version 3.3.9 is all
>> ready available and I
>> can change the rules style for amanda 3.3.9.
> ok.
> Just, I'd love to show you that several stuff you do manually can be
> instead done by some tools that are already there since a lot of times
> and really do the job.
> * cp of config.{sub,guess}: there is dh_autotools_dev since a lot of
> times, since mid-January there is the "native"
> dh_update_autotools_config(1) which is also run automatically by
> dh(1)
> * some of the stuff done in the clean target are done by
> dh_auto_clean(1)
> * that cp ChangeLog should already be done automatically by
> dh_installchangelogs(1)
> * all those lines to install lintian should be just done by
> dh_lintian(1) (just rename the *.lintian to *.lintian-overrides); for
> avoidance of doubts, this one thing I want to see changed, the other
> can wait for the time you'll rewrite the thing :)
>
>> This is for today.
> yeah, one step at time.
>
> Some more things from d/rules:
>
> * that $(shell pwd) can be $(CURDIR)
Done
> * you should remove the config.{sub,guess} you copy over
Done
> * what's that "source diff" target?? seams some old things that does
> nothing now, maybe it can be removed?
Done
> * do you know why dh_makeshlibs is called with --noscripts?
It silence a lintian warning "amanda-common:
postinst-has-useless-call-to-ldconfig"
> * the -l of that dh_shlibdeps should be uneeded.
Done
> * that fiddling with substvars seems to be uneeded: whilst something
> does put amanda-common in *.substvars in shlibs:Depends, something
> else in dpkg merges that dependency with what you already specify in
> d/control and keeps the one more restrictive (the versioned one you
> specify in d/control) => 4 lines less.
Done
> * on a site note, do you know that the nice thing of using variables
> with only one letter in a makefile makes possible to just use $c
> instead of $(c) ? :)
I don't like that and I don't like this 3 variable names, so they will
go away on next upstream release.
>
> more:
>
> * d/copyright looks outdated, at least with regards to years. Also, I'd
> love to see a DEP-5 compliant copyright file
I don't know how to identify what license is used on Amanda.
I don't know what license was used to create the debian package. Should
I contact the previous
DD that worked on this?
> * may you rename d/docs to d/amanda-common.docs, just for clearity?
Done
> * please add DEP-3 compliant headers to the patches lacking it, it's
> otherwise uneededly difficult to understand what a patch is for (and
> also just "Description: fix blalba." is annoying, really some
> description ought to be loger with a sequel "by changi
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
On 28/03/16 15:21, Mattia Rizzolo wrote: > Is there something blocking on this? > (gentle ping) > I had no reply from Bdale. I will try again. (Simple pong) :-) Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
On 28/03/16 15:21, Mattia Rizzolo wrote: > Is there something blocking on this? > (gentle ping) > Everything sorted out, and the last changes were pushed to the git repo. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Problem with dh_installman: usr/share/man/man8/amadmin.8: No such file or directory at /usr/bin/dh_installman line 131.
Hi, I am changing the rules of the package amanda to debhelper 9 and I am stopped in a problem with dh_installman. I have checked what I know and everything is correct. But still I think that is something obvious that I am missing. Possibly the manpages have an error in nroff code. The tail of the debuild is: dh_installman install -d debian/amanda-server/usr/share/man/man1/ install -p -m0644 debian/activate-devpay.1 debian/amanda-server/usr/share/man/man1/activate-devpay.1 usr/share/man/man8/amadmin.8: No such file or directory at /usr/bin/dh_installman line 131. debian/rules:39: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc -i -ICVS -I.svn failed The draft of the new package is available on: https://anonscm.debian.org/git/collab-maint/amanda.git What is my mistake? Kind regards Jose M Calhariz -- -- Frase de para-choque de caminhao: Mulher bonita eh que nem melancia grande, ninguem come sozinho. signature.asc Description: Digital signature
Re: Problem with dh_installman: usr/share/man/man8/amadmin.8: No such file or directory at /usr/bin/dh_installman line 131.
Thank you to both of you: - Andreas Metzler - Sven Joachim Now I have progressed, into another problem. But is another email, If I can not find the solution by my self. Thank you Jose M Calhariz On Sun, Jul 31, 2016 at 07:58:05PM +0200, Andreas Metzler wrote: > Jose M Calhariz wrote: > > I am changing the rules of the package amanda to debhelper 9 and I am > > stopped in a problem with dh_installman. I have checked what I know > > and everything is correct. But still I think that is something > > obvious that I am missing. Possibly the manpages have an error in > > nroff code. > > > The tail of the debuild is: > > >dh_installman > > install -d debian/amanda-server/usr/share/man/man1/ > > install -p -m0644 debian/activate-devpay.1 > > debian/amanda-server/usr/share/man/man1/activate-devpay.1 > > usr/share/man/man8/amadmin.8: No such file or directory at > > /usr/bin/dh_installman line 131. > [...] > > https://anonscm.debian.org/git/collab-maint/amanda.git > [...] > > Hello, > > (sid)ametzler@argenau:/tmp/FLANN/amanda-3.3.9$ find -name amadmin.8 > ./man/amadmin.8 > ./debian/tmp/usr/share/man/man8/amadmin.8 > > If you want to install this manpage with dh_installman you'll need to > list > debian/tmp/usr/share/man/man8/amadmin.8 > instead of > usr/share/man/man8/amadmin.8 > in debian/amanda-server.manpages. > > dh_installman does not search below debian/tmp as dh_install does. In > my personal experience it is mainly useful for manpages which are not > installed by "make install", e.g. Debian provided manpages in debian/. > I would suggest to install manpages which are handled by "make > install" with dh_install instead. > > BTW I think you are missing > --- a/debian/rules > +++ b/debian/rules > @@ -36,7 +36,7 @@ confflags = --prefix=/usr \ > --enable-s3-device > > %: > - dh $@ --parallel > + dh $@ --with autoreconf --parallel > > override_dh_auto_configure: > dh_auto_configure -- $(confflags) > > hth, cu Andreas > > -- -- Frase de para-choque de caminhao: Mulher bonita eh que nem melancia grande, ninguem come sozinho. signature.asc Description: Digital signature
RFS: sawfish, rep-gtk, librep ITA
A long time ago I tried to adopt sawfish and is build-depends. But my main sponsor being too busy for helping me. So I am searching for someone that can help sponsor the packages, close the ITA and help me fix the last bits for making the packages fit for Debian. The packages are very old. I can't update sawfish without updating it's build-depends. The latest changes are on collab-maint. I am reviewing the packages one more time. So expect more small changes. * Package name: librep Version : 0.92.5-1 Upstream Author : Christopher Bratusek * URL : http://download.tuxfamily.org/librep/ * License : GPL Section : lisp * Package name: rep-gtk Version : 1:0.90.8.2-1 Upstream Author : Christopher Bratusek * URL : http://download.tuxfamily.org/librep/rep-gtk/ * License : GPL Section : lisp * Package name: sawfish Version : 1:1.11-1 Upstream Author : John Harper, Christopher Bratusek * URL : http://download.tuxfamily.org/sawfish/ * License : GPL Section : x11 Kind regards Jose M Calhariz -- -- Toda sociedade tem os adolescentes que merece. -- J. B. Priestley signature.asc Description: Digital signature
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
Package: sponsorship-requests Severity: normal A long time ago I tried to adopt sawfish and is build-depends. But my main sponsor being too busy for helping me. So I am searching for someone that can help sponsor the packages, close the ITA and help me fix the last bits for making the packages fit for Debian. The packages are very old. I can't update sawfish without updating it's build-depends so starting with librep. The latest changes are on collab-maint and being tested in two of my PC for since August. * Package name: librep Version : 0.92.5-1 Upstream Author : Christopher Bratusek * URL : http://download.tuxfamily.org/librep/ * License : GPL Section : lisp -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pt_PT@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Re: RFS: sawfish, rep-gtk, librep ITA
On Wed, Dec 30, 2015 at 05:57:42PM +, Mattia Rizzolo wrote: > On Wed, Dec 30, 2015 at 05:30:50PM +0000, Jose M Calhariz wrote: > > A long time ago I tried to adopt sawfish and is build-depends. > > cool :) (as in: nice to see something adopting packages) > > > But my > > main sponsor being too busy for helping me. > > looking up your DDPO page seems like those ITA are the only things > related to you? do you use another email for the rest of your debian > work, maybe? > https://qa.debian.org/developer.php?email=jose.calha...@tecnico.ulisboa.pt I have used some addresses during the years, look into my PGP Key, to see how many address I have and most of them being used for Debian. Now I am collapsing into: jose.calhariz(AT)tecnico.ulisboa.pt for mailing-lists and jose(AT)calhariz.com for packaging work. > > > So I am searching for > > someone that can help sponsor the packages, close the ITA and help me > > fix the last bits for making the packages fit for Debian. > > sure, but please, file separate RFS *bugs* (against sponsorship-requests > pseudo-package, as usual) > > > The packages are very old. I can't update sawfish without updating > > it's build-depends. The latest changes are on collab-maint. I am > > reviewing the packages one more time. So expect more small changes. > > ok, so file the RFSes, maybe making one block another if that's the > case, once ready. > > I see the changes in librep and rep-gtk git repositories are from > August, if I'm going to sponsor those packages I'd ask to update the > changelog date, at least :) > Also, when I sponsor stuff from git I require something gpg signed (a > commit is fine), otherwise please upload the packages to mentors.d.n. > > > Thank you for your work! > (and sorry, but traking sponsorship requests by simple email in this ML > is hard, it can sometimes become crowded and difficult to follow, also, > when the sponsorship process gets stuck somehow, it's going to just be > forgotten (and, asking the upload of 3 packages in a single email isn't > really easy to follow up...) > Currently working on librep, open Bug#809451. In case you are interested. Kind regards Jose M Calhariz -- -- A utopia e o derradeiro reduto dos que não desesperaram da liberdade. -- Tristao de Ataide Alceu Amoroso Lima signature.asc Description: Digital signature
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
Replying inline: On 31/12/15 12:42, Mattia Rizzolo wrote: > control: tag -1 moreinfo > control: owner -1 ! > > On Wed, Dec 30, 2015 at 08:00:11PM +0000, Jose M Calhariz wrote: >> So I am searching for >> someone that can help sponsor the packages, close the ITA and help me >> fix the last bits for making the packages fit for Debian. >> >> The packages are very old. I can't update sawfish without updating >> it's build-depends so starting with librep. The latest changes are >> on collab-maint and being tested in two of my PC for since August. > ok, there a bunch of things I'd like to see before uploading this. > > * 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. > * use source/format 3.0 (quilt) > + so drop quilt build-dep > + and also the include in d/rules can go > + note: I won't upload stuff without d/source/format without a very > good reason. Done. > * d/README.source is outdated. moreover if you move to 3.0 (quilt) you > can just drop it. Done > * d/rules: > + the DEB_BUILD_OPTIONS thing about noopt can go, afaik dpkg takes > care of it nowadays Done > + please use dh-autoreconf (aka, #744619, you even have a patch!) Modified the patch, but follow most of it. > + 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. > + 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. I am stuck on the next changes. I will read documentation to understand what better what I need to do. Meanwhile I am publishing my changes to collab-maint so anyone can review it. > + 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. > * 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. > * librep-dev.links => no, please. linking /usr/share/doc/ > directory ain't nice at all, why is that in first place? > + 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 -.-' > * 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. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
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. 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/ >>> 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 remo
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
On 03/01/16 13:21, Mattia Rizzolo wrote: > ok, let's have a look at today's work :) > > On Sat, Jan 02, 2016 at 08:03:53PM +0000, Jose M Calhariz wrote: >> I decided to bite the bullet. Upstream already have packaging work for >> dh. As his work is GPL2 >> I decided to merge it. > oh, cool. > some things (the number is the line number): > > 2: #DH_VERBOSE = 1 > > well, not sure if without export it works the same, but I always saw > this with an export. furthermore, don't feel obliged to keep it > commented out, if you like verbose stuff in your build log, enable it :) You are right, the export keyword is very common here. I am commenting because currently I am not debugging the packaging. So I choose less verbose builds. > > 4: DPKG_EXPORT_BUILDFLAGS = 1 > 5: include /usr/share/dpkg/default.mk > > these are unneded, starting from debhelper compat 9 dh and dh_auto_* > exports them. See debhelper(7) for more info. Please consider removing > them. Done. > 9: DEB_PREF = $(shell gcc -print-multiarch) > > umh... just use DEB_HOST_MULTIARCH instead ? Done. > > 23: sm := $(shell grep '^Package: librep[0-9]' debian/control | sed -e > 's@^Package: librep\([0-9][0-9]*\).*@\1@' ) > > umh, what about: > sm := $(shell dh_listpackages|grep 'librep[0-9]\+') > and then use '$(sm)' instead of 'librep$(sm)' in the rules file? I don't like the name sm, so used libname instead and dh_listpackages | grep librep | head -n 1. Done. > 26:dh $@ --with autotools-dev --with autoreconf > > using both autotools-dev and autoreconf is usually just plain wrong. > with that also please remove the build-dep on autotools-dev. > See https://wiki.debian.org/Autoreconf for more info. Done > > 32:dh_auto_configure -- $(shell dpkg-buildflags --export=configure) > $(DEB_CONFIGURE_USER_FLAGS) > > that's the same as above, ther is no need to manually invoke > dpkg-buildflags starting from compat level 9 Done. > > 43: override_dh_auto_install: > 44: dh_auto_install > 45: dh_install > > instead please override only dh_install, no need to override > dh_auto_install. Not certain I have done the right thing here. But I tested and did not change a thing. > Now, the rest of the build stuff still looks unnecessarily complex, but > it's better than before. maybe I'll try to semplify it locally over the > next days. > > >>>>> * 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? > looks good to me. though I see there are files like > ./usr/lib/x86_64-linux-gnu/rep/rules.mk > that might be used by other packages. > but if that one is a makefile, why is it under /usr/lib ? > > I need to try a piuparts run, and see if everything is right. > Since there are only two r-deps once this package is more ready I'll try > to build them against this, to see if this multi-lib change affects > them. And I intended to adopt that two r-deps. What should make it easier. > >>>>> * librep-dev.links => no, please. linking /usr/share/doc/ >>>>> 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 :-( > those links are caused by the --link-doc option of dh_installdocs. > well, I'm not a fan of --link-doc, I really see too little point in it, >
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
Pushed. On 04/01/16 16:54, Mattia Rizzolo wrote: > sure, no worries :) > > On Mon, Jan 4, 2016 at 4:47 PM José M Calhariz wrote: > >> Sorry, I will push when arrive at home. >> >> On 4 January 2016 16:41:15 GMT+00:00, Mattia Rizzolo >> wrote: >>> On Sun, Jan 03, 2016 at 08:23:34PM +, Jose M Calhariz wrote: >>> >>>> Another iteration. >>>> >>> umh, can you push? >>> >>> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> signature.asc Description: OpenPGP digital signature
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
On 09/01/16 17:50, Mattia Rizzolo wrote: > On Sat, Jan 09, 2016 at 05:06:16PM +0000, Jose M Calhariz wrote: >> One more iteraction. > oh, this is getting cooler and cooler :) > >> On 07/01/16 14:31, Mattia Rizzolo wrote: >>> On Sun, Jan 03, 2016 at 08:23:34PM +, Jose M Calhariz wrote: >>>> On 03/01/16 13:21, Mattia Rizzolo wrote: >>>>> looks good to me. though I see there are files like >>>>> ./usr/lib/x86_64-linux-gnu/rep/rules.mk >>>>> that might be used by other packages. >>>>> but if that one is a makefile, why is it under /usr/lib ? >>>>> >>>>> I need to try a piuparts run, and see if everything is right. >>>>> Since there are only two r-deps once this package is more ready I'll try >>>>> to build them against this, to see if this multi-lib change affects >>>>> them. >>>> And I intended to adopt that two r-deps. What should make it easier. >>> Indeed, I'll probably double check this particular bit another day. >>> >>> Given that now librep16 is multiarch-able, you should add a >>> 'Multi-Arch: same' field in d/control for it. >> Done. > I'm going to try rebuilding the rdeps in the later today or tomrrow, and > I'll report back the results. Ok. >> I found the problem, Done. > woo :D > > OK, if the r-deps check I'm going to do will succeed I think we're good > to upload. :) > > just two more points: > > I find d/chaneglog to be somewhat a lot verbose. I think it's too much > verbose and also contains nowadays outdated bits (e.g. "Replace sed by > something more easy to read for variable version on debian/rules" is > just useless, also considering that line now doesn't exist anymore at > all! that's just an example, I can see more). So if I were you I'd > try to re-read the whole changelog and make it more easy and useful. I have trimed the changelog. Is not yet very good, but I hope that is good enough. And I will talk with upstream about this things. > The following lines are from check-all-the-things. > The first chunk shows there is a typo in debian/changelog, you might > want to fix it. Then I ask you to please forward all the rest > (typos or such, and outdated GPL-2+ text) upstream. > > $ codespell --quiet-level=3 > ./Makedefs.in:105: dependancy ==> dependency > ./ChangeLog:723: usefull ==> useful > ./ChangeLog:870: usefull ==> useful > ./configure:4647: nto ==> not | disable due to \n > ./configure:7545: nto ==> not | disable due to \n > ./configure:7695: nto ==> not | disable due to \n > ./configure:8963: nto ==> not | disable due to \n > ./configure:9998: nto ==> not | disable due to \n > ./config.sub:1403: nto ==> not | disable due to \n > ./NEWS:108: occured ==> occurred > ./NEWS:376: usefull ==> useful > ./aclocal.m4:106: occurence ==> occurrence > ./debian/changelog:163: Miscelaneous ==> Miscellaneous > ./intl/localealias.c:93: loosing ==> losing > ./intl/dcgettext.c:174: loosing ==> losing > ./intl/dcgettext.c:246: defintion ==> definition > ./m4/libtool.m4:2727: nto ==> not | disable due to \n > ./m4/libtool.m4:3317: nto ==> not | disable due to \n > ./m4/libtool.m4:3961: nto ==> not | disable due to \n > ./m4/libtool.m4:4117: nto ==> not | disable due to \n > ./m4/libtool.m4:4283: nto ==> not | disable due to \n > ./m4/libtool.m4:4434: nto ==> not | disable due to \n > ./m4/libtool.m4:5382: nto ==> not | disable due to \n > ./m4/libtool.m4:6581: nto ==> not | disable due to \n > ./src/streams.c:618: upto ==> up to > ./src/unix_main.c:452: Dont ==> Don't > ./src/sdbm.c:81: seperate ==> separate > ./src/README.sdbm:294: puting ==> putting > ./man/repl.texi:3: enviroment ==> environment > ./man/repl.texi:6: enviroment ==> environment > ./man/lang.texi:790: upto ==> up to > ./man/lang.texi:1414: sence ==> sense, since > ./man/lang.texi:4828: contruction ==> construction > ./man/lang.texi:4964: refered ==> referred > ./man/lang.texi:5098: Ususally ==> Usually > ./man/lang.texi:7300: upto ==> up to > ./man/lang.texi:9367: seperated ==> separated > ./man/lang.texi:9368: seperated ==> separated > ./man/news.texi:83: positon ==> position > ./man/news.texi:109: occured ==> occurred > ./man/news.texi:379: usefull ==> useful > ./lisp/rep/vm/assembler.jl:27: inbetween ==> between > > > $ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect > FSF address' > ./i
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
One more iteraction. On 07/01/16 14:31, Mattia Rizzolo wrote: > On Sun, Jan 03, 2016 at 08:23:34PM +0000, Jose M Calhariz wrote: >> On 03/01/16 13:21, Mattia Rizzolo wrote: >>> 43: override_dh_auto_install: >>> 44: dh_auto_install >>> 45: dh_install >>> >>> instead please override only dh_install, no need to override >>> dh_auto_install. >> Not certain I have done the right thing here. But I tested and did not >> change a thing. > yeah, it doesn't change the outcome, but it's 1) one line less in > d/rules and 2) more correct. > >>>>> 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? >>> looks good to me. though I see there are files like >>> ./usr/lib/x86_64-linux-gnu/rep/rules.mk >>> that might be used by other packages. >>> but if that one is a makefile, why is it under /usr/lib ? >>> >>> I need to try a piuparts run, and see if everything is right. >>> Since there are only two r-deps once this package is more ready I'll try >>> to build them against this, to see if this multi-lib change affects >>> them. >> And I intended to adopt that two r-deps. What should make it easier. > Indeed, I'll probably double check this particular bit another day. > > Given that now librep16 is multiarch-able, you should add a > 'Multi-Arch: same' field in d/control for it. Done. >>>>>>> * librep-dev.links => no, please. linking /usr/share/doc/ >>>>>>> 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 :-( >>> those links are caused by the --link-doc option of dh_installdocs. >>> well, I'm not a fan of --link-doc, I really see too little point in it, >>> int this case you just save some kB, just gaining troubles. >>> But give that the current state of librep is a mixed (every binary have >>> linked docs to librep9, except rep-doc), I'll leave the choice to you. >>> Your choises are: >>> * remove --link-doc for rep-doc, then you can just go on >>> * remove --link-doc altogether, then you need a bunch of .maintscript >>> files (see dh_installdeb(1) and dpkg-maintscript-helper(1) >> I will do this. But need time to reread the docs. Moved to TODO file. > I tried to do this, you can find attached a patch that seems to do this > transition correctly. Done. > >>>>>>> + 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. >>> I'm not sure what would be the idea behind librep16.preinst ? why do you >>> remove the symlink of librep9 ? >>> I haven't tried, but I think that directory goes away when deinstalling >>> librep9? > yes it does. So, can you explain why you did that? Removed the librep16.preinst > > > Something more: > > * d/copyright: > + there are 3 spurious line on top, not adhering to DEP-5, also they > are redundant. Please move Mikolaj email address to the debian/* > stanza and remove the lines Done > > + umh, is the Upstream-Name really 'sawfish'? Isn't it 'rep'? Done. > * d/control: > + vcs-field-not-canonical — please fix it Done > * is there a way to fix debian-rules-ignores-make-clean-error ? > > I found the problem, Done. signature.asc Description: OpenPGP digital signature
Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]
On 09/01/16 21:07, Mattia Rizzolo wrote: > On Sat, Jan 09, 2016 at 06:57:08PM +0000, Jose M Calhariz wrote: >>> I'm going to try rebuilding the rdeps in the later today or tomrrow, and >>> I'll report back the results. >> Ok. > that clearly fails because the header moved from e.g. rep.h => > rep/rep.h. > Well, guess thtat's expected, also the two rdeps come from the same > project so well, guess we're just going to upload this to experimental, > and prepare the 2 rdeps later (that you said you're going to adopt, > actually you own only 1 ITA, btw). Fixed the ITA. > >> I have trimed the changelog. Is not yet very good, but I hope that is >> good enough. > that's quite up to you, except some bits. > the rewrite of d/copyright using copyright-format-1.0 should be > documented, the rest looks documented enough to me. > >> And I will talk with upstream about this things. > cool. > > > ok, once you do this I'll upload, and we shall go one with one r-dep, > I'd say, wouldn't you? :) > The next r-dep neads to be rep-gtk, the sawfish needs the newer versions of librep and rep-gtk. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep
Package: sponsorship-requests Severity: normal A long time ago I tried to adopt sawfish and is build-depends. But my main sponsor being too busy for helping me. So I am searching for someone that can help sponsor the packages, close the ITA and help me fix the last bits for making the packages fit for Debian. The packages are very old. I can't update sawfish without updating it's build-depends. The latest changes are on collab-maint. I am reviewing the packages one more time. So expect more small changes. * Package name: rep-gtk Version : 1:0.90.8.2-1 Upstream Author : Christopher Bratusek * URL : http://download.tuxfamily.org/librep/rep-gtk/ * License : GPL Section : lisp -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep
Sorry for taking a long time to reply, adding my delay I had email problems. On Thu, Jan 14, 2016 at 12:13:29AM +, Mattia Rizzolo wrote: > On Wed, Jan 13, 2016 at 07:12:38PM +0000, Jose M Calhariz wrote: > > * Package name: rep-gtk > > ok, let the party begin! :) > > * you removed a old transition package. > + \o/ yay less cruft in the archive! > + FYI, I confirmed by `dak rm -Rbn rep-gtk-gnome` that it is a leaf > package. > + also please remove debian/rep-gtk-gnome.NEWS Done > * debian/control: > + a version costriction in a Suggest is really useless. As in, you > have no assurances *at all* that it'll be followed. > But then, you build-dep on librep >= $version, so you'll get a > depends on that version, so not all might be lost :) > tl;dr: you don't need to do anything here, but be aware that > versioned Suggests are meaningless. > + the build-dep on autotools-dev is useless, please remove it. Done > + I still get vcs-field-not-canonical by lintian. indeed Vcs-Git is > wrong (there is a /git/ too much in the middle). otherwise, you > might want to use https:// for Vcs-Git too instead of the dumb > git://. As you prefer. Done > + I have a extended-description-is-probably-too-short, please fix. I don't know what to add to the description so requested the help of Upstream. > * debian/changelog: > + 2 trailing whitespaces at line 4. Done > + "remove upstream debian directory" ??? what's this? > + "New localization of files for package rep-gtk." and this? > + "Replace sed command by dh_listpackages." this is not there anymore > + "Merge the packaging work of Christopher Roy Bratusek." be more > verbose in this. short dh, compat 9, dep5, blablabla Done > + s/read ability/readability/ maybe? Done > + mention the removal of rep-gtk-gnome. Done > + you need to target experimental, unstable won't be able to satisfy > the dependency on librep until the transition start (where you'll > need to re-upload the packages on unstable. actually it would be > enough to have them ready, bug given that there are a lot of > changes, and you are a sponsored person where there are reviews > going on, better have them in experimental, and re-upload them in > unstable later). Done > * debian/rules: > + override_dh_configure is unneed. as I said with librep, those flags > are already exported in compat 9. > - also , there is trailing whitespace here, but if you remove the > whole line... > + override_dh_install just to call dh_install ? ;) Need to cleanup gtk.la as is needed because of https://bugs.debian.org/684443 > + override_dh_installexamples => be aware you can also write the > directory name in debian/examples (up to you if you prefer small > files in debian/ or lines in d/rules) No preference, so I am going for lines in d/rules > + don't DH_VERBOSE need to be exported to work? > * you're building static libraries. Do you really need them? In Debian > we don't like static libraries. Given that this is a standard autofoo > package, --disable-static to configure should do the trick. > + this will also get rid of unstripped-static-library and > non-empty-dependency_libs-in-la-file lintian tags. See https://bugs.debian.org/684443 > * something to say about https://bugs.debian.org/680449 ? > No longer makes sense with the new version. When this rep-gtk and sawfish hit experimental I will ask user to try again. Kind regards Jose M Calhariz -- -- Cerveja? Serve já! signature.asc Description: Digital signature
Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep
On Fri, Jan 29, 2016 at 12:27:00PM +, Mattia Rizzolo wrote: > On Thu, Jan 28, 2016 at 09:44:23PM +0000, Jose M Calhariz wrote: > > Sorry for taking a long time to reply, adding my delay I had email > > problems. > > funny ;) > > > On Thu, Jan 14, 2016 at 12:13:29AM +, Mattia Rizzolo wrote: > > > + I have a extended-description-is-probably-too-short, please fix. > > > > I don't know what to add to the description so requested the help of > > Upstream. > > Ok. > > > > * you're building static libraries. Do you really need them? In Debian > > > we don't like static libraries. Given that this is a standard autofoo > > > package, --disable-static to configure should do the trick. > > > + this will also get rid of unstripped-static-library and > > > non-empty-dependency_libs-in-la-file lintian tags. > > > > See https://bugs.debian.org/684443 > > Ok. > > > > * something to say about https://bugs.debian.org/680449 ? > > > > No longer makes sense with the new version. When this rep-gtk and > > sawfish hit experimental I will ask user to try again. > > Ok. > > > All in all, this looks good to me. > Shall I upload? :) > Yes, please. By any chance are you at FOSDEM? Kind regards Jose M Calhariz -- -- A consciência e aquela voz interior que nos adverte de que alguem pode estar olhando. -- H. L. Mencken signature.asc Description: Digital signature
Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver
Package: sponsorship-requests Severity: normal Amanda have release a new upstream version. My main sponsor is too busy for helping me. So I am searching for someone that can help sponsor the new release. * Package name: amanda Version : 1:3.3.8-1 Upstream Author : Amanda Development Team * URL : http://www.amanda.org * License : GPL Section : utils -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
Package: sponsorship-requests Severity: normal A long time ago I tried to adopt sawfish and is build-depends. But my main sponsor being too busy for helping me. So I am searching for someone that can help sponsor the packages, close the ITA and help me fix the last bits for making the packages fit for Debian. The packages are very old. I could not update sawfish without updating it's build-depends. That was cared and are now on experimental. So is time for sawfish, the latest changes are on collab-maint. * Package name: sawfish Version : 1:1.11-1 Upstream Author : Christopher Bratusek * URL : http://download.tuxfamily.org/sawfish/ * License : GPL 2 Section : x11 -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Kind regards Jose M Calhariz
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
On 06/02/16 23:41, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
>
> On Sat, Feb 06, 2016 at 08:03:07PM +0000, Jose M Calhariz wrote:
>> The packages are very old. I could not update sawfish without
>> updating it's build-depends. That was cared and are now on
>> experimental. So is time for sawfish, the latest changes are on
>> collab-maint.
> Umh, couldn't you turn d/rules to use the dh sequencer?
I don't know enough and lintian show many problems with upstream d/rules.
> I anyway see a lot of nowadyas obsolete stuff that could really easily
> be removed, for example:
>
> * you include quilt.make: the package is source/format 3.0 (quilt), dpkg
> takes care of that already. that would also remove the quilt B-D
> (and the line in the clean target).
Done.
> * all that if/else/endif staff can go away if you stop calling manually
> ./configure and rely in dh_auto_configure
Done
> * maybe use dh-autoreconf instead of manually instead of copying
> config.{sub,guess} and calling autoconf, etc...
No certain the changes I have made are correct. But at least builds.
> * most (all?) of that clean rule is deal correctly by dh_auto_clean
Done.
> * the source targe should follow policy §4.9 (so, named get-orig-source)
Removed, not usefull for me.
>
> more:
>
> * d/changelog
> + trailing whitespaces at line 24
> + "Remove upstream debian directory." => what's this? do you mean the
> upstream tarball and you removed it? source fomat 3.0 already does
> it by itself, i don't understand what you did.
I created a commit in git that removes the upstream debian directory.
Maybe is not necessary.
> * d/control
> + the Build-Conflicts on automake1.4 is unneeded.
Done
> + the Build-Depends on dpkg-dev is unneeded
Done
> + there is an ongoing effort since a couple of weeks to switch Vcs-Git
> to stop using the git:// protocol, please switch Vcs-Git to https.
> (there is also a lintian tag for this, btw)
Done
> + and of course Vcs-Browser http => https
> + wait, why the sawfish binary would need an explicit dependency on
> librep9 ?? ain't that provided by shlibs:Depends?
Done
> * maybe you can consider to drop the -dbg package in favour of the
> automatically built dbgsym?
Done
> * d/menu: drop it?
Why?
> * bump debhelper compat level to 9?
Done
> * d/copyright: consider write a copyright-format 1.0 one? at a first
> sight doesn't look too much work.
Done
> * trying to build it: "configure: error: cannot locate librep >= 0.92.3"
> so you miss a build-dep.
> + didn't you try to build it in a clean chroot?
Err, my mistake.
> * once fixed the b-d, I get another ftbfs, with a lisp backtrace ending:
> 'error--> (file-error "No such file or directory" "rep/data/tables")'
> go figure...
Are you building in i386 or amd64?
> * so it seems you have symlinked doc dir. do as it pleases you, but
> anyway please drop those manually built .postinst file if their only
> use it that one.
Droped
> * please try to get a more lintian clean package.
Done
> * please try to get a reproducible buildable package, from what I see it
> wouldn't be difficult at all.
>
>
> pretty sure I would find something more with a deeper look, even more if
> I could build it...
>
>
> there are 57 open bugs, are you telling me none of them get closed by
> this upload? :\
> I anyway expect some bug triaging done…
Will do it.
>
>
>
> good work! :)
>
Kind regards
Jose M Calhariz
signature.asc
Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
Today I didn't review all yours remarks. But in the spirit of release early and release often here goes my today effort. On 07/02/16 22:01, Mattia Rizzolo wrote: > On Sun, Feb 07, 2016 at 08:40:10PM +0000, Jose M Calhariz wrote: >> On 06/02/16 23:41, Mattia Rizzolo wrote: >>> Umh, couldn't you turn d/rules to use the dh sequencer? >> I don't know enough and lintian show many problems with upstream d/rules. > well, let's fix them, then :) > Attached there is a d/rules using short dh, may you try it and bend it > better to the needs of this package? I managed to make it compile, but for a reason I don't know I needed to add the following lines: override_dh_auto_configure: cp /usr/share/misc/config.guess . cp /usr/share/misc/config.sub . dh_auto_configure --parallel I have tried many ideas but was only this way that it build > There are some errors, for example lintian complains about > dependency_libs in the .la files [0], and other stuff. > though it also fixes things like debian-changelog-file-missing and > no-copyright-file I otherwise have with the current rules file. > Another thing: the build log looks really different, there are way more > lisp-related lines, but I haven't looked at it at all. > And it's really untested and I think it would enjoy some more work. > >>> I anyway see a lot of nowadyas obsolete stuff that could really easily >>> be removed, for example: >>> >>> * all that if/else/endif staff can go away if you stop calling manually >>> ./configure and rely in dh_auto_configure >> Done > though you didn't remove the if/else/endif at the start of d/rules. Gone > >>> * the source targe should follow policy §4.9 (so, named get-orig-source) >> Removed, not usefull for me. > cool. > >>> * d/changelog >>> + "Remove upstream debian directory." => what's this? do you mean the >>> upstream tarball and you removed it? source fomat 3.0 already does >>> it by itself, i don't understand what you did. >> I created a commit in git that removes the upstream debian directory. >> Maybe is not necessary. > umh now I don't recall if gbp does the wrong thing while importing the > ustream tarball and do things wrong, but I hope it doesn't. Anyway, > that's a kind of thing that is not thought to be in d/changelog. > >>> * d/control >>> * maybe you can consider to drop the -dbg package in favour of the >>> automatically built dbgsym? >> Done > cool! > >>> * d/menu: drop it? >> Why? > https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file.html Done > >>> * d/copyright: consider write a copyright-format 1.0 one? at a first >>> sight doesn't look too much work. >> Done > though it's not compliant, and indeed lintian is noisy on it, please try > to figure out what's wrong with it and fix it. > I believe blindly following lintian here is enough, though it would be > nice if you could understand what's the problem by yourself :) I fix it, but I don't understand why :-) > >>> * once fixed the b-d, I get another ftbfs, with a lisp backtrace ending: >>> 'error--> (file-error "No such file or directory" "rep/data/tables")' >>> go figure... >> Are you building in i386 or amd64? > amd64. > though now it builds, umh. ok... I found a missing bump on Build-depens on rep. > >>> * so it seems you have symlinked doc dir. do as it pleases you, but >>> anyway please drop those manually built .postinst file if their only >>> use it that one. >> Droped > I haven't yet checked, though you need to make sure there is an upgrade > path, and remember that dpkg doesn't overwrite a symlink while > installing/upgrading a package. do you remember those symlink_to_dir > and dir_to_symlink thinghies of the other package? I remember something. I have to review it. > >>> * please try to get a reproducible buildable package, from what I see it >>> wouldn't be difficult at all. >>> >>> there are 57 open bugs, are you telling me none of them get closed by >>> this upload? :\ >>> I anyway expect some bug triaging done… >> Will do it. > > * d/clean: you are removing config.sub, config.guess, configure and > libtool. Well, > 1) theoretically once the package is built the clean target of d/rules > should bring the tree back to the original state. > 2) it makes git unnecessarly noisy about deleted files from the tree. > Just removing those 4 files from the d/clean file is enough, and > anyway I don't understand what would have been the whole point of > having them listed there in the first place. > > * P: sawfish-lisp-source: maintainer-script-without-set-e postinst > + and more like that > * d/rules: please try enabling the hardening build flags > > > > [0] add here a random rant about static libaries.. can't we just > drop them... :\ (last time I brought this up others said to keep > them for our users.. gah!) signature.asc Description: OpenPGP digital signature
Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11
On 08/02/16 21:57, Mattia Rizzolo wrote: > On Mon, Feb 08, 2016 at 09:29:55PM +0000, Jose M Calhariz wrote: >> Today I didn't review all yours remarks. But in the spirit of release >> early and release often here goes my today effort. > yay, I definitely approve this ;) > I hadn't gone deeper, just commented on your last changes here. > >> On 07/02/16 22:01, Mattia Rizzolo wrote: >>> On Sun, Feb 07, 2016 at 08:40:10PM +, Jose M Calhariz wrote: >>>> On 06/02/16 23:41, Mattia Rizzolo wrote: >>>>> Umh, couldn't you turn d/rules to use the dh sequencer? >>>> I don't know enough and lintian show many problems with upstream d/rules. >>> well, let's fix them, then :) >>> Attached there is a d/rules using short dh, may you try it and bend it >>> better to the needs of this package? >> I managed to make it compile, but for a reason I don't know I needed to >> add the following lines: >> >> override_dh_auto_configure: >> cp /usr/share/misc/config.guess . >> cp /usr/share/misc/config.sub . >> dh_auto_configure --parallel > that's so weird. > > even more in light of the new dh_update_autotools_config which is run > automatically by dh >= 9.20160114 and do exactly that. > Are you testing your package in an update sid chroot? Maybe the difference is that I build the software using: time gbp buildpackage --git-pbuilder --git-ignore-new or in a recent sid chroot: time debuild -uc -us I found another way to fix it, that seams to me to be more correct. override_dh_clean: dh_clean --exclude=config.sub --exclude=config.guess > >> I have tried many ideas but was only this way that it build > also, it did build here without them. > >>>>> * d/copyright: consider write a copyright-format 1.0 one? at a first >>>>> sight doesn't look too much work. >>>> Done >>> though it's not compliant, and indeed lintian is noisy on it, please try >>> to figure out what's wrong with it and fix it. >>> I believe blindly following lintian here is enough, though it would be >>> nice if you could understand what's the problem by yourself :) >> I fix it, but I don't understand why :-) > ok, I'm going to assume you read all of > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and > somehow did not understand it. > > DEP-5 copyright is RFC 822-compliant file where there are basically 3 > types of paragraphs: > * the header paragraph => you know it > * the file paragraphs > * the stand alone license paragraphs > > the file paragraph is composed by at least > * Files: > * Copyright: > * License: > > in your earlier attempt at it you put a blank line between Copyright and > License, and de-facto created a separated pargraph, totally disconnected > from the previous one. That one by itself was a compliant stand alone > license paragraph, but > 1) it was repeated by another one later > 2) it was not refereced by a License: line from a file paragraph. > > > I hope I made the thing at least clearer. Thank you. > >>>>> * please try to get a reproducible buildable package, from what I see it >>>>> wouldn't be difficult at all. > ♥ THANK YOU! :D > >>>>> there are 57 open bugs, are you telling me none of them get closed by >>>>> this upload? :\ > ok, I saw you added some closes: to the bug, and added a line to the > changelog saying that you closed those bugs. meh. > you should explicitly list what you are closing, briefly; probably the > best way is in a indented list, something like > * New upstream version. > + Fix blabla due to fofo. Closes: #x > + Fix ciaciaaicegow. Closes: #y > And adding to the changelog a sentence like "I closed bugs" is totally > useless, just remove it :) > Ok. I estimate this will take some days. signature.asc Description: OpenPGP digital signature
