Re: Proposal regarding future packaging

[Manoj Srivastava]

On Fri, 21 Sep 2007 03:25:23 + (UTC), Oleg Verych (Gmane) <[EMAIL 
PROTECTED]> said: 

> 19-09-2007, Bruce Sass: []
>>> > I like this too. Finding what a package has just installed is one
>>> > of the biggest holes in Debian right now, IMO. I have to use dpkg
>>> > -L to figure this out, and that's just too crude to be a real
>>> > solution.
>>> 
>>> Too crude?  That's a simple command, easily found in a relevant
>>> manpage.  In true Unix fashion, its output can be easily piped to
>>> other commands.  What's crude about it?
>> 
>> It doesn't catch files created by Maintainer scripts?

> This is the design flaw in those scripts (even in whole package
> management).

I am not sure you have made your case here.

Currently, using maintainer scripts, it is indeed possible to
 create a configuration file that is referred to by many packages, but
 is owned by none -- so the file survives even though the package that
 created it went away.

Why is this a design flaw?

manoj

-- 
Save gas, don't use the shell.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Proposal regarding future packaging

[Manoj Srivastava]

On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: 

> On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote:
>> 21-09-2007, Bruce Sass:
>> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote:
>> >> 19-09-2007, Bruce Sass:
>> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has
>> >> > been working on will help solve that wart though.
>> >>
>> >> How exactly?
>> >
>> > Exactly? I don't know. I haven't followed what is happening close
>> > enough.
>> >
>> > Basically, it allows a package to toss up a flag saying, `I'm here
>> > and  needs to be done.' It may require some convention
>> > and a little more infrastructure, but that is close to letting a
>> > package say, `add these paths to the list of paths which I
>> > control.'
>> 
>> Sure. But i thought, we are talking about finding/listing of
>> generated files.

> It is not feasible (imo) to automatically find files created by
> maintainer scripts. Having packages append .list themselves
> would (afaict) require they know too much about dpkg's internal
> operation, and all packages generating files would need to implement
> the algorithm.

> However, maintainer scripts can easily pass a list of generated paths
> on to a shared piece of code which dpkg controls. "triggers" looks
> like it could be the mechanism by which a package flags that it has
> generated files, and by which dpkg exerts control.

But this does not address the case of a file shared by many
 packages but really owned by none.

manoj
-- 
"To IBM, 'open' means there is a modicum of interoperability among some
of their equipment."-- Harv Masterson
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: User-Agent strings, privacy and Debian browsers

[Joey Hess]

Joerg Jaspert wrote:
> On 11150 March 1977, Peter Eckersley wrote:
> > I've seen reports from very large sites indicating that User-Agent
> > strings are almost as useful as cookies for tracking their users.
> 
> I cant believe this. Looking at the stats from packages.debian.org - U-A
> is the worst possible way to "track users". Would be totally dumb to try
> something with U-A:

Surely packages.debian.org is not a good example of a site with
generally few Debian users.

The scenario seems more likely to me on small non-technical sites that
only a few Debian unstable users are likely to visit. For special fun,
try browsing from an unusual architecture; that's in the user-agent
string too.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: User-Agent strings, privacy and Debian browsers

[Joerg Jaspert]

On 11150 March 1977, Peter Eckersley wrote:

>> This is highly debateable. There may be tens or thousands of users of
>> the same package visiting a web site.
> I've seen reports from very large sites indicating that User-Agent
> strings are almost as useful as cookies for tracking their users.

I cant believe this. Looking at the stats from packages.debian.org - U-A
is the worst possible way to "track users". Would be totally dumb to try
something with U-A:

Lets take the access log from packages.debian.org which starts at
20/Sep/2007:06:55:10 + which has 2576180 lines in it right now.

Looking for "MSIE 6.0" we have 97961 hits,
with more detail, first 15 rows we get
  13756 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
  12985 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
1.1.4322)
   6252 Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
   6048 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
1.1.4322; .NET CLR 2.0.50727)
   4627 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
   4505 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
2.0.50727)
   3371 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
   2321 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; 
.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
   1724 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
   1335 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
   1309 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; 
.NET CLR 2.0.50727)
   1256 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
2.0.50727; .NET CLR 1.1.4322)
   1235 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
1.1.4322; .NET CLR 2.0.50727; InfoPath.1)
   1196 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
909 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
1.1.4322; InfoPath.1)

which is most of them.

Same for anything matching "Firefox/", has 467789 total hits,
with more detail, first 15 rows we get
  89003 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 
Firefox/2.0.0.6 (Ubuntu-feisty)
  51159 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) 
Gecko/20070914 Firefox/2.0.0.7
  21879 Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 
Firefox/2.0.0.7
  11289 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 
Firefox/2.0.0.3 (Ubuntu-feisty)
  10975 Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.7) Gecko/20070914 
Firefox/2.0.0.7
  10217 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) 
Gecko/20070725 Firefox/2.0.0.6
   8542 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/20061201 
Firefox/2.0.0.6 (Ubuntu-feisty)
   7572 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.7) 
Gecko/20070914 Firefox/2.0.0.7
   6029 Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.7) 
Gecko/20070914 Firefox/2.0.0.7
   5379 Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.7) Gecko/20070914 
