Bug#395955: ITP: bioapi -- Framework for biometric-based authentication
Hi, what's the status of this one? Would be nice to have this for my fingerprint reader. pgpCC9pMCxDIe.pgp Description: PGP signature
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hi! Luca Capello wrote: Am I correct? Is tf-tool worth a single package or can I include it in libthinkfinger (as I'd prefer)? I think it's common practice to put the tools in a separate package, and suggest the name thinkfinger-tools instead of tf-tool, since it's easier for the user to identify what the package is for, and since other tools may be added in the future. [2] I still have a problem, because e.g. PAM module for the SGS Thomson Microelectronics fingerprint reader is longer than the expected 60 characters for the short description. Suggestions welcome! Perhaps you can drop the word Microelectronics from the short description. Thanks for working on this, it will be really nice to have it in Debian. Marcus pgpa8pWtEaV3c.pgp Description: PGP signature
Bug#410061: RFP: nspluginwrapper -- Mozilla plugin to use not native plugins
Package: wnpp Severity: wishlist * Package name: nspluginwrapper Version : 0.9.91.2 Upstream Author : Gwenole Beauchesne * URL : http://gwenole.beauchesne.info/en/projects/nspluginwrapper * License : GPL Programming Lang: C Description : Mozilla plugin to use not native plugins nspluginwrapper is an Open Source compatibility plugin for Netscape 4 (NPAPI) plugins. That is, it enables you to use plugins on platforms they were not built for. For example, you can use the Adobe Flash plugin on Linux/x86_64, NetBSD and FreeBSD platforms. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410016: ITP: Orange-data-mining -- Component-based data mining software
Am Mittwoch, den 07.02.2007, 13:03 +0900 schrieb Charles Plessy: Package name: Orange-data-mining [...] Sounds very interesting. Orange is released under General Public License (GPL) and as such is free if you use it under these terms. We do, however, oblige the users to cite the following white paper together with any other work that accompanied Orange any time you use Orange in your publications: This is a VERY strange addition. I think it is a) incompatible with the GPL, and as it links with at least Qt, this makes Orange indistributable. b) senseless, because if Orange is used in a scientific publication they have to be mentioned anyways - maybe not with this exact paper, but I am confident everybody uses that exact paper if they do not oblige the users, but ask them to use this paper - not another. This of course does not help with other publications like magazins and such. Bye, Alain signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#410016: ITP: Orange-data-mining -- Component-based data mining software
Am Mittwoch, den 07.02.2007, 13:03 +0900 schrieb Charles Plessy: Package name: Orange-data-mining Version : 2007-02-06 Upstream Author : Janez Demsar and Blaz Zupan (see also http://www.ailab.si/orange/acknowledgements.htm) URL : http://www.ailab.si/orange License : GPL Description : Component-based data mining software Be careful with this software. The C4.5 classifier is released under a completely different and restrictive license: This software may not be distributed in any form without permission of the copyright holder. Things like this always make me nervous. I'd check every file for an apropriate copyright notice! Bye, Alain signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#409367: ITP: iceape-locales -- language packs for Iceape
On Fri, Feb 02, 2007 at 02:09:54PM +0100, Robert Luberda wrote: Preliminary package (unfinished, not tested, lacks rebranding) can be found at http://pingu.ii.uj.edu.pl/~robert/iceape-locales/ Nice ... you think you can get the rebranding done soon, so we can push this? - Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409964: marked as done (ITA: mozilla-firefox-adblock)
Your message dated Wed, 07 Feb 2007 15:17:04 + with message-id [EMAIL PROTECTED] and subject line Bug#409964: fixed in mozilla-firefox-adblock 0.5.3.043-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: wnpp Severity: normal As I'm basically MIA these days, I'd like to orphan mozilla-firefox-adblock package: The AdBlock extension adds to IceWeasel browser an ability to filter unwanted objects on webpages. Filters can be specified using wildcards in order to block e.g. all images or JavaScript files from specific servers or directories. Homepage: http://adblock.mozdev.org/ Yaroslav Halchenko [debian-at-onerussian-com], who did latest NMU, already expressed his intention to adopt this package. -- Jacek Politowski ---End Message--- ---BeginMessage--- Source: mozilla-firefox-adblock Source-Version: 0.5.3.043-1 We believe that the bug you reported is fixed in the latest version of mozilla-firefox-adblock, which is due to be installed in the Debian FTP archive: mozilla-firefox-adblock_0.5.3.043-1.diff.gz to pool/main/m/mozilla-firefox-adblock/mozilla-firefox-adblock_0.5.3.043-1.diff.gz mozilla-firefox-adblock_0.5.3.043-1.dsc to pool/main/m/mozilla-firefox-adblock/mozilla-firefox-adblock_0.5.3.043-1.dsc mozilla-firefox-adblock_0.5.3.043-1_all.deb to pool/main/m/mozilla-firefox-adblock/mozilla-firefox-adblock_0.5.3.043-1_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Yaroslav Halchenko [EMAIL PROTECTED] (supplier of updated mozilla-firefox-adblock package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 6 Feb 2007 23:50:41 -0500 Source: mozilla-firefox-adblock Binary: mozilla-firefox-adblock Architecture: source all Version: 0.5.3.043-1 Distribution: unstable Urgency: low Maintainer: Yaroslav Halchenko [EMAIL PROTECTED] Changed-By: Yaroslav Halchenko [EMAIL PROTECTED] Description: mozilla-firefox-adblock - AdBlock extension for the IceWeasel web browser Closes: 408415 409964 Changes: mozilla-firefox-adblock (0.5.3.043-1) unstable; urgency=low . * New maintainer. (Closes: #409964: ITA: mozilla-firefox-adblock) Thanks Jacek Politowski for taking care about this beast before * Closing NMU bugreport (Closes: #408415) * Fresh dh_wraporig generating debian/README.Debian-source Files: c9d0c98f543c6e1dc28e85dcc425f79a 672 web optional mozilla-firefox-adblock_0.5.3.043-1.dsc 66ade0a9b1d4c87518769f3648b9e100 6890 web optional mozilla-firefox-adblock_0.5.3.043-1.diff.gz 107dc0ede32f60ca37dc26a62488f07a 74606 web optional mozilla-firefox-adblock_0.5.3.043-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFyelRjRFFY3XAJMgRArZnAJkBVo2M0SvQjyVT/qnH9Qfvb/pL5QCfTw+/ Ppzl/GOUojjRYajTglG39bQ= =IlFC -END PGP SIGNATURE- ---End Message---
Bug#409367: ITP: iceape-locales -- language packs for Iceape
On 7 Feb 2007 at 16:03, Alexander Sack wrote: Preliminary package (unfinished, not tested, lacks rebranding) can be found at http://pingu.ii.uj.edu.pl/~robert/iceape-locales/ Nice ... you think you can get the rebranding done soon, so we can push this? Yes. I've just uploaded the package - it's now waiting for ftpmasters. A copy of it can be found at http://pingu.ii.uj.edu.pl/~robert/iceape-l10n/ Best Regards, robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#409367: ITP: iceape-locales -- language packs for Iceape
Processing commands for [EMAIL PROTECTED]: retitle 409367 ITP: iceape-l10n -- Iceape Language/Region Packages Bug#409367: ITP: iceape-locales -- language packs for Iceape Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409367: ITP: iceape-locales -- language packs for Iceape
retitle 409367 ITP: iceape-l10n -- Iceape Language/Region Packages thanks On 5 Feb 2007 at 19:46, Christian Perrier wrote: locale usually is meant for a locale, ie the definition of parameters that characterize a langage/country combination l10n is meant for localisation which means the action of translating an internationalised software in a set of languages (as For all these reasons, l10n sounds to be the most appropriate to me. Many thanks for your clarification. I can now see that the *-l10n-* name is much better than *-locale-*, that's why the package I've just uploaded is called iceape-l10n. Best Regards, robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410090: ITP: prewikka -- Graphical front-end analysis console for the Prelude Hybrid IDS Framework
Package: wnpp Severity: wishlist Owner: Pierre Chifflier [EMAIL PROTECTED] * Package name: prewikka Version : 0.9.9 Upstream Author : Yoann Vandoorselaere [EMAIL PROTECTED] * URL : http://www.prelude-ids.org/ * License : GPL Programming Lang: Python Description : Graphical analysis console for the Prelude IDS Framework Prewikka is a graphical front-end analysis console for the Prelude Hybrid IDS Framework. . Providing numerous features, Prewikka facilitates the work of users and analysts. It provides alert aggregation and sensor and hearbeat views, and has user management and configurable filters. It has access to external tools such as whois and traceroute. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407654: O: slidentd -- minimal ident (RFC 1413) daemon
retitle 407654 ITA: slidentd -- minimal ident (RFC 1413) daemon Hi Daniel, I'm a happy slidentd user and would be glad to take over maintaining the package. I've built a new package that fixes #376543 and includes some syntatic improvements to the man pages so that they should render better. I uploaded it to mentors.debian.net. I seek sponsorship if the package is acceptable. Thanks, -- = David D. Smith davidsmith at acm.org Jabber/GoogleTalk: dds at jabber.org ; GPG: 0xE6511C7E IRC: dds on irc.freenode.net ; MSN: dds4418 at hotmail.com == pgphY8F9beDHC.pgp Description: PGP signature
Bug#409367: ITP: iceape-locales -- language packs for Iceape
Robert Luberda wrote: I can now see that the *-l10n-* name is much better than *-locale-*, that's why the package I've just uploaded is called iceape-l10n. thanks for paying attention to it, makes the cat happy :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407654: O: slidentd -- minimal ident (RFC 1413) daemon
David Smith wrote: Hi Daniel, Hi, I'm a happy slidentd user and would be glad to take over maintaining the package. Good, thanks a lot. I've built a new package that fixes #376543 and includes some syntatic improvements to the man pages so that they should render better. I uploaded it to mentors.debian.net. I seek sponsorship if the package is acceptable. The package is fine. However, just wondering, as I did use dpatch to do the upstream modifications, it would be more beautiful if you do so with the manpage corrections too, or, drop dpatch completely and replace it with the patch management system you prefere (or to even not use a patch management system at all). Let me know how you intend to do it, and I'm happy to sponsor the package. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375014: still planning to package libtap?
hi tyler, i'm wondering if you are still planning on packaging libtap. this bug report is 200 days old with no further comment from you. i'm interested in using (packaging if necessary) this myself, and if you're no longer interested and/or don't have the time, i'd like to take over this ITP. thanks, sean signature.asc Description: This is a digitally signed message part
Bug#375014: still planning to package libtap?
Sean, Please take it over. Nobody ever replied to my RFS. :-( - Tyler sean finney [EMAIL PROTECTED] wrote: hi tyler, i'm wondering if you are still planning on packaging libtap. this bug report is 200 days old with no further comment from you. i'm interested in using (packaging if necessary) this myself, and if you're no longer interested and/or don't have the time, i'd like to take over this ITP. thanks, sean -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375014: still planning to package libtap?
On Wed, 2007-02-07 at 11:08 -0800, Tyler MacDonald wrote: Sean, Please take it over. Nobody ever replied to my RFS. :-( oh, i missed the RFS and only saw the ITP. if you're still interested and have the source package laying around somewhere, i could sponsor it. it doesn't look like this is the most active upstream project out there, but if you'd rather co-maintain it, we could do that too :) sean signature.asc Description: This is a digitally signed message part
Processed: tagging bugs that are closed by packages in NEW as pending
Processing commands for [EMAIL PROTECTED]: # the following bugs are closed by packages in NEW # tags 408538 pending Bug#408538: ITP: qwtplot3d -- A 3D plotting library based on Qt/OpenGL There were no tags set. Tags added: pending tags 409154 pending Bug#409154: ITP: libapache2-mod-auth-openid -- OpenID authentication module for Apache2 There were no tags set. Tags added: pending tags 409187 pending Bug#409187: ITP: sigit -- a small utility to change signatures There were no tags set. Tags added: pending tags 409367 pending Bug#409367: ITP: iceape-l10n -- Iceape Language/Region Packages There were no tags set. Tags added: pending tags 409537 pending Bug#409537: kernel-patch-exec-shield: please rename to linux-patch-exec-shield There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
On (07/02/07 23:39), Luca Capello wrote: [2] I still have a problem, because e.g. PAM module for the SGS Thomson Microelectronics fingerprint reader is longer than the expected 60 characters for the short description. Suggestions welcome! Perhaps you can drop the word Microelectronics from the short description. Yes, this was my choice after Rafael Laboissiere privately suggested. Is it really manufactured by SGS Thompson? Is it not from ST Microelectronics? I didn't think the SGS Thompson name was used any more, even if it still exists. Thanks, James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hello! On Thu, 08 Feb 2007 00:13:02 +0100, James Westby wrote: On (07/02/07 23:39), Luca Capello wrote: [2] I still have a problem, because e.g. PAM module for the SGS Thomson Microelectronics fingerprint reader is longer than the expected 60 characters for the short description. Suggestions welcome! Perhaps you can drop the word Microelectronics from the short description. Yes, this was my choice after Rafael Laboissiere privately suggested. Is it really manufactured by SGS Thompson? Is it not from ST Microelectronics? I didn't think the SGS Thompson name was used any more, even if it still exists. From Wikipedia [1] The ST group was formed in June 1987 from the merger of two semiconductor companies Società Generale Semiconduttori (SGS) Microelettronica of Italy and Thomson Semiconducteurs, the semiconductor arm of France's Thomson. In May 1998, the company changed its name from SGS-THOMSON to STMicroelectronics following the withdrawal of Thomson SA. While it seems that the driver is manufactured by UPEK [2], indeed on my X60 with BIOS 2.05 and Debian kernel 2.6.18-4-amd64 I've: = [EMAIL PROTECTED]:~$ cat /proc/bus/usb/devices [...] T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 13 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0483 ProdID=2016 Rev= 0.01 S: Manufacturer=STMicroelectronics S: Product=Biometric Coprocessor C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 4 Ivl=20ms [...] [EMAIL PROTECTED]:~$ = So, it seems the best name would be STMicroelectronics, I'll bring this up to upstream ;-) Thx, bye, Gismo / Luca Footnotes: [1] http://en.wikipedia.org/wiki/STMicroelectronics [2] http://www.thinkwiki.org/wiki/Integrated_Fingerprint_Reader pgpfsuCwDSFiK.pgp Description: PGP signature
RE: Job Offer No Eudcation Required
Hi Debian-tetex-maint. I sincerely hope this message finds you in a great spirit. Just for a start I'd liket o congratulate you on this offer because our corporation got your contact and your short profile through an email listing affiliated with CareerBuilder. I would be extremelyi nterested in giving you a work at home career in which you can earn an extra income up to $5000 monthly. This work will not affect your present career and this is a very limited offer in wihch I will require your immediate response. I really hope to hear from you soon, since its a job that will enable you to enjoy an easy work at home. You will also be given the opportunity of being a part of our future and our team in which you will be highly appreciated. Please fill out our applciation form. No upfront fees asked, nothing, just your name and a phone number. Application form: http://www.cordellfp.info/index.html Your application will be processed ASAP. Kelly Drake man would have taken that as an omen and thought twice, thrice on what -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
ATM I don't really see any reason to create a separate package just for tf-tool, because libthinkfinger + tf-tool (binary and manpage) should generate a package around less than 50K in size. In case new tools will be added, we can split the package. I tend to agree with Luca. tf-tool is integral to the functionality of the package. However, in the package that I have started building, I have the following packages. I am not at all sure this is proper, but it is what I have done so far: libpam-thinkfinger (depends on libthinkfinger0) libthinkfinger0 libthinkfinger-dev thinkfinger (depends on libpam-thinkfinger) Yes, this was my choice after Rafael Laboissiere privately suggested. Sounds good to me too. Joshua signature.asc Description: OpenPGP digital signature
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hello! I'm cc:ing Joshua Rubin (the ThinkFinger co-maintinaer) and d-d to have more comments. On Wed, 07 Feb 2007 12:24:29 +0100, Marcus Better wrote: Luca Capello wrote: Am I correct? Is tf-tool worth a single package or can I include it in libthinkfinger (as I'd prefer)? I think it's common practice to put the tools in a separate package, and suggest the name thinkfinger-tools instead of tf-tool, since it's easier for the user to identify what the package is for, and since other tools may be added in the future. I'm aware of the common practice and this is the reason why I specifically asked for an advice. ATM I don't really see any reason to create a separate package just for tf-tool, because libthinkfinger + tf-tool (binary and manpage) should generate a package around less than 50K in size. In case new tools will be added, we can split the package. Is a strong reason against this? BTW, thanks for your suggestion about the package name, thinkfinger-tools would be definitively better. [2] I still have a problem, because e.g. PAM module for the SGS Thomson Microelectronics fingerprint reader is longer than the expected 60 characters for the short description. Suggestions welcome! Perhaps you can drop the word Microelectronics from the short description. Yes, this was my choice after Rafael Laboissiere privately suggested. Thx, bye, Gismo / Luca pgpJjSO7I6jJd.pgp Description: PGP signature
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hello! I'm adding again the bug report, please keep it cc:ed. On Thu, 08 Feb 2007 00:28:24 +0100, Evgeni Golov wrote: On Wed, 07 Feb 2007 23:39:39 +0100 Luca Capello wrote: ATM I don't really see any reason to create a separate package just for tf-tool, because libthinkfinger + tf-tool (binary and manpage) should generate a package around less than 50K in size. In case new tools will be added, we can split the package. Is a strong reason against this? Is tf-tool to be used by the user directly? If so, I would place it in an own package. If it's only a binary used in scripts/whatever - ship it in lib*. tf-tool requires root privileges because it needs to access the USB device. Moreover, practically speaking as a normal user you couldn't do anything more than acquire/verify your fingerprint, but stored in /tmp/test.bir. As root, however, you can automatically acquire a fingerprint for a login user (because it stores the fingerprint in /etc/pam_thinkfinger/). This is another reason I'd go for libthinkfinger only. The point is, the user might want to read something about the tool he is using. There is a manpage and /usr/share/doc/package/, the last one would be ugly for libthinkfinger, because user would expect packagename==binaryname. Hope you understand what I mean ;) I understand, but packagename==binaryname is already not respected and it'll be the case with the package name proposed by Marcus, i.e. thinkfinger-tools. Moreover, the presence of tf-tool in libthinkfinger will be advised in the package description and if necessary in README.Debian, but I'm against that (take xbase-clients as an example...). By the way, are there any prerelease packags for testing? This UPEK-blob gets on my nerves ;) The package is still in preparation, Joshua and I are working in a co-maintenance. I'll privately drop you a mail as soon as the package is ready. Thx, bye, Gismo / Luca pgpx0O6X4sRUp.pgp Description: PGP signature
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hi, On Thu, 08 Feb 2007 00:47:42 +0100 Luca Capello wrote: I'm adding again the bug report, please keep it cc:ed. Oh, sorry, was reading via gmane, so reply was sent over nntp only. Now CC'ing everyone. Is tf-tool to be used by the user directly? If so, I would place it in an own package. If it's only a binary used in scripts/whatever - ship it in lib*. tf-tool requires root privileges because it needs to access the USB device. Moreover, practically speaking as a normal user you couldn't do anything more than acquire/verify your fingerprint, but stored in /tmp/test.bir. As root, however, you can automatically acquire a fingerprint for a login user (because it stores the fingerprint in /etc/pam_thinkfinger/). This is another reason I'd go for libthinkfinger only. Sounds reasonable. I do not see any real pain shipping a binary in libfoo, even if the name suggests something different. I once read the following statement: How to check, whether my debian/copyright is okay? - Upload to NEW and wait for ftp-master action. As there is no point in the policy oslt, this would apply for your problem too ;) Thanks for packaging Evgeni -- ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED]) d(O_o)b | GPG/PGP-Key-ID: 0xAC15B50C -|- | 0C04 F872 0963 ADC9 AA83 882B 24A0 1418 AC15 B50C / \| http://www.die-welt.net - [EMAIL PROTECTED] Wie man Menschen tötet, lernt man jeden Abend im Fernsehen, aber wie man sie macht, DAS ist schlimm. pgpC1WtdmEMlN.pgp Description: PGP signature
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Hi, On Wed, 2007-02-07 at 23:39:39 +0100, Luca Capello wrote: ATM I don't really see any reason to create a separate package just for tf-tool, because libthinkfinger + tf-tool (binary and manpage) should generate a package around less than 50K in size. In case new tools will be added, we can split the package. Is a strong reason against this? Please do not include it in the lib package, it's a pain afterwards when a new version with a different soname is introduced and disallows parallel installation of those. (This will also be a problem for multi-arch). regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407654: O: slidentd -- minimal ident (RFC 1413) daemon
Daniel Baumann [EMAIL PROTECTED] writes: The package is fine. However, just wondering, as I did use dpatch to do the upstream modifications, it would be more beautiful if you do so with the manpage corrections too, or, drop dpatch completely and replace it with the patch management system you prefere (or to even not use a patch management system at all). Let me know how you intend to do it, and I'm happy to sponsor the package. I agree using dpatch is better so I've made the appropriate changes and reuploaded. I'm a big fan of darcs and am evaluating darcs-buildpackage but for now, just using dpatch is definitely better than directly modifying the source. Thanks, -- = David D. Smith davidsmith at acm.org Jabber/GoogleTalk: dds at jabber.org ; GPG: 0xE6511C7E IRC: dds on irc.freenode.net ; MSN: dds4418 at hotmail.com == pgp21XHhnyI3q.pgp Description: PGP signature
