Re: Patch Tagging Guidelines (aka DEP3)

[Ben Finney]

Raphael Hertzog  writes:

> On Tue, 08 Sep 2009, Bjørn Mork wrote:
> > Just a minor comment on the examples: Please either use your own domain
> > names or one of the names reserverd for examples.  foobar.com is
> > registered to Foobar Consulting.  They're probably used to this kind of
> > abuse, but still...
>
> Fixed too, I was already using example.com for a fake URL and I needed
> another different domain for the author. I used a Debian one, now.

Better than using a Debian one, you can make use of any or all of
‘example.com’, ‘example.org’, ‘example.net’. Each of those is guaranteed
available for use in examples by RFC 2606, and the fact that there are
three separate domains gives you flexibility in choosing examples.

-- 
 \ “To succeed in the world it is not enough to be stupid, you |
  `\must also be well-mannered.” —Voltaire |
_o__)  |
Ben Finney


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

Bug#545791: ITP: ncap -- Network Capture Library and Tools

[Ondřej Surý]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" 


* Package name: ncap
  Version : 1.8.1
  Upstream Author : Internet Systems Consortium
* URL : https://www.dns-oarc.net/tools/ncap
* License : BSD
  Programming Lang: C, Python
  Description : Network Capture Library and Tools

 ncap is a network capture utility like libpcap (on which it is based)
 and tcpdump. It produces binary data in ncap(3) format, either on
 standard output (by default) or in successive dump files. This
 utility is similar to tcpdump(1), but performs IP reassembly and
 generates framing-independent portable output. ncap is expected to be
 used for gathering continuous research or audit traces.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (900, 'jaunty-updates'), (900, 'jaunty-security'), (900, 
'jaunty-backports'), (900, 'jaunty'), (500, 'jaunty-proposed')
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: library-related policy question

[Cyril Brulebois]

Nikita V. Youshchenko  (06/09/2009):
> Is libpkg-guide an official debian document these days?

FSVO “official”:
 - http://packages.debian.org/sid/libpkg-guide
 - http://bugs.debian.org/libpkg-guide

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: The future of the boot system in Debian

[Cyril Brulebois]

Petter Reinholdtsen  (07/09/2009):
> I guess we were a bit unclear.  The point is to use it for upgrades
> (ie when it exist), while not installing /etc/inittab for new
> installs, thus slowly getting rid of the file while ensuring the
> switch do not affect upgrades negatively. :)

I guess you missed:
| [Please CC me in replies, I am currently not subscribed to -devel].

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#545795: ITP: libbind -- standard resolver library

[Ondřej Surý]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" 


* Package name: libbind
  Version : 6.0
  Upstream Author : Internet Systems Consortium
* URL : https://www.isc.org/software/libbind
* License : BSD
  Programming Lang: C++
  Description : the standard resolver library
 
 ISC's libbind provides the standard resolver library, along with
 header files and documentation, for communicating with domain name
 servers, retrieving network host entries from /etc/hosts or via DNS,
 converting CIDR network addresses, performing Hesiod information
 lookups, retrieving network entries from /etc/networks, implementing
 TSIG transaction/request security of DNS messages, performing
 name-to-address and address-to-name translations, and utilizing
 /etc/resolv.conf for resolver configuration.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (900, 'jaunty-updates'), (900, 'jaunty-security'), (900, 
'jaunty-backports'), (900, 'jaunty'), (500, 'jaunty-proposed')
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: State of developers-reference

[Marc 'HE' Brockschmidt]

Heya,

As I'm one of the people who have at some point volunteered to help with
the dev-ref, but mostly failed to actually do work, I guess I could say
a few words, without any pretense of actually knowing better than all
the other people who have already commented...

Lucas Nussbaum  writes:
> OK, let's try to change the way it is maintained by moving to something
> similar to policy. Several questions need to be addressed.
>
> - Where should discussions occur? Should we re-use debian-policy@, since
>   both documents are a bit related? Or use another list? I would
>   personally prefer to use another list (-policy@ is already quite
>   busy), but I could be convinced to use -pol...@.

I think moving discussions to -policy is a good idea, as these
discussion sometimes decide whether a specific change is implemented in
policy or dev-ref.

> Developers Reference gathers several kinds of information:
>
> (A) Purely informational documentation of Debian infrastructure and 
> procedures.
> This is the easiest kind of content. Once correctness has been verified,
> not much debate can happen about the information.

Should such information actually be part of the developers reference?
It seems this could easily be moved onto www. or wiki.debian.org.

> (B) Best practices about Debian packaging
> This is harder to handle, but it isn't normative: maintainers are free
> to do things differently: besides raising a few eyebrows, nothing will
> happen.  If something about developers-reference sounds normative, it's
> a mistake and should be moved to debian-policy.
>
> (C) Policy-like information about some procedures
> This is the hardest part. The developers-reference documents some
> processes that are not standardized by Debian policy, because they are
> not related to Debian packaging. An example of such processes is the NMU
> procedure. Not following those procedures correctly is likely to result in
> complaints from other maintainers.

I've checked the current dev-ref and had quite a few problems to decide
to which of the two categories the current content belongs. Handling
(B) like (C) seems not too problematic. If (A) is moved out of dev-ref,
this would give a simple, coherent change process completly analogous to
policy.

Marc
-- 
BOFH #240:
Too many little pins on CPU confusing it, bend back and forth until
10-20-- are neatly removed. Do _not_ leave metal bits visible!


pgpTyGhmiZnnv.pgp
Description: PGP signature

Bug#545811: ITP: texttrainer -- program to help you memorise text

[Jacob Kanev]

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

Package name: texttrainer
Version: 0.0.2
Upstream Author: Jacob Kanev 
URL: http://sourceforge.net/projects/texttrainer, 
http://home.arcor.de/j_kanev/texttrainer
License: GPL 3
Description: TextTrainer is a program which helps you memorise poems or plain 
texts in your native or in some foreign language. You learn by repeatedly 
reading the text, while after each run more (and different) words are being 
hidden (i.e. replaced by "_"). This will teach you a poem, parts of your text 
for a play, or  basic phrases of a foreign language before you go on holiday. 
Different learning curves may be selected, and for foreign language texts there 
is an automatic grammar correction. Data  files for TextTrainer can contain the 
plain text, as well as translations and pronounciation guides. Data files can 
be created with TextTrainer itself, or with any standard text editor.

-- 
   
   Boomtime, 33rd of Bureaucracy, 3175.
   jacob kanev
 eMail: j_ka...@arcor.de
(any eMail with attached Microsoft-only files
will be regarded as spam)
 tel: +49.30.42087590



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

Re: State of developers-reference

[Stefano Zacchiroli]

On Wed, Sep 09, 2009 at 12:42:22PM +0200, Marc 'HE' Brockschmidt wrote:
> > (A) Purely informational documentation of Debian infrastructure and 
> > procedures.
> > This is the easiest kind of content. Once correctness has been verified,
> > not much debate can happen about the information.
> Should such information actually be part of the developers reference?
> It seems this could easily be moved onto www. or wiki.debian.org.

I think they should (and I say that as a devref _user_ in this context).
One of the aim of a reference document is to be comprehensive (sometime
with original documentation sometime with pointers to the appropriate
doc). I find very valuable that the devref concentrate documentation
about some procedures and tools all DD should know.

It is a single place where to look (instead of googleing) and it is, or
at least I perceive it as such, authoritative.

> > (B) Best practices about Debian packaging
> > This is harder to handle, but it isn't normative: maintainers are free
> > to do things differently: besides raising a few eyebrows, nothing will
> > happen.  If something about developers-reference sounds normative, it's
> > a mistake and should be moved to debian-policy.
> >
> > (C) Policy-like information about some procedures
> > This is the hardest part. The developers-reference documents some
> > processes that are not standardized by Debian policy, because they are
> > not related to Debian packaging. An example of such processes is the NMU
> > procedure. Not following those procedures correctly is likely to result in
> > complaints from other maintainers.
> 
> I've checked the current dev-ref and had quite a few problems to decide
> to which of the two categories the current content belongs. Handling
> (B) like (C) seems not too problematic. If (A) is moved out of dev-ref,
> this would give a simple, coherent change process completly analogous to
> policy.

Even if it were (to which, humbly as user, I'm opposed) I don't think
the process should become completely analogous to policy. Policy is
driven by widespread adoption in thousands of packages, both (B) and (C)
can need to be written down somewhere before they are accepted (exactly
because you want to push the adoption).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: State of developers-reference

[Lucas Nussbaum]

On 09/09/09 at 12:42 +0200, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> As I'm one of the people who have at some point volunteered to help with
> the dev-ref, but mostly failed to actually do work, I guess I could say
> a few words, without any pretense of actually knowing better than all
> the other people who have already commented...
> 
> Lucas Nussbaum  writes:
> > OK, let's try to change the way it is maintained by moving to something
> > similar to policy. Several questions need to be addressed.
> >
> > - Where should discussions occur? Should we re-use debian-policy@, since
> >   both documents are a bit related? Or use another list? I would
> >   personally prefer to use another list (-policy@ is already quite
> >   busy), but I could be convinced to use -pol...@.
> 
> I think moving discussions to -policy is a good idea, as these
> discussion sometimes decide whether a specific change is implemented in
> policy or dev-ref.
> 
> > Developers Reference gathers several kinds of information:
> >
> > (A) Purely informational documentation of Debian infrastructure and 
> > procedures.
> > This is the easiest kind of content. Once correctness has been verified,
> > not much debate can happen about the information.
> 
> Should such information actually be part of the developers reference?
> It seems this could easily be moved onto www. or wiki.debian.org.

Why move this, and not the other parts of dev-ref?  I think that
instead, moving documentation from www.debian.org or wiki.debian.org to
dev-ref would be more interesting to promote best practices. Looking at
wiki.debian.org or some team's websites, it is easy to find different
recommendations for the same thing.

> > (B) Best practices about Debian packaging
> > This is harder to handle, but it isn't normative: maintainers are free
> > to do things differently: besides raising a few eyebrows, nothing will
> > happen.  If something about developers-reference sounds normative, it's
> > a mistake and should be moved to debian-policy.
> >
> > (C) Policy-like information about some procedures
> > This is the hardest part. The developers-reference documents some
> > processes that are not standardized by Debian policy, because they are
> > not related to Debian packaging. An example of such processes is the NMU
> > procedure. Not following those procedures correctly is likely to result in
> > complaints from other maintainers.
> 
> I've checked the current dev-ref and had quite a few problems to decide
> to which of the two categories the current content belongs.

Well, it's easy:
If it's about packaging, then it's a recommended practice, and it's not
normative, because if it were normative, it would be in policy.

But it's true that some procedural stuff could be moved into a seperate
chapter.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: State of developers-reference

[Jon Dowland]

On Mon, Sep 07, 2009 at 06:28:11PM +0200, Lucas Nussbaum
wrote:
> I see some value to a (mostly) self-contained
> documentation, but, if it helps getting contributions from
> more people, we could simply move to wiki.d.o.

If this was a popular choice (which it doesn't appear to
be); it would be blocked on sorting out the wiki.d.o
content licensing.

-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: State of developers-reference

[Holger Levsen]

Hi,

On Mittwoch, 9. September 2009, Jon Dowland wrote:
> If this was a popular choice (which it doesn't appear to
> be); it would be blocked on sorting out the wiki.d.o
> content licensing.

No. http://wiki.debian.org/DebianEdu/Documentation/Lenny has a very fine and 
sosorted licence situation. All GPL-2+ :)


regards,
Holger



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

Bug#545822: ITP: imaprowl -- IMAP new mail notification utility for iPhone using Prowl Public API

[Takuo KITAME]

Package: wnpp
Severity: wishlist
Owner: Takuo KITAME 


* Package name: imaprowl
  Version : 0.9.1
  Upstream Author : Takuo Kitame 
* URL : http://github.com/takuo/IMAProwl
* License : Ruby's License.
  Programming Lang: Ruby
  Description : IMAP new mail notification utility for iPhone using Prowl 
Public API
   Prowl is a service and an App for iPhone's Push Notification service.
   see http://prowl.weks.net/ for more about Prowl.
   .
   IMAProwl is an utility script to notify new mail of IMAP server with Prowl
   service.
   It's very useful to push notification of GMail or any other IMAP mail service
   to your iPhone.
   .
   This program uses IMAP/IDLE(RFC2177) or IMAP/NOOP to check the new mail on
   IMAP server.



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

zabbix: searching for co-maintainers

[Michael Ablassmeier]

hi guys, 

As me and Fabio (kobold) are quite busy with real life Tasks we are searching
for co-maintainers for debian's zabbix[3] packages. As it stands the Packages 
are
not in bad shape but we want to react before things go wild :-)

Personally i started with the maintenance as my old workplace used Zabbix for
Monitoring their Infrastructure, at the moment i even lack a valid Test Setup
for testing the Packages in a good way. Fabio still runs it in his environment. 

The Packages are maintained using the collab-maint repository[1] so it should
be possible for everyone to contribute. Especially if someone from the New
Maintainer Queue wants to come up: youre welcome.

 [1] http://bugs.debian.org/src:zabbix
 [2] 
http://svn.debian.org/wsvn/collab-maint/deb-maint/zabbix/#_deb-maint_zabbix_
 [3]
 zabbix-agent - software for monitoring of your networks -- agent
 zabbix-frontend-php - software for monitoring of your servers -- php frontend
 zabbix-server-mysql - software for monitoring of your networks -- server
 zabbix-server-pgsql - software for monitoring of your networks -- server

bye,
- michael


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

Re: State of developers-reference

[Paul Wise]

On Wed, Sep 9, 2009 at 8:41 PM, Holger Levsen  wrote:
> On Mittwoch, 9. September 2009, Jon Dowland wrote:
>> If this was a popular choice (which it doesn't appear to
>> be); it would be blocked on sorting out the wiki.d.o
>> content licensing.
>
> No. http://wiki.debian.org/DebianEdu/Documentation/Lenny has a very fine and
> sosorted licence situation. All GPL-2+ :)

Recent info about the wiki license situation and plans:

http://lists.debian.org/debian-www/2009/06/msg00083.html

-- 
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: RFC round 5: DEP-3: Patch Tagging Guidelines

[Manoj Srivastava]

On Tue, Sep 08 2009, Ben Finney wrote:

> Paul Wise  writes:

>> What format do the other DVCS systems use for patch export?
>
> Bazaar users generate a “merge directive” for serialising a change set
> http://bazaar-vcs.org/MergeDirective>. The merge directive is
> metadata to be read by the ‘bzr merge’ command; it is commonly
> accompanied in the same message by a plain-text ‘bzr diff’ output.

That does not seem to be a good format for a patch scheme,
 since it is dependent on specialized code to implement it.

>> Also, the git format-patch command can include encoded binary files,
>> which I don't think patch(1) can handle.
>
> Right, all these serialisations are essentially supersets of what
> ‘patch(1)’ can do, since they include things like removing files etc.

True. But our use case would still have a simple patch in the
 body; we are mostly talking about the header fields and the preamble in
 the body.  Post the signature separator, the contents are still a
 simple patch. The resulting format is _compatible_ with git
 format-patch and git am, but not identical.

Seems to me that we have a widely used convention (which might
 not be universal) that will meet our needs, and at least seems
 compatible with a lot of  software under distributed version control. I
 think it well behooves us to re-use this, rather than go off an
 reinvent the wheel ourselves and be incompatible with _everything_ else
 out there.

manoj
-- 
"No wife of *mine* is doing any dishes.  That's what we had the kid
for." from Deathlok comics #1
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: State of developers-reference

[Lucas Nussbaum]

On 09/09/09 at 21:43 +0800, Paul Wise wrote:
> On Wed, Sep 9, 2009 at 8:41 PM, Holger Levsen  wrote:
> > On Mittwoch, 9. September 2009, Jon Dowland wrote:
> >> If this was a popular choice (which it doesn't appear to
> >> be); it would be blocked on sorting out the wiki.d.o
> >> content licensing.
> >
> > No. http://wiki.debian.org/DebianEdu/Documentation/Lenny has a very fine and
> > sosorted licence situation. All GPL-2+ :)
> 
> Recent info about the wiki license situation and plans:
> 
> http://lists.debian.org/debian-www/2009/06/msg00083.html

Choosing CC BY-SA would nicely conflict with our existing documentation,
like the Debian new maintainer guide (GPL2+) or developers-reference
(GPL2+). Wouldn't it be possible to use CC BY-SA with an additional
clause allowing to switch to GPL2+?

The french CeCILL license has such a clause (see 5.3.4 in
http://www.cecill.info/licences/Licence_CeCILL_V2-en.txt).
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: State of developers-reference

[Stefano Zacchiroli]

On Wed, Sep 09, 2009 at 04:04:16PM +0200, Lucas Nussbaum wrote:
> Choosing CC BY-SA would nicely conflict with our existing documentation,
> like the Debian new maintainer guide (GPL2+) or developers-reference
> (GPL2+). Wouldn't it be possible to use CC BY-SA with an additional
> clause allowing to switch to GPL2+?
> 
> The french CeCILL license has such a clause (see 5.3.4 in
> http://www.cecill.info/licences/Licence_CeCILL_V2-en.txt).

Why are we discussing this, given that from early feedback it was more
or less clear that we do not want to go the wiki way for devref?

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: State of developers-reference

[Lucas Nussbaum]

On 09/09/09 at 16:18 +0200, Stefano Zacchiroli wrote:
> On Wed, Sep 09, 2009 at 04:04:16PM +0200, Lucas Nussbaum wrote:
> > Choosing CC BY-SA would nicely conflict with our existing documentation,
> > like the Debian new maintainer guide (GPL2+) or developers-reference
> > (GPL2+). Wouldn't it be possible to use CC BY-SA with an additional
> > clause allowing to switch to GPL2+?
> > 
> > The french CeCILL license has such a clause (see 5.3.4 in
> > http://www.cecill.info/licences/Licence_CeCILL_V2-en.txt).
> 
> Why are we discussing this, given that from early feedback it was more
> or less clear that we do not want to go the wiki way for devref?

That would apply to moving content from the wiki to dev-ref. If the wiki
is CC BY-SA, and dev-ref is GPL2+, we have a problem.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Bug#545795: ITP: libbind -- standard resolver library

[Guillem Jover]

Hi!

On Wed, 2009-09-09 at 10:20:57 +0200, Ondřej Surý wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Ondřej Surý" 

> * Package name: libbind
>   Version : 6.0
>   Upstream Author : Internet Systems Consortium
> * URL : https://www.isc.org/software/libbind
> * License : BSD
>   Programming Lang: C++
>   Description : the standard resolver library
>  
>  ISC's libbind provides the standard resolver library, along with
>  header files and documentation, for communicating with domain name
>  servers, retrieving network host entries from /etc/hosts or via DNS,
>  converting CIDR network addresses, performing Hesiod information
>  lookups, retrieving network entries from /etc/networks, implementing
>  TSIG transaction/request security of DNS messages, performing
>  name-to-address and address-to-name translations, and utilizing
>  /etc/resolv.conf for resolver configuration.

This seems to be already packaged:

  

And there's also the one coming from the bind9 source packages.

regards,
guillem


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

who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?

[Holger Levsen]

Hi,

today I noticed that quite many packages fail the piuparts test, because of a 
file left after purge in /var/lib/update-rd.d - who's responsibility is it to 
clean this up? Each package? Or? Or shouldn't those be cleaned on purge and 
piuparts should ignore those files? (I don't think the latter is the correct 
approach.)

http://paste.debian.net/46146/ shows affected logs in sid.


regards,
Holger


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

Re: Bug#545795: ITP: libbind -- standard resolver library

[Ondřej Surý]

Ah thanks,

missed that.

Ondrej

> This seems to be already packaged:
>
>  
>
> And there's also the one coming from the bind9 source packages.

It's not - libbind9 is something else.

Ondrej
-- 
Ondřej Surý 
http://blog.rfc1925.org/


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

Re: State of developers-reference

[Steve Langasek]

On Tue, Sep 08, 2009 at 11:33:54PM +0200, Lucas Nussbaum wrote:

> OK, let's try to change the way it is maintained by moving to something
> similar to policy. Several questions need to be addressed.

> - Where should discussions occur? Should we re-use debian-policy@, since
>   both documents are a bit related? Or use another list? I would
>   personally prefer to use another list (-policy@ is already quite
>   busy), but I could be convinced to use -pol...@.

I don't think putting it on another list addresses my concern.

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


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Pierre Habouzit]

On Wed, Sep 09, 2009 at 08:50:34AM -0500, Manoj Srivastava wrote:
> Seems to me that we have a widely used convention (which might
>  not be universal) that will meet our needs, and at least seems
>  compatible with a lot of  software under distributed version control. I
>  think it well behooves us to re-use this, rather than go off an
>  reinvent the wheel ourselves and be incompatible with _everything_ else
>  out there.

FWIW, for having discussed it with Raphael on #-qa, he seems pretty much
convinced my proposal to make DEP3 compatible with git-format-patch is
going in the good direction.

He's annoyed I sent that mail so late (and FWIW sorry but I hadn't the
time to do it before, and when I had time in august I hadn't
connectivity.. but whatever) but I think the proposal will be amended so
that we're compatible.
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Mike Hommey]

On Wed, Sep 09, 2009 at 07:48:18PM +0200, Pierre Habouzit wrote:
> On Wed, Sep 09, 2009 at 08:50:34AM -0500, Manoj Srivastava wrote:
> > Seems to me that we have a widely used convention (which might
> >  not be universal) that will meet our needs, and at least seems
> >  compatible with a lot of  software under distributed version control. I
> >  think it well behooves us to re-use this, rather than go off an
> >  reinvent the wheel ourselves and be incompatible with _everything_ else
> >  out there.
> 
> FWIW, for having discussed it with Raphael on #-qa, he seems pretty much
> convinced my proposal to make DEP3 compatible with git-format-patch is
> going in the good direction.
> 
> He's annoyed I sent that mail so late (and FWIW sorry but I hadn't the
> time to do it before, and when I had time in august I hadn't
> connectivity.. but whatever) but I think the proposal will be amended so
> that we're compatible.

Interestingly, using git format-patch format had been suggested back
in june and july, with more opposition...

Mike


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

Re: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?

[Petter Reinholdtsen]

[Holger Levsen]
> today I noticed that quite many packages fail the piuparts test,
> because of a file left after purge in /var/lib/update-rd.d - who's
> responsibility is it to clean this up? Each package? Or? Or
> shouldn't those be cleaned on purge and piuparts should ignore those
> files? (I don't think the latter is the correct approach.)

The directory belong to the sysv-rc package, and will be cleaned up
when that package is removed. :)

We discussed on IRC to remove files from there when update-rc.d is
asked to remove symlinks to a script, and if we decide to implement it
that would solve the piuparts issue.  Thanks for bringing it to our
attention. :)

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs

[Kurt Roeckx]

On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote:
> Steve Langasek wrote:
> 
> > On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
> >> But this will cause trouble anyway. Imagine this case: glib changes
> >> SONAME, both app and library depend on glib. app is recompiled, gtk isn't
> >> yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0.
> >> Kaboom! The only real solution is to make gtk's SONAME dependent on
> >> glib's, eg libgtk- x11-2.0.so.0-glib-1 (a la boost upstream with gcc
> >> versions).
> 
> I think I should have added that the app does not have to link directly with 
> glib.
> 
> > 
> > That's what symbol versioning is for.
> 
> >From /u/i/g/g/gtktextchild.h:
> 
> struct _GtkTextChildAnchor
> {
>   GObject parent_instance;
> 
>   gpointer GSEAL (segment);
> };
> 
> You lost anyway. If GObject or gpointer changes, symbol versioning doesn't 
> save you because _GtkTextChildAnchor is a public type

This can all be solved using symbol versioning.  Buf it will
probably require alot of work to get it right.


Kurt


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

Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs

[Pierre Habouzit]

On Thu, Sep 10, 2009 at 12:35:12AM +0200, Kurt Roeckx wrote:
> On Wed, Aug 26, 2009 at 03:46:36AM -0400, Felipe Sateler wrote:
> > Steve Langasek wrote:
> > 
> > > On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
> > >> But this will cause trouble anyway. Imagine this case: glib changes
> > >> SONAME, both app and library depend on glib. app is recompiled, gtk isn't
> > >> yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0.
> > >> Kaboom! The only real solution is to make gtk's SONAME dependent on
> > >> glib's, eg libgtk- x11-2.0.so.0-glib-1 (a la boost upstream with gcc
> > >> versions).
> > 
> > I think I should have added that the app does not have to link directly 
> > with 
> > glib.
> > 
> > > 
> > > That's what symbol versioning is for.
> > 
> > >From /u/i/g/g/gtktextchild.h:
> > 
> > struct _GtkTextChildAnchor
> > {
> >   GObject parent_instance;
> > 
> >   gpointer GSEAL (segment);
> > };
> > 
> > You lost anyway. If GObject or gpointer changes, symbol versioning doesn't 
> > save you because _GtkTextChildAnchor is a public type
> 
> This can all be solved using symbol versioning.  Buf it will
> probably require alot of work to get it right.

And it will probably require a _lot_ of code to be kept around for lots
of time. At best compatibility layers, and worst case, pure duplication
of all APIs.

symbol versioning is really nice, but it's not magic either ;)
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

RFC: Providing vi when /usr isn't mounted

[James Vega]

tag 528494 help
thanks

#528494 raised the idea of having vim-tiny (the default vi-like editor
on a base install) provide /bin/vi so that it would be accessible in
situations where /usr isn't available.  At first glance, I naïvely
figured this would be an easy change.  Of course, this wasn't the case
so I'd like to get some feedback on the proper approach for this since
this use case is actually something I've intended on doing since
vim-tiny became Priority: important.

We currently have 8 source packages[0] building binary packages which
provide vi in some form.  All except elvis-tiny use the alternatives
system to provide /usr/bin/vi.  Elvis-tiny ships /bin/vi which is a
small binary implementing its own sort of alternatives functionality[1].

The problem here is that I can't simply have vim-tiny ship /bin/vi
partly due to elvis-tiny but primarily due to the alternatives system
rightly not supporting a provided alternative changing location
depending on which of the available alternatives is active.

This would require a separate alternative, which is sub-optimal because
it leaves the possibility for different behavior depending on the order
of the system directories in the user's $PATH, as well as a naming
conflict if /usr/bin is symlinked to /bin.  Having vim-tiny simply ship
/bin/vi and not use the alternatives system runs into similar problems.

Thoughts? Suggestions?

[0] - 
Felipe Augusto van de Wiel (faw) 
   levee

Debian Vim Maintainers 
   vim

Pierre Habouzit 
   vim (U)

Teruyuki Morimura 
   jvim

Jan Christoph Nordholz 
   nvi

Brendan O'Dea 
   vile (U)

Miquel van Smoornburg 
   elvis-tiny

Paul van Tilburg 
   vile

James Vega 
   vim (U)

Colin Watson 
   vigor

Paweł Więcek 
   e3

[1] - See debian/wrapper.c at
  
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Modifying /etc/nsswitch.conf in Debian Packages

[Luke Faraone]

Hi,
I'm currently working on packaging Rainbow,
an implementation of the Bitfrost
 security
spesification. Rainbow runs user-level desktop applications with the same
level of resource isolation already used with a variety of system daemons,
giving each application instance its own UID, GID, and persistent storage
directory.

In order to function, Rainbow requires a NSS module, libnss-rainbow, to be
installed and enabled in /etc/nsswitch.conf.

>From what I can tell (as seen on bug
388864
), libnss-mdns modifies /etc/nsswitch.conf directly as part of its postinst.
I thought this wasn't allowed by Debian policy, but if I'm misunderstanding
I'm more than happy to adopt their solution.

On Ubuntu AuthClientConfig  seems
to serve a similar purpose. Assuming the above workaround was not
acceptable, would porting ACC to Debian and using that hook in my package be
so?

Please CC me, as I'm not subscribed to this list.

-- 
Luke Faraone
http://luke.faraone.cc

Cursos de programacao!

[www . basebinaria . net]

Viva caro/a Amigo/a.

Queremos convida-lo a visitar o nosso SITE
http://www.basebinaria.net. Esta a decorrer 
um curso de programacao de computadores, onde
pode aprender a fazer programas e jogos de 
video. Se e um apaixonado por computadores 
temos tambem muitos projectos para os varios
computadores que fizeram historia, tais como
o ZX Spectrum, Timex 2048, Commodore 64, 
Commodore Amiga 500.
Temos ainda esquemas de electronica e hardware 
diverso, para todos os fins.

Visite-nos

Os Melhores cumprimentos.

J.P.S



-
Send by "EASYMAIL" Info n.3
-



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

Re: Bits from the release team and request for discussion

[Russell Coker]

On Wed, 26 Aug 2009, Manoj Srivastava  wrote:
> if [ -e  /etc/pam.d/login ]; then
>   perl -pli~ -e 'm/session.*pam_selinux.so/ && s/^\#\s*//o'
> /etc/pam.d/login rm /etc/pam.d/login~
> fi
> if [ -e /etc/pam.d/ssh ]; then
>   perl -pli~ -e 'm/session.*pam_selinux.so/ && do { s/^\#\s*//o;
> s/multiple//; } ' /etc/pam.d/ssh rm /etc/pam.d/ssh~
> fi

I would prefer it if this sort of thing was kept to scripts 
like /usr/sbin/selinux-activate from the selinux-basics package.

If you believe that selinux-activate is inadequate in some way then feel free 
to file a bug report (or in the case of Manoj just do an upload to fix it).

In terms of documentation I think that perhaps comments in the 
selinux-activate script would go a long way.  Then the ideal advice would be 
something like "use selinux-activate, but if you want to do it your own 
different way then read the comments and do whatever seems right".

As things change scripts like selinux-activate will change to match.  But we 
will keep them matching the current distribution.

I have no objection to anyone editing config files by hand, but I would prefer 
that when offering advice such things be given a low priority.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: [RANT] [OT] Bloating dependencies instead of using recommends (was: Re: RFS: sqlkit)

[Don Armstrong]

On Thu, 10 Sep 2009, Rogério Brito wrote:
> I am really annoyed with the current trend of packages dragging in a
> lot of dependencies on which the packages don't really "depend". The
> word "dependency" seems to has lost its meaning.

Please file bugs against these packages as appropriate, with
information as to why the package shouldn't be depended on.
 

Don Armstrong

-- 
The solution to a problem changes the problem.
 -- Peer's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


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