RE: Non-debian running DD's (Was: Re: stop abusing debconf alread y)

[Anthony DeRobertis]

On Sat, 2003-04-26 at 00:12, Milanuk, Monte wrote:

> Gag.  Mail might actually be useful if Apple had had the brains to include
> simple stuff like *threading* of messages. 

Nope, not there yet, even in the latest 10.2.5 stuff...

> I guess 'normal' people don't subscribe to
> mailing-lists, where threading is *essential*.

/me doesn't consider it too essential, as long as you can sort by
subject which does a somewhat reasonable job. But it'd certainly be
nice.


signature.asc
Description: This is a digitally signed message part

Re: i386 compatibility & libstdc++

[Nick Phillips]

On Sat, Apr 26, 2003 at 05:06:56AM +0200, Arnd Bergmann wrote:

> The options we currently have are:
> 
> 1. drop i386 support completely: simple but painful
> 2. create a crippled distro for really old systems (e.g. i386 and i486)
> 3. keep everything the i386 way: slow and incompatible
> 4. like 3, but provide alternatives for new systems (i686+):
>needs a lot of work and ftp space.

No, 4 is not an option -- it would leave too many people in the
"unnecessarily binary-incompatible" bracket. If you want to do a
split at 686+ then you need *two* splits, one there and one at,
say, 486+.

I don't believe it's reasonable to leave people with Pentium-class
machines with systems that are not binary-compatible with other
distributions, and without the ability to use certain 3rd-party
software (in fact I think it's debatable whether or not we could
reasonably leave 486 users out in the cold in that way).

It may be relatively cheap and easy for *you* to buy a two-year-old
system, but I don't believe that in this case you are representative
of nearly enough of our users to be a useful example.



Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Today is the first day of the rest of your life.

Re: i386 compatibility & libstdc++

[Chris Cheney]

On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote:
> It may be relatively cheap and easy for *you* to buy a two-year-old
> system, but I don't believe that in this case you are representative
> of nearly enough of our users to be a useful example.

I also find it hard to believe that the majority of our users do not
have or can not purchase a system that is less than 7 years old. Being
that is how old the i686 sub-arch is... I once attempted to install
Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the
least. Machines old enough to be before i686 are probably also old
enough to be barely usable as a desktop, especially since ram prices
back then were still quite high (~ $40/MB iirc), and disk sizes quite
small (2GB HD was $300 in 1996). What are the theoretical binary-only
apps that these desktops would be using, whizbang 3d games, multimedia
players, or something else? A reduced size 386-586 arch wouldn't be bad
for a server, which imho is about all machines that old are really good
for anyway. (And no Manoj I am not attempting to troll with this post...)


In Dec 1994 I got my P90 with the biggest available ide hard drive
which was 500MB. Compare that size to what sid currently requires for
various installs:

sid chroot   install - 160MB
sid standard install - 249MB
sid standard + gnome install - 623MB
sid standard + kde   install - 677MB

The point being Debian sid with only one of the standard desktops (with
no extra packages and no swap space) is already bigger than most
machines from 1995 and older can support unmodified anyway...

Chris

Re: pbuilder and sid.

[Brian May]

On Sat, Apr 26, 2003 at 07:31:44AM +0200, Martin Godisch wrote:
> Try instead:
> 
>   $ pbuilder create --distribution woody
>   $ pbuilder update --distribution sid
> 
> Kind regards,

... or use the version of debootstrap for unstable.

I have compiled debootstrap and pbuilder unstable versions for woody,
use the following apt-get line:

deb http://www.microcomaustralia.com.au/debian/ woody main

... but you may not want to download all packages, just the debootstrap
one (and possibly pbuilder).
-- 
Brian May <[EMAIL PROTECTED]>

Re: i386 compatibility & libstdc++

[Andreas Metzler]

Arnd Bergmann <[EMAIL PROTECTED]> wrote:
[...]
> 1. drop i386 support completely: simple but painful
> 2. create a crippled distro for really old systems (e.g. i386 and i486)
> 3. keep everything the i386 way: slow and incompatible
> 4. like 3, but provide alternatives for new systems (i686+):
>   needs a lot of work and ftp space.
[...]

I'd vote for 1 or

1a. create a stripped down version for i386, i.e. required/important
and go for i486.

The reasoning is simple: Market share. i386 was never that popular as
i486 for the simple reason that machines were quite expensive and
that i286 was still available (and fast enough for many purposes).
  cu andreas
PS: A simple router might be better off with
http://www.zelow.no/floppyfw/ and there is floppy-linux dedicated for
ISDN routers too.
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: i386 compatibility & libstdc++

[Russell Coker]

On Sat, 26 Apr 2003 17:56, Chris Cheney wrote:
> I also find it hard to believe that the majority of our users do not
> have or can not purchase a system that is less than 7 years old. Being
> that is how old the i686 sub-arch is... I once attempted to install
> Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the

There are also other issues.  Currently it seems that Linux code does not get 
much testing on older hardware.

I have a 2.4.20 kernel compiled with recent GCC 3.2.x that runs on a number of 
Athlon, P2, and P3 machines.  But when installed on the single Pentium 
(non-MMX) machine I run the machine hangs within 6 hours repeatedly.

I haven't tracked this down in detail (it's difficult when each test cycle 
takes several hours and it's a production server).  But it's clear to me that 
something isn't working properly when compiling the latest kernel with the 
latest GCC for an older Pentium machine.

My client (who routinely installs P4 Windows machines for their customers) is 
not too bothered about being forced to upgrade from a Pentium because of 
this, they plan to rescue a Celeron that one of their customers discards...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: i386 compatibility & libstdc++

[Grzegorz B. Prokopski]

W liście z sob, 26-04-2003, godz. 09:56, Chris Cheney pisze: 
> On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote:
> > It may be relatively cheap and easy for *you* to buy a two-year-old
> > system, but I don't believe that in this case you are representative
> > of nearly enough of our users to be a useful example.
> In Dec 1994 I got my P90 with the biggest available ide hard drive
> which was 500MB. Compare that size to what sid currently requires for
> various installs:
> 
> sid chroot   install - 160MB
> sid standard install - 249MB
> sid standard + gnome install - 623MB
> sid standard + kde   install - 677MB

Huh, my first Linux server installation was 386 40MHz 8MB RAM
with 2,3GB hard disk which was starting AFAIK in "linear" mode
(it was in RH 6.0 days).

But even now FWICS it is quite common to use older hardware with
bigger disks, especially as distros tend to be bigger and bigger
(my router used to be potato which fit in 80MB HDD quite nicely,
but after upgrade to woody I couldn't fit all the previous
functionality within those 80MB).

Anyway - I am not using any true 386 systems since years,
so maybe first solution would be to just make i386 mean
"i486 and higher". If there's *real* need for i386, then
it should be possible to create i386true sub-distro in the future.

Just my 0.02$

Grzegorz B. Prokopski

PS: Do not make no jokes about running KDE/GNOME on i386true :-)

-- 
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Debian http://www.debian.org/


signature.asc
Description: PGP signature

Re: i386 compatibility & libstdc++

[Colin Walters]

On Fri, 2003-04-25 at 21:37, Josselin Mouette wrote:
> Le sam 26/04/2003 Ã 02:59, Matthew Palmer a Ãcrit :
> > For the original problem, it surely should be possible to build 386 and 486+
> > versions of libstdc++ and include both in the distro, with linker magic (or
> > installer magic) to tell the difference?
> 
> That would not be enough. We need specific versions of C++ applications
> for 386. Of course, only a few should be enough : python, apt, groff...
> but that is far from an empty list. That's why dropping i386 completely
> and provide an i386 subset of the distribution seems reasonable.

Agreed.  It seems to me though that we've just traded one problem (i386)
for another: our poor archive categorization.

How to define this distribution subset?

Re: i386 compatibility & libstdc++

[Nick Phillips]

On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:

> I'd vote for 1 or
> 
> 1a. create a stripped down version for i386, i.e. required/important
> and go for i486.

I'll drink to that!

-- 
Nick Phillips -- [EMAIL PROTECTED]
You are confused; but this is your normal state.

Re: i386 compatibility & libstdc++

[Nick Phillips]

On Sat, Apr 26, 2003 at 02:56:13AM -0500, Chris Cheney wrote:

> I also find it hard to believe that the majority of our users do not
> have or can not purchase a system that is less than 7 years old.

That's really not so relevant, even if correct. If they already have
a shitload of Pentiums which will do the job, why force them to buy
anything newer?

> Being
> that is how old the i686 sub-arch is... I once attempted to install
> Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the
> least.

Heh. I once (no, twice) installed on a 486-50 with 4MB of RAM... :-P
I can't remember whether that was slink, or whether I got hold of slink
after being suitably impressed with the results (had to leave dselect
running^Wthrashing for round about 36 hours, I think, for the initial
install ;) ).

