Re: Debian packages and upstart jobs

[Kel Modderman]

On Saturday 12 December 2009 07:07:21 Russ Allbery wrote:
> Hello everyone,
> 
> One of the packages I maintain, OpenAFS, is a network file system.  As
> such, one generally wants it to start before things like gdm that need to
> read the user's home directory.  However, in Ubuntu, gdm is started by
> upstart instead of an init script, and all init scripts are run after the
> native upstart jobs are run.
> 
> The best way to address this for Ubuntu would be to introduce an upstart
> job for OpenAFS.  However, the package is in universe and hence
> preferrably shared between Ubuntu and Debian.
> 
> Is there any reason why it would cause problems for me to add an upstart
> job to the Debian package, even though Debian doesn't currently use
> upstart?  (I realize that the logic around deactivating the init script if
> upstart is present may be a bit complex, but I suspect we can find ways of
> dealing with that.)  I assume the job just sit there quiescent until
> Debian switches to upstart.

debehlper >= 7.4.1 contains an implementation of dh_installinit which takes
care of debian/$package.upstart (and debian/$package.$name.upstart when called
with --name= parameter) by installing the job(s) to /etc/init.d/ with a
symlink from /etc/init.d/$jobfile -> /lib/init/upstart-job. It also adds
'upstart-job' to the substvars in misc:Depends.

The status of 'upstart-job' is unknown to me, which raises my concern that
Debian boot system may not be ready for upstart jobs when they are installed
by dh_installinit.

Thanks, Kel.


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

Re: doc-base section for server software

[Stefan Fritsch]

On Monday 07 December 2009, Stefano Zacchiroli wrote:
> IME, bugging the doc-base maintainer with well-motivated requests
>  for specific sections works quite well, have you tried that?
> 
I was not sure about the procedure. I have filed a bug on doc-base 
now.

Cheers,
Stefan


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

Re: dh_config_model_upgrade: package upgrade with Config::Model

[Dominique Dumont]

Le vendredi 4 décembre 2009 19:46:04, Stefano Zacchiroli a écrit :
> On Fri, Dec 04, 2009 at 06:54:56PM +0100, Dominique Dumont wrote:
> > The idea was to offer the user a possibility to bail out since
> > config-model is still experimental. But I'm beginning to wonder if
> > this is a good idea...
> 
> IMO it is not, in the sense that it is quite pointless to put this
> choice on the final users. The choice about whether to use it or not
> should be of the final *package maintainer*. If its use of config-model
> works, fine, otherwise _his_ package will be considered RC buggy as any
> other package erroneously fiddling with user conffile.

Ok, I'll remove this question.

> Please detail more the "write the model" case. I want that possibility,
> but it is not clear to me whether the custom model can be shipped within
> the package needing it at configuration time.  (Yes, that of course
> means that no-fiddling would be possible in preinst, but I got the
> impression that it was already the case.)

There are several possibilities:
- either the model can be used also to configure the application. In this 
case, the model should contain help text (description, summary...)
- or the model is used only in batch mode for upgrade. Since there's no user 
interaction, the help text can be skipped.

In the first case, it's better to ship the model in a separate package and 
upload it to CPAN. Debian-perl team will then package it.

In the second case, the model can be shipped only in the debian package.

> No, that's was not my question, sorry if it was not clear; let me try
> again. config-model will have a model for the previous maintainer
> version of some conffile, let's call it m_1; then config-model can have
> several other models m_2, ... m_n and it can jump up to m_n.
> 
> What I want to know is whether config-model allows me not to write a
> model m_i I'd like to arrive to in the package, but rather write a small
> program snippet which takes m_1 and modify it in some way. That's
> basically the different between "here is the model you should arrive to"
> (which I understand is supported) and "here is a recipe/program to
> obtain the model you should arrive to". 

I can easily add some code so that you can use config-model-edit (provided by 
Config::Model::Itself) in such a way.

For instance if you want to change the default value of PermitRootLogin, you 
would need to run this line while packaging libconfig-model-openssh-perl:

 config-model-edit -model Sshd -save class:Sshd element:PermitRootLogin \
 default=no 

Does this reply to your question ?

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


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

Re: Bug#558684: ITP: envstore -- save and restore environment variables

[Frank Lin PIAT]

Hi all,

Do April Fools' Day occur in November in some part of the world?

