Re: old homepage pseudo-field (future mass-bug filing?)

[Christian Perrier]

Quoting Stefano Zacchiroli ([EMAIL PROTECTED]):
> Hi, at http://sockmel.bononia.it/~zack/homepage-field/ I'm collecting
> some numbers about the usage of the new homepage field in debian/control
> vs that of the old pseudo-field in package description.
> 
> There should be all the info needed for a wish-list mass-bug filing ([1]
> is a direct link to a dd-list, so that people can check for false
> positives), though right now is probably too early (4'000 packages to
> go), but I'm not sure about the current policies for mass-bug filings.


I updated http://wiki.debian.org/DpkgHomepageFieldTransition with a
link to zack's pages as well as updated status for the various steps
described there.

With Manoj starting some cleaning work on policy's bug reports, I
expect the Policy part to be updated quite soon as well (would be good
for me to send a patch)



signature.asc
Description: Digital signature

Draft new policy document format

[Manoj Srivastava]

Hi,

At Debconf earlier this year, I gave a talk about the benefits
 of creating language for a lintian/linda check whenever we introduce a
 new policy rule (when appropriate, and feasible, of course).  Not only
 do we get a  instant Lintian check, but it would also tend to focus the
 discussion and design of the policy rule.

There a re a number of bits and pieces of policy scattered
 across several documents, not all of which can be found in the policy
 package.  These documents cover different areas, Menu, Python, Perl, X,
 etc. They also are at different places in the spectrum from release
 critical measures to best practice recommendations.

Also, there are various levels at which people tend to approach
 the policy document;  some people prefer reading the document by
 topics; which is useful is one is packaging something  in a topic area
 covered by multiple policy documents; others just want to see the
 "hard" policy rules, and defer best practices until later, to prevent
 being drowned in a flood of information.

Then there is the dimension of Debian sub projects and
 Derivatives, who would perhaps benefit from deriving from Debian
 policy, but adding some specialized directives of their own.

One solution that enables all these use cases is doing a set of
 books,  each book being a separate entity, with different author sets,
 but all using a common schema; each rule is an entity, has title,
 severity, normative section, rationale, informative section, and
 lintian psuedo-code.  Each book can have separate copyrights, SCM
 systems, and can even be compiled and published separately.

Each rule can become a separate XML entity, and live in a shared
 location on disk like /usr/share/debian-policy/.
 This way, you have a published book, and a dev version that has the
 entity definitions in a well known place; and people can create their
 own sets, reorder the rules, select only rules in a certain topic area,
 add rules of their own, or whatever.

In other words, you can then cherry pick the best part of each
 others manuals/

I had a conversation earlier with Roland Mas, he says that 
 it's pretty easy then to write an XSLT stylesheet, or a Perl script,
 that could parse the set/book/article/rule and ensure that all required
 sections are present in the correct order. You can even decide to show
 or hide various sections when rendering a final document; for instance
 if you want to generate a PDF of only the normative part of the Perl
 policy, you can decide to hide the lintian code and rationale; again,
 it's "a simple matter of XSLT".

With this in mind, I have created an initial draft format of the
 Debian technical policy set, and am including it in this mail.

Comments appreciated.

manoj


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";>

  The Debian policy Manual Set
  Debian Policy Set
  

  Manoj
  Srivastava


  2007


  
This set outline free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
  
  
This document is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.  See the GNU General Public License for more
details. 
  
  
You should have received a copy of the GNU General Public
License along with this document; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA  02111-1307  USA 
  

The Debian Project

  
November 30th, 2007

  Initial draft

  

  

  
The Debian Technical Policy Manual

  
ManojSrivastava
  
  
2007
  
  

  This set outline free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License as
  published by the Free Software Foundation; either version 2 of
  the License, or (at your option) any later version.


  This document is distributed in the hope that it will be
  useful, but WITHOUT ANY WARRANTY; without even the implied
  warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.  See the GNU General Public License for more
  details. 


  You should have received a copy of the GNU General Public
  License along with this document; if not, write to the Free
  Software Foundation, Inc., 59 Temple Place, Suite 330,
  Boston, MA 02111-1307 USA.  A copy of the GNU General Public
  License is avail

