Re: Dependencies on -dev packages
On 03 Sep 2002 11:58:10 -0700 Stephen Zander <[EMAIL PROTECTED]> wrote: > > What is the thinking behind always requiring libfoo-dev to depend on > libbar-dev when libfoo depends on libbar? I understand the need when > /usr/include/foo.h contains > > #include So that libbar-dev can conflict with packages that libbar is incompatible with at run-time, so that other shared libraries that are incompatible do not get loaded in the same shared namespace. Google, libpkg-guide. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Improper NMU (Re: NMU for libquota-perl)
On Wed, Sep 04, 2002 at 01:35:31AM +0200, Josip Rodin wrote: > It still requires effort by the non-maintainer to get the sources, fiddle > with it a little bit, recompile, and upload. Two minutes, sure, but two > minutes that could have been spent fixing #155939. ;) Um, the fix to #155939 is known - just have libc6 Depends: libdb1-compat. Only way I can speed that up is to NMU glibc, which ain't happening. :) -- Colin Watson [EMAIL PROTECTED]
Bug#159554: ITP: gkrellmms2 -- GKrellM version 2 XMMS Plugin
Package: wnpp Version: N/A; reported 2002-09-04 Severity: wishlist * Package name: gkrellmms2 Version : 2.1 Upstream Author : Sjoerd Simons <[EMAIL PROTECTED]> * URL : http://gkrellm.luon.net/ * License : GPL-2 Description : GKrellM version 2 XMMS Plugin GKrellM plugin which allows you to control XMMS from within GKrellM version 2. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux glass 2.4.18 #4 Sun May 5 13:12:05 CEST 2002 i586 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Re: Deleting /var/cache/*
On Wed, Sep 04, 2002 at 01:02:33PM +1000, Martijn van Oosterhout wrote:
> I think the key word is "files". As you say it doesn't talk about about
> directories, for good reason since it's an awful lot of work. you'd have to
> replace:
I think that FHS would transmit the content that "stuff" in /var/cache
can be deleted by the system administrator, even if is written only
"files".
> Look for cache file
> If not, go the long way
>
> with:
>
> Look for cache file
> If not, check for parent directory
> If not there, try to create it
> If fails, check for parent directory
> etc...
>
> Ofcourse, it could just do system("mkdir -p /var/cache/whatever/dir/it/is")
> everytime it wants to open a file but that would be inefficient.
No, you can try to check if there is the file, and if this is not the
case do the "mkdir -p" command. In this case the inefficiency is only
after a manual deletion by the sysadm, IMO this is an acceptable
behaviour.
IMO we should fill bugs (perhaps 'whishlist' until we clarify the FHS
intended approach) and fix the affected apps.
Cheers.
--
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
[EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
pgp3mzcrqqJ1a.pgp
Description: PGP signature
Re: Re: foomatic unmaintained?
Samuli Suonpaa <[EMAIL PROTECTED]> schrieb am 03.09.02 21:45:32:
> Rainer Dorsch <[EMAIL PROTECTED]> writes:
> > Hello,
> >
> > some weeks ago I was installing an HP OfficeJet and on the hpoj
> > mailing list somebody was pointing out that I need the latest
> > version of foomatic to get good results.but it seems that the
> > Debian foomatic-{bin,db} packages in sid are outdated. I contacted
> > the maintainer, Manfred Wassmann, but so far no response.
>
> What exactly is the problem with foomatic you are having? I've used
> first Woody's and later Sarge's foomatic and hpoj with my OfficeJet
> G55 for a long time and they've always seemed to perform just fine.
>
> Suonpää...
The HP syupported hpijs driver brings much better quality for color printing
than pcl3,... The foomatic package in Debian (all version use the same!) does
not yet have and hpijs entry for OJ6xx.
Rainer
__
Jetzt testen für 1 Euro! Ihr All-in-one-Paket!
https://digitaledienste.web.de/Club/formular/?mc=021106
Re: Deleting /var/cache/*
On Tue, Sep 03, 2002 at 10:34:23PM -0400, Duncan Findlay wrote: > /etc/cron.daily/man-db: > fopen: No such file or directory > mandb: can't create index cache /var/cache/man/1075: No such file or > directory > mandb: can't chmod /var/cache/man/index.bt: No such file or directory > mandb: warning: can't update index cache /var/cache/man/index.bt: No > such file or directory [...] Yeah, that all looks like a bug in man-db to me. Feel free to file it. -- Colin Watson [EMAIL PROTECTED]
Re: amavis build error on m68k
[the first time I tried sending this, I sent it to [EMAIL PROTECTED] instead of debian-devel@lists.debian.org :-(. Lets try again...] On Fri, Aug 30, 2002 at 06:05:01PM +1000, Brian May wrote: > According to the build log at: > > http://buildd.debian.org/fetch.php?&pkg=amavis&ver=20020517-16&arc > h=m68k&stamp=1030683083&file=log&as=raw> > > libmime-perl is installed: > > Selecting previously deselected package libmime-perl. > Unpacking libmime-perl (from .../libmime-perl_5.411-1.1_all.deb) ... > > [...] > > but then later on: > > checking for perl modules... > module not found in path: 'MIME/Parser'. > configure: error: You are missing some perl modules. Please check the README > make: *** [configure-stamp] Error 1 > > Is this some sort of perl 5.8 issue? (note: please ignore the build log for Mon 02 Sep 2002 02:06, now that *IS* a perl 5.8 issue... Instead look at Fri 30 Aug 2002 00:51) -- Brian May <[EMAIL PROTECTED]>
Re: Dumb little utilities
> rename 's/\.c$/.x/' cumbersome?
Come on. s///? Backslash? $? Not one, but two single quotes?
One may as well type for i in *.c ; mv $i ${i/.c(#e)/.x} or
for i (*.c) { mv $i ${i%c}x }
I really would rather type ren *.c *.x. But then, I don't think in
perl.
Re: foomatic unmaintained?
Rainer Dorsch <[EMAIL PROTECTED]> writes: > The HP syupported hpijs driver brings much better quality for color > printing than pcl3,... The foomatic package in Debian (all version > use the same!) does not yet have and hpijs entry for OJ6xx. I guess I still cannot understand what you mean. $ grep 'OfficeJet 6' /usr/share/foomatic/db/source/driver/hpijs.xml printer/185033 printer/74208 printer/100704 Is this not sufficient? I admit, I don't remember how I set up foomatic here. I _think_ I did it with foomatic-configure and I just looked in /usr/share/foomatic/db/source to find the right printer and driver id's. I still can't see why it couldn't be done with OfficeJet 6XX. Suonpää...
Re: Kernel problem
On Tue, Sep 03, 2002 at 07:40:23PM +0200, Michael Meskes wrote:
>
> The "error" message is:
>
> BIOS data check successful
That message comes from LILO. It sounds as if you've got a
boot loader problem that is triggered by the Debian kernels.
See if you can get it to load by removing the initrd from lilo.
Of course it won't boot, but it will hopefully give you a direction
as to where to look.
--
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: Deleting /var/cache/*
Duncan Findlay <[EMAIL PROTECTED]> wrote:
>
> True, the FHS does not specifically say that directories have to be
> recreated, but I would consider it a bug if they aren't. Anyone agree?
I think it would be much better if you did
find /var/cache ! -type d -print0 | xargs -0r rm -f
The complications in recreating those directories simply isn't worth it.
--
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: Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL
On Tue, Sep 03, 2002 at 10:59:14AM -0600, [EMAIL PROTECTED] wrote: > Hello! > > On Mon, Sep 02, 2002 at 01:52:13PM +0200, Javier Fernández-Sanguino Peña > wrote: > > On Sun, Aug 25, 2002 at 02:56:46PM +1000, Martijn van Oosterhout wrote: > ... > > > What I'm saying is that to must have a mail-server install, even if it is > > > just ssmtp or something like that. > > > > Yes, however the mail server should not be running as a daemon nor > > listening for incoming port 25 connections. > ... > > I checked out ssmtp and it is not what we would eventually want. It > does not deliver _any_ mail locally. > > Indeed procmail cannot deliver local mail, and I though about writing > some script which acomplishes the simple task of distinguishing > between local and remote recipients and pipe the local ones a copy via > the default delivery method, while putting the remote ones into a kind > of outgoing queue. However has it done or is faster than I, go ahead. I do not really understand what the point of this is, but if it is a small, minimal MTA, you can use masqmail. It happens that I am both up/downstream of it, so I can modify it to, say, masqmail-tiny, which does nothing but deliver mail locally, or, if required, remote via SMTP. It should not be too much work, I think. Incoming connections can be disabled, or can be done with inetd. Small drawback for masqmail is however, that it depends on libglib. I already have configure options to link that statically, increasing the size by ~30K. A pro is that it does not depend on procmail, and can deliver to mbox, maildir and an mda. Patches for MH are welcome. > Javier states it clearly, it is not necessary to have a daemon running > for this. You still need a queue running daemon for the case that the mailbox is locked, or a mail cannot be delivered for any reason. But this can also be done with a cron job. I will start a project of this kind only if I am somewhat sure that it will be used. So, give me feedback ;-). Otherwise I'll hide under my rock again. Greetings, Oliver -- debian/rules http://zork.net/~nick/srom/ pgpr9yqpFLehr.pgp Description: PGP signature
Re: Improper NMU (Re: NMU for libquota-perl)
Hi The! You wrote: > > DELAYED is fine. Not submitting a bug is not fine. > > Can DELAYED be set up to email the maintainer with the changelog? > Would that help the "unexpected" NMU from ambushing the maintainer? In this case the changelog and patch were actually sent to the maintainer; they only were not submitted to the BTS. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
HE ENCONTRADO UN VIRUS EN UN CORREO DE almeria@masterd.es PARA USTED
V I R U S A L E R T Nuestro antivirus ha encontrado los siguientes virus(es) I-Worm.Klez.h I-Worm.Klez.h en un correo para usted de: [EMAIL PROTECTED] ¡La entrega del correo ha sido detenida! Por favor, contacte con su administrador de correo ([EMAIL PROTECTED]) para más detalles.
RFP: eskuel -- MySQL databases administration interface written in PHP.
Package: wnpp Version: N/A; reported 2002-09-04 Severity: wishlist * Package name: eskuel Version : 1.0.2 Upstream Author : Mathieu LESNIAK <[EMAIL PROTECTED]> * URL : http://www.phptools4u.com/scripts/eskuel/?lang=english * License : GPL v2 http://www.phptools4u.com/divers/cgu.php Description : MySQL databases administration interface written in PHP. eskuel is a MySQL databases administration interface written in PHP. It allow user to manage simply and fully one or more database without any advanced knowledge in SQL language. Like phpMyAdmin, eskuel can backup a table property, export and import the structure and/or the content of a database. You'll be able to add, delete one or more records, control and optimize the size of one table or database, rename or copy datas, in fact you'll can do everything phpMyAdmin does but better and efficiently. Better because we tried to create a more attractive interface (just take a look at the screenshots), more ergonomic (you can quickly do everything), more "cross-browser" (no more bugging frames or dhtml) and customizable (absolutely !). More efficient because we wanted each request to be the fastest of the world, a maximum of actions available and we wish that every advanced SQL user could use eskuel easily. But you'd better have to try eskuel now ! You'll see exactly what we mean. Some cool features : - Query bookmark system - Context help - Interface in 2 or 3 columns - CSV Dump - Copy and rename table - Table comment (no more table needed) - Table check and repair - Customizable interfaces - Multi-users capabilities (based on htaccess) I know this is too similar to phpmyadmin, but the interface is so much nicer, no frames, that it is really worth it. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux aenima 2.4.18 #9 Tue Jun 25 20:53:50 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set) -- no debconf information -- .''`. Somewhere on this globe, every ten seconds, there is a woman giving : :' : birth to a child. She must be found and stopped -- Sam Levenson `. `' Proudly running Debian GNU/Linux Sid (2.4.18 + Ext3) `-www.amayita.com www.malapecora.com www.chicasduras.com
Bug#159574: general: Policy, Dependancy, Conflics - breaches - many
Package: general Version: N/A; reported 2002-09-04 Severity: important -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux link 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586 Locale: LANG=C, LC_CTYPE=C Hi, I really like Debians huge collection and the fact that it gives the user full liberty to choose. However - the liberty is every harder use as many packages are no longer following either Debian Policy or the Debian Social Contract. DEBIAN BUG: Many packages have dependacies that don't actually exist. DEBIAN BUG: Many packages have 'conflicts' that don't actually exist. There are WAY to many example. "gdm and xdm conflict": Thats complete bull. I use both. They don't conflict. They don't even need to use "alternatives" because they don't use the same resources. "xpaint and xfree86 conflict". If you install the classic "xpaint" then you have to remove X. That's so brain damaged it has to be criminal in origin. Infact: force install xpaint without the "required" lib: you'll find it works great, the marking is bull. If I uninstall "exim" - "cron" is selected for removal EVEN THOUGH I've selected otherwise. Obviously - cron doesn't need a mailer - but the system needs cron. What kind of idiot marked that package? Fact is: cron runs its service - mailer or no. DEBIAN BUG: Many packages break when "removed". Reinstalling does not correct. Reconfigure does not correct. DEBIAN BUG: Many packages are marked as using libraries that they don't actually use - causeing extraneous dependancies and conflicts. DEBIAN BUG: 'dselect' is WAY to 'helpful' in removing packages you have installed and preventing you from installing what you need installed. For instance: SVGA and S3 are both needed on one of my boxes. Is it *really* necessary to have stop and reconfigure the installer every time something simple and complete cogent is being done?? My point is: a warning is appreciated. But an "all stop - you can't do that" where I have to go out of my way to install a package -- that's just bull. DEBIAN BUG: dselect often removes packages which aren't selected for removal DEBIAN BUG: the "remove old cache y/n" message too easily clobbers the cache. DEBIAN BUG: Many packages break once "removed". 1) they do not remove all files (ok) 2) BUT when reinstall - they don't reinstall all files 3) you remove package, then all files, then reinstall 4) --> you STILL don't have all the files required <-- Gnome is one of these - but their are many. DEBIAN BUG: Many packages are *not* using the 'alternative' methods so they can co-exist with applications using similar resources. Thanks, John D. Hendrickson [EMAIL PROTECTED] [EMAIL PROTECTED] Oh, and Have Fun :)
Bug#159574: marked as done (general: Policy, Dependancy, Conflics - breaches - many)
Your message dated Wed, 4 Sep 2002 12:56:07 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#159574: general: Policy, Dependancy, Conflics - breaches - many has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 4 Sep 2002 10:46:09 + >From [EMAIL PROTECTED] Wed Sep 04 05:46:09 2002 Return-path: <[EMAIL PROTECTED]> Received: from ip68-100-131-54.nv.nv.cox.net (link.hunter) [68.100.131.54] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 17mXfl-0005Js-00; Wed, 04 Sep 2002 05:46:09 -0500 Received: (from [EMAIL PROTECTED]) by link.hunter (8.11.3/8.11.3) id g846kJq04765; Wed, 4 Sep 2002 02:46:19 -0400 Message-Id: <[EMAIL PROTECTED]> From: "John D. Hendrickson" <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: general: Policy, Dependancy, Conflics - breaches - many X-Mailer: reportbug 1.50 Date: Wed, 04 Sep 2002 02:46:19 -0400 X-BadReturnPath: [EMAIL PROTECTED] rewritten as [EMAIL PROTECTED] using "From" header Delivered-To: [EMAIL PROTECTED] Package: general Version: N/A; reported 2002-09-04 Severity: important -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux link 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586 Locale: LANG=C, LC_CTYPE=C Hi, I really like Debians huge collection and the fact that it gives the user full liberty to choose. However - the liberty is every harder use as many packages are no longer following either Debian Policy or the Debian Social Contract. DEBIAN BUG: Many packages have dependacies that don't actually exist. DEBIAN BUG: Many packages have 'conflicts' that don't actually exist. There are WAY to many example. "gdm and xdm conflict": Thats complete bull. I use both. They don't conflict. They don't even need to use "alternatives" because they don't use the same resources. "xpaint and xfree86 conflict". If you install the classic "xpaint" then you have to remove X. That's so brain damaged it has to be criminal in origin. Infact: force install xpaint without the "required" lib: you'll find it works great, the marking is bull. If I uninstall "exim" - "cron" is selected for removal EVEN THOUGH I've selected otherwise. Obviously - cron doesn't need a mailer - but the system needs cron. What kind of idiot marked that package? Fact is: cron runs its service - mailer or no. DEBIAN BUG: Many packages break when "removed". Reinstalling does not correct. Reconfigure does not correct. DEBIAN BUG: Many packages are marked as using libraries that they don't actually use - causeing extraneous dependancies and conflicts. DEBIAN BUG: 'dselect' is WAY to 'helpful' in removing packages you have installed and preventing you from installing what you need installed. For instance: SVGA and S3 are both needed on one of my boxes. Is it *really* necessary to have stop and reconfigure the installer every time something simple and complete cogent is being done?? My point is: a warning is appreciated. But an "all stop - you can't do that" where I have to go out of my way to install a package -- that's just bull. DEBIAN BUG: dselect often removes packages which aren't selected for removal DEBIAN BUG: the "remove old cache y/n" message too easily clobbers the cache. DEBIAN BUG: Many packages break once "removed". 1) they do not remove all files (ok) 2) BUT when reinstall - they don't reinstall all files 3) you remove package, then all files, then reinstall 4) --> you STILL don't have all the files required <-- Gnome is one of these - but their are many. DEBIAN BUG: Many packages are *not* using the 'alternative' methods so they can co-exist with applications using similar resources. Thanks, John D. Hendrickson [EMAIL PROTECTED] [EMAIL PROTECTED] Oh, and Have Fun :) --- Received: (at 159574-done) by bugs.debian.org; 4 Sep 2002 10:56:12 + >From [EMAIL PROTECTED] Wed Sep 04 05:56:12 2002 Return-path: <[EMAIL PROTECTED]> Received: from cabal.xs4all.nl (mx1.wiggy.net) [213.84.101.140] ([/mMySD491G07RKpQwTa1FqAb/AAVOFTX]) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 17mXpT-0005qB-00; Wed, 04 Sep 2002 05:56:12 -0500 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 17mXpP-0005
Re: amavis build error on m68k
>> Brian May <[EMAIL PROTECTED]> writes: > > checking for perl modules... > > module not found in path: 'MIME/Parser'. > > configure: error: You are missing some perl modules. Please check the > > README Funky... Looking in auric at the file /org/ftp.debian.org/ftp/dists/sid/Contents-m68k.gz I see MIME/Parser.pm there (m68k is pointless, libmime-parser is arch all). Looking at the script used to test for this (test.pl), I don't really see a reason why this should fail. Parser.pm returns 1 as it should. So, what I'm trying to say is look for the problem elsewhere, it doesn't seem to be neither in libmime-perl nor amavis. It seems to be a m68k-specific problem. Look at the build log for perl on m68k perhaps? -- Marcelo | "Not a man to mince words. People, yes. But not words." [EMAIL PROTECTED] | -- (Terry Pratchett, Small Gods)
Re: More manpower to our core teams
On Mon, Sep 02, 2002 at 12:02:08AM +0200, Josip Rodin wrote: > > > Anyway, I don't see the point of posting their email addresses. > > > > They're more or less public anyway, so that don't hurt. > > I for one wouldn't have liked if someone sent my @d.o address to -d-a, > because I don't use it for that stuff in order to have less spam on it. > IWJ seems to do the same for his @d.o address, and I believe several others. Okay, won't do that again. Greetings Torsten pgpDvTxdnaUDi.pgp Description: PGP signature
Bug#159574: general: Policy, Dependancy, Conflics - breaches - many
On Wed, Sep 04, 2002 at 02:46:19AM -0400, John D. Hendrickson wrote: > DEBIAN BUG: Many packages have dependacies that don't actually exist. Only in contrib/non-free. Anything else should be reported against the packages in question. > DEBIAN BUG: Many packages have 'conflicts' that don't actually exist. > > There are WAY to many example. "gdm and xdm conflict": Thats > complete bull. I use both. They don't conflict. They don't > even need to use "alternatives" because they don't use the same > resources. What distribution are you using? potato, I suspect. They don't conflict in woody. > "xpaint and xfree86 conflict". If you install the classic "xpaint" > then you have to remove X. That's so brain damaged it has to be > criminal in origin. Infact: force install xpaint without the > "required" lib: you'll find it works great, the marking is bull. What? xpaint doesn't conflict with anything. > If I uninstall "exim" - "cron" is selected for removal EVEN > THOUGH I've selected otherwise. Obviously - cron doesn't need > a mailer - but the system needs cron. What kind of idiot marked > that package? Fact is: cron runs its service - mailer or no. cron only Recommends: exim, and dselect 1.10 in testing/unstable doesn't force you to install recommendations. Earlier versions did. > DEBIAN BUG: Many packages break when "removed". Reinstalling does not > correct. Reconfigure does not correct. It would be productive to file bugs against those packages. > DEBIAN BUG: Many packages are marked as using libraries that they don't > actually use - causeing extraneous dependancies and conflicts. Ditto. Filing this against general might be a good way to complain loudly, but I'm not sure it's actually a good way to get things fixed. :) Upgrade to a modern version of Debian first, though. -- Colin Watson [EMAIL PROTECTED]
Re: Improper NMU (Re: NMU for libquota-perl)
On Sun, Sep 01, 2002 at 07:13:33PM -0500, John Goerzen wrote: > I'm concerned that a single person has the power to dictate such dramatic > changes in our procedures. Why is the NMU procedure not codified in Debian > Policy? There, at least, we have a better mechanism of updating it. You mean we have a better mechanism to not update it. In my opinion there is too much bureaucracy involved in changing debian-policy. I know about the debian-policy list and all that but it's just too hard to fight something through until it gets accepted if you don't have a lot of time to follow up on the discussions. And I bet Anthony for example does not have that much time... cu Torsten pgpBplPhNWclS.pgp Description: PGP signature
Re: Deleting /var/cache/*
On Wed, 04 Sep 2002, Martijn van Oosterhout wrote:
> Ofcourse, it could just do system("mkdir -p /var/cache/whatever/dir/it/is")
> everytime it wants to open a file but that would be inefficient.
If it has the permissions to do so. Not everything runs as root and can
create directories belowe /var/cache/.
yours,
peter
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred.| : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `-http://www.debian.org/
pgprKgAQ1ktc5.pgp
Description: PGP signature
HE ENCONTRADO UN VIRUS EN UN CORREO DE almeria@masterd.es PARA USTED
V I R U S A L E R T Nuestro antivirus ha encontrado los siguientes virus(es) I-Worm.Klez.h I-Worm.Klez.h en un correo para usted de: [EMAIL PROTECTED] ¡La entrega del correo ha sido detenida! Por favor, contacte con su administrador de correo ([EMAIL PROTECTED]) para más detalles.
[RFD] optimized versions of openssl
Hi, as you might know, there is only one binary package of libssl0.9.6 for each architecture. These packages are all build for the least capable processor. eg. for i386 there is no optimisation for pentiums etc. This has the benefit that it works on every i386 compatible processor but it is slow on processors where there could be a lot of optimisation. The idea is to have a standard libssl0.9.6 package with no optimisation and some optional packages like libssl0.9.6-i686 or libssl0.9.6-k7 which can replace libssl0.9.6. Do we have a general opinion or policy on optimized library versions? Other libraries (like libgmp?) could have the same issues. One problem is, that the build process and the names and number of packages would be depending on the architecture and can not be done with a standard rules files. Do we have modells for this? What do you think? Christoph -- Christoph Martin, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED]
Re: [RFD] optimized versions of openssl
On 09/04/2002 08:12:50 AM Christoph Martin wrote: >> etc. This has the benefit that it works on every i386 compatible >> processor but it is slow on processors where there could be a lot of >> optimisation. Oh not this thread again! Processor specific optimizations for i386 is debated approx every 2 months on debian-devel, plus or minus other distributions PR campaigns. >> Do we have a general opinion or policy on optimized library versions? I think I can safely speak for everyone on debian-devel as per this: 1) The difference in overall speed is small, and rarely publically reported. The 1% gain is individually considered either vital must-have, or worthless. 2) The archive disk space required expands. This is individually considered either intolerably huge or not worth mentioning. 3) In a question of "good taste" like this, one developer can't force another developer to either do this or not do this. If you want to do this, no one can stop you. >> Do we have modells for this? The kernel-image packages. >> What do you think? This eternal flamewar is located somewhere in: http://lists.debian.org archives
Re: Dumb little utilities
On 3 Sep 2002, Goswin Brederlow wrote: > "J. Scott Edwards" <[EMAIL PROTECTED]> writes: > > > On Wed Aug 28 11:37:29 2002 Allan Wind wrote: > > > On 2002-08-27 21:59:28, J. Scott Edwards wrote: > > > > file slicer (that can slice up a file into different size chunks). > > > > > > dd? > > > > Yea, that would do it, slightly more cumbersome to use. > > split ? > split is cool, but I thought it would only divide the file up into the same size pieces. So you would have to run it several times. -Scott
Re: Dumb little utilities
On Wed, Aug 28, 2002 at 08:19:54AM +0200, Ola Lundqvist wrote: > > little endian hex dump > May be interesting. Should be an option to "od", really. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: [RFD] optimized versions of openssl
On 09/04/2002 08:26:19 AM "Vince Mulhollon" wrote: >> I think I can safely speak for everyone on debian-devel as per this: >> >> 1) The difference in overall speed is small, and rarely publically >> reported. >> The 1% gain is individually considered either vital must-have, or >> worthless. >> 2) The archive disk space required expands. >> This is individually considered either intolerably huge or not worth >> mentioning. >> 3) In a question of "good taste" like this, one developer can't force >> another developer to either do this or not do this. >> If you want to do this, no one can stop you. I apologize for following up to my own response but I forgot one important one: 4) It makes troubleshooting "more exciting". Does user A's SSL not work while user B's works OK? What if user A is using -i386 while user B is using -tsc586 and the package maintainer is using -k6? Some individuals don't consider this a problem, some consider this a crisis.
Re: [RFD] optimized versions of openssl
>> Christoph Martin <[EMAIL PROTECTED]> writes: > The idea is to have a standard libssl0.9.6 package with no > optimisation and some optional packages like libssl0.9.6-i686 or > libssl0.9.6-k7 which can replace libssl0.9.6. The shared library is 179 kB. Why don't you just provide the optimized versions in the same package? Are the any stability/correctness issues with the optimized versions? If there are, what do you say to people installing the optimized packages and having trouble because of that? "I'm sorry, you installed a package I provide, ergo the problem is your fault not mine"? That doesn't sound right. -- Marcelo | Item 47: Ensure that non-local static objects are [EMAIL PROTECTED] | initialized before they are used | -- Scott Meyers, Effective C++
Re: Dumb little utilities
On Tue, 3 Sep 2002, Malcolm Parsons wrote: > On Tue, Sep 03, 2002 at 01:07:28PM -0600, J. Scott Edwards wrote: > > > > On Wed, 28 Aug 2002 Marcelo E. Magallon wrote: > > > > > > > > >> Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > > > > > > tab and untab (I just discovered that this can be done with pr). > > > > If it can be done with something else it might not be too necessary. It > > > > is your choice though. > > > > > > JFYI, it can also be done with expand. > > > > > > > One down. Is there a program to do the reverse and convert the spaces to > > tabs? > > unexpand. > Two down :)
Re: [RFD] optimized versions of openssl
On Wed, Sep 04, 2002 at 08:26:19AM -0500, Vince Mulhollon wrote: > On 09/04/2002 08:12:50 AM Christoph Martin wrote: > >> etc. This has the benefit that it works on every i386 compatible > >> processor but it is slow on processors where there could be a lot of > >> optimisation. > > Oh not this thread again! > Processor specific optimizations for i386 is debated approx every 2 months > on debian-devel, plus or minus other distributions PR campaigns. And SSL is one of the cases where it's actually important, unlike most other packages. -- Colin Watson [EMAIL PROTECTED]
Re: [RFD] optimized versions of openssl
"Vince Mulhollon" <[EMAIL PROTECTED]> writes: > I think I can safely speak for everyone on debian-devel as per this: > > 1) The difference in overall speed is small, and rarely publically > reported. The 1% gain is individually considered either vital > must-have, or worthless. You have obviously never used ssl on a SPARC machine. The lowest supported SPARC architecture is SPARCv7 which does not have hardware division and multiplication. Recompiling libssl with SPARCv8 optimizations speeds up logging in with ssh on an Ultra1 (SPARCv9) by a factor of 6, IIRC. See the debian-sparc archives for details. > This eternal flamewar is located somewhere in: > http://lists.debian.org archives And the less flamy part is in http://lists.debian.org/debian-sparc -- ilmari
Re: Dumb little utilities
I had no idea all of these existed (I have heard of zsh). Is there anyway
of finding these things out? Apropos won't work if you don't have them
installed?
Thanks
-Scott
On Tue, 3 Sep 2002, Clint Adams wrote:
> And if you use zsh, you don't need to bother with mmv or rename, since
> there's zmv.
>
> > > Anyway, it's similar to the 'rename' command that someone else mentioned.
> > > It renames multiple files like converting all the files in a directory
> > > from upper to lower case
> >
> > mmv \* \#l1
>
> zmv '(*)' '${(L)1}'
>
> > > or changing the extension of the *.c files to *.x.
> >
> > mmv \*.c \#1.x
>
> zmv '(*).c' '$1.x'
>
> or
>
> zmv -W '*.c' '*.x'
>
> or
>
> alias ren='noglob zmv -W'
> ren *.c *.x
>
>
> I find the last preferable to the more cumbersome syntaxes of rename and
> mmv.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
Re [RFD] optimized versions of openssl
> "Vince Mulhollon" <[EMAIL PROTECTED]> writes: > > > I think I can safely speak for everyone on debian-devel as per this: > > > > 1) The difference in overall speed is small, and rarely publically > > reported. The 1% gain is individually considered either vital > > must-have, or worthless. > > You have obviously never used ssl on a SPARC machine. The lowest > supported SPARC architecture is SPARCv7 which does not have hardware > division and multiplication. Recompiling libssl with SPARCv8 > optimizations speeds up logging in with ssh on an Ultra1 (SPARCv9) by > a factor of 6, IIRC. See the debian-sparc archives for details. I have a Sparc 5 and would never dream of attempting to use ssh without rebuilding openssl with the -mv8 optimization. I can definately state that it is an added benefit. Chris > > > This eternal flamewar is located somewhere in: > > http://lists.debian.org archives > > And the less flamy part is in http://lists.debian.org/debian-sparc > > -- > ilmari > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
Re: [RFD] optimized versions of openssl
On Wed, Sep 04, 2002 at 08:26:19AM -0500, Vince Mulhollon wrote: > I think I can safely speak for everyone on debian-devel as per this: > > 1) The difference in overall speed is small, and rarely publically > reported. > The 1% gain is individually considered either vital must-have, or > worthless. You're wholly incorrect here. Note the subject: openssl. Openssl has processor-specific assembly routines that are built at compile time. Using those routines rather than the least common denominator makes a *huge* difference in performance. (On sparc, for example, it can make the difference between an almost instantaneous ssh login and one that takes several seconds.) Back to the subject at hand, it would be nice at the least if there were an easy way to manually build processor-optimized ssl packages. (The current procedure to do that is anything but obvious or simple.) -- Mike Stone pgpVwdVy0MdGS.pgp Description: PGP signature
Re: [RFD] optimized versions of openssl
On 09/04/2002 08:51:02 AM [EMAIL PROTECTED] (Dagfinn Ilmari Mannsåker) wrote: >> division and multiplication. Recompiling libssl with SPARCv8 >> optimizations speeds up logging in with ssh on an Ultra1 (SPARCv9) by >> a factor of 6, IIRC. See the debian-sparc archives for details. This is quite possibly the first time during the eternal debate of processor specific optimizations on debian-devel, that someone has ever posted real measured numbers, showing greater than single digit percentage improvements for optimization. That changes the debate. In this individual case, I'd agree with you, it would be a great idea for someone to create a libssl-*-sparc8 package.
Re: [RFD] optimized versions of openssl
On Wed, Sep 04, 2002 at 03:35:58PM +0200, Marcelo E. Magallon wrote: > The shared library is 179 kB. Why don't you just provide the optimized > versions in the same package? Are the any stability/correctness issues Now for the real overachiever, what would be really cool is if you hacked openssl to do *runtime* detection of which optimizations to use. -- Mike Stone pgplPPbiNc8cG.pgp Description: PGP signature
Bug#159606: general: Gnome packaging crash prone, Xsession.
Package: general Version: N/A; reported 2002-09-04 Severity: important -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux link 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586 Locale: LANG=C, LC_CTYPE=C Hi, I've found a few problems with the X startups: which often don't really start X :) I think many user problems would go away if permissions were checked when gnome installs (or perms were tested in cron run). Since permission checks are somewhat standard in other packages, this should be possible. I find gnome is far to suceptible to not working. You log in with gdm and then get kicked out - back to gdm. You finally get in (likely by giving up your old desktop), you have no login environment. You uninstall and reinstall - but required files are still missing. Load gmc: sometimes it closes and opens in a loop. When Gnome doesn't load it often leaves no log messages or console messages as to why: you'd have to get the source or just guess. I put an old script of mine below about the HOME directory and Gnome. GDM BUG: GDM does not really login users correctly: --> GDM logs in the user without a login ENVIRONMENT <-- --> XDM logs in the user WITH a POSIX login ENVIRONMENT <-- (xdm can launch gnome easily) After much work figuring out why my login ENV wasn't being loaded, I narrowed it down to GDM (because everything GNOME works until GDM enters the picture). I wrote the author and of course got no reply. (You might not notice this unless you use a POSIX compliant login environment that sets environment variable when. A workaround for bash is below.) DEBIAN BUG: Xsession Xsession breaks the Xfree86 starup rules - with the meantion that those 'old startups' didn't handle multiple startups. That is is just plain wrong. However, Xsession ISN'T IN THE LOOP for Gnome startup. So, if its not 'IN THE LOOP' for starting the big few desktops, why does it need to ignore Xfree86 configs which work with xinit, xdm, startx (had Xsession not been there to misconfigure things ??) That is: why does Xsession need to rename the startup files and call them in a different order -- but add nothing new to the startup process ?? Certainly, a 'run-parts' could be in the system 'xinit'. So that is not an answer. Xinit, startx, xdm, ... have allways been compatible with multiple window managers. That's nothing new in any system. However, Xsession breaks the POSIX starup rule that allows the user to control their own starup in their home directory(s). Of course the old configs *were* carefully organized to allow system defaults AND user control as well - because it is the unix way to allow the user to run non-root software they have permission to run - they way they need to run it, right? Thanks, John D. Hendrickson [EMAIL PROTECTED] [EMAIL PROTECTED] # -- #!/bin/sh # Below: some talk and a script pertaining to Gnome files in $HOME, # and some solutions to various broken things. # # NOT GAURANTEED, of course # # Q: Some users can log into Gnome - some can't. # Q: I login with "gdm" - but it brings me back to the login. # # Gnome may not load or do WEIRD things if its file and directories are # setup wrong. For example - after "gdm" loging you don't get a spash # and it exits. Or no splash and just a plain destop. Also, you might # find "gmc" is acting weird - like it will open and close immediately # in a loop and applications aren't launching. # # The below script can fix some simple problems. # # Try this from the prompt to see if it will work. # (insure X is shutdown first, of course) # # bash# X vt7 & xterm & # This should work. Ctrl-Alt-Backspace. # # If it does not - then you may have a STARTUP problem - not a Gnome # configuration problem. Startup problems is a very big topic which # can span X, /etc/profile, /etc/X11, pam, gdm.conf, ssh, Xsession, # and worse. Try reinstalling :) As your linux distribution gets # bigger - so trouble shooting problems. # # also try: # bash# X vt7 & gnome-session & # # If that doesn't work but the first did - then you likely have a gnome # configureation problem. However - if the second line worked - but # your "gdm" logins don't. Hmm... Could be gdm - many something else. # # ---> # So don't bother with this script 1 and 2 worked as the same user in # question. # ---> # # Gnome's greatest design flaw ist thoughtless startup complexity, poor # error reporting, and no fail-safe, all combined. Why doesn't it just # start a basic desktop and THEN go goofing around ?? :) # # Corrupt or misconfigured things like those little startbar apps, # and incorrect launchers can cause severe enough p
Re: [RFD] optimized versions of openssl
>> Michael Stone <[EMAIL PROTECTED]> writes:
> Now for the real overachiever, what would be really cool is if you
> hacked openssl to do *runtime* detection of which optimizations to use.
That would be indeed much better. I blindly assumed he was talking
about compiler flags and I further assumed that openssl for some reason
exhibits an actual speedup thanks to those flags -- as opposed to the
usual 1% or so. If OpenSSL actually has hand-crafted processor
specific optimizations runtime detection would be indeed the way to go.
Even further, abstracting all this CPU detection stuff inside a library
would be the coolest thing. Something like:
struct cpu_optimized_function do_foobar_table[] = {
{ CPUDETECT_GENERIC, do_foobar_generic },
#if defined(INTEL...)
{ CPUDETECT_SSE, do_foobar_sse },
{ CPUDETECT_MMX, do_foobar_mmx },
#endif
#if defined(SPARC...)
{ CPUDETECT_SPARCV8, do_foobar_sv8 },
#endif
{ NULL, NULL }
};
/* ... */
do_foobar = pick_optimized_function(do_foobar_table);
Even better, hide the conditional inside a macro:
struct cpu_optimized_function do_foobar_table[] = {
CPUDETECT_GENERIC_ENTRY(do_foobar_generic)
CPUDETECT_SSE_ENTRY(do_foobar_sse)
CPUDETECT_MMX_ENTRY(do_foobar_mmx)
CPUDETECT_SV8_ENTRY(do_foobar_sv8)
CPUDETECT_LAST_ENTRY
};
something along those lines...
My guess is that this would foster runtime CPU detection since it
becomes a no-brainer.
--
Marcelo | "I can bite your leg if you like."
[EMAIL PROTECTED] | -- Gaspode the wonder dog
|(Terry Pratchett, Moving Pictures)
Re: Mostly solved (Is it me, pbuilder, dpkg or something else?)
On Tue, Sep 03, 2002 at 09:57:26PM +0900, Junichi Uekawa wrote: > On Tue, 3 Sep 2002 12:30:43 +0300 > [EMAIL PROTECTED] wrote: > > Extracting source > > unable to get login information for username "shaul" at > > /usr/lib/dpkg/controllib.pl line 56. > > Compilation failed in require at /usr/bin/dpkg-source line 22. > > pbuilder: Failed extracting the source > > -> unmounting /proc filesystem > > -> unmounting /dev/pts filesystem > > -> cleaning the build env > > [EMAIL PROTECTED]:/tmp# exit > > exit > > > This error is being emit inside the chroot, which > > > > > [EMAIL PROTECTED]:/tmp$ getent passwd shaul > > shaul:x:1000:1000:Shaul Karl,,,:/home/shaul:/bin/bash > > [EMAIL PROTECTED]:/tmp$ > > should be untrue. > I didn't fully understand you. Did you meant that the getent command should not have given those results? If so then I should have clarify that the getent command was not run from within the chroot. Instead I used a shell which has the normal system / as its root. Anyway, I have managed to get pbuilder to build those packages by putting the line BUILDUSERNAME=shaul in /etc/pbuilderrc. Previously BUILDUSERNAME was not defined. I still get Extracting source su: Authentication service cannot retrieve authentication info. (Ignored) But I hope it is harmless. > There is probably something else in your setup that is broken. > > > regards, > junichi > > -- > [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Shaul Karl, [EMAIL PROTECTED] e t
Re: [RFD] optimized versions of openssl
Michael Stone writes: > On Wed, Sep 04, 2002 at 03:35:58PM +0200, Marcelo E. Magallon wrote: > > The shared library is 179 kB. Why don't you just provide the optimized > > versions in the same package? Are the any stability/correctness issues > > Now for the real overachiever, what would be really cool is if you > hacked openssl to do *runtime* detection of which optimizations to use. I suspect it would be "better" to do install-time selection; the preferred way to choose is to benchmark the alternatives on a realistic task. That isn't something most people would want to do when they load the library, since it takes a while to do, and on a given CPU, the results are unlikely to change over time. Semi-static choice also makes it easier to diagnose which variant is being used when there are problems and is probably easier to do than run-time selection. (The overachiever variant of this is to set up dpkg alternatives at install-time so that the system admin can use the existing framework to override the automatic selection.) Michael
