Uploaded yafc 0.7.4-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Aug 2001 12:15:31 -0400 Source: yafc Binary: yafc Architecture: m68k Version: 0.7.4-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Decklin Foster [EMAIL PROTECTED] Description: yafc - Yet Another FTP Client Closes: 107155 Changes: yafc (0.7.4-1) unstable; urgency=low . * New upstream release, fixes DOS directory listing (Closes: #107155) Files: 5d97dc0ddfe21ca2b3216891ab39f31c 118130 net optional yafc_0.7.4-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTtMACgkQEycGpQPNsdJZ4QCfSHORlDhtLBo3q2IHT+wpo6DA mYcAmwUiardhtBWsp3rIhToLnYkAhU7O =dsSD -END PGP SIGNATURE-
Uploaded xdu 3.0-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 25 Aug 2001 10:47:05 +0200 Source: xdu Binary: xdu Architecture: m68k Version: 3.0-7 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Fredrik Hallenberg [EMAIL PROTECTED] Description: xdu- display the output of du in an X window Closes: 108879 Changes: xdu (3.0-7) unstable; urgency=low . * Added libxaw7-dev to build depends (closes: #108879) Files: 2c24f3fc6b0e5c73633e5b1c93b48353 14450 utils optional xdu_3.0-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTCUACgkQEycGpQPNsdJOkACgkEFT6ApOo8bDgWQJfAl4/ytL KbAAn3bqNhhlZCXIRlzPAqOdv2chtByR =Lh0U -END PGP SIGNATURE-
Uploaded xtartan 2.3-6 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Aug 2001 12:40:03 +0200 Source: xtartan Binary: xtartan Architecture: m68k Version: 2.3-6 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Anselm Lingnau [EMAIL PROTECTED] Description: xtartan- Display Scottish tartans Closes: 110467 Changes: xtartan (2.3-6) unstable; urgency=low . * Fixed path name for Debian menu entry (thanks to [EMAIL PROTECTED]). (closes: #110467) * Changed rules file for debhelper 3. Files: ad4bc4c457ce420e5387c52df0b12475 51392 x11 optional xtartan_2.3-6_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTp4ACgkQEycGpQPNsdIAywCgr7gibH7gBOYPf0qGW5J4QArX MvAAnicVuG9KZ7FB/ExvbE/po7nkXkgF =bGt+ -END PGP SIGNATURE-
Uploaded ftpgrab 0.1.2r-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Aug 2001 21:04:15 -0400 Source: ftpgrab Binary: ftpgrab Architecture: m68k Version: 0.1.2r-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Christian T. Steigies [EMAIL PROTECTED] Description: ftpgrab- file mirroring utility Closes: 104937 109414 Changes: ftpgrab (0.1.2r-3) unstable; urgency=low . * force building with with g++-2.95, this probably makes ftpgrab unbuildable on hppa and ia64, upstream is working on making it compatible with g++-3.0 (closes: #104937) * remove (unneeded) dh_suidregister from debian/rules * rebuild (closes: #109414) * update Standards-Version Files: 9ed816de7cde6e869ecc9bc9d6730201 48346 net optional ftpgrab_0.1.2r-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTJkACgkQEycGpQPNsdKs3gCeKbJl7H7lHZDy34OY2c/0ZE56 fv4AoJTnGJf75z2H7UwerTRdAfdFEjgC =U+MM -END PGP SIGNATURE-
Uploaded aterm 0.4.0-8 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Aug 2001 17:26:31 +0200 Source: aterm Binary: aterm aterm-ml Architecture: m68k Version: 0.4.0-8 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: aterm - Afterstep XVT - a VT102 emulator for the X window system aterm-ml - Afterstep XVT - a VT102 emulator for the X window system Closes: 105660 Changes: aterm (0.4.0-8) unstable; urgency=low . * src/command: applied patch from Eric Benoit [EMAIL PROTECTED], which adds the CSI 21 t control sequence, for title handling. * debian/rules: configure aterm with --enable-background-image to enable -pixmap, which should be on by default, but... (closes: #105660). You can now chose a pixmap to set as an aterm background. Files: 2ea3b6886ce6fcf5e09518c6d77acaa4 94742 x11 optional aterm_0.4.0-8_m68k.deb 41db078fa914b3e06292ed6c34c33863 230524 x11 optional aterm-ml_0.4.0-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTDEACgkQEycGpQPNsdIpUwCcC32KFAm4WxlPr3tGv1oXGlT4 plwAn1qqhWpGcU+W8t0ofyE/Ujw/iQM5 =emoV -END PGP SIGNATURE-
Uploaded ledit 1.10-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 30 Aug 2001 11:14:35 +0200 Source: ledit Binary: ledit Architecture: m68k Version: 1.10-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Sven LUTHER [EMAIL PROTECTED] Description: ledit - A line editor for interactive programs. Changes: ledit (1.10-3) unstable; urgency=low . * Fixed long line in short description Files: 820e332c9675b5c250b7bc796909563c 81190 editors optional ledit_1.10-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTHwACgkQEycGpQPNsdJJkgCdHjFrebM/eeackgju5js01S/w Xa0An2jYJQAR82dBeyW+4BrhAOIF7v3d =dJge -END PGP SIGNATURE-
Uploaded gkdial 1.5.12-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Aug 2001 22:02:07 -0300 Source: gkdial Binary: gkdial gkdial-gnome Architecture: m68k Version: 1.5.12-1 Distribution: unstable Urgency: high Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED] Description: gkdial - Gtk-based PPP dial-up configuration tool. gkdial-gnome - GNOME-based PPP dial-up configuration tool. Changes: gkdial (1.5.12-1) unstable; urgency=high . * New upstream release - fixes a nasty bug wich was making /etc/ppp/*-secrets worl-readable. Files: e02d016de3ef1061b903654d80347304 54166 admin extra gkdial-gnome_1.5.12-1_m68k.deb 43ab0da4c3efd4b0aa40e0eca054d54b 47846 admin optional gkdial_1.5.12-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTpUACgkQEycGpQPNsdITwACfTKKoET5A7slQW/tVXoZIfQnH togAn113brexhf4Ee2NjVoweB9X+4avz =MvzQ -END PGP SIGNATURE-
Uploaded filerunner 2.5.1-12 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 26 Aug 2001 15:44:34 +0100 Source: filerunner Binary: filerunner Architecture: m68k Version: 2.5.1-12 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Muhammad Hussain Yusuf [EMAIL PROTECTED] Description: filerunner - X-Based FTP program file manager Changes: filerunner (2.5.1-12) unstable; urgency=low . * Changed ..debian/menu to correct path. Files: f5a8d8bb49cc28dca556890dbd1d420d 113014 net optional filerunner_2.5.1-12_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTJAACgkQEycGpQPNsdLcwQCgkxNLC2JRZcMOF0YPYtEsXC+P YwgAoJDBGtfSNc2eFQVr7vwldTbn2/BN =MnqQ -END PGP SIGNATURE-
Uploaded zile 1.6.1-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Aug 2001 17:58:40 +0200 Source: zile Binary: zile Architecture: m68k Version: 1.6.1-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Carsten Leonhardt [EMAIL PROTECTED] Description: zile - a very small emacs-like editor Changes: zile (1.6.1-1) unstable; urgency=low . * new upstream release * complies with standards version 3.5.6.0 Files: 617f5e398999c9a52d095bbb44eaa340 94054 editors optional zile_1.6.1-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTIYACgkQEycGpQPNsdLmwgCfU/hfGOEtxIS8d5uNbqSh0Rle EW8AoKlrhfzmP9JSPLS04VKHF6tX8pZp =Yl3g -END PGP SIGNATURE-
Uploaded deskmenu 1.3.0-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 27 Aug 2001 09:50:16 -0400 Source: deskmenu Binary: deskmenu Architecture: m68k Version: 1.3.0-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Brandon L. Griffith [EMAIL PROTECTED] Description: deskmenu - A root menu for X11 window managers Changes: deskmenu (1.3.0-4) unstable; urgency=low . * Added a manpage. The program did not come with one so I whipped something up from the info in the README * Changed a section in the copyright that caused lintian to complain. Files: d71a65bb2382b6b8d4b571f764eb20b1 11140 x11 optional deskmenu_1.3.0-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTDsACgkQEycGpQPNsdJZJQCff6diqWBPnzcbF6AuRqg3t7Ki nagAn1Fh+ZvvKe18onxQspXHHkx+Og/f =bkMq -END PGP SIGNATURE-
Uploaded hx 0.7.14-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Aug 2001 23:19:29 +0200 Source: hx Binary: hx Architecture: m68k Version: 0.7.14-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Adrian Bunk [EMAIL PROTECTED] Description: hx - The Unix client for Hotline Changes: hx (0.7.14-4) unstable; urgency=low . * Maintainer set to Debian QA Group [EMAIL PROTECTED]. Files: 2ffad912feb9d635c7c4e4ee4ec0226d 37212 net optional hx_0.7.14-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTrEACgkQEycGpQPNsdLtZwCfSu1tLgQRMa46IK62Q3wrnCLR a5AAoKe58cRZgOwHqSll3CPbq4HB8nee =YRLl -END PGP SIGNATURE-
Uploaded xwrits 2.16-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 26 Aug 2001 08:08:39 -0400 Source: xwrits Binary: xwrits Architecture: m68k Version: 2.16-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Hugo Haas [EMAIL PROTECTED] Description: xwrits - Reminds you to take a break from typing Changes: xwrits (2.16-1) unstable; urgency=low . * New upstream version. Files: 9195b6c31e6a9455cf80467d54ec051f 76562 x11 optional xwrits_2.16-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTqgACgkQEycGpQPNsdIYyACePogA1OWTa0UK3p08jgwDRORg 5xYAoIZaGAbHebImK0nmPen+3DE0o5yH =kR0M -END PGP SIGNATURE-
Uploaded oroborus 1.14.0-5 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 27 Aug 2001 11:31:41 -0400 Source: oroborus Binary: oroborus Architecture: m68k Version: 1.14.0-5 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Brandon L. Griffith [EMAIL PROTECTED] Description: oroborus - A lightweight themeable windowmanager for X. Changes: oroborus (1.14.0-5) unstable; urgency=low . * Arto Jantunen [EMAIL PROTECTED] grabbed me on irc and pointed out that oroborus 1.14.0-4 would not start. After looking into his error message I saw that the makefile was not producing the correct arguments for creating the oroborusrc. There was no bug filed aainst this since he was the only one to report it and it was fixed immediately. I now am supplying a working copy of the oroborusrc file for /usr/share/oroborus and am going to contact the upstream author about making an /etc/oroborusrc file. Files: 50e966e8d37368a1ba7c2774be13c325 63900 x11 optional oroborus_1.14.0-5_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTFQACgkQEycGpQPNsdLtuwCcC2PrAr5oJTDKEKUimXgQnhn2 /mAAnR9M3yclSzcQhu3sCph2W7Ngh1jj =QD1E -END PGP SIGNATURE-
Uploaded pam 0.72-31 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 31 Aug 2001 13:16:39 -0400 Source: pam Binary: libpam-runtime libpam-modules libpam-cracklib libpam0g-dev libpam-doc libpam0g Architecture: m68k Version: 0.72-31 Distribution: unstable Urgency: low Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Sam Hartman [EMAIL PROTECTED] Description: libpam-cracklib - PAM module to enable cracklib support. libpam-modules - Pluggable Authentication Modules for PAM libpam-runtime - Runtime support for the PAM library libpam0g - Pluggable Authentication Modules library libpam0g-dev - Development files for PAM Closes: 108697 Changes: pam (0.72-31) unstable; urgency=low . * Add support for credential reinitialization in pam_group, closes: #108697 Files: b73ecf7a459249982f83927aa92ad7cb 62746 base required libpam0g_0.72-31_m68k.deb a918efce6617e9a34a7449fa331f3f19 138284 base required libpam-modules_0.72-31_m68k.deb fcb90da5181431aa81f60f6e28919bd5 42776 base required libpam-runtime_0.72-31_m68k.deb 3121e47928d10f4f4a8ccc409dacb0a0 149138 devel optional libpam0g-dev_0.72-31_m68k.deb 55fceef9734dc37d756b911a071439ce 43160 libs optional libpam-cracklib_0.72-31_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTKUACgkQEycGpQPNsdJCCQCgjud6qzW2XzZMtecbTE9DXxHn QCsAoIMphfyFxSHDe2SdlhF38bETOm0A =/FKZ -END PGP SIGNATURE-
Uploaded whois 4.5.8 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 26 Aug 2001 16:46:23 +0200 Source: whois Binary: whois Architecture: m68k Version: 4.5.8 Distribution: unstable Urgency: medium Maintainer: Debian/m68k buildd4 [EMAIL PROTECTED] Changed-By: Marco d'Itri [EMAIL PROTECTED] Description: whois - The GNU whois client Closes: 103480 109919 Changes: whois (4.5.8) unstable; urgency=medium . * Use a bigger internal buffer to parse server output (Closes: #109919). * Added german translation (Closes: #103480). * Added support for domains like eu.org and uk.com. * Fixed non-ASCII locales. * Added another DDN AS block, .info and .biz servers. * Updated .au netblocks data, .ng, .ua and .za TLD servers. * When mkpasswd output is redirected to a file only the hashed password is printed. * Made some cosmetic changes for solaris. Files: 21396f2b75f50572057675c40d0e05e2 27380 net standard whois_4.5.8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iEYEARECAAYFAjuSTmUACgkQEycGpQPNsdJ5xACdH5NRHvzOiBKgWddJXxmfcWrd s7UAnA81qUTCfRZ2ab1gA7s/1a4lrkDk =nltN -END PGP SIGNATURE-
Re: RFC: Signed packages and translations
- What would source packages look like for such a system? It /is/ possible to continue to use the old .orig.tar.gz + diff.gz, but automatic updates for new translations would invalidate the maintainer's signature. Should we seize the opportunity to switch to a more flexible source package format? Or just switch to .orig.tar.gz + diff.gz + .i18n.tar.gz? The new source format is the old source format. The translated parts are in the normal diff.gz. They cannot be, since the maintainer is not involved in uploading them. I think the i18n.tar.gz approach is the way to go. What about this: The *.i18n.tar.gz file contains files named package.control-ll_CC and package.templates-ll_CC which look like this (for the control file): Package: Description: original English description Description-ll_CC: translated description dpkg-source knows about these files, omits them from the diff and generates a separate .i18n.tar.gz when building source packages. However, only the descriptions which match the description from the master control file are added -- the others will just cause a warning. When building the package, the translated descriptions will be generated from these files in the resulting .deb. When katie sees a .i18n.tar.gz file, it will pass this file on to the ddtp's database, where it will be used to update the database. After that, the file is regenerated from the database and installed together with the rest of the package. When the ddtp database is updated, a new .i18n.tar.gz file is generated and installed, and the .deb is updated accordingly. This way, translators as well as maintainers can update the database -- translators by sending mail to the ddtp mailbot, maintainers by uploading .i18n.tar.gz files. To avoid problems with incorrect translations, maintainers are asked not to upload .i18n.tar.gz files unless necessary (perhaps that you need to pass a special option to dpkg-genchanges). Whenever the database is updated, the .debs and the .i18n.tar.gz are updated on the ftp server, but the .diff.gz is untouched. I think the .i18n.tar.gz file should not be mentioned in the .dsc file, since it will change over time, invalidating the signature. Hrm, it seems that file will need a .sig file signed by katie to accompany it when you download the full source. It's early morning and I'm tired. I almost bet I overlooked something. Simon
Re: RFC: Signed packages and translations
The translation archive can contain a control and a templates file. These files have much the same format as the corresponding files from the control.tar.gz file but with the exception that they contain only the identifiers (Package: xyz for control and Template: foo/bar for templates) and the translated Description-ll_CC: field. These files are merged by dpkg-deb when extracting the package. (btw: in the template file we have more translateable tags) Okay, will be fixed in the next version. I like this all, but we have the problem with outdated translations. Yes, that's why I want these files to be automatically added from the database: The database still contains the untranslated strings, so we can check whether the translations are up to date. If the checking were performed on the end user's machine, you would ship the unstranslated strings n+1 times, with n being the number of translations, and if the translation was no longer up to date, the end user's box would throw them away. With my proposal, a .deb file would never contain an outdated translation unless the maintainer forced it. A to written script (dh_i10ndesc) include the translation only in the deb, if the orignal description from the po file comform with the description in the controll file. With this we don't have outdate descriptions in the deb. This still has the problem that the maintainer has to take some action to get the translation into the .deb, which we wanted to avoid. But we might need to take an approach like that, see my next mail. The user can install a desc-trans-XX.deb and have with this deb a local override file. I don't see the point in this. Why would the user want to override translated descriptions? katie has all informations. it has the descriptions from the packages, the translations from the packages and maybe one/some override files with traslations. It can make Packages-XX files. But I don't like this. IMHO better is this: katie make the normal Packages file and some Descriptions-XX files. With only Package: and Description-XX: tags. Apt can download the Packages file like normal and/or on/some Descriptions file(s). This makes sense once people want to have the descriptions of uninstalled packages in multiple (read: more than one language on one box) languages, since it helps avoid some confusion with packages of the same name and version being available from multiple sources. The user can config what languages he will support. Apt can use this Descriptions files itself or (IMHO) better make a po file with the Packages and Description file and make with this a mo file. And use the normal dgettext. With this we don't use the desc-trans-XX.deb in real. What is the point in using gettext then? If you generate the .po file from two different sources (original and translation without the original text), the translation cannot be out of date. Simon
Re: RFC: Signed packages and translations
Step 1: Signed archives --- Quick note from vacation: signed packages are already designed and implemented. No need to reinvent the wheel. Do they allow unsigned/separately signed parts? Simon
Re: RFC: Signed packages and translations
You should all realise that GNU ar supports long filenames, so there is no need to obfuscate filenames from ar's point of view. GNU ar, yes. dpkg, no. Simon
Re: RFC: Signed packages and translations
I don't think translations should be in the source package at all, I'm opposed to this! Yes, not including the translations in the source package makes things much easier, but I think they still should be there at all costs. Yes, I can agree with that. I think we have to put them in a separate file though, so we don't break any signatures. See also my proposal extension a few mails ago. Simon
Re: RFC: Signed packages and translations
which uploads? There are no extra uploads. There have to be, in my eyes. Consider this scenario: katie can pretend there has been an upload. OK, but re-diffing will invalidate the maintainer's signature on the diff! Hm, I guess this doesn't matter as long as that sig's sole purpose is to authorize the upload. :-/ Putting the translations into the diff is not a good idea IMO, since I never download my own packages, so I never get updated translations. Simon
Re: RFC: Signed packages and translations
Also problematic is the idea of packaging all the translations into one package. This would never be up-to-date, and more frequent updates are not nice. I prefer a solution similar to the current system in ddts. This could be included in the current FTP archive, in the subdirectories for each language as proposed by Grisu before. If I've understood Grisu's proposal correctly, he suggests that each package with an active maintainer ship translated descriptions inside the package, and there is an override package which contains the translations for which there have been no uploads so far. Nothing is ever changed on the FTP server. Simon
Re: new port: and the winner is....
On Sat, Sep 01, 2001 at 01:09:03PM +0200, Richard Atterer wrote: Mingw requires that the program actually be able to build on a win32 system, but produces code that runs much faster, is far more stable in my experience, and competes head to head with the same app compiled for MSVC versions 4 and 6. Yes, but using mingw for the port is out of the question IMHO. If you tried that, you'd end up re-implementing Cygwin... That's not a problem if what resulted was not as buggy and otherwise broken as cygwin tends to be. -- Joseph Carter [EMAIL PROTECTED] Free software developer Feb 5 13:27:01 trinity lp0 on fire -- the Linux kernel, alerting me that there was some unknown problem with my printer (ie, it was out of ink) pgp3S5p5WZUT3.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sat, Sep 01, 2001 at 10:36:59PM +0200, Richard Atterer wrote: On Sat, Sep 01, 2001 at 01:32:26PM +0200, Michael Bramer wrote: - How do we avoid that a package is updated too often? Updating the .deb for each translation change is far too often - maybe add any new translations the moment the package moves from unstable to testing? Obviously, people using unstable will then not benefit from the translations. which uploads? There are no extra uploads. There have to be, in my eyes. Consider this scenario: - Maintainer uploads package with changed English translation - Maintainer goes AWOL - Translators catch up with translations Now what happens? The translations are there, waiting to be incorporated into any new upload of the package, but there is none. Isn't this exactly the problem that we have right now with templates, and that we're trying to solve with this whole system? if only katie put new parts in the deb. yes, we habe a problem. But maybe we can run add_translation_to_old_packages.pl weekly and this do the job. - What would source packages look like for such a system? It /is/ possible to continue to use the old .orig.tar.gz + diff.gz, but automatic updates for new translations would invalidate the maintainer's signature. Should we seize the opportunity to switch to a more flexible source package format? Or just switch to .orig.tar.gz + diff.gz + .i18n.tar.gz? The new source format is the old source format. The translated parts are in the normal diff.gz. OK, but re-diffing will invalidate the maintainer's signature on the diff! Hm, I guess this doesn't matter as long as that sig's sole purpose is to authorize the upload. :-/ no, only the translation in the package source (from the mailtainer are in the source.) Extra translations from katie or the weekly script are not in the source. You don't need real source, the translation is the source. There is no binary, I don't see a problem with this point. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Windows ist der One-Night-Stand unter den Betriebssystemen. Man fühlt sich so billig, wenn man es benutzt hat. -- Illiad in uf pgpxAdcCPMPA0.pgp Description: PGP signature
Re: funny idle time from time
On Sat, 1 Sep 2001 12:18, Wouter Verhelst wrote: I agree with most of what you say, but not with this. You can say a lot about NFS, including that it's bad, insecure, to be thrown away and changed by CODA or sth else, but not that it's slow. I've seen data transfers of ~800KByte/s via NFS. Over my 10MBit coax network. From a Pentium 166 to a Pentium 133. I don't know any other network file serving protocol that can do this. What other network protocols have you tried? I have attached the results from running Bonnie++ with my Thinkpad (P3-650, 256M) as an NFS client with both 10 baseT PC-Card and 100baseT CardBus network cards connected to an Athlon 800 with 256M, PCI 100baseT card and with a full duplex switch in between. The only time that NFS is really efficient is bulk input. I mounted the NFS share with rsize92,wsize92,nolock. Both machines run 2.4.9 and the NFS serving is in the kernel. I tried using smbfs but it dropped out under load (seems to be a bug in the client code). I tried making the Thinkpad the NFS server, but it wasn't fast enough and the client thought that it had fallen off the net and started the laborious back-off process (which kills performance). The end result, NFS isn't nearly as fast as it should be, but SMB is worse because I couldn't get it to work. Let's redirect this discussion to debian-user... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page Title: Bonnie++ Benchmark results Version 1.92aSequential OutputSequential InputRandomSeeksSequential CreateRandom CreateSizeChunk SizePer CharBlockRewritePer CharBlockNum FilesMax SizeCreateReadDeleteCreateReadDeleteK/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU lyta-100-nfs999367121496M54699488532407271298102753177.011617929434016192411161185124151454 lyta-100-nfsLatency716086us2683ms457ms39709us871msLatency462ms164ms12271us132ms98528us728us lyta-10-nfs999378658496M4039988434244471941209087.8416590141127165801158815123219155 lyta-10-nfsLatency330693us1227ms848ms52184us674msLatency774ms88644us25376us114ms115ms7331us 1.92a,1.92a,lyta-100-nfs,999367121,496M,,546,99,4885,3,2407,2,712,98,10275,3,177.0,1,16,1792,9,4340,16,1924,11,1611,8,5124,15,1454,7,16086us,2683ms,457ms,39709us,871ms,462ms,164ms,12271us,132ms,98528us,728us,142ms 1.92a,1.92a,lyta-10-nfs,999378658,496M,,403,99,884,3,424,4,471,94,1209,0,87.8,4,16,590,14,1127,16,580,11,588,15,1232,19,155,3,30693us,1227ms,848ms,52184us,674ms,774ms,88644us,25376us,114ms,115ms,7331us,139ms
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 07:03:07AM +0200, Simon Richter wrote: Also problematic is the idea of packaging all the translations into one package. This would never be up-to-date, and more frequent updates are not nice. I prefer a solution similar to the current system in ddts. This could be included in the current FTP archive, in the subdirectories for each language as proposed by Grisu before. If I've understood Grisu's proposal correctly, he suggests that each package with an active maintainer ship translated descriptions inside the package, and there is an override package which contains the translations for which there have been no uploads so far. Nothing is ever changed on the FTP server. yes, this is my proposal. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linux -- das System fuer Kaltduscher und aechte Maenner aus d.c.o.u.l.n pgpQUL0UYmmyk.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
On Sat, Sep 01, 2001 at 11:19:42PM +0200, Richard Atterer wrote: On Sat, Sep 01, 2001 at 03:38:58PM +0200, Raphael Hertzog wrote: Le Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer écrivait: With language-specific Packages files, there is no size issue. And that's a mirror where we I only have i386. So multiply by 10 arch, then by 50 languages, and you get 10Gb of Packages file. We could reduce that if we remove uncompressed Packages but still ... And a good part of those packages files changes daily ... so the mirror need to download many data each day. That's not acceptable. Oh, but you're not comparing this to the requirements for centralized translation packages: If you do, there is no difference, *if* you assume that the translation packages would also have to be released per arch. no, you don't need one package per arch. _Now_ We make only a file from the i386 arch. (IMHO you get 90% of the other archs with this file) But a po file with all descriptions in archs from sid, will not the big problem and is not very bigger. Furthermore, as mentioned before, translation packages have the disadvantage that new Descriptions, i.e. _the_ones_you_are_most_likely _to_look_at_, will *not* be translated because you haven't yet downloaded the latest translation package. no. If you download the desc-trans-XX.de you have all translations from XX on your system. Not only the translations from the installed packages. see my comments from a other proposal. Maybe we should make Descriptions-XX files (like the Packages files), get this with apt and make the po files with this files. This Descriptions files can maybe stored in one place per dist. Independent of the solution, we need some - translated Packages file - Description-XX file (with translated descriptions) - a desc-trans-XX.deb (with a po/mo file with translated descriptions) if the user should see translated descriptions before he installed a package. And all of this you must download and install before you can see the translations. The first and second download a patched apt, the last one you must install per hand. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Before you play two notes learn how to play one note - and don't play one note unless you've got a reason to play it. - Mark Hollis pgp7pJDidvMOW.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 07:03:01AM +0200, Simon Richter wrote: I like this all, but we have the problem with outdated translations. Yes, that's why I want these files to be automatically added from the database: The database still contains the untranslated strings, so we can check whether the translations are up to date. If the checking were performed on the end user's machine, you would ship the unstranslated strings n+1 times, with n being the number of translations, and if the translation was no longer up to date, the end user's box would throw them away. With my proposal, a .deb file would never contain an outdated translation unless the maintainer forced it. please can you point out this process more clearly in a new version of the proposal. A to written script (dh_i10ndesc) include the translation only in the deb, if the orignal description from the po file comform with the description in the controll file. With this we don't have outdate descriptions in the deb. This still has the problem that the maintainer has to take some action to get the translation into the .deb, which we wanted to avoid. But we might need to take an approach like that, see my next mail. no, I don't see a extra work. maybe the maintainer don't add translations: He must do nothing. The dh_i10ndesc script is in rules and make all work. maybe the maintainer add a french translation (a french maintainer): He write only a po file like description and the dh_i10ndesc script is in rules and make all work. If he change the english text and forgot the translation he get a error and the script don't add the translation in the deb. The user can install a desc-trans-XX.deb and have with this deb a local override file. I don't see the point in this. Why would the user want to override translated descriptions? Normal the user (or better root) don't have a this override file. But maybe he is a translator and translate some descriptions and he will add this translation to his po files and use this and he must not wait on the delay with the ddts and the ftp admin from this override file. This local override don't cost something. If we use the local gettext and some po files and generate with this a mo file, we have this feature and some roots will maybe use it... katie has all informations. it has the descriptions from the packages, the translations from the packages and maybe one/some override files with traslations. It can make Packages-XX files. But I don't like this. IMHO better is this: katie make the normal Packages file and some Descriptions-XX files. With only Package: and Description-XX: tags. Apt can download the Packages file like normal and/or on/some Descriptions file(s). This makes sense once people want to have the descriptions of uninstalled packages in multiple (read: more than one language on one box) languages, since it helps avoid some confusion with packages of the same name and version being available from multiple sources. this is IMHO a must feature. If you can only install one languages, the system is very bad. The user can config what languages he will support. Apt can use this Descriptions files itself or (IMHO) better make a po file with the Packages and Description file and make with this a mo file. And use the normal dgettext. With this we don't use the desc-trans-XX.deb in real. What is the point in using gettext then? If you generate the .po file from two different sources (original and translation without the original text), the translation cannot be out of date. gettext do all the work, you get never old translations, you must patch apt with 30 lines (note: we don't count apt now), we use old tested code, use all the time the same translations, ... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linux -- das System fuer Kaltduscher und aechte Maenner aus d.c.o.u.l.n pgpExiMu7mnwS.pgp Description: PGP signature
libgnomeprint error
I compile my own X so there are no debianisms in the X tree. Other than that it's debian unstable. Updated to the latest pkgs tonight and i recieved this error. Are there seperate font packages for gnome needed? I do have all of the xfonts installed. Info: ghostscript was found and has fonts in these directories: Info: /usr/local/lib/ghostscript/common Info: /usr/local/lib/ghostscript/5.50 Info: /usr/local/lib/ghostscript/fonts Info: /usr/local/share/ghostscript/common Info: /usr/local/share/ghostscript/5.50 Info: /usr/local/share/ghostscript/fonts Info: /var/lib/defoma/gs.d/dirs/fonts Info: /usr/share/ghostscript/common Info: /usr/share/ghostscript/5.50 Info: /usr/share/ghostscript/fonts Info: /usr/lib/ghostscript/common Info: /usr/lib/ghostscript/5.50 Info: /usr/lib/ghostscript/fonts Info: adding default directory /usr/local/lib/ghostscript/fonts to font path. Info: running /usr/bin/gnome-font-install --debug --afm-path=/usr/share/fonts/afms --pfb-path=/usr/share/fonts/pfbs --target=/usr/share/fonts/fontmap2 --assignment=ghostscript,/usr/local/lib/ghostscript/common --assignment=ghostscript,/usr/local/lib/ghostscript/5.50 --assignment=ghostscript,/usr/local/lib/ghostscript/fonts --assignment=ghostscript,/usr/local/share/ghostscript/common --assignment=ghostscript,/usr/local/share/ghostscript/5.50 --assignment=ghostscript,/usr/local/share/ghostscript/fonts --assignment=ghostscript,/var/lib/defoma/gs.d/dirs/fonts --assignment=ghostscript,/usr/share/ghostscript/common --assignment=ghostscript,/usr/share/ghostscript/5.50 --assignment=ghostscript,/usr/share/ghostscript/fonts --assignment=ghostscript,/usr/lib/ghostscript/common --assignment=ghostscript,/usr/lib/ghostscript/5.50 --assignment=ghostscript,/usr/lib/ghostscript/fonts --assignment=ghostscript,/usr/local/lib/ghostscript/fonts --fontmap-path=/usr/share/fonts. /usr/share/fonts/pfbs is not a directory Assigned ghostscript : /usr/local/lib/ghostscript/common Assigned ghostscript : /usr/local/lib/ghostscript/fonts Assigned ghostscript : /var/lib/defoma/gs.d/dirs/fonts Assigned ghostscript : /usr/share/ghostscript/5.50 Assigned ghostscript : /usr/local/lib/ghostscript/fonts Reading fontmap... Done Verifying fontmap entries Done Scanning source maps... Trying srcfile /usr/share/fonts/adobe-urw.font Trying srcfile /usr/share/fonts/urw-urw.font Trying srcfile /usr/share/fonts/debian.font Trying srcfile /usr/share/fonts/groff.font Trying srcfile /usr/share/fonts/tex.font Trying srcfile /usr/share/fonts/X.font Done Scanning directories: Done Sorting fonts... Done Sorting Type1 aliases... Done Building fonts... Done Something went wrong - NO FONTS
Re: libgal sonames
On Sat, Sep 01, 2001 at 11:25:32AM -0500, Colin Watson wrote: On Sat, Sep 01, 2001 at 05:23:03PM +0200, Rodrigo Moya wrote: The only problem I can see is with the -dev packages, which may need some work to allow different versions to be installed. That's OK. We often only support one version of -dev packages, so that people don't build against soon-to-be-obsolete versions by accident. It becomes problem if the versions are not source compatible, however. Then packages become unbuildable every time we release a new libgal version (and update the single libgal-dev). It may be better to have packages that link with libgal (other than evolution and gnumeric) link statically instead of dynamically. This would be a workaround until libgal stabilizes. Presumably it will stabilize at some point -- either that, or someone will take the most useful parts of libgal and give them a stable interface in another library. There's obviously enough need for what libgal provides, otherwise there wouldn't be so many packages using it now. -- Richard Braakman Will write free software for money. See http://www.xs4all.nl/~dark/resume.html
Re: Translating Debian packages' descriptions
On Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer wrote: Hi Raphael, On Fri, Aug 31, 2001 at 01:59:32PM +0200, Raphael Hertzog wrote: [snip] using my fr environnment I could'n reconfigure debconf to use the Gnome frontend, it wasn't listed in the proposed choices because the french translation was outdated and didn't include the new Gnome frontend. The contrary can happen, a choice has been removed but my french translation does still propose it :( I should have submitted a bug about this so that we can find a solution for debconf ... Hm, IMHO the package maintainer should be intelligent enough to notice that he has made an incompatible change to the templates, and as a result delete/comment out all the translations. Or did you use translations from a different source than the package itself? Ouch ! As translator, I can promise you that if Joey Hess had removed all my translation just because he added 'gnome' to the list of choices, he would had to search out another french translator ! The debconf i18n stuff is suposed to discard outdated translations, but it failed in this case. Call this a bug. So, you can fix that bug, and reinvent the wheel, or use the gettext mecanism to handle outdated translations. But we where at package descriptions, not debconf templates. (one problem after the other ;) Bye, Mt. PS: this perticular problem is fixed, since I updated the french translation. But the problem still exists for these languages: de, fi, gl, it, ja, ko, nl, pl, pt_br, ru, sv, zh_cn and zh_tw. To whom should I send my translation bug reports ? ;)
Re: Translating Debian packages' descriptions
On Sat, Sep 01, 2001 at 10:11:45AM +0200, Radovan Garabik wrote: Just a small nitpicks... On Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer wrote: Hi Raphael, On Fri, Aug 31, 2001 at 01:59:32PM +0200, Raphael Hertzog wrote: With language-specific Packages files, there is no size issue. About the only disadvantage I can think of is that the fallback language would have to be English, and not configurable - but surely that's acceptable. There is no encoding issue either, since AFAIK for well, it surely is less then optimal. Most Slovaks would want fallback to Czech version, and I imagine vice versa is also true. (and Ukrainians and Belorussians may want fallback to Russian - and now you have an encoding issue as well) Of 8 friends of mine that are using debian, I know that: 2 would want fallback hungarian-slovak-czech 1 would want fallback lithuanian-slovak-czech-russian 1 would want fallback slovak-hungarian-czech the rest would want fallback slovak-czech I prefer original English version nice statistics :-) Sure, that would be great. But, AFAIK, no i18n mecanism can handle that for now. Feel free to fill a wishlist bug report against gettext. It may also be that I misunderstood your mail, and that this feature exists somewhere. If it's the case, please be patient with me, and give me some pointers. Thanks, Mt.
Re: Translating Debian packages' descriptions
On Sun, Sep 02, 2001 at 09:12:52AM +0200, Martin Quinson wrote: On Sat, Sep 01, 2001 at 10:11:45AM +0200, Radovan Garabik wrote: Of 8 friends of mine that are using debian, I know that: 2 would want fallback hungarian-slovak-czech 1 would want fallback lithuanian-slovak-czech-russian 1 would want fallback slovak-hungarian-czech the rest would want fallback slovak-czech I prefer original English version nice statistics :-) Sure, that would be great. But, AFAIK, no i18n mecanism can handle that for now. Feel free to fill a wishlist bug report against gettext. It's not well documented (neither gettext (3) or setlocale (n) seems to mention it), but: ~ $ date -h date: invalid option -- h Try `date --help' for more information. ~ $ LANGUAGE=xo:eo_EO:de_DE:en date -h date: Ungültige Option -- »h« Mit `date --help' bekommen Sie mehr Informationen. ~ $ -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: step by step HOWTO switch debian installation into utf-8
On Sat, Sep 01, 2001 at 02:42:31PM -0500, David Starner wrote: en_AU UTF-8 tells it to make en_AU a UTF-8 locale. If you want en_AU.ISO-8859-1 as well, then add en_AU UTF-8 en_AU.ISO-8859-1 ISO-8859-1 this is probably the best idea or (what I would recommmend) en_AU.UTF-8 UTF-8 en_AU ISO-8859-1 to locale.gen. That's easier than hand-running localedef and keeps it up to date with any locale bugfixes. but in this case glibc will normalize the name and put locale into /usr/lib/locale/en_AU.utf8, which, if I understand it correctly, works but is not The Right Thing(tm) -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: libgal sonames
On Sat, Sep 01, 2001 at 05:30:52PM +0200, Rodrigo Moya wrote: On Sat, 2001-09-01 at 16:35, Mark Brown wrote: Well, yes but that goal could be accomplished by statically linking the library. Though if upstream think it makes sense to have it shared you're kind of stuck with a lot of the problems. but, that's what sonames and library versioning are for, are they not? Yes, but the ABI is so unstable that this would entail keeping around fairly large numbers of old libraries. I mean, the problem is on libgal9 being removed when installing libgal10. If both can coexist, there's no problem at all, right? It'll work but it's not nice and seems to miss some of the point of having the library be shared. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgp13OdDjPM56.pgp Description: PGP signature
CUPS
I just thought about trying cups on my home system but either I haven't found the correct way to configure it yet or it simply does not configure itself well enough IMO. I'm used to lpr(ng) with magicfilter. All I have to do is answer some question and I have a system up and running that prints everything I need. Now I installed some cups packages and have no printer. I wanted to install DeskJet_670C-cdj670.ppd or DeskJet_670C-pcl3.ppd from cupsomatic-ppd but just got a lpadmin: add-printer failed: The requested resource was not found on this server. Anyway, there does not seem to be much documentation and the web interface on port 631 gives some error messages resp. tells me that the resource is not available. Trying to print a test page I get postscript code listed. It seems to me that I missed something but what? I have installed all dependencies so that should not be the problem. Is there any howto available? Is there a reason why the package does not configure itself to the point where a user can use his printer? Finally, are there better printer systems available? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: RFC: Signed packages and translations
Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael A process on the ftp-master patch the deb with the Michael translation, if the translation is not alread in the the Michael package. This process don't change the package or the Michael version number- It only add the translation parts in the ar Michael file. So the same file name, at dieerent times, shall have different MD5Sums, and indeed, the same file on different debian archives shall have different lengths and different checksums. (Did you know that an X upload was rejected because it changed a file without changing the version number?) I don't think that signing all parts of the ar separately solves this issue at all. manoj -- Life is like a 10 speed bicycle. Most of us have gears we never use. Schultz Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: RFC: Signed packages and translations
On 01-09-01 Martijn van Oosterhout wrote: Can you store multiple signitures in the same file? Yes, that possible by using the OpenPGP format. You'll either need to use one-pass-signature packets, like GnuPG does by default, or the cleartext signed format. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAhcfhcu5Nb.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On 01-09-01 Simon Richter wrote: On Sat, 1 Sep 2001, Christian Kurz wrote: not be ascii armored since this would only introduce transmission overhead and gain nothing. The file name for this file is constructed from the Why does it gain nothing? What about problems during transmission? The ascii armor output which is protected by a crc checksum would help notice such a transmission problem. dpkg already has a mechanism for finding packages that have been corrupted by transferring them in ASCII mode. I mean, the .tar.gz is already binary, Since which day does dpkg download packages in ascci-mode from a url? Are you sure that you are not mixing up dpkg and apt-get? dpkg has as far as I know no mechanismen to detected corrupted packages and therefor having an ascii-armored signatures, with a crc checksum to detect transmission errors will be helpful. so why should the file following it be ASCII? Because there are situations where you don't use a tool that checks if the transmission was fine. You should not only find a solution for the specific case, that a tool downloads the packages from a server and already checks if the transmission was fine, but also for situations where such a tool is not provided. If the original filename is no more than sizeof(ar_name)-2 bytes long, .s is appended to it. If it is longer, the part of the file name before the .s? Another new extension? If you want to achive confusion for our users and developers, that's a possible way to go. If you really don't want to use ascii armor, then the extension should be .sig or if you use ascii-armor then .asc. The problem here is the filename length limit. I would have gone for .sig otherwise. Besides, you will only see those if you look at .deb files directly. And that will never happen? I'm tempted to say that there are cases where you have to look into the .deb directly or extract it via ar/tar. And the people will be confused in those cases, if they notice a file called .s, because that's an unusual extension. - Modify the autobuilders and existing developer scripts (debsign) so that they call dpkg-deb to sign the packages additionally to signing the .changes file. Sign packages build by an auto-builder? Of course. katie needs to verify that they were indeed created by an official autobuilder. How do you want to handle the issue with the passphrase in a secure way? How do you want to ensure that the key is safely placed on the autobuilder and how do you want to ensure that only trusted people have access to the autobuilder and especially this key? Placing a key on an auto-builder with script that contains the passphrase to sign all packages, is hazardous. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp0eljz1vprX.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 04:53:16AM -0500, Manoj Srivastava wrote: Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael A process on the ftp-master patch the deb with the Michael translation, if the translation is not alread in the the Michael package. This process don't change the package or the Michael version number- It only add the translation parts in the ar Michael file. So the same file name, at dieerent times, shall have different MD5Sums, and indeed, the same file on different debian archives shall have different lengths and different checksums. (Did you know that an X upload was rejected because it changed a file without changing the version number?) I don't think that signing all parts of the ar separately solves this issue at all. sorry, I don't make this proposal. This was only my understanding. If we can make this, if we have problem with the debian archives, if we can solved this problems, I don't know this all. I don't make comments on the points - 'put the translations in a extra ar element' and - make signatures on all ar elements I don't know the archives maintainment and the dpkg framework in this depth. I can't make real good comments on this. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman pgpWAzpod9mzT.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
On Sun, Sep 02, 2001 at 02:28:45AM -0500, David Starner wrote: On Sun, Sep 02, 2001 at 09:12:52AM +0200, Martin Quinson wrote: On Sat, Sep 01, 2001 at 10:11:45AM +0200, Radovan Garabik wrote: Of 8 friends of mine that are using debian, I know that: 2 would want fallback hungarian-slovak-czech 1 would want fallback lithuanian-slovak-czech-russian 1 would want fallback slovak-hungarian-czech the rest would want fallback slovak-czech I prefer original English version nice statistics :-) Sure, that would be great. But, AFAIK, no i18n mecanism can handle that for now. Feel free to fill a wishlist bug report against gettext. It's not well documented (neither gettext (3) or setlocale (n) seems to mention it), but: ~ $ date -h date: invalid option -- h Try `date --help' for more information. ~ $ LANGUAGE=xo:eo_EO:de_DE:en date -h date: Ungültige Option -- »h« Mit `date --help' bekommen Sie mehr Informationen. ~ $ yesterday I ask google and groups.google and find some pointers but no real documentation. I don't test this real, use this a fallback per - mo file, or - message? If it is per mo file, it is not usefull for our problem. But we can patch gettext. IMHO a per message based fallback is for normal gettext application also a nice thing. (with this someone can make a de_AT:de_DE:de:fr) If gettext support this per message (or if we patch it otherwise): Please, please dpkg and apt maintainers/developers use gettext for the translation! With gettext we have all, what we need and this all with some nice, small patches. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman pgp1KrUW3UDq7.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
Le Sat, Sep 01, 2001 at 11:19:42PM +0200, Richard Atterer écrivait: And that's a mirror where we I only have i386. So multiply by 10 arch, then by 50 languages, and you get 10Gb of Packages file. We could reduce that if we remove uncompressed Packages but still ... And a good part of those packages files changes daily ... so the mirror need to download many data each day. That's not acceptable. Oh, but you're not comparing this to the requirements for centralized translation packages: If you do, there is no difference, *if* you assume that the translation packages would also have to be released per arch. First : . a .deb package is compressed whereas Packages file from the mirror are not . i explicitely stated that the translation would be Architecture: all packages So there's a *big* difference if you take the time to calculate the numbers. Furthermore, as mentioned before, translation packages have the disadvantage that new Descriptions, i.e. _the_ones_you_are_most_likely _to_look_at_, will *not* be translated because you haven't yet downloaded the latest translation package. I already said that in my very first email ! I acknowledge this as a limitation. But since the goal is to be able to display translated description for our users (who are using stable, no ?) ... it's not a big deal if the geeks who are running unstable don't see the translation while it doesn't exist yet (or while they haven't updated their packages description file) ! You might argue that it's not necessary to make the translation packages arch-dependent. I think that's debatable, as some arches are way out of sync. gettext would help a bit, at the cost of depriving Beeing out of sync or not is not a problem since Description fields changes *very* rarely. All arches would benefit from the same number of translations ... And I find that having translations is far better that having not a single one and refusing to add them because we can't have the perfect solution right now. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Translating Debian packages' descriptions
On Sun, Sep 02, 2001 at 08:31:40AM +0200, Michael Bramer wrote: On Sat, Sep 01, 2001 at 11:19:42PM +0200, Richard Atterer wrote: Furthermore, as mentioned before, translation packages have the disadvantage that new Descriptions, i.e. _the_ones_you_are_most_likely _to_look_at_, will *not* be translated because you haven't yet downloaded the latest translation package. no. If you download the desc-trans-XX.de you have all translations from XX on your system. Not only the translations from the installed packages. I'm aware of this - what I was getting at is something like - a new package gets added to the archive - translators update the desc-trans package with a translation - J. Random Hacker does an apt-get update and then looks through the list of new packages for anything worth installing In this case J. will *always* see English descriptions for the new packages, since he hasn't upgraded the desc package yet. see my comments from a other proposal. Maybe we should make Descriptions-XX files (like the Packages files), Yes, I think this might be the best thing to do. (In fact, there's hardly a difference to the per-language Packages that I have been proposing before.) get this with apt and make the po files with this files. This Descriptions files can maybe stored in one place per dist. Independent of the solution, we need some - translated Packages file What for? I thought with this new proposal all translated descriptions end up in the Description-XX, and Packages contains the English descriptions? - Description-XX file (with translated descriptions) - a desc-trans-XX.deb (with a po/mo file with translated descriptions) if the user should see translated descriptions before he installed a package. AIUI, the desc-trans-XX.deb contains overrides for outdated descriptions in the source packages. But why put them in a separate package when you can put them directly into the Description-XX file? Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgpiwdtgzOQJc.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
On Sun, Sep 02, 2001 at 12:43:09PM +0200, Richard Atterer wrote: On Sun, Sep 02, 2001 at 08:31:40AM +0200, Michael Bramer wrote: On Sat, Sep 01, 2001 at 11:19:42PM +0200, Richard Atterer wrote: Furthermore, as mentioned before, translation packages have the disadvantage that new Descriptions, i.e. _the_ones_you_are_most_likely _to_look_at_, will *not* be translated because you haven't yet downloaded the latest translation package. no. If you download the desc-trans-XX.de you have all translations from XX on your system. Not only the translations from the installed packages. I'm aware of this - what I was getting at is something like - a new package gets added to the archive - translators update the desc-trans package with a translation - J. Random Hacker does an apt-get update and then looks through the list of new packages for anything worth installing In this case J. will *always* see English descriptions for the new packages, since he hasn't upgraded the desc package yet. yes you are right and this is a old point. But see my comment in a other mail. The desc-trans-XX.deb is/was only the first step. In future apt-get update must download some translations with the Package file. (btw: apt must download extra files all a time, if you use ddts or not, if you save the translation in the package or not, this is the special with the description. See other mail) I make some first thoughts about this in this mail. And now I thought about a newer, better proposal with this apt process. Independent of the solution, we need some - translated Packages file What for? I thought with this new proposal all translated descriptions end up in the Description-XX, and Packages contains the English descriptions? Yes I proposed this, see a below. - Description-XX file (with translated descriptions) - a desc-trans-XX.deb (with a po/mo file with translated descriptions) if the user should see translated descriptions before he installed a package. AIUI, the desc-trans-XX.deb contains overrides for outdated descriptions in the source packages. But why put them in a separate package when you can put them directly into the Description-XX file? sorry, I don't say this clearly. I miss a big _or_ in the list. In the other mail, I am thinking about: - translated Packages files like the hacked Packages files on gluck. See the guide and the faq on auric.d.o/~grisu/ddts/. I don't like this, this is a real hack. Apt don't know about the translation. It don't support real multi languages. It is a hack. or - extra Description-XX files, with only the translated descriptions. This is a better way. have some pro and cons. or - extra po like file (this was not in the old mail) or - normal desc-trans-XX.deb Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ja, aber der Bootvorgang ist doch so sch?n mit den Wolken und so. Das st?rt meiner Meinung nach garnicht. (Martin Heinz zum Rebooten von M$-W) pgpQ1PXNMJsr1.pgp Description: PGP signature
Re: SWI Prolog and GNU Prolog packages
SS == Sebastian Schaffert [EMAIL PROTECTED] writes: SS I would be willing to take over the maintanance of these two SS packages Please try to coordinate with Silvester Claassen [s.m.claassen at stalemate.nl], who expressed an interest to take over the packages (but haven't uploaded them for long time, so I don't know whether he's still interested in them), and Salvador Pinto Abreu [spa at di.uevora.pt], who is an upstream GNU Prolog developer and wanted to take over gprolog too (he stepped down in favor of Silvester originally). Regards, Milan Zamazal -- Here is my advice, don't try to program the bleeding edge for the general populace unless you really, really, really like migraines. Neal H. Walfield
ddts: notification about fr-translation of the libroxen-{roxpoll-doc|linkif|presentit}
I'm all for international descriptions. In roxen and roxen2 packages for debconf, I have a number of languages. But philippe, if you're to translate, then you have more job to do. You have 55 packages to translate! (just joking, don't take it the way it reads philippe, I _AM_ gratefull! :) Can I get more language translating, I'll upload asap. -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^/ /(_)_ __ _ ___ __ selective about who its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_| |Turbo Fredriksson [EMAIL PROTECTED] \\\/ \/_|_| |_|\__,_/_/\_\ Stockholm/Sweden Ft. Bragg BATF colonel president Serbian Rule Psix subway Cocaine tritium AK-47 congress domestic disruption jihad Soviet ammunition [See http://www.aclu.org/echelonwatch/index.html for more about this]
Bug#110959: ITA: doc-linux -- Linux HOWTOs, mini-HOWTOs, and FAQs
Package: wnpp Severity: normal Martin Michlmayr orphaned Marco Budde's packages today, as they don't appear to have been actively maintained for quite some time. I intend to adopt doc-linux (binary packages doc-linux-html and doc-linux-text), which is pretty seriously in need of an update before woody is released. I'm cc'ing this to -devel as doc-linux-text is Priority: standard. -- Colin Watson [EMAIL PROTECTED]
Re: CUPS
On 01-09-02 Michael Meskes wrote: I wanted to install DeskJet_670C-cdj670.ppd or DeskJet_670C-pcl3.ppd from cupsomatic-ppd but just got a lpadmin: add-printer failed: The requested resource was not found on this server. Would you mind telling us which version of cups you have installed? You didn't include that information. Anyway, there does not seem to be much documentation and the web interface on port 631 gives some error messages resp. tells me that the resource is not available. Under the following URL http://localhost:631/documentation.html is a lot of documentation about Cups, especially also an administrator and an user manual. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Nq16vm7lh.pgp Description: PGP signature
Re: ddts: notification about fr-translation of the libroxen-{roxpoll-doc|linkif|presentit}
On Sun, Sep 02, 2001 at 02:22:16PM +0200, Turbo Fredriksson wrote: I'm all for international descriptions. In roxen and roxen2 packages for debconf, I have a number of languages. But philippe, if you're to translate, then you have more job to do. You have 55 packages to translate! (just joking, don't take it the way it reads philippe, I _AM_ gratefull! :) Can I get more language translating, I'll upload asap. I didn't think package maintainers were supposed to upload packages with the translated descriptions? -- Colin Watson [EMAIL PROTECTED]
Re: CUPS
On Sun, Sep 02, 2001 at 12:19:51PM +0200, Christian Kurz wrote: Would you mind telling us which version of cups you have installed? You didn't include that information. Sorry, I forgot that. It's the actual woody version: ii cupsomatic-ppd 0.20010420-3 cups printer ppd's from LinuxPrinting.org ii cupsys 1.1.4-3Common UNIX Printing System(tm) - server ii cupsys-client 1.1.4-3Common UNIX Printing System(tm) - client pro ii kdelibs3-cups 2.2.0-final-3 KDE print system (CUPS support) ii libcupsys2 1.1.6-0.1 Common UNIX Printing System(tm) - libs ii libqtcups2 2.0-3 Qt interface library for CUPS ii qtcups 2.0-3 Qt front-end for CUPS. Under the following URL http://localhost:631/documentation.html is a lot of documentation about Cups, especially also an administrator and an user manual. Yes, I know that. But it appears to be a problem with the cupsomatic-ppd printer file. Also I still wonder if there's a reason for not configuring a printer in the postinst as does the lpr/magicfilter combo. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: step by step HOWTO switch debian installation into utf-8
On Sat, Sep 01, 2001 at 02:42:31PM -0500, David Starner wrote: en_AU UTF-8 tells it to make en_AU a UTF-8 locale. If you want en_AU.ISO-8859-1 as well, then add en_AU UTF-8 en_AU.ISO-8859-1 ISO-8859-1 or (what I would recommmend) en_AU.UTF-8 UTF-8 en_AU ISO-8859-1 Just out of interest, for what reason would you recommend the latter rather than the former? And what about en_AU.UTF-8 UTF-8 en_AU.ISO-8859-1 ISO-8859-1 ? Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: sysctl should disable ECN by default
#include hallo.h Neil Spring wrote on Sat Sep 01, 2001 um 06:39:58PM: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0145.html As David noted, I'm in favor of turning ECN off-as-default. Good. The problem - it is on by default in our precompiled kernel-image packages. To disable (by default), you have to remove ECN support from kernel or either patch the kernel to make int off-as-default (*) or put in in the template of sysctl.conf. (*) I doubt Herbert Xu would like such modifications. My point is still that it should be dirt simple to turn it on again. If you're going to quote the social contract, Okay, why not just put the line into sysctl.conf and present a big warning in the baseconfig? then you should see the logic in respecting the user's wishes, and not trying to disable what they've knowingly enabled in the kernel configuration. Look, we have in general two parts of users: - administrator kind, people that _may_ need ECN (but mostly don't though). We can expect them to RTFM and remove the hook from sysctl.conf after reading the baseconfig message. - the users - the majority. People that do as less RTFM as possible, that do not need ECN and the should not be bothered with such problems. This people would ignore the warning and have an easier life without getting in touch with sysctl.conf. Is my proposal acceptable now? Gruss/Regards, Eduard. -- Der Wahnsinn hat Methode! pgpUyKf5UtMPl.pgp Description: PGP signature
Re: ddts: notification about fr-translation of the libroxen-{roxpoll-doc|linkif|presentit}
On Sun, Sep 02, 2001 at 08:11:53AM -0500, Colin Watson wrote: On Sun, Sep 02, 2001 at 02:22:16PM +0200, Turbo Fredriksson wrote: I'm all for international descriptions. In roxen and roxen2 packages for debconf, I have a number of languages. But philippe, if you're to translate, then you have more job to do. You have 55 packages to translate! (just joking, don't take it the way it reads philippe, I _AM_ gratefull! :) Can I get more language translating, I'll upload asap. I didn't think package maintainers were supposed to upload packages with the translated descriptions? yes, not now. See the old and in future comming proposals and all mails with this proposals. Now we don't have a real form of - the use of the translation in dpkg and apt - the format of the 'pre install' download to the user - the format of the translation in the deb package and/or source. Read the notification: 'No action is required on your part.' If we have a ready process, we will make a announcement and I will change the mail from the server and add a guide and a attachment in the right format. Maybe you read the proposals and write your comments to debian-devel. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux It is not yet possible to change operating system by writing to /proc/sys/kernel/ostype. sysctl(2) man page pgpHrqZ6b5jRD.pgp Description: PGP signature
Re: sysctl should disable ECN by default
Eduard Bloch [EMAIL PROTECTED] writes: Package: procps Version: 1:2.0.7-6 Severity: wishlist Tags: woody I suggest to disable ECN¹ in the default network configuration. This should be done in Woody since we don't like our users to be confused just because of the ECN support in kernel is turned on. ¹ ECN bit causes trouble on bad configured firewalls, so the fresh installed Debian box won't be able to connect some remote hosts. Gruss/Regards, Eduard. I think that should be refiled against kernel-image-2.4.x. Those, since they have the flag enabled, should warn about it and turn it off in /etc/sysctl.conf upon first install (not on update, so you can delete the option). Or just ask via debconf. MfG Goswin
ECN: Why just on/off? can one mangle that per iptables?
Hi, I have some thoughts about the ECN bit: Why is it on per default when compiled in? Normaly I would expect it to be off unless activated in proc, like ip_forward or syn-cookie or lots of other stuff. Why can one only turn it on/off? I want it on normaly, but not for a few hosts or routes. Why can't I enable it to eth0 but not for eth1? Is there a way to mangle that bit (on or off) with iptables? I would realy love that feature. I have one site which doesn't work with ECN so I have to disable it. Why not catch all connects to that site and disbale the ECN bit upon connect per ipchains? I would like a package that comes with a blacklist of NON-ECN hosts and disables those per ipchain with regular updates. May the Source be with you. Goswin
Making better use of multiple maintainers
During the base freeze preparations in the last few weeks, a problem Debian has always had became apparent again. Since Debian is a distributed, volunteer run project it is hard to tell whether a maintainer is doing Debian work at the moment. In the freeze, it is often crucial to get a bug fixed within a very short period of time. If the maintainer doesn't respond to e-mail immediately, you can either wait or make an NMU. The former is problematic since it might delay the freeze and the latter might break the package, which in turn would cause a delay (Of course NMUs don't always break the package but the likelihood of breaking a package is higher if you don't know the package well). A feature has recently been implemented in dpkg/katie which could solve this problem (along with a couple of others) if deployed properly. In Debian, a package usually has one maintainer. When someone other than the maintainer makes a source upload, katie recognizes the upload as an NMU and tags the bugs as fixed instead of closing them. Since some packages have multiple maintainers, an Uploaders field (in debian/control) has been introduced in dpkg 1.9.13 (see #101815) -- katie now also checks this field in order to determine if the upload is an NMU. What I'm basically proposing is that it would be nice if packages had a backup maintainer or two listed in the Uploaders field. The maintainer could ask someone with whom he works together well and whom he trusts if he wants to co-maintain the package. The maintainer would still act as the package's official maintainer, but the other one can act as a backup when the main maintainer is busy or on vacation. I think we should try to implement that scheme at least for packages in base and standard... but why not go ahead and try to do it for all packages? Now, while this proposal may sound like a simple idea, it has wide ranging implications: - Bugs could get fixed sooner since more people are working on the package. This would help us meeting our release goals. - There would be less breakage due to NMUs because there is a backup who knows the package well. This would also give maintainers more control over who's likely to work on their packages if an emergency arises. - When the maintainer loses interest in a package, he doesn't necessarily have to orphan it and wait for someone to pick it up. Instead, he can immediately give the package to the backup maintainer. Orphaned packages often don't get the attention they would deserve and this might fix that. - Packages in the base system have more bugs than other packages. Now you may say that this is logical since more people use base packages than some other packages. But why don't we take this to the logical conclusion and have more maintainers for common packages? - The concept of one-package-one-maintainer doesn't necessarily have to be kept. As mentioned previously, I think it makes sense that common packages have more maintainers. This would mean that packages would get more attention and more bugs fixed. The BTS allows more than one person to get bug reports for a specific package (through an overwrite file) and in the future it will be possible to subscribe to individual bugs. The backup maintainer could follow the bug reports and assist the maintainer. I don't want to force this upon people. You are the maintainer of your packages and it's your decision whether you want to add backup maintainers. However, I feel that having multiple maintainers for packages could lead to a big increase in Debian's quality. At the moment, Debian is growing quite dramatically in size but I'd love to see more manpower devoted to existing packages instead of (or in addition to) new packages.
Re: step by step HOWTO switch debian installation into utf-8
On Sun, 2 Sep 2001, Drew Parsons wrote: en_AU UTF-8 tells it to make en_AU a UTF-8 locale. If you want en_AU.ISO-8859-1 as well, then add en_AU UTF-8 en_AU.ISO-8859-1 ISO-8859-1 or (what I would recommmend) en_AU.UTF-8 UTF-8 en_AU ISO-8859-1 Just out of interest, for what reason would you recommend the latter rather than the former? The only reason I can see for this is so that you don't surprise other users of the system by breaking their current en_AU locale setting. If you're on a single-user system, I don't see any reason for not pointing en_AU at UTF-8. And what about en_AU.UTF-8 UTF-8 en_AU.ISO-8859-1 ISO-8859-1 Then 'en_AU' is not a usable locale, and you have to specify a charset to get anything... There's a benefit to having a default charset for the locale. Steve Langasek postmodern programmer
library build problems
Hi all, I'm the maintainer of the libsndfile package, and I've noticed that there's been an NMU to fix a build problem. (Sorry for being absent ... got a job and have a lot less free time now.) Anyway, there's a new release, and I tried to update the package (from the NMU version) but now I'm having trouble building it. It seems that libtool is breaking somehow, during the compilation: ../libtool: test: =: unary operator expected ../libtool: test: =: unary operator expected and it just bombs out later with: libtool: link: cannot find the library `' Honestly I've *no* idea about libtool problems, so I'm just hoping that some kind soul here would be willing to help me with this? Thanks. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: Making better use of multiple maintainers
Martin Michlmayr [EMAIL PROTECTED] writes: - Bugs could get fixed sooner since more people are working on the package. This would help us meeting our release goals. The Mythical Man Month, of which Debian is exemplary[0]. Given enough eyes, all bugs are shallow, of which Debian is also exemplary, is a another, prettier, way of saying men and months are interchangeable commodities only when a task can be partitioned among many workers *with no communication among them*. It doesn't mean throw more people at a problem and it will get solved faster. Your idea is practicable iff the group of maintainers actually communicate with each other, that is, the package is actually jointly maintained. Let me take two of my own packages as an example: * wmaker. It's not a complex package, but it operates under several different conditions (or enviroments) which are different enough from each other that makes it imposible for me to gain expertise in all of them (IOW, I don't use wmaker with GNOME, and it's very time consuming for me to try to figure out ways of reproducing bugs under those conditions, given the *absolutely* *wonderful* and *marvelous* documentation GNOME and its packages have) * celestia. Simple. Very limited scope. Not many configuration options. Would I like to find a co-maintainer for wmaker? Yes. Celestia? No. My criteria for considering co-maintainership is simple: Can I cover all the possible ways of using this package myself? [0] We never finished that conversation at Linux Tag. -- Marcelo | This signature was automatically generated with [EMAIL PROTECTED] | Signify v1.07. For this and other cool products, | check out http://www.debian.org/
Re: sysklogd = syslog-ng
Hi All! On 2001 Aug 24, Wichert Akkerman wrote: AFAIK you'll still have to use klogd if you want to have addresses in kernel messages replaced with symbolic names from System.map. That is a bad idea anyway so please don't do that and use ksymoops instead. Why? I have a new version (at least :) from syslog-ng and I changed it to work with klogd. I do it wrong? -- PGP ID 0x8D143771, /C5 95 43 F8 6F 19 E8 29 53 5E 96 61 05 63 42 D0 GPG ID ABA0E8B2, 45CF B559 8281 8091 8469 CACD DB71 AEFC ABA0 E8B2 The quickest way of ending a war is to lose it - George Orwell
probably FAQ: Uploading to sid with potato's dupload?
Hi, this might be an FAQ; but for security, I'll ask as well: I do my development in a sid chroot on potato. Can I use potato's dupload to upload the finished packages, or do I need to copy my keys into the chroot to be able to use sid's dupload? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Making better use of multiple maintainers
How are things going to get better if new things like this aren't tried? It'll certainly knock out some issues in sponsorship and NM... If your only objections are those of the improbability of getting it to work, let Martin run with it and find out for hisself. On Sun, 2 Sep 2001, Marcelo E. Magallon wrote: Martin Michlmayr [EMAIL PROTECTED] writes: - Bugs could get fixed sooner since more people are working on the package. This would help us meeting our release goals. The Mythical Man Month, of which Debian is exemplary[0]. Given enough eyes, all bugs are shallow, of which Debian is also exemplary, is a another, prettier, way of saying men and months are interchangeable commodities only when a task can be partitioned among many workers *with no communication among them*. It doesn't mean throw more people at a problem and it will get solved faster. Your idea is practicable iff the group of maintainers actually communicate with each other, that is, the package is actually jointly maintained. Let me take two of my own packages as an example: * wmaker. It's not a complex package, but it operates under several different conditions (or enviroments) which are different enough from each other that makes it imposible for me to gain expertise in all of them (IOW, I don't use wmaker with GNOME, and it's very time consuming for me to try to figure out ways of reproducing bugs under those conditions, given the *absolutely* *wonderful* and *marvelous* documentation GNOME and its packages have) * celestia. Simple. Very limited scope. Not many configuration options. Would I like to find a co-maintainer for wmaker? Yes. Celestia? No. My criteria for considering co-maintainership is simple: Can I cover all the possible ways of using this package myself? [0] We never finished that conversation at Linux Tag. -- EMACS == Eight Megabytes And Constantly Swapping Who is John Galt? [EMAIL PROTECTED], that's who!
moving a package from non-US/main to main?
Hi, One of my packages, apg, has a new upstream release, 2.0.0b3. The old versions included some algorithms using SHA and were in non-US. The new version still has SHA, but can be compiled without using the SHA sources, using CAST instead. As far as I understand, a program only using CAST can be in main. What do I have to do to move the package? What do I do with the upstream tarball that still has the SHA code included? Is it possible to have a package's source in non-US while the binary package is in main? Any hints will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: moving a package from non-US/main to main?
Marc Haber: Is it possible to have a package's source in non-US while the binary package is in main? No, katie (the program which installs packages from incoming to its final destination) does not support that. However, you can repackage the .orig.tar.gz source and remove the non-US bits from it. Then you could upload both source and binaries to main. (warning: katie might complain that the md5sum of the .orig.tar.gz file changed, but I'm not sure in this case, it's possible that main and non-US/main have different namespaces).
Re: moving a package from non-US/main to main?
If the source includes SHA, then it must remain in non-US, together with the binaries (iow: binaries compiled without SHA, from a source which has SHA in it must be in non-us still). At least, that's what I think, but I may be wrong. -- Gergely Nagy \ mhp/|8] pgpJ5XuclYybE.pgp Description: PGP signature
Re: Making better use of multiple maintainers
[ your Mail-Followup-To is still leaving the list out ] John Galt [EMAIL PROTECTED] writes: How are things going to get better if new things like this aren't tried? It'll certainly knock out some issues in sponsorship and NM... If your only objections are those of the improbability of getting it to work, let Martin run with it and find out for hisself. Martin's mail was much longer than the tiny little bit which I replied to. I actually replied only to the assertion than putting more people behind one package gets bugs fixed faster because there's more people behind it, and I was by no means bashing his idea. I actually provided one example where it could make sense. I ought to listen to Zinsser and use shorter words, I obviously failed to get an idea across. -- Marcelo | This signature was automatically generated with [EMAIL PROTECTED] | Signify v1.07. For this and other cool products, | check out http://www.debian.org/
Re: moving a package from non-US/main to main?
On Sun, 2 Sep 2001 22:49:00 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] wrote: However, you can repackage the .orig.tar.gz source and remove the non-US bits from it. Then you could upload both source and binaries to main. That would break the principle of pristine sources, though. Can anybody confirm that CAST is not among the non-USable offenses? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: sysctl should disable ECN by default
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
3) can we disable ECN for joe user with the default kernel
while permitting joe custom-kernel-user to enable ECN with
one checkbox?
4) more than one place to make a configuration change
reuduces ease of use, which is what we're trying to achieve
by disabling ECN in the first place.
The Director's Cut:
Good. The problem - it is on by default in our precompiled kernel-image
packages. To disable (by default), (a) you have to remove ECN support from
kernel or (b) either patch the kernel to make int off-as-default (*) or (c)
put
in in the template of sysctl.conf.
(*) I doubt Herbert Xu would like such modifications.
(*) wha? no kernel patch is required. The default
distribution of the kernel, as distributed by Linus Himself
leaves ECN off. Somewhere, someone decided to turn it on.
Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?
I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN. A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.
Okay, why not just put the line into sysctl.conf and present a big
warning in the baseconfig?
I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?
Would this be printed when kernel-image is installed?
when kernel-package is run? from netbase? something at
all related to networking or the kernel?
Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
a message describing that ECN is disabled from there,
2) that configuration file has something to do with
networking, and 3) there's apparently a precedent with
syn_cookies configuration.
then you should see the logic in respecting the user's
wishes, and not trying to disable what they've knowingly
enabled in the kernel configuration.
Look, we have in general two parts of users:
- administrator kind, people that _may_ need ECN (but mostly don't
though). We can expect them to RTFM and remove the hook from
sysctl.conf after reading the baseconfig message.
- the users - the majority. People that do as less RTFM as possible,
that do not need ECN and the should not be bothered with such
problems. This people would ignore the warning and have an easier life
without getting in touch with sysctl.conf.
It seems our difference is that you think prioritizing
users means choosing for them, and I think prioritizing
users means respecting their (possibly incorrect, possibly
ignorant) choice. These don't necessarily conflict,
but it requires care to support both.
I don't think the dichotomy between illiterate idiots and
uber-administrators is realistic: I'm an 'administrator'
who'd rather spend time playing my guitar or doing research
than reading documentation. There are users of varying
skill levels, including those who have to recompile their
own kernel and will have the opportunity to decide in the
kernel configuration whether to enable ECN.
**When one checkbox should suffice, there should not be two.**
Is my proposal acceptable now?
Big warning + ECN disabled by default = acceptable.
Who am I to complain?
All I care about is that whatever legitimate attempts
the user makes to configure his or her system are
respected whenever possible. If a user configures
a kernel and says ECN, yes! he has a reasonable
expectation that ECN will actually be enabled. If ECN
will not be enabled, this must be clear - not hidden in
/usr/share/doc/{netbase,procps,kernel-image}, not hidden
in the gobs of messages one clicks through when installing
Debian, but shown when a custom kernel is installed or
booted. Better yet, if the user has enabled it in the
kernel, it should just stay enabled.
I realize these are hard things. I will tell a short
story to try to justify the effort. My mother uses a
windows machine, and wanted to configure her printer to
print 360dpi instead of 180dpi. She found that to do this,
she would have to enter the printer options dialog every
time she wanted to print. From within an application,
the configuration is not saved; not even for future
use by that application. Only if you enter the identical
printer options dialog from the control panel are settings
saved permanently. She has every legitimate reason to
believe that the choice made in the options dialog from
an application would be as permanent as from the control
panel, but it is not. Let's not make it as difficult to
configure a Debian system.
This discussion presumes
Re: moving a package from non-US/main to main?
Gergely Nagy [EMAIL PROTECTED] wrote:
If the source includes SHA, then it must remain in non-US, together
with the binaries (iow: binaries compiled without SHA, from a source
which has SHA in it must be in non-us still).
At least, that's what I think, but I may be wrong.
You're wrong, or we'd have to move the kernel to non-US.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: sysctl should disable ECN by default
Goswin Brederlow [EMAIL PROTECTED] wrote:
I think that should be refiled against kernel-image-2.4.x. Those,
since they have the flag enabled, should warn about it and turn it off
in /etc/sysctl.conf upon first install (not on update, so you can
delete the option).
Or just ask via debconf.
For those that weren't around here the first time this was discussed,
and are too lazy to read the archives:
1. CONFIG_INET_ECN must be turned on, otherwise the user will have to
recompile the kernel to use it.
2. The kernel will not be patched to disable it by default with INET_ECN
compiled in as the same thing can be easily achieved from user space.
3. The kernel-image postinst is not a good place to do this as installing
a kernel does not mean that you will boot it.
So do whatever you want, but please do it in the right place.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: sysctl should disable ECN by default
On Mon, 3 Sep 2001, Herbert Xu wrote: 3. The kernel-image postinst is not a good place to do this as installing a kernel does not mean that you will boot it. the postinst would be the worst place, as you can't be using that kernel already at the moment postinst is ran for the first time... -- wouter dot verhelst at advalvas dot be Human knowledge belongs to the world -- from the movie Antitrust
Bug#111005: ITP: libggimisc - GGI Misc extension library, split from libggi.
Package: wnpp Severity: wishlist The package was (unfortunately) split out of libggi. It provides hardware dependant extensions for framebuffer-, x- and svgalib-targets. - Programs that compile with -lggimisc have to depend on this package - Download: ftp://ftp.ggi-project.org/pub/ggi Homepage: http://www.ggi-project.org Copyright: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The above copyright notice applies to all files in this package, unless explicitly stated otherwise in the file itself or in a file named COPYING in the same directory as the file.
ITP survex
Survex is cave-surveying software, available for several platforms (Unix, Windows, RISCOS, DOS). IT has been available as an unofficial debian package for a year or so since I first had a go at packaging it, and the upstream author included that and made them work. However the packaging is primitive as well as unofficial so I've decided its time to do it properly. This work has been progressing astonishingly slowly so I refrained from posting here, but as I'm in danger of making some progress, I decided it was time to post an ITP. see http://www.survex.com/ for the current downloads and info. Wookey
Re: sysctl should disable ECN by default
#include hallo.h
Neil Spring wrote on Sun Sep 02, 2001 um 02:05:57PM:
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
See mail from Herbert.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
Another good idea.
(*) wha? no kernel patch is required. The default
Not really true.
distribution of the kernel, as distributed by Linus Himself
leaves ECN off. Somewhere, someone decided to turn it on.
while(discussion_turns_in_circle) {
- If ECN support is compiled, it is turned on by default.
- If we wish to have support for it, we have to enable it.
- When we enable it, it will be enabled by default.
}
Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?
See Herbert's mail. IMHO we need a good place to disable it and notify
the user.
I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN. A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.
All this is said before. I oppose strongly the use of such experimental
features in precompiled kernel images. If the are used, than not turned
on by default. If the kernel patching is not acceptable, we need a
runtime-solution to disable it, I don't see any other ways.
Okay, why not just put the line into sysctl.conf and present a big
warning in the baseconfig?
I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?
A good question. Theoreticaly first time when a 2.4.x kernel-image is
installed. A hook in the kernel's postinst is ugly, but doable.
Would this be printed when kernel-image is installed?
when kernel-package is run? from netbase? something at
all related to networking or the kernel?
On architectures with 2.4.x default kernel from baseconfig or so, on
architectures with 2.2.x kernel in the postinst of the kernel-image.
Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
Why not...
Is my proposal acceptable now?
Big warning + ECN disabled by default = acceptable.
Who am I to complain?
[ shorted director's cut, thanks for contribution ;) ]
Gruss/Regards,
Eduard.
--
Definition of Windows 9x:
A 32 bit upgrade to a 16 bit extensions for an 8 bit operating system
designed to run on a 4 bit processor by a 2 bit company that doesn´t
like 1 bit of competition.
Re: sysctl should disable ECN by default
Zitiere Eduard Bloch [EMAIL PROTECTED]: Can we just choose option (a) and be done with it? If Debian isn't going to choose option (a), why are we talking about option (c)? See Herbert's mail. IMHO we need a good place to disable it and notify the user. Since the beginning of this discussion the solution is there, available, and has been presented here. I just need to find the time to ask for inclusion. Or if someone wants to do that for me please go for it. *Please* check: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862msg=4repeatmerged=yes *t
Re: probably FAQ: Uploading to sid with potato's dupload?
On Sun, Sep 02, 2001 at 10:01:50PM +0200, Marc Haber wrote: Hi, this might be an FAQ; but for security, I'll ask as well: I do my development in a sid chroot on potato. Can I use potato's dupload to upload the finished packages, or do I need to copy my keys into the chroot to be able to use sid's dupload? You can safely try it and find out. I think the only thing to note about potato's dupload is that you have to add ftp-master to /etc/dupload.conf (or ~/.dupload.conf) manually. -- Colin Watson [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Sun, Sep 02, 2001 at 05:56:45PM +0200, Goswin Brederlow wrote: I think that should be refiled against kernel-image-2.4.x. Those, since they have the flag enabled, should warn about it and turn it off in /etc/sysctl.conf upon first install (not on update, so you can delete the option). Or just ask via debconf. no package is permitted to modify /etc/sysctl.conf. its a conffile belonging to procps, anything (except the admin) modifying it should receive a severity serious bug report. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpNGXvwRWTuS.pgp Description: PGP signature
Re: sysctl should disable ECN by default
(*) wha? no kernel patch is required. The default Not really true. After reading Herbert's mail, I understand what you were trying to do now with the patch. Thanks for explaining the baseconfig / postinst issues. What a mess. -neil
How many people need locales?
Hello. For the purposes of determining whether or not most users need to change the /etc/locale.gen file Ben and I need an estimate of the proportion of Debian users using locales among all Debian users. [ See Bug #111008 for details ]. I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? Thanks.
Re: How many people need locales?
Hi, I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? In case of Japanese, I cannot imagine any Japanese people using Linux without locale, except for server purpose. (I don't run apache, postfix, and so on under Japanese locale.) In short, all Japanese users of Desktop Linux use locale. Estimating number of users from ML subscribers: Since there are [EMAIL PROTECTED] mailing lists whose public language is Japanese, Japanese people tend to subscribe them and don't subscribe [EMAIL PROTECTED] or even debian-japanese@lists.debian.org . (The public language of debian-japanese@lists.debian.org is English and the list is mainly used by foreign people who want to configure Japanese environment.) I think the administrator of debian.or.jp mailing lists knows the number of subscribers of [EMAIL PROTECTED] lists. Also I imagine ordinary Chinese and Korean people use locale. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ Introduction to I18N http://www.debian.org/doc/manuals/intro-i18n/
Re: How many people need locales?
On Mon, Sep 03, 2001 at 02:21:04AM +0200, Santiago Vila wrote: Hello. For the purposes of determining whether or not most users need to change the /etc/locale.gen file Ben and I need an estimate of the proportion of Debian users using locales among all Debian users. [ See Bug #111008 for details ]. I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? There is a package called 'popularity-contest' . It looks for most used files/packages and sends them out anonymously to be compiled into statistics. Maybe you can talk to it's maintainer, and see if he is willing to look into locales statistics in the next release? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- GPG key-id: 1024D/5BE3DCFD Dmitriy CCAB 5F17 A099 9E43 1DBE 295C 9A21 2F1C 5BE3 DCFD Adobe put Dmitry in jail for the crime against society of revealing that they were selling ROT-13 as encryption. He is rotting in US prison as a political prisoner for speaking out. Free Dmitry Sklyarov! http://www.freesklyarov.org pgp6GniU4kIyB.pgp Description: PGP signature
Re: How many people need locales?
On Mon, Sep 03, 2001 at 09:46:42AM +0900, Tomohiro KUBOTA wrote: Hi, I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? In case of Japanese, I cannot imagine any Japanese people using Linux without locale, except for server purpose. (I don't run apache, postfix, and so on under Japanese locale.) In short, all Japanese users of Desktop Linux use locale. Estimating number of users from ML subscribers: Since there are [EMAIL PROTECTED] mailing lists whose public language is Japanese, Japanese people tend to subscribe them and don't subscribe [EMAIL PROTECTED] or even debian-japanese@lists.debian.org . (The public language of debian-japanese@lists.debian.org is English and the list is mainly used by foreign people who want to configure Japanese environment.) I think the administrator of debian.or.jp mailing lists knows the number of subscribers of [EMAIL PROTECTED] lists. Also I imagine ordinary Chinese and Korean people use locale. add Russian to that list too :-) --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ Introduction to I18N http://www.debian.org/doc/manuals/intro-i18n/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- GPG key-id: 1024D/5BE3DCFD Dmitriy CCAB 5F17 A099 9E43 1DBE 295C 9A21 2F1C 5BE3 DCFD Adobe put Dmitry in jail for the crime against society of revealing that they were selling ROT-13 as encryption. He is rotting in US prison as a political prisoner for speaking out. Free Dmitry Sklyarov! http://www.freesklyarov.org pgp5IXpmNFLAO.pgp Description: PGP signature
Re: sysctl should disable ECN by default
On Mon, Sep 03, 2001 at 07:44:19AM +1000, Herbert Xu wrote: 1. CONFIG_INET_ECN must be turned on, otherwise the user will have to recompile the kernel to use it. yes, that is correct. if the user wants ECN, they should compile the kernel to enable it. [...] So do whatever you want, but please do it in the right place. which is in the kernel-image .config file. 1. stock kernel-images should only include options which are necessary for booting installing debian 2. they should not include non-essential experimental features. ECN fails on both counts. ECN is a good thing, and widespread adoption of it should be encouraged - BUT enabling it should require an informed act by the user since it is likely to result in network outages at the moment. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Bug#110721: ITP: css-elisp -- Emacs Mode for editing Cascading Style Sheets
* Ole Aamot | URL: http://synthcode.com/emacs/lang/css-mode.el | Description: | css-elisp is a language mode for editing Cascade Style Sheets, | offering syntax highlighting and tab completion. There is also a css-mode available at http://www.garshol.priv.no/download/software/css-mode/ , which has some features not found in the version above. (Without me remembering the differences) I started merging them (at least, I think I did) a long time ago, just tell me if you want what I have. -- Tollef Fog Heen You Can't Win
Re: pam_xauth
* Wouter Verhelst | AFAIK, there's no package for it, but you can download it from his | website. I don't recall what that site was, but he's been discussing that | here a few weeks or months ago in a thread called X authentication and | su or something likewise. http://fgouget.free.fr/sux/ -- Tollef Fog Heen You Can't Win
Re: /usr/dict/ - /usr/share/dict/ request (bug #110632)
* Richard Kettlewell | (I await with interest your attempt to have /etc/alternatives and | /etc/rc*.d eliminated or de-symlinked...) apt-get install file-rc does one of them: $ ls /etc/rc*.d zsh: no matches found: /etc/rc*.d $ -- Tollef Fog Heen You Can't Win
Re: Making better use of multiple maintainers
On Sun, Sep 02, 2001 at 10:57:06PM +0200, Marcelo E. Magallon wrote: I ought to listen to Zinsser and use shorter words Only with Galt. -- G. Branden Robinson|If you wish to strive for peace of Debian GNU/Linux |soul, then believe; if you wish to [EMAIL PROTECTED] |be a devotee of truth, then http://people.debian.org/~branden/ |inquire. -- Friedrich Nietzsche pgpYBbW3MuGmv.pgp Description: PGP signature
Re: Bug#110875: sysctl should disable ECN by default
On Sat, Sep 01, 2001 at 04:04:12PM +0200, Eduard Bloch wrote: I suggest to disable ECN? in the default network configuration. This should be done in Woody since we don't like our users to be confused just because of the ECN support in kernel is turned on. This would be an abuse of the procps package and would only work on systems that are installing procps for the first time, which is a very small minority of machines. If ECN causes so much problems, then dont enable it in the default kernel. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/[EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
Re: How many people need locales?
On Mon, 03 Sep 2001, Santiago Vila wrote: For the purposes of determining whether or not most users need to change the /etc/locale.gen file Ben and I need an estimate of the proportion of Debian users using locales among all Debian users. That would be most non-english-speaking users, I suppose. However, if I relate this to #111008 (is this the right bug?), the answer is easier: I'd say the bug reporter is right. Debian patches to the sources CANNOT be allowed to break the translations; send them upstream and use an en locale in the meantime if the fixes are serious enough to warrant it. Even if only 10% of our users needed proper i18n support, that would still be enough reason not to break the gettext support like that IMHO. I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? That will get you a result with a tendency to less people need locales, I think. But it is useful if it gives you a positive (i.e. enough people need locales), in that case. Can you think of another way to estimate the proportion of users using locales? Ask maintainers of non-english-speaking countries what they know about their local use base. I can provide you with an answer for Brazil: we need it; People will use Conectiva just because of the better translation as things stand, let alone if the system looks like it will not support pt_BR out-of-the-box properly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpjEXzlwWyEx.pgp Description: PGP signature
Logos Sonneries/Repondeur/Dedicaces
Bonjour, Nous avons vu votre site : http://www.lists.debian.org et nous sommes certains que vous pouvez gagner beaucoup dargent avec votre trafic internet grace a: LOGOS/SONNERIES REPONDEUR TELEPHONIQUE DEDICACES AU TELEPHONE C'est amusant et sur tout le trafic que vous generez vous gagnez de l'argent. Nous vous fournissons les applications et les numéros audiotext prets a l'emploi. Nous vous fournissons nos solutions GRATUITEMENT. Vos statistiques sont consultables en temps reel par Internet. Nous vous payons à 30 jours nets. Audiotextelecom vous offre la meilleure solution du marché et le meilleur reversement. Vous pouvez demarrer en 2 jours sur n'importe quel pays d'Europe. Alors qu'attendez-vous, contactez-nous pour demarrer : http://members.tripod.de/UKmobiles1/ http://members.tripod.de/UKmobiles2/ http://members.tripod.de/UKmobiles3/ Si vous avez besoin aussi de solutions de paiement sans carte de crédit pour toutes vos applications Internet, contactez nous : nous avons aussi la solution pour vous. Cordialement, Monica Hayes Audiotext Voice Applications Hello, We have seen your website http://www.lists.debian.org and were sure you can earn great money with your Internet traffic and some amazing applications: LOGOS / RINGTONES ANSWER MACHINE VOICE GREETINGS Offer a new and amusing service and get money from all the traffic generated. We supply the applications and audiotext phone numbers needed. Setting-up our services is absolutely FREE. Your statistics are available in real time by Internet. We pay you at 30 days EOM. AudioTelecom offers to you the best turn-key solutions and the best payment rates. You can start in just 2 days from any European country. We hope you discover this amazing new solution, don´t hesitate to contact us to start earning big incomes. http://members.tripod.de/UKmobiles1/ http://members.tripod.de/UKmobiles2/ http://members.tripod.de/UKmobiles3/ If you also need payment solutions with no credit card needed for all your Internet applications, contact us : We have the solution you need. Kind regards, Monica Hayes Audiotext Voice Applications
Re: moving a package from non-US/main to main?
Marc == Marc Haber [EMAIL PROTECTED] writes: Marc On Sun, 2 Sep 2001 22:49:00 +0200 (CEST), Santiago Vila Marc [EMAIL PROTECTED] wrote: However, you can repackage the .orig.tar.gz source and remove the non-US bits from it. Then you could upload both source and binaries to main. Marc That would break the principle of pristine sources, though. So, that's not a principle, it's a somewhat desirable goal. For some licenses it may be necessary, but there are many reasons you might have to change the upstream tarball, including for example DFSG problems with part of a program. Marc Can anybody confirm that CAST is not among the non-USable Marc offenses? First, CAST is actually going to be less exportable than SHA. CAST is a crypto system family, SHA is a hash. I think software that only uses SHA is likely not to fall under ECCN 5d002 or 5e002 of the US Commerce Control List and thus doesn't fall under the annoying crypto stuff. I.E. I suspect you could have stuck the SHA only version in main, but need to stick SHA+CAST in non-us. Marc Greetings Marc Marc -- -- !! No courtesy Marc copies, please !! - Marc Haber | Questions are the | Marc Mailadresse im Header Karlsruhe, Germany | Beginning of Marc Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Marc Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29 Marc -- To UNSUBSCRIBE, email to Marc [EMAIL PROTECTED] with a subject of Marc unsubscribe. Trouble? Contact [EMAIL PROTECTED]
