| kirkland | slangasek: http://pastebin.ubuntu.com/352031/ | 00:00 |
|---|---|---|
| slangasek | kirkland: line 7 is invalid | 00:01 |
| slangasek | you can't have random shell syntax outside of a 'script' block :) | 00:01 |
| kirkland | 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 |
| slangasek | nope | 00:02 |
| kirkland | slangasek: bing | 00:02 |
| slangasek | (not AFAIK) - so you'd have to duplicate the line | 00:02 |
| slangasek | OTOH, I don't think your pre-start script depends on the contents of that file :) | 00:03 |
| slangasek | so what you want is: | 00:03 |
| slangasek | script | 00:03 |
| slangasek | [ -f /etc/default/libvirt-bin ] && . /etc/default/libvirt-bin || true | 00:03 |
| slangasek | exec /usr/sbin/libvirtd $libvirtd_opts | 00:03 |
| slangasek | end script | 00:04 |
| kirkland | slangasek: bingo! | 00:04 |
| kirkland | slangasek: works like a champ | 00:04 |
| kirkland | slangasek: thanks, as usual ;-) | 00:05 |
| kirkland | slangasek: one last question | 00:05 |
| kirkland | slangasek: i'm trying to figure out the correct "start on" req's | 00:06 |
| slangasek | ok | 00:07 |
| kirkland | slangasek: the init script says: http://pastebin.ubuntu.com/352034/ | 00:07 |
| kirkland | slangasek: i'd like to learn the translation between those two pieces | 00:07 |
| slangasek | I think 'start on runlevel [2345]' is simplest | 00:07 |
| slangasek | and 'stop on runlevel [!2345]' | 00:08 |
| kirkland | slangasek: so i don't need to account for required-start $network $local_fs ? | 00:08 |
| slangasek | (c.f atd, dmesg, apport...) | 00:08 |
| slangasek | no, those are guaranteed to be up before the runlevel is declared | 00:08 |
| kirkland | slangasek: is the stop on explicitly required? | 00:09 |
| kirkland | slangasek: and why the "45"? we haven't been putting those in our other upstart jobs | 00:10 |
| kirkland | slangasek: usually we've been doing start on [23] | 00:10 |
| slangasek | the 'stop on' prevents the job from continuing to respawn after killall5 has been called on shutdown | 00:10 |
| kirkland | slangasek: hmm, okay | 00:10 |
| slangasek | "why the 45" - because that's always been the default, and maps precisely to your existing 'Default-Start' line | 00:10 |
| kirkland | slangasek: again, the eucalyptus ones lack that currently; would it be nice to add them? | 00:10 |
| slangasek | 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 |
| kirkland | slangasek: okay, i'll fix | 00:11 |
| slangasek | strange, /etc/init/tty[23456].conf are 'start on runlevel [23]' | 00:11 |
| kirkland | slangasek: yeah, i'm grepping the others right now | 00:11 |
| * kirkland mulls an "alias" for 2345 ... | 00:12 | |
| crimsun | does anything need to be done to promote libtdb-dev to main? | 00:21 |
| crimsun | (i.e., currently causing pulseaudio to FTBFS) | 00:21 |
| TheMuso | crimsun: I thought tdb was in main? | 00:23 |
| wgrant | libtdb-dev is a new binary package that has landed in universe. | 00:26 |
| TheMuso | If it belongs to a source package in main, then its just a matter for an archive admin to promote the binary afaik. | 00:29 |
| james_w | it needs someone to process http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 00:30 |
| === kirkland` is now known as kirkland | ||
| kirkland | slangasek: would it be possible to permanently reschedule the server ISO builds for about 4 hours from now? | 01:56 |
| kirkland | slangasek: thats just about the perfect time to pick up western US changes | 01:57 |
| kirkland | slangasek: and build them in time for our earliest Euro team members | 01:57 |
| kirkland | cjwatson: I suspect you might be able to answer that too ^ | 01:57 |
| slangasek | I don't see any reason we could'nt | 01:58 |
| slangasek | couldn't | 01:58 |
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | fine by me | 02:00 |
| sbalneav | Sigh, Bug #501559 is still kicking my butt. | 03:05 |
| ubottu | 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:05 |
| sbalneav | There's so many differences between the older behaviour with forkpty, and the newer behavior. | 03:06 |
| === vorian_ is now known as stalcup | ||
| === stalcup is now known as v | ||
| TheMuso | /c/c | 04:09 |
| === asac_ is now known as asac | ||
| crimsun | are we still no-go on source v3.0 uploads? | 05:06 |
| RAOF | I thought we were go for 3.0 as of a couple of days before Christmas? | 05:09 |
| pitti | Good morning | 07:19 |
| ttx | pitti: Good morning | 07:20 |
| ttx | 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 |
| ttx | kirkland: I guess we need a larger safety margin between upload and respin at the end of your day | 07:21 |
| pitti | ttx: triggered | 07:21 |
| ttx | pitti: thx | 07:21 |
| === cdE|Woozy_ is now known as cdE|Woozy | ||
| pitti | 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:51 |
| dholbach | good morning | 07:59 |
| ttx | pitti: beh, the new respin still hasn't caught the latest. Investigating | 08:03 |
| ttx | pitti: is there a lag between publication and cd-builder archive sync ? | 08:04 |
| pitti | shouldn't be much | 08:04 |
| pitti | if it's on archive.u.c., antimony should see it, too | 08:04 |
| ttx | 1.6.2~bzr1120-0ubuntu3 has been published an hour ago. | 08:04 |
| * ttx checks up archive | 08:04 | |
| pitti | (antimony uses ftpmaster.internal) | 08:04 |
| ttx | archive has it since 0704 UTC | 08:05 |
| ttx | you triggered at 0721 | 08:05 |
| pitti | weird | 08:05 |
| pitti | ttx: what's that package? | 08:06 |
| ttx | pitti: eucalyptus -- http://archive.ubuntu.com/ubuntu/pool/main/e/eucalyptus/ | 08:06 |
| ttx | I need 1.6.2~bzr1120-0ubuntu3 for testing | 08:06 |
| pitti | ttx: hm, indeed cdimage@antimony:/srv/cdimage.ubuntu.com/ftp/pool/main/e/eucalyptus only has ubuntu2 | 08:09 |
| pitti | 2010-01-06 07:13 Packages.gz | 08:10 |
| pitti | (it's 08:10 on antimony) | 08:11 |
| pitti | ttx: I'll watch this, and when the next sync happens in 2 mins, I'll verify euca again and retrigger | 08:11 |
| superm1 | 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 |
| ttx | pitti: hm, the lag makes asking for a CD respin a little guesswork :) | 08:11 |
| ttx | pitti: cool, thanks | 08:11 |
| pitti | superm1: oh, it doesn't get dbus launched for you? | 08:12 |
| superm1 | pitti, not when hal-lock is ran | 08:12 |
| pitti | superm1: ah, I see; for some reason "lshal" doesn't trigger it either | 08:12 |
| pitti | lshal and hal-device (and I suppose hal-lock) has an extra check if it's running | 08:13 |
| ttx | 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:13 |
| superm1 | 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:14 |
| pitti | superm1: not sure; if you are okay with the pgrep, that works for me | 08:15 |
| superm1 | pitti, yeah i think that's the easiest solution for now, will commit it to ubiquity bzr then | 08:16 |
| superm1 | something else weird is going on with that gtk+ upload from yesterday though | 08:16 |
| superm1 | ubiquity uses setattr to make widgets callable at the top level, and that appears to have broken for some reason | 08:17 |
| paykoob | hi. when is the calm hours of Launchpad build farm for PPAs? I dont want to wait an hour! | 08:20 |
| pitti | ttx: hm, I don't know what's going on; it didn't update at all now | 08:27 |
| ttx | pitti: hm | 08:28 |
| pitti | 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:36 |
| StevenK | pitti: Right, so the only thing remaining is removal of u-n-r-d-s, which I'm still thinking about. | 08:38 |
| pitti | StevenK: oh, I don't see a replacement u-n-d-s? | 08:38 |
| pitti | or is that entirely obsolete now with didier's gdm changes to support an extra gconf tree? | 08:39 |
| StevenK | ubuntu-netbook-default-settings | 0.7.0 | lucid | source, all | 08:39 |
| StevenK | pitti: ^ ? | 08:39 |
| pitti | *cough* | 08:39 |
| StevenK | Haha :-) | 08:39 |
| pitti | StevenK: note that I said "I don't see", not "it's not there" :) | 08:40 |
| StevenK | pitti: Yes, so I brought it closer so you could see it. | 08:40 |
| persia | Winning on purely semantic terms only gets half-credit | 08:40 |
| StevenK | Awwww | 08:40 |
| * StevenK goes to cook dinner | 08:40 | |
| pitti | sweet, thanks | 08:40 |
| pitti | StevenK: enjoy! | 08:40 |
| persia | 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:41 |
| pitti | persia: that already happens | 08:52 |
| joaopinto | I had 2 system freezes with lucid in the last 2 weeks :( | 08:54 |
| persia | 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:55 |
| pitti | persia: right, u-n-d-s should build a transition package | 08:56 |
| persia | That was the suggestion :) | 08:56 |
| pitti | right, misunderstood you; sorry | 08:56 |
| persia | Might make sense for netbook-meta to do so as well. | 08:56 |
| pitti | same with u-n-r vs. u-n | 08:56 |
| persia | Right | 08:56 |
| seb128 | superm1, hey | 09:30 |
| seb128 | superm1, could you open this gtk bug upstream too? | 09:30 |
| superm1 | hi seb128 | 09:30 |
| superm1 | seb128, i think we have to adjust our code actually | 09:30 |
| superm1 | it looks like a fundamental change upstream | 09:30 |
| seb128 | I'm just reading it | 09:30 |
| superm1 | it should be a one line fix for ubiquity it looks like | 09:30 |
| seb128 | but if you read the bug referenced in the commit they say some software are using buggy assumptions | 09:30 |
| dholbach | which bug is that? | 09:31 |
| seb128 | right, what I was starting to think too | 09:31 |
| seb128 | dholbach, bug #503710 | 09:31 |
| dholbach | is it the reason why gtg crashes on startup? :) | 09:31 |
| ubottu | 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 |
| seb128 | dholbach, dunno, gtg could be buggy | 09:31 |
| seb128 | I don't use it | 09:31 |
| === charlie__ is now known as porthose | ||
| dholbach | I guess it's something different: | 09:32 |
| dholbach | ** | 09:32 |
| dholbach | Gtk:ERROR:/build/buildd/gtk+2.0-2.19.2/gtk/gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree) | 09:32 |
| dholbach | Aborted | 09:32 |
| seb128 | seems a different issue from the assertion | 09:32 |
| dholbach | ok ok | 09:32 |
| superm1 | seb128, http://pastebin.com/f206651ca appears to fix it for ubiquity from what i just tested | 09:34 |
| seb128 | superm1, good | 09:34 |
| seb128 | thanks for looking into that one | 09:34 |
| superm1 | so i'll do a ubiquity upload with thatso that live disks can be working again | 09:35 |
| dholbach | seb128: the bug I had is bug 503576 (bug 503630 seems to be a dup) | 09:46 |
| ubottu | 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 |
| ubottu | Launchpad bug 503630 in synaptic "synaptic will not load" [Undecided,New] https://launchpad.net/bugs/503630 | 09:46 |
| seb128 | ok | 09:47 |
| dholbach | 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:48 |
| seb128 | dunno | 09:50 |
| seb128 | I will look at that in a bit I'm busy with a cairo fix right now | 09:50 |
| dholbach | sure sure, no worries | 09:50 |
| seb128 | jdstrand, kees: is apparmor_parser using cpu for ages on evince install in lucid a known issue? | 10:15 |
| seb128 | we get some users ctrl-C-ing the install because they think it's stucked | 10:16 |
| tseliot | james_w: why does bzr-builddeb -S require the build dependencies of a package? Can I override this with -d ? | 10:22 |
| james_w | tseliot: yes, but it's spelt "-- -d" currently | 10:24 |
| tseliot | 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:26 |
| james_w | thanks, let me know if there are any problems | 10:27 |
| tseliot | sure | 10:28 |
| james_w | and feel free to improve the documentation if you find any areas that are lacking | 10:29 |
| cjwatson | could somebody process the new libssl0.9.8-udeb in NEW? it should end up in main | 10:30 |
| cjwatson | it's for a bug that the server guys wanted fixed | 10:31 |
| pitti | 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:31 |
| pitti | apw: right now, your wiki-status.py directly parses the original data again | 10:32 |
| pitti | apw: would you mind taking a look at http://paste.ubuntu.com/352238/ and check if this structure has everything you need? | 10:32 |
| pitti | 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 |
| pitti | cjwatson: looking | 10:33 |
| apw | 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:33 |
| pitti | apw: yes, the HTML report generator already does that | 10:34 |
| apw | cirtainly have no objection to the underlying desire | 10:34 |
| pitti | apw: SELECT max(date) FROM work_items | 10:34 |
| pitti | apw: and then SELECT ... WHERE date == (result from above) | 10:35 |
| apw | ok, fair enough. one assumes in the furture this thing will come inhouse, and start generating all the wiki pages for us | 10:35 |
| pitti | apw: the idea is to reduce the millions of DBs that I have (foundations-lucid-a2-workitems.db, global-lucid-workitems.db, etc.) | 10:35 |
| pitti | apw: into one "lucid.db" which knows about teams and milestones, and everything else that we need | 10:36 |
| pitti | 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 |
| pitti | and since the .db is publicly available, you can then also run scripts locally on it | 10:36 |
| pitti | apw: in fact, this data collection doesn't need all the pychart stuff, etc., so this could run on rookery | 10:37 |
| pitti | apw: (another reason why I want to split the programs) | 10:37 |
| pitti | then everyone could configure the collection on rookery | 10:37 |
| pitti | and I'd just need to run the burndown chart generation on my server | 10:37 |
| apw | 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 |
| seb128 | dholbach, gtk fix uploaded, I verfied it fixes gtg and seahorse | 10:38 |
| apw | 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:38 |
| apw | but it would be nice to be able to do that in generally | 10:39 |
| pitti | 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 |
| pitti | apw: ah, that's a good point | 10:39 |
| apw | 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:39 |
| pitti | 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 |
| pitti | apw: but in fact I think you are right | 10:40 |
| apw | but i think the format as it is does not preclude the change as a step 2 | 10:40 |
| pitti | 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:40 |
| pitti | 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 |
| pitti | instead of filtering the blueprints by team first and then by assignee (which is what we currently do) | 10:41 |
| apw | there are two mental views, work for desktop, and work being done by desktop, i think our reports are the later indeed | 10:42 |
| apw | (should be) | 10:42 |
| apw | yeah i believe so | 10:42 |
| pitti | 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:43 |
| pitti | apw: so, does wiki-report.py collect any extra information which isn't represented in those two tables? | 10:46 |
| apw | pitti, thinking | 10:47 |
| apw | pitti, the only generic thing i have to invent over the data there, is a milestone ordering | 10:48 |
| apw | 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 |
| pitti | apw: yeah, I think that should be a matter of data collection | 10:49 |
| pitti | i. e. if there's no status we could just fill in the description as value for "status" | 10:49 |
| apw | yeah, thats what i do, put 'Description: ' on the ftont and ram it in the same hole | 10:50 |
| apw | so no i can't see anything on my page which isn't in there | 10:51 |
| dholbach | seb128: you are a hero! | 10:52 |
| pitti | apw: http://paste.ubuntu.com/352248/ | 10:52 |
| pitti | apw: that provides milestone ordering, too | 10:52 |
| * seb128 hugs dholbach | 10:52 | |
| * dholbach hugs seb128 back | 10:53 | |
| apw | 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 |
| pitti | apw: (with the obvious omission in the work_items table fixed) | 10:53 |
| pitti | apw: hm, we get it as a string value only, and map it to a color | 10:54 |
| apw | +def priority_value(name): | 10:55 |
| apw | + if name == "Essential": | 10:55 |
| apw | + return 99 | 10:55 |
| pitti | def priority_value(name): | 10:55 |
| pitti | ah | 10:55 |
| apw | can this db do a function? then that would be fine represented as a function in the schema | 10:55 |
| pitti | apw: sqlite doesn't have a CREATE FUNCTION unfortunately | 10:57 |
| pitti | so priority -> value and priority->color mapping would need to be done in the report generator code | 10:57 |
| apw | we can live with that | 10:59 |
| apw | pitti, before you get hacking on it there are a couple of improveents sitting in my branch | 10:59 |
| apw | they all look pretty self contained | 10:59 |
| apw | mostly the stuff to fix the escaping to be correct | 11:01 |
| pitti | $ bzr merge lp:~apw/launchpad-work-items-tracker/wiki-status | 11:01 |
| apw | yeah | 11:01 |
| pitti | "Nothing to do." | 11:01 |
| apw | how long does LP take to update a branch once its pushed | 11:02 |
| pitti | on the webui, two or three minutes | 11:02 |
| pitti | but no delay at all if I use bzr+ssh:// to pull | 11:02 |
| apw | pitti, i think i am being dumb, looks to be in ther | 11:03 |
| apw | pitti, so let me know if there is anything i need to do in this conversion | 11:05 |
| pitti | 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 |
| pitti | however, that doesn't need to happen in lockstep | 11:07 |
| apw | yeah | 11:08 |
| pitti | apw: I probably need to break the API slightly, though, due to the DB reorg | 11:09 |
| pitti | apw: but I'll develop it in a branch and only merge it once everything works again | 11:09 |
| tseliot | james_w: it doesn't seem to be my lucky day: http://pastebin.ubuntu.com/352256/ | 11:17 |
| tseliot | :-/ | 11:17 |
| pitti | tjaalton: "The topic for #launchpad is: LP DB security updates, possible intermittent outages 11:00-11:30 UTC" | 11:18 |
| pitti | sorry, tseliot ^ | 11:18 |
| tseliot | pitti: oh, are you trying to say that launchpad doesn't hate me today :-P ? | 11:18 |
| james_w | tseliot: erg | 11:19 |
| pitti | tseliot: well, it hates everyone equally rather | 11:19 |
| james_w | ah | 11:19 |
| tseliot | :-D | 11:19 |
| james_w | might warrant a launchpad bug anyway | 11:19 |
| apw | pitti, seems reasonable, i can work against the other branch once its there | 11:19 |
| james_w | might be nice to say "LP is out for lunch, please come back later" | 11:20 |
| * tseliot nods | 11:20 | |
| === MacSlow is now known as MacSlow|lunch | ||
| james_w | 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? | 11:56 |
| soren | james_w: fcntl.flock(fd, fcntl.LOCK_EX), I think. | 12:04 |
| james_w | yeah, just found buried in the manpage the statement that they survive as long as the process, thanks | 12:04 |
| === MacSlow|lunch is now known as MacSlow | ||
| ttx | pitti: the daily server CD wasn't produced at 1030 UTC as usual... what's the status ? Was antimony archive synced ? | 12:30 |
| pitti | 2010-01-06 10:18 Packages.gz | 12:31 |
| pitti | it's 12:31 on antimony | 12:31 |
| pitti | it seems to lag badly today for some reason | 12:31 |
| ttx | I think 10:18 should be alright... let me doublecheck | 12:31 |
| pitti | anyway, it does have ubuntu3 now | 12:32 |
| pitti | (just checked Packages.gz) | 12:32 |
| * pitti respins | 12:32 | |
| pitti | ETA 10 mins | 12:32 |
| ttx | pitti: cool, thx | 12:32 |
| cjwatson | 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:33 |
| ttx | 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 |
| ttx | cjwatson: iiuc that could also be used instead of triggering CD respins just to test new eucalyptus uploads ? | 12:39 |
| cjwatson | ttx: sure | 12:40 |
| ttx | interesting. /me tests | 12:41 |
| amikrop | Nautilus, and the whole system/desktop/CPU gets eaten/stuck/froze when you browse a WebDAV directory. You should really do something. | 12:53 |
| amikrop | Another serious thing: You cannot copy to a WebDAV directory. Copying... hangs forever. | 12:58 |
| amikrop | WebDAV does not work at all. | 12:58 |
| amikrop | with Nautilus | 12:59 |
| tjaalton | blame gvfs-backends | 12:59 |
| tjaalton | (the package) | 12:59 |
| hyperair | and file a bug | 12:59 |
| tjaalton | that too | 12:59 |
| tjaalton | preferably upstream, or both | 12:59 |
| amikrop | excuse me, I won't | 13:03 |
| amikrop | I have already filed a bug or two about WebDAV and I got ignored | 13:04 |
| amikrop | so I don't think it has much point | 13:04 |
| amikrop | It is a bug in your Distro | 13:04 |
| amikrop | I want to help, so I report a problem | 13:04 |
| amikrop | if you want to make your distro usable, fix the bug | 13:05 |
| tjaalton | eh no, it's an upstream bug | 13:05 |
| persia | Um, it's a bug in *both* places. | 13:05 |
| tjaalton | they don't care about webdav enough | 13:05 |
| persia | (or it's not a bug) | 13:05 |
| hyperair | amikrop: erm yes, you report a problem by filing a bug. is that really so hard? | 13:05 |
| tjaalton | persia: well, true | 13:05 |
| hyperair | 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:08 |
| amikrop | hyperair: how do I report an upstream bug? | 13:09 |
| amikrop | because the whole system hangs and nothing works about webdav | 13:09 |
| hyperair | amikrop: you have to identify the upstream bug tracker, and then file a bug there. | 13:09 |
| amikrop | and I am forced to mount it via command line | 13:09 |
| amikrop | mount.davfs | 13:09 |
| amikrop | and not Connect server... | 13:09 |
| hyperair | since as tjaalton mentioned, the problem lies in gvfs-backend, the bug tracker would be bugzilla.gnome.org | 13:09 |
| hyperair | after that, if you can't fix the bug yourself, your only option is to be patient. | 13:10 |
| amikrop | I want to say, it is not a favor made to the users | 13:12 |
| amikrop | it is a favor made by the users | 13:12 |
| amikrop | to report problems | 13:12 |
| cjwatson | it's both | 13:13 |
| amikrop | I will report it there | 13:13 |
| dholbach | seb128: gtk fix fixes it | 13:58 |
| seb128 | dholbach, great | 13:59 |
| dholbach | seb128: the reason for the breakage was very amusing :) | 13:59 |
| seb128 | dholbach, ;-) | 13:59 |
| seb128 | "ups" | 13:59 |
| dholbach | yeah :) | 13:59 |
| jdstrand | seb128: re apparmor_parser> basically, yes. jjohansen is working on it and can give you the most up to date info | 14:18 |
| seb128 | jdstrand, thanks | 14:18 |
| seb128 | jjohansen, hey, is there any bug about apparmor_parser being sloooow? | 14:18 |
| seb128 | we got users stopping the evince install because they think it's stucked | 14:18 |
| seb128 | it seems to be apparmor eating cpu | 14:19 |
| jjohansen | yeah it can be, its in the dfa generation | 14:19 |
| jjohansen | I am working on some optimizations | 14:19 |
| seb128 | do you have a bug about that or want one? | 14:20 |
| seb128 | or you are working on it anyway and the bug is of no use? | 14:20 |
| jjohansen | seb128: no bug open yet, feel free to open one | 14:20 |
| seb128 | I might just reassing the next evince bug we get about installation stucked ;-) | 14:20 |
| jjohansen | seb128: well it overlaps with a work item, but they are different | 14:21 |
| statik | 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 |
| zul | statik: sure just ping me | 14:23 |
| statik | awesome thanks | 14:23 |
| kirkland | does anyone have a sample package that builds/installs upstarts scripts using a DEB_PYTHON_SYSTEM=pycentral stylely rules file? | 14:30 |
| pitti | kirkland: apport does | 14:31 |
| pitti | (the two have nothing in common, though) | 14:31 |
| pitti | python stuff is handled by dh_pycentral, while upstart scripts are handled by dh_installinit | 14:31 |
| kirkland | pitti: cheers | 14:32 |
| === robbiew_ is now known as robbiew | ||
| kirkland | pitti: okay, so i just need a dh_installinit line then in the build? | 14:32 |
| pitti | by and large, yes | 14:32 |
| pitti | there are some caveats, like you need to specify --upstart-only if there is _also_ a debian/foo.init | 14:32 |
| pitti | (which is likely when a package is also in Debian and we don't want to remove the init script to reduce delta) | 14:33 |
| kirkland | pitti: got it, thanks! | 14:35 |
| tweakt | How does Ubuntu build install CDs? I'm looking for the process used by Ubuntu devs to build official CDs. | 15:08 |
| tweakt | 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:08 |
| tweakt | Re: http://forum.soft32.com/linux/Ubuntu-CD-Image-Build-System-ftopict502887.html | 15:10 |
| ArneGoetje | pitti: I can try to deal with fontconfig, yes | 15:10 |
| tweakt | http://ubuntuforums.org/showthread.php?p=8563488 | 15:10 |
| tweakt | etc... | 15:10 |
| tweakt | Searches turn up little to nothing :-( | 15:11 |
| cjwatson | tweakt: 'bzr get lp:ubuntu-cdimage' and also check out the submodules in configs/devel | 15:12 |
| cjwatson | tweakt: then start with etc/crontab and follow references from there | 15:12 |
| cjwatson | tweakt: for live CDs, the livecd-rootfs package is also involved | 15:13 |
| tweakt | thanks a bunch! | 15:15 |
| tweakt | excuse my ignorance, the 'lp:' prefix is an automatic shortut for ubuntu servers, right? | 15:16 |
| sbalneav | 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 |
| ubottu | 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 |
| tweakt | launchpad... n/m | 15:16 |
| cjwatson | tweakt: it's implemented by bzr's launchpad plugin | 15:17 |
| cjwatson | see https://code.launchpad.net/ubuntu-cdimage for the equivalent in a web browser | 15:17 |
| sbalneav | 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 |
| tweakt | ahh, so it's debian-cd with ubuntu specific configs, excellent! | 15:18 |
| sbalneav | however, that's going to be some fairly major code work. | 15:18 |
| sbalneav | 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:19 |
| sbalneav | I'm not sure from a policy perspective what cordev's want. | 15:20 |
| mvo | 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 |
| mvo | sbalneav: ie. does this work on karmic? | 15:21 |
| sbalneav | yeah, works fine on karmic | 15:22 |
| stgraber | mvo: did your patch implement the same thing as the patch we used to have in karmic ? | 15:22 |
| mvo | 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:22 |
| mvo | sbalneav: sorry for that | 15:23 |
| sbalneav | 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:23 |
| sbalneav | 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:24 |
| mvo | 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 |
| ubottu | Debian bug 535544 in libgksu "libgksu 2.0.12 & tty_tickets does not match" [Normal,Fixed] | 15:27 |
| sbalneav | thanks, I'll look into that. | 15:28 |
| ttx | 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:28 |
| ttx | i.e. I end up with a system where ssh and avahi-daemon are started, but this job isn't | 15:29 |
| sbalneav | 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:29 |
| sbalneav | ah, I see. | 15:30 |
| * sbalneav read 535544 | 15:30 | |
| sbalneav | 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 | |
| ubottu | 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:31 |
| mvo | 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:33 |
| mvo | soren: cheers! which fix do you use? the xserver-xorg-video-nv patch or one against the xserver itself? | 15:34 |
| soren | mvo: I haven't actually tried any of them yet :) | 15:34 |
| sbalneav | mvo: ok, will do, I'll dig into it tonight. If you beat me to it, NP. Start your engines | 15:35 |
| soren | 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:35 | |
| mvo | 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:37 |
| soren | mvo: Sounds like fun. I've installed the package, I just need to find a good time to restart X. | 15:38 |
| ttx | slangasek: any clue for my upstart question from 30 minutes ago ? | 15:53 |
| soren | mvo: *chuckle* Um, yeah, I see what you mean about the colours being slightly off :) | 15:53 |
| joaopinto | mvo, any idea why does "LANG=C software-center" produces mixed translated and english strings ? | 15:55 |
| === BenC2 is now known as BenC | ||
| mvo | joaopinto: no, what is your default locale | 15:56 |
| joaopinto | pt_PT.UTF-8, my locale does show properly by default, I just wanted to check some original strings in english | 15:57 |
| mvo | 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 |
| mvo | joaopinto: maybe its some oddness with webkit | 15:57 |
| seb128 | joaopinto, use LANGUAGE=C software-center | 15:58 |
| joaopinto | seb128, same result, the menu is english, other piceses of the gui are random, english or native | 15:59 |
| joaopinto | ConfigParser.NoSectionError: No section: 'general' | 16:00 |
| seb128 | what pieces? | 16:00 |
| joaopinto | argh, this is not fixed yet :P ? | 16:00 |
| joaopinto | software center crashes on exit | 16:00 |
| soren | 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:00 |
| joaopinto | seb128, menu is english, on the right side bar, the "Get Software" tree is english, the "Installed Software" is portuguese | 16:01 |
| joaopinto | The "Categories" word is pt_pt, the category names are en_us | 16:02 |
| seb128 | ok, dunno then | 16:02 |
| seb128 | could be that some strings are coming from aptdaemon | 16:02 |
| joaopinto | buttons text is pt | 16:02 |
| seb128 | and it's running on whatever local your session is | 16:02 |
| seb128 | mvo, ^ | 16:02 |
| seb128 | ? | 16:02 |
| joaopinto | yes | 16:03 |
| slangasek | ttx: because of The Upstart Bug | 16:03 |
| ttx | slangasek: the TUB ? | 16:03 |
| slangasek | ttx: you would have to also restart avahi-daemon in order for upstart to see again that the second half of the condition is satisfied | 16:03 |
| ttx | slangasek: ah. uh. eh. | 16:04 |
| slangasek | oh, perhaps that's not The Upstart Bug; that might just be An Upstart Oddity | 16:04 |
| joaopinto | seb128, is very unlikely that the "Get Free Software" translated text come from aptdaemon ;) | 16:04 |
| ttx | slangasek: my issue seems to match the TUB quite well | 16:04 |
| ttx | slangasek: i'm trying to see how I can workaround it in the less ugly way[tm] | 16:04 |
| seb128 | joaopinto, using LANGUAGE=C makes this one english there... | 16:05 |
| ion | slangasek: It will get fixed in a future version of Upstart. | 16:05 |
| ttx | slangasek: sounds like some combination of respawn might be the less ugly | 16:05 |
| slangasek | ttx: I don't think there is a non-ugly way to work around that | 16:05 |
| joaopinto | seb128, I am refering to the button on the right panel, on the left panel it does show in english | 16:05 |
| slangasek | ion: I'm aware; AFAIK that won't happen for lucid | 16:05 |
| seb128 | joaopinto, ok, I don't know about this one | 16:06 |
| ttx | slangasek: is the TUB a feature or an acknowledged, lucid-targeted bug ? | 16:06 |
| seb128 | joaopinto, the right panel one is translated correctly there | 16:06 |
| seb128 | using LANGUAGE=C or LANGUAGE=de_DE.UTF-8 | 16:06 |
| seb128 | it's in english in first case and german in the second one | 16:07 |
| cwillu_at_work | slangasek, (ttx) would "(started ssh or started avahi-daemon) or (started avahi-daemon or started ssh)" work? :p | 16:07 |
| === beuno is now known as beuno-lunch | ||
| joaopinto | seb128, it does show properly now, I am sure it didn't, there must be caching involved somehow | 16:10 |
| joaopinto | well, I can't reproduce it's fixed :P | 16:12 |
| seb128 | good ;-) | 16:12 |
| slangasek | ttx: it's neither | 16:15 |
| slangasek | cwillu_at_work: it would "work", but you've turned an AND into an OR | 16:16 |
| joaopinto | hum, is there a manpage describing LANG vs LANGUAGE ? | 16:18 |
| ttx | slangasek: it's a bug that is not fixable in lucid ? | 16:20 |
| slangasek | ttx: correct | 16:20 |
| ttx | hm. | 16:21 |
| cjwatson | joaopinto: locale(7) | 16:21 |
| kees | seb128: the parser being slow for evince loading is known, but it only happens when the profile isn't already cached (i.e. new kernel). On new installs, this is supposed to be fixed in the installer (i.e. generate the cache during install instead of first-boot) | 16:23 |
| kees | seb128: though I saw "ages" being 4 seconds, Keybuk saw it take _27_ once, which I haven't reproduced. | 16:23 |
| seb128 | kees, could be, I noticed it on daily upgrade | 16:23 |
| seb128 | it takes over a minute there | 16:23 |
| kees | was a kernel upgrade involved? | 16:24 |
| seb128 | I guess so | 16:24 |
| kees | seb128: lucid or karmic? | 16:24 |
| seb128 | lucid | 16:24 |
| kees | well, >5 seconds is very odd, and I would considered a bug and regression. that said, it should be loading in parallel with everything else. | 16:25 |
| joaopinto | man locale mentions LANGUAGE, man setlocale only mentions LANG | 16:25 |
| seb128 | kees, it's over 30 seconds for sure | 16:25 |
| seb128 | the box being a mini10v | 16:25 |
| seb128 | cpu sucks there | 16:25 |
| seb128 | top showed that the apparmor_parser was using 100% cpu | 16:26 |
| cjwatson | joaopinto: that's correct | 16:26 |
| kees | that's really odd for it to run so long. can you tar up your /etc/apparmor.d directory for me and open a bug for it? | 16:26 |
| cjwatson | LANGUAGE is basically a weird override for LC_MESSAGES, in practice | 16:26 |
| seb128 | kees, ok, any way to trigger the same command manually to see how long it takes? | 16:27 |
| cjwatson | 'info gettext' has more detail | 16:27 |
| kees | I will try again to reproduce it on my super-slow laptop. | 16:27 |
| cjwatson | actually I think LANGUAGE might be an override for everything, beyond LC_ALL | 16:27 |
| kees | seb128: yeah, "sudo service apparmor reload" should be a "worst case". | 16:27 |
| cjwatson | but LANGUAGE has a different syntax | 16:27 |
| cjwatson | the point of LANGUAGE is that it can be colon-separated | 16:27 |
| joaopinto | from the manpage it looks to override only LC_MESSAGES | 16:27 |
| cjwatson | I suspect info gettext is more correct | 16:28 |
| joaopinto | ok, next time I will use: LANG=C LANGUAGE=C :) | 16:28 |
| cjwatson | LC_ALL=C LANGUAGE= is what I usually use if I want to hit things over the head | 16:29 |
| joaopinto | it is odd that LANG does not override LC_MESSAGES in specific cases | 16:29 |
| cjwatson | joaopinto: LANG is explicitly lowest-priority | 16:30 |
| seb128 | kees, that command is supposed to take ages or in the a few second magnitude you mentioned before too? | 16:30 |
| kees | seb128: so, with a lot of non-default profiles, etc, my system takes 15s on a reload. A default karmic should take maybe 5s | 16:30 |
| seb128 | kees, the mini10v is stock lucid | 16:31 |
| seb128 | that's the box I use for bootcharting | 16:31 |
| kees | right. how long did it take? | 16:31 |
| seb128 | still running... | 16:31 |
| kees | !! | 16:31 |
| kees | please send /etc/apparmor.d when it finishes... | 16:31 |
| seb128 | ok | 16:31 |
| seb128 | but it's stock lucid installed for an usb key | 16:32 |
| seb128 | I don't touch the box out of bootcharting | 16:32 |
| seb128 | for -> from rather | 16:32 |
| slangasek | ahhhhh | 16:32 |
| seb128 | still running... | 16:32 |
| slangasek | what just ate my color pallette for half my gnome terminals in a lucid upgrade? | 16:32 |
| seb128 | oh | 16:32 |
| seb128 | 176 seconds | 16:33 |
| kees | *gape* | 16:33 |
| seb128 | kees, ^ | 16:33 |
| Zorry | doko__: ping | 16:34 |
| kees | kees: let me know when you've got the bug open, and I'll download the apparmor.d tarball. that's pretty insane. | 16:35 |
| jdstrand | 176 seconds | 16:35 |
| seb128 | kees, talking to yourself? | 16:35 |
| highvoltage | sekunde | 16:35 |
| jdstrand | that has got to be some sort of record | 16:35 |
| jdstrand | seb128: you win! | 16:35 |
| seb128 | what do I win? ;-) | 16:35 |
| jdstrand | seb128: a slow boot process? | 16:36 |
| kees | seb128: yeah, I hate that kind of typo. ;) | 16:36 |
| seb128 | kees, http://people.canonical.com/~seb128/apparmor.d.tar.gz | 16:36 |
| seb128 | jdstrand, boot is fast, upgrade is slow | 16:36 |
| kees | seb128: thx | 16:36 |
| jdstrand | ah | 16:36 |
| seb128 | jdstrand, this box boot in 16 seconds | 16:36 |
| seb128 | grub to desktop loaded | 16:36 |
| jdstrand | sweet | 16:36 |
| kees | seb128: can you examine your dpkg log and find out what was upgraded that triggered it to throw away the cache? | 16:37 |
| seb128 | kees, how can I figure that from the dpkg.log? | 16:37 |
| seb128 | it only show what got upgraded | 16:37 |
| seb128 | which on daily lucid is a lot | 16:37 |
| kees | seb128: well, really I want to answer the question "what was upgraded between the time you booted quickly and the first boot of the parser being slow?" :P | 16:38 |
| seb128 | it's not boot being slow | 16:38 |
| seb128 | it's the upgrade | 16:38 |
| seb128 | synaptic sitting on "configuring evince" for 3 minutes | 16:38 |
| kees | Oh! | 16:38 |
| doko__ | Zorry: contentless pong (just write what you want) | 16:38 |
| seb128 | users do ctrl-C their upgrade thinking it's stucked | 16:39 |
| kees | seb128: okay. that makes more sense. (not the 3 minutes, but the issue) | 16:39 |
| seb128 | and we get apport bugs | 16:39 |
| seb128 | did I say boot when I'm pinged? I'm sorry | 16:39 |
| seb128 | it's an evince postinst issue | 16:39 |
| kees | no, I thought you meant system upgrade, not evince upgrade. :) | 16:39 |
| seb128 | I do | 16:39 |
| seb128 | daily update-manager dist-upgrade | 16:39 |
| seb128 | evince was in the batch | 16:39 |
| seb128 | do you want a bug with the tarball still? | 16:40 |
| kees | right. I thought it was getting stuck at boot time after an upgrade (which was an earlier complaint) | 16:40 |
| Zorry | doko__: can you test this patch on binutils-2.20 http://pax.grsecurity.net/binutils-2.19-pt-pax-flags-200811041810.patch for me ld segfault | 16:40 |
| kees | seb128: yes, please. I can't reproduce it yet, but it's clearly an issue. | 16:40 |
| Zorry | doko__: http://pastebin.com/d2b0e1a77 | 16:41 |
| doko__ | Zorry: well, it's not applied in the ubuntu package, isn't it? | 16:42 |
| kees | seb128: how much memory does the mini10v have? | 16:43 |
| Zorry | doko__: is not | 16:43 |
| seb128 | kees, 1G | 16:43 |
| seb128 | kees, i've 639M free right now | 16:44 |
| seb128 | +1.6G of swap | 16:44 |
| kees | seb128: okay, thanks. | 16:44 |
| Zorry | doko__: only adding unsigned int pax_flags; make ld segfault | 16:45 |
| === dendrobates is now known as dendro-afk | ||
| Zorry | doko__: just working on proof-of-concept with PaX and PIE | 16:49 |
| doko__ | Zorry: sorry didn't test this combination, and don't plan to. maybe ask kees aboutit? | 16:50 |
| Zorry | doko__: okey np kees did't have the time | 16:51 |
| jjohansen | seb128: want to run an apparmor test for me on your mini10v | 16:53 |
| === beuno-lunch is now known as beuno | ||
| kees | Zorry: why do you need PaX, btw? | 16:53 |
| seb128 | jjohansen, sure | 16:53 |
| Zorry | kees: full support for pax kernels | 16:54 |
| apw | cjwatson, would i be right in assuming the installer knows when to invoke compcache ? and can you point me at which of those bits do that? | 16:54 |
| jjohansen | seb128: as root can you do time apparmor_parser -S /etc/apparmor.d/usr.bin.evince >foo | 16:54 |
| zul | doko_: when you get a chance can you review python-pastescript and ptyhon-pastedeploy | 16:54 |
| seb128 | jjohansen, ok | 16:55 |
| jjohansen | seb128: then apparmor_parser -Br foo | 16:55 |
| seb128 | kees, jjohansen: bug #503869 | 16:55 |
| ubottu | Launchpad bug 503869 in apparmor "reload takes ages in lucid" [Undecided,New] https://launchpad.net/bugs/503869 | 16:55 |
| jjohansen | seb128: ah thanks | 16:55 |
| jjohansen | seb128: make that time apparmor_parser -Br foo | 16:56 |
| seb128 | jjohansen, the first command exit immediatly with a 234 error | 16:56 |
| geser | I've seen this on my dell mini10v too (upgrading evince took "ages") | 16:57 |
| kees | seb128: try it again with -T -S | 16:57 |
| kees | (I will fix -S to imply -T) | 16:57 |
| seb128 | running | 16:57 |
| seb128 | takes ages | 16:57 |
| cjwatson | apw: not really the installer, it's the live CD boot process | 16:57 |
| === dendro-afk is now known as dendrobates | ||
| cjwatson | apw: it's hooked up in casper | 16:58 |
| apw | i wanted to confirm how it invokes it, so apt-get source casper is my firend? | 16:58 |
| jjohansen | hrmm we should turn off caching when -S is used | 16:58 |
| kees | seb128: we're trying to verify that it's a userspace issue (parsing) not a kernel issue (loading) | 16:58 |
| kees | jjohansen: yup, already on it. | 16:58 |
| seb128 | still running... | 16:58 |
| smoser | cjwatson, Keybuk is out? | 16:58 |
| cjwatson | apw: casper/conf.d/compcache, and /usr/share/initramfs-tools/hooks/compcache in initramfs-tools (you'll already have this installed) | 16:58 |
| cjwatson | smoser: don't know, sorry | 16:58 |
| apw | cjwatson, thanks ... thats what i needed to know. it copes with both compcache and ramzswap as the module name | 16:59 |
| smoser | anyone? i'm hoping for a some info about bug 503212 . | 16:59 |
| ubottu | Launchpad bug 503212 in mountall "mountall crashed with SIGSEGV in main() without initramfs" [High,New] https://launchpad.net/bugs/503212 | 16:59 |
| smoser | if its not going to be fixed by alpha2, then i need to turn on ramdisks in our ec2 images. | 17:00 |
| seb128 | jjohansen, kees: done | 17:00 |
| apw | smoser, you can be sure its has not been tested without innitramfs | 17:00 |
| seb128 | I forgot to re-add the >log when fixing the syntax | 17:00 |
| seb128 | but it was around 3 minutes | 17:00 |
| smoser | apw, i know it *is* tested. i tested it :) | 17:00 |
| smoser | it doesn't work | 17:01 |
| seb128 | I'm running it again now | 17:01 |
| apw | smoser, indeed so ... i'd wonder if its not yet fully converted to the new devtmpfs thingy | 17:01 |
| kees | seb128: ok, so it's seems that -T -S takes 3 minutes, and the -Br takes very little? | 17:01 |
| seb128 | -Br exit immediatly on signal 9 | 17:01 |
| seb128 | "time apparmor_parser -Br foo" | 17:02 |
| seb128 | is that >foo | 17:02 |
| kees | the -S is writing out the binary profile to "foo", and -Br foo is loading it into the kernel. | 17:02 |
| jjohansen | ah, no you really want foo, you are loading the compiled profile generated in the -S command | 17:03 |
| seb128 | oh ok sorry | 17:03 |
| seb128 | one minute it's running again now | 17:04 |
| ion | smoser: I think i see the problem. I’ll fix it. | 17:07 |
| seb128 | kees, jjohansen: -T -S = 170s | 17:08 |
| seb128 | kees, jjohansen: -Br = 0.06s | 17:08 |
| jjohansen | seb128: thanks, what are the configs on that machine of yours? | 17:08 |
| jjohansen | ie. ssd, hd, memory | 17:08 |
| smoser | ion, that would rock, thank you. | 17:09 |
| seb128 | jjohansen, it's a mini10v with 1G of ram, it's an atom cpu, quite slow | 17:09 |
| seb128 | jjohansen, ssd disk | 17:09 |
| seb128 | jjohansen, io is very fast, there is plenty of ram and swap but cpu sucks | 17:10 |
| jjohansen | seb128: right, new the atom part just wondering the other parts of the config that can very | 17:10 |
| jjohansen | seb128: can you run top while doing the -S command and see what kind of memory/swap its hitting | 17:10 |
| seb128 | time said that 100%cpu was used during those 170 seconds for the -T -S command | 17:11 |
| seb128 | apparmor_parser is 100%cpu all the time | 17:11 |
| seb128 | memory usage is low | 17:12 |
| seb128 | 602meg free + 1.6gig swap, not changing there | 17:12 |
| jjohansen | seb128: okay thanks | 17:13 |
| seb128 | not moving, whatever apparmor_parser does it eats all cpu for 170 seconds | 17:13 |
| seb128 | jjohansen, you're welcome | 17:13 |
| jjohansen | seb128: I know what the problem is, we'll see if I can't fix it at least partially for alpha2 | 17:14 |
| seb128 | ok thanks | 17:14 |
| seb128 | should I comment on the bug to add details or will you do that? | 17:14 |
| jjohansen | if you can add the results of your testing that would be great | 17:15 |
| seb128 | jjohansen, done | 17:18 |
| seb128 | jjohansen, bug #503869 | 17:18 |
| ubottu | Launchpad bug 503869 in apparmor "reload takes ages in lucid" [Undecided,New] https://launchpad.net/bugs/503869 | 17:18 |
| seb128 | let me know if you need extra details | 17:18 |
| seb128 | kees, ^ | 17:18 |
| jjohansen | seb128: will do, thanks | 17:18 |
| seb128 | thank you | 17:18 |
| ion | It seems bug #458299 may have reappeared. | 17:19 |
| ubottu | Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Fix released] https://launchpad.net/bugs/458299 | 17:19 |
| === yofel_ is now known as yofel | ||
| statik | hi zul, Just following up from earlier: I reviewed the rabbitmq-server merge and the ubuntu changes are already upstream, so it should be a sync instead. I filed a sync request here https://bugs.edge.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/503875 | 17:24 |
| ubottu | Ubuntu bug 503875 in rabbitmq-server "Sync rabbitmq-server 1.7.0-3 (main) from Debian testing (main)" [Wishlist,New] | 17:24 |
| zul | statik: sounds good to me | 17:25 |
| davmor2 | asac: when FF opens in live desktop you are getting the pop up about add-ons again like in karmic | 17:28 |
| kees | seb128: so, while jjohansen digs further, do you think if I added a "Reloading evince AppArmor profile (this can take a long time) ..." message to the postinst it would be better? | 17:32 |
| kees | well, s/better/more understandable and people wouldn't report as many bugs/ | 17:32 |
| seb128 | kees, don't bother, it's lucid and and people tend to use update-manager which doesn't display the command line by default | 17:34 |
| seb128 | kees, just make it better before lucid turn stable ;-) | 17:35 |
| kees | seb128: that's what jjohansen is up to. sounds like it's hitting what the atom is really bad at, though. :( | 17:48 |
| jdong | *sigh* atom :-/ | 17:51 |
| jdong | really hit-or-miss performance wise | 17:51 |
| === andreasn__ is now known as andreasn | ||
| geser | kees, jjohansen: as I see this problem on my netbook too, does it help when I attach a strace log (with timestamps) to the bug? | 17:51 |
| jjohansen | geser: in this case it won't help much, the computational part makes very few syscalls | 17:52 |
| nixternal | wtf is going on with -devel ml? | 18:01 |
| === deryck is now known as deryck[lunch] | ||
| geser | -devel or -devel-discuss? | 18:41 |
| nixternal | one of them, they both go to the same place for me | 18:41 |
| cr3 | is there a way to configure xorg to not prompt when asking to fall back to safe mode? | 18:52 |
| === deryck[lunch] is now known as deryck | ||
| tweakt | I'm trying to use ubuntu-cdimage, getting an error about lockfile not found (I've made all the expected directories so far) | 19:30 |
| tweakt | ahh, nevermind. not a missing lockfile, but missing the program 'lockfile | 19:36 |
| kees | so, if I leave evince running, gnome-screensaver crashes. :) | 19:58 |
| chrisccoulson | kees - more gnome-screensaver crashes? :( | 20:05 |
| kees | chrisccoulson: yup. 100% reproducible too | 20:06 |
| chrisccoulson | kees - have you managed to debug it at all? | 20:08 |
| kees | chrisccoulson: just made it crash with --sync now, sending apport crash in a moment, one sec | 20:10 |
| chrisccoulson | cool, thanks. so it's another X error related crash is it? | 20:10 |
| kees | chrisccoulson: evince & sleep 1; gnome-screensaver-command -a boom. | 20:15 |
| chrisccoulson | kees - i can't make it crash here. this is on lucid isn't it? | 20:17 |
| kees | chrisccoulson: yup | 20:18 |
| kees | chrisccoulson: oh, evince not needed. lucid's g-ss just crashes immediately on activation. :P | 20:21 |
| chrisccoulson | that's very strange :-/ | 20:21 |
| kees | indeed. | 20:22 |
| kees | chrisccoulson: what is responsible for spawning g-ss originally, and can it respawn it? | 20:25 |
| kees | chrisccoulson: LP: #503961 | 20:26 |
| * kees stares at ubottu | 20:26 | |
| kees | bug 503961 | 20:26 |
| ubottu | Launchpad bug 503961 in gnome-screensaver "gnome-screensaver crashed with signal 5 in _XError()" [Undecided,New] https://launchpad.net/bugs/503961 | 20:26 |
| chrisccoulson | kees - gnome-session spawns it. i was thinking about adding proper session integration in gnome-screensaver, so that it can get respawned (and locked) in the event of it crashing | 20:26 |
| kees | chrisccoulson: that would be very nice. :) | 20:27 |
| chrisccoulson | i don't know if upstream would accept a patch for it | 20:27 |
| chrisccoulson | and then, if it keeps crashing, it could just nuke the session (i'm not sure if that's an acceptable fallback in extreme situations) | 20:27 |
| chrisccoulson | i'll have a look at that bug once the retracer has done it's magic anyway | 20:28 |
| chrisccoulson | thanks | 20:28 |
| ccheney | how do i make preformatted text on wiki.u.c ? | 20:29 |
| ccheney | or should i just put things into a list to force it to look preformatted | 20:29 |
| kees | chrisccoulson: nuking the session is probably worse. i.e. minor risk of physical security compromise vs 100% certainty of data loss | 20:30 |
| james_w | ccheney: {{{ <multiline text> }}} | 20:32 |
| ccheney | james_w: thanks | 20:48 |
| === korn_ is now known as c_korn | ||
| === hunger is now known as Guest27964 | ||
| mdz | does anyone know how to check that a gpg key generated via http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ does in fact use SHA256? | 21:26 |
| DktrKranz | mdz: I "manually" checked signing a little file | 21:29 |
| DktrKranz | at the top, you'll see HASH: SHA256 | 21:29 |
| DktrKranz | or SHA1, if things went wrong | 21:29 |
| seb128_ | jjohansen, kees: the apparmor_parser -S -T run takes 65 seconds on my laptop dell 630 config | 21:30 |
| kirkland | okay, i think it's time to block "patrick freundt" as an abusive user to ubuntu-devel-discuss | 21:30 |
| kirkland | robbiew: do you have admin privs on that list? | 21:30 |
| seb128_ | jjohansen, kees: not really specific to the atom, that box has a T7700 duo cpu | 21:30 |
| seb128_ | ie 2.4Ghz | 21:30 |
| highvoltage | kirkland: yes please :( | 21:30 |
| seb128_ | jjohansen, kees: weird that you guys don't get slow run on your boxes | 21:31 |
| robbiew | kirkland: I don't, sorry | 21:31 |
| seb128_ | jjohansen, kees: do you have a special "be fast" flag you use? ;-) | 21:31 |
| * kirkland checks who does ... | 21:31 | |
| kirkland | robbiew: list owned by evand | 21:32 |
| highvoltage | kirkland: evand does according to https://lists.ubuntu.com/mailman/listinfo/Ubuntu-devel-discuss | 21:32 |
| kirkland | robbiew: who appears to be out ... | 21:32 |
| kirkland | robbiew: i'll check with elmo | 21:32 |
| jjohansen | seb128_: nope | 21:32 |
| kirkland | elmo: anyone else besides evand have admin privs on ubuntu-devel-discuss@ ML ? | 21:32 |
| jjohansen | seb128_: once the profile is generated the 1st time it should pull it from the cache | 21:33 |
| jjohansen | so it should be fast then | 21:33 |
| elmo | kirkland: no | 21:33 |
| seb128_ | jjohansen, that doesn't seem to work | 21:34 |
| seb128_ | jjohansen, running the command again doesn't make it faster | 21:34 |
| === seb128_ is now known as seb128 | ||
| jjohansen | seb128: are you using the -T flag? | 21:36 |
| seb128 | yes | 21:36 |
| seb128 | sudo time apparmor_parser -S -T /etc/apparmor.d/usr.bin.evince > log | 21:37 |
| seb128 | I'm testing with that | 21:37 |
| jjohansen | ah, drop the -T flag | 21:37 |
| jjohansen | it means skip cache | 21:37 |
| seb128 | it exits with status 234 | 21:37 |
| seb128 | when I don't use -T | 21:38 |
| jjohansen | oh right that is because the is a bug, with -S atm | 21:38 |
| jjohansen | try apparmor_parser -r apparmor.d/usr.bin.evince | 21:38 |
| seb128 | ok that's fast | 21:39 |
| seb128 | thanks | 21:39 |
| jjohansen | erc /etc/apparmor.d/usr.bin.evince | 21:39 |
| seb128 | I will stop bothering you about that now | 21:39 |
| seb128 | I was just testing on my laptop to see the difference | 21:39 |
| jjohansen | that is actually loading the profile from cache | 21:39 |
| seb128 | it's 65 seconds on full cpu use there | 21:39 |
| seb128 | which seems still a lot of a duo 2.4Ghz | 21:39 |
| seb128 | of -> for | 21:39 |
| jjohansen | 65s for loading? | 21:40 |
| seb128 | centrino that's it | 21:40 |
| sebner | seb128: wondering, here it took 20% on the first cpu and 100% on the second one. Around 1-2 minutes | 21:40 |
| seb128 | "sudo time apparmor_parser -S -T /etc/apparmor.d/usr.bin.evince > log" | 21:40 |
| seb128 | jjohansen, I noticed because update-manager sit on "updating evince" for over a minute again | 21:40 |
| jjohansen | oh, okay that is recompiling the policy | 21:41 |
| jjohansen | but it should not take that long on a duo | 21:41 |
| jjohansen | eg my laptop takes about 12s | 21:41 |
| seb128 | on lucid? | 21:41 |
| seb128 | I never has the issue on karmic | 21:41 |
| seb128 | had | 21:41 |
| jjohansen | yes on lucid | 21:42 |
| seb128 | ok so I don't know why I've the issue on my boxes and not you | 21:42 |
| jjohansen | well actually on karmic but in a lucid vm | 21:42 |
| jjohansen | it is strange | 21:42 |
| jjohansen | where they clean installs or updates | 21:42 |
| seb128 | updates | 21:43 |
| seb128 | I update those boxes daily | 21:43 |
| seb128 | the mini is a test box for bootcharting | 21:43 |
| seb128 | and the laptop is my work config | 21:43 |
| jjohansen | would you be able to try a clean install to a usb stick | 21:43 |
| seb128 | yes | 21:44 |
| seb128 | I will do that tomorrow though | 21:44 |
| sbeattie | seb128: are you running amd64 or i386 on your duo? | 21:44 |
| seb128 | i386 | 21:44 |
| kees | ah, that's a difference, I'm running amd64... | 21:45 |
| kees | but still, on my duo it takes 8 seconds. | 21:45 |
| seb128 | well my laptop is not that new | 21:45 |
| seb128 | it's 2 years old now | 21:45 |
| seb128 | but it's a duo centrino 2.4G | 21:45 |
| seb128 | which is usually decent enough... | 21:45 |
| sbeattie | I think it's something specifically with the i386 toolchain in lucid. | 21:46 |
| seb128 | you noticed the issue too? | 21:46 |
| jjohansen | mine is core2duo at 1.6G so yours should be fine | 21:46 |
| jjohansen | though I was using 64bit lucid vm to test | 21:47 |
| sbeattie | seb128: Yeah, I just reproduced on lucid/i386 with an atom. | 21:47 |
| === juliank is now known as Guest44290 | ||
| sbeattie | 169.14user 0.25system 2:50.08elapsed 99PU | 21:47 |
| === juliank__ is now known as juliank | ||
| jjohansen | I have a native 32 bit install on a now atom machine (older original core cpu) I'll try testing there | 21:48 |
| jjohansen | s/now/none | 21:49 |
| TheMuso | kirkland: Thanks for the heads up, I just skip his mails now. :) | 21:51 |
| kirkland | TheMuso: ;-) | 21:51 |
| jjohansen | seb128, sbeattie: replicated: on a 1.73 GHz core cpu, 32 bit lucid install 114.429s real, 106.367s user | 21:54 |
| jjohansen | something is really broken on the 32 bit tool chain | 21:55 |
| jjohansen | kees: ^ | 21:55 |
| === cjwatson_ is now known as cjwatson | ||
| kees | yiiikes | 21:57 |
| sbeattie | jjohansen: no, something in lucid's evince profile's includes is triggering bad behavior, but it only shows up on i386. using karmic's parser booted in karmic against lucid's apparmor.d results in similar times, whereas it's almost an order of magnitude faster on karmic's evince profile. | 22:05 |
| jjohansen | hrmm | 22:06 |
| jjohansen | okay, I will continue to poke | 22:07 |
| sbeattie | jjohansen: i.e. ' sudo time apparmor_parser -I /mnt/etc/apparmor.d/ -S -T /mnt/etc/apparmor.d/usr.bin.evince' where /mnt is my fresh lucid installation results in an elapsed time of 2:54.45 | 22:07 |
| jjohansen | ugh, but only on i386 | 22:07 |
| sbeattie | yeah | 22:08 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| mdz | DktrKranz, thanks | 22:32 |
| douglasawh-work | how difficult would it be to put full disk encryption on the live CD? I can't image that taking up a lot of space, as the launchpad download is just 501.7 KB | 22:34 |
| douglasawh-work | but maybe I'm missing something | 22:35 |
| joaopinto | douglasawh-work, that has been brainstormed http://brainstorm.ubuntu.com/idea/14574/, however it was incorrectly set to duplicate :\ | 22:40 |
| douglasawh-work | joaopinto: thanks for pointing that out to me! | 22:43 |
| cjwatson | douglasawh-work: the problem isn't space, it's making it be supported by the live CD partitioner which involves some genuine actual hard code | 22:45 |
| cjwatson | douglasawh-work: we may make some progress towards that this cycle but LVM and RAID are higher priority for the moment | 22:45 |
| cjwatson | however fortunately those involve solving most of the same problems | 22:46 |
| douglasawh-work | cjwatson: thanks for the info. One additional related question which I've not researched. the switch from grub1 to grub2 made using dd for full disk encryption impossible (at least not without re-installing grub). How easy is it to install grub1 in Lucid and/or is that problem with grub2 fixed? | 22:47 |
| cjwatson | douglasawh-work: I'm not sure I understand the problem. Can you describe what's failing with grub2 in more detail? Is there a bug report or something? | 22:54 |
| joaopinto | argh, I am unable to boot without removing splash now :\ | 22:55 |
| joaopinto | I don't remember getting any updates related to boot recently | 22:56 |
| kees | gah, hitting mystery when building. | 22:59 |
| kees | dpkg-source: error: gunzip gave error exit status 1 | 22:59 |
| douglasawh-work | cjwatson: no bug report. The problem is that grub can't see the encrypted partition for some reason when dd is used. works fine in Jaunty. We were (kinda still are) under a bit of a time crunch to figure it out (time crunch is now to deploy) | 23:01 |
| cjwatson | douglasawh-work: so firstly, it's still straightforward to install grub legacy in karmic/lucid | 23:02 |
| cjwatson | but I'd like to figure this out anyway | 23:02 |
| cjwatson | "when dd is used" - could you elaborate? dd is a pretty generic tool :-) | 23:02 |
| cjwatson | I wouldn't have expected grub, either legacy or 2, to be able to see encrypted partitions in general | 23:03 |
| cjwatson | neither of them contains decryption code, to my knowledge | 23:03 |
| cjwatson | so I think I'd need to understand how you're setting things up | 23:03 |
| douglasawh-work | cjwatson: well, it works with Jaunty and Fedora, just using the default. I'll did out the exact dd command I'm using here in just a second | 23:04 |
| tweakt | what's the easiest way to include a custom preseed file when using the ubuntu-cdimage build process? | 23:30 |
| tweakt | I see them in debian-cd, I also need to customize the boot menu to use it | 23:31 |
| === robbiew is now known as robbiew_ | ||
| douglasawh-work | cjwatson: other than grub-common looking like it's still 1.97, the uninstall/re-install seemed to be super-easy. now I've got to test on an encrypted disk...I didn't have the new dd stuff documented where I usually do (like I said, we had a pretty tight deadline), but I'm pretty sure I know where it's at | 23:48 |
| douglasawh-work | to pull down - dd if=/dev/sda | ssh username@backupserver.fqdn "dd of=/directory_of_backups_on_ssh_server/backupfile.iso" | 23:49 |
| kirkland | slangasek: what does it mean if "status libvirt" returns a pid that's close, but not exactly the libvirtd process that I want? I suspect it's due to forking | 23:56 |
| slangasek | kirkland: probably means the job declaration is wrong for the service in question. Is the pid a process that's running, or one that's extinct? | 23:59 |
| kirkland | slangasek: status points to a dead process | 23:59 |
| kirkland | slangasek: i see "expect fork" in a bunch of these upstart scripts | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!