[09:35] <duanedesign> morning all
[09:49] <nigelb> Morning duanedesign
[09:49] <nigelb> hackathons ftw
[10:30] <duanedesign> nigelb: !!
[10:30] <duanedesign> :)
[10:32] <nigelb> duanedesign: heh, 2 days of hacking. total fun :)
[10:45] <duanedesign> whatcha working on nigelb ?
[10:45] <duanedesign> i have been working on a Preferences Panel for CLI Companion
[10:46] <duanedesign> so you can set scrollback, foreground and background color, encoding, etc...
[10:46] <duanedesign> So far only the scrollback works :\
[10:55] <nigelb> duanedesign: Nothin decided yet
[10:59] <duanedesign> nigelb: i found a new site to help with practicing Python http://codingbat.com/python
[10:59] <duanedesign> i like it better then euler, not so math oriented
[10:59]  * duanedesign not so good at math :P
[11:13] <nigelb> duanedesign: heh
[11:25] <duanedesign> off to get breakfast. Ill bring back donuts for all
[11:34] <nigelb> :)
[19:13] <paultag> aloha all
[19:13] <paultag> stuck in the airport :(
[19:14] <paultag> good thing I have my trusty phone modem
[19:21] <paultag> jcastro: your dude's AmeA / IAMA on reddit went great.
[19:21] <paultag> jcastro: dude's pretty cool.
[19:21] <paultag> AMA *
[19:27] <paultag> bbl, reading a book / flying
[19:27] <paultag> much love
[21:18] <duanedesign> paultag: travel safe
[21:18]  * duanedesign said two hours later
[22:26] <jcastro> paultag: thanks, his idea, I had doubts that it owuldn't turn into something dumb, but it ended up awesome
[22:27] <czajkowski> boo


[11:24] <AlexExtreme> it would be much easier to work with IMO
[11:25] <Keybuk> profiles are interesting
[11:25] <Keybuk> one could almost define them as a state in their own right
[11:31] <AlexExtreme> yes
[11:31] <Keybuk> which means you'd be able to turn them on/off during system runtime
[11:31] <AlexExtreme> if I were to use seperate files for each profile, what would be a good directory name for the profiles to live in? i thought /etc/bootprofiles.d, but a) it's a bit long b) profiles wouldn't just be used during boot :)
[11:36] <AlexExtreme> hmm, just a random thought: how about a directory structure like this for upstart:
[11:36] <AlexExtreme>  /etc/upstart
[11:36] <AlexExtreme>          |-----> profiles.d/ - Profiles defined here
[11:36] <AlexExtreme>          |-----> jobs.d/     - Jobs defined here
[11:36] <AlexExtreme>          |-----> states.d/   - States defined here
[11:37] <AlexExtreme> So instead, everything would live under /etc/upstart/something rather than scattered in many directories in /etc
[11:38] <Keybuk> I've been thinking of that, yeah
[11:38] <AlexExtreme> and /etc/event.d is incorrectly named anyway, since they aren't events really, they're jobs and states ;)
[11:39] <Keybuk> yeah
[11:39] <Keybuk> I'd thought of /etc/init instead of /etc/upstart
[11:39] <AlexExtreme> maybe
[11:46] <AlexExtreme> shall I write a spec for a new directory structure? ;)
[11:46] <Keybuk> I don't think it needs one at this point ;)
[11:46] <Keybuk> it's a one-line code change <g>
[11:47] <AlexExtreme> :P
[11:48] <AlexExtreme> the .d is unnecessary, really
[11:49] <AlexExtreme> it'd only be necessary really if there was something like: /etc/upstart/jobs - some static file, and /etc/upstart/jobs.d - a directory to do with that static file
[11:49] <AlexExtreme> since that static file is not there, and most likely won't ever need to be there, the .d is unnecessary
[11:52] <Keybuk> yeah that's what I thought
[11:52] <Keybuk> though it does fit other standard naming
[11:52] <Keybuk> e.g. /etc/udev/rules.d
[11:52] <Keybuk> and upstart will actually support single-conf-files
[11:53] <Keybuk> (I'm gonna push for 0.3.9 at the weekend, while my partner is away <g>
[11:53] <AlexExtreme> cool
[11:53] <AlexExtreme> so what super-duper-cool features are we gonna have? ;)
[11:54] <Keybuk>  - portability fixes
[11:54] <Keybuk>  - bug fixes
[11:54] <Keybuk>  - works when there's no console support by default (openvz, etc.)
[11:55] <Keybuk>  - internal rework of Event
[11:55] <Keybuk>  - multiple configuration file and directory support
[11:55] <Keybuk>  - "reload" support for configuration
[11:55] <Keybuk>  - new initctl commands to replace use of signals
[11:55] <Keybuk>  - new config layout
[11:56] <Keybuk> that lot
  - new config layout << what's that one?
