Re: nice demolition job ... epilog

[Debian Linux User]

On Wed, Sep 13, 2000 at 10:54:32PM -0300, Nicolás Lichtmaier wrote:
> >  Purpose of Rant: Stir up the coals ...
> 
>  Have you already put some meat?
> 
Yes, but unfortunately it was all devoured immediately by ravenous wolves. 
Barely raw as well... and apparently there was some indigestion thereafter.
Pity.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: KDE2 - nice demolition job ...

[John Galt]

I thought the netbase breakup was because of a old-BSD/GPL license
incompatibility...

On Wed, 13 Sep 2000, Joey Hess wrote:

> John Galt wrote:
> > The big package breakups have historically been related to licensing
> > issues
> 
> Not as far as I can remember. The X breakup and the netbase breakup, for
> instance, had nothing to do with licenses that I know of.
> 
> 

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel BUG [Was: Re: rm and ls don't work for large files]

[Jason Hansen]

On Tue, Aug 29, 2000 at 08:39:33AM +0200, Paul Slootman wrote:
> On Mon 28 Aug 2000, Nils Rennebarth wrote:
> > On Mon, Aug 28, 2000 at 02:52:01PM +0200, Paul Slootman wrote:
> 
> > > The problem here, as I mentioned in an earlier reply before this got
> > > crossposted to l-k, is that "our" version of libc is the one released
> > > with debian 2.2 potato, i.e. one that's intended for use with 2.2
> > > kernels. AFAIK 2.2 kernels don't have any lstat64.
> 
> > Ok, but someone will want to use larger files, be it with a patch to 2.2 or
> > with a 2.4 kernel. Do we need to release a special libc version for those?
> 
> Good question :-)  I have no idea. I would hope that the latest
> glibc checks whether lstat64 & friends are available, and if not,
> falls back to the 32-bit versions. Maybe someone who's intimate
> with the glibc details can enlighten us?
> 
> [ more good questions snipped ]
> 

I've been trying to get LFS to work with 2.2.16. And so far, I've had no
luck. I've used the patches against 2.2.16, found at
ftp://ftp.scyld.com/pub/lfs/lfs-1.2.0.tar.gz which applied cleanly.

After building the kernel, and a reboot. I recompiled the libc6 (2.1.3-13)
deb with LINUX_SOURCE set to the location of the patched kernel tree. After
installing the fresh .deb's and another reboot, I attempted to recompile
fileutils (4.0l-8)... However, fileutils configure script does not detect
'large file support.' The relevant lines from the configure script output
follow:

checking for _FILE_OFFSET_BITS... 64
checking for _LARGEFILE_SOURCE... no
checking for _LARGE_FILES... no

Does anyone have LFS working on a potato installation?

-- 
--
Jason Hansen  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: KDE2 - nice demolition job ...

[Joey Hess]

John Galt wrote:
> The big package breakups have historically been related to licensing
> issues

Not as far as I can remember. The X breakup and the netbase breakup, for
instance, had nothing to do with licenses that I know of.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: KDE2 - nice demolition job ...

[Nicolás Lichtmaier]

>  Purpose of Rant: Stir up the coals ...

 Have you already put some meat?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-get and proxy

[Jason Gunthorpe]

On Wed, 13 Sep 2000, Andreas Tille wrote:

> When I wrote, that the proxy variables were ignored just my description
> was wrong.  May be they are used but they are used in an other way
> than if I use settings in /etc/apt/apt.conf.  While trying several different
> proxy-settings (sorry, don't remember) there, I got explicitely the
> message that the proxy is contacted.  Using just the environment

Nope, they are 100% identical. The only way it could not work is if you
were not actually exporting the variable, or were typing something wrong.

> the time is always the same when updating package list (also doing this
> several times on the same box - at least this could be cached even
> without using a proxy - is this worth a wishlist-bug?) or when obtaining

It is cached - only environmental problems can defeat the cache - these
invariably boil down to defective servers, transparent proxies, or
*something* like that.

Jason



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-get and proxy

[Jason Gunthorpe]

On Wed, 13 Sep 2000, Andreas Tille wrote:

> >From /var/lib/dpkg/available:
> Package: makedev:
> ...
> MD5sum: 7f6b97b984c246ead2c7be45ce4f1678
> 
> /var/cache/apt/archives/partial> md5sum makedev_2.3.1-46_all.deb
> 7f6b97b984c246ead2c7be45ce4f1678  makedev_2.3.1-46_all.deb

Please use apt-cache show makedev rather than the available file, and
verify the version numbers too. 

Are you certain there is not a problem with your CPU/Memory that could
cause this?

See, the only time bytes are added to the hash is when they are written to
the file, so.. Well, what you are describing is impossible :> I'd like to
see strace -o /tmp/foo -f -ff's -s200 and script logs of an apt-get doing
this. 

I did lots of testing of apt-get and most squids and never once
encountered an MD5 error.
 
> Well but some of my boxes don't use NFS and those using NFS have trouble
> with tke lock file.  At least I had when I tried.  Any example for 
> /etc/exports and /etc/fstab which handle this right?

You need kernel NFS server for locking.

Jason


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: fix for daemon start (2)

[Henrique M Holschuh]

On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:
> I like it, but why not fold this functionality in update-rc.d itself?
> update-rc.d --query ? And why not define update-rc.d --list as well..

Well, for starters I don't grok perl, and I wasn't about to let that little
detail stop me from writing the sample code :-)

Also, update-rc.d and initscriptquery don't share much in the way of common
code, I think. I don't see any major advantages in merging the two, not to 
mention that it would generate a new interface for update-rc.d...

By keeping the two scripts separate, we avoid increasing the complexity of
update-rc.d and we also keep the two interfaces independent of each other.

