date:20051212

Thanks ...We don't want them to open multiple connections even to MULTIPLE servers...

Re: Packages-arch-specific (was: Sparc build failure analysis)

2005-12-12 Thread Thijs Kinkhorst

On Sun, 2005-12-11 at 08:52 -0800, Russ Allbery wrote:
> So I followed the instructions at the top of that file and requested a
> P-a-s entry, after asking people here what to do.  No response.  Hm.  I
> wasn't sure what to make of that -- maybe this request is too trivial to
> bother with, it's fine for the builds to fail, and I should just ignore
> it?  Or maybe my e-mail wasn't received?  Or maybe I misunderstood
> something and this was the wrong channel or the wrong thing to do?
[...]
> other arches aren't).  Is this because of my mail?  Because the buildd
> administrator noticed the error message?

In my opinion what's needed here is a pseudo package in the BTS against
which bugs can be filed for changes to P-a-s, and the maintainer for
that package would be the collection of current P-a-s maintainers.

Advantages:
- ensure for developers that their mail is not lost;
- ensure for P-a-s maintainers that they don't forget about less
important items if they don't have time for it right away;
- allow the P-a-s maintainers to use (user)tags and severities to
classify the requests (wontfix and moreinfo spring to mind);
- allow for porters to add their (dis)approval of a request to the bug;
- allow for everyone, developers, porters and other interested parties
alike, to see what the status is of a particular request.

These reasons are very comparable with why we encourage bugs to be filed
against packages in the BTS instead of sending them to the maintainer
email address.


bye,
Thijs


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

i'm still seeing archived bugs

2005-12-12 Thread Domenico Andreoli

hi,

  why i'm still seeing lots of archived bugs in my packages? hmm..
also the http://www.debian.org/Bugs/ form does not work correctly.

please, what am i doing wrong?

i'm accessing the logs with the following url:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=curl

thank you
domenico

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

Re: apt PARALLELISM

2005-12-12 Thread Martijn van Oosterhout

2005/12/12, Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
We don't want them to open multiple connections even to MULTIPLE servers...
That's odd though, because apt *does* open connections to multiple
servers all the time. To fetch packages lists, or if a package is only
available on one of the servers further down.

Secondly, the amount of data to be downloaded is
independant of the time it takes, thus, in aggregate, whether apt
parallelizes or not won't make any difference to the total bandwidth
used, although it may shift more load to the ftp2 servers since they
never get used in normal usage.

Finally, how much of these slowdowns reported by people are caused by
the bandwidth delay product. In that case, two servers will definitly
be able to use more than a single server by itself... I didn't think it
common practice for large mirror to configure multi-megabyte windows...

Have a nice day,

Re: i'm still seeing archived bugs

2005-12-12 Thread Andreas Tille


On Mon, 12 Dec 2005, Domenico Andreoli wrote:


 why i'm still seeing lots of archived bugs in my packages? hmm..
also the http://www.debian.org/Bugs/ form does not work correctly.


I guess it is because bug #339141 is just open.  It seems that nobody
really cares since 27 days.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: buildd administration

Anthony Towns  writes:

> On Sat, Dec 10, 2005 at 11:52:22AM +0100, Josselin Mouette wrote:
>> It got proposed because no one was able to give correct explanations
>> about why it hadn't been included. 
>
> Heh. I'm almost morbidly curious enough to ask what you think the
> "correct" explanation of why it hasn't been included is, except that,
> well, I'm not.

The only reason amd64 didn't get added and still hasn't been added is
that some mirros don't have enough space/bandwith to cope with another
arch.

That is for _sid_. Inclusion of sarge (as the misphrased GR wanted at
some point) was always blocked by not being in sid.

> For those playing along at home, Martin replied to Josselin's query at
> the time with his DPL hat on:
>
> http://lists.debian.org/debian-devel/2004/07/msg00253.html

|  - Some technical AMD64 questions: ftpmaster had some specific
|questions about the AMD64 port they want to see answered.  Also,
|an LSB person recently expressed some technical concerns (see [1]).

Ftp-master (meaning James here) never ever did express any questions
or any reply. Only second hand we got the information that suddenly
there were no more questions.

As for LSB issue that was just misunderstanding of the port status and
cleared up later in the thread. And the port inclusion policy (first
point in the mail) was always said that it will allow amd64 in anyway.

> Josselin's reaction to that explanation, which remains completely
> correct as far as it goes (though perhaps focussing too much on the
> "write a policy") is pretty much why I don't think explanations are a
> particularly useful part of addressing these controversies.

Without the explanation the contious weekly questions why amd64 wasn't
in debian would have continued. With it there was a small discussion
and then a lot less noise.

The explanation also ment we could give up asking for inclusion as
none of the (remaining) points were anything that could be changed.

>> I still believe it was a mistake to release without amd64. 
>
> We didn't release without amd64; the sarge release for amd64 is on
> amd64.debian.net.

You (as in Debian) released without amd64. Now don't start claiming
the ports own release is suddenly official when everybody maintained
the opposite all this time.

MfG
Goswin

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

Re: buildd administration

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 07:24:00PM -0800, Thomas Bushnell BSG wrote:
> That sort of information is helpful to tell you when there is a problem,
> but that's only the first step. ATM, the corresponding thing would
> be to (gosh!) setup a webpage tracking whatever issue you don't think
> is receiving enough attention, so people can see if it is actually a
> problem. The way to then go about solving it is *politely* working *with*
> the people who're currently involved.

buildd.net is tracking the buildds. So there is your webpage.

And we tried working with the people and they changed the rules so we
couldn't continue the help we did (compile packages for very backloged
archs).

You can only help if help gets accepted.

MfG
Goswin

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

Re: buildd administration

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> C'mon, this is a free software project.  The obvious first step for
>>> providing better infrastructure would be to make that infrastructure
>>> publically available for anyone to download, play with, hack on, or
>>> otherwise evaluate, whether the existing infrastructure component is
>>> similarly available or not.  I'd think this would just be common sense.
>
>> You can test and play around with buildd.net all you want and easily see
>> "its superiority". You can also contact Ingo and ask him for the
>> scripts, as I have done, and you may recieve them. Something that I
>> found impossible for buildd.d.o.
>
>> Ingo is offering a service and paying for it. That he isn't throwing the
>> source at anyone casualy stumbling accross his site should hinder anyone
>> intrested.
>
> I wholeheartedly approve of the decision to decline to use the software of
> people with this attitude towards free software as part of the core Debian
> infrastructure.  It's one thing to have the source diverge due to lack of
> time, but the above rings TONS of MAJOR warning bells for me.  It sounds
> very much like the sort of conversation that I get into with vendors who
> are trying to say they do "open source" without actually doing anything of
> the sort.
>
> Much of what we do here is *exactly* about throwing the source at anyone
> casually stumbling across our site.

Ok, lets take an example: Where is the source thrown at you for
www.debian.org?

It isn't. You have to ask around, get to know or dig deep along the
links to find cvs.debian.org.


Ingo and I wanted to improve the (still non public) buildd.d.o scripts
and were rejected with "All the info is already there". That is why
buildd.net now runs the scripts. The warning bells ring with
buildd.d.o, not buildd.net.

And yes, the buildd.net scripts are now closed sourced if you
will. But the offer to open them up, to integrate them into and
improve buildd.d.o was made long before that and still stands.

MfG
Goswin


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

Re: buildd administration

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 09:40:11PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns  writes:
>> > Requeue requests are part of handling logs... You get a failed log, you
>> > analyse it to say "oh, that's a transient error due to other things"
>> > then you requeue it... If that analysis comes from reading a mail,
>> > great.
>> So why was the request ignored for a month?  Why did my email result
>> in no action, twice, not even a response?
>
> I've told you what I'd need to answer that question already.
>
>> Perhaps you don't know the answer to these questions.  But then how
>> can you so surely assert that there is no problem?
>
> Easy: the best tools we've got to judge whether buildds are keeping up
> are the buildd graphs which indicate that with the exception of m68k
> and arm (hrm, and possibly hppa), all our ports are doing extremely well.
>
> Although I guess that's different from saying there's "no problem" if
> you're being pedantically literal. I have no interest in that sort of
> discussion though. *shrug*

So i386 never has a problem no matter how screwed up the buildd is?
The stats will always show a very high % for it no matter what.

The only thing the graph shows is the general case, the overall
performance of the arch. Not if a package has fallen through the
cracks and is ignored or forgotten.

MfG
Goswin


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

Re: buildd administration

Thiemo Seufer <[EMAIL PROTECTED]> writes:

> Jeroen van Wolffelaar wrote:
> [snip]
>> A similar issue I noted in the past is the big number of build failures
>> that don't get tagged 'Failed'. I tried working on classifying them, but
>> got bored so increadibly fast that I gave up, and decided for myself
>> this should be something the porters should rather look into. And thus I
>> mailed in June about that[2]. I don't believe anyone picked up that, but
>> I might be wrong, of course, my mail was hidden in a big thread about
>> various stuff, just like this very mail is...
>
> FWIW, I did for mips/mipsel and found your page to be very helpful.
>
>
> Thiemo

So why doesn't he get w-b access so he can actualy tag the bugs
failed?

MfG
Goswin


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

Re: buildd administration

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Fri, Dec 09, 2005 at 06:50:26PM +0100, Goswin von Brederlow wrote:
>> And when you try you get screamed at and flamed as witnessed in the
>> huge buildd flame fest the last time. Iirc some 3000 packages were
>> build outside the official buildd network across the involved archs at
>> that time.
>
> And for the Nth time, this had to change not because of the actual
> people involved but because those people were not in our web of trust.

Like Martin Loschwitz <[EMAIL PROTECTED]> or Falk Hueffner
<[EMAIL PROTECTED]>?

> Hamish

MfG
Goswin


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

Re: StrongARM tactics