Re: Bug#451799: new evince cannot display Japanese characters correctly

[Martín Ferrari]

(Dropping -legal from the cc)

On Nov 27, 2007 3:56 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> The new poppler version needs some specific files that contain some
> mappings between Unicode and other encodings, which are in a separate
> package.

That's all that it contains? can't that be reproduced with data from
iconv or similar?

-- 
Martín Ferrari

Triaging bugs

[Manoj Srivastava]

Hi,

I think I am coming up on a period where I have time again to
 devote to Debian, and am beginning to start to triage some policy bugs,
 to chime in and help out russ, who has mostly been carrying the torch
 the last few months.

Following his example, I have created usecategories to help me
 triage the policy issue, and  be more efficient while working on the
 policy package; and I figured that if I share it with y'all maybe I
 could sucker^H^H^H^H^H^Hentice afew people to pitch in help move the
 process along.

Once we have some experience working with this, and figuring out
 the right granularity of the categories, perhaps we'll create a
 [EMAIL PROTECTED] usercategory for the official state of
 the policy  process.


So, here is my classification of policy issues, with the
 unclassified bugs bubbling to the top. Enjoy.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&[EMAIL 
PROTECTED]&ordering=policy


manoj
-- 
Cheer Up!  Things are getting worse at a slower rate.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Heimdal changes

[C.J. Adams-Collier]

No response on -mentors in > 24 hours, so I'm looping in -devel.

Cheers,

C.J.


On Nov 29, 2007 8:33 AM, C.J. Adams-Collier <[EMAIL PROTECTED]> wrote:

