Re: visual c

[Francois Gouget]

On Fri, 28 Dec 2001, Erik Steffl wrote:

> > "Ing. Luis Chávez Romo" wrote:
> > 
> > I am tired of been a windows user. Let me know if there is an easy way
> > to move
> > an aplication developed in visual c to linux.
> 
>   it depends on libraries used, if the libraries are not available for
> linux than it might be quite hard.
> 
>   Another option is to have not entirely native application and use wine
> (kinda ugly but it might help the transition).

   Unless your application only uses the C library, your only solution
to port it to Linux is to use either Wine, then you run the .exe using
Wine, or Winelib, i.e. recompiling it against the Wine libraries.
   The Winelib way requires a bit more work, but will allow you to also
call Unix APIs (may allow for a better integration) and to progressively
migrate your application to a more portable API (although the transition
may not be easy, porting to a new API never is).

To learn more about Wine see the WineHQ web site:

   http://www.winehq.com/
 

--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
 Avoid the Gates of Hell - use Linux.

my.debian.org

[jab]

I was reading through the debian-devel archives, and came away
impressed with the ton of statistics out there for developers. Sure, I
knew my package bugs were online, as is my anonymized
latitude/longitude coordiantes. But I had no idea my karma [1] and
lintian reports [2] are tracked, along with who knows what else.

As a debian developer, I like an easier way to find and keep up with
all the nice reports out there keeeping track of me. I think it would
help myslef and others do a better job if they were more accessable.
One suggestion is a "portal" page in the vein of MyYahoo -- i.e. a web
page generated specifically for me, linking to all those Debian
statistics and reports directly relevant to me.

So the first question (as always) is -- does something like a
developer portal already exist, and if so, where?

Cheers,
Jeff

==

[1] http://master.debian.org/~edd/karma.txt
[2] http://lintian.debian.org/reports/mJeff_Breidenbach.html

Re: visual c

[Erik Steffl]

Francois Gouget wrote:
> 
> On Fri, 28 Dec 2001, Erik Steffl wrote:
> 
> > > "Ing. Luis Chávez Romo" wrote:
> > >
> > > I am tired of been a windows user. Let me know if there is an easy way
> > > to move
> > > an aplication developed in visual c to linux.
> >
> >   it depends on libraries used, if the libraries are not available for
> > linux than it might be quite hard.
> >
> >   Another option is to have not entirely native application and use wine
> > (kinda ugly but it might help the transition).
> 
>Unless your application only uses the C library, your only solution
> to port it to Linux is to use either Wine, then you run the .exe using
> Wine, or Winelib, i.e. recompiling it against the Wine libraries.
>The Winelib way requires a bit more work, but will allow you to also
> call Unix APIs (may allow for a better integration) and to progressively
> migrate your application to a more portable API (although the transition
> may not be easy, porting to a new API never is).
> 
> To learn more about Wine see the WineHQ web site:
> 
>http://www.winehq.com/

  there is also a number of other libraries (for GUI), I don't think you
have to use ms libs, you can use e.g. wxwindows, qt etc..., also, if the
application doesn't have complicated gui the porting might be fairly
easy... (it also depends on how well the app is designed, if the gui is
farily independent of back-end it's much easier to port it).

erik

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Gerhard Tonn]

Hi,
I have changed my mind and will write semi-automatically a bug report for 
each of the packages with severity grave.

I am currently rebuilding the latest version of each of the packages, so that 
a build log for s390 will be available at http://buildd.debian.org/ . I will 
then check that the problem is still there and write a bug report considering 
those who have already answered me.

Regards,
Gerhard

Preparing a Proposal: 3 DD needed for every NEW package

[Lenart Janos]

[Please Cc: to me! (ETOOHIGHVOLUME)]

As you might already have noticed Debian begun to bloat - so many
unneeded, unused, unmaintained(!) packages.
My opinion is that one DD alone couldn't upload NEW package, but he
needs 2 proponent DD who are willing to "give his signature for it".
Just to make it a little more complicated a minimum of 50 word long
justification needed from all the 3 guys (e.g. two proponent DD and the
future maintainer).

Will it work? I hope it will do work, as sponsored packages are usually
in a good manner, even with the rock of needing to wait for the sponsor.
Will it make Debian better? Unfortunately, it won't. It will probably
make it bloating less quick.

Guys. Wake up! The *ONLY* thing that gets some brain-dead geek to use
Debian is Debian's legendary quality. If Debian continue to go on this
way it's quality will be legendary. Only legendary.

Waiting for responses.

-- 
Lenart, Janos
<[EMAIL PROTECTED]>


pgpssLG5f8ffm.pgp
Description: PGP signature

Re: my.debian.org

[Stefano Zacchiroli]

On Sat, Dec 29, 2001 at 12:46:58AM -0800, [EMAIL PROTECTED] wrote:
> As a debian developer, I like an easier way to find and keep up with
> all the nice reports out there keeeping track of me. I think it would
> help myslef and others do a better job if they were more accessable.
> One suggestion is a "portal" page in the vein of MyYahoo -- i.e. a web
> page generated specifically for me, linking to all those Debian
> statistics and reports directly relevant to me.

I fully agree with your need.

Moreover I think that all this reports (or the "portal" if we manage to
create one) should be reported in the debian developer reference, some
of them are reported (like lintians report), but not all (thinks about
all informations about testing, or the MIA related database).

I'm a one-year aged developer and I needed various month time to know
where all this reports resides (and probably still exists some report or
source of information that I does not currently know).

BTW, why madison isn't packaged? We could package it and mention it in
the developer reference.

Cheers.

-- 
Stefano "Zack" Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863
Home Page: http://www.cs.unibo.it/~zacchiro
Undergraduate student of Computer Science @ University of Bologna, Italy
 - Information wants to be Open -


pgpdf60vMez2n.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Bernhard R. Link]

* Lenart Janos <[EMAIL PROTECTED]> [011229 11:32]:
> My opinion is that one DD alone couldn't upload NEW package, but he
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).

Help. What a burocracy! This only keep working maintainers away from
doing more usefull things.  Better make those not maintaining
their packages well filling out some forumla every week. 

> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.

I think it may help more to think of ways to get rid of packages than
making adding more difficult.





Hochachtungsvoll,
  Bernhard R. Link

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Martin Michlmayr]

* Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]:
> I have changed my mind and will write semi-automatically a bug
> report for each of the packages with severity grave.

Don't do this.  There are too many packages involved to file
semi-automatic bugs already and the bugs should not be grave either.
Are you convinced this makes _all_ these packages "unuseable or mostly
so, or causes data loss"?  The issue could appear in code which is
actually not relevant for 90% of users (i.e. severity important).

I suggest you first post a mail desribing this issue to d-d-announce.
Describe exactly why char signedness is a problem and what to do about
it.  Show examples how to fix the code (it's not hard but still..).
Then give the developers some time to actually do something about it.
And _then_ _consider_ filing bugs (by discussing it here again).

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: my.debian.org

[Martin Michlmayr]

* Stefano Zacchiroli <[EMAIL PROTECTED]> [20011229 11:32]:
> BTW, why madison isn't packaged? We could package it and mention it
> in the developer reference.

Because the tool requires the SQL database on pandora and auric.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Bug#126750: klogd should optionally be started from init(8)

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> True, true. However, sysklogd and klogd are logging daemons. They deserve
> some special treatment IMHO.

Even so, starting it from inittab is too much of a kludge.  For one thing,
it means that /etc/init.d/syslogd stop will either not work, or be an
ugly hack that fools around with inittab.

In any case, if the OOM killer has moved onto syslogd, then you've probably
lost control of the box anyway so restarting it is pretty pointless.

> That is not always possible, and sometimes a kernel VM screwup will cause
> it, no?

Why should we set up such ugly work arounds for kernel bugs or incompetent
admins?
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Alex Pennace]

