ITP: libtext-charwidth-perl, libtext-wrapi18n-perl

[Tomohiro KUBOTA]

Hi,

(Please Cc: me.)

I'd like to upload these two Perl modules.  Though I wrote these modules
myself to be used by debconf, I will upload these modules to CPAN and
these packages won't be debian-specific package.

See a thread of discussion in debian-i18n list starting from:
http://lists.debian.org/debian-i18n/2003/debian-i18n-200306/msg00012.html


Package: libtext-charwidth-perl
Description: Get width of characters on terminal
 This module permits perl softwares to get the width of characters
 and strings on terminal, using wcwidth() and wcswidth() in C.
 .
 It provides mbwidth(), mbswidth(), and mblen().
License: perl


Package: libtext-wrapi18n-perl
Description: International substitution of Text::Wrap
 This module intends to substitute Text::Wrap, which supports
 multibyte characters such as UTF-8, EUC-JP, and GB2312, fullwidth
 characters such as east Asian characters, combining characters
 such as diacritical marks and Thai, and languages which don't
 use whitespaces between words such as Chinese and Japanese.
 .
 It provides wrap().
License: perl


Since these packages have to be Depends:ed by debconf package,
Priority: of these packages have to be important.  (Joey and I
have agreed on this point, please see the debian-i18n thread.)

Test releases (needing brush-up) are already available at
http://www.debian.or.jp/~kubota/mojibake/debconf

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/

Bug#198260: ITP: streamtuner -- A GUI audio stream directory browser

[Ari Pollak]

Package: wnpp
Version: unavailable; reported 2003-06-20
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: streamtuner
  Version : 0.9.1
  Upstream Author : Jean-Yves Lefort <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/streamtuner
* License : GPL
  Description : A GUI audio stream directory browser

 Streamtuner is a stream directory browser. It offers an
 intuitive and unified interface to various streaming
 directories through the use of a plugin system.
 
 Current plugins included in this package are:
 - SHOUTcast

 More information and plugins can be found at:
 

- -- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux darth 2.4.21 #1 Fri Jun 13 20:06:05 EDT 2003 i686
Locale: LANG=C, LC_CTYPE=C

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+87QbwO+u47cOQDsRAtF9AJ9hhpKwb+pXDOIhQHdAwVztXedpZwCgg939
DnQA/buvr5U+6pzsttFTIoA=
=PZTZ
-END PGP SIGNATURE-

Re: Advice needed : Oracle and Debian Linux

[Kevin Kreamer]

Michael Meskes <[EMAIL PROTECTED]> writes:
> On Fri, Jun 20, 2003 at 12:53:34AM +1000, Russell Coker wrote:
>> As for the support people, I don't think that necessarily makes it 
>> impossible.  
>> If you started up a company to produce a commercial distribution based on 
>> Debian for running Oracle then having your people answer the phones at 
>> Oracle 
>> would be good for business...
>
> Not really. These people are on your pay roll but do not generate any
> revenue. So you have to have a lot of people busing this distro to run
> Oracle to make it work. 

If you charge per incident or such, then those people would generate
revenue.  Also, the ability to advertise that you have people at
Oracle answering questions could help generate revenue as well.

Basically, the assumption is that you would construct your business
plan so that it was good for business :-)

Kevin



pgphz6BJiSkod.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Sam Hocevar]

On Fri, Jun 20, 2003, Sebastian Kapfer wrote:

> > Also P MMX seems meaningless to me. MMX was, I think, introduced in
> > Pentium Pro (which is still a i586 according to uname)
> 
> Really? Seems wrong to me.

   Indeed. MMX and PPro are orthogonal features.

-- 
Sam.

Bug#198158: architecture i386 isn't i386 anymore

[Josselin Mouette]

Le ven 20/06/2003 à 15:39, Mathieu Roy a écrit :
> Skipping 386 for 486 seems acceptable because nowadays, a distro
> requires more HD space and RAM than it's possible to add with usual
> 386 motherboards, but dropping all Pentiums until Pentium II
> generation seems completely foolish. I hope I misunderstood your
> message.

A 486 is still pretty usable for a server or an X terminal nowadays, so
dropping it would be much more harmful than dropping.
Furthermore, the difference in performance between 486 and 586 is
ridiculous, while the 386->486 move gives appreciable gains.

There is absolutely no reason to drop i486, this is nonsense.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Bug#198158: architecture i386 isn't i386 anymore

[Sebastian Kapfer]

On Fri, 20 Jun 2003 23:40:13 +0200, Cyrille Chepelov wrote:

>> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
>> would count...
> 
> Hmmm. Until all of glibc, the kernel and gcc deprecate and discard
> support for 386 and 486,

One of them is enough to be a showstopper.

> I'd love if I could keep my home edgge router running the way it is
> thank you very much (and I'm happy with the great job the Security Team
> is doing). Not that the flea market value of a Pentium Classic is that
> high nowadays, but why fix what works? I thought Free Software was above
> planned obsolescence...

Sure it's nice when you can use old hardware until it breaks, not until
company XYZ wants to charge for new licenses.

> (note that if there is a compelling technical reason for forking i386
> into i386-proper and i686, I'm happy with it. Have you seen it? I
> haven't so far.)

IANAIAP (I am not an i386 assembler programmer), but if the illegal
instruction workaround which was proposed in this thread _does_ work, it
would probably turn out to be the best solution. Makes your old box run
Quake 3 ;-) and the guys running a 486+ kernel won't need to pay for it.
Would it hurt the i386's performance too hard?

A general solution to the problem would be nice. I don't know about other
arch's, but Intel and AMD are inventing new instructions faster than new
processor designs. Makes me wonder how a multi-architecture distro like
Debian is supposed to handle that. Is there something like automatic
detection of the "best" codepath given the limitations of the current CPU?
Not sure what effect something like that would have on binary sizes and
build times though...

(And no, I'm not demanding P4-optimized word processors here! Optimization
has to be restricted to packages where it really speeds up things.)

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Bug#198158: architecture i386 isn't i386 anymore

[Theo Cabrerizo Diem]

We run lot of P100 and P233 with hostap to provide internet access to
our customers with 2.4Ghz wi-fi. And some customers have P200,233MMX as
firewalls/mail servers/proxy.

I think 386 boxes are really slow ... and the admins of that boxes
 have faster boxes to build specific packages.. but maybe
