| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| mdeslaur | infinity, slangasek: I've put some test packages that enable amd64 flash here, and would really appreciate your invaluable comments, especially for the oneiric version : https://launchpad.net/~mdeslaur/+archive/64bitflash | 01:58 |
|---|---|---|
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| pitti | Good morning | 04:14 |
| ajmitch | morning pitti | 04:15 |
| pitti | ev: congrats, bcmwl wifi is now rather painless indeed! | 05:17 |
| pitti | ev: seems it's one tiny step away from perfection :) (bug 872119) | 05:17 |
| ubottu | Launchpad bug 872119 in ubiquity (Ubuntu) ""Error occurred while copying the network settings" on bcmwl machine" [Undecided,New] https://launchpad.net/bugs/872119 | 05:17 |
| micahg | @pilot in | 05:52 |
| === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg | ||
| === tkamppeter__ is now known as tkamppeter | ||
| dholbach | good morning | 07:07 |
| ev | pitti: argh. that one is entirely my fault and will take all of two seconds to fix | 08:00 |
| pitti | ev: not a dealbreaker; it makes it a whole lot more easy to use broadcom cards :) | 08:00 |
| pitti | ev: does that only affect bcmwl, or other wifi (such as intel), too? | 08:01 |
| ev | pitti: the copying of network-manager's brain to the installed system is broken, so it'll affect any card | 08:03 |
| ev | so the user will have to re-enter their wifi password | 08:03 |
| ev | and they'll all see that error dialog | 08:03 |
| pitti | ev: that more or less just copies /etc/NetworkManager/system-connections/*, or is there more to it? | 08:04 |
| ev | pitti: correct | 08:08 |
| micahg | @pilot out | 09:21 |
| === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| ev | @pilot in | 09:22 |
| === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === Riddelll is now known as Riddell | ||
| tumbleweed | can someone in ubuntu-branches please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 | 11:08 |
| tumbleweed | and mark https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 as merged (or whatever we do for SRUs targetted at the release branch) | 11:08 |
| === dholbach_ is now known as dholbach | ||
| tumbleweed | https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/75850 is also uploaded | 11:15 |
| tumbleweed | https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 appears to be rejected | 11:18 |
| doko | Laney, did you sort out the cairo-dock debian/upstream miscommunication? | 11:22 |
| tumbleweed | cjwatson / james_w: two more to mark Merged: https://code.launchpad.net/~brunoqc/ubuntu/natty/lfm/lfm-fix-786491/+merge/77859 https://code.launchpad.net/~jtaylor/ubuntu/natty/singularity/fix-576504/+merge/78286 | 11:28 |
| tumbleweed | that's it | 11:28 |
| Laney | doko: no, we should get on that as well | 11:39 |
| === dendro-afk is now known as dendrobates | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === Zic_ is now known as Zic | ||
| === dendrobates is now known as dendro-afk | ||
| === plars-holiday is now known as plars | ||
| === dendro-afk is now known as dendrobates | ||
| === dholbach_ is now known as dholbach | ||
| pitti | tumbleweed: done all but the bindwood one; what's with that one? | 14:19 |
| tumbleweed | pitti: I guess micahg is the pbest person to answer that one, but I'm assuming the fix is going into a different sourcepackage... | 14:34 |
| === kancerman_ is now known as kancerman | ||
| slangasek | jamespage: before setting plymouth:debug, were you able to reproduce bug #849414 consistently? | 14:41 |
| ubottu | Launchpad bug 849414 in plymouth (Ubuntu Precise) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/849414 | 14:41 |
| jamespage | slangasek: I was able to; however I appear to have stopped hitting that issue | 14:42 |
| slangasek | jamespage: so reverting plymouth:debug doesn't cause it to reappear either? :( | 14:42 |
| jamespage | slangasek, I running with it off now with no issues | 14:43 |
| jamespage | slangasek, so I was thinking about what had changed; I was getting an ugly text based splash when I saw the issue | 14:43 |
| slangasek | ah | 14:44 |
| jamespage | setting debug turned that off - and the issue went away | 14:44 |
| slangasek | that's helpful info :) | 14:44 |
| slangasek | right, I don't think setting debug turned it off, I think something else I did turned it off :) | 14:44 |
| slangasek | and your debug change just happened to coincide with other initramfs fixes | 14:44 |
| jamespage | slangasek, quite possibly | 14:44 |
| slangasek | jamespage: you could try re-breaking the graphics display by removing the plymouth-theme-ubuntu-logo package | 14:46 |
| jamespage | slangasek, sure - give me a couple of minutes | 14:46 |
| jamespage | slangasek, do you want me to turn debug on as well? | 14:47 |
| slangasek | jamespage: I'd try first without turning on debug (in case it's timing-sensitive), then if that reproduces the issue, turn on debug | 14:48 |
| jamespage | slangasek, ack | 14:48 |
| === Girly-Girl is now known as GirlyGirl | ||
| === sagaci_ is now known as sagaci | ||
| jamespage | slangasek, hmm - not able to reproduce | 14:54 |
| slangasek | jamespage: and it was 100% reproducible before? | 14:55 |
| jamespage | slangasek, yes - I turned debug mode on an off and the came and went | 14:55 |
| slangasek | jamespage: can I get apt logs, plus a big "here's where I turned on debugging" arrow, to try to work out what else changed on your system? | 14:55 |
| slangasek | jamespage: also, what's your video? | 14:55 |
| jamespage | slangasek, video is ATI Mobility Radeon HD 5400 Series | 15:00 |
| slangasek | jamespage: binary video drivers? | 15:01 |
| jamespage | slangasek, digging logs now | 15:05 |
| jamespage | slangasek, not sure whether its relevant but when I got the issues I had a really low res text based splash as well | 15:05 |
| jamespage | when I just tested it was much higher res | 15:05 |
| jamespage | slangasek, http://paste.ubuntu.com/706151/ | 15:05 |
| jamespage | slangasek, I think I first saw this issue on the 04/11 (indeed that is the date of the crash file that jhunt and I looked at earlier) | 15:06 |
| jamespage | I turned debug mode on then - and did a few reboots and could not reproduce | 15:06 |
| slangasek | oh heh | 15:06 |
| slangasek | higher res> so you've got vesafb loading and a framebuffer console, that's going to change things for sure | 15:07 |
| jamespage | slangasek, thats what I figured | 15:07 |
| slangasek | jamespage: this is with the cryptsetup package installed, right? | 15:07 |
| jamespage | slangasek, no | 15:07 |
| slangasek | hmm | 15:07 |
| slangasek | not sure why you would have gotten plymouth text without vesafb in that case | 15:08 |
| slangasek | are you using binary drivers? | 15:08 |
| jamespage | slangasek, yes | 15:08 |
| jamespage | slangasek, just to prove it - https://launchpadlibrarian.net/81898994/firegl-crash.jpg | 15:09 |
| slangasek | :-) | 15:10 |
| jamespage | thats from a diff bug | 15:10 |
| jamespage | looking at what i wrote on bug 865984 | 15:11 |
| ubottu | Launchpad bug 865984 in Ubuntu "firegl_sig_notifier crash on shutdown or reboot" [Undecided,New] https://launchpad.net/bugs/865984 | 15:11 |
| hallyn_ | slangasek: if you get a moment, can smoser and I ping you about a glibc bug and the likelyhood of it being considered fixable by upstream? | 15:12 |
| jamespage | I appear to have had a vesafb/framebuffer console until shortly before the 04/11 | 15:12 |
| jamespage | I raised that bug the same day I did the plymouth debug stuff | 15:13 |
| slangasek | hallyn_: just ask directly please :-) | 15:17 |
| cnd | seb128, is there still time to get the libgrip fix into oneiric? or should it be an sru? | 15:19 |
| seb128 | cnd, sru | 15:20 |
| cnd | ok | 15:20 |
| seb128 | cnd, which is fine we already got a stack of srus uploaded | 15:20 |
| seb128 | including compiz | 15:20 |
| cnd | ok | 15:20 |
| cnd | I'll prepare an sru upload then | 15:20 |
| pitti | Laney: wow, I wouldn't have expected breezy to top the upload score -- we had way fewer devs back then | 15:21 |
| pitti | Laney: well, maybe we uploaded 25 sets of langpacks :) | 15:21 |
| Laney | yeah, not sure what that is about | 15:22 |
| Laney | let me do the last query but s/oneiric/breezy/ | 15:22 |
| pitti | actually, it would be interesting to filter out all language-pack-* stuff | 15:22 |
| Laney | the data is all in udd ;-) | 15:22 |
| tseliot | slangasek: I'm seeing a lot of complaints on arm from apps such as gconf and metacity looking for gconfd-2 in /usr/lib/i386-linux-gnu/libgconf2-4/ instead of using /usr/lib/arm-linux-gnueabi/libgconf2-4/. There must be something wrong with my multi-arch setup here. Any ideas? (not a symlink works around the problem) | 15:23 |
| hallyn_ | mdeslaur: Bug 871847, I assume needs to wait for an SRU at this point? :) | 15:24 |
| ubottu | Launchpad bug 871847 in virt-viewer (Ubuntu) "Bad port '0' upon connect qemu+ssh" [High,Confirmed] https://launchpad.net/bugs/871847 | 15:24 |
| hallyn_ | slangasek: ok, i'm about to be afk for a few mins, but the problem basically is that grantpt in glibc starts out with a check for whether /dev/pts/{ptnum} is a valid slave. WIth /dev/pts being hardcoded. So if you call grantpt on /chroot/dev/pts/0, and /dev/pts/0 does not exist, the call will fail. | 15:25 |
| mdeslaur | hallyn_: yep, universe just went into freeze | 15:25 |
| hallyn_ | mdeslaur: zounds! | 15:25 |
| hallyn_ | ok, thanks :) | 15:25 |
| Laney | pitti: I don't think langpacks appear in -changes? | 15:25 |
| pitti | Laney: they don't | 15:26 |
| Laney | then they wouldn't be in these stats | 15:26 |
| pitti | Laney: ah, it's based on -changes@, not soyuz | 15:26 |
| hallyn_ | slangasek: this is only a problem when using a newly cloned devpts, so i'm not sure if glibc will deem that valid? | 15:26 |
| Laney | right | 15:26 |
| Laney | maybe autosyncs were announced back then? | 15:26 |
| slangasek | tseliot: uh? i386-linux-gnu vs. arm-linux-gnueabi, what's that about? You're saying you have an arm system, with i386 packages installed? | 15:26 |
| pitti | Laney: was just going to say :) | 15:26 |
| hallyn_ | slangasek: the workaround is doable but hacky - gotta fork, unshare a new mounts ns (with privilege), bind-mount /dev/pts, and then do the grantpt | 15:26 |
| pitti | Laney: right, see https://lists.ubuntu.com/archives/breezy-changes/2005-April/thread.html | 15:27 |
| bdmurray | stgraber: should bug 813065 be Fix Released - comment 9 leads me to think no | 15:27 |
| ubottu | Launchpad bug 813065 in ubiquity (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Fix released] https://launchpad.net/bugs/813065 | 15:27 |
| slangasek | hallyn_: why do you call grantpt against a chroot? | 15:27 |
| pitti | for the other months, too | 15:27 |
| slangasek | I don't think I understand the problem, sorry | 15:27 |
| Laney | let me exclude that then | 15:27 |
| tseliot | slangasek: no, they're all for arm | 15:27 |
| hallyn_ | slangasek: libvirt's parent process sets up /dev/pts/0 in the container's rootfs as a console for 'virsh console' to connect to | 15:27 |
| Laney | a much different picture emerges | 15:28 |
| stgraber | bdmurray: comment #9 was before Steve sent me a merge proposal fixing it properly which got merged and uploaded (comment #10) | 15:28 |
| hallyn_ | slangasek: though in any case, since thamanpage doesn't mention anything, glibc definately is *wrong*. | 15:28 |
| Laney | pitti: http://paste.debian.net/135733/ | 15:28 |
| slangasek | tseliot: but you said "There must be something wrong with my multi-arch setup here" - have you *done* some special multiarch setup? | 15:28 |
| bdmurray | stgraber: okay then what is going on with bug 871936? | 15:28 |
| ubottu | Launchpad bug 871936 in ubiquity (Ubuntu) "Live session switches to VT console [nvidia]" [Undecided,New] https://launchpad.net/bugs/871936 | 15:29 |
| pitti | Laney: still respectable, compared to warty and hoary | 15:29 |
| hallyn_ | slangasek: (but glibc might demand the manpage fix rather than the code fix :) | 15:29 |
| Laney | it's actually remaining fairly steady | 15:29 |
| stgraber | bdmurray: I'm not sure, maybe slangasek has an idea but AFAIK ubiquity-dm now does the right thing, it may simply be an nvidia specific flicker bug | 15:29 |
| tseliot | slangasek: no, I did nothing at all to set up multiarch. It's just that somehow apps are looking for that path | 15:29 |
| Laney | but oneiric moves up to fifth :-) | 15:29 |
| slangasek | hallyn_: heh, indeed... I don't know, sorry | 15:30 |
| hallyn_ | slangasek: nm, i guess i should join the m-l rather than bug you about it :) thanks | 15:30 |
| slangasek | tseliot: what's the exact error message? | 15:31 |
| tseliot | slangasek: "failed to activate configuration server: Failed to execute program /usr/lib/i386-linux-gnu/libgconf2-4/gconfd-2: Success | 15:31 |
| bdmurray | stgraber: okay the patch didn't seem hardware specific to me | 15:31 |
| tseliot | slangasek: this comes from gnome-settings-daemon, metacity, etc. | 15:31 |
| stgraber | bdmurray: indeed, it fixes flickerless for any graphic card that does work correctly with flickerless | 15:32 |
| stgraber | bdmurray: which AFAIK isn't the case of nvidia | 15:32 |
| hallyn_ | heh, i see, there really is no m-l | 15:33 |
| slangasek | tseliot: does i386-linux-gnu show up anywhere in config files under $HOME? | 15:33 |
| hallyn_ | libc-alpha it is. (weird name) | 15:33 |
| seb128 | slangasek, tseliot: I know what it is | 15:34 |
| slangasek | seb128: oh? | 15:34 |
| seb128 | slangasek, well, maybe not | 15:34 |
| seb128 | slangasek, /usr/share/dbus-1/services/org.gnome.GConf.service is in gconf2-common which is arch all | 15:34 |
| seb128 | but "Exec=/usr/lib/libgconf2-4/gconfd-2" there | 15:35 |
| slangasek | jamespage: when you said "04/11", you meant "04/10", right? | 15:35 |
| slangasek | seb128: hmm | 15:35 |
| jamespage | slangasek, hrm - yep | 15:36 |
| tseliot | seb128, slangasek: but then how would it look for i386-linux-gnu ? | 15:36 |
| seb128 | tseliot, the arch all is built on i386 | 15:36 |
| seb128 | so it would have the i386 path | 15:36 |
| slangasek | tseliot: I don't know; and I've not seen such an error on amd64 | 15:36 |
| seb128 | but that doesn't seem to be it | 15:36 |
| seb128 | the .service has non multiarch paths | 15:36 |
| seb128 | that was just an idea, ignore me ;-) | 15:36 |
| tseliot | seb128, slangasek: having a hardcoded path shouldn't be too good anyway | 15:36 |
| ogra_ | slangasek, i think i saw the same issue being discussed in #linaro this weekend | 15:38 |
| ogra_ | there must be a bug open for it already | 15:38 |
| seb128 | tseliot, ogra_, slangasek: is linaro or somebody shipping a multiarched version of gconf? | 15:38 |
| seb128 | our libgconf is not on multiarch | 15:38 |
| tseliot | that's a good question | 15:39 |
| seb128 | but it seems the service in arch all binary would lead to that question if somebody did a multiarch build without changing it to arch any | 15:39 |
| ogra_ | seb128, no idea, i think they are still working on switching their image builds to oneiric | 15:39 |
| seb128 | that's the only way I could explain it | 15:39 |
| ogra_ | (linaro is one release behind since they do monthly releases) | 15:39 |
| seb128 | question->error | 15:39 |
| seb128 | ogra_, well, we need multiarched gconf | 15:40 |
| seb128 | so that's not being "behind" | 15:40 |
| tseliot | slangasek: and no, I can't find any references to i386 in $HOME | 15:40 |
| slangasek | jamespage: are you sure you don't have cryptsetup installed? | 15:40 |
| seb128 | it seems somebody has a custom multiarch version of gconf | 15:40 |
| ogra_ | the error showed up for them after switching to oneiric | 15:40 |
| slangasek | tseliot: hmm | 15:40 |
| seb128 | ogra_, can you ask them their version of gconf? | 15:40 |
| ogra_ | i didnt follow that deeply, but i know they opened a bug | 15:40 |
| jamespage | slangasek, yes - http://paste.ubuntu.com/706181/ | 15:40 |
| slangasek | seb128: what do you mean by "multiarched gconf"? We should only have one copy of the daemon running... | 15:41 |
| tseliot | ogra_: right, I can only reproduce the problem in oneiric | 15:41 |
| seb128 | slangasek, the service is dbus activated, if the path was multiarch specific but they have a .service in arch:all that would lead to such issues | 15:41 |
| slangasek | ok | 15:41 |
| seb128 | slangasek, dbus would be trying to spawn the i386 location | 15:41 |
| slangasek | right; so when multiarching gconf, the daemon should be split out of the library package... | 15:42 |
| seb128 | or the .service should be in an arch:all binary | 15:42 |
| seb128 | so it gets the right location for each arch | 15:42 |
| tseliot | the latter sounds easier | 15:43 |
| seb128 | slangasek, the daemon is already splitted out of the library | 15:43 |
| seb128 | the issue is that the dbus service which has the service location is in gconf2-common arch:all | 15:43 |
| seb128 | we should just move the .service with the daemon when we multiarch it | 15:43 |
| seb128 | well, that's just guess work on what their issue is, but "/usr/lib/i386-linux-gnu/libgconf2-4/" doesn't make sense if gconf has not been changed for multiarch | 15:44 |
| seb128 | so I guess somebody did that work in a ppa or something | 15:44 |
| seb128 | ogra_, tseliot, slangasek: | 15:46 |
| seb128 | https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 | 15:46 |
| seb128 | "Convert to multiarch, gconf: DONE" | 15:46 |
| seb128 | so yeah, "linaro bug" I guess | 15:47 |
| ogra_ | seb128, i dont see that bug here and have no issues | 15:47 |
| ogra_ | i just saw it being discussed by the linaro gusy | 15:47 |
| seb128 | ogra_, well that didn't land in Ubuntu for sure | 15:47 |
| ogra_ | *guys | 15:47 |
| seb128 | ogra_, their workitem is DONE so I guess they have their own version somewhere | 15:47 |
| seb128 | in any case not an Oneiric issue ;-) | 15:47 |
| ogra_ | oh, its a linaro spec | 15:47 |
| * ogra_ missed that | 15:47 | |
| ogra_ | there it is | 15:49 |
| ogra_ | bug 871892 | 15:49 |
| ubottu | Launchpad bug 871892 in Linaro "org.gnome.GConf.service contains i386 pathname" [Undecided,New] https://launchpad.net/bugs/871892 | 15:49 |
| tseliot | ogra_, seb128, slangasek: that's the exact bug that I'm seeing here | 15:50 |
| seb128 | tseliot, what do you use? linaro or Ubuntu? | 15:50 |
| ogra_ | it was actually discussed yesterday ... | 15:51 |
| tseliot | seb128: ubuntu | 15:51 |
| seb128 | tseliot, dpkg -l | grep gconf | 15:51 |
| ogra_ | seb128, linaro builds their oneiric images from our archive plain, no additions but HW bits yet | 15:51 |
| ogra_ | they only start to work on oneiric this week | 15:51 |
| seb128 | ogra_, that doesn't make sense, gconf is not multiarch in Ubuntu, if it was I would knew it | 15:52 |
| ogra_ | seb128, right | 15:52 |
| tseliot | seb128: it doesn't seem to return anything | 15:52 |
| seb128 | tseliot, you don't have gconf installed? how did you do your install? | 15:52 |
| ogra_ | seb128, i dont kno wabout multiarch, what i know is that linaro only starts working on a release once ubuntu released it | 15:52 |
| seb128 | we still have a stack of things in the default install using it | 15:52 |
| ogra_ | so atm what they use should be plain ubuntu | 15:52 |
| ogra_ | since they only switched image builds to oneiric this week | 15:53 |
| seb128 | ogra_, well with their own layer or ppa on top I guess | 15:53 |
| ogra_ | for kernel and bootloaders,. yep | 15:53 |
| seb128 | ogra_, seeing https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 they need multiarch conversions over what oneiric has | 15:53 |
| ogra_ | but no desktop bits yet | 15:53 |
| ogra_ | right, that might be, i can only comment on what i observed ... i dont work in linaro :) | 15:54 |
| tseliot | seb128: apt-cache show gconf shows the installed size among other things | 15:54 |
| tseliot | seb128: err... gconf2 | 15:54 |
| seb128 | tseliot, how did you do your install? it's puzzling that you don't have gconf installed... are you sure you didn't type dpkg -l | grep gconf? | 15:54 |
| seb128 | type->typo | 15:55 |
| tseliot | seb128: yes, I typed it 3 times. I used our installer (which is probably the same as linaro) | 15:56 |
| ogra_ | no | 15:56 |
| ogra_ | linaro doesnt use any installer, they just install a metapackage in a chroot and tar that up | 15:57 |
| tseliot | ogra_: we're doing something similar, through the usual live-helper though | 15:57 |
| ogra_ | well, ubuntu installs tasks etc ... might get you minimally different results | 15:58 |
| seb128 | slangasek, just for the record it's indeed a linaro ppa with a multiarched version which has the .service in the arch all binary | 16:16 |
| seb128 | slangasek, i.e not an Ubuntu bug (tseliot get the issue on a custom build, not on an Ubuntu install) | 16:17 |
| * tseliot nods | 16:17 | |
| slangasek | seb128: ah, heh | 16:25 |
| slangasek | jamespage: did you for any reason set FRAMEBUFFER=y manually in your initramfs config? | 16:25 |
| jamespage | slangasek: no - I've not touched it | 16:26 |
| slangasek | jamespage: mmk | 16:27 |
| stgraber | SpamapS: I just posted the generate /etc/network/interfaces to bug 870214 | 16:27 |
| ubottu | Launchpad bug 870214 in open-iscsi (Ubuntu Oneiric) "iSCSI root installation creates manual eth0 configuration + long boot" [High,New] https://launchpad.net/bugs/870214 | 16:27 |
| stgraber | SpamapS: is it normal that the boot waits for 2 minutes with a /etc/network/interfaces like this one? | 16:27 |
| slangasek | jamespage: oh - could you try setting 'gfxpayload=text' manually in your /boot/grub/grub.cfg, instead of the default gfxpayload=$linux_gfx_mode? | 16:28 |
| jamespage | slangasek: OK | 16:28 |
| SpamapS | stgraber: it is normal that it would be waited on if eth0 doesn't exist | 16:28 |
| SpamapS | stgraber: since we're waiting for the full configuration of eth0. While its waiting, has eth0 been initialized by the kernel? | 16:29 |
| stgraber | SpamapS: hmm, I don't know for jamespage's setup, but I'm pretty sure eth0 existed in his case | 16:29 |
| stgraber | SpamapS: it's netboot with root on iscsi, so yes eth0 is initialized by ipconfig in the initramfs | 16:29 |
| SpamapS | Hm, so is it possible that we never get an 'ifup eth0' for that? | 16:30 |
| SpamapS | I would have thought 'ifup -a' would catch it in /etc/init/networking.conf | 16:30 |
| stgraber | sadly my test environment here lets me install over iscsi but not boot from it (I'm missing my usual PXE server ;)) | 16:32 |
| stgraber | oh, actually I guess I can extract the kernel and initrd and have kvm boot that directly | 16:32 |
| jamespage | stgraber, SpamapS: I still have one of the test images locally if you want me to poke it in any way | 16:32 |
| slangasek | SpamapS, stgraber: there should still be a network-device-add event which should still cause upstart to trigger an 'ifup eth0' - but what happens if you run 'ifup eth0' for this? | 16:33 |
| SpamapS | I'd guess then that the problem is ifup -a doesn't, for whatever reason, see eth0 as needing to come up.. and so doesn't execute the if-up.d jobs. | 16:33 |
| slangasek | it's not even an ifup -a | 16:33 |
| slangasek | it's /etc/init/network-interface.conf | 16:33 |
| SpamapS | Oh so you still get the network-device-added ? | 16:33 |
| slangasek | of course | 16:33 |
| slangasek | that comes from udev from coldplugging | 16:33 |
| SpamapS | well then wtf :) | 16:33 |
| SpamapS | is it possible thats happening before virtual-filesystems ? | 16:34 |
| slangasek | no | 16:34 |
| SpamapS | ah right, udev starts on virtual filesystems | 16:34 |
| stgraber | jamespage: is commented the two lines for eth0 in /etc/network/interfaces fixing the issue for you? | 16:37 |
| stgraber | (looking for a workaround) | 16:38 |
| jamespage | stgraber: rings a bell - lemme try | 16:38 |
| stgraber | slangasek, SpamapS, jamespage: Current discussion here (with Daviey) is that we could probably just release note the workaround for now, then SRU a fix if that doesn't involve changing /etc/network/interfaces, otherwise just have it fixed for P | 16:39 |
| stgraber | assuming commenting these lines workarounds the issue for jamespage | 16:40 |
| jamespage | stgraber: I don't think that its an issue thats going to impact alot of people so thats prob fine | 16:40 |
| jamespage | slangasek, just tried gfxpayload=text == no seg fault | 16:41 |
| stgraber | jamespage: yeah, it's also a case where if you boot a server, you'll already wait 5 minutes for your BIOS, waiting 2 minutes for your first boot shouldn't be too bad (assuming you know the workaround and apply it then) | 16:41 |
| slangasek | jamespage: did you get the 640x480 text again? | 16:41 |
| === deryck is now known as deryck[lunch] | ||
| jamespage | slangasek, I think so - ssd so boots fast - lemme double check | 16:42 |
| jamespage | stgraber: commenting the entries in /etc/network/interfaces works around the issue for me | 16:43 |
| stgraber | SpamapS: ok, so we at least have a workaround | 16:44 |
| slangasek | stgraber: why do we want this 'manual' entry in /e/n/i? | 16:45 |
| stgraber | slangasek: I can't think of a good reason for that, though I still think "inet manual" should work as it's valid syntax | 16:47 |
| slangasek | should work, but it's meant for interfaces where you're going to actually *do* something via up/down rules | 16:48 |
| slangasek | AFAICS this is a misuse of it; so if we can fix the bug by dropping that generated entry... | 16:48 |
| jamespage | slangasek: double checked - did boot in 640x480 text mode | 16:48 |
| slangasek | jamespage: and still no crash? Great, I'll mark the bug as fixed ;P | 16:48 |
| jamespage | slangasek: no crash | 16:49 |
| stgraber | slangasek: well, then I'll be happy to file another bug when I upgrade my servers where I have "inet manual" with a post-up and pre-down entry | 16:49 |
| stgraber | as they'll be affected by the same bug with a config that actually does something | 16:49 |
| slangasek | stgraber: or open an ifupdown task to go with the open-iscsi one | 16:49 |
| slangasek | and we can fix open-iscsi pre-release, and fix ifupdown post-release | 16:50 |
| SpamapS | slangasek: agreed on that, an empty manual entry is a place holder we don't need | 16:50 |
| SpamapS | Could it be that ifupdown agrees, and ignores it? | 16:50 |
| slangasek | dunno, testing | 16:51 |
| andreasn | jcastro, ping | 16:52 |
| jcastro | andreasn: hi | 16:52 |
| slangasek | SpamapS: I do see if-up.d scripts being run for my ifup of a manual interface, anyway | 16:52 |
| slangasek | SpamapS: and 'ifup foo' gets me a static-network-up event, so... dunno | 16:59 |
| slangasek | stgraber: ^^ | 16:59 |
| SpamapS | what about the upstart udev bridge | 16:59 |
| slangasek | stgraber: I'd suggest throwing some debugging into /etc/network/if-up.d/upstart to dump to a per-interface log file and see what's going on | 17:00 |
| SpamapS | is it racing with udev ? | 17:00 |
| SpamapS | like.. | 17:00 |
| SpamapS | it starts on starting udev .. | 17:00 |
| stgraber | jamespage: can you try that ^ | 17:00 |
| SpamapS | but does it return before its actually bridging? | 17:00 |
| slangasek | SpamapS: no, it always starts *before* udev and sits waiting on the netlink socket | 17:00 |
| slangasek | er | 17:00 |
| slangasek | SpamapS: I hope not :P I guess I can look | 17:00 |
| * SpamapS peeks at it too | 17:00 | |
| stgraber | slangasek: still working on getting my laptop back into a usable stage (for some reason my last reboot broke something) and then I'll try to get a complete iscsi setup for testing | 17:00 |
| slangasek | stgraber: ok :) | 17:01 |
| SpamapS | slangasek: no, as I would have expected, it adds the udev monitor before daemonizing | 17:02 |
| slangasek | SpamapS: right - I think we would be hearing about more things broken than just this, otherwise :) | 17:03 |
| SpamapS | if booting with --verbose , do we see the network-device-added event ? | 17:04 |
| slangasek | stgraber, SpamapS: I've changed my mind; there are legitimate corner case reasons why we want the entry for the interface... so network-manager doesn't even try to touch it :P | 17:11 |
| slangasek | stgraber: so I don't think we should change open-iscsi for release, but instead just SRU ifupdown (once we figure out what the problem is!) | 17:11 |
| stgraber | slangasek: sounds good. I'll mark the bug as invalid for open-iscsi, we already have a task for ifupdown and the release notes | 17:12 |
| hallyn_ | smoser: I emailed the glibc-alpha m-l about the grantpt issue. We'll see what they say | 17:16 |
| jamespage | stgraber, I logged some debug output with the manual entry in /e/n/i present and commented - neither generates any log data for eth0 from /etc/network/if-up.d/upstart | 17:16 |
| hallyn_ | (I'm expecting a spanking, tbh, but hopefully not) | 17:16 |
| jamespage | only get a file for lo | 17:16 |
| stgraber | SpamapS: ^ | 17:17 |
| smoser | hallyn_, link ? | 17:17 |
| hallyn_ | smoser: http://www.cygwin.com/ml/libc-alpha/2011-10/msg00008.html | 17:19 |
| SpamapS | jamespage: can you boot with --verbose and look in /var/log/boot.log for the net-device-added event ? | 17:24 |
| jamespage | SpamapS, sure | 17:24 |
| slangasek | stgraber, jamespage, SpamapS: I notice that open-iscsi installs an if-up.d hook of its own | 17:24 |
| slangasek | which sorts lexically before upstart | 17:24 |
| slangasek | I wonder if it's broken? | 17:25 |
| SpamapS | the lo hook fired... | 17:25 |
| slangasek | well, the hook special-cases lo ;) | 17:26 |
| stgraber | slangasek: oh, actually, the upstart script shipped by open-iscsi looks like it could break the boot | 17:26 |
| slangasek | oh excellent | 17:26 |
| slangasek | Oh dear | 17:27 |
| stgraber | I didn't even notice that thing before but that can explain a lot of things ;) | 17:27 |
| stgraber | http://paste.ubuntu.com/706245/ | 17:27 |
| stgraber | I'm guessing that as the interface is already in /run/network/ifstate, it's going to be entirely ignored by ifupdown and so we won't get the event... | 17:28 |
| slangasek | yes, it forcibly bypasses if-up.d, it writes to /run/network/ifstate without locking, and it fails to use a proper 'instance' declaration for network-interface | 17:28 |
| stgraber | I'm wondering if just removing it would be enough | 17:29 |
| slangasek | stgraber: so it looks like an open-iscsi-specific failure after all | 17:29 |
| stgraber | jamespage: can you try that? ^ | 17:29 |
| jamespage | stgraber: just doing the verbose boot - one second | 17:29 |
| slangasek | cjwatson: you seem to have written /etc/init/iscsi-network-interface.conf; do you recall why you were trying to prevent /etc/network/if-up.d scripts from being run for an iscsi interface? | 17:30 |
| stgraber | slangasek: we are going for dinner now, if it's confirmed that it works fine without the upstart job, I'll just remove it and upload to -proposed | 17:31 |
| slangasek | bug #457767 | 17:31 |
| ubottu | Launchpad bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767 | 17:31 |
| slangasek | stgraber: enjoy :) | 17:31 |
| SpamapS | slangasek: I would concurr with stgraber's assessment, this script does look like its our culprit. | 17:31 |
| SpamapS | slangasek: or, your assessment, somebody's | 17:32 |
| slangasek | SpamapS: yep - question is how we fix it... we shouldn't just drop it without taking care on upgrade to make sure users don't have configuration for the interface in /etc/network/interfaces that's going to cause the system to blow up on next boot | 17:32 |
| SpamapS | yeah this bug-ectomy requires some delicate scalpel work | 17:33 |
| SpamapS | I'm not sure why the author wanted to avoid the *.d scripts | 17:34 |
| slangasek | "the author" being cjwatson | 17:34 |
| SpamapS | ok, so we can ask him. :) | 17:34 |
| SpamapS | because that is precisely the issue we have, is that they were avoided | 17:35 |
| slangasek | yep | 17:35 |
| === deryck[lunch] is now known as deryck | ||
| jamespage | SpamapS, stgraber, slangasek: --verbose boot - http://paste.ubuntu.com/706249/ | 17:37 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | jamespage: yep, that's consistent with our theory. kill /etc/init/iscsi* and try again? | 17:38 |
| jamespage | slangasek, appears to be much happier | 17:39 |
| jamespage | stgraber: ^^ | 17:40 |
| jamespage | no network failsafe and I can see log data for eth0 as well as lo | 17:40 |
| slangasek | jamespage: thanks; can you send that info to the bug? | 17:43 |
| jamespage | slangasek, done | 17:46 |
| slangasek | jamespage: cheers :) | 17:46 |
| jamespage | np | 17:46 |
| SpamapS | slangasek: I don't see anything in the default server install that would be "bad" during if-up.. I was thinking though, don't we need to make sure eth0 is never brought down? | 17:51 |
| slangasek | SpamapS: certainly | 17:52 |
| SpamapS | I don't think it will be brought down but wondering if maybe some scripts down/up the interface. | 17:53 |
| slangasek | nothing should for interfaces not explicitly configured to have such things done | 17:55 |
| slangasek | (e.g., bridge interfaces) | 17:55 |
| SpamapS | just trying to reason why we'd want to avoid those scripts | 17:55 |
| SpamapS | a lot of them make some pretty strong assumptions | 17:55 |
| SpamapS | though one might be able to argue that most iSCSI root boxes don't share the iscsi interface with the general network connection... it should still be possible | 17:56 |
| slangasek | well, as cjwatson admits in his comment, this is a layering violation... and now it's biting us :) | 17:57 |
| slangasek | jamespage: I've struck out as far as finding anything in your apt log that will explain it; the only relevant change I see is fglrx, and the only effect that had should have been reproducible with the gfxpayload change. Could you try downgrading fglrx to version 2:8.881-0ubuntu3, to see if it does bring back the segfault? | 18:44 |
| hallyn_ | smoser: do you mind if i fwd your testcase for the libvirt pty probelm to the m-l? | 18:52 |
| smoser | oh sure, they'll have a field day. | 18:56 |
| smoser | :) | 18:56 |
| hallyn_ | do you have your latest version somewhere? | 18:57 |
| hallyn_ | otherwise i can just use the first version, that's fine. | 18:59 |
| smoser | i ended up trashing the instance that had your iprovements | 19:00 |
| smoser | https://gist.github.com/1251979 is where ih ad what i had. | 19:01 |
| hallyn_ | smoser: thanks much | 19:01 |
| micahg | pitti: what was the question for me, I seem to have missed it? | 19:09 |
| === yofel_ is now known as yofel | ||
| === Quintasan_ is now known as Quintasan | ||
| === dendro-afk is now known as dendrobates | ||
| === SanbarCo1puting is now known as SanbarComputing | ||
| micahg | pitti: it seems that librpc-xml-perl was demoted prematurely | 20:18 |
| micahg | pitti: oh, nevermind.. | 20:19 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| === plars is now known as plars-afk | ||
| micahg | cjwatson: when we merge dpkg for P, are we going to get the hardening flags emitted like Debian is doing? | 20:47 |
| === dendrobates is now known as dendro-afk | ||
| cjwatson | slangasek,SpamapS,stgraber: all I can really say from this vantage is that it caused a problem at the time, as noted in the comment in the script; I'm having trouble parsing my comment about /etc/network/*.d/ scripts, so it's entirely possible I was just confused | 20:50 |
| cjwatson | micahg: I intend to keep the flags in the environment for precise, because otherwise we'll have to convert too many packages to avoid lossage | 20:51 |
| micahg | cjwatson: i.e. different behavior than Debian? | 20:51 |
| cjwatson | micahg: for P, yes | 20:51 |
| cjwatson | although packages that have been converted to the new scheme in Debian shouldn't break; at worst, they'll have the flags specified twice | 20:52 |
| micahg | cjwatson: is this for stuff we already have in our environment or everything? My concern is that Debian is starting to abandon hardening-wrapper usage and starting to use the dpkg buildflags | 20:52 |
| cjwatson | micahg: packages that ask for dpkg-buildflags output will get it, don't worry | 20:53 |
| micahg | cjwatson: awesome, thanks :) | 20:53 |
| cjwatson | I'm just not going to remove stuff that wew already have in our environment | 20:53 |
| cjwatson | not until Q | 20:53 |
| micahg | yeah, that makes sense for an LTS | 20:53 |
| cjwatson | stgraber: it's possible I regarded manual as a hack and didn't want to depend on it | 20:54 |
| cjwatson | but I don't appear to have recorded my thought process very clearly, sorry | 20:54 |
| micahg | cjwatson: maybe we should just leave it in the env unless it'll break stuff, ideally we do want hardening by default (but we can save that discussion for UDS Q :)) | 20:54 |
| cjwatson | stgraber: I am a little concerned that there may be upgraded systems around that don't use the manual method | 20:54 |
| cjwatson | micahg: the things in the environment at the moment aren't hardening | 20:54 |
| micahg | ah | 20:55 |
| cjwatson | they're default optimisation settings and -Wl,-Bsymbolic-functions | 20:55 |
| cjwatson | we want to migrate to dpkg-buildflags in the long term because it offers more flexibility | 20:55 |
| cjwatson | for example it will make it easier to test-build the world with different compiler flags without having to use a compiler wrapper | 20:56 |
| SpamapS | cjwatson: its probably worth a review of the other methods and if-up.d scripts to see if they do anything we might perceive as dangerous to an iSCSI root.. if we can't find anything.. maybe just axe the upstart job. | 20:57 |
| cjwatson | actually | 20:59 |
| cjwatson | so the problem was that if you did an install with the installer acquiring its network settings by DHCP, before my hack in partman-iscsi, it got 'iface eth0 inet dhcp' | 21:00 |
| cjwatson | then when you did 'ifup eth0', it ran dhclient, which tore the interface down and set it back up again | 21:00 |
| cjwatson | and the world imploded | 21:00 |
| cjwatson | I think you should ignore my comment about .d scripts, it seems to be a red herring | 21:00 |
| kees | micahg: yeah, the trick is watching for packages that convert from hardening-wrapper/-includes to dpkg-buildflags to make sure they include +pie,+bindnow | 21:01 |
| cjwatson | so what this upstart job does is force ifup to do nothing for that interface, even if /etc/network/interfaces is misconfigured | 21:01 |
| cjwatson | removing that *might* be safe, but I would prefer to have say an 'ifpretendup' interface in ifupdown | 21:01 |
| cjwatson | or 'ifup --pretend' or whatever | 21:02 |
| micahg | kees: right, that's what I was asking about in my meek way :) | 21:02 |
| cjwatson | which would force the interface to be considered up (in ifstate) but not actually do any work | 21:02 |
| cjwatson | then we could use that in the upstart job (and fix the instance bug) and it would then be able to emit the right upstart event | 21:03 |
| cjwatson | although a temporary hack that might do the job for now would be to emit that event by hand | 21:04 |
| cjwatson | not the right fix but it would kill the delay | 21:04 |
| cjwatson | and should be no worse than what was there before | 21:04 |
| kees | micahg: I'd like to figure out some way to do build regression testing in Debian and Ubuntu that would alert when a package suddely stopped building with a flag or something, but it's seriously non-trivial to get right | 21:05 |
| * jdstrand waves to kees | 21:06 | |
| kees | hi jdstrand! :) | 21:06 |
| micahg | kees: emit the build flags at build time, then have LP parse the logs and fail if there's a regression? | 21:06 |
| jdstrand | :) | 21:06 |
| kees | micahg: yeah, but right now the bulk of that isn't visible in ubuntu's builds since we enforce it in the compiler without flags | 21:06 |
| ajmitch | you'd want to build the same source both with & without flags to narrow the cause of build failures down | 21:07 |
| stgraber | cjwatson: http://paste.ubuntu.com/706334/ for the workaround? | 21:08 |
| slangasek | stgraber: that doesn't solve the issue. If we're going to try to use this as a workaround, we ought ta have this job just call /etc/network/if-up.d/upstart with the right args | 21:10 |
| slangasek | (net-device-up is not the event we care about, it's static-networking-up) | 21:10 |
| hallyn_ | smoser: well... resposne was not unexpected but still unfortunate :) pls let me know if my patched libvirt worked for you | 21:10 |
| cjwatson | yeah, may as well not add *more* layering violations I guess | 21:11 |
| cjwatson | does my proposed interface extension to ifup sound reasonable longer-term though? | 21:11 |
| cjwatson | (static-network-up not static-networking-up ...) | 21:12 |
| slangasek | cjwatson: what does "pretend" give you that just getting the interface properly set as "manual" would not? | 21:12 |
| slangasek | because the upstart hook may not be the only one we care about running | 21:12 |
| slangasek | I dunno, would we want avahi-autoipd to run? | 21:13 |
| cjwatson | may be misnamed, what I want it to do is not actually do the main body of manipulating the interface | 21:13 |
| cjwatson | I'm happy for it to run all the hook scripts | 21:13 |
| cjwatson | (as I say I think my two-year-old comment was misleading) | 21:13 |
| slangasek | well, perhaps not unless we FIX that hook.. again... since it's adding a stupid route instead of bringing up an address | 21:14 |
| stgraber | cjwatson, slangasek: http://paste.ubuntu.com/706338/ | 21:14 |
| cjwatson | useless use of env :-) | 21:14 |
| stgraber | oh, indeed ;) | 21:14 |
| slangasek | :) | 21:14 |
| slangasek | otherwise, provided that works I think it looks good | 21:14 |
| cjwatson | do we need to handle ipv6? | 21:14 |
| cjwatson | appreciating the irony of me asking stgraber this | 21:15 |
| slangasek | :-) | 21:15 |
| slangasek | the hook doesn't distinguish by addrfam | 21:15 |
| cjwatson | I'm guessing open-iscsi is far too stupid to handle ipv6 | 21:15 |
| stgraber | haven't seen any hardware doing IPv6 PXE yet | 21:15 |
| * ajmitch didn't think PXE was specced yet for ipv6 | 21:15 | |
| cjwatson | it is | 21:15 |
| cjwatson | well, ish | 21:15 |
| ajmitch | oh? that's useful | 21:15 |
| cjwatson | it is in uefi, I'm not sure about bios | 21:15 |
| cjwatson | although only a uefi version nobody has yet | 21:16 |
| cjwatson | so still chocolate teapot level of usefulness | 21:16 |
| stgraber | jamespage: still around? | 21:16 |
| slangasek | regardless, the upstart hook fires once for each interface and doesn't care about address family; no point trying to make the open-iscsi job fancy | 21:17 |
| jamespage | stgraber, yep - running iscsi root tests :-) | 21:17 |
| stgraber | jamespage: awesome. Can you move the upstart script back into /etc/init, revert the changes to /etc/network/interfaces (so we have the inet manual in there) and apply this diff: http://paste.ubuntu.com/706339/? | 21:17 |
| jamespage | stgraber, just cooking one now - no problem | 21:18 |
| stgraber | jamespage: then try again but with "inet dhcp" instead of "inet manual" and check that it works too and finally with the two lines commented again | 21:18 |
| stgraber | that should cover most of the use cases ;) | 21:18 |
| jamespage | stgraber: all three of those test cases work great with the patch applied | 21:27 |
| jamespage | \o/ | 21:27 |
| stgraber | yeah! | 21:29 |
| smoser | hallyn_, tested your suggested patch | 21:31 |
| smoser | http://paste.ubuntu.com/706342/ | 21:31 |
| smoser | is what i get | 21:31 |
| stgraber | skaet, slangasek, cjwatson: Should I push that fix to -proposed and if Daviey really wants it we copy it and rebuild server? | 21:31 |
| smoser | you should be able to easily recreate this now that we know how to make it so that /dev/pts/0 wont be availalble. | 21:31 |
| cjwatson | stgraber: yes please | 21:34 |
| cjwatson | 22:26 <slangasek> stgraber: ^^ so open-iscsi to -proposed please :) | 21:34 |
| cjwatson | (#ubuntu-release) | 21:34 |
| bdrung_ | andersk: mozilla-devscripts fixed | 21:36 |
| ev | @pilot out | 21:43 |
| === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| andersk | bdrung_: Alright, trying that. | 21:44 |
| hallyn_ | smoser: ok, don't know why, that's gonna be lower priority | 21:45 |
| bdrung_ | andersk: how long will your test take? | 21:45 |
| andersk | bdrung_: Almost done, I think. | 21:45 |
| andersk | I recompiled xul-ext-lightning after adding ‘Breaks: ${xpi:Breaks}’ to all its debian/control stanzas, and ended up with what appears to be the right thing. | 21:46 |
| andersk | And the result installs and works. | 21:47 |
| bdrung_ | andersk: last chance to prevent the upload of m-d 0.29 | 21:48 |
| andersk | I say ship it! :-) | 21:49 |
| achiang | when does DIF usually occur relative to opening the archive? | 21:50 |
| micahg | achiang: 7-9 weeks in | 21:52 |
| achiang | micahg: ok, thanks | 21:52 |
| achiang | 7-9 weeks to get a new package in then. :-/ | 21:53 |
| micahg | achiang: no, you can request new stuff up to feature freeze, DIF is the automatic sync | 21:53 |
| achiang | oh, how long is feature freeze? | 21:53 |
| micahg | achiang: 2 months before release | 21:54 |
| achiang | micahg: ok thanks | 21:54 |
| micahg | achiang: the earlier the better though :) | 21:54 |
| achiang | micahg: yes, it's a somewhat tricky package, and i'm going the debian route | 21:54 |
| achiang | micahg: if i can't get it into debian before feature freeze, is there an ubuntu way to get it into universe? | 21:55 |
| micahg | achiang: sure, REVU is still open for the moment | 21:56 |
| bdrung_ | but the debian way is the easier way | 21:56 |
| achiang | bdrung_: yes, i got my package's dependency into debian just last week | 21:57 |
| achiang | bdrung_: but that took a while. i'm concerned about this new package i'm working on | 21:57 |
| bdrung_ | achiang: what package? | 21:57 |
| achiang | bdrung_: https://forge.betavine.net/scm/?group_id=76 -- wader-core is a drop-in, API compatible replacement for ModemManager | 21:58 |
| achiang | bdrung_: it supports Vodafone modems really well | 21:58 |
| Laney | you can probably ask the same sponsor to look at this one | 21:58 |
| achiang | Laney: yes, that was my plan | 21:59 |
| sammy | anyone using auth-update-config and authing from ldap? | 22:07 |
| sammy | supposedly its changes to common-password in pam.d should allow using passwd to change ldap passwords. everything else is running smoothly | 22:08 |
| sammy | nm google is my friend :) | 22:09 |
| bdrung_ | andersk: released :) | 22:21 |
| andersk | Cool. How are we going to handle rebuilding the extension packages against the new version? | 22:24 |
| bdrung_ | andersk: it requires manual work (adding ${xpi:Breaks}) | 22:26 |
| bdrung_ | andersk: m-d will be synced to precise. for which release do you need this feature? | 22:26 |
| andersk | bdrung_: I dunno, is oneiric likely to see Firefox 8 or Thunderbird 8 as an SRU? | 22:27 |
| bdrung_ | yes | 22:28 |
| andersk | The status quo seems to be that a Thunderbird 8 SRU in oneiric will break Lightning, like Thunderbird 7 did during the dev cycle, and it would be nice to have the package manager detect that before it causes a real problem. | 22:31 |
| micahg | andersk: we'll be SRUing lightning at the same time | 22:32 |
| bdrung_ | micahg: will you SRU mozilla-devscripts too? | 22:33 |
| bdrung_ | micahg: or just patch the heavy stuff in? | 22:33 |
| micahg | bdrung_: not planning on it | 22:33 |
| chrisccoulson | What feature in mozilla-devscripts? | 22:43 |
| bdrung_ | chrisccoulson: m-d 0.29 adds a ${xpi:Breaks} | 23:42 |
| === dendro-afk is now known as dendrobates | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