That's actually what got me started moving from slackware to Debian...

Anyway, back to the point.

> Machines old enough to be before i686 are probably also old
> enough to be barely usable as a desktop,

I think you'll find they'll do just fine in all sorts of roles.
Perhaps not as a whizzy desktop running the latest greatest KDE or Gnome
(resisting the temptation, see ;) ), but certainly running X (although
I must admit XFree >= 4 is a real memory hog compared to previous
versions).

> What are the theoretical binary-only
> apps that these desktops would be using, whizbang 3d games, multimedia
> players, or something else?

Whizbang 3d games and multimedia players are not the only things that
people write in C++.

> A reduced size 386-586 arch wouldn't be bad
> for a server, which imho is about all machines that old are really good
> for anyway. (And no Manoj I am not attempting to troll with this post...)

See, I think this is where you're just fundamentally mistaken.


> In Dec 1994 I got my P90 with the biggest available ide hard drive
> which was 500MB.

:-P No it wasn't. You must have been shopping in the wrong places.
I got my 486DX66 with a 504MB drive in mid '93 and had the option of
a bigger one (~1G I think, but can't remember exactly)...

> Compare that size to what sid currently requires for
> various installs:
> 
> sid chroot   install - 160MB
> sid standard install - 249MB

Perfectly fine. I think I'll have to finish the install on this P200MMX
I have sitting under my desk here just to see how big it does end up.


> The point being Debian sid with only one of the standard desktops (with
> no extra packages and no swap space) is already bigger than most
> machines from 1995 and older can support unmodified anyway...

Whilst I don't see that the "standard desktops" are at all essential to
a productive setup, I will agree that it is a shame how large the
standard installs are getting. I think there will come a point where
it is more useful to have a separate distribution or meta-distribution
for older systems (with a sensible-sized libc, for example) than to
stick with a "one size fits all" approach. I just don't think that with
the quantity of Pentium-class machines out there that we've got to that
point just yet.


Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
Give him an evasive answer.

Re: i386 compatibility & libstdc++

[Tollef Fog Heen]

* Russell Coker 

| My logtools package is written in C++ with the STL.  It performs
| well and will be quite useful to anyone who is running Apache for
| multiple domains on a 386.

No offense, but it is seriously slow.  IIRC, it's a magnitude slower
than mergelog, especially when merging a lot of files.  (And having
FILE_MAX set to 1024 is ridiculously low when merging a lot of log
files :)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: i386 compatibility & libstdc++

[Hamish Moffatt]

On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
> 1a. create a stripped down version for i386, i.e. required/important
> and go for i486.

Is there much performance improvement in dropping i386 in favour of
i486+?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

RE: Non-debian running DD's (Was: Re: stop abusing debconf alread y)

[Matthias Urlichs]

Hi,

On Sat, 26 Apr 2003 04:12:25 +, Milanuk, Monte wrote:
>  I guess 'normal' people don't subscribe to
> mailing-lists, where threading is *essential*.

Depends on the mailing list, I'd say. Most non-technical mailing lists
have so many people who use brain-dead webmail accounts that threading is
somewhat useless.

Personally, I have turned threading off in kmail; the mailing lists go
through a local mail<=>news gateway. Best of both worlds.

-- 
Matthias
-- 
I have never let my schooling interfere with my education.
-- Mark Twain

Re: Request for Clue: i18n of fortune-esque things

[Javier Fernández-Sanguino Peña]

On Thu, Apr 24, 2003 at 07:57:00PM +0200, Andreas Tille wrote:
> On Thu, 24 Apr 2003, Joel Baker wrote:
> 
> > That's more or less what I was hoping - however, checking
> > /usr/share/doc/fortune-mod doesn't show any references to 'language', or
> > any obvious references to i18n or l10n, at least on stable (my chroots are
> > currently down due to one machine having some severe stability problems).
> > Is this just a more-recent-than-stable development?
> Yes. Try testing and for instance fortunes-de which places the German
> cookies at the right place.
> 

That's far from being proper i18n, unless I understand it wrong i18n in 
fortunes just means placing new dat files under /usr/share/games/fortunes. 
That does not give any tools at all for translators to _translate_ 
fortunes, it's esentially a mechanism to show fortunes in different 
languages with _different_ (and usually localised) content.

If you want to have a fortune-based mechanism for debian tips you should 
make sure you can give translators tools to translate the tips in your 
package and give fortune a way to use the i18n properly. That is gettext, 
and there is no gettext support in fortune as far as I see it.

Otherwise you might get to create tips, have them translated and, in the 
long run, users will see _outdated_ (or incomplete) tips because there are 
no proper mechanisms (i.e. msgmerge) for translators to notice you updated 
the the tips or added new ones.

Just my 2c.

Regards

Javi

PS: I'm not sure how "tip of the day" is handled in KDE (kti) or GNOME 
(which program handles those?), maybe you could take a look (and talk) with
the upstream authors to know how are they handled, Gimp and Gnuchas also
seems to do properly it as far as I see..




pgp5bjOJmEcQG.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Andreas Metzler]

Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
>> 1a. create a stripped down version for i386, i.e. required/important
>> and go for i486.

> Is there much performance improvement in dropping i386 in favour of
> i486+?

I've no idea, I was arguing for splitting off i386 because it solves
the original problem.
  cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Bug in apt-get ? [replace essential package / Yes, do as I say]

[Miquel van Smoorenburg]

Before I file a bugreport I thought I'd ask here first ..

It seems that currently apt is not able to replace an essential
package. Well in fact the package I am trying to replace isn't
even really essential...

Sysvinit was split up in sysvinit, initscripts and sysv-rc. The last
one can be replaced by file-rc. Sysv-rc and file-rc conflict and
replace one another.

File-rc and sysv-rc are not Essential, but sysvinit depends on
(sysv-rc | file-rc) so they are 'virtually essential'. However that
doesn't matter as policy says:

D.2.8 Essential

If set to yes then dpkg and dselect will refuse to remove the package
(though it can be upgraded and/or replaced).

Dpkg gets it right. I can replace sysv-rc with file-rc :

# dpkg -i file-rc_0.8.0_all.deb
Selecting previously deselected package file-rc.
dpkg: considering removing sysv-rc in favour of file-rc ...
dpkg: yes, will remove sysv-rc in favour of file-rc.
(Reading database ... 39148 files and directories currently installed.)
Unpacking file-rc (from file-rc_0.8.0_all.deb) ...
Setting up file-rc (0.8.0) ...

However, apt wants to do this in two passes. First it wants to remove
sysv-rc, then it wants to install file-rc. It internally upgrades
sysv-rc to Essential because sysvinit is essential, and then refuses
to do the upgrade:

# apt-get install file-rc
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  sysv-rc
The following NEW packages will be installed:
  file-rc
WARNING: The following essential packages will be removed
This should NOT be done unless you know exactly what you are doing!
  sysv-rc (due to sysvinit)
0 packages upgraded, 1 newly installed, 1 to remove and 31  not upgraded.
Need to get 0B/33.1kB of archives. After unpacking 127kB will be used.
You are about to do something potentially harmful
To continue type in the phrase 'Yes, do as I say!'

If you type 'Yes, do as I say!' apt will run dpkg twice: one to remove
sysv-rc, then once again to install file-rc.

I even tried to install a file-rc package that has 'Provides: sysv-rc'
in the control file but that doesn't help either.

I do not want to remove sysv-rc, I'm replacing it. Is this a bug in
apt ? And, why is apt splitting the operation into two steps ?

Mike.

Re: An doubt

[Luiz Rafael Culik Guimaraes]

Hi Joey

Many thanks

Regards
Luiz

Re: i386 compatibility & libstdc++

[José Luis Tallón]

At 19:55 26/04/2003 +1000, you wrote:
On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
> 1a. create a stripped down version for i386, i.e. required/important
> and go for i486.
Is there much performance improvement in dropping i386 in favour of
i486+?
- Integrated math coprocessor ( why does libc still check for its 
availability? )
- Cache ( very much needed, i mught add )
- Pipeline "attempt" IIRC
- Mandatory 32bits Bus/Memory

IMHO, since we have concluded there are almost NO "true i386" around ( not 
even for routers ), the first *easy* split would be to drop i386 in favour 
of i486 for Sarge+
( does anybody really think i386 will survive another year/year-and-a-half 
?? ). This will solve the ABI problem in one, easy, shot
This means binary-i386 in Debian will really mean "binary-i486" -- I don't 
see any problems here.

