Hazy Shade of Winter
I was wondering if you would send me the sheet music for Hazy Shade of Winter - I want to transpose it for the piccolo, as that is the sexiest of instruments. thanks, Jimmy James the man so nice they named him twice.
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote: > On Sat, 21 Jun 2003, John Goerzen wrote: > > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > > Note that my idea was about patching the kernel that so the newer opcodes > > > would be emulated in software. Everything would still work even on a > > > 386, > > > just slower -- and the speed decrease can be removed by running apt-build. > > I don't see how that suggestion can possibly be taken seriously. Very few > > i386 machines have the requisite disk space, memory, and swap space to build > > large applications in Debian today. > You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build > doesn't even give the option of avoiding creation of .debs, and the bigger > machine is one scp (or two mcopys in an extreme case) away. This is a disturbing trend. You can't claim that Debian is usable on a machine if it requires another machine or Internet access to work basically. And no, there are not necessarily other machines reachable with scp, since some of these machines sit outside the firewall. Not only that, but this is a big pain as it requires the same version of Debian over there. It is not a workable solution.
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote: > On Sat, 21 Jun 2003, John Goerzen wrote: > > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > > Note that my idea was about patching the kernel that so the newer opcodes > > > would be emulated in software. Everything would still work even on a > > > 386, > > > just slower -- and the speed decrease can be removed by running apt-build. > > I don't see how that suggestion can possibly be taken seriously. Very few > > i386 machines have the requisite disk space, memory, and swap space to build > > large applications in Debian today. > You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build > doesn't even give the option of avoiding creation of .debs, and the bigger > machine is one scp (or two mcopys in an extreme case) away. Our operating system should not be wholly dependant on external factors (other machines, Internet access, whatever) to run. To make it so makes it virtually unusable in a number of situations. In this particular case, no, there is not always another machine network-reachable, as some of these sit outside the firewall. Not just that, but forcing that removes most of the benefits of Debian (apt-get dist-upgrade, etc) and we might as well just to back to Slackware from 1997.
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 11:24:57AM +0200, "Martin v. Löwis" wrote: > John Goerzen wrote: > > >As I say this, I'm sure people can say the same about i486 and even i386 > >machines. Why exactly do we need to remove this support? > > Read the bug report with the number you put in your Subject. Which is little help, as I've already posted in this thread that I'm reading mail offline for a few days.
Re: Dueling Banjoes
On Sun, 22 Jun 2003, Kevin Edwards wrote: > I was wondering if you would send me the sheet music for dueling banjoes - > I want to transpose it for other instruments - Sorry, can't help you there. I can give you the byte codes for dueling flamewars, however.
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote: > > Many video cards require XFree 4.3.x or above. They require agpgart in the > > kernel. They require iwconfig and other wireless tools. There are a whole > > Tell me, you seriously think that there is a libc5 program still around > that uses DRI ? Hell, libc5 was abandoned well before DRI even existed. I'm not talking about DRI programs; I'm talking about just basic support.
Dueling Banjoes
I was wondering if you would send me the sheet music for dueling banjoes - I want to transpose it for other instruments -
Re: how to package Haskell libraries
On Sun, 2003-06-22 at 18:08, Alan Shutko wrote: > Isaac Jones <[EMAIL PROTECTED]> writes: > > > How would Debian prefer to see this? Some people tell me that it'll > > probably be too slow to build the packages on the end-user's system > > (as is done for elisp), > > That's also done with Common Lisp, and I don't think it's too slow > (as an end-user). Right, but that approach definitely has some disadvantages, namely fragility and the fact that we're kind of subverting the whole idea of binary packages.
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Sun, Jun 22, 2003 at 04:58:09PM +0200, Andreas Barth wrote: > * Marco d'Itri ([EMAIL PROTECTED]) [030622 16:35]: > > On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote: > > >There is no technical reason why we can't support libc5 anymore. The only > > >reason that this is being discussed is that nobody has stood up to > > maintain > > >the package. > > > This looks like a good enough reason to me. > > Sorry, but I can find no RFA/O-entry for this package. That should be > done first before kicking it off. That's not a rule. Maintainers are allowed to say that their package should be removed if they believe that it's no longer useful; they're usually much more qualified to say that than, say, the QA group are. It's not as if it's impossible for somebody else to reintroduce the package if they really care. > And I don't remember to read anything from the current maintainer > either. Obviously you haven't looked too closely at who started this thread then? From: "Francesco P. Lovergine" <[EMAIL PROTECTED]> Subject: Proposal: removing libc5, altgcc and all their old-days dependencies Package: libc5 Maintainer: Francesco Paolo Lovergine <[EMAIL PROTECTED]> Cheers, -- Colin Watson [EMAIL PROTECTED]
Keysigning opportunity in Portland, OR
I'm going to be in Portland, Oregon, for June 22-28. I'll probably have time for a keysigning and maybe a quick beer if any Debian developers and/or users are interested. Just drop me a mail if you want to meet somewhere. -Brian -- Poems... always a sign of pretentious inner turmoil. pgp8NklV0An1e.pgp Description: PGP signature
Re: how to package Haskell libraries
Isaac Jones <[EMAIL PROTECTED]> writes: > How would Debian prefer to see this? Some people tell me that it'll > probably be too slow to build the packages on the end-user's system > (as is done for elisp), That's also done with Common Lisp, and I don't think it's too slow (as an end-user). -- Alan Shutko <[EMAIL PROTECTED]> - I am the rocks. Looking for a developer in St. Louis? http://web.springies.com/~ats/ Put your cat in box, add postage and mark "Schr*edinger."
Bug#198445: ITP: matroska -- extensible audio/video container format
Package: wnpp Version: unavailable; reported 2003-06-23 Severity: wishlist * Package name : matroska Version : CVS Upstream Authors : Ludovic "Blacksun" Vialle Christian HJ Wiesner Steve "robUx4" Lhomme * URL : http://www.matroska.org/ * License : dual GPL/QPL Description : extensible audio/video container format Matroska is a cross-platform multimedia container format for audio and video data, and aims to become the standard of multimedia container formats. It has support for menus (like DVDs), subtitles, seeking, error recovery and streaming (over the Internet or on a LAN). Note: the Matroska software is still under development, and only provides a demuxer library. I am packaging this because some media players can already be compiled with support for Matroska files. The binary package will be called libmatroska-dev and will contain .a and _pic.a libraries, because upstream foresees many API/ABI changes before a shared library can be released. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: how to package Haskell libraries
On Sunday 22 June 2003 19:45, Isaac Jones wrote: > There has been a lot of discussion recently on the Haskell mailing > lists about the best ways to package Haskell libraries and tools for > Debian. The main issues are: > > 1) there are a variety of "compiler" implementations, one of which is > an interpreter :) > > 2) not all Haskell implementations are available on all architectures > (ghc for instance) > > 3) just about every Haskell "compiler" and release is > binary-incompatible, (except maybe for nhc98). You might be able to apply the same techniques applied to C++ libs which suffer the same ABI-incompatibility. Currently, the workaround is to postfix the libs with a string-tag for the compiler-ABI. Hmmm, I just wonder: is it true that there is no solution for supporting different ABIs but rather just a transition-plan ? An imho real fix (afaik) encompasses an extension to the ELF-format/dynamic linker and is not due in the near future. Uli
Re: Update re: read-only root filesystem
On Sun, Jun 22, 2003 at 11:16:54AM +0200, Xavier Roche wrote: > > this is not a problem due to devpts filesystem. > Okay, using devfs it works perfectly. > A remaining problem is also Samba: > [2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85) > unable to open or create file /etc/samba/MACHINE.SID. Error was > Read-only file system > So actually samba writes to /etc/samba .. > The problem also occurs for the pwd database (sync with other machines) > [2003/06/22 11:13:11, 0] passdb/pdb_smbpasswd.c:startsmbfilepwent(237) > startsmbfilepwent_internal: failed to set 0600 permissions on password file > /etc/samba/smbpasswd. Error was Read-only file system > .unable to open passdb database. > Moving both /etc/samba/MACHINE.SID and /etc/samba/smbpasswd to /run/samba > solves the problem > Remarks? In general, you're likely to get much better results with a read-only root if you use current versions of packages from unstable. You seem to have found a way to resolve the issue with the Samba package, but in unstable the issue should not have arisen: /etc/samba/MACHINE.SID has been replaced by /var/lib/samba/secrets.tdb, and those wanting a read-only root can easily opt to use /var/lib/samba/passdb.tdb instead of /etc/samba/smbpasswd. -- Steve Langasek postmodern programmer pgpS4h7j5fTeV.pgp Description: PGP signature
Re: j2re1.3 plugin for mozilla isn't working.
Mike Hommey <[EMAIL PROTECTED]> writes: > On Sunday 22 June 2003 19:21, Allan Jacobsen wrote: >> I have been looking for working j2re1.4 packages for some times, but >> unfortunatly this does not work for me: >> >> isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot >> dpkg-buildpackage: source package is j2se1.4-i586 >> dpkg-buildpackage: source version is 1.4.1.0.1-4 >> dpkg-buildpackage: source maintainer is Sebastien NOEL <[EMAIL PROTECTED]> >> dpkg-buildpackage: host architecture is i386 >> fakeroot debian/rules clean >> sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied >> >> /usr/bin/make exists and has the right pemissions ??? > > oops, something missing in the procedure : chmod +x debian/rules > Or just use 'debuild -uc -us', this will do the fakerooting and chmoding for you ;-) Regards, Andy -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 This reality is really just a fucked-up dream -- Papa Roach
package descriptions dummy/transitional
Hello, I noticed a few transitional and dummy packages on my system, but there was no common way to identify them. I think the following packages exist: a) dummy packages which depend on the new name of a package for 1 - automatic updates after split or rename (e.g. xpdf-i) 2 - dependencies b) meta packages which depend on the actual version family (a lot of the python stuff looks like this) I would suggest/asume, that the a1 and a2 packages (at least) should have some common package description parts, and be in the same apt category? Is there a way I can get a list of those "you can remove it safely after upgrade (if no others depend on it)" packages? 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: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 12:06:16PM +0200, Andreas Barth wrote: > * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > > problem here (C++ ABI compatibility with other Linux distributions). The > > discussion is now about *how* to fix this bug: > > 1. just bump minimum supported i386-family processor to i486 > 1a. like 1, but just for c++-packages. 1b. Ban C++ and rewrite everything in C, and rejoice over the fact the we are rid of the horrid kludge that is C++. (No, I do not expect this to happen, and I do indeed expect flames for this... I've donned the asbestos suite...) > > 2. like 1, but bump to some other processor. this is not strictly needed > >to fix the bug, but it might be a good idea for other reasons. > >Dropping other architectures to fix this bug is probably not a good > >idea, as it won't fix the bug. > > 3. bump the supported processor, and rename the port > > 4. like 3, and also add an i386 distribution which does not support > >C++ at all > > 5. like 4, but support C++ in a way incompatible with other Linux > >distributions in the i386 distribution. /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
how to package Haskell libraries
Greetings,
There has been a lot of discussion recently on the Haskell mailing
lists about the best ways to package Haskell libraries and tools for
Debian. The main issues are:
1) there are a variety of "compiler" implementations, one of which is
an interpreter :)
2) not all Haskell implementations are available on all architectures
(ghc for instance)
3) just about every Haskell "compiler" and release is
binary-incompatible, (except maybe for nhc98). That is, we'd need
different binaries for ghc4, ghc5, and ghc6. Also we'd need different
binaries for profiling versions of the libraries, etc.
For instance, if I were to package HUnit, which is a simple case since
its pure Haskell code, I would need:
hunit-{hugs,nhc98} hunit-ghc{4,5,6} hunit-ghc{4,5,6}-prof
And whenever a new version of GHC6 is uploaded (for instance), all of
the packages like hunit-ghc6 would need to be updated at the same
time. That doesn't even get into the issues of the wide variety of
preprocessors that are common in this rapidly advancing language[1].
In practice, though, some packages might just be used on the newer
compilers.
This is why there aren't too many Haskell libraries in Debian right
now. We're discussing a set of software tools that might make this
situation easier for packagers either by helping to create packages
for each version of the compiler, or by building the packages on the
user's system.
How would Debian prefer to see this? Some people tell me that it'll
probably be too slow to build the packages on the end-user's system
(as is done for elisp), but I think it would be hard for package
maintainers to keep track of so many versions of their libraries. I'm
leaning toward writing software tools to help package maintainers
build & maintain that large number of packages, but would this be too
many Debian packages?
peace,
isaac
[1] Haskell is designed to have a "stable" version, Haskell98, and the
compilers come with a variety of extensions so that it is very useful
as a research language as well.
Re: j2re1.3 plugin for mozilla isn't working.
I have been looking for working j2re1.4 packages for some times, but unfortunatly this does not work for me: isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot dpkg-buildpackage: source package is j2se1.4-i586 dpkg-buildpackage: source version is 1.4.1.0.1-4 dpkg-buildpackage: source maintainer is Sebastien NOEL <[EMAIL PROTECTED]> dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied /usr/bin/make exists and has the right pemissions ??? Best regards Allan Jacobsen On Sunday den 22. June 2003 16:48, Mike Hommey wrote: > On Thursday 19 June 2003 18:36, Thomas E. Vaughan wrote: > > Has anyone else noticed this? > > This is due to the fact that Mozilla is now compiled with gcc 3.3, and that > j2re1.3 is still compiled with gcc 2.95 ; both are incompatible. > > You can get a working j2re1.4 (blackdown doesn't provide 1.3 compiled with > gcc 3.x) following this procedure : > - getting the "official" binary package > ftp://ftp.easynet.be/blackdown/JDK-1.4.1/i386/01/j2sdk-1.4.1-01-linux-i586- >gcc3.2.bin - getting the diff file made by Sebastien Noël > http://twolife.free.fr/debian/j2se1.4-i586_1.4.1.0.1-4.diff > - put the binary package into some directory > - inside this directory, use the patch with the command line : > # patch -p1 -i /path/to/j2se1.4-i586_1.4.1.0.1-4.diff > - now you can create a package with dpkg-buildpackage -rfakeroot or > fakeroot debian/rules binary > > Mike
Re: j2re1.3 plugin for mozilla isn't working.
On Sunday 22 June 2003 19:21, Allan Jacobsen wrote: > I have been looking for working j2re1.4 packages for some times, but > unfortunatly this does not work for me: > > isis:~/testdir/j2sdk# dpkg-buildpackage -rfakeroot > dpkg-buildpackage: source package is j2se1.4-i586 > dpkg-buildpackage: source version is 1.4.1.0.1-4 > dpkg-buildpackage: source maintainer is Sebastien NOEL <[EMAIL PROTECTED]> > dpkg-buildpackage: host architecture is i386 > fakeroot debian/rules clean > sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied > > /usr/bin/make exists and has the right pemissions ??? oops, something missing in the procedure : chmod +x debian/rules Mike -- "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, 2003-06-22 at 00:48, Adam Majer wrote: > I once read somewhere that you should _never_ compile in 486 > optimizations for use in processors other than the 486. Apparently > since 486 optimized code is padded a lot with NOPs. > > Apparently you are much better off on a Pentium or Athlon with > i386 optimized code than i486 optimized one. > > > Hence if we are going to migrate from i386, we should not > go to CPU like i486 and just move to a Pentium Classic > code (i586). You're forgetting that we can actually have it both ways; we compile with -march=i486 (or i586), and -mcpu=i686.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 02:46:12PM +0100, Andrew Suffield wrote: > > Apparently you are much better off on a Pentium or Athlon with > > i386 optimized code than i486 optimized one. > I vaguely recall something similar about the i586. FWIK, almost everything that can be done in two ways on ix86, like loop / dec jnz and frame / sub ebp blah, is faster one way on i586 and the other on i686. Moreover, i586 gets most performance boost from keeping everything in registers, while i686 gets most from using registers and memory evenly (!) - I don't know whether compilers support these optimisations, though. So if there will be a split, it should IMO be to i386 and i686. Of course, if C++ progs are going to be broken anyway, dropping i386 might be viable - in that case we'll get i486 and i686. Just my two cents... -- personal contact: [EMAIL PROTECTED], +35841 5323835 work contact: [EMAIL PROTECTED], +35850 3678003 kotisivu (henkkoht):http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
* Marco d'Itri ([EMAIL PROTECTED]) [030622 16:35]: > On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote: > >There is no technical reason why we can't support libc5 anymore. The only > >reason that this is being discussed is that nobody has stood up to maintain > >the package. > This looks like a good enough reason to me. Sorry, but I can find no RFA/O-entry for this package. That should be done first before kicking it off. And I don't remember to read anything from the current maintainer either. Cheers, 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
Re: kullervo (sbuild/m68k) broken?
Op zo 22-06-2003, om 13:53 schreef Andrew Lau: > Hey everyone, > > I haven't seen anyone mention this on debian-devel or debian-68k yet, > so before anymore time is wasted, could someone please take a look into > kullervo (sbuild/m68k)? Every build the last few days has failed due to > the following fatal error: > > dpkg: failed to open package info file > `/usr/local/home/buildd/build/chroot-unstable/var/lib/dpkg/available' > for reading: No such file or directory Thanks for telling; but we know. The filesystem was corrupt, because of a broken down hard disk. New hard disks have been ordered, and the disk has been replaced in the mean time. Note that this wasn't discussed on -68k, since that is not used by the debian m68k porters; instead, we use the [EMAIL PROTECTED] list. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: j2re1.3 plugin for mozilla isn't working.
On Thursday 19 June 2003 18:36, Thomas E. Vaughan wrote: > Has anyone else noticed this? This is due to the fact that Mozilla is now compiled with gcc 3.3, and that j2re1.3 is still compiled with gcc 2.95 ; both are incompatible. You can get a working j2re1.4 (blackdown doesn't provide 1.3 compiled with gcc 3.x) following this procedure : - getting the "official" binary package ftp://ftp.easynet.be/blackdown/JDK-1.4.1/i386/01/j2sdk-1.4.1-01-linux-i586-gcc3.2.bin - getting the diff file made by Sebastien Noël http://twolife.free.fr/debian/j2se1.4-i586_1.4.1.0.1-4.diff - put the binary package into some directory - inside this directory, use the patch with the command line : # patch -p1 -i /path/to/j2se1.4-i586_1.4.1.0.1-4.diff - now you can create a package with dpkg-buildpackage -rfakeroot or fakeroot debian/rules binary Mike -- "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded
Re: j2re1.3 plugin for mozilla isn't working.
> Has anyone else noticed this? I know that the unofficial j2se1.4 packages consistently crash under certain conditions when using JNI with C++ code; this is related to the fact that the j2se1.4 packages are still built using g++-2.95 whereas the default C++ compiler for debian is g++-3.x. Don't know if this is related to the mozilla problem or not. You could try downloading your own Java runtime from blackdown.org and using that instead of the unofficial debian packages; this fixed the JNI crashes for me. Ben.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 11:48:26PM -0500, Adam Majer wrote: > Sebastian Kapfer wrote: > >I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > >would count... > > > > I once read somewhere that you should _never_ compile in 486 > optimizations for use in processors other than the 486. Apparently > since 486 optimized code is padded a lot with NOPs. > > Apparently you are much better off on a Pentium or Athlon with > i386 optimized code than i486 optimized one. > > > Hence if we are going to migrate from i386, we should not > go to CPU like i486 and just move to a Pentium Classic > code (i586). I vaguely recall something similar about the i586. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpGGQSuO4gzE.pgp Description: PGP signature
Re: Update re: read-only root filesystem
Thomas Hood wrote: >No need. It is sufficient that /tmp/ and /dev/ be separate, writable, >filesystems. It is a local decision whether to make these tmpfs and >devfs, respectively. I've successfully run without a writeable dev but with devptsfs. How much "writeability" is required depends on how much you want to achieve. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Jun 22, Herbert Xu <[EMAIL PROTECTED]> wrote: >There is no technical reason why we can't support libc5 anymore. The only >reason that this is being discussed is that nobody has stood up to maintain >the package. This looks like a good enough reason to me. -- ciao, | Marco | [1676 advirpG9WvvSg]
Re: Update re: read-only root filesystem
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote: >[2003/06/22 11:13:11, 0] passdb/pdb_smbpasswd.c:startsmbfilepwent(237) > startsmbfilepwent_internal: failed to set 0600 permissions on password file > /etc/samba/smbpasswd. Error was Read-only file system > .unable to open passdb database. > >Moving both /etc/samba/MACHINE.SID and /etc/samba/smbpasswd to /run/samba >solves the problem > >Remarks? Why not /var/lib/samba? BTW, your README file is wrong: pppd will write to /etc/ppp/resolv.conf only if requested by the user with the usepeerdns configuration option. -- ciao, | Marco | [1677 prL1kY2AWFbTw]
j2re1.3 plugin for mozilla isn't working.
Has anyone else noticed this? -- Thomas E. Vaughan <[EMAIL PROTECTED]>
Re: Update re: read-only root filesystem
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote: >Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a >good idea) for future releases? For your ro-root system: definitely yes. For debian, don't dare. -- ciao, | Marco | [1679 corp.qbtCr/Hg]
Re: Update re: read-only root filesystem
On Jun 22, Thomas Hood <[EMAIL PROTECTED]> wrote: >The question is: Should we concede that a separate /dev/ fs is >required for running with a read-only root filesystem, or should we >take steps to eliminate fiddling with /dev/ files? I haven't Yes. Consoles *must* have their ownership changed. -- ciao, | Marco | [1678 riERn/qKVhs02]
Re: Update re: read-only root filesystem
On Sun, 2003-06-22 at 11:52, Xavier Roche wrote: > Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?) > allows you not to resevre space for /tmp on a specific partition Remark added. > > The question is: Should we concede that a separate /dev/ fs is > > required for running with a read-only root filesystem > > Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a > good idea) for future releases? No need. It is sufficient that /tmp/ and /dev/ be separate, writable, filesystems. It is a local decision whether to make these tmpfs and devfs, respectively. -- Thomas
Re: kullervo (sbuild/m68k) broken?
On 2003-06-22T21:53:01+1000 (Sunday), Andrew Lau wrote: > I haven't seen anyone mention this on debian-devel or debian-68k yet, > so before anymore time is wasted, could someone please take a look into > kullervo (sbuild/m68k)? Every build the last few days has failed due to > the following fatal error: > > dpkg: failed to open package info file > `/usr/local/home/buildd/build/chroot-unstable/var/lib/dpkg/available' > for reading: No such file or directory sysvinit's chroot breakage in unstable might have something to do with that: http://bugs.debian.org/197991 -towo -- circa mea pectora multa sund suspiria de tua pulchritudine que me ledunt misere tui lucent oculi sicut solis radii sicut splendor fulguris lucem donat tenebris pgpLBuvnsBzFb.pgp Description: PGP signature
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Sat, Jun 21, 2003 at 12:26:52PM -0500, John Goerzen wrote: > Why not just ship an old binutils/gcc to build the old libc5 binaries? > I really don't understand why this is such a difficult problem. If, for > instance, gcc 2.7.2 could build these things three years ago, why can't it > now? It's not as if some fundamental kernel structures have changed in a > hugely incompatible way; other binaries from that era work fine. That's what we have been doing for GCC: | $ i486-linuxlibc1-gcc --version | 2.7.2.3 (though not for binutils). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgphIKMm9Y1H5.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
Andreas Barth wrote: > * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > >>problem here (C++ ABI compatibility with other Linux distributions). The >>discussion is now about *how* to fix this bug: >>1. just bump minimum supported i386-family processor to i486 > > 1a. like 1, but just for c++-packages. As has been pointed out many times before and in this thread, dropping c++ support for i386 is much like dropping support completely, as important base packages (e.g. apt [0]) depend on it. Cheers T. 0. According to the priority and section, of course. pgpwGTXt3rchh.pgp Description: PGP signature
Re: Update re: read-only root filesystem
On Sun, Jun 22, 2003 at 11:52:45AM +0200, Xavier Roche wrote: > > To tell the truth, I didn't realize that so many files in /dev/ > > were being fiddled. Obviously, one solution to the problem is > > to have a separate writable /dev/ filesystem, e.g., devfs. > > Note that devfs is still "experimental" in 2.4 > > Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?) > allows you not to resevre space for /tmp on a specific partition > > > The question is: Should we concede that a separate /dev/ fs is > > required for running with a read-only root filesystem > > Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a > good idea) for future releases? tmpfs - yes (tmpfs is a requirement for posix shm), devfs - no, at least not until it's been cleaned up properly. Afaik it still has quite some race conditions in the v2.4, and there are still things left that need to be solved in a nice manner (just ask Alexander Viro...) [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Update re: read-only root filesystem
On Sun, Jun 22, 2003 at 11:32:57AM +0200, Thomas Hood wrote: > On Sun, 2003-06-22 at 01:02, Xavier Roche wrote: > > There are other problems : for example it seems that the system > > changes the /dev/ttyXX or /dev/pts/XX ownership depending on who is being > > logged in.. > > To tell the truth, I didn't realize that so many files in /dev/ > were being fiddled. Obviously, one solution to the problem is > to have a separate writable /dev/ filesystem, e.g., devfs. It's a historical thing. When you login you are given ownership of your tty device. The 'mesg' command twiddles these permissions so you can control who can write to your terminals. More recently, some distributions change ownership of cdroms and other devices to allow certain other things. For remote logins devpts solves the problem. I remember (a long time ago) being locked out of my machine because a read-only /dev prevented me logging in (login would complain about not being able to change ownership). > The question is: Should we concede that a separate /dev/ fs is > required for running with a read-only root filesystem, or should we > take steps to eliminate fiddling with /dev/ files? I haven't > looked into this question at all, since I have been satisfied with > devfs. It is much easier. I remember once arranging for /dev to be a ramdisk to solve the problem. The number of places that touch /dev would be many. > It is worth filing a report to ask that the script not try to > change the permissions and ownership of the pipe if it is not > necessary to do so, and that it tolerate failure. I'll file it. Tolerating failure would at least allow you to test with minimal problems. -- Martijn van Oosterhout http://svana.org/kleptog/ > "the West won the world not by the superiority of its ideas or values or > religion but rather by its superiority in applying organized violence. > Westerners often forget this fact, non-Westerners never do." > - Samuel P. Huntington pgpUjab6cWYPL.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
* "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > problem here (C++ ABI compatibility with other Linux distributions). The > discussion is now about *how* to fix this bug: > 1. just bump minimum supported i386-family processor to i486 1a. like 1, but just for c++-packages. > 2. like 1, but bump to some other processor. this is not strictly needed >to fix the bug, but it might be a good idea for other reasons. >Dropping other architectures to fix this bug is probably not a good >idea, as it won't fix the bug. > 3. bump the supported processor, and rename the port > 4. like 3, and also add an i386 distribution which does not support >C++ at all > 5. like 4, but support C++ in a way incompatible with other Linux >distributions in the i386 distribution. Cheers, 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
RE: Bug#198158: architecture i386 isn't i386 anymore
Hi all, I feel this whole discussion is somehow going into the wrong direction. What does it matter now whether we drop support for i386 and i486 (and possibly more), or just i386? Sooner or later we'll have the same problem (of changing the arch support being so difficult) again, if not with ix86 architectures, then with some other architecture. If you ask me, the proper long-term solution would be to make the arch names sub-arch independent (i.e. "ix86" or "ia32" instead of "i386"), and then make the archs have versions (i.e. "ix86 3" = "i386", "ix86 5" = "i586") and -- if this can be viably done somehow -- features (i.e. "ix86 5 +mmx" = P MMX, "ix86 6 +sse" = P III). This would ease adding and dropping (and specifying required) arch support immensely in the future. (A different syntax like "ix86-5-mmx" might be better, consider this a matter of discussion.) I know it isn't simple to make these changes in Debian. What do you think? Julian.
Re: Update re: read-only root filesystem
> To tell the truth, I didn't realize that so many files in /dev/ > were being fiddled. Obviously, one solution to the problem is > to have a separate writable /dev/ filesystem, e.g., devfs. Note that devfs is still "experimental" in 2.4 Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?) allows you not to resevre space for /tmp on a specific partition > The question is: Should we concede that a separate /dev/ fs is > required for running with a read-only root filesystem Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a good idea) for future releases? > It is worth filing a report to ask that the script not try to > change the permissions and ownership of the pipe if it is not > necessary to do so, and that it tolerate failure. I'll file it. Okay.
Re: Update re: read-only root filesystem
On Sun, 2003-06-22 at 01:02, Xavier Roche wrote: > There are other problems : for example it seems that the system > changes the /dev/ttyXX or /dev/pts/XX ownership depending on who is being > logged in.. To tell the truth, I didn't realize that so many files in /dev/ were being fiddled. Obviously, one solution to the problem is to have a separate writable /dev/ filesystem, e.g., devfs. The question is: Should we concede that a separate /dev/ fs is required for running with a read-only root filesystem, or should we take steps to eliminate fiddling with /dev/ files? I haven't looked into this question at all, since I have been satisfied with devfs. > Is there a list of devices that are supposed to change (rights/ownership) > during time? Look in the SE Linux packages for this kind of information. > And should I fill a BTS for the /etc/init.d/sysklogd bogus with > read-only /dev problem anyway? It is worth filing a report to ask that the script not try to change the permissions and ownership of the pipe if it is not necessary to do so, and that it tolerate failure. I'll file it. -- Thomas
Re: Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: While we're at it, I fail to see the logic of removing support for i386 while we still support m68k. Because there is a bug that only applies to i386 (see the subject). I wish everybody would focus on fixing this specific bug. There may be many good or bad things that can be said about dropping architecture support. This is not what this bug is about: we need to fix a real problem here (C++ ABI compatibility with other Linux distributions). The discussion is now about *how* to fix this bug: 1. just bump minimum supported i386-family processor to i486 2. like 1, but bump to some other processor. this is not strictly needed to fix the bug, but it might be a good idea for other reasons. Dropping other architectures to fix this bug is probably not a good idea, as it won't fix the bug. 3. bump the supported processor, and rename the port 4. like 3, and also add an i386 distribution which does not support C++ at all 5. like 4, but support C++ in a way incompatible with other Linux distributions in the i386 distribution. There are probably more options, but anybody proposing them, or speaking in favour or against one of these options should ask herself whether the message really helps in resolving this bug. Regards, Martin
Re: Update re: read-only root filesystem
> this is not a problem due to devpts filesystem. Okay, using devfs it works perfectly. A remaining problem is also Samba: [2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85) unable to open or create file /etc/samba/MACHINE.SID. Error was Read-only file system So actually samba writes to /etc/samba .. The problem also occurs for the pwd database (sync with other machines) [2003/06/22 11:13:11, 0] passdb/pdb_smbpasswd.c:startsmbfilepwent(237) startsmbfilepwent_internal: failed to set 0600 permissions on password file /etc/samba/smbpasswd. Error was Read-only file system .unable to open passdb database. Moving both /etc/samba/MACHINE.SID and /etc/samba/smbpasswd to /run/samba solves the problem Remarks?
Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: As I say this, I'm sure people can say the same about i486 and even i386 machines. Why exactly do we need to remove this support? Read the bug report with the number you put in your Subject. Regards, Martin
Re: RFC: fewer vim variants
On Sunday 15 June 2003 17:39, Marc Wilson wrote: > On Sun, Jun 15, 2003 at 11:23:34AM +0200, Stefano Zacchiroli wrote: > > What about a version _with_ all non-threaded interpreters, but _without_ > > gtk2/kde support? > > That would be console Vim, from either package. The GUI doesn't add so > much to it that you'd really feel it. > > Just never run "gvim" or "vim -g". :) I guess the main objection is dependencies: why should I install kde or gtk libs just to run a console vim with perl? -- vbi -- random link of the day: http://fortytwo.ch/sienapei/pohmogun pgphdBS4sbmLR.pgp Description: signature
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
Le sam 21/06/2003 à 19:26, John Goerzen a écrit : > > You, and rest of the minority who use libc5 program, can dual-boot > > an older distribution of Debian (say potato) where the programs still > > work. Yes, it can be a hassle, but it works. > > Assuming it supports your hardware. Which it is not entirely likely to do. > For instance: > > Many video cards require XFree 4.3.x or above. They require agpgart in the > kernel. They require iwconfig and other wireless tools. There are a whole > host of things that are not necessarily going to work from old > distributions, and the situation is only getting worse. Then you can still debootstrap the old distribution inside your existing system and run your software from the chroot. This is possible as long as the kernel supports libc5, and even if it gets dropped, there is user-mode-linux. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote: > Tell me, you seriously think that there is a libc5 program still around > that uses DRI ? Hell, libc5 was abandoned well before DRI even existed. the only libc5 program I do use is netscape 4.77 because it is compatible to some pages where mozilla/opera/konquerror fails. I would hate to reboot, to just open that page. But hopefully sometimes the mozilla bug gets fixed, and then i will be libc5 free :) 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: Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 12:37:21PM -0500, John Goerzen wrote: > On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote: > > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support > > for 386 and 486, I'd love if I could keep my home edgge router running the > > way it is thank you very much (and I'm happy with the great job the Security > > Team is doing). Not that the flea market value of a Pentium Classic is that > > high nowadays, but why fix what works? I thought Free Software was above > > planned obsolescence... > > While we're at it, I fail to see the logic of removing support for i386 > while we still support m68k. Because there are m68k maintainers and m68k boxes with enough disk-space and memory to buildall the packages. And a 68060 should be a match for low-end pentiums, should it not ? Friendly, Sven Luther
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Sat, Jun 21, 2003 at 12:26:52PM -0500, John Goerzen wrote: > On Thu, Jun 19, 2003 at 09:43:23PM +0200, David Weinehall wrote: > > Alternative 1: > > > > You, and rest of the minority who use libc5 program, can dual-boot > > an older distribution of Debian (say potato) where the programs still > > work. Yes, it can be a hassle, but it works. > > Assuming it supports your hardware. Which it is not entirely likely to do. > For instance: > > Many video cards require XFree 4.3.x or above. They require agpgart in the > kernel. They require iwconfig and other wireless tools. There are a whole Tell me, you seriously think that there is a libc5 program still around that uses DRI ? Hell, libc5 was abandoned well before DRI even existed. Friendly, Sven Luther
advise for packaging duali "arabic spell checker"
Hi all, I'm trying to package duali "an arabic spell checker" www.arabeyes.org currently i'm having a small problem there is duali itself and the data files. the db files are built from the data files using a python script. the upstream wants 2 things: the script used to build the db files to be moved to the duali package from the data package! and to distribute the data files in text form and they should be built on the user machine during installation. the data files "text" compressed are 1.1 MB while the db are 2.7 MB "large size difference as you can notice" i was thinking about splitting duali itself into 2 packages: 1- duali "the main dictionary" 2- duali-dev "contain the script" duali-data build-depends on duali-dev while duali itself depend only on duali-data I really don't know what to do so i thought about asking here for help. PS. duali currently is implemented in python. but the final version'll be C++ -- -- Katoob Main Developer Linux registered user # 224950 ICQ # 58475622 FIRST make it run, THEN make it run fast "Brian Kernighan". -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.fsf.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature pgpN3ue1gqChV.pgp Description: PGP signature
Bug#198158: architecture i386 isn't i386 anymore
On Sat, 21 Jun 2003, John Goerzen wrote: > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > Note that my idea was about patching the kernel that so the newer opcodes > > would be emulated in software. Everything would still work even on a 386, > > just slower -- and the speed decrease can be removed by running apt-build. > I don't see how that suggestion can possibly be taken seriously. Very few > i386 machines have the requisite disk space, memory, and swap space to build > large applications in Debian today. You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build doesn't even give the option of avoiding creation of .debs, and the bigger machine is one scp (or two mcopys in an extreme case) away. -- 1KB
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
John Goerzen <[EMAIL PROTECTED]> wrote:
>
> Why not just ship an old binutils/gcc to build the old libc5 binaries?
There is no technical reason why we can't support libc5 anymore. The only
reason that this is being discussed is that nobody has stood up to maintain
the package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: rsync in apt sources.list?
>> But why at the end of http://home.tiscali.cz:8080/~cz210552/aptrsync.html :
>> # Get anything we missed due to failed rsync's. [EMAIL PROTECTED] 24 Mar
>> 2002.
>> os.system('apt-get update')
well, it seems for me this just starts apt-get getting everything all
over again, http_proxy or not. So how does apt-get know if a
/var/lib/apt/lists/*Packages file is up to date or not? It might be
unaware that we have changed a Packages file underneath its nose
because it only knows about changes that it itself did?
Re: Bug#198158: architecture i386 isn't i386 anymore
Sebastian Kapfer wrote: I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote would count... I once read somewhere that you should _never_ compile in 486 optimizations for use in processors other than the 486. Apparently since 486 optimized code is padded a lot with NOPs. Apparently you are much better off on a Pentium or Athlon with i386 optimized code than i486 optimized one. Hence if we are going to migrate from i386, we should not go to CPU like i486 and just move to a Pentium Classic code (i586). - Adam PS. ASAIK, i486 is very similar to i386 if you compare them to a i585 processor. Not too many new instructions there.