Firefox/2.0.0.7
   4885 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/20070914 
Firefox/2.0.0.7
   4859 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) 
Gecko/20070914 Firefox/2.0.0.7
   4606 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070725 
Firefox/2.0.0.6
   4549 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070919 
Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
   4472 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) 
Gecko/20070914 Firefox/2.0.0.7

And thats a quick and very inaccurate way to do it. But it nicely shows
that modifying your UA (or forcing others to do so) does not gain you or
anyone else anything. The only effect you have is to make statistics
more unusable than they already are. Thats not worth to invest the work
this suggestion would need, even if it would only be a simple change. :)


-- 
bye Joerg
>Starting network management services:
>   Warning: -s option is deprecated, use -Lsd instead
Uah. snmpd on drugs.


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

Bug#443619: RFP: epdfview -- ePDFView is a free lightweight PDF document viewer

[esters]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org


   Package name: epdfview
Version: 0.1.6
Upstream Author: Jordi Fita <[EMAIL PROTECTED]>
URL: http://trac.emma-soft.com/epdfview/
License: GPL
Description: ePDFView is a free lightweight PDF document viewer using 
Poppler and GTK+ libraries. The aim of ePDFView is to make a simple PDF 
document viewer, in the lines of Evince but without using the Gnome libraries.


-- 
esters <[EMAIL PROTECTED]>



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

Re: User-Agent strings, privacy and Debian browsers

[Eduardo Trápani]

Consider for a moment a typical User-Agent string sent by a Debian web browser:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 Iceape/1.1.4 
(Debian-1.1.4-1)


I agree that it is a bit too verbose and it might even be a security 
problem, but reaching consensus on what portions of string to strip off 
is not going to be easy.


Maybe there could be a low priority question when installing the 
browser.  The use of phishing could be there too (another privacy 
problem) for iceweasel.


- choose your user agent: Mozilla/5.0 | Mozilla/5.0 (X11; U; Linux) | ...

- do you want to use Google's based phishing detection?  A list of known 
phishing sites will be downloaded from Google every 30 minutes: yes|no


Anyway, as somebody pointed out already, if no nobody else uses shorter 
user-agents, being *the* user with the "Mozilla/5.0" user-agent might be 
even more identiable than being a Debian user on a platform other than 
i386.  But as time goes by more users will have that kind of user-agent, 
I guess.  I would.


Eduardo


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

Re: Rfh: test mdadm 2.6.3-1

[Elimar Riesebieter]

On Sat, 22 Sep 2007 the mental interface of
martin f krafft told:

> Dear list,
> 
> I am ready to upload mdadm 2.6.3-1, but when I installed it on my
> home machine just before I left to Ireland, it failed to boot. I am
> almost sure that this was due to #441211, but I can't be sure.
> Unfortunately, I also had to remove my vmware setup from the laptop
> due to lack of space, so I have no testing environment.
> 
> If any of you are in the position to test mdadm 2.6.3-1, please do
> and report back. Does it boot systems with root on RAID? Does it
> boot other RAID systems? Does it affect systems without RAID?

mdadm - v2.6.3 - 20th August 2007

Booting form an array:

RAID1:

/dev/md3  /boot
/dev/md6  /
/dev/md7  /usr
/dev/md8  /usr/local
/dev/md9  /var

Seems to be ok here ;)

Elimar

-- 
  "Talking much about oneself can also 
   be a means to conceal oneself."
 -Friedrich Nietzsche


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

Re: User-Agent strings, privacy and Debian browsers

[Roberto C . Sánchez]

On Sat, Sep 22, 2007 at 12:39:25PM -0700, Peter Eckersley wrote:
> On Sat, Sep 22, 2007  at 11:36:41 +0100, Mark Brown wrote:
> > 
> > > This means, in practice, that many sites will be able to track
> > > Debian users by their User-Agent, even if (say) the user is blocking
> > > cookies or limiting them to a single session and is changing IP
> > > address regularly.
> > 
> > I would strongly expect that any user sufficiently concerned about
> > these issues to take active steps like those would be willing to use
> > things like either the user agent configuration availialbe one way or
> > another in most browsers or something like privoxy (possibly in
> > conjunction with tor) which will do the same things and more.
> 
> I think this misunderstands the problem.  Having stronger privacy is
> like an insurance policy: most of the people who end up having needed it
> never knew they were going to need it.  So they weren't going to have
> gone out and installed Privoxy (maybe with Tor) /and/ then examined it
> closely enough to realise that it doesn't alter their User-Agent by
> default, and configured it to masquerade as Firefox on Windows or
> something. 
> 
I have a feeling that you misunderstand the problem.

(Bad analogy time).

If you drive a Ford F-150 pickup truck and remove all the Ford badging
(the oval, the F-150 badge, etc), then does that make you any more
anonymous?  If you drive it around town, No.  You still have the same
license plate.  Your truck is still recognizable as a Ford F-150.
Besides that, the people who are interested in tracking you are able to
track you based on other things as well.

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: User-Agent strings, privacy and Debian browsers

[Peter Eckersley]

