Release-critical Bugreport for August 1, 2003
Bug stamp-out list for Aug 1 06:00 (CST) Total number of release-critical bugs: 828 Number that will disappear after removing packages marked [REMOVE]: 19 Number that have a patch: 128 Number that have a fix prepared and waiting to upload: 25 Number that are being ignored: 7 Explanation for bug tags: P pending + patch H help M moreinfo R unreproducible S security U upstream Some bugs have an additional set of tags indicating they only apply to a particular release: O for oldstable (potato), S for stable (woody), T for testing (sarge) or U for unstable (sid). -- Package: acpid (debian/main) Maintainer: Cajus Pollmeier [EMAIL PROTECTED] 203588 [] acpid: Shell script has nothing to do in /etc Package: adbbs (debian/main) Maintainer: Kai Henningsen [EMAIL PROTECTED] 190117 [ + ] adbbs: Default Configuration Uses pine pico Package: aime (debian/main) Maintainer: Ed Boraas [EMAIL PROTECTED] 172566 [] aime: fills up /var diskspace until it is overflowing Package: alsa-base (debian/main) Maintainer: Debian-Alsa Psychos [EMAIL PROTECTED] 200686 [] alsa-base must conflict with older versions of alsa-utils Package: alsa-driver (debian/main) Maintainer: Debian-Alsa Psychos [EMAIL PROTECTED] 199940 [] alsa-driver: debhelper builddepends version too low Package: alsaplayer (debian/main) Maintainer: Ivo Timmermans [EMAIL PROTECTED] 200956 [ H R ] alsaplayer doesn't build on s390 Package: amavisd-new-milter (debian/main) Maintainer: Brian May [EMAIL PROTECTED] 203545 [] amavisd-new-milter: /usr/sbin/amavis-milter always fails Package: animals (debian/main) Maintainer: Jim Lynch [EMAIL PROTECTED] 195404 [] animals: FTBFS with g++-3.3: strstream.h is gone Package: anjuta (debian/main) Maintainer: Rob Bradford [EMAIL PROTECTED] 203448 [] anjuta_1.1.97-1(alpha/unstable): missing build-depends Package: apache-ssl (non-US/main) Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org 194334 [P ] apache-ssl: postint blows away configuration files Package: apache2-mpm-prefork (debian/main) Maintainer: Thom May [EMAIL PROTECTED] 203093 [] Should be able to still uninstall if can't stop apache Package: aptitude (debian/main) Maintainer: Daniel Burrows [EMAIL PROTECTED] 201259 [] aptitude on PPC/testing can not be installed via apt Package: arla (non-US/main) Maintainer: Mikael Andersson [EMAIL PROTECTED] 198294 [] arla: FTBFS with gcc-3.3: Invalid preprocessor pasting Package: armagetron (debian/main) Maintainer: Andreas Bombe [EMAIL PROTECTED] 201638 [] armagetron_0.2.2-1(alpha/unstable): not 64-bit clean Package: arson (debian/main) Maintainer: Mike Markley [EMAIL PROTECTED] 195214 [ U ] arson: conflicts with a file from k3b Package: atari800 (debian/contrib) Maintainer: Dale Scheetz (Dwarf #1) [EMAIL PROTECTED] 193397 [] atari800_1.3.0-2(mipsel/unstable): out of date config.sub/config.guess 203707 [ + SU ] atari800 allows local root compromise. Package: atlas (debian/main) Maintainer: Camm Maguire [EMAIL PROTECTED] 192990 [] atlas_3.2.1ln-7(unstable/arm): FTBFS Package: atmelwlandriver (debian/main) Maintainer: Paul Hedderly [EMAIL PROTECTED] 201053 [] atmelwlandriver_2.1.1-3.1(hppa/unstable): FTBFS: bad build-depends Package: autoconf (debian/main) Maintainer: Ben Pfaff [EMAIL PROTECTED] 156259 [] [S] db4.0: does not build from source Package: autoinstall-i386 (debian/main) Maintainer: Jeff Licquia [EMAIL PROTECTED] 169249 [] autoinstall-i386: fails to build on unstable 174559 [] autoinstall-i386: build depends on unavailable package busybox-source-0.60.0 Package: ax25-xtools (debian/main) Maintainer: Bruce Walker [EMAIL PROTECTED] 200997 [] ax25-xtools: needs rebuilding against Xft2 fltk1.1 (= 1.1.3-2.1) Package: ayttm (debian/main) Maintainer: Michael D. Ivey [EMAIL PROTECTED] 187916 [] ayttm: segfault during startup 189710 [] ayttm: Yahoo module hangs on logging in 193071 [] ayttm: FTBFS with current flex Package: barrendero (debian/main) Maintainer: Eduardo Diaz Comellas [EMAIL PROTECTED] 187836 [] barrendero: FTBFS: Missing Build-Depends 203281 [] barrendero: Building from source makes empty package Package: bayonne (debian/main) Maintainer: Mark Purcell [EMAIL PROTECTED] 202119 [] bayonne: Possible missing dependency Package: bcm5700-source (debian/main) Maintainer: Ard van Breemen [EMAIL PROTECTED] 193144 [] bcm5700-source: THe module doesn't build Package: biew (debian/main) Maintainer: Stefan Alfredsson [EMAIL PROTECTED] 198791 [] biew: Left-clicking results in an endless loop Package: bind-doc (debian/main) Maintainer: LaMont Jones [EMAIL PROTECTED] 199797 [] bind-doc:
Re: templates partags de debconf
Quoting Denis Barbier ([EMAIL PROTECTED]): Hmmm, cette histoire me rappelle quelque chose. Ah oui, c'est http://kitenet.net/pipermail/config/2002-July/000293.html Je n'ai pas relancé ensuite. Bon, j'ai enfin lu ce truc. En résumé, sin un volontaire se propose pour maintenir un paquet debconf-shared ou équivalent, Joey fait dépender debconf de ce paquet et zou...Ensuite, ce serait au mainteneur de ce paquet de gérer les templates proprement et inclure dans son paquet les shared d'autres paquets. Je sens que je vais relancer le bazar en septembre, moi..
Re: bug dans gcc ?
Dans un message du 01 aoû à 18:15, Alexandre Pineau écrivait : Faut-il quand même faire un rapport de bug ou dois-je jeter mon PC par la fenêtre? En général ce genre de problèmes est du à de la mémoire défectueuse. Il est très probable que tu aies à jeter une ou plusieurs barettes. Le meilleur moyen d'en être sûr est d'utiliser memtest86 qui te testera ta mémoire à fond... Il existe même un patch pour le noyau qui permet de continuer à utiliser une barette défectueuse en isolant les parties qui ne marchent pas, mais je n'ai jamais testé. A+ -- Guillaume Morin [EMAIL PROTECTED] Et si je suis bien que si j'ai bu, tant pis (Cornu)
Re: bug dans gcc ?
Alexandre Pineau wrote: Bonjour, gcc (3.3.1 20030728 (Debian prerelease)) plante régulièrement pendant la compilation d'un paquet. Ce plantage n'est pas reproductible de façon claire : La compilation peut aller jusqu'au bout, ou planter sur un fichier c aléatoire. Juste après le plantage, une recompilation du fichier en question passe... Par contre, si je relance un make, ça plante systématiquement au même endroit. C'est la première fois que je rencontre ce genre de problème sur ma machine (un k6 2 500). exemples d'erreur : gcc -c -Wall -O3-I. -DPATH_FILES_DAT=\//usr/share/games/ire/data/\ -DPATH_FILES_CONF=\//etc/ire/\ -g -DALLEGRO -DBGUI `allegro-config --cflags` -DUSE_ALOGG -DUSE_ALSOUND `alogg-config --cflags` -DNO_ASM pe/pe_vm.cpp -o pe/pe_vm.o pe/pe_vm.cpp: Dans function « void PV_SetMember() »: pe/pe_vm.cpp:4130: internal compiler error: Instruction illégale Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. J'ai aussi eu un segmentation fault... par contre, si je relance un make derrière, ça fonctionne... sur la page web de gcc il est précisé : # An error that occurs only some of the times a certain file is compiled, such that retrying a sufficient number of times results in a successful compilation; this is a symptom of a hardware problem, not of a compiler bug (sorry) Faut-il quand même faire un rapport de bug ou dois-je jeter mon PC par la fenêtre? Merci d'vance pour vos conseils. Alexandre Je suggere en effet de ne pas faire de bug report, en effet, c'est helas souvent un pb de hard du type par exemple de ram ou de cache sur barette externe ( sur machine ancienne ) parfois defectueuse ou avec de mauvais contact. -- -- -- Jean-Marc LACROIX -- -- mailto : [EMAIL PROTECTED] -- ---
Re: bug dans gcc ?
On Fri, 1 Aug 2003 13:09:53 -0400 Guillaume Morin [EMAIL PROTECTED] wrote: En général ce genre de problèmes est du à de la mémoire défectueuse. Il est très probable que tu aies à jeter une ou plusieurs barettes. Le meilleur moyen d'en être sûr est d'utiliser memtest86 qui te testera ta mémoire à fond... Il existe même un patch pour le noyau qui permet de continuer à utiliser une barette défectueuse en isolant les parties qui ne marchent pas, mais je n'ai jamais testé. memtest86 ne m'a pas remonté d'anomalies. Je suis cependant d'accord, il s'agit probablement d'un problème de mémoire. Merci pour ton aide. J'en profite pour poser rapidement une autre question : J'ai un autre programme qui plante à l'exécution cette fois ci (Il fonctionne chez l'auteur amont) : [EMAIL PROTECTED]:~/games/ire/ire_test$ ./ire-ed Shutting down Allegro due to signal #11 Erreur de segmentation (Et oui, encore...) Un coup de gdb me donne : gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, consider re-linking Je suis sec, là. Je n'arrive pas à retrouver la commande qui permet de visualiser les différents symboles attachés à un programme. Alexandre Ps : Je suis inscrit à la liste deban-devel-french.
Re: bug dans gcc ?
Dans un message du 01 aoû à 21:19, Alexandre Pineau écrivait : memtest86 ne m'a pas remonté d'anomalies. Je suis cependant d'accord, il s'agit probablement d'un problème de mémoire. Merci pour ton aide. Si memtest86 ne t'a rien montré et que tu l'as laissé tourner assez longtemps pour qu'il fasse tous les tests, je doute que ce soit la mémoire. Par contre, je ne vois pas que ça peut être. Shutting down Allegro due to signal #11 Erreur de segmentation(Et oui, encore...) Un coup de gdb me donne : gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, consider re-linking Je suis sec, là. Je n'arrive pas à retrouver la commande qui permet de visualiser les différents symboles attachés à un programme. A priori, ça voudrait dire que tu as une lib dont l'ABI est différente de celle avec laquelle a le programme a été compilé. Ce n'est pas forcément ça qui déclenche le segfault (même si ça peut en être la raison). Tu peux recompiler le programme, ça devrait régler l'histoire de symboles... Ps : Je suis inscrit à la liste deban-devel-french. Le group-reply est le comportement par défaut sur les listes de diffusions. Si tu ne veux pas recevoir de copie, il y a un header à positionner dans ton message. -- Guillaume Morin [EMAIL PROTECTED] Remember when we'd celebrate. We'd drink and get high until late And now we're all alone (Placebo).
Re: bug dans gcc ?
Salut, Le vendredi 01 août 2003 à 21:19 +0200, Alexandre Pineau a écrit : [...] J'ai un autre programme qui plante à l'exécution cette fois ci (Il fonctionne chez l'auteur amont) : [EMAIL PROTECTED]:~/games/ire/ire_test$ ./ire-ed Shutting down Allegro due to signal #11 Erreur de segmentation(Et oui, encore...) Un coup de gdb me donne : gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, consider re-linking Je suis sec, là. Je n'arrive pas à retrouver la commande qui permet de visualiser les différents symboles attachés à un programme. Compile avec gcc -g AMHA, le plus simple à faire c'est d'utiliser valgrind (ce dit, gdb c'est bien) a+ -- Pierre Machard [EMAIL PROTECTED] TuxFamily.org [EMAIL PROTECTED] techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87 pgpPFOuK1iN92.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Steve Kemp [...] | I'm loath to ask the user if it should be setgid in the installer | because that's just needless distraction, but perhaps some global | 'setgidnes' setting could be stored in /etc/games? [...] what's wrong with a low-priority debconf question with a sane default? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: debconf 2005 in Vienna, Austria
On Thu, Jul 31, 2003 at 02:15:43PM +0200, Christian Perrier wrote: Quoting Jonathan Walther ([EMAIL PROTECTED]): 4 hours to get somewhere is just an enjoyable Sunday drive. Not on german Autobhanen... :-). And especially if this happens during the week. But it will be on sunday late afternoon to evening, were there is low traffic and almost no trucks (they are allowed starting from 22h or so only). We reached Hannover from Karlsruhe in less than 4 hours this year, and that is, somewhat around 500km or so. Friendly, Sven Luther
Re: debconf 2005 in Vienna, Austria
On Thu, Jul 31, 2003 at 03:24:22PM +0200, Martin List-Petersen wrote: Citat Sven Luther [EMAIL PROTECTED]: On Thu, Jul 31, 2003 at 10:22:34AM +0200, Oliver Kurth wrote: On Thu, Jul 31, 2003 at 09:48:01AM +0200, Sven Luther wrote: On Thu, Jul 31, 2003 at 02:29:06AM +0200, Bernd Eckenfels wrote: On Thu, Jul 31, 2003 at 02:12:08AM +0200, Amaya wrote: Martin List-Petersen dijo: Something like that sounds sane. It gives even the possibility organising a shuttle-bus or something likewise from LinuxTag to Vienna That sound so appealing that I would even consider also attendig LinuxTag :-) Keep in mind, this is 730km and will take up to 8-12h Nothing compared to the 1800 km from Karlsruhe to Oslo, And if there is a bus, you could sleep or just rest, not needing to drive or something such. There is also a direct night train, takes 9:30 hours. Just look at http://www.bahn.de. But trains would be much more expensive, i think, than a common (full) bus. That was somewhat the point, when i mentioned sharing a bus. It depends on how many we are of course. It could also be possible eventually make a deal with DB (Deutsche Bahn) about some group rabat, if we just know, how many are going. So it's mostly to coordinate this people first and then get an offer. Maybe they even want to sponsor us by then :))) Friendly, Sven Luther
Re: debconf 2005 in Vienna, Austria
Quoting Riku Voipio ([EMAIL PROTECTED]): Trains (atleast the newer ones in finland) have electric sockets, rail fan ON This is still quite rare. For instance, in french trains (TGV and Teoz, formerly known as Corailie Intercity trains), electric wires are only available in the most recent coaches and only in 1st class usually. From memory, they are a little bit more common in Germany but not too much and certainly not in all IC trains, especially 2nd class. rail fan OFF So, IMHO, you'd better have long life batteries.. :-)
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? Absolutely nothing at all, but it's a slippery slope, and I thought we were tending towards less interactivity in installations? Steve --
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, 31 Jul 2003 17:30:11 +0300, Richard Braakman wrote: On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. As well as the ones using dpkg-statoverride in their postinsts now. -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message pgpltuDWMkZ1q.pgp Description: PGP signature
[no subject]
debian-devel 120 wsd [EMAIL PROTECTED] 2003-08-01
Re: debconf 2005 in Vienna, Austria
also sprach Sven Luther [EMAIL PROTECTED] [2003.08.01.0846 +0200]: On Thu, Jul 31, 2003 at 03:24:22PM +0200, Martin List-Petersen wrote: Citat Sven Luther [EMAIL PROTECTED]: On Thu, Jul 31, 2003 at 10:22:34AM +0200, Oliver Kurth wrote: On Thu, Jul 31, 2003 at 09:48:01AM +0200, Sven Luther wrote: On Thu, Jul 31, 2003 at 02:29:06AM +0200, Bernd Eckenfels wrote: On Thu, Jul 31, 2003 at 02:12:08AM +0200, Amaya wrote: Martin List-Petersen dijo: please, everyone, learn to quote! -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpaF7c8A9oRk.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
Citat Christian Perrier [EMAIL PROTECTED]: Quoting Riku Voipio ([EMAIL PROTECTED]): Trains (atleast the newer ones in finland) have electric sockets, rail fan ON This is still quite rare. For instance, in french trains (TGV and Teoz, formerly known as Corailie Intercity trains), electric wires are only available in the most recent coaches and only in 1st class usually. From memory, they are a little bit more common in Germany but not too much and certainly not in all IC trains, especially 2nd class. In Denmark you've got electric sockets at every 2nd seat on all IC3, IC4. We'll make that requirement, when ordering the tour :o) rail fan OFF So, IMHO, you'd better have long life batteries.. :-) Ehe ... 2 pcs 48WHr batteries should ensure power for some of the trip. Regards, Martin List-Petersen martin at list-petersen dot dk -- You are dishonest, but never to the point of hurting a friend.
Re: CUPS should be the default print service in Debian/Sarge
On Thu, Jul 31, 2003 at 11:35:13AM -0700, Keegan Quinn wrote: FWIW, I've had very good experiences with the CUPS in unstable, so I'd not object to this. OTOH, installing it without it being 'default' is already quite trivial. What would this change entail, exactly? So i had/have either in unstable and in stable. Should exim not to be the default MTA, it would be trivial to install too. This is not the point: the point is that CUPS is perfectly working for most of us and shows really a lot of good features, a user-friendly interface, quite large number of direvers support. It is a good solution for any user level with most common printers/needs, thus it should be the default (IMHO). ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgp8IiEFCw2jg.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Steve Kemp | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: | | what's wrong with a low-priority debconf question with a sane default? | | Absolutely nothing at all, but it's a slippery slope, and I thought | we were tending towards less interactivity in installations? which is why I said «low priority»: 'critical' only prompts you if the system might break. Pick it if you are a newbie, or in a hurry. 'high' is for rather important questions 'medium' is for normal questions 'low' is for control freaks who want to see everything If you select low, you will have to drink off the fire hose. Having low-priority questionsis good, since it makes it easy to make customized installs with preloaded answers. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 10:08:17AM +0200, Micha? Politowski wrote: On Thu, 31 Jul 2003 17:30:11 +0300, Richard Braakman wrote: On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. As well as the ones using dpkg-statoverride in their postinsts now. From my investigations, I thought that the intended use of dpkg-statoverride was by the local administrator, modifying the default suid/sgid and ownership of the file as set in the package tarball. - Matt
Data loss: suggestions for handling
The latest upstream version of a package I've begun to maintain, IRM, has a problem in that a portion of the data in the system (relating to software and licence assignment) can't be upgraded along with the rest of the database - the schema is totally different. I've thought about it for a while, and I can't come up with any good way to make the change. The best I've come up with so far is to put a question in the postinst which warns the user and allows them to continue if they're sure, or they can CTRL-C out and backup. If it's running in non-interactive mode, the install aborts. I really want to make sure the user doesn't lose all their data. A couple of questions: * Am I being too paranoid? Considering that this change will (hopefully) go into Sarge, an upgrade could do very upleasant things to people's databases automatically. Although I think that admins who blindly update across stable releases are nuts, I'd prefer not to annoy a bunch of nuts admins if I can avoid it. g * Can anyone think of another way of handling this? I can think of a couple of other ways: - create an irm1.4 package, but that is, shall we say, ugly in the extreme, and there's no possible reason to have two different versions of IRM installed simultaneously, which is (IMO) the main reason for package versions in the name. - dump the old software tables and store the dump somewhere, giving pointers to the dump in all sorts of useful places. But if I put it somewhere temporary (/tmp), it might disappear before the admin realises, and somewhere permanent will chew disk space. I appreciate any comments or suggestions anyone has as to how I could proceed. - Matt
Re: setuid/setgid binaries contained in the Debian repository.
Joey Hess [EMAIL PROTECTED] wrote:
I also think it would be a good idea for policy to require all
setuid/gid bit grants to go through this or another list for peer
review, much as pre-depends are supposed to.
How about creating a new group for each game?
--
Debian GNU/Linux 3.0 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: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Thu, Jul 31, 2003 at 11:21:57AM +0200, Sam Hocevar wrote: For instance it fails to remove this construct: link type=text/css rel=stylesheet href=/foo.css / Or rel=alternate stylesheet, and the various combinations that arise from support of non-graphical readers, etc. If this does get packaged it'll certainly have a lot of bugs filed against it, so the maintainer needs to be aware that it may be more of a responsibility than just a political statement. -- Jon Dowland
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 19:19:10 +1000, Matthew Palmer wrote: [...] From my investigations, I thought that the intended use of dpkg-statoverride was by the local administrator, modifying the default suid/sgid and ownership of the file as set in the package tarball. This is also my understanding. Still, some packages do use it for better or worse reasons. One example I've just found in uml-utilities.postinst: if ! getent group uml-net /dev/null; then addgroup --quiet --system uml-net fi if ! dpkg-statoverride --list /usr/lib/uml/uml_net /dev/null; then dpkg-statoverride --update --add root uml-net 04750 \ /usr/lib/uml/uml_net fi -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message pgpBNKpOPbVPj.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. How about creating a new group for each game? Umm... With hundreds, possibly thousands (in the future anyway) of games, is this really what you want to do? -- Keith
Re: debconf 2005 in Vienna, Austria
On Fri, Aug 01, 2003 at 08:32:57AM +0200, Christian Perrier wrote: This is still quite rare. For instance, in french trains (TGV and Teoz, formerly known as Corailie Intercity trains), electric wires are only available in the most recent coaches and only in 1st class usually. From memory, they are a little bit more common in Germany but not too much and certainly not in all IC trains, especially 2nd class. IC2 trains in finland have electric sockets in 2nd class seats, As well as GSM repeaters. Older trains have electric sockets in the corridor, presumably not for public usage, but no sign forbidding to use them :) Night trains usually have a socket for shavers, which can be rather handy for charging purposes as well. A quick grep on bahn.de says that ICE-T trains (presumably the most expensive ones..) have power sockets for every seat. Anyone with experience on german/austrian railroad? So, IMHO, you'd better have long life batteries.. :-) Yes. a debcamp of users would probably blow some fuse :) But still, using a laptop in a train is more comfortable than on a bus, or God forbid, on a car. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: CUPS should be the default print service in Debian/Sarge
On pe, 2003-08-01 at 12:32, Luca - De Whiskey's - De Vitis wrote: It is a good solution for any user level with most common printers/needs, thus it should be the default (IMHO). Do we actually need a default print service at all? Mail is much more fundamental, for example, but lots of computers these days don't have a printer attached at all. -- Debian developers for gentleness.
Re: Data loss: suggestions for handling
Matthew Palmer (2003-08-01 19:51:46 +1000) :
The latest upstream version of a package I've begun to maintain,
IRM, has a problem in that a portion of the data in the system
(relating to software and licence assignment) can't be upgraded
along with the rest of the database - the schema is totally
different.
Do you have an upgrade script? Like a set of SQL commands that will
convert from one schema to the other? More importantly, do you have a
set of criteria to check that the upgrade went smoothly and is now
complete? If so, then I've done that successfully.
I've thought about it for a while, and I can't come up with any good
way to make the change. The best I've come up with so far is to put
a question in the postinst which warns the user and allows them to
continue if they're sure, or they can CTRL-C out and backup. If
it's running in non-interactive mode, the install aborts. I really
want to make sure the user doesn't lose all their data.
I faced the same problems with sourceforge and gforge.
A couple of questions:
* Am I being too paranoid?
Probably not. Maybe some of your users won't mind too much if they
lose data, but most of them probably will. Then there's the personal
pride in building a crash-proof system even if nobody notices.
* Can anyone think of another way of handling this? I can think of
a couple of other ways:
- create an irm1.4 package, but that is, shall we say, ugly
Ugly indeed.
- dump the old software tables and store the dump somewhere,
giving pointers to the dump in all sorts of useful places.
Could be an option.
I appreciate any comments or suggestions anyone has as to how I
could proceed.
The way I did it for the sourceforge and gforge packages is this: I
have a special table (called debian_metadata), in which I can store
key-value pairs. One of the keys (okay, the only one normally) is
db-version, and the corresponding value is a version number with the
same semantics as the one provided by dpkg for the ordering). When I
need to upgrade something, I go the following steps:
,[ One upgrade chunk ]
| Begin transaction
| Do stuff
| Check that stuff went fine (and raise an exception/abort if not)
| Update the value for db-version
| Commit transaction
`
This is of course only executed if current db-version is less than
targeted version. So I have a series of upgrade chunks, arranged like
this:
,[ Upgrade script ]
| $target version = 1.0
| if (current-version $target-version) {
|Do the upgrade chunk for target=$target-version
| }
|
| $target version = 1.1
| if (current-version $target-version) {
|Do the upgrade chunk for target=$target-version
| }
|
| $target version = 1.4
| if (current-version $target-version) {
|Do the upgrade chunk for target=$target-version
| }
`
The postinst script always runs this upgrade script. So all the
steps that were previously completed are not replayed, and you'll
start at the first one that hasn't been successfully run yet. If one
step fails, the transaction is aborted and the user is presented with
an error message giving out info such as the current db-version, the
SQL statement that went wrong, and so on. And he's requested to
report the bug with this info :-)
All this requires a transactional database, obviously, but they're a
dime a dozen these days.
For more details, apt-get source gforge and have a look at the
deb-specific/db-upgrade.pl script.
Roland.
--
Roland Mas
You can't second-guess ineffability, I always say.
-- Aziraphale, in Good Omens (Terry Pratchett and Neil Gaiman)
Re: CUPS should be the default print service in Debian/Sarge
On Fri, Aug 01, 2003 at 02:49:59PM +0300, Lars Wirzenius wrote: Do we actually need a default print service at all? Mail is much more fundamental, for example, but lots of computers these days don't have a printer attached at all. We needn't install a print service by default but if someone says that want one we ought to have a default to offer them. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: Package: acpid Version: N/A; reported 2003-07-31 Severity: serious Justification: Policy 9.1.1 The shell script /etc/acpi/powerbtn.sh should be installed in something else, like /usr/share/acpid/ or /usr/sbin/. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux imperatrice.arcanes 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] I've no problem with that, but: These scripts used by acpid should be treated as some kind of user configuration, like i.e. cron keeps skripts installed by someone in /etc/cron.daily, acpid keeps skripts that take actions when some events happened. I've no idea about the exact handling of this issue. Should I move these scripts to /usr/share/acpid or /usr/sbin? Thanks for any hints, Cajus
Re: debconf 2005 in Vienna, Austria
On Fri, Aug 01, 2003 at 02:06:48PM +0300, Riku Voipio wrote: A quick grep on bahn.de says that ICE-T trains (presumably the most ~ expensive ones..) have power sockets for every seat. Anyone with experience on german/austrian railroad? So, IMHO, you'd better have long life batteries.. :-) Yes. a debcamp of users would probably blow some fuse :) Man, this discussion is begging for a musical intermezzo... :) o/~ Let me see how hot you can get Then I'll turn up the amps, blow out the lights You're in darkness, then the mic ignites Glowin like it did before, but even more o/~ -- 2. That which causes joy or happiness.
Re: debconf 2005 in Vienna, Austria
Riku Voipio wrote: On Fri, Aug 01, 2003 at 08:32:57AM +0200, Christian Perrier wrote: This is still quite rare. For instance, in french trains (TGV and Teoz, formerly known as Corailie Intercity trains), electric wires are only available in the most recent coaches and only in 1st class usually. From memory, they are a little bit more common in Germany but not too much and certainly not in all IC trains, especially 2nd class. IC2 trains in finland have electric sockets in 2nd class seats, As well as GSM repeaters. Older trains have electric sockets in the corridor, presumably not for public usage, but no sign forbidding to use them :) Night trains usually have a socket for shavers, which can be rather handy for charging purposes as well. A quick grep on bahn.de says that ICE-T trains (presumably the most expensive ones..) have power sockets for every seat. Anyone with experience on german/austrian railroad? I've only taken a few trains in Germany, but the night train I was on had a socket by each table (to share between 4 people). Other than that, I've only been on the slow regional trains (which you wouldn't be taking anyway, but don't have sockets). So I think batteries would be a good idea... -- Keith
Bug#203768: RFP: sixpack -- Bibliography and Reference Manager
Package: wnpp Severity: wishlist * Package name: sixpack Version : 0.99 Upstream Author : Apparently Michael Lachmann http://www.santafe.edu/~dirk/ * URL or Web page : http://www.santafe.edu/~dirk/sixpack/ * License : GPL Description : Bibliography and Reference Manager SIXPACK is a free BibTeX and Reference Manager designed to * edit, convert and manage reference files * search and sort bibliographies * import and export many different bibliography types. Sixpack uses the excelent * have both a command line and a gui interface. * work completely from the keyboard. * be able to import references from the web, now even through direct-download using the bib-remote program. * be able to open an article through an external viewer.
Re: Data loss: suggestions for handling
* Matthew Palmer ([EMAIL PROTECTED]) wrote: - dump the old software tables and store the dump somewhere, giving pointers to the dump in all sorts of useful places. But if I put it somewhere temporary (/tmp), it might disappear before the admin realises, and somewhere permanent will chew disk space. /var/backups. Tell the admin, if they want to clean it up they can. Stephen pgpIQ1XH72vze.pgp Description: PGP signature
Ayuda
Nesecitaria los driver de la placa de red Cnet Pro200 PCI fast Ethernet Adapter Desde ya muchas graciasInternet GRATIS es Yahoo! Conexión. Usuario: yahoo; contraseña: yahoo Desde Buenos Aires: 4004-1010 Más ciudades: clic aquí.
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Fri, Aug 01, 2003 at 02:09:36PM +0200, Cajus Pollmeier wrote: On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: Package: acpid Version: N/A; reported 2003-07-31 Severity: serious Justification: Policy 9.1.1 The shell script /etc/acpi/powerbtn.sh should be installed in something else, like /usr/share/acpid/ or /usr/sbin/. I've no problem with that, but: These scripts used by acpid should be treated as some kind of user configuration, like i.e. cron keeps skripts installed by someone in /etc/cron.daily, acpid keeps skripts that take actions when some events happened. I've no idea about the exact handling of this issue. Should I move these scripts to /usr/share/acpid or /usr/sbin? I think at least the RCness of this bug is rather dubious, frankly. If the script is configuration (i.e. is human-editable and is expected to be edited by a reasonable number of people to configure acpid in some different way without having to hack acpid's source) then it should stay in /etc. The FHS doesn't forbid that, and if people really are editing it then it should definitely not be in /usr. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from
CB == Christoph Berg [EMAIL PROTECTED] writes: CB If you are both a DD and upstream, why didn't you package it CB yourself? Good question. Installing Pigdog DeCSS in somebody's Debian system doesn't really meet my goals for the software. The original point was to have mirrors around the world, and to distract from the witch hunt for DVD DeCSS. A /usr/bin/decss install doesn't really do that much. I was happy to see someone ITP the software, but I probably wouldn't do it myself. ~ESP -- Evan Prodromou [EMAIL PROTECTED]
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Cajus Pollmeier [EMAIL PROTECTED] writes: On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: Severity: serious Justification: Policy 9.1.1 (Debian should obey the FHS; I don't claim to be an FHS expert, but all it seems to say about /etc is no binaries, which this doesn't violate.) The shell script /etc/acpi/powerbtn.sh should be installed in something else, like /usr/share/acpid/ or /usr/sbin/. I've no problem with that, but: These scripts used by acpid should be treated as some kind of user configuration, like i.e. cron keeps skripts installed by someone in /etc/cron.daily, acpid keeps skripts that take actions when some events happened. Is this script that gets run when the console user presses the power button, and is it obvious that the user could potentially want to configure it? If so, then it makes sense that it should be a configuration file, and so by policy 10.7.2 it should live in /etc. (And as you point out, it's not like there aren't other admin-editable scripts in /etc already, say, all of /etc/init.d.) My reading is that what you're doing now is fine and the bug is wrong. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
I think at least the RCness of this bug is rather dubious, frankly. If the script is configuration I don't think the script is meant to be edited... So it should be in /usr/sbin. Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpjHl0gN4jh5.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Freitag, 1. August 2003 15:31, David Z Maze wrote: Cajus Pollmeier [EMAIL PROTECTED] writes: On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: Severity: serious Justification: Policy 9.1.1 (Debian should obey the FHS; I don't claim to be an FHS expert, but all it seems to say about /etc is no binaries, which this doesn't violate.) The shell script /etc/acpi/powerbtn.sh should be installed in something else, like /usr/share/acpid/ or /usr/sbin/. I've no problem with that, but: These scripts used by acpid should be treated as some kind of user configuration, like i.e. cron keeps skripts installed by someone in /etc/cron.daily, acpid keeps skripts that take actions when some events happened. Is this script that gets run when the console user presses the power button, and is it obvious that the user could potentially want to configure it? If so, then it makes sense that it should be a configuration file, and so by policy 10.7.2 it should live in /etc. (And as you point out, it's not like there aren't other admin-editable scripts in /etc already, say, all of /etc/init.d.) My reading is that what you're doing now is fine and the bug is wrong. So in case of a power down script, this may be somewhat fixed in its task. This would be true. But this script must not be the only one. Maybe the user wants to place a script for i.e. closing the LID or do special reactions on suspend events etc. In my understanding /etc/acpid is the correct place for that. So, I changed the serevity of the bug. I'm just off to vacations tomorrow - will look into this when I'm back. Thanks, Cajus
Re: CUPS should be the default print service in Debian/Sarge
Keegan Quinn wrote: FWIW, I've had very good experiences with the CUPS in unstable, so I'd not object to this. OTOH, installing it without it being 'default' is already quite trivial. What would this change entail, exactly? Probably making the print server task install it instead of lpr, which would have a side effect of making sure it's on CD#1 if it's not already. Probably also demoting the lpr package to optional and moving cups from there to standard. Possibly making lsb depend on part of cups instead of lpr. -- see shy jo, following this discussion with interest and his tasksel hat on pgppk4AHwmPay.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? -- - mdz
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Pierre THIERRY wrote: I don't think the script is meant to be edited... So it should be in /usr/sbin. You think wrong. The user should be able to choose whether the power button triggers shutdown or suspend to disk, for instance. -- Matthew Garrett | [EMAIL PROTECTED]
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 06:37:53PM +0100, Steve Kemp wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I'd like to see us move all of our setgid games (except, perhaps, nethack) away from using global score files by default. I think that should be a good option, but I can see several games that might suffer by it. I'm loath to ask the user if it should be setgid in the installer because that's just needless distraction, but perhaps some global 'setgidnes' setting could be stored in /etc/games? Personally, I would lean more towards having a setgid helper which writes to the game's score file. It is possible to audit such helpers completely in a short amount of time, and I feel that it would be far better to open ourselves up to letting users forge their own high scores than to the current exposures which are possible through group games. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? As long as the sane default is the safe default, which is not to be setgid. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:45:16PM +1000, Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. How about creating a new group for each game? This is only somewhat better, from a security perspective, than sharing a group, depending on how many games are installed on the system. -- - mdz
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
You think wrong. The user should be able to choose whether the power button triggers shutdown or suspend to disk, for instance. But one shouldn't have to edit a shell script to do it. It should just be necessary to edit a configuration file. Like modifying the action value to something like /usr/sbin/poweroff or /usr/sbin/suspend-to-disk Surely, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpgqzVk71oL5.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:18:53AM -0400, Matt Zimmerman wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? I would support such a change too, and would volunteer to assist if there was need for it. Steve -- pgpVrvHIYtBXb.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Pierre THIERRY dijo [Fri, Aug 01, 2003 at 03:58:23PM +0200]: I think at least the RCness of this bug is rather dubious, frankly. If the script is configuration I don't think the script is meant to be edited... So it should be in /usr/sbin. There are many scripts in /etc that are not meant to be edited unless a special need arises - The first packages that comes to my mind are pcmcia-cs and linux-wlan-ng. They have many different scripts in /etc/pcmcia, and almost always they work perfectly - I had to fiddle with them once. In my system I have 113 executable files under /etc, they belong to the most varied programs... And they are (or at least, they seem to be) perfectly valid configurable files. (most of them - see my next message) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgpwnZq7O92MR.pgp Description: PGP signature
Re: Data loss: suggestions for handling
On Fri, Aug 01, 2003 at 07:51:46PM +1000, Matthew Palmer wrote: The latest upstream version of a package I've begun to maintain, IRM, has a problem in that a portion of the data in the system (relating to software and licence assignment) can't be upgraded along with the rest of the database - the schema is totally different. Even if the schema is different, if it represents the same data, it should be possible to convert it. Maybe someone here (or upstream) can help with this. What instructions does upstream provide for the upgrade? Do they say that you must destroy this data and recreate it? -- - mdz
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
David Z Maze dijo [Fri, Aug 01, 2003 at 09:31:40AM -0400]: Cajus Pollmeier [EMAIL PROTECTED] writes: On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: Severity: serious Justification: Policy 9.1.1 (Debian should obey the FHS; I don't claim to be an FHS expert, but all it seems to say about /etc is no binaries, which this doesn't violate.) Ummm... I *did* find something strange, maybe you can give some more insight on this: [EMAIL PROTECTED]:/$ find /etc -type f -perm -755|xargs file|grep ELF etc/X11/rstart/rstartd.real:ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped [EMAIL PROTECTED]:/$ dpkg -S rstartd.real xutils: /etc/X11/rstart/rstartd.real This is clearly a binary, it is clearly not user-modifiable. Should it be in /etc? Should it just be a symlink to /usr/lib/xutils or something like it? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Fri, Aug 01, 2003 at 10:32:47AM -0500, Gunnar Wolf wrote: Ummm... I *did* find something strange, maybe you can give some more insight on this: [EMAIL PROTECTED]:/$ find /etc -type f -perm -755|xargs file|grep ELF etc/X11/rstart/rstartd.real:ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped [EMAIL PROTECTED]:/$ dpkg -S rstartd.real xutils: /etc/X11/rstart/rstartd.real This is clearly a binary, it is clearly not user-modifiable. Should it be in /etc? Should it just be a symlink to /usr/lib/xutils or something like it? Yes, it's a known bug, it'll be fixed. -- 2. That which causes joy or happiness.
Re: setuid/setgid binaries contained in the Debian repository.
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. Stephen pgpYXXeHWnI5U.pgp Description: PGP signature
Re: Data loss: suggestions for handling
On Fri, Aug 01, 2003 at 01:59:43PM +0200, Roland Mas wrote: Matthew Palmer (2003-08-01 19:51:46 +1000) : The latest upstream version of a package I've begun to maintain, IRM, has a problem in that a portion of the data in the system (relating to software and licence assignment) can't be upgraded along with the rest of the database - the schema is totally different. Do you have an upgrade script? Like a set of SQL commands that will convert from one schema to the other? More importantly, do you have a I do, but it doesn't work with the software portion. The rest of the system upgrades smoothly, but the information stored by the software tracker part is different enough that it can't be converted. I've extracted out all the SQL commands that do the upgrade from the upstream-supplied PHP script and have gotten those going OK. It's dealing with the seemingly unavoidable data loss in the software tracking part that I just can't deal with well. Upstream seems to think it too hard as well, because, while the rest of the system upgrades OK, they've got big warning, you will lose your software data messages all over the later versions. A couple of questions: * Am I being too paranoid? Probably not. Maybe some of your users won't mind too much if they lose data, but most of them probably will. Then there's the personal pride in building a crash-proof system even if nobody notices. A craftsman after my own heart. Pride in one's work. g - Matt
Re: Data loss: suggestions for handling
On Fri, Aug 01, 2003 at 08:04:09AM -0400, Stephen Frost wrote: * Matthew Palmer ([EMAIL PROTECTED]) wrote: - dump the old software tables and store the dump somewhere, giving pointers to the dump in all sorts of useful places. But if I put it somewhere temporary (/tmp), it might disappear before the admin realises, and somewhere permanent will chew disk space. /var/backups. Tell the admin, if they want to clean it up they can. Hey, look at that. Never knew that existed. Thankyou very much. I think my problem has been solved. Again, my thanks. - Matt
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Hi, Matthew Garrett wrote:
The user should be able to choose whether the power
button triggers shutdown or suspend to disk, for instance.
While I do agree that this kind of script is best placed in /etc, this
kind of choice can be configured by a normal /etc/acpid.conf that's read
by the script.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
A pretty woman is a welcome guest.
-- Byron
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote: * Matt Zimmerman ([EMAIL PROTECTED]) wrote: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. I think debian-security would be fine, maybe with a special Subject tag. -- - mdz
[PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
Adrian Bunk [EMAIL PROTECTED] wrote: [...] [3] http://www.fs.tum.de/~bunk/Debian/freeze Reading the whole Future releases of Debian thread, I thought that the main idea was that Debian need a more 'readable' status for the next stable release. I propose to create a meta-package called 'release-status-sarge' that depends on packages (with version number) that we want to see in sarge. Each maintainer has to fill a bug report to include his package in the next release and explain why the release has to wait for this package (or/ and this version of the package). We can have different bug level for the importance to include the package or not. The release-status-sarge maintainer can then add the package in the Depends field with the version number and close the bug, or he (she) can tag the bug 'wontfix' and explain why the package will not be in the next release. He (or she) can also ask for moreinfo. Why a meta-package and not a virtual-package? If we have a meta-package, we can use 'grep-excuse' to see who we are waiting for?, in addition with the BTS, it's a lot of informations. We can also submit other bugs against the release-status-sarge package, like Too many RC Bugs or any other information on why the release is nt ready yet. I think Adrian is right when he want more release. I think the idea of having a Debian release a year is not so bad, but I do not like the idea of a dead-line for Debian releases. I think that Next release of Debian will happen when it is ready should be a general way of thinking even in other areas! This does not mean we do not need a strict release plan, but I prefer to base the release plan on targets, not on dates. Clear release goals not a release date. Also, Debian has developed lot of interresting concepts, ideas and tools, my idea is just to use some of them, no additional development, to clarify stable release plan and goals to Debian users and even Debian developers. Any comments are appreciate, thank you for your time, Note: I could also call the proposal Debian Release Unified Goals but finally I don't think it's a good idea ;) -- Arnaud Vandyck http://alioth.debian.org/users/arnaud-guest/ pgpkrot1qJ0Cf.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:34:11AM +0200, Tollef Fog Heen wrote: * Steve Kemp | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: | | what's wrong with a low-priority debconf question with a sane default? | | Absolutely nothing at all, but it's a slippery slope, and I thought | we were tending towards less interactivity in installations? which is why I said «low priority»: 'critical' only prompts you if the system might break. Pick it if you are a newbie, or in a hurry. 'high' is for rather important questions 'medium' is for normal questions 'low' is for control freaks who want to see everything If you select low, you will have to drink off the fire hose. Having low-priority questionsis good, since it makes it easy to make customized installs with preloaded answers. The only question I would have about it is that every potentially-sgid game package would need to share the question (so that it only got asked once, but was available whenever needed) - organizing that could be a bit tricky, I would think. Certainly I think it would be one of the more reasonable uses of shared debconf stuff - one question, low priority, a sane default of not being sgid, and assuming packages used something proper (er, dpkg-statoverride?) to register the sgid bit, it doesn't matter if you blow away the answer cache - you can look at the existing state and find out what you need to know (or, presumably, override it). -- Joel Baker [EMAIL PROTECTED] pgpHUUfcNpVft.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Fri, Aug 01, 2003 at 02:06:48PM +0300, Riku Voipio wrote: Yes. a debcamp of users would probably blow some fuse :) Speaking as someone who's held an FRA (US Federal Railroad Administration) crew and fireman cert - it's unlikely, unless you do something that would overload a normal house circuit. Diesel locomotives are a giant diesel generator hooked up to electric traction motors, running through the switchbox at something like 600v (I haven't read the specs in a while, this might be off - but it's high enough to warrant being really careful around). Don't even ask about the amperage. Sapping off a little power to run a few household outlets is, by comparison, peanuts. Or, really, peanut crumbs. Now, just try not to be nervous at the fact that there's a pipe running under your feet pressurized to 90 PSI (at least on standard US trains), and you'll be fine. :) There's a reason they call popping the coupling seals on that line (the fail-safe (full stop) airbrake line) completely (rather than bleeding the air off) 'dynamiting'... -- Joel Baker [EMAIL PROTECTED] pgpRKx4EOtwNp.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 05:33:23PM +0100, Steve Kemp wrote: There's probably a lot to be said for building a chroot installation and installing each package in turn; but I don't have the time for that at the moment. I have some basic tools for doing this kind of thing using UML's copy-on-write block devices, so it is relatively efficient. This is one of the things that I plan to do with it once it is ready for large-scale projects. -- - mdz
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote: I propose to create a meta-package called 'release-status-sarge' that depends on packages (with version number) that we want to see in sarge. I don't think that the most important release goals can be expressed in terms of version numbers. For example, RC bug fixes. I don't find goals such as we want version X of package Y because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman wrote: On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote: * Matt Zimmerman ([EMAIL PROTECTED]) wrote: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. I think debian-security would be fine, maybe with a special Subject tag. Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Proposal: [DRAFT] require peer review for setuid and setgid program introduction Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Often these holes can be spotted easily with a simple review. Sometimes setuid/gid programs can be modified in fairly simple ways to not need these dangerous permissions at all. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. So, I propose that any new setuid or setgid programs should be reviewed by a team of interested people before being put into the distribution. In discussions on debian-devel, we agreed this was a good idea, and that debian-security is the appropriate list for these reviews. The reviewers will be whoever is interested, which currently includes at least one member of the security team, and one of our most prolific security auditors. Note the paralell with the existing requirement that essential packages be discussed on debian-devel. --- policy.sgml.orig2003-08-01 13:40:51.0 -0400 +++ policy.sgml 2003-08-01 13:45:24.0 -0400 @@ -7104,6 +7104,14 @@ execute them. /p +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p + p It is possible to arrange that the system administrator can reconfigure the package to correspond to their local -- see shy jo pgpsKaYcBNHRc.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman wrote: Personally, I would lean more towards having a setgid helper which writes to the game's score file. It is possible to audit such helpers completely in a short amount of time, and I feel that it would be far better to open ourselves up to letting users forge their own high scores than to the current exposures which are possible through group games. I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter (these names could be better). Then the helper would refuse to write any scores unless its real GID is scoresetter. -- see shy jo pgplRuxCwkTHX.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote: I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter (these names could be better). Then the helper would refuse to write any scores unless its real GID is scoresetter. I considered something like this, but I dismissed it as overcomplicated for the problem (of forging local high scores). I'd rather decrease the overall number of privileged programs than reorganize into a larger number of privilege groups. With fewer and fewer users per system these days, there isn't usually any glory in this kind of high score anyway, and only client/server games which are mediated by a neutral server can usefully provide this kind of scorekeeping. -- - mdz
Re: [PROPOSAL] Debian Release Plan
Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote: I propose to create a meta-package called 'release-status-sarge' that depends on packages (with version number) that we want to see in sarge. I don't think that the most important release goals can be expressed in terms of version numbers. For example, RC bug fixes. I don't find goals such as we want version X of package Y because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... We can think of a new release when 'release-status-sarge' will be in testing. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgpU6BP0phUe5.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote: Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Thanks for doing this. It looks fine, with the exception of a small typo: + Since setuid and setgid programs are often a security rick, ^ risk If we could come up with a standard way of setting these permissions, to avoid the kind of messing around in the postinst that we do now, it would be trivial to add lintian/linda warnings for this, to encourage maintainers to discuss the situation before uploading. doogie, asuffield and I discussed this on IRC recently. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. -- 2. That which causes joy or happiness.
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: I don't think that the most important release goals can be expressed in terms of version numbers. For example, RC bug fixes. I don't find goals such as we want version X of package Y because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... Of course it would, unless it had a versioned dependency that could not be met. And how would you know in which version the bug would be fixed? -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote: On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. Ah, ok. But the point was that it will miss many cases. For example, I've never seen this warning in uml-utilities because it uses a dynamically-allocated gid and so must use chmod in postinst rather than setting permissions in the .deb. If this could be done at build time rather than at install time, the check would be perfect. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
* Joey Hess ([EMAIL PROTECTED]) wrote: --- policy.sgml.orig 2003-08-01 13:40:51.0 -0400 +++ policy.sgml 2003-08-01 13:45:24.0 -0400 @@ -7104,6 +7104,14 @@ execute them. /p +p + Since setuid and setgid programs are often a security rick, 'risk' might be a bit better. :) + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the until it has been discussed .. ? + emdebian-security/em mailing list and a consensus about + doing that has been reached. and a consensus reached which approves of the application and it's needs. ? Stephen pgp0zhMViopSR.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003, Matt Zimmerman wrote: On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote: On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. Ah, ok. But the point was that it will miss many cases. For example, I've never seen this warning in uml-utilities because it uses a dynamically-allocated gid and so must use chmod in postinst rather than setting permissions in the .deb. If this could be done at build time rather than at install time, the check would be perfect. Andrew Suffield and I have plans to get rid of dynamic user creation in postinst, and chmod +s as well. preinst will create the user(by calling adduser), then the setuid-ness in the deb can be applied. This invovles modifying dpkg-deb to read a list of permission overrides. See -policy.
Re: CUPS should be the default print service in Debian/Sarge
On Thu, Jul 31, 2003 at 09:44:17AM -0400, Daniel Jacobowitz wrote: The last time I tried to use CUPS, I found it to be so user friendly that I couldn't get it to do anything useful. Very pretty, less functional; and the documentation was entirely inadequate. On the other hand, while lprng was anything but user-friendly, it was simple and well-documented. Much more important to have something that works before you go making it user-friendly! Care to give more details? Which printer? How was it connected? How did you try to setup CUPS? Even if I don't think the CUPS documentation is superb, for the setups I have had to deal with (anything but trivial) it was adequate, and the only thing I really that to read about what the IPP name service conventions. Marcelo
EARN $500 TO $700 PER WEEK DOWNLOADING FREE SOFTWARE!!
Make $500 to $700 per week for downloading FREE software!! Dear friend!! We know it sounds too good to be true, but itfs REAL! We pay you hard cash for you to download and install this FREE software and we pay you each month that you continue to use it. Best of all you will only have to download a small (110K) piece of software ONE time for FREE and you'll be on your way to earning BIG MONEY.. Just visit http://www.raden.plugusin4cash.com/ to find out more. Sincerely yours, Gary http://www.raden.plugusin4cash.com [EMAIL PROTECTED]
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Aug 01, David Z Maze [EMAIL PROTECTED] wrote: Is this script that gets run when the console user presses the power button, and is it obvious that the user could potentially want to configure it? If so, then it makes sense that it should be a configuration file, and so by policy 10.7.2 it should live in /etc. The user may want to configure it, but OTOH the script name is referenced in /etc/acpid/events/powerbtn, and it would probably be cleaner to make it point to a local script. -- ciao, | Marco | [1063 afeJFGjAxPvAk]
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 11:22:17 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? As long as the sane default is the safe default, which is not to be setgid. Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. manoj -- St. Patrick was a gentleman who through strategy and stealth drove all the snakes from Ireland. Here's a toasting to his health -- but not too many toastings lest you lose yourself and then forget the good St. Patrick and see all those snakes again. 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: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 13:46:48 -0400, Joey Hess [EMAIL PROTECTED] said: Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Proposal: [DRAFT] require peer review for setuid and setgid program introduction Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Often these holes can be spotted easily with a simple review. Sometimes setuid/gid programs can be modified in fairly simple ways to not need these dangerous permissions at all. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. So, I propose that any new setuid or setgid programs should be reviewed by a team of interested people before being put into the distribution. In discussions on debian-devel, we agreed this was a good idea, and that debian-security is the appropriate list for these reviews. The reviewers will be whoever is interested, which currently includes at least one member of the security team, and one of our most prolific security auditors. Note the paralell with the existing requirement that essential packages be discussed on debian-devel. This seems like a good practice kind of recommendation, not an requirement, and as such, may be better suited to be included in developers reference rather than policy, don't you think? manoj -- The Bird of Time has but a little way to fly ... and the bird is on the wing. Omar Khayyam 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: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. -- - mdz
Sheet Music
Could you please send me the sheet music for Dueling Banjos _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Jim Penny who has in past lives spent far too many hours playing nethack
Re: [PROPOSAL] Debian Release Plan
Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote: [...] If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... Of course it would, unless it had a versioned dependency that could not be met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. It does not matter to know in which version the bug will be fixed. What I want for sarge is emacs21 ( = 21.2 ) so if every RC bugs are closed with 21.3 or 21.4, the dependency =21.2 is ok. I think I do not understand what you mean or I do not see where the problem is. What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. The existance of this package in testing does not mean the next stable release must come out as soon as possible, but it's a monitor, it can give important informations on what have to be done to reach the next stable release. I think about this proposal just after the first mail of Adrian Bunk, but I think I did not think enough :( Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. Best regards, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgpa0RwcemmKk.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote: Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Hmm DSA-360: no (daemon) DSA-359: yes (uid root: hardware access) DSA-358: no (kernel) DSA-357: no (daemon) DSA-356: yes (gid games) DSA-355: no (web css) DSA-354: yes (gid games) DSA-353: no (daemon, temp file) DSA-352: no (user, temp file) DSA-351: no (web css) DSA-350: yes (gid games) DSA-349: no (daemon) DSA-348: yes (system root tool exploit) ... Looking at this statistic, it is clearly visible that most of the exploits are game related, in fact only one system tool and one hardware accessing 'game' would allow suid root exploits, all others are sgid games. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. Yes, but I think the eyes should concentrate on non sgid-games first. Because this might be a realy BIG junk of UGLYNESS one will find there :) And some of the suid root stuff, like hardware acces might even require debian to switch to some more sensible kernel setups. +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p Do we want to make an sgui games exception here? 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: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote: I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter Umm... you invent a scorewriter for removing the sgui games bit? And then you add a sgid scoresetter? I dont think this makes mch sence. Although it is true, that sgid games exploit are a problem, because they can be used to invade other game playing users, personally I think it is much more important to look at the other suids first. BUT: i realy do think each game MUST offer the non sgid option. We could have a global question herer: Do you want to limit gaming experiencing on your system but therefore increase system security? If you answer yes here, no game will be installed sgid games, and therefore you do not have shared highscores. yes no 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: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 04:13:30PM -0400, Jim Penny wrote: On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Of course it is the real reason. Otherwise you get exactly the same feature with a world-writable directory. (and anyway, there exists 'hearse' now, though I haven't tried it) -- - mdz
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote: [...] If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... Of course it would, unless it had a versioned dependency that could not be met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. It does not matter to know in which version the bug will be fixed. What I want for sarge is emacs21 ( = 21.2 ) so if every RC bugs are closed with 21.3 or 21.4, the dependency =21.2 is ok. And what if the version in testing has an RC bug? release-status-sarge says everything is OK. What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. I am saying that the reality of the situation is more complex than is accounted for in this approach. Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. I do not think that version number milestones are important for a release. I think that having a well-integrated, high-quality distribution is important for a release, and this is not so easily monitored. -- - mdz
Why doesn't yehia enter testing?
I wonder why yehia isn't entering testing. According to [0] it makes qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to yehia, AFAICS. Regards, Andy [0] http://bjorn.haxx.se/debian/testing.pl?package=yehiaexpand=1 -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Python is executable pseudocode, Perl is executable line-noise.
Re: Why doesn't yehia enter testing?
On Fri, Aug 01, 2003 at 10:40:12PM +0200, Andreas Rottmann wrote: I wonder why yehia isn't entering testing. According to [0] it makes qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to yehia, AFAICS. Regards, Andy [0] http://bjorn.haxx.se/debian/testing.pl?package=yehiaexpand=1 Hmm, I think that particular script might be in need of updating following some hacking that I understand has been done recently to the testing scripts. What I see at http://ftp-master.debian.org/testing/update_output.txt doesn't really indicate to me that yehia is causing qmailmrtg7 to be uninstallable; rather, it looks like qmailmrtg7 is being hinted in, it is uninstallable for reasons of its own, and the (alphabetically) last package in the group of packages being tried during this particular run is yehia. -- Steve Langasek postmodern programmer pgpmo7ygD0VIt.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote: [...] It does not matter to know in which version the bug will be fixed. What I want for sarge is emacs21 ( = 21.2 ) so if every RC bugs are closed with 21.3 or 21.4, the dependency =21.2 is ok. And what if the version in testing has an RC bug? release-status-sarge says everything is OK. You are rigth. I thought we can fill a RC bug to early for a stable release but you are right, if one of the version we want is in testing and we are OK for a release, yes, the monitor will be wrong! What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. I am saying that the reality of the situation is more complex than is accounted for in this approach. Isn't it a beginning? Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. I do not think that version number milestones are important for a release. I think that having a well-integrated, high-quality distribution is important for a release, and this is not so easily monitored. I agree. Anybody to try another proposal? ;) -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgp4qsb6l9Ypc.pgp Description: PGP signature
Re: Why doesn't yehia enter testing?
On Fri, Aug 01, 2003 at 10:40:12PM +0200, Andreas Rottmann wrote: I wonder why yehia isn't entering testing. According to [0] it makes qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to yehia, AFAICS. I've no idea where qmailmrtg7 is coming from, but actually yehia is caught up in the libsigc++ dependency chain. Since libsigc++'s library package name has changed since the version in testing, everything depending on the old version in testing needs to be rebuilt before the new group can go into testing. There are several packages at the moment holding this up: * aptitude used to depend on libsigc++0. The new version doesn't, but it needs the new apt, which is almost ready but is waiting for new versions of gcc-3.3 and glibc. * lostirc has RC bugs #194366 and #194867. * thoughttracker has various build problems; see #198905. * gtkextramm has RC bug #197591. * vdk2 has RC bug #201318. * fwbuilder fails to build on arm. Fix this lot and I think it should be OK ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 22:31:16 +0200, Bernd Eckenfels [EMAIL PROTECTED] said:
BUT: i realy do think each game MUST offer the non sgid option. We
could have a global question herer:
Hmm. Are you willing then to help modify each game to allow
this to happen? Some changes are quite extensive.
manoj
--
Date: 23 Feb 90 19:01:21 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) format STDOUT = @ @ @ @, $Just, $another,
$Perl, $hacker
. for(Just,another,Perl,hacker){eval\$$_=\$_;;};write;
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: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Well, if you are talking about packages in main, yes. But there are other games that follow policy that are also affected. manoj -- We cannot command nature except by obeying her. Sir Francis Bacon 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: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote: On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote: [...] If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... Of course it would, unless it had a versioned dependency that could not be met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. It does not matter to know in which version the bug will be fixed. What I want for sarge is emacs21 ( = 21.2 ) so if every RC bugs are closed with 21.3 or 21.4, the dependency =21.2 is ok. And what if the version in testing has an RC bug? release-status-sarge says everything is OK. Do we even know which packages in sarge have RC bugs? The last time I looked when you close a bug with an upload to sid it closes it entirely still. So we don't really have a good idea of how many RC bugs exist in sarge, only how many are in sid. Chris
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
On Fri, 1 Aug 2003, Arnaud Vandyck wrote: Adrian Bunk [EMAIL PROTECTED] wrote: [...] [3] http://www.fs.tum.de/~bunk/Debian/freeze Reading the whole Future releases of Debian thread, I thought that the main idea was that Debian need a more 'readable' status for the next stable release. ... While it would be nice to see at a glance how far along the next release is, the proposal doesn't address the real problem of the release cycle being too long... fix that and a more readable status of the next release would be moot. This has been an issue for as long as I can remember (I've been a Debian user since 1.3), creating a permanent testing archive was an attempt to solve it... but it hasn't worked because new software hits testing too fast for testing to stabilize enough to freeze (how long until the KDE packages in testing are a mix of 2.2, 3.1.2, and 3.1.3... two weeks?). I can only see two viable options: freeze at regular intervals and live with whatever happens to be in testing at the time, or extend the flow of packages paradigm all the way to stable. The first is like taking a 1/2 a step backwards (imo), the second requires another archive because testing can not work as both the output of unstable and the input for stable (it could if multiple versions of all packages could exist in the same archive at the same time). - Bruce
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 03:58:13PM -0500, Manoj Srivastava wrote: Hmm. Are you willing then to help modify each game to allow this to happen? Some changes are quite extensive. Hmm.. I am sure the maintainers of the affected packages will ask for help. 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: [PROPOSAL] Debian Release Plan
On Fri, 1 Aug 2003, Chris Cheney wrote: ... Do we even know which packages in sarge have RC bugs? The last time I looked when you close a bug with an upload to sid it closes it entirely still. So we don't really have a good idea of how many RC bugs exist in sarge, only how many are in sid. The BTS needs to adopt a package pool like mentality, where bugs are assigned to a particular version of a package instead of just the package. - Bruce
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote: On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote: And what if the version in testing has an RC bug? release-status-sarge says everything is OK. Do we even know which packages in sarge have RC bugs? The last time I looked when you close a bug with an upload to sid it closes it entirely still. So we don't really have a good idea of how many RC bugs exist in sarge, only how many are in sid. For now, http://ftp-master.debian.org/testing/testing_probs.html is the best idea we've got. -- Colin Watson [EMAIL PROTECTED]
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote: On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote: And what if the version in testing has an RC bug? release-status-sarge says everything is OK. Do we even know which packages in sarge have RC bugs? The last time I looked when you close a bug with an upload to sid it closes it entirely still. So we don't really have a good idea of how many RC bugs exist in sarge, only how many are in sid. Yep. The testing scripts try to guess, but really we have no concrete numbers. It is up to individual maintainers to know whether their package in sarge is releasable. One problem is that they have no reason to speak up if it is not, until the threat of release approaches. Then there is a big rush where everyone says but my package isn't ready. :-/ -- - mdz
Bug#203818: ITP: geeklog -- the ultimate weblog system
Package: wnpp Version: unavailable; reported 2003-08-01 Severity: wishlist * Package name: geeklog Version : 1.3.8 Upstream Author : Tony Bibbs and geeklog community [EMAIL PROTECTED] * URL : http://www.geeklog.net * License : GPLv2 Description : the ultimate weblog system Geeklog is a 'blog', otherwise known as a Weblog. It allows you to create your own virtual community area, complete with user administration, story posting, messaging, comments, polls, calendar, weblinks, and more! It can run on many different operating systems, and uses PHP4 and MySQL. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux davi 2.4.20-mh9 #1 Tue Jun 17 17:37:34 UTC 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 04:45:09PM -0600, Bruce Sass wrote: The BTS needs to adopt a package pool like mentality, where bugs are assigned to a particular version of a package instead of just the package. Hey, man, we're working on it. -- Colin Watson [EMAIL PROTECTED]
Bug#203820: Incorrect expanding [] glob
Package: bash Version: 2.05b-8.1 Severity: normal Hello When LC_COLLATE is set to pl_PL [] glob does not work correctly: [EMAIL PROTECTED]:/tmp/bash-test$ echo $LC_COLLATE pl_PL [EMAIL PROTECTED]:/tmp/bash-test$ touch a b C c D e F G h [EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z] b c C D e F G h [EMAIL PROTECTED]:/tmp/bash-test$ export LC_COLLATE=C [EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z] C D F G I am not sure that this is really bash error, that's why I Cc-ed it to [EMAIL PROTECTED] I didn't generate other language locales so I cannot test this error for it. Maybe people on debian-devel could give a feedback about it. I have locales version 2.3.1-17. This bug is also in woody. Packages' versions: ii bash 2.05a-11 The GNU Bourne Again SHell ii locales2.2.5-11.5 GNU C Library: National Language (locale) da Regards Artur -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux zlom 2.4.21 #1 Tue Jul 15 02:03:36 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=pl_PL Versions of packages bash depends on: ii base-files3.0.9 Debian base system miscellaneous f ii libc6 2.3.1-17 GNU C Library: Shared libraries an ii libncurses5 5.3.20030719-1 Shared libraries for terminal hand -- no debconf information
Re: setuid/setgid binaries contained in the Debian repository.
I demand that Stephen Frost may or may not have written... [snip] and a consensus reached which approves of the application and it's needs. ? Almost: s/'// :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | I don't ask for much, just untold riches... i Invalid device, 0:1