2005-12-12 Thread Thomas Viehmann

Wouter Verhelst wrote:
> That's still a bit of time wasted, but it's not really bad. The really
> problematic version is when a package is downloaded, build-deps are
> installed, and /then/ sbuild figures out that some version isn't recent
> enough.
According to the intersection of the debcheck build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, see e.g. gnucash.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: StrongARM tactics

2005-12-12 Thread Thomas Viehmann

Wouter Verhelst wrote:
> That's still a bit of time wasted, but it's not really bad. The really
> problematic version is when a package is downloaded, build-deps are
> installed, and /then/ sbuild figures out that some version isn't recent
> enough.
According to the intersection of the debcheck build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, as gnucash shows.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: State of gcc 2.95 use in Debian unstable

Bill Allombert <[EMAIL PROTECTED]> writes:

> On Fri, Dec 09, 2005 at 04:22:37PM +0100, Goswin von Brederlow wrote:
>> Heiko M?ller <[EMAIL PROTECTED]> writes:
>> 
>> > We found that gcc-2.95 -Os produces object code of acceptable quality 
>> > within reasonable compilation times. gcc >=3 is less efficient w.r.t.
>> > compilation time and memory consumption and in many cases even fails 
>> > to compile our codes due to the very long expressions. The C/C++ codes
>> > generated from the computer algebra software are perhaps unusual but 
>> > not broken.
>> 
>> Can you send in a few (hopefully short) examples that fail as
>> bugreports?
>
> I cannot speak for Heiko, but my examples are far from short. Indeed
> they include a statement that is several megabytes long.

Short as in

double foo(double in1, double in2, ...) {
return /* very very long formula */
}

or something. Not 20MB of unintresting prefix to the actual code that
fails.

> gcc exhaust all the memory available and fail with 
>  Internal compiler error:
>  virtual memory exhausted
> An gcc version that use less memory will be able to complete the
> compilation.

Or a system with more memory.

It would be intresting to see if it actualy does compile or if it get
stuck in a loop allocating memory all the time or something. Bug like
that do exist.

MfG
Goswin


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

Re: apt PARALLELISM

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Sun, Dec 11, 2005 at 02:45:50AM +0100, Marco d'Itri wrote:
>> On Dec 11, Charles Fry <[EMAIL PROTECTED]> wrote:
>> 
>> > But if multiple URLs could satisfactorily serve requests for a single
>> > repository, only one of them is currently used.
>> Which is fine, because we do not want people to open multiple
>> connections to the same server.
>
> True, but that's not what's being asked here. If multiple URLs could
> serve requests for a single repository---i.e., if you've got both 
> deb http://ftp1.CC.debian.org/debian unstable main
> and
> deb http://ftp2.CC.debian.org/debian unstable main
> in your sources.list, then apt will download everything from
> ftp1.CC.debian.org (bar those files it gets an error on at that server;
> in that case, it will download them from the second server).
>
> Which is, indeed, silly.

Unless you have

file://mnt/mirror/debian unstable main
http://ftp.de.debian.org/debian unstable main
http://ftp.debian.org/debian unstable main

where you certainly want to get all files locally and only fall back
to the web on errors and there also first use the german mirror and
only fall back to ftp.d.o on error.


If parallelism like this gets added then there has to be a way to
enable/disbale it specifically. It is not generaly a good thing.

MfG
Goswin


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

Re: apt PARALLELISM

Can have option in /etc/apt/apt.conf or apt-get (install || upgrade) with -? some char here for parallelism.And by default can be disabled ...

Re: apt PARALLELISM

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> 2005/12/12, Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
>
>   We don't want them to open multiple connections even to
>  MULTIPLE servers...
>
>
> That's odd though, because apt *does* open connections to multiple servers all
> the time. To fetch packages lists, or if a package is only available on one of
> the servers further down.
>
>
> Secondly, the amount of data to be downloaded is independant of the time it
> takes, thus, in aggregate, whether apt parallelizes or not won't make any
> difference to the total bandwidth used, although it may shift more load to the
> ftp2 servers since they never get used in normal usage.
> Finally, how much of these slowdowns reported by people are caused by the
> bandwidth delay product. In that case, two servers will definitly be able to
> use more than a single server by itself... I didn't think it common practice
> for large mirror to configure multi-megabyte windows...
> Have a nice day,

Actualy one thing apt could do:

[EMAIL PROTECTED]:~% host security.debian.org
security.debian.org A   82.94.249.158
security.debian.org A   128.101.80.133
security.debian.org A   194.109.137.218

Why not open 3 connections one to each host?

Or at least fall back to the other IPs if the first one gives an
error?

MfG
Goswin


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

Re: apt PARALLELISM

On Mon, 12 Dec 2005, Martijn van Oosterhout wrote:
> 2005/12/12, Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> > We don't want them to open multiple connections even to MULTIPLE
> > servers...
> 
> That's odd though, because apt *does* open connections to multiple servers
> all the time. To fetch packages lists, or if a package is only available on
> one of the servers further down.

Yah.  It is supposed to be the lesser of two evils, I think.  With the new
differential packaging lists, it will actually be a proper balance between
mirror load and user experience (see apt in experimental).

> Secondly, the amount of data to be downloaded is independant of the time it
> takes, thus, in aggregate, whether apt parallelizes or not won't make any
> difference to the total bandwidth used, although it may shift more load to
> the ftp2 servers since they never get used in normal usage.

It will make difference for people trying to download at the same time. I
have made this point a number of times again.

Let me get it clear:

1. We care about a large lot of people a lot more than we care for an
   individual's downloading speed

2. Thus we try to keep the mirror load down, and downloading hundreds of
   megabytes using multiple connections to multiple sources of the same file
   is heavily fronwed upon.

3. If one manages to prove that the best way to archieve (2) is through n
   parallel connections to the same mirror, or to n parallel connections to
   different mirrors, be my guest.

> Finally, how much of these slowdowns reported by people are caused by the
> bandwidth delay product. In that case, two servers will definitly be able to

I won't claim this is what happens in Internet-paradise countries, but here
there are two things that affect download speed the most after you get a
last-mile link that is not too slow (say, 384kbit/s or more):

  TCP/IP (roundtrip, packet loss, windows)
  ISP "backbone" link congestion

Whichever one is the worst bottleneck changes along the day.  When the
cable/ADSL/radios are unstable, packet loss can cause staggering slowdowns.
During the more busy hours, the backbone limitantion becomes apparent.
During the wee hours of the night on long holidays, TCP/IP is the one
limiting the speed of a single connection.

> use more than a single server by itself... I didn't think it common practice
> for large mirror to configure multi-megabyte windows...

TCP/IP windows?  Or user bw shaping?

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