On Sun, 2009-11-29 at 21:01 +0100, Maximilian Gass wrote:
> Package: wnpp
> 
> * Package name: envstore
>   Version : 2.0
>   Upstream Author : Daniel Friesel 
> * URL : https://derf.homelinux.org/~derf/projects/envstore/
> * License : WTFPL

WTF?

Please Sam, drop your F* webpage. The [Open-Source] world don't need yet
another license. Or make it clear that no one should actually use it.

>   Description : save and restore environment variables
> 
> envstore allows you to save environment variables into a seperate store, list
> them, and reload them into the shell again.

In most situation, this packaged can be replaced with:

echo $FOO > ~/.var_FOO
then
FOO=$(cat ~/.var_FOO)

In some exceptional situation, where the variable variables and escape
code should be preserved, one can use:
export | grep " PS4=" > ~/.var_FOO
then
. ~/.var_FOO

(No, it isn't guaranteed to be portable, and there might even be easier
ways to achieve all this).

I wonder how Unix could survive 30 years without such command.

Franklin


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

Re: Bug#558684: ITP: envstore -- save and restore environment variables

[Jonathan Yu]

On Sat, Dec 12, 2009 at 1:54 PM, Frank Lin PIAT  wrote:
> Hi all,
>
> Do April Fools' Day occur in November in some part of the world?
>
> On Sun, 2009-11-29 at 21:01 +0100, Maximilian Gass wrote:
>> Package: wnpp
>>
>> * Package name    : envstore
>>   Version         : 2.0
>>   Upstream Author : Daniel Friesel 
>> * URL             : https://derf.homelinux.org/~derf/projects/envstore/
>> * License         : WTFPL
>
> WTF?
>
> Please Sam, drop your F* webpage. The [Open-Source] world don't need yet
> another license. Or make it clear that no one should actually use it.
FWIW, the WTFPL is accepted as compatible with the GPL by the Free
Software Foundation:

http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

That is, at least version 2 of that license...
>
>>   Description     : save and restore environment variables
>>
>> envstore allows you to save environment variables into a seperate store, list
>> them, and reload them into the shell again.
>
> In most situation, this packaged can be replaced with:
>
> echo $FOO > ~/.var_FOO
> then
> FOO=$(cat ~/.var_FOO)
>
> In some exceptional situation, where the variable variables and escape
> code should be preserved, one can use:
> export | grep " PS4=" > ~/.var_FOO
> then
> . ~/.var_FOO
>
> (No, it isn't guaranteed to be portable, and there might even be easier
> ways to achieve all this).
>
> I wonder how Unix could survive 30 years without such command.
>
> Franklin
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: Debian packages and upstart jobs

[Steve Langasek]

On Sat, Dec 12, 2009 at 07:49:58PM +1000, Kel Modderman wrote:
> > One of the packages I maintain, OpenAFS, is a network file system.  As
> > such, one generally wants it to start before things like gdm that need to
> > read the user's home directory.  However, in Ubuntu, gdm is started by
> > upstart instead of an init script, and all init scripts are run after the
> > native upstart jobs are run.

> > The best way to address this for Ubuntu would be to introduce an upstart
> > job for OpenAFS.  However, the package is in universe and hence
> > preferrably shared between Ubuntu and Debian.

> > Is there any reason why it would cause problems for me to add an upstart
> > job to the Debian package, even though Debian doesn't currently use
> > upstart?  (I realize that the logic around deactivating the init script if
> > upstart is present may be a bit complex, but I suspect we can find ways of
> > dealing with that.)  I assume the job just sit there quiescent until
> > Debian switches to upstart.

> debehlper >= 7.4.1 contains an implementation of dh_installinit which takes
> care of debian/$package.upstart (and debian/$package.$name.upstart when called
> with --name= parameter) by installing the job(s) to /etc/init.d/ with a
> symlink from /etc/init.d/$jobfile -> /lib/init/upstart-job. It also adds
> 'upstart-job' to the substvars in misc:Depends.

> The status of 'upstart-job' is unknown to me, which raises my concern that
> Debian boot system may not be ready for upstart jobs when they are installed
> by dh_installinit.

Currently, the only provider of the "upstart-job" virtual package in the
archive is upstart itself.  So if you use dh_installinit to install an
upstart job, your package will force the installation of upstart onto the
system, which is not what we want.

The plan of record is to get an upstart-job implementation in place that
works with sysvinit, so that maintainers can ship *only* an upstart job, no
init script, and have the compatibility layer handle everything on systems
not running upstart (including architectures to which upstart can't be
easily ported).  That compatibility layer, once available, will conflict
with any efforts to ship both an upstart job and an init script in the
package.