On Sat, Sep 22, 2007  at 11:36:41 +0100, Mark Brown wrote:
> 
> > This means, in practice, that many sites will be able to track
> > Debian users by their User-Agent, even if (say) the user is blocking
> > cookies or limiting them to a single session and is changing IP
> > address regularly.
> 
> I would strongly expect that any user sufficiently concerned about
> these issues to take active steps like those would be willing to use
> things like either the user agent configuration availialbe one way or
> another in most browsers or something like privoxy (possibly in
> conjunction with tor) which will do the same things and more.

I think this misunderstands the problem.  Having stronger privacy is
like an insurance policy: most of the people who end up having needed it
never knew they were going to need it.  So they weren't going to have
gone out and installed Privoxy (maybe with Tor) /and/ then examined it
closely enough to realise that it doesn't alter their User-Agent by
default, and configured it to masquerade as Firefox on Windows or
something. 

Which brings us to a separate point: it's no use to have Privoxy
configured to block User-Agent strings, since that means you'll be the
one person with no User-Agent, which gives you an even smaller anonymity
sets than the default debian packages.  Yes, smart users will copy
Firefox on Windows, which works -- so long as there isn't one little
thing about their browser which gives away their platform.  Cos then,
they can be identified as the one guy running Iceweasel masquerading as
Firefox on Windows.  Also, plenty of debian users would have 

It really does help to have larger groups of people whose browsers are
behaving the same way by default.  In the case of Privoxy, this would
mean having all of the default Privoxy distributions (and especially
those that are shipped with Tor) use a single User-Agent.  We were also
planing to send those trivial Privoxy configuration patches, it'd be
great if we could get the community to standardise on "Mozilla/5.0
(Privoxy)" or something.

-- 
Peter Eckersley[EMAIL PROTECTED]
Staff TechnologistTel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993


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

Re: User-Agent strings, privacy and Debian browsers

[Peter Eckersley]

On Sep 22, Marco D'Itri <[EMAIL PROTECTED]> wrote:

> On Sep 22, Peter Eckersley <[EMAIL PROTECTED]> wrote:
> 
> > This means, in practice, that many sites will be able to track
> > Debian users by their User-Agent, even if (say) the user is blocking
> > cookies or limiting them to a single session and is changing IP
> > address regularly.
>
> This is highly debateable. There may be tens or thousands of users of
> the same package visiting a web site.

I've seen reports from very large sites indicating that User-Agent
strings are almost as useful as cookies for tracking their users.

> > Would there be any serious harm in terms of browser debugging?  Are
>
> Yes. For no real gain, it would make debugging harder and make
> statistics much less useful.
>
When do you need statistics about how many Debian users are using which
versions of which browser package?

As for debugging, I agree that there's an issue here, which is why I
asked the question.  But some evidence would be useful... does anyone
know any browser or site bugs that have been solved because the site
operator could see the version of a random visiting Debian browser?

--
Peter Eckersley[EMAIL PROTECTED]
Staff TechnologistTel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993


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

Re: User-Agent strings, privacy and Debian browsers

[Peter Eckersley]

Yes and no.  Although IP addresses are a better tracking mechanism than
User-Agent strings, each of them makes the other more effective.  If you
always browse from one IP, and all the other people at that IP use
Windows, then this doesn't help you.  

But maybe you use open wifi networks, and other Debian users also use
those networks.  Maybe there are other Debian users behind your NAT.
Maybe your friends come over sometimes and they also use Debian.  In
those cases, standardising the User-Agent string increases the size of
your anonymity sets for various activities.

On Sep 21, Roberto C. Sánchez <[EMAIL PROTECTED]> wrote:

>
> It would be sort of pointless unless we could find a way to all browse
> from the same IP address.
> 
> Regards,
> 
> -Roberto


-- 
Peter Eckersley[EMAIL PROTECTED]
Staff TechnologistTel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993


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

Rfh: test mdadm 2.6.3-1

[martin f krafft]

Dear list,

I am ready to upload mdadm 2.6.3-1, but when I installed it on my
home machine just before I left to Ireland, it failed to boot. I am
almost sure that this was due to #441211, but I can't be sure.
Unfortunately, I also had to remove my vmware setup from the laptop
due to lack of space, so I have no testing environment.

If any of you are in the position to test mdadm 2.6.3-1, please do
and report back. Does it boot systems with root on RAID? Does it
boot other RAID systems? Does it affect systems without RAID?

It *should* really just work, but I am sure you understand that
I don't simply want to upload.

You can get the package for i386/amd64 from here:
  
http://debian.madduck.net/repo/dists/unstable/main/binary-i386/admin/mdadm_2.6.3-1~unreleased.2_i386.deb
  sha1: fcbd3796e609a5e6bf1b5f1cfea373ad78feb136, size: 248524
  
http://debian.madduck.net/repo/dists/unstable/main/binary-amd64/admin/mdadm_2.6.3-1~unreleased.2_amd64.deb
  sha1: 0de12bccf04290939d52a3022aa20b22a6387e7a, size: 249664

Or the source:
  
http://debian.madduck.net/repo/dists/unstable/main/source/admin/mdadm_2.6.3-1~unreleased.2.dsc

I appreciate your help!

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"by accepting this brick through your window, you accept it as is
 and agree to my disclaimer of all warranties, express or implied,
 as well as disclaimers of all liability, direct, indirect,
 consequential or incidental, that may arise from the installation
 of this brick into your building." -- seen on irc


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms

[Daniel Baumann]

Thomas Goirand wrote:
> Does it mean that I should try and make it work with xmms2 instead,
> which means open an ITP for xmms2-pulse?

Hi Thomas,

please don't upload any xmms packages anymore; but go for xmm2 or
audacious (unless you want to take over xmms itself).

Regards,
Daniel

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: modified email address in debian/copyright file

[Joerg Jaspert]

On 11150 March 1977, Marc Haber wrote:

>>Same goes for those idiots with
>>"[EMAIL PROTECTED]" addresses.
> Using a plus sign in the mail address is a _very_ _very_ effective
> spam filter.

I dont care about the +. Thats not my point, im using such addresses myself.

-- 
bye Joerg
 SCSI benötigt drei Terminierungen, eine am einen Ende, eine
am anderen Ende, und das Leben einer Ziege über einer schwarzen Kerze


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

Re: Some questions about Debian

[Raphael Hertzog]

Hi,

On Sat, 22 Sep 2007, martin f krafft wrote:
> > How many "pieces of software" do you have in your distribution? Do you
> > distinguish between "source packages" and "binary packages"? (if yes,
> > give numbers for both). Are there subdivisions in the set of packages (by
> > kind of support, by "freeness")? Are all packages supported the same way,
> > or are there different levels of support? (If different levels, how many
> > packages are supported with each level?) Are some packages imported from
> > another distribution, or are most of your packages done from scratch by
> > your developers ?
> 
> I'd say we currently have around 1 source packages and around
> 18000 binary packages, most of which run on each of the 11
> architectures we support. We separate our packages according to
> freeness, distinguishing between free, non-free, and those packages
> that are free themselves but require non-free stuff to run. In
> general, you can expect the more free packages to get more support.

"main" (free) contains 11659 source packages currently,
and "non-free" 246, while contrib has 166 source packages.

Debian is only the "main" section. The other sections are a courtesy
provided to our users according to point 5 of our social contract
(http://www.debian.org/social_contract).

Packages in contrib, non-free can be very well supported by their
maintainers, but they have several drawbacks over main packages such
as no official security support (but updates are possible if the
maintainer preprares them, but the security team won't do anything by
themselves). They also aren't autobuilt by the main buildd but the team
that autobuild our experimental packages has decided to support non-free
packages as well when it was possible.

> Most of our packages are done from scratch by our developers,
> although we do get occasional contributions from other distros, such
> as Knoppix or Ubuntu.

It's more and more common that packages have been created for Ubuntu
in the first place. In many cases, their work is largely reused but
it's not automatic. The Debian maintainer can have different opinions
on the packaging tools to use...

We try to push co-maintenance between Debian and Ubuntu in those cases
because the work done for Ubuntu is better done inside Debian itself
since it will automatically end up in Ubuntu.

> > Q2. Your developers
> > What's a "developer" in your distribution? How many developers do you
> > have? How many of these developers were active in 2007? Does a company
> > (which one?) employ a large number of developers? Do you have different
> > "classes" of developers, or does everybody have the same access right to
> > all your packages? How do you integrate new developers? How do you
> > handle contributors who don't have access rights to the archive? (is
> > there some kind of mentoring/sponsoring system?)
> 
> A developer with Debian can upload packages, vote in project
> matters, and participate in private discussions, which are mostly
> for housekeeping; we try to keep technical stuff from them. We have
> about 1300 developers (I think), and I'd say no more than 400 of
> those are active.

The biggest elections tend to get between 500 and 600 voters. So I
expect that we have at least 600 people who are "active" at least once in
a year. The number of very regular contributor following many mailing
lists and which are always on IRC is way smaller of course, I'd say around
100 (that's the number of people who vote in the first day of any
election, so they are most likely following Debian every day).

> We do not really integrate new developers but rather expect them to
> integrate themselves by doing work and rising on the meritocratic
> scale. 

We expect every "applicant" (that's how we name people who want to become
Debian developer) to have contributed for at least 6 months even before
registering in our "New maintainer process".

Check out the doc on http://nm.debian.org if you want to learn more about
this.

It's not that difficult to contribute "before" because we have more and
more teams using resources such as alioth.debian.org where DD and non-DD
can collaborate easily. If you still package something alone, you can
usually find a sponsor on our [EMAIL PROTECTED] mailing list.

> > Q3. Developers and packages ownership
> > What's the relationship between developers and packages? Does each
> > package have an assigned developer, or can everybody modify all packages
> > without stepping on anyone's toes? Are packages mostly maintained by
> > teams, or by developers working alone?
> 
> Classically, in Debian every package is maintained by one developer,
> although more and more packages are being team-maintained now, but
> still not enough: we still have more single-maintained packages.
> A maintainer is simply the official point of contact and
> theoretically the only one who can make official uploads.

We do have a process for "Non-maintainer uploads" (NMU) which requires to
try to coord

Re: Some questions about Debian

[martin f krafft]

also sprach Lucas Nussbaum <[EMAIL PROTECTED]> [2007.09.21.0619 +0100]:
> I'm involved both in Debian and Ubuntu development, and I'm often
> frustrated by how little I know about the other distributions.
> After discussing this in a blog post[1], I got the impression that
> I wasn't alone in that case.

