Re: Debian for x86-64 (AMD Opteron)
#include hallo.h * Drew Scott Daniels [Thu, Apr 10 2003, 02:11:36PM]: I don't quite understand all the concepts being discussed but the following web pages may be worth reading. http://master.debian.org/~brinkmd/arch-handling.txt The idea is great and I came to very similar concept looking for a solution for various dynamic dependency problems. However I think that too many methods are hardcoded in Debian's packagement system and in too many maintainer's heads, so it will be just not possible to implement it in a sane way without forking a new distro. http://wiki.debian.net/BrainStorming MfG, Eduard.
subscribe
Re: /run and read-only /etc
On Wed, 2003-04-09 at 10:13, Marco d'Itri wrote:
Leaving /etc/adjtime as is and telling admins to move it and use a
symlink is a FHS violation because /etc/adjtime is.
What part of FHS does not apply to local changes you did not
understand?
No part. Please read my message again. The problem is the behavior of
the package; i.e., of the distribution, to which the FHS applies.
I don't care if the admin types:
# find /var -type f -exec '/bin/sh' '-c' 'mv {} /etc/`uuidgen`' ';'
(though I reserve the right to laugh my a** off)
/etc has a static nature. See the note on /etc/mtab under Table
3.7.3.1. It is also for configuration files. /etc/adjtime is neither.
Then propose to change FHS.
What change would you propose? Something along the lines of:
The requirements of this section must be followed, even if
the file happens to be called adjtime.
PLEASE read http://www.pathname.com/fhs/2.2/fhs-3.7.html. There is
only _one_ exception in the FHS for non-static/non-configuration data in
/etc, and that is mtab.
If you check your /etc into CVS, _nothing_ but mtab should change
without administrative action (except, perhaps, passwd, shadow, etc.).
That's what the FHS implies.
BTW: Debian is pretty close to FHS compliance on /etc. Once /run is
created and used, the only obvious one I notice is
http://people.debian.org/~stevenk/linda.d.o/unstable/binary-in-etc.html
signature.asc
Description: This is a digitally signed message part
Re: /run and read-only /etc
On Wed, 2003-04-09 at 14:17, Thomas Hood wrote: * ppp * Change /usr/sbin/pppd to: * Store PID in /run/, not in /var/run/ Why? Is the goal to make PPP-mounter /var to work?! If so, pppd has to be moved to /sbin. * pump * Add /etc/pump directory * Change /sbin/pump to: * Store PID in /run, not in /var/run Quite. Programs in /sbin shouldn't, in general, be using /var/run. The proposed new directory is for files similar to those in /var/run/ that are not just variable and unshareable but also local -- i.e., they must be writable independently of network connectivity. No, they must be on the root file system, like /bin and /sbin. Remember the root FS can be network mounted, e.g., over NFS. signature.asc Description: This is a digitally signed message part
Re: fakeroot with chroot.
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. user-mode-linux has too big overload and it is available only for i386 architecture. I've tested my modified fakeroot on alpha, sparc and ia64 and it works pretty well. I read another thread about fakeroot and I think I'll start new project called i.e. fakechroot which will be based on original fakeroot. The original project should be as stable as it is possible. My library is too experimental. -- Piotr Roszatycki, Netia Telekom S.A..''`. mailto:[EMAIL PROTECTED] : :' : mailto:[EMAIL PROTECTED] `. `' `-
Re: Database-specificisms considered harmful
Matthias Urlichs [EMAIL PROTECTED] wrote: * Package name: exim-mysql Personally, I do not like all those -mysql, -pgsql, -whatever packages. Who does? :-( 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). Just checking the dependencies and sizes on woody, neither libgda nor unixodbc are more leightweight than linking directly against mysql and pgsql *at* the *same* *time*. 217348 17. Jul 2002 /usr/lib/libmysqlclient.so.10.0.0 65636 31. Mär 2002 /usr/lib/libpq.so.2.2 60464 24. Mär 2002 usr/lib/libgda-client.so.0.0.0 148400 24. Mär 2002 usr/lib/libgda-common.so.0.0.0 472824 13. Apr 2002 usr/lib/libodbc.so.1.0.0 gda looks small but its interlibrary dependencies on woody are completely over the top (complete GNOME), the version in sid is iirc sane, but still pulls in libglib1.2, libxml1 and libxslt1, which makes it bigger than libmysqlclient+libpq. The crux of the whole matter with respect to exim is that it not optimized for binary redistribution (else it would dlopen the lookup modules) and that its *sql lookup methods are a lot older than gda and _perhaps_ unixobdc. 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..? Imho switching from direct lookups to one of these wrapper libraries isn't in the responsibilty of the debian maintainer _and_ I do not think a paragraph in policy would buy anything (policy is no stick to beat with), submitting patches to upstream might work. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Database-specificisms considered harmful
On Fri, Apr 11, 2003 at 04:34:00PM +0200, Matthias Urlichs arranged a set of bits into the following: 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). My own view on this (as someone who hacks in GForge among other things) is that anything that depends on MySQL can probably be modified to work with postgres easily (in terms of data tables, libraries are harder to switch). However anything which depends on a more powerful DB may not, they often use things like triggers, views (MySQL 5 will have), sub-selects (MySQL 4.1 has), stored procedures etc. Also many packages configure access perms to the db in the config scripts. 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgp6xopRoblUC.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Previously Arnd Bergmann wrote: 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 ;-). Since Depends are automatically calcuated by dpkg-shlibdeps I don't see the problem here. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 12 April 2003 13:00, Wichert Akkerman wrote:
Previously Arnd Bergmann wrote:
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 ;-).
Since Depends are automatically calcuated by dpkg-shlibdeps I don't see
the problem here.
Some examples: gcc-3.2 depends on libgcc1, kdenetwork depends on
libkdenetwork2 (=${Source-Version}), lsb depends on libz1 and libgl1.
None of these can be done with dpkg-shlibdeps. But you are right: while
there may be these exceptions, the vast majority of dependencies is
no problem.
Arnd
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+mACM5t5GS2LDRf4RAvJMAJ4ySRaSxEdpwv721L618yHR+TzjlgCdHefe
Nslw71kdaPs2rhXefjB220c=
=CFMT
-END PGP SIGNATURE-
Re: Upcoming removal of orphaned packages
Martin Michlmayr wrote: # 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. These packages all look likely to be leaves, but have you checked for other packages depending on them just to be sure? -- see shy jo pgpyW8mmZxWX5.pgp Description: PGP signature
Re: Upcoming removal of orphaned packages
* Joey Hess [EMAIL PROTECTED] [2003-04-11 23:11]: These packages all look likely to be leaves, but have you checked for other packages depending on them just to be sure? Not yet, but I intend to do so before the removal. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
At Fri, 11 Apr 2003 13:52:12 -0400 (EDT), Joe Nahmias wrote: Will these packages will still be available through archive.d.o or will they be purged from there as well? These packages will be available through http://snapshot.debian.net/, as much as I can afford to maintain. Regards, Fumitoshi UKAI
Re: Database-specificisms considered harmful
On Friday 11 April 2003 16:34, Matthias Urlichs wrote: * 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..? Why is a consesus needed? I agree with you that having each package as foo, foo-mysql, foo-pgsql, foo-whatever is ugly. But there's many generic db libraries in many languages, and I don't see a need to require one to be the standard. Another way (probably better in some cases) is to recommend people to use runtime loadable modules, then the foo-pgsql module would not be another version of foo, but the pgsql driver module for foo. (Like php, apache, ... are doing it). But whatever: I'd be very careful pushing this idea: who will write the code? Many (most?) pkg maintainers are not upstream developers. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpMUBCHJZcRw.pgp Description: signature
Re: Debian for x86-64 (AMD Opteron)
Wichert Akkerman [EMAIL PROTECTED] writes: * modify dpkg (already planned) to allow it to install packages from different architectures on a system where it makes sense * change the naming of the libraries, for example by adding '64' to the 64bit version of a library That way you could do something like: # echo x86-64 /etc/dpkg/legal-archs # dpkg -i libgtk2-2.0-1_i386.deb # dpkg -i lib64gtk2-2.0-1_x8664.deb That doesn't scale terribly well, does it? Everytime a new 64 bit architecture is introduced, all the library packages have to be updated by hand (instead of just being recompiled). The Arch field needs to be expanded, too, e.g. a la Brinkmann. -- Marcelo | One o'clock pee em! Hello, Insert Name Here! [EMAIL PROTECTED] | -- The Dis-organizer |(Terry Pratchett, Jingo)
Re: Upcoming removal of orphaned packages
On Friday 11 April 2003 19:52, Joe Nahmias wrote: Will these packages will still be available through archive.d.o or will they be purged from there as well? I guess you thought about http://snapshot.debian.net/ instead of archive? s.d.n main page explicitely says that removed pkgs will be retained there. So there's no problem recovering the latest version from sid of a package. cheers -- vbi -- Help! I'm trapped in a PDP 11/70! pgpEi9952IEnQ.pgp Description: signature
Re: Upcoming removal of orphaned packages
On Sat, Apr 12, 2003 at 03:15:17PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: I guess you thought about http://snapshot.debian.net/ instead of archive? s.d.n main page explicitely says that removed pkgs will be retained there. So there's no problem recovering the latest version from sid of a package. Well, they have to be stored on archive, too. Mainly for GPL licensing issues. 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: Work-needing packages report for Apr 11, 2003
On Fri, Apr 11, 2003 at 10:57:34PM +0200, 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? I would suspect packages like: exim-tls Obsolete with the soon-pending exim 4, iirc. udhcpd Do we need another dhcp server? defoma(!) Hopefully somebody will pick it up and make it stop sucking so utterly... mserver Looks insignificant. scanmail Loads of alternatives in the archive. mnogosearch Again, several alternatives. cadaver You get ten of these to the penny. phpgroupware Again, several alternatives. pppoeconf Yay, another config tool. Just what we need. pptp-linux AIUI, you have to rebuild your kernel with a patch, and the version of the patch in the archive doesn't work on recent kernels. So I doubt many people will be hugely affected. 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? If nobody is willing to take responsibility for it, we want to get rid of it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpoDLr2hs0bo.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Previously Marcelo E. Magallon wrote: That doesn't scale terribly well, does it? Everytime a new 64 bit architecture is introduced, all the library packages have to be updated by hand (instead of just being recompiled). I don't see that. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: Debian for x86-64 (AMD Opteron)
On Sat, Apr 12, 2003 at 03:38:45PM +0200, Wichert Akkerman wrote: Previously Marcelo E. Magallon wrote: That doesn't scale terribly well, does it? Everytime a new 64 bit architecture is introduced, all the library packages have to be updated by hand (instead of just being recompiled). I don't see that. You don't? How do you generate binary packages libfoo or lib64foo out of source foo depending on the target architecture? -- Marcelo
Re: Work-needing packages report for Apr 11, 2003
On Sat, Apr 12, 2003 at 02:34:32PM +0100, Andrew Suffield wrote: [...] mnogosearch Again, several alternatives. search.d.o is using it, IIRC it was the only search engine able to index foreign languages found on www.d.o. Denis
Re: Debian for x86-64 (AMD Opteron)
On Saturday 12 April 2003 15:42, Marcelo E. Magallon wrote: How do you generate binary packages libfoo or lib64foo out of source foo depending on the target architecture? Every architecture knows where its libraries are installed. One way would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either 'lib' or 'lib64' depending on the architecture. You have to do something like this anyway because the file list and the configure arguments are also different. Arnd
Re: Work-needing packages report for Apr 11, 2003
On Sat, Apr 12, 2003 at 02:34:32PM +0100, Andrew Suffield wrote: pptp-linux AIUI, you have to rebuild your kernel with a patch, and the version of the patch in the archive doesn't work on recent kernels. So I doubt many people will be hugely affected. Well, uni shut down VPN-access a while ago, but ISTR that pptp-linux worked out-of-the-box for me. Not sure. Michael
Re: Debian for x86-64 (AMD Opteron)
Arnd Bergmann [EMAIL PROTECTED] writes: Every architecture knows where its libraries are installed. One way would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either 'lib' or 'lib64' depending on the architecture. You have to do something like this anyway because the file list and the configure arguments are also different. I feel my leg being pulled :-) Again, with -v -v -v, what do you write in the Architecture field corresponding to the lib64foo package in the debian/control file? -- Marcelo | Real children don't go hoppity-skip unless they are [EMAIL PROTECTED] | on drugs. | -- Susan, the ultimate sensible governess |(Terry Pratchett, Hogfather)
Bug#188713: ITP: duplicity -- encrypted bandwith-efficient backup
Package: wnpp Version: unavailable; reported 2003-04-12 Severity: wishlist * Package name: duplicity Version : 0.4.0 Upstream Author : Ben Escoto [EMAIL PROTECTED] * URL : http://www.nongnu.org/duplicity/ * License : GPL Description : encrypted bandwidth-efficient backup Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux vision 2.4.20ptracefix-grsec #1 Sun Mar 23 12:00:17 CET 2003 = i686 Locale: LANG=3DC, [EMAIL PROTECTED] yours Martin -- [EMAIL PROTECTED] - NO HTML MAILS PLEASE GPG / PGP encrypted and signed messages preferred pgpA5Zz7J21QK.pgp Description: PGP signature
Re: Upcoming removal of orphaned packages
On Sat, 12 Apr 2003, Martin Michlmayr wrote: biomode -- [Biology] An Emacs mode to edit genetic data [#100215] * Orphaned 671 days ago I hope that the bugs will be fixed soon - at least I have heard rumors that work is going on. bugsx -- evolve biomorphs using genetic algorithms [#86636] * Orphaned 780 days ago ... fastlink -- [Biology] A faster version of pedigree programs of Linkage [#100221] * Orphaned 671 days ago I see no reason to remove bug free packages. I just used to take over all orphaned packages which have bugs filed on it in the past. As long as theses packages are free of bugs I see no reason for an upload. In general I would offer to care for biology related packages if noone else would be able to do this instead of me. freetds-jdbc -- Pure Java JDBC driver for MS SQL and Sybase [#117543] * Orphaned 529 days ago ACK. I was the former maintainer and think if noone insists it can be removed. mpsql -- A graphical frontend for PostgreSQL [#89957] * Orphaned 755 days ago It would be great if someone would step in here. Graphical frontends to PostgreSQL are quite rare. njplot -- [Biology] A tree drawing program [#100249] * Orphaned 671 days ago Same as for bugsx and fastlink. If you think the wishlist bug is a problem I would care for it soon. sabre -- Fighter plane simulator. [#175226] * Orphaned 97 days ago * 1 RC bugs. Hmm, would be a shame if noone would care for it. My son likes it and the bugs on it do not seem really hard, IMHO. Kind regards Andreas. PS: In general I like the idea to consolidate the archive ... -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: Upcoming removal of orphaned packages
On Sat, Apr 12, 2003 at 05:39:14PM +0200, Andreas Tille wrote: mpsql -- A graphical frontend for PostgreSQL [#89957] * Orphaned 755 days ago It would be great if someone would step in here. Graphical frontends to PostgreSQL are quite rare. It's not installable (#175816) and upstream seams to be gone. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] pgpMiOXW3cLse.pgp Description: PGP signature
Re: Work-needing packages report for Apr 11, 2003
I demand that Nathan Paul Simons may or may not have written... [snip] 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). Hmm. They're conffiles (not sure why, given that they're all binaries); have you tried 2.4 with the 2.3 drums files? AFAIK, nobody uses playmidi anymore. I use it from time to time, and I think that it should be left in the archive until most people are using 2.6-series kernels (and, thus, ALSA). Most sound cards these days don't even *come* with wavetable synthesis, and software synthesis (ie timidity) sounds so much better than FM synthesis. I have an SBLive; it has an on-board synth, which sounds almost as good as timidity (and has the advantage of using next to no CPU power). OTOH, the only synth support for emu10k1 is in ALSA, although there's OSS support for the MIDI port on these cards (but I don't have anything to plug in there). 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. Hmm... another reason to keep it, then. [snip] For instance, what are some good replacements for magicfilter? apsfilter seems to work well. Or linuxconf? A text editor :-) [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | Debian, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | 2003/04/12 16:51 - Mackems relegated to Division One DO NOT BEND, FOLD, STAPLE, OR IN ANY WAY MUTILATE THIS TAGLINE.
Hardware Compatibility List for Woody (exist)?
Dear Debian Devs, Is there any kind of Hardware Compatibility List for Debian(Woody)? I know there is the Hardware-Howto but this document is (too) old. How can I collect an up-to-date Hardware Compatibility List by inspecting (which) Kernel-Code(-Parts)? (How are the SuSE people for example do this-they have a very big HCL but I don't know if Debian can use the same HCL-?) If someone can answer this question I will start working on this so there will some up-to-date HCL for Woody. Thank you for reading my posting Thanks for all who will answer my questions Your debian_noob __ UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101
Some questions about Debian developers
Dear Debian Developers, I am very new to Debian and know I want to dive deeper into Debian. For this I have some questions: 1) What kind of developing does a Debian developer? Are you developing the packages (*.deb files)? I ask because I want to understand why this is so complicated. There are apt-scripts to create *.deb-files from source-packages (I mean *.tar or *tar.gz files). What are the hard parts of creating the deb-packages of new source-files why the Debian developers are working so long for a new version of the Debian stable release (3.1 or 4.0)? 2) Are you developing some fixes on the source files of the upstream-developers? I ask because I want to understand what kind of fixes and customizations a developer have to write to make his applications Debian-compliant. I plan some development for scientific-calculations and this information would help me to write Debian-compliant software(I want to create Debain-packages so others can install my software without much difficulties). 3) What are the quality specs that define which package can get from testing to unstable to stable? I already started reading the documents for Debian-developers but I couldn't find answers about my specific questions-yet. Thank you for reading my mail. Thanks for all who will answer my questions. Your debian_noob __ UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101
Fwd: ITP: oscommerce -- Online shop e-commerce solution with PHP/MySQL
- Mensagem Reenviada de [EMAIL PROTECTED] - Data: Sat, 12 Apr 2003 17:37:44 +0100 De: Bruno David Rodrigues [EMAIL PROTECTED] Assunto: ITP: oscommerce -- Online shop e-commerce solution with PHP/MySQL Para: [EMAIL PROTECTED] retitle 187134 ITP: oscommerce -- Online shop e-commerce solution with PHP/MySQL thanks * Package name: oscommerce Version : 2.1 Upstream Author : Harald Ponce de Leon [EMAIL PROTECTED] * URL : http://www.oscommerce.com * License : GPL Description : Online shop e-commerce solution with PHP/MySQL osCommerce is an online shop e-commerce solution under on going development by the open source community. Its feature packed out-of-the-box installation allows store owners to setup, run, and maintain their online stores with minimum effort and with absolutely no costs or license fees involved. . osCommerce combines open source solutions to provide a free and open e-commerce platform, which includes the powerful PHP web scripting language, the stable Apache web server, and the fast MySQL database server. . With no restrictions or special requirements, osCommerce is able to run on any PHP3 or PHP4 enabled web server, on any environment that PHP and MySQL supports, which includes Linux, Solaris, BSD, and Microsoft Windows environments. -- br/ 17:57:24 up 140 days, 18:10, 7 users, load average: 0.02, 0.07, 0.06 BOFH excuse #267: The UPS is on strike.
Re: fakeroot with chroot.
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. user-mode-linux has too big overload and it is available only for i386 architecture. I've tested my modified fakeroot on alpha, sparc and ia64 and it works pretty well. user-mode-linux can be ported to other arches, and although most ports are not complete, I have seen several attempts to port them. I read another thread about fakeroot and I think I'll start new project called i.e. fakechroot which will be based on original fakeroot. The original project should be as stable as it is possible. My library is too experimental. Yes, fakechroot would be a good name, I considered using that name myself when I tried writing my version of extended fakeroot. However, with fakeroot you are only overriding function symbols, and syscalls are not overloaded. I don't think it's really a recommended practice to call system calls directly without using glibc, but it is possible, and fakeroot will not work in that case. There are pretty ugly corner cases due to the way symbols are resolved, but since you seem to have gone quite far with fakechroot, I would wish you good luck in completing it, it looks like a very exciting project :) regards, junichi
Re: Debian for x86-64 (AMD Opteron)
On Saturday 12 April 2003 16:58, Marcelo E. Magallon wrote:
Arnd Bergmann [EMAIL PROTECTED] writes:
Every architecture knows where its libraries are installed. One way
would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either
'lib' or 'lib64' depending on the architecture. You have to do
something like this anyway because the file list and the configure
arguments are also different.
I feel my leg being pulled :-)
Again, with -v -v -v, what do you write in the Architecture field
corresponding to the lib64foo package in the debian/control file?
Ok, now I see your point. What I wanted to do is put 'Architecture: any'
in the control file and use debian/substvars to define the actual
name of the binary package, e.g. 'Package: ${lib}foo'. I suppose there
is a good reason why using a generated package name does not work, so
we have to come up with something else.
Sorry for the confusion.
Arnd
Bug#188732: ITP: gtk2-engines-smooth -- Highly configurable GTK+ 2 theme
Package: wnpp Version: unavailable; reported 2003-04-12 Severity: wishlist * Package name: gtk2-engines-smooth Version : 0.5 Upstream Author : Andrew Johnson [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/smooth-engine * License : GPL Description : Highly configurable GTK+ 2 theme Smooth GTK1/GTK2 Theme Engine is a simple theme engine intended to be smooth, fast, and highly configurable, such that it could eventually mimic most, if not all, major theme engines to high degree of acuracy, while still retaining a small footprint. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux eddie 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST 2003 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB (ignored: LC_ALL set)
Re: Debian for x86-64 (AMD Opteron)
At 19:10 12/04/2003 +0200, you wrote:
On Saturday 12 April 2003 16:58, Marcelo E. Magallon wrote:
Arnd Bergmann [EMAIL PROTECTED] writes:
Every architecture knows where its libraries are installed. One way
would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either
'lib' or 'lib64' depending on the architecture. You have to do
something like this anyway because the file list and the configure
arguments are also different.
I feel my leg being pulled :-)
Again, with -v -v -v, what do you write in the Architecture field
corresponding to the lib64foo package in the debian/control file?
Ok, now I see your point. What I wanted to do is put 'Architecture: any'
in the control file and use debian/substvars to define the actual
name of the binary package, e.g. 'Package: ${lib}foo'. I suppose there
is a good reason why using a generated package name does not work, so
we have to come up with something else.
Sorry for the confusion.
[ Disclaimer: just subscribed -- caught the thread already started ]
Sorry, i must me missing something obvious, but why would we need lib64foo ?
Why not just define the new architecture x86-64 and have katie/buildd do
the rest?
Users with Opteron/Athlon64 would have the additional bonus of a completely
optimized distro to run ( as good as or better than using a source-based
distribution such as Gentoo ), and it would be completely transparent for
developers...
Anything to do with the ability to mix-and-match 32 and 64-bit code in this
processors?
Arnd
Regards,
J.L.
Re: Hardware Compatibility List for Woody (exist)?
On Sat, Apr 12, 2003 at 06:58:35PM +0200, [EMAIL PROTECTED] wrote: How can I collect an up-to-date Hardware Compatibility List by inspecting (which) Kernel-Code(-Parts)? (How are the SuSE people for example do this-they have a very big HCL but I don't know if Debian can use the same HCL-?) If someone can answer this question I will start working on this so there will some up-to-date HCL for Woody. Hmm, i think the best way would be to collect a database for hardware supported by each configuration variable in the kernel config, and feed in the kernel configuration for each boot media and make it spit out a customized compatibility list for that image. There is no such service (not that i'm aware of) but it would be great to have around. Regards, Sami -- - Sami Haahtinen - -[ Notify immediately if you do not receive this message ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C -
Re: Debian for x86-64 (AMD Opteron)
On Sat, Apr 12, 2003 at 09:15:32PM +0200, José Luis Tallón wrote: [ Disclaimer: just subscribed -- caught the thread already started ] http://lists.debian.org/debian-devel Why not just define the new architecture x86-64 and have katie/buildd do the rest? Anything to do with the ability to mix-and-match 32 and 64-bit code in this processors? Yes. cheers, Michael
Re: Some questions about Debian developers
[EMAIL PROTECTED] wrote: 1) What kind of developing does a Debian developer? Are you developing the packages (*.deb files)? Yes. But that is only part of the entire task. I ask because I want to understand why this is so complicated. There are apt-scripts to create *.deb-files from source-packages (I mean *.tar or *tar.gz files). Complicated is in the eye of the beholder. The .deb packages themselves are just archives of gzip'd tar files. Which seem very simple. It is true that there are several different scripts used in the process of building a .deb package. But they don't seem very complicated once you try them. The entire process is documented quite well in the developer manual. However as is true of many projects the documentation can almost always stand improvement. Suggestions for documentation improvement are always welcome. What are the hard parts of creating the deb-packages of new source-files why the Debian developers are working so long for a new version of the Debian stable release (3.1 or 4.0)? You misunderstand. It is not difficult at all to make a package for a new piece of software. That is the very easy part. The hard part is making that new piece of software play well with other software. Frequently there are bad interactions. Here is an example. The option of one program changes. Another program uses the first program and so it needs to change too. An interaction while in isolation each package stands fine on its own. With ten thousand packages in the Debian archive keeping the bad interactions minimized is a difficult task. 2) Are you developing some fixes on the source files of the upstream-developers? Many times yes. But there is a strong pressure by policy to push those fixes back into the upstream version. Debian tries hard not to keep those fixes closed but instead pushes those back upstream so that all users of the software benefit, even those not using Debian. I ask because I want to understand what kind of fixes and customizations a developer have to write to make his applications Debian-compliant. If your software package is well behaved then I would not expect any customizations would be needed to make it Debian compliant. Well behaved has some room for debate. But basically a good upstream package works well in Debian, and probably other distributions too, with no changes. I plan some development for scientific-calculations and this information would help me to write Debian-compliant software(I want to create Debain-packages so others can install my software without much difficulties). Excellent! A good source of discussion for people starting out is on the debian-mentors mailing list. Try to follow the documentation for packaging your software. If you run into trouble, ask questions on the debian-mentors list. 3) What are the quality specs that define which package can get from testing to unstable to stable? http://www.debian.org/devel/testing You can find that link by going to the main Debian site and seeing Developers's Corner and following that to work in progress section where you find The testing distribution. Good luck with your project! Bob pgpljWjv41dOb.pgp Description: PGP signature
Bug#188748: ITP: zabbix -- Application and network monitoring
Package: wnpp Version: unavailable; reported 2003-04-12 Severity: wishlist * Package name: zabbix Version : 1.0beta9 Upstream Author : Alexei Vladishev [EMAIL PROTECTED] * URL : http://zabbix.sourceforge.net/ * License : GPL Description : Application and network monitoring Zabbix is software for application and network monitoring. Zabbix supports both polling and trapping techniques to collect data from monitored hosts. Flexible notification mechanism allows easy and quickly configure email notifications for pre-defined events. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ragueneau 2.4.18-k6 #1 Sun Apr 14 12:43:22 EST 2002 i586 Locale: LANG=C, LC_CTYPE=fr_FR
Re: Hardware Compatibility List for Woody (exist)?
How can I collect an up-to-date Hardware Compatibility List by inspecting (which) Kernel-Code(-Parts)? (How are the SuSE people for example do this-they have a very big HCL but I don't know if Debian can use the same HCL-?) Nor, nor could they really-- SuSE generates their list by people paying them money to say their hardware is certified under SuSE Linux. Debian has no such entity for people to pay us, and we're not as a rule very interested in doing so. Furthermore, distributions like SuSE and Red Hat not only heavily patch the kernels they release, they also rely on their customers not generating a custom kernel; it's my impression that Debian users, as a rule, are much more likely to do so. If someone can answer this question I will start working on this so there will some up-to-date HCL for Woody. First you'll have to define what you mean by HCL. What goes on the list? Is it sufficient for a network card to respond to ifup, or should it perform within some epsilon of its rated speed? What about a SCSI card? Should it be measured to work with disks, scanners, tape drives, and ghod knows what else? Some driver/hardware bugs show up only after a hundred hours or so of continuous operation; how long should a device be tested until it's considered 'compatible'? How do you maintain the list? What kinds of changes would require a recertification, and what kinds wouldn't? That's not to say this isn't a useful or interesting question to ask; just make sure you realize what you're getting yourself into when you do. -=Eric
Bug#188757: ITP: libmysqlclient-lgpl -- LGPL-licensed client library for MySQL databases
Package: wnpp Version: unavailable; reported 2003-04-12 Severity: wishlist * Package name: libmysqlclient-lgpl Version : 3.23.56 Upstream Author : MySQL AB * URL : http://www.mysql.com/ * License : LGPL Description : LGPL-licensed client library for MySQL databases This package contains a fork of the MySQL client library for use with software that is distributed under a GPL-incompatible license. Because it is based on an older, LGPL version of the official MySQL client library, it may lack features available in the MySQL 4.0 libs. If you are looking for a library for use in a GPL application, or in software which will not be distributed by Debian, you may prefer to use the official library from MySQL AB instead. Binary packages will initially be named libmysqlclient10 and libmysqlclient10-dev for compatibility with existing packages. It's been suggested that we host this library on alioth.debian.org, since this fork will require an official upstream home; the copyright file will be updated to reflect this if and when it happens. The initial upload will be little more than a copy of the old sources.
Re: /run and read-only /etc
Anthony DeRobertis [EMAIL PROTECTED] wrote:
* pump
* Add /etc/pump directory
* Change /sbin/pump to:
* Store PID in /run, not in /var/run
Quite. Programs in /sbin shouldn't, in general, be using /var/run.
I won't debate whether this is true in general, bug it is certainly
unnecessary in the case of pump. I have specifically added code to
deal with the inability to write to /var/run by making pump fall back
to using TCP sockets.
--
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: Upcoming removal of orphaned packages
Hi, On Sat, Apr 12, 2003 at 05:39:14PM +0200, Andreas Tille wrote: On Sat, 12 Apr 2003, Martin Michlmayr wrote: sabre -- Fighter plane simulator. [#175226] * Orphaned 97 days ago * 1 RC bugs. Hmm, would be a shame if noone would care for it. My son likes it and the bugs on it do not seem really hard, IMHO. The Upstream site has disappeared. And a quick google doesn't show anything interesting about it or its upstream author. regards, guillem
Bug#188771: ITP: multitail -- view diffent logiles windowed on console
Package: wnpp Version: unavailable; reported 2003-04-13 Severity: wishlist * Package name: multitail Version : 1.5 Upstream Author : Folkert van Heusden [EMAIL PROTECTED] * URL : http://www.vanheusden.com/multitail/ * License : GPL Description : view multiple logfiles windowed on console multitail lets you view one or multiple files like the original tail program. . The difference is that this program creates multiple windows on your console (with ncurses). It can also use colors while displaying the logfiles for faster recognizing which lines are important and which are not. . It is optimized for terminal-sessions through slow links. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stan 2.4.18 #1 Son Nov 3 01:29:12 CET 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] pgpeWAnLZI4tV.pgp Description: PGP signature
Re: Work-needing packages report for Apr 11, 2003
On Sat, Apr 12, 2003 at 04:01:28PM +0200, Denis Barbier wrote: On Sat, Apr 12, 2003 at 02:34:32PM +0100, Andrew Suffield wrote: [...] mnogosearch Again, several alternatives. search.d.o is using it, IIRC it was the only search engine able to index foreign languages found on www.d.o. Anybody who wants to keep it in Debian is welcome to adopt it. I just don't think we need to be overly worried if nobody does and it gets dumped. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpJyTcGstPfr.pgp Description: PGP signature
Re: Some questions about Debian developers
On Sat, Apr 12, 2003 at 06:56:51PM +0200, [EMAIL PROTECTED] wrote: snip People who don't use their real names are either too stupid or too embarrassed by what they are saying. Either way, reading the mail they send merely wastes valuable seconds. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgp4FHJU9BjfC.pgp Description: PGP signature
Re: Some questions about Debian developers
On Sun, Apr 13, 2003 at 12:59:05AM +0100, Andrew Suffield wrote: People who don't use their real names are either too stupid or too embarrassed by what they are saying. Either way, reading the mail they send merely wastes valuable seconds. There is no reason to blame people that wants to be anonymous. Anonymity and privacy should be rights all over the world. If you are not interested, please ignore tha requests, as several other people did. bye -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 Mathematicians practice absolute freedom. -- Henry Adams
Re: Some questions about Debian developers
On Sun, Apr 13, 2003 at 02:28:23AM +0200, Christian Surchi wrote: On Sun, Apr 13, 2003 at 12:59:05AM +0100, Andrew Suffield wrote: People who don't use their real names are either too stupid or too embarrassed by what they are saying. Either way, reading the mail they send merely wastes valuable seconds. There is no reason to blame people that wants to be anonymous. Anonymity and privacy should be rights all over the world. F^WBlaming people is a right, too :P Michael
Re: Some questions about Debian developers
On Sun, Apr 13, 2003 at 02:52:23AM +0200, Michael Banck wrote: There is no reason to blame people that wants to be anonymous. Anonymity and privacy should be rights all over the world. F^WBlaming people is a right, too :P Destroying absurd commonplaces too! ;-) -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 I have often regretted my speech, never my silence. -- Publilius Syrus
