Re: RFS: mscgen
Hi Niels, I looked at v0.16-1 of mscgen that you uploaded to mentors.debian.net. We are good to go except for a few small details. Comments: - You've modified the .orig.tar.gz to remove a file that doesn't have license information. In such cases, you should indicate that in the version number of the package (by adding a +dfsg1 or such to it). See also - lintian-info for the tag dfsg-version-with-period. - Please also include a small README.source documenting the above and indicating the use of dpatch (and refer to the README.source of dpatch in it). This is necessary per policy 3.8.1 (and I think a lintian check corresponding to this is on its way). Suggestions: - Few of the example files have a syntax error in them because they have a C style comment. Please consider including a dpatch that makes them work with mscgen without the user having to do any modifications to them. - You don't have to have the .0 in Standards-Version: 3.8.2.0. Only the first 3 digits of the version number are enough. The package looks good and we can upload if the above Comments are fixed. Also, read on ... On 09/07/09 11:54 +0200, Niels Thykier said ... Yes, the 0.15 release suffers from two very apparent bugs (an easily introduced seg. fault and a regression on a promoted sample file). I think that these could, however, easily be changed into using being a 0.15 with some debian patches. This is preferred usually if development is too active to consider uploading an SVN snapshot to unstable. Though such a change would require that the version number of mscgen was lowered. How would I go about doing that in regards to my changelog? Merge all entries so far into 0.15-5 (updating svn-releases to patches)? Yes, you could do that. As as aside, I don't mind (and infact prefer it) that you don't add a new changelog stanza every time a new revision of the package is uploaded to mentors.debian.net In debian/control Priority need not be extra, you can make it optional. See the thread http://lists.debian.org/debian-mentors/2009/05/msg00666.html also Done. The Priority stills seems to be extra in v0.16-1. But this will not be a blocker for our upload. Please consider maintaining the package in collab-maint on alioth, you would want to add the Vcs-* headers to debian/control in case you do that. In case there is no location from where you can download the upstream source (because you are packaging an svn snapshot), it is a good idea to have a get-orig-source target in debian/rules that gets the upstream source from svn and makes an .orig.tar.gz. Both of these sounds like good ideas, I will have a look at them. Thanks for considering. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: mscgen
On 09/07/13 23:18 +0200, Niels Thykier said ... - You've modified the .orig.tar.gz to remove a file that doesn't have license information. In such cases, you should indicate that in the version number of the package (by adding a +dfsg1 or such to it). See also - lintian-info for the tag dfsg-version-with-period. Done - I used +dfsg-debian-number since +dfsgdebian-version wanted me to rename the orig to include the deb-version (I assumed it would make me unable to recycle the orig in case of a debian specific upgrade). I don't think you can use +dfsgdebian-revision, it would either be +dfsg-debian-revision (like you did) or +dfsgX-debian-revision where X starts from 0. And you will have to modify X only if find out later that you did some mistake in cleaning up for DFSG freeness. For other debian specific upgrades on the same version of the package, you will increment the debian-revision. - Please also include a small README.source documenting the above and Added, I decided to include (most of) the dpatch README.source (it seemed to be written for this purpose). I tend to just include a pointer on the dpatch README.source rather than duplicate that information. That way people always get the latest info on the dpatch usage (if that changes). When I read up on this I noticed that the upgrade checklist [1] uses the word should whereas the standard policy [4.14] uses recommendation [2]. Ah, I did not notice that. Perhaps file a minor debian-policy bug? Though such a change would require that the version number of mscgen was lowered. How would I go about doing that in regards to my changelog? Merge all entries so far into 0.15-5 (updating svn-releases to patches)? Yes, you could do that. As as aside, I don't mind (and infact prefer it) that you don't add a new changelog stanza every time a new revision of the package is uploaded to mentors.debian.net The Priority stills seems to be extra in v0.16-1. But this will not be a blocker for our upload. Right, forgot to move that over to the new upstream release build. Fixed it (again). I suppose you could've avoided this minor detail if the package was in a VCS :-). Also, the intention behind a new dch stanza for each upload is to show changes from the previous revision. This becomes redundant if the package is in VCS. It also makes life easier for a sponsor to review what changed. It is uploaded on mentors again (0.16+dfsg-1). Uploaded, thank you for your work. Hereafter, do contact me directly for sponsorship of updates to the mscgen package. I could not include the changelog for 0.15-1 in the changes file (the -v option to dpkg-buildpackage needs a valid version number that is present _before_ all the stanzas that one wants to include in the .changes file). You will have to mark the bug pending now (see the bts program in the devscripts package). And you will also have to close that bug when the package gets out of the NEW queue. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: mscgen
Hi Niels,
I looked at mscgen 0.16~svn35-1 on mentors.debian.net
On 09/07/02 16:51 +0530, Y Giridhar Appaji Nag said ...
On 09/07/01 14:58 +0200, Niels Thykier said ...
I am looking for a sponsor for my package mscgen.
It builds these binary packages:
mscgen - Message Sequence Chart (MSC) generator
I will take a look at this package.
Comments:
I noticed that the released version upstream is 0.15 and you choose to
package the svn version. Is this a conscious decision? Any reason why you
choose to do it this way? The svn snapshot is suitable for widespread user.
You might want to upload 0.15 to unstable and upload 0.16~svn to experimental.
For an svn snapshot package, the debian/watch file doesn't really make sense.
in debian/control, it doesn't look like you need versioned dependencies on
most of the packages in Build-Depends. You don't need to Build-Depend on
libc6 (Hint: see build-essential) and you probably need libgd2-noxpm-dev or
libgd2-xpm-dev but not both.
in the Package: mscgen stanza, you don't need libgd2-xpm | libgd2-noxpm in
Depends. That would be generated automagically from ${shlibs:Depends}
depending on what you have in Build-Depends based on the above (Hint: read
about substvars and ${shlibs:Depends}).
In the Description Can be used ... is a bit abrupt, you might want to say
mscgen can be used ... and There also exists extensions ... would rather
be extensions also exist although MSCs need not be complicated to
create or use. is a bit odd in there.
The description of the dpatch 01_debian-patch is verbose and is incorrect wrt
what the patch actually does (in particular about the linker flags).
in debian/rules, it is not necessary to have dh_installdocs TODO when there
is a debian/docs file that lists TODO. dh_makeshlibs is not needed.
Suggestions:
In debian/control Priority need not be extra, you can make it optional. See
the thread http://lists.debian.org/debian-mentors/2009/05/msg00666.html also
Please consider maintaining the package in collab-maint on alioth, you would
want to add the Vcs-* headers to debian/control in case you do that.
In case there is no location from where you can download the upstream source
(because you are packaging an svn snapshot), it is a good idea to have a
get-orig-source target in debian/rules that gets the upstream source from svn
and makes an .orig.tar.gz.
Cheers,
Giridhar
--
Y Giridhar Appaji Nag | http://appaji.net/
signature.asc
Description: Digital signature
Re: RFS: mscgen
Hi Niels, On 09/07/01 14:58 +0200, Niels Thykier said ... I am looking for a sponsor for my package mscgen. Upstream Author : Michael C McTernan michael.mcternan.2...@cs.bris.ac.uk URL : http://www.mcternan.me.uk/mscgen/ License : Partly GPL-2 (or later), partly LGPL-2.1 (or later) Section : devel It builds these binary packages: mscgen - Message Sequence Chart (MSC) generator http://mentors.debian.net/debian/pool/main/m/mscgen/mscgen_0.16~svn31-1.dsc I would be glad if someone uploaded this package for me. I will take a look at this package. Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/06/01 16:47 +0100, Richard W.M. Jones said ... On Thu, May 28, 2009 at 01:26:32AM +0530, Y Giridhar Appaji Nag wrote: [snip...] Suggestions: - It is usually a good idea to maintain the debian packaging also in a VCS. I'm of course maintaining this package in my own VCS. Is the suggestion to add the debian/ subdirectory to my upstream git: http://git.et.redhat.com/?p=febootstrap.git;a=summary I thought it was bad for upstream to have their own debian/ subdirectory? It is, because (a) makes it difficult for the Debian package maintainers to read from the diff.gz what changes went in to making the package (b) upstream usually don't care about Debian policy and may not be able to keep up with it. However, in this case you are both upstream as well as the Debian package maintainer and maintaining the changes for Debian on a different branch is a good idea. - Since /usr/share/doc/febootstrap/README complains rather loudly that it is required to patch 2.8, consider including the patches in the doc directory as well. Surely not necessary since fakechroot will always be = 2.9 (by the dependencies)? That is right. Originally I was (incorrectly) thinking that it would be useful for a backport because fakechroot in stable is 2.8 (stable backports require a stable chroot build with no additional modified packages). The new package is in the same place: http://www.annexia.org/tmp/debian/ I uploaded the package, with a couple of changes: changed the FSF address in debian/copyright to the latest, and removed dh_link from debian/rules (it was not necessary). Please do include these changes in future revisions of the package. Another note: I built with -v2.1-1 in debbuildopts but that doesn't include the changelog entry for 2.1-1 in the changes file. So you will have to tag #530425 on your own as pending and later close it when the package is out of new and installed into the archive. Thank you for your work. Feel free to contact me directly for sponsorship of future updates to febootstrap. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/06/03 01:16 +0530, Y Giridhar Appaji Nag said ... On 09/06/01 16:47 +0100, Richard W.M. Jones said ... The new package is in the same place: http://www.annexia.org/tmp/debian/ I uploaded the package, with a couple of changes: changed the FSF address in debian/copyright to the latest, and removed dh_link from debian/rules (it was not necessary). Please do include these changes in future revisions of the package. It would've been a good idea to indicate these changes in the changelog, unfortunately, I forgot to do that. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/05/28 17:17 -0700, Russ Allbery said ... Y Giridhar Appaji Nag app...@debian.org writes: I am not sure if enforcing extra in cases other than conflicts, Depends: on lower priority and very clear specialised requirements (elinks-lite, debug symbols etc.) gains us much. Oh, yes, I agree. I wouldn't go to people in general and ask them to make their packages priority: extra. I was only questioning because you'd said to raise the priority from extra to optional, and this didn't seem like a package where we'd want to make a special effort to move it into optional. Ah, I tend to use optional unless _really_ extra based on the above definition rule. And I am not particular that the OP _must_ change the package priority to extra (if that is a conscious decision), however, the section devel is inappropriate (and looks like Rich did not modify the dh_make templates appropriately). Regards, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/05/27 13:41 -0700, Russ Allbery said ... Y Giridhar Appaji Nag app...@debian.org writes: I read that part of policy (only likely to be useful if you already know what they are) as there is an optional package that has been built out of the same source package, but this one is built for special needs of that package. My understanding was that this was largely for packages that conflict with those in = optional. OK, I looked at debootstrap and cdebootstrap, while the former is extra the latter is optional. As a maintainer of policy, what do you think? I use extra for anything that I consider to be for special use, obscure, or otherwise probably not worth listing with all the other packages in its section for the casual browser looking for interesting packages. This seems to be a very subjective criteria. So is the text in policy: optional (In a sense everything that isn't required is optional, but that's not what is meant here.) This is all the software that you might reasonably want to install if you didn't know what it was and don't have specialized requirements. This is a much larger system and includes the X Window System, a full TeX distribution, and many applications. Note that optional packages should not conflict with each other. The tricky part is reasonably. So, for instance, funky old Kerberos v4 compatibility packages I consider extra, or a new but currently mostly unused SASL implementation, or Shishi (an interesting Kerberos implementation, but 99% of users will want either MIT or Heimdal instead). I agree with this particular example. But I could argue if would reasonbly want to install Kerberos if I Didn't know what it was. I've not seen ftp-master enforce the distinction between optional and extra, not even in the cases where it is very clearly defined in policy i.e. extra contains all packages that conflict with others with required, important, standard or optional priorities. And in case of Packages must not depend on packages with lower priority values (excluding build-time dependencies).. Look at the Debcheck pages. I am not sure if enforcing extra in cases other than conflicts, Depends: on lower priority and very clear specialised requirements (elinks-lite, debug symbols etc.) gains us much. Regards, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: RFS: masqmail (updated package)
On 09/05/28 17:21 +0200, markus schnalke said ... [2009-05-24 23:11] markus schnalke mei...@marmaro.de I am looking for a sponsor for the new version 0.2.21-6 of my package masqmail. Now, someone did ... but how can I find out, who? The mail from mentors does not contain a name and I found no upload logs or a similar source. Use the who-uploads script from the devscripts package. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: febootstrap
Hi Rich, On 09/05/27 11:03 +0100, Richard W.M. Jones said ... Dear mentors, I'm looking for a sponsor for my package 'febootstrap'. As the name may suggest, it's a program like 'debootstrap' that bootstraps Fedora root filesystems. In reality, it's a smallish shell script around the 'yum' command (already in Debian), and uses fakeroot and fakechroot to do its work. It also includes some image minimization tools, and a program to turn root filesystems into initramfs images. Are there compelling reasons why one would want to use febootstrap as opposed to mach? [1]. [1] http://packages.debian.org/sid/mach Package name: febootstrap Upstream URL: http://et.redhat.com/~rjones/febootstrap/ My Debian package is available here: http://www.annexia.org/tmp/debian/ Cheers, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: RFS: febootstrap
Hi Daniel, On 09/05/27 09:25 -0700, Daniel Moerner said ... On Wed, May 27, 2009 at 5:50 AM, Y Giridhar Appaji Nag app...@debian.org wrote: Are there compelling reasons why one would want to use febootstrap as opposed to mach? [1]. The last upstream release of mach was on April 19, 2007. The list of supported distributions in the control file seems to predate the Fedora Core to Fedora renaming. That seems to be the last-upload date to the Debian archive. Upstream released 0.9.4 in Aug 2008. Febootstrap also seems to have more features. Sure, and looks like apt for rpm is necessary to run mach. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
ITR: febootstrap [Was: Re: RFS: febootstrap]
On 09/05/27 19:11 +0100, Richard W.M. Jones said ... On Wed, May 27, 2009 at 06:20:27PM +0530, Y Giridhar Appaji Nag wrote: On 09/05/27 11:03 +0100, Richard W.M. Jones said ... Dear mentors, I'm looking for a sponsor for my package 'febootstrap'. Are there compelling reasons why one would want to use febootstrap as opposed to mach? [1]. [1] http://packages.debian.org/sid/mach The biggest problem with mach is it needs root, eg to run 'apt-get' or 'yum' or to run %post scripts. febootstrap does the right thing - it encapsulates any operations using fakeroot/fakechroot, so you can use it from ordinary non-root build scripts. I will review the package and will send in comments (if any) / do an upload. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: febootstrap
On 09/05/27 11:03 +0100, Richard W.M. Jones said ... Dear mentors, I'm looking for a sponsor for my package 'febootstrap'. My Debian package is available here: http://www.annexia.org/tmp/debian/ Is the latest verison of the package is in the febootstrap directory? I noticed from the previous conversation that you fixed a few things (e.g the typo, but that is still present in fakechroot-2.8-relchroot.patch -- or did you intend to fix that only upstream and not in the package yet?). Or is http://www.annexia.org/tmp/debian/febootstrap_2.1-3.dsc the file I can dget and look at the source package? Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/05/27 23:57 +0530, Y Giridhar Appaji Nag said ...
On 09/05/27 11:03 +0100, Richard W.M. Jones said ...
Dear mentors, I'm looking for a sponsor for my package 'febootstrap'.
I will review the package and will send in comments (if any) / do an upload.
Comments:
- in debian/control, Section should be admin (not devel) and priority should
be optional (not extra).
- debian/control: Remove ${shlibs:Depends} from Depends, you don't need it.
- I am not happy with the presubj file. People using a Debian package expect
to file bugs in the Debian BTS and forcing them to use a different reporting
system (that requires them to signup for an account) is not nice. As a
package maintainer, it is your responsibility to 'forward' bugs upstream
etc. Most users don't know what bug is with Debian packaging means.
BTW, presubj files can be installed using dh_bugfiles (but that is not
relevant here).
- A lot of dh_* commands from the dh_make templates are still in debian/rules
but commented, please remove them.
- dh_strip in debian/rules is not necessary.
- Your intention in using dh_installexamples in debian/rules is to install
examples folder also to /usr/share/doc, but examples are not installed,
see dh_installexamples(1)
- The CVS directories (both upstream tarball as well as in the diff.gz)
clutter the directories, please remove them.
- Please run latest lintian (as lintian -EI --pedantic) on the package. Of
the tags that lintian reports, build-depends-without-arch-dep,
debian-watch-file-is-missing (and also diff-contains-cvs-control-dir,
source-contains-cvs-control-dir?) are worth fixing. Hint: lintian-info(1)
and dpkg-buildpackage -I -i. For fixes that you intend to make in the
upstream tarball for the next upstream release, please include lintian
overrides (See dh_lintian(1))
- Typo in debian/changelog: Remove comments from Debian/rules Debian should
not be capitalised there.
- In debian/copyright, please include the How to Apply These Terms to Your
New Programs related text instead of just GPL (v2+) in License:
Suggestions:
- It is usually a good idea to maintain the debian packaging also in a VCS.
Even though this package is simple, since you are also the upstream, I was
wondering if you you would be interested in maintaining the Debian packaging
also in upstream git (possibly on a debian branch). In case you implement
this suggestion, please add Vcs-Git and Vcs-Browser to debian/control.
- Since you are using debhelper = 7, have you considered using dh (your
debian/rules will be very simple).
- Please do include an upstream changelog from the next upstream release
onwards.
- Since /usr/share/doc/febootstrap/README complains rather loudly that it is
required to patch 2.8, consider including the patches in the doc directory
as well.
Best regards,
Giridhar
--
Y Giridhar Appaji Nag | http://appaji.net/
signature.asc
Description: Digital signature
Re: ITR: febootstrap
On 09/05/28 01:26 +0530, Y Giridhar Appaji Nag said ... On 09/05/27 23:57 +0530, Y Giridhar Appaji Nag said ... On 09/05/27 11:03 +0100, Richard W.M. Jones said ... Dear mentors, I'm looking for a sponsor for my package 'febootstrap'. I will review the package and will send in comments (if any) / do an upload. Comments: [snip...] Suggestions: - It is usually a good idea to maintain the debian packaging also in a VCS. Even though this package is simple, since you are also the upstream, I was wondering if you you would be interested in maintaining the Debian packaging also in upstream git (possibly on a debian branch). In case you implement this suggestion, please add Vcs-Git and Vcs-Browser to debian/control. This will help tools like debcheckout (from the devscripts package) that some people use. I noticed that you are incrementing the debian revision each time you update the package in your personal repository. While some Debian package sponsors like it that way, I actually prefer the opposite (just one changelog entry per upload to the Debian archive). But I don't insist either way, feel free do it the way you like it. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: ITR: febootstrap
On 09/05/27 13:02 -0700, Russ Allbery said ... Y Giridhar Appaji Nag app...@debian.org writes: Comments: - in debian/control, Section should be admin (not devel) and priority should be optional (not extra). Hm, why would you increase the priority to optional? This seems like an extra thing to me -- only people with specific needs who already knows it exists are likely to want to use this package. I read that part of policy (only likely to be useful if you already know what they are) as there is an optional package that has been built out of the same source package, but this one is built for special needs of that package. My understanding was that this was largely for packages that conflict with those in = optional. OK, I looked at debootstrap and cdebootstrap, while the former is extra the latter is optional. As a maintainer of policy, what do you think? Regards, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
On 09/05/20 09:58 +0100, Jonathan Wiltshire said ... On Wed, May 20, 2009 at 11:40:43AM +0300, Peter Pentchev wrote: Right. I had to use `dput -f' to make it upload the same revision twice. What I usually do is just remove the old one via the mentors.d.n web interface :) m.d.n will allow a same version upload and overwrite it. dput uses the local *.upload file to decide whether it's been uploaded yet. With the -U option introduced in dput 0.9.4, you can avoid writing the *.upload file. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
Hi Andrea, On 09/05/20 08:07 +0200, Andrea Bolognani said ... On Wed, 20 May 2009 09:03:05 +0530 Y Giridhar Appaji Nag app...@debian.org wrote: That leaves us with just one TODO, the examples file. Please fix that and upload a new package to m.d.n and I'll sponsor an upload. So we should be done now :) Yes we are, and hence uploaded :). Please feel free to contact me directly for sponsorship of updates to the scrotwm package. Have fun, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
Hi Andrea, On 09/05/18 13:41 +0530, Y Giridhar Appaji Nag said ... On 09/05/17 23:36 +0200, Andrea Bolognani said ... On Mon, 20 Apr 2009 10:48:12 +0200 Andrea Bolognani e...@kiyuko.org wrote: I am looking for a sponsor for my package scrotwm. The upload would fix these bugs: 514322 I would be glad if someone uploaded this package for me. I will review this package. I took a look at the package and have a bunch of comments: - It is not necessary that README.source be installed, README.source is for source packages only. - Any reason why you call ./debian/rules unpatch and not just depend on the unpatch target? - Per policy, binary-arch and binary-indep are optional. In your case there aren't complex arch/indep parts, so you can just have a binary: target. - It might be a good idea to use a examples file rather than listing all the files installed as examples (you have more than one or two example files). - apm executable in Debian is in /usr/bin and not in /usr/sbin. Should you Patch baraction.sh appropriately? - Since spawn_term uses x-terminal-emulator, you would want to Recommend x-terminal-emulator | xterm? - There are references to a scrot program in screenshot.sh, where does one find that program? - Are you recommending xfonts-terminus package because terminus-medium is the default setting in scrotwm.conf? Just wondering if you could downgrade that to a suggests. The package looks neat otherwise, thank you for the good work :) Cheers, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
On 09/05/19 22:27 +0200, Andrea Bolognani said ...
On Tue, 19 May 2009 19:46:46 +0530
Y Giridhar Appaji Nag app...@debian.org wrote:
- It is not necessary that README.source be installed, README.source is for
source packages only.
Fixed in collab-maint.
By the way, how am i supposed to upload a fixed version of the package to
mentors.debian.net without adding a spurious changelog entry?
It is not necessary that you add a new dch entry. Just upload a new version
of the package and mentors.d.n will replace the package it has with the new
version.
- Any reason why you call ./debian/rules unpatch and not just depend on the
unpatch target?
So that calling `make clean' executes the clean target of the patched
Makefile.
It isn't really needed at the moment, but were I to further patch the
Makefile, I wouldn't need to modify the rules file. Moreover, since the
build system is patched right before building, it seems correct to remove
the patches right after clean.
That is right. And many packages would want to do just this (use the patched
Makefile to clean) and they tend to do this with the clean target depending on
two targets, clean-patched and unpatch.
I am certain that there are many situations where 'calling' debian/rules
recursively is not a good idea, but the scrotwm build system is rather simple
and not one of those. Re-reading debian/rules isn't a lot of overhead either
so it is OK even if you leave this as is.
- Per policy, binary-arch and binary-indep are optional. In your case there
aren't complex arch/indep parts, so you can just have a binary: target.
I think you're mistaking binary-{arch,indep} for build-{arch,indep}. While
the latter are optional, the former are required.
Ah, my mistake. You are right.
- It might be a good idea to use a examples file rather than listing all the
files installed as examples (you have more than one or two example files).
I tried creating an examples file, but neither debian/examples nor
debian/scrotwm.examples did the trick. Can you confirm this?
A debian/examples file that has the following three lines works for me.
initscreen.sh
baraction.sh
screenshot.sh
In debian/rules, I changed ...
binary-arch: build
[snip...]
dh_installexamples initscreen.sh baraction.sh screenshot.sh
to
binary-arch: build
[snip...]
dh_installexamples
- apm executable in Debian is in /usr/bin and not in /usr/sbin. Should you
Patch baraction.sh appropriately?
- There are references to a scrot program in screenshot.sh, where does one
find that program?
I later realised that there is a scrot package.
I'm not sure it's worth it to patch the examples.
It usually is. examples are 'more documentation' than documentation is. When
I see an examples folder in /usr/share/doc/foo/examples, I tend to expect them
to work.
I've patched the system-wide configuration file so that Scrotwm can be run
without any kind of configuration, but the example files are provided just
as guideline.
Thinking a bit more, In this particular case your examples have nothing to do
with scrotwm as such so I think it is OK to leave them unpatched.
- Since spawn_term uses x-terminal-emulator, you would want to Recommend
x-terminal-emulator | xterm?
I Recommend dwm-tools for a similar reason, so it makes sense.
Fixed in collab-maint.
- Are you recommending xfonts-terminus package because terminus-medium is
the
default setting in scrotwm.conf? Just wondering if you could downgrade
that
to a suggests.
Based on my tests, some fonts might not work. Moreover, as I explained above,
I'd like the window manager to be usable right after installation without the
need for further configuration.
OK.
That leaves us with just one TODO, the examples file. Please fix that and
upload a new package to m.d.n and I'll sponsor an upload.
Cheers,
Giridhar
--
Y Giridhar Appaji Nag | http://appaji.net/
signature.asc
Description: Digital signature
ITR: scrotwm - dynamic tiling window manager
Hi Andrea, On 09/05/17 23:36 +0200, Andrea Bolognani said ... On Mon, 20 Apr 2009 10:48:12 +0200 Andrea Bolognani e...@kiyuko.org wrote: I am looking for a sponsor for my package scrotwm. The upload would fix these bugs: 514322 I would be glad if someone uploaded this package for me. I will review this package. The packaging repository has been made available under the collab-maint umbrella[1], and the package itself has been uploaded to mentors[2]. [1] http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk This is empty. Did you forget to push your changes to bzr.d.o? Cheers, Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
On 09/05/18 10:52 +0200, Andrea Bolognani said ... On Mon, 18 May 2009 13:41:35 +0530 Y Giridhar Appaji Nag app...@debian.org wrote: [1] http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk This is empty. Did you forget to push your changes to bzr.d.o? $ bzr log http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk | wc -l 278 $ So no, the repository is definitely not empty ;) Indeed, false alarm. Thank you for clarifying :) Giridhar -- Y Giridhar Appaji Nag | http://people.debian.org/~appaji/ signature.asc Description: Digital signature
Re: RFS: evilvte (updated package) - VTE terminal emulator
Hi Wen-Yen, On Tue, Apr 14, 2009 at 14:27, Wen-Yen Chuang ca...@calno.com wrote: I am looking for a sponsor for the new version 0.4.4.1-1 of my package evilvte. It builds the binary package: evilvte Description: an VTE based super lightweight terminal emulator Please have evilvte Provides: x-terminal-emulator in your next upload. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: [Done] Re: RFS: libdaemon (updated package) -- 3rd try
On 08/09/10 14:19 +0530, Kartik Mistry said ... On Wed, Sep 10, 2008 at 12:51 PM, Kartik Mistry [EMAIL PROTECTED] wrote: Original RFS: http://lists.debian.org/debian-mentors/2008/08/msg00321.html I will look and upload it by today. Uploaded. Thank you for the upload Kartik. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: libdaemon (updated package) -- 3rd try
Hi, 3rd public attempt at finding a sponsor for libdaemon. I would be happy if someone can do a sponsored upload. On 08/09/01 14:30 +0530, Y Giridhar Appaji Nag said ... On 08/08/21 22:33 +0530, Y Giridhar Appaji Nag said ... I am looking for a sponsor for the new version 0.13-1 of libdaemon. This update is for a new upstream release and builds the following binary packages: [snip...] I haven't heard from my previous sponsor in 3 weeks and 3 mails, hence this request to a wider group. I am still looking for someone to sponsor libdaemon. Original RFS: http://lists.debian.org/debian-mentors/2008/08/msg00321.html Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: libdaemon (updated package) -- new upstream release 0.13-1
Hi debian-mentors, On 08/08/21 22:33 +0530, Y Giridhar Appaji Nag said ... I am looking for a sponsor for the new version 0.13-1 of libdaemon. This update is for a new upstream release and builds the following binary packages: [snip...] I haven't heard from my previous sponsor in 3 weeks and 3 mails, hence this request to a wider group. I am still looking for someone to sponsor libdaemon. Original RFS: http://lists.debian.org/debian-mentors/2008/08/msg00321.html Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: sclapp and pytagsfs (updated packages)
Hi Vincent, On 08/08/04 21:14 +0200, Vincent Bernat said ... I have uploaded this new version. Thank you :) I don't know if I have already told it (if so, excuse the repetition) but since pytagsfs has unittests, you can run them unless there is nocheck in DEB_BUILD_OPTIONS. somerule: # for example install ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) # run tests # clean tests (some pyc for example) endif It is up to you to decide if you want to run unittests. It should not be too CPU intensive but unittests are generally quick. pytagsfs and sclapp tests require proctor [1], which has not been packaged for Debian yet. That is why I don't run the unit-tests as of now. [1] http://www.doughellmann.com/projects/Proctor/ Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: sclapp and pytagsfs (updated packages)
Hi Vincent, On 08/07/26 15:01 +0200, Vincent Bernat said ... As noted Alexander, this one fails to build from source : Traceback (most recent call last): File setup.py, line 22, in module from tests.common import TEST_DIR, TEST_DATA_DIR File tests/common.py, line 17, in module from sclapp.util import importName ImportError: No module named sclapp.util make: *** [build-stamp] Error 1 I suppose that you need to put a stronger dependency on sclapp. I did declare a stronger dependency, but 0.7 onwards pytagsfs also build-depends on sclapp and I don't know how I ignored this. I fixed this and also updated pytagsfs to 0.7.1 (a bugfix release). The package is ready for upload: http://mentors.debian.net/debian/pool/main/p/pytagsfs/ This is better to be subscribed, especially when you put yourself out of mail-followup-to header. I added a Mail-Followup-To: to this email. Thanks and regards, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
RFS: sclapp and pytagsfs (updated packages)
Hi, I am looking for sponsors to upload new upstream versions of sclapp and pytagsfs. These updates build the following binary packages (with the said changes): python-sclapp (0.5.2-1) - framework for Python command-line applications * New upstream release + sclapp.txt is now licensed under GPLv2+ * Update Standards-Version to 3.8.0 http://mentors.debian.net/debian/pool/main/s/sclapp pytagsfs (0.7.0-1) - maps media files to an arbitrary directory structure * New upstream release + Needs python-fuse = 0.2 * Remove patch 02_fuse_exceptions merged upstream * Update Standards-Version to 3.8.0 (no changes required) The packages are lintian except a warning in sclapp which is a non-issue IMO (The newer NEWS file is installed as changelog and I also retained the older CHANGELOG file in /usr/share/doc/sclapp). http://mentors.debian.net/debian/pool/main/p/pytagsfs Both these packages have been in use by the sclapp/pytagsfs community for a while and there haven't been any issues reported, so I consider it safe to do an upload with a freeze around the corner. I should've sent a call with RFS much earlier (I had the packages ready about a month ago) but I would'nt have been able to respond to feedback in a timely fashion then. I am not subscribed to either debian-mentors or debian-python, so please Cc: me on responses. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
RFS: sclapp and pytagsfs (updated packages)
Hi debian-mentors, I am looking for someone to sponsor updates to my packages sclapp and pytagsfs. I haven't heard from my earlier sponsor for these packages since over three weeks and 4 emails, hence this request to a wider audience. This update builds the following binary packages which the changes as listed. python-sclapp (0.5.1-2) - framework for Python command-line applications - Re-order license sections in copyright so that the license of bulk of sclapp is right at the beginning. http://mentors.debian.net/debian/pool/main/s/sclapp pytagsfs (0.6.0-2) - maps media files to an arbitrary directory structure - Change Section from python to utils - Patch 01_bug_reporting to set the bug reporting location to Debian and not upstream. - Patch 02_fuse_exceptions to catch any exception and log an error when fuse initialisation fails (like the user is not in the fuse group). http://mentors.debian.net/debian/pool/main/p/pytagsfs Both the packages are lintian clean but for a warning in sclapp which is a non-issue IMO (The NEWS file is installed as changelog and I also retained the older CHANGELOG file in /usr/share/doc/sclapp). There is a new upstream version of sclapp (0.5.2) but it was updated for pytagsfs 0.7 series (but 0.7.0 is still at rc1 and unreleased) and upstream hasn't tested pytagsfs 0.6.0 with sclapp 0.5.2. So I am not updating sclapp to 0.5.2 yet. I update a bunch of packages as a DM (and didn't screw up things yet) and in case you don't mind me uploading sclapp / pytagsfs as a DM please do let me know and I will add a DM-Upload-Allowed: yes I am not subscribed to debian-mentors, please Cc: me on responses. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Re: RFS: python-sclapp and pytagsfs (new packages) - trying again
Trying again for a sponsor. I've got comments and updated both the packages: - sclapp for a complete debian/copyright file, thanks Bernd Zeimetz (who gave me some useful comments but indicated he is busy right now to discuss the changes) - pytagsfs for a new upstream release. pytagsfs provides very cool functionality :) Both the packages are fairly simple (sclapp is a pure python module and pytagsfs needs it). http://mentors.debian.net/debian/pool/main/s/sclapp/ http://mentors.debian.net/debian/pool/main/p/pytagsfs/ Original RFS: http://lists.debian.org/debian-mentors/2008/03/msg00358.html Cheers, Giridhar PS: I am not subscribed to debian-mentors, please Cc: me on responses. On 08/04/01 02:17 +0530, Y Giridhar Appaji Nag said ... Thanks to Bernd Zeimetz for comments, updated packages are available at mentors.debian.net (the site is back up). http://mentors.workaround.org/debian/pool/main/s/sclapp/ http://mentors.workaround.org/debian/pool/main/p/pytagsfs/ Giridhar On 08/03/31 23:16 +0530, Y Giridhar Appaji Nag said ... The packages are available at http://www.appaji.net/foss/debian/ (since mentors.debian.net is down, I am using my personal web space). -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFS: python-sclapp and pytagsfs (new packages)
Hi, I am looking for a long-term sponsor for sclapp, a python module and pytagsfs, a FUSE filesystem application. These are new packages [1] [2] that I ITPed. [1] http://bugs.debian.org/472769 [2] http://bugs.debian.org/471971 python-sclapp is a Python module that makes it easy to write well-behaved command-line applications and helps authors deal with issues like signal handling, terminal character encodings, standard output failures (broken pipes) etc. It is necessary to use pytagsfs. pytagsfs is a FUSE filesystem that arranges media files in a virtual directory structure based on the file tags. A set of audio files could be mapped to a new directory structure organizing them hierarchically by album, genre, release date, etc. File tags can be changed by moving and renaming virtual files and directories. The virtual files can be modified, opened and played just like regular files. I've added Debian Python Modules Team and Python Applications Packaging Team to as uploaders of sclapp and pytagsfs respectively. sclapp is already in the python-modules SVN, and even though pytagsfs has the Vcs-* fields in debian/control I haven't yet committed it to python-apps SVN (I will do that as soon as I am added to the python-apps alioth project). pytagsfs is lintian clean but sclapp has one warning that I consider a non-issue (CHANGELOG is the older ChangeLog file, now replaced by the NEWS file upstream). The packages are available at http://www.appaji.net/foss/debian/ (since mentors.debian.net is down, I am using my personal web space). dget http://www.appaji.net/foss/debian/sclapp_0.5.1-1.dsc dget http://www.appaji.net/foss/debian/pytagsfs_0.5.0-1.dsc These are my first python packages, comments are welcome. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: python-sclapp and pytagsfs (new packages)
Thanks to Bernd Zeimetz for comments, updated packages are available at mentors.debian.net (the site is back up). http://mentors.workaround.org/debian/pool/main/s/sclapp/ http://mentors.workaround.org/debian/pool/main/p/pytagsfs/ Giridhar On 08/03/31 23:16 +0530, Y Giridhar Appaji Nag said ... The packages are available at http://www.appaji.net/foss/debian/ (since mentors.debian.net is down, I am using my personal web space). -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Fwd: Re: [mentors-ops] New mentors site as a Google SoC 2008 Debian project?
If there are students on these liss considering applying for the Google SoC 2008, Christoph Haas has ideas[1] for an enhanced mentors.debian.net site. [1] http://wiki.debian.org/SummerOfCode2008/debexpo I suppose Christoph is a bit late in proposing this, 31st March is the last date for student applications, but we try ... :) Cheers, Giridhar - Forwarded message from Christoph Haas [EMAIL PROTECTED] - From: Christoph Haas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sat, 29 Mar 2008 16:38:39 +0100 Subject: Re: [mentors-ops] New mentors site as a Google SoC 2008 Debian project? User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.4 Giridhar, On Wed, Mar 26, 2008 at 04:54:29PM +0530, Y Giridhar Appaji Nag wrote: On 08/03/26 10:00 +0100, Christoph Haas said ... On Sat, Mar 22, 2008 at 09:06:46PM +0530, Y Giridhar Appaji Nag wrote: Would it make sense to propose development of the new mentors site (significant parts of it, if not all of it) as one of the projects for Google SoC for Debian? Honestly I have no experience with the SoC and how it's handled in reality. I have already collected the bits, pieces and suggestions and glued together in a half-sane documentation that might help to develop the basic application. So if we follow that concept then it will probably be boring like hell for a SoC student to understand that and This sort of a thing is OK for the SoC. See the netconf [1] proposal for example. [1] http://wiki.debian.org/SummerOfCode2008/netconf start to code. IMHO the SoC is about people developing their own concepts. But feel free to correct me. I'm an englishman in NY here. Not really. Students can propose their own projects and concepts, but it is necessary that the project falls within the scope of a mentoring organization and there should be a mentor for the project. The Debian SoC 2008 wiki page [2] has links to whatever you should know and more. [2] http://wiki.debian.org/SummerOfCode2008 Alright, I've spent a while with the SoC concept. So I proposed the project here: http://wiki.debian.org/SummerOfCode2008/debexpo Let's see what happens. :) Kindly Christoph -- [EMAIL PROTECTED] www.workaround.org JID: [EMAIL PROTECTED] gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586 ___ mentors-ops mailing list [EMAIL PROTECTED] http://workaround.org/cgi-bin/mailman/listinfo/mentors-ops - End forwarded message - -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Newlines in debconf template descriptions
Replying to self, so that people searching for this also find the solution. On 08/03/25 16:56 +0530, Y Giridhar Appaji Nag said ... I want to include a newline after the help text for each command line option of ifplugd (actually ifplugd --help) in the template Description for ifplugd/args. debconf-updatepo seems to concatenate these as one single paragraph, which is not neat and hence #471178. I can do a --skip-pot and update the po/templates.pot manually when I modify the templates (not very often), that would solve the bug, but is this the best way to go about it? I also don't know what the best way is to have a frontend display newlines (not new-stanzas). Inserting an extra space at the beginning of a template text line will ensure that the resulting po/templates.pot file has a '\n' at the end of the previous line. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Newlines in debconf template descriptions
Hi, I want to include a newline after the help text for each command line option of ifplugd (actually ifplugd --help) in the template Description for ifplugd/args. debconf-updatepo seems to concatenate these as one single paragraph, which is not neat and hence #471178. I can do a --skip-pot and update the po/templates.pot manually when I modify the templates (not very often), that would solve the bug, but is this the best way to go about it? I also don't know what the best way is to have a frontend display newlines (not new-stanzas). Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: ITS: ifplugd (updated package) -- ITA and multiple bugs fixed
On 08/03/03 15:56 +0200, Alexander Schmehl said ... Am 2.3.2008 schrieb Y Giridhar Appaji Nag [EMAIL PROTECTED]: I am looking for a long-term sponsor for version 0.28-5 of ifplugd that I filed an ITA for. ifplugd is a configuration daemon for ethernet Since I'm a regular user of ifplugd, I intend to sponsor your package as soon as I have the time for it -- hopefully that should be latest on wednesday. Thank you Alexander. PS: If anyone else intents to sponsor ifplugd: Feel free ;) Co-maintainers are welcome too. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ pgpHCUkHeEaac.pgp Description: PGP signature
RFS: ifplugd (updated package) -- ITA and multiple bugs fixed
Hi All, I am looking for a long-term sponsor for version 0.28-5 of ifplugd that I filed an ITA for. ifplugd is a configuration daemon for ethernet devices. It will configure your ethernet device when a cable is plugged in and de-configure it if the cable is pulled out. It is useful on laptops. I would be very happy if the sponsor can also be a co-maintainer. Even though ifplugd itself is fairly stable (and written by upstream on Debian), there are quirks in how people want to use it. I probably do not have sufficient knowledge to maintain the package as well as I would've liked to and there are a good number of bugs that could do with an extra pair of eyes, hence the request for a co-maintainer (However a long-term sponsor is welcome as well). If you are interested in co-maintaining the package, please add youself as an uploader before you do an upload. The package is in collab-maint [1], so commit the change there too :) [1] svn://svn.debian.org/svn/collab-maint/ext-maint/ifplugd/unstable and http://svn.debian.org/wsvn/collab-maint/ext-maint/ifplugd/unstable/?op=log A summary of changes: #452184 - ITA for ifplugd #360464, #461395 - remove ifplugd.hotplug on package upgrades #213910, #319727 - make debconf questions self-contained #368797 - init script can run with /bin/sh and doesn't need bash #404955 - don't start daemon for non-existing static interfaces #418918 - ifplugd.rules was executable, chmod to 644 on upgrade #393185 - change incorrect name of /etc/default file in manpage #414888, #414760, #457827, #458193, #460304 - debconf translations Plenty of packaging changes, and fixes all lintian warnings. There are a bunch of other bugs in the BTS that can be fixed, none very pressing I would say, and I'd like to tackle them for a later upload. The package is available on mentors.d.n: http://mentors.debian.net/debian/pool/main/i/ifplugd dget http://mentors.debian.net/debian/pool/main/i/ifplugd/ifplugd_0.28-5.dsc Comments are welcome. Cheers, Giridhar PS: I am on a weak internet link, a bit busy and not subscribed to debian-mentors since a few days, so please Cc: me on responses and expect a delay of a day or two before you hear back from me. -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
DM uploads to experimental [Was: Re: Anonymous delayed queue?]
On 08/02/14 13:20 +0900, Charles Plessy said ... therefore tried a delayed upload, but as I am a DM, I have no access to gluck. Is there a possibility to make delayed uploads as a DM ? (Of course, it is not a big deal, but it helps to make the TODO list shorter). On a related note, is it possible to upload to experimental as a DM? Would dak look at the Maintainers: or Uploaders: and DM-Upload-Allowed: fields for the package in unstable? Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: libdaemon v0.12-1 (ITA, packaging updates)
On 07/12/21 16:39 +0530, Y Giridhar Appaji Nag said ... I am looking for a long-term sponsor for v0.12-1 of libdaemon. The upload would fix #452187 (ITA). Sjoerd Simons commented on the package and did a sponsored upload. Thank you. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: axel
Hi Erik, On 07/12/25 23:09 +0100, Erik Schanze said ... It would be a pleasure for me to sponsor you. Unfortunately I had problem installing the resulted package: neo:~# dpkg -i /var/cache/pbuilder/result/axel_1.0b-7_i386.deb (Reading database ... 238528 files and directories currently installed.) Preparing to replace axel 1.0b-7 (using .../result/axel_1.0b-7_i386.deb) ... Unpacking replacement axel ... Setting up axel (1.0b-7) ... /var/lib/dpkg/info/axel.postinst: line 7: [: missing `]' Is this /usr/doc transition stuff still needed? I thought I'd keep it around to let people upgrade from oldstable. But people have suggested that I remove it. I have removed it now. I uploaded a new version to mentors.d.n (tested for axel/axel-kapt upgrade from stable and within unstable also). Kindly regards and Merry Christmas to my Bangalore friends, Thank you, and hope you had a good Christmas too :) Best regards, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFS: axel [Was: Re: Looking for a sponsor for axel v1.0b-7 (ITA, repackage, bug fixes)]
Trying again, with a 'filterable' subject :) Cheers, Giridhar On 07/12/21 14:07 +0530, Y Giridhar Appaji Nag said ... I am (still) looking for a long-term sponsor for axel (v1.0b-7). I have had an offer for help since my last request [1] over a month ago, but haven't heard back in over two weeks. the following changes [2] have been made to the package: [1] http://lists.debian.org/debian-mentors/2007/11/msg00208.html [2] http://svn.debian.org/wsvn/collab-maint/ext-maint/axel/unstable/?op=log - Use debhelper for packaging - Bump up Standards-Version to 3.7.3 - There are no changes outside the debian directory now (all patches are in debian/patches) - Patch to make axel-kapt use x-terminal-emulator instead of a hardcoded terminal program - Patch to fix lintian warnings on axel-kapt Desktop file (and make sure that it passes desktop-file-validate). - Use simple kaptain pop-ups for the Help and Bug Report (earlier it would try to invoke kmail). - Hermann J. Beckers was kind enough to update his earlier de.po file. I've included that in the package. - All the lintian informational messages are also fixed. That apart, v1.0b-4 has fixes for multiple important bugs. Thanks to kmap, mario for comments earlier, further comments are welcome :-). I would be glad if someone can sponsor an upload. The package can be found on mentors.d.n [3] [3] http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=axel Cheers, Giridhar PS: There hasn't been an upload since v1.0b-4, so please use a -v1.0b-3 option to dpkg-buildpackage for generating the changes file. -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Looking for a sponsor for axel v1.0b-7 (ITA, repackage, bug fixes)
Hi, I am (still) looking for a long-term sponsor for axel (v1.0b-7). I have had an offer for help since my last request [1] over a month ago, but haven't heard back in over two weeks. the following changes [2] have been made to the package: [1] http://lists.debian.org/debian-mentors/2007/11/msg00208.html [2] http://svn.debian.org/wsvn/collab-maint/ext-maint/axel/unstable/?op=log - Use debhelper for packaging - Bump up Standards-Version to 3.7.3 - There are no changes outside the debian directory now (all patches are in debian/patches) - Patch to make axel-kapt use x-terminal-emulator instead of a hardcoded terminal program - Patch to fix lintian warnings on axel-kapt Desktop file (and make sure that it passes desktop-file-validate). - Use simple kaptain pop-ups for the Help and Bug Report (earlier it would try to invoke kmail). - Hermann J. Beckers was kind enough to update his earlier de.po file. I've included that in the package. - All the lintian informational messages are also fixed. That apart, v1.0b-4 has fixes for multiple important bugs. Thanks to kmap, mario for comments earlier, further comments are welcome :-). I would be glad if someone can sponsor an upload. The package can be found on mentors.d.n [3] [3] http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=axel Cheers, Giridhar PS: There hasn't been an upload since v1.0b-4, so please use a -v1.0b-3 option to dpkg-buildpackage for generating the changes file. -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFS: libdaemon v0.12-1 (ITA, packaging updates)
Hi All,
I am looking for a long-term sponsor for v0.12-1 of libdaemon. The
upload would fix #452187 (ITA).
Even though only an ITA will be closed by the upload, there are plenty
of packaging changes that I did in this version:
- Add Homepage: and Vcs-*: fields to the control file. Packaging in
maintained on svn.debian.org in collab-maint/ext-main/libdaemon
- Bump up Standards-Version to 3.7.3. Move away from ${Source-Version}
to ${binary:Version}
- Update debian/compat to 5 and Build-Depend on debhelper (= 5)
- Provide a libdaemon0-dbg package with the debugging symbols in it.
- Added a debian/watch file
- In the build target, modify the doxygen generated man pages to prevent
lintian I: hyphen-used-as-minus-sign
- Use .docs and .examples file rather than specifying the files
explicitly them in debian/rules. Install the upstream README file as
changelog
libdaemon0 is fairly important and has a few packages Depends-ing on it.
The package is lintian clean. and is available on mentors.d.n [1].
Comments and suggestions are welcome.
[1]
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libdaemon
Giridhar
PS: Despite the -1 Debian version, this isn't a new upstream release for
Debian. The 0.12 upstream release was NMUed as v0.12-0.1.
--
Y Giridhar Appaji Nag | http://www.appaji.net/
signature.asc
Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On 07/12/20 10:30 +0530, Kumar Appaiah said ... What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw This could just mean that atlas3-base-dev has been added to the dependencies of a package that you build-depend on. Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for Is your environment up-to-date? Did you ensure that you have all the latest packages (in particular, those that you build-depend on) from unstable? With pbuilder, you are using the latest. be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? I would say that the order of resolving dependencies may be different for different programs. Consider this: Option 1: You install refblas3-dev and then lapack3-dev, so atlas3-base-dev is not brought in because refblas3-dev exists. Option 2: The buildd gets the lapack3-dev and hence atlas3-base-dev first and then it gets refblas3-dev. But, when you build the package, if there is a check (maybe via the configure script) for atlas3-base-dev and then for refblas3-dev, in Option 1, refblas3-dev is used and in Option 2 atlas3-base-dev is used. (I did not verify the above, but this is a possible explanation). If you want to avoid the above, you should Build-Depends: lapack3-dev | refblas3-dev. You should be good with just a Build-Depends: lapack3-dev but the | refblas3-dev helps backporters (if lapack3 doesn't depend on refblas3-dev in its older versions). Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On 07/12/20 12:04 +0530, Kumar Appaiah said ... On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote: Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? And the answer is, that the dsc file itself has it ordered! The generated dsc file has ordered B-Deps. I think this has to do with the dpkg-dev refactoring. I'll find out if a bug is warranted, though I'd appreciate more input. IMO, this isn't a bug. The order in which packages are listed in the build-depends shouldn't matter. Build-Depends: lapack3-dev | refblas3-dev or Build-Depends: refblas3-dev | lapack3-dev (if you please) is what you want to use really. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFS: splint (updated package) -- ITA and fixes a bunch of bugs
Hi, I am looking for a long-term sponsor for a new version 3.1.2.dfsg-1 of the package splint that I adopted. It builds these binary packages: splint - A tool for statically checking C programs for bugs splint-data - Data files for splint - A static checker for C programs splint-doc-html - Documentation for splint - A static checker for C programs The package is lintian and linda clean (I added overrides for the missing manpage warning because the manpage is installed by splint-data). Changes from previous version: #171437 - splint: KR / standard C mismatch #298261 - splint: new upstream version - please package 3.1.2 #343564 - splint: small typo on manpage #352298 - splint: manpage problems, useless files, copyright file problems, requires environment variables #424719 - ITA: splint -- A tool for statically checking C programs for bugs #430328 - ldbl128 transition for alpha, powerpc, sparc, s390 #436744 - splint: update debian/copyright to 3.7.2 standards template The changelog has a few other things listed. In particular, I have removed manual.pdf from the upstream source (the source of manual.pdf is a Microsoft word document). I also download and include the FAQ/bugs and changelog files from upstream website because they are not in the upstream source tarball. The orig.tar.gz can be constructed from the get-orig-source target in debian/rules. I also split the package into three parts because the arch-indep part is fairly large compared to the arch-dep part. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/splint - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/splint/splint_3.1.2.dfsg-1.dsc Comments, suggestions etc. are welcome. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: splint (updated package) -- ITA and fixes a bunch of bugs
On 07/12/17 00:43 +0900, Michal Čihař said ...
Just quickly looked at the package, will look more deeply tomorrow and
upload if noone else will be more interested/faster than me.
Thank you, nobody else has expressed interest yet.
Are you sure that splint-data (= 3.1.2) dependency is right? Are you
sure that splint 4.0 data will work with splint 3.1.2? And anyway you
should not hardcode version and use ${source:Version} or
${binary:Version} instead.
I got this right this time around. Thank you for pointing it out.
Also the debian/*.dirs files seems not to be needed at all.
Fixed.
I also sneaked in a couple of other cosmetic changes. BTW, there is an
SVN repository [1] on alioth in collab-maint/ext-maint for splint.
[1] http://svn.debian.org/wsvn/collab-maint/ext-maint/splint/unstable/?op=log
Please pass a -v3.1.1-6 option to dpkg-buildpackage because I bumped up
the debian revision number.
Further comments are welcome.
Cheers,
Giridhar
--
Y Giridhar Appaji Nag | http://www.appaji.net/
signature.asc
Description: Digital signature
Removing parts of upstream tar-ball, parsers, autobuilding
Hello World!, I have a bunch of questions: 1. I have an upstream source tar-ball that accidentally includes some files that are generated (and cleaned when a make distclean is issued) using the build system, and it is not necessary that I include those files in the orig.tar.gz file. These files are not binary files. Now, the best thing to do would be to copy the upstream tar-ball as-is to orig.tar.gz and have a patch that removes these files (this will result in a big diff). However, is it OK to create an orig.tar.gz file based on the upstream tar-ball with these files removed? Do maintainers create a new orig.tar.gz based on the upstream tar-ball and use it (even in the non pkg-modified-to-be-dfsg case)? 2. Are there packages in our archive that directly include parsers (generated by bison etc.) in the orig.tar.gz directly rather than Build-Depends-ing on the parser-generator? I am guessing that there shouldn't be any (unless the parser is hand-edited heavily later) because a bug in the generated parser because of the parser-generator would be difficult to spot. 3. Related to the above: do our autobuilders re-build all packages that Build-Depend on a newly uploaded package? Or, are bugs like the above handled when (a) People voluntarily build the package or a part of the archive once in a while (b) A new version of the package that Build-Depends on the parser-generator is uploaded. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Removing parts of upstream tar-ball, parsers, autobuilding
On 07/12/13 19:03 +0530, Y Giridhar Appaji Nag said ... 2. Are there packages in our archive that directly include parsers (generated by bison etc.) in the orig.tar.gz directly rather than Build-Depends-ing on the parser-generator? gccxml includes gcc's parser and doesn't require bison (even though the original grammar file is also included). The gccxml source package uses it like upstream does. I wouldn't be suprised if there are more such packages. I am guessing that there shouldn't be any (unless the parser is hand-edited heavily later) because a bug in the generated parser because of the parser-generator would be difficult to spot. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Removing parts of upstream tar-ball, parsers, autobuilding
On 07/12/13 23:18 +0100, Bernhard R. Link said ... * Thibaut Paumard [EMAIL PROTECTED] [071213 14:46]: Now, the best thing to do would be to copy the upstream tar-ball as-is to orig.tar.gz and have a patch that removes these files (this will result in a big diff). I tend to move those files to a safe place in the configure rule and put them back in place in the clean rule. It's often awkward, but that ensures that what is in the diff is meaningful. If those file can be easily deleted (i.e. the configure will not fail with them not around), then there is not reason to put them back or delete them from the .tar.gz, just delete them in the clean target. dpkg-source has special code to ignore deleted files so they will not bloat the .diff.gz. (and deleting them by the diff would be wasted space anyway, a single rm line in debian/rules clean target is much smaller than having a copy of the file in the diff). This is what I am doing now. Thank you all. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: Need help with new package
Hi Hans, On 07/12/05 12:53 +0100, Hans-J. Ullrich said ... if someone would take a look to the package, if I soemthing forgot. This is my very first try, so maybe there are mistakes. The package is called unicornscan. You should upload the package to mentors.debian.net and post a link here for people to download and comment. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: axel (updated package) -- Fixes ITA and a bunch of bugs
Hi Mario, On Tue, 20 Nov 2007 09:31:24 +0100, Mario Iseli wrote: On Tue, Nov 20, 2007 at 01:27:36PM +0530, Y Giridhar Appaji Nag wrote: I am looking for a sponsor for a new version 1.0b-4 of axel. This I would like to sponsor it... The package looks ok, but I have one Thank you :) question: Why don't you switch to debhelper as most people use it nowadays for such packages? I will certainly do that. I wanted to focus on closing the bugs that were open against axel before I switch to DH and do other packaging changes. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFS: axel (updated package) -- Fixes ITA and a bunch of bugs
Hi, I am looking for a sponsor for a new version 1.0b-4 of axel. This is for an ITA. I originally requested Wilmer (the previous maintainer) for a sponsored upload but it has been over 2 weeks since I heard from him, hence this request to a wider audience :) It builds these binary packages: axel - A light download accelerator - Console version axel-kapt - A light download accelerator - Console version front-end The package is lintian and linda (after applying patch at #434989 to linda) clean. Bugs fixed and other changes: 196431 - Prevent crash on long URLs and also Increase max URL length. 359368 - Acknowledges /usr/doc transition NMU 419679 - ITA (adopted after speaking to Wilmer) 448964 - Remove backup (~) files that crept-in in 1.0b-3 449368 - Prevent crash if FTP CWD fails 449507 - Use strncpy instead of strcpy for length sensitive copies - Bump up Standards-Version to 3.7.2 - Correct a typo in the menu file, install menu file in /usr/share/menu/ - Cleanup the .desktop file (remove lintian warnings) - Add Homepage: to the description I have a bunch of other dpkg 1.14.6 changes (Homepage: and Vcs-* are valid fields in debian/control) that I did not commit to SVN [1] yet. I intend to release those in a later upload (because I might change to git -- I am still evaluating options). [1] http://svn.debian.org/wsvn/collab-maint/ext-maint/axel/unstable/?op=log The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/axel - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/axel/axel_1.0b-4.dsc Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
On 05/08/06 18:20 +0200, Philipp Kern said ... On Aug 6, 2005, at 6:09 PM, Bastian Venthur wrote: I wonder, because even if I've cleaned up the whole sources, there would still be the .orig.tar.gz where all this copyrighted stuff is in. You just encountered the case where you need to repackage the source code, with the non-free parts removed from the .orig.tar.gz. And when you are removing such non-free parts, and they form a good part of the orig.tar.gz, you should add a .dfsg to the upstream version number when creating a package, to make it clear that the non-free parts were removed. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
On 05/07/14 04:42 -0400, kamaraju kusumanchi said ... But can you please tell me, where in the policy does it say that? I could have missed it while reading and would like to know which sentences convey this information. Please dont just give the section numbers, I am looking for some sentences quoted from the debian-ploicy here. Quoting from http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime 8.1 Run-time shared libraries [snip] The run-time library package should include the symbolic link that ldconfig would create for the shared libraries. For example, the libgdbm3 package should include a symbolic link from /usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. 8.1.1 ldconfig [snip] Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building source packages
On 05/07/08 15:50 +1000, John Skaller said ... What I am asking for is: apt-get install fred and it installs fred. If 'fred' is not available for my architecture, it is compiled and installed automatically and transparently. This occurs recursively for all dependencies, at least up to some base level. apt-get --only-source build-dep fred apt-get --only-source -b source fred should do what you want. This is how the pine source packages in are built. Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