You say it right there: you're frustrated how little you know about
the "other" distributions, and yet in [0] you "complain" that we're
not bothering to reply.

0. http://www.lucas-nussbaum.net/blog/?p=252

Basically, you can answer all these yourself, but you say you want
someone else to do it. Well then, looking at the questions, all
I can say is that it's quite clear from them that you're of Debian
origin, so I expect to say 'yes' most of the time. Here we go:

> How many "pieces of software" do you have in your distribution? Do you
> distinguish between "source packages" and "binary packages"? (if yes,
> give numbers for both). Are there subdivisions in the set of packages (by
> kind of support, by "freeness")? Are all packages supported the same way,
> or are there different levels of support? (If different levels, how many
> packages are supported with each level?) Are some packages imported from
> another distribution, or are most of your packages done from scratch by
> your developers ?

I'd say we currently have around 1 source packages and around
18000 binary packages, most of which run on each of the 11
architectures we support. We separate our packages according to
freeness, distinguishing between free, non-free, and those packages
that are free themselves but require non-free stuff to run. In
general, you can expect the more free packages to get more support.
Most of our packages are done from scratch by our developers,
although we do get occasional contributions from other distros, such
as Knoppix or Ubuntu.

> Q2. Your developers
> What's a "developer" in your distribution? How many developers do you
> have? How many of these developers were active in 2007? Does a company
> (which one?) employ a large number of developers? Do you have different
> "classes" of developers, or does everybody have the same access right to
> all your packages? How do you integrate new developers? How do you
> handle contributors who don't have access rights to the archive? (is
> there some kind of mentoring/sponsoring system?)

A developer with Debian can upload packages, vote in project
matters, and participate in private discussions, which are mostly
for housekeeping; we try to keep technical stuff from them. We have
about 1300 developers (I think), and I'd say no more than 400 of
those are active. We used to have only a single status of developer,
but are soon going to get "contributors" as well, who can upload
their own packages themselves. We also have mentors (for advising)
and sponsors (for uploading), as you suggest in the question.

We do not really integrate new developers but rather expect them to
integrate themselves by doing work and rising on the meritocratic
scale. That said, there are quite a number of developers out there
interested in helping newcomers, and forums such as debian-mentors
and debian-women, who make it easier for newcomers to get answers to
less challenging technical questions, without being flamed.

There are several companies employing larger numbers of our
employees, such as Hewlett-Packard, and possibly Canonical, although
their employees aren't allowed to develop Debian during company
time.

> Q3. Developers and packages ownership
> What's the relationship between developers and packages? Does each
> package have an assigned developer, or can everybody modify all packages
> without stepping on anyone's toes? Are packages mostly maintained by
> teams, or by developers working alone?

Classically, in Debian every package is maintained by one developer,
although more and more packages are being team-maintained now, but
still not enough: we still have more single-maintained packages.
A maintainer is simply the official point of contact and
theoretically the only one who can make official uploads. However,
any other developer can upload packages according to a soft set of
rules. Some packages are maintained in version control systems and
it depends on each case whether other developers can commit or not.

> Other questions:
> - Did I send that mail to the right mailing list?

I would have said [EMAIL PROTECTED]
[EMAIL PROTECTED] may have been another.

> - Which question should I have asked? What should I ask next?

For each:
  - why is the project doing it that way
  - what would (you like) it (to) do instead, if it could freely change?
  - compare to the way another distro does it: what are the
advantages of your method?
  - compare to the way another distro does it: what are the
disadvantages of your method?

> - Do you think that this initiative is interesting?

It's interesting, alright. I am not sure whether it'll be fruitful.
Or rather, I am not sure who the targ

Re: modified email address in debian/copyright file

[Marc Haber]

On Thu, 20 Sep 2007 09:02:34 +0200, Joerg Jaspert <[EMAIL PROTECTED]>
wrote:
>You mean the foo at bar dot com value isnt parseable? I dont think it
>has any value to encode an address like this, as any little spambot can
>EASILY decode that.

Agreed.

>Same goes for those idiots with
>"[EMAIL PROTECTED]" addresses.

Using a plus sign in the mail address is a _very_ _very_ effective
spam filter.

|$ grep '<[EMAIL PROTECTED]>' /var/log/exim4/mainlog-20070920 | wc -l
|70
|$ grep '<[EMAIL PROTECTED]>' /var/log/exim4/mainlog-20070920 | wc -l
|77
|$ grep '<[EMAIL PROTECTED]>' /var/log/exim4/mainlog-20070920 | wc -l
|44
|$ grep '<[EMAIL PROTECTED]>' /var/log/exim4/mainlog-20070920 | wc -l
|81
|$

The number of messages _with_ mh+ prefix includes legitimate mail; the
messages to addresses with mh+ stripped off are all spam, rejectable
at SMTP RCPT time ("no such user").

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: User-Agent strings, privacy and Debian browsers

[Mark Brown]

On Fri, Sep 21, 2007 at 06:03:05PM -0700, Peter Eckersley wrote:

> This means, in practice, that many sites will be able to track Debian
> users by their User-Agent, even if (say) the user is blocking cookies or
> limiting them to a single session and is changing IP address regularly.

