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

[Varun Hiremath]

Hi all,

On Fri, 21 Sep, 2007 at 07:35:47AM +0100, Ian Campbell wrote:
> 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).

I have already stopped using sitetruth.com and the watch file has
been fixed in the svn:

http://bollin.googlecode.com/svn/liquidlnf/trunk/debian/watch

I will ask my sponsor to upload this fixed package soon.

Thanks
Varun

-- 
Varun Hiremath
Undergraduate Student,
Aerospace Engineering Department,
Indian Institute of Technology Madras,
Chennai, India
---
Homepage : http://varun.travisbsd.org


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

[Ron]

On Fri, Sep 21, 2007 at 07:42:52AM +0200, Mike Hommey wrote:
> On Fri, Sep 21, 2007 at 10:49:26AM +0930, Ron <[EMAIL PROTECTED]> wrote:
> > Package: wnpp
> > 
> > * Package name: gitpkg
> >   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 ?

Well, they are kind of orthogonal, so I don't really see what sense that
would make.  If you are using the git-buildpackage framework, then you
don't really need these scripts -- but you can use gitpkg to create a
source package from almost any repo with a half-sane structure, not just
ones in some carefully pre-determined form.  All you need is source for
a valid package in the repo, and knowledge of the tag/branch/commit that
you wish to roll the package from.  gitpkg will figure out all the rest
for itself automagically.  You can pluck a package from almost any
arbitrarily named point of almost any repo.

So if you are using gitpkg, you probably don't need git-buildpackage
either.  I've split this out as a standalone command after it became
apparent that the snippets I'd been putting into makefile targets in
various projects to do this could easily be generalised to run as an
external agent, maintained in one place for (and instantly added to)
all of them.

git offers too many degrees of freedom, which different projects might
profitably exercise, to put development through the bottleneck of an
old-style framework.  I think we can, and need to, think differently
about this, and this script is an exploration of that.

I know I'm not the only one who feels that git-buildpackage is not
'right' for them, and this is my best answer to that problem to date.
To point out a couple of concrete problems above and beyond prescribing
the repo layout:

Looking at the manual page for git-buildpackage, it would appear that
you can in fact only build packages from the current HEAD of a branch...
Is that really true?  If so, it sort of misses the point of keeping
all those old package versions in revision control.  If you can't go
back and perfectly reproduce an old package, then you still need to
keep the old packages themselves too...  krusty, say it ain't so?

My latest problem with tools from the git-buildpackage suite was with
git-import-dsc.  After discovering, to my horror, than none of the
cvs import tools seem to be able to get a cvs-buildpackage repo
correctly exported to something usable in git, I decided to forego
the detailed history in preference to being able to extract the old
packages again with perfect fidelity.  I've still got the old repo's
I can examine, and it won't be too long before that's mostly all
ancient history anyhow ...  so I decided to import all my old .debs
directly.  And was most surprised to learn that git-import-dsc can
only import one .deb per repo.  That's it.

So in the last few hours git-debimport was born to automate importing
them all.  Its much cruder and less polished that gitpkg, but its also
a one-shot tool and you won't keep using it like you might gitpkg.

I've had the gitpkg script up for people to poke at on the p.d.p url
for a few weeks now, and its been used in anger on a few packages,
and used in makefile target form for much longer than that.
I've mostly packaged it for my own convenience, but uploaded it to
share the love around.

I don't profess that its in anything like a final form, but if it
provokes some discussion on Better Ways To Do Things, then I'm all
for that.  If the git-buildpackage maintainer would like to pinch
or offer ideas I think that would be great.  If other people find
it useful or find ways to improve it, then maybe we are on to
something.  If not, it will become obsoleted by something better
and I'll be happy to chalk it up as Something I Don't Need To Do
Anymore ...

Anyhow, that's about 10x more text than it took to actually
implement it.  It's already uploaded waiting in NEW and if you
can't wait that long, its a single file with built in help that
you can grab from my p.d.o space.

Have a play with it.  Then we can have a constructive discussion
about what it is and where it belongs.

Cheers,
Ron


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

[Patrick Schoenfeld]

Hi,

