Accepted gforth 0.6.2-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 20 Nov 2003 00:40:02 -0700 Source: gforth Binary: gforth Architecture: source i386 Version: 0.6.2-2 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Changes: gforth (0.6.2-2) unstable; urgency=low . * Cleaned up some lintian problems. Nothing major. Files: 530d879254815a3e39ed87d281ea023e 562 interpreters optional gforth_0.6.2-2.dsc 42d41c9297fc8e9b8b6392d5b2666c57 17668 interpreters optional gforth_0.6.2-2.diff.gz 8e8c841ca18583564486f2d6a878a5e2 779898 interpreters optional gforth_0.6.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vHEcXXfiXWfzb/IRAk9wAJwM7CCvurT6lTdEQ6Wwr4/GRWyAJgCginiP yagmTVzjObhCNZHSsGcn0qQ= =eLrt -END PGP SIGNATURE- Accepted: gforth_0.6.2-2.diff.gz to pool/main/g/gforth/gforth_0.6.2-2.diff.gz gforth_0.6.2-2.dsc to pool/main/g/gforth/gforth_0.6.2-2.dsc gforth_0.6.2-2_i386.deb to pool/main/g/gforth/gforth_0.6.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sg3-utils 1.05-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 20 Nov 2003 00:59:26 -0700 Source: sg3-utils Binary: sg3-utils Architecture: source i386 Version: 1.05-2 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: sg3-utils - Utilities for working with generic SCSI devices Closes: 221762 221768 Changes: sg3-utils (1.05-2) unstable; urgency=low . * Um, like, set PREFIX to /usr in Makefile. :-\ (closes: #221768,#221762) * sg3-utils is NOT a debian-native package. Grr. Files: 6dc3f8992a76e5b186259a4b8ae7fd53 567 admin optional sg3-utils_1.05-2.dsc e1ac06d8a2d2ae07083266beadb45768 188002 admin optional sg3-utils_1.05.orig.tar.gz 04c697229851d1de8a6dd9f394dad87c 341 admin optional sg3-utils_1.05-2.diff.gz 193713f89b46138dd39dbfe3b7fc7dbb 380242 admin optional sg3-utils_1.05-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vHoGXXfiXWfzb/IRAvDHAKCAuugLoOB8HwhOf6/Pzln4yx7PhwCcC8Xi EdKH6qZNlIQSvEHV98TCf5I= =H0L7 -END PGP SIGNATURE- Accepted: sg3-utils_1.05-2.diff.gz to pool/main/s/sg3-utils/sg3-utils_1.05-2.diff.gz sg3-utils_1.05-2.dsc to pool/main/s/sg3-utils/sg3-utils_1.05-2.dsc sg3-utils_1.05-2_i386.deb to pool/main/s/sg3-utils/sg3-utils_1.05-2_i386.deb sg3-utils_1.05.orig.tar.gz to pool/main/s/sg3-utils/sg3-utils_1.05.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xfishtank 2.2-23 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 18 Nov 2003 22:09:50 -0700 Source: xfishtank Binary: xfishtank Architecture: source i386 Version: 2.2-23 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: xfishtank - turns your X root into an aquarium Closes: 217490 Changes: xfishtank (2.2-23) unstable; urgency=low . * Updated vroot.h to handle Xinerama (closes: #217490) Files: 3d885d27f6c4061ae5c2fe9db7dc71a6 577 x11 optional xfishtank_2.2-23.dsc 375f0d62fc469ac18609e7e8a980ae16 8432 x11 optional xfishtank_2.2-23.diff.gz 1b8fcbfc1301e71141ddb669fc550f25 86772 x11 optional xfishtank_2.2-23_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/uvteXXfiXWfzb/IRAlGuAJ9DIvngSWmLgwuRMzH/9beCWO7KNgCfUlO8 2e2blXMTW3/dFEAp4Nmv4sM= =ww0R -END PGP SIGNATURE- Accepted: xfishtank_2.2-23.diff.gz to pool/main/x/xfishtank/xfishtank_2.2-23.diff.gz xfishtank_2.2-23.dsc to pool/main/x/xfishtank/xfishtank_2.2-23.dsc xfishtank_2.2-23_i386.deb to pool/main/x/xfishtank/xfishtank_2.2-23_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sg3-utils 1.05-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 18 Nov 2003 22:22:29 -0700 Source: sg3-utils Binary: sg3-utils Architecture: source i386 Version: 1.05-1 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: sg3-utils - Utilities for working with generic SCSI devices Closes: 221143 Changes: sg3-utils (1.05-1) unstable; urgency=low . * New upstream release * updated description to match tools in package (closes: #221143) Files: fcaf4052546ec75409eae492f11ec182 501 admin optional sg3-utils_1.05-1.dsc 8ba79084898d7c8205a427875e8a3860 187901 admin optional sg3-utils_1.05-1.tar.gz 9cc8544dddb03a195217795ca2f524ce 412932 admin optional sg3-utils_1.05-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/uwUOXXfiXWfzb/IRAqWeAJ4rFgZiVqhTgqgQL9mEtKjfMvR1JACcCDKq 2cD87my+CkaqJHjApxexG3U= =2V5n -END PGP SIGNATURE- Accepted: sg3-utils_1.05-1.dsc to pool/main/s/sg3-utils/sg3-utils_1.05-1.dsc sg3-utils_1.05-1.tar.gz to pool/main/s/sg3-utils/sg3-utils_1.05-1.tar.gz sg3-utils_1.05-1_i386.deb to pool/main/s/sg3-utils/sg3-utils_1.05-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of Progeny projects
On Tuesday, Nov 11, 2003, at 23:39 America/Denver, Peter Zoeller wrote: Most software installs fail as a result of missing libraries. I would like to see a central repository for all libraries, old, new and development. A repository that when a library dependancy needs to be satisfied, the installer be it RPM, APT or anyone elses, can automatically access and download the appropriate version of library required. This repository should only hold nothing but libraries, no software, no packages, just libraries with a searchable capability that one could also manually search and download ones needs. Just curious... have you ever actually used Debian? When you write to a list comprised of Debian developers that concentrates on Debian software and library packaging needs to suggest something we've been doing that for years now, I have to wonder why. If you want to install software from Debian, all of our package installation methods automatically install all the libraries (and, optionally, any other recommended or suggested software) required for full operation. That's what we do. I'm not sure of the point of your suggestion-- having used more Red Hat systems in the past year than bears thinking about, I can see how you might think it useful for them, but even in that case, you have different libc versions, compiler revs, architectures and sometimes even kernels to keep track of, not to mention the version numbers of the libraries. The only sensible solution is to package libraries as part of a distribution, in which case I fail to see the utility of your idea. With the version numbers used in linux there is no fear as there is in the other OS of overlaying and existing library that would result in the breaking of other software. It would be no problem to run the same library beside its earlier parent satisfying the need of all software. Unless the new library was binary-incompatible with the old, requiring new revs of all the programs it uses. And then maybe the new library calls executables that don't exist, requiring you to install new software packages to handle that. At this point, it sounds like we're back to packaging libraries as part of a complete distribution, in which case I'm afraid your 'library-only' archive will not be of much use. Along with this there should be a tool that will allow the cleaning up of ones libraries based on lack of activity so that the directories holding libraries such as /lib can be safely maintained and kept from growing out of hand. Hrm. Sounds a lot like dpkg, combined with deborphan. Thanks to all open source developers for the work that has and continues to be done. You're welcome. :) -=Eric
Accepted yaz 2.0.2-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 26 Sep 2003 22:01:08 -0600 Source: yaz Binary: yaz-doc libyaz-dev yaz libyaz Architecture: source all i386 Version: 2.0.2-4 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: libyaz - Z39.50 runtime libraries libyaz-dev - Z39.50 development files and header files yaz- Utility programs for Z39.50 toolkit yaz-doc- Documentation for YAZ Closes: 211350 Changes: yaz (2.0.2-4) unstable; urgency=low . * libyaz-dev now depends on libyaz. (closes: #211350) Files: 4d1ae63f0c3b5d5b5af70aee012437d5 671 devel optional yaz_2.0.2-4.dsc 09d1d4a73054554c8743b429c2c2f4ae 249025 devel optional yaz_2.0.2-4.diff.gz f4c8d675027b751034f2b9d01cb85899 116042 devel optional yaz_2.0.2-4_i386.deb 39c9228cb3e52a64c5e979827bea49cc 205310 libs optional libyaz_2.0.2-4_i386.deb a74f78e4133ee88477a2ddb33ba0dce4 369090 devel optional libyaz-dev_2.0.2-4_i386.deb e3aaa19df50cef7c71635cdbeaaa1a2e 349016 doc optional yaz-doc_2.0.2-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dWOqXXfiXWfzb/IRAnwTAJ4vtrAxNgQCtlENkwp38YnSo+knUwCdGw5L 2FmXTcnE70DRRWv75FkJE/E= =UZ0N -END PGP SIGNATURE- Accepted: libyaz-dev_2.0.2-4_i386.deb to pool/main/y/yaz/libyaz-dev_2.0.2-4_i386.deb libyaz_2.0.2-4_i386.deb to pool/main/y/yaz/libyaz_2.0.2-4_i386.deb yaz-doc_2.0.2-4_all.deb to pool/main/y/yaz/yaz-doc_2.0.2-4_all.deb yaz_2.0.2-4.diff.gz to pool/main/y/yaz/yaz_2.0.2-4.diff.gz yaz_2.0.2-4.dsc to pool/main/y/yaz/yaz_2.0.2-4.dsc yaz_2.0.2-4_i386.deb to pool/main/y/yaz/yaz_2.0.2-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gforth 0.6.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Oct 2003 21:43:02 -0600 Source: gforth Binary: gforth Architecture: source i386 Version: 0.6.2-1 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Closes: 213680 Changes: gforth (0.6.2-1) unstable; urgency=low . * New upstream release * Remove INSTALL_INFO from Makefile.in to not generate /usr/share/doc/info/dir.(old).gz (closes: #213680) Files: 991ed73dcd006c0d4c0ec2408d721766 562 interpreters optional gforth_0.6.2-1.dsc 869112bd762b07fc4d2038a2d9965148 1925536 interpreters optional gforth_0.6.2.orig.tar.gz bb1730436d29721d2b76bc1d3d340abf 17429 interpreters optional gforth_0.6.2-1.diff.gz 260c291b62c1ad239fe0f48e98217db6 779920 interpreters optional gforth_0.6.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jMltXXfiXWfzb/IRAgEdAJ9fDgg47Z66QIU02U6Z8VA0/DxaTgCggTBV lf9/ikIk8ZRdwx6K75p5k60= =gDi5 -END PGP SIGNATURE- Accepted: gforth_0.6.2-1.diff.gz to pool/main/g/gforth/gforth_0.6.2-1.diff.gz gforth_0.6.2-1.dsc to pool/main/g/gforth/gforth_0.6.2-1.dsc gforth_0.6.2-1_i386.deb to pool/main/g/gforth/gforth_0.6.2-1_i386.deb gforth_0.6.2.orig.tar.gz to pool/main/g/gforth/gforth_0.6.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should MUA only Recommend mail-transfer-agent?
On Thursday, Aug 7, 2003, at 02:51 America/Denver, Peter Mathiasson wrote: On Wed, Aug 06, 2003 at 10:34:28PM -0700, Steve Lamb wrote: Here it isn't. That is because that correspondence is done on company time using company equipment supposedly for company purposes. They have the right to keep records of what is going on and some companies do, indeed, keep records. Obviously they're not going to keep the spam. The point is though that they do keep records and unless your personal mail is caught by some automatic filter or is removed manually (in which case it is read anyway) it can be saved. Then perhaps you should use an encrypted tunnel to a safer location. That was, in fact, more or less what he was talking about. (Steve did not mention an encrypted tunnel, but did talk about sending personal mail through a different server than the work one). I wouldn't send mails through that channel, even if it was work related. It can look fairly unprofessional if email from your work address goes through a different server; I would be surprised and more than a little wary if email from a major vendor came through a comcast.net SMTP server. Besides, many US firms have legally mandated document retention policies; archiving sent mail may be a required part of that. Of course, most of the time it's probably not. You should value your integrity more than that. Which is why he wants to send personal mail through a non-work server, no? -=Eric
Accepted gforth 0.6.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 20:50:47 -0600 Source: gforth Binary: gforth Architecture: source i386 Version: 0.6.1-4 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Closes: 195364 198055 Changes: gforth (0.6.1-4) unstable; urgency=low . * set no_dynamic_default=1 as a quick fix from the gforth mailing list. (closes: #195364) . * Applied Mario Lang's patch to autoload forth-block-mode and run-forth (closes: #198055) Files: e9a3408b5a080ef5cc3685e3aaca9f6b 562 interpreters optional gforth_0.6.1-4.dsc a494c214fe0eceb3f9f0271b7074a3f6 27987 interpreters optional gforth_0.6.1-4.diff.gz c61f2a4ff6aa5d7c42edd5d44e9c005d 775622 interpreters optional gforth_0.6.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MHLcXXfiXWfzb/IRAl9HAJ424J3JAMrLs4fP7lESOpEZuov7nACfTHog 0CU0tU88mDjsl8MnToaJXHY= =4rA4 -END PGP SIGNATURE- Accepted: gforth_0.6.1-4.diff.gz to pool/main/g/gforth/gforth_0.6.1-4.diff.gz gforth_0.6.1-4.dsc to pool/main/g/gforth/gforth_0.6.1-4.dsc gforth_0.6.1-4_i386.deb to pool/main/g/gforth/gforth_0.6.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yaz 2.0.2-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 6 Jul 2003 22:27:00 -0600 Source: yaz Binary: yaz-doc libyaz-dev yaz libyaz Architecture: source all i386 Version: 2.0.2-3 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: libyaz - Z39.50 runtime libraries libyaz-dev - Z39.50 development files and header files yaz- Utility programs for Z39.50 toolkit yaz-doc- Documentation for YAZ Closes: 198977 Changes: yaz (2.0.2-3) unstable; urgency=low . * Fixed debian/yaz-doc.doc-base to reflect reality (closes: #198977) Files: c504523ce14fe150a697e0665ad109f5 671 devel optional yaz_2.0.2-3.dsc 024bd2efc038bea8204404e0f2fdac22 247184 devel optional yaz_2.0.2-3.diff.gz 85ebb4e9ff841dcb46cd1f78cb6af264 112356 devel optional yaz_2.0.2-3_i386.deb b7007fa2aac58be5a18cb4a1d1c0645a 192576 libs optional libyaz_2.0.2-3_i386.deb d6541750c3ecf031662e604360a64959 353084 devel optional libyaz-dev_2.0.2-3_i386.deb 8ef10e02165d89248a3063ab1627cff8 348948 doc optional yaz-doc_2.0.2-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CPfDXXfiXWfzb/IRAnWNAJ9+hsAt56ctr2S4uDOjxit/YaHQWwCfRop2 /8DxSJD1K+h+MSMSpjgGVBQ= =jpvX -END PGP SIGNATURE- Accepted: libyaz-dev_2.0.2-3_i386.deb to pool/main/y/yaz/libyaz-dev_2.0.2-3_i386.deb libyaz_2.0.2-3_i386.deb to pool/main/y/yaz/libyaz_2.0.2-3_i386.deb yaz-doc_2.0.2-3_all.deb to pool/main/y/yaz/yaz-doc_2.0.2-3_all.deb yaz_2.0.2-3.diff.gz to pool/main/y/yaz/yaz_2.0.2-3.diff.gz yaz_2.0.2-3.dsc to pool/main/y/yaz/yaz_2.0.2-3.dsc yaz_2.0.2-3_i386.deb to pool/main/y/yaz/yaz_2.0.2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted space-orbit 1.01-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Jun 2003 23:18:41 -0600 Source: space-orbit Binary: space-orbit Architecture: source i386 Version: 1.01-2 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: space-orbit - A 3D space combat simulator Closes: 189770 195479 Changes: space-orbit (1.01-2) unstable; urgency=low . * 'orbit' wrapper now creates appropriate symlinks in ~/.orbit (closes: #189770) * hacked src/hud.c to not try to draw no missles for b0rken nVidia drivers (closes: #195479) Files: d16b9940bb767aff79827e4b85328efb 602 games optional space-orbit_1.01-2.dsc 9823788da217f30ba5e1f21145245b47 6722 games optional space-orbit_1.01-2.diff.gz fdcc9426d7190976382d71a29ee5527c 3192644 games optional space-orbit_1.01-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE++TEHXXfiXWfzb/IRAhJiAJ9W2ozP7m6RLHmScJbp3wzNaMmmkwCggJKT tTMBVYwJkPRNJKQCDexjzps= =h8tz -END PGP SIGNATURE- Accepted: space-orbit_1.01-2.diff.gz to pool/main/s/space-orbit/space-orbit_1.01-2.diff.gz space-orbit_1.01-2.dsc to pool/main/s/space-orbit/space-orbit_1.01-2.dsc space-orbit_1.01-2_i386.deb to pool/main/s/space-orbit/space-orbit_1.01-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
On Thursday, Jun 19, 2003, at 00:30 America/Denver, Sven Luther wrote: I have almost a ready package, i just now need a fine short description. How about: simple audio player with detachable GUI It's not perfect, I know. This sounds pretty nifty, actually, but hard to categorize. But this still doesn't sound quite right, and doesn't mention the second advantage, which is a bit difficult to express in a simple phrase anyway. The other thing to remember is that the short description is just a hook. It doesn't have to mention every distinguishing feature of the package, or else xemacs would never have been uploaded. :) Just attempt something catchy (which my contribution isn't, really), and leave the full description for the appropriate section. -=Eric (xemacs user, BTW)
Accepted yaz 2.0.2-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 May 2003 02:58:17 -0600 Source: yaz Binary: yaz-doc libyaz-dev yaz libyaz Architecture: source all i386 Version: 2.0.2-1 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: libyaz - Z39.50 runtime libraries libyaz-dev - Z39.50 development files and header files yaz- Utility programs for Z39.50 toolkit yaz-doc- Documentation for YAZ Changes: yaz (2.0.2-1) unstable; urgency=low . * Initial Release. * Re-debianized package for compliance with current policy Files: 10df5dc5b7c2bf14aadc5c41ccfa8c94 671 devel optional yaz_2.0.2-1.dsc 44e477d9aec8a74370bd291a66c01d81 1087985 devel optional yaz_2.0.2.orig.tar.gz ebcda2f279fdecbb3f36e138c11b8f5e 247105 devel optional yaz_2.0.2-1.diff.gz 06b97addcee6528b7e6917ee9b088ee5 112184 devel optional yaz_2.0.2-1_i386.deb 2e4a04659f26bd4191c96e1bc03ca91f 192334 libs optional libyaz_2.0.2-1_i386.deb f0f5dd9c51b524c8caf441b4ade2cf6e 298474 devel optional libyaz-dev_2.0.2-1_i386.deb 5efd6807d3f0e899b56d9d7c335a219c 348870 doc optional yaz-doc_2.0.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4OaOXXfiXWfzb/IRAr0tAKCF5UAWZt2i6n72esq4QxCMguKgMwCfaveX k0q680dgrkW5CBuYsRGEs9E= =dxlI -END PGP SIGNATURE- Accepted: libyaz-dev_2.0.2-1_i386.deb to pool/main/y/yaz/libyaz-dev_2.0.2-1_i386.deb libyaz_2.0.2-1_i386.deb to pool/main/y/yaz/libyaz_2.0.2-1_i386.deb yaz-doc_2.0.2-1_all.deb to pool/main/y/yaz/yaz-doc_2.0.2-1_all.deb yaz_2.0.2-1.diff.gz to pool/main/y/yaz/yaz_2.0.2-1.diff.gz yaz_2.0.2-1.dsc to pool/main/y/yaz/yaz_2.0.2-1.dsc yaz_2.0.2-1_i386.deb to pool/main/y/yaz/yaz_2.0.2-1_i386.deb yaz_2.0.2.orig.tar.gz to pool/main/y/yaz/yaz_2.0.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yaz 2.0.2-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Jun 2003 21:57:02 -0600 Source: yaz Binary: yaz-doc libyaz-dev yaz libyaz Architecture: source all i386 Version: 2.0.2-2 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: libyaz - Z39.50 runtime libraries libyaz-dev - Z39.50 development files and header files yaz- Utility programs for Z39.50 toolkit yaz-doc- Documentation for YAZ Changes: yaz (2.0.2-2) unstable; urgency=low . * Added .h files to -dev package Files: 17461090bfabe823f86ff37bcf04b73d 671 devel optional yaz_2.0.2-2.dsc 3748c84901183d1bc4af49dddca78d39 246882 devel optional yaz_2.0.2-2.diff.gz 1662d3472adc1ce80d0d20f938ebc20c 112282 devel optional yaz_2.0.2-2_i386.deb cd8b4a6c6dcb430eafc78d4931b5ab39 192526 libs optional libyaz_2.0.2-2_i386.deb 09afbbe725e8368bcc8d230d1a4e6e29 352994 devel optional libyaz-dev_2.0.2-2_i386.deb d6da74223b61190a021e8674a29e4a6f 348940 doc optional yaz-doc_2.0.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+5qlzXXfiXWfzb/IRAhJQAJ95I8ojwt2xVI/ih2gVrkPeGh4TuwCfXjTW /3yNZ1YEvwCn31H2mUO0fKc= =Ymdc -END PGP SIGNATURE- Accepted: libyaz-dev_2.0.2-2_i386.deb to pool/main/y/yaz/libyaz-dev_2.0.2-2_i386.deb libyaz_2.0.2-2_i386.deb to pool/main/y/yaz/libyaz_2.0.2-2_i386.deb yaz-doc_2.0.2-2_all.deb to pool/main/y/yaz/yaz-doc_2.0.2-2_all.deb yaz_2.0.2-2.diff.gz to pool/main/y/yaz/yaz_2.0.2-2.diff.gz yaz_2.0.2-2.dsc to pool/main/y/yaz/yaz_2.0.2-2.dsc yaz_2.0.2-2_i386.deb to pool/main/y/yaz/yaz_2.0.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#194961: ITP: yaz -- A C/C++ toolkit for Z39.50/ISO23950 applications
Package: wnpp Version: unavailable; reported 2003-05-27 Severity: wishlist * Package name: yaz Version : 2.0.2 Upstream Author : IndexData * URL : http://www.indexdata.dk/yaz/ * License : BSD-ish: http://www.indexdata.dk/yaz/doc/license.php Description : A C/C++ toolkit for Z39.50/ISO23950 applications YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3/SRW clients and servers. Sample clients and servers are included with the distribution, as well as documentation. I've put prospective packages up at http://people.debian.org/~emschwar/yaz.html if anybody cares to take a look. The license is basically BSD; it lacks clause 2 in /usr/share/common-licenses/BSD, and the disclaimer is worded slightly differently but AFAICT it is functionally identical. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux wormtongue 2.4.20skif #1 Tue Feb 18 17:27:36 MST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: plagiarism of reiserfs by Debian
I say it ought to be obvious, because Hans put the message in there intending it to be prominent, rather than (say) putting it in a doc file. It is reasonable to assume that he cared about putting this message in front of everyone who used it. If you can't understand why removing it would annoy him then I really doubt your ability to cooperate with other people. You have to realize, we still don't know that you're correct about what he's upset about, becuase Hans has not yet come out and said exactly what the problem is. One early message he posted in this thread indicated to me that his real problem was the lack of the author list in the Debian package of reiserfsprogs. And in any event, I don't think debian-devel is the place for him to air his concerns. Except in extreme cases, we don't overrule a package maintainer's decision to package the software he maintains however he likes. I don't see any indication he has tried unsuccessfully to air his concerns with the maintainer, either via private email, or by filing a bug, so regardless of our opinons, I don't see that at this point, any of us can do much more than generate more material for a flamewar. I have sent Hans private email, suggesting that he try to work this out off-list before resorting to what appeared to me to be a rather vitriolic email as a first approach to the project as a whole. I don't see that any of the discussion that is going on at this point is going to affect in any way the contents of the reiserfsprogs package, and certainly not in a way that Hans would like. Consider: you don't know what Hans doesn't like. You don't know how he'd like things to change. You don't know what he'd consider acceptable, or not. Nor do any of us, because he still hasn't said. As a result, about all we can do as a project is comment on whether or not what the maintainer did is allowable, and it appears that removing the message from mkreiserfs is, but deleting the contributors list isn't (though that appears to be unintentional). We can, as individual members, comment on how we feel about what happened, but given that we don't know exactly what Hans is upset about, even that is perhaps a bit presumptuous. I suggest we try to give this a rest until Hans can come up with a clear statement of what's wrong, and preferably one that includes his attempts to resolve things privately and the results thereof, before we generate too much more flameage. Once we know what the actual problem is, we can consider what solutions might exist. As it is, I don't see how we can do anything but fuel the flames. -=Eric
Re: Hardware Compatibility List for Woody (exist)?
How can I collect an up-to-date Hardware Compatibility List by inspecting (which) Kernel-Code(-Parts)? (How are the SuSE people for example do this-they have a very big HCL but I don't know if Debian can use the same HCL-?) Nor, nor could they really-- SuSE generates their list by people paying them money to say their hardware is certified under SuSE Linux. Debian has no such entity for people to pay us, and we're not as a rule very interested in doing so. Furthermore, distributions like SuSE and Red Hat not only heavily patch the kernels they release, they also rely on their customers not generating a custom kernel; it's my impression that Debian users, as a rule, are much more likely to do so. If someone can answer this question I will start working on this so there will some up-to-date HCL for Woody. First you'll have to define what you mean by HCL. What goes on the list? Is it sufficient for a network card to respond to ifup, or should it perform within some epsilon of its rated speed? What about a SCSI card? Should it be measured to work with disks, scanners, tape drives, and ghod knows what else? Some driver/hardware bugs show up only after a hundred hours or so of continuous operation; how long should a device be tested until it's considered 'compatible'? How do you maintain the list? What kinds of changes would require a recertification, and what kinds wouldn't? That's not to say this isn't a useful or interesting question to ask; just make sure you realize what you're getting yourself into when you do. -=Eric
Accepted gforth 0.5.0-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 8 Jan 2003 10:15:40 -0700 Source: gforth Binary: gforth Architecture: source i386 Version: 0.5.0-4 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Changes: gforth (0.5.0-4) unstable; urgency=low . * Fixes incorrect build using --enable-force-regs on non-m68k archs Files: 24c6d58a3750a562851206c34cd0818e 552 interpreters extra gforth_0.5.0-4.dsc d0fa144607b98e4e73a6bf4a49893133 12579 interpreters extra gforth_0.5.0-4.diff.gz c8f3cc38b612da2700e7aea1d2005c22 605266 interpreters extra gforth_0.5.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+HF1hXXfiXWfzb/IRAoKDAJ9VE8A9m8Wzt3fhffTHl/uZSbxo8QCfdtVD 9UePvjIJmV9y+cDNyOlgleo= =UIDa -END PGP SIGNATURE- Accepted: gforth_0.5.0-4.diff.gz to pool/main/g/gforth/gforth_0.5.0-4.diff.gz gforth_0.5.0-4.dsc to pool/main/g/gforth/gforth_0.5.0-4.dsc gforth_0.5.0-4_i386.deb to pool/main/g/gforth/gforth_0.5.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gforth 0.5.0-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 8 Jan 2003 17:07:47 -0700 Source: gforth Binary: gforth Architecture: source i386 Version: 0.5.0-5 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Changes: gforth (0.5.0-5) unstable; urgency=low . * Fixes won't-build-on-sparc problem Files: 73ea9090d5d9f1b9377f5ab22f691403 561 interpreters extra gforth_0.5.0-5.dsc 2ae97d6eea7cba59ea1586556b8950a0 12706 interpreters extra gforth_0.5.0-5.diff.gz 83579603dcbae9d94c5e66f80151c583 605274 interpreters extra gforth_0.5.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+HL3EXXfiXWfzb/IRAlcDAJ9GYmyZjXA7z7GhXz5pxCaahFX+3ACdGwpe 2xsZJn7d418dF3NBPOFBlWI= =ZGdU -END PGP SIGNATURE- Accepted: gforth_0.5.0-5.diff.gz to pool/main/g/gforth/gforth_0.5.0-5.diff.gz gforth_0.5.0-5.dsc to pool/main/g/gforth/gforth_0.5.0-5.dsc gforth_0.5.0-5_i386.deb to pool/main/g/gforth/gforth_0.5.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted space-orbit 1.0.1-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Jan 2003 19:23:18 -0700 Source: space-orbit Binary: space-orbit Architecture: source i386 Version: 1.0.1-9 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: space-orbit - A 3D space combat simulator Closes: 174843 Changes: space-orbit (1.0.1-9) unstable; urgency=low . * Added contents of doc/ to dh_installdocs (closes: #174843) Files: 4452f18c6aa293593f3871213d290880 607 games optional space-orbit_1.0.1-9.dsc fe071a5e5527502571feead3b97ed18d 6383 games optional space-orbit_1.0.1-9.diff.gz 4d35acec35fadc548d1fbdfa6437d10b 3184786 games optional space-orbit_1.0.1-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+G1kAXXfiXWfzb/IRAq7iAJ0XsB+P16LA+r7cpI+z8Z7yXbehogCgh8N7 jH/HE+SmSHLXCNpO68HNJag= =jTec -END PGP SIGNATURE- Accepted: space-orbit_1.0.1-9.diff.gz to pool/main/s/space-orbit/space-orbit_1.0.1-9.diff.gz space-orbit_1.0.1-9.dsc to pool/main/s/space-orbit/space-orbit_1.0.1-9.dsc space-orbit_1.0.1-9_i386.deb to pool/main/s/space-orbit/space-orbit_1.0.1-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gforth 0.5.0-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Jan 2003 17:20:15 -0700 Source: gforth Binary: gforth Architecture: source i386 Version: 0.5.0-3 Distribution: unstable Urgency: low Maintainer: Eric Schwartz [EMAIL PROTECTED] Changed-By: Eric Schwartz [EMAIL PROTECTED] Description: gforth - GNU Forth Language Environment Closes: 138894 139843 140153 154042 Changes: gforth (0.5.0-3) unstable; urgency=low . * Added portability patches from Anton Ertl (closes: #140153) * Forced compile on m68k to use --enable-force-reg (closes: #138894) * changed 50gforth.el to provide 'forth-mode (closes: #154042) * Applied Kevin Ryde's patch to gforth.el (closes: #139843) Files: 7b39772c74b3c69af0f434274a813bbd 552 interpreters extra gforth_0.5.0-3.dsc 5a1183d73f0c5ff4a2cddb9ac3c8 12538 interpreters extra gforth_0.5.0-3.diff.gz 2b41aade76fed5e089fc248022134440 602974 interpreters extra gforth_0.5.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+G3wcXXfiXWfzb/IRArZkAJsHVAlCs0qS45ekEEeg7Ih/dljO/QCeLH/f cDZKYiTFgmouXrOgJfTcMqo= =feXv -END PGP SIGNATURE- Accepted: gforth_0.5.0-3.diff.gz to pool/main/g/gforth/gforth_0.5.0-3.diff.gz gforth_0.5.0-3.dsc to pool/main/g/gforth/gforth_0.5.0-3.dsc gforth_0.5.0-3_i386.deb to pool/main/g/gforth/gforth_0.5.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Crazy idea: removing version numbers from debian
[EMAIL PROTECTED] (Vincent L. Mulhollon) writes: Perhaps any package can live in unstable, but any package that has a release critical bug older than 1 week is zapped from stable and placed back in unstable. Upon next package upload, it will be reinstated into stable. Ack! Can you imagine what would happen under that system with a package whose bugs are not handled that quickly? The version in stable would be $foo, next week it's $foo.1, a week later it's $foo again because of a RC bug filed in week 1, another week passes and the bug is fixed, so it's $foo.1 again. Not to mention we'd have to start supporting downgrades as well as upgrades (although I'm a new developer, I'm fairly sure we don't do that). New packages would not be allowed into stable until x days had passed in unstable status without a Release Critical Bug. Then someone files one when the maintainer's on vacation, nobody has time to do a NMU, and it pops back into unstable. Ick. Or perhaps any package can live in unstable, and every package has a copy of itself in unstable, but on the last day of the month it is kicked out of stable if it has an open RCB. If you are picky about RCBs, only apt-get stable on the first of the month. What if a RC bug is filed the day before the deadline? Last day of the month hits, users apt-get dist-upgrade and then are faced with having to downgrade their software. If you need a buggy package anyway, get it out of unstable. Better yet, don't put packages into stable until we release. Stable has a fairly well-defined meaning; I don't see much benefit from changing it. In theory this would complicate support because there would be so many versions of debian, yet developers survive with daily versions... But because those daily versions are numbered, we know that the version we're getting is the latest (or not, as we choose). How do you tell somebody I know that was fixed in the version I uploaded last week; don't download today's though, as it's known buggy without using version numbers? You could use dates, but that can get hideously complicated very quickly. Finally the idea I like the best is no numbers, only named updates. See above. Numbers make a lot of things easier. And we'd have a goal for the name. Like the goal for whiskey release would be every package that needs it supports debconf, or the goal for vodka is every package supports kernel 2.4 and IPv6, or the goal for scotch is every package supports perl 5.6 or whatever. A great idea. But can't we do that now? -=Eric -- Any philosophy that can be put in a nutshell belongs there. -- Sydney J. Harris