I would strongly expect that any user sufficiently concerned about these
issues to take active steps like those would be willing to use things
like either the user agent configuration availialbe one way or another
in most browsers or something like privoxy (possibly in conjunction with
tor) which will do the same things and more.

> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?

I don't personally think it's worth it.

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


signature.asc
Description: Digital signature

Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler

[Steinar H. Gunderson]

On Fri, Sep 21, 2007 at 09:44:04AM +1245, Andreas Fleckl wrote:
> It features the smallest possible size and memory requirements, the fastest
> speed, and offers fairly good functionality.

Size and memory aside, I sort of doubt asmutils' sort is faster than
coreutils' sort just because it's written in assembly.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Bug#443548: ITP: paperkey -- extract just the secret information out ouf OpenPGP secret keys

[Peter Palfrader]

Package: wnpp
Owner: Peter Palfrader <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: paperkey
  Version : 0.5
  Upstream Author : David Shaw
* URL : http://www.jabberwocky.com/software/paperkey/
* License : GPL
  Programming Lang: C
  Description : extract just the secret information out ouf OpenPGP secret 
keys

A reasonable way to achieve a long term backup of OpenPGP (GnuPG, PGP,
etc) keys is to print them out on paper.  The reasoning behind this is
that paper and ink has amazingly long retention qualities - far longer
than the magnetic or optical means that are generally used to back up
computer data.

Due to metadata and redundancy, OpenPGP secret keys are significantly
larger than just the "secret bits".  In fact, the secret key contains
a complete copy of the public key.  Since the public key generally
doesn't need to be escrowed (most people have many copies of it on
various keyservers, web pages, etc), only extracting the secret parts
can be a real advantage.

Paperkey extracts just those secret bytes and prints them.  To
reconstruct, you re-enter those bytes (whether by hand or via OCR) and
paperkey can use them to transform your existing public key into a
secret key.




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

Re: Proposal regarding future packaging

[Bruce Sass]

On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote:
> 21-09-2007, Bruce Sass:
> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote:
> >> 19-09-2007, Bruce Sass:
> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has
> >> > been working on will help solve that wart though.
> >>
> >> How exactly?
> >
> > Exactly? I don't know. I haven't followed what is happening close
> > enough.
> >
> > Basically, it allows a package to toss up a flag saying, `I'm here
> > and  needs to be done.' It may require some convention
> > and a little more infrastructure, but that is close to letting a
> > package say, `add these paths to the list of paths which I
> > control.'
>
> Sure. But i thought, we are talking about finding/listing of
> generated files.

It is not feasible (imo) to automatically find files created by 
maintainer scripts. Having packages append .list themselves 
would (afaict) require they know too much about dpkg's internal 
operation, and all packages generating files would need to implement 
the algorithm.

However, maintainer scripts can easily pass a list of generated paths on 
to a shared piece of code which dpkg controls. "triggers" looks like it 
could be the mechanism by which a package flags that it has generated 
files, and by which dpkg exerts control.


- Bruce


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

Re: User-Agent strings, privacy and Debian browsers

[Osamu Aoki]

Hi,

I think one technical solution which seems o be good to one person may
not be good one for others.

You must think realistic solution which do not affect others in any
negative way and possibly give more benefits than just solving your own
corner case problem.

On Fri, Sep 21, 2007 at 06:03:05PM -0700, Peter Eckersley wrote:
> Consider for a moment a typical User-Agent string sent by a Debian web 
> browser:
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 
> Iceape/1.1.4 (Debian-1.1.4-1)
> 
> Unfortunately, the fact that this information identifies a specific
> package and version of that package means that Debian users (already a
> select group) have their browsing identities further distinguished by
> their User-Agent strings.

If you consider this being unfortunate, it must be so for you.
Although I feel different, I understand you care this.

> This means, in practice, that many sites will be able to track Debian
> users by their User-Agent, even if (say) the user is blocking cookies or
> limiting them to a single session and is changing IP address regularly.
> 
> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?

Why you force your own needs to others who do not need this feature?
You may be the only Debian user in the IP range, then your risk exposure
in your sense is still higher.

> Would there be any serious harm in terms of browser debugging?  Are
> there many sites which usefully treat different Gecko browsers
> differently?
> 
> As a far more hypothetical question, what would people think of picking
> a single User-Agent for Gecko-based browsers for a larger set of
> GNU/Linux distributions?  Obviously, there is much more politics there,
> because any distributions that joined would be losing the ability to
> measure their desktop market share by looking at web statistics.

What you need is some kind of optional browser plug-in program which
will let you select User-Agent string. 

I know some web site only accept some OS or browser.  So ability to
masqarade your system will let you access those site pretending to be
different User-Agent/OS :-)  That will have not benefit just security
ultraconcious like you but also have real practical advantage.

> Peter Eckersley[EMAIL PROTECTED]
> Staff TechnologistTel  +1 415 436 9333 x131

Please think about creating such plug-in :-)

(Hmmm... there may already exist such plug-in...)

 http://chrispederick.com/work/user-agent-switcher/

Also there is good list of strings to chose from.

 http://www.testingreflections.com/node/view/5125

There seems to be problem installing to the Debian:
 
http://forums.debian.net/viewtopic.php?p=19231&sid=beb199fd158d6235839dfc0676b9e6cf

Maybe, you can work with maintainer of packages to pre-include this
user-agent-switcher in the Debian distribution since this is GPL2.

Osamu


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

Re: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms

[Thomas Goirand]

Thomas Viehmann wrote:
> Hi,
> 
> Thomas GOIRAND wrote:
>>   Description : Pulseaudio output plugin for xmms
> 
> Last I heard the xmms maintainers asked for input on removing xmms and
> how to deal with the plugins already in the archive...
> 
> Kind regards
> 
> T.

Does it mean that I should try and make it work with xmms2 instead,
which means open an ITP for xmms2-pulse?

Thomas


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

Re: [RFH] Implementing "Homepage:" field support in lintian/linda

[Faidon Liambotis]

Christian Perrier wrote:
> The latter should probably be quite conservative and only detect
> something like:
> 
> "^ +[Hh]ome *[Pp]age:.*"
> 
> in the package description.
/^\s+(web|home)\s*(site|page)\s*(:| at| is).*/i
seems to catch more (5087 hits) with few false positives.

Also, matching http:// would catch even more but with many false
positives so I'm not sure if it's a good idea.

Regards,
Faidon


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

Re: [RFH] Implementing "Homepage:" field support in lintian/linda

[Christian Perrier]

Quoting Faidon Liambotis ([EMAIL PROTECTED]):
> Christian Perrier wrote:
> > The latter should probably be quite conservative and only detect
> > something like:
> > 
> > "^ +[Hh]ome *[Pp]age:.*"
> > 
> > in the package description.
> /^ (web|home)( *)?(site|page) *(:| at| is).*/i
> seems to catch more (1905 hits)


and no false positives? (that was the point of my 'be quite
conservative' comment)




signature.asc
Description: Digital signature

Re: [RFH] Implementing "Homepage:" field support in lintian/linda

[Faidon Liambotis]

Christian Perrier wrote:
> The latter should probably be quite conservative and only detect
> something like:
> 
> "^ +[Hh]ome *[Pp]age:.*"
> 
> in the package description.
/^ (web|home)( *)?(site|page) *(:| at| is).*/i
seems to catch more (1905 hits)

Regards,
Faidon


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

Re: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms

[Sjoerd Simons]

On Sat, Sep 22, 2007 at 10:13:17AM +0200, Thomas Viehmann wrote:
> Hi,
> 
> Thomas GOIRAND wrote:
> >   Description : Pulseaudio output plugin for xmms
> 
> Last I heard the xmms maintainers asked for input on removing xmms and
> how to deal with the plugins already in the archive...

We already packaged xmms-pulse as part of pkg-pulseaudio. But never uploaded it
for exactly this reason. It doesn't seem very usefull to upload it just so it
can be removed a few months later.

You can find our packaging at
  http://svn.debian.org/wsvn/pkg-pulseaudio/xmms-pulse/

Ofcourse always feel free to join pkg-pulseaudio if you want to
package/maintain pulse related things :)..

  Sjoerd
-- 
Freedom is what you do with what's been done to you.
-- Jean-Paul Sartre


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

using "Breaks:", or how to replace it?

[Lucas Nussbaum]

Hi,

I maintain two packages:
T, in Debian with version 3.2.5-1
K, in Debian with version 1.0.2-1

The upstream developer for both apps recently released T 3.3 and K 1.1.
Problem is:
K 1.1 requires T 3.3
T 3.3 breaks K << 1.1

Avoiding the case where K 1.1 gets installed with T 3.2.5 is easy (using
a Depends).

However, what's the best way to avoid the case where K 1.0.2 gets
installed with T 3.3 ?

* dpkg and apt have support for Breaks in lenny, but this doesn't mean
  that we are supposed to use it before lenny+1 (according to
  #debian-devel)

* I could use a Conflicts in T, on K << 1.1. Policy says: (sect 7.3)

A Conflicts entry should almost never have an "earlier than" version
clause. This would prevent dpkg from upgrading or installing the
package which declared such a conflict until the upgrade or removal
of the conflicted-with package had been completed.
  
  But that seems OK in my case?

* I could add a check in postinst, but thhat seems dirty/overkill

* I could just do nothing
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: [RFH] Implementing "Homepage:" field support in lintian/linda

[Paul Wise]

On 9/22/07, Christian Perrier <[EMAIL PROTECTED]> wrote:

> Could some knowledgeable people propose some possible patches? I can
> coordinate that stuff, but proposing patches is better left to Those
> Who Know...

I offered to update the lintian patch I submitted years ago for
checking for a proper Homepage psuedo-field to a check for the new
Homepage field, Russ said policy/devref should be updated first.
Personally, I think updating everything at the same time is the right
order. Anyways, I'll work on the patch so it is ready for when lintian
will accept it.

Also: I think a debtags-like system (stored/maintained separately to
the packages and merged into the Sources/Packages files behind the
scenes) is more appropriate for homepages, since they can change
independently from a package and also it doesn't take much skill to
add them, so an army of users could add homepages to all those
packages that the maintainer won't be uploading just to add a homepage
or where the maintainer won't bother to add one.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms

[Thomas Viehmann]

Hi,

Thomas GOIRAND wrote:
>   Description : Pulseaudio output plugin for xmms

Last I heard the xmms maintainers asked for input on removing xmms and
how to deal with the plugins already in the archive...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

[RFH] Implementing "Homepage:" field support in lintian/linda

[Christian Perrier]

Changes to lintian/linda are often mentioned in that discussion.

Roughly speaking, we need these tools to:

- no longer complain about "Homepage:" being an unknown field
- warn people currently using the trick of mentioning the Home Page in
the package's description and suggest them to move this to the new
field



The latter should probably be quite conservative and only detect
something like:

"^ +[Hh]ome *[Pp]age:.*"

in the package description.

I would like to have something ready for lintian and linda so that it
could be proposed to their respective maintainer when it's time to do
so.

Could some knowledgeable people propose some possible patches? I can
coordinate that stuff, but proposing patches is better left to Those
Who Know...




signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christian Perrier]

