Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

On Fri, 3 Apr 2009, Raphael Geissert wrote: One additional thought: We store packaging Vcs and upstream homepage in debian/control. What about storing upstream Vcs there as well and teach uscan to look there as well. Just a rough thought. And do what with it? how will it know what it should

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl] >> I believe the original motivation for tmpfs /var/run in Solaris was >> that it was pointless to maintain scripts that try to clean >> /var/run (or /tmp or any other defined-transient directory) on >> boot, which can be dangerous and tricky if you don't write them >> carefully, wh

Re: Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

On Fri, Apr 03, 2009 at 11:25:22PM +0200, Sune Vuorela wrote: > On Friday 03 April 2009 23:02:28 Ehren Kret wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Ehren Kret > > > > > > * Package name: protobuf > > Version : 2.0.3 > > Upstream Author : Kenton Varda , et al. > >

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: > > Ubuntu. The FHS is silent about directories in /var/run across reboots > > but requires that all files in /var/run be deleted on reboot. > >> 4.) You have to manually cleanup in postrm. (I guess most packages will > >> forget > >

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

On Sat, Apr 4, 2009 at 7:37 AM, Michael Biebl wrote: > Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by > default. The OpenEmbedded distros do this too, I've especially seen that the ones associated with OpenMoko do that. In addition the pkg-fso folk's Debian for OpenMok

Re: Improvements to ‘debian/watch’ for fetching from VCS

Raphael Geissert writes: > Ben Finney wrote: > > > I'd prefer, if the information is to be encoded in the URL, that > > the URL should remain useable as-is with the VCS tool itself. > > > > I know that's possible for ‘svn+http://’, but it's not possible > > for ‘bzr+http://’ if the files are me

Re: Improvements to ‘debian/watch’ for fetching from VCS

Ben Finney wrote: > Raphael Geissert writes: > >> Ben Finney wrote: >> > * the fact that the URL doesn't necessarily indicate what VCS tool is >> > needed to interact with it (just about all of them allow an HTTP URL >> > for public read-only access, so that's what will commonly be used >> >

Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

On Wed, Apr 01, 2009 at 06:54:22PM +0200, "Milan P. Stanic" was heard to say: > On Wed, 2009-04-01 at 09:09, Mike Bird wrote: > > On Wed April 1 2009 00:03:10 Sune Vuorela wrote: > > > Qoreutils is a reimplementation of the classic tools from coreutils, > > > such as ls, mkdir and cp > > Thanks b

Re: Improvements to ‘debian/watch’ for fetching from VCS

Raphael Geissert writes: > Ben Finney wrote: > > * the fact that the URL doesn't necessarily indicate what VCS tool is > > needed to interact with it (just about all of them allow an HTTP URL > > for public read-only access, so that's what will commonly be used > > here) > > That can easil

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Raphael Geissert writes: > As Russ already said, the FHS requires that all files in /var/run be > deleted on reboot; so there's a "myriad" of bogus init scripts. Well, to be fair, it requires that all *files* be deleted, not directories. It doesn't really say anything clear about directories ot

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl wrote: > Russ Allbery schrieb: [...] > >> in tmpfs and have the cleaning happen automatically without doing any >> work. It simplifies the boot process and eliminates a whole class of > > I'm not sure I get that point. Why is the boot process simplified if now > every script has t

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery schrieb: > > I believe the original motivation for tmpfs /var/run in Solaris was that > it was pointless to maintain scripts that try to clean /var/run (or /tmp > or any other defined-transient directory) on boot, which can be dangerous > and tricky if you don't write them carefully,

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > Why is a system service that is started by inetd or D-Bus not a daemon? > Remember the times when exim4 or samba could still be started via inetd > (although those no longer support inetd mode afaik). Why would you store your PID somewhere if you're started from inetd (th

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl writes: >> Russ Allbery wrote: >>> Michael Biebl writes: > Another class of services which might be affected, are daemons/programs started by inetd. > >>> Why would they put anything in /var/run? > >> I guess for the same reasons why other system d

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > Russ Allbery wrote: >> Michael Biebl writes: >>> Another class of services which might be affected, are >>> daemons/programs started by inetd. >> Why would they put anything in /var/run? > I guess for the same reasons why other system daemons put stuff in /var/run They

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl writes: >> Russ Allbery wrote: > >>> It is, however, a standard and supported option and it's the default in >> >> Hm, what standard exactly do you refer too. > > standard, adjective [1622] > >2) (a) regularly and widely used,

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl writes: > >> Another class of services which might be affected, are daemons/programs >> started by inetd. > > Why would they put anything in /var/run? > I guess for the same reasons why other system daemons put stuff in /var/run Michael -- Why is it that

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[No CC please] Daniel Leidert wrote: [...] > > I would like to propose a complete rethinking of the watch files. > We have several packages, which must be prepared from a VCS or > must be repckaged. ATM several people changed to use something like > > $url $pattern debian /bin/sh get-orig-source

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > Another class of services which might be affected, are daemons/programs > started by inetd. Why would they put anything in /var/run? -- Russ Allbery (r...@debian.org) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > Russ Allbery wrote: >> It is, however, a standard and supported option and it's the default in > > Hm, what standard exactly do you refer too. standard, adjective [1622] 2) (a) regularly and widely used, available, or supplied (b) well-e

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl wrote: > Russ Allbery wrote: >> Michael Biebl writes: >>> 5.) If your package does not have an init script (I happen to maintain >>> two such packages), I now have to create init scripts simply to create a >>> /var/run directory. That's insane and even more wasting cpu cycles. >> Co

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl writes: Hi Russ >> 1.) It's not the default on Debian anyway > > It is, however, a standard and supported option and it's the default in Hm, what standard exactly do you refer too. > Ubuntu. The FHS is silent about directories i

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

