Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[MJ Ray]

Glenn Maynard <[EMAIL PROTECTED]>
> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
> nvi over vim [...]

I strongly prefer nvi over vim.  I dislike vim enough to
install vile when I need a bigger vi than nvi.  Last I tried
(albeit many moons ago), vim's vi-compatible mode wasn't and
there seemed little interest in bug reports (attitude of: How
can you not prefer vim? Run vim and all will be well. Love vim.)

AFAICT, Lars Wirzenius and Andrew M A Cater told similar things.
I guess you don't count them for some reason.  So, we'll wait
for data on preferences and the size thing seems clear anyway.

[...]
> > Please cc me on replies.
> 
> This is the only time I'll do so, to remind you to set Mail-Followup-To.
> It's your job to set headers expressing your preferences [...]

MFT is conceptually broken non-standard DJB-ware, but let's not
have this debate again. If you're using mutt, I'm just asking
you to use g instead of l to reply, not hack headers - you
might like to bugfix mutt to support List-* if it still doesn't.
My request was as suggested by
http://www.debian.org/MailingLists/#codeofconduct
so please honour it.

Thanks,
-- 
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/  irc.oftc.net/slef  Jabber/SIP ask


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

Re: Thoughts on Debian quality, including automated testing

[Andrew Suffield]

On Wed, Dec 21, 2005 at 11:17:43PM +0100, Thomas Hood wrote:
> If the problem is lack of motivation,
> and the chief motivator is a sense of responsibility, then you don't want
> to diffuse that.

Specifically motivation to do *this* task, rather than any of the
others in the pile that need doing. People who maintain significant
packages tend to be busy. Their reason for doing one thing over
another will be primarily dependent on what they want to do, and what
they feel they *should* do.

> > We would all be much worse off with the abolition of individual
> > responsibility.
> 
> The constitution already abolished it -- at least, if you interpret
> article 2.1 the way some people have.

I consider 'individual responsibility' to be a matter of personal
ethics, not enforced punishment. We do have a few morally bankrupt
maintainers (or, non-maintainers). I think the majority of developers
have some sense of responsibility, though. This belief is primarily
founded on the fact that I don't think Debian could have survived this
long at this size without it.

> Maybe it would be useful to reinforce a sense of responsibility in Debian.

You can't reinforce or enforce ethics - attempting to do so merely
gives you obedience, or a herd mentality. And I don't think that a
blame culture will accomplish anything.

On the other hand, I think there might be some benefit to requiring
that the Maintainer field must always denote one single Debian
developer, who would be the "buck stops here" guy for that
package. Not an applicant, not a mailing list, and not a group of
people. I believe the tools have now advanced to the point where this
is a practical option.

In general you're always far better off forcing every *change* to a
given component to go through a single individual. Large projects need
a pumpking, because dogpiling creates lousy software. For Debian this
would be cumbersome and unwieldy as a rule, but some high-importance
tasks could benefit from it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Thoughts on Debian quality, including automated testing

[Raphael Hertzog]

For the record, I have been favorable to team maintenance for years.
That's why the PTS begs for co-maintainers on packages of priority
standard or higher. That's why I pushed to setup alioth.debian.org.

On Wed, 21 Dec 2005, Thomas Hood wrote:
> It turns out that there is no need for them to be hurt at all.  Lone
> can carry on working as before and find a co-maintainer who won't get
> in his way.  But when Lone falls off his horse he'll be glad that Tonto
> is nearby.  

Unfortunately, this is simply not true for many small packages. None of my
packages are maintained in a team. I tried several times to get help for
libdbd-pg-perl and libdbd-mysql-perl but I never got any (except once).
(Now, I should probably move them to pkg-perl on alioth but I haven't
took the time to do that yet)

That is to say: you can't require the actual maintainer to find
co-maintainer by himself.

I do agree that maintaining more packages in team is a good idea but you
can't decide that it's the rule and be done. What you can do however, is
to work in that direction (like I do).

For example, you could have participated in the thread in debian-qa that I
recently started about "Collaborative maintenance", and put your brightest
ideas in the wiki :
http://wiki.debian.org/CollaborativeMaintenance
http://lists.debian.org/debian-qa/2005/12/msg00026.html

Or more concretely, you can help the maintainers find people to help. I'm
convinced that most maintainers of packages of priority standard or higher
have absolutely nothing against team maintenance but they simply didn't
took the time to organize this. So help them organize the transition !
Find co-maintainers, request an alioth project (or join an already
existing team) and get done with it. Start again with another package...

> In other words, this rule can have only positive effects.  :)

The Debian world has no "police" to force the application of any rule.
Governing the Debian world requires common sense, communication skills
and much time !

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Thoughts on Debian quality, including automated testing

[Thomas Hood]

Since I contributed to taking the thread off on a particular tangent
I feel I should try to bring it back to its original topic, which
is an important one.

I would like to hear some discussion about whether or not the quality
of Debian is high enough; and if it is not high enough, what can be
done to improve it?

Lars's headings were:

A) Prevent bugs from happening in the first place
B) Find and report bugs
C) Fix bugs that have been reported
D) Prevent bugs from entering the archive
Automated testing of program functionality
Let's take quality assurance seriously

Under most of these topics Lars discussed automated testing.  Are
there objections to Lars's concrete proposals (e.g., standardization
on a way to invoke package specific tests)?  Are there other ideas?
Should Debian do more auditing, for example?

For C, Lars discussed different degrees of shift from solitary toward
collective maintainership.  In the sequel opinions were emphatically
expressed that such a shift is not necessarily a good thing.  The
question remains whether better quality can be realized by changing
the organization in some way.  Perhaps not.  Then what other things
can be done to help individual maintainers fix more bugs and fix them
better?
-- 
Thomas Hood


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

Re: Thoughts on Debian quality, including automated testing

[Raphael Hertzog]

On Wed, 21 Dec 2005, Daniel Ruoso wrote:
> Em Qua, 2005-12-21 às 14:34 +, Matthew Garrett escreveu:
> > I think I've said this before, but I have no objections to anyone
> > uploading any of my packages. I'd be even happier if anyone who did so
> > was willing to enter into some sort of reciprocal agreement.
> 
> So do I, but I would be really happy if the uploader knows how I
> maintain the packages (I mean, using CVS, SVN or such) and cooperate
> using such tools.

This is legitimate.

> Maybe it would be interesting to have some information in the package
> saying how the package is managed and the preferrable way of doing an
> NMU (I actually, think that it's desirable to self-include in the
> Uploaders field, to acquire responsability also)...

This is definitely required. If I had time, I would have drafted such a
proposal for the Debian policy.

In the PTS, I'd like to be able to point people to the CVS/SVN/arch
repository used by the maintainers, however I can't because the
information is not stored, or is stored in a non-formal manner in
README.Debian.

Example:
VCS-Maint-Repository: svn://svn.debian.org/svn/pkg-gnome/packages/unstable/gksu
VCS-Maint-Repository: cvs://cvs.debian.org/debian-boot/debian-cd
VCS-Maint-Repository: none

We may also need to be able to specify multiple repositories: for example,
if several branches are maintained in parallel (unstable/experimental), or
maybe for derived distributions like Ubuntu which may want to list there,
the URL of the "branch" that they're maintaining on top of the original
Debian package.

BTW, at the same time, it would be good to add more similar meta-data like
"VCS-Upstream-Repository" or "Upstream-Website" which are definitely
needed to make the PTS effective for QA workers which need to find out the
upstream website/community to seek help, to check for potential patches, etc.

Be my guest, and formalize such a proposal for debian-policy. :-)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Thoughts on Debian quality, including automated testing

[Thijs Kinkhorst]

On Thu, 2005-12-22 at 08:38 +, Andrew Suffield wrote:
> On the other hand, I think there might be some benefit to requiring
> that the Maintainer field must always denote one single Debian
> developer, who would be the "buck stops here" guy for that
> package. Not an applicant, not a mailing list, and not a group of
> people.

This "not an applicant" thing is a bad idea. As you might know, the
NM-process is designed around the idea that someone has to prove they're
up to the task they want to do. That's why for packagers it's required
to have packaging activitity. Disallowing them to have the final
responsibility over a package disables you to evaluate whether they're
actually fit for this responsibility. In the current situation, it's
already clear that the person in the Maintainer field has the final
responsibility, and the sponsor acts as a fallback only.


Thijs


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

Re: Thoughts on Debian quality, including automated testing

[Frank Küster]

Thomas Hood <[EMAIL PROTECTED]> wrote:

> Under most of these topics Lars discussed automated testing.  Are
> there objections to Lars's concrete proposals (e.g., standardization
> on a way to invoke package specific tests)?  Are there other ideas?
> Should Debian do more auditing, for example?

I'm all for automated testing, but I want to support Lars' point that
the burden should be mostly on the people writing the automatisms, not
on individual package maintainers reinventing the wheel.

> Then what other things
> can be done to help individual maintainers fix more bugs and fix them
> better?

It would be good if there was a way to find out "problematic" packages,
by extracting information about

- how many bugs does a package have

- how many of them don't have a single response

- how many have not been dealt with for n months (or days/weeks for RC
  bugs) 

- how many packages depend on the package

and try to create some rating or ordering.  One could then not only
identify packages that could use some work, but also for which of them
it's most useful.

