Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Martín Ferrari]

On 09/07/15 02:19, Guillem Jover wrote:

>>  Most programs that are designed to be run as daemons do that work for
>>  themselves. However, you’ll occasionally run across one that does not. When
>>  you must run a daemon program that does not properly make itself into a true
>>  Unix daemon, you can use daemonize to force it to run as a true daemon.
> 
> Does this have any advantage over start-stop-daemon?

I can say that it does: start-stop-daemon misses some functionality you
need for programs that don't daemonise and log to stdout/stderr, which
is something I needed only last week. Having said that, I think that
'daemon' does everything that 'daemonize' does and more.


-- 
Martín Ferrari (Tincho)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559e75eb.2060...@tincho.org

Packaging certain libraries as "end-user software"

[Ansgar Burchardt]

Hi,

I'm wondering about the shared library packaging requirements in Policy
for the special case of scientific libraries that are not intended to be
used by applications, but are to be used by end-users directly, and that
do not have a stable ABI.

In particular does splitting out the shared library package provide
anything useful here? It means additional work for no benefit I can see
as parallel installation of multiple versions would require having
multiple -dev packages as well to be useful...

I'm considering to move the shared libraries into the -dev package, have
lib*-dev Provides: lib*-x.y.z and shlibs generate dependencies on the
provided virtual package. While no applications depend on the shared
libraries, the virtual packages are needed as the entire framework is
split over multiple source packages providing shared libraries with
dependencies between them. I'm thinking of dune-* / libdune-*-dev here,
but the same probably applies to other packages like deal.ii as well.

Does anyone see any problems with this plan?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559e92a8.9080...@debian.org

Re: Packaging certain libraries as "end-user software"

[Bas Wijnen]

Hi,

On Thu, Jul 09, 2015 at 05:26:32PM +0200, Ansgar Burchardt wrote:
> I'm wondering about the shared library packaging requirements in Policy
> for the special case of scientific libraries that are not intended to be
> used by applications, but are to be used by end-users directly,

What does "to be used by end users directly" mean?  That they will use them to
compile programs?  That's not special.  Because they are used for compiling,
most shared libraries are Build-Depends of other packges, but that's not the
only reason they exist.  All libraries are available for developer end users.

> and that do not have a stable ABI.

That is an issue.  It means that upstream will either need to change the soname
a lot, which is probably not what they do, or that it shouldn't be a shared
library (but a static library instead).

> In particular does splitting out the shared library package provide
> anything useful here? It means additional work for no benefit I can see
> as parallel installation of multiple versions would require having
> multiple -dev packages as well to be useful...

The benefit of changing the soname and package name of a shared library is not
that multiple versions can be used for development, but rather that programs
compiled against an incompatible old version will still work when the new
version is installed.  This is because the old version is not uninstalled from
the system (even if it may be removed from the archive after the dependency is
upgraded there; the old application still links to the old library, which will
remain installed on the user's machine at least until that application is
upgraded or removed).

This is true regardless of whether the application is provided by Debian or
not.  (But if it isn't, it is technically easy to remove the old library and
break the application; the user must take care not to do that.)

> Does anyone see any problems with this plan?

Yes.  The way we handle shared libraries for Debian packages works also for
programs that aren't in Debian.  Your proposal makes it harder for users to
keep their programs running when the library is upgraded (they are forced to
recompile).

Also, to repeat: if the ABI is very unstable, the library should probably not
be distributed as a shared library, but only as a static library.  Then all
those problems don't exist (but you're also missing some benefits, which is why
most libraries should better be shared, with the static version only installed
for special cases).

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150709163908.gd8...@fmf.nl

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Marco d'Itri]

On Jul 09, Martín Ferrari  wrote:

> I can say that it does: start-stop-daemon misses some functionality you
> need for programs that don't daemonise and log to stdout/stderr, which
> is something I needed only last week. Having said that, I think that
This looks like a job for systemd.

-- 
ciao,
Marco


pgptj83U7YFVx.pgp
Description: PGP signature

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Clint Byrum]

Excerpts from md's message of 2015-07-09 10:18:50 -0700:
> On Jul 09, Martín Ferrari  wrote:
> 
> > I can say that it does: start-stop-daemon misses some functionality you
> > need for programs that don't daemonise and log to stdout/stderr, which
> > is something I needed only last week. Having said that, I think that
> This looks like a job for systemd.
> 

Yes, all problems are just nails for that hammer!


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

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Matthias Klumpp]

2015-07-09 19:25 GMT+02:00 Clint Byrum :
> Excerpts from md's message of 2015-07-09 10:18:50 -0700:
>> On Jul 09, Martín Ferrari  wrote:
>>
>> > I can say that it does: start-stop-daemon misses some functionality you
>> > need for programs that don't daemonise and log to stdout/stderr, which
>> > is something I needed only last week. Having said that, I think that
>> This looks like a job for systemd.
>>
>
> Yes, all problems are just nails for that hammer!

Systemd does starting/stopping and managing services very well.
The tool you want to use in this case is systemd-run, which starts a
transient service for the command you want to run in the background.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caknhny8fd4hbr76bfw2yxq+hkxp69v5fydwweb7bxdzybds...@mail.gmail.com

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Michael Lustfield]

>>> > I can say that it does: start-stop-daemon misses some functionality you
>>> > need for programs that don't daemonise and log to stdout/stderr, which
>>> > is something I needed only last week. Having said that, I think that
>>> This looks like a job for systemd.
>>>
>>
>> Yes, all problems are just nails for that hammer!
>
> Systemd does starting/stopping and managing services very well.
> The tool you want to use in this case is systemd-run, which starts a
> transient service for the command you want to run in the background.
> Cheers,
> Matthias

Of course, we shouldn't expect everyone to use systemd-run because
that's locking into an init system which should quite obviously be
avoided.

It does seem like daemonize serves a very unique purpose where
start-stop-daemon is a bit overkill or cumbersome. It's obviously
something that would never be used in an init script where
start-stop-daemon is actually appropriate. However, I can see a few
situations where I would launch this from a script. Not only that...
but I can see myself rewriting some scripts to make use of this if it
were included in Debian.

Just my two cents.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAL4L7=AtLW0RfiM0-v0Y=bpwsa9om3ky0epo4d-_qwyptiz...@mail.gmail.com

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Marc Haber]

On Thu, 9 Jul 2015 19:18:50 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Jul 09, Martín Ferrari  wrote:
>> I can say that it does: start-stop-daemon misses some functionality you
>> need for programs that don't daemonise and log to stdout/stderr, which
>> is something I needed only last week. Having said that, I think that
>This looks like a job for systemd.

How do I have that functionality on Debian/kFreeBSD?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zdi7l-0007rg...@swivel.zugschlus.de

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Konstantin Khomoutov]

On Thu, 9 Jul 2015 13:10:35 -0500
Michael Lustfield  wrote:

[...]
> Of course, we shouldn't expect everyone to use systemd-run because
> that's locking into an init system which should quite obviously be
> avoided.

That, again.

The person who suggested using systemd merely pointed out that the task
of turning a regular process into daemon is trivially solvable using
systemd-run.  This kind of implies that if the OP uses systemd, they
could just read the appropriate manual page and have their task solved.

> It does seem like daemonize serves a very unique purpose where
> start-stop-daemon is a bit overkill or cumbersome. It's obviously
> something that would never be used in an init script where
> start-stop-daemon is actually appropriate. However, I can see a few
> situations where I would launch this from a script. Not only that...
> but I can see myself rewriting some scripts to make use of this if it
> were included in Debian.

Two points:

* It seems you have missed a message in this thread mentioning the
  `daemon` package which is in Debian (since ages) and is able to
  daemonize a regular program.

* Not to bash the maintainers of `start-stop-daemon` but this program
  is sort of a hack as it can't do most of what's expected from a
  daemonizer: it can't capture the standard output streams of the
  child it spawns and redirect them to syslog, and it can't restart the
  child when that dies.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150709232321.ebd0334a53d541327ca5d...@domain007.com

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Michael Lustfield]

>> Of course, we shouldn't expect everyone to use systemd-run because
>> that's locking into an init system which should quite obviously be
>> avoided.
>
> That, again.
>
> The person who suggested using systemd merely pointed out that the task
> of turning a regular process into daemon is trivially solvable using
> systemd-run.  This kind of implies that if the OP uses systemd, they
> could just read the appropriate manual page and have their task solved.

When I read it, it came across a bit different from that. It sounded
like that was to be considered "the" approach instead of one option.
Related to a bit further down...

>> It does seem like daemonize serves a very unique purpose where
>> start-stop-daemon is a bit overkill or cumbersome. It's obviously
>> something that would never be used in an init script where
>> start-stop-daemon is actually appropriate. However, I can see a few
>> situations where I would launch this from a script. Not only that...
>> but I can see myself rewriting some scripts to make use of this if it
>> were included in Debian.
>
> Two points:
>
> * It seems you have missed a message in this thread mentioning the
>   `daemon` package which is in Debian (since ages) and is able to
>   daemonize a regular program.

You're right. I missed (spaced on) that note. Which helped contribute
to my feelings above. I guess my argument is invalid. I'm sorry for
the noise then!

> * Not to bash the maintainers of `start-stop-daemon` but this program
>   is sort of a hack as it can't do most of what's expected from a
>   daemonizer: it can't capture the standard output streams of the
>   child it spawns and redirect them to syslog, and it can't restart the
>   child when that dies.

It can be a pain in the bum, but does (mostly) work... I need to start
playing with daemon!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAL4L7=d7dpzvsfixytjkkammqqgaqgwuma7a0axylkmhyx-...@mail.gmail.com

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Russ Allbery]

Marc Haber  writes:
> On Thu, 9 Jul 2015 19:18:50 +0200, m...@linux.it (Marco d'Itri) wrote:
>> On Jul 09, Martín Ferrari  wrote:

>>> I can say that it does: start-stop-daemon misses some functionality you
>>> need for programs that don't daemonise and log to stdout/stderr, which
>>> is something I needed only last week. Having said that, I think that

>> This looks like a job for systemd.

> How do I have that functionality on Debian/kFreeBSD?

runit, daemontools, supervisor, launchtool... reinventing this wheel is so
popular that you can find a wealth of different styles of tread.  It looks
like you maintain daemon, in fact.  :)

This is a little like uploading yet another MTA.  People are reasonably
asking "do we need *another* one?"

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fq8ongg@hope.eyrie.org

Work-needing packages report for Jul 10, 2015

[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: 673 (new: 6)
Total number of packages offered up for adoption: 176 (new: 0)
Total number of packages requested help for: 50 (new: 0)

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



The following packages have been orphaned:

   alien (#791522), orphaned 4 days ago
 Description: convert and install rpm and other packages
 Reverse Depends: lsb-core
 Installations reported by Popcon: 12109

   apt-p2p (#791801), orphaned yesterday
 Description: apt helper for peer-to-peer downloads of Debian
   packages
 Installations reported by Popcon: 69

   glances (#791432), orphaned 5 days ago
 Description: CLI curses based monitoring tool
 Installations reported by Popcon: 374

   liboggplay (#791527), orphaned 4 days ago
 Description: A library for playing OGG multimedia
 Reverse Depends: liboggplay1-dbg liboggplay1-dev
 Installations reported by Popcon: 22

   link-grammar (#791528), orphaned 4 days ago
 Description: Carnegie Mellon University's link grammar parser
 Reverse Depends: abiword-plugin-grammar liblink-grammar4
   liblink-grammar4-dev liblink-grammar4-java link-grammar
 Installations reported by Popcon: 5157

   ppl (#791996), orphaned today
 Description: Parma Polyhedra Library
 Reverse Depends: cloog-ppl libapron libapron-dev libcloog-ppl-dev
   libcloog-ppl1 libppl-c4 libppl-dev libppl-swi ppl-dev
 Installations reported by Popcon: 4774

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



No new packages have been given up for adoption, but a total of 176 packages
are awaiting adoption.  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 1984 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay muon muon-discover packagesearch
 Installations reported by Popcon: 44356

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

   awstats (#755797), requested 351 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 3749

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

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

   cups (#532097), requested 2224 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cinnamon-settings-daemon
   cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client
   cups-core-drivers (66 more omitted)
 Installations reported by Popcon: 113978

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

   developers-reference (#759995), requested 313 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 12039

   ejabberd (#767874), requested 248 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib
 Installations reported by Popcon: 643

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

   freeipmi (#628062), requested 1505 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev
   libfreeipmi16 libipmiconsole-dev libipmiconsole2 (5 more omitted)
 Installations reported by Popcon: 4999

   gnat-gps (#496905), requested 2506 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 434

   gnokii (#677750), requested 1118 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 1163

   gridengine (

YAGF is a seriously screwed package

[Susmita/Rajib Bandopadhyay]

Dear Sirs,

I need this software desperately to be finally free from the
strangle-hold of proprietary, closed-source software developers.

But I am shocked to find this software being ported into stable
packages, while it can do nothing. As soon as it is tried it shuts
itself off.

I hope the package will be salvaged by a nearest posssible date.

Regards,
Rajib Bandopadhyay


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caeg4czu4ocj0hhdecrn3kwwvd_x_co_iif6vxzqrncpu14p...@mail.gmail.com

Re: YAGF is a seriously screwed package

[Paul Wise]

On Fri, Jul 10, 2015 at 11:57 AM, Susmita/Rajib Bandopadhyay wrote:

> But I am shocked to find this software being ported into stable
> packages, while it can do nothing. As soon as it is tried it shuts
> itself off.

The correct way to file a bug report is listed here:

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

https://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: 
https://lists.debian.org/caktje6hkrfxl-c4zpggz9xk+sgmurep4ruabudsqo-+oucd...@mail.gmail.com