Bug#1024608: RFS: n2n/3.1.1-0.1 [NMU] -- Peer-to-Peer VPN network daemon
Hello Tianyu Chen, I've had a quick look at your proposed NMU and have some comments below. On Tue, Nov 22, 2022 at 12:45:17PM +0800, Tianyu Chen wrote: > Package: sponsorship-requests > Severity: normal > X-Debbugs-Cc: billchenchina2...@gmail.com > > Dear mentors, > > I am looking for a sponsor for my package "n2n": > > * Package name : n2n >Version : 3.1.1-0.1 >Upstream contact : Luca Deri > * URL : http://www.ntop.org/products/n2n/ > * License : Expat, __AUTO_PERMISSIVE__, GPL-3.0+ > * Vcs : https://github.com/leggewie-DM/n2n >Section : net > > Though "n2n" is already in debian, but it's already behind upstream(See > #914321 > and #1024139). I'm uploading a NMU for that. [...] > Changes since the last upload: > > n2n (3.1.1-0.1) unstable; urgency=medium > . >* Non-maintainer upload. >* New upstream version 3.1.1. (Closes: #914321, #1024139) First, an NMU is expected to be minimal changes needed. It is thus unexpected to see that you're completely gutting the existing packaging and replacing it with what is essentially a new from-scratch packaging. (specially since debian/changelog gives no clues about this.) I understand that a major new upstream version bump it might not have been possible to preserve much of the old stuff, but still it makes it quite hard for the reviewer. I'm also wary about your transition to machine-readable debian/copyright which throws away all existing copyright notices for existing package. I'm not a lawyer, so can't say what's correct I guess it can be argued both ways that you've completely replaced debian/ with new stuff or that no matter what it's still a derived work of the existing package. Either way, the new debian/copyright not having any explicit stanza for `Files: debian/*` makes me a bit worried. Also a nitpick, guidance like the below should IMHO be removed once you've done it: ``` # Please double check copyright with the licensecheck(1) command. ``` Many other files also has this comment (which you can also remove once you've followed the advice): ``` # You must remove unused comment lines for the released package. ``` (Another nitpick is that most files in debian/* starts with an empty line remove it?!) The old package had a /etc/init.d/n2n and in the new package you've introduced systemd service files with different naming! - How will upgrades works for existing users? - you're manually installing from debian/systemd/* (possibly because using template/instance units) which means you get no automatic debhelper integration generating maintscript code for you... and I don't see any manual either. Even if you want to ship disabled-by-default (as from docs there's no default configuration file installed, just a sample), you should likely issue a restart on upgrades atleast. In debian/rules you're manually hooking in dh_update_autotools_config ... when using dh compat 13 this is AFAIK handled automatically. You're also build-deping on cmake while at the same time specifying in debian/rules explicitly that you want to use autotools build system. Why? I'm having a hard time getting through all of this as a reviewer. One trivial example that makes it more annoying then necessary for a reviewer is debian/patches/move-man-pages.patch which makes the debdiff very verbose. Why not just submit something like this to upstream and then pull it in when upgrading to next upstream release?! If you really want to move files around, making a less noisy diff can be accomplished by using mv in debian/rules instead. Then it would be much more descriptive for a reviewer exactly what you're doing (rather than including a patch that is suitable for upstream submission). As is I can't comfortably sponsor this (but maybe someone else having a look has a different view), specially this close to the freeze. My personal recommendation would be that if it's too late to do minor incremental updates then pursue your ITS (rather than a NMU). Also please consider how upgrading existing users will work out. If you see no other way than the local sysadmin doing manual changes, then atleast write about this in debian/NEWS (see man dh_installchangelogs) and possibly also write some guidance in debian/README.Debian about how the integration works in Debian specifically and how the old installations configuration maps to the new. Regards, Andreas Henriksson
Bug#1027256: Subject: RFS: nvidia-vaapi-driver/0.0.8-1 -- VA-API implementation that uses NVDEC as a backend
Control: tags -1 + moreinfo Hello, Neither of the mendors.debian.net urls are accessible for me. On Thu, Dec 29, 2022 at 01:52:29AM +, YaNing Lu wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "nvidia-vaapi-driver": > > * Package name : nvidia-vaapi-driver >Version : 0.0.8-1 >Upstream contact : Stephen > * URL : https://github.com/elFarto/nvidia-vaapi-driver > * License : MIT > * Vcs : https://salsa.debian.org/Dami/nvidia-vaapi-driver >Section : video > > The source builds the following binary packages: > > nvidia-vaapi-driver - VA-API implementation that uses NVDEC as a backend > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/nvidia-vaapi-driver/ 404 Not Found > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/n/nvidia-vaapi-driver/nvidia-vaapi-driver_0.0.8-1.dsc 404 Not Found > > Changes since the last upload: > > nvidia-vaapi-driver (0.0.8-1) unstable; urgency=medium > . >* New upstream release. > > Regards, > -- > Lu YaNing Regards, Andreas Henriksson
Bug#911726: RFS: golang-github-xanzy-go-gitlab/0.11.3-1
Control: forcemerge 907212 911726 On Tue, Oct 23, 2018 at 05:01:31PM -0700, Felix Lechner wrote: > Package: sponsorship-requests > Severity: normal > X-Debbugs-CC: debian...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab". [...] You already have a sponsorship-request bug open for that. Please follow up on the comments in that bug report! Regards, Andreas Henriksson
Bug#907212: RFS: golang-github-xanzy-go-gitlab/0.0~git20180814.f3bc634-1 [ITP]
Control: tags -1 + moreinfo Hello Felix Lechner, On Fri, Aug 24, 2018 at 11:28:51AM -0700, Felix Lechner wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab" [...] I noticed there's a newer version available in the go-team git repo. I looked at that one, while I'm certainly no go packaging expert, your package looks fine to me except for one detail which you'll need to fix to have a chance to pass NEW. They copyright attribution. $ grep Copyright *.go | cut -d: -f2- | sort -u // Copyright 2015, Sander van Harmelen // Copyright 2017, Andrea Funto' // Copyright 2017, Arkbriar // Copyright 2017, Igor Varavko // Copyright 2017, Sander van Harmelen // Copyright 2017, Sander van Harmelen, Michael Lihs // Copyright 2017, Stany MARCEL // Copyright 2018, Patrick Webster // Copyright 2018, Sander van Harmelen Please make sure they're all accounted for in debian/copyright. One you have this fixed, please feel free to ping me directly (and cc this bug report) and I'll try to find time to look again and upload. Regards, Andreas Henriksson
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Hello Yavor Doganov, thanks for your quick followup. On Wed, Sep 05, 2018 at 11:22:23AM +0300, Yavor Doganov wrote: > Andreas Henriksson wrote: > > On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: > > > * debian/patches/gsettings-port.patch: New, migrate from GConf to > > > GSettings (Closes: #885817). > > > With gsettings migration I guess you feel it's unwelcome to have > > a dependency on gconf2 remaining in buster, but for data conversion > > the dependency needs to remain until gsettings conversion has shipped > > in one stable debian release (as a minimum). > > I agree completely. Some time ago I asked on the pkg-gnome list > precisely about this scenario [1] but didn't receive a reply. As the > situation now is clear and the new maintainer announced gconf is going > to be shipped in buster, I added explicit dependency on gconf2 and > removed the comment regarding migration from the patch. > > [1] > https://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/2018-August/145477.html The main problem here is that the gconf2->gsettings migration should have been done ~ 10 years ago already. Then it wouldn't have been a problem for buster. Unmaintained packages are a burden which we just can't allow block progress forever. It might just be better to remove them from debian and then provide them to potential users on the side. > > > > * debian/pixmaps/gnomint.xpm: > > > * debian/gnomint.menu: > > > * debian/gnomint.install: Delete. > > > > I guess you mean 'Delete' applies to all three above? > > Yes, this is a short variant that's widely used in upstream > changelogs. I changed it to "Delete" followed by "Likewise". "widely used in upstream changelogs" makes your GNU bias show. ;) > > > Maybe would have been better to write them under the same bullet > > point. (Also I'm not sure about separating the changelog on a > > per-file basis, rather than on a per-change basis but I guess that's > > related to personal taste and different people do it differently.) > > Well, yes, it is personal taste. I prefer the former concept as it's > very easy to miss some file or some tiny change with the latter. It > also corresponds with the GNU ChangeLog requirements so I don't have > to adapt mentally when I switch between a GNU-style ChangeLog and a > Debian changelog. > > OTOH, the per-change approach is very useful for commit messages. > > Thanks for the review. I reuploaded the package with these changes > and the timestamp updated. Regards, Andreas Henriksson PS. after sending you the previous mail I thought to myself that a Recommends might be more suitable, so people can remove gconf2 again after upgrade is finished (and anyone not installing recommends gets their choice of not migrating their settings) just thought I'd mention it...
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Hello Yavor Doganov, Thanks for working on improving this package. Please see comments below (inline). On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: [...] > I'm looking for a sponsor for a QA upload of "gnomint". > > * Package name: gnomint >Version : 1.3.0-1 [...] > Changes since the last upload: > > * QA upload. > * New upstream release. > * debian/compat: Set to 11. > * debian/control: Run wrap-and-sort -ast. > (Build-Depends): Bump debhelper requirement to match the compat level. > Remove autotools-dev and libgconf2-dev. > (Standards-Version): Claim compliance with 4.2.1 as of this release. > * debian/rules: Enable all hardening. Remove --with autotools_dev. > (override_dh_auto_install): Remove gconf schemas stuff. > * debian/patches/682432.patch: Refresh. > * debian/patches/02-cflags.patch: Remove configure hunk; refresh and > remove -Werror. Fix typo in the patch description. > * debian/patches/01-ldd.patch: > * debian/patches/10_gnutlsv3.diff: Delete, fixed upstream. > * debian/patches/fix-autoreconf.patch: New, fix autoreconf failure. > * debian/patches/gsettings-port.patch: New, migrate from GConf to > GSettings (Closes: #885817). I believe the switch to GSettings also > closes: #631768 which was probably due to the fact that GConf does not > apply changes atomically. This patch seems to include a conversion file to migrate the existing data/settings over from gconf2 to gsettings database, however the 'gsettings-data-convert' tool is part of the 'gconf2' package but there's no dependency from gnomint against gconf2 so the conversion won't happen unless the user already has gconf2 installed (which is becoming less and less likely). With gsettings migration I guess you feel it's unwelcome to have a dependency on gconf2 remaining in buster, but for data conversion the dependency needs to remain until gsettings conversion has shipped in one stable debian release (as a minimum). > * debian/patches/export-private-key-crash.patch: New, fix crash when > exporting the private key (Closes: #855200). Thanks to Karl E. > Jorgensen for the report. > * debian/patches/desktop-file.patch: New, fix some lintian complaints. > * debian/patches/spelling-errors.patch: New, self-explanatory. > * debian/patches/series: Update. > * debian/watch: New file. > * debian/pixmaps/gnomint.xpm: > * debian/gnomint.menu: > * debian/gnomint.install: Delete. I guess you mean 'Delete' applies to all three above? Maybe would have been better to write them under the same bullet point. (Also I'm not sure about separating the changelog on a per-file basis, rather than on a per-change basis but I guess that's related to personal taste and different people do it differently.) > * debian/copyright: Declare format. > Regards, Andreas Henriksson
Bug#884697: logrotate package
Hello Christian, On Sun, Aug 19, 2018 at 11:05:49AM +0200, Christian Göttsche wrote: [...] > > Please tell me if you want me to go ahead with further testing and > > uploading of the package, or if you already have someone else in mind > > for this task. > > Yes, I'd like to go ahead. [...] There doesn't seem to be any (signed) debian/3.14.0-1 tag in the logrotate repository at https://salsa.debian.org/debian/logrotate/tags Please push one, or if you'd rather finish up the changes in master and release them then please push a (signed) debian/3.14.0-2 tag. Also you might also want to add a debian/gbp.conf explicitly specifying which options should be used with this repo, like 'pristine-tar = True' etc. cf. https://salsa.debian.org/debian/iwd/blob/debian/master/debian/gbp.conf Poke me again once tagged and I'll look at uploading it. (I can probably guess that --git-debian-tag=a919cd247cfe5 is right, but I'd rather not guess and let you be explicit about what to use.) Regards, Andreas Henriksson PS. If you skip including debian/changelog entries in your commits and instead generate them from commit message using 'gbp dch --auto' it'll be easier to revert/cherry-pick/merge if needed later.
Bug#884697: Progress
Hello Christian Göttsche, On Fri, Jun 29, 2018 at 12:34:44PM +0200, Christian Göttsche wrote: > ping > > I uploaded a new version (lintian fixes, new std version, updated vcs > fields) to mentors (https://mentors.debian.net/package/logrotate). > Someone any ideas about the piuparts issues I mentioned? > > Otherwise I think the package is stable; its working for me on several > machines. I've looked over the 3.14.0-1 package version and generally everything looks very good to me. I'm appending my review notes about minor things below which might be useful for future improvements none the less. Please tell me if you want me to go ahead with further testing and uploading of the package, or if you already have someone else in mind for this task. Please also mention if you've contacted and what their response have been for the people offering mentorship (like in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887151#17 ). # logrotate WATCH OUT / HEADS UP: - I'm not sure about the current state but this has bitten me in the past. The debhelper systemd integration in the past had no particular knowledge about timer units. That resulted in the service unit for the respective timer unit being both enabled and *started* (or restarted, depending on if the package is newly installed or upgraded) at package installation/configure time. You likely do not want to trigger a logrotate at package installation/upgrade time and delay the entire dpkg operation until it completes. (I imagine some people might have massive logs that might take a very long time.) Please verify if current dh-systemd has improved on this front or if you need to add overrides for logrotate.service to not be started/enabled. I suspect this might very well be fixed now to just not start or enable services which don't have any [Install] section (like logrotate.service, but adding a build-time check to verify upstream doesn't slip one in there might be a useful safety for the future?). Minor things I reacted on that you might want to consider for future package versions: debian/upstream/metadata: - Repository url should have '.git' appended instead of last '/', right? - I think Bug-Database is more revelant for listing issues url instead of using Contact. debian/control: - I'm not sure using github project url in Homepage field is appropriate. It's supposed to be an url relevant for end users AFAIK. eg. github pages url would be suitable (if available, which it doesn't seem to be for logrotate). debian/logrotate.preinst: - how old is this? There are no version checks and I didn't look, but maybe it can be dropped now? The less manual written maintainerscript code the better. debian/logrotate.README.Debian: - this seems pretty outdated info as well considering for buster. Maybe it should also be dropped? debian/rules: - neat, but even better would be line-wrapping configure override using a backslash to put each config option on a separate line for easier reading. debian/tests: - given existance of tests reduces unstable->testing migration delay, this might just be a bit too trivial test to exist alone??? (while at the same time an existing test might be better than no test at all) debian/patches/manpage.patch: - why is this information relevant to put in the manpage? A more general solution would be to describe that apt-file can be used to search for which package contains something. Not suitable to document in specialized manpages like logrotate IMHO. Oh, I see this patch is not listed in series file so not applied. Well, might be another reason to drop it. debian/patches: - I see you've already upstreamed some of your work. I hope you will continue that trend with the remaining patches as well. Regards, Andreas Henriksson
Bug#904069: RFS: xsunpinyin/2.0.3-5 [RC]
Hello GengYu Rao, comments inlined below. On Thu, Jul 19, 2018 at 05:57:42AM +, GengYu Rao wrote: > Package: sponsorship-requests > Severity: important > Dear mentors, > > I am looking for a sponsor for my package "xsunpinyin" > > * Package name: xsunpinyin >Version : 2.0.3-5 [...] > dget -x > https://mentors.debian.net/debian/pool/main/x/xsunpinyin/xsunpinyin_2.0.3-5.dsc<https://mentors.debian.net/debian/pool/main/x/xsunpinyin/xsunpinyin_2.0.3-4.dsc> (^^^ broken!) > > > Changes since the last upload: > > migrate to salsa, and fixed URLs. > > > the repo is here https://salsa.debian.org/input-method-team/xsunpinyin Every commit is quite a mess, which is likely a contributing factor why you missed that you bumped compat from 7 -> 11, which isn't mentioned anywhere, in this commit: https://salsa.debian.org/input-method-team/xsunpinyin/commit/9630740c826b66ca615436283b590c75da62b7ab Such a compat change is something which needs to be carefully reviewed and not even mentioning it in the debian/changelog or in your sponsorship request rings a warning bell for me (and thus I stopped looking for other possible issues). Please consider in the future to spend more time writing useful commit messages, one change per commit, marking "typo" commits with 'Gbp-Dch: ignore' (see man gbp dch), (re)view the changes you're about to commit before doing so (using git commit -v) and finally generate debian/changelog using 'gbp dch --auto' to avoid missing to mention certain changes. It's also good to stay away from whitespace changes all over the place (as done by "helpful editors") as that makes diff/review your work unneccesarily hard. I'm not uploading (atleast in the current state), but hope that my comments was somewhat useful to you. Regards, Andreas Henriksson
Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]
Hello Gabriel F. T. Gomes, On Sun, Oct 01, 2017 at 07:40:40PM -0300, Gabriel F. T. Gomes wrote: [...] > I am looking for a sponsor for my package "bash-completion" [...] > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/b/bash-completion/bash-completion_2.7-1.dsc > > > My work is versioned with git (and I'm using git-buildpackage). > Currently, the git repository is hosted in: > http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable > > This upload updates maintainer information, as well as it updates > upstream sources to version 2.7 (from version 2.1). Since there were > many changes upstream, I made several changes downstream. You seem to have missed to incorporate all the NMUs of bash-completion... (atleast they where not part of the debian/changelog) Is there any reason why you did not include those changes? Won't your updated version conflict with packages who now ships their own bash completion files (that where dropped in the bash-completion NMUs)? Regards, Andreas Henriksson
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello halfdog, Sorry I have not had time to follow up to you. I simply don't have time. Hopefully my previous comments has been of some use to you, but I don't think I can help out anymore. On Thu, Aug 31, 2017 at 05:00:00AM +, halfdog wrote: > Hello Andreas, > > I did not hear from you after the last mails, see messages from > 04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested > in doing the (quite tricky) review? > > I have now also tested the build procedures and the software on > Debian Stretch, see today's upload of package to mentors.debian.org. > > Best regards, > hd > > Regards, Andreas Henriksson
Re: Preference for build or debhelper installing systemd unit files?
Hello J.T. Conklin,
On Wed, Jan 11, 2017 at 09:49:43AM -0800, J.T. Conklin wrote:
> This question is related to components Dell EMC (my current employer)
> are contributing to the Linux Foundation's openswitch project.
>
> With debhelper, systemd unit files can be installed by a package's build
> (ie. the Makefile installs them in $DESTDIR/lib/systemd/system/...) or
> they can be put in the debian/.service and dh_systemd_* will
> copy them to the package. In both cases, the dh_systemd_* scripts
> ensure that the proper boilerplate to enable/disable the service is
> added to the package's {post,pre}{inst,rm} scriptlets.
>
> My question, in the case where the same organization/people are
> responsible for both the software and the debian packaging, is whether
> there is a preference of which method is used.
Please do cooperate with your upstream on creating the best possible
service files. For example sometimes it might be complicated to work out
exactly which security restriction features you can turn on or not in a
service file, hopefully with upstreams help you can work it out.
Normally service files should not need to be distro specific.
This means prefer to *not* carry the service files in debian/*.service,
because this directory is part of your debian delta (not upstream).
At the same time it's not absolutely necessary for upstream to have
Makefile code to install the files, sometimes they're just available in
an example directory. In that case you can have them installed by just
adding them to debian/foo.install
Also, if there's some distro-specific thing you want to enable on top of
the upstream provided service file you can handle that as a regular
patch in debian/patches/foo.patch (which would be better than carrying
your own copy in debian/foo.service which will sooner or later become
outdated compared to upstreams).
In general my recommendation is to always try to keep your debian/
directory as minimal as possible. Everything you can and is useful to
share with upstream you should try to push upstream. Having a good
dialog with you upstream is useful in many cases. Even if you currently
can work out what you need sooner or later you'll likely run into an
issue which is easier to work out with upstreams help.
Regards,
Andreas Henriksson
Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework
Hello Frederic Bonnard, On Wed, Jan 11, 2017 at 09:28:19AM +0100, Frederic Bonnard wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, Gianfranco, > first best wishes to you all for this new year, health, success ; > especially in you Debian area :) . > > I am looking for a sponsor for my package "rear". > This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from > d/changelog : > > rear (2.00+dfsg-1) unstable; urgency=medium > > * New upstream release > * d/control : move asciidoc to Build-Depends (Closes: #849303) > > -- Frédéric Bonnard <fre...@linux.vnet.ibm.com> Tue, 10 Jan 2017 15:12:34 > +0100 [...] Given asciidoc was recently restructured with a new package split and the asciidoc package itself became a meta-package shouldn't you also take this opportunity to switch your build-dep to something else, like possibly asciidoc-base? (Not sure exactly what your needs are and which one of the asciidoc packages is suitable for you. The rear-doc package only seems to contain html files though and the asciidoc-base package description makes me think that's the suitable one.) Regards, Andreas Henriksson
Bug#850678: RFS: gnome-shell-extension-show-ip/4.0.1-1 [ITP]
Hello Kyle Robbertze, On Mon, Jan 09, 2017 at 11:49:06AM +0200, Kyle Robbertze wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "gnome-shell-extension-show-ip" [...] Really quickly looked at your package. The first thing to look at is debian/copyright as first thing to happen to your package after upload is that it'll get stuck in the NEW queue waiting for ftp-master review. They'll make sure your package is properly licensed and has obvious critical issues. Unfortunately you seem to document GPLv3+ in debian/copyright while the actual sources seems to say GPLv2+. (Except for the BSD special case which you already documented.) In my personal opinion it's your choice to "upgrade" to the later version but in my experience the ftp-masters expect you to document the original licensing offer made by upstream in debian/copyright. (So if you actually intend to upgrade the version of the license you likely atleast need to state this explicitly so it's obvious when it gets reviewed. I assume it's a simple mistake on your side though and you intended to use the same license as upstream.) I haven't looked further (yet). Regards, Andreas Henriksson
Bug#844765: RFS: gitless/0.8.4-1 -- new package
Hello Peter Pentchev, On Fri, Nov 18, 2016 at 10:15:20PM +0200, Peter Pentchev wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for the initial upload of my package > "gitless" - a version control system on top of Git. [...] I've looked over your new package sources (not built it yet). I have some comments of which (only) the first one is something I consider a blocker for uploading it. # debian/copyright and contradicting licensing. While the LICENSE.md file (and debian/copyright) claims the software is licensed under GPLv2+, when looking at the actual gitless/*.py files the header says GPLv2 (only). This contradiction might be something the debian ftp-masters has a problem with. I'd suggest you discuss it with upstream and suggest that if GPLv2+ is the intended license the headers are updated to clarify that. Please use the standard boilerplate in the file headers! See "How to Apply These Terms to Your New Programs" in LICENSE.md # manpage Please consider upstreaming it if you haven't already. # debian/patches/pager.patch Please consider using 'sensible-pager' before falling back on 'less'. (Also while less is usually preferred over more, I think more would be a more commonly available and thus better as a last resort fallback. On debian sensible-utils is Essential:yes so always available which means discussing any fallback after it is quite theoretical.) # debian/patches/python3.patch Why is forwarding it not-needed? # debian/tests/control This isn't my area of expertise, but do you really need to depend on things which your package already depends on for the test environment? Everything else looks super tidy to me. HTH. Regards, Andreas Henriksson
Bug#849318: RFS: eoconv/1.5-1
Hello Sean, On Mon, Jan 09, 2017 at 08:26:01PM -0700, Sean Whitton wrote: > Dear Andreas, > > On Sun, Dec 25, 2016 at 02:42:42PM +0100, Andreas Henriksson wrote: > > Your changes looks fine and I can sponsor them for you if you wish > > but have some questions for you below first. > > This RFS has been waiting on your response for a few weeks now, and > winter is coming. Are you prepared to upload, or can someone else take > this RFS off your hands? > > In the future, please consider taking ownership of RFS bugs that you > intend to shepherd through to upload. I did not take ownership exactly because I don't intend to shepherd anything. Any involvement from my side is strictly "take it or leave it". I don't intend to owe anyone anything because I volunteered to review something once. My time is already too limited. (And as long as my initial review comments stay unadressed I don't intend to sponsor it either ofcourse. Others might not see those points as issues for uploading, but that's up to them. Even if the points are adressed I might still not have time for it.) Please don't hold your breath waiting for anything from me. Regards, Andreas Henriksson
Bug#848496: RFS: libopenshot/0.1.2+ds1-1 [ITP][experimental]
Hello Ghislain Vaillant, On Sat, Dec 17, 2016 at 04:22:03PM +, Ghislain Vaillant wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "libopenshot" [...] I looked at your package and it looks fine to me, but given you're putting it under team maintenance (which is great!) shouldn't someone from the team sponsor you? They will likely also be able to review the package better then me. A personal recommendation would be to put the so version (9) in the filename pattern of your debian/lib*9.install file so that whenever the soname gets bumped you'll instantly notice it while building. Ofcourse lintian will also complain about soname not matching package name, but that's less subtle and you can't really have too many safeguards in place to catch potential mistakes in package ABI handling. Would also be interesting to know what your interest in packaging this library is. Do you have or intend to package something using this library? Regards, Andreas Henriksson
Bug#849521: RFS: rutorrent/3.7-1 [ITP] -- A front-end for the rTorrent torrent client
Hello Taylor Kline, On Tue, Dec 27, 2016 at 11:26:30PM -0500, Taylor Kline wrote: > Package: sponsorship-requests > Severity: wishlist > > Hello fine mentors, > > I am looking for a sponsor for "rutorrent" > > Package name: rutorrent > Version : 3.7-1 [...] > > /etc/ruTorrent - server files > > /usr/share/ruTorrent - user-set configuration files chmod'd to a+rwX [...] Thanks for being upfront with this, appreciated. I've looked over your package which I think mostly looks good. I'm not overly joyed by seeing the symlink farm in /etc pointing to /usr/share though. This is simply wrong as the files are not configuration files (which is why they don't live in /etc to begin with). Whatever needs these files should IMHO be fixed up to look for the in the correct location (so you can drop the symlinks). Making /usr/share/ruTorrent world-writable is the main issue though. This will never end well. You need to think about security and how you manage permissions somehow. This is in my opinion a blocker for uploading your package. Please also consider upstreaming your manpages. Not sure but if nginx has '*-available' '*-enabled' configuration pattern but I think it does and then maybe there's a way to provide a snippet for '*-available' that a user can in normal cases just enable. This should simplify for the user over having to read up and manually configure nginx. Regards, Andreas Henriksson
Bug#849754: RFS: guerillabackup/0.0.0-1
0 instead. This automatically includes dh-systemd, etc. It will also use 'restart /after/ upgrade' by default. * DEP14 rather than copying packaging during configure. * restart instead of stop+start. Also contact debian systemd maintainers for advice. Multiple services: Need to manually list each for dh_systemd_* to pick them up. Maintainer scripts: Avoid them. Please consider shipping the files with correct permissions rather than setting them in postinst. (That would also close the unpack->configure window of them having the incorrect permissions.) Please do not invent your own systemd integration glue rather than using the existing helpers. It's just way to easy to get it wrong and you're adding extra work on people reviewing your package. Your postrm file seems to contain nothing useful. Just remove it and it'll be completely generated when needed. Following earlier advice the postrm, etc. files should also become pointless -> removed. Regards, Andreas Henriksson
Bug#849691: RFS: gnome-shell-extension-radio/1.4-1 [ITP] -- GNOME shell extension for listening to Internet radio streams
Hello Leo, On Thu, Dec 29, 2016 at 09:22:23PM +0100, l...@ndrs.fr wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "gnome-shell-extension-radio", [...] Thanks for your interest in debian packaging. [...] > Everything is ready except a few contributors informations missing in > `debian/copyright` but I hope it'll to be fixed soon, see [4]. Please note that not all contributors may be copyright holders. If actual copyright holders are missing from debian/copyright that's likely a blocking issue though, as your package likely won't pass through the initial NEW review done by ftp-masters. (You seem to have put work into your debian/copyright and thanks for doing so. Having copyright and licensing information in order is great help for getting the package accepted and shipped in the Debian archive.) > > This is my first Debian package, sorry if I'm doing something wrong... Your package seems mostly fine. I'm not sure why you're overriding the build target in your debian/rules though rather than using override_dh_auto_build:. My main issue though is how to build from the VCS you refer us to? Please document the procedure for working with your source in debian/README.source when you use anything non-standard by choice. (Anything that's not building via a pure dpkg-buildpackage or gbp buildpackage invocation would count in my book as being non-standard. Please note that with gbp you can just ship debian/gbp.conf to make it 'just work'. Having all people who potentially want to build from source jump through hoops is not a good recipe for scalability.) I have thus not actually tried to build your package. Given I've not built it I also can not upload it (and this can't even be considered a complete review of it). > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849522 > [2] http://213.246.39.125/~leo/packaging/gnome-shell-extension-radio/ > [3] > https://gitlab.com/zapashcanon/gnome-shell-extension-radio-packaging/tree/master/debian > [4] https://github.com/hslbck/gnome-shell-extension-radio/issues/43 Regards, Andreas Henriksson
Bug#849493: RFS: vc/1.3.0-1 [ITP]
Hello Aleksey Samoilov, Thanks for your interest in packaging for Debian On Wed, Dec 28, 2016 at 05:59:36AM +0900, Aleksey Samoilov wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "vc" [...] > Alternatively, one can download the package with dget using this command: > > dget -xhttps://mentors.debian.net/debian/pool/main/v/vc/vc_1.3.0-1.dsc > > > Changes since the last upload: > > vc (1.3.0-1) unstable; urgency=medium > > * Initial release (Closes: #846491) I reviewed your package and it generally looks good. Minor comments: - not sure if enabling verbose dh is something I'd do by default. - dh compat 10 is the latest, not that it would buy you anything practically but staying with the current revision is usually a nice anyway. - you forgot to retitle #846491 to ITP (replacing RFP) and set yourself as owner. Over to the issue that didn't just make me sign and upload it: In Debian we have one shared namespace for all packages (and potential binaries, etc.). Shorter names often leads to collisions in the namespace. I don't see any other package currently named "vc" but still staying away from any 2letter name would in my opinion be preferrable. Atleast unless the name is obvious for most people and I think that's not the case here. For example myself (and likely many else) would being presented with only "vc" think it's about "virtual consoles". Certain things in the archive resolves the problem with the global debian namespace while still somewhat retaining their original name by adding a prefix, like eg. python-foo for what the python world generally knows as only 'foo'. Maybe you could consider renaming (both the source and binary) packages to simd-vc(-dev) or something similar? Please let me know what you think. (And a happy new year to you!) Regards, Andreas Henriksson
Bug#847105: wok source updated
Hello Lucio Correia, On Thu, Dec 15, 2016 at 02:58:46PM -0200, Lucio Correia wrote: > Breno, > > I've upload a new package with requested fixes. > > dget -x https://mentors.debian.net/debian/pool/main/w/wok/wok_2.3.0-1.dsc > > Let me know if anything else is necessary for wok. I took a quick look at this package and here are a few notes I made. I don't personally intend to sponsor you as this seems to be outside my expertice. - Seems like you've made an effort both to remove and use/depend on packaged javascript components like jquery etc, as well as adding missing sources for the minified bundled things. This should avoid the need for repackaging the orig tarball to remove source-less files, but at the same time it's a bit hard to check if you catched everything. Also, while I guess it's not strictly forbidden to bundle javascripts that aren't already packaged separately I think it's atleast frowned upon. You might want to consider joining in on the javascript packaging efforts and get (all of) your javascript dependencies packaged separately. - postinst pokes around in /etc and that is always a source for finding policy violating / release critical bugs. For example you check only for configure stage and enables the nginx site. This means you'll likely trigger on package upgrades and reenable a site that the local administrator might have disabled. Fix would likely be to check $2 for version to detect if configure is running under upgrade or newly-installed-package. - postrm removes files without checking ownership. I think it's ok for the purge action to be brutal, but the remove action should under no conditions cause harm to potentially locally configured things. For example you better check if sites-enable/wok is a symlink before removing it. The local admin might have replaced any of the files you installed under /etc with his own so removing them without very careful checking is likely to not end well. - consider dropping the conditional clauses for invoke-rc.d in both your postinst and postrm. The invoke-rc.d has been around for many releases and should always be available (or it would be a bug in the base system). I'm aware policy contains similar to what you're doing but policy is simply severely outdated. Directly invoking an init.d script can be potentially harmful and should never be done in todays system. (Policy even explicitly forbids it.) - 0001-Do-not-install-firewalld-conf-in-Debian.patch why? Please always document why. (fwiw, firewalld is available in debian also.) - 0001-Rename-wokd-to-wok.patch why? - 0001-Update-Datatables-Switch-and-Editable-libraries.patch patch is full of trailing whitespace addition noise. - 0005-Add-nginx.service-as-wokd.service-dependency.patch Executing kill in ExecStop is bad as it's async. This is bad and potentially causes 'restart' to fail as 'stop' action will not wait for stop to actually finish. HTH. Regards, Andreas Henriksson PS. you might want to block ginger RFS on ginger-base RFS and ginger-base RFS on wok RFS.
Bug#842588: RFS: photo-booth/1.0.1~rc1-1 [ITP Bug#788954]
Control: tags -1 + moreinfo
Hello Adam Wight,
On Sun, Oct 30, 2016 at 04:11:28PM +, Adam Wight wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "photo-booth"
[...]
A few notes:
- the Standards-Version you're specifying is outdated, see
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz
- you're using dh compat 9 and manually enabling --parallel,
if you upgraded to dh compat 10 you'd get that by default.
- The package fails to build for me. Removing/disabling
--parallel makes the package build. See attached build log.
Failing to build from source is obviously a blocker issue, thus
tagging moreinfo.
Please consider either fixing the upstream build system to
work correctly when building in parallel or (explicitly?)
disable parallel building. Please remove the moreinfo tag
when you have this issue resolved.
Regards,
Andreas Henriksson
W: /root/.pbuilderrc does not exist
[0mI: using fakeroot in build.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Sun Dec 25 15:22:45 CET 2016[0m
[0mI: pbuilder-time-stamp: 1482675765[0m
[0mI: Building the build Environment[0m
[0mI: extracting base tarball [/var/cache/pbuilder/base.tgz][0m
[0mI: copying local configuration[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: mounting /run/shm filesystem[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: policy-rc.d already exists[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Copying source file[0m
[0mI: copying [../photo-booth_1.0.1~rc1-1.dsc][0m
[0mI: copying [../photo-booth_1.0.1~rc1.orig.tar.gz][0m
[0mI: copying [../photo-booth_1.0.1~rc1-1.debian.tar.xz][0m
[0mI: Extracting source[0m
dpkg-source: warning: extracting unsigned source package
(photo-booth_1.0.1~rc1-1.dsc)
dpkg-source: info: extracting photo-booth in photo-booth-1.0.1~rc1
dpkg-source: info: unpacking photo-booth_1.0.1~rc1.orig.tar.gz
dpkg-source: info: unpacking photo-booth_1.0.1~rc1-1.debian.tar.xz
[0mI: Installing the build-deps[0m
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team <pbuilder-ma...@lists.alioth.debian.org>
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 9), cmake, gettext, libcairo2-dev, libopencv-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 9729 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on debhelper (>= 9); however:
Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on cmake; however:
Package cmake is not installed.
pbuilder-satisfydepends-dummy depends on gettext; however:
Package gettext is not installed.
pbuilder-satisfydepends-dummy depends on libcairo2-dev; however:
Package libcairo2-dev is not installed.
pbuilder-satisfydepends-dummy depends on libopencv-dev; however:
Package libopencv-dev is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
pbuilder-satisfydepends-dummy is already installed at the requested version
(0.invalid.0)
pbuilder-satisfydepends-dummy is already installed at the requested version
(0.invalid.0)
The following NEW packages will be installed:
autoconf{a} automake{a} autopoint{a} autotools-dev{a} bsdmainutils{a}
cmake{a} cmake-data{a} debhelper{a} dh-autoreconf{a} dh-python{a}
dh-strip-nondeterminism{a} file{a} fontconfig{a} fontconfig-config{a}
fonts-dejavu-core{a} gettext{a} gettext-base{a} gir1.2-atk-1.0{a}
gir1.2-freedesktop{a} gir1.2-gdkpixbuf-2.0{a} gir1.2-glib-2.0{a}
gir1.2-gtk-2.0{a} gir1.2-pango-1.0{a} gnome-icon-theme{a} groff-base{a}
gtk-update-icon-cache{a} hicolor-icon-theme{a} icu-devtools{a}
intltool-debian{a} libarchive-zip-perl{a} libarchive13{a} libatk1.0-0{a}
libatk1.0-data{a} libatk1.0-dev{a} libavahi-client3{a} libavahi-common-data{a}
libavahi-common3{a} libavcodec-dev{a} libavcodec57{a} libavformat-dev{a}
libavformat57{a} libavutil-dev{a} libavutil55{a} libbluray1{a} libbsd0{a}
libcairo-gobject2{a} libcairo-scri
Bug#849318: RFS: eoconv/1.5-1
Hello Dmitry Bogatov, Your changes looks fine and I can sponsor them for you if you wish but have some questions for you below first. On Sun, Dec 25, 2016 at 02:05:58PM +0300, Dmitry Bogatov wrote: > > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "eoconv" > > * Package name: eoconv > Version : 1.5-1 > Upstream Author : Tristan Miller <psychon...@nothingisreal.com> > * Url : http://en.nothingisreal.com/wiki/Eoconv > * Licenses: GPL-3+ > Section : text > > It builds those binary packages: > > * eoconv > > To access further information about this package, visit the following URL: > > https://mentors.debian.net/package/eoconv > > Alternatively, one can download the package with dget using this command: > dget -x > https://mentors.debian.net/debian/pool/main/e/eoconv/eoconv_1.5-1.dsc > > Alternatively, you can access package debian/ directory via git from URL: > https://anonscm.debian.org/cgit/users/kaction-guest/eoconv.git This repository looks whack. How do you build it? You should really add a debian/README.source with the details if you intend to use this as the official packaging vcs (as listed by the Vcs-* fields). If you really want to have just the debian directory in the VCS rather than the normal (in git world) full upstream sources, you should IMHO look into git-buildpackage and see the --git-overlay option in 'man gbp buildpackage'. (You'd want to set that option in your debian/gbp.conf) > > More information about eoconv can be obtained from > http://en.nothingisreal.com/wiki/Eoconv > > Changes since last upload: > > * New upstream release > * Update upstream maintainer GPG key (new identity) > * Patch to remove deperecated pragma is applied upstream, delete from > quilt series. > * Adjust debian/rules and eoconv.manpages to change of upstream build > system. Don't you want to give your last upload enough time to migrate to testing before uploading again? The 1.4-2 revision seems to contain useful fixes and if uploading now they would not reach testing in 4 days Regards, Andreas Henriksson
Bug#848993: RFS: llmnrd/0.2-1 [ITP]
On Fri, Dec 23, 2016 at 09:41:29PM +0100, Pali Rohár wrote: > On Friday 23 December 2016 14:46:53 Andreas Henriksson wrote: > > You use DAEMON_OPTS in the default file, while sysvinit seems to be > > standardizing on DAEMON_ARGS to avoid the messy work of later > > migration of conffile settings you might want to consider switching > > to DAEMON_ARGS now before the first version has been uploaded. You > > decide. > > Hm... Another option would be to use LLMNRD_OPTS. Looks like other > daemons in Debian (e.g. ntpd or rsync) use env variable _OPTS in > /etc/default/. > > What do you think about it? The reason to use DAEMON_ARGS is that if you ever where to switch to init-d-script in the future it would "just work" without needing messy conversion handling. Your current init scripts seems to already support DAEMON_ARGS already so it would just be a case of changing the default file to use DAEMON_ARGS. Giving it an even more specialized name lite LLMNRD_OPTS seems like you're expecting environment variable leakage between different services and that should in my opinion be handled by fixing the leakage instead. In the end this is all your choice. I've reviewed your existing package and is ready to upload as soon as you've decided on this matter. Poke me asap and there might still be a theoretical chance of making into stretch (although I basically assume it's already missed since we need to clear both the NEW queue + a 10 day migration time before 5 jan - and I don't expect to see 0-day NEW queue handling on christmas). Regards, Andreas Henriksson
Bug#848993: RFS: llmnrd/0.2-1 [ITP]
Hi again Pali Rohár, On Fri, Dec 23, 2016 at 11:29:59AM +0100, Pali Rohár wrote: > Now lintian on mentors shows warning: > > package-uses-experimental-debhelper-compat-version > 10 Yes, lintian is simply wrong/outdated here. It's just a tool to help you find issues, don't blindly follow lintian like if it was religion or policy. Normally you'd consider a lintian override in cases where you have confirmed lintian is wrong, but in this case the warning will likely go away by itself if you just give it some time for new lintian releases to appear. More importantly I wanted to mention a detail which might be useful to consider before uploading your package: You use DAEMON_OPTS in the default file, while sysvinit seems to be standardizing on DAEMON_ARGS to avoid the messy work of later migration of conffile settings you might want to consider switching to DAEMON_ARGS now before the first version has been uploaded. You decide. FYI, I also filed issues upstream for potential systemd service improvements. #15, #16. Shipping the file is as simple as running "echo etc/llmnrd.service >> debian/llmnrd.install" as dh compat 10 takes care of the rest for you. You might want to consider dropping the attached patch in debian/patches/ and adding debian/patches/series containing it's name to preserve default file configuration under both init systems. Regards, Andreas Henriksson --- a/etc/llmnrd.service +++ b/etc/llmnrd.service @@ -4,7 +4,8 @@ [Service] Type=simple -ExecStart=/usr/sbin/llmnrd +EnvironmentFile=-/etc/default/llmnrd +ExecStart=/usr/sbin/llmnrd $DAEMON_OPTS $DAEMON_ARGS Restart=on-failure User=nobody Group=nogroup
Bug#848993: RFS: llmnrd/0.2-1 [ITP]
On Fri, Dec 23, 2016 at 11:28:39AM +0100, Pali Rohár wrote: > Hi! Now I uploaded new version to mentors. > [...] > So I cannot use init-d-script easily. [...] Thanks for following up with a good explanation for the choices you make. [...] > Reasons why I did not install systemd service file: [...] You're ofcourse free to decide not to spend time on specific things, but at the same time by integrating your package in a less than optimal way with Debian you'll likely not attract as much interest from potential sponsors. Also, any network facing daemon really need to think about security implications. Just running as root and not caring is in my opinion not a good option. Other options than using the systemd feature would be: * help upstream implement the privilegies dropping feature. * use start-stop-daemon to start under a less privilegied user. Either way you'll need to implement the integration in your package to create the less privilegied user. See adduser. Not sure I'll consider this a blocker, but it's borderline for me. Will review your new revision when I find time. Regards, Andreas Henriksson
Bug#848993: RFS: llmnrd/0.2-1 [ITP]
Hello, On Fri, Dec 23, 2016 at 11:18:03AM +0100, Christian Seiler wrote: > Hi there, > > sorry for the formatting, writing this on my phone. > > > Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson > <andr...@fatal.se>: [...] > >on upstream issue #2. > > I'm not sure that'll work. In contrast to systemd services init scripts are > necessarily very distro-dependent. You can hack together something that's > cross-distro, but that's really ugly. [...] If only looking at major distributions Debian is likely the only one still using init scripts. OTOH apparently upstream thinks catering for the niche distros is important enough to file a bug report about it against his own software. Making the debian init script more portable could just be seen as a future improvement IMO. :P [...] > IMHO init scripts are distro-dependent anyway (see above). I didn't know > about the issues in init-d-script and since I use that in my own packages, > I'll look into that. Any pointers? [...] See existing bug reports, many contain init-d-script in title at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit My personal opinion is that for example breaking the LSB hooks that redirects direct /etc/init.d/foo invokations to using systemctl (which you really, really want to do when) under running systemd is quite unfortunate (#826214, #826215). I also find it very unfortunate that minor bugs that goes unfixed gets worked around depending on implementation-specific ways which means that the more people who use init-d-script the hard it will become to ever fix it up without breaking all users which then relies on the exact current/previous implementation. I've already asked about rolling back to the old skeleton but since noone is caring for sysvinit that has just ended up in void. When this issue was brought up with dh-make maintainers they instead decided to just completely drop sysvinit example. :/ If needed, we should probably discuss this further elsewhere as this is getting off-topic for the llmnrd sponsorship bug report. Regards, Andreas Henriksson
Bug#848993: RFS: llmnrd/0.2-1 [ITP]
Hello, Started looking at this bug report yesterday but got discracted... I spotted much the same issues as Chrisian so I'll instead just echo what he's saying and add a few comments. (I'll be able to sponsor you once the package is ready.) On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote: > Hi, > > as announced on IRC, I'm just doing a review, since I'm not a DD > and can't sponsor: > > - packaging in a VCS would be nice to have (plus the appropriate >Vcs-Browser / Vcs-... headers in d/control) > > - debian/copyright: > > * Tobias Klauser wasn't just active in 2016, the earliest >copyright notice of his I could find in the package is >from 2014; so s/2016/2014-2016/ there > > * missing mention of Copyright (C) 2012 Christoph Jaeger >for pkt.h > > * missing mention of Copyright (C) 2009-2012 Daniel >Borkmann for util.[ch] The debian/copyright issue is the only major reason I seen not to upload right now, because this issue will possibly mean rejection from NEW queue. Please carefully look at all source files and document copyright holders (autogenerated build files can be excluded). > > - debian/compat: why only 9? compat 10 is considered stable now >and unless you have a good reason I would recommend that any new >package should use compat 10. (please read the debhelper manual >though for information on what changed between 9 and 10) (compat 10 also gives you a nice automatic dh-autoreconf and dh-systemd. Don't forget both to bump debian/compat and the debhelper build-dependency.) > > - init.d: this file name works with dh_installinit, but is not >documented, so I'd recommend using llmnrd.init as the file name I see you're already credited by upstream so I assume you have already established a good relationship with your upstream. That's very good and very useful. Keep your upstream happy. Upstreams like contributions. You have a golden opportunity on upstream issue #2. > > - init.d: any particular reason you don't use init-d-script? (See >current /etc/init.d/skeleton for how this works; it will >automatically source /etc/default/$scriptname and interpret the >DAEMON_ARGS variable, so your init script could probably be just >a couple of lines that set the name of the executable) I'd recommend *against* "init-d-script". It has several outstanding issues, is unmaintained/orphaned/unproven and AIUI that also means the init script becomes debian-only. > > - any reason you don't install the systemd service provided by >upstream in addition to the init script? Please do. Please also consider improving the systemd service shipped by upstream. (Another golden opportunity for upstream contributions.) Most importantly have a look at the User= directive as it seems like running unprivilegied is preferred (see upstream issue #4). See also the Restrict*= directives provided by systemd which would also be nice to limit the potential attack surface. > > - debian/rules: nice and clean, I like it > > - upstream's build system does git id to get the git revision of >the current source - but that will clash if you have the packaging >in git (which can happen implicitly when someone checks out the >package source via e.g. dgit) > >Minor cosmetic thing, but makes the package non-reproducible >depending on whether you build from unpacked .dsc or from a git >environment > > - lintian warnings: >W: llmnrd: binary-without-manpage usr/bin/llmnr-query >W: llmnrd: binary-without-manpage usr/sbin/llmnrd > > > - you should probably add a line "export Q =" to debian/rules to >disable silent builds. While these look nicer, automated build >log scanners such as blhc aren't able to catch problems. debhelper today automatically disables silent rules when building on buildds. Using Q environment variables isn't the normal thing though. Even better than to explicitly disable silent build would be to hook up Q to the automatic debhelper version (V=1?). > > - Building in sbuild appears to work fine. > > - Package appears to work fine (though I don't have any llmnr >device running at the moment, so I could only test name >resolution of my own system) > > Regards, > Christian > Regards, Andreas Henriksson
Re: RFS: emerillon
On tor, 2010-04-08 at 22:10 -0400, Mathieu Trudel-Lapierre wrote: [...] Keeping in mind the (off-topic) discussion on bug 575384, the rationale for having this retrieved from git is that it simplifies (at least for me) maintaining and regularly building the package, if nothing else because I am already using the same or very similar recipes in other packages, including in helping maintaining NetworkManager in Ubuntu. [...] I suggested that you look at gnome-pkg-tools get-orig-source rules. Did you? That target normally fetches the real orig tarballs but can also be used to fetch from git as far as I could see when quickly looking at the cdbs script (by just setting DEB_UPSTREAM_GIT_REV). I do understand that you might want to easily be able to build local test versions straight from git for your testing, but these should IMHO not be uploaded as official Debian packages. I don't understand what advantage your never fetch the real orig tarball rules has over gnome-pkg-tools, please explain. (As I see it, with gnome-pkg-tools you get the best of both. Easy building from git and fetching of real tarballs for official uploads.) (I don't see that you're doing this for all *your* packages in *ubuntu* as an explanation and strong reason to go with your way over already established ways of handling this used by *many* maintainers inside *debian*.) -- Regards, Andreas Henriksson -- 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/1270793843.9289.100.ca...@amd64.fatal.se
Re: RFS: emerillon
On Fri, Apr 09, 2010 at 08:48:25AM +0200, أحمد المحمودي wrote: This package fails to build wether on Debian unstable or on Lucid. Buildlogs are attached. Probably because of GTK_DISABLE_DEPRECATED being defined... ./configure --enable-deprecations=no This should be one of the differences between upstream git and upstream release tarballs (but it's not uncommon that upstream forgets to disable deprecations in release tarballs as well hopefully this is something that will improve upstream with a couple of more releases). Regards, Andreas Henriksson -- 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/20100409074106.ga2...@amd64.fatal.se
Re: RFS: emerillon
On Fri, Apr 09, 2010 at 08:15:41AM -0400, Mathieu Trudel-Lapierre wrote: Le vendredi 09 avril 2010 à 08:17 +0200, Andreas Henriksson a écrit : [...] I do understand that you might want to easily be able to build local test versions straight from git for your testing, but these should IMHO not be uploaded as official Debian packages. I agree, any random git commit X shouldn't just be blindly uploaded as an official Debian package. However, I can see a reason already to publish a git commit for emerillon rather than the last release (but feel free to let me know if you feel this is unreasonable): the last release of emerillon (0.1.1) was in January, and since there has been commits to git with additional translations. I'd very much like to be able to include those, for the benefit of everyone. I think this is usually handled by cherry-picking from upstream git repo into a packaging repositorys branch which is then exported into debian/patches/ to avoid messing with the orig tarball ... or similar when the packaging is not done in a git repo. (Feel free to check out the rygel packaging for an example of a patch branch exported to debian/patches/.) Anyway, it's definitely common that debian/patches/ contains patches that comes from upstream and AFAIK not common to re-package the orig tarball and put it inside there. [...] At least for me, it makes sense to use already *known to me* and *comfortable to me* ways of handling this, in the event that I was to maintain it alone (or with other people who are familiar with this method). It doesn't mean it's something I invented, and actually isn't the case anyway. It's also clear I couldn't just use a method I was not aware of yet, but thanks for pointing it out to me. These reasons of using my method is obviously no longer a valid point if maintaining emerillon with pkg-gnome, where yes, gnome-pkg-tools is the established way of fetching tarballs or building from git. You're ofcourse welcome to handle your packages any way you wish. I was interested if you saw any actual general advantage in your way other then you being used to it. I guess we've confirmed not. This wasn't clear to me in our previous ping-pong and I'm sorry if repeating this question in new ways annoyed you. -- Andreas Henriksson signature.asc Description: Digital signature
Re: RFS: ampache (updated package)
I am looking for a sponsor for the new version 3.5.4-1 of my package ampache. uploaded, thanks. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mandos (updated package)
On Mon, Oct 26, 2009 at 10:56:41PM +0100, Teddy Hogeborn wrote: I am looking for a sponsor for the new version 1.0.14-1 of my package mandos. It fixes a FTBFS bug on mips and mipsel. Uploaded. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#543741: ettercap: should this package be orphaned?
Hello Lucas! Adding debian-mentors list to the discussion... On Wed, Aug 26, 2009 at 06:28:29PM +0200, Lucas Nussbaum wrote: Package: ettercap [...] While reviewing some packages, your package came up as a package that should maybe be orphaned by its maintainer, because: [...] [ To Andreas: are you interested in adopting ettercap? ] [...] Not being a heavy user of the program myself and to be honest not extremely entusiastic about it either I'd rather see someone else take lead. *If* this package becomes orphaned, I'll happily sponsor someone willing to maintain it. Maybe there's someone on debian-mentors who would be willing to adopt it if it's orphaned. Any volunteers? -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: nc6 (updated package)
Hello! Is there any reason for nc6 anymore? The default netcat has been renamed to netcat-traditional and the alternative is netcat-openbsd (which is protocol independent and thus does ipv6) It seems to me there's no need for nc6 anymore now that a proper protocol-independent version exists? Please enlighten me on what I've missed... -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mandos (updated package)
On tis, 2009-02-24 at 15:00 +0100, Teddy Hogeborn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors and others, I am looking for a sponsor for the new version 1.0.7-1 of my package mandos. Seems like something funky is going on. Are you missing terminating ` on mandos_user (line 58) and mandos_group (line 63) in initramfs-tools-hook? (Anyone receiving an unwanted CC of this mail should tell me and I shall refrain from sending further RFS mails to them.) Please continue to CC me if you want me to look at your packages! :) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: giver
Hello! I've had a quick look at your package, and even though I'm no expert on c# I think it could use some additional work to reach perfection. Please see the Debian CLI Policy http://pkg-mono.alioth.debian.org/cli-policy/ There are some stuff like using dh_clideps which is an absolute minimum for a C# package as far as I know. You should be able to find alot of other useful hints in there as well to improve your package. You'll find experts on this topic in #debian-mono on irc.OFTC.net (aka. irc.debian.org). You should probably ask them for review of your package as well! You should also try running lintian against your packages .changes file after building it. You'll get some warnings and with the -i switch you'll get some hints on fixes. Last but not least I'd like to question your choice of using GPL licensing for the package of a program licensed under MIT. This might cause trouble when sending things upstream (atleast if you get contributions which you are not the copyright holder of yourself and need to ask for permission to relicense). I recommend every maintainer do this regularly with as much as possible to keep the differences as small. (You could start with your manual page for example.) HTH, HAND. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: new version of bandwidthd.
tags 416651 + pending thanks New version of bandwidthd available at: http://fatal.se/pub/debian/bandwidthd/bandwidthd-2.0.1+cvs20050208-11/ (debdiff + piuparts log available in the same location) - lintian and linda clean - passes all piuparts tests. - adds LSB section to init script (which was requested last time I posted here). - fixes one etch-ignore RC bug. - fixes language errors in template + updates all translations. - adds german translation. - fixes minor error in maintainer script to generate a valid configuration even if iproute isn't installed. Please sponsor! :) Have a nice day! -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: bandwidthd - bandwidth monitoring daemon
Hello! I've already mailed my regular sponsor (which usually is a busy person) without any response (yet). As I really want a newer version in before Etch releases I'm sending a request for sponsorship to this list. Package description available at: http://packages.debian.org/bandwidthd The latest version fixes all reported bugs, including RC bugs, and some more: http://bugs.debian.org/bandwidthd New package available at: http://www.fatal.se/pub/debian/bandwidthd-latest/ It's lintian and linda clean (with no overrides). Things to watch out for: Please make sure that I've correctly made the maintainer changes as I've switched email address since last debian upload. (old: [EMAIL PROTECTED], new: [EMAIL PROTECTED]) Please make sure that your build environment is clean so the -noxpm version of GD is pulled in to have more options for the binary dependencies. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bandwidthd - bandwidth monitoring daemon
Please CC me to make it easier to reply as I'm not subscribed. Sorry, but it's not lintian clean: W: bandwidthd: init.d-script-missing-lsb-section Oh, sorry ... missed to check the binary package, only the source (*.dsc). Anyway, I have no useful information to provide in the LSB section. My daemon is pretty selfcontained. Seems pretty insane to not have a default instead of cluttering every init script with this header. I can make a new version providing a LSB section which basically would look the same as the example but with name and descriptions changed if anyone feels strongly for having one, otherwise I'll hold off on it and add it the next time I make a new version with other changes Please tell me if anybody consider this as a blocker for sponsoring. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bandwidthd - bandwidth monitoring daemon
On Fri, 2006-09-29 at 19:06 +0200, Thijs Kinkhorst wrote: Correct, but that's not release-critical. Hence I've uploaded the package as-is now to fix the outstanding issue. I trust the maintainer to address this lintian error in his next upload :) Many thanks! I sure will fix it the next time around... I'm sorry I missed to check the binary packages. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Replying to my own mail yesterday (again) no-traffic-bug which caused no-graphing-possible (skipping current run) fixed... (My suspicion than something more was broken was probably just because I was in a hurry and didn't notice that I've configured the subnet wrong.) Will submit this to the bandwidthd patch tracker at sourceforge. David: please continue with the review/merge... http://fjortis.info/pub/debian/bandwidthd-1.2.1/upstream/ New debian package 1.2.1b-14 which includes this fix and some other changes suggested by Eduard Bloch. Eduard: could you please test this new version (and investigate why bandwidthd doesn't pick up any packets on your system, possible subnet configuration error). http://fjortis.info/pub/debian/bandwidthd-latest/ Regards, Andreas Henriksson
Re: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Replying to my own mail yesterday (again) no-traffic-bug which caused no-graphing-possible (skipping current run) fixed... (My suspicion than something more was broken was probably just because I was in a hurry and didn't notice that I've configured the subnet wrong.) Will submit this to the bandwidthd patch tracker at sourceforge. David: please continue with the review/merge... http://fjortis.info/pub/debian/bandwidthd-1.2.1/upstream/ New debian package 1.2.1b-14 which includes this fix and some other changes suggested by Eduard Bloch. Eduard: could you please test this new version (and investigate why bandwidthd doesn't pick up any packets on your system, possible subnet configuration error). http://fjortis.info/pub/debian/bandwidthd-latest/ Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Replying to my own mail yesterday David: Please don't merge the patches I've sent you. I've looked into the skipping current run problem this morning. I haven't found the root cause but here are my conclusions so far... Affected: bandwidthd-1.2.1b-13 (debian package) bandwidthd-1.2.1b + all patches sent upstream (http://fjortis.info/pub/debian/bandwidthd-1.2.1/upstream/) bandwidthd-1.2.1b + fork patch sent upstream Not affected: (?) bandwidthd-1.2.1b (plain upstream) Minor bug: CommitData sets MayGraph=FALSE before initiating a graphing run to prevent another graphing run before the first one is finished and then calls WriteOutWebpages. MayGraph=TRUE is set when there is a (grapher) child to reap. WriteOutWebpages doesn't fork a child if there's nothing in DataStore. One solution to this would be to change WriteOutWebpages to return an error code so CommitData can reenable MayGraph if WriteOutWebpages fails to not prevent future graphing runs forever. Alternative solution: Check the datastore before changing MayGraph and calling WriteOutWebpages (this OTOH can't handle fork failures). Problem: The skipping current run problem is there because the minor bug above. The real bug is somewhere else though and I need to find out why the DataStore is empty. I can't see how any of my changes can cause this problem. I will have to look closer on the fork patch and investigate this further If the workarounds mentioned doesn't cure it for you or have anything to add in tracking down the problem please drop me a mail and I'll look at it as soon as I get my next chance to investigate. I'll post a status update later on Thanks to everyone testing the package! Thanks Adeodato for the suggestion on lists @lists.debian.org in muttrc which I've now added. Still I want to urge everyone to please CC me thanks. Regards, Andreas Henriksson
Re: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Replying to my own mail yesterday David: Please don't merge the patches I've sent you. I've looked into the skipping current run problem this morning. I haven't found the root cause but here are my conclusions so far... Affected: bandwidthd-1.2.1b-13 (debian package) bandwidthd-1.2.1b + all patches sent upstream (http://fjortis.info/pub/debian/bandwidthd-1.2.1/upstream/) bandwidthd-1.2.1b + fork patch sent upstream Not affected: (?) bandwidthd-1.2.1b (plain upstream) Minor bug: CommitData sets MayGraph=FALSE before initiating a graphing run to prevent another graphing run before the first one is finished and then calls WriteOutWebpages. MayGraph=TRUE is set when there is a (grapher) child to reap. WriteOutWebpages doesn't fork a child if there's nothing in DataStore. One solution to this would be to change WriteOutWebpages to return an error code so CommitData can reenable MayGraph if WriteOutWebpages fails to not prevent future graphing runs forever. Alternative solution: Check the datastore before changing MayGraph and calling WriteOutWebpages (this OTOH can't handle fork failures). Problem: The skipping current run problem is there because the minor bug above. The real bug is somewhere else though and I need to find out why the DataStore is empty. I can't see how any of my changes can cause this problem. I will have to look closer on the fork patch and investigate this further If the workarounds mentioned doesn't cure it for you or have anything to add in tracking down the problem please drop me a mail and I'll look at it as soon as I get my next chance to investigate. I'll post a status update later on Thanks to everyone testing the package! Thanks Adeodato for the suggestion on lists @lists.debian.org in muttrc which I've now added. Still I want to urge everyone to please CC me thanks. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi Eduard! ... and David, which I think might be interested in the bandwidthd skips graphing bug part right below. Eduard, sorry for not spotting your mail sooner... I'm not subscribed to debian-mentors and forgot to mention that I want to be CCed. For anyone interested in reading Eduards initial mail: http://lists.debian.org/debian-mentors/2004/07/msg00136.html The thread started here: http://lists.debian.org/debian-mentors/2004/07/msg00120.html To everyone for the future: Please _always_ CC me when replying to any of my mails or anything that you think I might be interested in Bandwidthd skips graphing bug... I also triggered this when installing bandwidthd on my workstation yesterday (trying out debconf changes which I finally managed to get working). I haven't done an extensive review of the code but from what I've seen it could need some cleanups (more then the few ones I've already done). About Previouse graphing run not complete... Skipping current run.. Bandwidthd forks of children for doing the graphing so that no packets get lost if it takes some time to finish. These children aren't reaped until the next graphing run... If it's time to graph and there aren't any children to reap bandwidthd currently thinks the previous run isn't complete. Atleast on my workstation yesterday there where no graph childs at all... just the main 4 processes I don't know (yet) how this is possible but I will look into in really soon. The only thing I can think of straight up is that the first fork fails (and checking for fork failures isn't done) and there's no children to reap creating the infinite loop which never forks any children. I don't think that fork failure is very likely to happen on my idle workstation every time I tried restarting bandwidthd so as I said, I'll have to look closer at it... Priority: critical Next issue... Bandwidthd outputs stuff to stdout like Packet Encoding: Ethernet. It's on the upstream TODO-list and also one of my highest priorities to change bandwidthd to behave like a daemon should This includes _not_ working out of the current directory as it currently does and using syslog for any messages. Closing stdin/stdout/stderr is required before the package can be moved to the debconf layout I've created. I've send a couple of minor patches to David Hinkle (upstream) which I'd like to see merged before I continue with more work though... (He said he'll do a final review and then merge them but I haven't heard anything and they haven't shown up in the cvs at sourceforge so I'm still waiting..) Priority: high Moving along Few things that come to my mind... - write the required config steps into README.Debian Don't know why I haven't done this yet Will do ASAP. My goal is to (optionally) manage the config file with debconf though, but as this will not happen until I've finished the daemon behave cleanup I'll document the config steps for now. Priority: critical - move TODO paragrah into debian/TODO file (there are extra handling methods for a such file) I've though about it, but my goal was to not have any unfinished buissness. I guess that was really naive of me.. Will do this... Priority: high - do not confuse with megabyte (m, MB, 10^6) and mebibyte (M, MiB, 2^10) I was under the impression that bandwidthd only did bits (not bytes) which simplifies this issue alot. :) The TODO-item in my readme is more about when to use upper- and lower-case. AFAIK this is how it's supposed to be: Mega and above should be uppercase. Kilo and below should be lowercase. Bit should be lowercase (and byte uppercase, but since there's only bits...) Seconds should be lowercase. But who cares Priority: low Guess I need to go shopping for medium priority issues. ;) Just started my vacation like 1 hour ago, so these issues will have to wait a couple of days. I've hopefully made some progress in a week unless someone else cracks all these nuts before I get a chance. I'll post a status report to the list later on Thanks to everyone who've posted comments so far! Regards, Andreas Henriksson
RE: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi Eduard! ... and David, which I think might be interested in the bandwidthd skips graphing bug part right below. Eduard, sorry for not spotting your mail sooner... I'm not subscribed to debian-mentors and forgot to mention that I want to be CCed. For anyone interested in reading Eduards initial mail: http://lists.debian.org/debian-mentors/2004/07/msg00136.html The thread started here: http://lists.debian.org/debian-mentors/2004/07/msg00120.html To everyone for the future: Please _always_ CC me when replying to any of my mails or anything that you think I might be interested in Bandwidthd skips graphing bug... I also triggered this when installing bandwidthd on my workstation yesterday (trying out debconf changes which I finally managed to get working). I haven't done an extensive review of the code but from what I've seen it could need some cleanups (more then the few ones I've already done). About Previouse graphing run not complete... Skipping current run.. Bandwidthd forks of children for doing the graphing so that no packets get lost if it takes some time to finish. These children aren't reaped until the next graphing run... If it's time to graph and there aren't any children to reap bandwidthd currently thinks the previous run isn't complete. Atleast on my workstation yesterday there where no graph childs at all... just the main 4 processes I don't know (yet) how this is possible but I will look into in really soon. The only thing I can think of straight up is that the first fork fails (and checking for fork failures isn't done) and there's no children to reap creating the infinite loop which never forks any children. I don't think that fork failure is very likely to happen on my idle workstation every time I tried restarting bandwidthd so as I said, I'll have to look closer at it... Priority: critical Next issue... Bandwidthd outputs stuff to stdout like Packet Encoding: Ethernet. It's on the upstream TODO-list and also one of my highest priorities to change bandwidthd to behave like a daemon should This includes _not_ working out of the current directory as it currently does and using syslog for any messages. Closing stdin/stdout/stderr is required before the package can be moved to the debconf layout I've created. I've send a couple of minor patches to David Hinkle (upstream) which I'd like to see merged before I continue with more work though... (He said he'll do a final review and then merge them but I haven't heard anything and they haven't shown up in the cvs at sourceforge so I'm still waiting..) Priority: high Moving along Few things that come to my mind... - write the required config steps into README.Debian Don't know why I haven't done this yet Will do ASAP. My goal is to (optionally) manage the config file with debconf though, but as this will not happen until I've finished the daemon behave cleanup I'll document the config steps for now. Priority: critical - move TODO paragrah into debian/TODO file (there are extra handling methods for a such file) I've though about it, but my goal was to not have any unfinished buissness. I guess that was really naive of me.. Will do this... Priority: high - do not confuse with megabyte (m, MB, 10^6) and mebibyte (M, MiB, 2^10) I was under the impression that bandwidthd only did bits (not bytes) which simplifies this issue alot. :) The TODO-item in my readme is more about when to use upper- and lower-case. AFAIK this is how it's supposed to be: Mega and above should be uppercase. Kilo and below should be lowercase. Bit should be lowercase (and byte uppercase, but since there's only bits...) Seconds should be lowercase. But who cares Priority: low Guess I need to go shopping for medium priority issues. ;) Just started my vacation like 1 hour ago, so these issues will have to wait a couple of days. I've hopefully made some progress in a week unless someone else cracks all these nuts before I get a chance. I'll post a status report to the list later on Thanks to everyone who've posted comments so far! Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi Goswin! Goswin von Brederlow [EMAIL PROTECTED] skrev den Thu, 08 Jul 2004 15:29:11 +0200: Nice one. I would like to see this included. Me too... ;) I also have some feature suggestions (if its not yet possible): Great! Unfortunately bandwidthd isn't very configurable, which on the other hand is also good because it makes it really easy to use. 1. logarithmic scale for bandwith and time options missing. 2. draw incoming positive and outgoing negative in the same graph or vice versa missing. I really like the idea though... I'll implement this some day. ;) 3. stack the different protocols on top of each other hmm. isn't the current graph stacked? a config option to make all protocols start from the bottom of the graph and an extra color for total might be good. Currently the next protocol adds on top of the previous. Although basing it from the ground up also requires intelligence on which protocol to put in front so they all show up and I guess quite some more code this isn't something I'm prepared to do with the package... on the other hand, nothing is stopping me from having a separate working tree where I do development against upstream. That will probably happen when the package require less time. (I currently have my hands full trying to learn debconf.) 4. draw line or bar graphs missing. Lines (you mean a line for the top right?) could be an easy solution to the which protocol to put in front problem that appears when starting all protocols from the baseline. 5. smoothing of the graph (e.g. each point is the average bandwith over the last hour while points are 10m apart, i.e. they overlap timewise) missing. I kind of like the edgy graphs, but smoothing shouldn't be very hard to implement as an option. 6. draw multiple views of the same data in one graph (e.g. unsmooth as bars, 1h avg. and 1d avg as lines overlayed) missing. If they all get implemented there's no reason why not to make a config option which not only gives you the possibility of choosing one. We can just as well change ip-timeframe-something.png to include GRAPHMETHOD and then just enable/disable each method in the config and adjust the html-output. :) Graphs are drawn quite frequently though and I guess multiplying all the work a couple of times will use up quite some resources. MfG Goswin As you see there's not really much flexibility in bandwidthd today. On the other hand thats probably why so many people like it. Flexible graphs can be created with mrtg/rrd-tool/scripts or whatever combination. The problem with that is just that it usually takes up alot of time and I guess many people like me don't really want to spend alot of time on network graphs. It's only something nice to have if you can get it for free. I'll send your comments to David Hinkle (upstream) and also keep them around for a rainy day to try to implement myself. Hopefully this will give him something to think about so he stops thinking that bandwidthd is for the most part to be stable and complete. ;P Thanks for your comments! Btw. If you are good at debconf and have a minute over to help me find out why the config script isn't getting triggered even though I've tried dh_installdebconf and manually copying the script and templates to tmp/DEBIAN/ please yell! :) -- Regards, Andreas Henriksson
RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi everybody! I'm looking for a sponsor to my bandwidthd package. BandwidthD tracks traffic on the local network. It uses libpcap to dissect the traffic and libgd to draw graphs (optional). Capable of logging traffic to CDF (optional), recovering from CDF (optional) and putting interface in promisc mode (optional). The daemon is totally stand alone and very easy to configure and use. Only dependancies are libpcap and libgd (any version). Example output available at http://fjortis.info/bandwidthd/. Relevant information about upstream: - Name: BandwidthD - Version : 1.2.1b - Upstream Author : David Hinkle [EMAIL PROTECTED] - URL : http://bandwidthd.sourceforge.net/ - License : GPL - Description : tracks network utilization per ip and draws graphs. Relevant information about package: - Name: bandwidthd - Version : 1.2.1b-13 - URL : http://fjortis.info/pub/debian/bandwidthd-latest/ - Packager: Andreas Henriksson [EMAIL PROTECTED] - Lintian clean : Yes. - ITP : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227768 - Example output : http://fjortis.info/bandwidthd/ Additional information: - Package also available from http://mentors.debian.net/. - RFP filed by upstream author. - Contact with upstream author established. (Changes done in the bandwidthd package are on it's way into the upstream cvs.) - Package compatible with Woody (simply build on woody and install). - Very easy to configure and use. Any suggestions, comments, flames welcome! Regards, Andreas Henriksson signature.asc Description: Digital signature
RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi everybody! I'm looking for a sponsor to my bandwidthd package. BandwidthD tracks traffic on the local network. It uses libpcap to dissect the traffic and libgd to draw graphs (optional). Capable of logging traffic to CDF (optional), recovering from CDF (optional) and putting interface in promisc mode (optional). The daemon is totally stand alone and very easy to configure and use. Only dependancies are libpcap and libgd (any version). Example output available at http://fjortis.info/bandwidthd/. Relevant information about upstream: - Name: BandwidthD - Version : 1.2.1b - Upstream Author : David Hinkle [EMAIL PROTECTED] - URL : http://bandwidthd.sourceforge.net/ - License : GPL - Description : tracks network utilization per ip and draws graphs. Relevant information about package: - Name: bandwidthd - Version : 1.2.1b-13 - URL : http://fjortis.info/pub/debian/bandwidthd-latest/ - Packager: Andreas Henriksson [EMAIL PROTECTED] - Lintian clean : Yes. - ITP : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227768 - Example output : http://fjortis.info/bandwidthd/ Additional information: - Package also available from http://mentors.debian.net/. - RFP filed by upstream author. - Contact with upstream author established. (Changes done in the bandwidthd package are on it's way into the upstream cvs.) - Package compatible with Woody (simply build on woody and install). - Very easy to configure and use. Any suggestions, comments, flames welcome! Regards, Andreas Henriksson signature.asc Description: Digital signature
BandwidthD packages for review.
Hi! I've created my first Debian packages, namely bandwidthd. Original source is available from: http://bandwidthd.sourceforge.net It's released under the GPL and is a logging and graphing daemon which uses libpcap to collect information and (optionally) create graphs per ip. Extremely easy to configure. The packages are available from: http://fjortis.info/pub/debian/ Latest version right now (1.2.1b-8) is at: http://fjortis.info/pub/debian/bandwidthd-1.2.1/8/ (They are built on my PentiumIII running Debian Testing...) Any suggestions on how to improve the package are welcome. I have read the new maintainer guide, but feel free to point me to any documentation that will be helpful for me. My plan is to, once I feel the package is mature enough, try to find a sponsor. Any suggestions on how to successfully establish a sponsor-relation is welcome. Primarily how to find a DD who is willing to sponsor my package. If you can help me out with creating manpages please get in touch with me! Hopefully I'll atleast get someone to test the package. Regards, Andreas Henriksson
BandwidthD packages for review.
Hi! I've created my first Debian packages, namely bandwidthd. Original source is available from: http://bandwidthd.sourceforge.net It's released under the GPL and is a logging and graphing daemon which uses libpcap to collect information and (optionally) create graphs per ip. Extremely easy to configure. The packages are available from: http://fjortis.info/pub/debian/ Latest version right now (1.2.1b-8) is at: http://fjortis.info/pub/debian/bandwidthd-1.2.1/8/ (They are built on my PentiumIII running Debian Testing...) Any suggestions on how to improve the package are welcome. I have read the new maintainer guide, but feel free to point me to any documentation that will be helpful for me. My plan is to, once I feel the package is mature enough, try to find a sponsor. Any suggestions on how to successfully establish a sponsor-relation is welcome. Primarily how to find a DD who is willing to sponsor my package. If you can help me out with creating manpages please get in touch with me! Hopefully I'll atleast get someone to test the package. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