Another good thing would be an effort to go through important packages'
ancient bugs and clear them up.  E.g. all those, mostly years-old dpkg
bugs that report a segfault.  Either something should be done about
them, or they should be closed.  My impression is that dpkg is actively
maintained currently, but had some problems in the past, and the current
maintainers don't have the time to clean up this inherited mess.  It
seems to me that this is a problem in other packages, too.  teTeX is one
of them...


Regards, Frank


-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: /run vs. /lib/run

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Anthony Towns   wrote:
>On Thu, Dec 22, 2005 at 01:37:11AM +, Miquel van Smoorenburg wrote:
>> This works at least on 2.6. [...]
>> This means that /var/run is always writable.
>
>That's really quite nice. I wonder if requiring 2.6 is even much of a
>problem -- 2.6.0 came out two years ago already and will be three by
>the time etch is released, after all; and I assume the Hurd can deal
>with this sort of issue trivially.

Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.

>If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
>use of /var/run, it might be worth just moving them to /var/lib anyway.

Well actually, perhaps we should not even use mount --move. Just
copying the files is enough:

cd /var/run
( cd /; mount -a )
if ! [ . -ef /var/run ]
then
cp -a . /var/run
rm -rf ./*  # (probably not needed)
umount -n -l .
fi
cd /

I tested this and it works fine. It's also a better solution, since
several packages contain directories in /var/run and ofcourse
they expect them to still exist after a reboot.

There's still a problem here - if /var/run is not overmounted,
how do you copy the contents of the current /var/run tmpfs
into the /var/run underneath ?

Perhaps something like this instead:

cd /var/run
( cd /; mount -a )
mount --move . /var/lib/earlyrun
cd /
cp -a /var/lib/earlyrun/. /var/run
umount -n -l /var/lib/earlyrun  # we could try a few times
# without -l first to give
# daemons using early /var/run
# time to realize what happened

There are 2 conditions for programs using "early /var/run",
if they are running as a daemon (eg bootlogd):

1. Don't chdir into /var/run
2. Every so often (before every write), check if open file
   handles for files in /var/run still correspond to the
   actual file - compare fstat() and stat()

For things like pidfiles, resolv.conf, mtab etc it will just work.

The only thing is - this won't work for Debian/kFreeBSD. Someone
needs to write MS_MOVE support for the kFreeBSD kernel, I guess :)

Mike.


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

Re: switching to vim-tiny for standard vi?

[Jon Dowland]

On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote:
> su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
> > We already have two editors in the base system, nvi and nano.
> 
> Yes, that being the bloat I was referring to.

I think there should be at least one non-modal editor in base.

-- 
Jon Dowland
http://alcopop.org/


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

RFH: kernel-patch-suspend2

[martin f krafft]

Hi,

I am the maintainer of kernel-patch-suspend2 in Debian experimental.
Due to my tendonitis, I am unable to incorporate some necessary
changes to the package, so it's hopelessly outdated. I am thus
looking for people temporarily or permanently interested in helping
with the package. If it is any motivation, then I can say that the
package is rather clean and complex, so it's quite an enjoyable
challenge to maintain. I have previously called it the most complex
kernel patch package in the Debian archive, as it uses all kinds of
kernel-package, mkinitrd, and kernel-image hooks.

Here's an approximate TODO list, with priorities 1(highest)-3:

  - [1] upgrade to/incorporate latest versions (for 2.6.14)
  - [1] migrate from mkinitrd to yaird support
  - [2] migrate to debconf, like kernel-package has done.
  - [2] enable filewriter support
* already done quick'n'dirty in my repo
* ideally add debconf support and coordinate with hibernate
  package for better integration (shared debconf entries,
  filewriter location, swap file creation)
  - [3] improve patching system. right now, I include the original
patch, and a patch against the patch to make it compile
against Debian kernels. this can get hairy. ideally use
dh_kpatches and add support for Debian and vanilla kernels
without patching patches.

Interested parties please reply privately. I'd enjoy working with
others on this. We can create an alioth project if necessary.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"you don't sew with a fork, so I see no reason
 to eat with knitting needles."
   -- miss piggy, on eating chinese food


signature.asc
Description: Digital signature (GPG/PGP)

Re: Remove an ITP

[Frank Küster]

Claudio Moratti <[EMAIL PROTECTED]> wrote:

> Hi *
>
> I sent, some time ago, two ITPs: vamps (#320067) and k9copy (#320045)...
>
> Packages are ready, but vamps can not enter in Debian, because the upstream 
> author don't want to make public his real identity (now in debian/copyright 
> I've a "Vamps Admin ", but this solution does not follow the Debian 
> Policy

Why do you think this would violate the policy?  Of course we must have
a clear indication that the person who put a "This is licensed under
FOO" into the files is actually the one who wrote the code; but I can't
see how this is less or more guaranteed in your case compared to any
freshmeat/sourceforge/whatever download; they don't require to check
your ID card, let alone sign keys or whatever.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: /run vs. /lib/run

[Peter Samuelson]

[Miquel van Smoorenburg]
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse they
> expect them to still exist after a reboot.

That's a bug, IMO - they should mkdir -p in their init scripts if
necessary.  It's not like that's hard to do.


signature.asc
Description: Digital signature

Re: Thoughts on Debian quality, including automated testing

[Adrian von Bidder]

On Thursday 22 December 2005 09.38, Andrew Suffield wrote:
> On the other hand, I think there might be some benefit to requiring
> that the Maintainer field must always denote one single Debian
> developer, who would be the "buck stops here" guy for that
> package. Not an applicant, not a mailing list, and not a group of
> people. I believe the tools have now advanced to the point where this
> is a practical option.

Now that's an idea I like.

-- vbi

-- 
Vote for me.  You may not agree with me, but at least I understand
what's going on
-- steevo in news.admin.net-abuse.email


pgpZAnkSfkdce.pgp
Description: PGP signature

Re: Thoughts on Debian quality, including automated testing

[Adrian von Bidder]

Thomas, sorry for continuing the debate still on this single aspect of Lars' 
mail :-)

On Thursday 22 December 2005 10.02, Thomas Hood wrote:
> C) Fix bugs that have been reported
> For C, Lars discussed different degrees of shift from solitary toward
> collective maintainership.  In the sequel opinions were emphatically
> expressed that such a shift is not necessarily a good thing.

Hmm.  AFAICS The strongly voiced opinions have only opposed to the *force* 
team maintainership thing.  That team maintainership *when the maintainers 
want it* is a good idea and should probably be encouraged has not been 
debated.  There was some argument whether team maint of trivial, small 
packages makes sense and there was Frank's statement about large-scale 
teams which I completely agree with.

cheers
-- vbi

-- 
The prablem with Manoca is thot it's difficult ta tell the difference
between o cauple af the letters.
-- Jacob W. Haller on alt.religion.kibology


pgp6rQJXKEjG0.pgp
Description: PGP signature

Re: RFH: kernel-patch-suspend2

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2005.12.22.1129 +0100]:
> Interested parties please reply privately. I'd enjoy working with
> others on this. We can create an alioth project if necessary.

My latest working tree is at 

  http://madduck.net/~madduck/scratch/kernel-patch-suspend2_2.2-0.rc14.1.tar.gz

Note that the package is already at 2.2-0.rc14.1, but I have not
incorporated 2.2 yet. The latest version included is 2.1.9.9 for
2.6.12. The tendonitis came unexpectedly.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
* Overfiend came out of the womb complaining.
-- #debian-devel


signature.asc
Description: Digital signature (GPG/PGP)

Re: Thoughts on Debian quality, including automated testing

[Adrian von Bidder]

On Thursday 22 December 2005 10.55, Frank Küster wrote:
> - how many bugs does a package have
> - how many have not been dealt with for n months (or days/weeks for RC
>   bugs)

Changing the default ordering on the bts web pages from bug age to 'last 
action age' might already show some effect.

Hmmm.  But it'd make the ordering much more volatile.  So maybe bad idea?  
But at least displaying time since last update alongside the age of the bug 
might make sense.

-- vbi

-- 
It works! Now if only I could remember what I did...


pgpCfq75DxBf2.pgp
Description: PGP signature

Re: switching to vim-tiny for standard vi?

[Lars Wirzenius]

to, 2005-12-22 kello 10:20 +, Jon Dowland kirjoitti:
> On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote:
> > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
> > > We already have two editors in the base system, nvi and nano.
> > 
> > Yes, that being the bloat I was referring to.
> 
> I think there should be at least one non-modal editor in base.

Behold the awesome non-modality of nano.

-- 
Boilerplate programming mean tools lack power.


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

Re: /run vs. /lib/run

[Henrique de Moraes Holschuh]

On Thu, 22 Dec 2005, Miquel van Smoorenburg wrote:
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse
> they expect them to still exist after a reboot.

It is trivial to enhance these packages to support an ephemeral /var/run, if
it comes to 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


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

Re: /run vs. /lib/run

[Russell Coker]

On Thursday 22 December 2005 20:58, "Miquel van Smoorenburg" 
<[EMAIL PROTECTED]> wrote:
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:

Copying the files won't work well if some of them are open at the time...

> There are 2 conditions for programs using "early /var/run",
> if they are running as a daemon (eg bootlogd):
>
> 1. Don't chdir into /var/run

Why not?  mount --move works even when programs have their current directory 
under the tree that's being moved.

> 2. Every so often (before every write), check if open file
>handles for files in /var/run still correspond to the
>actual file - compare fstat() and stat()

Not needed if mount --move is used instead of copying the files.

> The only thing is - this won't work for Debian/kFreeBSD. Someone
> needs to write MS_MOVE support for the kFreeBSD kernel, I guess :)

Or we can just require that kFreeBSD users not have a separate /var partition.  
It's not as if Debian/kFreeBSD has many users.

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


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

Re: c2a transition: libraries still needing transition

[Adeodato Simó]

* Aaron M. Ucko [Wed, 21 Dec 2005 15:17:31 -0500]:

> It's not quite that simple, as some applications will also need
> sourceful uploads because tight dependencies between binary-all and
> binary-arch packages yielded broken binNMUs:

>   cinepaint
>   kgeography
>   pingus

> (maybe others, those are just the ones I've run into that haven't been
> fixed yet).  Surprisingly, only pingus has a bug open about the matter
> (#342231).

  Bugs filed against cinepaint (344400), kgeography (344403) and also,
  ickle (344402). asc had one (343216), I've adjusted its severity.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol


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

Re: Size matters. Debian binary package stats

[Michelle Konzack]

Am 2005-12-18 12:36:05, schrieb Ron Johnson:
> On Sun, 2005-12-18 at 12:59 +0100, Steinar H. Gunderson wrote:
> > On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> > > I've run some scripts to find out the size of binary pakcages in debian
> > > and how theycould be made smaller, here's the results:
> > 
> > My comments are about the same as on IRC:
> > 
> >   - Disk space is cheap, bandwidth is cheap.
> 
> Spoken like someone who's never had to pay for a server room.

ACK.

My Internet Connection in Paris/France and Offenburg/Germany
went
France  Germany

E1 (colo) 2.460   480   Euro/month

E3 (colo)17.600  2100   Euro/month

  incl. traffic  8 Euro/GByte

STM-1 (FO)   32.000 42.000  Euro/month
  incl. traffic  incl. traffic
   using my own CISCO 7xxx

Curently I have in France a singel E3 with E1 Backup
and in Germany a Dual E1.

Betweex X-mas and new year, I will instal my third Server
in Swiss and the price is between Germany and France.

I have already read in debian-isp, that in the USA ate STM-4
(622 MBit, FiberOptic) are availlable for 120.000 US$/month.

Oops!!!

Oh yes, a E1 in Morocco cost around 7000 Euro, an E3 43.00 Euro
and a STM-1 is around 130.000 Euro.  All prices per Month !!!

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: Size matters. Debian binary package stats

[Michelle Konzack]

Hi Andrew,

Am 2005-12-19 03:02:06, schrieb Andrew Suffield:

> I wish we could get it that cheap for my day job. What we have to pay
> to get useful bandwidth has more zeros in it.

I feel with you, because I have an E3 in Morocco and must pay
450.000 DHs wich are around around 43.000 Euro per month.

Currently I have a Proxim Tsunami MP.11a OutDoor-Router and
two Lucent Stinger IP DSLAM with each 24 Ports plus a Debian
"portslave" with 2 Cyclades PC400-Modem (each 60 Ports)

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: Size matters. Debian binary package stats

[Michelle Konzack]

Am 2005-12-19 09:56:27, schrieb Olaf van der Spek:

> > I wish we could get it that cheap for my day job. What we have to pay
> > to get useful bandwidth has more zeros in it.
> 
> Are you paying > 10 $/gb?
> Where is it that expensive?

I pay 450.000 DHs (around 57.000 US$) in Morocco
for an E3 (34 MBit) with traffic included.

An Internet Access 128/64 KBit is arRound 24 US$
and 1024/128 KBIT 90 US$.  SO THINK TWICE!

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: Thoughts on Debian quality, including automated testing

[Petter Reinholdtsen]

[Russ Allbery]
> Also, I think this is a little silly for small packages.  My
> experience with this sort of volunteer work in other areas is that
> if one person does nearly all the work on a regular basis, you're
> not gaining that much by having a backup.  The person who is
> theoretically the backup isn't up to speed on the package anyway and
> is going to be starting roughly as cold as any other random person
> out there.

Did you miss the point that a package need to rot quite a long time
before packages are taken out of the hands of a missing or useless
maintainer?  If there is a co-maintainer, he will most likely not wait
that long before he continue maintenance of the package.

You seem to be talking about a "co-maintainer" whose entire
responsibility is to be listed in the uploaders field, while I talk
about co-maintainers which have expressed interest in actually
maintaining a package.  The latter are quite likely to be able to take
over when the primary maintainer us unable to keep up with his tasks.


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

Re: Size matters. Debian binary package stats

[Florian Weimer]

* Michelle Konzack:

> Am 2005-12-19 09:56:27, schrieb Olaf van der Spek:
>
>> Are you paying > 10 $/gb?
>> Where is it that expensive?
>
> I pay 450.000 DHs (around 57.000 US$) in Morocco
> for an E3 (34 MBit) with traffic included.

With traffic included?  How's that more than 10$ per gigabyte
transferred and month? 8-)


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

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/21/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > Are you paying > 10 $/gb?
>
> Heck yes, you can't get it that cheap unless you have no SLA (or one
> of those insulting SLAs that come with residential service, claiming
> that it doesn't have to work at all). And you can't get that at all on
> a pipe of any significant size (unless you're big enough to work out a
> peering agreement). We pay per month though, not per byte.

That's unlimited traffic then I assume?
At 1 mbyte/s (average) you'd be paying > 25000 $/month.

But do you actually need very high uptime for very large transfers?

Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan <[EMAIL PROTECTED]>

* Package name: freebsd6-buildutils
  Version : 6.0
* URL : http://www.freebsd.org/
* License : BSD
  Description : Utilities for building FreeBSD 6.x sources

 This package contains the FreeBSD 6.x counterparts of some standard build
 utilities (make, yacc, lex ..)
 .
 They have some specific modifications needed to be able to build FreeBSD 6.x
 sources.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)


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

Bug#344419: ITP: kfreebsd-6 -- kernel of FreeBSD 6.x

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan <[EMAIL PROTECTED]>

* Package name: kfreebsd-6
  Version : 6.0
* URL : http://www.freebsd.org/
* License : BSD
  Description : kernel of FreeBSD 6.x

kfreebsd-source-6.0:

  Description: source code for kernel of FreeBSD 6.0 with Debian patches
  This package provides the source code for kernel of FreeBSD 6.0, base of
  a GNU/kFreeBSD system.

Description for the other, kfreebsd-i386-specific binary packages is analogous
to the ones in kfreebsd-5 debian/control file.

Preliminar packages available at svn://svn.debian.org/glibc-bsd/trunk/kfreebsd-6

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)


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

Re: /run vs. /lib/run

[Anthony Towns]

On Thu, Dec 22, 2005 at 09:58:37AM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Anthony Towns   wrote:
> >On Thu, Dec 22, 2005 at 01:37:11AM +, Miquel van Smoorenburg wrote:
> >> This works at least on 2.6. [...]
> >> This means that /var/run is always writable.
> >That's really quite nice. I wonder if requiring 2.6 is even much of a
> >problem -- 2.6.0 came out two years ago already and will be three by
> >the time etch is released, after all; and I assume the Hurd can deal
> >with this sort of issue trivially.
> Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.

Dude, so it does! Though in that case the mount manpage is wrong :-/

> >If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
> >use of /var/run, it might be worth just moving them to /var/lib anyway.
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:

That doesn't work if some app keeps the file open while /var is being mounted
though.

> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse
> they expect them to still exist after a reboot.

I suppose that's true; but where's the difficulty in just initialising
/var/run on mount from some template for the programs that need it?

> The only thing is - this won't work for Debian/kFreeBSD. Someone
> needs to write MS_MOVE support for the kFreeBSD kernel, I guess :)

Can't kFreeBSD do transparent mounts anyway, and just mount a real
/var/run over the top of a tmpfs, leaving the tmpfs still visible?

On Thu, Dec 22, 2005 at 05:15:32AM -0600, Peter Samuelson wrote:
> [Miquel van Smoorenburg]
> > I tested this and it works fine. It's also a better solution, since
> > several packages contain directories in /var/run and ofcourse they
> > expect them to still exist after a reboot.
> That's a bug, IMO - they should mkdir -p in their init scripts if
> necessary.  It's not like that's hard to do.

crack and crack-md5 are the only packages that include it in the deb;
the others already do it from the app, init script or postinst. But
we need to support third party apps too; so some special handling's
probably worthwhile.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Size matters. Debian binary package stats

[Eduard Bloch]

#include 
* Goswin von Brederlow [Wed, Dec 21 2005, 05:03:41PM]:

> > $ uncompressor
> > -bash: uncompressor: command not found
> >
> > This solution doesn't look usable in scripts and user have to use a
> > more complex syntax.
> 
> You have to replace uncompressor with whatever tool is the right to
> uncompress the format. Just like you have to use -z or -j depending on
> gzip or bzip2 compression.

"ucat" from the unp package. However, for this purpose it is rather a
cludge and IIRC it does not work with STDIN well.

Eduard.

-- 
Ambassador Londo Mollari: I would remind the Drazi Ambassador that the Centuri
have already signed the declaration.
Citizen G'Kar: And if the Centuri can sign it, anybody can sign it!
Ambassador Londo Mollari: Right!
 -- Quotes from Babylon 5 --


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

Re: Thoughts on Debian quality, including automated testing

[Daniel Ruoso]

Em Qui, 2005-12-22 às 10:22 +0100, Raphael Hertzog escreveu:
> On Wed, 21 Dec 2005, Daniel Ruoso wrote:
> > Maybe it would be interesting to have some information in the package
> > saying how the package is managed and the preferrable way of doing an
> > NMU (I actually, think that it's desirable to self-include in the
> > Uploaders field, to acquire responsability also)...
> In the PTS, I'd like to be able to point people to the CVS/SVN/arch
> repository used by the maintainers, however I can't because the
> information is not stored, or is stored in a non-formal manner in
> README.Debian.

Hmmm... You probably pointed out the best way to achieve that... If you
look carefully, you'll see that the PTS uses informations that are
spreaded around several subsystems...

So, the nicest way is to create yet another subsystem that would manage
this type of information, and once many people starts putting
information there, the PTS will include it also...

daniel


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

Re: Size matters. Debian binary package stats

[Eduard Bloch]

#include 
* Goswin von Brederlow [Wed, Dec 21 2005, 04:19:56PM]:

> > Actual maintainer of dpkg is evaluating the possibility to use 7zip.
> > Even if the decision of using 7zip by default is far from being taken, it 
> > looks
> > likely that dpkg will at least start supporting it.
> >
> > Cheers,
> 
> It can't be the default unless stable dpkg has support for installing
> such debs. That means not before etch+1 or more likely etch+2.

Why not? Use Pre-Depends. Sounds evil but is more reliable than just
hoping that all users always upgrade to the latest stable.

Of course dpkg and all of its dependencies must not be compressed with
7zip.

Eduard.
-- 
Commander Jeffrey David Sinclair: Everyone lies, Michael. The innocent lie
because they don't want to be blamed for something they didn't do and the
guilty lie because they don't have any other choice.
 -- Quotes from Babylon 5 --


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

Re: switching to vim-tiny for standard vi?

[Henning Makholm]

Scripsit Lars Wirzenius <[EMAIL PROTECTED]>
> to, 2005-12-22 kello 10:20 +, Jon Dowland kirjoitti:
>> On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote:
>> > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:

>> > > We already have two editors in the base system, nvi and nano.

>> > Yes, that being the bloat I was referring to.

>> I think there should be at least one non-modal editor in base.

> Behold the awesome non-modality of nano.

Yes; therefore it is not bloat to have nvi and nano both in base; they
satisfy different needs (having a vi because we're unix resp. having a
non-modal editor for the rest of us).

-- 
Henning Makholm"There is a danger that curious users may
  occasionally unplug their fiber connector and look
  directly into it to watch the bits go by at 100 Mbps."


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

Re: Thoughts on Debian quality, including automated testing

[Russ Allbery]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Russ Allbery]

>> Also, I think this is a little silly for small packages.  My experience
>> with this sort of volunteer work in other areas is that if one person
>> does nearly all the work on a regular basis, you're not gaining that
>> much by having a backup.  The person who is theoretically the backup
>> isn't up to speed on the package anyway and is going to be starting
>> roughly as cold as any other random person out there.

> Did you miss the point that a package need to rot quite a long time
> before packages are taken out of the hands of a missing or useless
> maintainer?

Maybe that's the problem that you should concentrate on fixing instead of
trying to work around it with a solution that won't necessarily fix it and
which adds pointless overhead to packages that are well-maintained?

> If there is a co-maintainer, he will most likely not wait that long
> before he continue maintenance of the package.

Or maybe he'll be so uninterested in the package since there's never been
anything for him to do that he won't even notice the problem and won't be
any improvement over not having a co-maintainer at all.

> You seem to be talking about a "co-maintainer" whose entire
> responsibility is to be listed in the uploaders field, while I talk
> about co-maintainers which have expressed interest in actually
> maintaining a package.  The latter are quite likely to be able to take
> over when the primary maintainer us unable to keep up with his tasks.

I'm pointing out that if you require co-maintainers for small packages,
what you're going to get is a whole bunch of the former.  There isn't
enough work for two people, plus people annoyed with the rule will list
co-maintainers in order to make people stop bugging them.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

[Help] sgml-speaking person needed to fix cdbs FTBFS

[Frank Küster]

tags 339806 help
thanks

Hi,

db2latex-xsl has a bug that causes cdbs to FTBFS, and this bug has been
open and without a comment for more than a month now.  The problem is
that a buggy LaTeX input file is generated, and I have already posted to
the bug how a correct file would look like.  But I don't speak sgml or
xml or whatever, and have no idea how to achieve this.



-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Thoughts on Debian quality, including automated testing

[Russ Allbery]

Frank Küster <[EMAIL PROTECTED]> writes:

> It would be good if there was a way to find out "problematic" packages,
> by extracting information about

> - how many bugs does a package have
> - how many of them don't have a single response
> - how many have not been dealt with for n months (or days/weeks for RC
>   bugs) 
> - how many packages depend on the package

> and try to create some rating or ordering.  One could then not only
> identify packages that could use some work, but also for which of them
> it's most useful.



Was posted to debian-devel a few days ago.  :)

> Another good thing would be an effort to go through important packages'
> ancient bugs and clear them up.  E.g. all those, mostly years-old dpkg
> bugs that report a segfault.  Either something should be done about
> them, or they should be closed.

Amen to this.  As soon as I finish a few other projects related to my own
packages, I'd been thinking about picking one of those packages and
volunteering to do bug triage.  I don't see how anyone can find anything
in the BTS when a package has hundreds of bugs, and certainly I doubt new
bug reporters are really reviewing all of the existing bugs if there are
more than a hundred of them.  (debbugs's strong point is handling a small
number of bugs on *lots* of different packages; I find it somewhat
difficult to follow when dealing with a *lot* of bugs on a single
package.)

-- 
Russ Allbery ([EMAIL PROTECTED])   

[Help] sgml-speaking person needed to fix cdbs FTBFS

[Frank Küster]

tags 339806 help
thanks

Hi,

db2latex-xsl has a bug that causes cdbs to FTBFS, and this bug has been
open and without a comment for more than a month now.  Since cdbs is
kind of a central package, this is too long.

The problem is that a buggy LaTeX input file is generated, and I have
already posted to the bug how a correct file would look like.  But I
don't speak sgml or xml or whatever, and have no idea how to achieve
this.

It would be great if someone could volunteer to address this.  If you
have further LaTeX-related questions, I'm happy to help (please contact
debian-tetex-maint@lists.debian.org). 

TIA, Frank

(sorry for the prematurely sent first version of this mail)

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Thoughts on Debian quality, including automated testing

[Frank Küster]

Russ Allbery <[EMAIL PROTECTED]> wrote:

> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> It would be good if there was a way to find out "problematic" packages,
>> by extracting information about
>
>> - how many bugs does a package have
>> - how many of them don't have a single response
>> - how many have not been dealt with for n months (or days/weeks for RC
>>   bugs) 
>> - how many packages depend on the package
>
>> and try to create some rating or ordering.  One could then not only
>> identify packages that could use some work, but also for which of them
>> it's most useful.
>
> 
>
> Was posted to debian-devel a few days ago.  :)

That's a nice starter;  the number of depending and build-depending
package would be a nice extension.

Thanks, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Thoughts on Debian quality, including automated testing

[Erinn Clark]

* Christian Perrier <[EMAIL PROTECTED]> [2005:12:22 08:10 +0100]: 
> > > Bureaucracy is often designed to do lots of things "better" and it often
> > > doesn't achieve them. It creates needless hassle, more 'paperwork', and
> > > has very few benefits besides making people feel like they've done
> > > something useful when they haven't. 
> > 
> > You are saying that requiring people to find co-maintainers is
> > "bureaucracy"?  Someone I know well recently got co-maintainers for
> > three of his packages by posting a single message to debian-devel.
> 
> I think that what Erinn wants to say is more that *forcing* (or
> putting pressure on) maintainers to find co-maintainers would be
> "bureaucracy".

If something makes people's lives complicated for no gain and makes them
jump through hoops to get the same exact thing done, I consider it
bureaucracy. This rule would qualify under that definition. 

> I think that she will however agree that *encouraging* co-maintenance
> for "key" or "important" packages (which is a very vague definition)
> is one of the ways to go. But she will probably be able to say it by
> herself: I'm just interpreting

Not necessarily. I would encourage team maintenance on either
exceptionally large packages (or groups of small packages) or 
packages where the maintainer is unable to handle the amount of work
(bug reports, constant upstream releases, etc.) Conversely, I might also
encourage single-person maintenance on packages with ineffective teams
(see Andrew Suffield's mail about this; he basically covers this
territory.)

The fact that a package is important (note: not referring to Priority
here) is not indicative of the amount of work necessary, nor is it
indicative of the amount of time and expertise a given maintainer has 
for it. 

-- 
off the chain like a rebellious guanine nucleotide


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

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Stefano Zacchiroli]

On Thu, Dec 22, 2005 at 03:43:14PM +1000, Anthony Towns wrote:
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> downgrading that dependency a possibility, so base could include the
> regular vim binary plausible?

The philosophy in the packaging has been:
* vim-tiny -> has smaller as possible version of vim
* vim -> ordinary vim

vim-tiny has thus been compiled with a small subset of features _and_
minimizing dependencies. vim with a standard set of features without
caring about dependencies.

I don't like downgrading the vim -> vim-runtime dependency since IMO if
a user apt-get-installs vim he expect a fully working vim installation
(including help and syntax highlighting).

If there's the need of more vim features in the standard installation I
would rather prefer to tune vim-tiny compilation including more
features. On this subject, please note that adding gpm support will
trigger the additional libgpmg1 dependency.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi?

[Andreas Metzler]

Riku Voipio <[EMAIL PROTECTED]> wrote:
> While I'm a addicted vim user, the build-dependencies of vim(-tiny)
> is a bit scary for a base package. While we do not have requirements
> of base packages of being easily buildable, changing to vim-tiny
> will make bootstrapping a basic debian system again a little bit
> harder.

> nvi:

> Build-Depends: debhelper, libncurses5-dev

> vs

> vim-tiny:

> Build-Depends: debhelper (>= 4.2.21), dpkg (>> 1.7.0), bzip2, perl (>= 5.6), 
> libgpmg1-dev [!hurd-i386] | not+linux-gnu, libperl-dev (>= 5.6), tcl8.4-dev 
> [!hurd-i386] | tcl8.3-dev [!hurd-i386], python-dev, libncurses5-dev, ruby, 
> ruby1.8-dev | ruby-dev, libgtk2.0-dev (>= 2.2) | libgtk1.2-dev, 
> libgnomeui-dev [!hurd-i386], lesstif2-dev

As Joey already remarked moving vim to base has no effect on
bootstrapping, because it does change _when_ in the process vim is
built.

However, the nvi is evidently a lot simpler than vim and less likely
both to show from rc-bugs to suffer from being kept out of testing due
to rc-bugs in its build-depencies. This might make a difference the
base-freeze slightly more difficult.
   cu andreas



-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Stefano Zacchiroli]

On Wed, Dec 21, 2005 at 05:41:45PM -0600, Steve Greenland wrote:
> > vim-tiny depends on the 200k-ish vim-common too, so nvi seems
> > about half the total size of a vim-tiny today.
> Okay, so that's not "about the same". Stefano? If the above numbers are

If this is some kind of insinuation, ... well, I'm kind of pissed-off by
it.  I never used the expression "about the same". Joey forwarded a post
of mine containing the verbatim words:

   The installed-size of it and of vim-common are as I anticipated (776
   + 232 on i386); 

[ vim-common is now some Kb smaller, but this is not relevant here ]

In the very same post Joey correctly added:

  It's now only marginally larger than nvi

Thus, no one of the proposer speaked of something "about the same".

> correct, then the best case is a (696+200-560)==336K increase. Last I
> heard, the CD builders considered that a non-trivial amount of space. Or
> am I confusing the boot image with base?

I asked Joey, as one of the installer maintainer, and for him the size
increase is not a problem. If it is a problem for the CD builders, they
can speak in this thread. If it is not a problem for these people, why
is it a problem for you?

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi?

[Andreas Metzler]

Andreas Metzler <[EMAIL PROTECTED]> wrote:
[...]
> bootstrapping, because it does change _when_ in the process vim is
^
   not


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

Re: Thoughts on Debian quality, including automated testing

[Christian Perrier]

> The fact that a package is important (note: not referring to Priority
> here) is not indicative of the amount of work necessary, nor is it
> indicative of the amount of time and expertise a given maintainer has 
> for it. 


Sure. However, an "important" package will more badly suffer from lack
of maintenance during several months or even years.

This is the main weakness of packages maintained by single
individuals. By experience, it takes time before it becomes obvious
that the person who was very well maintaining this or that package is
no more able to do soor lacks time and is slowly neglecting it.

At the very minimum, a team maintenance will increase our chances to
have a faster reaction in such cases

I perfectly hear your objection to an increased pressure to use team
maintenance and maybe avoid putting too much "social pressure" for
team maintaining everything. I think this discussion had the advantage
of making the issues clearer and give more clues to people who will
have to make the choice of team-maintaining something.




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

debbugs tangent (was Re: Thoughts on Debian quality, including automated testing)

[Erinn Clark]

* Russ Allbery <[EMAIL PROTECTED]> [2005:12:22 09:14 -0800]: 
> (debbugs's strong point is handling a small
> number of bugs on *lots* of different packages; I find it somewhat
> difficult to follow when dealing with a *lot* of bugs on a single
> package.)

OT for this thread, but: do you notice this even with usertags/user
categories? I'd be curious to hear suggestions for improvements.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: debbugs tangent

[Russ Allbery]

Erinn Clark <[EMAIL PROTECTED]> writes:
> * Russ Allbery <[EMAIL PROTECTED]> [2005:12:22 09:14 -0800]:

>> (debbugs's strong point is handling a small number of bugs on *lots* of
>> different packages; I find it somewhat difficult to follow when dealing
>> with a *lot* of bugs on a single package.)

> OT for this thread, but: do you notice this even with usertags/user
> categories? I'd be curious to hear suggestions for improvements.

I'm not sure yet; I haven't tried hard to use usertags to work around
this.  For the packages I've worked on so far, it's been easier to just
fix the bugs until the bug list got down to something reasonable.  I think
it's likely to help a great deal, though, and may largely take care of the
problem for developers (although it doesn't help the reportbug problem).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

(no subject)

[Arttest]

please uninstall callwave [EMAIL PROTECTED]

New experimental sysvinit

[Thomas Hood]

A new version of sysvinit is being prepared for release to experimental.

1. We'll omit /run from this since debate about it continues unabated.

2. One thing I would like to do in this release is to remove the
dynamically created/deleted /etc/login file from the root filesystem.
It is proposed that initscripts create and delete a flag file in
/var/lib/initscripts/ and that /etc/nologin become a symbolic link to
/var/lib/initscripts/nologin.  Then the administrator then has these
options:

  No-login mode at boot until boot complete:   DELAYLOGIN=yes
  No-login mode never: DELAYLOGIN=no
  No-login mode always:  rm -f /etc/nologin ; :> /etc/nologin

Anyone see any problems with this scheme?  Any better ideas?
-- 
Thomas Hood


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

New experimental sysvinit

[Thomas Hood]

(Improved version, sans confusing typo.)

A new version of sysvinit is being prepared for release to experimental.

1. We'll omit /run from this since debate about it continues unabated.

2. One thing I would like to do in this release is to remove the
dynamically created/deleted /etc/nologin file from the root filesystem.
It is proposed that initscripts create and delete the nologin flag file
in /var/lib/initscripts/ and that /etc/nologin become a symbolic link
to /var/lib/initscripts/nologin.  Then the administrator then has these
options:

  No-login mode at boot until boot complete: DELAYLOGIN=yes
  No-login mode never:  rm -f /var/lib/initscripts/nologin ; DELAYLOGIN=no
  No-login mode always: touch /var/lib/initscripts/nologin ; DELAYLOGIN=no

Anyone see any problems with this scheme?  Any better ideas?
-- 
Thomas Hood


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

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> to do.
> 2. nameif has issues when using /etc/mactab.  I can't remember the exact 
> problems as I can't access that machine right now, but I couldn't get 
> nameif to work that way.

you should  not try to assign ethX because of the not-temp-rename problem.

BTW: i refuse to add a init script for mactab, for exactly the reason i
think it belongs in the interfaces file.

Gruss
Bernd


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

Closing bugs due to removed code (was Re: Re: c2a transition: libraries still needing transition)

[Filipus Klutiero]

BTW: there are in bts some translations of fuse's debconf templates... may
I close these bugs with the upload which will remove templates at all or
should I close them manually with explanation that there won't be any
questions since now?




As you want. See for example 
http://packages.qa.debian.org/b/base-config/news/1.html



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

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[MJ Ray]

Stefano Zacchiroli <[EMAIL PROTECTED]>
> [...] In the very same post Joey correctly added:
>   It's now only marginally larger than nvi [...]

167% is a rather big margin, isn't it?

> I asked Joey, as one of the installer maintainer, and for him the size
> increase is not a problem. If it is a problem for the CD builders, they
> can speak in this thread. If it is not a problem for these people, why
> is it a problem for you?

If one is honest and says that vim-tiny will replace nvi because
the decision-makers prefer it, then that's fine, but this
doesn't look like a technically-based decision.  It doesn't
seem supported by current data to claim that vim-tiny isn't
a real size increase, or that this doesn't mean most vi users
(both vim-fans and vim-haters) will want to install another vi
besides the default one.

Are there many vi users who will just use vim-tiny?
Most "small vi" users don't seem to like vim, IME.

-- 
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/  irc.oftc.net/slef  Jabber/SIP ask


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

Re: /run vs. /lib/run

[Gabor Gombas]

On Thu, Dec 22, 2005 at 05:18:43PM +1100, Russell Coker wrote:

> Putting system directories under /tmp is a really bad idea, it opens 
> possibilities of race condition attacks by unprivileged users against system 
> processes.  Generally for almost everything we should be looking to reduce 
> usage of /tmp rather than increase it.

There are no user processes while scripts in /etc/rcS.d are running (not
even crontabs, since cron itself has not been started yet). And after
rc.S has finished, there is no justification to use /run. I do not see
the problem with using /tmp for /run.

Moreover, I still mean to mount a temporary tmpfs over /tmp, so unless
you explicitely do a "chmod a+w /tmp", normal user processes will not
even be able to write to /tmp until the real /tmp is mounted (or if /tmp
is on /, until the tmpfs is unmounted).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -


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

Re: Thoughts on Debian quality, including automated testing

[Raphael Hertzog]

On Thu, 22 Dec 2005, Daniel Ruoso wrote:
> > In the PTS, I'd like to be able to point people to the CVS/SVN/arch
> > repository used by the maintainers, however I can't because the
> > information is not stored, or is stored in a non-formal manner in
> > README.Debian.
> 
> Hmmm... You probably pointed out the best way to achieve that... If you
> look carefully, you'll see that the PTS uses informations that are
> spreaded around several subsystems...

I know that, I've written it ! :-)

> So, the nicest way is to create yet another subsystem that would manage
> this type of information, and once many people starts putting
> information there, the PTS will include it also...

Why should I create yet another unofficial thing while we already have
proper infrastructure in place to distribute meta-data about our packages ?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: /run vs /var/run

[Gabor Gombas]

On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote:

> 368K is an issue on a machine with 8M of RAM, it's an annoyance if you have 
> 16M, beyond about 32M it stops being a problem.

Yeah, and a new optimization step only takes a few thenth of a second and
only a few extra KB of memory, so why not add it. And then everyone
complains that newer gcc versions are far slower than 2.95 was, and some
people can no more build complex applications due to the extra memory
requirements. It was just 0.1% bloat every time...

> Incidentally if 368K of memory is a problem for you then you should probably 
> stop using Ext3.  Ext2 uses less RAM (and that's RAM for non-pagable data).

I hope you've already packed the UPS you're sending me. Once I receive
it, I'll gladly convert my ext3 filesystems to ext2. Until then please
do not compare apples to oranges.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -


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

Re: /run vs /var/run

[Russell Coker]

On Friday 23 December 2005 10:48, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote:
> > 368K is an issue on a machine with 8M of RAM, it's an annoyance if you
> > have 16M, beyond about 32M it stops being a problem.
>
> Yeah, and a new optimization step only takes a few thenth of a second and
> only a few extra KB of memory, so why not add it. And then everyone
> complains that newer gcc versions are far slower than 2.95 was, and some
> people can no more build complex applications due to the extra memory
> requirements. It was just 0.1% bloat every time...

If the changes make things better for people who have machines that are <5 
years old then making them slightly worse for people with ancient hardware is 
not a big deal IMHO.

Regarding building complex applications, there are lots of decently powerful 
machines on the net that you can use for such things.  I've got a machine 
with 2*P3-1GHz CPUs, 2*18G 10,000rpm U160 SCSI disks (and a couple more disks 
available without cables), and a gig of RAM (might be able to find a second 
gig) that I want to donate for such use.  All I need is a place to host it in 
Melbourne (or someone who wants to pay postage to somewhere else that it can 
be hosted).  It needs an ATX 2.0 PSU, but I'm sure I'll find someone willing 
to donate that.  Incidentally it's the most powerful machine I've ever owned 
and it's significantly faster in every way than the machines I use for my 
regular work.  If it wasn't unreasonably noisy I'd run it at home.

The machine is aimed to be used as part of the nipl.net project (see 
http://www.nipl.net for details).  There is an admin team ready to run it and 
they want to use Debian.

> > Incidentally if 368K of memory is a problem for you then you should
> > probably stop using Ext3.  Ext2 uses less RAM (and that's RAM for
> > non-pagable data).
>
> I hope you've already packed the UPS you're sending me. Once I receive
> it, I'll gladly convert my ext3 filesystems to ext2. Until then please
> do not compare apples to oranges.

If you are concerned about what happens when a machine crashes then you should 
want to have the commonly written transient files on a tmpfs.  Having a quiet 
file system is the best way of surviving a sudden power failure.  Note that 
there are many hardware issues related to power failure that ext3 can't fix.  
Data journalling can help but not many people use that feature.

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


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

Re: New experimental sysvinit

[Linas Zvirblis]

Thomas Hood wrote:


  No-login mode at boot until boot complete: DELAYLOGIN=yes
  No-login mode never:  rm -f /var/lib/initscripts/nologin ; DELAYLOGIN=no
  No-login mode always: touch /var/lib/initscripts/nologin ; DELAYLOGIN=no

Anyone see any problems with this scheme?  Any better ideas?


This might be a silly question, but what would happen if DELAYLOGIN=yes 
and /var/lib/initscripts/nologin does not exist?



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

Re: /run vs. /lib/run

[Russell Coker]

On Friday 23 December 2005 10:36, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 22, 2005 at 05:18:43PM +1100, Russell Coker wrote:
> > Putting system directories under /tmp is a really bad idea, it opens
> > possibilities of race condition attacks by unprivileged users against
> > system processes.  Generally for almost everything we should be looking
> > to reduce usage of /tmp rather than increase it.
>
> There are no user processes while scripts in /etc/rcS.d are running (not

There are processes run from rcS.d that use data written by untrusted user 
processes, /etc/init.d/nviboot is one example.

There are also processes that read network data (which is potentially 
hostile).  /etc/init.d/ntpdate is one example.

> even crontabs, since cron itself has not been started yet). And after
> rc.S has finished, there is no justification to use /run. I do not see
> the problem with using /tmp for /run.

Why not use /home?  Why not /root?  Both of those directories will work and 
should not be accessed from rcS.d, but for good design we don't want to do 
this.

One of the problems with using a directory such as /tmp in a way other than 
it's usual design under extraordinary circumstances is that people will see 
the code in question, not understand the situation in which it was run, and 
write other code that runs in multi-user mode which does similar things.  
Another problem is that code which is written to run in single-user mode may 
get changed to run in multi-user mode.  A little thing like insecure 
temporary file use in /tmp is not something that a typical sys-admin or 
programmer is likely to notice when changing a program to run at a different 
time.

> Moreover, I still mean to mount a temporary tmpfs over /tmp, so unless
> you explicitely do a "chmod a+w /tmp", normal user processes will not
> even be able to write to /tmp until the real /tmp is mounted (or if /tmp
> is on /, until the tmpfs is unmounted).

The default for a tmpfs is that the root directory is mode 1777, so if you 
don't explicitly remove such access then it's granted.  You might want to do 
some tests of some of the things you are suggesting.

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


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

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Anthony Towns]

On Thu, Dec 22, 2005 at 10:38:31PM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > to do.
> > 2. nameif has issues when using /etc/mactab.  I can't remember the exact 
> > problems as I can't access that machine right now, but I couldn't get 
> > nameif to work that way.
> you should  not try to assign ethX because of the not-temp-rename problem.
> BTW: i refuse to add a init script for mactab, for exactly the reason i
> think it belongs in the interfaces file.

So what's the problem with adding a pre-up.d script?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Anthony Towns]

On Thu, Dec 22, 2005 at 07:39:59PM +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 22, 2005 at 03:43:14PM +1000, Anthony Towns wrote:
> > > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > > nvi ranges from 560 to 1040 with a median of 648k
> > vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> > downgrading that dependency a possibility, so base could include the
> > regular vim binary plausible?
> The philosophy in the packaging has been:
> * vim-tiny -> has smaller as possible version of vim
> * vim -> ordinary vim
> vim-tiny has thus been compiled with a small subset of features _and_
> minimizing dependencies. vim with a standard set of features without
> caring about dependencies.

Hrm, I see the figures above are mixing .deb and installed sizes too. The
deb sizes are nvi=288k, vim-tiny=377k, vim=570k.

> I don't like downgrading the vim -> vim-runtime dependency since IMO if
> a user apt-get-installs vim he expect a fully working vim installation
> (including help and syntax highlighting).

Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
Or would vim-basic really not run without the stuff in -runtime? (If the above
means vim becomes an empty package, moving the stuff from vim-runtime into it
might be feasible/worthwhile)

> If there's the need of more vim features in the standard installation I
> would rather prefer to tune vim-tiny compilation including more
> features. On this subject, please note that adding gpm support will
> trigger the additional libgpmg1 dependency.

libgpmg1 is already in standard, and is 50k of .deb.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Anthony Towns]

On Thu, Dec 22, 2005 at 11:11:59PM +, MJ Ray wrote:
> Stefano Zacchiroli <[EMAIL PROTECTED]>
> > [...] In the very same post Joey correctly added:
> >   It's now only marginally larger than nvi [...]
> 167% is a rather big margin, isn't it?

Depends what it's a percentage of; if it were a percentage of all of base,
sure; but it's not, it's a percentage of nvi.

> If one is honest and says that vim-tiny will replace nvi because
> the decision-makers prefer it, 

One doesn't need to be honest to say that, merely tautological: yes,
decisions happen when decision makers decide.

> Are there many vi users who will just use vim-tiny?
> Most "small vi" users don't seem to like vim, IME.

I prefer nvi because of the default vim configuration issues discussed
earlier; autoindenting while pasting in particular is annoying. With
that fixed, I'd be happy to have vim be the default vi on my system,
and would tend to do that, since some of my users strenuously prefer
having vim around.

Cheers,
aj


signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi?

[Eric Dorland]

* Joey Hess ([EMAIL PROTECTED]) wrote:
> As you can see below and in the BTS, vim's maintainer has managed to
> create a vim-tiny package that is vim without some of the extras such as
> syntax highlighting. It's now only marginally larger than nvi, which is
> the standard vi included in the base system (amazingly, it's smaller
> than nano, the other editor in the base system). Stefano suggested that
> vim-tiny could replace nvi and become part of base, and I think it's a
> good idea.
> 
> There are obviously users who will prefer nvi to vim (and others who
> prefer some other vi), but I get the impression there are rather more who
> prefer vim, it's probably the most commonly used vi in linux these days.
> 
> One argument I can think of for keeping nvi in base is that it is the
> closest to bug-compatible with the original vi. However, I don't think
> that will prevent hardcore vi users from easily using vim-tiny if
> it's in base.

Another good reason for doing this is that for basically every Linux
user I've encountered, vi == vim. When I tell non-Debian users that
Debian ships with something called nvi instead of vim by default, they
shake their heads and disbelief and next words out of their mouths
either make fun of Debian, or make fun of me (*snif*).

Now we don't necessarily have to pander to these people, but this
change is the sort of thing that will help the change perception of
Debian for people who think we're a bunch of crazies.

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: buildd administration -- TeX related FTBFS

[Osamu Aoki]

Hi, 

On Tue, Dec 20, 2005 at 01:48:12PM +0100, Frank Küster wrote:
> Osamu Aoki <[EMAIL PROTECTED]> wrote:
...
> > I think one to ease tension is to make tetex packages to coexist in
> > archive just like many gcc.
> 
> That would be nice - but it would cause even more work, I fear.  And it
> would be the cause of even more bugs, because you can't just simply use
> one symlink pointing to the right place, but need to maintain a complete
> tree of TeX input and configuration files, in a setup where users can
> mix up trees with one changed line in the central configfile...

I should have been clear.  I wish them to coexist only in "archive" but
they can conflict each other to make only one of them to be installed.
Maybe, dummy package to go with them  is also nice.

I know it is too much work to make them installable simultaneously.
Maintaining 2 version are still a lot of work, though.

As for auto-building some sections of archive in sid environment but
overriding some packages with ones from experiment or local archive, I
think pbuilder should be useful. (I will try it some time soonish.  It
should be quite simple.)

Osamu

Re: Thoughts on Debian quality, including automated testing

[Kevin Mark]

On Wed, Dec 21, 2005 at 03:07:10PM +0100, Adrian von Bidder wrote:
> On Wednesday 21 December 2005 12.23, Thomas Hood wrote:
> 
> > I don't think that it is ridiculous to require that every package have a
> > team behind it---i.e., at least two maintainers.  First, if someone can't
> > find ONE other person willing to be named as a co-maintainer of a given
> > package then I would seriously doubt that that package (or that person)
> > is an asset to Debian.
> 
> The problem is: do you honestly want to force people who don't want to have 
> comaintainers on their packages to leave Debian?

Hi vbi,
Packages, not being sentient, don't mind being comaintained, its people
who have objections to comaintaining packages. So its a social problem,
not a technical one. In most cases the comaintainers will not be equal
in technical skill, social skills, etc. Working together SHOULD benefit
both people and Debian. Does Debian need less/anti social folks? Is it
beneficial to Debian/the packages/the users? The lesser skilled
person(LSP) could gain skill. The more skilled person(MSP) should be
able to give the LSP some directed task (like I read about in the NM
proposal from 'HE'), thus providing a type of apprenticeship. The other
person does not have to know everything about the package, but could
offload some of the effort of the MSP. This allow the LSP to gain
technical as well as Debian skills(debian workflow and social norms). So
the LSP could be in the NM queue or be a less experience DD or someone
less skill in a certain language/specialized Debian task, this would
provide some way to bring folks in who want to expand their skills/role
but dont want to takeover a package like in certain one-point-of-failure
tasks.

> 
> Or do you want people who really don't want to have comaintainers for their 
> packages to put somebody in just so they are following the rules, while 
> they regard anything done by this comaintainer on his own like they would 
> regard an intrusive NMU?

Well if someone would treat another maintainer in that way or would
think an NMU intrusive, is that person being as social as Debian
expects? Is being able to working with someone (even if they may be less 
skilled) something uncommon to Debian? 

> 
> Don't misunderstand me: team maintenance is great, and I think it makes 
> sense even for small and trivial packages.  But trying to force anybody to 
> do anything is no productive in Debian (and we'd have to modify the 
> constitution for this, anyway :-)

I guess there could be expections like there are for other things in
Debian (like p-a-s) but like openness, the more [comaintained] , the better.

pax vobiscum,
Kev
ps. happy $HOLIDAYS and $YEAR++
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Anand Kumria]

On Wed, Dec 21, 2005 at 03:21:07PM +0100, Goswin von Brederlow wrote:
> Anand Kumria <[EMAIL PROTECTED]> writes:
> 
> > On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote:
> >> Anand Kumria <[EMAIL PROTECTED]> writes:
> >> 
> >> > I'd like to congratulate our ftp-master team on their ability to timely
> >> > process packages progressing through the NEW queue.
> >> >
> >> >  [1]
> >> >
> >> > I think you are an excellent example of people who are too busy for 
> >> > Debian.
> >> >
> >> > I must say that I am particularly impressed that you've managed to
> >> > frustrate our users for over 1 year with the package 'xvidcap'.
> >> 
> >> Guessing by the name alone I would say this is a patent issue like
> >> mplayer and therefore a problem package that is not likely to get
> >> resolved anytime soon.
> >> 
> >> But that is just a guess.
> >
> > And it is an incorrect guess. xvidcap itself uses libraries already in
> > Debian. But thanks for playing "guess the mind of the ftp-masters".
> >
> > Was it fun?
> 
> Yes and I guessed right it seems.

I think you've been smoking too much.

> The ffmpeg library in debian is a problem case and probably should not
> be in there. That issue hasn't been decided yet and till then anything
> using it stays stuck.

Really? Excellent then. I would expect that gstreamer0.10-ffmpeg, 
recently uploaded, to be stuck in NEW for a year (at least) then.

If it isn't then your theory is wrong.

What you are saying that is that a sceanario such as:
- a company (e.g. Unisys) asserting a patent on 
- a file format (e.g. GIF) which has 
- a library (e.g. libgif) which is used by
- an application (e.g. gimp)

should result in further uploads of the gimp being held indefinately in
the NEW queue until such time as any perceived library patent problem is
resolved.

I'd argue that either:
- the library, and all dependant program be removed from the
  archive
- that applications merely linked to the library be allowed in
  but that the library maintainer be asked to remove the
  offending code

In the spirit of Anthony's blog entry [1], I've CC'd him for an informal
opinion about that.

> >> For non problem cases the NEW queue was never as fast as now so
> >> congratulation of improving the NEW queue so much already. Giving your
> >> past month performance I'm sure the few remaining issues can be
> >> resolved in time as well. Ignoring anything 2 weeks or newer I count
> >> only 7 packages. This is great.
> >
> > Maybe you are a fan of being left in limbo, or like the perverbial
> > Schrödinger's cat, but even a bad process can benefit from assurances.
> >
> > A simple assurance that your package will be rejected from the NEW queue
> > if no ftp-master approves it within 2 weeks would actually be a benefit.
> 
> And would result in mplayer being uploaded again and again everytime
> someone forgets it was there before.
> 
> Beter to have it stuck but documented why.

Surely it be better to document that in the REJECT FAQ that a package:
- with a particular name 
- or linked to a particular library
- isn't likely to be looked at prior to autoREJECT occuring

Then it wouldn't even be stuck.

Anand

[1]: http://azure.humbug.org.au/~aj/blog/2005/12/11

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Bug#344496: ITP: squirrel -- the squirrel programming language

[Alexander Schmehl]

Package: wnpp
Severity: wishlist
Owner: Alexander Schmehl <[EMAIL PROTECTED]>


* Package name: squirrel-lang
  Version : 2.0.5
  Upstream Author : Alberto Demichelis <[EMAIL PROTECTED]>
* URL : http://www.squirrel-lang.org/
* License : zlib/libpng license
  Description : scripting language with small ressource requirements
  
Squirrel is a high level imperative/OO programming language, designed to
be a powerful scripting tool that fits in the size, memory bandwidth,
and real-time requirements of applications like games.


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.15-rc6-vinyamar
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)



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

Heimdal and openssh

[Juha Jäykkä]

Hi!

I am in the process of implementing Heimdal and OpenAFS into our
laboratory network (already using LDAP for NSS). The network contains a
mixed environment of sarge and sid (even one etch, but I plan to upgrade
that to sid soon). Now, the version of Heimdal will be 0.7.1, which has
been in experimental for a while and just made its way to unstable. This
seems to produce a couple of problems (points, rather).

1) Ssh-krb5 (sarge) and openssh 4.2 (sid) will not talk GSSAPI to each
other. I gather from openssh mailing lists that no versions of openssh <4
and >4 will ever talk GSSAPI together due to some security patches made.
Thus this is not a Debian -related problem, but it leads to one.

2) I can either build openssh 3.8 on the sids or 4.2 on the sarges. It's
wiser to build 4.2 on sarges (security and upgrade path), especially since
backports.org has already done that.

3) LDAP needs gssapi libraries compiled against Heimdal, not MIT kerberos
(I assume this has something to do with the service being used is Heimdal,
not MIT.) So, install Heimdal GSSAPI libraries on sids, compile and
install them on sarges.

4) Now that I have Heimdal GSSAPI libraries, openssh GSSAPI will not work.
Recompiling openssh against heimdal-dev instead of its declared build-dep
libkrb5-dev solves the problem. Now LDAP SASL works, Heimdal works and
GSSAPI-ssh works and AFS tokens are passed automatically.

5) As a side note: I learned afterwards that AFS token passing with ssh
*needs* openssh compiled againsta heimdal-dev. Thus compiling everything
against Heimdal is somewhat compulsory here to make AFS work without extra
afslog/aklog commands.

Now my real question: what's the smartest way to keep all these
self-compiled packages up to date? And is it worth filing a bug report
against the various packages involved, asking for versions compiled
against both heimdal-dev and libkrb5-dev? Since there are two reasons
pro-Heimdal and con-MIT [1], should Debian start using Heimdal as its
primary KerberosV implementation? I know Ubuntu people have been
discussing the same question but I don't know what they decided if indeed
there has yet been any decision. One more question: did I make a mistake
somewhere along the road? ;) I would like nothing better than a solution
which does *not* involve packages being compiled by hand. Heimdal 0.7.1
cannot be helped, but how about the others? (Luckily Heimdal is quite
stable and does not need updating very often.)

Cheers,
Juha

[1] MIT kerberos is not thread safe (unless my info is outdated) and only
Heimdal is capable of seamlessly integrating to AFS. The first can be
worked around, but the second is probably very important to anyone running
AFS and kerberos.

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


pgpjGfeXailqb.pgp
Description: PGP signature

Re: Heimdal and openssh

[Russ Allbery]

Juha Jäykkä <[EMAIL PROTECTED]> writes:

> 1) Ssh-krb5 (sarge) and openssh 4.2 (sid) will not talk GSSAPI to each
> other. I gather from openssh mailing lists that no versions of openssh
> <4 and >4 will ever talk GSSAPI together due to some security patches
> made.  Thus this is not a Debian -related problem, but it leads to one.

Er, huh?

wanderer:~> dpkg -l ssh-krb5
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  ssh-krb5   3.8.1p1-10 Secure rlogin/rsh/rcp replacement (OpenSSH w
wanderer:~> ssh windlord
Last login: Thu Dec 22 21:07:28 2005 from 113.110-113-64.ftth.swbr.surewest.net
 23:10:07 up 12 days,  7:22, 28 users,  load average: 0.00, 0.01, 0.00

windlord:~> dpkg -l openssh-server
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  openssh-server 4.2p1-5Secure shell server, an rshd replacement

Works fine for me.

> 3) LDAP needs gssapi libraries compiled against Heimdal, not MIT
> kerberos (I assume this has something to do with the service being used
> is Heimdal, not MIT.)

No, it has to do with thread safety and is partly obsolete now that MIT
Kerberos 1.4 is in sid.  MIT 1.4 should be fine for OpenLDAP for most
purposes (although as I recall Quanah says that it has a lot of trouble
compared to Heimdal under load).

Anyway, LDAP just uses SASL; it doesn't link with Kerberos directly.  So
you should be fine installing whatever SASL modules you prefer, whether
the Heimdal ones or the MIT ones.

> 4) Now that I have Heimdal GSSAPI libraries, openssh GSSAPI will not
> work.

Um, this doesn't make any sense to me.  Two different GSSAPI libraries,
two different library names or SONAMEs, should co-exist on the same system
just fine.  The *development* packages don't co-exist, but the libraries
do.  I have them both installed at the same time on my system right now.

> 5) As a side note: I learned afterwards that AFS token passing with ssh
> *needs* openssh compiled againsta heimdal-dev.

Don't ever do AFS token passing.  Pass your Kerberos tickets with GSSAPI
and then use a PAM module to get AFS tokens from your forwarded tickets.
AFS token passing is obsolete, insecure, and requires that you use
protocol version one.

> Now my real question: what's the smartest way to keep all these
> self-compiled packages up to date?

I'm pretty sure you shouldn't need to do any of this.  :)

> [1] MIT kerberos is not thread safe (unless my info is outdated)

MIT Kerberos is thread-safe as of 1.4.

> and only Heimdal is capable of seamlessly integrating to AFS.

MIT Kerberos works fine with AFS, but I admit that you have to go to
marginally more effort.  Not enough to deter me from using MIT, but if you
prefer Heimdal, I won't stand in your way.  :)

> The first can be worked around, but the second is probably very
> important to anyone running AFS and kerberos.

Not really.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Thoughts on Debian quality, including automated testing

[Adrian von Bidder]

[lots of snippage]

I fear I don't see your point - and I feel you don't see mine.

Here's why I feel *forced* comaintainership is not a solution:

Maintainers divide in
 (i) those who already work in teams on their packages
 (ii) those who don't.

Ignore (i).

(ii) divides in
 (a) those who do a good job
 (b) those ho don't.
Ignore here what metrics we use to decide that. 

This division is not useful because (a) maintainers may become (b) 
maintainers over time.  So there's

 (a) those who know when to ask for help and
 (b) those who don't.

Now, my claim is that only this (b) is what the forced comaintainership will 
try to solve.  And badly, because I assume that those latter maintainers 
are also those who would, probably, object anyway to forced 
co-maintainership, and so would either ignore the order, be forced out of 
Debian in consequence, or pay lipservice by putting Random Joe Developer 
into Uploaders (I'm not claiming they'd do that without consent of Random 
Joe, but I claim that he'd never do anything on the package, and 
consequently would not make a difference even if the package is relatively 
badly maintained.)

The other side, and we've seen some people say this in this thread already, 
is that even if a maintainer asks for help, he may not get any - IIRC nis 
was one such package, and I claim that its still used by quite a few, so in 
theory somebody should be found.

Ok, I hope this is stated clearly enough.

cheers
-- vbi

-- 
Stilblüten aus Schreiben von Versicherungsnehmern:
Meine Antwort vom 17.7 hat sich offenbar mit Ihrer Erinnerung
gekreuzt.


pgphVdGrQppx3.pgp
Description: PGP signature

Work-needing packages report for Dec 23, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 173 (new: 1)
Total number of packages offered up for adoption: 101 (new: 12)
Total number of packages requested help for: 21 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libmldbm-sync-perl (#344324), orphaned yesterday
 Description: Perl module for safe concurrent access to MLDBM
   databases
 Reverse Depends: libapache-asp-perl
 Installations reported by Popcon: 93

172 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   fbgrab (#344450), offered today
 Description: Framebuffer grabber
 Installations reported by Popcon: 71

   libconfig-general-perl (#344462), offered today
 Description: generic configuration module
 Reverse Depends: ddtc slbackup arch-buildpackage
   w3c-markup-validator cwcdr acheck
 Installations reported by Popcon: 447

   libemail-find-perl (#344452), offered today
 Description: Perl module to find RFC 822 email addresses in
   arbitrary text
 Reverse Depends: libhtml-fromtext-perl
 Installations reported by Popcon: 351

   libhtml-fromtext-perl (#344453), offered today
 Description: Mark up text as HTML
 Reverse Depends: webmin-ldap-user-simple liblog-tracemessages-perl
   libapache-miniwiki-perl
 Installations reported by Popcon: 353

   libhtml-linkextractor-perl (#344454), offered today
 Description: Perl module used to extract links from HTML documents
 Installations reported by Popcon: 266

   libhttp-cache-transparent-perl (#344455), offered today
 Description: Perl module used to transparently cache HTTP requests
 Reverse Depends: xmltv-util
 Installations reported by Popcon: 436

   libsort-versions-perl (#344456), offered today
 Description: Perl module for sorting of revision (and similar)
   numbers
 Reverse Depends: libmodule-packaged-perl libparse-cpan-packages-perl
   libcss-tiny-perl
 Installations reported by Popcon: 96

   libterm-progressbar-perl (#344457), offered today
 Description: Perl module to print a progress bar
 Installations reported by Popcon: 259

   libtk-tablematrix-perl (#344458), offered today
 Description: Table/matrix widget extension to Perl/Tk
 Reverse Depends: xmltv-gui
 Installations reported by Popcon: 329

   lincity (#38), offered today
 Description: build & maintain a city/country
 Reverse Depends: junior-games-sim
 Installations reported by Popcon: 544

   moomps (#343823), offered 5 days ago
 Description: system monitoring daemon which works using
   configuration
 Installations reported by Popcon: 2

   xabacus (#39), offered today
 Description: simulation of the ancient calculator
 Installations reported by Popcon: 205

89 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 182 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot
 Installations reported by Popcon: 55

   athcool (#278442), requested 422 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 207

   debtags (#321654), requested 138 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit
 Installations reported by Popcon: 389

   dselect (#282283), requested 397 days ago
 Description: a user tool to manage Debian packages

   fetchmail (#331642), requested 79 days ago
 Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail
 Installations reported by Popcon: 2504

   grub (#248397), requested 591 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
   grub-splashimages
 Installations reported by Popcon: 6724

   gtkpod (#319711), requested 151 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 217

   gutenbrowser (#331203), requested 81 days ago
 Description: Project Gutenberg Etext reader
 Installations reported by Popcon: 53

   lib (#329966), requested 89 days ago
 Description: Perl interfaces to the Gtk and Gnome libraries

Re: New experimental sysvinit

[Adrian von Bidder]

On Friday 23 December 2005 01.40, Linas Zvirblis wrote:
> Thomas Hood wrote:
> >   No-login mode at boot until boot complete:
> > DELAYLOGIN=yes No-login mode never:  rm -f /var/lib/initscripts/nologin
> > ; DELAYLOGIN=no No-login mode always: touch
> > /var/lib/initscripts/nologin ; DELAYLOGIN=no
> >
> > Anyone see any problems with this scheme?  Any better ideas?
>
> This might be a silly question, but what would happen if DELAYLOGIN=yes
> and /var/lib/initscripts/nologin does not exist?

I surmise that it's created somewhere in runmefirst.  After all, the 
usual state of a running system is that the file doesn't exist...

-- vbi


-- 
Witz ist Intellekt auf dem Bummel.
-- Oscar Wilde


pgpevbHMD3rmw.pgp
Description: PGP signature