So if you really want to upstartify the package for Ubuntu (which isn't
necessary - the current focus in Ubuntu is upstartifying those services that
are on a default system, there's not as much benefit to converting other
services yet), my personal recommendation for now would be to build the
package differently for Debian than for Ubuntu.

-- 
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: Debian packages and upstart jobs

[Russ Allbery]

Kel Modderman  writes:

> debehlper >= 7.4.1 contains an implementation of dh_installinit which
> takes care of debian/$package.upstart (and debian/$package.$name.upstart
> when called with --name= parameter) by installing the job(s) to
> /etc/init.d/ with a symlink from /etc/init.d/$jobfile ->
> /lib/init/upstart-job. It also adds 'upstart-job' to the substvars in
> misc:Depends.

> The status of 'upstart-job' is unknown to me, which raises my concern
> that Debian boot system may not be ready for upstart jobs when they are
> installed by dh_installinit.

Oh, huh, that's intriguing.  I'm not completely sure that I want to pull
upstart-job in for all users of OpenAFS, but that's a really elegant
solution to the problem.  Maybe I should.

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


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

Bug#560863: ITP: lamson -- The Python SMTP Server

[Sebastian Otaegui]

Package: wnpp
Severity: wishlist
Owner: Sebastian Otaegui 


* Package name: lamson
  Version : 1.0pre7
  Upstream Author : Zed A. Shaw
* URL : http://lamsonproject.org
* License : GPL
  Programming Lang: Python
  Description : The Python SMTP Server

Lamson's goal is to put an end to the hell that is "e-mail application
development". Rather than stay stuck in the 1970s, Lamson adopts modern
web application framework design and uses a proven scripting language
(Python).

Features:
* Avoid aliases forever! Lamson uses friendly regular expressions
  and FSM-based routing.
* Use an RDBMS and ORM instead of a bizarre combination of
  flat-files and hashtables!
* Get up and running quickly. Lamson can be installed and running in
  30 seconds.



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

Re: Debian packages and upstart jobs

[Russ Allbery]

Steve Langasek  writes:

> So if you really want to upstartify the package for Ubuntu (which isn't
> necessary - the current focus in Ubuntu is upstartifying those services
> that are on a default system, there's not as much benefit to converting
> other services yet), my personal recommendation for now would be to
> build the package differently for Debian than for Ubuntu.

The problem is that there are real bugs caused by OpenAFS not using
upstart in Ubuntu because gdm starts before the user's home directory is
available.

However, I'm not willing to maintain separate packages for Ubuntu and
Debian.  So I suppose the bug will persist for the time being, or someone
else will have to maintain separate Ubuntu packages.  :/

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


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

Bug#560877: ITP: python-jsonpickle -- jsonpickle is a Python library for serialization and deserialization of complex Python objects to and from JSON.

[John Paulett]

Package: wnpp
Severity: wishlist
Owner: John Paulett 


* Package name: python-jsonpickle
  Version : 0.3.1
  Upstream Author : John Paulett 
* URL : http://jsonpickle.github.com
* License : BSD
  Programming Lang: Python
  Description : jsonpickle is a Python library for serialization and 
deserialization of complex Python objects to and from JSON.

The standard Python libraries for encoding Python into JSON, such as the 
stdlib’s json, simplejson, and demjson, can only handle Python primitives that 
have a direct JSON equivalent (e.g. dicts, lists, strings, ints, etc.). 
jsonpickle builds on top of these libraries and allows more complex data 
structures to be serialized to JSON. jsonpickle is highly configurable and 
extendable–allowing the user to choose the JSON backend and add additional 
backends.



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

Re: Sponsorship requirements and copyright files

[Charles Plessy]

[If I remember correctly, the question below is whether the law in the U.S.A.
requires us to reproduce all copyright statements from the source files when we
redistribute binary programs, or if this is only needed when the license
expliciterly asks so.]

Le Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery a écrit :
> Joerg Jaspert  writes:
> 
> > Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let
> > SPI get us some lawyers input on the question. Thats probably the best
> > course.
> 
> Yes.  I'm wholeheartedly in favor of this, and I think we should hold any
> resolution of this discussion for the results of that.  There are a
> surprising number of gotchas hidden in licenses that people think are
> straightforward and read past, and it would be nice to know what our basic
> legal requirements are.

Dear Steve, FTP team, and everybody.

The discussion was held for half a year now. Can we have an update on what is
happening on the lawyer side?

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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