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

[Christoph Haas]

On Thu, Sep 20, 2007 at 07:05:04AM +0200, Christian Perrier wrote:
> A recent discussion back in August, in -devel, showed that the current
> common trick of using a "Homepage:" pseudo-field in binary packages'
> descriptions is not really optimal.

Indeed. It's formally specified to be used in the description field. So
IMO it definitely belongs into the group control fields instead.
In the worst case I have to get the package and read debian/copyright to
find out where about the upstream's home page.

> In the discussion, it was pointed that dpkg, as of 1.14.6, supports
> the use of a "Homepage:" field in debian/control.
> 
> As a consequence, it seems logical to promote the use of that field
> and recommend abandoning "Homepage" paragraphs in packages'
> description.
> 
> As, in the Smith review project conducted on debian-l10n-english, we
> review packages' descriptions, we would like to get more input about
> recommending the use of that new field from now.
> 
> Are there any reasons *not* to do so (such as other tools that would be
> broken or the like)?

I couldn't think of any.

> Of course, a mass bug-filing could also later happen but that would
> probably be a *huge* bug filing which should be avoided now. Entering
> a transition period where all communication media towards develpers
> are used to suggest switching to the use of this field would be more
> appropriate.

Unless there are any reasons not to use the field someone (tm) should
announce it on debian-devel-announce. Perhaps some time later a mass bug
filing could be done with a "minor" priority.

Having the field easily parseable would definitely make my life easier.
E.g. sponsors could be pointed to the upstream's home page from
mentors.debian.net so they quickly see in advance what application they
are considering to sponsor.

Cheers
 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


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

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

[Lars Wirzenius]

to, 2007-09-20 kello 07:05 +0200, Christian Perrier kirjoitti:
> Of course, a mass bug-filing could also later happen but that would
> probably be a *huge* bug filing which should be avoided now. Entering
> a transition period where all communication media towards develpers
> are used to suggest switching to the use of this field would be more
> appropriate.
> 
> Of course, documents such as the Developer's Reference wuold then need
> to be adapted.

I'd start with amending the Developers' Reference, then having a test
added to lintian and linda, and after that announcing it on
debian-devel-announce. Then next year, after everyone's had time to
react and upload new packages, do a mass bug filing.

-- 
It's 1978! Things should be round by now -- Michael Kelso (That 70's
show)


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

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

[Michal Čihař]

Hi

On Thu, 20 Sep 2007 07:05:04 +0200
Christian Perrier <[EMAIL PROTECTED]> wrote:

> As a consequence, it seems logical to promote the use of that field
> and recommend abandoning "Homepage" paragraphs in packages'
> description.
> 
> As, in the Smith review project conducted on debian-l10n-english, we
> review packages' descriptions, we would like to get more input about
> recommending the use of that new field from now.
> 
> Are there any reasons *not* to do so (such as other tools that would be
> broken or the like)?

Well I started to use this field in some my packages, but I see few
problems:

1. Policy does not cover this field, you will also get "I:
unknown-field-in-control homepage" from lintian.

2. packages.debian.org/aptitude/other tools does not support this field.
This means that moving Homepage from description to separate field for
now means that no user will be able to see it.

These are definitely not a showstoppers, but I think that they should
be resolved first before pushing Homepage field to be used.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

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

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 09:57:44AM +0200, Christoph Haas wrote:
> > Of course, a mass bug-filing could also later happen but that would
> > probably be a *huge* bug filing which should be avoided now. Entering
> > a transition period where all communication media towards develpers
> > are used to suggest switching to the use of this field would be more
> > appropriate.
> Unless there are any reasons not to use the field someone (tm) should
> announce it on debian-devel-announce. Perhaps some time later a mass bug
> filing could be done with a "minor" priority.

Agreed, I would welcome the mass bug filing and I would love to see my
packages bugged so that to have a roadmap of which need to be fixed.

Still, out of curiosity, how do you guys plan to do the mass bug filing?
To me it doesn't seem easy to implement. The naive solution of bugging
all package without a Homepage field will not work because not all
package probably have an Homepage; I agree that the false negatives
would be only a few, but that's not a valid reason for bugging
non-bugged packages.

Other ideas?

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

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

[Andreas Tille]

On Thu, 20 Sep 2007, Stefano Zacchiroli wrote:


To me it doesn't seem easy to implement. The naive solution of bugging
all package without a Homepage field will not work because not all
package probably have an Homepage; I agree that the false negatives
would be only a few, but that's not a valid reason for bugging
non-bugged packages.

Other ideas?


Bugging those packages that contain an url in the description first?
Perhaps grepping debian/copyright for potential homepage strings?

Kind regards

   Andreas.

--
http://fam-tille.de


--
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 11148 March 1977, Ben Finney wrote:

>> Recently, perhaps mainly due to so many spams, it looks common to
>> write email address like "foo at some.where" etc. and I wonder if it
>> is acceptable to use such modified email address in Upstream Author
>> field of debian/copyright file.
> IANADD, but would argue that making the copyright file, including any
> email addresses, machine-parseable is a worthwhile goal. This goal
> precludes munging the address.

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.
Same goes for those idiots with
"[EMAIL PROTECTED]" addresses.


-- 
bye Joerg
 and yes, the ftpmasters are not the most clueful people


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

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

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 10:49:17AM +0200, Andreas Tille wrote:
> Bugging those packages that contain an url in the description first?
> Perhaps grepping debian/copyright for potential homepage strings?

Ah, ok, so probably the initial proposal was to file bugs against
packages using the pseudo Homepage field in the description, asking the
maintainers to convert it in the new one. That's of course trivial (and
still welcome). I was thinking about how to bug packages to actually
include an Homepage field where is actually missing ...

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

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

[Andreas Tille]

On Thu, 20 Sep 2007, Stefano Zacchiroli wrote:


Ah, ok, so probably the initial proposal was to file bugs against
packages using the pseudo Homepage field in the description, asking the
maintainers to convert it in the new one.


No I think you did understand the initial proposal right, but I was
suggesting how we might more or less prevent false positives (while
missing all those that have no homepage mentioned at all).  My idea
also extends to those that do not use the string "homepage" or
"URL" in their control file but also list *any* URL in free text
in their description which is not inconvient and might have good
chances to be a link to the real home page.


That's of course trivial (and
still welcome). I was thinking about how to bug packages to actually
include an Homepage field where is actually missing ...


Moreover I said that we might be able to parse debian/copyright for
potential homepage strings.

Kind regards

 Andreas.

--
http://fam-tille.de


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

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

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 11:22:14AM +0200, Andreas Tille wrote:
> Moreover I said that we might be able to parse debian/copyright for
> potential homepage strings.

Yep, I got that, sorry for not replying on it.

But this does not seem really feasible to me: in debian/copyright you
almost always have some URL (at least in packages generated in the last
5(?) years with dh_make), but it's hard to tell if it's a homepage
rather than an apache directory listing or some version control system
or something like that ..

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: modified email address in debian/copyright file

[Ben Finney]

Please don't email copies of list messages unless explicitly requested.
http://www.debian.org/MailingLists/#codeofconduct>

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> On 11148 March 1977, Ben Finney wrote:
> > IANADD, but would argue that making the copyright file, including
> > any email addresses, machine-parseable is a worthwhile goal. This
> > goal precludes munging the address.
> 
> You mean the foo at bar dot com value isnt parseable?

That form isn't the only way email addresses get munged. The line
needs to be drawn somewhere; I would argue "valid RFC2821 email
address" is the place to draw it.

> I dont think it has any value to encode an address like this, as any
> little spambot can EASILY decode that.

Agreed. I would not be against a policy requirement that email
addresses in package metadata should be the literal address without
munging.