[12:01] <Keybuk> see above ;)
[12:01] <Keybuk> we just agreed on that, no? :p
[12:01] <AlexExtreme> oh
[12:02] <AlexExtreme> i thought that was this one: <Keybuk>  - multiple configuration file and directory support
[12:02] <AlexExtreme> anyhow, sounds good :)
[12:03] <Keybuk> that one is the code support in cfgfile to support tracking what config directories/files have been parsed, and which jobs were found in them
[12:03] <Keybuk> looks something like
[12:03] <Keybuk>   cfg_source_new (NULL, "/etc/init/jobs.d", NULL);
[12:03] <Keybuk>   cfg_source_new (NULL, "/etc/init/states.d", NULL);
[12:03] <Keybuk>   cfg_reload ();
[12:04] <AlexExtreme> ah
[12:27] <AlexExtreme> whoo, written my basic profile parser :p
[12:54] <rgl_> Keybuk, 0.3.9 will work inside a linux-vserver guest?
[12:59] <Keybuk> rgl: in theory
[01:00] <rgl> Keybuk, it will use syslog instead of /dev/console ?
[01:03] <Keybuk> no
[01:03] <Keybuk> it reopens /dev/console properly
[01:05] <rgl> Keybuk, humm, but there is no /dev/console
[01:07] <Keybuk> there's always a /dev/console
[01:07] <rgl> no there isn't ;)
[01:08] <rgl> you have to either link it to /dev/null, or start up syslog-ng to create a pipe at /dev/console
[01:08] <rgl> (linux-vserver does not have a virtualized /dev/console)
[01:08] <Keybuk> it still exists in the kernel
[01:09] <rgl> sure.  but last time I've checked, its not advised to export it to guests.
[01:09] <Keybuk> syslog won't be running, because this is init :)
[01:11] <rgl> humm, good point *G*
[01:11] <AlexExtreme> well, what does sysvinit do? :)
[01:13] <rgl> by default, a linux-vserver does not start init.  it just runs /etc/init.d/rc
[01:14] <rgl> but we can make it run init.  but last time I've tried, I failed to make upstart work at all :-(
[01:14] <Keybuk> AlexExtreme: opens /dev/null
[01:14] <AlexExtreme> rgl: then what is the parent of all the processes? surely when rc exits it'll drop dead since process #1 has died
[01:15] <rgl> AlexExtreme, there is a "virtual" #1.   the guest will stay awake until all its processes die.  (and not when #1 dies)
[01:15] <AlexExtreme> ah
[01:16] <Keybuk> what reaps children?
[01:16] <rgl> I think its that "virtual" #1.
[01:17] <rgl> but I don't known for sure.  there is some magic/vudu out there *G*
[01:17] <rgl> anyways, last night, I couldn't make upstart 0.3.8 do what I want :-(
[01:18] <rgl> can you guys look at http://pastie.caboo.se/66469 and tell me if I'm doing something wrong?
[01:18] <rgl> namely, when I "start php-fcgi", the "php-fcgi-1" does not start at all.
[01:31] <Keybuk> I don't see why that shouldn't work
[01:32] <Keybuk> run in another window
[01:32] <Keybuk> "sudo initctl events"
[01:32] <Keybuk> then do "start php-fcgi" and paste the output of initctl from the other window
[01:33] <rgl> OK.  give me a sec to fireup vmware. :D
[01:36] <rgl> Keybuk, odd.  it now works!
[01:37] <rgl> Keybuk, do I have to restart upstart after I add a new service file or something like that?
[01:40] <Keybuk> shouldn't need to
[01:40] <Keybuk> 0.2.7 had bugs where it didn't notice
[01:40] <Keybuk> 0.3.8 should work just fine
[01:40] <Keybuk> if you have experienced bugs, we'd like to get them fixed :p
[01:42] <rgl> I can't reproduce the problem I had yesterday.  but sure, if I found some bug I'll let you known.
[01:43] <rgl> I found one quirk that is bugging me, if a process fails to restart for five(?) times in a row, upstart never tries to launch it again, it that normal?  can I config it?
[01:43] <Keybuk> right
[01:43] <Keybuk> you'll see a "respawning too fast" type warning
[01:43] <Keybuk> I think it's attempting to respawn 5 times in 10 seconds
[01:44] <Keybuk> it's configurable
[01:44] <Keybuk>   "respawn limit COUNT PERIOD"
[01:44] <Keybuk> e.g.
[01:44] <Keybuk>   respawn limit 100 10
[01:44] <Keybuk> (stop job if it respawns more than 100 times in any 10s period)
[01:44] <rgl> ah nice :D
[01:45] <Keybuk> if either of them are 0, then the respawn catching is disabled
[01:45] <rgl> works on 0.3.8? :D
[01:45] <Keybuk> most things work on 0.3.8
[01:46] <rgl> cool :D
[01:46] <rgl> what you mean respawn catching is disabled?  the service is always restarted?
[01:47] <Keybuk> yeah
[01:47] <Keybuk> service is allowed to restart as many times as it likes
[01:47] <Keybuk> why were you hitting the respawn limit out of interest?
[01:47] <Keybuk> usually that means that the thing you're exec'ing is dying
[01:47] <Keybuk> which is bad, no?
[01:48] <rgl> yes it is a bad thing :D
[01:48] <Keybuk> why was it dying?
[01:48] <rgl> I was trying it :D
[01:48] <rgl> to see how upstart reacted when the service dies
[01:49] <Keybuk> ah right
[01:49] <Keybuk> a few notes from scrollback
[01:49] <Keybuk> "service"
[01:49] <Keybuk> and "start" doesn't exit
[01:49] <Keybuk> Upstart has two basic types of jobs
[01:49] <Keybuk> Tasks and Services
[01:49] <Keybuk> Tasks are things like "run fsck", or "backup my home directory", etc.
[01:49] <Keybuk> Services are daemons and stuff
[01:50] <Keybuk> for tasks, "start" deliberately doesn't exist until it's complete (and events they "start on" aren't deemed finished), since the task is not successful until it exists
[01:50] <Keybuk> s/exist/exit/
[01:50] <Keybuk> for services, you want "start" to exit (and events to finish) when it is running, since that's when it's successful
[01:51] <Keybuk> (a successful fsck is a finished one, a successful web server is a running one)
[01:51] <Keybuk> they're otherwise identical in configuration
[01:51] <Keybuk> Upstart jobs default to being tasks
[01:51] <Keybuk> if you want them to be services, you need to put either "service" or "respawn" in the config
[01:52] <rgl> woah, thx!  that explains things :-)
[01:53] <Keybuk> there's a third option as well
[01:53] <Keybuk> but this is not fully implemented yet
[01:53] <Keybuk> (supervision on processes that fork into the background)
[01:53] <Keybuk> --
[01:54] <Keybuk> why failing services still say "started"
[01:54] <Keybuk> this is because from Upstart's point of view, it has started -- the script is running
[01:54] <Keybuk> there's no internal way (yet) for the service to notify Upstart that it is, in fact, really running and really ready
[01:54] <Keybuk> there's two planned improvements here:
[01:55] <Keybuk>  1 - better catching of exec() failures.  Right now Upstart forks the child and assumes it's running; exec() failures aren't special.  This will change so that the exec() has to finish before Upstart moves the job out of the spawned state (and thus can move directly into stopping if the exec() failed for some reason)
[01:56] <Keybuk>  2 - libupstart readyness notification.  services that take a while to be ready will be able to use libupstart to notify upstart that they're accepting connections, etc.  if this fails to happen, they can be considered failed, killed, and restarted
[02:00] <rgl> I see.  thx for the explanation :-)
[02:00] <rgl> are you also planning on having monit alike-features? :D
[02:02] <Keybuk> no
[02:03] <Keybuk> no particular reason to, since monit already has those features
[02:03] <Keybuk> you can use monit to do the monitoring, and have it tell upstart to restart services, etc.
[02:04] <rgl> ah ok.
[02:04] <rgl> maybe monit could be enhanced to do real time monitoring by listening to upstart events.
[02:04] <Keybuk> I'm a full believer in the "do only one thing well"
[02:04] <Keybuk> exactly
[02:04] <Keybuk> same for heartbeat, et al
[02:05] <Keybuk> it makes no sense for upstart to grow the ability to communicate across serial ports, etc.
[02:05] <Keybuk> it makes far more sense for the services that already can do that to link to libupstart and emit events, or even start/stop processes themselves
[02:05] <Keybuk> if you look at initctl, it's just a wrapper around libupstart
[02:05] <Keybuk> so any process can do whatever it can do
[02:05] <Keybuk> (ie. list services, start/stop them, emit events, etc.)
[02:06] <rgl> makes sense :)
[02:07] <rgl> what is libupstart?
[02:07] <rgl> I mean, I see no libupstart package
[02:07] <Keybuk> the IPC library
[02:08] <Keybuk> see upstart/message.h in the source code
[02:08] <Keybuk> it's not separately packaged yet, because the API isn't anywhere near stable
[02:08] <rgl> ah, so its not yet packed as a .so file.
[02:08] <Keybuk> right, it's an .a file in the source linked to by initctl
[02:09] <Keybuk> anything initctl does is through libupstart messages
[02:09] <Keybuk> e.g. "initctl version"
[02:10] <Keybuk> that's done by something like:
[02:10] <Keybuk>   int sock = upstart_open ();
[02:10] <Keybuk>   NihIoMessage *msg = upstart_message_new (NULL, UPSTART_INIT_DAEMON, UPSTART_VERSION_QUERY);
[02:10] <Keybuk>   nih_io_message_send (msg, sock);
[02:11] <Keybuk>   msg = nih_io_message_recv (NULL, sock, NULL);
[02:11] <Keybuk>   upstart_message_handle (NULL, msg, { UPSTART_VERSION, my_func }, NULL);
[02:11] <Keybuk> my_func (..., const char *version, ...) {
[02:11] <Keybuk>    printf ("%s\n", version);
[02:11] <Keybuk> }
[02:12] <rgl> sweet :D
[02:12] <rgl> what is NIH?   (not invented here? *G*)
[02:12] <ion_> NihIoMessage *msg = upstart_message_new (NULL, UPSTART_INIT_DAEMON, UPSTART_I_NEED_CAFFEINE_NOW);
[02:12] <Keybuk> yes
[02:12] <Keybuk> ion_: UPSTART_EVENT_EMIT, "i-need-caffeine" :p
[02:13] <ion_> :-)
[02:13] <Keybuk> rgl: libnih is my "Copy & Paste" code library
[02:13] <Keybuk> that stack of code that most developers have of useful bits and pieces that don't quite exist anywhere else
[02:13] <Keybuk> it's roughly akin to glib, or the hackerlab lib, etc.
[02:13] <rgl> ah, good old misc. utils lib :D
[02:14] <Keybuk> I should put that in the FAQ?
[02:14] <Keybuk> "Q. Why do you use libnih and not glib?"
[02:14] <Keybuk> "A. typedef int gint"
[02:14] <ion_> Hehe
[02:14] <rgl> whats the pun? :D
[02:15] <Keybuk> pun?
[02:15] <rgl> I didn't get the answer *G*
[02:15] <rgl> so I suppose its a pun or something like that
[02:16] <Keybuk> glib provides alternate names for all of the C standard types
[02:16] <Keybuk> allegedly for portability
[02:16] <Keybuk> so instead of "int", you have "gint"
[02:16] <Keybuk> and instead of "char", you have "gchar"
[02:17] <rgl> so what?
[02:17] <Keybuk> it's silly
[02:18] <Keybuk> "gpointer is easier to use than void *"
[02:18] <Keybuk> no it's not
[02:18] <rgl> its like having DWORD, UNIT and the like, no? :D
[02:18] <Keybuk> it's longer to type, and it's not very C-ish
[02:18] <Keybuk> DWORD makes sense, since it varies between platforms
[02:18] <Keybuk> and needs to be defined differently in different circumstances
[02:19] <rgl> the "WORD" is "DWORD" is different for each CPU I guess.  so its like silly too.  unless WORD is not as in CPU WORD.
[02:20] <Keybuk> glib tries to hide C from the programmer
[02:20] <Keybuk> you don't program in C, you program in "glib"
[02:20] <Keybuk> this strange OO-ish variant of C
[02:20] <Keybuk> this, to me, seems silly
[02:21] <rgl> C with gobjects :D
[02:27] <rgl> why do jobs default to task instead of service?
[02:29] <ion_> Id expect most of the jobs to be tasks eventually.
[02:33] <Keybuk> rgl: had to pick one
[02:33] <rgl> why not make it explicit?
[02:33] <Keybuk> if "service" was the default, you'd need a "task" stanza
[02:34] <Keybuk> and then you'd have the issue where you'd have to error if both "task" and "respawn", or "task" and "daemon" were specified
[02:34] <Keybuk> with "task" as the default, there's no need for any conflicts checking - "service", "respawn" and "daemon" are all possible options; and any of them implicitly enable "service" if not already specified
[02:35] <Keybuk> explicit is the likely end-point, yeah
[02:35] <Keybuk> but then that's icky, because you'd need "file doesn't state any of 'task', 'service', 'respawn', 'daemon', 'state', 'profile'" etc.
[02:35] <Keybuk> another option is to configure them in different directories
[02:35] <Keybuk> /etc/init/tasks.d
[02:36] <Keybuk> /etc/init/services.d
[02:36] <rgl> or "unknown job type" *G*
[02:36] <ion_> In the long run, multiple directories might be good, as the number of jobs will go up.
[02:36] <Keybuk> of course, multiple directories has the namespace issue
[02:37] <ion_> True.
[02:37] <Keybuk> /etc/init.d/task.d/foo
[02:37] <Keybuk> /etc/init.d/service.d/foo
[02:37] <Keybuk> which wins?
[02:37] <rgl> humm, havin different directories means you'll have different event namespaces?  that is, how you'd wait for a task/service?
[02:37] <rgl> yeah *G*
[02:37] <ion_> Neither. Upstart gives an error and doesnt use either one.
[02:38] <rgl> or foo.task foo.service *G*
[02:39] <Keybuk> rgl: ick
[02:39] <Keybuk> :p
[02:41] <rgl> hehe
[02:41] <rgl> one thing I would like is "nested" services, that is, php-fcgi, php-fcgi/1, etc :D
[02:47] <Keybuk> rgl: we kinda have that <g>
[02:47] <Keybuk> your php-fcgi is an excellent use case for something else we've been thinking of
[02:47] <Keybuk> and let me explain by first talking about that
[02:47] <Keybuk> right now we have /etc/event.d/tty[1-6]
[02:47] <Keybuk> 6 files, all of which do the same thing, with different arguments
[02:47] <Keybuk> and each one would need something like
[02:48] <Keybuk>   while tty-added tty1 until tty-removed $TTY
[02:48] <Keybuk>   exec /sbin/getty 38400 tty1
[02:48] <Keybuk> eurgh
[02:48] <Keybuk> it would be better to have one getty job that runs 6 times, with different arguments
[02:48] <Keybuk> we have this kind of thing already
[02:48] <Keybuk> "instance" jobs
[02:48] <Keybuk> if you put the "instance" keyword in the config file, then every "start" will spawn off a new instance
[02:49] <Keybuk> so "status php-fcgi" would return as many lines as "start" has been called
[02:49] <Keybuk> likewise for events
[02:49] <Keybuk> so, we could have a single getty job:
[02:49] <Keybuk>   instance
[02:49] <Keybuk>   while tty-added tty[1-6]  until tty-removed $TTY
[02:49] <Keybuk>   exec /sbin/getty 38400 $TTY
[02:50] <Keybuk> that'd get run 6 times, since six matching "tty-added" events would occur
[02:50] <Keybuk> and each one would run until its associated tty was removed
[02:50] <Keybuk> your example would work very well with file events
[02:50] <Keybuk>   instance
[02:51] <Keybuk>   while file-exists /var/run/php/fcgi.*
[02:51] <Keybuk>   exec /usr/bin/php5-cgi -b $FILE
[02:51] <Keybuk> you'd get as many events as you had matching files, and thus as many instances of that job
[02:51] <Keybuk> "status" would show them all
[02:51] <Keybuk> "start" would have to specify which file it wanted to start with ...
[02:52] <Keybuk>    # initctl start php-fcgi FILE=/var/run/php/fcgi.foo
[02:52] <Keybuk> "stop" would have to specify which instance to stop; or "stop php-fcgi" would stop them all
[02:55] <rgl> hum, so to start an instance we just need to touch a file?   and to stop it we just need to rm it?
[02:55] <Keybuk> yeah
[02:56] <rgl> all FS have notifications?
[02:56] <Keybuk> inotify is in the VFS layer, so yeah
[02:57] <rgl> you are targetting linux only?
[02:57] <Keybuk> absolutely
[02:57] <Keybuk> Upstart is unashamedly dependant on features of the Linux kernel
[02:57] <rgl> okay :D
[02:58] <Keybuk> I think the above is a pretty elegant solution, what do you think?
[02:59] <rgl> its pretty neat :D
[03:00] <rgl> at least for this particular use-case :-)
[03:00] <rgl> can I have it now? ;-)
[03:01] <Keybuk> soon
[03:01] <Keybuk> the instance bit works now
[03:01] <Keybuk> the tying instances to events bit depends on complex-event-config
[03:01] <Keybuk> and you'd want file events as well, which are todo
[03:02] <rgl> cool :D
[03:03] <AlexExtreme> bah
[03:03] <AlexExtreme> Keybuk, can you help me with NihList quickly? :)
[03:03] <Keybuk> sure
[03:04] <AlexExtreme> hang on
[03:06] <AlexExtreme> http://frugalware.org/paste/1453 << ok, that's my code. it's probably really ugly, but anyway :) the loop at the bottom goes through each of the things i've added to the list and prints them out, but it prints out complete rubbish and uses the wrong value for disabled. so obviously i'm adding stuff incorrectly. it's mostly based on what i've seen from notify.c in upstart
[03:06] <AlexExtreme> s/disabled/enabled/
[03:09] <Keybuk> style: "NihList entry" is nominally the first thing in a struct
[03:09] <Keybuk> (nothing assumes this, but it's just a style point)
[03:09] <AlexExtreme> heh
[03:09] <AlexExtreme> well
[03:09] <AlexExtreme> that kinda fixed it :p
[03:09] <Keybuk> you don't need NIH_LIST_FOREACH_SAFE
[03:09] <Keybuk> just NIH_LIST_FOREACH will do
[03:09] <Keybuk> aha!
[03:10] <Keybuk> yes, the iter points you're getting are pointers to the entry member
[03:10] <Keybuk> so you can't just cast them to upstart_profileentry_t
[03:10] <Keybuk> (this is the reason I always put the NihList entry first <g>)
[03:10] <AlexExtreme> :)
[03:10] <AlexExtreme> well
[03:10] <AlexExtreme> now i'm getting this
[03:10] <AlexExtreme> [14:09:35]  [ alex in ~/Frugalware/work/upstart/profile ]  $ ./profile default
[03:10] <AlexExtreme> Parsing profile default...
[03:10] <AlexExtreme>  * Everything will be enabled by default but can be overridden
[03:10] <AlexExtreme>  * network will be enabled no matter what
[03:10] <AlexExtreme> but, it doesn't seem to recognise the fact that there is also an apache entry there somewhere
[03:11] <AlexExtreme> [14:10:39]  [ alex in ~/Frugalware/work/upstart/profile ]  $ cat default
[03:11] <AlexExtreme> * = y
[03:11] <AlexExtreme> apache = y
[03:11] <AlexExtreme> network = n
[03:11] <Keybuk> you free the job in the loop ;)
[03:11] <AlexExtreme> oops
[03:11] <AlexExtreme> :p
[03:12] <AlexExtreme> [14:11:22]  [ alex in ~/Frugalware/work/upstart/profile ]  $ ./profile default
[03:12] <AlexExtreme> Parsing profile default...
[03:12] <AlexExtreme>  * Everything will be enabled by default but can be overridden
[03:12] <AlexExtreme>  * apache will be disabled no matter what
[03:12] <AlexExtreme>  * network will be enabled no matter what
[03:12] <AlexExtreme> yay \o/
[03:12] <AlexExtreme> thanks ;)
[03:12] <AlexExtreme> now to make it check against files in /etc/event.d
[03:13] <rgl> "stop on runlevel [!1] " is that a stop on runlevel not 1 ?
[03:13] <Keybuk> yes
[03:13] <rgl> is so, why the []  ?
[03:13] <Keybuk> fnmatch()
[03:13] <Keybuk> standard UNIX glob(7) syntax
[03:14] <rgl> the runlevel arg is a glob?
[03:14] <Keybuk> yes
[03:14] <rgl> ah alright :D
[03:14] <Keybuk> arguments to events in "on" are globs
[03:14] <rgl> I can have: stop on runlevel 1 2 3 ?
[03:14] <Keybuk> so that means stop on any runlevel event with a single-character argument that is not the character "1"
[03:14] <Keybuk> no
[03:14] <Keybuk> stop on runlevel [123
[03:14] <Keybuk> stop on runlevel [123]
[03:14] <Keybuk> the runlevel event has a single argument, the runlevel being entered
[03:15] <rgl> ACK :)
[03:17] <Keybuk> I realised the other day that the runlevel event should have a RUNLEVEL and PREVLEVEL environment variable
[03:17] <Keybuk> then I could do away with all of the code in the rc jobs
[03:18] <Keybuk> runlevel would update utmp and emit the event itself
[03:19] <Keybuk> err, telinit would
[03:20] <Keybuk> then I could do away with runlevel --set
[03:40] <rgl> how do I make sure the admin does not start an service because another one is not running?
[03:40] <rgl> something like dependencies.
[03:42] <rgl> oh well, scrap that.  if it depends on other, and that one is not started, the start of the service will eventually fail because of that.  so the admin will notice that somehing is not right.
[03:44] <Keybuk> how do you mean
[03:44] <Keybuk> right
[03:47] <AlexExtreme> hooray! http://frugalware.org/paste/1454
[04:02] <rgl> Keybuk, what is the behaviour of jobs that are symlinks?   I mean, I have a symlink: php-fcgi-3 -> php-fcgi-1 and when I change php-fcg-1 job file, and do a: stop php-fcgi-3 ; start php-fcgi-3;  upstart does not reload the job file.  Is that intended?
[04:03] <Keybuk> err
[04:03] <Keybuk> yes :-)
[04:03] <AlexExtreme> iirc inotify has some bugs with symlinks
[04:04] <Keybuk> either we need to handle symlinks specially, or inotify needs to handle them specially
[04:04] <Keybuk> use hardlinks for now :o)
[04:04] <rgl> ok :D
[04:04] <AlexExtreme> kernel command line arguments that the kernel doesn't use are passed to init, right?
[04:05] <Keybuk> AlexExtreme: foo=bar arguments are set in init's environment
[04:05] <Keybuk> AlexExtreme: anything else is an argument, yes
[04:06] <AlexExtreme> ah, cool. so if i were to do what my profiles spec says on the kernel command line, i'd get the requested profile in the environment?
[04:08] <Keybuk> right
[04:08] <Keybuk> except upstart doesn't pass those yet (bug)
[04:18] <rgl> Keybuk, ouch, even hardlinks do not work *G*
[04:18] <Keybuk> heh
[04:18] <Keybuk> really?
[04:18] <Keybuk> interesting
[04:19] <rgl> yup, really.  I had to touch the file to upstart to reload it.
[04:20] <Keybuk> that's odd
[04:20] <Keybuk> since touching the file is the same effect as editing it, no? :p
[04:20] <Keybuk> maybe it's touch-by-name
[04:21] <rgl> the point is.  if I edit the config file (say, on hardlink 1), I have to touch all the other hardlinks too.
[04:23] <rgl> so I really need that "instance" feature you've talked yearlier, or else I might be biten in the arse someday heheh
[04:29] <AlexExtreme> i don't need upstart to pass them to the jobs, i need it from upstart itself :)
[04:29] <AlexExtreme> (the environment vars)
[04:43] <AlexExtreme> hmm
[04:45] <AlexExtreme> is the profile override on the kernel command line thing that I put in the profiles spec really necessary? I can't really think of a valid use case for it
[04:45] <Keybuk> dunno, I can't remember what it was for?
[04:46] <AlexExtreme> The profile can be overridden at boot-time by specifying extra kernel command line arguments, like the example below. It tells upstart to use the "noserver" profile but overrides what the profile defines should be done with mysql and postgresql:
[04:46] <AlexExtreme>     *
[04:46] <AlexExtreme>       bootprofile=noserver override=mysql:no,postgresql:no
[04:46] <AlexExtreme> it's just the override part i'm referring to
[04:46] <Keybuk> oh right
[04:46] <AlexExtreme> you should definitely be able to change the profile at boot :)
[04:47] <Keybuk> and after booted? :p
[04:47] <AlexExtreme> yes, of course :P
[04:47] <AlexExtreme> actually
[04:47] <Keybuk> which begs the question, do the jobs respond to the events, and just not start
[04:47] <Keybuk> so when you re-enable the profile, they start immediately
[04:48] <AlexExtreme> IMO they shouldn't immediately start
[04:49] <Keybuk> why not?
[04:49] <Keybuk> if I enable multiuser, shouldn't things like getty start? :p
[04:49] <AlexExtreme> true
[04:50] <AlexExtreme> that, of course, makes life a lot harder :) (at least, afaik)
[05:03] <AlexExtreme> http://upstart.ubuntu.com/wiki/Profiles << how's that?
[05:05] <rgl> I have to ask this.  why a file and not a directory with the jobs you want on a profile?
[05:06] <AlexExtreme> huh?
[05:06] <AlexExtreme> the file only lists the names of the jobs
[05:07] <rgl> and the directory would too.  you just need to have a file named after the job name.
[05:07] <rgl> that way, its easier for a package to add a job into a profile.  (it doesn't need to edit a file).
[05:07] <AlexExtreme> there would be a utility to do that
[05:08] <AlexExtreme> so the packages would just call a utility
[05:08] <AlexExtreme> and you wouldn't be able to do the * with that, nor disable jobs easily
[05:08] <AlexExtreme> and it requires you to use symlinks
[05:08] <rgl> I like the directory better.  *G*
[05:08] <rgl> if you don't want a job in a profile, that create a file for it.
[05:09] <rgl> if you don't want a job in a profile, don't create a file for it.
[05:09] <AlexExtreme> i don't see why it's better, all i can see are disadvantages
[05:09] <rgl> *srug*
[05:13] <rgl> maybe the command should be named "profile" as in "initctl profile new-profile-name"?


[12:00] <danilos> gmb, hi, what do you think of https://devpad.canonical.com/~danilo/screencasts/inline-validation-error.ogv for inline error handling?
[12:01] <gmb> danilos: Sweeet.
[12:01] <gmb> Love it.
[12:01] <danilos> gmb, cool, thanks, then I'll run with it :)
[12:01] <gmb> Excellent.
[12:37] <benji> oops, forgot to fire up my IRC client
[12:44]  * gmb grabs some lunch
[13:22] <gary_poster> ok, bac, I think I've worked through my mail backlog sufficiently.  I think milestone is the last one to be done?
[13:22] <bac> gary_poster: really?  ok.  are you offering?  i'm still working on the distro abnormalities
[13:22] <gary_poster> bac, yes, I am offering
[13:23] <gary_poster> I'll start
[13:23] <bac> excellent
[13:24] <bac> danilos: your screencast is great!
[13:24] <danilos> bac, thanks :)
[13:25] <danilos> gary_poster, fwiw (since you joined right after I posted the URL), https://devpad.canonical.com/~danilo/screencasts/inline-validation-error.ogv
[13:26] <gary_poster> danilos, a thing of beauty :-) thank you
[13:26] <bac> danilos: you need to up the volume for the soundtrack
[13:26] <danilos> bac, heh, did it record that as well? that was accidental :))
[13:26] <gary_poster> "odistani" means stop or something?
[13:27] <danilos> yeah, it means "give up"
[13:27] <danilos> or "cancel"
[13:27] <gary_poster> lol
[13:27] <gary_poster> I like "give up"
[13:27] <gary_poster> I think we should change all of our "cancel" buttons in LP to "give up" or perhaps "surrender"
[13:28] <benji> heh
[13:28] <danilos> heh
[13:30] <danilos> uhm, mumble time?
[13:30] <gary_poster> oh yeah, that
[13:30] <danilos> :)
[13:30] <gary_poster> bac benji danilos gmb munble/kanban
[13:31] <benji> on a realted note, the green checkmark and red X buttons are far too small
[13:31] <gary_poster> you all are probably there already...
[13:31] <gary_poster> I think that's an LP issue, benji but could be wrong
[13:31] <danilos> yeah, they are bitmaps which don't really work well with our high resolution screens
[13:31] <benji> yeah, I think it is too, they're used all over the place
[13:32] <benji> I wouldn't mind nice big buttons with words and those images on the buttons
[13:38] <gmb> Mumble is too much fun.
[13:38] <danilos> gmb, don't play with the buttons :)
[13:38] <gmb> Hee hee.
[13:39]  * benji vows to cultivate the MP cover letter style of Dostoyevsky.
[13:44] <gary_poster> :-)
[13:45] <danilos> gary_poster, 1-on-1 calls today, right?
[13:45] <gary_poster> danilos, was going to say that, yeah
[13:45] <gary_poster> have a card on board for it
[13:45] <gary_poster> the only tricky bit will be gmb
[13:45] <gary_poster> gmb, after I write my cover letter and before you start review we can havee a quick call?
[13:46] <gmb> gary_poster: Sure, that works for me.
[13:46] <gary_poster> cool thanks
[13:46] <gary_poster> Warning for those who care: I intend to merge devel into ~yellow/launchpad/accordionoverlay before making my review branch
[13:50] <benji> k
[13:51] <gary_poster> bac, combine-css.in from ~yellow's accordionoverlay has this conflict when I merge devel in: http://pastebin.ubuntu.com/584817/ .  All three of the galley-accordion files exist in the tree.  Do you have any suggestions on how to merge that?
[13:53] <bac> gary_poster: you need both gallery-accordion css files and you need the new sprite file
[13:53] <gary_poster> bac, but what about the other gallery accordion file?
[13:53] <gary_poster> I was just about to see if it subsumes the other two
[13:53] <bac> gary_poster: sorry.  you need core and skin
[13:54] <gary_poster> so delete the third one?
[13:54] <bac> yes, delete from that file
[13:54] <gary_poster> ack, thanks.
[13:55] <gary_poster> bac, and I'm also doing a corresponding "bzr rm ./lib/lp/contrib/javascript/yui3-gallery/gallery-accordion/assets/skins/sam/gallery-accordion.css" yeah?
[13:56] <bac> sure, it is vestigial
[13:56] <gary_poster> cool thanks
[14:21] <bac> gary_poster: i jotted some notes yesterday as i encountered some problems/suspicions.  they are http://pastebin.ubuntu.com/584843/
[14:21] <gary_poster> looking
[14:28] <gary_poster> thanks bac.  +1 on making a card for the first two bullet points.
[14:28] <gary_poster> For the third, I hear what you are saying.  I don't know of a more standard way of doing it (I looked), and I think I grew that from some code Danilo had done on another branch (but it was in progress, so he may have had something better in mind later).
[14:29] <gary_poster> Elsewhere I wrote this to cache the decision within a loop, so that if you kept encountering the same team at least that would be cheaper.  In the current code path, the function will only be a problem if the user is a member of many teams.
[14:29] <gary_poster> You or Curtis would be our best hopes in discovering an existing standard way of doing that.  Otherwise, we can either pre-emptively attack the code (possibly having to make another table to cache the decision?  sounds expensive.  Do you have another idea?) or wait and see if it is a problem.
[14:29] <gary_poster> Finally, for bullet point 4, I'd be +1 on making a nice-to-have card in our display backlog lane to add the action portlet if Huw or someone else representative seems to agree.
[14:31] <danilos> gary_poster, bac: I believe team.adminmembers expands the list of admins with the owner (if needed) in python, which is why you've got to use it or re-implement it; not sure that's the good solution though
[14:33] <gary_poster> It sounds like it is not particularly more efficient either.  I wonder...
[14:33] <gary_poster> It seems like there might be a SQL way of using the team membership table and the adminmembers to ask if a person were a member of the admins, or of admin teams
[14:34] <gary_poster> that would probably be significantly better
[14:34] <danilos> that code would certainly benefit from being a Collection (in LP sense of Collections) allowing easy matching/joining and resulting in a single query; doing it directly with Storm is possible as well
[14:35] <danilos> gary_poster, probably best for the short term, so +1 on that, though I wouldn't dwell on it and would leave it as a separate task
[14:36] <gary_poster> danilo, agreed on separate task/card.  which is your short term recommendation?  Storm directly?
[14:36] <danilos> gary_poster, yeah
[14:36] <gary_poster> cool
[14:36] <gary_poster> bac, +1 on making a card for that too then
[14:36] <danilos> gary_poster, long-term would be rewriting all of Team model code to use Collections :)
[14:37] <gary_poster> :-)
[14:37] <gary_poster> I don't think I'll commission that just now ;-)
[14:37] <gary_poster> bac, I will make cards for you if you want, but not till I finish the MP, and have my scheduled calls
[14:37] <danilos> heh, are you absolutely sure???
[14:37] <gary_poster> lol
[14:37] <bac> gary_poster: ok.  sorry i was making tea
[14:37] <danilos> anyway, gary_poster, when do we chat? (or do you want to get hold of gmb first)
[14:37] <gary_poster> np bac
[14:38] <gary_poster> danilos, in 52 min
[14:38] <bac> gary_poster: i can just hear lifeless complaining about that method, though.
[14:38] <danilos> gary_poster, ah, google calendar DST fuckup, ok
[14:38] <gary_poster> right
[14:38] <gary_poster> to both of you ;-)
[14:38] <bac> danilos: you can make all appts in google cal be UTC
[14:39] <gary_poster> well
[14:39] <gary_poster> I want these to follow along with my timezone usually
[14:39] <danilos> me too
[14:39] <bac> that's problematic if everyone doesn't follow your same DST rules.  :)
[14:40] <danilos> gary_poster, we probably need to create them in UTC, and everyone sets the local time zone as appropriate
[14:40] <bac> i think canonical should be a dst-free zone
[14:40] <gary_poster> if everyone would simply follow along with the *American* legislature's silly DST laws, then things would be much simpler ;-) .  or, yeah, we could do what the rest of the world does, but America is not too good at that sometimes. :-)
[14:41] <bac> gary_poster: we're saner than many.  last year argentina's president arrived from a long trip and cancelled DST that was to begin the next day.  my iphone never recovered
[14:41] <gary_poster> danilos, feel free to change, though next week we should be re-aligned
[14:41] <danilos> heh, this time, I don't think America is much to blame, DST itself is simply insane and if it really is to save electricity, let's just get up earlier :)
[14:41] <gary_poster> lol bac
[14:41] <gary_poster> heh
[14:41] <danilos> gary_poster, yeah, leaving it as-is, to see how it'll look next week
[14:41] <gary_poster> cool
[14:51] <danilos> bac, benji, gmb: hi guys, I'll be adding you all as my peer reviewers -- don't feel obligated to fill it in, but if you've got any input you want to share with me, I'd be happy to hear it out in there as well :)
[14:52] <benji> k
[14:52] <bac>          sure
[14:52] <danilos> (if allhands.c.c lets me, since it's a pleasure to use)
[14:52] <gmb> Fair enough. I keep forgetting I need to do that, so I'll likely do the same.
[14:53] <bac> gary_poster: i'm confounded by bmurray's work with subscribe/bugtask/bugsupervisor.  i'm not convinced it is doing what he thinks ATM.
[14:53] <gary-lunch> weird
[14:54] <danilos> gmb, I believe email from Claire said the deadline for self-evaluation and requesting peer reviews is tomorrow
[14:55] <gmb> Blimey. Better get on with it then.
[14:55] <gmb> I appear to have come unsubscribed from warthogs and allhands, which hasn't helped.
[14:55] <gary_poster> huh
[14:55] <gary_poster> yeah, I would need to do that too then :-P
[14:55] <gmb> danilos: Thanks for the heads-up
[14:56] <gary_poster> likewise
[14:57] <danilos> gmb, I think I said this before, but it's not necessarily a bad thing to be unsubscribed from warthogs@ ;)
[14:57] <gmb> :)
[14:57] <gary_poster> heh, it collects mail for me
[14:59] <danilos> "flag \Seen" sieve rule FTW :)
[14:59] <gary_poster> bac, can you give a quick explanation as to why lib/lp/registry/templates/product-portlet-license-missing.pt went from tal:content to tal:replace
[14:59] <gary_poster> ?
[15:01] <bac> gary_poster: replace is correct since it is using 'structure' the replacement value has an anchor in it.  with 'content' there was an <a> within an <a>
[15:01] <gary_poster> perfect, thanks bac
[15:01] <bac> it came up b/c i was doing so much work with the web inspector console open i discovered a lot of HTML errors, like the one i showed you yesterday
[15:02] <bac> we should have an automated manner of finding those
[15:02]  * gary_poster wonders if tidy is better these days or what the alternatives are now
[15:02] <gary_poster> though that would have had a hard time ctahcing this
[15:02] <gary_poster> we kinda want something spidering the rendered site
[15:03] <gary_poster> and telling us about oopsies
[15:04] <gary_poster> bac, could you please scan over the MP draft http://pastebin.ubuntu.com/584864/plain/ and give me corrections/additions/ etc.?
[15:04] <gary_poster> it's pretty bare bones
[15:04] <bac> ok
[15:04] <gary_poster> but I didn't have time for much else
[15:05] <gary_poster> eh, XXX should be replaced with the string "lib/lp/registry/javascript/tests/test_structural_subscription.js : Test code."
[15:06] <bac> gary_poster: i'm pretty sure these are left-overs from an aborted first effort:
[15:06] <bac> lib/lp/app/javascript/accordionoverlay.js : simple base class for adding an accordion within an overlay.
[15:06] <bac> lib/lp/app/javascript/tests/test_accordionoverlay.js : test.
[15:06] <bac> a quick grep should show they are not used
[15:06] <bac> it is my fault for leaving them around
[15:07] <gary_poster> ok, will do, bac.  Also, a lint shows a lot of tab characters in the JS.  I don't know who introduced them, but to your knowledge they are not intentional, right?
[15:07] <bac> gary_poster: my emacs was dumb wrt JS at the beginning.  it has been emsmartened
[15:07] <gary_poster> :-)
[15:07] <gary_poster> k
[15:07] <gary_poster> I'll clean those up too
[15:08] <bac> (of course it now strips tabs from makefiles, which is irritating)
[15:08] <gary_poster> heh
[15:08] <bac> gary_poster: the remainder of the letter looks fine to me.  it is quite concise.  well done.
[15:09] <gary_poster> thanks bac
[15:09] <bac> regarding windmill, i think we need something
[15:10] <bac> for instance, the unit tests in test_subscription_links work happily even if the bits to invoke the JS setup are missing from the page template
[15:10] <gary_poster> yup
[15:10] <bac> the JS is "well" tested
[15:10] <gary_poster> :-)
[15:10] <bac> so i think we need windmill to just show the links are visible and have js-action class
[15:11] <gary_poster> sounds good.  I'll add that as a note.
[15:15] <bac> hi gmb, can you help me unravel some bugs infrastructure?
[15:15] <gmb> bac: I can try. What's up?
[15:16] <bac> gmb: could you tell me where i'd see BugsTaskSearchListingMenu in use for an IDistribution?
[15:16] <bac> would that be bugs.launchpad.dev/ubuntu ?
[15:17] <bac> there is funky logic for when the subscribe link is shown but i'm unconvinced it works
[15:18] <gmb> Hmm
[15:19] <gmb> bac: Yes, I think bugs.l.n/ubuntu should work.
[15:20] <bac> ok
[15:20] <bac> thanks for the sanity check.  bugs views aren't nearly as straightforward as others...
[15:21] <gmb> Nope. The joys of working on one of the oldest bits of the system I guess.
[15:21] <gmb> There are times I'd like to find Brad Bollenbach and ask "what were you thinking?"
[15:29] <gary_poster> Fixing line length lint in JS: not my idea of a good time.
[15:39] <gary_poster> gmb, ok, https://code.launchpad.net/~gary/launchpad/accordion-client-1/+merge/54715 is calculating a diff.  Sorry it took so long, but I had to do a few cleanups.  Oh, I should have added in the MP that lint is happy.  Quick call?>
[15:40] <gmb> gary_poster: Sure. Let me get my mumble on.
[15:40] <gary_poster> cool
[15:44] <danilos> gary_poster, hi, ping me when you are done with gmb and/or ready for our own 1-on-1 :)
[15:46] <gary_poster> cool
[15:50] <gary_poster> danilos, ready when you are
[16:05] <danilos> gary_poster, LP_DEBUG_SQL
[16:05] <danilos> gary_poster, LP_DEBUG_SQL=1
[16:45] <gmb> gary_poster, bac: On line 327 of the diff here https://code.launchpad.net/~gary/launchpad/accordion-client-1/+merge/54715, the feature flag that gets looked up is 'advanced-structural-subscriptions.enabled'. I thought this had been changed to 'malone.advanced...'; is that the case? If so, is this branch up-to-date?
[16:47] <gary_poster> gmb, it is not up to date
[16:47] <gmb> Ah.
[16:47] <gary_poster> that work is being done in a separate branch
[16:47] <gmb> Ok. Works for me.
[16:47] <gary_poster> cool
[16:54] <gary_poster> bac, I'm going to go lunch.  Should I start the milestone when I return?
[16:54] <gary_poster> I don't have a lot of time actually
[16:55] <gary_poster> But I might be able to get it done.
[16:55] <gary_poster> (before tomorrow I mean)
[16:55] <gary_poster> ...back in about an hour
[18:07]  * gmb -> afk for a while; about half way through the mega review and in need of a brain break
[18:31] <bac> gary_poster: chat?
[18:32] <gary_poster> bac, we have an emergency that we are on the hook for: bug emails are not going out.  I'm trying to do a bit of investigation.  will be ready in a few.  s'ok
[18:32] <gary_poster> ?
[18:33] <bac> gary_poster: np, ping me when ready
[18:33] <gary_poster> thanks will do
[18:55] <benji> gary_poster: FYI, I just got some bug mail.
[18:56] <gary_poster> benji, cool, from how long ago?
[18:58] <benji> gary_poster: it's hard to say, but Leonard just commented on the bug 5 minutes ago (but that comment wasn't incldued in the mail)
[19:00] <benji> gary_poster: it seems that teh email was sent as a result of marking the bug fix released at 2011-03-24 18:50:04
[19:01] <benji> (which was about 10 minutes ago)
[19:02] <gary_poster> benji thanks
[19:30] <benji> gary_poster: I figure you've seen these emails, but just in case: "The script 'send-bug-notifications' didn't run on 'loganberry' between 2011-03-24 18:07:04 and 2011-03-24 19:07:04 (last seen 2011-03-24 15:55:20.954998)"
[19:30] <gary_poster> yeah, thanks benji.  the odd thing is that it did run then :-/
[19:30] <gary_poster> according to the log
[19:31] <benji> hmm
[19:31] <benji> does "didn't run" mean ran but had a non-zero exit value?
[19:31] <gary_poster> not sure
[19:36] <benji> hmm, maybe there is a watchdog process that has expectations about when scripts should run and it somehow tracks when they run (through log files?)
[20:15] <gary_poster> benji, call soon :-P
[22:08] <gmb> gary_poster: Around?
[22:08] <gary_poster> gmb, sadly, yes :-)
[22:08] <gmb> gary_poster: Heh. It's 22:08 local time, so I feel your pain.
[22:09] <gary_poster> yeah, you have it worse, def :-)
[22:09] <gmb> Anyway, the accordion client branch (1) is r=me but needs some work before it lands. I don't think any changes will be massive, but if they are someone else can easily add a review vote; I didn't want it to be blocked on me whilst I'm away.
[22:11] <gary_poster> gmb, sounds good, and reasonable
[22:11] <gary_poster> thank you gmb
[22:11] <gmb> np
[22:11] <gary_poster> have a good night and a nice few days
[22:12] <gmb> Thanks; I will.
[22:12]  * gmb leaves.
[22:12] <gary_poster> :-)


 I guess it is afternoon.
