Re: DMA, ide-scsi, devfs by default
Erich Schubert <[EMAIL PROTECTED]> writes: > But if it is reliable i would recommend using it. It makes lot of things > much easier and probably is much more intuitive for beginners as well. > (just thinking of /dev/discs/disc0/part1 and /dev/cdroms/cdrom0 ) What's especially cool is that it hardwires the British (or Australian, in this case, I guess) spelling of `disc' as part of the UI, though `disk' seems far more widespread in the rest of the kernel (consistency, what's that?) -Miles -- We live, as we dream -- alone
Re: consider regression of perl!
Dan, Then you might take a stab at debugging the testcase from the bugzilla report... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=69254 ...since it sounds similar. If it isn't then we have another bug to fix. Jack
Re: consider regression of perl!
On Mon, Aug 26, 2002 at 11:48:21PM -0400, Jack Howarth wrote: > Adam, >Well it will be one thing if the debian perl maintainers > are going to actively track down and fix these critical perl > bugs on their own. However if we are going to passively wait > for fixes from upstream, perhaps perl 5.80 will introduce > a bit too much breakage for right now. I mean dpkg IS an > essential package. You can't break that willy nilly. Also, > correct me if I'm wrong but doesn't even gentoo linux consider > perl 5.80 too twitchy to include? Jack, This is in the definition of unstable. Problems need to be a great deal more widespread before we would resort to backing down from an upgrade. I am working with Brendan to help him reproduce this bug. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: How to get rid of non-free packers?
At Mon, 26 Aug 2002 00:23:30 -0700, Osamu Aoki wrote: > On Mon, Aug 26, 2002 at 09:33:40AM +0900, GOTO Masanori wrote: > > At Fri, 23 Aug 2002 16:01:15 +0300, > > Juhapekka Tolvanen wrote: > > >It's free to distribute on the network, but if you distribute for > > >the people who cannot access the network (by magazine or CD-ROM), > > >please send E-Mail (Inter-Net address) to the author before the > > >distribution. That's well where this software is appeared. > > >If you cannot do, you must send me the E-Mail later. > > > > > > Original Source Code License Statement: > > > > > >/*Copyright (C) MCMLXXXIX Yooichi.Tagawa */ > > >/*ModifiedNobutaka Watazaki */ > > >/* Thanks to H.Yoshizaki. (MS-DOS LHarc)*/ > > > > > > Clip here > > Masanori, I do not know where you got this but this is memo by Tsugio. > > Manual page seems to me the thorough license from the original authors. > Please consider the following for copyright section. Many restrictions > for commercial use of modified code. Thank you for your indication and translation! I've added the below statement. > Boy, this license did not make much sense even in Japanese. It get > worse with my English. (Maybe this was so bad Masanori may have skipped > translating this one.) > > Here "commercial" may be interpreted as "for-fee". "Added value" seems > to mean "feature enhancement". Your translation is great. Original statement has only weak argument... The insufficiency of this license statement is similar to early Japanese "freeware" licenses. I agree with your terms. Thanks. > > > I think, only way to get free unpacking software for LHA-files is to > > > negotiate with those Japanese persons. Here are some URL of Japanese > > > LHA-software: > > > > > > http://shibuya.cool.ne.jp/lha/ > > > > I think it can be replaceable with below Tsugio's source. > > > > > http://www2m.biglobe.ne.jp/~dolphin/lha/lha.htm > > > > Debian package uses his (Tsugio's) source. It also can handle -lh7- > > format. I already contacted with him, but his response were too slow > > (waited over 4 months, or more!), and he thought changing license was > > very difficult. LHa for unix was hacked by many people at least over > > 13 years, they have treated their license as "vague". Historical > > reason makes difficult to change their license. > > It looks like Arai-san [EMAIL PROTECTED] seems to be most active. > http://ns103.net/~arai is his URL > > He has new autoconf version. > > It looks to me people are treating almost like public domain as long as > New sources are available to general public. It's worth considering to include/replace with his patch. It includes some more features. My little concern is he does not state any copyright issues clearly. I try to contact to him. Regards, -- gotom
Re: consider regression of perl!
Adam, Well it will be one thing if the debian perl maintainers are going to actively track down and fix these critical perl bugs on their own. However if we are going to passively wait for fixes from upstream, perhaps perl 5.80 will introduce a bit too much breakage for right now. I mean dpkg IS an essential package. You can't break that willy nilly. Also, correct me if I'm wrong but doesn't even gentoo linux consider perl 5.80 too twitchy to include? Jack ~
Re: Hello.
On Mon, 26 Aug 2002, David D.W. Downey wrote: > On Tue, Aug 27, 2002 at 03:37:14AM +0300, Nir Peled woke up, and decided to > spew forth: > > I'm SURE you'll have a lot more *customers* If you'll add KDE3.0.3 (Released > > few days ago) I'm also idleing in your server on the OPN network, And if > > you'll join #debian in there you'll see the request for Newer KDE Is big. > > No one likes to compile from source (Which can make a dependencies > > problems). > > So, I know I don't really count for you, but It'll be very nice if you'll > > release an update to KDE. We have customers? We only have users. Please be aware of the distinction.
Re: consider regression of perl!
On Mon, 26 Aug 2002, Jack Howarth wrote: > Hello, > Considering how unstable perl 5.80 currently is, wouldn't it be > wise to regress sid back to perl 5.60 and move 5.80 into experimental > instead? So far this upgrade has done major damage to dpkg by breaking > install-info making any additional glibc builds in sid impossible. > I have also found similar bugreports in bugzilla of perl segfaulting > in certain circumstances. With debian's heavy reliance on perl for its > system maintenance scripts this current move to 5.80 seems far too > destablizing for sid. Especially as it will wreak havoc with any move > to gcc 3.2 builds. unstable is as unstable does. /me goes about looking for a Cheese of the Month Club, to sign Jack up for.
consider regression of perl!
Hello, Considering how unstable perl 5.80 currently is, wouldn't it be wise to regress sid back to perl 5.60 and move 5.80 into experimental instead? So far this upgrade has done major damage to dpkg by breaking install-info making any additional glibc builds in sid impossible. I have also found similar bugreports in bugzilla of perl segfaulting in certain circumstances. With debian's heavy reliance on perl for its system maintenance scripts this current move to 5.80 seems far too destablizing for sid. Especially as it will wreak havoc with any move to gcc 3.2 builds. Jack
Re: Security notification script
On Mon, 2002-08-26 at 16:31, Rob Bradford wrote: > http://www.robster.org.uk/files/security-update-check.py That's an interesting approach. What I do is: #!/bin/sh apt-get -qq update && apt-get -qq -s dist-upgrade in /etc/cron.daily/local_aptupdate. Of course, this mails me if any packages are going to be changed, not just ones from security.d.o. But since my machine runs woody, these are the only changed packages.
Re: Hello.
On Tue, Aug 27, 2002 at 03:37:14AM +0300, Nir Peled woke up, and decided to spew forth: > I'm SURE you'll have a lot more *customers* If you'll add KDE3.0.3 (Released > few days ago) I'm also idleing in your server on the OPN network, And if > you'll join #debian in there you'll see the request for Newer KDE Is big. > No one likes to compile from source (Which can make a dependencies problems). > So, I know I don't really count for you, but It'll be very nice if you'll > release an update to KDE. > While this is true, you have to bear in mind both the development cycle timeline as well as the level of bug hunting that takes place in Debian GNU/Linux. Just because the latest and greatest was released the day before does not entitle it to immediate inclusion in Debian. It has a slew of bug testing to go through before it even makes it into the *testing* branch, never mind the stable branch. This is the defining line between Debian and most other distributions. Most other distributions will auto include the latest and greatest with *very* little bug testing (ther than sufficient testing to get it to at least install), whereas Debian GNU/Linux does extensive testing and bug collection *before* it's released. Unstable is the first stop of any application into the Debian stream. Once it's in Unstable, it will be eligible for pipelining further into the system once it's been extensively tested and battered into shape. -- David D.W. Downey <[EMAIL PROTECTED]> Upstream - libpam-pgsql.codecastle.com Debian - Woody: 0.5.2-3 Sid: 0.5.2-5 State - bugs.debian.org/libpam-pgsql "The price of Free Software is Eternal Literacy." "I'd rather die on my feet, than live on my knees." Deloris Clayborn pgpWfIeGQEnzq.pgp Description: PGP signature
KDE 3.0.3 Packages (was: Hello)
On Tue, Aug 27, 2002 at 03:37:14AM +0300, Nir Peled wrote: > Hello, I'm using debian for like 6 months, I used Redhat before. I > gotta say Debian is **A LOT** Better then RH, I like the development > and all. :-) > My only concern is your packages (Not that bad, Just wondering) I'm > wondering why there's only KDE2.2 for stable.. I'm SURE you'll have a > lot more *customers* If you'll add KDE3.0.3 (Released few days ago) > I'm also idleing in your server on the OPN network, And if you'll join > #debian in there you'll see the request for Newer KDE Is big. No one > likes to compile from source (Which can make a dependencies problems). > So, I know I don't really count for you, but It'll be very nice if > you'll release an update to KDE. Perhaps you may be interested in this announcement on DebianPlanet: http://debianplanet.org/node.php?id=778 I don't personally use KDE, but that article and the comments will probably help. Cheers. :) --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE
urgent assistance
Petroleum (Special) Trust Fund Contract Award Committee National Secretariat Victoria-Island Lagos-Nigeria. Email:[EMAIL PROTECTED] ATTENTION: THE MANAGING DIRECTOR, The Petroleum Special Trust Fund was set up by the late Head of State General Sani Abacha who died on 8th June 1998, to manage the excess revenue accruing from the sale of petroleum and its allied products as a result of domestic increase in the prices of petroleum products. The estimated annual revenue for 1999 was 45 billion US Dollars Ref. FMF A26 Unit 3B paragraph "D" of the Auditor General of the Federal Republic of Nigeria Report of NOV. 1999 on estimated revenue. I am the Chairman of the Contract Award committee and my committee is solely responsible for awarding and payment of contracts on behalf of the Federal Government of Nigeria . My Committee awarded contracts to foreign contractors for the supply of Agricultural Machines and spare parts to the Ministry of Agriculture and Natural Resources. We overshot the contract sum by USD35 Million. We have paid the contractors and withholding the balance of 35 Million United States Dollars. Beceause of existing domestic laws forbidding civil servants from opening, operating and maintaining foreign accounts, we do not have the expertise to transfer this balance of funds to a foreign account. However, this balance of 35 Million United States Dollars($35 million USD) has been secured in form of credit/payment to a foreign contractor.Hence, we wish to transfer into your bank account as the beneficiary of the funds. We have also arrived at a conclusion that you will be compensated to the tune of 25% of the total sum transfered while 5% will be reserved for incidental expenses that both parties will incur in the course of actualizing this transaction and the balance of 70% will be kept for the Committee members. If you know you are capable of helping us actualize our life's dream,You should send to me immediately the details of your bank particulars or open a new account where we can transfer the money(US$35M)which you will hold in trust for us until we come over there for our own share.Your nature of business does not matter in this transaction. As soon as you open the account, send by e-mail immediately with thedetails of the account viz: Name of bank, address, routing number, telex number, Account number, Tel and Fax number.You should also include the name of your company, your personal address, Tel and Fax numbers for further communication. Note that this transaction will be concluded within 10 working days from the day you give your consent. Sincerely yours, mr micheal c nwolisa
Hello.
Hello, I'm using debian for like 6 months, I used Redhat before. I gotta say Debian is **A LOT** Better then RH, I like the development and all. My only concern is your packages (Not that bad, Just wondering) I'm wondering why there's only KDE2.2 for stable.. I'm SURE you'll have a lot more *customers* If you'll add KDE3.0.3 (Released few days ago) I'm also idleing in your server on the OPN network, And if you'll join #debian in there you'll see the request for Newer KDE Is big. No one likes to compile from source (Which can make a dependencies problems). So, I know I don't really count for you, but It'll be very nice if you'll release an update to KDE. Best Regards, Nir peled.
Re: Preferred way to build shared objects from PIC archives?
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > No, that should work fine. I don't know what's broken... you may wish > to try extracting all the objects via ar and relinking them; that > should be pretty easy, but I'm not sure it will help. That's actually how upstream does it, but then there are complications due to the fact that some libraries only contain *.glo instead of *.o (the former having OpenGL support enabled). Anyway, I managed to find the problem: on arm, the linker honors --no-whole-archive but silently ignores -no-whole-archive, so GCC's insertion of -lgcc -lc -lgcc leads to those errors when the linker sees the second -lgcc. (Sigh.) I have no idea why it's decided to become so picky, or why the problem only happens on arm, though I have to admit that the man page for ld only lists the double-dash form. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
unsubscribe mikael.petersson@lovelace.d2g.nu
Migration to /usr/share/doc
Hi everybody. This may be quite stupid or frivolous. :-) I have noticed the migration of the extra documentation files from /usr/doc/ to /usr/share/doc/ (as also describes the Debian Policy chapter 13.3). I am trying not to use exclusively the simbolic link to /usr/share/doc/ but to look directly to the new folder. Well, I there is a (very) simple and boring fact: the completion locks because there is /usr/share/doc-base/ too. I searched for some explanations about it in the Debian Policy, even if its name is self-explanatory. I did not find anything. Couri So my questions/proposals are: - Why this directory exists? And what is it about? - Is it possible to move their contents to /usr/share/doc/ allowing a faster search through the filesystem? Thanks for reading, Giorgio [I cc it to debian-devel] ___ Class, that's the only thing that counts in life. Class. Without class and style, a man's a bum; he might as well be dead. -- "Bugsy" Siegel
Re: old ITP's
* Bernd Eckenfels <[EMAIL PROTECTED]> [2002-08-26 23:43]: > > The changed date is clearly wrong. I suggest you redo your stats and > > post an updated list. > > and please include the email address of the reporter for better grepping. Plus the one who did the last modification. (Image an RFP which was retitled to ITP -- you want to know who retitled it, not who filed the bug). -- Martin Michlmayr [EMAIL PROTECTED]
Re: old ITP's
On Mon, Aug 26, 2002 at 11:11:03PM +0200, Peter Palfrader wrote: > The changed date is clearly wrong. I suggest you redo your stats and > post an updated list. and please include the email address of the reporter for better grepping. Greetings Bernd
Re: DMA, ide-scsi, devfs by default
BTW: i also remember having read that certain hardware doesn't work with ide-scsi, so enabling ide-scsi for all IDE hardware is a bad choice. (i think one of the boot-floppies people tried using ide-scsi by default, and got some problem reports) And additional drawback IMHO is the following: devfs is really nice, and it's nice to see /dev/cdroms/cdrom0 - but with ide-scsi i also get /dev/cdroms/cdrom1 ... 6 for different "luns" of my ide writer... i havn't yet understood why they are created... it's kind of unintuitive to have 7 nodes for my cd writer and 1 for my cd+dvd player... ) We also should watch what 2.5 will bring... now it seems like the IDE redesign was reverted, but maybe it will come again or yet another different approach. Maybe these kernels will be DMA-Enabled by default. I think there is an option to enable DMA by default for certain chipsets already - probably the ones where it is safe... I like devfs very much, btw - but there were race conditions and such stuff in there before, so the current state of devfs should be checked. But if it is reliable i would recommend using it. It makes lot of things much easier and probably is much more intuitive for beginners as well. (just thinking of /dev/discs/disc0/part1 and /dev/cdroms/cdrom0 ) Greetings, Erich -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C The best things in life are free: Friendship and Love. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. Humor sollte immmer dabeisein, auch bei Problemen.
Re: old ITP's
On Mon, 26 Aug 2002, Bas Zoetekouw wrote: > Below's a list of the bug tahtw will be renamed. The "filed" and > "changed" fields in the list are the number of days that have past since > the bug was opened, and since any addition was made to the report, > respectively. > #85612 mixmasterfiled: 560, changed 509 The changed date is clearly wrong. I suggest you redo your stats and post an updated list. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ pgpog7gX0GERy.pgp Description: PGP signature
Re: Convenient way to enable IDE DMA
On Monday 26 August 2002 12:45 pm, Nate Eldredge wrote: > As for hdparm, this is complicated with ide-scsi. For ide-scsi to work > you have to make the ide-cd module ignore the scsi-ified drive. In which > case /dev/hdc or whatever it is won't work until you have loaded the > ide-scsi module, perhaps by touching /dev/scd0. So at least in my setup, > further complications are needed. > Be warned, ide-scsi resets the using_dma flag when it's loaded. This is an even bigger problem with devfs, because after ide-cd is unloaded there is no /dev/hd? node to feed hdparm. The only workaround I've found so far is to create a temporary device node, /tmp/hdd, load ide-scsi, and `hdparm -d 1 /tmp/hdd'. Oh, you can get some pretty decent improvements with `hdparm -c 1' as well. It toggles 12/32-bit IDE transfer modes, and isn't reset by ide-scsi. Found all this out trying to get my new PlexWriter 40/12/40a 40x CD-RW drive to burn discs full speed. -- "das ist liebe, das ist hass / mit eifersucht vermahlen"
Re: Convenient way to enable IDE DMA
On Mon, Aug 26, 2002 at 12:45:54PM -0700, Nate Eldredge wrote: > > The other question is how it should be enabled. One way is "hdparm -d 1 > > /dev/hd?" or moral equivalent in an init script. Another way appears to > > be "hda=dma ..." or "ide0=dma ..." on the kernel command line, though I > > haven't tested this yet. Apparently there are also CD-ROM drives for > > which it should not be enabled. > > Further info: "hda=dma" doesn't seem to exist, I was mistaken. "ide0=dma" > doesn't actually enable dma, for some reason. "ide0=autotune" doesn't > either. Grr. > > As for hdparm, this is complicated with ide-scsi. For ide-scsi to work > you have to make the ide-cd module ignore the scsi-ified drive. In which > case /dev/hdc or whatever it is won't work until you have loaded the > ide-scsi module, perhaps by touching /dev/scd0. So at least in my setup, > further complications are needed. > > (Btw: a nice way to enable ide-scsi might be nice as well. CD burners are > becoming very common.) You mean something like maybe with 2.4: # CONFIG_BLK_DEV_IDECD is not set CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_ADMA=y CONFIG_BLK_DEV_PDC202XX=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y Substitute PDC202XX/VIA82CXXX for your chipset(s), of course. Also, devfs makes the scripts more sane if you wanna do hdparm things at bootup since you only see the devices you've actually got in the filesystem. If someday a Debian installation uses 2.4+ kernels only, Debian should be using devfs by default. Won't happen till then because Herbert Xu would sooner cut his wrists than apply a patch to Debian's kernels which was not required to make the thing compile and boot. -- Joseph Carter <[EMAIL PROTECTED]> You're entitled to my opinion unclean: err, the admin team do not control the archive, that's the ftp cabal get your cabals right, damn it :-P pgpoq0pf0qDY9.pgp Description: PGP signature
Re: Convenient way to enable IDE DMA
On Mon, 26 Aug 2002, Nate Eldredge wrote: > Thoughts? Propose a patch against the hdparm package?
Security notification script
I have written a python script that allows you to compares locally installed packages with those on security.debian.org. Furthermore it provides a description of the problem/DSA name if the package is mentioned in the DSA RDF. The script is intended to be run as a normal user in a crontab, and thus produces no output if the system is completely upto date. You will need to install python2.2 and python2.2-xml prior to using the script which can be found at http://www.robster.org.uk/files/security-update-check.py Any feedbacl/ideas would be much appreciated. I plan to make some minor changes and package this up later this week :) Cheers Rob -- Rob 'robster' Bradford Founder: http://www.debianplanet.org/ Developer: http://www.debian.org/ Monkey with keyboard: http://www.robster.org.uk/ signature.asc Description: This is a digitally signed message part
Re: Convenient way to enable IDE DMA
On 26 Aug 2002, Federico Di Gregorio wrote: > Il lun, 2002-08-26 alle 21:45, Nate Eldredge ha scritto: > > > As for hdparm, this is complicated with ide-scsi. For ide-scsi to work > > you have to make the ide-cd module ignore the scsi-ified drive. In which > > case /dev/hdc or whatever it is won't work until you have loaded the > > ide-scsi module, perhaps by touching /dev/scd0. So at least in my setup, > > further complications are needed. > > > > (Btw: a nice way to enable ide-scsi might be nice as well. CD burners are > > becoming very common.) > > hdc=ide-scsi as a boot param. but don't ask me where i found it, i don't > remember. Not sufficient for the kernel-image packages, since everything is a module. A couple extra lines are also needed in /etc/modules. Not a huge issue, but something a newbie might not know to do. -- Nate Eldredge HMC CS Staff [EMAIL PROTECTED]
Re: Convenient way to enable IDE DMA
On Mon, 26 Aug 2002, Nate Eldredge wrote: > On Mon, 26 Aug 2002, Nate Eldredge wrote: > > > The other question is how it should be enabled. One way is "hdparm -d 1 > > /dev/hd?" or moral equivalent in an init script. Another way appears to > > be "hda=dma ..." or "ide0=dma ..." on the kernel command line, though I > > haven't tested this yet. Apparently there are also CD-ROM drives for > > which it should not be enabled. > > Further info: "hda=dma" doesn't seem to exist, I was mistaken. "ide0=dma" > doesn't actually enable dma, for some reason. "ide0=autotune" doesn't > either. Grr. ... which is apparently because ide is a module in the 2.4.18 kernel image package. So in order to set it, it looks like I have to change it in the initrd filesystems and rebuild the image. Even more of a pain. -- Nate Eldredge HMC CS Staff [EMAIL PROTECTED]
Re: Convenient way to enable IDE DMA
Il lun, 2002-08-26 alle 21:45, Nate Eldredge ha scritto: > As for hdparm, this is complicated with ide-scsi. For ide-scsi to work > you have to make the ide-cd module ignore the scsi-ified drive. In which > case /dev/hdc or whatever it is won't work until you have loaded the > ide-scsi module, perhaps by touching /dev/scd0. So at least in my setup, > further complications are needed. > > (Btw: a nice way to enable ide-scsi might be nice as well. CD burners are > becoming very common.) hdc=ide-scsi as a boot param. but don't ask me where i found it, i don't remember. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra signature.asc Description: PGP signature
Re: Convenient way to enable IDE DMA
On Mon, 26 Aug 2002, Nate Eldredge wrote: > The other question is how it should be enabled. One way is "hdparm -d 1 > /dev/hd?" or moral equivalent in an init script. Another way appears to > be "hda=dma ..." or "ide0=dma ..." on the kernel command line, though I > haven't tested this yet. Apparently there are also CD-ROM drives for > which it should not be enabled. Further info: "hda=dma" doesn't seem to exist, I was mistaken. "ide0=dma" doesn't actually enable dma, for some reason. "ide0=autotune" doesn't either. Grr. As for hdparm, this is complicated with ide-scsi. For ide-scsi to work you have to make the ide-cd module ignore the scsi-ified drive. In which case /dev/hdc or whatever it is won't work until you have loaded the ide-scsi module, perhaps by touching /dev/scd0. So at least in my setup, further complications are needed. (Btw: a nice way to enable ide-scsi might be nice as well. CD burners are becoming very common.) -- Nate Eldredge HMC CS Staff [EMAIL PROTECTED]
Re: Preferred way to build shared objects from PIC archives?
On Sun, Aug 25, 2002 at 09:13:35PM -0400, Aaron M. Ucko wrote: > The shared libraries in ncbi-tools6 and related packages currently > start out as static archives of PIC objects, which then get turned > into shared libraries with commands of the form > > gcc -shared -Wl,-soname=libddvlib.so.6 -o libddvlib.so.6.1.20020426 \ > -Wl,-whole-archive libddvlib.a -Wl,-no-whole-archive > > This (admittedly roundabout) procedure works fine on i386, and has > worked on other platforms until now, but as of some time in the past > three months has started failing on arm with > > /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o): In function `__dummy': > __dummy.o(.text+0x0): multiple definition of `__dummy' > /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o)(.text+0x0): first > defined > here > > and a slew of similar messages. Is this a toolchain bug, or am I > going about things the wrong way? (Building the shared libraries > directly, while obviously preferable, would require too much tweaking > to the awkward upstream build system.) > > Please Cc me on replies, as I do not subscribe to -devel. No, that should work fine. I don't know what's broken... you may wish to try extracting all the objects via ar and relinking them; that should be pretty easy, but I'm not sure it will help. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: old ITP's
On Mon, Aug 26, 2002 at 03:05:35PM -0400, Clint Adams wrote: > > > #87667 gstreamerfiled: 546, changed 546 > > > > As an example, this package was uploaded to experimental on friday, > > and has been packaged upstream for about a year. It was last changed > > 62 days ago. > > Why experimental? Because it's not ready for unstable. gstreamer-plugins build-deps on 38 packages, at least 6 of which have constantly changing ABIs (and some, APIs). Because of this, it's not clear to me that it would ever have a chance of making it into testing without a lot of luck, and I'm making sure that the (non-DD) maintainer has the flexibility to drastically change the packaging if necessary. dave...
Convenient way to enable IDE DMA
I just noticed that IDE DMA is not enabled by default in woody, nor in the kernel-image package (at least for 2.4.18 and I assume for the others also). I can understand this, since there are some systems for which enabling IDE results in hideous corruption. But for others it gives you a a huge increase in disk performance (about a factor of 10 in my hdparm -t tests). So I think there should be a convenient and well-documented way to enable it. Perhaps a configuration option should be offered. The other question is how it should be enabled. One way is "hdparm -d 1 /dev/hd?" or moral equivalent in an init script. Another way appears to be "hda=dma ..." or "ide0=dma ..." on the kernel command line, though I haven't tested this yet. Apparently there are also CD-ROM drives for which it should not be enabled. I think this is important. DMA disabled has given me trouble with CD burning and video capture, and you should not have to be an expert to be able to turn it on. (I consider that expecting newbies to write an init script or look up kernel command line options is not really reasonable.) Also, it may give people the impression that Debian is "slow". Thoughts? -- Nate Eldredge HMC CS Staff [EMAIL PROTECTED]
Re: old ITP's
> > #87667 gstreamerfiled: 546, changed 546 > > As an example, this package was uploaded to experimental on friday, > and has been packaged upstream for about a year. It was last changed > 62 days ago. Why experimental?
Re: old ITP's
On Mon, 2002-08-26 at 19:30, Bas Zoetekouw wrote: > Hi! > > At te moment, there are a lot of old ITP's hanging around in the WNPP, Hi, When I was looking through the RFP list a while back, I noticed many of them were for packages that were not maintained upstream - sometimes they were still at the planning stage after a number of years; sometimes they had been abandoned (many napster clones); in other cases, upstream just seemed to be very amateurish with little sign of development (e.g. not using cvs; no mailing lists; seem to be only one developer; no documentation; latest 'news' on the site being from many months or years ago; poorly designed website). As I am not yet a developer, I did not try to close the RFP's. What action should be taken about such RFPs? -- +--+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.comtildemh.commh@ | +--+ signature.asc Description: This is a digitally signed message part
Re: old ITP's
Il lun, 2002-08-26 alle 20:30, Bas Zoetekouw ha scritto: > #68155 grassfiled: 1443, changed 1443 in Incoming by more than one month now. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] All programmers are optimists. -- Frederick P. Brooks, Jr. signature.asc Description: PGP signature
Re: old ITP's
On Mon, Aug 26, 2002 at 08:30:13PM +0200, Bas Zoetekouw wrote: > At te moment, there are a lot of old ITP's hanging around in the WNPP, > with (seemingly) nothing happening to them. In order to clean out the > WNPP, I intend to rename the ITP's that have been open longer than 1 year > to RFP's. This will affect approximately 200 ITP's. Why is this necessary? Keep in mind that a lot of ITPs are actually packaged and are either in experimental or an upstream repository, or upstream has requested that the packager hold off until the project stabilizes. In addition, wnpp keeps track of packages that cannot be packaged because of licensing issues, and the bug generally is a repository for reasons why it can't be packaged. Perhaps it would be wise to change these to "CBP - can't be packaged". > Below's a list of the bug tahtw will be renamed. The "filed" and > "changed" fields in the list are the number of days that have past since > the bug was opened, and since any addition was made to the report, > respectively. Your "changed" field appears to be incorrect for a large number of packages. > #87667 gstreamerfiled: 546, changed 546 As an example, this package was uploaded to experimental on friday, and has been packaged upstream for about a year. It was last changed 62 days ago. Please do not off-load the work of fixing up the problems caused by mass-changing wnpp bugs to others. I can't see how one can do this kind of task productively without hand sorting each bug. dave...
old ITP's
Hi! At te moment, there are a lot of old ITP's hanging around in the WNPP, with (seemingly) nothing happening to them. In order to clean out the WNPP, I intend to rename the ITP's that have been open longer than 1 year to RFP's. This will affect approximately 200 ITP's. The renaming will be done by sending an automated mail that explains the reason the bug is renamed. This message is Cc'ed to the person who opened the bug, to people who have retitled it, and to others who have commented on the bug (i.e. people who have sent mails to [EMAIL PROTECTED]). In order to make life easier for people who are still interesed in fullfilling their ITP, retitling the bug back to an ITP will be as easy as replying to this automated mail. Below's a list of the bug tahtw will be renamed. The "filed" and "changed" fields in the list are the number of days that have past since the bug was opened, and since any addition was made to the report, respectively. #68107 chordfiled: 1492, changed 1492 #68111 minfofiled: 1405, changed 1405 #68117 projex filed: 1317, changed 1317 #68122 squeak filed: 1392, changed 1392 #68132 nist's posix validation suitefiled: 1919, changed 1919 #68155 grassfiled: 1443, changed 1443 #68170 changesysfiled: 1745, changed 1745 #68171 wmx-4filed: 1233, changed 1233 #68181 ptl filed: 1393, changed 1393 #68192 pikt filed: 1363, changed 1363 #68223 tclhttpd filed: 1667, changed 1667 #68224 ears filed: 1394, changed 1394 #68226 gtk-module-gspeech filed: 1207, changed 1207 #68228 hyperbolefiled: 1919, changed 1919 #68243 linux phone filed: 1919, changed 1919 #68245 mupadfiled: 1919, changed 1919 #68256 tinymush filed: 1919, changed 1919 #68257 pclu filed: 1430, changed 1430 #68262 eli filed: 1611, changed 1611 #68264 v2html filed: 1546, changed 1546 #68269 kopi filed: 1166, changed 1166 #68272 perlindexfiled: 1639, changed 1639 #68276 socket-++filed: 1429, changed 1429 #68288 pikt filed: 1363, changed 1363 #68296 ncp filed: 1165, changed 1165 #68709 roundup filed: 748, changed 389 #69446 biomail filed: 736, changed 510 #69763 fbmuck filed: 733, changed 510 #69952 dict-de-it filed: 731, changed 632 #71657 ricochet filed: 711, changed 509 #72105 xfonts-silipafiled: 705, changed 705 #72775 liblv-ruby filed: 696, changed 696 #72776 libmhash-rubyfiled: 696, changed 696 #73036 siggen filed: 692, changed 509 #75038 jazz++ filed: 677, changed 677 #75078 imagej filed: 676, changed 676 #75400 bcastfiled: 672, changed 586 #75492 kcommander filed: 671, changed 671 #75672 ofbisfiled: 668, changed 668 #75673 zen filed: 668, changed 668 #76816 qtwvdialer filed: 652, changed 652 #77075 kvoctrainfiled: 649, changed 542 #77705 asc filed: 642, changed 586 #77944 libjtc filed: 639, changed 639 #77945 orbacus filed: 639, changed 639 #77982 libapache-mod-virgulefiled: 639, changed 639 #77983 xvl filed: 638, changed 638 #78204 smaugfiled: 636, changed 636 #78205 papaya filed: 636, changed 636 #78207 netshfiled: 636, changed 636 #78208 narval filed: 636, changed 636 #78209 broadcast2000filed: 636, changed 636 #78210 mpeg2movie filed: 636, changed 636 #78366 xmmp filed: 634, changed 509 #78687 big-sister filed: 630, changed 509 #78762 xmms-blursk filed: 630, changed 630 #78
BUSINESS RELATIONSHIP
CAPT. PAUL DIMANGO. TEL. 27 73 234 9108. FAX 27 72 486 3248. Dear Sir, URGENT INVESTMENT OFFER I know you will be surprise to receive this email from me, but please this letter is a request from someone in dare need of assistance. I Capt. PAUL DIMANGO from Angola, a personal aide to the late Jonas Savimbi of UNITA Angola who was ambushed and killed on Friday 22 of February 2002. I got your name and address from a business desk chamber of commerce and industry in Johannesburg South Africa. I decided to solicit for your business assistance to transfer the sum of US$26. 5 Million (Twenty Six Million Five Hundred Thousand United State Dollars only) from my Boss safe deposit into your personal or company's account. Before the death of Jonas Savimbi, I was in charge of overseeing his personal finances and the up keep of his family expenses. I have access to most of the money he starched away in a private security firm in South Africa. This was made possible because he entrusted me with the authority to use my name in depositing these funds, which he realized from the sales of Diamond in Angola. This is to avert any suspicion prior to when this money will be used for the purchase of Arms and Ammunitions. Before his death I received on his behalf a payment of US$26.5 Million (Twenty Six Million Five Hundred Thousand Unites State Dollars ) in cash, which I deposited in a vault of private security company here in Johannesburg, South Africa but I deposited the funds as Diplomatic Archival Antique? this I did for my security. I am now living in South Africa, as a political Asylum seeker because the situation in my country is not safe for me to go back as there is bound to be serious power tussle and the fate of UNITA the organization that my late Boss was the head before he was killed. I have made up my mind to divert this money and to make a living out of it, since my former boss and I are the only people who have the knowledge about this last payment. Regulatory law of South Africa does not permit asylum seeker certain financial rights. In view of this, I cannot invest this fund in South Africa hence I am seeking your assistance to move out this money out of South Africa to a foreign country for investment purpose which you are going to be the investment manager. For your assistance and effort, I am prepared to offer you 20% of the total fund while 5% will be set aside for any incidental expenses that will be incurred on the course of this transaction and also we are going to donate 5% to the Charity Organization in your country. Please note that this transaction is 100% risk free as I have made adequate arrangement with a bank Director here that will assist us in moving out the money through a Bank network. The major thing I demand from you is assuring me safety of this money when it finally gets to you. Further information and arrangement will commence as soon as trust; confidence and good working relationship is established between us. I shall be most grateful if you maintain the confidentiality of this matter. Please confirm your interest via above telephone and fax numbers. And your urgent reply will be highly appreciated. Best regards, CAPT. PAUL DIMANGO.
Re: First experience with gcc-3.2 recompiles
On Monday 26 August 2002 18:55, you wrote: > On Mon, 26 Aug 2002, Gerhard Tonn wrote: > > > apt: failed with "debian/rules:20: build/environment.mak: No such file > > > or directory" gg: failed with "/usr/bin/ld: cannot find -ljpeg" > > > hylafax: failed because textfmt wasn't built[1] > > > latte: failed with "Your STL string implementation is unusable." > > > nana: failed with "make: dh_testdir: Command not found" > > > qnix: failed with "make: execvp: ./configure: Permission denied" > > > > I am going to write bug reports for build problems that are not gcc 3.2 > > specific. > > Do be a bit careful, APT didn't build because you changed the package > (NMU version number) and didn't have autoconf/etc installed which are not > needed otherwise. > I have started to subcategorize the failed packages. The subdirectory gcc-3.2_specific contains the gcc-3.2 specific compile problems. The other failed packages are still under investigation. I will rebuild them with gcc-2.95 and without NMU versioning to verify the failure. Gerhard
Re: First experience with gcc-3.2 recompiles
On Mon, 26 Aug 2002, Gerhard Tonn wrote: > > apt: failed with "debian/rules:20: build/environment.mak: No such file or > > directory" gg: failed with "/usr/bin/ld: cannot find -ljpeg" > > hylafax: failed because textfmt wasn't built[1] > > latte: failed with "Your STL string implementation is unusable." > > nana: failed with "make: dh_testdir: Command not found" > > qnix: failed with "make: execvp: ./configure: Permission denied" > > > I am going to write bug reports for build problems that are not gcc 3.2 > specific. Do be a bit careful, APT didn't build because you changed the package (NMU version number) and didn't have autoconf/etc installed which are not needed otherwise. Jason
Re: RFC: OpenLDAP and TLS/SSL
On Mon, 2002-08-26 at 17:57, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Aug 2002, Luca Barbieri wrote:
> > Both problems can be solved by simply writing the version scripts so
> > that only a version tag is mentioned in each:
> > libpng2.ver:
> > LIBPNG_2.0 {global: png_*);
> >
> > libpng3.ver:
> > LIBPNG_3.0 {global: png_*);
> >
> > However, we'll still get a warning message if versioned binaries are
> > used with unversioned libraries.
>
> Not a problem. But, does this solves all the possible scenarios?
>
> Could you please write a wrap-up with all the scenarios (like Ultrich did),
> and mentioning how the proposed solution would act, and how the system acts
> now?
>
> We can then take this to the LSB, and see if we can all agree to do
> something that all distros will accept.
I did this in "A better solution for png/sasl/etc problems using
versioned symbols".
Is that enough? (the only significant flaw in that mail is that I forgot
to explicitly mention that only programs must link with libraries in the
/usr/lib/dev directory (that would be better named /usr/lib/novers)).
signature.asc
Description: This is a digitally signed message part
Sharp SPAM [marketing@sharpsystems.com: Special Price Offer for Select Sharp Systems Products]
It appears that Sharp Systems systematically spammed writers to the Debian-Laptop list, which certainly is an abuse of the debian lists. (they did not spam the list, so they don't directly violate the anti-spam rules of debian though) The spam arrived 12. Aug 2002. I was spammed shortly after posting there about LCD screens, and a few other posters confirmed my assumption that this resulted to that spam. The SPAM contained correct headers and was properly addressed, mailserver was gatekeeperil2.sharpsec.com, which is registered to sharp as well. It even refers to a probably correct Sharp Freecall number (although i do not live in the USA, so i can't call it) I did NOT request any information from Sharp, especially not about LCD screens (why should i buy an LCD screen in the States, where i have to pay shipment to Europe, when i've got a 1600x1200 LCD in my non-Sharp fine notebook?) It's a shame that a compaby i though once as a major player relies on such dodgy - and in many countries ILLEGAL - methods of annoying potential customers. Guess i'll drop them into my filter list, or wait for them to spam me again, then sue them. Greetings, Erich Well, i hope this public complaint and discredit, which most probably be kept in the archives on the net for a long time will make them stop doing such inpolite things and reconsider their marketing strategies... I also now decided that I won't spend my money on a "Sharp Zaurus". (I didn't really intend to buy any PDA anyway). - Forwarded message from Sharp Systems Marketing <[EMAIL PROTECTED]> - Organisation: Sharp Systems of America From: "Sharp Systems Marketing" <[EMAIL PROTECTED]> To: "Erich Schubert" <[EMAIL PROTECTED]> Subject: Special Price Offer for Select Sharp Systems Products Erich Schubert, Sharp Systems of America is offering its award-winning products at a special price to select customers and companies! Come to www.sharpsystems.com and look at our award winning line of notebook PCs and LCD monitors. >From now until September 30, 2002 you are entitled to receive a $100 rebate >when purchasing any of the following products from Sharp Place: Actius MV10W, >Actius UM30W or LL-T1820B LCD monitor. Simply order your product from www.sharpplace.com, and send a copy of this offer along with your on-line receipt from Sharp Place to: Sharp Systems, 5901 Bolsa Ave, Huntington Beach, CA 92647 For more info, check out our website, or call us at (800) BE-SHARP. *if you prefer not to receive mailings in the future, please send an email to [EMAIL PROTECTED] - End forwarded message - -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Ein Freund ist ein Geschenk, das man sich selbst macht. Humor sollte immmer dabeisein, auch bei Problemen.
shouldn't root.adm , -rw-r----- , be policy for all non-public log files?
Hi, I maintain the Lire package, which processes log files from e.g. sendmail, bind, apache, boa and lots of other services. I don't want to run any Lire processes as root. However, of course, the processes need read access to log files. Unfortunately, there seems to be no rule or policy on how access permissions for log files should be. Wouldn't it be nice if all non-public log files were owned by group `adm', and groupreadable? (World readability for public log files is fine too, of course.) Currently, this is the case for quite a lot of commonly found log files. (A short investigation shows some exceptions: in order to read exim's logs, one needs to be in the `mail' group. For squid this is the `proxy' group.) I've reread the "exploring debian's users and groups" discussion on http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg00272.html , although similar issues were raised, no conclusion seems to have been reached on this specific subject (other than "adm is to read logs".) See also http://bugs.debian.org/153812 . In the current situation, I can't automatically configure my package to get readaccess for all supported logs, without running it as root :( Bye, Joost -- . . http://mdcc.cx/ Joost van Baal. . . . . .http://logreport.org/ pgpeJ0XhJeRTb.pgp Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Thu, 22 Aug 2002, Luca Barbieri wrote:
> Both problems can be solved by simply writing the version scripts so
> that only a version tag is mentioned in each:
> libpng2.ver:
> LIBPNG_2.0 {global: png_*);
>
> libpng3.ver:
> LIBPNG_3.0 {global: png_*);
>
> However, we'll still get a warning message if versioned binaries are
> used with unversioned libraries.
Not a problem. But, does this solves all the possible scenarios?
Could you please write a wrap-up with all the scenarios (like Ultrich did),
and mentioning how the proposed solution would act, and how the system acts
now?
We can then take this to the LSB, and see if we can all agree to do
something that all distros will accept.
> BTW, libraries that use one the conflicting ones must be compiled with
> -fPIC, but that should already happen.
Yes. It is unacceptable not to do so, because that would break completely in
some archs. Libraries are to be compiled with -fPIC and that's all.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: RFC: OpenLDAP and TLS/SSL
On Thu, 22 Aug 2002, Luca Barbieri wrote: > On Thu, 2002-08-22 at 00:11, Henrique de Moraes Holschuh wrote: > > On Wed, 21 Aug 2002, Luca Barbieri wrote: > Otherwise, if more then one version of the symbol is > available, none of the definitions is accepted and the search > continues with the next object. > > If we modify the loader so that it instead accepts the first one, this > first one will be correct for the main program. Hmm, what drawbacks would such a change have? If there are none... > With unmodified loaders and multiple versioned libraries in a program, > the binaries will fail until they are recompiled to use versioned > symbols. However this isn't worse than the current situation that causes > them to pseudorandomly fail. Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
> * kaffe and other GPL-licensed JVMs can only be used with GPL compatible > software (i.e. no Apache style licenses!). See > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > Not to mention that kaffe's classlib is GPL [1] What exactly do you mean by this? The interpreter can be GPL, but the software that the interpreted program links against cannot. Obviously this includes the software provided by the class library. I'm not sure if this includes software provided by the JVM. It's also not clear to me what the difference is between compiling some java code against a set of interfaces (whether they are actual java interfaces, or just some java classes), and then running your program with a GPL'ed implementation of said interfaces. Are you violating the GPL in the first or second instance? John Leuner
Re: How to get rid of non-free packers?
On Sat, 24 Aug 2002, +05:00:59 EEST (UTC +0300), Brian May <[EMAIL PROTECTED]> pressed some keys: > On Fri, Aug 23, 2002 at 04:01:15PM +0300, Juhapekka Tolvanen wrote: > > It is not very bad thing if we can't create archives in formats like > > ACE, ARJ, LHA or RAR with free software. But it is more important to > Ideally, amavis needs access for all archive formats so it can check > for viruses in E-Mail... You mean it must be able to UNpack those packed files attached to E-Mail? > > P.S: I don't subscribe to mailing-lists of Debian, so please Cc: your > > replies to me. And I am not Debian developer. > > Please set your Mail-Followup-To: header correctly in future, that > way mutt will automatically do the right thing. Thanks. I did not know about that. I already know, how to use Followup-To: -header in Usenet News. -- Juhapekka "naula" Tolvanen * * University of Jyväskylä * * [EMAIL PROTECTED] http://www.cc.jyu.fi/~juhtolv/index.html * * * * "STRAIGHT BUT NOT NARROW!!" "Vesi hakkaa minua maahan, kuin tuhat lekaa ja miljoona vasaraa. Niinkuin lauletaan, niin happi räjähtää ja kauniista kaunein kädet ojentaa." Apulanta
域名注册，主机申请，网站建设
域名注册主机申请网站建设一条龙为您服务 中国服务全球专业的域名注册提供商，现推出主机、域名注册优惠服务： “特惠1+1企业上网套餐”是中国服务器网络有限公司为您推出的超值服务， “先服务，后收费！”内容包括： 30M asp cgi,php +ACCESS 数据库,送国际顶级域名一个 250元/年 100M asp cgi,php +ACCESS 数据库,送国际顶级域名一个，只需 350元/年 200N asp cgi,php +ACCESS 数据库,送国际顶级域名一个,只需 600元/年 特惠1+1上网套餐是企业上网，企业商务化的理想选择，现正火爆选购中 快速度申请(请点击）： http://www.cnserver.com/webmaster/eje-form.htm 欢迎访问我司网站进一步了解：http://www.cnserver.net http://www.cnserver.com http://www.linemail.net 联系电话:0592-2516932 QQ:93767793
域名注册，主机申请，网站建设
域名注册主机申请网站建设一条龙为您服务 中国服务全球专业的域名注册提供商，现推出主机、域名注册优惠服务： “特惠1+1企业上网套餐”是中国服务器网络有限公司为您推出的超值服务， “先服务，后收费！”内容包括： 30M asp cgi,php +ACCESS 数据库,送国际顶级域名一个 250元/年 100M asp cgi,php +ACCESS 数据库,送国际顶级域名一个，只需 350元/年 200N asp cgi,php +ACCESS 数据库,送国际顶级域名一个,只需 600元/年 特惠1+1上网套餐是企业上网，企业商务化的理想选择，现正火爆选购中 快速度申请(请点击）： http://www.cnserver.com/webmaster/eje-form.htm 欢迎访问我司网站进一步了解：http://www.cnserver.net http://www.cnserver.com http://www.linemail.net 联系电话:0592-2516932 QQ:93767793
Re: How to get rid of non-free packers?
On Fri, 23 Aug 2002, +21:51:59 EEST (UTC +0300), Juhapekka Tolvanen <[EMAIL PROTECTED]> pressed some keys: > On Fri, 23 Aug 2002, +16:01:15 EEST (UTC +0300), > Juhapekka Tolvanen <[EMAIL PROTECTED]> pressed some keys: > Docs about format of LHA or LZH is here: > > http://www.osirusoft.com/joejared/lzhformat.html As you can see, that Joe Jared is creating some LHA-software. http://www.osirusoft.com/joejared/ http://www.osirusoft.com/joejared/lh7online.html But their licences are not very DFSG-compliant. Who could pressure him gently to change licence? -- Juhapekka "naula" Tolvanen * * University of Jyväskylä * * [EMAIL PROTECTED] http://www.cc.jyu.fi/~juhtolv/index.html * * * * "STRAIGHT BUT NOT NARROW!!" "Vesi hakkaa minua maahan, kuin tuhat lekaa ja miljoona vasaraa. Niinkuin lauletaan, niin happi räjähtää ja kauniista kaunein kädet ojentaa." Apulanta
Re: Bug#158059: ITP: metacity-themes -- Themes for the Gtk2 metacity window manager
On Sun, 2002-08-25 at 20:18, Colin Walters wrote: > On Sat, 2002-08-24 at 14:37, Mark Howard wrote: > > > Initial packages for this are available at > > http://tildemh.com/tmp/metacity-themes/ > > Hmmwhere's the source package? http://tildemh.com/tmp/debian/ As this collection is not available anywhere, I have generated the metacity-themes source tarball myself, using the debian/build-orig-source script. This simply takes a metacity-themes directory containing a number of tarballs of individual themes from various upstream locations and generates a single source tarball. The build scripts then unpack each tarball to the correct location. Currently, any discrepancies in the source tarball are all handled manually - removing duplicate licenses from the /usr/share/themes/theme-name/metacity-1, for example (by manually, I mean manually adding a line to the build process to deal with it). Also, the copyright and README files are all handled manually at present. I am now considering writing a perl script to handle the data a little better. This would involve storing all the details of each theme in a table and automatically generating documentation, most probably to be placed in /usr/share/doc/metacity-themes/theme-name/. This would then also scan the theme directories (as created by the upstream tarballs) for documentation and move them to these directories. -- +--+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.comtildemh.commh@ | +--+ -- +--+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.comtildemh.commh@ | +--+ signature.asc Description: This is a digitally signed message part
Re: perl 5.6 dependent packages
On Mon, Aug 26, 2002 at 05:57:50PM +1000, Brendan O'Dea wrote: > > If those package are still going to be shipped separately (because > > they're going to evolve outside the perl core), then they should stay > > in the archive and perl must add Provides for them. Hence, the user > > can still choose to use either those in the perl core, or the > > sperate ones (maybe more recent at some point). > > You're missing the point. No, I added some information. > The problem is that some packages have *versioned* dependencies on those > packages: "smokeping" for example depends on "libdigest-md5-perl (>= 2.13-2)". > > While perl does have a provide for "libdigest-md5-perl", it's not > considered as there is no version associated. So the dependencies on that > (and other packages) need to be changed. I didn't say it doesn't have to be changed. > As far as retaining the stand-alone versions of [now] uninstallable perl > modules in the archive goes, is there any point? They can be re-packaged > if/when the need arises. It depends on the will of the maintainers of those packages. Those modules are likely to have newer versions in the upcoming months, maybe users will be interested in newer versions? Cheers, -- Jérôme Marant
gim, a possible gpm replacement
I am posting this here because mail to the current Debian maintainer of gpm, Zephaniah E. Hull, bounces. gim can already serve fine as a "repeater" (pointer device for X) itz> A sneak preview of gim is available at itz> http://www.speakeasy.net/~itz/hacks/gim-0.9.1.tar.gz itz> gim is a replacement for gpm, the classic linux mouse itz> multiplexor. Unlike gpm, it doesn't speak the native protocols itz> of mice; instead, it uses gii (the General Graphics Interface itz> input library) to get mouse input. Thus, gii is a prerequisite itz> for gim. itz> I consider the code in this snapshot complete, except for itz> bugfixes. Testing is appreciated. One thing that needs to be itz> completed before a public release is documentation. I know about itz> that and will be working on it. Now up to 0.9.2, in the same place. The addition is a simple C++ interface for clients (in the libgim subdirectory of the distribution). Docs are still missing... -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
Bug#158320: ITP: cl-defsystem3 -- A system definition and building package for Common Lisp programs
Package: wnpp
Version: N/A; reported 2002-08-26
Severity: wishlist
* Package name: cl-defsystem3
Version : 3.3ii
Upstream Author : Mark Kantrowitz and Marco Antoniotti
* URL : http://sourceforge.net/projects/clocc
* License : DFSG compatible
Description : A system definition and building package for Common Lisp
programs
defsystem is a "make"-like tool for building Common Lisp
systems. Defsystem3 is currently part of the Debian package Common
Lisp Controller. However, in discussions with the Defsystem3's and
Common Lisp Controller's maintainers, there is an advantage for
packaging this separately. After this package has been accepted into
the Debian distribution, Common Lisp Controller will remove defsystem
code and depend upon this package.
I'm not exactly sure of the category of the license. I believe it to
be DFSG compatible:
;;; Use, copying, modification, merging, publishing, distribution
;;; and/or sale of this software, source and/or binary files and
;;; associated documentation files (the "Software") and of derivative
;;; works based upon this Software are permitted, as long as the
;;; following conditions are met:
;;; o this copyright notice is included intact and is prominently
;;;visible in the Software
;;; o distribution of a modification to the Software have been
;;;previously submitted to the maintainers; if the maintainers
;;;decide not to include the submitted changes, the "full
;;;name" of the re-distributed Software ("MK:DEFSYSTEM", or
;;;"MAKE:DEFSYSTEM", or "MK-DEFSYSTEM") must be changed.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux tiger 2.4.19 #1 SMP Sat Aug 3 10:05:27 MDT 2002 i686
Locale: LANG=C, LC_CTYPE=C
G'Day from Australia
Hello, We understand you are interested in "genuine" home-based businesses that offer security and peace of mind, as well as an excellent income. If this is the case, we sincerely believe we may have just what you are looking for ... superb incomes from low risk, financially sound companies backed by stable management. Be assured, this is NOT a scam. It is a genuine opportunity that has been fully researched. You will find full details on our web page at: http://x-elle.com (Please note, we have taken particular care to ensure this email is sent to only those who are interested in home-based businesses (or working from home). Despite our efforts, there are always exceptions and you might have received this in error. If this is the case, please accept our sincere apologies. This is a once-off mailing and you will not hear from us again. Thanks.) Kind regards, Pieter and Pam (Living the Dream in sunny Australia !)
Hello!!!
ENGR.GEORGE MBA. DIRECTOR, MINERALS & NATURAL RESOURCES, SOUTH AFRICAN MINISTRY OF MINING & MINERAL RESOURCES, (SMMR) PRETORIA, REPUBLIC OF SOUTH AFRICA Sir, It is my pleasure to write you this letter on behalf of my colleagues. I have decided to seek a confidential co-operation with you in executing of a deal hereunder for the benefit of all parties, and hope you will keep it confidential because of the nature of this business. I am the Director of Mineral and Natural Resources of the South African Ministry of Mining and Mineral Resources (SMMR) and I have the co-operation of two other top officials, we have in our possession an overdue payment in US funds. The funds represent some percentage of the contract executed on behalf of my ministry by a foreign firm, which we over-invoiced to the amount of US$15,500,000.00 (Fifteen Million Five Hundred Thousand United States Dollars.) Though the actual contract cost has been paid to the original contractor, leaving the excess balance unclaimed. Since the present Government is determined to pay foreign contractors all debts owed, so as to maintain good relationship with other governments. As a result we include our bills for approvals with the co-operation of some officials at the Federal Ministry of Finance. We are seeking your assistance as the Beneficiary of the unclaimed funds, since we are not allowed to operate a foreign account. We hereby propose that, should you be willing to assist us in this transaction your share as compensation will be 30% while my colleagues and I receive 60% and 10% for miscellaneous expenses. This business itself is 100% safe, provided you treat it with utmost confidentiality. I have reposed my confidence in you and hope that you will not disappoint us. Kindly notify me by Email for further details, upon your acceptance of this proposal. Best Regards, Engr. George Mba
Re: perl 5.6 dependent packages
On Mon, Aug 26, 2002 at 09:33:51AM +0200, Jérôme Marant wrote: >On Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea wrote: >> Note that in addition, since perl 5.8.0 includes some modules which were >> previously stand-alone, any package declaring a versioned[0] dependency >> on: >> >> libdigest-md5-perl, libmime-base64-perl, libnet-perl, >> libtime-hires-perl, libstorable-perl, >> libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl, >> liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, >> libtest-harness-perl, libtest-simple-perl >> >> needs to either have the version for that dependency removed, or just to >> depend on perl (>= 5.8.0). > > If those package are still going to be shipped separately (because > they're going to evolve outside the perl core), then they should stay > in the archive and perl must add Provides for them. Hence, the user > can still choose to use either those in the perl core, or the > sperate ones (maybe more recent at some point). You're missing the point. The problem is that some packages have *versioned* dependencies on those packages: "smokeping" for example depends on "libdigest-md5-perl (>= 2.13-2)". While perl does have a provide for "libdigest-md5-perl", it's not considered as there is no version associated. So the dependencies on that (and other packages) need to be changed. As far as retaining the stand-alone versions of [now] uninstallable perl modules in the archive goes, is there any point? They can be re-packaged if/when the need arises. --bod
Re: perl 5.6 dependent packages
On Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea wrote: > On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote: > >perl 5.8 will enter unstable at the next dinstall run. Before it can > >make testing though, we have to update the following 84 packages which > >still depend on perlapi-5.6.*. This list should take into account those > >packages that were already NMU'd. > > > >[EMAIL PROTECTED]:~>grep-available -F depends perlapi-5.6 -s package > > Note that in addition, since perl 5.8.0 includes some modules which were > previously stand-alone, any package declaring a versioned[0] dependency > on: > > libdigest-md5-perl, libmime-base64-perl, libnet-perl, > libtime-hires-perl, libstorable-perl, > libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl, > liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, > libtest-harness-perl, libtest-simple-perl > > needs to either have the version for that dependency removed, or just to > depend on perl (>= 5.8.0). If those package are still going to be shipped separately (because they're going to evolve outside the perl core), then they should stay in the archive and perl must add Provides for them. Hence, the user can still choose to use either those in the perl core, or the sperate ones (maybe more recent at some point). -- Jérôme Marant
Re: How to get rid of non-free packers?
Hi, On Mon, Aug 26, 2002 at 09:33:40AM +0900, GOTO Masanori wrote: > At Fri, 23 Aug 2002 16:01:15 +0300, > Juhapekka Tolvanen wrote: > >It's free to distribute on the network, but if you distribute for > >the people who cannot access the network (by magazine or CD-ROM), > >please send E-Mail (Inter-Net address) to the author before the > >distribution. That's well where this software is appeared. > >If you cannot do, you must send me the E-Mail later. > > > > Original Source Code License Statement: > > > >/*Copyright (C) MCMLXXXIX Yooichi.Tagawa */ > >/*ModifiedNobutaka Watazaki */ > >/* Thanks to H.Yoshizaki. (MS-DOS LHarc)*/ > > > > Clip here Masanori, I do not know where you got this but this is memo by Tsugio. Manual page seems to me the thorough license from the original authors. Please consider the following for copyright section. Many restrictions for commercial use of modified code. Permission is given for redistribution, copy, and modification provided following conditions are met. 1. Do not remove copyright clause. 2. Distribution shall conform: a. The content of redistribution (i.e., source code, documentation, and reference guide for programmers) shall include original contents. If contents are modified, the document clearly indicating the fact of modification must be included. b. If LHa is redistributed with added values, you must put your best effort to include them (Translator comment: If read literally, original Japanese was unclear what "them" means here. But undoubtedly this "them" means source code for the added value portion and this is a typical Japanese sloppy writing style to abbreviate as such) Also the document clearly indicating that added value was added must be included. c. Binary only distribution is not allowed (including added value ones.) 3. You need to put effort to distribute the latest version (This is not your duty). NB: Distribution on Internet is free. Please notify me by e-mail or other means prior to the distribution if distribution is done through non-Internet media (Magazine, CDROM etc.) If not, make sure to Email me later. 4. Any damage caused by the existence and use of this program will not be compensated. 5. Author will not be responsible to correct errors even if program is defective. 6. This program, either as a part of this or as a whole of this, may be included into other programs. In this case, that program is not LHa and can not call itself LHa. 7. For commercial use, in addition to above conditions, following condition needs to be met. a. The program whose content is mainly this program can not be used commercially. b. If the recipient of commercial use deems inappropriate as a program user, you must not distribute. c. If used as a method for the installation, you must not force others to use this program. In this case, commercial user will perform its work while taking full responsibility of its outcome d. If added value is done under the commercial use by using this program, commercial user shall provide its support. Boy, this license did not make much sense even in Japanese. It get worse with my English. (Maybe this was so bad Masanori may have skipped translating this one.) Here "commercial" may be interpreted as "for-fee". "Added value" seems to mean "feature enhancement". > > > > I think, only way to get free unpacking software for LHA-files is to > > negotiate with those Japanese persons. Here are some URL of Japanese > > LHA-software: > > > > http://shibuya.cool.ne.jp/lha/ > > I think it can be replaceable with below Tsugio's source. > > > http://www2m.biglobe.ne.jp/~dolphin/lha/lha.htm > > Debian package uses his (Tsugio's) source. It also can handle -lh7- > format. I already contacted with him, but his response were too slow > (waited over 4 months, or more!), and he thought changing license was > very difficult. LHa for unix was hacked by many people at least over > 13 years, they have treated their license as "vague". Historical > reason makes difficult to change their license. It looks like Arai-san [EMAIL PROTECTED] seems to be most active. http://ns103.net/~arai is his URL He has new autoconf version. It looks to me people are treating almost like public domain as long as New sources are available to general public. Anyway, there is good amount of file format conventions written in Tsugio's page. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki @ Cupertino CA USA, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://www.debian.org/doc/manuals/reference/ also http://qref.sf.net `. `' "Our Priorities are Our Users and Free Software" --- Soci
Re: First experience with gcc-3.2 recompiles
On Sunday 25 August 2002 22:00, you wrote: > > > The build logs of the packages can be found at > > http://people.debian.org/~gt/gcc-3.2_transition > > I hate to say, but the list of failed packages needs to get > investigated a little bit, since not all failures seem to be GCC 3.2 > and syntax related: > > > apt: failed with "debian/rules:20: build/environment.mak: No such file or > directory" gg: failed with "/usr/bin/ld: cannot find -ljpeg" > hylafax: failed because textfmt wasn't built[1] > latte: failed with "Your STL string implementation is unusable." > nana: failed with "make: dh_testdir: Command not found" > qnix: failed with "make: execvp: ./configure: Permission denied" > I am going to write bug reports for build problems that are not gcc 3.2 specific. Gerhard
Re: trustworthy, seasoned developer, and Swedish
On Fri, Aug 02, 2002 at 08:59:47AM +0200, martin f krafft wrote: > anyone of you with fulfilling the subject's three requirements? i've > been contacted about donations for debian in sweden, and if you would > be able to, it would be great if you could proxy those. Hi I forgot to reply to this mail. I think I can proxy this if you tell me how to do that. > or does anyone have better suggestions on how to handle swedish > donations? But according to the thread it might be better ways. I just wanted to tell that I can handle this, maybe. Regards, // Ola > > -- > martin; (greetings from the heart of the sun.) > \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] > > "all language designers are arrogant. goes with the territory..." > -- larry wall -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: MAKEDEV Replacement status
I'm still waiting for bdale to find time to look at the code I've released so far. I would like to know whether he likes the direction it's headed, before continuing.. On Sat, Aug 24, 2002 at 04:36:07PM -0400, Don Armstrong wrote: > > I was just about to file a wishlist against makedev to get support for > dpti0 .. dptiX (adaptec i2o raid cards) added to MAKEDEV, but remembered that > there had been some talk in July about it's replacement.[1] > > Could Andreas Salmon, Bdale Garbee, and Sean Perry comment on the > status of a replacement MAKEDEV if one is in the works? [Or point me > to relevant documentation?] > > If not, I'll just file a bug w/ patch. > > > Don Armstrong > > 1: > http://lists.debian.org/debian-devel/2002/debian-devel-200207/threads.html#00270 > > -- > Always try to do things in chronological order. > It's less confusing that way. > > http://www.donarmstrong.com > http://www.anylevel.com > http://rzlab.ucr.edu -- Broad surveillance is a mark of bad security. -- Bruce Schneier
Re: Menu system rewrite update (Aug 6 2002)
On Fri, 23 Aug 2002, Thimo Neubauer wrote: > Sorry to interrupt your speculations about a gnuplot menu-entry but > it's been in the package for ages (about 1997)... Yes, opening a xterm > with the gnuplot commandline inside is a bit strange but nobody ever > complained and at least it can be found that way. > > IMHO the menu is more a way of showing the user which programs are > installed on the machine, thus the entry makes (at least a bit of) > sense. This meets exactly what I would expect about a menu entry for this kind of programs. (Perhaps I should check the facts before doing wild guesses - sorry.) Kind regards Andreas.
Re: apt-get wants to upgrade package to same version?
On Fri, Aug 23, 2002 at 07:12:28PM +0200, Ludovic Rousseau wrote: > Try to reorder your sources.list file. So another words, it is not sufficient to simply disable an apt-get source line by giving it a priority of -1, I must also delete that line from sources.list too? (as normally this entry is my first preference). I suspect this is a more general problem with apt-get that it assumes that if two versions of the same package are available from different sources, then both packages will be exactly the same. As such, it will always use the Packages entry from the first Packages file it finds, because it assumes the other entries will be the same anyway. Maybe apt should really provide a warning if it finds this assumption is incorrect? -- Brian May <[EMAIL PROTECTED]>