Debian and the desktop (was: Re: Complaint about #debian operator)

2005-12-12 Thread Michael Banck

(Dropping Josh and moving to -devel, as this is discussion is going
elsewhere)

On Mon, Dec 12, 2005 at 01:59:05PM +0100, martin f krafft wrote:
> However, some users just want a computer that works (the "plain
> users"). They don't want to have to learn too much about Linux or
> Debian, they just want to get work done. 

I don't understand why for Etch, if a user chooses "Desktop" during
tasksel, they shouldn't get the just works[tm] experience.

This might take some effort, and perhaps some more tuning than just a
bunch of packages getting installed, but I think there is still time
left to make Etch rock on the desktop.  Hey, even Sarge seems pretty
much good enough for a lot of users already.

> Let them use Ubuntu.

Ubuntu's excellence shouldn't be an excuse to sit back and not make our
Desktop the best possible.

cheers,

Michael

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

Re: Packages-arch-specific (was: Sparc build failure analysis)

2005-12-12 Thread Steve Langasek

On Sun, Dec 11, 2005 at 08:52:04AM -0800, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:

> >> Again: what can I do with such a list?  See the list below.

> > Changes to the P-a-s list should be sent to the contacts listed at the top
> > of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific).

> So I followed the instructions at the top of that file and requested a
> P-a-s entry, after asking people here what to do.  No response.  Hm.  I
> wasn't sure what to make of that -- maybe this request is too trivial to
> bother with, it's fine for the builds to fail, and I should just ignore
> it?  Or maybe my e-mail wasn't received?  Or maybe I misunderstood
> something and this was the wrong channel or the wrong thing to do?

Right, well, as noted, it's generally a fairly low priority to get packages
added to P-a-s -- even though it's an eventual goal, the waste just really
isn't so much (in the usual case) to warrant a rush job.  So from that
standpoint, as long as there is quite such the backlog on P-a-s that there
is (from what I can see), it seems like something maintainers should also
give a pretty low priority to.

Anyway, you could always try throwing this in Adam's direction as well now
that he's listed as a co-maintainer of the file.

> I waited a while (my saved mail says two months) and asked my AM about it.
> He said that mailing them again was probably the right thing to do.  So I
> went ahead and did that, providing the specific entry that I think should
> be used.  No response (that was in August).  However, I notice in the
> build report that m68k is now marking openafs as "not for us" (but the
> other arches aren't).  Is this because of my mail?  Because the buildd
> administrator noticed the error message?

That would be noticing the error message...

> This is a really minor issue in the grand scheme of things.  It's not RC,
> it doesn't break anything, it's really mostly cosmetic plus a minor
> resource waste.  Now I'm feeling kind of guilty about bothering clearly
> busy people with a trivial request, and I probably really shouldn't send
> this message to debian-devel either, since certainly it's not any kind of
> serious problem that this hasn't been done.

Eh, well, don't get all guilted up over it. :)

> Maybe the right thing to do would be to work out a way for package
> maintainers to provide input to their own P-a-s entries in some sort of
> automated fashion?  It does seem like a package maintainer is generally
> going to know this sort of thing, and I hate to bother busy buildd
> maintainers with this kind of thing if I could do it myself.

Well, except between the time you wrote this message and the time I'm
drafting a reply to it, I've filed/upgraded at least three bugs about
packages wrongly limiting themselves to Architecture: i386; and I'm sure
there are plenty more out there in the packages I haven't looked at yet.
Skills do vary among maintainers, and especially among novice maintainers
there's certainly a tendency to mark packages as arch-specific when they
shouldn't be.  If P-a-s were being updated automatically based on whatever
the maintainer thinks should be there, it would've been substantially harder
to find these bugs.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

signature.asc
Description: Digital signature

Re: apt PARALLELISM

2005-12-12 Thread Marco d'Itri

On Dec 12, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Why not open 3 connections one to each host?
Why do?

> Or at least fall back to the other IPs if the first one gives an
> error?
I hope that this already happens...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: apt PARALLELISM

2005-12-12 Thread Marco d'Itri

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

> > use more than a single server by itself... I didn't think it common practice
> > for large mirror to configure multi-megabyte windows...
> TCP/IP windows?  Or user bw shaping?
He means the TCP window size, and it *is* common practice for large
mirrors to tune it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: apt PARALLELISM

On Mon, 12 Dec 2005, Marco d'Itri wrote:
> On Dec 12, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > > use more than a single server by itself... I didn't think it common 
> > > practice
> > > for large mirror to configure multi-megabyte windows...
> > TCP/IP windows?  Or user bw shaping?
> He means the TCP window size, and it *is* common practice for large
> mirrors to tune it.

Yeah, thought so.  We certainly tune TCP/IP (and just about everything else)
in all fileservers here for maximum throughput, be it over http, ftp, CIFS
or NFS.  If there is a reason to shape bandwidth, it is done through other
means at the outbond QoS shaper.  That's why I found it strange that he
asked about multi-megabyte windows.

-- 
  "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: apt PARALLELISM

2005-12-12 Thread Henning Makholm

Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]>

> 1. We care about a large lot of people a lot more than we care for an
>individual's downloading speed

> 2. Thus we try to keep the mirror load down, and downloading hundreds of
>megabytes using multiple connections to multiple sources of the same file
>is heavily fronwed upon.

Of course, trying to download the _same_ file from several different
servers simultaneously would be very wasteful. However it seems to be
not what the proposal in this thread is about.

As far as I read the proposal, it is about downloading _different_
files from different mirrors - if you have 25 packages to get for your
'apt-get update' operation, download 5 packages from each of 5
different servers, with one connection to each server active at a
time.

While I cannot see any very common situation where such parallellism
would be an advantage, it is not clear that it would increase the load
of any or all servers.

At least, I cannot see that there would be any ill effects of a
hypothetical pseudo-parallel implementation that downloads 5 packages
from each of the 5 servers, but sequentially such that only a single
connection to a single server is active. And the difference from
_that_ to an actual parallel implementation is just to shift the
connections each server experiences a bit in time - the number of KB
served by each server stays constant.

Is your point that a server prefers to push bytes through the
connection at a constant rate, and starts wasting resources if the
available bandwidth fluctuates because the last-mile ADSL has to be
shared with a shifting number of parallel downloads from other
servers? But when the bottleneck is closest to the client, enabling
parallel downloads would not make much sense anyway.

(Of course, Goswin has a valid point that some people have their
sources.list deliberately written with a remote, undesirable, server
at the end as a _fallback_ option. Therefore parallelism should at
best be an _option_, not something that apt starts doing unbidden).

> I won't claim this is what happens in Internet-paradise countries, but here
> there are two things that affect download speed the most after you get a
> last-mile link that is not too slow (say, 384kbit/s or more):

I have 768 kb/s at home, and my apt updates through that pipe operate
close to its peak capacity. But they are at least one order of
magnitude slower than from my desk at work (which is just two or three
100+ Mb/s hops away from the national research backbone). Same mirror
in both cases.

>From that experience, a last-mile link in the 1 Mb/s range would still
seem to be the limiting factor - and therefore people at the end of
such links would have little use for parallelism in the first place.

-- 
Henning Makholm  "What has it got in its pocketses?"


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

Removing gtksee package

2005-12-12 Thread Nico Golde

Hi,
I intend to request the removal of the gtksee package from 
the archive. So let me explain why.

I adopted the package in July 2004 and had a pretty active 
assosiation with the upstream author.
During the time upstream authors absence became more and 
more frequent and after some time he mailed me and told me 
that because of private problems he is probably not able to 
do be upstream maintainer any longer. After this I haven't 
heard anything for a while now.

The package is in a fairly good state but has some annoying 
bugs [1]. So I played a bit with gqview which seems be a 
good replacement. It has all features gtksee has and a bit 
more.
Nonetheless a few people are still using it. So I requested 
for adoption which I think would be still possible with a 
maintainer who can also do a bit of upstream maintaing.

So what do you think should I request a removal or wait for 
an adopter?
Regards Nico

[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gtksee
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!


pgplO1NOe8wV6.pgp
Description: PGP signature

Re: apt PARALLELISM

2005-12-12 Thread Wouter Verhelst

On Mon, Dec 12, 2005 at 12:52:09PM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > True, but that's not what's being asked here. If multiple URLs could
> > serve requests for a single repository---i.e., if you've got both 
> > deb http://ftp1.CC.debian.org/debian unstable main
> > and
> > deb http://ftp2.CC.debian.org/debian unstable main
> > in your sources.list, then apt will download everything from
> > ftp1.CC.debian.org (bar those files it gets an error on at that server;
> > in that case, it will download them from the second server).
> >
> > Which is, indeed, silly.
> 
> Unless you have
> 
> file://mnt/mirror/debian unstable main
> http://ftp.de.debian.org/debian unstable main
> http://ftp.debian.org/debian unstable main
> 
> where you certainly want to get all files locally and only fall back
> to the web on errors and there also first use the german mirror and
> only fall back to ftp.d.o on error.
> 
> If parallelism like this gets added then there has to be a way to
> enable/disbale it specifically. It is not generaly a good thing.

I'd rather think you'd only want to parallellize per protocol. I.e.,
only get stuff from http:// URIs if you can't get them from file://
URIs, etc.

On your point with one mirror being farther away than other mirrors, I
don't think that's such a problem; this could be handled by a smart
enough algorithm to distribute packages to the fetchers. For example,
first sort them so that large packages are at the end; then start
downloading one package from each mirror, measuring the time it takes to
perform that download; and when you have enough data to be sure, give
the larger packages to the faster mirrors, and the smaller packages to
the slower ones.

Such an algorithm should be more than enough for the common setup. There
will indeed be cases where that isn't going to be enough (i.e., you've
got two mirrors that are approximately as fast, but one is on the other
end of a line where you pay per downloaded byte while the other isn't),
so a way to disable parallellism will still be welcome; but I don't
think it needs to remain disabled by default.

That being said, I don't have either the time or teh skillz to implement
all this, so I'll shut up now.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/

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

Bug#343082: ITP: netgen -- automatic 3d tetrahedral mesh generator

2005-12-12 Thread Denis Barbier

Package: wnpp
Severity: wishlist
Owner: Denis Barbier <[EMAIL PROTECTED]>


* Package name: netgen
  Version : 4.4
  Upstream Author : Joachim Schoeberl
* URL : http://www.hpfem.jku.at/netgen/ngs44.tar.gz
* License : LGPL
  Description : automatic 3d tetrahedral mesh generator
   Netgen is an automatic mesh generation tool for two and three
   dimensions.  Netgen generates triangular or quadrilateral meshes in 2D,
   and tetrahedral meshes in 3D.
   .
   The input for 2D is described by spline curves, and the input for 3D
   problems is either defined by constructive solid geometries, or by the
   standard STL file format.  Netgen contains modules for mesh optimization
   and hierarchical mesh refinement.  Curved elements are supported of
   arbitrary order.
   .
   Since version 4.4, Netgen also embeds NGSolve, which is a general
   purpose 3D finite element solver. Version 1.x supports scalar (heat
   flow), elasticity and magnetic field problems.  NGSolve performs
   adaptive mesh refinement, the matrix equations are solved by optimal
   order multigrid methods.
   .
   Homepage: http://www.hpfem.jku.at/netgen/

Denis


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

Re: apt PARALLELISM

On Mon, 12 Dec 2005, Henning Makholm wrote:
> As far as I read the proposal, it is about downloading _different_
> files from different mirrors - if you have 25 packages to get for your
> 'apt-get update' operation, download 5 packages from each of 5
> different servers, with one connection to each server active at a
> time.
> 
> While I cannot see any very common situation where such parallellism
> would be an advantage, it is not clear that it would increase the load
> of any or all servers.

It would be an advantage *to the receiving end* if TCP/IP is the limiting
factor, as it compresses in time the number of connections made, thus more
of them are active at the same time and not interfering with one another.

Depending on how the queues work, even when the ISP backbone is full, trying
for more connections might increase your overall transfer speed *at the
undeniable fact that you will be making it worse for everyone else in the
ISP*.

OTOH, this compresses in time the resources used by a single individual.
Whether this translates to diminished experience for a large group of
individuals (which will also have compressed their resource usage profile in
time) or not, is not such a simple question.

> from each of the 5 servers, but sequentially such that only a single
> connection to a single server is active. And the difference from
> _that_ to an actual parallel implementation is just to shift the
> connections each server experiences a bit in time - the number of KB
> served by each server stays constant.

The bandwidth is constant, yes.  The ammount of active connections and the
aggregate flow speed is not, it increases as you have compressed time.  I.e.
you use more resources for a shorter time.  

THis is not something that would bother anyone if it is a single user... but
if you have 10k users doing that, often close enough in time, well, things
should get MUCH worse as far as I can see.  If they are doing this at random
times in the day, OTOH, it would not be that bad, I guess.

> Is your point that a server prefers to push bytes through the
> connection at a constant rate, and starts wasting resources if the

Constant _total_ average flow rates are *always* the best to work with IMHO,
but that was not what I was talking about.

> servers? But when the bottleneck is closest to the client, enabling
> parallel downloads would not make much sense anyway.

They do.  I have experienced them, I have a 4Mbit/s cable downlink at the
moment, I can assure you that, unless the ISP is having trouble on the
last-mile feeder (i.e. extreme packet loss, trying to pump more in the wire
just makes things worse), it improves my download speed to have multiple
connections (it doesn't matter if I am transfering the same data or not, I
am talking about the aggregate flow here).

Whether MY [a single individual] increased download speed is worth the extra
load on the mirror network, and whether it WOULD increase the load on the
mirror network is what we are asking here.

(and for the people who can't read whole threads, my position is that we
should never decrease the experience of a group of people to increase the
experience of an individual).

> (Of course, Goswin has a valid point that some people have their
> sources.list deliberately written with a remote, undesirable, server
> at the end as a _fallback_ option. Therefore parallelism should at
> best be an _option_, not something that apt starts doing unbidden).

Agreed.

> >From that experience, a last-mile link in the 1 Mb/s range would still
> seem to be the limiting factor - and therefore people at the end of
> such links would have little use for parallelism in the first place.

That's not how it works when you have shitty backbone connectivity, like in
Brazil.  It doesn't matter if they deliver 4Mbit/s to your home, the
network in the middle is crap when compared to what I've seen in the USA and
Europe.

-- 
  "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: Debian and the desktop (was: Re: Complaint about #debian operator)

2005-12-12 Thread martin f krafft

also sprach Michael Banck <[EMAIL PROTECTED]> [2005.12.12.1405 +0100]:
> I don't understand why for Etch, if a user chooses "Desktop" during
> tasksel, they shouldn't get the just works[tm] experience.

Yeah, and let's draw from the work by the Ubuntu guys, rather than
doing it a different way!
 
> Ubuntu's excellence shouldn't be an excuse to sit back and not
> make our Desktop the best possible.

Very well put.

-- 
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!
 
it's as bad as you think, and they are out to get you.


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

Re: Debian and the desktop


Yeah, and let's draw from the work by the Ubuntu guys, rather than
doing it a different way!


But doesn't Ubuntu use Debian installer?


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

Re: apt PARALLELISM

As far as I read the proposal, it is about downloading _different_files from different mirrors - if you have 25 packages to get for your
'apt-get update' operation, download 5 packages from each of 5different servers, with one connection to each server active at atime.That is what I mean ...

Re: apt PARALLELISM

2005-12-12 Thread Olaf van der Spek

On 12/12/05, Ivan Adams <[EMAIL PROTECTED]> wrote:
>
>
> > As far as I read the proposal, it is about downloading _different_
> > files from different mirrors - if you have 25 packages to get for your
> > 'apt-get update' operation, download 5 packages from each of 5
> > different servers, with one connection to each server active at a
> > time.
> >
>
> That is what I mean ...

But with HTTP pipelining you can download all 25 files with only a
single TCP connection.
Using 5 TCP connections (to different servers) instead of 1 simply
means you're using more resources for yourself.

Re: apt PARALLELISM

My goal is using more bandwidth with apt-proxy servers on my friends, who have other internet connection.And I want to download first packet from my internet and second packet at the same time from the apt-proxy with my friend internet connection.
Now, I can only download all packets from my internet, and if it fails will go to the apt-proxy ...

Re: apt PARALLELISM


Ivan Adams wrote:


My goal is using more bandwidth with apt-proxy servers on my friends, who
have other internet connection.
And I want to download first packet from my internet and second packet at
the same time from the apt-proxy with my friend internet connection.

Now, I can only download all packets from my internet, and if it fails will
go to the apt-proxy ...


Sounds like your /etc/apt/sources.list does not match your expectations. 
Servers will be used in the order they appear in the file.



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

Re: apt PARALLELISM

2005-12-12 Thread Bas Zoetekouw

Hi Ivan!

You wrote:

> 
> As far as I read the proposal, it is about downloading _different_
> files from different mirrors - if you have 25 packages to get for your
> 'apt-get update' operation, download 5 packages from each of 5
> different servers, with one connection to each server active at a
> time.
> 
> That is what I mean ...  

But what would you gain from that?  In my experience, the mirrors are
fast enough to saturate anything but the fastest (100Mb) links.  

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


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

Re: apt PARALLELISM

2005-12-12 Thread Simon Richter


Hi,

Bas Zoetekouw wrote:


But what would you gain from that?  In my experience, the mirrors are
fast enough to saturate anything but the fastest (100Mb) links.  


I think the idea is

a) load-balancing over multiple DSL lines
b) checking a bunch of apt-proxy servers whether they can provide the 
file instantantaneously before asking one to actually get the file (with 
the added constraint that a different server be queried for every file 
not present anywhere, so the load balancing will still work).


