Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 16:32, Tollef Fog Heen wrote:
> ]] Dmitrijs Ledkovs
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>
> Why the -L ?
>
! -L = not a symlink, upstart jobs cannot be symlinks. Above is a
very basic sanity check.
I haven't checked, but if above is implemented, the logic of checking
"equivalent upstart job is available" should match the one already
implemented in the update-rc.d / incoke-rc.d / service commands.
So consider above more of a working proof of concept, rather than
final code proposal.
Regards,
Dmitrijs.
--
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/CANBHLUgc0mNkGRej0w+ECmwrh-RfDw+eV=x=jrhdddox2bu...@mail.gmail.com
Work-needing packages report for Jun 21, 2013
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: 480 (new: 0) Total number of packages offered up for adoption: 153 (new: 1) Total number of packages requested help for: 60 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 480 packages are orphaned. See http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: olive (#712937), offered today Installations reported by Popcon: 56 152 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 1235 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 75694 asymptote (#517342), requested 1574 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 4553 athcool (#278442), requested 3159 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 61 balsa (#642906), requested 634 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 1202 bastille (#592137), requested 1048 days ago Description: Security hardening tool Installations reported by Popcon: 152 cardstories (#624100), requested 787 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 12 chromium-browser (#583826), requested 1117 days ago Description: Chromium browser Reverse Depends: chromium chromium-browser chromium-browser-dbg chromium-browser-inspector chromium-browser-l10n chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 17269 cups (#532097), requested 1475 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-daemon cups-dbg cups-filters (58 more omitted) Installations reported by Popcon: 122739 debtags (#567954), requested 1235 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2476 fbcat (#565156), requested 1254 days ago Description: framebuffer grabber Installations reported by Popcon: 151 flightgear (#487388), requested 1825 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 586 freeipmi (#628062), requested 756 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev libipmiconsole2 libipmidetect-dev libipmidetect0 (2 more omitted) Installations reported by Popcon: 2914 gnat-4.4 (#539633), requested 1892 days ago Description: backport bug fixes from trunk (GCC 4.5) Reverse Depends: ghdl gnat-4.4 libgnat-4.4 libgnat-4.4-dbg libgnatprj-dev libgnatprj4.4 libgnatprj4.4-dbg libgnatprj4.4-dev libgnatvsn-dev libgnatvsn4.4 (2 more omitted) Installations reported by Popcon: 1833 gnat-gps (#496905), requested 1757 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 501 gnokii (#677750), requested 369 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: 2048 gnupg (#660685), requested 486 days ago Description: GNU privacy guard - a free PGP replacement Reverse Depends: apt bootstrap-base cdebootstrap cdebootstrap-static cdebootstrap-udeb clamav-unofficial-sigs cloud-utils debian-archive-keyring debian-edu-archive-keyring debian-ports-archive-keyring (48 more omitted) Installations reported by Popcon: 151794 gpa (#663405), requested 467 days ago Description: GNU Privacy Assistant (GPA) Installations reported by Popcon: 657 gradle (#683666), requested 322 days ago Description: Groovy based build system Reverse Depen
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 18:26, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
>> Thus in a bug report 712763 [4], included below, I instead propose
>> instead shipping slightly larger block of code in the upstart package
>> which is sourced by /lib/lsb/init-functions from init-functions.d
>> directory. Something along the lines of:
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> case "${1:-}" in
>> start|restart|force-reload)
>> exit 1
>> ;;
>> stop)
>> exit 0
>> ;;
>> esac
>> fi
>> fi
>
> Libraries, even shell libraries, should generally not call exit. It's
> very surprising behavior. The overall program flow should remain under
> the control of the main program.
In general I agree, and I think this was one of points of including
helper-free check in the policy & including a helper in the
init-functions, which one can call as appropriate.
Another fundamental question is: should direct invocation of
/etc/init.d/ be outright deprecated? and thus even stronger
safe-guards put in place (e.g. something at the scale of chmod -x
/etc/init.d/*)
or shall we allow people shooting themselves in the foot and allow
init.d scripts not to have upstart-safeguard if a maintainer does not
wish to include one? E.g. update-rc.d / incoke-rc.d
/ service works correctly with sysv-init & upstart, but if one invokes
init.d scripts directly and they happen to be managed by upstart,
leave those users on their own? At the moment policy is a must: "SysV
init scripts for which an equivalent upstart job is available __must__
query the output of the..."
Regards,
Dmitrijs.
--
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/CANBHLUgzgF+YvnsZXxv4hYvEx-jm4M_p=kTZv=yaqjuuq18...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
> On 20 June 2013 18:26, Russ Allbery wrote:
> > Dmitrijs Ledkovs writes:
> >
> >> Thus in a bug report 712763 [4], included below, I instead propose
> >> instead shipping slightly larger block of code in the upstart package
> >> which is sourced by /lib/lsb/init-functions from init-functions.d
> >> directory. Something along the lines of:
> >
> >> if init_is_upstart; then
> >> upstart_job=/etc/init/$(basename ${0:-}).conf
> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
> >> case "${1:-}" in
> >> start|restart|force-reload)
> >> exit 1
> >> ;;
> >> stop)
> >> exit 0
> >> ;;
> >> esac
> >> fi
> >> fi
> >
> > Libraries, even shell libraries, should generally not call exit. It's
> > very surprising behavior. The overall program flow should remain under
> > the control of the main program.
>
> In general I agree, and I think this was one of points of including
> helper-free check in the policy & including a helper in the
> init-functions, which one can call as appropriate.
>
> Another fundamental question is: should direct invocation of
> /etc/init.d/ be outright deprecated? and thus even stronger
> safe-guards put in place (e.g. something at the scale of chmod -x
> /etc/init.d/*)
> or shall we allow people shooting themselves in the foot and allow
> init.d scripts not to have upstart-safeguard if a maintainer does not
> wish to include one? E.g. update-rc.d / incoke-rc.d
> / service works correctly with sysv-init & upstart, but if one invokes
> init.d scripts directly and they happen to be managed by upstart,
> leave those users on their own? At the moment policy is a must: "SysV
> init scripts for which an equivalent upstart job is available __must__
> query the output of the..."
I think printing out a noisy warning and allowing people to shoot themselves in
the foot would be good. I reckon a significant number of legacy
(custom/proprietary) scripts currently attempt to poke /etc/init.d/foo directly.
Perhaps allowing the sysadmin to choose the desired behaviour via debconf would
do..
One point of concern that just occurred to me is that on an Upstart-booted,
running system that was just upgraded to include this init-functions snippet,
Upstart wouldn't know about init.d-started services, and wouldn't be able to
stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
wouldn't be able to stop the process using the traditional sysvinit script
either. You'd end up needing to kill the service manually or trawl through the
init script to figure out how to kill it properly.
--
Kind regards,
Loong Jin
signature.asc
Description: Digital signature
Bug#712972: ITP: mp4parser -- Generic parser and writer for ISO 14496 based files
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: mp4parser Version : 1.0-RC-23 Upstream Author : Sebastian Annies * URL : http://code.google.com/p/mp4parser/ * License : Apache-2.0 Programming Lang: Java Description : Generic parser and writer for ISO 14496 based files The MP4 Parser project consists in: * ISO Parser, an API for reading and writing the MP4 file structure. It is a low level tool dealing with the so called boxes but it is as well as dealing with structure like tracks and movies. * ISO Viewer, a Swing application that helps you to visualize the MP4 box structure. -- 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/20130621103710.9248.39099.reportbug@debiandev
Re: ITP: ruby-em-hiredis -- fast and simple Redis client for EventMachine
On Fri, Jun 21, 2013 at 7:32 AM, Faidon Liambotis wrote: > On 06/21/13 02:59, Per Andersson wrote: >> >> Package: wnpp > > > Please use X-Debbugs-Cc when filing ITP bugs (or reportbug, which does this > automatically). Do not Cc debian-devel directly, as it's impossible for > someone to properly reply to your bug report without looking its bug number > up on the WNPP bug index. Sure, thanks for the tip. > Also, the whole point of Cc'ing ITPs to debian-devel is for people to get a > chance to make notes/raise questions/object, so you should wait a day or two > before uploading, not upload within three hours or so. Reasonable of course. > Finally, like any bug > report, when someone does take the time to make a comment on an ITP of > yours, it is customary to at least reply to them addressing or rejecting > their concerns :) Absolutely. Something in particular that you have in mind? Thanks for taking the time to enlighten me! Best, Per > Cheers, > Faidon -- 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/cabyrxsqnjooiyj07xzkj4xibpmy43o10u62soh8futunk-2...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 11:24, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> On 20 June 2013 18:26, Russ Allbery wrote:
>> > Dmitrijs Ledkovs writes:
>> >
>> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> instead shipping slightly larger block of code in the upstart package
>> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> directory. Something along the lines of:
>> >
>> >> if init_is_upstart; then
>> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> case "${1:-}" in
>> >> start|restart|force-reload)
>> >> exit 1
>> >> ;;
>> >> stop)
>> >> exit 0
>> >> ;;
>> >> esac
>> >> fi
>> >> fi
>> >
>> > Libraries, even shell libraries, should generally not call exit. It's
>> > very surprising behavior. The overall program flow should remain under
>> > the control of the main program.
>>
>> In general I agree, and I think this was one of points of including
>> helper-free check in the policy & including a helper in the
>> init-functions, which one can call as appropriate.
>>
>> Another fundamental question is: should direct invocation of
>> /etc/init.d/ be outright deprecated? and thus even stronger
>> safe-guards put in place (e.g. something at the scale of chmod -x
>> /etc/init.d/*)
>> or shall we allow people shooting themselves in the foot and allow
>> init.d scripts not to have upstart-safeguard if a maintainer does not
>> wish to include one? E.g. update-rc.d / incoke-rc.d
>> / service works correctly with sysv-init & upstart, but if one invokes
>> init.d scripts directly and they happen to be managed by upstart,
>> leave those users on their own? At the moment policy is a must: "SysV
>> init scripts for which an equivalent upstart job is available __must__
>> query the output of the..."
>
> I think printing out a noisy warning and allowing people to shoot themselves
> in
> the foot would be good. I reckon a significant number of legacy
> (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
> directly.
> Perhaps allowing the sysadmin to choose the desired behaviour via debconf
> would
> do..
>
I'm not sure I understand you.
> One point of concern that just occurred to me is that on an Upstart-booted,
> running system that was just upgraded to include this init-functions snippet,
> Upstart wouldn't know about init.d-started services, and wouldn't be able to
> stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
> wouldn't be able to stop the process using the traditional sysvinit script
> either. You'd end up needing to kill the service manually or trawl through the
> init script to figure out how to kill it properly.
>
Only if both are present:
/etc/init/myservice.conf
/etc/init.d/myservice
The /etc/init.d/myservice, should exit/do nothing if and only if PID1
is upstart, since upstart is managing myservice via a native upstart
job.
If there is no equivalent upstart job (as I think is the case in your
example above), the init.d script must continue to function correctly
as per debian policy (including start/stop/restart).
Thus the init-functions.d snippet above does a check of if upstart is
PID1 and the '/etc/init/myservice.conf' exists, and only then adds the
appropriate exit 1/0. And in the case of upstart-booted system it will
indeed be managing "myservice".
Are you talking about a case where a package is upgraded from
sysv-init.d only to an upstart&sysv-init.d capable version? As per
current recommendations, such services are stopped in preinst (cleanly
via init.d script) & started in postinst (potentially by upstart). [1]
Maybe I didn't understand the scenario you described. Can you please elaborate?
[1] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
--
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/canbhlugvkssirjxadahg+bgycgtz1berqstyeyqkpyiub+m...@mail.gmail.com
Re: ITP: foreman -- manage Procfile-based applications
On Mon, Jun 10, 2013 at 3:48 AM, Faidon Liambotis wrote: > On 06/10/13 03:46, Per Andersson wrote: >> >> * Package name: foreman >>Version : 0.63.0 >>Upstream Author : David Dollar >> * URL : http://github.com/ddollar/foreman >> * License : MIT >>Programming Lang: Ruby >>Description : manage Procfile-based applications >> >> Foreman is a manager for Procfile-based applications. Its aim is to >> abstract >> away the details of the Procfile format, and allow you to either run >> your >> application directly or export it to some other process management >> format. > > > There's a more popular/more complicated piece of software called Foreman[1], > for which there's an RFP already[2], as well as a component of that, > foremancli, already in Debian. Upstream provides a package too, although you > could argue it isn't our problem if there's a naming conflict. I saw this but decided to ignore it for now since there hasn't been any activity with Foreman in over a year. If the name conflict arise in Debian it is a pretty small matter to change it then I think. I.e. Foreman[1] renaming to theforeman as the upstream web page or this foreman renaming to ruby-foreman or some such, it is not a big thing IMHO. > Nevertheless, I think it'd be best to avoid a package naming conflict > between the two apparently completely unrelated applications. I agree. > Oh, and BTW, you should probably explain what a Procfile is on the long > description of your package as it's not immediately obvious. I will add this. Thanks for taking the time to make Debian better! Best, Per > Regards, > Faidon > > 1: http://www.theforeman.org/ > 2: http://bugs.debian.org/663101 -- 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/CABYrXSQQ6cggW9qf+JtxvVFU=z3dkk6+oiwmjbi9r3wwzht...@mail.gmail.com
Re: Bug#712908: ITP: stencil-clojure -- implementation of the Mustache template system for Clojure
On Thu, Jun 20, 2013 at 20:09 +0200, Eugenio Cano-Manuel Mendoza wrote: > Package: wnpp > Severity: wishlist > Owner: "Eugenio Cano-Manuel Mendoza" > > * Package name: stencil-clojure > Version : 0.3.2 > Upstream Author : David Santiago > * URL : https://github.com/davidsantiago/stencil > * License : EPL-1 > Programming Lang: Clojure, Java > Description : implementation of the Mustache template system for Clojure > > Stencil is a Clojure implementation of Mustache, a template system. > Mustache lacks of control flow statements such as if/else conditionals > or for loops; it instead features section tag processing lists and > lambdas. Mustache also enforces a strong separation of logic from > presentation. Thanks for working on this, but the description could certainly be improved. The first step would be something like: --- Description : implementation of mustache templates for Clojure . Stencil is a Clojure implementation of Mustache, a template system. Mustache lacks any explicit control flow statements such as if/else conditionals or for loops, but instead features section tag processing lists and lambdas. Mustache also enforces a strong separation of logic from presentation. --- But I am not too happy about the "section tag processing lists lambdas. Can't think of anything better right now, but lets find something that makes the design decisions behind mustache and why one would want to use it a bit clearer. A good idea is probably to look into the other mustache libraries (ruby-mustache, libjs-mustache, node-mustache) for inspiration. -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On Fri, Jun 21, 2013 at 11:52:40AM +0100, Dmitrijs Ledkovs wrote:
> On 21 June 2013 11:24, Chow Loong Jin wrote:
> > On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
> >> On 20 June 2013 18:26, Russ Allbery wrote:
> >> > Dmitrijs Ledkovs writes:
> >> >
> >> >> Thus in a bug report 712763 [4], included below, I instead propose
> >> >> instead shipping slightly larger block of code in the upstart package
> >> >> which is sourced by /lib/lsb/init-functions from init-functions.d
> >> >> directory. Something along the lines of:
> >> >
> >> >> if init_is_upstart; then
> >> >> upstart_job=/etc/init/$(basename ${0:-}).conf
> >> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
> >> >> case "${1:-}" in
> >> >> start|restart|force-reload)
> >> >> exit 1
> >> >> ;;
> >> >> stop)
> >> >> exit 0
> >> >> ;;
> >> >> esac
> >> >> fi
> >> >> fi
> >> >
> >> > Libraries, even shell libraries, should generally not call exit. It's
> >> > very surprising behavior. The overall program flow should remain under
> >> > the control of the main program.
> >>
> >> In general I agree, and I think this was one of points of including
> >> helper-free check in the policy & including a helper in the
> >> init-functions, which one can call as appropriate.
> >>
> >> Another fundamental question is: should direct invocation of
> >> /etc/init.d/ be outright deprecated? and thus even stronger
> >> safe-guards put in place (e.g. something at the scale of chmod -x
> >> /etc/init.d/*)
> >> or shall we allow people shooting themselves in the foot and allow
> >> init.d scripts not to have upstart-safeguard if a maintainer does not
> >> wish to include one? E.g. update-rc.d / incoke-rc.d
> >> / service works correctly with sysv-init & upstart, but if one invokes
> >> init.d scripts directly and they happen to be managed by upstart,
> >> leave those users on their own? At the moment policy is a must: "SysV
> >> init scripts for which an equivalent upstart job is available __must__
> >> query the output of the..."
> >
> > I think printing out a noisy warning and allowing people to shoot
> > themselves in
> > the foot would be good. I reckon a significant number of legacy
> > (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
> > directly.
> > Perhaps allowing the sysadmin to choose the desired behaviour via debconf
> > would
> > do..
> >
>
> I'm not sure I understand you.
I'm saying that some people may have custom scripts, cronjobs or whatnot calling
/etc/init.d/ directly, and may not be very pleased about /etc/init.d/ scripts
losing their +x permissions and breaking these scripts.
Hence, rather than completely disabling the init.d scripts, I'd rather that
invoking an init.d script directly prints out a big fat warning on stderr that
lets the admin know, while still doing something sane (starting the service
anyway). Kinda like how Ubuntu's sysvinit.d scripts currently operate right now.
> > One point of concern that just occurred to me is that on an Upstart-booted,
> > running system that was just upgraded to include this init-functions
> > snippet,
> > Upstart wouldn't know about init.d-started services, and wouldn't be able to
> > stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ],
> > you
> > wouldn't be able to stop the process using the traditional sysvinit script
> > either. You'd end up needing to kill the service manually or trawl through
> > the
> > init script to figure out how to kill it properly.
> >
>
> [...]
>
> Are you talking about a case where a package is upgraded from
> sysv-init.d only to an upstart&sysv-init.d capable version? As per
> current recommendations, such services are stopped in preinst (cleanly
> via init.d script) & started in postinst (potentially by upstart).
No, I'm talking about upgrading an upstart installation that doesn't have that
init-functions snippet in place, to one that does. Are you going to bring down
all sysvinit-started processes when that happens, so that Upstart can track
them?
--
Kind regards,
Loong Jin
signature.asc
Description: Digital signature
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 15:05, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 11:52:40AM +0100, Dmitrijs Ledkovs wrote:
>> On 21 June 2013 11:24, Chow Loong Jin wrote:
>> > On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> >> On 20 June 2013 18:26, Russ Allbery wrote:
>> >> > Dmitrijs Ledkovs writes:
>> >> >
>> >> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> >> instead shipping slightly larger block of code in the upstart package
>> >> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> >> directory. Something along the lines of:
>> >> >
>> >> >> if init_is_upstart; then
>> >> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> >> case "${1:-}" in
>> >> >> start|restart|force-reload)
>> >> >> exit 1
>> >> >> ;;
>> >> >> stop)
>> >> >> exit 0
>> >> >> ;;
>> >> >> esac
>> >> >> fi
>> >> >> fi
>> >> >
>> >> > Libraries, even shell libraries, should generally not call exit. It's
>> >> > very surprising behavior. The overall program flow should remain under
>> >> > the control of the main program.
>> >>
>> >> In general I agree, and I think this was one of points of including
>> >> helper-free check in the policy & including a helper in the
>> >> init-functions, which one can call as appropriate.
>> >>
>> >> Another fundamental question is: should direct invocation of
>> >> /etc/init.d/ be outright deprecated? and thus even stronger
>> >> safe-guards put in place (e.g. something at the scale of chmod -x
>> >> /etc/init.d/*)
>> >> or shall we allow people shooting themselves in the foot and allow
>> >> init.d scripts not to have upstart-safeguard if a maintainer does not
>> >> wish to include one? E.g. update-rc.d / incoke-rc.d
>> >> / service works correctly with sysv-init & upstart, but if one invokes
>> >> init.d scripts directly and they happen to be managed by upstart,
>> >> leave those users on their own? At the moment policy is a must: "SysV
>> >> init scripts for which an equivalent upstart job is available __must__
>> >> query the output of the..."
>> >
>> > I think printing out a noisy warning and allowing people to shoot
>> > themselves in
>> > the foot would be good. I reckon a significant number of legacy
>> > (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
>> > directly.
>> > Perhaps allowing the sysadmin to choose the desired behaviour via debconf
>> > would
>> > do..
>> >
>>
>> I'm not sure I understand you.
>
> I'm saying that some people may have custom scripts, cronjobs or whatnot
> calling
> /etc/init.d/ directly, and may not be very pleased about /etc/init.d/ scripts
> losing their +x permissions and breaking these scripts.
>
I see, ok.
> Hence, rather than completely disabling the init.d scripts, I'd rather that
> invoking an init.d script directly prints out a big fat warning on stderr that
> lets the admin know, while still doing something sane (starting the service
> anyway). Kinda like how Ubuntu's sysvinit.d scripts currently operate right
> now.
>
Unfortunately doing that is not possible, whilst also simultaneously
supporting sysvinit and upstart in the archive. Because as per policy
at the moment we must preserve fully working sysv init scripts.
>> > One point of concern that just occurred to me is that on an Upstart-booted,
>> > running system that was just upgraded to include this init-functions
>> > snippet,
>> > Upstart wouldn't know about init.d-started services, and wouldn't be able
>> > to
>> > stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ],
>> > you
>> > wouldn't be able to stop the process using the traditional sysvinit script
>> > either. You'd end up needing to kill the service manually or trawl through
>> > the
>> > init script to figure out how to kill it properly.
>> >
>>
>> [...]
>>
>> Are you talking about a case where a package is upgraded from
>> sysv-init.d only to an upstart&sysv-init.d capable version? As per
>> current recommendations, such services are stopped in preinst (cleanly
>> via init.d script) & started in postinst (potentially by upstart).
>
> No, I'm talking about upgrading an upstart installation that doesn't have that
> init-functions snippet in place, to one that does. Are you going to bring down
> all sysvinit-started processes when that happens, so that Upstart can track
> them?
>
I see now what your question is.
Upstart only supervises processes configured with native upstart jobs.
Thus one cannot use upstart to stop sysv init scripts, one should use
`service` command which can correctly stop init scripts and upstart
jobs alike.
>> > Upstart wouldn't know about init.d-started services, and wouldn't be able
>> > to
>> > stop them.
That's always true, upstart manages only natively configured jobs.
>>> Additionally, due to
Encrypted popcon submissions
Dear Debian people, I upload popularity-contest 1.58 which add support for encrypted submissions. For this release it is not activated by default. Please help test this feature by adding ENCRYPT="yes" to /etc/popularity-contest.conf to activate it. Once this feature has seen proper testing, we will activate it by default. There are two other features worthy of note in 1.58: * popularity-contest now report the dpkg Vendor field. This will allow to track submission by derivative distribution. * popularity-contest now trucate the reported atime and ctime to multiple of 12 hours to reduce information leak. Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: Digital signature
Re: Encrypted popcon submissions
Hi, Am 21.06.2013 17:08, schrieb Bill Allombert: > * popularity-contest now report the dpkg Vendor field. This will allow to > track submission by derivative distribution. Thanks for that, that sounds immensly useful. I hope popcon.d.o is updated to make use of that information. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#713019: ITP: aspectj-maven-plugin -- AspectJ compiler Maven Plugin
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: aspectj-maven-plugin Version : 1.4 Upstream Author : Kaare Nilsen * URL : http://mojo.codehaus.org/aspectj-maven-plugin * License : MIT Programming Lang: Java Description : AspectJ compiler Maven Plugin Handles AspectJ usage within Maven. Functionality provided is: weaving of aspects (or existing aspects from libraries) with the test and/or main classes, weaving of pre-existing jars and ajdoc reporting. -- 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/20130621213853.10767.60865.reportbug@debiandev
Re: Encrypted popcon submissions
* Bill Allombert , 2013-06-21, 17:08: I upload popularity-contest 1.58 which add support for encrypted submissions. Great news. :-) BTW, you probably want to pass --no-options to gpg. -- Jakub Wilk -- 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/20130621220128.ga1...@jwilk.net
Re: ITP: foreman -- manage Procfile-based applications
On 13249 March 1977, Per Andersson wrote: >> There's a more popular/more complicated piece of software called Foreman[1], >> for which there's an RFP already[2], as well as a component of that, >> foremancli, already in Debian. Upstream provides a package too, although you >> could argue it isn't our problem if there's a naming conflict. > I saw this but decided to ignore it for now since there hasn't been any > activity > with Foreman in over a year. If the name conflict arise in Debian it is a > pretty > small matter to change it then I think. I.e. Foreman[1] renaming to > theforeman as > the upstream web page or this foreman renaming to ruby-foreman or some such, > it is not a big thing IMHO. In Debian its actually a pretty big matter. The more so the longer the wrongly named package exists in Debian. So it is *much* preferred to not have it at all, if the conflict is known from the beginning. -- bye, Joerg -- 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/87sj0ahp3d@lennier.ganneff.de
Re: Encrypted popcon submissions
On Fri, Jun 21, 2013 at 11:08 PM, Bill Allombert wrote: > I upload popularity-contest 1.58 which add support for encrypted submissions. ... > Once this feature has seen proper testing, we will activate it by default. ... > * popularity-contest now report the dpkg Vendor field. This will allow to > track submission by derivative distribution. > > * popularity-contest now trucate the reported atime and ctime to multiple of > 12 hours to reduce information leak. I wonder if the release team would accept a backport of these features to popcon in stable/oldstable. GPG and time truncation are security enhancements and reporting the dpkg Vendor field is very useful and has no risks. Once GPG is tested, would you consider doing a stable/oldstable update before the next point release? -- 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/CAKTje6GHAovgiA=hkskpm5d+nmc08qfcbf5ik4nnls4sa4r...@mail.gmail.com
Re: [Popcon-developers] Encrypted popcon submissions
[Paul Wise] > I wonder if the release team would accept a backport of these > features to popcon in stable/oldstable. GPG and time truncation are > security enhancements and reporting the dpkg Vendor field is very > useful and has no risks. Once GPG is tested, would you consider > doing a stable/oldstable update before the next point release? I suspect the new encryption feature would break popcon.skolelinux.org, as we have not investigated the new feature and use popularity-contest directly from Debian. Our collector would start getting encrypted submissions and lack the key to decrypt them. For Jessie, I hope we have time to figure out a solution, but for Wheezy we are not going to rewrite that part of our system. -- Happy hacking Petter Reinholdtsen One of the Debian Edu developers -- 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/20130622040019.ge28...@ulrik.uio.no
Re: [Popcon-developers] Encrypted popcon submissions
On Sat, Jun 22, 2013 at 12:00 PM, Petter Reinholdtsen wrote: > I suspect the new encryption feature would break > popcon.skolelinux.org, as we have not investigated the new feature and > use popularity-contest directly from Debian. Our collector would > start getting encrypted submissions and lack the key to decrypt them. This could be solved by having a mapping between encryption keys and URLs. A mechanism that would allow derivatives to just drop some files/dirs into their base-files package would probably be the easiest. Also you could just have popcon in DebianEdu submit only to the Debian popcon site, IIRC DebianEdu sets the dpkg vendor field to something other than Debian? > For Jessie, I hope we have time to figure out a solution, but for > Wheezy we are not going to rewrite that part of our system. Fair enough. -- 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/CAKTje6HfTEs4_=-ymezgj0yuz+fswvk_1oadwpn98wxb7bm...@mail.gmail.com
Re: [Popcon-developers] Encrypted popcon submissions
[Paul Wise] > This could be solved by having a mapping between encryption keys and > URLs. A mechanism that would allow derivatives to just drop some > files/dirs into their base-files package would probably be the > easiest. I suspect the easiest way would be to allow more than one GPG key to be used when encrypting, and finding the keys in a .d directory. > Also you could just have popcon in DebianEdu submit only to the > Debian popcon site, IIRC DebianEdu sets the dpkg vendor field to > something other than Debian? Debian Edu do not set the dpkg vendor field in Wheezy and earlier. I created http://bugs.debian.org/712996 > to track its inclusion yesterday. -- 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/20130622043814.gf28...@ulrik.uio.no
