RFS: wmanager (update, adopt, fix bugs)
Dear mentors, I am looking for a sponsor for the new version 0.2.1-3 of the "wmanager" package; I am hereby attempting to adopt it, fix its two bugs, and bring it up-to-date with the Debian policy and the modern world in general :) It builds these binary packages: wmanager - Select a window manager at X startup The package appears to be lintian-, linda-, pbuilder-, and piuparts-clean. The upload would fix these bugs: 417758, 438265, 455007 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/wmanager - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget -x http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-3.dsc JFYI, here's my changelog entry for the 0.2.1-3 version: * New maintainer. Closes: #455007. * Switch to dpatch. * Support "noopt" and "nostrip" in DEB_BUILD_OPTIONS. Closes: #438265. * Install the HISTORY file as the upstream changelog. * Update Standards-Version to 3.7.3. * Since menu-2.1.26, install-menu is in /usr/bin, so change the path in debian/menu-method and bump the version in the menu dependency. * No longer ignore "make clean" errors. * Create the md5sums control file. * Fix a warning about a C++ string used as a C character string. * No need to pass -isp to dpkg-gencontrol any more. * Constify the arguments to WManager::_CutString(). * If "werror" is specified in DEB_BUILD_OPTIONS, make all compiler warnings fatal. * Fix the FTBFS with GCC 4.3 by including . Closes: #417758. * Only link against libfltk, it will bring in everything it needs. I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. pgpZmUVTBbWOZ.pgp Description: PGP signature
Re: ITR: wmanager (update, adopt, fix bugs)
On Mon, Dec 17, 2007 at 02:02:06PM -0600, Luis Rodrigo Gallardo Cruz wrote: > On Mon, Dec 17, 2007 at 06:44:23PM +0200, Peter Pentchev wrote: > > Dear mentors, > > > > I am looking for a sponsor for the new version 0.2.1-3 of the "wmanager" > > package; I am hereby attempting to adopt it, fix its two bugs, and bring it > > up-to-date with the Debian policy and the modern world in general :) > > I will review your package. You made quite a few changes, so it might > take me several days. No problem, thanks a lot! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgpkf1rcm2UJ2.pgp Description: PGP signature
Re: RFS: timelimit - Simple utility to limit a process's absolute execution time
On Sat, Dec 15, 2007 at 06:29:10PM +0200, Peter Pentchev wrote: > On Fri, Dec 07, 2007 at 05:11:36PM +0200, Peter Pentchev wrote: > > On Thu, Dec 06, 2007 at 09:09:58PM +0200, Peter Pentchev wrote: > > > Dear mentors, > > > > Hi, it's me again :) > > > > > I am looking for a sponsor for my package "timelimit". > > > > That part is still true :) However, after a private e-mail from > > a Debian developer, I have released a new upstream version of > > the timelimit utility and then uploaded a new Debian package to > > mentors.debian.net. > > Well, after a couple of comments from Damyan Ivanov off-list, I removed > configure, configure-stamp, and a couple of dh_* invocations from > the debian/rules file. Another comment from Damyan Ivanov, and dh_installdirs bit the bullet. Here's yet another version of my timelimit package... * Package name: timelimit Version : 1.1-1 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) * URL : http://devel.ringlet.net/sysutils/timelimit/ * License : Two-clause BSD Section : utils > > It builds these binary packages: > > timelimit - Simple utility to limit a process's absolute execution time > > > > The timelimit utility executes a command and terminates the spawned process > > after a given time with a given signal. A "warning" signal is sent first, > > then, after a timeout, a "kill" signal, similar to the way init(8) operates > > on shutdown. > > > > The package seems to be lintian-, linda-, pbuilder-, and piuparts-clean. > > > > The upload would fix these bugs: 453290 All that is still true. The package can be found on mentors.debian.net: - dget -x http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.1-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpMQwvG4ZFGP.pgp Description: PGP signature
Re: ITR: wmanager (update, adopt, fix bugs)
On Wed, Dec 19, 2007 at 07:04:25PM -0600, Luis Rodrigo Gallardo Cruz wrote: > On Mon, Dec 17, 2007 at 02:02:06PM -0600, Luis Rodrigo Gallardo Cruz wrote: > > On Mon, Dec 17, 2007 at 06:44:23PM +0200, Peter Pentchev wrote: > > > Dear mentors, > > > > > > I am looking for a sponsor for the new version 0.2.1-3 of the "wmanager" > > > package; I am hereby attempting to adopt it, fix its two bugs, and bring > > > it > > > up-to-date with the Debian policy and the modern world in general :) > > > > I will review your package. You made quite a few changes, so it might > > take me several days. > > Ok, my (very few) comments: > > 1. You have in debian/rules > > build: patch build-stamp > build-stamp: debian/control $(MAN) > > and > > clean: clean-patched unpatch > clean-patched: debian/control > > That's bad, because those rules might fail if the package is ever > built with -j, since they don't enforce patching before building and > cleaning before unpatching. > > Please change them to something like > > build: patch-stamp build-stamp > build-stamp: debian/control patch-stamp $(MAN) > > and > > clean: debian/control >[commands ...] >$(MAKE) -f debian/rules unpatch Done, see below for the updated package. However, there just might be a problem here - not with wmanager itself, but a more general problem. I pretty much copied those rules from the dpatch manual - the "DPATCH IN DEBIAN PACKAGES" section. The examples given there will not work with parallel make either. Should a bug against dpatch be filed to update the manual? Or should we wait until people come to at least some sort of agreement on the parallel make issue before filing any bugs and making changes? :) (yeah, I guess you can tell I've been following the parallel make discussion on debian-policy ;) > 2. It would be nice to pass along at least the makefile patch > upstream. Now, upstream does not seem to be very active. Is that > because of lack of bugs, or a lack of upstream? If the second case is > true, you will be having to act as _de facto_ upstream. Are you > willing and able to do this? I'm not raising an objection here, I just > want you to state it explicitely. Actually I intend to pass *all* the changes upstream - some as bugfixes (the C++ build fixes), some as recommendations (my reworked Makefile), and some as simple suggestions (the system-wide wmanagerrc that was already in the Debian package). I've still not tried to contact Meik Tessmer just because I wanted to wait until the patches are settled - both here in the Debian package and in the FreeBSD port of wmanager that I will also adopt. So, basically, at this point I don't know if the upstream author is active :) On to your actual question - yes, if the upstream author turns out to be inactive, I do intend to take up maintainership of wmanager, both the Debian package, the FreeBSD port, and the "upstream" sources themselves. It is already in my Subversion repository (the Vcs-svn control field points to it), with the Debian and FreeBSD changes integrated as far as possible, and I intend to keep it that way. > 3. Will you be wanting to keep debian/rules as is, or are you planning > to migrate to some helper package? If the second, be aware that I'm > not willing to sponsor cdbs based packages. I don't understand it and > I'm not really willing to learn it. Thus, I'd politely recommend ;) > you use debhelper. Well, I myself like debhelper very much, and both my local packages (most of which will never see the light of day for work-related reasons) and the timelimit package that I've RFS'd recently are all done using debhelper. With wmanager, the situation is somewhat weird - Tommi Virtanen actually used it in the past, but dropped it in version 0.2-4 seven years ago. We'll see - there's a very good chance that I will reintroduce debhelper at some point instead of doing things by hand (like the md5sums file creation). In this version, I just wanted to deviate as little as possible from Tommi Virtanen's work. > Other than that, your package is very nicely updated, so as soon as > you do the patching rules fixes, I can sponsor this version. Thanks a lot! :) I uploaded an updated version to mentors.debian.net - http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-3.dsc The only change is in the debian/rules file; no revision bump, no new changelog entries, since this falls under the "Switch to dpatch" entry that I already added at the very start. I saw your message earlier today about naming interim uploads ~1, ~2, etc., but IMHO this is not needed in this particular instance; I'll keep it in mind for th
RFS: timelimit (updated, add Conflicts)
Dear mentors, I am looking for a sponsor for the new version 1.1-2 of my package "timelimit". The new revision adds a conflict with the "netpipes" package since both install /usr/bin/timelimit. It builds these binary packages: timelimit - Simple utility to limit a process's absolute execution time The package appears to be lintian-, linda-, pbuilder-, and piuparts-clean. The upload would fix these bugs: 457444 The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.1-2.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgpypmpKHLmfk.pgp Description: PGP signature
Re: Information
On Tue, Dec 25, 2007 at 08:30:11AM +0100, Jean-Christian BEDIER wrote: > 2007/12/25, Mauro <[EMAIL PROTECTED]>: > > > > On Dec 24, 2007 5:17 PM, Jean-Christian BEDIER <[EMAIL PROTECTED]> > > wrote: > > > Thanks for your answer, i'm actually working on warning when i use > > lintian, > > > some of them seems to be strange, maybe someone could help me a little > > bit? > > > > could you paste those warnings here or on http://pastebin.com/ ? > > in my small experience, those warnings are mostly because you missed > > something in the control file, or the files in the directory debian > > are not well formated. > > Hi, > > I wish you add a merry xmas ;) > > Next a pastebin link for my lintian warning: > > http://pastebin.com/m4a6f2da0 > > Thanks for your help ! Just a note: the lintian utility itself explains some of its warnings in more detail if you give it the "-i" option, as in: lintian -i backup-nas-0.1-1_i386.changes Also, it may give even more information (meaning warnings ;) if you add the "-I" (uppercase "i") option: lintian -Ii backup-nas-0.1-1_i386.changes So... let's take a look at the warnings that are troubling you, one by one. (Disclaimer: I am not a Debian developer, I just try to help sometimes :) > W: backup-nas: binary-without-manpage backup-nas // OK i understand this > one no problem Yep, that's a pretty clearly worded warning :) It is part of the Debian Policy that every binary, be it an executable program, a script, or whatnot, should have a manual page. Now you have two options - either write a manual page and incorporate it into your "real" source (in the backup-nas-0.1.tar.gz, I assume, although it might be better to release a new version with the manual page), or write a manual page as part of the Debian package. If your Debian package uses debhelper, take a look at the dh_installman(1) program - it will look for an e.g. backup-nas.1 file in your debian/ directory and do the right thing with it. Of course, there are other ways to handle Debian-specific manual pages, too. > W: backup-nas: executable-not-elf-or-script > ./etc/backup-nas/backup-nas.conf // Why ? i already add this path in > my conffiles The problem here is not that it is not a conffile, but that it has been installed with the executable bit set. The lintian utility examines the permissions on all files that a package installs, and it considers a file to be executable if it, well, has the "x" bit set in its mode :) What commands do you use to actually place the backup-nas.conf file into the staging area's etc/ directory? Maybe you should specify a mode there - 644 would be more like a config file, maybe even 600 if only root should be able to see its contents. > W: backup-nas: syntax-error-in-debian-changelog line 7 "badly > formatted heading line" There seem to be two things wrong with the last line of your changelog: - it does not start with a space, but "--" straight away; - there is only one space after your e-mail address before the date. Take a look at section 4.4 of the Debian Policy; the last line of your changelog should be more like: -- Jean-Christian BEDIER <[EMAIL PROTECTED]> Mon, 24 Dec 2007 22:38:49 -0700 (note the leading space and the additional space before "Mon") Another comment about your changelog file: you seem to be leaving two blank lines between entries; one should be enough :) > W: backup-nas: syntax-error-in-debian-changelog line 7 "found eof > where expected more change data or trailer" This is a follow-up to the previous warning - it's just that lintian could not find a line that says who made the last slew of changes and when, simply because it could not parse your changelog's last line. Hope this helps; try to fix these warnings (I hope my advice has been at least somewhat correct), and feel free to ask for more help if needed :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgpg7SuSZokxC.pgp Description: PGP signature
Re: RFS: swedish (updated ispell and spell packages)
On Wed, Jun 11, 2008 at 05:49:38PM +0200, Jeremiah C. Foster wrote: [snip] > > > > - Convert debian/copyright to UTF-8 > > > > > > Done. > > > > You converted it to ASCII. Please use UTF-8, use e.g. iconv for that. Also, > > you've removed your own copyright statement for the Debian packaging. > > Added my copyright statement back, changed to UTF-8 using > iconv. The `file` command is still saying ASCII however. Not sure how > to determine proper encoding. E, I could be wrong here, but if a file is valid 7-bit ASCII, it actually *is* valid UTF-8, isn't it now? :) Thus, the Policy requirement that the Debian changelog be valid UTF-8 should really be satisfied by a valid 7-bit ASCII file - it just does not need to use any of the "UTF-8 extensions". G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. pgpnWsA0Gu5XI.pgp Description: PGP signature
Re: RFS: swedish (updated ispell and spell packages)
On Thu, Jun 12, 2008 at 03:54:30PM +0200, Tobias Toedter wrote: > On Wednesday 11 June 2008 17:57:47 Peter Pentchev wrote: > > E, I could be wrong here, but if a file is valid 7-bit ASCII, > > it actually *is* valid UTF-8, isn't it now? :) > > Yes, you're correct. However, the copyright file of the last upload is *not* > plain ASCII, it's encoded in ISO-8859-1, using special characters for > Swedish. Therefore, the conversion from ISO-8859-1 to UTF-8 should include > those characters as well, making it "real" UTF-8 instead of ASCII. Oh. Right then. Guess I should've spent half a minute to actually look at the last changelog. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpxBI9BfMf4O.pgp Description: PGP signature
RFS: s5 - A simple HTML-based presentation system
Dear mentors, I am looking for a sponsor for my package "s5". * Package name: s5 Version : 1.1-1 Upstream Author : Eric Meyer <[EMAIL PROTECTED]> * URL : http://www.meyerweb.com/eric/tools/s5/ * License : public domain Programming Lang: JavaScript, HTML, CSS Section : text It builds these binary packages: s5 - A simple HTML-based presentation system I've tested the package with lintian and pbuilder, both from sid. The upload would fix these bugs: 484630 The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/s/s5/s5_1.1-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpMJv1MuUNlB.pgp Description: PGP signature
RFS: wmanager - updated package
Hi, I am looking for a sponsor for the new version 0.2.1-4 of my package "wmanager". The last-time sponsor is currently busy, so I hope I could find somebody interested here :) It builds these binary packages: wmanager - Select a window manager at X startup The highlights of this update are: * Convert the package build to debhelper, minimizing the rules file. * Convert the copyright file to the new format. * The wmanager home site has risen from the dead, so add a watchfile. * Convert the manual pages to mdoc format. * Make the support scripts a bit more portable. The changelog entry has more detailed information. The package has been tested with lintian on the testing and unstable distributions. The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-4.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpqPG0b3wICe.pgp Description: PGP signature
Re: RFS: wmanager - updated package
On Wed, Jul 02, 2008 at 11:29:36PM -0400, Mike O'Connor wrote: > On Thu, Jul 03, 2008 at 01:43:00AM +0300, Peter Pentchev wrote: > > Hi, > > > > I am looking for a sponsor for the new version 0.2.1-4 of my package > > "wmanager". The last-time sponsor is currently busy, so I hope I could > > find somebody interested here :) > > I'm happy to have uploaded this one. Its a useful package for me. Thanks! And thanks for actually looking into it; I'll fix the FAQ bug as soon as possible :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgpxbxRgeeco3.pgp Description: PGP signature
Re: RFS: nemesis (updated package)
On Wed, Jul 02, 2008 at 05:13:14PM +0200, Andreas Wenning wrote: > On Wed, 2008-07-02 at 16:38 +0200, Cyril Brulebois wrote: > > Andreas Wenning <[EMAIL PROTECTED]> (02/07/2008): > > > Running "lintian -I" against the generated .deb gives a lot of "I: > > > nemesis: hyphen-used-as-minus-sign". There was a discussion on this list > > > about how to change this within the last few weeks, but can't seem to > > > find the message just now. > > > > The complete lintian message (“long description”) should help you find > > references, and learn how to fix this. > > It explains what the problem exactly is; but when the man-pages are > supplied by upstream patching all of them might not be the best > solution. I remember a message containing a sed command that might be > helpful, and managed to find it now: > http://lists.debian.org/debian-mentors/2008/06/msg00416.html Just for the record, unfortunately, sometimes patching upstream's manual pages is the only correct solution. There are cases when the "-" character appears in a manual page in both roles - as "a minus sign" and as a "real" hyphen. For example, look at my proposed changes to the xvkbd package in bug #484490 - these include a patch to the manual page that changes "-" to "\-" in *some* cases, but not always; there are uses like "UNIX-like" and "upper-case" when the hyphen is indeed a hyphen. Thus, an automated "escape all hyphens" is not always a correct solution, though it is usually the easiest :) Somewhat off-topic, but, well, that's one of the less important reasons why I always write mdoc manual pages :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgp2ikBrd3w9m.pgp Description: PGP signature
RFS: dante - fix RC bugs, adopt, update
Hi, I am looking for a sponsor for the new version 1.1.19.dfsg-1 of the "dante" package - I'm adopting it, fixing three RC bugs (dante does not currently have a version in testing), updating it to the new upstream release, and updating the Debian packaging a lot. It builds these binary packages: dante-client - SOCKS wrapper for users behind a firewall dante-server - SOCKS (v4 and v5) proxy daemon (danted) libdsocksd0 - SOCKS library for internal use by the dante client libsocksd0 - SOCKS library for packages built using libsocksd-dev libsocksd0-dev - Development files for compiling programs with SOCKS support The package has been tested by lintian on testing and unstable. The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), and 486756 (ITA). The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.dsc I would be glad if someone uploaded this package for me, so that dante has a chance of making it into Lenny now that the RC bugs are fixed. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpwMxwunDdMg.pgp Description: PGP signature
Re: RFS: dante - fix RC bugs, adopt, update
On Thu, Jul 17, 2008 at 05:19:37PM +0300, Peter Pentchev wrote: > Hi, > > I am looking for a sponsor for the new version 1.1.19.dfsg-1 > of the "dante" package - I'm adopting it, fixing three RC bugs > (dante does not currently have a version in testing), updating it > to the new upstream release, and updating the Debian packaging > a lot. > > It builds these binary packages: > dante-client - SOCKS wrapper for users behind a firewall > dante-server - SOCKS (v4 and v5) proxy daemon (danted) > libdsocksd0 - SOCKS library for internal use by the dante client > libsocksd0 - SOCKS library for packages built using libsocksd-dev > libsocksd0-dev - Development files for compiling programs with SOCKS support > > The package has been tested by lintian on testing and unstable. > > The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), > and 486756 (ITA). > > The package can be found on mentors.debian.net: > http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.dsc > > I would be glad if someone uploaded this package for me, so that dante > has a chance of making it into Lenny now that the RC bugs are fixed. I forgot this in the RFS, but here's the brief part of the changelog (the 1.1.19.dfsg-1 changelog entry itself also has a file-by-file breakdown of the changes): * New maintainer. Closes: #486756 * Do not start danted if the config file contains nothing but the default settings. Closes: #232574, #368322, #466082. * Use quilt to manage the patches, converting all existing ones. * Fix some lintian warnings * Add a watch file and README.source * Honor DEB_BUILD_OPTIONS * Separate the dante client library into a package of its own * Minimize the rules file by using debhelper 7 * Add the Vcs-Svn and Vcs-Browser source control fields * Add symbols files for the libraries * Convert the copyright file the machine-parseable format * Fix some C compiler warnings, mainly related to printf format strings * Enable build hardening unless DEB_BUILD_OPTIONS contains "nohardening" * New upstream version - remove the sockd/serverconfig.c upstream patch - doc/README.msproxy was removed * Install all sample configuration files [file-by-file changes snipped] G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgp1ytwR9Z1N6.pgp Description: PGP signature
Re: RFS: dante - fix RC bugs, adopt, update
On Thu, Jul 17, 2008 at 08:42:38PM +0300, George Danchev wrote: [snip] > > Peter, > I just uploaded that package, since it brings notable improvements over the > last one found in sid -- thanks for taking care of that! Thanks! > I have one question, though: did you feed upstream with the patches applied > to the upstream code, AFAICS they will be interested in all of them, but > `rename' ones ? No, I haven't sent them upstream yet. Of course I will - but I thought I'd wait for someone to review and upload the Debian package first, just in case some more changes are needed. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. pgp1T5SHMncqS.pgp Description: PGP signature
Perl testing (prove) dependencies
Hi, I have written a small utility for fetching variables from an INI-style configuration file, and ITP'd it at #502543 - confget. Actually, there already is a Debian package for it that I've been using at $REALJOB for a couple of weeks, but now that it seems to be mature enough to be shown to the world, I've got a dependency question :) After the build, confget may optionally run a test suite. This is done with Perl's prove(1) utility - t/*.t files, "1..8", "not ok 3" and such. Thus, prove(1) must be present at build time (I'm using debhelper 7 - it runs dh_auto_test automatically, since my Makefile has a test target, and I like that). Now, since confget already depends on debhelper which obviously pulls in most of Perl, may I just make use of that, or should I add an explicit build dependency on "perl | libtest-harness-perl", just in case the build mechanism changes at some point in the future? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgp9dnFoFh6Dm.pgp Description: PGP signature
Re: RFS: fig2sxd
On Sat, Oct 25, 2008 at 12:15:52PM +0200, Vincent Bernat wrote: > OoO En cette fin de matin?e radieuse du samedi 25 octobre 2008, vers > 11:07, Alexander B?rger <[EMAIL PROTECTED]> disait : > > >> ... "Debian" changelog, not upstream ... > > > Hmm. I do not have an upstream changelog, and all previous > > debian/changelog entries have the same problem. So what would you > > suggest to do: > > > * Move all debian/changelog entries actually describing upstream changes > > to a new upstream-changelog and replace it with "new upstream version" > > for all upstream versions (0.1 -- 0.19) in debian/changelog? > > * Keep the existing debian/changelog entries and start the upstream > > changelog now? > > > And, as adding a new upstream changelog would mean that the orig.tar.gz > > changes: > > > * Fix it in the next version (0.20) once there are upstream code > > changes? > > * Fix it now, keep version 0.19 and hide the new upstream changelog > > until 0.20-1? > > * Add the new upstream changelog via debian's diff.gz? That seems odd. > > * Make 0.20 and 0.20-1. What would then be the upstream changelog > > entry? > > No, no, you don't have to maintain yourself upstream changelog (you = as > Debian package maintainer). But he is also the upstream maintainer :) That's where his confusion comes from - he is asking how to combine the idea of an upstream changelog with the idea of a Debian changelog :) Let's start with the disclaimer that I am not a Debian developer :) Alexander, IMHO the best thing you could do in this particular case is, indeed, to release a new upstream version, 0.20, with a changelog included, and then package it for Debian with a "New upstream release" log for that particular version. The changelog you put in the 0.20 upstream tarball should include all the changes for previous releases - maybe just copied over from the Debian changelog. This will be useful to others who try to use fig2sxd on other OS's, not just Debian :) After you release the 0.20 upstream version of fig2sxd, make a new Debian package for 0.20-1. If there were other changes you did *to the Debian packaging* in the 0.19-1 version that this RFS is for (it seems you bumped Standards-Version at least), you may keep that changelog entry - though there are Debian developers who would frown upon changelog entries for versions that have never been uploaded, there are others who like the idea of keeping track of the changes one at a time. However, if you decide to keep the 0.19-1 Debian changelog entry, you should remove the actual description of the upstream changes and replace it with "New upstream version". IMHO it might be better to just skip 0.19-1 in the Debian changelog - change the top line to fig2xsd (0.20-1) so that it seems that you made the changes there :) And, IMHO, no, you should not modify earlier Debian changelog entries! Just leave them as they are - yes, there will be some duplication between the upstream and the Debian changelogs now, but in time, with new upstream versions of fig2sxd, it will become insignificant. Again, all of this is just my opinion, and IANADD :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpaIV9rN7dOK.pgp Description: PGP signature
Re: building package with different libs
On Wed, Oct 29, 2008 at 04:30:25PM +0100, Adeodato Sim?? wrote:
> * Thorsten Alteholz [Fri, 17 Oct 2008 20:06:09 +0200]:
>
> > Hi,
>
> Hello,
>
> > I need some advice on building packages with different libs.
> > Assuming that I have software S which needs to be linked against library L.
> > For whatever reason there are several implementations (L1, L2, L3) of
> > this library available. Each of them has its advantages and it would be
> > fine
> > to build three packages SL1, SL2 and SL3.
> > Unfortunately L1, L2 and L3 conflict each other. So what would be the
> > best way to build all three packages from one source package? Is this
> > possible at all?
>
> > To make this a bit more realistic: It is about package meep-mpi.
> > Currently it uses libhdf5-serial and there is a requet to build it with
> > libhdf5-mpich and libhdf5-openmpi. So my Build-Depends: in the source
> > section
> > needs to contain either libhdf5-serial-dev, libhdf5-mpich-dev or
> > libhdf5-openmpi-dev. Is it still possible to build package
> > meep-mpi-hdf5serial,
> > meep-mpi-hdf5mpich and meep-mpi-hdf5openmpi at the same time?
>
> If the different implementations conflict among them, I don't think you
> can build all three SL{1,2,3} binary packages from the same source
> package.
Well, actually, you can - just look at the various apache2 packages.
However, the build mechanism has to be a bit complicated...
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
When you are not looking at it, this sentence is in Spanish.
pgpny0U9CIfPO.pgp
Description: PGP signature
Re: building package with different libs
On Wed, Oct 29, 2008 at 06:00:15PM +0100, Adeodato wrote:
> * Peter Pentchev [Wed, 29 Oct 2008 18:09:07 +0200]:
>
> > > If the different implementations conflict among them, I don't think you
> > > can build all three SL{1,2,3} binary packages from the same source
> > > package.
>
> > Well, actually, you can - just look at the various apache2 packages.
> > However, the build mechanism has to be a bit complicated...
>
> Care to ellaborate? I don't think in that case the build-dependencies
> conflict, OR they are built from the same source package.
Oh, sorry, my mistake. A momentary lapse of reason made me forget that
the discussion is about conflicting build dependencies, not just about
conflicting binary packages. Apologies all around.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
What would this sentence be like if pi were 3?
pgpWMvVczwnIu.pgp
Description: PGP signature
RFS: truncate
Dear mentors, I am looking for a sponsor for my package "truncate". * Package name: truncate Version : 2007.03.13-1 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) * URL : http://devel.ringlet.net/sysutils/truncate/ * License : Two-clause BSD Section : utils It builds these binary packages: truncate - FreeBSD utility to truncate or extend the size of files The truncate utility adjusts the length of each regular file given on the command-line. This package is simply a redistribution of the utility as found in the FreeBSD base system. . Homepage: http://devel.ringlet.net/sysutils/truncate/ The package is lintian clean. The upload would fix these bugs: 415016 The package can be found on mentors.debian.net: - dget -x http://mentors.debian.net/debian/pool/main/t/truncate/truncate_2007.03.13-1.dsc Just for the record, I know about dd(1)'s "seek" option :) But still, truncate(1) is a useful utility in its own right, if only for the ease of invoking it and the intuitive command-line interface :) I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgpamrbxzKEfo.pgp Description: PGP signature
Re: RFS: truncate
On Wed, Apr 18, 2007 at 04:53:38PM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for my package "truncate". > > * Package name: truncate > Version : 2007.03.13-1 > Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) > * URL : http://devel.ringlet.net/sysutils/truncate/ > * License : Two-clause BSD > Section : utils [snip] > The package is lintian clean. *Sigh*. And 'ere I was, thinking I'd read the template carefully and changed everything :) This one ought to say "lintian and linda clean and pbuilder tested" :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. pgpIR8VerUOJT.pgp Description: PGP signature
Re: RFS: truncate
On Wed, Apr 18, 2007 at 03:27:09PM +0100, Neil Williams wrote: > On Wed, 18 Apr 2007 16:53:38 +0300 > Peter Pentchev <[EMAIL PROTECTED]> wrote: > > > truncate - FreeBSD utility to truncate or extend the size of files > > > > The truncate utility adjusts the length of each regular file given > > on the command-line. This package is simply a redistribution of the > > utility as found in the FreeBSD base system. > > That description doesn't help explain why a file would need to be > truncated (or extended without allocating space). Why truncate a file > (and lose data) rather than split the file? Why extend a file > without allocating space? Most (all?) file->open routines will support > complete truncation to zero length, what is the advantage of retaining > only a portion of the old data in the file and risk losing data > integrity (because not all regular files use linear storage). > XML/HTML/SGML are just three common regular file types that will react > badly to arbitrary truncation and ignore extended file sizes without > adding data. > > Don't assume that users will know anything about the FreeBSD version - > you need to explain the what, why and when of using such a program > without reference to assumptions based on *BSD. Argh. Yep, come to think of it, this brief description could be kinda misread this way :) Actually, the reference to FreeBSD was more of a recognition of the truncate original authors, not a usage reference or anything - but you're right, in the absence of any usage references at all... Actually, the reason that pushed me to port truncate(1) to Debian was the need to create a large empty file while tracking down a problem with a webserver's large file support. Other than that, I've used it to initialize loopback-mount filesystems, maim lastlog files and news spool indices by only leaving the headers, and "sudo truncate -s0 file" as an easier-on-the-fingers alias for "sudo sh -c ': > file'" :) So... what do you think about the following description? Or should I file a wishlist bug against bsdmainutils to get truncate(1) included there? The truncate utility adjusts the length of each regular file given on the command-line. It may be used to create sparse files (zero-filled files that do not take up any space on disk) for virtual filesystems, empty data files, or simply large files for testing. It may also empty a file by setting its size to 0 bytes, or remove all but a portion of the data, most useful when the file has a well-known record-based structure like e.g. filesystem images, news spools, utmp or sa(8) accounting files, graphics images, etc. . This package is simply a redistribution of the truncate utility as found in the FreeBSD base system. . Homepage: http://devel.ringlet.net/sysutils/truncate/ Thank you and the others for the prompt replies and comments! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgpjHTGPWzElK.pgp Description: PGP signature
Re: RFS: truncate
On Thu, Apr 19, 2007 at 10:35:17AM +0200, Mike Hommey wrote:
> On Thu, Apr 19, 2007 at 10:34:24AM +0300, Damyan Ivanov wrote:
> > -=| Peter Pentchev, 19.04.2007 00:54 |=-
> >
> > > Or should I file a wishlist bug against bsdmainutils to get
> > > truncate(1) included there?
> >
> > I'd say bsdmainutils fits perfect. Its description says:
> >
> > lots of small programs many people expect to find when they use a
> > BSD-style Unix system
>
> Even better, the short description: collection of more utilities from FreeBSD
>
> > So please file a whishlist bug for bsdmainutils. Bonus points for
> > providing a patch :)
>
> I'd say it would be better to reassign the ITP and retitle it appropriately.
Yep, that's what I was going to do. I will reassign it and retitle it,
after I've come up with a patch - most probably a bit later today.
Once again, thanks to all of you for the advice - and I wonder how
I could have possibly missed the bsd{,main}utils packages :\
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This would easier understand fewer had omitted.
pgpu1VSrufq3m.pgp
Description: PGP signature
Re: RFS: truncate
On Thu, Apr 19, 2007 at 11:55:16AM +0300, Peter Pentchev wrote:
> On Thu, Apr 19, 2007 at 10:35:17AM +0200, Mike Hommey wrote:
> > On Thu, Apr 19, 2007 at 10:34:24AM +0300, Damyan Ivanov wrote:
> > > -=| Peter Pentchev, 19.04.2007 00:54 |=-
> > >
> > > > Or should I file a wishlist bug against bsdmainutils to get
> > > > truncate(1) included there?
> > >
> > > I'd say bsdmainutils fits perfect. Its description says:
> > >
> > > lots of small programs many people expect to find when they use a
> > > BSD-style Unix system
> >
> > Even better, the short description: collection of more utilities from
> > FreeBSD
> >
> > > So please file a whishlist bug for bsdmainutils. Bonus points for
> > > providing a patch :)
> >
> > I'd say it would be better to reassign the ITP and retitle it appropriately.
>
> Yep, that's what I was going to do. I will reassign it and retitle it,
> after I've come up with a patch - most probably a bit later today.
>
> Once again, thanks to all of you for the advice - and I wonder how
> I could have possibly missed the bsd{,main}utils packages :\
Okay, I've handed bug #415016 over to the bsdmainutils package, and
Daniel Baumann kindly said he'd take a look at it. So, I guess that
this RFS is no more - after all the great advice, this is an ex-RFS :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I had finished this sentence,
pgpyf7jaOoNHX.pgp
Description: PGP signature
Re: RFS: truncate
On Thu, Apr 19, 2007 at 04:49:40PM +0100, P?draig Brady wrote: > Chris Lamb wrote: > > Mike Hommey wrote: > > > >> Very frankly, this should go into coreutils. > > > > Or bsdmaintutils/bsdutils? > > Yes that's the obvious place for it. > Note one can achieve the same functionality with dd > See: http://www.pixelbeat.org/scripts/truncate Yep, I did mention dd(1)'s "seek" option in my initial RFS :) Still, I was not aware of a working version based on dd; thanks for the pointer to the script, and for writing it! :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgpO7eEtF1pjX.pgp Description: PGP signature
RFS: timelimit - Simple utility to limit a process's absolute execution time
Dear mentors, I am looking for a sponsor for my package "timelimit". * Package name: timelimit Version : 1.0-1 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) * URL : http://devel.ringlet.net/sysutils/timelimit/ * License : Two-clause BSD Section : utils It builds these binary packages: timelimit - Simple utility to limit a process's absolute execution time The timelimit utility executes a command and terminates the spawned process after a given time with a given signal. A "warning" signal is sent first, then, after a timeout, a "kill" signal, similar to the way init(8) operates on shutdown. The package seems to be lintian-, linda-, pbuilder-, and piuparts-clean. The upload would fix these bugs: 453290 The package can be found on mentors.debian.net: - dget -x http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.0-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpG6ZX9R1DEW.pgp Description: PGP signature
Re: RFS: timelimit - Simple utility to limit a process's absolute execution time
On Thu, Dec 06, 2007 at 09:09:58PM +0200, Peter Pentchev wrote: > Dear mentors, Hi, it's me again :) > I am looking for a sponsor for my package "timelimit". That part is still true :) However, after a private e-mail from a Debian developer, I have released a new upstream version of the timelimit utility and then uploaded a new Debian package to mentors.debian.net. * Package name: timelimit Version : 1.1-1 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) * URL : http://devel.ringlet.net/sysutils/timelimit/ * License : Two-clause BSD Section : utils > It builds these binary packages: > timelimit - Simple utility to limit a process's absolute execution time > > The timelimit utility executes a command and terminates the spawned process > after a given time with a given signal. A "warning" signal is sent first, > then, after a timeout, a "kill" signal, similar to the way init(8) operates > on shutdown. > > The package seems to be lintian-, linda-, pbuilder-, and piuparts-clean. > > The upload would fix these bugs: 453290 All that is still true. The package can be found on mentors.debian.net: - dget -x http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.1-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? pgpg92umknr7Y.pgp Description: PGP signature
Re: Packages getting created without signature
On Thu, Dec 13, 2007 at 11:56:52PM +1100, Michael Lamothe wrote: > I think that the -k is used to specify which key to use. You can have > multiple GPG keys. > > I don't know the "safe" way to do what you're asking. But if you find > out please let me know. :) Well, there's always gpg-agent, of course... isn't this pretty much what it was *written* for? :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. pgpYiDdXVvvVo.pgp Description: PGP signature
Re: RFS: timelimit - Simple utility to limit a process's absolute execution time
On Fri, Dec 07, 2007 at 05:11:36PM +0200, Peter Pentchev wrote: > On Thu, Dec 06, 2007 at 09:09:58PM +0200, Peter Pentchev wrote: > > Dear mentors, > > Hi, it's me again :) > > > I am looking for a sponsor for my package "timelimit". > > That part is still true :) However, after a private e-mail from > a Debian developer, I have released a new upstream version of > the timelimit utility and then uploaded a new Debian package to > mentors.debian.net. Well, after a couple of comments from Damyan Ivanov off-list, I removed configure, configure-stamp, and a couple of dh_* invocations from the debian/rules file. Now here is yet another, hopefully final, version of my timelimit Debian package - still as 1.1-1. * Package name: timelimit Version : 1.1-1 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> (myself) * URL : http://devel.ringlet.net/sysutils/timelimit/ * License : Two-clause BSD Section : utils > > It builds these binary packages: > > timelimit - Simple utility to limit a process's absolute execution time > > > > The timelimit utility executes a command and terminates the spawned process > > after a given time with a given signal. A "warning" signal is sent first, > > then, after a timeout, a "kill" signal, similar to the way init(8) operates > > on shutdown. > > > > The package seems to be lintian-, linda-, pbuilder-, and piuparts-clean. > > > > The upload would fix these bugs: 453290 All that is still true. The package can be found on mentors.debian.net: - dget -x http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.1-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgpXjIcMTTyWG.pgp Description: PGP signature
Bug#684679: RFS: nullmailer/1:1.11-2 (security bugfix upload request)
On Tue, Aug 14, 2012 at 02:51:16AM +0400, Michael Tokarev wrote: > On 13.08.2012 00:18, Nick Leverton wrote: > [] > > diff -Nru nullmailer-1.11/debian/changelog nullmailer-1.11/debian/changelog > > --- nullmailer-1.11/debian/changelog2012-06-16 16:36:28.0 > > +0100 > > +++ nullmailer-1.11/debian/changelog2012-08-11 23:55:36.0 > > +0100 > > @@ -1,3 +1,9 @@ > > +nullmailer (1:1.11-2) unstable; urgency=low > > + > > + * Make 'remotes' not world-readable (Closes: #684619) > > What's wrong with remotes being world-readable? For instance, it may include SMTP authentication information. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? signature.asc Description: Digital signature
Bug#687620: RFS: udpxy/1.0.23-1 [ITP]
On Wed, Dec 12, 2012 at 10:50:49PM +1100, Alex Z wrote: > Hi, Helmut! It's me again. > > Almost all notices you mentioned below are fixed. At least, now we > have manpages. :-) > > But i have some difficulties with hardening. > I cleanly see, that all required flags gets used during build > process, for example: > > cc -D_FORTIFY_SOURCE=2 -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE -c > udpxy.c -o udpxy.o > cc -D_FORTIFY_SOURCE=2 -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE -c > sloop.c -o sloop.o > > for compiling, and > > cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -Wl,-z,relro -DUDPXREC_MOD -DNDEBUG > -DTRACE_MODULE -o udpxy udpxy.o sloop.o rparse.o util.o prbuf.o > ifaddr.o ctx.o mkpg.o rtp.o uopt.o dpkt.o netop.o extrn.o main.o > udpxrec.o > > for linking. But lintian says, that "udpxy: > hardening-no-fortify-functions usr/bin/udpxrec". > Can it be false-positive? The linking line that you pasted above is the one used to create the udpxy executable file, while Lintian complains about a file named udpxrec. Is udpxrec a separate program? If so, you should look at the way it is linked (find the link line in the log that generates a udpxreg executable, a line that contains something like '-o udpxrec'). If udpxrec is really the name that udpxy is installed as (or if it is a hardlink or something similar to udpxy), then the situation is a bit more complicated. Can you post your full build log? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Thit sentence is not self-referential because "thit" is not a word. signature.asc Description: Digital signature
Bug#687620: RFS: udpxy/1.0.23-1 [ITP]
On Thu, Dec 13, 2012 at 12:00:33AM +1100, Alex Z wrote: > Peter Pentchev писал 2012-12-12 23:43: > >On Wed, Dec 12, 2012 at 10:50:49PM +1100, Alex Z wrote: > > > >The linking line that you pasted above is the one used to create the > >udpxy executable file, while Lintian complains about a file named > >udpxrec. Is udpxrec a separate program? If so, you should look > >at the > >way it is linked (find the link line in the log that generates a > >udpxreg > >executable, a line that contains something like '-o udpxrec'). > > > >If udpxrec is really the name that udpxy is installed as (or if it > >is a > >hardlink or something similar to udpxy), then the situation is a bit > >more complicated. Can you post your full build log? > > Sure, build log in attachment. JFYI, urpxrec is just a symlink to > udpxy. > dpkg-buildpackage -rfakeroot -D -us -uc > dpkg-buildpackage: source package udpxy > dpkg-buildpackage: source version 1.0.23-4 > dpkg-buildpackage: source changed by Alex 'AdUser' Z > dpkg-source --before-build udpxy-1.0.23-4 > dpkg-buildpackage: host architecture i386 > dpkg-source: info: using options from udpxy-1.0.23-4/debian/source/options: > --extend-diff-ignore=^util/mkdep$ > fakeroot debian/rules clean > dh clean >dh_testdir >dh_auto_clean > make[1]: Entering directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' > rm -f core.* core udpxy.dep udpxy.o sloop.o rparse.o util.o prbuf.o ifaddr.o > ctx.o mkpg.o rtp.o uopt.o dpkt.o netop.o extrn.o main.o udpxrec.o udpxy > udpxrec > make[1]: Leaving directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' >dh_clean > dpkg-source -b udpxy-1.0.23-4 > dpkg-source: info: using options from udpxy-1.0.23-4/debian/source/options: > --extend-diff-ignore=^util/mkdep$ > dpkg-source: info: using source format `3.0 (quilt)' > dpkg-source: info: building udpxy using existing ./udpxy_1.0.23.orig.tar.gz > dpkg-source: info: building udpxy in udpxy_1.0.23-4.debian.tar.gz > dpkg-source: info: building udpxy in udpxy_1.0.23-4.dsc > debian/rules build > dh build >dh_testdir >dh_auto_configure >dh_auto_build > make[1]: Entering directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' > cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -MM udpxy.c sloop.c rparse.c util.c prbuf.c ifaddr.c > ctx.c mkpg.c rtp.c uopt.c dpkt.c netop.c extrn.c main.c udpxrec.c > udpxy.dep This seems to be a "make depend" target - it uses all the hardening flags for the C preprocessor and, somewhat weirdly, all the hardening flags for the C compiler, too. But this is harmless :) > make[1]: Leaving directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' > make[1]: Entering directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' > -e > Making a [release] version (use 'debug' target as an alternative) > > make[2]: Entering directory `/home/alex/assembly/udpxy/udpxy-1.0.23-4' > cc -D_FORTIFY_SOURCE=2 -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE -c udpxy.c -o > udpxy.o This is the actual build (compile) command. It passes the hardening flags for the C preprocessor (what would be in CPPFLAGS), but for some reason it does not have the hardening flags for the C compiler itself (what would be in CFLAGS, e.g. -fstack-protector and its ssp-buffer-size, also -Wformat and -Werror=format-security). My guess is that this is what Lintian complains about, and my guess is that something has gone wrong with setting the flags in your rules file or passing them down to the Makefile. [snip more compilation lines] > cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -Wl,-z,relro -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE > -o udpxy udpxy.o sloop.o rparse.o util.o prbuf.o ifaddr.o ctx.o mkpg.o rtp.o > uopt.o dpkt.o netop.o extrn.o main.o udpxrec.o This is the linking command, it contains all the flags it should - even some more, but it really doesn't hurt in this case :) [snip installation of the generated udpxy executable as both /usr/bin/udpxy and /usr/bin/udpxyrec in the build staging area] > Now running lintian... > W: udpxy: hardening-no-fortify-functions usr/bin/udpxrec > W: udpxy: hardening-no-fortify-functions usr/bin/udpxy > Finished running lintian. > Now signing changes and any dsc files... > signfile udpxy_1.0.23-4.dsc Alex 'AdUser' Z Yep, Lintian complains all right. Could you post the rules file that you used to get this result? Somehow I don't think that it is the rules file in the package that you uploaded to mentors.d.n today - *that* package doesn't want to build on my system, since the install step fails trying to install stuff into /usr/local instead of /usr :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If I were you, who would be reading this sentence? signature.asc Description: Digital signature
Bug#687620: RFS: udpxy/1.0.23-1 [ITP]
On Wed, Dec 12, 2012 at 03:27:31PM +0100, Helmut Grohne wrote: > On Wed, Dec 12, 2012 at 10:50:49PM +1100, Alex Z wrote: > > Almost all notices you mentioned below are fixed. At least, now we > > have manpages. :-) > > Ok. Let me have a look below. > > > for linking. But lintian says, that "udpxy: > > hardening-no-fortify-functions usr/bin/udpxrec". > > Can it be false-positive? > > This check has had false positives in the past. As you checked the > compilation and linking steps, you can likely ignore it. ...except that in this case it is not a false positive; see my message from a minute ago :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence. signature.asc Description: Digital signature
RFS: confget -- read variables from INI-style configuration files
Dear mentors, I am looking for a sponsor for my package "confget". * Package name: confget Version : 1.01-1 Upstream Author : Peter Pentchev (myself) * URL : http://devel.ringlet.net/textproc/confget/ * License : Two-clause BSD Section : text It builds these binary packages: confget- read variables from INI-style configuration files The package has been lintian- and pbuilder-tested. The upload would fix these bugs: 502543 (ITP) The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/c/confget/confget_1.01-1.dsc Here is the long description of the package: The confget utility examines a INI-style configuration file and retrieves the value of the specified variables from the specified section. Its intended use is to let shell scripts use the same INI-style configuration files as other programs, to avoid duplication of data. The confget utility may retrieve the values of one or more variables, list all the variables in a specified section, list only those whose names or values match a specified pattern (shell glob or regular expression), or check if a variable is present in the file at all. It has a "shell-quoting" output mode that quotes the variable values in a way suitable for passing them directly to a Bourne-style shell. I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgppHpX48dr29.pgp Description: PGP signature
Re: RFS: lbzip2
On Mon, Feb 16, 2009 at 03:01:10AM +0100, ERSEK Laszlo wrote:
> Paul Wise wrote:
>
> > And now onto the package review:
> >
> > Why does your diff.gz patch the Makefile? Shouldn't you add those
> > changes to the upstream Makefile?
>
> I don't think so. As my general, hobbyist free software development
> policy, I *always* and *exclusively* follow the Single Unix Specification:
Actually, that's great. I wish there could be more people like you.
Really, I do.
[snip]
> One such thing would be the set of paths I'd to put under an "install:"
> rule. This has clearly no place in Makefile.dev which is my personal
> playground, or Makefile.portable, which is what it is called. (The
> default Makefile, using gcc, is a concession towards the fact that most
> people have gcc without an appropriate c89 wrapper.)
>
> I simply couldn't satisfy all conceivable users with any "install:"
> target. I believe there's a world out there that doesn't conform to the
> FHS, for example users with install rights only in their respective
> (freely structured) home directories. Maybe someone doesn't want to
> install the manual at all. I just list the files one should consider
> installing, in the README.
Sorry for replying to a month-old e-mail :)
A possible solution - the one I use for all my pieces of software -
is to use environment variables. Since most of the things that vary
between OS's and installations are either paths or user/group names or
permission modes, they can, indeed, be configured with variables.
NB: I am well aware that all of the following depends on make(1)
understanding the ?= syntax. If the programs should be packaged for
OS's which do not have a ?=-aware version of make(1), that could,
indeed, be a problem. There are those who would just wave this problem
away with "oh well, you can always use GNU make, right?"; I'm not
one of them, and if you really intend your software to be ported to
non-?=-aware-make-OS's, then all of the following should be taken with
a grain of salt - or just look at the end for another possible solution :)
The way I do it is to set several variables so that the default behavior
is close to my FreeBSD system and then just pass them on the "make"
command-line when building the Debian, RedHat, or what-have-you package:
LOCALBASE?= /usr/local
PREFIX?=${LOCALBASE}
BINDIR?=${PREFIX}/bin
LIBDIR?=${PREFIX}/lib
MANDIR?=${PREFIX}/man/man
MAN1DIR?= ${MANDIR}1
BINOWN?=root
BINGRP?=wheel
BINMODE?= 555
SHAREOWN?= ${BINOWN}
SHAREGRP?= ${BINGRP}
SHAREMODE?= 444
...and a couple more. Then, for Debian, I just need to change PREFIX,
MANDIR, and BINGRP, and it all works just fine (the modes do not need
changing, there's dh_fixperms for that ;)
Of course, those could be redone for a FHS/Linux system instead:
LOCALBASE?= /usr
MANDIR?=${PREFIX}/share/man/man
BINGRP?=root
BINMODE?= 755
SHAREMODE?= 644
...and then the other ports, e.g. to FreeBSD, would have to pass those
variables either on the make(1) command line or in the environment.
Either way, it's a possible solution.
As to the ?=-aware make(1) problem, a possible solution for that one
would be a shell script which generates the Makefile with values from
the shell script's environment. This is getting dangerously close
to a "configure" script and not all that far away from the autotools,
but, no, I am not trying to convince you to use those - I don't, myself :)
But sometimes, a shell "configure" script is enough to Do The Right Thing(tm).
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because "thit" is not a word.
pgpiEkJmgXZum.pgp
Description: PGP signature
Re: RFS: confget -- read variables from INI-style configuration files
On Thu, Mar 19, 2009 at 09:58:34PM +0200, George Danchev wrote:
> On Wednesday 18 March 2009 11:43:40 Peter Pentchev wrote:
> > Dear mentors,
>
> Hello Peter,
>
> > I am looking for a sponsor for my package "confget".
> >
> > * Package name: confget
> > Version : 1.01-1
> > Upstream Author : Peter Pentchev (myself)
> > * URL : http://devel.ringlet.net/textproc/confget/
> > * License : Two-clause BSD
> > Section : text
> >
> > It builds these binary packages:
> > confget- read variables from INI-style configuration files
> >
> > The package has been lintian- and pbuilder-tested.
> >
> > The upload would fix these bugs: 502543 (ITP)
> >
> > The package can be found on mentors.debian.net:
> > dget -x
> > http://mentors.debian.net/debian/pool/main/c/confget/confget_1.01-1.dsc
> >
> > Here is the long description of the package:
> >
> > The confget utility examines a INI-style configuration file and retrieves
> > the value of the specified variables from the specified section.
> > Its intended use is to let shell scripts use the same INI-style
> > configuration files as other programs, to avoid duplication of data.
> >
> > The confget utility may retrieve the values of one or more variables,
> > list all the variables in a specified section, list only those whose names
> > or values match a specified pattern (shell glob or regular expression), or
> > check if a variable is present in the file at all. It has a
> > "shell-quoting" output mode that quotes the variable values in a way
> > suitable for passing them directly to a Bourne-style shell.
>
> It took me some time to assimilate the hardening notes at wiki.d.o [1], I'm
> remotely familiar with, though this document is informative enough about
> potential build and run-time failures on different architectures wrt
> compiler/linker hardening options. Anyway, buildd logs and buglogs should be
> monitored closely, and in case of troublesome behaviour we should disable
> features via DEB_BUILD_HARDENING_[feature]=0.
> The question is: is it worth the effort? Let's say, I'm fine either way ;-)
Well, the hardening wrapper has shown me some problems in both third-party
software and also (very few, but still) in my own programs in the past
couple of months, so if you're asking about whether it's worth it to
compile with the hardening wrapper and pay attention to its warnings, then
I personally say "hell yeah!" :) But then... confget already uses it,
doesn't it? I'm not quite sure what exactly you mean here :)
> A couple of minor points: confget(1) manpage references to a non-existing
> Config::IniFiles(3) which potentially should describe the syntax of ini
> configuration files if I'm not mistaken?
Erm... hmm. Actually, Config::IniFiles(3) is the manual page of
the Perl Config::IniFiles module, available in Debian as
libconfig-inifiles-perl - but then I guess you already knew that :)
The reason I cross-referenced it in the SEE ALSO section of the confget(1)
manual page is not to describe the format, but to point to a different
implementation, a different programming library that people can use to
access INI files. Maybe it's not quite clear, and I agree that maybe,
once in a while, it could even be confuzzling; do you think I should drop
the cross-reference and just spell it out in words, something like
"Another INI parser is the Config::IniFiles Perl module" or something?
> It would be even better to include
> some short configuration files samples/examples in the binary package itself.
> Your own t{1|2}.ini should suffice.
Ah, examples. An interesting, intriguing concept, indeed :)
I'm not sure if t1.ini and t2.ini are really suitable as sample INI files;
they're more like silly, contrived, awful examples of the depths that
an INI file can sink to... But I could install them as examples, if you
think it's appropriate.
I can't prepare a new package right now, but sometime tomorrow I'll see
what I can do about uploading a new version, if you think it's worth it.
> Otherwise, the package looks useful and the source code very clean and sound.
> Let me know what you think about the above points, and I'll sponsor.
Thanks for the time you took to examine it!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If this sentence didn't exist, somebody would have invented it.
pgpiN9yrdnn7f.pgp
Description: PGP signature
Re: RFS: confget -- read variables from INI-style configuration files
On Fri, Mar 20, 2009 at 01:37:27AM +0200, George Danchev wrote:
> On Thursday 19 March 2009 23:12:22 Peter Pentchev wrote:
[snip]
> > The reason I cross-referenced it in the SEE ALSO section of the confget(1)
> > manual page is not to describe the format, but to point to a different
> > implementation, a different programming library that people can use to
> > access INI files. Maybe it's not quite clear, and I agree that maybe,
> > once in a while, it could even be confuzzling; do you think I should drop
> > the cross-reference and just spell it out in words, something like
> > "Another INI parser is the Config::IniFiles Perl module" or something?
>
> Sure, SEE ALSO sections is a proper place for citing alternatives, and
> detailing this is a *Perl* module would give pointers to the users (me
> included).
Well, actually what I did was take this change, another couple of
things (the example files, a small fix to the testing framework), and
just go ahead and release a new upstream version, confget-1.02.
A Debian package for it is available on mentors.d.n now:
http://mentors.debian.net/debian/pool/main/c/confget/confget_1.02-1.dsc
Let me know if you think that I should coalesce the changelog entries
into a single 1.02 "Initial release" one.
> It is still not very clear to me how to find the full configuration file
> syntax specification? Moreover there is neither a Standard nor a popular
> protocol which stipulates that. How are users supposed to know the gory
> details about it? Note that, "Anybody has looked at some INI files in the
> past" doesn't sound extremely promising ;-)
Unfortunately, as you say, there is no single standard for INI files.
The confget utility implements some of the more popular constructs -
sections (naturally), allowed whitespace in most positions, backslash
line continuations, comments (both "#" and ";"). There are things that
other parsers do that confget doesn't, like spaces *within* a variable
name; if there is popular demand, it may learn to do that, too :)
As to "how users are supposed to know", if this sentence of yours was
leading to the examples issue, see below :)
> > > It would be even better to include
> > > some short configuration files samples/examples in the binary package
> > > itself. Your own t{1|2}.ini should suffice.
> >
> > Ah, examples. An interesting, intriguing concept, indeed :)
> >
> > I'm not sure if t1.ini and t2.ini are really suitable as sample INI files;
> > they're more like silly, contrived, awful examples of the depths that
> > an INI file can sink to... But I could install them as examples, if you
> > think it's appropriate.
> >
> > I can't prepare a new package right now, but sometime tomorrow I'll see
> > what I can do about uploading a new version, if you think it's worth it.
>
> Sure, take your time. Examples are just good to have, although not mandatory.
> So, the only unclear point left is the configuration file syntax
> specification. This is not a hard showstopper, but would be very nice to have
> in place proper.
Version 1.02 of confget installs the t1.ini and t2.ini files as examples.
Since those files' purpose until now was indeed to be contrived edge
cases for regression testing, and examples are not generally supposed to
be that bad (at least, not *supposed* to ;), I added some comments in
those files so they are a bit more suitable.
Here's hoping you like version 1.02 better :)
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I were you, who would be reading this sentence?
pgp7UryMNIKzk.pgp
Description: PGP signature
Re: RFS: confget -- read variables from INI-style configuration files
On Mon, Mar 23, 2009 at 10:06:14PM +0200, George Danchev wrote: > On Sunday 22 March 2009 02:17:30 Peter Pentchev wrote: > > Hello, > > > Well, actually what I did was take this change, another couple of > > things (the example files, a small fix to the testing framework), and > > just go ahead and release a new upstream version, confget-1.02. > > > > A Debian package for it is available on mentors.d.n now: > > http://mentors.debian.net/debian/pool/main/c/confget/confget_1.02-1.dsc > > Great. I looked at it and uploaded it. Thanks! > > Let me know if you think that I should coalesce the changelog entries > > into a single 1.02 "Initial release" one. > > Not a big deal, I passed -v, so your `Initial release. Closes: xxx' is also > included in *.changes, thus the BTS magic will work as well. Yep, I was just wondering if I remembered correctly that you liked the interim versions in the changelog even though they never made it into the archive. Apparently, I did and you still do :) > > > It is still not very clear to me how to find the full configuration file > > > syntax specification? Moreover there is neither a Standard nor a popular > > > protocol which stipulates that. How are users supposed to know the gory > > > details about it? Note that, "Anybody has looked at some INI files in the > > > past" doesn't sound extremely promising ;-) > > > > Unfortunately, as you say, there is no single standard for INI files. > > The confget utility implements some of the more popular constructs - > > sections (naturally), allowed whitespace in most positions, backslash > > line continuations, comments (both "#" and ";"). There are things that > > other parsers do that confget doesn't, like spaces *within* a variable > > name; if there is popular demand, it may learn to do that, too :) > > I don't think I would use spaces in variable names ;-) However, there is > nothing wrong to support it if you find it useful. > > > Version 1.02 of confget installs the t1.ini and t2.ini files as examples. > > Since those files' purpose until now was indeed to be contrived edge > > cases for regression testing, and examples are not generally supposed to > > be that bad (at least, not *supposed* to ;), I added some comments in > > those files so they are a bit more suitable. > > Ok, thank you. > > > Here's hoping you like version 1.02 better :) > > I was not whining for a BNF grammar ;-), but for few documentation in > order to bring closer confget's reading of INI files to the user's > writing them; that would avoid subtle discrepancies or > misunderstandings. Sure, that's how I read your message too :) No problem, examples are indeed nice to have, especially when dealing with vaguely defined stuff. Once again, thanks for all your time in this discussion! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. pgpxKvKkwnae0.pgp Description: PGP signature
RFS: dante (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.19.dfsg-3 of my package "dante". This version does not fix any problems listed in the Debian BTS; what it DOES fix is a serious problem with libsocksd0-dev - it was absolutely and completely uninstallable because I'd mistyped the name of the libsocksd0 dependency :( The 1.1.19.dfsg-3 version also fixes a lot of lintian warnings and updates Standards-Version to 3.8.1 with a minor change to the server startup script. It builds these binary packages: dante-client - SOCKS wrapper for users behind a firewall dante-server - SOCKS (v4 and v5) proxy daemon (danted) libdsocksd0 - SOCKS library for internal use by the dante client libsocksd0 - SOCKS library for packages built using libsocksd-dev libsocksd0-dev - Development files for compiling programs with SOCKS support The package has been tested with lintian and pbuilder. The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-3.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgprmTaD1c1k5.pgp Description: PGP signature
Re: RFS: dante (updated package)
On Wed, Mar 25, 2009 at 10:58:47PM +0200, George Danchev wrote: > On Wednesday 25 March 2009 14:54:41 Peter Pentchev wrote: > > Dear mentors, > > Hello Peter, > > > I am looking for a sponsor for the new version 1.1.19.dfsg-3 > > of my package "dante". This version does not fix any problems > > listed in the Debian BTS; what it DOES fix is a serious problem > > with libsocksd0-dev - it was absolutely and completely uninstallable > > because I'd mistyped the name of the libsocksd0 dependency :( > > The 1.1.19.dfsg-3 version also fixes a lot of lintian warnings and > > updates Standards-Version to 3.8.1 with a minor change to the server > > startup script. > > I looked at 1.1.19.dfsg-3 and uploaded it. Thanks for taking care of these! Thanks! :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgpoEjRWgXpMl.pgp Description: PGP signature
Point to semi-official backported packages?
Hi,
For work-related reasons, I'm in the habit of keeping an Etch backport
of any packages I make in the same Subversion repository where the real
unstable/testing packages are developed. Now with debhelper >= 7.0.50
and Lenny, in all probability I'll keep a Lenny version, too. My repo
structure is usually like that:
path/package
- trunk
- package
(the package with my fixes common to all OS's I try it on)
- package-pkg
- debian
(the debian/ subdir of the Debian unstable package)
- debian-lenny
(the debian/ subdir of the Debian Lenny package)
- debian-etch
(the debian/ subdir of the Debian Etch package)
- branches
- vendor
- package
(the stock version of a package, if I keep its sources there, too)
- debian
- package
(the package with all Debian-related patches)
- freebsd
- package
(the package with all FreeBSD-related patches)
- tags
- package-N.NN-stock
(the stock version from branches/vendor)
- package-N.NN
(my version from either trunk/ or branches/debian/)
- package-N.NN-N-debian
- package-N.NN-N-debian-lenny
- package-N.NN-N-debian-etch
(the debian/ subdirectories of the Debian packages)
Now... I know about - and use, and love - the Vcs-Svn and Vcs-Browser
control fields. However, I would like to have the unstable package contain
some kind of pointers to my own Lenny and Etch ports to avoid duplication
of work if anyone should be interested in such a thing. Where should I
mention the trunk/-pkg/debian-{etch,lenny} subtrees?
README.source comes to mind, or alternatively, X-Vcs-Svn-Etch:
and X-Vcs-Svn-Lenny: control fields or something - but the control fields
would elicit warnings from lintian :)
Is there already a precedent in the archive?
(And yes, I know about backports.d.n; maybe I'll get 'round to submitting
or maintaining stuff there at some point, but for the present it is
a bit easier for me to keep it all in a single repo :)
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence no verb.
pgpVyGB1VUA5x.pgp
Description: PGP signature
RFS: prips (adopted and updated)
Dear mentors,
I am looking for a sponsor for the new version 0.9.5-1
of my package "prips". I've adopted the Debian package,
and since upstream seems to be, well, moribund, I've also
taken the liberty of adopting the upstream piece of software
and releasing a new version.
It builds these binary packages:
prips - Print IP address on a given range
The package is lintian- and pbuilder-clean.
The upload would fix these bugs: 497429, 519379
The package can be found on mentors.debian.net:
dget -x http://mentors.debian.net/debian/pool/main/p/prips/prips_0.9.5-1.dsc
Just for reference, here is the changelog of my 0.9.5-1 entry:
prips (0.9.5-1) unstable; urgency=low
* New maintainer. Closes: #519379
* Fix the date format of the 0.9.4-3 changelog entry. Closes: #497429
* Move the debhelper compatibility version to debian/compat.
* Add a watch file.
* Add the Homepage, Vcs-Svn, and Vcs-Browser control fields.
* Convert the copyright file to the machine-parseable format and
add some copyright notices for the Debian packaging.
* Bump the debhelper compatibility level to 7:
- add ${misc:Depends} to the binary package
* Bump Standards-Version to 3.8.1:
- the new version honors our CFLAGS, thus honoring DEB_BUILD_OPTIONS
* Use dh_install to install the prips binary.
* Minimize the rules file using debhelper 7's dh(1) utility.
* New upstream version - actually, I adopted the package:
- remove all the Debian patches - some of them were integrated upstream,
and the cidr_lp64 one was overtaken by the uint32_t change
- remove the manpage - integrated upstream, rewritten as mdoc(7)
and fleshed out a bit
- remove README.Debian - the upstream has a manpage now :)
* Use build hardening by default, disabled by the "nohardening" option.
* Use the -Werror compiler flag if the "werror" option is present.
-- Peter Pentchev Fri, 27 Mar 2009 19:36:58 +0200
I would be glad if someone uploaded this package for me.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Do you think anybody has ever had *precisely this thought* before?
pgpSDt3ALsGlW.pgp
Description: PGP signature
Re: Point to semi-official backported packages?
On Sat, Mar 28, 2009 at 12:35:44PM +0900, Paul Wise wrote:
> On Fri, Mar 27, 2009 at 8:28 PM, Peter Pentchev wrote:
>
> > Now... I know about - and use, and love - the Vcs-Svn and Vcs-Browser
> > control fields. However, I would like to have the unstable package contain
> > some kind of pointers to my own Lenny and Etch ports to avoid duplication
> > of work if anyone should be interested in such a thing. Where should I
> > mention the trunk/-pkg/debian-{etch,lenny} subtrees?
> > README.source comes to mind, or alternatively, X-Vcs-Svn-Etch:
> > and X-Vcs-Svn-Lenny: control fields or something - but the control fields
> > would elicit warnings from lintian :)
>
> IMO just upload them to backports.org and be done with it.
> Alternatively any of the other options you mention sound fine.
Well, now that I've seen the rest of your message and explanation,
I will :) It was just that I was, indeed, confused about the "correct"
backports site, and since Git isn't quite my cup of tea yet (a question
of both personal preference *and* lack of time to learn it, I guess ;)
I thought the learning curve to backports.d.n was a bit high :)
> > (And yes, I know about backports.d.n; maybe I'll get 'round to submitting
> > or maintaining stuff there at some point, but for the present it is
> > a bit easier for me to keep it all in a single repo :)
>
> I think you mean backports.org, backports.debian.net is not what you
> think it is. Despite its name, backports.d.n is a personal backports
> archive for Daniel Bauman.
Oh! Oh... Well, that explains that, then. Now that I've seen that
backports.org is a real, full-fledged Debian package archive with
upload queues, buildd's and everything, I'll upload there. Thanks!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If you think this sentence is confusing, then change one pig.
pgpmBzGpwNFY3.pgp
Description: PGP signature
RFC: dma -- the DragonFly Mail Agent
Dear mentors, This is not even an RFS :) Now, seriously - I've prepared a package for dma, the DragonFly Mail Agent, as ITP'd in my #511410, I've uploaded it to mentors.d.n, and I've sent out a request for debconf translations. The call for translations should hit the -i18n list in a couple of minutes, and there's a ten-day timeout on it. Still, if any of you could find the time to take a look at the dma package itself and tell me if I've done anything horribly wrong, I'd be very grateful :) * Package name: dma Version : 0.0.2009.01.10 Upstream Author : Matthias Schmidt , Simon Schubert * URL : http://www.dragonflybsd.org/ * License : BSD Programming Lang: C Description : the DragonFly Mail Agent, a lightweight MTA It builds these binary packages: dma- the DragonFly Mail Agent, a lightweight MTA The package has been tested with lintian and pbuilder. The upload would fix these bugs: 511410 The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.02.11-1.dsc Note: the dma sources themselves are NOT available for direct download from http://www.dragonflybsd.org/. I've made the tarball from a git checkout as of, well, 2009/01/10 :) The only change since then has been a raised C compiler warnings level. Thanks in advance, and thanks for y'all's great job in mentoring! :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpFVREQ6K0Cp.pgp Description: PGP signature
Re: RFC: dma -- the DragonFly Mail Agent
On Tue, Mar 31, 2009 at 10:28:16PM +0200, George Danchev wrote: > On Monday 30 March 2009 17:23:48 Peter Pentchev wrote: > > Dear mentors, > > Hello Peter, > > > This is not even an RFS :) > > > > Now, seriously - I've prepared a package for dma, the DragonFly Mail > > Agent, as ITP'd in my #511410, I've uploaded it to mentors.d.n, and > > I've sent out a request for debconf translations. The call for > > translations should hit the -i18n list in a couple of minutes, and > > there's a ten-day timeout on it. > > > > Still, if any of you could find the time to take a look at the dma > > package itself and tell me if I've done anything horribly wrong, > > I had a look at it and found nothing horribly wrong, though packaging MTA is > not that trivial, no matter how lightweight it is. Yeah, I learned that the hard way. However, $REALJOB really *really* needed something to replace nullmailer with, and since I'd noticed dma mentioned on the FreeBSD lists recently, I thought I'd give it a try. > The one that grabbed my attention is the large list of patches applied to the > upstream code (if we don't take into account the debian-specific ones > 0x-debian-*). Some of them are also hunk'ing, but you can fix that. > [snip] > > > > Note: the dma sources themselves are NOT available for direct > > download from http://www.dragonflybsd.org/. I've made the tarball > > from a git checkout as of, well, 2009/01/10 :) The only change > > since then has been a raised C compiler warnings level. > > I also had a look at the FreeBSD port of dma [1] and it doesn't seem to be so > heavily patched. So, it seems like either your colleague is missing something > or you are just taking the chance to develop in debian/patches/ ;-) ... hence > communicating and consulting your changes upstream would bring these > improvements to more users and developers. > > [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/dma/ Errr... and of course I forgot to mention this in my not-an-RFS :) All the patches that are not Debian-specific have been submitted upstream in the DragonFlyBSD issue tracker: http://bugs.dragonflybsd.org/issue1321 I hope that some of them will get folded into the "main distribution". > Otherwise the packaging looks solid, but then again I'm not an MTA wizard ;-) Neither am I :) And thanks for the time you've taken! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgp20tRmLJUxn.pgp Description: PGP signature
Re: suggest: midi sequencer
On Wed, Apr 01, 2009 at 10:46:43AM +0200, Grammostola Rosea wrote: > Hi, > > What if my package suggest to use an midi sequencer, e.g. Rosegarden or > qtractor? I think I'm searching for something which looks similar to this: > > konqueror | www-browser > > but what name does those midi sequencers have? If you're asking what is the name of the Debian package of Rosegarden, you should be able to figure this out by yourself from the information at http://packages.debian.org/ :) If you're asking about the www-browser part, well, that's a virtual package as described in the Debian Policy (you've actually read that, right? :) The Policy also describes how to properly depend on programs that provide virtual packages - exactly this way, by depending first on a specific one that your package works best with and, alternatively, on the virtual package so that any alternative installed would satisfy it. So, is there a virtual package that defines a MIDI sequencer? Well, you should be able to figure this out by yourself from the package information of the Rosegarden and qtractor packages: do they "Provide" something that looks like a generic name of a MIDI sequencer? In this specific case, no, they do not, so you have to depend on either of them (or any other MIDI sequencers that you are aware of) by package name, you can't really get away with a virtual package. Hope that helps. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpdmDq7IAmaB.pgp Description: PGP signature
RFS: hexer (adopted & updated package)
Dear mentors, I am looking for a sponsor for the new version 0.1.4c-3 of my package "hexer". This is an adoption - ITA #520635. The changelog entry describing my update to the Debian packaging of hexer is included a bit further down. There's just one binary package: hexer - An interactive binary editor with a Vi-like interface The package has been tested with lintian and pbuilder. The upload would fix these bugs: 437160, 520635 The package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.4c-3.dsc Some may have noticed that it is my custom to 1. fix all compiler warnings in a package build, and 2. use the hardening wrapper. For this particular case, I've chosen not to do that straight away with the adoption; I'll probably adopt the upstream package itself in the next day or two and bring that 13-year-old code up to snuff. The problem is, the patch that fixes just -Wall -Wstrict-prototypes was more than 120 KBytes long :) IMHO, it'll better that I do this as a new upstream release :) Just for reference, here's my adoption changelog entry: hexer (0.1.4c-3) unstable; urgency=low * New maintainer. Closes: #520635 * Use quilt for patch management. * Drop the README patch; with all due respect to Peter Mathiasson, in my humble opinion this information is addressed to developers, not end-users, and thus belongs right here, in the Debian changelog instead. * Add a watch file. * Fix up the manual page a bit: - use .\" instead of ./" for comments - properly use hyphens instead of minus-signs * Flesh out the long description with a list of hexer features. * Unbreak the "comment" and "argument" words in the help text to avoid spellcheck warnings from lintian. * Override the "no upstream changelog" and "no homepage field" lintian warnings. * Add the Vcs-Svn and Vcs-Browser fields. * Bump the debhelper compatibility version to 7: - add misc:Depends to the binary package - minimize the rules file * Bump Standards-Version to 3.8.1: - replace Apps with Applications in the menu section - honor the "nostrip" build option; Closes: #437160 - override the compiler program and flags so the "noopt" build option is also honored - add the README.source file mentioning the use of quilt * Convert the copyright file to the machine-parseable format and add my copyright notice on the Debian packaging. * Build with -Werror if "werror" is specified in DEB_BUILD_OPTIONS. * Fix some compiler warnings. * Quote the "needs" and "section" menu file fields and install it. -- Peter Pentchev Fri, 03 Apr 2009 05:31:17 +0300 I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgpWEpVS6k5AX.pgp Description: PGP signature
Re: RFS: hexer (adopted & updated package)
On Fri, Apr 03, 2009 at 11:17:05AM +0800, Paul Wise wrote: > On Fri, Apr 3, 2009 at 10:50 AM, Peter Pentchev wrote: > > > - dget http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.4c-3.dsc > > I'm unable to sponsor at the moment, but I took a look at the diff.gz. > > Please remove the lintian overrides, you should only override lintian > complaints when the lintian test is wrong and it isn't possible to fix > the test for your case, not when you just want to ignore it or the > test has a bug. In this case there isn't an upstream homepage or > changelog yet, which are both valid complaints that you intend to fix > by taking over upstream. Good point. Thanks! > The rest of the diff.gz looks fine, I suggest someone else do a deeper > review and upload this package. I've built and uploaded a new version of hexer-0.1.4c-3 to mentors.d.n at the same URL: http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.4c-3.dsc The changes are: - removed the lintian overrides - reworded the last line in the changelog entry; 5:30am does not for good grammar make! Thanks to you and Michal both for taking a look! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgpKDGaQzhEBX.pgp Description: PGP signature
Re: "out of date on mips: siege (from 2.66-2)"
On Sat, Apr 04, 2009 at 09:53:53AM +0100, Tristan Greaves wrote: > Hi all, > > Could someone please explain the above Excuse for me? (I understand the > _what_ but not the _why_ in this instance). > > https://buildd.debian.org/pkg.cgi?pkg=siege > > My package has successfully built on the other architectures, but the > process does not seem to have run on mips. There are no click-through logs > to look at in order to see if there was a specific problem here, or whether > the build just has not kicked off for some reason. Take a look at those two URL's, and the dates on them: https://buildd.debian.org/build.php?arch=i386&pkg=siege&ver=2.67-3 https://buildd.debian.org/build.php?arch=mips&pkg=siege My guess would be that the mips buildd has simply not managed to get 'round to building siege-2.67-3 yet. Check again in a day or three :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgp9L85p0XLXc.pgp Description: PGP signature
RFS: wwwstat (adopted & updated)
Dear mentors, I am looking for a sponsor for the new version 2.0-5 of my package "wwwstat". It's an adoption attempt, ITA: #519383. It builds a single binary package: wwwstat- httpd logfile analysis package The package has been tested with lintian and pbuilder. The upload would fix these bugs: 519383 The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/w/wwwstat/wwwstat_2.0-5.dsc I would be glad if someone uploaded this package for me. Just for reference, here's my adoption changelog entry: wwwstat (2.0-5) unstable; urgency=low * New maintainer. Closes: #519383 * Use quilt for patch management. * Add a watchfile. * Move debhelper from B-D-I to B-D - used in the "clean" target. * Move the manual pages to separate files under debian/ instead of creating them from a patch. * Correct the copyright statements on the manual pages. * Use wwwstat.manpages and do not pass -A to dh_installman. * Fix a couple of hyphens in the oldlog2new.8 manual page. * Add the Homepage, Vcs-Svn, and Vcs-Browser fields. * Bump the debhelper compatibility version to 7: - add misc:Depends to the binary package - minimize the rules file using debhelper's override targets * Bump Standards-Version to 3.8.1: - add the README.source file mentioning the use of quilt * Update the copyright file: - convert it to the machine-parseable format - add my copyright notice on the Debian packaging - elaborate on the need to quote the package's LICENSE file verbatim; wwwstat is licensed under the old Artistic license, not the one included in common-licenses, so it must be spelled out in full - remove the note about common-licenses * Do not install the README file - it contains no useful info by itself. -- Peter Pentchev Mon, 06 Apr 2009 01:17:11 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. pgpT7a40UvS0V.pgp Description: PGP signature
Re: RFS: screenruler (updated package) (ruby)
On Sat, Feb 28, 2009 at 12:39:59AM +0100, Siegfried Gevatter (RainCT) wrote: > Dear mentors, > > I am looking for a sponsor for the new version > 0.85really0.8.9.1+bzr24-1 of my package "screenruler". (The version is > this weird because is using a broken version scheme and I didn't > realize in time... I've already asked him to change it). E... Sorry if this is a sorta-uninformed comment on the wrong track, but if the reason for this kind of versioning is that the last upstream release (and the one that is in the Debian archive) is 0.85 and now upstream released 0.8.9.1 and 0.8 < 0.85, shouldn't this really be solved with an epoch? Couldn't you set a version of 1:0.8.9.1-1 on your new package and be done with it? :) Yes, I know that epochs are generally frowned upon, discouraged and stuff, and it's the same way in the FreeBSD ports system - an epoch is a measure of last resort, since once bumped (or set), it *has* to stay forever. Still, sometimes it's the necessary evil. Of course, I could be wrong in this particular case :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpN5bjCQpFZd.pgp Description: PGP signature
dante: libc6 dependency: can't migrate to testing?
Hi, I've been seeing this for the past two weeks: http://qa.debian.org/excuses.php?package=dante libdsocksd0/alpha unsatisfiable Depends: libc6.1.1 (>> 2.9) libsocksd0/alpha unsatisfiable Depends: libc6.1.1 (>> 2.9) ...and I'm not exactly sure what the problem is. Okay, so I see that libc6 has some weirdness on alpha (building a libc6.1 instead of libc6), but still I'm really not sure where the libc6.1.1 instead of libc6.1 comes from. What should I do now? - look for a problem in debhelper 7 on alpha (shlibds:Depends generation) - look for a problem in the build hardening wrapper on alpha - look for a problem in dante's control file (but it's just shlibs:Depends and misc:Depends for those two libraries) - poke and anger the wanna-build gods to do something by hand - just wait patiently? :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpH0gHwUk6QY.pgp Description: PGP signature
RFS: timelimit (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.4-2 of my package "timelimit" which builds a single binary package: timelimit - Simple utility to limit a process's absolute execution time It has been lintian- and pbuilder-tested. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.4-2.dsc I would be glad if someone uploaded this package for me. Just for the record, here's the changelog entry: timelimit (1.4-2) unstable; urgency=low * Refer to GPL-2, not just GPL, in the copyright file. * Bump Standards-Version to 3.8.1 with no changes. * Add misc:Depends to the binary package. * Minimize the rules file using debhelper override targets. * Update the copyright years for the Debian packaging. * Point to the actual Debian package files in Vcs-Svn and Vcs-Browser, not at the full timelimit upstream repository. -- Peter Pentchev Tue, 14 Apr 2009 11:13:21 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! pgp6GJuHXivWL.pgp Description: PGP signature
RFS: ethstats (adopted and updated)
Dear mentors, I am looking for a sponsor for the new version 1.0-3 of my package "ethstats". This is a very simple, lightweight, easy to use tool for gathering and displaying the throughput of the network interfaces. Of course, it's far from iptraf or wireshark, but sometimes one needs just a couple of numbers. I'm adopting ethstats, and I've overhauled the Debian packaging a lot, bringing it up to the current standards and tools. It builds a single binary package: ethstats - script that quickly measures network device throughput The package has been tested with lintian and pbuilder. The upload would fix these bugs: 519342 The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/e/ethstats/ethstats_1.0-3.dsc I would be glad if someone uploaded this package for me. Just for reference, here's the changelog entry of my adoption update: ethstats (1.0-3) unstable; urgency=low * New maintainer. Closes: #519342 * Keep everything in the debian/ directory: - remove the ethstats copy of ethstats.pl and regenerate it in the "build" target - move the ethstats.sgml manual page into debian/ - remove the manual page in the "clean" target * Add a watch file. * Use debian/compat to specify the debhelper compatibility level. * Clean up the rules file: - remove lots of useless commented-out stuff - remove the useless and empty configure target - remove the nostrip and noopt handling - it's a Perl script! - remove lots of useless debhelper tool invocations - move many debhelper tool invocations from the binary target to the install target, where the dh utility would place them - this is an arch-independent package, so use binary-indep, not binary-arch! * Move docbook-to-man to B-D-I from B-D. * Remove the dot at the end of the package synopsis. * Depend on "perl", not "perl5". * Bump the debhelper compatibility level to 7: - add misc:Depends to the binary package - minimize the rules file * Bump Standards-Version to 3.8.1 with no changes. * Convert the copyright file to the machine-parseable format and add my copyright notice. -- Peter Pentchev Sat, 09 May 2009 16:43:44 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. pgpQii0pFxCcK.pgp Description: PGP signature
Re: RFS: wwwstat (adopted & updated)
On Mon, Apr 06, 2009 at 01:37:47AM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for the new version 2.0-5 of my > package "wwwstat". It's an adoption attempt, ITA: #519383. Well, no reply, so let's try this again :) The wwwstat package is a simple Perl tool for analyzing Apache-style (well, NCSA-style or whatever) logfiles, and providing various types of statistics. Granted, there are other packages that do that, but apparently people like this simple and fast one, too, and even have it installed on their systems :) The rest of the original request is still valid: > It builds a single binary package: > wwwstat- httpd logfile analysis package > > The package has been tested with lintian and pbuilder. > > The upload would fix these bugs: 519383 > > The package can be found on mentors.debian.net: > dget -x http://mentors.debian.net/debian/pool/main/w/wwwstat/wwwstat_2.0-5.dsc > > I would be glad if someone uploaded this package for me. > > Just for reference, here's my adoption changelog entry: > > wwwstat (2.0-5) unstable; urgency=low > > * New maintainer. Closes: #519383 > * Use quilt for patch management. > * Add a watchfile. > * Move debhelper from B-D-I to B-D - used in the "clean" target. > * Move the manual pages to separate files under debian/ instead of > creating them from a patch. > * Correct the copyright statements on the manual pages. > * Use wwwstat.manpages and do not pass -A to dh_installman. > * Fix a couple of hyphens in the oldlog2new.8 manual page. > * Add the Homepage, Vcs-Svn, and Vcs-Browser fields. > * Bump the debhelper compatibility version to 7: > - add misc:Depends to the binary package > - minimize the rules file using debhelper's override targets > * Bump Standards-Version to 3.8.1: > - add the README.source file mentioning the use of quilt > * Update the copyright file: > - convert it to the machine-parseable format > - add my copyright notice on the Debian packaging > - elaborate on the need to quote the package's LICENSE file verbatim; > wwwstat is licensed under the old Artistic license, not the one > included in common-licenses, so it must be spelled out in full > - remove the note about common-licenses > * Do not install the README file - it contains no useful info by itself. > > -- Peter Pentchev Mon, 06 Apr 2009 01:17:11 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. pgpAsW18kE4yJ.pgp Description: PGP signature
Re: include desktop file and icon
On Mon, May 11, 2009 at 05:49:02PM +0200, Grammostola Rosea wrote: > Paul Wise wrote: > > On Mon, May 11, 2009 at 5:40 PM, Grammostola Rosea > > wrote: > > > > > >>> my install file looks like: > >>> > >>> phasex-0.11.1/phasex.desktop usr/share/applications > >>> phasex-0.11.1/pixmaps/* usr/share/pixmaps > >>> > >>> > >>> > >> Comments, suggestions to solve this? > >> > > > > phasex.desktop usr/share/applications > > pixmaps/* usr/share/pixmaps > > > > > thanks > > lintian says: > P: phasex source: direct-changes-in-diff-but-no-patch-system > misc/phasex.desktop and 1 more Sigh. And what does "lintian -i" say about that? And what does that actually *mean*? And do you want to use a patch system? And if you do, why not use one? And if there are really good reasons why you don't want to use a patch system, then you can ignore this warning - but only after you've come to understand what it means and why it is there. And understanding what it means and why it is there is usually - and in this case, too - as simple as *reading* the output of "lintian -i", thinking about it a bit, then reading what people with similar issues have said and done on the -mentors list, and sometimes examining a couple of packages that are already in Debian to see how they deal with it. In this particular case, just reading the additional information that Lintian displays ought to be enough to understand it :) Erm... I hope this doesn't seem harsh; it isn't meant to be. Just a piece of well-meant advice that has helped me deal with lintian warnings and other packaging problems in the past year or two :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! pgpSWcvd3PiQH.pgp Description: PGP signature
Re: include desktop file and icon
On Tue, May 12, 2009 at 11:08:29AM +0200, Grammostola Rosea wrote: > Peter Pentchev wrote: > > On Mon, May 11, 2009 at 05:49:02PM +0200, Grammostola Rosea wrote: [snip] > >> lintian says: > >> P: phasex source: direct-changes-in-diff-but-no-patch-system > >> misc/phasex.desktop and 1 more > >> > > > > Sigh. And what does "lintian -i" say about that? And what > > does that actually *mean*? And do you want to use a patch system? > > And if you do, why not use one? And if there are really good > > reasons why you don't want to use a patch system, then you can > > ignore this warning - but only after you've come to understand > > what it means and why it is there. > > > > And understanding what it means and why it is there is usually - > > and in this case, too - as simple as *reading* the output of > > "lintian -i", thinking about it a bit, then reading what people > > with similar issues have said and done on the -mentors list, > > and sometimes examining a couple of packages that are already in > > Debian to see how they deal with it. > > > > In this particular case, just reading the additional information > > that Lintian displays ought to be enough to understand it :) > > > > Erm... I hope this doesn't seem harsh; it isn't meant to be. > > Just a piece of well-meant advice that has helped me deal with > > lintian warnings and other packaging problems in the past > > year or two :) > > > > > Thanks, I understand your point. > But I can't understand all those messages yet and I'm not gonna read > hundreds of difficult to read manual pages with at least 200 pages each.. > > I hope this doesn't seem harsh ;) But in my experience, it works the > best at start to ask experienced people and learn bit by bit how things > work. At first the manpages are mostly 'acadabra' but picking up some > bits from others will help you to be able to quickly understand the more > sophisticated issues. In my experience, when people tell me how to do it > and I succeeded once, I don't have to ask it again how it works (like > the install file thing). After a while I see other people do things > different and then I can ask and investigate why... > > If you want to read all the different things at start at once, packaging > for Debian will cost you a fulltime job and that would in many cases not > be good. > > I think the help is good on this list. thanks for that. But I don't > think 'read the manpages of that, that and that package' is a very > productive way to learn things. It's like reading all the manuals for > the electric apparatus in your house... you wouldn't have time to work > on Debian if you did that... Well... I think I should rather let others answer that - I'm not a DD, not applied even to DM yet (though I intend to do both soon), just a random volunteer who tries to help Debian every once in a while with a package or fifteen :) So maybe someone more authoritative could chime in here and give us an official opinion if needed :) Still, I'd just like to point out that none of what you describe was actually a problem for me a couple of years ago when I started. (Just for the record, it was not a full-time job back then, and it isn't now, although the truth is that part of my job *does* include making Debian packages of in-house software for Etch and Lenny). I read the Developer's Reference, I examined several packages to see how things were done, I ran "dh_make" with different options to see what it did... then I ran it once again and started working on lintian warnings (and errors, too, in my first packages). Working on them was really just "run lintian -i, read what it says, read the Policy section if one is mentioned, take a look at the manpage of the dh_* tool in question, change one line be done with it". Maybe it helped that I started using just plain debhelper from the start, and first dpatch, then quilt afterwards. IMHO, debhelper's manpages are written wonderfully - short, to the point, with plain and simple descriptions of what the tool does and what files it reads. And, of course, following the -mentors list helped a lot :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpHbJh6oMFos.pgp Description: PGP signature
Re: include desktop file and icon
On Tue, May 12, 2009 at 12:43:21PM +0300, Peter Pentchev wrote: [snip] > Well... I think I should rather let others answer that - I'm not > a DD, not applied even to DM yet (though I intend to do both soon), > just a random volunteer who tries to help Debian every once in > a while with a package or fifteen :) So maybe someone more > authoritative could chime in here and give us an official opinion > if needed :) Just one final point now, and I'm shutting up, I promise :) This is something I simply forgot to write in my previous e-mail, and it was *the main reason* I started writing it! It is, by all means, my largest pet peeve for the past more than twelve years, ever since I started writing documentation for my first small programs and then I had three different coworkers come to me with "simple little questions" that were already answered in the docs. The main reason - I *almost* want to say "the only reason" - for anybody, ever, to write documentation for any project is to lighten the support burden on the project authors later on. Let's just consider a simple little question that may be answered in two sentences and may be documented in five (e.g. including a section heading). Now, which do you think is easier *for everyone*: 1. The author does not document the question, and in the next year, fifty people ask him the same question in person, via e-mail, ICQ, IRC, or bug reports. Each time he responds with the same two sentences, for a total of fifty sentences for the question, a hundred sentences for the answer, and a hundred minutes time overall. Also, the author is... let's say, somewhat irritated... for having to repeat himself fifty times. Hopefully, he gets irritated enough to document the answer :) 2. The author does document the question. Throughout the next year, fifty people read the question in the docs and do not bother the author, for a total of five sentences for the documented question, and fifty-five minutes time overall (five minutes for the author documenting the question, and fifty minutes for the people answering it). Now, in the second scenario, the author has the time to actually do something else while people find the answer for themselves :) And now, consider the case when the author *has* documented the answer and fifty people *still* come to him with the same question, over and over again, when they could have spent a minute - or, well, sometimes five minutes - to just find the answer in the docs. Shall we say, "the author is somewhat irritated"? :) As I said, I'm shutting up now :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgphVlxyjvPuo.pgp Description: PGP signature
RFS: debsigs (adopted, fixed bugs, updated)
Dear mentors, I am looking for a sponsor for the new version 0.1.15 of my package "debsigs". This is an adoption - Branden Robinson filed an RFA a while ago after taking care of the debsigs package for a long time. I've fixed all of its outstanding bugs and updated the packaging to conform to the current standards and best practices. There is a single binary package: debsigs- toolset for applying cryptographic signatures to Debian packages It has been tested with lintian and pbuilder. The upload would fix these bugs: 98088, 161541, 161680, 163643, 175337, 175338, 457319, 522257 The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/d/debsigs/debsigs_0.1.15.dsc I would be glad if someone uploaded this package for me. JFYI, here's my adoption changelog entry: debsigs (0.1.15) unstable; urgency=low * New maintainer. Closes: #522257 * Fix the changelog format by removing the Vim formatting codes. * Do not install the empty /usr/sbin directory and remove the debian/dirs file altogether. * Convert the copyright file to the machine-parseable format and add my copyright notice. * Bump the debhelper compatibility level to 7: - store it in debian/compat - use debian/debsigs as the build directory instead of debian/tmp - add misc:Depends to the binary package - remove the dh_installmanpages invocation, all the manual pages are installed by the Perl build framework itself - use dh_prep instead of dh_clean in the "install" target * Remove the debian/debsigs.undocumented file - both programs listed there have already been documented. * Bump Standards-Version to 3.8.1: - move debhelper to Build-Depends from Build-Depends-Indep * Add the Vcs-Svn and Vcs-Browser source control fields. * Make the short description a noun phrase. * Clean up the rules file: - do not ignore "make clean" errors - remove some commented-out cruft - remove the OPTIMIZE flags to Makefile.PL - no C code here - pass -k to dh_clean in the "install" target - move some dh_* invocations from the "binary-indep" to the "install" target to mimic the behavior of the dh(1) tool - remove some dh_* invocations that simply do not apply - finally, minimize this file using debhelper 7's dh(1) tool :) * Stop debsigs-autosign from always passing key ID's and keyring paths to debsigs; gpg is smart enough to figure out which key to use and where to find it. Closes: #161541 * Make the test script include all the modules. * Use strict mode and enable Perl warnings for all modules and scripts. * Set the version of the debsigsmain module to the package's version. * Bump the version of all the other modules. * Add my copyright notice to the modules. * Add -h and -V options and syntax() and version() functions to all the executable scripts. Closes: #175337, #175338 * Fix a misspelled variable name in debsigs-autosign. * Document the signature types in the debsigs usage message and manual page, and refer to it from the debsigs-autosign ones. Closes: #457319 * Make the binary package recommend debsig-verify. Closes: #163643 * Teach debsigs-signchanges to extract the key ID from the changes file if it is not specified in $DEBSIGSOPTIONS. Closes: #98088 * Rework debsigs-signchanges so it recalculates all types of checksums listed in the changes file, not just MD5 ones. * Add the fixup() function to the arf module to read an archive file and remove the trailing slashes in the member names. Invoke that function in debsigs. Closes: #161680 -- Peter Pentchev Sat, 16 May 2009 18:27:40 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence, pgp0SflX9aXMY.pgp Description: PGP signature
Re: ITR: scrotwm - dynamic tiling window manager
On Wed, May 20, 2009 at 08:07:57AM +0200, Andrea Bolognani wrote: > On Wed, 20 May 2009 09:03:05 +0530 > Y Giridhar Appaji Nag wrote: > > > > 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. > > 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 :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. pgpv4x6dsCRVA.pgp Description: PGP signature
RFS: libdebug (adopted, updated, fixed bugs)
Dear mentors, I am looking for a sponsor for the new version 0.4.3-1 of my package "libdebug". This is an attempt to adopt the package, turn it into a non-native one, become upstream, bring the Debian packaging up to the current standards and best practices, and fix the single outstanding bug. It's a simple library written in C which provides logging and memory debugging routines, it has been in Debian since 2002, and it could use a little TLC :) It builds these binary packages: libdebug0 - Memory leak detection system and logging library libdebug0-dev - Development files for the debug library I'm aware that it would be better for the -dev package to be named just libdebug-dev, but I've decided not to change that in my first adoption upload. Of course, if an interested mentor thinks that it would be preferable to change it right away, I could do that, too. The package has been tested with lintian and pbuilder. The upload would fix these bugs: 437346 (nostrip), 499260 (ITA) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/l/libdebug/libdebug_0.4.3-1.dsc I would be glad if someone uploaded this package for me. JFYI, here's my adoption changelog entry: libdebug (0.4.3-1) unstable; urgency=low * New maintainer. Closes: #499260 * Override a "shlib calls exit" lintian warning - this is a debugging library, it is supposed to exit on grave errors. * Add a symbols file starting at libdebug0-0.4.2 obtained from mole. * Make this a non-native package. * Add a watch file. * Convert the copyright file to the machine-readable format and add my copyright notice. * Add the Vcs-Svn and Vcs-Browser control fields. * Bump the debhelper compatibility version to 7: - add misc:Depends to the binary package * Bump Standards-Version to 3.8.1: - use binary:Version instead of hardcoding the dependencies between the binary packages - support "nostrip" in DEB_BUILD_OPTIONS. Closes: #437346 - add the Homepage control field * Build with lots of compiler warning flags. * Build with -Werror if "werror" is in DEB_BUILD_OPTIONS. * Enable build hardening unless "nohardening" is in DEB_BUILD_OPTIONS. * Remove the unused debian/Makefile. * Remove debian/libdebug0.postinst - dh_makeshlibs takes care of this. * Do not try to clean the source in the "build" target, it's upstream's job now. * Use dh_install instead of dh_movefiles. * Minimize the rules file using debhelper override targets. * Pass prefix correctly during the install phase now that upstream supports DESTDIR in the canonical way. -- Peter Pentchev Thu, 28 May 2009 16:02:51 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpNiuJ6UGBY4.pgp Description: PGP signature
RFS: pslist -- utility that lists, kills, or renices a process and its descendants
Dear mentors, I am looking for a sponsor for my package "pslist". * Package name: pslist Version : 1.2-1 Upstream Author : Peter Pentchev (myself) * URL : http://devel.ringlet.net/sysutils/pslist/ * License : BSD-2 Section : misc Programming Lang: Perl It builds these binary packages: pslist - utility that lists, kills, or renices a process and its descendants pslist is a simple utility to list the process ID's of a process and all its children, and its children's children, and so on. If invoked with a command name which ends in 'kill', it sends a signal to a selected group of processes. If invoked with a command name which ends in 'renice', it sets the nice level of the selected group of processes. As witnessed by a recent exchange on the Debian Russian mailing list - http://lists.debian.org/debian-russian/2009/05/msg00571.html - there is indeed a demand (albeit limited) for such a utility, so I thought I'd share with the world something I wrote way back in 2000 and have used ever since :) The package has been tested with lintian and pbuilder. The upload would fix these bugs: 530539 (ITP) The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/p/pslist/pslist_1.2-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgpO6Q5vvWRv0.pgp Description: PGP signature
Re: RFS: pslist -- utility that lists, kills, or renices a process and its descendants
On Sun, May 31, 2009 at 09:48:10AM +1000, Ben Finney wrote: > Peter Pentchev writes: > > > pslist - utility that lists, kills, or renices a process and > > its descendants > > This is a good synopsis; my only note would be that it's a little too > long. Perhaps this is better: > > utility for management of a process and its descendants I chose "control" over "management", but thanks for the idea :) > > pslist is a simple utility to list the process ID's of a process and all > > its children, and its children's children, and so on. > > The apostophe (“'”) is never used to form a plural. Yep, seems so. Seems I took a trend for a rule, but yes, it seems that no authoritative style manual recommends "'s" for abbreviations, although it has become pretty much common practice in the past few years. Fixed, thanks. > You might also > ensure the term “PID” appears in the description, so that searches > using that term will find your package. > > I would suggest the above should read: > >… process IDs (PIDs) of a process and … Accepted :) > > If invoked with a command name which ends in 'kill', it sends a > > signal to a selected group of processes. If invoked with a command > > name which ends in 'renice', it sets the nice level of the selected > > group of processes. > > This sounds useful. Good fortune getting your package inspected and > sponsored. Thanks a lot for the language review! I took the opportunity to fix the "upstream" manual page and docs, too, and I just went ahead and released a new version, packaged it and uploaded it to mentors.d.n: dget -x http://mentors.debian.net/debian/pool/main/p/pslist/pslist_1.3-1.dsc G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. pgpLsOgKCKjRz.pgp Description: PGP signature
Re: RFS: pslist (3rd try) -- utility that lists, kills, or renices a process and its descendants
On Sat, May 30, 2009 at 05:16:48PM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for my package "pslist". Here we go again, with my changes after Ben Finney's recommendations, and a Standards Version bump to the just-released Policy 3.8.2 :) * Package name: pslist Version : 1.3-1 Upstream Author : Peter Pentchev (myself) * URL : http://devel.ringlet.net/sysutils/pslist/ * License : BSD-2 Section : misc Programming Lang: Perl It builds these binary packages: pslist - utility that controls a process and its descendants pslist is a simple utility to list the process IDs (PIDs) of a process and all its children, and its children's children, and so on. If invoked with a command name which ends in 'kill', it sends a signal to a selected group of processes. If invoked with a command name which ends in 'renice', it sets the nice level of the selected group of processes. > As witnessed by a recent exchange on the Debian Russian mailing list - > http://lists.debian.org/debian-russian/2009/05/msg00571.html - > there is indeed a demand (albeit limited) for such a utility, > so I thought I'd share with the world something I wrote way back > in 2000 and have used ever since :) > > The package has been tested with lintian and pbuilder. > > The upload would fix these bugs: 530539 (ITP) The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/p/pslist/pslist_1.3-1.dsc Thanks in advance! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgp8n8MGq7Lym.pgp Description: PGP signature
RFS: wmanager (updated the Debian packaging)
Dear mentors, I am looking for a sponsor for the new version 0.2.1-6 of my package "wmanager". This is just an update to the Debian packaging - quilt instead of dpatch, debhelper 7.2, Policy 3.8.2, et al (more info below). Mike O'Connor, who sponsored my last two uploads of wmanager, seems to be busy in the past couple of weeks, so I'm asking on the list. There is a single binary package: wmanager - window-manager selection tool used at X startup It has been tested with lintian and pbuilder. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-6.dsc I would be glad if someone uploaded this package for me. JFYI, here's my changelog entry for 0.2.1-6: wmanager (0.2.1-6) unstable; urgency=low * Switch to quilt for patch management: - change the patches' naming scheme - reformat the comment headers - update the README.source file - use the quilt plugin for debhelper in the rules file * Refresh the copyright file a bit: - move the homepage from Original-Source-Location to the control file's Homepage field. - remove the redundant Packaged-By and Packaged-Date fields - bump the CopyrightFormat proposal revision a bit - bump the year of my copyright notice for the Debian packaging * Add misc:Depends to the binary package. * Bump Standards-Version to 3.8.2 with no changes. * Move the various lists of installed files to debian/wmanager.* * Update a comment in the rules file - GCC 4.3 is the default now :) * Remove some cruft from the rules file. * Minimize the rules file using debhelper override targets. * Add the Vcs-Svn and Vcs-Browser control fields. * Make the short description a noun phrase. -- Peter Pentchev Wed, 17 Jun 2009 12:27:01 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgp3Kfr0rLDm7.pgp Description: PGP signature
Re: Packaging data for a CGI
On Sat, Jun 20, 2009 at 01:36:25PM +1000, Erik de Castro Lopo wrote: > Hi all, > > I'm packaging a command line app called hoogle that can also run as > a CGI (depending on whether QUERY_STRING or REQUEST_URI is defined). > The source package generates three binary packages: > >hoogle - the binary >hoogle-data - architecture independant data >hoogle-cgi - creates a symlink from /usr/lib/cgi-bin to the binary > in /usr/bin/ > > The issue I'm having is that the CGI also has some resources (an > XML file, a javascript file and some PNGs) that need to be put > somewhere appropriate so the web server can serve them in response > to a standard HTTP GET. > > I would put this somewhere under /var/www but the policy manual > says thats a bad idea: > >http://webapps-common.alioth.debian.org/draft/html/ch-issues.html > > Where should I put these resources? Look at some other packages; I believe the convention is to use /usr/share/. In your case, if there is already stuff in /usr/share/hoogle/ for the hoogle-data package, you might pick /usr/share/hoogle/www/ or www-data/ or something like that for the CGI script's resources. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgpVuJWZnG8kG.pgp Description: PGP signature
Re: Packaging data for a CGI
On Sat, Jun 20, 2009 at 08:08:49PM +1000, Erik de Castro Lopo wrote: > Peter Pentchev wrote: > > > Look at some other packages; I believe the convention is to use > > /usr/share/. In your case, if there is already stuff in > > /usr/share/hoogle/ for the hoogle-data package, you might pick > > /usr/share/hoogle/www/ or www-data/ or something like that for > > the CGI script's resources. > > Sorry, I don't think I explained my self clearly enough. > > The problem is that the CGI generates HTML which has links > which look like: > > /hoogle/hoogle.css > /hoogle/hoogle.png > /hoogle/hoogle.js > > which the web client would interpret as: > > http://host-cgi-was-served-from/hoogle/hoogle.css > > and so on. The obvious solution is to put them in /var/www/hoogle/ > but this location seems to be discouraged by the policy manual. > > I was wondering if there was another solution. Yes, there is, and that's exactly what I meant :) Sorry for not explaining this more clearly, or pointing at a specific package; take a look at e.g. the phpmyadmin or phppgadmin packages. (of course, I am not a Debian Developer, so the following might not necessarily be the right way of doing things; it's just that I've seen it done in more than one package) Your package should place the files into /usr/share/hoogle/www/. After that, it should either create a file in /etc/apache2/conf.d/ containing something like this (that's what phppgadmin does): Alias /hoogle /usr/share/hoogle/www/ Order allow,deny Allow from all # Any other options your data files might need ...or it should instruct the user to do that for the virtual hosts she wants it active on. It may also install a symlink in /var/www/hooogle/ pointing to /usr/share/hoogle/www/. The latter two options are what the phpmyadmin package does; also see its README.Debian file. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. pgpVx56hZnWbk.pgp Description: PGP signature
Re: Packaging data for a CGI
On Sat, Jun 20, 2009 at 08:39:46PM +0800, Paul Wise wrote: > On Sat, Jun 20, 2009 at 6:52 PM, Peter Pentchev wrote: > > > Your package should place the files into /usr/share/hoogle/www/. > > After that, it should either create a file in /etc/apache2/conf.d/ > > containing something like this (that's what phppgadmin does): > > > > Alias /hoogle /usr/share/hoogle/www/ > > Uhh, doesn't that mean the package will clobber /hoogle for every > vhost on the server? Actually, it does - that's why I mentioned phpmyadmin's advising the user to do that only for the virtual hosts that need it. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? pgpnV3r7czIoH.pgp Description: PGP signature
Re: Generating lintian-overrides file?
On Thu, Jun 25, 2009 at 08:52:30PM +1000, Erik de Castro Lopo wrote: > Chow Loong Jin wrote: > > > You could, but I am not aware of any lintian tag specifying the version > > of the package in it. Could you post the output of lintian exactly? > > Sorry, I think you misunderstood. Lintian complains about the file: > > > usr/lib/haskell-packages/ghc6/lib/Cabal-1.6.0.3/ghc-6.10.3/Distribution/License.hi > > The hand generated lintian overrides file contains this: > > libghc6-cabal-dev binary: extra-license-file > usr/lib/haskell-packages/ghc6/lib/Cabal-1.6.0.3/ghc-6.10.3/Distribution/License.hi > > However, every time the compiler version changes (6.10.3 above) or the > package version number changes (1.6.0.3 above) I need to hand edit the > overrides file. The overrides file may contain a kind of wildcards at the start or end of the information field - see section 2.4 of the Lintian documentation: Many tags can occur more than once (e.g. if the same error is found in more than one file). You can override a tag either completely by specifying its name (first line in the examples) or only one occurrence of it by specifying the additional info, too (second line in the examples). If you add an asterisk (*) at the start and/or end of the additional info, this will match arbitrary strings similar to the shell wildcard. Asterisks located at any other place in the info have no special meaning. This wildcard support was added in Lintian version 2.0.0. Thus, you could try something like: libghc6-cabal-dev binary: extra-license-file */Distribution/License.hi G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? pgp6gdpfAeGwP.pgp Description: PGP signature
Re: RFS: drcom-pum
On Thu, Jun 25, 2009 at 09:54:44PM +0800, Henry Huang wrote: > On Thu, Jun 25, 2009 at 3:55 AM, Jan Hauke Rahm wrote: [snip] > > As far as I can tell your package looks quite nice. Your debian/rules > > could be much shorter, though. Comments could be deleted and since > > you've already set dh compatibility to 7 you could also make use of it. > > A simple > > > > #!/usr/bin/make -f > > > > %: > > dh $@ > > > > would do the trick. > > it is the easiest way for me to use dh(1). > However, i need to specify the name of init script and drcomclient > manpage as follows: > > dh_installinit --name=drcom > dh_installman --name=drcom > > So i keep the original debian/rules by deleting the comments in it. Well, you can do that by either using... dh install --before init dh_installinit --foo dh install --before man dh_installman --bar dh install --remaining ...or, with debhelper (>= 7.0.50): override_dh_installinit: dh_installinit --foo override_dh_installman: dh_installman --bar %: dh $@ G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpI6rUv08Rx1.pgp Description: PGP signature
Re: RFS: drcom-pum
On Thu, Jun 25, 2009 at 04:12:39PM +0200, Jan Hauke Rahm wrote: > On Thu, Jun 25, 2009 at 09:54:44PM +0800, Henry Huang wrote: > > However, i need to specify the name of init script and drcomclient > > manpage as follows: > > > > dh_installinit --name=drcom > > dh_installman --name=drcom > > No problem with dh7 as well: > > | #!/usr/bin/make -f > | > | %: > | dh $@ > | > | override_dh_installinit: > | dh_installinit --name=drcom > | > | override_dh_installman: > | dh_installman --name=drcom Note that, as I said in my reply, the override targets appear in debhelper 7.0.50 (or, usually, 7.2.x), not just 7. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgpkKAqSm03sW.pgp Description: PGP signature
Re: RFS: drcom-pum
On Thu, Jun 25, 2009 at 05:16:11PM +0300, Peter Pentchev wrote: > On Thu, Jun 25, 2009 at 09:54:44PM +0800, Henry Huang wrote: > > On Thu, Jun 25, 2009 at 3:55 AM, Jan Hauke Rahm wrote: > [snip] > > > As far as I can tell your package looks quite nice. Your debian/rules > > > could be much shorter, though. Comments could be deleted and since > > > you've already set dh compatibility to 7 you could also make use of it. > > > A simple > > > > > > #!/usr/bin/make -f > > > > > > %: > > > dh $@ > > > > > > would do the trick. > > > > it is the easiest way for me to use dh(1). > > However, i need to specify the name of init script and drcomclient > > manpage as follows: > > > > dh_installinit --name=drcom > > dh_installman --name=drcom > > > > So i keep the original debian/rules by deleting the comments in it. > > Well, you can do that by either using... > > dh install --before init > dh_installinit --foo > dh install --before man > dh_installman --bar > dh install --remaining And, of course, this should be in the opposite order, since dh(1) invokes dh_installman before dh_installinit :) > ...or, with debhelper (>= 7.0.50): > > override_dh_installinit: > dh_installinit --foo > > override_dh_installman: > dh_installman --bar > > %: > dh $@ This is order-independent. Okay, okay, I know, three mails on the subject is about enough, I'm stopping now :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. pgp2vllIJyVQr.pgp Description: PGP signature
Re: RFS: drcom-pum
On Thu, Jun 25, 2009 at 10:39:13PM +0800, Henry Huang wrote: > my dh = 7.0.13 < 7.0.50 > It seems "override" could not take effects. Yep, so take a look at my message describing the use of --before and --remaining. You can still shorten your rules file a lot. > How to solve this problem -- i got no idea :( > > uscan warning: In debian/watch, > no matching hrefs for watch line > http://www.drcom-client.org/en/downloads/ > http://www.drcom-client.org/downloads/packages/src/drcom-pum-(.*)\.tar\.gz Right - you're examining http://www.drcom-client.org/en/downloads/ but you actually need to examine the Linux download page, http://www.drcom-client.org/en/downloads/linux.html And on that page, the links are *not* full URL's - look at the page source to see that they have http://www.drcom-client.org/en/downloads/linux.html /downloads/packages/src/drcom-pum-(.*)\.tar\.gz Note that I haven't actually tested this, you may have to tweak it a bit to suit your needs. Play around a bit with uscan --report --verbose ...and... uscan --report --debug ...to see the URL's that uscan parses from the page. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. pgpZhd0yBLSbx.pgp Description: PGP signature
RFS: dma -- lightweight mail transport agent (new package)
Dear mentors, I am looking for a sponsor for my new package "dma" (ITP: #511410). * Package name: dma Version : 0.0.2009.02.11-1 Upstream Author : Matthias Schmidt , Simon Schubert * URL : http://www.dragonflybsd.org/ * License : BSD Section : mail Programming Lang: C It builds a single binary package: dma- lightweight mail transport agent The DragonFly Mail Agent is a small Mail Transport Agent (MTA), designed for home and office use. It accepts mails from local Mail User Agents (MUA) and delivers them either to local mailboxes or remote SMTP servers. Remote delivery includes support for features such as TLS/SSL and SMTP authentication. dma is not intended as a replacement for full-featured MTAs like Sendmail, Postfix, or Exim. Consequently, dma does not listen on port 25 for incoming connections. The package has been tested with lintian and pbuilder. The upload would fix these bugs: 511410 (ITP) The package can be found on mentors.debian.net: dget http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.02.11-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgpvSNVaMslkH.pgp Description: PGP signature
Re: RFS: dma -- lightweight mail transport agent (new package)
On Mon, Jun 29, 2009 at 01:52:00AM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for my new package "dma" (ITP: #511410). > > * Package name: dma > Version : 0.0.2009.02.11-1 > Upstream Author : Matthias Schmidt , > Simon Schubert > * URL : http://www.dragonflybsd.org/ > * License : BSD > Section : mail > Programming Lang: C > > It builds a single binary package: > dma- lightweight mail transport agent > > The DragonFly Mail Agent is a small Mail Transport Agent (MTA), > designed for home and office use. It accepts mails from local Mail > User Agents (MUA) and delivers them either to local mailboxes or > remote SMTP servers. Remote delivery includes support for features > such as TLS/SSL and SMTP authentication. > > dma is not intended as a replacement for full-featured MTAs like > Sendmail, Postfix, or Exim. Consequently, dma does not listen on > port 25 for incoming connections. > > The package has been tested with lintian and pbuilder. > > The upload would fix these bugs: 511410 (ITP) Just a note that a bit earlier today, I reuploaded the dma package with the same version number, but with five more debconf translations that people had filed in the BTS against the (non-existent) package "dma" :) Thus, now the upload would fix #511410, #533458, #533614, #533890, #534101, and #534860. The package is at the same URL: dget http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.02.11-1.dsc Thanks in advance for any reviews and comments! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgp6MYyNUlKKI.pgp Description: PGP signature
Re: RFS: djmount
On Sun, Aug 09, 2009 at 08:18:27PM +0200, Patrick Matth??i wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Paul Wise schrieb: > > On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci > > (midget) wrote: > >> Nick Leverton wrote: > >>> The upstream package contains private copies of libtalloc and pupnp, both > >>> of > >>> which are already included in Debian in their own right (libtalloc1 and > >>> libupnp3). Perhaps you could consider specifying --with-external-libupnp > >>> and --with-external-talloc in your ./configure. If there are any > >>> changes you need to libupnp3, I would be pleased to receive suggestions > >>> in the BTS. IANADD so I can't upload for you, sorry. > >> PS: Shall I remove from the original sources 'libupnp' and 'talloc' and > >> rename the package to be > >> DFSG, or it's OK to distribute upstream sources like that ? > > > > By far the best is to talk to upstream and get them to remove the > > embedded code copies along with any patches needed to build properly. > > ACK. > > > > > Personally I wouldn't bother stripping the embedded code copies from > > the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules > > just before the ./configure call so that there is no chance of the > > package being built against the embedded code copies though. > > Moving would be better, because with this way you are modifying the > tarball and then you will mostly have an error on building the package > twice. AIUI, dpkg-source has no problem with files that are present in the .orig.tar.gz but are missing in the actual source directory - it just ignores the missing file and goes on. Isn't this the conventional way to deal with autotools-generated "configure", "Makefile", etc? So, IMHO, just removing them in the configure target should be fine. > I also do not see any need for it, if it realy builds against the system > wide libs. As Paul Wise said, the removing would be a good idea if the packager is not completely certain that the upstream build system will never, ever, under any circumstances, use the bundled source even if it is told to use the external libraries. Consider a build system that goes like, "Oh, okay, you told me to use the external library, but something changed, I can't quite locate the header file, or this definition is no longer available, or something just messed up... no matter, if I can't use the external library, I'll just use my own source, I *know* things will build just fine this way!". Honest, I've seen upstream sources that did that. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgp0tX7hZmew6.pgp Description: PGP signature
RFH, AlmostRFS: confget-1.02-2 (updated package)
Hi, This is not quite a request for sponsorship, but rather something like a request for help. The confget package, kindly sponsored by George Danchev back in March, has remained in unstable since then because of a FTBFS bug #526961 on the "mips" and "mipsel" architectures. I tried to ask for help on the debian-mips list - http://lists.debian.org/debian-mips/2009/05/msg9.html - but got no reply. As noted in both the bug log and my email to debian-mips, I strongly suspect a bug lurking in the hardening-wrapper; it might turn out that George Danchev was right in doubting whether the build should be hardened by default. FWIW, I personally think the hardening wrapper is a great idea, and I enable it by default in all my packages, but still... :) So, now for the actual RFH: could anybody with access to a Debian unstable installation on the mips or mipsel architecture try to build the confget-1.02-1 package as currently available in unstable? http://ftp.de.debian.org/debian/pool/main/c/confget/confget_1.02-1.dsc If the build fails as in the buildd logs, could you please try my new version at mentors.d.n: http://mentors.debian.net/debian/pool/main/c/confget/confget_1.02-2.dsc It is pretty much the same as 1.02-1, with the hardening wrapper disabled, groff used instead of groff-base, and a couple of minor fixups to the Debian packaging that should not affect the build or the test suite. If the version without the hardening should build successfully, just let me know and I'll upload a new one with the bug closed in the changelog entry. Otherwise... I'll just have to start thinking about what really causes the test failure :) Thanks in advance for any assistance! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgp7UpZfNb5i6.pgp Description: PGP signature
Re: RFH, AlmostRFS: confget-1.02-2 (updated package)
On Tue, Aug 11, 2009 at 10:20:40PM +0300, George Danchev wrote: > Hi, > [snip George quoting my RFH about confget FTBFS on mips and mipsel] > > That smells like a bug in the compiler which failed to produce correct > code on > these architectures with hardening options enabled. As I see it, all tests > failed at the same line in confget.c, so I guess we should be able to narrow > that down and reassign #526961 against gcc. I could try to build a test case or five; I'll look into this tomorrow. > Meanwhile, we can upload > confget_1.02-2 without closing #526961 with it. Agreed? Oh, that'd be great; thanks! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgptlYTJOxZFV.pgp Description: PGP signature
Re: Requests to sponsor new library packages (was: why?)
On Wed, Aug 19, 2009 at 10:11:12AM +1000, Ben Finney wrote: > Sune Vuorela writes: > > > For example, I would be very reluctant to sponsor a first package of a > > person that was a new library without any application using it, > > whereas a interesting kde application might easier catch my eye. > > That's interesting, thank you for that perspective. What do you propose, > then, for a maintainer who wants to get a new package into Debian, but > that package requires one or more separately-packaged libraries that > *also* need to be sponsored into Debian before the “interesting” package > can go in? I've had to do this with Perl modules once - I wanted to package a particular module, but it had a chain of dependencies that were not packaged yet. What I did was file a series of ITP bugs, stating my intentions clearly - first for the "target" package, saying "This module also needs So-And-So and This-And-That, which will be ITP'd separately", and then for the dependencies, each ITP stating "This module is needed for the packaging of So-And-So (ITP #NNN)". A couple of days later, helpful people from the Debian Perl Group did the last part that I'd missed - made the ITP bugs block one another in the proper order. Thus, anyone who reads the library bug sees "it is needed for ITP #NNN", and anyone who reads the original ITP bug sees "blocked by #NNN" and knows why it hasn't been RFS'd yet. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgpeCahtl8XsC.pgp Description: PGP signature
RFS: mbuffer (new package)
Dear mentors, I am looking for a sponsor for the initial upload of my package "mbuffer" - a simple tool for buffering data streams for various purposes, including writing to block devices, testing throughput, and many others. * Package name: mbuffer Version : 20090628-1 Upstream Author : Thomas Maier-Komor * URL : http://www.maier-komor.de/mbuffer.html * License : GPL-3+ * Language: C There is a single binary package: mbuffer- tool for buffering data streams The mbuffer tool is used to buffer data streams and show the I/O rate and summary to the user. It is especially useful for writing backups to fast tape drives or streaming them over the network. If used correctly, it can prevent buffer underruns and speed up the whole backup or transfer process. It has been tested with lintian and pbuilder. The upload would fix these bugs: 534216 The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/m/mbuffer/mbuffer_20090628-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpjrXy9v2nbt.pgp Description: PGP signature
RFS: donkey (adopted & updated)
Dear mentors,
I am looking for a sponsor for version 0.5-18 of the package "donkey"
which I am trying to adopt (ITA #541053). It is a simple S/Key
(one time password) generator which could come quite useful to
people who still care :)
* Package name: donkey
Version : 0.5-18
Upstream Author : Kazuhiko Yamamoto
* License : GPL-2/GPL-2+
Language: C
Section : net
It builds a single binary packages:
donkey - One Time Password calculator
The package has been tested with lintian and pbuilder.
The upload would fix these bugs: 414341 (FTBFS), 541053 (ITA)
The package can be found on mentors.debian.net:
dget -x http://mentors.debian.net/debian/pool/main/d/donkey/donkey_0.5-18.dsc
JFYI, here's my adoption changelog entry:
donkey (0.5-18) unstable; urgency=low
* New maintainer. Closes: #541053
* Fix a FTBFS on GNU/kFreeBSD. Closes: #414341
* Properly clean up the object directory as also suggested by
Cyril Brulebois in #414341 :)
* Add the Vcs-Svn and Vcs-Browser control fields.
* Add a watch file.
* Escape several minus signs in the manual page.
* Remove the dot at the end of the short description.
* Specify a debhelper compatibility version of 7:
- create the debian/compat file
- install into debian/donkey instead of debian/tmp
- version the debhelper build dependency
- add ${misc:Depends} to the binary package
- minimize the rules file using override targets
* Bump Standards-Version from 3.2.1 to 3.8.3 with no changes :)
* Add all copyright holders to the copyright file and convert it to
the DEP 5 format.
* Silence a couple of compiler warnings with a quilt patch and
a README.source file to note the use of quilt.
* Use the build hardening wrapper.
-- Peter Pentchev Fri, 21 Aug 2009 16:14:13 +0300
I would be glad if someone uploaded this package for me.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Hey, out there - is it *you* reading me, or is it someone else?
pgpIKOGXor4nq.pgp
Description: PGP signature
Re: RFS: donkey (adopted & updated)
On Sat, Aug 22, 2009 at 10:07:41AM +0200, Patrick Matth??i wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Peter Pentchev schrieb:
> > Dear mentors,
> >
> > I am looking for a sponsor for version 0.5-18 of the package "donkey"
> > which I am trying to adopt (ITA #541053). It is a simple S/Key
> > (one time password) generator which could come quite useful to
> > people who still care :)
> >
> > * Package name: donkey
> > Version : 0.5-18
> > Upstream Author : Kazuhiko Yamamoto
> > * License : GPL-2/GPL-2+
> > Language: C
> > Section : net
> >
> > It builds a single binary packages:
> > donkey - One Time Password calculator
> >
> > The package has been tested with lintian and pbuilder.
> >
> > The upload would fix these bugs: 414341 (FTBFS), 541053 (ITA)
> >
> > The package can be found on mentors.debian.net:
> > dget -x
> > http://mentors.debian.net/debian/pool/main/d/donkey/donkey_0.5-18.dsc
> >
> > JFYI, here's my adoption changelog entry:
>
>
> Hello,
Hi, and thanks for the review! I've uploaded a new package with
the same version at the above URL, which fixes some of your issues and
also reformats the long description field, as suggested by Kartik Mistry
in private mail. Responses inline...
> > donkey (0.5-18) unstable; urgency=low
> >
> > * New maintainer. Closes: #541053
> > * Fix a FTBFS on GNU/kFreeBSD. Closes: #414341
> > * Properly clean up the object directory as also suggested by
> > Cyril Brulebois in #414341 :)
>
> I realy do not like smileys in changelogs, please remove it.
Point taken. I was kinda doubtful about it myself. Smiley removed.
> > * Add the Vcs-Svn and Vcs-Browser control fields.
> > * Add a watch file.
> > * Escape several minus signs in the manual page.
> > * Remove the dot at the end of the short description.
> > * Specify a debhelper compatibility version of 7:
> > - create the debian/compat file
> > - install into debian/donkey instead of debian/tmp
> > - version the debhelper build dependency
> > - add ${misc:Depends} to the binary package
> > - minimize the rules file using override targets
> > * Bump Standards-Version from 3.2.1 to 3.8.3 with no changes :)
>
> Same and I do not believe that you can switch from 3.2 to 3.8 without
> changes, what is e.g. with donkey-0.5/debian/README.source
Again, smiley removed. As to the standards version update, well, for
a very simple package that has nothing to do with X, is not a webserver,
and uses debhelper, it is, indeed, possible. I was surprised, too,
but it's true.
The changelog entries were written in the order of doing the work.
The Standards Version update came *before* the C compiler warnings fix,
and the quilt usage (thus README.source) is only there because of
the warnings fix. So, at the time I bumped Standards-Version, there
was no README.source file.
> > * Add all copyright holders to the copyright file and convert it to
> > the DEP 5 format.
> > * Silence a couple of compiler warnings with a quilt patch and
> > a README.source file to note the use of quilt.
> > * Use the build hardening wrapper.
>
> I do not think that this is a good idea, the package is highly experimental.
> You may manual add/override compiler flags in debian/rules.
True. My recent problems with confget (see #526961), and yours and
George Danchev's doubts about the hardening wrapper have just managed
to cause me to change my own policy on using it :) In the new package,
the hardening wrapper is enabled if "hardening" is in DEB_BUILD_OPTIONS.
> > -- Peter Pentchev Fri, 21 Aug 2009 16:14:13 +0300
> >
> > I would be glad if someone uploaded this package for me.
>
> Last note:
>
> Your package lacks a homepage control field.
Yes, I know; there simply isn't one. It seems that upstream has been,
to put it mildly, not very active for the past couple of years.
Still, since donkey is a useful and simple piece of software, I fully
intend to take over upstream duties, too, if the need should arise;
if that happens, there will be an upstream homepage.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
"yields falsehood, when appended to its quotation." yields falsehood, when
appended to its quotation.
pgpiajNWh2BPk.pgp
Description: PGP signature
RFS: gforth (adopted & updated)
Dear mentors,
I am looking for a sponsor for the new version 0.7.0+ds1-1
of my package "gforth". This is an adoption upload (ITA #540827)
which pretty much overhauls the Debian packaging, fixes a long-standing
manpage rendering problem, and fixes a bug regarding the proper
compilation and installation of the Emacs Forth mode file.
Gforth used to build a single package, but with this version I'm
splitting the shared data out:
gforth- GNU Forth Language Environment
gforth-common - GNU Forth architecture-independent dictionaries
The package has been tested with lintian and pbuilder.
The upload would fix these bugs: 385399 (gforth.el), 540827 (ITA)
The package can be found on mentors.debian.net:
http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-1.dsc
JFYI, here's my adoption changelog entry. I'd be glad for any comments,
since I do realize that a whole night of hacking instead of sleeping is
liable to leave a loose end or three somewhere :)
gforth (0.7.0+ds1-1) unstable; urgency=low
* New maintainer. Closes: #540827
* Use quilt for patch management and add the debian/README.source file.
* Fix the build:
- specify an absolute prefix to "make install".
- remove a couple of files that "make distclean" seems to miss.
* Add the Homepage, Vcs-Svn, and Vcs-Browser control fields.
* Install the NEWS file as an upstream changelog.
* Deal with config.sub and config.guess properly - copy them from
the autotools-dev package before running "configure" and remove them
in the "clean" target.
* Keep the vmgen.1 manual page in the debian/ directory.
* Bump the debhelper compatibility level to 7:
- version the debhelper build dependency
- add ${misc:Depends} to the binary package
- leave removing of the *-stamp files to dh_clean
- use dh_prep instead of dh_clean -k
- shorten the rules file using the dh(1) helper and override targets
- disable debhelper's verbose mode
* Bump Standards-Version to 3.8.3:
- leave "install-info" to dpkg triggers and add the proper dependency
* Disable an i*86 "optimization" of passing the non-existing -m486
option to gcc.
* Break out /usr/share/gforth/ into a gforth-common package.
* Make three example scripts executable.
* Repackage to remove the CVS directories.
* Fix the .TQ macro invocations in the groff.1 manual page so that
the short options are actually rendered!
* Add all the copyright holders to the copyright file and convert it
to the DEP 5 format.
* Properly compile and install gforth.el. Closes: #385399.
-- Peter Pentchev Sun, 23 Aug 2009 10:05:05 +0300
I would be glad if someone uploaded this package for me.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence was in the past tense.
pgpdw8KT2QHDE.pgp
Description: PGP signature
Re: RFS: gforth (adopted & updated)
On Sun, Aug 23, 2009 at 09:39:20AM +0200, Patrick Matthaei wrote: > Peter Pentchev schrieb: > > Dear mentors, > > > > I am looking for a sponsor for the new version 0.7.0+ds1-1 > > of my package "gforth". This is an adoption upload (ITA #540827) > > which pretty much overhauls the Debian packaging, fixes a long-standing > > manpage rendering problem, and fixes a bug regarding the proper > > compilation and installation of the Emacs Forth mode file. > > > > Gforth used to build a single package, but with this version I'm > > splitting the shared data out: > > gforth- GNU Forth Language Environment > > gforth-common - GNU Forth architecture-independent dictionaries > > > > The package has been tested with lintian and pbuilder. > > > > The upload would fix these bugs: 385399 (gforth.el), 540827 (ITA) > > > > The package can be found on mentors.debian.net: > > http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-1.dsc > > > > JFYI, here's my adoption changelog entry. I'd be glad for any comments, > > since I do realize that a whole night of hacking instead of sleeping is > > liable to leave a loose end or three somewhere :) > > > > Hello, > > on the first look it is fine, but I found a RC bug: > > > gforth (0.7.0+ds1-1) unstable; urgency=low > > > > * New maintainer. Closes: #540827 [snip] > > * Break out /usr/share/gforth/ into a gforth-common package. > > You are missing replaces and conflicts at your new gforth-common > package, upgrades / installations would fail if they install your > - -common package and the old gforth one. Oh, right. Thanks! I've uploaded a new version at the same mentors.d.n. URL: http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-1.dsc Thanks for the quick peek! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpFiiRaNXyvI.pgp Description: PGP signature
Re: RFS: gforth (adopted & updated)
On Sun, Aug 23, 2009 at 01:01:51PM +0200, Patrick Matthaei wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Peter Pentchev schrieb: > > On Sun, Aug 23, 2009 at 09:39:20AM +0200, Patrick Matthaei wrote: > >> Peter Pentchev schrieb: > >>> Dear mentors, > >>> > >>> I am looking for a sponsor for the new version 0.7.0+ds1-1 > >>> of my package "gforth". This is an adoption upload (ITA #540827) > >>> which pretty much overhauls the Debian packaging, fixes a long-standing > >>> manpage rendering problem, and fixes a bug regarding the proper > >>> compilation and installation of the Emacs Forth mode file. > >>> > >>> Gforth used to build a single package, but with this version I'm > >>> splitting the shared data out: > >>> gforth- GNU Forth Language Environment > >>> gforth-common - GNU Forth architecture-independent dictionaries > >>> > >>> The package has been tested with lintian and pbuilder. > >>> > >>> The upload would fix these bugs: 385399 (gforth.el), 540827 (ITA) > >>> > >>> The package can be found on mentors.debian.net: > >>> http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-1.dsc > >>> > >>> JFYI, here's my adoption changelog entry. I'd be glad for any comments, > >>> since I do realize that a whole night of hacking instead of sleeping is > >>> liable to leave a loose end or three somewhere :) > >>> > >> Hello, > >> > >> on the first look it is fine, but I found a RC bug: > >> > >>> gforth (0.7.0+ds1-1) unstable; urgency=low > >>> > >>> * New maintainer. Closes: #540827 > > [snip] > >>> * Break out /usr/share/gforth/ into a gforth-common package. > >> You are missing replaces and conflicts at your new gforth-common > >> package, upgrades / installations would fail if they install your > >> - -common package and the old gforth one. > > > > Oh, right. Thanks! > > > > I've uploaded a new version at the same mentors.d.n. URL: > > http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-1.dsc > > There are licenses missing, e.g (didn't checked everything): > > gforth-0.7.0+ds1$ licensecheck -r .|grep LGPL > ./engine/strtoul.c: LGPL (v3 or later) (with incorrect FSF address) > ./engine/dblsub.c: LGPL (v3 or later) (with incorrect FSF address) > ./engine/getopt1.c: LGPL (v3 or later) (with incorrect FSF address) > ./engine/strtol.c: LGPL (v3 or later) (with incorrect FSF address) > > In debian/copyright there is nothing about LGPL > > Please also check for possible other missing licenses. Oops. Good catch. I've learned not to trust licensecheck fully and also do my own pass over all the source files; in this case, it seems I wasn't as thorough as I should've been - caught lots of different licenses, but mistook the LGPL-3+ files for full GPL-3+. Now that I took another look, there were also several more GFDL files. Reuploaded at the same mentors.d.n location. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpjD5SskECfx.pgp Description: PGP signature
RFS: gforth (updated, fixes FTBFS on all buildds)
Dear mentors, I am looking for a sponsor for the new version 0.7.0+ds1-2 of my package "gforth". Patrick Matthaei kindly uploaded 0.7.0+ds1-1 a couple of days ago, but it turns out that I had completely forgotten that the buildd framework only builds the arch-indep packages once and then builds just the arch-dep packages on the rest of the buildd's... which my rules file failed miserably for a silly reason. The only change in this version is the creation of a directory at the proper time. It builds these binary packages: gforth - GNU Forth Language Environment gforth-common - GNU Forth architecture-independent dictionaries The package has been tested with lintian and pbuilder. The upload would fix these bugs: 543569 (FTBFS) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-2.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpVbCE49gSj2.pgp Description: PGP signature
RFS: dma (updated, bugs fixed)
Dear mentors, I am looking for a sponsor for the new version 0.0.2009.07.17-2 of my package "dma". It updates the packaging a bit and fixes two bugs from the Debian BTS - allows the spool directory to live on a filesystem like XFS that does not set the d_type field in the dirent structure, and generates better, longer, more random, more reliable Message-Id fields on new messages if the MUA has not done so. It builds a single binary package: dma- lightweight mail transport agent The package has been tested with lintian and pbuilder. The upload would fix these bugs: 544357 (spool on XFS), 544475 (better Message-Id) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-2.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: dma (0.0.2009.07.17-2) unstable; urgency=low * Allow the spool directory to live on a filesystem that does not set the d_type member of the dirent structure, like XFS. Closes: #544357 * Randomize the Message-Id a bit more. Closes: #544475 * Bump Standards-Version to 3.8.3 with no changes. * Only enable the build hardening wrapper if the "hardening" build option is specified. * Switch the copyright file header from the Wiki to DEP 5. * Remove the manual page ".Dx" patch - the groff version in Squeeze knows about the .Dx mdoc macro. Add a lintian override for the "Unknown DragonFly version" error. * Convert the patch file headers to the DEP 3 format. -- Peter Pentchev Tue, 01 Sep 2009 13:36:33 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? pgppBHmgWU1T3.pgp Description: PGP signature
RFS: gforth (updated)
Dear mentors, I am looking for a sponsor for the new version 0.7.0+ds1-3 of my package "gforth". This is an attempt to fix three different failures to build on mips, armel, and s390 respectively. It builds these binary packages: gforth - GNU Forth Language Environment gforth-common - GNU Forth architecture-independent dictionaries The package has been tested with lintian and pbuilder. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-3.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: gforth (0.7.0+ds1-3) unstable; urgency=low * Explicitly depend on libtool and libltdl-dev; several benefits: - make the build environment-agnostic and not dependent on what just happens to be installed - fix a FTBFS if libtool is installed but libltdl-dev isn't; some of the autobuilders are configured that way * Add a missing semicolon in engine/support.c to try and fix the FTBFS on s390. * Temporarily use libffi instead of libffcall on armel, until libffcall's issues are resolved. -- Peter Pentchev Tue, 01 Sep 2009 17:58:12 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. pgpwMBpXo3Swi.pgp Description: PGP signature
s390 and hppa virtual machines?
Hi, One of my packages, gforth, is having a weird FTBFS on hppa and a not-so-weird FTBFS on s390. A couple of weeks ago I asked here about help with a mips/mipsel problem, and two people kindly pointed out qemu as a way to (slowly, but still something) test things on different architectures. This, along with Aurelien Jarno's images at http://people.debian.org/~aurel32/qemu/ helped a lot with mips, mipsel, and armel. Is there anywhere I could find a ready-made qemu image of lenny, squeeze, or sid for either s390 or hppa? Installing it from scratch would be a bit more time-consuming than upgrading a ready-made image :( If not, could anyone suggest some other emulation environment that I could use for s390 or hppa? I came across a couple of mentions of Hercules, but they were all several years old. Any help would be appreciated. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. pgpHW92AMHToY.pgp Description: PGP signature
Re: RFS: mbuffer (new package)
On Wed, Aug 19, 2009 at 06:27:26PM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for the initial upload of my package > "mbuffer" - a simple tool for buffering data streams for various > purposes, including writing to block devices, testing throughput, > and many others. Nobody interested? :) > * Package name: mbuffer > Version : 20090628-1 > Upstream Author : Thomas Maier-Komor > * URL : http://www.maier-komor.de/mbuffer.html > * License : GPL-3+ > * Language: C > > There is a single binary package: > mbuffer- tool for buffering data streams > The mbuffer tool is used to buffer data streams and show the I/O rate and > summary to the user. It is especially useful for writing backups to > fast tape drives or streaming them over the network. If used correctly, > it can prevent buffer underruns and speed up the whole backup or > transfer process. > > It has been tested with lintian and pbuilder. > > The upload would fix these bugs: 534216 > > The package can be found on mentors.debian.net: > http://mentors.debian.net/debian/pool/main/m/mbuffer/mbuffer_20090628-1.dsc > > I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Do you think anybody has ever had *precisely this thought* before? pgpFHvlrg9rhf.pgp Description: PGP signature
RFS: hexer (updated, adopted upstream, cleaned up)
Dear mentors, I am looking for a sponsor for the new version 0.1.5-1 of my package "hexer". I've adopted the upstream development of hexer, integrated the Debian patches, cleaned it up a lot, and fix a nasty crash (or a weird display of characters in the status line) reported in the Debian BTS (#540571). It builds a single binary package: hexer - An interactive binary editor with a Vi-like interface The package has been tested with lintian and pbuilder. The upload would fix these bugs: 540571 (v*printf() abuse leading to a crash) The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.5-1.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: hexer (0.1.5-1) unstable; urgency=low * New upstream release: - I adopted the upstream package, too - all the patches were integrated upstream - the installation directories need to be passed in the environment - lots of cleanup - fix a crash due to abuse of the v*printf() routines (Closes: #540571) * No longer use quilt, drop the README.source file. * Add a Homepage field now that I'm providing one :) * Use the build hardening wrapper if the "hardening" option is enabled. * Bump Standards-Version to 3.8.3 with no changes. * Point the watch file and the copyright file to the new upstream page. * Update the copyright file. * Use the DEP 5 format for the copyright file header. -- Peter Pentchev Fri, 04 Sep 2009 14:46:46 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgp6pIoiAr4x5.pgp Description: PGP signature
RFS: qliss3d (adopted & updated)
Dear mentors, I am looking for a sponsor for the new version 1.3.2-5 of my package "qliss3d". I'm trying to adopt the package (ITA #446448) and update the Debian packaging quite a bit. It builds a single binary package: qliss3d- demonstration tool for Lissajous figures The package has been tested with lintian and pbuilder. I know that there is a newer upstream version, I decided to handle this after the adoption clean-up upload. There is also a 'no upstream changelog' lintian warning, which I'll bring up with upstream after I update to version 1.3.2.1. The upload would fix these bugs: 446448 (ITA) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/q/qliss3d/qliss3d_1.3.2-5.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: qliss3d (1.3.2-5) unstable; urgency=low * New maintainer. Closes: #446448 * Refresh config.sub and config.guess at configure time and remove them at clean-up time to avoid them polluting the diff.gz. * Point to SourceForge in the Homepage field and the copyright file. * Add a watch file pointing to Bart Martens's unofficial redirector. * Switch from dpatch to quilt. * Add the 11-cxxflags.patch to actually pass the proper flags to the C++ compiler. * Remove all the CFLAGS handling from the rules file - we do not even *have* any plain C code! * Bump Standards-Version to 3.8.3: - add the README.source file to note the use of quilt * Convert the copyright file to the DEP 5 format and add my own copyright notice for the Debian packaging files. * Remove the deprecated "Encoding" field from the desktop file. * Bump the debhelper compatibility level to 7: - let dh_auto_configure determine whether --build and --host are needed - add 12-destdir.patch to honor DESTDIR and simplify the installation - minimize the rules file using debhelper override targets * Add 13-warnings.patch to fix a couple of compiler warnings. * Enable the build hardening wrapper if "hardening" is specified in DEB_BUILD_OPTIONS. * Add 14-libm.patch to help the configure script find pow(3) and sqrt(3) in libm. * Add a DEP 3 header to 10-locale.patch to match the new patches. -- Peter Pentchev Fri, 04 Sep 2009 11:19:57 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgp7rIbHSCRrl.pgp Description: PGP signature
RFS: gforth (updated, fix FTBFS on s390)
Dear mentors, I am looking for a sponsor for the new version 0.7.0+ds1-4 of my package "gforth". It tries (again, a bit harder this time) to fix a FTBFS on s390. It builds these binary packages: gforth - GNU Forth Language Environment gforth-common - GNU Forth architecture-independent dictionaries The package has been tested with lintian and pbuilder. The upload would fix these bugs: 544827 (FTBFS on s390) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-4.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgpQyVHXJdin1.pgp Description: PGP signature
Re: RFS: mobile-broadband-provider-info (updated package)
On Mon, Sep 07, 2009 at 06:11:21AM +0100, Bhavani Shankar R wrote: > On Mon, Sep 7, 2009 at 5:44 AM, Kartik Mistry wrote: > > > Some points: > > + There are couple of Lintian info/messages you may want to fix. > > > > There is already upstream target in rules file (apt-get orig-source) and I > dont think watch file is required explicitly.. If you want I > can add it :) Isn't the watch file also useful for keeping track of the packages using the Debian External Health System - http://qa.debian.org/ ? I personally find it very, very useful for the packages I maintain - keeping my developer QA page always open in a browser tab and taking a look at the "Watch" column every day or so helps a lot. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. pgpKWXitddCf0.pgp Description: PGP signature
RFS: wmanager (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.2.1-7 of my package "wmanager". This version adds some useful functionality to the wmanager-loop utility (maintained as part of the Debian package, although I have some hope that the upstream maintainer will accept it one day) and also fixes some packaging nits (see the changelog entry below). It builds a single binary package: wmanager - window-manager selection tool used at X startup The package has been tested with lintian and pbuilder. It can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-7.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: wmanager (0.2.1-7) unstable; urgency=low * Let wmanager-loop honor the WM environment variable, if set, to specify the first window manager to run. * Bump the debhelper version dependency to 7.0.50 because of the use of override targets. * Bump Standards-Version to 3.8.3 with no changes. * Switch the copyright file header from the Wiki page to DEP 5 and shorten the file by breaking out the GPL-2+ blurb into its own block. * Actually implement the "patch" and "unpatch" targets in the rules file since the dh(1) tool does not always provide them. * Convert the patch file headers to DEP 3. * Only enable the build hardening wrapper if "hardening" is specified in DEB_BUILD_OPTIONS. -- Peter Pentchev Tue, 08 Sep 2009 18:02:52 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgppDTAl0nS2H.pgp Description: PGP signature
RFS: gforth (updated, fix FTBFS)
Dear mentors, I am looking for a sponsor for the new version 0.7.0+ds1-5 of my package "gforth". The only change in this version is that, with the kind assistance of Frans Pop and the other members of the debian-hppa list, I managed to fix the last FTBFS, the one on hppa. It builds these binary packages: gforth - GNU Forth Language Environment gforth-common - GNU Forth architecture-independent dictionaries The package has been tested with lintian and pbuilder. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/g/gforth/gforth_0.7.0+ds1-5.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpDJU9OUXqgm.pgp Description: PGP signature
Re: RFS: qliss3d (adopted & updated)
On Fri, Sep 04, 2009 at 03:15:12PM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.3.2-5 > of my package "qliss3d". I'm trying to adopt the package > (ITA #446448) and update the Debian packaging quite a bit. Bump? :) > It builds a single binary package: > qliss3d- demonstration tool for Lissajous figures > > The package has been tested with lintian and pbuilder. > I know that there is a newer upstream version, I decided to > handle this after the adoption clean-up upload. There is also > a 'no upstream changelog' lintian warning, which I'll bring up > with upstream after I update to version 1.3.2.1. > > The upload would fix these bugs: 446448 (ITA) > > The package can be found on mentors.debian.net: > http://mentors.debian.net/debian/pool/main/q/qliss3d/qliss3d_1.3.2-5.dsc > > I would be glad if someone uploaded this package for me. > > JFYI, here's the changelog entry: > > qliss3d (1.3.2-5) unstable; urgency=low > > * New maintainer. Closes: #446448 > * Refresh config.sub and config.guess at configure time and remove them > at clean-up time to avoid them polluting the diff.gz. > * Point to SourceForge in the Homepage field and the copyright file. > * Add a watch file pointing to Bart Martens's unofficial redirector. > * Switch from dpatch to quilt. > * Add the 11-cxxflags.patch to actually pass the proper flags to > the C++ compiler. > * Remove all the CFLAGS handling from the rules file - we do not even > *have* any plain C code! > * Bump Standards-Version to 3.8.3: > - add the README.source file to note the use of quilt > * Convert the copyright file to the DEP 5 format and add my own > copyright notice for the Debian packaging files. > * Remove the deprecated "Encoding" field from the desktop file. > * Bump the debhelper compatibility level to 7: > - let dh_auto_configure determine whether --build and --host are needed > - add 12-destdir.patch to honor DESTDIR and simplify the installation > - minimize the rules file using debhelper override targets > * Add 13-warnings.patch to fix a couple of compiler warnings. > * Enable the build hardening wrapper if "hardening" is specified > in DEB_BUILD_OPTIONS. > * Add 14-libm.patch to help the configure script find pow(3) and > sqrt(3) in libm. > * Add a DEP 3 header to 10-locale.patch to match the new patches. > > -- Peter Pentchev Fri, 04 Sep 2009 11:19:57 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. pgpxgOTJQFLAN.pgp Description: PGP signature
Re: RFS: mbuffer (new package)
On Thu, Sep 03, 2009 at 01:03:06PM +0300, Peter Pentchev wrote: > On Wed, Aug 19, 2009 at 06:27:26PM +0300, Peter Pentchev wrote: > > Dear mentors, > > > > I am looking for a sponsor for the initial upload of my package > > "mbuffer" - a simple tool for buffering data streams for various > > purposes, including writing to block devices, testing throughput, > > and many others. > > Nobody interested? :) Bump? :) > > * Package name: mbuffer > > Version : 20090628-1 > > Upstream Author : Thomas Maier-Komor > > * URL : http://www.maier-komor.de/mbuffer.html > > * License : GPL-3+ > > * Language: C > > > > There is a single binary package: > > mbuffer- tool for buffering data streams > > The mbuffer tool is used to buffer data streams and show the I/O rate and > > summary to the user. It is especially useful for writing backups to > > fast tape drives or streaming them over the network. If used correctly, > > it can prevent buffer underruns and speed up the whole backup or > > transfer process. > > > > It has been tested with lintian and pbuilder. > > > > The upload would fix these bugs: 534216 > > > > The package can be found on mentors.debian.net: > > http://mentors.debian.net/debian/pool/main/m/mbuffer/mbuffer_20090628-1.dsc > > > > I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpJqnZthGn6J.pgp Description: PGP signature
Re: RFS: wmanager (updated package)
On Wed, Sep 09, 2009 at 12:05:45AM +0300, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.2.1-7 > of my package "wmanager". This version adds some useful > functionality to the wmanager-loop utility (maintained as > part of the Debian package, although I have some hope that > the upstream maintainer will accept it one day) and also > fixes some packaging nits (see the changelog entry below). Bump? :) > It builds a single binary package: > wmanager - window-manager selection tool used at X startup > > The package has been tested with lintian and pbuilder. > > It can be found on mentors.debian.net: > http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-7.dsc > > I would be glad if someone uploaded this package for me. > > JFYI, here's the changelog entry: > > wmanager (0.2.1-7) unstable; urgency=low > > * Let wmanager-loop honor the WM environment variable, if set, to > specify the first window manager to run. > * Bump the debhelper version dependency to 7.0.50 because of the use > of override targets. > * Bump Standards-Version to 3.8.3 with no changes. > * Switch the copyright file header from the Wiki page to DEP 5 and > shorten the file by breaking out the GPL-2+ blurb into its own block. > * Actually implement the "patch" and "unpatch" targets in the rules file > since the dh(1) tool does not always provide them. > * Convert the patch file headers to DEP 3. > * Only enable the build hardening wrapper if "hardening" is specified > in DEB_BUILD_OPTIONS. > > -- Peter Pentchev Tue, 08 Sep 2009 18:02:52 +0300 G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgpxBQgFYeLv2.pgp Description: PGP signature
RFS: timelimit (updated, new upstream)
Dear mentors, I am looking for a sponsor for the new version 1.5-1 of my package "timelimit". It builds a single binary package: timelimit - Simple utility to limit a process's absolute execution time It has been tested with lintian and pbuilder. The upload would fix these bugs: 547452 (alternate signal reporting) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/t/timelimit/timelimit_1.5-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. pgptvtJhTfCCl.pgp Description: PGP signature