not ability to rebuild all base packages and apt/dpkg/libs itself.

But 486's DX (DX-50/DX2-66/DX4-100) and 586's are faster boxes to do
something with them .. and inexpensives to put in a roof of building ..
and being hit by storms =)  and don't have another boxes to rebuild
all packages.

Just my 2 cents

[]'s


On Fri, 2003-06-20 at 10:45, Stephen Stafford wrote:
> On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> > On Fri, 20 Jun 2003, Stephen Stafford wrote:
> > > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > > > What about perusing the INT 6 idea, and going all the way up to i686?
> > > While I support the removal of 386 support, I absolutely and strenuously
> > > object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> > > use a nunber of 4/586 machines still (I have one 486 which I use for
> > > embedded development and 3 P100 boxen which are used for various things 
> > > like
> > > CVS server, gateway/firewall, testing various things).
> > Note that my idea was about patching the kernel that so the newer opcodes 
> > would be emulated in software.  Everything would still work even on a 386, 
> > just slower -- and the speed decrease can be removed by running apt-build.
> 
> I'm still not convinced.  Your argument works just as well in reverse.  If
> people running >=686 want to they are perfectly capable of building the
> packages to take advantage of it themselves, and FAR more able to afford the
> computrons to do so (recompiling most of a system on a 486 will never be my
> idea of fun...on (say) a 1GHz machine, it's far easier to do)
> 
> I'm also still not convinced of the usefulness of these optinisations per
> architecture at non-high loads.  I submit that a 486 is FAR more likely to
> be running at high load than a 1GHz machine.  The 486 can far less afford
> the performance hit from emulating instructions in software than a 1GHz
> machine can by not having the small optimisations built by default.
> 
> This basically comes down to "will a significant portion of our userbase
> suffer if we do this?"  Personally I think the answer is "yes".  You
> obviously have a different viewpoint here :)
> 
> Cheers,
> 
> Stephen
> 

Re: Bug#198158: architecture i386 isn't i386 anymore

[Mathieu Roy]

Cyrille Chepelov <[EMAIL PROTECTED]> a tapoté :

> Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit:
> 
> > > but dropping all Pentiums until Pentium II generation
> > > seems completely foolish. I hope I misunderstood your message.
> > 
> > I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> > would count...
> 
> Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support
> for 386 and 486, I'd love if I could keep my home edgge router running the
> way it is thank you very much (and I'm happy with the great job the Security
> Team is doing). Not that the flea market value of a Pentium Classic is that 
> high nowadays, but why fix what works? I thought Free Software was above 
> planned obsolescence...

RedHat provide glibc for i386, i586 and i686. Why doesn't Debian
provide several packages for i*86 when the package can be optimized a
lot depending on the CPU type? 

Hard disk space on the pool?

Someone mentionned gstreamer, telling it uses optimization included
in i586. Why not, for this package, at the option of the maintainer,
provide gstreamer*.i386 and gstreamer*.i586 in the pool?
A user that try "apt-get/aptitude install gstreamer" with a computer
=< i586 will get the optimized package, the others will get the legacy 
package.

It may creates extra works but this way Debian can keep a wide 
support of i386 (asked by some people on that thread) while providing
optimized binaries for people that run recent hardware (asked by some
on people on that thread too).


-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Brian Nelson]

Javier FernÃndez-Sanguino PeÃa <[EMAIL PROTECTED]> writes:

[...]
> I was wondering, should I make a mass filing of bugs for those packages 
> who fail to produce a proper description? 
>
> I would probably first do so for the packages whose short description =
> long description or who do not have a description at all and would review
> which of the "one liners" do not provide sufficient information.

That sounds sane enough to me.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpydGNseIUr0.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Cyrille Chepelov]

Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit:


> > but dropping all Pentiums until Pentium II generation
> > seems completely foolish. I hope I misunderstood your message.
> 
> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> would count...

Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support
for 386 and 486, I'd love if I could keep my home edgge router running the
way it is thank you very much (and I'm happy with the great job the Security
Team is doing). Not that the flea market value of a Pentium Classic is that 
high nowadays, but why fix what works? I thought Free Software was above 
planned obsolescence...

(note that if there is a compelling technical reason for forking i386 into
i386-proper and i686, I'm happy with it. Have you seen it? I haven't so far.)

-- Cyrille

-- 

Re: Bug#198158: architecture i386 isn't i386 anymore

[Colin Walters]

On Fri, 2003-06-20 at 13:15, Sebastian Kapfer wrote:

> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
> would count...

Making the cut at the Pentium as opposed to i486 would have some
benefits; the Pentium introduced some new instructions such as cmpxchg8b
that are actually used by some software, e.g. gstreamer.

Re: Bug#198158: architecture i386 isn't i386 anymore

[Matt Zimmerman]

On Fri, Jun 20, 2003 at 01:58:08PM -0500, Adam Heath wrote:

> On Fri, 20 Jun 2003, Matt Zimmerman wrote:
> > They will if they want security updates for their firewall.
> 
> You mean debian provided security updates.  Users can always upgrade and
> compile software themselves.

Judging by the volume of whining about potato, I estimate there are very few
users willing to do this work themselves.

-- 
 - mdz

Re: Bug#198158: architecture i386 isn't i386 anymore

[Adam Heath]

On Fri, 20 Jun 2003, Matt Zimmerman wrote:

> On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
>
> > >1918space and are masqueraded to the outside internet by a firewall/gateway
> > >running Debian on a 486 or low end pentium.  I believe this to be a fairly
> > >significant proportion of our userbase and I'd oppose any move to
> > >marginalise them like this.
> >
> > You will upgrade these router to sarge o newer distributions?
>
> They will if they want security updates for their firewall.

You mean debian provided security updates.  Users can always upgrade and
compile software themselves.

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Daniel Burrows]

On Fri, Jun 20, 2003 at 05:53:09PM +0200, Javier Fernández-Sanguino Peña 
<[EMAIL PROTECTED]> was heard to say:
> I was wondering, should I make a mass filing of bugs for those packages 
> who fail to produce a proper description? 

  Yes, please!

  Daniel

Re: not modified modifications

[Branden Robinson]

