[00:06] xnox: https://rt.admin.canonical.com/Ticket/Display.html?id=68468 [00:06] xnox: For now you'll just have to get IS to remove things for you [00:08] cjwatson: whilst modern style porter boxes would be nice, getting rapt to support "remove" command would be nice as well. [00:09] (limited to things outside of e.g. minimal and build-essentials or some such) [00:09] Maybe, but that just increases the chance of people clashing with each other. I'd rather we just had modern infra [00:13] xnox: Not supporting remove was an intentional design decision when we wrote rapt. [00:13] ok. [00:14] 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] (But yes, we should just move to the Debian way of doing things) [00:15] ? [00:15] doko: don't worry, we are not _actually_ breaking one of your in-progress 8h builds. it's just hypothetical =) [00:15] doko: You were just being used as a fictional example, not being summoned. [00:17] oh, I would like YOU to be summoned, and not just as a fictional example [00:17] 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] yeah, glibc sucks with test suites [00:19] infinity: so that patch from andrew fixes the eglibc build for me [00:23] oh i guess i should also glom up the test case [00:38] 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:39] mwhudson: So, that should be Will's setcontext patch, Will's testcase for same, and that 2-liner for the alignment issue. [00:39] mwhudson: With patch headers pointing to origin, since none of them are in git yet. :/ [00:39] infinity: i just commented on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1279620#9 [00:39] Launchpad bug 1279620 in eglibc (Ubuntu Trusty) "stack corruption running "go install launchpad.net/juju-core/..."" [High,Confirmed] [00:40] infinity: i don't know the formatting for patch headers, i can go find it out i guess... [00:40] hi guys I want to know if ubuntu 14.04 will work will daul boot [00:40] UBUNTUuser: yep [00:40] mwhudson: Oh, I don't care if it's formatted in any specific way. Garbage above the diff is fine. [00:40] mwhudson: I can fix it up, I just want the refs. [00:41] infinity: is that bug comment useful? i can email them as well... [00:42] you sure I am already having problems with ubuntu 13.10 [00:42] I have a uefi which secure boot [00:42] is on [00:44] UBUNTUuser: your question is probably better suited for #ubuntu, this is the dev channel [00:45] ok [00:45] mwhudson: Nope, that's perfect. [00:49] robert_ancell: Did you want your changelog for that lightdm to actually match reality? :P [00:49] infinity, um... what did I write? [00:49] robert_ancell: s/greeter/cursor/ [00:49] yeah, that would make more sense [00:50] 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] stgraber: xnox: I'm around now [00:50] infinity, there are many wrong changelog entries :) [00:50] robert_ancell: I don't doubt it. :) [00:51] cjwatson: so since you fixed bug 1300072 my trusty install works but now im running into bug 1274320 [00:51] 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] cyphermox: well, you could help me understand what's going on in silo11 and why it failed to build =) [00:51] bug 1274320 in grub2 (Ubuntu) "Error: diskfilter writes are not supported" [Medium,Confirmed] https://launchpad.net/bugs/1274320 [00:51] sure [00:51] robert_ancell: Also, wtf? -lstdc++? Is that not building with g++? [00:51] infinity, I have no idea, but the library build explicitly does that [00:51] so making the introspection match fixes the problem [00:52] cyphermox: it said it build everything, and then decided not to upload them.... or something?! [00:52] robert_ancell: Ahh, yeah, it's using cc [00:52] robert_ancell: Building C++ code with cc is usually a sign that one's doing something wrong. [00:52] cyphermox: i'd love to fix that up, if i new what needs changing. [00:53] oh, nice. [00:53] infinity, feel free to berate them on https://bugzilla.gnome.org/show_bug.cgi?id=727521 :) [00:53] Gnome bug 727521 in build "Fails to build on ppc64el" [Normal,Unconfirmed] [00:54] robert_ancell: Although... This could have more to do with the libtool macros being broken in that build. [00:54] robert_ancell: Did you test with just dh_autoreconf before adding the link hack? [00:54] checking whether the g++ linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes [00:54] Err, wrong paste. [00:54] checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no [00:54] ^-- Indicative of libtool macros needing love. [00:55] infinity, no, I only added it because I couldn't patch the Makefile directly without automake getting confused [00:55] robert_ancell: So, the above needs to be addressed. And if dh_autoreconf fixes the above, the lstdc++ thing probably isn't needed. [00:56] infinity, I can check, but I think it will need the -l stdc++ [00:56] robert_ancell: It really shouldn't if other arches don't. [00:57] infinity, g-ir-scanner is great at getting linking wrong [00:57] blkperl: expected, grub can't write to raid, not new [00:57] infinity, huh, you're right [00:58] (or lvm) [00:58] robert_ancell: Figured. I'll reject your current upload, then. :) [00:58] infinity, cheers :) [00:58] blkperl: and save_env involves writing to /boot/grub/grubenv [00:59] blkperl: the best we could do is maybe silence the error - but like I say it isn't a new thing [00:59] robert_ancell: You might want to followup to that upstream bug noting that all they need is a newer/saner libtool. [00:59] robert_ancell: So people don't go hunting in circles some other weird cause. :) [01:00] infinity, should I re-use -0ubuntu2 or do I make a -0ubuntu3? [01:00] robert_ancell: 2 is fine, the rejected one doesn't get used up. [01:01] xnox: tbh, I think there might be no way for me to tell you currently [01:02] xnox: let's try to run it again :/ [01:05] cyphermox: maybe add the two source packages to "Sources:" line? [01:05] 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] cyphermox: no idea if that will help the train driver or not =) [01:07] two new source packages? [01:07] chiluk: well that's not possible, they're built from the same source. [01:07] that's what I was thinking. [01:07] cyphermox: they are existing, in the archive, and i think they were previously released via train already. [01:07] and that patch was long ago. [01:08] yeah.. [01:08] xnox: well if the issue was with versions you should get an error earlier [01:08] cyphermox: right.... hm =) i'm clueless, all I know is how to operate dput =) [01:08] 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:09] xnox: let me re-run this step by step [01:09] cjwatson was afraid we were missing a define for the efi build maybe [01:09] if it really doesn't work I'll frankenstein the ci... dah [01:09] no longer have access to the jenkins box [01:09] chiluk: no [01:10] 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] chiluk: grub_serial_ns8250_add_port could fail for reasons other than the parsing, which would produce the same error [01:10] fyi, this isn't official business [01:10] chiluk: I think Vladimir has misdiagnosed this [01:10] k thanks [01:10] chiluk: also grub_serial_ns8250_add_port doesn't seem likely to work on class 3 (or whatever the terminology is) EFI devices [01:11] chiluk: you'd need something involving the efiserial driver [01:11] any suggestions on how to go about debugging grub? [01:11] chiluk: which seems to generate efiXXX style port names [01:12] I'm not familiar with that style [01:12] are you suggesting trying serial --port=efif0e0? [01:12] cjwatson or something similar [01:12] I think they're sequential rather than a big hex number [01:13] efi0, efi1, etc. [01:13] cool give me a sec to check. [01:13] don't offhand see how to get a list of registered ports [01:14] I'm out of my element here... [01:14] oh, the output of "terminal_input" without args should include them with "serial_" prefixed [01:15] robert_ancell: That did the trick, cheers. [01:15] infinity, thank you. I learned some more obscure build system knowledge today :) [01:17] cjwatson terminal_input yields "serial_* serial at_keyboard" [01:18] 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] chiluk: maybe your EFI just doesn't probe the serial ports [01:18] which is possible [01:18] I have a bug open with intel as well. [01:18] xnox: got it now: https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/+packages [01:19] 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] cjwatson, it's showing up as 2.02~beta2-8 [01:19] right, good [01:19] cyphermox: \o/ [01:20] 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] It's a NUC, so about as bleeding edge as it can be without being an engineering sample. [01:20] cyphermox: will test from silo as soon as they are ready, and will ping you about publishing them. [01:20] chiluk: grub-core/term/serial.c grub-core/term/efi/serial.c would be the places to start [01:20] (I'm not convinced that NUCs aren't pretty much engineering samples, from all the bugs I've heard people complain about) [01:20] probably the latter [01:20] ah... efi/serial.c missed that one [01:20] infinity, I have mine working pretty darn well./ [01:20] you'll probably want to add traces to the loop in grub_efiserial_init [01:21] except for this efi issue everything else seems pretty decent. [01:21] cjwatson, stupid question... what's best way to print out info without printf? [01:21] chiluk: Everyone seems to have their pet complaint. This is yours. :) [01:21] infinity, I even have kvm working reliably-ish. [01:21] chiluk: err, I don't quite get the question, grub_dprintf is generally the best way to debug grub [01:22] that's the answer I was looking for. [01:22] there's a grub_printf to print things unconditionally [01:22] but you indeed don't have the standard C library [01:22] right.. [01:22] I haven't screwed with things this early in boot before. [01:23] see e.g. grub-core/disk/efi/efidisk.c for an example of using grub_dprintf [01:23] though it's scattered pretty liberally over the codebase [01:24] the first arg to grub_dprintf is something that you might put in "set debug=" [01:26] 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:27] sure, it's possible. I think it's been confirmed to work at least sometimes :) [01:27] for such old-school tech it should work all the time. [01:30] chiluk: serial may be old-school tech, but EFI serial sure isn't. [01:31] The driver only went into 2.02, IIRC === salem_ is now known as _salem [01:31] Oh, no, git says it was in 2.00, just a couple of patches since then [01:32] But even so [01:34] cjwatson: alright thanks, good to know its nothing serious :) [01:51] something is pulling in the entire Unity world on Ubuntu GNOME :( [02:06] cyphermox: i have finished testing all packages from silo 11, please upload them into -proposed. [02:06] cyphermox: all is good. [02:10] xnox: done [02:30] 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] Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] [02:39] xnox are you still around and will to upload https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 [02:39] Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] === thegatta_ is now known as thegattaca [03:13] FourDollars: hey, re: your bluetooth patch === maclin_ is now known as maclin [03:14] cyphermox: yes [03:14] I'm not convinced it would really fix the crash... [03:14] cyphermox: Err... XD [03:14] I agree with the extra check, but it's freeing the caps list in the device that crashes bluez [03:15] cyphermox: Because it is freed before. [03:15] 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:16] 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:17] if you tell me you could reproduce the crasher reliably on your hardware and it fixed it, then all good :) [03:17] cyphermox: Before it runs to the crash place, it will run unix_device_removed(). [03:18] oh wait a second [03:32] FourDollars: can you easily reproduce this crash? I can't here. I'd really like to see the backtrace for all threads [03:33] cyphermox: Yes, I can easily reproduce this issue. [03:34] cyphermox: I need some time to setup the environment because I am working on many different machines for this issue. [03:34] oh ok [03:36] ah, I see what's happening now [03:37] Do you stiil need the backtrace for all threads? [03:38] cyphermox: ? [03:39] no, I don't [03:40] OK [03:40] I see what you're doing now, fully agree with the patch, I'll upload now for trusty, and then for precise [03:40] Thanks a lot. :D [03:55] stgraber: fyi, now that udev links w/ libcgmanager0, d-i ftbfs due to a lack of a libcgmanager-udeb [03:55] hallyn: ^ [03:57] and libnih0 apparently [03:57] stgraber: Also, upstart needs udebs now because of that (nih and nih-dbus) [03:57] Which might be a slipper slope... [03:57] 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] Disabling cgmanager support in the udev udeb pass might be smarter. [03:58] 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] stgraber: With --as-needed, I wouldn't expect it to be. [04:00] ./lib/systemd/systemd-udevd [04:00] libcgmanager.so.0 => not found [04:00] It's definitely udevd itself that's linked to it. [04:01] stgraber: I'll just add --disable-whatever to the udeb pass and test that. [04:01] infinity: right, --disable-cgmanager should do the trick [04:02] 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] stgraber: It probably statically links libsystemd, because Lennart and Kai. [04:03] stgraber: And your cgmanager stuff is built into libsystemd, so... [04:03] Testbuilding now. [04:10] hey infinity want to do an upload for https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 as well? [04:10] Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] [04:13] stgraber: http://paste.ubuntu.com/7197140/ Looks like success. [04:14] stgraber: And in the queue, if you'd like to do the honours. [04:14] infinity: looks good, will review in the queue. Thanks for fixing that one! [04:14] hey stgraber I see you listed as a patch pilot would you help me with an upload for bug 1301692 ? [04:14] 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:16] 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:17] sure thing.. I'll harass tomorrow's patch pilot === jackson is now known as Guest50945 === maclin__ is now known as maclin [06:47] good morning [06:48] hey dholbach [06:49] hi darkxst [06:50] 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] bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Incomplete] https://launchpad.net/bugs/1294891 [06:50] s/was/wasnt/ [06:50] is that what you meant? [09:04] Are SRU for packages in Universe handled differently than for those in main ? [09:04] Nope [09:05] Laney: ok,thanks [09:22] mvo_!!! [09:22] hey mpt [09:25] * janimo hugs mvo [09:29] * mvo_ hugs janimo [09:47] 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] Launchpad bug 1294124 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with AssertionError in confirmChanges()" [Medium,Confirmed] [09:47] it's ranked 3rd on the daily e.u.c trusty report with 30 reports in a day === vrruiz_ is now known as rvr [09:53] 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] jibel, what bug? [09:53] seb128, 1294124 [09:54] jibel, you mean it doesn't match https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721 ? [09:54] jibel, I'm not sure what you are getting at? it's not a bug? it's mistriaged? [09:55] seb128, I mean this signature matches any upgrade that fails because a package is non-upgradable [09:55] in that case 'brasero' [09:55] where do you see that? [09:55] jibel, I'm looking at https://launchpadlibrarian.net/169922204/Traceback.txt ... are we looking at the same thing? [09:55] seb128, from apt.log [09:56] I mean the signature [09:56] where do you see it [09:57] https://launchpadlibrarian.net/169922201/DuplicateSignature.txt [09:57] I don't see anything on https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721 [09:57] jibel, that has the python bt? [09:57] 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? [10:00] shouldn't* [10:03] 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] jibel, let's fix the assert and make it report the actual errors then :p [10:04] jibel, do you know why those packages (e.g brasero) are non-upgradable? [10:09] seb128, not yet, I'll try to reproduce it. [10:09] jibel, thanks [10:10] * seb128 shakes fist at ted [10:11] my desktop greets me at each login with an apport prompt about click :/ [10:11] seb128: is that still from those few days where a new indicator version pulled in all of click? [10:12] 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] things like click list work there [10:12] even if the clicks can't be run from unity7 === zyga_ is now known as zyga [10:16] https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1290997 [10:16] Launchpad bug 1290997 in url-dispatcher (Ubuntu) "click crashed with gi._glib.GError in run(): Child process exited with code 139" [High,Triaged] [10:17] right [10:17] which is why I shake my first at ted :p [10:18] (it also tops e.u.c since yesterday) [10:18] 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] 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] slangasek: do you agree, or am I missing something here? === MacSlow is now known as MacSlow|lunch [10:38] pitti: yes, please! [10:39] pitti: is logind also present on the servers and taking care of login buttons there? [10:39] pitti: atleast acpid shouldn't do anything if there is logind present. [10:41] xnox: yes, that seems like the easiest solution then (pidof systemd-logind) [10:41] xnox: I'm not sure whether it's running on all servers, but it might not be [10:42] 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:47] I made a comment on the bug, I'll look into that [10:48] * Laney finds some systemd-cgmanagery bugs [10:59] 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. [11:00] xnox: sure; it's a mostly useless web app anyways :-P [11:01] xnox: is it already unpublished by dbarth? [11:01] yeah, it never had any mobile CSS either [11:01] sergiusens: yes, he unpublished it in the store. [11:02] sergiusens: yup unpublished; see if you need to let your script now [11:02] know [11:02] xnox: dbarth done [11:03] cool thanks [11:03] next sync should do the right thing at 11 after the clock [11:09] xnox: FTR, logind isn't on our server images (meh.. we keep dragging along acpid/acpi-support) [11:09] xnox: so instead of completely ripping it out, let's go for "check for logind" for trusty, yes [11:09] acpi-support will survive us all.. [11:10] pitti: it will do for another 5 years =) [11:10] seb128, hi! [11:12] 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] 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 === ara is now known as Guest11257 [11:20] ypwong, hey, sure, adding to our list [11:21] happyaron, ^ would you have a free slots to look at that one? === mino_ is now known as mino === slacker_1l is now known as slacker_nl [12:41] 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] infinity: just re-run "prepare-testbed amd64" is the easiest [12:41] pitti: Won't that download a fresh cloud image all over? [12:42] infinity: with the prepare-testbed VMs it's not trivial to dist-upgrade them; you can do it, though [12:42] infinity: yes, it will; but they aren't particularly big [12:42] Bigger than a dist-upgrade.:) [12:42] But will keep that in mind the next time it annoys me. [12:43] infinity: so run the image with -hda pristine-trusty-amd64-20140324_084956.img and -hdb pristine-trusty-amd64-20140324_084956.img.seed [12:43] with whichever images you have [12:43] and then log in as ubuntu/ubuntu and dist-upgrade [12:44] 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:48] 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:51] infinity: it's in the pipeline :) https://wiki.debian.org/MartinPitt/DistributedDebCI [12:51] infinity: that already exists in autopkgtest [12:51] pitti: Which already exists? Mirror/proxy selection? [12:51] 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:52] adt-buildvm-ubuntu-cloud --help [12:52] pitti: Oh, should I be using something other than lp:auto-package-testing? I was just following a random wiki. [12:52] -m URL, --mirror URL Use this mirror for apt (default: [12:52] http://archive.ubuntu.com/ubuntu) [12:52] -p URL, --proxy URL Use a proxy for apt [12:52] and adt-build-lxc just automagically uses whichever apt proxy you have on the host [12:52] that doesn't have a --mirror yet, please file a bug if you need that [12:53] infinity: you can use the new stuff; lp:a-p-t is still what we are running in production [12:53] 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:54] 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:55] 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] 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] pitti: Ahh, cool. Alright, I'll look at that at some point. [12:55] 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:56] 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 :) === _salem is now known as salem_ [12:56] pitti: Pointing out the doc on the above page might be helpful. ;) [12:57] 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] infinity: yes, I'm going to do that once we actually switch over production [12:57] infinity: I think for now the official answer is still "prepare-testbed every day" and "run-adt-test" [12:57] it's just about as expensive as it can get, but it's easy === StevenK_ is now known as StevenK === wgrant_ is now known as wgrant === ara_ is now known as ara [14:16] pitti: have you had a change to look at my apport-retrace package versions branch? === brendand is now known as brendand-afk [14:17] hallyn: any idea what could be causing bug 1301882? from the backtrace it looks like we're stuck in ping... [14:18] bug 1301882 in systemd (Ubuntu) "systemd-logind can get hung in cg_enumerate_tasks" [Undecided,New] https://launchpad.net/bugs/1301882 [14:18] mvo_: Hi, would you mind having a look at bug 1300465? Its not too important but curious. [14:18] bug 1300465 in python-apt (Ubuntu) "description dialog is empty" [High,Triaged] https://launchpad.net/bugs/1300465 [14:19] sure [14:19] bdmurray: I "stole" #1286161 from you, hope you don't mind [14:19] mvo_: heh, not at all! [14:20] jcastro: He's mine, back off. [14:20] Erm, ECHAN. [14:21] 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] 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] 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] mvo_: what might go wrong with the fix for bug 1286161? [14:21] 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:24] bdmurray: sorry, not this week; the sprint takes pretty much all brain and time, I'm afraid [14:25] 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] mvo_: And then convince me directly that it's low impact, and why. ;) [14:26] stgraber: I'll take a look [14:28] pitti: ah, didn't know you were sprinting [14:30] bdmurray: on the phone right now, will reply in a bit [14:32] stgraber: do you know if cgmanager had crashed/restarted? [14:33] hallyn: don't know [14:33] Laney: can you post your /var/log/upstart/cgmanager.log in the bug? [14:33] ok lemme set up a victim vm to torment [14:33] stgraber: oh yes, sorry, which one? [14:33] or either I guess [14:34] btw I got it back into the borked state accidentally if you want some data out of it :-) [14:34] stgraber: i can't imagine why it would've happened otherwise. especialy on ping [14:34] Laney: you had no containers running right? [14:35] hallyn: I almost certainly did, I usually do === pedronis__ is now known as pedronis [14:35] and certainly do now [14:36] Laney: oh but that shoudl be fine, i should've asked, the ping hang didn't happen in a container? [14:36] Everything I was doing with loginctl was outside [14:37] hallyn: log is attached [14:38] thanks. [14:47] 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:48] thanks infinity, I will do this [14:48] mvo_: okay, jibel you could do some automated testing with that new version of apt right? [14:49] stgraber: logind doesn't do any threading right? [14:51] 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:53] bdmurray, sure, if you provide a deb, I can run the tests with this version. [14:53] mvo_: why don't you upload it to the saucy-proposed queue and I'll approve it later today [14:54] bdmurray: sounds good [15:01] pitti: the powerd debug symbols seem to be out of date [15:01] 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:02] 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] slangasek: this acpid{d,support} stuff is annoyingly sticky :( [15:02] pitti: ah, doh [15:03] bdmurray: checking where it was built and trying to rescue [15:04] pitti: thanks [15:06] bdmurray: hm, the ddebs are nowhere on kishi06/toyol/lamiak, so there's nothing to rescue I'm afraid [15:06] 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] 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:07] bdmurray: "powerd has no unstripped objects, ignoring" [15:07] bdmurray: so I think powerd is built without -g [15:07] psusi: ah, see, this is why I hate having ubiquity tasks on bugs that just amount to incorporating new included sources [15:08] yep [15:08] psusi: closing, thanks [15:08] bdmurray: so the build log doesn't have any -On option or -g [15:09] bdmurray: that's a "cmake does not respect $CFLAGS" kind of bug, I'm afraid [15:09] 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] sound like a good idea, and if so, what is the partman-xxx to file the bug against? partman-efi, or partman-auto? [15:10] 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] or better yet, switch to using grub-pc instead of grub-efi [15:11] psusi: maybe partman-efi. not sure we *can* switch to grub-pc at that point, it may not necessarily be able to install [15:12] psusi: certainly not partman-auto === brendand-afk is now known as brendand [15:12] 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:13] cjwatson: why wouldn't it be able to install? [15:13] stgraber, (it only happens ever 20th to 60th boot, which kills the devices in the lab) [15:13] (i noticed plenty of mesaages where gcmanager repawns a few times during a normal boot) [15:14] ogra_: and I don't suppose adb is up by the time it hangs? [15:14] 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]