Bom dia debian-devel
Title: FRAGRÂNCIAS FAMOSAS FRAGRÂNCIAS FAMOSAS? Azzaro, Dolce & Gabbana, Angel, Pólo, Armani, Chanel 5, Gabriela Sabatini, Paco, 212, CK One, Bvlgari entre outras 62 fragrâncias diferentes. Preço? Só R$ 31,00 e você ainda recebe em casa. (FRETE GRÁTIS) Home Page: http://igspot.ig.com.br/fator5contratipos Atendimento on-line: ICQ: 178.481.806 TELEFONE (014) 424.9215 Messenger/MSN- [EMAIL PROTECTED] Conheça a maior linha de Perfumes Contratipos do Brasil. Distribuidor Autorizado - FATOR5 Perfumes Contratipos Importados Contratipos, são perfumes novos, desenvolvidos a partir de um original importado. Nossos Contratipos são fabricados com matéria prima importada, essência de primeira linha, que garantem qualidade sem concorrência no Brasil. NOTA: Seu endereço eletrônico foi extraído de mensagens que chegaram a minha caixa postal, através de mensagens enviadas por amigos, clientes e outros contatos em comum. Se o recebimento desta mensagem lhe causa qualquer tipo de inconveniência, peço que a desconsidere, e que responda este e-mail com o título REMOVER, para que possa excluir seu endereço de minha relação pessoal, e não mais importuná-lo(a). Obrigado pela atenção.
Re: Release-critical Bugreport for April 4, 2003
On Fri, 4 Apr 2003, BugScan reporter wrote: > Package: xshipwars-server (debian/main) > Maintainer: Adam Majer <[EMAIL PROTECTED]> > 150411 [P ] xshipwars-server: POSIX shell incompatibilities > 173966 [ ] xshipwars-server: won't uninstall unless the server is > running! This package has is taged patch to one bug and in fact includes another patch in the text of the other bug which is tagged pending. Moreover it contains an offer from Colin Watson to sponsor the package from half a year ago. I guess someone should hijack the package. Moreover it would be worth thinking about switching to a more recent upstream version - even if this is tagged development. Hey, it is a game. Kind regards Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote: > This package has is taged patch to one bug and in fact includes another > patch in the text of the other bug which is tagged pending. Moreover > it contains an offer from Colin Watson to sponsor the package from > half a year ago. I guess someone should hijack the package. Moreover I was sponsoring it previously and I'm still willing to do so. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpGGVbVRJjVw.pgp Description: PGP signature
Re: Release-critical Bugreport for April 4, 2003
On Fri, 11 Apr 2003, Mark Brown wrote: > > This package has is taged patch to one bug and in fact includes another > > patch in the text of the other bug which is tagged pending. Moreover > > it contains an offer from Colin Watson to sponsor the package from > > half a year ago. I guess someone should hijack the package. Moreover > > I was sponsoring it previously and I'm still willing to do so. Could you please be so kind to ask the maintainer whether he want to continue maintaining? Kind regards Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: Release-critical Bugreport for April 4, 2003
On Fri, 4 Apr 2003, BugScan reporter wrote: > Package: xscreensaver (debian/main) > Maintainer: Karl Ramm <[EMAIL PROTECTED]> > 171772 [ ] Alarm clock error > 180063 [ ] xscreensaver: exit on X Error after any authentication > attempt Xscreensaver has a lot of bugs tagged pending, a lot of "fixed in NMU" but not closed bugs and moreover a new upstream version which might perhaps fix something. Moreover I wonder if I'm correct if suspect that the files /usr/share/xscreensaver/config belong to /etc because it might be possible to change these xml files to influence the behaviour of the hacks so they are configuration files. I did not investigated deeply here but someone with more xscreensaver experience might perhaps check this. This would be another release critical but easy to fix bug. Anybody wants to care about this package? Kind regards Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: ocaml compiled binaries and rpath
On Thu, Apr 10, 2003 at 10:56:34PM +0200, Martin Pitt wrote: > Hi! > > I'm just packaging planets (#187988) which is written in ML and > compiled with ocaml. The problem is that the ocaml linker uses the > rpath feature (i. e. hardcoded libary paths). Yes, it does ... > It seems to be against Debian policy to use rpath; on the other hand, > the ocaml linker does not seem to allow disabling it (at least the > documentation says nothing about this issue). Well, see the huge flamewars about this on debian-mentors some time back. It didn't resulted in any conclusive result though. > lintian says: > > W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets > /usr/lib:/usr/X11R6/lib > N: > N: The binary or shared library defines the `RPATH'. Usually this is a > N: bad thing. Most likely you will find a Makefile with a line like: > N: gcc test.o -o test -Wl,--rpath > N: or > N: gcc test.o -o test -R/usr/local/lib > N: Please contact debian-devel@lists.debian.org if you have questions > N: about this. Just ignore it or add a override. > Does anybody know whether it's possible to avoid that? If not, it is > just a warning, so how bad it would be just to ignore it? Well, as ocaml packager, i would vote for letting it like that, as said, there are argument for both solutions, and i prefer to let things like upstream does it (be it only for compatibility with other non-debian related packages). That said, i thought that this kind of problem only occured with library packages using C binding stub libs. I will try to have a look at your package this evening, if you give me a pointer to it. That said : 1) have you read the ocaml packaging policy in /usr/share/doc/ocaml ? 2) There is a debian-ocaml-maint mailing list that is maybe more suited to discusing things related to packaging ocaml stuff, and i will CC this mail there, where you may want to subscribe if you are going to maintain ocaml related stuff. Friendly, Sven Luther
Re: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 10:03:50AM +0200, Andreas Tille wrote: > Could you please be so kind to ask the maintainer whether he want to > continue maintaining? Will do. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote: > On Fri, 4 Apr 2003, BugScan reporter wrote: > > Package: xshipwars-server (debian/main) > > Maintainer: Adam Majer <[EMAIL PROTECTED]> > > 150411 [P ] xshipwars-server: POSIX shell incompatibilities > > 173966 [ ] xshipwars-server: won't uninstall unless the server is > > running! > > This package has is taged patch to one bug and in fact includes another > patch in the text of the other bug which is tagged pending. Moreover > it contains an offer from Colin Watson to sponsor the package from > half a year ago. I guess someone should hijack the package. Hold it for a bit, please. I've been talking to the maintainer privately for the last week. An upload is waiting until the new libjsw is accepted. -- Colin Watson [EMAIL PROTECTED]
Re: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 10:13:01AM +0200, Andreas Tille wrote: > Moreover I wonder if I'm correct if suspect that the files > > /usr/share/xscreensaver/config > > belong to /etc because it might be possible to change these xml files > to influence the behaviour of the hacks so they are configuration > files. I don't think that's a valid general argument. It's possible to change, for example, the files in /usr/share/groff/current/tmac so that groff behaves differently in useful ways, but that doesn't mean I'm going to make them configuration files and therefore implicitly support this configuration. Some things may be regarded as code changes even if it happens that they can be done in files that are more or less plain text. > I did not investigated deeply here but someone with more xscreensaver > experience might perhaps check this. This would be another release > critical but easy to fix bug. "foo is not as configurable as it should be" is a wishlist bug, not a release-critical bug. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bom dia debian-devel
Putz piada essa msg aqui né This lists isn't for marketing! On Thu, 10 Apr 2003 22:18:13 "Alexandre Venturini " <[EMAIL PROTECTED]> wrote: > FRAGRÂNCIAS FAMOSAS > > FRAGRÂNCIAS FAMOSAS? > > > > Azzaro, Dolce & Gabbana, Angel, > > Pólo, Armani, Chanel 5, Gabriela Sabatini, > > Paco, 212, CK One, Bvlgari > > entre outras 62 fragrâncias diferentes. > > > > > > > > > > Preço? > > Só R$ 31,00 e você ainda recebe em casa. > > (FRETE GRÁTIS) > > > > Home Page: http://igspot.ig.com.br/fator5contratipos > http://igspot.ig.com.br/fator5contratipos > > > > Atendimento on-line: ICQ: 178.481.806 > > > > TELEFONE _ (014) 424.9215 > > > > Messenger/MSN- mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] > > > > > > Conheça a maior linha de Perfumes Contratipos do Brasil. > > > > > > Distribuidor Autorizado - FATOR5 Perfumes Contratipos Importados _ > Contratipos, são perfumes novos, desenvolvidos a partir de um original > importado. Nossos Contratipos são fabricados com matéria prima importada, > essência de primeira linha, que garantem qualidade sem concorrência no Brasil. > > > > > > NOTA: Seu endereço eletrônico foi extraído de mensagens que chegaram a minha > caixa postal, através de mensagens enviadas por amigos, clientes e outros > contatos em comum. Se o recebimento desta mensagem lhe causa qualquer tipo de > inconveniência, peço que a desconsidere, e que responda este e-mail com o > título REMOVER, para que possa excluir seu endereço de minha relação pessoal, > e não mais importuná-lo(a). Obrigado pela atenção. > > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of > "unsubscribe". Trouble? Contact [EMAIL PROTECTED] .''`. Rodrigo Tadeu Claro (rlinux) : :' : Debian-SP - irc.freenode.net - #debian-sp `. `'` email - [EMAIL PROTECTED] `-www.rodrigoclaro.cjb.net ->> UIN168799234 -- Linux User Registered #301748 Debian-BR User #504 GPGkey ID D33084F2 -->> http://www.keyserver.net Duvidas sobre Debian? Visite o Rau-tu do CIPSGA: http://rautu.cipsga.org.br pgpDleqBiUISf.pgp Description: PGP signature
Re: /run and read-only /etc
* Jeremy Jackson <[EMAIL PROTECTED]> [030410 23:59]: > Can someone point me the message(s) discussing /run (and why not > /etc/run) - I would like to think that adding another directory off / > should be avoided. /etc/run sounds nice, unless you want to support > booting before /etc is mounted... On the one hand we try to catch the spirit of the FHS. Those things have nothing to do with configuration nowadays considered content of /etc. The things to be moved out of /etc are there because staying in historic places due to lack of better place (like /etc/mtab), crude hacks to get unsupported things more-or-less working (like non-static nameservers) or are already breaking FHS and thus policy(like /etc/printcap.cups). Some of those things have no other place, as they are state-information needed before /var/run is accessable, thus the new directory. On the other hand, keeping different things sperate will also help our users. (Imaging a rule "/etc if for configuration except /etc/run, thus only tar the rest of /etc, if you want to restore your configuration later easily). There is a reason, why we have "/home" instead of "/usr/home[s]". Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
Package: wnpp Version: N/A; reported 2003-04-11 Severity: wishlist * Package name: exim-mysql Version : 3.36 Upstream Author : Mark Baker <[EMAIL PROTECTED]> (debian exim upstream) * URL : http://www.exim.org/ * License : GPL Description : An MTA (Mail Transport Agent) with mysql backend support. I already packaged with one (exim compiled with mysql and tls support). I needed it personally, with the provided debian exim package a recompile is necessary to use a mysql backend. debian package mirror: http://draenor.its-toasted.org/~phil/deb-pkgs distribution: unstable component: unofficial -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux draenor 2.4.20-586tsc #1 Mon Jan 13 21:37:44 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Bug#173966: Release-critical Bugreport for April 4, 2003
On Fri, 11 Apr 2003, Colin Watson wrote: > Hold it for a bit, please. I've been talking to the maintainer privately > for the last week. An upload is waiting until the new libjsw is > accepted. Thanks Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: Debian for x86-64 (AMD Opteron)
* Daniel Jacobowitz <[EMAIL PROTECTED]> [030410 22:52]: > > What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit > > legacy stuff (note the slash). > > > > Ofcourse, they'll get the rpath thing wrong and commercial applications > > are going to insist on /lib64, shiver. > > Well, it's written into the ABI documentation for at least a few > platforms now, so it's a bit late to do anything about it :( I think however it is implemented, it will open a whole can of worms. Also note the mess the move of sparc64 from */lib/64 to */lib64 caused to woddy. (one needs a "dpkg -r libc6-sparc64 libgcc1 libstdc++3 gcc-3.0 fakeroot && apt-get -u upgrade && apt-get install fakeroot" and perhaps some additional "dpkg --configure -a" if one missed something in between to upgrade to a new glibc. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Bug#188569: ITP: common-lisp-devel -- Metapackage for Common Lisp development
Package: wnpp Version: N/A; reported 2003-04-11 Severity: wishlist * Package name: common-lisp-devel Version : 1.0 Upstream Author : Kevin Rosenberg <[EMAIL PROTECTED]> * URL : [ No yet written ] * License : BSD Description : Metapackage for Common Lisp development I received an e-mail from a Debian user who (correctly) states that Debian is the premier platform for Common Lisp development. He requested a metapackage such as common-lisp-devel which will depend on -- at least CL implementation and suggest others -- all CL source packages -- all CL tools and documentation That's about 90 binary packages. Before working on such a package, I'd like to solicit feedback from others if they thinks this is a good idea. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux tiger 2.4.20 #3 SMP Sat Mar 22 13:03:46 MST 2003 i686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Re: Bom dia debian-devel
On Fri, Apr 11, 2003 at 06:38:23AM -0300, Rodrigo Tadeu Claro wrote: > Putz piada essa msg aqui n? > > This lists isn't for marketing! 1) Please don't reply to spam. 2) If you must reply to spam, please don't quote the whole thing! -- Colin Watson [EMAIL PROTECTED]
Re: >2000 packages still waiting to enter testing, > 1500 over age
Josip Rodin <[EMAIL PROTECTED]> writes: > On Wed, Apr 09, 2003 at 12:54:34PM +0200, Petter Reinholdtsen wrote: >> I suggest we remove packages which haven't entered testing after more >> more then 300 days. > > Packages can be stuck out of testing due to their dependencies, so 300 days > of lag only indicates a serious problem with a package, it does not > automatically imply it. I suggest you spend time fixing stuff on a case by > case basis, rather than make sweeping generalizations :) Packages can also be stuck out of testing due to bugs filed specially to keep the packages out of testing. Frankly, this is not done often enough, many of the -snap or -devel packages (where is a released stable version of the package and the former are development versions, mostly pulled from cvs, sometimes even daily) should stay in unstable, or at least never be put in stable. If the -snap or -devel packages really are more stable than their counterparts, the former should be removed and the latter upgraded to the -snap or -devel version.
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri Apr 11, 11:47am +0200, Philipp Kern wrote: > * Package name: exim-mysql > Version : 3.36 > > I already packaged with one (exim compiled with mysql and tls support). > I needed it personally, with the provided debian exim package a > recompile is necessary to use a mysql backend. > debian package mirror: http://draenor.its-toasted.org/~phil/deb-pkgs > distribution: unstable > component: unofficial For what it's worth, exim4-daemon-heavy includes MySQL support; this package isn't in the archive yet, I grabbed it from q.bofh.de at some point, and that's stopped working. The package was from a team working on exim 4.x packaging, presumably it'll be uploaded to the archive eventually (though "eventually" may be far enough into the future to warrant this package, given how slow they're going at it). pgpydj4zb7MyI.pgp Description: PGP signature
Bug#188574: ITP: libcommons-dbcp-java -- short description
Package: wnpp Severity: wishlist * Package name: libcommons-dbcp-java Version : 1.0 Upstream Author : Jakarta Apache group * URL : http://jakarta.apache.org/commons/dbcp/ * License : Apache Software License Description : Database Connection Pooling Services Depends on libcommons-pool-java and can be interresting with Tomcat to use the jdbc connection pooling (simply add symlinks from the two libs to /usr/share/tomcat4/commons/lib... it works for me :-)) I put it in Section: contrib/libs Sources.list: deb http://vbstefi60.fapse.ulg.ac.be/~arnaud/debian ./ deb-src http://vbstefi60.fapse.ulg.ac.be/~arnaud/debian ./ Regards, -- Arnaud Vandyck @ work FingerPrint = 82F3 45D0 F1B2 D79E D0BE 5188 E2FC C566 EEB6 B4C2 pgpKcJZu5KJrE.pgp Description: PGP signature
Re: Bug#188307: ITP: gpdf -- GNOME pdf viewer
On Wed, Apr 09, 2003 at 11:08:56PM +0200, Filip Van Raemdonck wrote: > On Thu, Apr 10, 2003 at 12:32:48AM +1000, Hamish Moffatt wrote: > > I was surprised that neither of you contacted me as Xpdf maintainer, > > Hmm, well. I've yet to take a closer look at how much gpdf & xpdf source > are alike; I only just decided gpdf was usable enough when I ITPed. The CVS logs show lots of recent imports of Xpdf 2.02 code, so I'd say it's pretty similar. > Gpdf is just one binary, and some GNOME specific support files. > It doesn't have (it would be stupid to do so) any of the xpdf utilities. > Nor does it need say xpdf-common installed to work, it's standalone. And Does it not support the Xpdf language handling? eg the files in /usr/share/xpdf, /etc/xpdf etc. This seems to be pretty important to many Debian users. > There just isn't anything useful yet IMO at this point to contact you > about. Simple as that. OK, if you think so. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri, Apr 11, 2003 at 11:47:23AM +0200, Philipp Kern wrote: > * Package name: exim-mysql [...] > I already packaged with one (exim compiled with mysql and tls support). > I needed it personally, with the provided debian exim package a > recompile is necessary to use a mysql backend. [...] Build-Depends: [...] libmysqlclient-dev, libssl-dev |-- | http://www.mysql.com/doc/C/o/Copyright.html as of 2002-07-20: | |1.4.2 Copyrights and Licenses Used by MySQL | [...] | 1. All the MySQL-specific source in the server, the mysqlclient |library and the client, as well as the GNU readline library is |covered by the GNU General Public License. See section [26]H GNU |General Public License. The text of this license can also be found |as the file `COPYING' in the distributions. |-- You cannot distribute this, GPL and OpenSSL licenses are incompatible. http://pkg-exim4.alioth.debian.org/ cu andreas
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri Apr 11, 02:25pm +0200, Andreas Metzler wrote: > http://pkg-exim4.alioth.debian.org/ Ack, sorry, I didn't realise you guys were uploading to experimental now :) pgp5PKNAFgS4V.pgp Description: PGP signature
Re: Fakeroot to obsolete DESTDIR
Hi, On Thu, 10 Apr 2003 12:26:38 +, Wesley W. Terpstra wrote: > What I propose to do is to slightly extend fakeroot to also intercept > open/diropen. If the open call would create a file, redirect it to > /.../debian/tmp or some such location. If the call would open a file, > first check /.../debian/tmp and then /. > This breaks for any installer which checks if the new file and the old file are different before replacing the old file. > To illustrate this, lets take an example: (here libbar depends on > libfoo) > Library dependencies may or may not be resolved using the open() call from a preloaded library. (Actually, I think they aren't. Did you check?) Personally I would NOT depend on it, regardless of whether it currently works or not. WRT the patch size, I suggest that $DESTDIR is needed for things other than Debian packages. Examples: RPM packaging. Installing onto AFS volumes. Therefore the "large diff" is going to be accepted into the next upstream release, given a reasonably reasonable upstream author. IMHO, maintainers who package stuff from non-reasonable upstreams typically have worse problems than adding $DESTDIR to a few places... -- Matthias -- The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
Andreas Metzler wrote: > Build-Depends: [...] libmysqlclient-dev, libssl-dev > [license snipped] > You cannot distribute this, GPL and OpenSSL licenses are incompatible. So how you exim4 guyes managed to get around that? By the use of gnutls? If yes I'll switch to that one IF I continue exim-mysql for myself. bye
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
David Pashley told me: > This is wrong. Philip Hazel is the upstream author. Mark Baker is the > maintainer for the exim packages. I suggest you talk to Mark and talk to > people on the exim4 mailing list, [EMAIL PROTECTED] (CCed). Ok, but because I didn't know the correct one I wrote "debian exim upstream" because I did previously copy his package and modified it. Corrected in next "release". > There is exim4 in experimental and they will be moved into sid in the > near future. There is a package with all the DB lookups compiled in. You > may want to look at that. Alternatively, you may want to create a > package with as many of the lookups that you can like pgsql. There is no > point in having an exim, exim-mysql, exim-pgsql etc packages. You may > want to call the package something like exim-heavy. I'll look into exim4 configuration syntax and things like that as soon as possible (when I got time, probably at the weekend). The problem is that I don't know pgsql and I originally wanted a package for 3.36 with mysql compiled in. A heavy package would force me to compile in ldap,pgsql,nis etc. and that would require the "end-user" to install packages he wouldn't need normally for running such a daemon. If exim would have shared modules I would agree with you, I also see your point of the load of packages this would lead to, but e.g. exim4-daemon-heavy doesn't even depend on mysql, but pgsql, and other things users would probably never be using like ldap. If there's somebody who could propose a better solution (probably apart from creating a heavy daemon or upgrading to exim4) I would like to hear it :) But as I said I'll look into exim4 debian packages if it would suit for me. Thanks for listening, phil
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
* David B Harris ([EMAIL PROTECTED]) [030411 13:05]: > On Fri Apr 11, 11:47am +0200, Philipp Kern wrote: > > * Package name: exim-mysql > > Version : 3.36 > > > > I already packaged with one (exim compiled with mysql and tls support). > > I needed it personally, with the provided debian exim package a > > recompile is necessary to use a mysql backend. > > debian package mirror: http://draenor.its-toasted.org/~phil/deb-pkgs > > distribution: unstable > > component: unofficial > For what it's worth, exim4-daemon-heavy includes MySQL support; this > package isn't in the archive yet, I grabbed it from q.bofh.de at some > point, and that's stopped working. They are in experimental, see http://packages.debian.org/cgi-bin/search_packages.pl?keywords=exim4&searchon=names&subword=1&version=all&release=all At q.bofh.de are still backports to woody that work fine, also under testing. (And at least the backports are really usable and have a _very_ nice configuration setup. I can't say anything about experimental, as I haven't tried them yet.) Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: Debian for x86-64 (AMD Opteron)
Hi,
On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thursday 10 April 2003 16:43, Emile van Bergen wrote:
>
> > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
>
> > >
> > > # echo x86-64 >> /etc/dpkg/legal-archs
> > > # dpkg -i libgtk2-2.0-1_i386.deb
> > > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> >
> > libssl0.9.6-0.9.6c-2_i386.deb or
> > libssl0.9.6-0.9.6c-2_i686.deb;
> >
> > on a x86-64 you'd have the choice between those same two plus
> >
> > libssl0.9.6-0.9.6c-2_x8664.deb
>
> These two proposals have a significant difference. The first one
> needs more changes to the individual library packages because it
> changes not only the file names but also the package names. I'm
> not sure how to best handle dependencies on this.
Simple: explicitly. I don't think it'd be a good idea to allow 32-bit
apps to link to 64-bit libraries and vice versa. How would you layout
the (shared) address space? Handling all cases would become a mess
quickly.
You do want to allow both 32-bit and 64-bit versions of libraries to be
installed, for which you need different package names; you want to avoid
adding fields to a package's "primary key", so that the dependency tree
assmebly mechanisms can be left as they are.
> The second proposal would mean that dpkg will have to be changed
> so it can install the same package for both x8664 and {i386,i686}
> at the same time, which could prove difficult. The dependencies
> here can basically stay the same (e.g. ssh will continue to
> depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
> to know about an additional dimension concerning dependencies, e.g.:
That is exactly what Wichert wanted to avoid. I'm sorry, you probably
got this idea because of a most unfortunate typo of mine in the last
.deb I mentioned; I meant lib64ssl0.9.6-0.9.6c-2_x8664.deb there.
There are two distinct issues I wanted to illustrate:
1. different package name (for 64 bits), different architecture,
more than one architecture allowed by dkpg: allows 32-bit and 64-bit
versions of packages to coexist; allows (64-bit) machines to install
packages from compatible (32-bit) architectures. This was Wichert's
idea.
2. same package name, different "architecture", more than one
architecture allowed by dpkg: solves CPU optimized libraries in
a transparent way; no changes to dependencies necessary. This is what
Wichert's suggested extension to dpkg would allow when using the same
package name.
Hope it's clear now.
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
pgpEKvXwn6hs9.pgp
Description: PGP signature
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri, Apr 11, 2003 at 03:14:37PM +0200, Philipp Kern wrote: > Andreas Metzler wrote: >> Build-Depends: [...] libmysqlclient-dev, libssl-dev >> [license snipped] >> You cannot distribute this, GPL and OpenSSL licenses are incompatible. > So how you exim4 guyes managed to get around that? > By the use of gnutls? If yes I'll switch to that one IF I continue > exim-mysql for myself. Yes, exim4 uses GnuTLS. I do not know whether GnuTLS' openssl compability layer is "god enough" for exim v3, exim v4 supports GnuTLS natively. cu andreas
Re: Suggestions accepted
Hello, On Thu, Apr 10, 2003 at 11:52:44PM -0300, Rodrigo Tadeu Claro wrote: > Hello! > > I'm going to do it with name gtk-fm. IMHO, gtk-* should be reserved to packages that are part of the GTK project, or at least closely tied with it. To me foo-bar implies that this packages is the bar part from foo like in bind9-doc or libnss-db. For gtk-fm, dropping the dash (gtkfm), like it has been done for many packages (gtkterm, gtksql, ...), seems more appropriate. Maybe some guidelines should be included in section 6.2 of the developper's reference, so there is consistency in package naming. -- Jeremie Koenig <[EMAIL PROTECTED]>
Re: SASL/LDAP/DB dependency hell.
> > I could not convince libpng maintainers to use versioned symbols because > > they were apparently not available on AIX and Windows. > > AIX is an ancient PoS. And Windows, well... :) > > Symbol versioning is something that can be turned on and off where it is > available. Not using it because "foo" doesn't support it makes no sense. AS > FAR AS you write the detection code... The question was that whether libdb4.1 was safe to be linked alongside with libdb2, and the answer is yes. What AIX or Windows are, or what makes sense is a different question :) regards, junichi
Database-specificisms considered harmful
Hi, > * Package name: exim-mysql Personally, I do not like all those -mysql, -pgsql, -whatever packages. Whatever happened to the idea of using a common database access library like iODBC? It's reasonably small, Not A Burden if you happen to not require any database lookup features, and it doesn't bloat the archives with four versions of exim (-none, -mysql, -pgsql, and -kitchensink). Personally, I would consider adding an appropriate paragraph to Policy. Something along the lines of * Programs which access SQL databases should do so through libgda2/unixodbc/???. ... assuming that we can reach some sort of consensus on which library should be used..? -- Matthias -- Well, I think Perl should run faster than C. :-) -- Larry Wall in <[EMAIL PROTECTED]>
Re: fakeroot with chroot.
> > > http://people.debian.org/~dexter/fakeroot/ > > > > > > Have a good fun! > > > > > Nice. Very nice. Will you put that into the official fakeroot? > > I really don't know. The fakeroot is not my project and I'm afraid my > patches are too experimental for such stable tool. Also there is too much > work with cleaning up the code. Should I start new project or join to the > original fakeroot? I once tried to do something similar, but noticed that user-mode-linux does the same thing to a fuller extent. If you look at it this way, user-mode-linux is a fakeroot that traps all syscalls. regards, junichi
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri, Apr 11, 2003 at 03:30:38PM +0200, Andreas Barth wrote: > They are in experimental, see > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=exim4&searchon=names&subword=1&version=all&release=all Rather than the obscenely ugly URL like that, use the convenient http://packages.debian.org/exim4 The rewrite rules exist for the very purpose of accomplishing this :) -- 2. That which causes joy or happiness.
Re: fakeroot with chroot.
On Fri, Apr 11, 2003 at 11:50:20PM +0900, Junichi Uekawa wrote: > > I really don't know. The fakeroot is not my project and I'm afraid my > > patches are too experimental for such stable tool. Also there is too much > > work with cleaning up the code. Should I start new project or join to the > > original fakeroot? > > I once tried to do something similar, but noticed that > user-mode-linux does the same thing to a fuller extent. > > If you look at it this way, user-mode-linux is a fakeroot that traps > all syscalls. And provides a completely separate process table, and fake block devices, and... -- - mdz
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri, Apr 11, 2003 at 03:30:38PM +0200, Andreas Barth wrote: [exim4] > At q.bofh.de are still backports to woody that work fine, also under > testing. (And at least the backports are really usable and have a > _very_ nice configuration setup. I can't say anything about > experimental, as I haven't tried them yet.) The backports on q.bofh.de are outdated, please use the ones on http://www.logic.univie.ac.at/~ametzler/debian/exim4manpages/woody/ instead. cu andreas
Re: Release-critical Bugreport for April 11, 2003
On Fri, Apr 11, 2003 at 07:13:48AM -0500, BugScan reporter wrote: > > Package: airsnort (debian/main) > Maintainer: Noel Koethe <[EMAIL PROTECTED]> > 167901 [ ] [S] Unfullfilable Depends: prevents the package from > working (and Depends: not properly setup) That bug only applies to woody, I don't see why it should be RC. > > Package: doc-rfc (debian/main) > Maintainer: Kai Henningsen <[EMAIL PROTECTED]> > [REMOVE] > 92810 [ ] doc-rfc: license is not DFSG-free This package should _not_ be REMOVED, it should be moved to non-free. Also, notice that the bug reports lists a number of packages who include RFCs in the distribution. Thus, it not only applies to doc-rfc, but to some other packages as well. > Package: doc-rfc-std (debian/main) > Maintainer: Kai Henningsen <[EMAIL PROTECTED]> > [REMOVE] > 111218 [ + ] Cannot install/remove There's a patch to fix this issue and it has been pending for quite some time. Would a NMU be ok? > Package: mozilla-locale-es-es (debian/main) > Maintainer: Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]> > 176874 [P H] mozilla-locale-es-es is not installable in unstable I will fix this one after I came back from vacation. >Package: plptools (debian/main) >Maintainer: John Lines <[EMAIL PROTECTED]> >[REMOVE] > 178981 [ S ] [EMAIL PROTECTED]: Local root vuln in SuSE >8.0 plptools package] > >Package: plptools-kde (debian/main) >Maintainer: John Lines <[EMAIL PROTECTED]> > 173345 [ ] undeclared dep on kdelibs-dev I _think_ I have this issues solved. I've sent a patch and will probably do a NMU in the near future. Hugo Espuny (hec) will test these packages in his Psion. Regards Javi pgpvcCWpUkwjS.pgp Description: PGP signature
Re: Release-critical Bugreport for April 11, 2003
On Fri, Apr 11, 2003 at 05:29:56PM +0200, Javier Fernández-Sanguino Peña wrote: > On Fri, Apr 11, 2003 at 07:13:48AM -0500, BugScan reporter wrote: [...] > > Package: doc-rfc-std (debian/main) > > Maintainer: Kai Henningsen <[EMAIL PROTECTED]> > > [REMOVE] > > 111218 [ + ] Cannot install/remove > > There's a patch to fix this issue and it has been pending for quite some > time. Would a NMU be ok? [...] Imho yes. A more than a year old RC bug without reaction from the maintainer is a prime candidate for NMU. cu andreas
Bug#188608: ITP: xmms-speex -- Speex speech codec - XMMS input plugin
Package: wnpp Version: unavailable; reported 2003-04-12 Severity: wishlist * Package name: xmms-speex Version : 0.6.0 Upstream Author : Jens Burkal <[EMAIL PROTECTED]> * URL : http://jzb.rapanden.dk/speex * License : GPL Description : Speex speech codec - XMMS input plugin Ogg Speex is an audio codec designed for speech recordings. It can go down to very low bit rates (on the order of 16Kbps) while remaining intelligible. . This package contains an XMMS input plugin for Speex files. For a command line encoder and decoder, have a look at the `speex' package. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux thebox 2.4.20ck3+skas #1 Tue Feb 25 01:23:43 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Rob Weir <[EMAIL PROTECTED]> http://www.ertius.org/ GPG keys: 1024D/1E73B7CD, 4096R/3ABDE5EC | Do I look like I want a CC? Words of the day:dictionary Mafia counter intelligence event security sweep pgpyrxwYZy3SO.pgp Description: PGP signature
Re: Bug#150411: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 10:27:06AM +0100, Colin Watson wrote: > On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote: > > On Fri, 4 Apr 2003, BugScan reporter wrote: > > > Package: xshipwars-server (debian/main) > > > Maintainer: Adam Majer <[EMAIL PROTECTED]> > > > 150411 [P ] xshipwars-server: POSIX shell incompatibilities > > > 173966 [ ] xshipwars-server: won't uninstall unless the server is > > > running! > > > > This package has is taged patch to one bug and in fact includes another > > patch in the text of the other bug which is tagged pending. Moreover > > it contains an offer from Colin Watson to sponsor the package from > > half a year ago. I guess someone should hijack the package. Yo, what's the dillio? At least *ask* me if I'm still here! :) Both bugs are trivial and xshipwars wouldn't be going anywhere anyway because lijsw has to get fixed (it is a C library compiled as C++ library - for why look at the orig.tar.gz files). If you want to hijac a package, look at some of the O: packages that need to get picked up. > Hold it for a bit, please. I've been talking to the maintainer privately > for the last week. An upload is waiting until the new libjsw is > accepted. As he said :) - Adam
Re: fakeroot with chroot.
Piotr Roszatycki wrote: > I really don't know. The fakeroot is not my project and I'm afraid my > patches are too experimental for such stable tool. Also there is too much > work with cleaning up the code. Should I start new project or join to the > original fakeroot? Start a fakechroot project :) I have tested it, and it is really nice. I would be very interested to be able to run a kind of pbuilder without needing root access. AFAIK user-mode-linux require root access to set up the network to have network access under uml. Next step is of course to port it to other distros, so that we can build Debian packages on them. > I'd like to make "/proc" directory transparent for chroot-ed environment. > It would be possible to use pstools. Another idea? Use the real /proc ? Or I missed something. Suppose a fakechroot in /fake/. In the fake chroot, /usr refer to /fake/usr. I would like the possibility to specify that some directories most not have /fake prepended by fakechroot: that /proc in the fake chroot refer to the real /proc not /fake/proc, for example. This can also be useful for /dev, etc... Cheers, -- Bill. <[EMAIL PROTECTED]> Please CC me!
Re: Upcoming removal of orphaned packages
Will these packages will still be available through archive.d.o or will they be purged from there as well? Joe Nahmias, DD wannabe Martin Michlmayr wrote: > There are currently about 200 orphaned packages, many of which have been > on WNPP for quite a long time and some with RC bugs. I intend to request > the removal of the following packages in two weeks unless a package has > been adopted by someone until then. If you want to keep one of the > following packages, please make sure to > - change the title of the bug from O: to ITA: as described on > http://www.debian.org/devel/wnpp > - make an upload to the archive, change the Maintainer: field to you, > fix as many bugs as possible, also check for new upstream releases, > etc. > - Make sure to close the WNPP bug in your upload. > > If you cannot make an upload for some reason (e.g., you need a sponsor), > then contact me privately. However, unless there is a good reason, an > upload should happen within the next 2 weeks. > # The rules: > # * All packages orphaned less than 90 days ago will be kept! > # * Ignore all bugs less than 30 days old. > # otherwise: > # * Packages with RC bugs will be removed. > # * Packages orphaned 180 days ago and with NMUed RC bugs will be removed. > # * Packages orphaned with a Standards-Version less than 3.0 (which > # would be a RC bug anyway) will be removed. > # * Packages orphaned more than 360 days ago will be removed in any case.
Re: Upcoming removal of orphaned packages
On Sat, Apr 12, 2003 at 03:06:32AM +1000, Martin Michlmayr wrote: > If you want to keep one of the following packages, please make sure to > - change the title of the bug from O: to ITA: as described on > http://www.debian.org/devel/wnpp > - make an upload to the archive, change the Maintainer: field to you, > fix as many bugs as possible, also check for new upstream releases, > etc. > - Make sure to close the WNPP bug in your upload. > > If you cannot make an upload for some reason (e.g., you need a sponsor), > then contact me privately. However, unless there is a good reason, an > upload should happen within the next 2 weeks. > taper -- Full-screen system backup utility. [#115960] > * Orphaned 541 days ago > > taper -- Full-screen system backup utility. [#115960] > * Orphaned 541 days ago I use taper on a regular basis, but I wouldn't actually have time to maintain it. It does seem to work pretty well, the bugs filed against it are all pretty much easy to work with, and it would be a shame to lose it. So I offer, er, gratitude? to whoever keeps it alive... -- 2. That which causes joy or happiness.
Re: Upcoming removal of orphaned packages
On Fri, 11 Apr 2003, Joe Nahmias wrote: > Will these packages will still be available through archive.d.o or will > they be purged from there as well? archive.d.o stores stable distros, and is never "purged" of packages (although too old releases just might. Depends on the amount of space, I suppose). If the packages ever went in a Debian stable distro, that version won't be purged. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Upcoming removal of orphaned packages
* Joe Nahmias <[EMAIL PROTECTED]> [2003-04-11 13:52]: > Will these packages will still be available through archive.d.o or > will they be purged from there as well? They won't be removed from already released versions of Debian. So if the packages were in potato or woody, they will be available through archive.d.o. (Otherwise, they will be kept in the morgue on auric for a whilw but that's only accessiable for developers.) -- Martin Michlmayr [EMAIL PROTECTED]
Attempting a Debian Install on a Libretto 100CT
The Philadelphia Area Debian Society (PADS) (http://www.CJFearnley.com/pads/) Presents Attempting a Debian Install on a Libretto 100CT When: Wednesday 16 April 2003, 8:00 PM - 9:30 PM Presenter: Mike Leone Where: 4416 Osage, Apartment 20 Philadelphia, PA Thanks to our hosts: Samantha and Fred Ollinger Abstract We will attempt to install Debian on a Libretto 100CT. Installing on this laptop is complicated by the PCMCI-Bridge which isn't recognized after the kernel boots. We will explore options for getting this installed in the hopes that Mike will have Debian on his laptop at the end of the evening. Social Dinner Attendees are invited to gather for dinner prior to the meeting at 6:30 PM at Abyssinia Ethiopian Restaurant, 229 S 45th St, Philadelphia, PA 19104-2918, (215) 387-2424. Please RSVP, so that we can call ahead for reservations. -- Christopher J. Fearnley | LinuxForce Inc. [EMAIL PROTECTED] | Chief Technology Officer http://www.LinuxForce.net | Software Solutions / Systems Management
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 11 April 2003 15:49, Emile van Bergen wrote: > On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote: > > On Thursday 10 April 2003 16:43, Emile van Bergen wrote: > > > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > > > # dpkg -i libgtk2-2.0-1_i386.deb > > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > I'm not sure how to best handle dependencies on this. > > Simple: explicitly. I don't think it'd be a good idea to allow 32-bit > apps to link to 64-bit libraries and vice versa. How would you layout > the (shared) address space? Handling all cases would become a mess > quickly. Right. In case it was not clear to everybody: The ELF format does not specify linking of 32 and 64 objects together, so this is not subject to discussion anyway. > You do want to allow both 32-bit and 64-bit versions of libraries to be > installed, for which you need different package names; you want to avoid > adding fields to a package's "primary key", so that the dependency tree > assmebly mechanisms can be left as they are. Yes, but what I also want to avoid is having to change every single instance of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing them all again for mips64 ;-). What I have in mind is something along the lines of libfoo 'Provides: libfoo(32bit)' lib64foo 'Provides: libfoo(64bit)' bar 'Depends: libfoo($BITSIZE)' I don't know if it's possible to teach dpkg and the other tools about this. And this is only the tip of the iceberg: As Cyrille noted already, the real challenge will be finding a policy for the -dev packages. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lxq+5t5GS2LDRf4RAmHzAKCiqYgXZffN3cqtgF95aFd+rBVLHACfUjOH tje7TlhqQD5ySvSs6bNJwr0= =hmhD -END PGP SIGNATURE-
Re: /run and read-only /etc
(I am resending this because the earlier version contained
a few minor errors. I suppose I should put this on the web
somewhere and post the link.)
(I repeat the call for people to look for files that are in
/etc/ but shouldn't be.)
Here are:
* an updated list of wishes filed,
* an updated TODO suggestion including a TODO for a resolv.conf
management scheme based on Emile's idea,
* a brief rationale for adding /run/,
* and a discussion of some FHS passages that present problems.
The read-only root effort
=
Wish reports filed or updated
* sysvinit
#150355: Please move motd to /var/lib/
#188087: Move ioctl.save out of /etc/
* util-linux
#156489: Please move adjtime out of /etc/
* ppp
#187756: Patch to allow /etc/ to be read-only
* pppconfig
#187810: Please support read-only /etc/
/etc/ppp/ip-up.d/0dns-up and /etc/ppp/ip-down.d/0dns-down
shouldn't create temporary files in /etc/
#187651: Please document how to keep resolv.conf static
* linuxlogo
#187953: Please do not store files in /etc/. Use /var/lib/.
* cupsys
#187954: Move /etc/printcap.cups under /var/
Wishes to be filed (by Jamie Wilkinson) after more testing
I think that the /run/ directory needs to be added before we
can do very much about the resolv.conf problem.
* base-files
Add /run/ directory
* pam, shadow
Allow either /etc/nologin or /run/nologin to prevent nonroot login
* sysvinit:
Touch /run/nologin (not /etc/nologin) when there is a delay
before a shutdown.
* util-linux
Use /run/mtab for mount's statefile
TODO for etc/resolv.conf
Overview
* /etc/resolv.conf -> /run/resolv.conf
* Networking daemon pidfiles go in /run/
* Resolv.conf-like files go in /run/resolver/interfaces/
* DNS cache configuration file fragments go in /run//
* "/etc/init.d/resolver reload" regenerates /run/resolv.conf
and calls DNS cache update scripts in /etc/resolver/update.d/
* libc6
* Create /etc/init.d/resolver script to:
* Do "run-parts /etc/resolver/update.d"
* Write /run/resolv.conf which:
* lists 127.0.0.1 first if some local nameserver is running
* then lists other nameservers from /run/resolver/interfaces/*
* As B. Link and others have noted, this will have to be done
with some care.
* Change postinst to install symlink in rcS.d
* bind
* Create script /etc/resolver/update.d/bind to:
* Write a "forwarders { ... }" statement to
/run/bind/named.conf.options.forwarders containing
the nameserver adresses from /run/resolver/interfaces/*
* Then do "/etc/init.d/bind reload"
* Change the /etc/bind/named.conf.options file to include
/run/bind/named.conf.options.forwarders within the
"options { ... }" statement.
* dnscache
* Something similar
* ppp
* Change /usr/sbin/pppd to:
* Store PID in /run/, not in /var/run/
* Create script /etc/ppp/ip-up.d/resolver to:
* Write the lines:
nameserver $DNS1
nameserver $DNS2
to /run/resolver/interfaces/$PPP_IFACE
* Then call /etc/init.d/resolver reload
* Create script /etc/ppp/ip-down.d/resolver to:
* Delete /run/resolver/interfaces/$PPP_IFACE
* Then call /etc/init.d/resolver reload
* pump
* Add /etc/pump directory
* Change /sbin/pump to:
* Store PID in /run, not in /var/run
* By default, don't write /etc/resolv.conf
* Run /etc/pump/up after configuring interface, furnishing
$IFACE and nameserver addresses $DNS1 and $DNS2
* Add script /etc/pump/up to:
* Write the lines:
nameserver $DNS1
nameserver $DNS2
to /run/resolver/interfaces/$IFACE
* Then call /etc/init.d/resolver reload
* Add script /etc/pump/down to:
* Delete /run/resolver/interfaces/$IFACE
* Then call /etc/init.d/resolver reload
* Move pump.conf under /etc/pump
* dhcp3-client
* Change /sbin/dhclient to:
* By default, store PID in /run, not in /var/run
* Change /etc/dhcp3/dhclient-script to:
* Write resolv.conf information to
/run/resolver/interfaces/$interface not to /etc/resolv.conf
* Then call /etc/init.d/resolver reload
TODO later
* Fix diskless tools
* ifupdown
* Wish that ifstate be moved under /run/network/
* sysvinit
* Add support for mounting / read-only.
* Add support for mounting /run/ as a separate filesystem.
* The patches in #30446 and #186892 should be reviewed
in implementing this.
Rationale for adding /run directory
===
The /var/ hierarchy is for "variable" files -- i.e., files that vary
during normal system operation.
The /var/run/ hierarchy contains variable files that are "unshareable" --
i.e., usable only by one system.
The proposed new directory is for files similar to those
Fwd: ITP: bashish (retitle from RFP) -- theme-engine using bash and other POSIX shells
I meant debian-devel, not [EMAIL PROTECTED] ;) - Mensagem Reenviada de [EMAIL PROTECTED] - Data: Fri, 11 Apr 2003 21:55:40 +0100 De: Bruno David Rodrigues <[EMAIL PROTECTED]> Assunto: ITP: bashish (retitle from RFP) -- theme-engine using bash and other POSIX shells Para: [EMAIL PROTECTED] Original RFP available at bug 182233. * Package name: bashish Version : 1.9.19 Upstream Author : Thomas Eriksson <[EMAIL PROTECTED]> * URL : http://bashish.sourceforge.net/ * License : GPL Description : Theme engine for POSIX shells Bashish is a theme-engine that uses POSIX shells to customize nearly all aspects of the terminal: title, colors, prompt, font, background, etc. . It has a modular design which makes it easy to add features (and it does have a lot) while keeping good performance. . Bashish allows users to switch themes 'on the fly'. Each console application may have it's own theme which automatically gets switched to when the application is started (an alias or function will be created for each themed application). Packages available at [1] I had to add two lintian overrides for a missleading licence file and not liking csh scripting, but this is a package with scripts for [ba]sh and [t]csh and others. PS: I'm CC'ing to devel to simulate the behaviour when it's a new ITP. [1] http://www.litux.org/debian/unstable/Packages.html#bashish -- 21:56:57 up 139 days, 22:10, 7 users, load average: 0.39, 0.29, 0.18 BOFH excuse #238: You did wha... oh _dear_
Re: Work-needing packages report for Apr 11, 2003
I am not currently using anything on the wnpp-list, but it seems to me that not all these packages are better off gotten rid off. Does anyone know something about the importance of these packages? Has/can someone run this against the popularity-contest? My point is that I could prolly adopt a package or two, but have no knowledge or particular interest in what is being offered. On the other hand we should probably take care of the packages we have before we take on new ones, I suppose. I would suspect packages like: exim-tls udhcpd defoma(!) mserver scanmail mnogosearch cadaver phpgroupware pppoeconf pptp-linux to be of some importance. I feel obliged to take responsibility for at least one of them, but - as I said - I use none of them (except for defoma of course). So, do we have some way of separating that which we really want to get rid off from that which unfortuneately has been orphaned? More over I wish to revive the inflammable discussion as to whether or not it would be a good idea to have a section in the archives for unmaintained, much like non-US or non-free. I really think it is the best thing for our users if they can see up front that the package that they are about to install is not necessarily likely to be bugfixed in the foreseeable future. Furthermore if they don't have the skills to fix things themselves, then they just cut of that apt-source. Lars. On Fri, Apr 11, 2003 at 12:32:33AM -0400, [EMAIL PROTECTED] wrote: > Report about packages that need work for Apr 11, 2003 > > Total number of packages offered up for adoption: 63 > Number of packages offered up for adoption this week: 3 > Total number of orphaned packages: 196 > Number of packages orphaned this week: 26 > -- Lars Bahner: http://lars.bahner.com/; Voice: +4792884492; Fax: +4792974492 Key fingerprint = A913 7B54 E5FC 804D C12B 18DE 493D 83DE 5DE6 C5D6
Re: fakeroot with chroot.
On Fri, Apr 11, 2003 at 07:49:20PM +0200, Bill Allombert wrote: > AFAIK user-mode-linux require root access to set up the network > to have network access under uml. No, this is only true for the tuntap transport. The slirp transport, for example, requires no additional privileges, and it is not difficult to envision other approaches to accomplish the same thing. -- - mdz
Re: Debian for x86-64 (AMD Opteron)
Hi, On Fri, Apr 11, 2003 at 09:42:52PM +0200, Arnd Bergmann wrote: > On Friday 11 April 2003 15:49, Emile van Bergen wrote: > > > You do want to allow both 32-bit and 64-bit versions of libraries to be > > installed, for which you need different package names; you want to avoid > > adding fields to a package's "primary key", so that the dependency tree > > assmebly mechanisms can be left as they are. > > Yes, but what I also want to avoid is having to change every single instance > of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, > hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing > them all again for mips64 ;-). You don't need that. Depends: libfoo will just stay Depends: libfoo. No lib64foo will be pulled in, as it has a DIFFERENT PACKAGE NAME. > What I have in mind is something along the lines of > libfoo 'Provides: libfoo(32bit)' > lib64foo 'Provides: libfoo(64bit)' > bar 'Depends: libfoo($BITSIZE)' > I don't know if it's possible to teach dpkg and the other tools about this. I really have lost all clue of what you think is missing from current behaviour. - lib64foo /already/ provides lib64foo. - bar (a binary 64 bit package) can /already/ depend on lib64foo (and not libfoo). What's the problem? Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpbq1ynPSDxN.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 11 April 2003 23:17, Emile van Bergen wrote: > > What I have in mind is something along the lines of > > libfoo 'Provides: libfoo(32bit)' > > lib64foo 'Provides: libfoo(64bit)' > > bar 'Depends: libfoo($BITSIZE)' > > I don't know if it's possible to teach dpkg and the other tools about > > this. > > I really have lost all clue of what you think is missing from current > behaviour. > > - lib64foo /already/ provides lib64foo. > - bar (a binary 64 bit package) can /already/ depend on lib64foo (and > not libfoo). > > What's the problem? The problem is when dpkg-shlibdeps can not determine the correct dependencies on library packages (e.g. a versioned Depends) and the package maintainer added an explicit 'Depends: libfoo (>= 1.2.3)' to the control file. Unless the source package is changed , the 64 bit binary will end up with 'Depends: lib64foo, libfoo (>=1.2.3)' instead of the correct 'Depends: lib64foo (>=1.2.3)'. Luckily, these seem to be far less common than I first though, so it could still be possible to do them by hand. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lzaw5t5GS2LDRf4RAk+3AJ9Xm+Vl/K78zi6o4/nC0LpREVZnVwCgop7v uPSmQuNwdri9aam2uRxeJPQ= =wSKS -END PGP SIGNATURE-
Re: Work-needing packages report for Apr 11, 2003
On Fri, 2003-04-11 at 13:57, Lars Bahner wrote: > I am not currently using anything on the wnpp-list, but it > seems to me that not all these packages are better off gotten > rid off. > > Does anyone know something about the importance of these > packages? Has/can someone run this against the popularity-contest? Speaking for myself, I can say that I still have playmidi installed, albeit version 2.3 instead of 2.4 (2.4 drums sound ugly on my wavetable for some reason I can't fathom; not a Debian problem per se, it's in upstream too). AFAIK, nobody uses playmidi anymore. Most sound cards these days don't even *come* with wavetable synthesis, and software synthesis (ie timidity) sounds so much better than FM synthesis. The only reason I have playmidi installed is that I have a very nice wavetable synthesis daughter board, and playmidi is the only thing I've found that can use it. I'm no "professional MIDI musician", but I suspect that most who are use something other than playmidi. I wouldn't miss it, and I don't think most others will either. As for some of the others, I was thinking about picking up gtick, but I'm not a Debian developer, and it is rumored to be abandoned upstream. I didn't even know about freebirth until someone mentioned that it could probably replace gtick, but it looks like freebirth is orphaned too! There are a couple of others in there that make me wonder: if they go what are some (good) alternatives? For instance, what are some good replacements for magicfilter? Or linuxconf? > My point is that I could prolly adopt a package or two, but have > no knowledge or particular interest in what is being offered. > > On the other hand we should probably take care of the packages > we have before we take on new ones, I suppose. > > I would suspect packages like: > exim-tls > udhcpd > defoma(!) > mserver > scanmail > mnogosearch > cadaver > phpgroupware > pppoeconf > pptp-linux > > to be of some importance. I feel obliged to take responsibility for > at least one of them, but - as I said - I use none of them (except > for defoma of course). > > So, do we have some way of separating that which we really want > to get rid off from that which unfortuneately has been orphaned? > > More over I wish to revive the inflammable discussion as to > whether or not it would be a good idea to have a section in > the archives for unmaintained, much like non-US or non-free. > > I really think it is the best thing for our users if they > can see up front that the package that they are about to install > is not necessarily likely to be bugfixed in the foreseeable > future. Furthermore if they don't have the skills to fix things > themselves, then they just cut of that apt-source. > > Lars. > > > On Fri, Apr 11, 2003 at 12:32:33AM -0400, [EMAIL PROTECTED] wrote: > > Report about packages that need work for Apr 11, 2003 > > > > Total number of packages offered up for adoption: 63 > > Number of packages offered up for adoption this week: 3 > > Total number of orphaned packages: 196 > > Number of packages orphaned this week: 26 > > > -- > Lars Bahner: http://lars.bahner.com/; Voice: +4792884492; Fax: +4792974492 > > > Key fingerprint = A913 7B54 E5FC 804D C12B 18DE 493D 83DE 5DE6 C5D6 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- The more I use other operating systems, the more I like Debian GNU/Linux http://www.debian.org http://www.gnu.org http://www.linux.org signature.asc Description: This is a digitally signed message part
Nameserver-pushing mechanism
(sorry, i have easy enthusiasm, especially at 2:30 am ;)
On Fri, Apr 11, 2003 at 10:39:46PM +0200, Thomas Hood wrote:
> TODO for etc/resolv.conf
> Overview
> * /etc/resolv.conf -> /run/resolv.conf
> * Networking daemon pidfiles go in /run/
> * Resolv.conf-like files go in /run/resolver/interfaces/
> * DNS cache configuration file fragments go in /run//
> * "/etc/init.d/resolver reload" regenerates /run/resolv.conf
> and calls DNS cache update scripts in /etc/resolver/update.d/
Sounds quite good. But I have a suggestion about going one step further:
include the whole thing into ifupdown.
Justification: nameservers are added per interface, right ? Some are
static, some are dynamic, all of them should be used when the interface
gets up and be dropped when it gets down. Have a look at this piece of
/etc/network/interfaces file :
# We have the way to sort them we need...
auto lo eth0 ppp0
# So you run a local dns server ? No ugly hack to make, and you can
# still choose to use it or not.
interface lo inet loopback
nameserver 127.0.0.1
nsnopush bind9
# Something static
interface eth0 inet static
address 123.45.67.89
...
search example.com
nameserver 123.45.67.5
nspush bind9
# Something dynamic
interface ppp0 inet ppp
provider someone
nspush bind9
Isn't this just beautiful ? ;)
In this case, every external nameserver gets pushed to bind, and the
local bind9 nameserver gets pushed to everything else.
Underlying programs to configure interfaces (dhcpcd, pppd, ...) would
put their resolv.conf data in /run/network/resolv.d/. They
have no need to call any script to do the update, ifupdown manages it
itself.
After an interface has been brought up or taken down, ifupdown sweeps
its config file. For each interface there, wished update scripts (all by
default) from /etc/resolv-update.d are fed the appropriated recomposed
resolv.conf data to their standard input. For instance
/etc/resolv-update.d/glibc would just do "cat >/run/resolv.conf". bind9
would do :
exec >/run/bind/named.conf.forwarders
echo "forwarders {"
grep '^nameserver ' | while read a b; do echo $b; done
echo "}"
Note that glibc's resolver is just considered as a client of the
mechanism here, not as the central thing.
Something like a push-resolvers command would still be included into
ifupdown to be called from bind's postinst, among others.
We will also need that ifupdown waits until ppp/dhcp has finished before
exiting. This has to be done someday, anyway. /run makes it possible,
since we can create, for instance, a /run/network/pid.ppp0 file to be
killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown.
> * libc6
Would just need to drop a script into /etc/resolv-update.d.
Others would stay valid, thanks for the investigation.
I'd like to hear opinions about this. In the case you think it's the way
to go, i'd be ok to do the work to extend ifupdown.
--
Jeremie Koenig <[EMAIL PROTECTED]>
Re: Work-needing packages report for Apr 11, 2003
On Fri, Apr 11, 2003 at 05:23:39PM -0700, Nathan Paul Simons wrote: | | [...] Most sound cards these days don't even *come* with wavetable | synthesis, [...] | Er, the SBLive and its Creative brethren do, don't they? At least, I'm presuming that's what "sound fonts" are for. Has it been removed in later versions of the card? CP.
