Bug#767372: Reassigning to pantomime
Hi, Yavor Doganov wrote (30 Oct 2014 11:59:26 GMT) : An attempt to contact the original authors of GNUMail and LuserNET for request for relicensing under GPL + OpenSSL exception has failed, so the problem will be solved in the library by switching to GnuTLS. [Looking at it since it's a RC bug affecting Jessie.] FTR: * there's a sponsorship request: https://bugs.debian.org/767372 * the patch applied in the proposed package has been proposed upstream in August: https://lists.nongnu.org/archive/html/gap-dev-discuss/2014-08/msg0.html * There's been exactly one reply there, two months later: https://lists.nongnu.org/archive/html/gap-dev-discuss/2014-09/msg0.html (... and no other messages on the list in between) Upstream asks Yavor a question that's not been answered yet. I don't personally feel comfortable introducing a crypto-related patch in Debian, that upstream won't take, and that apparently hasn't been looked at by many persons yet. I hope this problem can be fixed on the long term, but I doubt that anyone who doesn't have a good knowledge of both pantomime *and* crypto libraries can sensibly sponsor the proposed upload. As far as Jessie is concerned, I fail to see what can reasonably be done except letting pantomime1.2 and lusernet.app be auto-removed (which will be the case in 13 days unless something else happens in the meantime) :/ ... except if the release team decides to flag this RC bug jessie-ignore. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85389jtdn5@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Control: retitle -1 RFS: keyringer/0.3.6-1 -- Distributed secret management using GnuPG and Git Hi, (sorry for the delay..) Gaudenz Steinlin wrote (20 May 2014 16:26:21 GMT) : I guess this is a sponsorship request. It looks like it :) I lost a bit track of the status. So did I. @rhatto: in this case, you want to retitle the bug, so it's clear what you are asking. I did it this time, so you can see how it's done :) Intrigeri are you going to have a look or would you prefer if I did? I certainly wouldn't mind if you gave me a hand on that one. Note that I usually also act as a reviewer and tester for upstream changes. Where can I find the package? I usually take it from an OpenPGP-signed Git tag: git://git.sarava.org/keyringer.git (standard gbp layout) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85tx7yhtdc@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Silvio Rhatto wrote (17 Apr 2014 21:24:29 GMT) : I also got swamped with work and it's still hard to find when I should ask for a new release to be uploaded into Debian. I suggest just closing this RFS bug, then. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85d2gediwr@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Hi Gaudenz, rhatto, and others, Gaudenz Steinlin wrote (17 Apr 2014 06:30:09 GMT) : Any update on this? I'm currently evaluating keyringer for my use and would like to test the latest release. If intrigeri is just busy I can also help with sponsoring the package (only after easter though). I was waiting for rhatto to formally request sponsorship for 0.3.3-1, by retitling this RFS. Sorry if I seem to be nitpicking and this was done implicitly already -- it was simply not clear to me. rhatto? OTOH, sure, I'm generally busy, and I certainly would not mind being joined by Gaudenz when it comes to sponsoring this package, be it for 0.3.3 only, or on the longer run :) (Context: my ((mentoring + volunteers coordination) / hack) ratio is at risk. Please help me find some more time to hack, and I promise I'll make good use of it :) Take care, cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85fvlbmzon@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Hi, Silvio Rhatto wrote (22 Mar 2014 19:53:54 GMT) : I just released 0.3.3 with fixed suggested in this thread. Looks good to me, feel free to retitle and reuse this RFS. Note that your branches don't seem to have been pushed to Git yet, while the tags have been. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85ppldjlcj@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Hi, Silvio Rhatto wrote (18 Mar 2014 00:17:11 GMT) : Em Mon, Mar 17, 2014 at 10:29:12AM +0100, intrigeri escreveu: Great! Here's a quick code review of the changes since 0.2.9. Thanks for the review :) You're welcome. In the future, how about releasing a RC, issueing a call for reviews and tests, before going the full way to RFS? Congrats for the improvements. Only two minor glitches remain. I can now see: - echo Fatal: no such key $recipient on your GPG keyring. + echo Fatal: no such key $recipient on your OpenPGP keyring. ... but I'm not sure OpenPGP keyring makes any sense. Unless the OpenPGP standard defines this concept, I think GnuPG keyring would be more correct. +gpg --batch --refresh-keys $recipient I'm not sure this really does what you mean here. At least the GnuPG manpage does not talk about it. Perhaps use --recv-keys for better clarity? Ping? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85a9ci8r1v@boum.org
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Hi, Silvio Rhatto wrote (14 Mar 2014 20:43:23 GMT) : I am looking for a sponsor for release 0.3.2-1 of keyringer. Great! Here's a quick code review of the changes since 0.2.9. I'm not convinced that the key expiry check does not introduce more severe regressions than it improves the UX. Let's see: * Does it support the case when I have multiple keys for a given recipient in my keyring, and e.g. one is expired, but the one that should be used is not? * It seems that all subkeys (regardless of their intended usage) must *not* be expired, else keyringer errors out. This won't work with people who change their encryption subkey on a regular basis, will it? * Why try to check this ourselves at all, while GnuPG will do it anyway (and likely in a more correct way)? +candidates=(`keyringer_exec find $BASEDIR | grep -i $1 | grep -e '.asc$'`) This seems fragile to me. How about passing find something like '-name *$i*.asc' instead? Same concerns in lib/keyringer/actions/find. + echo Could not find exact match \$1\, please chose one of the following secrets: s/exact match/exact match for/ s/chose/choose/ +Alis to clip action. +: Alis to clip action. s/Alis/Alias/ +If you're using debian `jessie` or `unstable`, just run s/debian/Debian/ +# If you run it more than that interval, no canary will +# be updated. more than once in this time span, maybe? +# - Can optinally be included in another git repository +# (encrypted or plain+signed), commited and pushed Ask your preferred spell checker :) +# - Then, add the following at your ~/.profile or wherever you want your canary +#be called from: keyringer keyring canary. s/at your/to your/ It's unclear to me what calling a canary means in this context. Clarify? In a few places, s/GPG/GnuPG/ + echo Please check for this key or fix the recipient file. s/check for/retrieve this key yourself/, maybe? +gpg --batch --refresh-keys $recipient I'm not sure this really does what you mean here. At least the GnuPG manpage does not talk about it. Perhaps use --recv-keys for better clarity? + keyringer_exec git $BASEDIR gc --prune=all Potentially losing user's data feels quite wrong, in an action called check, and documented as Run maintenance checks in a keyring. +echo Fatal: please set the full GPG signature hash for key ID $recipient: I'm afraid GPG signature hash is unclear to most people. Just say OpenPGP fingerprint instead? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85iordgolz@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, quidame wrote (20 Jul 2013 10:56:58 GMT) : First, was the target distribution change in debian/changelog intentional? (0.4.12 has experimental, 0.4.13 has unstable.) Yes it is; the target distribution was set to experimental for the wheezy's freeze duration... after what it was forgotten. Do you think I should revert to experimental ? No, unstable should be fine. Thanks for all the fixes. I've just reviewed and built 0.4.15 and hoped to upload right away, but Lintian is still not happy: W: bilibop-rules: extended-description-contains-empty-paragraph N: N:The extended description (the lines after the first line of the N:Description: field) contains an empty paragraph. N: N:Severity: normal, Certainty: certain N: N:Check: description, Type: binary, udeb N: W: bilibop: extended-description-contains-empty-paragraph W: bilibop-lockfs: extended-description-contains-empty-paragraph W: bilibop-common: extended-description-contains-empty-paragraph W: bilibop-udev: extended-description-contains-empty-paragraph Looks like some buggy variable substitution. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85ioy97ye7@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi,
intrigeri wrote (04 Jul 2013 06:49:08 GMT) :
I plan to review, and hopefully upload bilibop next week.
Here we go.
First, was the target distribution change in debian/changelog
intentional? (0.4.12 has experimental, 0.4.13 has unstable.)
Second, it looks like important changes and refactoring are flowing in
rather quickly, so I'd like to check that you are confident with the
current state of bilibop, and believe it is stable enough to be part
of a Debian release. Do you confirm this?
Also, please keep in mind that once bilibop is uploaded to Debian, the
responsibility of backward compatibility will be yours, as the
maintainer. This being said, while I certainly wouldn't mind a bit
more abstraction / factorization at some places, the code looks solid
enough :)
Some nitpicking follows, that should be fixed before the initial
upload IMHO:
+myshell=$(awk -F: \$1 ~ /$(whoami)/ {print \$NF} /etc/passwd)
Maybe use `getent' instead?
Also Lintian says:
I: bilibop-common: spelling-error-in-manpage
usr/share/man/man1/drivemap.1.gz informations information
... and a few others, so you probably want to run it in verbose /
pedantic mode and take the results into account.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/854nbqh0g2@boum.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
Jakub Wilk wrote (11 Nov 2012 00:38:28 GMT) : * Vasudev Kamath kamathvasu...@gmail.com, 2012-11-10, 11:28: debian/watch contains only a single line version=3? Is that intentional? As far as I can see, this change is not documented in the changelog. Yes file is introduced to suppress the lintian warning. A Lintian override would be less hackish, and would express the intent a bit more clearly, wouldn't it? Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85d2zk1rfr@boum.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
Vasudev Kamath wrote (15 Oct 2012 17:38:41 GMT) : On 19:08 Mon 15 Oct , intrigeri wrote: I think you should read the documentation about -s ours, before concluding you can't merge it back to master. Tried that but what here happens is wheezy branch is based on master which doesn't have any 38 related history at all. So merging will overwrite my 39 work. (I tried this) It's unclear to me how git merge -s ours, if done in the correct direction, could overwrite any work in the current branch, but I may have misunderstood the problem entirely, and I don't care that much, so let's leave it at that. Cheers! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85ehks57z7@boum.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
Hi, Vasudev Kamath wrote (15 Oct 2012 03:43:55 GMT) : * git checkout master git merge -s ours squeeze Well I don't really think I can merge it back to master! I think you should read the documentation about -s ours, before concluding you can't merge it back to master. Well unfortunately that repository no more exists! I don't know what happened but I guess either domain moved or something else happened. Have you tried asking the previous maintainer to provide you with their old repository's history? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85y5j7d5na@boum.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
Hi, (meta: I'm Vasudev's AM ;) Vasudev Kamath wrote (12 Oct 2012 03:31:39 GMT) : On Fri, Oct 12, 2012 at 12:28 AM, Jakub Wilk jw...@debian.org wrote: New repository for the squeeze branch feels wrong to me FWIW it feels wrong to me to. That's what branches are for. Note that branches in the same repository don't necessarily have to share common ancestors: e.g. the pristine-tar branch, when using gbp + pristine-tar, does not share its history with the upstream and packaging branches. Well it is actually wrong but I can't see other altenative but I think I will try it on -mentors and see if others have any good idea. One thing I can think is just remove existing suckless-tools repository (I any how have my local copy) then rename suckless-tools-38 to suckless-tools and on top of this import my 39 work so 38 history and 39 both can leave together. Let me see Rewriting already published branches' history is a no-go. What I would suggest is: * create a squeeze branch in the existing repository (from scratch, no shared ancestors) * import the needed and missing (older) version into the squeeze branch * git checkout master git merge -s ours squeeze Also, given previous maintainer had his own repository in his own domain, importing their history, merged with ours strategy, may be an option too. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wqytnrjd@boum.org
Re: git, first later steps
Hi, So, my question about Git is: should I start it from the initial release, or from the actual one ? When using a git-buildpackage workflow, git-import-dsc makes it trivial to import the full history, especially for a native package such as yours. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85bokb113g@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, quid...@poivron.org wrote (16 Jun 2012 00:52:22 GMT) : http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.0.dsc Hopefully, I'll review this before the end of the month. Other potential sponsors: if you can be faster than me, please do. So, I don't understand the interest/benefit to build a non-native source package that would be used only on Debian. The only benefit, and the reason why I mentionned this as a possibility, would be to have a way to differentiate, in the version numbers, new releases that only change the packaging, from releases that change things deeper. All this because you seemed to be reluctant to increase the version number for minor changes in debian/control and stuff. But I don't care, really. Both native and non-native would do. Surely it is entirely possible, but I don't think everything possible must be done. Obviously. Cheers! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85zk81omwv@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
quid...@poivron.org wrote (08 Jun 2012 22:35:21 GMT) : OK. But packaging is not a goal in itself, so I think I will not send a new version with just (in the changelog): * Fix typos, unclear sentences and language errors in debian/control, in the documentation and in the comments of the scripts and functions. Well, as you see fit. I am waiting: - for new comments from you or another DD - to find by myself something to optimize in the code How long do you intend to wait? Another possibility would be to move to non-native and increment the Debian revision number only. In the present case, we would move from 0.2-1 to 0.2-2, which would reflect the actual changes quite better. For me, this solution, if it is one, implies a lot of issues: For bilibop-common, of course, no problem. With some minor changes, maybe bilibop-rules could be fully portable too. But bilibop-lockfs, in its actual state, is distribution dependent; it depends on initramfs-tools, which is a Debian native source package. If I rewrite bilibop-lockfs to make it more portable (i.e to integrate it in the 'dracut' infrastructure) it will never be installed on Debian, because the default initramdisk builder is initramfs-tools, which conflicts with dracut. But maybe I'm wrong and I have a bad overview on this issue. Maybe bilibop-lockfs could be only a debian patch. Or what ? I think it is entirely possible, even though not perfectly elegant, to turn the package into a non-native one without immediately making the code distro-independent and well separated between the Debian patch and the upstream code. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8562b063me@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi,
quid...@poivron.org wrote (08 Jun 2012 10:46:14 GMT) :
+ * debian/control: more precise description of the packages, their
purposes
+and features. Add a statement about the required kernel version.
I doubt this statement is in debian/control.
[...]
The first paragraph of the description and the requirement, which are
common to all binary packages, are included with ${Description} and
${Requirement}, defined in debian/substvars. Not good ?
Ooops, I missed it, sorry. This comment of mine shall be
ignored, then.
OK, what is the best way, now ?
1. Fix typos and other errors you mention above, modify the existing
changelog entry and keep the version number (0.2) ?
I'd rather not see differing code or packaging called the same.
In that case, is it possible to put the 'new' version to
mentors.debian.org and overwrite the previous one ?
No idea.
2. Fix typos and other things, add a new changelog entry and increment
the version number (0.2.1) ?
Yes.
In that case, how to deal with the irrelevant or useless
informations of the actual changelog ?
Forget it :)
3. ?
Another possibility would be to move to non-native and increment the
Debian revision number only. In the present case, we would move from
0.2-1 to 0.2-2, which would reflect the actual changes quite better.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/85pq9a80gp@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, quid...@poivron.org wrote (07 Jun 2012 12:53:34 GMT) : The whole thing is arch:all, but some shell functions require a Linux kernel shouldn't bilibop-common have a versioned dependency on Linux kernel = 2.6.37 (needed by backing_file_from_loop), and be arch:linux-any instead? I don't know exactly how to do a versioned dependency on the kernel. We don't need a versioned dependency, but we need to depend on the *Linux* kernel. Additionally, changing 'all' by 'linux-any' leads to the creation of architecture dependent binaries (formally, by their names), but with exactly the same contents: shell scripts, udev rules, manpages and other plain text documents. Sure. It's a tiny bit sad, but this set of packages is *not* arch:all, given it does not work on kfreebsd-* architectures. So, I'm not sure that it is the best way. Maybe, for bilibop-common, Architecture: linux-any, and for the others, Architecture: all ? This would for sure avoid some stupid duplication, but it would nevertheless create a set of packages that are uninstallable on some architectures, without that fact being made clear to the users of those architectures. So, really, I think the only sane way is to move everything (that is or depends on bilibop-common) to arch:linux-any. Do you think a NOTE in the extended description and/or in the README could be sufficient ? It would be sufficient to address the minimal Linux kernel version requirement, but certainly not to address the needs Linux one. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85bokvb7ce@boum.org
Bug#675532: Fwd: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.2.dsc Great! + * New OpenPGP key. I doubt this is relevant to debian/changelog. + * debian/control: change 'Achitecture: all' to 'Architecture: linux-any' for +all binaries. I think you mean all binary packages, right? + * debian/control: more precise description of the packages, their purposes +and features. Add a statement about the required kernel version. I doubt this statement is in debian/control. + * Clean debian/rules. Without specifics, this is mostly useless noise. s/an heuristic/a heuristic/ s/an udev/a udev/ normal users Perhaps non-priviledged users instead? I'm not sure I like the concept of normality involved here. A initramfs-hook was moved from bilibop-common to bilibop-lockfs. AFAICT, this is not mentionned in debian/changelog (which is the main place where changes must be documented, given this is a native package, and you use no VCS to explain the rationale of each atomic change.) Things are progressing! :) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85vcj2a76j@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, bilibop project wrote (02 Jun 2012 00:07:22 GMT) : I am looking for a sponsor for my package bilibop Here is a first, quick review. First of all, this is great work. In case this is your first Debian packaging work, as you seem to indicate in the ITP bug, then congrats! The whole thing is arch:all, but some shell functions require a Linux kernel shouldn't bilibop-common have a versioned dependency on Linux kernel = 2.6.37 (needed by backing_file_from_loop), and be arch:linux-any instead? Quotes such as in « disk » are no international symbols, and I've seen English native speakers misinterpret those. You want an URI to a versioned copyright format: Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ (catched by lintian --pedantic). Any Vcs-Git / Vcs-Browser field? If you have none ready, I suggest setting up a Git repository in collab-maint on Alioth. Given the Maintainer is a collective email address, we need at least one human listed in the Uploaders: field (Debian Policy §3.3) -- note that this field has nothing to do with who actually sponsors the uploads; either put yourself, a co-maintainer, or the first sponsor if they are willing to take the responsibility to act as co-maintainers. Why does bilibop-common's postinst and postrm run update-initramfs? The debian/changelog entry must close the ITP bug. The debian/rules header about Sample debian/rules that uses debhelper should be removed. Why the need to disable override_dh_pysupport by hand? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85aa0hio3c@boum.org