IANADD but...

Christian Perrier wrote:
> 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.

you wrote what I thought when I read this proposal. After all it makes
sense to first add support for the field in every important app (that
includes p.d.o and apt off course) before there are bugs filed against
packages.

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

Hm. If you say that this should be specified in DevRef  when enough
people are using it, but you prefer to documenting the field in the
Policy first, then I think this order is wrong. Probably should
lintian/linda be changed all together with the policy and then announced.

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

Wouldn't it make sense to make it mandatory from the beginning of a
policy change?

Just my 2 cents.

Best Regards,

Patrick


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

Proposed menu changes

[Manoj Srivastava]

Hi,

While in the process of working on a new fvwm package, I
 noticed that the Menu policy has changed some of the old titles to new
 ones.  For example, WindowManagers => "Window Managers", Modules =>
 "FVWM Module" (which is incorrect; the correct way to address the wm
 is Fvwm). 

But this means that people  who use Debian menus in fvwm have
 now got to change their .fvwm/.fvwmrc files; and use the new names.
 For example, 
+ "&WindowManagers" Popup /Debian/WindowManagers
+ "&FVWM Modules" Popup "/Debian/Modules"
 nust become.
+ "&FVWM Modules" Popup "/Debian/FVWM_Modules"
+ "&Window Managers" Popup "/Debian/Window_Managers"

So, with the new menu policy, Fvwm users have to edit their
 configuration files.  Are there any plans for preserving backwards
 compatibility, or at least a transition plan?

manoj
-- 
Someone in DAYTON, Ohio is selling USED CARPETS to a SERBO-CROATIAN
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: [RFC] Promoting the use of "Homepage:" field in debian/control

[Manoj Srivastava]

On Thu, 20 Sep 2007 18:02:56 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

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

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.

Oh, if anyone has any ideas about the docbook template for
 policy rules, now is the time to send them in.  I am planning on
 spending time on all the policy related proposals I talked about at
 debconf.

manoj
-- 
Murder is contrary to the laws of man and God. M-5 Computer, "The
Ultimate Computer", stardate 4731.3
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]

Bug#443437: ITP: innotop -- A mysql and innodb monitor

[Patrick Schoenfeld]

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

* Package name: innotop
  Version : 1.4.3
  Upstream Author : Baron Schwartz 
* URL : http://innotop.sourceforge.net
* License : GPL
  Programming Lang: Perl
  Description : A mysql and innodb monitor

innotop is a text-mode monitoring tool for MySQL and InnoDB.
..
innotop can monitor InnoDB transactions and internals, queries and processes,
deadlocks, foreign key errors, replication status, system variables and status
and much more.

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

Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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: [RFC] Promoting the use of "Homepage:" field in debian/control

[Raphael Hertzog]

On Fri, 21 Sep 2007, Manoj Srivastava wrote:
>  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

p.d.o already supports it. "apt-cache show" obviouly displays the field.

The work left concerns higher-level user interface like aptitude and
synaptic. Someone should file bugs against them for a start (I checked and
none of them have a bug with a subject matching /homepage/).

Maybe update-manager too.

Cheers,
-- 
Raphaël Hertzog

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


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

Re: Bug#443222: ITP: uriparser -- URI parsing library compliant with RFC 3986

[Adeodato Simó]

* Elimar Riesebieter [Thu, 20 Sep 2007 00:06:21 +0200]:

> It looks like it can be used to strip uri's out of MUA to view i.e.
> inet pages similar to urlview?

I don't know, so you'd have to ask upstream, but personally I doubt it.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Let us not be ashamed to speak what we shame not to think.
-- Michel de Montaigne


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

[Adeodato Simó]

* Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:

> Again, please comment,

Personally, I think the change that should really go first is lintian/linda
(emitting a warning for packages that put the homepage in the description),
since that's what will make most packages change, and will give the
Homepage field the status quo needed to make it into devref and policy.

It will also make the size of the mass bug filings smaller, though I'm
not sure I like the idea of a MBF for this.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott


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

ITP: libconvert-pem-perl -- It reads and writes PEM files contaiining ASN.1 -encoded objects.

[Deepak Tripathi]

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

* Package name : libconvert-pem-perl
Version   : 0.07
Upstream Author  : Benjamin Trott, [EMAIL PROTECTED]
* URL : 
http://search.cpan.org/~btrott/Convert-PEM-0.07/

* License: Perl License
Programming Lang   : Perl
Description: /Convert::PEM/ reads and writes PEM files 
containing ASN.1-encoded objects. The files can optionally be encrypted 
using a symmetric cipher algorithm, such as 3DES.



--
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 04:53:34PM +0930, Ron <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 21, 2007 at 07:42:52AM +0200, Mike Hommey wrote:
> > On Fri, Sep 21, 2007 at 10:49:26AM +0930, Ron <[EMAIL PROTECTED]> wrote:
> > > Package: wnpp
> > > 
> > > * Package name: gitpkg
> > >   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 ?
> 
> Well, they are kind of orthogonal, so I don't really see what sense that
> would make.  If you are using the git-buildpackage framework, then you
> don't really need these scripts (...)

Actually, I don't see why it's necessary to have a package for 2 scripts
that might not be even 100 lines each. These scripts could be
distributed with git-buildpackage. There is no reason git-buildpackage
should be limited to the set of scripts it already contains, or a single
possible workflow for using git to maintain debian packages ?

What are we going to see next ? Yet another package because someone else
will feel none of gitpkg or git-buildpackage fit his needs ?

Why not have only one package containing different tools that fit
different needs ?

Mike


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

[Patrick Schoenfeld]

Mike Hommey schrieb:
> What are we going to see next ? Yet another package because someone else
> will feel none of gitpkg or git-buildpackage fit his needs ?

Whats so bad about this? FOSS is much about choice, isn't it? Why
shouldn't the user have the choice to select from different tools? In my
humble opinion it does not make so much sense to pack those tools
together just to have less packages.

> Why not have only one package containing different tools that fit
> different needs ?

Why don't you buy a cow, if you want a bottle of milk? Because you don't
need it. And you don't want it. So why force the user to install a lot
of (for him) useless tools if they just need and want one package that
does the job nice? Also it makes it much harder for users to *find* the
tools they need.

Just my 2 cents.
Best Regards,

Patrick


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

pe, 2007-09-21 kello 16:44 +0200, Adeodato Simó kirjoitti:
> * Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:
> 
> > Again, please comment,
> 
> Personally, I think the change that should really go first is lintian/linda
> (emitting a warning for packages that put the homepage in the description),

At the very least, lintian should stop warning about Homepage:, right?
(Sorry if it already doesn't warn, I haven't had time to upgrade and the
machine hosting my mirror decided to commit suicide today.)

-- 
Code is cheap to write.


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

[Josselin Mouette]

Le vendredi 21 septembre 2007 à 20:49 +0200, Patrick Schoenfeld a écrit :
> Whats so bad about this? FOSS is much about choice, isn't it? Why
> shouldn't the user have the choice to select from different tools? In my
> humble opinion it does not make so much sense to pack those tools
> together just to have less packages.

Debian is about building an operating system, not about packing a giant
pile of crap that a few people in the world will ever use. Having some
choice between 2 incomplete tools is worse than not having any choice.
Either these tools are complementary and they should be packaged
together, or they are functionally similar and should be merged.

> Why don't you buy a cow, if you want a bottle of milk? Because you don't
> need it. And you don't want it. So why force the user to install a lot
> of (for him) useless tools if they just need and want one package that
> does the job nice? 

A pair of scripts is not "a lot of useless tools", sorry. The real issue
here is archive bloat.

> Also it makes it much harder for users to *find* the
> tools they need.

Are you serious? Tools are much easier to find when in a single package
that achieves the desired functionality. 

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

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

[Manoj Srivastava]

On Fri, 21 Sep 2007 22:08:12 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 

> pe, 2007-09-21 kello 16:44 +0200, Adeodato Simó kirjoitti:
>> * Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:
>> 
>> > Again, please comment,
>> 
>> Personally, I think the change that should really go first is
>> lintian/linda (emitting a warning for packages that put the homepage
>> in the description),

> At the very least, lintian should stop warning about Homepage:, right?
> (Sorry if it already doesn't warn, I haven't had time to upgrade and
> the machine hosting my mirror decided to commit suicide today.)

Err, I did not find it warned me about my fvwm uploads, so that
 part is done too.

manoj
-- 
Some marriages are made in heaven -- but so are thunder and lightning.
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: [RFC] Promoting the use of "Homepage:" field in debian/control

[Adeodato Simó]

* Manoj Srivastava [Fri, 21 Sep 2007 16:51:03 -0500]:

> On Fri, 21 Sep 2007 22:08:12 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 
> > At the very least, lintian should stop warning about Homepage:, right?
> > (Sorry if it already doesn't warn, I haven't had time to upgrade and
> > the machine hosting my mirror decided to commit suicide today.)

> Err, I did not find it warned me about my fvwm uploads, so that
>  part is done too.

Try `lintian -I`. (Because the warning was not a W:arning, but an I:nfo
item.)

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Don't be irreplaceable, if you can't be replaced, you can't be promoted.


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

Re: Bug#440577: libdkim-dev: Package namespace conflict

[Mike Markley]

On Sun, Sep 02, 2007 at 06:33:51PM -0700, Mike Markley <[EMAIL PROTECTED]> 
wrote:
> On Sun, Sep 02, 2007 at 11:46:18PM +0200, Magnus Holmgren <[EMAIL PROTECTED]> 
> wrote:
> > Both dkim-milter and libdkim builds libdkim-dev, and libdkim0 and libdkim2 
> > conflict too, even though the names aren't completely identical. As I 
> > explained when dkim-milter was first packaged, I'm not completely foreign 
> > to 
> > dropping Alt-N's libdkim altogether, but the issue should be properly 
> > discussed first.
> 
> Somehow I'd had a brainlapse and forgotten about this issue before
> uploading the new packages; entirely my fault.
> 
> If you still see value in the AltN library, I'm happy to rename my
> packages (probably to something like libdkim-sendmail or libsmdkim or
> the like). We'll still need to decide about library names, but I don't
> see that you need to drop your packages unless they're completely
> unnecessary.

I haven't heard anything back, so I'll assume that you continue to plan
to maintain the existing libdkim. My current plan is to do the rename
as described above; input from debian-devel is welcomed (but I'm not
subscribed, so please Cc: me).

-- 
Mike Markley <[EMAIL PROTECTED]>

There can be no twisted thought without a twisted molecule.
- R. W. Gerard


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

User-Agent strings, privacy and Debian browsers

[Peter Eckersley]

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.

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?

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.

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

[Roberto C . Sánchez]

On Fri, Sep 21, 2007 at 06:03:05PM -0700, Peter Eckersley wrote:
> 
> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?
> 
It would be sort of pointless unless we could find a way to all browse
from the same IP address.

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

[Marco d'Itri]

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.

> What do people think of picking a single User-Agent string for all
> versions of all of Debian's Gecko-based browsers?
It's a bad idea. Please do not try to fuck up browsers.

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

> there many sites which usefully treat different Gecko browsers
> differently?
It's probably a number small enough to not be relevant in any decision.
Using the User-Agent string instead of proper functional testing is
badly broken anyway and is not the reason for User-Agent and similar
headers in other protocols.

> 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?
A waste of time for us, but I am sure that you could use it to make some
nice PR to justify your job.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Thomas GOIRAND]

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

* Package name: xmms-pulse
  Version : 0.9.3
  Upstream Author : Lennart Poettering <[EMAIL PROTECTED]>
* URL : http://0pointer.de/lennart/projects/xmms-pulse/
* License : GPL v2
  Programming Lang: C/C++
  Description : Pulseaudio output plugin for xmms

 This plugin connects xmms to Pulseaudio, a drop in replacement for the ESD
 sound server with much better latency, so its output will be mixed with your
 system sounds and the output of other ESD/pulse programs, rather than
 conflicting with them.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (700, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)



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

Re: Proposal regarding future packaging

[Oleg Verych (Gmane)]

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.



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

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


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





signature.asc
Description: Digital signature