On Thu, Jun 19, 2003 at 04:59:00PM -0400, Matt Zimmerman wrote:
> On Thu, Jun 19, 2003 at 12:36:49AM +0200, Bernd Eckenfels wrote:
> 
> > i am very sure, I did never have touched this file, so why is dpkg always
> > asking me if i want to overwrite it? IS this a dpkg problem, is it a
> > packaging problem, or is is a script which is modifying those files?
> 
> I believe this happens when a conffile moves from one package to another, is
> renamed, or a configuration file switches to being a conffile when it was
> previously not.

It can also happen in the perverse case where a package has a file
marked as a conffile for a while, is then upgraded to a version that
doesn't ship the file at all, then later starts to have the conffile
again and is upgraded.

In other words, obsolete conffiles, even unmodified ones, are not purged
on upgrade.

-- 
G. Branden Robinson| One doesn't have a sense of humor.
Debian GNU/Linux   | It has you.
[EMAIL PROTECTED] | -- Larry Gelbart
http://people.debian.org/~branden/ |


pgpgITytu1lFf.pgp
Description: PGP signature

Re: aptitude borked [was: Re: Fun with python-apt]

[Daniel Burrows]

  Have you tried "dpkg --remove apt-listchanges" or
"dpkg --purge apt-listchanges"?

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   "You see, I've already stolen the spork of wisdom |
|and the spork of courage..  together with the spork  |
|of power, they form the mighty...TRI-SPORK!" -- Fluble   |
\-- Does your computer have Super Cow Powers? --- http://www.debian.org --/

Re: Bug#198158: architecture i386 isn't i386 anymore

[Sebastian Kapfer]

On Fri, 20 Jun 2003 17:20:13 +0200, Mathieu Roy wrote:

> If so, are you kidding? The Pentium classic (i586) was still available
> in 1997.

It is still available even today. Not sure where to get a mainboard for
this beast, but just a week ago I saw it on a price list.

> I know a lot of person who use a Pentium classic as mini-server, with is
> really enough to run a local network.
> 
> Also P MMX seems meaningless to me. MMX was, I think, introduced in
> Pentium Pro (which is still a i586 according to uname)

Really? Seems wrong to me.

> and nowadays computers still got MMX (so what is the meaning of P MMX?
> PPro? PII? PIII? PIV?).

MMX was introduced with the Pentium/MMX (P55C) processor. That's a Pentium
(i586) with MMX bolted on. PPro (P6, i686) doesn't have MMX (being
introduced before the Pentium MMX). PII united the two designs. It
features a PPro core _and_ MMX. So I guess the meaning of P MMX is pretty
clear. It refers to the classic Pentium with MMX.

> Skipping 386 for 486 seems acceptable because nowadays, a distro
> requires more HD space and RAM than it's possible to add with usual 386
> motherboards,

You could always burn a CD-ROM for /usr :-)

> but dropping all Pentiums until Pentium II generation
> seems completely foolish. I hope I misunderstood your message.

I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
would count...

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Bug#198158: architecture i386 isn't i386 anymore

[Matt Zimmerman]

On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:

> >1918space and are masqueraded to the outside internet by a firewall/gateway
> >running Debian on a 486 or low end pentium.  I believe this to be a fairly
> >significant proportion of our userbase and I'd oppose any move to
> >marginalise them like this.
> 
> You will upgrade these router to sarge o newer distributions?

They will if they want security updates for their firewall.

-- 
 - mdz

Bug#198158: architecture i386 isn't i386 anymore

[Andreas Barth]

* Stephen Stafford ([EMAIL PROTECTED]) [030620 15:35]:
> Judging from my random contacts with users, it's a fairly usual setup to see
> a network of higher (500Mhz+) end hardware machines which sit on a LAN in
> 1918space and are masqueraded to the outside internet by a firewall/gateway
> running Debian on a 486 or low end pentium.  I believe this to be a fairly
> significant proportion of our userbase and I'd oppose any move to
> marginalise them like this.

Well, the key problem is: debian doesn't properly support the way
i386+ is constructed. That does also make problems for amd64.

It would be really nice to be able to just put (additional) i686- (or
64bit-)optimized binaries in place where they are usefull, but only
there and without doubling every binary.

An possible way is: split i386 into subarchitectures i386-[subtype]
and a plain i386, where subtype is one of i486, i586, i686,  For
every subtype there is a list what subtypes are acceptable in addition
to plain i386 to install (so a i386-i686 would also install i386-i486
and i386-i586 packages). At creating the debian packages, normally
(also with Architecture: any) only the plain i386 packages are
created. If it is usefull to generate also packages for one or more
subtypes they must be specified explizitly at the Architecture line.

This way would also have the advantage that the existing mmx, 3dnow,
... packages (that are really just making the package list larger
without adding content) can be removed. 


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: aptitude borked [was: Re: Fun with python-apt]

[Aaron M. Ucko]

"David A. Greene" <[EMAIL PROTECTED]> writes:

> guarantee it will work because it seems as though apt thinks
> apt-listchanges is still installed.

This is a matter of configuration files; try purging apt-listchanges,
and if that doesn't work remove /etc/apt/apt.conf.d/20listchanges
yourself.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: aptitude borked [was: Re: Fun with python-apt]

[Matt Zimmerman]

On Fri, Jun 20, 2003 at 10:27:14AM -0400, David A. Greene wrote:

> Matt Zimmerman wrote:
> 
> >If you had wanted to find out the answer before sending this to
> >debian-devel, you would not have had to look very far.
> >bugs.debian.org/python-apt has the answer three times over.
> >
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566
> 
> That's not particularly helpful.  Consider my situation:
> 
> # aptitude dist-upgrade
> [...]
> 67 packages upgraded, 46 newly installed, 0 to remove and 39 not upgraded.
> Need to get 0B/106MB of archives. After unpacking 55.0MB will be used.
> Do you want to continue? [Y/n/e/d/v/action/?] y
> Writing extended state information... Done
> /bin/sh: line 1: /usr/bin/apt-listchanges: No such file or directory
> E: Failure running script /usr/bin/apt-listchanges --apt || test $? -ne 10
> Ack!  Something bad happened while installing packages.  Trying to recover:
> Reading Package Lists... Done
> Building Dependency Tree
> Reading extended state information... Done

Again, the answer to your problem lies in the bug tracking system, and this
time, the bug is already fixed:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=89830&archive=yes

In apt 0.5.5+ this should no longer be a problem.  You can also work around
this by purging apt-listchanges, instead of just removing it.

-- 
 - mdz

Re: Advice needed : Oracle and Debian Linux

[Michael Meskes]

On Fri, Jun 20, 2003 at 12:53:34AM +1000, Russell Coker wrote:
> As for the support people, I don't think that necessarily makes it 
> impossible.  
> If you started up a company to produce a commercial distribution based on 
> Debian for running Oracle then having your people answer the phones at Oracle 
> would be good for business...

Not really. These people are on your pay roll but do not generate any
revenue. So you have to have a lot of people busing this distro to run
Oracle to make it work. 

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

[mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Javier Fernández-Sanguino Peña]

Policy section 2.3.3 states:

 The description should be written so that it gives the system
 administrator enough information to decide whether to install the
 package.

However I've found a number of packages which use a long description which 
is more or less the _same_ as the short description. Sample:
$ apt-cache show kdebase-data
(...)
Description: KDE Base (shared data)
 KDE Base (shared data).
 .
 This package is part of the official KDE base module.

And some (2) others which do not provide an extended description at all or 
provide an extended description of only one line. I've used an ugly scripts 
(attached) which produces ugly results (attached too).

I was wondering, should I make a mass filing of bugs for those packages 
who fail to produce a proper description? 

I would probably first do so for the packages whose short description =
long description or who do not have a description at all and would review
which of the "one liners" do not provide sufficient information.

Regards

Javi




results.txt.gz
Description: Binary data


find-wrong-descript.pl
Description: Perl program


pgpC1RlU2LIwJ.pgp
Description: PGP signature

Re: not modified modifications

[Adam Heath]

On Thu, 19 Jun 2003, Matt Zimmerman wrote:

> On Thu, Jun 19, 2003 at 12:36:49AM +0200, Bernd Eckenfels wrote:
>
> > i am very sure, I did never have touched this file, so why is dpkg always
> > asking me if i want to overwrite it? IS this a dpkg problem, is it a
> > packaging problem, or is is a script which is modifying those files?
>
> I believe this happens when a conffile moves from one package to another, is
> renamed, or a configuration file switches to being a conffile when it was
> previously not.

Some X package once had a conffile.  Upstream then changed stuff around, and
the package no longer included the conffile.  Then upstream changed again, and
the conffile came back.  Dpkg prompted on this last upgrade, and never said a
thing for the other installs/upgrades(about the conffile no longer being a
conffile).

aptitude borked [was: Re: Fun with python-apt]

[David A. Greene]

Matt Zimmerman wrote:
If you had wanted to find out the answer before sending this to
debian-devel, you would not have had to look very far.
bugs.debian.org/python-apt has the answer three times over.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566
That's not particularly helpful.  Consider my situation:
# aptitude dist-upgrade
[...]
67 packages upgraded, 46 newly installed, 0 to remove and 39 not upgraded.
Need to get 0B/106MB of archives. After unpacking 55.0MB will be used.
Do you want to continue? [Y/n/e/d/v/action/?] y
Writing extended state information... Done
/bin/sh: line 1: /usr/bin/apt-listchanges: No such file or directory
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -ne 10
Ack!  Something bad happened while installing packages.  Trying to recover:
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information... Done
# aptitude remove apt-listchanges
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information... Done
Package apt-listchanges is not installed, not removed
[...]
Do you want to continue? [Y/n/e/d/v/action/?] y
Writing extended state information... Done
/bin/sh: line 1: /usr/bin/apt-listchanges: No such file or directory
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information... Done
???
It seems like apt-get might work (it says it will upgrade 100
packages instead of 67) but the 67 are in the apt cache,
I'm on a modem today and I don't have time to download 14MB
of data over a flaky phone line today.  And then there's no
guarantee it will work because it seems as though apt thinks
apt-listchanges is still installed.
Help?
 -Dave
--
"Some little people have music in them, but Fats, he was all music,
 and you know how big he was."  --  James P. Johnson

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Francesco P. Lovergine]

On Thu, Jun 19, 2003 at 05:33:28PM -0400, Anthony DeRobertis wrote:
> 
> On Thursday, Jun 19, 2003, at 06:57 US/Eastern, Francesco P. Lovergine 
> wrote:
> 
> >And surely Debian DOES NOT support
> >non-free (in DFSG sense) software,
> 
> No, but we do support our users who attempt to run it. See clause 1 of 
> the Social Contract.
> 

There will be archived packages for that. Also that is users support IMHO.
Thinking of actively support a dead and buggy library for ever and 
trying to keep it compatible with a modern distro is simply craziness.


-- 
Francesco P. Lovergine

Bug#198158: architecture i386 isn't i386 anymore

[Andreas Rottmann]

Stephen Stafford <[EMAIL PROTECTED]> writes:

> I'm not fully convinced that moving up to full 686 optimisation has that
> many benefits under all but the highest loads anyway (in userspace at least,
> we already have processor specific kernels).  Do you have a link to
> a URL with studies/analysis of this?
>
I just want to mention that also have /lib/iX86 for libraries where
optimization matters (e.g. libssl).

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.

Bug#198158: architecture i386 isn't i386 anymore

[Josip Rodin]

On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> As i686 is already like ten(?) years old,

I was intrigued by this statement and went to look it up.

CPU:Released:
-
80386   1985
80486   1989
Pentium 1993
Pentium Pro 1995

> I would say 99.9% [1] machines that run sarge are 686 and higher
> 
> [1] 90% of statistics are made up on the spot.

Right. I can't say I have many 

Bug#198158: architecture i386 isn't i386 anymore

[Mathieu Roy]

Adam Borowski <[EMAIL PROTECTED]> a tapoté :

> > In any case we need to make clear if we allow 486 optimisation that
> > are not i386 compatible or not.
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machines 
> that run sarge are 686 and higher -- thus, moving to i686-specific 
> optimizations would be good for the vast majority of users (this comes 
> from someone who set up two servers on P MMX two weeks ago :p)
> 
> If speed on archaic machines is an issue, you can always use the
> wonderful piece of software called apt-build.


You said that "if speed on archaic machines is an issue, you can
always use the  wonderful piece of software called apt-build.". You
replied to a message that asked "if we allow 486 optimisation that
 are not i386 are not i386 compatible or not".

It's not a matter of harmless optimisation (nobody will object about
that) but of incompatible optimisation. Are you proposing to make
Debian for i*86 a distribution incompatible with < i686?

If so, are you kidding? The Pentium classic (i586) was still available
in 1997.