Ben Finney wrote: [...] > > For my purposes, I would like to be able to specify “fetch from the > VCS at $URL, getting the specific working tree referenced by > identifier $ID” and then the rest of what uscan does for generating > an original source archive from the working tree. > > That's made

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

Andreas Tille wrote: [...] > > One additional thought: We store packaging Vcs and upstream homepage > in debian/control. What about storing upstream Vcs there as well and > teach uscan to look there as well. Just a rough thought. > And do what with it? how will it know what it should look for?

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > 1.) It's not the default on Debian anyway It is, however, a standard and supported option and it's the default in Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. > 4.) You have to manua

Re: Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

On Friday 03 April 2009 23:02:28 Ehren Kret wrote: > Package: wnpp > Severity: wishlist > Owner: Ehren Kret > > > * Package name: protobuf > Version : 2.0.3 > Upstream Author : Kenton Varda , et al. > * URL : http://code.google.com/p/protobuf/ http://packages.qa.debian

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

Cyril Brulebois writes: > Vincent Fourmond (01/04/2009): >> Although I admit that schroot is a neat tool to deal with that, it is >> overkill in the case of wine, and much too complex for users that would >> be interested to use wine: one of the public that can be attracted to >> the GNU/Linux

Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Hi, one of the changes in 3.8.1 was, that support for tmpfs on /var/run (and /var/tmp) became mandatory [9.3.2]. Lintian is now also complaining very loudly (error) if your package ships a directory in /var/run or /var/tmp and suggests to create them in the init script. While I can see the benefi

Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

Package: wnpp Severity: wishlist Owner: Ehren Kret -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: protobuf Version : 2.0.3 Upstream Author : Kenton Varda , et al. * URL : http://code.google.com/p/protobuf/ * License : New BSD License Programm

Re: DEP-4: The TDeb specification.

On Fri, 03 Apr 2009 16:45:46 -0400 Filipus Klutiero wrote: Please note: All of the implementation details can wait until after Squeeze - all that is needed for this release cycle is that apt and dpkg can handle a migration from Squeeze to Squeeze+1 where packages being upgraded may use TDebs for

Re: DEP-4: The TDeb specification.