-- 
 \   "If [a technology company] has confidence in their future |
  `\  ability to innovate, the importance they place on protecting |
_o__)  their past innovations really should decline."  -- Gary Barnett |
Ben Finney


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

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

[Luca Capello]

Hello!

On Thu, 20 Sep 2007 10:31:31 +0200, Michal Čihař wrote:
> On Thu, 20 Sep 2007 07:05:04 +0200 Christian Perrier <[EMAIL PROTECTED]> 
> wrote:
>> As a consequence, it seems logical to promote the use of that field
>> and recommend abandoning "Homepage" paragraphs in packages'
>> description.
>
> Well I started to use this field in some my packages, but I see few
> problems:
>
> 1. Policy does not cover this field, you will also get "I:
> unknown-field-in-control homepage" from lintian.

This is a minor warning.

> 2. packages.debian.org/aptitude/other tools does not support this
> field.  This means that moving Homepage from description to separate
> field for now means that no user will be able to see it.

This is strange: the Homepage field is shown for some packages [1] and
not for others [2], e.g. reported below:
=
[EMAIL PROTECTED]:~$ apt-cache show ikiwiki | grep "^Homepage"
Homepage: http://ikiwiki.info/

[EMAIL PROTECTED]:~$ apt-cache show deb-gview | grep "^Homepage"
Homepage: http://dpkg-view.alioth.debian.org/

[EMAIL PROTECTED]:~$ 
=

FWIW, the number of source packages implementing the Homepage: field
is still very very low:
=
[EMAIL PROTECTED]:~$ wget 
http://ftp.ch.debian.org/debian/dists/sid/main/source/Sources.gz
[EMAIL PROTECTED]:~$ zgrep -c "^Package" Sources.gz
11659
[EMAIL PROTECTED]:~$ zgrep -c "^Homepage" Sources.gz
20
[EMAIL PROTECTED]:~$
=

/me goes to move the homepage from Description: to Homepage: for his
packages...

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://packages.debian.org/sid/ikiwiki
[2] http://packages.debian.org/sid/deb-gview


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

Re: Packages with RFCs deleted

[Anthony Towns]

On Thu, Sep 20, 2007 at 09:46:47AM +0900, Charles Plessy wrote:
> Le Wed, Sep 19, 2007 at 01:08:40AM +1000, Anthony Towns a ?crit :
> > For what it's worth, we don't do that. References I'm aware of:
> > http://lists.debian.org/debian-legal/2003/05/msg00092.html
> > http://lists.debian.org/debian-legal/2003/05/msg00149.html
> Hi Anthony,
> thank for the links. So in the end, am I right to say that, since the
> point of view of the FTP team is that RFC are software, orig.tar.gz
> files which contain them fail to comply the DFSG and therefore are not
> accepted in main?

It's not my POV that RFCs are "software", no :) 

It is the POV of ftpmaster that everything in main, whether it be a .deb,
.tar.gz or .diff.gz needs to meet the DFSG though.

As you can probably tell from the second link above, I'm not personally
very invested in having .orig.tar.gz's be pristine versus removing
unused non-free stuff from them, but the position we've taken in the
past has been to insist on it being removed, and I think it's worth
being consistent.

Cheers,
aj



signature.asc
Description: Digital signature

Novedades de escorts en Argentina

[Novedades de Escorts]

Hola en los siguientes links tenes un listado de las mejores escorts argentinas

Escorts Independientes: http://www.directoriodeescort.com.ar/01reco-inde.html
Escorts Recomendadas: http://www.directoriodeescort.com.ar/02reco-dep1.html

Escorts Vip: http://www.lasmejoresescorts.com/1/index50.html
Escorts Vip: http://www.paraisoterrenal.com.ar/sala.htm



Saludos!!!

Become employed today in a respectable international company and reach the financial success. (no investment reqired)

[dougie hamid]

Big international commercial organization is seeking of talented, honest, 
reliable representatives in different regions. Because of developing of our 
business the organization is proposing to you to become its part. You can work 
part time or full time.
Requirements: 
Internet Connection 
Basic knowledge of PC 
Honesty 
Reliability

Basic knowledge of marketing is a plus.
If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: [EMAIL PROTECTED] 
1) Full name 
2) Contact phone numbers
3) Languages 
4) Part time job/Full time
No investments needed to start working with us. 
The preference is given to employees with knowledge of foreign languages.

Thank you and we are looking forward to cooperate in long term base with you.

P.S. This job is not associated with "money muls"


All this from pencil lead: "graphite is a very old material, but take a tiny tube of 
graphite and it has totally different properties, says Dai. "That's what nanotech is all 
about."



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

Bug#443350: ITP: josm -- Java Open Street Map editor

[Giovanni Mascellani]

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

   Package name: josm
Version: 1.5
Upstream Author: Immanuel Scholz <[EMAIL PROTECTED]> & others
URL: http://josm.eigenheimstrasse.de/
License: GPL
Description: Java Open Street Map editor
JOSM is an editor for OpenStreetMap written in Java 1.5. It makes you
able to download OSM data from the on-line database, edit them and then
upload the modifications to the database.

OpenStreetMap is a Wiki-like project aimed squarely at creating and
providing free geographic data such as street maps to anyone who wants
them. Data are obtained mainly by walking or driving while a GPS unit
is recording your path, then are edited in order to include also
information such as street names and classification, points of
interest, etc. and finally uploaded to the database.

You can see the work done so far at http://www.openstreetmap.org.

Giovanni.
-- 
Giovanni Mascellani <[EMAIL PROTECTED]>
Pisa, Italy

Web: http://giomasce.altervista.org
SIP: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED]
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)



signature.asc
Description: PGP signature

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

[Joey Hess]

Luca Capello wrote:
> This is strange: the Homepage field is shown for some packages [1] and
> not for others [2], e.g. reported below:
> =
> [EMAIL PROTECTED]:~$ apt-cache show ikiwiki | grep "^Homepage"
> Homepage: http://ikiwiki.info/
> 
> [EMAIL PROTECTED]:~$ apt-cache show deb-gview | grep "^Homepage"
> Homepage: http://dpkg-view.alioth.debian.org/

IIRC this is because the alpha buildd didn't have a new version of dpkg
on it, so didn't generate debs with the Homepage field, and packages.d.o
looks at alpha packages first when generating pages for binaries. (So
the source pages should be ok.) There was a thread about this recently.
I don't know if the alpha buildd has been updated yet.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Andreas Fleckl]

Package: wnpp
Severity: wishlist
Owner: Andreas Fleckl <[EMAIL PROTECTED]>


* Package name: asmutils
  Version : 0.18
  Upstream Author : Various Authors 

* URL : http://asm.sourceforge.net/asmutils.html
* License : GPL v2
  Programming Lang: i386 Assembler
  Description : coreutils replacement written in i386 assembler

asmutils is a set of miscellaneous utilities written in assembly language, 
targeted on embedded systems and small 
distributions (e.g. installation or rescue disks); also it contains a small 
libc and a crypto library. It features 
the smallest possible size and memory requirements, the fastest speed, and 
offers fairly good functionality.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Proposal regarding future packaging

[David Given]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Goerzen wrote:
[...]
> 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?

Well, it doesn't actually tell me what I need to know --- how to get started
using a package. I only use it because it's the only way of figuring out what
documentation has installed, and even then it just gives me a dumb list of man
pages and info files, with no suggestions about which one would be a good
starting point for further reading.

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8wEsf9E0noFvlzgRAr9EAJ9UD5iUwVMapddNp+HEjbx95pQWvgCffr7h
cFm6nWfVsniNtiCRsXX8mgo=
=KuyY
-END PGP SIGNATURE-

Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git

[Ron]

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

* Package name: gitpkg
  Version : 0.1
  Upstream Author : Ron <[EMAIL PROTECTED]>
* URL : http://people.debian.org/~ron/gitpkg/
* License : GPL
  Programming Lang: bash
  Description : helper scripts for maintaining packages with git

 This packages provides some simple scripts that assist with maintaining
 Debian packages in git.
 .
 gitpkg- creates a source package from tagged revisons.
 git-debimport - creates a git repository from a set of existing packages.



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

Wiki page (was Re: [RFC] Promoting the use of "Homepage:" field in debian/control)

[Philippe Cloutier]

I'd start with amending the Developers' Reference, then having a test
added to lintian and linda, and after that announcing it on
debian-devel-announce. Then next year, after everyone's had time to
react and upload new packages, do a mass bug filing.
Basically agreed. I created 
http://wiki.debian.org/HomepageFieldTransition adding a few things.



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

Wiki page (was Re: [RFC] Promoting the use of "Homepage:" field in debian/control)

[Philippe Cloutier]

>
> I'd start with amending the Developers' Reference, then having a test
> added to lintian and linda, and after that announcing it on
> debian-devel-announce. Then next year, after everyone's had time to
> react and upload new packages, do a mass bug filing.
Basically agreed. I created 
http://wiki.debian.org/HomepageFieldTransition adding a few things.



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

Re: Proposal regarding future packaging

[Oleg Verych (Gmane)]

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'm hoping the dpkg "triggers" functionality Ian Jackson has been 
> working on will help solve that wart though.

How exactly?



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

Re: Proposal regarding future packaging

[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.'


- Bruce


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

Use of our external site embedded into a Debian file

[John Nagle]

REF: http://db.debian.net/lurker/message/20070707.195201.8e2c00a8.en.html
Author: Varun Hiremath
Date: 2007-07-07 12:52 -700
To: 423669
CC: control, Torsten Werner
New-Topics: Processed: uscan: https support
Subject: Bug#423669: uscan: https support

We noticed a wierd usage of our SiteTruth.com site mentioned in a
Debian bug report.  Bug report #423669 apparently patched a problem
by using a link to a CGI script on our site.

We have a system that rates web pages, and as a service for webmasters,
we have a little utility, "viewer.cgi", which is used to show users how
our crawler saw a page.  Somebody stuck this into a Debian watchfile
because it can be used to read a HTTPS page via HTTP, something they needed.

But "viewer.cgi" does more than that.  It's not a transparent proxy.
It truncates pages at 1MB, parses the HTML into a tree, converts
to Unicode/UTF-8, makes all the links absolute, removes embedded
content (Javascript, Flash, etc.), and outputs the result as cleaned up
and properly indented HTML.  What you get out isn't quite what went in.
So this probably isn't what you want.

SiteTruth really shouldn't be part of some Debian build procedure.
We suggest finding some other way to read HTTPS pages with HTTP.
Wrong tool for the job.  Thanks.

John Nagle
SiteTruth
http://www.sitetruth.com
[EMAIL PROTECTED]


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

Re: Use of our external site embedded into a Debian file

[Ben Finney]

[cc-ing John Nagle as context suggests he's not on this list. John, if
you are subscribed, please say so and we'll stop cc-ing you.]

John, thanks very much for researching the problem before reporting
it. I understand it can be alarming to see that an automated system is
accessing your system in what appears to be an inappropriate fashion;
thank you for coming to us with information instead of demands :-)

John Nagle <[EMAIL PROTECTED]> writes:

> We noticed a wierd usage of our SiteTruth.com site mentioned in a
> Debian bug report.  Bug report #423669 apparently patched a problem
> by using a link to a CGI script on our site.

That's not the case. Varun Hiremath is showing an example of a
workaround to fetch a file; bug #423669 is unrelated to sitetruth.com.

> We have a system that rates web pages, and as a service for
> webmasters, we have a little utility, "viewer.cgi", which is used to
> show users how our crawler saw a page.  Somebody stuck this into a
> Debian watchfile because it can be used to read a HTTPS page via
> HTTP, something they needed.

Yes, that was the example. It's actually unrelated to the resolution
of bug #432669, which was (according to the information in the bug
report) fixed by implementing HTTPS properly in the 'uscan' utility.

> SiteTruth really shouldn't be part of some Debian build procedure.
> We suggest finding some other way to read HTTPS pages with HTTP.
> Wrong tool for the job.  Thanks.

You're quite right that it would be foolish to do so. I believe, from
reading the bug report, that it was merely being used to demonstrate
the problem (lack of HTTPS support), rather than to become part of a
package's built procedure.

Do you have reason to believe the sitetruth.com service is still being
accessed routinely from Debian build programs?

-- 
 \ "Today, I was -- no, that wasn't me."  -- Steven Wright |
  `\   |
