Nabble - debian-policy

Bug#561828: debian-policy: add restriction for non arch all packages

2009-12-20T07:05:52Z

* Carl Fürstenberg <azatoth@...> [091220 15:51]:
> currently section 5.6.8 doesn't say when a package should be in arch
> all except when source package is arch all (which in turn gives the same
> argument).
> I think following statement should be added: "If the content of a
> package is architeture independent in relation to it's particular use,
> then the package must have architecture 'all'".

I think if it is deemed necessary at all to formulate it, it should give
the real rule: "If a package built on one architecture can be used on
all architectures, ..".

There is at least the case of different dependencies per architecture,
which cannot yet be expressed in an architecture all package.

Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561828: debian-policy: add restriction for non arch all packages

2009-12-20T06:27:54Z

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

currently section 5.6.8 doesn't say when a package should be in arch
all except when source package is arch all (which in turn gives the same
argument).
I think following statement should be added: "If the content of a
package is architeture independent in relation to it's particular use,
then the package must have architecture 'all'".

-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to sv_SE.UTF-8)
Shell: /bin/sh linked to /bin/bash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii doc-base 0.9.5 utilities to manage online documen

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: medical profession listings

2009-12-19T08:53:43Z

Here's what we're offering for this week:

788,114 in total * 17,482 emails
Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology,
Neurology, Plastic Surgery, Psychiatry, Cardiology and much more

16 different sortable fields

Searching for a Dentists Database? And uncover new opportunities? All data is verified:
US Dentists Database Updated Records 2009
This database includes only licensed dentists:
New for this Year: Database of Dentists <> in America (reg$599)
<> 192,003 Dentists with City, State, Zip
<> 189,050 Addresses
<> 191,033hone Numbers
<> 95,226 Fax #'s
<> 51,440 E-Mail Addresses
Last-named* title* address1* city* state* zip* county* phone** Email Address* Fax Number* Website

Price for this week only = $296 listed above

reply here Henry@...

Good until the end of this week.

contact rembox@... for record exclusion.

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561494: Fwd: devref and policy should agree on where to document tarball repacking

2009-12-18T14:05:46Z

On Fri, Dec 18, 2009 at 02:37:49PM +0100, Thibaut Paumard wrote:

>>I have a slight, but not overwhelming, preference for having this in
>>README.source rather than in debian/copyright;
>
>Hi,
>
>I believe this belongs in copyright. This is based on two
>considerations:
>
>1) debian/copyright is (should be) the central repository for
>legal information for the source package as well as for all the
>binary packages it builds;

We're talking about files that have been removed and are consequently *not*
part of the source package. Even if we conclude that debian/copyright is
the right place to document *what* has been removed from the upstream
source, I certainly disagree that this would include documenting the
*license* of the removed files in debian/copyright, and that's not what has
been asked for here. At most, I think best practice is to document what was
removed and give a short explanation of why the removal was necessary; that
doesn't imply reproducing the problematic license, just stating what the
problematic license terms are.

>2) most free licenses require to clearly specify modifications to
>licensed work. Deleting files is to be considered a modification
>of the source package, which _is_ the licensed work.

Deleting files is done when those files don't meet the DFSG, so I don't see
how this can ever be a problem with a free license. :)

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Bug#561494: Fwd: devref and policy should agree on where to document tarball repacking

2009-12-18T09:48:07Z

Thibaut Paumard <mlotpot.news@...> writes:

>> 2) most free licenses require to clearly specify modifications to
>> licensed work. Deleting files is to be considered a modification of the
>> source package, which _is_ the licensed work.
>>
>> By the same token, I am starting to realise that we should also
>> certainly specify in debian/copyright that some files have been
>> patched. If using a patch system, the files are not modified in the
>> source package, but still the binary packages are built with or even
>> ship modified files. Also the details of the modifications belong
>> elsewhere, I think debian/copyright should clearly state that our
>> package is derived work, not the original, unmodified work.

