Accepted resolvconf 1.79 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 01 Apr 2016 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.79 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers <resolvconf-de...@lists.alioth.debian.org> Changed-By: Thomas Hood <jdth...@gmail.com> Description: resolvconf - name server information handler Closes: 804976 819498 Changes: resolvconf (1.79) unstable; urgency=low . [ Thomas Hood ] * Use which to test for availability of dnssec-triggerd * [19003cb] Drop obsolete versioned dependencies. Thanks to biebl (Closes: 804976) * [b348580] Update README * [7e33af8] Omit chown from example script resolvconf-update-bind. Thanks to Marc Haber (Closes: #819498) * [22bfead] Create runtime dir if it does not exist. (In some upgrade scenarios resolvconf gets called before the postinst or initscripts get run.) Thanks to Martin Pitt (LP: #1536335) Checksums-Sha1: 9d7c20b5d384058d32d122ce558a6dcdc30b3a3a 1704 resolvconf_1.79.dsc a12afabe9e798aa72d0e0834e6d771b2e72b1b55 72672 resolvconf_1.79.tar.xz 520757e684c5ef56e23c699884aea6daec29b0d2 74158 resolvconf_1.79_all.deb Checksums-Sha256: e8b794948c8979d3be577cebec1a092341d0b7d9042d443d6efa48ec01a52959 1704 resolvconf_1.79.dsc 8e2843cd4162b706f0481b3c281657728cbc2822e50a64fff79b79bd8aa870a0 72672 resolvconf_1.79.tar.xz 7d564b42807cd5d97ed2f5e6b2032b946225800f60cb24dbd9eb7e15cbaf84e6 74158 resolvconf_1.79_all.deb Files: eab2e851db4c2d346fddb383a7d4eb1a 1704 net optional resolvconf_1.79.dsc aab2382020fc518f06a06e924c56d300 72672 net optional resolvconf_1.79.tar.xz 7055f59950997f453aa2634ffa7412fe 74158 net optional resolvconf_1.79_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXPixqAAoJEFifA/AbpVA4OogQAJf9lG4UBzEM+gpCuy7bKwNU gSORn1uH8B33EucLih2dfLivq4aTuQvDHaA4+5Wxlcm/e/aVi37UYywqG3UoPJfa OLd+yCP+69RmM1t3+cKuHO8SiYQ3jTf8KeX13trT4jX1U6bI/QM2wNAUkHvoRMJG L+61dsHwyw/F4Jat+d23HvmUBCRACr3A54NfMmWwTdpfHFz0jmRE38tqxhYb15BS 6GkRBZea9yFBHNp9rnnt3eROfJJriI1sglokZsbMGHIQdlTi7VCx5BEolj10SDQs fgSyGP6TxtfqRxAlHHQKJ6aaisyQpO6oRdt45Mq4aAuv+9UTWuRoGoOzt0O/4Ydo B5fUpUnXYHnD5ZOTcrnTXrKS7bRCT0K4FREY3AohDoD5eCKGK0eDPfbzoEe2HIsW rP6Xr+WBoHdHlvTMtBlruVkX7011XhjEojhv1TWSGkR0y6Ki+KrEnabmzANGTuPZ M+CnTa2HGEYMlG8bSBGAIo0RTYc2RSZ16dL2CWfvGuHMZ4PORh9JHyhVYWFfegYE gLqpeg4UIkShx9uAAsmOcSN6WIsagZ4R1GDET3rnctgNnG18AVaUaC4051nWZBek dDYc5Sd85KKprXTYlM/I96+gEDxKTLTPdJhpbpTrtUtnDgisRuMAQq2UoibAfnP6 3MoEDrFegRCYL4iLM6jg =59sC -END PGP SIGNATURE-
Accepted resolvconf 1.78 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 03 Jun 2015 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.78 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 787457 Changes: resolvconf (1.78) unstable; urgency=low . [ Marco Nenciarini ] * [dd83369] debian/gbp.conf: Use new-style sections sans git- [ Thomas Hood ] * [f73de5c] Add sysv-rc dependency which should have been added in release 1.75 when start and stop were no longer given to update-rc.d (Closes: #787457) * [ac8f46e] postinst: Delete bad rc symlinks arising from #787457. Checksums-Sha1: 4103deb44af05d93b8a564b37225877d31eac772 1704 resolvconf_1.78.dsc 3fec5f64bbc417b406cc04e257886b49e739c32f 72504 resolvconf_1.78.tar.xz cc385998a944cc6c39f34b12de7de9f4d1d74bca 73962 resolvconf_1.78_all.deb Checksums-Sha256: 091edb23f5089674f8cfa7861a7b6c0a9b437e45d307dbd9fb5a1bdccc147501 1704 resolvconf_1.78.dsc 961b22e8fcf0c7de7e90a050323e6fa221bc8b25a5348c160be3506f7e73a7a3 72504 resolvconf_1.78.tar.xz 9d0d629121873057b435b06787636c10bf7185ecbbfcaec1c193d57910c1e0ac 73962 resolvconf_1.78_all.deb Files: 853183d8efd31f52d6ff9c08ec11dd27 1704 net optional resolvconf_1.78.dsc 373a9f9544c84aa477a7425ae773b8b5 72504 net optional resolvconf_1.78.tar.xz ef2f4de185a73159a620b2399aaa7ce9 73962 net optional resolvconf_1.78_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJV3YqVAAoJEFifA/AbpVA4VIQP/jclH8G55h5p7gPR5gmMyRbc JQXC5iBHrwPX1Ib/6zhKuQKXoBAZuStAUXZ/p18l5bTsfBoMc5CAm1Qx2bTzOp+D 2k0BoW+Bd3nxueTHoYAJlsGn5HMTuJLZMZzhwSF4zw2gL+dE4nYfDlHrYCw4488R g6e3pdy78QZQbY0D/upUMgfVKgsEX8GvhOfI4UcLpoTiJsKO5OHrq0tgWItPlCSm BuUDyyErCsswHYA3a9Le6F44ir4b+zQrjRpk1Ax1P2z9RQOK0xHRhGk4NnQF535d aGvYtPqD8+gDz+KQ69v+C/9P991MzJgZ2qgdlrgV8ik+WIvanL9a+nsDEiJS0fe9 xr9t0AMvf1t5IYAG9Di8j8R6Va1rX+Mhr4hR98b4tG6IuPl0uKRfxN7PjUGpmRfF WFyaO6SmH+E7xn33AqxneByfBYJKsEjscloHjvlXc+tt5uXwrLtJoFerLYlfwjOD woPoGCXu0dppiltqgsl4lqT3vXp2wGUrxEmgG5Acy6N4iQ4+4V6u5DL3xOutCFR3 Ia5SPY/vLZomSeApdMz/HnxM+VrYGrgDS6SpdKubmFBywegQYY5AoFQFRRyLz0fG n/EWJj9u/7dskZubqU5xYkKJYGr6PE2sWZ9M482FVYe9xs3+aOSi2JsIBr/kiu1G HLpLly5Jt9ncO6UPfu4z =yHtM -END PGP SIGNATURE-
Accepted resolvconf 1.77 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 21 Apr 2015 21:04:08 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.77 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.77) unstable; urgency=low . * [0781847] interface-order: match br ifaces at the same priority as eth ifaces (see LP#1446681) * Remove obsolete upgrade code * [00ad4bf] Override immutability attrib on /etc/resolv.conf if dnssec-trigger is installed. See #776778 for background. Checksums-Sha1: f151c9a8dc09c802fbd0690b09c6be13df3caa8a 1704 resolvconf_1.77.dsc cc43713fcf51d982b1a83e5b65b8c8c0441e6f2b 72252 resolvconf_1.77.tar.xz 21e4c1675e26e90408c0f9b95212db41d82964ba 78170 resolvconf_1.77_all.deb Checksums-Sha256: 5f43dd083ec2ebafed6302ca359da626aa0bc09f83c8b89896ee5d068beb340d 1704 resolvconf_1.77.dsc 5a6e21e8ba6822a5f93075c8c8fe7977e34780ba551af51930d0b31fdd99ab56 72252 resolvconf_1.77.tar.xz aeb0b7467fdc91d5e03e1f5a8cc34dfca31254e0f1068253442bcac920ac34b5 78170 resolvconf_1.77_all.deb Files: d1386f3c1553e8dee17e82a0d9cb48c3 1704 net optional resolvconf_1.77.dsc 7362d766e47bfc253500f42b30330d9f 72252 net optional resolvconf_1.77.tar.xz 23657a1edf9b7c0bc44501ff58296105 78170 net optional resolvconf_1.77_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVUO9jAAoJEFifA/AbpVA4wKgP/2mbDjASWtFXxMwn4gPkweuP zYT/h1UclNV5794wu63Tj+o4xEVvh+WWa+B74OQSJNL9iIo5rv+2UKzv+pmEaanR O4EhvJxl+4NAJ1Moitp9FHjXeXvVUMAZ4sOJmSFQggPfvfLaCob5oWIx675gmyuw aDq4xxMeSThAZGH8f4aEcvY1R+hd8W/53MqLkIitiTGnbtr8KSGSFARbMFKDeKAQ HbXYxOeUBsgCypSh2e5jZQ5nSFRQ69mb7qr9X9JoQakfF5SVcSadIEoJZ4jlF3FE +P6L9fv6Uy7pkcgQhxbdHURBjNWQf2ZfUBrYqkkjywsi6aVj+gjnjAnb6/P78frh 75jC9wJar8318zszVpWoc5cEoYP3VdjHc8988FnmUxJwI6JCcAJMJlGqWCsCFy82 rhueYcUzLAJp6JajHfqMS4Vy6QG3bgTSyPtHdKmiIPqNjbhyBSkwrvEbO0Ky2p3U B19DgR5bPyMAXNoJC9+pDSKBNVmVWPCoEfRjoIgdELvbZzZjhooTi8IiFNYoUgWM p1sawkwTuMMmuuz64NHOi5MrELaAmOKSpiCxbRxR2OaTJLv0gytF/FDAcm/i1fiI BcdstsTBb5g8TgeR7bInO6gLn0c9wdquRBp6Ao7s18wYo3ifIBx5icv5xmpgL1O3 t0Ve7z02/CqVqBytA8Hn =dgPV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrsim-0005iw...@franck.debian.org
Accepted resolvconf 1.76.1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 23 Jan 2015 21:46:34 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.76.1 Distribution: unstable Urgency: medium Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 775356 Changes: resolvconf (1.76.1) unstable; urgency=medium . * [eb81ca0] Eliminate bashisms. Thanks to Michael Gilbert (Closes: #775356) Checksums-Sha1: 3a0c954a1fcf62b6402ae46c0c8468ebc3b749c8 1712 resolvconf_1.76.1.dsc bfa94c839d8df041c36a1ad7f7371ab262b72bdb 72328 resolvconf_1.76.1.tar.xz bd9fb92a2676b76d50d69739a047c0701d11ca95 78064 resolvconf_1.76.1_all.deb Checksums-Sha256: b4f41d16156c4b95d552f6358bba2ec44bf3b8fc3d58ef72fc45c19c6926b321 1712 resolvconf_1.76.1.dsc 05318a7988f2b6fa400468ea096f0ccf73d166ac47a4fbab287ff63bea9502d3 72328 resolvconf_1.76.1.tar.xz e7da311f90339d238761acb568a9aebea7a4eb94f34abada695e97aef2a6bc63 78064 resolvconf_1.76.1_all.deb Files: 167ec5c33324cf1bce6f889150b50d38 1712 net optional resolvconf_1.76.1.dsc 16f395f43ef5d832922b0cd4a82efcaa 72328 net optional resolvconf_1.76.1.tar.xz 240c1ed4540f2150271ddb8ac83fbca7 78064 net optional resolvconf_1.76.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUx291AAoJEFifA/AbpVA4iU4P/iLrqBn/n3JOWIcSIMixhedx jcpvXYChhAUhd5vYD4vixaMgntSEgDKrJjNosVR02MfwEE1FLUJ5syVCEJnLso5B /ufHf2jN+/XctvdrCiKixp6AX9/nUc/wtFifhZvnLzTMRAMLj4n+YnMz3hPUWQYb 64YDU4YsPYGY3OsdqDPlXhm2wyzYhmXTlfE1NWEbwWZ9aYeJvkbCe+uhkngPJSfi MGiupWdI3qNRaT0nHGS8d1UeP5kxwXKiK8Jolv930qJDZ4k9y6Lok+BfzO6SAGHA SFT77Hs8bLcKq5twWp8SprbefaNAOzBtzOnxsDUhIQnhfPHPbV9ZJi88uL6U8NiI maabPEEJqklyr52Evoqd99ny+DEiRsCb4Sv5QjEBc2oO/FgwpPTH+v/ToNN7bDaF XalEd80yrNSDr0ruDqOHwVmyBPJeaRw4GUyH1Dr4TyQYy8KmnA2W6mcjFJrUlbCq ozUi0gEn5pLGG4n8FaD5fYwTomKmVmVMxNJKhe+rmZbmow2WM+jdKLY033VrtNJy K9HLzGFCigvpbNAmE4wuj96CxSyDzEgDhPUay5IRvLTY7b1AjdOtM0AoDwjppHZy DgdTH7lHIaABYC+k6XpUBgor83ggpB6NBPGAW6BpdzSqWF/8TSL5QowCYJWufJMk faJ8V64wmDaZnSx46dWd =egY9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yg3w2-0003g2...@franck.debian.org
Accepted resolvconf 1.76 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 10 Oct 2014 13:42:54 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.76 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 749405 Changes: resolvconf (1.76) unstable; urgency=low . * resolvconf.service: Install into sysinit.target, not into network.target (Closes: #749405) Thanks to Martin Pitt and Edward Allcutt * [c405030] Add exclusion for L2TP VPN plugin (LP#1349011) * [4cbd73d] Bump Standards-Version Checksums-Sha1: edd97597a8e09f3dee656289ef7e8e5649d43178 1704 resolvconf_1.76.dsc 723e02ac93bf8da17c07dacf59c174b134769da9 72232 resolvconf_1.76.tar.xz 2585ee60c0e081a000abf3cafe4b92e7bdd1e54b 78012 resolvconf_1.76_all.deb Checksums-Sha256: 6ca084e45903477a1d2dbb8b7451f4ebfda5f06847e42b5e22b845043441b19a 1704 resolvconf_1.76.dsc c9f40f7405b37399ddbf29ca4205b4911ee35cb9ffd9be7671faa2385b1fa573 72232 resolvconf_1.76.tar.xz b1083c25aaf6d7fe2f493401abd5007db44a2813af863b0fe5ea300a8bf6d482 78012 resolvconf_1.76_all.deb Files: 547a8cd9b0ef956d57294f7c981512ff 1704 net optional resolvconf_1.76.dsc d78ce30ea068999cd3e0523300b27255 72232 net optional resolvconf_1.76.tar.xz badf88d429ccad32ced59536b59915e7 78012 net optional resolvconf_1.76_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUO9FOAAoJEFifA/AbpVA4k6oP/joYrbDgfe0TqmWzFX30XOj3 bUuKtgUaTdNivwhLT0AkmkRr54JDGOqMWBW12TvRv7JpxPHl++iEnJe0hxv+9Cno 0UIM4l33ousK44HfAdm/+YcxceGZIzUwiq+FzzPXuBI4OO7fq9PLqaPvijFh1a3m Fs7L37J2ImUsEaAbZwG9bfdmeSSmYELRuPPj2DAeB7I0+AgXhk3oc9VgnCtT3dNl qfbU+UF4EvvzNL0ryTe/tL6pnpYbA/DmwjTKcRYFYsH8+I/aiWnsmaoSq50g6FKG wkTHpRblonnnTNIWa80sdrpXk0ZdJGhbb9w4IGTmnLcXYd6tSknsHGvsOCHxFSvL rspnOWGcoQObQpWbSvetIe32PKtFt9LrBFekm3F5A3obLHy1D9oxPV8CR+cLe9Uo MAiKRMvAqSZpR6DPreheyh4U0cW2sxP/wI9w2EFYqAYR86pqv56GMWy1v3wDFgGV PSL2bZ+OGjbQgBgpOzgBmgjzIOI9KqHexUbvDdtujnThxFu6+2uUPFkRUVRtaBaD fZsBulVO3AKfI2UkJsGO/qAsZgnLEPM0NaEIDLdEBfeYfIfV1bNF6tKWqbnxxNyG Sa7y93+1nK5GxFcMq0NcQ/CPdAcXG80D2zX8cal5r2S9kHF94Y0Bu0CwN6ePmQgw ejKBXyhLNHXjAEWESNme =fhKI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xdfli-0001kg...@franck.debian.org
Accepted resolvconf 1.75 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 08 May 2014 11:57:29 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.75 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 700846 718021 718232 718714 737158 Changes: resolvconf (1.75) unstable; urgency=low . * [49dedb8] Update man page re: dns-nameserver (Closes: 718021) * [6195584] Don't give update-rc.d start and stop (Closes: #718232) * [eed7eb1] Add pt_BR.po. Thanks to A. R. Gomes (Closes: #718714) * [a84a8f2] Remove buggy dnscache update script which should be in dnscache-run anyway * [b93b150] Fix typo in README (Closes: #737158) * [6a47a50] Add systemd unit. Thanks Martin Pitt (Closes: #700846) Checksums-Sha1: d1a66026a8db7df12e2af5e97a449177b1067d0f 1708 resolvconf_1.75.dsc e85fc983ad6957fb651bc2fbb48b144ea59aae4b 72068 resolvconf_1.75.tar.xz 8ab8eef1eca68854fa1e57bb29003b943f0d298e 8 resolvconf_1.75_all.deb Checksums-Sha256: 5b8feaaefcc5ca95dc42c4129d118678b8026279322ccb37bf07accfb41c930d 1708 resolvconf_1.75.dsc 16167f37a77ef4bc4596dcbefece269b6a10d10fa448594ec55ed3303193086e 72068 resolvconf_1.75.tar.xz de0f817928519762b1a793763b54f115c9911ecdfcd6fd63db7d52c285acae16 8 resolvconf_1.75_all.deb Files: 999b9142c387ce240b7524f1265e9cef 8 net optional resolvconf_1.75_all.deb c2d9122218dbffc55e4b54d52e4f7ec9 1708 net optional resolvconf_1.75.dsc 4b8bc86a3cf070e3fd0e9aff7eaaba56 72068 net optional resolvconf_1.75.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTc465AAoJEFifA/AbpVA46MMQAJdGNkHwVSlhj9s27q6tY7SI TmNCo+pN9FJM/zBxpoG9x1aI+DKEannyiYcfQZhc0sxF0QnfokSTfnQpbEuxs0ME M9l3lrbceEMNO8wV6y2M0eGZeaH8tVNq7EOKMRwX8hbYZdys3N6xivxSJ6rtXne1 2Y4Cr/LDHFBuDmP7XWxsBZPE9YdRo3ozl4qf/4Qthc5XeIFVepwaitrOoLHGQEc6 4j9rj13tnb2UbRLnq8Ls6PayZSKtlRO1U1aEcZZaAMrQU2dRUNT9vLwbor32y+PH AY3aMWS9xbA1ImAM7iQgsYuYmGKQa0KOYNV7mwbkbrOOqj4pE2mfx7Bg2bOMJvDS AD7FPOkKLvsb9DI+/2sWnfc4HQq4vAFHZoeJ+Q1QnEhYEfLi83aO0VLqfr9xRiZS jQBiUFq5Cms1uGUsXNnSFQz8QbpKExlrQuh9YNC4yY3xl+W+VZI5wJSXU1gKYlB0 XmhbjfpkmcE4Di7XWatDneaIBPBG4JUm3tB/cYS4iT7UWJAJlUFRKqy1ItnNiA6u nu0Cmu3mzbEXk8i9stB8X7OEuLEEBPEHL4dUvn9UJ6rJNJpS8DvgkouS3Syes6Jq bA8Ks6HRgmXrzxbLwM7uK9HNL2YbmwmVThUMtRmTbasO+HRJO04mMpgGaG0LIp07 a2X+GAkmIowKKBOKvkzP =l+W0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbuw-9w...@franck.debian.org
Re: getaddrinfo() return value chaos
I wrote: Kurt has filed a new bug report against eglibc http://sourceware.org/bugzilla/show_bug.cgi?id=15726 which draws the developers' attention to RFC3493 which specifies the return values of getaddrinfo(). These should be as follows. [...] Further discussion can best be carried on in the upstream Bugzilla ticket. Arising from the discussion in that ticket an effort has begun better to describe the desired behavior of getaddrinfo(). Initial results can be seen here: http://sourceware.org/glibc/wiki/NameResolver -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521dde8f.5000...@gmail.com
Re: Preventing government subversion in Debian, verification of binary package uploads
We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. If a Debian contributor were faced with a demand to do something that undermines the privacy or other interests of Debian users then I would hope and expect that the contributor would choose instead to cease being a contributor. Were he not to do so then he would have to be regarded as an infiltrator. Here I assume that U.S. law is not so draconian that it can require someone who has contributed to Debian (and who is therefore trusted) to continue doing so. So perhaps the more pertinent question is, what safeguards does Debian have against infiltration? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52192992.6070...@gmail.com
Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Op 8 aug. 2013 17:49 schreef Tom H tomh0...@gmail.com het volgende: The output below is from Debian Sid with libnss-myhostname installed [...] [root@debdeb:/etc]# cat hostname debdeb [root@debdeb:/etc]# cat hosts 127.0.0.1 localhost [root@debdeb:/etc]# getent hosts 127.0.1.1 192.168.1.250 debdeb This is interesting. -- Thomas
Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Op 7 aug. 2013 10:33 schreef Wouter Verhelst wou...@debian.org het volgende: Historically, localhost has always been 127.0.0.1. It feels wrong to change that, simply because localhost starts showing up in places it was never meant to show up in. To clarify, no one is proposing that 'localhost' be assigned any (IPv4) address other than 127.0.0.1 in /etc/hosts. The question is what IP address the system hostname should be assigned when the machine has no static external IP address. Currently it is assigned 127.0.1.1 and the proposal is to assign it 127.0.0.1 with 'localhost' becoming a mere alias. I have already expressed my opinion about that proposal. -- Thomas
Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Sorry I'm a bit late contributing to this discussion. Christoph Anton Mitterer wrote: The eventual result[1] was that Debian nowadays ships /etc/hosts like these per default: 127.0.0.1 localhost 127.0.1.1 host_name.domain_name host_name As also described in the Debian reference[2]. That's not entirely accurate. Wheezy and Ubuntu Desktop install an /etc/hosts like the following, without a domain_name. 127.0.0.1 localhost 127.0.1.1 host_name The Debian Reference is out of date. Some years ago it was the case that if a machine had a static external IP address then this was listed instead of '127.0.1.1'. I presume that this is still the case but I haven't checked (and I am on the road, so can't easily check, sorry). The hostname is not necessarily a domain name, at least not de jure. Right. Ideally nothing would blindly treat the system hostname as a domain name. I don't know how that practice ever got started, but it overlooked the fact that machines can have multiple domain names and multiple IP addresses, any of which can be externally administered and any of which can be changed at any time. The machine itself doesn't even know when its domain names change. But in reality, many programs and people rely or are at least used to the hostname being resolvable. That practise won't change and we cannot do much about it. That seems too pessimistic to me. If there are broken programs we can patch them. - Most applications that listen to the loopback actually only listen to 127.0.0.1 (and perhaps ::1) but often not to 127.0.0.0/8. Last time I checked, most applications that listen on 127.0.0.1 listen on all addresses, thus including 127.0.0.0/8. This is why resolving the hostname to 127.0.1.1 actually causes few if any problems in practice. = so the overall proposal (I) is: If no one has any technical reasons against, can we stop using 127.0.1.1 and let the hostname point to 127.0.0.1 as in: 127.0.0.1 localhost 127.0.0.1 foobar[.bar.net foobar] Strictly speaking, each IP address in /etc/hosts should be represented by no more than one line. Your proposal has the consequence that 'localhost' is the canonical name for 'foobar'. Please don't do this. I don't want to return to the days of 'localhost' appearing in log files and command line prompts. Simon McVittie wrote: libnss-myhostname is basically this, and is packaged. It tries to return a public address if possible, only falling back to 127.0.0.2 (upstream), 127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more suitable. This is exactly what you need if you need the system hostname to be resolvable to an IP address. (And I am prepared to believe that we still need that, even though I haven't tested it recently.) With the nsswitch configuration hosts: files ... dns ... myhostname myhostname resolves the system hostname if nothing else does so first. So it can be overridden either by DNS or by /etc/hosts. If the system hostname changes, no file has to be edited. Nice. Also nice is the fact that myhostname resolves the system hostname to an external address if there is one, increasing the chances that the result is similar to what would be obtained from DNS. Wouter Verhelst wrote: The right way, in my opinion, is that /etc/hosts should look like this: 127.0.0.1 localhost 127.0.0.1 hostname.domain hostname Strictly speaking there should be no more than one line per IP address, so that would be 127.0.0.1 localhost hostname.domain hostname in which case 'localhost' is the canonical name for alias 'hostname'. or, alternatively: 127.0.0.1 hostname.domain hostname localhost In that case 'hostname.domain' is the canonical name for alias 'localhost'. Before any move is made to conflate the system hostname with 'localhost' in this way I'd like to see some proof that this no longer causes any malfunction, or if it does cause malfunction (e.g., 'localhost' appearing in log files) then I'd like to see the malfunctioning packages fixed in advance of the transition from 127.0.1.1 to 127.0.0.1. And before making this potentially disruptive change, I'd like to see evidence that the current practice actually causes problems --- problems that can't easily be solved by patching individual packages either to make them listen on 127.0.1.1 on the one hand or to make them talk to localhost on the other. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajn8kfcqbzh6scduqya1udjn397xo3wwvaj1mbfvzhvghkk...@mail.gmail.com
Accepted resolvconf 1.74 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 20 Jul 2013 21:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.74 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.74) unstable; urgency=low . * [bb84ffc] Tweak the README: * [e3910a7] Recommend use of 'dns-nameserver'. No longer mention the useless deprecated 'dns-domain'. * [2fe6083] Add dump-debug-info script * [b24b66d] Add --after option to list-records Checksums-Sha1: f7d1ca9a5f0994382108a7882293e2938b0347df 1098 resolvconf_1.74.dsc bb949585e780ff6d8585bd22703726bbbd9a9284 84505 resolvconf_1.74.tar.gz e122fb7ac6532c69cee976b2e6cd2d90a62d5b02 76114 resolvconf_1.74_all.deb Checksums-Sha256: 176ba4323180e22ce3ababb8da24ad30eae04979c1dca727e97d79cb35049072 1098 resolvconf_1.74.dsc 2e72e6884e9105cbf57101ab0f11e768717b6f76b7f5100c6a2a0cc69bb3d4a0 84505 resolvconf_1.74.tar.gz 918eaf9276714478def34d42d3d9f0bb6df7ec0aeae73577d3aa703d9d435b3e 76114 resolvconf_1.74_all.deb Files: b44891eaeb50adf4065c987ce6450867 1098 net optional resolvconf_1.74.dsc 2f190d3bb8960b69157f63590c262e93 84505 net optional resolvconf_1.74.tar.gz e628a6f6e9bf6993795881e8850f6f81 76114 net optional resolvconf_1.74_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iF4EAREIAAYFAlHz9vIACgkQ3VcITofi8ruztAD/ZBOX1lyzcZCP5Z5b8RgadXzu V5mGMgsrdcSG4I3Qo6EBAIEHVlWIbjzUvuxQ110x0V6L+EZOX5Z8dKaAR9PNTEz4 =LO42 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1v37fd-0003cx...@franck.debian.org
Re: getaddrinfo() return value chaos
Kurt has filed a new bug report against eglibc http://sourceware.org/bugzilla/show_bug.cgi?id=15726 which draws the developers' attention to RFC3493 which specifies the return values of getaddrinfo(). These should be as follows. - Things work as expected: return 0 - The nameserver replies that the hostname does not exist: EAI_FAIL - The nameserver doesn't reply, or replies with a temporary failure: EAI_AGAIN - You used AI_NUMERICHOST or AI_NUMERICSERV and didn't give a number: EAI_NONAME Further discussion can best be carried on in the upstream Bugzilla ticket. -- Thomas Hood
Re: getaddrinfo() return value chaos
It looked to me as if #582916 and roughly duplicate #671789 could have been fixed in libc6 2.17-7 which it includes two commits http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188 the first of which is included in eglibc 2.17 http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_17/libc/NEWS?view=markup and the second of which is included as a patch named 'cvs-getaddrinfo-EAI_NONAME.diff' in 2.17-7. So I upgraded libc6 on my Debian 7.0 machine. With the standard nsswitch.conf there is no change in the behavior of my test program. As before, either with empty or with bogus resolv.conf or with bogus domain name getaddrinfo() returns -2 with (supposedly therefore not significant) errno 2. With nsswitch.conf changed to have simply hosts: dns, the following is the output of the test program. Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 110 Results of looking up a bogus name: status = -2, errno = 110 This is different from both Debian 7.0 and Ubuntu 13.04 and sort of half way between the two. As in Debian 7.0 the status is still always -2 in case of error. As in Ubuntu 13.04 errno is 110 when an incorrect nameserver address is given, as opposed to 111 when resolv.conf is empty (but errno is not supposed to be significant here because status is -2). Callers of getaddrinfo() will only be able to rely on these return values once the values have stabilized in eglibc (which they may not yet have done) and once the bug (assuming it's a bug and not a feature) is fixed whereby, with the standard nsswitch.conf, the incorrect errno is returned. Interested parties might want to enter into discussion with upstream in order to ensure that there is a clear specification of what these return values should be under different circumstances. Ideally tests would be added which check whether the specification has been adhered to. -- Thomas
Re: getaddrinfo() return value chaos
On Mon, Jul 8, 2013 at 8:23 AM, Helmut Grohne hel...@subdivi.de wrote: Here are my results: Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -11, errno = 110 Results of looking up a bogus name: status = -11, errno = 110 This is an almost-sid box with libc6 2.17-5. The results are consistent with my earlier observations. My system above has [...]: hosts: files gw_name dns [...] So maybe mdns is to blame here for part of the trouble? Can you verify that really the last mdns4 entry makes up for the difference? Just checked on Debian 7.0 with libc6 upgraded to version 2.17-7 from sid. Behavior is exactly the same as yours, quoted above, except with status = -2 where you have status = -11. Same behavior with hosts: dns and hosts: files mdns4_minimal [NOTFOUND=return] dns. -- Thomas
Re: boot ordering and resolvconf
On Friday and Saturday I sent messages to this list but they
appear to have been filtered out. I try again and CC:
Helmut Grohne this time so at least he will receive this
message and we can continue the discussion over e-mail.
My Friday message contained a C program and its output
when run on my own machine. The purpose was to illustrate
a program re-reading resolv.conf when it changes. Since then
Helmut has posted a long message[0] which among other
things makes the same point, so there's no need for me to
belabor it here. However, there is one remaining question
where we still have different findings and I think we should
get to the bottom of this difference since it is relevant for
how we think about ntpd bug report #683061.
Helmut Grohne wrote:
On Sun, Jun 30, 2013 at 10:40:03PM +0200, Thomas Hood wrote:
A problem is that getaddrinfo() doesn't distinguish in its return
status between couldn't reach a nameserver and nameserver
says the name doesn't exist. Either way it returns EAI_SYSTEM
with errno=2 (ENOENT).
I cannot confirm this observation and assume it to be wrong.
Helmut Grohne wrote:
So what happens when you getaddrinfo ...
... a non-existent name? - EAI_SYSTEM ENOENT
... something when nothing is bound to port 53?
- EAI_SYSTEM ECONNREFUSED
... something when port 53 is bound, but does not answer?
- EAI_SYSTEM ETIMEDOUT
I don't get these results.
I attach a program x.c and append the output below, run on
Ubuntu 13.04. It shows that when resolv.conf is an empty file
and getaddrinfo() is called (... I have no local nameserver
running, so this causes failure to find a nameserver...) the
return value and errno are -11 and 2: EAI_SYSTEM and ENOENT.
The return values are the same when getaddrinfo() is called
with a nonexistent domain name. It was on the basis of a quick
test like this that I wrote what Helmut quoted.
But that was on an Ubuntu 13.04 system. I next ran the program
on Debian 7.0 and got the same results except that the return
value was -2 (EAI_NONAME) instead of -11, both in the case of
the bogus domain name and in the case of the unreachable
nameserver. Ubuntu and Debian thus differ on the return
value, but neither of them distinguishes between
name-doesn't-exist and nameserver-not-found.
Comparing my program with Helmut's the only significant
difference I saw was that he gave getaddrinfo() NULL as the
hints argument. I changed my program to give NULL hints
but the results were the same.
I wonder why Helmut and I are getting different results.
=== x.c run on Ubuntu 13.04 ===
$ sudo ./a.out
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 2
Results of looking up a bogus name: status = -11, errno = 2
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -11, errno = 2
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 2
Results of looking up a bogus name: status = -11, errno = 2
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -11, errno = 2
=== x.c run on Debian 7.0 ===
$ su
# ./a.out
Making resolv.conf empty
Results of looking up www.google.com: status = -2, errno = 2
Results of looking up a bogus name: status = -2, errno = 2
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -2, errno = 2
Making resolv.conf empty
Results of looking up www.google.com: status = -2, errno = 2
Results of looking up a bogus name: status = -2, errno = 2
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -2, errno = 2
[0] http://lists.debian.org/debian-devel/2013/07/msg00201.html
--
Thomas Hood
#include sys/types.h
#include sys/socket.h
#include netdb.h
#include errno.h
#include stdio.h
struct addrinfo hints;
struct addrinfo *res;
void check_google()
{
int status;
status = getaddrinfo(www.google.com, 0, NULL, res);
printf(Results of looking up www.google.com: status = %d, errno = %d\n, status, errno);
status = getaddrinfo(sjfkdsjfswfloo0f02938sjf28398sd.com, 0, NULL, res);
printf(Results of looking up a bogus name: status = %d, errno = %d\n, status, errno
getaddrinfo() return value chaos
Continuing on from the boot ordering and resolvconf thread; cc:ed to Helmut in case this gets filtered again; bcc:ed to 683...@bugs.debian.org since this is relevant for how that issue is addressed... Executive summary: The getaddrinfo() returns different values depending on the OS and on nsswitch.conf settings, making it very difficult to use getaddrinfo() return values to deciding how to handle an error. Here are the results of further experiments with getaddrinfo(). I am using the attached x.c program. It tries to look up the valid domain name 'www.google.com' and an invalid name four times: * once with empty /etc/resolv.conf (in which case the resolver tries 127.0.0.1:53) * once with /etc/resolv.conf pointing to a working nameserver on my LAN * once with empty /etc/resolv.conf (again) * once with /etc/resolv.conf pointing to an IP address where there is no working nameserver OS is Debian 7.0. # ./a.out Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 2 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 As I saw before, status is always -2 (EAI_NONAME). The manpage doesn't say that errno is significant in that case. (It is significant when status is -11.) Helmut got different results. Is the difference between my machine and Helmut's machine attributable to some diff in nsswitch.conf, perhaps? I have: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I tested next with hosts: dns and got different results. Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Now errno for empty or incorrect resolv.conf is 111 (ECONNREFUSED ). And with correct resolv.conf and bogus domain name errno is 101 (ENETUNREACH). That doesn't make too much sense but as I said I don't think we are supposed to pay attention to errno if status is -2. Next I ran the program on Ubuntu 13.04 with hosts: dns. Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -11, errno = 110 Results of looking up a bogus name: status = -11, errno = 110 This is different in two ways. First the status is -11 (EAI_SYSTEM) instead of -2 (EAI_NONAME) when no nameserver can be reached. Second, there is now a difference between the empty-resolv.conf case and the resolv.conf-with-bogus-address case. In the latter case errno is 110 (ETIMEDOUT) instead of 111 (ECONNREFUSED). This is better. Debian 7.0 has libc6 version 2.13-37. Ubuntu 13.04 has libc6 version 2.17-0ubuntu5. What's behind all this? [google, google...] I see that in November 2012 a change was made upstream http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 in response to a complaint that the wrong status was returned in the case of an internal error (out-of-fds). http://sourceware.org/bugzilla/show_bug.cgi?id=14719 This is possibly the reason that I get status -11 instead of -2 on Ubuntu. But the result of the change was that getaddrinfo() returned EAI_SYSTEM in too many cases. http://sourceware.org/bugzilla/show_bug.cgi?id=15339 This has recently (May 2013) been fixed http://sourceware.org/bugzilla/show_bug.cgi?id=15635 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188
Re: getaddrinfo() return value chaos
On Sun, Jul 7, 2013 at 2:41 PM, Kurt Roeckx k...@roeckx.be wrote: A related bug is #582916 Thanks. Besides that, #671789 and #713799 are also probably related. The latter was closed by the 2.17-7 release which is the most recent in unstable; I should be testing with that version rather than with the wheezy version, 2.13-38 (not 2.13-37 as I incorrectly claimed in my previous message, sigh). -- Thomas
Re: Updating /etc/hosts automatically / behavior of sed command
Tad Frank wrote: Your issue lies in the line: sed -e s/$REGISTERED_IP/$CURRENT_IP/g /etc/hosts /etc/hosts.new I searched debian-devel for the message to which you are responding; the most recent message with that subject header dates from December 1999. Yes, people were dynamically updating /etc/hosts in 1999 but I hope that no one has to do that any longer. :) -- Thomas Hood
Re: boot ordering and resolvconf
Ian Jackson wrote: I think the first thing to do is recognise the underlying problem. To fix this problem properly we need a coherent system design. The two designs lead to different sets of fixes. A. resolv.conf is a static file which changes only very rarely. B. resolv.conf is not static and may change due to network environment changes. The only underlying problem I know of is that ntpd is broken (#683061). Other applications work fine in mode B. And the reason that ntpd doesn't work properly is NOT that resolv.conf is dynamic. Ntpd doesn't work properly because it treats any name resolution failure as equivalent to host does not exist and treats host does not exist as a fatal error. So ntpd will also fail in mode A unless you manage to get name service fully operational before ntpd starts. Merely pointing /etc/resolv.conf at a local nameserver does not rule out the possibility of name service failures; it just ensures that applications can access some nameserver once the local nameserver has started. That's nice but it doesn't fix ntpd. Lookups will still fail, e.g., if ntpd starts before the nameserver or if the nameserver doesn't have a forwarding address yet. Applications have to be able to deal with temporary name service failures. The assumptions that got this thread started were made here: Helmut Grohne wrote: Usually any program reads /etc/resolv.conf once on the first DNS lookup. So all daemons started before the local DNS cache will either use a different server, or fail DNS resolution in all cases. A minority of services (avahi-daemon, fetchmail, postfix, sendmail, squid, and squid3) hook into resolvconf to reload their daemons when /etc/resolv.conf is changed by resolvconf. These daemons will not be affected by this problem. Many other services on the other hand will. This is an as-yet unsubstantiated claim. Libc resolver clients generally re-read resolv.conf every time it changes. Are there known examples of programs that fail to do so? Ian Jackson wrote: Is there some reason not to use dnsmasq for this ? To do this we would have to: * install dnsmasq by default * teach resolvconf to update dnsmasq's config rather than resolv.conf (but apparently Ubuntu have done this work) * make sure that the full-on DNS servers all conflict with dnsmasq and listen on 127.0.0.1 Policy would say: * By default resolv.conf should contain only 127.0.0.1 * No package may update resolv.conf's nameserver settings * All nameserver packages should conflict with dnsmasq (perhaps via a specified virtual-package) and must provide general nameservice on 127.0.0.1. * Nameserver packages and network configuration packages should use resolvconf to communicate the actual nameservers, if they wish to do this. (Support for this is not required by policy, but if support is provided this is how it should be done.) It's worth discussing what Debian should install and run by default. Ubuntu Server installs resolvconf by default. Ubuntu Desktop installs resolvconf, NetworkManager and dnsmasq-base by default: NetworkManager runs an instance of dnsmasq as a forwarding nameserver. But there is no need to introduce new restrictions and policy unless, perhaps, it does turn out that large numbers of libc resolver clients need to be modified, which so far as I know is not the case. -- Thomas Hood
Re: boot ordering and resolvconf
To those who aren't yet familiar with resolvconf, I'd suggest reading the resolvconf package README and the resolvconf(8) manpage. http://anonscm.debian.org/gitweb/?p=resolvconf/resolvconf.git;a=blob;f=README http://anonscm.debian.org/gitweb/?p=resolvconf/resolvconf.git;a=blob;f=man/resolvconf.8 -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d43cc2.4030...@gmail.com
Re: boot ordering and resolvconf
Tollef Fog Heen wrote: I think changing /etc/resolv.conf automatically is broken at all. What's the malfunction? We should have a generated /run/resolv.conf that's overridden by the settings in /etc/resolv.conf (if it exists). This allows you to have a consistent set of domains searched for matching hosts even when roaming to other networks. It also allows me to express the preference «I want to use localhost as a nameserver, always» without resorting to chattr to prevent dhclient, NetworkManager and other tools from auto-updating the resolv.conf file. Those features are available in resolvconf. Let's consider your idea. I like the aspect that /etc/resolv.conf remains a static file and doesn't have to be symlinked to a generated resolv.conf. However, your idea requires that the glibc resolver be enhanced. And once it is enhanced the logic is cast in binary stone: /etc/resolv.conf always overrides /run/resolv.conf, period. With resolvconf the logic is under the control of the administrator. If the admin puts a static file at /etc/resolv.conf then resolv.conf is static. If the admin puts a symlink at /etc/resolv.conf then the target of that symlink is used. With the resolvconf approach the resolver configuration is readable in one file which has the familiar semantics, resolv.conf(5). If there are two files then questions arise about how the one overrides the other. If /run/resolv.conf contains nameserver options and so does /etc/resolv.conf, then are both addresses tried, or just the latter, or what? Also, you will need a third file, also static, to provide defaults which get overridden by /run/resolv.conf. This will need to be documented. If it's the case that the mere existence of a file at /etc/resolv.conf causes /run/resolv.conf to be completely ignored then there is not so great a difference between your idea and resolvconf. With resolvconf, the absence of a symlink at /etc/resolv.conf is what causes the dynamic resolv.conf to be ignored. What is missing from your idea so far is functionality to handle multiple sources of nameserver information. What if the machine runs both dhclient and a VPN client, or both ifup and pppd? In the past each of these sorts of programs updated /etc/resolv.conf and (sometimes) restored the file to the preceding state on exit which left the file in an incorrect state if programs were stopped in other than LIFO order. Some packages make use of resolvconf hook scripts, a mechanism whereby they get notified when the resolver configuration changes. You could think about whether or not you want to implement that too, and how. Cheers, - - Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d2c629.30...@gmail.com
Re: boot ordering and resolvconf
In addition resolvconf does not properly support mode (A), due to the local forwarding nameserver is running requirement. It can leave /etc/resolv.conf empty until the name server is actually started. Well, you are right that resolvconf was designed to support mode B, and only supports mode A as a trivial case of mode B where a local forwarding nameserver is always running. That resolvconf leaves resolv.conf empty of nameserver entries when no nameservers are available is intentional. The idea is to advertise only addresses where something is actually listening. I understand, though, (vaguely) that this is not how things work in the systemd world, so I expect that resolvconf, or the use of resolvconf, will have to be adapted for the systemd world. Help and advice will be appreciated: see bug report #700846. By the way, inconsistent with the aforementioned idea is the fact that the resolver defaults to using 127.0.0.1 if there are no nameserver lines in resolv.conf. Were you aware of that? As far as I can tell the unbound part works very well on wheezy already. Well except for ntpd not noticing. Thanks for pointing that out. I don't use unbound so I hadn't noticed that resolvconf hook scripts have been added to the unbound package. I will update the resolvconf README. -- Thomas
Re: boot ordering and resolvconf
Helmut Grohne wrote: All that I am aiming for is to declare one of the following practises as broken: * Treating an empty /etc/resolv.conf as a permanent error or failing to discover changes in /etc/resolv.conf later on. * Changing /etc/resolv.conf during startup of a local dns cache. I think that the first one is broken. If name service is unavailable just after boot then that should not be treated as a permanent error. An answer from a nameserver that a domain name does not exist might more reasonably be treated as a permanent error, but that is disputable. In a world where computers move among LANs, DNS does not always look the same, so it's not unreasonable to retry periodically even after being told NXDOMAIN. A problem is that getaddrinfo() doesn't distinguish in its return status between couldn't reach a nameserver and nameserver says the name doesn't exist. Either way it returns EAI_SYSTEM with errno=2 (ENOENT). I am not aware that there is anything (except perhaps ntpd) that needs to be fixed. It is true, that ntpd can work around this issue. Still it appears like a bad design to treat EAI_SYSTEM as a temporary error. Can you explain why you think that? -- Thomas
Re: boot ordering and resolvconf
Ian Jackson wrote: The two designs lead to different sets of fixes. A. resolv.conf is a static file which changes only very rarely. Implications: 1. Existing DNS client applications do not need to change. 2. DNS service should always be provided at a fixed address 3. Therefore in the default installation this address should refer to localhost. Otherwise it cannot be redirected later as the network environment or installed package set changes. 4. Therefore in most installations there should be a local proxy or cache. It should use DHCP-provided, PPP-provided or similar, as a forwarder. The local DNS provider address should be owned by whatever proxy or cache is installed. B. resolv.conf is not static and may change due to network environment changes. Implications: 1. All existing DNS applications must be modified to notice changes to resolv.conf. 2. Corollary: all existing DNS resolver libraries must be so modified. 3. This will be impractical unless a common mechanism with a convenient interface (and low impact on the rest of a program) is provided. Hopefully resolvconf fits this bill. I don't know exactly how impractical B2 is. The libc's resolver is probably a hard case because of the libc's low level in the protocol stack. Can we make it aware of resolvconf ? Resolvconf supports both mode A and mode B and allows switching between them. With resolvconf installed, (A) so long as a local forwarding nameserver is running, resolv.conf points to this nameserver and thus rarely changes; but (B) if no local forwarding nameserver is running and the network environment changes then resolv.conf is updated and client applications are notified via resolvconf hook scripts in /etc/resolvconf/update.d/ and /etc/resolvconf/update-libc.d/. Even clients without resolvconf hook scripts make use of the latest resolv.conf information because eglibc was enhanced two years ago to watch the mtime of /etc/resolv.conf and re-initialize the resolver state when it changes. Because of this, I am not aware that there is anything (except perhaps ntpd) that needs to be fixed. The difficulty with plan A is probably B4. Do we have a suitable minimal proxy we can install, a way to reconfigure it based on dhcp etc., and a means to displace it when something more substantial like unbound is installed ? Resolvconf supports the use of dnsmasq, pdnsd and djbdns dnscache as local forwarding nameservers and reconfigures them based on input from DHCP clients, ifup and NetworkManager. Support for bind9 and unbound could easily be added (see bug report #483098). -- Thomas Hood resolvconf maintainers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cda59b.1000...@gmail.com
Accepted resolvconf 1.72 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 May 2013 13:50:30 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.72 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.72) unstable; urgency=low . * [d3b9390] Fix flag file name in debian/config Checksums-Sha1: ae8b0f3114ffe0e96f66f1f1e1da8c22e62abd2b 1087 resolvconf_1.72.dsc 66ac13c3ba0ba9fcca3c34762371a5f311d3c3e7 82703 resolvconf_1.72.tar.gz 233f86cd3a7f5335e0bc31455ca4221ea07f722c 74344 resolvconf_1.72_all.deb Checksums-Sha256: b2aca47c8fcdcc5b0cff2829280725d58c2b462b42ce7a6380ccc18aa4a06ded 1087 resolvconf_1.72.dsc 196e8b5ef0a0282bf99e156113b058e65dd7f889cf4aea16597cddeef7e7cd43 82703 resolvconf_1.72.tar.gz 2a0f91f56ffe76a706962f22d0ba32bede644238687bfd6cd411c3f13c25418c 74344 resolvconf_1.72_all.deb Files: 16bcd0a0dfee44406333b6d28c27cf51 1087 net optional resolvconf_1.72.dsc 6bf631213c97f89261d997c78f7b9506 82703 net optional resolvconf_1.72.tar.gz 43c5820e87ffe0935fdf71a9e0bd63ab 74344 net optional resolvconf_1.72_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlGRB4sACgkQ3VcITofi8ruGXAD+PsdFBmgJ+0as7qfNEgQiTtc+ dK0aHcxkQCWZOdIc+nUBAJ3BCbM7NPlyWmmRQqLliy6HTyXwoY6NuO9lKdqX9erA =Xgc1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ubuz5-0007ni...@franck.debian.org
Accepted resolvconf 1.71 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 25 Mar 2013 12:00:00 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.71 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.71) unstable; urgency=low . [ Thomas Hood ] * [7e4b50a] Accept multiple dns-nameserver options in /e/n/i, allowing at most one address per option line. Requires Jessie. * [cd7f88b] Simplify maintainer scripts: no longer handle upgrading from Squeeze; Pre-Depend on Wheezy version of initscripts. * [68654a4] Only linkify once; our memory that we have linkified is the existence of file /etc/resolvconf/do-not-linkify-resolvconf which can of course be created or deleted by the admin. *Do* linkify on dpkg-reconfigure --- same behavior as in Ubuntu but implemented without changing debconf answers. * [27551b1] Add Upstart job file from Ubuntu * [9b72d0e] resolvconf: Remove the *-runtime-directories options which were intended to ease maintenance when the Debian and Ubuntu versions were being maintained together. Now that the Ubuntu package is maintained separately and makes no use of these options, their raison d'être has vanished. Transfer the underlying code to the initscript and to the Upstart job file. * [9b854f8] if-down.d/resolvconf: Drop workaround for fixed #338348 * [27f6103] Remove refs to totd which has been removed from Debian * [06a14e1] Update README Checksums-Sha1: 8f823d05f2163b26da9dab444eaafc9b7250ded5 1087 resolvconf_1.71.dsc bdf80da395bc2530d0294f7390d5834190dfdba3 82616 resolvconf_1.71.tar.gz f86d2d075d4116d728eba887d56d8f2a80994eeb 74214 resolvconf_1.71_all.deb Checksums-Sha256: 92f83f6e59c66b6397e4af36a23d3ef523da1416d9fecb65442b774b4cf5c70c 1087 resolvconf_1.71.dsc f2ec30a0e89330c6cbc3117efd60639da8305782979844ee4a1906e4b0ca230c 82616 resolvconf_1.71.tar.gz e036dcfa36b8deb9d97f9b50933a7d0df8b2e3284c1e2d10de6f0511a65b3cf1 74214 resolvconf_1.71_all.deb Files: 6a808a3637465f6409a62a39eeb98e6b 1087 net optional resolvconf_1.71.dsc f073ab06b11584c8af86e7f84a56680e 82616 net optional resolvconf_1.71.tar.gz 92ce6cae0874392c042bfc0331d09a05 74214 net optional resolvconf_1.71_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlFQhLEACgkQ3VcITofi8rvdvAEAozab1uZIeS6VGYqy7nwh7AZF j8dNVSCqDzeIZLg1NHUBAJEze4h03HWDZ6NqUL4xwki8EUGlj2P8cQSYs0X6cbGJ =0WMO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ukb1n-0005er...@franck.debian.org
Accepted resolvconf 1.70 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 Feb 2013 20:00:00 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.70 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 513445 697435 Changes: resolvconf (1.70) unstable; urgency=low . [ Thomas Hood ] * [ec06f8d] Add NEWS item about the bind update script being disabled (Closes: #697435) * [ec06f8d] Change interface-order such that it more consistently prioritizes IPv6 records over IPv4 records and ifup records over DHCP-client records (Fixes LP#1094345). N.B., previously eth0.inet had lower priority than eth0.dhclient had, and now has higher priority. So now a dns-nameservers option in an inet dhcp stanza in /etc/network/interfaces can be used to override a bad IPv4 server address coming in via DHCP (Closes: #513445) * [9e26ca4] Drop DM-Upload-Allowed * [0863189] Use ifquery instead of grep /e/n/i in debian/config. Because of need for ifquery, add versioned Dependency on ifupdown. Instigated by debian-devel thread: http://lists.debian.org/debian-devel/2013/01/msg00159.html * [eef5e1c] update.d/libc: Don't restart nscd any more. Nscd now spontaneously re-reads resolv.conf when it changes (Fixes LP#1110331). This shouldn't have much effect since nscd's hosts cache was disabled by default in 2007 and restarting nscd unnecessarily did no harm. http://www.eglibc.org/archives/patches/msg00977.html * [f559774] resolvconf.8: Undocument the now-deprecated *-runtime-directories options and mention that static resolver options should be migrated to resolv.conf.d/base. * [396e5b1] resolvconf.8: Remove the statement, no longer true in Jessie, that an option can only be used once per /e/n/i stanza. Checksums-Sha1: dbddfde198fb1735619555e8a92903c1794a3086 1053 resolvconf_1.70.dsc 7d515431b61a6bfbd3dce726e8cab563bf861a2b 82725 resolvconf_1.70.tar.gz b73df204fe6b5082a2e32a6b78bd1b40ae06488d 73474 resolvconf_1.70_all.deb Checksums-Sha256: 7c13ca57afddc3047af26cfc364dafe019795a14cb9206e5ffe91f0424ff0954 1053 resolvconf_1.70.dsc 7bb1ccfb68d61a96b91d135c4048f464482b634b0fc4a4b9d9a0f56ced5b4bf6 82725 resolvconf_1.70.tar.gz c574f7b73db83c9c903edb37afb8b5668e9c85d0882b0db3b61196fdcb7347d1 73474 resolvconf_1.70_all.deb Files: 4f3f71fae9a9437ee488785a1f6b7593 1053 net optional resolvconf_1.70.dsc 95e19745790fd1c9a102ddde3bfdb15c 82725 net optional resolvconf_1.70.tar.gz 7548b5417d50a0bf91eed2215d909ada 73474 net optional resolvconf_1.70_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlEVJRgACgkQaGRzDfCV5eSILwCeMS4ww2DO4gOit5Gm5N1R0MNp j3kAn1BBlXC9DiQU2cSjJhHZ6AmQf4k+ =qw5G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1u3qsz-0006zh...@franck.debian.org
socket-based activation has unmaintainable security?
One of the most interesting statements in the recent udev discussion was Steve Langasek's claim that socket-based activation has fundamentally unmaintainable security. A couple people have asked for clarification and I would also like to know what problem Steve was referring to. Can someone please give me the golden clue? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5110dcec.4010...@gmail.com
Accepted resolvconf 1.69 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 17 Dec 2012 12:00:00 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.69 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 681623 687507 Changes: resolvconf (1.69) unstable; urgency=low . * [276fc24] Bump Standards-Version; no changes required * [6982da6] README: Name packages that clobber /etc/resolv.conf * [4cb082a] README: Update * [044e9a3] ip-up.d/000resolvconf: Do nothing if USEPEERDNS not set * [d988a9e] if-up.d/000resolvconf: Silently (for now) accept option name 'dns-nameserver' as a synonym for 'dns-nameservers' in anticipation of support in ifupdown (no sooner than wheezy+1) for duplicate options in a stanza, after which it will make sense to specify multiple nameserver addresses on equally many dns-nameserver lines * [e0db2cb] Deal with obsolete conf files (Closes: #687507, #681623) Checksums-Sha1: ef241ce4683b006f0b5fc48fc1933b7f49cdea6b 1076 resolvconf_1.69.dsc 479ff21a50a2086587ac3449474e9abc2b07dd9c 81207 resolvconf_1.69.tar.gz eb89f0340185a70e6dec034d23d1cb1a3cfc80f2 71770 resolvconf_1.69_all.deb Checksums-Sha256: f35c085126f21ae7a425910c1e6d7cc557ecf63ca22aa3aab8a1ca9cfedfd976 1076 resolvconf_1.69.dsc e386a6e5ac81d292edbc0d8fbd0cfbbdbb4a76ac06c5f08079a1aa8cc59f3fcb 81207 resolvconf_1.69.tar.gz 741434da483ce810e049272be1d59561947e50d8bf04fef09619733a6c932161 71770 resolvconf_1.69_all.deb Files: b76372cf4101db7fede4680a89b49551 1076 net optional resolvconf_1.69.dsc a5cacf9724f1b79a685cc5dfe2c643c9 81207 net optional resolvconf_1.69.tar.gz be666dcb7ca74343045375e55f37901c 71770 net optional resolvconf_1.69_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlDYJvAACgkQaGRzDfCV5eTQwwCdEaeUs0bFapWGS21QYKHLc6Tb la8An0H5ue5ZOfvONmzLgcYQMBsLi+kh =e+V7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tn4rl-00013k...@franck.debian.org
Accepted resolvconf 1.68 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 10 Sep 2012 11:46:05 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.68 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 683672 Changes: resolvconf (1.68) unstable; urgency=low . * [1527598] Add sk.po. Thanks to Slavko (Closes: #683672) * [7713764] Update resolvconf's ppp hook also to exit when passed /org/freedesktop/NetworkManager/PPP/* (LP: #994575, LP: #1046154) Checksums-Sha1: 525b9fc0e9df65273773b3831a980bfe2a0813ca 1110 resolvconf_1.68.dsc 65c8ba008746e168f37723d770be583b25fc24df 80682 resolvconf_1.68.tar.gz e7650058bcf1f0e7ef19df82e2828584f4a685a8 70222 resolvconf_1.68_all.deb Checksums-Sha256: 0bcdbd1473c0d472554b9cea27ec2ebfcb04e6d4622eceaaf97d83db307cfe6e 1110 resolvconf_1.68.dsc f88fec7e167afce6f6fb4c5304dd625b71521b278b826a857796451753c9a964 80682 resolvconf_1.68.tar.gz e4c101a0cbb9ff141021e79a58b57613e7d9e8e649873cbfdf3a7b03469cc171 70222 resolvconf_1.68_all.deb Files: a5bf74aafd8331c0062785c71c9468ef 1110 net optional resolvconf_1.68.dsc 61cca51474ccec74f3de15f44b182666 80682 net optional resolvconf_1.68.tar.gz d90e0b8c6ae06b51be6a7231412858fc 70222 net optional resolvconf_1.68_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlBPSS4ACgkQ3VcITofi8rszQAD9Hc/Y8F7gc/nKYdUjeJfnkZwB pbh0dGXM4J21Op4JJ6YA/jFMOfM8hHfOSTGJoL8imIVmOVFj9iP/oWFkzhCynsSn =LaTy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tbsef-sd...@franck.debian.org
Accepted resolvconf 1.67 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 19 Jun 2012 13:17:56 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.67 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.67) unstable; urgency=low . [ Thomas Hood ] * [5e645ac] Use more conventional name for record created by resolvconf's pppd hook script * [58da88f] Change resolvconf's pppd hook script such that it does not call resolvconf if pppd was run by nm-pptp-service (See LP#994575) * [16b4ae5] Bump Standards-Version; no changes Checksums-Sha1: 3c8c67272b437d04f914b88d557db14594fd4c57 1076 resolvconf_1.67.dsc fc1c7899d763c897a80bab169b8c06ebb88dc490 79002 resolvconf_1.67.tar.gz 71e60ff2ae724767c4c1f3488535294d384cb6d1 68960 resolvconf_1.67_all.deb Checksums-Sha256: df5801820c8ff088cb393b0502ff35463ecb80b4d78c8b8965a5d5223074ef53 1076 resolvconf_1.67.dsc 31b6f4489f4a2912d854244c3dca159a6610d314bc3893b5ec6291cc23304571 79002 resolvconf_1.67.tar.gz 9cea1742ca2132e1f512cce9bafd524e6ef266f3741f01ac39ca0371171a2b35 68960 resolvconf_1.67_all.deb Files: 924b59dbc293434669a50d7556311bc8 1076 net optional resolvconf_1.67.dsc 62da86743692cfe4290bee216ac6873e 79002 net optional resolvconf_1.67.tar.gz 2cd22dd140315ee1dcdc6f7752de05d0 68960 net optional resolvconf_1.67_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/g4KsACgkQaGRzDfCV5eRfVQCeMRR5ZrDguTi2W5CybWCKinXr 3a4AnAh+4cP+yGZnMRk0rHKDlTD8VYoW =qOpo -END PGP SIGNATURE- Accepted: resolvconf_1.67.dsc to main/r/resolvconf/resolvconf_1.67.dsc resolvconf_1.67.tar.gz to main/r/resolvconf/resolvconf_1.67.tar.gz resolvconf_1.67_all.deb to main/r/resolvconf/resolvconf_1.67_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sh6wk-0005tb...@franck.debian.org
Accepted resolvconf 1.66 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 08 Jun 2012 10:26:53 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.66 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.66) unstable; urgency=low . [ Thomas Hood ] * [ed8ab34] Silence lsattr error message in postinst * [23217c3] resolvconf(8): List allowed dns-* interfaces(5) options * [b69c873] and describe more verbosely how the libc update script generates the dynamic resolv.conf file (Fixes LP##990660 and LP#999337). Thanks to Nathan Stratton Treadway. * [aa99b9b] update.d/libc: Only run hook scripts if /etc/resolv.conf is a symbolic link to the updated dynamic file. Checksums-Sha1: 0e9d21d122b21a282ebf34316d6a5668911d9fb9 1108 resolvconf_1.66.dsc 2a1cf19d5a03fb24bd48044e736c1ec33e1c3dbc 78617 resolvconf_1.66.tar.gz 4cee400154f35a39d48812fb5ec7529728988213 68738 resolvconf_1.66_all.deb Checksums-Sha256: f3bebad0171f73a379e4483d3da8abb029c06343109f6c880642b85228ec45cb 1108 resolvconf_1.66.dsc a00e1e47525de8865c517c29bc860d212f27d63e854092b8c52d35b1f4a1d59c 78617 resolvconf_1.66.tar.gz cf7714f6c33ee83b76a2ec17468a7d4c87cfdc18222d39918fbd36125126ac3a 68738 resolvconf_1.66_all.deb Files: 71a03322790b3298bf1f06d0270e55c9 1108 net optional resolvconf_1.66.dsc 9e9b284a995c3263be2c9c9e07a9606a 78617 net optional resolvconf_1.66.tar.gz 1cb1f2e1b6037d3dd4b0a39903244d8f 68738 net optional resolvconf_1.66_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAk/SB/YACgkQ3VcITofi8rtPUQD/SoK5EXhb7yHp70BdGGoOrYOX z9WJxjkN8CQe0wcFS8gA/it6/1axFd44r1SPCHJ94AqaLN+L01MjKHncuihGcHS8 =gR/5 -END PGP SIGNATURE- Accepted: resolvconf_1.66.dsc to main/r/resolvconf/resolvconf_1.66.dsc resolvconf_1.66.tar.gz to main/r/resolvconf/resolvconf_1.66.tar.gz resolvconf_1.66_all.deb to main/r/resolvconf/resolvconf_1.66_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sd19a-0006qn...@franck.debian.org
Accepted resolvconf 1.65 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 13 Mar 2012 09:09:35 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.65 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 662724 Changes: resolvconf (1.65) unstable; urgency=low . [ Thomas Hood ] * [3f0a1a1] Create /etc/resolvconf/run and its target and subdir in the postinst as well as in the preinst (Closes: #662724) * [ae16ea8] In postinst, as last resort, create /run/resolvconf/ even if /run isn't a tmpfs. * [25711bf] ifupdown hook scripts: Don't return error to ifupdown (Addresses #661591 so far as resolvconf is concerned) * [8da29c3] Document that list-records doesn't list empty records. Add patterns for biosdevnames (See LP#949473) * [a998de3] Update default interface order patterns in list-records * [94baf61] resolvconf(8): Update ref to dhclient hook script (See LP#953257) Checksums-Sha1: d14346b950dfc228958d274ced251bbd73d61476 1074 resolvconf_1.65.dsc 5bde06d7bbc6d0a6e6c0d5f266e22d32291f4b41 77461 resolvconf_1.65.tar.gz 9d1e4de5c0fa9ac951b6a49b6822025929af40f6 67704 resolvconf_1.65_all.deb Checksums-Sha256: 5af0510a73896c8a491c399451c6d01fd2f55859e9d34bd66b382eafc4969b7a 1074 resolvconf_1.65.dsc 3876a50a71c5e3e08373b7e41d5ca9a6cf19cf48e9decb3ab0a7c67261d58785 77461 resolvconf_1.65.tar.gz 751ed0f845228b0d96258a620b41333227049406fa048801bbaf91a88d9a24ec 67704 resolvconf_1.65_all.deb Files: 567f6a75a4035caf9530c648912e0c0c 1074 net optional resolvconf_1.65.dsc 8411411956f986a43021fa7e71d1bae8 77461 net optional resolvconf_1.65.tar.gz bf2e876348d03237edbbe1652074173f 67704 net optional resolvconf_1.65_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+N52QACgkQaGRzDfCV5eRudwCdEdURYYKsovTvh0DgpG5nDwBg GFsAn2pHr4AdqKXHf1DpH+UIxMpWzzHI =Zdni -END PGP SIGNATURE- Accepted: resolvconf_1.65.dsc to main/r/resolvconf/resolvconf_1.65.dsc resolvconf_1.65.tar.gz to main/r/resolvconf/resolvconf_1.65.tar.gz resolvconf_1.65_all.deb to main/r/resolvconf/resolvconf_1.65_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1skgvx-0008cj...@franck.debian.org
On init in *Debian*
Technical and other merits of contending init systems have been discussed here at some length. I think we should focus on another question, namely, which alternative is best suited to *Debian*, taking into consideration Debian's developer community structure (many independent package maintainers, minimalistic policy) and the role of Debian in relation to other distributions, most importantly Ubuntu. Init system foo might be technically fabulous, but if maintaining foo in Debian requires frequent simultaneous changes to many packages then foo might not be well suited to Debian. By alternatives I mean alternative sets of sets of supported init systems: * sysvinit for all kernels * Upstart for Linux; sysvinit for others * systemd for Linux; sysvinit for others * sysvinit and optionally Upstart for Linux; sysvinit for others * sysvinit and optionally Upstart and optionally systemd for Linux, sysvinit and optionally systemd for others etc., etc., The proposal to drop support for kernels other than Linux has already been adequately aired. For the sake of focus I'd like to make the assumption in this thread that support for alternative kernels and architectures will not be dropped on account of the choice of init system alternative. Putting the question another way: is it most compatible with Debian's structure and consistent with its traditions to continue supporting sysvinit universally (enforced by policy) and to leave it up to maintainers, helped by others, to support other init systems alongside sysvinit? Then if things happen as they have in the past, Upstart enthusiasts will open bug reports requesting the inclusion of Upstart job configuration files; systemd enthusiasts will open bug reports requesting the inclusion of systemd service files, and so on. Or do you see some other approach as more compatible and consistent? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajn8kfa5vsjj3osz1cjuwyfwco_fpnamz96aq-h0xtvddqo...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Sun, Feb 26, 2012 at 17:24, Goswin von Brederlow goswin-...@web.de wrote: Maybe the solution isn't event base or dependency based. Maybe the right solution is event based and dependency based. In one sense this is obviously right. Any solution has to respond to various kinds of events and has to be able to serialize multiple activities that need to be serialized. Both Upstart and systemd do both of these things. Upstart provides event-oriented plumbing which can be used to do very many interesting things, almost all of which are wrong. The right ones are listed in the Upstart Intro, Cookbook and Best Practises. It looks as if systemd takes the approach of hard-coding all the right ones so that the user only has to choose which thing is right for his program. Systemd hides the event handling so the user doesn't have to think about them; she only has to think about the states. She has to think about states because dependencies are between states, e.g., her web application Foo's reqiurement that database Bar be running. If either Upstart or systemd (but not both) turns out to have a fundamental design flaw such that it cannot fulfill some important process management requirement, then that will make it easy for us to choose between them. But I haven't seen evidence that either one has such a flaw. So, the choice will be difficult because it has to be made by weighing many different and almost incommensurable pros and cons. -- Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJn8KfCGKsdoQnLF-wA=d9a_prmbdpwdehdauekisaoh1tb...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 20:17, Steve Langasek vor...@debian.org wrote: On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote: Upstart also does not support Should-Start which makes it impossible to provide corect init scripts for a number of services. For example autofs will not work if it uses nis because nis is not started before autofs. Due to the lack of Should-Start the only way to get nis to start before autofs would require autofs to depends on nis. The way to express this in upstart is to declare nis 'start on starting autofs or runlevel [2345]'. The relationship is written in the opposite direction compared with LSB init scripts, but is no less flexible. This will, however, start nis in parallel with autofs, whereas what is probably wanted is that nis be up and running before autofs is started. I guess that the wanted behavior has to be implemented through some sort of start-nis task which starts on autofs starting, blocks the latter so long as it runs, and stops when nis has started. Or perhaps there is an easier way. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajn8kfa0ydttos4d2ggzckch6o4h0bwazaepykufihgfpfw...@mail.gmail.com
Re: upstart: please update to latest upstream version
I have a few questions. First, to repeat the original question, will we be seeing Upstart 1.4 in Debian experimental or unstable? Second, I would be interested in reading a good technical comparison of Upstart and systemd. Does anyone have a URL for me? I know the System V init system fairly well but I am new to both Upstart and systemd. Obviously the two are similar insofar as they are both able to supersede SysV init. But my newbie impression is that the two are fundamentally different, Upstart being event-oriented and Systemd state-oriented from the user's point of view. So the choice between the two isn't just a matter of taste. Analogy: We want to rewrite an ancient line-numbered BASIC program and now have a choice between Python and Prolog. One of the two languages is likely to be better suited to the task at hand. Which is why I'd like to see a good, objective technical comparison. Or perhaps each language would be best suited to part of the task formerly performed by the BASIC program. Which raises a third question: is there any point in using *both* Upstart and systemd? Example off the top of my head: Upstart takes care of early boot and starts systemd which in turn starts service daemons. Does this make any sense, and if so, what would be the advantages and disadvantages of this? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajn8kfday1kgofrokn1i3+qehh4y8pehb57vqqp9jnjm+rr...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Thu, Feb 23, 2012 at 11:58, Goswin von Brederlow goswin-...@web.de wrote: Upstart also does not support Should-Start which makes it impossible to provide correct init scripts for a number of services. For example autofs will not work if it uses nis because nis is not started before autofs. Due to the lack of Should-Start the only way to get nis to start before autofs would require autofs to depends on nis. Is it really impossible to implement correct behavior using Upstart? Or is it just inconvenient to do so? Addressing partly the above and partly my own request for a technical comparison of Upstart and systemd, there is this: http://upstart.ubuntu.com/cookbook/#critique-of-dependency-based-init-systems --- but it doesn't go into much depth, isn't entirely unbiased and doesn't actually name systemd. -- Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJn8KfAxuQZu3OZDkqB5DDE7s9ia9k7WsR2xp=9pwabtyod...@mail.gmail.com
Eliminating bash scripts?
Recently I noticed some bug reports asking that scripts be
rewritten to run on (POSIX) sh. These weren't the familiar
(and completely justified) complaints about bashisms in scripts
shebanged #!/bin/sh. These were requests to rewrite #!/bin/bash
scripts as #!/bin/sh scripts. Why do this? The following reasons
were advanced.
* The package then has fewer dependencies
* ... and can then be installed on a system without bash.
* When /bin/sh is dash, the script will run faster
* ... and will run on a shell which is smaller and thus less buggy
* ... and more secure
* ... and, after all, standard, whereas bash is not,
* ... and consequently better understood by programmers,
* ... and portable, whereas bash is not.
* Indeed, dash is the future whereas bash is history.
* If sed has to be used, that OK, its regexps are better than
bash's extended globs.
I wonder what Debian folk think about these claims.
Should we be aiming to eliminate all bash scripts from Debian?
Are there real-world Debian systems that are minimal enough
to have trouble running bash, but not so minimal that busybox
has to be used?
One thing I would like to point out immediately is that a bash
script will not necessarily run faster if it has to be rewritten
to run on sh. This is especially true if ${//}s are replaced by
pipes to sed.
--
Thomas Hood
Accepted resolvconf 1.61 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 26 Sep 2011 09:42:11 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.61 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 642965 Changes: resolvconf (1.61) unstable; urgency=low . * [cbb5105] list-records: Add comment re: extglob; speed up final loop * [4492943] Eliminate bashisms from /sbin/resolvconf. (Other scripts in this package still use bash, though, so this does not close wish #519364.) Thanks to Stefan Monnier * [63da54b] update.d/libc: Only run-parts update-libc.d/ if the latter exists. (Closes: #642965) Checksums-Sha1: e52c785c8e7e1634d143e480f6da98f80d855424 1032 resolvconf_1.61.dsc 6b26e049c11db80be984df34d3e71d5569b9d645 76237 resolvconf_1.61.tar.gz 6269b6b1f4badbc3e033a3450ee91df2c99160ec 66500 resolvconf_1.61_all.deb Checksums-Sha256: 7504863b9d57fb6ed5d8351029b7e84c24ec9e2235a50c18bceb6d9c61c9ac5a 1032 resolvconf_1.61.dsc 0eaa97fa29f8e30a541d549abe76766e5e4edfa841721529c85616d7c0089908 76237 resolvconf_1.61.tar.gz ce4bd5075ee4703389bd54cc98e4b2e79508d44cce5f3441c706a614bcfbba4f 66500 resolvconf_1.61_all.deb Files: 9edf02ab3b972c1a268b9502915206db 1032 net optional resolvconf_1.61.dsc ac1cfa1abc7c690f1d8917f746ad80a5 76237 net optional resolvconf_1.61.tar.gz 84144d3cd2556e2d3f4eb8dc3c3641a5 66500 net optional resolvconf_1.61_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6ARzwACgkQaGRzDfCV5eSWFQCdGg0snJ2Of+bAPTwZHqjHcQXU 9uUAnRRe7BVr6mTPSihWIayJxYdi7E2Z =w2Ha -END PGP SIGNATURE- Accepted: resolvconf_1.61.dsc to main/r/resolvconf/resolvconf_1.61.dsc resolvconf_1.61.tar.gz to main/r/resolvconf/resolvconf_1.61.tar.gz resolvconf_1.61_all.deb to main/r/resolvconf/resolvconf_1.61_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1r87pm-0001lw...@franck.debian.org
Accepted resolvconf 1.59 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 23 Aug 2011 10:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.59 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 633014 635470 635775 Changes: resolvconf (1.59) unstable; urgency=low . * dhclient-enter-hooks.d/resolvconf: Add support for dhclient DHCPv6 (Closes: #635470) * postinst: Fail with message if /etc/resolv.conf is immutable (Closes: #635775) * Mention in resolvconf(8) that /etc/default/resolvconf has to be created if it is to be used to set resolvconf environment variables (Closes: #633014) * Drop outdated id.po Checksums-Sha1: 8c71ae550706ef49c665ba371e1c85a54390711f 1044 resolvconf_1.59.dsc 84922602cdea48673e14a6d9c4104c14ee3e0751 75892 resolvconf_1.59.tar.gz c53758e4927106e9279e8810e428384c88f354e1 65828 resolvconf_1.59_all.deb Checksums-Sha256: 7339c62a3ebcf8ccb29cba3e36ca89279c82a8575d755a5c35b68b55588640b8 1044 resolvconf_1.59.dsc 37691677cea24da66d6664c98668b5f16667c0133f17feb166f246ee923ad756 75892 resolvconf_1.59.tar.gz e6c90b4c3582488767135d64c6957b7b46ff951cd2e785acc250a97cdc2cfd6a 65828 resolvconf_1.59_all.deb Files: 276c58604818066b1fa536a1b958231f 1044 net optional resolvconf_1.59.dsc 59b20258bb8a3c25b8c4083fc0279547 75892 net optional resolvconf_1.59.tar.gz 1938221d42b073762bbd365b3faae353 65828 net optional resolvconf_1.59_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5TsAUACgkQaGRzDfCV5eRlCACfVABuekmJs4UgL+6gfQ3PWwuP 4TUAnjnSZUP5qE44k8ipQKObdpimbEbU =m8S+ -END PGP SIGNATURE- Accepted: resolvconf_1.59.dsc to main/r/resolvconf/resolvconf_1.59.dsc resolvconf_1.59.tar.gz to main/r/resolvconf/resolvconf_1.59.tar.gz resolvconf_1.59_all.deb to main/r/resolvconf/resolvconf_1.59_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qvsjt-0006jv...@franck.debian.org
Accepted resolvconf 1.56 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 06 Jun 2011 15:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.56 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 629022 629165 629186 629201 629411 Changes: resolvconf (1.56) unstable; urgency=low . [ Thomas Hood ] * Create /etc/resolvconf/run as a directory if no tmpfs is available into which it can symlink. (Closes: #629186) * Eliminate warning brought to light by piuparts: * Grep /etc/network/interfaces only if it exists * Run dpkg-trigger with --no-await * Update README * Update debconf template translations: * sv.po thanks to Martin Bagge (Closes: #629022) * ru.po thanks to Yuri Kozlov (Closes: #629165) * de.po thanks to Helge Kreutzmann (Closes: #629201) * eu.po thanks to Iñaki Larrañaga Murgoitio (Closes: #629411) Checksums-Sha1: e6fc79d5a637c0e5687fa95ff81f3bd8736a0544 1044 resolvconf_1.56.dsc a289367050077986c2cced58e57cfd097cfb0af2 75564 resolvconf_1.56.tar.gz 5e6b752a464aaafef3fae113a1aa54d973ef4e25 64294 resolvconf_1.56_all.deb Checksums-Sha256: 6ac817e79d48a11c9f99d49069975d3e9074f1e05f0d658b630a503129abd477 1044 resolvconf_1.56.dsc d57e87dd5a0648c3f949e999fe7cf9e83e46711f1e34390b156750b3f55a2a60 75564 resolvconf_1.56.tar.gz 028bd9bf83b5217f799320280644b5bbf63e4d87f796acbf2e534c562f590542 64294 resolvconf_1.56_all.deb Files: 5a17e9c35238a0451a4c783ddc407eb1 1044 net optional resolvconf_1.56.dsc 060f6ed8c64724378484e7e0cff89f4c 75564 net optional resolvconf_1.56.tar.gz fdfec13010b84a62885b8b74bf81f226 64294 net optional resolvconf_1.56_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3s5dIACgkQaGRzDfCV5eR3RgCeLSO1FTYWuBLqS6hdTouMUoKR +VsAnA1Pk4FFkaJ+ympZtwdLcwhd4HLq =jeRK -END PGP SIGNATURE- Accepted: resolvconf_1.56.dsc to main/r/resolvconf/resolvconf_1.56.dsc resolvconf_1.56.tar.gz to main/r/resolvconf/resolvconf_1.56.tar.gz resolvconf_1.56_all.deb to main/r/resolvconf/resolvconf_1.56_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qtb6i-0003wf...@franck.debian.org
Accepted resolvconf 1.55 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 31 May 2011 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.55 Distribution: unstable Urgency: medium Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 628524 628669 628719 Changes: resolvconf (1.55) unstable; urgency=medium . [ Thomas Hood ] * Include old update.d/bind script for illustration purposes as /usr/share/doc/resolvconf/resolvconf-update-bind. * Use /usr/lib/resolvconf/dpkg-event.d instead of a /etc/... path for dpkg event hook scripts. The scripts don't need to be configuration files. * In postrm print a message and put up debconf note recommending reboot. (Closes: #628524) * Remove comments from /etc/resolv.conf on removal. * Remove /lib/init/rw/resolvconf on purge. (Closes: #628669) * Update debconf template translation * eu.po thanks to Iñaki Larrañaga Murgoitio (Closes: #628719) * Clean up many .po headers * Update README Checksums-Sha1: af672b6cbce86a16f95081f96e1a33fdf9f85158 1044 resolvconf_1.55.dsc 4dc0a416d89db63ba431583392585b4beb82429a 75000 resolvconf_1.55.tar.gz 9202ab4cb95a59f221c1e1a5d0702dae186d6fbd 63488 resolvconf_1.55_all.deb Checksums-Sha256: 321103b23358f78dccc2dd39298db307f9a91ce3cab7bdb524f262218e754e78 1044 resolvconf_1.55.dsc 04ce901836768534a75e97c44f7a90b4c919f238653f5d454620d1ab50af4927 75000 resolvconf_1.55.tar.gz b8fa582dc8510eea491777c17701dcad686699a932f6df5a395e55d4576c4f9c 63488 resolvconf_1.55_all.deb Files: 8bfb0c9038d07fc93486a3ff5da9d5ed 1044 net optional resolvconf_1.55.dsc a22fe453abf3debe4bdbc5a3874ff57e 75000 net optional resolvconf_1.55.tar.gz 20963370fbc36bd46a7ded03e98c863c 63488 net optional resolvconf_1.55_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3mFMUACgkQaGRzDfCV5eR04wCfcrBVWRLl3X58X0oRXVFW1XV7 0HgAoIhdfYuL1OnMPaF7gN+b62XpFw1E =sBa/ -END PGP SIGNATURE- Accepted: resolvconf_1.55.dsc to main/r/resolvconf/resolvconf_1.55.dsc resolvconf_1.55.tar.gz to main/r/resolvconf/resolvconf_1.55.tar.gz resolvconf_1.55_all.deb to main/r/resolvconf/resolvconf_1.55_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qrixa-mj...@franck.debian.org
Accepted resolvconf 1.53 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 20 May 2011 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.53 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 268073 567059 608933 627440 627691 Changes: resolvconf (1.53) unstable; urgency=low . [ Thomas Hood ] * Dpkg trigger is now called 'resolvconf-enable-updates' and is now intended only for internal use. * Other packages are notified of the installation of resolvconf via hook scripts that they put in /etc/resolvconf/packaging-event.d/ as described in the Usage information for maintainers section of the resolvconf README file. (Closes: #567059, #627691) * Update my e-mail address in various places * Update debconf template translations * cs.po thanks to Miroslav Kure (Closes: #627440) * Remove /etc/resolvconf/update.d/bind (Closes: #608933, #268073); include it as /usr/share/doc/resolvconf/resolvconf-update-bind for illustration purposes. Instead of this old script, the bind9 package should include a hook script /etc/resolvconf/update.d/bind9 as has been requested in #483098. * Due to changes in Debian infrastructure change debian/control fields Vcs-Svn and Vcs-Browser. Ref: http://lists.debian.org/debian-devel-announce/2011/05/msg9.html Checksums-Sha1: 956f1e111479bf0a3b22b3e3dee3b9a3e9c28d35 1044 resolvconf_1.53.dsc e873f66780cecc94f987138aed7b90ea341bade2 83176 resolvconf_1.53.tar.gz cd08dd5d249570937029f22e66b5fd75330c5f2e 61922 resolvconf_1.53_all.deb Checksums-Sha256: 80968fd37d09e100a3dee68384e4e71cbb1eaf87380f8028b590559a9506915a 1044 resolvconf_1.53.dsc c3fdab3c2ba69ba464522a30bd43b4dc7c4d3920bedd9acf1ed212bc4b4d013d 83176 resolvconf_1.53.tar.gz 6ed9c23f4a2da6d73b1f401277f92cb537b75eb7a37ae89cbdb2f7c96da22140 61922 resolvconf_1.53_all.deb Files: e36b06f60c3725602e34af863619cf9a 1044 net optional resolvconf_1.53.dsc 2befcdee11425cc24292d395583c9775 83176 net optional resolvconf_1.53.tar.gz e5441164a5bf09fa44458f394a3aa7fa 61922 net optional resolvconf_1.53_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3cxe4ACgkQaGRzDfCV5eTCcACeNQ/+aBz595ouHp9P7j3igYWD tF4An0kcJVixbeT+Yeq2HoMFWNqGqPzl =Z8Pk -END PGP SIGNATURE- Accepted: resolvconf_1.53.dsc to main/r/resolvconf/resolvconf_1.53.dsc resolvconf_1.53.tar.gz to main/r/resolvconf/resolvconf_1.53.tar.gz resolvconf_1.53_all.deb to main/r/resolvconf/resolvconf_1.53_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qpb5r-0005z4...@franck.debian.org
Accepted resolvconf 1.54 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 25 May 2011 13:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.54 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Changes: resolvconf (1.54) unstable; urgency=low . [ Thomas Hood ] * Put exit 0 at the end of each maintainer script Checksums-Sha1: 5ba683b9fe5602e296156d5749f49699a86aca44 1044 resolvconf_1.54.dsc 039be468d651ad889913d4dce46d51cb28068dce 83211 resolvconf_1.54.tar.gz 41d01bf01743e128d933956fdf806129d642f433 61970 resolvconf_1.54_all.deb Checksums-Sha256: 6364d5eef7d65189496f171c542f73b52cdd6655e197e2cde5165de22218bb0c 1044 resolvconf_1.54.dsc 3fd4b40fbbd6f8709ac5c8aba5558b762c9c0ed2d5fe131f2b797b8b7d8146e6 83211 resolvconf_1.54.tar.gz 8c222add059392f78b90480a0b53e59570dee9727b0973f1ff5b6917bdee81ee 61970 resolvconf_1.54_all.deb Files: f9110a806e373cb9108711d57a26d5cd 1044 net optional resolvconf_1.54.dsc 1a604279f91f34b9702b6a55c859807d 83211 net optional resolvconf_1.54.tar.gz 669aee738bcd7478875ebdf0603808a0 61970 net optional resolvconf_1.54_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3dOJYACgkQaGRzDfCV5eTD8wCfQDpqSf+bEEm/D2U75IHZ9P3p lbEAoIsdweVroDXjOiPpUNrB0OhvthQ9 =MIi+ -END PGP SIGNATURE- Accepted: resolvconf_1.54.dsc to main/r/resolvconf/resolvconf_1.54.dsc resolvconf_1.54.tar.gz to main/r/resolvconf/resolvconf_1.54.tar.gz resolvconf_1.54_all.deb to main/r/resolvconf/resolvconf_1.54_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qphio-yf...@franck.debian.org
Accepted resolvconf 1.52 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 13 May 2011 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.52 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 625623 625786 625896 626030 626302 626675 Changes: resolvconf (1.52) unstable; urgency=low . [ Thomas Hood ] * Add debian/source/format at lintian's suggestion * Update debconf template translations * ru.po thanks to Yuri Kozlov (Closes: #625623) * sv.po thanks to Martin Bagge (Closes: #625786) * nl.po thanks to Vincent Zweije (Closes: #625896) * de.po thanks to Helge Kreutzmann (Closes: #626030) * da.po thanks to Joe Dalton (Closes: #626302) * fr.po thanks to Christian PERRIER, Steve Petruzzello and David Prévot * pt.po thanks to Pedro Ribeiro (Closes: #626675) * Remove long outdated pt_BR.po * Don't run mkdir with -v in debian/p*inst Checksums-Sha1: 13a24ccd9ed0a66e5f5eb05124f01888b7942131 1079 resolvconf_1.52.dsc a1f4330de9baefa9ee04e2488d836c894b0e7d2f 83194 resolvconf_1.52.tar.gz 707860491a4ac7ea4f3a54a6bfa72ec0ac4b7c96 61518 resolvconf_1.52_all.deb Checksums-Sha256: 83160b8b64a6dc2439ed284b11df5aa2f49a0cb609d52d884fab97faedb26380 1079 resolvconf_1.52.dsc 0959bc70a4568badbe8733a6941054867b6c361f7379fb12d8ee8ccb422bd47e 83194 resolvconf_1.52.tar.gz 25d95274e723a4b76d30a75488198e239bbd7d4e2b4bdc6ca181ec1faf2afb83 61518 resolvconf_1.52_all.deb Files: 4a37c5fb7ad92523e24ce2757d5dba71 1079 net optional resolvconf_1.52.dsc 39e4d665595548fe3f3b0bddf2e290e7 83194 net optional resolvconf_1.52.tar.gz 293f413e9374d0f6b99811c27a997a87 61518 net optional resolvconf_1.52_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3RmE4ACgkQaGRzDfCV5eT90QCeLjnLzcvnL704r6xMcsZQJas3 k+0AnjAoPH3T6Kqe+IxzLXagOHIUeDlX =4kJL -END PGP SIGNATURE- Accepted: resolvconf_1.52.dsc to main/r/resolvconf/resolvconf_1.52.dsc resolvconf_1.52.tar.gz to main/r/resolvconf/resolvconf_1.52.tar.gz resolvconf_1.52_all.deb to main/r/resolvconf/resolvconf_1.52_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qm5ek-0006dw...@franck.debian.org
Accepted resolvconf 1.51 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 03 May 2011 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.51 Distribution: experimental Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 568820 Changes: resolvconf (1.51) experimental; urgency=low . [ Thomas Hood ] * Rename 'TRUNCATE_NAMESERVER_LIST_AFTER_127' to 'TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS' and make it cause the nameserver list to be truncated also after an IPv6 loopback address. (Closes: #568820) * Normalize contents of records -- i.e., strip out comments and whitespace and shorten IPv6 nameserver addresses. This makes it easier to implement the change above. * Add debian/test-normalization script to test the normalization code. * Update resolvconf/downup-interfaces template again. Ready for re-translation! Checksums-Sha1: 4afba91c8454193b9ad2ea3a15b84b3e65db0926 1070 resolvconf_1.51.dsc 4036ac791efe7f7db4ccf9dcb338ac25dd87c7c2 88300 resolvconf_1.51.tar.gz d968de9755d10b10ed4d4f4209451fb1bd325b52 58114 resolvconf_1.51_all.deb Checksums-Sha256: 034587b82ae27eca123f2e67972f51507355dcc201a05c6bb9aedfa29cfcd3ec 1070 resolvconf_1.51.dsc 7e63421dac1f722de625ab55722571cf56befa30b22dab3e4e9e29a0f30f3004 88300 resolvconf_1.51.tar.gz 4058e929eb89af259f8c72170443732957197606d9e6871a3ecd6cc79a2b66bf 58114 resolvconf_1.51_all.deb Files: 578b496823118897a50673234ff4692f 1070 net optional resolvconf_1.51.dsc 41e3f9c30839ef6543911100a920a67f 88300 net optional resolvconf_1.51.tar.gz 09e801ed8690fabdf3a6a2ec8391d9e3 58114 net optional resolvconf_1.51_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3AFbsACgkQaGRzDfCV5eS8ugCdGv39mThZNPJYLToN4GZkaqMp wJgAnjrTOsL4f4YLvHYOh0xrWJRU4Zq9 =uysJ -END PGP SIGNATURE- Accepted: resolvconf_1.51.dsc to main/r/resolvconf/resolvconf_1.51.dsc resolvconf_1.51.tar.gz to main/r/resolvconf/resolvconf_1.51.tar.gz resolvconf_1.51_all.deb to main/r/resolvconf/resolvconf_1.51_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhhen-0004hc...@franck.debian.org
Accepted resolvconf 1.50 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 27 Apr 2011 12:00:00 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.50 Distribution: experimental Urgency: low Maintainer: resolvconf maintainers resolvconf-de...@lists.alioth.debian.org Changed-By: Thomas Hood jdth...@gmail.com Description: resolvconf - name server information handler Closes: 414692 Changes: resolvconf (1.50) experimental; urgency=low . [ Thomas Hood ] * Also migrate non-symlinked directory /etc/resolvconf/run to /run/resolvconf. * Be interested in own trigger and enable updates only when triggered. This could eliminate some superfluous updates on installation. (Evidence that a package is allowed trigger itself: http://lists.debian.org/debian-dpkg/2007/10/msg00175.html) * Add section Usage information for maintainers to the README file discussing the new trigger. * Document the original file in resolvconf(8). (Closes: #414692) * Improve markup of resolvconf(8). Checksums-Sha1: c0c2796748df67899f1952f4744f621d9e8db8ec 1070 resolvconf_1.50.dsc 9c84dd37aba2e0f4ec20508b34720eeff6acdbac 86198 resolvconf_1.50.tar.gz 0dd1fce2d1e3fedd9423433d0c9be0ded8133eca 57184 resolvconf_1.50_all.deb Checksums-Sha256: 4d165df09b04bd1a694208c00c3d6c0d23e449f8556010ee366eb449b2361d8c 1070 resolvconf_1.50.dsc c1af412d9fcafa355d32dc200877a3d1bb405f1b5bb4184eb8471305eaa237f6 86198 resolvconf_1.50.tar.gz 9404448c803194aa46478b03cc2bcd99a6459c6d114856cbe8e8a9a7730cddd8 57184 resolvconf_1.50_all.deb Files: 9079cbc156b568e57a371878d84b6c71 1070 net optional resolvconf_1.50.dsc c630856e35c3787795dfc6f9b1522797 86198 net optional resolvconf_1.50.tar.gz 9617db9c1ca12123aabcaae03f1d40cf 57184 net optional resolvconf_1.50_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk25LFEACgkQaGRzDfCV5eT3twCggRQWF5o+56aME2+eifdqUq4U r7UAnjfLBlo3A4i0EctY8qltC8BfVhSO =PtTg -END PGP SIGNATURE- Accepted: resolvconf_1.50.dsc to main/r/resolvconf/resolvconf_1.50.dsc resolvconf_1.50.tar.gz to main/r/resolvconf/resolvconf_1.50.tar.gz resolvconf_1.50_all.deb to main/r/resolvconf/resolvconf_1.50_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qfnmw-0006hn...@franck.debian.org
Re: /run in experimental
Resolvconf 1.49, which makes use of /run instead of /lib/init/rw for storing run-time data, has just been uploaded to experimental. Those testing the experimental initscripts package (2.88dsf-13.4) are invited to test this experimental resolvconf package along with it. -- Thomas Hood resolvconf maintainers resolvconf-de...@lists.alioth.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dae67ee@gmail.com
Re: /run support for wheezy: final (I hope) call for testing
Another problem that comes to mind is the Too many levels
of symbolic links errors. If a symbolic link is added at
the beginning of a system path are we increasing the risk
that this error will be triggered?
$ grep MAX_NESTED_LINKS linux/namei.h
enum { MAX_NESTED_LINKS = 8 };
char *saved_names[MAX_NESTED_LINKS + 1];
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dab404a.9080...@gmail.com
Re: Only forbid use of old alternatives to /run in wheezy+1?
This is not to say we couldn't remove it on startup though. You should not remove /lib/init/rw on the next reboot. If the upgrade stops due to an error then the system might be rebooted before the upgrade is continued. /lib/init/rw needs to remain present until all packages using it have been upgraded to wheezy. Only the wheezy+1 version of initscripts is in a position to assume that all other packages have been upgraded to wheezy. You can try to force things using Breaks and other tricks but I don't see the reason to complicate things and take risks. -- Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dab4881.9060...@gmail.com
Only forbid use of old alternatives to /run in wheezy+1?
While I applaud the introduction of /run, I have some concerns about how quickly users of alternatives to /run could be required to switch to the new location. Consider the following scenario. Package P is using /lib/init/rw. At some point the new version of initscripts is installed. The latter's postinst makes /run available, initially as a bind mount of /var/run, post-reboot as a separate tmpfs. OK. But P has not been updated yet; it is still using /lib/init/rw. So initscripts's postinst certainly can't remove /lib/init/rw immediately. What if the latter merely arranges for the removal of /lib/init/rw after the next reboot? Then if the admin reboots, P is broken after the reboot until it gets upgraded. But if P is some kind of infrastructure package then its breakage could cause the administrator anguish. Note that P's maintainer can't do anything about this problem because it is the squeeze version of P that gets broken. The squeeze version of P simply didn't expect that /lib/init/rw would suddenly disappear. I suppose the new initscripts could Conflict with P in order to force upgrade of P at the same time as initscripts; but this makes the upgrade process more rigid and fragile. If the upgrade fails for one reason or another after initscripts has been installed then, again, P is broken after reboot until it gets upgraded. But does the system still have access to the network? I think that P should be allowed to continue using /lib/init/rw at least until the wheezy version of its postinst runs. But this occurs after initscripts's postinst runs. And that is the last chance initscripts has to eliminate /lib/init/rw in wheezy. So I conclude that initscripts should only eliminate /lib/init/rw in wheezy+1. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikb9w+-mirnnceykt1z2wk01tm...@mail.gmail.com
Resolvconf trigger? (Re: #567059)
Hi. I am considering introducing a trigger to the resolvconf package in order to solve the problem (discussed in #567059) where resolvconf is installed on a system where a caching nameserver is already running. The problem is that, on installation, resolvconf takes control of /etc/resolv.conf but the nameserver has not yet registered its address (normally 127.0.0.1) with resolvconf; so when resolvconf updates the resolv.conf file the nameserver's address is incorrectly absent. The problem disappears after reboot, but that is obviously not good enough. The idea is that resolvconf activates a trigger and caching nameservers register interest in the trigger. When triggered, a caching nameserver checks to see if resolvconf is now installed; if so then the nameserver registers its IP address with resolvconf. Questions: 1. Is this the best way to solve the problem? 2. What races and other pitfalls should I watch out for? 3. What is an appropriate name for the trigger? 4. Does anything have to be approved or discussed on a particular mailing list or can I go ahead and introduce the trigger and then ask the maintainers of caching nameservers to make use of it? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da814ec.7010...@gmail.com
Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)
First of all, thanks to Roger Leigh for leading this effort. Roger Leigh wrote: Proposal: Switch the default for all tmpfs mounts from 50% to 20%; it's still very large, but you have to mount many more to be able to break your system. He should have said ... but you have to mount *and fill* many more to be able to break your system. The current tmpfs size of 50% suffices to protect the system should any *one* tmpfs be completely filled by a wayward process. Is that not good enough? I.e., do we really need to worry about the case where multiple tmpfses get filled simultaneously? Does it matter whether the system fails due to filesystem full or due to OOM? Broken is broken. If we do need to worry about that case then the real solution is not arbitrarily to increase the number-of-tmpfses-to-fill-up-in- order-to-break-the-system from 2 to 5. One real solution is to limit the total amount of memory that all tmpfses can take up to some value less than 100%. Another is to look more closely at which tmpfses could reasonably be attacked and limit the sum of *their* sizes to something less than 100%. -- Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da576b3.7010...@gmail.com
Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)
I just realized that I misunderstood Roger Leigh's posting and so my previous message was mostly superfluous. My apologies. 1. His statement but you have to mount many more to be able to break your system was correct (and can be made more explicit by adding ... by filling them all). 2. His proposal *was* to reduce the size of all tmpfses (together) to 50%, as follows: /run 10% /run/shm 20% /tmp 20% /run/lock, /lib/init/rw very small What remains of my previous message are my two questions: 1. Is OOM importantly worse than a full system tmpfs? I think so too, but 2. Even if so, do we have to worry about OOM happening because *multiple* tmpfses got filled? We are already safe from OOM if one tmpfs (whose size is 50% of memory) gets filled. -- Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da5bf6e.9090...@gmail.com
openresolv vs. resolvconf
I am interested in how openresolv stacks up against resolvconf. For starters the openresolv home page conveniently compares[0] openresolv with resolvconf. * Works with POSIX shell and userland Nice. Resolvconf requires bash. But since resolvconf scripts are short, and bash is Essential in Debian, this doesn't seem like a major advantage. * Does not need awk, grep or sed which means we can work without /usr mounted Resolvconf does not use awk. It does use grep and sed but these aren't under /usr. This is no accident: resolvconf was also designed to work without /usr mounted. * Works with other init systems than Debians' out of the box * Available as a 2 clause BSD license Compatibility with non-Debian systems is an advantage if it has the result that most distros can standardize on one package. Resolvconf has been ported to other distros and a quick Google search reveals that openresolv is available for several distros, but I don't know what the adoption statuses of the packages are. Resolvconf is GPL. * Prefer configs via IF_METRIC for dynamic ordering Sounds like a good idea. If two addresses are available, put the one available via a route with the lowest metric first in the nameserver list. Resolvconf doesn't do this at present. * Configures zones for local resolvers other than libc Resolvconf and openresolv are primarily middleware that mediate between interface configurers and name servers and resolvers. Both can and do support alternative resolvers to the glibc resolver, via hook scripts. Any hook scripts for one can presumably be ported quite easily to the other and vice versa. An important advantage of openresolv could be that it isn't, like resolvconf, undermaintained[1]. If openresolv is truly a drop-in replacement for resolvconf then migration from resolvconf to openresolv would be one way of solving this undermaintenance problem. What further pros and cons do people see out there? [0]http://roy.marples.name/projects/openresolv/wiki/OpenResolvReasons [1]http://bugs.debian.org/477723 -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf4e6bf.7030...@gmail.com
How to warn about need to port changes to new configuration file?
It is planned that an upcoming version of resolvconf will add a new hook script for isc-dhcp-client which is identical to the existing one for dhcp3-client. An administrator who has made local changes to the latter hook script should probably make the same changes to the former. Is there a need to warn the administrator that he should (presumably) re-implement his changes in the new file? If so, what is the best way to warn him? Should debconf notes be used? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1b7d4b.4060...@gmail.com
Re: libnss-myhostname instead of mangling /etc/hosts
One reason for resolving the system hostname to 127.0.1.1 in an NSS service is that this allows us to list that service last on the hosts: line in /etc/nsswitch.conf, thus making 127.0.1.1 the resolved address of last resort, coming after addresses resolved via /etc/hosts and/or DNS. Please see http://lists.debian.org/debian-glibc/2005/06/msg00173.html for one of the earlier discussions about this issue. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c18c3a1.7060...@gmail.com
Accepted resolvconf 1.42 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 03 Aug 2008 21:27:56 +0200 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.42 Distribution: unstable Urgency: high Maintainer: resolvconf maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: resolvconf - name server information handler Closes: 491780 493501 493608 494084 494872 Changes: resolvconf (1.42) unstable; urgency=high . [ Thomas Hood ] * init script: Add X-Start-Before and Should-Stop dependencies on ifupdown and networking (Closes: #493501, #494084, #494872) * [Debconf translation updates] * Japanese (Closes: #493608) * Swedish (Closes: #491780) Checksums-Sha1: cda4ad55cfc6dc374171a2c00b56ebbc417bb5fd 1113 resolvconf_1.42.dsc 6f94286491bf24c591b3e37d3c17cf23f400e8af 73023 resolvconf_1.42.tar.gz d47db02acae2d911ad5457c8062ef804483cb54b 53634 resolvconf_1.42_all.deb Checksums-Sha256: 2dadf956af2122a475b5ab1084c8e444b474509fb669fa8173c0012cd50d2a69 1113 resolvconf_1.42.dsc 5fbaebc8349e310d1707c74659b3dc698341c2edfa2773ad6f2570563ad49498 73023 resolvconf_1.42.tar.gz d33f847303425809c7ec63248a08bd4694d0037ea512c2fc9fa7dda4814f39f1 53634 resolvconf_1.42_all.deb Files: 04f4f321348a27f347a1b4bc575711a3 1113 net optional resolvconf_1.42.dsc 205919a6754c93f61c76cd8f851c81b3 73023 net optional resolvconf_1.42.tar.gz c701b90399f9eaef6b3000b1371bdfda 53634 net optional resolvconf_1.42_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIpeuK20zMSyow1ykRAsxQAKCfj3/MxhdX039zantUWRBh8bQtuQCgyGny binXJ2KwNJjF3hCDrzoprhc= =9nuU -END PGP SIGNATURE- Accepted: resolvconf_1.42.dsc to pool/main/r/resolvconf/resolvconf_1.42.dsc resolvconf_1.42.tar.gz to pool/main/r/resolvconf/resolvconf_1.42.tar.gz resolvconf_1.42_all.deb to pool/main/r/resolvconf/resolvconf_1.42_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting resolvconf back into testing
Peter Samuelson wrote: Looks like you just need to wait 4 more days. Lenny isn't frozen yet, not for optional packages. OK, thanks. (I was under the impression that some sort of intervention was required in order to undo a removal.) -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting resolvconf back into testing
On 15 June the resolvconf package was removed from testing due to an RC bug. A fixed version of the package has been uploaded and is now in unstable. I would like to request that the resolvconf package be re-admitted to testing. Unfortunately I haven't received any responses to this request from the DDs on the resolvconf maintenance team. I hope that some DD who reads d-d can take care of ushering resolvconf back into testing. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mwavem 2.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 21 Apr 2008 13:48:14 +0200 Source: mwavem Binary: mwavem Architecture: source i386 Version: 2.0-3 Distribution: unstable Urgency: low Maintainer: Debian mwavem maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: mwavem - Mwave/ACP modem support software Closes: 476761 Changes: mwavem (2.0-3) unstable; urgency=low . * Deal with bashisms in sh scripts: * Switch to #!/bin/bash in /usr/sbin/mwavemd * s/kill -9/kill -s KILL/ in /etc/init.d/mwavem Thanks to Raphael Geissert for pointing out the problems. (Closes: #476761) * Add LSB headers to initscript Checksums-Sha1: d89e5c2c84037dd77c22326c75f1e33f03668021 1046 mwavem_2.0-3.dsc 58c723db2b3fbc91c5c7c6b690e667046d032c17 16962 mwavem_2.0-3.diff.gz 603b63ae9085fe044ae7f34c93d5b4d30a204b57 930182 mwavem_2.0-3_i386.deb Checksums-Sha256: 6d4174405c33bc8845ec7bf2fd38c525d6e0eacebd47fe482ab9477ef78445de 1046 mwavem_2.0-3.dsc 3865a5b1efa70c91d23a387f0848265fb58e1e12e411b40b80216576afec88d7 16962 mwavem_2.0-3.diff.gz b7cc0e86e55350f86a6037cdf449bd603616b9a68cf191cd8499882f00391d12 930182 mwavem_2.0-3_i386.deb Files: b8ab6d5f9534ac37cbb0798909bddd2b 1046 non-free/utils extra mwavem_2.0-3.dsc 63b7387e35d84a3b547b307d614e6d8f 16962 non-free/utils extra mwavem_2.0-3.diff.gz fba9e9177bab5fa246e98598f8037c8c 930182 non-free/utils extra mwavem_2.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIDfIupdwBkPlyvgMRAqo4AJ9ZX6vmxyFrIP7ecD6LV8VgHlG3hQCfUVqv pKBHmjjzpYJ5Esp1S+j6BnA= =lQ88 -END PGP SIGNATURE- Accepted: mwavem_2.0-3.diff.gz to pool/non-free/m/mwavem/mwavem_2.0-3.diff.gz mwavem_2.0-3.dsc to pool/non-free/m/mwavem/mwavem_2.0-3.dsc mwavem_2.0-3_i386.deb to pool/non-free/m/mwavem/mwavem_2.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted resolvconf 1.38 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 Dec 2007 12:00:00 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.38 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: resolvconf - nameserver information handler Closes: 412511 413752 415783 431181 451751 Changes: resolvconf (1.38) unstable; urgency=low . [ Thomas Hood ] * Remove ru versions of man pages which failed lexgrog check * Add initscript lsb header (Closes: #451751) * Eliminate obsolete checks for old bad hook scripts (Addresses but does not close # 388956) * New nscd pidfile location is /var/run/nscd/nscd.pid (Closes: #415783) Thanks to Bob Knock. * Add gl.po, thanks to Jacobo Tarrio (Closes: #412511) * Add pt.po, thanks to Miguel Figueiredo (Closes: #413752) . [ Daniel Kahn Gillmor ] * Use /lib/init/rw instead of /dev/shm (Closes: #431181) Thanks, Roger Leigh! Files: e5f0fe7414a7775dcdf68989bc80f7a1 736 net optional resolvconf_1.38.dsc e5ca27168f615ca3fc8b60834e6659b4 70531 net optional resolvconf_1.38.tar.gz 682388d3f3ddf0210a6dd9132bede93f 50832 net optional resolvconf_1.38_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHg6qAaGRzDfCV5eQRAqx4AJ9HG61HmmUDcDDnj76GkbuYySDCKgCgjZvc ji8XCafOVjqppJudrZh6UkE= =U2it -END PGP SIGNATURE- Accepted: resolvconf_1.38.dsc to pool/main/r/resolvconf/resolvconf_1.38.dsc resolvconf_1.38.tar.gz to pool/main/r/resolvconf/resolvconf_1.38.tar.gz resolvconf_1.38_all.deb to pool/main/r/resolvconf/resolvconf_1.38_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted thinkpad 5.9-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Sat, 22 Apr 2006 15:48:10 +0200 Source: thinkpad Binary: thinkpad-source thinkpad-base Architecture: source i386 Version: 5.9-2.1 Distribution: unstable Urgency: low Maintainer: Debian tpctl maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: thinkpad-base - Configuration files for thinkpad-modules packages thinkpad-source - Source code for thinkpad-modules packages Closes: 364235 Changes: thinkpad (5.9-2.1) unstable; urgency=low . [ Thomas Hood ] * NMU. Martin Krafft will be the new (chief) maintainer. * /etc/udev/thinkpad.rules: Fix bug that caused many devices to be owned by group thinkpad (Closes: #364235) Files: e4496df959b0ed6fd84efd799a200fb0 684 utils extra thinkpad_5.9-2.1.dsc 72519a480542ae4b0b98f643dc7db4c7 13030 utils extra thinkpad_5.9-2.1.diff.gz b6274106054d82baf0b831b55b9a4b8d 28386 utils extra thinkpad-base_5.9-2.1_i386.deb 1c12fe82b9c351d9d86403fcb0bb4293 76286 utils extra thinkpad-source_5.9-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iEYEAREDAAYFAkRZDdgACgkQscRzFz57S3N67ACfVLgDD7IAuVrqXqxCBBqQ6fKq 0ZIAoLHw1TnK7GUA6EovorjAwE1PH/fz =Kv9V -END PGP SIGNATURE- Accepted: thinkpad-base_5.9-2.1_i386.deb to pool/main/t/thinkpad/thinkpad-base_5.9-2.1_i386.deb thinkpad-source_5.9-2.1_i386.deb to pool/main/t/thinkpad/thinkpad-source_5.9-2.1_i386.deb thinkpad_5.9-2.1.diff.gz to pool/main/t/thinkpad/thinkpad_5.9-2.1.diff.gz thinkpad_5.9-2.1.dsc to pool/main/t/thinkpad/thinkpad_5.9-2.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted resolvconf 1.35 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 Jan 2006 23:53:47 +0100 Source: resolvconf Binary: resolvconf Architecture: source all Version: 1.35 Distribution: unstable Urgency: low Maintainer: resolvconf maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: resolvconf - nameserver information handler Closes: 350383 Changes: resolvconf (1.35) unstable; urgency=low . [ Daniel Nylander / TH ] * Add sv.po . [ Yuri Kozlov / TH ] * Add ru.po; add ru translations of manpages (Closes: #350383) . [ Thomas Hood ] * DH_COMPAT=5 * Relicense with GPL version option * Remove /lib/init from initscript PATH since standard readlink program with -f option now works as required * Depend on coreutils = 5.93 to get revised readlink program Files: f0bd197a6e526e63dcd18d5e9e221ba9 652 net optional resolvconf_1.35.dsc 8a21b94baf76ae2902cc55321c7fa6a4 66179 net optional resolvconf_1.35.tar.gz ff32d421f7384e1918fcab60f1dcae13 59366 net optional resolvconf_1.35_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWVuh+DWPovKDPJMRAgLOAJ0SLpJa1lXYsbtyFS/wkzibvqjltgCcC23L UuudgDZ1BHgT1LoYWfCd6WQ= =aSPE -END PGP SIGNATURE- Accepted: resolvconf_1.35.dsc to pool/main/r/resolvconf/resolvconf_1.35.dsc resolvconf_1.35.tar.gz to pool/main/r/resolvconf/resolvconf_1.35.tar.gz resolvconf_1.35_all.deb to pool/main/r/resolvconf/resolvconf_1.35_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Interim maintainer needed for thinkpad and tpctl
I plan to cease maintaining the thinkpad and tpctl Debian packages very soon. Martin Krafft kindly agreed to take them over, but he will only be able to start work at the end of May. A new version of the thinkpad package needs to be uploaded soon in order to close a bug that is rated severity: critical. Therefore I am seeking an interim maintainer of thinkpad and tpctl, preferably someone who would like to carry on as co-maintainer with Martin. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
Petter wrote: I have not confirmed that this procedure will work, but here is my suggestions anyway. - The Alioth system administrators have asked for help several times. Get in touch with them and check what exactly they need help with. Do a good job helping them, and prove that way your abilities as a system administrator. Next, contact the new maintainer frontdesk and ask how the NM process fit your skill set and interest, and go through the process to become a official Debian Developer. Given that it takes up to two years to process an applicant answering standard questions from templates, how long is it likely to take to process someone through a custom process? Possibly less time if the applicant doesn't get hung up on difficult questions, but probably more; and the customization won't scale. And can we be sure that the applicant will be subjected to pointless busywork this way (to test his tolerance for Debian's institution of people carelessly wasting one another's time)? Another thing: According to my AM, the applicant's prior work can't be used to prove his competence because the Front Desk and the DAM can't be bothered to look at that work. How do we ensure that applicants on the custom track will be subjected to similar obtuseness? Perhaps there should be a checklist to ensure a level playing field. [] Find something that he doesn't know and tell him to go away if he doesn't know it [] Ignore the applicant's past work in Debian [] Make the applicant rephrase §6.4: Summary of ways maintainer scripts are called in his own words [] Make the applicant wait for months for no particular reason [] Blame the applicant for above delays Seriously though, Jerome, I'd advise you not to get your hopes up too high. Here's the experience of Debian's newest DD: Received application2004-04-21 [...] Application Manager recommends to DAM Approved on 2004-07-12 FD checks completeness of report Approved on 2006-02-21 by Marc Brockschmidt (he) DAM Approval Approved on 2006-03-20 by Joerg Jaspert (joerg) -- Thomas Hood
Re: Emphasize teams, not packages
Jérôme Warnier wrote: But [packaging] is not my main contribution to Debian, I propose patches and close bugs for many packages I personally use or need for customers, and this is not recognized currently as sufficient for becoming a DD... and I'm not the only one. and later wrote: So, how can I apply for DDship while doing the things I'm best at? Obviously you can't, currently. You aren't the first to see a potential problem with the current equation of DD'ship with Debian project membership. It's hard to predict whether this will ever change. If you think that it should change then nothing is stopping you from making the suggestion here. It's up to the members to decide whether they want to implement such change, though. (It's a bit of a catch-22, since existing members are less likely to see the exclusivity of Debian as a problem. However, you always have the option of participating in some other project, such as Ubuntu, which does recognize contributions other than package maintenance.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted thinkpad 5.9-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 12 Feb 2006 14:31:06 +0100 Source: thinkpad Binary: thinkpad-source thinkpad-base Architecture: source i386 Version: 5.9-2 Distribution: unstable Urgency: low Maintainer: Debian tpctl maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: thinkpad-base - Configuration files for thinkpad-modules packages thinkpad-source - Source code for thinkpad-modules packages Closes: 353190 Changes: thinkpad (5.9-2) unstable; urgency=low . [ Thomas Hood ] * Note that CONFIG_OBSOLETE_INTERMODULE must be set to 'y' for 2.6.16 (Closes: #353190) Files: 3ca623d5a218f9db89b306cf90caf058 713 utils extra thinkpad_5.9-2.dsc 2d925451bfc4b6ed7f6c8f9e1fb8c310 13017 utils extra thinkpad_5.9-2.diff.gz a55ad743ae36512ebebe6eb8638ddc61 28270 utils extra thinkpad-base_5.9-2_i386.deb 3774719710f16b7d4472d09c95f8ca80 75908 utils extra thinkpad-source_5.9-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJ+expFNRmenyx0cRAjebAKCEKh3byYCVpvoPfaKgzXK97OTeCgCg+9xk qxi4XUUPVaQAsJRc5c/Zl0s= =cMOr -END PGP SIGNATURE- Accepted: thinkpad-base_5.9-2_i386.deb to pool/main/t/thinkpad/thinkpad-base_5.9-2_i386.deb thinkpad-source_5.9-2_i386.deb to pool/main/t/thinkpad/thinkpad-source_5.9-2_i386.deb thinkpad_5.9-2.diff.gz to pool/main/t/thinkpad/thinkpad_5.9-2.diff.gz thinkpad_5.9-2.dsc to pool/main/t/thinkpad/thinkpad_5.9-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sysvinit 2.86.ds1-14 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Mar 2006 19:45:04 +0100 Source: sysvinit Binary: sysv-rc sysvinit initscripts Architecture: source i386 all Version: 2.86.ds1-14 Distribution: unstable Urgency: low Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: initscripts - Scripts for initializing and shutting down the system sysv-rc- System-V-like runlevel change mechanism sysvinit - System-V-like init utilities Closes: 356226 357245 357667 357667 Changes: sysvinit (2.86.ds1-14) unstable; urgency=low . [ Thomas Hood ] * umountfs: Unmount in order of decreasing mount point length without making use of the sort program (Closes: #356226) Thanks to Jiri Polach * Don't Build-Depend on selinux stuff on kfreebsd-amd64 (Closes: #357245) * Make initscripts Conflict with sysvinit ( 2.86.ds1-12) because bootlogd initscript uses an option that was introduced in 2.86.ds1-12 (Closes: #357667) * bootlogd: Mention -p and -c options in usage message (Closes: #357667 too) Files: af35b1109c6a83b8e603c30ab6c93488 1225 admin required sysvinit_2.86.ds1-14.dsc ba405c5dc38f8cf1a34bb41b1f7dec63 120980 admin required sysvinit_2.86.ds1-14.diff.gz ea7b0fa768c156cf8817548f7a9a5b91 121862 admin required sysvinit_2.86.ds1-14_i386.deb 0cc0284d8ed35b8f0601f6e1adcee529 48534 admin required initscripts_2.86.ds1-14_i386.deb b5b56522d1c0a80adfda1539b543dad6 47814 admin required sysv-rc_2.86.ds1-14_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQEVAwUBRCfslYjztdzjjnrPAQIIWwf9Gyrfp5keI26cHYU/XjUfNda+HHfbBBTQ dUxnA/0QQhCTZPlYPh/eLizqf+1lsL/3lDdasVH+2pwsq9e3xwbVUcGWPvkkvxhY UjI7qmjxGtMNikvQ4aCsP/wpFrtZu31dp6hZdQoE6EAULZryB/uZbsqzUPrPApcL unVxJl1TDaeTZJh35T93sboDggHigGkx/kMMJgobtg4YH4yuyOm4yG7dzTF6v+tb 8NGHhMyJi5k189HYM/mEg5+00eusBbuwP4c/Qu0Vl3a91srbAjBUebHTVQftffjL S8TFV7174nop9aoA9JYC78VS6EDGWZCMcVIOucWXshfU74/2wSTbDQ== =EA3T -END PGP SIGNATURE- Accepted: initscripts_2.86.ds1-14_i386.deb to pool/main/s/sysvinit/initscripts_2.86.ds1-14_i386.deb sysv-rc_2.86.ds1-14_all.deb to pool/main/s/sysvinit/sysv-rc_2.86.ds1-14_all.deb sysvinit_2.86.ds1-14.diff.gz to pool/main/s/sysvinit/sysvinit_2.86.ds1-14.diff.gz sysvinit_2.86.ds1-14.dsc to pool/main/s/sysvinit/sysvinit_2.86.ds1-14.dsc sysvinit_2.86.ds1-14_i386.deb to pool/main/s/sysvinit/sysvinit_2.86.ds1-14_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dicussion about patches ... ignoring patches make motivation to provide them fall
Me: [In the hypothetical case] I write to the maintainer of P but get no reply. After repeating this a few times I (finally!) get a message from the P maintainer... about his having more important things to do than deal with my patch. [...] Frans Pop: Alternative conclusion to this saga... I discuss on d-devel if the Foo project is a worthwhile goal and how I've gotten stuck. There is general agreement that Foo is worth pushing for the next release. I ask for a review of/help with my patches to the packages that block progress, deal with the comments that come back and NMU them (after mailing the maintainer one last time). [...] Right. Either way, the maintainer's failure to respond to my messages ends up costing me a lot of time. The prospect of this is likely to have a negative impact on my motivation to undertake project Foo in the first place. This was the contention expressed in the Subject line and is the only point I would want to support. Svenl originally claimed that ignoring patches is an act of contempt, but I would certainly not go that far. Yes, responding to a request would be regarded as elementary politeness in some spheres, but Debian's social norms are not the same as those of everyday life. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dicussion about patches ... ignoring patches make motivation to provide them fall
Russ Allbery wrote: Whenever this topic comes up on debian-devel, the conversation seems to focus on the small minority of maintainers who don't respond to bugs, are still active on their packages, resist any attempt at co-maintainership, and can't be dealt with through the MIA process. Yes, these are the most frustrating cases. Such people, to the extent that they exist, are frustrating; they're also such a small minority of the problem that if they were all we had to worry about, Debian would be in awesome shape. [...] If you run into a maintainer who doesn't want your help, move on and try another maintainer. It might not be so simple. Suppose I have taken it upon myself to push change Foo through Debian. The Foo project requires cooperation from several DDs and at the beginning I can't tell whether I will get that cooperation from all of them. After having devoted many hours to project Foo and after the passage of some months I find that progress is blocked by needed changes to package P. I write to the maintainer of P but get no reply. After repeating this a few times I (finally!) get a message from the P maintainer... about his having more important things to do than deal with my patch. Time goes by and the patch is never spoken of again. Of course I move on and do something else. But I have wasted a lot of time, Foo never gets done, and I have learned not to undertake any more projects like Foo in the future. Not within Debian, anyway. Purely hypothetical case, but it could happen. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sysvinit 2.86.ds1-13 (source i386 all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 13 Feb 2006 08:42:44 +0100
Source: sysvinit
Binary: sysv-rc sysvinit initscripts
Architecture: source i386 all
Version: 2.86.ds1-13
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Thomas Hood [EMAIL PROTECTED]
Description:
initscripts - Scripts for initializing and shutting down the system
sysv-rc- System-V-like runlevel change mechanism
sysvinit - System-V-like init utilities
Closes: 352398 352741 353083 353212 353585 355746 356226
Changes:
sysvinit (2.86.ds1-13) unstable; urgency=low
.
[ Thomas Hood ]
* umountfs: Unmount even if sort not available (Closes: #356226)
* last: Fix strncmp bug (Closes: #353585)
* umountroot: Tweak handling of error messages from mount
(Closes: #352398)
* /etc/init.d/skeleton: Source init-functions (Closes: #353212)
* initscripts.postrm: Don't remove /etc/init.d/mountdevsubfs
* mount{all,nfs}.sh: Don't set TMPTIME cuz it's not used here
* pidof.8: Don't imply that pidof is in /sbin (Closes: #352741)
* sysv-rc: /etc/init.d/README: Refer user to /usr/share/doc/sysv-rc/
(Closes: #353083)
* Add NEWS.Debian with entry for 2.86.ds1-10 which reports the
replacement of the bootclean.sh function library by the
bootclean initscript. (Closes: #355746)
.
[ Petter Reinholdtsen ]
* Silence init.d/hostname.sh when VERBOSE=no.
* /etc/init.d/skeleton: Show how to use the VERBOSE variable.
Files:
1bdac978d0aa0b415ed32336af55bf9d 1193 admin required sysvinit_2.86.ds1-13.dsc
469cfeb5978d1e4fe239148fcfb9f093 120339 admin required
sysvinit_2.86.ds1-13.diff.gz
6753a87cc5f45afbe2fbdb45b3e5e13d 121684 admin required
sysvinit_2.86.ds1-13_i386.deb
038edc6f1791a5188a708af5b70d0d1e 48158 admin required
initscripts_2.86.ds1-13_i386.deb
b51e91a531b9dca67a5d243665323374 47636 admin required
sysv-rc_2.86.ds1-13_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iQEVAwUBRBi/fojztdzjjnrPAQLd7wgAmo9mvTJlzj6w0xaRIACD6/sq+g+cHHdt
0ltxJxymD3AiYDwnt7haXJ7e1iXqH/bJr1kvOaqKIZR1QhgVf/TL68dNd3nNsaSU
jVuArv0XkDRzD15fbleOPg/x/XVghp1BCQ98PFgVd8vqalUifAAiA+DQgXVqOhLf
xZpDQSlug/QzdkMlwRKDCHE2/Aup1NuldNoIXh7tXhY6KrN65VxifVWVWpWccxzU
2CTpzO76kqH1svucKA4/A6PEnIiIJ6rIZ8GQol0kYG3SS0Ha6F7eL478H6wWCWPa
9hz+b0ApeOrrooT1HUPn2djHRkhY1pmG/tpUScdVmyCY37rpwacRKg==
=HLuX
-END PGP SIGNATURE-
Accepted:
initscripts_2.86.ds1-13_i386.deb
to pool/main/s/sysvinit/initscripts_2.86.ds1-13_i386.deb
sysv-rc_2.86.ds1-13_all.deb
to pool/main/s/sysvinit/sysv-rc_2.86.ds1-13_all.deb
sysvinit_2.86.ds1-13.diff.gz
to pool/main/s/sysvinit/sysvinit_2.86.ds1-13.diff.gz
sysvinit_2.86.ds1-13.dsc
to pool/main/s/sysvinit/sysvinit_2.86.ds1-13.dsc
sysvinit_2.86.ds1-13_i386.deb
to pool/main/s/sysvinit/sysvinit_2.86.ds1-13_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conffile purging and maintainer scripts
Roger Leigh wrote: Until last month, dpkg forgot about conffiles which were removed or moved on package upgrade. As a consequence, maintainers had to remember to purge these conffiles by hand in the package postrm script. I just want to highlight the word these above in order to reduce the possibility of confusion. Postrms should not delete files that are currently conffiles of the package. dpkg takes care of deleting such files at the right time. If a file /etc/foo was formerly a conffile of the package but no longer is so then /etc/foo should be dealt with in the preinst or postinst. (Dealing with it has to take into account both the old and the new behavior of dpkg with respect to disappearing conffiles. I speak vaguely here because I haven't looked into the new behavior.) If it isn't dealt with there then it might be appropriate to delete it in the postrm, but not if there is reason to suspect that some other package is now using /etc/foo. 1) sarge - etch upgrades - In order to handle upgrades from sarge correctly, maintainers will still have to manually remove conffiles in their maintainer scripts until at least etch+1 by my reckoning. Is this correct? Again, postrms should not remove files that are currently conffiles. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted thinkpad 5.9-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Dec 2005 10:00:00 +0200 Source: thinkpad Binary: thinkpad-source thinkpad-base Architecture: source i386 Version: 5.9-1 Distribution: unstable Urgency: low Maintainer: Debian tpctl maintainers [EMAIL PROTECTED] Changed-By: Thomas Hood [EMAIL PROTECTED] Description: thinkpad-base - Configuration files for thinkpad-modules packages thinkpad-source - Source code for thinkpad-modules packages Closes: 298652 315293 317496 342256 342458 342865 Changes: thinkpad (5.9-1) unstable; urgency=low . [ Thomas Hood ] * New upstream (Closes: #342865) + Remove thinkpadpm (Closes: #315293, #342256, #298652) + Remove non-ASCII chars from SUPPORTED-MODELS (Closes: #317496) * Eliminate thinkpad-base.preinst. We now support upgrades from the sarge version (5.8-4) or later. * -source README.Debian: Mention possibility of using linux-headers * -source README.Debian: Mention module-assistant (Closes: #342458) * -base README.Debian: Add info re: ACPI and APM * Bump Standards-Version to 3.6.2.1; no changes required * Update FSF address * Now maintained by the members of the pkg-tpctl project at alioth Files: 85a0b967c209d7f945dc03ae9b4afe99 702 utils extra thinkpad_5.9-1.dsc 9cd4e86277bb7baeca97e93f57f49e87 74779 utils extra thinkpad_5.9.orig.tar.gz fc6096db6ad18a2173fcf0844457040f 12969 utils extra thinkpad_5.9-1.diff.gz 7cfcac9d37bcbd1984f8902b17b2c0dc 28178 utils extra thinkpad-base_5.9-1_i386.deb 506f7152d14db62bc3835ee2a3b0a5a6 75338 utils extra thinkpad-source_5.9-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD7w4IpFNRmenyx0cRAphnAJ0Q+OhXEku6NCdiosgLav0IaqICtACeI0sX 7CvxOKzghDbszqit4rSl2ho= =+Saf -END PGP SIGNATURE- Accepted: thinkpad-base_5.9-1_i386.deb to pool/main/t/thinkpad/thinkpad-base_5.9-1_i386.deb thinkpad-source_5.9-1_i386.deb to pool/main/t/thinkpad/thinkpad-source_5.9-1_i386.deb thinkpad_5.9-1.diff.gz to pool/main/t/thinkpad/thinkpad_5.9-1.diff.gz thinkpad_5.9-1.dsc to pool/main/t/thinkpad/thinkpad_5.9-1.dsc thinkpad_5.9.orig.tar.gz to pool/main/t/thinkpad/thinkpad_5.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
Peter Samuelson wrote: That's a bug, IMO - they should mkdir -p in their init scripts if necessary. It's not like that's hard to do. Tim Cutts wrote: [...] In my case I was mounting /var/run and /var/lock as tmpfs filesystems all the time to reduce hard disk access on a machine that was running all the time. Ubuntu is already mounting tmpfs's on /var/lock and /var/run. It's a reasonable thing to do and we should support it. That means that packages using these directories should create any subdirectories they need. Don't forget to set ownership and permissions. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPL version option
Now that a draft of GPL version 3 has been published it seems appropriate to examine what the implications would be for current licensees of GPL'd software. For many licensees it will have implications because the software is licensed under the GPL with a version option. The text of the GPL itself includes this section: 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. Actual source files contain text like this (with version option): This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. but some of them contain text like this (without version option): This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 dated June, 1991. I had never paid much attention to this before and to my surprise I found several source files that _I_ had written which lacked the version option. When I examined other source files I found a bit of a mess. Several debian/copyright files contained without option texts whereas the source files themselves contains with option texts. These had to be corrected. My guess is that there may be other packages out there that need to be reviewed with respect to the granting or non-granting of the GPL version option. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Frank_Küster wrote: That sounds good, but wouldn't it be even better to have a symlink /usr/bin/debpython-minimal or so, pointing to the interpreter? Then one could still replace the interpreter by something else (by putting it into /usr/local/bin), for example in order to debug a particularly weird problem in a config script? Or python-minimal could just provide /usr/bin/python-minimal. Then programs with minimal requirements would have #!/usr/bin/python-minimal and their packages would Depend on python-minimal, whereas normal python programs would have #!/usr/bin/python and would Depend on python. Behind the scenes /usr/bin/python would be a symlink to python-minimal but users wouldn't have to know this. The interpreter could even be modified so that it allows only modules from the minimal set to be imported, when run as /usr/bin/python-minimal. Thus if upstream's concern is that users not have a stripped down python, then Debian provides a stripped down python-minimal instead. -- Thomas Hood
Re: when and why did python(-minimal) become essential?
Matt Zimmerman wrote: The compromise we struck with upstream was that we would not give the user a system with a broken Python. So upstream objects to the separate packaging of python-minimal unless all of python is installed when python-minimal is installed (which in Ubuntu's case is: always) unless the user takes special action to prevent this. Hmm. Given that Debian does not have python in base and that some Debian packagers would like to make use of python-minimal, and Debian presumably does not want to make python-minimal Essential: yes, I'd suggest that a different way be sought for satisfying upstream. I'll assume that python2.4-minimal Recommending: python2.4 won't be enough. How about this? The current python2.4-minimal package contains /usr/bin/python2.4. We would move this to /usr/lib/python2.4/interpreter so that it is no longer present on the standard search path. The full python2.4 package would contain a symlink /usr/bin/python2.4 - /usr/lib/python2.4/interpreter to make the interpreter available on the path. python-minimal Depends on python2.4-minimal and contains the symlink /usr/bin/python - /usr/bin/python2.4. In addition it would contain the symlink /usr/lib/python/interpreter - /usr/lib/python2.4/interpreter. Packages that currently Depend on python but use only minimal functionality could Depend on python-minimal but they would have to run python using /usr/lib/python/interpreter. The stripped down python interpreter would be hidden from command-line users but would still be available for use by packaged programs. Thomas Bushnell wrote: Ok, but now I'm confused: why is python-minimal needed in Essential? Why not simply depend on it straightforwardly? http://marc.theaimsgroup.com/?l=debian-develm=113768382100129w=2 -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
I wrote: Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I doubt it. [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29 there's a claim that they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. Looking at that page today I see that it has changed. It seems to be more accurate now, though I didn't keep a copy of the old text with which I could compare what is written now: Ubuntu and Debian are distinct but parallel and closely linked systems. The Ubuntu project seeks to complement the Debian project in the following areas: [...] When a bug is reported in the Debian bug tracking system and then later fixed in Ubuntu, the fixes are communicated back directly to the Debian developers responsible for that package in Debian and record the patch URL in the debian bug system. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Steve Langasek wrote: Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, and obtaining this benefit does not require that python-minimal be Essential: yes in Debian. In any case I am hoping to see python-minimal included in Debian. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
beside the fact that I find useful to name eth0 the realtek and eth1 the other, there is a casuality in the naming process that I cannot remove If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? What I mean by 'races' are sequences like these: * Kernel creates eth0 * Userspace notices eth0, looks at its properties, and... * Kernel creates eth1 * ...tries to rename it to 'eth1', but that name is taken -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
In any case I am hoping to see python-minimal included in Debian. I now see that it is already in sid. :) $ apt-cache madison python-minimal python-minimal |2.3.5-5 | http://ftp.nl.debian.org sid/main Packages -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Md wrote: SuSE uses some scripts to handle persistent interface names [...] I had no time yet to investigate the details. I just looked at the rename_netiface script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name Now trying several times, etc., may work, but it's a kludge. There are sound ways of resolving contention for a shared resource. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Theodore Ts'o wrote: I looked at the patches for e2fsprogs, and I have to conclude that unfortunately, they patches are worse than useless. It's not clear exactly what is being diffed against what, but if I had to guess it's a diff of Debian stable or Debian testing versus the latest in Ubuntu unstable --- or whatever is their development branch. I have encountered that problem too---sometimes the patches are diffs against the wrong version. And on _top_ of that, we have all sorts of gratuitous autotools changes. I can't comment on your package. I have seen changes in some packages that looked gratuitious, but then I have been comforted by the thought that the perpetrators of gratuitous changes are the ones who have to pay the price for it, because they have to carry such changes forward. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
sysvinit 2.86.ds1-10 is now in incoming. Along with udev 0.080-1 this should fix the problem (/dev/pts not mounted early enough) that kept some people from using bootlogd. Beyond that, it is the latest of a string of experimental releases. The sysvinit team is hoping that it is not too far off base in regarding this to be a candidate for release to unstable. Again, TIA for testing it. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Steve Langasek wrote: FWIW, here's what I see in practice. We have Ubuntu saying that they give back to Debian; and then we have a fairly large divergence between what Debian has in unstable and what's going into the next Ubuntu release, with IME very little patch submission to the Debian BTS, plus particular individuals who are working diligently to make sure their own Ubuntu changes get integrated effectively into Debian. I don't think that patches-submitted-to-the-BTS is a good way to measure how much Ubuntu is contributing to Debian. Ubuntu's patches are readily available: http://people.ubuntulinux.org/~scott/patches/ If they were submitted to the BTS then that would just create more work for the Debian maintainer as well as for the Ubuntu maintainer, since the former would have to tag the report and ensure it gets closed on the next upload, etc. Yes, it might be more helpful than the current breakdown of patches into changelog and packaging components if there was a further breakdown into parts suitable for Debian and parts not suitable for Debian. However, to perform this breakdown would be for Ubuntu developers to make judgments about what is suitable for Debian, and I am sure that such judgments would provoke negative reactions from Debian developers. So I think that it is up to Debian maintainers to review the Ubuntu patches from time to time and to backport what appears to be suitable for Debian. I agree that it would be nice if Ubuntu developers tried to get their changes into sid. It is certainly not their responsibility to do so, but in my experience Ubuntu developers have been very cooperative when they have been approached. So I don't see a big problem. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
John Hasler wrote: I can't see how putting up patches on a Web site is better than (or even as good as) filing bug reports. The web site requires less labor to maintain than hundreds of bug reports. Again, why should Ubuntu's patches be handled any differently than those of other users? In short: because Ubuntu isn't just another user, but a whole distribution. cobaco wrote: So how is it the Debian maintainers responsibility to go hunting for usefull patches? I did not say that it is a DD's responsibility to go hunting for patches. As is well known, Debian developers don't have responsibilities (Constitution article 2.1). However, if a particular Debian Developer feels motivated to improve his package then he'd be well advised to examine what Ubuntu has done to it. Transfer of information requires two parties: a provider and a recipient. Ubuntu, the provider, has published its changes. The transfer can only be completed when the receiver is ready to receive, but this is not always the condition of Debian maintainers. So it is efficient if the transfer take place on the initiative of the latter. Once he or she is ready, he or she doesn't have to hunt, because the patches are all at a known location. http://people.ubuntulinux.org/~scott/patches/ Ah, here we come to the heart of the problem: when they have been approached, this clearly points to the fact that the initiative for synchronization between ubuntu and debian lies with Debian not Ubuntu (by and large, some exceptions have been mentioned). Right. In the mean while Ubuntu proudly calls ubuntu gives things back, whereas in reality we mostly have a situation of ubuntu will help debian maintainers that want to take things back I don't see a profound difference between helping to take and giving. Perhaps what you want is giving on a silver platter? - It's this misrepresentation of where (most of) the initiative lies which pisses people off. I think that people are pissed off for other reasons. (But I admit that I can only speculate. I can't read people's hearts and minds.) Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I doubt it. [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29 there's a claim that they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: Bug#344758: init.d script should create /var/run/dirmngr
The submitter of #344758 wrote: The script should create /var/run/dirmngr to allow users to map their /var/run to a temporary filesystem like tmpfs. Thanks. Peter Eisentraut wrote: What do you think about this request? It seems reasonable, but I think if this should be supported, there ought to be a general policy (formal or informal) on it because I think many other init scripts will suffer from similar problems. A program that needs to put files into a subdirectory of /var/run/ should create the required subdirectory itself at run time. This can be done by an initscript or by the program itself if it runs as root. Remember ownership and permissions. [ ! -d /var/run/foo ] mkdir --mode=755 /var/run/foo chown foouser:foogroup /var/run/foo Do this no sooner than /etc/rcS.d/S47 and no later than when the dir is needed. :) As pointed out by Peter Samuelson, this dir should be removed by the postrm on purge. I would advise not including /var/run/foo in the package since it is superfluous and its presence could hide a bug in your directory-creation code. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
Would it be useful if the initscript that clears /var/run also created a directory hierarchy under /var/run? (There are different ways of implementing thus, but we can talk about details if this feature is deemed worthwhile.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Andreas Schuldei wrote: we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. Manoj Srivastava wrote: What on earth for? Andreas Schuldei wrote: [...] people who want to help/contribute seem to be turned away by the burecratic nature of the NM process with its long waiting periods. People who want to contribute without that process need to find a way to do that easily and effectively, without spending too much time to find where they can do that. [...] Manoj, i think you are trying to polarize the discussion. I think that the discussion is already polarized; there is obviously a sharp difference of view. The disagreement is reflected in the inconsistency between the existence of easy entry points, which you favor. and the whole philosophy behind the NM process, which was presumably favored by those who set up that process. You seem to be assuming that Debian should encourage people to contribute, whereas the NM process was deliberately set up to discourage applicants. You assume that applicants are scarce, but the assumption behind NM is that there are more than enough. You assume that newcomers can be given the benefit of the doubt, whereas the assumption behind NM is that newcomers should not be trusted until they have endured trials. You assume that contributors are different, but the assumption behind NM is that developers all need to learn the same skills. You assume that people can learn as they go, but NM insists that applicants learn everything up front. If there are easy entry points in Debian which allow non-DDs to do the same work as DDs then I can see why a defender of the current NM process would regard those points as weaknesses in Debian's defenses, which should be closed rather than advertized. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Anthony Towns: Anyway, the real point of replying was for me to have some fun playing (what I'll hereby dub) the false dichotomy game. That's where you take a set of contradictory statements, and setup reasonable scenarios where, in fact, both alternatives are true simultaneously. I'd call it the obscure the point game, because the pairs of statements were meant to illustrate a difference in attitude, not a set of absolute contradictions. But I think you know that. Because you are really playing another game, which I'll dub the innuendo game. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Joseph Michael Smidt wrote: I believe the greatest barrier the Debian Project has in preventing widespread contributions from greater numbers of volunteers is a psychological barrier. I have personally introduced Debian to several of my friends and always emphasize the idea that they too can contribute to the great cause whether by documentation, translation or adopting a package, etc... Universally they are excited, desire to try it out, then come back having read what it takes to be a Debian Developer and are overwhelmed. They then begin searching out other open source projects where it seems psychologically they will be able to be more of an assistance. They are right: most probably they will find it easier to make contributions to other projects. What is missing from your message is the argument why this should be changed. Would it in fact be a good thing if your friends devoted their time to Debian rather than to those other projects? It is not obvious to me that that would be better. The great cause is the free software movement as a whole. Within that movement there should be room for different kinds of projects, including exclusive hobby clubs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Andreas Schuldei wrote: we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. we should leave that option for the ones that want to contribute above average. If there is any truth to what Joseph Michael Smidt originally said: 1.)All people psychologically want to feel important and that they are an official part of an organization. I feel there should be an official title for all contributers so they feel like they are part of the community, not just a pion until they get official developer status. then it might help to reword several pages at debian.org so that they are more inclusive. Rename Developers' Corner to Contributors' Corner. Under The People write This is a comprehensive listing of all the Debian _maintainers_ accompanied with a list of packages they maintain, instead of ...developers... (which would also be more accurate since non-DD maintainers are already listed). And so on. Reword with the principle in mind that there are many contributors to Debian who are not Debian Developers®. -- Thomas Hood
Package dependencies due to documentation relationships?
In #303948 it is requested that coreutils Suggest: glibc-doc on the grounds that documentation in the former links to documentation in the latter. I have seen other requests of this kind and I have never been sure how these situations are supposed to be handled. Are there policies or recommendations about how documentation relationships should be reflected in package dependencies? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
A new version of sysvinit is being prepared for release to experimental. OK, sysvinit 2.86.ds1-8 is now in incoming. TIA for testing it. ;) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
Henrique de Moraes Holschuh wrote: How well that works with /var in a separate partition? It should work fine because S55bootmisc.sh runs after S45mountnfs.sh. -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
And that is probably not what I would expect. What about doing something like this... NOLOGIN=boot nologin exists during boot NOLOGIN=alwaysnologin always exists NOLOGIN=never nologin never exists That would be fine if we were adding a new feature, but I am trying to modify an existing feature (to make it compatible with a read-only root filesystem) without altering its behavior any more than necessary. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Since I contributed to taking the thread off on a particular tangent I feel I should try to bring it back to its original topic, which is an important one. I would like to hear some discussion about whether or not the quality of Debian is high enough; and if it is not high enough, what can be done to improve it? Lars's headings were: A) Prevent bugs from happening in the first place B) Find and report bugs C) Fix bugs that have been reported D) Prevent bugs from entering the archive Automated testing of program functionality Let's take quality assurance seriously Under most of these topics Lars discussed automated testing. Are there objections to Lars's concrete proposals (e.g., standardization on a way to invoke package specific tests)? Are there other ideas? Should Debian do more auditing, for example? For C, Lars discussed different degrees of shift from solitary toward collective maintainership. In the sequel opinions were emphatically expressed that such a shift is not necessarily a good thing. The question remains whether better quality can be realized by changing the organization in some way. Perhaps not. Then what other things can be done to help individual maintainers fix more bugs and fix them better? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
