Re: Rsum des discussions au sujet de debconf sur debian-devel
Quoting Martin Quinson ([EMAIL PROTECTED]): Il me semble qu'une meilleure solution ici serait de demander au mainteneur d'iso-codes de faire un ptit script permettant de faire les conversions qui vont bien (nom - code), et d'obtenir la traduction des noms. En attachement, un ptit script offrant l'API suivante : USAGE: iso-codes getcode (language|country) iso-codes getlangcode iso-codes getcountry code Et on peut faire code=`iso-codes getcode French` pour avoir code==fr On devrait pouvoir traduire, au moins dans le sens en-autre, mais j'ai pas reussi a le faire car gettext(1) me resiste. Si quelqu'un y arrive, je pense que ce script gagnerait a etre inclu dans le paquet iso-codes, et je ferais le rapport et suivi de bug necessaire. Je supporte cette proposition. A mon avis, ton script peut déjà aller dans iso-codes, même s'il ne sait pas encore fournir la version traduite. Ce serait ainsi déjà très pratique pour au moins deux paquets, geneweb et sympa si on se réfère à la discussion précédente..:-) Je vois même encore plus loin : Il y a certainement encore d'autres paquets qui proposent, via debconf, le choix d'une langue. Pour l'instant, cela oblige les traducteurs à traduire des listes de langues : Template: geneweb/lang Type: select Choices: Afrikaans (af), Bulgarian (bu), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) Choices-ca.ISO-8859-15: afrikaans (af), búlgar (bu), català (ca), xinès (zh), txec (cs), danès (da), holandès (nl), anglès (en), esperanto (eo), estonià (et), finès (fi), francès (fr), alemany (de), hebreu (he), islandès (is), italià (it), letó (lv), noruec (no), polonès (pl), portuguès (pt), romanès (ro), rus (ru), espanyol (es), suec (sv) Choices-da.ISO-8859-1: afrikaans (af), bulgarsk (bu), catalansk (ca), kinesisk (zh), tjekkisk (cs), dansk (da), hollandsk (nl), engelsk (en), esperanto (eo), estisk (et), finsk (fi), fransk (fr), tysk (de), hebræisk (he), islandsk (is), italiensk (it), lettisk (lv), norsk (no), polsk (pl), portugisisk (pt), rumænsk (ro), russisk (ru), spansk (es), svensk (sv) etc... Du coup, dès qu'une nouvelle langue est ajoutée, bing.toutes les traductions deviennent fuzzy. On pourrait donc peut-être imaginer une entrée spécifique dans le fichier templates que po-debconf traiterait de manière particulière : _LangChoices: Afrikaans, Bulgarian, Catalan, Chinese, Czech, Danish, Dutch, English, Esperanto, Estonian, Finnish, French, German, Hebrew, Icelandic, Italian, Latvian, Norwegian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish Dans ce cas précis, quand on utiliserait debconf-updatepo, les champs Choices seraient automatiquement mis à jour A part modifier des scripts de po-debconf, cela n'imposerait qu'une chose de plus : rendre celui-ci dépendant de iso-codes C'est juste une idée pas encore totalement formée, mais je pense que vous gettez bien le point? :-)
Re: Résumé des discussions au sujet de debconf sur debian-devel
On Sun, Apr 27, 2003 at 08:41:16AM +0200, Christian Perrier wrote: [...] Du coup, dès qu'une nouvelle langue est ajoutée, bing.toutes les traductions deviennent fuzzy. Pas nécessairement, tu peux regarder ce que j'avais fait avec languagechooser (mais les nouvelles versions ont été complètement remaniées), en utilisant __Choices au lieu de _Choices. Cette syntaxe est expliquée dans po-debconf(7), section « New master templates ». On pourrait donc peut-être imaginer une entrée spécifique dans le fichier templates que po-debconf traiterait de manière particulière : _LangChoices: Afrikaans, Bulgarian, Catalan, Chinese, Czech, Danish, Dutch, English, Esperanto, Estonian, Finnish, French, German, Hebrew, Icelandic, Italian, Latvian, Norwegian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish Dans ce cas précis, quand on utiliserait debconf-updatepo, les champs Choices seraient automatiquement mis à jour A part modifier des scripts de po-debconf, cela n'imposerait qu'une chose de plus : rendre celui-ci dépendant de iso-codes L'idée est intéressante, mais le nombre de paquets concerné est très faible, je ne sais pas si ça vaut le coup d'ajouter cette dépendance. Denis
[base-files] Bug ?
Bonjour, Suite à des essais avec le paquet linuxlogo et les fichiers /etc/issue*, j'ai remarqué qu'il n'était pas possible de regénérer le fichier /etc/issue. En supprimant (ou en déplacant) /etc/issue et /etc/issue.net, il est impossible de les réinstaller avec : # apt-get --reinstall install base-files Pourtant, la commande dpkg -S /etc/issue /etc/issue.net renvoie que ces deux fichiers appartiennent au paquet base-files. Est-ce un bogue de base-files ou est-ce qu'un autre script d'installation se charge de créer ces fichiers ? -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
c-arbre
Bonjour, Je developpe avec mes camarades un paquet Debian pour notre logiciel (C-Arbre) que nous aimerions voir, un jour dans cette Distrbution. Suivant la procedure decrite dans le guide du nouveau mainteneur, y a t'il quelqu'un pour me signer ma cle gpg? C-Arbre : http://freshmeat.net/projects/c-arbre Realink.org : http://realink.org Georges
[Debian-Lex] Interview with subproject leader
[Most of the discussion on the Debian-Lex proto-subproject has been off-list, so I'm sending this one to the list so that people can see something of our progress. These answers will be made into an article by Matt Black at some point after we get an official list and Web area.] On Sun, 2003-04-27 at 10:07, Matt Black wrote: * Tell me a about yourself / your background. I'm from Perth, Western Australia, where I work both as a lawyer specialising in information technology law, and as the manager of an IT consultancy. Having one foot in the IT field and another in the IT world is helpful because these areas cross over in much of the work that I do. For example, I fought a prominent legal case against a spammer last year in which my IT knowledge proved useful, and my legal knowledge is often useful when my IT consultancy provides services to law firms. I've been using Debian GNU/Linux for about eight years, and both arms of my business now use it exclusively. * What is Debian? Debian aims to be a universal operating system, that is free to distribute and develop. Debian is available for numerous types of computer system, but its most widely used variant is based around the Linux operating system kernel and runs on ordinary PC hardware. It is, if you like, an alternative for Microsoft Windows, but with the advantage of having many thousands of software packages bundled with it, all of which are free to use and to extend. * What is Debian-Lex? Debian-Lex is project to create a subset of Debian that will provide a pre-configured operating system designed specifically for use in legal practice. Our aim is that Debian-Lex will not only sit on lawyers' desktops, but also be found in their accounts departments, on their office servers, and be used in court registries. Debian-Lex is not a competitor to Debian, as everything that goes into Debian-Lex will go straight into Debian also. It will, however, make it easier to install a Debian GNU/Linux system that is tuned to the requirements of a legal practice. * Who are the people behind Debian and Debian-Lex? The Debian project is quite unique in that it comprises over a thousand participants from all around the world, ranging from software engineers to documentation maintainers, all of whom are unpaid for the work they contribute to the project (although some are sponsored by their employers). Debian-Lex, being a sub-project of Debian, is being developed by some of these same volunteers, so far including three qualified lawyers. Anyone is welcome to apply to join the project, so long as they share our ideals of collaboratively developing a free operating system. * What advantages will Debian-Lex bring to lawyers and law firms? There are hundreds of proprietary software packages designed for lawyers, to fulfil their specialist needs for time recording, trust accounting, and client and matter management. Most of these packages do not interoperate with each other, and still less frequently can the packages in use by one firm exchange information seamlessly with packages in use by another firm, or those in use by a court. One of our main aims for Debian-Lex is to increase interoperability of legal software. * What kind of specialist software will be available in Debian-Lex? We hope to provide a framework for various software packages to access and maintain a central database of client and matter information. One of these will be a sophisticated multi-user accounting package, another is a desktop time recording package, and a third is the well-renowned Microsoft Office-compatible office suite, OpenOffice.org. On a more obscure note, we will have a tool to check for conflicts of interest, and various tools to search and manipulate legal transcripts and pleadings. * With the importance that attaches to legal proceedings, shouldn't lawyers be willing to pay for the best rather than preferring free software? Often free software (or open source software) is the best available. This is so because it can draw on the talents of a much wider community of developers than proprietary software. Moreover, if a software tool does not meet the needs of its users, they have free access to the source code which enables them to modify it to suit their requirements, or to pay a software developer to do so. Many lawyers have been caught out when support for specialised proprietary software they are using has been withdrawn by its developer, or the developer has gone out of business. The use of free, open source software reduces this concern. * When will Debian-Lex be 'released'? That all depends on how many contributors decide to collaborate on it! The Debian project at large does not have a fixed timeline for its releases, and Debian-Lex follows the same policy. We expect that a full, working operating system pre-configured for lawyers will be available if not by the time of the next official Debian release, then by the time of the
Re: Bug#190912: ITP: konqueror-embedded -- A light version of the Konqueror web browser for use in small machines
On Sat, Apr 26, 2003 at 10:24:31PM -0500, Gunnar Wolf wrote: Package: wnpp Version: unavailable; reported 2003-04-26 Severity: wishlist * Package name: konqueror-embedded Version : 20021229_snapshot Upstream Author : Simon Hausman [EMAIL PROTECTED], Paul Chitescu [EMAIL PROTECTED] * URL : http://www.konqueror.org/embedded/ * License : GPL Description : A light version of the Konqueror web browser for use in small machines The Konqueror/Embedded project attempts to build up a special version of the web browsing component of the KDE browser Konqueror (in particular its html rendering engine khtml and its io subsystem). Konqueror-embedded runs as one static binary, being as small as possible while still providing all essential features of a web browser, including -snip- * SSL -snip- This is likely illegal if it is truely one binary and doesn't do the kpart abstraction stuff... I really wish openssl would just vanish someday. Chris
Re: Bug#190912: ITP: konqueror-embedded -- A light version of the Konqueror web browser for use in small machines
-snip- * SSL -snip- This is likely illegal if it is truely one binary and doesn't do the kpart abstraction stuff... I really wish openssl would just vanish someday. Time to start converting the world to gnu TLS, it seems... Morgon -- You said homosexuals form a small percentage of the population. So do Jews. Is that a reason to deny someone equality? - Richard Marceau
Re: Bug#190912: ITP: konqueror-embedded -- A light version of the Konqueror web browser for use in small machines
On Sun, Apr 27, 2003 at 01:48:01AM -0400, Morgon Kanter wrote: -snip- * SSL -snip- This is likely illegal if it is truely one binary and doesn't do the kpart abstraction stuff... I really wish openssl would just vanish someday. Time to start converting the world to gnu TLS, it seems... Yep, as far as I know the only things that need converting will be kdelibs: kcert, kio/kssl and kdebase: kcontrol/crypto. Whoever decides to actually attempt rewriting them with gnu tls might want to contact upstream beforehand though. Also post on debian-kde mailing list if you decide to work on it since there are several people who may wish to help you with it. Thanks, Chris
Re: [Debian-Lex] Interview with subproject leader
On Sun 27 April 2003 13:54, Jeremy Malcolm wrote: [Most of the discussion on the Debian-Lex proto-subproject has been off-list, so I'm sending this one to the list so that people can see something of our progress. These answers will be made into an article by Matt Black at some point after we get an official list and Web area.] If anybody missed Jeremy's original post about debian-lex (debian for lawyers), it is here: http://lists.debian.org/debian-devel-0304/msg01285.html I think it's a good idea to get some 'media' coverage of the project in forums where interested parties might be lurking. I know debian-lex is in its infancy, but I think that one way to help things move along is to expose the idea to tech-savvy potential users. I know there are some lawyers around the Debian lists, but there are probably numerous computer-minded lawyers who aren't. With such a specialisation aimed at lawyers, it is probably important to get as much input from potential users (ie lawyers, law firms) as possible I know that this isn't the most important part of any project, but it's what I can do at the moment, so hopefully it will be of some help. I have at least one (non-linux) news site in mind where a story about Debian-Lex might be welcome. Maybe others have ideas about good places to get Lex some coverage? I'll at least wait until Jeremy gets a subproject page set up at http://www.debian.org/devel/ and makes an 'official' announcement before proceeding with 'marketing' Lex, but I definitely think it is worth marketing. Once the project has more of a 'product' to offer, I'm sure there would be many law societies/bar associations interested in it as well. Matt
Bug#190922: ITP: gnome-randr-applet -- Simple gnome-panel front end to the xrandr extension
Package: wnpp Version: unavailable; reported 2003-04-27 Severity: wishlist * Package name: gnome-randr-applet Version : 0.2 Upstream Author : Matthew Allum [EMAIL PROTECTED] * URL : http://handhelds.org/~mallum/downloadables/grandr_applet-0.2.tar.gz * License : GPL Description : Simple gnome-panel front end to the xrandr extension Gnome-randr-applet is a simple gnome-panel front end to the xrandr extension found in XFree86 4.3+ releases. Notice that i had already packaged this and uploaded it to the NEW queue, but it was rejected, since it has a dependency on X 4.3.0, which is not (yet) in the archive. I also have a question about the package name, upstream is grandr-applet, but other similar packages are called hardware-monitor and gnome-sensors, so i thought that the grandr should be changed to gnome-randr. But does it make sense to guard the applet bit ? I think i really should ask on debian-gtk-gnome. And should hardware-monitor better be called gnome-hardware-monitor-applet ? -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux iliana 2.4.21-pre5 #1 SMP dim mar 30 10:51:33 CEST 2003 i686 Locale: LANG=fr_FR.ISO-8859-1, LC_CTYPE=fr_FR.ISO-8859-1
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:28:53PM -0500, Gunnar Wolf wrote: For practical purposes, yes... Although emulated FP is really, REALLY slow. I installed a machine to be a X terminal about two years ago - 386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a similarly-configured machine with a hardware FP unit, to the point of deciding it would be a text terminal, with no X :) 386DX didn't have the copro either. You needed a '387. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: dpkg conffiles merging - request for status summary
Jarno Elonen [EMAIL PROTECTED] wrote: Just to bring the uninitiated like me up to date about ways to upgrade changed dpkg conffiles, I would greatly appreciate if someone with insight could summarize the current status: [...] + Are there some specific reasons why dpkg doesn't offer merge interactively in addition to keep old, install new, show diff and shell when upgrading a package with changed conffiles or is it just a feature that nobody has tried to implement yet? + Does dpkg currently save the original conffiles somewhere to make 3-way merging possible? [...] Afaik the original conffile is not available, dpkg just has the md5sum of it in /var/lib/dpkg/status. I doubt that two-way-merging is _very_ useful. cu andreas
Re: dpkg conffiles merging - request for status summary
Afaik the original conffile is not available, dpkg just has the md5sum of it in /var/lib/dpkg/status. I doubt that two-way-merging is _very_ useful. Well, you can now try for yourself. :-) http://elonen.iki.fi/code/dpkg-merge/ - Jarno
Re: experimental conffile merge for dpkg
On Sun, Apr 27, 2003 at 03:40:33AM +0300, Jarno Elonen wrote: http://elonen.iki.fi/code/dpkg-merge/ contains the patched dpkg and a new interactive python curses based two-way merge tool called imediff2 (+ 3 screenshots for the impatient). Why two-way merge instead of three-way? The problem with the traditional two way merge is that it is impossible to distinguish what changes have been made locally vs what changes have been made upstream. So I am often left wondering: Is this an important change I made? Or is this a critical change upstream made? Typically, when resolving conflicts in conffiles while updating packages, I would like to do one of the following (depending on where the most changes are) manually or semi-automatically: 1. get the diff of all local changes, and apply them to the new upstream version. This would be idea if few local changes have been made, and would work (manually at least) even if large changes have been made to the upstream. 2. get the diff of all upstream changes, and apply then to the local version. This would be best of the local version has big changes, but the upstream version doesn't change much. Unfortunately neither is currently possible at the moment, simply because dpkg doesn't save a copy of the last installed config file anywhere. (Note: I use upstream here to mean either the upstream author or the Debian package maintainer). -- Brian May [EMAIL PROTECTED]
Re: Time to package simpleinit?
Hi Henrique, It is good to see that there is actually work done on it. Obviously you are more into the topic (and you are a debian developer), so It's up to me to offer you help with that, not the other way around :-) After reading through your paper (nice work), it looks to me as if the the simpleinit's and similar scheme's advantage is only the way the startup scripts, while /sbin/init does much more (SIGPWR, reexecuting itselfe, spawning login programs). It would be bad if the user that wants to use simpleinit or minit had to do without the advanced sysvinit functionality. So the right place (it seems to be) to implement the init scripts handling would be /etc/init.d/rc and make our minit or simpleinit packages compatible with sysvinit. Would that be possible? Would we reimplement it in /bin/bash, or strip down the non-init-script-handling-functionality of minit/simpleinit? How will the communication between /sbin/init and the simpleinit/minit work? Or won't that scheme work? While the simpleinit approach works well with you proposal in Section 5.4.1, how would that work with minit? If the maintainer scripts register the dependencies using update-rc, then there is a duplicity (information to update-rc and /sbin/init-* scripts called in the /etc/init.d/-scripts). Joachim aka nomeata Am Sam, 2003-04-26 um 22.28 schrieb Henrique de Moraes Holschuh: On Sat, 26 Apr 2003, Joachim Breitner wrote: * The /etc/init.d/ scripts would need to add need otherscript (and sometimes provide something). As I think it is a very bad idea to edit these scripts in our post-install (and try to reedit them in pre-remove)) one would have to file bugs agains packages with /etc/init.d scripts. Will that be sucessfull? How cooperative will the maintainers of these script be? Very, as long as it is done in a serious, generic way. I am willing to help you on this. But first, please read http://people.debian.org/~hmh/debconf2/debconf2-initscripts-bkg.pdf We have a lot of work ahead of us. I took a halt on it because I lacked the time, but now that Miquel surfaced again and did the sysv split, we could continue designing the system. I figure sysvinit and friends will have stabilized again in a more change-init-system-friendly way by the time we finish... Once it is designed (a way to properly support the dynamic dependencies such as need and provide of simpleinit), we can start deploying it. -- Joachim Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
thanks again i d7ez5e2pvzjp
Erase your email record here.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:05:50PM -0500, Gunnar Wolf wrote: I agree, the vast majority of our users can afford newer machines. So, I think we should drop m68k, mips and other similar unfashionable old archs, don't you think? The majority of our users will be happy... I'm not sure where the misconception of mips being an old arch comes from. Just look at the au1500 or the R1x000 CPUs. What are criteria for an architecture being old and unfashionable? Regards, -- Guido
subscribe
subscribe
Re: experimental conffile merge for dpkg
Why two-way merge instead of three-way? Because of... Unfortunately neither is currently possible at the moment, simply because dpkg doesn't save a copy of the last installed config file anywhere. ...this. I thought it would make big difference to have even 2-way merging now instead of none at all, and that there really ought to be a more intuitive tool for the job than sdiff. So actually, imediff2 was my main goal and dpkg was just the main motivation for making it. If we can agree wether or not, how and where the original conffiles should be saved, I'll be happy to implement 3-way merging to dpkg and write imediff3 as a user friendly UI for it. Opinions? - Jarno
Re: experimental conffile merge for dpkg
Jarno Elonen (2003-04-27 14:16:02 +0300) : If we can agree wether or not, how and where the original conffiles should be saved, I'll be happy to implement 3-way merging to dpkg and write imediff3 as a user friendly UI for it. Opinions? Unrelated to this diff thing, it's going to be a big help for people who inadvertantly remove conffiles and can't restore them (or even defaults) even with apt-get --reinstall install package. There might be things to think about though: some packages have lots of conffiles, and that could mean some extra disk space, which not everyone will want to spend. Maybe make it optional. Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- wiggy in #debian-devel
Re: Bug#190922: ITP: gnome-randr-applet -- Simple gnome-panel front end to the xrandr extension
On Sun, 2003-04-27 at 08:18, Sven Luther wrote: Package: wnpp Version: unavailable; reported 2003-04-27 Severity: wishlist * Package name: gnome-randr-applet Version : 0.2 Upstream Author : Matthew Allum [EMAIL PROTECTED] * URL : http://handhelds.org/~mallum/downloadables/grandr_applet-0.2.tar.gz * License : GPL Description : Simple gnome-panel front end to the xrandr extension Gnome-randr-applet is a simple gnome-panel front end to the xrandr extension found in XFree86 4.3+ releases. Notice that i had already packaged this and uploaded it to the NEW queue, but it was rejected, since it has a dependency on X 4.3.0, which is not (yet) in the archive. I also have a question about the package name, upstream is grandr-applet, but other similar packages are called hardware-monitor and gnome-sensors, so i thought that the grandr should be changed to gnome-randr. But does it make sense to guard the applet bit ? I think i really should ask on debian-gtk-gnome. And should hardware-monitor better be called gnome-hardware-monitor-applet ? Personally i think your choice of name is excellent. Prepending the gnome- is pretty helpful as is appending the -applet. Although i think you should explain what it does directly in the description; Simple gnome applet to change display settings (resolution, etc) And then include further explanation of everything it can do with XRandr in the description. I think you might be right about the naming of hardware-monitor, it is a very generic name. Cheers, Rob -- Rob 'robster' Bradford Founder: http://www.debianplanet.org/ Developer: http://www.debian.org/ Monkey with keyboard: http://www.robster.org.uk/
Re: experimental conffile merge for dpkg
There might be things to think about though: some packages have lots of conffiles, and that could mean some extra disk space, which not everyone will want to spend. Maybe make it optional. Bzipping could help, and maybe even tarring them all to one file. As a quick test, I bzip-tarred my entire /etc. The resulting file was merely 1.4MB even though there are about 1300 'ii' or 'rc' packages on my system. - Jarno
Re: Who b0rked my Ghostscript and fonts?
On Wed, 23 Apr 2003, +20:27:07 EEST (UTC +0300), Michael Fedrowitz [EMAIL PROTECTED] pressed some keys: On Wed, Apr 23, 2003 at 12:02:00PM +0300, Juhapekka Tolvanen wrote: FontPath/usr/share/fonts/truetype/freefont FontPath/usr/share/fonts/truetype/ttf-bitstream-vera FontPath/usr/share/fonts/truetype/dustin FontPath/usr/share/fonts/truetype/openoffice FontPath/usr/share/fonts/truetype/thryomanes Don't do this. Install x-ttcidfont-conf and add /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType to your font paths instead. (Which almost every font package's README.Debian tells you to do, btw.) That package is installed from unstable, but a directory called /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType do not exist. I deinstalled that package it with dpkg --purge --force-depends and then reinstalled it and that helped. Weird... But my GhostScript is still b0rken. -- Juhapekka naula Tolvanen * * http colon slash slash iki dot fi slash juhtolv Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Cicero
fwctl and ipchains-perl - any takers?
Hello, (this mail is send to the debian developers and to francis, the upstream author) Martin, while maintaining the archive, contacted me, because he wanted to remove the orpahaned ipchains-perl module. He noticed, that my fwctl is depending on it. Personally I love fwctl and use it on some old stable servers, but I agree with him that it makes not much sence to maintain the package any longer. So here is my question, is anybody willing to take over fwctl/ipchains-perl and add iptables support, or has anybody some ideas what to do? My perl is a bit rusty, so the started project to migrate it ti iptables was stopped since I had not much enough time. I also maintain the required libnetwork-ipv4addr-perl which will be orphaned if nobody else contacts me on that, too. upstream: http://indev.insu.com/Fwctl/fwctl.html bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fwctl Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: i386 compatibility libstdc++
On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. There are many uses for Debian other than your GNOME or KDE desktop. signature.asc Description: This is a digitally signed message part
Re: i386 compatibility libstdc++
On Sat, 2003-04-26 at 12:15, Steve Langasek wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Your non-sustainable Western consumerism is showing. rant Actually, for most of those old 486's, replacing them with new 486's would be much more sustainable, due to the lessened power draw. /rant Of course, the rest of your post stands. signature.asc Description: This is a digitally signed message part
Re: [Debian-Lex] Interview with subproject leader
On Sun, 2003-04-27 at 01:37, Matt Black wrote: I think it's a good idea to get some 'media' coverage of the project in forums where interested parties might be lurking. I know debian-lex is in its infancy, but I think that one way to help things move along is to expose the idea to tech-savvy potential users. I know there are some lawyers around the Debian lists, but there are probably numerous computer-minded lawyers who aren't. There are, iirc, 3 - 4 key email lists used many tech-savvy attorneys. One thing is for certain, if attorneys like a product, they'll push it and talk about it loudly. So, while I agree with you on the 'media' coverage, if done correctly, much of the coverage will handle itself. IMO, Jeremy has done an excellent job identifying the initial packages. I'm sure there are others, but what he's pieced together will solve almost 100% of an attorney's day-to-day requirements. -- steve ___ | | | There's a difference between being grumpy and | | hating every little fucker in existence. | | | | http://monticello.biz : technology that works | | http://exitwound.org : hard to find | | http://buckowensfan.com : he's the man | --- signature.asc Description: This is a digitally signed message part
Bug#190971: ITP: libsdl-sound1.2 -- Decodes several sound file formats including wav and mp3
Package: wnpp Version: unavailable; reported 2003-04-27 Severity: wishlist * Package name: libsdl-sound1.2 Version : 1.0.0 Upstream Author : Ryan Gordon [EMAIL PROTECTED] * URL : http://icculus.org/SDL_sound/ * License : GPL Description : Decodes several sound file formats including wav and mp3 This library is meant to make the programmer's sound playback tasks simpler. The programmer gives SDL_sound a filename, or feeds it data directly from one of many sources, and then reads the decoded waveform data back at her leisure. If resource constraints are a concern, SDL_sound can process sound data in programmer-specified blocks. Alternately, SDL_sound can decode a whole sound file and hand back a single pointer to the whole waveform. SDL_sound can also handle sample rate, audio format, and channel conversion on-the-fly and behind-the-scenes, if the programmer desires. I am packaging this out of necessity, since I am adopting gltron, and since version 0.62, gltron depends on SDL_sound. Ben Armstrong [EMAIL PROTECTED] -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux sanctuary 2.4.20sanctuary.3.3 #1 Sat Dec 21 22:56:44 AST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: Samsung ML-1210 + Gimp-print
n Fri, Apr 25, 2003 at 07:13:03PM +, Martin Wheeler wrote: Has anyone solved the problem of getting a Samsung ML-1210 to print (over USB cable connection) using CUPS and Gimp-print? (Foomatic, actually.) ... I have no printing problems whatsoever now (that I know of, anyway), _except_ for printing from gimp (always worked beautifully with my other printers in the past). Dear Martin, Try changing the printing command to lpr -Pprinter instead of gimp-print's default of lp -s -dprinter -oraw. That's how I managed to get my Lexmark E210 (same gs engine: gdi) to print from The Gimp 1.3 under CUPS. Foomatic doesn't seem to like raw input in this case. Hope this helps. Yours sincerely, Andrew Netsnipe Lau -- --- * Andrew Netsnipe Lau Computer Science Student Rep, UNSW * * # apt-get into it Debian GNU/Linux Package Maintainer * * netsnipe(+)debianplanet.org\0 alau(+)cse.unsw.edu.au\0 * * GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1 9F4A 9B24 C07D 2E8B 68BD * --- pgpDIx2WVqkF4.pgp Description: PGP signature
Bug#190977: ITP: kq -- an adventure game in the spirit of Final Fantasy
Package: wnpp Version: unavailable; reported 2003-04-27 Severity: wishlist * Package name: kq Version : 0.98+cvs.20030129 Upstream Author : Josh Bolduc [EMAIL PROTECTED] * URL : http://kqlives.sourceforge.net/ * License : GPL v2 Description : an adventure game in the spirit of Final Fantasy KQ is an adventure game in the spirit of old console games such as Secret of Mana, Final Fantasy or Zelda. Choose your player amongst the eight different adventurers, visit towns, buy weapons and equipment, learn magic, slash monsters, and maybe you will eventually find the magical Staff of Xenarum! -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.5.53 #2 Thu Apr 24 01:24:46 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: Bug#190922: ITP: gnome-randr-applet -- Simple gnome-panel front end to the xrandr extension
On Sun, Apr 27, 2003 at 01:10:57PM +0100, Rob Bradford wrote: On Sun, 2003-04-27 at 08:18, Sven Luther wrote: Package: wnpp Version: unavailable; reported 2003-04-27 Severity: wishlist * Package name: gnome-randr-applet Version : 0.2 Upstream Author : Matthew Allum [EMAIL PROTECTED] * URL : http://handhelds.org/~mallum/downloadables/grandr_applet-0.2.tar.gz * License : GPL Description : Simple gnome-panel front end to the xrandr extension Gnome-randr-applet is a simple gnome-panel front end to the xrandr extension found in XFree86 4.3+ releases. Notice that i had already packaged this and uploaded it to the NEW queue, but it was rejected, since it has a dependency on X 4.3.0, which is not (yet) in the archive. I also have a question about the package name, upstream is grandr-applet, but other similar packages are called hardware-monitor and gnome-sensors, so i thought that the grandr should be changed to gnome-randr. But does it make sense to guard the applet bit ? I think i really should ask on debian-gtk-gnome. And should hardware-monitor better be called gnome-hardware-monitor-applet ? Personally i think your choice of name is excellent. Prepending the gnome- is pretty helpful as is appending the -applet. Although i think :))) you should explain what it does directly in the description; Simple gnome applet to change display settings (resolution, etc) And then include further explanation of everything it can do with XRandr Ok, you are right there and i will change this before i do the actual upload, which i cannot do before 4.3.0 is in the archive anyway. in the description. I think you might be right about the naming of hardware-monitor, it is a very generic name. Yes, but gnome-hardware-monitor-applet is pretty long which may cause trouble dpkg -l and some other package management tools, and hardware-monitor is the upstream name. I will let it like this for now (it is already in sid and sarge), until there is a agreement on what exactly to do here. Friendly, Sven Luther
Re: i386 compatibility libstdc++
On Saturday 26 April 2003 05:08, Chris Cheney wrote: On Sat, Apr 26, 2003 at 09:36:56AM +0800, Cameron Patrick wrote: What about the Via C3? That was introduced not too long ago, runs moderately quickly (~1GHz) with low power consumption, but IIRC doesn't support the i686 instruction set. The issue with this appears to be a gcc bug with respect to compiling for i686: http://marc.theaimsgroup.com/?l=linux-kernelm=104263370505476w=2 Considering cmov optional for i686 seems odd. The only major new operand added from i586-i686 was cmov. In most cases using cmov is a HUGE win because you avoid branching. Even as a owner of a C3 cpu, I would leave C3 on the other side of the fence, slowing down 99% of Athlon/PII users for the sake of 1% of C3 users doesn't make sense.
Re: pilot-link in Sid and Sarge: Much bigger question
Matthew Palmer wrote: it's labour-intensive, it's pretty damn effective. ^ And there's why it doesn't work for Debian. We don't have money to throw at our developers. I never claimed we should. I merely explained one of the many reasons Debian is fundamentally slower than other distributions. I also, as you prominently underlined, explained why this solution is not an option for Debian. Face the facts: Debian Is Different. No amount of complaining about it will change that. So Debian is perfect? No need to discuss problems and possible solutions? Maybe we should close the bug tracker too. It's telling that pointing out a problem is automatically defined as complaining. What is this, a sect? I though this was the developer list. You're targetting a different audience than Debian is, so that's probably a good way to scratch your itch. Right, then please define the Debian target audience for me. To end up in the current state, the list would have to look something like: 1) Developers (who can run unstable) 2) Server admins (who don't need new software) Is this really what you want? Because then we (or, in that case, you) should post it in big not-so-friendly letters on the front page so the rest of the world, including developers, can make an informed choice. And? Debian appears to have chosen High Quality over Bleeding Edge. Actually, Debian has chosen Portability over Quality. Quality means a lot more than just fixing bugs, you know. A program that does not work with current data or devices has low quality even if it doesn't crash. The mere age of most packages in stable is a very serious quality flaw. And no, before you build that straw man, I'm not saying Debian should contain more bugs. I'm saying we need to rethink the system, because today we don't even let the bug fixes in! If you don't like that choice, you can choose to use something different, or roll your own. How about improving Debian? Or is that heresy? I'd install Debian across the board if a Linux solution was called for, because it's a stable, reliable, functional platform, which is *exactly* what what companies need. That is correct, but not complete. Companies also need software to do their day-to-day work. Software such as cross-platform word processors, spreadsheets and browsers that can actually show their client's home pages. Debian does not offer this. Yet not one of you will admit that this is a problem. Eye candy comes a distinct 20th (or lower). I've worked in places which are still using greenscreens, because stability, reliability, a known UI, and a lack of distraction, is far more important than the latest whizz-bang shiny! hey look my monitor's melting GUI. It is more than a little arrogant to claim all the changes since woody is just eye candy... I might as well say this too, to head off your assumptions: I am a developer. I run unstable. I don't want to run testing. This is not a personal gimme issue, I already have everything I want. But this issue, this system flaw, lowers the overall appeal of Debian. I like Debian. I like the voluntary nature and the Free Software ideals behind it. I like apt. I've been planning to contribute in various ways. But if the general consensus among debian developers is that 90% of the computer-using public is too stupid to care about, I don't think I'll bother. Heck, I've got what I want, why should I care about the rest of the world? Right? The social contract says We will be guided by the needs of our users. I guess it all comes down to the definition of our users. -- Björn
Hey - Please read! yaey4mzvr
Don't want any more adverts? Simply click here.
Bug#190994: ITP: quat -- quat: a 3D quaternionic fractal generator
Package: wnpp Version: N/A; reported 2003-04-27 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: quat Version : 1.20 Upstream Author : Dirk Meyer [EMAIL PROTECTED] * URL : http://www.physcip.uni-stuttgart.de/phy11733/index_e.html * License : GPL Description : quat: a 3D quaternionic fractal generator Quat draws 3D slices from 4-dimensional quatern fractals. These are different from what are normally called three-dimensional fractals, which are merely a reinterpretation of two-dimensional data. Quat has many parameters for coloring, drawing functions, defining intersection planes, and more. It can work in both the console and with X. The console version will save the fractal to a PNG file, and the X version will also display on screen a version (typically of worse quality) of the image being drawn to the PNG file. - -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux surgo 2.4.20rc4 #1 Wed Mar 5 20:50:15 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQEVAwUBPqw2hw+aqp0pfOpbAQL51AgAmWNof/mVYAqNsyz8ke3EkmLRC7CN3i0T LhqEMZTskwL3+RDZV539HUPsyxiXXvuDM5cxHMmil77WXPlhlzaPLSGs2ZGmIdc0 FfzKwfhf3k3DD4VxvLmPUKdHE4lzf9as7AOFEIvCyrkHinDU/wjo1UkxzjC1QeVq yuDFKiBqeQtlsIjzSwoD6J7EwOoMJcf/8glBLDyA6P3BvleU9ZOiTAb9QyrJRkzq hORxrILZxfFluAnXjCzkwZj0rYDH9Cces+0JBNGu25utABu/UQ9S7OVoiV4k70Jh 9nR23x6kmgW+fId2V3AC57AFSnKizeYBF+P3Qf5U/iu10ujzNMRvxg== =58zh -END PGP SIGNATURE-
Re: pilot-link in Sid and Sarge: Much bigger question
Björn Stenberg (2003-04-27 21:17:04 +0200) : [...] Actually, Debian has chosen Portability over Quality. Quality means a lot more than just fixing bugs, you know. A program that does not work with current data or devices has low quality even if it doesn't crash. The mere age of most packages in stable is a very serious quality flaw. [...] How about improving Debian? Or is that heresy? To me, you seem to express the view that improving Debian means throwing away our release process, including the way testing works. This process has been thought about for a long time by lots of people, and carefully crafted to match some goals. I happen to believe the goals are worthy, and the process is adapted to these goals. I was only a prospective or recent developer when testing was brought to life, but I do not remember much opposition to it when it was designed, presented, discussed, then implemented. And it seems to me that the goals are correctly fulfilled by the process. From that, I infer that either 1. you disagree with the goals that the release process aims at fulfilling, 2. you disagree that the process is good at its job for structural reasons, or 3. you believe the process does not work as expected for other reasons. In case 1, I suggest you bring up a discussion on debian-project, so that the goals for the next release and the more general goals of releases (in terms of what it means to release a new stable distribution) can be discussed to death, and we eventually come up with maybe a different set of targets for the release process. In case 2, I suggest you express your concerns about how the release process is not adapted to what we want to achieve, and supply helpful ideas to make it better. In case 3, please help us identify the reasons why the process does not give the expected results. Also, please provide help to fix those problems. *Supposing* I were agreeing with you on the existence of a problem, I would probably be of the opinion classified as case 3 above. The reason I could identify for the problem would be that people prefer bitching and complaining about testing being late and stable being old, rather than helping fixing bugs. I agree with the goals. I believe the testing process is appropriate. The problem is not that this process requires software to be tested and declared relatively bug-free before they are admitted into testing. The problem is that the software is not even remotely bug-free. And it is so at least partly because people try to put new versions of software into Debian, which means the system integration and the synchronisation of programs and libraries are an uphill battle. And it is so at least partly because people complain as soon as there's a new upstream release, thus delaying the testing of the whole system. There's no such thing as a known-good program. You have to have a known-good *system*. Taking the last known-good version of each part of the system, putting all that together and hoping the whole system will work is, to say the least, idealistic. Roland. -- Roland Mas Just a little bit of you every day will surely keep the doctors away. -- Just a little bit of you (The Jackson Five)
Re: i386 compatibility libstdc++
Anthony DeRobertis [EMAIL PROTECTED] wrote: [...] rant Actually, for most of those old 486's, replacing them with new 486's would be much more sustainable, due to the lessened power draw. /rant Since manufacturing computers takes _very_ much energy I doubt that. cu andreas
Dropping/splitting (proper) i386 support
This is an attempt to summarize some points. 1. Why do we have a problem, other than performance issues? * To maintain binary compatibility with other distributions for C++ packages, Debian needs to use the i486+ version of atomicity.h supplied by GCC. * This version is significantly faster than the i386 version. * GCC 3.2 doesn't even supply a working i386 version (GCC 3.3 does). * This is exposed ABI (currently) and therefore cannot be solved by multilibbing. 2. What performance benefits do we get as side effects of dropping 386? * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.). http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.html Not sure if there's anyone programming to the data bus. :-) * i486 has a cache, and accordingly an 'invalidate cache' instruction. * i486 has an 'invalidate TLB entry' instruction (INVLPG). 386 requires the flushing of the entire page table. * i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly others -- I haven't found a complete list). * OpenSSL is *much* faster on i486+ than on i386. The improvements for going to i586, i686, etc. are not that great. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html * The kernel is markedly faster compiled for i486+ than on i386. Again, the improvements for subsequent chips are not as impressive. This is at least partly *not* a tuning issue; for 386, the kernel needs extra code whenever it writes to user pages (http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0445.html), has to clear the whole page table rather than using INVLPG, and uses less efficient options rather than CMPXCHG,XADD, and BSWAP in heavily-used code paths (including read-write semaphores). Other instances I've seen show a really sharp performance improvement with i486-specific code rather than i386-specific code, and declining benefits for each subsequent model. I'm not sure how much is tuning and how much is architecture-specific, of course. Oddly, it looks like GCC doesn't currently ever generate 486-specific instructions; they are only (currently) of benefit to assembly programmers. (Hmm... maybe I should see if there's an enhancement opportunity to GCC there.) 3. How much impact will this have on users? * Two people have reported live 386 systems (not clear if they're using Debian): Being used for ISDN logger and for DNS server: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01915.html Being used for ADSL firewall: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01918.html * Lots of people have reported live 486 systems using Debian. * 486s are still being sold. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02099.html * Supposedly, i386 was never as popular as i486. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02014.html This matches my recollection that until the 486 came out, software was generally targeted at the 286 (IBM AT). 4. Conclusion. The i386 support is marginal, there are very few users of it, and it's significantly impeding the rest of the distribution. There are several ways to deal with this. * Split into a full 'i386' architecture and a full 'i486' architecture. Causes massive wasteful archive bloat... unless someone enhances the architecture system, so that binary packages can identify themselves as being the same for 386 and 486 (or different and incompatible with ABI breakage...), and so that source packages can identify themselves as building in the appropriate manner, and so that dependencies are handled correctly,... This is quite difficult and seems unlikely to happen in the near future, if ever. * Drop i386 support entirely; 'i386' architecture becomes 'i486'. The most dramatic option. * Drop i386 support mostly. 'i386' architecture becomes 'i486'. Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture, but don't require that any packages build on it in order to go into testing or to release Debian; it would be a bonus architecture, with a limited number of packages avaiable. This seems to be the most immediately feasible option. Several people have already indicated their approval of this idea. I wouldn't wait for sarge to release, but do it ASAP. (Since C++ is already semi-broken on 386s, this would likely make things better for i386 in fact; at least it would have a specific functioning project.) This is assuming someone with a real i386 is willing to lead a 'Debian-real-i386' project (which wouldn't be a huge amount of work, really; upstream support is usually pretty good, you don't have to actually compile packages on your slow 386, just test them there, and you don't have to worry about ABI compatibility with anyone much). If nobody is willing then I'd say there just isn't enough support and 386 should be dropped outright. --Nathanael
Kernel 2.5
Hi all I've configured and built the kernel, using gcc-2.95, make bzImage and modules, installed modules under /lib/modules/2.5.68. Everything goes fine except for a bunch of depmod errors during the 'make modules_install' which I'm guessing is because the new modules don't match the running kernel. I've updated grub to point to the kernel. When booting, grub seems to find it, uncompress it, then it says 'OK, booting the kernel' and nothing more. It just hangs. I don't see the line announcing the kernel version or compiler etc. Any tips or pointers? I've tried to be quite conservative with the config... no preempt, no smp, and the basic stuff as builtin rather than modules. Any ideas? -- 'Try to relax and ENJOY the crisis.' - Ashleigh Brilliant
Re: Dropping/splitting (proper) i386 support
Nathanael Nerode [EMAIL PROTECTED] writes: Oddly, it looks like GCC doesn't currently ever generate 486-specific instructions; they are only (currently) of benefit to assembly programmers. (Hmm... maybe I should see if there's an enhancement opportunity to GCC there.) I have a patch floating around here that adds a __builtin_bswap32/64, which could generate bswap on i486, if anybody is interested. I was planning to recognize bswaps from C Code too, but I'm not sure that will work out... I think it would be quite useful, though, since byte swapping often occurs in performance-critical code like emulators. -- Falk
Re: Kernel 2.5
On Sun, Apr 27, 2003 at 21:37:06 +0100, Mark Shuttleworth wrote: I've configured and built the kernel, using gcc-2.95, I've not followed 2.5 development, but I'd suspect the recommended compiler for building it ought to be gcc 3.2 or 3.3 rather than 2.95 by now - check the documentation carefully and try if switching to a new compiler for your kernel build helps. HTH, Ray -- [...] you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company. Jamie Zawinski in http://www.jwz.org/gruntle/nomo.html
Re: Dropping/splitting (proper) i386 support
Hi Nathanael! You wrote: * Drop i386 support mostly. 'i386' architecture becomes 'i486'. Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture, but don't require that any packages build on it in order to go into testing or to release Debian; it would be a bonus architecture, with a limited number of packages avaiable. Sounds reasonable. I'd rather not drop i386 at all, but I guess something needs to be done. BTW: do you have any quantative numbers on the i386/i486 performance issues (e.g. for openssl)? -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: Samsung ML-1210 + Gimp-print
On Mon, 28 Apr 2003, Andrew Lau wrote: Try changing the printing command to lpr -Pprinter instead of gimp-print's default of lp -s -dprinter -oraw. Thanks Andrew -- that worked a treat! Funny though -- I know had already tried 'lpr -P printer' note space; can't remember whether I blew away the raw option with it, though. And now having seen the time it takes the printer to react to some of the sample print files I was sending it, I wonder whether I was waiting long enough before assuming that it hadn't worked. Anyway -- all now works beautifully. My next task will be to find out how to get QCad to accept a printer ... -- Martin Wheeler - StarTEXT / AVALONIX - Glastonbury - BA6 9PH - England [EMAIL PROTECTED] http://startext.demon.co.uk/ GPG pub key : 8D6B948B ECC6 D98E 4CC8 60E3 7E32 D594 BB27 3368 8D6B 948B - Share your knowledge. It's a way of achieving immortality. -
Re: /run/, resolvconf and read-only root
Hi. I noticed that in order to implement your read-only root proposal, you propose to modify the pam package. I'm not really sure I see the justification for read-only /. I can see several possible justifications and some of the possible goals conflict. Until you get general consensus on a specific goal, I'm unlikely to accept such changes if they are submitted to me. As a maintainer I want to be able to look at some statement and answer the following questions: 1) Why are people mounting root read-only? 2) When root is read-only, what information is variable and what information should be immutable? Why is this a reasonable categorization? 3) What information needs to go in /var vs /run? This message not withstanding, I will follow any related changes to policy to the best of my ability.
Re: i386 compatibility libstdc++
Matthew Palmer [EMAIL PROTECTED] writes: On 26 Apr 2003, Josselin Mouette wrote: Le sam 26/04/2003 à 02:59, Matthew Palmer a écrit : For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? That would not be enough. We need specific versions of C++ applications for 386. Of course, only a few should be enough : python, apt, groff... but that is far from an empty list. That's why dropping i386 completely and provide an i386 subset of the distribution seems reasonable. Whoops, of course. so we'd have ftp.debian.org/ woody main 386only then? Dunno if the autobuilders could handle it, but it'd be one way around it... Couldn't this be solved by using Marcus Brinkmann's architectures-as-dependencies plan? Would this not allow to have several packages, each targetted for different processors? -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: Kernel 2.5
Turn on virtual terminal support... Chris
Re: Time to package simpleinit?
One big problem about Richard Gooch's simpleinit is that it is functionally very different from the standard systme V init scripts. Specifically, he always assumes that runlevel n+1 is always a superset of runlevel n, and that in order to get to runlevel n+1, you must first start up all of the services at runlevel n. Runlevel 6 has been used for reboot since time immemorial, and in fact is documented in Debian Policy as such. Simpleinit can't support this. * The /etc/init.d/ scripts would need to add need otherscript (and sometimes provide something). As I think it is a very bad idea to edit these scripts in our post-install (and try to reedit them in pre-remove)) one would have to file bugs agains packages with /etc/init.d scripts. Will that be sucessfull? How cooperative will the maintainers of these script be? And just adding need otherscript and provide otherscript will break compatibility on systems that don't use simpleinit, unless the system V initscript package is enhanced to provide no-op functions which provide need and provide. * Is there even interest in simpleinit by others than me? I would also need someone to ask if I have problems with sysvinit or similar, and I would like to know who thinks he is capable of helping me? Are there people that might help me when it comes to file bug against packages with /etc/init.d scripts? Simpleinit is unfortunately completely incompatible with System V init. So at the very least, Debian Policy would have to be amended to support simpleinit, and I'm not really convinced it's really worth it for Debian to support two fundamentally different init script systems. Not only are the init scripts different, but the interface which is exported to the system administrator, and what can and can't be implemented using simpleinit, is completely different. For this reason, I consider simpleinit to be a failure and a mistake. With a little bit more work, for example, the traditional system V runlevels could be implemented, and the dependencies could have been implemented in a structured comment block, for full backwards compatibility. I've been told that SuSE's init scripts system does this, while also providing full automatic dynamic dependency management, ala simpleinit. I haven't had a chance to look at it, but everything I've heard about it makes it sound far better than simpleinit. - Ted
Re: Kernel 2.5
On Sun, Apr 27, 2003 at 09:37:06PM +0100, Mark Shuttleworth wrote: When booting, grub seems to find it, uncompress it, then it says 'OK, booting the kernel' and nothing more. It just hangs. I don't see the line announcing the kernel version or compiler etc. CONFIG_VGA_CONSOLE=y Milan
Re: i386 compatibility libstdc++
At 12:52 27/04/2003 -0400, you wrote: On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Hey! Where did you get that from? I'd love to have one of those ( specially if they came in a 19 1U form factor or similar !!! ) There are many uses for Debian other than your GNOME or KDE desktop. Surely. This is why i proposed keeping everything compiled for 486 or higher -- that's where the upstream split is, too ... ( we would then need just an small subset of the packages recompiled for i386's libstdc++ ABI ) J.L.
Re: Kernel 2.5
* Mark Shuttleworth [EMAIL PROTECTED] [030427 16:59]: I've configured and built the kernel, using gcc-2.95, make bzImage and modules, installed modules under /lib/modules/2.5.68. Everything goes fine except for a bunch of depmod errors during the 'make modules_install' which I'm guessing is because the new modules don't match the running kernel. I believe that you can still build with gcc-2.95. To the best of my recollection I did do that at least once... although I've been using 3.2 for the most recent builds. The new modules (*.ko) do not work with the old module utils. It may be that you just have to rebuild the kernel with the presence of these new utilities. $ apt-cache show module-init-tools Package: module-init-tools Priority: optional Section: admin Installed-Size: 292 Maintainer: Christopher L Cheney [EMAIL PROTECTED] Architecture: i386 Version: 0.9.11-1 Depends: libc6 (= 2.3.1-1) Conflicts: modutils (= 2.4.21-1) Filename: pool/main/m/module-init-tools/module-init-tools_0.9.11-1_i386.deb Size: 57682 MD5sum: 02a3792d3557590cba978d82aa40383b Description: tools for managing Linux kernel modules This package contains a set of programs for loading, inserting, and removing kernel modules for Linux (versions 2.5.48 and above). It serves the same function that the modutils package serves for Linux 2.4. B. -- WebSig: http://www.jukie.net/~bart/sig/ pgp4qj3z6w9ey.pgp Description: PGP signature
test
test sorry
Re: i386 compatibility libstdc++
On Mon, 2003-04-28 at 08:45, José Luis Tallón wrote: At 12:52 27/04/2003 -0400, you wrote: Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Hey! Where did you get that from? I'd love to have one of those ( specially if they came in a 19 1U form factor or similar !!! ) Rack mount? These sorts of things are usually about the size of a pack of playing cards, and aren't intended for use as a stand-alone machine or server: they're often used as embedded systems for industrial monitoring and control, etc. However, even at this level use of the i386 arch is diminishing rapidly, and most of the PC104 etc cards you see around the place are at least 486 or better. My company set up some industrial monitoring units a couple of years ago for a client and we used AMD chips running a very minimal Debian, because the 386 options were just way too underpowered. So speaking as someone with a vested interest in maintaining Debian support for small scale embedded systems, even I wouldn't care if i386 was dropped (at least officially - as someone else noted, running unofficial i386 sources wouldn't be too hard if anyone cared enough to do it). At this point i486 seems to be the minimal ix86 arch worth maintaining, IMHO. Cheers Jonathan
Re: Kernel 2.5
On Sun, Apr 27, 2003 at 06:45:42PM -0400, Bart Trojanowski wrote: * Mark Shuttleworth [EMAIL PROTECTED] [030427 16:59]: I've configured and built the kernel, using gcc-2.95, make bzImage and modules, installed modules under /lib/modules/2.5.68. Everything goes fine except for a bunch of depmod errors during the 'make modules_install' which I'm guessing is because the new modules don't match the running kernel. I believe that you can still build with gcc-2.95. To the best of my recollection I did do that at least once... although I've been using 3.2 for the most recent builds. Right. I compiled it with gcc-2.95.4 (woody). It works on my workstation but crashes on the armada notebook. The new modules (*.ko) do not work with the old module utils. It may be that you just have to rebuild the kernel with the presence of these new utilities. $ apt-cache show module-init-tools Yes. You are right again. This must be installed. I downloaded it from unstable and compiled on woody. It works. Milan
[grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
Hi, I am in the process of rewriting grep-dctrl. The rewrite attempts to gain speed over the old version while removing one of the greatest defects in the old code: the new grep-dctrl is able to combine searches in full boolean manner. The current version does not yet duplicate all the features of the old code, but most of the core functionality, as well as boolean queries, is implemented. In my own tests, the new code has beaten the old code speedwise in almost all situations and never lost to it. In some cases, I have seen as much as a sixfold increase in speed. I am requesting testers for the new code. Try all the stuff you are used to do with current grep-dctrl and verify that the old and the new code produce (essentially) identical output from identical inputs. Try out the new boolean search feature and try to find bugs in it. Try to find cases where the new code loses to the old code speedwise (or to the other options: dpkg. dpkg-awk, ara, maybe even apt-cache). Report your findings (both positive and negative) to me, at [EMAIL PROTECTED] Do not use the BTS for the new code yet. The following features of the old code is not yet functional: * The switches -n, -d, -c, -v, --config-file * Command name based input file location (thus, there is no grep-status or grep-available) * Multiple field names in -F (use the boolean query mechanism to get the effect) (I intend to fix this before this code goes to unstable. The new code will duplicate all the functionality of the old code, eventually.) The following new features are implemented: * Boolean queries: use -a (--and), -o (--or), ! (--not); parentheses can be used like in test or expr For example -F Section utils -a ! -FDepends -e 'gnome|kde|gtk' The new code is not yet packaged, you need to compile it out of cvs. It is in Alioth, project dctrl-tools, branch v1_rewrite: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools co \ -r v1_rewrite dctrl-tools make (The debian/ directory there is out of date, and so are the docs.) Thank you all for your attention. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgp9jIbyJ1abX.pgp Description: PGP signature
Re: Kernel 2.5
On Mon, Apr 28, 2003 at 12:40:28AM +0200, Milan P. Stanic wrote: On Sun, Apr 27, 2003 at 09:37:06PM +0100, Mark Shuttleworth wrote: When booting, grub seems to find it, uncompress it, then it says 'OK, booting the kernel' and nothing more. It just hangs. I don't see the line announcing the kernel version or compiler etc. CONFIG_VGA_CONSOLE=y Sorry. I made a mistake. It should be: CONFIG_VT_CONSOLE=y Milan
Re: [grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
On Mon, Apr 28, 2003 at 02:32:30AM +0300, Antti-Juhani Kaijanaho wrote: I am in the process of rewriting grep-dctrl. The rewrite attempts to gain speed over the old version while removing one of the greatest defects in the old code: the new grep-dctrl is able to combine searches in full boolean manner. I had toyed with the idea of rewriting grep-dctrl using sgrep macros. I haven't tried it, but I think it may be powerful enough. Did you look into this possibility? -- - mdz
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 02:23:03PM +0200, José Luis Tallón wrote: At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) - Cache ( very much needed, i mught add ) - Pipeline attempt IIRC - Mandatory 32bits Bus/Memory IMHO, since we have concluded there are almost NO true i386 around ( not even for routers ), Here is an extract of recent boot messages from one such animal: Apr 22 23:27:43 debian kernel: Linux version 2.4.18 ([EMAIL PROTECTED]) (gcc version 2.95.4 (Debian prerelease)) #1 fre mar 22 02:53:42 CET 2002 [...] Apr 22 23:27:43 debian kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=301 ether=10,0x300,eth0 ether=9,0x240,eth1 Apr 22 23:27:43 debian kernel: Console: colour VGA+ 80x25 Apr 22 23:27:43 debian kernel: Calibrating delay loop... 3.62 BogoMIPS [...] Apr 22 23:27:45 debian kernel: CPU: 386 Running Woody and acting as a router. There might be more of them than you think. A stripped down version of i386 might actually be a good thing for those of us who still uses 386 machines (with comparably small HD:s) 1a seems appropriate. -- Hans Ekbrand (http://sociologi.cjb.net) [EMAIL PROTECTED] GnuPG key: 1024D/7050614E (currently active subkey 03CE8884) Fingerprint: 1408 C8D5 1E7D 4C9C C27E 014F 7C2C 872A 7050 614E Key available at keyserver.kjsl.com Encrypted emails prefered. pgpDaLioyIySM.pgp Description: PGP signature
Re: experimental conffile merge for dpkg
On Sun, Apr 27, 2003 at 03:52:13PM +0300, Jarno Elonen wrote: There might be things to think about though: some packages have lots of conffiles, and that could mean some extra disk space, which not everyone will want to spend. Maybe make it optional. Bzipping could help, and maybe even tarring them all to one file. As a quick test, I bzip-tarred my entire /etc. The resulting file was merely 1.4MB even though there are about 1300 'ii' or 'rc' packages on my system. You don't want to have to gunzip everything though just so you can update one file... How about: /var/lib/xyz/package1.tar.gz /var/lib/xyz/package2.tar.gz ... /var/lib/xyz/package3.tar.gz So you have one tar.gz file per package. Or, if that is too many files in one directory, use the package pools naming system: /var/lib/xyz/p/package1.tar.gz /var/lib/xyz/p/package2.tar.gz ... /var/lib/xyz/p/package3.tar.gz -- Brian May [EMAIL PROTECTED]
Re: [grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
On Mon, Apr 28, 2003 at 02:32:30AM +0300, Antti-Juhani Kaijanaho wrote: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools co \ -r v1_rewrite dctrl-tools make [EMAIL PROTECTED]:~ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools co -r v1_rewrite dctrl-tools cvs [server aborted]: can't chdir(/var/lib/gforge/chroot/home/users/anoncvs_dctrl-tools): No such file or directory Gotta love Alioth. I even used my own user account on the system and it doesn't have permissions to write a cvs lockfile. Got a tarball? :( Regards, Josh -- New PGP public key: 0x27AFC3EE pgpa6Jh8vHOGr.pgp Description: PGP signature
Re: Dropping/splitting (proper) i386 support
Bas Zoetekouw [EMAIL PROTECTED] writes: BTW: do you have any quantative numbers on the i386/i486 performance issues (e.g. for openssl)? I hacked up a quick script (http://ilmari.org/sslcmp) that compares two 'openssl speed' outputs and gives you the ratio, here's the output for i386 vs i486 on a P-III Mobile: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2 1.0091.0220.9920.9941.000 md4 1.1821.0741.1521.0701.018 md5 1.3511.5962.0792.9023.443 hmac(md5) 1.3851.4991.8342.5323.318 sha11.1571.5201.5531.6071.608 rmd160 1.1721.2761.3981.4951.552 rc4 1.3871.3661.3781.3621.352 des cbc 1.9801.9611.9581.9571.991 des ede32.0572.0632.0962.0832.089 rc2 cbc 0.9960.9890.9980.9980.991 blowfish cbc1.2461.2361.2441.2481.246 cast cbc0.9810.9931.0081.0120.995 aes-128 cbc 0.9971.0151.0151.0060.999 aes-192 cbc 1.0281.0091.0101.0211.010 aes-256 cbc 1.0211.0171.0231.0161.015 signverifysign/s verify/s rsa 512 bits0.5590.6671.7721.759 rsa 1024 bits0.4950.5562.0131.900 rsa 2048 bits0.4890.5162.0561.950 rsa 4096 bits0.4960.5142.0001.944 signverifysign/s verify/s dsa 512 bits0.5330.5141.9181.991 dsa 1024 bits0.4890.4952.0262.031 dsa 2048 bits0.4950.4832.0152.071 For i486 vs i686/cmov the results are less impressive: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2 1.0421.0171.0501.0451.047 md4 1.0421.0350.9420.9720.997 md5 1.1551.1411.1001.0230.989 hmac(md5) 1.2681.2431.2061.1101.030 sha11.0321.0401.0261.0061.006 rmd160 1.0321.0141.0111.0141.011 rc4 1.0021.0010.9900.9881.003 des cbc 1.0001.0030.9951.0000.987 des ede30.9911.0060.9921.0021.001 rc2 cbc 1.0041.0081.0111.0081.011 blowfish cbc1.0010.9941.0051.0011.010 cast cbc0.9830.9910.9790.9850.995 aes-128 cbc 1.0061.0071.0131.0181.021 aes-192 cbc 1.0101.0081.0141.0001.012 aes-256 cbc 1.0061.0100.9961.0031.007 signverifysign/s verify/s rsa 512 bits1.0001.0000.9901.002 rsa 1024 bits1.0001.0000.9991.004 rsa 2048 bits0.9961.0001.0050.998 rsa 4096 bits1.0021.0000.9641.000 signverifysign/s verify/s dsa 512 bits1.0001.0001.0031.008 dsa 1024 bits1.0001.0001.0021.002 dsa 2048 bits1.0001.0280.9980.977 -- ilmari
Re: i386 compatibility libstdc++
I demand that Gunnar Wolf may or may not have uselessly CC'd to me... [snip] I thought that in-kernel emulation would have solved the gap between 486 DX and SX. For practical purposes, yes... Although emulated FP is really, REALLY slow. Is it safe to mention ARM710 in this thread? :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Hugh of Borg: Resistance is futile. I will assimilate you.
Re: pilot-link in Sid and Sarge: Much bigger question
Roland Mas wrote: *Supposing* I were agreeing with you on the existence of a problem, I would probably be of the opinion classified as case 3 above. The reason I could identify for the problem would be that people prefer bitching and complaining about testing being late and stable being old, rather than helping fixing bugs. I agree with the goals. I believe the testing process is appropriate. The problem is not that this process requires software to be tested and declared relatively bug-free before they are admitted into testing. The problem is that the software is not even remotely bug-free. Apparently the software is bug-free enough, say, in the case of KDE 3 or Gnome 2.2, for the vast majority of other Linux distributions. I'm not saying there aren't a lot of bugs in those packages, but haven't seen any real show stoppers on SuSE 8.2 or Red Hat 9. The point is that this sofware we're talking about is good enough for the vast majority of Linux users. (And I'm saying that because in most What distro do you run polls, I see the troika of RH, SuSE, and Mandrake pulling the bulk of the votes.) Is the build system in Debian better? I personally *do* think so. I started this thread so that I could understand where the project was headed, not just from a theoretical point of view (which I can get from the docs on debian.org), but from an in-the-trenches point of view. It turns out that it's the same view, but I didn't know that going in. (It was only after pestering the Red Hat list that I found out that their consumer versions are going to be more like rolling betas going forward, so I just wanted to poke this list and see what happened.) The problem with the build process -- to me -- at this point -- is that by being correct from a developer's point of view, you've made the system only acceptable for developers. Now, I'm as developer as the next guy. I program for a living. It just happens to be in Visual Studio 6 and .NET, for the most part. But I do LAMP development as well, and I program in every system I'm on. (You know the saying, Writers write?...) But there comes a point that I don't want to have to develop the system upon which I'm trying to develop. I have several LAMP site migrations and updates to do, and I'm sitting here debating the finer points of Debian's process, NOT because I want to start an argument, and NOT because I want to hack on my system to get it to do all the basic things I *need* it to do, but because I want to know if this is going to allow me to eventually settle in and do the things I really want to do without getting in my way, and yet keep up reasonably with the changing featureset of GNU/Linux at large. If that's NOT the case, then I ought to shut up and go run something else. In case 1, I suggest you bring up a discussion on debian-project, so that the goals for the next release and the more general goals of releases (in terms of what it means to release a new stable distribution) can be discussed to death, and we eventually come up with maybe a different set of targets for the release process. I can't find this on the mailing list listing page. I was sure that there was *some* group dedicated to talking about the project as a project, but I'm missing it now. I'd like to join it and get a feel for it. In the past few days of living in woody, I've already seen that I can indeed run the NVidia driver and get my video card working under XFree86 4.1, which I didn't think was possible. KDE 2.2 looks an awful lot like 3.x with the addition of the crystal icon theme. The only thing I lack at this point is the ability to backup my Tungsten, and I just downloaded the 2.4.20 patch to make that work. I haven't actually built the kernel yet, but I think it will be fairly straightforward given the surprisingly good documentation surrounding this distro. What I'm trying to say by this is that, despite how old the software is, I'm not finding a lot of things that Debian isn't able to actually *do*. I may not have the gorgeous OpenGL screensavers in xscreensaver-4.09, but on the other hand, stable is proving just that. Everything works as expected. In short, I think this is going to work for *me*, but I'm still trying to get a look into a crystal ball about the future prospects for Debian. Regards, dk
Re: Kernel 2.5 boot failure [SOLVED]
She boots! Thanks to Bart Trojanowski for much help. I'm posting this to the list in case someone else runs into the same problem trying to build kernel 2.5 on Debian unstable. The symptom was an apparently frozen screen after the message 'Uncompressing Linux... Ok, booting the kernel.' First, I needed to install module-init-tools. These are needed for the new-style kernel modules in 2.5. Then Bart suggested that it might be a problem with the console config in the kernel I was building: Bart Trojanowski wrote: You need to enable virtual terminal support CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y It may also be PTYs... CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 This nearly solved the problem. I just needed to jiggle to config a bit more. I think the extra magic incantation was another config option: CONFIG_VGA_CONSOLE=y Hope this helps someone else. Thanks Bart, Mark -- 'Try to relax and ENJOY the crisis.' - Ashleigh Brilliant