We might then try to judge how much of a benefit we can get by moving on to 
i586+ for the vast majority of the archive ( other distributions support 
i586+ *only*, so it can't be that bad, can it? ). Retiring i586 right now 
looks a bit "bold" to be done right now.

I do own a (retired now) 486, with 16MB -- it was really a pain when i last 
used it[ 2years ago], with SuSE 6.2 [released 1998].
These machines are only good for routers now, which means we could create a 
subarch, with just the kernel, basic libs, iptables, ssh, security tools 
and things like that (maybe Postfix/exim/sendmail ? )  -- no need for 
Apache, nor MySQL/PostgreSQL ( !!! ),  especially no need for XFree, 
Gnome, KDE et al -- and everything would be fine. As a side effect, we 
would get the basic installation size down to about 50-65MB ( just 
guessing! ): this can only be an improvement.

The smaller machines me or any of my friends/relatives/acquaintances are 
using are P90 w/32MB, loaded with say, 120GB IDE HDD -- used as "servers" 
connected to cable/ADSL lines, running mldonkey, ftp servers,  -- 
All running "Woody" :D
This means we shouldn't leave that *whole lot* of users without frequent 
security updates for Apache, Postfix/exim, proftpd, ...


Regards,
J.L.

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Daniel Burrows]

On Sat, Apr 26, 2003 at 11:12:00AM +, Miquel van Smoorenburg <[EMAIL 
PROTECTED]> was heard to say:
> # dpkg -i file-rc_0.8.0_all.deb
> Selecting previously deselected package file-rc.
> dpkg: considering removing sysv-rc in favour of file-rc ...
> dpkg: yes, will remove sysv-rc in favour of file-rc.
> (Reading database ... 39148 files and directories currently installed.)
> Unpacking file-rc (from file-rc_0.8.0_all.deb) ...
> Setting up file-rc (0.8.0) ...

  Where'd this deb come from?  0.7.0 is all I can find in the archive..

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|"But what *does* kill me bloody well leaves me dead!"|
|  -- Terry Pratchett, _Carpe Jugulum_|
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: i386 compatibility & libstdc++

[Bart Trojanowski]

* Grzegorz B. Prokopski <[EMAIL PROTECTED]> [030426 04:45]:
> Anyway - I am not using any true 386 systems since years,
> so maybe first solution would be to just make i386 mean
> "i486 and higher". If there's *real* need for i386, then
> it should be possible to create i386true sub-distro in the future.

That sounds very inappropriate not to mention confusing. Besides, we
already have a synonym for "i486 and higher", it's "i486".

B.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgpkgUe1OUuKK.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Darren Salt]

I demand that José Luis Tallón may or may not have written...

> At 19:55 26/04/2003 +1000, you wrote:
>> On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
>>> 1a. create a stripped down version for i386, i.e. required/important
>>> and go for i486.
>> Is there much performance improvement in dropping i386 in favour of i486+?

> - Integrated math coprocessor ( why does libc still check for its
> availability? ) [...]

486SX.

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   We've got Shearer, you haven't

You are taking yourself too seriously.

Re: i386 compatibility & libstdc++

[Bart Trojanowski]

* Hamish Moffatt <[EMAIL PROTECTED]> [030426 05:57]:
> On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
> > 1a. create a stripped down version for i386, i.e. required/important
> > and go for i486.
> 
> Is there much performance improvement in dropping i386 in favour of
> i486+?

For openssl there is a huge improvement.  I was doing benchmarks on
openssl (they were done for internally at a company I no longer work
for).  We were using P3's at the time.  The highest performance gain was
between i386->i486 for varied ciphers; that is to say going to i586 or
i686 (with gcc2.9x) was not that much better.

Take this with a grain of salt...  this may actually have something to
do with openssl having canned ASM implementations for some ciphers on
some architectures, but I am not sure about that.

B.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgpMdscIMu4LI.pgp
Description: PGP signature

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Marcelo E. Magallon]

On Sat, Apr 26, 2003 at 09:54:39AM -0400, Daniel Burrows wrote:

 >   Where'd this deb come from?  0.7.0 is all I can find in the archive..

 Hint: look at the name of the sysvinit maintainer.

 Maybe Miquel is testing the packages *gasp* before uploading them.

 Marcelo

Re: i386 compatibility & libstdc++

[Matthew Garrett]

In chiark.mail.debian.devel, Matthias Klose wrote:

>- Trying to "fix" this resulted in libstdc++5 packages built for
>  i386 and ix86, and selecting the atomicity implementation based on
>  target cpu macros. This approach doesn't work, as I learned now.
>  See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's
>  not possible to mix the two implementations.

Is it possible to "fix" this (ie, provide ABI compatible versions for
i386 and i486) without breaking stuff? 386s are faster than many other
pieces of hardware that we still support, so dropping them seems strange
- on the other hand, an i386 sub-distribution sounds like a world of
pain. Having a standard library that only supports one of the allegedly
supported processors if the ABI changes sounds like the real bug to me.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: i386 compatibility & libstdc++

[Bart Trojanowski]

* Darren Salt <[EMAIL PROTECTED]> [030426 10:26]:
> I demand that José Luis Tallón may or may not have written...
> 
> > At 19:55 26/04/2003 +1000, you wrote:
> >> On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
> >>> 1a. create a stripped down version for i386, i.e. required/important
> >>> and go for i486.
> >> Is there much performance improvement in dropping i386 in favour of i486+?
> 
> > - Integrated math coprocessor ( why does libc still check for its
> > availability? ) [...]
> 
> 486SX.

I thought that in-kernel emulation would have solved the gap between 486
DX and SX.

B.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgpSjyH3NcIVN.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[José Luis Tallón]

At 14:17 26/04/2003 +0100, you wrote:
I demand that José Luis Tallón may or may not have written...
> At 19:55 26/04/2003 +1000, you wrote:
>> On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
>>> 1a. create a stripped down version for i386, i.e. required/important
>>> and go for i486.
>> Is there much performance improvement in dropping i386 in favour of i486+?
> - Integrated math coprocessor ( why does libc still check for its
> availability? ) [...]
486SX.
Though I own one, these are not exactly *full* 486, but just the low-cost 
version...


--
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   We've got Shearer, you haven't
You are taking yourself too seriously.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Anthony Towns]

On Sat, Apr 26, 2003 at 11:12:00AM +, Miquel van Smoorenburg wrote:
> Sysvinit was split up in sysvinit, initscripts and sysv-rc. The last
> one can be replaced by file-rc. Sysv-rc and file-rc conflict and
> replace one another.

Hrm. Any possibility of making sysv-rc and file-rc be concurrently
installable, via alternatives or somethign similar? That's the way mawk
and gawk work, which is a similar situation.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgp4KMzfiwLX3.pgp
Description: PGP signature

Re: libpng clarification

[Steve M. Robbins]

Hi,

Chris Cheney asks

So gnome doesn't use imlib (in Debian at least it seems to), or
did I somehow miss why it appears RedHat only has one version of
imlib, which is the version compiled against libpng12?

Red Hat hacked gdk-imlib so that libraries loaded as "modules"
(like png) do NOT put their symbols in the global table.  So they
can link with png3 but the clients of gdk-imlib don't see the
png3 symbols.

If you now wonder why Debian doesn't do that, the answer is that
gdk-imlib is not the only Gnome 1 library that uses png.  (The other
one is gdk_pixbuf) Before I knew that, I *did* employ the Red Hat
patch on gdk-imlib.  It was an unmitigated disaster because programs
that linked with both imlib and pixbuf started crashing.  In the end,
it seemed best to just introduce a second source package so that I
could build gdk-imblib1 with png2, and a new imlib with png3.

-Steve

Re: i386 compatibility & libstdc++

[Mark Brown]

On Sat, Apr 26, 2003 at 10:08:12AM -0400, Bart Trojanowski wrote:

> For openssl there is a huge improvement.  I was doing benchmarks on
> openssl (they were done for internally at a company I no longer work

OpenSSL can (and already does) drop in the CPU-specific variants at run
time in an ABI-compatible fashion.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgprX89DkTfRV.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Mark Brown]

On Sat, Apr 26, 2003 at 10:55:08AM -0400, Bart Trojanowski wrote:
> * Darren Salt <[EMAIL PROTECTED]> [030426 10:26]:

> > 486SX.

> I thought that in-kernel emulation would have solved the gap between 486
> DX and SX.

It works just as well for 386SX as for 486SX.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgpk6yuJTCti0.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Darren Salt]

I demand that Bart Trojanowski may or may not have CCed to me WITHOUT MY
ASKING FOR THAT...

> * Darren Salt <[EMAIL PROTECTED]> [030426 10:26]:
>> I demand that José Luis Tallón may or may not have written...
>>> At 19:55 26/04/2003 +1000, you wrote:
 On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote:
> 1a. create a stripped down version for i386, i.e. required/important
> and go for i486.
 Is there much performance improvement in dropping i386 in favour of
 i486+?
>>> - Integrated math coprocessor ( why does libc still check for its
>>> availability? ) [...]
>> 486SX.

> I thought that in-kernel emulation would have solved the gap between 486 DX
> and SX.

Good point...

Unless there's some code which is only worth using in the absence of hardware
FP :-)

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Scumderland 0  Newcastle United 1 :-)