My suggestion would be to simply drop apt-proxy and turn towards squid, 
which can do exactly that (there is an inter-proxy protocol); it will 
take a bit to configure it to let .deb files live longer than other 
files (since they don't change), but should not be too hard). The only 
thing it doesn't do is load balancing the DSL lines.


   Simon


signature.asc
Description: OpenPGP digital signature

Re: Debian and the desktop

2005-12-12 Thread Christian Perrier

Quoting Linas Zvirblis ([EMAIL PROTECTED]):
> >Yeah, and let's draw from the work by the Ubuntu guys, rather than
> >doing it a different way!
> 
> But doesn't Ubuntu use Debian installer?


Yes, but they don't use tasksel...which is the one installing a
"desktop" task.

>From the D-I team point of view: there are certainly tons of things to
improve in our default installs, especially when we exit the real
domain of D-I and enter the domain of general setup of a default
system.

Here, let's face it: we have no team working on this in Debian. The
result of a default desktop install for Debian is the result of what
we get when installing X, then Gnome+KDE and some other stuff.

This is something that comes outside the scope of the D-I team, at
least as we currently work.

We (D-I team) maintain tasksel, yes (mostly Joey) but we don't do that
much more. We don't really do choices because we aren't in a position
of doing choices (hey, this is why "desktop" installs the whole bloat
of KDE *AND* Gnome ). 

As a result, the default Debian desktop worksbut it lacks a few
polishing features which our custom^W users find in other distros

Examples?

-default sound setup
-default wireless setup
-design of the default login screen
-probably tons of details which, alone, aren't a big deal...but will
 make the difference at the end.

"Are we devoted to our users?", asked Marga at Debconfwe should
think about this sometimes...:)



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

Re: buildd administration

2005-12-12 Thread Russ Allbery

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Ok, lets take an example: Where is the source thrown at you for
> www.debian.org?

> It isn't. You have to ask around, get to know or dig deep along the
> links to find cvs.debian.org.

Funny, I just did a Google search for

site:www.debian.org cvs repository www.debian.org

and there it was, plain as day.

> Ingo and I wanted to improve the (still non public) buildd.d.o scripts
> and were rejected with "All the info is already there". That is why
> buildd.net now runs the scripts. The warning bells ring with buildd.d.o,
> not buildd.net.

> And yes, the buildd.net scripts are now closed sourced if you will. But
> the offer to open them up, to integrate them into and improve buildd.d.o
> was made long before that and still stands.

See, what you keep missing is that, regardless of the willingness of the
current buildd maintainers to work with you, you are using the openness or
not of your work as a bargaining point.  I have serious philosophical
problems with that.

Until such time as the proposed new infrastructure is *actually* free
software, as opposed to a bargaining chip, I personally consider your
objections invalid and completely support the decision of the buildd team.
Even if the current software isn't publically available for whatever
reason (personally, I'm putting my money on "hacked into place over time
and not particularly easy to massage into a form someone else could run,"
but who knows), if you want to make an argument that your stuff is better,
you have to actually release it as free software as far as I'm concerned.
It's the minimal bar to meet, and it's not even interesting to have a
conversation with you about it until you meet that bar.

-- 
Russ Allbery ([EMAIL PROTECTED])   

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

Re: Debian and the desktop


Replying to Christian Perrier.

I see what you mean. But who is going to create The Debian Style? Maybe 
a contest is needed?



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

Re: buildd administration

2005-12-12 Thread Ingo Juergensmann

On Mon, Dec 12, 2005 at 10:46:10AM -0800, Russ Allbery wrote:

