[00:00] slangasek: http://pastebin.ubuntu.com/352031/ [00:01] kirkland: line 7 is invalid [00:01] you can't have random shell syntax outside of a 'script' block :) [00:02] slangasek: if i put that in pre-start, will the result of that shell script sourcing (variables/values) be available to the exec? [00:02] nope [00:02] slangasek: bing [00:02] (not AFAIK) - so you'd have to duplicate the line [00:03] OTOH, I don't think your pre-start script depends on the contents of that file :) [00:03] so what you want is: [00:03] script [00:03] [ -f /etc/default/libvirt-bin ] && . /etc/default/libvirt-bin || true [00:03] exec /usr/sbin/libvirtd $libvirtd_opts [00:04] end script [00:04] slangasek: bingo! [00:04] slangasek: works like a champ [00:05] slangasek: thanks, as usual ;-) [00:05] slangasek: one last question [00:06] slangasek: i'm trying to figure out the correct "start on" req's [00:07] ok [00:07] slangasek: the init script says: http://pastebin.ubuntu.com/352034/ [00:07] slangasek: i'd like to learn the translation between those two pieces [00:07] I think 'start on runlevel [2345]' is simplest [00:08] and 'stop on runlevel [!2345]' [00:08] slangasek: so i don't need to account for required-start $network $local_fs ? [00:08] (c.f atd, dmesg, apport...) [00:08] no, those are guaranteed to be up before the runlevel is declared [00:09] slangasek: is the stop on explicitly required? [00:10] slangasek: and why the "45"? we haven't been putting those in our other upstart jobs [00:10] slangasek: usually we've been doing start on [23] [00:10] the 'stop on' prevents the job from continuing to respawn after killall5 has been called on shutdown [00:10] slangasek: hmm, okay [00:10] "why the 45" - because that's always been the default, and maps precisely to your existing 'Default-Start' line [00:10] slangasek: again, the eucalyptus ones lack that currently; would it be nice to add them? [00:11] I don't know why anyone would be creating jobs that only start in runlevels 2 and 3; yes, eucalyptus ought to have that added [00:11] slangasek: okay, i'll fix [00:11] strange, /etc/init/tty[23456].conf are 'start on runlevel [23]' [00:11] slangasek: yeah, i'm grepping the others right now [00:12] * kirkland mulls an "alias" for 2345 ... [00:21] does anything need to be done to promote libtdb-dev to main? [00:21] (i.e., currently causing pulseaudio to FTBFS) [00:23] crimsun: I thought tdb was in main? [00:26] libtdb-dev is a new binary package that has landed in universe. [00:29] If it belongs to a source package in main, then its just a matter for an archive admin to promote the binary afaik. [00:30] it needs someone to process http://people.canonical.com/~ubuntu-archive/component-mismatches.txt === kirkland` is now known as kirkland [01:56] slangasek: would it be possible to permanently reschedule the server ISO builds for about 4 hours from now? [01:57] slangasek: thats just about the perfect time to pick up western US changes [01:57] slangasek: and build them in time for our earliest Euro team members [01:57] cjwatson: I suspect you might be able to answer that too ^ [01:58] I don't see any reason we could'nt [01:58] couldn't === cjwatson_ is now known as cjwatson [02:00] fine by me [03:05] Sigh, Bug #501559 is still kicking my butt. [03:05] Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559 [03:06] There's so many differences between the older behaviour with forkpty, and the newer behavior. === vorian_ is now known as stalcup === stalcup is now known as v [04:09] /c/c === asac_ is now known as asac [05:06] are we still no-go on source v3.0 uploads? [05:09] I thought we were go for 3.0 as of a couple of days before Christmas? [07:19] Good morning [07:20] pitti: Good morning [07:21] pitti: I could use a server CD respin, the one that spinned two hours ago unfortunately didn't catch eucalyptus 1.6.2~bzr1120-0ubuntu3 [07:21] kirkland: I guess we need a larger safety margin between upload and respin at the end of your day [07:21] ttx: triggered [07:21] pitti: thx === cdE|Woozy_ is now known as cdE|Woozy [07:51] cody-somerville: btw, yesterday I changed hal to get dbus activated instead of launched by upstart; if hal doesn't work with Xubuntu any more, I'm to blame (please ping me) [07:59] good morning [08:03] pitti: beh, the new respin still hasn't caught the latest. Investigating [08:04] pitti: is there a lag between publication and cd-builder archive sync ? [08:04] shouldn't be much [08:04] if it's on archive.u.c., antimony should see it, too [08:04] 1.6.2~bzr1120-0ubuntu3 has been published an hour ago. [08:04] * ttx checks up archive [08:04] (antimony uses ftpmaster.internal) [08:05] archive has it since 0704 UTC [08:05] you triggered at 0721 [08:05] weird [08:06] ttx: what's that package? [08:06] pitti: eucalyptus -- http://archive.ubuntu.com/ubuntu/pool/main/e/eucalyptus/ [08:06] I need 1.6.2~bzr1120-0ubuntu3 for testing [08:09] ttx: hm, indeed cdimage@antimony:/srv/cdimage.ubuntu.com/ftp/pool/main/e/eucalyptus only has ubuntu2 [08:10] 2010-01-06 07:13 Packages.gz [08:11] (it's 08:10 on antimony) [08:11] ttx: I'll watch this, and when the next sync happens in 2 mins, I'll verify euca again and retrigger [08:11] pitti, it certainly broke launching ubiquity in an xfce env (lack of hal), but i think http://pastebin.com/f473910b2 will handle this [08:11] pitti: hm, the lag makes asking for a CD respin a little guesswork :) [08:11] pitti: cool, thanks [08:12] superm1: oh, it doesn't get dbus launched for you? [08:12] pitti, not when hal-lock is ran [08:12] superm1: ah, I see; for some reason "lshal" doesn't trigger it either [08:13] lshal and hal-device (and I suppose hal-lock) has an extra check if it's running [08:13] pitti: scripting the famous "trigger on antimony-publication slangasek magic" could help here. Somethign like "trigger-cd-on-publication server eucalyptus_1.6.2~bzr1120-0ubuntu3" would make your life easier :) [08:14] pitti, well up to you whether you want to patch that behavior out, or if just a pgrep for hald is sufficient (i mean hal-lock shouldn't need to be ran if hal isn't running in the first place!) [08:15] superm1: not sure; if you are okay with the pgrep, that works for me [08:16] pitti, yeah i think that's the easiest solution for now, will commit it to ubiquity bzr then [08:16] something else weird is going on with that gtk+ upload from yesterday though [08:17] ubiquity uses setattr to make widgets callable at the top level, and that appears to have broken for some reason [08:20] hi. when is the calm hours of Launchpad build farm for PPAs? I dont want to wait an hour! [08:27] ttx: hm, I don't know what's going on; it didn't update at all now [08:28] pitti: hm [08:36] didrocks, StevenK: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-une has one remaining work item "Rename ubuntu-netbook-remix{,-default-settings}" which is marked "in progress"; who is working on this? do you need any help with NEW, etc.? [08:38] pitti: Right, so the only thing remaining is removal of u-n-r-d-s, which I'm still thinking about. [08:38] StevenK: oh, I don't see a replacement u-n-d-s? [08:39] or is that entirely obsolete now with didier's gdm changes to support an extra gconf tree? [08:39] ubuntu-netbook-default-settings | 0.7.0 | lucid | source, all [08:39] pitti: ^ ? [08:39] *cough* [08:39] Haha :-) [08:40] StevenK: note that I said "I don't see", not "it's not there" :) [08:40] pitti: Yes, so I brought it closer so you could see it. [08:40] Winning on purely semantic terms only gets half-credit [08:40] Awwww [08:40] * StevenK goes to cook dinner [08:40] sweet, thanks [08:40] StevenK: enjoy! [08:41] StevenK: Why not drop u-n-r-d-s, and have u-n-d-s provide a dummy for transition? Shouldn't that improve the experience of karmic upgraders? [08:52] persia: that already happens [08:54] I had 2 system freezes with lucid in the last 2 weeks :( [08:55] pitti: Erm, does it? My lucid apt-cache doesn't show a dummy u-n-r-d-s from the u-n-d-s source, just a Replace/Conflict against u-n-r-d-s by u-n-d-s. I also still see in lucid a u-n-r package depending on u-n-r-d-s, and a separate u-n package dependsing on u-n-d-s. [08:56] persia: right, u-n-d-s should build a transition package [08:56] That was the suggestion :) [08:56] right, misunderstood you; sorry [08:56] Might make sense for netbook-meta to do so as well. [08:56] same with u-n-r vs. u-n [08:56] Right [09:30] superm1, hey [09:30] superm1, could you open this gtk bug upstream too? [09:30] hi seb128 [09:30] seb128, i think we have to adjust our code actually [09:30] it looks like a fundamental change upstream [09:30] I'm just reading it [09:30] it should be a one line fix for ubiquity it looks like [09:30] but if you read the bug referenced in the commit they say some software are using buggy assumptions [09:31] which bug is that? [09:31] right, what I was starting to think too [09:31] dholbach, bug #503710 [09:31] is it the reason why gtg crashes on startup? :) [09:31] Launchpad bug 503710 in mythbuntu-control-centre "updated gtk+2.0 package has problems referring to the name of widgets loaded from a builder UI file" [Undecided,Fix released] https://launchpad.net/bugs/503710 [09:31] dholbach, dunno, gtg could be buggy [09:31] I don't use it === charlie__ is now known as porthose [09:32] I guess it's something different: [09:32] ** [09:32] Gtk:ERROR:/build/buildd/gtk+2.0-2.19.2/gtk/gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree) [09:32] Aborted [09:32] seems a different issue from the assertion [09:32] ok ok [09:34] seb128, http://pastebin.com/f206651ca appears to fix it for ubiquity from what i just tested [09:34] superm1, good [09:34] thanks for looking into that one [09:35] so i'll do a ubiquity upload with thatso that live disks can be working again [09:46] seb128: the bug I had is bug 503576 (bug 503630 seems to be a dup) [09:46] Launchpad bug 503576 in seahorse "Seahorse fails to start with error Gtk:ERROR:/build/buildd/gtk+2.0-2.19.2/gtk/gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree) ) = 113 in Lucid" [Undecided,New] https://launchpad.net/bugs/503576 [09:46] Launchpad bug 503630 in synaptic "synaptic will not load" [Undecided,New] https://launchpad.net/bugs/503630 [09:47] ok [09:48] I don't know if it's a red herring, but in the case of gtg the last file to be opened is one of the DMZ cursors too (like in the seahorse bug I mentioned) [09:50] dunno [09:50] I will look at that in a bit I'm busy with a cairo fix right now [09:50] sure sure, no worries [10:15] jdstrand, kees: is apparmor_parser using cpu for ages on evince install in lucid a known issue? [10:16] we get some users ctrl-C-ing the install because they think it's stucked [10:22] james_w: why does bzr-builddeb -S require the build dependencies of a package? Can I override this with -d ? [10:24] tseliot: yes, but it's spelt "-- -d" currently [10:26] james_w: aah, ok, it makes sense. I'm about to make my 1st upload as a core-dev and I'm following the instructions from the DistributedDevelopment wiki page. Excellent work BTW. [10:27] thanks, let me know if there are any problems [10:28] sure [10:29] and feel free to improve the documentation if you find any areas that are lacking [10:30] could somebody process the new libssl0.9.8-udeb in NEW? it should end up in main [10:31] it's for a bug that the server guys wanted fixed [10:31] apw: I'm currently working on reorganizing the work items tracker and DB, so that I don't need a million cron jobs and to parse each spec three times (it'll get more hairy once we get to alpha-3) [10:32] apw: right now, your wiki-status.py directly parses the original data again [10:32] apw: would you mind taking a look at http://paste.ubuntu.com/352238/ and check if this structure has everything you need? [10:33] apw: then wiki-status.py could get the data from the db, and we'd have a clear separation of data collection and report generation (I plan to split the thing into "collect", "html-report", "wiki-report", and "burndown-chart" [10:33] cjwatson: looking [10:33] pitti, can i tell what is current with that form? or would you assume i am dropping the db each time for my use case [10:34] apw: yes, the HTML report generator already does that [10:34] cirtainly have no objection to the underlying desire [10:34] apw: SELECT max(date) FROM work_items [10:35] apw: and then SELECT ... WHERE date == (result from above) [10:35] ok, fair enough. one assumes in the furture this thing will come inhouse, and start generating all the wiki pages for us [10:35] apw: the idea is to reduce the millions of DBs that I have (foundations-lucid-a2-workitems.db, global-lucid-workitems.db, etc.) [10:36] apw: into one "lucid.db" which knows about teams and milestones, and everything else that we need [10:36] my server would then regenerate this every hour (which is then doable; parsing the stuff ten times for all teams is too much for hourly processing) [10:36] and since the .db is publicly available, you can then also run scripts locally on it [10:37] apw: in fact, this data collection doesn't need all the pychart stuff, etc., so this could run on rookery [10:37] apw: (another reason why I want to split the programs) [10:37] then everyone could configure the collection on rookery [10:37] and I'd just need to run the burndown chart generation on my server [10:38] pitti, yep all sounds reasonable. one thing to consider (and i think this is a global wrongness) is that rather than assuming that a group owns just the specs which are in its team [10:38] dholbach, gtk fix uploaded, I verfied it fixes gtg and seahorse [10:38] is that actually a team owns all the work for its members, i fake that by adding items from other teams specs which are assigned to 'my' team people [10:39] but it would be nice to be able to do that in generally [10:39] apw: in http://paste.ubuntu.com/352238/ the concept is that a spec is owned by a team, but a work item is owned by a person (or a team), which is not necessarily the same team as the spec [10:39] apw: ah, that's a good point [10:39] yeah i think the data allows it, and if we want to do that generally it should be easy in all reports if we have a team to people mapping [10:40] apw: it's next to impossible right now with split DBs; but if it's all in one DB, this is much easier indeed [10:40] apw: but in fact I think you are right [10:40] but i think the format as it is does not preclude the change as a step 2 [10:40] apw: instead of having a "team" entry in the spec_info table, I think we should rather have a "teams" table which maps people to a team [10:41] then a report for the "desktop" team would collect all work items which are assigned to all people which are part of that team [10:41] instead of filtering the blueprints by team first and then by assignee (which is what we currently do) [10:42] there are two mental views, work for desktop, and work being done by desktop, i think our reports are the later indeed [10:42] (should be) [10:42] yeah i believe so [10:43] apw: well, I think I'll keep the "team" entry in spec_info, even if we don't want to use it; if we ever want to create such a report "by us, for us", it can come in handy [10:46] apw: so, does wiki-report.py collect any extra information which isn't represented in those two tables? [10:47] pitti, thinking [10:48] pitti, the only generic thing i have to invent over the data there, is a milestone ordering [10:49] pitti, oh we do use the description of the spec as a fallback for the status, but i guess you'd call that status in both cases [10:49] apw: yeah, I think that should be a matter of data collection [10:49] i. e. if there's no status we could just fill in the description as value for "status" [10:50] yeah, thats what i do, put 'Description: ' on the ftont and ram it in the same hole [10:51] so no i can't see anything on my page which isn't in there [10:52] seb128: you are a hero! [10:52] apw: http://paste.ubuntu.com/352248/ [10:52] apw: that provides milestone ordering, too [10:52] * seb128 hugs dholbach [10:53] * dholbach hugs seb128 back [10:53] pitti, should priority have a sortable numeric value, its main use it converted to a number for sorting as far as i can see [10:53] apw: (with the obvious omission in the work_items table fixed) [10:54] apw: hm, we get it as a string value only, and map it to a color [10:55] +def priority_value(name): [10:55] + if name == "Essential": [10:55] + return 99 [10:55] def priority_value(name): [10:55] ah [10:55] can this db do a function? then that would be fine represented as a function in the schema [10:57] apw: sqlite doesn't have a CREATE FUNCTION unfortunately [10:57] so priority -> value and priority->color mapping would need to be done in the report generator code [10:59] we can live with that [10:59] pitti, before you get hacking on it there are a couple of improveents sitting in my branch [10:59] they all look pretty self contained [11:01] mostly the stuff to fix the escaping to be correct [11:01] $ bzr merge lp:~apw/launchpad-work-items-tracker/wiki-status [11:01] yeah [11:01] "Nothing to do." [11:02] how long does LP take to update a branch once its pushed [11:02] on the webui, two or three minutes [11:02] but no delay at all if I use bzr+ssh:// to pull [11:03] pitti, i think i am being dumb, looks to be in ther [11:05] pitti, so let me know if there is anything i need to do in this conversion [11:07] apw: once I get the "collect" script rewritten, it's by and large to change wiki-status.py to use the DB instead of parsing the data again [11:07] however, that doesn't need to happen in lockstep [11:08] yeah [11:09] apw: I probably need to break the API slightly, though, due to the DB reorg [11:09] apw: but I'll develop it in a branch and only merge it once everything works again [11:17] james_w: it doesn't seem to be my lucky day: http://pastebin.ubuntu.com/352256/ [11:17] :-/ [11:18] tjaalton: "The topic for #launchpad is: LP DB security updates, possible intermittent outages 11:00-11:30 UTC" [11:18] sorry, tseliot ^ [11:18] pitti: oh, are you trying to say that launchpad doesn't hate me today :-P ? [11:19] tseliot: erg [11:19] tseliot: well, it hates everyone equally rather [11:19] ah [11:19] :-D [11:19] might warrant a launchpad bug anyway [11:19] pitti, seems reasonable, i can work against the other branch once its there [11:20] might be nice to say "LP is out for lunch, please come back later" [11:20] * tseliot nods === MacSlow is now known as MacSlow|lunch [11:56] I want to lock a file from a python process, I would like the lock to be exclusive and only exist as long as the process does, which type of lock has those semantics? [12:04] james_w: fcntl.flock(fd, fcntl.LOCK_EX), I think. [12:04] yeah, just found buried in the manpage the statement that they survive as long as the process, thanks === MacSlow|lunch is now known as MacSlow [12:30] pitti: the daily server CD wasn't produced at 1030 UTC as usual... what's the status ? Was antimony archive synced ? [12:31] 2010-01-06 10:18 Packages.gz [12:31] it's 12:31 on antimony [12:31] it seems to lag badly today for some reason [12:31] I think 10:18 should be alright... let me doublecheck [12:32] anyway, it does have ubuntu3 now [12:32] (just checked Packages.gz) [12:32] * pitti respins [12:32] ETA 10 mins [12:32] pitti: cool, thx [12:33] jiboumans,ttx: for RT#36737, can't you just boot the netboot installer with anna/choose_modules=eucalyptus-udeb? that should have much the same effect as the CD boot option [12:39] cjwatson: hmm, yes, that could take care of the "installed from UEC installer" feature testing... as we would test the ISO release deliverables as part of regular ISO testing anyway [12:39] cjwatson: iiuc that could also be used instead of triggering CD respins just to test new eucalyptus uploads ? [12:40] ttx: sure [12:41] interesting. /me tests [12:53] Nautilus, and the whole system/desktop/CPU gets eaten/stuck/froze when you browse a WebDAV directory. You should really do something. [12:58] Another serious thing: You cannot copy to a WebDAV directory. Copying... hangs forever. [12:58] WebDAV does not work at all. [12:59] with Nautilus [12:59] blame gvfs-backends [12:59] (the package) [12:59] and file a bug [12:59] that too [12:59] preferably upstream, or both [13:03] excuse me, I won't [13:04] I have already filed a bug or two about WebDAV and I got ignored [13:04] so I don't think it has much point [13:04] It is a bug in your Distro [13:04] I want to help, so I report a problem [13:05] if you want to make your distro usable, fix the bug [13:05] eh no, it's an upstream bug [13:05] Um, it's a bug in *both* places. [13:05] they don't care about webdav enough [13:05] (or it's not a bug) [13:05] amikrop: erm yes, you report a problem by filing a bug. is that really so hard? [13:05] persia: well, true [13:08] amikrop: bug reports are fixed by people who have interest in the problem. you're more likely to find people interested in fixing webdav support in the upstream (because even if ubuntu people fix it, the fix is going back upstream as well) [13:09] hyperair: how do I report an upstream bug? [13:09] because the whole system hangs and nothing works about webdav [13:09] amikrop: you have to identify the upstream bug tracker, and then file a bug there. [13:09] and I am forced to mount it via command line [13:09] mount.davfs [13:09] and not Connect server... [13:09] since as tjaalton mentioned, the problem lies in gvfs-backend, the bug tracker would be bugzilla.gnome.org [13:10] after that, if you can't fix the bug yourself, your only option is to be patient. [13:12] I want to say, it is not a favor made to the users [13:12] it is a favor made by the users [13:12] to report problems [13:13] it's both [13:13] I will report it there [13:58] seb128: gtk fix fixes it [13:59] dholbach, great [13:59] seb128: the reason for the breakage was very amusing :) [13:59] dholbach, ;-) [13:59] "ups" [13:59] yeah :) [14:18] seb128: re apparmor_parser> basically, yes. jjohansen is working on it and can give you the most up to date info [14:18] jdstrand, thanks [14:18] jjohansen, hey, is there any bug about apparmor_parser being sloooow? [14:18] we got users stopping the evince install because they think it's stucked [14:19] it seems to be apparmor eating cpu [14:19] yeah it can be, its in the dfa generation [14:19] I am working on some optimizations [14:20] do you have a bug about that or want one? [14:20] or you are working on it anyway and the bug is of no use? [14:20] seb128: no bug open yet, feel free to open one [14:20] I might just reassing the next evince bug we get about installation stucked ;-) [14:21] seb128: well it overlaps with a work item, but they are different [14:23] hey zul, do you mind if i merge rabbitmq-server from debian today? would you be available to review/upload the merge proposal? [14:23] statik: sure just ping me [14:23] awesome thanks [14:30] does anyone have a sample package that builds/installs upstarts scripts using a DEB_PYTHON_SYSTEM=pycentral stylely rules file? [14:31] kirkland: apport does [14:31] (the two have nothing in common, though) [14:31] python stuff is handled by dh_pycentral, while upstart scripts are handled by dh_installinit [14:32] pitti: cheers === robbiew_ is now known as robbiew [14:32] pitti: okay, so i just need a dh_installinit line then in the build? [14:32] by and large, yes [14:32] there are some caveats, like you need to specify --upstart-only if there is _also_ a debian/foo.init [14:33] (which is likely when a package is also in Debian and we don't want to remove the init script to reduce delta) [14:35] pitti: got it, thanks! [15:08] How does Ubuntu build install CDs? I'm looking for the process used by Ubuntu devs to build official CDs. [15:08] As a first step, I've found and learned how to use germinate which I beleive is part of the process to determine the packages needed [15:10] Re: http://forum.soft32.com/linux/Ubuntu-CD-Image-Build-System-ftopict502887.html [15:10] pitti: I can try to deal with fontconfig, yes [15:10] http://ubuntuforums.org/showthread.php?p=8563488 [15:10] etc... [15:11] Searches turn up little to nothing :-( [15:12] tweakt: 'bzr get lp:ubuntu-cdimage' and also check out the submodules in configs/devel [15:12] tweakt: then start with etc/crontab and follow references from there [15:13] tweakt: for live CDs, the livecd-rootfs package is also involved [15:15] thanks a bunch! [15:16] excuse my ignorance, the 'lp:' prefix is an automatic shortut for ubuntu servers, right? [15:16] mvo: Hey, still no love on Bug #501559. I dug into the code, and the non-forkpty way of doing things doesn't appear to handle stderr handling at all, and sabayon generates a lot of stderr output. [15:16] Launchpad bug 501559 in libgksu "libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL" [High,Confirmed] https://launchpad.net/bugs/501559 [15:16] launchpad... n/m [15:17] tweakt: it's implemented by bzr's launchpad plugin [15:17] see https://code.launchpad.net/ubuntu-cdimage for the equivalent in a web browser [15:18] the fix certainly works, and the BEST way to fix it would be to hack proper stderr handling into gksu for non forkpty [15:18] ahh, so it's debian-cd with ubuntu specific configs, excellent! [15:18] however, that's going to be some fairly major code work. [15:19] So, the $50 question of the day is: should we make some major changes to the code, but NOT have to have an extra --enable in rules, or do the --enable [15:20] I'm not sure from a policy perspective what cordev's want. [15:21] sbalneav: hm, the non-forkpty way is/was default in the past, I wonder why this is now becoming a problem? or is there something else that changed? [15:21] sbalneav: ie. does this work on karmic? [15:22] yeah, works fine on karmic [15:22] mvo: did your patch implement the same thing as the patch we used to have in karmic ? [15:22] sbalneav: oh, in this case please reopen the bug (or open a new one) with a example, I have a look then. what we have should behave the same as in karmic [15:23] sbalneav: sorry for that [15:23] mvo: that's the laughable part. I've spent 6 months beating sabayon into a useable state as a managment tool, going sofar as to become gnome upsteam on the project, and now at the last minute, I'm stalled by gksu :) [15:24] mvo: Not your fault, but when I looked at the code from the -12 version and the new -13 verson, my first (admittedly quick) impression was that forkpty's WERE being done by default. But I could be wrong. :( [15:27] sbalneav: I put a bit of background into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535544 - I may misrember, its was ~6 month ago that I worked on this particular bit [15:27] Debian bug 535544 in libgksu "libgksu 2.0.12 & tty_tickets does not match" [Normal,Fixed] [15:28] thanks, I'll look into that. [15:28] upstart question: any reason why this job (http://pastebin.ubuntu.com/352361/) would get stopped when ssh is stopped (right) but not get restarted when ssh is respawned (wrong) ? [15:29] i.e. I end up with a system where ssh and avahi-daemon are started, but this job isn't [15:29] mvo: here's the question: is it more desirable to actually make the code change, as a patch, than enable the option? Is this a "syncing from debian" thing? [15:30] ah, I see. [15:30] * sbalneav read 535544 [15:31] ok, well, if you'd like, I could dig into how to fix the stderr handling tonight. [15:31] * soren hugs mvo for tracking down a fix for bug 494627 [15:31] Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627 [15:33] sbalneav: that would be nice, it should be not too hard given that it worked fine in karmic. I will try to check it out later today when i find some time and if I find something interessting I will let you know on irc [15:34] soren: cheers! which fix do you use? the xserver-xorg-video-nv patch or one against the xserver itself? [15:34] mvo: I haven't actually tried any of them yet :) [15:35] mvo: ok, will do, I'll dig into it tonight. If you beat me to it, NP. Start your engines [15:35] I'll take the nv one for a spin in a few minutes (in the middle of a meeting). [15:35] * sbalneav makes vroom vroom sounds [15:37] soren: ok :) the nv one gave me funny colors (but only after a cold reboot), I believe the second one (comment #18) is the correct one, I'm currently waiting for upstream to comment [15:38] mvo: Sounds like fun. I've installed the package, I just need to find a good time to restart X. [15:53] slangasek: any clue for my upstart question from 30 minutes ago ? [15:53] mvo: *chuckle* Um, yeah, I see what you mean about the colours being slightly off :) [15:55] mvo, any idea why does "LANG=C software-center" produces mixed translated and english strings ? === BenC2 is now known as BenC [15:56] joaopinto: no, what is your default locale [15:57] pt_PT.UTF-8, my locale does show properly by default, I just wanted to check some original strings in english [15:57] soren: I can create packages in my PPA, basicly the patch for -nv needs to be reverted and http://launchpadlibrarian.net/37478080/crash_fix.patch added to xserver-xorg-core. that works for me [15:57] joaopinto: maybe its some oddness with webkit [15:58] joaopinto, use LANGUAGE=C software-center [15:59] seb128, same result, the menu is english, other piceses of the gui are random, english or native [16:00] ConfigParser.NoSectionError: No section: 'general' [16:00] what pieces? [16:00] argh, this is not fixed yet :P ? [16:00] software center crashes on exit [16:00] mvo: Don't waste time on it for me, if you're going to do things differently for Ubuntu proper. I can build those packages myself. [16:01] seb128, menu is english, on the right side bar, the "Get Software" tree is english, the "Installed Software" is portuguese [16:02] The "Categories" word is pt_pt, the category names are en_us [16:02] ok, dunno then [16:02] could be that some strings are coming from aptdaemon [16:02] buttons text is pt [16:02] and it's running on whatever local your session is [16:02] mvo, ^ [16:02]