Re: Two line init.d scripts? Sure, that will work!

[Holger Levsen]

Hi Petter,

On Mittwoch, 5. Februar 2014, Petter Reinholdtsen wrote:
[...]
> As for the line counting in the subject, I decided to ignore commented
> lines.  Including those, we end up on 11 lines. :)

I think this illustrates nicely the problem with this approach:

- there are two lines, which contain code.
- there are five commented lines, which are interpreted and contain important 
data.
- and there are four lines of commented code, which are mostly comments, 
except two.

I don't think it's worse pushing this confusing "solution" out to hundreds of 
packages, especially since superior solutions exists. The days of elf objects 
are long gone too and while nostalgia has a place, I don't think it should be 
sid.


cheers,
Holger




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

Re: amd64 arch and optimization flags?

[Jaromír Mikeš]

2014-02-06 Julian Taylor :

> On 06.02.2014 00:39, Jaromír Mikeš wrote:
>
> > I would like to add some optimization flags for amd64 arch in some
> > packages (mostly LV2 nad LADSPA plugins).
> > I found these as candidates for amd64 arch:
> >
> > -msse
> > -msse2
> > -mfpmath=sse
>
> this is enabled by default on amd64
>

Can you elaborate a bit here?
When I builded in clean chroot (amd64) I never noticed that these flags
would be added.



>
> > -ffast-math
>
> this is dangerous it changes results, sometimes significantly (e.g. for
> complex numbers), only use if you don't care about correctness or have
> verified its still correct.
>
> > -ftree-vectorize
>
> this does sometimes slow programs down, usually only programs doing
> numeric work profit from it, these usually enable it by themselves.
> It is enabled by the -O3 optimization level.
> it is mostly safe to use if you follow the C standard strictly (i.e. no
> unaligned access of aliased variables)
>
> > -mtune=generic
>
> should be the default, but you can safely change that to something else.
> generic in gcc < 4.9 is I think pentium4 which is a very old chip.
>
> gcc-4.9 will change the default of it to bulldozer/intel-core btw:
> http://gcc.gnu.org/gcc-4.9/changes.html
>

Thank you for commenting these flag. They looks like they shouldn't be
generally applied in all cases.

best regards

mira

Re: amd64 arch and optimization flags?

[Sylvestre Ledru]

On 06/02/2014 10:22, Jaromír Mikeš wrote:
>
>
>
> 2014-02-06 Julian Taylor  >:
>
> On 06.02.2014 00:39, Jaromír Mikeš wrote:
>
> > I would like to add some optimization flags for amd64 arch in some
> > packages (mostly LV2 nad LADSPA plugins).
> > I found these as candidates for amd64 arch:
> >
> > -msse
> > -msse2
> > -mfpmath=sse
>
> this is enabled by default on amd64
>
>
> Can you elaborate a bit here?
> When I builded in clean chroot (amd64) I never noticed that these
> flags would be added.
It is done by default by the compiler internally.

Sylvestre

Re: amd64 arch and optimization flags?

[Jaromír Mikeš]

2014-02-06 Sylvestre Ledru :

>  On 06/02/2014 10:22, Jaromír Mikeš wrote:
>
> 2014-02-06 Julian Taylor :
>
>> On 06.02.2014 00:39, Jaromír Mikeš wrote:
>>
>> > I would like to add some optimization flags for amd64 arch in some
>> > packages (mostly LV2 nad LADSPA plugins).
>> > I found these as candidates for amd64 arch:
>> >
>> > -msse
>> > -msse2
>> > -mfpmath=sse
>>
>>  this is enabled by default on amd64
>>
>
>  Can you elaborate a bit here?
> When I builded in clean chroot (amd64) I never noticed that these flags
> would be added.
>
> It is done by default by the compiler internally.
>

Aha ... so these default flags are added by compiler and they are not
controlled by debian tools at all?
Can I see somewhere default flags for different archs?

regards

mira

Re: amd64 arch and optimization flags?

[Tollef Fog Heen]

]] Jaromír Mikeš 

> Aha ... so these default flags are added by compiler and they are not
> controlled by debian tools at all?
> Can I see somewhere default flags for different archs?

run gcc -dumpspecs on the different platforms and you can see them.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738jwsh0k@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Helmut Grohne]

Hi Pere,

On Wed, Feb 05, 2014 at 10:31:09PM +0100, Petter Reinholdtsen wrote:
> The idea is to let init.d scripts look like this:
> 
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond

This idea has been brought up a fair number of times now. While others
have already pointed out, that this is basically the approach taken by
OpenRC, we have a very similar implementation in the archive for far
longer. It's called upstart!

The relevant bits can be found in insserv, watch out for
"/lib/init/upstart-job". It takes things one step further though.
Instead of having an interpreted script, it right out replaces the init
script with a symbolic link to the mentioned helper. That in turn can
derive the job name from argv[0] and use the existing upstart job
description.

My attempt to reproduce such a utility for systemd have not worked out
unfortunately (for lack of time/interest).

So yeah, the approach taken is one that is known to be good. The main
downside I see with your particular implementation is that your answer
to the problem of too many standards is adding yet another one.

Why not write an upstart job instead? It works with sysvinit today!

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206095622.ga22...@alf.mars

Re: Two line init.d scripts? Sure, that will work!

[Sergey B Kirpichev]

> I think this illustrates nicely the problem with this approach:
> - there are two lines, which contain code.
> - there are five commented lines, which are interpreted and contain important 
> data.
> - and there are four lines of commented code, which are mostly comments, 
> except two.

