Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le jeudi 13 août 2009 00:48:13, Manoj Srivastava a écrit :
> > That makes a difference in the sense that it helps to improve the
> > workflow by putting as much information as possible in the same place.
>
> Oh, for Pete's sake, just run zless on the file lintian already
>  reports for you. If people are too lazy to run zless , I kinda
>  doubt they are actually going to the effort of actually doing a good
>  job on their packages. You realize you still have to read the sections
>  mentioned in the policy document, right?

Treating people to be lazy will not lead to a better quality of their 
packages. Simplifying their work, however, will.

> > Even more, if, as I suggested, it lists only changes that couldn't be
> > automatised, that would make lintian a consistent tool for checking a
> > package against the current policy.
>
> ANd how is lintian supposed to know this? Or are you saying we
>  have a new version of lintian every time that policy is updated, and it
>  hard codes the line in the upgrading checklist to report, and only
>  reports sections that have changes not fully checked by lintian -- and
>  for what? so that someone does not have to type zless ?

I realize this is not easy to implement. I will, however propose something 
showing the whole list of changes.



Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le jeudi 13 août 2009 01:13:44, Romain Beauxis a écrit :
> Le jeudi 13 août 2009 00:31:40, Paul Wise a écrit :
> > Please file a bug (and patch) against lintian, I doubt the lintian
> > maintainers would have a problem with this as long as it is
> > implemented sanely.
>
> Ok. Are the .desc files processed in any way ?
> I looked at lintian's source and could find any substitution there..

That was meant to be private, sorry for noise..

Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le jeudi 13 août 2009 00:31:40, Paul Wise a écrit :
> Please file a bug (and patch) against lintian, I doubt the lintian
> maintainers would have a problem with this as long as it is
> implemented sanely.

Ok. Are the .desc files processed in any way ?
I looked at lintian's source and could find any substitution there..


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Thu, Aug 13 2009, Romain Beauxis wrote:

> What I mean is that we can use the information contained in the
> standards- version tag and display at this place the list of changes
> that were done since> 3.7.0 

Assuming you have the policy package installed.

> That makes a difference in the sense that it helps to improve the workflow by 
> putting as much information as possible in the same place.

Oh, for Pete's sake, just run zless on the file lintian already
 reports for you. If people are too lazy to run zless , I kinda
 doubt they are actually going to the effort of actually doing a good
 job on their packages. You realize you still have to read the sections
 mentioned in the policy document, right?


> Even more, if, as I suggested, it lists only changes that couldn't be
> automatised, that would make lintian a consistent tool for checking a
> package against the current policy.

ANd how is lintian supposed to know this? Or are you saying we
 have a new version of lintian every time that policy is updated, and it
 hard codes the line in the upgrading checklist to report, and only
 reports sections that have changes not fully checked by lintian -- and
 for what? so that someone does not have to type zless ?

manoj
-- 
Linux: Because a PC is a terrible thing to waste. (By
komar...@craft.camp.clarkson.edu, Mark Komarinski)
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Thu, Aug 13 2009, Charles Plessy wrote:

> Le Wed, Aug 12, 2009 at 10:44:26PM +0800, Paul Wise a écrit :
>> 
>> IIRC, there is a plan for splitting Descriptions out of the Packages files
>
> For the curious, there is some extra information here:
> http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2009-August/000507.html
>
> In my experience, Standards-Version is not an accurate indicator of
> Policy conformance, so unless there is a collective effort to change
> this, I would support the idea of Standards-Version becomming
> optional.

As steve said, it is not an indicator of policy conformance, and
 it is not supposed to be one. So there need not be a concerted effort
 to change the meaning of the field. It is a bookmark into the upgrading
 checklist based on the last version the upoaders  checked against.

If there are people not managing their Standards Versions fields
 like they are supposed to, and are too lazy or incompetent to keep
 track of a simple version, I suggest we start thinking about removing
 DD status from people based on a track record of incompetence.

BTW, you did file serious bugs against the packages that were
 not policy compliant, right?

manoj
-- 
Make no little plans; they have no magic to stir men's blood. Daniel
Hudson Burnham
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's the use for Standards-Versi on?

[Giacomo A. Catenazzi]

Raphael Hertzog wrote:
> On Wed, 12 Aug 2009, Manoj Srivastava wrote:
>> I do not have a strong opinion about this, apart from the fact
>>  that it must be present in the sources when someone is looking to
>>  update the package, and it should be accessible before downloading all
>>  the sources. So having it in the diff.gz and PTS would be good enough.
> 
> The PTS gets it from Sources.gz so removing it is not really an option.

PTS could read data from an other file.

BTW also Maintainer and Uploader fiels are uselessly exported.
The real maintainers and uploaders are defined by the values in the
last uploaded package, not from actual package.
[BTW sometime maintainers are also partially defined by wnpp reports]

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Paul Wise]

On Thu, Aug 13, 2009 at 1:15 PM, Romain Beauxis wrote:

> What I mean is that we can use the information contained in the standards-
> version tag and display at this place the list of changes that were done since
> 3.7.0
>
> That makes a difference in the sense that it helps to improve the workflow by
> putting as much information as possible in the same place.
>
> Even more, if, as I suggested, it lists only changes that couldn't be
> automatised, that would make lintian a consistent tool for checking a package
> against the current policy.

Please file a bug (and patch) against lintian, I doubt the lintian
maintainers would have a problem with this as long as it is
implemented sanely.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le jeudi 13 août 2009 00:09:09, Cyril Brulebois a écrit :
>   Romain Beauxis  (12/08/2009):
> > Is it foolish to propose this as a lintian check ? "Hey, standards
> > version is outdated, here are the changes that ought to be done"
>
> checks/standards-version.desc

Please, pretty please, try to make sentences. I hardly understand your 
comment, which makes it ambigous.

Here is the output of a lintian warning currently in the case of an outdated 
standards-version:

W: foo: ancient-standards-version 3.7.0 (current is 3.8.2)
N:  
  
N:The source package refers to a Standards-Version that has been obsolete   
  
N:for more than two years. Please update your package to latest Policy and  
  
N:set this control field appropriately.
N:
N:If the package is already compliant with the current standards, you
N:don't have to re-upload the package just to adjust the Standards-Version
N:control field. However, please remember to update this field next time
N:you upload the package.
N:
N:See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the
N:debian-policy package for a summary of changes in newer versions of
N:Policy.
N:
N:Severity: normal, Certainty: certain


What I mean is that we can use the information contained in the standards-
version tag and display at this place the list of changes that were done since 
3.7.0

That makes a difference in the sense that it helps to improve the workflow by 
putting as much information as possible in the same place.

Even more, if, as I suggested, it lists only changes that couldn't be 
automatised, that would make lintian a consistent tool for checking a package 
against the current policy.


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Charles Plessy]

Le Wed, Aug 12, 2009 at 10:44:26PM +0800, Paul Wise a écrit :
> 
> IIRC, there is a plan for splitting Descriptions out of the Packages files

For the curious, there is some extra information here:
http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2009-August/000507.html

In my experience, Standards-Version is not an accurate indicator of Policy
conformance, so unless there is a collective effort to change this, I would
support the idea of Standards-Version becomming optional.

In further developments, it could later be managed independantly from
debian/control together with other meta-data like the VSC, Homepage, Section
and Description fields, the Debtags, etc.

Have a nice day,

-- 
Charles Plessy


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Cyril Brulebois]

Romain Beauxis  (12/08/2009):
> Is it foolish to propose this as a lintian check ? "Hey, standards version
> is outdated, here are the changes that ought to be done"

checks/standards-version.desc

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Wed, Aug 12 2009, Russ Allbery wrote:

> Paul Wise  writes:
>
>> Not having anything to do with Ubuntu, I don't know anything about the
>> details, but they have had automatic debug packages and automated
>> crash report stuff for quite a while, a couple of years IIRC. The
>> specs for that are here:
>>
>> https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols> 
>> https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports
>
> Ah, thank you!
>
> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification.  It
> does use *.ddeb.  There isn't any clear statement about how *.ddeb
> packages differ from *.deb packages.  It looks like, by and large,
> they don't, except they may not need to contain the same set of
> things.  The packages are not in debian/control or the things fed from
> it, but are in *.changes.

Thanks for the link.

They mention:
--8<---cut here---start->8---
# They (ddebs)  can be arranged in a proper pool structure with a
  Packages file etc., so that existing tools to mirror, download, and
  ship debs can be reused.  
# Users can actually install them if they want to. 

 ...

An apt frontend will be provided to conveniently install debug symbols:
e. g. apt-get debug apache2 would install the -dbgsym ddebs for apache2
and all its dependencies. This will allow developers to actually install
the .ddebs 
--8<---cut here---end--->8---


This is what I find interesting. So, not quite
 aptitude/synhaptic, but analogous to apt-get source. This does answer
 some of the questions I had about implementation.

> Ubuntu is creating one debug package per binary package, as I and a few
> other people have said we prefer.  However, they're using the
> gnu_debuglink method, not the id method, so they don't have the one
> problem with that method previously identified in this thread when the
> same binary is copied into multiple packages.

Or the facility to keep debug symbols around for multiple
 versions of shared libraries (with the same soname), which is an
 advantage the build id method has.

> The proposal appears to only work for packages using debhelper, although
> the steps are laid out so presumably they could be done manually if need
> be.

Yes, though some sleight of hand might be needed do build a
 package which is not in control (dpkg-deb --nocheck), or if the package
 is in debian/control, debian/files would have to have the .deb line
 removed, and dpkg-distaddfile used to register the ddeb file name).

> Ubuntu uses -dbgsym as the magic namespace.  I don't know if it would be
> good for us to do the same or to use a different namespace to avoid
> problems for them in cases where we decide to build the package manually
> via debian/control and debian/rules.

I would still like to see coverage figures to figure out what
 percentage of the archive will need this.


> It looks like the plan with *.ddeb is to treat them specially in the
> archive software and divert them into a different tree in the archive
> instead of using a separate archive area, which I think they're doing
> now from that page.  It also looks like one of the justifications for
> the separate package is to hide them in the apt front-end so that
> users don't see all the additional packages.  I'm personally skeptical
> this is a good idea, although I can see the merits of not returning
> them in apt-cache search.

I am not sure I see that. When I ask apt cache for packages that
 currently have a debug package, I do not see the rpesence of
 information about the debug package as garbage; it is nice to know that
 the debg information exists.


> Ah, and it looks like the automated crash reporting offers to download the
> -dbgsym packages and install them.

Reading the spec, it seems to me that the primary motivation was
 for users to provide crash dumps with bug reports, and not much screen
 time is given to users debugging their own applications linked to
 vendor libraries, or for the developer user  in general. I think that
 use case should be addressed as well.

> I don't see any sign in this of a share.

I am not sure I see much utility in a share, personally, since I
 have not really had an installation where I spent any time in where the
 mount would not have been prevented by perimeter defenses and security
 policies.

manoj
-- 
"Help save the world!"  --Larry Wall in README
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Cyril Brulebois]

Russ Allbery  (12/08/2009):
> zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
> | sed /`grep Standards-Version debian/control | awk '{ print $2 }'`/Q
> 
> ?  I just use zless on that file and stop reading when I get to the
> current Standards-Version of the package, but that would automate it.

Argh, you beated me to it.

> This is, indeed, exactly the use of the Standards-Version field that both
> Manoj and I are advocating.

It somewhat reminds me of something being checked during NM. I guess
old-timers will reply that once upon a time… but oh well.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le mercredi 12 août 2009 23:22:45, Russ Allbery a écrit :
> Romain Beauxis  writes:
> > But there could be another use of this field, which would fit into the
> > test- driven workflow. What about a tool that displays the changes in
> > the policy based on the declared supported version and the latest
> > version ?
>
> Like:
>
> zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
> | sed /`grep Standards-Version debian/control | awk '{ print $2
> }'`/Q
>
> ?  I just use zless on that file and stop reading when I get to the
> current Standards-Version of the package, but that would automate it.
>
> This is, indeed, exactly the use of the Standards-Version field that both
> Manoj and I are advocating.

Is it foolish to propose this as a lintian check ? "Hey, standards version is 
outdated, here are the changes that ought to be done"

Even more, this could include only the changes that cannot be automated..


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Russ Allbery]

Romain Beauxis  writes:

> But there could be another use of this field, which would fit into the
> test- driven workflow. What about a tool that displays the changes in
> the policy based on the declared supported version and the latest
> version ?

Like:

zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
| sed /`grep Standards-Version debian/control | awk '{ print $2 }'`/Q

?  I just use zless on that file and stop reading when I get to the
current Standards-Version of the package, but that would automate it.

This is, indeed, exactly the use of the Standards-Version field that both
Manoj and I are advocating.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Manoj Srivastava]

On Wed, Aug 12 2009, Russ Allbery wrote:

> Paul Wise  writes:
>> On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava 
>> wrote:
>
>>>        I too am wondering if we should defer the polivy change until
>>>  the details get shaken out with a partial deployment of the scheme.
>
>> Full deployment already happened (in Ubuntu).
>
> As .ddebs?  What's the policy about what can go in them and how are they
> integrated with the packaging tools?  And could you point me at the Ubuntu
> share for the debugging information so that I can see what protocols it's
> using?

Did ubuntu have to modify the default package manager (synaptic,
 right?) in order to allow the user to install the ddebs locally? I
 would be interested in the details of how to hook up to the debug
 packages archive in Ubuntu (I shall try installing an Ubuntu virtual
 machine this weekend to try this out).

> Prior experience is *great*.  We can learn from the experiences of Ubuntu.

I would also like to learn of the coverage Ubuntu managed to
 achieve, given that they have full deployment. What is the percentage of
 packages they managed to auto create?  This is indeed very valuable
 information, I  am surprised no one has been mentioning any figures at
 all about this full deployment in Ubuntu.

manoj
-- 
"A mind is a terrible thing to have leaking out your ears." The League
of Sadistic Telepaths
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Romain Beauxis]

Le mercredi 12 août 2009 04:59:09, Josselin Mouette a écrit :
> AIUI, this header is here to indicate which version of the policy the
> package is supposed to conform to. This way, we have a way to enforce
> which policy versions are supported, e.g. in a stable release, by
> forbidding the too old versions.

Cleartly, that this field is not quite used at the moment. Clearly also, the 
packaging workflow nowadays tends to be driven by lintian checks. You do the 
update, you pass through the automated tests.

Some people remarked that, unfortunately, not all policy requirements can be 
automated, hence there is a difference between being lintian clean and 
conforming to the policy.

Some other remarked that it is a very time-consuming task to do all the 
checklist for every policy change, which is quite true.

But there could be another use of this field, which would fit into the test-
driven workflow. What about a tool that displays the changes in the policy 
based on the declared supported version and the latest version ?

This could display a simple checklist that the maintainer could check easily. 
This would also include only the relevant changes since the latest check, 
while we only have diff from one version to another.

Eventually, after going through the list, you could safetly update this field 
knowing and also save time.



Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Russ Allbery]

Paul Wise  writes:

> Not having anything to do with Ubuntu, I don't know anything about the
> details, but they have had automatic debug packages and automated
> crash report stuff for quite a while, a couple of years IIRC. The
> specs for that are here:
>
> https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols
> https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports

Ah, thank you!

https://wiki.ubuntu.com/AptElfDebugSymbols is the specification.  It does
use *.ddeb.  There isn't any clear statement about how *.ddeb packages
differ from *.deb packages.  It looks like, by and large, they don't,
except they may not need to contain the same set of things.  The packages
are not in debian/control or the things fed from it, but are in *.changes.

Ubuntu is creating one debug package per binary package, as I and a few
other people have said we prefer.  However, they're using the
gnu_debuglink method, not the id method, so they don't have the one
problem with that method previously identified in this thread when the
same binary is copied into multiple packages.

The debug packages depend on the packages for which they have symbols,
which solves the problem of not installing debug packages that both
provide symbols for the same binary.

The proposal appears to only work for packages using debhelper, although
the steps are laid out so presumably they could be done manually if need
be.

Ubuntu uses -dbgsym as the magic namespace.  I don't know if it would be
good for us to do the same or to use a different namespace to avoid
problems for them in cases where we decide to build the package manually
via debian/control and debian/rules.

It looks like the plan with *.ddeb is to treat them specially in the
archive software and divert them into a different tree in the archive
instead of using a separate archive area, which I think they're doing
now from that page.  It also looks like one of the justifications for the
separate package is to hide them in the apt front-end so that users don't
see all the additional packages.  I'm personally skeptical this is a good
idea, although I can see the merits of not returning them in apt-cache
search.

Ah, and it looks like the automated crash reporting offers to download the
-dbgsym packages and install them.

I don't see any sign in this of a share.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Paul Wise]

On Thu, Aug 13, 2009 at 11:25 AM, Russ Allbery wrote:

> As .ddebs?  What's the policy about what can go in them and how are they
> integrated with the packaging tools?  And could you point me at the Ubuntu
> share for the debugging information so that I can see what protocols it's
> using?
>
> Prior experience is *great*.  We can learn from the experiences of Ubuntu.

Not having anything to do with Ubuntu, I don't know anything about the
details, but they have had automatic debug packages and automated
crash report stuff for quite a while, a couple of years IIRC. The
specs for that are here:

https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols
https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Russ Allbery]

Paul Wise  writes:
> On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava wrote:

>>        I too am wondering if we should defer the polivy change until
>>  the details get shaken out with a partial deployment of the scheme.

> Full deployment already happened (in Ubuntu).

As .ddebs?  What's the policy about what can go in them and how are they
integrated with the packaging tools?  And could you point me at the Ubuntu
share for the debugging information so that I can see what protocols it's
using?

Prior experience is *great*.  We can learn from the experiences of Ubuntu.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Paul Wise]

On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava wrote:

>        I too am wondering if we should defer the polivy change until
>  the details get shaken out with a partial deployment of the scheme.

Full deployment already happened (in Ubuntu).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Manoj Srivastava]

On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:


> There will still be a repository with all the .ddebs.

And aptitude and dpkg will know how to install ddebs, somehow?
 and synaptic, etc?

> But also we will have a share that will ship all the debugging symbols
> in a build id file hierarchy structure (so something like
> .build-id/xx/xxx.debug). You can mount it in your system and use
> it as if you had installed every -ddeb available in the
> archive.

So all debugging has to happen online? Many places have a
 prohibition against mounting a file system from outside the firewall,
 though installing packages that have been vetted is permissible

. 

> Furthermore, if disk space permits it, we will provide symbols for
> more than one version (i.e. not only the current package in the
> archive, but maybe the last three or whatever we can do), since build
> ids permit it.

With packages, mirrored repositories may have a different
 retention policy, and not rely on the packages one has installed
 disappearing off the remote filesystem.

The system you propose works great for the use case you have
 envisaged: Debugging on a low security instllation with always on
 broadband connection to the network; but surely that is not the only
 model we provide.

I am also wondering about the obstacles placed in the path of
 packages that will not be covered by the automated system. While we
 were  talking about generating .debs, that was some work, but not any
 different from creating a package.  Now, in order to create a hand
 crafted ddeb, what does one do? Add a nerw package to debian/control,
 build it, rename the package, edit ./debian/files before
 dpkg-genchanges is called  -- this is more complex than just calling
 dpkg-buildpackage and be done with it.

So I am wondering if the selction by package name is not good
 enough, and  whether we really need selection using *.ddeb$  --
  /.*-ddeb_.*\.deb$/ is not that much more complex a regular expression,
  and it brings with it the ability to  manually create the debug symbol
  packages easily, using dpkg-bvuildpackage.

I too am wondering if we should defer the polivy change until
 the details get shaken out with a partial deployment of the scheme.


manoj
-- 
"Don't tell me I'm burning the candle at both ends -- tell me where to
get more wax!!"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Russ Allbery wrote:

>>> Except that in that case, the old library will be NBS and thus I see
>>> no point why you would want to keep it installed. The only reason
>>> would be if it was meant to stay around, but in that case I'm sure the
>>> source package names would be different.

>> Because you're trying to debug a binary on your system that's linked
>> against it.

> Then you should work on making your package build with the new library,
> since it will be FTBFS anyway :)

I was not under the impression that this system was intended only for the
use of Debian Developers.

> I don't consider this a real issue.

I do.  I think it's a fairly significant one.

> There will still be a repository with all the .ddebs. But also we will
> have a share that will ship all the debugging symbols in a build id file
> hierarchy structure (so something like .build-id/xx/xxx.debug). You
> can mount it in your system and use it as if you had installed every
> -ddeb available in the archive. Furthermore, if disk space permits it,
> we will provide symbols for more than one version (i.e. not only the
> current package in the archive, but maybe the last three or whatever we
> can do), since build ids permit it.
>
> With this in place, we can integrate reporting tools (bug-buddy,
> drkonqi, apport) to use that service to magically provide meaningful bug
> reports with complete backtraces.

Hm, that's interesting, but I suspect that few enough of our users will be
able to use such a thing that we shouldn't let that influence any other
design choices.  Most shares are not going to be able to be mounted
through firewalls, for example, so that form of the debug symbols won't be
available to quite a few users.

Or maybe by "share" you meant something that was more like a file download
service over HTTP than, say, NFS?

> If you use this, you won't need to get a backtrace, realize you're
> missing some symbols, install some more debug packages, rinse,
> repeat... :)

I thought you were planning on automating *this*, which I think is more
useful than providing a share.  It seems like it would be fairly
straightforward in conjunction with the Contents database and the ldd
output on the binary that crashed.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Harald Braumann]

On Thu, 13 Aug 2009 02:03:43 +0100
Roger Leigh  wrote:

> On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote:
> > On Wed, 12 Aug 2009 13:03:30 +0100
> > Roger Leigh  wrote:
> > 
> > > On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote:
> > > > I'm not sure, whether a conclusion is already reached.
> > > > 
> > > > 1. apt-get install mysql
> > > > 2. enter mysql client
> > > > 3. create database test; create table test( test char(10) );
> > > > 
> > > > Replace mysql with whatever application you like.
> > > > 
> > > > What should be the encoding of database and table test in cases
> > > > like the above?
> > > > 
> > > > Currently it's iso-something, discriminating everybody from
> > > > other countries. If it would be utf-8 instead, it would have at
> > > > least two advantages
> > > > 
> > > > - The clueless user would get a sane default
> > > > - utf-8 isn't as discriminating as iso-8859-1
> > > 
> > > UTF-8 is the sane default choice in this situation, so long as
> > > MySQL is capable of handling it.
> > 
> > Is that a real problem? Usually applications that use a SQL DB come
> > with some script to set up the schema. If they want UTF-8, they will
> > create a table with UTF-8 encoding. I wouldn't change MySQL's
> > default without reason, because old scripts might rely on that
> > behaviour.
> 
> Those "old scripts" which don't specify an encoding *are already
> buggy* due to not saying what they want, implying that the default
> (whatever that might be) is fine.
Agreed. Still no need to break them on purpose.

 
> There's the possibility that this might cause some problems, but they
> are problems in the script, not in MySQL.  Keeping using an obsolete
> encoding like Latin 1 (or whatever the default currently is) prevents
> any breakage, but at the expense of moving to a sane default for the
> future.
I really don't care too much about the specific case of MySQL, as I
hardly ever create or manipulate SQL data by hand. All I was saying
and you seem to be saying as well, if I understand you correctly,
is that it is the duty of the application that creates and uses SQL
tables to specify the encoding, if it cares about it. If the
application does that, it will work, no matter what default is
specified for MySQL. So this specific case is a non-issue, IMO, and
MySQL's default doesn't need to be changed. But if it is, just for the
sake of it, then that's fine with me. Some scripts might break, but OK.

> 
> > Those applications, however, should be configured to use UTF-8 by
> > default (if they support it) and their DB setup scripts accordingly.
> 
> They should indeed, but if they don't then they need to explicitly
> spell out what they *do* support.
The should.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Automatic Debug Packages

[Roger Leigh]

On Thu, Aug 13, 2009 at 02:58:45AM +0200, Emilio Pozuelo Monfort wrote:
> Roger Leigh wrote:
> > On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> >> Quantity of .ddebs:
> >> Usually there should only be one .ddeb per source. Of course there are
> >> always exceptions from the rule, so Maintainers may chose to have one
> >> per binary package. This should only be taken when the size of the debug
> >> package gets *huge* otherwise. It is hard to set definite numbers here,
> >> but a 5mb package would surely not be a reason to split into two 2.5mb
> >> ones.
> > 
> > This fails to address the rather valid concern brought up about
> > having different versions of libraries and binaries installed
> > from the same source package.  Having one .ddeb per binary would
> > solve this elegantly.
> 
> Except that in that case, the old library will be NBS and thus I see no point
> why you would want to keep it installed. The only reason would be if it was
> meant to stay around, but in that case I'm sure the source package names would
> be different.

The scenario has been described already in the thread.

> > It's also rather space-inefficient for the user.
> 
> If that bothers you, you can use the share we plan to provide.

No thanks, I like my debug symbols in a nice convenient packaged
format, signed by the archive admins.

While you might plan to be providing some fancy (yet enigmatic) service
based upon the debug deb content, I still want them installable,
preferably automatically getting all dependent debug symbols as well
using apt.  Preferably with a .deb extension; I see no reason why they
can't be first-class Debian packages in addition to being used for
mysterious as-yet-unspecified purposes.

I can't say I'm particularly enthused with the apparent lack of
consideration for most of the issues with the proposal brought up in
this thread.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
> Emilio Pozuelo Monfort  writes:
>> Roger Leigh wrote:
> 
>>> This fails to address the rather valid concern brought up about having
>>> different versions of libraries and binaries installed from the same
>>> source package.  Having one .ddeb per binary would solve this
>>> elegantly.
> 
>> Except that in that case, the old library will be NBS and thus I see no
>> point why you would want to keep it installed. The only reason would be
>> if it was meant to stay around, but in that case I'm sure the source
>> package names would be different.
> 
> Because you're trying to debug a binary on your system that's linked
> against it.

Then you should work on making your package build with the new library, since it
will be FTBFS anyway :)

I don't consider this a real issue.

>>> It's also rather space-inefficient for the user.
> 
>> If that bothers you, you can use the share we plan to provide.
> 
> I'm very curious to see more details about how this is going to work.  It
> sounds like we may need to hold off making any decisions or Policy changes
> here until the details of that system is worked out if the normal delivery
> system for the things in .ddebs won't be via package installation.

There will still be a repository with all the .ddebs. But also we will have a
share that will ship all the debugging symbols in a build id file hierarchy
structure (so something like .build-id/xx/xxx.debug). You can mount it in
your system and use it as if you had installed every -ddeb available in the
archive. Furthermore, if disk space permits it, we will provide symbols for more
than one version (i.e. not only the current package in the archive, but maybe
the last three or whatever we can do), since build ids permit it.

With this in place, we can integrate reporting tools (bug-buddy, drkonqi,
apport) to use that service to magically provide meaningful bug reports with
complete backtraces.