On Sat, Dec 29, 2001 at 11:31:15AM +0100, Lenart Janos wrote:
> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.
> My opinion is that one DD alone couldn't upload NEW package, but he
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).

As far as this proposal applies to free software, how does this serve
the interests of the free software community? (See section 4 of the
Debian Social Contract.) My opinion is this policy is an
unneeded hurdle that needs to be negotiated for new free software
packages, and some free software may be excluded amid cries of
bloat. Then, I argue, we would serve only a subset of the free
software community.

webrt2 packaging, anyone else?

[Sami Haahtinen]

After a while of struggling with issues with time, I've gotten to a
conclusion where I've better hand over the packaging to someone else.

if there is someone who has more time to dedicate to the packaging of
webrt2 (or request-tracker as suggested by the upstream) please let me
know.

Regards, Sami

-- 
  -< Sami Haahtinen >-
  -[ Is it still a bug, if we have learned to live with it? ]-
-< 2209 3C53 D0FB 041C F7B1  F908 A9B6 F730 B83D 761C >-


pgpgvd5OqSyAs.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[martin f krafft]

also sprach Alex Pennace <[EMAIL PROTECTED]> [2001.12.29.1212 +0100]:
> As far as this proposal applies to free software, how does this serve
> the interests of the free software community? (See section 4 of the
> Debian Social Contract.) My opinion is this policy is an
> unneeded hurdle that needs to be negotiated for new free software
> packages, and some free software may be excluded amid cries of
> bloat. Then, I argue, we would serve only a subset of the free
> software community.

it might well provide enhanced quality, but i seriously doubt that
anyone will want to deal with the extra coordination involved. it's a
good idea, just not possible to be realized IMHO.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
always remember you're unique, just like everyone else.


pgpxxAAHn0H0L.pgp
Description: PGP signature

Re: design issues in debian packages

[Kjetil Torgrim Homme]

(sorry about the late reply, holidays, you know :-)

Adam Heath <[EMAIL PROTECTED]> writes:

> On 21 Dec 2001, Kjetil Torgrim Homme wrote:
> 
> > I'd prefer a non-executable file to mean "disable".  This makes it
> > possible to use 0 byte files only (execute bit means yes or no :),
> > although packages should not use this trick.
> 
> But this won't work.  The .$file has to exist in /etc, so it can be
> modified.  It also must be a conffile.  Which means it will exist
> AFTER the package has been removed, but not purged.
> 
> So, this means it must be an executable, that checks for a file that
> exists in the package when it is installed.

Okay.  I thought you'd install .$file in the post remove script.  So
there will be a .$file for most every $file, then?

> > It's all very flexible and nice, but pretty complex and not very
> > intuitive for the enduser.  It might help a little to call .$file
> > something more explicit like .disabled?.$file instead.  (The question
> > mark may be a bad idea, though.)
> 
> I don't find it at all complex.

Of course not, you came up with it :-)

My point is, a normal user will not have read a description of how
this works.  He will find a .$file and have no idea why and how.
Making the filename more self-documenting would help, IMHO.


Kjetil T.

Re: Bug#126750/749: klogd/sysklogd should optionally be started from init(8)