And yet another one:
- there are many people in the Debian, who are not aware about LSB at all...
(I'm not surprised, that among tech-ctte members too...)

> I don't think it's worse pushing this confusing "solution" out to hundreds of
> packages, especially since superior solutions exists.

For example?  (And please keep away systemd/upstart/etc propaganda from
this thread, it's all about sysvinit only.)

Peter, thank you for your work.  Have you tried any complex init
script to fit this business (apache2 or postfix, for example)?

BTW, I don't think your postfix script is an actual replacement for the
current init-script.  For example, there are create_xconsole() and 
sendsigs_omit()
functions.  Also, there is the do_rotate function - a very common example
when you want to implement a custom action (not just one from fixed set
start/stop/reload/etc).

Also, you should keep in mind this scenario as well:
https://lists.debian.org/debian-ctte/2013/12/msg00156.html

Last but not least, we can utilize custom lsb-headers (X-Debian-* like) to
keep information like pidfile or daemon binary path name.  I think,
there is a parser for this LSB-info somewhere in the lsb-* packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206103221.ga1...@darkstar.order.hcn-strela.ru

Re: Two line init.d scripts? Sure, that will work!

[Ansgar Burchardt]

On 02/06/2014 10:56, Helmut Grohne wrote:
> The relevant bits can be found in insserv, watch out for
> "/lib/init/upstart-job".

The current version of insserv in unstable, 1.14.0-5, doesn't seem to
contain this file.

> It takes things one step further though.
> Instead of having an interpreted script, it right out replaces the init
> script with a symbolic link to the mentioned helper. That in turn can
> derive the job name from argv[0] and use the existing upstart job
> description.
> 
> My attempt to reproduce such a utility for systemd have not worked out
> unfortunately (for lack of time/interest).

Using systemd jobs instead of the init script if available is already
implemented:

~ # /etc/init.d/cron restart
[ ok ] Restarting cron (via systemctl): cron.service.

> Why not write an upstart job instead? It works with sysvinit today!

How would the init script continue to work on sysvinit if it was
replaced with a symlink as you said earlier?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f36565.4080...@debian.org

Re: Two line init.d scripts? Sure, that will work!

[Jonas Smedegaard]

Quoting Petter Reinholdtsen (2014-02-05 22:31:09)
> The idea is to let init.d scripts look like this:
> 
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond
> 
> Short and to the point, and in the simple case only list the path to 
> the daemon to start.  The code to implement init.d scripts is moved to 
> /lib/init/init-d-script, and the redundant code spread across 
> /etc/init.d/ can be dropped.

Marvellous idea!


> A few days ago I picked up the idea again, and wrote a more complete
> draft of the /lib/init/init-d-script.  The code is available in the
> simpler-init-scripts in the sysvinit GIT repository, available from
>  http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts
>  >.
> I've tested it on a few packages, and believe the code is ready for
> wider testing.
> 
> The main target group for this feature are the majority of packages 
> with init.d scripts, the ones starting a single daemon.  There are 
> around 1000 packages in Debian with init.d scripts.  Around 100 of 
> them start stuff using rcS.d/, and tend to be quite complex.  Most of 
> the rest start a simple daemon and are based on different generations 
> of /etc/init.d/skeleton.  The target for this feature is the latter 
> group.

I am involved in a few of those simple uses, and have long wanted to 
simplify netatalk as well (by splitting the daemons as separate sysV 
scripts).

As soon as available in Debian (but not before, I cannot find time to 
juggle unusual environments) I will migrate to this simple form.

...unless peers in the various teams I am involved in object, obviously.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Two line init.d scripts? Sure, that will work!

[Gergely Nagy]

Petter Reinholdtsen  writes:

> The reason I bring this up on debian-devel@ is twofold.  First, I want
> to gather feedback on the idea.  Will it work for your package, or are
> some more hooks needed?

With my syslog-ng upstream hat on: please, for the love of $deity, no!
It's bad enough having to care about three init systems on Linux, then
some more on the BSDs, and not break legacy unixes either.

With my syslog-ng debian maintainer hat on, I honestly do not want to
deal with even more (and since I provide backports, I can't just abandon
the old init script for the foreseeable future, either).

Also, pushing complexity into a common script would only mean that if,
for some reason, it needs a fix that only syslog-ng triggers, I'm
screwed, and need to fall back to a full-blown script anyway. Having had
a look at the current sysvinit file of syslog-ng, I'd fall back there
anyway (mostly for the silly dance done in syslogng_wait()).

The idea is nice in theory, but unless you go the full mile, and do a
truly declarative syntax like systemd, from my point of view, it will be
worthless.

As a comparsion, here's the systemd unit file (15 lines including blanks):

,
| [Unit]
| Description=System Logger Daemon
| Documentation=man:syslog-ng(8)
| 
| [Service]
| Type=notify
| Sockets=syslog.socket
| ExecStart=/usr/sbin/syslog-ng -F
| ExecReload=/bin/kill -HUP $MAINPID
| StandardOutput=null
| Restart=on-failure
| 
| [Install]
| WantedBy=multi-user.target
| Alias=syslog.service
`

Or the upstart service thingy (which I actually have never tried), which
is 9 lines including blanks:

,
| description   "system logging daemon"
| 
| start on filesystem
| stop on runlevel [06]
| 
| expect fork
| respawn
| 
| exec syslog-ng --process-mode=background
`

I assume an OpenRC init file would be similarly short.

What would your solution buy me, that neither systemd, nor upstart do?
Both which of those provide me features not present in sysvinit, which
are tremendously useful for my use cases.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vbwsedus.fsf@algernon.balabit

Re: Two line init.d scripts? Sure, that will work!

[Petter Reinholdtsen]

[Helmut Grohne]
> This idea has been brought up a fair number of times now. While others
> have already pointed out, that this is basically the approach taken by
> OpenRC, we have a very similar implementation in the archive for far
> longer. It's called upstart!
> 
> The relevant bits can be found in insserv, watch out for
> "/lib/init/upstart-job". It takes things one step further though.
> Instead of having an interpreted script, it right out replaces the
> init script with a symbolic link to the mentioned helper. That in
> turn can derive the job name from argv[0] and use the existing
> upstart job description.

Ah, had completely forgotten about that script./lib/init/upstart-job.
Thank you for bringing it to my attention.  Found the
/lib/init/upstart-job script in the upstart package and the code to
allow insserv to run '/etc/init.d/script lsb-header' to generate the
LSB header from the upstart job.

It make sure /etc/init.d/ scripts are available for machines using
upstart, but do not make sure the script work on machines without
upstart.  I guess that could be solved by moving the
/lib/init/upstart-job file out of the upstart package and into a more
suitable package, but a more extensive rewrite is also needed (it
expect start, stop, status and reload to be commands able to take
actions on services).  Do I misunderstand how upstart-job work?  If I
install a package with an upstart job and a symlink to
/lib/init/upstart-job from /etc/init.d/ on Hurd, will it work?
Testing...  Nope, did not work:

  root@hurdtest:~# cat /etc/init/ssh.conf 
  # ssh - OpenBSD Secure Shell server
  #
  # The OpenSSH server provides secure shell access to the system.

  description "OpenSSH server"

  start on runlevel [2345]
  stop on runlevel [!2345]

  respawn
  respawn limit 10 5
  umask 022

  env SSH_SIGSTOP=1
  expect stop

  # 'sshd -D' leaks stderr and confuses things in conjunction with 'console log'
  console none

  pre-start script
  test -x /usr/sbin/sshd || { stop; exit 0; }
  test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
  test -c /dev/null || { stop; exit 0; }
  
  mkdir -p -m0755 /var/run/sshd
  end script

  # if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
  # 'exec' line here instead
  exec /usr/sbin/sshd -D
  root@hurdtest:~# ls -l /etc/init.d/ssh
  lrwxr-xr-x 1 root root 21 Feb  6 09:49 /etc/init.d/ssh -> 
/lib/init/upstart-job
  root@hurdtest:~# /etc/init.d/ssh status
  Rather than invoking init scripts through /etc/init.d, use the service(8)
  utility, e.g. service ssh status
  /etc/init.d/ssh: 58: /etc/init.d/ssh: initctl: not found

  Since the script you are attempting to invoke has been converted to an
  Upstart job, you may also use the status(8) utility, e.g. status ssh
  /etc/init.d/ssh: 70: /etc/init.d/ssh: status: not found
  root@hurdtest:~# /etc/init.d/ssh lsb-header
  Rather than invoking init scripts through /etc/init.d, use the service(8)
  utility, e.g. service ssh lsb-header
  /etc/init.d/ssh: 58: /etc/init.d/ssh: initctl: not found

  The script you are attempting to invoke has been converted to an Upstart
  job, but lsb-header is not supported for Upstart jobs.
  root@hurdtest:~# 


My idea was to make sure systems based on linux, kfreebsd and hurd
could keep using the init.d scripts even if upstart, systemd or openrc
is used by default on Linux, by reducing the maintenance burden for
package maintainers to keep such scripts working.  Both upstart,
systemd, openrc, file-rc and sysv-rc are able to start daemons in
packages providing init.d scripts, and the LSB require such scripts to
keep working, so we would most likely have that support around until
we decide to drop LSB support in Debian.

> So yeah, the approach taken is one that is known to be good. The
> main downside I see with your particular implementation is that your
> answer to the problem of too many standards is adding yet another
> one.

Well, I do not add a standard.  I keep the existing LSB standardized
init.d script standard and make them easier to maintain by reducing
the amount of information/code each package maintainer need to provide.

> Why not write an upstart job instead? It works with sysvinit today!

Because it only work with upstart at the moment. :)

-- 
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
Archive: http://lists.debian.org/20140206104724.gh1...@ulrik.uio.no

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand]

On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote:
> Hi.
> 
> A few months ago I drafted an idea to rewrite init.d scripts to use a
> common implementation and only specify the unique parts in the init.d
> scripts themselves.  That draft can be found on
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>  >.
> 
> The idea is to let init.d scripts look like this:
> 
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond
> 
> Short and to the point, and in the simple case only list the path to
> the daemon to start.  The code to implement init.d scripts is moved to
> /lib/init/init-d-script, and the redundant code spread across
> /etc/init.d/ can be dropped.
> 
> A few days ago I picked up the idea again, and wrote a more complete
> draft of the /lib/init/init-d-script.  The code is available in the
> simpler-init-scripts in the sysvinit GIT repository, available from
>  http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts
>  >.
> I've tested it on a few packages, and believe the code is ready for
> wider testing.
> 
> The main target group for this feature are the majority of packages
> with init.d scripts, the ones starting a single daemon.  There are
> around 1000 packages in Debian with init.d scripts.  Around 100 of
> them start stuff using rcS.d/, and tend to be quite complex.  Most of
> the rest start a simple daemon and are based on different generations
> of /etc/init.d/skeleton.  The target for this feature is the latter
> group.
> 
> The reason I bring this up on debian-devel@ is twofold.  First, I want
> to gather feedback on the idea.  Will it work for your package, or are
> some more hooks needed?  Second, I wonder where such script best would
> belong.  My initial idea is to put it in the initscripts package,
> installed on almost all Debian systems, but I suspect sysvinit-utils
> is a good place too.  I plan to use the system in the initscripts
> package, and am relucant to add new dependencies to it, as this would
> make the new dependency a required package.
> 
> Comments?

Well, you've been trying to reimplement OpenRC... with less features!
Don't bother, switch to OpenRC, and call it a day... :)

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f3688d.5010...@debian.org

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand]

On 02/06/2014 07:36 AM, Petter Reinholdtsen wrote:
> [Russ Allbery]
>> It's probably worth mentioning that this is basically the path down
>> which OpenRC went, except that OpenRC has taken the concept somewhat
>> further to allow the dependencies to be specified in code instead of
>> comments (using special shell functions).  You may want to take a
>> look at their syntax, since it's extremely close to what you're
>> doing but possibly a bit more fleshed out.
> 
> Yeah, I discovered that OpenRC had a similar approach, but without
> staying compatible with our current set of scripts in /etc/init.d/.

[1] Sorry... what?!? :)

It's perfectly compatible. You just decide what you want to
(re-)implement or not. In fact, that's one of the very strong point of
OpenRC: it allows a very smooth migration away from sysv-rc, where one
can decide what to re-write or not.

> The two goals I had in mind were to allow us to migrate individual
> scripts to this system without having to replace sysv-rc, file-rc, or
> any of the other implementations currently running init.d scripts (ie
> stay compatible with the current LSB based init.d script format)

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows to
mix dependencies with LSB or it's own implementation.

> and reduce the code duplication between init.d scripts. OpenRC can't
> provide both these, as far as I can see. 

Look again! :)

> It solve a lot of other problems for sure. :)

Yes.

> This approach also make it easier to identify the "simple" init.d
> scripts, and possibly also make it easier to integrate them with for
> example systemd and upstart by providing a replacement for the
> init-d-script script or by extending init-d-script.

Unfortunately, it doesn't, because there will be problems with
dependencies, as much as I understand.

Cheers,

Thomas

[1] Because there's readers not assuming good faith: no pun intended,
just huge surprise to read that...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f369f4.6060...@debian.org

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand]

On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote:
> Hi.
> 
> A few months ago I drafted an idea to rewrite init.d scripts to use a
> common implementation and only specify the unique parts in the init.d
> scripts themselves.  That draft can be found on
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>  >.
> 
> The idea is to let init.d scripts look like this:
> 
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond

By the way, I forgot to mention: the shebang thing replacement was
painful in OpenRC, so we recently made it so that we don't need to
replace it by /bin/openrc-run (previously called "runscripts")... :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f36ae0.9060...@debian.org

Bug#737830: ITP: belle-sip -- SIP stack from the Linphone team

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: belle-sip
  Version : 1.2.4
  Upstream Author : Jehan Monnier 
* URL : http://www.linphone.org/
* License : GPL2+, GPL3+, BSD, MIT, zlib
  Programming Lang: C and ANTLR
  Description : SIP stack from the Linphone team

Belle-Sip is a new SIP stack (RFC3261) developed by the Linphone team.