If you use this, you won't need to get a backtrace, realize you're missing some
symbols, install some more debug packages, rinse, repeat... :)

Hope this was clear,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Julien Cristau]

On Thu, Aug 13, 2009 at 02:58:45 +0200, Emilio Pozuelo Monfort wrote:

> If that bothers you, you can use the share we plan to provide.
> 
I'd like to still be able to debug offline, thank you very much.  So far
you've avoided answering the question, though: why one ddeb per source
instead of per binary?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Roger Leigh wrote:

>> This fails to address the rather valid concern brought up about having
>> different versions of libraries and binaries installed from the same
>> source package.  Having one .ddeb per binary would solve this
>> elegantly.

> Except that in that case, the old library will be NBS and thus I see no
> point why you would want to keep it installed. The only reason would be
> if it was meant to stay around, but in that case I'm sure the source
> package names would be different.

Because you're trying to debug a binary on your system that's linked
against it.

>> It's also rather space-inefficient for the user.

> If that bothers you, you can use the share we plan to provide.

I'm very curious to see more details about how this is going to work.  It
sounds like we may need to hold off making any decisions or Policy changes
here until the details of that system is worked out if the normal delivery
system for the things in .ddebs won't be via package installation.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Roger Leigh]

On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote:
> On Wed, 12 Aug 2009 13:03:30 +0100
> Roger Leigh  wrote:
> 
> > On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote:
> > > I'm not sure, whether a conclusion is already reached.
> > > 
> > > 1. apt-get install mysql
> > > 2. enter mysql client
> > > 3. create database test; create table test( test char(10) );
> > > 
> > > Replace mysql with whatever application you like.
> > > 
> > > What should be the encoding of database and table test in cases
> > > like the above?
> > > 
> > > Currently it's iso-something, discriminating everybody from other
> > > countries. If it would be utf-8 instead, it would have at least two
> > > advantages
> > > 
> > > - The clueless user would get a sane default
> > > - utf-8 isn't as discriminating as iso-8859-1
> > 
> > UTF-8 is the sane default choice in this situation, so long as MySQL
> > is capable of handling it.
> 
> Is that a real problem? Usually applications that use a SQL DB come
> with some script to set up the schema. If they want UTF-8, they will
> create a table with UTF-8 encoding. I wouldn't change MySQL's default
> without reason, because old scripts might rely on that behaviour.

Those "old scripts" which don't specify an encoding *are already buggy*
due to not saying what they want, implying that the default (whatever
that might be) is fine.

There's the possibility that this might cause some problems, but they
are problems in the script, not in MySQL.  Keeping using an obsolete
encoding like Latin 1 (or whatever the default currently is) prevents
any breakage, but at the expense of moving to a sane default for the
future.

> Those applications, however, should be configured to use UTF-8 by
> default (if they support it) and their DB setup scripts accordingly.

They should indeed, but if they don't then they need to explicitly
spell out what they *do* support.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Roger Leigh wrote:
> On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
>> Quantity of .ddebs:
>> Usually there should only be one .ddeb per source. Of course there are
>> always exceptions from the rule, so Maintainers may chose to have one
>> per binary package. This should only be taken when the size of the debug
>> package gets *huge* otherwise. It is hard to set definite numbers here,
>> but a 5mb package would surely not be a reason to split into two 2.5mb
>> ones.
> 
> This fails to address the rather valid concern brought up about
> having different versions of libraries and binaries installed
> from the same source package.  Having one .ddeb per binary would
> solve this elegantly.

Except that in that case, the old library will be NBS and thus I see no point
why you would want to keep it installed. The only reason would be if it was
meant to stay around, but in that case I'm sure the source package names would
be different.

> It's also rather space-inefficient for the user.

If that bothers you, you can use the share we plan to provide.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Roger Leigh]

On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> Quantity of .ddebs:
> Usually there should only be one .ddeb per source. Of course there are
> always exceptions from the rule, so Maintainers may chose to have one
> per binary package. This should only be taken when the size of the debug
> package gets *huge* otherwise. It is hard to set definite numbers here,
> but a 5mb package would surely not be a reason to split into two 2.5mb
> ones.

This fails to address the rather valid concern brought up about
having different versions of libraries and binaries installed
from the same source package.  Having one .ddeb per binary would
solve this elegantly.

It's also rather space-inefficient for the user.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Steve McIntyre]

On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote:
>
>Any thoughts? We could have such a vote over and done in about two weeks,
>with the DPL's consent, and it'd seem a lot more inclusive and less
>cabal-tastic than how things seem to be working atm...

Personally, I think the last thing we need is a GR on this front right
now. There's still discussion going on and plenty of scope for
interested people to make their feelings known. We don't need the
overhead of a GR at all that I can see.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's the use for Standards-Version?

[David Claughton]

Daniel Moerner wrote:
> On 08/12/2009 03:01 PM, David Claughton wrote:
>> Manoj Srivastava wrote:
>>> On Wed, Aug 12 2009, Neil Williams wrote:
>>>
 On Wed, 12 Aug 2009 08:16:14 -0500
 Manoj Srivastava  wrote:
   * updated Standards-Version (no changes needed)
>>> Firstly, you do not ahve to put that into the changelog, and,
>>>  secondly, one should not have to update a packagejust to up the
>>>  standards version string. I just fix local git and wait for a real
>>>  reason to update the package.
>>>
>> 
>> I would add that updating the package just to bump the version is a
>> really bad idea from the POV of the user, who gets to incur a bandwidth
>> hit to d/l a new package that is identical to his/her existing one.
>> 
>> 
> 
> I don't think that anyone was every seriously defending that people do
> uploads just to bump the Standards-Version, I think the objection was
> more that bumping the Standards-Version needlessly clutters the
> changelog and wastes space. I'll admit I don't quite understand why,
> though. It's up to the maintainer to be as verbose as he or she feels there.
> 
> Daniel
> 

Fair enough - I thought Neil was implying that this sometimes happened
but on re-reading this wasn't quite what he said ;-)

Cheers,

David.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's the use for Standards-Version?

[Russ Allbery]

Daniel Moerner  writes:

> I don't think that anyone was every seriously defending that people do
> uploads just to bump the Standards-Version, I think the objection was
> more that bumping the Standards-Version needlessly clutters the
> changelog and wastes space. I'll admit I don't quite understand why,
> though. It's up to the maintainer to be as verbose as he or she feels
> there.

Yeah, exactly.  Personally, I prefer to explicitly record in changelog the
points at which I've resynchronized my package with Policy and
double-checked that I haven't missed anything.  I don't always do that
with every upload, depending on the urgency, and it's useful to be able to
go back and see when I last did so.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's the use for Standards-Version?

[Daniel Moerner]

On 08/12/2009 03:01 PM, David Claughton wrote:
> Manoj Srivastava wrote:
>> On Wed, Aug 12 2009, Neil Williams wrote:
>>
>>> On Wed, 12 Aug 2009 08:16:14 -0500
>>> Manoj Srivastava  wrote:
>>>   * updated Standards-Version (no changes needed)
>> Firstly, you do not ahve to put that into the changelog, and,
>>  secondly, one should not have to update a packagejust to up the
>>  standards version string. I just fix local git and wait for a real
>>  reason to update the package.
>>
> 
> I would add that updating the package just to bump the version is a
> really bad idea from the POV of the user, who gets to incur a bandwidth
> hit to d/l a new package that is identical to his/her existing one.
> 
> 

I don't think that anyone was every seriously defending that people do
uploads just to bump the Standards-Version, I think the objection was
more that bumping the Standards-Version needlessly clutters the
changelog and wastes space. I'll admit I don't quite understand why,
though. It's up to the maintainer to be as verbose as he or she feels there.

Daniel



signature.asc
Description: OpenPGP digital signature

Re: What's the use for Standards-Versio n?

[David Claughton]

Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Neil Williams wrote:
> 
>> On Wed, 12 Aug 2009 08:16:14 -0500
>> Manoj Srivastava  wrote:
>>   * updated Standards-Version (no changes needed)
> 
> Firstly, you do not ahve to put that into the changelog, and,
>  secondly, one should not have to update a packagejust to up the
>  standards version string. I just fix local git and wait for a real
>  reason to update the package.
> 

I would add that updating the package just to bump the version is a
really bad idea from the POV of the user, who gets to incur a bandwidth
hit to d/l a new package that is identical to his/her existing one.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Harald Braumann]

On Wed, 12 Aug 2009 13:03:30 +0100
Roger Leigh  wrote:

> On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote:
> > I'm not sure, whether a conclusion is already reached.
> > 
> > 1. apt-get install mysql
> > 2. enter mysql client
> > 3. create database test; create table test( test char(10) );
> > 
> > Replace mysql with whatever application you like.
> > 
> > What should be the encoding of database and table test in cases
> > like the above?
> > 
> > Currently it's iso-something, discriminating everybody from other
> > countries. If it would be utf-8 instead, it would have at least two
> > advantages
> > 
> > - The clueless user would get a sane default
> > - utf-8 isn't as discriminating as iso-8859-1
> 
> UTF-8 is the sane default choice in this situation, so long as MySQL
> is capable of handling it.

Is that a real problem? Usually applications that use a SQL DB come
with some script to set up the schema. If they want UTF-8, they will
create a table with UTF-8 encoding. I wouldn't change MySQL's default
without reason, because old scripts might rely on that behaviour.

Those applications, however, should be configured to use UTF-8 by
default (if they support it) and their DB setup scripts accordingly.

Cheers,
harry


signature.asc
Description: PGP signature

Re: I want to delete an ITP

[Sandro Tosi]

Hello Leinier,
first of all, this question is more fit for debian-mentors that for
-devel, so I'm adding the list to CC (please follow up there, removing
-devel).

2009/8/12 Leinier Cruz Salfran :
> Hello.
>
> I'm creating my first package, after reading the debian policy and
> others mails in 'debian-mentors' list I want to delete the ITP Bug
> #539568 in order to create a new one with the same library but with
> other name .. How can I do that?

Well, if you only want to change the package name, simply retitle the
bug. Instructions are at [1]. Please also note that the package name
you specify in the ITP is the source package name, not the binary
one(s) (and not, the may also not correspond, in some cases).

[1] http://www.debian.org/Bugs/server-control

In case you need also to add new information, do so mailing the bug at
nn...@bugs.debian.org

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

I want to delete an ITP

[Leinier Cruz Salfran]

Hello.

I'm creating my first package, after reading the debian policy and
others mails in 'debian-mentors' list I want to delete the ITP Bug
#539568 in order to create a new one with the same library but with
other name .. How can I do that?

Thanks



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Automatic Debug Packages

[Joerg Jaspert]

On 11826 March 1977, Emilio Pozuelo Monfort wrote:

> The proposal is (very briefly) to make dak accept .ddeb packages (containing
> debugging symbols using build-ids), and to then modify helper tools to
> automatically generate them and add them to the changes file. I've written 
> down
> the details in the wiki [2], and I'll appreciate it if you could give some
> feeback. I don't want to trash this completely though, so no drastic changes
> preferred :)

What a long thread, brrr. So lets take the start message of it and reply
to a few points that have been all over in it.


First, the naming:
It is indeed us Ftpmasters who want them named .ddeb. For two reasons -
a simple one is that it makes the handling much easier, if you can match
on *.ddeb$. Another one is that they aren't "real" debs like .deb. They
aren't meant for normal user consumption, but only for special
situations. For most users possibly completly automated and
transparently in the background. Seperating them as .ddeb helps making
it clear it is "something different than what you know from usual debian
packages". More so than a -debug in the name alone.

Also, ddebs should probably be defined in policy as not having
maintainer scripts.

Additionally the naming should include a -$DEBUG, so it will be
$package-$DEBUG_$version_$arch.ddeb.
$DEBUG should be a string not otherwise used, debug would probably work
well.



Second the storage:
Archive side they will be put into the normal
directories right beside the source and other binaries from the
package. They will, however, not be exported to the public view of the
archive. Instead we will export a second directory which contains them,
which can then be mirrored seperately from mirrors that do want to have
them.

Now, as that will be a seperately exported mirror tree it leaves license
compliance (provide binaries, provide source). Thats discussable - as we
only provide debug symbols/code/whatever_funny_language_uses_for_it we
might not fall below that requirement. Most likely we ensure compliance
by having symlinks back into the normal /debian/ mirror tree of a
mirror, and requiring each mirror to only mirror this if they also have
/debian/. (This was one way the sarge amd64 archive was presented to the
mirrors. Saved some of them quite a lot of space, not needing to
duplicate the source from Debian.)


Contents of a .ddeb:
The contents of a .ddeb should strictly be limited to debugging symbols
- or whatever their equivalent is in other programming
languages/environments. No user needed/runable parts should be there.
Which will keep -dbg packages like the python interpreters in the normal
archive.
Additionally a .ddeb must either include a
/usr/share/doc/$package-$debug/ directory or a symlink to a
/usr/share/doc/$package directory of a package it depends on.



Quantity of .ddebs:
Usually there should only be one .ddeb per source. Of course there are
always exceptions from the rule, so Maintainers may chose to have one
per binary package. This should only be taken when the size of the debug
package gets *huge* otherwise. It is hard to set definite numbers here,
but a 5mb package would surely not be a reason to split into two 2.5mb
ones.


Other stuff:
Most of the other stuff is not of much concern to us.
As to how the files within ddebs should be named, this isn't an archive
side matter (although I personally favor to put files named after their
build-ids into the .ddebs).

The packages do also not need to be listed in debian/control, if they
follow the "one ddeb per source" general rule. If there are more of them
then they will need to be explicitly defined.
They do *ALL* have to appear in the .changes file uploaded.


-- 
bye, Joerg, your FTPMaster of the evening
"Hätten die Affen, von denen wir angeblich abstammen, geahnt, dass durch
die Evolution eines Tages aus Ihren Reihen Politiker entstehen würden,
wären sie auf Ihren Bäumen geblieben und hätten niemals versucht den
aufrechten Gang zu erlernen."
(J. Sheridan, Babylon5)


pgpp5E43bfWNQ.pgp
Description: PGP signature

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 14:17 -0400, Neil Roeth a écrit :
> If people don't have time to handle all their packages properly, they should
> reduce the number of packages they maintain.

I’ve seen this kind of arguments again and again, and every time it
looks more stupid to me. If you don’t have anything more interesting to
say, maybe you could consider shutting up.

It’s easy to try teaching lessons, but how about a reality check? Most
Debian developers are interested only in maintaining their pet package,
not in belonging to core teams. If what you suggest is that core teams
should abandon their packages, you can immediately start looking for a
new operating system.

> I suspect you are right, the general quality might not be up to my standards.
> However, as Manoj said, we did all sign up to maintain packages that conform
> to policy, and I think the problem you are describing is with some DDs not
> living up to their commitment rather than with the current process.

I signed up to produce the best operating system possible. And
unfortunately it doesn’t seem possible to do it with a 100 packages
archive.

> Removing
> this just makes it easier for people to be sloppy, shift work onto someone
> else, and pretend they are living up to that commitment.

Or maybe that makes it easier for people to shift work onto something
more useful.

> Why would you bump the standards version without actually checking to see if
> the package meets that standard?  That's worse than leaving it as it was.  I
> trust myself to make a conscientious effort to do it correctly if I choose to
> do it at all, but I no longer trust you.

I’m glad to learn that I can trust you to correctly put numbers in your
control files.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Bits from the release team and request for discussion

[Raphael Hertzog]

On Tue, 11 Aug 2009, Matthew Johnson wrote:
> On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
> > Personally I don't think we should do a GR to recommend a freeze or release 
> > date.
> > We already used the DPL election to push a release, when it was *long* due, 
> > but
> > I don't think we should push a freeze.
> 
> Zack has been patching devotee to allow more informal (and not at all
> binding) polls to be run with the same infrastructure. I think this
> could be a suitable candidate to run using that. It allows us to have a
> poll which can only be voted in by DDs and not easily stuffed, but
> without having to go through the pain of a formal resolution.

I would like to see such a poll as well.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Russ Allbery]

Neil Williams  writes:

> In which case all we need is the existing lintian check and for
> Standards-Version to be ignored by dpkg-dev so that it doesn't get into
> the .dsc, it doesn't get into the Sources.gz and it is finally OK to get
> rid of all these pointless messages in debian/changelog.gz:
>
>   * updated Standards-Version (no changes needed)

If you don't want to put that in your changelog, don't.  I consider it
something I want to document in my packages, so I do.  I would continue
doing so even if it were an optional field (although I am completely
opposed to making it optional).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Russ Allbery]

Emilio Pozuelo Monfort  writes:

> I'd be in favour of making it optional or deprecating it if we (as in
> the project) were good in adding checks to lintian for changes in the
> policy or reporting bugs where it's not possible (or in addition to the
> checks).

I already attempt to add checks to Lintian for everything that goes into
each new release of Policy.  Unfortunately, there are severe limitations
in what's possible in an automated checking tool.  There are a *lot* of
changes to Policy that are just infeasible for Lintian to check, at least
without considerable development work in hard and difficult areas, such as
parsing and understanding arbitrary shell code.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Neil Roeth]

On Aug 12, Josselin Mouette (j...@debian.org) wrote:
 > Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit : 
 > > I've had some packages for years during which policy was changed and 
 > > required
 > > corresponding changes in my packages. In that case, the "previous 
 > > developer"
 > > was me, so I'm pretty confident that the previous developer did at least as
 > > good a job as the current developer. :-)
 > > 
 > > Your statement is a broad indictment of your fellow DDs as incompetent
 > > developers who cannot perform the simple task of reading a few lines of 
 > > policy
 > > changes and determine if they imply any required changes for their 
 > > packages.
 > > Oh, well, it's your life, make all the enemies you want.
 > 
 > When you only work on 6 packages for which you do a pretty good job, you
 > tend to assume that other packages in the archive are maintained the
 > same way. Well here’s a scoop, a lot of packages in the archive belong
 > to maintainers with hundreds of them in their hands, whether alone or in
 > teams. Not all packages can receive the level of attention you are
 > expecting.

You weren't saying people don't have time to give them attention, you were
saying they were incompetently making the changes.  That's a different
argument and the one to which I responded.

If people don't have time to handle all their packages properly, they should
reduce the number of packages they maintain.  I don't work on more packages
precisely because I know my DD time is limited and there is a minimum level of
attention that I think is required for each. I find the standards version and
upgrading checklist combo to be a net time saver.

 > Try going through large parts of the archive when you need to test a
 > change, for example. You may be surprised with the overall quality
 > you’ll meet. After that, you may change your mind about expecting a
 > declarative field to be conformant with the rest of the packaging.

I suspect you are right, the general quality might not be up to my standards.
However, as Manoj said, we did all sign up to maintain packages that conform
to policy, and I think the problem you are describing is with some DDs not
living up to their commitment rather than with the current process.  Removing
this just makes it easier for people to be sloppy, shift work onto someone
else, and pretend they are living up to that commitment.

 > Heck, I wouldn’t even trust *myself* to do that correctly. Bumping the
 > standards version is a boring task I have to do so much that I never
 > bother to have a look at the upgrading checklist, except for the most
 > complex packages.

Why would you bump the standards version without actually checking to see if
the package meets that standard?  That's worse than leaving it as it was.  I
trust myself to make a conscientious effort to do it correctly if I choose to
do it at all, but I no longer trust you.

 > > > This also assumes that the upgrading checklist contains all relevant
 > >  > information, which is also wrong for real cases.
 > > 
 > > Even if it contains most of the relevant information, it is useful.  If 
 > > there
 > > is something missing, that's when someone filing a bug can be a backup.
 > > No need to throw out the baby with the bath water.
 > > 
 > > BTW, I just glanced at the debian-policy bug page and see none related to 
 > > the
 > > upgrading checklist.  Can you provide some bug numbers of those "real 
 > > cases"
 > > of missing information so I can check my packages?  No hurry, if you've 
 > > just
 > > neglected to file them, do that first, then let me know.  Thanks.
 > 
 > I’m not implying the upgrading checklist itself is incomplete.

I don't see any semantic difference between "the upgrading checklist is
incomplete" and "This also assumes that the upgrading checklist contains all
relevant information, which is also wrong for real cases".

 > But there
 > are other things in Debian than following the policy, you know? Most of
 > the changes needed in packages are not here because of changes in the
 > policy itself, but because of changes in other packages: packaging
 > helpers, toolchain, menu system, various pieces of low-level plumbing
 > that upstream redesigns every other month… these are the things that
 > require attention. Not looking at whether the package is using the
 > Speedo fonts.

Yes, so go ahead and leave it at the last version it complied with and wait
for the RC bugs.  Just don't do more damage by changing it without making the
corresponding changes.

 > > If there are current bugs, sure, you should attack those first. But you're
 > > making a stronger argument that because the workflow is not bulletproof, 
 > > that
 > > invalidates the whole process and it should be discarded.  I disagree, I 
 > > find
 > > it very useful and hope we keep it.
 > 
 > It may be useful for you, but it is being an annoyance for others. The
 > suitable thing to do in such cases would be to make the fie

Re: What’s the use for Standards-Version?

[Russ Allbery]

Josselin Mouette  writes:

> This assumes that the previous developer has correctly updated the
> package according to the stated Standards version. Which is, in the
> general case, wrong.

No, it assumes that the previous developer tried to update the package
according to the stated standards version, which in my experience is
correct.  They may still have bugs -- bugs happen.  But it means that the
older stuff is just bugs they missed, and hence falls into the less common
category of bugs missed by at least one person, instead of the new stuff
that one knows from standards-version the maintainer had never even looked
at.

> This also assumes that the upgrading checklist contains all relevant
> information, which is also wrong for real cases.

Please report bugs against Policy if you see missing things in
upgrading-checklist and I will add them.  Note, though, that the file is
intended to give you an idea, from reading the entry, whether you need to
go re-read that section of Policy, not to be a substitute for re-reading.

> If you want to bring a random package up-to-date with the policy, it is
> generally more useful to look at its RC bugs, and also at its other
> bugs.

Sure, and in practice it's even more useful to look at Lintian, but both
of those miss things, sometimes a lot of things.  Having a pointer into
upgrading-checklist is also very useful.

> Said otherwise, with the current state of our practice, the workflow you
> describe is flawed. Which makes the standards version declaration
> useless.

I *completely* disagree.  Manoj speaks for me on this one.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541245: ITP: WorldVistA EHR -- WorldVistA EHR is a repackage and extended version of VistA produced by WorldVistA

[K.S. Bhaskar]

Package: wnpp
Severity: wishlist
Owner: "K.S. Bhaskar" 


* Package name: WorldVistA EHR
  Version : VOE/ 1.0
  Upstream Author : K.S. Bhaskar 
* URL : http://worldvista.org/World_VistA_EHR
* License : GPL v2
  Programming Lang: MUMPS
  Description : WorldVistA EHR is a repackage and extended version of VistA 
produced by WorldVistA

