=== robbiew is now known as robbiew_ === juergbi_ is now known as juergbi === [2]sassyn is now known as sassyn === ev1 is now known as ev === ev1 is now known as ev === robbiew_ is now known as robbiew === [3]sassyn is now known as sassyn [20:30] is this the channel for ubuntu networking stuff? [20:32] Hello could someone help me in a matter where I have hard to connect to a multiple SSID WLAN network? [20:37] xopah: that has nothing to do with Upstart, sorry [20:45] Two persons from totally different parts thought this channel has something to do with networkingithin a couple of minutes? Interesting occurrence. [20:45] networking within [20:48] keybuk: could you please point me in the right direction? [20:48] Wher shuld I turn? [20:49] xopah: #ubuntu would be a good next stop [20:49] ion: we were recommended to go here from #ubuntu ... [20:49] Keybuk: ^^WTF?!? [20:50] sadmac: thanks. I'll try there again. [20:50] xopah: np [20:50] hmm. Is #ubuntu having troll problems? [20:52] * sadmac imagine's Scott's "you're making absolutely no sense" face [20:52] I am having problems with programs due to a pygtk not beeing seen [20:53] there are multiple python versions and it worked under gentoo [20:53] Younder: how does this relate to upstart? [20:54] * sadmac begins to get a sinking feeling [20:55] sorry I'll go back to the python group.. take my chances === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew_ [20:58] * Keybuk wonders whether there's a channel mode flag [20:58] to refuse entry to people also in #ubuntu [20:58] Keybuk: wouldn't that block, say, you for example? [20:58] no [20:58] I'm not in #ubuntu [20:59] Keybuk: heh. maybe I don't understand #ubuntu [20:59] * sadmac is in #fedora [20:59] Ubuntu is where users go to ask questions [20:59] err #ubuntu [21:00] Keybuk: yeah. so is #fedora. I like to meet the people [21:00] we have more users than you [21:00] a LOT more users [21:00] they whine more too [21:00] Keybuk: yeah, I don't know that I'd like to meet /your/ users. Ours troll more than yours I'd imagine though [21:00] at least yours might know something of what they're talking about :p [21:01] Keybuk: actually I think 3/4 of the people giving help at any time in #fedora just have irssi set up to periodically say "www.justfuckinggoogleit.com" [21:01] sadmac: Just for fun, join #ubuntu for a minute. It’ll be an... interesting experience. :-P [21:02] “I visited #ubuntu shortly and survived” [21:02] Keybuk: again though, if you do have so many more users, wouldn't you also be blocking half the relevant portion of the internet? [21:02] * raphael__ wonders how #ubuntu, #fedora and #debian compare [21:02] ion: My God, its full of stars! [21:03] It’s full of trolls and the blind trying to lead the blind! rather. [21:03] #debian is nearly as big and not 1/10 as noisy [21:04] ion: that doesn't help me delineate between the three [21:04] ion: they seem to be under the impression that they're linux users of some kind [21:04] from what I've heard, #debian has all /their/ advice macro'd to "go install Ubuntu" [21:05] sadmac: don't think so, it's usually /msg dpkg foo [21:07] raphael__: the users know what dpkg is? sounds like a nice place. [21:07] sadmac: dpkg is a bot on #debian [21:07] * raphael__ wonders how long Keybuk is going to wait before setting mode +m to stop this offtopic conversation :) [21:08] Keybuk: oic [21:08] raphael__: this channel rarely gets on-topic :p [21:08] Keybuk: but from what I've seen off-topic conversations don't last this long ;) [21:08] Keybuk: fine. on topic: I'm finally edging near a workable nih_parse, which is, of course, making me want to replace nih_error while I'm at it :) [21:09] Yes, it would be terrible if that actual users of upstart got a say :) [21:10] Younder: what are you talking about? [21:11] sadmac: what were you going to change? [21:11] Well at present the boot process, to me at any rate, is very confused. I can't see where sysv ends and upstart begins. [21:11] Keybuk: probably not change so much as a new mechanism, along the lines of the lisp condition/restart thing that I've poked at a few times [21:12] Younder: depends which distro you look at [21:12] ubuntu 9.10 [21:12] Keybuk: it would also make a nice replacement for nih_log while we're at it (probably with no API change there) [21:12] most actual Linux distributions tend to have the Upstart /sbin/init daemon run the SysV-style rc scripts (/etc/init.d) [21:13] some distributions (like Ubuntu) do far more in a Upstart native way than others (like Fedora) [21:13] embedded Linux platforms (Chrome OS, Palm Web OS, Maemo, etc.) often use Upstart entirely natively [21:13] Younder: read you read "man runlevel" ? [21:13] sadmac: I know I'm going to regret this, but ... explain? :p [21:14] notting: since I'm thinking of it, when do you want 0.6 tagged into rawhide? Will you just do it yourself when initscripts is ready? [21:14] Younder: that should be "man 7 runlevel" [21:14] Keybuk: basically there is a function/macro called nih_sig() [21:14] Keybuk, sure, but gtk is not on any runlevel. Tomcat and apache, however, are. [21:14] Younder: that's because GTK+ has nothing to do with Upstart [21:14] and Upstart has nothing to do with GTK+ either [21:15] my toaster is also not on any runlevel [21:15] Keybuk: if (some_error) nih_sig (TYPE_OF_ERROR, &some_info, &some_more_info); [21:15] sadmac: hrm. i haven't looked at the other apps. so i'll probably work on it tomorrow or thursday [21:15] yet I can still make toasted goodness [21:15] sadmac: that's basically how nih_error behaves, no? [21:15] and ubuntu has nothing to with upstart either..? [21:15] Keybuk: well, what nih_sig does is interesting [21:15] They just created it [21:15] Younder: Ubuntu uses Upstart, yes [21:16] hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible? [21:16] Younder is clearly a troll. Let’s not feed it anymore. :-P [21:16] I guess what I wnat to know is: is there a reference manual for upstart? [21:16] Keybuk: nih_sig runs a handler for the error, which is a function pointer registered beforehand [21:17] Younder: plenty, start at "man upstart" on your system? [21:17] Keybuk: that function runs right away, and either 1) corrects the error (notice the args passed by ref) 2) longjmps, or 3) aborts [21:17] ah [21:17] more like dpkg-style [21:17] Keybuk, info? [21:17] you have ohshit() [21:17] btw, what's all the nih_foo? I saw it on ureadahead and seemed like it is being used in other places, but it's sort of strange that it doesn't seem to be a shlib [21:18] Keybuk: never seen dpkg code [21:18] ohshit calls any registered error handlers and longjmps back up [21:18] raphael__: it is in lucid [21:18] never mind [21:19] Keybuk: the nih_log thing comes in under the "corrects the error" option. nih_log just calls nih_sig (LOG_EVENT_$LEVEL, log_text) [21:19] oh, I see where you're going with that [21:19] Keybuk: the default handler does just what nih_log does now, but because there's a handler stack, the log line is now also a sort of tracepoint when you're debugging [21:19] it'd be nice if you could thwart the error ;) [21:20] Keybuk: yeah, that too [21:20] e.g. if you raise ENOFILE, an error handler could increase the rlimit, then make you try again [21:20] Keybuk: precisely the idea [21:20] but then that requires while loops and stuff ;) [21:20] while (some_syscall (...) < 0) [21:20] Yeah, the condition/restart thing is powerful. [21:20] nih_sig (...) [21:20] ie. assume that nih_sig solves the problem or longjmps you out [21:21] this is basically how dpkg works [21:21] Keybuk: I'm pulling apart libunwind now to see if it has anything to make some of the uglies around longjmp [21:21] More powerful than plain exceptions. [21:21] I spent a long time maintaining dpkg [21:21] nih_error was originally written for dpkg2 ;) [21:21] it doesn't behave the same way for a reason [21:21] ion: and, ironically, easier to do in C [21:21] a *lot* of problems with dpkg were caused by errant error handlers [21:22] Keybuk: I think it can be made cleaner than it has been. [21:23] I'll play with it if I get to it. right now I want to get the parser standing up so I can finish the early triggers stuff and push some of it. [21:26] hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible? (Any hint?) [21:26] michas: add a line to the jobs that says "console output" [21:27] sadmac, well, it is an old init.d script. IIRC "console output" works only in the real upstart scripts. [21:28] the first "log_action_begin_msg" prints, but any further echo or log doesn't print anymore. I assume it ist upstart filtering the output or something... [21:29] michas: that's going to depend on how upstart is being used to run sysv scripts in ubuntu. you'll have to ask in an ubuntu related channel [21:29] michas: If the script sources /lib/lsb/init-functions, try log_action_msg "foo" or something like that. [21:30] still won't work ;) [21:30] michas: write to a different file, e.g. echo blah blah >> /dev/my.log [21:30] ion, it does use init-function. the first log message works. the second does not. - that's why I suspect upstart. [21:31] nothing to do with upstart per se [21:31] Ubuntu has a "no messages on console during boot" policy [21:31] michas: Please ignore what i said and do what Keybuk said. :-) [21:31] they get hidden with extreme prejudice [21:31] Keybuk, ok, that will surely do. but I'm still wordering wtf is goin on there. ;) [21:34] michas: there are ways to make them appear [21:34] you can add "console output" to /etc/init/rc.conf and /etc/init/rc-sysinit.conf [21:34] and something like console=tty1 to your kernel command-lien [21:34] making sure not to run usplash [21:34] that brings most of them back [21:35] ah, thanks, that looks good. I'll try that. [21:35] but if it doesn't work, try #ubuntu ;) [21:35] :-D [21:36] allright, I'll do. thanks. [21:38] one last real upstart question: ist there a way to do something like "start on *" f.e. to monitor all events? [21:39] no [21:39] Why would you want that? [21:39] such a thing would match itself, for a start [21:39] including its own stopped event ;) [21:39] if you instanced it, you'd end up with a fork bomb [21:40] I just started to read about all the upstart stuff. And then I wondered what events will happen at a startup on my system. [21:41] there used to be a way to dump them as they happened, but we removed it. [21:42] kind of a dangerous thing. People do horrible things when you give them access to that sort of thing from shell scripts. [21:42] :) ok, guess you are right. :) [21:42] you can still see them with --verbose [21:43] there's thousands in the startup of a typical ubuntu system [21:43] where do I have to put that --verbose? [21:43] keybuk: --verbose or --debug? [21:43] michas: kernel command-line [21:43] ion: I tend to recommend --verbose these days [21:43] Alright [21:43] --debug adds things you generally don't want to see [21:44] michas: you could also systemtap them out if you have a recent enough version and a little elbow grease to apply [21:44] * sadmac makes a note to add stap tracepoints to upstart for doing that sort of thing [21:45] are those options documented anywhere? [21:46] michas: no [21:46] ok :) [21:46] (unless you count "init --help" :p) [21:47] oops. too easy. [21:55] ok, thanks a lot. (That current upstart/rc mix in ubuntu is quite confusing, once things don't work as expected... Hope, they switch to upstart completely soon.)