| cjwatson | xnox: https://rt.admin.canonical.com/Ticket/Display.html?id=68468 | 00:06 |
|---|---|---|
| cjwatson | xnox: For now you'll just have to get IS to remove things for you | 00:06 |
| xnox | cjwatson: whilst modern style porter boxes would be nice, getting rapt to support "remove" command would be nice as well. | 00:08 |
| xnox | (limited to things outside of e.g. minimal and build-essentials or some such) | 00:09 |
| cjwatson | Maybe, but that just increases the chance of people clashing with each other. I'd rather we just had modern infra | 00:09 |
| infinity | xnox: Not supporting remove was an intentional design decision when we wrote rapt. | 00:13 |
| xnox | ok. | 00:13 |
| infinity | xnox: Because you removing a build-conflict that happens to be a build-dep that doko's 8h build-in-progress depdends on would suck. | 00:14 |
| infinity | (But yes, we should just move to the Debian way of doing things) | 00:14 |
| doko | ? | 00:15 |
| xnox | doko: don't worry, we are not _actually_ breaking one of your in-progress 8h builds. it's just hypothetical =) | 00:15 |
| infinity | doko: You were just being used as a fictional example, not being summoned. | 00:15 |
| doko | oh, I would like YOU to be summoned, and not just as a fictional example | 00:17 |
| infinity | doko: But, given our history, whenever I think of someone breaking a computer and affecting a long-running build, the hypothetical user is you. ;) | 00:17 |
| * infinity still remembers the week-long GCC builds on his Amiga... | 00:17 | |
| doko | yeah, glibc sucks with test suites | 00:17 |
| mwhudson | infinity: so that patch from andrew fixes the eglibc build for me | 00:19 |
| mwhudson | oh i guess i should also glom up the test case | 00:23 |
| infinity | mwhudson: Okay, can you give me an email with all the patches you know and love, and I'll get them queued up for the next upload? | 00:38 |
| infinity | mwhudson: So, that should be Will's setcontext patch, Will's testcase for same, and that 2-liner for the alignment issue. | 00:39 |
| infinity | mwhudson: With patch headers pointing to origin, since none of them are in git yet. :/ | 00:39 |
| mwhudson | infinity: i just commented on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1279620#9 | 00:39 |
| ubottu | Launchpad bug 1279620 in eglibc (Ubuntu Trusty) "stack corruption running "go install launchpad.net/juju-core/..."" [High,Confirmed] | 00:39 |
| mwhudson | infinity: i don't know the formatting for patch headers, i can go find it out i guess... | 00:40 |
| UBUNTUuser | hi guys I want to know if ubuntu 14.04 will work will daul boot | 00:40 |
| blkperl | UBUNTUuser: yep | 00:40 |
| infinity | mwhudson: Oh, I don't care if it's formatted in any specific way. Garbage above the diff is fine. | 00:40 |
| infinity | mwhudson: I can fix it up, I just want the refs. | 00:40 |
| mwhudson | infinity: is that bug comment useful? i can email them as well... | 00:41 |
| UBUNTUuser | you sure I am already having problems with ubuntu 13.10 | 00:42 |
| UBUNTUuser | I have a uefi which secure boot | 00:42 |
| UBUNTUuser | is on | 00:42 |
| blkperl | UBUNTUuser: your question is probably better suited for #ubuntu, this is the dev channel | 00:44 |
| UBUNTUuser | ok | 00:45 |
| infinity | mwhudson: Nope, that's perfect. | 00:45 |
| infinity | robert_ancell: Did you want your changelog for that lightdm to actually match reality? :P | 00:49 |
| robert_ancell | infinity, um... what did I write? | 00:49 |
| infinity | robert_ancell: s/greeter/cursor/ | 00:49 |
| robert_ancell | yeah, that would make more sense | 00:49 |
| infinity | robert_ancell: Not enough of a nit for me to reject, but feel free to retroactively fix it in your VCS so it's not a lie on the next upload. :P | 00:50 |
| cyphermox | stgraber: xnox: I'm around now | 00:50 |
| robert_ancell | infinity, there are many wrong changelog entries :) | 00:50 |
| infinity | robert_ancell: I don't doubt it. :) | 00:50 |
| blkperl | cjwatson: so since you fixed bug 1300072 my trusty install works but now im running into bug 1274320 | 00:51 |
| ubottu | bug 1300072 in parted (Ubuntu Trusty) "LVM installation fails - regression with parted 2.3-17" [Critical,Fix released] https://launchpad.net/bugs/1300072 | 00:51 |
| xnox | cyphermox: well, you could help me understand what's going on in silo11 and why it failed to build =) | 00:51 |
| ubottu | bug 1274320 in grub2 (Ubuntu) "Error: diskfilter writes are not supported" [Medium,Confirmed] https://launchpad.net/bugs/1274320 | 00:51 |
| cyphermox | sure | 00:51 |
| infinity | robert_ancell: Also, wtf? -lstdc++? Is that not building with g++? | 00:51 |
| robert_ancell | infinity, I have no idea, but the library build explicitly does that | 00:51 |
| robert_ancell | so making the introspection match fixes the problem | 00:51 |
| xnox | cyphermox: it said it build everything, and then decided not to upload them.... or something?! | 00:52 |
| infinity | robert_ancell: Ahh, yeah, it's using cc | 00:52 |
| infinity | robert_ancell: Building C++ code with cc is usually a sign that one's doing something wrong. | 00:52 |
| xnox | cyphermox: i'd love to fix that up, if i new what needs changing. | 00:52 |
| cyphermox | oh, nice. | 00:53 |
| robert_ancell | infinity, feel free to berate them on https://bugzilla.gnome.org/show_bug.cgi?id=727521 :) | 00:53 |
| ubottu | Gnome bug 727521 in build "Fails to build on ppc64el" [Normal,Unconfirmed] | 00:53 |
| infinity | robert_ancell: Although... This could have more to do with the libtool macros being broken in that build. | 00:54 |
| infinity | robert_ancell: Did you test with just dh_autoreconf before adding the link hack? | 00:54 |
| infinity | checking whether the g++ linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes | 00:54 |
| infinity | Err, wrong paste. | 00:54 |
| infinity | checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no | 00:54 |
| infinity | ^-- Indicative of libtool macros needing love. | 00:54 |
| robert_ancell | infinity, no, I only added it because I couldn't patch the Makefile directly without automake getting confused | 00:55 |
| infinity | robert_ancell: So, the above needs to be addressed. And if dh_autoreconf fixes the above, the lstdc++ thing probably isn't needed. | 00:55 |
| robert_ancell | infinity, I can check, but I think it will need the -l stdc++ | 00:56 |
| infinity | robert_ancell: It really shouldn't if other arches don't. | 00:56 |
| robert_ancell | infinity, g-ir-scanner is great at getting linking wrong | 00:57 |
| cjwatson | blkperl: expected, grub can't write to raid, not new | 00:57 |
| robert_ancell | infinity, huh, you're right | 00:57 |
| cjwatson | (or lvm) | 00:58 |
| infinity | robert_ancell: Figured. I'll reject your current upload, then. :) | 00:58 |
| robert_ancell | infinity, cheers :) | 00:58 |
| cjwatson | blkperl: and save_env involves writing to /boot/grub/grubenv | 00:58 |
| cjwatson | blkperl: the best we could do is maybe silence the error - but like I say it isn't a new thing | 00:59 |
| infinity | robert_ancell: You might want to followup to that upstream bug noting that all they need is a newer/saner libtool. | 00:59 |
| infinity | robert_ancell: So people don't go hunting in circles some other weird cause. :) | 00:59 |
| robert_ancell | infinity, should I re-use -0ubuntu2 or do I make a -0ubuntu3? | 01:00 |
| infinity | robert_ancell: 2 is fine, the rejected one doesn't get used up. | 01:00 |
| cyphermox | xnox: tbh, I think there might be no way for me to tell you currently | 01:01 |
| cyphermox | xnox: let's try to run it again :/ | 01:02 |
| xnox | cyphermox: maybe add the two source packages to "Sources:" line? | 01:05 |
| chiluk | Hey cjwatson , I'm casually looking into https://savannah.gnu.org/bugs/?42026 , and Vladimir thinks that our grub-efi version is differnt from our grub-pc version. Any clue where to start looking? The grub-pc version works fine, but the grub-efi fails to discover the amt sol serial port.. | 01:05 |
| xnox | cyphermox: no idea if that will help the train driver or not =) | 01:05 |
| cyphermox | two new source packages? | 01:07 |
| cjwatson | chiluk: well that's not possible, they're built from the same source. | 01:07 |
| chiluk | that's what I was thinking. | 01:07 |
| xnox | cyphermox: they are existing, in the archive, and i think they were previously released via train already. | 01:07 |
| cjwatson | and that patch was long ago. | 01:07 |
| chiluk | yeah.. | 01:08 |
| cyphermox | xnox: well if the issue was with versions you should get an error earlier | 01:08 |
| xnox | cyphermox: right.... hm =) i'm clueless, all I know is how to operate dput =) | 01:08 |
| cyphermox | unless it's trying to make the exact same version but with a different source tarball, though that shouldn't happen given that we datestamp the version anyway | 01:08 |
| cyphermox | xnox: let me re-run this step by step | 01:09 |
| chiluk | cjwatson was afraid we were missing a define for the efi build maybe | 01:09 |
| cyphermox | if it really doesn't work I'll frankenstein the ci... dah | 01:09 |
| cyphermox | no longer have access to the jenkins box | 01:09 |
| cjwatson | chiluk: no | 01:09 |
| cyphermox | xnox: let's just try to rerun, see how it goes, and if it still fails we'll need ev or olli or jfunk to help for now | 01:10 |
| cjwatson | chiluk: grub_serial_ns8250_add_port could fail for reasons other than the parsing, which would produce the same error | 01:10 |
| chiluk | fyi, this isn't official business | 01:10 |
| cjwatson | chiluk: I think Vladimir has misdiagnosed this | 01:10 |
| chiluk | k thanks | 01:10 |
| cjwatson | chiluk: also grub_serial_ns8250_add_port doesn't seem likely to work on class 3 (or whatever the terminology is) EFI devices | 01:10 |
| cjwatson | chiluk: you'd need something involving the efiserial driver | 01:11 |
| chiluk | any suggestions on how to go about debugging grub? | 01:11 |
| cjwatson | chiluk: which seems to generate efiXXX style port names | 01:11 |
| chiluk | I'm not familiar with that style | 01:12 |
| chiluk | are you suggesting trying serial --port=efif0e0? | 01:12 |
| chiluk | cjwatson or something similar | 01:12 |
| cjwatson | I think they're sequential rather than a big hex number | 01:12 |
| cjwatson | efi0, efi1, etc. | 01:13 |
| chiluk | cool give me a sec to check. | 01:13 |
| cjwatson | don't offhand see how to get a list of registered ports | 01:13 |
| chiluk | I'm out of my element here... | 01:14 |
| cjwatson | oh, the output of "terminal_input" without args should include them with "serial_" prefixed | 01:14 |
| infinity | robert_ancell: That did the trick, cheers. | 01:15 |
| robert_ancell | infinity, thank you. I learned some more obscure build system knowledge today :) | 01:15 |
| chiluk | cjwatson terminal_input yields "serial_* serial at_keyboard" | 01:17 |
| cjwatson | chiluk: it is also possible, I suppose, that you have a zombie GRUB image lying around from ages back, so double-check the version on the GRUB menu and not just the binary package | 01:18 |
| cjwatson | chiluk: maybe your EFI just doesn't probe the serial ports | 01:18 |
| chiluk | which is possible | 01:18 |
| chiluk | I have a bug open with intel as well. | 01:18 |
| cyphermox | xnox: got it now: https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/+packages | 01:18 |
| cjwatson | and if it's a bleeding-edge-enough EFI then it may not allow access to the traditional inb/outb style of port-banging | 01:19 |
| chiluk | cjwatson, it's showing up as 2.02~beta2-8 | 01:19 |
| cjwatson | right, good | 01:19 |
| xnox | cyphermox: \o/ | 01:19 |
| cjwatson | chiluk: I don't see any debug messages currently being logged by the relevant code, so you'll probably have to add grub_dprintf ("serial", ...) to various places and then "set debug=serial" | 01:20 |
| infinity | It's a NUC, so about as bleeding edge as it can be without being an engineering sample. | 01:20 |
| xnox | cyphermox: will test from silo as soon as they are ready, and will ping you about publishing them. | 01:20 |
| cjwatson | chiluk: grub-core/term/serial.c grub-core/term/efi/serial.c would be the places to start | 01:20 |
| infinity | (I'm not convinced that NUCs aren't pretty much engineering samples, from all the bugs I've heard people complain about) | 01:20 |
| cjwatson | probably the latter | 01:20 |
| chiluk | ah... efi/serial.c missed that one | 01:20 |
| chiluk | infinity, I have mine working pretty darn well./ | 01:20 |
| cjwatson | you'll probably want to add traces to the loop in grub_efiserial_init | 01:20 |
| chiluk | except for this efi issue everything else seems pretty decent. | 01:21 |
| chiluk | cjwatson, stupid question... what's best way to print out info without printf? | 01:21 |
| infinity | chiluk: Everyone seems to have their pet complaint. This is yours. :) | 01:21 |
| chiluk | infinity, I even have kvm working reliably-ish. | 01:21 |
| cjwatson | chiluk: err, I don't quite get the question, grub_dprintf is generally the best way to debug grub | 01:21 |
| chiluk | that's the answer I was looking for. | 01:22 |
| cjwatson | there's a grub_printf to print things unconditionally | 01:22 |
| cjwatson | but you indeed don't have the standard C library | 01:22 |
| chiluk | right.. | 01:22 |
| chiluk | I haven't screwed with things this early in boot before. | 01:22 |
| cjwatson | see e.g. grub-core/disk/efi/efidisk.c for an example of using grub_dprintf | 01:23 |
| cjwatson | though it's scattered pretty liberally over the codebase | 01:23 |
| cjwatson | the first arg to grub_dprintf is something that you might put in "set debug=" | 01:24 |
| chiluk | cjwatson, cool thanks again... I'll push this a bit.. considering how many of us are investing in nucs, it'd be nice to have these things work reliably... that and it might be nice to test serial on an efi machine just in case this is a larger problem. | 01:26 |
| cjwatson | sure, it's possible. I think it's been confirmed to work at least sometimes :) | 01:27 |
| chiluk | for such old-school tech it should work all the time. | 01:27 |
| cjwatson | chiluk: serial may be old-school tech, but EFI serial sure isn't. | 01:30 |
| cjwatson | The driver only went into 2.02, IIRC | 01:31 |
| === salem_ is now known as _salem | ||
| cjwatson | Oh, no, git says it was in 2.00, just a couple of patches since then | 01:31 |
| cjwatson | But even so | 01:32 |
| blkperl | cjwatson: alright thanks, good to know its nothing serious :) | 01:34 |
| darkxst | something is pulling in the entire Unity world on Ubuntu GNOME :( | 01:51 |
| xnox | cyphermox: i have finished testing all packages from silo 11, please upload them into -proposed. | 02:06 |
| xnox | cyphermox: all is good. | 02:06 |
| cyphermox | xnox: done | 02:10 |
| chiluk | hey infinity can I get some upload lovin on https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 I notice there are no patch pilots online right now. | 02:30 |
| ubottu | Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] | 02:30 |
| chiluk | xnox are you still around and will to upload https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 | 02:39 |
| ubottu | Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] | 02:39 |
| === thegatta_ is now known as thegattaca | ||
| cyphermox | FourDollars: hey, re: your bluetooth patch | 03:13 |
| === maclin_ is now known as maclin | ||
| FourDollars | cyphermox: yes | 03:14 |
| cyphermox | I'm not convinced it would really fix the crash... | 03:14 |
| FourDollars | cyphermox: Err... XD | 03:14 |
| cyphermox | I agree with the extra check, but it's freeing the caps list in the device that crashes bluez | 03:14 |
| FourDollars | cyphermox: Because it is freed before. | 03:15 |
| cyphermox | so that extra check would only guard you from trying the free the device if the device pointer is invalid, not from invalidly freeing the capabilities list if the device pointer is valid but the caps list may not be (as seemed to be the case in your crash) | 03:15 |
| cyphermox | so while I'm happy with the patch as it is, I can't confirm it's valid as I have no way to really reproduce this state | 03:16 |
| cyphermox | if you tell me you could reproduce the crasher reliably on your hardware and it fixed it, then all good :) | 03:17 |
| FourDollars | cyphermox: Before it runs to the crash place, it will run unix_device_removed(). | 03:17 |
| cyphermox | oh wait a second | 03:18 |
| cyphermox | FourDollars: can you easily reproduce this crash? I can't here. I'd really like to see the backtrace for all threads | 03:32 |
| FourDollars | cyphermox: Yes, I can easily reproduce this issue. | 03:33 |
| FourDollars | cyphermox: I need some time to setup the environment because I am working on many different machines for this issue. | 03:34 |
| cyphermox | oh ok | 03:34 |
| cyphermox | ah, I see what's happening now | 03:36 |
| FourDollars | Do you stiil need the backtrace for all threads? | 03:37 |
| FourDollars | cyphermox: ? | 03:38 |
| cyphermox | no, I don't | 03:39 |
| FourDollars | OK | 03:40 |
| cyphermox | I see what you're doing now, fully agree with the patch, I'll upload now for trusty, and then for precise | 03:40 |
| FourDollars | Thanks a lot. :D | 03:40 |
| dannf | stgraber: fyi, now that udev links w/ libcgmanager0, d-i ftbfs due to a lack of a libcgmanager-udeb | 03:55 |
| dannf | hallyn: ^ | 03:55 |
| dannf | and libnih0 apparently | 03:57 |
| infinity | stgraber: Also, upstart needs udebs now because of that (nih and nih-dbus) | 03:57 |
| infinity | Which might be a slipper slope... | 03:57 |
| stgraber | well, our systemd source now build-depends against libcgmanager-dev because we need logind to talk to cgmanager in some cases. I can't think of a good reason for udev itself to do so though, maybe I can get some sanity into upstream's crazy Makefile to avoid that particular one | 03:57 |
| infinity | Disabling cgmanager support in the udev udeb pass might be smarter. | 03:57 |
| stgraber | well, udev never does anything with cgroups, so there's no good reason for it to be linked to cgmanager to begin with | 03:58 |
| infinity | stgraber: With --as-needed, I wouldn't expect it to be. | 03:58 |
| infinity | ./lib/systemd/systemd-udevd | 04:00 |
| infinity | libcgmanager.so.0 => not found | 04:00 |
| infinity | It's definitely udevd itself that's linked to it. | 04:00 |
| infinity | stgraber: I'll just add --disable-whatever to the udeb pass and test that. | 04:01 |
| stgraber | infinity: right, --disable-cgmanager should do the trick | 04:01 |
| stgraber | I'm still pretty confused as to why udev would even use any of that code to begin with, I was under the (apparently wrong) impression that udev was supposed to be kept mostly separate after its merge into systemd... | 04:02 |
| infinity | stgraber: It probably statically links libsystemd, because Lennart and Kai. | 04:02 |
| infinity | stgraber: And your cgmanager stuff is built into libsystemd, so... | 04:03 |
| infinity | Testbuilding now. | 04:03 |
| chiluk | hey infinity want to do an upload for https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 as well? | 04:10 |
| ubottu | Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] | 04:10 |
| infinity | stgraber: http://paste.ubuntu.com/7197140/ Looks like success. | 04:13 |
| infinity | stgraber: And in the queue, if you'd like to do the honours. | 04:14 |
| stgraber | infinity: looks good, will review in the queue. Thanks for fixing that one! | 04:14 |
| chiluk | hey stgraber I see you listed as a patch pilot would you help me with an upload for bug 1301692 ? | 04:14 |
| ubottu | bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] https://launchpad.net/bugs/1301692 | 04:14 |
| stgraber | chiluk: it's past midnight here and I'm headed to bed after I'm done reviewing that systemd upload, I'll be happy to take a look tomorrow if you remind me though :) | 04:16 |
| chiluk | sure thing.. I'll harass tomorrow's patch pilot | 04:17 |
| === jackson is now known as Guest50945 | ||
| === maclin__ is now known as maclin | ||
| dholbach | good morning | 06:47 |
| darkxst | hey dholbach | 06:48 |
| dholbach | hi darkxst | 06:49 |
| darkxst | re bug 1294891, was quite clear on exactly what is need with license texts, I put full text for CC-BY-SA 2 and 3 in both COPYING and debian/copyright | 06:50 |
| ubottu | bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Incomplete] https://launchpad.net/bugs/1294891 | 06:50 |
| darkxst | s/was/wasnt/ | 06:50 |
| darkxst | is that what you meant? | 06:50 |
| caribou | Are SRU for packages in Universe handled differently than for those in main ? | 09:04 |
| Laney | Nope | 09:04 |
| caribou | Laney: ok,thanks | 09:05 |
| mpt | mvo_!!! | 09:22 |
| mvo_ | hey mpt | 09:22 |
| * janimo hugs mvo | 09:25 | |
| * mvo_ hugs janimo | 09:29 | |
| seb128 | bdmurray, mvo_: would have of you have some spare cycles to look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1294124 ? | 09:47 |
| ubottu | Launchpad bug 1294124 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with AssertionError in confirmChanges()" [Medium,Confirmed] | 09:47 |
| seb128 | it's ranked 3rd on the daily e.u.c trusty report with 30 reports in a day | 09:47 |
| === vrruiz_ is now known as rvr | ||
| jibel | seb128, the crash signature is not really accurate for this bug because from the duplicates the root cause of the failure is "MarkUpgrade() called on a non-upgrable pkg: 'brasero'" | 09:53 |
| seb128 | jibel, what bug? | 09:53 |
| jibel | seb128, 1294124 | 09:53 |
| seb128 | jibel, you mean it doesn't match https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721 ? | 09:54 |
| seb128 | jibel, I'm not sure what you are getting at? it's not a bug? it's mistriaged? | 09:54 |
| jibel | seb128, I mean this signature matches any upgrade that fails because a package is non-upgradable | 09:55 |
| jibel | in that case 'brasero' | 09:55 |
| seb128 | where do you see that? | 09:55 |
| seb128 | jibel, I'm looking at https://launchpadlibrarian.net/169922204/Traceback.txt ... are we looking at the same thing? | 09:55 |
| jibel | seb128, from apt.log | 09:55 |
| seb128 | I mean the signature | 09:56 |
| seb128 | where do you see it | 09:56 |
| jibel | https://launchpadlibrarian.net/169922201/DuplicateSignature.txt | 09:57 |
| seb128 | I don't see anything on https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721 | 09:57 |
| seb128 | jibel, that has the python bt? | 09:57 |
| seb128 | jibel, anyway, I'm unsure what you are getting at, even if some packages are not-upgradable that should hit an assert and is a bug still no? | 09:57 |
| seb128 | shouldn't* | 10:00 |
| jibel | seb128, right, this is a bug. My point is that the problem on errors.u.c aggregates all the failures caused by non-upgradable packages. | 10:03 |
| seb128 | jibel, let's fix the assert and make it report the actual errors then :p | 10:03 |
| seb128 | jibel, do you know why those packages (e.g brasero) are non-upgradable? | 10:04 |
| jibel | seb128, not yet, I'll try to reproduce it. | 10:09 |
| seb128 | jibel, thanks | 10:09 |
| * seb128 shakes fist at ted | 10:10 | |
| seb128 | my desktop greets me at each login with an apport prompt about click :/ | 10:11 |
| pitti | seb128: is that still from those few days where a new indicator version pulled in all of click? | 10:11 |
| seb128 | pitti, no, I'm having click installed because we use it in the touch settings and I'm testing those on my desktop | 10:12 |
| seb128 | things like click list work there | 10:12 |
| seb128 | even if the clicks can't be run from unity7 | 10:12 |
| === zyga_ is now known as zyga | ||
| Laney | https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1290997 | 10:16 |
| ubottu | Launchpad bug 1290997 in url-dispatcher (Ubuntu) "click crashed with gi._glib.GError in run(): Child process exited with code 139" [High,Triaged] | 10:16 |
| seb128 | right | 10:17 |
| seb128 | which is why I shake my first at ted :p | 10:17 |
| seb128 | (it also tops e.u.c since yesterday) | 10:18 |
| pitti | slangasek: as we have logind now taking care of the power button even if nobody is logged in, I think it's time to rip this functionality out of acpid; it leads to bugs like bug 1201180 | 10:18 |
| ubottu | bug 1201180 in kde-workspace (Ubuntu) "Pressing power button turns off the PC ignoring the presence of another session manager" [Medium,Triaged] https://launchpad.net/bugs/1201180 | 10:18 |
| pitti | slangasek: do you agree, or am I missing something here? | 10:18 |
| === MacSlow is now known as MacSlow|lunch | ||
| xnox | pitti: yes, please! | 10:38 |
| xnox | pitti: is logind also present on the servers and taking care of login buttons there? | 10:39 |
| xnox | pitti: atleast acpid shouldn't do anything if there is logind present. | 10:39 |
| pitti | xnox: yes, that seems like the easiest solution then (pidof systemd-logind) | 10:41 |
| pitti | xnox: I'm not sure whether it's running on all servers, but it might not be | 10:41 |
| xnox | pitti: it can and does create sessions for serial/ssh users etc. but i'm not sure how far down libpam-systemd & logind are seeded. | 10:42 |
| pitti | I made a comment on the bug, I'll look into that | 10:47 |
| * Laney finds some systemd-cgmanagery bugs | 10:48 | |
| xnox | sergiusens: hey! Could you please remove ubuntuone click webapp from http://people.canonical.com/~ubuntu-archive/click_packages/click_list ? we no longer want it pre-installed, as u1 file services will be shutdown. | 10:59 |
| sergiusens | xnox: sure; it's a mostly useless web app anyways :-P | 11:00 |
| sergiusens | xnox: is it already unpublished by dbarth? | 11:01 |
| ogra_ | yeah, it never had any mobile CSS either | 11:01 |
| xnox | sergiusens: yes, he unpublished it in the store. | 11:01 |
| dbarth | sergiusens: yup unpublished; see if you need to let your script now | 11:02 |
| dbarth | know | 11:02 |
| sergiusens | xnox: dbarth done | 11:02 |
| dbarth | cool thanks | 11:03 |
| sergiusens | next sync should do the right thing at 11 after the clock | 11:03 |
| pitti | xnox: FTR, logind isn't on our server images (meh.. we keep dragging along acpid/acpi-support) | 11:09 |
| pitti | xnox: so instead of completely ripping it out, let's go for "check for logind" for trusty, yes | 11:09 |
| pitti | acpi-support will survive us all.. | 11:09 |
| xnox | pitti: it will do for another 5 years =) | 11:10 |
| ypwong | seb128, hi! | 11:10 |
| ypwong | seb128, could you or someone in your team take a look at bug 1299855? We need the feature to set the default search engine in ubuntu kylin | 11:12 |
| ubottu | bug 1299855 in ubuntu-defaults-builder (Ubuntu) "setting browser.search.defaultenginename in distribution.ini does not have effect" [High,Confirmed] https://launchpad.net/bugs/1299855 | 11:12 |
| === ara is now known as Guest11257 | ||
| seb128 | ypwong, hey, sure, adding to our list | 11:20 |
| seb128 | happyaron, ^ would you have a free slots to look at that one? | 11:21 |
| === mino_ is now known as mino | ||
| === slacker_1l is now known as slacker_nl | ||
| infinity | pitti: If I'm using run-adt-test, what's the best way to upgrade my base image so it's not updated over and over on every run? | 12:41 |
| pitti | infinity: just re-run "prepare-testbed amd64" is the easiest | 12:41 |
| infinity | pitti: Won't that download a fresh cloud image all over? | 12:41 |
| pitti | infinity: with the prepare-testbed VMs it's not trivial to dist-upgrade them; you can do it, though | 12:42 |
| pitti | infinity: yes, it will; but they aren't particularly big | 12:42 |
| infinity | Bigger than a dist-upgrade.:) | 12:42 |
| infinity | But will keep that in mind the next time it annoys me. | 12:42 |
| pitti | infinity: so run the image with -hda pristine-trusty-amd64-20140324_084956.img and -hdb pristine-trusty-amd64-20140324_084956.img.seed | 12:43 |
| pitti | with whichever images you have | 12:43 |
| pitti | and then log in as ubuntu/ubuntu and dist-upgrade | 12:43 |
| infinity | pitti: Also, when can get right of the twisty maze of jenkins-is-the-worst-video-game-ever and have results I can actually navigate, like Debian now does? ;) | 12:44 |
| infinity | pitti: Aaaand a feature request, being able to stuff mirror and apt_proxy info into the image via arguments to prepare-testbed would make me happy. | 12:48 |
| pitti | infinity: it's in the pipeline :) https://wiki.debian.org/MartinPitt/DistributedDebCI | 12:51 |
| pitti | infinity: that already exists in autopkgtest | 12:51 |
| infinity | pitti: Which already exists? Mirror/proxy selection? | 12:51 |
| pitti | infinity: I don't want to waste too much effort on lp:auto-package-testing and jenkins any more, given that I really want both of them to go away next cycle | 12:51 |
| pitti | adt-buildvm-ubuntu-cloud --help | 12:52 |
| infinity | pitti: Oh, should I be using something other than lp:auto-package-testing? I was just following a random wiki. | 12:52 |
| pitti | -m URL, --mirror URL Use this mirror for apt (default: | 12:52 |
| pitti | http://archive.ubuntu.com/ubuntu) | 12:52 |
| pitti | -p URL, --proxy URL Use a proxy for apt | 12:52 |
| pitti | and adt-build-lxc just automagically uses whichever apt proxy you have on the host | 12:52 |
| pitti | that doesn't have a --mirror yet, please file a bug if you need that | 12:52 |
| pitti | infinity: you can use the new stuff; lp:a-p-t is still what we are running in production | 12:53 |
| pitti | infinity: but locally I don't use it any more, I just run adt-run directly with schroot, LXC, or QEMU (depending on what's appropriate) | 12:53 |
| pitti | infinity: I spent some time to write /usr/share/doc/autopkgtest/README.running-tests.gz, I hope that's a good enough intro how to run schroot/lxc/qemu and how to build testbeds | 12:54 |
| infinity | pitti: Are there docs for idiots on how to do it that way? I've just been following the two simple steps on http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test for prepare/run-adt | 12:55 |
| pitti | infinity: if you have a test which doesn't open network ports or fiddles with the kernel, then using an existing schroot is certainly by far the easiest method | 12:55 |
| infinity | pitti: Ahh, cool. Alright, I'll look at that at some point. | 12:55 |
| infinity | pitti: And yeah, schroots would be fine for most things (and how Debian seems to be running their tests?), but I'd prefer to match production when I can. Ish. | 12:55 |
| pitti | infinity: read that doc and please tell me if anything is unclear; I'm really eager that this is a good intro document, as ohterwise I'll keep explaining this on IRC forever :) | 12:56 |
| === _salem is now known as salem_ | ||
| infinity | pitti: Pointing out the doc on the above page might be helpful. ;) | 12:56 |
| pitti | infinity: don't worry; if it works in a minimal schroot it's very likely also going to work in the fat cloud images | 12:57 |
| pitti | infinity: yes, I'm going to do that once we actually switch over production | 12:57 |
| pitti | infinity: I think for now the official answer is still "prepare-testbed every day" and "run-adt-test" | 12:57 |
| pitti | it's just about as expensive as it can get, but it's easy | 12:57 |
| === StevenK_ is now known as StevenK | ||
| === wgrant_ is now known as wgrant | ||
| === ara_ is now known as ara | ||
| bdmurray | pitti: have you had a change to look at my apport-retrace package versions branch? | 14:16 |
| === brendand is now known as brendand-afk | ||
| stgraber | hallyn: any idea what could be causing bug 1301882? from the backtrace it looks like we're stuck in ping... | 14:17 |
| ubottu | bug 1301882 in systemd (Ubuntu) "systemd-logind can get hung in cg_enumerate_tasks" [Undecided,New] https://launchpad.net/bugs/1301882 | 14:18 |
| bdmurray | mvo_: Hi, would you mind having a look at bug 1300465? Its not too important but curious. | 14:18 |
| ubottu | bug 1300465 in python-apt (Ubuntu) "description dialog is empty" [High,Triaged] https://launchpad.net/bugs/1300465 | 14:18 |
| mvo_ | sure | 14:19 |
| mvo_ | bdmurray: I "stole" #1286161 from you, hope you don't mind | 14:19 |
| bdmurray | mvo_: heh, not at all! | 14:19 |
| infinity | jcastro: He's mine, back off. | 14:20 |
| infinity | Erm, ECHAN. | 14:20 |
| stgraber | hallyn: one idea would be to switch to using a single connection to cgmanager and keep it open to avoid all those connect/ping/disconnect but I'm not sure this would have fixed that particular hang. (The reason for all the connect/disconnect is that logind spends most of its time idle and I wanted to be as robust as possible in case something goes wrong with cgmanager and the reconnect code doesn't work) | 14:21 |
| mvo_ | what the process to request a FFe for apt 1.0 for trusty? http://people.canonical.com/~mvo/apt_0.9.15.4ubuntu2_to_1.0ubuntu1.debdiff <- its a bit long, mostly cppchecker fixes | 14:21 |
| stgraber | hallyn: an alternative would be to have connect fail after a short timeout if ping doesn't respond, not sure how easy that'd be. | 14:21 |
| bdmurray | mvo_: what might go wrong with the fix for bug 1286161? | 14:21 |
| ubottu | bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161 | 14:21 |
| pitti | bdmurray: sorry, not this week; the sprint takes pretty much all brain and time, I'm afraid | 14:24 |
| infinity | mvo_: File a but against the apt package titled "[FFe] update apt to shiny version with more cows" , describe the how and why in the bug, and subscribe ubuntu-release. | 14:25 |
| infinity | mvo_: And then convince me directly that it's low impact, and why. ;) | 14:25 |
| hallyn | stgraber: I'll take a look | 14:26 |
| bdmurray | pitti: ah, didn't know you were sprinting | 14:28 |
| mvo_ | bdmurray: on the phone right now, will reply in a bit | 14:30 |
| hallyn | stgraber: do you know if cgmanager had crashed/restarted? | 14:32 |
| stgraber | hallyn: don't know | 14:33 |
| stgraber | Laney: can you post your /var/log/upstart/cgmanager.log in the bug? | 14:33 |
| hallyn | ok lemme set up a victim vm to torment | 14:33 |
| Laney | stgraber: oh yes, sorry, which one? | 14:33 |
| Laney | or either I guess | 14:33 |
| Laney | btw I got it back into the borked state accidentally if you want some data out of it :-) | 14:34 |
| hallyn | stgraber: i can't imagine why it would've happened otherwise. especialy on ping | 14:34 |
| hallyn | Laney: you had no containers running right? | 14:34 |
| Laney | hallyn: I almost certainly did, I usually do | 14:35 |
| === pedronis__ is now known as pedronis | ||
| Laney | and certainly do now | 14:35 |
| hallyn | Laney: oh but that shoudl be fine, i should've asked, the ping hang didn't happen in a container? | 14:36 |
| Laney | Everything I was doing with loginctl was outside | 14:36 |
| Laney | hallyn: log is attached | 14:37 |
| hallyn | thanks. | 14:38 |
| mvo_ | bdmurray: so what might go wrong - well, the ording might break in a different way. there is no indicataion that this is the case and it definitely fixes the bug in the bugreport | 14:47 |
| mvo_ | thanks infinity, I will do this | 14:48 |
| bdmurray | mvo_: okay, jibel you could do some automated testing with that new version of apt right? | 14:48 |
| hallyn | stgraber: logind doesn't do any threading right? | 14:49 |
| mvo_ | bdmurray: yeah, that would be great. I can do some testing on my workstation too. I think its pretty safe (the diff) but we all know that shortly before a release stuff may break :) | 14:51 |
| jibel | bdmurray, sure, if you provide a deb, I can run the tests with this version. | 14:53 |
| bdmurray | mvo_: why don't you upload it to the saucy-proposed queue and I'll approve it later today | 14:53 |
| mvo_ | bdmurray: sounds good | 14:54 |
| bdmurray | pitti: the powerd debug symbols seem to be out of date | 15:01 |
| slangasek | pitti: ah yes, if logind is now handling the power button outside of login sessions (hurray), we should indeed drop it from acpid (double-hurray!) | 15:01 |
| pitti | slangasek: right, thanks; as xnox pointed out, it's not currently on server images, so for now I just added the "pidof systemd-logind" check | 15:02 |
| pitti | slangasek: this acpid{d,support} stuff is annoyingly sticky :( | 15:02 |
| slangasek | pitti: ah, doh | 15:02 |
| pitti | bdmurray: checking where it was built and trying to rescue | 15:03 |
| bdmurray | pitti: thanks | 15:04 |
| pitti | bdmurray: hm, the ddebs are nowhere on kishi06/toyol/lamiak, so there's nothing to rescue I'm afraid | 15:06 |
| psusi | cjwatson: I noticed that it looks like you fixed bug #1065281 some time ago, but it still has one open task against ubiquity ( not release specific ). Has it really not been fixed in trusty, or does it not affect anything above precise and so the task should be removed? | 15:06 |
| ubottu | bug 1065281 in partman-efi (Ubuntu Quantal) "Installer crashed when trying to partition 4k/4k sector hard disks" [High,Triaged] https://launchpad.net/bugs/1065281 | 15:06 |
| pitti | bdmurray: "powerd has no unstripped objects, ignoring" | 15:07 |
| pitti | bdmurray: so I think powerd is built without -g | 15:07 |
| cjwatson | psusi: ah, see, this is why I hate having ubiquity tasks on bugs that just amount to incorporating new included sources | 15:07 |
| psusi | yep | 15:08 |
| cjwatson | psusi: closing, thanks | 15:08 |
| pitti | bdmurray: so the build log doesn't have any -On option or -g | 15:08 |
| pitti | bdmurray: that's a "cmake does not respect $CFLAGS" kind of bug, I'm afraid | 15:09 |
| psusi | btw, I've been closing a lot of bugs lately that are installer crashes due to booting the installer in efi mode, and trying to install on a disk already set up for bios mode.. I think we really, really need to fix partman-xxx to stop and tell the user they need to reboot in bios mode instead of getting to grub-install failing | 15:09 |
| psusi | sound like a good idea, and if so, what is the partman-xxx to file the bug against? partman-efi, or partman-auto? | 15:09 |
| stgraber | hallyn: it's not extremely clear due to the way all of systemd's code is mixed together... I don't believe logind itself uses threads but I may be wrong... | 15:10 |
| psusi | or better yet, switch to using grub-pc instead of grub-efi | 15:10 |
| cjwatson | psusi: maybe partman-efi. not sure we *can* switch to grub-pc at that point, it may not necessarily be able to install | 15:11 |
| cjwatson | psusi: certainly not partman-auto | 15:12 |
| === brendand-afk is now known as brendand | ||
| ogra_ | stgraber, we are seeing weird issues with the boot on phones (not sure you read the ubuntu-phone ML lately), the system locks up hard after run-init since nothing changed in mountall and cgmanager is the first additional thing to start there, do you know of any issues cgmanager could cause ? | 15:12 |
| psusi | cjwatson: why wouldn't it be able to install? | 15:13 |
| ogra_ | stgraber, (it only happens ever 20th to 60th boot, which kills the devices in the lab) | 15:13 |
| ogra_ | (i noticed plenty of mesaages where gcmanager repawns a few times during a normal boot) | 15:13 |
| stgraber | ogra_: and I don't suppose adb is up by the time it hangs? | 15:14 |
| psusi | isn't partman-auto where you pick then guided - install along side option? I would think that's where you would want to look at the current disk layout and decide if you should force grub-pc instead of grub-efi | 15:14 |
| stgraber | ogra_: when cgmanager respawns, do you get a crash entry in /var/crash by any chance? | 15:14 |
| ogra_ | stgraber, nope, no adb across run-init ... we have an emergency shell that kicks off wqhen the container cant start and one on panic in the initrd | 15:14 |
| hallyn | stgraber: that's bad if it does. then we need to fix that nih/dbus threading issue | 15:14 |
| Laney | hallyn: It doesn't AFAICS | 15:15 |
| hallyn | ah good, my victim is done installing. now to torture it | 15:15 |
| hallyn | ok | 15:15 |
| ogra_ | stgraber, i'll check, i'm not near the phone atm | 15:15 |
| dholbach | xnox, Paolo just pinged me about https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1300400 again - he said they want to get out an Italian CD for 14.04 but would need this fixed - if you don't have time, do you know anyone else who could take a look at this? | 15:15 |
| ubottu | Launchpad bug 1300400 in live-build (Ubuntu) "Please add saucy and trusty strings to releases.sh" [Undecided,Confirmed] | 15:15 |
| stgraber | ogra_: it still wouldn't explain why the phone doesn't boot though. Even if cgmanager fails to start or crashes, the worst case scenario should be that the container won't start. | 15:16 |
| stgraber | ogra_: but the rest of the system doesn't depend on cgmanager and so everything else should start, including adb | 15:16 |
| xnox | dholbach: i'll sponsor that patch now. | 15:17 |
| xnox | dholbach: we can work on a generic solution later. | 15:18 |
| dholbach | xnox, awesome | 15:18 |
| cjwatson | psusi: I'd have to go pick over the UEFI spec with a fine tooth-comb to see if there's anything that e.g. a class 3 device might do that could break grub-pc installation. Dunno | 15:19 |
| cjwatson | psusi: platform-specific stuff like this, other than default partition layouts, doesn't belong in partman-auto | 15:19 |
| cjwatson | psusi: (also, you're asking a question and then arguing with the answer ...) | 15:19 |
| ogra_ | stgraber, unless the android kernel is not safe for something cgmanager tries to do to it | 15:20 |
| psusi | well, I mean, if the existing disk is MBR partitioned, then obviously the machine normally boots in bios mode, right? so screw efi | 15:20 |
| stgraber | ogra_: doubtful, all cgmanager does is write to plain text files | 15:21 |
| stgraber | ogra_: and is basically a copy/paste of what LXC used to do directly itself before | 15:21 |
| cjwatson | psusi: well, probably, yeah | 15:21 |
| ogra_ | stgraber, ok | 15:21 |
| xnox | cjwatson: psusi: it can do either, e.g. on Macs they keep MBR and UEFI in sync thus one can boot using either method. That's more or less how bootcamp works. | 15:21 |
| cjwatson | psusi: but you definitely want to do it later than partman-auto because it's completely legitimate for somebody to manually zap the existing partition table and replace it with GPT in order to convert to full-fat UEFI | 15:21 |
| psusi | xnox: right.. but the disk is gpt ( hybrid ) | 15:22 |
| cjwatson | xnox: that's an irrelevant side issue though, as parted will still see that as GPT | 15:22 |
| xnox | ok. | 15:22 |
| psusi | cjwatson: yes, but isn't partman-auto the place where they decide they are not going to do that, but do a side-by-side install? | 15:22 |
| psusi | on the existing pure MBR disk? | 15:22 |
| hallyn | stgraber: ok, so i have just installed ubuntu-desktop on trusty vm, but cgmanager and logind are not installed. ? | 15:23 |
| hallyn | shouldn't logind be automaticlaly there? | 15:23 |
| cjwatson | psusi: they can perfectly well switch to manual partitioning | 15:23 |
| cjwatson | psusi: in fact, to overwrite the existing partition table, I think they may *have* to switch to manual partitioning | 15:23 |
| cjwatson | psusi: like I say, partman-auto is just simply the wrong place for this | 15:23 |
| psusi | *after* they already chose side by side in partman-auto? | 15:23 |
| cjwatson | that has nothing to do with it | 15:24 |
| cjwatson | look | 15:24 |
| stgraber | hallyn: it should, is that vm up to date? | 15:24 |
| cjwatson | consider an existing mbr disk. user selects manual partitioning, may or may not replace the entire thing with GPT | 15:24 |
| psusi | maybe I'm misunderstanding the relationship between the menu and the partman modules... I thought that partman-auto implements the options for either guided or manual partitioning? | 15:24 |
| cjwatson | if it's GPT at the commit stage, then we don't complain, otherwise we do | 15:25 |
| cjwatson | simple | 15:25 |
| cjwatson | partman-auto does not step in at the commit stage | 15:25 |
| cjwatson | partman-efi (and others) do, via check.d scripts | 15:25 |
| hallyn | stgraber: yup. what should bring in logind? (logind is the pkg name right?) | 15:25 |
| cjwatson | no, partman-auto does not implement manual partitioning beyond just the single option letting you get into it | 15:25 |
| stgraber | hallyn: systemd-services is the package name | 15:25 |
| psusi | right, that's what I meant, that's where you make the choice | 15:25 |
| cjwatson | but that choice is not sufficient information to decide whether to issue this warning | 15:26 |
| cjwatson | the proper place to do it is in a check.d script which happens at commit time | 15:26 |
| cjwatson | and those do not belong in partman-auto | 15:26 |
| psusi | so if you choose the side-by-side option, then at that point, if the disk is mbr, I would think that would be where we want to set a flag to not bother loading partman-efi, and force grub-pc | 15:26 |
| cjwatson | I'm not going to argue this further | 15:26 |
| hallyn | stgraber: oh, hm, that's there | 15:26 |
| psusi | what warning? I'm trying to avoid any kind of warning | 15:27 |
| cjwatson | not bother loading partman-efi> you misunderstand the architecture | 15:27 |
| cjwatson | please stop it | 15:27 |
| stgraber | hallyn: it should only bring libcgmanager0 though, not the daemon itself | 15:27 |
| cjwatson | you asked a question, I gave you the answer ... | 15:27 |
| stgraber | hallyn: so a default desktop install won't have Laney's problem, the hangs are currently restricted to those who have lxc installed | 15:27 |
| hallyn | stgraber: oh ok. and it uses fs if cgmanager is not installed. got it | 15:27 |
| hallyn | ok just making sure what i had was sane, thanks :) | 15:27 |
| cjwatson | grub-installer should be the thing that decides which grub platform to install | 15:28 |
| cjwatson | if it's necessary to tell the user they can't proceed with their current layout, then that belongs in a check.d script in partman | 15:28 |
| cjwatson | if it's possible to avoid such a thing, then partman doesn't need to change at all | 15:29 |
| cjwatson | in neither case should partman-auto be touched | 15:29 |
| psusi | ok, but we want to change its decision based on the fact that we are doing a side-by-side install on an MBR disk... is that information availible to grub-installer? | 15:29 |
| cjwatson | no, there's no need to take that into consideration | 15:29 |
| cjwatson | all grub-installer needs to know is the partition label in place when it runs | 15:30 |
| cjwatson | which is well after partitioning | 15:30 |
| cjwatson | it's not relevant how it got that way | 15:30 |
| psusi | ahh... ok... got ya | 15:30 |
| cjwatson | and, you can just as well do a side-by-side install in manual partitioning as in partman-auto ... | 15:30 |
| cjwatson | it's obviously more effort, but it's entirely doable | 15:30 |
| cjwatson | partman-auto is basically just recipes and code for applying them, not anything specifically about the implementation of the various filesystems and labels and such | 15:31 |
| psusi | ok, I was thinking we only wanted to do this for the guided install option, but yea, I suppose it also makes sense in manual | 15:32 |
| cjwatson | I try very hard to keep this sort of thing out of partman-auto because the inevitable result is a bug ten seconds later complaining that the same thing doesn't work in manual partitioning :-) | 15:33 |
| cjwatson | It's a lot easier to be hard-nosed about the architecture from the start | 15:33 |
| psusi | what triggers partman-efi to be loaded? | 15:36 |
| psusi | so partman-efi's check should throw an error if you are using gpt but don't have an efi system partition ( or maybe bios_grub? ), but if you are using mbr, let it go and have grub-installer switch to grub-pc if using mbr? | 15:37 |
| psusi | or perhaps issue a warning that the resulting system may not boot.. hrm... | 15:41 |
| cjwatson | partman-efi is Priority: standard, so anna loads it by default if it's available. | 15:42 |
| psusi | probably want to suppress that warning though if they picked guided install beside | 15:43 |
| cjwatson | Yeah, partman-efi should probably only care about systems with GPT. | 15:43 |
| cjwatson | I don't think guided install or not should be relevant. Yes, it's a bug if guided install sets up something wrong, but we still want to know about it early rather than failing in a confused heap that's hell to debug later. | 15:43 |
| cjwatson | EFI System Partition / bios_grub> I feel that partman-efi should probably allow either, and grub-installer should use that to decide which platform to install | 15:44 |
| psusi | I think the warning makes perfectly good sense if they did a manual setup, but I'd rather not give the user a scary warning if they are doing a side by side install with an existing setup that obviously boots in bios mode just fine | 15:44 |
| cjwatson | Though partman-efi's job is really specifically about the EFI System Partition, so maybe this actually belongs somewhere like partman-partitioning | 15:44 |
| cjwatson | (which already handles stuff about bios_grub) | 15:45 |
| cjwatson | We need to make sure that the logic is such that the warning doesn't appear in such a side-by-side case, and that we install a boot loader which will cope | 15:45 |
| psusi | right. that's what I'm saying | 15:45 |
| mvo_ | bdmurray: so for #1300465 - you see pkg.candidate.raw_description, correct? | 15:46 |
| cjwatson | But detecting guided partitioning and suppressing the warning in that case is the wrong answer | 15:46 |
| cjwatson | This is a safety check - it's better not to proceed than to generate something unbootable due to a logic bug in partitioning | 15:46 |
| mvo_ | bdmurray: on what system did you reproduced this? anything I could try to reproduce this? | 15:46 |
| psusi | hrm... I suppose I was using the guided partitioning as a surrogate for detecting existing operating systems later | 15:46 |
| cjwatson | And it's furthermore better to at least give users the chance to fix it, rather than have the whole system just be uninstallable | 15:47 |
| cjwatson | (which a check.d warning will naturally do - they can fall back to manual partitioning) | 15:47 |
| psusi | right, but I'd like to avoid even a warning if ther's another OS on the disk that obviously is booting just fine in bios mdoe | 15:48 |
| cjwatson | Well, we seem to be largely in agreement that we only need to generate a warning if you have a GPT label without any boot-type partition | 15:49 |
| cjwatson | So that shouldn't be an issue | 15:49 |
| psusi | right | 15:49 |
| bdmurray | mvo_: yes, I see raw_description but description is empty | 15:49 |
| cjwatson | We do need to check the final state though - with BIOS+GPT you could break that existing OS by the changes that you make in the partitioner (not guided, presumably, but you could wipe the bios_grub partition) | 15:49 |
| cjwatson | All I'm saying is that the way we avoid issuing warnings with guided partitioning is by not doing wrong things in guided partitioning :-) | 15:50 |
| cjwatson | (Which I think is already the case, as far as this matter goes) | 15:50 |
| cjwatson | Side-by-side won't touch the boot partition (of either type), and using the whole disk will set up a new one | 15:51 |
| cjwatson | partman-auto only has to be aware of the platform to the extent of setting up the right boot-type partition for it, and knowing how to reuse one that already exists | 15:52 |
| hallyn | all right reproduced it | 15:52 |
| cjwatson | All of that should be in place | 15:52 |
| bdmurray | mvo_: weird, all of those are empty for me | 15:52 |
| cjwatson | recipes/atomic is used on BIOS, and has "1 1 1 free $iflabel{ gpt } $reusemethod{ } method{ biosgrub } ." (i.e. "if GPT, reuse an existing bios_grub partition if present, otherwise make a new one") | 15:53 |
| psusi | so should the check for bios_grub || esp be in partman-efi, partman-partitioning, or one in each? | 15:53 |
| mvo_ | bdmurray: could you add some debug code into /usr/lib/python2.7/dist-packages/apt/package.py in @property descripton(self)? (around line 330) ? | 15:53 |
| cjwatson | recipes-amd64-efi/atomic is used on UEFI, and has "$iflabel{ gpt } $reusemethod{ } method{ efi } format{ } ." (i.e. "if GPT, reuse an existing ESP if present, otherwise make a new one") | 15:54 |
| mvo_ | bdmurray: to see if that fails maybe? anything special about this system? or is it a "normal" ubuntu install? (special as in different languages or something) | 15:54 |
| cjwatson | psusi: Hm, partman-partitioning/check.d/biosgrub *already* has code that does exactly this | 15:54 |
| cjwatson | # Is there at least one EFI System Partition or BIOS Boot Partition, as | 15:54 |
| cjwatson | # appropriate? | 15:54 |
| cjwatson | Worst case it has some slight bug and needs to be fixed, but we don't need to write that code again | 15:55 |
| mvo_ | bdmurray: do you have any output from "ls /var/lib/apt/lists/*Transla*" | 15:55 |
| psusi | ohh? hrm... it may not be working then | 15:55 |
| bdmurray | mvo_: it happens on a virtual machine too | 15:55 |
| mvo_ | bdmurray: I suspect for some reasons the "translations" are not downloaded for you (which means that you don't get the long descriptions) | 15:55 |
| mvo_ | bdmurray: the Package file only contains the short summary these days | 15:55 |
| cjwatson | psusi: should be visible in the partman log | 15:55 |
| psusi | I'll play around with it | 15:55 |
| cjwatson | under check.d/08biosgrub or something like that | 15:56 |
| mvo_ | bdmurray: but this does not make that much sense if you have the full description in the pkg.raw_description :/ | 15:56 |
| bdmurray | mvo_: yeah, that seems to be it. ls: cannot access /var/lib/apt/lists/*Transla*: No such file or directory | 15:56 |
| mvo_ | bdmurray: aha! so the question is why you don't get translations :) | 15:56 |
| mvo_ | bdmurray: I assume you never actively disabled them? what do you see with: $ apt-config dump|grep Languages | 15:57 |
| cjwatson | psusi: I'd be happy to look through logs of an installation that should have generated such a warning and didn't, if you have one to hand | 15:57 |
| cjwatson | (i.e. manual GPT partitioning and no ESP or bios_grub partition as appropriate) | 15:57 |
| bdmurray | mvo_: its my mirror, sorry | 15:58 |
| psusi | cjwatson: I'll try to reproduce it... unless this was a relatively recent fix? I just know I have seen a number of bugs where people didn't have the bios_grub partition so grub-install failed | 15:59 |
| mvo_ | bdmurray: no problem | 15:59 |
| mvo_ | bdmurray: good to know whats causing it :) | 15:59 |
| cjwatson | psusi: partman-partitioning 83ubuntu2 in precise | 16:00 |
| cjwatson | (before release) | 16:00 |
| hallyn | yeah the EMFILE doesn'tlook like a kernel issue - bc it does have a buttlaod of files listed in select | 16:00 |
| hallyn | and /proc/pid/fd shows 1024 open files | 16:01 |
| mvo_ | infinity: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1302033 fwiw, but looking over the changelog maybe its better if I just cherry pick stuff | 16:01 |
| ubottu | Launchpad bug 1302033 in apt (Ubuntu) "[FFe] apt 1.0" [Undecided,New] | 16:01 |
| infinity | mvo_: I like the idea of shipping the new shiny in trusty, but yeah, it might be too late to properly test all those changes. I'll go through the diff after I've slept and see just how crazy it really is. | 16:02 |
| infinity | mvo_: The build-profiles change is probably trivial and auditable, and I'd like it in, for instance. | 16:02 |
| mvo_ | infinity: mostly long, but has some mildly scary bits | 16:03 |
| mvo_ | infinity: I'm also a bit torn between shinny and conservative here :) | 16:03 |
| infinity | mvo_: I'll try to get a definitive answer to you soon enough that you can start cherry-picking things you really want if it's a "no". | 16:03 |
| * mvo_ goes and gets some dinner first | 16:03 | |
| * infinity wonders if it's too late to ship Packages.xz for trusty, or if we can get that through and tested before release day. | 16:05 | |
| infinity | hallyn: Did we give up on qemu 2.0, or is that still in testing? | 16:09 |
| bdmurray | mvo_: is bug 1286161 fixed in trusty apt already? | 16:10 |
| ubottu | bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161 | 16:10 |
| stgraber | hallyn: does it look like a cgmanager bug or did I mess up something in logind? | 16:13 |
| hallyn | infinity: absolutely did not give up on it. upstream hasn't released 2.0 yet though, | 16:14 |
| hallyn | infinity: so my plan on monday, if it is not released, is to push based on v2.0.0-rc0 + diffpatch | 16:14 |
| hallyn | stgraber: well it's possible that logind is keeping open it's files and so cgmanager never closes them... not sure yet | 16:14 |
| infinity | hallyn: Well, we're cutting it close. If you plan to push 2.0ish, and it's well-tested, we should do that sooner, rather than later, and update to a later rc/git/final as we can. | 16:15 |
| hallyn | stgraber: tbh since the testsuite doesn't do this it must be somethign logind is doing, but cgmanager should defend itself against it | 16:15 |
| === _salem is now known as salem_ | ||
| stgraber | hallyn: ok, so what does it look like, missing disconnect in some case? | 16:16 |
| hallyn | infinity: the 2.0 has been tested quite a bit out of ppa:ubuntu-virt/candidate fwiw, so it wont' be going into the archive green | 16:16 |
| hallyn | stgraber: yeah | 16:16 |
| infinity | hallyn: Right, it should still be ASAP is all I'm saying. :) | 16:16 |
| hallyn | stgraber: my guess would be the fds we pass in | 16:16 |
| hallyn | no wait, you're not doing scm anywhere right? | 16:16 |
| hallyn | infinity: ok, well i can push whenever. i just pushed a new pkg to ppa. | 16:17 |
| hallyn | infinity: now what i have now is based on a git snapshot tarball. is that ok, or is it better ot use the qemu v2.0.0-rc0 snapshot + a huge diff? | 16:17 |
| hallyn | (I prefer the former but i have a feeling it's not as 'correct') | 16:17 |
| stgraber | hallyn: nope, not doing a single scm call | 16:18 |
| hallyn | infinity: also since the debian qemu maintainer prefers to have qemu-ssytem-aarch64 be rolled into qemu-system-arm, i figure we should do that now before release | 16:18 |
| hallyn | infinity: any objections to that? (you've seen the pkg) | 16:19 |
| stgraber | hallyn: I also just re-checked the code and I always call close... | 16:19 |
| infinity | hallyn: Err, which Debian maintainer prefers that? mjt or vagrant? | 16:19 |
| hallyn | mt | 16:19 |
| hallyn | mjt | 16:19 |
| hallyn | stgraber: well running the testsuite 10 times doesn't leave a single extra open fd... | 16:19 |
| infinity | hallyn: aarch64 and arm really aren't the same platform at all, I feel like perhaps he's missing that. | 16:19 |
| hallyn | infinity: his feeling is if you can run armhf binaries on aarch64, then it's the same situation as x86/x86_64 | 16:20 |
| infinity | hallyn: You can't always. | 16:20 |
| hallyn | yup we've been over that | 16:20 |
| hallyn | anyway i can go either way, | 16:21 |
| infinity | hallyn: aarch64 doesn't require an ARM execution unit, it's an optional bolt-on. | 16:21 |
| hallyn | but if debian will merge them and we don't do it before 14.04 release, then we have to keep a metapackage until 16.10 | 16:21 |
| infinity | hallyn: But meh, I don't much care either. i386/amd64 are in x86, powerpc/ppc64 are in ppc, I don't mind if arm/aarch64 follow suit, even if it's less technically correct. | 16:21 |
| infinity | hallyn: So, if mjt won't move on the topic, bundle 'em up. | 16:21 |
| infinity | hallyn: As to the tarball, I don't care. There's nothing inherently more or less correct about one method versus the other, so long as you have a trust path of some sort to the original code. | 16:22 |
| hallyn | infinity: if you wanna go make the case in oftc#debian-qemu that it's less technically correct, maybe you can suade him :) vorlon and i couldnt | 16:22 |
| hallyn | cool | 16:22 |
| infinity | hallyn: So, signed tags in the git case, or signed tarballs in the orig case. | 16:22 |
| hallyn | ok i'll push that today, with or without the merged arm | 16:22 |
| hallyn | hm. signed tags? | 16:23 |
| infinity | hallyn: I'm not going to bother arguing the point, if both you and vorlon tried. Just merge. :P | 16:23 |
| hallyn | meaning there needs to be a tag by upstream? | 16:23 |
| hallyn | or just that the last commit id should show up in the version? | 16:23 |
| infinity | hallyn: Well, or signed commits. This isn't a "need", per se, just that, well, how else do you know you're not serving me some MITMed git repo of doom? :) | 16:23 |
| xnox | ls | 16:23 |
| hallyn | infinity: still missing the point <duncecap> - how to sign the commit? right now i have qemu_2.0~git-20140403.de03c31.orig.tar.gz | 16:24 |
| hallyn | where de03c31 is current git HEAD | 16:25 |
| infinity | hallyn: As in was the commit at the head of your branch signed by anyone? | 16:25 |
| hallyn | signed-off-by, yes | 16:25 |
| infinity | hallyn: And does git log --show-signature show that it was PGP signed? | 16:29 |
| infinity | hallyn: (signed-off != signed) | 16:29 |
| hallyn | nope | 16:30 |
| infinity | hallyn: Anyhow, like I said, this isn't some hard requirement, it's just the sanest way to an auditable trust path to someone who says the repo is sane. | 16:30 |
| infinity | There are tons of snapshots in the archive that aren't signed. :P | 16:30 |
| hallyn | the v2.0.0-rc0 tag isn't signed either actually, so i'll go with the snapshot :) | 16:30 |
| hallyn | thanks | 16:31 |
| hallyn | oh this'll be fun. kvm: malloc(): memory corruption: 0x00007f49cc8c3120 (qemu 1.0 on trusty kernel... probably my own fault) | 16:32 |
| stgraber | Laney: so I believe bug 1301846 shows an actual bug in logind which is usually avoided because logind would just make an invalid fs path and return -1, instead the new code sends that to normalize_controller which contains the assert. I have a fix for this now, doing a test build and will upload after lunch. | 16:35 |
| ubottu | bug 1301846 in systemd (Ubuntu) "loginctl crashed with SIGABRT" [Medium,New] https://launchpad.net/bugs/1301846 | 16:35 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| hallyn | stgraber: oh, how ar eyou opening your dbus connections? bc if you don't open them as private then they won't really be closed | 16:37 |
| Laney | stgraber: Yeah, I saw it comes all the way from the top but didn't check what logind does itself to avoid passing that in | 16:37 |
| hallyn | stgraber: yeah i think this might be the problem, | 16:38 |
| hallyn | stgraber: in lxc, we do connection = dbus_connection_open_private(CGMANAGER_DBUS_SOCK, &dbus_error); | 16:39 |
| hallyn | i guess logind is running as a part of a long-running lightdm (?) process. since it never exits it never closes any of the connections | 16:39 |
| hallyn | lemme try my hand at a patch... | 16:40 |
| hallyn | stgraber: so i'd try something like http://paste.ubuntu.com/7199494/ | 16:43 |
| hallyn | lessee if it builds over yonder, | 16:43 |
| hallyn | of course if that works, the question remains how cgmanager should defend itself against that | 16:46 |
| hallyn | hrmph. that didn't suffice | 17:13 |
| hallyn | d'oh, i see why | 17:16 |
| hallyn | let's try http://paste.ubuntu.com/7199648/ | 17:17 |
| bdmurray | slangasek: looking at bug 1090196 which continues to receive duplicates (see my last comment on it), do you have any ideas what we could do to improve the situation? | 17:29 |
| ubottu | bug 1090196 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.57-1ubuntu1: ndiswrapper kernel module failed to build [Cannot find kernel build files in ... Please give the path to kernel build directory with the KBUILD=<path> argument to make]" [High,Fix released] https://launchpad.net/bugs/1090196 | 17:29 |
| slangasek | bdmurray: unseed ndiswrapper as obsolete? | 17:30 |
| bdmurray | slangasek: on precise? | 17:30 |
| slangasek | oh, probably not so much there :) | 17:30 |
| slangasek | bdmurray: if this was fixed in dkms later, should we maybe backport that fix onto precise? Or do we know why users are winding up with the image installed but not the headers? | 17:31 |
| hallyn | stgraber: : http://paste.ubuntu.com/7199648/ seems to work | 17:33 |
| hallyn | smoser: jcastro: btw that also should fix the problem you had yesterday afternoon i recon' (at least for a bit) | 17:34 |
| bdmurray | I was guessing that people just read some web page that reads 'apt-get install linux-image-generic-lts-saucy'. | 17:34 |
| jcastro | hallyn, I am free now if you want to take a look | 17:34 |
| slangasek | bdmurray: why would any page say that? we don't recommend that users install enablement kernels on top of already-installed, already-working systems | 17:34 |
| hallyn | jcastro: can you just ps -ef | grep cgmanager to get its pid, then look at /proc/$pid/fd ? | 17:35 |
| hallyn | i assume you'll see 1024 fds there | 17:35 |
| slangasek | bdmurray: oh, because there's an askubuntu answer for this question - so it's all jcastro's fault! | 17:35 |
| hallyn | stgraber: ^ should I push with that fix? | 17:35 |
| hallyn | hm, /me back in 3 mins | 17:36 |
| smoser | hallyn, possible. | 17:37 |
| smoser | $ sudo ls /proc/267/fd | wc -l | 17:37 |
| smoser | 208 | 17:37 |
| smoser | that is what was there now. | 17:37 |
| smoser | but it isn't acting up now. | 17:37 |
| bdmurray | slangasek: most of what I'm finding seems to recommend linux-generic-lts-* though | 17:37 |
| jcastro | yeah I just did a string search and the lts-* is the one people are recommending | 17:39 |
| hallyn | smoser: log out and in a few times | 17:39 |
| bdmurray | jcastro: with linux-generic or linux-image-generic though? | 17:39 |
| jcastro | I as searching for linux-image-generic | 17:40 |
| bdmurray | jcastro: and that wouldn't install the linux-headers which is the problem. | 17:40 |
| jcastro | "sudo apt-get install linux-headers-generic linux-image-generic" seems to be common | 17:41 |
| jcastro | but I can do a doublecheck | 17:41 |
| bdmurray | jcastro: okay, if its both that's good | 17:41 |
| slangasek | jcastro: edit proposed on http://askubuntu.com/questions/257617/how-can-i-upgrade-the-ubuntu-12-04-2-kernel-to-3-5-0-23/257623#257623 | 17:41 |
| smoser | hallyn, http://paste.ubuntu.com/7199760/ | 17:42 |
| smoser | that is seriously leaky | 17:42 |
| hallyn | stgraber: pushed that change to ubuntu:systemd; i think you're working on another update so i'll leave it there for you. | 17:42 |
| hallyn | smoser: yeah, at least we know the fix for that. the next q is hwo to have cgmanager protect itself in teh future. looking at dbus/dbus-timeout.c | 17:43 |
| jcastro | bdmurray, protip: any user can do direct queries of the AU database: http://data.stackexchange.com/askubuntu/queries Handy if you want to search for a specific issue, compare it to say, pageviews of the results to investigate if there is a popular question giving out specific incorrect advice | 17:44 |
| stgraber | hallyn: back from lunch, looking | 17:46 |
| bdmurray | jcastro: oh neat, thanks | 17:48 |
| stgraber | hallyn: stacked my change on top of that one, test build running. | 17:54 |
| hallyn | cool | 17:54 |
| hallyn | stgraber: so i'm thinking two things: | 17:57 |
| hallyn | 1. have cgmanager keep a count of open connections per uid, limit those to say 5 (maybe 20 for root) | 17:57 |
| hallyn | 2. keep a nih_timer for each open connection, reset it on every method call, and close the connection after the default (25s) | 17:58 |
| stgraber | hallyn: 1) would cause some of my machines to fail quite miserably when I start a few hundreds of containers at the same time | 17:58 |
| stgraber | hallyn: 2) sounds fine | 17:59 |
| hallyn | maybe 1 isn't necessary | 17:59 |
| stgraber | hallyn, Laney: just updated to my patched logind here and things appear to be solid, not seeing any fd leaks on login/logout and logind hasn't crashed, uploading | 18:29 |
| hallyn | cool | 18:31 |
| mvo_ | bdmurray: hello, #1286161 is not yet fixed, I can cherry pick that as well or its fixed with the apt 1.0 update | 18:46 |
| === jackson is now known as Guest37026 | ||
| === Guest37026 is now known as Noskcaj_ | ||
| Noskcaj_ | seb128, Thanks for fixing the gnome-icon-themes-extra bug | 19:11 |
| seb128 | Noskcaj_, yw! | 19:12 |
| === roadmr is now known as roadmr_afk | ||
| barry | doko: what's the current state of cross building python packages? e.g. https://wiki.ubuntu.com/CrossBuilding under "Known large-scale problems" it says Python multiarch support, but the debian bug that links to is fixed. however, cross building e.g. autopilot according to the given instructions fails trying to install dependencies (python2.7). is the bug fixed in debian but not yet in ubuntu? | 19:33 |
| doko | barry: which build dependencies? | 19:34 |
| barry | doko: http://paste.ubuntu.com/7200212/ | 19:35 |
| doko | barry: try with --arch-only | 19:35 |
| barry | doko: you don't mean `sbuild --arch-only` since sbuild doesn't have that option. (but --no-arch-all still doesn't help) | 19:39 |
| doko | barry, for dpkg-buildpackage, it's -B (and -b if you don't want to touch the diff) | 19:40 |
| psusi | cjwatson: well darn... I thought that was goign to be nice and easy: I copied a chunk of code from check.d/biosgrub that detects an efi system partition and if not found, fall back to grub-pc, but it seems that you can't make use of parted in grub-installer? or should you and I just messed something up somehow? | 19:40 |
| barry | doko: hmm... --no-arch-all is supposed to pass -B to dpkg-buildpackage while --arch-all is supposed to pass -b | 19:42 |
| barry | doko: should that note about "almost fixed" in the CrossBuilding wiki page be removed? | 19:47 |
| doko | does it build for you? if yes, then yes, please remove it | 19:47 |
| barry | it doesn't, but i don't know whether that's caused by the bug or not. | 19:48 |
| doko | well, try without sbuild | 19:48 |
| barry | doko: i'm going to say in the context of that wiki page, it is not fixed. you can cross build e.g. apt just fine with sbuild | 19:52 |
| doko | cjwatson, ^^^ I don't agree with barry here. is this an issue with sbuild? | 19:53 |
| barry | similar problem with pure python3 applications | 19:56 |
| doko | barry, no. try to cross-build zope.interface. this works | 19:58 |
| * barry tries | 19:58 | |
| doko | sorry, can't help you with sbuild | 19:58 |
| barry | yeah no worries, if it's an sbuild problem, i'll file the appropriate bug | 19:59 |
| barry | i'm not going to remove that known problem from the wiki page until and unless i can get it working in sbuild, which is what that page is all about | 20:00 |
| barry | heh, cross building zope.interface *does* work in an sbuild. i'll look more closely at autopilot's control file | 20:02 |
| === roadmr_afk is now known as roadmr | ||
| cjwatson | psusi: there's existing code that uses libparted, just not the parted binary | 20:28 |
| cjwatson | psusi: parted_server isn't running so you can't use partman stuff | 20:28 |
| cjwatson | psusi: (please mail me if you're still stuck, we don't have very compatible IRC times) | 20:29 |
| psusi | cjwatson: yea, that's what my guess was | 20:34 |
| bdmurray | caribou: can you verify bug 1281066? | 21:07 |
| ubottu | bug 1281066 in deja-dup (Ubuntu Saucy) "Needs to backport trusty's fix to handle duplicity's lockfile" [Medium,Fix committed] https://launchpad.net/bugs/1281066 | 21:07 |
| Laney | stgraber: nice one | 21:26 |
| bdmurray | Laney: would you mind having a look at bug 1261096? I haven't quite been able to sort out why its restarting whoopsie all the time. | 21:28 |
| ubottu | bug 1261096 in whoopsie-preferences (Ubuntu) "whoopsie-prefernces respawns whoopsie in an infinite loop" [High,Confirmed] https://launchpad.net/bugs/1261096 | 21:28 |
| bdmurray | robru: is there a bug refernce for the unity-chromium-extension fix for "Pass string argument to MediaPlayer.init on to backend."? | 21:29 |
| stgraber | Laney: let me know if you get into any more trouble, we want to make sure that stuff is solid before we start shipping cgmanager on all systems whenever we finally land the support in upstart | 21:32 |
| kirkland | cjwatson: I encountered https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1302206 today, installing Ubuntu server | 21:49 |
| ubottu | Launchpad bug 1302206 in debian-installer (Ubuntu) "wifi configured and working in debian-installer, but not after installation at first boot" [Undecided,New] | 21:49 |
| kirkland | cjwatson: I'm curious if this is designed behavior, if this should have worked? | 21:50 |
| === salem_ is now known as _salem | ||
| stgraber | kirkland: I don't believe netcfg knows how to setup a NM wifi connection at least I can't remember seeing code for that last I patched that part of the code | 21:56 |
| stgraber | oh, though you said server | 21:56 |
| robru | bdmurray, not sure what you're talking about, sorry | 21:57 |
| kirkland | stgraber: I was surprised/impressed that when I chose wlan0 in d-i as my primary interface, it scanned my network, found my essid, prompted me for passphrase, connected, drew an ip | 21:57 |
| stgraber | I'd vaguely expect it to spit out a valid ifupdown config for wifi but maybe the code is less clever than I remembered | 21:57 |
| kirkland | stgraber: I was just disappointed that that working wifi network did not get committed to disk and wasn't operational on reboot | 21:57 |
| Laney | bdmurray: ooooooookay, don't know this code though | 21:58 |
| stgraber | kirkland: yeah and the code has logic to spit out ifupdown or NM config files for most of that, the NM stuff is pretty recent so I wouldn't be surprised that wifi is missing, I'm vaguely surprised it doesn't generate a working ifupdown config though | 21:58 |
| stgraber | kirkland: what's you /etc/network/interfaces like post-install? | 21:58 |
| Laney | Maybe you could see what whoopsie-preferences is doing | 21:58 |
| kirkland | stgraber: lo only | 21:58 |
| robru | bdmurray, oh, if you're referring to http://bazaar.launchpad.net/~webapps/unity-chromium-extension/13.10/revision/234, you'd have to ask justinmcp, he asked me to SRU it. | 22:02 |
| bdmurray | robru: yeah, I'm asking about change that was in 2.4.8+13.10.20131108.1-0ubuntu1 with no bug reference | 22:03 |
| robru | bdmurray, yeah, I don't know it, sorry | 22:05 |
| bdmurray | robru: but you uploaded it to saucy -proposed? | 22:06 |
| robru | bdmurray, no? I uploaded it to ppa:ubuntu-unity/sru-staging | 22:10 |
| robru | bdmurray, I gotta step out for a bit. I sent an email to justin asking about the bug and cc'd you. | 22:13 |
| bdmurray | robru: okay, thanks | 22:13 |
| robru | bdmurray, you're welcome | 22:13 |
| bdmurray | Sweetshark: is there a bug about an issue with OOXML and libreoffice? I'm looking at the libreoffice upload in the precise-proposed queue. | 22:17 |
| Laney | bdmurray: might have fixed it | 22:35 |
| Laney | you on amd64? | 22:35 |
| bdmurray | Laney: yeah | 22:35 |
| Laney | one sec | 22:38 |
| Laney | bdmurray: okay, give deb http://people.canonical.com/~laney/package-junkyard ./ a go | 22:40 |
| Laney | Let me know if it fixes it for you and I'll upload in the morning | 22:40 |
| Laney | going to bed now, see you | 22:41 |
| bdmurray | Laney: thanks, that seems like not enough though... | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!