Our historical stance on this part of the problem is that debian/changelog
is sufficient documentation for what changes have been made to the package
(although that does imply that one needs to document in debian/changelog
what changes you're making).

This is consistent with the FSF's stance that the ChangeLog file is
sufficient to satisfy the GPL requirement that changes be documented
(since the GPL is one of the licenses with the most restrictive
requirements about change notices).

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561597: developers-reference: servers in upload queue list is old

2009-12-18T06:47:03Z

Package: developers-reference
Severity: minor
Version: 3.4.3

Hi,

- use ftp.upload.debian.org instead of ftp-master.debian.org for upload queue
- no upload queue in Japan, now.

About "upload queue" article in D-D-R, it is quite old.
As 5.6.1. Uploading to ftp-master,
>To upload a package, you should upload the files (including the signed
>changes and dsc-file) with anonymous ftp to ftp-master.debian.org in
>the directory /pub/UploadQueue/.

But refers to d-d-a, Joerg says
> - there is ftp.upload.debian.org, please use that in future instead of
> ftp-master.debian.org

we should recommend to use ftp.upload.debian.org.

And,
>The queues on master.debian.org, samosa.debian.org, master.debian.or.jp,
>and ftp.chiark.greenend.org.uk are down permanently, and will not be resurrected.
>The queue in Japan will be replaced with a new queue on hp.debian.or.jp some day.

master.debian.or.jp was stopped and hp.debian.or.jp doesn't work now.
I suggest to remove last sentence.

--
Regards,

Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
http://wiki.debian.org/HidekiYamane

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561494: Fwd: devref and policy should agree on where to document tarball repacking

2009-12-18T05:37:49Z

Sorry, my answer went to "submit" instead of the right bug.

Copy sent again to d-devel to allow answers to go to the bug report.

Début du message réexpédié :

> Réenvoyé-De : debian-devel@...
> De : Thibaut Paumard <mlotpot.news@...>
> Date : 18 décembre 2009 14:17:09 HNEC
> À : Debian Debian Developers <debian-devel@...>, Debian
> Bug Debian BTS submit <submit@...>
> Objet : Rép : devref and policy should agree on where to document
> tarball repacking
>
>
> Le 17 déc. 09 à 17:28, Steve Langasek a écrit :
>
>> Package: developers-reference
>> Version: 3.4.3
>>
>> On Thu, Dec 10, 2009 at 04:45:33PM -0800, Russ Allbery wrote:
>>> Charles Plessy <plessy@...> writes:
>>
>>>> while checking the section 6.7.8.2 of the Developers reference
>>>> (“Repackaged upstream source”) in the context on another thread
>>>> on this
>>>> list
>>>> (http://lists.debian.org/msgid-search/d921045c2e3ae5ecfba088e9d82eb2c6@...
>>>> ),
>>>> I found the following :
>>
>>>> A repackaged .orig.tar.gz
>>
>>>> 1. should be documented in the resulting source package.
>>>> Detailed
>>>> information on how the repackaged source was obtained, and on
>>>> how
>>>> this can be reproduced should be provided in debian/copyright.
>>>> It
>>>> is also a good idea to provide a get-orig-source target in your
>>>> debian/rules file that repeats the process, as described in the
>>>> Policy Manual, Main building script: debian/rules.
>>
>> [...]
>> I have a slight, but not overwhelming, preference for having this in
>> README.source rather than in debian/copyright;
>
> Hi,
>
> I believe this belongs in copyright. This is based on two
> considerations:
>
> 1) debian/copyright is (should be) the central repository for legal
> information for the source package as well as for all the binary
> packages it builds;
>
> 2) most free licenses require to clearly specify modifications to
> licensed work. Deleting files is to be considered a modification of
> the source package, which _is_ the licensed work.
>
> By the same token, I am starting to realise that we should also
> certainly specify in debian/copyright that some files have been
> patched. If using a patch system, the files are not modified in the
> source package, but still the binary packages are built with or even
> ship modified files. Also the details of the modifications belong
> elsewhere, I think debian/copyright should clearly state that our
> package is derived work, not the original, unmodified work.
>
> What is not clear to me is whether we need to list all the files
> that are modified (or removed), or whether a generic "this work may
> have been modified prior to inclusion in Debian" is sufficient (in
> debian/copyright).
>
> Best regards, Thibaut.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561494: devref and policy should agree on where to document tarball repacking

2009-12-17T09:54:21Z

On Thu, Dec 17, 2009 at 08:28:18AM -0800, Steve Langasek wrote:

> Package: developers-reference
> Version: 3.4.3
>
> I have a slight, but not overwhelming, preference for having this in
> README.source rather than in debian/copyright; however, I think the more
> important issue here by far is that policy and the devref currently
> recommend including the same information in two different places, and this
> duplication is bad and inevitably leads to *both* locations being unreliable
> sources for this information. Moving this to a bug on the devref (per my
> personal preference); if consensus is that debian/copyright is the right
> place for this, then we can reassign it to policy, but one way or the other
> one of these documents should be changed to agree with the other.