-- 
  "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


pgpkHs9pOdebR.pgp
Description: PGP signature

Re: determining if we're using db.h from libc6 or libdb2?

[Domenico Andreoli]

On Wed, Sep 13, 2000 at 02:38:07PM -0700, Darren/Torin/Who Ever... wrote:
> Domenico Andreoli, in an immanent manifestation of deity, wrote:
> >i don't know how much what i'm going to say would be of help, but if you 
> >added
> >a new check in configure.in in order to let your source know what kind of 
> >db.h
> >you have? you could be pretty sure that your sources are getting compiled the
> >right way.
> 
> Well, I'd need to know how to detect it.  I'm assuming that this isn't a
> bundled module with configure.  I can't just detect for db2.4 since that
> just happens to be the version included in glibc2.[01].  The user might
> just have that version installed.
> 
of course you cannot test version numbers only. yes, version could help to
choose whether or not the test is needed. you know that below a certain
version you are speaking of db2 in glibc2 and above you are speaking of db2
out of glibc2. between these versions you have ambiguity and test is needed.
what to do in this test i'm not able to tell you.

> I suppose that I could have configure write a C program that included
>  and linked with -ldb.  If it failed, try including  and
> if that worked, then I've isolated the problem in configure.
> 
i suppose you should care what the linker is linking your test code at too, but
you already know this.

i have a printed manual of autoconf i've never read too much. it seems not to be
a great pain write new tests, but for sure it is neither *that* easy. i never 
did
such a thing before.

IMHO, your problem your problem is best solved by autoconf.

btw, if i'm not wrong, these changes in glibc2 affects many other developers.
maybe in autoconf's upstream level they will write this test. maybe.

i'm sorry i cannot help you more :((

cheers

ps: and if you check for something like __DB_H__ after the header that in older
glibc2 would have included it? if this symbol is not defined, it means that you
are talking about a glibc2 without db2. so you know where to look for it.
! since i don't know which relation exists between glibc2 headers and
db2 ones, i could be completely wrong. :(

just an idea to make simpler the test for autoconf. something like:

#include 

int main()
{
#ifdef __DB_H__
  return 0;
#elif
  return 1;
#endif
}

checking the return of this test you should know what kind of db.h you have and
you don't even care about which library to link it at! this code should work
without any db2 library linked, since it doesn't reference any external symbol.
hmm, i'm not so sure of this last words... i'm not a great developer.

but once you know who db.h is, you know which db2 shared library you need.

... more 2 cents... :)

-[ Domenico Andreoli, aka cavok
  --[ get my public gpg key at http://www.freeweb.org/free/cavok/gpgkey.asc
 -[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


pgp6wl1OMhNtk.pgp
Description: PGP signature

Re: mp3 encoding patents.

[Bart Schuller]

On Wed, Sep 13, 2000 at 12:57:10PM -0700, Sean 'Shaleh' Perry wrote:
> On 13-Sep-2000 [EMAIL PROTECTED] wrote:
> > Sorry to bring up this subject again.
> > I just wanted to know that can't mp3 encoders be distributed from a non-us
> > site where the policies are much more relaxed ?
> > 
> the patents are held in Germany.  This restricts us because most countries in
> Europe accept them.

We would have a mirroring problem in any case, but that would still not
rule out hosting them in (and for) countries that don't allow these
kinds of patents.

Speaking for the Netherlands: you can't patent maths/software here.
European patents are also not automatically valid here, you still have
to apply for the patent. However, there's a fast track for european
patents, so the application could just be a formality. What happens if
such a formality clashes with the local laws is an interesting question.

Searching the Dutch patent database, I couldn't find the relevant
patents, but that might be because I don't know which are the relevant
patents. Anyone have some numbers?

http://nl.espacenet.com/ for Dutch patents, replace the nl with a
different country code if you're interested.

Oh, and of course IANAL.

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Webmin: we're almost there

[Jaldhar H. Vyas]

Of course the moment I decided to upload 0.80 they released 0.81.  Luckily
most of the modifications survived intact.  I'm just fixing up a few
little things.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: determining if we're using db.h from libc6 or libdb2?

[Darren/Torin/Who Ever...]

Domenico Andreoli, in an immanent manifestation of deity, wrote:
>i don't know how much what i'm going to say would be of help, but if you added
>a new check in configure.in in order to let your source know what kind of db.h
>you have? you could be pretty sure that your sources are getting compiled the
>right way.

Well, I'd need to know how to detect it.  I'm assuming that this isn't a
bundled module with configure.  I can't just detect for db2.4 since that
just happens to be the version included in glibc2.[01].  The user might
just have that version installed.

I suppose that I could have configure write a C program that included
 and linked with -ldb.  If it failed, try including  and
if that worked, then I've isolated the problem in configure.

Darren
-- 
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]><[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

too funny to not pass on...

[Seth Cohn]

from debian-freshmeat, where we are talking about setting up the new DFMR
(Debian Freshmeat Repository)
Seth:
b) apt-get able, so it's a ftp and/or http site, and a
single line to stick into etc/apt/sources.list
Jeff Covey of freshmeat:
this would rock.

we'll have to work with the apt coding crew to get ready for the day
osdn decides they could be selling ad space here.
# apt-get install mod_foo
Reading Package Lists... Done
Building Dependency Tree... Done
Contacting ad server... Done
/\
|   This download is brought to you by Cisco Systems.|
| BUY OUR ROUTERS!  BUY OUR ROUTERS!  BUY OUR ROUTERS!  BUY OUR ROUTERS! |
| http://www.cisco.com/ |
\/


Seth again:
Debian was brought to you today by the letters J, K, and the number 5.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]