Accepted buffycli 0.7-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Jun 2012 16:55:08 +0200 Source: buffycli Binary: buffycli Architecture: source all Version: 0.7-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - Text mode alternative to Buffy Closes: 649091 672768 Changes: buffycli (0.7-1) unstable; urgency=low . * New upstream release 0.7 closes: #672768 closes: #649091 Checksums-Sha1: e8026a5dc4d7212d232147c377a55b944e889390 2068 buffycli_0.7-1.dsc 81e9375ffb975ff0751dff7ec89906949d195f83 17112 buffycli_0.7.orig.tar.gz a1b0452e72acf0ec71f17da8c8806c14522de2ff 3039 buffycli_0.7-1.diff.gz 38bd41d196347fade3ae4809d5682d09bb72a483 11204 buffycli_0.7-1_all.deb Checksums-Sha256: 6d382f24330a5be40fb61c0c1af7e68af8b5f4c8792dbfdebe96a2d8c3dd4cec 2068 buffycli_0.7-1.dsc 97f1aad2268ab78a263d516d0ab79ca00f8928bb3c4ba3d56c8f4042db42bfb9 17112 buffycli_0.7.orig.tar.gz 4607298c8918c13fd47477934d340275f382f05d9ce740511d1b82a9c4ccebca 3039 buffycli_0.7-1.diff.gz 6d9966b9abedeb5d55965944a2c85fc8f284df2532afaf0dfeaf5f4eb8a5e9aa 11204 buffycli_0.7-1_all.deb Files: 4a8c21e9221950d37e78d551a75fc47f 2068 mail optional buffycli_0.7-1.dsc fcc4b0f93825325b70c0484c824bd492 17112 mail optional buffycli_0.7.orig.tar.gz 4723474cd0783d71da3a581dd49a67ec 3039 mail optional buffycli_0.7-1.diff.gz 89aa3640faef8af9351d3f8c35645d75 11204 mail optional buffycli_0.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQLvBAEBCgDZBQJP6dMEwBEaaHR0cDovL21hcnRpbi1rcmFmZnQubmV0L2dwZy9z aWctcG9saWN5LzU1Yzk4ODJkOTk5YmJjYzQvMjAxMTAxMjQxMTI1P3NoYTUxMnN1 bT0xY2FkOTZmZDI3ZDMyMzNmNTNlMjI4NDk1MzM2NDgxMDdlNWVlOGQ1YmU2NTUy NTFkNzRjOGYxYzVjM2JjNDJmMjMwNGZhNTE1MTUwZjdiZDRkZDA1ZTk4MTk5MjRm MDQ5NTEzZWU5OTYyY2E3MTcwOWY4MWQ5NDUxNTg1MmJkOAAKCRBVyYgtmZu8xPAk D/wIu1EWR8nnEwCyaRmiG8RJLiAonZGmiChl1XiGXDS277K6dic8D4seZLzHsXGQ LsLxxalPl6CkF+VQz909wuX2Qujqf/uvdHHrV6kndw/8Q4uKMxUKuEq1q9Oq2C7H 3CBGujlM5N/3/Z8jc+G+8ibJtUaCWVlOhY9mxW0RsSQa+swUSG8Xf8e5Rov3iz2b gE4KtsI0tjIhOOEMT1u78lu0GUmV+hgfI7zCSAC52up39MOsKBfykFqGkIXpa/yH oSeb4RBSlw+09ZpyVBXZwsOjoWf5KlfgpxQQRm/bwo6O6s2LIYN8405TA+0LLfX8 0esdmDzxAnuYadIvQ3IGphsHIfGEma/gveOdDdTJwEYO4bsAd0xtG9ZCrhTBZ+7q HdjwyK3wr1dWYVC9IDSCJ7Z0DlWZTCP1fGZCs3PnJRjEm+uxvdmxi25UkT0D2jHY pTAxWozx9qe55BHFzpmC94I2gwX53ByHHCqGEnxc9lV/n910pZ47resDv1Eh69SG RUk7UIu/vny6wy6tHBq8tzO9Z+0TgG+v/WuHVr452gqyabH3oDrngnxalC53BYe6 Uq4SdTR+jY/8nPnc98MH3Moj0kU15pwilSci38rEeJdaUCKBKnmmcGrTvI5MyjcM LI8TiRsip5hd10+tE/hi/Tg/JuiDQ5mYxMxzUgB/iMMtaQ== =oWNK -END PGP SIGNATURE- Accepted: buffycli_0.7-1.diff.gz to main/b/buffycli/buffycli_0.7-1.diff.gz buffycli_0.7-1.dsc to main/b/buffycli/buffycli_0.7-1.dsc buffycli_0.7-1_all.deb to main/b/buffycli/buffycli_0.7-1_all.deb buffycli_0.7.orig.tar.gz to main/b/buffycli/buffycli_0.7.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sjxzl-00067m...@franck.debian.org
Accepted buffycli 0.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Wed, 10 Mar 2010 14:24:38 +0100 Source: buffycli Binary: buffycli Architecture: source all Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - a text mode alternative to Buffy Closes: 487858 573278 Changes: buffycli (0.5-1) unstable; urgency=low . * New upstream release. Closes: #487858, #573278 Update standards-version, fix lintian warning Checksums-Sha1: 356ac180931a36e16bcfe84ad76972e42cbdaf90 1102 buffycli_0.5-1.dsc 22d982096abf1297488283e5db10288c89d90bfc 16948 buffycli_0.5.orig.tar.gz 74df126689c8a9ef9402928dffedd0c0cf0e96c8 2907 buffycli_0.5-1.diff.gz 02b09d04adffba0d2cb731ff765465e6643e1780 10924 buffycli_0.5-1_all.deb Checksums-Sha256: a074e8a07b692a1f6d4c0fd1762c648145a496d30a1e387ff2c51155de73b213 1102 buffycli_0.5-1.dsc 9711e56749f883049111eccf29b2d6e6bfdc31db2b4a6ba0fd6f6c5230dea2f2 16948 buffycli_0.5.orig.tar.gz 4e624ac68fae23ad0c9c54ebea133e31c2e803910656f09567528de1ab7fcbbb 2907 buffycli_0.5-1.diff.gz a063b98a245ba67e23f1dd68b0a71b77d20a3b363095a6c9ca18ba20c13b5cda 10924 buffycli_0.5-1_all.deb Files: 06d59d30548ad704441e303146931ef1 1102 mail optional buffycli_0.5-1.dsc 2e32c4d53e732743d17d818f96599097 16948 mail optional buffycli_0.5.orig.tar.gz ba3cf3fc12e1ac4afa5a57fba067dae2 2907 mail optional buffycli_0.5-1.diff.gz ca0f55ea408164e65bbfc69d37425793 10924 mail optional buffycli_0.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkuXo+gACgkQIgvIgzMMSnUjQwCfXYvhlXk0FMQfV8dAck976Xtv 0J8AoLy5MEEUoJeE32QrQ/ZRR5laOd44 =XfNX -END PGP SIGNATURE- Accepted: buffycli_0.5-1.diff.gz to main/b/buffycli/buffycli_0.5-1.diff.gz buffycli_0.5-1.dsc to main/b/buffycli/buffycli_0.5-1.dsc buffycli_0.5-1_all.deb to main/b/buffycli/buffycli_0.5-1_all.deb buffycli_0.5.orig.tar.gz to main/b/buffycli/buffycli_0.5.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1npnu5-0005jt...@ries.debian.org
Accepted dwoo 1.1.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Tue, 09 Feb 2010 14:05:56 +1300 Source: dwoo Binary: dwoo Architecture: source all Version: 1.1.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: dwoo - PHP5 template engine Changes: dwoo (1.1.1-1) unstable; urgency=low . * Packaged new dwoo upstream release 1.1.1 Checksums-Sha1: b08148ae4713eb6de0cfb5fb91b980424279d9ab 1071 dwoo_1.1.1-1.dsc d813d0b3a25291eb04f231b67d44b3a4cfcbc9aa 456272 dwoo_1.1.1.orig.tar.gz 52a8bdcb768c17e4e8593daa74ab383d49a2a646 5230 dwoo_1.1.1-1.diff.gz 81b1aec3d6c9e6ab6135b2246775fb07cb61c634 475518 dwoo_1.1.1-1_all.deb Checksums-Sha256: 7c6b52e1911bb5e7a13f59dc4686045b584c36ee2bf7454811cede55bedd5a78 1071 dwoo_1.1.1-1.dsc 331f3931d0236cc49f0ee422fe7ac8af64d2a74f86aad6f92e5f05f61e520be3 456272 dwoo_1.1.1.orig.tar.gz b3defdc676486009ef5f17678b8b6a8631bff3cdeded99c3effbd316e00dd0aa 5230 dwoo_1.1.1-1.diff.gz 14046efc8c2f1226316f55a09c04c93c87180586f53870480a6e6fdacdf48502 475518 dwoo_1.1.1-1_all.deb Files: 9010da9a6f1ac91ca44f9e6f2d8c892d 1071 php optional dwoo_1.1.1-1.dsc eaef79eb1eac77f1bb0f0feee1ede747 456272 php optional dwoo_1.1.1.orig.tar.gz d9b590f79297e0767e41385e7e4289d5 5230 php optional dwoo_1.1.1-1.diff.gz c0a60a22f67708890cf0a9a17fa00718 475518 php optional dwoo_1.1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAktw21cACgkQIgvIgzMMSnXplgCg3yKELdyWJnBkdgmK3FVydsUl ga8AnjSw6e4IYnxpQC0+rggBm5TrhGbn =xfKg -END PGP SIGNATURE- Accepted: dwoo_1.1.1-1.diff.gz to main/d/dwoo/dwoo_1.1.1-1.diff.gz dwoo_1.1.1-1.dsc to main/d/dwoo/dwoo_1.1.1-1.dsc dwoo_1.1.1-1_all.deb to main/d/dwoo/dwoo_1.1.1-1_all.deb dwoo_1.1.1.orig.tar.gz to main/d/dwoo/dwoo_1.1.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted dwoo 1.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Wed, 04 Nov 2009 15:28:41 +0100 Source: dwoo Binary: dwoo Architecture: source all Version: 1.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: dwoo - PHP5 template engine Closes: 543241 Changes: dwoo (1.1-1) unstable; urgency=low . * Initial release (Closes: #543241) Checksums-Sha1: 24432bc828baac44d766c290924fa2af28651974 1057 dwoo_1.1-1.dsc a60e65fc7aa87ae5ca6450d8e9890acc423c43db 450060 dwoo_1.1.orig.tar.gz 56bf2fcdf0f2be4ed366bd485b11987bb39e6c28 5071 dwoo_1.1-1.diff.gz 74e2d9e2239aab29e2b1d0cff00166d99f772672 447986 dwoo_1.1-1_all.deb Checksums-Sha256: 1ed6981de6d29bb0cf07ac2ee2d0ff118f8c50a24d12fbc5f678401d09f3d024 1057 dwoo_1.1-1.dsc 0c45453d32ff429ad6a499b943f11b043458ab070db4c3cd370dff361d4a3da1 450060 dwoo_1.1.orig.tar.gz f94bfc71791b2bebd386980125b60793265c5cc2c57f5589556951fbaea6e46b 5071 dwoo_1.1-1.diff.gz 0531049116372bbe5f3a43f3b0874f0cca8e49a371f1bfa963a450ddbb582700 447986 dwoo_1.1-1_all.deb Files: cb3fa24972928fd7f4590f73944b3c8f 1057 php optional dwoo_1.1-1.dsc 26c80995643f6c54c0cfd7a4a514319e 450060 php optional dwoo_1.1.orig.tar.gz 9b03feac082b8dfc4dd7e30b92349326 5071 php optional dwoo_1.1-1.diff.gz 82a54660deace0b605a995e7dc614e17 447986 php optional dwoo_1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAksFHYAACgkQIgvIgzMMSnWPHQCgpP4mfww7EH6lmpbGrmrPt+WW PJUAn0AVFqye5ewoAICGneZ5YsRDHo84 =0DtW -END PGP SIGNATURE- Accepted: dwoo_1.1-1.diff.gz to main/d/dwoo/dwoo_1.1-1.diff.gz dwoo_1.1-1.dsc to main/d/dwoo/dwoo_1.1-1.dsc dwoo_1.1-1_all.deb to main/d/dwoo/dwoo_1.1-1_all.deb dwoo_1.1.orig.tar.gz to main/d/dwoo/dwoo_1.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
transitioning from a single to split package
[ please cc both me and the package team ] Hi debian-devel The Moodle package team is currently evaluating how to best upgrade the existing not very well working, and out of date package. Moodle is a webapp that works with both mysql and postgres. We currently have a single package that supports both (badly) and we're talking about migrating to a split package, using dbconfig-common. The problem we've come across is how to handle migrations. If we have a moodle package, that depends on moodle-mysql | moodle-pgsql, then package managers that just install the first dependency, could cause a situation, for example, where someone has configured their moodle installation to work on postgres, but the upgrade installs moodle-mysql, which is obviously a problem. We could detect this case in preinst, and complain bitterly and refuse to install, but that's going to break upgrades, so is obviously a no-goer. I think the best way to handle this, is stop having a moodle package at all, but instead have a moodle-common package, that depends on either moodle-mysql and moodle-pgsql. These two obviously depend on moodle-common, and conflict with each other, and all three new packages conflict with the old moodle package. This, I believe avoids the migration problem, and forces a manual installation. If we ship with a NEWS.Debian (inside moodle-common, I guess), which announces that one must manually install moodle-mysql or moodle-pgsql, is this a good enough way to migrate from a single to a split package without breaking the upgrade? Cheers, Penny -- /* --- Penny Leach | http://mjollnir.org | http://she.geek.nz GPG: 8347 00FC B5BF 6CC0 0FC9 AB90 1875 120A A30E C22B --- */ signature.asc Description: Digital signature
Re: transitioning from a single to split package
Hi, On Sun, Nov 01, 2009 at 08:01:20PM -0600, Raphael Geissert wrote: First of all, why do you want to split moodle? there's for example phpbb3 which uses dbconfig and allows multiple different DBMS as backends. Fair question. There's also quite a few packages that depend on dbconfig-common and have split between -mysql and -pgsql - to be honest, we thought that was the general direction packages were taking that supported both, but that may have been based on a faulty assumption. Personally, I think it's tidier, and less ambiguous for users. Second, why wouldn't users be allowed to install both, together, the -mysql and -pgsql versions? Well, that's logically equivalent to installing multiple versions of the same package. At the moment, there's one moodle installation, which has code that lives in /usr/share/moodle, and connects to one database. This is determined by its one config file. You can do tricks in the config file to fool Moodle into connecting to different databases, based on some rule (like virtualhost), but I don't see the use case here, and I don't think any other web applications support being installed multiple times, do they? Cheers, Penny -- /* --- Penny Leach | http://mjollnir.org | http://she.geek.nz GPG: 8347 00FC B5BF 6CC0 0FC9 AB90 1875 120A A30E C22B --- */ signature.asc Description: Digital signature
Accepted buffycli 0.4.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Thu, 22 Oct 2009 19:36:14 +0200 Source: buffycli Binary: buffycli Architecture: source all Version: 0.4.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - a text mode alternative to Buffy Changes: buffycli (0.4.1-1) unstable; urgency=low . * new upstream release, adds oikill Checksums-Sha1: f5178140b3cf4ec7da73b3f581234c1a95103a50 1116 buffycli_0.4.1-1.dsc 7e27aa73305c41b6c3f0bf511893b8d84e2ea2bd 16887 buffycli_0.4.1.orig.tar.gz 1e40adda68285690222dc7b40a4b4871d29402a6 2826 buffycli_0.4.1-1.diff.gz 96b008ed8eb65adf4d8abf0a586202e06dfab931 10780 buffycli_0.4.1-1_all.deb Checksums-Sha256: 91fbe0a643d480c8c76e6490edaee5c4b58e838d8858f89ca1487e3993a10159 1116 buffycli_0.4.1-1.dsc 279788fedc1856e54854bb7147d771ffb7cbb2b8d2f3c900ff263a073453fd0c 16887 buffycli_0.4.1.orig.tar.gz 9a965bc47de6981a500ef0460836ddd7864917c0727260c1a7ef4f6c29193b6a 2826 buffycli_0.4.1-1.diff.gz 85e8a3b3b20b4c9fe897a7b2f4bbe7f2ae003e2503b387c82c5349b96c9c6c66 10780 buffycli_0.4.1-1_all.deb Files: 702e01ef85672153add2c3aabe995612 1116 mail optional buffycli_0.4.1-1.dsc 1c2af3ac69daf4c506b3c01a0d1a13ca 16887 mail optional buffycli_0.4.1.orig.tar.gz 9f01d3570661766fc6d2f9efdaf0c6d3 2826 mail optional buffycli_0.4.1-1.diff.gz 4e50ba9511c3960677d62ddacfbc3aa2 10780 mail optional buffycli_0.4.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkrgm6wACgkQIgvIgzMMSnXjsgCgxMoYR/DwkCP93NpWh3HhOcS3 zQMAn0UQUH6A9ToO3UcZ2pNxULOrGGWb =Qsl0 -END PGP SIGNATURE- Accepted: buffycli_0.4.1-1.diff.gz to pool/main/b/buffycli/buffycli_0.4.1-1.diff.gz buffycli_0.4.1-1.dsc to pool/main/b/buffycli/buffycli_0.4.1-1.dsc buffycli_0.4.1-1_all.deb to pool/main/b/buffycli/buffycli_0.4.1-1_all.deb buffycli_0.4.1.orig.tar.gz to pool/main/b/buffycli/buffycli_0.4.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543241: ITP: dwoo -- PHP5 template engine
Package: wnpp Severity: wishlist Owner: Penny Leach pe...@mjollnir.org * Package name: dwoo Version : 1.1.0 Upstream Author : Jordi Boggiano s...@seld.be * URL : http://dwoo.org * License : Modified BSD Programming Lang: PHP Description : PHP5 template engine Dwoo is a PHP5 template engine positioned as an alternative to Smarty, it is (nearly) fully compatible with Smarty's templates and plugins, but it is written from scratch and aimed at going one step further with a cleaner codebase. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted buffycli 0.4-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Sat, 25 Jul 2009 16:42:36 +0200 Source: buffycli Binary: buffycli Architecture: source all Version: 0.4-2 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - a text mode alternative to Buffy Changes: buffycli (0.4-2) unstable; urgency=low . * update standards version to 3.8.2 . buffycli (0.4-1) unstable; urgency=low . * new upstream release, adds terminal title Checksums-Sha1: a258e499cb606fcf9eaa4d1cfd2c714e057ef349 1101 buffycli_0.4-2.dsc f2facf7f7ad1f45be7f94b73872439dbe7715205 16852 buffycli_0.4.orig.tar.gz 717ab4ff7cf56557af6d124d465e15299144f136 2788 buffycli_0.4-2.diff.gz 490f459048c1a483d1aaf6201c97e033aaa33988 10728 buffycli_0.4-2_all.deb Checksums-Sha256: f31f766f1c4abe30c5eeb800a0d09ef0cb9ceed15cfb0617eb9b3d78430addd2 1101 buffycli_0.4-2.dsc 8eabc5ddff637927eae48645218153771a8764ad7d9d0eb58e79b87c760adfe2 16852 buffycli_0.4.orig.tar.gz fce50e26da51134f5d12827d987d9b1967e0f58eafed80dfba91eeb7f1c2ffcc 2788 buffycli_0.4-2.diff.gz c7235bc51a73daa8cff4cdbaa42c21ca87edc839b01c9688d5ddf5aa32db2841 10728 buffycli_0.4-2_all.deb Files: d3eb8bd3afe6c41e7c22ccc9d8c6e28d 1101 mail optional buffycli_0.4-2.dsc 1a11413e902dfe23d3539e5d49233940 16852 mail optional buffycli_0.4.orig.tar.gz 9782bb812c51df70b01ff079f642b7a9 2788 mail optional buffycli_0.4-2.diff.gz 67db18f300a4b0f0f029d1570d12131f 10728 mail optional buffycli_0.4-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkprPiYACgkQIgvIgzMMSnUGRQCgjPVkMXkUNnMqCCE01osvDEHZ XwEAnijL7U2OJyH2elo8TZe12t49F65T =zlTf -END PGP SIGNATURE- Accepted: buffycli_0.4-2.diff.gz to pool/main/b/buffycli/buffycli_0.4-2.diff.gz buffycli_0.4-2.dsc to pool/main/b/buffycli/buffycli_0.4-2.dsc buffycli_0.4-2_all.deb to pool/main/b/buffycli/buffycli_0.4-2_all.deb buffycli_0.4.orig.tar.gz to pool/main/b/buffycli/buffycli_0.4.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted buffycli 0.3.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 22 Feb 2009 12:43:06 +0100 Source: buffycli Binary: buffycli Architecture: source all Version: 0.3.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - a text mode alternative to Buffy Changes: buffycli (0.3.1-1) unstable; urgency=low . * new upstream release, one tiny bugfix since 0.3 Checksums-Sha1: 02fd7b28adc09466c2aba783af91842cc71218d4 1110 buffycli_0.3.1-1.dsc 9fc8d96a0ffa16f1cc9c989cbfedbabdc6c0f3fb 16759 buffycli_0.3.1.orig.tar.gz 69e19b75a2b1614ffcf0661ebf30cfdeebea224a 2692 buffycli_0.3.1-1.diff.gz 7a9874de7335c7fe3e2f15e27c548c5cb2f72752 10490 buffycli_0.3.1-1_all.deb Checksums-Sha256: 2c1256bad8b03b5551e9f7c44afa167c782ee02c2b1518af84b845339ab8042a 1110 buffycli_0.3.1-1.dsc 30a67a766e01ff82efb21e7af53a7c3c6a1bc1c571a3f5a6b9766296dcaa4a78 16759 buffycli_0.3.1.orig.tar.gz 91e3920826c3ada1144e62af310c0352d4421d03affd12e2d9586325d7164ca1 2692 buffycli_0.3.1-1.diff.gz e4142fdd6caee317d74b62f63720f3c2ee958c3dfcb95d5adc36e66a28765202 10490 buffycli_0.3.1-1_all.deb Files: 36400d02dc3a20726833e1160fcf7ce1 1110 mail optional buffycli_0.3.1-1.dsc d2834c9f1ca227b46623cc4f26cdcd10 16759 mail optional buffycli_0.3.1.orig.tar.gz 6914a4aeeba2db96c024d6ff4befcbf3 2692 mail optional buffycli_0.3.1-1.diff.gz e0554cf241b833dd4604c2ae4fc9b522 10490 mail optional buffycli_0.3.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmhPTEACgkQIgvIgzMMSnWgNQCdErU2ATTkkyatOms4TCID/Vs7 jTsAoOSt+BWI289sSs9lS7rPldZpNlKu =B0C0 -END PGP SIGNATURE- Accepted: buffycli_0.3.1-1.diff.gz to pool/main/b/buffycli/buffycli_0.3.1-1.diff.gz buffycli_0.3.1-1.dsc to pool/main/b/buffycli/buffycli_0.3.1-1.dsc buffycli_0.3.1-1_all.deb to pool/main/b/buffycli/buffycli_0.3.1-1_all.deb buffycli_0.3.1.orig.tar.gz to pool/main/b/buffycli/buffycli_0.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted buffycli 0.3.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 22 Feb 2009 15:46:57 +0100 Source: buffycli Binary: buffycli Architecture: source all Version: 0.3.2-1 Distribution: unstable Urgency: low Maintainer: Penny Leach pe...@mjollnir.org Changed-By: Penny Leach pe...@mjollnir.org Description: buffycli - a text mode alternative to Buffy Changes: buffycli (0.3.2-1) unstable; urgency=low . * new upstream point release,added setting for showing/hiding totals row Checksums-Sha1: 1dc3114cc14182092fac48786eaa436b62a17556 1110 buffycli_0.3.2-1.dsc 3775643f151fd5619bc5645425f5d563543dd4cf 16843 buffycli_0.3.2.orig.tar.gz e6fd6eb3c2b3b4304cecd922d970ffe4156eef89 2735 buffycli_0.3.2-1.diff.gz aacc7abf0a2c645367d214ea915890eb087aebee 10642 buffycli_0.3.2-1_all.deb Checksums-Sha256: 4a3db1b6388405c32e0eb8d2ea9c016fb2cce64a644fe630833a4b14433a41da 1110 buffycli_0.3.2-1.dsc a61f4c634e5fb8f074759b28c47d03b7558a711d90110b7f550f6b4fbf8236aa 16843 buffycli_0.3.2.orig.tar.gz 39dfd4afd0449b2f860a6d7ce411350adddc29646d058468f3af59f9f488ae4e 2735 buffycli_0.3.2-1.diff.gz c023b4543e4061110f80755fc6b575969da0d3e9aabc932c8cb3379ca8369ec3 10642 buffycli_0.3.2-1_all.deb Files: 1a857f578f0a8c4a6c9dfe2b26f92bf6 1110 mail optional buffycli_0.3.2-1.dsc 6488c2a24a6d7f2dc0801090da2b4b60 16843 mail optional buffycli_0.3.2.orig.tar.gz 97b6ea44adbc53ae5395f4ab234cf48a 2735 mail optional buffycli_0.3.2-1.diff.gz ab9ac32b4713bc16bc184d72d6db3a97 10642 mail optional buffycli_0.3.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmhZyMACgkQIgvIgzMMSnW+SQCglTngJeyYQ1Klq5F8uwmd/kdB OP4Anjfoj0Vu/fEoa/RD1BXh43QZomwy =dpVi -END PGP SIGNATURE- Accepted: buffycli_0.3.2-1.diff.gz to pool/main/b/buffycli/buffycli_0.3.2-1.diff.gz buffycli_0.3.2-1.dsc to pool/main/b/buffycli/buffycli_0.3.2-1.dsc buffycli_0.3.2-1_all.deb to pool/main/b/buffycli/buffycli_0.3.2-1_all.deb buffycli_0.3.2.orig.tar.gz to pool/main/b/buffycli/buffycli_0.3.2.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted buffycli 0.2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 24 Jul 2008 18:32:28 +0100 Source: buffycli Binary: buffycli Architecture: source all Version: 0.2.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach [EMAIL PROTECTED] Changed-By: Penny Leach [EMAIL PROTECTED] Description: buffycli - a text mode alternative to Buffy Changes: buffycli (0.2.1-1) unstable; urgency=low . * new upstream release * fixes regression introduced in 0.2 which 'fixed' #490431 Checksums-Sha1: 5cab2066d4ff29f78601a424db6d6b1626a405af 1061 buffycli_0.2.1-1.dsc 328bb7e83f7b0d459667c5d6b0afd70c34b754dd 16551 buffycli_0.2.1.orig.tar.gz 1d8c664a25873993aa48bc0de6c5abec6e9ce7d0 2035 buffycli_0.2.1-1.diff.gz 6eaaf83e9f976cc96b58c02e9ed425f321ebe1c1 9548 buffycli_0.2.1-1_all.deb Checksums-Sha256: bdddc13d8f2e2fead458163a6122b6a4d7cfe4629a0792e2f4a88c4725001d7c 1061 buffycli_0.2.1-1.dsc d75dd0deba07e083dbcfe7d49cc1b4a4a53cc23bba51ff9d73892dc1708941ae 16551 buffycli_0.2.1.orig.tar.gz f3b8c0bb1bfb207f72738eb1d31b444c024ff1f1a903ee14d204e06267cdcab6 2035 buffycli_0.2.1-1.diff.gz d9441d228cd0a67fed9ea3a882f7af014c8b9d5499b60a812a0c50f6c9bdde0d 9548 buffycli_0.2.1-1_all.deb Files: c3203ae50aebefaae63278c939781352 1061 mail optional buffycli_0.2.1-1.dsc edbf41a36fdadce95c8c3d7eb26b6ca3 16551 mail optional buffycli_0.2.1.orig.tar.gz e20aaec2613176b49c3ccb4370dacf80 2035 mail optional buffycli_0.2.1-1.diff.gz 93c804650c01bc603720ae523697c0aa 9548 mail optional buffycli_0.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiJheAACgkQIgvIgzMMSnVuwwCfRBra6+2Es4SEAK2s86lIKHIV UKYAoKo2OU1kB/K6PHDxZeJnfqYR6eeC =GU4x -END PGP SIGNATURE- Accepted: buffycli_0.2.1-1.diff.gz to pool/main/b/buffycli/buffycli_0.2.1-1.diff.gz buffycli_0.2.1-1.dsc to pool/main/b/buffycli/buffycli_0.2.1-1.dsc buffycli_0.2.1-1_all.deb to pool/main/b/buffycli/buffycli_0.2.1-1_all.deb buffycli_0.2.1.orig.tar.gz to pool/main/b/buffycli/buffycli_0.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted buffycli 0.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 25 Jun 2008 00:59:05 +1200 Source: buffycli Binary: buffycli Architecture: source all Version: 0.1-1 Distribution: unstable Urgency: low Maintainer: Penny Leach [EMAIL PROTECTED] Changed-By: Penny Leach [EMAIL PROTECTED] Description: buffycli - a text mode alternative to Buffy Closes: 487840 Changes: buffycli (0.1-1) unstable; urgency=low . * Initial release (Closes: #487840) Checksums-Sha1: 21799d40d63fe11bb8307f1fef70f298966d445a 1047 buffycli_0.1-1.dsc 15f8cc8f12bd33ca2246f6d9002d455d2fe8c438 16791 buffycli_0.1.orig.tar.gz a26bc256731970e78484dedf863ea38877ee4306 1920 buffycli_0.1-1.diff.gz 5cd051680b30886f868ed3d7b64958ff9f17b087 9646 buffycli_0.1-1_all.deb Checksums-Sha256: 73f5bb63efd5e99a5a6d7479b9b955cf19ff95cf9bee3c393049b332fdcead6e 1047 buffycli_0.1-1.dsc 3f9478e1b03133102ea3aad1b97489db56a1aa8568a9813eb8d550b915af7447 16791 buffycli_0.1.orig.tar.gz f59a0a2b49f1e5a27fa0b545cf82cca92fe718c0606bc449cbc0feeac9cb5da7 1920 buffycli_0.1-1.diff.gz 47e4313083fa0bca830cb9b463c751c3f63adc0dd52bc8846201bfda15296175 9646 buffycli_0.1-1_all.deb Files: 25d6b3d745559107381d6c1914f547d5 1047 mail optional buffycli_0.1-1.dsc 200b1e2139667fa682a29cd6e2f2bcd7 16791 mail optional buffycli_0.1.orig.tar.gz ff48598965b8c14463279c526d7aedb1 1920 mail optional buffycli_0.1-1.diff.gz e2dda4f8d5ad9661988cdf90f5ad9ac5 9646 mail optional buffycli_0.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh1r8sACgkQIgvIgzMMSnUmcwCdH2KkIwLmlzcCO4DpqXGRd2Pe 9BwAn18IxYa5CIQrj0QIo/qgqZdmvC58 =0Rpn -END PGP SIGNATURE- Accepted: buffycli_0.1-1.diff.gz to pool/main/b/buffycli/buffycli_0.1-1.diff.gz buffycli_0.1-1.dsc to pool/main/b/buffycli/buffycli_0.1-1.dsc buffycli_0.1-1_all.deb to pool/main/b/buffycli/buffycli_0.1-1_all.deb buffycli_0.1.orig.tar.gz to pool/main/b/buffycli/buffycli_0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487840: ITP: buffycli -- Buffycli is a command line alternative to Buffy
Package: wnpp Severity: wishlist Owner: Penny Leach [EMAIL PROTECTED] * Package name: buffycli Version : 0.1 Upstream Author : Penny Leach [EMAIL PROTECTED] * URL : * License : GPL Programming Lang: Perl Description : Buffycli is a command line alternative to Buffy Buffy is a program that displays a compact summary of your mail folders, and allows to invoke a command (usually a mail reader) on them. It is written with the intent of being a handy everyday tool for people handling large volumes of mail. For mutt users, this can be a nice front-end to supplement the simple built-in folder browser when one has many folders to keep track of. . Buffy tries hard to work out of the box: it looks for mail folders in sensible places and comes with reasonable defaults. . The program is functional but still very young, and only Maildir and Mailbox format are supported at the moment. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-vserver-686 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
On 5/26/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: While you're obviously free to set your own standards as to whose keysyou sign and not, I have come to the conclusion that the exact samespelling requirement doesn't make that much sense.As an example, take Bdale whose real name isn't Bdale, but Barksdale Garbee III (iirc, it'sbeen some time since I last saw his passport, apologies if for anymisspellings, etc).He goes by the name of Bdale and more people know him by that name than by Barksdale, so signing his key based on thismakes sense.The same goes for middle names people never use, etc.Me too. My passport and NZ Driver's License both say Penelope, but I have gone by Penny all my life, and that's the name on my key. I'm pretty sure there were people at Debconf5 who didn't sign my key because of this. That's fine, everyone is entitled to their choice, although it struck me as a little bit silly. Penny is clearly short for Penelope. Perhaps this was my bad when I made the key displayed a lack of foresight. This is probably not really a useful contribution to this discussion; carry on.Penny-- context: http://she.geek.nz || http://catalyst.net.nz
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
On 5/27/06, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Only if you are reasonably well acquinted with the English language andusual english names and nicknames.This is true. One of the people at Debconf 5 I was thinking of, whose name I absolutely have no idea of anymore, was either a native english speaker or pretty fluent. You are of course, correct, but it's not the case in this specific example. There is nothing stopping you from adding a new user-id with your full name and the same email address as you have in your Penny Leach user-id.Infact, I suggest you do so and add that user-id.People can chose which oneto sign, they are not forced to sign all user-ids in a key... Perhaps, but it raises all sorts of questions about identity that are probably off topic here. Apart from anything else, I don't identify with the name 'Penelope' at all. Clearly, my gmail address is penelope.leach, that's because most non numeric variations on 'Penny' were all taken :)I frequently find that people I have known for years never knew my name was Penelope. Perhaps they would refuse to sign the Penelope uid because they have always known me as Penny? It doesn't bother me enough to add a Penelope uid, just another element to the issue of trying to verify identity.-- context: http://she.geek.nz || http://catalyst.net.nz
Bug#312413: ITP: serendipity -- PHP Weblog/Blog software
Package: wnpp Severity: wishlist * Package name: serendipity Version : 0.8.1 Upstream Author : Jannis Hermanns [EMAIL PROTECTED] * URL : http://www.s9y.info/ * License : BSD Description : PHP Weblog/Blog software PHP blog with all the common features (comments,track/pingbacks,RSS) plus cool extras:Click'n' blog admin,extensible event-driven plugin API,easy styling, multiuser,image management,static pregeneration and a nifty installer: unpack, open in browser! -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.25-1-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hey man, stop throwing away your money
Hey man, stop throwing away your money http://www.prumie.net/ss/ Wanna be more man? Check this dude -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ploticus 2.20-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 Apr 2004 22:12:00 -0500 Source: ploticus Binary: ploticus Architecture: source i386 Version: 2.20-3 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: ploticus - A script driven business graphics package Closes: 240560 Changes: ploticus (2.20-3) unstable; urgency=low . * Add late fix for errbarfields. Fix found in http://groups.yahoo.com/group/ploticus/message/691. Solves a problem with asymetric error bands. * Add late fix for proc_axis.c. Fix found in http://groups.yahoo.com/group/ploticus/message/722 This solves a problem with cumulative rounding of days in graphs with days stubs. * Add late fix version of chunk_area. Fix from http://ploticus.sourceforge.net/download/chunk_area This solves a problem with dates with no day number, as mm/. * Add late fix version of heatarea.pl. Fix from http://ploticus.sourceforge.net/download/heatmap.pl * Add late fix version of proc_getdata.c. Fix found at http://ploticus.sourceforge.net/download/proc_getdata.c This permits comma delimited files with more than 255 characters per row to be processed. * Add late fix version of proc_lineplot.c. This is from http://ploticus.sourceforge.net/download/proc_lineplot.c It clips labels, and handles the degenerate case of no points in the range properly. * Add pltestsuite to debian package as /usr/share/doc/ploticus/examples * Remove recommends of libming-fonts-openoffice. The package has been removed from debian. closes: Bug#240560 Files: ef1905393ab8eaa96bd2d684321eeed6 652 misc optional ploticus_2.20-3.dsc c863d74193966fdb6358410f6274a4ee 17473 misc optional ploticus_2.20-3.diff.gz c14a217691e49267e8e2c628f9eea207 256776 misc optional ploticus_2.20-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAcM2zqjfbISpbKw0RAqWtAJ4nHYd2AFKtSsXWvFA+y+O5a7ZLtQCeIoAU GI/MaTTaqjbbDp8Fi6F/VpM= =KUZD -END PGP SIGNATURE- Accepted: ploticus_2.20-3.diff.gz to pool/main/p/ploticus/ploticus_2.20-3.diff.gz ploticus_2.20-3.dsc to pool/main/p/ploticus/ploticus_2.20-3.dsc ploticus_2.20-3_i386.deb to pool/main/p/ploticus/ploticus_2.20-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zope-zshell 1.60-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 08 Feb 2004 23:24:20 -0500 Source: zope-zshell Binary: zope-zshell Architecture: source all Version: 1.60-2 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: zope-zshell - command line interface to Zope Closes: 219113 225251 225784 Changes: zope-zshell (1.60-2) unstable; urgency=low . * Thanks Luca for NMU. * Added ja.po. (Closes: #225784) * Adam Kessel improved zshellcle - python version was fixed (Closes: #225251) * from NMU, upstream, work with python 1.5.2(Closes: #219113) Files: 953310693d85b3e22410c4c03701ad9f 582 web optional zope-zshell_1.60-2.dsc 30df22aa5d64fc9d689a963f1a85a051 12113 web optional zope-zshell_1.60-2.diff.gz 7115fdaddbbebec965262fac6f121f01 55340 web optional zope-zshell_1.60-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAKFxMqjfbISpbKw0RAhPPAJ49kpaEtUvz//X07SXv7c4gvgkB4ACgmdz+ +qljOLOxw2xl8i1s2yp79u8= =SorL -END PGP SIGNATURE- Accepted: zope-zshell_1.60-2.diff.gz to pool/main/z/zope-zshell/zope-zshell_1.60-2.diff.gz zope-zshell_1.60-2.dsc to pool/main/z/zope-zshell/zope-zshell_1.60-2.dsc zope-zshell_1.60-2_all.deb to pool/main/z/zope-zshell/zope-zshell_1.60-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ploticus 2.20-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Jan 2004 22:33:00 -0500 Source: ploticus Binary: ploticus Architecture: source i386 Version: 2.20-2 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: ploticus - A script driven business graphics package Closes: 228983 Changes: ploticus (2.20-2) unstable; urgency=low . * libming has been removed from the distribution, drop swf support. closes: Bug#228983 Files: a9c843c465ac26fa159e700cfa4cbda4 652 misc optional ploticus_2.20-2.dsc 897c97ff65c7b31270911e5bc6eae388 12052 misc optional ploticus_2.20-2.diff.gz 6bd18f6cce9b891b7381505bd859e210 170620 misc optional ploticus_2.20-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAD0UMqjfbISpbKw0RAiGVAKCRUTo6wT6mOO0gNc57wRwiO2K+/gCgzHc7 8WPEDTFs7xluA85k1nVHGzc= =/uFT -END PGP SIGNATURE- Accepted: ploticus_2.20-2.diff.gz to pool/main/p/ploticus/ploticus_2.20-2.diff.gz ploticus_2.20-2.dsc to pool/main/p/ploticus/ploticus_2.20-2.dsc ploticus_2.20-2_i386.deb to pool/main/p/ploticus/ploticus_2.20-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ploticus 2.20-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 25 Dec 2003 10:41:14 -0500 Source: ploticus Binary: ploticus Architecture: source i386 Version: 2.20-1 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: ploticus - A script driven business graphics package Changes: ploticus (2.20-1) unstable; urgency=low . * New upstream.closes: Bug #197293 Files: 3cd24f726604553f35ce15362319afba 665 misc optional ploticus_2.20-1.dsc 9072fb6a29e79eb4be0ed60f9b16bd17 397663 misc optional ploticus_2.20.orig.tar.gz 6a9751ca7eeff98586e767075f10340e 12195 misc optional ploticus_2.20-1.diff.gz e964772cf0c286483696c2f19924579a 174094 misc optional ploticus_2.20-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/6xJRqjfbISpbKw0RAkpbAJsEVD0W2nn87vO12o36MpwRym4bDACgtLfU jreQ4V+Rb0FES9a8xWWS27Y= =V5T9 -END PGP SIGNATURE- Accepted: ploticus_2.20-1.diff.gz to pool/main/p/ploticus/ploticus_2.20-1.diff.gz ploticus_2.20-1.dsc to pool/main/p/ploticus/ploticus_2.20-1.dsc ploticus_2.20-1_i386.deb to pool/main/p/ploticus/ploticus_2.20-1_i386.deb ploticus_2.20.orig.tar.gz to pool/main/p/ploticus/ploticus_2.20.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, 18 Dec 2003 13:42:23 -0500 Branden Robinson [EMAIL PROTECTED] wrote: Actually, I think daemons first showed up in the _Fiend Folio_, which means we have the British to thank for this confusion. ;-) What about Maxwell's daemon? This is usually thought to be the computer origin of the term. 19th Century. http://ei.cs.vt.edu/~history/Daemon.html Jim Penny
Re: rice doc status
On Fri, 7 Nov 2003 15:55:25 -0500 [EMAIL PROTECTED] wrote: I don't know if you are virused, or if your sender has been spoofed, or what. Anyway, you might want to look into this. You appear to be spewing odd word documents people you don't know. Jim Penny -Original Message- From: Melody,Thomas,GREENWICH,Information Services Sent: Wednesday, November 05, 2003 3:09 PM To: Winters,John,GREENWICH,Information Services Cc: Fine,Paul,GREENWICH,Information Systems Subject:FW: rice doc status John, Was this completed ? Tom -Original Message- From: Fine,Paul,GREENWICH,Information Systems Sent: Wednesday, November 05, 2003 2:48 PM To: Melody,Thomas,GREENWICH,Information Services Subject:rice doc status Tom, I am unsure if you have this rice doc or not If not here it is...it is to copy the ship-to to the shipment doc in dv3 240 Thanks Paul Fine Nest Data Transfer for shipto.doc e Waters North America SAP Analyst Phone-203-629-7234 Pager-1-888-22-WATER
Accepted drawmap 2.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 6 Nov 2003 22:43:00 -0500 Source: drawmap Binary: drawmap Architecture: source i386 Version: 2.5-1 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: drawmap- draws customized maps, using raw USGS data files Closes: 219081 Changes: drawmap (2.5-1) unstable; urgency=low . * New upstream release closes: Bug#219081 * See /usr/share/doc/drawmap/WHATS_NEW for list of upstream modifications Files: d88d8405e579761253d2148d81202fc4 563 math optional drawmap_2.5-1.dsc ff82c1d36fe943b818ec216a99957236 249257 math optional drawmap_2.5.orig.tar.gz 23a9f87acd86a42399b8f0259e6dac0a 8401 math optional drawmap_2.5-1.diff.gz 3d1c958d4d7127c4eecf148edac6d896 196338 math optional drawmap_2.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qxsmqjfbISpbKw0RAmpJAJ9qhNimjWbCc0eCzEtequ8D54plFQCgl4Ph c+mH4ytABMIIM2LVKlTYp7E= =Jzkp -END PGP SIGNATURE- Accepted: drawmap_2.5-1.diff.gz to pool/main/d/drawmap/drawmap_2.5-1.diff.gz drawmap_2.5-1.dsc to pool/main/d/drawmap/drawmap_2.5-1.dsc drawmap_2.5-1_i386.deb to pool/main/d/drawmap/drawmap_2.5-1_i386.deb drawmap_2.5.orig.tar.gz to pool/main/d/drawmap/drawmap_2.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing python-pygresql and libpqpp packages
On Fri, 10 Oct 2003 14:46:15 +0100 Oliver Elphick olly@lfix.co.uk wrote: Barring objection, and there may be some legitimate objection, as I am well behind and feeling mighty damned guilty about it, I will pick it up. This is somewhat natural because I am already PoPy packager, and PoPy is being merged into pygresql. Jim Penny This is not strictly orphaning, more infanticide. I'm not sure conventional orphaning fits, since the source package is not being orphaned. The PostgreSQL python interface (python-pygresql) has been separated upstream into its own source tree. Since it no longer needs to be built with postgresql itself, and since I do not use python, the python binaries will no longer be built when postgresql 7.4 is released (in a few weeks).
Re: 2.5/2.6 IPsec stack should live in a kernel-patch!
On Thu, 2 Oct 2003 01:38:45 +0200 [EMAIL PROTECTED] (Domenico Andreoli) wrote: On Wed, Oct 01, 2003 at 05:38:51PM -0500, Steve Langasek wrote: [ObPrivate: this doesn't belong on private. Quote me freely.] On Wed, Oct 01, 2003 at 11:56:14PM +0200, martin f krafft wrote: Thus I propose that Herbert should remove the IPsec patch and make it a separate kernel-patch. If anyone has other objections than I won't do it because it's my choice, I don't feel like it, and there is nothing you can do about it, then please speak up. On the other hand, if you agree with me, let your voice be heard! i'm interested only in the debian kernel without 2.5/2.6 IPsec. in my mind this should be vanilla kernel + debian fixes. But 2.5/2.6 include IPSEC in the vanilla kernel! Jim Penny
Re: music sheet
On Tue, 9 Sep 2003 08:14:59 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. - Matt The problem, amazingly enough, is that he did google for dueling banjos sheet music, and Debian is the number one and number two hit! This has become a self-perpetuating google-flop. People google, google points them to Debian to get this sheet music, and the act of asking reinforces google's notion that debian is a good place to get the music! Jim Penny
Accepted python-popy 2.0.8-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 19 Aug 2003 22:00:22 -0400 Source: python-popy Binary: python2.2-popy python2.3-popy python-popy python2.1-popy Architecture: source i386 Version: 2.0.8-7 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: python-popy - empty package moving default python-popy package to python2.3 python2.1-popy - module providing access to PostgreSQL from Python2.1 python2.2-popy - module providing access to PostgreSQL from Python2.2 python2.3-popy - module providing access to PostgreSQL from Python2.3 Closes: 205750 Changes: python-popy (2.0.8-7) unstable; urgency=low . * change to mirror default python becoming 2.3.closes: Bug# 205750 Files: 51dbbaa59f861704fa1785c47ddf17b5 699 libs optional python-popy_2.0.8-7.dsc 7e7b937c5d2d8d39b6e9350b889ec748 26518 libs optional python-popy_2.0.8-7.diff.gz 2be356494e06b2c93543cf75de51fbf6 6292 libs optional python-popy_2.0.8-7_i386.deb 2158447942b425fe2f392e0aa8cb7985 16638 libs optional python2.1-popy_2.0.8-7_i386.deb 23ff4354d144e8b1961a257b49102a03 16672 libs optional python2.2-popy_2.0.8-7_i386.deb 8f5958f03f32a27cf4a6c390a5924fc4 16670 libs optional python2.3-popy_2.0.8-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QtvgqjfbISpbKw0RAg0gAKCN+HCFIxaP+wDPAjptZJ93TnS1pgCfcGn6 +LfMhy042QeVRSB7WoAEVJQ= =CQ0P -END PGP SIGNATURE- Accepted: python-popy_2.0.8-7.diff.gz to pool/main/p/python-popy/python-popy_2.0.8-7.diff.gz python-popy_2.0.8-7.dsc to pool/main/p/python-popy/python-popy_2.0.8-7.dsc python-popy_2.0.8-7_i386.deb to pool/main/p/python-popy/python-popy_2.0.8-7_i386.deb python2.1-popy_2.0.8-7_i386.deb to pool/main/p/python-popy/python2.1-popy_2.0.8-7_i386.deb python2.2-popy_2.0.8-7_i386.deb to pool/main/p/python-popy/python2.2-popy_2.0.8-7_i386.deb python2.3-popy_2.0.8-7_i386.deb to pool/main/p/python-popy/python2.3-popy_2.0.8-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Jim Penny who has in past lives spent far too many hours playing nethack
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, 30 Jul 2003 11:38:12 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2003 at 05:56:32PM +0200, Emile van Bergen wrote: I object to this ITP. Not very strongly, but I still object. I think it's a wonderful idea to have a decss package in Debian. If Debian cannot distribute the decss that allows Debian users to view DVD movies (yet), then distributing this one is a good alternative, I'd say. You're clearly quite mad. Regardless of whether this script is trivial to implement, it's not something anyone should be encouraged to actually*use*. CSS is the *best* feature of the HTML4 standard. Why would anyone in their right mind wish to strip nearly all the logical structure markup out of a document? Uhh, it is to tweak the international copyright cartel, and the RIAA in particular. They have written cease and desist letters to anyone who has a file names deCSS on their system. This is an attempt to make such a filename so common that these letters are pointless, and possibly evidence of illegal activity. Jim Penny
Re: Debconf or not debconf
On Wed, 02 Jul 2003 22:25:26 +0200 Thomas Viehmann [EMAIL PROTECTED] wrote: Jim Penny wrote: Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. What is difficult to test in ssl connections fail? I routinely test mine with telnet-ssl or python scripts (though I remember something about python and IMAP SSL not too long ago)... Well, you have to have a place to launch the scripts from. It the tunnel is at the edge, and listening only to the outward-facing interface, or it is listening only to localhost, and you don't want to have the testing tools on your firewall, or ... Also, the silentness would IMHO be better fixed by adding a big fat NOT to the init script (although anything more than a NOT will be controversial as well...). Reminds me of something I should fix for my packages... This is a completely different complaint, more of an aside that should never have been raised here. It has nothing to do with the change in format of configuration information, debconf-ing or not debconf-ing. It has to do with the experience of making repeated changes to the configuration file, while feeling under some time pressure, running/etc/init.d/stunnel restart, seeing no output, and thinking silence is golden. You know, the usual Unix tradition. Jim Penny
Re: Debconf or not debconf
On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. Jim Penny -- Steve Langasek postmodern programmer
Re: Debconf or not debconf
On Wed, 2 Jul 2003 15:57:01 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 02, 2003 at 10:50:29AM -0400, Jim Penny wrote: On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. I was aware of the issue, because I had looked at the upgrade for Windows users. I still got mildly bitten by this upgrade. I would prefer to have a hard stop message. Jim Penny
Accepted zope-zshell 1.5-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Jun 2003 22:26:45 -0400 Source: zope-zshell Binary: zope-zshell Architecture: source all Version: 1.5-2 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: zope-zshell - command line interface to Zope Changes: zope-zshell (1.5-2) unstable; urgency=low . * Correspondence with upstream with upstream yielded a solution to problem of end-of-file not closing zshellcli script. Tested and working. Man page changed accordingly. * Wrong depends. Does not depend on python-xmlrpc. Depends rather on Fredrik Lundh's xmlprclib, which is a standard part of python 2.2 and later. Files: 9580aebf54d74037ab052919bc91e722 578 web optional zope-zshell_1.5-2.dsc eec847f0ed26b38a0308538a941b72b1 6043 web optional zope-zshell_1.5-2.diff.gz 9354e5b5c40f7de50741e78353831f96 50262 web optional zope-zshell_1.5-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE++l0jqjfbISpbKw0RAqcZAKCOpVy2RYuyt/CYXVeQ5Qim5yQ7vQCeOYig ZZorKvglL+XGeGzw0Ftjxjo= =j+EG -END PGP SIGNATURE- Accepted: zope-zshell_1.5-2.diff.gz to pool/main/z/zope-zshell/zope-zshell_1.5-2.diff.gz zope-zshell_1.5-2.dsc to pool/main/z/zope-zshell/zope-zshell_1.5-2.dsc zope-zshell_1.5-2_all.deb to pool/main/z/zope-zshell/zope-zshell_1.5-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? No, actually, that is ambiguous. Read literally, it means that only software source similar to GNU Autoconf can be configured with this tool. You really mean: A tool, similar to GNU Autoconf, for configuring software Admittedly this is ugly. It may also be really inaccurate. I have no idea of how similar to GNU Autoconf the tool is. I hope that it is not very similar at all. Perhaps: A tool to configure software (GNU Autoconf also has this purpose) Jim Penny
Accepted zope-zshell 1.5-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 21 Jun 2003 17:33:52 -0400 Source: zope-zshell Binary: zope-zshell Architecture: source all Version: 1.5-1 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: zope-zshell - command line interface to Zope Closes: 133560 168994 184462 193158 Changes: zope-zshell (1.5-1) unstable; urgency=low . * New upstream version (sorry it took so long to package) closes: Bug#193158 * ZShellCLI working, named zshellcli in debiancloses: Bug#133560 * Support for new zope packaging (single INSTANCEHOME) * change in dependency due to zshellcli - now depends on python2.2:, as well as python2.1. * change short descriptioncloses: Bug#168994 * Change copyright, thanks josh for NMU. Note, the license addendum has been removed by upstream. closes: Bug#184462 Files: 9152946a237a1e22729ad48bd9e94813 578 web optional zope-zshell_1.5-1.dsc 0381be3715211b7fb5d1a9fcf9f8bdd1 48347 web optional zope-zshell_1.5.orig.tar.gz c6952f8c91dd683e4f2acbd05461ddc7 5762 web optional zope-zshell_1.5-1.diff.gz 18fb9e52ed788488ebd98ba7e09d6ee6 50064 web optional zope-zshell_1.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+9buSqjfbISpbKw0RAvmDAJ9QHX1lgqdfvx8GYD/fPCS/8t1FtQCgyd9G QjlVH7hev5YkhHz8xR81dkc= =GimP -END PGP SIGNATURE- Accepted: zope-zshell_1.5-1.diff.gz to pool/main/z/zope-zshell/zope-zshell_1.5-1.diff.gz zope-zshell_1.5-1.dsc to pool/main/z/zope-zshell/zope-zshell_1.5-1.dsc zope-zshell_1.5-1_all.deb to pool/main/z/zope-zshell/zope-zshell_1.5-1_all.deb zope-zshell_1.5.orig.tar.gz to pool/main/z/zope-zshell/zope-zshell_1.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 15, 2003 at 10:43:50PM +0200, Bj?rn Stenberg wrote: Matthias Urlichs wrote: Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Note that the version shown is simply the current libgcc.so version. Current as of when? When the upload was done? Current at package build time, that is when dpkg-shlibdeps is run. dpkg-shlibdeps has no idea whether an older version would be sufficient, so it plays safe. Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Not often. Most slow release libraries are strongly backwards compatible. When it does become a problem, it can be terrible for a few weeks. Lots of packages need to be rebuilt. Unstable becomes, well, unstable. Then things get back to the normal level of chaos. Jim Penny Note: I don't have a suggestion for a better method right now, I'm just trying to understand the implications of the current system. -- Bj?rn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-popy 2.0.8-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 12 Jan 2003 16:18:55 -0500 Source: python-popy Binary: python2.2-popy python2.3-popy python-popy python2.1-popy Architecture: source i386 Version: 2.0.8-6 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: python-popy - empty package moving default python-popy package to python2.2 python2.1-popy - module providing access to PostgreSQL from Python2.1 python2.2-popy - module providing access to PostgreSQL from Python2.2 python2.3-popy - module providing access to PostgreSQL from Python2.3 Changes: python-popy (2.0.8-6) unstable; urgency=low . * change to libpq3 * Note: there is an unfortunate change in PostgreSQL casting * behavior. 1 may no longer be cast to boolean. Valid * representations of 1 are TRUE, 't', 'true', 'y', 'yes', and '1'. * Simile for false. This is non-idimatic for python. Files: 8b22729a93ed5946f368fc9e3896a9d3 699 libs optional python-popy_2.0.8-6.dsc a75005a4bb23cc19a521ec10c9219318 26432 libs optional python-popy_2.0.8-6.diff.gz 1864fa5f6b80d45cac4a3a2db50cd8f8 6136 libs optional python-popy_2.0.8-6_i386.deb 15f97ac52888eb9ccc0a3105a10bf0b9 16116 libs optional python2.1-popy_2.0.8-6_i386.deb 8a0d081ecda82cdddfd47050b581b38a 16152 libs optional python2.2-popy_2.0.8-6_i386.deb 7780b69166795cb1647ae8e148387d79 16136 libs optional python2.3-popy_2.0.8-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+IiMwqjfbISpbKw0RAuYTAJ9VZzPYQzDmyaNeudpOmbQD0F3imwCfSzpU uupUS6mYf8pW3Qarg31uHQY= =EOoX -END PGP SIGNATURE- Accepted: python-popy_2.0.8-6.diff.gz to pool/main/p/python-popy/python-popy_2.0.8-6.diff.gz python-popy_2.0.8-6.dsc to pool/main/p/python-popy/python-popy_2.0.8-6.dsc python-popy_2.0.8-6_i386.deb to pool/main/p/python-popy/python-popy_2.0.8-6_i386.deb python2.1-popy_2.0.8-6_i386.deb to pool/main/p/python-popy/python2.1-popy_2.0.8-6_i386.deb python2.2-popy_2.0.8-6_i386.deb to pool/main/p/python-popy/python2.2-popy_2.0.8-6_i386.deb python2.3-popy_2.0.8-6_i386.deb to pool/main/p/python-popy/python2.3-popy_2.0.8-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Tue, Dec 10, 2002 at 05:18:38PM -0500, Branden Robinson wrote: On Thu, Dec 05, 2002 at 08:33:08PM -0600, John Hasler wrote: However, if that data can only be usefully expressed in precisely that way (that is, reverse-engineering those algorithms would regenerate the file) then the copyright on the file is probably unenforceable. Exactly. If there is no possibility for original expression within the technical constraints imposed, one has no ability to generate the sort of work which copyright is designed to protect. about 48 or more scripts are encoded. ASCII was frozen. That leaves 47! ways to order the scripts (and they did not choose alphabetic by english name). Latin alone has 840 code points (characters). Even given that there is a traditional ordering in the portions of this, there are other big spans that have no natural order. Bunch more choices made here. Then, each character has a potential of 22 binary properties, (not derived from UnicodeData.txt, but in a separate file PropList.txt), and 14 fields, most of which have 20 to 256 or more options. I would venture to guess that even with a perfect oracle, it would be essentially imposible to reverse engineer the Unicode data files, much less the ancillary algorithms. That is, a 32 bit search space with at least 36 properties to be discovered per data point is whopping big. Jim Penny
Re: location of UnicodeData.txt
On Fri, Dec 06, 2002 at 08:12:57AM -0600, John Hasler wrote: Thomas Bushnell writes: The copyright is on the *file* and not on the data,... Did I say it was? ...and certainly not on the *information* which the file contains. An instantiation of that information could be considered a derivative of the copyrighted work. My second paragraph explains one reason why it might not be. A couple of URLs of interest: http://lxr.mozilla.org/seamonkey/source/intl/unicharutil/tools/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/unicode/makeunicodedata.py?rev=1.17content-type=text/vnd.viewcvs-markup Both show that these projects (at least) are mechanically deriving their internal unicode tables from UnicodeData.txt. Jim Penny
Re: location of UnicodeData.txt
But they clearly do not want you to modify anything, including character name! Character name is a searchable field, which some applications may need. It's an English field, for which there is a canonical translation for French, and there should be translation for other languages. But, on the unicode stability policy page http://www.unicode.org/unicode/standard/stability_policy.html it says: The character names are used to distinguish between characters, and do not always express the full meaning of each character. They are designed to be used programmatically, and thus must be stable. In some cases the original name chosen to represent the character is inaccurate in one way or another. Any such inaccuracies are dealt with by adding annotations to the character name list (which is printed in the Unicode Standard and provided in a machine-readable format), or by adding descriptive text to the standard. Note: It is possible to produce translated names for the characters, to make the information conveyed by the name accessible to non-English speakers. Hmmm. What does that mean? Are translated names to be annotations, descriptions, character names, or are they maintained in a separate table? How do you use the name programmatically if you don't know the language they are in? I did some googling, but could not find the French trasnlation files. Is there an URL? Jim Penny
Re: location of UnicodeData.txt
If a system simply declared a section of data to be UniCode data, and made no attempt to comprehend the contents, it probably would not need to have access to the contents of Unicode.txt. Just like if a system simply declared a section of data to be code complaint to Fortran-2026, and if it made no attempt to comprehend it, it wouldn't need access to the contents of that standard. A text-processing program that needs to display data is going to need the contents of UnicodeData for BiDi. A proper cut program should use UnicodeData, so it doesn't seperate a character from a subsequent combining character. A spell program is going to need the data to know which characters end words. Anything that handles text in a way more complex then cat will access to this data. OK, now, supposing that the unicode license is found to be non-DSFG free, and hence that UnicodeData.txt is non-free. Suppose a program implements either unicode collation, regular expressions, or any of the other things mentioned above. (collation is at: http://www.unicode.org/unicode/reports/tr10/, regular expressions are at http://www.unicode.org/unicode/reports/tr18/) Can the program be in debian main? In other words, does the program require ... non-free packages or packages which are not in our archive at all for ... execution? Jim Penny
Re: location of UnicodeData.txt
On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote: On Sat, Nov 30, 2002 at 12:35:25PM -0500, Jim Penny wrote: I think you are missing the points here. First of all, DFSG applied to the standard does not want to change the standard, but wants all to be able to change the text of the standard. Huh? If I change the text of the standard, I have changed the standard! No you haven't, only the standards body in question can do that. The above is in the context of people wanting to be able to change the unicode.txt file(s). This file cannot be changed without producing something that differs from the standard. Correcting it produces an artifact that is distinct from the standard. Is that unclear? There are all sorts of reasons why you might wish to create derivative works based on the standard -- a new standard for a different purpose, for example. Derivative works are covered by copyright. Period. I would advise that you not base a defense of infringment of copyright on the fact that you have only used it to create a derivative work. Or helpful documentation of the standard for people who are intimidated by the 'dry' nature of the original... This, on the other hand, would probably be regarded as fair use, especially as you would need only illustrative snippets to create such documentation. In normal circumstances, embedding the entire table in your documentation would likely not be regarded as fair use, but that is a fact based pattern that would have to be decided on a case by case basis. In this case, it is arguable that the Unicode Consortium's license specifically permits inclusion of the entire table, as it does permit unlimited extraction. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Engage brain. Do you think that if I want to create a competitor to, say, GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? Or any one of the thousands of DFSG-free packages that are in main? Brain engaged. OK, according to you, anyone can make a competitor to GNU Emacs and may use the GNU emacs code. Great. So, now consider microsoft visual gnu emacs, which is released under the MS-EULA. If that seems to fail to capture your meaning, then well, suppose I think that the GPL sucks, and that BSD is the one true license. Can I the create FreeOpenBSDGNU emacs with a BSD license (as a derivative work)? What's that? Oh, you mean that anyone may produce a derivative work that is licensed in a manner compatible with the original work's license, provided the original license specifically grants that right? Oh. Yes, I agree with that. Stated in those terms, it is not much of a surprise. Now, where in the Unicode license does it give you permission to create derivative works? The license does say Information can be extracted from these files Oh, and you have to provide an accompanying notice indicating the source. The license does not say that any of the information in files provided by the Unicode Consortium can be modified (except by extraction). This makes it fail DSFG guideline 3. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Tomorrow will be cancelled due to lack of interest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Sun, Dec 01, 2002 at 11:10:09AM +0100, Bernhard R. Link wrote: * Jim Penny [EMAIL PROTECTED] [021130 18:43]: Huh? If I change the text of the standard, I have changed the standard! For example, if I have : 0332;COMBINING LOW LINE;Mn;220;NSM;N;NON-SPACING UNDERSCORE and change this to 0332;NON-COMBINING LOW LINE;Mn;220;NSM;N;SPACING UNDERSCORE Then the standard has been changed! That is, this file is line after line of character number assignment, followed by character name, (and other information). There is no possible change that does not change the standard! Hint: (from standard writer's viewpoint) - A standard that can be changed by anyone, at anytime, without notice and consultation is not a standard, especially if it is a contentious standard that has some people seriously upset (i.e, Russian and XJK users). You seem to understand less and less. If the text is changed, it is no longer the standard. (A standard can not be changed changing the text, as the standard is not a local file, but the unmodified text). So, can a standard be DSFG free? What the licence of a standard file may resonable demand is that no changed text pretends to be the unmodified standard. They can demand more than that, a lot more. All of copyright law comes to bear (if the standard is deemed copyrightable and has been copyrighted.) In particular, the owner of a copyright has, unless waived, control over the right to distribute derivative works. The text of every standard that I know of is modifiable. However, it normally takes the consent of the standards body and is issued under its aegis. Again, Jim Penny's unicode standard has no value, and even debian unicode has very limited appeal. You are again talkin of the standard. Not the text of the standard. A standard body can issue a new standard. And trademark laws and other things can force any new XYZ standard for UVW to be issued by some special entity. Look at the file! UniCode.txt is the core of the standard, it happens to be an ASCII text file. So what, every standard is embodied in text at some point! You seem to regard standards as some Platonic ideal, completely divorced from the text which defines them. This may be a valid viewpoint in some cases; e.g. the original algol-60 report. It is not in other cases, e.g. the algol-68 report. UniCode.txt is a text file which has no redundacy and no explanatory text. There is simply no portion of this file that can be modified without making an artifact that differs from the standard in some substantive way. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Now, IANAL, but I suspect that any unicode editor that reproduced enough information from the unicode standard to be useful would be considered a derived work. More importantly, I think that is is arguable that this table is, in the terms of the Debian Social Contract, necessary for the execution of a full unicode editor. (The language of the debian Social Contract is even more general and vague than copyright law! It talkes about and to freely use the information supplied in the creation of products supporting the UnicodeTM Standard. If this does not include making modifications, then jurisdiction is more broken then I ever thought. (In my eyes the information should even not be copyrightable at all, but this point may be discussed). The license permits extraction of information for documentation or programs. This may be completely different from modification or correction of information. In either case, the social contract would place the unicode table into non-free; and any editor that depended on the table, or information derived from the table (in a copyright sense) in either non-free or contrib. The table itself may be non-free. I doubt any editor will use the file itself but use modification suitable for the program. I have no problem with this result. But saying that the unicode character table cannot be distributed by debian, in spite of specific language permitting us to do so, seems a bit extreme. If it does not suit for main, then it can not be distributed as part of debian. (by definition) But is can be distributed by debian, not as a part of debian. That is, it may be put in non-free, and it may be distributed using the debian mirrors. Note: I did not use the phrase part of, that is yours. And the consequences of this decision will probably seem extreme to many people. This example just happens to be particularly cogent; there is no doubt it is non-free, there is no doubt it is copyrightable, there is little doubt that it is necessary for the execution of a substantial corpus of programs
Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 07:30:57PM +0200, Richard Braakman wrote: On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote: On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote: There are all sorts of reasons why you might wish to create derivative works based on the standard -- a new standard for a different purpose, for example. Derivative works are covered by copyright. Period. I would advise that you not base a defense of infringment of copyright on the fact that you have only used it to create a derivative work. Umm, yes. That's exactly why the text of a standard should be free. You seem to be confusing the should be and is discussions. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Engage brain. Do you think that if I want to create a competitor to, say, GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? Or any one of the thousands of DFSG-free packages that are in main? Brain engaged. OK, according to you, anyone can make a competitor to GNU Emacs and may use the GNU emacs code. Great. So, now consider microsoft visual gnu emacs, which is released under the MS-EULA. You seem to have hit the wrong button when you tried to engage your brain. Why would create a competitor have to mean create a competitor under a conflicting license? The GNU Emacs license allows you to create a competitor without starting from scratch. That is what makes it free! The question above did not specify that the competitor was to be GPL licensed. In the universe of GPL licensed programs, you are indeed free to create a competitor using code incorported from GNU emacs; in fact, the universe of DFSG licenses was specified. In the universe of DFSG licensed programs, you are not free to create a competitor using incorporated code, in particular, you cannot create a BSD licensed version of GNU emacs using derived code. (And if BSD licenses were allowed, then so would the MS-EULA license, by washing the GPL through the BSD license.) What's that? Oh, you mean that anyone may produce a derivative work that is licensed in a manner compatible with the original work's license, provided the original license specifically grants that right? Oh. Yes, I agree with that. Stated in those terms, it is not much of a surprise. I don't think he meant that at all. You're confusing may with should expect to be able to. The whole provided... clause misses the point. Laws do not define morality. This is straying terribly far from field, but are you saying that it is morally correct that the debian project modify standards without permission of the standards body? Or that it is morally correct to incorporate (portions of) other programs in your work unconditiontally and without permission of the original creators? Are you saying that if the FSF brings a suit alleging GPL violation, that this suit is immoral? If your answer to any of these is yes, then your morality is very different from mine. Now, why do you think that it would not be a good thing for the text of the text of the Unicode license to be free? Your only answer so far seems to be because it currently isn't. 1) that is a good enough answer to make a determination on whether it is part of non-free, contrib, or main. 2) It is an embodiment of years of work by many people who did not agree that it should be free (in DSFG terms). 3) I can think of no value in a standard that is DFSG free. The purpose of a standard is to ensure interoperability. If there first has to be a discovery phase to determine how my standard deviates from your standard, interoperability is reduced if not destroyed. This is not to say that standards should not permit extension. Most do. However, even this has been controversial in the past (Microsoft Kereboros, for example). Jim Penny Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 10:43:42AM -0800, Thomas Bushnell, BSG wrote: Jim Penny [EMAIL PROTECTED] writes: Now, where in the Unicode license does it give you permission to create derivative works? The license does say Information can be extracted from these files Oh, and you have to provide an accompanying notice indicating the source. The license does not say that any of the information in files provided by the Unicode Consortium can be modified (except by extraction). This makes it fail DSFG guideline 3. What about the null extraction, done by using the extraction tool named cat? As far as I can tell, this is permitted. It would not be permitted under normal copyright law, but the license does permit arbitrary extraction. Extraction of the entirety still appears to be extraction. What the Unicode Consortium does not say is what the distribution rights are relative to the subsetted tables. This is a license weakness, but I suspect that any sane judge would hold that giving permission to do the extracting implies giving permission to distribute the result. But, I suspect that any sane judge would also say that extraction for the purpose of license laundering is not implied. That is, you could not take the Unicode Consortium's file, apply cat to it, and relicense the result under BSD (for example). Now, what is Unicode Consortium really saying here? They are saying that you are allowed to use subsets of Unicode. For example, you may be interested in only a few languages. You may select the relevant portions of the table out. Or, if you know that you don't care about bidirectionality, ligation, extenders, grapheme link, or any of the other various and sundry attibutes, you may drop them. In other words, you can do either row or column projection if that is advantageous to you. But they clearly do not want you to modify anything, including character name! Character name is a searchable field, which some applications may need. Jim Penny -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Fri, Nov 29, 2002 at 11:37:41AM +0100, Bernhard R. Link wrote: * Jim Penny [EMAIL PROTECTED] [021128 03:35]: So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Absent said permission, which is hardly ever going to be given, they must be considered non-free. (This is, of course, logically forthright.) Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. Yet, unicode is supposed to be the canonical character encoding scheme for debian. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? I think you are missing the points here. First of all, DFSG applied to the standard does not want to change the standard, but wants all to be able to change the text of the standard. Huh? If I change the text of the standard, I have changed the standard! For example, if I have : 0332;COMBINING LOW LINE;Mn;220;NSM;N;NON-SPACING UNDERSCORE and change this to 0332;NON-COMBINING LOW LINE;Mn;220;NSM;N;SPACING UNDERSCORE Then the standard has been changed! That is, this file is line after line of character number assignment, followed by character name, (and other information). There is no possible change that does not change the standard! Hint: (from standard writer's viewpoint) - A standard that can be changed by anyone, at anytime, without notice and consultation is not a standard, especially if it is a contentious standard that has some people seriously upset (i.e, Russian and XJK users). This is a good thing, the text of standards should be modifiable. How else shall someone write the following standard without having written the first or having to write all from scratch? The text of every standard that I know of is modifiable. However, it normally takes the consent of the standards body and is issued under its aegis. Again, Jim Penny's unicode standard has no value, and even debian unicode has very limited appeal. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Secondly: What has a unicode editor have to do with the unicode standard? It should only implement it. If it would contain parts of the standard-text (tables or whatever) that were protected by copyright law and the standard would allow no modifications, then noone would be allowed to copy the editor. (No special problem with debian) A unicode editor must know certain properties of the character set (note, I am not talking about font properties here, unicode does not deal with fonts.) Examples might be langauge, combining marks, bidirectionality, input methods, surrogates, Hangul syllables. These are things that an editor must know, and that pretty much, must be looked up in the unicode table. Now, the unicode license happens to be fairly clear, and fairly permissive. See: http://www.unicode.org/Public/UNIDATA/UnicodeCharacterDatabase.html It specifically gives permission for redistibution, without fee, providing a statement of copyright, and a disclaimer are preserved. It also specifically allows incorporation into programs under the same terms. But those terms happen to be non-DSFG free. They fail 3 and 8. Now, IANAL, but I suspect that any unicode editor that reproduced enough information from the unicode standard to be useful would be considered a derived work. More importantly, I think that is is arguable that this table is, in the terms of the Debian Social Contract, necessary for the execution of a full unicode editor. (The language of the debian Social Contract is even more general and vague than copyright law! In either case, the social contract would place the unicode table into non-free; and any editor that depended on the table, or information derived from the table (in a copyright sense) in either non-free or contrib. I have no problem with this result. But saying that the unicode character table cannot be distributed by debian, in spite of specific language permitting us to do so, seems a bit extreme. And the consequences of this decision will probably seem extreme to many people. This example just happens to be particularly cogent; there is no doubt it is non-free, there is no doubt it is copyrightable, there is little doubt that it is necessary for the execution of a substantial corpus of programs which are otherwise DFSG free. These program would certainly include unicode editors, and would probably include python, perl and ruby. Jim Penny Hochachtungsvoll, Bernhard R. Link -- gEistiO sagen wir mal...ich hab alle sourcen in /lost+found/waimea me gEistiO: [...] Warum lost+found? gEistiO wo haette ich es denn sonst hingeben solln
Re: location of UnicodeData.txt
On Wed, Nov 27, 2002 at 03:54:35PM -0500, Branden Robinson wrote: On Wed, Nov 27, 2002 at 07:59:00PM +0200, Richard Braakman wrote: On Wed, Nov 27, 2002 at 08:50:10AM -0800, Thomas Bushnell, BSG wrote: Heh. There's another: miscfiles: /usr/share/misc/unicode.gz The current version is Unicode 3.1.1. According to http://www.unicode.org/Public/UNIDATA/UnicodeData.html there's a version 3.2. Hmm, is this file Free? There's a license on that same page: This is a question for -legal, FYI. Limitations on Rights to Redistribute This Data Recipient is granted the right to make copies in any form for internal distribution and to freely use the information supplied in the creation of products supporting the Unicode^TM Standard. The files in the Unicode Character Database can be redistributed to third parties or other organizations (whether for profit or not) as long as this notice and the disclaimer notice are retained. Information can be extracted from these files and used in documentation or programs, as long as there is an accompanying notice indicating the source. I see no problem with this license as far as it goes, but it doesn't go far enough. There is no permission granted to make modifications (and distribute modified versions). (DFSG 3) So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Absent said permission, which is hardly ever going to be given, they must be considered non-free. (This is, of course, logically forthright.) Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. Yet, unicode is supposed to be the canonical character encoding scheme for debian. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? What an interesting anecdote! Jim Penny
Re: location of UnicodeData.txt
On Wed, Nov 27, 2002 at 04:53:00PM -0500, Branden Robinson wrote: On Wed, Nov 27, 2002 at 04:23:51PM -0500, Jim Penny wrote: I see no problem with this license as far as it goes, but it doesn't go far enough. There is no permission granted to make modifications (and distribute modified versions). (DFSG 3) So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. I cannot speak for all proponents of the proposed GR, but yes, that's my understanding. Yet, unicode is supposed to be the canonical character encoding scheme for debian. I don't see that in the current version of the Policy manual, but it wouldn't surprise me if we were to standardize on Unicode, since it seems to be the best-of-breed in the character set department. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? Many (perhaps all) RFCs are non-free as well; does that mean that compliant implementations must go into contrib or non-free? I notice that you did not answer. As far as I can tell, given the current definition, the logically coherent answer is yes. There is some wiggle room in this. See below. What an interesting anecdote! I do not grasp what place emotionalism has in a simple, coolheaded discussion of licensing. If you are upset with the ramifications of the DFSG, you can always propose a General Resolution to amend its terms, or repeal it entirely, perhaps in favor of something more pragmatic. Anecdote. A particular fact of an interesting nature. Incidentally, is there a reason you did not respect the Mail-Followup-To header? Yup, the anecdote had nothing to do with legal. Had a lot to do with the ramifications of the more radical interpretations of the DFSG and the consequences of these interpretations. It was interesting to see you argue that a license was non-free. To be consistent with the GR, you should have been observing that it could not be a part of debian. If there is a point in this, it is that the status quo ante allows some wiggle room. In particular, section 5 of the social contract grants this. If you remove section 5, and reduce debian to only things that have a DSFG license, the resulting axiomatic system can be used in interesting ways. In particular, recursive application of the axioms is very intersting. Can an artifact that claims to be compliant with a non-DSFG free standard itself be considered to be free? That is, does it depend on the standard for its execution? Compare and contrast this with an installer of a non-free package. Note: the typical installer can, in fact, install an infinite number of items -- after all, most installers are not strongly version dependent! Jim Penny Note: there is an intentional ambiguity of the word debian above, which will drive some fundamentalists crazy. My definition of debian: the totality of software, documents, and other artifacts produced by debian developers and contributed to the debian archives.
Re: Pick a name, any name...
On Wed, Nov 27, 2002 at 05:34:20PM -0800, Sean 'Shaleh' Perry wrote: On Wednesday 27 November 2002 02:03, Roland Mas wrote: Current candidates include: hey how about something much less cryptic like forge. Nothing worse than having to guess what woman's name some silly coder named the program I am looking for. On the other hand, if you want truly obscure, here are some suggestions: Norse: Magni As Magni and Modi grew older, they learned many things from the dwarves, whom they would often visit. When Modi came of age, he took it upon himself to teach man how to forge and fashion bronze. Magni continued to learn things from the dwarves; and after learning many things, took it upon himself to teach man how to forge and fashion iron. Note: learned from dwarfs; positive association with magnificent. Norse: Draupnir Draupnir was a golden ring (or belt, there seems to be some confusion), that had the property that every ninth day 8 gold rings of equal weight dropped from it. Note: No special special affiliation with forges, just a promise of riches. Gaulish: Belisama The Gaulish/Celtic goddess of light and fire, the forge and of crafts. Note: sounds kind of like bellissimo. Hawaiian: Pele The Hawaiian (Polynesian) goddess of the fire in the volcano, the mother of eruptions. She is a ravishing, whimsical goddess who resides in the volcano Kilauea on Hawaii. Note: no special affinity with forges, but mother of eruptions (and flame-wars?) seems appropriate. Aztec: Veveteotl God of fire and creativity. Darkover: Sharra The most dangerous matrix on all Darkover was the legendary Sharra. Embodied in the image of a chained woman, wreathed in flames, it was the last remaining weapon of the Ages of Chaos that had almost destroyed civilization on the planet of the Bloody Sun. Then again, forge seems much safer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ploticus 2.0.4-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Oct 2002 22:49:31 -0400 Source: ploticus Binary: ploticus Architecture: source i386 Version: 2.0.4-3 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: ploticus - A script driven business graphics package Changes: ploticus (2.0.4-3) unstable; urgency=low . * Rebuild due to problem with shlibs. Switch to libgd2-dev. Files: ee226f96c0a91c748a1cec314f357449 580 misc optional ploticus_2.0.4-3.dsc 8fe5f2d739a1d150b75928b66230fbbf 755002 misc optional ploticus_2.0.4-3.tar.gz 2772d0bb687cc77c036fa09a6c5a1cb4 156288 misc optional ploticus_2.0.4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uSIsqjfbISpbKw0RAp3hAJ9DRXPL1q0pTqPkytVe4JLhIo1mqgCfThaF dXJTLuLojsC2g1TYv5wjEH4= =AT7U -END PGP SIGNATURE- Accepted: ploticus_2.0.4-3.dsc to pool/main/p/ploticus/ploticus_2.0.4-3.dsc ploticus_2.0.4-3.tar.gz to pool/main/p/ploticus/ploticus_2.0.4-3.tar.gz ploticus_2.0.4-3_i386.deb to pool/main/p/ploticus/ploticus_2.0.4-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-popy 2.0.8-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 2 Sep 2002 23:10:55 -0400 Source: python-popy Binary: python2.2-popy python1.5-popy python-popy python2.1-popy Architecture: source i386 Version: 2.0.8-4 Distribution: unstable Urgency: low Maintainer: James W. Penny [EMAIL PROTECTED] Changed-By: James W. Penny [EMAIL PROTECTED] Description: python-popy - empty package moving default python-popy package to python2.1 python1.5-popy - module providing access to PostgreSQL from Python1.5 python2.1-popy - module providing access to PostgreSQL from Python2.1 python2.2-popy - module providing access to PostgreSQL from Python2.2 Changes: python-popy (2.0.8-4) unstable; urgency=low . * change default version to python2.2-popy Files: e94bcc85c1daf0d8ebc4811edc3d2ca6 699 libs optional python-popy_2.0.8-4.dsc 4a5fc7c572a52274db07f64bf7dfffa1 26052 libs optional python-popy_2.0.8-4.diff.gz 2ca23d5b3fc443d0488af95bcd7a1813 5510 libs optional python-popy_2.0.8-4_i386.deb 614df8ab075efdfa72049865b1ef7992 15668 libs optional python1.5-popy_2.0.8-4_i386.deb 783cf15931b349e8a6f189dc166da0a4 15754 libs optional python2.1-popy_2.0.8-4_i386.deb c52fda410c7feb9914aed9a51fed5664 15774 libs optional python2.2-popy_2.0.8-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9dXffqjfbISpbKw0RAkHXAJ9xIqDGtm6jBI6tMA5BMNh5ZrHQ6gCgl01u nvI/0yJEh/tpwtqrPn9Da38= =FhVF -END PGP SIGNATURE- Accepted: python-popy_2.0.8-4.diff.gz to pool/main/p/python-popy/python-popy_2.0.8-4.diff.gz python-popy_2.0.8-4.dsc to pool/main/p/python-popy/python-popy_2.0.8-4.dsc python-popy_2.0.8-4_i386.deb to pool/main/p/python-popy/python-popy_2.0.8-4_i386.deb python1.5-popy_2.0.8-4_i386.deb to pool/main/p/python-popy/python1.5-popy_2.0.8-4_i386.deb python2.1-popy_2.0.8-4_i386.deb to pool/main/p/python-popy/python2.1-popy_2.0.8-4_i386.deb python2.2-popy_2.0.8-4_i386.deb to pool/main/p/python-popy/python2.2-popy_2.0.8-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 03:25:01PM +0200, Laura Creighton wrote: On Aug 06, Torsten Landschoff wrote: As the new upstream of python-gnome (for GNOME 2) needs python 2.2 for building I am wondering when python 2.2 will get the default version for Debian. Any insights? I believe a consensus was reached on debian-python that we would move to Python 2.3 as the next default Python, skipping 2.2 entirely. My recommendation would be to separately maintain a python 2.2-compatible python-gnome and a 2.1 compatible version, at least until the 2.3 release. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 The new Python Business Forum (www.python-in-business.com) is collaborating with the Python developers to produce Python-in-a-Tie, a business-targetted release of Python. This is a 'Sumo-Release', which will include other useful Python libraries and programs which are not part of the standard Python releases. What we want is a release we tell our cyustomers to run which will give them 18 months or so during which there is no need for them, as users, not developers, to upgrade a to a newer version of Python. Then we will target a next release, and to be the next Python-in-a-Tie. I am the Chairman of the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which we are telling Python developers is the release which they should write for. Therefore I think that skipping the 2.2 release in favour of the 2.3 would be a mistake. Please cc any discussion and replies to me since I do not read debian-devel. Thanks very much, But, this does not say that python2.2 will not be available. It is, and, as far as I know, will continue to be. I think that the general consensus was that debian would maintain whatever versions we had to, if Python-in-a-Tie were packaged in debian, it would mark python2.2 as a requirement, and until said package was either rewritten to use python2.3+, or removed from the archive, it would be impossible to remove python2.2. Nor is it much of a pain for a developer: scripts being /usr/bin/python2.2, rather than just /usr/bin/python. Your group does not even need to be aware of this; this is something the debian developer should be taking care of. There has been dicussion of removing python1.5. But this is because there are very few packages left that depend on it. Debian does not historically remove packages easily or without thought. Jim Penny Laura Creighton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 11:02:18AM -0400, Guido van Rossum wrote: Thanks for the post, Laura. I agree -- Python 2.3 won't be ready for a long time, and I recommend to the Debian folks that they standardize on Python 2.2. For now, that will be Python 2.2.1; a maintenance release, 2.2.2 will be issued some time later this year. But Zope 2.5, one the more popular applications, requires 2.1.3. Can we be more aggressive in changing default versions than Zope? Jim Penny I don't expect 2.3 to reach maturity until mid 2003. --Guido van Rossum (home page: http://www.python.org/~guido/) [Context:] snipped.
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 02:54:31PM -0500, Chris Lawrence wrote: On Aug 14, Laura Creighton wrote: The new Python Business Forum (www.python-in-business.com) is collaborating with the Python developers to produce Python-in-a-Tie, a business-targetted release of Python. This is a 'Sumo-Release', which will include other useful Python libraries and programs which are not part of the standard Python releases. What we want is a release we tell our cyustomers to run which will give them 18 months or so during which there is no need for them, as users, not developers, to upgrade a to a newer version of Python. Then we will target a next release, and to be the next Python-in-a-Tie. I am the Chairman of the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which we are telling Python developers is the release which they should write for. Therefore I think that skipping the 2.2 release in favour of the 2.3 would be a mistake. Please cc any discussion and replies to me since I do not read debian-devel. Thanks very much, Laura: (and Guido et al.) Debian plans to support at least Python 2.2 and 2.3 in the next release (sarge); unlike other distributors, we do not have a problem with making multiple Python versions available so long as they are useful. If you need to target a specific release of Python (i.e. 2.2), you should use #!/usr/bin/env python2.2. However, the *default* Python shipped by Debian (i.e. /usr/bin/python) affects things within our distribution, and there may be wins for us basing on 2.3 rather than 2.2 (the enumerate builtin being an obvious, immediate example; universal newline support may also be important). Now, if 2.3 won't be stable until well into next year (as opposed to the schedule in PEP 283), then we may want to target 2.2.x as our default version. This is something that largely depends on our anticipated release schedule - which is not very calendar driven, but Q2 2003 is less likely to make sarge than Q4 2002. (Note that debian-python is probably the most appropriate list for followups.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ One final point. We will almost definitely not switch the default python in sid (current unstable), until there is talk that Sarge is nearing a freeze. There is simply no point in undergoing the pain of a major python release twice in a single unstable cycle. We will instead make the decision of what python will be default in Sarge when it nears release, not now. Current stable, woody, is shipping with 2.1 as default. That cannot be undone, it is released, and at the time the decision was made, 2.2 was way too close to the cutting edge for comfort. Moreover, we would not recommend that the target audience of Python-in-a-Tie run sid. Sid breaks things occasionally, sometimes badly. Sid tortures small defenseless things for a hobby! 2.2 is available in woody already. Invoke it using /usr/bin/python2.2. BTW: is the PIAT consortium going to offer any DSFG free software? Jim Penny
Postgres and non-us
PostgreSQL now has a dependency on openssl/ssl.h in a fundamental header file, postgresql/libpq-fe.h. Does this mean that every piece of software which requires this header file to compile will also have to be migrated to nonus? Jim Penny
debian.org
Hello, I hope you can help me. May I ask if your company/organization put MS Word files on your CD's? We are the sole distributors of icWord, which isthe Microsoft word viewer for the Mac. Our SW allows Mac users to view, copy and print Word documents without having to purchase or use Microsoft Word. icWord viewer is also designed for CD distribution purposes. Do you think you could find interest in such a viewer? If you have any questions please feel free to contact me. Your opinionwill be appreciated. Thank you, Penny B. Panergy Ltd. [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
I also do NOT like the kernels compiled for a huge number of systems. I do not think it helps either hotrodders or little old ladies from pasadena. Hotrodders can and should build their own, and lolfp's cannot tell which kernel they need (they do not know, or care if they have a 586 or a Pentium Classic, and probably think they have a Pentium, even if it is from AMD)! I am not even sure that initrd is all that great. I have looked in the man pages, in /usr/share/doc/kernel-doc-2.4.2, /usr/share/doc/kernel-image-2.4.2-pentiumiii-smp, on google, and in other places and have yet to see the answer to my questions. These are: 1) how do I boot from a non-IDE root disk? 2) How do I control what goes into initrd in a more reasonable way than nothing/most/all. (and what does most do, anyway?). Jim Penny