[18:26] <teddy-dbear> yep


[03:56] <pitti> Bonjour tout le monde
[05:20] <czajkowski> aloha
[05:35] <Mirv> hello czajkowski
[06:47] <jibel> Good morning
[06:59] <Mirv> hello jibel
[07:05] <jibel> Hey Mirv
[08:03] <Laney> hallo
[08:07] <didrocks> ok, after 2 hours just being connected to other IRC network and looking at emails, I found that IRC was weirdly too quiet. Seems I didn't join freenode :p
[08:08] <Laney> a great ping avoidance tactic there
[08:10] <czajkowski> didrocks: lol
[08:10] <czajkowski> one way to get some work done to be fair
[08:11] <BigWhale> Greetings everyone. After a long absence, I just wanted to say that you guys rock. Now, move along, nothing to see here. :)
[08:12] <didrocks> czajkowski: it clearly worked! :)
[08:16] <czajkowski> Laney: I haz pug! !
[08:16] <mlankhorst> grr, morning
[08:19] <Laney> czajkowski: I saw the picture!
[08:19] <Laney> cuuuuuuute
[08:19] <Laney> mlankhorst: how's the jet lag?
[08:19] <mlankhorst> not bad :P
[08:19] <mlankhorst> I think
[08:19] <mlankhorst> only just woke up though
[08:24] <bdrung> good morning. :)
[08:29] <Mirv> haha didrocks, I thought you just wanted radio silence until worked through emails
[08:29] <didrocks> Mirv: well, was a nice consequence but wasn't intended ;)
[09:33] <Sweetshark_away> Bonjours a tous! Just a note, I am conferencing this week so expect latency ...
[12:23] <desrt> Laney: hey
[12:56] <Saviq> desrt, larsu bounced to you:
 larsu, so, we need multiple sets of values for "infographic palettes"
