Re: ITR: wicrawl
On Wed, 02 Jan 2008 23:25:18 + David Newgas <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-02 at 13:14 +, Neil Williams wrote: > > On Wed, 02 Jan 2008 12:46:11 + > > David Newgas <[EMAIL PROTECTED]> wrote: > > > > Umm, I meant programming language: C, C++, Python, Perl, etc. > > Hehe. The program itself is Perl, but it has plugins written from C, > perl and python. OK, thanks. > > > Wicrawl is a simple wi-fi (802.11x) Access Point auditor with a simple > > > and flexible plugin architecture. The plugins allow us to find out > > > useful information about an AP so we don’t have to manually check each > > > access point. > > > > OK, so what is the advantage over existing methods of doing this, like > > wifi-radar and simple iwconfig commands? > > > > Perhaps the description needs expanding ... the plugins handle things > like wep cracking, wpa bruteforcing, bypassing of payment-required > access points... > It's not designed to handle connecting to networks, more is a user > friendly way to test their security. Sounds like it would be good to expand on the 'auditor' element in the short description to include the role of testing security. > That would be fantastic. Only one portion of it (the "apwebcrack" > plugin) is written in python, so I don't know if you still feel like it. Yes, I'm happy with that. I'll post a more detailed review tonight. > > http://people.debian.org/~codehelp/#lang > > Having read through the rest of this doc, I also noticed I missed the > Homepage: field. I changed this, and others things (all documented in > changelog) As per your suggested course of action, I uploading it to > mentors as 0.4a-2. Thanks. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp0SRKdwiyWv.pgp Description: PGP signature
RFS: scim-array (ITP: #452867)
Dear mentors, I am looking for a sponsor for my package "scim-array". ITP: #452867 * Package name: scim-array Version : 0.0.2-1 Upstream Author : Yu-Chun Wang <[EMAIL PROTECTED]> * URL : http://scimarray.openfoundry.org/index_en.html * License : GPL Section : utils It builds this binary package: scim-array - an Array 30 input method engine for scim The package is lintian clean. The package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/s/scim-array/scim-array_0.0.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: gcin (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3.7.1-1 of my package "gcin". It closes bug #419366, #420504, #436914. It builds these binary packages: gcin - a GTK+ based input method platform for Chinese users gcin-qt3-immodule - a QT input method module with gcin as backend It can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/g/gcin/gcin_1.3.7.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: gcin 1.3.7.1-1 (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3.7.1-1 of my package "gcin". It closes bug #419366, #420504, #436914. It builds these binary packages: gcin - a GTK+ based input method platform for Chinese users gcin-qt3-immodule - a QT input method module with gcin as backend It can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/g/gcin/gcin_1.3.7.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: poco (updated package) [2nd try]
Dear mentors, I am looking for a sponsor for the new version 1.2.9-3 of my package "poco". It builds these binary packages: libpoco-dev - Development files for POCO - The C++ Portable Components libpoco2 - POCO - The C++ Portable Components The package appears to be lintian clean. The upload would fix these bugs: 457356 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/poco - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/poco/poco_1.2.9-3.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt <[EMAIL PROTECTED]> http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: vttest - test compatibility of terminals
Dear mentors, I am looking for a sponsor for my package "vttest". The upload would close ITP: #254938 * Package name: vttest Version : 2.7+20071216-1 Upstream Author : Thomas E. Dickey <[EMAIL PROTECTED]> * URL : http://invisible-island.net/vttest/ * License : BSD style, DFSG compatible Section : utils It builds a binary package: vttest - a program to test the compatibility of terminals The package is lintian clean. The package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/v/vttest/vttest_2.7+20071216-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Il giorno Wed, 2 Jan 2008 12:02:58 +0100
David Paleino <[EMAIL PROTECTED]> ha scritto:
> Please don't upload it yet. I've just found out a minor issue during build:
> after svn-buildpackage the sources are left modified. Looking at it right now.
Ok, I can't solve this, thus asking for help.
Upstream's tarball provides a file, src/GNOME_GThumb.h, which is dynamically
generated during the build. Now, it happens that this file, at the end of the
build, is different from the provided one, and $(MAKE) distclean deletes it.
This gives a tarball different from the original one, thus having unmatching
md5sums.
What I've done is:
1) patching the Makefile.{am,in} to make that file stay there after distclean;
2) patching the cited file to "prevent" modifications during the build (it's
just a line removed), so that when the "unpatch" rule does its job, it goes
back to the original file.
These actions did have catastrofic effects: the build fails, looking for a
non-existant file, which is named after a Makefile rule. I can't understand why
make is looking for that file; it is not referenced anywhere, only in that rule
(it's something like "gthumb_sources_idl_stamp"). This is probably due to the
fact that the removed line is:
#line 14 "/usr/share/idl/bonobo-2.0/Bonobo.idl"
Without those patches, it builds just fine, but this is what happens when the
build finishes:
$ svn-buildpackage ...
...
$ svn status
M src/GNOME_GThumb.h
$
This isn't, obviously, optimal: I'd expect a FTBFS if this package gets
uploaded, and I wouldn't know how to fix it, since I'm not able right now.
Any help? :)
David
--
. ''`. Debian maintainer | http://snipurl.com/qa_page
: :' : Linuxer #334216 | http://www.hanskalabs.net/
`. `'`GPG: 1392B174 | http://www.debianizzati.org/
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature
Re: RFS: vttest - test compatibility of terminals
Hi Wen, * Wen-Yen Chuang <[EMAIL PROTECTED]> [2008-01-03 17:53]: [...] > It builds a binary package: > vttest - a program to test the compatibility of terminals Compatible with what? Please fix the description. From the website: "In conformance of the good old hacker traditions, the only documentation of this program is the source code itself. To understand it, you also need a copy of the original VT100 manual from DEC." I hope you documented this package well enough so people would not to get the source package + a VT100 manual?! :) Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpk4MBgvQ97L.pgp Description: PGP signature
Re: RFS: gthumb (updated and adopted package)
Hi David, Le jeudi 03 janvier 2008 à 19:22 +0100, David Paleino a écrit : [...] > .. > $ svn status > M src/GNOME_GThumb.h > $ > > This isn't, obviously, optimal: I'd expect a FTBFS if this package > gets > uploaded, and I wouldn't know how to fix it, since I'm not able right > now. > Just a suggestion: why not copy the original file while building, and move the copy back to its original location in the clean rule? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Il giorno Thu, 03 Jan 2008 19:28:33 +0100 Julien Valroff <[EMAIL PROTECTED]> ha scritto: > Hi David, Hi Julien, > Le jeudi 03 janvier 2008 à 19:22 +0100, David Paleino a écrit : > [...] > > .. > > $ svn status > > M src/GNOME_GThumb.h > > $ > > > > This isn't, obviously, optimal: I'd expect a FTBFS if this package > > gets uploaded, and I wouldn't know how to fix it, since I'm not able right > > now. > > Just a suggestion: why not copy the original file while building, and > move the copy back to its original location in the clean rule? Uhm. This seems a "ugly hack" to me, but might work :) (/me stupid for not thinking before!) Let me try, I'll be here (I hope) in ~5mins (build time ;)) David -- . ''`. Debian maintainer | http://snipurl.com/qa_page : :' : Linuxer #334216 | http://www.hanskalabs.net/ `. `'`GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: vttest - test compatibility of terminals
Nico Golde wrote: It builds a binary package: vttest - a program to test the compatibility of terminals Compatible with what? Please fix the description. = Its long description: This is a program to test the compatibility (or to demonstrate the non-compatibility) of so-called "VT100-compatible" terminals. In conformance of the good old hacker traditions, the only documentation of this program is the source code itself. To understand it, you also need a copy of the original VT100 manual from DEC. . Additional tests (past version 1.7) are provided for analysis of vt220, vt420 terminals, as well as variants of xterm. = I have no idea how to write all this into a short description. I think it is too long for "a program to test the compatibility of terminals for VT100, VT220, and VT420". Any good ideas? Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: keynav (ITP: #431634)
Dear mentors, I am looking for a sponsor for my package "keynav". The upload would fix ITP: #431634 * Package name: keynav Version : 20071031-1 Upstream Author : Jordan Sissel <[EMAIL PROTECTED]> * URL : http://www.semicomplete.com/blog/projects/keynav/ * License : BSD style, DFSG compatible Section : utils It builds the binary package: keynav - uses keyboard as a fast mouse cursor mover The package is lintian clean. The package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/k/keynav/keynav_20071031-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wen-Yen Chuang (caleb) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vttest - test compatibility of terminals
Hi Wen, * Wen-Yen Chuang <[EMAIL PROTECTED]> [2008-01-03 20:31]: > Nico Golde wrote: > >>It builds a binary package: > >>vttest - a program to test the compatibility of terminals > >Compatible with what? Please fix the description. > > = > Its long description: > This is a program to test the compatibility (or to demonstrate the > non-compatibility) of so-called "VT100-compatible" terminals. In conformance > of > the good old hacker traditions, the only documentation of this program is the > source code itself. To understand it, you also need a copy of the original > VT100 manual from DEC. > . > Additional tests (past version 1.7) are provided for analysis of vt220, vt420 > terminals, as well as variants of xterm. > = > > I have no idea how to write all this into a short description. What about - tests VT100 compatibility of terminalsa? > I think it is too long for "a program to test the compatibility of terminals > for VT100, VT220, and VT420". It also sucks because you just copied it from the Website ;) > Any good ideas? Please remove the part about the documentation from the description and write some documentation. Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp0xieu9s8S3.pgp Description: PGP signature
Re: RFS: gthumb (updated and adopted package)
Hi Ove, (please don't CC me, I'm subscribed to the list) Il giorno Thu, 03 Jan 2008 22:27:55 +0100 Ove Kaaven <[EMAIL PROTECTED]> ha scritto: > David Paleino skrev: > > > Upstream's tarball provides a file, src/GNOME_GThumb.h, which is dynamically > > generated during the build. Now, it happens that this file, at the end of > > the build, is different from the provided one, and $(MAKE) distclean > > deletes it. > > Does it *need* to exist before you start the build, or is it a > completely autogenerated file? If the latter, you shouldn't have to do > anything at all. Let distclean wipe it, it'll result in a clean .diff.gz. It seems like is not needed: $ svn rm src/GNOME_GThumb.h D src/GNOME_GThumb.h $ svn status M debian/patches/series M debian/rules D src/GNOME_GThumb.h $ svn-buildpackage ... ... build command was successful; binaries are in /deb/rep/build-area/. The changes file is: /deb/rep/build-area/gthumb_2.10.8-1_i386.changes Binary packages: /deb/rep/build-area/gthumb_2.10.8-1_i386.deb /deb/rep/build-area/gthumb-data_2.10.8-1_all.deb rm -rf /deb/rep/build-area/gthumb-2.10.8 $ svn status M debian/patches/series M debian/rules D src/GNOME_GThumb.h $ but... read the following. > > This gives a tarball different from the original one, thus having unmatching > > md5sums. > > If it's a non-native package, the orig tarball doesn't change. If you're > making a new tarball after building, you're doing something wrong. > Pretty much any attempt to create the exact same tarball more than once > is doomed to fail, if only because the timestamp will be different. I'm not recreating the tarball. The first times I was making packages, my sponsors told me that the result of "debuild clean" (or fakeroot debian/rules clean) had to be the same as the original tarball unpacked + debian/. Is this wrong? This is the real question: upstream provides that file, while at the end of debian/rules clean I simply delete it, thus having different "tarballs" (in a wider sense) I hope you got my point. Kindly, David -- . ''`. Debian maintainer | http://snipurl.com/qa_page : :' : Linuxer #334216 | http://www.hanskalabs.net/ `. `'`GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: gthumb (updated and adopted package)
David Paleino skrev: Il giorno Wed, 2 Jan 2008 12:02:58 +0100 David Paleino <[EMAIL PROTECTED]> ha scritto: Please don't upload it yet. I've just found out a minor issue during build: after svn-buildpackage the sources are left modified. Looking at it right now. Ok, I can't solve this, thus asking for help. Upstream's tarball provides a file, src/GNOME_GThumb.h, which is dynamically generated during the build. Now, it happens that this file, at the end of the build, is different from the provided one, and $(MAKE) distclean deletes it. Does it *need* to exist before you start the build, or is it a completely autogenerated file? If the latter, you shouldn't have to do anything at all. Let distclean wipe it, it'll result in a clean .diff.gz. This gives a tarball different from the original one, thus having unmatching md5sums. If it's a non-native package, the orig tarball doesn't change. If you're making a new tarball after building, you're doing something wrong. Pretty much any attempt to create the exact same tarball more than once is doomed to fail, if only because the timestamp will be different. (Just pitching in...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
David Paleino skrev: I'm not recreating the tarball. The first times I was making packages, my sponsors told me that the result of "debuild clean" (or fakeroot debian/rules clean) had to be the same as the original tarball unpacked + debian/. Is this wrong? I'd qualify that somewhat. It's certainly good practice; the idea is that building again never results in something different, and it's good to be clean anyway. However, if doing that is difficult (such as if upstream forgot to run distclean and left cruft in the orig tarball), I think it's also reasonable to follow the following rule (considering dpkg-buildpackage will invoke clean before building): Original tarball + debian diff + debuild clean = debuild + debuild clean or, failing that, at least the fundamental rule: Original tarball + debian diff + debuild + debuild clean = another debuild + debuild clean You should never break this last rule, but the stricter rule you're currently following is not really worth bending over backwards for IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