Belle-Sip supports multiple transports at the same time, has a dual IPv6 and
IPv4 stack, is fully asynchronous and implements the +sip.instance and alias
parameters. It also handles network disconnections better, offers a privacy API
and supports rich presence.

SIP/TLS is handled by the lightweight polarssl library (as opposed to openssl).

Relevance:

This library is required to build the latest Linphone beta version 3.6.99. It
will probably replace libosip and libeXosip, a more mature SIP stack, in future
Linphone releases.

Maintenance:

I plan to submit the package to the Debian VOIP Team and hope to contribute to
maintenance going forward.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206110008.11252.99011.reportbug@wu-desktop

Re: Two line init.d scripts? Sure, that will work!

[Petter Reinholdtsen]

[Thomas Goirand]
>> Yeah, I discovered that OpenRC had a similar approach, but without
>> staying compatible with our current set of scripts in /etc/init.d/.
>
> [1] Sorry... what?!? :)
>
> It's perfectly compatible. You just decide what you want to
> (re-)implement or not. In fact, that's one of the very strong point of
> OpenRC: it allows a very smooth migration away from sysv-rc, where one
> can decide what to re-write or not.

I realise I was a bit unclear.  I mean that openrc scripts can not be
used with sysv-rc and file-rc (or systemd or upstart), not that openrc
is unable to handle LSB compatible init.d scripts.  So a package
providing a openrc script will not be started on a system using
sysv-rc, if I understand it correctly.  Did I misundertand this?  I
realise openrc can handle all the existing init.d scripts with LSB
headers just fine.

> Since last summer, OpenRC has full support for LSB headers. Also, I
> believe that OpenRC is the only init system replacement which allows
> to mix dependencies with LSB or it's own implementation.

That is not the case.  Both systemd and upstart allow this as well.

>> This approach also make it easier to identify the "simple" init.d
>> scripts, and possibly also make it easier to integrate them with for
>> example systemd and upstart by providing a replacement for the
>> init-d-script script or by extending init-d-script.
>
> Unfortunately, it doesn't, because there will be problems with
> dependencies, as much as I understand.

Yes, different name spaces will be a challenge.  But it can be handled
by deciding to keep the name spaces in sync, using the same name for
the same service in LSB headers, upstart jobs and systemd jobs.

--
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
Archive: http://lists.debian.org/20140206110622.gj1...@ulrik.uio.no

Re: Two line init.d scripts? Sure, that will work!

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> Ah, had completely forgotten about that script./lib/init/upstart-job.
> Thank you for bringing it to my attention.  Found the
> /lib/init/upstart-job script in the upstart package and the code to
> allow insserv to run '/etc/init.d/script lsb-header' to generate the
> LSB header from the upstart job.

This will break if you're using systemd and there's no systemd service
for the service in question, so this is a pretty icky approach.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppn0qz5j@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Tollef Fog Heen]

]] Thomas Goirand 

> Since last summer, OpenRC has full support for LSB headers. Also, I
> believe that OpenRC is the only init system replacement which allows to
> mix dependencies with LSB or it's own implementation.

It's not, systemd has provided this from the start.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lhxoqz1c@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> > Since last summer, OpenRC has full support for LSB headers. Also, I
> > believe that OpenRC is the only init system replacement which allows
> > to mix dependencies with LSB or it's own implementation.
> 
> That is not the case.  Both systemd and upstart allow this as well.

How do I write an upstart job that depends on a sysvinit service being
started (which again depends on a specific upstart job being started)?
IIRC, that's not supported, since init scripts aren't first class
citizens in upstart.  That might have changed since last time I looked
at upstart, though.

> Yes, different name spaces will be a challenge.  But it can be handled
> by deciding to keep the name spaces in sync, using the same name for
> the same service in LSB headers, upstart jobs and systemd jobs.

That + alias support.  Anything else is not going to work.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ha8cqywt@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Petter Reinholdtsen]

[Thomas Goirand]
> Well, you've been trying to reimplement OpenRC... with less
> features!  Don't bother, switch to OpenRC, and call it a day... :)

Actually, I am trying to reduce code duplication in /etc/init.d/ while
allowing package maintainers an easy way to stay compatible with
systemd, upstart, openrc, sysv-rc and file-rc, which to me is a
different problem than OpenRC try to solve. :)

Those that want to keep their current init.d script can do so without
any problems from this new approach whatsoever, so this is just an
option for those that want to move the task of writing init.d scripts
to me (or the ones maintaining init-d-script) instead of keeping it
for themselves. :)

> By the way, I forgot to mention: the shebang thing replacement was
> painful in OpenRC, so we recently made it so that we don't need to
> replace it by /bin/openrc-run (previously called "runscripts")... :)

Where can I read more about these problems.  One obvious and annoying
one is that 'sh -x /etc/init.d/script start' no longer work, making it
harder to debug the scripts, but that is the only one I have seen so
far.

-- 
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
Archive: http://lists.debian.org/20140206113000.gb13...@ulrik.uio.no

Re: Two line init.d scripts? Sure, that will work!

[Petter Reinholdtsen]

[Sergey B Kirpichev]
> Peter, thank you for your work.  Have you tried any complex init
> script to fit this business (apache2 or postfix, for example)?

Nope.  It is ment as an option for the packages with simple needs.
Those with complex needs can use it too, probably, but it might be
easier to just keep the current init.d scripts.

> BTW, I don't think your postfix script is an actual replacement for
> the current init-script.  For example, there are create_xconsole()
> and sendsigs_omit() functions.

Ah, good point.  Added do_start_cleanup and do_stop_prepare hooks to
cater for such needs.

> Also, there is the do_rotate function - a very common example when
> you want to implement a custom action (not just one from fixed set
> start/stop/reload/etc).

Not quite sure if that is within scope of this mechanism.  Will think
more about it.

> Also, you should keep in mind this scenario as well:
> https://lists.debian.org/debian-ctte/2013/12/msg00156.html

Multiple daemons is definitely out of scope.

> Last but not least, we can utilize custom lsb-headers (X-Debian-*
> like) to keep information like pidfile or daemon binary path name.
> I think, there is a parser for this LSB-info somewhere in the lsb-*
> packages.

Why do you believe this is an advantage?

PS: Peter Reinholdtsen is my distant cousin. 
-- 
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
Archive: http://lists.debian.org/20140206113555.gd13...@ulrik.uio.no

Re: debconf managed configuration files

[Vincent Danjean]

On 05/02/2014 10:42, Daniel Pocock wrote:
> I've also found some references to the UCF package but it is not
> referenced in the debconf-devel manpage itself, is UCF the way to go or
> is this a red herring?

If the default configuration file is shipped as-is by the package
(no changes due to debconf question, local tests, ...), then ucf
is not very interesting (more complex to manage, the only advantage
I see is the possibility of three-way merge).

  As soon as the contents of the configuration file cannot be put as-is
in the package and must be changed/edited, then dpkg conffile cannot
be used (else, you get a prompt on upgrade without local modifications).
  In this case, I find ucf very convenient. Ucf does lots of things
that I do not have to reimplement myself. My regret is that ucf is
not integrated with dpkg (so dpkg -S does not know ucf-managed files)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f378cf.3000...@free.fr

Re: Two line init.d scripts? Sure, that will work!

[Ian Jackson]

Petter Reinholdtsen writes ("Two line init.d scripts?  Sure, that will work!"):
> A few months ago I drafted an idea to rewrite init.d scripts to use a
> common implementation and only specify the unique parts in the init.d
> scripts themselves.  That draft can be found on
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>  >.
> 
> The idea is to let init.d scripts look like this:

Before you go too far down this path, I'd like to suggest that you do
something which makes it possible to provide init system configuration
for other than sysvinit, at the same time.  And that you use an
arrangement which uses a non-forking startup protocol for the daemon.

I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21235.30991.367467.686...@chiark.greenend.org.uk

Re: Two line init.d scripts? Sure, that will work!

[Helmut Grohne]

Hi Ansgar,

I am sorry to tell you that you are completely missing the point.

On Thu, Feb 06, 2014 at 11:35:17AM +0100, Ansgar Burchardt wrote:
> On 02/06/2014 10:56, Helmut Grohne wrote:
> > The relevant bits can be found in insserv, watch out for
> > "/lib/init/upstart-job".
> 
> The current version of insserv in unstable, 1.14.0-5, doesn't seem to
> contain this file.

insserv does not provide the upstart-job wrapper, but it supports(!) it
in being able to parse generated dependencies rather than reading the
init script.

> > My attempt to reproduce such a utility for systemd have not worked out
> > unfortunately (for lack of time/interest).
> 
> Using systemd jobs instead of the init script if available is already
> implemented:
> 
> ~ # /etc/init.d/cron restart
> [ ok ] Restarting cron (via systemctl): cron.service.

This functionality is entirely orthogonal to the one I was proposing.
You are talking about redirecting the init script invocation to a
running systemd instance. I am talking about sysvinit (as pid 1) to
execute systemd .service descriptions.

> How would the init script continue to work on sysvinit if it was
> replaced with a symlink as you said earlier?

When you invoke /etc/init.d/foo you really invoke the helper (e.g.
/lib/init/upstart-job). This helper evalutes its argv and determines,
that it is acting for service foo and what action to carry out. It then
reads the corresponding (the name foo must match here) job description
and carries out the configured actions.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206120724.ga18...@alf.mars

Re: Re: Two line init.d scripts? Sure, that will work!

[Sergey B Kirpichev]

> Where can I read more about these problems.  One obvious and annoying
> one is that 'sh -x /etc/init.d/script start' no longer work, making it
> harder to debug the scripts

Probably init-d-script could pass some cli-specified options to sh
with set builtin.  To allow something like this:

/etc/init.d/script -x start
or
/etc/init.d/script start -x


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206121607.ga6...@darkstar.order.hcn-strela.ru