[12:56] <Saviq>  larsu, so that would be palette1/foreground palette1/background etc.
[12:56] <Saviq>  larsu, would relocatable dconf schemas be a good way to store those in dconf?
[12:56] <Saviq>  larsu, question no. 2 - to iterate over those, should they just all be stored under a common path, so, say /com/canonical/infographic/palettes/{palette1,palette2} etc.?
[12:56] <Saviq>  and if so, do we need a *list* of those paths stored somewhere, or would iterating over /com/canonical/infographic/palettes/'s children be enough
[12:57] <larsu> desrt: ^^
[12:57] <larsu> how does gnome-terminal store profiles?
[12:57] <desrt> we want to allow the user to set their own palette for infographics?
[12:57] <desrt> seems a bit.... excessive
[12:58] <desrt> why can't we just pick a good palette?
[12:58] <Saviq> desrt, impossible
[12:58] <desrt> (and maybe another one for the low-vision theme)
[12:58] <Saviq> desrt, for different backgrounds
[12:58] <Saviq> desrt, more over, we need those to be oem / operator-overridable
[12:59] <desrt> ah.  a question of branding.
[12:59] <larsu> personally, I'd go with a dictionary or array
[12:59] <Saviq> desrt, yeah
[12:59] <desrt> okay.
[12:59] <desrt> oem overrides ~= gsettings overrides
[12:59] <desrt> user ~= gsettings
[12:59] <desrt> er.  ~= dconf
[12:59] <desrt> but i sort of agree with larsu here.... having an entire schema to describe a palette seems to be overkill
[13:00] <desrt> seems more like you should have a single array of colour names ('as')
[13:00] <Saviq> desrt, that'd have to be an array of arrays
[13:00] <Saviq> desrt, as we need to have multiple palettes "active" at a time, to choose from
[13:00] <desrt> because you want multiple palettes, user-selectable?
[13:01] <Saviq> desrt, so it's not about selecting a *single* palette, but a *set* of palettes
[13:01] <desrt> what is the choice criteria between the palettes?
[13:01] <Saviq> desrt, from which we'll then choose runtime
[13:01] <Saviq> based on wallpaper / infographic source / whatever
[13:01] <desrt> that's not really saying very much
[13:01] <desrt> how do i decide between palette 0 and 1 based on wallpaper?
[13:02] <desrt> the brightness of the wallpaper?
[13:02] <Saviq> desrt, average color and stuff - we'll need algorithms for that
[13:02] <desrt> representative colours?
[13:02] <desrt> okay... but say i know the average colour for the wallpaper (and we already have an algorithm for that, btw)... how do i turn that into a choice of palette?
[13:02] <desrt> go through the list and see which is a 'best fit'?
[13:02] <Saviq> desrt, yeah, something like that - and then the user should be able to override, if the algorithm barfs
[13:03] <desrt> okay.  this is not a setting.
[13:03] <desrt> this is data.
[13:03] <Saviq> desrt, I agree
[13:03] <Saviq> pete-woods, ↑ input?
[13:03] <desrt> the setting, if any, is that there should be a "palette name" (string?) setting that the user can set
[13:03] <desrt> the palette colours themselves should not be stored in gsettings, i think
[13:04] <desrt> gsettings is not really meant to be an oem override management system -- it's meant to be for settings that the user might actually want to set
[13:04] <pete-woods> Saviq: I have no particular need for the palettes to be configured through dconf, but I was requested to read them from there, so that's what I'm trying to do
[13:04] <desrt> there are lots of other (more boring and appropriate) ways to allow oem overrides
[13:05] <larsu> there's also a widely recognized format for storing palettes (all the drawing programs use it). It's a very simple text file
[13:05] <desrt> this sounds much better
[13:06] <Saviq> larsu, desrt yeah, I was leaning towards some ini-file-style palettes, and only storing the path to them in gsettings
[13:06] <desrt> Saviq: store the basename
[13:06] <Saviq> yes
[13:06] <Saviq> that
[13:06] <larsu> Saviq: right. I'd go with the name, though, and have the path be something static
[13:06] <larsu> ah. okay
[13:06] <desrt> Saviq: then you can do a gsettings override for the default name, if you like
[13:06]  * larsu has too much irc lag
[13:06] <Saviq> XDG_DATA_DIR
[13:06] <Saviq> FTW
[13:07] <larsu> \o/
[13:07] <desrt> XDG_DATA_DIRS/palettes/[basename].ext
[13:07] <desrt> or whatever
[13:07] <larsu> err, unity-palettes
[13:07] <Saviq> pete-woods, what do you say?
[13:07] <pete-woods> Saviq: that sounds sensible enough to me
[13:10] <mterry> robru_, so...  any luck poking around for an answer to the ubuntu-sdk / qtaudioengine question?
[13:19] <attente> alberts, hey
[13:20] <attente> i'm running flashback right now but can't seem to replicate the problem
[13:20] <alberts> attente: hey. what problem?
[13:20] <attente> with the indicators getting mashed up with the app menu
[13:21] <attente> also the *v* problem seems to be a transcription problem
[13:21] <attente> i'm guessing he meant just v, but then again i don't know what value v is supposed to be
[13:21] <attente> same problem there
[13:23] <alberts> attente: I will try install ubuntu and test app menu myself.
[13:26] <alberts> attente: but that line now is causing error. isn't it better to revert that line?
[13:27] <attente> alberts, i think so
[13:27] <attente> i think it should use a new MP though
[14:07] <bjf> bug or feature? in recent saucy update:  i'm no longer able to set my 'caps lock' to 'ctrl' with: dconf write /org/gnome/libgnomekbd/keyboard/options "['ctrl\tctrl:nocaps']"
[14:07] <bjf> is there a new way to do this?
[14:37] <alberts> attente: how did you test indicator-applet problem? I added comment on merge proposal.
[14:41] <attente> alberts, i tested it and everything seemed fine
[14:41] <attente> but i guess there's something wrong on my end if it's broken from a clean daily build
[14:42] <alberts> attente, you tested on saucy, right? in gnome flashback session?
[14:42] <attente> alberts, is there something i need to do other than logging into the flashback session?
[14:42] <attente> alberts, yes
[14:44] <alberts> attente: yes. 1) you need install indicator-applet, indicator-applet-appmenu, indicator-session as they are not installed by default. Than you have to add for example indicator-applet-session or indicator-applet-appmenu or indicator-applet to panel.
[14:45] <alberts> without fix indicator applet session will load other indicators too, but it should load only session indicator.
[14:46] <alberts> same thing is reported against indicator-applet-appmenu, but i cannot test it es appmenu does not work on my real install nor on virtualbox.
[14:47] <attente> alberts, ok, i'll give it a try now
[14:56] <attente> alberts, how do you modify the panel?
[14:58] <alberts> attente: Win + Alt + Right click on the panel
[14:59] <attente> alberts, oh wow, that definitely broke something...
[15:00] <attente> the act of just adding something to the panel seems to just clear the entire thing
[15:01] <alberts> attente: no, it is because of indicator-applet-appmenu.
[15:01] <alberts> kill indicator-applet-appmenu process
[15:01] <alberts> i would suggest to test that bug with indicator-applet-session
[15:02] <attente> ok
[15:05] <attente> ok, alberts, i'll test your branch right now
[15:14] <bjf> in saucy, where did the "Keyboard Layout Options" dialog go to?
[15:14] <alberts> attente: seems that indicator-applet-appmenu does not work because of libappmenu.so (appmenu indicator?)
[15:15] <alberts> CRITICAL: Gtk - gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed
[15:15] <alberts> WARNING: Gtk - gtk_menu_attach_to_widget(): menu already attached to GtkModelMenuItem
[15:15] <attente> alberts, yeah, i can't seem to get it working properly
[15:16] <attente> even adding the session indicator doesn't seem to appear
[15:16] <alberts> Maybe it does not work only on x64. That could explain why it worked for bug reporter
[15:17] <alberts> did you kill indicator-applet-appmenu process?
[15:17] <attente> i did, but it seems to be running again
[15:17] <attente> ah, there we go
[15:17] <attente> session indicator is back :)
[15:20] <alberts> are you testing my branch now? if yes, you should see only session indicator. if no, than you will see session indicator + other indicators.
[15:25] <attente> alberts, yep, it seems to work fine
[15:25] <attente> i guess that appmenu indicator is a totally different bug though
[15:26] <alberts> attente: yes, i think it is different but too
[15:29] <attente> ok alberts, going to check one more time with the old version to make sure we don't have a regression
[15:29] <alberts> attente: ok. :)
[15:44] <attente> alberts, looks good :)
[15:49] <Laney> pitti: hello! got a minute for timedated? :P
[15:50] <Laney> We just found out in #ubuntu-touch that it relies on using temporary files for atomic symlinks/writes to update the timezone and this breaks in unfortunate ways on the ro phone images
[15:59] <Laney> pitti: cjwatson's suggestion is to symlink it instead to a symlink in a writeable directory somewhere and do manipulations in there
[15:59] <Laney> Requires probably un-upstreamable code changes though
[16:05] <tedg> desrt, Did your patch to "crash" on criticals land in GLib?
[16:06] <alberts> attente: thanks for approving. :) who can approve merge proposals in ubuntu-themes? i would love to see approved and merged your branches.
[16:10] <attente> alberts, np! i'm not sure about themes, maybe xnox?
[16:58] <jasoncwarner> Laney attente didrocks fyi, lightdm was supposed to land today, but a test failed so might not, but we should be ready for it tomorrow
[16:59] <jasoncwarner> attente will all your language settings just work when lightdm lands?
[16:59] <Laney> w-o-w
[16:59] <didrocks> jasoncwarner: ok, thanks for the info!
[16:59] <jasoncwarner> Laney I'd love if that timedate was ready to go when it landed ;)
[16:59]  * jasoncwarner fingers crossed!
[16:59] <Laney> larsu: I think I'm an idiot because I can't get the bluetooth-enabled action to change state even with the new i-bluetooth
[17:00] <blkperl> so bug 1213744 has completely broken thunderbird on my lab of ubuntu machines, is there going to be a fix soon?
[17:00] <Laney> I'm trying actiongroup.enabled.activate(false) but no-oooo
[17:00] <Laney> jasoncwarner: ya, me too; hoping pitti has some wisdom there tomorrow
[17:01] <larsu> Laney: leave out the "false", that action doesn't have a parameter
[17:01] <jasoncwarner> thanks, Laney
[17:02] <Laney> larsu: If I activate it without a parameter the state doesn't change either. :-/
[17:02] <Laney> code comin' up
[17:03] <larsu> Laney: ya, this is the bug in i-power that charles' branch fixes
[17:03] <Laney> no I installed that
[17:03] <larsu> oh, then it might be a bug in qml, I haven't tested that yet
[17:03] <larsu> s/qml/qmenumodel
[17:03] <Laney> hrhr
[17:03] <Laney> well, maybe it's a problem with me
[17:04] <alberts> who knows why there is no network indicator icon in gnome-session-flashback?
[17:04] <Laney> http://paste.ubuntu.com/6146339/
[17:04] <larsu> Laney: does the state change with `gdbus call --session --dest com.canonical.indicator.bluetooth --object-path /com/canonical/indicator/bluetooth --method org.gtk.Actions.Activate bluetooth-enabled [] {}`?
[17:05] <Laney> nein
[17:05] <Laney> maybe that indicates I didn't install it correctly
[17:05] <larsu> Laney: note that there's also still a bug in g-c-c. The switch behaves weirdly
[17:05] <larsu> and sometimes resets the state
[17:05]  * Laney nods
[17:06] <Laney> I haven't been using that though
[17:06] <larsu> hm, weird
[17:06] <Laney> give me a second
[17:08] <attente> jasoncwarner, is this the phone? because the MP still hasn't been merged yet...
[17:09] <Laney> I'm just approving that!
[17:10] <attente> oh. ha, thanks Laney :)
[17:13] <alberts> attente: why ps-jenkins failed approve merge proposal for indicator-applet?
[17:14] <attente> alberts, not sure, it just says there's a problem with the GPG signature
[17:14] <Laney> attente: Maybe not; missing whatever Depends to provide com.canonical.keyboard.maliit
[17:17] <Laney> larsu: got the new one with the patch from charles now and it still doesn't toggle unfortunately :(
[17:17] <attente> Laney, sorry, the branch that provides that hasn't been merged into the ubuntu-keyboard
[17:17] <Laney> attente: ah, well that'll be needed then
[17:17] <Laney> apply ze pressure
[17:17] <charles> I don't think the change to i-bluetooth is the problem
[17:18] <attente> Laney, sure :)
[17:18] <Laney> I got the impression that the activating it from gdbus worked for larsu but maybe not
[17:18] <larsu> Laney: yes, it does work for me. What does `gdbus call --session --dest  com.canonical.indicator.bluetooth --object-path /com/canonical/indicator/bluetooth --method  org.gtk.Actions.Activate bluetooth-enabled
[17:18] <larsu> oops
[17:19] <larsu> wrong copy/paste
[17:19] <larsu> what does all of that above with s/Activate/Describe return?
[17:19] <Laney> ((true, signature '', [<true>]),)
[17:20] <larsu> okay, so bluetooth is on for you right now?
[17:20] <larsu> (last member of that tuple is the state)
[17:20] <Laney> yeah
[17:20] <larsu> and if you now call Activate, does that return any error?
[17:20] <larsu> of not, what des Describe return after calling Activate?
[17:20] <alberts> attente: and what next? now it says needs review...
[17:21] <Laney> oh, hang on
[17:22] <Laney> I was accidently calling it over ssh
[17:22] <Laney> to my desktop which doesn't have bt hardware
[17:22] <attente> alberts, i'm not sure, i think it's just a hiccough with jenkins
[17:22] <jasoncwarner> attente: yes, the phone. what is holding up the MP from being merged?
[17:22] <jasoncwarner> oh, didn't see laney was on that.
[17:23] <Laney> seems to work on my laptop with old i-bluetooth
[17:23] <Laney> so with no hardware you can try to activate the action but it'll never change
[17:24] <larsu> sounds like a bug :)
[17:24] <larsu> charles: ^^
[17:25] <charles> Laney, is /dev/rfkill writable on your system?
[17:25] <Laney> my user has an rw acl
[17:25] <charles> k
[17:26] <Laney> anyway, yay; it seems to work on my laptop
[17:26] <larsu> \o/
[17:26] <jasoncwarner> attente didn't quite follow the thread, will the language and keyboard settings be ready when lightdm lands tomorrowish?
[17:28] <Laney> nice, seems to hide correctly too
[17:29] <Laney> will MP that tomorrow if location works as well and it works on the device
[17:29] <Laney> jasoncwarner: attente said it's waiting for a branch to get merged into ubuntu-keyboard
[17:29] <jasoncwarner> didrocks slangasek says the download service should land tomorrow. can you get with him and barry etc to know what we would need to do to update the updater?
[17:29] <attente> jasoncwarner, i don't think it will...
[17:29] <jasoncwarner> Laney attente is there a specific branch? i'll start poking people
[17:30] <attente> jasoncwarner, it's this one: https://code.launchpad.net/~attente/ubuntu-keyboard/gsettings-schema/+merge/185121
[17:30] <attente> but the problem is, if it hasn't been merged yet, i doubt those settings are being used by maliit
[17:30]  * Laney is off for now, see you
[17:31] <jasoncwarner> attente who needs to merge it?
[17:31] <attente> jasoncwarner, tmoenicke
[17:34] <charles> https://code.launchpad.net/~charlesk/ubuntu-system-settings/bluetooth-plugin/+merge/186957 is finally passing jenkins
[17:34] <charles> who has a headset s.t. they can do a full review? :)
[17:35] <charles> Laney did a good partial review wrt code inspection
[17:37] <attente> alberts, i'll see if i can trigger a rebuild
[17:37] <alberts> attente: ok, thanks!
[17:43] <attente> alberts, sorry, looks like i can't do it myself, we'll have to look for someone else to do it :(
[17:46] <alberts> attente: do you know who can do it? I am new here, so I don't know anyone.
[18:04] <bjf> in saucy, where did the "Keyboard Layout Options" dialog go to?
[18:28] <robru_> mterry, no, haven't heard from zoltan
[18:28] <mterry> robru_, I poked him in #ubuntu-touch earlier, he didn't reply
[18:29] <robru_> mterry, today? bah. quite the vacation!
[18:29] <ogra_> i see him talking in ci-eng
[18:30] <robru_> mterry, which bug was it again?
[18:30] <robru_> mterry, actually I just got his attention in #canonical
[20:36] <attente> fginther, hi, do you know who can trigger a rebuild of this? https://jenkins.qa.ubuntu.com/job/indicator-applet-saucy-amd64-autolanding/7/console
[20:37] <fginther> attente, if you re-approve the merge proposal, it will re-run.
[20:37] <attente> fginther, oh, ok, thanks!
[20:56] <dupondje> Any idea's why my cursor would keep blinking when something redraws (its very noticable when playing audio in audacious).
[20:56] <dupondje> Known bug in Saucy ?
[23:46] <bjf> in saucy, where did the "Keyboard Layout Options" dialog go to?


[02:14] <bryce> tjaalton, http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package-status.html
[02:43] <Sarvatt> and of course fglrx-installer-experimental-9 failed to build on amd64 for quantal and raring, something to fix up tomorrow in my favorite package ever
[02:47] <Sarvatt> at least fglrx-installer-experimental-9 isn't as retarded as nvidia-experimental-310 they already abandoned and moved on to nvidia-experimental-313. whoever thought versioned -experimental packages were ok was silly :)
[02:48]  * ScottK waves to Sarvatt.
[02:48] <Sarvatt> there are going to be at least 10 packages to maintain in every previous release by 14.04, tseliot doesn't scale that well :(
[02:50] <Sarvatt> maybe if we dont forward port anything but the newest one when the next dev release opens
[02:51] <Sarvatt> there is going to be bugs about experimental-310 not working with the X abi in 13.04, that will never be fixed because nvidia made 313 to work with that (hypothetical, 315 or whatever wil be the one supporting xserver 1.14)
[02:54] <ScottK> Sounds like "fun"
[02:57] <bjsnider> Sarvatt, are you complaining about amd and nvidia again?
[02:57] <bjsnider> they make good stuff
[02:57] <bjsnider> really good stuff
[02:58] <Sarvatt> nah amd is fine, fglrx-installer-backports-9 will cover an entire years worth of updates
[02:58] <Sarvatt> its just nvidia already gave up on 310 and there wont be more, its 313 now, probably something else valve needs next :)
[02:59] <Sarvatt> fglrx-installer-backports-9 means everything from 2012, nvidia revs the version every other month but the old ones need to work but dont get updated :)
[03:00] <bjsnider> keeping up with the updates would be a full-time job
[03:00] <bjsnider> do they still have the long-lived release too?
[03:00] <Sarvatt> i'm just hoping nvidia-experimental-310 doesn't get copied to 13.10, its already irrelevant
[05:31] <tjaalton> bryce: ah, nice
[13:58] <mlankhorst> ok looks like I got synchronization to not hang up completely at least :P
[13:59] <tjaalton> btw, isn't it true that 13.04 will be quite boring hybrid-wise?
[13:59] <tjaalton> just like xserver 1.14 will be
[14:06] <mlankhorst> true
[14:06] <mlankhorst> vblanking is impossible to do cross-device right now for example
[18:41] <bryce> Sarvatt, plan is -310 users will get moved to nvidia-current on upgrade to 13.10
[19:28] <mlankhorst> shoo, go vacation
[20:16] <bryce> mlankhorst, heh yep you're right