Developed by WorldVistA (http://worldvista.org) and released under GPL
v2, WorldVistA EHR is a repackaged and extended version of the VistA
health care information system (HIS) developed by the US Department of
Veterans Affairs, and in the public domain through the US Freedom of
Information Act.

WorldVistA successfully submitted WorldVistA EHR for certification by
CCHIT (http://cchit.org) in 2007.  WorldVistA EHR VOE/ 1.0 was tested
and passed inspection of 100 percent of a set of criteria for
functionality (ability to create and manage electronic records for all
patients, as well as automating workflow in a physician's office),
interoperability (a first step in the ability to receive and send
electronic data to other entities such as laboratories), and security
(ability to keep patients' information safe).

Note: Downloading and installing the software is not sufficient and
does *not* grant permission to make claim of CCHIT
certification. Contact WorldVistA to discuss certification.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541242: ITP: VistA -- Real time health care information system including electronic health record

[K.S. Bhaskar]

Package: wnpp
Severity: wishlist
Owner: "K.S. Bhaskar" 


* Package name: VistA
  Version : To be determined
  Upstream Author : K.S. Bhaskar 
* URL : http://worldvista.org/AboutVistA
* License : Public domain, GPL v2, AGPL v3
  Programming Lang: MUMPS
  Description : Real time health care information system including 
electronic health record

VistA is the complete health care information system (HIS) which is
developed and used by the US Department of Veterans Affairs to run all
of its hospitals and clinics.  It is in the public domain through the
US Freedom of Information Act.  Versions are also in use both in the
US and internationally, including the US Department of Defense, the US
Indian Health Service, the Mexican Instituto Mexicano del Seguro
Social, etc.  There are also flavors of VistA provided by WorldVistA
(http://worldvista.org) and Medsphere (http://medsphere.org).

I intend to create a VistA meta package that can be satisfied by other
packages, such as WorldVistA EHR or OpenVista.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541239: ITP: GT.M -- Database Engine with Extreme Scalability and Robustness

[K.S. Bhaskar]

Package: wnpp
Severity: wishlist
Owner: "K.S. Bhaskar" 


* Package name: GT.M
  Version : V5.3-004A
  Upstream Author : K.S. Bhaskar 
* URL : http://fis-gtm.com
* License : AGPL v3
  Programming Lang: C with some modules in x86 assembly language
  Description : Database Engine with Extreme Scalability and Robustness

 GT.M is a database engine with scalability proven in large real-time
 transaction processing systems that have thousands of concurrent
 users, individual database file sizes to the Terabyte range (with
 virtually unlimited aggregate database sizes).  Yet the light
 footprint of GT.M allows it to also scale down for use in small
 applications and software appliances (virtual machines).
 
 The GT.M data model is hierarchical associative memory (i.e.,
 multi-dimensional array) that imposes no restrictions on the data
 types of the indexes or content - the application logic can impose
 any schema, dictionary or data organization suited to its problem
 domain.  (Database engines that do not impose schemas, but which
 allow layered application software to impose and use whatever schema
 that is appropriate to the application are popularly referred to as
 "document oriented", "schemaless" or "schema-free" databases.)
 
 GT.M's compiler for the standard M (also known as MUMPS) scripting
 language implements full support for ACID (Atomic, Consistent,
 Isolated, Durable) transactions, using optimistic concurrency control
 and software transactional memory (STM) that resolves the common
 mismatch between databases and programming languages. Its unique
 ability to create and deploy logical multi-site configurations of
 applications provides unrivaled continuity of business in the face of
 not just unplanned events, but also planned events, including planned
 events that include changes to application logic and schema.
 
 Community support forums for GT.M can be found at
 http://sourceforge.net/projects/fis-gtm and support with assured
 service levels on commercial terms can be purchased from
 gtmsupp...@fnis.com.


-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Raphael Hertzog]

On Wed, 12 Aug 2009, Manoj Srivastava wrote:
> I do not have a strong opinion about this, apart from the fact
>  that it must be present in the sources when someone is looking to
>  update the package, and it should be accessible before downloading all
>  the sources. So having it in the diff.gz and PTS would be good enough.

The PTS gets it from Sources.gz so removing it is not really an option.

> I also do not see much of a downside in letting current practice
>  be -- what are the things I am missing?

Me neither. It's probably some size reduction affinity that Neil has due
to his emdebian involvment... but I think it's diverging from the topic of
this thread.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version ?

[Emilio Pozuelo Monfort]

Josselin Mouette wrote:
> Hi,
> 
> the question in the subject may sound a bit naive, but I’m starting to
> wonder why we still set the Standards-Version in package control files.
> 
> AIUI, this header is here to indicate which version of the policy the
> package is supposed to conform to. This way, we have a way to enforce
> which policy versions are supported, e.g. in a stable release, by
> forbidding the too old versions.
> 
> However I think this approach doesn’t fit the current way we deal with
> policy changes. The de facto way of dealing with policy breakages
> currently is to directly report serious bugs against packages not
> conforming, regardless of the Standards-Version they declare. We will
> even often NMU them without changing the Standards-Version, while having
> actually fixed them to conform to newer versions.
> 
> Currently I don’t think this header reflects anything useful in a vast
> majority of our packages. I’m spending more time updating the header
> than actually updating old packages to conform to policy changes.
> 
> What would you think of deprecating this header?

I'd be in favour of making it optional or deprecating it if we (as in the
project) were good in adding checks to lintian for changes in the policy or
reporting bugs where it's not possible (or in addition to the checks). Then,
checking upgrade-checklist wouldn't be necessary, and S-V wouldn't have any
sense (at least to me as I use it to check upgrade-checklist since the version
specified in S-V).

Also checking upgrade-checklist is time consuming, usually for no benefit (we
all see those "Update Standards-Version, no changes needed"). So right now it's
like if I was lintian and had to run those checks manually. So moving them from
upgrade-checklist to lintian itself, or to the bts would be very welcome.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit : 
> I've had some packages for years during which policy was changed and required
> corresponding changes in my packages. In that case, the "previous developer"
> was me, so I'm pretty confident that the previous developer did at least as
> good a job as the current developer. :-)
> 
> Your statement is a broad indictment of your fellow DDs as incompetent
> developers who cannot perform the simple task of reading a few lines of policy
> changes and determine if they imply any required changes for their packages.
> Oh, well, it's your life, make all the enemies you want.

When you only work on 6 packages for which you do a pretty good job, you
tend to assume that other packages in the archive are maintained the
same way. Well here’s a scoop, a lot of packages in the archive belong
to maintainers with hundreds of them in their hands, whether alone or in
teams. Not all packages can receive the level of attention you are
expecting.

Try going through large parts of the archive when you need to test a
change, for example. You may be surprised with the overall quality
you’ll meet. After that, you may change your mind about expecting a
declarative field to be conformant with the rest of the packaging.

Heck, I wouldn’t even trust *myself* to do that correctly. Bumping the
standards version is a boring task I have to do so much that I never
bother to have a look at the upgrading checklist, except for the most
complex packages.

> > This also assumes that the upgrading checklist contains all relevant
>  > information, which is also wrong for real cases.
> 
> Even if it contains most of the relevant information, it is useful.  If there
> is something missing, that's when someone filing a bug can be a backup.
> No need to throw out the baby with the bath water.
> 
> BTW, I just glanced at the debian-policy bug page and see none related to the
> upgrading checklist.  Can you provide some bug numbers of those "real cases"
> of missing information so I can check my packages?  No hurry, if you've just
> neglected to file them, do that first, then let me know.  Thanks.

I’m not implying the upgrading checklist itself is incomplete. But there
are other things in Debian than following the policy, you know? Most of
the changes needed in packages are not here because of changes in the
policy itself, but because of changes in other packages: packaging
helpers, toolchain, menu system, various pieces of low-level plumbing
that upstream redesigns every other month… these are the things that
require attention. Not looking at whether the package is using the
Speedo fonts.

> If there are current bugs, sure, you should attack those first. But you're
> making a stronger argument that because the workflow is not bulletproof, that
> invalidates the whole process and it should be discarded.  I disagree, I find
> it very useful and hope we keep it.

It may be useful for you, but it is being an annoyance for others. The
suitable thing to do in such cases would be to make the field optional.
Would that be OK?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Bug#541223: ITP: libtext-dhcpleases-perl -- libtext-dhcpleases-perl -- an object-oriented interface to ISC DHCPD leases files

[Javier Uruen Val]

Package: wnpp
Severity: wishlist
Owner: Javier Uruen Val 


* Package name: libtext-dhcpleases-perl
  Version : 0.9
  Upstream Author : Carlos Vicente  
* URL : http://search.cpan.org/dist/Text-DHCPLeases/
* License : (Perl Artistic)
  Programming Lang: (Perl)
  Description : libtext-dhcpleases-perl -- an object-oriented interface to 
ISC DHCPD leases files

Text::DHCPLeases provides an object-oriented interface to ISC DHCPD leases 
files.
The goal is to objectify all declarations, as defined by the ISC dhcpd package
man pages.

This interface is useful for analyzing, reporting, converting lease files,
or as a tool for other applications that need to import dhcpd lease data
estructures.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Roger Leigh wrote:

> On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote:
>> On Wed, Aug 12 2009, Neil Williams wrote:
>> 
>> > On Wed, 12 Aug 2009 08:22:17 -0500
>> > Manoj Srivastava  wrote:
>> >
>> >> > In many cases, wouldn't such a relationship be better expressed by a
>> >> > dependency on a package that implemented the new behaviour? Often it's
>> >> > dpkg and many of those situations are already handled via just such a
>> >> > dependency. So why have the extra field?
>> >> 
>> >> Because not all new policy changes are reflected by a new
>> >>  version of some package? And for  Developer picking up a package and
>> >>  wanting to know what needs to be looked at in order to achieve policy
>> >>  compliance, a mess of possible dependency relationships is a lot harder
>> >>  to base that decision on than a simple standards version.
>> >
>> > OK, so if it's mainly for the benefit of the (next) maintainer, why not
>> > leave the field in debian/ but not put it into the Sources.gz file and
>> > not make an issue of it if it is out of date? ould be a comment in
>> > debian/rules.
>> 
>> I do not have a strong opinion about this, apart from the fact
>>  that it must be present in the sources when someone is looking to
>>  update the package, and it should be accessible before downloading all
>>  the sources. So having it in the diff.gz and PTS would be good enough.
>
> The only /real/ use for the standards version is using it as a starting
> point for upgrading to the current standards version, and that's already
> making the (rather naïve) assumption that it was already fully conforming
> with Policy to begin with.

I donot think it is a naive assumption at all. The commohn case
 with most package uploads is that the previous maintainer is the
 current maintainer. Usually, I try to make sure that my package is
 policy compliant (don't we all? we signed up for it). Then I see what
 has changed in policy since then, and try to ensure that the package
 still complies with policy.

Now, I can still make mistakes, and leave room for others to
 notice and file bugs, but the primary process is still to look at
 policy and proactively fix policy related bts, not wait for people to
 find them for me and file bugs.

Minimizing the reading I need to do (by checking what has
 changed in policy since I last checked policy) is a nice, useful
 optimization.

>> I also do not see much of a downside in letting current practice
>>  be -- what are the things I am missing?
>
> For most packages, it's typically the case that a new version of Policy
> requires no package changes, yet one needs to trawl through the changes
> in the upgrading checklist and then update the version number in the
> control file.  Basically busy-work with no actual benefit; it's just
> pointless make-work for the maintainer.

Keeping packages policy compliant is one of the tasks that
 maintainers must do -- apart from the trawling through
 copyrights, making sure all configuration files live in /etc -- comes
 with the territory.


> We have an automated method for checking Policy compliance: lintian.
> I'd far prefer that Policy transgressions were reported first and
> foremost by lintian rather than requiring manual (and potentially
> less reliable) checking by the maintainer.  Rather than depending
> upon the maintainer's diligence, Policy conformance would then be
> assessed by automated checking than the presence of a number, which
> is of potentially unreliable provenance in the first place.

Lintian does not provide full coverage, and it can't. Some
 policy dictums do not have a lintian check. Looking over the policy
 changes seems like a decent addendum. By all means run lintian, but
 nothing actually beats a human paying attention. Quality of
 implementation improves. Deban developers ought to be acting like they
 could be replaced by a small script (a t shirt I own).


manoj

-- 
"I think there is a world market for maybe five computers." Thomas
Watson, chairman of IBM, 1943
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#540365: ITP: turnin-ng -- Assignment submitter and manager

[Guillem Jover]

On Sun, 2009-08-09 at 16:40:44 -0400, Ryan Kavanagh wrote:
> On Sun, Aug 09, 2009 at 05:23:43PM +0200, Guillem Jover wrote:
> > I hope the packages uploaded won't have a «project» binary in the
> > PATH?
> 
> At the moment yes, Turnin-NG provides /usr/bin/project since that's what the
> original turnin / project app provided. However, I can either:
>  1) Rename the project script to something else upstream.
>  2) Rename it in the Debian package and add a note to README.Debian.
> 
> I'm not sure which I prefer. #1 has the advantage of being consistent across 
> all
> distributions. #2 makes it so that if someone else wants to move away from 
> SPARC
> and use Turnin-NG as a direct replacement for their old binaries, they can.
> 
> What do you think?

I'd rename it upstream, less troubles for everyone. It's of course
unfortunate that the original program was named like that, but I don't
think continuing to take over such generic name is good in general. You
could still document that in the Description, and README.Debian maybe
also including a recipe for sites that might want to create for example
a compat symlink under /usr/local for transitional purposes, or something
to that effect.

For the upstream part you could also do a slow transition, provide a
«project» wrapper that prints a warning on stderr notifying the user
about it being obsolete and pointing to the new name, the executing
the actual program. The wrapper could be shipped for a period of time
before complete removal, and installed only if enabled via some
configure flag (or make target, as in “make install-obsolete”). Or
just document the rename.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Steve Langasek]

On Wed, Aug 12, 2009 at 04:36:23PM +0100, Roger Leigh wrote:
> The only /real/ use for the standards version is using it as a starting
> point for upgrading to the current standards version, and that's already
> making the (rather naïve) assumption that it was already fully conforming
> with Policy to begin with.

All it is is a bookmark into the policy upgrade-checklist - and it's a
useful bookmark to have.  It doesn't imply any assumptions about full Policy
compliance.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Guillem Jover]

Hi!

On Tue, 2009-08-11 at 13:03:13 -0700, Russ Allbery wrote:
> Open questions:

> * Can we require a one-to-one correspondance between binary package names
>   and debug package names that provide symbols for that binary package?  I
>   think we should; I think it would make the system more straightforward.

Being able to debug your system with a mixture of applications using an
old and new shared library coming from the same source package for which
the soversion got bumped is pretty helpful, w/o needing to downgrade the
whole debugging package every time one wants to debug applications
using either.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’ s the use for Standards-Version?

[Roger Leigh]

On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Neil Williams wrote:
> 
> > On Wed, 12 Aug 2009 08:22:17 -0500
> > Manoj Srivastava  wrote:
> >
> >> > In many cases, wouldn't such a relationship be better expressed by a
> >> > dependency on a package that implemented the new behaviour? Often it's
> >> > dpkg and many of those situations are already handled via just such a
> >> > dependency. So why have the extra field?
> >> 
> >> Because not all new policy changes are reflected by a new
> >>  version of some package? And for  Developer picking up a package and
> >>  wanting to know what needs to be looked at in order to achieve policy
> >>  compliance, a mess of possible dependency relationships is a lot harder
> >>  to base that decision on than a simple standards version.
> >
> > OK, so if it's mainly for the benefit of the (next) maintainer, why not
> > leave the field in debian/ but not put it into the Sources.gz file and
> > not make an issue of it if it is out of date? ould be a comment in
> > debian/rules.
> 
> I do not have a strong opinion about this, apart from the fact
>  that it must be present in the sources when someone is looking to
>  update the package, and it should be accessible before downloading all
>  the sources. So having it in the diff.gz and PTS would be good enough.

The only /real/ use for the standards version is using it as a starting
point for upgrading to the current standards version, and that's already
making the (rather naïve) assumption that it was already fully conforming
with Policy to begin with.

> I also do not see much of a downside in letting current practice
>  be -- what are the things I am missing?

For most packages, it's typically the case that a new version of Policy
requires no package changes, yet one needs to trawl through the changes
in the upgrading checklist and then update the version number in the
control file.  Basically busy-work with no actual benefit; it's just
pointless make-work for the maintainer.

We have an automated method for checking Policy compliance: lintian.
I'd far prefer that Policy transgressions were reported first and
foremost by lintian rather than requiring manual (and potentially
less reliable) checking by the maintainer.  Rather than depending
upon the maintainer's diligence, Policy conformance would then be
assessed by automated checking than the presence of a number, which
is of potentially unreliable provenance in the first place.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Neil Williams wrote:

> On Wed, 12 Aug 2009 08:22:17 -0500
> Manoj Srivastava  wrote:
>
>> > In many cases, wouldn't such a relationship be better expressed by a
>> > dependency on a package that implemented the new behaviour? Often it's
>> > dpkg and many of those situations are already handled via just such a
>> > dependency. So why have the extra field?
>> 
>> Because not all new policy changes are reflected by a new
>>  version of some package? And for  Developer picking up a package and
>>  wanting to know what needs to be looked at in order to achieve policy
>>  compliance, a mess of possible dependency relationships is a lot harder
>>  to base that decision on than a simple standards version.
>
> OK, so if it's mainly for the benefit of the (next) maintainer, why not
> leave the field in debian/ but not put it into the Sources.gz file and
> not make an issue of it if it is out of date? ould be a comment in
> debian/rules.