[Marco d'Itri]

On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

 >> What do people think?
 >Go for it. The OOM killer will hit just about anything which is not a kernel
 >thread, and losing syslogd and klogd is a major no-no.
The OOM code is supposed to be fixed in 2.4 kernels.

I still see no reason to consider klogd more important than e.g. sshd.

-- 
ciao,
Marco

Re: webrt2 packaging, anyone else?

[Tollef Fog Heen]

*  (Sami Haahtinen)

| After a while of struggling with issues with time, I've gotten to a
| conclusion where I've better hand over the packaging to someone else.
| 
| if there is someone who has more time to dedicate to the packaging of
| webrt2 (or request-tracker as suggested by the upstream) please let me
| know.

I'd like to take it -- should I just write to the ITP and take over
the packaging?

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: my.debian.org

[Noel Koethe]

On Sam, 29 Dez 2001, [EMAIL PROTECTED] wrote:

Hello,

> As a debian developer, I like an easier way to find and keep up with
> all the nice reports out there keeeping track of me. I think it would
> help myslef and others do a better job if they were more accessable.
> One suggestion is a "portal" page in the vein of MyYahoo -- i.e. a web
> page generated specifically for me, linking to all those Debian
> statistics and reports directly relevant to me.

Just build your own personal page (replace login with your
debian login)



[EMAIL PROTECTED]


 [EMAIL PROTECTED]
http://www.debian.gr.jp/~kitame/maint.cgi?num=srcs&limit=&showpkgs=on&maint=LOGIN
">my packages
http://bugs.debian.org/[EMAIL PROTECTED]">my bugs
http://lintian.debian.org/reports/mYOUR_FULLNAME.html";>lintian 
reports
http://bugs.debian.org/from:[EMAIL PROTECTED]">reported bugs
http://buildd.debian.org/bymaint.php?maint=NAME%20SURNAME%20%3CLOGIN%40debian.org%3E%20";>buildd
http://master.debian.org/~edd/karma.txt";>karma





-- 
Noèl Köthe

Re: Bug#126750: klogd should optionally be started from init(8)

[Bernd Eckenfels]

On Sat, Dec 29, 2001 at 02:40:41AM -0200, Henrique de Moraes Holschuh wrote:
> > You should be trying to avoid OOM situations in the first place.
> 
> That is not always possible, and sometimes a kernel VM screwup will cause
> it, no?

Hmm.. OOM Killer should avoid killing long running root daemons, whats is
speacial on your system that it affects the klogd so often?

If we solve that, then having a perodic process checking for all daemons is
probably better.

On the other hand, having a generic interface to register (move) daemons
from rc.d to inittab would be a nice thing. Because for example sshd is so
critical to me I like to move it to inittab often, too.

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: Preparing a Proposal: 3 DD needed for every NEW package

[Josselin Mouette]

Lenart Janos a écrit :
> 
> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.

I don't think all these packages should be swept out. Unmaintained 
packages that don't have bunches of bugs shouldn't be a problem, for 
example.

A better solution, IMO, would be to evaluate which packages should be 
removed from the archive (and I believe there are not very much). To do 
that, one could consider the orphaned packages that have important bugs, 
ore more than N (define N as you like) normal bugs. A large part of them 
could certainly be replaced by other (maintained) ones. Then, a 
Replaces: field should be added in those packages - or maybe replaces is 
too strong and we would have to add another field.

For the other ones (unmaintained, buggy, AND without replacement), the
users should be clearly informed when installing the, and maybe the
package could be removed from the archive after 2 releases.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'
  `-  Debian GNU/Linux -- The power of freedom


pgpnpV0sRWxCw.pgp
Description: PGP signature

Bug#126883: [ITP]: mozilla-ca-cert -- Mozilla builtin CA certificates' PEM files

[Fumitoshi UKAI]

Package: wnpp
Severity: wishlist

* Package name: mozilla-ca-cert
  Version : 0.9.7 ?
  Upstream Author : mozilla.org
* URL : http://www.mozilla.org/
* License : MPL or GPL
  Description : Mozilla builtin CA certificates' PEM files

Mozilla has several builtin CA certificate, but it can be useful only in 
mozilla for now.  It would be very useful for other OpenSSL enabled
applications, such as w3m-ssl.  This package will provides PEM files
generated from mozilla certdata.txt, install them to /etc/ssl/certs
and probably generate hash symlinks by using c_rehash(1).
So a package using openssl can use /etc/ssl/certs as CApath to verify
SSL peer certificate.

What do you think about this package?  Does it make sense?
If mozilla maintainer or openssl maintainer is interested to provide this
package, I'd like to tell them how to build this package instead of 
building this by myself.

Can we put this package in main?

Any comments?

Thanks,
Fumitoshi UKAI

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Raphael Hertzog]

Le Sat, Dec 29, 2001 at 11:31:37AM +0100, Lenart Janos écrivait:
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).
> 
> Will it work? I hope it will do work, as sponsored packages are usually
> in a good manner, even with the rock of needing to wait for the sponsor.
> Will it make Debian better? Unfortunately, it won't. It will probably
> make it bloating less quick.
> 
> Guys. Wake up! The *ONLY* thing that gets some brain-dead geek to use
> Debian is Debian's legendary quality. If Debian continue to go on this
> way it's quality will be legendary. Only legendary.

Well, the basic idea is not so stupid, but the implementation is not
really great.

I have something better to propose. But it requires a new (long asked)
feature : the ability to subscribe to a "package" (to get its bug logs,
to get mails sent to @packages.debian.org [1]).

- for each ITP, we need at least 2 developers that will maintain the
  package, they both subscribe to the package, one is the official
  maintainer, the other is listed in the Uploaders: field.

- ftpmasters only accepts packages that fullfill this requirement (they
  check that there's someone listed in Uploaders)

In the long run, we'd really need summary mails to be sent to
@packages.debian.org[1] to let people remember that they are
in charge of the packages and to point them where work is needed.

Cheers,

[1]  should really be  ...

PS: Feel free to CC me since I read debian-devel only once a week.
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguer sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: my.debian.org

[Stefano Zacchiroli]

On Sat, Dec 29, 2001 at 01:52:25PM +0100, Noel Koethe wrote:
> > As a debian developer, I like an easier way to find and keep up with
> > all the nice reports out there keeeping track of me. I think it would
> > help myslef and others do a better job if they were more accessable.
> > One suggestion is a "portal" page in the vein of MyYahoo -- i.e. a web
> > page generated specifically for me, linking to all those Debian
> > statistics and reports directly relevant to me.
> 
> Just build your own personal page (replace login with your
> debian login)

This is not the point: you are able to write that page because you know
what link put in it.

The point is to collect all informations about reports in a place that
is well known, easy to know for new developers (i.e. readable in the
developers reference) and kept up to date.

Cheers.

-- 
Stefano "Zack" Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863
Home Page: http://www.cs.unibo.it/~zacchiro
Undergraduate student of Computer Science @ University of Bologna, Italy
 - Information wants to be Open -


pgprHAOG4k0m8.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Bas Zoetekouw]

Hi Lenart!

You wrote:

> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.
> My opinion is that one DD alone couldn't upload NEW package, but he
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).

What problem exactly are you trying to solve here? Why exactly is it a
problem that Debian has so many packages? Which packages do you find
unneeded and unused? A package that may be not useful for you may be
very useful for many others.

I agree with you that the many orphaned packages are a problem, but that
won't be solved by your proposal.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 


pgpbSVLNMfaCZ.pgp
Description: PGP signature

outdated ARM version keeps package from entering testing

[Eric Van Buggenhaut]

Hi my fellown developpers,

I'm the maintainer of crafty, a chess game engine.

Current version of crafty in sid for i386 and other archA's is
18.12-4. Because current version for arm is 17.13-6, crafty doesn't make it
into Woody.

I'd like 18.12-4 to enter Woody before freeze because it fixes some
imortant bugs but ...

1) There's no auto-build of crafty because it's non-free.

2) I was thinking about building it myself but there's no machine
available (debussy.d.o is down - rameau.d.o runs potato)


What am I supposed to do ??

Please CC me.

-- 
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Lenart Janos]

On Sat, Dec 29, 2001 at 03:30:28PM +0100, Bas Zoetekouw wrote:
> You wrote:
> > As you might already have noticed Debian begun to bloat - so many
> > unneeded, unused, unmaintained(!) packages.
> > My opinion is that one DD alone couldn't upload NEW package, but he
> > needs 2 proponent DD who are willing to "give his signature for it".
> > Just to make it a little more complicated a minimum of 50 word long
> > justification needed from all the 3 guys (e.g. two proponent DD and the
> > future maintainer).
> unneeded and unused? A package that may be not useful for you may be
> very useful for many others.
True. But, if you can't find 3 people out of 900 (so 1 out of 300) who
see interest in a package, then that package is most probably very
rarely used.

Other thing: there might be a need for a new Priority (or re-arrange the
current ones). I mean, something like 'Priority: zero' or something like
that, so they won't even go to the official set of the CDs, etc.

> I agree with you that the many orphaned packages are a problem, but that
> won't be solved by your proposal.
Sure, but it might stop the growing of that list.

Regards,
-- 
Lenart, Janos
<[EMAIL PROTECTED]>


pgpvypG6ZQm1y.pgp
Description: PGP signature

Re: outdated ARM version keeps package from entering testing

[Tollef Fog Heen]

* Eric Van Buggenhaut 

| 2) I was thinking about building it myself but there's no machine
| available (debussy.d.o is down - rameau.d.o runs potato)
| 
| 
| What am I supposed to do ??

I'd talk to [EMAIL PROTECTED], he should be able to get you an account on
europa.armlinux.org or similar.  It runs unstable, iirc.

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Lenart Janos]

On Sat, Dec 29, 2001 at 03:21:32PM +0100, Raphael Hertzog wrote:
> Le Sat, Dec 29, 2001 at 11:31:37AM +0100, Lenart Janos ?crivait:
>
> Well, the basic idea is not so stupid, but the implementation is not
> really great.
The important part is that something must be done.

> I have something better to propose. But it requires a new (long asked)
> feature : the ability to subscribe to a "package" (to get its bug logs,
> to get mails sent to @packages.debian.org [1]).
[...]
> PS: Feel free to CC me since I read debian-devel only once a week.
The best would be if *every* package in Debian would have at least 2
(better, 3) responsible people (like maintainer) assigned to. Please
note that I am not thinking of Uploaders: . My mail is not about who are
allowed to upload at all, it's about responsibility.

-- 
Lenart, Janos
<[EMAIL PROTECTED]>


pgpjFoBeLRArX.pgp
Description: PGP signature

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Francesco P. Lovergine]

On Sat, Dec 29, 2001 at 11:59:32AM +0100, Martin Michlmayr wrote:
> * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]:
> > I have changed my mind and will write semi-automatically a bug
> > report for each of the packages with severity grave.
> 
> Don't do this.  There are too many packages involved to file
> semi-automatic bugs already and the bugs should not be grave either.
> Are you convinced this makes _all_ these packages "unuseable or mostly
> so, or causes data loss"?  The issue could appear in code which is
> actually not relevant for 90% of users (i.e. severity important).
> 
> I suggest you first post a mail desribing this issue to d-d-announce.
> Describe exactly why char signedness is a problem and what to do about
> it.  Show examples how to fix the code (it's not hard but still..).
> Then give the developers some time to actually do something about it.
> And _then_ _consider_ filing bugs (by discussing it here again).
> 
> -- 
> Martin Michlmayr
> [EMAIL PROTECTED]
> 

I agree. As for yardradius, the bug could be in fact secondary - programs
works anyway. 
Severity level should be evaluated in every single case.

-- 
Francesco P. Lovergine

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Gerhard Tonn]

On Saturday 29 December 2001 11:59, you wrote:
> * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]:
> > I have changed my mind and will write semi-automatically a bug
> > report for each of the packages with severity grave.
>
> Don't do this. 

That's fine with me. I don't see what it helps though except that the 
problems don't appear in the list of release critical bugs.


Gerhard

Re: outdated ARM version keeps package from entering testing

[Philip Blundell]

In message <[EMAIL PROTECTED]>, Eric Van Buggenhaut writes:
>1) There's no auto-build of crafty because it's non-free.
>
>2) I was thinking about building it myself but there's no machine
>available (debussy.d.o is down - rameau.d.o runs potato)

Mmm.  I suppose we should think about making rameau's unstable chroot a bit
more publicly available.

Do you want me to cajole the autobuilder into having a go at crafty despite
its non-free status?

p.

Re: outdated ARM version keeps package from entering testing

[Eric Van Buggenhaut]

On Sat, Dec 29, 2001 at 03:52:53PM +, Philip Blundell wrote:
> In message <[EMAIL PROTECTED]>, Eric Van Buggenhaut writes:
> >1) There's no auto-build of crafty because it's non-free.
> >
> >2) I was thinking about building it myself but there's no machine
> >available (debussy.d.o is down - rameau.d.o runs potato)
> 
> Mmm.  I suppose we should think about making rameau's unstable chroot a bit
> more publicly available.
> 
> Do you want me to cajole the autobuilder into having a go at crafty despite
> its non-free status?
> 

Thanks for your quick answer. I'm currently connected to rameau and
try to build crafty for potato (it could be run on sid later on, I guess), but 
package build-depends on bzip2 which isn't
installed. Building bzip2 in $HOME worked fine but can't be executed because of
the absence of /usr/lib/libbz2.so.0.

So, if you can give me an access to chroot I'll try to build the
package myself and if not possible, having the autobuilder doing the
job would be nice, ppl keep sending bugs about crafty for a problem
that has been solved in newer versions.

Please CC me.

Cheers,

-- 
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]

Re: Bug#126750: klogd should optionally be started from init(8)

[Henrique de Moraes Holschuh]

On Sat, 29 Dec 2001, Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > True, true. However, sysklogd and klogd are logging daemons. They deserve
> > some special treatment IMHO.
> 
> Even so, starting it from inittab is too much of a kludge.  For one thing,

It is far better than anything else I can think of. Fiddling with the OOM
killer to avoid killing syslog and klog is worse, for example. Writing
something else to do what init already does, and does well is pointless,
too.

This could be done in a nice, generic way so that we have a common interface
to add stuff to inittab, sort of like update-rd.d. Then, it becomes less of
a disgusting hack.

> it means that /etc/init.d/syslogd stop will either not work, or be an
> ugly hack that fools around with inittab.

Yes, that part disgusts me. Writing a update-rc.d-like interface (or
update-inetd-like, for that matter) to do it is actually a good idea, and
probably the way to go.

> In any case, if the OOM killer has moved onto syslogd, then you've probably
> lost control of the box anyway so restarting it is pretty pointless.

Not really. Forsenics are always useful.

> > That is not always possible, and sometimes a kernel VM screwup will cause
> > it, no?
> 
> Why should we set up such ugly work arounds for kernel bugs or incompetent
> admins?

I don't know, maybe because it is useful for real? And because the current
kernel VM is too incompetent at doing its job?

I agree we should not setup an ugly work-around, but we can design, write
and setup a non-ugly inittab interface, and use that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#126750/749: klogd/sysklogd should optionally be started from init(8)

[Henrique de Moraes Holschuh]

On Sat, 29 Dec 2001, Marco d'Itri wrote:
> On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>  >> What do people think?
>  >Go for it. The OOM killer will hit just about anything which is not a kernel
>  >thread, and losing syslogd and klogd is a major no-no.
> The OOM code is supposed to be fixed in 2.4 kernels.

This really is not enough reason to do, or not do the inittab thing. And
there are reports of OOM problems and VM screwups in lkml still.

> I still see no reason to consider klogd more important than e.g. sshd.

Nor do I. I would try do get both into MY inittab...

-- 
  "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: Preparing a Proposal: 3 DD needed for every NEW package

[Gustavo Noronha Silva]

On Sat, 29 Dec 2001 16:21:39 +0100
Lenart Janos <[EMAIL PROTECTED]> wrote:

> > I have something better to propose. But it requires a new (long asked)
> > feature : the ability to subscribe to a "package" (to get its bug logs,
> > to get mails sent to @packages.debian.org [1]).
> [...]
> > PS: Feel free to CC me since I read debian-devel only once a week.
> The best would be if *every* package in Debian would have at least 2
> (better, 3) responsible people (like maintainer) assigned to. Please
> note that I am not thinking of Uploaders: . My mail is not about who are
> allowed to upload at all, it's about responsibility.
uh... that would make life very difficult... you'd have to discuss
every modification before implementing it, that takes time...

I think we have this problem to solve: quality going down and the
solution I see is attacking this problem in its roots: removing
bad packages and bad/mia maintainers

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

Re: Bug#124624: foiltex: Spelling error in description

[Ulrich Eckhardt]

On Friday 28 December 2001 07:44, Atsuhito Kohda wrote:
> >  Package: foiltex
> >  Description: A collection of LaTeX files for making foils.
> >   A number of features are built-in including large sans serif font 
While you're at it add a comma here^

> > - normal font, options for setting normalsize at 20pt (default), 17pt,
> > + normal font, options for setting normal size at 20pt (default), 17pt,
> > 25pt or 30pt, new macros for starting new foils, for special environments
> > like Theorem and Proof, simple macros to control the headline and
> > footline.
>
> Hi all,
>
> I got an above reports and I thought it was reasonable at first,
> but, in TeX world, "normalsize" is a correct terminology and
> I guessed the above sentence is an intentional one of the
> upstream author (I cited the above from the original document
> i.e. readme.flt).

I agree that this is a special tex-term.

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Steve Langasek]

On Sat, Dec 29, 2001 at 11:23:44AM +0100, Gerhard Tonn wrote:
> Hi,
> I have changed my mind and will write semi-automatically a bug report for 
> each of the packages with severity grave.

> I am currently rebuilding the latest version of each of the packages, so that 
> a build log for s390 will be available at http://buildd.debian.org/ . I will 
> then check that the problem is still there and write a bug report considering 
> those who have already answered me.

Please consider the unixodbc problem answered for.  I have already filed 
a bug against this package.

Thanks,
Steve Langasek
postmodern programmer


pgpXeIdjJZavY.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Francesco P. Lovergine]

On Sat, Dec 29, 2001 at 02:14:15PM +0100, Josselin Mouette wrote:
> Lenart Janos a icrit :
> > 
> > As you might already have noticed Debian begun to bloat - so many
> > unneeded, unused, unmaintained(!) packages.
> 
> I don't think all these packages should be swept out. Unmaintained 
> packages that don't have bunches of bugs shouldn't be a problem, for 
> example.
> 
> A better solution, IMO, would be to evaluate which packages should be 
> removed from the archive (and I believe there are not very much). To do 
> that, one could consider the orphaned packages that have important bugs, 
> ore more than N (define N as you like) normal bugs. A large part of them 
> could certainly be replaced by other (maintained) ones. Then, a 
> Replaces: field should be added in those packages - or maybe replaces is 
> too strong and we would have to add another field.
> 
> For the other ones (unmaintained, buggy, AND without replacement), the
> users should be clearly informed when installing the, and maybe the
> package could be removed from the archive after 2 releases.
> 

Add also that packages can reach their End-Of-Life time. 
So, no more upstream maintainer(s), no more active development and more valid
alternatives to them. This is unfortunately true for so much pkgs.
Currently I do not see any valid management of this kind of problem in the 
Project, but for maintainer minds. 
Apparently, too much maintainers are not really active
and too much pkgs are built up without a RFP. Some packages are
built starting from beta-quality sw, and this is not a good practice.
Burocracy cannot solve these problems. Maintainers intelligence could.


-- 
Francesco P. Lovergine

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Bdale Garbee]

[EMAIL PROTECTED] (Lenart Janos) writes:

> On Sat, Dec 29, 2001 at 03:30:28PM +0100, Bas Zoetekouw wrote:
> > You wrote:
> > > As you might already have noticed Debian begun to bloat - so many
> > > unneeded, unused, unmaintained(!) packages.
> > > My opinion is that one DD alone couldn't upload NEW package, but he
> > > needs 2 proponent DD who are willing to "give his signature for it".
> > > Just to make it a little more complicated a minimum of 50 word long
> > > justification needed from all the 3 guys (e.g. two proponent DD and the
> > > future maintainer).
> > unneeded and unused? A package that may be not useful for you may be
> > very useful for many others.
> True. But, if you can't find 3 people out of 900 (so 1 out of 300) who
> see interest in a package, then that package is most probably very
> rarely used.

I can't think of any package, offhand, for which I couldn't find two people
in Debian to say yes.  Therefore, I don't see this porposal as providing any
real utility... it just adds process overhead and makes the jobs of people
who are already overworked harder.

> Other thing: there might be a need for a new Priority (or re-arrange the
> current ones). I mean, something like 'Priority: zero' or something like
> that, so they won't even go to the official set of the CDs, etc.

I've thought about this before, too.  It's not entirely clear to me why we
want packages in the distribution we're not willing to see released on CD's
other than for legitimate release-critical bugs, though.

Bdale

Bug#126897: RFP: php4-rrdtool -- php4 module for accessing RRDtool databases

[Matt Zimmerman]

Package: wnpp
Severity: wishlist

Since it appears being actively maintained and distributed separately from
RRDtool, it would make most sense for someone to package it in its own
right.  

* Package name: php4-rrdtool
  Version : 1.03
  Upstream Author : Joe Miller <[EMAIL PROTECTED]>
* URL : 
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/contrib/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : php4 bindings for librrd

-- 
 - mdz

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Mark Brown]

On Sat, Dec 29, 2001 at 10:16:04AM -0700, Bdale Garbee wrote:
> [EMAIL PROTECTED] (Lenart Janos) writes:

> > Other thing: there might be a need for a new Priority (or re-arrange the
> > current ones). I mean, something like 'Priority: zero' or something like
> > that, so they won't even go to the official set of the CDs, etc.

> I've thought about this before, too.  It's not entirely clear to me why we
> want packages in the distribution we're not willing to see released on CD's
> other than for legitimate release-critical bugs, though.

The approach that's been discussed in the past (and which I believe is
currently attempted) is to try to put more widely used software on the
lower numbered CDs.

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


pgpPxTnVrUMwG.pgp
Description: PGP signature

Re: Bug#124624: foiltex: Spelling error in description

[Matt Zimmerman]

On Fri, Dec 28, 2001 at 10:04:42PM +0100, Ingo Saitz wrote:
> MoiN
> 
> On Fri, Dec 28, 2001 at 03:44:19PM +0900, Atsuhito Kohda wrote:
> > From: Matt Zimmerman <[EMAIL PROTECTED]>
> > > - font, options for setting normalsize at 20pt (default), 17pt, 25pt or
> > > + font, options for setting normal size at 20pt (default), 17pt, 25pt or
> > 
> > I got an above reports and I thought it was reasonable at first, 
> > but, in TeX world, "normalsize" is a correct terminology and 
> 
> Maybe you want to use \normalsize instead?

I was about to suggest the same thing; I made this erroneous correction
because it wasn't clear from context what this was referring to.  If it had
read "\normalsize" or if "normalsize" was quoted, it would be clearer.

-- 
 - mdz

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Adam Majer]

On Sat, Dec 29, 2001 at 11:31:37AM +0100, Lenart Janos wrote:
> [Please Cc: to me! (ETOOHIGHVOLUME)]
> 
> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.
> My opinion is that one DD alone couldn't upload NEW package, but he
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).

This doesn't sound too bad to me, _but_ a better report might be to set up some 
sort of automatic system that 
sends out email to all maintainers at 1 month intervals [or something like 
that]. If someone doesn't respond to 2 
or 3, then they are marked inactive and someone, preferable a human, verifies 
that the maintainer is not active 
anymore and orphans all of his/her packages... This would eliminate the 
unmaintained problem...

As for unused packages, it is a very subjective thing :) Something like iraf 
might now be used by many but it is
still needed by some.. Removing stuff like this turns Debian into RedHat - no 
one wants that.

Unneeded packages might still be used but then it is up to the maintaner to 
orphan them and if they are trully 
unneeded then they would not be adopted.

None of the above thing change the way that packages are maintaned - easier to 
implement. It would also catch the 
perm. AWOL maintainers. 


Any opinions??

- Adam


pgp7xHmPN6esm.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Sebastian Rittau]

On Sat, Dec 29, 2001 at 03:21:32PM +0100, Raphael Hertzog wrote:

> - for each ITP, we need at least 2 developers that will maintain the
>   package, they both subscribe to the package, one is the official
>   maintainer, the other is listed in the Uploaders: field.

This may work with larger packages, but it's just an incredible
coordination overhead with smaller package like po-utils, which I have
just packaged. This will only cost time that most of us don't have
plenty of.

It seems to me that the exisiting NMU scheme is sufficient for most of
the small and medium sized packages.

 - Sebastian

[Evms-devel] Re: RFP: EVMS

[Kevin Corry]

On Friday 28 December 2001 23:48, Matt Zimmerman wrote:
> On Fri, Dec 28, 2001 at 10:28:47AM -0600, Kevin Corry wrote:
> > The most recent release for EVMS is on our website:
> > http://www.sf.net/projects/evms/ The current release is 0.2.4. Our beta
> > release (0.9.0) should be coming out mid-January. Right now, the releases
> > are available as source tarballs and RPMs, and we'd love to have a debian
> > package as well in the future. If you are interested in creating a debian
> > package for EVMS, feel free to let me know if you have any questions
> > about how EVMS works or how to get it installed and running.
>
> I have already grabbed the latest release and started work on evms packages
> for Debian, though I haven't touched them for over a week since I have been
> away.  I should have experimental packages ready within the next week or
> so.

Great!

> I have been using LVM for some time, and I am eager to start working with
> EVMS.  Once I have working packages, I will be migrating some of my LVM
> volumes to EVMS using them, which should be a good initial test.

Let me know how your tests go.

> I have not as yet built a kernel with the EVMS patch.  I hope it is
> possible to include both LVM and EVMS for migration purposes; is this true?

Yep. I run kernels with both EVMS and LVM enabled. Just make sure you don't 
mount the same LV with both systems at the same time. Also, if you make any 
volume modifications with one system (add/delete LVs, add/delete PVs from a 
VG, etc), you may need to reboot in order for the other to pick up the 
changes.

-Kevin

Re: Bug#126750: klogd should optionally be started from init(8)

[Tommi Virtanen]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Florian Weimer wrote:
> > The package installation scripts should offer to run klogd from
> > inittab, since klogd regularly dies in OOM situations and is not
> > restarted if the current mechanism is used.

IMHO the right solution is to slowly replace sysvinit's init.d
with something that can monitor whether the children are still
alive. For _everything_.

I know many of you hate DJB, but his daemontools is a good
idea (though I do dislike the implementation, atleast parts of
it).

-- 
[EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
double a,b=4,c;main(){for(;++a<2e6;c-=(b=-b)/a++);printf("%f\n",c);}

Re: Bug#126750: klogd should optionally be started from init(8)

[martin f krafft]

also sprach Tommi Virtanen <[EMAIL PROTECTED]> [2001.12.29.2035 +0100]:
>   IMHO the right solution is to slowly replace sysvinit's init.d
>   with something that can monitor whether the children are still
>   alive. For _everything_.

ntpdate??? for instance...

surely not everything, but everything that qualifies as a daemon...

> I know many of you hate DJB, but his daemontools is a good
> idea (though I do dislike the implementation, atleast parts of
> it).

he is an asshole, but his software is good.

> [EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
   ^
h! someone i can bug when full cluster decides to not work the way i
want... :)

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
(a)bort, (r)etry, (p)retend this never happened


pgpeBFHbUHaO5.pgp
Description: PGP signature

Re: design issues in debian packages

[Adam Heath]

On 29 Dec 2001, Kjetil Torgrim Homme wrote:

> > I don't find it at all complex.
>
> Of course not, you came up with it :-)
>
> My point is, a normal user will not have read a description of how
> this works.  He will find a .$file and have no idea why and how.
> Making the filename more self-documenting would help, IMHO.

Well, the .$file can be a shell script.  Shell scripts can have comments.
Problem solved.

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Russell Coker]

Firstly having three people saying that a package should be in Debian seems 
like a useless waste of time to me.

Because of this, if such an idea is implemented then I will second any 
package which meets current Debian policy without exception, this means that 
anyone who wants a new package included needs only one other person to back 
it up.  If one other person takes the same approach as me then it'll be just 
as easy to get packages in Debian as it is now.

On Sat, 29 Dec 2001 16:21, Lenart Janos wrote:
> On Sat, Dec 29, 2001 at 03:21:32PM +0100, Raphael Hertzog wrote:
> > Le Sat, Dec 29, 2001 at 11:31:37AM +0100, Lenart Janos ?crivait:
> >
> > Well, the basic idea is not so stupid, but the implementation is not
> > really great.
>
> The important part is that something must be done.

Why?

Why not try to get something done about real problems, such as the fact that 
major critically important packages such as libc6 have lots of open bugs of 
severity normal or above!

I know that someone will probably say "let's ban work on less important 
things until more work is done on libc6 etc".  However the fact is that a 
very large proportion of developers lack the skills to work on serious 
problems with libc6, I personally don't look into libc6 issues when I have 
spare time because of the difficulty with working on that code.

Also having many things packaged for Debian frees up developer time.  The 
fact that 99% of all programs I want to use are already packaged saves me a 
large amount of time that can be spent on better things (such as Debian 
development).

> > I have something better to propose. But it requires a new (long asked)
> > feature : the ability to subscribe to a "package" (to get its bug logs,
> > to get mails sent to @packages.debian.org [1]).

Sounds like a great idea!  There's quite a number of packages I'd like to 
subscribe to in that fashion, for such packages I could probably help out 
occasionally.

> > PS: Feel free to CC me since I read debian-devel only once a week.
>
> The best would be if *every* package in Debian would have at least 2
> (better, 3) responsible people (like maintainer) assigned to. Please
> note that I am not thinking of Uploaders: . My mail is not about who are
> allowed to upload at all, it's about responsibility.

Why ask for three people when finding one person who has the time to spare is 
so difficult?

Also having more people doesn't necessarily get more productivity...

-- 
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/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: outdated ARM version keeps package from entering testing

[Adam Heath]

On Sat, 29 Dec 2001, Eric Van Buggenhaut wrote:

> Thanks for your quick answer. I'm currently connected to rameau and
> try to build crafty for potato (it could be run on sid later on, I guess), 
> but package build-depends on bzip2 which isn't
> installed. Building bzip2 in $HOME worked fine but can't be executed because 
> of
> the absence of /usr/lib/libbz2.so.0.

LD_LIBRARY_PATH

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Raphael Hertzog]

Le Sat, Dec 29, 2001 at 09:04:48PM +0100, Russell Coker écrivait:
> > > I have something better to propose. But it requires a new (long asked)
> > > feature : the ability to subscribe to a "package" (to get its bug logs,
> > > to get mails sent to @packages.debian.org [1]).
> 
> Sounds like a great idea!  There's quite a number of packages I'd like to 
> subscribe to in that fashion, for such packages I could probably help out 
> occasionally.

I'd probably do the same for packages I maintained in the past and for
packages where i have good knowledges. And hopefully many people would
do the same.

> Why ask for three people when finding one person who has the time to spare is 
> so difficult?

The basic goal is that someone still gets the bug reports if the main
maintainer disappears. As those people would get the bug logs, they'd
notice that the main maintainer never responds and could decide to take
it over. Occasionnaly they could also help for particular bug
reports or when the maintainer goes on vacation. Having well defined
"backup" maintainers is definitely useful ...

Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguer sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Colin Watson <[EMAIL PROTECTED]> writes:

> > But I suspect that eight people is nowhere near enough people.  Maybe
> > I could join...
> 
> Please do! Adrian Bunk posted a proposal a month or so ago for QA
> organization in the future, containing a good summary of the kinds of
> things people can work on.

So one problem is that I looked at the To Do List on the QA pages, and
it has one item.  I looked at the release critical bugs on important
packages, and they are all small things that can only be effectively
solved by the maintainer (fixing minor typo problems, etc).  

I'm sure there's lots of work to be done, but it's not clear what
exactly it is.

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Thomas Bushnell, BSG]

Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:

> I think we have this problem to solve: quality going down and the
> solution I see is attacking this problem in its roots: removing
> bad packages and bad/mia maintainers

I can see how removing bad packages helps.  How does removing an MIA
maintainer make anything better?

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Henrique de Moraes Holschuh]

On Sat, 29 Dec 2001, Thomas Bushnell, BSG wrote:
> Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:
> > I think we have this problem to solve: quality going down and the
> > solution I see is attacking this problem in its roots: removing
> > bad packages and bad/mia maintainers
> 
> I can see how removing bad packages helps.  How does removing an MIA
> maintainer make anything better?

We orphan ALL his packages, we get to know he is MIA and will not wait for
him for anything.

-- 
  "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: Preparing a Proposal: 3 DD needed for every NEW package

[Thomas Bushnell, BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Sat, 29 Dec 2001, Thomas Bushnell, BSG wrote:
> > Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:
> > > I think we have this problem to solve: quality going down and the
> > > solution I see is attacking this problem in its roots: removing
> > > bad packages and bad/mia maintainers
> > 
> > I can see how removing bad packages helps.  How does removing an MIA
> > maintainer make anything better?
> 
> We orphan ALL his packages, we get to know he is MIA and will not wait for
> him for anything.

Oh, I think orphaning his packages can be a useful thing to do.  But I
just don't see why explicitly punting him helps.  Just make the
packages available for other people, and then welcome the guy back
if/when he returns.

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Mark Brown]

On Sat, Dec 29, 2001 at 12:45:54PM -0800, Thomas Bushnell, BSG wrote:

> I can see how removing bad packages helps.  How does removing an MIA
> maintainer make anything better?

I don't know that removing MIA maintainers would help that much but
opening up their packages so that other people could work on them more
easily would be useful.

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


pgpVOz90m92Ph.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Henrique de Moraes Holschuh]

On Sat, 29 Dec 2001, Thomas Bushnell, BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > On Sat, 29 Dec 2001, Thomas Bushnell, BSG wrote:
> > > Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:
> > > > I think we have this problem to solve: quality going down and the
> > > > solution I see is attacking this problem in its roots: removing
> > > > bad packages and bad/mia maintainers
> > > 
> > > I can see how removing bad packages helps.  How does removing an MIA
> > > maintainer make anything better?
> > 
> > We orphan ALL his packages, we get to know he is MIA and will not wait for
> > him for anything.
> 
> Oh, I think orphaning his packages can be a useful thing to do.  But I
> just don't see why explicitly punting him helps.  Just make the

If he did not warn us he would be MIA (all it takes is a message to -devel,
-private, or asking someone in irc to send said email), and he has not a
damn good excuse (being in the hospital nearly dying is a good one for not
notifying anyone, for example), he deserves to go through the pains of
nm.debian.org to learn to be more considerate of others.

-- 
  "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: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 29 Dec 2001, Thomas Bushnell, BSG wrote:

> Colin Watson <[EMAIL PROTECTED]> writes:
>
> > > But I suspect that eight people is nowhere near enough people.  Maybe
> > > I could join...
> >
> > Please do! Adrian Bunk posted a proposal a month or so ago for QA
> > organization in the future, containing a good summary of the kinds of
> > things people can work on.
>
> So one problem is that I looked at the To Do List on the QA pages, and
> it has one item.  I looked at the release critical bugs on important
> packages, and they are all small things that can only be effectively
> solved by the maintainer (fixing minor typo problems, etc).

look at http://base.debian.net/ and http://standard.debian.net/

There are rc bugs listed that are more than just trivial.

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Colin Watson]

On Sat, Dec 29, 2001 at 04:52:58PM +0100, Gerhard Tonn wrote:
> On Saturday 29 December 2001 11:59, you wrote:
> > * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]:
> > > I have changed my mind and will write semi-automatically a bug
> > > report for each of the packages with severity grave.
> >
> > Don't do this. 
> 
> That's fine with me. I don't see what it helps though except that the 
> problems don't appear in the list of release critical bugs.

Auto-filing grave bugs is a problem because we're having a hard enough
time releasing woody as it is.

Alternatively put, arm and powerpc have had this problem for some time,
so I'd hope that users of those architectures would have filed bugs
about real problems caused by this type of code.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: WARNING: Jack Howarth is an agent of destruction

[Anders Jackson]

Michael Stone <[EMAIL PROTECTED]> writes:

> On Tue, Dec 25, 2001 at 10:29:49PM +1100, Herbert Xu wrote:
> > The last time I checked the maximum sentence for treason in Great Britain
> > was death...
> 
> Hmm, that can't be right. Aren't the brits complaining about the US
> wanting to execute terrorists, because of conflicts with EU declaration
> of human rights?
(This is of toppic, isn't it)

Isn't it UN declaration of human rights, not EUs.  And I think that
USA has signed them to.

(I don't like death penalties, an faulty (and/or) unfair sentence
 can't be undone.  A life sentence can.)

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Bas Zoetekouw]

Hi Lenart!

You wrote:

> True. But, if you can't find 3 people out of 900 (so 1 out of 300) who
> see interest in a package, then that package is most probably very
> rarely used.

Let me refrase my question: can you explictly point out some packages
that have been ITP'ed lately and of which you think that they should not
go into Debian because they aren't needed? I can't, so I don't think
there's a problem here.

> > I agree with you that the many orphaned packages are a problem, but that
> > won't be solved by your proposal.

> Sure, but it might stop the growing of that list.

We could also just drop all extra and optional packages, that might also
stop teh growing of that list (and it will be a lot more effective I
think). Seriously though, it's not the new packages we should worry
about (they are mostly well taken care of and not orphaned quickly), but
the old ones.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Gustavo Noronha Silva]

On Sat, 29 Dec 2001 19:09:48 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> On Sat, 29 Dec 2001, Thomas Bushnell, BSG wrote:
> > Oh, I think orphaning his packages can be a useful thing to do.  But I
> > just don't see why explicitly punting him helps.  Just make the
> 
> If he did not warn us he would be MIA (all it takes is a message to -devel,
> -private, or asking someone in irc to send said email), and he has not a
> damn good excuse (being in the hospital nearly dying is a good one for not
> notifying anyone, for example), he deserves to go through the pains of
> nm.debian.org to learn to be more considerate of others.
that's exactly what I think... anyway what I meant with 'removing MIA
maintainers' was: send him a notice that he'll be removed if he won't
take care of his packages/other tasks for foo more days, if he does
not answer or tell us he's giving up his key is removed from the keyring
and etc... I don't see the point on keeping long-MIA maintainers.. after
that he has to go through nm.debian.org again.

Besides that's a good test to check if the applicant has time 
and will hehehe

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

Re: Bug#126750: klogd should optionally be started from init(8)

[Herbert Xu]

On Sat, Dec 29, 2001 at 02:09:36PM -0200, Henrique de Moraes Holschuh wrote:
> 
> It is far better than anything else I can think of. Fiddling with the OOM
> killer to avoid killing syslog and klog is worse, for example. Writing

Nope, that's exactly what the OOM killer was designed to do.  Processes
like syslogd is meant to be the last ones to be killed.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#126750: klogd should optionally be started from init(8)

[Henrique de Moraes Holschuh]

On Sun, 30 Dec 2001, Herbert Xu wrote:
> On Sat, Dec 29, 2001 at 02:09:36PM -0200, Henrique de Moraes Holschuh wrote:
> > It is far better than anything else I can think of. Fiddling with the OOM
> > killer to avoid killing syslog and klog is worse, for example. Writing
> 
> Nope, that's exactly what the OOM killer was designed to do.  Processes
> like syslogd is meant to be the last ones to be killed.

Well, you're the authority on the kernel here. If you think it is a good
idea to modify the OOM, I will not disagree.

Such mod to the OOM would at the very least give us time to leisurely write
an inittab control interface (generic, might be useful for a lot of stuff),
and test and deploy it. It would be useful for the *getty packages, for
example.

Then it would be simple to make such changes locally, or based on debconf
requests of user preference (or not at all) for any package that might
benefit from it.

I am not at ease to go poking on the OOM, though. Someone else better used
to kernel programming should do 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: Bug#126750: klogd should optionally be started from init(8)

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>> 
>> Nope, that's exactly what the OOM killer was designed to do.  Processes
>> like syslogd is meant to be the last ones to be killed.

> I am not at ease to go poking on the OOM, though. Someone else better used
> to kernel programming should do it...

The OOM killer should already do this as it is, no modifications are
required...
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#126750: klogd should optionally be started from init(8)

[Henrique de Moraes Holschuh]

(not cc'ed to the bts)

On Sun, 30 Dec 2001, Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> >> Nope, that's exactly what the OOM killer was designed to do.  Processes
> >> like syslogd is meant to be the last ones to be killed.
> > I am not at ease to go poking on the OOM, though. Someone else better used
> > to kernel programming should do it...
> The OOM killer should already do this as it is, no modifications are
> required...

I've just read the OOM killer in 2.4.17. It has provisions that tend NOT to
select klogd or syslogd in a system that has been running for a while, but
it may end up killing them.  

It does this by assuming that such important stuff was started early, and
stayed put (i.e. was not restarted)... at least that is what I understood
from the code and comments.

Now, if you just upgraded sysklogd, or otherwise caused an important process
to restart, you are less safe against the OOM trying to kill what you did
NOT want it to kill.

Nowhere does it use the process name to lessen the chances of killing a
process. IMHO it would be a nice idea to have such a whitelist just in case.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#126750: klogd should optionally be started from init(8)

[Russell Coker]

On Sun, 30 Dec 2001 01:03, Dominik Kubla wrote:
> On Sat, Dec 29, 2001 at 09:47:27PM -0200, Henrique de Moraes Holschuh wrote:
> > Nowhere does it use the process name to lessen the chances of killing a
> > process. IMHO it would be a nice idea to have such a whitelist just in
> > case.
>
> Extremely bad idea... All of a sudden every process somebody does not want
> to be killed is called "syslog" or "named" or what ever.

True.

> Let's face it folks: if the OOM killer hits you constantly you have
> exhausted your resources.  The solution is to buy new resources, not to
> invent convoluted schemes to make a bad situatation last longer.

There are other options.  You could have a root-only syscall which says 
"don't kill me" to go with the root-only syscall for "don't page me out".

-- 
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/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Bug#126750: klogd should optionally be started from init(8)

[Henrique de Moraes Holschuh]

On Sun, 30 Dec 2001, Russell Coker wrote:
> On Sun, 30 Dec 2001 01:03, Dominik Kubla wrote:
> > On Sat, Dec 29, 2001 at 09:47:27PM -0200, Henrique de Moraes Holschuh wrote:
> > > Nowhere does it use the process name to lessen the chances of killing a
> > > process. IMHO it would be a nice idea to have such a whitelist just in
> > > case.
> > Extremely bad idea... All of a sudden every process somebody does not want
> > to be killed is called "syslog" or "named" or what ever.
> True.

Not just like that. Read the code you two before you start talking nonsense.

Such a table should not (and needs not) to benefit processes running by
someone else than root, unless you wanted to do such a thing on purpose and
coded it like that.  Root processes already have a much lesser probability
of being killed. If I want a table to fix the issue with the ordering
on time of two or three processes, I would need to be quite stupid to do
something that screwed up the OOM balancing so much that users would start
naming their processes syslog or named to avoid them being killed.

As for root naming processes syslog to avoid them being killed, there is
something to be said about stupidity.

> > Let's face it folks: if the OOM killer hits you constantly you have
> > exhausted your resources.  The solution is to buy new resources, not to
> > invent convoluted schemes to make a bad situatation last longer.

Lets face it: it would be best if the logging stuff did not get killed
without reason, and would restart itself in such cases. There IS a lot of
advantage on resilience. Improving resilience is not futile, but it is not
an substitute to good administration. Does that mean one should never bother
to improve the tools to be more resilient, because good administration is
more important? IMHO, no.

I dislike important crap that dies too easily, and I think init is the
natural choice for taking care of [the very few] processes that need to be
shephered, because it already does just that, and does it very well.  

I fail to see why that is a convoluted solution, and why it is good to have
frail syslog daemons, and nothing to kick their back into life should they
die, but maybe I am myoptic...  as for the OOM, it was not MY idea to fiddle
with it.

> There are other options.  You could have a root-only syscall which says 
> "don't kill me" to go with the root-only syscall for "don't page me out".

Yes. This is another way to do it, and it is a good one too.  Harder to
implement, since you need to somehow keep that 'don't kill me' state stored
somewhere, but it is a better solution than the table, I suppose.

But do recall it must mean "I am important, schedule me to die last", not
"don't kill me".

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

Museum

[Sherlock Holmes]

Visit The World's Most Famous Address!

The Sherlock Holmes Museum
221b Baker Street, London England
http://www.sherlock-holmes-museum.org.uk/happynewyear.html


A Happy New Year to all our visitors, old and new!

Please see our Victorian New Year Greetings Card that we have made especially 
for you.

You can email it to any friend, or print it out as a free souvenir from London!


Yours faithfully,


John Riley
Assistant Curator
http://www.sherlock-holmes-museum.org.uk/happynewyear.html
 

NMU sclient

[Ian Eure]

hi there. i've prepared a NMU for sclient, which fixes it's two outstanding 
bugs.

upstream seems to be dead, the last release was in 1999. maintainer seems to 
be mia.

any objections?

Bug#126967: ITP: pnet -- Portable .NET C# compiler & runtime

[Andrew Mitchell]

Package: wnpp
Version: N/A; reported 2001-12-30
Severity: wishlist

* Package name: pnet
  Version : 0.2.6
  Upstream Author : Rhys Weatherly <[EMAIL PROTECTED]>
* URL : http://www.southern-storm.com.au/portable_net.html
* License : GPL (with linking exception)
  Description : DotGNU Portable.NET C# compiler & runtime

DotGNU Portable.NET is a project under the DotGNU meta-project. Its goal is to 
build a suite of free software tools to build and execute Common Language 
Infrastructure (CLI) applications. The initial target platform is GNU/Linux, 
with other platforms to follow in the future.
This package contains the runtime engine, the C# compiler, and other tools.
Currently, packages are done but need to be tidied up.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux ajmitch 2.4.17-pre7 #2 Tue Dec 11 00:16:38 NZDT 2001 i586
Locale: LANG=C, LC_CTYPE=