On Fri, 3 Apr 2009 18:46:48 +0100 Ian Jackson wrote: > Neil Williams writes ("Re: DEP-4: The TDeb specification."): > > On Tue, 31 Mar 2009 13:06:35 -0400 > > Filipus Klutiero wrote: > > > What is the purpose of creating a new binary package format for this (as > > > opposed to reusing, say, th

Re: Re: DEP-4: The TDeb specification.

On Fri, 03 Apr 2009 04:21:59 -0400 Filipus Klutiero wrote: > That would be a nice improvement, but let me suggest another > implementation. To avoid introducing a second diff, why not updating the > regular diff (in the case of non-native packages) but indicating that > the package shouldn't

Re: DEP-4: The TDeb specification.

Neil Williams writes ("Re: DEP-4: The TDeb specification."): > On Tue, 31 Mar 2009 13:06:35 -0400 > Filipus Klutiero wrote: > > What is the purpose of creating a new binary package format for this (as > > opposed to reusing, say, the deb format)? > > To support easier management of the translati

Re: Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

On 3 April 2009 at 07:51, Sylvestre Ledru wrote: | Le vendredi 03 avril 2009 01:24 +0200, Matthias Klose a crit : | > Chris Walker schrieb: | > > Soeren Sonnenburg writes: | > > | > >> Package: wnpp | > >> Severity: wishlist | > >> Owner: Soeren Sonnenburg | > >> | > >> * Package name: j

Re: Again: Bug#503367: plink: file conflict with putty-tools

On Fri, 3 Apr 2009, Steffen Moeller wrote: we should ask the technical committee to rule over it. And maybe this needs some voting in the end. Who is this *we*? Do you volunteer? IMHO plink should be renamed because it is way less popular than the putty tool. So we will loose this voting any

Re: Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

Matthias Klose writes: > Chris Walker schrieb: > > Soeren Sonnenburg writes: > > > >> Package: wnpp > >> Severity: wishlist > >> Owner: Soeren Sonnenburg > >> > >> * Package name: jblas > > > > This package seems likely to be of interest to debian-science, so I'm > > sending this mail the

Re: Again: Bug#503367: plink: file conflict with putty-tools

Hello, Daniel Leidert wrote: > Andreas Tille wrote: >> in October last year there was a longish discussion about name space >> pollution regarding plink. If you like to spend some time you should >> read the complete log of #503367 [1]. >> >> I decided to put an end now on this issue to make sure

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

On 03 Apr 15:42, Nico Golde wrote: > Hi, > * Raphael Geissert [2009-04-02 19:45]: > > [Security team BCC'ed] > > > > Hi, > > > > Do we really need another mozilla browser around? > > Last time I heard the iceweasel maintainers were looking for other people > > to > > help them. > > > > I don'

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

On Fri, Apr 03, 2009 at 03:42:22PM +0200, Nico Golde wrote: > Hi, > * Raphael Geissert [2009-04-02 19:45]: > > [Security team BCC'ed] > > > > Hi, > > > > Do we really need another mozilla browser around? > > Last time I heard the iceweasel maintainers were looking for other people > > to > >

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

Hi, * Raphael Geissert [2009-04-02 19:45]: > [Security team BCC'ed] > > Hi, > > Do we really need another mozilla browser around? > Last time I heard the iceweasel maintainers were looking for other people to > help them. > > I don't think yet another clone of firefox is going to do any good i

Re: Improvements to ‘debian/watch’ for fet ching from VCS

Ben Finney wrote: Noah Slater writes: On Fri, Apr 03, 2009 at 10:04:21AM +1100, Ben Finney wrote: * the plethora of different concepts for mapping identifiers to specific working trees in different VCSen (revision-id and branches and tags, oh my!) This could be possible with a set of con

Bug#522396: RFP: rekonq -- KDE 4's lightweight QtWebkit based web browser

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: rekonq Version: 0.0.4 Upstream Author: Andrea Diamantini URL: http://rekonq.sourceforge.net/ License: GPL2+ Description: KDE 4's lightweight QtWebkit based web browser re

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

On Fri, 3 Apr 2009, Daniel Leidert wrote: I would like to propose a complete rethinking of the watch files. We have several packages, which must be prepared from a VCS or must be repckaged. ATM several people changed to use something like $url $pattern debian /bin/sh get-orig-source-script One

Re: DEP-4: The TDeb specification.

On Fri, 03 Apr 2009 04:21:59 -0400 Filipus Klutiero wrote: > That would be a nice improvement, but let me suggest another > implementation. To avoid introducing a second diff, why not updating the > regular diff (in the case of non-native packages) but indicating that > the package shouldn't b

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

Ben Finney wrote: > Raphael Geissert writes: > > > I planned to add support for svn in version 4 watch files (it would > > be a matter of svn info svn://domain.tld/path/to/repo and some data > > massaging). > > > > But well, now that everyone is talking about it why not just tell > > what is miss

Re: Request for Comments: Standardize enabling/disabling of system services

On Fri, Apr 03, 2009 at 10:18:20AM +0200, Patrick Schoenfeld wrote: > On Thu, Apr 02, 2009 at 12:41:20PM -0700, Steve Langasek wrote: > > > Indeed. Didn't think about the possibility of diversions. I guess > > > diverting the init scripts could be a solution (besides that it needs > > > some furthe

Re: Re: DEP-4: The TDeb specification.

Neil Williams wrote: On Tue, 31 Mar 2009 13:06:35 -0400 Filipus Klutiero wrote: > Neil Williams wrote: > > Primary Motivations (in order): > >1. Updates to translations should not require source NMU's. > > > I guess

Re: Request for Comments: Standardize enabling/disabling of system services

On Thu, Apr 02, 2009 at 12:41:20PM -0700, Steve Langasek wrote: > > Indeed. Didn't think about the possibility of diversions. I guess > > diverting the init scripts could be a solution (besides that it needs > > some further work to the service managing utility). Then I'd > > whole-heartedly agree

Re: Request for Comments: Standardize enabling/disabling of system services

On Thu, Apr 02, 2009 at 12:07:25PM -0700, Steve Langasek wrote: > On Thu, Apr 02, 2009 at 01:12:25PM +0200, Patrick Schoenfeld wrote: > > On Wed, Apr 01, 2009 at 06:05:48PM -0700, Steve Langasek wrote: > > > > I think that renaming and/or removing the init script symlinks is the > > > > Right Thing