YES! GET IN! WAHEY! Etc.

RE: Non-debian running DD's (Was: Re: stop abusing debconf alread y)

[Nathan Paul Simons]

On Fri, 2003-04-25 at 21:12, Milanuk, Monte wrote:
> Gag.  Mail might actually be useful if Apple had had the brains to include
> simple stuff like *threading* of messages.  All the fluff in the world, and
> the message sorting of pine.  Go figure.  When I got my first Mac (eMac
> running 10.1.5 w/ the Jaguar disks in the box) I'd been reading all these
> wonderful reviews of the various mail clients for OS X, and the authors
> especially gushed about Mail.app.  When I finally figured out it plain
> didn't support message threading, and found out that a lot of other people
> had the same gripe, I wondered, 'what in the blue blazes do these writers
> actually use email for?'  I guess 'normal' people don't subscribe to
> mailing-lists, where threading is *essential*.

As a long time Mac admin/programmer, one of the things I've noticed
about a lot of Mac users is that they will gush over anything Apple does
or makes.  If Apple made Windows, they would love it.

-- 
The more I use other operating systems, the more I like Debian GNU/Linux
http://www.debian.org  http://www.gnu.org  http://www.linux.org


signature.asc
Description: This is a digitally signed message part

Re: i386 compatibility & libstdc++

[Steve Langasek]

On Sat, Apr 26, 2003 at 02:56:13AM -0500, Chris Cheney wrote:
> On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote:
> > It may be relatively cheap and easy for *you* to buy a two-year-old
> > system, but I don't believe that in this case you are representative
> > of nearly enough of our users to be a useful example.

> I also find it hard to believe that the majority of our users do not
> have or can not purchase a system that is less than 7 years old.

Your non-sustainable Western consumerism is showing.

> Machines old enough to be before i686 are probably also old enough to
> be barely usable as a desktop, especially since ram prices back then
> were still quite high (~ $40/MB iirc), and disk sizes quite small (2GB
> HD was $300 in 1996). What are the theoretical binary-only apps that 
> these desktops would be using, whizbang 3d games, multimedia
> players, or something else? A reduced size 386-586 arch wouldn't be bad
> for a server, which imho is about all machines that old are really good
> for anyway. (And no Manoj I am not attempting to troll with this post...)

Though I don't think we have to worry about binary-only C++ apps for 486
and 586 machines, AIUI the whole reason there are two
binary-incompatible implementations is that one gives a performance gain
on newer systems.  Users of lower-end systems that are already limping
deserve a chance at seeing some of these performance benefits, the same
as users of newer systems.

As for using i486s and i586s as anything other than servers, I'm
currently involved in a project whose goal is to put surplus PC and Mac
hardware running free (as in beer) software into the hands of
disadvantaged members of the community.  I also know of a church locally
that was considering the adoption of Debian for the PCs they ship to
West Africa (just add electricity) as part of their mission work.  While
neither of these scenarios demands cutting-edge software or frequent
security updates, it would be nice to be able to provide such users with
an OS that can keep pace with the shifting protocol soup of the
Internet.  If it's a call between tossing updates and tossing the
donated 486s, though, the hardware stays.

-- 
Steve Langasek
postmodern programmer


pgpVFfyUaoOBv.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Emile van Bergen]

Hi,

On Sat, Apr 26, 2003 at 05:07:41PM +0100, Mark Brown wrote:

> On Sat, Apr 26, 2003 at 10:55:08AM -0400, Bart Trojanowski wrote:
> > * Darren Salt <[EMAIL PROTECTED]> [030426 10:26]:
> 
> > > 486SX.
> 
> > I thought that in-kernel emulation would have solved the gap between 486
> > DX and SX.
> 
> It works just as well for 386SX as for 486SX.

Note that the SX suffix for 386 means a 16-bit external data bus
(instead of a 32-bit one for the DX), whereas for 486 the SX means no FP
included.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

lilo with debconf

[Andrés Roldán]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

I am maintaining LILO at the moment and there are several requests
- From the LILO users asking for using debconf on the package.

I have made the package with debconf and I was about to upload it 
but I talked with some friends and they told me to ask you all first 
before make this upload. This is because this change could affect 
the default Debian installation in some way.

Any comments are appreciated.

- -- 
Andres Roldan, CSO
Fluidsignal Group
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+qrnP2OByS7KTlusRAqwTAJ4qq8jLPR6+GYUugTydmi3CFVFpGACff6mI
56Y5i+Si46zkKREOng7D6BI=
=LBIS
-END PGP SIGNATURE-

Re: i386 compatibility & libstdc++

[Bart Trojanowski]

* Mark Brown <[EMAIL PROTECTED]> [030426 12:21]:
> On Sat, Apr 26, 2003 at 10:08:12AM -0400, Bart Trojanowski wrote:
> 
> > For openssl there is a huge improvement.  I was doing benchmarks on
> > openssl (they were done for internally at a company I no longer work
> 
> OpenSSL can (and already does) drop in the CPU-specific variants at run
> time in an ABI-compatible fashion.

This question is obviously off topic for this thread but I am
interested...

re 'at run time':  Does that mean that at compile time there are
multiple snippets of functionally-equivalent code compiled to support
varied run-time arch's?

I have not looked the the OpenSSL code in a while. :)

B.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgp5utoeRk3RY.pgp
Description: PGP signature

Re: lilo with debconf

[Bernd Eckenfels]

On Sat, Apr 26, 2003 at 11:54:36AM -0500, Andrés Roldán wrote:
> I have made the package with debconf and I was about to upload it 
> but I talked with some friends and they told me to ask you all first 
> before make this upload. This is because this change could affect 
> the default Debian installation in some way.

You can upload it to a private location for review. I am willing to check
it. I hope you do lilo.conf parsing and rewriting? Therefore it would
instantly work with an exisiting lilo.conf without new questions?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Anthony Towns   wrote:
>On Sat, Apr 26, 2003 at 11:12:00AM +, Miquel van Smoorenburg wrote:
>> Sysvinit was split up in sysvinit, initscripts and sysv-rc. The last
>> one can be replaced by file-rc. Sysv-rc and file-rc conflict and
>> replace one another.
>
>Hrm. Any possibility of making sysv-rc and file-rc be concurrently
>installable, via alternatives or somethign similar? That's the way mawk
>and gawk work, which is a similar situation.

Well, that is perhaps possible, but 'there can be ony one'. If file-rc
is the way the system runs, and you change the alternatives links
to the update-rc.d/invoke-rc.d/rc/RCs of sysv-rc, you made your
system unable to boot (or shutdown). Having them both installed
is dangerous.

Besides, I think that what apt is doing is against policy. Policy
says that an essential package /can/ be replaced. Apt refuses
to do that (but dpkg does it just fine). So I though that perhaps
there is something that I'm overlooking. Ideas ?

Perhaps I should just dive into the apt source code and fix it,
but it has been years ago since I touched C++ ..

Mike.

Re: i386 compatibility & libstdc++

[Mark Brown]

On Sat, Apr 26, 2003 at 12:53:04PM -0400, Bart Trojanowski wrote:

> re 'at run time':  Does that mean that at compile time there are
> multiple snippets of functionally-equivalent code compiled to support
> varied run-time arch's?

The support is actually in the runtime linker.  libssl is compiled
multiple times with CPU-optimized versions installed into subdirectories
of /usr/lib indicating the CPU type.  While doing runtime linking ld.so
looks first in the CPU-specific subdirectories.  This only works if the
ABIs of the libraries are interchangable.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp6O8sC8kgKo.pgp
Description: PGP signature

Re: lilo with debconf

[Colin Watson]

On Sat, Apr 26, 2003 at 11:54:36AM -0500, Andrés Roldán wrote:
> I am maintaining LILO at the moment and there are several requests
> - From the LILO users asking for using debconf on the package.
> 
> I have made the package with debconf and I was about to upload it 
> but I talked with some friends and they told me to ask you all first 
> before make this upload. This is because this change could affect 
> the default Debian installation in some way.

I suspect it would be a good idea to look through the archived bugs and
list archives from the last time debconf was added to lilo.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Time to package simpleinit?

[Joachim Breitner]

Hi,

obviously debian sid is from now on capable of supporting several init
script schemes. Now I wonder if it is now possible to package R. Goochs
simpleinit [1]. But I have some questions:

 * Would that require replacing sysv-rc or sysvinit+sysv-rc? I think
R.Goochs /sbin/init is capable of replacing our /sbin/init, but we
actually only want to replace the way the startup scripts are handled.
 * The /etc/init.d/ scripts would need to add "need otherscript" (and
sometimes "provide something"). As I think it is a very bad idea to edit
these scripts in our post-install (and try to reedit them in
pre-remove)) one would have to file bugs agains packages with
/etc/init.d scripts. Will that be sucessfull? How cooperative will the
maintainers of these script be?
 * Is there even interest in simpleinit by others than me? I would also
need someone to ask if I have problems with sysvinit or similar, and I
would like to know who thinks he is capable of helping me? Are there
people that might help me when it comes to file bug against packages
with /etc/init.d scripts?

Thx for your attention

Joachim aka nomeata

[1] http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: OpenEXR packages (fwd)

[Andrew Lau]

On Sat, Apr 26, 2003 at 09:10:44AM +0200, Jesus Climent wrote:
> On Fri, Apr 25, 2003 at 07:27:28PM -0700, Drew Hess wrote:
> > 
> > Hey guys, can I do anything to help get OpenEXR into Debian?
> 
> Seems that we are both MIA. I am busy with my project, and I contacted him to
> tell him I will not be ready to maintain the package, and since he had another
> ITP, he could go ahead.
> 
> But no answer so far.
> 
> Andrew. are you there?

Moo. 

I totally forget to get back to you guys about it. Sorry! I've been
really busy recently with my university studies, but I should have
some spare time soon to finish off where I left off before I found out
Jesus was working on it. I should be able to upload them in a week and
a half to a fortnight's time. Is that a problem for you Drew?

Yours sincerely,
Andrew "Netsnipe" Lau

-- 
---
* Andrew "Netsnipe" Lau  Computer Science & Student Rep, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---


pgpDTIRikaCfh.pgp
Description: PGP signature

Re: lilo with debconf

[Steve Langasek]

On Sat, Apr 26, 2003 at 11:54:36AM -0500, Andrés Roldán wrote:

> I am maintaining LILO at the moment and there are several requests
> From the LILO users asking for using debconf on the package.

> I have made the package with debconf and I was about to upload it 
> but I talked with some friends and they told me to ask you all first 
> before make this upload. This is because this change could affect 
> the default Debian installation in some way.

This was attempted before, with disasterous results.  Before uploading
to stable, you should test the package thoroughly, upload a test package
to experimental, and actively solicit feedback from the developer
community.  It would be nice if lilo used debconf, but any brokenness in
the process is sure to bring a user backlash. :)

-- 
Steve Langasek
postmodern programmer


pgpDRNmrRd964.pgp
Description: PGP signature

Re: lilo with debconf

[Andrés Roldán]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> On Sat, Apr 26, 2003 at 11:54:36AM -0500, Andrés Roldán wrote:
>> I have made the package with debconf and I was about to upload it 
>> but I talked with some friends and they told me to ask you all first 
>> before make this upload. This is because this change could affect 
>> the default Debian installation in some way.
>
> You can upload it to a private location for review. I am willing to check
> it. I hope you do lilo.conf parsing and rewriting? Therefore it would
> instantly work with an exisiting lilo.conf without new questions?

you can add the following sources to your sources.list

deb http://people.fluidsignal.com/~aroldan/debian unstable main
deb-src http://people.fluidsignal.com/~aroldan/debian unstable main

Thanks in advance

>
> Greetings
> Bernd
> -- 
>   (OO)  -- [EMAIL PROTECTED] --
>  ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
>   o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
> (OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

-- 
Andres Roldan, CSO
Fluidsignal Group

Re: lilo with debconf

[Bernd Eckenfels]

On Sat, Apr 26, 2003 at 01:18:02PM -0500, Andrés Roldán wrote:
> you can add the following sources to your sources.list
> deb http://people.fluidsignal.com/~aroldan/debian unstable main
> deb-src http://people.fluidsignal.com/~aroldan/debian unstable main

apt-get does not work, but i installed it manually:

The first note (lilo/install-note):
"Changing the default LILO boot menu bitmap"
is it realy needed to present this message, wouldnt it be easier to try to
parse the config file, if everything is fine?


Ummm.. on my version of lilo debconf is asking me if reconfiguration is
needed, and if yes, it will start liloconf. This is for sure safe, but I
doubt that this is what was understood by "configuring lilo with debconf".

liloconf does not work if stated from debconf on my system, the first prompt
hangs, no enter or ^d helps, only ^c.

I also think you should only skip the liloconf step, but not the link step
in postinst.

BTW: the lba32 option by liloconf is inserted into the file without a
boilerplate comment and before the "# generated by" line.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Bug in apt-get ? [replace essential package / Yes, do as I say]

[Daniel Burrows]

On Sat, Apr 26, 2003 at 04:31:36PM +0200, "Marcelo E. Magallon" <[EMAIL 
PROTECTED]> was heard to say:
> On Sat, Apr 26, 2003 at 09:54:39AM -0400, Daniel Burrows wrote:
> 
>  >   Where'd this deb come from?  0.7.0 is all I can find in the archive..
> 
>  Hint: look at the name of the sysvinit maintainer.

  Ok, if we're going to play the sarcasm game..

  Hint: look at the name of the file-rc maintainer.

>  Maybe Miquel is testing the packages *gasp* before uploading them.

  So I take it he's NMUing file-rc and these are private packages?  I was
hoping there were 0.8.0 packages in the wild that I could use to unclog
the sysvinit situation on my computer. :(

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| "Fluble, the others want you to know that we|
|  have you surrounded with tranquilizer rifles   |
|  and are prepared to use them.  Again."  -- Fluble  |
\-- Does your computer have Super Cow Powers? --- http://www.debian.org --/

evolution menu icons broken

[Jack Howarth]

  Does gdk-imlib1 need to be rebuilt? It seems since the new png
changes went into debian ppc sid, the menu icons are broken in
evolution.
  Jack

/run/, resolvconf and read-only root

[Thomas Hood]

This message is about three interdependent goals:

1. To create /run/, which makes it possible ...
2. to implement variable resolver configuration, which will help
3. to make it possible to mount / read-only.

(In the present context, "variable" information is information
that changes during the normal operation of a system, not
just when the system is administered.)

So far in pursuit of #3 I have filed a few bug reports asking
that programs store certain variable information under /var/.
Those changes should be straightforward and relatively
uncontroversial.  As was discussed here earlier, however,
some programs cannot use /var/ and need something like /run/.
Creating /run/ and creating a variable resolver configuration
framework are liable to be more controversial.  (It shouldn't
be too controversial at the FHS level, however.  I have posted
questions on the FHS list and no serious objections have been
raised against the idea of /run/.  Someone pointed out that
several distros already use /initrd/ without FHS permission.
There's good reason for that, so no big deal.)

So, ... before I begin asking maintainers to implement the
necessary changes, I ask for commentary here on the following
outline.

#1  /run/
=

Jamie Wilkinson has prepared patches: http://spacepants.org/
and is updating them for the latest sysvinit release (2.85).
  * base-files
  Add /run/ directory
  * pam, shadow
  Allow either /etc/nologin or /run/nologin to prevent
  nonroot login
  * sysvinit:
  Touch /run/nologin (not /etc/nologin) when there is a
  delay before a shutdown.
  * util-linux
  Use /run/mtab for mount's statefile

#2. Variable resolver configuration
===

The resolver configuration file, /etc/resolv.conf, is one of the
variable files in /etc/.  ppp/pppconfig and pump both modify it, 
stomping on each other's changes if they are both used.  Neither
of them notifies DNS caches of available forwarders.

It is proposed that these problems be solved by means of the
following variable resolver configuration scheme.

* Symlink /etc/resolv.conf -> /run/resolvconf/resolv.conf
* Resolv.conf-like files are maintained for each i'face in
  /run/resolvconf/interface/ by the configurator of that i'face
* DNS cache configuration file fragments go in /run//
* /sbin/update-resolver regenerates /run/resolvconf/resolv.conf
  and calls DNS cache update scripts in /etc/resolvconf/update.d/
  to update DNS cache configuration file fragments in
  /run//

TODO -- done in EXPERIMENTAL resolvconf package -- latest version:
  http://panopticon.csustan.edu/thood/resolvconf_0.3.tar.gz
  http://panopticon.csustan.edu/thood/resolvconf_0.3_all.deb
  * resolvconf (to be integrated into libc6, home of the resolver)
* Create /sbin/update-resolver="/etc/init.d/resolvconf reload"
* Create /etc/init.d/resolvconf script to:
  * Write /run/resolvconf/resolv.conf which lists nameservers
from /run/resolvconf/interface/* files
  * Do "run-parts /etc/resolvconf/update.d"
* Symlink /etc/rcS.d/S39resolvconf -> /etc/init.d/resolvconf
  * ppp
* Create script /etc/ppp/ip-up.d/resolvconf to:
  * Write the lines:
  nameserver $DNS1
  nameserver $DNS2
to /run/resolvconf/interface/$PPP_IFACE
  * Then run update-resolver
* Create script /etc/ppp/ip-down.d/resolvconf to:
  * Delete /run/resolvconf/interface/$PPP_IFACE
  * Then run update-resolver
  * bind
* Create script /etc/resolvconf/update.d/bind to:
  * Convert /etc/bind/named.options.sed into
/run/bind/named.options (which is to be included
in /etc/bind/named.conf)
  * Then run "/etc/init.d/bind reload"

TODO
  * pppconfig
* Modify /etc/ppp/ip-up.d/0dns-up, /etc/ppp/ip-down.d/0dns-down
  to call /sbin/update-resolver if available instead of futzing
  with /etc/resolv.conf
  * pump
* Change /sbin/pump to:
  * Write resolv.conf info to /run/resolvconf/interface/pppX
instead of to the current /etc/resolv.conf
  * Then run update-resolver
  * dhcp3-client
* Change /etc/dhcp3/dhclient-script to:
  * Write resolv.conf info to /run/resolvconf/interface/$IFACE
instead of to the current /etc/resolv.conf
  * Then run update-resolver
  * ifupdown
* Allow nameservers to be listed in /etc/network/interfaces
  thus:
nameserver a.b.c.d
  For each such nameserver:
  * Write to /run/resolvconf/interface/$IFACE the line
  nameserver a.b.c.d
  * Then run update-resolver
  * bind
* Change the /etc/bind/named.conf file to include
  /run/bind/named.options 
* Convert /etc/bind/named.conf.options into
  /etc/bind/named.options.sed
* Change /etc/init.d/bind script to:
  * At the bottom of start(), write
  nameserver 127.0.0.1
to /run/resolvconf/interface/lo
and then run update-resolver
  * At top of stop(), delete /run/resolvconf/interface/

1/5阳朔凤凰行--商旅沙龙debian-devel03:39:08

[ddsjjkdjkld]

Re: Time to package simpleinit?

[Henrique de Moraes Holschuh]

On Sat, 26 Apr 2003, Joachim Breitner wrote:
>  * The /etc/init.d/ scripts would need to add "need otherscript" (and
> sometimes "provide something"). As I think it is a very bad idea to edit
> these scripts in our post-install (and try to reedit them in
> pre-remove)) one would have to file bugs agains packages with
> /etc/init.d scripts. Will that be sucessfull? How cooperative will the
> maintainers of these script be?

Very, as long as it is done in a serious, generic way. I am willing to help
you on this.  But first, please read
http://people.debian.org/~hmh/debconf2/debconf2-initscripts-bkg.pdf

We have a lot of work ahead of us.  I took a halt on it because I lacked the
time, but now that Miquel surfaced again and did the sysv split, we could
continue designing the system.  I figure sysvinit and friends will have
stabilized again in a more change-init-system-friendly way by the time we
finish...

Once it is designed (a way to properly support the dynamic dependencies such
as need and provide of simpleinit), we can start deploying it.

-- 
  "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: pilot-link in Sid and Sarge: Much bigger question

[Björn Stenberg]

David Nusinow wrote:
> You say you can't deal with unstable because the software is broken.
> Well, that's because the software you want isn't ready to be released.

That's not the whole truth. A _lot_ of software is ready and working, but is
held back from entering sarge due to dependency problems that other distros
simply don't have. This is an issue I have been probing the last weeks.

An example: Before gcc-3.3 and gcc-3.2 went in the other day, no less than 607
packages were stuck in unstable waiting for them. How many of those packages
actually required gcc 3 to compile and run? I'd guess not many.

While debians binary compatibility demands can be argued as more elegant or
"right" than simple source dito, they definitely are more complex and lead to
dependency problems that hold back working software.

> Sarge simply isn't ready to release.

Damn right it's not, sarge is way too _old_ for release. Mozilla 1.0.0? No
openoffice.org? Gnome 1? KDE 2.2?

One difference, good or bad, between Debian and commercial distributions is
the lack of branches above stable. When commercial distro X makes a release,
they pick the last-known-good versions of all the packages they want, compile
it all, change a few versions, compile again and ship the product. It's crude,
it's labour-intensive, it's pretty damn effective.

In Debian, it's not uncommon for a great number of packages to need to have
their latest versions bug free at the same time to reach testing and thus be a
release candidate. If any one of the required packages introduce a bug, the
whole house of cards falls down. For packages with a lot of external
references, a testing release is almost impossible to achieve without a
coordinated freeze. Look at Mozilla, it's had 16 uploads since the last one
that was admitted into testing. Why was none of those 16 accepted into
testing? It's not because all of those releases were more buggy than the
testing version is (lord knows 1.0.0 is barely usable.)  It's due to
ever-breaking, and ever-increasing, dependencies. Mozilla now even requires
gtk+ 2.0. I bet that's news to the people running it on KDE, or gnome1, or
win32.

Don't get me wrong. The current system works great. It produces some really
high-quality releases, for a truckload of platforms. The only catch is the
software in those releases is two years old.

Before brushing this aside as an uninformed rant, stop for a moment and
consider which release you'd recommend your computer-savvy-but-no-programmer
friends to use when they want to run linux at work. Then tell me there is no
problem.

-- 
Björn

Bug#190901: ITP: gnome-sensors -- A GNOME2 applet that displays your hardware sensors (fan speed,

[Sven Luther]

Package: wnpp
Version: unavailable; reported 2003-04-27
Severity: wishlist

* Package name: gnome-sensors
  Version : 0.9c
  Upstream Author : Vinicius Kursancew <[EMAIL PROTECTED]>
* URL : http://www.vkcorp.org/gsensors/
* License : GPL
  Description : A GNOME2 applet that displays your hardware sensors.

This is a GNOME2 applet that displays your hardware sensors (fan
speed, temperature, voltage ...) status and can warn you and log
if a sensor goes out of a specified range.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux iliana 2.4.21-pre5 #1 SMP dim mar 30 10:51:33 CEST 2003 i686
Locale: LANG=fr_FR.ISO-8859-1, LC_CTYPE=fr_FR.ISO-8859-1

Re: lilo with debconf

[Andrés Roldán]

Hi again.

I have figured out that LILO used debconf a few years ago to create
/etc/lilo.conf with disasterous results. At this moment, LILO configuration
is made by running /usr/sbin/liloconfig in postinst script but, as this 
script is made in perl, you cannot upgrade LILO non-interactively.
If, for instance, a user has a cron with the following:

apt-get update
apt-get -y dist-upgrade

The user must answer the liloconfig questions in order to make his upgrade
done.

I was thinking (and that's why I wrote this email) in a solution that
may fix this problem. What if debconf tells the user to run liloconfig
manually and AFTER the installation and not by postinst script? Would this
be the best solution?

As always, any input is appreciated.


Andrés Roldán <[EMAIL PROTECTED]> writes:

> Hi
>
> I am maintaining LILO at the moment and there are several requests
> From the LILO users asking for using debconf on the package.
>
> I have made the package with debconf and I was about to upload it 
> but I talked with some friends and they told me to ask you all first 
> before make this upload. This is because this change could affect 
> the default Debian installation in some way.
>
> Any comments are appreciated.
>
> -- 
> Andres Roldan, CSO
> Fluidsignal Group
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>

-- 
Andres Roldan, CSO
Fluidsignal Group

Re: pilot-link in Sid and Sarge: Much bigger question

[David Krider]

Björn Stenberg wrote:
An example: Before gcc-3.3 and gcc-3.2 went in the other day, no less than 607
packages were stuck in unstable waiting for them. How many of those packages
actually required gcc 3 to compile and run? I'd guess not many.
Well, hey, if gcc 3.3 has made it into stable, this is big news. Upon 
checking, I see that KDE 3.1.1 has followed suit. (I'm not a Gnome 2.x 
fan. It seems to me that the entire project is in beta, and there's 
nothing the packagers would be able to do with that.) Unfortunately, 
Mozilla's still stuck at 1.*0*?! I mean, I would have at least thought 
that Debian would be starting with the mozilla group's bug fix for that 
branch. *As long as sarge would release by the end of the year*, this 
puts the distro only *1* year behind the rest of the pack. If it takes 
two years to release sarge (like woody), then nothing has changed anyway.

dk

Re: Time to package simpleinit?

[Matthew Palmer]

On 26 Apr 2003, Joachim Breitner wrote:

>  * The /etc/init.d/ scripts would need to add "need otherscript" (and
> sometimes "provide something"). As I think it is a very bad idea to edit
> these scripts in our post-install (and try to reedit them in
> pre-remove)) one would have to file bugs agains packages with
> /etc/init.d scripts. Will that be sucessfull? How cooperative will the
> maintainers of these script be?

Sysvinit works fine for me, and I have no idea what simpleinit does, but if
your bugreport on my packages includes sufficient instructions to make the
change, and the change doesn't cause undue disruption to other current
functionality, I'd be quite happy to apply the change and reupload ASAP.


-- 
---
#include 
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

Re: pilot-link in Sid and Sarge: Much bigger question

[Matthew Palmer]

On Sat, 26 Apr 2003, [iso-8859-1] Björn Stenberg wrote:

> One difference, good or bad, between Debian and commercial distributions is
> the lack of branches above stable. When commercial distro X makes a release,
> they pick the last-known-good versions of all the packages they want, compile
> it all, change a few versions, compile again and ship the product. It's crude,
> it's labour-intensive, it's pretty damn effective.
  ^

And there's why it doesn't work for Debian.  We don't have money to throw at
our developers.

Face the facts: Debian Is Different.  No amount of complaining about it will
change that.  From the fundamentals, right up to the work-a-day issues, it's
all fundamentally different to any other mainstream distro out there. 
That's why many people love Debian.  It's also why many people loathe
Debian.

If you do not like it, you have the choice of many other distributions of
software out there.  You are even free to get together with a bunch of your
mates and rebuild the latest, shiny! versions of all of the desktop
distractions on top of woody or sarge. I'd even encourage you to do that. 
You're targetting a different audience than Debian is, so that's probably a
good way to scratch your itch.

> Don't get me wrong. The current system works great. It produces some really
> high-quality releases, for a truckload of platforms. The only catch is the
> software in those releases is two years old.

And?  Debian appears to have chosen High Quality over Bleeding Edge.  If you
don't like that choice, you can choose to use something different, or roll
your own.

> Before brushing this aside as an uninformed rant, stop for a moment and
> consider which release you'd recommend your
> computer-savvy-but-no-programmer friends to use when they want to run
> linux at work. Then tell me there is no problem.

I'd install Debian across the board if a Linux solution was called for,
because it's a stable, reliable, functional platform, which is *exactly*
what what companies need.  Eye candy comes a distinct 20th (or lower).  I've
worked in places which are still using greenscreens, because stability,
reliability, a known UI, and a lack of distraction, is far more important
than the latest whizz-bang shiny! "hey look my monitor's melting" GUI.

Now, if you'd asked the question "what would you recommend to your csbnp
friends to try Linux at home" I'd probably burn them a Mandrake disc.  If
they want shiny! then they can have shiny.


-- 
---
#include 
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

experimental conffile merge for dpkg

[Jarno Elonen]

Hi,

I've written an experimental conffile merge support for dpkg.

http://elonen.iki.fi/code/dpkg-merge/ contains the patched dpkg
and a new interactive python & curses based two-way merge tool
called imediff2 (+ 3 screenshots for the impatient).

For those who would like try it:

  + install 'dpkg_1.10.10merge_i386.deb'
  + install 'imediff2_1.0-1_all.deb'
  + run 'export MERGE2=/usr/bin/imediff2'
  + install some package with updated conffiles
and press 'm' (the option is only visible if
the MERGE2 environment variable is set)

The changes to dpkg are also in a separate patch file,
'dpkg-merge.patch'

Here's the proposed changelog for dpkg:

   * Added an experimental 'Merge' option
 (Closes: #189805, #48717, #120152)
   * Enclosed file names with quotes in command string (Closes #147583)
   * Added a message with the path of the new conffile in Suspend
   * Ignore SIGINT while waiting for child processes so that dpkg
 doesn't die if the child is ctrl-c'd

- Jarno

Re: pilot-link in Sid and Sarge: Much bigger question

[Colin Watson]

On Sat, Apr 26, 2003 at 10:48:25PM +0200, Björn Stenberg wrote:
> An example: Before gcc-3.3 and gcc-3.2 went in the other day, no less than 607
> packages were stuck in unstable waiting for them. How many of those packages
> actually required gcc 3 to compile and run? I'd guess not many.

Without the relevant version of libgcc1, those packages cannot be
guaranteed to work. You might be able to build it with an older
compiler, but the packages *as uploaded* require the newer libgcc1.

-- 
Colin Watson  [EMAIL PROTECTED]

simpleinit and other init procedures

[Erich Schubert]

Hello,
I have working "simpleinit-msb" and "minit" packages on my system.
(simpleinit-msb is an extended simpleinit, see 
http://www.winterdrache.de/linux/newboot/)
and "minit" has nice monitoring capabilities and is similar to
daemontools, but GPL (http://www.fefe.de/minit/)

The initscripts for the packages need a lot of fiddling, but i think i
have a reasonable example set ready.

I'd like to have support for linux-progress-patch, too, if you design a
complete new init system. (I'm interested in that, too... i had intended
to work at this in DebCamp, but i probably won't come to DebConf now. )

Greetings,
Erich Schubert
-- 
erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_
 Go away or i'll replace you with a very small shell script.  //\
 Jemanden zu lieben heißt glücklich zu sein, ihn glücklich zu sehen.  V_/_

Bug#190909: ITP: libxml-libxml-common-perl -- Perl module for common routines & constants for XML::LibXML et al

[Ardo van Rangelrooij]

Package: wnpp
Version: unavailable; reported 2003-04-26
Severity: wishlist

* Package name: libxml-libxml-common-perl
  Version : 0.12.1
  Upstream Author : Christian Glahn <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/XML/
* License : Artistic, GPL
  Description : Perl module for common routines & constants for XML::LibXML 
et al

This module contains several constants and functions that are shared
by XML::LibXML, XML::GDOME and XML::LibXSLT (not all done yet, though).

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux gondor 2.4.20 #1 SMP Sat Apr 19 09:54:38 CDT 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: Time to package simpleinit?

[David B Harris]

On Sat Apr 26, 07:36pm +0200, Joachim Breitner wrote:
>  * The /etc/init.d/ scripts would need to add "need otherscript" (and
> sometimes "provide something"). As I think it is a very bad idea to edit
> these scripts in our post-install (and try to reedit them in
> pre-remove)) one would have to file bugs agains packages with
> /etc/init.d scripts. Will that be sucessfull? How cooperative will the
> maintainers of these script be?

I second Matthew Palmer and Henrique's sentiments. Matthew's in that if
you do all the work for me, I'll merge it (likely quickly :). And
Henrique's in that it needs to be fairly generic.


pgp0FlsmzWqA1.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Gunnar Wolf]

> > It may be relatively cheap and easy for *you* to buy a two-year-old
> > system, but I don't believe that in this case you are representative
> > of nearly enough of our users to be a useful example.
> 
> I also find it hard to believe that the majority of our users do not
> have or can not purchase a system that is less than 7 years old. Being
> that is how old the i686 sub-arch is... I once attempted to install
> Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the
> least. Machines old enough to be before i686 are probably also old
> enough to be barely usable as a desktop, especially since ram prices
> back then were still quite high (~ $40/MB iirc), and disk sizes quite
> small (2GB HD was $300 in 1996). What are the theoretical binary-only
> apps that these desktops would be using, whizbang 3d games, multimedia
> players, or something else? A reduced size 386-586 arch wouldn't be bad
> for a server, which imho is about all machines that old are really good
> for anyway. (And no Manoj I am not attempting to troll with this post...)

I agree, the vast majority of our users can afford newer machines. So, I
think we should drop m68k, mips and other similar unfashionable old
archs, don't you think? The majority of our users will be happy...

I would not do that. First of all, many of us do have quite old and
useful machines. Lots of people use 386/486 machines as home gateways -
even mission-critical gateways at the office, those machines are still
enough to handle E1 level traffic. And... Well, at my gateway at home
(i486) I have Samba, Bind and Apache running - And quite smoothly.

If we have to split somehow what should be supported for i386-old and
what should require i386-fast, we will find out many users who found a
creative use for their old hardware. Debian is about choice - we should
do our best to let the *user* choose what he can and can not do with his
old machine.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Bug#190909: ITP: libxml-libxml-common-perl -- Perl module for common routines & constants for XML::LibXML et al

[Glenn Maynard]

On Sat, Apr 26, 2003 at 08:35:56PM -0500, Ardo van Rangelrooij wrote:
> * Package name: libxml-libxml-common-perl

I'm sure you're just being consistent, or conforming with policy, but
these "libxml-libxml" package names look almost as absurd as binutils
"2.13.90.0.18-1.7 Super Turbo Edition" versioning ...

-- 
Glenn Maynard

Re: i386 compatibility & libstdc++

[Gunnar Wolf]

> > >>> 1a. create a stripped down version for i386, i.e. required/important
> > >>> and go for i486.
> > >> Is there much performance improvement in dropping i386 in favour of 
> > >> i486+?
> > 
> > > - Integrated math coprocessor ( why does libc still check for its
> > > availability? ) [...]
> > 
> > 486SX.
> 
> I thought that in-kernel emulation would have solved the gap between 486
> DX and SX.

For practical purposes, yes... Although emulated FP is really, REALLY
slow. I installed a machine to be a X terminal about two years ago -
386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a
similarly-configured machine with a hardware FP unit, to the point of
deciding it would be a text terminal, with no X :)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgp331Hzham4J.pgp
Description: PGP signature

Re: i386 compatibility & libstdc++

[Bart Trojanowski]

* Gunnar Wolf <[EMAIL PROTECTED]> [030426 22:29]:
> > > >>> 1a. create a stripped down version for i386, i.e. required/important
> > > >>> and go for i486.
> > > >> Is there much performance improvement in dropping i386 in favour of 
> > > >> i486+?
> > > 
> > > > - Integrated math coprocessor ( why does libc still check for its
> > > > availability? ) [...]
> > > 
> > > 486SX.
> > 
> > I thought that in-kernel emulation would have solved the gap between 486
> > DX and SX.
> 
> For practical purposes, yes... Although emulated FP is really, REALLY
> slow. I installed a machine to be a X terminal about two years ago -
> 386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a
> similarly-configured machine with a hardware FP unit, to the point of
> deciding it would be a text terminal, with no X :)

I agree completely -- in todays world of CPU's capable of many millions
of FP operations/s you really don't want a 486SX.  

However, in the context of our conversation it makes no difference that
the performance sucks.  A 486 is a 486 as far as a Debian package is
concerned.  We don't need to consider the 486SX when deciding where the
architecture split should be.

B.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgpFlLXGMqJ8E.pgp
Description: PGP signature

debian.org machine with pbuilder/debootstrap?

[Hamish Moffatt]

I'd like to test some build-deps using pbuilder, but don't have the
bandwidth locally to set up/maintain it. Do any of the debian.org
machines have pbuilder/debootstrap installed? I tried a few but couldn't
spot one.

Many have chroots but don't tend to have the relevant build-deps
installed.

Thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Bug#190909: ITP: libxml-libxml-common-perl -- Perl module for common routines & constants for XML::LibXML et al

[Ardo van Rangelrooij]

Glenn Maynard ([EMAIL PROTECTED]) wrote:
> On Sat, Apr 26, 2003 at 08:35:56PM -0500, Ardo van Rangelrooij wrote:
> > * Package name: libxml-libxml-common-perl
> 
> I'm sure you're just being consistent, or conforming with policy, but
> these "libxml-libxml" package names look almost as absurd as binutils
> "2.13.90.0.18-1.7 Super Turbo Edition" versioning ...

Well, it's not completely out of the blue: XML::LibXML is a Perl wrapper
around libxml2, just as XML::LibXSLT is around libxslt and XML::GDOME
is around libgdome2.  libxml2 is the base library for these other lib*,
and so it does make sense to name the common module XML::LibXML::Common.
And for the Debian package name we put lib in front and -perl at the
end, and make it all lowercase (all per Perl Policy and general Policy).

But since it's just a base module, hardly any user would have to deal
with this package directly, since the new version of XML::LibXML will
automagically pull the common package on the system.

Thanks,
Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
GnuPG fp:   3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Bug#190913: ITP: konqueror-embedded -- A small version of the Konqueror web browser

[Gunnar Wolf]

Package: wnpp
Version: unavailable; reported 2003-04-26
Severity: wishlist


* Package name: konqueror-embedded
  Version : 20021229_snapshot
  Upstream Author : Simon Hausman <[EMAIL PROTECTED]>, Paul Chitescu <[EMAIL 
PROTECTED]>
* URL : http://www.konqueror.org/embedded/
* License : GPL
  Description : A small version of the Konqueror web browser

The Konqueror/Embedded project attempts to build up a special version of
the web browsing component of the KDE browser Konqueror (in particular
its html rendering engine khtml and its io subsystem).
Konqueror-embedded runs as one static binary, being as small as possible
while still providing all essential features of a web browser, including

* HTML4
* CSS
* JavaScript
* Cookies
* SSL
* Non-blocking IO
* Builtin Image Viewer
* IPv6 support
* Full xbel compatible bookmark
* support and management

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux jerx 2.4.20jerx #1 Wed Mar 26 09:50:22 CST 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Bug#190912: ITP: konqueror-embedded -- A light version of the Konqueror web browser for use in small machines

[Gunnar Wolf]

Package: wnpp
Version: unavailable; reported 2003-04-26
Severity: wishlist


* Package name: konqueror-embedded
  Version : 20021229_snapshot
  Upstream Author : Simon Hausman <[EMAIL PROTECTED]>, Paul Chitescu <[EMAIL 
PROTECTED]>
* URL : http://www.konqueror.org/embedded/
* License : GPL
  Description : A light version of the Konqueror web browser for use in 
small machines

The Konqueror/Embedded project attempts to build up a special version of
the web browsing component of the KDE browser Konqueror (in particular
its html rendering engine khtml and its io subsystem).
Konqueror-embedded runs as one static binary, being as small as possible
while still providing all essential features of a web browser, including

* HTML4
* CSS
* JavaScript
* Cookies
* SSL
* Non-blocking IO
* Builtin Image Viewer
* IPv6 support
* Full xbel compatible bookmark
* support and management

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lactop 2.4.20dellactop #1 Fri Mar 7 18:47:37 CST 2003 i686
Locale: LANG=C, LC_CTYPE=C

[Debian-Lex] Interview with subproject leader

[Jeremy Malcolm]

[Most of the discussion on the Debian-Lex proto-subproject has been
off-list, so I'm sending this one to the list so that people can see
something of our progress.  These answers will be made into an article
by Matt Black at some point after we get an official list and Web area.]

On Sun, 2003-04-27 at 10:07, Matt Black wrote:

> * Tell me a about yourself / your background.

I'm from Perth, Western Australia, where I work both as a lawyer
specialising in information technology law, and as the manager of an IT
consultancy.  Having one foot in the IT field and another in the IT
world is helpful because these areas cross over in much of the work that
I do.  For example, I fought a prominent legal case against a spammer
last year in which my IT knowledge proved useful, and my legal knowledge
is often useful when my IT consultancy provides services to law firms. 
I've been using Debian GNU/Linux for about eight years, and both arms of
my business now use it exclusively.

> * What is Debian?

Debian aims to be a universal operating system, that is free to
distribute and develop.  Debian is available for numerous types of
computer system, but its most widely used variant is based around the
Linux operating system kernel and runs on ordinary PC hardware.  It is,
if you like, an alternative for Microsoft Windows, but with the
advantage of having many thousands of software packages bundled with it,
all of which are free to use and to extend.

> * What is Debian-Lex?

Debian-Lex is project to create a subset of Debian that will provide a
pre-configured operating system designed specifically for use in legal
practice.  Our aim is that Debian-Lex will not only sit on lawyers'
desktops, but also be found in their accounts departments, on their
office servers, and be used in court registries.  Debian-Lex is not a
competitor to Debian, as everything that goes into Debian-Lex will go
straight into Debian also.  It will, however, make it easier to install
a Debian GNU/Linux system that is tuned to the requirements of a legal
practice.

> * Who are the people behind Debian and Debian-Lex?

The Debian project is quite unique in that it comprises over a thousand
participants from all around the world, ranging from software engineers
to documentation maintainers, all of whom are unpaid for the work they
contribute to the project (although some are sponsored by their
employers).  Debian-Lex, being a sub-project of Debian, is being
developed by some of these same volunteers, so far including three
qualified lawyers.  Anyone is welcome to apply to join the project, so
long as they share our ideals of collaboratively developing a free
operating system.

> * What advantages will Debian-Lex bring to lawyers and law firms?

There are hundreds of proprietary software packages designed for
lawyers, to fulfil their specialist needs for time recording, trust
accounting, and client and matter management.  Most of these packages do
not interoperate with each other, and still less frequently can the
packages in use by one firm exchange information seamlessly with
packages in use by another firm, or those in use by a court.  One of our
main aims for Debian-Lex is to increase interoperability of legal
software.  

> * What kind of specialist software will be available in Debian-Lex?

We hope to provide a framework for various software packages to access
and maintain a central database of client and matter information.  One
of these will be a sophisticated multi-user accounting package, another
is a desktop time recording package, and a third is the well-renowned
Microsoft Office-compatible office suite, OpenOffice.org.  On a more
obscure note, we will have a tool to check for conflicts of interest,
and various tools to search and manipulate legal transcripts and
pleadings.

> * With the importance that attaches to legal proceedings, shouldn't lawyers 
> be 
> willing to pay for the best rather than preferring free software?

Often free software (or open source software) is the best available. 
This is so because it can draw on the talents of a much wider community
of developers than proprietary software.  Moreover, if a software tool
does not meet the needs of its users, they have free access to the
source code which enables them to modify it to suit their requirements,
or to pay a software developer to do so.  Many lawyers have been caught
out when support for specialised proprietary software they are using has
been withdrawn by its developer, or the developer has gone out of
business.  The use of free, open source software reduces this concern.

> * When will Debian-Lex be 'released'?

That all depends on how many contributors decide to collaborate on it! 
The Debian project at large does not have a fixed timeline for its
releases, and Debian-Lex follows the same policy.  We expect that a
full, working operating system pre-configured for lawyers will be
available if not by the time of the next official Debian release, then
by the time of th