Quoting Manoj Srivastava ([EMAIL PROTECTED]):

> Right. These are staid, old, boring, unchanging fields; and
>  maintainers need not expect these to change; and putting them in policy
>  means that even dpkg can't change the fields drastically  fro under the
>  developers.
> 
> However, policy is not exhaustive; and if policy says nothing on
>  a topic, it means the topic is permitted, not prohibited; so the
>  Homepage: field can be used by any package without the package falling
>  foul of policy.

OK. I am not very strongly pushing the idea of documenting first in
the policy. This was just about exploring the various possibilities.

I keep you comment about the proposed changes to the policy being
roughly OK. I added them to the wiki page but kept those policy
changes coming after other changes such as APT frontends
implementation, devref update, dh-make and lintian/linda stuff.


> So, while I will not prevent you from going the route you
>  proposed, if you feel it is the right thing to do, I would still advice
>  caution. Having said that, I am not sure what changes might be needed
>  for home page fields (is there a concept like ultiple homepages?), but


It seems that very few packages currently use multiple URLs in the
pseudo-field in the package's description. 

So we could maybe allow that field to be multi-valued...




signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Manoj Srivastava]

On Sat, 22 Sep 2007 08:56:29 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

> Quoting Manoj Srivastava ([EMAIL PROTECTED]):
>> Actually, policy is usually the last thing that you want to do, in
>> the general case.  Policy is usually stable (well, not quite as
>> stable as it has been this year, but work seems to be easing up a
>> trifle, so expect a policy release in a couple of weeks).
>> 
>> But the idea is that policy documents mature practice, and only when
>> it is deemed really required.  Since so few packages do the Homepage
>> thing, I would much rather see a working design, supported by apt and
>> p.d.o, make any changes or tweaks as are needed; and _then_ we look
>> at policy.  If very few packages are using it still, you'll have to
>> start with a MAY or suggests, anyway.

> That was my initial idea: have the policy document after the practice
> became common practice as I remember that you (Manoj, but also often
> aj) often remind that the Policy is more about documenting common
> practice and turning it into 'rules' thanestablishing rules before
> they're really used.

> However, re-reading the part that describes debian/control fields in
> the policy, I noticed that they're describe in the *policy* and not in
> the DevRef.

Right. These are staid, old, boring, unchanging fields; and
 maintainers need not expect these to change; and putting them in policy
 means that even dpkg can't change the fields drastically  fro under the
 developers.

However, policy is not exhaustive; and if policy says nothing on
 a topic, it means the topic is permitted, not prohibited; so the
 Homepage: field can be used by any package without the package falling
 foul of policy.

> So, my thought when I proposed to begin with the policy was to have it
> describe that field without making it mandatory (MAY requirement, not
> MUST requirement) so that lintian/linda can point developers to it
> when issuing a warning for the missing field.

> So I roughly propose to:

> - Add an item to "5.3 Binary package control files -- DEBIAN/control":
>   - Homepage
>   (note the missing "mandatory")

> - Add a level 3 section to 5.6 List of fields: 5.6.x Homepage
> The upstream project home page URL. It should preferably contain and
> http(s) URL linking to a page describing the upstream project with
> access to the project's resources. This is an optional field

This looks like a sound addition to policy.  Have you given any
 thought to a lintian/linda check? (make sure it is a legal URI,
 optionally check to see if it is a valid URL pointing to a real web
 page, etc). Yes, I am still trying to thing about machine readable
 policy documents :)

> Would this better field for an early integration in the policy or do
> you still recommend that it comes after implementation in aptish tools
> and adoption by "enough" packages (probably following integration in
> lintian/linda)?

Well. When it comes to policy, I am very conservative (I am
 still smarting from the /usr/doc transition fiasco).  Remember the
 X-SVN: field? After we thought it was all decided, arch came up, and we
 split the single field into a browser and a repo field; and that came
 only after it was implemented, people started using it, and other folks
 (arch users, like me) came up with suggestions an changes, and the
 fields were changed.

It would have been much harder to do so if we had to wait for
 policy to change. (I know, I know. Slow policy changes are at least
 partially my fault).

So, while I will not prevent you from going the route you
 proposed, if you feel it is the right thing to do, I would still advice
 caution. Having said that, I am not sure what changes might be needed
 for home page fields (is there a concept like ultiple homepages?), but
 I have often found that people have far more imagination than I have.

manoj
-- 
"It's what you learn after you know it all that counts." John Wooden
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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