> Even if the current software isn't publically available for whatever
> reason (personally, I'm putting my money on "hacked into place over time
> and not particularly easy to massage into a form someone else could run,"

That's one part of the reasons... 

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: Debian and the desktop

2005-12-12 Thread Simon Richter


Hi,

Christian Perrier wrote:


From the D-I team point of view: there are certainly tons of things to
improve in our default installs, especially when we exit the real
domain of D-I and enter the domain of general setup of a default
system.


The point is that this is not the a task for d-i. If an user wants to 
install the desktop task later on, there is no d-i in the background 
anymore, but the user experience should be about the same. So it's a 
packaging issue.



-default sound setup


Sound is symptomatic of a much larger class of problems, namely that 
there is no system service that forwards resources other than display 
and keyboard to the user currently logged in. In Unix, the default is to 
lock people out, so in the default setup there is no sound and USB stick 
access (the Windows way of allowing anyone to access all devices opens 
another can of worms). What would be required is some resource 
forwarding framework in which a priviledged process will pass out 
handles to sound/usb/floppy/... to anyone who asks via the proper 
channels (X11 springs to mind, as only clients belonging to the user 
logged in should have access to the display) or presenting the proper 
credentials. This would not be a Debian specific solution.



-default wireless setup


This is also related to the clash of the two approaches ("multiuser 
system with capable admin" versus "single-user personal system where all 
users need admin priviledge to associate to new APs as they roam with 
their laptop"). What we need is a solution that handles the in-between 
cases as well, and it's not Debian specific either.


The most pressing issues are those that lie in system design and are not 
distribution specific. That Ubuntu doesn't have those issues to the 
extent Debian has is related to the "single-user with sudo" approach 
they have taken, but this is not a solution.


   Simon


signature.asc
Description: OpenPGP digital signature

Re: Packages-arch-specific

2005-12-12 Thread Russ Allbery

Steve Langasek <[EMAIL PROTECTED]> writes:

> Right, well, as noted, it's generally a fairly low priority to get
> packages added to P-a-s -- even though it's an eventual goal, the waste
> just really isn't so much (in the usual case) to warrant a rush job.  So
> from that standpoint, as long as there is quite such the backlog on
> P-a-s that there is (from what I can see), it seems like something
> maintainers should also give a pretty low priority to.

Yeah, that makes sense.

I agree with the other message that having something in the BTS for this
is probably a good idea.  That way, one knows the message has been
received and is in a queue somewhere and that people will pick it up when
they get a chance, or if it really belongs somewhere else, they can easily
transfer it or close it or what have you.

> Anyway, you could always try throwing this in Adam's direction as well
> now that he's listed as a co-maintainer of the file.

I noticed that just as I was sending the last message and may do that.

> Well, except between the time you wrote this message and the time I'm
> drafting a reply to it, I've filed/upgraded at least three bugs about
> packages wrongly limiting themselves to Architecture: i386; and I'm sure
> there are plenty more out there in the packages I haven't looked at yet.
> Skills do vary among maintainers, and especially among novice
> maintainers there's certainly a tendency to mark packages as
> arch-specific when they shouldn't be.  If P-a-s were being updated
> automatically based on whatever the maintainer thinks should be there,
> it would've been substantially harder to find these bugs.

Oh, hm, yeah, good point.  I wasn't thinking to base it on the control
file so much as letting the maintainer send a PGP-signed message somewhere
to change it, but either way, that's a concern.

-- 
Russ Allbery ([EMAIL PROTECTED])   

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

Re: Debian and the desktop

2005-12-12 Thread Joey Hess

Christian Perrier wrote:
> (hey, this is why "desktop" installs the whole bloat of KDE *AND* Gnome ). 

It's possible that this statement is false, and that some change might
have been made in this area under less than clear circumstances as a
kind of experiment just to see how long it takes for someone to notice
and what traspires if they do. Or not.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian and the desktop

On Mon, Dec 12, 2005 at 08:25:49PM +0100, Simon Richter <[EMAIL PROTECTED]> was 
heard to say:
> >-default sound setup
> 
> Sound is symptomatic of a much larger class of problems, namely that 
> there is no system service that forwards resources other than display 
> and keyboard to the user currently logged in... [snip]
>  What would be required is some resource 
> forwarding framework in which a priviledged process will pass out 
> handles to sound/usb/floppy/... [snip]
>
> >-default wireless setup
> 
> This is also related to the clash of the two approaches ("multiuser 
> system with capable admin" versus "single-user personal system where all 
> users need admin priviledge to associate to new APs as they roam with 
> their laptop"). What we need is a solution that handles the in-between 
> cases as well, and it's not Debian specific either.

  Essentially what you are saying is that since we can't provide a 100%
generic solution that works perfectly in every concievable situation by
default, we shouldn't bother making the default install work better in
any situation (even, say, one that accounts for the overwhelming majority
of current and potential users).  This is certainly in keeping with Debian
tradition, and it's also the reason I now hand out Ubuntu CDs instead of
Debian ones to new users.

  Daniel


signature.asc
Description: Digital signature

Reminder: pre-Christmas bug squashing ends Wednesday

2005-12-12 Thread martin f krafft

Dear fellow developers and contributors,

This is a reminder that the bug squashing period I announced on
24 Nov 2005 is ending this coming Wednesday, 11:59 CET.

For more information, please see

  http://lists.debian.org/debian-devel-announce/2005/11/msg00019.html

Kind regards,

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


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

Re: Packages up for adoption: gnokii, coldsync

2005-12-12 Thread David Moreno Garza

On 15:03 Sun 11 Dec 2005, George Wright wrote:
> * on Sun, Dec 11, 2005 at 12:21:28PM +1000, Bradley Marshall wrote:
> 
> > I'm not sure if this is the right process to follow, so please
> > let me know if there's something else I should be doing.
> 
> ditto for me - shall I fill in an ITA? I'm not a DD and am unsure as to how 
> to proceed.

Yes, please.

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 Por mi raza, hablará el espíritu.


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

Re: Debian and the desktop

2005-12-12 Thread Joey Hess

Daniel Burrows wrote:
> On Mon, Dec 12, 2005 at 08:25:49PM +0100, Simon Richter <[EMAIL PROTECTED]> 
> was heard to say:
> > >-default sound setup
> > 
> > Sound is symptomatic of a much larger class of problems, namely that 
> > there is no system service that forwards resources other than display 
> > and keyboard to the user currently logged in... [snip]
> >  What would be required is some resource 
> > forwarding framework in which a priviledged process will pass out 
> > handles to sound/usb/floppy/... [snip]
> >
> > >-default wireless setup
> > 
> > This is also related to the clash of the two approaches ("multiuser 
> > system with capable admin" versus "single-user personal system where all 
> > users need admin priviledge to associate to new APs as they roam with 
> > their laptop"). What we need is a solution that handles the in-between 
> > cases as well, and it's not Debian specific either.
> 
>   Essentially what you are saying is that since we can't provide a 100%
> generic solution that works perfectly in every concievable situation by
> default, we shouldn't bother making the default install work better in
> any situation (even, say, one that accounts for the overwhelming majority
> of current and potential users).  This is certainly in keeping with Debian
> tradition, and it's also the reason I now hand out Ubuntu CDs instead of
> Debian ones to new users.

Which is the kind of statement that truely puzzles me, since the
permissions issues Simon was talking about[1] are some of the things that
we went ahead and fixed in the obvious quick-and-dirty make-it-work way in
sarge.

This kind of disconnect between what an installed Debian system actually
does, what some developers think it does, and results like Debian
developers passing out Ubuntu CDs instead of contributing more fixes to
Debian is intensely frustrating to me.

-- 
see shy jo

[1] Which are AFAIK not the same ones that Christian was talking about,
since Christian happens to maintain the package that fixed them!


signature.asc
Description: Digital signature

Re: Debian and the desktop

2005-12-12 Thread David Moreno Garza

On 21:01 Mon 12 Dec 2005, Linas Zvirblis wrote:
> Replying to Christian Perrier.
> 
> I see what you mean. But who is going to create The Debian Style? Maybe 
> a contest is needed?

What are you talking about Debian Style?

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 Save the planet, it is the only one with chocolate.


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

Re: apt PARALLELISM

2005-12-12 Thread Joey Hess

Marco d'Itri wrote:
> > Or at least fall back to the other IPs if the first one gives an
> > error?
> I hope that this already happens...

apt doesn't know anything about round robin dns, and especially with
secure apt, if one mirror gets out of sync things break horribly. This
recently happened with http.us.debian.org which had one mirror desynced
for a week or more (or perhaps still; I had to stop using it because of
that).

-- 
see shy jo

signature.asc
Description: Digital signature

Re: Debian and the desktop

2005-12-12 Thread David Moreno Garza

On 20:25 Mon 12 Dec 2005, Simon Richter wrote:
> This is also related to the clash of the two approaches ("multiuser 
> system with capable admin" versus "single-user personal system where all 
> users need admin priviledge to associate to new APs as they roam with 
> their laptop"). What we need is a solution that handles the in-between 
> cases as well, and it's not Debian specific either.

I think that when pointing at 'desktop' task is to make all of this
available. Selecting it will override the fact that the system you are
setting up is multi or uniuser. This shouldn't care to the desktop task.
The sound system should be set, as well as the wireless thing and other
stuff, in spite of the availability of these or how the system will be
used.

> The most pressing issues are those that lie in system design and are not 
> distribution specific. That Ubuntu doesn't have those issues to the 
> extent Debian has is related to the "single-user with sudo" approach 
> they have taken, but this is not a solution.

Why not? I think I couldn't understand correctly your point here.

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 "The number of RC bugs in Debian is..." -Steve Langasek.

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

Re: Debian and the desktop

2005-12-12 Thread Frans Pop

On Monday 12 December 2005 21:25, Joey Hess wrote:
> It's possible that this statement is false, and that some change might
> have been made in this area under less than clear circumstances as a
> kind of experiment just to see how long it takes for someone to notice
> and what traspires if they do. Or not.

Hmm. I do know why the change was made and expect either
- a reversal to the Sarge situation when the reasons for the change have
  disappeared;
_or_
- a proper discussion on wether to keep things as they are now, default to
  "the other" desktop (no, not that one ;-) or a solution where the user
  is actually offered a choice during the installation (which has always
  been my personal preference).

Keeping the current situation just because nobody comments is not a really 
nice thing to do IMO. Please take this as me commenting.


pgp8gW67I2efb.pgp
Description: PGP signature

Re: Debian and the desktop


David Moreno Garza wrote:


What are you talking about Debian Style?


Color scheme, artwork (default wallpaper, login screen, even CD covers). 
All those little things that would make a user say "Yep, that's Debian".


A user should get the same visual feeling whether he chose GNOME or KDE 
for his desktop, whether he decided for KDM or GDM etc. This might sound 
silly for experienced users, but, take my word for it, this is something 
of a major importance to the newbies.


Every major distribution has that little something (be it only a default 
wallpaper) that makes it what it is (navy blue Mandriva, brownish 
Ubuntu), so if desktop is the goal for Debian, it should also have that.



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

Re: Debian and the desktop

2005-12-12 Thread David Nusinow

On Mon, Dec 12, 2005 at 11:37:31PM +0200, Linas Zvirblis wrote:
> David Moreno Garza wrote:
> 
> >What are you talking about Debian Style?
> 
> Color scheme, artwork (default wallpaper, login screen, even CD covers). 
> All those little things that would make a user say "Yep, that's Debian".

Check out the windowmaker package. It has (or had as of a few years ago) a
beautiful Debian theme complete with a very nice wallpaper. Creating
similar themes for other window managers and desktop environments would be
great.

 - David Nusinow

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

In-Reply-To [was: Re: buildd administration]

2005-12-12 Thread Kevin B. McCarty

Nathanael Nerode wrote:

> This is an omnibus reply. Sorry about the thread-breaking, but I'm on
> yet *another* computer, and I can't seem to find a mailer which
> respects the In-Reply-To headers from the web pages or lets me add my
> own.

Off-topic, but Moz Thunderbird in Debian at least does the former.  (I
wrote and submitted the patch myself, since it's how I reply to d-d
without being subscribed :-)  One still has to fix the subject, any
quotes, etc. by hand of course.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544

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

Re: Debian and the desktop

2005-12-12 Thread Gustavo Noronha Silva

Em Seg, 2005-12-12 às 23:37 +0200, Linas Zvirblis escreveu:
> David Moreno Garza wrote:
> 
> > What are you talking about Debian Style?
> 
> Color scheme, artwork (default wallpaper, login screen, even CD covers). 
> All those little things that would make a user say "Yep, that's Debian".

The desktop-base package was supposed to address exactly that problem,
but there was not a lot of interest in the KDE and GNOME teams to
actually work on that.

I think we have managed to create some feeling on the GNOME front,
though, with a default desktop and customized splash screen. GDM lacks
integration, though.

> Every major distribution has that little something (be it only a default 
> wallpaper) that makes it what it is (navy blue Mandriva, brownish 
> Ubuntu), so if desktop is the goal for Debian, it should also have that.

That'd be something, but there's much more that we should think about.
This is just the top of the iceberg.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  

signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: Debian and the desktop

2005-12-12 Thread Roberto C. Sanchez

David Nusinow wrote:
> On Mon, Dec 12, 2005 at 11:37:31PM +0200, Linas Zvirblis wrote:
> 
>>David Moreno Garza wrote:
>>
>>
>>>What are you talking about Debian Style?
>>
>>Color scheme, artwork (default wallpaper, login screen, even CD covers). 
>>All those little things that would make a user say "Yep, that's Debian".
> 
> 
> Check out the windowmaker package. It has (or had as of a few years ago) a
> beautiful Debian theme complete with a very nice wallpaper. Creating
> similar themes for other window managers and desktop environments would be
> great.
> 
>  - David Nusinow
> 
> 

Better yet, we should make WindowMaker the only window manager in
Debian.  Down with GNOME and KDE!

Does it show that I am a WindowMaker fan? :-)

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: Debian and the desktop

2005-12-12 Thread Eduard Bloch

#include 
* Joey Hess [Mon, Dec 12 2005, 03:53:02PM]:

> This kind of disconnect between what an installed Debian system actually
> does, what some developers think it does, and results like Debian
> developers passing out Ubuntu CDs instead of contributing more fixes to
> Debian is intensely frustrating to me.

Welcome to reality. I remember people saying that boot-floppies had no
i18n or USB support at all (etc.) even long time after Woody has been
released. Looks like some kind of mental inertia.

Eduard.
-- 
 und warum ist der nicht so schön bunt wie bei Suse?


signature.asc
Description: Digital signature

Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

  The attached text is a first draft of a proposed extension to the
Description field to explicitly handle bulleted lists.  The extended
syntax allows list items to be treated specially by frontends (for
instance, bullet characters can be replaced with graphics, and the
body of the list item can be word-wrapped); current Descriptions should
either parse correctly or be no worse off than they currently are.
Current versions of aptitude implement this proposal.

  Daniel
  Abstract:

  This document describes a proposed extension to the Description
formatting policy (policy section 5.6.13) to support better formatting
of bullet lists in package descriptions.  The proposed policy is
primarily a formalization of existing best practice regarding bullets;
most current package descriptions will parse as expected with no
changes, and packages that do not can easily be converted to the new
format without degrading presentation in legacy package management
tools.

  The Description extensions described in this document are presently
implemented in aptitude (>= 0.4.0).

  Background and Motivation:

  Policy 5.6.23 provides for "preformatted" lines in descriptions.
These are lines beginning with at least two spaces, and will be
displayed verbatim; they are either unwrapped or hard-wrapped.  The
current best-practice approach to including bullet lists in package
descriptions is to write each line of the list as a preformatted line;
for instance,

= snip here =
 QEMU is a FAST! processor emulator: currently the package supports
 arm, powerpc, sparc and x86 emulation. By using dynamic translation
 it achieves reasonable speed while being easy to port on new host
 CPUs. QEMU has two operating modes:
 .
  * User mode emulation: QEMU can launch Linux processes compiled for
one CPU on another CPU.
  * Full system emulation: QEMU emulates a full system, including a
processor and various peripherials. It enables easier testing and
debugging of system code. It can also be used to provide virtual
hosting of several virtual PC on a single server.
 .
 As QEMU requires no host kernel patches to run, it is very safe and
 easy to use.
= snip here =

  This convention has several serious limitations, however.  Perhaps
most importantly, it does not gracefully accomadate smaller terminals;
while other paragraphs are word-wrapped by conforming user interfaces,
word-wrapping of these preformatted paragraphs is (rightly) forbidden.
This leads to poor readability when the terminal size is decreased;
for instance, formatting to 60 columns produces:

= snip here = 
QEMU is a FAST! processor emulator: currently the package
supports arm, powerpc, sparc and x86 emulation. By using
dynamic translation it achieves reasonable speed while being
easy to port on new host CPUs. QEMU has two operating modes:

* User mode emulation: QEMU can launch Linux processes compi
led for
  one CPU on another CPU.
* Full system emulation: QEMU emulates a full system, includ
ing a
  processor and various peripherials. It enables easier test
ing and
debugging of system code. It can also be used to provide
 virtual
hosting of several virtual PC on a single server.
 .
 As QEMU requires no host kernel patches to run, it is very
safe and easy to use.
= snip here =

  In contrast, the proposed mechanism allows this description to be
formatted in 60 columns as follows:

= snip here =
 QEMU is a FAST! processor emulator: currently the package
 supports arm, powerpc, sparc and x86 emulation. By using
 dynamic translation it achieves reasonable speed while
 being easy to port on new host CPUs. QEMU has two operating
 modes: 
 
 * User mode emulation: QEMU can launch Linux processes
   compiled for one CPU on another CPU. 
 * Full system emulation: QEMU emulates a full system,
   including a processor and various peripherials. It
   enables easier testing and debugging of system code. It
   can also be used to provide virtual hosting of several
   virtual PC on a single server. 
 
 As QEMU requires no host kernel patches to run, it is very
 safe and easy to use.
= snip here =

Extensions to the syntax of Description blocks:

  As mentioned above, all lines beginning with two or more spaces are
treated identically under current Policy.  This proposal introduces
the concept of a /bulleted block/.  A bulleted block consists of a
series of lines such that:

  (1) The first line begins with N > 2 spaces,

  (2) The first non-space character of the first line is a bullet
  character, and

  (3) Each subsequent line begins with at least N + 1 + M spaces,
  where M is the number of spaces immediately following the first
  non-space character of the first line.

  For the purposes of this definition, the bullet characters are [*-+].

  The following are examples of bulleted blocks:

= snip here =
 * If Peter Piper picked a peck of pickled pepp

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread sean finney

On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote:
>   The attached text is a first draft of a proposed extension to the
> Description field to explicitly handle bulleted lists.  The extended

wow! that's quite a document.  i'm glad to see that people are
focusing on the Really Big problems facing debian today.

okay, that was a bit punchy... sorry i couldn't help it :)

seriously though, i think the proposal is quite well written.  the only
critique i have is that i think it's maybe going a little too far out
there to talk about nested lists, as i can't imagine them being at all
practical in what's supposed to be a short, informative description of
a package.

sean

signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Peter Samuelson


[Daniel Burrows]
>   (1) The first line begins with N > 2 spaces,

Don't you mean N >= 2?

>   (2) The first non-space character of the first line is a bullet
>   character, and
> 
>   (3) Each subsequent line begins with at least N + 1 + M spaces,
>   where M is the number of spaces immediately following the first
>   non-space character of the first line.

I think that's overgeneral.  I do not see the point in allowing M != 1.
I say keep the spec simple; forcing frontends to include parsing
complexity that doesn't even add anything useful is a Bad Thing.

(If aptitude wants to handle M != 1 in order to make certain legacy
descriptions look better, fine, but I don't think it should be
explicitly condoned.)

>   For the purposes of this definition, the bullet characters are [*-+].

Agreed, "o" was always a hack, though one I myself have been guilty of.

> The individual lines within a bulleted block should be parsed as if
> N+M characters were stripped from the left-hand side of the block (if
> M=0, the initial bullet character should be treated as if it were a
> space).

See above about supporting M == 0.  It doesn't even look good in legacy
frontends.  And as you say later on a related subject:

>   Furthermore, fixing the description in this case is trivial.

Peter


signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Roger Leigh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Burrows <[EMAIL PROTECTED]> writes:

>   The attached text is a first draft of a proposed extension to the
> Description field to explicitly handle bulleted lists.

That's quite a complex document for something I believe should be
quite simple.

When I use Emacs, it can reflow text (M-q) by looking at the
indentation level of the following lines.  It can even cope with
bullets, outdents, indents, etc.  If a frontend display routine could
handle that, that would solve the problem generically, and would
handle any level of indentation required.

Specifically regarding bullets: We now have UTF-8 encoded control
files, so why not simply use the UCS bullet character (U+2022)?

Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFDng9YVcFcaSW/uEgRApKxAKCVYU3MScc4m28D7wEuUHzRG2hRgACfaYIn
m0MyBHEJLb5GGqmzOigDuis=
=79Bc
-END PGP SIGNATURE-

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

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

On Mon, Dec 12, 2005 at 06:38:59PM -0500, sean finney <[EMAIL PROTECTED]> was 
heard to say:
> On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote:
> >   The attached text is a first draft of a proposed extension to the
> > Description field to explicitly handle bulleted lists.  The extended
> 
> wow! that's quite a document.  i'm glad to see that people are
> focusing on the Really Big problems facing debian today.
> 
> okay, that was a bit punchy... sorry i couldn't help it :)
> 
> seriously though, i think the proposal is quite well written.  the only
> critique i have is that i think it's maybe going a little too far out
> there to talk about nested lists, as i can't imagine them being at all
> practical in what's supposed to be a short, informative description of
> a package.

  That's a fair point, but I felt that there wasn't any reason to
artificially restrict the sorts of lists that could be handled when
nested lists can be dealt with in such a natural fashion.  There are at
least a few cases where I can imagine two-level lists being useful,
and they seem to exist in the wild (see samhain and xml-core, for instance).

  One interesting question that I can see is whether to treat a
*word-wrapped* line that starts with a bullet character as a bulleted
item.  Doing so would make several more natural ways of expressing lists
work, especially nested lists -- the example in my document is actually
wrong!  On the other hand, doing this at the top-level would mean that
conforming descriptions wouldn't degrade cleanly, while doing it only for
sub-lists is inelegant.

  Daniel

signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Jeroen van Wolffelaar

On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote:
>   The attached text is a first draft of a proposed extension to the
> Description field to explicitly handle bulleted lists.  The extended
> syntax allows list items to be treated specially by frontends (for
> instance, bullet characters can be replaced with graphics, and the
> body of the list item can be word-wrapped); current Descriptions should
> either parse correctly or be no worse off than they currently are.
> Current versions of aptitude implement this proposal.

Excellent initiative to work on this.

> Extensions to the syntax of Description blocks:
> 
>   As mentioned above, all lines beginning with two or more spaces are
> treated identically under current Policy.  This proposal introduces
> the concept of a /bulleted block/.  A bulleted block consists of a
> series of lines such that:

s/lines/series of items/, otherwise, you'd have a a series of lines that
each consist of a number of lines: ambigious (or at least confusing)
wording.

>   (1) The first line begins with N > 2 spaces,

That should be N >= 2 I presume, otherwise, your examples are
inconsistent with this definition. Also, I think that for inclusion in
policy the text should make clear that the leading space required for
line continuation in the control file block is included in N.

>   (2) The first non-space character of the first line is a bullet
>   character, and
> 
>   (3) Each subsequent line begins with at least N + 1 + M spaces,
>   where M is the number of spaces immediately following the first
>   non-space character of the first line.

I'd note that M might be as small as zero. This is implied by the lack
of prohibition in (2), but it can't hurt to be clear.

>   For the purposes of this definition, the bullet characters are [*-+].

Better write [*+-], to prevent needless ambiguity with regex syntax,
where [*-+] actually means '*' or '+', excluding '-'. Or just list the
three characters.

In concreto, I'd suggest using the following definition instead, also
covering the nested bulleting that's only defined-by-example below:

For in policy 5.6.12:

 * Those starting with two or more spaces. These will be displayed
   verbatim, unless it is part of a bulleted list. The first line of a
   bulleted list will start, after the two or more spaces, with a bullet
   character ('*', '-' or '+'), followed by zero or more spaces,
   followed by the beginning of the item text. Each line after this line
   will be either:
- continued bullet item text, indented at least as far as the
  beginning of the bullet item text on the line of the last bullet,
  or
- a subsequent bullet item, with the same bullet item character,
  indented at the same level, with the item text also starting at
  the same (or deeper) level as the first bullet item
- a nested bullet item, according to the rules of a first top-level
  bullet item line, but indented at least as deep as the bullet item
  text of the current level

  Every other line not matching the definition above is considered to be
  part of a verbatim text block, and the bullet item list is then
  supposed to be terminated on the preceeding line.

I do think this does make it a bit complicated though... hm.

>   The following are examples of bulleted blocks:
> 
> = snip here =
>  * If Peter Piper picked a peck of pickled peppers, how many pickled 
> peppers did Peter Piper pick?
> 
>  *Fourscore and
>   seven years ago,
>   our forefathers brought forth upon this continent
>   a new nation.
>   .
>-- Abraham Lincoln, 16th President of the United States of America

According to your and my definition, this would be a bullet item too,
like (in HTML) - Abraham Lincoln (...) America ? Or how do I
misread your definition then, if this is *not* an instance of a bulleted
list?

Alternative:

A totally different way might be to exploit policy's opportunity to
extending the description syntax. Policy 5.6.12 explicitely states that
lines starting with a dot should not be used and are left open for
future expansions. So why not use *that*? Like, definition by example:

Descrition: Great package to moo
 This package totally rocks, because:
 . It has super cow powers
 . The internet access point at the Wig and Pen bar is using this
   package too, and customers are happy with it
   . This includes Lachlan McOmish
   . And more stuff
  This
   is
a
   verbatim
  block (indented at least one space more than normal continuation
  bullet text would need to be)
 . It's written in whitespace, with a level editor in brainfuck

This will allow for both verbatim blocks in bulleted lists, will leave
verbatim blocks totally like they are today, no redefinitions, and
enables to be defined more easily (no need to care for what happens with
looks-like-bulleted-but-isn't-bulleted stuff).

Only disadvantage I see is closing the door for ev

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

On Mon, Dec 12, 2005 at 05:49:02PM -0600, Peter Samuelson <[EMAIL PROTECTED]> 
was heard to say:
> 
> [Daniel Burrows]
> >   (1) The first line begins with N > 2 spaces,
> 
> Don't you mean N >= 2?
> 
> >   (2) The first non-space character of the first line is a bullet
> >   character, and
> > 
> >   (3) Each subsequent line begins with at least N + 1 + M spaces,
> >   where M is the number of spaces immediately following the first
> >   non-space character of the first line.
> 
> I think that's overgeneral.  I do not see the point in allowing M != 1.
> I say keep the spec simple; forcing frontends to include parsing
> complexity that doesn't even add anything useful is a Bad Thing.
> 
> (If aptitude wants to handle M != 1 in order to make certain legacy
> descriptions look better, fine, but I don't think it should be
> explicitly condoned.)

  Good point.  I've adjusted this in my copy (updated version attached).

  Daniel
  Abstract:

  This document describes a proposed extension to the Description
formatting policy (policy section 5.6.13) to support better formatting
of bullet lists in package descriptions.  The proposed policy is
primarily a formalization of existing best practice regarding bullets;
most current package descriptions will parse as expected with no
changes, and packages that do not can easily be converted to the new
format without degrading presentation in legacy package management
tools.

  The Description extensions described in this document are presently
implemented in aptitude (>= 0.4.0).

  Background and Motivation:

  Policy 5.6.23 provides for "preformatted" lines in descriptions.
These are lines beginning with at least two spaces, and will be
displayed verbatim; they are either unwrapped or hard-wrapped.  The
current best-practice approach to including bullet lists in package
descriptions is to write each line of the list as a preformatted line;
for instance,

= snip here =
 QEMU is a FAST! processor emulator: currently the package supports
 arm, powerpc, sparc and x86 emulation. By using dynamic translation
 it achieves reasonable speed while being easy to port on new host
 CPUs. QEMU has two operating modes:
 .
  * User mode emulation: QEMU can launch Linux processes compiled for
one CPU on another CPU.
  * Full system emulation: QEMU emulates a full system, including a
processor and various peripherials. It enables easier testing and
debugging of system code. It can also be used to provide virtual
hosting of several virtual PC on a single server.
 .
 As QEMU requires no host kernel patches to run, it is very safe and
 easy to use.
= snip here =

  This convention has several serious limitations, however.  Perhaps
most importantly, it does not gracefully accomadate smaller terminals;
while other paragraphs are word-wrapped by conforming user interfaces,
word-wrapping of these preformatted paragraphs is (rightly) forbidden.
This leads to poor readability when the terminal size is decreased;
for instance, formatting to 60 columns produces:

= snip here = 
QEMU is a FAST! processor emulator: currently the package
supports arm, powerpc, sparc and x86 emulation. By using
dynamic translation it achieves reasonable speed while being
easy to port on new host CPUs. QEMU has two operating modes:

* User mode emulation: QEMU can launch Linux processes compi
led for
  one CPU on another CPU.
* Full system emulation: QEMU emulates a full system, includ
ing a
  processor and various peripherials. It enables easier test
ing and
debugging of system code. It can also be used to provide
 virtual
hosting of several virtual PC on a single server.
 .
 As QEMU requires no host kernel patches to run, it is very
safe and easy to use.
= snip here =

  In contrast, the proposed mechanism allows this description to be
formatted in 60 columns as follows:

= snip here =
 QEMU is a FAST! processor emulator: currently the package
 supports arm, powerpc, sparc and x86 emulation. By using
 dynamic translation it achieves reasonable speed while
 being easy to port on new host CPUs. QEMU has two operating
 modes: 
 
 * User mode emulation: QEMU can launch Linux processes
   compiled for one CPU on another CPU. 
 * Full system emulation: QEMU emulates a full system,
   including a processor and various peripherials. It
   enables easier testing and debugging of system code. It
   can also be used to provide virtual hosting of several
   virtual PC on a single server. 
 
 As QEMU requires no host kernel patches to run, it is very
 safe and easy to use.
= snip here =

Extensions to the syntax of Description blocks:

  As mentioned above, all lines beginning with two or more spaces are
treated identically under current Policy.  This proposal introduces
the concept of a /bulleted block/.  A bulleted block consists of a
series of lines such that:

  (1) The first line begins with N >=

Hello,Since, I am not 'valid' poster of this list, my mail me
be blocked by listadmin! I asked DWN to report for foss.in/2005
conference in India and Debian activity during event. Joey can answer
about this post. Thanks Joey to encourage me.

Background:

foss.in/2005 was earlier known as Linux Bangalore -YEAR [1] Starting
from 2001 it was highly sucessful in terms of both - attendences and
speakers. Speakers was from all over the world. The conference was
renamed in aim with to change focus to particular city and only to
linux - it is now represents more wider choice of Free and Open Source
Software - foss.in itself represnts website name! [2]

Debian at foss.in!

India, the second largest nation in the world - which is top in IT all
over, lacks contibutation towards FOSS and particulary Debian! There
are only 2 active Debian Developers in India. Jaldhar Vyas [3] who
headed Debian-IN Project [4] was worried about the situation. Jaldhar
made it possible to India. Thus, two talks was arranged in conference!
Jaldhar spend most of time in meeting people to explain and answers
question about Debian and Debian-IN. Vaidhy who was DD in past helped a
lot during jaldhar was busy with other work. Debian-IN BOF was
organised and it was successful. Many people signed each other's key
and make thier way towards become Debian Developer.

What Next ?
Lots more! We expect that there should be 20 Debian Developers in
near future. Representation at DebConf6 [5] from India will also make
some difference in situation too. If you are coming to India, please
make announcement and arrange to meet people so that more key-signing
party can be organise.

Well, People behind foss.in is here [6] which includes speakers and oraganisers.
[1] http://linux-bangalore.org/[2] http://foss.in/2005/
[3] http://debian-in.alioth.debian.org/
[4] http://www.braincells.com/debian/
[5] http://debconf.org/
[6] http://planet.foss.in/

Thanks!-- ,_ , Kartik Mistry (O,O) GNU/Linux Developer/Enthu( )Blog : kartikm.blogspot.com -"--"->
<-GPG Key : 0xD1028C8D

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

On Tue, Dec 13, 2005 at 12:01:52AM +, Roger Leigh <[EMAIL PROTECTED]> was 
heard to say:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Daniel Burrows <[EMAIL PROTECTED]> writes:
> 
> >   The attached text is a first draft of a proposed extension to the
> > Description field to explicitly handle bulleted lists.
> 
> That's quite a complex document for something I believe should be
> quite simple.
> 
> When I use Emacs, it can reflow text (M-q) by looking at the
> indentation level of the following lines.  It can even cope with
> bullets, outdents, indents, etc.  If a frontend display routine could
> handle that, that would solve the problem generically, and would
> handle any level of indentation required.

  The heart of the document describes how to do this in a simple and
precise way.  The first section explains some reasons that it's useful
to recognize bulleted lists, while the last couple sections have
implementation notes and analysis of the impact on current frontends
and Descriptions.

> Specifically regarding bullets: We now have UTF-8 encoded control
> files, so why not simply use the UCS bullet character (U+2022)?

  It might make sense to recognize the Unicode bullet character,
but forcing people to use it is not a good idea for several reasons,
with backwards-compatibility being a major one.

  Daniel

signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

On Tue, Dec 13, 2005 at 01:21:41AM +0100, Jeroen van Wolffelaar <[EMAIL 
PROTECTED]> was heard to say:
> On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote:
> > Extensions to the syntax of Description blocks:
> > 
> >   As mentioned above, all lines beginning with two or more spaces are
> > treated identically under current Policy.  This proposal introduces
> > the concept of a /bulleted block/.  A bulleted block consists of a
> > series of lines such that:
> 
> s/lines/series of items/, otherwise, you'd have a a series of lines that
> each consist of a number of lines: ambigious (or at least confusing)
> wording.

  Each bulleted block is one bullet item -- the syntax doesn't care
about sequences of items, just individual ones (although the frontend is
free to treat sequences differently from lone items).

  This can probably be made clearer.  How about this wording?

= snip here =
  As mentioned above, all lines beginning with two or more spaces are
treated identically under current Policy.  This proposal introduces
the concept of a /bulleted block/.  A bulleted block represents the
contents of a single list item; it consists of a series of lines
such that:
= snip here =

> >   (2) The first non-space character of the first line is a bullet
> >   character, and
> > 
> >   (3) Each subsequent line begins with at least N + 1 + M spaces,
> >   where M is the number of spaces immediately following the first
> >   non-space character of the first line.
> 
> I'd note that M might be as small as zero. This is implied by the lack
> of prohibition in (2), but it can't hurt to be clear.

  As was noted in another reply, it probably makes sense to require M == 1
in the spec; only a few packages that I've seen use anything else and
it looks best in legacy frontends.

> >   For the purposes of this definition, the bullet characters are [*-+].
> 
> Better write [*+-], to prevent needless ambiguity with regex syntax,
> where [*-+] actually means '*' or '+', excluding '-'. Or just list the
> three characters.

  Good point.  I'm afraid that I'm guilty of being a bit lazy here.

> In concreto, I'd suggest using the following definition instead, also
> covering the nested bulleting that's only defined-by-example below:

  It actually is defined, but you have to read between the lines.  (it's
the bit about parsing as if N+M spaces were stripped)  Unfortunately, my
example was wrong!  (see attachment)

> For in policy 5.6.12:

  [snip] As you noted, this is a bit hard to read; I'll probably tackle
the problem of writing this up for Policy at some point in the future,
once there's some agreement on what the format should be.

> >   The following are examples of bulleted blocks:
> > 
> > = snip here =
> >  * If Peter Piper picked a peck of pickled peppers, how many pickled 
> > peppers did Peter Piper pick?
> > 
> >  *Fourscore and
> >   seven years ago,
> >   our forefathers brought forth upon this continent
> >   a new nation.
> >   .
> >-- Abraham Lincoln, 16th President of the United States of America
> 
> According to your and my definition, this would be a bullet item too,
> like (in HTML) - Abraham Lincoln (...) America ? Or how do I
> misread your definition then, if this is *not* an instance of a bulleted
> list?

  Yes, that's a good point.  My example includes something that parses
incorrectly :-).  Note, however, that in the wild there are exactly two
packages that break this way in aptitude out of the whole archive
(checked with a regexp search), and that even these would not break if
we required a space after the bullet character.

> Alternative:
> 
> A totally different way might be to exploit policy's opportunity to
> extending the description syntax. Policy 5.6.12 explicitely states that
> lines starting with a dot should not be used and are left open for
> future expansions. So why not use *that*? Like, definition by example:

  I don't like this approach as much for a couple reasons -- it's not as
natural (the format I proposed looks fine without any interpretation at all),
you'd have to edit a lot of packages (most bulleted lists are in the right
format already, in my observation), and it might not display properly
in legacy frontends (frontends might display them literally, but Policy
is silent on how these lines should be handled; aptitude IGNORES
everything past the dot!)

  Daniel

signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Roger Leigh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Burrows <[EMAIL PROTECTED]> writes:

> On Tue, Dec 13, 2005 at 12:01:52AM +, Roger Leigh <[EMAIL PROTECTED]> was 
> heard to say:
>> Daniel Burrows <[EMAIL PROTECTED]> writes:
>> 
>> >   The attached text is a first draft of a proposed extension to the
>> > Description field to explicitly handle bulleted lists.
>> 
>> That's quite a complex document for something I believe should be
>> quite simple.
>> 
>> When I use Emacs, it can reflow text (M-q) by looking at the
>> indentation level of the following lines.  It can even cope with
>> bullets, outdents, indents, etc.  If a frontend display routine could
>> handle that, that would solve the problem generically, and would
>> handle any level of indentation required.
>
>   The heart of the document describes how to do this in a simple and
> precise way.  The first section explains some reasons that it's useful
> to recognize bulleted lists, while the last couple sections have
> implementation notes and analysis of the impact on current frontends
> and Descriptions.

Sure.  This was not meant to be overly critical.  It's just that Emacs
has already solved the problem, and can even cope with the case of a
bullet appearing as the first character of a paragraph line.  You
could just copy that algorithm.

>> Specifically regarding bullets: We now have UTF-8 encoded control
>> files, so why not simply use the UCS bullet character (U+2022)?
>
>   It might make sense to recognize the Unicode bullet character,
> but forcing people to use it is not a good idea for several reasons,
> with backwards-compatibility being a major one.

ACK.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFDnh1JVcFcaSW/uEgRAlMzAKDqO6WNkjnc3n57AmLucFVGWjp9EwCfQTWg
K9wkKPDWKwTCmbj1+X0nc9o=
=IroD
-END PGP SIGNATURE-


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

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Peter Samuelson


[Daniel Burrows]
>   (1) The first line begins with N >= 2 spaces,
>   (3) Each subsequent line begins with at least N + 2 spaces.

Hm.  That brings up the minor point of whether N should ever be
anything but (2 * nest_level).

I don't feel strongly about that one, though.

Also, in the Best Practices section, it would be good to decide whether
blank lines (" .\n") should be used before or after bulleted lists, or
between items.  This is something existing packages are not at all
consistent about.  My feeling is that a blank line should be used
before and after, but *not* in between items.


signature.asc
Description: Digital signature

Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.

2005-12-12 Thread Peter Samuelson


[Peter Samuelson]
> Hm.  That brings up the minor point of whether N should ever be
> anything but (2 * nest_level).

Or if you consider nest_level to be zero-based, (2 + 2 * nest_level).
It occurs to me, though, that some might prefer the raw presentation
look of (2 + 3 * nest_level).  I might even prefer it myself.

Specifying either of those, or leaving it open as it is now, would be
fine with me.


signature.asc
Description: Digital signature

Re: apt PARALLELISM