Accepted jigdo 0.7.3-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 28 Dec 2009 17:46:15 +0100 Source: jigdo Binary: jigdo-file Architecture: source amd64 Version: 0.7.3-3 Distribution: unstable Urgency: low Maintainer: Richard Atterer atte...@debian.org Changed-By: Richard Atterer atte...@debian.org Description: jigdo-file - Download Debian CD images from any Debian mirror Closes: 370384 413574 418694 507993 515285 516053 528644 548482 Changes: jigdo (0.7.3-3) unstable; urgency=low . * Brown paper bag bugfix release * Non-versioned dependency on libdb-dev rather than libdb4.6-dev. Closes: #548482 * No longer build GUI application and jigdo package, since the GUI will remain unfinished. :~-| Only build jigdo-file package. Closes: #515285, #413574, #370384, #516053 * Updated debian-mirrors.jigdo from current Mirrors.masterlist * Workaround for problem with jigdo-file md5sum together with --no-check-files. Closes: #418694, #528644 Quite possibly also Closes: #507993 * Refer to GPL-2 rather than GPL file in copyright file (lintian) * Avoid warning of man about the jigdo-file.1 manpage (lintian) * Fixed doc-base section of debian-jigdo-mini-howto (lintian) Checksums-Sha1: 3029655a818eaceaaaf39c27c0df9991c11b16a7 997 jigdo_0.7.3-3.dsc 56eb75f002d994633adaf2941d903a39971275d5 18929 jigdo_0.7.3-3.diff.gz 8258dbe32421fb4cdc4ea5a0536d37f4842e9596 207822 jigdo-file_0.7.3-3_amd64.deb Checksums-Sha256: 04b40726f85867b7eca57996009d82a05f7f858804d390818e00b4c3321ad5f4 997 jigdo_0.7.3-3.dsc 483b70b0f26006003d091c94dc804b4751c72eaf172498ef36e8a5a7c797e432 18929 jigdo_0.7.3-3.diff.gz c124bbf8f7d7574e6132b736048fd96421c891376a26c4d8abfefa783872f7a6 207822 jigdo-file_0.7.3-3_amd64.deb Files: 092455f5c09647579f4cf6673283dae5 997 utils extra jigdo_0.7.3-3.dsc 9f1982b4b744a33748430e039b87b78e 18929 utils extra jigdo_0.7.3-3.diff.gz 9f0d0017ccf1044edcb35c62fc5d0ecd 207822 utils extra jigdo-file_0.7.3-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAktAxWgACgkQeeb23IiDVPf86ACdEL7ygXC/S59Gha8c8yz85ydx CKMAn1QEqnrj23V964BQDvbuKamQW4BM =K3e6 -END PGP SIGNATURE- Accepted: jigdo-file_0.7.3-3_amd64.deb to main/j/jigdo/jigdo-file_0.7.3-3_amd64.deb jigdo_0.7.3-3.diff.gz to main/j/jigdo/jigdo_0.7.3-3.diff.gz jigdo_0.7.3-3.dsc to main/j/jigdo/jigdo_0.7.3-3.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote: [I'm personally slightly concerned about relaxing britney allowing testing to get into unreleasable states; a flag to re-enable the old behavoir late in release would probably be good.] Adeodato's proposal makes a lot of sense, but still I agree with the above. Always in a releasable state was a good design decision for testing, and this change will muddy the idea a bit further. At the very least, there should be an auto-generated web page listing packages in testing that are currently unreleasable! For a cleaner separation, testing could be split it two: The normal, releasable testing works according to the strict rules as before. A second, add-on repository (let's call it mouldy;-) can realize Adeodato's idea: It is only intended to be added to sources.list _in addition to testing_, and contains out-of-date library packages and the programs which depend on them. Rather than removing packages from testing to make way for a new transition, britney would move them over to mouldy. This way, they would still be available. At the same time, the fact that they moved there is a clear sign to the respective maintainers that they need to do something to get their packages into a releasable state. Once the problem is resolved, those packages which only indirectly depended on the library transition can be moved back from mouldy to testing without recompilation. I can't say I'm too much of an expert with these issues, so there may be problems with this scheme. For example, it is possible that mouldy would end up containing everything and testing would be empty, which would buy you nothing. :) Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 01:07:56AM -0700, Paul Hardy wrote: However, the original BDF version can contain ASCII comments that are not preserved in the PCF version. These comments often contain information such as author, copyright, and licensing information. With the BDF versions discarded, that information is lost -- there is no round-trip conversion from BDF to PCF to BDF. My first thought: Could BDF be considered a source format for PCF? The logical consequence would be to ship BDF in the source package, and to convert it to PCF when the font package is built. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted jigdo 0.7.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 20 Sep 2008 22:16:25 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.3-2 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager (beta version) jigdo-file - Download Debian CD images from any Debian mirror Closes: 422059 437240 470211 Changes: jigdo (0.7.3-2) unstable; urgency=medium . * Switched to libdb4.6. Closes: #470211 * Switched to libcurl4 * jigdo-mirror passes --no-verbose to wget rather than --non-verbose. Closes: #422059 * Hack Makefile(.in) not to strip if DEB_BUILD_OPTIONS=nostrip. Closes: #437240 Checksums-Sha1: 66344fb4ee1bd60fc63fa8d8e4bb66ec4e88aafd 1002 jigdo_0.7.3-2.dsc 96c4e5853aeee51ca553c47e00a2c40ab6085249 11999 jigdo_0.7.3-2.diff.gz deaf8850586b59e81ada58fbcb19db6d7115d320 186044 jigdo_0.7.3-2_i386.deb c78396fb8ae140e4f397082c4af8e998d5721a31 208394 jigdo-file_0.7.3-2_i386.deb Checksums-Sha256: 7f30f46c5db1643bcd78b65dfd5c395564daf56c9e8053eb45476371c900a9df 1002 jigdo_0.7.3-2.dsc 4339e350c05494f7f2c2ccd280859422175a4d21db09fd01b754425153fdd44a 11999 jigdo_0.7.3-2.diff.gz a379e1c170a8f7253bf1bef1929f45bc9037962af47b3685d802c70abd5abe1d 186044 jigdo_0.7.3-2_i386.deb c36888505fd642db206ae0d20d2c6e39cb6f3ff57f75a6d1554ee3039d950b1c 208394 jigdo-file_0.7.3-2_i386.deb Files: a8acd7adaa05d8ea115ae89c09e7e97b 1002 utils extra jigdo_0.7.3-2.dsc 41f5019272f9718346bd2c94814d3a8b 11999 utils extra jigdo_0.7.3-2.diff.gz a20fb232489779adbe1f8f204618ccb8 186044 utils extra jigdo_0.7.3-2_i386.deb 7b0cd7b7fe1876ebbcc644f4e9196c96 208394 utils extra jigdo-file_0.7.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFI1WGheeb23IiDVPcRAsGwAKCsfLJUkrcwHygYfILoV9k0kSvpeACgmgSk K34s80yQm8fiFohe+SwtkBU= =weLX -END PGP SIGNATURE- Accepted: jigdo-file_0.7.3-2_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.3-2_i386.deb jigdo_0.7.3-2.diff.gz to pool/main/j/jigdo/jigdo_0.7.3-2.diff.gz jigdo_0.7.3-2.dsc to pool/main/j/jigdo/jigdo_0.7.3-2.dsc jigdo_0.7.3-2_i386.deb to pool/main/j/jigdo/jigdo_0.7.3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dbus and initscripts
On Mon, Jun 02, 2008 at 07:34:22PM +0200, Wouter Verhelst wrote: - Stuff is broken, and I want to debug. This debugging might involve stopping and starting services one at a time. The current dbus setup makes this impossible. Personally, I find the current behaviour useful in the following situation: More frequently than I would like, something about Gnome is broken: Nautilus doesn't mount my USB stick or NetworkManager doesn't want to connect to the WLAN. In those cases, it's convenient to just get things going quickly by restarting all of dbus. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-14 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 28 Apr 2008 00:20:10 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-14 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 455087 476112 Changes: udftools (1.0.0b3-14) unstable; urgency=medium . * Added $remote_fs as dependency to LSB init header. Closes: #476112 * Removed useless /etc/modutils/udftools file. Closes: #455087 * Lintian cleanups: Proper copyright info, Homepage: in debian/control Checksums-Sha1: a31a76f3c7aec607641450d4f5724bd30ef9cd90 998 udftools_1.0.0b3-14.dsc 3f2eed36042718b47cfaedc3693946b08f35fb6e 385129 udftools_1.0.0b3-14.diff.gz 946265f041303e270b3f4bd532991db358758e34 77812 udftools_1.0.0b3-14_i386.deb Checksums-Sha256: 4b0b3fbbf4ebbcab6b732743ac081f4ca2d7e963600d3cfd8fc798e6df36b171 998 udftools_1.0.0b3-14.dsc 1cb031c4b18374c7ff54a904c70dec3efa6fd15f6d52ea40c5605cb4afff37b2 385129 udftools_1.0.0b3-14.diff.gz 6ff7bd058b80e262f3aa609f36d8bef00d24251332643910d7a3723eadb8a2eb 77812 udftools_1.0.0b3-14_i386.deb Files: e84bee41d532f722b3f5f545a21b14ba 998 otherosfs extra udftools_1.0.0b3-14.dsc 57123738517f51aaf5fefa651f47853f 385129 otherosfs extra udftools_1.0.0b3-14.diff.gz 01b2be6883925aacc2d0cc35b0d5bb35 77812 otherosfs extra udftools_1.0.0b3-14_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIFQoBeeb23IiDVPcRAk3YAKCHMgxLFjKUD03YFxjcqxyRHRNv2QCgjFCa 07x4pZaGRPBA782EF3gRYP4= =ZCUk -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-14.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-14.diff.gz udftools_1.0.0b3-14.dsc to pool/main/u/udftools/udftools_1.0.0b3-14.dsc udftools_1.0.0b3-14_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-14_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
[Followups set to debian-cd] On Tue, Mar 18, 2008 at 10:32:29AM +0100, Mattias Wadenstein wrote: It would also be useful for me who runs the main cd torrent seeder in that I could just have an up-to-date debian archive and snapshot (minor rsync update), instead of syncing 300+ gigs of data before all the seeds are started up. Are you concerned about increased seek times, Matthias? IIRC people like Attila Nagy mentioned from time to time that jigdo thrashed their disks a bit more than regular .iso downloads. On Tue, Mar 18, 2008 at 10:20:12AM +, Steve McIntyre wrote: I've written code for jigdoofus (exactly the FUSE-based idea that aj suggested) already, but it needs some more work yet. My eventual hope was that it might allow lots of our normal archive mirrors to become CD ISO mirrors or torrent seeders. But I got distracted from it quite a while back... IIRC jigdoofus uncompressed the data on the fly, which made it a bit slow, right? What's the right solution to cache the data from the .template file? Write the pieces to disk uncompressed? Re-compress them with something like LZO? Hmm, a FastCGI solution would also be possible for serving the files via HTTP (but not BitTorrent). I'm tempted... Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-13 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Nov 2007 11:21:03 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-13 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 223266 285313 288355 372093 405821 407144 413625 414801 434164 453629 453667 Changes: udftools (1.0.0b3-13) unstable; urgency=low . * Fixed wrudf build failure with newer GCC. Closes: #453629, #453667 * pktsetup: Return meaningful exit status on errors. Closes: #223266 * Output error message if opening device fails. Closes: #285313 * Recommends: udev. Closes: #405821 * Updated pktsetup manpage. Closes: #414801 * Added Homepage: field to debian/control * Got rid of devfs and makedev support, no longer depend on makedev. No longer attempt to create devices. No longer depend on debconf. Closes: #434164, #407144 * Updated default /etc/default/udftools to be suitable for most people (Though they still need to uncomment DEVICES themselves.) Closes: #413625 * Added info on defaults of cdrwtool -l -w -p in manpage. Closes: #372093 * Added a few #include string.h to avoid compiler warnings * Documented -q switch in cdrwtool manpage (though it's already described in the Description section). Closes: #288355 * Re-libtoolized Files: 8131f50688b0da4d5a884e3e43fe1607 604 otherosfs extra udftools_1.0.0b3-13.dsc 02a3fd66e50f0d75d3c3baec9f103d3a 386907 otherosfs extra udftools_1.0.0b3-13.diff.gz 3184a3eb902c10d1f29d15bfe7c30f1d 77920 otherosfs extra udftools_1.0.0b3-13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHUDOzeeb23IiDVPcRAqXpAJ9pyRRGSW95j9269FyAtfHawCZNyQCbBjx6 d52vGKU8MD0Y9Qbr2lmMdNw= =3fVa -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-13.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-13.diff.gz udftools_1.0.0b3-13.dsc to pool/main/u/udftools/udftools_1.0.0b3-13.dsc udftools_1.0.0b3-13_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hama-slide-mouse-control 1.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 12 Jul 2007 10:20:39 +0200 Source: hama-slide-mouse-control Binary: hama-slide-mouse-control Architecture: source i386 Version: 1.0-2 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: hama-slide-mouse-control - Control the DPI setting and thumb buttons of a Hama SLide S1 gami Closes: 432735 Changes: hama-slide-mouse-control (1.0-2) unstable; urgency=medium . * added missing build-dep on libusb-dev (Closes: #432735) Files: fe41cd3cdbda2a2b5dc4d55850944661 633 utils extra hama-slide-mouse-control_1.0-2.dsc 529d5bbea972ede577a9142cc0c6dfc1 2044 utils extra hama-slide-mouse-control_1.0-2.diff.gz 14c8da5583a6efa65adaf5a6bd887b9a 15012 utils extra hama-slide-mouse-control_1.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGl0tLeeb23IiDVPcRAn4+AJ4+8ldSKJIklzXhmuxz3qSFRcfp7QCeJlJ3 D3JJf/84QP474kc/kIS7ifI= =ZEsp -END PGP SIGNATURE- Accepted: hama-slide-mouse-control_1.0-2.diff.gz to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-2.diff.gz hama-slide-mouse-control_1.0-2.dsc to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-2.dsc hama-slide-mouse-control_1.0-2_i386.deb to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hama-slide-mouse-control 1.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Jun 2007 18:58:55 +0200 Source: hama-slide-mouse-control Binary: hama-slide-mouse-control Architecture: source i386 Version: 1.0-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: hama-slide-mouse-control - Control the DPI setting and thumb buttons of a Hama SLide S1 gami Changes: hama-slide-mouse-control (1.0-1) unstable; urgency=low . * Initial release Files: 8f99785df5d2e1683c8d2d00552ac93e 621 utils extra hama-slide-mouse-control_1.0-1.dsc b8bbff212e639f21b1159db4a3f19aea 16512 utils extra hama-slide-mouse-control_1.0.orig.tar.gz eab827c46620114dc14dde3b4c4e16a8 1972 utils extra hama-slide-mouse-control_1.0-1.diff.gz 15a188cf937b49ab4ab4dab4b803c104 14926 utils extra hama-slide-mouse-control_1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGftzyeeb23IiDVPcRAjrFAJ0QGpkqgK3XFnlWp+LMkoUkRUGm9QCfd+Fj fXLB2NBq6Lpf+ahnZXUzyiY= =bA9W -END PGP SIGNATURE- Accepted: hama-slide-mouse-control_1.0-1.diff.gz to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-1.diff.gz hama-slide-mouse-control_1.0-1.dsc to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-1.dsc hama-slide-mouse-control_1.0-1_i386.deb to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0-1_i386.deb hama-slide-mouse-control_1.0.orig.tar.gz to pool/main/h/hama-slide-mouse-control/hama-slide-mouse-control_1.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 10:11:55AM +0200, Stefano Zacchiroli wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? IMHO, a good test would be to build the package twice and then to compare whether the created .debs are identical between the first and second run. (Of course, file timestamps would have to be ignored when comparing.) Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-12 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Nov 2006 00:18:34 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-12 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 334212 335327 360527 369660 386962 Changes: udftools (1.0.0b3-12) unstable; urgency=low . * Fixed 'man mkudffs' typo: Versital. Closes: #335327 * Did not make the postinst create mount points or fstab entries, but documented the procedure in the README. Closes: #369660: Installation should create /media/cdrw0 and suggest /etc/fstab * Described procedure of formatting a disc for packet writing in the README.Debian. Closes: #360527: Serious lack of documentation * Correctly detect presence of udev by looking for /dev/.udev * Do not ask user whether to create devices. Closes: #386962 (Sorry, translators, templates removed. :-/ Closes: #334212 ) * Added a Suggests: dvd+rw-tools, pmount * Lintian: Fixed FSF address in copyright file, added LSB info to init script Files: 282ee774782b64569aafbcbaba259180 604 otherosfs extra udftools_1.0.0b3-12.dsc 769d0641199f617567cf5718856e57fb 342247 otherosfs extra udftools_1.0.0b3-12.diff.gz 88320802b812dfbe3f77b8c132dbc838 77974 otherosfs extra udftools_1.0.0b3-12_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFaKWXeeb23IiDVPcRAn02AJ9I6Gr8kqf5W+Fa12YyKJ61NAN+wACfU5+b HUaXq9a7B7lYYngfHjEaUqA= =MFWJ -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-12.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-12.diff.gz udftools_1.0.0b3-12.dsc to pool/main/u/udftools/udftools_1.0.0b3-12.dsc udftools_1.0.0b3-12_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-12_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote: Thank you for this very cool effort! Might we see checklib packaged for Debian soon? Hmm, maybe the functionality could be included in lintian? Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 19 May 2006 19:25:46 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.3-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager (beta version) jigdo-file - Download Debian CD images from any Debian mirror Closes: 320163 336487 342973 Changes: jigdo (0.7.3-1) unstable; urgency=low . * New upstream release * Removed build-dep on GCC 3.4, now builds with GCC 4.x. Closes: #342973 * Say in jigdo description that the package is in beta Closes: #320163: jigdo: Short description too vague * Build-depend on libdb4.4 Closes: #336487: jigdo: please switch to libdb4.3 Files: 13670c45042a221f1797f5813d0ad25b 631 utils extra jigdo_0.7.3-1.dsc c8debeb3c24e7ef2cecaec637eadf9f1 759157 utils extra jigdo_0.7.3.orig.tar.gz 38637c32b908f3a479861a3622ba26cb 4767 utils extra jigdo_0.7.3-1.diff.gz 762042420c0da12ba0bb27be3d595cee 192656 utils extra jigdo_0.7.3-1_i386.deb 53450def8fa12cf58e654d7b3e42be1b 210500 utils extra jigdo-file_0.7.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD4DBQFEbjbneeb23IiDVPcRAuLRAJ0Uihw4u8/Bm6pPh2eVpOvqe4tZdgCYtVXr WnX7QOy/0303A38qi0Ss+w== =87sV -END PGP SIGNATURE- Accepted: jigdo-file_0.7.3-1_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.3-1_i386.deb jigdo_0.7.3-1.diff.gz to pool/main/j/jigdo/jigdo_0.7.3-1.diff.gz jigdo_0.7.3-1.dsc to pool/main/j/jigdo/jigdo_0.7.3-1.dsc jigdo_0.7.3-1_i386.deb to pool/main/j/jigdo/jigdo_0.7.3-1_i386.deb jigdo_0.7.3.orig.tar.gz to pool/main/j/jigdo/jigdo_0.7.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
On Thu, Apr 27, 2006 at 01:30:17PM +0200, Andreas Barth wrote: I'd rather prefer if you don't overexegerate. Yes, please restrict yourself to the levels of exaggeration which are appropriate for Debian mailing lists. ;-) SCNR, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwww-doc 0.20060330 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Mar 2006 12:26:59 +0200 Source: libwww-doc Binary: libwww-doc Architecture: source all Version: 0.20060330 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-doc - The W3C WWW library - documentation Changes: libwww-doc (0.20060330) unstable; urgency=low . * _Really_ fixed section (doc, not devel)... Files: 2d23efcf7f0266209a7d77c78778b649 511 doc optional libwww-doc_0.20060330.dsc 6557d55ba11edc6fd6d2b6a5573c5ebc 472392 doc optional libwww-doc_0.20060330.tar.gz 455d920defa3d69c82c17d6afbf440d2 475514 doc optional libwww-doc_0.20060330_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEKmFVeeb23IiDVPcRAguBAKCkisWEc1sg5JDhInYCP5qvzymg8QCfUAxv Bs0YS4lvr0JOHVS3QtY6REc= =vS4M -END PGP SIGNATURE- Accepted: libwww-doc_0.20060330.dsc to pool/main/libw/libwww-doc/libwww-doc_0.20060330.dsc libwww-doc_0.20060330.tar.gz to pool/main/libw/libwww-doc/libwww-doc_0.20060330.tar.gz libwww-doc_0.20060330_all.deb to pool/main/libw/libwww-doc/libwww-doc_0.20060330_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwww-doc 0.20060328 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Mar 2006 10:57:40 +0200 Source: libwww-doc Binary: libwww-doc Architecture: source all Version: 0.20060328 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-doc - The W3C WWW library - documentation Closes: 359525 Changes: libwww-doc (0.20060328) unstable; urgency=low . * Rebuild: finish /usr/doc transition (Closes: #359525) Files: 5c8961a52f7db1e658a582062446f531 515 devel optional libwww-doc_0.20060328.dsc 4d1e6fdd71368d28cb9cb66ffb09b6d9 472415 devel optional libwww-doc_0.20060328.tar.gz 9a74758e252fda8a268cd40aa1d4d20f 475424 devel optional libwww-doc_0.20060328_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEKP7Jeeb23IiDVPcRAqA3AJ9bAyM+TFDA8xjMLuHts8qemaRzYQCgjfZ3 sjw8+Lz+BIVDlXoeF1QUtLw= =5tfZ -END PGP SIGNATURE- Accepted: libwww-doc_0.20060328.dsc to pool/main/libw/libwww-doc/libwww-doc_0.20060328.dsc libwww-doc_0.20060328.tar.gz to pool/main/libw/libwww-doc/libwww-doc_0.20060328.tar.gz libwww-doc_0.20060328_all.deb to pool/main/libw/libwww-doc/libwww-doc_0.20060328_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted btyacc 3.0-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Mar 2006 11:22:34 +0200 Source: btyacc Binary: btyacc Architecture: source i386 Version: 3.0-5 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: btyacc - Backtracking parser generator based on byacc Closes: 359373 Changes: btyacc (3.0-5) unstable; urgency=low . * Rebuild: finish /usr/doc transition (Closes: #359373) * Update debhelper compat and standards version Files: 2c0cb58a6eac53f698a306515eacc155 552 devel extra btyacc_3.0-5.dsc 1c8ec468118dcd401795362607452b5b 21783 devel extra btyacc_3.0-5.diff.gz 312d127a803491f7490eed4a0c8d4053 94110 devel extra btyacc_3.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEKQVDeeb23IiDVPcRAl+wAKCEFN1zlmCVMZYD7Gu2TwdXqVmSswCfeRtn V5UHPFTjevrPIJRHJgRGtGw= =vW6x -END PGP SIGNATURE- Accepted: btyacc_3.0-5.diff.gz to pool/main/b/btyacc/btyacc_3.0-5.diff.gz btyacc_3.0-5.dsc to pool/main/b/btyacc/btyacc_3.0-5.dsc btyacc_3.0-5_i386.deb to pool/main/b/btyacc/btyacc_3.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwww-doc 0.20060329 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Mar 2006 11:49:28 +0200 Source: libwww-doc Binary: libwww-doc Architecture: source all Version: 0.20060329 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-doc - The W3C WWW library - documentation Changes: libwww-doc (0.20060329) unstable; urgency=low . * Fixed section (doc, not devel) Files: de8356bf00ef202ee9a58d84cbb4dd41 511 doc optional libwww-doc_0.20060329.dsc 93793f4c8bd0a87a90db9b29f8f22cc5 472353 doc optional libwww-doc_0.20060329.tar.gz 161294c6883a26654bba55352be9673a 475470 devel optional libwww-doc_0.20060329_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEKQcKeeb23IiDVPcRAstGAKCN+u+1gVEeiA1wu9bAW7QCuQBswQCgo1Ea U3TCJiwrHVqEihvrpQWCiWo= =RVIa -END PGP SIGNATURE- Accepted: libwww-doc_0.20060329.dsc to pool/main/libw/libwww-doc/libwww-doc_0.20060329.dsc libwww-doc_0.20060329.tar.gz to pool/main/libw/libwww-doc/libwww-doc_0.20060329.tar.gz libwww-doc_0.20060329_all.deb to pool/main/libw/libwww-doc/libwww-doc_0.20060329_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to automatically update files on alioth from svn
On Tue, Nov 29, 2005 at 10:30:04PM +0100, Yann Dirson wrote: I have written a small post-commit hook for a somewhat different usage (the original problem was versionning the hooks themselves). I've been doing this for quite a while with a variety of SVN repos, with very different users and content. Here are a few things I've run into: - Ensure the correct locale setting is used, otherwise you'll run into trouble with non-ASCII filenames. For example, do export LANG=en_US if en_US defines the correct character set to use (UTF-8, ISO-8859-1, whatever...) For optimal results, svnserve should run with the same setting as the checkout script. ;-) - Use the --non-interactive switch for svn up. - Use svn cleanup if there is trouble during the svn up. A situation where this is necessary Should Not Happen (tm), but it surely has for me. :-/ - Do a fresh checkout if the destination dir does not contain a .svn subdirectory. (Of course you could do this manually, but with lots of repos it's very nice...) - Consider putting a line use-commit-times = yes into the ~/.subversion/config of the user that does the svn up. That way, checked-out files' timestamps will be those of their last change, not the time of the checkout. I like to use this for websites maintained in SVN - it allows you e.g. to create appropriate page last changed on .. messages. BTW, it's not necessary to add locking to the script, AFAIK runs of the postcommit script will be serialized by SVN (at least for my libdb repos, dunno about FSFS!). Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Oct 2005 23:26:11 +0200 Source: w3c-libwww Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0 Architecture: source i386 Version: 5.4.0-11 Distribution: unstable Urgency: high Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Closes: 334443 Changes: w3c-libwww (5.4.0-11) unstable; urgency=high . * Security fix for Library/src/HTBound.c, patch taken from Redhat's w3c-libwww-5.4.0-10.0.FC3.1.src.rpm, Redhat bug #159597 Closes: #334443: CAN-2005-3183: DoS through incorrect bounds checking in HTBoundary_put_block() Files: 3116cbd1214b9cbf2077bde53c55db5d 692 libs optional w3c-libwww_5.4.0-11.dsc 35e58941dbc3bf91ebbe2a4bd049c808 556804 libs optional w3c-libwww_5.4.0-11.diff.gz 86ae090547637c0ec729912042654104 446358 libs optional libwww0_5.4.0-11_i386.deb 784ef394760bddfe81108a8369853a8b 453490 libs optional libwww-ssl0_5.4.0-11_i386.deb 2ba1ef97852af5018dee7a9a3cd1ca96 633382 libdevel optional libwww-dev_5.4.0-11_i386.deb 3ca94616d5c525186cd48672ce8b3ea3 639870 libdevel optional libwww-ssl-dev_5.4.0-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDWrYBeeb23IiDVPcRAofEAJoDN/lWqgOHfZa05U4xMXOU7gWDngCdGWsj JW5pSoXZWn9MGwcjcZLH2Ok= =+1Eo -END PGP SIGNATURE- Accepted: libwww-dev_5.4.0-11_i386.deb to pool/main/w/w3c-libwww/libwww-dev_5.4.0-11_i386.deb libwww-ssl-dev_5.4.0-11_i386.deb to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-11_i386.deb libwww-ssl0_5.4.0-11_i386.deb to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-11_i386.deb libwww0_5.4.0-11_i386.deb to pool/main/w/w3c-libwww/libwww0_5.4.0-11_i386.deb w3c-libwww_5.4.0-11.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-11.diff.gz w3c-libwww_5.4.0-11.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-11.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 3 Oct 2005 14:11:50 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-11 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 288894 288896 300916 309572 331368 Changes: udftools (1.0.0b3-11) unstable; urgency=low . * Depend on debconf | debconf-2.0, cf. http://lists.debian.org/debian-devel/2005/08/msg00136.html * Updated FSF address in copyright file according to lintian message * Re-libtoolized for good measure * Clarified README.Debian. Closes: #288894 * Updated URL in manpage. Closes: #288896 * INTL:ru Russian debconf template translation. Closes: #300916 * Small manpage fix. Closes: #309572 * INTL:sv Swedish debconf templates translation. Closes: #331368 Files: a2161d54aea9c0e84280f15a35412994 604 otherosfs extra udftools_1.0.0b3-11.dsc 41940b1091f9ff31ba0111d619500585 345626 otherosfs extra udftools_1.0.0b3-11.diff.gz fe3824cdb17af093af92b0b8c5c30fb3 77148 otherosfs extra udftools_1.0.0b3-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDQTfYeeb23IiDVPcRAkKaAJsFbDFinTBStRkiJcqLUOPIKmorPQCfWMpI n1Cao6Z9CXZL8NG2mVto1AA= =V5i5 -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-11.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-11.diff.gz udftools_1.0.0b3-11.dsc to pool/main/u/udftools/udftools_1.0.0b3-11.dsc udftools_1.0.0b3-11_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-11_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-10 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 3 Oct 2005 16:46:17 +0200
Source: w3c-libwww
Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0
Architecture: source i386
Version: 5.4.0-10
Distribution: unstable
Urgency: low
Maintainer: Richard Atterer [EMAIL PROTECTED]
Changed-By: Richard Atterer [EMAIL PROTECTED]
Description:
libwww-dev - The W3C WWW library - development files
libwww-ssl-dev - The W3C WWW library - development files (SSL support)
libwww-ssl0 - The W3C-WWW library (SSL support)
libwww0- The W3C WWW library
Closes: 218394
Changes:
w3c-libwww (5.4.0-10) unstable; urgency=low
.
* Re-libtoolized with debian/rules bootstrap to make package buildable
with current unstable.
Closes: #218394: libwww0: please update libtool (and config.{guess,
sub}) for GNU/KFreeBSD port
Files:
f177151b92405639cb8fb153209c15ee 692 libs optional w3c-libwww_5.4.0-10.dsc
91fbf8474bd8217260f2d38a8d6b949a 555669 libs optional
w3c-libwww_5.4.0-10.diff.gz
1f3b28150d375b04753e6575c22bed34 444822 libs optional libwww0_5.4.0-10_i386.deb
4bdca493cf03c0336c4997453bad8fcf 451892 libs optional
libwww-ssl0_5.4.0-10_i386.deb
20c422d60ba599a3522c82838236e261 631998 libdevel optional
libwww-dev_5.4.0-10_i386.deb
441c57ea7deef7286ba3e8a7b671b24d 638586 libdevel optional
libwww-ssl-dev_5.4.0-10_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDQU/Yeeb23IiDVPcRAq7aAJ4kIKTJUedqRpVhbp8HVczdtn2PdwCfVjLv
DgL0sEiXDMsC6yv5Ze9EGSM=
=8lxJ
-END PGP SIGNATURE-
Accepted:
libwww-dev_5.4.0-10_i386.deb
to pool/main/w/w3c-libwww/libwww-dev_5.4.0-10_i386.deb
libwww-ssl-dev_5.4.0-10_i386.deb
to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-10_i386.deb
libwww-ssl0_5.4.0-10_i386.deb
to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-10_i386.deb
libwww0_5.4.0-10_i386.deb
to pool/main/w/w3c-libwww/libwww0_5.4.0-10_i386.deb
w3c-libwww_5.4.0-10.diff.gz
to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-10.diff.gz
w3c-libwww_5.4.0-10.dsc
to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-10.dsc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl status update
On Thu, Sep 29, 2005 at 03:19:18PM -0700, Steve Langasek wrote: On Thu, Sep 29, 2005 at 03:27:30PM +0200, Richard Atterer wrote: On Thu, Sep 29, 2005 at 02:37:35PM +0200, Marco d'Itri wrote: Why is openssl the default? I think everybody agrees that in the long period everybody will want to use gnutls, No, as has been shown by the discussions in the last weeks, there is *no* agreement on which SSL library should be the default. There isn't? I saw some arguments that explain why it's not possible to convert all curl-using applications from OpenSSL to GNUTLS without a recompile due to unavailable ABI changes, but I thought it was pretty clear that the default going forward should be the one whose license is maximally compatible with that of applications using libcurl (i.e., GNUTLS). Yes - I should clarify what I said: _In_the_long_run_ the agreed goal was to move to GnuTLS. However, above Marco asked why the _current_ default isn't GnuTLS. I'm not so sure whether it should be: Upstream's choice will remain OpenSSL for the foreseeable future, GnuTLS is allegedly still slightly more buggy than OpenSSL (does anyone have any details?) and is lacking some features. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl status update
On Thu, Sep 29, 2005 at 02:37:35PM +0200, Marco d'Itri wrote: Why is openssl the default? I think everybody agrees that in the long period everybody will want to use gnutls, No, as has been shown by the discussions in the last weeks, there is *no* agreement on which SSL library should be the default. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote: Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? From the adduser/addgroup manpage: If the file /usr/local/sbin/adduser.local exists, it will be executed after the user account has been set up in order to do any local setup. The arguments passed to adduser.local are: username uid gid home-directory, and the environment variables DEBUG and VERBOSE will be set according to the settings in the master program. You can use this to execute the same adduser/addgroup command in the chroot. While this doesn't guarantee that the different files are 100% in sync, I think it'll get close enough for practical usage. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. I am rather swamped with lots of other things. Daniel (curl upstream) sounds like he will accept a patch to implement this, but he will probably not do any work on this himself. Also see http://curl.haxx.se/mail/lib-2005-09/0066.html, a first, very incomplete patch by me. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Mon, Sep 12, 2005 at 02:05:23PM +0200, Marco d'Itri wrote: On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote: Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. I do not believe that it's worth the effort, there are no really good reasons to use OpenSSL in the long time. Development effort should be focused on fixing any eventual gnutls bugs (either in the library itself or in the libcurl glue). Well, how much is in the long run? It could be years. Furthermore, OpenSSL is simply much more popular, plus it will stay the primary SSL implementation for curl upstream for the foreseeable future. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
Just fix the program that generates our HTML mailing list archives, and make it output meta name=robots content=noindex for mails which contain any of the Forbidden Words! Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libcurl and moc
FWIW, I've started work on implementing the solution outlined in http://curl.haxx.se/legal/distro-dilemma.html. However, my spare time is very limited, so I can't promise anything about when (or even whether) I can finish this. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libcurl and moc
On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote: But no one has yet answered my question: *why* are there ABI differences between the gnutls and openssl builds? To the best of my knowledge (I could be wrong), ATM the only ABI difference is that when OpenSSL is used, curl_easy_setopt(handle, CURLOPT_SSL_CTX_FUNCTION, param) is supported. That CURLOPT_SSL_CTX_FUNCTION code cannot be supported if GnuTLS is used because GnuTLS does not offer comparable functionality. param above is a pointer to an OpenSSL SSL_CTX struct. According to the curl_easy_setopt manpage: This function gets called by libcurl just before the initialization of an SSL connection after having processed all other SSL related options to give a last chance to an application to modify the behaviour of openssl's ssl initialization. IMHO this incompatibility is quite minor - very few programs will actually register that callback. However, Daniel (curl upstream) believes it possible that future versions of the library will provide other SSL-related hooks of this sort. On Sat, Sep 03, 2005 at 12:47:06AM +1000, Paul TBBle Hampson wrote: If I've understood correctly, it is because curl expects the client program or library to -lgnutls or -lopenssl and therefore provide the SSL symbols to match the symbols which that build of the .so file is expecting. This is the point I move from suggesting things to spectating, 'cause I can't wrap my head above the reason for the above. No, you're mixing things up. I believe you're talking about what is described towards the end of http://curl.haxx.se/legal/distro-dilemma.html. Whenever libcurl switches to the described mechanism, then _at_that_moment_ it might be necessary to increase the .so version. That's because programs are then required to link explicitly against one of the SSL-enabling backend libs, called lib2 on the page above. You don't suddenly want your old libcurl3-using programs to fail with run-time link errors... HTH, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: long long support on all archs?
On Tue, Aug 30, 2005 at 01:25:09PM +0200, Ondrej Sury wrote: does all archs in debian have support for long long datatype? Yes, AFAIK, but... I want to apply 64bit quotas for cyrus22-imapd and I have to choose between patch which has checks for long long support and patch which doesn't have this check and use long long by default. ...I recommend you use int64_t from stdint.h instead of long long, this is more portable. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results of the meeting in Helsinki about the Vancouver proposal
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote: Currently, sponsored packages are only signed, not built, by official Debian Developers. Ahem, no! As the sponsor, you should rebuild the package from source using the diff from the packager, and using the upstream sources, not the sources provided by the packager. See this page: http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-sponsoring Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 21 Aug 2005 21:33:03 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-10 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 323952 Changes: udftools (1.0.0b3-10) unstable; urgency=low . * INTL:vi Vietnamese translation for udftools (Closes: #323952) Files: 764b32fbaa4d980e25965831e516a38c 603 otherosfs extra udftools_1.0.0b3-10.dsc 285e002035a39c7ec929b7ffc8bfc720 14541 otherosfs extra udftools_1.0.0b3-10.diff.gz 6b7a8cb843c18324c9c17563a3c820f8 76590 otherosfs extra udftools_1.0.0b3-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCNfHeeb23IiDVPcRAvVmAJwLBrSkQyc0WuyWBBBlojiknYoXYwCePmsX cdg9wkqaYHrHEut/fLpX8lc= =nvyC -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-10.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-10.diff.gz udftools_1.0.0b3-10.dsc to pool/main/u/udftools/udftools_1.0.0b3-10.dsc udftools_1.0.0b3-10_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xprobe 0.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 Aug 2005 13:43:07 +0200 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.3-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.3-1) unstable; urgency=low . * New upstream version Files: 5049bb5a6d787b5406ee698a3552b77c 574 net extra xprobe_0.3-1.dsc 3ebb89ed9380038d368327816e34ec54 533636 net extra xprobe_0.3.orig.tar.gz 5408a8a9eeec0d48e57a5cbdc6f18b68 3446 net extra xprobe_0.3-1.diff.gz 4a7bc0fd193f266c7ee452cfd7418483 396068 net extra xprobe_0.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAyQGeeb23IiDVPcRAmKLAJ47ipFh/fQDIf511ItHjdtVwz4eBQCeKZgj U+rv8vDr67Gd5PR+6PTVkV4= =jdY5 -END PGP SIGNATURE- Accepted: xprobe_0.3-1.diff.gz to pool/main/x/xprobe/xprobe_0.3-1.diff.gz xprobe_0.3-1.dsc to pool/main/x/xprobe/xprobe_0.3-1.dsc xprobe_0.3-1_i386.deb to pool/main/x/xprobe/xprobe_0.3-1_i386.deb xprobe_0.3.orig.tar.gz to pool/main/x/xprobe/xprobe_0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.2-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 21 Jul 2005 13:35:38 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.2-2 Distribution: unstable Urgency: high Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager jigdo-file - Download Debian CD images from any Debian mirror Closes: 319327 Changes: jigdo (0.7.2-2) unstable; urgency=high . * High-urgency upload for RC bugfix. * Closes: #319327: jigdo_0.7.2-1: FTBFS (alpha/unstable): C++ prototype mismatch on 64-bit systems Thanks to Steve Langasek for the good work. * Build with gcc-3.4, not 4.0 due to problems on some arches (see #319327) Files: 1e170d168dcb4326c0c7ca9f198281d4 683 utils extra jigdo_0.7.2-2.dsc e5ca2ea98bbdc479375e21ac02ac6132 5003 utils extra jigdo_0.7.2-2.diff.gz 279af6a738b97096e58e083fcf8325c3 211824 utils extra jigdo_0.7.2-2_i386.deb 12a45b8eb028366087dd8b1bd1895002 233860 utils extra jigdo-file_0.7.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC34treeb23IiDVPcRAsTjAJ9ZoVlvbDJ21I8VfBMMXRjK+dzAOACfX5fI sFFHX3Ww3BOU+X0HathACrQ= =x7Qt -END PGP SIGNATURE- Accepted: jigdo-file_0.7.2-2_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.2-2_i386.deb jigdo_0.7.2-2.diff.gz to pool/main/j/jigdo/jigdo_0.7.2-2.diff.gz jigdo_0.7.2-2.dsc to pool/main/j/jigdo/jigdo_0.7.2-2.dsc jigdo_0.7.2-2_i386.deb to pool/main/j/jigdo/jigdo_0.7.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 6 Jul 2005 15:18:36 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.2-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager jigdo-file - Download Debian CD images from any Debian mirror Closes: 242729 292573 310881 314028 Changes: jigdo (0.7.2-1) unstable; urgency=low . * New upstream release * Fixed de.po file Closes: #314028: [INTL:de] German PO file corrections * Closes: #292573: jigdo-file: Bad format string in error message * Correctly deal with copy: URLs when reading /etc/apt/sources.list Closes: #310881: jigdo-lite doesn't know copy:// urls * Added support for --noask switch to jigdo-lite Closes: #242729: jigdo-lite always asks for mirror Files: 4921f8264256c0b0d97b32de99e4837a 674 utils extra jigdo_0.7.2-1.dsc ca9429076b095e69f55801e3240082c1 757204 utils extra jigdo_0.7.2.orig.tar.gz c370c10fd18ddaa1e515bc98050d7427 4502 utils extra jigdo_0.7.2-1.diff.gz 03d4b412a24e81c300797f2438aaeac4 205764 utils extra jigdo_0.7.2-1_i386.deb d8806ede548f3da6fb4c174feac2988b 229674 utils extra jigdo-file_0.7.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1mWqeeb23IiDVPcRAsooAJ9cpY6fvP6oAv7OPu6feyFHvZGOCgCfa/7i TH5n3l5spkMw/hSOF/ccd3w= =hxY8 -END PGP SIGNATURE- Accepted: jigdo-file_0.7.2-1_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.2-1_i386.deb jigdo_0.7.2-1.diff.gz to pool/main/j/jigdo/jigdo_0.7.2-1.diff.gz jigdo_0.7.2-1.dsc to pool/main/j/jigdo/jigdo_0.7.2-1.dsc jigdo_0.7.2-1_i386.deb to pool/main/j/jigdo/jigdo_0.7.2-1_i386.deb jigdo_0.7.2.orig.tar.gz to pool/main/j/jigdo/jigdo_0.7.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] TeX font of Debian Logo?
On Thu, Jul 07, 2005 at 03:46:20PM +0200, Andreas Tille wrote: Does anybody know whether there is a TeX font which is equal or at least very similar to the font used in our Logo I've never seen a Debian-ish TeX font. Do you only need the Debian logo in your TeX document? Then a far more promising plan is to embed the PostScript version of the logo as a picture. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD Pages
On Wed, Jun 29, 2005 at 02:23:58PM -0500, David Moreno Garza wrote: On Thu, 2005-05-26 at 08:29 +0200, Raphael Hertzog wrote: I've noticed that http://www.debian.org/distrib/cd/ and http://www.debian.org/CD/ are basically the same. /CD/ has more information than /distrib/cd/, so perhaps it would be best to make /distrib/cd/ redirect to /CD/ ? IMO you can safely replace /distrib/cd by a redirect to /CD/. In that case, you'd better also directly change the link on the left block of the front page... Isn't there any further discussion for this? I'm making the change unless somebody comes up with something different about it. I'm all for this change - when I created /CD/, it was intended to be linked directly from the front page, and in fact, it was set up like this for a while. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote: Looking at the bug log, it seems that you had no business increasing the severity in the first place. You didn't report the bug, you [...] So now just people who are affected by bugs are allowed to report them? And it's also forbidden to go through the list of open bugs and attempt to alert developers of important issues by raising the severity (if necessary)? While I have no opinion regarding the bug being discussed here, I believe that those few people who take the time to go through open bugs often do very valuable work, e.g. by identifying upgrade bugs which are waiting to happen the moment we release. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xprobe 0.2.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 22:54:24 +0100 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2.2-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.2.2-1) unstable; urgency=low . * New upstream version Files: b899763a48778ca812a11d46480c6b98 580 net extra xprobe_0.2.2-1.dsc 8eea1406d035827bb8bfeb0536622e1f 521785 net extra xprobe_0.2.2.orig.tar.gz 979ff0a5550e6ebbd40f9148e0dd5161 3430 net extra xprobe_0.2.2-1.diff.gz 4f0cad7ec9e9737b44801e73624c683d 361928 net extra xprobe_0.2.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD4DBQFCG60reeb23IiDVPcRAo7wAJME/4BflIv4mmOJNyEHz3Bvjc72AJ0QUlLe o1Jcin89B/Ik3TxZZ1Xp7Q== =G7eS -END PGP SIGNATURE- Accepted: xprobe_0.2.2-1.diff.gz to pool/main/x/xprobe/xprobe_0.2.2-1.diff.gz xprobe_0.2.2-1.dsc to pool/main/x/xprobe/xprobe_0.2.2-1.dsc xprobe_0.2.2-1_i386.deb to pool/main/x/xprobe/xprobe_0.2.2-1_i386.deb xprobe_0.2.2.orig.tar.gz to pool/main/x/xprobe/xprobe_0.2.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#288497: ITP: libsnowball-swedish-perl -- Stemming algorithm for Swedish
On Tue, Jan 04, 2005 at 01:07:42PM +, Dominic Hargreaves wrote: I can see that this is suboptimal. Given that this is how the modules are distributed upstream ie. individually, how should I avoid this? Would it be acceptable to package them all as one debian package somehow, and thus lose the transparency that orig.tar.gz brings? Or is there some other solution to this that I haven't spotted? I agree, the code should come in one big package. I have no idea how the Perl policy handles this case, though. You should check whether the big package needs to Provide: libsnowball-swedish-perl for all languages. If it is important for you that the original tarballs are preserved, you can put them inside an orig.tar.gz that you make. The tar.gz-inside-tar.gz approach looks a bit unclean, though... at the end of the day, this decision is up to you as the maintainer, the package pool contains examples of both re-tarred sources and tar.gz-inside-tar.gz. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted udftools 1.0.0b3-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 21:40:19 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-9 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - tools for UDF filesystems and DVD/CD-R(W) drives Closes: 288621 Changes: udftools (1.0.0b3-9) unstable; urgency=medium . * Switched from libreadline4-dev to libreadline5-dev in build-deps * Applied patch by Andreas Jochens Closes: #288621: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment Files: 312d9a6bd7bc9f6bf275044d4ee84987 601 otherosfs extra udftools_1.0.0b3-9.dsc 4cbb9d5dbea62c54681644890c190b94 14017 otherosfs extra udftools_1.0.0b3-9.diff.gz a89afd0ae2a5415687c744ca585c0aa2 72208 otherosfs extra udftools_1.0.0b3-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2wNLeeb23IiDVPcRAv2uAKCfZBdNUh6ZCOlUJC4wiKQJvc/fPwCfRUX9 SUDHBEeNhsJHxQ2VSRg0tbY= =TwQN -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-9.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-9.diff.gz udftools_1.0.0b3-9.dsc to pool/main/u/udftools/udftools_1.0.0b3-9.dsc udftools_1.0.0b3-9_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 27 Dec 2004 15:16:57 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-8 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 287303 Changes: udftools (1.0.0b3-8) unstable; urgency=medium . * Added Czech debconf translation by Miroslav Kure - thanks! Closes: #287303 Files: 0f25bd23726087b11bf383f907fa3d82 609 otherosfs extra udftools_1.0.0b3-8.dsc 1fbddf214b4a98404588b202eef6f01b 13279 otherosfs extra udftools_1.0.0b3-8.diff.gz 99a330c50f029aaab300d0fbf3ca7f7d 76736 otherosfs extra udftools_1.0.0b3-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB0Bq0eeb23IiDVPcRArxJAJ4uv2QNdwzcdroRwBKFdCw7uP3f0gCeP7hD Bt/pn3djPNfdE7XX9fS0cls= =Ps3F -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-8.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-8.diff.gz udftools_1.0.0b3-8.dsc to pool/main/u/udftools/udftools_1.0.0b3-8.dsc udftools_1.0.0b3-8_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xprobe 0.2.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 26 Dec 2004 13:22:45 +0100 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2.1-3 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.2.1-3) unstable; urgency=low . * Also re-libtoolized libs-external/USI++/src Files: 75abea5c207c2ffdc84e9fa3a457cf27 581 net extra xprobe_0.2.1-3.dsc a619169144fdf6ee958b7f9e7a2364ba 63952 net extra xprobe_0.2.1-3.diff.gz 4e094b5a1424d6a6712fd9c7cd99e131 341102 net extra xprobe_0.2.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBzrhQeeb23IiDVPcRAn2IAKCJHK+JnHgC41Nb/q0FP1l0w4jtXwCcDIlJ AFD9gLA1ol0fwmq/CuZnQto= =HGOR -END PGP SIGNATURE- Accepted: xprobe_0.2.1-3.diff.gz to pool/main/x/xprobe/xprobe_0.2.1-3.diff.gz xprobe_0.2.1-3.dsc to pool/main/x/xprobe/xprobe_0.2.1-3.dsc xprobe_0.2.1-3_i386.deb to pool/main/x/xprobe/xprobe_0.2.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xprobe 0.2.1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Dec 2004 14:07:03 +0100 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2.1-2 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.2.1-2) unstable; urgency=low . * Re-libtoolized to fix build problem on mipsel (*sigh*, upstream keeps forgetting about this.) Files: f770ac223c4a9456dc002fdea02f4f68 581 net extra xprobe_0.2.1-2.dsc 2624492521d4e6aa573366ed184a0851 61708 net extra xprobe_0.2.1-2.diff.gz 4befef32328a92634f072e250aaf256e 341074 net extra xprobe_0.2.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBzBUzeeb23IiDVPcRAhQSAJwNHePxgQNYWIqnnJ4C0+yPydJmvACfTyJf OSyxs3OPHdbpFiAz8rpHvUY= =kjUg -END PGP SIGNATURE- Accepted: xprobe_0.2.1-2.diff.gz to pool/main/x/xprobe/xprobe_0.2.1-2.diff.gz xprobe_0.2.1-2.dsc to pool/main/x/xprobe/xprobe_0.2.1-2.dsc xprobe_0.2.1-2_i386.deb to pool/main/x/xprobe/xprobe_0.2.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xprobe 0.2.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Dec 2004 19:38:12 +0100 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2.1-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.2.1-1) unstable; urgency=low . * New upstream version Files: c1e0b16a733afb994241c20d6842473f 580 net extra xprobe_0.2.1-1.dsc aaddb4bf793ef573b7fb43ee91bb2224 481766 net extra xprobe_0.2.1.orig.tar.gz 6264ac6b754f112968affc1ba0cd1e56 3015 net extra xprobe_0.2.1-1.diff.gz 64c7cdba90eb8cd5247d4ecb74969dc0 341020 net extra xprobe_0.2.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFByyM9eeb23IiDVPcRAg1YAJ43g3bzxnXx/dQqzPqO0bq90dB0wwCcDED2 VMf+77GCZE2BS79NjbVZA1M= =mk73 -END PGP SIGNATURE- Accepted: xprobe_0.2.1-1.diff.gz to pool/main/x/xprobe/xprobe_0.2.1-1.diff.gz xprobe_0.2.1-1.dsc to pool/main/x/xprobe/xprobe_0.2.1-1.dsc xprobe_0.2.1-1_i386.deb to pool/main/x/xprobe/xprobe_0.2.1-1_i386.deb xprobe_0.2.1.orig.tar.gz to pool/main/x/xprobe/xprobe_0.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 12 Dec 2004 16:41:41 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-7 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 285311 Changes: udftools (1.0.0b3-7) unstable; urgency=medium . * Applied patch by Christoph Hellwig - thanks! Closes: #285311: mkudffs fails on big-endian systems * Updated to Standards-Version 3.6.1 Files: 76961b469dce5b24157537e784e68f66 609 otherosfs extra udftools_1.0.0b3-7.dsc cb1f9a6fd809fbd1c43b5214e51e66fb 12990 otherosfs extra udftools_1.0.0b3-7.diff.gz d48792712858aca302f0a2568401cfee 71894 otherosfs extra udftools_1.0.0b3-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBvHV9eeb23IiDVPcRAmLrAJ43vXGXByaETCufGSO+GIfP1F/j9QCgrMFp sd5qaxiyheA7yJB2fV5YgLY= =qbRt -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-7.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-7.diff.gz udftools_1.0.0b3-7.dsc to pool/main/u/udftools/udftools_1.0.0b3-7.dsc udftools_1.0.0b3-7_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: charsets in debian/control
On Tue, Dec 07, 2004 at 10:17:17AM -0500, Daniel Burrows wrote: On Tuesday 07 December 2004 12:44 am, Peter Samuelson wrote: And if the app already deals with charset conversions but assumes iso-8859-1 input, then it's trivial to fix it to assume utf-8 input. This is not true. iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset. Storing and manipulating iso-8859-1 strings requires no changes to internal datatypes (only conversions for input and output); storing and manipulating Unicode means you have to switch to a completely different set of string-handling functions for all internal operations. No, you do not have to do this. You can keep working with char, the changes when switching to UTF-8 will mostly have to deal with the fact that one Unicode character is represented by more than one char. This means that you need to use a different strlen function, take care only to chop strings of char at character boundaries, ensure that input strings are actually valid UTF-8, etc. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted udftools 1.0.0b3-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 1 Nov 2004 14:42:41 +0100 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-6 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 274489 278696 Changes: udftools (1.0.0b3-6) unstable; urgency=medium . * Applied patch by Christopher Martin (thanks!) Closes: #278696: udftools scripts need overhaul to work with all kernels * Closes: #274489: udftools: Mistakes in README.Debian Files: 44fa9e691043c44da4229654119e4eef 609 otherosfs extra udftools_1.0.0b3-6.dsc 2f77f564919d4cdb61aacff0bae5c6dd 12317 otherosfs extra udftools_1.0.0b3-6.diff.gz 047a7962ea7d02af99a3a27a368d284a 71844 otherosfs extra udftools_1.0.0b3-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBhkiueeb23IiDVPcRAhAKAJ9bB9nrlyKsqF+lbwF7vh2JBDyzrQCcDNnp QEat9wtq0/Hy+v9UOQiFF+c= =Q5l1 -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-6.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-6.diff.gz udftools_1.0.0b3-6.dsc to pool/main/u/udftools/udftools_1.0.0b3-6.dsc udftools_1.0.0b3-6_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Content of CDs / DVDs
Hello, /me puts jigdo author hat on. On Wed, Oct 20, 2004 at 06:38:07PM -0500, Matthew Dempsky wrote: Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: Of course! Now I can't believe I didn't think about jigdo first... probably because I'm not very familiar with it. Assuming that it allows to create custom isos then it's great for this purpose. In fact alongside picking up custom packages we could create some predefined (maybe based on the popularity) templates. Anyone willing to work on it? Maybe some Alioth project? I'm not DD yet so someone else would be forced to create such project. But I would like to contribute in such addition to project. How difficult is it to generate jigdo templates on the fly? It sounds like a fun project if that's not too difficult a task. It's not /that/ easy, because the .template includes a md5 checksum for the entire image, and also other, per-file checksums. This means that during the on-the-fly generation, all the file data needs to be read into memory to calculate the checksum, so creating the .template will take quite a while. (Of course, at the expense of outputting images with a wrong (i.e. zero) image md5sum, you can go faster...) Look at Steve McIntyre's JTE project http://www.einval.com/~steve/software/JTE/ for something very much like this. As of 2 weeks ago, JTE is used to produce the weekly CD/DVD images. All in all, IMHO generating per-user images on the fly is not really feasible. However, I think it might make sense to offer several variant CD compilations, a bit like the Home, Professional and Server variants of other Linux distros. OTOH, offering such variants will increase the number of available Debian images yet again. We already offer images for different arches, different sizes (business-card/netinst/CD/DVD/DLDVD) and different distributions (sid/sarge/woody), the total number of images is getting truly confusing, especially for people new to Debian. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: Content of CDs / DVDs
On Thu, Oct 21, 2004 at 06:21:24PM +0800, Cameron Patrick wrote: Would it be more feasible if all of the intelligence was on the client side? The client could slurp down a Packages file, work out which packages to include and split them into CD-sized chunks, download the debs from a mirror somewhere, then fetch the installer and whatever else is necessary to make the CD usable. It'd be like jigdo, but taken one stage further. That would be possible, but it wasn't a design goal for jigdo. With jigdo, I wanted to create bit-exact copies of officially released images. Once you start executing mkisofs on the user's machine, this becomes difficult to achieve, so jigdo leaves creating the iso9660 filesystem to other tools. Have a look at the debian-cd scripts and imagine doing all this on the user's machine - not trivial! Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: If you'd be so kind as to refer to #274993, I think we have a problem. A number of packages (see the bug report) depend on spamassassin, but some are not going to work with version 3, which changed the API considerably. The example here is spamass-milter, which simply does not work. IMHO the easiest solution is to introduce a spamassassin2 package which conflicts with the spamassassin package, and to have spamass-milter and friends depend on spamassassin2. Actually fixing the programs to use the 3.0 API can then happen as a subsequent step - and if it doesn't happen by release time, we still have spamassassin 3 in stable... Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted xprobe 0.2rc1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 21 Aug 2004 19:53:07 +0200 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2rc1-2 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Closes: 264866 Changes: xprobe (0.2rc1-2) unstable; urgency=medium . * Change compiler flags to compile without optimization Closes: #264866: FTBFS: g++ internal compiler error: Segmentation fault Files: 68d5a6b77dd2fd68023bb5de59a3d7ce 584 net extra xprobe_0.2rc1-2.dsc 57180a44c24e577427f8d8dc09e045f7 89895 net extra xprobe_0.2rc1-2.diff.gz 776e14c3b72d7d6997bdc4838db04e87 342456 net extra xprobe_0.2rc1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBJ42Jeeb23IiDVPcRAgfKAJ9RouqYrF0M1ACeRL0su32lsIe0TwCcCa9Q 9iQKq3UG0luMyI2W0YwCjbA= =x2kX -END PGP SIGNATURE- Accepted: xprobe_0.2rc1-2.diff.gz to pool/main/x/xprobe/xprobe_0.2rc1-2.diff.gz xprobe_0.2rc1-2.dsc to pool/main/x/xprobe/xprobe_0.2rc1-2.dsc xprobe_0.2rc1-2_i386.deb to pool/main/x/xprobe/xprobe_0.2rc1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 15 Aug 2004 21:21:38 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-5 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 245801 Changes: udftools (1.0.0b3-5) unstable; urgency=medium . * Incorporate patch by Peter Osterlund, http://w1.894.telia.com/~u89404340/ Changed init.d script to deal with new features of the code. Closes: #245801: can't use pktsetup * Updated docs: Need kernel 2.6.8+ or extra kernel patch Files: c0d169e300213da5548116373d4be844 609 otherosfs extra udftools_1.0.0b3-5.dsc d226a40e8d24200b14850143c4eadb14 11896 otherosfs extra udftools_1.0.0b3-5.diff.gz cad2d59bf6d3c5ac177cea7b7ee36980 71556 otherosfs extra udftools_1.0.0b3-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBIJoaeeb23IiDVPcRAjjdAJ0QOJuums2lbXqRkaNbZzjLGY0vSwCfTt01 ydk44UhumCbTXuumZe/kihY= =xw0Q -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-5.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-5.diff.gz udftools_1.0.0b3-5.dsc to pool/main/u/udftools/udftools_1.0.0b3-5.dsc udftools_1.0.0b3-5_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.1-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Jul 2004 17:09:30 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.1-5 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager jigdo-file - Download Debian CD images from any Debian mirror Closes: 221375 Changes: jigdo (0.7.1-5) unstable; urgency=low . * Added build-depends on GCC 3.4, use it for compilation Closes: #221375: jigdo should be compiled with g++-3.3 to undergo c102 transition. Files: 506abe494b8ac9942896e6d00c6f5785 662 utils extra jigdo_0.7.1-5.dsc a9c846934d8f2713f056a5439c70b706 6638 utils extra jigdo_0.7.1-5.diff.gz 43c016fc0cc06ec5c694f290281855b1 233108 utils extra jigdo_0.7.1-5_i386.deb e4c2f258ae23bbf081c0e92b85b0bb8e 223960 utils extra jigdo-file_0.7.1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBC7d6eeb23IiDVPcRAilgAKCm/OlWYD6+0WBrvjjijkQs+fYqAQCgnoBE TPY90wVesxThQMyBJ3zaH6o= =+fgr -END PGP SIGNATURE- Accepted: jigdo-file_0.7.1-5_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.1-5_i386.deb jigdo_0.7.1-5.diff.gz to pool/main/j/jigdo/jigdo_0.7.1-5.diff.gz jigdo_0.7.1-5.dsc to pool/main/j/jigdo/jigdo_0.7.1-5.dsc jigdo_0.7.1-5_i386.deb to pool/main/j/jigdo/jigdo_0.7.1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Jul 2004 23:33:35 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-4 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 258492 Changes: udftools (1.0.0b3-4) unstable; urgency=low . * Today is intl minor bug submitter day, it seems ;-P Applied patch to change scripts: test x test y, not test x -a y Closes: #258492: XSI:ism in debian/config (and upstream deb-dir) Files: 56ae9ad28fecc7bf3f1f2f499c69aeeb 601 otherosfs extra udftools_1.0.0b3-4.dsc efcf309a2f451678e8737882073e2db2 7900 otherosfs extra udftools_1.0.0b3-4.diff.gz 309aacc43a3ac694850f66cb6506348f 68742 otherosfs extra udftools_1.0.0b3-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7xCkeeb23IiDVPcRAjNRAKCO6HrOPLamLXjAuBQJEO2+J99EvQCfd2a7 MRLM1qPbJTEW39YpZmXEmhg= =Gqrz -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-4.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-4.diff.gz udftools_1.0.0b3-4.dsc to pool/main/u/udftools/udftools_1.0.0b3-4.dsc udftools_1.0.0b3-4_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Jul 2004 21:11:01 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-3 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 258447 Changes: udftools (1.0.0b3-3) unstable; urgency=low . * Added in README.Debian: Extra kernel patch required for pktsetup * Removed upstream changelog %-| Closes: #258447: stale upstream changelog Files: 741a6e6790a897775934317347ec66c4 601 otherosfs extra udftools_1.0.0b3-3.dsc d62fe4e4e321584ac402b34ea5af797e 7472 otherosfs extra udftools_1.0.0b3-3.diff.gz ef6839a16bd218bc13bc21c17aba43f1 68614 otherosfs extra udftools_1.0.0b3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7vSEeeb23IiDVPcRAgBZAKCfcLwwqa0QFEimesDvJpz4MIHaCACfYZga RodS/1X1N4yplhZvv5ExxX8= =5AmQ -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-3.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-3.diff.gz udftools_1.0.0b3-3.dsc to pool/main/u/udftools/udftools_1.0.0b3-3.dsc udftools_1.0.0b3-3_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 5 Jul 2004 15:45:21 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.1-4 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager jigdo-file - Download Debian CD images from any Debian mirror Closes: 257646 Changes: jigdo (0.7.1-4) unstable; urgency=low . * jigdo-file: Bugfix for the code which deduces missing --image/ --jigdo/--template arguments. Broken in 0.7.1, would deduce /x.iso.template from /x.iso, instead of /x.template (Adrian Bunk) Closes: #257646: output file name changes broke scripts Files: 88a8b96d14648f60d65f1e99482bf7f4 644 utils extra jigdo_0.7.1-4.dsc 189ae070dffc4e9c329380303f4a54c1 5134 utils extra jigdo_0.7.1-4.diff.gz 9d5f9fdc5b35deccbf8c267d1ec6867b 231348 utils extra jigdo_0.7.1-4_i386.deb 484edd2b3df89a8e8a839d839418d608 224878 utils extra jigdo-file_0.7.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6VyHeeb23IiDVPcRArFuAJ0cXZrkhgy0N/74YZvRCFuB1G8WjACfWtBr 3ixXu+e0j0eWMgfuQr/OnpY= =pPof -END PGP SIGNATURE- Accepted: jigdo-file_0.7.1-4_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.1-4_i386.deb jigdo_0.7.1-4.diff.gz to pool/main/j/jigdo/jigdo_0.7.1-4.diff.gz jigdo_0.7.1-4.dsc to pool/main/j/jigdo/jigdo_0.7.1-4.dsc jigdo_0.7.1-4_i386.deb to pool/main/j/jigdo/jigdo_0.7.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.7.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Jun 2004 15:26:36 +0200 Source: jigdo Binary: jigdo jigdo-file Architecture: source i386 Version: 0.7.1-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo - GTK+ download manager jigdo-file - Download Debian CD images from any Debian mirror Closes: 192275 205740 223786 248489 Changes: jigdo (0.7.1-1) unstable; urgency=low . * New upstream release * Fixes segfaults due to big local vars on stack, closes: #192275 * jigdo-lite: Fix interpretation of jigdo-file return code, closes: #205740 * Upstream release includes workaround which enables DVD (4GB file) creation even if compiled with GCC 3.0 to 3.4, closes: #248489 * Bugfix for jigdo-file make-image: Failed assertion `nextAlignedOffoff' and huge .template with 4GB image, closes: #223786 Files: d4296bf443e16b87b379c99e6ef53ff6 580 utils extra jigdo_0.7.1-1.dsc e50aa9c06166906b4785116b761e7626 714665 utils extra jigdo_0.7.1-1.tar.gz abe8231c975ee2c85f5bac2c73fc1e11 231094 utils extra jigdo_0.7.1-1_i386.deb 58b9eeac3b735de5babc209305a7057b 224550 utils extra jigdo-file_0.7.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA2Yvgeeb23IiDVPcRAkfHAJsG9Jk8MEErAhSd/WMohbVejuuvXwCbBU5E tFffvwd8IZtjrVJwzPSr3+w= =ZkGf -END PGP SIGNATURE- Accepted: jigdo-file_0.7.1-1_i386.deb to pool/main/j/jigdo/jigdo-file_0.7.1-1_i386.deb jigdo_0.7.1-1.dsc to pool/main/j/jigdo/jigdo_0.7.1-1.dsc jigdo_0.7.1-1.tar.gz to pool/main/j/jigdo/jigdo_0.7.1-1.tar.gz jigdo_0.7.1-1_i386.deb to pool/main/j/jigdo/jigdo_0.7.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b3-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 May 2004 14:56:24 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b3-2 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 248755 Changes: udftools (1.0.0b3-2) unstable; urgency=low . * Closes: #248755: [l10:ca] udftools catalan debconf templates Files: a916b7625ccb1201f094d7aadae5e7a1 601 otherosfs extra udftools_1.0.0b3-2.dsc bb562788a895176a620e589f43c78fd8 7259 otherosfs extra udftools_1.0.0b3-2.diff.gz d9962677c878d9eafb4f8e60a030c076 68646 otherosfs extra udftools_1.0.0b3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFApMLZeeb23IiDVPcRAgyoAJ0QM8NDi2MgbFG9rbcIy20SnNcmTACeKocf 9UV/uolRtEWpHwgTvTpq0N0= =GvKU -END PGP SIGNATURE- Accepted: udftools_1.0.0b3-2.diff.gz to pool/main/u/udftools/udftools_1.0.0b3-2.diff.gz udftools_1.0.0b3-2.dsc to pool/main/u/udftools/udftools_1.0.0b3-2.dsc udftools_1.0.0b3-2_i386.deb to pool/main/u/udftools/udftools_1.0.0b3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 29 Sep 2003 23:10:16 +0200 Source: w3c-libwww Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0 Architecture: source i386 Version: 5.4.0-9 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Changes: w3c-libwww (5.4.0-9) unstable; urgency=low . * Fixed yet another timestamp problem which sometimes caused attempt to run automake during build Files: f87b9381cc9d65758520e3c86ba364af 690 libs optional w3c-libwww_5.4.0-9.dsc 9e22e71b056602134076980d6574f98a 506185 libs optional w3c-libwww_5.4.0-9.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eKnieeb23IiDVPcRAqi1AJ9THJZn5cGIOrgHQ/Z0vgdRV+iuDgCgmxTN 5Cir4HjEMN/a4H+sOFOPGbo= =5uOv -END PGP SIGNATURE- Accepted: w3c-libwww_5.4.0-9.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-9.diff.gz w3c-libwww_5.4.0-9.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-9.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 28 Sep 2003 20:24:49 + Source: w3c-libwww Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0 Architecture: source i386 Version: 5.4.0-8 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Changes: w3c-libwww (5.4.0-8) unstable; urgency=low . * -l switches from -7 only worked if old version of the package already installed - fixed with additional -L switches. * libtool did not like the circular dependency between libwwwfile and libwwwdir. Fixed by putting all the code of libwwwdir into libwwwfile and turning libwwwdir into an empty dummy lib (for backward compatibility) Files: 3cc0ae5eb1bbeabf2059a423c139377c 690 libs optional w3c-libwww_5.4.0-8.dsc 7eef99747c2942026a79b3c77811feb3 503357 libs optional w3c-libwww_5.4.0-8.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQE/eDUMeeb23IiDVPcRAk2pAJ4/fgfj70m5qdDEyYX4HP0mRedpRQCXVfhF lqil10GaV+eFwnQaLr2hYg== =5dCL -END PGP SIGNATURE- Accepted: w3c-libwww_5.4.0-8.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-8.diff.gz w3c-libwww_5.4.0-8.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-8.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b2-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 28 Sep 2003 12:29:02 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b2-5 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 213074 Changes: udftools (1.0.0b2-5) unstable; urgency=low . * Fixed fix of devfs part of init script, ahem... Closes: #213074 Files: 7827d7682a321dc3a7162aa89a220f27 576 otherosfs extra udftools_1.0.0b2-5.dsc eea73a7fdc99a98ec393504649ae24c8 22429 otherosfs extra udftools_1.0.0b2-5.diff.gz 678ad960ff5bdb7909f015e826ed1a09 44996 otherosfs extra udftools_1.0.0b2-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/drmmeeb23IiDVPcRAjHxAJ4zDjj6LpBp041djkmcwebDcBA4RQCgp2P/ Mt1gBDIyd5d5Wv3/CfS+QCs= =TFUL -END PGP SIGNATURE- Accepted: udftools_1.0.0b2-5.diff.gz to pool/main/u/udftools/udftools_1.0.0b2-5.diff.gz udftools_1.0.0b2-5.dsc to pool/main/u/udftools/udftools_1.0.0b2-5.dsc udftools_1.0.0b2-5_i386.deb to pool/main/u/udftools/udftools_1.0.0b2-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Converting configure.in for use with new auto* tools - what a mess!
Hi, I've fixed a critical bug in w3c-libwww and now want to regenerate all the libtool/autoconf/automake files. Not trivial! The usual libtoolize/aclocal-1.4/autoheader2.13 etc works under testing, but I get build errors there, so I suspect I should try the latest versions in unstable. (The build error, incidentally, is that libtool wants to access files named foo/.libs/.libs/bar, when foo/.libs/bar would appear to be correct.) With the same libtoolize/aclocal-1.4/autoheader2.13 under unstable, the latter gives FATAL ERROR: Autoconf version 2.50 or higher is required for this script. Hrm :-/ So next I tried to convert the configure.in to work with newer versions of automake. I checked the quoting of strings containing commas, replaced all AM_ macro calls except for AM_INIT_AUTOMAKE/AM_CONFIG_HEADER, ran autoupdate and cleaned up the mess it made of the configure.in. Now I've got a configure.in for which autoheader2.50 *still* gives me the infamous undefined macro: _m4_divert_diversion error, even though I've followed the respective hints in the autoconf info pages. I've uploaded the file to http://atterer.net/debian/configure.in - could some autoconf-knowledgeable person please have a look at getting it to work with the w3c-libwww sources, or give me some hints what I need to fix? Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote: [lots of useful stuff] Many thanks indeed - that resolved all the problems! (But it took me a while to track down the additional old-style AC_DEFINEs in acinclude.m4, they also caused problems.) Unfortunately it turns out that the libtool in unstable still accesses foo/.libs/.libs/bar instead of foo/.libs/bar. But I've kludged around this by setting up a symlink .libs - . in the respective .libs directory, and that seems to work. Unless someone knows a better solution, I'll upload the package like that... Thanks again for your help! Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted udftools 1.0.0b2-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 27 Sep 2003 15:14:24 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b2-4 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 204164 209077 Changes: udftools (1.0.0b2-4) unstable; urgency=low . * Fixed init script to work with devfs, closes: #204164 * Dutch translation of debconf templates, closes: #209077 Files: acf4cdf9bec18325a12d8b2fe8a49d25 576 otherosfs extra udftools_1.0.0b2-4.dsc f71abf20b1afa968b1bcbfa4baa0e72b 22385 otherosfs extra udftools_1.0.0b2-4.diff.gz 2560f51fc625ed25471098ad7dfce6e0 44948 otherosfs extra udftools_1.0.0b2-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dY/eeeb23IiDVPcRAvA+AKCNhFCn4S4JNGhCTpVbvZIF6XgeYACeJ9VD AHZVCC1ORnkVXoUt34R7cB8= =vBxO -END PGP SIGNATURE- Accepted: udftools_1.0.0b2-4.diff.gz to pool/main/u/udftools/udftools_1.0.0b2-4.diff.gz udftools_1.0.0b2-4.dsc to pool/main/u/udftools/udftools_1.0.0b2-4.dsc udftools_1.0.0b2-4_i386.deb to pool/main/u/udftools/udftools_1.0.0b2-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 25 Sep 2003 17:08:27 +0200 Source: w3c-libwww Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0 Architecture: source i386 Version: 5.4.0-7 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Closes: 193880 208188 Changes: w3c-libwww (5.4.0-7) unstable; urgency=low . * Changed configure.in and friends to work with latest autoconf/automake. I hate automake. * Changed section of libwww[-ssl]-dev to libdevel * Fixed time stamp problems with html.tar.bz2, closes: #208188 * Added -l switches to link all libs with the libs they depend on, closes: #193880 Files: 406be33912bbb50007741a19dcf686d4 690 libs optional w3c-libwww_5.4.0-7.dsc 0f7ec78d3778e8fc791fd81ad0913904 502206 libs optional w3c-libwww_5.4.0-7.diff.gz 90766551dad34813ec4a06aa0e33edc5 431580 libs optional libwww0_5.4.0-7_i386.deb c5b7dd0f4843a576c0f86996c6e96c32 437574 libs optional libwww-ssl0_5.4.0-7_i386.deb e5b8c84b2531439c1fdf0ea94e1f3a6c 614918 libdevel optional libwww-dev_5.4.0-7_i386.deb 5d04acb4e7774623dda6a36c6c7ba16e 621498 libdevel optional libwww-ssl-dev_5.4.0-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dckQeeb23IiDVPcRAicwAJ9ytH9pqSCI1sKKYdI1cHyKggu9uQCgm0Bx NvJ14OuPID/PIn3kwXYuH2s= =ffeP -END PGP SIGNATURE- Accepted: libwww-dev_5.4.0-7_i386.deb to pool/main/w/w3c-libwww/libwww-dev_5.4.0-7_i386.deb libwww-ssl-dev_5.4.0-7_i386.deb to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-7_i386.deb libwww-ssl0_5.4.0-7_i386.deb to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-7_i386.deb libwww0_5.4.0-7_i386.deb to pool/main/w/w3c-libwww/libwww0_5.4.0-7_i386.deb w3c-libwww_5.4.0-7.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-7.diff.gz w3c-libwww_5.4.0-7.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-7.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: music sheet
On Tue, Sep 09, 2003 at 10:41:14AM +1000, Craig Sanders wrote: why dont we just put up a page on www.debian.org with the requested sheet music (or, if it's copyrighted then appropriate links to sites where it can be found). FWIW, I always enjoy it when it comes up again. Maybe I should start a Dueling Banjos Fan Club. :-) If debian-news carried an item which explains that we're not that musical after all, I'm sure that would make it to the top of Google's list... BCCd. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ pgpJjLC9V8jik.pgp Description: PGP signature
Future of Libwww Survey by W3C
Hello, as the maintainer of the libwww packages, I'd like to notify you of a survey the W3C is doing: - Forwarded message from Jose Kahan [EMAIL PROTECTED] - Date: Tue, 2 Sep 2003 10:52:22 +0200 From: Jose Kahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Announcement] Future of Libwww Survey Folks, W3C has stopped work on Libwww [1] and invites the libwww user community to participate in a Future of Libwww Survey [2] that will help to determine its future. Libwww is a free, highly modular client side Web API written in C for Unix and Windows. A public W3C account is required to complete the survey [3]. Read more about W3C Open Source/Free software [4]. The full text of the announcement is included here below. [1] http://www.w3.org/Library/ [2] http://www.w3.org/Library/Survey2 [3] http://cgi.w3.org/MemberAccess/Public [4] http://www.w3.org/Status -jose - FULL ANNOUNCEMENT -- Future of Libwww Survey -- Due to lack of resources, the World Wide Web Consortium is unable to continue the development and support of libwww[3]. The purpose of this message is to get more information from the existing libwww user community to know what steps should be taken next. Libwww is a highly modular, general-purpose client side Web API written in C for Unix and Windows (Win32). It's well suited for both small and large applications, like browser/editors, robots, batch tools, etc. Pluggable modules provided with libwww include a complete HTTP/1.1 implementation (with caching, pipelining, PUT, POST, Digest Authentication, deflate, etc), MySQL logging, FTP, HTML/4, XML (expat), RDF (SiRPAC), WebDAV, and much more. The purpose of libwww is to serve as a testbed for protocol experiments. Development of libwww goes back to 1991. Inside W3C, it had a major role within the HTTP Working Group. More recently, it is being used by the Amaya editor and browser. There are other HTTP libraries developed by other people. However, libwww is the only library that has a full implementation of the HTTP specification, including caching and pipelining. In order to evaluate whether there are enough people willing to continue working on libwww or if the project should be stopped, we would appreciate your taking some time to answer a survey on The Future of libwww. We're conducting this survey in order to get a better idea of what are libwww's limitations, where new developments/effort should be invested, and how many people are actively using it. We have prepared a public on-line WBS[4] survey at http://www.w3.org/2002/09/wbs/1/libwww/[5]. Having an on-line survey allows us to compile the results on-the-fly. If you have never answered a W3C public WBS questionnaire before, you will first need to request a W3C Public Account[6]. Sorry for this inconvenience. The survey is open from September 2 up to September 30, 2003. Individual answers will be kept confidential. Overall results will be made available on this page and they will also be posted to the regular libwww mailing list. Thanks for your comments and views! N.B. This survey doesn't mean that W3C plans to invest more resources on libwww or its further development. We expect this effort to come from the open source community. -- Jose Kahan -- List of References Document's URL: http://www.w3.org/Library/Survey2.html [4] http://www.w3.org/2002/09/wbs/1/ [5] http://www.w3.org/2002/09/wbs/1/libwww/ [6] http://cgi.w3.org/MemberAccess/Public - End forwarded message - -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: debian archive disk space requirements.
On Sat, Aug 30, 2003 at 12:18:50PM +0200, Josip Rodin wrote: Is there any way to reduce the size of the archive over the next 4-6 weeks ? We are still waiting for Joey to officially announce the obsolescence of potato on -announce so that it can be moved to archive.debian.org. That will buy us six, seven gigabytes at most. Other than that, I've no idea. Pray to god that testing and unstable stop diverging so much? :) Hm, another possibility is to just make a new stable release, and then to delete all those woody packages. ;-) Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 11:08:23AM +0200, Tore Anderson wrote: [snip... oh my!] How amusing to see Sobig.F cited as the reason for reassigning grave severity to a bug! Looks to me as if you just didn't find a sobig-f package to file the bug against, so something else had to be the culprit. In the long run, it would be nice to have a special mail header used by all auto-responders - bounces, virus alerts, out-of-office, maybe even a variant for challenge-response systems -, to allow these mails to be filtered. A good (temporary) solution for people who use c-r systems is to filter Sobig.F, like so (.procmailrc): :0 * ^Subject: (Re: That movie|Re: Wicked screensaver|Re: Your application|Re: Approved|Re: Re: My details|Re: Details|Your details|Thank you!)$ * ^X-MailScanner: Found to be clean Mail/spam Challenge-response antispam systems are considered useful by enough users to be included in the archive. IMHO it must be left to the user to decide whether they're worth the trouble or not - Debian has no business making such decisions on behalf of the user. Cheers, Richard (who, also hates c-r systems, but that's irrelevant) -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted xprobe 0.2rc1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 9 Aug 2003 00:38:26 +0200 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.2rc1-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Changes: xprobe (0.2rc1-1) unstable; urgency=low . * New upstream version, re-libtoolized. Files: 51ab96cb5978bcfa67480dbd78ca115d 584 net extra xprobe_0.2rc1-1.dsc e97cf2f230408a1ade8a6769125159f3 465336 net extra xprobe_0.2rc1.orig.tar.gz 091ac0558a6221e64e929c21d32d686b 50532 net extra xprobe_0.2rc1-1.diff.gz 5095835043c8c0ecb810cfe59a530775 318148 net extra xprobe_0.2rc1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/NC4neeb23IiDVPcRAnVaAJsE6JdsfhfbbQlTO9Jp0dtR3cluFgCfdHde dIDJIWpRRDqCZ2hT/MEQa+s= =2mHo -END PGP SIGNATURE- Accepted: xprobe_0.2rc1-1.diff.gz to pool/main/x/xprobe/xprobe_0.2rc1-1.diff.gz xprobe_0.2rc1-1.dsc to pool/main/x/xprobe/xprobe_0.2rc1-1.dsc xprobe_0.2rc1-1_i386.deb to pool/main/x/xprobe/xprobe_0.2rc1-1_i386.deb xprobe_0.2rc1.orig.tar.gz to pool/main/x/xprobe/xprobe_0.2rc1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udftools 1.0.0b2-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 13 Jul 2003 12:05:58 +0200 Source: udftools Binary: udftools Architecture: source i386 Version: 1.0.0b2-3 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: udftools - Tools for UDF filesystems and DVD/CD-R(W) drives Closes: 199829 200443 Changes: udftools (1.0.0b2-3) unstable; urgency=low . * Added init script which calls pktsetup during startup for devices configured in /etc/default/udftools. Original version of script by Aleksandar Topuzovic - thanks! * Updated config.guess/sub just for the fun of it. * gettext support for debconf templates by Michel Grentzinger (thanks!), closes: #199829 * French translation of debconf templates, closes: #200443 Files: a95ccea4e171a78dded9bc8010bd4ea2 576 otherosfs extra udftools_1.0.0b2-3.dsc d67a3eea2f10b6201dd6f9532e8e71ba 22054 otherosfs extra udftools_1.0.0b2-3.diff.gz a16c1f4c6a65a29f5200981463655d40 44462 otherosfs extra udftools_1.0.0b2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/EUozeeb23IiDVPcRAj/mAKCnoHnqWX6SMppR5XObJ1hUtprnqgCfXmas Os4VmDqPTTif9M0Y/Yo/MpE= =0aP/ -END PGP SIGNATURE- Accepted: udftools_1.0.0b2-3.diff.gz to pool/main/u/udftools/udftools_1.0.0b2-3.diff.gz udftools_1.0.0b2-3.dsc to pool/main/u/udftools/udftools_1.0.0b2-3.dsc udftools_1.0.0b2-3_i386.deb to pool/main/u/udftools/udftools_1.0.0b2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#200163: ITP: png2ico -- command-line PNG to ICO converter
On Tue, Jul 08, 2003 at 06:28:51PM +0200, Thomas Viehmann wrote: martin f krafft wrote: Description : command-line PNG to ICO converter What does png2ico do that convert doesn't? Apart from the mentioned favicon.ico generation, I've also had the need to create .ico files for some cross-platform development (GTK+ on Windows). There's already xpm2wico, but png is a nicer source format. Support for .ico in convert or gimp would be nicer still, though. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Accepted xprobe 0.1-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Jun 2003 16:39:52 +0200 Source: xprobe Binary: xprobe Architecture: source i386 Version: 0.1-5 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: xprobe - Remote OS identification Closes: 191128 195560 Changes: xprobe (0.1-5) unstable; urgency=low . * Re-libtoolized to bring config.guess etc up to date, closes: #191128 * Eliminated use of multi-line strings, which cause build failure with gcc 3.3, closes: #195560 Files: 270a6062f262f0b156cebb0df9b3b602 575 net extra xprobe_0.1-5.dsc 49abff0629e111d18fe01bbd84c762ae 38664 net extra xprobe_0.1-5.diff.gz 998d4eedc3c9a0088531f061125ef4d6 292674 net extra xprobe_0.1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+2hgieeb23IiDVPcRAqKNAKCl3kdZyCAxQjO5k/AsmPMYZXTaowCeI1bs 0Hxg/ejDVbGcWQEmRioTzPQ= =eP7T -END PGP SIGNATURE- Accepted: xprobe_0.1-5.diff.gz to pool/main/x/xprobe/xprobe_0.1-5.diff.gz xprobe_0.1-5.dsc to pool/main/x/xprobe/xprobe_0.1-5.dsc xprobe_0.1-5_i386.deb to pool/main/x/xprobe/xprobe_0.1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: steambox ripper
On Mon, May 19, 2003 at 09:06:20PM +1000, RedaComputer wrote: Could you please help me to find the website from where I am able to download steambox ripper. No, sorry - I'm afraid we'll first have to complete our search for the sheets of dueling banjos before we can work on your request. Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Accepted w3c-libwww 5.4.0-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 8 Mar 2003 15:55:52 + Source: w3c-libwww Binary: libwww-dev libwww-ssl0 libwww-ssl-dev libwww0 Architecture: source i386 Version: 5.4.0-6 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Closes: 174694 182362 Changes: w3c-libwww (5.4.0-6) unstable; urgency=low . * Now using debhelper 4 * Added homepage URL to description * Recompiled with libssl0.9.7, closes: #182362 * Fixed shlibs: When compiling with libwww-ssl0 installed, resulting packages will depend on libwww-ssl0 and not libwww0|libwww-ssl0. Unfortunately, the cleverer solution of only libwww-ssl0's libwwwssl.so having a shlibdep of libwww-ssl0 (and the others libwww0|libwww-ssl0) does not work, as lintian would later complain about package-has-a-duplicate-relation libwww0,libwww0|libwww-ssl0. Closes: #174694 Files: 3c54d0bd6a0b9ee0e1ef61b0b149be3d 689 libs optional w3c-libwww_5.4.0-6.dsc 1ffdaf22743f9c084e6961ebfed6f172 98309 libs optional w3c-libwww_5.4.0-6.diff.gz d22d9db44759dd3860a5aae619e294ce 427902 libs optional libwww0_5.4.0-6_i386.deb 6758176f3902f020bd22b9f22316bd5c 434242 libs optional libwww-ssl0_5.4.0-6_i386.deb 0677706cfc62e82d3e8cf1e910a81851 614234 devel optional libwww-dev_5.4.0-6_i386.deb d00ac36f12f7b3020d7d70d185cf129c 620782 devel optional libwww-ssl-dev_5.4.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ao+seeb23IiDVPcRAtWaAJ90f9Rx9CZHrsg/vx0kOu0y6x10NACeIYvX aGamcW6zZQ08RiOdHgJd2/8= =wK60 -END PGP SIGNATURE- Accepted: libwww-dev_5.4.0-6_i386.deb to pool/main/w/w3c-libwww/libwww-dev_5.4.0-6_i386.deb libwww-ssl-dev_5.4.0-6_i386.deb to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-6_i386.deb libwww-ssl0_5.4.0-6_i386.deb to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-6_i386.deb libwww0_5.4.0-6_i386.deb to pool/main/w/w3c-libwww/libwww0_5.4.0-6_i386.deb w3c-libwww_5.4.0-6.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-6.diff.gz w3c-libwww_5.4.0-6.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-6.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.6.9-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 25 Jan 2003 00:10:32 +0100 Source: jigdo Binary: jigdo-file Architecture: source i386 Version: 0.6.9-2 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo-file - Download Debian CD images from any Debian mirror Closes: 178195 Changes: jigdo (0.6.9-2) unstable; urgency=low . * Fixed build errors with new versions of GCC 3.2, closes: #178195 Files: 2c28e0af1aa985875c12d73e41b94342 586 utils extra jigdo_0.6.9-2.dsc cb077c323e5f3f912f2f85df9836b5f7 3678 utils extra jigdo_0.6.9-2.diff.gz 610a4aaa9a4a90a723bba81b0898d34d 207764 utils extra jigdo-file_0.6.9-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Mwg5eeb23IiDVPcRAv/YAJ97fqgl/cNkfjt/JxvE2MSsPZ3v6ACbBcI0 4gGkE7Bqr10TFMmSHOcwQVs= =e1qk -END PGP SIGNATURE- Accepted: jigdo-file_0.6.9-2_i386.deb to pool/main/j/jigdo/jigdo-file_0.6.9-2_i386.deb jigdo_0.6.9-2.diff.gz to pool/main/j/jigdo/jigdo_0.6.9-2.diff.gz jigdo_0.6.9-2.dsc to pool/main/j/jigdo/jigdo_0.6.9-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jigdo 0.6.9-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 26 Dec 2002 18:02:28 +0100 Source: jigdo Binary: jigdo-file Architecture: source i386 Version: 0.6.9-1 Distribution: unstable Urgency: low Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: jigdo-file - Download Debian CD images from any Debian mirror Closes: 153643 153947 154338 163721 176947 Changes: jigdo (0.6.9-1) unstable; urgency=low . * New upstream release * jigdo-lite: When temporary dir is already present, scan its contents *before* downloading the first batch of files, closes: #153643 * jigdo-file: Prevent infinite loop if I/O error occurs during scanning of files, closes: #153947 * jigdo-lite: Use a separate temporary dir for each new download. This allows you to run several jigdo-lite instances in the same dir at the same time, closes: #154338 * Improved handling of invalid cache files (created if disc gets full during cache update): Instead of crashing, jigdo-file prints an error. However, libdb still corrupts the cache file, closes: #163721 * jigdo-lite supports a --scan command line option to avoid the Files to scan question, closes: #176947 * Conflicts: jigdo ( 0.6.9) because of jigdo.mo in both packages, just to allow for smooth upgrade for people using my unofficial jigdo package. * Added the Debian jigdo mini-HOWTO to the doc directory Files: cc71e0ab200ac45a95c7d5ff936f093e 586 utils extra jigdo_0.6.9-1.dsc 16eedd68f6c9990504f50376ef4574c9 519864 utils extra jigdo_0.6.9.orig.tar.gz 878ded35ecf3ac212a7c6498a1f65ffa 3246 utils extra jigdo_0.6.9-1.diff.gz 87bac63ce1d1c4172f1f558c530a8ecc 207656 utils extra jigdo-file_0.6.9-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+KgIheeb23IiDVPcRAmC7AJ9x6ca5HS/kXbr1XwanV4cDP9kyqQCdHLNr J1ResJcFT2sWK/7htZnUsLQ= =aVd6 -END PGP SIGNATURE- Accepted: jigdo-file_0.6.9-1_i386.deb to pool/main/j/jigdo/jigdo-file_0.6.9-1_i386.deb jigdo_0.6.9-1.diff.gz to pool/main/j/jigdo/jigdo_0.6.9-1.diff.gz jigdo_0.6.9-1.dsc to pool/main/j/jigdo/jigdo_0.6.9-1.dsc jigdo_0.6.9.orig.tar.gz to pool/main/j/jigdo/jigdo_0.6.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-linux Windows program - was Re: bill gates Linux
On Sun, Dec 08, 2002 at 07:04:46PM +0200, Richard Braakman wrote: Are VFAT partitions still common? I thought Windows 2000 and XP both used NTFS by default. And last time I tried (about a year ago, I think) mounting NTFS read-write on Linux was still flaky. But ISTR that _file_overwrite_ support for NTFS now works, to allow precisely the sort of loopback installation we're talking about! Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: How to validate Debian woody CDs?
On Fri, Nov 29, 2002 at 01:35:10PM +0100, Vera Friederichs wrote: I have tried several procedures (only with CD2): [...] dd if=/dev/cdrom bs=1k count=8656864 | md5sum I just noticed that the count is wrong - surely the size of your CD isn't 8.6 GB? :) Here are the sizes (in kb) of my 3.0r0 i386 set: 1_NONUS: 662624 2: 661216 3: 662656 4: 656960 5: 654592 6: 657760 7: 354048 Yes, I checked the README-files. They say it is woody (unofficial, but that should not be the problem?) A mistake was made during the CD generation, so the CDs say they're unofficial, but they're not. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: How to validate Debian woody CDs?
On Thu, Nov 28, 2002 at 01:51:02PM +0100, Jochen Voss wrote: Is this a good way to check wheter the CDs are official Debian CDs? Yes! Except md5sum should be called differently, see below. The result was that the checksums did match for CD #1, but did NOT match for the remaining CDs. When she asked the dealer he told her, that this does not indicate a problem, but could be caused by additional bits at the beginning or end of the CD. Does this make sense? It does, unfortunately (at the end, at least). According to the mkisofs docs, many OSs break if the length of a CD is not a multiple of the OS page size, or something like that. To avoid this problem, mkisofs adds a few sectors of zeroes to the end of the CD image. These zeroes are included in the md5sum. However, when writing the image to CD, I think some programs add yet more padding to the end of the written data, just to be safe. cdrecord needs an explicit -pad to do this, but other programs may add the padding by default. But it is possible to pass the correct data to md5sum: First, mount the CD. Just working on the unmounted device doesn't always seem to work. Then, try one of two things: cat /dev/cdrom | md5sum Apparently, this is preferable to md5sum /dev/cdrom because cat does a better job of really reading all the available data - YMMV. I'm not sure whether the above will work if more padding was added e.g. by cdrecord, so better try the alternative: dd if=/dev/cdrom bs=1k count=# | md5sum where the # is the 1k-blocks value from the output of df /cdrom. HTH, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ pgpmDFIrMNiUC.pgp Description: PGP signature
Accepted w3c-libwww 5.4.0-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 12 Oct 2002 20:45:41 +0200 Source: w3c-libwww Binary: libwww-ssl-dev libwww-ssl0 libwww-dev libwww0 Architecture: source i386 Version: 5.4.0-5 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Closes: 161148 163977 Changes: w3c-libwww (5.4.0-5) unstable; urgency=medium . * Re-libtoolized source using libtool 1.4.2-7.1, now really fixes build problems; closes: #161148 * Fixed bogus GCC warning comparison is always true on machines where char is unsigned, patch sent upstream; closes: #163977 Files: c56ccd120293851daaa99af34c723032 694 libs optional w3c-libwww_5.4.0-5.dsc b095cc6285a38963f6a2ef22e65caa92 97974 libs optional w3c-libwww_5.4.0-5.diff.gz 7af320a85f8ac4ed1f902ba7b042e341 418524 libs optional libwww0_5.4.0-5_i386.deb d94f8f81c97245b8e643ca76fd20698a 424942 libs optional libwww-ssl0_5.4.0-5_i386.deb cc17b23268508bd115ecdf9db310fb05 601230 devel optional libwww-dev_5.4.0-5_i386.deb d65c3e020e14bdab058edef1b819c1fa 607908 devel optional libwww-ssl-dev_5.4.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9qHmMeeb23IiDVPcRAvv/AKCsDYg9enKYYIXPrtoyDA4e0tVYZACfYGAQ GNSnqZtQVjEtIy2LA8KNxrU= =tKMo -END PGP SIGNATURE- Accepted: libwww-dev_5.4.0-5_i386.deb to pool/main/w/w3c-libwww/libwww-dev_5.4.0-5_i386.deb libwww-ssl-dev_5.4.0-5_i386.deb to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-5_i386.deb libwww-ssl0_5.4.0-5_i386.deb to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-5_i386.deb libwww0_5.4.0-5_i386.deb to pool/main/w/w3c-libwww/libwww0_5.4.0-5_i386.deb w3c-libwww_5.4.0-5.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-5.diff.gz w3c-libwww_5.4.0-5.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3c-libwww 5.4.0-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Sep 2002 19:42:26 +0200 Source: w3c-libwww Binary: libwww-ssl-dev libwww-ssl0 libwww-dev libwww0 Architecture: source i386 Version: 5.4.0-4 Distribution: unstable Urgency: medium Maintainer: Richard Atterer [EMAIL PROTECTED] Changed-By: Richard Atterer [EMAIL PROTECTED] Description: libwww-dev - The W3C WWW library - development files libwww-ssl-dev - The W3C WWW library - development files (SSL support) libwww-ssl0 - The W3C-WWW library (SSL support) libwww0- The W3C WWW library Closes: 161148 163370 Changes: w3c-libwww (5.4.0-4) unstable; urgency=medium . * 5.4.0-3 did not include libwwwapp.so on many arches. Re-libtoolized source using libtool 1.4.2-7 - libtool bug #98342 caused link errors for libwwwapp.so, but did not result in a build error. Closes: #161148, #163370 * Added config/*.pl files from old pre-5.3.2 sources, they seem to have been omitted accidentally for the 5.4.0 release. Files: ade93fae169dfdf56716cbfc0fc702de 694 libs optional w3c-libwww_5.4.0-4.dsc cd71bd545df84c0d90d3aef4c06b6994 96748 libs optional w3c-libwww_5.4.0-4.diff.gz e36a2402a7185acf80099b4ae8534023 418398 libs optional libwww0_5.4.0-4_i386.deb efdfc740413ce77fd3a982db0c76ddf6 424818 libs optional libwww-ssl0_5.4.0-4_i386.deb b8ca74a9dd7fd40d4a381c7d4b6d03c4 601106 devel optional libwww-dev_5.4.0-4_i386.deb beb66798d9211c886bd4809e10a16166 607852 devel optional libwww-ssl-dev_5.4.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9nyjneeb23IiDVPcRAgXmAJwM4EuD6NRYQm5CXVXkG0quoe3rVQCePjZy Ko2e2hpcUTC0CYzxPMtwtec= =Y+im -END PGP SIGNATURE- Accepted: libwww-dev_5.4.0-4_i386.deb to pool/main/w/w3c-libwww/libwww-dev_5.4.0-4_i386.deb libwww-ssl-dev_5.4.0-4_i386.deb to pool/main/w/w3c-libwww/libwww-ssl-dev_5.4.0-4_i386.deb libwww-ssl0_5.4.0-4_i386.deb to pool/main/w/w3c-libwww/libwww-ssl0_5.4.0-4_i386.deb libwww0_5.4.0-4_i386.deb to pool/main/w/w3c-libwww/libwww0_5.4.0-4_i386.deb w3c-libwww_5.4.0-4.diff.gz to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-4.diff.gz w3c-libwww_5.4.0-4.dsc to pool/main/w/w3c-libwww/w3c-libwww_5.4.0-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody CD not bootable with adaptec + scsi-cdrom
On Sun, Sep 01, 2002 at 06:51:16AM +0200, Goswin Brederlow wrote: I the discovered that the woody CD (linuxtag prerelease) doesn't boot. I heard of similar for the real woody release CDs on irc. Can anyone boot the CDs, which one of the set and what hardware? Same if you can't boot. Also whats different between potato and woody? potato has this multiboot thing and woody not anymore, right? What was wrong with it? Seems to be more compatible the old way. Before the woody release, it became clear that many people needed different kernels for their hardware: Quite a few need bf24 for their new hardware (e.g. USB keyboard), others need vanilla for their ancient hardware. See http://www.debian.org/CD/faq/#bootable for info on the different flavours. At the same time, it was considered important to allow installation using just the first CD, so somebody came up with the multiboot idea. Experiments then showed that multiboot didn't work on some machines - *however*, this can be said of all methods which allow you to choose between several images at boot time. So the final solution was to use multiboot only on the first CD, the other CDs use the same method as potato. The few machines on which it fails are either old or have a SCSI CD-ROM, booting from one of the later CDs should work for them. AFAIK if the woody release multiboot CD fails, it even prints a message which tells you to do that. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
Hi, I have been waiting all along for someone to post this, but nobody does, so... As usual Heise got it right: http://www.heise.de/newsticker/data/vza-28.08.02-000/ (German). Essentially, the relevant change to the MP3 license was already made 1.5 years ago, but apparently nobody noticed until now. Thomson tolerate violations against their license are far as *de*coders are concerned. That's what the Thomson PR person probably talked about... However, such a statement is not enough for us to keep MP3 decoders in the distribution, I'm afraid. Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: Debian's problems, Debian's future
On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote: On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote: I beleive this method is patented by somebody, [snip] has someone a pointer? Here's some stuff from my mail archives - I haven't checked whether the links still work. The following one probably doesn't, but looks like the patent number is 6167407: http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=/netahtml/srchnum.htmr=1f=Gl=50s1='6167407'.WKU.OS=PN/6167407RS=PN/6167407 Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ - Forwarded message from Clifford Heath [EMAIL PROTECTED] - Date: 29 Jan 2001 10:05:11 +1100 From: Clifford Heath [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: Goswin Brederlow [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: reverse checksumming [legal] What came first, rsync or the patent? OSA refers to its issued patent US6006034 as the SmartPull patent. This isn't the patent that threatens rsync, though it might be relevant to some of the preceeding discussion. I haven't considered whether there's any overlap with rsync itself - in any case I doubt OSA would attempt to block use of rsync. We think that rsync is wonderful! The patent that may overlap with rsync is US5446888 and its followup number US5721907, with precedence date Jan 14 1994. I am not a lawyer, but it seems to directly conflict with rsync. I've had correspondence with the rights holders, as OSA wished to implement something similar in a product but held off until licensing concerns were addressed. They are Travelling Software Inc. (TSI), and refer to the technology as SpeedSync, using it in their LapLink product line. At the time of my last contact (August 1999), Travelling Software had not made a determination if rsync infringes on any intellectual property right of TSI or not. Read the patent and decide for yourself. I'm not qualified to hold a legal opinion. The patent clearly identifies which operations are performed on the host sending the file, and which on the host receiving it. We discovered a method which reversed many of the operations with substantial benefit (as Tim Adam has told you), and filed a patent to this effect, with a defensive intent. This latest patent has not issued (it's pending). So we have no rights (yet!) to ask you to cease and desist from implementing and using it. Be aware that this might change in the future. I personally believe (and think OSA agrees) that it would be counter-productive to the industry as a whole, but it's not my decision. Who knows, OSA itself might be sold to some sharks who think differently... This is just the rsync algorithm and thats probably way older than the patent, so the patent might not hold. I don't believe that rsync is older, but in any case it's difficult and expensive to challenge an issued patent over prior art, and I don't think that Tridge is likely to do that. If you fear a suit from TSI and would choose a prior art defense, you will need Tridge's help, as only he could establish priority. Can the text of the Patent be found anywhere online? http://www.delphion.com/details?pn=US05721907__ -- Clifford Heath, Open Software Associates, mailto:[EMAIL PROTECTED], Ph +613 9895 2194, Fax 9895 2020, http://www.osa.com.au/~cjh, 56-60 Rutland Rd, Box Hill 3128, Melbourne, Victoria, Australia. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rsyncable GZIP (was Re: Package metadata server)
On Sun, Apr 07, 2002 at 08:16:28PM +0200, Otto Wyss wrote: What amazes me is that nobody is able or willing to provide any figures. So I guess no provider of an rsync server is interested in this subject and therefore it can't be a big problem. It is a problem on cdimage.d.o, which is also ftp.uk.d.o. A single CD image rsync means a load of 1 for 10 minutes, and once 5 people or so rsync in parallel, the machine gets quite sluggish. Using rsync just for the Packages file would probably work, but forget about also using it for the packages. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EURO and CENT signs in the console keymaps
On Tue, Jan 01, 2002 at 07:53:46PM +0100, Eduard Bloch wrote: a related note, when will the Euro be part of fixed? :) Anybody knows anything about it? Huch, apt-get install xfonts-base-transcoded and you have fixed fonts with latin15 charset. My -misc-fixed fonts already have iso8859-15 even without that package, FWIW. Hm... but could the transcoded iso8859-15 fonts maybe move to the regular xfonts-100/75dpi packages? IMHO, the Euro should be supported by a standard X install, without the need for another big font package. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: bind9-chroot (was: questions on ITP)
WRT chrooting certain applications - wouldn't it make sense to mandate one consistent way for the user to do this if the package supports it? That way, chrooting daemons is much more user-friendly, which in turn will (hopefully) lead to more people doing it. One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. (The config file should probably not be read directly, instead the init.d script should call a small query script. That way, file format changes are possible.) Furthermore, IMHO init.d scripts that support chrooting should clearly print [chrooted] or [non-chrooted] in their startup message, both to make the user aware that chrooting is possible, and to make it clear whether it takes place. So: - If I were to put together a chroot-helper package, would people be interested in using it for their package? - Any chance of getting a recommendation for this into policy? Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgpRpbNdfnvwh.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote: Help, please no. More supports for chroots may be nice. But not this way! init.d-scripts calling scripts, that parse global config files is ugly and one of the many points to make people switch from Suse or Redhat to debian. On Sat, Sep 22, 2001 at 05:46:57PM +0200, Martin F Krafft wrote: well, you might just use SuSE then... :-) The config script was only a suggestion, and maybe there is a better way. But my main point was: Chrooting a daemon should be possible in a uniform way for all daemons that support it. What alternative possibilities for implementing this do you see? The package will have to contain the necessary chrooting script somewhere, and the admin will have to perform some action to trigger its execution. After he has done that, the init.d script should execute the chrooted daemon. It is possible to tell the admin to edit the init.d script, changing some variable assignment to chroot=yes, but somehow I don't think this is very clean, either... Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgp2CxJpGiE30.pgp Description: PGP signature
Re: OCELOT SQL DBMS is now free open source (fwd)
On Tue, Sep 18, 2001 at 05:36:59PM +0200, Simon Richter wrote: I just came across this, perhaps someone is interested in packaging it. While we're at it; another interesting database that really ought to be included with Debian is SAP-DB http://www.sapdb.org. Note that there's a pending ITP (#88988) from 9 Mar 2001 by Bernd Eckenfels [EMAIL PROTECTED] I had a look at it. To package it, at least the following is necessary: - A few days' time to get acquainted with the build system - A week or two to get it packaged (rough estimate) - Source code for all the _development_tools_ from SAP (start with that) - A couple of changes to make it FHS compliant - More time to package the various extensions, language preprocessors etc. and with that, you get a wonderful, full-featured DBMS! Maybe some task force would be required to do the work, though. (Sorry, I haven't got the time.) SAP-DB is being actively developed by ~100 people in Berlin. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgpIVptPiSFzF.pgp Description: PGP signature
Re: Bug#112020: ITP: keychain -- An OpenSSH key manager
On Wed, Sep 12, 2001 at 11:06:30PM -0400, Daniel Jacobowitz wrote: Keychain is functionaly equivalent to a passphraseless key, though. Exactly my point! The only additional thing you get with keychain is a false sense of security. On Wed, Sep 12, 2001 at 07:08:32PM -0500, Cesar Mendoza wrote: I find the package useful and I'm also aware of the shortcomings of ssh-agent, but was your solution to cron job's that do rsync over ssh? SSH keys without a passphrase! :-/ Not that I like the idea, but you have to realize that keychain buys you absolutely nothing! and I don't think that pass phrase less keys is an option. Sorry, but I can't understand why you think keychain is more secure. What's really needed is a little work on ssh-agent so that - when ssh asks for a DSA passphrase, it also sends it to ssh-agent - ssh-agent can expire keys after some time of inactivity I know that but for now we have to work with what we have, don't you think? Indeed. You might want to experiment with the following: Create a dedicated user on the machine that you log into, whose default shell is not /bin/sh, but a script of yours which executes rsync with the right options, no matter what arguments are passed to it. Also, the user should not be able to write to any files in his home directory. This way, even if the key is compromised, it will be difficult for the attacker to do anything but run that one command. This doesn't provide an awful lot of security, and a determined attacker might find a way to circumvent it, but it's already a lot better than a completely open account. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgpNCX1z3Kcci.pgp Description: PGP signature
Re: Bug#112020: ITP: keychain -- An OpenSSH key manager
On Tue, Sep 11, 2001 at 03:00:44PM -0500, Cesar Mendoza wrote: Package: wnpp Severity: whishlist ^ typo From the keychain help: Keychain is an OpenSSH key manager, typically run from ~/.bash_profile. When run, it will make sure ssh-agent is running; if not, it will start ssh-agent. It will redirect ssh-agent's I would prefer if this program weren't packaged for Debian. It demonstrates cluelessness on the part of its author and encourages bad security practice in two ways: - ssh-agent running continuously 24/7 with valid keys - ssh-agent running on the machines that you log into, rather than only on the machine you sit at For Debian, under X ssh-agent is already running when the user logs in, so you can access it from any number of X terminals. On the console, if you want equivalent features, use RSA/DSA keys without a pass phrase. KEYCHAIN IS NOT MORE SECURE THAN THAT. It is no problem and tools exist to extract the keys from a running ssh-agent process. I'd like to remind you that inappropriate use of ssh-agent has in the past resulted in a hacker getting access to important servers. (IIRC it was only mentioned on -private at the time, so no details.) What's really needed is a little work on ssh-agent so that - when ssh asks for a DSA passphrase, it also sends it to ssh-agent - ssh-agent can expire keys after some time of inactivity Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgp5Xw15UWWzG.pgp Description: PGP signature
Re: Reasons why package central approach to handling translations may be suboptimal
On Thu, Sep 06, 2001 at 08:10:10PM +0200, Michael Bramer wrote: no, don't re-invent the wheel. This all make gettext. We don't need patch apt, dpkg, other toold this way. We must only use a old, nice and tested tool: gettext. Nice, I wasn't aware it solves the encoding problem as well! The only place where it isn't 100% suited for our purposes is the Descriptions-XX.po, because the English text is duplicated. Would it make sense to hack gettext to make it allow checksums instead of the English descriptions? Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: Reasons why package central approach to handling translations may be suboptimal
On Thu, Sep 06, 2001 at 03:42:00PM +0900, Junichi Uekawa wrote: I have been reading the DDTS thread, and seeing that it was resolving into a each package should maintain their translation. I would like to present what I think may be problematic in that approach : 1. This results in filing random bugs in BTS in random manner. [snip] I think there's an answer to this problem: When the maintainer updates the translations of his package, this should be fully automated. E.g. just one command update-translations --from-mbox my_mail_archive which fishes out the DDTS messages (which are sent in a standard layout), or, for people lucky enough to be permanently online, an update-translations --from-web command in debian/rules which gets the translation updates directly from the DDTS server. So far, *everything* related to a Debian package can be found in the corresponding source package. I don't think it's a good idea to change this. 2. A package is re-uploaded with translation. There is a package uploaded with one-line changelog saying something like Merged spanish templates. It is a load to autobuilder/ftpmirror/etc. and of course manual intervention to rebuild a package means that an error occurs, and it does. The main problem here is that translation start after the initial upload of packageto Debian happens, which means there will be a -2 Debian package which will include the translation, and a -1 Debian package will have no translation. Yes, that's one of the basic problems. IMHO with the proposed override mechanism via Descriptions-XX.po (or whichever form it is going to have), this is mostly solved - anyone getting the -1 package from testing will already see the translation. People tracking unstable may or may not see them, depending on how often they update and on the speed of the translators. Some people are concerned that their daily update from unstable will need too much bandwidth because of all those extra uploads. If the override mechanism works, I see no reason not to have a policy don't re-upload if only the translation changed. 3. No choice of I want this locale and not others. I assume in particular you mean I prefer this _encoding_? This is a point that hasn't been discussed at all so far. Will there be one description .po file per language in the source package, or one for all translations? The alternatives here are: - Supply descriptions in UTF-8, and recode them for the user's current encoding on the user's machine. Nice and clean, but requires support (possibly quite extensive changes) in dpkg/apt. NB, we _do_not_ need full Unicode support in all of Debian for this, just in the tools that deal directly with the description data. - Supply descriptions in UTF-8 and recode them to a default encoding that root can configure on each machine. Do the recoding immediately after an apt-get update or dpkg -i, so the UTF-8 version is never stored on the machine. Might be the way to go for the moment, even if it's not ideal. Most importantly, it is upwards-compatible with the first solution above. - Pick one default encoding per language and just assume the user uses that encoding. Problematic: Should we ever want to change the default encoding, there'll be lots of packages using the old encoding, and we'd be stuck with it. I'm all for at least _supplying_ the translations in UTF-8, even if they're not stored on the user's machine like that for now. Note that this does not even mean that the translators need to produce translations in UTF-8 - the DDTS can recode their work into UTF-8. Comments? Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgp16ClvZnD3o.pgp Description: PGP signature
Re: new proposal: Translating Debian packages' descriptions
Hi Michael, all in all, I think this sounds nice! On Tue, Sep 04, 2001 at 01:22:16PM +0200, Michael Bramer wrote: 1.) use all the time _gettext_! I agree, otherwise we'd just have to keep re-inventing the wheel. 2.) get the .po/.mo files on the system [snip] If we don't like this process on the client all the time, we can produce Descriptions-XX.po files and the clinet must only download this file and save this in the right dir. But this file will include the orignal description and with this it has the double size and download time. I don't know enough about gettext - am I assuming correctly that in the .mo file, the English translation is replaced with a checksum or similar, so you do not need to store the complete English translation? 4.) How get katie (or the desc-trans-XX.deb) the translation? [snip] 5.) translated descriptions in the package. [snip] I see only one problem: the size. We have now 80446 .deb packages and 7643 source packages in the debian archiv on ftp-master. If we include the translation in the deb, we must store this in the source and in every deb package. check this calculation: If in all sources are only one desription with 130 (geziped) bytes of description we get 1 MByte per languages. If we use po files in the source (see below), we get 2 MBytes per languages And all deb packages have only one description with 130 (geziped) bytes. This make 10 MByte per languages. If we store the description as po file, we will use 20 MByte per languges. 11/22 MByte per languages, with only 10 languages we will get 110/220 MBytes. Hm, this sounds a lot, but note that relative to the complete archive size, it's only an increase of about 1%. A well-invested way of using this disc space, IMHO. With more Packages, ports, languages, this will grow. This bytes must all be downloaded, uploaded and synced with the time. And on the local system the descriptions and the translations of all languages from the package will stored on the local harddisk (without gzip). Count: With 10 languages, 1000 installed Packages and 380 Bytes per description and per translation you get additional 4/8MBytes on the local disk. Is this all usefull in a 'normal' deb package from the debian project? Maybe yes. We must decide this. (I personal don't find the real pro about this. But we can add it and I don't have a real problem with this. I see only the size problem, and this is not a big problem.) I think it's very important to have the translations in the *source* package. For the binary package, I don't know... - Gnome and KDE do include all translations, and I think it's easier to handle. Additionally, disc space is really cheap these days, so maybe it would be better just to include all the descriptions, too. In all the cases I propose: store the description in the source as .po file in the /debian/ dir (one per languages). This is the only real good way to store the translations. (no encodeing problem, no outdated text, no debconf-mergetemplate hack, ...) Seconded. But how get the maintainer the translation? We have some cases: - The maintainer translate the description hisself - He find some own translator (like now with debconf) - He use the ddtp - He can ask the ddts and get all translations of the package - He can use the override file of katie - He use the notification mails from the ddts (In future the server will use the decided format in this mail. With this, the maintaner must only copy this file in the source.) Now the technique part: The proposal with the biggest patch, is the 'put the translation in a own element in the deb ar'. Maybe this is nice and feasible. But this is not a fast way. Because of this I propose some solutions: 1.) (very fast) put the translation as normal .po file in the /usr/share/desc-trans/locale/desc-trans.d/ dir. finish. This don't need some extra work on dpkg etc. Actually, I think this is completely sufficient. Let the maintainer include updated translations at his convenience in new uploads, and use the override mechanism for the Descriptions-XX.mo.gz files until he has done so. Hm, but note that this means that dpkg will need to look first at Descriptions-XX.mo files downloaded by apt, and only then at the .po file in the package. Would that be a problem? 2.) Put the translation in the control.tar.gz of the deb. [snip] 3.) Add the desc-trans.tar.gz in the deb ar as a own new element. [snip] Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Tue, Sep 04, 2001 at 05:50:52PM +0200, Michael Bramer wrote: On Tue, Sep 04, 2001 at 09:44:11AM -0500, Adam Heath wrote: As an automated mail, to which I have not request, I consider this spam. Please remove me, and all ways of contacting me, from your automated lists. I do not take kindly to unwarranted spam mails. OH, this is now the second 'remove me' request. Now the server can only mail notifications to all packages or to no packages. Should I stop it? Comments? The way I see your current proposals, such notifications will /eventually/ be necessary because maintainers will need to update their source packages with translations. Until then, it's not really necessary. IMHO, we should first reach a conclusion as to *how* a package maintainer should add the translation to the package. However, Adam, I think you overreact a bit. As noted by others, this spam is actually the result of someone spending some time on improving your package. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: new proposal: Translating Debian packages' descriptions
On Tue, Sep 04, 2001 at 08:55:32PM +0200, Michael Bramer wrote: On Tue, Sep 04, 2001 at 07:59:47PM +0200, Richard Atterer wrote: 2.) get the .po/.mo files on the system [snip] If we don't like this process on the client all the time, we can produce Descriptions-XX.po files and the clinet must only download this file and save this in the right dir. But this file will include the orignal description and with this it has the double size and download time. I don't know enough about gettext - am I assuming correctly that in the .mo file, the English translation is replaced with a checksum or similar, so you do not need to store the complete English translation? see in the info page from gettext. [snip] You see in the mo file is the orignal description. OK, then why do you say above But [the .po] will include the orignal description and with this it has the double size? Doubled size compared to what? Packages-XX? put the translation as normal .po file in the /usr/share/desc-trans/locale/desc-trans.d/ dir. finish. This don't need some extra work on dpkg etc. Actually, I think this is completely sufficient. Let the maintainer include updated translations at his convenience in new uploads, and use the override mechanism for the Descriptions-XX.mo.gz files until he has done so. Descriptions-XX.mo.gz? not Descriptions-XX.po.gz? Er, maybe .po. As I said, I'm not really a gettext expert. if dpkg use gettext, dpkg show the translation of all textes in the mo file. And if you use apt-get update you have the translation of all packages (from the apt source) in the .mo file. Right, the Descriptions-XX.po.gz needs to contain all translations. Sorry, I mixed things up. (BTW, wouldn't it make sense to represent the English translation only with a checksum in Descriptions-XX? We'd save a lot of space...) What do you think of my main point: Since we already have an override facility with the Descriptions-XX.po.gz, why should we bother introducing another override mechanism which modifies the control.tar.gz? OK, dpkg --info will not work until the maintainer catches up, but most people use dselect or apt-cache show. All the best, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