I know a lot of person who use a Pentium classic as mini-server, with
is really enough to run a local network.

Also P MMX seems meaningless to me. MMX was, I think, introduced in
Pentium Pro (which is still a i586 according to uname) and nowadays
computers still got MMX (so what is the meaning of P MMX? PPro? PII?
PIII? PIV?).  
And, what do you mean by higher than i686? i64?

Skipping 386 for 486 seems acceptable because nowadays, a distro
requires more HD space and RAM than it's possible to add with usual
386 motherboards, but dropping all Pentiums until Pentium II
generation seems completely foolish. I hope I misunderstood your
message.  


> [1] 90% of statistics are made up on the spot.

90% of meaningless statistics, you mean?


-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> On Fri, 20 Jun 2003, Stephen Stafford wrote:
> > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > > What about perusing the INT 6 idea, and going all the way up to i686?
> > While I support the removal of 386 support, I absolutely and strenuously
> > object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> > use a nunber of 4/586 machines still (I have one 486 which I use for
> > embedded development and 3 P100 boxen which are used for various things like
> > CVS server, gateway/firewall, testing various things).
> Note that my idea was about patching the kernel that so the newer opcodes 
> would be emulated in software.  Everything would still work even on a 386, 
> just slower -- and the speed decrease can be removed by running apt-build.

I'm still not convinced.  Your argument works just as well in reverse.  If
people running >=686 want to they are perfectly capable of building the
packages to take advantage of it themselves, and FAR more able to afford the
computrons to do so (recompiling most of a system on a 486 will never be my
idea of fun...on (say) a 1GHz machine, it's far easier to do)

I'm also still not convinced of the usefulness of these optinisations per
architecture at non-high loads.  I submit that a 486 is FAR more likely to
be running at high load than a 1GHz machine.  The 486 can far less afford
the performance hit from emulating instructions in software than a 1GHz
machine can by not having the small optimisations built by default.

This basically comes down to "will a significant portion of our userbase
suffer if we do this?"  Personally I think the answer is "yes".  You
obviously have a different viewpoint here :)

Cheers,

Stephen

Bug#198158: architecture i386 isn't i386 anymore

[Marcelo E. Magallon]

On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:

 > I would say 99.9% [1] machines that run sarge are 686 and higher --

 Please provide real data that backs this assertion up.

 > moving to i686-specific optimizations would be good for the vast
 > majority of users

 Please provide real data that backs this assertion up.

 Thank you in advance,

 Marcelo

Re: Bug#198190: ITP: upx-ucl-beta -- an efficient live-compressor for executables (beta version)

[Mario Lang]

Peter Makholm <[EMAIL PROTECTED]> writes:

> Robert Luberda <[EMAIL PROTECTED]> writes:
>
>> I intend to package an unstable (beta) version of upx.
>> This version supports compresing of the Linux kernel and thus 
>> can be used by our boot floppies team.
>
> Isn't the kernel already compressed?

