| doko | great, new poppler upload obsoleting today's maint+1 work | 00:12 |
|---|---|---|
| hyperair | Laney: yay thanks | 00:21 |
| infinity | doko: Heh, I was just complaining about that in #-release :P | 00:21 |
| doko_ | <infinity> Oh, thank god, I was worried we might go a whole month without a poppler ABI bump. | 00:53 |
| doko_ | <infinity> I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint. | 00:53 |
| doko_ | <doko> just staff two people from -desktop for the team, there's not much to do for -foundations | 00:53 |
| === cpg is now known as cpg|away | ||
| TheMuso | @pilot in | 02:00 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso | ||
| needhelp1 | Hello all, im helping to pull some data for Ubuntu Beta releases and have a very short survey up on google documents found here. https://docs.google.com/spreadsheet/viewform?formkey=dFdSTUgzREoyeFZNSWRHSjlXMGYteGc6MQ Anyone interested please take the survey and feel free to share the link. The results will be published in two weeks to the public domain. | 02:17 |
| sladen | needhelp1: could you publish some context (who you are; what it's for (eg. Thesis research, graphics design) | 02:19 |
| sladen | needhelp1: many people are unlikely to click random URLs, so you may end up missing out on results (but that depends on who your target audiences is, and we don't know that either!) | 02:20 |
| needhelp1 | sladen, im a college student | 02:23 |
| needhelp1 | sent you a pm also | 02:23 |
| sladen | nb ^^, there's more context at http://nathanheafner.com/home/2012/09/11/ubuntu-beta-users-survey/ | 02:35 |
| lifeless | cjwatson: do you need another test from me ? | 03:24 |
| pitti | Good morning | 03:38 |
| === cpg|away is now known as cpg | ||
| fabo | micahg: thanks. dannf reported a recent bug and we rebased on latest upstream release 1.2.0. an update package should be submitted soon. | 05:04 |
| TheMuso | @pilot out | 05:57 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === charles__ is now known as Guest11727 | ||
| === Guest11727 is now known as charles | ||
| dholbach | good morning | 06:55 |
| === tkamppeter_ is now known as tkamppeter | ||
| rose7676 | help | 07:53 |
| rose7676 | The following packages have unmet dependencies: | 07:53 |
| rose7676 | fglrx : Depends: xorg-video-abi-11 but it is not installable | 07:53 |
| rose7676 | Recommends: fglrx-amdcccle but it is not going to be installed | 07:53 |
| rose7676 | E: Unable to correct problems, you have held broken packages. | 07:53 |
| rose7676 | ? | 07:53 |
| pitti | rose7676: not much you can do right now -- current quantal fglrx driver is broken | 07:54 |
| pitti | you need to wait until a compatible one gets uploaded, and use the free one until then (do give it a try, it shoudl work well) | 07:54 |
| rose7676 | pitti, The following NEW packages will be installed: | 07:56 |
| rose7676 | fglrx-amdcccle nvidia-current-updates | 07:56 |
| rose7676 | 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. | 07:56 |
| rose7676 | Need to get 73.7 MB of archives. | 07:56 |
| rose7676 | After this operation, 215 MB of additional disk space will be | 07:56 |
| rose7676 | ????? nvidia-current-updates | 07:57 |
| pitti | mvo: ^ what was the magic again to ask apt to be verbose about dependency resolution? | 07:58 |
| pitti | rose7676: what did you try to do, dist-upgrade? | 07:58 |
| rose7676 | 12.04 | 07:58 |
| rose7676 | and 12.10 | 07:59 |
| mvo | pitti: -o Debug::pkgProblemResolver=true -o Debug::pkgDepCache::AutoInstall=true | 08:01 |
| mvo | pitti: I guess we should add a --debug-resolver shortcut actually | 08:01 |
| mvo | pitti: to make this more acessable | 08:01 |
| pitti | that'd be great | 08:01 |
| === henrix_ is now known as henrix | ||
| dholbach | can somebody please reject https://code.launchpad.net/~vpilvio/ubuntu/quantal/gpiv/typo-fix/+merge/123450? | 08:10 |
| dholbach | shadeslayer, I'm not sure what to do with https://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121225 | 08:11 |
| pitti | dholbach: done | 08:11 |
| dholbach | thanks | 08:12 |
| shadeslayer | ugh, I forgot about kdevelop .... it's in my PPA atm, need to include that fix | 08:12 |
| shadeslayer | can I assign code reviews to myself? | 08:13 |
| shadeslayer | hmm ... can't even subscribe myself | 08:13 |
| dholbach | shadeslayer, I added you to it | 08:15 |
| shadeslayer | thx | 08:15 |
| cjwatson | lifeless: nothing more to test right now; I tried to set up a simpler reproduction environment (just linear dmraid), but it passed; so I think this is specific to striped, and I need to remember how to set that up | 08:16 |
| ev | mpt: we finally finished the deployment: https://errors.ubuntu.com/ | 08:22 |
| mpt | \o/ | 08:23 |
| ev | I'm most annoyed by that unchecked-by-default teams checkbox | 08:23 |
| mpt | ... I see no checkbox | 08:24 |
| geser | looks great | 08:27 |
| ev | mpt: when you are thrown into the openid check | 08:28 |
| geser | is there an explanation for the colors in the ranking table? | 08:28 |
| mpt | heh | 08:28 |
| * ev metaphorically bangs his head on the desk | 08:28 | |
| mpt | geser, we're trying to work out how to do without one, but haven't succeeded yet. In the meantime: grey = not observed in the latest version, red = supposedly fixed but observed since. | 08:29 |
| shadeslayer | dholbach: can I close branch merges with the changelog? | 08:29 |
| shadeslayer | or is that only for boogs | 08:29 |
| dholbach | shadeslayer, no, but you can mark it merged (or merge the branch via bzr and it should(?) get auto-merged) | 08:30 |
| mpt | ev, I just realized that if the default table is top errors for all Ubuntu users, eventually a majority may fall into the "not observed in the latest version" category, because they'll be in old releases but not the development release. Already it's 41/100. | 08:30 |
| ev | hmm yeah | 08:31 |
| mpt | ev, I suppose that could be refined to "not observed in the latest version on the same release". | 08:31 |
| ev | how would you do that though? | 08:31 |
| ev | oh | 08:31 |
| shadeslayer | dholbach: Actually, there's a new upstream bugfix release that I'm planning on uploading | 08:31 |
| dholbach | cool | 08:32 |
| geser | mpt: is it intended that the bug link doesn't point to the "master" bug for duplicated bugs? (like for the jockey-gtk entry at rank 11 which also points to a private bug where I first thought it was a broken link because I wasn't logged in into LP) | 08:36 |
| lifeless | geser: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414 | 08:37 |
| ubottu | Launchpad bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Wishlist,Triaged] | 08:37 |
| geser | lifeless: in this case the master bug is public, but errors.u.c links to 927985 (which is private) instead of 734376 (master and public) | 08:39 |
| mpt | geser, I don't know how that part works, sorry, ask ev | 08:42 |
| lifeless | geser: oh, thats interesting, and unusual. | 08:43 |
| jamespage | doko_, just finishing up a rebuild test for java 7 - FTBFS now look much better but > 150 packages build bytecode for >= Java 7 only | 08:43 |
| shadeslayer | dholbach: will be fixed once I QA everything from : https://launchpad.net/~rohangarg/+archive/experimental/+packages | 08:44 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| ev | geser: I'll look into it shortly | 08:46 |
| xnox | ev++ good deployment of errors, hunting some info down now. | 08:53 |
| ev | xnox: cheers | 08:53 |
| ev | geser: so the information for that comes from apport's crash-digger | 09:47 |
| tjaalton | infinity: so, the touchpad hotkey mess is due to acpi-support. /etc/acpi/asus-touchpad.sh gets triggered as well, and it can mess things up if it's a synaptics touchpad.. | 10:07 |
| === mcclurmc_away is now known as mcclurmc | ||
| tjaalton | also, if you happen to have the touchpad disabled setting in g-s-d and boot the machine up, there is no user-friendly way to get the touchpad working again, since the properties are flip-flopped so it'll always be disabled (nice that synaptics has two properties to disable the device..) | 10:09 |
| tjaalton | g-s-d does the right thing | 10:10 |
| tjaalton | pitti: what happened to https://blueprints.launchpad.net/ubuntu/+spec/acpi-support-deprecation :) | 10:11 |
| pitti | tjaalton: I guess it died off at the last mile :( | 10:12 |
| tjaalton | yeah :/ | 10:12 |
| tjaalton | was wondering why one laptop with Alps worked fine, and the other with synaptics hit these weird issues, but it was because asus-touchpad.sh doesn't recognize Alps :) | 10:13 |
| silverarrow | hi | 10:18 |
| silverarrow | is it possible to track down why a video streams when it is not suppose to ? | 10:18 |
| silverarrow | I mean, figuring out what is working more than all the error messages | 10:19 |
| didrocks | jamespage: just to double check, the packages you want in main in addition to those that already promoted are radosgw and python-ceph, right? | 10:29 |
| jamespage | didrocks, yes please | 10:29 |
| didrocks | jamespage: doing the promotion now | 10:29 |
| jamespage | ta | 10:30 |
| didrocks | yw :) | 10:30 |
| jamespage | didrocks, BTW I just hit a bug in radosgw on armhf - bug 1049582 | 10:30 |
| ubottu | Launchpad bug 1049582 in ceph (Ubuntu) "radosgw crash on armhf architecture" [Undecided,New] https://launchpad.net/bugs/1049582 | 10:30 |
| jamespage | it works just fine on x86 - I will raise this with upstream today - have a call later on | 10:31 |
| didrocks | jamespage: ok, I don't block on that then, trusting you to keep track :) promoted | 10:35 |
| === Phantomas1 is now known as Phantomas | ||
| didrocks | jamespage: btw, looking at the python-ceph package, it can certainbly be arch: all (if you have another upload to do) | 10:35 |
| didrocks | but no hurry :) | 10:36 |
| jamespage | didrocks, ack | 10:36 |
| jamespage | I'll put that on my list TODO | 10:36 |
| didrocks | thanks | 10:37 |
| === glebihan_ is now known as glebihan | ||
| === doko_ is now known as doko | ||
| === cpg is now known as cpg|away | ||
| doko | jamespage, you did disable the openvswitch-datapath-dkms package in openvswitch, however xcp-networkd still depends on it. should the dependency just dropped? | 10:58 |
| jamespage | doko, I did because its broken in quantal; however I think zul was looking at fixing it up again to work with the 3.5 kernel | 10:59 |
| doko | jamespage, could you track this? it shows up in NBS | 11:00 |
| jamespage | its provided by the kernel; so thats probably a reasonable course of action if we can't ressurect this | 11:00 |
| jamespage | doko, sure - leave it with me | 11:00 |
| doko | thanks | 11:00 |
| doko | janimo, ping | 11:19 |
| janimo | doko, hi | 11:19 |
| === MacSlow is now known as MacSlow|lunch | ||
| === Quintasan_ is now known as Quintasan | ||
| doko | jamespage, the 150 bytecode for 7 packages are no good. I assume these are all packages which don't use one of the helper tools for the build? | 11:58 |
| jamespage | doko, I suspect so - maven stuff will be OK; javahelper to | 11:59 |
| jamespage | they will probably all be ant/Make custom builds | 11:59 |
| jamespage | doko, I have the list - will be raising bugs soon | 11:59 |
| jamespage | like today | 11:59 |
| doko | is there already a lintian check? | 12:00 |
| jamespage | doko, yes - and experimental one "incompatible-java-bytecode-format" - thats what I've been checking for | 12:05 |
| jamespage | doko, http://paste.ubuntu.com/1200436/ | 12:08 |
| === MacSlow|lunch is now known as MacSlow | ||
| doko | jamespage, sort by source/component would be nice | 12:16 |
| jamespage | I think about 7 of those are in main | 12:17 |
| jamespage | I will do that - just trying to finish something else first | 12:17 |
| === _salem is now known as salem_ | ||
| === Quintasan_ is now known as Quintasan | ||
| === sagaci_ is now known as sagaci | ||
| pitti | meh - if there is one package that really benefits from -proposed uploads, it's eglibc.. | 13:08 |
| ogra_ | too late | 13:10 |
| smagoun | didrocks: Hi, I don't understand why you marked bug 1040839 'Fix Released'. You comment makes it sound like it should be marked "WontFix". | 13:10 |
| ubottu | Launchpad bug 1040839 in thunderbird-couchdb (Ubuntu Quantal) "Thunderbird hangs accessing eds on startup" [High,Fix released] https://launchpad.net/bugs/1040839 | 13:10 |
| didrocks | smagoun: the hanging was because the protocols don't match, so it's either updating the API or removing the component (that is not supported) | 13:13 |
| didrocks | smagoun: more a semantic discussion, if you prefer to set it won't fix, please do :) | 13:13 |
| smagoun | didrocks: right. Have either of those changes happened in Q? If not, the fix is not released | 13:14 |
| smagoun | It's a pretty bad bug....IMHO we at least need to remove thunderbird-couchdb | 13:14 |
| didrocks | smagoun: that's what I did and hence I changed the status | 13:14 |
| ogra_ | cant you just add a Breaks: <= libedataserver-1.2-15 to thunderbird-couchdb ? | 13:15 |
| ogra_ | so that they cant be installed together | 13:15 |
| didrocks | ogra_: well, there is no more upstream for it, nobody will maintain it and port to the new API | 13:15 |
| didrocks | (which is quite an extensive change) | 13:15 |
| ogra_ | oh, you mean tb-couchdb | 13:16 |
| didrocks | yep | 13:16 |
| smagoun | didrocks: So thunderbird-couchdb will be removed during an upgrade from 12.04-12.10? That is good. It wasn't clear from your comment that you made that change | 13:16 |
| ogra_ | ah | 13:16 |
| chrisccoulson | will removing it from the archive guarantee that it's removed on upgrade? | 13:16 |
| didrocks | smagoun: yeah, sorry, it will when people choose "remove obsolete packages" as part of the update-manager process | 13:16 |
| chrisccoulson | didrocks, hmmm, we probably want to guarantee that it gets removed | 13:17 |
| didrocks | chrisccoulson: you can add a breaks to ensure people using apt-get dist-upgrade to have that done | 13:17 |
| didrocks | s/to// | 13:17 |
| chrisccoulson | yeah, i don't mind | 13:17 |
| didrocks | I think it will be best :) | 13:18 |
| smagoun | +1 for guaranteeing removal | 13:19 |
| === cjohnston_ is now known as cjohnston | ||
| smartboyhw | Can someone tell me which channel is/are the best on fixing bugs, I need it to write Ubuntu Accomplishments | 14:02 |
| mr_pouit | mterry: lightdm-set-defaults doesn't work as expected with your patch: show_remote_login is TRUE in lightdm by default but FALSE in lightdm-set-defaults | 14:05 |
| mterry | mr_pouit, ah, so it sets remote to false too easily? | 14:06 |
| mr_pouit | mterry: also, lightdm-set-defaults --keep-old --show_remote_login=false/true doesn't do anything | 14:06 |
| mterry | mr_pouit, regarding the false-by-default in set-defaults, I thought set-defaults doesn't set anything unless it's specified by user? | 14:07 |
| mr_pouit | mterry: yeah, my first statement is probably wrong because of the second one: --keep-old and --remove don't do anything with --show-remote-login (lightdm.cinf is never updated) | 14:09 |
| mterry | mr_pouit, is it broken with manual-login too? (I cargo-culted the manual login treatment, so I'm curious if this is a general error or something I did) | 14:10 |
| tsdgeos | can someone make https://bugs.launchpad.net/bugs/1026164 public? | 14:14 |
| ubottu | Error: malone bug 1026164 not found | 14:14 |
| tsdgeos | i just got thrown there when trying to report a bg | 14:14 |
| mdeslaur | tedg: please get someone to fix LP: #1049849 | 14:15 |
| mdeslaur | bug 1049849 | 14:16 |
| ubottu | Launchpad bug 1049849 in lightdm (Ubuntu) ""Remote Login" account not confined by guest AppArmor profile" [Undecided,New] https://launchpad.net/bugs/1049849 | 14:16 |
| tedg | mdeslaur, Okay, how do I test that? | 14:16 |
| mdeslaur | tedg: hold on, I'll add steps to reproduce in the bug | 14:16 |
| tedg | mdeslaur, Thanks! | 14:18 |
| mdeslaur | tedg: ok, steps added. thanks! | 14:21 |
| mr_pouit | mterry: it's a general error for booleans apparently (update_boolean() doesn't do what's needed compared to update_string()) | 14:26 |
| mterry | mr_pouit, yeah, good point. It's noticably not caring whether an existing value is there | 14:28 |
| dholbach | thanks xnox for replying to that tweet | 14:29 |
| xnox | dholbach: your welcome. It's not "true" LDAP integration, but it does at least work these days. | 14:29 |
| dholbach | great | 14:30 |
| dholbach | thanks | 14:30 |
| smoser | anyone aware of this: http://paste.ubuntu.com/1200691/ | 14:56 |
| smoser | python-twisted is currently uninstallable | 14:56 |
| smoser | doko, you apparently copied that from debian recently? | 14:57 |
| doko | smoser, working on it | 15:00 |
| smoser | thank you. | 15:01 |
| micahg | slangasek: Bug #1049840 is broke since precise-updates is higher than quantal for nspr | 15:05 |
| ubottu | Launchpad bug 1049840 in ia32-libs (Ubuntu Quantal) "ia32-libs-multiarch wrong dependancies on quantal 64bit" [Undecided,Incomplete] https://launchpad.net/bugs/1049840 | 15:05 |
| slangasek | micahg: should that be a pocket copy? | 15:06 |
| micahg | idk, I haven't reviewed the changes | 15:06 |
| micahg | either a pocket copy or a no change rebuild if the changes don't apply | 15:06 |
| micahg | hrm, either way it should probably be rebuilt on quantal though | 15:09 |
| micahg | slangasek: looks like no change rebuild is the way to go, are you already doing it, or should I? | 15:12 |
| slangasek | micahg: I'm uploading | 15:14 |
| micahg | ok, thanks | 15:14 |
| === ken__ is now known as kenvandine | ||
| === dpm is now known as dpm-afk | ||
| infinity | tjaalton: *poke* | 15:46 |
| tjaalton | infinity: *dodge* | 15:47 |
| infinity | tjaalton: Feel an urge to limit intel-gpu-tools to "amd64 i386"? | 15:47 |
| tjaalton | infinity: probably makes sense | 15:48 |
| infinity | (I was about to do that for the Ubuntu package, and noticed you're just releasing from Debian git anyway) | 15:48 |
| infinity | tjaalton: "any-amd64 any-i386" might also make sense, except that it doesn't appear to love non-linux arches anyway, from what the Debian build logs are showing me. | 15:48 |
| infinity | tjaalton: So, yeah, "amd64 i386" is probably right. | 15:49 |
| tjaalton | yeah I'll add just those | 15:49 |
| infinity | tjaalton: Danke. | 15:49 |
| tjaalton | infinity: dunno if you saw, but the hotkey issue was with acpi-support. bug 804109 has the details | 15:52 |
| ubottu | Launchpad bug 804109 in acpi-support (Ubuntu) "remove/edit racy /etc/acpi/asus-touchpad.sh" [Medium,Triaged] https://launchpad.net/bugs/804109 | 15:52 |
| infinity | tjaalton: Fun, fun. | 15:52 |
| tjaalton | it shouldn't do anything for synaptics devices, ok to keep the hack for evdev using touchpads until g-s-d handles them | 15:53 |
| === jacky is now known as jalcine | ||
| infinity | tjaalton: Maybe I'll fix it (the intel-gpu-tools thing) in Ubuntu right now for my own sanity on the FTBFS/dep-wait list, and you can just commit to Debian git later. | 15:55 |
| tjaalton | I've done the commit already | 15:57 |
| tjaalton | and merge | 15:57 |
| smoser | slangasek, ping | 15:58 |
| tjaalton | uploaded too :) | 15:58 |
| infinity | tjaalton: Oh, shiny. Thanks. | 15:58 |
| jamespage | slangasek, ever have one of those days with a package? I can't seem to get samba right | 16:02 |
| jamespage | so --upstart-only should only be used when the upstart configuration is NOT replacing a init script with the same name? | 16:02 |
| jamespage | I did not get that from the man page | 16:03 |
| slangasek | smoser: hey there | 16:04 |
| slangasek | jamespage: correct - sorry for the bad documentation :) | 16:04 |
| smoser | slangasek, i'll get you access to a system to poke around if you dont mind | 16:05 |
| smoser | for bug 1031065 | 16:05 |
| ubottu | Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065 | 16:05 |
| * jamespage goes todo another samba upload | 16:05 | |
| slangasek | jamespage: in a cycle or two it'll be obsolete anyway | 16:05 |
| slangasek | smoser: I have very little time to look at it right now due to the management sprint, but if you can give me a system that'll be up for a few days that I can poke at when I get a chance, that'd be great | 16:05 |
| smoser | sure | 16:05 |
| smoser | i'll send you info | 16:06 |
| jamespage | well actually that will be tomorrow now... | 16:06 |
| tjaalton | hit bug 983543 while trying to dist-upgrade to quantal | 16:10 |
| ubottu | Launchpad bug 983543 in eglibc (Ubuntu) "Internal Error, No file name for libc6" [Undecided,Confirmed] https://launchpad.net/bugs/983543 | 16:10 |
| ev | mpt, bdmurray: so we don't have a "link to an existing bug" link | 16:23 |
| ev | as bdmurray has noticed | 16:23 |
| ev | I'm wondering if we can get away with just telling people to dup whatever they've done to the errors created bug | 16:23 |
| infinity | tjaalton: Hrm. I've seen that once (thought it was libstdc++, not libc) on an aborted upgrade. Rest of the system was fine, apt was in a tizzy. Not entirely sure where to reassign it, or even how to reproduce it (and almost certain it's not glibc's fault). | 16:23 |
| infinity | tjaalton: If you have any meaningful way to actually make it happen reliably, I'd love a reproducer. | 16:24 |
| ev | or if we need to provide a pair of "create / link to existing" links | 16:24 |
| tjaalton | infinity: yeah it's misfiled | 16:24 |
| mpt | ev, I can suggest how to present either of those, but which one of them to do is out of my ambit | 16:24 |
| xnox | ev: well we need a link that takes it to ~ page as apport does where you can search or file new. | 16:24 |
| xnox | ev: that doesn't help with linking up though =( | 16:25 |
| mpt | ev, because I don't know how noisy auto-generated bug reports would be. | 16:25 |
| mpt | (And therefore how good an idea it is to auto-generate them.) | 16:25 |
| bdmurray | ev: there is also the issue regarding traceback and line numbers for source code changing. so there may already be an existing bug in launchpad just with different line numbers that is already triaged / assigned/ fixed. | 16:25 |
| ev | xnox: please rephrase - I don't follow | 16:25 |
| ev | mpt: you indirectly raise an interesting point | 16:26 |
| bdmurray | and marking that as a duplicate of the errors created bug seems less efficient | 16:26 |
| ev | we're going to be autogenerating bugs for the top X crashes | 16:26 |
| cjwatson | I've never really understood how I'm supposed to take an existing errors report and arrange for there to be a bug for it, if I'm not actually encountering it myself | 16:26 |
| ev | so how does that play in? Are they just forced to dup when one exists, but provided with a "create / link" links otherwise? | 16:26 |
| cjwatson | I don't know about the linking bit, but I would find a creation-on-request facility extremely helpful | 16:26 |
| ev | cjwatson: that just landed - there are "create" links in the bug columns | 16:26 |
| ev | as of today | 16:26 |
| ev | it wont show up for failed to retrace bugs - marked with "failed:" on the front of the signature | 16:27 |
| cjwatson | Ah | 16:27 |
| cjwatson | There are no create links in the page I have loaded | 16:27 |
| cjwatson | But trying to write 40GB to USB means my entire system is rather slow so it's hard to chec | 16:28 |
| cjwatson | k | 16:28 |
| cjwatson | Oh yes, I see them now, thanks | 16:28 |
| bdmurray | ev: I'm talking about bug 1048830 | 16:28 |
| ubottu | Launchpad bug 1048830 in Errors "error report without a bug link" [Undecided,New] https://launchpad.net/bugs/1048830 | 16:28 |
| cjwatson | So I'm interested in the logic of not presenting that for failed-to-retrace bugs | 16:29 |
| cjwatson | Because that implies you (consciously or otherwise) think developers can't do anything about them | 16:29 |
| ev | cjwatson: I do | 16:29 |
| === deryck is now known as deryck[lunch] | ||
| mpt | ev, I don't see the "create" links -- is that because I'm not in the appropriate team? | 16:29 |
| cjwatson | Which raises the question of why we're bothering to show them | 16:29 |
| mpt | (not that I want to be) | 16:29 |
| ev | cjwatson: to raise awareness of how much we need to fix ddebs | 16:30 |
| cjwatson | ev: But that isn't true, I've certainly fixed failed-to-retrace bugs in the past because the problem was obvious from the top of the stacktrace | 16:30 |
| ev | and how much I need to feed things back through the retracer | 16:30 |
| cjwatson | This is an invalid assumption | 16:30 |
| ev | cjwatson: fair enough | 16:30 |
| ev | it's somewhat complex to fix | 16:30 |
| === dpm-afk is now known as dpm | ||
| cjwatson | Now admittedly it's a hell of a lot easier with a stacktrace, but ... | 16:30 |
| ev | as if we do work out a process to feed things back through the retracer | 16:30 |
| ev | we'll need to clean up the bug links too | 16:30 |
| cjwatson | Yes, true | 16:31 |
| ev | and we might have multiple stacktrace address signatures with "failed:" on the front | 16:31 |
| ev | that map to a single crash signature | 16:31 |
| ev | and need some way of determining which bug is the master - or just dup them all to it | 16:31 |
| * ev digs up the bug number for this re-retracing | 16:31 | |
| cjwatson | I'm certainly *aware* of how much we need to fix ddebs, but realistically I think the answer is more LP development time in UE | 16:31 |
| ev | cjwatson: https://bugs.launchpad.net/daisy/+bug/1044418 | 16:31 |
| cjwatson | Yeah, I know what you mean | 16:32 |
| ev | cjwatson: oh absolutely | 16:32 |
| ubottu | Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New] | 16:32 |
| ev | and it's as much to remind me as anything else | 16:32 |
| ev | I have no doubt that I'll have to play a role in fixing it | 16:32 |
| ev | I just want to make sure I'm reminded of the importance of this vs starting up other subprojects on errors | 16:32 |
| ev | if we can't see the failed to retrace crashes, then the problem might as well not exist to me | 16:33 |
| ev | (it actually used to be this way) | 16:33 |
| ev | but I grew worried that it wasn't clear that this was not the entire picture | 16:33 |
| ev | at the very least I need to better tag them as such | 16:33 |
| ev | as people easily miss "failed:" in the signature | 16:33 |
| ev | and I don't mean by putting more text in that line | 16:34 |
| cjwatson | Numbers on Ubuntu-specific vs. not in the last day of 12.10 error reports: about 70% Ubuntu-specific vs. 30% not | 16:34 |
| ev | hmm? | 16:34 |
| cjwatson | Of course that probably needs to be compared with usage to be meaningful | 16:34 |
| cjwatson | Sorry, I mean on Ubuntu-specific packages | 16:34 |
| ev | oh, vs debian? | 16:34 |
| ev | mpt: you're not signed in | 16:35 |
| cjwatson | No, as in 70% of reports from the top 100 were in packages developed specifically for Ubuntu | 16:35 |
| ev | mpt: you need to click off to a problem page first | 16:35 |
| ev | mpt: feel free to provide UI for a login link or a better approach for this | 16:35 |
| ev | ahhh | 16:35 |
| ev | go us | 16:35 |
| xnox | ev: go us.... *sigh* | 16:35 |
| ev | cjwatson: I'm entirely happy with being proven wrong on all my points, so long as it's done using data as you've done here :) | 16:36 |
| cjwatson | This was roughly my point in the meeting - it suggests that fixing our own problems should be the priority, not worrying about the long tail which is basically absent from errors | 16:36 |
| ev | cjwatson: indeed | 16:36 |
| ev | that whole thing went off the rails | 16:36 |
| ev | I just want us to focus on QA in the immediate moment | 16:36 |
| cjwatson | It's probably a bit different for different time periods, but it's unfortunately laborious to count | 16:37 |
| ev | not go, "oh, well we're not at feature freeze yet, we can fix this later" | 16:37 |
| ev | and never do | 16:37 |
| ev | because it's not a LTS | 16:37 |
| cjwatson | I don't think that's really what people were saying as such, but anyway | 16:37 |
| ev | cjwatson: we do have an API for this... | 16:37 |
| cjwatson | ev: Not for "was this package developed specifically for Ubuntu?" | 16:37 |
| ev | oh indeed not | 16:38 |
| ev | sorry about that | 16:38 |
| ev | so before we get too sidetracked | 16:38 |
| ev | bug links | 16:39 |
| ev | we currently provide create bug links | 16:39 |
| ev | do we also provide the ability to manually enter a number | 16:39 |
| ev | rather than one being autocreated | 16:39 |
| ev | err in addition to | 16:39 |
| ev | if one is not already set, that is | 16:39 |
| ev | or | 16:39 |
| ev | do we rely on duping to the errors created bug | 16:40 |
| bdmurray | I say yes and provide bug 1048830 as a reason why | 16:40 |
| ubottu | Launchpad bug 1048830 in Errors "error report without a bug link" [Undecided,New] https://launchpad.net/bugs/1048830 | 16:40 |
| bdmurray | and https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapport-gtk%3Aconfigparser.DuplicateOptionError%3A%3Cmodule%3E%3Arun_argv%3Arun_crashes%3Arun_crash%3Aui_present_report_details%3Aget_desktop_entry%3Aread%3A_read which should be linked to bug 1048834 | 16:40 |
| ubottu | Launchpad bug 1048834 in indicator-datetime (Ubuntu Quantal) "configparser crash with indicator-datetime-preferences.desktop" [Medium,Fix released] https://launchpad.net/bugs/1048834 | 16:40 |
| bdmurray | both of the bugs that I would linke to are already fixed or have lots of work done on them | 16:41 |
| bdmurray | and duping those bugs to one created by errors seems silly | 16:41 |
| ev | so are these generating different signatures? | 16:41 |
| cjwatson | barry: Any progress on bug 1035869? I noticed it showing up on errors | 16:42 |
| ubottu | Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869 | 16:42 |
| bdmurray | ev: the tracebacks for the software-properties-gtk bug have different signatures yes because the line number in the source code changed | 16:43 |
| ev | bdmurray: I'm really weary of moving to launchpad bugs to manage the linkage between problems | 16:43 |
| ev | so I'm wondering if we should instead make it possible to merge problems together in the database | 16:44 |
| ev | or maybe a combination of the two | 16:45 |
| mpt | People still use computer-janitor? Wow. | 16:45 |
| ev | that's unfortunate for them | 16:45 |
| ev | bdmurray: sorry - I know that's really vague | 16:45 |
| ev | my brain is somewhat melted after the meeting | 16:46 |
| ev | but suddenly keying the problems we're seeing on something other than the crash signature would be a massive change | 16:46 |
| ev | and indeed, something external to the database | 16:46 |
| bdmurray | but now we have errors listed that are fixed and don't require more work | 16:47 |
| ev | well they're not fixed | 16:47 |
| ev | if they were fixed they wouldn't be appearing | 16:47 |
| cjwatson | Or they're multiple bugs with the same signature | 16:48 |
| ev | I kind of think this goes into the server-side hooks | 16:52 |
| ev | we should be able to write code that says, when encountering a signature with data in the report that matches this pattern, put it in this bucket instead | 16:53 |
| ev | rather than just into a bucket IDed by the regular crash signature | 16:53 |
| === mcclurmc is now known as mcclurmc_away | ||
| micahg | like bugpatterns but for errors.u.c | 16:56 |
| ev | micahg: right, we're moving all that server side | 16:56 |
| ev | https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-bucketing-improvements | 16:56 |
| ev | I don't think that sort of thing should be pushed via apt or include lots of silly "choose a door for punishment" dialogs | 16:57 |
| === jtechidna is now known as JontheEchidna | ||
| xnox | mpt: thanks to askubuntu.com I now can have rounded corners & joined up buttons with transparent background http://askubuntu.com/questions/185284/how-to-get-rid-of-the-background-gradient-of-the-inline-gtktoolbar/187039#187039 | 17:05 |
| mpt | win | 17:06 |
| xnox | mpt: I had to spend 500 askubuntu reputation points, as only the bounty attracted answers.... | 17:06 |
| SpamapS | pitti: can you explain the giant upload of translations into the precise-proposed queue? Are we just supposed to wave those through? | 17:07 |
| SpamapS | slangasek: ^^ | 17:07 |
| SpamapS | cjwatson: ^^ | 17:07 |
| * SpamapS hoping one of those 3 minds will have the answer | 17:07 | |
| * SpamapS also hoping to clear it up on https://wiki.ubuntu.com/ArchiveAdministration once he knows | 17:08 | |
| infinity | SpamapS: I was about to mass-accept them. | 17:09 |
| * xnox wonders if SpamapS has to click tickboxes 400 times | 17:09 | |
| * SpamapS will pay $0.01/click .. ;) | 17:09 | |
| infinity | SpamapS: (accepting now) | 17:11 |
| cjwatson | Anyone here happen to be an expert in dmraid? | 17:15 |
| cjwatson | I'm trying to re-create Robert's setup in bug 803658 in a VM, using dmraid -C | 17:15 |
| ubottu | Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658 | 17:15 |
| barry | cjwatson: not yet, but i have a browser tab open on it :/ | 17:15 |
| cjwatson | I'm using variations on 'dmraid -f isw -C ARRAY0 --type 01 --disk /dev/sda,/dev/sdb,/dev/sdc,/dev/sdd' | 17:16 |
| cjwatson | This ostensibly succeeds, and indeed (reasonably) complains if I give it fewer than four disks | 17:16 |
| cjwatson | However, it's evidently written garbage, because 'dmraid -ay' says 'ERROR: isw: wrong number of devices in RAID set "isw_cjehcgig_ARRAY0-1" [4/2] on /dev/sda' (and so on for the other three disks) | 17:17 |
| SpamapS | infinity: ok, thanks. So to confirm, thats always just a wave-through? | 17:17 |
| infinity | SpamapS: To -proposed, yes. There's some level of verification that happens before they get to migrate. | 17:17 |
| === dpm is now known as dpm-afk | ||
| === deryck[lunch] is now known as deryck | ||
| smoser | hallyn, maybe this is expected. | 17:53 |
| smoser | but i do an lxc-clone -o source -n new | 17:53 |
| smoser | and new has in its config a reference to source's fstab | 17:53 |
| hallyn | smoser: no that's a bug | 17:54 |
| tjaalton | after dist-upgrade, dnsmasq was listening on 127.0.1.1 but resolv.conf points to 127.0.0.1 | 17:56 |
| === henrix is now known as henrix_ | ||
| SpamapS | barry: reading through the discussion on http://bugs.python.org/issue15906 ... oh what fun! | 18:01 |
| iamfuzz | cjohnston, Hi Colin, what version of live-build do you use for precise/quantal builds? I'e been fiddling with it and run into issues even with a vanilla build | 18:03 |
| cjohnston | :-( | 18:03 |
| hallyn | smoser: well, actually, i'm not 100% sure | 18:03 |
| infinity | iamfuzz: You wanted cjwatson. ;) | 18:03 |
| hallyn | smoser: i think it was left like that for now bc there's a limit to what we can do | 18:03 |
| infinity | iamfuzz: And we use the version that's in the archive for each release. | 18:03 |
| iamfuzz | tab failure ftw | 18:04 |
| smoser | cyphermox, ^ i think you helped me with issues like tjaalton has | 18:04 |
| smoser | hallyn, really? | 18:04 |
| iamfuzz | infinity, interesting, I had to patch the one in precise just to get it to build anything | 18:04 |
| infinity | live-build | 3.0~a24-1ubuntu32.5 | precise-updates | source, all | 18:04 |
| infinity | live-build | 3.0~a57-1ubuntu4 | quantal | source, all | 18:04 |
| hallyn | i.e. if we copy over the fstab, then do we also process it? but if we do that, then we may have to copy over the direcotires mounted in the fstab | 18:04 |
| iamfuzz | trying quantal now | 18:04 |
| infinity | iamfuzz: It might help to realise that we use the auto/{config,build} scripts from livecd-rootfs (also from the appropriate release). | 18:05 |
| hallyn | smoser: i'd almost want to say 'if anything is in there other than proc and sys, refuse' | 18:05 |
| iamfuzz | infinity, many thanks, I'll take a look at that, I had been generating mine with lb config | 18:05 |
| hallyn | stgraber: ^ did you ahve thoughts on handling of /var/lib/lxc/c1/fstab when it's being cloned? | 18:05 |
| smoser | hallyn, sorry | 18:06 |
| smoser | bad explanation | 18:06 |
| smoser | $ grep $SRCNAME /var/lib/lxc/xm/config | 18:06 |
| smoser | lxc.mount = /var/lib/lxc/source-quantal-amd64/fstab | 18:06 |
| smoser | err.. | 18:06 |
| smoser | well, i didn't mean to paste that | 18:07 |
| barry | SpamapS: indeed! i think we've converged on a plan though, and i'll be landing a followup patch in 2.7, 3.2, and 3.3.1 (won't affect 3.3.0) as soon as the test suites finish | 18:07 |
| smoser | but, that is what i opened a bug about | 18:07 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049987 | 18:07 |
| ubottu | Launchpad bug 1049987 in lxc (Ubuntu) "lxc-cloned container breaks if source is later destroyed" [Undecided,New] | 18:07 |
| stgraber | hallyn: well, we surely don't want to reference the source container, so we should probably be using the same code I wrote for lxc-start-ephemeral (or rather that I ported to python) | 18:07 |
| hallyn | stgraber: in fact, rewrite it in python :) | 18:08 |
| hallyn | all right - we have a bug thanks to smoser to address it in | 18:08 |
| stgraber | hallyn: that code basically checks for lxc.mount, if it exists and points to a valid file, it's going to create a fstab file in the target and copy the content, replacing any occurence of the source container path by destination container path | 18:08 |
| hallyn | stgraber: my fear is, then ppl will have /dev/lxc/container1_p3 being mounted in that fstab, will clone the container, and expect taht to get copied and the copy used | 18:09 |
| stgraber | hallyn: well, I suppose I could actually move that logic out of lxc-start-ephemeral and move it to the python overlay by making clone() in python do that by default and add a copy_rootfs=False argument to that function to cover the ephemeral case | 18:09 |
| hallyn | i.e. we need to draw a clear, simple line of what we do and don't do | 18:10 |
| hallyn | maybe your line works | 18:10 |
| hallyn | long as we document it | 18:10 |
| hallyn | somewhere | 18:10 |
| stgraber | hallyn: yeah... I think copying the fstab makes sense, I'm not a big fan of altering it though. I only did it because that's what lxc-start-ephemeral used to do | 18:11 |
| stgraber | hallyn: it was making a lot of sense when we didn't have relative mounts in the fstab, but that's been fixed for more than 6 months now | 18:11 |
| stgraber | so maybe we can get away with just copying the fstab as a whole and not actually touch it, which would simplify the code a lot | 18:12 |
| stgraber | any special case should then be dealt with using pre-mount hooks | 18:12 |
| stgraber | (so if someone really wants some magic to determine what lvm to use, they can do that) | 18:12 |
| hallyn | right - the most important thing is to make sure this is documented. oh hey. there's no lxc-clone man page | 18:13 |
| hallyn | lunch, bbl | 18:14 |
| stgraber | hallyn: I also think we really need to spend some time upstream splitting all the storage code into separate scripts that we can simply call from templates, tools, ... | 18:14 |
| stgraber | hallyn: having to re-implement btrfs/lvm/... over and over again is really painful at the moment and the source of a lot of bugs | 18:15 |
| stgraber | ideally templates should really only care about building a rootfs, they shouldn't do all the storage setup or all the config themselves | 18:15 |
| smoser | hallyn, you should just put a macro of some sort in the fstab | 18:16 |
| smoser | and let that reference ROOT_DIR or the like | 18:16 |
| stgraber | I might start working on clone() in python upstream soon-ish and will make sure we look into the storage backend mess for 13.04 | 18:16 |
| smoser | then only replace ROOT_DIR | 18:16 |
| smoser | and not replace the rendered version | 18:17 |
| stgraber | smoser: no need for that, as I said, we support relative mounts | 18:17 |
| smoser | ah.ok. thnen yes. | 18:17 |
| stgraber | "/tmp/.X11-unix tmp/.X11-unix none bind" | 18:17 |
| smoser | and that is much preferred over full paths. | 18:17 |
| stgraber | that means, mount /tmp/.X11-unix to /var/lib/lxc/<container>/rootfs/tmp.X11-unix as a bind mount | 18:17 |
| stgraber | yep, we just need to make sure everyone uses that :) | 18:18 |
| smoser | well, you have an issue there. | 18:19 |
| * xnox reads lvm highlights backlog | 18:19 | |
| smoser | hm.. maybe not. | 18:20 |
| * xnox nothing that interested me much.... | 18:22 | |
| === cpg|away is now known as cpg | ||
| hallyn | stgraber: agreed | 18:38 |
| arges | infinity, hey you still have time today to chat about the eglibc fma4/avx patches? | 18:50 |
| slangasek | smoser: bug #1031065> ok, so you have a network interface but you're not getting a udev event for it. This is all in lxc, right? | 18:52 |
| ubottu | Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065 | 18:52 |
| slangasek | smoser, hallyn: should we *expect* udev events for network interfaces within a containeR? | 18:53 |
| === dpm-afk is now known as dpm | ||
| infinity | arges: Yep. | 18:58 |
| arges | infinity, cool | 18:58 |
| * arges pulls up https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/979003 | 18:59 | |
| ubottu | Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress] | 18:59 |
| infinity | arges: So, the first order of business would be to make sure we can drum up hardware and reproducers. | 18:59 |
| stgraber | slangasek: we'd like to but it's not the case at the moment. Containers do get udev events once udev is spawned in the container but we don't call udevadm trigger so you wouldn't get event for stuff that happened before udev started. | 18:59 |
| infinity | arges: It should be fixed in quantal, and it's fixed in the precise queue (really need to get that reviewed at some point), but I still suspect we can get away with less nasty backports for older releases. | 19:00 |
| stgraber | slangasek: rationale for not running udevadm trigger being that as we don't have a device namespace yet, doing so would essentially flood the host and all other containers with udev event for all devices (not only these tied to that specific container) | 19:00 |
| arges | infinity I can look into getting hardware | 19:00 |
| infinity | arges: But it's hard to say that for sure without being able to test a more limited fix. | 19:00 |
| slangasek | smoser: ^^ right, so that's the reason you're getting the delay | 19:00 |
| infinity | arges: (Basically, I think we can take the sketchy patch that Debian used and that you attached to the bug for older releases, but only if the FMA4 portion of the bug doesn't exist on << precise) | 19:01 |
| arges | infinity, so the goal would be to do a full backport of the precise/quantal patch into lucid to see if it works initally? then go for the do-no-harm fix? | 19:01 |
| stgraber | slangasek: that's why we had to introduce /etc/init/network-interface-container.conf to workaround that for the loopback device. For the others we rely on networking.conf doing the right thing. | 19:01 |
| stgraber | smoser: ^ | 19:01 |
| arges | infinity, ok | 19:01 |
| arges | infinity, so sounds like... we need to get a chip with the FMA4 extension... I did build a test package of the do-no-harm fix to have that verified in the bug | 19:01 |
| arges | but not response yet | 19:02 |
| infinity | arges: Fully backporting the 2.16 fix to lucid is impossible, it touches code that didn't exist in older releases of glibc. This is why I *suspect* that the less complete fix (that you attached) might be good enough for 2.11 and 2.13, but we need to test. | 19:02 |
| arges | infinity, ok. | 19:02 |
| infinity | arges: Pretty much as soon as I can get some sort of confirmation that this won't need fixing on AMD hardware two minutes after we fix it on Intel hardware, I'm happy to push the lucid and oneiric uploads. | 19:03 |
| infinity | arges: I don't particularly feel like fixing it twice. :P | 19:03 |
| arges | infinity, true. Ok I'll work on getting the AMD hardware | 19:04 |
| infinity | arges: For reference, the AMD version of the bug is https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051 | 19:04 |
| ubottu | Launchpad bug 956051 in eglibc (Ubuntu Precise) "libc6 crash while running 'xm'" [High,Confirmed] | 19:04 |
| infinity | arges: Which, for now, only has a precise task, as I *believe* it doesn't affect older releases. | 19:04 |
| arges | infinity, so looks like there is a patch for that too in the bug... does the overall avx/fma4 patch cover that? or is the patch in the bug another workaround? | 19:06 |
| arges | in 956051 that is | 19:06 |
| infinity | arges: That's the 2.16 commit (well, some of them, our final patch ended up being bigger still) | 19:06 |
| infinity | arges: And that's in quantal and precise. | 19:07 |
| infinity | arges: (In the precise upload queue, that is...) | 19:07 |
| arges | infinity, so can we point the people affected in 956051 to those packages and have htem verify? | 19:07 |
| slangasek | stgraber: do we need/want to bring up an interface config within the container, then? | 19:07 |
| infinity | arges: It's already been verified fixed in quantal. Can't point anyone at anything in precise until it's accepted into -proposed and built. :/ | 19:07 |
| infinity | arges: But it's the identical patchset, so it should DTRT. | 19:08 |
| arges | infinity, so would it make sense to target 956051 to quantal and mark it 'fix released' to indicate that it has been fixed in that package | 19:08 |
| arges | or | 19:08 |
| arges | oh | 19:08 |
| arges | i see the larger task already is marked fix released | 19:08 |
| infinity | Yeah, no need to target the development release. | 19:09 |
| stgraber | slangasek: not sure I understand the question. What do you mean by "interface config"? | 19:09 |
| infinity | arges: I'll try to chase up some people who aren't me to finish reviewing the precise upload and get it accepted. | 19:10 |
| slangasek | stgraber: why do we need an interface setup inside the container? it's having this config that causes the network to come up | 19:10 |
| arges | infinity, ok | 19:10 |
| slangasek | stgraber: er, causes the network to be delayed | 19:10 |
| arges | infinity, i'll try to drum up some hardware and do some testing. | 19:10 |
| infinity | arges: Best thing for you to do would be to sort out the right set of Intel and AMD (kinda want both) hardware for us to both reproduce and verify the state of lucid and oneiric, so we can push those ASAP. | 19:10 |
| arges | infinity, ack | 19:11 |
| infinity | arges: Carlos had a whole set of testing kit that we used to do the 2.16 fixes upstream, but he had to return most of it. :/ | 19:11 |
| stgraber | slangasek: still not sure I understand. Containers have a loopback device and an ethernet device (eth0) just like regular systems, both of which have configuration defined in /etc/network/interfaces and get configured by ifupdown at boot time. | 19:12 |
| smoser | stgraber, is it ok if i/you upload isc-dhcp ? | 19:22 |
| SpamapS | hrm, so, Unity doesn't have a micro release exception, right? | 19:25 |
| * SpamapS looks at the 21 bugs fixed in latest unity precise-proposed upload and wonders | 19:26 | |
| infinity | SpamapS: No, but if it's a bugfix-only release with all the bugs documented, the version number is meaningless. | 19:26 |
| infinity | As long as it's all auditable and such. | 19:26 |
| SpamapS | It is | 19:26 |
| SpamapS | its just.. a big audit ;) | 19:26 |
| infinity | Yeah. That's why I left it for you after I did the really easy nux and unity-2d! ;) | 19:26 |
| SpamapS | infinity: and I would have gotten away with it if it weren't for you darn kids! | 19:27 |
| * SpamapS shakes fist | 19:27 | |
| maco | meddling | 19:27 |
| SpamapS | man some of these are really big code changes too | 19:29 |
| stgraber | smoser: I'm still working on a last fix for it, so unless you need it urgently, I'm planning on uploading it probably later today | 19:31 |
| stgraber | smoser: (I'm fixing the case where dhclient dies after a lease expires when called with -1) | 19:32 |
| smoser | ok. later today is fine. | 19:32 |
| bdmurray | @pilot in | 19:35 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray | ||
| barry | doko: upstream hg should be good to go for bug 1048710 | 19:36 |
| ubottu | Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710 | 19:36 |
| SpamapS | \o/ | 19:41 |
| wds | hi, may I ask a support question here? (no response in main forum) | 19:51 |
| === cmagina-lunch is now known as cmagina | ||
| === emma is now known as em | ||
| bdmurray | Can somebody mark https://code.launchpad.net/~bkerensa/ubuntu/precise/hellanzb/fix-for-957323/+merge/123358 as merged? | 20:07 |
| slangasek | stgraber: ok, that answers my question, thanks. so that means that smoser's problem comes down to containers relying on /e/i/networking.conf to bring up interfaces, plus /e/i/networking.conf blocking on local-filesystems, plus cloud-init deliberately blocking the local-filesystems event | 20:44 |
| slangasek | stgraber: how can we solve this circular dependency? | 20:44 |
| slangasek | smoser: ^^ | 20:44 |
| stgraber | slangasek: I'm not familiar with cloud-init, can you paste that upstart job? | 20:50 |
| stgraber | slangasek: depending on what it actually needs, it might be as simple as using a "or container", but that depends on whether that'd introduce a race or not... | 20:50 |
| slangasek | stgraber: the job is specifically designed to block the rest of the boot, but wait for the network to come up, so that it can pull config over the network | 20:51 |
| smoser | slangasek, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/upstart/ | 20:55 |
| slangasek | stgraber: ^^ the jobs | 20:55 |
| smoser | cloud-init.conf is the job that depends on networking | 20:57 |
| smoser | and it blocks on cloud-init-nonet.conf (which ensures that cloud-init is up) | 20:57 |
| smoser | s/ensures that cloud-init is up/ensures that network is up/ | 20:59 |
| stgraber | smoser: so it looks like this code would be failing on any machine where one or more interface needs to be brought up by networking.conf, no? | 20:59 |
| stgraber | for example, adding the following to /etc/network/interfaces in a cloud instance should trigger the same thing: | 20:59 |
| stgraber | auto br0 | 20:59 |
| stgraber | iface br0 inet manual | 20:59 |
| stgraber | bridge-ports none | 21:00 |
| stgraber | as it's going to be required to get static-network-up and won't be automatically setup by udev events (as it's not tied to any physical interface) | 21:00 |
| slangasek | stgraber: yes, but why would you install the cloud tools on such a machine? | 21:04 |
| slangasek | this is for cloud guests | 21:04 |
| stgraber | slangasek: lxc containers would be one use case for having a bridge interface that's not bridged to a physical device | 21:06 |
| stgraber | slangasek: another one would be using a gre/sit/... tunnel | 21:06 |
| smoser | so. yeah, its limited to "simplistic" networking. for some definition of "simplistic" | 21:07 |
| smoser | but thats ok. | 21:07 |
| smoser | cloud-init is also limited to /usr being on / (it uses python early in boot). thats not ideal, but also ok. | 21:08 |
| slangasek | going forward that's going to be a constraint anyway | 21:08 |
| slangasek | (not this cycle, but next) | 21:08 |
| stgraber | slangasek: actually, there's something I'm not sure about, why do we only wait for virtual-filesystems for network-interface.conf but wait for local-filesystems for networking.conf? | 21:09 |
| stgraber | (network-interface depends on getting a udev event which itself depends on virtual-filesystems, somewhat indirect, but still) | 21:09 |
| slangasek | stgraber: because networking.conf is designed to sit at the same place in the boot sequence as the classical /etc/init.d/networking | 21:09 |
| smoser | i have to run. i'll be aback and read backscroll. | 21:10 |
| slangasek | we could revisit whether this is still reasonable, but making it happen sooner does increase the risk of it happening too early | 21:10 |
| smoser | slangasek, you can give stgraber access to that instance if its at all helpful, but the reproduce case is easiliy described and demonstrated. | 21:10 |
| smoser | thanks to both of you. | 21:10 |
| stgraber | well, if we think that we need to wait for local-filesystems for networking jobs to run at the same time as the sysvinit job in Debian, then we probably should also make network-interface.conf depend on local-filesystems | 21:11 |
| stgraber | (which would completely break cloud-init for everyone then) | 21:11 |
| slangasek | stgraber: not at all, I don't think we want network interfaces to wait for local-filesystems before they come up | 21:13 |
| slangasek | I'm just saying that the reason we're doing that is because /historically/, it was envisioned as a catch-all | 21:13 |
| slangasek | that may or may not be something we still care about | 21:13 |
| stgraber | yeah, might revisit that next cycle, not sure I want to deal with the potential side effects of changing that for 12.10 ;) | 21:14 |
| stgraber | so, one thing that cloud-init could do but would be really quite ugly is to do "initctl emit --no-wait net-device-added INTERFACE=eth0 || true" if it's in a container. Ideally without hardcoding eth0. But that's quite ugly and wrong... | 21:16 |
| barry | slangasek: can you comment on #3 of bug 1035869 ? | 21:18 |
| ubottu | Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869 | 21:18 |
| xnox | barry: see my comment about the janitor..... | 21:29 |
| xnox | barry: for some reason it is only seeded on ubuntu-server..... | 21:29 |
| * xnox ponders if you can make computer-janitor to remove itself as obsolete software.... | 21:30 | |
| barry | xnox: i agree with you! we should just kill it and remove it from the archive. is that too late for quantal? think we'll piss too many people off? | 21:30 |
| barry | xnox: brilliant! :-D | 21:30 |
| xnox | barry: i think it's something like two pints to Laney and micahg and you can get it removed from quantal | 21:31 |
| * Daviey unseeds it | 21:31 | |
| Laney | erm | 21:32 |
| stgraber | Daviey: you should probably wait for a FFe... | 21:32 |
| Laney | yes indeed | 21:32 |
| barry | i don't care if it's just moved to universe. i just don't personally ever want to hack on it again :) | 21:32 |
| Laney | what good is moving it to universe? | 21:33 |
| Daviey | stgraber: barry raised one right there, FFe granted. | 21:33 |
| Laney | it's not supposed to be where you shove crap you don't want to look at | 21:33 |
| barry | Laney: honestly, none | 21:33 |
| Laney | this haste concerns me a bit | 21:33 |
| barry | Laney: would you feel better if i filed a official ffe for removal? | 21:34 |
| stgraber | barry: having a FFe would help so it can be properly documented that it's dropped and can be used as a tracking bug for archive removal too | 21:34 |
| Laney | I want to consider what use cases it has and if we can/should serve them elsewhere | 21:35 |
| Daviey | right, yes.. a bug for removal should exist. | 21:35 |
| stgraber | having to refer to irc logs when someone asks why something was removed from the media or the archive is suboptimal | 21:35 |
| xnox | barry: does update-manager use any of computer-janitor? e.g. do we need to keep computer-janitor, but can kill computer-janitor-gtk for example? | 21:35 |
| Daviey | I just disagree that shipping a package on the server on cd pool requires an FFe. | 21:35 |
| === salem_ is now known as _salem | ||
| Daviey | There is paperwork for the sake of it, and required paperwork.. Removal from the archive sure does require paperwork.. Dropping from server-ship, no thanks. | 21:36 |
| xnox | if ubuntu-server drops computer-janitor, then computer-janitor will move into component missmatches (surely) | 21:37 |
| infinity | Yes, and it will drop to universe. | 21:37 |
| barry | xnox: i would not change the vestiges of janitor in u-m, at least this cycle | 21:37 |
| infinity | That's entirely unrelated to people talking about removing it from the archive. | 21:37 |
| xnox | ok. | 21:37 |
| barry | xnox: but the c-j package itself has the dbus service, gtk, cli. all those must die | 21:38 |
| stgraber | Daviey: I disagree but don't feel like arguing about it now (and don't particularly care for this specific one). | 21:38 |
| xnox | barry: hmm... binary packages, not source please: is the above crash in the gtk app? then we can drop computer-janitor-gtk (bin) but leave the computer-janitor (bin) | 21:38 |
| infinity | xnox: And how does that help anyone? The source is buggy regardless. :P | 21:39 |
| xnox | regardless computer-janitor (src) will stay in main cause u-m build-deps on computer-janitor (bin) | 21:39 |
| * xnox should re-read the bug report again =))))) | 21:39 | |
| infinity | (And u-m build-deps on c-j? reverse-depends(1) doesn't think so) | 21:40 |
| barry | xnox: i don't think u-m depends on c-j. it has a breaks, but that's it afaict | 21:40 |
| barry | c-j depends on u-m because if its incestuous relationship | 21:40 |
| xnox | .... it also fails to build from source?! | 21:40 |
| infinity | Nothing reverse depends or build-depends on c-j. | 21:40 |
| xnox | barry: ok. | 21:41 |
| * barry files the ffe | 21:41 | |
| xnox | how is it an "remove from the archive & FFe" or "just remove from the archive"? | 21:41 |
| xnox | I thought FFE is for including stuff, not dropping. | 21:42 |
| Daviey | removing a feature, is still a feature :) | 21:42 |
| stgraber | xnox: FFe is for any feature change to the archive, removing something from a product or removing something from the archive are both changes | 21:42 |
| xnox | ah... so FFe for feature deltas ;-) | 21:42 |
| infinity | Indeed. | 21:43 |
| infinity | Otherwise, we could remove all installation images, drop all desktop tasks, and leave people with di netboot images, and that would totally not violate feature freeze. | 21:43 |
| * infinity runs off to do that and giggles madly. | 21:43 | |
| * Daviey realises that rdepends seems to think Breaks: is a depends? | 21:44 | |
| infinity | Daviey: apt-cache rdepends just shows "relationships". | 21:44 |
| infinity | Daviey: It's badly named. | 21:44 |
| infinity | Daviey: Use reverse-depends(1) instead. | 21:44 |
| Daviey | yeah.. i was just poking it. | 21:45 |
| Laney | so what does c-j do that's good? | 21:46 |
| Laney | ISTR that it removes old kernels? | 21:46 |
| xnox | Laney: it removes obsolete packages. Ideally it should do $ sudo apt-get autoremove; remove old kernels; remove dummy packages; | 21:46 |
| stgraber | smoser: isc-dhcp uploaded | 21:47 |
| infinity | Removing old kernels will be done more sanely in R (fixing that here, but not fussed about getting an FFe for Q) | 21:47 |
| barry | Daviey, Laney, xnox, infinity https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/1050071 | 21:47 |
| ubottu | Launchpad bug 1050071 in computer-janitor (Ubuntu) "[FFe] Remove Computer Janitor from the archive" [Undecided,New] | 21:47 |
| infinity | Removing dummy packages could totally be built into apt-get autoremove. | 21:47 |
| barry | and i am going to mark bug 1035869 wont fix | 21:47 |
| ubottu | Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869 | 21:47 |
| Laney | so while I agree it should be done, I just want to help good ideas not get lost | 21:48 |
| xnox | infinity: except sometimes c-j would get it wrong, e.g. look at the oldlibs section which at one point had "old" linux-standard compat libs | 21:48 |
| infinity | To be fair, I'm not sure *what* c-j actually cleans. | 21:48 |
| Daviey | Laney: there is a separate kernel team effort to remove old kernels, but ogasawara mentioned today that it will most likely be postponed to R | 21:48 |
| Laney | I remember that session at UDS | 21:48 |
| xnox | infinity: then it would remove those and $half of your $apps | 21:48 |
| infinity | Daviey: By "kernel team", you mean "Adam"? | 21:48 |
| barry | iirc, c-j does not clean old kernels anyway | 21:49 |
| xnox | maybe it stopped... it did at one point... until it got it wrong.... | 21:49 |
| Laney | well, what does it do? | 21:49 |
| Laney | autoremove, oldlibs? | 21:49 |
| ogasawara | infinity: indeed, I'd assumed you owned the clean old kernels bit | 21:50 |
| Daviey | infinity: Seems so.. https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels | 21:50 |
| barry | Laney: it's got a bunch of plugins which kind of try to figure out what is no longer needed. problems with this include bug #458872 | 21:51 |
| ubottu | Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Wishlist,Triaged] https://launchpad.net/bugs/458872 | 21:51 |
| barry | Laney: https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/458872/comments/3 | 21:52 |
| barry | :) | 21:52 |
| infinity | ogasawara: I do, and it'll get done before R, and I'll land it when we open the archive. | 21:52 |
| infinity | ogasawara: I see no point in pushing feature freeze for it, when it's the sort of thing that should have testing anyway. ;) | 21:52 |
| ogasawara | infinity: Oooo sweet | 21:52 |
| ogasawara | infinity: agreed, I see no hurry to land it for Q | 21:53 |
| Laney | barry: hah | 21:53 |
| Laney | update-manager should consider taking on some desirable features | 21:53 |
| xnox | Laney: buggy, unused, RoM, feature-less ...... | 21:53 |
| barry | Laney: yes or sc. mvo and i have discussed this in the past. | 21:54 |
| Laney | well I don't think it's unused or feature-less | 21:54 |
| Laney | as the bugs do come in | 21:54 |
| SpamapS | I know I asked this like, 3 weeks ago.. but.. are we any closer to having nvidia binary drivers for quantal? | 22:13 |
| * SpamapS has not dist-upgraded in a while | 22:13 | |
| ajmitch | SpamapS: they wfm on quantal | 22:16 |
| SpamapS | ah so perhaps they just quietly arrived? | 22:19 |
| SpamapS | I was still under the spell of "DONT DIST UPGRADE THERE IS A NEW X" | 22:20 |
| ajmitch | yeah, 304.43 was uploaded on the 28th, supports new X ABI | 22:20 |
| SpamapS | sweet | 22:23 |
| slangasek | barry: seems like my opinion has already been superseded by the discussion? :) | 22:29 |
| slangasek | barry: and I don't think you need a FFe for removal of a package | 22:30 |
| stgraber | slangasek: even when that involves unseeding from a supported media and altering rdepends (update-manager) so it can be dropped from the archive? | 22:31 |
| doko | infinity, can we give back packages on all archs before the test rebuild? | 22:34 |
| infinity | doko: Yeah, we can. I was waiting for powerpc to catch up. | 22:36 |
| stgraber | slangasek: oh, nevermind, got confused by the discussion earlier, nothing actually depends on it (or build-depends), so yeah, it's just a seed modification + removal from the archive | 22:36 |
| infinity | doko: I also kinda wanted to wait for RT#51115 to be done. :/ | 22:36 |
| slangasek | stgraber: exactly | 22:36 |
| bkerensa | bdmurray: sure | 22:37 |
| bkerensa | :D | 22:37 |
| barry | slangasek: thanks. i think it's not a bad idea to have the decision to remove officially recorded in a bug tho | 22:44 |
| slangasek | barry: quite, that's definitely preferred from the archive admin side | 22:46 |
| slangasek | barry: bug against the package, assign to ubuntu-archive | 22:47 |
| barry | slangasek: i will be *so* happy to never have to look at that code again :) | 22:47 |
| xnox | barry: oh the irony of spending all that time =) | 22:49 |
| barry | xnox: s'ok. i've wasted more time on stupider things :) | 22:50 |
| Kardos | hey all | 22:59 |
| SpamapS | silly question.. why is rmadison so darn slow? | 23:15 |
| smoser | slangasek, you have any ideas ? the emit of the net-device-added is not un-like the hack i am quite likely to need to do to get precise functional (potentially emitting virtual-filesystems there). | 23:28 |
| xnox | SpamapS: isn't it a call to a cgi script which is well slow? maybe something similar can be redone in python and call it lpmadison and add it to ubuntu-dev-tools?! | 23:30 |
| cjwatson | SpamapS: Because it's at least four years since I put any effort into optimising madison-lite | 23:30 |
| cjwatson | xnox: oh FFS don't rewrite stuff for the sake of it | 23:30 |
| cjwatson | optimise it instead | 23:30 |
| cjwatson | now I know perl isn't the prevailing religion but it'll probably be faster than python for the lots of text processing involved here | 23:31 |
| xnox | cjwatson: is rmadison always up to date? I can't remember but I think I did see it to be behind launchpad. Especially with respect to unapproved uploads... unless I am wrong | 23:31 |
| cjwatson | and I will happily take patches to madison-lite | 23:31 |
| xnox | cjwatson: I'm about the canonical datasource, rather than choice of language here. If it works, don't touch it. | 23:32 |
| cjwatson | xnox: it uses /srv/archive.ubuntu.com/ubuntu on lillypilly | 23:32 |
| SpamapS | cjwatson: so its just a ton of data that it has to churn through? | 23:32 |
| SpamapS | I notice some packages come back very quickly while others just spin | 23:32 |
| cjwatson | SpamapS: Yeah, it has to recache each time the archive changs | 23:32 |
| cjwatson | If you're the first hit after an archive refresh, it'll take a while | 23:32 |
| cjwatson | I wouldn't expect it to be package-specific | 23:32 |
| SpamapS | ah so it leans heavily on the cache crutch :) | 23:32 |
| SpamapS | if you've already turned to that.. probably not a ton that can be done to optimize | 23:33 |
| cjwatson | It's possible that the cache is a pessimisation these days | 23:33 |
| cjwatson | It's years since I checked how the I/O works out | 23:33 |
| SpamapS | I can't imagine it would be overloaded | 23:33 |
| SpamapS | the server I mean | 23:33 |
| cjwatson | lillypilly has a bunch of stuff on it | 23:34 |
| SpamapS | true | 23:34 |
| cjwatson | load average: 4.22, 6.45, 7.96 | 23:34 |
| SpamapS | how many CPU's/spindles in that? | 23:34 |
| cjwatson | Admittedly 8 CPUs (well, might be HT going on) | 23:34 |
| cjwatson | I suspect it just needs a straightforward look at the algorithms before worrying about any of that | 23:35 |
| cjwatson | Remind me after 12.10 releases? :-) | 23:35 |
| SpamapS | cjwatson: bzr branch? | 23:35 |
| SpamapS | I once fancied myself a perl programmer | 23:35 |
| cjwatson | http://anonscm.debian.org/bzr/users/cjwatson/madison-lite/trunk | 23:35 |
| cjwatson | The cache is fairly noddy because it's trying to be as light on dependencies as possible | 23:36 |
| cjwatson | It could be that sqlite or something would be better | 23:37 |
| SpamapS | cjwatson: some pretty deep regex-fu in there too | 23:37 |
| xnox | well... non scientific benchmarking: debian and udd URLs are much faster than ubuntu URL queries | 23:37 |
| xnox | for test package after multiple runs. | 23:38 |
| xnox | no clue what debian & udd have deployed though | 23:38 |
| bdmurray | @pilot out | 23:39 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| ajmitch | the debian udd instance is on a new machine now, it's a postgres db | 23:39 |
| xnox | plus debian/udd output is formatted nicer | 23:39 |
| cjwatson | The Debian one is talking to the dak database directly | 23:40 |
| cjwatson | So it never has to recache or anything | 23:40 |
| SpamapS | cjwatson: any reason we don't redo this to just poke launchpad directly? | 23:40 |
| cjwatson | Haha, you think the API will be faster | 23:40 |
| SpamapS | s/think/hope/ | 23:41 |
| cjwatson | The API is particularly weak on things like binary<->source mappings | 23:41 |
| SpamapS | ah yeah | 23:41 |
| SpamapS | too many joins | 23:41 |
| SpamapS | and it has to hit that whole version ordering thing | 23:41 |
| SpamapS | IIRC there is python being run for every row when that is used | 23:41 |
| SpamapS | as in, python inside pgsql | 23:41 |
| cjwatson | madison-lite might be optimised by shelling out to grep-dctrl for the hard work of parsing | 23:42 |
| cjwatson | That'll probably be faster than line-by-lining in perl | 23:42 |
| cjwatson | That would make the cache update faster, then either it wouldn't require a cache, or convert the cache to sqlite, based on profiling | 23:42 |
| SpamapS | well thats easy enough to strawman | 23:42 |
| cjwatson | That'd be my suggestion anyway | 23:43 |
| cjwatson | And it's easy enough to run locally to try | 23:43 |
| SpamapS | I'm looking at all the regexes right now.. | 23:43 |
| cjwatson | Yeah, I never profiled those, although to be fair I'm not sure how to avoid them and retain correctness given the interface | 23:43 |
| SpamapS | and they're really not that heavy on what usually drags regex perf down.. not lots of backrefs and such | 23:45 |
| cjwatson | No, I knew enough to avoid those | 23:46 |
| slangasek | smoser: to get precise functional> I was planning to SRU these mountall fixes after bake-in | 23:49 |
| smoser | slangasek, hm.. | 23:49 |
| smoser | ok then. | 23:49 |
| slangasek | smoser: as for emitting net-device-added, well, one hack is as good as another as far as I'm concerned ;) | 23:49 |
| smoser | i was planning on the cloud-init 'start on starting mountall' fixup | 23:50 |
| cjwatson | SpamapS: Oh, also, having a tool which produces this report based on Packages/Sources has been helpful to me on innumerable occasions in the past, when I suspect that other things are lying to me | 23:50 |
| slangasek | smoser: I don't see any problems specifically with faking net-device-added. I would like to fix this properly for the future | 23:50 |
| cjwatson | SpamapS: So I wouldn't like to end up maintaining two tools in order to keep that facility | 23:50 |
| smoser | slangasek, yeah. so you have an idea on how i could not emit that twice ? | 23:50 |
| slangasek | smoser: starting mountall> well, depends on your timeline I guess; I do think we want the SRU anyway because it fixes various NFS-at-boot issues | 23:50 |
| smoser | i could have a job that got the event and wrote a /run marker. | 23:51 |
| smoser | but that would seem racy | 23:51 |
| slangasek | smoser: nah, create a separate job in cloud-init that's 'start on container' and emits it | 23:51 |
| smoser | cloud-init has way to many upstart jobs :) | 23:51 |
| smoser | but sure, one more | 23:51 |
| smoser | thanks for your help. i'll poke more | 23:51 |
| SpamapS | cjwatson: indeed.. thats why Holmes has Watson. ;) | 23:52 |
| SpamapS | well and to watch his back | 23:52 |
| * cjwatson decided not to bother getting a doctorate just in order to be Dr Watson | 23:52 | |
| xnox | cjwatson: you probably can get an honorary degree | 23:54 |
| cjwatson | xnox: I'm not sure what the official stance is in the UK (and wp is vague on it) but I would not generally be inclined to use prenominal Dr for a holder of an honorary doctorate | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!