Confused by .la file removal vs static linking support
Hi I maintain a library package, libetpan. I'm going to unload a new version, and, among other things, I was going to remove .la file, per release-goal In http://ftp-master.debian.org/~aba/la/current.txt, package is listed as 'libetpan: dependency_libs', so I thoughty I just need to remove .la file from -dev package However I'm confused with how this interfers with static linking support. I've seen talks on this in list archives, but no project-scope resolution. libetpan-dev depends on several other -dev packages because libraries from those are mentioned in dependency_libs, and because libraries provided by those -dev packages are needed to link statically against libetpan. So, should I: (1) just drop .la file, or (2) drop .la file, downgrade dependences on -dev packages to recommends: or suggests:, or (3) drop .la file and dependences on -dev packages, but keep libetpan.a, or (4) drop .la file and dependences on -dev packages and libetpan.a Perhaps (4) is the most consistent solution, since nobody cares about static linking these days. However AFAIU debian's policy is still to provide static libraries. (3) looks like plain inconsistency: package will provide .a file, but not ensure things required for using .a file into system. So I likely should choose from (1) and (2). Please advice. signature.asc Description: This is a digitally signed message part.
Re: Confused by .la file removal vs static linking support
On Sun, 2 May 2010 13:17:08 +0400 "Nikita V. Youshchenko" wrote: > I'm going to unload a new version, and, among other things, I was > going to remove .la file, per release-goal (Thanks for the reminder, the lack of a bug report led to me completely forgetting that I meant to do something about this goal for my own packages.) (Not having .la files that need mangling with dpkg-cross would make cross-building easier too - apart from the .pc files, the rest of the dpkg-cross changes would just be moving files around, not modifying them. One less thing to go wrong, so I'm in favour of removing .la files generally. Simply removing the contents of dependency_libs isn't as good - it the .la is an issue, remove all of it IMHO.) > In http://ftp-master.debian.org/~aba/la/current.txt, package is > listed as 'libetpan: dependency_libs', so I thoughty I just need to > remove .la file from -dev package > > However I'm confused with how this interfers with static linking > support. I've seen talks on this in list archives, but no > project-scope resolution. In the discussion that led to the release goal: "It might happen that we come to the conclusion that we need to keep a few la-files around, as they might be a help for static compiling, but static compiling is at best "not the default", so I would be quite surprised if that's more than 5-10 files (and then that's the exception that confirms the rule)." http://lists.debian.org/debian-devel/2009/08/msg00783.html That's about as resolved as it got AFAICT. Static linking is generally discouraged, ergo static linking support is expendable if such support gets in the way of more useful things, like binNMUs - which it does. > libetpan-dev depends on several other -dev packages because libraries > from those are mentioned in dependency_libs, and because libraries > provided by those -dev packages are needed to link statically against > libetpan. But does any package in Debian actually do the static linking? > So, should I: > > (1) just drop .la file, or > (2) drop .la file, downgrade dependences on -dev packages to > recommends: or suggests:, or > (3) drop .la file and dependences on -dev packages, but keep > libetpan.a, or > (4) drop .la file and dependences on -dev packages and libetpan.a > > Perhaps (4) is the most consistent solution, since nobody cares about > static linking these days. However AFAIU debian's policy is still to > provide static libraries. 8.3 - The static library (libraryname.a) is usually provided in addition to the shared version. That reads more like Policy documenting usual practice rather than mandating that static linking is necessarily desirable or should be explicitly supported even if it causes issues elsewhere. > (3) looks like plain inconsistency: package will provide .a file, but > not ensure things required for using .a file into system. > So I likely should choose from (1) and (2). Removing the .la and retaining the .a is useful because? (To actually statically link without the .la (or with an .la 'mangled' to empty the dependency_libs field) largely amounts to reconstructing the information that was in the .la originally. That should be sufficient disincentive to try to statically link at all. Hence, is it worth wasting archive space on the inevitably much larger .a files?) Personally, I'm thinking of dropping static support in the Debian packages by removing the .la and the .a but preserving dependencies where needed for shared library builds (i.e. Requires: in the .pc file, not Requires.private, where my library directly exports symbols in it's own API that are resolved in another shared library.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpewujDMtQTT.pgp Description: PGP signature
Re: Confused by .la file removal vs static linking support
On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > (To actually statically link without the .la (or with an .la 'mangled' > to empty the dependency_libs field) largely amounts to reconstructing > the information that was in the .la originally. That should be > sufficient disincentive to try to statically link at all. Hence, is it > worth wasting archive space on the inevitably much larger .a files?) > Static linking is resolved by providing a foo.pc file so that "pkg-config --static --libs foo" is all that's needed to find the right libs. Cheers, Julien signature.asc Description: Digital signature
Bug#579924: ITP: iptraf-ng -- Interactive Colorful IP LAN Monitor
Package: wnpp Severity: wishlist Owner: Frederic Peters Owner: Frederic Peters * Package name: iptraf-ng Version : 1.0.2 Upstream Author : Gerard Paul Java * URL : https://fedorahosted.org/iptraf-ng * License : GPL Programming Lang: C Description : Interactive Colorful IP LAN Monitor IPTraf-ng is an ncurses-based IP LAN monitor that generates various network statistics including TCP info, UDP counts, ICMP and OSPF information, Ethernet load info, node stats, IP checksum errors, and others. iptraf-ng is a fork of iptraf (unmaintained for years), with patches from all around already applied, an updated build system, etc. The binary names are left unchanged, this package will replace the iptraf package. Cheers, Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502103758.6947.84300.report...@nezt
Re: Confused by .la file removal vs static linking support
> On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > (To actually statically link without the .la (or with an .la 'mangled' > > to empty the dependency_libs field) largely amounts to reconstructing > > the information that was in the .la originally. That should be > > sufficient disincentive to try to statically link at all. Hence, is it > > worth wasting archive space on the inevitably much larger .a files?) > > Static linking is resolved by providing a foo.pc file so that > "pkg-config --static --libs foo" is all that's needed to find the right > libs. This does not clarify the question about dependences. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005021530.38...@blacky.localdomain
Re: Confused by .la file removal vs static linking support
* Nikita V. Youshchenko [100502 11:27]: > (3) looks like plain inconsistency: package will provide .a file, but not > ensure things required for using .a file into system. I think (3) is the best you can do if you assume the .a file is usefull to anyone. If someone wants to link to the .a file, they will need to give the other libraries anyway, so why not also install those individually? Also remember that "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.". Even without those other development packages, most of the functionality is still there, so I think that is the perfect example for a "Suggests". Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502113154.ga24...@pcpool00.mathematik.uni-freiburg.de
Re: Confused by .la file removal vs static linking support
On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote: > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > > (To actually statically link without the .la (or with an .la 'mangled' > > > to empty the dependency_libs field) largely amounts to reconstructing > > > the information that was in the .la originally. That should be > > > sufficient disincentive to try to statically link at all. Hence, is it > > > worth wasting archive space on the inevitably much larger .a files?) > > > > Static linking is resolved by providing a foo.pc file so that > > "pkg-config --static --libs foo" is all that's needed to find the right > > libs. > > This does not clarify the question about dependences. > It does, because foo.pc won't work without its dependencies installed (even if you're not using --static; they're needed for --cflags). Cheers, Julien signature.asc Description: Digital signature
Proposed changes to the Debian Machine Usage Policy (DMUP)
Hi, the Debian Project Leader recently asked DSA in his delegation[1] to fix a flaw in the current version of the DMUP, the fact that expulsions are DAM's domain, and not our's. I took the opportunity to also fix some other minor stuff in the current version of the document. Please note that this is a first draft, not the final version, which needs to be announced as per delegation to debian-devel-announce. Summary of changes: The Debian Systems Administration Team will do whatever is necessary to keep all machines and services running. Or to say it with someone else's words from IRC: "DSA has to look after this crap, so please don't be a dick." Find attached my proposed changes as commit log, as diff to the current version and as full text of the new version. I started mainaining the new version in git on http://db.debian.org/git/DMUP.git, copied over frequently to http://git.debian.org/?p=mirror/DMUP.git;a=summary (gitweb frontend). Cheers, Martin [1] http://lists.debian.org/debian-devel-announce/2010/04/msg00016.html -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 commit 6fe8c48ea05d8c2f5280aeff330c998b9a103ef7 Author: Martin Zobel-Helas Date: Sun May 2 16:24:17 2010 +0200 Better wording for §0 Signed-off-by: Martin Zobel-Helas commit f473e656a58efa062b44bca68c6b6d38f9886fd5 Author: Martin Zobel-Helas Date: Sun May 2 16:10:09 2010 +0200 expulsions are DAM's domain Signed-off-by: Martin Zobel-Helas commit abcc73391e77840da60a5d9fcee81ec8fb05e1b6 Author: Martin Zobel-Helas Date: Sun May 2 15:38:12 2010 +0200 Add a stanza about the intention of this document and DSA Signed-off-by: Martin Zobel-Helas commit 9965a489dcf11d3b0b6182a15b380e5caef19481 Author: Martin Zobel-Helas Date: Sun May 2 15:03:55 2010 +0200 s/DSA's/DSA/ Signed-off-by: Martin Zobel-Helas commit a704b18213b3ecfa2ac69fef522af9f1f7032d7b Author: Martin Zobel-Helas Date: Sun May 2 14:43:59 2010 +0200 Avoid first/second person wherever possible commit 84fdb6be7c271fb03a051faee4def6a8f5302535 Author: Martin Zobel-Helas Date: Sun May 2 14:31:37 2010 +0200 Move 2.4 to 2.1, as used abbreviations should be mentioned before being used Signed-off-by: Martin Zobel-Helas commit b249343ade59410dd4a2d515b6f70f69d03cd54d Author: Martin Zobel-Helas Date: Sun May 2 13:46:11 2010 +0200 Add a stanza about the version of this document. Rational: Newer versions need to be announced as per DSA delegation stated in http://lists.debian.org/debian-devel-announce/2010/04/msg00016.html We also want that prior versions of that document become invalid when the new version becomes valid. Signed-off-by: Martin Zobel-Helas commit eb4a1e7215b535bda6a447d72a7769bfc4f7 Author: Martin Zobel-Helas Date: Sun May 2 13:33:50 2010 +0200 start new version of DMUP commit ce85a966ae8e0c3476cc6309a35fbcccabdd90c7 Author: Martin Zobel-Helas Date: Sun May 2 13:18:36 2010 +0200 initial version taken from cvs.d.o, Revision 1.7 diff --git a/DMUP b/DMUP index 73312cf..8aba26e 100644 --- a/DMUP +++ b/DMUP @@ -1,10 +1,16 @@ Debian Machine Usage Policies - Version 1.1.1 + Version 1.1.2 +0. This version of the Debian Machine Usage Policies becomes effective + on $DATE1 and supersedes all previous versions. It was announced on + $DATE2 1. Introduction This document describes the policies for using Debian machines and all rules surrounding those. In short: + + The Debian Systems Administration Team will do whatever is +necessary to keep all machines and services working and +running in a secure fashion. + Don't by any wilful, deliberate, reckless or unlawful act interfere with the work of another developer or jeopardize the integrity of data networks, computing equipment, systems @@ -20,23 +26,24 @@ Debian Machine Usage Policies guidelines specify rules that may be violated if necessary but we would rather one did not. 2. General statements - 1. Privilege + 1. Used abbreviations + o DSA - Debian Systems Administration Team + o DMUP - Debian Machine Usage Policy (this document) + o DPL - Debian Project Leader + o DAM - Debian Account Managers + 2. Privilege Access to Debian Facilities is a privilege, not a right or a -commercial service, and we reserve the right to revoke this +commercial service, and DSA reserves the right to revoke this privilege at any time, without prior notice. An explanation will be given within 48 hours. - 2
Re: Confused by .la file removal vs static linking support
Neil Williams wrote: > But does any package in Debian actually do the static linking? A few udebs use static linking to avoid the need for separate udebs for certain libraries. It also helps to reduce memory usage as only needed symbols are linked in. It's only used in a few specific cases; the normal practice is to provide a library from a udeb. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005021656.02073.elen...@planet.nl
Re: Proposed changes to the Debian Machine Usage Policy (DMUP)
Martin Zobel-Helas writes: > I took the opportunity to also fix some other minor stuff in the current > version of the document. Please note that this is a first draft, not the > final version, which needs to be announced as per delegation to > debian-devel-announce. > > ... > > Find attached my proposed changes as commit log, as diff to the current > version and as full text of the new version. I'm new to Debian; I just read the DMUP for the first time. I don't think it is clear what is "Policy" and what is "guideline". Some of the paragraphs in section 4 appear to be guidelines; everything after "examples of what we consider net abuse", for instance. I suggest saying "all numbered paragraphs in section 4 are policies, everything else is guideline", and changing section 4 to have policy paragraphs numbered, similar to section 3. In addition, the statement, "This list is not and cannot be inclusive." is unclear. I think it means "there are other policies that the DSA will enforce that are not listed here". While this is reasonable, there must be some process to communicate such policies before they are enforced. Maybe this is not a problem in practice. Thanks for your work on Debian, -- -- Stephe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/82pr1e5ou5@stephe-leake.org
Re: Proposed changes to the Debian Machine Usage Policy (DMUP)
Hi, i just applied the following patch from Stefano Zacchiroli. 3b5a642da4b800dfde386df835e57b5d86f4 diff --git a/DMUP b/DMUP index 8aba26e..ced6cd0 100644 --- a/DMUP +++ b/DMUP @@ -55,9 +55,9 @@ Debian Machine Usage Policies Systems Administration and convince DSA that there will be no further breaches of the DMUP by the offender. 3. If the offender fails to contact DSA within 14 days, DSA - will propose this account to DAM to be terminated and the - offender expelled from the Debian project. If the offender - has announced they will be on vacation in this time frame + will suspend the corresponding account and propose to DAM the + expulsion of the offender from the Debian project. If the offender + has announced they will be on vacation in this time frame, this period will be extended with the announced duration of the vacation. 4. If the offender is expelled from the project they can @@ -65,8 +65,8 @@ Debian Machine Usage Policies month. The offense will remain on record. 2. Second offense 1. The offenders accounts will be suspended immediately and - DSA will propose this account to DAM to be terminated - immediately. + DSA will propose to DAM the expulsion of the offender from + the Debian project. 2. If the offender does not file for an appeal within the designated time frame the account is terminated. 3. The offender is prohibited from registering as a Debian -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502164508.ga1...@ftbfs.de
Re: Confused by .la file removal vs static linking support
I'm a little alarmed at the attitude that "no one cares about static linking" so that it's okay to drop the .a files. Likely relatively few people care, but there are some that do. One example is scientific users that need to ensure reproducibility of computer experiments [1] over many years: one technique used is to statically link the code and quarantine it so that it isn't disturbed by system library upgrades. It's not the only technique used, of course, but "our priorities are our users" so let's think hard before removing this option for them. To the original poster's question, it seems to me that [2] is reasonably clear that the request is to drop the .la file. I wouldn't necessarily downgrade the -dev package dependencies: often they are there not only for the static lib, but also because your library's includes will #include files from other libs it depends on, so all users of your -dev package may need the depended-upon -devs. So it will depend on the situation at hand. -Steve [1] http://lists.debian.org/debian-science/2010/04/msg00037.html [2] http://lists.debian.org/debian-devel/2009/08/msg00808.html signature.asc Description: Digital signature
Re: Confused by .la file removal vs static linking support
> On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote: > > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > > > (To actually statically link without the .la (or with an .la > > > > 'mangled' to empty the dependency_libs field) largely amounts to > > > > reconstructing the information that was in the .la originally. > > > > That should be sufficient disincentive to try to statically link > > > > at all. Hence, is it worth wasting archive space on the inevitably > > > > much larger .a files?) > > > > > > Static linking is resolved by providing a foo.pc file so that > > > "pkg-config --static --libs foo" is all that's needed to find the > > > right libs. > > > > This does not clarify the question about dependences. > > It does, because foo.pc won't work without its dependencies installed > (even if you're not using --static; they're needed for --cflags). What for? signature.asc Description: This is a digitally signed message part.
Re: Confused by .la file removal vs static linking support
> I wouldn't > necessarily downgrade the -dev package dependencies: often they are > there not only for the static lib, but also because your library's > includes will #include files from other libs it depends on, so all > users of your -dev package may need the depended-upon -devs. So it > will depend on the situation at hand. With libetpan, it is not the case. Several libs (libdb, libcurl, libsasl, libexpat, liblockfile) are used by libetpan internally, but none of their interfaces is experted by libetpan, and none of headers of those libraries is included by any public libetpan header. In this case, dependences on those -dev packages are only because of (1) dependemcy_libs in .la file, and (2) support for static linking. signature.asc Description: This is a digitally signed message part.
Re: Confused by .la file removal vs static linking support
Nikita V. Youshchenko, le Sun 02 May 2010 21:18:26 +0400, a écrit : > > On Sun, May 2, 2010 at 15:30:37 +0400, Nikita V. Youshchenko wrote: > > > > On Sun, May 2, 2010 at 11:46:23 +0100, Neil Williams wrote: > > > > > (To actually statically link without the .la (or with an .la > > > > > 'mangled' to empty the dependency_libs field) largely amounts to > > > > > reconstructing the information that was in the .la originally. > > > > > That should be sufficient disincentive to try to statically link > > > > > at all. Hence, is it worth wasting archive space on the inevitably > > > > > much larger .a files?) > > > > > > > > Static linking is resolved by providing a foo.pc file so that > > > > "pkg-config --static --libs foo" is all that's needed to find the > > > > right libs. > > > > > > This does not clarify the question about dependences. > > > > It does, because foo.pc won't work without its dependencies installed > > (even if you're not using --static; they're needed for --cflags). > > What for? For #includes that your library may do for its API (e.g. gobject). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502180612.gm27...@const.famille.thibault.fr
Re: Confused by .la file removal vs static linking support
> > > > > Static linking is resolved by providing a foo.pc file so that > > > > > "pkg-config --static --libs foo" is all that's needed to find > > > > > the right libs. > > > > > > > > This does not clarify the question about dependences. > > > > > > It does, because foo.pc won't work without its dependencies > > > installed (even if you're not using --static; they're needed for > > > --cflags). > > > > What for? > > For #includes that your library may do for its API (e.g. gobject). But libetpan's public headers do not include any headers of those dependent packages, so it is not the case. Any other reason? signature.asc Description: This is a digitally signed message part.
Re: Confused by .la file removal vs static linking support
Nikita V. Youshchenko, le Sun 02 May 2010 23:54:02 +0400, a écrit : > > > > > > Static linking is resolved by providing a foo.pc file so that > > > > > > "pkg-config --static --libs foo" is all that's needed to find > > > > > > the right libs. > > > > > > > > > > This does not clarify the question about dependences. > > > > > > > > It does, because foo.pc won't work without its dependencies > > > > installed (even if you're not using --static; they're needed for > > > > --cflags). > > > > > > What for? > > > > For #includes that your library may do for its API (e.g. gobject). > > But libetpan's public headers do not include any headers of those dependent > packages, so it is not the case. Maybe, but for some other libraries it is, he just meant it to be an example why -dev is not only needed just for --static. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502200140.gu27...@const.famille.thibault.fr
Re: Confused by .la file removal vs static linking support
Twas brillig at 23:54:02 02.05.2010 UTC+04 when yo...@debian.org did gyre and gimble: >> For #includes that your library may do for its API (e.g. gobject). NVY> But libetpan's public headers do not include any headers of those dependent NVY> packages, so it is not the case. NVY> Any other reason? Wish of pkg-config maintainers. And GNOME developers insistance (so applications developers may blindly include gtk+2.0.pc and get all the stack). -- http://fossarchy.blogspot.com/ pgpggh3nTecRM.pgp Description: PGP signature
Re: Bug#579675: ITP: goban -- Goban screensaver
Hello, On Thu, 2010-04-29 at 22:36 +0400, Al Nikolov wrote: > Package: wnpp > Severity: wishlist > Owner: Al Nikolov > > > * Package name: goban > Version : 1.1 > Upstream Author : Scott Draves > * URL : http://draves.org/goban/ > * License : GPL > Programming Lang: C > Description : Goban screensaver The short description should not include the package name, maybe something like: "screen saver replaying games of Go" > Replays historical games of go (aka wei-chi and baduk) on the screen. The long description could/should also mention: - that it's a screen-saver. - that it is "Designed to work with xscreensaver and Gnome." - which "historical games of go" are replayed? (the game played using cgoban, right?) Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272832135.5782.2121.ca...@solid.paris.klabs.be
Re: Bug#579569: ITP: ants -- advanced normalization tools for brain and image mapping
On Wed, 2010-04-28 at 13:23 -0400, Yaroslav Halchenko wrote: > > * Package name: ants > Description : advanced normalization tools for brain and image mapping > > The ANTS package is designed to enable researchers with advanced tools for > brain and image mapping. ^^ This paragraph could be written in a way to clarify that this tool analyses brain images (i.e it has nothing to do with organizing mind/ideas) > Many of the ANTS registration tools are > diffeomorphic, but deformation (elastic and BSpline) transformations are > available. Unique components of ANTS include multivariate similarity metrics, > landmark guidance, the ability to use label images to guide the mapping and > both greedy and space-time optimal implementations of diffeomorphisms. The > symmetric normalization (SyN) strategy is a part of the ANTS toolkit as is > directly manipulated free form deformation (DMFFD). Thanks, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272833573.5782.2283.ca...@solid.paris.klabs.be
Re: Bug#579600: ITP: sigrok -- Crossplatform logic analyzer and protocol decoder software
On Thu, 2010-04-29 at 00:41 +0200, Uwe Hermann wrote: > Owner: Uwe Hermann > > * Package name: sigrok > Version : 0.1 Version is 0.1... the package description could mention that the software is an early release (alpha/experimental), to avoid deception (and encourage feed-back). > Description : Crossplatform logic analyzer and protocol decoder software Some suggestions to improve the description: > sigrok is a portable, cross-platform, Free/Libre/Open-Source logic analyzer > software This paragraph applies to the whole Debian archive, so it could be dropped. > that supports various logic analyzer hardware products. So, the description could start with: "sigrok is a logic analyzer and protocol decoder software..." Then "This is used by [whom] to help doing [what]." > Design goals: Those features could be written as text, rather than bullets. > - Broad hardware support. Supports a wide variety of logic analyzers >from various vendors with different capabilities. Isn't that implicit, from the list below? > - Cross-platform. Works on Linux, Mac OS X and Windows, Does this really matter to Debian users? > and on many architectures including x86, ARM, Sparc and PowerPC. Unless this feature is unique to this tool, it can be dropped. > - Scriptable protocol decoding. Extendable with protocol decoders >and analyzers written in Python. > - Format support. Supports various input and output formats (raw, >ASCII, hex, CSV, gnuplot, VCD, others). > > Supported (and/or work-in-progress) logic analyzer devices: (A list is fine here.) > - Saleae Logic > - EE Electronics XLA/ESLA100 > - ASIX SIGMA > - Openbench Logic Sniffer > - ZEROPLUS Logic Cube LAP-C series > - CWAV USBee SX > - Braintechnology USB-LPS > - Buspirate (v3) > - Intronix Logicport My cents, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272834584.5782.2402.ca...@solid.paris.klabs.be
Re: Bug#579692: ITP: libtest-inter-perl -- framework for more readable interactive test scripts
On Thu, 2010-04-29 at 22:03 +0100, Chris Butler wrote: > Package: wnpp > Owner: Chris Butler > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org > > * Package name: libtest-inter-perl > Version : 1.01 > Upstream Author : Sullivan Beck > * URL : http://search.cpan.org/dist/Test-Inter/ > * License : Artistic or GPL-1+ > Programming Lang: Perl > Description : framework for more readable interactive test scripts Just a quick suggestion to improve the description: > Test::Inter is another framework for writing test scripts. It is loosely ^ insert "for perl developers". which clarifies: - the programming language - who are the intended users (i.e the developers) > inspired by Test::More, and has most of it's functionality, but it is > not a drop-in replacement. > > This framework offers the ability to write the tests in a more readable > format, and you can access specific tests in a reasonably interactive fashion. My 2¢, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272834588.5782.2403.ca...@solid.paris.klabs.be
Re: Bug#579147: ITP: libapp-cpanminus-perl -- Get, unpack, build and install modules from CPAN
On Sun, 2010-04-25 at 18:12 +, Jeremiah C. Foster wrote: > > * Package name: libapp-cpanminus-perl > Description : Get, unpack, build and install modules from CPAN > > A dependency free, zero configuration, and stand alone CPAN module > installer. Maintainable and extensible with plugins and friendly > to shell scripting. When running, it requires only 10MB of RAM. The package description should mention that the modules aren't integrated with Debian packaging (no resolution dependency ; some conflicts may happens ; security updates aren't handled by apt***, etc). Also, installing the same module on 2 systems at a few days interval does not guarantee to install the the version (isn't it?) So the preferred way to install a perl module in Debian is to use package from Debian) My 2 cents, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272835062.5782.2452.ca...@solid.paris.klabs.be
Re: Bug#579177: ITP: xul-ext-monkeysphere -- Iceweasel/Firefox extension for using Monkeysphere on the web
On Sun, 2010-04-25 at 18:44 -0400, Jameson Graef Rollins wrote: > * Package name: xul-ext-monkeysphere > Version : 0.1 The package description could mention that this is an early/alpha/experimental release, to avoid deception (and encourage feed-back) > Description : Iceweasel/Firefox extension for using Monkeysphere on the > web > > Monkeysphere is a system for using the OpenPGP web of trust > as a PKI for rsa keys. ^^^ Is it appropriate to name those keys "RSA" Wouldn't it be better to state that it's a replacement for X509 certificates? (there is probably an even better wording, but I can't find it). > This extensions enables Monkeysphere checking of X.509 certificates > from https hosts whose keys are in the web of trust. The long description should mention that this package contains an Iceweasel extensions, maybe: "This package contains an Iceweasel/Firefox extensions to use Monkeysphere for checking of X.509 certificates from https hosts whose keys are in the web of trust." My 2 cents, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272836217.5782.2566.ca...@solid.paris.klabs.be
Re: Confused by .la file removal vs static linking support
Le dimanche 02 mai 2010 à 11:57 -0500, Steve M. Robbins a écrit : > One example is scientific users that need to ensure reproducibility of > computer experiments [1] over many years: one technique used is to > statically link the code and quarantine it so that it isn't disturbed > by system library upgrades. … and never manage to run it again later on, when the NSS interface has changed. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#580005: ITP: otf-apanov-heuristica -- derivative font of Adobe's Utopia typeface, with improvements
Package: wnpp
Severity: wishlist
* Package name: otf-apanov-heuristica
Version : 0.2.1
Upstream Author : Andrey V. Panov
* URL : http://code.google.com/p/evristika/
* License : SIL Open Font License
Programming Lang: Fontforge + Python scripts
Description : derivative font of Adobe's Utopia typeface, with
improvements
Heuristica (also: "Эвристика") is the name of a transitional serif
typeface based on Adobe Systems' donated version of their Utopia
typeface (designed originally by Robert Slimbach).
Heuristica improves Utopia with the primary intent of adding Cyrillic
symbols by Andrey V. Panov. Andrey has also incorporated Vietnamese
glyphs made available by Hàn Thế Thành.
Heuristica is a family that features Regular and Italic shapes, with
both being present also in Bold weight.
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100503021034.ga30...@ime.usp.br
Found last answer - universe done.
Problem was : God himself borned answer was : just do logical ,,Armaggedon operation starded'' self test code ok 1 last 2 branches mission test code nown for 3 familes from one only 1 eva gender same branch born family. branche test succesful condition seems ok 1 test condition seems done for his ok Has husband test condition test succes code condition ok for her husband too Succes code for my sister code for her sister unknown cause che and her husband is in too mush love also failure Tried anything desperately sorry cause lost for me gained 14 yo God sadness cause mission nown for me only confirmed last sunday in a like batist church but officialy nown from my first neighbor day after. He Also protestant His Nationality from antilles island Mine french Joined french air army 16 Would like regain britain nationality mission done from me yestarday 12 pm devil defeat status test ok confirmed code name armageddon mission test ok Mission done seems ok for me Very high concentration soldiers in my life Great ! S: Thomas Other details Since sun 20 pm i control my life in all aspect too :) had terrificly be sad too mush long Likely just enough long for me S: any Armageddon leader Born Life system engineer thomas 42 answer day -1 In the unknown unlikely minimum Eva join limit time limit In same unknown Eva mission done Has unreleaved hard secret job name code for ''any borned ready universal universal secret code name "antechrist #n'' born name code name thomas Issied code name unknown no error done mission done parents 2 condition oppositon unlikelikely 2 parents lost in the universe opposite condition error succes "antechrit error code name last try test condition 0k'' gained 3rd time last try test ok eva adan joined succes code status ok -- Thomas Harding t...@thomas-harding.name 1 rue Raymond Vannier 45000 Orléans, France "l'info libre est responsable" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0rympb2dbr5j.bn5xz...@smtp.thomas-harding.name