It is, using gzip.  upx repacks it using its own
algorithm, which usually results in a kernel about
100kb smaller.

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
> 
> Stephen Stafford wrote:
> 
> >While I support the removal of 386 support, I absolutely and strenuously
> >object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> >use a nunber of 4/586 machines still (I have one 486 which I use for
> >embedded development and 3 P100 boxen which are used for various things 
> >like
> >CVS server, gateway/firewall, testing various things).
> >
> >Judging from my random contacts with users, it's a fairly usual setup to 
> >see
> >a network of higher (500Mhz+) end hardware machines which sit on a LAN in
> >1918space and are masqueraded to the outside internet by a firewall/gateway
> >running Debian on a 486 or low end pentium.  I believe this to be a fairly
> >significant proportion of our userbase and I'd oppose any move to
> >marginalise them like this.
> 
> You will upgrade these router to sarge o newer distributions?
> i think removal of some 486sx will have some advantages (removal of
> software floating point support in kernels/disks..

I fail to see the gain in this.  If you don't need software floating point,
then it isn't used AFAIK.

Although, yes...in principle, I'm happy enough to drop 486sx support if it's
shown to have any real benefits.  I believe we should retain 486dx support
though.

Cheers,

Stephen

Bug#198158: architecture i386 isn't i386 anymore

[David Goodenough]

On Friday 20 June 2003 13:25, Adam Borowski wrote:
> On Fri, 20 Jun 2003, Bill Allombert wrote:
> > On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> > > - drop the i386 support
> >
> > What we have not yet decided is whether we drop i386 support for C++
> > packages or for all packages. If we choose the former, the mini-i386
> > will just need to contain the important C++ packages. If we choose
> > the later, developers can start to activate i486 optimisation in
> > random packages.
>
> Hmm... I'm not sure about this as the last time I used assembler was
> in the times of real mode DOS, but there is a yet another option:
> we can patch the kernel so when an invalid opcode occurs, whatever
> instruction was at CS:EIP gets emulated in software, similar to the
> way i387 emulation is done.
> (arch/i386/kernel/entry.S)
> Of course, this would further slow down the speed demon known as 80386,
> but since (AFAIK) the 486-specific opcodes get used pretty rarely in
> non-kernel code, the performance hit wouldn't be crippling.  And, there
> is no performance hit at all for >386 machines, as no legitimate process
> ever triggers the invalid opcode fault.
>
> > In any case we need to make clear if we allow 486 optimisation that
> > are not i386 compatible or not.
>
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machines
> that run sarge are 686 and higher -- thus, moving to i686-specific
> optimizations would be good for the vast majority of users (this comes
> from someone who set up two servers on P MMX two weeks ago :p)

You are forgetting embedded processors, many of which - in current product - 
are 486, 586 or at best 686 (some are Via C3 which is sort of 686).  So 
while conventional PCs may have moved on, there are a lot of potential
users out there who have not - this way thay do not need fans, do not
need lots of power, and are extreemly reliable.

There are even some 386 processors still be sold out there in the embedded
market.

David

>
> If speed on archaic machines is an issue, you can always use the
> wonderful piece of software called apt-build.
>
> Regards,
>  1KB
>
> [1] 90% of statistics are made up on the spot.
>
> /---\ Shh, be vewy, vewy quiet,
>
> | [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
>
> \---/
> Segmentation fault (core dumped)

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Fri, 20 Jun 2003, Stephen Stafford wrote:
> On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > What about perusing the INT 6 idea, and going all the way up to i686?
> While I support the removal of 386 support, I absolutely and strenuously
> object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> use a nunber of 4/586 machines still (I have one 486 which I use for
> embedded development and 3 P100 boxen which are used for various things like
> CVS server, gateway/firewall, testing various things).
Note that my idea was about patching the kernel that so the newer opcodes 
would be emulated in software.  Everything would still work even on a 386, 
just slower -- and the speed decrease can be removed by running apt-build.

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#198158: architecture i386 isn't i386 anymore

[Giacomo A. Catenazzi]

Stephen Stafford wrote:
While I support the removal of 386 support, I absolutely and strenuously
object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
use a nunber of 4/586 machines still (I have one 486 which I use for
embedded development and 3 P100 boxen which are used for various things like
CVS server, gateway/firewall, testing various things).
Judging from my random contacts with users, it's a fairly usual setup to see
a network of higher (500Mhz+) end hardware machines which sit on a LAN in
1918space and are masqueraded to the outside internet by a firewall/gateway
running Debian on a 486 or low end pentium.  I believe this to be a fairly
significant proportion of our userbase and I'd oppose any move to
marginalise them like this.
You will upgrade these router to sarge o newer distributions?
i think removal of some 486sx will have some advantages (removal of
software floating point support in kernels/disks..
ciao
giacomo

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > In any case we need to make clear if we allow 486 optimisation that
> > are not i386 compatible or not.
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machines 
> that run sarge are 686 and higher -- thus, moving to i686-specific 
> optimizations would be good for the vast majority of users (this comes 
> from someone who set up two servers on P MMX two weeks ago :p)
> 
> If speed on archaic machines is an issue, you can always use the
> wonderful piece of software called apt-build.
>  

While I support the removal of 386 support, I absolutely and strenuously
object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
use a nunber of 4/586 machines still (I have one 486 which I use for
embedded development and 3 P100 boxen which are used for various things like
CVS server, gateway/firewall, testing various things).

Judging from my random contacts with users, it's a fairly usual setup to see
a network of higher (500Mhz+) end hardware machines which sit on a LAN in
1918space and are masqueraded to the outside internet by a firewall/gateway
running Debian on a 486 or low end pentium.  I believe this to be a fairly
significant proportion of our userbase and I'd oppose any move to
marginalise them like this.

I'm not fully convinced that moving up to full 686 optimisation has that
many benefits under all but the highest loads anyway (in userspace at least,
we already have processor specific kernels).  Do you have a link to
a URL with studies/analysis of this?

Cheers,

Stephen

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Fri, 20 Jun 2003, Bill Allombert wrote:
> On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> > - drop the i386 support
> What we have not yet decided is whether we drop i386 support for C++
> packages or for all packages. If we choose the former, the mini-i386
> will just need to contain the important C++ packages. If we choose
> the later, developers can start to activate i486 optimisation in
> random packages.
Hmm... I'm not sure about this as the last time I used assembler was 
in the times of real mode DOS, but there is a yet another option:
we can patch the kernel so when an invalid opcode occurs, whatever 
instruction was at CS:EIP gets emulated in software, similar to the
way i387 emulation is done.
(arch/i386/kernel/entry.S)
Of course, this would further slow down the speed demon known as 80386,
but since (AFAIK) the 486-specific opcodes get used pretty rarely in 
non-kernel code, the performance hit wouldn't be crippling.  And, there
is no performance hit at all for >386 machines, as no legitimate process
ever triggers the invalid opcode fault.

> In any case we need to make clear if we allow 486 optimisation that
> are not i386 compatible or not.
What about perusing the INT 6 idea, and going all the way up to i686?
As i686 is already like ten(?) years old, I would say 99.9% [1] machines 
that run sarge are 686 and higher -- thus, moving to i686-specific 
optimizations would be good for the vast majority of users (this comes 
from someone who set up two servers on P MMX two weeks ago :p)

If speed on archaic machines is an issue, you can always use the
wonderful piece of software called apt-build.
 
Regards,
 1KB

[1] 90% of statistics are made up on the spot.

/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Content rejected.

[spambody]

Content rejected.

Based on an automated review of the content in a message you sent,
the message appears to be unsolicited commercial e-mail or to contain
content that we deem inappropriate for our business environment. The
message has been blocked from delivery.  If you feel you received
this message in error, please forward this message, the address that
you are trying to send to, and any questions to [EMAIL PROTECTED]


Received: from SMTP32-FWD by imail.duda.com
  (SMTP32) id A0A44; Fri, 20 Jun 2003 08:13:37 -0400
Received: from ov7.duda.com [10.1.1.11] by imail.duda.com
  (SMTPD32-7.15) id AA586E01013C; Fri, 20 Jun 2003 08:13:12 -0400
Received: from psmtp.com ([12.158.35.165])
 by ov7.duda.com (SAVSMTP 3.1.0.29) with SMTP id M2003062008130013292
 for <[EMAIL PROTECTED]>; Fri, 20 Jun 2003 08:13:11 -0400
Received: from source ([146.82.138.6]) by exprod6mx25.postini.com 
([12.158.35.251]) with SMTP;
Fri, 20 Jun 2003 05:12:59 PDT
Received: from localhost (localhost [127.0.0.1])
by murphy.debian.org (Postfix) with QMQP
id B79291F437; Fri, 20 Jun 2003 07:05:11 -0500 (CDT)
Old-Return-Path: <[EMAIL PROTECTED]>
Received: from master.debian.org (master.debian.org [146.82.138.7])
by murphy.debian.org (Postfix) with ESMTP id 2E1AA1F3EC
for ; Fri, 20 Jun 2003 06:30:04 
-0500 (CDT)
Received: from debbugs by master.debian.org with local (Exim 3.35 1 (Debian))
id 19TK5j-0007lN-00; Fri, 20 Jun 2003 06:30:03 -0500
Date: Fri, 20 Jun 2003 06:30:03 -0500
From: BugScan reporter <[EMAIL PROTECTED]>
To: debian-devel-announce@lists.debian.org
Subject: Release-critical Bugreport for June 20, 2003
Message-ID: <[EMAIL PROTECTED]>
Reply-To: debian-devel@lists.debian.org, [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.28i
Sender: Debian BTS <[EMAIL PROTECTED]>
X-Debian-Message: RC bugreport check passed
Mail-Followup-To: debian-devel@lists.debian.org
X-Spam-Status: No, hits=-8.3 required=4.0
tests=BAYES_00,USER_AGENT_MUTT
version=2.53-lists.debian.org_2003_04_28
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53-lists.debian.org_2003_04_28 
(1.174.2.15-2003-03-30-exp)
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-devel-announce@lists.debian.org
X-Mailing-List:  
X-Loop: debian-devel-announce@lists.debian.org
List-Post: 
List-Help: 
List-Subscribe: 
List-Unsubscribe: 
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Resent-Date: Fri, 20 Jun 2003 07:05:11 -0500 (CDT)
X-Declude-Sender: [EMAIL PROTECTED] [12.158.35.165]
X-Declude-Spoolname: Dfa586e01013c558a.SMD
X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam.
X-Spam-Tests-Failed: Whitelisted [0]

Re: Bug#198190: ITP: upx-ucl-beta -- an efficient live-compressor for executables (beta version)

[Peter Makholm]

Robert Luberda <[EMAIL PROTECTED]> writes:

> I intend to package an unstable (beta) version of upx.
> This version supports compresing of the Linux kernel and thus 
> can be used by our boot floppies team.

Isn't the kernel already compressed?

-- 
 Peter Makholm |One thing you do is prevent good software from
 [EMAIL PROTECTED] |  being written. Who can afford to do professional
 http://hacking.dk | work for nothing?
   | -- Bill Gates

Bug#198190: ITP: upx-ucl-beta -- an efficient live-compressor for executables (beta version)

[Robert Luberda]

Package: wnpp
Version: unavailable; reported 2003-06-20
Severity: wishlist


Hi,

I intend to package an unstable (beta) version of upx.
This version supports compresing of the Linux kernel and thus 
can be used by our boot floppies team.


* Package name: upx-ucl-beta
  Version : 1.91
  Upstream Author : 
Markus F.X.J. Oberhumer <[EMAIL PROTECTED]>
Laszlo Molnar <[EMAIL PROTECTED]>
* URL : http://upx.sourceforge.net (CVS repository)
* License : GPL
  Description : an efficient live-compressor for executables (beta version)
  .
  This is a beta version of UPX, the advanced executable file compressor.
  .
  Comparing to the stable version (available in upx-ucl and upx-nrv packages),
  this version e.g.:
   - has slightly better compression algorithm
   - supports bootable Linux kernels
   - support playstation exes
  and probably has a lot of known and unknown bugs, so please use it
  only for testing!
  .
  NOTE: This package is based on the UCL library, which is licensed under GPL.


Regards,

Robert

Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.

[Nick Phillips]

On Thu, Jun 19, 2003 at 09:39:30AM -0500, Steve Langasek wrote:

> > > > Well, except that it doesn't actually describe the package well. Maybe 
> > > > insert "FIFO controlled" before "audio player."
> > > 
> > > Or better, "FIFO-controlled", so it doesn't read like a past-tense
> > > sentence fragment about FIFO having controlled an audio player.
> 
> > I have almost a ready package, i just now need a fine short description.
> > The upstream author is not so happy about the FIFO controlled stuff,
> > since it sounds as if using quark is difficult. The main advantages of
> > quark are :
> 
> It's by geeks for geeks, but FIFOs scare the target audience? :-)

FWIW, I think the original short description was fine; it conveys the
attitude that has likely been taken while developing it, which in turn
gives you rather a lot of information about what the end product is
likely to be like.

Far better than any of the alternatives suggested so far, at any rate :-P


Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
It may or may not be worthwhile, but it still has to be done.

Bug#198158: architecture i386 isn't i386 anymore

[Josselin Mouette]

Le ven 20/06/2003 à 10:58, Bill Allombert a écrit :
> What we have not yet decided is whether we drop i386 support for C++
> packages or for all packages. If we choose the former, the mini-i386
> will just need to contain the important C++ packages. If we choose
> the later, developers can start to activate i486 optimisation in
> random packages.
> 
> In any case we need to make clear if we allow 486 optimisation that
> are not i386 compatible or not.

As C++ packages include APT, and even if it is not required, I think it
could be time to declare ourselves completely i386-incompatible.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Bug#198158: architecture i386 isn't i386 anymore

[Bill Allombert]

On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> Package: general
> Severity: serious
> Tags: sarge, sid
> 
> [please don't reassign to any gcc/libstdc++ package]
> 
> The solution I would favour would be:
> 
> - drop the i386 support
> 
> - keep the i386 architecture name
> 
> - let dpkg-architecture output the new configuration string
>   (i.e. i486-linux)
> 
> - if anybody wants to start the mini-i386 architecture, we have to
>   find an architecture name for it.
> 
> changing the dpkg-architecture's ARCH string to i.e. i486 would break
> a lot of build scripts ...

What we have not yet decided is whether we drop i386 support for C++
packages or for all packages. If we choose the former, the mini-i386
will just need to contain the important C++ packages. If we choose
the later, developers can start to activate i486 optimisation in
random packages.

In any case we need to make clear if we allow 486 optimisation that
are not i386 compatible or not.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

Re: rsync in apt sources.list?

[Dan Jacobson]

>> Doing apt-get update just seems to start downloading the Packages.gz
>> even though we just rsynced Packages.
Tim> It could easily be a bug.
Radim> It writes HIT! message there and skip this file, because it is
Radim> up-to-date by rsync.
Next time I will try with http_proxy unset, because I recall with
wwwoffle, a HTTP HEAD causes a GET or something.
Tim> I use apt-proxy now and am happy.
I will investigate if modem user me can use that to relieve the
apt-get update burden needed (to e.g. just upgrade a few KB packages).

Bug#198158: architecture i386 isn't i386 anymore

[Matthias Klose]

Package: general
Severity: serious
Tags: sarge, sid

[please don't reassign to any gcc/libstdc++ package]

Nathanel's summary:
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html

A list of proposals what to do:
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html

Some questions on this topic:
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html


The solution I would favour would be:

- drop the i386 support

- keep the i386 architecture name

- let dpkg-architecture output the new configuration string
  (i.e. i486-linux)

- if anybody wants to start the mini-i386 architecture, we have to
  find an architecture name for it.

changing the dpkg-architecture's ARCH string to i.e. i486 would break
a lot of build scripts ...

comments welcome.

Re: Bug#198125: ITP: gtk-industrial-engine -- Flat-looking GTK engine from Ximian

[Josselin Mouette]

Le ven 20/06/2003 à 00:15, Josselin Mouette a écrit :
> * Package name: gtk-industrial-engine
>   Version : 0.2.26
>   Upstream Author : Owen Taylor <[EMAIL PROTECTED]>
>   Alexander Larsson <[EMAIL PROTECTED]>
>   Christopher Lahey <[EMAIL PROTECTED]>
> * URL : http://ftp.ximian.com/pub/xd2/redhat-9-i386/source/
>   (I will probably make my own tarball available 
>somewhere as it currently includes unrelated stuff
>and is provided only in srpm format.)
> * License : GPL
>   Description : Flat-looking GTK+ engine from Ximian

Sorry, the license is LGPL, not GPL.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Package Lists and Size

[Glenn McGrath]

On Fri, 20 Jun 2003 16:50:46 +1000
Anthony Towns  wrote:

> No, you don't. We've done the maths, incremental --ed style diffs are
> the way to do this: they make for by far the smallest download, and
> minimal archive bloat.

ed style diffs can be a problem in that the same diff can be applied
multiple times without errors, corrupting your original file.

If there was a release number built in the packages file it could be
checked before applying, or else a context or unified diff may be
better.



Glenn

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Francesco P. Lovergine]

On Thu, Jun 19, 2003 at 09:43:23PM +0200, David Weinehall wrote:
> 
> You, and rest of the minority who use libc5 program, can dual-boot
> an older distribution of Debian (say potato) where the programs still
> work. Yes, it can be a hassle, but it works.
> 

Also woody...

-- 
Francesco P. Lovergine

Re: Bug#198125: ITP: gtk-industrial-engine -- Flat-looking GTK engine from Ximian

[Josselin Mouette]

Le ven 20/06/2003 à 08:30, Tobias Wolter a écrit :
> On 2003-06-20T00:15:48+0200 (Friday), Josselin Mouette wrote:
> 
> > Package: wnpp
> > Version: unavailable; reported 2003-06-19
> > Severity: wishlist
> > 
> > * Package name: gtk-industrial-engine
> 
> "gtk-engines" is the common prefix for GTK engine packages, so you
> should use gtk-engines-industrial, IMHO.

This is the source package name, of course the binary will be named
gtk2-engines-industrial.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

versions of -dev packages

[Nikita V. Youshchenko]

Hello.

I am running several systems that are a mix of stable, testing and sid, with
apt preferences set up such that stable is the highest priority, testing
lower than stable, sid lower that testing.

When something from e.g. sid is needed for some reason, I run
 apt-get -t unstable install xxx

This often upgrades library packages also. But often when library package is
upgraded, other packages related to the library (-dev, -doc, ...) stay at
older version. This may or may not cause technical problems, but definitly
is some sort of inconsistency that is really difficult to resolve always by
hands.

Maybe this shoul be resolved by adding appropriate dependences/conflicts to
the packages? E.g. all packages related to the library package should
conflict with any other version of the library package?

Or there should be a way to make apt to upgrade/downgrade all packages built
from the same source at once (whan any package from that source is being
upgraded/downgraded)?

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Aaron Lehmann]

On Fri, Jun 20, 2003 at 02:35:18PM +1200, Philip Charles wrote:
> As long as these doc's exist someone will make money by providing the
> means of reading them, if OOo does not.

That someone is Microsoft.

> IMHO, the problem has been resolved.

Re: Package Lists and Size

[Anthony Towns]

On Sun, Jun 15, 2003 at 01:41:10PM +1200, Corrin Lakeland wrote:
> > So, i think if there .diff's exist, maybe apt-get can patch the
> > Changes into the files on the client, or a small wrapper arround
> > apt-get can do this..
> Goodness, you are the second person to ask for this in a month.  Diff is not 
> suitable since there are many versions the file could be diffed against.  You 
> need rsync, anoncvs, or similar.

No, you don't. We've done the maths, incremental --ed style diffs are
the way to do this: they make for by far the smallest download, and
minimal archive bloat.

Cheers,
aj

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

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgprYfy4mWR3h.pgp
Description: PGP signature

Re: Bug#198125: ITP: gtk-industrial-engine -- Flat-looking GTK engine from Ximian

[Tobias Wolter]

On 2003-06-20T00:15:48+0200 (Friday), Josselin Mouette wrote:

> Package: wnpp
> Version: unavailable; reported 2003-06-19
> Severity: wishlist
> 
> * Package name: gtk-industrial-engine

"gtk-engines" is the common prefix for GTK engine packages, so you
should use gtk-engines-industrial, IMHO.

> I'm not sure I will package the GTK1 stuff, as we have very little Gnome
> software still using it in sid.

If you decide only to package the gtk2 stuff, you might consider using
gtk2-engines-industrial as a name.

-towo
-- 
circa mea pectora multa sund suspiria de tua pulchritudine que me ledunt misere
tui lucent oculi sicut solis radii sicut splendor fulguris lucem donat tenebris



pgpGeuUFOSthb.pgp
Description: PGP signature

Re: docbook kernel docs and debian unstable

[J.H.M. Dassen (Ray)]

AFAICT debian-user would have been a more appropriate place for this.

On Thu, Jun 19, 2003 at 16:25:54 -0400, John F Davis wrote:
> I am trying to read the docs in the Documentation/DocBook directory of a
> linux kernel.
> 
> I do this: make pdfdocs and I get an error about need to install docbook
> style sheets.  I think the error is really because I dont have db2html
> installed.

Install the "docbook-utils" package which contains db2html.

> I noticed that in the docbook-utils directory there is  a program  called
> jw which appears to convert docbook to pdf.  However, this package needs
> jadetex and that will not install.

Sounds like http://bugs.debian.org/183285 which has been fixed in 3.12-5
which made it into the archive during yesterday's dinstall run.

HTH,
Ray
-- 
TV is the worst of both worlds. It's not as good at words as radio is
because the pictures are a distraction which demand attention, and it's not
as good as cinema because the pictures are not nearly as good.
Douglas Adams in http://slashdot.org/article.pl?sid=00/06/21/1217242

Re: Final call for votes for the Condorcet/Cloneproof SSD voting methods GR

[Angus Lees]

At Fri, 20 Jun 2003 13:06:14 +1000, Angus Lees wrote:
> [vote]

i am teh l4mer

-- 
 - Gus