I would like to say that I agree with you, and that I too prefer README.source
over debian/copyright, for various reason including that source repackaging
shoule have no effect on the copyright status of the binary package, so it
is quite sufficient to be documented in the source package only.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

signature.asc (204 bytes) Download Attachment

Bug#561494: devref and policy should agree on where to document tarball repacking

2009-12-17T08:28:18Z

Package: developers-reference
Version: 3.4.3

On Thu, Dec 10, 2009 at 04:45:33PM -0800, Russ Allbery wrote:
> Charles Plessy <plessy@...> writes:

> > while checking the section 6.7.8.2 of the Developers reference
> > (“Repackaged upstream source”) in the context on another thread on this
> > list
> > (http://lists.debian.org/msgid-search/d921045c2e3ae5ecfba088e9d82eb2c6@...),
> > I found the following :

> > A repackaged .orig.tar.gz

> > 1. should be documented in the resulting source package. Detailed
> > information on how the repackaged source was obtained, and on how
> > this can be reproduced should be provided in debian/copyright. It
> > is also a good idea to provide a get-orig-source target in your
> > debian/rules file that repeats the process, as described in the
> > Policy Manual, Main building script: debian/rules.

> > I have no strong opinion on the subject, but I think that either the
> > Developers Reference should be modified to reflect current consensus and
> > practice, or in contrary the section 6.7.8.2 of the Dev. Ref. argues for
> > the incorporation of the removing information in the DEP-5
> > machine-readable format.

> I personally still believe this information belongs in debian/copyright,
> not in README.source. README.source might be appropriate if there are
> detailed instructions required for how someone else would create a new
> upstream source tarball, but debian/copyright is the appropriate location
> to describe the provenance of the upstream tarball, which in my opinion
> should include a human-readable description of transformations applied to
> it.

I have a slight, but not overwhelming, preference for having this in
README.source rather than in debian/copyright; however, I think the more
important issue here by far is that policy and the devref currently
recommend including the same information in two different places, and this
duplication is bad and inevitably leads to *both* locations being unreliable
sources for this information. Moving this to a bug on the devref (per my
personal preference); if consensus is that debian/copyright is the right
place for this, then we can reassign it to policy, but one way or the other
one of these documents should be changed to agree with the other.

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

signature.asc (844 bytes) Download Attachment

Bug#561413: Policy possibly should not recommend *.la files

2009-12-16T15:14:25Z

On Wed, Dec 16, 2009 at 02:42:06PM -0800, Russ Allbery wrote:

> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
>
> Policy currently says:
>
> An ever increasing number of packages are using libtool to do their
> linking. The latest GNU libtools (>= 1.3a) can take advantage of the
> metadata in the installed libtool archive files (*.la files). The main
> advantage of libtool's .la files is that it allows libtool to store and
> subsequently access metadata with respect to the libraries it builds.
> libtool will search for those files, which contain a lot of useful
> information about a library (such as library dependency information for
> static linking). Also, they're *essential* for programs using
> libltdl.
>
> Given the various problems that we've run into with *.la files, particularly
> around adding unnecessary shared library dependencies, I wonder if this
> paragraph should be revised to be a bit less encouraging about retaining
> *.la files.

Agreed.

> (Although I suppose that this may change if binutils-gold and
> its --as-needed default becomes the default linker.)

binutils-gold currently only support a subset of Debian plateforms:
(amd64, armel, i386, powerpc, sparc).

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#561413: Policy possibly should not recommend *.la files

2009-12-16T14:42:06Z

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

Policy currently says:

An ever increasing number of packages are using libtool to do their
linking. The latest GNU libtools (>= 1.3a) can take advantage of the
metadata in the installed libtool archive files (*.la files). The main
advantage of libtool's .la files is that it allows libtool to store and
subsequently access metadata with respect to the libraries it builds.
libtool will search for those files, which contain a lot of useful
information about a library (such as library dependency information for
static linking). Also, they're *essential* for programs using
libltdl.

Given the various problems that we've run into with *.la files, particularly
around adding unnecessary shared library dependencies, I wonder if this
paragraph should be revised to be a bit less encouraging about retaining
*.la files. (Although I suppose that this may change if binutils-gold and
its --as-needed default becomes the default linker.)

-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii doc-base 0.9.5 utilities to manage online documen

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#462377: Updated policy in python-defaults 2.5.4-4 should resolve the confusion

2009-12-14T19:13:24Z

Now the that policy shipped in python-defaults has been updated (including a
review of Manoj's document, it should be at least clear which reference should
be used. We will need some time before we should consider it fully blessed,
so this is progress on this bug, but doesn't resolve it.

signature.asc (204 bytes) Download Attachment

Link to: Titel

2009-12-14T04:21:45Z

Link to: Titel

Titel

Would you like to earn an extra Earn $200 - $500
Every Day? for just 45 minutes work?

Data Entry Workers Needed Worldwide!
FOR MORE INFO PLEASE GO TO:
http://vur.me/544358/Global_Data_Entry/

I would personally like to invite you
to become part of our team doing work-at-home data entry.
We have guided thousands of team members to success
using our new type of data-entry job called Global Data Entry.
Some members are currently making $300 - $2000 and more per day,
we have been dealing with online data entry for over 7 years.

Once you become a via member, you will have exclusive
access to legitimate data entry opportunities life time.
Forms are just 1-3 pages and take only a few minutes to complete
You will be in control and they will pay you
directly via direct deposit, paypal or check.
Earnings are paid every 2 weeks.

Once you have signed up with our via team member,
we will provide you with complete guidance and
tutorials on exactly how to do these different job tasks and
to make this work for you, especially the downloadables files
of GLOBAL DATA ENTRY to send you in your email account.

It is possible to quit your job for the first used 3 days,
how much more if you work hardly 8 hours a day.
This is what you have been waiting for!
don't hesitate to grab this big opportunities, just try it
and I can guarantee you 100% you'll enjoy it.

Paul Dobson
Home-Data Entry
Affiliate Marketer
pauldobson143@...

FOR MORE INFO PLEASE GO TO:
http://vur.me/544358/Global_Data_Entry/

God Bless from a very satisfied member

one time only registration fee because we only want serious job
If we allowed for free we would have "curiosity"
applicants filling applications that were not really serious

This is a one time adv. email only and you won't received further mailings about this.

If you would like to opt-out just send an e-mail with "Opt Out in the subject line to the address

--------------------------------------------------------------------
We would like to point out that the sender’s address has not been verified.
Please ignore this e-mail if you have any doubts about the authenticity of the sender

Bug#391841: debian-policy: Remove time-daemon

2009-12-12T13:32:40Z

On Sat, Dec 12, 2009 at 09:58:24AM -0300, Dererk wrote:
>
> I consider that the description is both, relatively generic and straight
> forward to a function or service, which in my opinion, in this case is
> the main goal.

The problem I have with alot of virtual packages is what you
can expect from such a virtual package. Some of them are
very clear in what you can expect, but others are not.

It currently just says "anything that serves as a time daemon".
I can for instance interpret that as a daemon that just tells
you what the current time is, like the daytime or time service.
It's part of most inetd implementation, but ussually not
enabled by default. It will not change the local clock,
just tell you the current time.

Someone else might want to have something that can keep it's
clock more or less at the correct time, but doesn't need it
to be a daemon. There are several programs that can do that like
adjtimex, hwclock, chrony and probably some others that
compensate for the drift of your clock by having 2 measurements
and setting the kernel kernel to compensate for that.

Others might need something to have all computers in their
network to agree on the time. For instance Kerberos needs
them to agree on the time, but it doesn't care that it's the
correct time. This can be done by ntp by setting 1 server to
redistribute it's local clock and let all others sync to that,
but requires manual configuration.

Depending on ntp does not garantee you anything. The computer
might not be in a network, or it might be but might not have
access to external ntp servers.

On a related note we currently have this in the init script info
section:
# Provides: ntp

So packages that now depends on ntp | time-daemon and there is
something else that provides time-daemon installed, and the
package has a Required-Start: ntp in the init script it
probably broken unless that other package also provides ntp.

And ntp currently does not sync the clock at start, it ussually
takes about 3 minutes for it to set the time for the first time.
There is a program ntp-wait you could use to wait for that,
but you probably don't want to wait that long before starting
your service.

If you have that installed on your laptop, and you currently don't
have network connectivity you probably also don't want to wait
until that times out before you can log in.

Kurt

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#560839: debian-policy: please move digressions into footnotes

2009-12-12T09:40:35Z

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

$ zgrep -A2 'author of this' /usr/share/doc/debian-policy/policy.txt.gz | sed -e 's/^$ *$//;s/.*(/(/' | fmt
(the author of this manual has heard of a package whose versions went
`1.1', `1.2', `1.3', `1', `2.1', `2.2', `2' and so forth).

This statement is in no way normative, please move it into a footnote.

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Processed: Re: Bug#559895: menu: New Category Applications/Multimedia

2009-12-12T07:06:11Z

Processing commands for control@...:

> reassign 559895 debian-policy
Bug #559895 [menu] menu: New Category Applications/Multimedia
Bug reassigned from package 'menu' to 'debian-policy'.
Bug No longer marked as found in versions menu/2.1.42.
> thanks
Stopping processing here.

Please contact me if you need assistance.

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

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#559895: menu: New Category Applications/Multimedia

2009-12-12T07:03:23Z

reassign 559895 debian-policy
thanks
On Mon, Dec 07, 2009 at 05:45:35PM +0100, Andreas Marschke wrote:

> Package: menu
> Version: 2.1.42
> Severity: normal
>
> Hi,
>
> I'm here by proposing to add a new category to the menu called
> Applications/Multimedia or FreeDesktop.org conform Applications/AudioVideo as
> some of the shipped applications with debian o not only comply to the current
> category they are in.
> For examble, vlc is in the category Applications/Viewers and bangarang is in
> the category Applications/Sounds although both are able to play videos as
> well as music and show pictures. For this reason it is only understandable to
> add the new category called either Applications/Multimedia or
> Applications/AudioVideo .

Hello Andreas,
the menu section is defined by the menu subpolicy which is part of
debian-policy and not of the menu package. Reassigning.

Looking at the menu subpolicy, I believe that both vlc and bangarang belong
to Applications/Video.

I do not think a section Applications/Multimedia would be useful, unless we
remove both Applications/Video and Applications/Sound. Almost all programs
that are able to deal with video can deal with sound since movie usually
include sound component, so I think there is some expectation that programs
in Applications/Video will do sound. At worse a program can define two
menu entries one in Sound and one in Video, maybe with a different command.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#391841: debian-policy: Remove time-daemon

2009-12-12T04:58:24Z

Hello Peter,

I perfectly understand what you mean, but as you also mentioned, you are
referring to ntpdate as if it was possible to be in conflict with any
software provided by time-daemon, while note being a daemon anyway.

I consider that the description is both, relatively generic and straight
forward to a function or service, which in my opinion, in this case is
the main goal.

Let's consider a very very plain and simple shell script (or
in-your-favorite-scripting-language ;-) ), which runs into a loop and
cycles a ntpdate software checking for time deviation, wouldn't it be a
candidate for a 'time-daemon' package provider?
I do consider it will perfectly suit as it servers the purpose of
getting a system time-synced, Ok Ok, in a completely roughly fashion,
but it somehow does.

Please reconsider the remotion of this virtual-package.

Cheers,

Dererk

--
BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. Poor misguided fools.

signature.asc (853 bytes) Download Attachment

Bug#560808: developers-reference: typo (programms -> programs)

2009-12-12T04:13:55Z

Package: developers-reference
Version: 3.4.3
Severity: minor

$ zgrep programm /usr/share/doc/developers-reference/developers-reference.txt.gz
Please use the programms dd-list and if appropriate whodepends

--
Jakub Wilk

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#560411: debian-policy: Document debconf's SETTITLE command in the debconf-spec

2009-12-11T02:32:43Z

On Fri, Dec 11, 2009 at 12:06:16AM +0100, Frans Pop wrote:
> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
> Tags: patch
> X-Debbugs-CC: debconf@...
>
> Attached a patch to document the SETTITLE command in the debconf policy.
> Inclusion of this command should not pose any problems as it has been
> supported since 1993 (debconf version 1.3.22).
^^^^
In which calendar ?

SCNR,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Firmanızı / Sitenizi Ekleyin !

2009-12-10T21:54:11Z

Firmanızı

Firmanızı / Sitenizi Ekleyin !

www.webdebul.com

Bug#560411: debian-policy: Document debconf's SETTITLE command in the debconf-spec

2009-12-10T15:06:16Z

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
Tags: patch
X-Debbugs-CC: debconf@...

Attached a patch to document the SETTITLE command in the debconf policy.
Inclusion of this command should not pose any problems as it has been
supported since 1993 (debconf version 1.3.22).

diff -ur debian-policy.orig/debconf_spec/debconf_specification.xml debian-policy/debconf_spec/debconf_specification.xml
--- debian-policy.orig/debconf_spec/debconf_specification.xml 2009-08-16 02:19:11.000000000 +0200
+++ debian-policy/debconf_spec/debconf_specification.xml 2009-12-10 23:58:22.000000000 +0100
@@ -10,8 +10,8 @@

<articleinfo>
<title>Configuration management</title>
- <subtitle>Protocol version 2</subtitle>
- <releaseinfo>Revision 7.0</releaseinfo>
+ <subtitle>Protocol version 2.1</subtitle>
+ <releaseinfo>Revision 7.1</releaseinfo>
<author>
<firstname>
Wichert
diff -ur debian-policy.orig/debconf_spec/include/commands.xml debian-policy/debconf_spec/include/commands.xml
--- debian-policy.orig/debconf_spec/include/commands.xml 2009-08-16 02:19:11.000000000 +0200
+++ debian-policy/debconf_spec/include/commands.xml 2009-12-10 23:58:22.000000000 +0100
@@ -6,7 +6,7 @@
<para>
This exchanges with the frontend the protocol version
number that is being used. The current version is
- 2.0. Versions in the 2.x series will be
+ 2.1. Versions in the 2.x series will be
backwards-compatible. You may specify the protocol version
number you are speaking. The frontend will return the version
of the protocol it speaks. If the version you specify is too
@@ -53,10 +53,10 @@
</table>
</para>
</listitem>
-<listitem id="command_title">
+<listitem id="command_settitle">
<para>
- TITLE
- <parameter>string</parameter>
+ SETTITLE
+ <parameter>template</parameter>
</para>
<para>
You can use this command to set a title in the
@@ -65,6 +65,22 @@
of the frontend's window. If you don't specify anything, a
title will automatically be generated.
</para>
+ <para>
+ Using a template has the advantage that titles are translatable
+ and that they can be maintained in the same place as other text
+ displayed to users.
+ </para>
+</listitem>
+<listitem id="command_title">
+ <para>
+ TITLE
+ <parameter>string</parameter>
+ </para>
+ <para>
+ Similar to SETTITLE, but takes a string instead of a template as
+ parameter. Consequence is that the title will not be translatable,
+ unless some other mechanism (like gettext) is used.
+ </para>
</listitem>
<listitem id="command_stop">
<para>
diff -ur debian-policy.orig/debconf_spec/include/types.xml debian-policy/debconf_spec/include/types.xml
--- debian-policy.orig/debconf_spec/include/types.xml 2009-08-16 02:19:11.000000000 +0200
+++ debian-policy/debconf_spec/include/types.xml 2009-12-10 23:58:22.000000000 +0100
@@ -69,6 +69,13 @@
as is possible.
</entry>
</row>
+ <row>
+ <entry>title</entry>
+ <entry>
+ Holds a (short) string that can be displayed using the SETTITLE
+ command. Only the value of the short description will be used.
+ </entry>
+ </row>
</tbody>
</tgroup>
</table>

Processed: Re: Bug#560287: debian-policy: document dfsg, ds and debian suffix of version numbers when repackaging

2009-12-10T11:39:09Z

Processing commands for control@...:

> reassign 560287 developers-reference
Bug #560287 [debian-policy] debian-policy: document dfsg, ds and debian suffix of version numbers when repackaging
Bug reassigned from package 'debian-policy' to 'developers-reference'.
Bug No longer marked as found in versions debian-policy/3.8.3.0.
> thanks
Stopping processing here.

Please contact me if you need assistance.

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

--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#560287: debian-policy: document dfsg, ds and debian suffix of version numbers when repackaging

2009-12-10T11:35:42Z

reassign 560287 developers-reference
thanks

Thomas Koch <thomas@...> writes:

> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist

> The proper use of dfsg, ds or debian as version number suffix in case of
> repackagaged upstream tarballs is not documented anywhere. It's also not
> clear, wether the suffix should be appended with a point, a dash or a
> tilde.

I think this is a devref thing, so I'm taking the liberty of reassigning
it accordingly. Policy doesn't care what string you use, since it's not
an interface and software doesn't rely on the value of the string (other
than Lintian, but that's a special case).

Lintian's recommendation is to use a + because it sorts before a period if
upstream adds an additional level of version number. Some people use a
tilde instead, which also works but has slightly different effects and
can't easily be used if you already uploaded the unmunged version.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-10T02:13:31Z

Le Fri, Dec 04, 2009 at 04:44:51PM -0800, Russ Allbery a écrit :
>
> <p>
> Every binary package must include a verbatim copy of its
> copyright and distribution license in the file
> <file>/usr/share/doc/<var>package</var>/copyright</file> or
> symlink the <file>/usr/share/doc/<var>package</var> directory to
> a package that does (see <ref id="copyrightfile"> for further
> details).

Dear Russ and everybody,

a small nitpicking here: in many packages, the copy of the license and
copyright information is not verbatim. For instance:

- we correct the FSF address in the GPL,
- we often collapse copyright statements.

While I have no doubt that the current wording is not ambiguous for active
developers, I am a little bit concerned that it could confuse newcommers.

I understand that ‘verbatim’ is already in the current Policy wording, but
since the topic of this bug is ‘Clarify requirements for copyright file’, I
wonder if it should be addressed. In that case, we may need to wait for the
report of the SPI lawyers who were asked some questions related to this issue…

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#560287: debian-policy: document dfsg, ds and debian suffix of version numbers when repackaging

2009-12-10T01:23:51Z

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

The proper use of dfsg, ds or debian as version number suffix in case of
repackagaged upstream tarballs is not documented anywhere. It's also not
clear, wether the suffix should be appended with a point, a dash or a
tilde.

-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (1000, 'stable'), (990, 'unstable'), (700, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii doc-base 0.9.5 utilities to manage online documen

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Come join me on Government Lists - U.S. | Canada

2009-12-09T06:28:05Z

Network Email

Join me on Government Lists - U.S. | Canada

REACH YOUR KEY GOVERNMENT AUDIENCE EASILY!

government--
mailing--
lists.com has:

1 blog post

I welcome you to join me on this business network.

REACH YOUR KEY GOVERNMENT AUDIENCE EASILY!
http://www.government-mailing-lists.com

Click to Join

Members on Government Lists - U.S. | Canada:

government--
mailing--
lists.com

Richard Furlong

Ryan Sharpe

Jim Kellough

Nitin Chaudhry

About Government Lists - U.S. | Canada

government-mailing-lists.com is the key-contact database for reaching government markets. Government Lists – U.S. | Canada

10 photos

To control which emails you receive on Government Lists - U.S. | Canada, click here

Sitenizi ekleyin !

2009-12-07T16:29:31Z

Sitenizi ekleyin www

Sitenizi ekleyin

www.WebdeBul.com

Türk İş Dünyasının Kalbi'nde Yerinizi alın !

2009-12-07T10:13:09Z

Sizleride aramızda görmekten mutlluluk duyarız

Sizleride aramızda görmekten mutlluluk duyarız.

Firmanızı ekleyin, Ürün ve hizmetlerinizi tanıtın, Alım satım taleplerini değerlendirin, bu devasa Networkte yeni iş bağlantıları kurun.
Alın , satın KAZANIN

www.worldbusinessturk.com

Türk İş Dünyasının Kalbi

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-06T21:46:29Z

Steve Langasek <vorlon@...> writes:
> On Sun, Dec 06, 2009 at 09:18:21PM -0800, Russ Allbery wrote:

>> No, Lintian has a special tag that it issues when it's checking a binary
>> package in isolation and therefore can't double-check that the doc symlink
>> points within the same source package. That tag isn't (and certainly
>> shouldn't be) something that the archive auto-rejects on.

> Does lintian issue that tag when the package isn't being checked in
> isolation, it's being checked via the .changes file for a -B upload?

Looks that way.

# We can only check if both packages come from the same source
# if our source package is currently unpacked in the lab, too!
if (-d "source") { # yes, it's unpacked

# $link from the same source pkg?
if (-l "source/binary/$link") {
# yes, everything is ok.
} else {
# no, it is not.
tag "usr-share-doc-symlink-to-foreign-package", "$link";
}
} else { # no, source is not available
tag "cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package", "";
}

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-06T21:26:45Z

On Sun, Dec 06, 2009 at 09:18:21PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon@...> writes:

> > If one package is arch: any and one package is arch: all, won't the lintian
> > check fail anyway in the event of a -B build (as happens on all the
> > autobuilders), due to the arch: all package being unavailable? Would this
> > translate to an archive auto-reject?

> No, Lintian has a special tag that it issues when it's checking a binary
> package in isolation and therefore can't double-check that the doc symlink
> points within the same source package. That tag isn't (and certainly
> shouldn't be) something that the archive auto-rejects on.

Does lintian issue that tag when the package isn't being checked in
isolation, it's being checked via the .changes file for a -B upload?

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-06T21:18:21Z

Steve Langasek <vorlon@...> writes:

> If one package is arch: any and one package is arch: all, won't the lintian
> check fail anyway in the event of a -B build (as happens on all the
> autobuilders), due to the arch: all package being unavailable? Would this
> translate to an archive auto-reject?

No, Lintian has a special tag that it issues when it's checking a binary
package in isolation and therefore can't double-check that the doc symlink
points within the same source package. That tag isn't (and certainly
shouldn't be) something that the archive auto-rejects on.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#555982: debian-policy: RPATH in binaries and shared libraries

2009-12-06T20:23:23Z

On Wed, Dec 02, 2009 at 10:29:17PM +0100, Kurt Roeckx wrote:
> So /usr/lib/libextractor.so.1 should either set up an rpath
> for /usr/lib/libextractor/ or tell the full path to the dynamic
> loader when it tries to load it's plugins.

Preferably the latter; I don't see the point in using rpath for something
other than shared library linking, and it just gets you a complimentary
lintian error, so... (Also, doing this via rpath will, infinitesimally,
slow down the *actual* shared library lookups at startup time.)

> If they weren't plugins you load dynamicly, but something you link
> too, I have mixed feelings about using an rpath.

I don't... in that case they should be in /usr/lib. :)

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-06T20:08:43Z

On Fri, Dec 04, 2009 at 04:39:39PM -0800, Russ Allbery wrote:
> > Should we tighten this to be a dependency on the same version? Otherwise
> > it would be possible to have the two packages coming from different
> > versions of the source package where the license changed in between,
> > with wrong information in the copyright file for the package that has a
> > symlink. Not sure if this hypothetical case is worth the trouble.

> My inclination is to say no, since there are various tricky problems with
> requiring the dependency be on the same version when one package is arch:
> any and one package is arch: all. There's also been push-back in
> debian-devel against a Lintian tag requiring that the dependency be on the
> same version, so there's some evidence that we don't have consensus for
> requiring that.

If one package is arch: any and one package is arch: all, won't the lintian
check fail anyway in the event of a -B build (as happens on all the
autobuilders), due to the arch: all package being unavailable? Would this
translate to an archive auto-reject?

(I accept that it may not be the consensus, but at least in the case of
arch:any -> arch:all dependencies within a source package, it's always safe
and appropriate to use (= ${source:Version}) in the dependency; that
wouldn't be the /same/ version, but it's not guaranteed that all binary
package from a given source package have the same binary version number,
either - what matters is the "=" here.)

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Bug#556015: debian-policy: Clarify requirements for copyright file

2009-12-06T20:03:11Z

On Fri, Dec 04, 2009 at 04:44:51PM -0800, Russ Allbery wrote:

> >> + <item>
> >> + All the requirements for using a symlink instead of a
> >> + directory as <file>/usr/share/doc/<var>package</var></file>
> >> + described in <ref id="addl-docs"> must be met. This means
> >> + both packages must come from the same source package and the
> >> + package must depend on the package containing its copyright
> >> + and distribution license.
> >> + </item>
> >> +
> >> + <item>
> >> + There must be a direct dependency on the package containing
> >> + the copyright and distribution license. An indirect
> >> + dependency via a third package is not sufficient.
> >> + </item>

> > Some package currently don't do this, but have an A->B->C dependency,
> > where A, B and C are all from the same source package and C contains the
> > copyright. I guess it would be good to have some input from a
> > maintainer that does that.

> Lintian has been warning about this for some time, and I think it may even
> be an ftp-master reject at this point. The logic has been that we don't
> require software looking for copyright files to implement full transitive
> dependency logic, only look in a package and its immediate dependencies.
> I'm okay with relaxing that if we come up with good alternative wording,
> but it's different from what we've required,

I don't agree that this has ever been required prior to the start of
ftp-master lintian rejects. Lintian is not the standard for what we
require, Policy is; and I don't think "[the package] must be accompanied by
a verbatim copy [in /usr/share/doc/$package/copyright]" implied any of these
requirements. I think it's clear from context that the intent is to ensure
/usr/share/doc/$package/copyright is present *when all of the package's
dependencies are installed*; if the intent were otherwise, it could have
been stated more simply as "the package must *contain* a verbatim copy
[...]".

So far from being a simple clarification of Policy, I think this is a change
which makes packages buggy under Policy that were not previously. I
understand the desire to align the Policy rule with what lintian can
reasonably check on a per-source-package basis, but I don't think this
should be made a "must" in advance of the archive actually being in
conformance.

> and I'm not sure it's really worth the effort. It's not that difficult to
> add the additional direct dependency, and it amounts to a no-op from the
> package management perspective.

There are various operations for which the number of package relationships
in the archive as a whole, or within a cluster of related packages, dominate
the equation. The requirement of an additional direct dependency is
reasonable, but not a no-op.

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment