Re: RFS: gnome-inm-forecast
OoO En cette nuit striée d'éclairs du lundi 02 juin 2008, vers 02:00, Gustavo Iñiguez Goya [EMAIL PROTECTED] disait: Dear mentors, I am looking for a sponsor for my package gnome-inm-forecast. * Package name: gnome-inm-forecast Version : 0.6.1 Upstream Author : Gustavo Iñiguez Goya [EMAIL PROTECTED] * URL : http://kutxa.homeunix.org/trac/gnome-inm-forecast * License : GPL Section : gnome It builds these binary packages: gnome-inm-forecast - Spanish weather forecast applet for the GNOME desktop Hi Gustavo! What is the difference with the forecast applet shipped in Gnome? -- panic(huh?\n); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c pgpu6SeDjwRiD.pgp Description: PGP signature
Re: RFS: gnome-inm-forecast
On Mon, Jun 2, 2008 at 2:14 PM, Vincent Bernat [EMAIL PROTECTED] wrote: What is the difference with the forecast applet shipped in Gnome? The ITP listed a few. Ideally upstream would have got their code added to the GNOME applet and libgweather. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: automake-idl
* Olaf Mandel [EMAIL PROTECTED] [080602 03:40]: * the repeated use of $(CURDIR) where a . or nothing at all would have sufficed is a bit annoying. (especially when done unsafe and unecessarily adding new problems if paths contain spaces). Actually, the unprotected use was only in the parts created by dh_make. I changed those. Also, I made the strings a bit shorter by using the variable $(DESTDIR) instead of $(CURDIR)/debian/foo. But leaving out $(CURDIR) completely... I like how it reminds me of where executables are and relative to which path I am working. Is it really that bad? I only said a bit annoying. '$(CURDIR)/configure' is quite more to parse than './configure'. * having a build-indep and a build-arch (the latter doing nothing) would be nice. Added. Thanks. But install still depends on build = build-indep. It's not like it makes any difference for this package, thus what install depends on does not matter. For packages having both build-arch and build-indep doing something and those being able to be done independently, having different install targets depending on the different build targets (or no install target at all and doing the work in binary-*), would be the way to go. But in this package the only difference in having build-arch and build-indep is increasing the number of packages supporting those target thus increasing the chances they will actually be used in some future and make building other packages faster. I didn't understand that part of the policy (ch 4.9) very well: Should I make build-arch return with exit status 2 or can I just leave it as an empty target? Just an empty target is good. After all, all what you had to build for arch dependent packages was done by doing nothing. * Copyright information is incomplete. While copyright information of the build files if often forgotten (but better should not be), Those are still missing. (i.e. files like missing, install-sh, ...) at least automake-idl seems to contain at least a partial fork auf automake (as opposed to be generated or copied by automake). Even if you do not install that stuff, it's copyrights and licenses should be listed. For autoconf-orb I agree, the information is missing. I don't want to add comments assigning the copyright information to upstream without talking to them, first. On that note: would it even be Ok for me to add such copyright notices to the files, copying information from the COPYING file? Or is this not valid? I think it is best to ask the author. COPYING only contains the whole license and neigther a copyright notice nor a license statement. Perhaps the COPYING file was just copied there by automake and the author did not think about it at all. After all, even FSF distributes their m4 files under a very permissive license: (from /usr/share/aclocal-1.10/init.m4 on my system) # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, # 2005, 2006 Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. But with automake-idl, where copyright information is present, I made a mistake. That package is GPL2, not GPL3 and the copyright holder is the FSF, not the upstream author of autoconf-orb! Sorry about that, it has been corrected in the newest upload. Unless Vladimir Panov assigned copyright to FSF, he still is copyright holder for at least his modifications. Some more I just saw: The dependencie of autoconf-orb look very strange. The dependency on automake-idl looks like it should be an Suggests at most. The version dependency on autoconf I do not understand. After all, even with this dependency, you cannot be sure an older autoconf is not used with those files, and none of them seems to include an AC_PREREQ to actually tell to need a newer version. So where does this version come from? Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnome-inm-forecast
On Mon, Jun 02, 2008 at 08:14:32AM +0200, Vincent Bernat wrote: Hi Vincent OoO En cette nuit striée d'éclairs du lundi 02 juin 2008, vers 02:00, Gustavo Iñiguez Goya [EMAIL PROTECTED] disait: Dear mentors, I am looking for a sponsor for my package gnome-inm-forecast. * Package name: gnome-inm-forecast Version : 0.6.1 Upstream Author : Gustavo Iñiguez Goya [EMAIL PROTECTED] * URL : http://kutxa.homeunix.org/trac/gnome-inm-forecast * License : GPL Section : gnome It builds these binary packages: gnome-inm-forecast - Spanish weather forecast applet for the GNOME desktop Hi Gustavo! What is the difference with the forecast applet shipped in Gnome? Firstly Vincent, sorry for answer you directly instead of doing it to the list. The main difference is that this applet extracts the information from the Spanish Meteorological Agency, which supplies a more accurate weather forecast for Spain, and by city. Besides this important difference, AEMET (http://www.aemet.es) supplies some kind of reports (avalanche/snowfalls) for the pyrenees which no others websites do it (except meteofrance). The GNOME's one, does not provide a weather forecast report of any kind for Spain (if I'm not wrong). Only the current weather condition for the selected city. Regards, Gustavo. -- panic(huh?\n); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing init.d scripts
OoO Pendant le repas du lundi 02 juin 2008, vers 19:41, David Paleino [EMAIL PROTECTED] disait: Hi all, I'm packaging dkms [1] (ITP #481590), and it needs to install a script into init.d. I have a ./debian/dkms_autoinstaller.init, which should be placed in /etc/init.d/ by dh_installinit. And it does its job. But dh_installinit manpage also states: It also automatically generates the postinst and postrm and prerm commands needed to set up the symlinks in /etc/rc*.d/ and to start and stop the init scripts. This is not actually true, at least in my case. And this is why I'm asking for help here. After a debuild, lintian warns: W: dkms: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/dkms_autoinstaller N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. This is usually a bug, unless you omit the links N: intentionally for some reason or create the links some other way. N: I supposed dh_installinit did that! So, I tried grabbing clean postinst and postrm from /usr/share/debhelper/dh_make/debian/, and left only the #DEBHELPER#. This didn't work either. Look at debian/X/DEBIAN/postinst after dpkg-buildpackage to see if something is missing. -- I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV -+- Bart Simpson on chalkboard in episode 3G02 pgpZEVQmCadCZ.pgp Description: PGP signature
RFS: mxallowd
Dear mentors, I am looking for a sponsor for my package mxallowd. * Package name: mxallowd Version : 1.5 Upstream Author : Michael Stapelberg [EMAIL PROTECTED] * URL : http://michael.stapelberg.de/mxallowd * License : GPLv2 Section : net It builds these binary packages: mxallowd - Anti-Spam-Daemon using nolisting/iptables The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mxallowd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mxallowd/mxallowd_1.5.dsc I would be glad if someone uploaded this package for me. Kind regards Michael Stapelberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Installing init.d scripts
Hi all, I'm packaging dkms [1] (ITP #481590), and it needs to install a script into init.d. I have a ./debian/dkms_autoinstaller.init, which should be placed in /etc/init.d/ by dh_installinit. And it does its job. But dh_installinit manpage also states: It also automatically generates the postinst and postrm and prerm commands needed to set up the symlinks in /etc/rc*.d/ and to start and stop the init scripts. This is not actually true, at least in my case. And this is why I'm asking for help here. After a debuild, lintian warns: W: dkms: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/dkms_autoinstaller N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. This is usually a bug, unless you omit the links N: intentionally for some reason or create the links some other way. N: I supposed dh_installinit did that! So, I tried grabbing clean postinst and postrm from /usr/share/debhelper/dh_make/debian/, and left only the #DEBHELPER#. This didn't work either. After this, I tried calling /usr/sbin/update-rc.d dkms_autoinstaller defaults in the configure case of the postinst, and: /usr/sbin/update-rc.d -f dkms_autoinstaller remove in postrm. But lintian is still warning about that. Oh, well, lintian throwed an error as well: E: dkms: postrm-contains-additional-updaterc.d-calls /etc/init.d/dkms_autoinstaller N: N: The postrm de-registers an /etc/init.d script which has not been N: registered in the postinst script before. N: On my system: # find /etc/ -name *dkms_autoinstaller* # LANG=C dpkg -i dkms_2.0.19-1_all.deb Selecting previously deselected package dkms. (Reading database ... 16 files and directories currently installed.) Unpacking dkms (from dkms_2.0.19-1_all.deb) ... Setting up dkms (2.0.19-1) ... Adding system startup for /etc/init.d/dkms_autoinstaller ... /etc/rc0.d/K20dkms_autoinstaller - ../init.d/dkms_autoinstaller /etc/rc1.d/K20dkms_autoinstaller - ../init.d/dkms_autoinstaller /etc/rc6.d/K20dkms_autoinstaller - ../init.d/dkms_autoinstaller /etc/rc3.d/S20dkms_autoinstaller - ../init.d/dkms_autoinstaller /etc/rc4.d/S20dkms_autoinstaller - ../init.d/dkms_autoinstaller /etc/rc5.d/S20dkms_autoinstaller - ../init.d/dkms_autoinstaller Processing triggers for man-db ... # find /etc/ -name *dkms_autoinstaller* /etc/rc0.d/K20dkms_autoinstaller /etc/rc1.d/K20dkms_autoinstaller /etc/rc3.d/S20dkms_autoinstaller /etc/rc4.d/S20dkms_autoinstaller /etc/rc5.d/S20dkms_autoinstaller /etc/rc6.d/K20dkms_autoinstaller /etc/init.d/dkms_autoinstaller # LANG=C apt-get --purge remove dkms Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: dkms* 0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded. After this operation, 266kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 200034 files and directories currently installed.) Removing dkms ... 0 Removing any system startup links for /etc/init.d/dkms_autoinstaller ... /etc/rc0.d/K20dkms_autoinstaller /etc/rc1.d/K20dkms_autoinstaller /etc/rc3.d/S20dkms_autoinstaller /etc/rc4.d/S20dkms_autoinstaller /etc/rc5.d/S20dkms_autoinstaller /etc/rc6.d/K20dkms_autoinstaller Purging configuration files for dkms ... Removing any system startup links for /etc/init.d/dkms_autoinstaller ... Processing triggers for man-db ... # That seems working. Is lintian broken? Or am I missing something really obvious? Kindly, David [1] http://linux.dell.com/projects.shtml#dkms -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Installing init.d scripts
On Mon, 02 Jun 2008 19:54:47 +0200, Vincent Bernat wrote: OoO Pendant le repas du lundi 02 juin 2008, vers 19:41, David Paleino [EMAIL PROTECTED] disait: W: dkms: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/dkms_autoinstaller N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. This is usually a bug, unless you omit the links N: intentionally for some reason or create the links some other way. N: I supposed dh_installinit did that! So, I tried grabbing clean postinst and postrm from /usr/share/debhelper/dh_make/debian/, and left only the #DEBHELPER#. This didn't work either. Look at debian/X/DEBIAN/postinst after dpkg-buildpackage to see if something is missing. Forgot to mention that, sorry (I already did this check before). The postinst in the control directory only contains the manually added update-rc.d call, while in place of #DEBHELPER# I can only see a blank line: $ tail DEBIAN/postinst echo postinst called with unknown argument \`$1' 2 exit 1 ;; esac exit 0 $ -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Installing init.d scripts
OoO Pendant le journal télévisé du lundi 02 juin 2008, vers 20:01, David Paleino [EMAIL PROTECTED] disait: W: dkms: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/dkms_autoinstaller N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. This is usually a bug, unless you omit the links N: intentionally for some reason or create the links some other way. N: I supposed dh_installinit did that! So, I tried grabbing clean postinst and postrm from /usr/share/debhelper/dh_make/debian/, and left only the #DEBHELPER#. This didn't work either. Look at debian/X/DEBIAN/postinst after dpkg-buildpackage to see if something is missing. Forgot to mention that, sorry (I already did this check before). The postinst in the control directory only contains the manually added update-rc.d call, while in place of #DEBHELPER# I can only see a blank line: If you rename .init.d to init.d, what happens? Do you use --name parameter of dh_installinit? If not, dh_installinit tries to find init.d or package.init.d. Underscore is not allowed in a package name. -- /* * Hash table gook.. */ 2.4.0-test2 /usr/src/linux/fs/buffer.c pgpo6i5nk1yGP.pgp Description: PGP signature
Re: RFS: libgpiv, gpiv and gpivtools (2nd try)
OoO En cette matinée ensoleillée du lundi 26 mai 2008, vers 09:46, Gerber van der Graaf [EMAIL PROTECTED] disait: Package: libgpiv-0.5.2 Hi Gerber! Your debian/changelog is quite unusual. While this is allowed, it is more usual to have blank line after first line and blank one before last one: libgpiv (0.3.3-1) unstable; urgency=low * Initial Release. Closes: #354150 -- Gerber van der Graaf [EMAIL PROTECTED] Wed, 22 Mar 2006 20:39:27 +0100 debian/conffiles.1 is not needed anymore. Moreover, I think that conffiles.1 is not a valid file at all. Just remove it. Same for rules.1. Your description in debian/control is quite dense. Add blank lines in the long description. Moreover, remove the capital on the first letter of the short description: library for You also might want to provide a -dbg library. Look at dh_strip which is able to most steps for you. In debian/copyright, you should copy paste the complete disclaimer at the top of each file: Libgpiv is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. For example, you forgot to say that this software is licensed under GPLv2 or later. You are using dh_movefiles. This is deprecated. Use dh_install instead. The manual page states how to migrate from dh_movefiles to dh_install. You can shorten a bit debian/rules: + CFLAGS and INSTALL_PROGRAM settings can be removed, this is now done automatically + you can remove the block from shared library versions to latest awk: you don't use those variables You can also update the snippet to update config.sub and config.guess: ifneq $(wildcard /usr/share/misc/config.sub) cp -f /usr/share/misc/config.sub config.sub endif ifneq $(wildcard /usr/share/misc/config.guess) cp -f /usr/share/misc/config.guess config.guess endif Package: gpiv-0.5.2 I will look at it later. -- I WILL NOT DO THE DIRTY BIRD I WILL NOT DO THE DIRTY BIRD I WILL NOT DO THE DIRTY BIRD -+- Bart Simpson on chalkboard in episode AABF08 pgpXba2S0jpqW.pgp Description: PGP signature
Re: Installing init.d scripts
Please don't CC me. On Mon, 02 Jun 2008 20:18:06 +0200, Vincent Bernat wrote: OoO Pendant le journal télévisé du lundi 02 juin 2008, vers 20:01, David Paleino [EMAIL PROTECTED] disait: Forgot to mention that, sorry (I already did this check before). The postinst in the control directory only contains the manually added update-rc.d call, while in place of #DEBHELPER# I can only see a blank line: If you rename .init.d to init.d, what happens? Isn't that *.init/init? From man dh_installinit: If a file named debian/package.init exists, then it is installed into etc/init.d/package in the package build directory, with package replaced by the package name. Do you use --name parameter of dh_installinit? I wasn't using it. Using --name dkms_autoinstaller made it work, thanks! (I tried that before, but was using debian/XXX.init, XXX.init...) If not, dh_installinit tries to find init.d or package.init.d. This seems like a bug in the manpage of dh_installinit? I haven't tried wheter the .d-form works as well... Underscore is not allowed in a package name. Uhm, right. But does dh_installinit depend on the package name? That's a file, not a package -- and in fact works with --name (the package is simply dkms) Thanks, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: gnome-art-ng
OoO La nuit ayant déjà recouvert d'encre ce jour du lundi 26 mai 2008, vers 23:06, Julien Lavergne [EMAIL PROTECTED] disait: I am looking for a sponsor for my package gnome-art-ng. The goal of Gnome-art-ng is to replace gnome-art (non maintained upstream, see http://www.miketech.net/gnome-art/index.php). It provides the same features : - download previews and thumbnails from art.gnome.org for backgrounds, icons, splash etc .. - Install them directly by a simple clic Hi Julien! Did you try to contact current maintainers of gnome-art package? They may be interested to sponsor you. You can also try to seek sponsorship inside Debian Gnome Maintainers group on alioth. This is usually easier than to find a sponsor here. -- Instrument your programs. Measure before making efficiency changes. - The Elements of Programming Style (Kernighan Plauger) pgpZh9b5W6WaI.pgp Description: PGP signature
Re: Installing init.d scripts
OoO Pendant le journal télévisé du lundi 02 juin 2008, vers 20:47, David Paleino [EMAIL PROTECTED] disait: If you rename .init.d to init.d, what happens? Isn't that *.init/init? Yes, my mistake. Underscore is not allowed in a package name. Uhm, right. But does dh_installinit depend on the package name? Yes. I suppose that dh_installinit search for any *.init file but does debhelper magic only if it matches packagename.init. The fact that it installs *.init even for files not matching package name is not documented though. -- I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG -+- Bart Simpson on chalkboard in episode 9F18 pgp12shlDyD4x.pgp Description: PGP signature
Re: RFS: eboard (updated package)
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 27 mai 2008, vers 23:20, Patrik Fimml [EMAIL PROTECTED] disait: I am looking for a sponsor for the new version 1.1.1-1 of the package eboard, the new version 2-2 of the package eboard-extras-pack1 and version 1-1 of the package eboard-extras-pack2. I have requested to adopt these packages, and this has been accepted[1] by the current maintainer. [1] http://lists.debian.org/debian-devel/2008/05/msg01013.html Did you try to request sponsorship from him? eboard - A GTK+ chessboard program Why did you move eboard-addtheme to /usr/bin? This seems to require a lintian override and no real benefit, isn't it? This is a bit odd to have a package depends on xfonts-75dpi. Do you know the rationale behind this dependency? Also, remove the capitalization in the short description a GTK+ chessboard program or even GTK+ chessboard program. Most (all?) files are licensed under GPLv2 or later version while your debian/copyright only states GPLv2. In your debian/rules, you have: build: configure-stamp build-stamp Both dependencies can be run in parallel. This means that configure can happens after build. An alternative could be build: build-stamp build-stamp: configure-stamp You might want to use dh_lintian to install lintian file. Read the manual page to find the correct version of debhelper to use in this case. There is a lintian warning: W: eboard: copyright-without-copyright-notice eboard-extras-pack1 - Additional piece sets and sounds for eboard (pack 1) debian/control and debian/compat disagrees. Moreover, remove the capitalization of the first letter in the short description in debian/control. There is the same problem with parallelisation in debian/rules than for eboard package. You also might want to remove the fact that debian/rules is a sample file. Check some lintian warnings with lintian -viI: I: eboard-extras-pack1 source: build-depends-without-arch-dep eboard W: eboard-extras-pack1: copyright-without-copyright-notice eboard-extras-pack2 - Additional piece sets and sounds for eboard (pack 2) See above. :) -- printk(KERN_WARNING Multi-volume CD somehow got mounted.\n); 2.2.16 /usr/src/linux/fs/isofs/inode.c pgpf2otS0QdiU.pgp Description: PGP signature
RFS: dkms
Dear mentors, I am looking for a sponsor for my package dkms. * Package name: dkms Version : 2.0.19-1 Upstream Author : Dell, Inc. [EMAIL PROTECTED] * URL : http://linux.dell.com/projects.shtml#dkms * License : GPL-2+ Section : admin It builds these binary packages: dkms - Dynamic Kernel Module Support framework DKMS is a framework designed to allow individual kernel modules to be upgraded without changing the whole kernel. It is also very easy to rebuild modules as you upgrade kernels. This is the Ubuntu popcon for this package, it might reveal the number of potential users in Debian as well: #rank name inst vote old recent no-files 3304 dkms 16672 4812 10856 1000 4 The package is lintian (unstable) clean. The upload would close the ITP #481590. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dkms/dkms_2.0.19-1.dsc Regards, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
RFS: macchanger (adopted package)
Dear mentors, I am looking for a sponsor for the new version 1.5.0-2 of macchanger, which I'm adopting. It builds these binary packages: macchanger - utility for manipulating the MAC address of network interfaces Features: . * set specific MAC address of a network interface * set the MAC randomly * set a MAC of another vendor * set another MAC of the same vendor * set a MAC of the same kind (eg: wireless card) * display a vendor MAC list (today, 6200 items) to choose from The package is lintian (unstable) clean. The upload would fix these bugs: 391400, 481102 (ITA) The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/m/macchanger/macchanger_1.5.0-2.dsc I would be glad if someone uploaded this package for me. Kind regards David Paleino -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: eboard (updated package)
Vincent Bernat [EMAIL PROTECTED] writes: This is a bit odd to have a package depends on xfonts-75dpi. Do you know the rationale behind this dependency? It's also a Policy violation. See Policy 11.8.5, first point, last sentence. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dish
Hi Vincent, Thanks for your comments. On Fri, 30 May 2008, Vincent Bernat wrote: Hi Dimitar! Sorry for being picky, but you left configure-stamp target which is useless too since you don't have configure target any more. I was not sure about the configure time-stamp, now the target is removed. This is a matter of taste, but I would put config_examples/* in debian/examples instead of config_examples. I moved the files to debian/examples. Moreover, you should fix all lintian warnings (use lintian -viI on .changes). For manual page, you can either use a patch management system lintian run over _source.changes didn't show me any problems - that's why I missed them since I checked and uploaded only sources. But lintian run over _i386.changes let me see the warnings. In future I'll ckeck all .changes :-) or use this snippet in install target of debian/rules: sed -i 's/\B-/\\-/g' debian/dish/usr/share/man/man1/* Check what this command really does before using it in debian/rules. The snippet is not ok, because it escapes all '-' but help2man actually does most of the escape-job correctly, as I looked exactly at the troubles. Only some in the file seealso (which is simply included and is supposed to be already formated in *roff), and some in the SYNOPSIS section are not escaped. In the Makefile, I pipe now the output from help2man into sed to escape only unescaped '-'. -- I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD -+- Bart Simpson on chalkboard in episode 8F13 Finally, I did some minor changes in the main program and the Makefile. Hence a new upstream release emerged and has been uploded: - dget http://mentors.debian.net/debian/pool/main/d/dish/dish_1.16.2-1.dsc Kind regards, Dimitar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: macchanger (adopted package)
Hi David! On Mon, Jun 2, 2008 at 5:08 PM, David Paleino [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.5.0-2 of macchanger, which I'm adopting. I will look at it. Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dish
OoO En ce début de soirée du lundi 02 juin 2008, vers 21:37, Dimitar Ivanov [EMAIL PROTECTED] disait: Finally, I did some minor changes in the main program and the Makefile. Hence a new upstream release emerged and has been uploded: - dget http://mentors.debian.net/debian/pool/main/d/dish/dish_1.16.2-1.dsc Uploaded. For a future release, you should add a lintian override for this lintian warning: W: dish: spelling-error-in-description mysql MySQL Thanks. -- /* After several hours of tedious analysis, the following hash * function won. Do not mess with it... -DaveM */ 2.2.16 /usr/src/linux/fs/buffer.c pgpZAU1dGmeti.pgp Description: PGP signature
Re: RFS: poco and poco-doc (updated packages) [3rd try]
2008/5/22 Vincent Bernat [EMAIL PROTECTED]: I did not check if it is a requirement, but debug version of library are usually suffixed by -dbg. For example libpocoxml5-dbg. Is there any difference between the debug and non debug versions apart from stripped symbols? If there is no other difference, you might prefer to use dh_strip to generate debug version of your packages. This will install debug symbols in /usr/lib/debug like most dbg packages. d suffix in debug library names is POCO convention, I would like to keep this, as those libraries are not just unstripped version of non d libraries. Also most people uses library name with d suffix when want to link against debug version. In debian/changelog, why did you set urgency=high? You should also acknowledge NMU. Low is OK, I have no explanation for high, so I changed this. NMU is also acknowledged now. Since you are removing non-free stuff from orig tarball, you should either explain in README.Debian-source how to get the dfsg tarball from the orig tarball or add a get-orig-source in debian/rules. README.Debian-source added. Change is tinny. Only one directory contains examples with NDA notice. Those files were removed. You can remove the CFLAGS settings in debian/rules. This is now done by dpkg-buildpackage. Done. Your debian/watch needs some mangling: Newest version on remote site is 1.3.2, local version is 1.3.2+dfsg1 = remote site does not even have current version Look at dmangleversion flag to correct this. Done. There are also a build-dep change. After a small review I decided to replace iODBC with unixODBC. Fixed package: http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.2+dfsg1-1.dsc Regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On 02/06/2008, Krzysztof Burghardt wrote: Since you are removing non-free stuff from orig tarball, you should either explain in README.Debian-source how to get the dfsg tarball from the orig tarball or add a get-orig-source in debian/rules. README.Debian-source added. Change is tinny. Only one directory contains examples with NDA notice. Those files were removed. Last time I checked, debian/copyright was the best place to document this, see devref 6.7.8.2 (although it was previously advised to use README.Debian-source). Mraw, KiBi. pgpsq5RWdospf.pgp Description: PGP signature
Re: RFS: QA Upload: kcemirror - Windows CE remote control tool like VNC
OoO En ce milieu de nuit étoilée du lundi 02 juin 2008, vers 04:05, Barry deFreese [EMAIL PROTECTED] disait: Here is another QA upload that fixes RC bug #482216 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482216. http://mentors.debian.net/debian/pool/main/k/kcemirror/kcemirror_0.1.5-2.dsc If someone has time to review and/or upload I would appreciate it. Hi Barry! I have uploaded your package. I had some minor remarks but prefered to not bother you with another upload since the goal was to fix an RC bug: - dpkg-buildpackage now set CFLAGS and -s option of INSTALL_PROGRAM is the job of dh_strip - there are two lintian warnings -- Terminate input by end-of-file or marker, not by count. - The Elements of Programming Style (Kernighan Plauger) pgpiMJAsLIjjw.pgp Description: PGP signature
Re: RFS: dish
This one time, at band camp, Vincent Bernat said: OoO En ce début de soirée du lundi 02 juin 2008, vers 21:37, Dimitar Ivanov [EMAIL PROTECTED] disait: Finally, I did some minor changes in the main program and the Makefile. Hence a new upstream release emerged and has been uploded: - dget http://mentors.debian.net/debian/pool/main/d/dish/dish_1.16.2-1.dsc Uploaded. For a future release, you should add a lintian override for this lintian warning: W: dish: spelling-error-in-description mysql MySQL Or, instead of hiding the warning, just fix the spelling? If it's a bug in lintian, report that instead. Overrides shouldn't be used lightly and encouraging one for a capitalization issue seems like poor judgement, IMHO. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: QA Upload: kcemirror - Windows CE remote control tool like VNC
Vincent Bernat wrote: OoO En ce milieu de nuit étoilée du lundi 02 juin 2008, vers 04:05, Barry deFreese [EMAIL PROTECTED] disait: Here is another QA upload that fixes RC bug #482216 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482216. http://mentors.debian.net/debian/pool/main/k/kcemirror/kcemirror_0.1.5-2.dsc If someone has time to review and/or upload I would appreciate it. Hi Barry! I have uploaded your package. I had some minor remarks but prefered to not bother you with another upload since the goal was to fix an RC bug: - dpkg-buildpackage now set CFLAGS and -s option of INSTALL_PROGRAM is the job of dh_strip - there are two lintian warnings Vincent, Looks like someone beat us to it, but thanks! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: automake-idl
Bernhard R. Link schrieb: * Olaf Mandel [EMAIL PROTECTED] [080602 03:40]: -Snipp- * Copyright information is incomplete. While copyright information of the build files if often forgotten (but better should not be), Those are still missing. (i.e. files like missing, install-sh, ...) Hello, as far as I can see, all files in automake-idl contain copyright information. Especially since missing, install-sh etc are not part of automake-idl. It only contains the main executable and these support files: depout2-idl.m4 idldep idlfix idl.am. All of those have a copyright header in the file. [Copyright notices] For autoconf-orb I agree, the information is missing. I don't want to add comments assigning the copyright information to upstream without talking to them, first. I added copyright / license headers to all files after talking to Vladimir Panov (the original author). He prefers a GPL header over the complete public domain header that the FSF uses for their files. at least automake-idl seems to contain at least a partial fork auf automake (as opposed to be generated or copied by automake). Even if you do not install that stuff, it's copyrights and licenses should be listed. -Snipp- Unless Vladimir Panov assigned copyright to FSF, he still is copyright holder for at least his modifications. Vladimir told me he intentionally left the copyright with the FSF for the patched files and assigned it to the FSF for the files he created from scratch. Is it good enough to just be the original author and claim the copyright lies with someone else (like done here) or would a more formal process be needed (IANAL)? Some more I just saw: The dependencie of autoconf-orb look very strange. The dependency on automake-idl looks like it should be an Suggests at most. Actually, I think the Depends is right. While a configure file that does not use the AI_* macros still works with Makefiles generated by the normal automake, a configure file that uses these macros relies on automake-idl being of that-and-that version without (at the moment) encoding this in the Makefile. For example, a new version of autoconf-orb could create configure scripts that do not work on Makefiles generated by the old versions of automake-idl. As the Suggests header does not enforce keeping the version updated (I think), it should be Depends. Or what happens in this case: Package: foo (0.0.1); Suggests: bar (= 0.0.1) foo, bar both in the same Distribution apt-get install foo bar Package: foo (0.0.2); Suggests: bar (= 0.0.2) only foo (0.0.2) in the Distribution, bar (0.0.2) is delayed apt-get dist-update I don't think that this would do the correct thing of holding back foo until bar (0.0.2) becomes available (untested! Am I right?). Would a combination of Suggests and Conflicts be appropriate for this situation? I think just a Depends is better, though. The version dependency on autoconf I do not understand. After all, even with this dependency, you cannot be sure an older autoconf is not used with those files, and none of them seems to include an AC_PREREQ to actually tell to need a newer version. So where does this version come from? I just copied the version I had on my machine in there, which was too harsh. The package simply depends on autoconf without a version, now. New versions uploaded to mentors.debian.net. Here are the differences: * autoconf-orb: ** All files now contain copyright notices ** Relaxed dependency on autoconf * automake-idl: ** usr/bin/automake-idl was using the wrong default for perllibdir Best regards, Olaf -- Olaf Mandel eMail [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
gts library / version numbering watch file
Dear mentors, After finishing the work on man pages, I uploaded my updated package to mentors. I tested this with gerris and k3d packages (both of them uses gts), I used binaries packages and also compiled them from sources using this new version of library. I seems to be working ok. I will try to contact k3d maintainer for some testing too. As I said in a previous email, upstream is using snapshots releases. So, library still says 0.7.6, but sources has changed a lot from 0.7.6 tarball... as suggested, I tried to contact upstream but not reply is received yet. For this package, I used gts-0.7.6.20080513, where 2008-05-13 is the date of the snapshot. Is this ok? or should I package it as gts-snapshot like used by upstream? In both cases, I don't know how can I create a debian/watch for this situation. Upstream tarball is named gts-snapshot.tar.gz. No version information is given in filename. Any suggestion? Thanks a lot. Ruben Molina. signature.asc Description: Esta parte del mensaje está firmada digitalmente