I do not have a strong opinion about this, apart from the fact
 that it must be present in the sources when someone is looking to
 update the package, and it should be accessible before downloading all
 the sources. So having it in the diff.gz and PTS would be good enough.

I also do not see much of a downside in letting current practice
 be -- what are the things I am missing?

manoj
-- 
A businessman is a hybrid of a dancer and a calculator. Paul Valery
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Neil Williams wrote:

> On Wed, 12 Aug 2009 08:16:14 -0500
> Manoj Srivastava  wrote:
>
>> > What would you think of deprecating this header?
>> 
>> This would be bad, since when someone looks at the package, they
>>  would not know easily what they have to look for to update the
>>  package. The Standards Version gives a pointer into the upgrading
>>  checklist, and that remains useful.
>
> In which case all we need is the existing lintian check and for
> Standards-Version to be ignored by dpkg-dev so that it doesn't get into
> the .dsc, it doesn't get into the Sources.gz and it is finally OK to
> get rid of all these pointless messages in debian/changelog.gz:
>
>   * updated Standards-Version (no changes needed)

Firstly, you do not ahve to put that into the changelog, and,
 secondly, one should not have to update a packagejust to up the
 standards version string. I just fix local git and wait for a real
 reason to update the package.

This way, I see no reason for it not to be in the Sources.gz,
 though making it easy to get to the standards version when
 contemplating taking a package over or doing and NMU would work too.

> If people really want a way of scanning the Standards-Version from
> outside the source, it could be added as a field in the PTS, reading
> from the .diff.gz.

That would work.

manoj
-- 
Uneven economic and political development is an absolute law of
capitalism. Nicolai Lenin
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Neil Roeth]

On Aug 12, Josselin Mouette (j...@debian.org) wrote:
 > Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :
 > > > AIUI, this header is here to indicate which version of the policy the
 > > > package is supposed to conform to. This way, we have a way to enforce
 > > > which policy versions are supported, e.g. in a stable release, by
 > > > forbidding the too old versions.
 > > 
 > > No, that is wrong. The reason we put in the Standards version is
 > >  to let the next developer know what to look for in the upgrading
 > >  checklist in policy in order to bring the package up to date with policy
 > 
 > This assumes that the previous developer has correctly updated the
 > package according to the stated Standards version. Which is, in the
 > general case, wrong.

I've had some packages for years during which policy was changed and required
corresponding changes in my packages. In that case, the "previous developer"
was me, so I'm pretty confident that the previous developer did at least as
good a job as the current developer. :-)

Your statement is a broad indictment of your fellow DDs as incompetent
developers who cannot perform the simple task of reading a few lines of policy
changes and determine if they imply any required changes for their packages.
Oh, well, it's your life, make all the enemies you want.

 > This also assumes that the upgrading checklist contains all relevant
 > information, which is also wrong for real cases.

Even if it contains most of the relevant information, it is useful.  If there
is something missing, that's when someone filing a bug can be a backup.
No need to throw out the baby with the bath water.

BTW, I just glanced at the debian-policy bug page and see none related to the
upgrading checklist.  Can you provide some bug numbers of those "real cases"
of missing information so I can check my packages?  No hurry, if you've just
neglected to file them, do that first, then let me know.  Thanks.

 > If you want to bring a random package up-to-date with the policy, it is
 > generally more useful to look at its RC bugs, and also at its other
 > bugs.
 > 
 > Said otherwise, with the current state of our practice, the workflow you
 > describe is flawed. Which makes the standards version declaration
 > useless.

If there are current bugs, sure, you should attack those first. But you're
making a stronger argument that because the workflow is not bulletproof, that
invalidates the whole process and it should be discarded.  I disagree, I find
it very useful and hope we keep it.

 > 
 > -- 
 >  .''`.  Josselin Mouette
 > : :' :
 > `. `'   “I recommend you to learn English in hope that you in
 >   `- future understand things”  -- Jörg Schilling

-- 
Neil Roeth


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Paul Wise]

On Wed, Aug 12, 2009 at 10:33 PM, Neil Williams wrote:
> On Wed, 12 Aug 2009 08:16:14 -0500
> Manoj Srivastava  wrote:
>
>> > What would you think of deprecating this header?
>>
>>         This would be bad, since when someone looks at the package, they
>>  would not know easily what they have to look for to update the
>>  package. The Standards Version gives a pointer into the upgrading
>>  checklist, and that remains useful.
>
> In which case all we need is the existing lintian check and for
> Standards-Version to be ignored by dpkg-dev so that it doesn't get into
> the .dsc, it doesn't get into the Sources.gz and it is finally OK to
> get rid of all these pointless messages in debian/changelog.gz:
>
>  * updated Standards-Version (no changes needed)
>
> If people really want a way of scanning the Standards-Version from
> outside the source, it could be added as a field in the PTS, reading
> from the .diff.gz.

IIRC, there is a plan for splitting Descriptions out of the Packages
files, so Standards-Version could get a similar treatment.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Remove control field Conflicts if the package is no longer in the repository

[Timur Birsh]

Hi,

Giacomo A. Catenazzi wrote:

>>> I think that as long as the package (cdgrab, in this case) is
>>>  not longer in stable, the conflicts line may be removed (we support
>>>  partial upgrades from stable, as far as is possible). In this case,
>>>  apparently cdgrab is not anywhere, so the conflicts line may go.
>> 
>> Really it is still in the archive, but with an other name.
>> So I see two options:
>> - replace cdgrab (<< 0.7) with abcde (<< 0.7)
> 
> Oops. This is a stupid option because abcde (<< 0.7) never existed.
> Sorry for the noise

OK. Thanks a lot.

-- 
Timur


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Josselin Mouette wrote:

> Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :
>> > AIUI, this header is here to indicate which version of the policy the
>> > package is supposed to conform to. This way, we have a way to enforce
>> > which policy versions are supported, e.g. in a stable release, by
>> > forbidding the too old versions.
>> 
>> No, that is wrong. The reason we put in the Standards version is
>>  to let the next developer know what to look for in the upgrading
>>  checklist in policy in order to bring the package up to date with policy
>
> This assumes that the previous developer has correctly updated the
> package according to the stated Standards version. Which is, in the
> general case, wrong.

Firstly, when you update a package, the previous maintainer
 could have done all kinds of things wrong. If you do not trust the
 maintainer, you check. The chances are that they did not update the
 standards version, so youhave more checking to do from upgrading
 checklist. More work for you, but no other downside. If you think the
 maintainer was malicious, and updated the standards version without
 making changes to the package, you are stuck with a full review of
 policy and the package. And report the maintainer.

If you think the majority of the maintainers upo blindly
 upgrading the standards version and not the package, we need to do some
 maintainer purging.

In my experience, the packages I have worked with, the standards
 version has not been upgraded without the package itself.


> This also assumes that the upgrading checklist contains all relevant
> information, which is also wrong for real cases.

Frankly, if you think that upgrading checklist does not contain
 everything relevant a maintainer has to check for the policy update in
 question, this is a bug, and I do not se that you have filed any. And
 can you point to  a concrete case, please? Which policy upgrade came
 with a deficient upgrading checklist?

> If you want to bring a random package up-to-date with the policy, it is
> generally more useful to look at its RC bugs, and also at its other
> bugs.

Heh. You have a far greater faith in people discovering and
 filing RC bugs. Lookgin at RC bugs  is of course a necessary, but not,
 in my opinion, a sufficient, condition for bringing the package up to
 date. If a maintainer are not looking at the standards version, then
 the packages they maintain are suspect.

> Said otherwise, with the current state of our practice, the workflow you
> describe is flawed. Which makes the standards version declaration
> useless.

I beg to differ. The standards version is a useful tool for
 people who follow the (simple) rules, and just because there are lazy
 (and perhaps malicious) maintainers out there does not mean the
 work-flow is broken.

I hope that the majority of developers are not as lazy,
 incompetent, or malicious as you imply, and do not update the standards
 version without actually updating the packages in question.

manoj
-- 
Bachelor: A guy who is footloose and fiancee-free.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Neil Williams]

On Wed, 12 Aug 2009 08:16:14 -0500
Manoj Srivastava  wrote:

> > What would you think of deprecating this header?
> 
> This would be bad, since when someone looks at the package, they
>  would not know easily what they have to look for to update the
>  package. The Standards Version gives a pointer into the upgrading
>  checklist, and that remains useful.

In which case all we need is the existing lintian check and for
Standards-Version to be ignored by dpkg-dev so that it doesn't get into
the .dsc, it doesn't get into the Sources.gz and it is finally OK to
get rid of all these pointless messages in debian/changelog.gz:

  * updated Standards-Version (no changes needed)

If people really want a way of scanning the Standards-Version from
outside the source, it could be added as a field in the PTS, reading
from the .diff.gz.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp8Ki8d9QoTO.pgp
Description: PGP signature

Re: What’s the use for Standards-Version?

[Neil Williams]

On Wed, 12 Aug 2009 08:22:17 -0500
Manoj Srivastava  wrote:

> > In many cases, wouldn't such a relationship be better expressed by a
> > dependency on a package that implemented the new behaviour? Often it's
> > dpkg and many of those situations are already handled via just such a
> > dependency. So why have the extra field?
> 
> Because not all new policy changes are reflected by a new
>  version of some package? And for  Developer picking up a package and
>  wanting to know what needs to be looked at in order to achieve policy
>  compliance, a mess of possible dependency relationships is a lot harder
>  to base that decision on than a simple standards version.

OK, so if it's mainly for the benefit of the (next) maintainer, why not
leave the field in debian/ but not put it into the Sources.gz file and
not make an issue of it if it is out of date? It could be a comment in
debian/rules.

It's beginning to sound that it is neither more nor less important than
the year of the copyright stamp in debian/copyright or whether a
package uses CVS, SVN or git. i.e. it is a feature of the packaging and
not much else.

If Standards-Version is only useful for developers picking up a new
package, why does that data ever have to be copied into the archive
files? It's better just as a part of the .diff.gz - almost as if it was
a file like debian/compat.

> > Also, for Standards-Version: to be useful again, wouldn't it be
> > appropriate for lintian to have support for testing the package against
> > the *declared* standards version? I doubt that this would be
> > particularly welcome or easy to implement, hence I agree that the field
> > itself is becoming irrelevant. Yes, we can test with the version of
> 
> That would be wrong. A Standards version has nothing to do with
>  deciding whether or not a package is buggy WRT policy.  If it does not
>  match current policy, the package is buggy, period.  Even if the
>  mainteiner has cleverly set the standards version to 0.0.0.

So all packages are only tested against Policy as it is at the moment
that the test is considered.

Fine, so again, what is the point of having Standards-Version: in the
Sources.gz file?

What is the point of complaining that it is out of date when the only
version of Policy that matters is the latest one anyway?
 
> The standards version is not a means of getting out of meeting
>  policy. 

Then what is the point of the field at all?
 
> From a Project point of view, it is useful to see if a package
>  in the archive meets current policy, not whether it met policy when the
>  standards version was last touched (and encourage people to not change
>  the standards version or follow policy). So assuming there is a
>  relation between bugginess and standards version is wrong; the latter
>  is only useful for people trying to update the package, so that they
>  know what to look for.

In which case, I don't see why it needs to be preserved into the
archive meta-data - it can just be left in the .diff.gz
somewhere as a comment or left in the .changes file for the PTS to
pick up on.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpnh4KdWZxRl.pgp
Description: PGP signature

Re: What’s the use for Standards-Version ?

[Giacomo A. Catenazzi]

Josselin Mouette wrote:

Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :

AIUI, this header is here to indicate which version of the policy the
package is supposed to conform to. This way, we have a way to enforce
which policy versions are supported, e.g. in a stable release, by
forbidding the too old versions.

No, that is wrong. The reason we put in the Standards version is
 to let the next developer know what to look for in the upgrading
 checklist in policy in order to bring the package up to date with policy


This assumes that the previous developer has correctly updated the
package according to the stated Standards version. Which is, in the
general case, wrong.


8-/

Why will developers update standard version, if they don't update the
package? As shown by codehelp, a lot of package declare old policies.

If this is the common case, we have a real problem on developer side.



This also assumes that the upgrading checklist contains all relevant
information, which is also wrong for real cases.

If you want to bring a random package up-to-date with the policy, it is
generally more useful to look at its RC bugs, and also at its other
bugs.


Bugs happens, so standard version doesn't mean "no RC bugs according
polixy x.y.z".  But we must correct packages before user will file a
RC bug. And I think few policy-induced RC bugs are discovered.



Said otherwise, with the current state of our practice, the workflow you
describe is flawed. Which makes the standards version declaration
useless.


But also your proposal: Maintainers are not able to check policy,
so we must rely on other people checking the policy and filling
the bugs? Who are such RC reporter?

hmmm.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Samuel Thibault]

Roger Leigh, le Wed 12 Aug 2009 11:30:50 +0100, a écrit :
> > > The default is UTF-32 or UTF-16, whichever corresponds to the width of
> > > wchar_t.
> > 
> > This documentation is bogus BTW.  It should read "UCS-4 or UCS-2".
> 
> It's "strictly" correct according to the standard.
> http://en.wikipedia.org/wiki/UTF-32/UCS-4 for an overview.

« except that the UTF-32 standard has additional Unicode
semantics. »

In UTF-32 mode, gcc introduces a BOM, and in UTF-16 it allows without
warnings characters after U+.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :
> > AIUI, this header is here to indicate which version of the policy the
> > package is supposed to conform to. This way, we have a way to enforce
> > which policy versions are supported, e.g. in a stable release, by
> > forbidding the too old versions.
> 
> No, that is wrong. The reason we put in the Standards version is
>  to let the next developer know what to look for in the upgrading
>  checklist in policy in order to bring the package up to date with policy

