Accepted tkcvs 8.2.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 08 Jun 2012 22:25:55 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.2.3-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: tkcvs - Graphical front-end to CVS and Subversion Closes: 675352 Changes: tkcvs (8.2.3-1) unstable; urgency=low . * New upstream version * Updated to standards 3.9.3 * Provides tkdiff (Closes: #675352) Checksums-Sha1: 2010d857f369e0b8f13886825c026aa56dc3f53a 1313 tkcvs_8.2.3-1.dsc 5a2fdd7eb535aed61e01deec0f1fe2a1f28ef39a 571024 tkcvs_8.2.3.orig.tar.gz 3c283727ac85012d17e662425be1ac3b5dde1b96 10524 tkcvs_8.2.3-1.diff.gz ecce7e08b0b101a4fd2b8a3fa0250b167f042edd 454864 tkcvs_8.2.3-1_all.deb Checksums-Sha256: c560d0240feb4b33a26d08596e67f8a106a70a25e7822e54da13b4aead2eb5e1 1313 tkcvs_8.2.3-1.dsc 7e52ddd37208c88380b5c416cd9f5abc70024da4e871ee0a3f91b96837064c8b 571024 tkcvs_8.2.3.orig.tar.gz 5b3c4bccd0e7c3d4835224796d6bb6ca9ae8e833890cfee16a00ef7707679a75 10524 tkcvs_8.2.3-1.diff.gz 721663942b880825a3122a0cc3a74b99b6155c9f623afad84133b34bcfa6e980 454864 tkcvs_8.2.3-1_all.deb Files: 31404b2075517753cde5958cf1405c0b 1313 vcs optional tkcvs_8.2.3-1.dsc 95cfaa44cfb233daed2b3d4fb26c0fa2 571024 vcs optional tkcvs_8.2.3.orig.tar.gz 15d60568de1cc6eee50d9a1b3d78866a 10524 vcs optional tkcvs_8.2.3-1.diff.gz d92eb4092568fd668bf6beac2cd32619 454864 vcs optional tkcvs_8.2.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBT9J3QBypeFo2odvPAQIHhggArncITGdoCyQr+upLMsFmC9fUb09honHd 6Le3jW3bWZm9hcGDY/hE7BgoJ5nHbb7XdX4wNQSeeRbCPZzI2TAopNJec1sjU1Dl sgkuqVjIBNcNqV/vGZ4pr3m9cT81cmGnk+90546MM3yR0sMhod+TrGk5Ar5xXnl/ gAsIo/Io7HR3jMx/J/XuN/0WZsX4pXIKRkoV5YQuvmuAt9aLO60QWB+EGlV5HJjC J8bSYLNcKc34g1+DyYOIYcmeQhqctu1Mlroulb21bsR5E38+DqJ9lODKKo4GJGZR enR0dtcEGmgOBGNaGdM/mOQTHizS5HF70EWtBr2gOJ6sx1Ht/6b87g== =CyOF -END PGP SIGNATURE- Accepted: tkcvs_8.2.3-1.diff.gz to main/t/tkcvs/tkcvs_8.2.3-1.diff.gz tkcvs_8.2.3-1.dsc to main/t/tkcvs/tkcvs_8.2.3-1.dsc tkcvs_8.2.3-1_all.deb to main/t/tkcvs/tkcvs_8.2.3-1_all.deb tkcvs_8.2.3.orig.tar.gz to main/t/tkcvs/tkcvs_8.2.3.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/e1sd7vz-0005uf...@franck.debian.org
Accepted am-utils 6.2+rc20110530-3 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 18 Jan 2012 20:54:36 + Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.2+rc20110530-3 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Changes: am-utils (6.2+rc20110530-3) unstable; urgency=low . * Fixed missing build dependency on dpkg-dev Checksums-Sha1: e4ad0d84fba25ab71c953ec16b0e1dd0cc1d6722 1771 am-utils_6.2+rc20110530-3.dsc b4214641d44ef151c2cfe0374f92d3373418b0c1 76647 am-utils_6.2+rc20110530-3.diff.gz 5dcb857fe682f7297c41ea8c54010045b6f5f9df 415656 am-utils-doc_6.2+rc20110530-3_all.deb 82969283fa8a09b6d4848ad6dd0838e47f15540f 183392 libamu4_6.2+rc20110530-3_i386.deb 20a780cdd4b3f6cee681857b0703252d7692e6f6 464988 am-utils_6.2+rc20110530-3_i386.deb 9217da719c5020946609073ae647d474094d9a80 53014 libamu-dev_6.2+rc20110530-3_i386.deb Checksums-Sha256: 9e9dcbb8c96fb9ed559273de0fc4fe1206b962862e04473076c272c957070166 1771 am-utils_6.2+rc20110530-3.dsc d9aa66db9cb3a0095b9ccfb6529056ee4ebaca010d1610e0487cbd462dd5db22 76647 am-utils_6.2+rc20110530-3.diff.gz 0ea78793d5b46fd0f711519d9f265aa5a0b0ae64056c7db5bf52c248abb1af5e 415656 am-utils-doc_6.2+rc20110530-3_all.deb c5c949d4e16199ff9b0fdff387cda14ff2c5cec669c155e30c5939e86c4ee137 183392 libamu4_6.2+rc20110530-3_i386.deb ac9164481448f24f65f9875b7583807e051cb7a7b527a6855051870d21b0d4e7 464988 am-utils_6.2+rc20110530-3_i386.deb a6163b54e4749154d66eae3e5d2e0edd5c7ca4f5e7b0feb53f081584748c208e 53014 libamu-dev_6.2+rc20110530-3_i386.deb Files: 6e526e0b9204b49430044c459df1 1771 net extra am-utils_6.2+rc20110530-3.dsc 8d70dd65f6d5220f4284556b05e70fcf 76647 net extra am-utils_6.2+rc20110530-3.diff.gz c5e379125f8de80a5237cddcc684bf59 415656 doc extra am-utils-doc_6.2+rc20110530-3_all.deb 84e3a301e4d77111c18373acad1b2930 183392 libs extra libamu4_6.2+rc20110530-3_i386.deb 77254a08cc4b54e5b7d774ff98d6a540 464988 net extra am-utils_6.2+rc20110530-3_i386.deb 986fb9a1d42322a353894ed93ff7981f 53014 libdevel extra libamu-dev_6.2+rc20110530-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTxczvBypeFo2odvPAQLu8Qf+Lbyr+pVZdSF5mN2uFNb/wMtCU7VaVuMc MHuy1RZoyqNGSN9xybEtrCci9ayCvWw6BTBiRlGzbTEp31SH8rc7LuiMuHADk4i5 7K18SGXyNQtY6ca3+TrZzZ++t2FjADVV/uONB68qZpjDiK8r1artaYSbZodgD+3L n3iIGRIgxMocR3nvyCTx2U3gSIRL5BigWbS1Cb+oXERJMQTDGKcTk/LeigcrZe1L zpAEF7TUbT6YEGTR9NQP6Axks0u+AmEollFl+TX9lYP9XWw0nDXHYAmEmai08La0 ouV/Bl3OVm8bS6SPC8vXotEaypVDD/cXgb8nunG9kolISjbCwnGeXA== =L3kh -END PGP SIGNATURE- Accepted: am-utils-doc_6.2+rc20110530-3_all.deb to main/a/am-utils/am-utils-doc_6.2+rc20110530-3_all.deb am-utils_6.2+rc20110530-3.diff.gz to main/a/am-utils/am-utils_6.2+rc20110530-3.diff.gz am-utils_6.2+rc20110530-3.dsc to main/a/am-utils/am-utils_6.2+rc20110530-3.dsc am-utils_6.2+rc20110530-3_i386.deb to main/a/am-utils/am-utils_6.2+rc20110530-3_i386.deb libamu-dev_6.2+rc20110530-3_i386.deb to main/a/am-utils/libamu-dev_6.2+rc20110530-3_i386.deb libamu4_6.2+rc20110530-3_i386.deb to main/a/am-utils/libamu4_6.2+rc20110530-3_i386.deb -- 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/e1rncsf-00061r...@franck.debian.org
Accepted am-utils 6.2+rc20110530-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 30 May 2011 17:00:03 +0100 Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.2+rc20110530-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 628312 Changes: am-utils (6.2+rc20110530-1) unstable; urgency=low . * Imported Upstream version 6.2+rc20110530 * nfs_mount.h-needs-sys-socket.h.patch no longer needed * New patch to support recent libtool versions by using libtoolize (Closes: #628312) * Updated policy to 3.9.2 Checksums-Sha1: fe1c19ec5b0f5599eb45100e90f5913f9cc12bdc 1622 am-utils_6.2+rc20110530-1.dsc 44f35e93b4fd95d094d683a054caa4b66d5e5fa7 1113848 am-utils_6.2+rc20110530.orig.tar.gz 90e2db97ce717a97f2a8374b0bcd458639109a8f 74464 am-utils_6.2+rc20110530-1.diff.gz bf991895296b7bca76c07e909b72fb1352755088 415512 am-utils-doc_6.2+rc20110530-1_all.deb e5a32cb67304146f6a66fe1633a457aabb565e59 179850 libamu4_6.2+rc20110530-1_i386.deb 510d836258f30b14f434fd8ff016465082091b94 444174 am-utils_6.2+rc20110530-1_i386.deb f6a5517d554833c14adc942c4c11455769434355 50144 libamu-dev_6.2+rc20110530-1_i386.deb Checksums-Sha256: 9374a9ce9aedaf610c9160dd152671a16ce1645b905bed41b2badb19657cb561 1622 am-utils_6.2+rc20110530-1.dsc 88089853914f6d0d5653c6a481732183254717657f8a12d8b307bd2ce028e280 1113848 am-utils_6.2+rc20110530.orig.tar.gz f16a9a33d1b44d2228260dfe83a4587a27c4b02d3dea0f1c15366072b9db0477 74464 am-utils_6.2+rc20110530-1.diff.gz 34a6bc224a560a9871740754737225c004282bdb024d8e304057a37a9b2ec62b 415512 am-utils-doc_6.2+rc20110530-1_all.deb 13a70f20698410cb43dfeee42d3792054c30b12abe4016750a1053ba033ed30c 179850 libamu4_6.2+rc20110530-1_i386.deb 9f3737eab04a7d41358bcf40da6fa8a7370e7dc6334a5a1f69c42103614827d5 444174 am-utils_6.2+rc20110530-1_i386.deb a400aa67787ab242d20e68c1a733eaee7808f94e0889930446487615eac6d0bd 50144 libamu-dev_6.2+rc20110530-1_i386.deb Files: 0ef8ad6582c70374ec1324bd7ad582a6 1622 net extra am-utils_6.2+rc20110530-1.dsc 03048774bafec693e31f2d62ea6a5960 1113848 net extra am-utils_6.2+rc20110530.orig.tar.gz 8759f6de9985e3bd95d09c2f36fb3e33 74464 net extra am-utils_6.2+rc20110530-1.diff.gz 315362a3c33dd301e3dfe8824429333f 415512 doc extra am-utils-doc_6.2+rc20110530-1_all.deb 438a5a8cfcfe916ce8c557d0055b3237 179850 libs extra libamu4_6.2+rc20110530-1_i386.deb 0f43e00a82d7a0e51b6049f2ec4b722d 444174 net extra am-utils_6.2+rc20110530-1_i386.deb 7a818b743826ed07c0fbe398cd9b827e 50144 libdevel extra libamu-dev_6.2+rc20110530-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTePi6xypeFo2odvPAQKPYAf+LLlQY3jhqdbph2vGxYnnwz0rwDXVlt6m Uso3dEG/XKDknvDe5+MuRWYAEvHt8rTQl45yLvzEb4zdfHDMMzoXTiLDECp7jidd NaXk8nhOYG+bQoSx4Mb2w/TL9IUpXVPs056sBtW9/Ts4iffF2raIoX9IKMM0fl3X 1PTqVFkM9w6wz/sqjvpyYcAQyMBKPSnQUvGNkoa4wPkZ87UVFkQnimbu3F2s6i8a hr2t2MXsI8UD9YryNrRac61g5Vt1isZel+vZqwfRseEa1HZeVp+xjG9SQgwuDV63 XCSm83NUdsWXxSxc52HoKWOIjo7+y6Y5ocWayNikospoItEJ6T2iow== =vEI/ -END PGP SIGNATURE- Accepted: am-utils-doc_6.2+rc20110530-1_all.deb to main/a/am-utils/am-utils-doc_6.2+rc20110530-1_all.deb am-utils_6.2+rc20110530-1.diff.gz to main/a/am-utils/am-utils_6.2+rc20110530-1.diff.gz am-utils_6.2+rc20110530-1.dsc to main/a/am-utils/am-utils_6.2+rc20110530-1.dsc am-utils_6.2+rc20110530-1_i386.deb to main/a/am-utils/am-utils_6.2+rc20110530-1_i386.deb am-utils_6.2+rc20110530.orig.tar.gz to main/a/am-utils/am-utils_6.2+rc20110530.orig.tar.gz libamu-dev_6.2+rc20110530-1_i386.deb to main/a/am-utils/libamu-dev_6.2+rc20110530-1_i386.deb libamu4_6.2+rc20110530-1_i386.deb to main/a/am-utils/libamu4_6.2+rc20110530-1_i386.deb -- 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/e1qraxo-0001wg...@franck.debian.org
Accepted am-utils 6.2+rc20101201-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Jan 2011 20:16:13 + Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.2+rc20101201-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 496062 596966 597076 597077 Changes: am-utils (6.2+rc20101201-1) unstable; urgency=low . * Imported Upstream version 6.2+rc20101201 * Patch buildall so it notices the localconfig header * Patch to fix kernel structure hostname field (Closes: #596966, #496062, #597076) * Fix restart problem (Closes: #597077) * Patch configure.in to detect linux/nfs_mount.h properly * Updated build procedure for squeeze * Updated to standards 3.9.1 and fixed Lintian warnings Checksums-Sha1: 7c03405fb3d2cf1a491d906bc312c03df534eeb1 1613 am-utils_6.2+rc20101201-1.dsc 6975e188783887f07fc423604f06e5b15be3898c 1068036 am-utils_6.2+rc20101201.orig.tar.gz 2441d485db147144c4261b39704cf4b7b7ccf5e3 74419 am-utils_6.2+rc20101201-1.diff.gz 592498c25fd0cee6ae0460aea240613577fe049c 415162 am-utils-doc_6.2+rc20101201-1_all.deb b844828ef1df3dc7cce5d41fc6665d84d8355bc3 179490 libamu4_6.2+rc20101201-1_i386.deb f90f8c2f339e55c82943e8dc7a8b1bccbd27ebb4 442904 am-utils_6.2+rc20101201-1_i386.deb 7af2c89897ff3d5ab16a0f4799e8de562613b668 50616 libamu-dev_6.2+rc20101201-1_i386.deb Checksums-Sha256: fd54ae60ab11f06f4215ad0b786447c844ae754545c22c65cb00498436713d6e 1613 am-utils_6.2+rc20101201-1.dsc cc5092b2a01532822da0aa0dce9dd8b93204babcf62b0bc4b8854b47cee66233 1068036 am-utils_6.2+rc20101201.orig.tar.gz e7bba717eed5a43edf7d5855522502aed88eaa541bdaf721ea8f2a682906ad92 74419 am-utils_6.2+rc20101201-1.diff.gz 80605dded4d61e186d76aa0a5e1f08af1e60d73e26a9323359c2bbcb4b44b0e2 415162 am-utils-doc_6.2+rc20101201-1_all.deb 8a539501ea37f02087fb73a5ef3038ebf5cec66775ecaad68e8c60c969771fb6 179490 libamu4_6.2+rc20101201-1_i386.deb 80c89b07420cc4181483686729895d202b3980a55fd3b2c887ae2937920d6741 442904 am-utils_6.2+rc20101201-1_i386.deb b72cc8d7e8a3f719455b0a5f0008e88232dd5386be00d50c17882e8902ad1fa3 50616 libamu-dev_6.2+rc20101201-1_i386.deb Files: 8124cee3318227c82b251b947daa1dc3 1613 net extra am-utils_6.2+rc20101201-1.dsc c49bc01ba3f5790cf521092495715f4b 1068036 net extra am-utils_6.2+rc20101201.orig.tar.gz 7a0cb635bcd6c8050ad7ecdd1b864f0f 74419 net extra am-utils_6.2+rc20101201-1.diff.gz 07f89c412638c81202b5694d611817d8 415162 doc extra am-utils-doc_6.2+rc20101201-1_all.deb 9980409d5d9d38d7eddc03c0ef5f2aaa 179490 libs extra libamu4_6.2+rc20101201-1_i386.deb a966d04950de80e6fc7c5040ba3e8c79 442904 net extra am-utils_6.2+rc20101201-1_i386.deb 500bc78c091362553cd129192bd1e754 50616 libdevel extra libamu-dev_6.2+rc20101201-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTS4PpRypeFo2odvPAQKkvAgAiBMUxeBr75KZClLCnVRWoD6kl5bmBurE mP/KZtxs7eka9ATwSKzMngDV+h8DYopgK6VXwmUmvwppqY6dFTHJQuW6qLq3eA7c Lm5w0lk2tSfmNlz42pTk0Tg8xgPhSi8YjjK9fVwnqP5L32g6KTBSYYgEm3ZuUfLq P8iZ1KnBM7uXx6tHJQ6UmvTZqC64YtaYnDD3qwb1AQS+7YS1iGunVxX5qYbt2rfC jVHGBTRa8W1M0M8lYZW5/rpbzexWVY1ZB7Y3ScXNIznVbw8JxSyTzhwarDN2Mldr CdQ/PbuY0EG+C8UT9E1o0Fx0eCoQjAfFil95CS5W7iQMTn88u/+8zQ== =/k+z -END PGP SIGNATURE- Accepted: am-utils-doc_6.2+rc20101201-1_all.deb to main/a/am-utils/am-utils-doc_6.2+rc20101201-1_all.deb am-utils_6.2+rc20101201-1.diff.gz to main/a/am-utils/am-utils_6.2+rc20101201-1.diff.gz am-utils_6.2+rc20101201-1.dsc to main/a/am-utils/am-utils_6.2+rc20101201-1.dsc am-utils_6.2+rc20101201-1_i386.deb to main/a/am-utils/am-utils_6.2+rc20101201-1_i386.deb am-utils_6.2+rc20101201.orig.tar.gz to main/a/am-utils/am-utils_6.2+rc20101201.orig.tar.gz libamu-dev_6.2+rc20101201-1_i386.deb to main/a/am-utils/libamu-dev_6.2+rc20101201-1_i386.deb libamu4_6.2+rc20101201-1_i386.deb to main/a/am-utils/libamu4_6.2+rc20101201-1_i386.deb -- 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/e1pjq7g-0007nw...@franck.debian.org
Accepted tkcvs 8.2.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 20:45:30 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.2.1-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: tkcvs - A graphical front-end to CVS and Subversion Changes: tkcvs (8.2.1-2) unstable; urgency=low . * Updated to standards 3.8.4 Checksums-Sha1: 893d88091bcb64eb955120418801fde201e06443 1277 tkcvs_8.2.1-2.dsc 6caffefe85a3c1be04311ee535cccbd13da1ceac 10546 tkcvs_8.2.1-2.diff.gz 3daf510529e3063c1a3bd97d32280d219dbb08b6 1175804 tkcvs_8.2.1-2_all.deb Checksums-Sha256: 260b999d456de2ada224bc8527a8bb7ba76923dc0b9fde95b972d505855d139e 1277 tkcvs_8.2.1-2.dsc 8ddc44f3057955bc4454c9d388c4c77143963eff336c43a71fa7e46178390f07 10546 tkcvs_8.2.1-2.diff.gz 4f2bd96555e55d920f64f100c47271cec5382a9211e76288f325d91208f59ffe 1175804 tkcvs_8.2.1-2_all.deb Files: a86746c961900ef6e57f9535020f88b4 1277 vcs optional tkcvs_8.2.1-2.dsc e6f7591c5f4884b0ee1f6d89b6afe8dd 10546 vcs optional tkcvs_8.2.1-2.diff.gz 2f7eaa9e9b4598ce6be807c5d4a046ed 1175804 vcs optional tkcvs_8.2.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBS/1syRypeFo2odvPAQJIEQgAt1guWL+iE+GTxsX3ldOGQHiMSw2jFb9W mmlmsTjyB0u2fmBfJl2Nf7cw7BYB/9ZGprzXknBzDBugbDv/ReVH6WEJyU/O8qN1 PqACiRBr6XHDklvh4Uooc21u1OJJTOw59Rq+R4TEKccioLMQvAYOL3+J3rnN8wcZ ygzTcPTRrhsdfiZdKzyQ8rckxwiYbmG8KZGgFLqJK3+d9K7rkHJgE67rhqDC+2eC IPw5l8zoxClX3o1572nvB8SINDL+HzYDWgg/WkzaAjx1qXiaaj+EA+cN1smr4gbG R/ddfFfMGh7Sk8P801OMNxjDwE40oRkGYme6/FQFE3TynA8GPn4XrQ== =MAcQ -END PGP SIGNATURE- Accepted: tkcvs_8.2.1-2.diff.gz to main/t/tkcvs/tkcvs_8.2.1-2.diff.gz tkcvs_8.2.1-2.dsc to main/t/tkcvs/tkcvs_8.2.1-2.dsc tkcvs_8.2.1-2_all.deb to main/t/tkcvs/tkcvs_8.2.1-2_all.deb -- 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/e1oil7x-0002zj...@ries.debian.org
Accepted tkcvs 8.2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 09:25:49 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.2.1-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 545106 580191 Changes: tkcvs (8.2.1-1) unstable; urgency=low . * New upstream version (Closes: #580191) * Change package section to vcs * Remove conflict with tkdiff, but keep 'Replaces' (Closes: #545106) Checksums-Sha1: 2ee0df9d1388d61299c6d58027246fb2922000ae 1277 tkcvs_8.2.1-1.dsc be8f9a5bbb630c4721969211a183c0d1557fb209 1182929 tkcvs_8.2.1.orig.tar.gz bb540efb97aa7508d6d4fad4d44985d39f040f0c 10474 tkcvs_8.2.1-1.diff.gz 8ff57382c40af98f74abb4ad583fc03a3df79482 1175782 tkcvs_8.2.1-1_all.deb Checksums-Sha256: d75292bb34c4945dae174374d910678952d430800893a7b404d0151910654d99 1277 tkcvs_8.2.1-1.dsc 03d1a0c6c69b150eee81127dd8153529787aaee34012e1e168ca9c4bba8278aa 1182929 tkcvs_8.2.1.orig.tar.gz 9bd90678d551972db3c5d8dc22cba13c102cb1b69f8d14ffa7425f5fdfc0fec0 10474 tkcvs_8.2.1-1.diff.gz 94d0ecb423f5ccfb803b783e2b46381d7332572dde4341e102587ee709ef56d0 1175782 tkcvs_8.2.1-1_all.deb Files: bbfe2174dadf8f73637067923baf50be 1277 vcs optional tkcvs_8.2.1-1.dsc adb16f196b0350f3ee8158d2909ea5eb 1182929 vcs optional tkcvs_8.2.1.orig.tar.gz 4f07bcf237f62f51817317c9fda3bb73 10474 vcs optional tkcvs_8.2.1-1.diff.gz 780fe28b362eb4c186515e6d310b9865 1175782 vcs optional tkcvs_8.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBS/zNqhypeFo2odvPAQJlKwf+MBRXl7kZ+lDOIUk7hmDFmcaVD4tsEdSp 1+PXHCqxLb5OyJ+TdWewgaeGTb7lHDQi8VYCN3dtPDUfytDlLyOHJPZsFa/Aseoh yccQhxVrMchCUplrwl+2Y/4B6vTpX1rbZwr7ZMLar8TuDmcF4Zx5lkIrXSURywkO ufpLlmnmNe3GnEEQfTnYwIqX8qYdQ/3NMUZvnLLFqkupyaiX/+fjXxpwCfFy3jaB pvaWnR2R3+q9wSzHm3kXmA4MNz8GiEaN+gHkWQ+QpyuYWzjC8yCCo2hTFuWA/jkV dokVJIUTgTOZe2EgSNS9MctxntiUbX62nOIIgEcRHElk9RjQEtYBUw== =2aDm -END PGP SIGNATURE- Accepted: tkcvs_8.2.1-1.diff.gz to main/t/tkcvs/tkcvs_8.2.1-1.diff.gz tkcvs_8.2.1-1.dsc to main/t/tkcvs/tkcvs_8.2.1-1.dsc tkcvs_8.2.1-1_all.deb to main/t/tkcvs/tkcvs_8.2.1-1_all.deb tkcvs_8.2.1.orig.tar.gz to main/t/tkcvs/tkcvs_8.2.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 Archive: http://lists.debian.org/e1ohlyz-0001lv...@ries.debian.org
Accepted am-utils 6.1.5-15 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 16 Sep 2009 09:49:30 +0200 Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.1.5-15 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 546774 Changes: am-utils (6.1.5-15) unstable; urgency=low . * Updated to standards 3.8.3 * Fixed build problem with info docs (Closes: #546774) Checksums-Sha1: b2fc1e833989b9c57f1e450dbaf40bd98728dc42 1553 am-utils_6.1.5-15.dsc 5d40790e90afb2922f95391559e0580fdfdc482a 72016 am-utils_6.1.5-15.diff.gz 8d550bb5b7f59be3de285fd9aa356fea814fc3cb 700088 am-utils-doc_6.1.5-15_all.deb 89bd5031f22b726026a137232726bc5d6433d0d7 164778 libamu4_6.1.5-15_i386.deb a45659534bbde2b3432e6e8e587bf93cad5b0ad3 396686 am-utils_6.1.5-15_i386.deb 82345cf294833ee779c33b9967b840b6cdbebe6f 45272 libamu-dev_6.1.5-15_i386.deb Checksums-Sha256: 3a425dc9c28eb2fcdc9bcfdc1b74644c780ccb46558cab7a0de84f00aae45373 1553 am-utils_6.1.5-15.dsc ed4afe5e329e19c74dd0cb4291b15bf07814eba3113610b44be062e4404df1f5 72016 am-utils_6.1.5-15.diff.gz 2b098f4979f4ddb6ccc79830686afe1e8a2f2ac70e551012f584c3569343b728 700088 am-utils-doc_6.1.5-15_all.deb 4cdd552ccd52049bbb452afb5f1bddf994d84d86a68fafbaee4d97605a79e62d 164778 libamu4_6.1.5-15_i386.deb 8f70dec40fa806388eefc5bf57d42c5aaf833233fa5ce24c1c39e1bb9ccd15b7 396686 am-utils_6.1.5-15_i386.deb e38cd961b2d56f86e15c6f538f2fb84fb1b16f11ab7a36726dd5251437f598fc 45272 libamu-dev_6.1.5-15_i386.deb Files: 70aceea96494968bc66301909bd01ad2 1553 net extra am-utils_6.1.5-15.dsc cc3a7d1bcbce75c9699e38ea74a990c2 72016 net extra am-utils_6.1.5-15.diff.gz 60052ba1ef01727fef42df5c81029a04 700088 doc extra am-utils-doc_6.1.5-15_all.deb 723c638333d1f6646f9ed53f5803f46c 164778 libs extra libamu4_6.1.5-15_i386.deb a9cee91bbc37ff4d1baf43d42f65a74a 396686 net extra am-utils_6.1.5-15_i386.deb af7fd241ded1922b778a5dcdd4bd19c9 45272 libdevel extra libamu-dev_6.1.5-15_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSrCf5BypeFo2odvPAQIg2Qf/QFQmTdnCoDCWDnmMCDI+22xBGDvEBYsu iOLcLQ/i+VCxFmXKxl1sGEckUHtnlI4jWcMqSfKGhVC0gON7tb9Cd2NtDssbO5H5 Iqh7n08eTjgBTEFzmm7+xzyqAN2eAKChT/OOgCtSjNHUV+h7cN3EUB2or2Zr2hnE 1F080AJb/f9aJGAdwrpVUyiKT/TOd2y1aNQCCM0to2dJrt52QHsOjYAKqBUYSqPi QNBTTaXGdHYAntYW0E+uOgFhZJdoa+niVpFespbv4jneB4V0W04rfw9AJnd+nMT8 /SghpJbciZDnxQlEgmowb2K+OtZi86qsmg+QPw9Lb4pUppJhyUYFkw== =iRUx -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-15_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-15_all.deb am-utils_6.1.5-15.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-15.diff.gz am-utils_6.1.5-15.dsc to pool/main/a/am-utils/am-utils_6.1.5-15.dsc am-utils_6.1.5-15_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-15_i386.deb libamu-dev_6.1.5-15_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-15_i386.deb libamu4_6.1.5-15_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-15_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted tkcvs 8.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 17:33:08 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.2-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts t...@chiark.greenend.org.uk Changed-By: Tim Cutts t...@chiark.greenend.org.uk Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 412987 517897 Changes: tkcvs (8.2-1) unstable; urgency=low . * New upstream version * Updated to policy 3.8.2 * Removed conflict with tk8.3 (Closes: #517897) * Change the suggested tag date format to avoid locale issues (Closes: #412987) Checksums-Sha1: e4fb0a43137b9a0fbe6dfa6261164e53741008ca 1262 tkcvs_8.2-1.dsc cd9c074ee1731a9daf8ee4980db59969116a37de 1168522 tkcvs_8.2.orig.tar.gz 5f060fa2c126c699155132aacd73ca63328540a7 10748 tkcvs_8.2-1.diff.gz 10657aff82c01fd243bff4ee63399830c53594ad 1160326 tkcvs_8.2-1_all.deb Checksums-Sha256: 0db443c08e43d96c5d85017f16024d85de6a1c0414ea7fb120ac39694cf7035d 1262 tkcvs_8.2-1.dsc ec4d48462fd40fc1fc71f291fba39454883fe819484a4b65acc52310702fff37 1168522 tkcvs_8.2.orig.tar.gz 7ddee17c9667c49bde68c88831d8d8ab0345f9a9936e4b0d0493784c923c1591 10748 tkcvs_8.2-1.diff.gz 6068e90fabe0f1b331fc20659123058117b9b2e6fe2fd24b6e9ad36e77e8e702 1160326 tkcvs_8.2-1_all.deb Files: bd8e055791d3467ddf6b26bd7006b4b5 1262 devel optional tkcvs_8.2-1.dsc 28400e226b910e79360d562f700f4650 1168522 devel optional tkcvs_8.2.orig.tar.gz 899cffd384880374da0e9413c2bdf487 10748 devel optional tkcvs_8.2-1.diff.gz 044ee6ce841919b537d058c1b7d5c80f 1160326 devel optional tkcvs_8.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSoLpARypeFo2odvPAQJtjwf/Ta7Rdqt/T2LT9I7KLIE6hLFRqOZnqECX HyWBHMIAu/spz9lgYiHefe6yi7i3ZD8Qzduv9qVx8wf5THVoTUbHK4fuS8JV2rmQ /mCzwPoDZa298L4mQKLmA/5rwLv/LLFgg/Q/f7DMyxf8NwY/5eHtLv10T8QktYCI dAgC1Xu6oTMY4/ggmv9wqFTf66QJ1YYPcAWD5u5znNz1ZZh+WxFbtAtuOObPSgdX i3dwo+bnkq1kkCu98/seHcli/e9qVxhX4l4s99LXqf9gU+4u6Q8A1LVPc3K+GbNE FxuIZUvDSXjhj+h+QQLpudPoCq2jnuk5yggAQxbhWlWoSRu+Nzq8Gw== =qeXL -END PGP SIGNATURE- Accepted: tkcvs_8.2-1.diff.gz to pool/main/t/tkcvs/tkcvs_8.2-1.diff.gz tkcvs_8.2-1.dsc to pool/main/t/tkcvs/tkcvs_8.2-1.dsc tkcvs_8.2-1_all.deb to pool/main/t/tkcvs/tkcvs_8.2-1_all.deb tkcvs_8.2.orig.tar.gz to pool/main/t/tkcvs/tkcvs_8.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 tkcvs 8.1-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 21 Oct 2008 17:52:14 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.1-5 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 502922 Changes: tkcvs (8.1-5) unstable; urgency=low . * Accidentally missed out tkdiff (Closes: #502922) Checksums-Sha1: 646d14af736fab30e46aedf28830258489c18812 1268 tkcvs_8.1-5.dsc 263ec52beb90baef675bd2cea03f52e08ae81f26 10634 tkcvs_8.1-5.diff.gz 6c88c2b3c93a2b51d4906d12e2b78f02b2f6806f 1155906 tkcvs_8.1-5_all.deb Checksums-Sha256: 7deb7c932882a9161353064d5a207122456501e8e86c19f064b9d69dd6e95df5 1268 tkcvs_8.1-5.dsc a19a33c4d8fc561bb9dd30bb50c6f2fa01ff6f3470cc7284ddb51c2f26f9a71f 10634 tkcvs_8.1-5.diff.gz d9721dd029f0e40523ec3ad27aa70838cc797548bb7406e467adadde0aa680fe 1155906 tkcvs_8.1-5_all.deb Files: 5539fdebdfc640f77af93c4efdc03b4f 1268 devel optional tkcvs_8.1-5.dsc 41cc3e9388ba3ea118641f524cad78cd 10634 devel optional tkcvs_8.1-5.diff.gz c0ae8d6d82f6709f56cbc5ce16aa1553 1155906 devel optional tkcvs_8.1-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSP37IBypeFo2odvPAQLmiQgAk0KfPAie6uZw20Nx9ONBH7DYHs3R+qpS 91WwPJ9I0vX2+EdJ9ITz6auiCqsE0oUUYuQdlXMLfdNsQNvJ5aVUuL7oCVin024x 5iDtoB9vZX0ZA0dAgUZGMAfi4+BXtOMvg15YlHxBZ8jmroQvl56TGCnj0TsDZbw3 jsYeyZ8lQppo/uVBuNnS/751O8FvSoK//rXAZBY3WOytkor/zksfRGYC0iCAsJtH +x6FidJkf04fsrEMM9Anzza8aFPHAgZhc6BsiEPhfCUOQC8YagFbM47jImeOKMRE u+nJBgadbhMP0cvzB9+My/JCxjqzbSU8q4tqHBSOzM8Id1EiSwIGkw== =qOm+ -END PGP SIGNATURE- Accepted: tkcvs_8.1-5.diff.gz to pool/main/t/tkcvs/tkcvs_8.1-5.diff.gz tkcvs_8.1-5.dsc to pool/main/t/tkcvs/tkcvs_8.1-5.dsc tkcvs_8.1-5_all.deb to pool/main/t/tkcvs/tkcvs_8.1-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.1-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 18 Oct 2008 20:57:34 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.1-4 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 502545 Changes: tkcvs (8.1-4) unstable; urgency=low . * Allow tkcvs to work with either tk8.4 or tk8.5 (Closes: #502545) Checksums-Sha1: b64f1dcaa176e91ac4520adfdc5786acf5ce311d 1268 tkcvs_8.1-4.dsc b813f5fe116bb49b72296b6159e0c6b41688e051 10585 tkcvs_8.1-4.diff.gz 2300dd9d8a047cf899f27be75760220233d55eec 1074634 tkcvs_8.1-4_all.deb Checksums-Sha256: 38d6ccbb2a9d89ddb715e96697a1218a9c73cad5e93e9002facdb337a1cbd806 1268 tkcvs_8.1-4.dsc 0f232ca907b286dd527c377c6fcedf675eb126b00d1f466b4a63d088b76f2afb 10585 tkcvs_8.1-4.diff.gz 678885d719d5d1ed27dd27bc3fd924e5dce9d86b451447a85425baff10d762f5 1074634 tkcvs_8.1-4_all.deb Files: f6a6ebd86bebe0267443527a50f3e23d 1268 devel optional tkcvs_8.1-4.dsc 9290112d13160554416aa4e7112fdfab 10585 devel optional tkcvs_8.1-4.diff.gz dfbce27f135bfd8c3677d6988047fb45 1074634 devel optional tkcvs_8.1-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSPo4ehypeFo2odvPAQKlgQf/f/tiIb/LDOrEh+tmdXhYdZZf7XXhM+9X lY8TCWHHNXbywmG7u3BD5oPKFQS+jbN5gZmkAw0ecbnKi0SCl7e0hWz5+LDagQGF NJMv4yPxWxqTaKfxERJ0EGmiDr58gZw9UK7zZWSQjTjw7sFK0FRai0mF8Xb9u84F ti1EZ44YnPateexro3FzytmtntukHmUB5hUn7Hn6pDGZLmxn9nikLTZTjO2XxHmW ezoKn5js0b+g4mtXZwX0J4r8QPb0MUXewFMqp5RkJdA2JfMl61dwDSE1tRLTJvD1 jd7wO2xTQiaPSasGf9+e0kn+wCpcvdcmnZt1jfd/fSSmJcDDEB56Mg== =qHXZ -END PGP SIGNATURE- Accepted: tkcvs_8.1-4.diff.gz to pool/main/t/tkcvs/tkcvs_8.1-4.diff.gz tkcvs_8.1-4.dsc to pool/main/t/tkcvs/tkcvs_8.1-4.dsc tkcvs_8.1-4_all.deb to pool/main/t/tkcvs/tkcvs_8.1-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.1-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Oct 2008 10:40:51 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.1-3 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 501256 Changes: tkcvs (8.1-3) unstable; urgency=low . * Patch from Alexander Galinin to fix merge within a branch (Closes: #501256) Checksums-Sha1: 8b2aacdd0a4c1b212d62b493548dd3173553d4c5 1268 tkcvs_8.1-3.dsc 9a359c7e92e7a2507bf28b91806ded6820d0ea75 10566 tkcvs_8.1-3.diff.gz 3d46a0e8375d61d8b22d752147bd604e16fa4ead 1155850 tkcvs_8.1-3_all.deb Checksums-Sha256: e8f7ea595f257518080d5b60d29fb47ebe14a58348759218e10069a2f70e404e 1268 tkcvs_8.1-3.dsc cca4822a5e7af87ed5d8415618e91968ed6af6ffd1feadffeec159dede135eef 10566 tkcvs_8.1-3.diff.gz 70b087f71160170daca7ee382940106112585bc341726a42c40d8706626698f7 1155850 tkcvs_8.1-3_all.deb Files: efe9b8a432560d91b30b031eaddd8916 1268 devel optional tkcvs_8.1-3.dsc da82f83bf1b04861d88f4ee3532a088b 10566 devel optional tkcvs_8.1-3.diff.gz 7c8ec8ba13563c39a045bf6cac609a49 1155850 devel optional tkcvs_8.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSOnVDhypeFo2odvPAQJl/Af/UuFN3oEqnGae792VSu0BiVTBCmlSjXdC fvLEuiTxkX8jowyUAw1DXICpN6b/PR0nUn/NUBcJQcVx8p4PjLLGqZqE0ICvH5WI LmuEb8ZheC7fXgS/vW00okA4gyFiYEWNNeyiM0wrHpLOQJ+28DLNpZ1krYetWtpK T06vI1oHgWhntB3rHulcJW95JvfZQ7ucHffo2BdvV5EueAq9YTECX6/q0q8S2c0V pcAMV9pQR6IxEdD5DXgMQQ9jJrOkXMeF7ff1lysNlSOCfE/57lWTzSYhi9paSXgK ezfHUVU1TgG8+kLBJ0u+w0YelGsXj+E6ORP5oNofUVbo0ZTHGkJimQ== =M6/X -END PGP SIGNATURE- Accepted: tkcvs_8.1-3.diff.gz to pool/main/t/tkcvs/tkcvs_8.1-3.diff.gz tkcvs_8.1-3.dsc to pool/main/t/tkcvs/tkcvs_8.1-3.dsc tkcvs_8.1-3_all.deb to pool/main/t/tkcvs/tkcvs_8.1-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-12 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 20 Sep 2008 11:26:27 +0200 Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.1.5-12 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 498707 Changes: am-utils (6.1.5-12) unstable; urgency=low . * Change postinst to use invoke-rc.d, so that am-utils can be safely installed in chroots. (Closes: #498707) Checksums-Sha1: 6b95bb03e797016ca06623ec2001b266832f3da1 1520 am-utils_6.1.5-12.dsc 6c07db73a08fda59321c531882adefca19ced8a7 73369 am-utils_6.1.5-12.diff.gz c6ee6bc88c90a31f00f0f485e3fcd547588a6f2c 567994 am-utils-doc_6.1.5-12_all.deb 475386cf1dae285e12e9736633069bb2bc6bebf7 164940 libamu4_6.1.5-12_i386.deb 6ef891733f9e69724e825321bd3897481844b228 392308 am-utils_6.1.5-12_i386.deb 3d49df0aedfb62d0e92c31d858c920413956d0ee 45336 libamu-dev_6.1.5-12_i386.deb Checksums-Sha256: 21aecff8a5c87582210d030f7daf29f41541b54810c3ac95de8dd31b6e8f87b1 1520 am-utils_6.1.5-12.dsc a125bd16a825c055207ce2bf706fb12e5ccc7d88e1f84e6a1954474af2e77d68 73369 am-utils_6.1.5-12.diff.gz 06489a2ad8f69aa6f285559d122fa13921c071470db43595a74f474605d4ea67 567994 am-utils-doc_6.1.5-12_all.deb d25ec3cbeb1e9ecdf17a0ff1d1b1df304810a7b102c669c0f868c7ca54522b13 164940 libamu4_6.1.5-12_i386.deb 9ebd19cc4dee0806058aad2c3eca4ee8b40c750d37fc800506b9750a473111df 392308 am-utils_6.1.5-12_i386.deb e9d9232c3827320c6f1a22ed37c039f67727abcdef54960a1b25f551b23c7915 45336 libamu-dev_6.1.5-12_i386.deb Files: 97fceb18050dfc7fe1f61b2dcb5f80fc 1520 net extra am-utils_6.1.5-12.dsc 01db1d0b83b2c88d3e26c42b046e95ed 73369 net extra am-utils_6.1.5-12.diff.gz 0f2b9b90de1df06e72c45697168c4ca9 567994 doc extra am-utils-doc_6.1.5-12_all.deb ac8442f2d9de21a9c8d98560b26e7660 164940 libs extra libamu4_6.1.5-12_i386.deb 1b482d0face7fe922d76ed7ee17e964c 392308 net extra am-utils_6.1.5-12_i386.deb ef09c05daab9dc6c5a12cf60e005b501 45336 libdevel extra libamu-dev_6.1.5-12_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSNTOnxypeFo2odvPAQLBOAf7BQTBHycZEtEzQFJl5zB+sfIkrhyZW6Pk Y3H5rbsOsjvO9rTwpOPNIUltmy2YEg/d2bSlQqNyBP1Vr6GQgm1pmG5qC0aW0il6 hQX+Zd/umDJozke1L9gW+MDwlohzUsC3qXQGp+4PMr/1IGnbtL20hEnDVeFAzanR OnW9yXrsjYVi/FTzPmhytSW51d+jhGVgZe3nevvsc02+tP+cKd0y8pYZH4MesvbN eG5B1FJfSsQurphavsTakJAmE+YKSscpaPrpFkgzQ0Avuxlmq70DO5votebX8aQB pt7guilzbiDx4IZd1zBndAN+exSIIkmJ9vZnj+qOG3L5020r4a2Q5A== =tbxk -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-12_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-12_all.deb am-utils_6.1.5-12.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-12.diff.gz am-utils_6.1.5-12.dsc to pool/main/a/am-utils/am-utils_6.1.5-12.dsc am-utils_6.1.5-12_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-12_i386.deb libamu-dev_6.1.5-12_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-12_i386.deb libamu4_6.1.5-12_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-12_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 05 Sep 2008 14:12:42 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.1-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 489666 Changes: tkcvs (8.1-2) unstable; urgency=low . * Updated policy to 3.8.0 * Fixed bashism in contrib script (Closes: #489666) * Fixed a couple of lintian warnings Checksums-Sha1: d81e18587ae0c2d80d25d9f9174281207e47db9c 1268 tkcvs_8.1-2.dsc 8e79db19fbddb8ae182fbbc2e6fea1a40834a985 10368 tkcvs_8.1-2.diff.gz 36626cab0c1cfcd4480366e884c67909460a18c6 1155800 tkcvs_8.1-2_all.deb Checksums-Sha256: 7cec0366ac48d1032cba9115f633e805b1e9e01fe76598700c4e53f7942165a0 1268 tkcvs_8.1-2.dsc 814565951fefce0b825df7752af6f1c215eadf65aad17d9c6ad691571859c8b9 10368 tkcvs_8.1-2.diff.gz a472047fe0fea9b2ac833a378efba6a176a11874e8e2a4aada5b85eecc80fb4f 1155800 tkcvs_8.1-2_all.deb Files: 3e62721b477ef96f005cea8dbfb027f6 1268 devel optional tkcvs_8.1-2.dsc 0e3b7e514c2326937eba230be6253081 10368 devel optional tkcvs_8.1-2.diff.gz c6e7133ec01e1b804194f4875b729eec 1155800 devel optional tkcvs_8.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSMEj/BypeFo2odvPAQLuRQf+JYMMyzIYtZaqtSm90CwliPGdIjGy6aT1 e5xdEqoZNzncVv8cZV/iQFLLnTHn6Xx0YCqy9HHaCRd//fxVbu3J5DWID9cUIghe SId6urkjIWbWeScvhFk0otnoV0o+alU8N27Dceilf35QBeUq38SL+IHUE/wD89Zu F36vBiRsC1eq09HjQwE7vjyiYSpScQyuqyp+V9i5TIK0Yxpt8xj/Lf4hAZxZtPd4 34J0iiLFbcZYlnUWXmuKIpo2rhhWEJzM+c2E2V399Wc5gsukuEz8mGCySqvg57FD 7RLzK0K7waAGzqHxAeP5I6ZVolJ4Y4DVBmmD6nS0rgXYvNJwD/lcow== =nYqV -END PGP SIGNATURE- Accepted: tkcvs_8.1-2.diff.gz to pool/main/t/tkcvs/tkcvs_8.1-2.diff.gz tkcvs_8.1-2.dsc to pool/main/t/tkcvs/tkcvs_8.1-2.dsc tkcvs_8.1-2_all.deb to pool/main/t/tkcvs/tkcvs_8.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-11 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 04 Sep 2008 18:34:21 +0200 Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.1.5-11 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 496060 Changes: am-utils (6.1.5-11) unstable; urgency=low . * Added patch to use at most version 4 of the NFS mount struct, pending a proper fix to support later versions upstream in the future (Closes: #496060) * Updated to policy 3.8.0 * Moved documentation to System/Administration (from old non-existent section) Checksums-Sha1: 91b9a5d6dde5a88408d81d0e32afd8d3e3bfeb79 1520 am-utils_6.1.5-11.dsc cc5fea120f1e30875fd2098e2b4f6a4e2d18b168 73375 am-utils_6.1.5-11.diff.gz a0db1e5e637d792e11bc8790ec76c73f489fd07d 567932 am-utils-doc_6.1.5-11_all.deb adc6ac15b242d56a1b5f9366261dd0d0b3bd68a1 164872 libamu4_6.1.5-11_i386.deb 8b2c6e0c3d09075a6abda5052f505c0a851bc32e 392316 am-utils_6.1.5-11_i386.deb 9edfc11ecb13e4ae4ff71849936237d12e871f3b 45338 libamu-dev_6.1.5-11_i386.deb Checksums-Sha256: 6bfbdf62101616b9ac0e1ba40d872ccb0aded016803e078319ac13513ec2c52c 1520 am-utils_6.1.5-11.dsc 80e3d23bab625c48a315df1dce58bae403c52bb99bff164b5c7e1c7ae42b2173 73375 am-utils_6.1.5-11.diff.gz d84a32f98c2c04afaa14a532f71d1df49ca6eed1558bf89633cf8560481469d5 567932 am-utils-doc_6.1.5-11_all.deb a7e1a9f6dbf0c40ae89940bdfbf4f2df2c4a89014f5a651215c18dfcda4f792a 164872 libamu4_6.1.5-11_i386.deb 95683a3e6afa8095ce359ca7888c9856a9ad8f55f453ccdc79891c000166f50f 392316 am-utils_6.1.5-11_i386.deb 0ae5a7efdf9242494869c186a112dc864669747b049d7ffcb31d2bcbedac1f98 45338 libamu-dev_6.1.5-11_i386.deb Files: bf6265a8acb43826686d1c1e765b802a 1520 net extra am-utils_6.1.5-11.dsc a14ec78bf1ea06812f6391857f887298 73375 net extra am-utils_6.1.5-11.diff.gz 140eca623e6a844da824889d5ef3992f 567932 doc extra am-utils-doc_6.1.5-11_all.deb 2601f21408d9f11a2821f897803969c5 164872 libs extra libamu4_6.1.5-11_i386.deb e290cc951c81a0ed4889bd86b09703cb 392316 net extra am-utils_6.1.5-11_i386.deb b5694106387ec77768f354d08c6b97ce 45338 libdevel extra libamu-dev_6.1.5-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSMElqhypeFo2odvPAQIqQAgAopNF5DZvsFxTNHBo8uyCi4apbdXKF5kI mUpghpOsExyRsLjKRmaKARbCcsBAVSF+XNsFJPGR2Vu8ASRRZO7Pr+WmYgxwxmQz x5H9JgnUA3Ceges8707xL5h0GLDbUtfpfH/7F5+E1qguEvYzESEr6Ll1/8VQKpwV DXGoKk2pldMRe4xL6MGXhsU/vduBvLTDldrNZzOgDM1nSVoZFw2y37Ksm8B3ZRP5 8Hvd+Zm2S5+qTQLC49lhVqNK8TAjMZVJF0XJ/0HOV/QFJqJb3/kr50fB10sbR99c 8kDERiYgzgF6aLRmZZ9bcmnKP2GIQuk6O30vB+a+u48+Vcm3sLqc8w== =GoEA -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-11_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-11_all.deb am-utils_6.1.5-11.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-11.diff.gz am-utils_6.1.5-11.dsc to pool/main/a/am-utils/am-utils_6.1.5-11.dsc am-utils_6.1.5-11_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-11_i386.deb libamu-dev_6.1.5-11_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-11_i386.deb libamu4_6.1.5-11_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-11_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 12 Jun 2008 12:34:36 +0200 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.1-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 485923 Changes: tkcvs (8.1-1) unstable; urgency=low . * New upstream version (Closes: #485923) * Moved to tk8.5 * Updated standards to 3.7.3 * Revised menu location according to policy * Added short description to tkdirdiff manpage * tkdiff is now being provided by tkcvs internally Checksums-Sha1: d8b5372f3aae7d39302ff8377ccb8254fbfdd46f 1265 tkcvs_8.1-1.dsc bddf1c3966f02a378e4ae926fe481a54f2d17dbd 1155137 tkcvs_8.1.orig.tar.gz 82b85c5a8d11834a126b442ba0ac3e68da2d70dc 7580 tkcvs_8.1-1.diff.gz d673b94efc9ee5548ba633d434d521152bb09da0 1155590 tkcvs_8.1-1_all.deb Checksums-Sha256: 07e309b7ebe6bf8cade5d50160996ed8553bd1e821804c3523562378c3ca3ea7 1265 tkcvs_8.1-1.dsc b207692d63d31e9a5d4d191595b78099404f8cfa97397d4a36567c91cd69c76e 1155137 tkcvs_8.1.orig.tar.gz 8b3e5cd113c826907dfb3f61805985ae1ee10fc3558ebd602f8a97bb952afd10 7580 tkcvs_8.1-1.diff.gz e37de30ffe2445d92b3e4d39ba803d94493177c09f8c1faf79cdbcdae6fd84c1 1155590 tkcvs_8.1-1_all.deb Files: 9653bfab7cd75dfd27af6ca1db1dbd38 1265 devel optional tkcvs_8.1-1.dsc e6f8a11602d66ffa8803360c8cd4e67d 1155137 devel optional tkcvs_8.1.orig.tar.gz 18ab0041c45d13e6fb194b87ee824eb0 7580 devel optional tkcvs_8.1-1.diff.gz d33066ca56565a2f8aacde5b765913f8 1155590 devel optional tkcvs_8.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSFEBrRypeFo2odvPAQJrdAf/QQ7mVWz6dVMUwGaBEerV8z9F1XQBbpPU Nu2j03IJ01+C9VUaAkf1zW4QmLTvv+aACV4BVwZNVm2ugIaoOXfY0d28BbsDDJHZ qOAPU6sCQQswh4P3Q+WUHhd5GkJqW8Kg5bWmsUxx0gK8CWwinpIrgdzeeXwEbMlI LL3T/pPQLwvuh2kypWPx9AMJxSU/HgXBloSlVvHVqsDTdJyFKBTYReFft09a1Kg3 4d8H8pZ/OgY9N9DXlQFa6uqGezSOTnP3WRtLYy/YIO8AF/885qDRc9YIl0AKT0UD g9GvsBTEwFK4aRhZBBBw9xoU9BIpT03sCxw4q1ISYjP9w2lYgesBcg== =zu3l -END PGP SIGNATURE- Accepted: tkcvs_8.1-1.diff.gz to pool/main/t/tkcvs/tkcvs_8.1-1.diff.gz tkcvs_8.1-1.dsc to pool/main/t/tkcvs/tkcvs_8.1-1.dsc tkcvs_8.1-1_all.deb to pool/main/t/tkcvs/tkcvs_8.1-1_all.deb tkcvs_8.1.orig.tar.gz to pool/main/t/tkcvs/tkcvs_8.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic debiian installation
On 7 Jun 2008, at 1:37 pm, Michael Tautschnig wrote: [sorry for cross-posting, I guess this thread should move away from debian-devel, but I'm not subscribed to any of the others] Hello, I would like to use a system to install automatically all my debian pc. But i don't know wich could be the best between FAI and PRESSEED. Somebody could explain the difference the avantage and disavantage of the two methodes...! It depends a lot on your specific needs. If you're fine with setting whatever is debconf-configurable (be it at install time, using d-i's preseeding options, or rather at the level of the installed packages), preseeding may be an appropriate way to go. FAI, on the other hand, is a very flexible framework for installing systems. Debconf preseeding is supported, but just one option out of many. You might want to run several scripts for fine-tuning your system, copy over config files, etc. Flexibility comes at the cost of probably slightly higher complexity, but people tend to get to know it quite easily. I use both systems, in different contexts, and the above is pretty much what I'd agree with. If your requirements are fairly simple, and you're principally installing very standard workstations which don't deviate much from the default answers, then preseeding works very well. Score +1 for preseeding. But FAI is much more flexible, and allows you to mess with pretty much any stage of the installation process in great detail. Score +1 for FAI. It's also more complicated to set up. Score -1 for FAI. FAI is easier to troubleshoot - as soon as the install starts, the machine runs an ssh server, even before hard disk partitioning has happened, so you can log in and inspect what's going on (or going wrong!). Score +1 for FAI. However, FAI usually depends on NFS -- yes, I know about fai-cd -- and so isn't very appropriate for installing machines which are not part of the same network (FAI: -1), whereas a preseeding install can easily use http or whatever to fetch its configuration information, and that's more WAN friendly (Preseed: +1). You might want to talk to the Munich guys who've done cool stuff with FAI there, including installing on wide networks. FAI has an update mode, which preseeding doesn't. So if you want to update machines, you can use the same FAI config that you're using to install new machines to bring old machines up to your new standard. Of course, there are other ways to do that (cfengine, for example, which is what I use rather than FAI updates). I think FAI works better when you have a wide variety of system configs to install, because you can define multiple classes and have machine very flexibly belong to any combination of those classes. Preseeding is rather more monolithic, and becomes hard to maintain if you don't want your machines absolutely uniform. So there are arguments in favour of both. On balance, I prefer FAI, mainly because of easier trouble-shooting and customisation. But I happily use both. This is all IMHO, naturally. Your mileage may vary. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-10 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 11 Jun 2008 18:04:38 +0200 Source: am-utils Binary: am-utils libamu4 libamu-dev am-utils-doc Architecture: source all i386 Version: 6.1.5-10 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 467054 467456 468423 479884 Changes: am-utils (6.1.5-10) unstable; urgency=low . * Restored mk-amd-map and manual page (Closes: #467054) * Added support for the DEB_BUILD_OPTIONS debug option * Removed ancient versioned conflict with old amd package (Closes: #468423) * Using quilt for patch management * Patch from Dominic Hargreaves for mk-amd-map to clean up temporary files more consistently (Closes: #467456) * Patch from Philippe Troin for using nolock option on toplvl mounts (Closes: #479884) * Turned the 6.1.5-6 autoconf changes into a manageable patch Checksums-Sha1: aa28eaeca55024a2e2520e725449f0892b9b56f3 1485 am-utils_6.1.5-10.dsc 8a189ccc398141c7fc164d27030c87b017544803 73073 am-utils_6.1.5-10.diff.gz 2205ac768c59ba9a0eb75208b37a9a3603525f5a 567774 am-utils-doc_6.1.5-10_all.deb ddb00fa225e747578f17aae98a452d72653eb43c 164354 libamu4_6.1.5-10_i386.deb 48cb1737ced9c686b0d9bf468e5eea663a21e81a 390588 am-utils_6.1.5-10_i386.deb 9ee8cbb9ccc637e8da63c88c3323a0b4bcf7ecc6 45122 libamu-dev_6.1.5-10_i386.deb Checksums-Sha256: 1ea448906a56cda7417593c9ef7ee072a95413ad11a83fafdf0bea28199826a8 1485 am-utils_6.1.5-10.dsc 31d58b88995eafa673ef743aa89939099011f4462c9f82090b555b358f02c904 73073 am-utils_6.1.5-10.diff.gz c32877b01b796b287fc9f727ee926d9a752c12ffbf984fc09744cfbddbf63c39 567774 am-utils-doc_6.1.5-10_all.deb e902bfc1f1f7ad45b277763bddb1f976c073e213381688fe8581ff549f895d8a 164354 libamu4_6.1.5-10_i386.deb 3028cf3020266260ae8f3e72d597ac4371cfca5ebbf70dd977b1bb286ac4be58 390588 am-utils_6.1.5-10_i386.deb 9a0cfce777aedd3d8a051154031f051760fe8db367d3dd370f878830d5cde9fc 45122 libamu-dev_6.1.5-10_i386.deb Files: b3a1a682c8adb7999a51942e7aa2 1485 net extra am-utils_6.1.5-10.dsc 00fcdb71ec5518d9ef48fb1ff3bc7dc2 73073 net extra am-utils_6.1.5-10.diff.gz 4d9fd955ec755e981c424ecde911a506 567774 doc extra am-utils-doc_6.1.5-10_all.deb 1703c4533d2042584101f5db1c51c75b 164354 libs extra libamu4_6.1.5-10_i386.deb b926597975152798e9238321f0e12c35 390588 net extra am-utils_6.1.5-10_i386.deb 20495928a801ff2186932b754d4d2871 45122 libdevel extra libamu-dev_6.1.5-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSE/5xRypeFo2odvPAQKSPQf/T7Xs9DSxOKFIF3ukpMSuxK/pogWg7kfk Q/kVr4JEvQfstsCNU8Sx08NvQ/RZ6jZIPXhrttVEsIsip+VfsniaNktWHjD1Jfpf g7ZhkreX1GchbuD6K1hfy+cfW7ttczUtjkNTTDX5pKrjQkYELe9eSuarMpCMowWz 5tNHeMibZmmGYubvjsmF3NMtDKloyr5qg+1rDefIX1VMMa7OSC0HhMFEVwJqiucy 0heAJoXX7U++q2fjdii24k/s0uqGxCF43xl7Ts/B598pREZTkmSh2i/fjX/TBJJB D0LkgSF5sC9MU4VjqFaLNKEqEnAnXUeRJ23ZaxDg5SUhmlSkrvjJEA== =unvm -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-10_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-10_all.deb am-utils_6.1.5-10.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-10.diff.gz am-utils_6.1.5-10.dsc to pool/main/a/am-utils/am-utils_6.1.5-10.dsc am-utils_6.1.5-10_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-10_i386.deb libamu-dev_6.1.5-10_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-10_i386.deb libamu4_6.1.5-10_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
am-utils and recent kernels
Hi people, I'm here to ask for your thoughts about what I should do with the am- utils automounter in Lenny. Recent kernels are more picky about some aspects of NFS, which has exposed a bug in am-utils. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479884 http://bugzilla.kernel.org/show_bug.cgi?id=10349 http://lkml.org/lkml/2008/4/1/402 The problem exists severely with 2.6.25 and later, with am-utils pretty much failing to work at all. But the problem is actually more insidious than that, and may need fixing in etch-and-a-half; am-utils with kernels 2.6.19-2.6.24 does not fail completely, but locking isn't working correctly. There has been much comment about this on the am-utils mailing list, but so far no-one from the upstream developers has commented. I have a nasty feeling the project may now be dead - there hasn't been a release for some years. Fortunately there is a workaround: change the default method am-utils uses for creating its intercepts from userland NFS to using the kernel's autofs implementation. This works well, and has some other advantages; it's much faster and doesn't suffer from amd's traditional pwd problem. But that last improvement is also a potential issue; because it does break backward compatibility to a certain extent. Any software the user has which has been relying on the value of pwd to store configuration information, for example, will break. An example is GNOME at sites where home directories are automounted from an NFS server. GNOME hard codes your home directory into its config files, and unfortunately it uses pwd for that, rather than the returned result from getpwent(), or similar. So I'm in a bit of a quandary, here. For new installations, clearly making autofs the default mount_type is sensible. But what can I do for existing installations? Ideally, I'd like to fix the upstream bug, but it's a bit beyond my capabilities, especially without assistance from the upstream team. Anyone got any thoughts? Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: table view wnpp page now on wnpp.debian.net
On 17 Mar 2008, at 3:35 am, Sebastian Pipping wrote: Tim Cutts wrote: Hm, can you help with creating a good set of colors? There are a number of programs around which can help with this. I use Color Oracle: http://colororacle.cartography.ch/ It sits in a Gnome panel, and will temporarily change your entire display's colours to simulate three different kinds of colour blindness. While I do like the concept of this application, it seems to be closed source and (probably?) does not take choosing colors off my shoulders. Well, at least it's free (beer) if not free (speech). Its algorithm is published, though, so if someone felt so inclined they could probably write something free (speech). I haven't seen anything open source yet. Basically, the general advice is to avoid distinguishing colours solely in the red and green components; red, green and yellow can all be confused by colour blind males. I have seen suggested spectra for use in charts for colour blind people, and the predominating colours are blue and brown. Still not free, but the following web site probably helps you do what you want: http://wellstyled.com/tools/colorscheme2/index-en.html Click on its triad button, and it automatically picks three contrasting colours which work in all forms of colour blindness (including the extremely rare case of totally monochromatic vision). For example: #5CB85C #B85CA1 #E6A173 is one such set, and works quite well for normal vision, because they are greenish, purplish and beige-ish respectively. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: table view wnpp page now on wnpp.debian.net
On 13 Mar 2008, at 9:33 pm, Sebastian Pipping wrote: Tim Cutts wrote: A minor niggle, but the colours you have chosen are not good for the 5% of your male viewers who have deuteranopia or protanopia, the two most common forms of colour-blindness. I don't have either condition myself, but I've been bitten by this before in web pages I've created... in particular the green and yellow shades are almost identical for people with either condition. Hm, can you help with creating a good set of colors? There are a number of programs around which can help with this. I use Color Oracle: http://colororacle.cartography.ch/ It sits in a Gnome panel, and will temporarily change your entire display's colours to simulate three different kinds of colour blindness. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's use in the Human Genome Project mentioned in the The Guardian
On 12 Mar 2008, at 8:15 am, Stefano Zacchiroli wrote: On Tue, Mar 11, 2008 at 04:28:31PM +, Tim Cutts wrote: Just thought you might like to read that as a break from the flame wars. Thanks, this kind of interruptions have indeed chance of breaking flamewars :-) However, you might be interested in http://times.debian.net, it is an advertisement place, blog-like, for this kind of good news about Debian. It reported about the very same news a couple of days ago: http://times.debian.net/1225-Sanger-Institute-Debian-cluster-320-TB-swap-1.5-PB-storage . I do find Tony's description of it as swap a bit odd. I run the thing, and I don't think of it as swap! It's more like /tmp; a holding area for the raw image data from the sequencers, before it's processed down to a more manageable form for long term storage. 320TB is enough for two weeks' raw data, at the current resolution and experimental procedure. It'll drop to one week when they double the per-experiment data output later this year... To be quite frank this stuff gives us, the admins, the screaming heebie-jeebies, but in a fun way. The scientists have some really fantastic ideas coming down the line, but the IT to support them is quite a challenge! We're always on the lookout for people to join the team - if anyone's interested in seriously large scale computing with Debian and has good ideas for how to deal with petabytes of data and thousands of CPUs, we want to hear from you! All areas are of interest; SAN storage, networking, cluster filesystems, automating systems administration, self-healing systems, interoperability with Windows and Mac OS X, scientific code optimisation, you name it, we have to deal with it. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: table view wnpp page now on wnpp.debian.net
The colors were introduced for distinction, to speed up hopping from bug to bug of a certain type. I decided against coloring the legend because it (probably, didn't try) looks ugly and because in my view it was not important which color ITP is. But that's just my view. I plan to open up the source soon so you will be able to play with that :-) A minor niggle, but the colours you have chosen are not good for the 5% of your male viewers who have deuteranopia or protanopia, the two most common forms of colour-blindness. I don't have either condition myself, but I've been bitten by this before in web pages I've created... in particular the green and yellow shades are almost identical for people with either condition. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-9 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 28 Jan 2008 22:34:29 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-9 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 462857 462880 Changes: am-utils (6.1.5-9) unstable; urgency=low . * Fix source package upload (Closes: #462880) * Fix permissions on debian/changelog to allow binNMU uploads (Closes: #462857) * Removed texinfo source from docs package - not supported by doc-base Files: 3cbad0ba0aa27f572c9323010a1b3fe9 1090 net extra am-utils_6.1.5-9.dsc 7842d4cf1da4c0af4ad0f09b7b68384e 70529 net extra am-utils_6.1.5-9.diff.gz 9be08a896a640974b38f214ba23dd432 567594 doc extra am-utils-doc_6.1.5-9_all.deb f0bd5eb7ef2a5cfd65163271e35991ba 164186 libs extra libamu4_6.1.5-9_i386.deb 6e7e50e2e27c1c535d508561ec8194cd 385710 net extra am-utils_6.1.5-9_i386.deb f115265e9825669c69c3422708577d19 45138 libdevel extra libamu-dev_6.1.5-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR59foRypeFo2odvPAQK6ygf+It1bvAEeTKeKVpYcno0riQoNaiRlX9r3 SbqDXvCAk9PHvxlsD15gt782F9BrHSF5g/dle1CpGcB3MzR87HQiAm7Ll69u+jER 1Y3iNQpEroWs45GaYygfe0dZ83BXXEOnvbCQgZ8FQO8lBmJp18K9UVQVPE5WKmwc uP4WkFwwrcjeDahNvKvuzxEIgLnGGwAlAAhSm3wwbac5oY1cU8iu6XB5UqskibuT ADcZsRTIVVKWxIrwtmDqwgjFOkeTaKdPnZdrM4oI+m0IeabYB+cjgGkph53Ey5UO A4c++dF0FbcppDBaIyTR7aK5wWtOF4EKAbjtkeQ6KESFohQp/8kp9Q== =zRyy -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-9_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-9_all.deb am-utils_6.1.5-9.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-9.diff.gz am-utils_6.1.5-9.dsc to pool/main/a/am-utils/am-utils_6.1.5-9.dsc am-utils_6.1.5-9_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-9_i386.deb libamu-dev_6.1.5-9_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-9_i386.deb libamu4_6.1.5-9_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-8 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Oct 2007 07:16:55 +0100 Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-8 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 447148 453795 Changes: am-utils (6.1.5-8) unstable; urgency=low . * New pt_BR debconf translation (Closes: #447148) * Fix shlibdeps for am-utils (Closes: #453795) Files: a111bcb1fa90fbe308bc8fe68c8f8117 1022 net extra am-utils_6.1.5-8.dsc 1a8b36cd563be079de639b8fa58701cd 1527657 net extra am-utils_6.1.5-8.tar.gz f8d94d3dcd84b1a06682ca267b88615f 661212 doc extra am-utils-doc_6.1.5-8_all.deb 2294407defd20a7c6e8565fdbc89e7a6 164066 libs extra libamu4_6.1.5-8_i386.deb c25c766f02c8999bd20cd67d3fef2358 385466 net extra am-utils_6.1.5-8_i386.deb 36dcb9bb9d1b516d3df675092ae50eb4 45142 libdevel extra libamu-dev_6.1.5-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR4yDvhypeFo2odvPAQLEJQf/ZUXTQpr1jdBXjZLVolrRTMu3pc/3XQTP cfSyG67qHDWUuaEdnwxa4iC4fckKY4FxssjmYqVEF/C3imb2fvC9tx75CokcX/b4 yuRLQsG5sKPRAfEfV22vx/vz0j2UdvTvmk4KNNiYlChOi5ZEyMkIIF05LZwuPW4D JP+skqzw18cYURS5TE37U4xNp9Z2ETRbvWaJz5RBAe7F4alQXBQiHV2BFnmv5xgn RB8OfIDdTFD5IfRaLDdx/epZqVliqYBePu0gKOiIW3F/11RyLobTZwRZBWbs9Nx4 ceSZ3BgOtAWgWLU/3+60RdQQBVrQ1ag56HgLsUpCVlauXlFgVAdGgg== =cpR+ -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-8_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-8_all.deb am-utils_6.1.5-8.dsc to pool/main/a/am-utils/am-utils_6.1.5-8.dsc am-utils_6.1.5-8.tar.gz to pool/main/a/am-utils/am-utils_6.1.5-8.tar.gz am-utils_6.1.5-8_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-8_i386.deb libamu-dev_6.1.5-8_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-8_i386.deb libamu4_6.1.5-8_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2 Dec 2007, at 2:21 am, Daniel Schepler wrote: I finally got through the test builds of all the source packages in sid for i386 using dpkg-buildpackage -j3 on a dual core machine. The results as before are at http://people.debian.org/~schepler/build-logs/bymaint.html . Some statistics: 204 built BROKEN packages 1408 FAILED 230 FAILED, even with regular build 8986 succeeded 1014 succeeded, but with jobserver warnings These are not encouraging statistics, especially considering the fact that there are undoubtedly many false negatives, so I'll hold off on submitting bug reports for now. Well, am-utils lists as building broken packages, but when I looked at the log, it was just that the parallel build had produced the multiple binary packages in a different order from the serial build. At least, that's my interpretation of the following from debdiff: Files moved or copied from at least TWO packages or to at least TWO packages - - -rw-r--r-- root/root DEBIAN/control From packages: am-utils-doc, am-utils, libamu4, libamu-dev To packages: am-utils-doc, libamu4, libamu-dev, am-utils - -rw-r--r-- root/root DEBIAN/md5sums From packages: am-utils-doc, am-utils, libamu4, libamu-dev To packages: am-utils-doc, libamu4, libamu-dev, am-utils - -rwxr-xr-x root/root DEBIAN/postinst From packages: am-utils-doc, am-utils, libamu4 To packages: am-utils-doc, libamu4, am-utils - -rwxr-xr-x root/root DEBIAN/postrm From packages: am-utils, libamu4 To packages: libamu4, am-utils Or does that mean something more basic that's wrong with the packages? Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR1PWWBypeFo2odvPAQLydAgArlhmYhkRt8s4FDKg8i5QYa6DlgrKJCz3 fKifS0P0w8yR3E7NLkpS5co+lFZ2Htb2xs4MMD7pWmRBXCxIsh6+6bIPnUfc/mp1 C3VfdfPwPAoER/A6EryfoBA2Y+tof7ewVjEDFaViIlWxsDhaRQgLAck/xx1m51Yd pbnscakO7P8BK9yzirhHHJ6VmlXgU4HkES2xkzZzAumxnmrklkzRWIg52iCBhi8h kGwTmBVAMeRlXP1Iu6sGZFGOIh72wjO2EQ7M5GsbVPYkwbPN/FoyrceSe+2hz+CO 2sA/w9f3wRhIH1WfgiLZTj4d9YGM95iNvkqhl4Wlc6A7IEkgSMvdHg== =QcpJ -END PGP SIGNATURE- -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3 Dec 2007, at 12:43 pm, Daniel Schepler wrote:
Control files of package am-utils: lines which differ (wdiff format)
Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (=
2.6.1-1),
libgdbm3, libhesiod0, libldap2 (= 2.1.17-1), libwrap0, perl,
debconf (=
1.2.0), ucf, debianutils (= 1.6)
So the Depends line got changed in the parallel build.
Sure, yes, I realise that one. Don't know why it's happening though.
It may change though as I make changes do deal with the shlibdeps
stuff that's also going on at the moment, so I'm going to deal with
that first, and see whether this problem persists afterwards.
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBR1QEaBypeFo2odvPAQJ1WQgAizNT66pUw/GB72oB8zc1+RVzYrseaRFo
pqZIerbj1mr3G4rKur+wuYAfVEJDR9zgSWEmebwGuklHsa+eztWcYAgWfD8OBvmD
1vSyhIhfgN0tARQQORX7Ba9G3lM7MnLs8/Rvn3APm0/vacJDDKCucEwdsTqDGpDH
yBh6/9yxF8lLiaumiomGO+vFZTkREXk2CtxNI8nh44ijgYkSdj1QZj9lZ7cuCC3W
8FnHeLlit9l2K3EVH/0dE/3YcBt2uf3QRfURVKdtPrwpNMuGh0FkuHdScm+BPh/L
oDHtYuSxkElPam3q25a8wno15wVt5qaz+nJ43TtvsC6WGJNxIqNorw==
=I2Ko
-END PGP SIGNATURE-
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.4-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 15 Sep 2007 08:52:42 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.4-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 442111 Changes: tkcvs (8.0.4-2) unstable; urgency=low . * Fixed bug in cvscfg(editor) handling, which caused .tkcvs to grow (Closes: #442111) Files: ba7b3f17253ac6a4a71c309752cacd4b 858 devel optional tkcvs_8.0.4-2.dsc b272bba3071b6f8fec37d6ef14ece02d 6766 devel optional tkcvs_8.0.4-2.diff.gz cbf65797c364eaa3364a7b2ce4d917cf 1070958 devel optional tkcvs_8.0.4-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRuzYIRypeFo2odvPAQL9gAf/Wu13bEHVQKCAlHx7cJ23cYU8d6nSbnyZ MWm0vhMoc7gioEb5ckJGlOTt0LgV7kYci+xoUiIdYRQLl9WK+UBF5/p5FjGgFJYu iAl/GhotPYtPsCZzWIHb83zOPBiUC5AWzU4aVhlo9anE1gLBpprQEywNc64RYTR7 N4ffmFHvQFu3c3f+QojYdJDexFoAWG7hkrkFlay4GdVTeB0b3oH7q4thto4b6GuX DQqFrB0i6UQoURB9VYzwQ1QGitg/GYZ+XNd4pu8mdBuobNtClKQOBiffiNm153K6 FkWZ9E/eFlxr/n41om8xzQdoT9c+JC8vNJVyErIGJ96Y/vgBTo2XnQ== =tOnI -END PGP SIGNATURE- Accepted: tkcvs_8.0.4-2.diff.gz to pool/main/t/tkcvs/tkcvs_8.0.4-2.diff.gz tkcvs_8.0.4-2.dsc to pool/main/t/tkcvs/tkcvs_8.0.4-2.dsc tkcvs_8.0.4-2_all.deb to pool/main/t/tkcvs/tkcvs_8.0.4-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-7 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 8 Aug 2007 16:36:24 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-7 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 436308 Changes: am-utils (6.1.5-7) unstable; urgency=low . * Added build-dependency on po-debconf to satisfy lintian * Changed build-dependency on libwrap-dev to libwrap0-dev (Closes: #436308) Files: 1d646fb86e0267fb74eb9464a20b563f 1090 net extra am-utils_6.1.5-7.dsc ca61f36cad98040e2028eb3478d47f34 70752 net extra am-utils_6.1.5-7.diff.gz 949591b9551f8de9fc1faa456e1fc8f9 661102 doc extra am-utils-doc_6.1.5-7_all.deb dc0654e4f0e56916f3e290a0140afaf6 384650 net extra am-utils_6.1.5-7_i386.deb 569c2cc2afd2315bb762a4d1014c5ef8 164314 libs extra libamu4_6.1.5-7_i386.deb c742bae5cdf4ca1cfa71130ce0f0b2c2 45460 libdevel extra libamu-dev_6.1.5-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRsAaNxypeFo2odvPAQJlXgf/SiA1fbnUC/qjR+hpjBSHqVY77omUKB+g dbkz/1X6mpUPfbZ98EsvfT4120CImteSw7FVyEfP9Ft66lejQrvOONUuvh5RqDYN bSJKD229N6rxJ9wJEunL2eFyKu+7nAndQpud+/sHoM9xgoHCJJhB+2QHDLVEeAQ4 RlYFKi83S0IbPDBcmF/wDf54st2eOY3QRL92fiaNu5+tvUjTH2sLtq4ebhGrc3rP xJYdcKGpV12iE9zbR9ZcGY89xFL8y+r6nMNMoLZOuospGbiqDxmhxzl/wjTI6lCJ 7dqh4J8qdYu2vU/sfbb/YB3xluw3YwRzPMcp1QR/IE8kr0BFcC4Rfw== =j8pV -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-7_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-7_all.deb am-utils_6.1.5-7.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-7.diff.gz am-utils_6.1.5-7.dsc to pool/main/a/am-utils/am-utils_6.1.5-7.dsc am-utils_6.1.5-7_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-7_i386.deb libamu-dev_6.1.5-7_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-7_i386.deb libamu4_6.1.5-7_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Aug 2007 18:31:15 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.4-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 375686 399391 417572 Changes: tkcvs (8.0.4-1) unstable; urgency=low . * New upstream version (Closes: #375686, #399391) * New tkdirdiff program * Fixed some minor errors in packaging flagged up by lintian * Menu entry correctly removed on package removal (Closes: #417572) Files: 981a0873f5531967038a99a284e91ddb 858 devel optional tkcvs_8.0.4-1.dsc b337f9d1514f1bb6528f60c8977815cb 1151160 devel optional tkcvs_8.0.4.orig.tar.gz 893bad0db9f6c00d771e79807dafe684 6780 devel optional tkcvs_8.0.4-1.diff.gz 07b2f744b7b722f28dd3f2bd806c2b68 1070956 devel optional tkcvs_8.0.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRsCVnRypeFo2odvPAQKkqwgAkDXcJoeFeLM/gbmJ1hQjjR82b0HNPi5k zHkZrZp4/Mhv1GuGyYrKq5x1NFI8Tn0BWlS7pgVrrtH61VKt35BrOXgkgoojukYG hcOFK+DmjlgVMiWjzSxR9m7ziXAcN01YwU1iLyqumKjUzjFtlp6pDRHfiSUWRoEJ egWu6Cl1oiE0VCsiJnXAzdfzUnymucvJTx4rJ1wlxXbGlsgHmTer13b/TXL16kgG 3x1IZoIt0puBaPYjf5hCIgXlJZeTGjrXoXDZ3sLWHJIpWVrnJI39lqoJzHgYmWnv KG6hFqLrUYIvu2DhDV4T9K9WIwkRnQVu/ImKt+nzXLszJQ+PsaaZdA== =Rwen -END PGP SIGNATURE- Accepted: tkcvs_8.0.4-1.diff.gz to pool/main/t/tkcvs/tkcvs_8.0.4-1.diff.gz tkcvs_8.0.4-1.dsc to pool/main/t/tkcvs/tkcvs_8.0.4-1.dsc tkcvs_8.0.4-1_all.deb to pool/main/t/tkcvs/tkcvs_8.0.4-1_all.deb tkcvs_8.0.4.orig.tar.gz to pool/main/t/tkcvs/tkcvs_8.0.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-6 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Jun 2007 18:12:53 +0100 Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all powerpc Version: 6.1.5-6 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 422415 427260 Changes: am-utils (6.1.5-6) unstable; urgency=low . * Enabled autofs support (nfs remains the default) * init script modified to try to be more thorough when shutting down amd especially when using autofs as the mount method. * Added Italian debconf translation (Closes: #422415). * Added build dependency on linux-kernel-headers, and backported autoconf change for kernel version from 6.1.6 CVS prerelease (Closes: #427260). Files: 534a30444d9ba4e6360ec0670cc41d41 1077 net extra am-utils_6.1.5-6.dsc bd5184b2a343051b78748b155b3be30c 71526 net extra am-utils_6.1.5-6.diff.gz ed6189fcce209d124d6c45df4a61f144 663280 doc extra am-utils-doc_6.1.5-6_all.deb 1b0e3e38c4ceefe632abbcf94f3d6ee0 418218 net extra am-utils_6.1.5-6_powerpc.deb 9081d1f3fb25b9531a1b65718db56720 169452 libs extra libamu4_6.1.5-6_powerpc.deb 81336f4b00c4b57652122139dc32369d 49150 libdevel extra libamu-dev_6.1.5-6_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRozL2hypeFo2odvPAQLUawf/e2/J1H66G6XO47jnqYlyzdfNHoGMbF7d gdAHnJlfHFemJPVCYl5TTd1OwOK9RGwgfc8zdYYXCJBOnRNUZ+35RPkeSpA5Ph18 w+SjN7JmbeQ0G3kYoKPxc5v+ysefWWxBZGbi4aiVfSXjeWesfA0/Zp0gyibCRyQ6 x7KSYZ0Sv7QH0P5dQdHK1iTcvGm4a/RU8BV4Lu7+zwiSvZia7h1o/CiKr3InumOy nCFcnjnH3LIwypshO19tCVsyIxANoqc25zX/96OpORjDEBkUTSoL3nuVkOg4DuOh kO5meg3wrgMl/EfIMX0b92eAlOSUPtwqqqOesIn2/W7/eOXnDQOsDA== =EKbV -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-6_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-6_all.deb am-utils_6.1.5-6.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-6.diff.gz am-utils_6.1.5-6.dsc to pool/main/a/am-utils/am-utils_6.1.5-6.dsc am-utils_6.1.5-6_powerpc.deb to pool/main/a/am-utils/am-utils_6.1.5-6_powerpc.deb libamu-dev_6.1.5-6_powerpc.deb to pool/main/a/am-utils/libamu-dev_6.1.5-6_powerpc.deb libamu4_6.1.5-6_powerpc.deb to pool/main/a/am-utils/libamu4_6.1.5-6_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11 Jun 2007, at 9:22 pm, Josselin Mouette wrote: You seem to strongly believe the cheap desktop hard disk is different from the server hard disk. This is entirely wrong. Apart from 10k and 15k rpm disks, these are all strictly the same. Only the electronics change. That's not true, unfortunately. They also have different design criteria for duty cycles, and more stringent MTBF testing requirements. There's been a lot of assertion in this thread, without any real data, so this post provides links to some hard data provided by disk manufacturers. Here follows a posting I sent to the Bioclusters mailing list a few months ago, which includes PDF documents from Seagate showing that their desktop products are absolutely *not* equivalent to their higher-end spindles: Quote begins: Practical experience of running a petabyte of storage arrays here is what I'm basing my opinion on, not claims for device MTBF. Besides, MTBF is highly dependent on duty cycle. MTBF figures are meaningless if you don't also consider the duty cycle. You need to make sure the spindles are designed for a 24/7 duty cycle. Cheap SATA drives normally are not. Anyway, you asked for figures, so here we are, from a spindle manufacturer and (later) from Microsoft (yes, I know): http://www.seagate.com/docs/pdf/marketing/tp_544_tiered_storage.pdf Their nearline fibrechannel drives have an MTBF of 1 million hours, 24/7 duty cycle, read/write. Their desktop SATA drives have an MTBF of 600,000 hours, but that's for an 8x5 largely read-only duty cycle. If you abuse them by running them 24x7 read-write, I dare say it will be considerably less. But ignoring that, by my rough estimate, a double drive failure causing data loss of your RAID5 array using desktop SATA drives will probably happen about four times more frequently than using fibrechannel disks. Of course, you can buy high MTBF SATA drives but (surprise!) they cost about the same as the fibrechannel ones. More details here about what Seagate put in their cheap drives vs. the expensive ones: http://www.seagate.com/content/docs/pdf/whitepaper/ D2c_More_than_Interface_ATA_vs_SCSI_042003.pdf There are also some sobering graphs in this joint presentation from Seagate and Microsoft (apologies for the Powerpoint): http://download.microsoft.com/download/9/8/f/98f3fe47- dfc3-4e74-92a3-088782200fe7/TWST05005_WinHEC05.ppt The graph showing the probability of second disk error during RAID5 rebuild on desktop and server drives is slightly scary even for server drives, but positively terrifying for the cheap drives. This of course, is why we use RAID6 and a hot spare in our large Lustre filesystems. RAID5 is simply not reliable enough, using the SATA drives which underly our SFS servers. As many others have said in this thread, you get cheap or reliable. You do not get both. Quote ends -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRm6UlBypeFo2odvPAQJAzwf/fNAU26PvkXcsjKu+7nknd5WWpB6E1KtB fER1jAEgGjnJOAfumFR56m2QKMm+TDBOX1BQ5z7bV1S010QRme1zEwX8V8N+rAv5 9aLBUnhEAaBMEmy6ls0aQUv13SKgxjryBGUCdUP+xq2g8DSFpdH+4IKYjbIjPi7M nGU2UBH8zrxdkE32AwUU1PIP7gjmvDeiUUmkjbzoI+nUdPCLLEu/HgPShAZLHy3S fRQrRJc6q/gjtA8aTeOL5zUY7NhWjfSngO1A5B6Q26fr0LGUXYkjhuVdTpVY8aat 82os02g+J+gIHOqI8+4b/GkYETK8pEg/pO8xY2ofShTQXl6x9Uv/Ig== =LxT7 -END PGP SIGNATURE- -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On 10 Jun 2007, at 6:38 pm, Steffen Moeller wrote: On Sunday 10 June 2007 17:20:54 you wrote: On 9 Jun 2007, at 11:27 am, Steffen Moeller wrote: Once a (computational) biologist starts a new project, (s)he wants the latest data no matter what and anything older than three months (or a week sometimes) is likely not to be acceptable. Actually, my experience is that they tend to want diametrically opposite things, at the same time. 1) When starting a new project, they usually want the very latest data. 2) But they usually then want to keep that data static for the lifetime of the project. :o) very true. For 1) I hink that Debian packages for databases do not work. They might well work for 2), though. ... except that they usually want several versions present at once, which would mean a completely separate package name for each release. Ick. But ... how can one directly access a feature on the genome that has no accession number because you have just found it across releases of Ensembl? * base pairs and chromosome ID does not work across (NCBI) releases * centiMorgans are too vague * distances in bp relative to the nearest genomic marker? Not too bad, probably. The easiest seems indeed to keep the data on which whatever results are computed which is diagnosed as behaviour 2). Oh, yes, I'm not saying the requirement isn't *reasonable*. It just makes life difficult! Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Large static datasets like genomes (Re: Reasonable maximum package size ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5 Jun 2007, at 9:47 pm, Roger Leigh wrote: Anthony Towns [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 06:28:53PM +0900, Charles Plessy wrote: Le Tue, Jun 05, 2007 at 10:09:07AM +0200, Michael Hanke a ?crit : My question is now: Is it reasonable to provide this rather huge amount of data in a package in the archive? many thanks for bringing this crucial question on -devel. In my field, I wish that it would be possible to apt-get install the human genome for instance. Are either of you going to debconf, or able to point out some example large (free?) data sets that should be packaged like this as a test case for playing with over debconf? The NCBI non-redundant database (nr). Having this packaged and frequently updated (maybe in volatile) would be fantastic. There are also quite a number of other significant (popular) databases used for bioinformatics, genomics, proteomics and other biological fields which would be really nice to have in Debian. Here's a selection: ftp://ftp.ncbi.nih.gov/blast/db/ ftp://ftp.ncbi.nih.gov/refseq/ ftp://ftp.ncbi.nih.gov/repository/ ftp://ftp.ncbi.nih.gov/pub/taxonomy/ Because these are all in standard formats, it might even be possible to have updated packages generated and uploaded semi-automatically. These would be really useful in conjunction with much of the bioinformatics software already available in Debian, which could make good use of them if they were put in standardised locations. Obviously such things can't be put into Debian directly; Debian doesn't update nearly fast enough. There's nothing to stop you creating a repository of data .deb files though, separate from Debian itself, which people can track. Especially if the BitTorrent distribution method becomes a reality. Here at the Sanger Institute, we use Debian heavily, but we specifically *don't* use Debian tools for either bioinformatics software or the large data sets. Reasons for this: 1) Currently, package management requires root access, and we want users to be able to update their own data sets (aside: I'd love it if we could have some sort of user package system which could allow non-root users to install software packages in areas they have access to, and yet have full dependency checking on the main system packages) 2) Having large data sets in packages installed on lots of machines wastes a lot of disk space, especially when modern cluster filesystems can get you just as good performance with only a single copy of the data. 3) The frequency with which updates are required is much too high to make the effort of the packaging worth it. Sanger has instead a single centrally maintained set of data sets, with a MySQL database attached which stores things like (a) the upstream version of the data (b) when it was downloaded (c) which local machines are known to have copies. There are then scripts which can be run to do things like ask what version of a database I can see locally, and whether there is a newer version available centrally. If so, which files do I need to rsync to obtain a new copy? As has been mentioned previously, a separate archive section so that mirrors could skip them would be nice. Together, all these databases are eye-wateringly huge. Especially when uncompressed. If you archive them, it really is going to get eye-watering. As you know, these databases are growing exponentially, and if you want to save historical versions as well... argh! Even Ensembl has abandoned the idea of keeping the data forever. As an aside, several people in this list are interested in large scale biological data, and you may or may not be aware that I'm giving a presentation at debconf about what we're doing at the Sanger Institute, and how Debian fits in. I imagine some of you would like to come to that talk, and if you wish to contact me off list to suggest things you particularly want me to talk about, then please do. Some of the topics I could cover: 1) Management of a thousand node cluster (choice of hardware, automated installation, configuration management, monitoring) 2) Parallel filesystems (Lustre, GPFS, PVFS etc) 3) Scalability issues in genomic analysis (especially in the software which builds and then presents http://www.ensembl.org) 4) Maintaining our own package repository 5) Migration from Tru64 to Debian 6) Multipath SAN access, failover and so on 7) Approaches to job scheduling on large clusters 8) Problems with MySQL at this scale Feel free to suggest to me things that you'd find interesting to talk about. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRmaMOxypeFo2odvPAQKhEAgArX2wh5j/2mBBYSWCWyFzezsYcgR6P6RE Ha2xD+z47hlomwrAQ6vvCNcCvdyro0OfneiQSJsuWPGJQW4wkN3UUtjrLkOybkHD EFNeAZO2qTC0AVzXmk7VpEWYbduPXSZJClGw7nueWFuLjBmnah7Q7nRoqbZFTMu+
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On 6 Jun 2007, at 12:00 pm, Andreas Tille wrote: On Wed, 6 Jun 2007, Tim Cutts wrote: ... (some interesting points) There were many valid points in your mail but even if the issue was raised at the example of biological data it is a more general issue for others as well. It might be that we could: 0. Find a solution for large data sets in generel 1. Find a solution for static biological data (I couldn't believe that all biological data are really changing that frequently). Sadly, it does. Data sets like the human genome are being constantly tweaked and re-evaluated in the light of more recent discoveries. New assemblies of the raw sequence are produced at irregular intervals, but additional data in the form of ESTs (expressed sequence tags, for the non-bioinformaticians that are still awake) and similar forms comes online all the time, and that's why Ensembl is completely rebuilt from scratch every two months. It used to be once a month, but now that we do more than 20 genomes, and not just human, we don't have enough human and silicon resources to do the whole thing that frequently any more. 2. Find a solution that might make the kind of handling of dynamical data as you described more user firendly (bittorrent). Bittorrent's main downside, as far as I can see, is that it tends to work best when there are lots of subscribers to the data, which isn't always the case. It also tends to require the sort of firewall rules which scare the pants of most network admins. As an aside, several people in this list are interested in large scale biological data, and you may or may not be aware A least readers of debian-med mailing list should be aware :) : http://lists.debian.org/debian-med/2007/06/msg3.html Cool, thanks for that. As the message above says I would like to organise a Debian-Med day where I would really like to discuss some things in a round of people who are interested in medicine and microbiology. It would be great if you would join this. Sure. I have no idea whether you will be in Edinburgh the whole time. If not just suggest a day where you would like to meet with others (in case you are interested). I'm not there for the whole thing; I arrive on Tuesday at about lunchtime, and will be leaving on Friday afternoon. I personally would be mostly interested in top 4 (Maintaining our own package repository). Fine - the top listed things were the things that first spring to mind, and that I usually find myself talking about! Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alpha for developers?
On 10 Apr 2007, at 1:54 am, Steve Langasek wrote: Hi Bernd, On Mon, Apr 09, 2007 at 11:27:05PM +0200, Bernd Zeimetz wrote: Sam Hocevar mentioned on his platform that there is no Alpha machine available for developers. As we have a few standing around in a cellar at work I'd be willing to setup one or two of them to be used as machines for developers, if there's anybody interested in that (and the machines still work). I believe there is a machine earmarked as a porter box that will be brought on-line soon at the same facility hosting the most recently added buildd (goetz.d.o). If that falls through, I'll let you know. Indeed - the machine (a four-way ES45 with 8 GB RAM) is ready and waiting for the DSA's to do their stuff. Apologies for the delay, but it's out of my hands now. We've provided the machine, it's up to Ryan and friends to get the machine set up the way it needs to be for DD's to use. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-5 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Mar 2007 09:17:49 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-5 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 414770 Changes: am-utils (6.1.5-5) unstable; urgency=low . * Added nl debconf translation (Closes: #414770). Files: 3e61c951335e5e5bf97d550c7ca6dc9f 1055 net extra am-utils_6.1.5-5.dsc dbc3b1e176cc5196cb4c5be2511c4788 66547 net extra am-utils_6.1.5-5.diff.gz d589a08b2ee85f1815e183ad2c873dab 658938 doc extra am-utils-doc_6.1.5-5_all.deb a988dc0abc8b3c1460b6371545a51f3b 381576 net extra am-utils_6.1.5-5_i386.deb b3ae9b03dce210f3ac8f5eee771491bb 163802 libs extra libamu4_6.1.5-5_i386.deb 31e2cb1091460c88d6cbf2e80b4fa20a 45986 libdevel extra libamu-dev_6.1.5-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRf0JLRypeFo2odvPAQKw7QgAxRnKJ859Nf47KONMdV7pkazyVWq9pITf 0Jb/vm6FyhqRA/GSI16Ge24QYvDzMRF17PN0mBzWNdRY8CitresdkoMO3zPE1ufJ Zrf+kG5J59ndaFpXTUMfc8DL5ddcPmzyDgM5m9PORE3N8AVkDUsDpOv6tQolQ7PB joh/ioQ/cq7z2fF+WQf5gThGfwkMszf378UuQa0J0ajIHIyJFRz5VDnaqu/YIPol io05TkAJ6d4vnoTmLui71d0xCRnMR+KstRPnZj9XupkBE8pySbVtfoHPQQ/cO2Mt y4zcmi0iq7MTEpTpt7GsWUVEzSvSo0OaODEriALbccfoCQYv/rgERw== =7tPu -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-5_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-5_all.deb am-utils_6.1.5-5.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-5.diff.gz am-utils_6.1.5-5.dsc to pool/main/a/am-utils/am-utils_6.1.5-5.dsc am-utils_6.1.5-5_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-5_i386.deb libamu-dev_6.1.5-5_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-5_i386.deb libamu4_6.1.5-5_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 5 Mar 2007 14:46:35 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-4 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 407579 413343 413386 Changes: am-utils (6.1.5-4) unstable; urgency=low . * New Galician debconf translation (Closes: #413343) * Updated Portuguese and German debconf translations (Closes: #407579, #413386). * Converted all debconf translations to UTF-8 Files: abf3d4c3d7685d7c7b3c3fb0ae5ead12 1055 net extra am-utils_6.1.5-4.dsc 99fa872ad7ca8b394dc7d3208a20d4a4 63976 net extra am-utils_6.1.5-4.diff.gz 4de57a0584f565bcac563f519c5b2b02 658902 doc extra am-utils-doc_6.1.5-4_all.deb 16a5f29c71db7d889de482797b33bdd6 379640 net extra am-utils_6.1.5-4_i386.deb a1dadeaeb7fef64f4c6456918c5155aa 163780 libs extra libamu4_6.1.5-4_i386.deb 6456e5a7c00843826640cfcefbc94d29 45984 libdevel extra libamu-dev_6.1.5-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRexFYxypeFo2odvPAQJuWQf/QDgiWxy+TYQv00r/3lmV0JWRFTmwwc3Z yKt1DIdm0Hu6udYDfhEyDr7SU2Tb2Idn8iEqLV4u5Qxo6/Z92xu8EgcI3vwTK06Z r3T1uIQesxPZNR1LV40TqWEBd5xDaafXPDhChGMNSzG7zZ8N8b5u9Oi6nKrXKE7t qZ544ym+ZNkh1y2OX9ohhqQgr3Dc9b04jyojxmk1VUUBGywo2fu057oSwpD7Rfdk Sm0BwDhHpBRfxidw5OtNCZNe85o8ZnAamHk4Zn91ZMJ2OBoFnp3XtBtHDPZ3i3Y2 gGSZ1/+AuQphTtyljxlLK9ovij+Eq3TamRX8bd3Wt8E0dg3sK+XHjw== =XCN4 -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-4_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-4_all.deb am-utils_6.1.5-4.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-4.diff.gz am-utils_6.1.5-4.dsc to pool/main/a/am-utils/am-utils_6.1.5-4.dsc am-utils_6.1.5-4_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-4_i386.deb libamu-dev_6.1.5-4_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-4_i386.deb libamu4_6.1.5-4_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I *love* goodbye-microsoft.com
On 24 Feb 2007, at 12:44 pm, [EMAIL PROTECTED] wrote: Strangely, I feel a tiny pang of guilt. I now have an apple box for the first time in decades. One of the main deciding factors was to buy unixy goodness :-) That was my main reason for buying an Apple four or so years ago. but also to get some exposure to OSX. I tried for a while to live in OSX, but in the end I installed Debian on it. It's not that I couldn't build everything I wanted, it's just that not having everything just work is like going back in time ten years. It's not that there isn't ports or fink, but there isn't debian, short of a full install, and the alternatives don't measure up. It's not that I couldn't take debian to osx (in my fevered imagination), it's that I'm too lazy to even try. Well, that's sort of what fink is. I have to sheepishly admit that I use OS X every day on my Apple machines. I don't have Debian installed on any of them - I do my DD work on server machines. The main reason for that is that I still think that for GUI things Apple have the edge over any of the Linux alternatives. The UI is simple, functional, and well integrated. Debian is fabulous in so many ways, but I still don't think any Linux distribution really cuts it on the desktop (although I do administer a network of 300 Debian desktop machines at work, so I don't think it's *that* bad). I've also been very pleased to not the fairly vibrant OSS community that has grown up around OS X. There is a *lot* of really quite good free software work going on for OS X (Fink, Camino, Adium, SSHKeychain being the principal ones I use every single day). Yes, there's a lot of Windows-style shareware too, but I think the free stuff is reaching critical mass, when it becomes difficult for the shareware authors to justify their position, when that developer over there --- is offering something open and free. Having said that, when I can justify it to my good lady wife, I'm looking forward to buying an Intel Mac and being able to run OS X and Linux simultaneously - I tried doing DD work under Virtual PC for a while, but it was a non-starter. Just way too slow. Just the configure script on one of my packages (am-utils, which admittedly has the configure script from hell) took more than an hour to run under Virtual PC on my 1 GHz PowerBook. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian in Sanger (Re: update on binary upload restrictions)
On 6 Feb 2007, at 11:22 am, Wouter Verhelst wrote: http://www.oracle.com/technology/tech/linux/install/xe_on_debian.html (dunno whether that's what you need, but Oracle does support their products on Debian these days, if I understand them correctly) Yes, I know about that (and indeed have given it a whirl), but they don't really support it properly. It's a case of we've made this available for you, but if it doesn't work, tough and that's with the ridiculous uber-expensive support contract we have. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian in Sanger (Re: update on binary upload restrictions)
On 2 Feb 2007, at 10:28 am, Gabor Gombas wrote: On Thu, Feb 01, 2007 at 08:10:56PM +, Tim Cutts wrote: What I'd actually like is some sort of non-root packaging system so that users could build software with decent dependency checking for their shared software infrastructure. Can dpkg be cajoled into doing that? I knew people who were doing this with rpm. AFAIK the only tricky part was the pre-seeding of the RPM database with some packages that were installed on the system level (like libc) so the dependency tracking could work. dpkg also has a --root ... option, but unfortunately dpkg seems to check for root privileges before trying to install a package so it is pretty much useless. Yes, indeed, because --root does a chroot() which requires root privilege. What I'm basically after is a dpkg-alike that uses a different root directory, but without using a chroot, so that non- root users can use it. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian in Sanger (Re: update on binary upload restrictions)
On 1 Feb 2007, at 1:00 am, Charles Plessy wrote: (Sorry for the noise, I reply on the list since Sanger's mail server thinks I am a spammer. Does it? I am very interested to hear that Sanger is using Debian on thousands of machines. Do not hesitate to tell us a bit more on [EMAIL PROTECTED] Bioinformatics is part of our effort as we include it in pre-clinical research, and we would love to see our priorities a bit more user-driven. Well, we basically use Debian everywhere we can; we have a few machines running other Linux variants where support requires it (Oracle, mainly). Our Top 500 compute cluster runs almost entirely Debian, this consists of 600 machines. Two are Tru64 Alphaservers, two are SGI Altix 350's running a horrible old version of Red Hat, and the remainder are all IBM blade servers running Debian. A total of 1462 CPUs. All the Debian machines use the HP SFS cluster filesystem (HP's productized version of Lustre) for sharing data. Job scheduling is with Platform LSF, and configuration management is with cfengine2 (our own modification of this; the package currently in etch lacks some features we need). Of the 700 or so desktop machines in the Institute, about 300 are running Debian, the rest Windows. There is a possibility we may move the desktop machines to Ubuntu, but that is not decided yet. Again, configuration management, in common with the cluster, is through cfengine2. We maintain our own internal package repository for both home-grown packages and local modifications of standard debian packages, backports and whatnot. We're quite keen to present something about all this at Debconf; I realise the deadline has passed, but hopefully they'll squeeze us in... For the moment, I am finishing to improve support of multiple alignment programs, and will work on EMBOSS with others soon. http://wiki.debian.org/SequenceAlignment http://alioth.debian.org/projects/pkg-emboss/ Generally, we are not using Debian packaging techniques for bioinformatics software. The software requirements of the users move too quickly, so packaged versions are always out of date, and besides, different users often require different versions, so we just leave the maintenance of such software packages to the users themselves, and store them on a central BlueArc NFS server. That's not to say that your packaging efforts are not valuable; I think they're extremely valuable, and will help small laboratories and the like build functional bioinformatics systems very quickly without requiring large amounts of assistance from dedicated support staff they probably can't afford. Regards, Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian in Sanger (Re: update on binary upload restrictions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1 Feb 2007, at 1:30 pm, Steffen Moeller wrote: Have you installed the popularity-contest package? No. The network admin didn't like the idea of all the mail messages. I think I might just ignore him though. :-) There is probably no point for Debian to compete in the package versions with upstream developers of BioPerl, Wise, EMBOSS and whatever other tools yours and your neighbouring institutes' are providing :o) What I'd actually like is some sort of non-root packaging system so that users could build software with decent dependency checking for their shared software infrastructure. Can dpkg be cajoled into doing that? A main difference of Debian to other Linux distributions is probably the merger of us and you/them, ours and yours/theirs. I am very confident that you will find sponsors external to the Sanger Center of even within who would help in getting your changes into the main distribution. It should be only a few days between submission and its appearance in unstable. Please contact Debian-Med whenever you feel that some action from the side of the Debian commuity could possibly be beneficial for your cause. And somehow I hope that you already feel a part of the community. Thanks. :-) Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRcJJWxypeFo2odvPAQLLZwgAwWX7rPWpl2MXlAe3tWwQ2auTFOhq8uru CkOhYVi0uIdjTzxmp3GzKvE3QShkp1hTT4RYvcA4afBqCc0WWxN1LpcuvfW+OFcc iqtWKhIc43cyQNxNVyDk/Nj/Ve0Y9wtNqIBZ0UAV6PMDn2CWwuy2NqHv63E68Kpm iChQqxqiY5JjxrzE5fNJJUZtXpANBEuRRlL7rTNDPOCbCgDUcVpmpp0QkGQ6GrZc 1T/Vw8+BSpJtaPmzYHQlFBjLqz2AyMS5+JITyeYsd44Qv+FlczVez4gd9RQRaoQJ s7yTO3CWFSH7aDiXqYlpYMbwC0zxcdKBDECPx6p+8NjPX/Oq4C5RSA== =wqfE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
On 25 Jan 2007, at 1:23 am, James Troup wrote: (a) we don't currently have the buildd infrastructure for this - it would require a minimum of 2 (preferably 3) machines dedicated to being i386 buildds. It would also make i386 uploads much more sensitive to delays and really require better coverage than one human could provide. Sanger could easily host at least one of these, in addition to the new alpha buildd we host. We have reserved 6 IP addresses in the firewall zone that goetz.debian.org sits in, so we can host another 5 machines for whatever purpose the Debian Admins would like. We have lots of bandwidth, and management buy-in to us hosting this stuff is strong (after all, we use Debian on thousands of machines here, so it's in our interests to help the project work) Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407446: [Fwd: Re: Bug#407446: general: automatic mount network share in filesystem.]
On 24 Jan 2007, at 10:08 am, Jean-Michel wrote: [am-utils] This seems to works with NFS. But what's about Samba? Out of the box, no, but it can do so if you create your maps correctly; am-utils supports using arbitrary mount programs, so you can tell it how to use smbmount, for example. See: http://www.am-utils.org/docs/am-utils/am-utils_10.html#SEC109 However, you will have the problem of what user to mount the filesystem as, since SMB requires, as I understand it, authentication against the server before you can mount the filesystem, and you then mount the filesystem with the credentials and access rights of that user. For read-only guest shares, that's not a problem, but for read- write access it is. So (a) you'd have to hard code the access credentials into the mount script you give to am-utils, and (b) all users on the system would be accessing the SMB share with the access rights of this hard-coded user. Again, that's possibly OK if this is a single-user system, but it's no good on a multi-user system. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of disk i/o per process
On 31 Dec 2006, at 6:34 pm, liran tal wrote: Thanks for the reply Steinar. The blktrace is a tool and I was wondering if there's something in / proc itself that I can use to get some info regarding the disk i/o per process. Yes, there is. echo 1 /proc/sys/vm/block_dump causes the kernel to log all I/O, so it all appears in your syslog. It's probably not something you want to leave switched on. :-) Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arches and etch
On 3 Nov 2006, at 5:30 pm, Steinar H. Gunderson wrote: On Fri, Nov 03, 2006 at 04:55:04PM +, Tim Cutts wrote: The 486 was the first CPU in the X86 family to have an integral FPU. Only the 486DX; the 486SX didn't. Being thoroughly pedantic, yes it did, but it was disabled in the hardware. When you installed a 487, it disabled your 486SX completely, and you were effectively running with a normal 486. A more interesting question is when Intel finally integrated the 86 and 87 processors; as I understand it, the 486 was effectively just a 386 and 387 in a single package; the regions of silicon were still quite discrete. I'd heard that that situation lasted for some time, but I don't know when they were properly integrated. It's kind of like Intel's new so-called four-core chips, which are basically just two of the current dual-core CPUs in a single package (which has interesting implications for memory contention issues, which led to some interesting discussions at SC06 last month) (Are we offtopic now? :-) ) Oh yeah! :-) Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils [was: Re: Upgrading the priority of ucf]
On 6 Nov 2006, at 9:26 am, Josselin Mouette wrote: Le jeudi 02 novembre 2006 à 05:22 -0800, Josh Triplett a écrit : I would suggest b); reducing the standard set of packages seems like a feature, it won't break upgrades (if installed, the package will stay installed), and new installs don't need to get nfs-kernel-server as part of the *default* install. We're not talking about the NFS server, but of the NFS client. And a working NFS client is surely something we want as part of the default install. If someone wants to run an nfs server, they can install an nfs server package, either nfs-kernel-server or nfs-user-server (no good reason to prefer one to the other). nfs-user-server is deprecated. I think we shouldn't even ship it at all. I still use it on some real-world servers, but I can't now remember why. I definitely found something which only worked with the userland server. Wish I could remember what it was, but since the machines in question are production servers, I'm not about to mess with them to find out... Tim
Re: Downgrading the priority of nfs-utils
On 7 Nov 2006, at 3:40 am, Goswin von Brederlow wrote: Roger Leigh [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] writes: Le jeudi 02 novembre 2006 à 05:22 -0800, Josh Triplett a écrit : I would suggest b); reducing the standard set of packages seems like a feature, it won't break upgrades (if installed, the package will stay installed), and new installs don't need to get nfs-kernel-server as part of the *default* install. We're not talking about the NFS server, but of the NFS client. And a working NFS client is surely something we want as part of the default install. What's the rationale for needing it as part of the default install? The majority of the Debian (and GNU/Linux systems in general) I see tend to not use NFS at all. Do we have any usage statistics for the NFS client? But wouldn't you be surprised if mount -tnfs server:/path /local/path suddenly wouldn't work anymore in a fresh install? And I'm not sure that you are right with your majority claim. A lot of larger installations use nfs and they quickly add up to a lot of systems rivaling the rest of the user base in numbers. Perhaps it's time I installed popcon on the 1000+ Debian systems I maintain as part of my job... :-) Tim
Re: Downgrading the priority of nfs-utils
On 7 Nov 2006, at 11:17 pm, Brian May wrote: Goswin == Goswin von Brederlow [EMAIL PROTECTED] tuebingen.de writes: Goswin But wouldn't you be surprised if mount -tnfs server:/path Goswin /local/path suddenly wouldn't work anymore in a fresh Goswin install? Not really, no. I would be more surprised if it did work. NFS has a reputation of being insecure. I am not aware of any organisations, big/small, that use NFS any more except on restricted sets of computers. puts hand up Er, here. Global NFS home directories. And at the last place I worked. And the place before that. Oh, actually, in every single place I've worked for the past 10 years. I suppose you could claim the set of machines running NFS is restricted in that it's behind a firewall, but that's the only sense. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-3 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 27 Nov 2006 20:37:54 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-3 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 400229 Changes: am-utils (6.1.5-3) unstable; urgency=low . * Moved amq-check-wrap check from config back to postinst (Closes: #400229). * Fixed an error in the postrm script Files: 583eb977219b6bc6a3079c0671ac5eac 1055 net extra am-utils_6.1.5-3.dsc fae46d376e8cd4b242b093f08b159cd7 61282 net extra am-utils_6.1.5-3.diff.gz 131ca266a6de0c41405d481634ffe0ea 627172 doc extra am-utils-doc_6.1.5-3_all.deb 4a4ca4b80238ac072edf96736d9db2cf 373490 net extra am-utils_6.1.5-3_i386.deb 22f3ad452d4a1d445117b2acb57704ad 163700 libs extra libamu4_6.1.5-3_i386.deb 2458444ee4d73ba6ba768776348a5395 45992 libdevel extra libamu-dev_6.1.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBRWtXzhypeFo2odvPAQJcewf/eSQNrXGyugU4CwOouT+7nz/ie/ZUUUwE 6NJRDW1WmFG1vQAByel8nepDaTmgSg0sx4PronJw89p7Co2f9NnYueuEbHLw67CC 7SNyhHluvhIy1p77kGfcBTZ0dvfe3JTI2mL/gVQmCImJktcgw78TjOehQmdC1JAc XcVAwJPWER58znEe/oxKgLF4qH075dpADmI0sjAH9XmPpmYKutRLxvB94cLWfs0g QvzErdOeu6NiwHhgMHY9KRTl5AY9QhyWptsXeP4Mhi0iNHBop0ZTJL12T9yjnPKy iow97epNR58yeutgeQHrXAnDsB5I1NYIjjqmvCM5B9plIQG+YzBv5g== =zIJ4 -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-3_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-3_all.deb am-utils_6.1.5-3.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-3.diff.gz am-utils_6.1.5-3.dsc to pool/main/a/am-utils/am-utils_6.1.5-3.dsc am-utils_6.1.5-3_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-3_i386.deb libamu-dev_6.1.5-3_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-3_i386.deb libamu4_6.1.5-3_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arches and etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31 Oct 2006, at 3:07 am, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/06 14:43, Bill Allombert wrote: On Sat, Oct 28, 2006 at 01:04:28PM +0100, Neil McGovern wrote: [snip] Because we never had ? We have dropped support for i386, but only a fraction of i386 had a MMU and so were able to run Linux, and this change was forced upon us by the rest of the world. I'm very sure that all 386 chips had MMU. You might have been thinking of the 386SX, which did not have an FPU. However, it could easily (but *slowly*) run Linux when enable software FP was enabled in the kernel. Er, none of the 386 chips had an FPU. IIRC, the difference between a 386DX and a 386SX was the interface to the rest of the machine; the 386SX has interface circuitry similar to a 286, so that hardware manufacturers didn't need to design a completely new board for a 386 machine, but could adapt their existing (cheap) 286 designs instead. The 486 was the first CPU in the X86 family to have an integral FPU. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRUt0cRypeFo2odvPAQKsqwf+PTs+x9GWR8aaXOavoMn+Zvsb89tAPZ3z Myr4xdRPhNZ3R/9QIYi12T+l5vjFfzWEbJtpvrFinYa+K5HAB3G7xUm/mZYSMfEF MvJlR5COmPGyjNg/euomYteDSXdLoj06xbav9hLXB51WpT84jdQBEn0CjgRUuBV+ OUB82136en1PKHY7oJbQXdwHoEThsOdkeop94slQhR+G1BwLtCQU9FBewC1i3L6n tNJvzT6b3iuRdYckUtHTWb5fiEORK0DXVqAM1wzlUZiSX2xqJQowFvfQ4jNiMEnn JYXw9EXUzIKy81eHwh4M0ajHAZptWt39Hd8uzdXr3lklBNtuK61/qg== =740J -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.3-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Oct 2006 09:06:16 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.3-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Changes: tkcvs (8.0.3-2) unstable; urgency=low . * Updated to policy 3.7.2 Files: fa7666081c182e5979aa1454a0e699c6 858 devel optional tkcvs_8.0.3-2.dsc 4e45bed695137ba2660e506df5f25da2 5767 devel optional tkcvs_8.0.3-2.diff.gz 51b523f2a35202b9d7a0173fc73bb7e7 1044820 devel optional tkcvs_8.0.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBRSIaXBypeFo2odvPAQJJzwf7BzOF97zgB7m7G/VeIGfIRgRXScCCpiVW 8JlTxI5H7Ru7h0JZ980TAGlHPksAr6gcFy6aIH5EgBCs1lK0uZp0NUHUi2GuUHX2 /MYwguEaENdbddZyqHQ0wLjl8n0MxnBOPBzjCP1iIfMPf7F/EtVOcMlr8epdoAH4 LeH1qtMBQBWN9P2ef2RRuZ9axojRUDB3IcwzFVRUHjJb/iHWsQ96SSv2AbUdpjuj mIyKb0WhBuJAOPs/hcCtjngxxznTpyxjyAc5Gwxgt4QF93WLUfzWOZhksQ+eib+q YSjzs8hEhV57t86gZjR5tSq5GCaYAQhUQ0Tr+cJykMyW5l/zFHIX4w== =hspT -END PGP SIGNATURE- Accepted: tkcvs_8.0.3-2.diff.gz to pool/main/t/tkcvs/tkcvs_8.0.3-2.diff.gz tkcvs_8.0.3-2.dsc to pool/main/t/tkcvs/tkcvs_8.0.3-2.dsc tkcvs_8.0.3-2_all.deb to pool/main/t/tkcvs/tkcvs_8.0.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.3-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Oct 2006 09:21:57 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.3-3 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 368824 Changes: tkcvs (8.0.3-3) unstable; urgency=low . * Included desktop icon patch from Ubuntu (Closes: #368824) Files: 6896f9f97314ddfa6f8bd3537e5b9dce 858 devel optional tkcvs_8.0.3-3.dsc 0303afb06c7406dcf927462e6e4af2cc 5839 devel optional tkcvs_8.0.3-3.diff.gz 02751c00db760cb00a5b73be6cc385c1 1045510 devel optional tkcvs_8.0.3-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBRSIfGhypeFo2odvPAQLLrQf/ayMfplTh3kLgWZ1Ke9k77un0hhwX/r2F IY0QOKsfGaH4J5xGNwPcaa7/86v9AbkU2T2ZL/gt57kpnTyYGWLfkCu57lYkupwP fOZSRWSAzPx/fRkql2KuwubUXq+oBOrOjIYoDbhgKu06kQBEj/0O+SXl2s/+otJp tk71cnqBj5e0qEFe/h6n56lB7Uh/sIkxNC449znaPotYAbM9ZxuLwZksMgDvHAhT 0gRWHg8JzZ9DAx3Ai7Yn27mew4FBB6RoBLdvhGXPUhCVkF8uSMUSQ163S85BBym4 UXd5BxQRxSIZTz+l+NMVOouM4XP7DMaVXDKtfNJEXZogEQxg6qgHYQ== =3Jdj -END PGP SIGNATURE- Accepted: tkcvs_8.0.3-3.diff.gz to pool/main/t/tkcvs/tkcvs_8.0.3-3.diff.gz tkcvs_8.0.3-3.dsc to pool/main/t/tkcvs/tkcvs_8.0.3-3.dsc tkcvs_8.0.3-3_all.deb to pool/main/t/tkcvs/tkcvs_8.0.3-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Oct 2006 08:27:02 +0100 Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all i386 Version: 6.1.5-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 376057 377897 388706 Changes: am-utils (6.1.5-2) unstable; urgency=low . * Re-working of packaging scripts to meet policy, and place /etc/default/am-utils under ucf control. * Added LSB INIT INFO to init script as per policy * Renamed pt_PT translation to pt (Closes: #376057) * Updated fr, pt, cs, sv, vi and ja translations. (Closes #368687, #370301, #379952, #379993, #388664, #388757, #389131, #389337, #390305 * Adjusted debconf questions according to policy (Closes: #377897, #388706) * Fixed incorrect command line when setting the cluster name in /etc/default/am-utils * Standards version 3.7.2 Files: b801c36b5cc60e54f1ac56548b8b2a5a 1055 net extra am-utils_6.1.5-2.dsc 1f4dafce281d714e3efd128de670183c 61204 net extra am-utils_6.1.5-2.diff.gz de4eb48f3a211fcc8168e1fb7fb01632 627086 doc extra am-utils-doc_6.1.5-2_all.deb 6d407377d09c9525b89386db5dec8143 373408 net extra am-utils_6.1.5-2_i386.deb a4c2ff9d08b50aa4bff1c70b85c6d2ce 163640 libs extra libamu4_6.1.5-2_i386.deb a1d059853f9d5a90b4e8e5b253edd5a9 45990 libdevel extra libamu-dev_6.1.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBRSERgRypeFo2odvPAQJ9MggAnR1HpVNZMvOyEUYAhd6iZdyughUlu03E QPcm7wB6yb1EFIqoPzVLw7RRbHLixO9FWsG1IbF03586lnpRFueqF4mhm3gDe89i FEV3lqvqRfVRk+gy2+Jp2mUBhkI4Ip+pZfZ5+UlUoSYAPCBAFhp/REBwE6AYzqqV 3aHKHj/NPcjJcwivYepCiTHK6BvBl5qgz7IeV65ihyiKOAqFnfEX5HPNEe3ULxe3 Cpbiw60AWbpyyKsYSxBOyfReWKV1mhzsaN3RCT3/+yqVdxOf2S+zjsPfGtN5hEit ASyaAcrHdgWaJfENjCezlLuYnqT86N2fKKjAMqIqurMPvUblgxfmqQ== =oe36 -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.5-2_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.5-2_all.deb am-utils_6.1.5-2.diff.gz to pool/main/a/am-utils/am-utils_6.1.5-2.diff.gz am-utils_6.1.5-2.dsc to pool/main/a/am-utils/am-utils_6.1.5-2.dsc am-utils_6.1.5-2_i386.deb to pool/main/a/am-utils/am-utils_6.1.5-2_i386.deb libamu-dev_6.1.5-2_i386.deb to pool/main/a/am-utils/libamu-dev_6.1.5-2_i386.deb libamu4_6.1.5-2_i386.deb to pool/main/a/am-utils/libamu4_6.1.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deploying configuration as packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30 Aug 2006, at 7:23 pm, Josselin Mouette wrote: First question to the developers, what are you using for deploying configuration on your servers? cfengine. Currently being used to manage configuration files on about 1,500 machines here (mostly Debian, but some Red Hat and SuSE as well -- that's one of the benefits of using cfengine, that it will work on just about any Unix-like system, so it's particularly useful at sites which aren't completely homogeneous). Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRPb/phypeFo2odvPAQKcLgf+Mg7ldCrHFhRf+4g1MetWrwj4V7Jo3xlU Nc0wKkNA4tA2RG8bCMOx0hNyOisyy5ztCCWM9JHbvGBg2j0KPvxOLrd1kGxceHHc pMxa8BERq/evX06/PHhVT+KM1KEdKxqxJSXzQSo5rvKwovjpvMRm5UoonQzxAXxE NJt5u1EKOPiGvJviTi8peLYfjtRDk3fAvhLoZaIwEcSg7m5muBBCoPj8ebacP1ll kCmIi/1r41lekoHFbqAzFxBaglz+lNm/dLqOJoUkSewXNOe5ABoqgN+IyP1NX2np qres7WjtBWJGxFYRGE2h0Zhl3pJ+UkXChGvyYE14iV60mulgLkzf6Q== =AcDb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8 Aug 2006, at 10:48 pm, martin f krafft wrote: also sprach Michael S. Peek [EMAIL PROTECTED] [2006.08.08.2239 +0100]: The next time there's an upgrade for courier-authdaemon, won't it overwrite my version of /etc/courier/authdaemonrc with it's own? No way. Packages must *never* overwrite your files in /etc. Is this kind of thing addressed in the Debian Policy Manual (and I just missed it)? Well, yes. Section 10.7. PS: I suggest you look into cfengine2 or parrot, these are designed to do configuration file changes in an organised fashion. They have steep learning curves but they're powerful. Doing this with packages (c.f. dpsyco) is painful, IME. I second the cfengine2 recommendation. We're managing configuration of around 1000 Debian machines here with it (700 or so IBM blades, 300 or so desktops, and a handful of other more exotic machines, some of which are not using Debian), and for the most part it works like a charm, although it does cause some problems when updating packages, because of course the cfengine-distributed conffile has a different md5sum which will cause dpkg to wibble. However, since we're managing conffiles with cfengine2, we just tell dpkg to always keep the existing config file, and that's OK, although it does mean we occasionally have to manually look at .dpkg-new files in case there's some new option we need to add. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRNndqBypeFo2odvPAQItrAf/Qx4kdd3KMlECpmlZcDMhEFedHi20GBCe 2Z94gjTS5k17NBEMNPhHDs4bvSwz5wpj5/NJ+wuEkAZO8WMz2ZD+EJYimKJYIcMA T0EREjWrtWDBFVLK/TRjt3VNkHBmvJKJHSTdihAVwpPRLGb6z50PucLzpPrUwr1C cXjUvsgcEMDZQCcj9j4xNRPgUseqZsomvw6TIrmUByOkl/OCVOpKaTcHRbea+/Y9 Bn+Q4BzxE2N7zf0Kbw3tL1qqeEetklu7gFojAYLcAXr3p9px9bx4AeTkLbTLK9x8 9Famx1nAGgligiLYLXA/qYrdxNhYMB8Su40snzVCGRxP4g6XAADNAQ== =uEMy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 May 2006, at 10:46 pm, Roberto C. Sanchez wrote: I found this more instructive: $ apt-cache search -n .\*-dev\$ | sed 's/ -.*//' | xargs apt-cache show | grep \^Section: | sort | uniq -c 1 Section: admin 1 Section: comm 3 Section: contrib/libdevel 256 Section: devel 5 Section: doc 1 Section: electronics 1 Section: games 3 Section: gnome 3 Section: graphics 6 Section: interpreters 3 Section: kde 1379 Section: libdevel ... etc In other words, on a Sarge system (with backports), over 93% of the packages (the total is 1757) report themselves as being in devel or libdevel. On the whole, I would say that is pretty good. Playing devil's advocate for a moment: I would have said there is sometimes an argument for a development package not being in devel, but rather being in the same section as its 'parent' program; one could think of devel and libdevel as being for general purpose programming tools and libraries. There could be examples where the development files are only really relevant in some extremely specialised context (for example some scientific application or other) and cluttering up the devel and libdevel sections with them just adds noise to those sections. I'm not saying I actually agree with this, but I can see an argument for it. A case in point might be libamu4-dev, a package for which I am the maintainer. This contains development files for libamu4, the core libraries of the BSD automounter. It is in libdevel, as you'd expect. I find it hard to believe that anyone actually uses these (I don't have any practical need for them, and I'm the package maintainer!) - they're there in case people want to, but I suspect it's a package needed or wanted by a vanishingly small number of people, and it certainly doesn't count as a general purpose programming library. Does it really need to be staring people in the face in the libdevel section? Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRGxoBhypeFo2odvPAQIhpgf/XdDs0nRNAKrPOXpGTxSfRtqLsXzIQwPV bZPfNoeW0JcURqngfmmkb2Kv0ClEovsQ8qjEupzhYx6avX09iTmIKHvXQgZ7bckk Ve3wOgYZEHMpZOhmXyRe5SKNGXXoZqEZ8Wd4/Nl+twQlkrRXedPPO7NYXKkRgpVY T75+3PE5wrXgLafAuTGIIYthPiP4iLE8fwXBVP1qhG+jndvWoIbXe5wpQgsO5AmT 6ENlmFt7NULZsOJYlM4sP0YQHZR6lureP7dj0QNvp7dLdii9WBSH3byMsVAQAGbv j85D8Tf/SIfO4atmq1Eb4tpbPzOucvsuJM4VBFdzLNPWPu/eiNNGpQ== =FrSj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On 15 May 2006, at 1:13 pm, Henning Makholm wrote: Scripsit Russ Allbery [EMAIL PROTECTED] More generally, Perl modules to send mail rather than using /usr/sbin/sendmail are often useful with web applications (or other applications that need security isolation) that are running in a chroot. To use /usr/sbin/sendmail in the chroot requires setting up a chroot maildrop, and while there are packages to do this, using some module that can speak SMTP is often the path of least resistance. Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. I've done that on some systems. Works quite well. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 14 May 2006 11:06:19 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.3-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 359222 Changes: tkcvs (8.0.3-1) unstable; urgency=low . * New upstream release, fixes some problems with SVN repositories (Closes: #359222) Files: 70b2e7c030c1bd0919ad163f8e8ca41b 858 devel optional tkcvs_8.0.3-1.dsc e0d97a278252b59f1a9b37aff6651beb 1130771 devel optional tkcvs_8.0.3.orig.tar.gz 00ed0bca6ead561fbaf97ae3596bed2b 5298 devel optional tkcvs_8.0.3-1.diff.gz 6fc1e412d24b4bcf801f8ac3ff68cfd0 1044758 devel optional tkcvs_8.0.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBRGcFChypeFo2odvPAQLyXAf9HsP7wytQYFshsAAoISjEvU9wfLZMV2mx DoQ/jtnR8jdUCkuea0v6voFSTpVkWpwRWyOpAyZFJ9k3ySWLPc2JSO1OEbkL2/BR aKePyGgXEULcigyqFNu5INq7bvqAUYH2GIxyvUtj2vfh+6OdektL6iVZ7MqQ3OBo qvogNAHmzcyfYpLBq0zpG7f9Ob2cMJx66EaOmgSxhpvHCvdWIX8/PUCx3aVw0XwQ wjVfY8dy4OhJChhRL6sZ1LmSqkncdlBNrxABHzZjsd2zJLPPxfF6W8chMyRE/Lw2 Jliiwt1TrT6+1nhLTVsaW9VI8gh3TVsfpSfQYxtrqsbX5siksJTc9w== =Yf68 -END PGP SIGNATURE- Accepted: tkcvs_8.0.3-1.diff.gz to pool/main/t/tkcvs/tkcvs_8.0.3-1.diff.gz tkcvs_8.0.3-1.dsc to pool/main/t/tkcvs/tkcvs_8.0.3-1.dsc tkcvs_8.0.3-1_all.deb to pool/main/t/tkcvs/tkcvs_8.0.3-1_all.deb tkcvs_8.0.3.orig.tar.gz to pool/main/t/tkcvs/tkcvs_8.0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.5-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 12 May 2006 17:16:46 +0100
Source: am-utils
Binary: am-utils libamu-dev libamu4 am-utils-doc
Architecture: source all i386
Version: 6.1.5-1
Distribution: unstable
Urgency: low
Maintainer: Tim Cutts [EMAIL PROTECTED]
Changed-By: Tim Cutts [EMAIL PROTECTED]
Description:
am-utils - automounter utilities from 4.4BSD (includes amd)
am-utils-doc - automounter utilities documentation
libamu-dev - Support library for amd the 4.4BSD automounter (development)
libamu4- Support library for amd the 4.4BSD automounter (runtime)
Changes:
am-utils (6.1.5-1) unstable; urgency=low
.
* New upstream release
* Modified rules and control to support cross-compiling and generally
follow recommendations set out in the autotools-dev package
* Added AM_UTILS_CLUSTERNAME so that ${cluster} is under debconf control
Files:
5ed3d73aeee4615c5de81c1d3dd9079a 1055 net extra am-utils_6.1.5-1.dsc
bc07514f4316511ace5087b9e6dc3771 1922684 net extra am-utils_6.1.5.orig.tar.gz
d5da3ea96eac77a934c830f26f59306c 59223 net extra am-utils_6.1.5-1.diff.gz
7755c6e165f646130736f3da904a5b11 603060 doc extra am-utils-doc_6.1.5-1_all.deb
867ef891ceb7ebbebd64ad2220b30664 378566 net extra am-utils_6.1.5-1_i386.deb
d8ece5a3dd8cc9595ee26e3d1c16bcaa 162206 libs extra libamu4_6.1.5-1_i386.deb
0658c3497ae17fb981e34832009b211d 45288 libdevel extra
libamu-dev_6.1.5-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBRGhFQhypeFo2odvPAQJrTwf9HyVEifPIexIlVjN+T5lx4WJ/7nerJGS1
Eba4lU4DIq2SgDomKAhUrwBF9FkAoRDSSONnUGtCwH8y3Ju9WA9ARyKSTK4QJkjf
L+crHaPdI3crG5x7Ygn3OlczagUHnIQ7XrcBhCjR0arZ9hBsO8voT5JlHG16l7ZA
oyMWLnr7Y3tMeNNopnVRNx4s1yquPUbF5Tu6WRhCcKg7mY7PnetA4AsdCpeKcy/R
8NGvju91KraGBqNBvWAFTxe2c5nrN/2B1TTEZRm2DxTgr7jr86yqGfukJmQfQJnn
dQmPrWsVMTINec+0lzSDkBy4w7ol+VcoTm86pywbBCe+BbcSWvrQug==
=hfIO
-END PGP SIGNATURE-
Accepted:
am-utils-doc_6.1.5-1_all.deb
to pool/main/a/am-utils/am-utils-doc_6.1.5-1_all.deb
am-utils_6.1.5-1.diff.gz
to pool/main/a/am-utils/am-utils_6.1.5-1.diff.gz
am-utils_6.1.5-1.dsc
to pool/main/a/am-utils/am-utils_6.1.5-1.dsc
am-utils_6.1.5-1_i386.deb
to pool/main/a/am-utils/am-utils_6.1.5-1_i386.deb
am-utils_6.1.5.orig.tar.gz
to pool/main/a/am-utils/am-utils_6.1.5.orig.tar.gz
libamu-dev_6.1.5-1_i386.deb
to pool/main/a/am-utils/libamu-dev_6.1.5-1_i386.deb
libamu4_6.1.5-1_i386.deb
to pool/main/a/am-utils/libamu4_6.1.5-1_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 8.0.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 7 Feb 2006 13:49:20 + Source: tkcvs Binary: tkcvs Architecture: source all Version: 8.0.1-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS and Subversion Closes: 349866 Changes: tkcvs (8.0.1-1) unstable; urgency=low . * New upstream release (Closes: #349866) * Updated to DH_COMPAT=4 Files: 543c8eb694f4214a9fd86af632617409 794 devel optional tkcvs_8.0.1-1.dsc 65b3fd2c53cfc890843fcdcca8a115c6 1145633 devel optional tkcvs_8.0.1-1.tar.gz a3a76e28cb65cfbab471f0a02a3bfedb 1055776 devel optional tkcvs_8.0.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ+ilshypeFo2odvPAQJGDQf/YOeoKs5r8wWl9dT0U6SFqWhRv9a72l1D zW8NCc/AS/6Mu/ePA34leJrxhECJ7uy0ApX/mM012CLErXSoQfdxdiuw8oO9d/m8 pD8JSVh+95G7V2zG3gPiCsRB8wVA/6cbUrCCHsXBsrsdxn/sll3jzKCFkucPCmxJ kXQmtKBDFrVmJWQkOn6lke5CssxmhDSVTrXYSHyZIep8/3epCagcKDVp1TPBfaEe PM4Pi/DWVymwU9d0kI+WIntG1SrgUZa1we298HEdElQROEBqxDvU16W7GglJVa8x 1nlcgXyAlSnJTha5VE2XI6bompxji2giqIxaNKtlNHK2SjefPVZoJg== =Dq+m -END PGP SIGNATURE- Accepted: tkcvs_8.0.1-1.dsc to pool/main/t/tkcvs/tkcvs_8.0.1-1.dsc tkcvs_8.0.1-1.tar.gz to pool/main/t/tkcvs/tkcvs_8.0.1-1.tar.gz tkcvs_8.0.1-1_all.deb to pool/main/t/tkcvs/tkcvs_8.0.1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22 Dec 2005, at 11:15 am, Peter Samuelson wrote: [Miquel van Smoorenburg] I tested this and it works fine. It's also a better solution, since several packages contain directories in /var/run and ofcourse they expect them to still exist after a reboot. That's a bug, IMO - they should mkdir -p in their init scripts if necessary. It's not like that's hard to do. Mailman is one such package (/var/lock in its case, but the assumption is the same). When I suggested making that change to Tollef, he wasn't very receptive. In my case I was mounting /var/run and /var/lock as tmpfs filesystems all the time to reduce hard disk access on a machine that was running all the time. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iQEVAwUBQ9cuXhypeFo2odvPAQKYFAf/YDufmFMXx4747K5ovHKKcgW7iGOVgsso O5uys08TQ9OWJbvlskEgBW3+A5j5sSgO4tiTi8mki5w+iIj1pMzKY2aVbgA2i3I3 f4jZJG+Sc+AOf2WSGizIl7P7KWbuhOLoRFyXc5cx8Z3i9IOjcd3d3s69GB1P4J1P ZOl73D8aq2dQZrUl3SSgkGx/6xFiRq7coOhSPg3x111Pz20yx0h43Qm3aNh2sGgv LKLmT8EU787LS9RGgnYQ5I0VWdu/IorytoWkZHabJhYUQSDaV1FAs08EuNGNajdA s+g9SFP5RsHwcgNIMQZ+5LPunpHHs1YByGZ1KWWT018MRLrzi+PkMg== =bv/R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.3-2 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 Jan 2006 12:24:32 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all powerpc Version: 6.1.3-2 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 344229 Changes: am-utils (6.1.3-2) unstable; urgency=low . * Moved a stray manpage from /usr/man to /usr/share/man. Closes: #344229 (by Nathanael Nerode), a release critical bug. Patch from Lars Wirzenius. * Fixed init script not to barf if NIS not set up on machines with FQDN. Files: 382f2e8fcfa8e8e723e40ef778f8f08c 1010 net extra am-utils_6.1.3-2.dsc 04601cb9940db7deac09eeaaf7a55e9e 55830 net extra am-utils_6.1.3-2.diff.gz e0be8cd96b6e273a35562464cecfc3ea 594436 doc extra am-utils-doc_6.1.3-2_all.deb e514231030577f24817280c6824b953f 395310 net extra am-utils_6.1.3-2_powerpc.deb 564e0567128d412ad272bfdde8de2b12 161824 libs extra libamu4_6.1.3-2_powerpc.deb c4ac8f9667be9cc2c4fe889a91f96256 49442 libdevel extra libamu-dev_6.1.3-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ70d2hypeFo2odvPAQI68ggAhZtRZIwhWrD2GBwmhHdeNqgFrTIciPoP YUis92iD4pqkCkY5RSLhRwP7iczdZR0Ca+WC6dYLvbE5PTssXk6O5AUQxcnwEYkS 7Kf1CeD5D6LUAiytbyvUG+fRjr94pewOI0etNT4lOV9wk4nnKBT2v6eEI887pi1m ySRDny48sehOzy3OhVViy3Bz/BLRLPESCMsdh5ZXksEmEtUPD2uUpsZRutk0o4Uu 89mRNCv1ZlpNbwOsq5JPY2td/iE3dhYp3OeCeh+eZea6KDrN9GGw4O9YRBOISqXp xxcMZ2EMQm9EKnz7XvYGJoUgHszRzVLrMC+Vr6gKnBVABvRpsfRPiA== =sAjT -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.3-2_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.3-2_all.deb am-utils_6.1.3-2.diff.gz to pool/main/a/am-utils/am-utils_6.1.3-2.diff.gz am-utils_6.1.3-2.dsc to pool/main/a/am-utils/am-utils_6.1.3-2.dsc am-utils_6.1.3-2_powerpc.deb to pool/main/a/am-utils/am-utils_6.1.3-2_powerpc.deb libamu-dev_6.1.3-2_powerpc.deb to pool/main/a/am-utils/libamu-dev_6.1.3-2_powerpc.deb libamu4_6.1.3-2_powerpc.deb to pool/main/a/am-utils/libamu4_6.1.3-2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338503: ITP: cvssuck -- inefficient cvs repository grabber using cvs command
On 11 Nov 2005, at 2:32 pm, Junichi Uekawa wrote: Hi, CVSsuck is a mirroring tool for CVS repositories. Unlike other tools such as CVSup or rsync, it uses cvs command to access the repository. So, it works well with remote repositories without a special server or shell account. However it is inefficient and not perfect because CVS client/server protocol is not designed for mirroring. If a server provides special way to grab a repository, you shouldn't use CVSsuck. Sounds like this is best kept out of the archive then... To me it sounded like a pretty good idea, if the server only provides anonymous pserver CVS access. I wouldn't call it a mirror though; how does it manage to fetch the complete repository including history? It doesn't do something evil like fetch the cvs log, and then fetch every single revision for every file, does it? I shudder to think what would happen if it does that and someone pointed it at the largest public CVS server I maintain (cvs.sanger.ac.uk) which has several GB of CVS repository. The Ensembl source code alone has had about 60,000 revisions made to it in its life (judging by the revision number that I ended up with when I converted it to a Subversion repository as an experiment). If it's not doing anything as complex as that, what does it give you that just using cvs checkout doesn't? Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15 Nov 2005, at 2:34 pm, Steve Langasek wrote: * The mail backlog that `will never be able to be delivered' was (as far as I can tell) all spam that chiark has been properly rejecting. No: there is nothing proper about rejecting mail from a host that you have configured to forward mail for you. I can see where you're coming from, but it's unavoidable, isn't it? Most of us probably have accounts which forward email to us, and over which we have no control; for example in my case I have two, one at debian.org, and one at Cambridge University (cantab.net), as well as any number of mailing lists. If those upstream sources are more lax about spam than the downstream SMTP receiver (whether chiark or something else) then this sort of thing is inevitable. I happen to have a chiark account, and my chiark address is the primary one I use for Debian development (see the maintainer field for any of my packages, or indeed the address from which I post to Debian mailing lists like this one) so I have some personal interest in this particular issue. It does seem it was a little hasty to have blanket-banned chiark- bound email, especially when it is well known that there are a significant number of DD's that use the machine. I specifically use chiark for things as publicly visible as my Debian package maintenance address, news and mailing list postings, precisely *because* of its somewhat draconian anti-spam measures. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iQEVAwUBQ3tHZRypeFo2odvPAQKRoggAtoiXmeOkePAFtBsP8LDpniinK9a88VEx OBrZtpk+yWmbMAX6y8Rifq2df62HDy4d2hTlBg26/bPXckhZiWhbIuJL8Ev1VxmI hggQ1knqgUyKCuiEXmuLO/ueH2wCN+mzc9coFN+Nu4cVp6QQuuYZAP4Yz8oIm3DO mFEw8N2lDRLJIbxg2RNHD71hkOtpHu9AGal1k0+GwDbLeVni4Wx4TxKXsRxD5bLV D1bruCihwtXJIhHK2CornOW9fljsOc8IipO/43Rt3tB+ks+3g89LPZQVcCu8ZbWK 7Bx2EheaWC0STqSpJRGqMTCH2oxnS0PfPFsRf/i3zMS5YX+usuzBbA== =9LTp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.3-1 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 10 Nov 2005 10:01:48 + Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all powerpc Version: 6.1.3-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 330260 331566 336341 Changes: am-utils (6.1.3-1) unstable; urgency=low . * New upstream version (Closes: #331566) * Updated sv translation (Closes: #330260) * New pt_PT translation thanks to Marco Ferra [EMAIL PROTECTED] (Closes: #336341) * Re-worked rules file to use dh_install rather than dh_movefiles Files: 9e8b7b89c806c697b3ae0bb1fb6664d5 1010 net extra am-utils_6.1.3-1.dsc 6b023c3d5270429f4ce54ee1edea4f8f 1892542 net extra am-utils_6.1.3.orig.tar.gz beb708e0d2c4b082a09d56e218d415fc 55781 net extra am-utils_6.1.3-1.diff.gz fc6400af7f6c72c7ef07dd6ac7cdf97a 594306 doc extra am-utils-doc_6.1.3-1_all.deb d74b7a1492d0ae6ac2944e6ddcde8ba1 395538 net extra am-utils_6.1.3-1_powerpc.deb 20d56d8e01e4064cd2477fd18b95fd11 161756 libs extra libamu4_6.1.3-1_powerpc.deb 0c0a2942f27813c3840843c44245403c 49422 libdevel extra libamu-dev_6.1.3-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ3OFPxypeFo2odvPAQLm5wf/d6l76RDXq7bDAxktc7MXzJiZ4+iOe4Vf 0C+ATt4lBIy/QROx+L0OyOUeCnUaFiUE4SUM+644HLuVZugmoWmwp3ylLBaWuuNd UhUTj4dPtRIFRtlsEp8BmdbkB7Yo2i2IitUeKEC7MnxCHyOem/0i028Qqp3m3LB7 rYaNDTpfgDlPiM0eHBbPo7NgKAuUrK2G/rsrrTJRMz9GhKzTAh2jD/Tl3f0S+UEc qcqSh35zLVemmpi19O6HM+newZFs2FYrAiZuzfCW0DSjQYq19fy9pyFlkUSUF4C/ 7YTY/NIN5TpjhRGhxrQ24ttoOvsw5j/t3T0AK77Wb7tc6MGGBngUZw== =ha2L -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.3-1_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.3-1_all.deb am-utils_6.1.3-1.diff.gz to pool/main/a/am-utils/am-utils_6.1.3-1.diff.gz am-utils_6.1.3-1.dsc to pool/main/a/am-utils/am-utils_6.1.3-1.dsc am-utils_6.1.3-1_powerpc.deb to pool/main/a/am-utils/am-utils_6.1.3-1_powerpc.deb am-utils_6.1.3.orig.tar.gz to pool/main/a/am-utils/am-utils_6.1.3.orig.tar.gz libamu-dev_6.1.3-1_powerpc.deb to pool/main/a/am-utils/libamu-dev_6.1.3-1_powerpc.deb libamu4_6.1.3-1_powerpc.deb to pool/main/a/am-utils/libamu4_6.1.3-1_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.1.1-1 (source all alpha)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 1 Sep 2005 15:34:06 +0100 Source: am-utils Binary: am-utils libamu-dev libamu4 am-utils-doc Architecture: source all alpha Version: 6.1.1-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu4- Support library for amd the 4.4BSD automounter (runtime) Closes: 89029 248388 276559 318521 Changes: am-utils (6.1.1-1) unstable; urgency=low . * New upstream version (Closes: #318521) * Added ldap support (Closes: #276559) * Cookbook modified to reflect the lack of extended regexps (Closes: #248388) * mtab / mounts discrepancies believed fixed upstream (Closes: #89029) * Moved libamu.la into -dev package in accordance with policy section 10.2 Files: 69a74b47d26881e7d1a2a0fe1998b5eb 1010 net extra am-utils_6.1.1-1.dsc d80262aff0f66cac815d963556526257 1871009 net extra am-utils_6.1.1.orig.tar.gz 64d06930103e2e9f571e6656553878dd 58053 net extra am-utils_6.1.1-1.diff.gz c29394b1570130c37668437823ee37f0 647904 doc extra am-utils-doc_6.1.1-1_all.deb 2ec9bd0ff9ea49e9ca2c1a76ed4188ce 415314 net extra am-utils_6.1.1-1_alpha.deb 663bc2108f021618de61522b6648cef5 158954 libs extra libamu4_6.1.1-1_alpha.deb cf5901c7006f7d07f546b0046955523c 59126 libdevel extra libamu-dev_6.1.1-1_alpha.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQyGq6BypeFo2odvPAQIFFQf+NZpgyzl5J+gu2E7NGShCgQjMA+7K1OzJ MWwkocTHxB96ItwH3e8T6Hq2ry3JI0b2S2tmAVB8WdqYDDLiF/aNbDnrqLM+H77B q0rLr/PIs2u1ZxuE9cPijGWhhysyvJGJai0gAaaLaJ1XDGJ8HKCcxwIBadUA0/fD /YyL0ypdNzFfCvofvuHNRD4VhvF7GL8sGrjOUVqlgXW/IqOPykQlOejM6nUnz8wH 0/Tb7+fHllvZ98+C5w5EpCTs4aPUjOUUjhzKfhRaw0rHeVhUh9kUjyoRdr0a5bEI P+0Kx1TxTdHiTDMDzgr14a8BwxJopooDZj25kl8ZlSbAnuMevutMvQ== =lbXg -END PGP SIGNATURE- Accepted: am-utils-doc_6.1.1-1_all.deb to pool/main/a/am-utils/am-utils-doc_6.1.1-1_all.deb am-utils_6.1.1-1.diff.gz to pool/main/a/am-utils/am-utils_6.1.1-1.diff.gz am-utils_6.1.1-1.dsc to pool/main/a/am-utils/am-utils_6.1.1-1.dsc am-utils_6.1.1-1_alpha.deb to pool/main/a/am-utils/am-utils_6.1.1-1_alpha.deb am-utils_6.1.1.orig.tar.gz to pool/main/a/am-utils/am-utils_6.1.1.orig.tar.gz libamu-dev_6.1.1-1_alpha.deb to pool/main/a/am-utils/libamu-dev_6.1.1-1_alpha.deb libamu4_6.1.1-1_alpha.deb to pool/main/a/am-utils/libamu4_6.1.1-1_alpha.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: long long support on all archs?
On 31 Aug 2005, at 9:54 am, Petter Reinholdtsen wrote: [Ondrej Sury] I am unsure if such patch would be accepted upstream, since Cyrus runs on more then Linux and *BSD variants. Does Solaris/AIX/whatever(tm) has stdint.h? I believe both SOlaris and AIX got it. It is a POSIX standard header. Check URL:http://www.opengroup.org/onlinepubs/009695399/basedefs/ stdint.h.html#tag_13_48. And the int64_t type is required if the platform support 64-bit integer types. Tru64 has it too, as does Mac OS X. I thought it was pretty much *the* portable way of doing this, these days. Where I work, use of this header has solved a lot of problems; interestingly we tend to get 32/64 bit assumptions which are the opposite way around from normal - this place has been using Alphas more or less since they came out, and a lot of [less than careful] C coders here got used to assuming long was 64-bit (which it is, on Tru64), which gave them some nasty surprises when they tried to run their code on non-Alpha boxes. :-) Tim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 7.2.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.7 Date: Tue, 30 Aug 2005 14:25:57 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 7.2.4-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS Changes: tkcvs (7.2.4-1) unstable; urgency=low . * New upstream release. * Updated to standards version 3.6.2 Files: ed39e4d3495464fbf17cac051255e197 860 devel optional tkcvs_7.2.4-1.dsc 3bd06d00e25994bad2eb3918f548b68e 1091026 devel optional tkcvs_7.2.4.orig.tar.gz c4d9cf48edcffe679d7f81ded03b4c71 4793 devel optional tkcvs_7.2.4-1.diff.gz 5c3d4a4a28d14279bda7461a8fea8f25 931780 devel optional tkcvs_7.2.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQxWEyRypeFo2odvPAQg+9Qf+JqdGeuT7YoTUfg5vL4ZNf96mr19SQ2Xi tFNf8En3z7sOrp8tVGdO/lOyx0l7phrNiwx0T3jCyUDaNAheOL2ElcrWP549F2r+ T5vLoQuTu2Fygfi36yqpgZs9QOK3cPoX5o6PrW7c7mS9LbDyZWYWEr89WHXF3E4I dsWjriHvUmrrw3b3G7DB84g8YZ6kpP09Qrgq5eVonwP+HWpk0XgcITxV/I+VTt1K PdLokBvd7XdA/Dw+ygtZA9Fa7pnuvSOrwJ07LsKKrTlGIHEQN2fZH7xxGGO01kZz pf8pPjA4OVP5rjHDpACTBX4h1vx4gLsW5+RGmqMyA279i5a2bS8NdA== =Rgit -END PGP SIGNATURE- Accepted: tkcvs_7.2.4-1.diff.gz to pool/main/t/tkcvs/tkcvs_7.2.4-1.diff.gz tkcvs_7.2.4-1.dsc to pool/main/t/tkcvs/tkcvs_7.2.4-1.dsc tkcvs_7.2.4-1_all.deb to pool/main/t/tkcvs/tkcvs_7.2.4-1_all.deb tkcvs_7.2.4.orig.tar.gz to pool/main/t/tkcvs/tkcvs_7.2.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.0.9-4 (source all alpha)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Aug 2005 13:36:11 +0100 Source: am-utils Binary: libamu2 am-utils libamu-dev am-utils-doc Architecture: source all alpha Version: 6.0.9-4 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu2- Support library for amd the 4.4BSD automounter (runtime) Closes: 205794 206440 249666 274223 276738 285095 307135 313030 313248 314133 Changes: am-utils (6.0.9-4) unstable; urgency=low . * New maintainer * Fully closes bugs fixed by prior NMUs (closes: #285095, #205794, #206440, #274223, #276738, #249666). * Added source dependency on recent texi2html * German debconf translation fixes from Jens Seidel [EMAIL PROTECTED]. (closes: #314133) * Vietnamese debconf from Clytie Siddall [EMAIL PROTECTED]. (closes: #313030) * Japanese debconf from Kenshi Muto [EMAIL PROTECTED]. (closes: #307135) * Updated Czech debconf from Miroslav Kure [EMAIL PROTECTED]. (closes: #313248) * Removed a couple of bashisms from am-utils config, postinst and postrm. * Purging no longer incorrectly deletes files in /etc/am-utils that were not created by the package. Files: 5a0ff19b17ca87727a95c151807b68ee 996 net extra am-utils_6.0.9-4.dsc e60bda0b46cb488bdba42a43919a6239 88346 net extra am-utils_6.0.9-4.diff.gz fba95ac4f1282e19b9453310f94b3712 557728 doc extra am-utils-doc_6.0.9-4_all.deb f2786d652b48aa52a2ee6355ede70a29 308338 net extra am-utils_6.0.9-4_alpha.deb d5641c4f9c3a08fd5899bb3ee68194cb 96024 libs extra libamu2_6.0.9-4_alpha.deb 38bf934d5d3fcecce7cd027fb172ea1e 53334 libdevel extra libamu-dev_6.0.9-4_alpha.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQwsehRypeFo2odvPAQKyQQgAuOY8Cv1qnc2a9i4m0MImkK74UXFTGSKX zKpz025cTFD2hE68iwzmmfP036Y3vka6P+ZYPdyIuSzmhOcC2GvV5Zs8eDJ1Ketu aPttOtGewwGvY0fDBIfFlzbZdbyFspmwOU+Ct6nNDUQh1VpRrfcHykx5sbFLi8Ul jOG7gW110xRpnDYAFs7GVCEMKPbgtmOjMpO2JWA8G7wdpR4L31em0bh0AlfBAMfO uAwWJtD/ZltwvF5sFY5Q4uksSE2GmqdHK5nk7DPOwucSvgvX1jdenARyFmRAxvfU E2eMqc8CZO/dc0dFiWhrDMV3GmKtCGPKguWHtH5OeinHHfV1A0aGpg== =QpcQ -END PGP SIGNATURE- Accepted: am-utils-doc_6.0.9-4_all.deb to pool/main/a/am-utils/am-utils-doc_6.0.9-4_all.deb am-utils_6.0.9-4.diff.gz to pool/main/a/am-utils/am-utils_6.0.9-4.diff.gz am-utils_6.0.9-4.dsc to pool/main/a/am-utils/am-utils_6.0.9-4.dsc am-utils_6.0.9-4_alpha.deb to pool/main/a/am-utils/am-utils_6.0.9-4_alpha.deb libamu-dev_6.0.9-4_alpha.deb to pool/main/a/am-utils/libamu-dev_6.0.9-4_alpha.deb libamu2_6.0.9-4_alpha.deb to pool/main/a/am-utils/libamu2_6.0.9-4_alpha.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: launchd and lookupd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2 May 2005, at 9:14 am, martin f krafft wrote: Apple has just released launchd, a init/cron/watchdog/etc. replacement. Has anyone looked at it? It seems like a bit of work to port it to Linux, but then it's also possibly a great tool which could revolutionise the sysv-rc stuff we have in Debian without us having to write dependency-rc. I've been looking at launchd a little lately, on my Mac OS X box. I wanted to run squid and dnsmasq on it, so I ended up looking into launchd a little. I like the look of what I've seen. A fast boot process (which is certainly the case for me - Mac OS X 10.4 boots much faster than 10.3 on my machines) is only part of it; the ability for users to use it to create really quite sophisticated automated tasks - such as taking some action automatically if someone deposits a file in the FTP incoming directory, for example - is really good, and simple to use. I haven't quite got its handling of boot time dependencies right; the launchd manpages aren't entirely comprehensive, it seems to me... Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iQEVAwUBQqrDlBypeFo2odvPAQLRGwf/XafgwHB1R2iPMfEmIMPcL2hvWFLne+ep o2WpMVSbepIer66L+A9a3r9fjmGUQ2Qu7PVarrVSUgOCSGrchW63MPMrx3r8L7T6 sA9VThReCuRQuI7cZjbeg+K4ApmWXTDvT7ePsIGvmqEVy+2npPButEvK1j/pBbN5 +VWrAQJxueIGIMq5eyMIUwMe1YWuQ+h8G/2K3GsDlzS1wzA6QZfQT+QWpppdMkx3 vfsuTPi6lYHsfpmSIa+l1YZ8ss54wr8XezCL6peJGBEZBC1Y8FWMSMGUM4j5yxGf bRuHQr2jpY4qk7pYQyysfPJq8zyLi1p4GqJejO5+dZ47vAWBzXIapw== =fkN+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: distributed batch processing
On 18 May 2005, at 8:18 am, Josselin Mouette wrote: Le mardi 17 mai 2005 à 23:47 -0700, Ron Chen a écrit : All of those are opensource (even the EE mode) and can be downloaded from the SGE homepage: http://gridengine.sunsource.net At first glance, this doesn't look DFSG-free. Indeed not, but it's less non-free than LSF. :-) Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159
Re: distributed batch processing
On 13 May 2005, at 2:05 pm, Paul Brossier wrote: queue *is* in woody, and is planned to go in sarge as it is. i will bump the severity of the bug i reported to serious. It must have made it back in eventually then - it got pulled at one stage because it did very nasty things to /dev/tty: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=56931archive=yes Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: distributed batch processing
On 10 May 2005, at 1:05 am, Paul Brossier wrote: Hi all, I am looking at ways to distribute batch jobs on various hosts. Essentially, i have N different command lines, and M different hosts to run them on: foo -i file1.data -p 0.1 foo -i file2.data -p 0.1 foo -i file3.data -p 0.1 ... foo -i file1.data -p 0.2 ... I had a try with 'queue' [1], but it seems rather obsolete now. I am now seeking recent alternatives. I went across a few solutions, such as DQS [2] (non-free, unmaintained), OpenPBS [3] (non-free), and distribulator [4] (looks interesting). Now i feel like i have missed something obvious. Is there a tool out there that i could use as a drop in replacement for queue? This is not the right forum for this question. However, I'll answer you anyway, since I know something about this. The two market leaders for this sort of processing are Sun GridEngine (which is free [as in beer, at least]) and Platform LSF, which is proprietary and costs $$$, but is very good at what it does. Both products can do what you are asking. Personally, I use LSF in my day job on a ~1500 CPU cluster, running a mixture of Red Hat 8.0, Debian sarge (on newer X86 boxes), Tru64 5.1B (on alphas) and SGI ProPack Linux (on our SGI Altixes), but I know SGE could run this as well. In LSF, you'd submit that set of jobs (let's say your files are named file1.data - file100.data) as something like the following: bsub -Jset1[1-100] -o 0.1.output.%I foo -i file\$LSB_JOBINDEX.data -p 0.1 bsub -Jset2[1-100] -o 0.2.output.%I foo -i file\$LSB_JOBINDEX.data -p 0.2 The standard output and standard error, as well as a job summary (CPU time and memory used, etc) would appear in output files named: 0.1.output.1 0.1.output.2 etc GridEngine would have its own methods for doing these so called job arrays. I looked at GNU queue a long time ago, and it looked (to me) as though its mode of operation was largely based on how LSF works, but when I looked at GNU queue it was pretty fundamentally broken (and it got removed from woody as a result). GridEngine is rather different in its organisation, but a lot of people swear by it. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
On 4 May 2005, at 6:39 pm, Wouter Verhelst wrote: On Wed, May 04, 2005 at 04:35:25PM +0100, Tim Cutts wrote: On 1 May 2005, at 8:53 am, Wouter Verhelst wrote: True. However, it does no harm to add the conflicts, while it does make it easier for your users. When presented with a bug in another package that completely breaks mine (rather than the entire system), usually I do add the conflicts: header. I think that's a dangerous thing to do. When the bug in the other package is fixed, the chances are that you won't know about it, and then you'll end up with two packages which conflict with each other for no reason. That's why we have versioned conflicts. Also, when adding a conflicts to another package that is buggy, it would be _extremely_ bad form to not track that other package for when the bug is fixed -- or, at least, to file or reassign a bug to that package. Good point - I'd forgotten about versioned conflicts (never having needed to use one!). It causes no harm, as long as one is careful. And isn't being careful something you should be doing anyway? Yup. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
On 1 May 2005, at 8:53 am, Wouter Verhelst wrote: On Sun, May 01, 2005 at 12:38:41AM +0200, Jeroen van Wolffelaar wrote: On Sat, Apr 30, 2005 at 06:45:26PM -0300, Otavio Salvador wrote: But you remove the package from testing doesn't mean we won't have users with it installed since it was present there so, IMHO, the Conflict is need. The bug is in the other package, packages are not required to work around other bugs in other packages, that'd be a gigantic mess of workarounds. There'll be lots of workarounds, but that doesn't necessarily equate to 'a mess'. If dash breaks using my package for whatever reason, I'm not going to add a conflict: dash (with non-fixed version or whatever), dash needs to fix it. True. However, it does no harm to add the conflicts, while it does make it easier for your users. When presented with a bug in another package that completely breaks mine (rather than the entire system), usually I do add the conflicts: header. I think that's a dangerous thing to do. When the bug in the other package is fixed, the chances are that you won't know about it, and then you'll end up with two packages which conflict with each other for no reason. In this case, that's fair enough, because they're two variants of the same thing, but I don't think this sort of thing should be done in the general case. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted am-utils 6.0.9-3.2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 26 Mar 2005 20:07:58 + Source: am-utils Binary: libamu2 am-utils libamu-dev am-utils-doc Architecture: source all i386 Version: 6.0.9-3.2 Distribution: unstable Urgency: low Maintainer: Philippe Troin [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu2- Support library for amd the 4.4BSD automounter (runtime) Closes: 205794 206440 Changes: am-utils (6.0.9-3.2) unstable; urgency=low . * Non-maintainer upload * Switched to po-debconf. (closes: #205794) * Added French debconf template translation. (closes: #206440) * Added Czech debconf template translation. * Updated Spanish debconf template translation. * All above patches from Lucas Wall Files: a2d8f8fdcc67f2ceb7a13dfdd96fc1d4 689 net extra am-utils_6.0.9-3.2.dsc a0062312f30d8d2fdf8df0d4c4068c35 81131 net extra am-utils_6.0.9-3.2.diff.gz 1372bd846d2f21bd2997ba71c3750917 470868 doc extra am-utils-doc_6.0.9-3.2_all.deb 2c8c27165f61de73e2e435c94b239666 261422 net extra am-utils_6.0.9-3.2_i386.deb b63c712cc9437db844722231004487b3 92026 libs extra libamu2_6.0.9-3.2_i386.deb ed6de6cd9248157afc3e3fd1950f32fd 42220 libdevel extra libamu-dev_6.0.9-3.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCRcgvFuL09fyB4VkRAnHvAKCOHAZu8oTwstJu8nbILqIm/6OtnQCdHpiB sVJcmQSoPQT3HZPbcwDiJkI= =iK2O -END PGP SIGNATURE- Accepted: am-utils-doc_6.0.9-3.2_all.deb to pool/main/a/am-utils/am-utils-doc_6.0.9-3.2_all.deb am-utils_6.0.9-3.2.diff.gz to pool/main/a/am-utils/am-utils_6.0.9-3.2.diff.gz am-utils_6.0.9-3.2.dsc to pool/main/a/am-utils/am-utils_6.0.9-3.2.dsc am-utils_6.0.9-3.2_i386.deb to pool/main/a/am-utils/am-utils_6.0.9-3.2_i386.deb libamu-dev_6.0.9-3.2_i386.deb to pool/main/a/am-utils/libamu-dev_6.0.9-3.2_i386.deb libamu2_6.0.9-3.2_i386.deb to pool/main/a/am-utils/libamu2_6.0.9-3.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2 Mar 2005, at 2:58 pm, Gustavo Noronha Silva wrote: [No need to CC me, I'm on the list] Em Qua, 2005-03-02 às 07:06 +0100, Michael Koch escreveu: I like the idea. I sometimes miss an easy way to say don't start X, too, although most times I do want it to run. is rm /etc/rc2.d/S99gdm not easy enough for you ? Easy enough for me in my system. It would be nice to have a standard way of telling the system to not start X on any Debian system while keeping X start up being the default without the need of messing with /etc/rc?.d/ and/or /etc/inittab. It would also make pre-seeded installs easier; we're trying to get this working at the moment at work, but there's a nasty interaction between recent 2.6 kernels, udev, and gdm, causing the X server to wedge (I understand from the person dealing with this that it's because udev hasn't been started at the point in the install that gdm tries to start). Given that the machine is still installing at this point, gdm trying to start up seems a little unnecessary, and a simple way to avoid it would help. Obviously I've given pretty much the same list of suggestions as this thread to the admin doing our Debian desktop installs. Tim - -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQEVAwUBQiXdYRypeFo2odvPAQiIoAf+N+Vzx4H4+MUnvmhAzkrqIlphYy2j4Old rNZIXg8rlVn5aLhkJxcHsR2yxjgr5NBdxTel6a1og9BQuMgbKLVe0HcKF2KcrK6I zAhRYr8twP/CHDAWjZQ9xs4J8htFNcdDiJHlJT4NEAu302SUmMWXGYRP2OMPJQey XR6CfayzkaboeOCBRTvM+Y0lWqx0LWCQpoi6wz8q1/KV46RVuW76FCnb4E2cd0xh t0WwgWE7Ejtyi7jp/+Vfuz145yNmikuvVyzi5vLFDqiaEQrVn8HZcwLd7sDR/XKL 7X6qvF/OxLKeZmSJpPCp2PevR/1WXjWdljHkJBje4vyIu3B3yUm7RA== =LMSB -END PGP SIGNATURE-
Re: Who could be able to help SW vendors to support Debian?
On 3 Feb 2005, at 5:53 pm, Eric Lavarde wrote: Hi, as I understand myself as someone aware of the support problems of software problems, I would like to point to 2 problems: 1. the Debian Kernel is a bit different from the kernel.org Kernel; example: at work we used the Apani VPN client, which did work under all kind of RedHat/SuSE kernel, but not under the Debian kernel, even though there is some compiling done at installation time (i.e. not only binary modules delivered). The RedHat kernel is considerably further diverged from kernel.org than Debian's is. This is one of the major issues I have with vendors only supporting Red Hat; Red Hat apply all sorts of patches and God knows what to their kernel. 2. as a software provider, you need to be able to reproduce the problem of your customer to solve it (at least for non-obvious problems), so that you can reproduce the problem in your environment, debug, correct and test again. (I would also imagine there could be some legal implications if you are officially supporting a certain setup, but practically aren't able to support it properly; but we want to stay out of the court ;-) ). What is the consequence? you need a limited amount of possible combinations, you need to have a stable system (in the sense: not changing every three weeks) and you would greatly appreciate to be informed of changes that might break your system before your customer actually installs the patch/update/whatever. Imagine a customer doing regularly an apt-get update upgrade in order to be sure to have the latest security fixes, and all of a sudden, your expensive software stops to work, at all of your customers, almost at once. You're out of business! Well, this sort of thing happens with Red Hat AS as well. We've been having immense problems with it lately for Oracle. Game over! Well, I'd hope you'd test the upgrade on a development machine first. :-) I agree that the continuous upgrade cycle of testing and unstable is not suitable for a support matrix for an ISV. It's one reason why Debian really needs to get Sarge out of the door - ISVs will only support stable releases, and Debian's stable releases are too few and far between. I'm exagerating a bit but that's what they want: no surprise, be able to clearly define what is supported and what not (e.g. self compiled kernel or not?!), have a chance to test before their own customers do. I understand what you're getting at, but nevertheless my example stands to show that ISV's can and do support purely on the basis of kernel and C library. Platform Computing have been working that way with LSF for years, and I haven't noticed them going out of business. In their case this is because they only link against the really fundamental system libraries: 11:41:03 [EMAIL PROTECTED]:~$ ldd /usr/local/lsf/5.1/linux2.4-glibc2.3-x86/etc/lim libpthread.so.0 = /lib/libpthread.so.0 (0x4001e000) libm.so.6 = /lib/libm.so.6 (0x4006f000) libnsl.so.1 = /lib/libnsl.so.1 (0x40092000) libdl.so.2 = /lib/libdl.so.2 (0x400a7000) libc.so.6 = /lib/libc.so.6 (0x400aa000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) and the lim daemon is the only part of LSF which is really architecture-specific, and even then it doesn't do anything really scary; it just reads stuff out of /proc. Hence the fact that their support matrix requires certain kernel versions. Regards, Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Who could be able to help SW vendors to support Debian?
On Tue, Feb 01, 2005 at 07:37:27PM +0100, Christian Perrier wrote: Would any people around have pointers which could be given to such people?? Do we already have an entry point for such technical issues as proprietary SW vendors needing technical information about the way to support Debian?? The first thing I would do is to try to convince the vendor not to get so hung up on supporting different distributions. If their product depends tightly on kernel stuff, then they should base their support matrix on kernel version, not on distribution. Point them at Platform Computing as an example of how to do it with LSF. They support Linux, and they don't give a stuff what distribution you're running. They support certain kernels, and certain C libraries, and other than that they don't care. And they're not too precise about kernel version - on X86 you can run any 2.4 or 2.6 kernel, and any 2.1, 2.2 or 2.3 glibc. They're a little pickier on other architectures (they don't support 2.6 on either Alpha or Itanium yet). Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290536: ITP: acedb -- Object-oriented genome database system
Package: wnpp Severity: wishlist Package name: acedb Version : 4.9t Upstream Author : Ed Griffiths [EMAIL PROTECTED] URL : http://www.acedb.org License : GPL, portions are LGPL Description : Object-oriented genome database system ACeDB (originally standing for A C. elegans Database) is an unusual database system originally designed for the sequencing of the genome of the nematode worm, C. elegans. It is still in production use for the annotation of genome sequence data. It can be used for other kinds of data too, especially if those data lend themselves to a tree-based representation. For example, ACeDB has been used for storing chip-test data. There are X Window System and command line interfaces to the database, and various supporting applications used for more detailed inspection of certain types of genomic data. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.8-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]
Re: New stable version after Sarge
On 4 Jan 2005, at 3:45 pm, Steve Greenland wrote: On 04-Jan-05, 07:40 (CST), Paul van der Vlis [EMAIL PROTECTED] wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Which could be seen as a problem by some; but in some ways it's probably the way to go. As far as my own use of Debian goes, almost every machine I install runs testing, and has done for years. There's a level of protection in there thanks to the rules that are in place, and I rather like the incremental improvement approach as opposed to release-based. With the trend as it is at the moment, the endpoint is that Debian will eventually stop releasing altogether (some end users probably think this has already happened!) and will essentially become an upstream, developer-oriented, steadily evolving distribution from which the likes of Ubuntu take regular snapshots for the masses to use. The downside of this is that it will essentially bar Debian systems from being formally supported by independent software vendors, since stable releases are what they depend on. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: Status of Kernel 2.4.28 packages?
On 2 Jan 2005, at 7:16 pm, Christoph Hellwig wrote: On Sun, Jan 02, 2005 at 07:37:59PM +0100, Stephan Niemz wrote: The kernel version 2.4.28 is out for almost seven weeks now. Does anybody know about the status of the corresponding Debian packages? And is there an estimation for when the kernel-patch-* packages will support the new kernel version? There's an unfinished 2.4.28 kernel-source package in the debian-kernel SVN repository. For me and several other members of the debian kernel team 2.4 packages have been a much lower priority than 2.6 packages. Given that and that sarge will release with 2.4.27 anyway I'm not sure when a 2.4.28 package will get into unstable. Any reason you're not using 2.6 kernels? There are plenty of reasons not to use 2.6 kernels. I'd love to use 2.6 for everything, but in many cases at work I can't. There are too many kernel modules from third party sources (some of which are binary -- yes I know, but sometimes we have to just live with the idiots in some commercial software and hardware companies) which just don't support 2.6 yet. Having said that, for such machines I tend not to upgrade the kernel much anyway, since the same idiotic companies usually have strict support matrices for the exact kernel version they support. 2.6 is still too new as far as most ISVs are concerned, and so Debian shouldn't lower the priority of work on 2.4 kernels too much just yet, in my opinion. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: LCC and blobs
On 11 Dec 2004, at 12:24 am, Ron Johnson wrote: On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote: Matthew Palmer [EMAIL PROTECTED] writes: On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: On Dec 09, Bruce Perens [EMAIL PROTECTED] wrote: [snip] Then we might as well remove the whole kernel from main, since most devices depend on a non-free firmware blob to operate. Why does it Most ? Maybe not most, but many, and the proportion is increasing. If we force these into contrib, then a lot of hardware will not work out of the box for people trying to install Debian. Especially wireless cards on laptops. This is likely to put people off the distribution. Firmware was given that name to distinguish it from regular software. It's more akin to the hardware than it is to regular software, in my view, and should probably be given an exception from the normal dependency on non-free software rules. Think of it this way: It's not the driver software depends on the firmware to function; it's the hardware that depends on the firmware to function. The software dependency is a side-effect. If the firmware were burned into flash ROM on the card, we wouldn't have a problem, so why is it different when it's held in volatile memory on the card? Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: LCC and blobs
On 11 Dec 2004, at 1:39 am, Brian Nelson wrote: As for whether Debian would actually distribute the firmware blobs in main, I would prefer that we do. It can be a real pain installing Debian on a system in which I have to retrieve the firmware from an external source. It's only hurting the end-user by making them jump through more hoops to install Debian, with no obvious benefit. Hear hear. However, there seems to be a strong movement to make Debian 100% free down to the last bit. Reversing this movement is another much more controversial issue. If Debian tries to be too rigid, we run a serious risk of consigning ourselves to history, because people just won't install Debian any more if it doesn't work out-of-the-box on most hardware - and the time is pretty much already here that most systems contain at least one component that loads firmware from disk every boot. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159
Re: LCC and blobs
On 11 Dec 2004, at 11:16 pm, Josselin Mouette wrote: Le samedi 11 décembre 2004 à 23:12 +, Tim Cutts a écrit : If Debian tries to be too rigid, we run a serious risk of consigning ourselves to history, because people just won't install Debian any more if it doesn't work out-of-the-box on most hardware - and the time is pretty much already here that most systems contain at least one component that loads firmware from disk every boot. Most systems ? Come on. I don't think it's the case today, but I think that it will be soon. It's the way the world is going. Furthermore, compromising our ideals just to run on more hardware is not a good idea. When there are technical solutions to run Debian on this hardware without such a compromise, this becomes completely stupid. But they are technical solutions that cause a great deal of effort for the user, and like meeting people, meeting a new distribution is very much a matter of first impressions counting. If the new user, especially a relatively non-computer-savvy one, finds that their shiny new Debian install doesn't work on their network card, they'll just try again with a different distro, or go back to Windows. I don't know what the answer is here, but I think this problem is likely to get more acute, and could seriously degrade Debian's ease of use -- which is already not something it has a fantastic reputation for -- and thereby its popularity. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: Is Debian a common carrier? Was: package rejection
On 8 Dec 2004, at 8:53 am, Thomas Bushnell BSG wrote: The discussion about common carriers is all very interesting, but irrelevant. There are many protections in American law, and common carrier status is only one. We are certainly not responsible for things which are not obscene, and the package in question is not obscene (b/c under US law a cartoon such as that cannot be legally obscene). I could be wrong, but Debian is occasionally used and distributed by people outside the USA. Making any argument in this thread with reference solely to US law is irrelevant to the problems at hand. To be honest I really don't see what the problem is here. Content which is illegal to distribute in pretty much any significant market should be kept off the first CD, and probably shouldn't be in main. That way, users and distributors in any country can distribute and/or use the basic Debian distribution without any worries. They can distribute or use other parts of the archive, including packages such as the Bible or Hot-babe, at their own discretion. I have no problems with people packaging these things, they just shouldn't be part of the base install, or present on the media required to perform a base install. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Accepted am-utils 6.0.9-3.1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 27 Nov 2004 15:08:49 + Source: am-utils Binary: libamu2 am-utils libamu-dev am-utils-doc Architecture: source all i386 Version: 6.0.9-3.1 Distribution: unstable Urgency: medium Maintainer: Philippe Troin [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: am-utils - automounter utilities from 4.4BSD (includes amd) am-utils-doc - automounter utilities documentation libamu-dev - Support library for amd the 4.4BSD automounter (development) libamu2- Support library for amd the 4.4BSD automounter (runtime) Closes: 274223 276738 Changes: am-utils (6.0.9-3.1) unstable; urgency=medium . * NMU * Changed debian/rules and added localconfig.h to override configure's decisions about what filesystems to support so that it no longer depends on the configuration of the build host kernel (Closes: #274223, #276738.) * Added missing Section to control * Updated to policy 3.6.1 Files: 314eb97df28b95fb9f1b75cbd832efce 689 net extra am-utils_6.0.9-3.1.dsc 8a2867ca1ff0036c84402388a8ab0e23 72661 net extra am-utils_6.0.9-3.1.diff.gz 3aa280ea4125d382c8e800e97976f61a 470864 doc extra am-utils-doc_6.0.9-3.1_all.deb bd03b163098663ed4f6c189806fd0529 259626 net extra am-utils_6.0.9-3.1_i386.deb d13060a0d2cd89352e8166d4f2a7aa58 91936 libs extra libamu2_6.0.9-3.1_i386.deb dfdfa39a7f8f9cd3f15318ca45243b43 42240 libdevel extra libamu-dev_6.0.9-3.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrlQYFuL09fyB4VkRAp83AJ0coleLpz+rzEwpyzeUq+znQgXo9QCdGK+2 ssQEN2Oo8BMHngxsEBkIAV8= =nu57 -END PGP SIGNATURE- Accepted: am-utils-doc_6.0.9-3.1_all.deb to pool/main/a/am-utils/am-utils-doc_6.0.9-3.1_all.deb am-utils_6.0.9-3.1.diff.gz to pool/main/a/am-utils/am-utils_6.0.9-3.1.diff.gz am-utils_6.0.9-3.1.dsc to pool/main/a/am-utils/am-utils_6.0.9-3.1.dsc am-utils_6.0.9-3.1_i386.deb to pool/main/a/am-utils/am-utils_6.0.9-3.1_i386.deb libamu-dev_6.0.9-3.1_i386.deb to pool/main/a/am-utils/libamu-dev_6.0.9-3.1_i386.deb libamu2_6.0.9-3.1_i386.deb to pool/main/a/am-utils/libamu2_6.0.9-3.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 7.2.2-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 25 Nov 2004 21:13:39 + Source: tkcvs Binary: tkcvs Architecture: source all Version: 7.2.2-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS Closes: 282193 Changes: tkcvs (7.2.2-1) unstable; urgency=low . * New upstream release. Closes: #282193 Files: 918fed7095b3c6381390e818843905c6 566 devel optional tkcvs_7.2.2-1.dsc 8cf12b4e30209228eb8050ac6ee2da80 1083922 devel optional tkcvs_7.2.2.orig.tar.gz 93fbf0922814a3894967b621db81f2d5 4771 devel optional tkcvs_7.2.2-1.diff.gz 08331989b238d81b0715fe5af9836076 931482 devel optional tkcvs_7.2.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBplDeFuL09fyB4VkRAmL+AJ9uWfL4Xxwpb4+zMjT3XLb7KPPo7QCgi7gK nMlFOpgZHRTG3cAEMtw6DLQ= =xviY -END PGP SIGNATURE- Accepted: tkcvs_7.2.2-1.diff.gz to pool/main/t/tkcvs/tkcvs_7.2.2-1.diff.gz tkcvs_7.2.2-1.dsc to pool/main/t/tkcvs/tkcvs_7.2.2-1.dsc tkcvs_7.2.2-1_all.deb to pool/main/t/tkcvs/tkcvs_7.2.2-1_all.deb tkcvs_7.2.2.orig.tar.gz to pool/main/t/tkcvs/tkcvs_7.2.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkcvs 7.2.1-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 13 Jul 2004 20:40:12 +0100 Source: tkcvs Binary: tkcvs Architecture: source all Version: 7.2.1-1 Distribution: unstable Urgency: low Maintainer: Tim Cutts [EMAIL PROTECTED] Changed-By: Tim Cutts [EMAIL PROTECTED] Description: tkcvs - A graphical front-end to CVS Closes: 152060 Changes: tkcvs (7.2.1-1) unstable; urgency=low . * New maintainer * New upstream release * Added alternative xterm dependency for x-terminal-emulator, in accordance with policy * Changed deprecated use of dh_installmanpages to dh_installman * Removed conffiles file, now that debhelper treats /etc files as conffiles anyway * /etc/tkcvs/tkcvs_def.tcl sets a default date format. Not setting it in .tkcvs is not a problem. Closes: #152060. Files: 7528f5cb254d6556283e4a77a1affdf0 566 devel optional tkcvs_7.2.1-1.dsc a552cdccd7cde73eaa8a41294f499cfc 1083178 devel optional tkcvs_7.2.1.orig.tar.gz 224579a34bf5645ab615dc81c335150b 4767 devel optional tkcvs_7.2.1-1.diff.gz ca910d97eaab40a4b40c3068b3b396a2 931154 devel optional tkcvs_7.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9UJmFuL09fyB4VkRAtsfAKCo0/tkQd6PPQQwcvFtBaxpNHlcBACfRJ/5 xVQYf/TXE15+N5OLIhRYo9c= =dZ7W -END PGP SIGNATURE- Accepted: tkcvs_7.2.1-1.diff.gz to pool/main/t/tkcvs/tkcvs_7.2.1-1.diff.gz tkcvs_7.2.1-1.dsc to pool/main/t/tkcvs/tkcvs_7.2.1-1.dsc tkcvs_7.2.1-1_all.deb to pool/main/t/tkcvs/tkcvs_7.2.1-1_all.deb tkcvs_7.2.1.orig.tar.gz to pool/main/t/tkcvs/tkcvs_7.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm: Exim + Chos standard?
On 16 Jun 1997, Kai Henningsen wrote: I meant the possibility for a customer to request the ISP exim to reject any mail that comes from, say, savetrees.com. You know, what AOL does, except I want individual customers to be able to configure individual lists. I don't think that is possible with exim. There are no facilities for individual users to modify which messages are rejected at the SMTP conversation level. They can of course set up exim filters in their .forward files to junk anything they don't want, but that of course isn't rejecting the mail, technically. Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On 16 Jun 1997, Miquel van Smoorenburg wrote: Ofcourse there also needs to be a file (LocalIP with sendmail) to define IP ranges that may use your SMTP host as a relay - for customers that use your host as smarthost (Eudora, pegasus, netscape, sendmail null clients etc). Well, exim certainly has the capability to allow relaying from/to certain IP ranges. Our major mail server for example has: sender_net_accept_relay = 131.111.0.0/255.255.0.0 So that Eudora users within the 131.111 domain can use us as a smarthost. I tell people that if they want to send mail from outside that domain they will need to log into the machine using telnet/rlogin/ssh and use an MUA on the machine itself, or arrange with a more local system to act as a smarthost while they're not in Cambridge. Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
On 15 Jun 1997, Rob Browning wrote: Alexander Koch [EMAIL PROTECTED] writes: (I'd vote for exim if uucp is guaranteed to work) Ok, so what are the arguments for exim over qmail (at least why do you prefer it?) I've heard arguments for qmail and exim over sendmail. qmail is supposed to be more secure. Theoretically, exim's design allegedly means there might be some security issues, but none have been found yet. There has been argument about this ad nauseam on the exim-users mailing list. My own feeling is that the primary disadvantage with qmail is that Dan decided that sendmail was awful (with some justification) and proceeded to change a lot of things whether they needed it or not. I am, for example, irritated that qmail's forwarding file is called .qmail. What was the point of that? Does changing the name from .forward to .qmail really improve security? The bottom result of changes like this is that qmail is not a drop-in replacement for sendmail or smail. Exim is; it has a sophisticated .forward syntax of its own, but it does understand pretty well any .forward for smail or sendmail. qmail does not understand anything but the most simple cases. This means that if you have a lot of users on your machine (probably not the case for most debian sites, but it's an issue as far as I'm concerned) you will have to re-educate them as to the new ways of qmail (once you'v re-educated yourself as well, of course). To be quite honest, my 1,300 users have taken a long time gwtting used to how the standard UNIX mail system works, and they don't want to waste time learning a new one. For a single user system of course this is not a problem. Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On 14 Jun 1997, John Goerzen wrote: Christoph Lameter [EMAIL PROTECTED] writes: It might be good if we would replace smail in hamm with exim. Exim should be the standard mailer for hamm: Exim doesn't provide UUCP capabilities *at all*, thus it is rather useless for sites that use UUCP (like me). Right now, I am using sendmail. (What, BTW, is the reason for not using sendmail?) Well, for one thing exim (and smail) are a hell of a lot easier to configure than sendmail. That was what originally moved me towards exim at work - I really didn't want to muck about fixing numerous broken sendmail setups when in far less time I could just switch all the machines over to exim with a more capable configuration that actually worked properly. :-) This of course has nothing to do with Linux per se; these were all SGI boxes, but it's why I initially got interested in exim. I then made the debian package since I wanted the same MTA on all the systems I administer. I am pleased to see that exim is gaining some popularity. I shall expend some effort over the next few days in correcting some of the outstanding bugs in the package; I have been rather busy of late fighting with Silicon Graphics over broken hardware... Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On Sun, 15 Jun 1997, Christian Hudon wrote: To make this clearer, the only thing that would happen it that exim would be marked with priority 'important' and smail with priority 'extra'.. And yes, I think it'd be a good idea, assuming that exim's .forward syntax is backward-compatible with sendmail/smail's syntax. Which indeed it is. Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