> Hey folks,
>
> I'm looking to make some changes to the heimdal debian packages.
> Currently, the heimdal-kdc package contains the following daemons:
>
> * ./usr/lib/heimdal-servers/kdc
> * ./usr/lib/heimdal-servers/kadmind
> * ./usr/lib/heimdal-servers/kpasswd
>
> If I understand correctly, kdc is responsible for checking credentials
> and issuing tickets, kpasswd is responsible for updating credentials,
> and kadmind is responsible for remote administration of credentials.
>
> As it stands, kadmind is started only from inetd.  During a perusal of
> the docs, I found the following:<
> 4.6 Remote administration
> =
>
> The administration server, `kadmind', can be started by `inetd' (which
> isn't recommended) or run as a normal daemon. If you want to start it
> from `inetd' you should add a line similar to the one below to your
> `/etc/inetd.conf'.
> EOF
>
> I modified my krb5.conf file so that heimdal stores its principals in an
> LDAP data store.  A peculiarity of this configuration is that kadmind
> expects the access control file to be named after the LDAP dn of the
> principal container node and to be in the current directory:<
> [EMAIL PROTECTED]:~$ ls -l /etc/heimdal-kdc/*.acl
> -rw-r--r-- 1 root root 156 Nov  8 18:00 /etc/heimdal-kdc/kadmind.acl
> lrwxrwxrwx 1 root root  28 Nov  8 17:31
> /etc/heimdal-kdc/ldap:ou=KerberosPrincipals,dc=cls2,dc=colliertech,dc=
> org.acl -> /etc/heimdal-kdc/kadmind.acl
> EOF
>
> In order to set $PWD to the correct value, inetd would need to call a
> wrapper which does the chdir(2) and exec(3) .  I haven't gotten around
> to creating one, since the documentation advises against a configuration
> which uses inetd and hints toward eventual deprecation / obsolescence of
> inetd support.
>
> I have instead created some extra package files in
> heimdal-0.7.2.dfsg.1/debian/ which will (hopefully) configure kadmind to
> run as a daemon.  When I get it working on my system, I'll submit a
> patch to the BTS and prostrate myself for a beating.
>
> At this point, it seems that kadmind and kpasswd should be de-coupled
> from kdc and moved into their own packages.  I can imagine many use
> cases where administrators wouldn't feel comfortable opening a TCP port
> for remote administration of kerberos principals, and "slave" servers
> should not run kpasswd.  Allowing sysadmins to choose not to install the
> daemons seems a useful feature.
>
> Currently, all heimdal servers run as root.  Yipe.  We should probably
> create a system user and group as well as an SELinux MAC policy.
> This /is/ a network authentication infrastructure, after all.
>
> [EMAIL PROTECTED]:~$ ps auwx | grep heimdal | grep root
> root  1776  0.0  4.1   7164  2712 ?Ss   06:13   0:00
> /usr/lib/heimdal-servers/kdc
> root  1778  0.0  2.6   6172  1740 ?Ss   06:13   0:00
> /usr/lib/heimdal-servers/kpasswdd
>
> While going through all of this, I considered requirements to ease the
> process of modifying the heimdal packages to configure the system to use
> alternative principal sources.  Is it possible to have one package query
> another's entries in the database?  How about making modifications to
> another's configuration?  In order to store to OpenLDAP, heimdal would
> benefit from being able to discover some system settings:
>
> * the configured LDAP base DN
> * LDAP bind dn and password capable of creating the KerberosPrincipals
> ou and a bind dn for the heimdal daemons' access to principals
>
> Additionally, the package would need to cause some modifications
> to /etc/default/slapd and /etc/ldap/slapd.conf, which are owned by the
> slapd package.
>
> * /etc/default/slapd:
> ** SLAPD_SERVICES="$SLAPD_SERVICES ldapi:///"
>
> /etc/ldap/slapd.conf:
> ** include /etc/ldap/schema/hdb.schema
> ** localSSF 
> ** sasl-secprops minssf=
> ** sasl-regexp "gidNumber=\\\+uidNumber= UID>,cn=peercred,cn=external,cn=auth"
>""
> ** access to dn.subtree=
>by dn=""
>
> Will heimdal packages need to ask slapd to re-configure itself with
> these modifications, or can they make modifications in such a way that
> slapd won't over-ride them and will recognize them when the user
> re-configures?
>
> If heimdal is configured to store principals to LDAP, removal of slapd
> would break the system's kerberos settings, unless principals were
> dumped to heimdal's native database and the /etc/krb5.conf were updated
> to reflect the change.
>
> I would like to see a simple set of regression tests run after
> (re)configuration of slapd and heimdal packages.  This would ensure that
> the heimdal user is able to access and modify principals.  There should
> also be a rollback mechanism in case the regression tests fail.  I'd
> hate to see an automated update cause a kerberos outage until a human
> was able to fix t

Re: old homepage pseudo-field (future mass-bug filing?)

[Russ Allbery]

Adeodato Simó <[EMAIL PROTECTED]> writes:
> * Christian Perrier [Fri, 30 Nov 2007 17:55:43 +0100]:

>> IIRC (I can't check online right now), it was agreed that a lintian
>> check would help a lot *before* the MBF, in order to minimize the size
>> of the MBF.

> Yeah, such test already exists, but it's an Info:, not a Warning:
> (that's what Russ thought it was appropriate at the time).
>
> When the field has reached critical mass, I guess it'll be time to ask
> lintian maintainers to bump the I to W. Or maybe it's even time for that
> now.
>
> You're right that with it becoming W, the MBF should be much much
> smaller.

I was hesitant to make it a warning because it doesn't really break
anything about the package, but I suppose there's really no point in
keeping the old fields around.

I'll upgrade it for the next lintian release.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Michael Shuler]

On 11/30/2007 11:51 AM, Milan P. Stanic wrote:
> Are you sure that the complete package is in the public domain?
> Some files are, but not all of them, AFAIK.

There has been some additional discussion on this topic in BTS, as well
as some other places.

http://bugs.debian.org/453680
http://linux.slashdot.org/article.pl?sid=07/11/30/0430201
http://video.google.com/videoplay?docid=-3147768955127254412

-- 
Michael


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

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Kevin B. McCarty]

Kevin B. McCarty wrote:

> Assuming that qmail-1.03.tar.gz contains all the code written by DJB
> that's needed to build qmail, that seems pretty explicit.

My apologies, I briefly confused qmail and djbdns.  Good news for the
qmail maintainers, at any rate.  I have not yet found an explicit
re-licensing of djbdns or daemontools on cr.yp.to (which is currently
very slow, probably slashdotted).

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751


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

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Russ Allbery]

Robert Edmonds <[EMAIL PROTECTED]> writes:

> Package: wnpp
> Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
> Severity: wishlist
>
> * Package name: djbdns
>   Version : 1.05
>   Upstream Author : Daniel J. Bernstein
> * URL : http://cr.yp.to/djbdns.html
> * License : public domain

I'm pretty sure this isn't the case.  See:

http://cr.yp.to/distributors.html

Also note the djbdns-installer package already in contrib.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Kevin B. McCarty]

Milan P. Stanic wrote:

> On Fri, Nov 30, 2007 at 10:24:48AM -0500, Robert Edmonds wrote:

>> Supposedly DJB has released all of his code into the public domain.  If
>> this is really the case and passes DFSG, I plan to package djbdns
>> assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to.
> 
> Are you sure that the complete package is in the public domain?
> Some files are, but not all of them, AFAIK.


The text on http://cr.yp.to/qmail/dist.html now reads:

> I hereby place the qmail package (in particular, qmail-1.03.tar.gz, with MD5 
> checksum 622f65f982e380dbe86e6574f3abcb7c) into the public domain. You are 
> free to modify the package, distribute modified versions, etc.
> 
> This does not mean that modifications are encouraged! Please take time to 
> ensure that your distribution of qmail supports exactly the same interface as 
> everyone else's. In particular, if you move files, please set up symbolic 
> links from the original locations, so that you don't frivolously break 
> scripts that work everywhere else. 

Assuming that qmail-1.03.tar.gz contains all the code written by DJB
that's needed to build qmail, that seems pretty explicit.

best regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751


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

Re: old homepage pseudo-field (future mass-bug filing?)

[Adeodato Simó]

* Christian Perrier [Fri, 30 Nov 2007 17:55:43 +0100]:

> IIRC (I can't check online right now), it was agreed that a lintian
> check would help a lot *before* the MBF, in order to minimize the size
> of the MBF.

Yeah, such test already exists, but it's an Info:, not a Warning:
(that's what Russ thought it was appropriate at the time).

When the field has reached critical mass, I guess it'll be time to ask
lintian maintainers to bump the I to W. Or maybe it's even time for that
now.

You're right that with it becoming W, the MBF should be much much
smaller.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain


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

Re: Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Milan P. Stanic]

On Fri, Nov 30, 2007 at 10:24:48AM -0500, Robert Edmonds wrote:
> Package: wnpp
> Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
> Severity: wishlist
> 
> * Package name: djbdns
>   Version : 1.05
>   Upstream Author : Daniel J. Bernstein
> * URL : http://cr.yp.to/djbdns.html
> * License : public domain
>   Programming Lang: C
>   Description : Replacement for BIND, written by Dan Bernstein
[...]
> Supposedly DJB has released all of his code into the public domain.  If
> this is really the case and passes DFSG, I plan to package djbdns
> assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to.

Are you sure that the complete package is in the public domain?
Some files are, but not all of them, AFAIK.



signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Christian Perrier]

Quoting Stefano Zacchiroli ([EMAIL PROTECTED]):
> Hi, at http://sockmel.bononia.it/~zack/homepage-field/ I'm collecting
> some numbers about the usage of the new homepage field in debian/control
> vs that of the old pseudo-field in package description.
> 
> There should be all the info needed for a wish-list mass-bug filing ([1]
> is a direct link to a dd-list, so that people can check for false
> positives), though right now is probably too early (4'000 packages to
> go), but I'm not sure about the current policies for mass-bug filings.

May I point you to http://wiki.debian.org/DpkgHomepageFieldTransition ?


A plan is detailed there, which is the consequence of discussions back
in September.

IIRC (I can't check online right now), it was agreed that a lintian
check would help a lot *before* the MBF, in order to minimize the size
of the MBF.

If you automate some data collection (which is good), I suggest you
link this on that wiki page.




signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Miriam Ruiz]

2007/11/30, Adeodato Simó <[EMAIL PROTECTED]>:
> * Miriam Ruiz [Fri, 30 Nov 2007 18:38:30 +0100]:
>
> > So your suggestion is to remove the pseudo-field from the description
> > now? If it is so, please say, so we can move towards there :)
>
> Yes, that'd be the suggestion.

Thanks Dato, we'll review the policy we're following in the Games Team
about that :)

Miry

Re: old homepage pseudo-field (future mass-bug filing?)

[Adeodato Simó]

* Miriam Ruiz [Fri, 30 Nov 2007 18:38:30 +0100]:

> So your suggestion is to remove the pseudo-field from the description
> now? If it is so, please say, so we can move towards there :)

Yes, that'd be the suggestion.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane


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

Re: old homepage pseudo-field (future mass-bug filing?)

[Miriam Ruiz]

2007/11/30, Bernd Zeimetz <[EMAIL PROTECTED]>:
> for a backport you have to add a changelog entry anyway, fixing the
> Homepage field is not that complicated, so I can't see a problem here.

So your suggestion is to remove the pseudo-field from the description
now? If it is so, please say, so we can move towards there :)

Greetings,
Miry


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

Re: old homepage pseudo-field (future mass-bug filing?)

[Bernd Zeimetz]

Stefano Zacchiroli wrote:
> On Fri, Nov 30, 2007 at 03:10:49PM +0100, Adeodato Simó wrote:
>> Backports. Old dpkgs will ignore the Homepage field.
> 
> Ermm .. ok, but (general question) do we really want to slow-down the
> spreading of some best practice to not hinder backport-ability?  After
> all backports is not an official part of Debian. YMMV.
> 

for a backport you have to add a changelog entry anyway, fixing the
Homepage field is not that complicated, so I can't see a problem here.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: old homepage pseudo-field (future mass-bug filing?)

[gregor herrmann]

On Fri, 30 Nov 2007 16:03:34 +0100, Luca Capello wrote:

> While my packages are not false positive if we consider the version in
> the archive, they're false positive if we consider the Debian VCS
> version.  

Same here (both for my "own" packages and for all packages of the
pkg-perl group).

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Queen: My Fairy King


signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Stefano Zacchiroli]

On Fri, Nov 30, 2007 at 04:03:34PM +0100, Luca Capello wrote:
> Stefano, why your d-d alias says "Debian Devel Italian ML"?  ;-)

Because I messed up my headers before sending the mail :-)

> While my packages are not false positive if we consider the version in
> the archive, they're false positive if we consider the Debian VCS
> version.  In fact, I already replaced the old homepage-in-Description
> with the new Homepage: field, but for one reason or another the updated
> version hasn't uploaded yet.

Well, to me this is 1-1 with bug tagged +pending in the BTS. The bug is
there, it is just that it will be fixed with the next upload. Though my
lists do not show bugs, they show potential bugs and they do so using
the latest version of the package in the archive.

After all the Homepage field is to the benefit of our users, and as long
as the fixed package is in your repository they can't take benefit of
the fix.

Cheers.

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


signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Stefano Zacchiroli]

On Fri, Nov 30, 2007 at 03:10:49PM +0100, Adeodato Simó wrote:
> Backports. Old dpkgs will ignore the Homepage field.

Ermm .. ok, but (general question) do we really want to slow-down the
spreading of some best practice to not hinder backport-ability?  After
all backports is not an official part of Debian. YMMV.

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


signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Luca Capello]

Hi all!

Stefano, why your d-d alias says "Debian Devel Italian ML"?  ;-)

On Fri, 30 Nov 2007 13:30:55 +0100, Stefano Zacchiroli wrote:
> There should be all the info needed for a wish-list mass-bug filing
> ([1] is a direct link to a dd-list, so that people can check for false
> positives),
>
> [1] 
> http://sockmel.bononia.it/~zack/homepage-field/pkg_w_old_homepage_pseudo_field.dd-list.txt

First of all, thank you for your check!

While my packages are not false positive if we consider the version in
the archive, they're false positive if we consider the Debian VCS
version.  In fact, I already replaced the old homepage-in-Description
with the new Homepage: field, but for one reason or another the updated
version hasn't uploaded yet.

I don't know how many corner cases like mine exist, but IMO it's
something we should consider.

Thx, bye,
Gismo / Luca


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

Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein

[Robert Edmonds]

Package: wnpp
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: djbdns
  Version : 1.05
  Upstream Author : Daniel J. Bernstein
* URL : http://cr.yp.to/djbdns.html
* License : public domain
  Programming Lang: C
  Description : Replacement for BIND, written by Dan Bernstein
 The following were taken from various HTML pages under
 http://cr.yp.to/djbdns.html
 .
 dnscache is a local DNS cache. It accepts recursive DNS queries from
 local clients such as web browsers and mail transfer agents. It
 collects responses from remote DNS servers. It caches the responses to
 save time later.
 .
 tinydns is a DNS server. It accepts iterative DNS queries from hosts
 around the Internet, and responds with locally configured information.
 .
 pickdns is a load-balancing DNS server. It accepts iterative DNS
 queries from hosts around the Internet, and responds with a dynamic
 selection of locally configured IP addresses with 5-second TTLs.
 .
 walldns is a reverse DNS wall. It accepts iterative DNS queries for
 in-addr.arpa domains from hosts around the Internet, and supplies
 generic responses that avoid revealing local host information.
 .
 rbldns is an IP-address-listing DNS server. It accepts iterative
 DNS queries from hosts around the Internet asking about various IP
 addresses.  It provides responses showing whether the addresses are on
 a locally configured list, such as RBL or DUL.
 .
 axfrdns is a DNS zone-transfer server. It reads a zone-transfer
 request in DNS-over-TCP format from its standard input, and responds
 with locally configured information.
 .
 The security of this software is guaranteed by the author.  Details of
 the guarantee can be found at http://cr.yp.to/djbdns/guarantee.html

 (snagged from the djbdns-installer djbdns description)

Supposedly DJB has released all of his code into the public domain.  If
this is really the case and passes DFSG, I plan to package djbdns
assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to.

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Adeodato Simó]

* Stefano Zacchiroli [Fri, 30 Nov 2007 15:05:11 +0100]:

> So, what are the cases where a package with the new field would need to
> have also the old pseudo-field to avoid risking that the information is
> not shown?

Backports. Old dpkgs will ignore the Homepage field.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: The Magnetic Fields - Underwear


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

Re: old homepage pseudo-field (future mass-bug filing?)

[Stefano Zacchiroli]

On Fri, Nov 30, 2007 at 01:37:14PM +0100, Miriam Ruiz wrote:
> My personal position about this, as well as the current policy for the
> packages maintained by the Games Team, is to have simultaneously both
> the new Homepage header as well as the old pseudo-field in the

I really do not see the point of this. apt-cache showsrc show both the
description and all fields (hence including Homepage) and
packages.debian.org already shows the new field on the right.

So, what are the cases where a package with the new field would need to
have also the old pseudo-field to avoid risking that the information is
not shown?

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


signature.asc
Description: Digital signature

Re: adding user to package-forreign group

[Marvin Renich]

* Micha Lenk <[EMAIL PROTECTED]> [071129 17:27]:
[snip]
> 
> But prior to releasing the package I am seeking for feedback here,
> whether that really is a good idea. Is there anything that I missed? Is
> it okay to mess around with other package's group memberships? Any other
> comments?
> 
> Please give me feedback about whether to proceed this way or not.
> 
> Regards
>   Micha
> 

This is somewhat of a hack, but since we are talking about a user
"chipcard" and a group "cyberjack", can you have udev assign ownership
to chipcard:cyberjack?  I believe udev can handle separate files in
/etc/udev/rules.d/ so that the libchipcard package can have its own file
that adds chipcard as the owner without changing the group assigned by a
previous udev rule.  This would allow anyone who follows directions
found on the internet to still have it work, but for libchipcard to be
able to function without possibly interfering with an existing user
cyberjack that is unrelated to this smart card reader.  (I agree with
another post in this thread about not adding chipcard to the cyberjack
group unless you are sure that the cyberjack group is only used for the
purpose you think it is.)

Martin, does the udev rule for the Cyberjack specify root as owner, or
does it only specify the group?  I've only done simple things with udev,
so I'm not sure how two rules specifying conflicting owners would work.

Micha, if there is more to the cyberjack software than just a kernel
module and udev rule, and if you had the inclination, you could package
cyberjack as a separate Debian package, and then you would have control
of how the udev rules were set up for both packages.  Debian users who
install an official Debian cyberjack package (from main or non-free)
will, in general, expect the debian package to "get it right" and will
not be messing around with instructions found on the web.  Proper
instructions in README.Debian in both packages should clarify any
ambiguities.

My opinion is that the Debian package should make things work for
Debian, even when deviating from published instructions for non-Debian
users.  This gets trickier, as you are experiencing, when a Debian
package has to interact with non-Debian software, but if you package
cyberjack for Debian, that minimizes the impact on upstream support, as
most naive Debian users will contact Debian first, and the less naive
will read README.Debian.


I've never used libchipcard or a Cyberjack reader, nor have I looked at
the instructions for installing or using either.


...Marvin


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

Re: old homepage pseudo-field (future mass-bug filing?)

[Cyril Brulebois]

On 30/11/2007, Miriam Ruiz wrote:
> My personal position about this, as well as the current policy for the
> packages maintained by the Games Team, is to have simultaneously both
> the new Homepage header as well as the old pseudo-field in the
> description for a while, until the former is started to be used. In
> any case, we even go a bit longer than that anyway, and keep both for
> a bit longer, to make life easier to backports.

I don't really see the point about doing so, actually. If it has the new
field, it gets discarded by older dpkg w/o any errors. If it hasn't,
what's the problem? p.d.o displays the right information, I believe. And
if someone is skillzzzed enough to install backports, one should be able
to find the Homepage information on p.d.o.

> Maybe it would be useful to have a list of the packages that have the
> old pseudo-field in the description and simultaneously do not have the
> newer field in control.

That sounds way better to me.

Cheers,

-- 
Cyril Brulebois


pgpqB5DkAkPle.pgp
Description: PGP signature

Re: xinetd is a viable inet-superserver

[Marco d'Itri]

On Nov 29, Roger Leigh <[EMAIL PROTECTED]> wrote:

> - create a /etc/inetd.d directory
Wrong approach. Write an update-inetd replacement which can maintain its
own database and can compare it to an existing configuration to know if
the local admin changed something.

> IIRC I did mention something along these lines for consideration
So I probably already told you that you were wrong.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: old homepage pseudo-field (future mass-bug filing?)

[Miriam Ruiz]

2007/11/30, Stefano Zacchiroli <[EMAIL PROTECTED]>:
> Hi, at http://sockmel.bononia.it/~zack/homepage-field/ I'm collecting
> some numbers about the usage of the new homepage field in debian/control
> vs that of the old pseudo-field in package description.
>
> There should be all the info needed for a wish-list mass-bug filing ([1]
> is a direct link to a dd-list, so that people can check for false
> positives), though right now is probably too early (4'000 packages to
> go), but I'm not sure about the current policies for mass-bug filings.
>
> Cheers.
>
> [1] 
> http://sockmel.bononia.it/~zack/homepage-field/pkg_w_old_homepage_pseudo_field.dd-list.txt

My personal position about this, as well as the current policy for the
packages maintained by the Games Team, is to have simultaneously both
the new Homepage header as well as the old pseudo-field in the
description for a while, until the former is started to be used. In
any case, we even go a bit longer than that anyway, and keep both for
a bit longer, to make life easier to backports.

Maybe it would be useful to have a list of the packages that have the
old pseudo-field in the description and simultaneously do not have the
newer field in control.

Greetings,
Miry


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

old homepage pseudo-field (future mass-bug filing?)

[Stefano Zacchiroli]

Hi, at http://sockmel.bononia.it/~zack/homepage-field/ I'm collecting
some numbers about the usage of the new homepage field in debian/control
vs that of the old pseudo-field in package description.

There should be all the info needed for a wish-list mass-bug filing ([1]
is a direct link to a dd-list, so that people can check for false
positives), though right now is probably too early (4'000 packages to
go), but I'm not sure about the current policies for mass-bug filings.

Cheers.

[1] 
http://sockmel.bononia.it/~zack/homepage-field/pkg_w_old_homepage_pseudo_field.dd-list.txt

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


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