This assumes that the previous developer has correctly updated the
package according to the stated Standards version. Which is, in the
general case, wrong.

This also assumes that the upgrading checklist contains all relevant
information, which is also wrong for real cases.

If you want to bring a random package up-to-date with the policy, it is
generally more useful to look at its RC bugs, and also at its other
bugs.

Said otherwise, with the current state of our practice, the workflow you
describe is flawed. Which makes the standards version declaration
useless.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).

[Jonathan Yu]

On Tue, Aug 11, 2009 at 9:56 PM, Romain Beauxis wrote:
> Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit :
>> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
>> > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
>> >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
>> >> > The dh_make template for debian/copyright induces many developers to
>> >> > put their packaging work under the GPL, and I have already seen
>> >> > packages whose license is otherwise BSD-ish with such patches. If the
>> >> > maintainer suddenly goes MIA and the patch is non-trivial, then in
>> >> > theory if we want to respect what is written, we are stuck with a
>> >> > GPL'ed patch. Therefore, we have an optional License field to make
>> >> > things crystal clear if necessary.
>> >>
>> >> Sounds like dh_make needs a bug report about the default packagaging
>> >> license, could you file one?
>> >
>> > Dear all,
>> >
>> > we just had a case in the Debian Med packaging team where the upstream
>> > author of software licensed under terms similar to the BSD license got
>> > upset to see the Debian packaging licenced under the GPL, and posted a
>> > reminder that GPLed contributions to his software will not be accepted.
>>
>> Yes, this is precisely why the pkg-perl team usually goes with "same
>> terms as Perl itself" (Artistic | GPL) and whatever the upstream
>> licensing terms are (usually Artistic | GPL but sometimes BSD).
>>
>> So for example if upstream is BSD-licensed, then I'd personally put
>> something like:
>> Artistic | GPL | BSD
>> for the debian/* files
>>
>> My reasoning is that the upstream can get stuff like patches back into
>> their software (the BSD) provision but also allows anyone that can use
>> Perl to use the patch (Artistic | GPL). Further, if upstream decides
>> later to change to the "same as Perl" license (it is probably the most
>> popular license on CPAN), it is okay for them to do so (with our
>> patches).
>>
>> In the case of Debian-Med (being an outsider and not knowing what the
>> team works with), I'd say explicitly licensing your debian/* files
>> under the same license as upstream would be appropriate, or perhaps a
>> combination of upstream | GPL licensing. This is clearly a discussion
>> we all need to have within teams/package groups/etc -- namely, what do
>> we want our debian/* files to be licensed under.
>
> And also what exactly is covered by the license claim. For instance, in the
> case of patches contained in debian/, I have some doubts about the license
> that applies.
>
> Usually, when one wants to propose a patch to a project, it has to do it under
> the original licence. That's particularly the case if the patch consists, for
> instance, of the diff of a commit from the current developpement code of the
> same upstream project...
That does apply if you are proposing a patch for direct inclusion into
the project, though not even necessarily. I think that in that case
it's usually just assumed that you are providing code under the same
license. With a patch you're writing original code so you should have
the right to license it as you please, but you still need for the
patch to comply with the original license so that it can be included
without forcing upstream to change their license.

In any case, some superset of upstream + whatever other licenses you
want should be OK, since the upstream can integrate your changes by
licensing the code under their license. You still technically hold the
copyright to the diff but it usually doesn't matter, and authors often
assume copyright of your work unless it's a rather sizable patch,
which I think is what we want in the end.

Anyway, if the patch is applied upstream it's usually removed from
debian/patches/* so this point is sort of moot, right? As long as the
upstream is allowed to integrate the patch
>
> Hence, are patches in debian/ covered by the license claimed for the project
> upstream, or for the debian packaging ?
I'm of course not a lawyer, but my assumption is that code written by
someone is owned by that person, so it's covered by the Debian
packager/packaging team.
>
>
> Romain
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Remove control field Conflicts if the package is no longer in the repository

[Giacomo A. Catenazzi]

Giacomo A. Catenazzi wrote:

Manoj Srivastava wrote:

On Wed, Aug 12 2009, Timur Birsh wrote:


Hello Debian Developers,

I've recently uploaded (thanks to Bart Martens for sponsoring) my 
first package and want to adopt the next one. It's cd-discid [1]. Its 
debian/control file contains the Conflicts field. This package 
conflicts with cdgrab (<< 0.7), which is no longer exists in the 
repository. So, I have a question, may I remove Conflicts field safely?


I think that as long as the package (cdgrab, in this case) is
 not longer in stable, the conflicts line may be removed (we support
 partial upgrades from stable, as far as is possible). In this case,
 apparently cdgrab is not anywhere, so the conflicts line may go.


Really it is still in the archive, but with an other name.
So I see two options:
- replace cdgrab (<< 0.7) with abcde (<< 0.7)


Oops. This is a stupid option because abcde (<< 0.7) never existed.
Sorry for the noise

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Remove control field Conflicts if the package is no longer in the repository

[Giacomo A. Catenazzi]

Manoj Srivastava wrote:

On Wed, Aug 12 2009, Timur Birsh wrote:


Hello Debian Developers,

I've recently uploaded (thanks to Bart Martens for sponsoring) my first 
package and want to adopt the next one. It's cd-discid [1]. Its 
debian/control file contains the Conflicts field. This package conflicts 
with cdgrab (<< 0.7), which is no longer exists in the repository. So, I 
have a question, may I remove Conflicts field safely?


I think that as long as the package (cdgrab, in this case) is
 not longer in stable, the conflicts line may be removed (we support
 partial upgrades from stable, as far as is possible). In this case,
 apparently cdgrab is not anywhere, so the conflicts line may go.


Really it is still in the archive, but with an other name.
So I see two options:
- replace cdgrab (<< 0.7) with abcde (<< 0.7)
- remove the conflicts (because it is too old).

Notes:
The rename was done just before freezing potato, nearly 10 years ago.
http://lists.debian.org/debian-devel/1999/11/msg00182.html

See also abcde changelog:
http://packages.debian.org/changelogs/pool/main/a/abcde/abcde_2.3.99.8-1/changelog

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Neil Williams wrote:

> On Wed, 12 Aug 2009 11:59:09 +0200
> Josselin Mouette  wrote:
>
>> However I think this approach doesn’t fit the current way we deal with
>> policy changes. The de facto way of dealing with policy breakages
>> currently is to directly report serious bugs against packages not
>> conforming, regardless of the Standards-Version they declare. We will
>> even often NMU them without changing the Standards-Version, while having
>> actually fixed them to conform to newer versions.
>
> In many cases, wouldn't such a relationship be better expressed by a
> dependency on a package that implemented the new behaviour? Often it's
> dpkg and many of those situations are already handled via just such a
> dependency. So why have the extra field?

Because not all new policy changes are reflected by a new
 version of some package? And for  Developer picking up a package and
 wanting to know what needs to be looked at in order to achieve policy
 compliance, a mess of possible dependency relationships is a lot harder
 to base that decision on than a simple standards version.


> Also, for Standards-Version: to be useful again, wouldn't it be
> appropriate for lintian to have support for testing the package against
> the *declared* standards version? I doubt that this would be
> particularly welcome or easy to implement, hence I agree that the field
> itself is becoming irrelevant. Yes, we can test with the version of

That would be wrong. A Standards version has nothing to do with
 deciding whether or not a package is buggy WRT policy.  If it does not
 match current policy, the package is buggy, period.  Even if the
 mainteiner has cleverly set the standards version to 0.0.0.

The standards version is not a means of getting out of meeting
 policy. 


From a Project point of view, it is useful to see if a package
 in the archive meets current policy, not whether it met policy when the
 standards version was last touched (and encourage people to not change
 the standards version or follow policy). So assuming there is a
 relation between bugginess and standards version is wrong; the latter
 is only useful for people trying to update the package, so that they
 know what to look for.

manoj
-- 
Some of my readers ask me what a "Serial Port" is.  The answer is: I
don't know.Is it some kind of wine you have with breakfast?
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Remove control field Conflicts if the package is no longer in the repository

[Manoj Srivastava]

On Wed, Aug 12 2009, Timur Birsh wrote:

> Hello Debian Developers,
>
> I've recently uploaded (thanks to Bart Martens for sponsoring) my first 
> package and want to adopt the next one. It's cd-discid [1]. Its 
> debian/control file contains the Conflicts field. This package conflicts 
> with cdgrab (<< 0.7), which is no longer exists in the repository. So, I 
> have a question, may I remove Conflicts field safely?

I think that as long as the package (cdgrab, in this case) is
 not longer in stable, the conflicts line may be removed (we support
 partial upgrades from stable, as far as is possible). In this case,
 apparently cdgrab is not anywhere, so the conflicts line may go.

manoj
-- 
The IBM purchase of ROLM gives new meaning to the term "twisted
pair". Howard Anderson, "Yankee Group"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Manoj Srivastava]

On Wed, Aug 12 2009, Josselin Mouette wrote:

> Hi,
>
> the question in the subject may sound a bit naive, but I’m starting to
> wonder why we still set the Standards-Version in package control files.
>
> AIUI, this header is here to indicate which version of the policy the
> package is supposed to conform to. This way, we have a way to enforce
> which policy versions are supported, e.g. in a stable release, by
> forbidding the too old versions.

No, that is wrong. The reason we put in the Standards version is
 to let the next developer know what to look for in the upgrading
 checklist in policy in order to bring the package up to date with policy

This is no way implies that the package with an old standards
 version does not have to comply to latest policy. In other words, I
 can't just set Standards-Version to 0.0.0 and blithely ignore any
 policy -- the package would be buggy if it does not  follow the latest
 policy, regardless of the standards version.

> However I think this approach doesn’t fit the current way we deal with
> policy changes. The de facto way of dealing with policy breakages
> currently is to directly report serious bugs against packages not
> conforming, regardless of the Standards-Version they declare. We will
> even often NMU them without changing the Standards-Version, while having
> actually fixed them to conform to newer versions.
>
> Currently I don’t think this header reflects anything useful in a vast
> majority of our packages. I’m spending more time updating the header
> than actually updating old packages to conform to policy changes.
>
> What would you think of deprecating this header?

This would be bad, since when someone looks at the package, they
 would not know easily what they have to look for to update the
 package. The Standards Version gives a pointer into the upgrading
 checklist, and that remains useful.

manoj
-- 
Insufficient facts always invite danger. Spock, "Space Seed", stardate
3141.9
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version?

[Neil Williams]

On Wed, 12 Aug 2009 11:59:09 +0200
Josselin Mouette  wrote:

> However I think this approach doesn’t fit the current way we deal with
> policy changes. The de facto way of dealing with policy breakages
> currently is to directly report serious bugs against packages not
> conforming, regardless of the Standards-Version they declare. We will
> even often NMU them without changing the Standards-Version, while having
> actually fixed them to conform to newer versions.

In many cases, wouldn't such a relationship be better expressed by a
dependency on a package that implemented the new behaviour? Often it's
dpkg and many of those situations are already handled via just such a
dependency. So why have the extra field?

Also, for Standards-Version: to be useful again, wouldn't it be
appropriate for lintian to have support for testing the package against
the *declared* standards version? I doubt that this would be
particularly welcome or easy to implement, hence I agree that the field
itself is becoming irrelevant. Yes, we can test with the version of
lintian in lenny or etch but that's not really using the
Standards-Version field, it's using the release process instead.
Currently, lintian is taking a different approach that if the
debian/changelog has not been touched since Policy was updated, it
doesn't complain about tests that are new (and conversely complains if
the pointless Standards-Version field is out of sync with that
calculation). Presumably this is because the Standards-Version field
itself isn't suitable for a lintian test, so why have the field at all?

As a final thought, it would be nice to drop 10,000+ lines from the
Sources.gz file too - Sources.gz doesn't need to be the same size as
Packages.gz.

$ grep -c
Standards-Version 
/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_source_Sources
13695

Interestingly, using a 'sort -u|grep -c Standards-Version' pipe gives
*60* unique Standards-Versions in the current Sources for unstable.

3.0.0, 3.0.1, 3.0.1.1, 3.1.0, 3.1.0.0, 3.1.1, 3.1.1.0, 3.1.1.1, 3.2.0,
3.2.0.0, 3.2.1, 3.2.1.0, 3.5.0, 3.5.1, 3.5.10, 3.5.1.0, 3.5.10.0,
3.5.2, 3.5.2.0, 3.5.3, 3.5.4, 3.5.5, 3.5.5.0, 3.5.6, 3.5.6.0, 3.5.6.1,
3.5.7, 3.5.7.1, 3.5.8, 3.5.8.0, 3.5.9, 3.5.9.0, 3.6.0, 3.6.0.1, 3.6.1,
3.6.10, 3.6.1.0, 3.6.1.1, 3.6.2, 3.6.2.0, 3.6.2.1, 3.6.2.2, 3.6.3,
3.7.0, 3.7.1.2, 3.7.2, 3.7.20, 3.7.2.0, 3.7.2.1, 3.7.2.2, 3.7.3,
3.7.3.0, 3.8.0, 3.8.0.0, 3.8.0.1, 3.8.1, 3.8.1.0, 3.8.2, 3.8.2.0

> Currently I don’t think this header reflects anything useful in a vast
> majority of our packages. I’m spending more time updating the header
> than actually updating old packages to conform to policy changes.

+1

It could be made optional - only set if there is a reason to set it.
(Quite what those reasons would be, I have no idea but someone will
probably come up with one or two.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpDJudKo7Onu.pgp
Description: PGP signature

Re: default character encoding for everything in debian

[Roger Leigh]

On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote:
> I'm not sure, whether a conclusion is already reached.
> 
> 1. apt-get install mysql
> 2. enter mysql client
> 3. create database test; create table test( test char(10) );
> 
> Replace mysql with whatever application you like.
> 
> What should be the encoding of database and table test in cases like the 
> above?
> 
> Currently it's iso-something, discriminating everybody from other countries.
> If it would be utf-8 instead, it would have at least two advantages
> 
> - The clueless user would get a sane default
> - utf-8 isn't as discriminating as iso-8859-1

UTF-8 is the sane default choice in this situation, so long as MySQL
is capable of handling it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: MBF for removal of python-gnome2-desktop binary package

[Emilio Pozuelo Monfort]

Josselin Mouette wrote:
> Emilio Pozuelo Monfort 
>scribes

> Python Applications Packaging Team 
>scribes (U)

Fixed in trunk.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
> Josselin Mouette  writes:
>> If we use build IDs (and this has quite some advantages, like being able
>> to do more than just dump the ddebs on a repository), this can lead to
>> having the same detached debugging symbols in two binary packages, since
>> sometimes a binary is built twice the same exact way and put in two
>> different binary packages.
> 
> Hm, really?  The toolchains that I'm familiar with basically never produce
> the same binary twice; something is always slightly different from
> timestamp information.  Could you give an example of such a case in the
> archive right now where identical binaries are in multiple packages so
> that I can better understand how this happens?

There are things the linker takes into account for calculating the build id. The
timestamp isn't one of them.

E.g.:

emi...@saturno:/tmp$ echo "main(){}" > a.c; cp a.c b.c; gcc -o a a.c; gcc -o b
b.c; eu-readelf -n a b | grep Build
Build ID: c164b7f24a18b665601cd1d1b9fa0af6afb728bb
Build ID: c164b7f24a18b665601cd1d1b9fa0af6afb728bb

So in cases where you build a package twice with different configure flags, it's
be possible that those don't affect some binaries, getting the same build ids.

E.g., after a build of evince/2.26.1-2 from testing (the package in unstable has
been changed to ship the backends in the library package so this is no longer
the case, but to show this happens):

r...@saturno:~/evince-2.26.1# eu-readelf -n
debian/evince/usr/lib/evince/1/backends/*so
debian/evince-gtk/usr/lib/evince/1/backends/*so | grep Build | sort | uniq -c
  2 Build ID: 0232654930d90461896f3d58fe08178082a217df
  2 Build ID: 08de63310c0ff98c5aac6392d95c7bd6fc502c8b
  2 Build ID: 71b914ea23bb199d9d98de2a15a9d07e982a3ae0
  2 Build ID: 7a40178124bf7698de230b2298378f08795ddbe5
  2 Build ID: 8de5ebfcb2bfceb9ed19a57d6bbc918392e152ec
  2 Build ID: c0b63d2ecd7432f0a01441e0794306651c88f5f7
  2 Build ID: c3b7f89bda6381e5849819032f842e6870e184b5
  2 Build ID: dffdcca3f7a89b4b9da333d7cc638a96ed8b1bc8


Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: default character encoding for everything in debian

[Thomas Koch]

It's impressing how quickly threads on this list grow big. :-)

I'm not sure, whether a conclusion is already reached.

1. apt-get install mysql
2. enter mysql client
3. create database test; create table test( test char(10) );

Replace mysql with whatever application you like.

What should be the encoding of database and table test in cases like the 
above?

Currently it's iso-something, discriminating everybody from other countries.
If it would be utf-8 instead, it would have at least two advantages

- The clueless user would get a sane default
- utf-8 isn't as discriminating as iso-8859-1

Best regards,

Thomas Koch

> Hi,
>
> I've an issue, that I forgot to set the character encoding of tomcat to
> utf-8 after reinstalling a server.
> Now, before I report a wishlist(?) bug to tomcat, I want to ask (and invite
> to discuss) shouldn't utf8 be the default character set everywhere? So when
> installing a package from Debian I can assume that where a character
> encoding can be set, it't set to utf8.
> MySQL would be another example, which to my knowledge uses isoXYZ as
> default character encoding.
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Roger Leigh]

On Wed, Aug 12, 2009 at 07:54:33AM +0200, Giacomo A. Catenazzi wrote:
> Samuel Thibault wrote:
> > Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit :
> >> while length(str) in any language up to the 1990s was a mere
> >> substraction, now we must go through the string checking each byte to
> >> see if it is a Unicode marker and substract the appropriate number of
> >> bytes.
> > 
> > Not necessarily.  Any sane implementation should just use wchar_t and
> > substraction gets back.
> 
> An implementation that use wchar_t is usually not sane, but usually
> it is (also) buggy. It is very difficult (AFAIK not impossible,
> but I'm not so sure) to write portable (POSIX way, so with changing
> locales) programs using wchar_t.

Do you have any concrete examples to back up these assertions?

They worked perfectly well for me last time I checked.  There were
bugs in the distant past, but I don't see any issues with current
GCC/libc.

BTW, since POSIX/SUS are a superset of the standard C library, they
contain all of the same wide character handling functionality.  I'm
not sure what you're getting at with the "changing locales"; SUS
locale functionality like setlocale() comes directly from C with no
changes.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

MBF for removal of python-gnome2-desktop binary package

[Josselin Mouette]

Hi,

due to some upcoming changes in the list of supported modules upstream,
the python-gnome2-desktop binary package will be removed soon. Packages
must depend on the individual modules instead. 

For example, if the only module used is gnomeapplet, you must depend on
python-gnomeapplet instead. A list of modules that different packages
use is available at http://wiki.debian.org/GnomePythonSplitting but
beware since it was generated a few months ago.

Please also note that python-nautilusburn will be removed eventually,
but if possible, this will happen only after python-braseroburn has been
packaged and been here for a while.

The dd-list follows. MBF will happen soon, except for packages for which
I’ll be warned that it’s fixed in the repository.

David Villa Alises 
   ows

Michael Biebl 
   tracker

Adolfo González Blázquez 
   cameramonitor

Salvatore Bonaccorso 
   giplet

Debian GNOME Maintainers 
   hamster-applet (U)
   ontv (U)

Debian OLPC 
   sugar-toolkit

Sebastian Dröge 
   ontv (U)

Pedro Fragoso 
   hamster-applet

Jeremy Guitton 
   ontv

Philipp Kern 
   timer-applet

Julian Andres Klode 
   gimmie

Clement Lorteau 
   gtkvncviewer

Maintainers of GStreamer packages 

   elisa-plugins-good

Loic Minier 
   elisa-plugins-good (U)

Kartik Mistry 
   ldtp

Emilio Pozuelo Monfort 
   scribes

Sam Morris 
   serpentine

Josselin Mouette 
   hamster-applet (U)

Philippe Normand 
   elisa-plugins-good (U)

Adriaan Peeters 
   music-applet

Frederic Peters 
   gnome-blog

Siegfried-Angel Gevatter Pujals 
   webboard

Ara Pulido 
   ldtp (U)

Python Applications Packaging Team 
   scribes (U)

Arnaud Quette 
   elisa-plugins-good (U)

Jonas Smedegaard 
   sugar-toolkit (U)

Jose Carlos Garcia Sogo 
   conduit

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: default character encoding for everything in debian

[Roger Leigh]

On Wed, Aug 12, 2009 at 09:56:49AM +0200, Samuel Thibault wrote:
> Giacomo A. Catenazzi, le Wed 12 Aug 2009 08:03:30 +0200, a écrit :
> > Bastian Blank wrote:
> > > On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote:
> > >> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
> > >>> Not necessarily.  Any sane implementation should just use wchar_t
> > >> Which could be UTF16 and therefore still has complicatd length 
> > >> semantics. 
> > > 
> > > No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like
> > > Windows).
> > 
> > No wchar_t is locale dependent (per POSIX).
> 
> What do you mean?  The compiler can't know the locale in advance for
> the width and endianness.  The value might depend on the locale, yes,
> but that's not a problem as long as you convert into UTF-8 before
> communicating with other applications.
> 
> One same systems (Debian systems are), it's just always UCS-4.

Specifically, __STDC_ISO_10646__ is defined to indicate that wchar_t
is always UCS-4 in all locales.

> > BTW on gcc:
> > 
> > -fwide-exec-charset=charset
> > Set the wide execution character set, used for wide string and
> > character constants.
> 
> It hurts when I shoot myself in the foot.

This feature of GCC is one of the more obscure areas of locale
handling.  How does the encoding of strings at the level of
individial translation units work with a single per-process
global locale and C formatted I/O?  Curious minds would like to
know!

> > The default is UTF-32 or UTF-16, whichever corresponds to the width of
> > wchar_t.
> 
> This documentation is bogus BTW.  It should read "UCS-4 or UCS-2".

It's "strictly" correct according to the standard.
http://en.wikipedia.org/wiki/UTF-32/UCS-4 for an overview.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What’s the use for Standards-Version ?

[Giacomo A. Catenazzi]

Josselin Mouette wrote:

Hi,

the question in the subject may sound a bit naive, but I’m starting to
wonder why we still set the Standards-Version in package control files.

AIUI, this header is here to indicate which version of the policy the
package is supposed to conform to. This way, we have a way to enforce
which policy versions are supported, e.g. in a stable release, by
forbidding the too old versions.

However I think this approach doesn’t fit the current way we deal with
policy changes. The de facto way of dealing with policy breakages
currently is to directly report serious bugs against packages not
conforming, regardless of the Standards-Version they declare. We will
even often NMU them without changing the Standards-Version, while having
actually fixed them to conform to newer versions.

Currently I don’t think this header reflects anything useful in a vast
majority of our packages. I’m spending more time updating the header
than actually updating old packages to conform to policy changes.

What would you think of deprecating this header?


I find convenient to see what I should check, because of policy upgrades.
[ /usr/share/doc/debian-policy/upgrading-checklist.txt.gz ]

Not always I've time to check/update the package to the new policy (e.g.
when correcting a single bug), so the upload date is not sufficient, and
doing a complete/deep check is time intensive. Further I cannot trust
lintian or bug reports for policy compliance.

PS: I'm also not sure that lintian could do these check automatically.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

What’s the use for Standards-Version?

[Josselin Mouette]

Hi,

the question in the subject may sound a bit naive, but I’m starting to
wonder why we still set the Standards-Version in package control files.

AIUI, this header is here to indicate which version of the policy the
package is supposed to conform to. This way, we have a way to enforce
which policy versions are supported, e.g. in a stable release, by
forbidding the too old versions.

However I think this approach doesn’t fit the current way we deal with
policy changes. The de facto way of dealing with policy breakages
currently is to directly report serious bugs against packages not
conforming, regardless of the Standards-Version they declare. We will
even often NMU them without changing the Standards-Version, while having
actually fixed them to conform to newer versions.

Currently I don’t think this header reflects anything useful in a vast
majority of our packages. I’m spending more time updating the header
than actually updating old packages to conform to policy changes.

What would you think of deprecating this header?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Remove control field Conflicts if the package is no longer in the repository

[Timur Birsh]

Hello Debian Developers,

I've recently uploaded (thanks to Bart Martens for sponsoring) my first 
package and want to adopt the next one. It's cd-discid [1]. Its 
debian/control file contains the Conflicts field. This package conflicts 
with cdgrab (<< 0.7), which is no longer exists in the repository. So, I 
have a question, may I remove Conflicts field safely?

1. http://packages.debian.org/sid/cd-discid

Thanks.
-- 
Timur


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Samuel Thibault]

Giacomo A. Catenazzi, le Wed 12 Aug 2009 08:03:30 +0200, a écrit :
> Bastian Blank wrote:
> > On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote:
> >> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
> >>> Not necessarily.  Any sane implementation should just use wchar_t
> >> Which could be UTF16 and therefore still has complicatd length semantics. 
> > 
> > No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like
> > Windows).
> 
> No wchar_t is locale dependent (per POSIX).

What do you mean?  The compiler can't know the locale in advance for
the width and endianness.  The value might depend on the locale, yes,
but that's not a problem as long as you convert into UTF-8 before
communicating with other applications.

One same systems (Debian systems are), it's just always UCS-4.

> BTW on gcc:
> 
> -fwide-exec-charset=charset
> Set the wide execution character set, used for wide string and
> character constants.

It hurts when I shoot myself in the foot.

> The default is UTF-32 or UTF-16, whichever corresponds to the width of
> wchar_t.

This documentation is bogus BTW.  It should read "UCS-4 or UCS-2".

> Note that default encoding is UTF-8, thus giving a UTF-32 wchar_t
> in most developer machines.

I don't understand this sentence.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: default character encoding for everything in debian

[Samuel Thibault]

Giacomo A. Catenazzi, le Wed 12 Aug 2009 07:54:33 +0200, a écrit :
> Samuel Thibault wrote:
> > Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit :
> >> while length(str) in any language up to the 1990s was a mere
> >> substraction, now we must go through the string checking each byte to
> >> see if it is a Unicode marker and substract the appropriate number of
> >> bytes.
> > 
> > Not necessarily.  Any sane implementation should just use wchar_t and
> > substraction gets back.
> 
> An implementation that use wchar_t is usually not sane, but usually
> it is (also) buggy.

Why? It's just about using wide functions instead of usual functions.

> PS: note that the binary encoding depend on compiler environment (but
> such info is not exported).

See my other mail.  A lot of things can be made to depend on the
compiler environment.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org