 seems there is no way to avoid the debhelper usage.
[00:41] <mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
[00:41] <mbiebl> not an upstart issue per se, as Keybuk already told you
[05:55] <djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit -> disagree
[05:55] <djszapi> better to avoud the cdbs usage. I will not develop a software because of a one time usage...
[05:55] <mbiebl> got nothing to do with cdbs
[05:56] <djszapi> but yeah...I know the developers like forcing others to contribute. However it will not happen this time :)
[05:56] <mbiebl> and nobody forces you
[05:56] <djszapi> you indeed do
[05:56] <mbiebl> no
[05:57] <djszapi> more people told more times, I should use debhelper, but you still keep repeating I should patch cdbs. Meanwhile I told /quite many times/ I will /not/. period.
[05:57] <mbiebl> repeating to patch cdbs? You are confused
[05:59] <djszapi> oh well
[05:59] <djszapi> sorry, I will not patch cdbs, I will just use the debhelper.
[06:00] <mbiebl> wtf
[06:00] <mbiebl> I never said you should patch cdbs
[06:00] <mbiebl> where the hell did you read that non-sense
[06:00] <djszapi> not because of I am not involved in opensource leisure time and fulltime project, but I like working efficiently.
[06:00] <djszapi> and this is not my current interest
[06:00] <djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
[06:01] <djszapi> no, indeed no.
[06:01] <mbiebl> so?
[06:01] <djszapi> 08:00 < djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
[06:01] <djszapi> 07:59 < djszapi> sorry, I will not patch cdbs, I will just use the debhelper.
[06:01] <mbiebl> djszapi: sorry Id did not repeat that
[06:01] <mbiebl> and dh_installinit != cdbs
[06:02] <mbiebl> seems your irc client is playing tricks with you 
[06:02] <djszapi> sorry, I do not have time for this, back to work.
[06:02] <djszapi> I clearly claimed I will use the debhelper, that is. There is not much to say over that.
[06:03] <mbiebl> you still didn't understand it dh_installinit is part of debhelper
[06:03] <mbiebl> hopefully you know what you are doing
[06:03] <mbiebl> anyway, seems pointless talking to you
[06:03] <djszapi> sure, none of us on the #debian-devel knows.
[06:03] <djszapi> but you !!
[06:04] <mbiebl> obviously you don't
[06:04] <djszapi> ignore
[06:06] <mbiebl> of course you can stay ignorant if you don't take any advice
[06:12] <mbiebl> Keybuk: are you using Gentoo nowadays :-)
[06:21] <djszapi> SpamapS: good to hear, is it already reported then ?
[06:22] <djszapi> However I will not use that improvement since I need to port the packaging style to debhelper today and I would not like to "port" it back then :)
[06:22] <djszapi> or change anything.
[06:22] <djszapi> but there is a work ongoing, I think I am lucky. I do not even need then to report this feature request.
[06:23] <djszapi> * if there is ..
[06:25] <SpamapS> djszapi: no promises as to when it will be done. I wanted to work on it last Ubuntu cycle and it just got slammed to the bottom of my list. :-P
[06:25] <djszapi> 'kay =p
[06:26] <djszapi> I mean it is not important for me if I can use override_dh_installinit: for now.
[07:25] <djszapi> SpamapS ping
[07:26] <djszapi> SpamapS: I got the idea here: http://permalink.gmane.org/gmane.linux.debian.devel.general/162391 override_dh_installinit: $stuff_to_manually_install_to_etc_init_apps. But i do not know what it means :o
[07:26] <djszapi> I do not see any good description for thsi override_dh_installinit here either: http://www.debian.org/doc/manuals/maint-guide/dother.en.html#initd
[07:51] <SpamapS> djszapi: it means, at the time when you'd normally call dh_installinit, you'll run those commands
[07:52] <SpamapS> djszapi: they don't go right after the:, but on the next line , preceded by a tab.
[07:52] <djszapi> SpamapS: so if I would like to change the path for one file only, I can do that right ?
[07:52] <djszapi> I do not need to "enumerate" all the files because the other files I do not overwrite here will be copied just fine, right ?
[07:53] <SpamapS> djszapi: dh_installinit is pretty elaborate. You'll need to either call it with special arguments, or emulate everything it does.
[07:54] <djszapi> well, I would like to modify one file install path, but it is really a big overhead to do the other 100-200 files manually....
[07:54] <djszapi> that should not be touched at all....
[07:54] <djszapi> just what needs modification.
[07:55] <djszapi> otherwise, it is not really an intelligent system
[08:08] <djszapi> SpamapS ^
[08:09] <SpamapS> I need something that ends in a ?
[08:10] <djszapi> pardon ?
[08:10] <SpamapS> You made a lot of statements
[08:10] <SpamapS> but if you want help, I'm not sure how to help you without a question
[08:11] <djszapi> well, the question is that how I can overwrite the install path for *one* file.
[08:11] <djszapi> without forcing me to install all the other 1000+ files manually.
[08:11] <mbiebl> don't install it via dh_installinit but with dh_install
[08:12] <mbiebl> i.e. don't name it *.init or *.upstart
[08:12] <mbiebl> but you will lose all dh_installinit integration
[08:13] <mbiebl> i.e. start/stop in the maintainer scripts etc
[08:13] <mbiebl> you need to do that manually, if you need that
[08:13] <djszapi> SpamapS ^
[08:16] <SpamapS> mbiebl is right.
[08:16] <SpamapS> and I am sleeeepppyy
[08:17] <SpamapS> djszapi: good luck! I'm going to bed
[08:17] <djszapi> Alright, he will remain ignored about his tone :)
[08:17] <djszapi> I will ask the guy on the debian-devel mailing list who advised it to me.
[08:18] <mbiebl> you are hilarious. do whatever you like
[12:24] <mrvn> Moin. Can I write an upstart job that is run last during startup?
[16:16] <toabctl> is upstart-udev-bridge available in debian stable (ustart 0.6) ?
[16:17] <toabctl> jhunt, i want to execute a job after /dev/ttyS2 is available and use "start on tty-device-added" but nothing happen
[16:18] <toabctl> jhunt, and i got the example from the cookbook you've written.
[16:37] <mrvn> toabctl: you need to specify the instance you are waiting for I thin
[16:37] <mrvn> k
[17:07] <jhunt> toabctl: might be a bug in your .conf file. which example are you referring to? there is no example with tty-device-added in the cookbook.
[17:09] <toabctl> jhunt, i used the example from section 9.2.3. "start on (graphics-device-added or drm-device-added)" and replaced this with "start on tty-device-added"
[17:10] <jhunt> are you running natty?
[17:30] <toabctl> jhunt, no. i use debian on arm
[17:31] <toabctl> jhunt, my question is: can i use upstart-udev-bridge in upstart 0.6.6 or is this a new feature?
[17:34] <toabctl> jhunt, have to go. i'll ask again tomorrow. thanks!
[20:44] <Keybuk> mbiebl: CrOS is built from Gentoo/Portage
[21:38] <mbiebl> Keybuk: interesting. didn't know that
[21:39] <Keybuk> it's about the only distribution system out there that can cross-compile
[21:42] <mbiebl> it's not that I really know much about this topic, but iirc one of multi-archs goals in Debian/Ubuntu is to make cross-compile easier
[21:43] <Keybuk> yeah, and multi-arch has been about two years away
[21:43] <Keybuk> for the past ten years ;-)
[21:46] <mbiebl> hehe, true. At least there seems to be progress atm
[23:34] <astory> if I want to run a job as late into shutdown as possible while the filesystem is still live, what event should I have it start on?
[23:35] <mbiebl> astory: what do you want to do during shutdown?
[23:35] <astory> just remove a file, I'm trying to track unsafe shutdowns
[23:36] <mbiebl> astory: are you on ubuntu?
[23:36] <astory> yes
[23:37] <mbiebl> /etc/rc{0,6}/S60umountroot will mount / ro
[23:37] <mbiebl> you want to remove the file before that
[23:38] <astory> so how do I configure the script so that happens?
[23:38] <mbiebl> start the sysv init script at S59
[23:38] <astory> ah, thanks.
[23:39] <mbiebl> unless you place your file on another partition
[23:39] <mbiebl> then you need  to do it before S40umountfs
[23:39] <astory> it's going to be in /var, so that should be on root on my systems
[23:41] <mbiebl> astory: the shutdown/unmounting in Ubuntu is not really "upstartified"
[23:42] <astory> mbiebl: so should I be using a regular init script, then?
[23:42] <mbiebl> that's why a sysv init script is the simplest solution for your case
[23:42] <mbiebl> yes
[23:42] <astory> ok, thanks
[23:42] <mbiebl> [00:38:35] <mbiebl> start the sysv init script at S59 (in rc6/rc0)