RFS: wepbuster
Dear mentors, I am looking for a sponsor for my package wepbuster. * Package name: wepbuster Version : 1.0~beta0.7-1 Upstream Author : Mark Jayson Alvarez unknown * URL : http://code.google.com/p/wepbuster/ * License : BSD Section : admin It builds these binary packages: wepbuster - small utility to aid in conducting Wireless Security Assessment The package appears to be lintian clean. The upload would fix these bugs: 550387 My motivation for maintaining this package is: I ocassionally use it to check APs at the office|home. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/wepbuster - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/wepbuster/wepbuster_1.0~beta0.7-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: Debian changelog vs upstream changelog
On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote: Rather, it would be good to have a facility similar to the way the Debian changelog is currently available: have the upstream changelog published in a predictable location by package name. Where the changelog is already part of the source package and has a sensible name, and the package calls dh_installchangelogs, it's already installed as /usr/share/doc/*/changelog and the Debian changelog as changelog.Debian. The only unpredictable part of that is whether upstream enclosed one in the first place. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian changelog vs upstream changelog
On Fri, Nov 27, 2009 at 4:55 PM, Jonathan Wiltshire deb...@jwiltshire.org.uk wrote: Where the changelog is already part of the source package and has a sensible name, and the package calls dh_installchangelogs, it's already installed as /usr/share/doc/*/changelog and the Debian changelog as changelog.Debian. The only unpredictable part of that is whether upstream enclosed one in the first place. It is also unpredictable that upstream put a ChangeLog or a NEWS file (or the change info in README or elsewhere) in the ChangeLog and what the Debian maintainer did with the situation. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian changelog vs upstream changelog
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote: Rather, it would be good to have a facility similar to the way the Debian changelog is currently available: have the upstream changelog published in a predictable location by package name. Where the changelog is already part of the source package and has a sensible name, and the package calls dh_installchangelogs, it's already installed as /usr/share/doc/*/changelog and the Debian changelog as changelog.Debian. The only unpredictable part of that is whether upstream enclosed one in the first place. This misses the point: that's not available using standard tools (e.g. pressinc ‘C’ in aptitude's browser) *before* making the decision whether to install a new upstream version. Since that feature is currently absent, I advocate Debian's changelog entry to summarise user-visible changes in the “New upstream version” entry, so that the prospective user of that version can find what changed in a predictable location before downloading the package. -- \ “If you can't beat them, arrange to have them beaten.” —George | `\Carlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian changelog vs upstream changelog
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote: Rather, it would be good to have a facility similar to the way the Debian changelog is currently available: have the upstream changelog published in a predictable location by package name. Where the changelog is already part of the source package and has a sensible name, and the package calls dh_installchangelogs, it's already installed as /usr/share/doc/*/changelog and the Debian changelog as changelog.Debian. The only unpredictable part of that is whether upstream enclosed one in the first place. In order for apt-listchanges to do its nice summary, though, you need two features: a consistent location *and* a consistent format, so that you can show only the changes from the currently installed version. The second part is rather hard for arbitrary upstream changelogs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Embedding one .deb inside another
Le 26 nov. 09 à 21:59, Joe Smith a écrit : Hi, I'm having an issue with distributing a .deb package that has a dependency on another .deb package that might not be in an available repository (or the target may not have a network connection at the time of installation). What I'd like to do, ideally, is embed the dependency inside the parent package. That way, in the preinst script, it could just install it's dependency. However, the problem is that when installing the parent package, it locks the dpkg system so when it, in the preinst step, goes to run dpkg -i on the embedded .deb file, it can't get a lock and fails. I believe that one way would be for the content on the depended-upon package to be in the depending package. The depending package should then Provides: the depended-upon package. This is still an ugly solution. Unless in a very controlled environment, that will eventually cause problems. T. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: roxterm (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.16.1-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The upload would fix these bugs: 557049 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Tony Houghton -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: RFS: bluemindo (updated package)
2009/11/27 Thibaut GIRKA t...@sitedethib.com: Your package drops this symlink with out any mention of that in the changelog: lrwxrwxrwx root/root /usr/share/bluemindo/COPYING - ../common-licenses/GPL-3 Did you mean to do that? Let me check... Yeah, the program does not use it anymore. Ok, package uploaded. You might want to file a bug on ftp.debian.org about the priority override disparity: http://packages.qa.debian.org/b/bluemindo.html http://lists.debian.org/debian-devel-announce/2009/08/msg1.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
Dear mentors, Hi, I am looking for a sponsor for the new version 1.16.1-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The upload would fix these bugs: 557049 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.1-1.dsc I would be glad if someone uploaded this package for me. Package looks good and 557049 seems to be addressed as well, at least works for me;-). JFYI I just run into some leftovers in the roxterm(1) and roxterm- config(1) manpages -- they both contain [FIXME: manual] and [FIXME: source], and these are also shown in the man browser too. This is not a huge problem per se, and the package in sid also has it, but I think you might want to know about it and address it further. I use that package and I'm willing to upload. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: g3dviewer
Dear mentors, I am looking for a sponsor for my package g3dviewer. * Package name: g3dviewer Version : 0.2.99.5~svn130-1 Upstream Author : Markus Dahms m...@automagically.de * URL : http://automagically.de/g3dviewer/ * License : GPL-2+ Section : graphics It builds these binary packages: g3dviewer - 3D model viewer for GTK+ g3dviewer-dbg - g3dviewer debug symbols package The package appears to be lintian clean. The upload would fix these bugs: 520151 My motivation for maintaining this package is: I am currently the maintainer of the package libg3d[1] and related binary packages. g3dviewer is the actual main application which uses libg3d to read and display many 3d file formats without the need of special editor software. So it is something like a image viewer but for 3d data instead of images. It would make sense to me to maintain both the application and the main library behind the application. I've already tried to get it uploaded in March 2009[1] without any known response. I am Debian maintainer, but Dm-Upload-Allowed is not set at the moment. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/g3dviewer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/g3dviewer/g3dviewer_0.2.99.5~svn130-1.dsc I would be glad if someone uploaded this package for me. Kind regards Sven Eckelmann [1] http://packages.qa.debian.org/libg/libg3d.html [2] http://lists.debian.org/debian-mentors/2009/03/msg00377.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
On Fri, 27 Nov 2009 21:39:25 +0200 George Danchev danc...@spnet.net wrote: Package looks good and 557049 seems to be addressed as well, at least works for me;-). JFYI I just run into some leftovers in the roxterm(1) and roxterm- config(1) manpages -- they both contain [FIXME: manual] and [FIXME: source], and these are also shown in the man browser too. This is not a huge problem per se, and the package in sid also has it, but I think you might want to know about it and address it further. I use that package and I'm willing to upload. Thanks. I've added the missing elements to the DocBook files the man pages are generated from, I hope they're OK now. This was an upstream change so I've uploaded a new version: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.2-1.dsc -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Buildd failed: C compiler cannot create executables
Felipe Sateler fsate...@gmail.com (26/11/2009): Your package build-depends on ccache, and it actively enforces it in the debian/rules file. Why is that? I would be willing to bet money that the problem is that buildd's have no (writable) home directory, so ccache fails. Drop the ccache stuff, or if it _absolutely_ necessary, setup a bogus $HOME so that ccache can work in the buildds. I shall collect your money. Next time, check the facts. Mraw, KiBi. signature.asc Description: Digital signature
Re: Buildd failed: C compiler cannot create executables
Joachim Wiedorn ad_deb...@joonet.de (27/11/2009): thanks for this informations! Nice to see you noticed the FTBFS yourself. I opened a bug anyway (before opening my =debian-mentors/ folder). :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Can /usr/share/doc/pkg be deleted on upgrade ?
Hi all: On Thursday 26 November 2009 15:00:18 Lucas B. Cohen wrote: Thibaut Paumard wrote: Le 26 nov. 09 à 13:38, Lucas B. Cohen a écrit : Esteemed Debian mentors, Is it considered acceptable for a package to blindly delete, then recreate its entire directory under /usr/share/doc upon installation or upgrade ? [...] In worse-case scenarios, these could be illogically interpreted as explicit permission for a package to rule unilateraly on its doc directory. It's not illogical, I really think no other package should ever put anything in another package's /usr/doc/share/pkg. On the other hand, I think it's best to keep the content of /usr/share/doc/pkg static as much as possible. Thank you Thibaut. I really was thinking more about a human who would have uncautiously stored some personal documentation in there. Installing a new Debian release and finding out your personal notes have been rm'd should IMHO not be a risk to the user, hower small. Not personal but sysadmin related. When I want to find information about a given package I go to /usr/share/doc/pkg so I find reasonable that the local sysadmin would add notes about the package right there if needed. In fact I never did that but I certainly would be surprised if I find my notes vapourished if I did. After all, even on a package unistall, customized data under /etc is preserved (that's expected by the way Debian manages config files) but files under /var/log or /var/lib are preserved too, so why one should expect that those under /usr/share/doc won't? A package should take the count on exactly what files add and remove exactly those prior to remove any directory which will only happen if such directory is empty so if I add a file it will be preserved. Less surprise path. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: linux-any arch
Benoit Mortier benoit.mort...@opensides.be (21/11/2009): So my question is can we use linux-any today or do we have to fix the problem an other way ? Keep “Architecture: any” for now, possibly FTBFS very early when not on a Linux architecture (you could use a check on DEB_HOST_ARCH_OS in debian/rules), and get your package added to P-a-s[1]. 1. http://wiki.debian.org/PackagesArchSpecific Mraw, KiBi. signature.asc Description: Digital signature
Re: Buildd failed: C compiler cannot create executables
On Sat, 2009-11-28 at 03:17 +0100, Cyril Brulebois wrote: Felipe Sateler fsate...@gmail.com (26/11/2009): Your package build-depends on ccache, and it actively enforces it in the debian/rules file. Why is that? I would be willing to bet money that the problem is that buildd's have no (writable) home directory, so ccache fails. Drop the ccache stuff, or if it _absolutely_ necessary, setup a bogus $HOME so that ccache can work in the buildds. I shall collect your money. Next time, check the facts. Which would be...? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
On Fri, 27 Nov 2009 21:39:25 +0200 George Danchev danc...@spnet.net wrote: Package looks good and 557049 seems to be addressed as well, at least works for me;-). JFYI I just run into some leftovers in the roxterm(1) and roxterm- config(1) manpages -- they both contain [FIXME: manual] and [FIXME: source], and these are also shown in the man browser too. This is not a huge problem per se, and the package in sid also has it, but I think you might want to know about it and address it further. I use that package and I'm willing to upload. Thanks. I've added the missing elements to the DocBook files the man pages are generated from, I hope they're OK now. This was an upstream change so I've uploaded a new version: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.2-1.dsc Good. It turns out that yesterday I had installed autotools-dev by accident in my supposed to be clean chroot, so I failed to spot the following failure (and manage to complete the whole check cycle including install/deinstall/running). checking whether i486-linux-gnu-gcc and cc understand -c and -o together... yes configure: error: cannot run /bin/sh ./config.sub make: *** [config.status] Error 127 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Adding autotools-dev back to build-dependencies fixes it, however I wonder what were your considerations to remove it in the first place from there? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can /usr/share/doc/pkg be deleted on upgrade ?
Jesús M. Navarro jesus.nava...@undominio.net writes: Not personal but sysadmin related. When I want to find information about a given package I go to /usr/share/doc/pkg so I find reasonable that the local sysadmin would add notes about the package right there if needed. No, I don't think that's reasonable. The ‘/usr’ hierarchy (with the important exception of ‘/usr/local’) should be considered entirely the province of the package management system; any files there can appear or disappear as dictated by the packages. The sysadmin's site-local files should be going under ‘/usr/local’, which *is* out of bounds for the package manager. Less surprise path. That's the benefit of following standards like the FHS: there are places like ‘/usr’ that can be managed entirely by the package manager. Anyone surprised by that isn't following established convention. -- \ “The best ad-libs are rehearsed.” —Graham Kennedy | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
