Re: Building Debian from Sources
Mustafa KYR wrote: Hello, I am a new engineer and I was just a debian user in my former life. I want to build debian linux from sources to understand it all. I spent lots of time during search about it. I'm not sure how much building from source will help your understanding, but anyway, http://oldpeople.debian.org/~jgoerzen/dfs/ is probably the thing closest to your request. Thiemo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted istanbul 0.2.2-4.1 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 31 Oct 2008 11:49:01 +0100 Source: istanbul Binary: istanbul Architecture: source powerpc Version: 0.2.2-4.1 Distribution: unstable Urgency: low Maintainer: Luca Bruno [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: istanbul - Desktop session recorder producing Ogg Theora video Closes: 500418 Changes: istanbul (0.2.2-4.1) unstable; urgency=low . * Non-maintainer upload. * Re-enable builds for any architecture. (Closes: #500418) Checksums-Sha1: 07af967c4b50d2a39389b988c2dced3cdba5e9e0 1532 istanbul_0.2.2-4.1.dsc 09ae7869c180de5530eb2c8fad14e6077fe39a6d 7972 istanbul_0.2.2-4.1.diff.gz 5447733cf9ac564f01646472960d280fe977d122 78504 istanbul_0.2.2-4.1_powerpc.deb Checksums-Sha256: 9e2d7b22b40cf20cd2713c889dbf04a41f2fc35b1d3bc6004c34d43c852dc469 1532 istanbul_0.2.2-4.1.dsc d243f24460faefc88d5823acc93d4e5a922ae4969c724df70e8a01083c73ecf5 7972 istanbul_0.2.2-4.1.diff.gz d43a8fab3a368d083f06ceca86672ec2079e8ba6e5d5e3500b1f712899b8d26e 78504 istanbul_0.2.2-4.1_powerpc.deb Files: 72be879a4ae8fb1597f7ff50519cc363 1532 gnome extra istanbul_0.2.2-4.1.dsc f858f94d360eecff79595b11872f9ce2 7972 gnome extra istanbul_0.2.2-4.1.diff.gz 03790d39cb2abbcb1521f2b23403a588 78504 gnome extra istanbul_0.2.2-4.1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkK5tgACgkQXNuq0tFCNaBXhQCguQeNb4vPGBQ/Ve8BMJ6n+jFG A0UAnAtQNYF0drG3jTEC1TY3/y4wMIii =wqX3 -END PGP SIGNATURE- Accepted: istanbul_0.2.2-4.1.diff.gz to pool/main/i/istanbul/istanbul_0.2.2-4.1.diff.gz istanbul_0.2.2-4.1.dsc to pool/main/i/istanbul/istanbul_0.2.2-4.1.dsc istanbul_0.2.2-4.1_powerpc.deb to pool/main/i/istanbul/istanbul_0.2.2-4.1_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbcl 1:1.0.18.0-2 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 25 Oct 2008 01:06:48 +0100 Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.18.0-2 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Closes: 503255 Changes: sbcl (1:1.0.18.0-2) unstable; urgency=low . * Fix cffi NULL pointer dereferencing. (Closes: #503255) Checksums-Sha1: 84383a8821dcb05614937ca53a6b25abc387f203 1281 sbcl_1.0.18.0-2.dsc 1e5334937cc275c5ea064d6204ba3b391c33c579 44675 sbcl_1.0.18.0-2.diff.gz 3450fc88e8df341b6dfda85216393312ec055159 1044780 sbcl-doc_1.0.18.0-2_all.deb 2df73e4890c22ced83c1e163cb936cda76f43ae8 3371106 sbcl-source_1.0.18.0-2_all.deb 40f1dee7c5430a5c9d6b63b52f552a90a26d9b6e 9652392 sbcl_1.0.18.0-2_mips.deb Checksums-Sha256: f2d7041d575a70ffabf5759fefbac5d9b484e8a358a155345fd77ceb18a5fc88 1281 sbcl_1.0.18.0-2.dsc 7ada0c89519cca7e15835399e001f5b15c1c02e1d4eb3a2f1f178937cfdbe6c1 44675 sbcl_1.0.18.0-2.diff.gz cc4151a1e8befb3127974707bf50843776a37e90295db9aba4614e8fccaa48e2 1044780 sbcl-doc_1.0.18.0-2_all.deb 00f3938e367fb08898d6270db3a839777bf87a2ff4e85d0a1de0a1c6b55bdea3 3371106 sbcl-source_1.0.18.0-2_all.deb eda225073fb3b768a1bfc94b42c8bf5b934f3475b134469cb849e358388dd194 9652392 sbcl_1.0.18.0-2_mips.deb Files: a412b4abb64a36b2893a3b90fc96a162 1281 devel optional sbcl_1.0.18.0-2.dsc beab037d8916f188828fa75964142e0c 44675 devel optional sbcl_1.0.18.0-2.diff.gz f48a783caa83ffd4510af7950560352b 1044780 doc optional sbcl-doc_1.0.18.0-2_all.deb f86d3dbc91640b296cb9dc428f563e9a 3371106 doc optional sbcl-source_1.0.18.0-2_all.deb 8d064074ba653276632477f98f29b4cc 9652392 devel optional sbcl_1.0.18.0-2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkDjx8ACgkQXNuq0tFCNaAyNACeL3iYipG1p0sCPNsC509hgd4A kIIAnAhrSAEV9qXO8uYqVy/qe4H2XHjq =Sw7C -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.18.0-2_all.deb to pool/main/s/sbcl/sbcl-doc_1.0.18.0-2_all.deb sbcl-source_1.0.18.0-2_all.deb to pool/main/s/sbcl/sbcl-source_1.0.18.0-2_all.deb sbcl_1.0.18.0-2.diff.gz to pool/main/s/sbcl/sbcl_1.0.18.0-2.diff.gz sbcl_1.0.18.0-2.dsc to pool/main/s/sbcl/sbcl_1.0.18.0-2.dsc sbcl_1.0.18.0-2_mips.deb to pool/main/s/sbcl/sbcl_1.0.18.0-2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lcdproc 0.5.2-1.2 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 02 Oct 2008 09:06:08 +0200 Source: lcdproc Binary: lcdproc Architecture: source powerpc Version: 0.5.2-1.2 Distribution: unstable Urgency: low Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: lcdproc- LCD display driver daemon and clients Closes: 416261 Changes: lcdproc (0.5.2-1.2) unstable; urgency=low . * Non-maintainer upload. * Support all architectures except s390. * Add support for kfreebsd, thanks Cyril Brulebois. (Closes: #416261) Checksums-Sha1: 162ec9f603a1f30d36fd09174c321b7bd0047747 1190 lcdproc_0.5.2-1.2.dsc 0b8956b07d1afe1040593a587d13a6a77dae7381 13334 lcdproc_0.5.2-1.2.diff.gz c39292b04d41839ec26514d706e9ba08d585fa53 381182 lcdproc_0.5.2-1.2_powerpc.deb Checksums-Sha256: cdf973ea36dae72f8cc0266f709b41401d01d97e7861901f77c4d8f4c61938e3 1190 lcdproc_0.5.2-1.2.dsc 1394cf493a849775d73a2a091066e27da6eeebf2e41c8f596bef668701729f32 13334 lcdproc_0.5.2-1.2.diff.gz 453b1e36831de1317d73f0d9feb07e2caa4071d67c79c0492f6c1c66241ee3ca 381182 lcdproc_0.5.2-1.2_powerpc.deb Files: 47f27058f2a6627f7668343a31e6144e 1190 utils extra lcdproc_0.5.2-1.2.dsc 6e836cca47bfa1efad39303b36a8be9f 13334 utils extra lcdproc_0.5.2-1.2.diff.gz ce16f99f7f79627b1d2bcd060dcbdce7 381182 utils extra lcdproc_0.5.2-1.2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjlBKUACgkQXNuq0tFCNaDbUgCg0/fJpQeEz3OK6gvY7poJOi34 Bj4An23Yi5AFUM2FioBXuwsIONpw23Fi =3w9G -END PGP SIGNATURE- Accepted: lcdproc_0.5.2-1.2.diff.gz to pool/main/l/lcdproc/lcdproc_0.5.2-1.2.diff.gz lcdproc_0.5.2-1.2.dsc to pool/main/l/lcdproc/lcdproc_0.5.2-1.2.dsc lcdproc_0.5.2-1.2_powerpc.deb to pool/main/l/lcdproc/lcdproc_0.5.2-1.2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python2.4 2.4.5-5.2 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 29 Sep 2008 09:19:46 + Source: python2.4 Binary: python2.4 python2.4-minimal python2.4-examples python2.4-dev idle-python2.4 python2.4-doc python2.4-dbg Architecture: source all mips Version: 2.4.5-5.2 Distribution: unstable Urgency: medium Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: idle-python2.4 - An IDE for Python (v2.4) using Tkinter python2.4 - An interactive high-level object-oriented language (version 2.4) python2.4-dbg - Debug Build of the Python Interpreter (version 2.4) python2.4-dev - Header files and a static library for Python (v2.4) python2.4-doc - Documentation for the high-level object-oriented language Python python2.4-examples - Examples for the Python language (v2.4) python2.4-minimal - A minimal subset of the Python language (version 2.4) Closes: 500383 Changes: python2.4 (2.4.5-5.2) unstable; urgency=medium . * Non-maintainer upload. * Expand platform definition patch to regenerate configure, th patch was ineffective in the previous upload. Closes: #500383. Checksums-Sha1: 5f4ea6a3b6947583886edadab805b11d1c69e230 1614 python2.4_2.4.5-5.2.dsc 349530feb2ae58fbf90c4c3fd226e9092fe977a0 232194 python2.4_2.4.5-5.2.diff.gz ea09aa6798e12ff8a6c8abdd80fb63e4a16ca9bf 592746 python2.4-examples_2.4.5-5.2_all.deb fba89358c802c36f2efa79a77354eff433ae1ddb 62454 idle-python2.4_2.4.5-5.2_all.deb fd4e48e04d7f3bfea344fe26a19b9d14a7f8cd31 2841204 python2.4_2.4.5-5.2_mips.deb 5b535a48dcf48f11ce6e9106f6b858a15285e82c 1029124 python2.4-minimal_2.4.5-5.2_mips.deb 61d4bfdd42de85660f08f0ad31003b4e52b1eb55 1693532 python2.4-dev_2.4.5-5.2_mips.deb 851cd8af338e2e6039fd79ce276177964505086a 7088596 python2.4-dbg_2.4.5-5.2_mips.deb Checksums-Sha256: 65a77763ba8ac65f33059a2526253a8dad1eee250e2c5890f2d6e00892076307 1614 python2.4_2.4.5-5.2.dsc 40a6cd917663bc4c45f06a8706100fbb113185f188970a4f9ed22d771d1dfedf 232194 python2.4_2.4.5-5.2.diff.gz bc32e2512786d461fe189dec33c584021bf92e52e88358aa821c32ed9f5ecfba 592746 python2.4-examples_2.4.5-5.2_all.deb 8231aa6864e4ec6b6eeb0eed75519dd560152dcf25cfef46b0a6042538741501 62454 idle-python2.4_2.4.5-5.2_all.deb 23dce9b912c65a8276563e962f0a463344054d7c0eb8f7f796037f7c4c203f7e 2841204 python2.4_2.4.5-5.2_mips.deb 30191607fa384da99bceea06d4f497776c1b64aed5e4dc485b7ebe116309c74a 1029124 python2.4-minimal_2.4.5-5.2_mips.deb f036c9d320ffb75f57e8bd9027a9987c9ddf683efede662e1c198b7b9c478cfb 1693532 python2.4-dev_2.4.5-5.2_mips.deb 04922ec09e3ecad40b19016bc7f524225fdbf8cdca330c9fb6690c19f87e2aec 7088596 python2.4-dbg_2.4.5-5.2_mips.deb Files: cae9a850d503d334dc2bb0a17498bd51 1614 python optional python2.4_2.4.5-5.2.dsc c457e47cd7bbb59a7ea6c575896f99da 232194 python optional python2.4_2.4.5-5.2.diff.gz bb27006656ee876783206747c7c7ef5f 592746 python optional python2.4-examples_2.4.5-5.2_all.deb cb84ea28bf60e4ee17a7188509a8563a 62454 python optional idle-python2.4_2.4.5-5.2_all.deb 7c59bebc7bf3f38f7f40df1141d835f2 2841204 python optional python2.4_2.4.5-5.2_mips.deb 6fc231c86ebba0bfa9c7268056111621 1029124 python optional python2.4-minimal_2.4.5-5.2_mips.deb 33d6800bfa79babcd5fa8f15ec546381 1693532 python optional python2.4-dev_2.4.5-5.2_mips.deb f6524a545787494d0236479975b4fdb3 7088596 python extra python2.4-dbg_2.4.5-5.2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjgtHIACgkQXNuq0tFCNaAcfwCaAtBLCSVX7XCfikwK9ov4LJFb cQAAoIi7RpmISyLixluEM7N1kkV63grd =5oRW -END PGP SIGNATURE- Accepted: idle-python2.4_2.4.5-5.2_all.deb to pool/main/p/python2.4/idle-python2.4_2.4.5-5.2_all.deb python2.4-dbg_2.4.5-5.2_mips.deb to pool/main/p/python2.4/python2.4-dbg_2.4.5-5.2_mips.deb python2.4-dev_2.4.5-5.2_mips.deb to pool/main/p/python2.4/python2.4-dev_2.4.5-5.2_mips.deb python2.4-examples_2.4.5-5.2_all.deb to pool/main/p/python2.4/python2.4-examples_2.4.5-5.2_all.deb python2.4-minimal_2.4.5-5.2_mips.deb to pool/main/p/python2.4/python2.4-minimal_2.4.5-5.2_mips.deb python2.4_2.4.5-5.2.diff.gz to pool/main/p/python2.4/python2.4_2.4.5-5.2.diff.gz python2.4_2.4.5-5.2.dsc to pool/main/p/python2.4/python2.4_2.4.5-5.2.dsc python2.4_2.4.5-5.2_mips.deb to pool/main/p/python2.4/python2.4_2.4.5-5.2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python2.4 2.4.5-5.1 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 28 Sep 2008 19:17:31 +0100 Source: python2.4 Binary: python2.4 python2.4-minimal python2.4-examples python2.4-dev idle-python2.4 python2.4-doc python2.4-dbg Architecture: source all mips Version: 2.4.5-5.1 Distribution: unstable Urgency: medium Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: idle-python2.4 - An IDE for Python (v2.4) using Tkinter python2.4 - An interactive high-level object-oriented language (version 2.4) python2.4-dbg - Debug Build of the Python Interpreter (version 2.4) python2.4-dev - Header files and a static library for Python (v2.4) python2.4-doc - Documentation for the high-level object-oriented language Python python2.4-examples - Examples for the Python language (v2.4) python2.4-minimal - A minimal subset of the Python language (version 2.4) Closes: 498857 500383 Changes: python2.4 (2.4.5-5.1) unstable; urgency=medium . * Non-maintainer upload. * Expand copyright notice to cover licenses of linked against libraries. Closes: #498857. * Introduce new platform definitions for alpha, hppa, mips, mipsel, sparc. Closes: #500383. Checksums-Sha1: 52e460c908344acd44d385bd8fd6ec942cc2c14b 1614 python2.4_2.4.5-5.1.dsc 7176983f7e818ace8f5f16efa583b9d5c2c9d557 232128 python2.4_2.4.5-5.1.diff.gz b156bf1062ef3f2479e28e4dfe8d8a90e7c71238 592660 python2.4-examples_2.4.5-5.1_all.deb eb09b91a844f6e2425fae90080c5d6c4cdc5419e 62428 idle-python2.4_2.4.5-5.1_all.deb be3b3edd2ef53010403e9a86a7f9fb3f554ec654 2841108 python2.4_2.4.5-5.1_mips.deb 6ac6d2ff21f4ac29e8b412e0ee3c8c46f50bd76b 1029126 python2.4-minimal_2.4.5-5.1_mips.deb c039eb259566416c7e076d3f244556232dbb930a 1693556 python2.4-dev_2.4.5-5.1_mips.deb ea5a4d557f3081f88890b9a7cd31f89150c84855 7088578 python2.4-dbg_2.4.5-5.1_mips.deb Checksums-Sha256: a77972defdb3daa88068ae78c7c754b1d4deb431eeaa9021e83583c238c2068c 1614 python2.4_2.4.5-5.1.dsc 5ac7097dc5cdb391f03d7589b7dda17d5c12cd92a4bdc6f94ab0361bd6502ac2 232128 python2.4_2.4.5-5.1.diff.gz 1ee476ef3b64bb8b02a88e6829ca9348acf475fe7c442bee0456d327f7bf0d19 592660 python2.4-examples_2.4.5-5.1_all.deb d948d9247cb9c4417703a57b7a37636cad52cf8d0590a6c91bb1de688e20913a 62428 idle-python2.4_2.4.5-5.1_all.deb 1ab5766979793391d41b02147cdf12cd75acc0366957ff36cd48e0edb007c266 2841108 python2.4_2.4.5-5.1_mips.deb 8a5c6d9215b2996877133d555374a8acad340168b891f1a0f1478ededec4ec98 1029126 python2.4-minimal_2.4.5-5.1_mips.deb ece4190878987fcb3ccd9f1d8561f1d7399e03713b015a5d8e676a77870d 1693556 python2.4-dev_2.4.5-5.1_mips.deb 4c2bc5c18f1dc4c44b122a5e48a2321d25d37389e156adcdd44db07b55d995e7 7088578 python2.4-dbg_2.4.5-5.1_mips.deb Files: e2ccfb69fba38eca197343f9fb0d9626 1614 python optional python2.4_2.4.5-5.1.dsc cd1fc1bb370a3a6cf5820e9f3f717e33 232128 python optional python2.4_2.4.5-5.1.diff.gz a6c402d4aa5f6a1c207a623a1e357be9 592660 python optional python2.4-examples_2.4.5-5.1_all.deb 609173e1aa1f266aa4e81165d238af1c 62428 python optional idle-python2.4_2.4.5-5.1_all.deb cb5db9433d6d3ba047a15f30858acace 2841108 python optional python2.4_2.4.5-5.1_mips.deb 60a844ab1b16ec1b7f4216942fdc 1029126 python optional python2.4-minimal_2.4.5-5.1_mips.deb 63bb88cd8910d2a1be68c722c40c2abf 1693556 python optional python2.4-dev_2.4.5-5.1_mips.deb 4fbef591656a8012bfae0137e6abda2f 7088578 python extra python2.4-dbg_2.4.5-5.1_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjf3ZIACgkQXNuq0tFCNaAsHACgvrTJRv8lYn3s7YYmV42PdU/F DIEAoMnB4EeKGqwYDVeH8Tv0UYVPJ2YD =m29K -END PGP SIGNATURE- Accepted: idle-python2.4_2.4.5-5.1_all.deb to pool/main/p/python2.4/idle-python2.4_2.4.5-5.1_all.deb python2.4-dbg_2.4.5-5.1_mips.deb to pool/main/p/python2.4/python2.4-dbg_2.4.5-5.1_mips.deb python2.4-dev_2.4.5-5.1_mips.deb to pool/main/p/python2.4/python2.4-dev_2.4.5-5.1_mips.deb python2.4-examples_2.4.5-5.1_all.deb to pool/main/p/python2.4/python2.4-examples_2.4.5-5.1_all.deb python2.4-minimal_2.4.5-5.1_mips.deb to pool/main/p/python2.4/python2.4-minimal_2.4.5-5.1_mips.deb python2.4_2.4.5-5.1.diff.gz to pool/main/p/python2.4/python2.4_2.4.5-5.1.diff.gz python2.4_2.4.5-5.1.dsc to pool/main/p/python2.4/python2.4_2.4.5-5.1.dsc python2.4_2.4.5-5.1_mips.deb to pool/main/p/python2.4/python2.4_2.4.5-5.1_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python2.5 2.5.2-11.1 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 28 Sep 2008 19:04:23 +0100 Source: python2.5 Binary: python2.5 python2.5-minimal python2.5-examples python2.5-dev idle-python2.5 python2.5-dbg Architecture: source all mips Version: 2.5.2-11.1 Distribution: unstable Urgency: medium Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: idle-python2.5 - An IDE for Python (v2.5) using Tkinter python2.5 - An interactive high-level object-oriented language (version 2.5) python2.5-dbg - Debug Build of the Python Interpreter (version 2.5) python2.5-dev - Header files and a static library for Python (v2.5) python2.5-examples - Examples for the Python language (v2.5) python2.5-minimal - A minimal subset of the Python language (version 2.5) Closes: 498477 499132 Changes: python2.5 (2.5.2-11.1) unstable; urgency=medium . * Non-maintainer upload. * Expand copyright notice to cover licenses of linked against libraries. Closes: #498477. * Introduce new platform definitions for alpha, hppa, mips, mipsel, sparc. Closes: #499132. Checksums-Sha1: 745f980f7e48578412084233ac8d3ecd3ca8ed35 1822 python2.5_2.5.2-11.1.dsc 5f185411ecc04890587dc0c57d47913569f03d6e 252853 python2.5_2.5.2-11.1.diff.gz 89b3705436ea6577bf8c078bf566eb29c2feb4a8 649526 python2.5-examples_2.5.2-11.1_all.deb 035738b6ba925ff28152d2dff5d0450349be7a3c 66430 idle-python2.5_2.5.2-11.1_all.deb c6e9e2b4955160857455727701b5c1d62f670e10 2928972 python2.5_2.5.2-11.1_mips.deb 9d5308a974c57059d3570634cf78fcbcfd67c1b6 1237714 python2.5-minimal_2.5.2-11.1_mips.deb 397cb0849929e80f47daaa4c28e2123b28907b10 2121328 python2.5-dev_2.5.2-11.1_mips.deb e2b72b304f28ff0c87e865e6e3d3f84d78c8c3ae 8130516 python2.5-dbg_2.5.2-11.1_mips.deb Checksums-Sha256: f8f40bfdd5826102995566c7d90e17c911f1d0a4d0d344cc57abc411e46a15a6 1822 python2.5_2.5.2-11.1.dsc 63201a394a013e6ffb4f90684fd21eec1490ad671c35a88e7f0f29f0bec72382 252853 python2.5_2.5.2-11.1.diff.gz 07b30dda3ecc157f09ae0abfeba3a07132dd40655c0c470ef6f0f3c819880883 649526 python2.5-examples_2.5.2-11.1_all.deb 18ba90c25cb6d4f40a171561c986353053d575e772dd4566d28111efcdbf23a2 66430 idle-python2.5_2.5.2-11.1_all.deb 2d5969009bb5c47ad6f5bca152ee2e68d1907872d59958a1136835aa49b6ccdb 2928972 python2.5_2.5.2-11.1_mips.deb 7e479787844e633e5b607ba7124bb30b1a8c56c4308e6c6706b487626db62697 1237714 python2.5-minimal_2.5.2-11.1_mips.deb 47f538ef1d843c25f9cde149ecf9af20249436f4c3f28d10a70bb7b1694e6ecd 2121328 python2.5-dev_2.5.2-11.1_mips.deb fd7cfc5d9c2c55bd2a98a1456888487bfcddd39b9cc7c3d080f564119907c5ef 8130516 python2.5-dbg_2.5.2-11.1_mips.deb Files: 44a7db9ec85f0aec3f797cf6b157936a 1822 python optional python2.5_2.5.2-11.1.dsc 4bf4c07843d00f492c4f6d919c7cc82a 252853 python optional python2.5_2.5.2-11.1.diff.gz dfabccc1d546c33c691a371ae36180d0 649526 python optional python2.5-examples_2.5.2-11.1_all.deb 605c498cdbfa375d42773da29ae68436 66430 python optional idle-python2.5_2.5.2-11.1_all.deb 6ce958200420d99c18bfdb0db3aada51 2928972 python optional python2.5_2.5.2-11.1_mips.deb f0057641ab4b55927c968625b20b4de9 1237714 python optional python2.5-minimal_2.5.2-11.1_mips.deb ce0ae23d8fb1719e293897bbe60dabf2 2121328 python optional python2.5-dev_2.5.2-11.1_mips.deb c39bbeb87998525de5dfc2068b9e17dd 8130516 python extra python2.5-dbg_2.5.2-11.1_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjgJV8ACgkQXNuq0tFCNaCQSQCgu3lQWWMvkD3MlOSqqspzWZPw Q7AAoLhS/I9jtQZ9Sj9onFBWlhJDgsda =969T -END PGP SIGNATURE- Accepted: idle-python2.5_2.5.2-11.1_all.deb to pool/main/p/python2.5/idle-python2.5_2.5.2-11.1_all.deb python2.5-dbg_2.5.2-11.1_mips.deb to pool/main/p/python2.5/python2.5-dbg_2.5.2-11.1_mips.deb python2.5-dev_2.5.2-11.1_mips.deb to pool/main/p/python2.5/python2.5-dev_2.5.2-11.1_mips.deb python2.5-examples_2.5.2-11.1_all.deb to pool/main/p/python2.5/python2.5-examples_2.5.2-11.1_all.deb python2.5-minimal_2.5.2-11.1_mips.deb to pool/main/p/python2.5/python2.5-minimal_2.5.2-11.1_mips.deb python2.5_2.5.2-11.1.diff.gz to pool/main/p/python2.5/python2.5_2.5.2-11.1.diff.gz python2.5_2.5.2-11.1.dsc to pool/main/p/python2.5/python2.5_2.5.2-11.1.dsc python2.5_2.5.2-11.1_mips.deb to pool/main/p/python2.5/python2.5_2.5.2-11.1_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnudatalanguage 0.9~rc1-1.1 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 19 Aug 2008 15:00:55 +0200 Source: gnudatalanguage Binary: gnudatalanguage Architecture: source powerpc Version: 0.9~rc1-1.1 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: gnudatalanguage - Free IDL compatible incremental compiler Closes: 495470 Changes: gnudatalanguage (0.9~rc1-1.1) unstable; urgency=low . * Non-maintainer upload. * Fix FTBFS on arm, armel, mips, mipsel due to invalid LDFLAGS line. (Closes: #495470) Checksums-Sha1: 030662a6d206ae70600125d1d8f5eaa6b26fd2aa 1331 gnudatalanguage_0.9~rc1-1.1.dsc 4b2cb4e8438a8dc5e66160fc4688121933a29371 23459 gnudatalanguage_0.9~rc1-1.1.diff.gz 7db2352f35d01253f843d7309125822a822adf16 1953042 gnudatalanguage_0.9~rc1-1.1_powerpc.deb Checksums-Sha256: 030ff431e812731ed83605709909a43304853491cdfcd2fec3ae54a4c35f 1331 gnudatalanguage_0.9~rc1-1.1.dsc bb3f44327129012531c7c51efda54753cb8b6b65a07e4cc48e282ac1fee22759 23459 gnudatalanguage_0.9~rc1-1.1.diff.gz 3a2a75dfc9997ea9dcab27d83d8ea53b5698595146c883963938fe235dfa0171 1953042 gnudatalanguage_0.9~rc1-1.1_powerpc.deb Files: 1929d7c04711fb16bf8bb76fbbcd4c55 1331 interpreters optional gnudatalanguage_0.9~rc1-1.1.dsc 014dcc2d7fb728a0c3766ea6ccd123b4 23459 interpreters optional gnudatalanguage_0.9~rc1-1.1.diff.gz 63ca7a08d46c618ba186dbb80530f79c 1953042 interpreters optional gnudatalanguage_0.9~rc1-1.1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiq1IAACgkQXNuq0tFCNaBHlQCgyVaiAp7+d4/NvesSpDJv5HAQ w0UAn2i/nCtUH/XDVsDtKz6DQIOFP1c+ =xm0J -END PGP SIGNATURE- Accepted: gnudatalanguage_0.9~rc1-1.1.diff.gz to pool/main/g/gnudatalanguage/gnudatalanguage_0.9~rc1-1.1.diff.gz gnudatalanguage_0.9~rc1-1.1.dsc to pool/main/g/gnudatalanguage/gnudatalanguage_0.9~rc1-1.1.dsc gnudatalanguage_0.9~rc1-1.1_powerpc.deb to pool/main/g/gnudatalanguage/gnudatalanguage_0.9~rc1-1.1_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbcl 1:1.0.18.0-1 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 04 Jul 2008 23:00:48 +0100 Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.18.0-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Changes: sbcl (1:1.0.18.0-1) unstable; urgency=low . * New upstream release. Major changes: + minor incompatible change: SB-SPROF:WITH-PROFILING now by default profiles only the current thread. + minor incompatible change: changes to SYMBOL-VALUE of constants defined with DEFCONSTANT now signal an error. + enhancement: SB-SPROF now has support for wallclock profiling, and is also able to profile specific threads. REPORT output has also additional sorting options. + enhancement: better pretty-printing of DEFPACKAGE forms. (Thanks to Michael Weber) + optimization: structure allocation has been improved ** constructors created by non-toplevel DEFSTRUCTs are ~40% faster. ** out of line constructors are ~10% faster. ** inline constructors are ~15% faster. ** inline constructors are capable of dynamic extent allocation (generally on x86 and x86-64, in some cases on other platforms as well.) + optimization: simple uses of HANDLER-CASE and HANDLER-BIND no longer cons. + optimization: file compiler is now able to coalesce non-circular lists, non-base strings, and bit-vectors. Additionally, constants are never referenced through SYMBOL-VALUE at runtime. + optimization: code defining methods on PRINT-OBJECT (and other generic functions in the COMMON-LISP package) now loads faster. + bug fix: EAI_NODATA is deprecated since RFC 3493. Stop using it in sb-bsd-sockets. + bug fix: if COMPILE-FILE aborts due to an unwind, the partial fasl is now deleted. (reported by Attila Lendvai) + bug fix: READ-LINE always returned NIL for the last line in files. (reported by Yoshinori Tahara) + bug fix: more accurate disassembly annotations of foreign function calls. (thanks to Andy Hefner) + bug fix: trimming non-simple strings and non-string string designators when the there is nothing to trim works properly. (thanks to James Knight) + new feature: SB-POSIX bindings for mlockall, munlockall, and setsid. (thanks to Travis Cross) + fixed some bugs revealed by Paul Dietz' test suite: ** NIL is a valid function name (regression at 1.0.13.38) ** FILL on lists was missing its return value (regression at 1.0.12.27) ** STRING-TRIM, STRING-LEFT-TRIM, and STRING-RIGHT-TRIM did not respect fill pointers properly (regression at 1.0.12.23) ** STRING-TRIM, STRING-LEFT-TRIM, and STRING-RIGHT-TRIM did not respect displacement indices properly (regression at 1.0.12.23) Checksums-Sha1: 0344e5477ceed37dd085dc115d375d8cc78aa74f 1281 sbcl_1.0.18.0-1.dsc 21f4b5706950f727d34d166915f512b2444b5bcf 4083571 sbcl_1.0.18.0.orig.tar.gz dc961610a47aa7b362ab56cc9ae265e3eacf9ae8 43927 sbcl_1.0.18.0-1.diff.gz 6fe98b16f0b0d282795550062b6093e16812e679 1044718 sbcl-doc_1.0.18.0-1_all.deb e6d4cedcd3708a9cf810c1514fac122436477cec 3371260 sbcl-source_1.0.18.0-1_all.deb 93c70454cb674018e3a83542fdbcd81da6e8568f 9651508 sbcl_1.0.18.0-1_mips.deb Checksums-Sha256: ed855960d2bea2542ac50fbf4040cba63f326de7ae3802b93663d804fb372d8d 1281 sbcl_1.0.18.0-1.dsc 726e40bf60aafc3b3e158cb288080c54c40b1cfb2f209383e50675f2c873e751 4083571 sbcl_1.0.18.0.orig.tar.gz 304726cef5b8c3a02d8982a3c31f8b489b4336049b5f84493c68fc24718bc044 43927 sbcl_1.0.18.0-1.diff.gz f1c28af76c79646cd18f96c60ff451226efa92c7414e16cdccc3726b7c18da3e 1044718 sbcl-doc_1.0.18.0-1_all.deb c2cf89ddcb43053ad565e81a3d8ed887559392f847f70e1415d8b41431f9c552 3371260 sbcl-source_1.0.18.0-1_all.deb 216a45496806891402e9a8e5865dabcc59be86f15536a8ab16b029c7a5258412 9651508 sbcl_1.0.18.0-1_mips.deb Files: d91f80ad7073954fb2f60ec7411d37b2 1281 devel optional sbcl_1.0.18.0-1.dsc 0413d06b567887717a74f286f2bcd908 4083571 devel optional sbcl_1.0.18.0.orig.tar.gz 6b9171ef3491df2b30df9cd3e99c69a9 43927 devel optional sbcl_1.0.18.0-1.diff.gz 152f72493e0928c168cadc14bd90fd6d 1044718 doc optional sbcl-doc_1.0.18.0-1_all.deb aaff61cec0c10cf5e6499cebf1741f94 3371260 doc optional sbcl-source_1.0.18.0-1_all.deb 9860dac1f2069a60d34d5e0cc3e220e5 9651508 devel optional sbcl_1.0.18.0-1_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhvZEIACgkQXNuq0tFCNaDqPACg1aPqM48IB7P7nEJklgi+uhD3 YVQAoItKBGU7q9xC2VbXJc5Ho9y4Cg9b =U0Dx -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.18.0-1_all.deb
Accepted sbcl 1:1.0.17.0-1 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Jun 2008 03:27:19 +0100 Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.17.0-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Changes: sbcl (1:1.0.17.0-1) unstable; urgency=low . * New upstream release. Major changes: + temporary regression: user code can no longer allocate closure variable storage on stack, due to bug 419 without explicitly requesting it. Please consult sbcl-devel for advice if you need to use this feature in the meanwhile. + new feature: runtime argument --control-stack-size can be used to adjust thread default control stack size. + enhancement: improved TIME output ** all times are reported using the measured accuracy (milliseconds for real and GC times, microseconds for everything else.) ** processor cycle counts on x86 and x86-64. ** interpreted forms are counted for both evaluator modes. ** number of lambdas converted by the compiler is reported. ** CPU percentage report (computed from real and total run time.) ** more comprehensive run time reporting, using a condenced format ** interperted form, lambda, and page fault counts are omitted when zero. + optimization: ADJOIN and PUSHNEW are upto ~70% faster in normal SPEED policies. + optimization: APPEND is upto ~10% faster in normal SPEED policies. + optimization: two argument forms of LAST are upto ~10% faster in normal SPEED policies. + optimization: NCONC no longer needs to heap cons its REST list in normal SPEED policies. + bug fix: SB-FLUID build feature no longer breaks the build. (thanks to Sidney Markowitz) + bug fix: UNION and NUNION work with :TEST-NOT once more, regression since 1.0.9.1. (thanks to Eric Marsden) + bug fix: result of MAKE-ARRAY can be stack allocated - regression since 1.0.15.36. (thanks to Paul Khuong) + bug fix: LAST when always returned the whole list when given a bignum as the second argument. + bug fix: dynamic extent allocation of nested lists and vectors could leak to otherwise accessible parts. + bug fix: invalid optimization of heap-allocated alien variable reference. + bug fix: fasl header checking is less vulnerable to different platform word lengths. + bug fix: more correct assembler syntax for GNU binutils 2.18.50.0.4 support. (thanks to Marijn Schouten) + bug fix: fix ECASE warnings from CMUCL-as-xc-host. (reported by Andreas Franke) + bug fix: the fopcompiler can handle LOCALLY forms (with no declarations) successfully. (reported by Attila Lendvai) Checksums-Sha1: 681a2d9c41fa960a39ac30cbf4a8223ad65eac7c 1273 sbcl_1.0.17.0-1.dsc 54f7ff414e3359ccf11106322d9345b4f468df7a 4100126 sbcl_1.0.17.0.orig.tar.gz 4dfb3d44d1821938d7e364f41907dcb7c16b5245 43155 sbcl_1.0.17.0-1.diff.gz 51cc8e179d06d6ca1ff8bf2869172fa0e0dbbe63 1041626 sbcl-doc_1.0.17.0-1_all.deb 1fb7aad7bada077cbe0d34e6ee79dbb079681194 3363002 sbcl-source_1.0.17.0-1_all.deb 0806743392465458ce1d9c45daa90de4a3323eec 9736310 sbcl_1.0.17.0-1_mips.deb Checksums-Sha256: 0b2e2fcbb5764a64057d7802312ba41e593b1356793658e8a953fcb12c7984ea 1273 sbcl_1.0.17.0-1.dsc 11a3feb6405d2a5528a1b7138f9a80494aa6eede2cb137fb7a9b4e5bbf066d39 4100126 sbcl_1.0.17.0.orig.tar.gz 0b3083869f72391e9737e9afe52a4f1b9881c8bf4e2747fe46ffe2e00da5a655 43155 sbcl_1.0.17.0-1.diff.gz 1f41be4669bfa5c8a6c0b9247c386f9f3f4e48b5c60cdfeb5635d44a8ee8e8d8 1041626 sbcl-doc_1.0.17.0-1_all.deb f6de0d38cfa4f525ddad5e88662802129a1d535346d0672e8b8e86221c1ec034 3363002 sbcl-source_1.0.17.0-1_all.deb f2992eabec2d7ed7b0c6491e6fa1c0bff372843d0c8c1fc1c8c39d03bd23cc4c 9736310 sbcl_1.0.17.0-1_mips.deb Files: 837700f7df7fb0285922df567acad190 1273 devel optional sbcl_1.0.17.0-1.dsc d2fd7a02b5165c31100da6ea45915a1d 4100126 devel optional sbcl_1.0.17.0.orig.tar.gz 4ff6549bb41035fde0251b4c22b9e91a 43155 devel optional sbcl_1.0.17.0-1.diff.gz 97c4e251ece19724e6701b376e4c24ba 1041626 doc optional sbcl-doc_1.0.17.0-1_all.deb 1af002406f70bf28fedf55a98d92403b 3363002 doc optional sbcl-source_1.0.17.0-1_all.deb 3956e4459cc653192d4e220108d30ec6 9736310 devel optional sbcl_1.0.17.0-1_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQ7h7XNuq0tFCNaARAskUAJ94RsMXuuXVMZo5awCDMbbYzq0/dwCgvY4X sl2W3ryoJEfRb/3A3lvU5qQ= =KLFG -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.17.0-1_all.deb to pool/main/s/sbcl/sbcl-doc_1.0.17.0-1_all.deb sbcl-source_1.0.17.0-1_all.deb to pool/main/s/sbcl
Re: Current build status of the mips port
Luk Claes wrote: Hi Thiemo Thanks for this status report. Thiemo Seufer wrote: I went again through the mips build problems and collected the appended list which records the current state, with a few annotations added. Needs retry --- All given back when still needed. Please don't include packages in such a listing that have a sane wanna-build state: packages in Needs-Build or Dep-Wait or Building (for a normal amount of time)... FTR, this list was only meant as an overview, not as a means to prod buildd admins or the release team to do something with it. :-) I planned to request give-backs via mail to -release. All the items below need further analysis. Maybe needs retry (TODO: check) --- -- Qt ABI, fix by waiting for next Qt version -- kde4libs# needs rebuild to fix ABI (or wait for new version) kdebase-runtime merkaartor universalindentgui sailcut psi ktoon # Broken qt ABI Do they or do they not need wanna-build magick? I believe they will need only retries once a new kde4libs is uploaded to unstable (which will fix the current qreal/float/double ABI breakage on mips/mipsel). That said, I haven't tested if that's enough. -- ghc6 stuff -- washngo # vm exhausted, (arm armel mips mipsel powerpc) haskell-haskell-src # vm exhausted, (mips mipsel alpha) lhs2tex pandoc gtkrsync highlighting-kate haskell-happs-data haskell-happs-ixset haskell-happs-server haskell-happs-state haskell-happs-util haskelldb-hsql-mysql haskelldb-hsql-odbc haskelldb-hsql-postgresql haskelldb-hsql-sqlite3 arch2darcs darcs-buildpackage hpodder Will these probably build fine when retried? At least washngo still fails, I haven't tested the rest of it. -- other -- mlt # (ia64 mips mipsel powerpc) vdr-plugin-live kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips powerpc s390 sparc) mozart gpsdrive libgtk-java # needs libcairo-java-dev qtnx# needs libnxcl1 tuxguitar music-applet# needs libxml-parser-perl, (mips mipsel powerpc) mplayer # (hppa mips mipsel powerpc sparc) edenmath.app gnome-chemistry-utils virt-manager gsynaptics ucspi-proxy epiphany-extensions What does this list mean? Those _may_ build now, but that's untested. Should be in in P-a-s (or not-for-us?) -- Did you contact P-a-s administrators (and buildd maintainers) about it? I mail the P-a-s administrator about once a year, I never got a response. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Current build status of the mips port
I went again through the mips build problems and collected the appended list which records the current state, with a few annotations added. Thiemo Debian mips port, status 2007-05-16. See also: http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstablea=mipspriority= Architecture-independent problems, failed packages and Dep-waits are not systematically tracked. The mipsel port is only incidentially tracked. == Maybe fixed (TODO: remove when actually ok) --- cacao # CTX_EPC undeclared, patch sent, #449185, #479529, fixed in experimental, reopened root-system # partial patch sent, #434855, fixed differently upstream # - but FTBFS in experimental with new version gddrescue # patch sent, #474426 guile-1.8 # segfaults (ia64 mips mipsel), patch sent, #481378 firebird2.0 # patch sent, #481208 scribus # was disabled for old toolchain bug, re-enable requested, #481441 libflorist # odd gnat-4.1 dep, patch sent, #479075 tightvnc# Needs imake tweak, patch sent, #481444 lasso # botched java check, patch sent, #479737, (mips mipsel s390) soci# patch sent, #481499 Needs retry --- usepackage # not reproducible, (mips mipsel) openarena # not reproducible, (mips) hildon-thumbnail # (mipsel) libhildonfm # (mips) [mipsel needs dep-wait on hildon-thumbnail] hildon-desktop # (sparc) [mips mipsel need dep-wait on libhildonfm] helium # (mipsel powerpc) netatalk# (mips) illuminator # (arm mips mipsel) libgdal-grass # (mips mipsel powerpc) hplip # (mips mipsel) Maybe needs retry (TODO: check) --- -- Qt ABI, fix by waiting for next Qt version -- kde4libs# needs rebuild to fix ABI (or wait for new version) kdebase-runtime merkaartor universalindentgui sailcut psi ktoon # Broken qt ABI -- ghc6 stuff -- washngo # vm exhausted, (arm armel mips mipsel powerpc) haskell-haskell-src # vm exhausted, (mips mipsel alpha) lhs2tex pandoc gtkrsync highlighting-kate haskell-happs-data haskell-happs-ixset haskell-happs-server haskell-happs-state haskell-happs-util haskelldb-hsql-mysql haskelldb-hsql-odbc haskelldb-hsql-postgresql haskelldb-hsql-sqlite3 arch2darcs darcs-buildpackage hpodder -- other -- mlt # (ia64 mips mipsel powerpc) vdr-plugin-live kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips powerpc s390 sparc) mozart gpsdrive libgtk-java # needs libcairo-java-dev qtnx# needs libnxcl1 tuxguitar music-applet# needs libxml-parser-perl, (mips mipsel powerpc) mplayer # (hppa mips mipsel powerpc sparc) edenmath.app gnome-chemistry-utils virt-manager gsynaptics ucspi-proxy epiphany-extensions Broken source - -- Bug reported -- monotone# Testsuite too strict, #474280 mklibs # See #445507 xserver-xorg-video-newport # See #402178 g-wrap # See #473085 noteedit# See #474896 libjdic-java# doesn't try to build arch-specific packages, #478943 iaxclient # Needs atomics, #475809 ardour # See #474422 kaffe # perl failure, pending, #479716 xcircuit# creates files in clean, #481460 glob2 # See #479872 gst-editor # See #436324 gnome-cups-manager # See #417209 camelbones # See #447373, removal requested haskell-syb-with-class # template haskell, #469890 -- gcc-4.3 induced bugs, no patch -- insighttoolkit # See #474537, #478950 necpp # See #474838 gpsim # See #474796 ttfm# See #474409 asc # See #478838 qtractor# See #481393 dballe # See #381397 -- bug unreported -- libqglviewer# creates files in clean galax # creates files in clean gigedit # gcc-4.3 gnudatalanguage # gcc-4.3 Should be in in P-a-s (or not-for-us?) -- -- sys/io.h on (mips mipsel powerpc) -- flashrom lcd4linux vbetool libx86 superiotool rovclock -- ocamlopt on !(alpha arm armel hppa ia64 m68k mips mipsel s390) -- ara spamoracle whitelister -- no upstream support for mips/mipsel -- rtai xen-3 virtualbox-ose xserver-xorg-video-intel # x86 only xserver-xorg-video-geode # x86 only libacpi # x86/ia64 only flashplugin-nonfree-extrasound # i386 only eeepc-modules-2.6 # i386 only cpushare# P2P distributed computing client systemtap # needs kprobe umview # UML related? usplash tuxonice-userui # needs libusplash-dev brdesktop-artwork # needs libusplash-dev -- other -- gcj-4.1 # obsolete on mips/mipsel Unported -- Hard to port, porting deferred -- qemu# currently no host support upstream purelibc llvm-gcc-4.2 openmpi openafs -- Maybe needs port (TODO: check) -- freej xenomai lcdproc dphys-kernel-packages ddccontrol
Accepted sbcl 1:1.0.16.0-2 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 03 May 2008 08:28:53 +0100 Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.16.0-2 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Changes: sbcl (1:1.0.16.0-2) unstable; urgency=low . * Fix alpha build failure. Checksums-Sha1: a962f0a5a6e8cebce15ff335a0d1e5869a326d77 1273 sbcl_1.0.16.0-2.dsc 030a03a297238a5c98942d8314ea072be4343a6c 42398 sbcl_1.0.16.0-2.diff.gz 9ddc3ecab75d7a2d8ecb78d42ccbe0fcb65bd094 1040750 sbcl-doc_1.0.16.0-2_all.deb ba62185b929162e45da093c717396f076a766f7d 3359706 sbcl-source_1.0.16.0-2_all.deb 459c8e13d358b99b346426f52b438440da99707b 9726294 sbcl_1.0.16.0-2_mips.deb Checksums-Sha256: 5bc7fdfa870d3bc27b058aa1d2b51b12ef79729cda686d35d4b697351c97e3cb 1273 sbcl_1.0.16.0-2.dsc 8bb8f4030f197ebfc8984aac921c8eb31faf8dc765d9df0435fdb3b2f72d0bff 42398 sbcl_1.0.16.0-2.diff.gz 1a9168c3ab0d372dd2a110ff627265e1726eba224427b9e81c14933129100e0a 1040750 sbcl-doc_1.0.16.0-2_all.deb 826147032969d899a7c2ab3356fcd7db9e24d533ca5b209328c15e5dc3a3d176 3359706 sbcl-source_1.0.16.0-2_all.deb 7a9185572876551f838767da14b9282d69c479724cc84fbeb7435d361ba7362b 9726294 sbcl_1.0.16.0-2_mips.deb Files: bde4c19b8d74a510f037d2b9769a16f5 1273 devel optional sbcl_1.0.16.0-2.dsc 145d0a15a67b6ff8b6ece4b487070618 42398 devel optional sbcl_1.0.16.0-2.diff.gz 7dff47c3ab5dd1b79bb7b30b13702a8d 1040750 doc optional sbcl-doc_1.0.16.0-2_all.deb 39ece2f93f7c2ba3ded9b17b22e96927 3359706 doc optional sbcl-source_1.0.16.0-2_all.deb c037e5fe1edda3149c78041ae7464439 9726294 devel optional sbcl_1.0.16.0-2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIHDlUXNuq0tFCNaARAiIdAKDIoilpmvcd9bBcsaJtqAKnfLHdpACg+V3I 8exeAsYZxXlXxoSTpUamuw0= =zN6k -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.16.0-2_all.deb to pool/main/s/sbcl/sbcl-doc_1.0.16.0-2_all.deb sbcl-source_1.0.16.0-2_all.deb to pool/main/s/sbcl/sbcl-source_1.0.16.0-2_all.deb sbcl_1.0.16.0-2.diff.gz to pool/main/s/sbcl/sbcl_1.0.16.0-2.diff.gz sbcl_1.0.16.0-2.dsc to pool/main/s/sbcl/sbcl_1.0.16.0-2.dsc sbcl_1.0.16.0-2_mips.deb to pool/main/s/sbcl/sbcl_1.0.16.0-2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbcl 1:1.0.16.0-1 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 01 May 2008 13:34:28 +0100 Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.16.0-1 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Changes: sbcl (1:1.0.16.0-1) unstable; urgency=low . * Re-allow builds for alpha and sparc. * New upstream release. Major changes: + minor incompatible change: revert the changes to sb-posix's error signaling added in 1.0.14. + minor incompatible change: change PROBE-FILE back to returning NIL whenever we can't get a truename, as was the case before 1.0.14. + minor incompatible change: SB-BSD-SOCKETS:NAME-SERVICE-ERROR now inherits from ERROR instead of just CONDITION. + new feature: SB-INTROSPECT can provide source locations for instances as well. (thanks to Tobian Ritterweiler) + optimization: binding special variables now generates smaller code on threaded platforms. + optimization: MEMBER and ASSOC are over 50% faster for :TEST #'EQ and cases where no :TEST is given but the compiler can infer that the element to search is of type (OR FIXNUM (NOT NUMBER)). + optimization: better LOGNOT on fixnums. + optimization: modular arithmetic for a particular requested width is implemented using a tagged representation unless a better representation is available. + fixed bug 423: TRULY-THE and *CHECK-CONSISTENCY* interaction. + bug fix: SB-BSD-SOCKETS:MAKE-INET-ADDRESS checks the input string for wellformedness and returns a specialized vector. (reported by Francois-Rene Rideau) + bug fix: FIND-CLASS was not thread-safe. (reported by Attila Lendvai) + bug fix: ~R was broken for vigtillions. (thanks to Luis Oliveira) + bug fix: attempt to obtain *SCHEDULER-LOCK* recursively when unscheduling timer at the same time as another timer fires. + bug fix: don't reschedule timers for dead threads. + bug fix: periodic polling was broken. (thanks to Espen S Johnsen) + bug fix: copying output from RUN-PROGRAM to a stream signalled bogus errors if select() was interrupted. + enhancement: add support for fcntl's struct flock to SB-POSIX. Checksums-Sha1: b7a7108871d634a61670da0b73faaff3347f3e6e 1273 sbcl_1.0.16.0-1.dsc 5e7c4a4260d4412b220089665ae957a0d2f10abe 4096806 sbcl_1.0.16.0.orig.tar.gz 55dbf5a7ca5ad2f9a7f9480e4bfe9d6774067d38 42369 sbcl_1.0.16.0-1.diff.gz 3e88d144133eb8b072689d660511b4ca37084d41 1040716 sbcl-doc_1.0.16.0-1_all.deb fe9f39095600216a8e877d22506c811f903ed7ac 3359590 sbcl-source_1.0.16.0-1_all.deb 8035ea1594d3eede922101373e47890df3a2888f 9726176 sbcl_1.0.16.0-1_mips.deb Checksums-Sha256: 169cb6b4ac403c68070aea578af4d59c9d1857a5568ab2b70a7068d328276eba 1273 sbcl_1.0.16.0-1.dsc 8de105ae13dbbb288e444a3430179021f0095e11586d5343fd7ae34e374ebc6e 4096806 sbcl_1.0.16.0.orig.tar.gz bf59d996a4b7c2ec63a4e3bc512f8f169ee89e713e6065685e801f572883d9bf 42369 sbcl_1.0.16.0-1.diff.gz 310fcc9d5b68d5235adb68655a5015815b77401a7513eb2254600f7cc17821c0 1040716 sbcl-doc_1.0.16.0-1_all.deb cec1bb728d2e468cd24288f205b4aa88f2673a97e9cf02fba3cf3a26520a4860 3359590 sbcl-source_1.0.16.0-1_all.deb 0c55548a88e0b03c7a9e06851e4247ac93f131613bfa2accecdb402f6fde7117 9726176 sbcl_1.0.16.0-1_mips.deb Files: c5c605a1df7107fd8e694647e0066e03 1273 devel optional sbcl_1.0.16.0-1.dsc 951b0c444c2ccfc422bc4c832d331177 4096806 devel optional sbcl_1.0.16.0.orig.tar.gz 2fc31f071952ffe49cea72989a541595 42369 devel optional sbcl_1.0.16.0-1.diff.gz 3417f04380fbbbf2454f79b895947456 1040716 doc optional sbcl-doc_1.0.16.0-1_all.deb 0f2f857672e19cd8bcc35592f97cf522 3359590 doc optional sbcl-source_1.0.16.0-1_all.deb 835464ef2c32c24ee286568db327ead3 9726176 devel optional sbcl_1.0.16.0-1_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIGrIaXNuq0tFCNaARAvFlAKDNgHXDDtMGcppSz0d30U+fFR/8cwCgiNoA 6W8z2SCi2PaFMHc9dD1/kpI= =hST+ -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.16.0-1_all.deb to pool/main/s/sbcl/sbcl-doc_1.0.16.0-1_all.deb sbcl-source_1.0.16.0-1_all.deb to pool/main/s/sbcl/sbcl-source_1.0.16.0-1_all.deb sbcl_1.0.16.0-1.diff.gz to pool/main/s/sbcl/sbcl_1.0.16.0-1.diff.gz sbcl_1.0.16.0-1.dsc to pool/main/s/sbcl/sbcl_1.0.16.0-1.dsc sbcl_1.0.16.0-1_mips.deb to pool/main/s/sbcl/sbcl_1.0.16.0-1_mips.deb sbcl_1.0.16.0.orig.tar.gz to pool/main/s/sbcl/sbcl_1.0.16.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbcl 1:1.0.15.0-2 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 28 Mar 2008 15:37:57 + Source: sbcl Binary: sbcl sbcl-doc sbcl-source Architecture: source all mips Version: 1:1.0.15.0-2 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sbcl - A Common Lisp compiler and development system sbcl-doc - Documentation for Steel Bank Common Lisp sbcl-source - Source code files for SBCL Closes: 463569 Changes: sbcl (1:1.0.15.0-2) unstable; urgency=low . * Re-allow builds for mips and mipsel (Closes: #463569) Files: d1bf96b39c3fbc35689f1ba6d293e795 893 devel optional sbcl_1.0.15.0-2.dsc d66b5e68bdd1d1b7a2a3ba3da610327d 37492 devel optional sbcl_1.0.15.0-2.diff.gz 3a3d4a2d0203e16b3db9709c9e661746 1045092 doc optional sbcl-doc_1.0.15.0-2_all.deb f6d5cd0457ba48830c18b28431e89780 3353142 doc optional sbcl-source_1.0.15.0-2_all.deb e872b3932dab3391ed81a6720881c698 9742390 devel optional sbcl_1.0.15.0-2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9rWJXNuq0tFCNaARAlrrAKCuPP8ieFaxj0uNPchm8wxSW/uCzgCfSEfY 9Aezo5Mp23/8DuC2gpmcIL0= =LLnE -END PGP SIGNATURE- Accepted: sbcl-doc_1.0.15.0-2_all.deb to pool/main/s/sbcl/sbcl-doc_1.0.15.0-2_all.deb sbcl-source_1.0.15.0-2_all.deb to pool/main/s/sbcl/sbcl-source_1.0.15.0-2_all.deb sbcl_1.0.15.0-2.diff.gz to pool/main/s/sbcl/sbcl_1.0.15.0-2.diff.gz sbcl_1.0.15.0-2.dsc to pool/main/s/sbcl/sbcl_1.0.15.0-2.dsc sbcl_1.0.15.0-2_mips.deb to pool/main/s/sbcl/sbcl_1.0.15.0-2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
Charles Plessy wrote: Le Fri, Feb 29, 2008 at 10:40:57AM +0100, Marc 'HE' Brockschmidt a écrit : Due to kernel problems, the mips* buildds haven't been very reliable in the past few weeks, creating a lng backlog of packages that need to be built. As there seems to be a workaround for the kernel bug, this should start getting better from the weekend on. As a maintainer: Just wait. Dear Marc, it is good news to read that there is a solution being found. However, I am a bit confused because previous messages were suggesting that the problem was disk speed, not downtime. The problem is a compound of 1) Not enough RAM (only 512 MB) in some machines, which causes an increasing number of package builds to use swap, and some of them to evenutually fail to build because of a timeout. 2) Slow on-board PIO IDE, from which the firmware can boot from 3) A kernel-imposed limit of 1 GB when PCI DMA devices (like a SATA disk controller) is used. 4) A kernel bug in the cache coherency management which hits PIO IDE, and causes instability since kernel 2.6.18. Up to then, the problem was mostly papered over by an excessive amount of cache flushing in the kernel code. This problem went unnoticed upstream since PIO IDE is these days only used on very small/cheap systems, where a different code path is used. Each of those points costs a chunk of performance and makes the buildds less reliable. The current state is: 4) I tracked this bug down (which was very hard) and wrote a kernel patch which waits for upstream review. The code is hairy enough, so I don't know yet if it is a proper solution or only a workaround. That said, it works fine on my machine (which is the same model than the buildd hardware). 3) This was supposedly fixed in kernel 2.6.22+, and works fine on the successor model of the hardware. It still fails on the buildd hardware, however, so the current choice is between 1GB and fast I/O or more RAM and slow I/O. I am working on fixing this bug. 2) The obvious solution is to add SATA disks to the buildds, this is currently in the works. 1) Upgrades to 1-2 GB RAM are also currently worked on (or already done). For a properly running machine of this type I expect it is capable to build ~5% of the unstable archive per day. IOW, the current backlog should be handled soon. Thiemo
Re: Long-term mass bug filing for crossbuild support
Neil Williams wrote: [snip] As noted elsewhere in this thread, --build can be specified alone but is usually only used for specialist builds for i686 on i386 etc. I fail to see the merit of proposing that packages add --build to the normal Debian build for no reason. One reason is that a guess via uname will lead to e.g. a mips64-linux build attempt on a 32 bit userland, just because the kernel is 64 bit. Generally speaking, such guesses are unreliable in multi-ABI environments. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FYI: Current package build status for the mips port
Hello All, I went through the whole set of failing builds for mips, fixed some bugs and had at least a cursory look at each package. The result is the rather terse list I append here. Thiemo Debian mips port, buildability status 2007-11-03. See also: http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstablea=mipspriority= Dep-waits ar not tracked in this list. === Maybe fixed (TODO: remove when actually ok) --- strace # patch sent, #448802, another one sent to upstream list gprolog # mips patch restored and sent, #448952 uriparser # too strict symbol test, #448959 swi-prolog # very old config.guess, #408076, update promised sbcl# mips/mipsel accidentally removed, will be back next upload pulseaudio # needs newer libatomic-ops, #449125 jvim# patch sent, #273376 cacao # CTX_EPC undeclared, patch sent, #449185 srtp# patch sent, #439976 Buildd issues (TODO: fix kernel/firmware, talk to admins) - libxerces2-java # buildd memory-starved (test-build works) darcs # buildd memory-starved (test-build works) bouncycastle# buildd memory-starved (test-build works) swt-gtk # buildd memory-starved (test-build works) pigment # package check cannot be authenticated netpipe # recorded as uploaded, but missing? loop-aes# recorded as uploaded, but missing? rxvt-unicode# not reproducible (test-build works) sqlitebrowser # not reproducible (test-build works) coreutils # fails tests on buildd, not reproducible for me. (kernel issue?) m-tx# not reproducible, seemingly too relaxed build-dep version pythonmagick# not reproducible (test-build works) Broken generic source, bugs reported defrag # broken on all architectures, unmaintained? dak postman sear php4-ps netatalk libaudio-flac-decoder-perl liblinux-aio-perl ircii-pana openslp-dfsg trang rrootage postgresql-pljava cynthiune.app nyello prokyon3 swh-plugins libavg beast purelibc nikwi firebird1.5 complearn-gui complearn-mpi exif pypy ocaml-reins abraca fusd-kor grouch.app tcpreplay xserver-xorg-input-joystick # fixed upload pending gcj-4.1 # obsolete package happs listlike gtkrsync pugs miro mozart-gtk # fails on all architectures, #419692 prc-tools # proposed-orphaned, #444713 Broken generic source, bugs unreported (TODO: report) - pixie # fails on all architectures autopartkit # fails on all architectures gnustep-dl2 # fails on all architectures twin# includes linux/bitops.h elfkickers # uses internal kernel headers keepalived # uses (likely internal) kernel headers libqglviewer# tries to write outside build dir monotone# tries to run testsuite outside build dir nessus-plugins # unreported gengameng # unreported libswirl-java # unreported solfege # unreported C++ bugs, no bugs filed (TODO: test again with latest g++) -- openmovieeditor ardour qtiplot ktoon chemeq gparted kawari8 No upstream support and hard to port (porting deferred) --- rtai openafs virtualbox-ose xen-3 firebird2.0 flashrom# attempts to use sys/io.h, should be in P-a-s lcd4linux # attempts to use sys/io.h, should be in P-a-s vbetool # attempts to use sys/io.h, unmaintained?, should be in P-a-s libx86 # attempts to use sys/io.h, should be in P-a-s ara # no ocamlopt, should be in P-a-s spamoracle # no ocamlopt, should be in P-a-s elfsh # x86-isms vzctl qemu openmpi # supports IRIX6, not Linux/MIPS Maybe missing ports (TODO: check out) - usplash usplash-theme-debian dynagen lcdproc ocsinventory-agent libflorist libtexttools gambas gambas2 scribus ddccontrol dfsbuild rovclock whitelister open-invaders umview ogre-contrib glest # endianness? scratchbox2 eciadsl pdns-recursor fische odyssey etoken-pro-support systemtap linux-modules-contrib-2.6 grub2 libjdic-java Portability bugs, or other TODO: crystalspace# No IEEE float, #358044 smarteiffel2# eiffeltest not built flumotion # configure fails to find gst-python iceowl # mozilla mips patch missing freehdl # reproduced, but build suppresses compiler error output -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sibyl-installer 1.10 (source mipsel)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 11 Sep 2007 15:37:54 +0100 Source: sibyl-installer Binary: sibyl-installer Architecture: source mipsel Version: 1.10 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sibyl-installer - Install the SiByl boot loader on your disk (udeb) Changes: sibyl-installer (1.10) unstable; urgency=low . [ Otavio Salvador ] * Replace 'base-installer' dependency by 'installed-base' virtual package. Needs base-installer 1.81. . [ Updated translations ] * Bengali (bn.po) by Jamil Ahmed * Esperanto (eo.po) by Serge Leblanc * Italian (it.po) by Stefano Canepa * Dutch (nl.po) by Frans Pop * Punjabi (Gurmukhi) (pa.po) by A S Alam * Romanian (ro.po) by Eddy PetriÈor * Vietnamese (vi.po) by Clytie Siddall Files: f49c6939cbedc8ea3c2e1f5d1fbf9635 687 debian-installer standard sibyl-installer_1.10.dsc 62e80e886750322650c0ccfabf4e4cbf 32328 debian-installer standard sibyl-installer_1.10.tar.gz 8dd73c53125e3feb1bd5fbf0da25da72 16434 debian-installer standard sibyl-installer_1.10_mipsel.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG6wMnXNuq0tFCNaARAm9wAKCk3bOGR+rU7QjO2IQsTs4K+hpq7wCgwnQI 6yl10giUvtQQPkzhBXNcA0Q= =rJFD -END PGP SIGNATURE- Accepted: sibyl-installer_1.10.dsc to pool/main/s/sibyl-installer/sibyl-installer_1.10.dsc sibyl-installer_1.10.tar.gz to pool/main/s/sibyl-installer/sibyl-installer_1.10.tar.gz sibyl-installer_1.10_mipsel.udeb to pool/main/s/sibyl-installer/sibyl-installer_1.10_mipsel.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted colo-installer 1.10 (source mipsel)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 11 Sep 2007 15:18:09 +0100 Source: colo-installer Binary: colo-installer Architecture: source mipsel Version: 1.10 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: colo-installer - Install the Cobalt boot loader on your disk (udeb) Changes: colo-installer (1.10) unstable; urgency=low . [ Otavio Salvador ] * Replace 'base-installer' dependency by 'installed-base' virtual package. Needs base-installer 1.81. Files: 9c6625825d4ec22729f1048d254d4f84 655 debian-installer standard colo-installer_1.10.dsc 4814c013b28daad86cbcb6af9d7a37ca 31580 debian-installer standard colo-installer_1.10.tar.gz 70a18f634352815a384f35e9b016bacb 15096 debian-installer standard colo-installer_1.10_mipsel.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG6wMQXNuq0tFCNaARAs3pAJ4rZSHrRoY/ToebpunlovMSJcYUgQCfRYfm V9kDKCCLLPPwtDHRHVCVa6o= =l3Ov -END PGP SIGNATURE- Accepted: colo-installer_1.10.dsc to pool/main/c/colo-installer/colo-installer_1.10.dsc colo-installer_1.10.tar.gz to pool/main/c/colo-installer/colo-installer_1.10.tar.gz colo-installer_1.10_mipsel.udeb to pool/main/c/colo-installer/colo-installer_1.10_mipsel.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
Raphael Hertzog wrote: [snip] 2/ Second example, libconfig0 has a supplementary symbols _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes from. Is this a internal symbols that I missed? On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above. On amd64 it has lost the _DYNAMIC symbol. Same question as above. The symbols for PLT and dynamic section are magic for the dynamic loader, they aren't relevant WRT shared library dependencies. I guess the same applies to the powerpc SDA symbols. Quick googling led me to believe that I can/should exclude all those. If someone can confirm, it would be great. 3/ Third example, libgci0/0.9.5.dfsg-2 on mipsel has a 0x62 global symbol: 009b6870 gD *ABS* 009b6170 0x62 It also has a 0x63 symbol but this one is marked local so is already discarded. 009b4cb0 lD *ABS* 009b6580 0x63 I have no idea where they come from and what they're used for. Can someone from debian-mips enlighten me? Looks like a corrupted symbol table. 4/ Fourth example, libgarlic2006 on alpha has many supplementary symbols ending in ___elabs. No idea what the root difference is. 5/ Fifth example, it looks like 64 bits ports tend to have differences in common like on libneon2.6 where various functions suffixed by 64 disappear on those arches (ne_get_range64, ne_set_request_body_fd64, ne_set_request_body_provider64). 64bit ports tend to handle 64bit offsets in their interface functions, so they don't need special versions for e.g. LFS. If you want to investigate a bit more on differences, you can grab that file: http://users.alioth.debian.org/~hertzog/comparison.tar.bz2 (139 Mb) the result-compare contain the information about differences on all packages. You can then lookup the difference manually by diffing files in result/sid/*.symbols.* About C++ libraries --- Can anyone explain me why there's randomness in symbol mangling? If I compare the symbols file of gnunet-qt for example I get differences like this between i386 and alpha: @@ -67,10 +67,10 @@ [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 libgnunetqtmodule_about.so.1 gnunet-qt #MINVER# [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 But if you check what it refers too, they refer to the same symbol: $ c++filt _ZThn8_N11GTextEditorD0Ev non-virtual thunk to GTextEditor::~GTextEditor() $ c++filt _ZThn16_N11GTextEditorD0Ev non-virtual thunk to GTextEditor::~GTextEditor() And if I convert the symbols files with c++filt then both files are identical. Different object/vtable layout, see http://www.codesourcery.com/cxx-abi/abi.html#mangling Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about toolchain and objdump's output on ia64/mips/mipsel
Raphael Hertzog wrote: Hello, while working on http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps I'm discovering some arch-specific differences in the objdump -T output of libraries. * On ia64, static functions appear in objdump's output and they are marked as local. See my previous message to debian-ia64: http://lists.debian.org/debian-ia64/2007/08/msg0.html I presume this applies only to static functions whose address wasn't taken inside the module. Otherwise this would be a bug for e.g. callbacks exported via a function pointer. * On ia64, mips and mipsel, functions with gcc's visibility attribute hidden also appear in objdump's output and they are marked as local. Example with libglib2.0: 000386a8 lDF .text 0020 Base.hidden IA__g_list_free Hidden symbols are treated as forced local, at least on mips/mipsel, they aren't supposed to be usable from other components. I have two questions: * are those behaviour expected on those arches or are they bugs in the respective toolchains? For mips/mipsel this is the expected behaviour. * can I consider (in general and not only for those architectures) all those symbols marked as local as unusable by applications linked to those libraries? Yes, as long as unusable means not referencable from other components. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
Steve McIntyre wrote: [snip] mips jealously scribbles all over the first 512 bytes I figure that's a DVH Disk Volume Header as used on SGI machines. mipsel == bytes 000-008 : 0-padding 008-011 : magic header 012-015 : boot mode 016-019 : load address 020-023 : exec address 024-027 : boot file length 028-031 : boot file location Looks like an Ultrix boot record for a DECstation. That's a list of boot file extents and their locations. For an ISO we can assume contiguous files, so it makes no difference in that case. (otherwise blank - may contain other boot files, but we don't use it) There's only a single boot file. As a sidenote, there are other mips/mipsel system architectures with different firmware and disk layout conventions. This makes even building a CD which boots on all mips systems tricky. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdebian-installer 0.47 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Nov 2006 15:59:38 + Source: libdebian-installer Binary: libdebian-installer4 libdebian-installer-extra4 libdebian-installer4-udeb libdebian-installer-extra4-udeb libdebian-installer4-dev Architecture: source mips Version: 0.47 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: libdebian-installer-extra4 - Library of some extra debian-installer functions libdebian-installer-extra4-udeb - Library of some extra debian-installer functions (udeb) libdebian-installer4 - Library of common debian-installer functions libdebian-installer4-dev - Library of common debian-installer functions libdebian-installer4-udeb - Library of common debian-installer functions (udeb) Changes: libdebian-installer (0.47) unstable; urgency=low . * Fix FTBFS on mips/mipsel. Files: 5c42bec4e26f17e718960d00e9998ef7 881 libs optional libdebian-installer_0.47.dsc f8a77ed449bb49bd4439f1558276f10a 378236 libs optional libdebian-installer_0.47.tar.gz f224877c5902532a7c1c4f101a267e38 26436 libs optional libdebian-installer4_0.47_mips.deb 5307c99870b08566752cba7b1716a3ac 159092 libdevel optional libdebian-installer4-dev_0.47_mips.deb e04262515963dbb77115fbf7bf470b52 19740 debian-installer optional libdebian-installer4-udeb_0.47_mips.udeb 3c4a38b8bf0a4640c051397dd3c5f92e 10076 libs optional libdebian-installer-extra4_0.47_mips.deb 0f2aaafed5cd60a23805dbea9b4632b0 3616 debian-installer optional libdebian-installer-extra4-udeb_0.47_mips.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZIDnXNuq0tFCNaARAn21AKCD0sq6oPthVC1GzN+su6DlO/Ay7gCguREJ Jx/9bYA/jD5HyLou23OXnrA= =jZMs -END PGP SIGNATURE- Accepted: libdebian-installer-extra4-udeb_0.47_mips.udeb to pool/main/libd/libdebian-installer/libdebian-installer-extra4-udeb_0.47_mips.udeb libdebian-installer-extra4_0.47_mips.deb to pool/main/libd/libdebian-installer/libdebian-installer-extra4_0.47_mips.deb libdebian-installer4-dev_0.47_mips.deb to pool/main/libd/libdebian-installer/libdebian-installer4-dev_0.47_mips.deb libdebian-installer4-udeb_0.47_mips.udeb to pool/main/libd/libdebian-installer/libdebian-installer4-udeb_0.47_mips.udeb libdebian-installer4_0.47_mips.deb to pool/main/libd/libdebian-installer/libdebian-installer4_0.47_mips.deb libdebian-installer_0.47.dsc to pool/main/libd/libdebian-installer/libdebian-installer_0.47.dsc libdebian-installer_0.47.tar.gz to pool/main/libd/libdebian-installer/libdebian-installer_0.47.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#395262: Arch: all package FTBFS due to test needing network access - RC?
Sven Luther wrote: On Wed, Nov 01, 2006 at 11:53:32PM -0600, Peter Samuelson wrote: Robert Collins [EMAIL PROTECTED] writes: I can also note why bazaar wont build as root: its test suite includes a test for the ability to handle read only directories correctly. As root, anything is writable, so this test fails. [Goswin von Brederlow] That test should add a test for root and skip it. If that is the only reason not to build as root then that should be no excuse (post etch). Your unspoken premise is that there is a _reason_ to support building packages as root. Why? I think it is better just to tell people not to do that. Do some arch not have trouble with fakeroot, and need sudo to work ? This means you need to be able to build packages as real root, no ? Or was this fixed lately ? I think mips/mipsel, and some other arch where concerned. For mips/mipsel this was fixed before sarge. The autobuilder continue to use sudo, and catch some bugs that way. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping an architecture from a package
Ian Wienand wrote: Hi, One of my packages (numactl) has dropped support for two architectures. I would very much like the new package to make it into testing, but it of course fails the up-to-date on previous architectures rule. I thought if I had removed the architectures the scripts would notice, but they don't seem to have [1]. http://www.debian.org/devel/testing says what I should do if I have FTBFS, but not so much what to do if I deliberately dropped it. Do you bug release managers directly, or file a bug somewhere, or send something to a mailing list? File a removal request against package ftp.debian.org. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.1 [gfdl] documentation packages for non-free
Nikita V. Youshchenko wrote: Hello. I'm one of those people beaten by recent removal of gcc documentation. Both myself and people to whom I recommend Debian, *need* gcc documentation to be available in the system. So I had four options: - start a new flamewar on the issue, - stop to use Debian (and to recomment it), - install documentation in non-package form, - create appropriate documentation debs (for non-free). Since I'm a DD, the only real option for me was the last one. I've created gcc-4.1-doc-non-dfsg package, intended for non-free. This package builds several binary packages (cpp-4.1-doc, gcc-4.1-doc, gfortran-4.1-doc, tree;ang-4.1-doc), that contain all files - man pages, info and html docs - that have been in gcc-4.1 4.1.1-10 package [last version before documentation removal], but are not in the current 4.1.1ds1-13 package. I'm going to upload this to non-free. But before that, I'd like interested people to look into the package, and give any comments they feel appropriate. Currently, I've put the package to http://zigzag.lvk.cs.msu.su/~nikita/debian/gcc-doc/ Looks good at a first glance. Thank you for your work. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted arcboot-installer 1.4 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 16 Jul 2006 14:35:01 +0100 Source: arcboot-installer Binary: arcboot-installer Architecture: source mips Version: 1.4 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: arcboot-installer - Install Arcboot on a hard disk (udeb) Changes: arcboot-installer (1.4) unstable; urgency=low . * Thiemo Seufer - New upload for translation updates. . [ Updated translations ] * Arabic (ar.po) by Ossama M. Khayat * Bosnian (bs.po) by Safir Secerovic * Catalan; Valencian (ca.po) by Jordi Mallach * Danish (da.po) by Claus Hindsgaul * German (de.po) by Jens Seidel * Dzongkha (dz.po) * Esperanto (eo.po) by Serge Leblanc * Estonian (et.po) by Siim Põder * Basque (eu.po) by Piarres Beobide * Finnish (fi.po) by Tapio Lehtonen * Irish (ga.po) by Kevin Patrick Scannell * Gujarati (gu.po) by Kartik Mistry * Hungarian (hu.po) by SZERVÃC Attila * Italian (it.po) by Giuseppe Sacco * Georgian (ka.po) by Aiet Kolkhi * Khmer (km.po) by Leang Chumsoben * Kurdish (ku.po) by Erdal Ronahi * Nepali (ne.po) by Shiva Pokharel * Norwegian Nynorsk; Nynorsk, Norwegian (nn.po) by HÃ¥vard Korsvoll * Northern Sami (se.po) by Børre Gaup * Slovak (sk.po) by Peter Mann * Slovenian (sl.po) by Jure Äuhalev * Swedish (sv.po) by Daniel Nylander * Thai (th.po) by Theppitak Karoonboonyanan * Turkish (tr.po) by Recai OktaÅ * Vietnamese (vi.po) by Clytie Siddall Files: 491f6d14e2f0e118c1fbff8aa550f9ca 653 debian-installer standard arcboot-installer_1.4.dsc 45cd1946ebc7c2a95fad9d51513f2730 59881 debian-installer standard arcboot-installer_1.4.tar.gz c4e5eec92136994eb7a81a0fbdf01797 38482 debian-installer standard arcboot-installer_1.4_mips.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEukT0XNuq0tFCNaARAsuQAJ9S1hI79Qmo7bM5vzPRiy16lgiDfgCgxx5g H2NN8gl8X9h0mpQGzBCjR2s= =1pQO -END PGP SIGNATURE- Accepted: arcboot-installer_1.4.dsc to pool/main/a/arcboot-installer/arcboot-installer_1.4.dsc arcboot-installer_1.4.tar.gz to pool/main/a/arcboot-installer/arcboot-installer_1.4.tar.gz arcboot-installer_1.4_mips.udeb to pool/main/a/arcboot-installer/arcboot-installer_1.4_mips.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted delo-installer 1.3 (source mipsel)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 16 Jul 2006 15:21:34 +0100 Source: delo-installer Binary: delo-installer Architecture: source mipsel Version: 1.3 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: delo-installer - Install Delo on a hard disk (udeb) Changes: delo-installer (1.3) unstable; urgency=low . [ Updated translations ] * Arabic (ar.po) by Ossama M. Khayat * Bosnian (bs.po) by Safir Secerovic * Catalan (ca.po) by Jordi Mallach * Danish (da.po) by Claus Hindsgaul * German (de.po) by Jens Seidel * Dzongkha (dz.po) * Esperanto (eo.po) by Serge Leblanc * Estonian (et.po) by Siim Põder * Basque (eu.po) by Piarres Beobide * Finnish (fi.po) by Tapio Lehtonen * Irish (ga.po) by Kevin Patrick Scannell * Gujarati (gu.po) by Kartik Mistry * Hungarian (hu.po) by SZERVÃC Attila * Italian (it.po) by Giuseppe Sacco * Georgian (ka.po) by Aiet Kolkhi * Khmer (km.po) by Leang Chumsoben * Kurdish (ku.po) by Erdal Ronahi * Nepali (ne.po) by Shiva Pokharel * Norwegian Nynorsk (nn.po) by HÃ¥vard Korsvoll * Northern Sami (se.po) by Børre Gaup * Slovak (sk.po) by Peter Mann * Slovenian (sl.po) by Jure Äuhalev * Swedish (sv.po) by Daniel Nylander * Thai (th.po) by Theppitak Karoonboonyanan * Vietnamese (vi.po) by Clytie Siddall Files: 7310f2aed760abf6a225071d29af42c7 603 debian-installer standard delo-installer_1.3.dsc cda2c89ae25b7df9abb289912f969d91 37825 debian-installer standard delo-installer_1.3.tar.gz 02b46df99744a28c380574a3c125cff1 20900 debian-installer standard delo-installer_1.3_mipsel.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEulYpXNuq0tFCNaARAvRQAJ94IKjSsGM94RoXHkgoLGzwjHBAzgCg7URs ucy/kWryonrwDjFJPVJa+s0= =00CF -END PGP SIGNATURE- Accepted: delo-installer_1.3.dsc to pool/main/d/delo-installer/delo-installer_1.3.dsc delo-installer_1.3.tar.gz to pool/main/d/delo-installer/delo-installer_1.3.tar.gz delo-installer_1.3_mipsel.udeb to pool/main/d/delo-installer/delo-installer_1.3_mipsel.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-2.95 2.95.4.ds15-25 (source all mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 06 Jun 2006 02:14:15 +0100 Source: gcc-2.95 Binary: cpp-2.95-doc libg++2.8.1.3-glibc2.2 g77-2.95-doc cpp-2.95 gobjc-2.95 libstdc++2.10-dbg gcc-2.95 gpc-2.95-doc chill-2.95 gpc-2.95 libg++2.8.1.3-dev libg++2.8.1.3-dbg libstdc++2.10-dev libstdc++2.10-glibc2.2 g++-2.95 g77-2.95 gcc-2.95-doc Architecture: source mips all Version: 2.95.4.ds15-25 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: chill-2.95 - The GNU CHILL compiler cpp-2.95 - The GNU C preprocessor cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp) g++-2.95 - The GNU C++ compiler g77-2.95 - The GNU Fortran 77 compiler g77-2.95-doc - Documentation for the GNU Fortran compiler (g77) gcc-2.95 - The GNU C compiler gcc-2.95-doc - Documentation for the GNU compilers (gcc, gobjc, g++) gobjc-2.95 - The GNU Objective-C compiler gpc-2.95 - The GNU Pascal compiler gpc-2.95-doc - Documentation for the GNU Pascal compiler (gpc) libg++2.8.1.3-dbg - The GNU C++ extension library - debugging files libg++2.8.1.3-dev - The GNU C++ extension library - development files libg++2.8.1.3-glibc2.2 - The GNU C++ extension library - runtime version libstdc++2.10-dbg - The GNU stdc++ library (debugging files) libstdc++2.10-dev - The GNU stdc++ library (development files) libstdc++2.10-glibc2.2 - The GNU stdc++ library Closes: 336061 336064 350688 Changes: gcc-2.95 (2.95.4.ds15-25) unstable; urgency=low . * Matthias Klose [EMAIL PROTECTED] . * Add big-endian arm (armeb) support (Lennert Buytenhek). Closes: #336064. * Generate the control file explicitely (debian/rules control-file) still using cpp-2.95, remove the build dependency on cpp-2.95. Closes: #336061. * Fix build failure with new make. Closes: #350688. . * Thiemo Seufer [EMAIL PROTECTED] . * Provide the canonical chill compiler. * Update standards version. * Fix some lintian warnings by adjusting the build dependencies * Fix changelog formatting. Files: 047c34cf1438b6a595f34d2b95c84261 1146 devel optional gcc-2.95_2.95.4.ds15-25.dsc f260c4cdeafa57683f03fe6dc94e8674 867634 devel optional gcc-2.95_2.95.4.ds15-25.diff.gz 5ac034c4738bc82d8652d7dc8e2179d5 69856 doc optional cpp-2.95-doc_2.95.4-25_all.deb 0de55302caa68d748bc6ad46aba72cb1 315374 doc optional g77-2.95-doc_2.95.4-25_all.deb fdbb868146347fdd2cc68d668df01d79 447474 doc optional gcc-2.95-doc_2.95.4-25_all.deb 57288cfdd7f0377ed60d997298c7c958 531000 doc optional gpc-2.95-doc_2.95.4-25_all.deb a21c6ecb7e1005dbd749601ec20e1d62 1145380 devel optional gcc-2.95_2.95.4-25_mips.deb 685d9b593d244c5f7e048923eb0bba04 131068 interpreters optional cpp-2.95_2.95.4-25_mips.deb 5ac7f41b68d1cb4c95251b358c831409 1263350 devel optional g++-2.95_2.95.4-25_mips.deb c9d8a034dd2ed9ec4c47e03dfa197c8e 1063740 devel optional gobjc-2.95_2.95.4-25_mips.deb 91ecf4bf76d7a1b9592ecce4f6b3e9e6 1355402 devel optional g77-2.95_2.95.4-25_mips.deb aa476f59589abc0848df351e77c0cf5f 1056956 devel extra chill-2.95_2.95.4-25_mips.deb 6bc8e649e0cf82c9e6f7aed8ae9e787e 371456 libs optional libstdc++2.10-glibc2.2_2.95.4-25_mips.deb d85df52bd7470f1b7293bf421407b973 328892 libdevel optional libstdc++2.10-dev_2.95.4-25_mips.deb 9d0c689b6d5ffa4e9b2a8c63fe5e4d91 334588 libdevel extra libstdc++2.10-dbg_2.95.4-25_mips.deb c94c7afeeb8824d826f1d30ddfee1be7 347582 libs optional libg++2.8.1.3-glibc2.2_2.95.4-25_mips.deb 67963cfe8d8f3ae26b15f198de51ceb9 355682 libdevel extra libg++2.8.1.3-dev_2.95.4-25_mips.deb 10dfbdb084db0aba898e8d6134d40509 314978 libdevel extra libg++2.8.1.3-dbg_2.95.4-25_mips.deb 3dd45caf88b1595da5ac9c16713a68d4 1696932 devel optional gpc-2.95_2.95.4-25_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhStrXNuq0tFCNaARAgvlAJ9GTeDlY4lnScBZT0so1Kp86rJf5QCg2ZUn BSAZ9wTVqykod8Yzc7oaOPg= =jmH6 -END PGP SIGNATURE- Accepted: chill-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/chill-2.95_2.95.4-25_mips.deb cpp-2.95-doc_2.95.4-25_all.deb to pool/main/g/gcc-2.95/cpp-2.95-doc_2.95.4-25_all.deb cpp-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/cpp-2.95_2.95.4-25_mips.deb g++-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/g++-2.95_2.95.4-25_mips.deb g77-2.95-doc_2.95.4-25_all.deb to pool/main/g/gcc-2.95/g77-2.95-doc_2.95.4-25_all.deb g77-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/g77-2.95_2.95.4-25_mips.deb gcc-2.95-doc_2.95.4-25_all.deb to pool/main/g/gcc-2.95/gcc-2.95-doc_2.95.4-25_all.deb gcc-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/gcc-2.95_2.95.4-25_mips.deb gcc-2.95_2.95.4.ds15-25.diff.gz to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-25.diff.gz gcc-2.95_2.95.4.ds15-25.dsc to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-25.dsc gobjc-2.95_2.95.4-25_mips.deb to pool/main/g/gcc-2.95/gobjc-2.95_2.95.4-25_mips.deb gpc-2.95-doc_2.95.4-25_all.deb
Re: glibc built with gcc-4.1 (update)
Falk Hueffner wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Falk Hueffner a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error: macro requires $at register while noat in
effect
{standard input}:374: Error: macro requires $at register while noat in
effect
{standard input}:438: Error: macro requires $at register while noat in
effect
{standard input}:471: Error: macro requires $at register while noat in
effect
make[3]: *** [/tmp/buildd/glibc-2.3.6/build-tree/alpha-libc/misc/ioperm.o]
Error 1
Hrm. gcc puts .arch ev4 into the .s, and this overrides -mev6 for as.
I cannot really think of anything better than
Ok, thanks a lot, I will add it in the SVN soon.
Do you think it is a fix or a workaround? Or rather do you think this
behaviour is correct?
Well, the right thing to do would be to turn arch to ev6, and then
restore it to whatever it was previously; with this patch, it remains
turned on for the rest of the file and could potentially hide errors.
However, I don't think that's possible with gas. So given this
deficiency, I don't think there's a better way.
FYI, the MIPS gas has
.set push
.set mips32
# ...
.set pop
which is very useful to handle such situations. Alpha gas at least
doesn't document anything similiar, but it might be useful to
implement such a feature for it.
Thiemo
Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys
Lionel Elie Mamane wrote: On Sat, May 27, 2006 at 04:07:22PM +0200, Martijn van Oosterhout wrote: The obvious example is the UK, which insists on checking your passport if you come from the mainland. Passport or ID Card, that is. The www.britishembassy.gov.uk website suggests EEA nationals need only an ID card. A Passport is often recommended regardless. It doesn't get stamped. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
Manoj Srivastava wrote: On 25 May 2006, Andreas Tille spake thusly: On Thu, 25 May 2006, Manoj Srivastava wrote: It has come to my attention that Martin Kraff used an unofficial, and easily forge-able, identity device at a large key Is there any reason to revoke my signature I have put on Martin's key after he showed me his passport? In my opinion, yes, if you consider subverting the KSP like that unacceptable behaviour. Keysigning isn't for judging behaviour but for confirming identity. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing the default syslogd (again...)
Nathanael Nerode wrote: [snip] The installer can use whatever seems most appropriate (does it even log?): The installer does log and puts the logs at /var/log/debian-installer/ on the successfully installed system. If the installation fails, the logs (in the installer ramdisk) are a valuable source of information. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Carlos Correia wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Weimer escreveu: | * Jeroen van Wolffelaar: | | |Official packages of Sun Java are now available from the non-free |section of Debian unstable, thanks to Sun releasing[11 Java under a new |license: the Operating System Distributor License for Java (DLJ)[2][3]. | | | This license requires that we remove all other Java implementations | from the mirror network: | No, it doesn't! ~From DLJ FAQ (http://download.java.net/dlj/DLJ-FAQ-v1.1.txt): 8. Does this license prevent me shipping any alternative technologies ~in my OS distribution? ~ The DLJ does not restrict you from shipping any other technologies ~ you choose to include in your distribution. However, you can't use ~ pieces of the JDK configured in conjunction with any alternative ~ technologies to create hybrid implementations, or mingle the code ~ from the JDK with non-JDK components of any kind so that they run ~ together. It is of course perfectly OK to ship programs or libraries ~ that use the JDK. Because this question has caused confusion in the ~ past, we want to make this absolutely clear: except for these ~ limitations on combining technologies, there is nothing in the DLJ ~ intended to prevent you from shipping alternative technologies with ~ your OS distribution. Why isn't e.g. an alternative pointing from some other Java environment to the JDK javac a hybrid implementation? It is the point of a distribution like Debian to integrate the various pieces. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Francesco Poli wrote: On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote: [For -legal people, the license is attached.] Thanks. [...] Also, section 4 poses a major issue. If, for any reason, the Linux kernel doesn't do something that Java requires, then we are obligated to either fix it or inform everyone who has acquired Java from us. Indeed, it seems we are in chains: whenever Sun decides that we should do it, we are bound to modifying the Debian System to satisfy their requirements and/or notifying the world about the issue. Or stop distributing, which terminates the license immediately. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Peter 'p2' De Schrijver wrote: Being able to install multiple versions is some use to multiarch, but could also be used for other things, such if two packages provide the same binary (git for example). Or to install multiple 'version 'numbers' of the same package. The big problem then is when to install multiple versions of a binary? How should the depends decide when that is needed or wanted and when not? Esspecialy when different versions are available per architecture. One way of doing this would be to make a binary a special directory which contains the actual binary files for the architectures the binaries exist. AIX 1.x did this and allowed transparent execution of binaries in a heterogenous cluster. So if you would start a binary on IA32 AIX machine which only existed in a mainframe AIX version, the system would automatically start the binary on one of the mainframe AIX nodes in the cluster. If an IA32 AIX binary was available, it would locally start this binary. The 'binary directory' had the name, the binary would normally have. The actual binary files get the architecture name they implement as the filename. Eg: there would be an /bin/ls directory containing 2 files : i386, ibm370. How would programs or user specifiy what binary to call? How would You could explicitly start /bin/ls/i386 I think (which would fail if you did it on the wrong machine). The obvious problem here: The scheme is incompatible with non-multiarched software. It would at least require a package manager which specialcases /bin directory, a one-time conversion which moves the binaries, and some trickery for alternatives. Plus some more things which don't come to mind immediately, I guess. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sibyl-installer 1.5 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 14 May 2006 01:39:20 +0100 Source: sibyl-installer Binary: sibyl-installer Architecture: source mips Version: 1.5 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: sibyl-installer - Install the SiByl boot loader on your disk (udeb) Changes: sibyl-installer (1.5) unstable; urgency=low . * Old-style options for head/tail are no longer supported by new busybox. Files: 3ae5e9a644828cdd2db181ca942f7ae6 610 debian-installer standard sibyl-installer_1.5.dsc b9e3612091c52252011cc35153fcc153 30448 debian-installer standard sibyl-installer_1.5.tar.gz 0f360c9dee9fb3977420fb7dc0fc785c 14714 debian-installer standard sibyl-installer_1.5_mips.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEZoOtXNuq0tFCNaARApwRAKCqbrcdOQ6IbOjyvmvsjUgoVjWgyQCgjqM8 7bpmDIz00AScSQI+kkhj7kA= =InZq -END PGP SIGNATURE- Accepted: sibyl-installer_1.5.dsc to pool/main/s/sibyl-installer/sibyl-installer_1.5.dsc sibyl-installer_1.5.tar.gz to pool/main/s/sibyl-installer/sibyl-installer_1.5.tar.gz sibyl-installer_1.5_mips.udeb to pool/main/s/sibyl-installer/sibyl-installer_1.5_mips.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted colo-installer 1.5 (source mipsel)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 13 May 2006 23:05:10 +0100 Source: colo-installer Binary: colo-installer Architecture: source mipsel Version: 1.5 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: colo-installer - Install the Cobalt boot loader on your disk (udeb) Changes: colo-installer (1.5) unstable; urgency=low . * Old-style options for head/tail are no longer supported by new busybox. Files: cf0ec2acee742e4f76037b7f07f771f5 577 debian-installer standard colo-installer_1.5.dsc 46c53cff7433b8300825b5c36274dead 29634 debian-installer standard colo-installer_1.5.tar.gz 84dfa09674f618699b6b267b2c16afe8 13270 debian-installer standard colo-installer_1.5_mipsel.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEZolkXNuq0tFCNaARAsJ4AJ4u7RAeQvPhZycVx4zNtQxDdR24hgCeM5Q9 ggjEuDYeiCJbA8basCNhu2w= =TDHk -END PGP SIGNATURE- Accepted: colo-installer_1.5.dsc to pool/main/c/colo-installer/colo-installer_1.5.dsc colo-installer_1.5.tar.gz to pool/main/c/colo-installer/colo-installer_1.5.tar.gz colo-installer_1.5_mipsel.udeb to pool/main/c/colo-installer/colo-installer_1.5_mipsel.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster wrote: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? BSD should be fine, for example. Seconds, since when do we consider the GPL to be viral? Don't know about you, but the FSF does - it has created the LGPL because of this. http://www.gnu.org/licenses/why-not-lgpl.html Thiemo
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster wrote: Simon Josefsson [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Any license that is compatible with the GPL, such as the revised BSD license. But the software is a derivative work of the GPL. Doesn't it need to be licensed under the GPL, too? It likely is an aggregation of works. Distributing the whole will need to adhere to all licenses of all parts involved, and the license for the aggregate will need to be compatible to them as well (for example public domain). IANAL, Thiemo
Re: multiarch status update
[EMAIL PROTECTED] wrote: I have created a new page in the wiki to track info and status http://wiki.debian.org/multiarch I looked at the upstream standards proposal: http://lackof.org/taggart/hacking/multiarch/ It's good. I am particularly pleased by the specification: The terms arch and os represent the Architecture and Operating System as defined and provided by config.guess. It is crucial that this naming be entirely standardized. This *should* be sufficient. Is it sufficient? Cases where it would not be sufficient would be the following: (1) Cases where config.guess reports the same name for functionally different systems, such as the two MIPS ABIs. This should be considered a bug in config.guess, plain and simple. To expand a bit on this, I don't think config.guess is sufficient to handle those cases. E.g. for a MIPS system with 64bit kernel, config.guess will return mips64el-unknown-linux-gnu even when there's only a (little endian) O32 userland installed, but for a 32bit kernel it will be mipsel-unknown-linux-gnu unless the call is prefixed with linux32, which changes the uname, and thus the config.guess output. The endianness is guessed from the defaults of the system compiler (the first cc in $PATH), which is a) not necessarily available, and b) supposed to be exchangable in a full multiarch environment. What's worse, mips64 is a rather entrenched term with inconsistent meanings which cover both the N32 and N64 ABI. A fix to config.guess would AFAICS require to specify a multiarch mode, which changes the output to, say, mipsn32el-unknown-linux-gnu for N32 and to mipsn64-unknown-linux-gnu for N64 (that still doesn't answer the question which ABI would be the native one). But in that case the config.guess can't be the canonical source of information any more. This is not only MIPS-specific, a similiar problem arises e.g. for a ILP32 ABI for x86_64. I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which provides mappings for multiarch-sensitive programs. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
Marc Haber wrote: On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto [EMAIL PROTECTED] wrote: Richard A Nelson [EMAIL PROTECTED] writes: On Wed, 3 May 2006, Colin Watson wrote: The rest of the system accounts are happily running with /bin/false There is now /bin/nologin which is more secure You can surely explain why /bin/nologin is more secure than /bin/false. I'm eager to learn. I am curious why any of both would be more secure than /dev/null, a place which makes it hard to smuggle an infected binary into. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
Gabor Gombas wrote: On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote: You can surely explain why /bin/nologin is more secure than /bin/false. I'm eager to learn. I am curious why any of both would be more secure than /dev/null, a place which makes it hard to smuggle an infected binary into. If the attacker has enough privileges to replace /bin/nologin or /bin/false, then I fail to see what extra protection would /dev/null give. s/smuggle an infected/install a broken/ , doesn't change the point I wanted to make. Also, applications expecting an executable binary as the login shell may break when they find a device node there. And if the breakage is exploitable, then using /dev/null may turn out to be less secure than using /bin/bash. Such a binary is completely broken, and it would fail in a similiar way for any sort of file it has no execute permission for, not only for $SHELL. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
Gabor Gombas wrote: On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote: Such a binary is completely broken, and it would fail in a similiar way for any sort of file it has no execute permission for, not only for $SHELL. Sure, but that does not change the fact that it is a failure path that is usually not well-tested. Triggering it deliberately without a general audit of login shell handling therefore may discover new bugs with security implications. So you expect systems to become exploitable by mounting /usr as noexec when they provide some /usr/bin/foo shell? Do you also expect this is more likely than an exploitable bug in /usr/sbin/nologin or /bin/false with their dependencies on ldso and glibc? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compiling packages for the standard distribution with -Os instead of -O2
Anthony DeRobertis wrote: On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote: For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at least on the bigger arches (ia32, ia64, amd64, etc), as we can probably trust gcc not to screw up. If gcc generally generates faster code with -Os than -O2, then isn't that a gcc bug, It doesn't do so generally. in that the optimizations enabled by -O2 are incorrectly picked? The compiler can only make some broad assumptions about the CPU's memory/cache system, and none about the size of the working set. If the working set with -O2 spills out of the cache but doesn't with -Os then you get a performance improvement from -Os, for the next CPU with bigger caches it can swing back. [Also, are there that man AMD64 machines with limited memory? Or IA64?] Swap is now mostly irrelevant for performance discussions, if you hit swap you won't have performance anyway. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Light Desktop - meta package
Linas Žvirblis wrote: Joey Hess wrote: By this lie of reasoning the only task that Debian can afford to ship is either KDE or Gnome. No, not at all. That is not what I was trying to say. KDE and GNOME were examples of something that did not happen overnight. They proved worthy of becoming a task. Would you accept KDE as a task, if it was started yesterday? A XFCE-based lightweight desktop also isn't something which happened overnight. It's the usual thing I install as desktop environment, and I appreciate that it might become easier and better integrated now. Thiemo
Re: Bug#361418: [Proposal] new Debian menu structure
Ognyan Kulev wrote: Hamish Moffatt wrote: HAM is not an acronym, so Ham Radio would be more appropriate. Even better (IMHO) is the full term Amateur Radio, but some may disagree. I've CC'd debian-hams for their input also. Is there a problem with using Amateur (Ham) Radio? It is unnecessarily complicated. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: [Proposal] new Debian menu structure
Manoj Srivastava wrote: On 14 Apr 2006, Thiemo Seufer told this: Ognyan Kulev wrote: Hamish Moffatt wrote: HAM is not an acronym, so Ham Radio would be more appropriate. Even better (IMHO) is the full term Amateur Radio, but some may disagree. I've CC'd debian-hams for their input also. Is there a problem with using Amateur (Ham) Radio? It is unnecessarily complicated. Do we really want to cater to people who are thrown off by (Ham)? Yes. Debian shouldn't be the Linux Distribution of Cryptic Acronyms. Would it not be a public service to steer such simple souls to something which may be better fit for them, like, say, Windows? I doubt Windows is a better fit. Since when has dumbing down debian been a goal? What exactly was dumbed down here? Is there a non-Ham Amateur Radio we would have to distinguish from? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Light Desktop - meta package
André Luiz Rodrigues Ferreira wrote: 2006/4/13, Pierre Habouzit [EMAIL PROTECTED]: Le Jeu 13 Avril 2006 15:20, Linas Žvirblis a écrit : I think this would be better than a meta package because it would be available in the regular install, and it would avoid some of the issues with meta packages. Meta package or not, I do not consider Light Desktop a good name because it is too general. A name like XFCE desktop would be way more descriptive. because *you* know what XFCE is and looks like In the majority of the times the user doesn't knows what is XFCE. IMHO, xfce is seemed Gnome and Kde. The idea is to have good applications for a light desktop (no depend of Gnome,XFCE or outher WM) and not my favorites :) FWIW, Lightweight Desktop or Lean Desktop sounds better to me. Thiemo
Re: project machine architecture aliases
On Sun, Mar 26, 2006 at 03:09:11PM -0500, Steve M. Robbins wrote: Hi, I have another wishful thinking idea for build machines to float. Suppose I get a bug report saying my package has failed to build on architecture glooble. I don't personally have a globle machine. To debug the problem, I need to fire up www.debian.org/devel, find the link to the list of project machines, scan the list for the name of a glooble machine (which is likely to be the name of a completely unrelated composer of music). Finally, I can log in. Wouldn't it be nice if I could just do: ssh glooble.dev.debian.org and have that be an alias to some machine of architecture glooble? You can setup something similiar with a local ssh config (and maintain and publish that config snippet). I'm assuming that there's a way to do fancy DNS load balancing amongst the machines of type glooble that are currently available. Well, probably you want to re-login to the same machine... Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote:
[snip]
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Actually, I disagree. To me it makes perfect sense the way it
currently is, namely:
kernel-arch-libc
kernel and libc can be empty when they're the default (Linux and
glibc respectively).
The uclibc port uses Linux so I think i386-uclibc is fine. There
could be kfreebsd-i386-uclibc in the future, I suppose, or something
like that.
Makes sense. I would prefer however to stick with gcc's convention
of having arch(-vendor)-kernel-libc, however, kernel-arch(-vendor)-libc
is also
suitable.
Note that for Debian the arch part implies also the ABI, so we won't
have a 1:1 mapping to GNU-style arch-vendor-os-libc+abi anyway.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Wed, Feb 22, 2006 at 08:47:31PM -0800, Steve Langasek wrote: On Thu, Feb 23, 2006 at 12:22:27AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 22 Feb 2006, Chris Stromsoe wrote: for the entire lifetime of the current stable release. Will -17.1 be making its way into stable any time soon? I seriously doubt so. Changing the stable sysklogd requires an upload to stable (which did not happen), and that the stable release manager approves it. Also, mips and mipsel have failed to build sysklogd -17.1, probably due to toolchain borkage: In file included from /usr/include/asm/atomic.h:26, from module.h:31, from ksym_mod.c:97: /usr/include/asm/cpu-features.h:15:35: error: cpu-feature-overrides.h: No such file or directory Maybe that crap is fixed already in mips/mipsel, and a rebuild request/binNMU request for sysklogd should be done to address that? $ dpkg -c l/linux-kernel-headers/linux-kernel-headers_2.6.13+0rc3-2_mips.deb |grep cpu-feature -rw-r--r-- root/root 4858 2005-07-12 21:46:46 ./usr/include/asm/cpu-features.h -rw-r--r-- root/root 414 2005-07-12 21:46:46 ./usr/include/asm/mach-generic/cpu-feature-overrides.h -rw-r--r-- root/root 836 2005-07-12 21:46:46 ./usr/include/asm/mach-ip22/cpu-feature-overrides.h -rw-r--r-- root/root 1039 2005-07-12 21:46:46 ./usr/include/asm/mach-ip27/cpu-feature-overrides.h -rw-r--r-- root/root 1215 2005-07-12 21:46:46 ./usr/include/asm/mach-ip32/cpu-feature-overrides.h -rw-r--r-- root/root 1200 2005-07-12 21:46:46 ./usr/include/asm/mach-ja/cpu-feature-overrides.h -rw-r--r-- root/root 1909 2005-07-12 21:46:46 ./usr/include/asm/mach-mips/cpu-feature-overrides.h -rw-r--r-- root/root 1321 2005-07-12 21:46:46 ./usr/include/asm/mach-ocelot3/cpu-feature-overrides.h -rw-r--r-- root/root 1284 2005-07-12 21:46:46 ./usr/include/asm/mach-rm200/cpu-feature-overrides.h -rw-r--r-- root/root 1042 2005-07-12 21:46:46 ./usr/include/asm/mach-sibyte/cpu-feature-overrides.h -rw-r--r-- root/root 1218 2005-07-12 21:46:46 ./usr/include/asm/mach-yosemite/cpu-feature-overrides.h $ It looks to me like this is still broken on mips. A bug on l-k-h is probably in order. It is probably (also?) a sysklogd bug, userland code isn't supposed to use the kernel's atomic operations. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller wrote: Dear Thiemo, we very much appreciate your work on the gcc-2.95 debian package. For us - and probably also for other users in the scientific community - the old compiler version is still of great value. We use gcc-2.95 to compile C/C++ code with very large mathematical expressions generated by computer algebra software. This involves very long (several thousand lines of code) functions to evaluate multi-variable polynomial expression resulting from perturbation theoretical solutions of physical problems. We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Well, gcc 3.x was somewhat disappointing WRT, but I would expect 4.0 to do better. If 4.x fails for your (valid and standard-conforming) code, please consider to provide a testcase to the upstream developers. I'm sure they are interested in it, and long-term it will help you as well to have a more modern compiler which can handle such cases. Since what we are doing is not so unusual in theoretical physics we are probably not alone with these kind problems. Please consider that even if no other debian packages would depend on gcc-2.95 many users may very much require it. Indeed, I got also one private reply which suggested gcc-2.95 is still an interesting choice for some numerics code. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Jeroen van Wolffelaar wrote: [snip] A similar issue I noted in the past is the big number of build failures that don't get tagged 'Failed'. I tried working on classifying them, but got bored so increadibly fast that I gave up, and decided for myself this should be something the porters should rather look into. And thus I mailed in June about that[2]. I don't believe anyone picked up that, but I might be wrong, of course, my mail was hidden in a big thread about various stuff, just like this very mail is... FWIW, I did for mips/mipsel and found your page to be very helpful. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Steve Langasek wrote: [snip] So those should get added to P-a-s instead. Well, but that'd be something for the buildd-admin to collect. (Or maintainers of the packages, but that doesn't seem to fashionable nowadays...) Um... no. This is *porter* work; one does not have to be a buildd admin to analyze a build failure to see whether the package belongs in P-a-s, and there's no reason that the buildd admins alone should bear the responsibility for figuring out whether a permanent build failure should be fixed or ignored. (Maintainers probably need to be involved in this process, but usually maintainers don't have the requisite knowledge about all our ports to make informed decisions on their own.) FWIW, I started to send mips patches for P-a-s, following the procedure outlined at the top of this file. There was neither a response nor any other discernable action. Saying that's the buildd admin's job about tasks that don't *need* to be done by the buildd admin is a pretty effective way of encouraging the problems that the Vancouver proposal sought to address, where two or three people end up carrying all the ports, and all their time is eaten up by maintaining the buildds and giving back failed packages with no time for following through on the permanent failures (which, even though they sometimes represent a minority of Maybe-Failed packages usually account for a majority of the actual work needing done). A while later, and rather by accident, Ryan Murray told me on IRC (paraphrased) Of course they were ignored, you aren't a buildd admin. Send them to me. So I did. Ryan acknowledged to have received them with (again paraphrased) Well, it's not so urgent. This was about 6 weeks ago. weechat: don't know, error on dh-strip on 5 archs, no bug filed That's 2 out of 7 which need actual debugging, both not arm-specific. And only 1/7 where some action of the buildd maintainer is needed at this time to get something build. The dep-wait is well inside the some action of the buildd maintainer is needed. The needed P-a-s entries could be handeled centrally if the problem description is pile of maybe-failed packages. Wonderful. Nice to see that you think P-a-s entries are somebody else's problem that should be handled centrally. It appears to be the idea of the people with write access to P-a-s. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Thomas Viehmann wrote: Hi Steve, Steve Langasek wrote: Ok. Here's some feedback on some that I either disagree with, or don't see enough rationale for. (This is why, ideally, the process should involve the porters and the maintainers...) Thanks. Doesn't hurt do get educated... +dfsbuild: i386 alpha powerpc amd64 # [ANAIS] debian from scratch installer Seems like it should be portable without too much trouble to other architectures, if there was porter interest? Yes, OTOH it clearly needs to be adapted to whatever it's ported to, and there haven't been any arch additions for well over a year, so it seems interest is limited. For ree: How portable is scaning /dev/mem between position 0xc and 0xf in 512 byte blocks for some magic number as a concept? Not so much. On mips/mipsel it will read some part of the running Linux kernel that way. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Steve Langasek wrote: [snip] -grub2: !hppa !ia64 m68k # bootloader +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc # bootloader for i386/powerpc [?] Is a P-a-s entry some sort of a final verdict? I don't think it makes sense to attempt builds of a package for some years when it is known to fail. (Years might not be true for grub2, an example which comes to mind is gwydion-dylan.) [snip] +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386 # reads ROM from /dev/mem, i386/amd64/ia64-specific The description says this package can also extract font data from video card ROMs. Are we certain this is specific to i386/amd64/ia64? At least for mips/mipsel reading /dev/mem with a PC-like hardcoded offset won't yield anything useful. +rootskel-gtk: alpha amd64 i386 powerpc sparc # [ANAIS] udeb for graphical debian-installer Just because it's only built for these archs now doesn't mean this has to be true long-term. Agreed. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Thomas Viehmann wrote: Hi, Vincent Sanders wrote: [1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm taking a random (end of alphabet) sample from maybe-failed: twinkle: requeue (probably libccrtp was stuck in NEW) wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696 xchm: retry (needed libchm-dev) xmms-openspc: arch specific (says maintainer in control) zinc-compiler: arch specific dependency (ghc6) visualboyadvance: buggy, could requeue to get #334727 weechat: don't know, error on dh-strip on 5 archs, no bug filed That's 2 out of 7 which need actual debugging, both not arm-specific. If you're deperate for people looking at build-failures, that's OK, but only few of them seem really arm-specific. The number of Maybe-Failed packages doesn't tell much. A while ago I went through it for mips and found that the vast majority consists of - Packages which should be in P-a-s - Packages which should be in state Dep-Wait - Packages which are broken in the same obvious way for several architectures Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted partitioner 0.32 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 30 Nov 2005 22:04:22 + Source: partitioner Binary: partitioner Architecture: source mips Version: 0.32 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: partitioner - Partition a hard drive (udeb) Changes: partitioner (0.32) unstable; urgency=low . * Colin Watson - Build the architecture name into the binary rather than making a messy call to /usr/bin/udpkg --print-architecture (with hardcoded path!). - Unhardcode path to update-dev to allow a smoother transition to a generic /bin/update-dev that handles udev too. * Thiemo Seufer - Fix find use in debian/rules Files: 1722677aec42989a939ff8f23a09748e 824 debian-installer standard partitioner_0.32.dsc 5233f3ae1ec45460c29615af662ee933 30785 debian-installer standard partitioner_0.32.tar.gz ab6eb000811f79dc7da64df8e67fe338 17410 debian-installer standard partitioner_0.32_mips.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjiJCXNuq0tFCNaARAukuAKC3SWfBkGKRrHiY18lgrCIkUHTYqACg82dh 1fVDIa7Zf4VPPgvEi9TZukY= =Qd7K -END PGP SIGNATURE- Accepted: partitioner_0.32.dsc to pool/main/p/partitioner/partitioner_0.32.dsc partitioner_0.32.tar.gz to pool/main/p/partitioner/partitioner_0.32.tar.gz partitioner_0.32_mips.udeb to pool/main/p/partitioner/partitioner_0.32_mips.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: Hi all! On Mon, 28 Nov 2005, Miles Bader wrote: nicely as texlive-lang-tibetan and texlive-fonts-recommended. On Mon, 28 Nov 2005, Rogério Brito wrote: texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? As I said, it is true that I can arbitrary hyphens, but there was a decisison behind these names: Keeping the collections of TeX live (this is what users see when they use the installer) and the debian packages namewise in sync. I have no problem introducing different names, but only if I see good reasons other than I like it or it is usual like this. To me, the argument on name-sync collection-debiannames is strong enough to keep the current names. FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Andrew Vaughan wrote: On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. As a user, I much prefer foo + libfoo + foo-doc-en + foo-doc-fr rather than foo + libfoo + foo-en-doc + foo-fr-doc To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type It may look more natural, but it makes pattern matching harder (e.g. python-docutils is a false positive for the naive approach). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: [snip] For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang ? Arabic is ar, IIRC. For groups of languages like cjk or indic it might make sense to split the packages further, or, if that's not feasible, use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style two-character). Finally a question concerning the package build from binaries-source: texlive-binaries-source 96M texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools texlive-langcjk Renaming some of them in the `obvious' way is in fact misleading: Take eg old:texlive-binextra and rename it to new:texlive-extra-bin Then most Debian users would expect a package texlive-extra and this one would provide only the binaries. But in binextra there are not the binaries for some extra package, there are just extra binaries including the necessary support files, so complete packages. Probably texlive-extra and texlive-fontutils then? In any case, there's not much need to search for executables only packages. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Marvin Renich wrote: * Norbert Preining [EMAIL PROTECTED] [051128 11:20]: Dear all! Please comment, not only on the package naming, but also on the bin-to-source mapping. texlive-documentation-source57M Reasoning: The documenatation is actually in a specific language, so we use the respective language code. texlive-documentation-base texlive-base-doc texlive-documentation-bulgarian texlive-bg-doc texlive-documentation-czechslovak texlive-cs-doc texlive-documentation-dutch texlive-nl-doc texlive-documentation-english texlive-en-doc Best wishes Norbert In [1], Thiemo Seufer asserts that FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. I completely disagree. The point was about documentation and ukenglish. There is already precedent for using foo-doc-fr ordering of -doc-LANG: aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX, speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech), speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja. I saw no examples of -XX-doc with XX a language. apt-cache pkgnames |egrep '(^doc-|-doc-|-doc$|-docs$)' should catch most documentation packages, it shows the -doc suffix as the most popular one. The most notable exceptions to PKG-doc-XX were doc-linux-XX and doc-debian-XX, but in these cases, you can consider 'doc-linux' and 'doc-debian' to be the package names, rather than documentation for the linux or debian package. And, the -XX still came after. I think -doc-XX is more natural, and I don't see why in [2] Thiemo said that it made pattern matching harder. In fact, I think it is easier to find documentation for the foo package with foo-doc; then you can easily see what languages are available. If you know you are intersted in foo, then it is easy anyway (apt-cache pkgnames instead of search for the purpose of this discussion): apt-cache pkgnames | grep '^foo.*-doc$' If the idea is to remove some documentation from a space-constrained system, a -doc suffix would be easier. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Brian May wrote: Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes: Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Thiemo Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. Wrong, it makes break-ins harder. OTOH we don't put stickers with this car is locked on our cars. The quote above suggested a signed package is somehow better than an unsigned one, even when no improvements can be shown. But the only thing it reliably achieves in that case is to increase the exposure of the signing key. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Rafael Laboissiere wrote: [Please, Cc: to me, I am not currently subscribed to debian-devel.] * Thiemo Seufer [EMAIL PROTECTED] [2005-11-24 02:13]: Stephen Gran wrote: FWIW, Rafael, at first blush I have to say I agree with you. A maintainer address in Debian is just a way to get in touch with someone when something goes wrong with the package. If the mailing list is a good way to get in touch with people when those packages break, then it seems like a reasonable maintainer address. AFAIU the changelog entry is supposed to bear the name of the uploader, and thus can't be a mailing list. Policy 4.4 seems to support this: The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. [snip] I think that are two distinct concepts here. The first is the maintainer of the package, which should receive any e-mail messages related to the package. This name appears in the debian/changelog entry as well as in the Maintainer field. All correspondence must be directed to this entity (either a person or a mailing list). You apparently missed the quote above, which specifically talks about the person uploading. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: [snip] The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. [snip] I think that are two distinct concepts here. The first is the maintainer of the package, which should receive any e-mail messages related to the package. This name appears in the debian/changelog entry as well as in the Maintainer field. All correspondence must be directed to this entity (either a person or a mailing list). You apparently missed the quote above, which specifically talks about the person uploading. And we are in danger of allowing policy to drive practice, rather than vice versa. This rule is in policy for a long time now. If you want to have it changed, please propose a policy change instead of simply violating policy. The problem is, there are many packages currently being group maintained. These groups generally have some sort of group contact email address: grep-dctrl -n -s Maintainer '' /var/lib/apt/lists/*Sources | grep list | wc -l 843 I see exactly one false positive in that rather simple minded test, so the number of packages maintined in this way is rather high. So, the complaint was that this: Maintainer: s390 Build Daemon [EMAIL PROTECTED] Changed-By: Debian Octave Group [EMAIL PROTECTED] Doesn't have a real person behind it. When I look at the original, though, I see: Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] That looks fine. It seems to me policy is lagging behind actual practice here, and the right thing to do is add something to the effect that the maintainer field may also contain the contact information for the group maintaining a package if it is group maintianed, so long as the Changed-By: field in the original upload still contains the real name of the uploader. How could the autobuilder find out what the original Changed-By: content was? That is, short of reverse-engineering it from the signed .dsc, which may still choose the wrong key uid. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: [snip] And we are in danger of allowing policy to drive practice, rather than vice versa. The problem is, there are many packages currently being group maintained. These groups generally have some sort of group contact email address: grep-dctrl -n -s Maintainer '' /var/lib/apt/lists/*Sources | grep list | wc -l 843 I see exactly one false positive in that rather simple minded test, so the number of packages maintined in this way is rather high. Btw, about this simple-minded test: 299 of those are maintained by the Debian Install System Team, and nobody there felt compelled to put [EMAIL PROTECTED] in the changelog for whatever reason. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: This one time, at band camp, Thiemo Seufer said: Btw, about this simple-minded test: 299 of those are maintained by the Debian Install System Team, and nobody there felt compelled to put [EMAIL PROTECTED] in the changelog for whatever reason. What is the difference betwen this: Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] and this: Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] If you can show me where one is wrong and the other is right, I'll keep quiet. None is wrong or right. Both are contents of a .changes file, unavailable for a (re-)build from source. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: This one time, at band camp, Thiemo Seufer said: Stephen Gran wrote: This one time, at band camp, Thiemo Seufer said: Btw, about this simple-minded test: 299 of those are maintained by the Debian Install System Team, and nobody there felt compelled to put [EMAIL PROTECTED] in the changelog for whatever reason. What is the difference betwen this: Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] and this: Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] If you can show me where one is wrong and the other is right, I'll keep quiet. None is wrong or right. Both are contents of a .changes file, unavailable for a (re-)build from source. But the .dsc is. Which has no Changed-By: field. This stuff is easily traceable, if we want to. I can see the benefit of having the same name in the Maintainer field and in the changelog for some. A better one than Because I want to? Note that the Maintainer field is changed by buildds, their uploads count as (binary) NMU. I can see arguments against it, but none that make it an RC bug. Policy violations are RC by definition. We still have the original signatures on the dsc and changes to find out who uploaded it, if we're interested. Only by tracking down the .changes file of the original upload. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Isaac Clerencia wrote: On Thursday, 24 November 2005 22:03, Stephen Gran wrote: But the .dsc is. This stuff is easily traceable, if we want to. I can see the benefit of having the same name in the Maintainer field and in the changelog for some. I can see arguments against it, but none that make it an RC bug. We still have the original signatures on the dsc and changes to find out who uploaded it, if we're interested. My opinion is that the Changed-By: should reflect the people who has changed the package in the best possible way, and if that way is by putting a mailing list there I can't see any problem with it. This obviously isn't achieved when the Changed-By: differs between the initial upload and later (re-)builds. Also, the people who has changed the package from the archive's POV is the person who signed the upload. For the package's users the Changed-By: is rather irrelevant, they have Maintainer: encoded in the package (which stems from the control file, not from the changelog). BTW, I'm the person who recommended to Rafael that kind of changelog schema based on the practices of the Debian Qt/KDE team. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Isaac Clerencia wrote: On Thursday, 24 November 2005 22:36, Thiemo Seufer wrote: I can see arguments against it, but none that make it an RC bug. Policy violations are RC by definition. According to policy should's are not RC. Policy 5.6.4 has no should. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: This one time, at band camp, Rafael Laboissiere said: I am moving this discussion to debian-devel, since I am not sure we are really violating the Policy. Feel free to move it further to debian-policy, if you think it is appropriate. FWIW, Rafael, at first blush I have to say I agree with you. A maintainer address in Debian is just a way to get in touch with someone when something goes wrong with the package. If the mailing list is a good way to get in touch with people when those packages break, then it seems like a reasonable maintainer address. AFAIU the changelog entry is supposed to bear the name of the uploader, and thus can't be a mailing list. Policy 4.4 seems to support this: The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. Bastian, what's the rationale for the filings you've been doing? Do you really think a mailing list address, (where any and all correspondence about the packages is presumably archived and possibly even publicly accessible), is somehow worse than mailing a single person (who hopefully archives their package mail, but maybe not, and can almost be guaranteed not to have publicly browseable archives)? What are you hoping to do here? It provides a convenient way to find the person who did the final touches before an upload. The uses you are arguing are covered by the Maintainer: field. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Marc Haber wrote: [snip] How is it possible for you to claim something is more secure when you don't understand it well enough to say how it's different? Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Sorry, but that's a snake oil rationale. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-2.95 2.95.4.ds15-24 (mips all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Nov 2005 14:48:52 +0100 Source: gcc-2.95 Binary: cpp-2.95-doc libg++2.8.1.3-glibc2.2 g77-2.95-doc cpp-2.95 gobjc-2.95 libstdc++2.10-dbg gcc-2.95 gpc-2.95-doc chill-2.95 gpc-2.95 libg++2.8.1.3-dev libg++2.8.1.3-dbg libstdc++2.10-dev libstdc++2.10-glibc2.2 g++-2.95 g77-2.95 gcc-2.95-doc Architecture: mips all source Version: 2.95.4.ds15-24 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: chill-2.95 - The GNU CHILL compiler cpp-2.95 - The GNU C preprocessor cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp) g++-2.95 - The GNU C++ compiler g77-2.95 - The GNU Fortran 77 compiler g77-2.95-doc - Documentation for the GNU Fortran compiler (g77) gcc-2.95 - The GNU C compiler gcc-2.95-doc - Documentation for the GNU compilers (gcc, gobjc, g++) gobjc-2.95 - The GNU Objective-C compiler gpc-2.95 - The GNU Pascal compiler gpc-2.95-doc - Documentation for the GNU Pascal compiler (gpc) libg++2.8.1.3-dbg - The GNU C++ extension library - debugging files libg++2.8.1.3-dev - The GNU C++ extension library - development files libg++2.8.1.3-glibc2.2 - The GNU C++ extension library - runtime version libstdc++2.10-dbg - The GNU stdc++ library (debugging files) libstdc++2.10-dev - The GNU stdc++ library (development files) libstdc++2.10-glibc2.2 - The GNU stdc++ library Closes: 339703 Changes: gcc-2.95 (2.95.4.ds15-24) unstable; urgency=low . * Thiemo Seufer [EMAIL PROTECTED] . * Remove sparc-gcc4-fix.dpatch again, fix sparc FTBFS (Closes: #339703). Files: dab75cc4cf26a83907ca3b2d8ffd2dd6 1166 devel optional gcc-2.95_2.95.4.ds15-24.dsc ca0202d87825dcded686783166c50270 431012 devel optional gcc-2.95_2.95.4.ds15-24.diff.gz 63271cfb13687d9daedd6409d9a16254 69908 doc optional cpp-2.95-doc_2.95.4-24_all.deb 0280f6cdcab3e39ed0c3e5bf9d6625c5 315564 doc optional g77-2.95-doc_2.95.4-24_all.deb cb61b207e172162676b7177798cf0322 447516 doc optional gcc-2.95-doc_2.95.4-24_all.deb 9e1068555f632cac0178f8d0a77d1382 531052 doc optional gpc-2.95-doc_2.95.4-24_all.deb b96fad70168d5e261335eb724998773d 1143748 devel optional gcc-2.95_2.95.4-24_mips.deb 3b0392024e73537014d10e76def1d3bd 130938 interpreters optional cpp-2.95_2.95.4-24_mips.deb e9aace1e2ef14bc1da014bb680aec42a 1262752 devel optional g++-2.95_2.95.4-24_mips.deb b68355244861d42bacc4a9a67c1d0b15 1062890 devel optional gobjc-2.95_2.95.4-24_mips.deb ce491810b6c4ca9b14782d5bd4d5bf74 1352680 devel optional g77-2.95_2.95.4-24_mips.deb 1777f7ef4e8589ad1132b5bdfec1404d 1055738 devel extra chill-2.95_2.95.4-24_mips.deb 8035ae6b3208b5d62a4a7fd05a9e2000 370808 libs optional libstdc++2.10-glibc2.2_2.95.4-24_mips.deb 2397739c8cb1a7db389de6abe91452ae 317370 libdevel optional libstdc++2.10-dev_2.95.4-24_mips.deb 397380d0d7654d65b4067a70b2bdc642 334604 libdevel extra libstdc++2.10-dbg_2.95.4-24_mips.deb 4c612a375aa3055fc80b3bf89bd8bd7d 346826 libs optional libg++2.8.1.3-glibc2.2_2.95.4-24_mips.deb d9505a4a3cacbe4d43083edd03d621fd 341526 libdevel extra libg++2.8.1.3-dev_2.95.4-24_mips.deb f438e464aa3083b83dfa8e81d5481946 315032 libdevel extra libg++2.8.1.3-dbg_2.95.4-24_mips.deb 887393081cd2a5c26bf3c5c8637a4688 1695506 devel optional gpc-2.95_2.95.4-24_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDffFkXNuq0tFCNaARAkqEAJ93niyhqCiGawbvm/CNPCmVJM2bQACg21YJ MkN/+HrYd8tln1GQ6nh7x40= =TAke -END PGP SIGNATURE- Accepted: chill-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/chill-2.95_2.95.4-24_mips.deb cpp-2.95-doc_2.95.4-24_all.deb to pool/main/g/gcc-2.95/cpp-2.95-doc_2.95.4-24_all.deb cpp-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/cpp-2.95_2.95.4-24_mips.deb g++-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/g++-2.95_2.95.4-24_mips.deb g77-2.95-doc_2.95.4-24_all.deb to pool/main/g/gcc-2.95/g77-2.95-doc_2.95.4-24_all.deb g77-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/g77-2.95_2.95.4-24_mips.deb gcc-2.95-doc_2.95.4-24_all.deb to pool/main/g/gcc-2.95/gcc-2.95-doc_2.95.4-24_all.deb gcc-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/gcc-2.95_2.95.4-24_mips.deb gcc-2.95_2.95.4.ds15-24.diff.gz to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-24.diff.gz gcc-2.95_2.95.4.ds15-24.dsc to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-24.dsc gobjc-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/gobjc-2.95_2.95.4-24_mips.deb gpc-2.95-doc_2.95.4-24_all.deb to pool/main/g/gcc-2.95/gpc-2.95-doc_2.95.4-24_all.deb gpc-2.95_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/gpc-2.95_2.95.4-24_mips.deb libg++2.8.1.3-dbg_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dbg_2.95.4-24_mips.deb libg++2.8.1.3-dev_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dev_2.95.4-24_mips.deb libg++2.8.1.3-glibc2.2_2.95.4-24_mips.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-glibc2.2_2.95.4-24_mips.deb libstdc++2.10
Re: State of gcc 2.95 use in Debian unstable
Mark Brown wrote: On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? It was relatively common to find C++ code that wouldn't build with the new C++ front end in GCC 3.0. Is there one left today? (Does this mean it is dead upstream?) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Nikita V. Youshchenko wrote: Dave Carrigan wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs AFAICS this makes a point to have some (un-/little) maintained version of gcc-2.95 somewhere. It doesn't make a point to distribute it as part of an official etch release. - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. Apparently those packages weren't useful/important enough to bring them into Debian... Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Thiemo Seufer wrote: Nikita V. Youshchenko wrote: [snip] Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs AFAICS this makes a point to have some (un-/little) maintained version of gcc-2.95 somewhere. It doesn't make a point to distribute it as part of an official etch release. - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. Apparently those packages weren't useful/important enough to bring them into Debian... s/packages/programs which need gcc 2.95/, that is. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Moritz Muehlenhoff wrote: In linux.debian.devel, you wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? [..] Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. I agree. Plus, compilation of C code with 2.95 is typically twice as fast as 4.0. While 2.95 may be too buggy wrt C++, it's still useful for C. I wouldn't recommend to compile new code with 2.95 just because it is faster. It doesn't do standard C and misses many broken constructs which are caught by newer compilers. It may still have some use for regression tests, and for old code without a prospect of getting updated. I don't know how relevant those cases are for Debian. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Nikita V. Youshchenko wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. I have not yet faced a situation where newer binutils wont, work. #336022, as the latest example I saw. [snip] Apparently those packages weren't useful/important enough to bring them into Debian... Are debian compiler packages intended to compile debian packages only, or also to be used as compiler for non-debian tasks also? IMHO the latter, as long as it incurs no additional overhead. The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. By whom, and for what? So far I haven't heard a specific project's name. So why remove it? Is it worth to fix when it breaks again? (Currently it FTBFS on alpha, probably binutils-induced.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
State of gcc 2.95 use in Debian unstable
Hello All, while preparing an upload of gcc-2.95 which fixes its worst problems I wondered how many users of it are actually left. 9 packages in unstable still declare a build dependency on gcc-2.95 or g++-2.95, this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. The appended list gives a short overview of what needs to be done to achieve this. Please tell me if I missed or misunderstood something. Thiemo Unacknowledged NMU for one year, FTBFS for 200 days, either update or remove: Bao C. Ha [EMAIL PROTECTED] curselBuild-Depends: gcc-2.95 Sparc bootloader, needs update: Ben Collins [EMAIL PROTECTED] silo Build-Depends: gcc-2.95 Obsolete according to #debian-hurd, no request for removal filed yet: GNU Hurd Maintainers bug-hurd@gnu.org gnumach1 Build-Depends: gcc-2.95 Replacement (2.6 Kernel) in the works, should be removed once 2.6 is stable enough: Christian T. Steigies [EMAIL PROTECTED] kernel-image-2.4.27-m68k Build-Depends: gcc-2.95 kernel-patch-2.4.27-m68k Build-Depends-Indep: gcc-2.95 Openfirmware emulator/replacement(?), powerpc specific, needs update: Guillem Jover [EMAIL PROTECTED] openhackware Build-Depends-Indep: gcc-2.95 Unacknowledged NMU for one year, either update or remove: Ben Pfaff [EMAIL PROTECTED] gcccheckerBuild-Depends: gcc-2.95 Erraneous build dependency, should get fixed in the next upload, #336564: Robin Verduijn [EMAIL PROTECTED] mcvs Build-Depends: gcc-2.95 [mips mipsel] Malloc debugging, #285685 suggests it is broken for 300 days now, either update or remove: Steve M. Robbins [EMAIL PROTECTED] ccmalloc Build-Depends: g++-2.95 [alpha arm i386 m68k mips mipsel powerpc s390 sparc] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Steve M. Robbins wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: Malloc debugging, #285685 suggests it is broken for 300 days now, either update or remove: Steve M. Robbins [EMAIL PROTECTED] ccmalloc Build-Depends: g++-2.95 [alpha arm i386 m68k mips mipsel powerpc s390 sparc] It's not broken. That bug is there to remind me to improve the package dependencies. Ccmalloc isn't dependent on GCC 2.95 per se. It's just that we build a stub for each supported version of g++. So if 2.95 goes away, I'll just remove that build-dep. No problem. Ok, I'll record it as Build-Deps on g++-2.95 only to support gcc-2.95. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Ben Pfaff wrote: Thiemo Seufer [EMAIL PROTECTED] writes: Unacknowledged NMU for one year, either update or remove: Ben Pfaff [EMAIL PROTECTED] gcccheckerBuild-Depends: gcc-2.95 I recently filed a request to have this package removed. It is not maintained upstream and valgrind is a better replacement. JFTR, request for removal was #337558. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-2.95 2.95.4.ds15-23 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 14 Nov 2005 19:44:31 +0100 Source: gcc-2.95 Binary: cpp-2.95-doc libg++2.8.1.3-glibc2.2 g77-2.95-doc cpp-2.95 gobjc-2.95 libstdc++2.10-dbg gcc-2.95 gpc-2.95-doc chill-2.95 gpc-2.95 libg++2.8.1.3-dev libg++2.8.1.3-dbg libstdc++2.10-dev libstdc++2.10-glibc2.2 g++-2.95 g77-2.95 gcc-2.95-doc Architecture: source i386 all Version: 2.95.4.ds15-23 Distribution: unstable Urgency: low Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: chill-2.95 - The GNU CHILL compiler cpp-2.95 - The GNU C preprocessor cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp) g++-2.95 - The GNU C++ compiler g77-2.95 - The GNU Fortran 77 compiler g77-2.95-doc - Documentation for the GNU Fortran compiler (g77) gcc-2.95 - The GNU C compiler gcc-2.95-doc - Documentation for the GNU compilers (gcc, gobjc, g++) gobjc-2.95 - The GNU Objective-C compiler gpc-2.95 - The GNU Pascal compiler gpc-2.95-doc - Documentation for the GNU Pascal compiler (gpc) libg++2.8.1.3-dbg - The GNU C++ extension library - debugging files libg++2.8.1.3-dev - The GNU C++ extension library - development files libg++2.8.1.3-glibc2.2 - The GNU C++ extension library - runtime version libstdc++2.10-dbg - The GNU stdc++ library (debugging files) libstdc++2.10-dev - The GNU stdc++ library (development files) libstdc++2.10-glibc2.2 - The GNU stdc++ library Changes: gcc-2.95 (2.95.4.ds15-23) unstable; urgency=low . * Thiemo Seufer [EMAIL PROTECTED] . * Acknowledge NMU. * Use gcc 4 fix on all architectures. * Add myself to Uploaders. . * Matthias Klose [EMAIL PROTECTED] . * Add build dependency on dpkg-dev (= 1.13.9). Files: c5a595aec8468142941dd59d9759ebba 1166 devel optional gcc-2.95_2.95.4.ds15-23.dsc 485ca3c5eac4d6c95947262ca256cdfe 430096 devel optional gcc-2.95_2.95.4.ds15-23.diff.gz f124d49997c62df616ba558b51682a89 69852 doc optional cpp-2.95-doc_2.95.4-23_all.deb 86582ff452e9a9b8e1e291352a20a606 315528 doc optional g77-2.95-doc_2.95.4-23_all.deb a77585849f9b5262bdff12c409508a77 447484 doc optional gcc-2.95-doc_2.95.4-23_all.deb e72640c7e2ee8ba803b6d065c352c2ac 530876 doc optional gpc-2.95-doc_2.95.4-23_all.deb 29d00e22ef62c2acdd91c5c8a1dcd41f 948512 devel optional gcc-2.95_2.95.4-23_i386.deb 6afca7ae015dcb677c57d507ff07e9ab 115910 interpreters optional cpp-2.95_2.95.4-23_i386.deb c4ad447f3115bd9e15024b1ae0bf65d2 1029066 devel optional g++-2.95_2.95.4-23_i386.deb b8ec0866599e8576e0b5899b068c59b3 857574 devel optional gobjc-2.95_2.95.4-23_i386.deb 6d32e39eea525bbf58d3dc772422badc 1119588 devel optional g77-2.95_2.95.4-23_i386.deb d6841d3e365b21bf4abba53a2561d5e3 865150 devel extra chill-2.95_2.95.4-23_i386.deb dfeb604a635a19af671fe24c2984e03f 329340 libs optional libstdc++2.10-glibc2.2_2.95.4-23_i386.deb fd45e3363759c2cfa3bb31666126848d 296948 libdevel optional libstdc++2.10-dev_2.95.4-23_i386.deb 8d3f085f3e91bc65119b527b669601f2 292730 libdevel extra libstdc++2.10-dbg_2.95.4-23_i386.deb ff4c7751717f3eabbf01693ece63eeb8 315724 libs optional libg++2.8.1.3-glibc2.2_2.95.4-23_i386.deb 5165f07749e06f6df168cd417b6fb8f2 314922 libdevel extra libg++2.8.1.3-dev_2.95.4-23_i386.deb 8cb4d1b8d506772c7d8726416e08bf6c 284088 libdevel extra libg++2.8.1.3-dbg_2.95.4-23_i386.deb a481d4bec6ec616d7a547a0ccc5c8842 1400992 devel optional gpc-2.95_2.95.4-23_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDep5aStlRaw+TLJwRAg/oAKCleunM7dv1uHBxh6IYKOIdVcqslgCeL50o FGqKPculLjbq/cpm1XQww3g= =76sL -END PGP SIGNATURE- Accepted: chill-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/chill-2.95_2.95.4-23_i386.deb cpp-2.95-doc_2.95.4-23_all.deb to pool/main/g/gcc-2.95/cpp-2.95-doc_2.95.4-23_all.deb cpp-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/cpp-2.95_2.95.4-23_i386.deb g++-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/g++-2.95_2.95.4-23_i386.deb g77-2.95-doc_2.95.4-23_all.deb to pool/main/g/gcc-2.95/g77-2.95-doc_2.95.4-23_all.deb g77-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/g77-2.95_2.95.4-23_i386.deb gcc-2.95-doc_2.95.4-23_all.deb to pool/main/g/gcc-2.95/gcc-2.95-doc_2.95.4-23_all.deb gcc-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/gcc-2.95_2.95.4-23_i386.deb gcc-2.95_2.95.4.ds15-23.diff.gz to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-23.diff.gz gcc-2.95_2.95.4.ds15-23.dsc to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-23.dsc gobjc-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/gobjc-2.95_2.95.4-23_i386.deb gpc-2.95-doc_2.95.4-23_all.deb to pool/main/g/gcc-2.95/gpc-2.95-doc_2.95.4-23_all.deb gpc-2.95_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/gpc-2.95_2.95.4-23_i386.deb libg++2.8.1.3-dbg_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dbg_2.95.4-23_i386.deb libg++2.8.1.3-dev_2.95.4-23_i386.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dev_2.95.4-23_i386.deb
Accepted linux-patch-2.6-mips 2.6.12-3 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 05 Nov 2005 23:14:46 +0100 Source: linux-patch-2.6-mips Binary: linux-headers-2.6.12-1-sb1-swarm-bn linux-headers-2.6.12-1-r10k-ip27 linux-image-2.6.12-1-r4k-ip22 linux-headers-2.6-r10k-ip30 linux-image-2.6-r10k-ip27 linux-image-r5k-ip32 linux-image-2.6-r5k-ip32 linux-image-2.6.12-1-r10k-ip27 linux-headers-2.6-sb1-swarm-bn linux-image-2.6-r4k-ip22 linux-image-2.6-r10k-ip30 linux-headers-2.6.12-1-r10k-ip30 linux-image-2.6.12-1-r10k-ip30 linux-image-2.6-sb1-swarm-bn mips-tools linux-headers-2.6-r4k-ip22 linux-image-2.6.12-1-r5k-ip32 linux-headers-2.6-r5k-ip32 linux-image-2.6.12-1-sb1-swarm-bn linux-image-sb1-swarm-bn linux-headers-2.6.12-1-mips linux-headers-2.6.12-1 linux-headers-2.6.12-1-r4k-ip22 linux-image-r10k-ip27 linux-headers-2.6.12-1-r5k-ip32 linux-headers-2.6-r10k-ip27 linux-image-r10k-ip30 linux-image-r4k-ip22 Architecture: source mips Version: 2.6.12-3 Distribution: experimental Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: linux-headers-2.6-r10k-ip27 - Header files for Linux kernel 2.6 on SGI Origin linux-headers-2.6-r10k-ip30 - Header files for Linux kernel 2.6 on SGI Octane linux-headers-2.6-r4k-ip22 - Header files for Linux kernel 2.6 on SGI Indy/Indigo2 linux-headers-2.6-r5k-ip32 - Header files for Linux kernel 2.6 on SGI O2 with R5x00 CPU linux-headers-2.6-sb1-swarm-bn - Header files for Linux kernel 2.6 on SWARM linux-headers-2.6.12-1 - Common header files for mips/mipsel Linux kernel 2.6.12 linux-headers-2.6.12-1-r10k-ip27 - Header files for Linux kernel 2.6.12 on SGI Origin linux-headers-2.6.12-1-r10k-ip30 - Header files for Linux kernel 2.6.12 on SGI Octane linux-headers-2.6.12-1-r4k-ip22 - Header files for Linux kernel 2.6.12 on SGI Indy/Indigo2 linux-headers-2.6.12-1-r5k-ip32 - Header files for Linux kernel 2.6.12 on SGI O2 with R5x00 CPU linux-headers-2.6.12-1-sb1-swarm-bn - Header files for Linux kernel 2.6.12 on SWARM linux-image-2.6-r10k-ip27 - Linux kernel 2.6 image on SGI Origin linux-image-2.6-r10k-ip30 - Linux kernel 2.6 image on SGI Octane linux-image-2.6-r4k-ip22 - Linux kernel 2.6 image on SGI Indy/Indigo2 linux-image-2.6-r5k-ip32 - Linux kernel 2.6 image on SGI O2 with R5x00 CPU linux-image-2.6-sb1-swarm-bn - Linux kernel 2.6 image on SWARM linux-image-2.6.12-1-r10k-ip27 - Linux kernel 2.6.12 image on SGI Origin linux-image-2.6.12-1-r10k-ip30 - Linux kernel 2.6.12 image on SGI Octane linux-image-2.6.12-1-r4k-ip22 - Linux kernel 2.6.12 image on SGI Indy/Indigo2 linux-image-2.6.12-1-r5k-ip32 - Linux kernel 2.6.12 image on SGI O2 with R5x00 CPU linux-image-2.6.12-1-sb1-swarm-bn - Linux kernel 2.6.12 image on SWARM linux-image-r10k-ip27 - Linux kernel image on SGI Origin linux-image-r10k-ip30 - Linux kernel image on SGI Octane linux-image-r4k-ip22 - Linux kernel image on SGI Indy/Indigo2 linux-image-r5k-ip32 - Linux kernel image on SGI O2 with R5x00 CPU linux-image-sb1-swarm-bn - Linux kernel image on SWARM mips-tools - MIPS specific kernel tools Closes: 335967 Changes: linux-patch-2.6-mips (2.6.12-3) experimental; urgency=low . * mips-tools lacked the elf2ecoff binary. (Closes: #335967) * Switch the little endian SWARM also to 32bit for now. Files: edab7e0a0319b1670eac6c3fb6a5e8f8 1402 devel optional linux-patch-2.6-mips_2.6.12-3.dsc 78b6c31befce1007ea40a8d0f8042197 615126 devel optional linux-patch-2.6-mips_2.6.12-3.tar.gz 12debd6e44e929f48bd2b88efae081ff 2014 devel optional linux-headers-2.6-r4k-ip22_2.6.12-3_mips.deb 9ea2c050eb1d74fad2e1fe3e8f27aefe 1998 base optional linux-image-2.6-r4k-ip22_2.6.12-3_mips.deb 2aee726d86d3fac7681fad8c18a48dd7 1982 base optional linux-image-r4k-ip22_2.6.12-3_mips.deb ae1b85d630080e2be5a260f7757a 1998 devel optional linux-headers-2.6-r10k-ip27_2.6.12-3_mips.deb 72b6e5f2b55852ef6e2fc5f9113795b5 1978 base optional linux-image-2.6-r10k-ip27_2.6.12-3_mips.deb 8eb38a9f2c372b583fa65c1944134c99 1968 base optional linux-image-r10k-ip27_2.6.12-3_mips.deb 8f1ee0fcf5bc169be9389be3d2c435e5 1992 devel optional linux-headers-2.6-r10k-ip30_2.6.12-3_mips.deb d88d8d7d7cf1dc3faf84608debc6e13b 1978 base optional linux-image-2.6-r10k-ip30_2.6.12-3_mips.deb f3bc71f0960f016ce7d3b0b7daceadfc 1970 base optional linux-image-r10k-ip30_2.6.12-3_mips.deb 865b5761f749eb9885d38f5b20a50b7b 2018 devel optional linux-headers-2.6-r5k-ip32_2.6.12-3_mips.deb d44e171cf5f55bd4a25adfee328b337e 1996 base optional linux-image-2.6-r5k-ip32_2.6.12-3_mips.deb 366c86121edda6c976e88a86d6539032 1982 base optional linux-image-r5k-ip32_2.6.12-3_mips.deb 26aad22c7c703f3f87500c529ace6727 1998 devel optional linux-headers-2.6-sb1-swarm-bn_2.6.12-3_mips.deb 8bfd2e6a9117941c6739978a76a76990 1978 base optional linux-image-2.6-sb1-swarm-bn_2.6.12-3_mips.deb 3a4057ee39f879937b4492a7a2818fe4 1968 base optional linux-image-sb1-swarm-bn_2.6.12-3_mips.deb
Re: ncpfs_2.2.6-2_mipsel: FTBFS: internal compiler error: Floating point exception
Aníbal Monsalve Salazar wrote: On Mon, Nov 07, 2005 at 10:01:26AM +1100, Anibal Monsalve Salazar wrote: Package: ncpfs Severity: serious Version: 2.2.6-2 Tags: sid Justification: fails to build from source There was an error while trying to autobuild your package: Automatic build of ncpfs_2.2.6-2 on rem by sbuild/mipsel 69 Build started at 20051028-2357 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper, libpam0g-dev, gettext [...] ncplib.c: In function 'ipx_make_reachable_rip': ncplib.c:595: internal compiler error: Floating point exception Bug#337864. Is this a well-known bug in gcc-4.0? Yes, #336167, patch available, fixed upstream. Should I build-depend on gcc 3.4 [mip mipsel]? Not if it isn't urgent. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: more tolerant licensing for Debian infrastructure
Jaldhar H. Vyas wrote: [was Re: Debian based GNU/Solaris: pilot program] On Thu, 3 Nov 2005, Matthew Garrett wrote: Remember that dpkg is GPLed, so there's a slightly awkward bootstrapping issue. This reminds me of an issue which I feel needs change but I've never felt worked up enough to do anything about. Why do programs written specifically for Debian such as dpkg or apt, have a license which is not compatible with some other DFSG-compliant licenses? Because the authors chose so. I understand we like the GPL but the DFSG is laxer in some respects. And the spirit of Debian is the DFSG not the GPL. I submit anything written specifically for the Debian Project should either have some more permissive yet DFSG-compliant license or at the most GPL + an exemption for linking to other DFSG compliant software. Is there any source with a copyright assignment for The Debian Project? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: more tolerant licensing for Debian infrastructure
Jaldhar H. Vyas wrote: On Thu, 3 Nov 2005, Thiemo Seufer wrote: Why do programs written specifically for Debian such as dpkg or apt, have a license which is not compatible with some other DFSG-compliant licenses? Because the authors chose so. Obviously. But the question was why they chose to do so when it goes against the spirit of the DFSG? You really want to claim the GPL violates the spirit of the DFSG? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-patch-2.6-mips 2.6.12-2 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Sep 2005 04:29:47 +0200 Source: linux-patch-2.6-mips Binary: linux-headers-2.6.12-1-sb1-swarm-bn linux-headers-2.6.12-1-r10k-ip27 linux-image-2.6.12-1-r4k-ip22 linux-headers-2.6-r10k-ip30 linux-image-2.6-r10k-ip27 linux-image-r5k-ip32 linux-image-2.6-r5k-ip32 linux-image-2.6.12-1-r10k-ip27 linux-headers-2.6-sb1-swarm-bn linux-image-2.6-r4k-ip22 linux-image-2.6-r10k-ip30 linux-headers-2.6.12-1-r10k-ip30 linux-image-2.6.12-1-r10k-ip30 linux-image-2.6-sb1-swarm-bn mips-tools linux-headers-2.6-r4k-ip22 linux-image-2.6.12-1-r5k-ip32 linux-headers-2.6-r5k-ip32 linux-image-2.6.12-1-sb1-swarm-bn linux-image-sb1-swarm-bn linux-headers-2.6.12-1-mips linux-headers-2.6.12-1 linux-headers-2.6.12-1-r4k-ip22 linux-image-r10k-ip27 linux-headers-2.6.12-1-r5k-ip32 linux-headers-2.6-r10k-ip27 linux-image-r10k-ip30 linux-image-r4k-ip22 Architecture: source mips Version: 2.6.12-2 Distribution: experimental Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: linux-headers-2.6-r10k-ip27 - Header files for Linux kernel 2.6 on SGI Origin linux-headers-2.6-r10k-ip30 - Header files for Linux kernel 2.6 on SGI Octane linux-headers-2.6-r4k-ip22 - Header files for Linux kernel 2.6 on SGI Indy/Indigo2 linux-headers-2.6-r5k-ip32 - Header files for Linux kernel 2.6 on SGI O2 with R5x00 CPU linux-headers-2.6-sb1-swarm-bn - Header files for Linux kernel 2.6 on SWARM linux-headers-2.6.12-1 - Common header files for mips/mipsel Linux kernel 2.6.12 linux-headers-2.6.12-1-r10k-ip27 - Header files for Linux kernel 2.6.12 on SGI Origin linux-headers-2.6.12-1-r10k-ip30 - Header files for Linux kernel 2.6.12 on SGI Octane linux-headers-2.6.12-1-r4k-ip22 - Header files for Linux kernel 2.6.12 on SGI Indy/Indigo2 linux-headers-2.6.12-1-r5k-ip32 - Header files for Linux kernel 2.6.12 on SGI O2 with R5x00 CPU linux-headers-2.6.12-1-sb1-swarm-bn - Header files for Linux kernel 2.6.12 on SWARM linux-image-2.6-r10k-ip27 - Linux kernel 2.6 image on SGI Origin linux-image-2.6-r10k-ip30 - Linux kernel 2.6 image on SGI Octane linux-image-2.6-r4k-ip22 - Linux kernel 2.6 image on SGI Indy/Indigo2 linux-image-2.6-r5k-ip32 - Linux kernel 2.6 image on SGI O2 with R5x00 CPU linux-image-2.6-sb1-swarm-bn - Linux kernel 2.6 image on SWARM linux-image-2.6.12-1-r10k-ip27 - Linux kernel 2.6.12 image on SGI Origin linux-image-2.6.12-1-r10k-ip30 - Linux kernel 2.6.12 image on SGI Octane linux-image-2.6.12-1-r4k-ip22 - Linux kernel 2.6.12 image on SGI Indy/Indigo2 linux-image-2.6.12-1-r5k-ip32 - Linux kernel 2.6.12 image on SGI O2 with R5x00 CPU linux-image-2.6.12-1-sb1-swarm-bn - Linux kernel 2.6.12 image on SWARM linux-image-r10k-ip27 - Linux kernel image on SGI Origin linux-image-r10k-ip30 - Linux kernel image on SGI Octane linux-image-r4k-ip22 - Linux kernel image on SGI Indy/Indigo2 linux-image-r5k-ip32 - Linux kernel image on SGI O2 with R5x00 CPU linux-image-sb1-swarm-bn - Linux kernel image on SWARM mips-tools - MIPS specific kernel tools Changes: linux-patch-2.6-mips (2.6.12-2) experimental; urgency=low . * Enable ll/sc workaround for Cobalt. * Fix package build for non-mips packages. * Add missing addrspace defines for SWARM. * Don't miss pending signals returning to user mode after signal processing. * Disable advansys scsi because it references ISA DMA. * Build in modules which have troubles with unexported functions. * Fix broken network checksumming. * Use a 32bit SWARM kernel, 64bit has module loading problems. * Disable cobalt for now, it doesn't boot. Files: 0d54108f82f082cc36ce141e4eb7def1 1402 devel optional linux-patch-2.6-mips_2.6.12-2.dsc 18d80381ef76600f55a872bd80d7e894 596007 devel optional linux-patch-2.6-mips_2.6.12-2.tar.gz a733f5e962aa80fde58381617a1addea 1922 devel optional linux-headers-2.6-r4k-ip22_2.6.12-2_mips.deb 1626f2093c00f2e3805a65a4d8337803 1898 base optional linux-image-2.6-r4k-ip22_2.6.12-2_mips.deb d3ca6ba25a63892bca2f2ce3a4c48a0e 1888 base optional linux-image-r4k-ip22_2.6.12-2_mips.deb 25424f012634a4aa64801bafae555adf 1898 devel optional linux-headers-2.6-r10k-ip27_2.6.12-2_mips.deb ccdbe1620ce002dc19722b529e50d31a 1880 base optional linux-image-2.6-r10k-ip27_2.6.12-2_mips.deb 7045a42d7cbb39e33df5c955d1de684a 1870 base optional linux-image-r10k-ip27_2.6.12-2_mips.deb ca1566dd074cce9abeaabe0c5c42ac68 1896 devel optional linux-headers-2.6-r10k-ip30_2.6.12-2_mips.deb 323afdee0f78717119300bcb3366f179 1880 base optional linux-image-2.6-r10k-ip30_2.6.12-2_mips.deb 98e724c1c8a7a91fe315eb055c07b4a3 1868 base optional linux-image-r10k-ip30_2.6.12-2_mips.deb ec109f3669dddb74fe12d175c4fbdb99 1920 devel optional linux-headers-2.6-r5k-ip32_2.6.12-2_mips.deb 9da9cffbf6a387ba6d80dfb94435db19 1900 base optional linux-image-2.6-r5k-ip32_2.6.12-2_mips.deb 158ab5da13c8c293b35ee71db020e8d5 1886 base optional linux-image
Accepted kernel-patch-2.4.27-mips 2.4.27-11.040815-2 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 07 Oct 2005 00:21:12 +0200 Source: kernel-patch-2.4.27-mips Binary: kernel-headers-2.4.27 kernel-image-2.4.27-sb1-swarm-bn mips-tools kernel-image-2.4.27-r4k-kn04 kernel-image-2.4.27-r4k-ip22 kernel-image-2.4.27-xxs1500 kernel-image-2.4.27-r5k-lasat kernel-image-2.4.27-r3k-kn02 kernel-image-2.4.27-r5k-cobalt kernel-image-2.4.27-r5k-ip22 Architecture: source mips Version: 2.4.27-11.040815-2 Distribution: unstable Urgency: medium Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: kernel-headers-2.4.27 - Header files related to a specific Linux kernel kernel-image-2.4.27-r4k-ip22 - Linux kernel binary image kernel-image-2.4.27-r5k-ip22 - Linux kernel binary image kernel-image-2.4.27-sb1-swarm-bn - Linux kernel binary image mips-tools - mips specific kernel tools Changes: kernel-patch-2.4.27-mips (2.4.27-11.040815-2) unstable; urgency=medium . * Enable built-in cramfs support for all kernels, needed for d-i. Files: be79500b736f1e589e1d51ad85ee7d9b 1051 devel optional kernel-patch-2.4.27-mips_2.4.27-11.040815-2.dsc cf6b9d0f3745b4336039120af2efd625 307878 devel optional kernel-patch-2.4.27-mips_2.4.27-11.040815-2.tar.gz 407ab8416c8953181eea52b9a87909b8 18166 devel optional mips-tools_2.4.27-11.040815-2_mips.deb a10cbe56e0adefa8c50d223eebe11aae 7206898 base optional kernel-image-2.4.27-sb1-swarm-bn_2.4.27-11.040815-2_mips.deb c6a4fcf267b0feecb6eb582dd46c9883 3866602 base optional kernel-image-2.4.27-r4k-ip22_2.4.27-11.040815-2_mips.deb e97c3c7b705fe68a4aedb13e0c361f87 3869486 base optional kernel-image-2.4.27-r5k-ip22_2.4.27-11.040815-2_mips.deb 0ba308de55b583dc8ff0d9621b987b9d 4913106 devel optional kernel-headers-2.4.27_2.4.27-11.040815-2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDRscHXNuq0tFCNaARAsVqAKC1gOC3z61TRXBOVdcUPzOkXvlvvgCgyFXz TBGc49dOLs7P8uIUCZgS1ik= =Ig7c -END PGP SIGNATURE- Accepted: kernel-headers-2.4.27_2.4.27-11.040815-2_mips.deb to pool/main/k/kernel-patch-2.4.27-mips/kernel-headers-2.4.27_2.4.27-11.040815-2_mips.deb kernel-image-2.4.27-r4k-ip22_2.4.27-11.040815-2_mips.deb to pool/main/k/kernel-patch-2.4.27-mips/kernel-image-2.4.27-r4k-ip22_2.4.27-11.040815-2_mips.deb kernel-image-2.4.27-r5k-ip22_2.4.27-11.040815-2_mips.deb to pool/main/k/kernel-patch-2.4.27-mips/kernel-image-2.4.27-r5k-ip22_2.4.27-11.040815-2_mips.deb kernel-image-2.4.27-sb1-swarm-bn_2.4.27-11.040815-2_mips.deb to pool/main/k/kernel-patch-2.4.27-mips/kernel-image-2.4.27-sb1-swarm-bn_2.4.27-11.040815-2_mips.deb kernel-patch-2.4.27-mips_2.4.27-11.040815-2.dsc to pool/main/k/kernel-patch-2.4.27-mips/kernel-patch-2.4.27-mips_2.4.27-11.040815-2.dsc kernel-patch-2.4.27-mips_2.4.27-11.040815-2.tar.gz to pool/main/k/kernel-patch-2.4.27-mips/kernel-patch-2.4.27-mips_2.4.27-11.040815-2.tar.gz mips-tools_2.4.27-11.040815-2_mips.deb to pool/main/k/kernel-patch-2.4.27-mips/mips-tools_2.4.27-11.040815-2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What do you do if a package is built and not uploaded?
Petter Reinholdtsen wrote:
[Nathanael Nerode]
I'm thinking of python2.1, which is a key element in some testing
transitions.
It's out of date on alpha, mips, mipsel, and powerpc -- *yet the buildd logs
indicate successful builds on all of them on August 30*. I have already
emailed debian-mips@lists.debian.org, and the listed maintainers of the
relevant alpha and powerpc buildds.
What to do? Well, you curse the lack of transparecy in the buildd
maintainence process, and hope the problem will be fixed soon. I've
not been able to find any other procedure that work better that this
simple approach. I've tried to emailing Ryan Murray using the address
listed at the bottom of all the buildd web pages, but do not remember
if I ever got a reply. I've tried emailing the porters list, but most
often this is either met with silence or I get a reply saying that the
buildd admins for the given arhc are not reading the porters list.
I've tried asking on IRC, and actually once got feedback from someone
claiming to be the buildd maintainer of the arch in question (no way
to verify this, have not found the list of maintainers), and some
times one of the porters are willing to do a manual build.
Mailing {alpha,mips,[EMAIL PROTECTED] is my best guess. There
is usually no reply, but from some cases I conclude the mailboxes are
read. I don't know if those addresses are documented anywhere.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
W. Borgert wrote: On Mon, Sep 19, 2005 at 10:45:26AM +0930, Debonaras Project Lead wrote: The Debonaras project (http://www.debonaras.org) is a group of Linux developers who have created the beginnings of a big-endian ARM (armeb) port of Debian. We have built 2500+ stable packages so far (see http://ftp.debonaras.org). Just a completely uninformed question: Wasn't the -el (endian little) in mipsel a pun on the wrong endianess? I don't think so. If so, shouldn't it be armBE, because it's the right endianess? -EL/-EB/-el/-eb are commonly used gcc switches to select endianness. OTOH, the host configuration uses arm*b-* or arm*be-* for big endian ARM, so a case could be made for both ways. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
Simon Richter wrote: Hi, Wrong is endian little that knows everyone but. Thgir yltcaxe! eurtub ,iw ta llobynt ydknih fo ehtlihcnerd? ac si tIirc delldne elpp ssennaire a rof-: .nosa ) Thiemo signature.asc Description: Digital signature
Accepted arcboot 0.3.8.7 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 17 Sep 2005 20:15:35 +0200 Source: arcboot Binary: arcboot tip22 Architecture: source mips Version: 0.3.8.7 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: arcboot- Bootloader for SGI/MIPS IP22 and IP32 machines tip22 - Tftp boot image builder for SGI/MIPS IP22 and IP32 machines Closes: 313114 317662 Changes: arcboot (0.3.8.7) unstable; urgency=low . * Add vietnamese translation, thanks Clytie Siddall (Closes: #313114). * Add czech translation, thanks Miroslav Kure (Closes: #317662). * Switch from the local e2fslib to the up-to-date libext2fs-nopic.a in Debian, but don't delete the old version for now. * Avoid inclusion of kernel headers. Files: 2c0a67eafcc6b7288d61fad52cac6d00 557 admin optional arcboot_0.3.8.7.dsc 188e2720f305a8bf3835775eaa103e75 741070 admin optional arcboot_0.3.8.7.tar.gz d76de79a0d4ae728e09211654d830537 76562 admin optional arcboot_0.3.8.7_mips.deb 4f11079a9c42e54b996253ca26f07163 20294 admin optional tip22_0.3.8.7_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDLF6sXNuq0tFCNaARAhmNAKCggU9LazetcWFmVV3thSZgnkbXbgCggLlb L9PZsfEbOe0lI5aBNhhs17w= =i3q0 -END PGP SIGNATURE- Accepted: arcboot_0.3.8.7.dsc to pool/main/a/arcboot/arcboot_0.3.8.7.dsc arcboot_0.3.8.7.tar.gz to pool/main/a/arcboot/arcboot_0.3.8.7.tar.gz arcboot_0.3.8.7_mips.deb to pool/main/a/arcboot/arcboot_0.3.8.7_mips.deb tip22_0.3.8.7_mips.deb to pool/main/a/arcboot/tip22_0.3.8.7_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-patch-2.6-mips 2.6.12-1 (source mips)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 12 Sep 2005 16:31:30 +0200 Source: linux-patch-2.6-mips Binary: linux-headers-2.6.12-1-sb1-swarm-bn linux-headers-2.6.12-1-r10k-ip27 linux-headers-2.6-r10k-ip30 linux-image-2.6-r10k-ip27 linux-image-2.6.12-1-r4k-ip22 linux-image-r5k-ip32 linux-image-2.6-r5k-ip32 linux-image-2.6.12-1-r10k-ip27 linux-headers-2.6-sb1-swarm-bn linux-image-2.6-r10k-ip30 linux-image-2.6-r4k-ip22 linux-headers-2.6.12-1-r10k-ip30 linux-image-2.6.12-1-r10k-ip30 linux-image-2.6-sb1-swarm-bn mips-tools linux-headers-2.6-r4k-ip22 linux-image-2.6.12-1-r5k-ip32 linux-headers-2.6-r5k-ip32 linux-image-2.6.12-1-sb1-swarm-bn linux-image-sb1-swarm-bn linux-headers-2.6.12-1-r4k-ip22 linux-headers-2.6.12-1-mips linux-headers-2.6.12-1 linux-image-r10k-ip27 linux-headers-2.6.12-1-r5k-ip32 linux-image-r10k-ip30 linux-headers-2.6-r10k-ip27 linux-image-r4k-ip22 Architecture: source mips Version: 2.6.12-1 Distribution: experimental Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Thiemo Seufer [EMAIL PROTECTED] Description: linux-headers-2.6-r10k-ip27 - Header files for Linux kernel 2.6 on SGI Origin linux-headers-2.6-r10k-ip30 - Header files for Linux kernel 2.6 on SGI Octane linux-headers-2.6-r4k-ip22 - Header files for Linux kernel 2.6 on SGI Indy/Indigo2 linux-headers-2.6-r5k-ip32 - Header files for Linux kernel 2.6 on SGI O2 with R5x00 CPU linux-headers-2.6-sb1-swarm-bn - Header files for Linux kernel 2.6 on SWARM linux-headers-2.6.12-1 - Common header files for mips Linux kernel 2.6.12 linux-headers-2.6.12-1-r10k-ip27 - Header files for Linux kernel 2.6.12 on SGI Origin linux-headers-2.6.12-1-r10k-ip30 - Header files for Linux kernel 2.6.12 on SGI Octane linux-headers-2.6.12-1-r4k-ip22 - Header files for Linux kernel 2.6.12 on SGI Indy/Indigo2 linux-headers-2.6.12-1-r5k-ip32 - Header files for Linux kernel 2.6.12 on SGI O2 with R5x00 CPU linux-headers-2.6.12-1-sb1-swarm-bn - Header files for Linux kernel 2.6.12 on SWARM linux-image-2.6-r10k-ip27 - Linux kernel 2.6 image on SGI Origin linux-image-2.6-r10k-ip30 - Linux kernel 2.6 image on SGI Octane linux-image-2.6-r4k-ip22 - Linux kernel 2.6 image on SGI Indy/Indigo2 linux-image-2.6-r5k-ip32 - Linux kernel 2.6 image on SGI O2 with R5x00 CPU linux-image-2.6-sb1-swarm-bn - Linux kernel 2.6 image on SWARM linux-image-2.6.12-1-r10k-ip27 - Linux kernel 2.6.12 image on SGI Origin linux-image-2.6.12-1-r10k-ip30 - Linux kernel 2.6.12 image on SGI Octane linux-image-2.6.12-1-r4k-ip22 - Linux kernel 2.6.12 image on SGI Indy/Indigo2 linux-image-2.6.12-1-r5k-ip32 - Linux kernel 2.6.12 image on SGI O2 with R5x00 CPU linux-image-2.6.12-1-sb1-swarm-bn - Linux kernel 2.6.12 image on SWARM linux-image-r10k-ip27 - Linux kernel image on SGI Origin linux-image-r10k-ip30 - Linux kernel image on SGI Octane linux-image-r4k-ip22 - Linux kernel image on SGI Indy/Indigo2 linux-image-r5k-ip32 - Linux kernel image on SGI O2 with R5x00 CPU linux-image-sb1-swarm-bn - Linux kernel image on SWARM mips-tools - MIPS specific kernel tools Changes: linux-patch-2.6-mips (2.6.12-1) experimental; urgency=low . * Initial mips/mipsel 2.6 kernel. Files: 4c1e12bd69ae7e82e58fc2bc91864ee8 1401 devel optional linux-patch-2.6-mips_2.6.12-1.dsc c35a960d45e15feaf75d6324c0cfd875 582948 devel optional linux-patch-2.6-mips_2.6.12-1.tar.gz e13f50e0036fae965fbb50e8031b7e76 1578 devel optional linux-headers-2.6-r4k-ip22_2.6.12-1_mips.deb 05c992fd7922e4c9ee868715fe74970d 1570 base optional linux-image-2.6-r4k-ip22_2.6.12-1_mips.deb b778cd227cbc2b74d8d2414022e0da79 1560 base optional linux-image-r4k-ip22_2.6.12-1_mips.deb 171b2331039245670abf2ec18a814b07 1556 devel optional linux-headers-2.6-r10k-ip27_2.6.12-1_mips.deb 4dd763a293de3c950d0d0cc45d90f5b8 1550 base optional linux-image-2.6-r10k-ip27_2.6.12-1_mips.deb aef7c10a4eae668bdd120d810945ce7e 1542 base optional linux-image-r10k-ip27_2.6.12-1_mips.deb d85b64bb6fc55d20b2b29b1cc2e552d5 1568 devel optional linux-headers-2.6-r10k-ip30_2.6.12-1_mips.deb 5f3e750a586471452b24efc8ec33e240 1556 base optional linux-image-2.6-r10k-ip30_2.6.12-1_mips.deb 3d91169083b0fd09e0395efa0cde536c 1540 base optional linux-image-r10k-ip30_2.6.12-1_mips.deb 907e91dea6d958f0dd71ef8cf0a3ff62 1592 devel optional linux-headers-2.6-r5k-ip32_2.6.12-1_mips.deb 6b3bc7388d7d9b0ab6ccf3930378cef8 1568 base optional linux-image-2.6-r5k-ip32_2.6.12-1_mips.deb 0b6a4efd3f84b1bfc4406a7f9b34960a 1564 base optional linux-image-r5k-ip32_2.6.12-1_mips.deb 87bcf40b651b84c096b783ba4957016f 1558 devel optional linux-headers-2.6-sb1-swarm-bn_2.6.12-1_mips.deb f4a28aa680034264ebb5082f660b76a3 1556 base optional linux-image-2.6-sb1-swarm-bn_2.6.12-1_mips.deb 72dca4a4395f7ab7419ecd5c6e46cb15 1546 base optional linux-image-sb1-swarm-bn_2.6.12-1_mips.deb f829b0c699127dd79e893a743c749dec 2114 devel optional mips-tools_2.6.12-1_mips.deb 643bda418f596dabeb0a93aee7e49876 6436332 base
Re: a desperate request for licence metadata
John Hasler wrote: Petter Reinholdtsen writes: We have the the same limitation in norwegian law, were the work need to have (the norwegian expression) verkshøyde, which implies a certain quality level as Andreas puts it. Do you mean quality or originality? The amount of creativity the author put in _successfully_. Are you saying that if I write a highly original stream of conciousness novel that is judged by the critics to be of abysmal literary quality that I will be denied a copyright in Norway? If the average audience consistently says this is useless crap then that's basically the outcome. (Copyright wouldn't be denied, it is either inherent in the work or not there at all. There's no copyright registration like in the US, it's not needed.) Is buggy spaghetti code not protected in Germany? Computer programs are exempted from that requirement. As for the quality of the product of the entertainment industry, I'm not sure if your judgement matches that of the law. That's the problem. How does the law judge the quality of works of authorship? Do the courts employ panels of literary critics? When they need external expertise they may do for that specific case. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a desperate request for licence metadata (was Re: migrating w iki content from twiki (w.d.net) to moinmoin (w.d.org))
Jesús M. Navarro wrote: Hi, Andreas: El Martes, 06 Septiembre 2005 18:20, Andreas Schuldei escribió: * Petter Reinholdtsen [EMAIL PROTECTED] [2005-09-06 17:39:06]: Which I fail to understand, as the limited rights provided to me by law should be sufficient for the wiki content in most cases. i spoke to a german lawyer about this exact (license) issue when skolelinux.de pondered an applicable license for it's wiki and aparently it is doubtfull that wiki content is worthy to protect in the first place. There needs to be a certain quality level reached, aparently, which is not necessarily given in a wiki. So this discussion about a license for the debian wiki might be very debianish but also irrelevant. (c: No, I don't think it isn't. Even if German laws renders not having a explicit license good enough for the case at hand, reality is copyright laws *tends* to overprotect the author against other (potential) users. By explicitly saying what are the rights you give to your users you: a) Make a case by the explicit announce it (so people can become aware that not everybody will give the same rigths with their works) and b) Insure you are not dependant (to an extent, at least) on what's the default for any given country's laws about this item. In Spain, for instance, not mentioning any explicit copyright notice gives complete control to the author and no control (except for reading it in the very media it originally was published) to the user. Same in Germany. Relying on the speculation that no Debian wiki article will ever be good enough to gain copyright protection is unwise IMHO. It breaks down in exactly those cases where licensing is most likely to become a real issue. This may still not be a problem for Debian, because it can claim the author's concludent permission to publish his work, but everyone who redistributes/republishes some content from the wiki may face unexpected trouble. IANAL, Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a desperate request for licence metadata
Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Computer programs are exempted from that requirement. The work needs to have some kind of creative art. Without any quality judgement, correct. This doesn't leave anything of interest out. Trivial programs are also not protected in a lot countries. I meant to refer to Germany specifially. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a desperate request for licence metadata
John Hasler wrote: [snip] Are you saying that if I write a highly original stream of conciousness novel that is judged by the critics to be of abysmal literary quality that I will be denied a copyright in Norway? Thiemo Seufer writes: If the average audience consistently says this is useless crap then that's basically the outcome. (Copyright wouldn't be denied, it is either inherent in the work or not there at all. There's no copyright registration like in the US, it's not needed.) You appear to contradict yourself. Do I have a copyright, or do I not? You have if your work is worthwile to be protected. (BTW copyright is also automatic in the US. Registration is only required just before you file suit, and then it's just a matter of a form and a small fee with no possibility of denial). When they need external expertise they may do for that specific case. So if I brought suit against someone for making unauthorized copies of my Usenet articles a court guided by panel of literary critics might rule them not worthy of protection? If the court finds it can't decide the matter without a panel of literary critics this may happen. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