Re: Two line init.d scripts? Sure, that will work!

[Helmut Grohne]

On Thu, Feb 06, 2014 at 11:47:24AM +0100, Petter Reinholdtsen wrote:
> actions on services).  Do I misunderstand how upstart-job work?  If I
> install a package with an upstart job and a symlink to
> /lib/init/upstart-job from /etc/init.d/ on Hurd, will it work?
> Testing...  Nope, did not work:

Thanks for evaluating the methodology on Hurd! I am sure that this is
not caused by a fundamental flaw and would consider your observation to
be a bug in the implementation.

> My idea was to make sure systems based on linux, kfreebsd and hurd
> could keep using the init.d scripts even if upstart, systemd or openrc
> is used by default on Linux, by reducing the maintenance burden for
> package maintainers to keep such scripts working.  Both upstart,
> systemd, openrc, file-rc and sysv-rc are able to start daemons in
> packages providing init.d scripts, and the LSB require such scripts to
> keep working, so we would most likely have that support around until
> we decide to drop LSB support in Debian.

The goal to have a portable interface is venerable and I for one fully
support it. While it is true that currently the LSB init script
interface is the supported method, I do not think that keeping this
support should be a long term goal. We had extensive discussion on this
already and if you read the TC discussion, you'll notice that getting
rid of this interface is among the top reasons for choosing an
alternative. This is why I argue to wrap up one of the contenders and
make it support the old interface reasonably well for some time, before
ditching it entirely.

> Well, I do not add a standard.  I keep the existing LSB standardized
> init.d script standard and make them easier to maintain by reducing
> the amount of information/code each package maintainer need to provide.

Essentially you are. Similarly you could argue that cdbs was not a
standard for Debian packages. Your helper creates a layer that needs to
be understood to interface with it. This is kind of a gray area, so I
would rather not oppose your solution if it turns out to work well. Good
luck with that!

> > Why not write an upstart job instead? It works with sysvinit today!
> 
> Because it only work with upstart at the moment. :)

Point taken. I still think that this is a limitation of the current
packaging rather than a fundamental one. If one assumes that the TC
decides in favour of upstart, this would be one of the first things to
fix in order to be able to drop init scripts in favour of job
descriptions. I am making no claims about the actual result though.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206123243.gb18...@alf.mars

Re: Two line init.d scripts? Sure, that will work!

[Simon McVittie]

On 06/02/14 12:07, Helmut Grohne wrote:
> This functionality is entirely orthogonal to the one I was proposing.
> You are talking about redirecting the init script invocation to a
> running systemd instance. I am talking about sysvinit (as pid 1) to
> execute systemd .service descriptions.

I'm sure we've been over this, on this very list, in several previous
threads. I used to think this was a great idea, too; I've been convinced
that it isn't feasible.

Part of the reason that systemd service descriptions are so simple is
that there's a significant amount of code in systemd to make them
simpler. Any wrapper that executed these descriptions would need to
provide the same semantics (or a large subset, and significant effort to
debug service descriptions that were only tested with "real systemd" and
make them work with "fake systemd").

One example is that because systemd uses cgroups to "capture" all the
processes from a service, the service doesn't need to be careful to
track all its child, grandchild, etc. processes and make sure they get
cleaned up. (Real-world example: gdm3 doesn't currently kill all its
child processes on exit,
. I suspect
that that bug just doesn't happen under systemd - which was probably the
only configuration tested upstream - because systemd + cgroups do that
work, once, for all services.)

Another example is that socket activation and automounting filesystems
means that many dependencies can be implicit. (Real-world example:
systemd services never need to depend on dbus.service or syslog.service,
only on the corresponding sockets, which are part of the default
dependency set.)

I'm sure there are more bits and pieces like those, that systemd
services are free to rely on for (potentially major) simplifications.

If you think you can prove me wrong, you're more than welcome to write
the tool that does this. I would predict that it will need to be written
in C/C++ to get enough control; it will either be Linux-specific or have
explicitly separate code paths for Linux and kFreeBSD; by the time it
works reliably, it'll look rather similar to systemd; and by the time
you've sorted out circular dependencies, it'll have about the same level
of coupling between components as systemd. If I'm wrong about that,
great; again, please prove me wrong.

I'm not going to write that tool, because I already have one; it's
called systemd. :-)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f38169.8070...@debian.org

Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Sebastian Reichel]

Hi,

There have been multiple new upstream releases for stunnel4 and the
package has gathered quite some bugs without any feedback from its
maintainer. Looking at Rodrigo's QA page [0] his last actions were
quite some time ago (2012) and most packages would have gathered RC
bugs without the help of some fellow Debian Developers doing NMUs.

Lennart Weller has prepared an updated package for stunnel4, which
does not fit the default NMU criteria (e.g. being minimal) and is
also willing to take over the package. I would sponsor the package
for him once Rodrigo's status is clear.

So here are my questions:
 * Does anyone know Rodrigo's whereabouts/status?
 * Can the MIA team take this over?

[0] http://qa.debian.org/developer.php?login=rodrigo&comaint=yes

-- Sebastian


signature.asc
Description: Digital signature

Re: Re: Two line init.d scripts? Sure, that will work!

[Sergey B Kirpichev]

>> Peter, thank you for your work.  Have you tried any complex init
>> script to fit this business (apache2 or postfix, for example)?
>
> Nope.  It is ment as an option for the packages with simple needs.
> Those with complex needs can use it too, probably, but it might be
> easier to just keep the current init.d scripts.

They aren't too complex, actually.

> Ah, good point.  Added do_start_cleanup and do_stop_prepare hooks to
> cater for such needs.

Probably, we should have hooks,
that can be invoked before specified action (e.g. start or stop)
and after.  But not just for start/stop.

BTW, there is try-restart action, mentioned in the LSB.  Probably,
you should add this.  And you can implement some standard
do_reload function (with HUP signal), disabled by
default; the package maintainer can enable this with one-liner like
alias do_reload_override=standard_boilerplate_for_do_reload

Also, a very common pattern is to specify some daemon
options somewhere in /etc/default/.  Probably, it's a good
idea to include /etc/default/$YOUNAMEIT file and use
some variable (e.g. $OPTIONS) to provide additional
arguments to do_start_cmd/do_restart_cmd/do_reload_cmd.

>> Also, there is the do_rotate function - a very common example when
>> you want to implement a custom action (not just one from fixed set
>> start/stop/reload/etc).
>
> Not quite sure if that is within scope of this mechanism.  Will think
> more about it.

You can add a specific helper to be invoked if a non-standard
action is specified.  Only if that helper doesn't exist
OR fail with status code 3 - call usage().  Then exit with the
provided status code (or 3).

> Multiple daemons is definitely out of scope.

I don't think that it's a bad idea to think about.

PS:
> PS: Peter Reinholdtsen is my distant cousin.

Sorry for typo :(


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206132429.gb6...@darkstar.order.hcn-strela.ru

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Thomas Goirand]

On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote:
>> Since last summer, OpenRC has full support for LSB headers. Also, I
>> believe that OpenRC is the only init system replacement which allows
>> to mix dependencies with LSB or it's own implementation.
> 
> That is not the case.  Both systemd and upstart allow this as well.

I knew that both systemd and upstart can use LSB header scripts. But I
read that upstart (at least) would launch these only at the end of the
boot process, not mixing them in the boot order with upstart jobs. Can
any Upstart specialist (Steve maybe?) can tell if this is right or
wrong? What is systemd doing exactly with the LSB dependencies?

With OpenRC, what happens is that the LSB headers are transformed into
the internal syntax of OpenRC (eg: use, need, after, provide, etc.),
which makes it possible to have LSB header scripts be integrated within
the ordering calculation, just as if they were native OpenRC runscripts.
They are also involved in the dependency loop breaking system that has
recently been added to OpenRC.

BTW, Debian has a way too many LSB header scripts with Required-Start:
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing. How does systemd & upstart deal with this pile of
garbage that Required-Start: $all is?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f38ff3.7010...@debian.org

Re: amd64 arch and optimization flags?

[Felipe Sateler]

On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote:

> On 06.02.2014 00:39, Jaromír Mikeš wrote:
>> 
>> Hi all,
>> 
>> I would like to add some optimization flags for amd64 arch in some
>> packages (mostly LV2 nad LADSPA plugins).
>> I found these as candidates for amd64 arch:
>> 
>> -msse -msse2 -mfpmath=sse
> 
> this is enabled by default on amd64
> 
>> -ffast-math
> 
> this is dangerous it changes results, sometimes significantly (e.g. for
> complex numbers), only use if you don't care about correctness or have
> verified its still correct.

IME, audio processing software can get away with it. Csound and its 400+ 
library of opcodes has been built with this option and I have had no 
complaints yet.

What is dangerous about this options? I see a warning in the gcc docs, 
but how can I know if my program relies "on a precise definition of IEEE 
floating point"?

> 
>> -ftree-vectorize
> 
> this does sometimes slow programs down, usually only programs doing
> numeric work profit from it, these usually enable it by themselves.
> It is enabled by the -O3 optimization level.
> it is mostly safe to use if you follow the C standard strictly (i.e. no
> unaligned access of aliased variables)

Audio processing software tend to be about numeric work ;)

It is probably better to pass -O3 to performance critical code.

> 
>> -mtune=generic
> 
> should be the default, but you can safely change that to something else.
> generic in gcc < 4.9 is I think pentium4 which is a very old chip.
> 
> gcc-4.9 will change the default of it to bulldozer/intel-core btw:
> http://gcc.gnu.org/gcc-4.9/changes.html

My experience is that -mtune=generic provides a great boost over no -
mtune, at least on i386 when I tested it.

I have just tested again on amd64 and it makes no difference.


-- 
Saludos,
Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ld03jt$8d5$1...@ger.gmane.org

Re: Two line init.d scripts? Sure, that will work!

[Thomas Goirand]

On 02/06/2014 08:34 PM, Simon McVittie wrote:
> it'll look rather similar to systemd; and by the time
> you've sorted out circular dependencies, it'll have about the same level
> of coupling between components as systemd.

Why that? Dependency loops just have to be broken at run time when
calculating the boot order, I don't see why this would introduce high
coupling between components. Could you explain?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f396ff.7080...@debian.org

Re: Two line init.d scripts? Sure, that will work!

[Helmut Grohne]

On Thu, Feb 06, 2014 at 12:34:49PM +, Simon McVittie wrote:
> I'm sure we've been over this, on this very list, in several previous
> threads. I used to think this was a great idea, too; I've been convinced
> that it isn't feasible.

Yes, I concur with the reasoning that I didn't quote here. In fact I
brought up many of those reasons on my own. I consider the eliding of
dependency information the most difficult hurdle to overcome.

> If you think you can prove me wrong, you're more than welcome to write
> the tool that does this. I would predict that it will need to be written
> in C/C++ to get enough control; it will either be Linux-specific or have
> explicitly separate code paths for Linux and kFreeBSD; by the time it
> works reliably, it'll look rather similar to systemd; and by the time
> you've sorted out circular dependencies, it'll have about the same level
> of coupling between components as systemd. If I'm wrong about that,
> great; again, please prove me wrong.

I think this is 90% correct. Writing a 100% compatible .service
interpreter basically amounts to the same complexity as writing systemd.
But there is a twist here. The stupid portability argument that many
(including me) keep making over and over again. So rather than rewrite
100% of systemd to achieve 100% compatibility a feasible goal may(!) be
to rewrite 10% of systemd in a portable way to be able to run 50% of the
real world .service files. That's already a significant fraction in
terms of not having to maintain init scripts.

Unfortunately I will not be able to pull this alone. My earlier request
for help or even interest was met with silence. I guess that most people
are fine with running the reference implementation on a supported
kernel. Me too.

Now we drifted a fair bit from the original argument. Unlike systemd,
upstart has a head start here. It provides a somewhat limited reverse(!)
compatibility wrapper today. The design decisions made by the upstart
developers make it easier to write and port this wrapper than it is for
systemd for precisely the reasons not quoted from your mail.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206142054.ga16...@alf.mars

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Tollef Fog Heen]

]] Thomas Goirand 

> BTW, Debian has a way too many LSB header scripts with Required-Start:
> $all, which is very bad. A decent init system has to deal with this, and
> there's no sane way to do so but arbitrarily breaking what the author of
> the script wrote. A lintian warning telling that $all is just bad would
> be a very nice thing. How does systemd & upstart deal with this pile of
> garbage that Required-Start: $all is?

$all obviously (as you point out) doesn't work well. Semantically, it
doesn't make sense to have more than one script depending on $all.
IIRC, systemd just ignores it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2j0qpw9@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Joey Hess]

Petter Reinholdtsen wrote:
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond

> As for the line counting in the subject, I decided to ignore commented
> lines.  Including those, we end up on 11 lines. :)

If there was ever any doubt that LSB's abuse of comments in init script
headers was a bad idea (of the sort committees commonly develop),
I think you've conclusively proven it here.

-- 
see shy jo


signature.asc
Description: Digital signature

please warn about "Required-Start: $all" in legacy init scripts

[Holger Levsen]

package: lintian
severity: wishlist

Hi,

On Donnerstag, 6. Februar 2014, Thomas Goirand wrote:
> BTW, Debian has a way too many LSB header scripts with Required-Start:
> $all, which is very bad. A decent init system has to deal with this, and
> there's no sane way to do so but arbitrarily breaking what the author of
> the script wrote. A lintian warning telling that $all is just bad would
> be a very nice thing.


cheers,
Holger


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

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Sergey B Kirpichev]

> $all obviously (as you point out) doesn't work well. Semantically, it
> doesn't make sense to have more than one script depending on $all.

What I should use instead?  Use case:
http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206145958.ga9...@darkstar.order.hcn-strela.ru

Bug#737867: please warn about "Required-Start: $all" in legacy init scripts

[Holger Levsen]

package: lintian
severity: wishlist
x-debbugs-cc: 
debian-devel@lists.debian.org,pkg-sysvinit-de...@lists.alioth.debian.org

Hi,

On Donnerstag, 6. Februar 2014, Thomas Goirand wrote:
> BTW, Debian has a way too many LSB header scripts with Required-Start:
> $all, which is very bad. A decent init system has to deal with this, and
> there's no sane way to do so but arbitrarily breaking what the author of
> the script wrote. A lintian warning telling that $all is just bad would
> be a very nice thing.


cheers,
Holger



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

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Tollef Fog Heen]

]] Sergey B Kirpichev 

> > $all obviously (as you point out) doesn't work well. Semantically, it
> > doesn't make sense to have more than one script depending on $all.
> 
> What I should use instead?  Use case:
> http://packages.qa.debian.org/m/monit.html

That's not a use case.

> Usually, you want to start this service last and stop first.

Why should it start last?  (Stopping first I can see the point of, to
avoid spuriously restarting a daemon that's just been shut down, but it
should probably then just integrate with the init system so it knows if
the system is about to shut down and then avoid restarting daemons.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878utoqnru@xoog.err.no

Re: debconf managed configuration files

[Dominique Dumont]

On Wednesday 05 February 2014 10:42:23 Daniel Pocock wrote:
> Has anybody written any further documentation about debconf with
> configuration files, for example, for those that don't meet the
> assumptions for the example in the debconf-devel manpage?
> 
> Are there any particular packages that are regarded as examples of best
> practice?

Depending on what you want to achieve, you may be interested by 
https://wiki.debian.org/PackageConfigUpgrade (although this does not use 
debconf)

I've recently updated this page. Unfortunately, I still have not found the 
time to update the documentation before uploading the new version of lcdproc 
(which is showcased in this page)

Hope this helps 

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1762861.niBGnQ49Wd@ylum

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Sergey B Kirpichev]

>> Usually, you want to start this service last and stop first.
>
> Why should it start last?

Because monit is not systemd.  monit - is only an utility for
proactive monitoring, not yet another init-replacement.

So, lets start services first, then start monitoring.  Do
we want to play races with sysvinit?  No.  Now can you see the point?

> but it should probably then just integrate with the init
> system so it knows if the system is about to shut down and
> then avoid restarting daemons.

The above use case is just a simplest example of such
integration.  It's sysvinit responsibility to start/stop monit
as appropriate.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206155156.gb18...@darkstar.order.hcn-strela.ru

Bug#737872: ITP: vim-snipmate -- Vim script that implements some of TextMate's snippets features.

[Andrea Capriotti]

Package: wnpp
Severity: wishlist
Owner: Andrea Capriotti 

* Package name: vim-snipmate
  Version : 0.84
  Upstream Author : Michael Sanders 
* URL : http://www.vim.org/scripts/script.php?script_id=2540
* License : MIT
  Programming Lang: Vim
  Description : Vim script that implements some of TextMate's snippets
features.

 SnipMate.vim aims to be an unobtrusive, concise vim script that implements
 some of TextMate's snippets features in Vim. A snippet is a piece of
 often-typed text that you can insert into your document using a trigger word
 followed by a .

 For instance, in a C file using the default installation of snipMate.vim, if
 you type "for" in insert mode, it will expand a typical for loop in C:

 for (i = 0; i < count; i++) {

 }

 To go to the next item in the loop, simply  over to it; if there is
 repeated code, such as the "i" variable in this example, you can simply start
 typing once it's highlighted and all the matches specified in the snippet will
 be updated.

 snipMate.vim has the following features among others:

  - The syntax of snippets is very similar to TextMate's, allowing easy
conversion.
  - The position of the snippet is kept transparently (i.e., it does not use
marks/placeholders inserted into the buffer), allowing you to escape out
of an incomplete snippet, something particularly useful in Vim.
  - Variables in snippets are updated as-you-type.
  - Snippets can have multiple matches.
  - Snippets can be out of order. For instance, in a do...while loop, the
condition can be added before the code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206160608.12710.40801.report...@nb-capriotti.cineca.it

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Thomas Goirand]

On 02/06/2014 10:59 PM, Sergey B Kirpichev wrote:
>> $all obviously (as you point out) doesn't work well. Semantically, it
>> doesn't make sense to have more than one script depending on $all.
> 
> What I should use instead?  Use case:
> http://packages.qa.debian.org/m/monit.html
> Usually, you want to start this service last and stop first.

Let's say you want to run monit in Hurd, then it must *not* start last.
The last one must always be the hurd console.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f3bdec.8050...@debian.org

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Tollef Fog Heen]

]] Sergey B Kirpichev 

> >> Usually, you want to start this service last and stop first.
> >
> > Why should it start last?
> 
> Because monit is not systemd.  monit - is only an utility for
> proactive monitoring, not yet another init-replacement.
> 
> So, lets start services first, then start monitoring.  Do
> we want to play races with sysvinit?  No.  Now can you see the point?

An init system that doesn't handle the case of something going «please
start $service» when it's already in the process of starting that
service, is buggy.

> > but it should probably then just integrate with the init
> > system so it knows if the system is about to shut down and
> > then avoid restarting daemons.
> 
> The above use case is just a simplest example of such
> integration.  It's sysvinit responsibility to start/stop monit
> as appropriate.

Sure, worst case is that monit, in the middle of shutting down, requests
a service start which won't ever happen (because the machine will be
shut down by then).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871tzgqev4@xoog.err.no

Re: Two line init.d scripts? Sure, that will work!

[Vitaliy Filippov]

I'm sure there are more bits and pieces like those, that systemd
services are free to rely on for (potentially major) simplifications.


...and IMHO it's the main systemd problem: it's too complex. :)
And my personal opinion is that having implicit dependencies also isn't  
good...


--
With best regards,
  Vitaliy Filippov


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/op.xavhpsyr0ncgu9@vitalif.vhome

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Sergey B Kirpichev]

> An init system that doesn't handle the case of something going «please
> start $service» when it's already in the process of starting that
> service, is buggy.

It's not the problem, as all (most) debian's init-scripts use
start-stop-daemon.  The real problem - email notifications.  You don't
want them while normal system startup, but if you start monit in the
middle of system initialization - you will got them.

Are you trying to sell me yet another init or do you suggest some
alternative solution *with* Debian's sysvinit, not using
"Should-Start/Stop: $all"?  If the first, please stop.  If
the second - please go ahead.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206191501.ga18...@darkstar.order.hcn-strela.ru

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Tollef Fog Heen]

]] Sergey B Kirpichev 

> Are you trying to sell me yet another init or do you suggest some
> alternative solution *with* Debian's sysvinit, not using
> "Should-Start/Stop: $all"?  If the first, please stop.  If
> the second - please go ahead.

No.

I'm pointing out why $all doesn't do what you want.  «$all» means «after
everything else has started» and if you have two of those, you have a
loop.  Loops are bugs.

In your particular case (and sysvinit), I'd say the admin should just
add dependencies on the monit script for the monitored services since I
don't think sysvinit support dynamically generating those dependencies
on boot. (If it does, I'm sure somebody will chime in with how to do it
for sysvinit.)

With systemd, I'd say a generator that adds After+Wants:
$monitored_services would be the right (and better) solution (this would
also solve the shutdown problem).  I assume upstart has a reasonable way
to solve this, but I'm not familiar with what it should be.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txccovwy@xoog.err.no

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Chris Knadle]

On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote:
> Hi,
> 
> There have been multiple new upstream releases for stunnel4 and the
> package has gathered quite some bugs without any feedback from its
> maintainer. Looking at Rodrigo's QA page [0] his last actions were
> quite some time ago (2012) and most packages would have gathered RC
> bugs without the help of some fellow Debian Developers doing NMUs.
> 
> Lennart Weller has prepared an updated package for stunnel4, which
> does not fit the default NMU criteria (e.g. being minimal) and is
> also willing to take over the package. I would sponsor the package
> for him once Rodrigo's status is clear.
> 
> So here are my questions:
>  * Does anyone know Rodrigo's whereabouts/status?
>  * Can the MIA team take this over?
> 
> [0] http://qa.debian.org/developer.php?login=rodrigo&comaint=yes
> 
> -- Sebastian

NMUs don't necessarily need to be minimalistic -- for instance packaging new 
versions is something that can be done with NMUs.  This is admittedly not 
terribly clear and I raised this question in #672198 which hasn't had any 
activity for almost two years.

For cases where the maintainer is unresponsive for an extended period, I'd 
recommend requesting a new version via a 'wishlist' bug, then releasing a new 
version as a -0.1 NMU.  Others (myself included) have done this successfully.

As always, thanks for your continued work in Debian.  ;-)

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

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

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Clint Byrum]

Excerpts from Tollef Fog Heen's message of 2014-02-06 11:58:37 -0800:
> ]] Sergey B Kirpichev 
> 
> > Are you trying to sell me yet another init or do you suggest some
> > alternative solution *with* Debian's sysvinit, not using
> > "Should-Start/Stop: $all"?  If the first, please stop.  If
> > the second - please go ahead.
> 
> No.
> 
> I'm pointing out why $all doesn't do what you want.  «$all» means «after
> everything else has started» and if you have two of those, you have a
> loop.  Loops are bugs.
> 
> In your particular case (and sysvinit), I'd say the admin should just
> add dependencies on the monit script for the monitored services since I
> don't think sysvinit support dynamically generating those dependencies
> on boot. (If it does, I'm sure somebody will chime in with how to do it
> for sysvinit.)
> 
> With systemd, I'd say a generator that adds After+Wants:
> $monitored_services would be the right (and better) solution (this would
> also solve the shutdown problem).  I assume upstart has a reasonable way
> to solve this, but I'm not familiar with what it should be.
> 

Correct me if I'm wrong, but there are basically two problems.

1) Some services are fragile and will behave badly if started before
some explicit services (nfsd needs nis-things running if nis is in use)
2) Some services are meant to be started after the system has reached a
steady state (monit, cron, etc).

For (1), upstart uses an upstart job I wrote, called wait-for-state.
This should be built into upstart, but ENOROUNDTUITS. You basically put
this in your pre-start:

pre-start exec start wait-for-state WAITER=$JOB WAIT_FOR=thingtowaitfor

This job will wait for the job if it is starting, or start it if it is
stopped, but can work in reverse for stopping/stopped things as well. This
works fairly reliably, but it is somewhat confusing. Ideally upstart
would just have a 'while' condition instead of or in addition to 'start
on'. It is, btw, a myth that Upstart is not state based. It is, it just
makes it a huge PITA to actually use the state it tracks quite nicely.

For (2), the system startup itself needs some re-working from the way
Ubuntu has done it and upstart works in Debian. Right now, you basically
have carefully orchestrated plumbing events that lead up to the system
reaching the default runlevel. At that point, we go into hyper-parallel
mode because most daemons should be:

start on runlevel [2345]
stop on runlevel [016]

This works fine for things like apache and mysql, because they can start
in parallel and if your web app doesn't work for a few seconds while
mysql gets its stuff together oh-well. Trying really hard to get all of
the relationships right for all of the daemons in Debian is not going to
work well.  There is no reason that anything that normally communicates
over the network should ever assume its dependent services are already up.

For the things that matter a lot, the wait-for-state method exists.

But for monit, we want to start after basically everything, so we go
after sysvinit is completely done:

start on stopped rc RUNLEVEL=[2345]
stop on starting rc RUNLEVEL=[016]

This will at least start those things after mysql and apache are starting,
but rc is not blocked on them being _started_.  To do that, one just
needs to create some grouping jobs like this:

--/etc/init/network-services.conf--
start on runlevel [2345]
stop on runlevel [016]
description "All Network Services"
--end--

Then all the jobs that used runlevel just migrate to this:

start on starting network-services
stop on stopped network-services

Aside from making more sense to humans, that would allow things like
monit to say:

start on started network-services
stop on stopping network-services

This is just one of those things that requires time, and only fixes
really subtle bugs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1391718159-sup-4...@fewbar.com

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Sergey B Kirpichev]

> I'm pointing out why $all doesn't do what you want.

It's exactly what I want.

> «$all» means «after everything else has started» and if you
> have two of those

You have a bug.  Yes, some packages abuse $all, I admit this,
but not all of them (e.g. monit).

> In your particular case (and sysvinit), I'd say the admin should just
> add dependencies on the monit script for the monitored services since I
> don't think sysvinit support dynamically generating those dependencies
> on boot. (If it does, I'm sure somebody will chime in with how to do it
> for sysvinit.)

AFAIK, this can be done with /etc/insserv/overrides/
That is not a problem *for human* to add a file
in /etc/insserv/overrides/ and override monit's LSB-headers.

> With systemd, I'd say a generator that adds After+Wants:

The problem is not the mechanisms, like after+wants, not the
output format for this generator (systemd stuff or
LSB-headers) - but the generator itself.

So, I don't buy this "solution", sorry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140206221006.gb22...@darkstar.order.hcn-strela.ru

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Sebastian Reichel]

On Thu, Feb 06, 2014 at 03:27:51PM -0500, Chris Knadle wrote:
> On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote:
> [...]
>
> NMUs don't necessarily need to be minimalistic -- for instance packaging new 
> versions is something that can be done with NMUs.  This is admittedly not 
> terribly clear and I raised this question in #672198 which hasn't had any 
> activity for almost two years.

Yes, but its advised to change as little as possible. I think
changing the packaging style from cdbs to debhelper and similar
changes are not ok (note: this is just an example).

> For cases where the maintainer is unresponsive for an extended period, I'd 
> recommend requesting a new version via a 'wishlist' bug, then releasing a new 
> version as a -0.1 NMU.  Others (myself included) have done this successfully.

I opened the wishlist bug entry for that (#723781) in September and
agree, that uploading a -0.1 NMU would solve the issue of the new
upstream version.

OTOH having an active maintainer is more helpful than lots of NMUs
IMHO. Thus it makes more sense to take over packages or add at least
add a Co-Maintianer for this.

> As always, thanks for your continued work in Debian.  ;-)

You are welcome.

-- Sebastian


signature.asc
Description: Digital signature

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Chris Knadle]

Adding Gregor Herrmann to this because he and I were looking to work on 
#672198 but we both were swamped with other work.

On Friday, February 07, 2014 00:02:16 Sebastian Reichel wrote:
> On Thu, Feb 06, 2014 at 03:27:51PM -0500, Chris Knadle wrote:
> > On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote:
> > [...]
> > 
> > NMUs don't necessarily need to be minimalistic -- for instance packaging
> > new versions is something that can be done with NMUs.  This is admittedly
> > not terribly clear and I raised this question in #672198 which hasn't had
> > any activity for almost two years.
> 
> Yes, but its advised to change as little as possible. I think
> changing the packaging style from cdbs to debhelper and similar
> changes are not ok (note: this is just an example).

I know; I agree with you and I think the text is a bit misleading -- by 
stating that you shouldn't change the packaging style it seems to indicate 
that NMUs are supposed to be minimalistic, but a situation in which the 
maintainer of a package disappears for an extended period is exactly a 
situation in which a minimalistic change approach won't work.

> > For cases where the maintainer is unresponsive for an extended period, I'd
> > recommend requesting a new version via a 'wishlist' bug, then releasing a
> > new version as a -0.1 NMU.  Others (myself included) have done this
> > successfully.
>
> I opened the wishlist bug entry for that (#723781) in September and
> agree, that uploading a -0.1 NMU would solve the issue of the new
> upstream version.

When I last did this in #728545 for mumble, the situation was rather serious 
because it had been removed from jessie due to package dependency issues and 
needed to get fixed ASAP.  So I opened a wishlist bug, then waited about a 
week, then uploaded a package for review to mentors.debian.net and started 
hunting for a DD sponsor.

I contacted the prior maintainer, who examined the package and decided it was 
good enough and uploaded it to the DELAYED/5 queue.  Then I wrote to the bug 
to notify the maintainer in case he needed more time to respond and review the 
package if needed.

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728545

I didn't change the packaging style in doing this, but just about everything 
else did.  ;-)  Obviously I was willing to support the package if there were 
problems brought by my sponsored upload, and as long as you keep this in mind 
as well then I think this practice should work.

> OTOH having an active maintainer is more helpful than lots of NMUs
> IMHO. Thus it makes more sense to take over packages or add at least
> add a Co-Maintianer for this.

Right, exactly.  But to start with you may not want to do that; the maintainer 
normally gives approval for adding a co-maintainer.  After you've done several 
NMU uploads and tried to contact the maintainer via the MIA team, then after 
that I think the next logical step I think is to add one's self onto the list 
of Uploaders... basically only because I know of no better option rather than 
that being "the right thing to do".  Because it's not reasonable to be 
expected to do minimalistic changes for long periods of time.

So NMUs can solve things in the short-term, but between NMUs and "where to go 
from there" is still a limbo I haven't yet gotten good answers for.  There's 
been a lot of debate on [debian-devel] about this and NMUs are generally one 
of the answers, but there are situations that don't quite fit any standard 
situation.  Like for instance a maintainer might be MIA but ignoring one 
particular package for a long period of time, thus the MIA team can't say that 
the maintainer is really MIA, yet the package isn't getting maintenance, and 
thus no next logical step to take.  That's why I'm suggesting that adding 
one's self to Uploaders after some number of NMUs seems to make sense.  :-/  
Again not necessarily right, just "the least worst" next step I can think of.

> > As always, thanks for your continued work in Debian.  ;-)
> 
> You are welcome.

Cheers.  If you take the suggestion to do a new version NMU, keep in touch 
with me and let me know how it works out.  [Likewise if you're able figure out 
"the right path forward", let me know, because I'm likewise in a situation 
with a package where I need to know what the right solution for this is.  ;-)]

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

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

Work-needing packages report for Feb 7, 2014

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 512 (new: 11)
Total number of packages offered up for adoption: 152 (new: 2)
Total number of packages requested help for: 54 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   acoustid-fingerprinter (#737287), orphaned 5 days ago
 Description: Acoustid fingerprinter
 Installations reported by Popcon: 118

   cricket (#737290), orphaned 5 days ago
 Description: Program for collection and display of time-series data
 Installations reported by Popcon: 74

   django-authority (#737292), orphaned 5 days ago
 Description: more powerful permission system for Django
 Installations reported by Popcon: 30

   django-notification (#737293), orphaned 5 days ago
 Description: user notification management for Django
 Installations reported by Popcon: 37

   django-pagination (#737294), orphaned 5 days ago
 Description: utilities for creating pagination tools for Django
 Installations reported by Popcon: 52

   lua-augeas (#737298), orphaned 5 days ago
 Description: Lua binding to the Augeas C API
 Reverse Depends: deets
 Installations reported by Popcon: 15

   pristine-tar (#737871), orphaned today
 Description: regenerate pristine tarballs
 Reverse Depends: bzr-builddeb mercurial-buildpackage pkg-perl-tools
 Installations reported by Popcon: 2588

   readline5 (#737301), orphaned 5 days ago
 Description: GNU readline and history libraries, run-time libraries
 Reverse Depends: aptsh clisp dbacl dvbstreamer ice35-services
   lib32readline-gplv2-dev lib64readline-gplv2-dev
   libreadline-gplv2-dev libreadline5-dbg libreiser4-dev (8 more
   omitted)
 Installations reported by Popcon: 139348

   semanticscuttle (#737585), orphaned 2 days ago
 Description: Self-hosted and web-based social bookmark manager
 Installations reported by Popcon: 8

   stopwatch (#737302), orphaned 5 days ago
 Description: Virtual stopwatch and timer
 Installations reported by Popcon: 569

   tlslite (#737303), orphaned 5 days ago
 Description: a pure Python SSL/TLS library
 Installations reported by Popcon: 76

501 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   python-pefile (#737647), offered 2 days ago
 Description: Portable Executable (PE) parsing module for Python
 Installations reported by Popcon: 63

   springlobby (#737415), offered 4 days ago
 Description: single/multiplayer lobby for the Spring RTS engine
 Reverse Depends: springlobby-dbg
 Installations reported by Popcon: 298

150 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1466 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 79338

   athcool (#278442), requested 3390 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 54

   balsa (#642906), requested 865 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 808

   cardstories (#624100), requested 1018 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 11

   chromium-browser (#583826), requested 1348 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-dbg chromium-l10n mozplugger
 Installations reported by Popcon: 24418

   cups (#532097), requested 1706 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon
   cups-dbg (62 more omitted)
 Installations reported by Popcon: 136224

   debtags (#567954), requested 1466 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2419

   fbcat (#565156), requested 1485 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 153

   freeipmi (#628062), requested 987 days ago
 Description: GNU implementation of the IPMI protocol
 Reve

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Sebastian Reichel]

On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote:
> I know; I agree with you and I think the text is a bit misleading -- by 
> stating that you shouldn't change the packaging style it seems to indicate 
> that NMUs are supposed to be minimalistic, but a situation in which the 
> maintainer of a package disappears for an extended period is exactly a 
> situation in which a minimalistic change approach won't work.

Right. So just take over the package and do normal uploads? By
uploading normal changes as NMU this is what you effectively do
anyways.

> > > For cases where the maintainer is unresponsive for an extended period, I'd
> > > recommend requesting a new version via a 'wishlist' bug, then releasing a
> > > new version as a -0.1 NMU.  Others (myself included) have done this
> > > successfully.
> >
> > I opened the wishlist bug entry for that (#723781) in September and
> > agree, that uploading a -0.1 NMU would solve the issue of the new
> > upstream version.
> 
> When I last did this in #728545 for mumble, the situation was rather serious 
> because it had been removed from jessie due to package dependency issues and 
> needed to get fixed ASAP.  So I opened a wishlist bug, then waited about a 
> week, then uploaded a package for review to mentors.debian.net and started 
> hunting for a DD sponsor.
> 
> I contacted the prior maintainer, who examined the package and decided it was 
> good enough and uploaded it to the DELAYED/5 queue.  Then I wrote to the bug 
> to notify the maintainer in case he needed more time to respond and review 
> the 
> package if needed.
> 
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728545
> 
> I didn't change the packaging style in doing this, but just about everything 
> else did.  ;-)  Obviously I was willing to support the package if there were 
> problems brought by my sponsored upload, and as long as you keep this in mind 
> as well then I think this practice should work.

I think its okay for stunnel to simply follow the steps described in
the MIA section of the developers reference [0].

> > OTOH having an active maintainer is more helpful than lots of NMUs
> > IMHO. Thus it makes more sense to take over packages or add at least
> > add a Co-Maintianer for this.
> 
> Right, exactly.  But to start with you may not want to do that; the 
> maintainer 
> normally gives approval for adding a co-maintainer.  After you've done 
> several 
> NMU uploads and tried to contact the maintainer via the MIA team, then after 
> that I think the next logical step I think is to add one's self onto the list 
> of Uploaders... basically only because I know of no better option rather than 
> that being "the right thing to do".  Because it's not reasonable to be 
> expected to do minimalistic changes for long periods of time.

The MIA team can orphan packages if the maintainer is MIA, see [0].
Having a ghost-maintainer doing NMUs while the maintainer is MIA
feels wrong to me.

> So NMUs can solve things in the short-term, but between NMUs and "where to go 
> from there" is still a limbo I haven't yet gotten good answers for.  There's 
> been a lot of debate on [debian-devel] about this and NMUs are generally one 
> of the answers, but there are situations that don't quite fit any standard 
> situation.  Like for instance a maintainer might be MIA but ignoring one 
> particular package for a long period of time, thus the MIA team can't say 
> that 
> the maintainer is really MIA, yet the package isn't getting maintenance, and 
> thus no next logical step to take.  That's why I'm suggesting that adding 
> one's self to Uploaders after some number of NMUs seems to make sense.  :-/  
> Again not necessarily right, just "the least worst" next step I can think of.

If the maintainer is still working on some packages he should be
contactable. Thus one can simply ask the maintainer if he/she wants
to give the package to another maintainer or get a co-maintainer.

[0] 
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

-- Sebastian


signature.asc
Description: Digital signature

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Chris Knadle]

Leaving off the MIA team on this reply, mainly because I don't think this is 
"news" to them per se and I'd rather not "spam" them.

On Friday, February 07, 2014 02:54:09 Sebastian Reichel wrote:
> On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote:
> > I know; I agree with you and I think the text is a bit misleading -- by
> > stating that you shouldn't change the packaging style it seems to indicate
> > that NMUs are supposed to be minimalistic, but a situation in which the
> > maintainer of a package disappears for an extended period is exactly a
> > situation in which a minimalistic change approach won't work.
> 
> Right. So just take over the package and do normal uploads? By
> uploading normal changes as NMU this is what you effectively do
> anyways.

Well, here's the typical scenario:

   - maintainer stops maintaining a package, for whatever reason,
 and doesn't respond to communication... for a long time.

   - things change, the package you use that the maintainer had previously
 maintains breaks, or gets very old compared to upstream that 
 compatibility issues arise.

What are your options?  Without doing some kind of new upload, the package is 
in trouble.  By doing a new upload, like the maintainer would normally have 
done, you're /helping the maintainer/ as much as you're helping yourself.

To do anything else would mean everyone using the package living with some 
kind of brokenness in it, because you're perpetually "on hold" hoping the 
maintainer returns, and he/she might not.

That, unfortunately, happens.

Waiting, say, six months for the MIA process to complete so that you can take 
over a package really doesn't make sense if the next Stable release is going 
to be frozen within that timeframe and the package may get dropped for being 
ancient, if the package has fallen out of Testing because of dependency 
issues, if there are security or other RC bugs... and so on.  Whether or not 
you can wait depends on the situation.

[...]
> I think its okay for stunnel to simply follow the steps described in
> the MIA section of the developers reference [0].

Sure -- there's nothing wrong with trying that.  The idea is simply to find 
some avenue that works, whatever it is, and for that avenue to be as 
reasonable as possible for all parties.

> > > OTOH having an active maintainer is more helpful than lots of NMUs
> > > IMHO. Thus it makes more sense to take over packages or add at least
> > > add a Co-Maintianer for this.
> > 
> > Right, exactly.  But to start with you may not want to do that; the
> > maintainer normally gives approval for adding a co-maintainer.  After
> > you've done several NMU uploads and tried to contact the maintainer via
> > the MIA team, then after that I think the next logical step I think is to
> > add one's self onto the list of Uploaders... basically only because I
> > know of no better option rather than that being "the right thing to do". 
> > Because it's not reasonable to be expected to do minimalistic changes for
> > long periods of time.
> 
> The MIA team can orphan packages if the maintainer is MIA, see [0].
> Having a ghost-maintainer doing NMUs while the maintainer is MIA
> feels wrong to me.

There are situations in which the maintainer is /not/ MIA overall, but seems 
to be ignoring a particular package.  Let me know what you think is reasonable 
to do in that case.

The philosophy I've heard and am going by is the "Debian do-ocracy" -- 
(quoting one of Stefano Zacchiroli's talks [0]):

"An individual Developer may make any technical or nontechnical
 decision with regard to their own work;
 [ Debian Constitution, §3.3.1.1 ]"

The extension of this is that in lieu of the maintainer doing the work he/she 
would normally do but now isn't, your work should not be impeded perpetually 
as a result.  It therefore seems reasonable to do the necessary work yourself, 
trying to take the maintainer's wishes into account at the same time.

In these situations it is obviously best if the maintainer knew ahead of time 
that they'd not be maintaining the package anymore and orphan it such that 
another maintainer can do so, but that doesn't always happen.


[0] http://upsilon.cc/~zack/talks/2011/20110321-taipei.pdf


Also -- disclaimer -- this view I have is not without controversy, and I am 
not a DD, nor a DM.  I got into packaging work out of necessity because of 
package breakage, and so NMUs are a central part of what I currently do.
With them I have a path to fix issues with Debian package via sponsored 
uploads, without them I'm simply on hold waiting until the maintainer decides 
to show up with a new package -- and I think waiting 17 months was enough.

What I'm doing here is offering suggestions -- avenues of possible choices -- 
/not/ trying to tell you what to do or "what you should do".  How you decide 
to proceed is up to you and depends on how desperate you are to have the 
package you care about functional again, your 

Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[James McCoy]

Hi all,

In devscripts 2.13.3, uscan gained the ability to verify signature of
the upstream tarball using a file debian/upstream-signing-key.pgp.  In
2.14.0, I added the ability to use armored keys and decided to move the
files under debian/upstream/, an idea which had been suggested by a few
people.

This introduced a conflict with DEP-12 (c.f., #736760), which uses
debian/upstream to track metadata about the upstream project.  Tools
like umegaya[0] and Debian Med's task list[1] use the information
provided in this file.

[0]: http://upstream-metadata.debian.net/
[1]: http://blends.debian.org/med/tasks/

Part of the reason I chose to use debian/upstream/ is that an extensible
location for upstream related information (similar in spirit to
debian/source/) could be useful.  I also was unaware of (or had
forgotten about) DEP-12's existing use of debian/upstream, which was
appropriated around 01/2012 as the new name for
debian/upstream-metadata.yaml.

This leads to the question of how to move forward from here?

Transitioning to debian/upstream/ would require:

- Choosing a new name for DEP-12's file and updating the wording in
  DEP-12.  My suggestion would be debian/upstream/metadata.

- Updating the data collection code for umegaya and Debian Blends, the
  latter of which has an initial patch[2] based on my suggestion in 1).

- Renaming the file in the VCS repositories for all packages providing
  this information.  This is ~350 packages according to
  ullman:/srv/udd.debian.org/mirrors/machine-readable, which doesn't
  include packages that still haven't transitioned from
  upstream-metadata.yaml.  Note, that this only needs to happen in the
  VCS and not a source upload.

[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736760#35

Sticking with the status quo would require:

- Changing uscan to look for debian/upstream-signing-keys.{pgp,asc}

- Updating the ~17 packages that have started using debian/upstream/

While the latter is less work, my preference would be for the former
since it provides a consistent place to look for upstream information
in the context of a Debian source package.  It seems unlikely to me both
that uscan/DEP-12 will be the only projects that will want access to
upstream-related information and that any other information would
necessarily fit into one of those two buckets that they understand.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Process spervision with Monit support in init systems (was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))

[Thomas Goirand]

On 02/07/2014 03:58 AM, Tollef Fog Heen wrote:
> ]] Sergey B Kirpichev 
> 
>> Are you trying to sell me yet another init or do you suggest some
>> alternative solution *with* Debian's sysvinit, not using
>> "Should-Start/Stop: $all"?  If the first, please stop.  If
>> the second - please go ahead.
> 
> No.
> 
> I'm pointing out why $all doesn't do what you want.  «$all» means «after
> everything else has started» and if you have two of those, you have a
> loop.  Loops are bugs.
> 
> In your particular case (and sysvinit), I'd say the admin should just
> add dependencies on the monit script for the monitored services since I
> don't think sysvinit support dynamically generating those dependencies
> on boot. (If it does, I'm sure somebody will chime in with how to do it
> for sysvinit.)
> 
> With systemd, I'd say a generator that adds After+Wants:
> $monitored_services would be the right (and better) solution (this would
> also solve the shutdown problem).  I assume upstart has a reasonable way
> to solve this, but I'm not familiar with what it should be.

The only viable solution is to integrate monit support inside the init
system, like what's currently happening in OpenRC:

http://qnikst.github.io/posts/2013-11-06-openrc-supervision.html

with patch available here:

https://github.com/qnikst/openrc/compare/s-vision

Note that it is on my todo list to evaluate this patch, but I didn't
have the time to do that work yet. Any contribution would be welcome
from anyone willing to test it, and see if it integrates well with the
current OpenRC package.

Note that this has verry little to do with *process* supervision, like
it would be done with s6 (http://skarnet.org/software/s6/) which is also
on the OpenRC upstream todo list.

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f44bac.70...@debian.org

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Paul Wise]

Another project that looks at DEP-12 metadata is DUCK, the Debian URL
checker. I think it looks at DEP-12 stuff as a source of URLs to
check.

In your patch I think you mean [ ! -d $srcfile ] instead of -e? The
latter will match if debian/upstream is a dir or a file but I think
you want it to only match on files and maybe symlinks?

There are other issues with uscan/DEP-12;

debian/watch is duplicated in the Watch field in DEP-12 debian/upstream.

The Homepage field from debian/control is duplicated in DEP-12 debian/upstream.

umegaya doesn't support packages where there is no VCS. Not sure if
the blends site has the same issue?

-- 
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
Archive: 
http://lists.debian.org/caktje6ez0esinx3ze8ce+cjzmyfw_rfiyoijy7xpvozcwpn...@mail.gmail.com

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[James McCoy]

On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote:
> Another project that looks at DEP-12 metadata is DUCK, the Debian URL
> checker. I think it looks at DEP-12 stuff as a source of URLs to
> check.

From a quick glance, doesn't seem so.

> In your patch I think you mean [ ! -d $srcfile ] instead of -e? The
> latter will match if debian/upstream is a dir or a file but I think
> you want it to only match on files and maybe symlinks?

The part I think you're referring to is the handling of svn
repositories, in which case the existence check is for an exported file
named either upstream (for debian/upstream) or metadata (for
debian/upstream/metadata).  There's a call to "svn ls" a few lines
earlier that determines which actually exists.

I did notice something else in looking over the patch and will follow up
with that to the bug.

> There are other issues with uscan/DEP-12;
> 
> debian/watch is duplicated in the Watch field in DEP-12 debian/upstream.

Partially.  DEP-12 assumes it to be a version=3 format line and only
supports a single line.

> umegaya doesn't support packages where there is no VCS. Not sure if
> the blends site has the same issue?

As far as I know, both are specifically intended to collect data only
from a VCS, yes.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Charles Plessy]

Le Fri, Feb 07, 2014 at 12:41:51AM -0500, James McCoy a écrit :
> On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote:
> 
> > There are other issues with uscan/DEP-12;
> > 
> > debian/watch is duplicated in the Watch field in DEP-12 debian/upstream.
> 
> Partially.  DEP-12 assumes it to be a version=3 format line and only
> supports a single line.

Hello everbody,

I regret all the confusion that I created, in this thread and in the Debian Med
team, by storing a copy of the watch file in the debian/upstream files in the
packages that I maintain.

I did that for fun and did not intend to suggest that there was any support on 
any
plan in the short/mid term to superseed the debian/watch file.

Please just ignore this field.  I do not intend at all to make it part of DEP
12 (which will be updated after I repair the DEP website, that is still broken
after the last reform of Alioth).

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207055427.gb2...@falafel.plessy.net