_o__)  |
Ben Finney


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

Re: Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git

[Mike Hommey]

On Fri, Sep 21, 2007 at 10:49:26AM +0930, Ron <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ron <[EMAIL PROTECTED]>
> 
> * Package name: gitpkg
>   Version : 0.1
>   Upstream Author : Ron <[EMAIL PROTECTED]>
> * URL : http://people.debian.org/~ron/gitpkg/
> * License : GPL
>   Programming Lang: bash
>   Description : helper scripts for maintaining packages with git
> 
>  This packages provides some simple scripts that assist with maintaining
>  Debian packages in git.
>  .
>  gitpkg- creates a source package from tagged revisons.
>  git-debimport - creates a git repository from a set of existing packages.

Couldn't that be merged with git-buildpackage ?

Mike


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

Work-needing packages report for Sep 21, 2007

[wnpp]

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

Total number of orphaned packages: 302 (new: 2)
Total number of packages offered up for adoption: 78 (new: 0)
Total number of packages requested help for: 36 (new: 0)

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



The following packages have been orphaned:

   blogtk (#443133), orphaned 2 days ago
 Description: GTK Weblogging client
 Installations reported by Popcon: 93

   gsasl (#442273), orphaned 6 days ago
 Description: GNU SASL command line utility
 Reverse Depends: gsasl libgsasl7-dev libmailutils1 libvmime-dev
   libvmime0 mailutils mailutils-imap4d mailutils-mh mailutils-pop3d
   mpop (1 more omitted)
 Installations reported by Popcon: 1398

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



No new packages have been given up for adoption, but a total of 78 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 819 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 112

   apt-build (#365427), requested 509 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 856

   apt-show-versions (#382026), requested 408 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2959

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

   cvs (#354176), requested 574 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (15
   more omitted)
 Installations reported by Popcon: 20605

   dpkg (#282283), requested 1034 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more
   omitted)
 Installations reported by Popcon: 63979

   elvis (#432298), requested 73 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 298

   gentoo (#422498), requested 137 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 268

   grub (#248397), requested 1228 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator
 Installations reported by Popcon: 58596

   ispell-et (#391105), requested 351 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 41

   kradio (#429873), requested 92 days ago
 Description: Comfortable Radio Application for KDE
 Installations reported by Popcon: 285

   lirc (#364606), requested 514 days ago
 Description: Linux Infra-red Remote Control support
 Reverse Depends: audacious-plugins-dev audacious-plugins-extra
   digitaldj fbtv gkrellm-radio gnomeradio gxine irmp3 kradio
   liblircclient-dev (21 more omitted)
 Installations reported by Popcon: 42952

   loop-aes-utils (#385614), requested 385 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-modules-2.6.22-2-486
   loop-aes-modules-2.6.22-2-4kc-malta loop-aes-modules-2.6.22-2-686
   loop-aes-modules-2.6.22-2-686-bigmem
   loop-aes-modules-2.6.22-2-alpha-generic
   loop-aes-modules-2.6.22-2-alpha-legacy
   loop-aes-modules-2.6.22-2-alpha-smp loop-aes-modules-2.6.22-2-amd64
   loop-aes-modules-2.6.22-2-footbridge
   loop-aes-modules-2.6.22-2-iop32x (33 more omitted)
 Installations reported by Popcon: 742

   mc (#380999), requested 415 days ago
 Description: midnight commander - a powerful file manager
 Reverse Depends: junior-system
 Installations reported by Popcon: 15014

   mol (#436450), requested 44 days ago
 Description: The Mac-on-Linux emulator
 Reverse Depends: mol-drivers-linux mol-drivers-macos
   mol-drivers-macosx mol-modules-source
 Installations reported by Popcon: 71

   mwavem (#313369), requested 829 days ago (non-free)
 Description: Mwave/ACP modem s

Some questions about Debian

[Lucas Nussbaum]

Hi,

Following my blog post about communications between distros[1], I contacted
openSUSE and Fedora developers and had a lot of interesting answers. I'd
like to get answers to the same questions from Debian developers.

[1] http://www.lucas-nussbaum.net/blog/?p=250

I could probably write the answers myself, but I think that it's much
better if I act as an "outsider" here, and other developers answer the
questions (so I'm not speaking "for" Debian).

So here is the mail I sent to the other distros.
---
Hi,

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.

So I decided to do something about that, and to go ask the other
distributions' developers a few questions. If this works well (answers and
interest from other distros), I might do that again, or turn this into
something more formal (for example, a mailing list and/or a wiki would
seem well suited for that).

I started by contacting openSUSE and Fedora developers developers, and got
very interesting answers.  I'll publish the answers on my blog[2], and, if
this proves to raise interest, move them to a wiki.

[1] http://www.lucas-nussbaum.net/blog/?p=250
[2] http://www.lucas-nussbaum.net/blog/

Here is a first set of questions. In your answers, please avoid codenames
(act as if the reader didn't know anything about your distribution).
Please try to write your answer as a short paragraph, answering all the
sub-questions from the questions at once.

Q1. Packages
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 ?

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?)

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?

Other questions:
- Did I send that mail to the right mailing list?
- Which question should I have asked? What should I ask next?
- Do you think that this initiative is interesting?
- Do you think that this should move to a seperate mailing list? Would
  you participate in such a mailing list?
- Can you suggest a project that could host such a mailing list without
  annoying anyone? :)
- Any other suggestions?

Thank you for reading me so far -- and for answering my questions if you
did. ;) If you want me to ping you when I'll publish the answers, just
drop me a mail.

-- 
| 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: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christian Perrier]

Quoting Lars Wirzenius ([EMAIL PROTECTED]):

> I'd start with amending the Developers' Reference, then having a test
> added to lintian and linda, and after that announcing it on
> debian-devel-announce. Then next year, after everyone's had time to
> react and upload new packages, do a mass bug filing.


I'd probably add a changes to section 5.6 of the Policy (List of
fields) before adding a test to lintian and linda.

Then file a bug against *apt* packages and p.d.o to have them support
displaying info from that field, before or after the d-d-a
announcement.

I'm not sure whether to amend the DevRef first as it usually documents
"best practices"which will probably become best practices once
enough people started using them.

So, maybe documenting the field in the Policy, first, would be the
best to do.

Then DevRef, then lintian/linda, the d-d-a announcement.

After enough time, we could first send a MBF on packages that match 
"^ +[Hh]ome[Pp]age:" in their description to suggest moving this to
the new field.

Then, a while later, it could become time to think about making this
field mandatory or not and send another MBF against packages that
don't have it at all.


Again, please comment, particularly about the order of changes in
developers documentation. I think this summarizes what I've read as
of now.






signature.asc
Description: Digital signature

Re: Use of our external site embedded into a Debian file

[Ian Campbell]

Package: liquidlnf
Priority: Normal
Version: 2.9.1-2

Please stop using sitetruth.com in your debian/watch -- I think it would
be preferable to just disable the watch file until uscan gets https
support, if it doesn't already have it (I think 2.10.7 does though).

John, this mail to [EMAIL PROTECTED] will open a bug on the package with the
link to your site.

Ian.

On Thu, 2007-09-20 at 22:18 -0700, John Nagle wrote:
> REF: http://db.debian.net/lurker/message/20070707.195201.8e2c00a8.en.html
> Author: Varun Hiremath
> Date: 2007-07-07 12:52 -700
> To: 423669
> CC: control, Torsten Werner
> New-Topics: Processed: uscan: https support
> Subject: Bug#423669: uscan: https support
> 
> We noticed a wierd usage of our SiteTruth.com site mentioned in a
> Debian bug report.  Bug report #423669 apparently patched a problem
> by using a link to a CGI script on our site.
> 
> We have a system that rates web pages, and as a service for webmasters,
> we have a little utility, "viewer.cgi", which is used to show users how
> our crawler saw a page.  Somebody stuck this into a Debian watchfile
> because it can be used to read a HTTPS page via HTTP, something they needed.
> 
> But "viewer.cgi" does more than that.  It's not a transparent proxy.
> It truncates pages at 1MB, parses the HTML into a tree, converts
> to Unicode/UTF-8, makes all the links absolute, removes embedded
> content (Javascript, Flash, etc.), and outputs the result as cleaned up
> and properly indented HTML.  What you get out isn't quite what went in.
> So this probably isn't what you want.
> 
> SiteTruth really shouldn't be part of some Debian build procedure.
> We suggest finding some other way to read HTTPS pages with HTTP.
> Wrong tool for the job.  Thanks.
> 
>   John Nagle
>   SiteTruth
>   http://www.sitetruth.com
>   [EMAIL PROTECTED]
> 
> 
-- 
Ian Campbell

NEWS FLASH!!
Today the East German pole-vault champion became the West German pole-vault
champion.


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

Bug#443406: Acknowledgement (Use of our external site embedded into a Debian file)

[Debian Bug Tracking System]

Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received.  It is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Varun Hiremath <[EMAIL PROTECTED]>

If you wish to submit further information on your problem, please send
it to [EMAIL PROTECTED] (and *not* to
[EMAIL PROTECTED]).

If you have filed this report in error and wish to close it, please
send mail to [EMAIL PROTECTED] with an explanation
why the bug report should be closed.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Use of our external site embedded into a Debian file

[Ian Campbell]

On Fri, 2007-09-21 at 15:41 +1000, Ben Finney wrote:
> 
> > We have a system that rates web pages, and as a service for
> > webmasters, we have a little utility, "viewer.cgi", which is used to
> > show users how our crawler saw a page.  Somebody stuck this into a
> > Debian watchfile because it can be used to read a HTTPS page via
> > HTTP, something they needed.
> 
> Yes, that was the example. It's actually unrelated to the resolution
> of bug #432669, which was (according to the information in the bug
> report) fixed by implementing HTTPS properly in the 'uscan' utility.

It wasn't just an example, liquidlnf 2.9.1-2 in unstable references
sitewatch in debian/watch.

Ian.
-- 
Ian Campbell

You have all eternity to be cautious in when you're dead.
-- Lois Platford


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