Re: find eating all memory
On Wed, Jan 02, 2002 at 06:45:53PM -0600, Bryan Andersen wrote: > > > on a simple 'find /var -name sendmail* -print' command, the find-process > > > eats all my memory (128 Meg RAM) > > > when there is no memory left, the process gets killed. Some information about the output (or lack thereof) might be usefuli. (In a bug report to findutils, of course.) > > > I work with debian woody with recent update, reiserfs, 128 meg RAM & 256 > > > meg SWAP on my P3 733 system. > > Check the file system for symbolic link loops. By default, find doesn't follow links. When forced to (-follow), it keeps track of inodes and doesn't enter the same directory twice. -- Glenn Maynard
Re: find eating all memory
On Wed, Jan 02, 2002 at 06:45:53PM -0600, Bryan Andersen wrote: > Andreas Rottmann wrote: > > > > Michael De Nil <[EMAIL PROTECTED]> writes: > > > > > Hi > > > > > > on a simple 'find /var -name sendmail* -print' command, the find-process > > > eats all my memory (128 Meg RAM) > > > when there is no memory left, the process gets killed. > > > > > > I work with debian woody with recent update, reiserfs, 128 meg RAM & 256 > > > meg SWAP on my P3 733 system. > > Check the file system for symbolic link loops. But these occur quite often.. especially with Nautilus - the Desktop directory has a link back to home. IMHO, find should be able to check for those loops. - Adam
bogus maintainers?
>From http://www.debian.org/devel/people, I see: Maintainer, Unknown Kernel Package <[EMAIL PROTECTED]> main: kernel-doc-2.4.5-r4k-kn04, kernel-source-2.4.5-r4k-kn04 What's up with this? This is not a legitimate maintainer address IMO. Thomas
proftpd with the security bug fixed still not in testing due to m68k
Hi, It seems the lack of a m68k package for proftpd 1.2.4-2 is stopping proftpd from propagating into testing, and the change between -1 and -2 is a security fix. However, the package should exist, as shown on: http://buildd.debian.org/fetch.php?&pkg=proftpd&ver=1.2.4-2&arch=m68k&stamp=1009311868&file=log&as=raw Can someone check this out please? -- 2. That which causes joy or happiness.
Re: mutt-1.3.24-3 complains of read-only /var/mail/foo
On Wed, Jan 02, 2002 at 11:00:58AM -0900, Christopher S. Swingley wrote: > > A quick search of the debian-devel archive didn't turn up > > anything about this, but I might have goofed the search. > > Anyway, mutt-1.3.24-2 works well enough for me, but 1.3.24-3 > > won't let me modify /var/mail/foo. > > # chown root:mail /usr/bin/mutt_dotlock > # chmod 2755 /usr/bin/mutt_dotlock > > $ ls -l /usr/bin/mutt_dotlock > -rwxr-sr-x1 root mail /usr/bin/mutt_dotlock This bug is fixed in mutt-1.3.25-1, and besides this minor glitch, it's important to upgrade to 1.3.25 because it fixes a rather serious security hole. Jan
Bug#127557: ITP: vectoroids -- vector-based rock-shooting game
Package: wnpp Version: N/A; reported 2002-01-02 Severity: wishlist * Package name: vectoroids Version : 1.0.5 Upstream Author : Bill Kendrick <[EMAIL PROTECTED]> * URL : http://www.newbreedsoftware.com/vectoriods/ * License : GPL Description : "Vectoroids" is a vector-based rock-shooting game similar to the arcade classic "Asteroids." It is an SDL game based on the source for "Agendaroids," an X-Window game written for the Agenda VR3 Linux-based PDA written by the same author. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux gleep 2.4.16 #1 Tue Dec 4 14:29:28 EST 2001 i686 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1
Re: find eating all memory
Andreas Rottmann wrote: > > Michael De Nil <[EMAIL PROTECTED]> writes: > > > Hi > > > > on a simple 'find /var -name sendmail* -print' command, the find-process > > eats all my memory (128 Meg RAM) > > when there is no memory left, the process gets killed. > > > > I work with debian woody with recent update, reiserfs, 128 meg RAM & 256 > > meg SWAP on my P3 733 system. Check the file system for symbolic link loops. -- | Bryan Andersen | [EMAIL PROTECTED] | http://www.nerdvest.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | "Linux, the OS Microsoft dosen't want you to know about.". | | -Bryan Andersen|
Re: EURO and CENT signs in the console keymaps
I demand that Miquel van Smoorenburg may or may not have written... > In article <[EMAIL PROTECTED]>, > Scott Dier <[EMAIL PROTECTED]> wrote: >> The best one is where microsoft put their symbol in >> 'iso-8859-1'-cp1252-winlatin1, which is in 80, instead of a4 where >> iso-8859-15 puts it. What does most codepages use? 80 or A4? Does >> iso-8859-1 even have anything in 80? Is this going to lead to lots of >> confusion? > Ah, so *that's* why I'm seeing a lot of open squares on webpages where I > should see a Euro symbol. Instead of using iso8859-15, the site is using M$ > bastard-8859-1. Well perhaps the Linux distro's should follow that example, > put a Euro symbol at 0x80 in the 8859-1 charset. It would not be completely > standards-compliant but it would be easy and useful. Or would that make us > just as bad as Microsoft where standards are concerned? There is precedent for this elsewhere; the E**o character appears at 0x80 in RISC OS 4's Latin* character sets. -- | Darren Salt | linux (or ds) at | nr. Ashington, | Linux PC, Risc PC | youmustbejoking | Northumberland | No Wodniws here | demon co uk | Toon Army | Let's keep the pound sterling "Bother", said Pooh, as he received his telephone bill.
Re: 2 package(s) to rebuild on i386/stable
On Wed, Jan 02, 2002 at 11:05:06PM +0100, Wichert Akkerman wrote: > That page is somewhat deceptive unfortunately. [snip] > kubrick: down It's reachable from here. Best Regards, -- Davide Puricelli, [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org Undergraduate Student of Computer Science at University of Bologna PGP key: finger [EMAIL PROTECTED] pgpJOX3tA9XbO.pgp Description: PGP signature
Re: 2 package(s) to rebuild on i386/stable
Previously Steve Langasek wrote: > Is the lack of current information on the machines page a result of > there being no one to keep the page up-to-date, or because no one tells > the page maintainer when a machine's status has changed? Mostly because debian-admin is aware of machine status but tends to take ages to update that page, if at all Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: how to move a config file during package upgrade
On Wed, Jan 02, 2002 at 03:17:09PM +0100, Wichert Akkerman wrote: > Previously Thomas Lange wrote: > > my package fai will have a new location for its configuration file > > /etc/fai.conf. The next version will use /etc/fai/fai.conf. How can I > > handle this in a preinst script during an upgrade ? Any examples would > > be fine. > > Move it in the preinst. Approximately: (new-version is the first version which uses /etc/fai/fai.conf) preinst: case "$1" in upgrade) version=$2 if dpkg --compare-versions "$2" lt new-version && test -f /etc/fai.conf; then mkdir -p /etc/fai mv /etc/fai.conf /etc/fai/fai.conf fi ;; esac If there is other preinst code which could fail, add: postrm: case "$1" in abort-upgrade) version=$2 if dpkg --compare-versions "$2" lt new-version && test -f /etc/fai/fai.conf; then mv /etc/fai/fai.conf /etc/fai.conf fi ;; esac So that if things go wrong, the user is not left with a broken installation. -- - mdz
Re: 2 package(s) to rebuild on i386/stable
On Wed, Jan 02, 2002 at 11:05:06PM +0100, Wichert Akkerman wrote: > Previously Thomas Bushnell, BSG wrote: > > According to http://db.debian.org/machines.cgi, there are fifteen > > machines running potato with access for developers. > That page is somewhat deceptive unfortunately. > auric: has packages from testing/unstable installed > debussy: only reachable through a gateway machine if you happen to > have an account on it > kubrick: down I guess I'm fortunate that the machines page is not kept up-to-date, or I wouldn't have tried sshing to kubrick the other day. ;) (kubrick is in fact up). > lully: down > pandora: has packages from testing/unstable installed > tervola: down Is the lack of current information on the machines page a result of there being no one to keep the page up-to-date, or because no one tells the page maintainer when a machine's status has changed? Presumably it's not because the machine admins don't know how to contact the page admins, given that an [EMAIL PROTECTED] address is printed clearly on the bottom of the webpage.. Cheers, Steve Langasek postmodern programmer pgp5YbR5TRhl1.pgp Description: PGP signature
Re: 2 package(s) to rebuild on i386/stable
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > According to http://db.debian.org/machines.cgi, there are fifteen > > machines running potato with access for developers. > > That page is somewhat deceptive unfortunately. Hrm. Seems to me that something should be done. For some value of "something"; not sure what tho.
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
* Wichert Akkerman | Previously Kevin Corry wrote: | > Could the "ldconfig" call be added to the top-level Makefile "install" | > target? | | No, since you might not be installing on a real system but a temporary | location to build a package or for some other reason. Also if you | are not running as root but with fakeroot ldconfig will fail. In which case «ldconfig -n $libdir» should work just fine. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, Jan 02, 2002 at 04:00:21PM -0600, Kevin Corry wrote: > On Wednesday 02 January 2002 14:35, Matt Zimmerman wrote: > > It would sacrifice a little bit of bloat (libdlist.so on my i386 system is > > about 10k) for not having to worry about shared library management for this > > library. If you want to just keep the versioning in sync with the other > > library, that should work, too, or you can have a completely separate > > versioning scheme (in which case libdlist will need to go in a separate > > binary package). > > Hmm...libdlist.so is almost 50k on my system. And I don't think I have any > debugging turned on. That would be because my libdlist.so comes from my Debian packages, which run strip --strip-unneeded on shared objects. > In the documentation that we have, I have tried to move towards using the > EVMS terminology, so I would suggest the same for the man pages. OK. -- - mdz
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 15:01, Matt Zimmerman wrote: > On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote: > > Basically, we don't want to force the user-interfaces to to be > > recompiled on every minor change to the engine core that doesn't change > > any of the external APIs. We only intend to change these APIs across a > > major version change. At most, new APIs may be added, but existing ones > > (and their defined functionality) will remain the same. Having the soname > > include only the major number means the existing binary user-interfaces > > could be used if a new minor or patch-level version of the engine library > > appears. > > OK, so it sounds like the ABI should be stable enough to do normal library > versioning. So it should start with libevms.so.0 and increment with each > major release. You can basically do what you want with the rest of the > version number (libevms.so.0.x.y or such) to indicate minor revisions, but > it is not, in general, a good idea to try to make this correspond to a > software release. libtool has this to say about it: > > >*_Never_* try to set the interface numbers so that they correspond > to the release number of your package. This is an abuse that only > fosters misunderstanding of the purpose of library versions. Instead, > use the `-release' flag (*note Release numbers::), but be warned that > every release of your package will not be binary compatible with any > other release. > > > The -release flag gives you sonames of the form libfoo-x.y.z.so as we > discussed earlier, while -version-info (the normal case) lets you specify a > parameter indicating which interfaces are available in this version of the > library, and handles the actual library versioning automatically. Hmmm.. Well, for the time being, I have updated the engine/Engine/Makefile in CVS to use libevms.so.major as the SONAME. As for the "release" vs "app API" version numbers, we will have to discuss this some more. Perhaps we will need to come up with a separate version number just for the app API, similar to how we have a separate version for the IOCTL interface in the kernel code. In any case, I'll be looking forward to seeing your automake/libtool setup. Hopefully it can help us clear up some of these issues. -Kevin
Re: EURO and CENT signs in the console keymaps
Eduard Bloch <[EMAIL PROTECTED]> writes: > - the Norwegian and Swedish keymap (relative to US layout: <4>) All my keyboards (swedish) have it on AltGr + e. Shift + 4 is still the ¤-symbol (currency). /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: 2 package(s) to rebuild on i386/stable
Previously Thomas Bushnell, BSG wrote: > According to http://db.debian.org/machines.cgi, there are fifteen > machines running potato with access for developers. That page is somewhat deceptive unfortunately. auric: has packages from testing/unstable installed debussy: only reachable through a gateway machine if you happen to have an account on it kubrick: down lully: down pandora: has packages from testing/unstable installed tervola: down Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 14:35, Matt Zimmerman wrote: > On Wed, Jan 02, 2002 at 08:32:28AM -0600, Kevin Corry wrote: > > If you are interested in creating an automake/libtool setup, give it a > > try and I will look it over and see if we can include it in the future. > > OK, will do. Great! > > > > Currently the dlist package doesn't have any version number, but I'm > > > > sure we can come up with one if it makes things easier. I will try to > > > > do that tomorrow. > > > > > > Since libdlist is so small (and not subject to a lot of revision), you > > > might just want to statically link it and avoid the issue altogether. > > > > I suppose that would be possible. But wouldn't that just bloat the size > > of the engine core and plugin libraries? > > It would sacrifice a little bit of bloat (libdlist.so on my i386 system is > about 10k) for not having to worry about shared library management for this > library. If you want to just keep the versioning in sync with the other > library, that should work, too, or you can have a completely separate > versioning scheme (in which case libdlist will need to go in a separate > binary package). Hmm...libdlist.so is almost 50k on my system. And I don't think I have any debugging turned on. I'll look into what changes would be necessary to make dlist a static library and let you know what I find out. > > > > [man pages for LvmUtils] > > > > > > I can certainly do that; for the most part, it should just be a matter > > > of copying the corresponding LVM man pages and noting differences in > > > behaviour, right? > > > > Pretty much. Those utilities are meant to model the ones from LVM. All of > > the options should be the same, except some of the options are ignored in > > EVMS, either because they aren't implemented yet or aren't pertinent. If > > you glance through the code in engine/UserInterfaces/LvmUtils, each > > source file has a function called parse_options() that should give you an > > idea of which options are ignored in EVMS. > > I will spend some time on this after I have a satisfactory set of initial > packages. One other thing, should I change the terminology in the man > pages to use the EVMS terms, since that is what the commands actually do, > or leave them with the LVM terms, since they correspond to the commands? In the documentation that we have, I have tried to move towards using the EVMS terminology, so I would suggest the same for the man pages. > > Ok. So the idea would be just to run "make configure" instead of > > explicitly calling "autoconf"? > > Yes. The automake stuff does a pretty good job of this, and it gets pretty > complex with all of autoconf's dependencies and re-generating individual > makefiles. I'll prepare an experimental automake patch so you can decide > if you want to go that way. Cool. -Kevin
Re: 2 package(s) to rebuild on i386/stable
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > Um, they don't need one. All Debian maintainers have access to a > > stable system, since Debian maintains some for just this sort of > > reason. > > Debian does not unfortunately. According to http://db.debian.org/machines.cgi, there are fifteen machines running potato with access for developers. If anything, the problem is that there isn't an i386 running unstable.
Bug#127510: ITP: sqlite -- An SQL engine in a C library
Package: wnpp Version: N/A; reported 2002-01-02 Severity: wishlist * Package name: sqlite Version : 2.2.0 Upstream Author : D. Richard Hipp <[EMAIL PROTECTED]> * URL : http://www.hwaci.com/sw/sqlite/ * License : Probably public domain, but I'll have to make sure. Description : An SQL engine in a C library The source will surely produce this packages: libsqlite The C library libsqlite-dev The C library - development files sqlite The commandline interface but I probably will package the docs (as found in the WWW): sqlite-doc, and the TCL bindings: sqlite-tcl (or libsqlite-tcl). Andy -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux alice 2.4.13 #1 Mon Dec 17 10:59:08 CET 2001 i686 Locale: LANG=C, LC_CTYPE=
Re: find eating all memory
Michael De Nil <[EMAIL PROTECTED]> writes: > Hi > > on a simple 'find /var -name sendmail* -print' command, the find-process > eats all my memory (128 Meg RAM) > when there is no memory left, the process gets killed. > > I work with debian woody with recent update, reiserfs, 128 meg RAM & 256 > meg SWAP on my P3 733 system. > > Here is what I get using 'top': > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM CTIME COMMAND > 24610 root 14 0 98624 82M 400 R21.2 76.8 0:17 find > > I cannot reproduce that neither on my Athlon 900Mhz, 384MB, ext3fs nor on my Duron 700MHz, 192MB, reiserfs systems. But anyway, you should probably file a bug against findutils. The maintainer/upstream may have more of a clue what causes this. Perhaps you should try another kernel (2.2/2.4) first, to preclude a kernel bug. Andy -- Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | [EMAIL PROTECTED] Georg-Rendlweg 28| A-5111 Bürmoos | Austria | Europe 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
Re: DEBNAME or DEBFULLNAME?
On Wed, Jan 02, 2002 at 09:18:39PM +0100, Gerfried Fuchs wrote: > [DEBNAME vs DEBFULLNAME] > > I filed a bug against devscripts (#115601) ages ago about this, i got > > bitten nastily by this. I personally prefer DEBNAME. > > It seems that we can't get a consensus Which "some other tools" > are those you were speaking of in that bugreport? I have only got > answers regarding DEBFULLNAME but none regarding DEBNAME. > > I personally would like to have DEBNAME also - but that's not our call. > There is a broader mass (of programs) that seems to be using DEBFULLNAME > than DEBNAME (still, I only know about reportbug) so I'm about to file > it as bugreport against that package for the start. My .zshrc sets DEBFULLNAME and everything I use works with that. 'nuff said ;o) -- 2. That which causes joy or happiness.
Re: Missing security uploads
On Wed, Jan 02, 2002 at 09:46:45PM +0100, Martin Schulze wrote: > > > > > > > DSA 041 > > > > > > > Package: joe > > > > > > > Preparer: Wichert Akkerman > > > > > > > > > > Actually, I did this at one point, but then elmo said it won't get > > > > > accepted. > > > > > > > > because of the two different joe_2.8.orig.tar.gz files. > > > > > > -rw-rw-r--1 troupdebadmin 192245 Mar 9 2001 > > > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > > > -rw-r--r--1 joey Debian 192245 Dec 1 2000 > > > joe_2.8.orig.tar.gz > > > > > > 84c1aebfce7876b8639945da3c29f204 > > > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > > > 84c1aebfce7876b8639945da3c29f204 joe_2.8.orig.tar.gz > > > > > > Don't look too different for me. > > > > That's because you're not looking in the right place. See pool/main/j/joe: > > > > -rw-rw-r--1 troupdebadmin 193756 Mar 9 2001 joe_2.8.orig.tar.gz > > Aha. > > But: 1st, I'm interested in stable, 2nd the katie db told me the path > from above elmo said that katie will get confused with another stable upload of joe and had me remove the upload from incoming. I now remembered that my upload is still in auric:~joy/j/ Ask him if and how to get it into stable. > and 3rd why do potato and unstable/testing have different .orig.tar.gz > versions? I changed the source format to DBS in unstable. -- 2. That which causes joy or happiness.
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote: > What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the > filename for the library (where x is the version major number, y is minor, > and z is patchlevel)? This seems to be common on many of the libraries on > my system. It all comes down to binary compatibility. In the end, the shared library versioning scheme does not necessarily have any relationship to the version numbering of the software, and in the most correct case, it necessarily does not. If the soname is libevms.so.x, then any binary compiled against a given x must be able to link and run correctly with any other (to be practical, newer) version of libevms which will provide /usr/lib/libevms.so.x. If evms is ready to make that commitment to binary compatibility, then it should ship /usr/lib/libevms.so.x.y.z, and symlinks /usr/lib/libevms.so.x and /usr/lib/libevms.so, where y.z denotes revisions that do not break binary compatibility. If the interfaces are still changing a lot at this point in development, it would be wiser to use libevms-a.b.c.so so that no release will be binary compatible with any other release. > Basically, we don't want to force the user-interfaces to to be recompiled on > every minor change to the engine core that doesn't change any of the external > APIs. We only intend to change these APIs across a major version change. At > most, new APIs may be added, but existing ones (and their defined > functionality) will remain the same. Having the soname include only the major > number means the existing binary user-interfaces could be used if a new minor > or patch-level version of the engine library appears. OK, so it sounds like the ABI should be stable enough to do normal library versioning. So it should start with libevms.so.0 and increment with each major release. You can basically do what you want with the rest of the version number (libevms.so.0.x.y or such) to indicate minor revisions, but it is not, in general, a good idea to try to make this correspond to a software release. libtool has this to say about it: *_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the `-release' flag (*note Release numbers::), but be warned that every release of your package will not be binary compatible with any other release. The -release flag gives you sonames of the form libfoo-x.y.z.so as we discussed earlier, while -version-info (the normal case) lets you specify a parameter indicating which interfaces are available in this version of the library, and handles the actual library versioning automatically. -- - mdz
Re: Missing security uploads
Martin Schulze wrote: > But: 1st, I'm interested in stable, 2nd the katie db told me the path > from above, and 3rd why do potato and unstable/testing have different > .orig.tar.gz versions? Oh, and how are we supposed to fix that? Regards, Joey -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists.
Re: Missing security uploads
Josip Rodin wrote: > On Wed, Jan 02, 2002 at 09:19:52PM +0100, Martin Schulze wrote: > > > > > > DSA 041 > > > > > > Package: joe > > > > > > Preparer: Wichert Akkerman > > > > > > > > Actually, I did this at one point, but then elmo said it won't get > > > > accepted. > > > > > > because of the two different joe_2.8.orig.tar.gz files. > > > > -rw-rw-r--1 troupdebadmin 192245 Mar 9 2001 > > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > > -rw-r--r--1 joey Debian 192245 Dec 1 2000 joe_2.8.orig.tar.gz > > > > 84c1aebfce7876b8639945da3c29f204 > > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > > 84c1aebfce7876b8639945da3c29f204 joe_2.8.orig.tar.gz > > > > Don't look too different for me. > > That's because you're not looking in the right place. See pool/main/j/joe: > > -rw-rw-r--1 troupdebadmin 193756 Mar 9 2001 joe_2.8.orig.tar.gz Aha. But: 1st, I'm interested in stable, 2nd the katie db told me the path from above, and 3rd why do potato and unstable/testing have different .orig.tar.gz versions? Regards, Joey -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists.
Re: DEBNAME or DEBFULLNAME?
On Wed, 2002-01-02 at 20:18, Gerfried Fuchs wrote: > [please copy me on replies] > > * Rob Bradford <[EMAIL PROTECTED]> [2002-01-02 20:03]: > [DEBNAME vs DEBFULLNAME] > > I filed a bug against devscripts (#115601) ages ago about this, i got > > bitten nastily by this. I personally prefer DEBNAME. > Okay, so reportbug was the only thing that used it, so maybe we should just agree to use DEBFULLNAME. Now go do something productive... That was the reason for me to kick that topic. -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org pgpZmuRSOf3Qi.pgp Description: PGP signature
Re: What config file for a .pm perl module ?
Eric Van Buggenhaut <[EMAIL PROTECTED]> writes: > The upstream code requires the administrator to introduce the user > data (username, password, port, database, etc.) in the same Password.pm file, > which looks horrible to me. Ok, we've seen some solutions but the real problem remains: The perl modules in question can only be used proberly by users with acess to the configuration file. Why shouldn't normal users be able to use the module in a unrestricted way? Perl programmers should be able to make a config-hash themself and feed that to the module (probaly the constructor for the objects belonging to the module.) -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Missing security uploads
On Wed, Jan 02, 2002 at 09:19:52PM +0100, Martin Schulze wrote: > > > > > DSA 041 > > > > > Package: joe > > > > > Preparer: Wichert Akkerman > > > > > > Actually, I did this at one point, but then elmo said it won't get > > > accepted. > > > > because of the two different joe_2.8.orig.tar.gz files. > > -rw-rw-r--1 troupdebadmin 192245 Mar 9 2001 > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > -rw-r--r--1 joey Debian 192245 Dec 1 2000 joe_2.8.orig.tar.gz > > 84c1aebfce7876b8639945da3c29f204 > /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz > 84c1aebfce7876b8639945da3c29f204 joe_2.8.orig.tar.gz > > Don't look too different for me. That's because you're not looking in the right place. See pool/main/j/joe: -rw-rw-r--1 troupdebadmin 193756 Mar 9 2001 joe_2.8.orig.tar.gz -- 2. That which causes joy or happiness.
Re: Bug#123887: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, Jan 02, 2002 at 08:32:28AM -0600, Kevin Corry wrote: > On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote: > > I would recommend libevms-0.2.4.so, as you said above, over the current > > libevms.0.2.4.so, since many other programs use that convention. > > I have tried changing the soname to the version-specific name, and > everything seems to work. The only problem I see now is that the user must > run "ldconfig" after installing, because the user-interfaces are linked > against "evms", and not against the specific version of evms. But this > really shouldn't be a problem. It also means we probably don't need to > explicitly create the sym-link on "make install", since "ldconfig" will do > that. Could the "ldconfig" call be added to the top-level Makefile > "install" target? Anything linking against the library must be linked against the versioned name, so that the library doesn't change on them unexpectedly. For example: libsnmp-0.4.2.so => /usr/lib/libsnmp-0.4.2.so (0x4001f000) is correct, and: libevms.so => /usr/lib/libevms.so (0x40027000) is not. After changing the soname, if you re-link the executables against the new library, it should embed the versioned name in the executable so that it looks more like: libevms-0.2.4.so => /usr/lib/libevms-0.2.4.so (0x40027000) > If you are interested in creating an automake/libtool setup, give it a try > and I will look it over and see if we can include it in the future. OK, will do. > > > Currently the dlist package doesn't have any version number, but I'm sure > > > we can come up with one if it makes things easier. I will try to do that > > > tomorrow. > > > > Since libdlist is so small (and not subject to a lot of revision), you > > might just want to statically link it and avoid the issue altogether. > > I suppose that would be possible. But wouldn't that just bloat the size of > the engine core and plugin libraries? It would sacrifice a little bit of bloat (libdlist.so on my i386 system is about 10k) for not having to worry about shared library management for this library. If you want to just keep the versioning in sync with the other library, that should work, too, or you can have a completely separate versioning scheme (in which case libdlist will need to go in a separate binary package). > > By the way, dlist.h defines a type dlist_t, and as I understand it, > > types ending with the "_t" suffix are reserved by POSIX. > > Is that going to be a huge problem? Changing that is going to entail a lot > of searching-and-replacing in the code. And evms has other data structures > with similar naming-schemes (see engine/include/enginestructs.h). Are > those a problem as well? It isn't causing any immediate problems for me, so unless POSIX decides to define a type dlist_t and it is widely implemented, it should be safe for now. It's just a standards conformance/cosmetic type of issue. > > > [man pages for LvmUtils] > > > > I can certainly do that; for the most part, it should just be a matter > > of copying the corresponding LVM man pages and noting differences in > > behaviour, right? > > Pretty much. Those utilities are meant to model the ones from LVM. All of > the options should be the same, except some of the options are ignored in > EVMS, either because they aren't implemented yet or aren't pertinent. If > you glance through the code in engine/UserInterfaces/LvmUtils, each source > file has a function called parse_options() that should give you an idea of > which options are ignored in EVMS. I will spend some time on this after I have a satisfactory set of initial packages. One other thing, should I change the terminology in the man pages to use the EVMS terms, since that is what the commands actually do, or leave them with the LVM terms, since they correspond to the commands? > I've applied your Makefiles patch, and everything seems to work fine. Only > one other question: In the top-level make.rules, we have some #defines > that are based on configuration options (notably PluginDirectory). This is > set so the core engine will know which directory to look in to find the > plugin libraries. Does the DESTDIR construct affect this define? In other > words, should the PluginDirectory define be prepended with DESTDIR as > well? My guess is no, based on your quote above, which implies that > DESTDIR is kind of a temporary location. You are correct that those variables should not reference DESTDIR. This is precisely the difference between DESTDIR and modifying the prefix variables; it just specifies where to place the files for installation, not the location from where they will actually be executed. > > Is the idea to get the latest aclocal.m4, which has the latest list of > > plugin subdirectories? If so, another method would be to have a Makefile > > rule for building configure which depends on aclocal.m4, something like: > > > > configure: configure.in aclocal.m4 > > autoconf > > > > (this
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 14:04, Adam Heath wrote: > On Wed, 2 Jan 2002, Kevin Corry wrote: > > What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the > > filename for the library (where x is the version major number, y is > > minor, and z is patchlevel)? This seems to be common on many of the > > libraries on my system. > > > > Basically, we don't want to force the user-interfaces to to be > > recompiled on every minor change to the engine core that doesn't change > > any of the external APIs. We only intend to change these APIs across a > > major version change. At most, new APIs may be added, but existing ones > > (and their defined functionality) will remain the same. Having the soname > > include only the major number means the existing binary user-interfaces > > could be used if a new minor or patch-level version of the engine library > > appears. > > So, when you need to make an incompatible change, what would you do? There > is no version in the SONAME, so you are SOL(shit, out of luck). > > The SONAME *MUST* has a version encoded into it. Otherwise, I would rather > see this library NOT included in debian, no matter how good it is, or what > it does. Um, I just suggested using libevms.so.x as the soname. x is the major version of the library, so the SONAME has a version number encoded in it. My question was simply, how detailed a version number does it need to be. Is the major number sufficient, or does it need to be major.minor.patchlevel? If an incompatible API change needs to be made, the major number will be incremented, and thus the existing binaries will need to be recompiled. As I said, many other existing libraries on my system use just the major version in their SONAMEs (e.g. libc.so.6, libdl.so.2, etc), so it seems that this method should be sufficient. -Kevin
Re: Missing security uploads
Josip Rodin wrote: > On Wed, Jan 02, 2002 at 12:47:30AM +0100, Josip Rodin wrote: > > > maybe some other DD can pick out those security updates and upload > > > them to stable. > > > > > > > The people who have prepared a security advisory should upload the > > > > respective packages to stable as well. Hence please upload the > > > > referring packages to stable so potato will contain fixed packages > > > > some time: > > > > > > > > DSA 041 > > > > Package: joe > > > > Preparer: Wichert Akkerman > > > > Actually, I did this at one point, but then elmo said it won't get accepted. > > because of the two different joe_2.8.orig.tar.gz files. -rw-rw-r--1 troupdebadmin 192245 Mar 9 2001 /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz-rw-r--r-- 1 joey Debian 192245 Dec 1 2000 joe_2.8.orig.tar.gz 84c1aebfce7876b8639945da3c29f204 /org/ftp.debian.org/ftp/dists/potato/main/source/editors/joe_2.8.orig.tar.gz 84c1aebfce7876b8639945da3c29f204 joe_2.8.orig.tar.gz Don't look too different for me. Next reason? Regards, Joey -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists.
Re: DEBNAME or DEBFULLNAME?
[please copy me on replies] * Rob Bradford <[EMAIL PROTECTED]> [2002-01-02 20:03]: [DEBNAME vs DEBFULLNAME] > I filed a bug against devscripts (#115601) ages ago about this, i got > bitten nastily by this. I personally prefer DEBNAME. It seems that we can't get a consensus Which "some other tools" are those you were speaking of in that bugreport? I have only got answers regarding DEBFULLNAME but none regarding DEBNAME. I personally would like to have DEBNAME also - but that's not our call. There is a broader mass (of programs) that seems to be using DEBFULLNAME than DEBNAME (still, I only know about reportbug) so I'm about to file it as bugreport against that package for the start. So long, Alfie [trying to destroy inconsistencies and not plant bad blood] -- I don't know, chmod g+a something and the world goes crazy :) -- Craig Small, [EMAIL PROTECTED] pgpvbpLQR1kuF.pgp Description: PGP signature
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, 2 Jan 2002, Kevin Corry wrote: > What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the > filename for the library (where x is the version major number, y is minor, > and z is patchlevel)? This seems to be common on many of the libraries on my > system. > > Basically, we don't want to force the user-interfaces to to be recompiled on > every minor change to the engine core that doesn't change any of the external > APIs. We only intend to change these APIs across a major version change. At > most, new APIs may be added, but existing ones (and their defined > functionality) will remain the same. Having the soname include only the major > number means the existing binary user-interfaces could be used if a new minor > or patch-level version of the engine library appears. So, when you need to make an incompatible change, what would you do? There is no version in the SONAME, so you are SOL(shit, out of luck). The SONAME *MUST* has a version encoded into it. Otherwise, I would rather see this library NOT included in debian, no matter how good it is, or what it does.
Re: DEBNAME or DEBFULLNAME?
> reportbug uses DEBNAME; dh_make, vim debchangelog filetype plugin use > DEBFULLNAME and I guess there might be other tools (emacs has something > similar but I don't know which one that uses) that use the one or the > other. I personally like to try to eliminate those inconsistencies and > bug the packages. > I filed a bug against devscripts (#115601) ages ago about this, i got bitten nastily by this. I personally prefer DEBNAME. -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org pgpc0bTRQmaoZ.pgp Description: PGP signature
Re: Thoughts on network detection and configuration on Debian
[Thomas Hood] > A master plan does not entail having a master tool, however. Debian could use kudzu or harddrake to automatically adapt to HW configuration changes. There is some work needed to get these to do sensible things with the HW detected (on Debian that is), but both being able to detect the HW is a start. :-)
Re: mutt-1.3.24-3 complains of read-only /var/mail/foo
> A quick search of the debian-devel archive didn't turn up > anything about this, but I might have goofed the search. > Anyway, mutt-1.3.24-2 works well enough for me, but 1.3.24-3 > won't let me modify /var/mail/foo. # chown root:mail /usr/bin/mutt_dotlock # chmod 2755 /usr/bin/mutt_dotlock $ ls -l /usr/bin/mutt_dotlock -rwxr-sr-x1 root mail /usr/bin/mutt_dotlock Chris -- Christopher S. Swingley phone: 907-474-2689 Computer / Network Manager email: [EMAIL PROTECTED] IARC -- Frontier ProgramGPG and PGP keys at my web page: University of Alaska Fairbanks www.frontier.iarc.uaf.edu/~cswingle pgpUC57DeP1i2.pgp Description: PGP signature
mutt-1.3.24-3 complains of read-only /var/mail/foo
A quick search of the debian-devel archive didn't turn up anything about this, but I might have goofed the search. Anyway, mutt-1.3.24-2 works well enough for me, but 1.3.24-3 won't let me modify /var/mail/foo. I just moved from testing to unstable today. Has anyone else seen this? -- Thomas E. Vaughan CloudSat Dynamic Spacecraft Simulation Ball Aerospace, Boulder, CO, USA
Re: EURO and CENT signs in the console keymaps
> However, I tend to spend most of the year living in the Netherlands, > which is one of the countries adopting the Euro, and there's no Euro > symbol in the fonts used by en_AU. I don't speak Dutch, so there's not much > point setting LANG to nl, nl_NL or whatever. And there's no [EMAIL > PROTECTED] In > fact, for English speakers, there's only [EMAIL PROTECTED] Sure, the UK > hasn't > adopted the Euro, but is it inconceivable that English speakers of non-Euro > countries might need to use the Euro symbol? Sure, we havent adopted the euro *yet* (just you wait...), but i'd really like to use an en_GB with euro support. So that I can get my £ sign (unavailable in C). Is this possible, i suppose i could use en_IE as the Irish have switched. -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org pgpyTYPhu6Tvy.pgp Description: PGP signature
Re: Bug#127461: ITP: SkunkWeb - An extensible and easy to use web application server
On Wed, 2002-01-02 at 15:50, Dave Swegen wrote: > package: wnpp > severity: wishlist > > > License: GPL v2 > > URL: http://skunkweb.sourceforge.net > > Description: > > SkunkWeb is a web application server written in python. It enables easy > use of components and templates using a combination of python, HTML, and > its own markup language STML. Components can output HTML or python > objects. > > It provides an easy and powerful component caching mechanism, as well as > providing for remote component inclusions. It can be run using either > either its own http server, or can be called from apache using an apache > extension module. > I spent ages talking to the developers to try and get them to make their build system at all FHS compliant, so that i could then package it. I deliberately did not ITP it due to massive packaging headaches prior to the changes. I hope you succeed in creating a great package from it. It is a really nice app, contact me if you need help testing the package. I had hoped on using it for some development work over at Debian Planet. Have fun... -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org pgp9QTPUUAxLf.pgp Description: PGP signature
find eating all memory
Hi on a simple 'find /var -name sendmail* -print' command, the find-process eats all my memory (128 Meg RAM) when there is no memory left, the process gets killed. I work with debian woody with recent update, reiserfs, 128 meg RAM & 256 meg SWAP on my P3 733 system. Here is what I get using 'top': PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM CTIME COMMAND 24610 root 14 0 98624 82M 400 R21.2 76.8 0:17 find greetz michael --- Michael De Nil -- [EMAIL PROTECTED] Linux LiSa 2.4.14 #6 SMP Sun Nov 25 16:59:04 CET 2001 i686 20:25:01 up 1 day, 6:19, 7 users, load average: 4.31, 3.61, 3.04 ---
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 08:32, Kevin Corry wrote: > On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote: > > Currently, the default installation names the library libevms.0.2.4.so > > and libevms.so is a symlink to that. However, the soname is libevms.so: > > > > objdump -x /usr/lib/libevms.0.2.4.so | grep SONAME > > objdump: /usr/lib/libevms.0.2.4.so: no symbols > > SONAME libevms.so > > > > And this is the name which is embedded in executables which are linked > > against the library: > > > > ldd =evms > > libdl.so.2 => /lib/libdl.so.2 (0x4001f000) > > libdlist.so => /usr/lib/libdlist.so (0x40023000) > > libevms.so => /usr/lib/libevms.so (0x40027000) > > libc.so.6 => /lib/libc.so.6 (0x4005) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) > > > > I believe what you want is the -soname linker option, but I normally use > > libtool for this kind of thing. Since you don't have to worry about OS > > portability, you can probably get away with calling ld directly, but > > could easily put together a libtool setup for it (and automake as well) > > if you're interested. > > > > I would recommend libevms-0.2.4.so, as you said above, over the current > > libevms.0.2.4.so, since many other programs use that convention. > > I have tried changing the soname to the version-specific name, and > everything seems to work. The only problem I see now is that the user must > run "ldconfig" after installing, because the user-interfaces are linked > against "evms", and not against the specific version of evms. But this > really shouldn't be a problem. It also means we probably don't need to > explicitly create the sym-link on "make install", since "ldconfig" will do > that. Could the "ldconfig" call be added to the top-level Makefile > "install" target? > > I have also switched the library file name to libevms-x.y.z.so from > libevms.x.y.z.so. > > If you are interested in creating an automake/libtool setup, give it a try > and I will look it over and see if we can include it in the future. What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the filename for the library (where x is the version major number, y is minor, and z is patchlevel)? This seems to be common on many of the libraries on my system. Basically, we don't want to force the user-interfaces to to be recompiled on every minor change to the engine core that doesn't change any of the external APIs. We only intend to change these APIs across a major version change. At most, new APIs may be added, but existing ones (and their defined functionality) will remain the same. Having the soname include only the major number means the existing binary user-interfaces could be used if a new minor or patch-level version of the engine library appears. Any comments? -Kevin
package upgrade statistics
145 packages upgraded, 12 newly installed, 1 to remove and 4 not upgraded. Need to get 91.4MB of archives. After unpacking 4027kB will be used. - from an apt-get dist-upgrade in Debian testing. I find these things impressive. I have, many times, heard people who were elated to discover the beauty of apt. I think if we start collecting more statistics to share, it could help more people understand why they should try Debian. Things like, since the beginning of time: How many package upgrades have I done ? How much total file size have I downloaded for upgrades ? How much time has all this downloading taken ? How much time has all the package configuration taken ? How much time has all the package installation taken ? How many complete (dist-)upgrades have I done ? How many (and which) Debian distributions have I gone through ? I think the right place to collect this might be in apt. I have a few beginning thoughts on specifics, but this just occurred to me about 18 minutes ago. I am willing to invest time in this. I have *never* reinstalled Debian (except when I had unrelated hardware failure). I think these could result in some pretty impressive statistics. -- "Every normal man must be tempted at times to spit upon his hands, hoist the black flag, and begin slitting throats." - Henry Louis Mencken (1880-1956) http://www.ChaosReigns.com
Re: How to put files at a location determined at install-time.
On Mon, Dec 31, 2001 at 07:09:41PM +0100, Marc L. de Bruin wrote: > On my system, I have hde1 (mounted as /), and md0 (hde2+hdg1, mounted as > /raid1). The home-dirs are on /raid1/home and I have a symlink /home -> > /raid1/home (this probably is a bad thing, I know). No, this isn't necessarily bad. However, why don't you specify the location of your home directories for specific accounts in your /etc/passwd, and specify your default home directory in the user management utilities? If you use /raid1/home as your home directory, you won't need to rely upon symbolic links and your applications will have one less system call to make for each home directory file access. Alternatively, look into Linux LVM (http://www.sistina.com/lvm). It's current release is quite up to date in the 2.4.16+ kernels, and I believe there's a current package in Debian for lvm tools. You can logically manage your raid1 partition into multiple, growable/shrinkable logical paritions/filesystems. Also, you could use the mount --bind option to use 2.4.x VFS. bash# mount --bind /raid1/home /home > So, the root-user might want the files to be physically installed on > /raid1, e.g. /raid1/mydata, so that a user "blah" (/raid1/home/blah) can > make a hardlink from /raid1/home/blah/afile to /raid1/mydata/afile. This sounds like a broken software package if it depends upon hardlinks. Hardlinks should be used with caution and only under specific circumstances. A good example is linking a file under multiple directories on the same filesystem when the directories are used as a form of data organization. (For example, the MH Rand email format.) Additionally, user home directories should not be touched by a Debian installation package. When the user uses this application, why does it not search a predefined path for files? Is there no $APPSHARE variable or configuration option for a user-based RC file (~/.)? Is there no default RC file for the application in /etc//? Could you provide the user with this functionality? Could upstream? -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Get my public key, ICQ#, etc. Send email w/the Subject: "get help"
Re: 2.4.17 kernel compilation
Douglas Bates wrote: > On a Debian 3.0 (testing) system updated to binutils 2.11.92.0.12.3-4, > I get a failure when trying to compile a 2.4.17 kernel. The last part > of the transcript is enclosed. > > ld -m elf_i386 -T /usr/src/linux-2.4.17/arch/i386/vmlinux.lds -e stext > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > init/version.o \ > --start-group \ > arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o > fs/fs.o ipc/ipc.o \ > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o > drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o > drivers/pci/driver.o drivers/video/video.o drivers/i2c/i2c.o \ > net/network.o \ > /usr/src/linux-2.4.17/arch/i386/lib/lib.a > /usr/src/linux-2.4.17/lib/lib.a /usr/src/linux-2.4.17/arch/i386/lib/lib.a \ > --end-group \ > -o vmlinux > drivers/sound/sounddrivers.o(.data+0x1d4): undefined reference to `local > symbols in discarded section .text.exit' > > My .config file has > CONFIG_SOUND=y > CONFIG_SOUND_TRIDENT=y > and all other CONFIG_SOUND_* unset. > > I can compile successfully if I unset all CONFIG_SOUND*. > > Suggestions? Downgrade to binutils 2.11.92.0.10-4. Newer versions may run into exactly this problem when compiling recent 2.4 kernels, depending on your kernel configuration. You can find binutils 2.11.92.0.10-4 in my archive of not-quite-current Debian unstable packages for i386 at http://crdic.ath.cx/debian . Access it with a web browser, not with dpkg; it's not a formal package repository, just a directory full of .debs. Craig
2.4.17 kernel compilation
On a Debian 3.0 (testing) system updated to binutils 2.11.92.0.12.3-4, I get a failure when trying to compile a 2.4.17 kernel. The last part of the transcript is enclosed. ld -m elf_i386 -T /usr/src/linux-2.4.17/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/i2c/i2c.o \ net/network.o \ /usr/src/linux-2.4.17/arch/i386/lib/lib.a /usr/src/linux-2.4.17/lib/lib.a /usr/src/linux-2.4.17/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/sound/sounddrivers.o(.data+0x1d4): undefined reference to `local symbols in discarded section .text.exit' My .config file has CONFIG_SOUND=y CONFIG_SOUND_TRIDENT=y and all other CONFIG_SOUND_* unset. I can compile successfully if I unset all CONFIG_SOUND*. Suggestions? -- Douglas Bates[EMAIL PROTECTED] Statistics Department608/262-2598 University of Wisconsin - Madisonhttp://www.stat.wisc.edu/~bates/
Re: Bug#127252: -unstable compiled against the wrong libpng
> Problem is we still have lots of users who will be wondering where > their graphics have gone and will be filing bug reports against all sorts > of packages, as well as creating all sorts of bogus links to the > wrong shared libraies to work around the problem. (Have a look in > debian-kde) How about adding a slang popup notice in libpng3 package stating that "the problem is known and being worked on, please don't file new bug reports" and uploading it as a "new upgrade"? - Jarno -- Something's rotten in the state of Denmark. -- Shakespeare
Re: EURO and CENT signs in the console keymaps
Marco d'Itri wrote: > On Jan 02, Paul Dwerryhouse <[EMAIL PROTECTED]> wrote: > > >Maybe I'm missing something here, but it's actually quite annoying to > Yes, you are. > > echo 'en_AU.ISO8859-15 ISO-8859-15' >> /etc/locale.gen > locale-gen Possibly dumb question: does it matter that the above is not listed in /usr/share/doc/locales/SUPPORTED.gz? Will 'en_US.ISO8859-15 ISO-8859-15' also work? Craig
Bug#127461: ITP: SkunkWeb - An extensible and easy to use web application server
package: wnpp severity: wishlist License: GPL v2 URL: http://skunkweb.sourceforge.net Description: SkunkWeb is a web application server written in python. It enables easy use of components and templates using a combination of python, HTML, and its own markup language STML. Components can output HTML or python objects. It provides an easy and powerful component caching mechanism, as well as providing for remote component inclusions. It can be run using either either its own http server, or can be called from apache using an apache extension module.
Re: 2 package(s) to rebuild on i386/stable
On Tue, Jan 01, 2002 at 03:13:18PM -0800, Thomas Bushnell, BSG wrote: > [EMAIL PROTECTED] (Martin Schulze) writes: > > These packages have to be rebuilt for stable on i386 in order to let > > the packages go into 2.2r5. > > ... > > > > This mail was generated automatically. > > Why is the mail not simply sent to the maintainers? I guess the assumption is that, if the package wasn't built for i386 in the first place, the maintainer doesn't have an i386 system. I don't know if that's true in this case. -- Colin Watson [EMAIL PROTECTED]
Re: Last preparations for Debian GNU/Linux 2.2r5
On Wed, Jan 02, 2002 at 02:47:18AM +0100, Josip Rodin wrote: > On Wed, Jan 02, 2002 at 12:04:01AM +0100, Martin Schulze wrote: > > groff stable1.15.2-2alpha, arm, i386, m68k, powerpc, sparc > > groff updates 1.15.2-3i386 > > > > Changelog says: > > > > * Use lpr as the print spooler, even if it happens not to be > > installed on the build system. Version 1.15.2-2 broke 'groff > > -l', which worked with previous versions of groff in stable > > (thanks, Mike Fontenot). > > > > Since I can't even find a single bug report that says 'groff > > -l' is broken in stable > > Well there you have it up there, the maintainer thanks an unknown person. > This is quite likely someone who noticed it's broken and reported it. That's correct, it was a report on -user from somebody who had just upgraded from 2.2r3 to 2.2r4. -- Colin Watson [EMAIL PROTECTED]
Re: VIM features
On Wed, 2 Jan 2002, Wichert Akkerman wrote: > Previously Junichi Uekawa wrote: > > Is it not possible to create a "vi" wrapper script which > > contains something like the following? > > That doesn't make any difference since that is implied when you invoke > vim as vi. Bah. But you know how does he mean. :) from that script you can check if it is invoked as vim/vi and maybe you can use the specific conf file. or whatever. -- VWOL Tamas SZERB <[EMAIL PROTECTED]> GPG public key: http://people.debian.org/~toma/gpgkey-toma.asc
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote: > > Because new plugins are still being written for the engine, we set up the > > Makefile to remove 'configure' on a 'make distclean'. This forces you to > > run 'autoconf' to regenerate 'configure' in the event new plugin or > > user-interface subdirectories were added to the engine. I suppose in the > > future, before releasing a package I should modify the Makefile to not > > delete 'configure' on 'make distclean', since the end-user will have no > > need for this functionality. > > Is the idea to get the latest aclocal.m4, which has the latest list of > plugin subdirectories? If so, another method would be to have a Makefile > rule for building configure which depends on aclocal.m4, something like: > > configure: configure.in aclocal.m4 > autoconf > > (this is what automake does by default) I just noticed an interesting quirk with this method. If I do a "make distclean" (after taking out the "rm configure", so it is no longer deleted), and then try to run "make configure", it fails because Makefile tries to include make.rules, which is deleted by "make distclean". So you would have to remember to run "make configure" before running "make distclean" in order to pick up the aclocal.m4 changes. Or just revert to running "autoconf". Or is there another way? I'm not very familiar with automake, so I could be totally out-of-whack here. -Kevin
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
Previously Kevin Corry wrote: > Could the "ldconfig" call be added to the top-level Makefile "install" > target? No, since you might not be installing on a real system but a temporary location to build a package or for some other reason. Also if you are not running as root but with fakeroot ldconfig will fail. > I've applied your Makefiles patch, and everything seems to work fine. Only > one other question: In the top-level make.rules, we have some #defines that > are based on configuration options (notably PluginDirectory). This is set so > the core engine will know which directory to look in to find the plugin > libraries. Does the DESTDIR construct affect this define? No, it should not. DESTDIR is only used when installing files on the filesystem to put them in a different location. This can be a temporary location when building a package, or a chroot environment, but not something you will see when running the application. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote: > Currently, the default installation names the library libevms.0.2.4.so and > libevms.so is a symlink to that. However, the soname is libevms.so: > > objdump -x /usr/lib/libevms.0.2.4.so | grep SONAME > objdump: /usr/lib/libevms.0.2.4.so: no symbols > SONAME libevms.so > > And this is the name which is embedded in executables which are linked > against the library: > > ldd =evms > libdl.so.2 => /lib/libdl.so.2 (0x4001f000) > libdlist.so => /usr/lib/libdlist.so (0x40023000) > libevms.so => /usr/lib/libevms.so (0x40027000) > libc.so.6 => /lib/libc.so.6 (0x4005) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) > > I believe what you want is the -soname linker option, but I normally use > libtool for this kind of thing. Since you don't have to worry about OS > portability, you can probably get away with calling ld directly, but could > easily put together a libtool setup for it (and automake as well) if you're > interested. > > I would recommend libevms-0.2.4.so, as you said above, over the current > libevms.0.2.4.so, since many other programs use that convention. I have tried changing the soname to the version-specific name, and everything seems to work. The only problem I see now is that the user must run "ldconfig" after installing, because the user-interfaces are linked against "evms", and not against the specific version of evms. But this really shouldn't be a problem. It also means we probably don't need to explicitly create the sym-link on "make install", since "ldconfig" will do that. Could the "ldconfig" call be added to the top-level Makefile "install" target? I have also switched the library file name to libevms-x.y.z.so from libevms.x.y.z.so. If you are interested in creating an automake/libtool setup, give it a try and I will look it over and see if we can include it in the future. > > Currently the dlist package doesn't have any version number, but I'm sure > > we can come up with one if it makes things easier. I will try to do that > > tomorrow. > > Since libdlist is so small (and not subject to a lot of revision), you > might just want to statically link it and avoid the issue altogether. I suppose that would be possible. But wouldn't that just bloat the size of the engine core and plugin libraries? > By the way, dlist.h defines a type dlist_t, and as I understand it, types > ending with the "_t" suffix are reserved by POSIX. Is that going to be a huge problem? Changing that is going to entail a lot of searching-and-replacing in the code. And evms has other data structures with similar naming-schemes (see engine/include/enginestructs.h). Are those a problem as well? > > I believe we have someone working on some man pages. Currently I think > > they will just be for evms (command line) and evmsgui. I will check to > > see if we can write some man pages for the LVM-emulation utilities. If > > you'd like to take an initial shot at those, feel free. > > I can certainly do that; for the most part, it should just be a matter of > copying the corresponding LVM man pages and noting differences in > behaviour, right? Pretty much. Those utilities are meant to model the ones from LVM. All of the options should be the same, except some of the options are ignored in EVMS, either because they aren't implemented yet or aren't pertinent. If you glance through the code in engine/UserInterfaces/LvmUtils, each source file has a function called parse_options() that should give you an idea of which options are ignored in EVMS. Hopefully the only noticable difference to the users are just the verbose messages, which are obviously going to be different than in LVM. Also, in the EVMS tools, the "-v" and "-d" options both control the level of logging in the engine. > > > - Makefile stuff > > > > > > I modified the makefiles to support DESTDIR, and to remove the > > > autoconf clutter in 'clean' instead of 'distclean'. I can't run > > > 'distclean' from the package build scripts because it removes > > > 'configure'; I'm not sure why this is, since configure is part of the > > > distribution. My diff is attached. > > > > I guess I've never used the DESTDIR construct before. I assume that is > > just an externally set environment variable? I will patch in these > > changes to the Makefiles. > > I believe it started as a GNU standard ( (standards)Command Variables ), > but it has become common in other circles as well. > > >Optionally, you may prepend the value of `DESTDIR' to the target > filename. Doing this allows the installer to create a snapshot of the > installation to be copied onto the real target filesystem later. Do not > set the value of `DESTDIR' in your Makefile, and do not include it in > any installed files. With support for `DESTDIR', the above examples > become: > > $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo > $(INSTALL_DATA)
Re: HP jis support in ghostscript
>> "CS" == Carlos Sousa <[EMAIL PROTECTED]> writes: > I'd just like to know if there are any plans to compile the new HP jis > support into the gs package any time soon. I believe the debian SOHO > user base using HP printers would benefit from the enhanced printing > capabilities this driver provides. gs (6.51-6) unstable; urgency=low * ijs/*: Include the ijs driver from the hpijs source. * debian/devices: Add ijs to the device list. * src/contrib.mak: Include ijs/contrib.mak-6.51.add -- Torsten Landschoff <[EMAIL PROTECTED]> Mon, 31 Dec 2001 15:00:45 +0100 Christian
Re: EURO and CENT signs in the console keymaps
Miquel van Smoorenburg <[EMAIL PROTECTED]> writes: > Ah, so *that's* why I'm seeing a lot of open squares on webpages > where I should see a Euro symbol. Instead of using iso8859-15, the > site is using M$ bastard-8859-1. Well perhaps the Linux distro's > should follow that example, put a Euro symbol at 0x80 in the 8859-1 > charset. It would not be completely standards-compliant but it would > be easy and useful. Or would that make us just as bad as Microsoft > where standards are concerned ? If you call it ISO 8859-1: Yes. If you call it windows-1252 or cp1252, have a blast, but it will still be a lot of work. Personally, I think we should direct our energy towards Unicode support (in UTF8 form) instead. It's about time we stopped patching the character sets and started using something which scales worldwide. Kjetil T.
Re: Bug#126750: klogd should optionally be started from init(8)
On Sat, 29 Dec 2001, Henrique de Moraes Holschuh wrote: > > This is bogus, anything can die in an OOM situation. Are you going to > > put all daemons into inittab? > True, true. However, sysklogd and klogd are logging daemons. They deserve > some special treatment IMHO. > Actually, I am pondering doing such a thing to sshd on my remote systems, > too. I think it would be far better to have the logging daemons and ssh checked by the watchdog daemon. IMO it is not a good idea to restart the daemons when we are OOM anyway, since this might do real damage, a clean reboot would be better. > > You should be trying to avoid OOM situations in the first place. > That is not always possible, and sometimes a kernel VM screwup will cause > it, no? Hrm, I have 768 megs of swap, and watchdog is set up to reboot before OOM happens, which never did, so it is possible. In the case of a VM screwup, I'd like my box to reboot and send me a mail rather than let mysql die in the middle of a transaction and serve "database connection refused" pages to everyone until apache also dies. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
HP jis support in ghostscript
I'd just like to know if there are any plans to compile the new HP jis support into the gs package any time soon. I believe the debian SOHO user base using HP printers would benefit from the enhanced printing capabilities this driver provides. Please forgive me if this isn't the right list to post this question to, but debian-user just didn't seem appropriate... A good (and productive :) 2002 to you all. -- Carlos Sousa
Re: EURO and CENT signs in the console keymaps
On Wed, Jan 02, 2002 at 02:04:12PM +1100, Paul Dwerryhouse wrote: > However, I tend to spend most of the year living in the Netherlands, > which is one of the countries adopting the Euro, and there's no Euro > symbol in the fonts used by en_AU. I don't speak Dutch, so there's not much > point setting LANG to nl, nl_NL or whatever. And there's no [EMAIL > PROTECTED] In > fact, for English speakers, there's only [EMAIL PROTECTED] Sure, the UK > hasn't > adopted the Euro, but is it inconceivable that English speakers of non-Euro > countries might need to use the Euro symbol? I have the same Problem here, as a german speaking geek I refuse to use de_DE as my locale. On the Other hand my usual en_US has no Euro Alias. Of course I can make one, thats what I did. On the other hand, I prefer to tag everything with ASCII oder LATIN1 unless I actually use one of the extended chars. On my System I have only "lucidus" and "thryomanes" as ISO8859-15 Font I think I need to check my fontpath and xfs setting. [EMAIL PROTECTED]:~> xlsfonts -fs *ISO8859-15* -b&h-lucidux mono-medium-o-normal--0-0-0-0-m-0-iso8859-15 -b&h-lucidux mono-medium-o-normal--0-0-0-0-m-0-iso8859-15 -b&h-lucidux mono-medium-r-normal--0-0-0-0-m-0-iso8859-15 <- this for console -b&h-lucidux mono-medium-r-normal--0-0-0-0-m-0-iso8859-15 -b&h-lucidux sans-medium-o-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux sans-medium-o-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux sans-medium-r-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux sans-medium-r-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux serif-medium-o-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux serif-medium-o-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux serif-medium-r-normal--0-0-0-0-p-0-iso8859-15 -b&h-lucidux serif-medium-r-normal--0-0-0-0-p-0-iso8859-15 -hmiller-thryomanes-bold-i-normal--0-0-0-0-p-0-iso8859-15 -hmiller-thryomanes-bold-r-normal--0-0-0-0-p-0-iso8859-15 -hmiller-thryomanes-medium-i-normal--0-0-0-0-p-0-iso8859-15 -hmiller-thryomanes-medium-r-normal--0-0-0-0-p-0-iso8859-15 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: how to move a config file during package upgrade
Previously Thomas Lange wrote: > my package fai will have a new location for its configuration file > /etc/fai.conf. The next version will use /etc/fai/fai.conf. How can I > handle this in a preinst script during an upgrade ? Any examples would > be fine. Move it in the preinst. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
how to move a config file during package upgrade
Hi, my package fai will have a new location for its configuration file /etc/fai.conf. The next version will use /etc/fai/fai.conf. How can I handle this in a preinst script during an upgrade ? Any examples would be fine. -- Thomas -- Thomas Lange Institut fuer Informatikmailto:[EMAIL PROTECTED] Universitaet zu Koeln Pohligstr. 1Telefon: +49 221 470 5303 50969 KoelnFax: +49 221 470 5317 1024D/AB9B66FD AEA6 A8C1 BD8E 67C4 8EF6 8BCA DC13 E54E AB9B 66FD --
Bug#127447: ITP: xclasses -- C++ layout library for the X Window System
Package: wnpp Version: N/A; reported 2002-01-02 Severity: wishlist * Package name: xclasses Upstream Author : Juergen Schmitz <[EMAIL PROTECTED]> * URL : http://www.JS-Home.org/Xclasses/index.php * License : LGPL Description : C++ layout library for the X Window System Xclasses is a C++ layout library for the X Window System. All objects (called gadgets) are font sensitiv, i.e. their size changes with the size of the used screen font and the size of the window. All objects (gadgets) have the same base class (class gadget) so there are all used the same. Gadgets are put together in groups (class group also bases on gadget) which manage the correct size of all gadgets (and/or groups!) inside. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux donald.duckburg.org 2.4.17 #1 ven dic 28 19:35:11 CET 2001 i686 Locale: LANG=it_IT, LC_CTYPE=it_IT -- Davide Puricelli, [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org Undergraduate Student of Computer Science at University of Bologna PGP key: finger [EMAIL PROTECTED]
Bug#127448: ITP: xcmail -- MIME and multi POP3 capable mailtool
Package: wnpp Version: N/A; reported 2002-01-02 Severity: wishlist * Package name: xcmail Upstream Author : Juergen Schmitz <[EMAIL PROTECTED]> * URL : http://www.JS-Home.org/XCmail/index.php * License : GPL Description : MIME and multi POP3 capable mailtool XCmail is a MIME and multi POP3 capable mailtool for X11 using the Xclasses layout library. XCmail was designed completely object orientated and by this may be improved easily. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux donald.duckburg.org 2.4.17 #1 ven dic 28 19:35:11 CET 2001 i686 Locale: LANG=it_IT, LC_CTYPE=it_IT -- Davide Puricelli, [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org Undergraduate Student of Computer Science at University of Bologna PGP key: finger [EMAIL PROTECTED]
안녕 하세요 다사자입니다.(광고)
Title: 안녕하세요 다사자닷넷 입니다 안녕하세요. 저희 다사자.넷은 오픈 기념행사로 2002. 1. 1 - 2002.1.31일 까지 전품목 정상 가격의 10% 할인된 가격으로 판매하고 있으며 또한 모든 운송비를 저희가 책임 지 고 여러분의 집까지 배달해 드립니다. 또한 저희 회사는 미국 내 현지 매장에서 구입한 물품을 미국 내 물류센터에서 여러분의 집까지 직접 배송해 드립니다. 한국 내 믿을 만한 매장이 없으시다고? 이제는 걱정하지 마십시오. 언제 어디서든 여려 분이 원하는 물건을 직접 찾아서 현지에서 직접 배달해 드릴 것 입니다. 저희 다사자 인터넷쇼핑 몰은 믿음과 신용으로 생겨난 회사입니다. t Prada(1M0608)\299,000 Prada(B2811)\452,000 Aigner(73925)\360,000 Aigner(Flap형)\364,000 서비스 이용 시 궁금한 점이나 불편사항이 있으시면 고객지원센터 (http://www.dasaja.net/bbs.htm)에 접속하시거나 다사자닷넷 고객센터 033-748-0078 으로 연락해주십시오.
Re: EURO and CENT signs in the console keymaps
On Jan 02, Paul Dwerryhouse <[EMAIL PROTECTED]> wrote: >Maybe I'm missing something here, but it's actually quite annoying to Yes, you are. echo 'en_AU.ISO8859-15 ISO-8859-15' >> /etc/locale.gen locale-gen >have to change the LANG environment variable in order to access the Euro >symbol. You may use $LC_CTYPE which just changes the charset. -- ciao, Marco
Re: 2 package(s) to rebuild on i386/stable
On Wed, Jan 02, 2002 at 12:40:46PM +0100, Wichert Akkerman wrote: > Previously Thomas Bushnell, BSG wrote: > > Um, they don't need one. All Debian maintainers have access to a > > stable system, since Debian maintains some for just this sort of > > reason. > Debian does not unfortunately. Even if it did they may well end up having to bug debian-admin to get build dependancies installed. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpDPwHItEiZD.pgp Description: PGP signature
Re: Bug#127252: -unstable compiled against the wrong libpng
On Wed, Jan 02, 2002 at 01:06:21PM +0100, Noel Koethe wrote: > On Mit, 02 Jan 2002, Mark Purcell wrote: > > > > That's the problem; there is just no real solution besides a big > > > recompile. > > > > My question still remains. If we require a big recompile, when/ how are we > > going to bother to advise the maintainers of these packages? It has been > > stated that we are talking about 300+ packages :-( > > Maybe we could use: debian-devel-announce: Announcements for developers I guess we could do something like that. Problem is we still have lots of users who will be wondering where their graphics have gone and will be filing bug reports against all sorts of packages, as well as creating all sorts of bogus links to the wrong shared libraies to work around the problem. (Have a look in debian-kde) Then of course not every developer actually reads/ acts on devel-announce, yes I know hard to believe isn't it. I still think the only solution is to do the same as per python and automatically file bug reports/ conflicts with all pacakges which depend on libpng2. But I would be happy to be told otherwise. Mark
Re: Question about cdrecord and -audio
On Mon, Dec 31, 2001 at 04:12:58PM -0600, Adam Majer wrote: > Hi all, > > I'm hopping that someone has some experience with audio CD recording and > can help me a bit. I can record data CDs without any problems but if I > try the audio option I get the following output > > > mira:/tmp# cdrecord -dev=0,0 -dummy -audio -pad t.iso Mmmm, are you really wanting to burn an audio CD from an ISO9660 image ??? I doubt it'll ever work. -- Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano) Andago \_|_/ Av. Santa Engracia, 54 \/ \/ E-28010 Madrid - tfno:+34(91)2041100 a n d a g o |--http://www.andago.com /\___/\ "Innovando en Internet" / | \ [EMAIL PROTECTED]
Re: VIM features
Previously Junichi Uekawa wrote: > Is it not possible to create a "vi" wrapper script which > contains something like the following? That doesn't make any difference since that is implied when you invoke vim as vi. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Bug#127252: -unstable compiled against the wrong libpng
On Mit, 02 Jan 2002, Mark Purcell wrote: > > That's the problem; there is just no real solution besides a big > > recompile. > > My question still remains. If we require a big recompile, when/ how are we > going to bother to advise the maintainers of these packages? It has been > stated that we are talking about 300+ packages :-( Maybe we could use: debian-devel-announce: Announcements for developers -- Noèl Köthe
Re: VIM features
On Wed, 2 Jan 2002 12:40:11 +0100 Wichert Akkerman <[EMAIL PROTECTED]> wrote: > Right now they're only enabled for a few specific filetypes > (word-wrapping for emails for example). I doubt it's possible > to figure out how vim is invoked in the scripts and change > behaviour on that. Is it not possible to create a "vi" wrapper script which contains something like the following? #!/bin/bash vim -C "$@" regards, junichi
Re: 2 package(s) to rebuild on i386/stable
Previously Thomas Bushnell, BSG wrote: > Um, they don't need one. All Debian maintainers have access to a > stable system, since Debian maintains some for just this sort of > reason. Debian does not unfortunately. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: VIM features
Previously Miquel van Smoorenburg wrote: > Because it's *EVIL* (hello Wichert ;) ) Ook gelukkig nieuwjaar Miquel :) > Wichert, would it be possible to only enable the line-wrapping > auto-inserting syntax-highlighting coffee-making mode when vim is > invoked as "vim" and leave it out when invoked as "vi" ? Right now they're only enabled for a few specific filetypes (word-wrapping for emails for example). I doubt it's possible to figure out how vim is invoked in the scripts and change behaviour on that. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Bug#127252: -unstable compiled against the wrong libpng
On Wed, 2 Jan 2002 21:36:24 +1100 Mark Purcell <[EMAIL PROTECTED]> wrote: > My question still remains. If we require a big recompile, when/ how are we > going to bother to advise the maintainers of these packages? It has been > stated that we are talking about 300+ packages :-( Mass NMU, setting Build-Depends to libpng-dev version that is for libpng3 sounds like a way to go. Note that the recent python translation took more than a month to complete, I believe (well, I didn't). It might be easier to set libpng3 to conflict with libpng2, so that until libpng2 is removed from the system libpng3 does not enter, which would make the problem more obvious. Then again, do we really want to do this now? regards, junichi
Re: EURO and CENT signs in the console keymaps
#include Joey Hess wrote on Tue Jan 01, 2002 um 11:33:48PM: > Yeah Paul has a point. I'm in America; I've never even been to Europe, > but since I do pay for things in (virtual) euro (gandi.net rules), it'd > be odd to have to change my LANG to get the symbol. The Debian euro Not LANG is the main problem, but LC_CTYPE. Applications do not accept the "euro" keycode at all or not as the expected char. And many are still to dumb to look for alternative charset if LC_CTYPE is not latin1, so you have to switch manually. > work if LANG is not set right? I haven't yet downloaded the (huge) > transcoded fonts to try it myself. I got the contents of the xfonts-*-transcoded packages, dropped all non-latin15 fonts and put the resulting tarball on people.debian.org/~blade/fonts/. > > I'll continue using 'E' for Euro, '#' for pounds, 'Y' for Yen, and 'c' for > > cents You can allways use the ASCII replacements, as European had to do for many years with "full ASCII compliant" hardware and software. Gruss/Regards, Eduard. -- Wer Stabilität aufgibt, um Benutzerfreundlichkeit zu bekommen, verdient keins der beiden und bekommt meist auch keins. -- frei nach B. Franklin
Re: Bug#127252: -unstable compiled against the wrong libpng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > > That's the problem; there is just no real solution besides a big > recompile. My question still remains. If we require a big recompile, when/ how are we going to bother to advise the maintainers of these packages? It has been stated that we are talking about 300+ packages :-( Or are we going to do as we are currently and wait until users report vague problems (these don't get straight forward bug reports - aka debian-kde confusion over the real problem). Personally I would like to see an automated bug report stating what the issues are and how the maintainer can fix it. That's what I got during the last update to python and it made my life as a maintainer straight forward. Rather than having to guess some non-backwards compatable change in an dependant package. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8MuKtoCzanz0IthIRAuDHAJ9VZ1Fbn+X45XPjttkqLNNxJuMJeQCfdpzN N1ylOMPx3JAyrNZPimA/BVg= =M723 -END PGP SIGNATURE-
Re: EURO and CENT signs in the console keymaps
> Huch, "apt-get install xfonts-base-transcoded" and you have fixed fonts > with latin15 charset. And visit: FWIW, it is latin9, not 15. (I know, I could have left this unsaid.) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: EURO and CENT signs in the console keymaps
> There is a cent symbol: ¢ (compose c |) Or Shift-AltGr-e (*) for us poor little individuals who do not have a compose key on our keyboard (and have not bothered to map it anywhere); I think this Cent-symbol belongs to ISO-8859-1, at least so this is not "going crazy" about i18n as someone suggested. (*) At least on my X keymap, which is Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "fi" -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: 2 package(s) to rebuild on i386/stable
Martin Schulze <[EMAIL PROTECTED]> writes: > Thomas Bushnell, BSG wrote: > > [EMAIL PROTECTED] (Martin Schulze) writes: > > > > > These packages have to be rebuilt for stable on i386 in order to let > > > the packages go into 2.2r5. > > > ... > > > > > > This mail was generated automatically. > > > > Why is the mail not simply sent to the maintainers? > > Because they don't have to have a stable system anymore, hence would be > useless. Um, they don't need one. All Debian maintainers have access to a stable system, since Debian maintains some for just this sort of reason.
Re: VIM features
In article <[EMAIL PROTECTED]>, Eduard Bloch <[EMAIL PROTECTED]> wrote: >I would like to see more user feedback on Debian's settings of the >VIM editor. Currently, two important features are disabled in the >default configurations: Syntax highlighting and special intending >schemes. The question is: why? Because it's *EVIL* (hello Wichert ;) ) Wichert, would it be possible to only enable the line-wrapping auto-inserting syntax-highlighting coffee-making mode when vim is invoked as "vim" and leave it out when invoked as "vi" ? Mike.
Re: EURO and CENT signs in the console keymaps
In article <[EMAIL PROTECTED]>, Scott Dier <[EMAIL PROTECTED]> wrote: >The best one is where microsoft put their symbol in >'iso-8859-1'-cp1252-winlatin1, which is in 80, instead of a4 where >iso-8859-15 puts it. What does most codepages use? 80 or A4? Does >iso-8859-1 even have anything in 80? Is this going to lead to lots of >confusion? Ah, so *that's* why I'm seeing a lot of open squares on webpages where I should see a Euro symbol. Instead of using iso8859-15, the site is using M$ bastard-8859-1. Well perhaps the Linux distro's should follow that example, put a Euro symbol at 0x80 in the 8859-1 charset. It would not be completely standards-compliant but it would be easy and useful. Or would that make us just as bad as Microsoft where standards are concerned ? Mike.
Re: 2 package(s) to rebuild on i386/stable
Thomas Bushnell, BSG wrote: > [EMAIL PROTECTED] (Martin Schulze) writes: > > > These packages have to be rebuilt for stable on i386 in order to let > > the packages go into 2.2r5. > > ... > > > > This mail was generated automatically. > > Why is the mail not simply sent to the maintainers? Because they don't have to have a stable system anymore, hence would be useless. Regards, Joey -- Computers are not intelligent. They only think they are. Please always Cc to me when replying to me on the lists.
Re: VIM features
On Tue, Jan 01, 2002 at 02:56:58PM -0800, Caleb Shay wrote: > I second this. For example, at the bottom of /etc/vim/vimrc there are > several lines commented out "as they cause vim to behave a lot different > from regular vi". However, as was pointed out below, vim is NOT the > default vi when you install, so why not enable some more of it's better > features. After all, to make vim the alternative to vi you have to > manually use update-alternatives. If you've gone through the trouble to > do that you are obviously a "vim" user, not a "vi" user, so you WANT > those features. Actually, vim does install as an alternative for vi. At less priority than nvi obviously since nvi is more pure. It used to install itself as like priority 100 for both that and /usr/bin/editor. Neither of those were terribly good things, and I am glad to see that they've changed since potato. -- Joseph Carter <[EMAIL PROTECTED]> Now I'll take over the world Change the Social Contract? BWAHAHAHAHAHAHAHAHAHAHAHA. -- Branden Robinson pgpbKVMhVVig0.pgp Description: PGP signature
