[00:23] // TODO:: fix alignment of src! [00:23] yathink [00:25] armhf and alignment? :) [00:25] I dealt with those in the past, but I got the impression our newer armhf kernels had traps to magically handle that. [00:26] At least, the same failures I saw in the past stopped happening. [00:28] rbasak: it's actually an increased problem, for whatever reason the arm64 kernels don't do fix-ups so when LP moved to armhf containers on arm64 things started failing. Which is not a bad thing, given that the Android BSP kernels do the same [00:31] Ah, that makes sense. [00:33] Does /proc/cpu/alignment exist on arm64? On armhf, it's the default that changed in our kernels I think. But it makes sense to not fix it. [00:33] (well, "fix" it) [00:40] bug 1556599 looks *fun* [00:40] bug 1556599 in kubuntu-meta (Ubuntu) "ISO images don't have valid partition tables" [Undecided,New] https://launchpad.net/bugs/1556599 [00:46] rbasak: yeah, no /proc/cpu/alignment at least on porter-arm64 [00:49] tsimonq2: should probably be reassigned to the ubuntu-cdimage project; but also, we've been using the same boot code on all these images for a while now, and the list of tools the submitter mentions trying to use strongly suggests user error here [00:49] slangasek: yeah, I was thinking PEBKAC [01:30] hmm, anybody familiar with GNOME/GTK software? there's a rather trivial bug that I'd like to fix, but I've never even touched anything like that [01:31] (anybody familiar with that that has a half an hour to spare ;) ) [02:02] tsimonq2: just ask your question ;) [02:03] oh yeah I should do that [02:03] :P [02:03] * tsimonq2 slips Lubuntu hat on [02:05] let me find this bug... [02:05] bug 1516454 [02:05] bug 1516454 in gnumeric (Ubuntu) "gnumeric menu ->help ->about gnumeric -> license button, does not work." [Low,Confirmed] https://launchpad.net/bugs/1516454 [02:05] shouldn't it be as simple as mapping the button to the correct spot? [02:07] are any errors printed to stderr? or xsession errors? [02:07] let me fire up my Lubuntu VM here... [02:07] you might get lucky and see an error message with the exact cause :) [02:08] good idea sarnold [02:08] it's been a Lubuntu bug for a while now and it seems trivial enough [02:09] I could imagine the actual cause could span a huge range of possibilities, from "no one has bothered to implement the dialog box yet" to "the name of the widget was misspelled in an API that doesn't provide any compile-time error checking" [02:10] the only error-looking output that I don't know what it is is an error about not being able to connect to the Accessbility bus [02:10] which I don't think would cause that? [02:10] probably not [02:12] if it was written in Qt, I'd be able to use Qt Creator's awesome little tools to figure it out [02:12] but unfortunately it doesn't seem like there's anything like that for GTK [02:14] the question is, where do I start? [02:17] I'd look at the source code for where that button is defined [02:18] ok [02:18] usually what I do is rgrep through the source for keywords I'm looking for ("License" in this case), to have somewhere to start with [02:18] what's the difference between grep and rgrep? [02:18] rgrep is grep -r [02:18] oh ok [02:18] my first attempt kind of failed... no real license buttons here http://sources.debian.net/src/gnumeric/1.12.32-1/src/dialogs/dialog-about.c/ [02:19] no, doesn't appear to be [02:19] but I did giggle at "comments", _("Free, Fast, Accurate - Pick Any Three!"), [02:19] I wonder if you're not seeing the about dialog rendering the contributors animation as a button [02:20] the screenshot -really- looks like it's supposed to be a clickable button. heh. [02:21] oh indeed [02:21] but also, oh, that looks like magic about dialog magic. [02:21] seems like there's no definition for that in the code... [02:22] I also need to update the bug to include the fact that Credits doesn't work either [02:22] I bet GTK_TYPE_ABOUT_DIALOG does this automatically in some cases [02:24] yep, that's deep in gtk [02:24] cyphermox: ha! that l9ooks like it [02:25] "You can specify license information with the “license” property " https://developer.gnome.org/gtk2/stable/gtk-migrating-GtkAboutDialog.html [02:26] so it might be a GTK bug? [02:27] well [02:27] They Probably Hoped[tm] that authors would set the properties and thus make the buttons useful [02:27] tsimonq2: so, the gist of it is that when you reach an issue like this, it's often useful to go dig in yet more code -- in this case, the gtk source, to figure out what happens when the about dialog is being created -- so that GTK_ABOUT_DIALOG generates the License button itself; and the buttons are hooked up to specific properties that are configured as you insitanciate that object [02:27] right [02:28] it's not a GTK bug, but a property missing in gnumeric. as you mentioned, very straightforward to fix [02:28] you could bicker and argue about whether itt's a good idea to show the buttons if the properties aren't set... [02:28] ok, thanks guys for guiding me in the right direction :) [02:33] sarnold: well, yeah, I suppose ;) [02:34] tsimonq2: so the fix is a one-liner [02:34] \o/ [02:34] dunno, I found GPL2 and GPL3 ilcense files there, that's a very long line :) [02:34] sarnold: no [02:35] you can set it with a property which takes an enum ;) [02:35] oh! I got distracted by the mention of the type of dialog box it would show and their recommendation to use paragraphs [02:36] right; I think it would suffice to set license_type; and from there things would work and be correct [02:36] Gnumeric says GPL2 or 3 at your choice, that reads to me as GPL2+ [02:39] so I might need a license property? [02:39] I think it ought to be license_type [02:39] I can dig into it more tomorrow when I've had a bit more sleep and my brain is ready for this type of debugging, but for now, I was wondering if you guys saw anything obvious [02:40] tsimonq2: yep [02:40] tsimonq2: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license might help [02:41] my opinion would be to give you a chance to fix it yourself, and thus claim an upload (I'll be happy to sponsor) [02:42] awesome, thanks :) [02:50] cyphermox, sarnold: GPL-2, GPL-3, or both? I'm reading debian/copyright and I'm a bit unsure about what I should put... [02:50] or even GPL-2+? [02:51] tsimonq2: I haven't studied it closely but GPL-2+ feels like a likely fit [02:52] ok I'll assume that for the time being [02:52] tsimonq2: it might not hurt to check upstream gnumeric repo and see if they've already addressed it [02:52] LocutusOfBorg: are you planning on uploading the fix for llvm-toolchain-3.6? [02:52] sarnold: good stuff [02:52] ok [02:53] tsimonq2: "cherrypick checkin ..." is a lot easier to review than new code :) [02:54] +1 [02:56] hmmm, seems like it's *not* upstream [02:56] amazing how a tiny thing turns into a medium thing quickly :) [03:03] hmm, DuckDuckGo didn't return anything, so does this look right to you guys? http://paste.ubuntu.com/23282692/ [03:03] multi-line GTK properties [03:04] tsimonq2: it's probably better to set the license-type property isntead: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license-type [03:05] https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkLicense [03:05] ok got it [03:17] sarnold, cyphermox: that didn't work :( [03:18] and I should really go to bed [03:18] good night everyone o/ [03:21] goodnight tsimonq2 :) [04:38] Good morning [05:49] good morning [06:27] nacc, I can't, I'm not a core-dev, just let caribou upload it [06:54] nacc, Thanks, I will have a look at the shutdown script issue [07:10] doko_: oSoMoN: cjwatson: re: Qt/QML arm64 problem. it doesn't indeed seem to be anything I can revert, and it doesn't happen on my arm64 device (frieza). so it's likely due to the builder kernel update, and it would need a real fix somewhere, I don't know where. it might go away once I backport V4 JIT for arm64 http://code.qt.io/cgit/qt/qtdeclarative.git/log/?qt=grep&q=arm64 but that won't happen for [07:10] yakkety of course. [07:12] (I'm sad that the search url there doesn't give any more entries of potential Qt side fixes) [07:49] Mirv: do I understand correctly, that this is QML issue does not only affect tests, but also real apps? [07:52] mardy: maybe since it's happening in executing QML code, but only if you run apps on similar device/configuration to the builder machines.. whatever part of the configuration has the cause for the problem. so, things compile and run fine on my Bq tablet. [08:11] Mirv: should we temporarily disable arm64 tests, or do you have some other tricks in the sleeve? [08:31] pitti: hi I was trying to set up an autopkgttest environment on my s390x lpar, using autpkgtest 4.1 I could avoid some issues (like bad default mirror), but eventually I'm stopped by sometihng not happening as expected "timed out waiting for "login prompt on ttyS0"" [08:32] pitti: the image boots just fine if I throw it at a qemu-kvm, so I wanted to ask if there are known issues or obvious steps missing? [08:32] cpaelzer: how did you create the image? you should normally use autopkgtest-buildvm-ubuntu-cloud for it [08:32] pitti: sudo ~/autopkgtest-4.1/tools/autopkgtest-buildvm-ubuntu-cloud -v --arch=s390x --mirror=http://ports.ubuntu.com/ubuntu-ports -r yakkety -s $((10*1024*1024*1024)) [08:32] cpaelzer: that will start a root bash on ttyS1 so that autopkgtest can talk to it; if that doesn't exist, it needs to be able to log into a getty on ttyS0, so that must start [08:33] cpaelzer: (-s can take something like "10G") [08:34] cpaelzer: if you boot it in kvm with -serial stdio, do you see the boot messages and can log in? [08:34] I didn't add any serial on my last try, the defaults worked [08:34] let me add -serial stdio [08:35] -serial stdio fails as the default sclp console already grabbed stdio [08:35] should I disable sclp [08:36] or is that it boots just fine via sclp console proof enough? [08:36] pitti: ^^ [08:36] cpaelzer: I don't know what sclp is [08:36] cpaelzer: but if ttyS0 doesn't work for the console, then autopkgtest won't work with it [08:37] it is "their" native console protocol [08:38] and thereby what you get when you do nothing [08:39] cpaelzer: hmm, no idea what that is, but I figure if a normal serial console doesn't work then the qemu runner and/or the image build needs to be adjusted for that [08:48] pitti: the default console is sclp which is a line mode console, using -nographic that already is connected to stdio and working fine [08:48] pitti: if I need a "normal" console I can use virtio-serial e.g. by appending -chardev socket,path=/tmp/port0,server,nowait,id=port0-char -device virtio-serial -device virtserialport,id=port1,name=org.fedoraproject.port.0,chardev=port0-char [08:48] pitti: I'm not sure what that implies for the ttyS0 you need for autopkgtest [08:49] cpaelzer: what it does is it connects to ttyS0 and waits for a "login: " prompt [08:50] cpaelzer: and then it either checks if there is a root shell on ttyS1, or if it can log into ttyS0 if you gave it a user and password as options [08:50] cpaelzer: i. e. it needs a foot into the door -- it's really difficulty to communicate with a QEMU instance, there's nothing like lxc-attach or lxc exec or schroot -r [08:51] pitti: yeah I agree, so that is what you do via the -serial unix:/tmp/autopkg... then right? [08:51] cpaelzer: and a serial console is the most common thing; I guess you can massage that to work with that console, might just need an option to specify a differnt device name? [08:51] right [08:51] I'll add one on my own and see if/what spawns there [09:05] mardy: at the moment no other tricks, since I only just managed to rule out that it's not anything I changed (since I had recent qtbase and qtdeclarative updates), and that it does not happen on our arm64 hardware [09:10] pitti: without further tweaking nothing seems to spawn on those extra consoles (and no /dev/tty* entries created) [09:10] pitti: it is ok for me to step away, do you want a bug to document it for later on with what I've found so far? [09:11] cpaelzer: if you want to dump it in a bug, sure; I can't work on it myself anyway as I don't have access to this env [09:11] * pitti is still amazed how different everything is with s390x :) [09:11] pitti: I'll dump and I'm sure xnox can give you access to some in instance your team if you need/want [09:14] ok collected the arm64 issue facts to bug #1630906 [09:14] bug 1630906 in ubuntu-push-qml (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/1630906 [09:21] cjwatson: oSoMoN: doko_: bug #1630906 has the collected failures, happens on vivid + xenial + yakkety [09:21] bug 1630906 in webbrowser-app (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/1630906 [09:23] thanks Mirv. LP times out when I want to mark myself affected :/ [10:00] xnox: can you please push your upstart commits to bzr? or want me to grab the diff from LP: [10:00] ? [10:15] xnox: I pushed it now === alan_g_ is now known as alan_g [10:48] caribou: please take this for Debian too: https://launchpad.net/ubuntu/+source/makedumpfile/1:1.6.0-2ubuntu1 [11:04] doko_: ok, will do [11:06] pitti: I found a s390x way to get a login prompt onto those unix sockets and documented it in the bug. is there a way to inject/replace the default -serial parameters with my tweaked ones on my system? [11:07] pitti: I wonder if unblocking these just gets to the next hurdle or if it would run fine then [11:08] pitti, i have them locally, did not upload upstart to the archive yet, hence did not push..... [11:09] pitti, my question is who uploaded things =) [11:10] xnox: someone synced it from some PPA, and it's in -proposed; I had to do a followup upload, so I synced bzr and pushed my stuff on top [11:10] cool, thanks. [11:10] cpaelzer: not one with options, as I didn't expect this case; you can of course create a locally hacked up autopkgtest-virt-qemu to play around with [11:11] pitti: ok, looking at virt/autopkgtest-virt-qemu atm [11:12] sil2100, 2016-10-06 08:45:17 +0100 (sil2100) Publishing packages. [11:12] it would be nice not to land my stuff for me =) [11:13] sil2100, especially without autopkgtest results. [11:13] anyway, it's superseeded now. so doesn't really matter at all. === hikiko is now known as hikiko|ln === highvolt1ge is now known as highvoltage [11:52] xnox: ah, right, the yakkety one - yeah, sorry, prematurely published that one [11:52] We wanted the xenial one badly and it was ok, so I insta-published the yakkety one without checking if all autopkgtests ran [11:53] xnox: but the xenial one was fine, everything passed and was green [11:53] sil2100, i thought you will copy xenial ppa into xenial overlay ppa (using copy-package, not release) [11:54] because xenial one is now stuck in SRU queue, and will be probably rejected there (as there is no bug # reference) [11:54] I did do a copy-package to the overlay, but I thought you wanted to have that released in xenial-updates too? [11:54] excellent then =) [11:54] yeah, i do want it in xenial-updates, eventually [11:55] My understanding was we release it to xenial-updates too as an SRU but I copy it to the overlay to have it faster (since as you can see we're really desparate for it ;p) [11:55] Sorry for the issues anyway [11:56] desparate times, need desparate measures =) [11:56] * xnox is struggling to escape from this island at the moment === marcusto_ is now known as marcustomlinson === hikiko|ln is now known as hikiko [12:08] sil2100, slangasek, robru: hi, question about bileto.ubuntu.com ACLs. any chance we could grant permissions to per-package uploaders so they wouldn't require a sponsor to test PPA fixes? [12:09] I thought that happened ages ago [12:09] I can push to bileto and I am not a coredev; I'm not sure if that applies to any Ubuntu package or just packages I have upload rights for [12:11] robru or someone had to add to me to the access list since ~ubuntu-dev don't have rights to bileto by default [12:12] interesting, the create new tickets fails with a 401 instantly for me [12:12] you may just need to be added to bileto-users [12:13] jbicha: bileto does archive.checkUpload in LP, so it should honour the usual permissions [12:13] yeah, do requests to get added to bileto-users have a defined process a.k.a who should I bother? [12:15] I guess sil2100 or robru could answer that [12:16] Yeah, I can do that [12:17] sil2100: https://launchpad.net/~paelzer that would be me [12:17] Yeah, the tricky part is... there is no fine grained ACL for bileto right now [12:17] pitti: hi! yesterday I uploaded click-apparmor 0.3.17 to fix an autopkgtest failure and it migrated (yay) [12:17] sil2100: to understand is that just membership of the normal LP group at https://launchpad.net/~bileto-users ? [12:17] cpaelzer: yeah [12:17] jdstrand: nice! [12:18] sil2100: that was the discussion before - is the ACL good enough to - once being member of the bileto-users - only push packages you are supposed to [12:18] pitti: apparmor-easyprof-ubuntu got hung up on click-apparmor 0.3.15 and 0.3.15 failures (boo :) [12:18] sil2100: and cjwatson referenced that it calls archive..checkUpload [12:18] pitti: and I thought it would get retried against 0.3.17 and then pass, but it looks like the retry against 0.3.17 didn't happen [12:18] cpaelzer: yeah, basically for the publish step that's true, but there is a problem elsewhere [12:19] jdstrand: maybe you retried before 0.3.16 was published? [12:19] pitti: can you look at update_excuses.html and advise? [12:19] jdstrand: I'd just try it again [12:19] cpaelzer: since there is no finer ACL, this means that anyone having access to bileto can basically modify/interact with any other ticket, not only his/her own [12:20] pitti: plausible? this was several weeks ago-- click-apparmor failed initially cause of a problem in click, which took a while, then that exposed an autopkgtest failure in click-apparmor, and I dragged my feet on fixing it [12:20] jdstrand: http://autopkgtest.ubuntu.com/packages/c/click-apparmor/yakkety/amd64 so the run for apparmor-easyprof-ubuntu/16.10.3 happened two weeks ago against 0.3.16 [12:20] s/which took a while/which took a while to get fixed/ [12:20] jdstrand: yeah, we don't auto-retry failed tests [12:20] ah [12:20] ok, so that explains it [12:20] cpaelzer: so even though there is no risk of publishing something you dont't have power over, but a problem in possibility to hijack (or by accident) do something with other landings [12:20] jdstrand: I have a bug about that, but right now that doesn't happen [12:20] pitti: so, what should I do to get it migrating? [12:21] jdstrand: just retry the test [12:21] cpaelzer: will bring this up a few people and will get back to you if we can do something here [12:21] *bring this up with a few [12:21] pitti: I'm not sure from update_excuses.html what to retry. the apparmor-easyporof-ubuntu tests passed and the links for click-apparmor are to the known failing versions [12:21] jdstrand: the queue is currently veeeery long (glibc update), but I'll cut that off in a few hours [12:22] jdstrand: retry the click-apparmor ones for a-e-u (i. e. the failing ones), that's the right thing [12:22] autopkgtest for click-apparmor/0.3.16: amd64: Regression [12:22] jdstrand: a retry will always run against the latest version of the package (it doesn't have any other choice anyway :) ) [12:22] retry that one ^ [12:22] correct [12:22] (and the other two? [12:22] ok, thanks! [12:22] jdstrand: so on a re-run you'll get a result for .17 [12:23] ok, that wasn't clear to me either (if I saw '0.3.17 (not tested)' or really any reference to 0.3.17, I would've tried that I think, but that is probably part of the bug you are referring to :) [12:23] thanks sil2100, that is totally enough - myself and coreycb just wnated to clarify if that is possible and what would have to be done - seems to be in the right hands now [12:24] sil2100, cpaelzer, thanks! [12:24] cpaelzer, coreycb: I'll see what we can do, I'll poke you later today once I know more ;) [12:24] jdstrand: I mean bug 1491145 [12:24] bug 1491145 in Auto Package Testing "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/1491145 [12:25] In the end we'd like to make bileto 'the tool' for any Ubuntu related landing, but yeah, we're still not there yet [12:25] * jdstrand nods [12:25] pitti: ok, retried. Thanks! :) [12:25] jdstrand: actually no, that's something different [12:26] pitti: I'm not sure how often this happens, but perhaps a FAQ entry in https://wiki.ubuntu.com/ProposedMigration would make sense? [12:28] jdstrand: sure (it hasn't come up by now) [12:35] cpaelzer: thanks for bug 1630963! I can trivially reproduce with a VM that didn't have the setup-testbed bits installed [12:35] bug 1630963 in autopkgtest (Ubuntu) "issues using user and password in adt-virt-qemu" [Undecided,New] https://launchpad.net/bugs/1630963 [12:36] cpaelzer: I still get a login failure though, looking into that now [12:39] pitti: I didn't get it complete either, but I tohught those easy steps would help you to fix it [12:39] cpaelzer: right; fixing was trivial, I just don't have automatic test cases for a VM without ttyS1 [12:40] cpaelzer: I'm getting a timeout on VirtSubproc.expect(term, b'\nlogout', 10) [12:40] i. e. --debug shows me it sent the password and the command, but it doesn't log out [12:40] cpaelzer: same for you? [12:40] * cpaelzer is rereading his console [12:41] timeout on VirtSubproc.expect(term, b'\nlogout', 10) [12:41] pitti: yes [12:41] great [12:43] LocutusOfBorg: nacc: sure I can upload [12:44] caribou, you can grab from my ppa the changes, but I think your patch was already good, since it is just a copy-paste [12:44] cpaelzer: oh, let me guess -- no passwordless sudo? [12:45] LocutusOfBorg: yeah, I got everything ready here, I was about to upload when nacc mentionned the other failures [12:45] cpaelzer: I'm going to teach it $SUDO_ASKPASS [12:45] I can't reproduce the failures, don't know === marcusto_ is now known as marcustomlinson [12:50] LocutusOfBorg: ok, uploaded along with clamav [12:52] yep saw it :) [12:53] doko_, what is this patch? http://launchpadlibrarian.net/254386710/llvm-toolchain-3.7_1%3A3.7.1-2ubuntu1_1%3A3.7.1-2ubuntu2.diff.gz [12:53] I don't see it applied on 3.8, neither forwarded in Debian === _salem is now known as salem_ [13:18] pitti: thanks for patching it so fast, but FYI even when making sudo pw-less in guest and host I still run into the timeout we both saw before [13:18] cpaelzer: yep, still debugging [13:18] cpaelzer: I think it fails earlier, I see a "Password:" prompt which is from login, not from sudo [13:19] cpaelzer: you can tell that this isn't the preferred/commonly used way to use VMs :) [13:19] ok, I let you do so - just read your closing comment as "without pw it should be good" [13:19] cpaelzer: no chance to get that root shell on ttyS1 on s390x? [13:20] i. e. what autopkgtest.service does [13:20] pitti: oh I think it could work, I just don't know how yet :-) [13:20] pitti: establishing the services you usually have for ttyS1 for hvc didn't work [13:21] although I could have had minor issues that didn't throw errors, yet still blocked it from working [13:24] pitti: I'll look at it once more and let you know if I get a root shell onto it [13:25] cpaelzer: I'm making progress, but seems automatically logging in is rather flaky on ttyS0 [13:56] pitti: I get closer step by step, it missed most of your setup-testbed in regard to consoles [13:56] pitti: I now have spawned a root-something on my hvc1 [13:57] and after a few issues I think I have that set up, running adt with that now [13:57] an "id" on that console gives me root, so one step further [13:59] did something change with today's dist-upgrade to cause gpg-agent not to run in the session? [14:00] barry: there was a race condition, fixed in https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu34 [14:00] barry: chances are that it's that [14:01] barry: still in -proposed, but feel free to grab that and test [14:01] pitti: ack, thanks [14:02] pitti: ok I'm over the login thing I think - only to hit "KVM_S390_MEM_OP failed: Cannot allocate memory" [14:02] pitti: I'll enable more debugging to see what command caused that [14:03] likely around: : failure: timed out on client shared directory setup [14:03] 9p supported at all there ? [14:04] cpaelzer: maybe not in the s390x version of qemu? [14:05] pitti: I'll ask people who know [14:05] 9p is supported in s390x [14:05] but it has different name [14:05] there one is :-) [14:05] 10p [14:05] only 2.7 qemu fixed to have aliases which are arch independant [14:05] cpaelzer: "10p"? /me isn't sure, joke or serious [14:06] must-p would be a joke in the sense of the container p-hole :-) [14:06] xnox: adt is currently adding "-virtfs local,id=autopkgtest,path=/tmp/autopkgtest-virt-qemu.84_ut07n/shared,security_model=none,mount_tag=autopkgtest" to qemu [14:06] xnox: do you have at hand what the alternative is or shall I check docs to puzzle that together [14:07] cpaelzer, that will not work, as -virtfs is not ported to use s390x device names [14:07] one needs to spell out things with -device. [14:07] I thought so [14:07] let me look it up for you. [14:07] if a more verbose syntax works on x86 too, happy to use that; otherwise we can add a hack to not use 9p at all, but then it'll be dog slow [14:08] pitti: the verbose syntax usually works usually everywhere arch-wise, but not back in time with some older versions [14:08] cpaelzer: >= trusty should be fine, that's where I backport it to [14:09] cpaelzer: ah, found out why the user/password login broke [14:09] apparently reading from the tty now reads one char at a time [14:09] meh, /me so doesn't want to implement his own line buffering [14:18] argh, that wasn't it even [14:29] pitti: yep, upstart's -proposed fixes it for me. thanks! i love being west of you :) [14:29] lol [14:29] xnox: the 9p changes worked - thanks [14:30] pitti: I updated bug 1630909 with the next stage that fails - if you have a pointer where I should look at let me know [14:30] bug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x" [Undecided,New] https://launchpad.net/bugs/1630909 [14:30] actually the title isn't so much console anymore given what fixes we already documented in that bug :-) [14:32] LocutusOfBorg: llvm-toolchain build failed : https://launchpad.net/ubuntu/+source/llvm-toolchain-3.6/1:3.6.2-3ubuntu3/+build/10997680/+files/buildlog_ubuntu-yakkety-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu3_BUILDING.txt.gz [14:34] trying to compile a cifs.ko module; the resulting module is 10x as big and refuses to load due to "format exec error". What am I doing wrong here? [14:38] cpaelzer: turns out this nut is a lot harder to crack than I thought (surprise) - I get awfully long timeouts and blocking on reading ttyS0, not sure why [14:38] cpaelzer: I'll keep looking at user/password login, but might take a bit [14:39] pitti, ttyS0 shouldn't exist. [14:39] xnox: I'm debugging on x86 :) [14:39] ah [14:39] =) [14:39] xnox: but yes, it should totally exist [14:40] on s390x.... there is only one console, and one must use -no-defaults to specify where one wants it to be redirected. very obscure. [14:44] xnox: so is the POP defining the machine [14:44] ? [14:44] xnox: that it has this kind of console [14:44] * xnox doesn't know what POP means. [14:44] Principles of Operation [14:44] source is from ubuntu linux-source-4.4.0-xxx package. Vermagic on original module is 4.4.0-38, new module has 4.4.19 [14:45] existing kernel won't load it. [14:45] in qemu s390x virtio-ccw machine type pre-defines a slcp console which one cannot modify using any command line option s=( [14:45] yeah because that is in "the definition" of the machine [14:45] xnox: still I couldn't agree more that it sucks in virtual and Linux centric world [14:47] to have such a console is an integral part of the architecture as defined - that is why it is in there IMO [14:47] xnox: pop at http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a [14:47] i'm fine with forcing slcp console, i'm not fine with not able to redirect that on to file/socket/dev/null on the hypervisor side of things [14:48] afterall, the virtual machine only knows that there is slcp, and shouldn't care where it is connected to on the host side. [14:48] xnox: I'd recommend to ask borntraeger and mihaijlov in ubuntu-s390x [14:48] so POP is fine, machine definition is fine, but qemu args are limited. [14:48] they are the right persons to do so [14:48] xnox: might be because it is line mode [14:48] which makes it "different" (tm) [14:49] it redirects just fine when i do -no-defaults, specify slcp by hand =) [14:49] i don't think it is line mode in qemu though. [14:49] it seems to be better than that. [14:49] ok, then the time is right to do so, really just catch borntraeger and mihajlov [14:49] cause e.g. qemu VM window has colours and can run emacs [14:49] I think this relation allows backward feature requests as well [14:50] i might just email qemu mailing list and enquire, and add them to CC [15:08] this is neat, I solved it, thanks. I fixed /lib/modules/version/build/Makefile and then recompiled my module with make -C /lib/modules/version/build/ M=$(pwd) [15:15] LocutusOfBorg: caribou: ack, thanks [15:15] smb: thanks! [15:15] LocutusOfBorg: slangasek was asking about moving away from llvm-3.6 in the foundation meeting minutes ago [15:16] LocutusOfBorg: in clamav I mean, you might not [15:20] caribou: ack, it's on server team's mind too -- presumably something we might want to pursue upstream? I can file an issue tracker, etc. [15:23] nacc: as LocutusOfBorg was saying yesterday, Debian is also transitioning to llvm-3.8 so it is an issue upstream as well [15:24] caribou: got it [15:24] caribou: tracked in llvm's issue tracker too? [15:25] nacc: don't know where to check [15:25] err, i meant clamav's [15:25] https://bugzilla.clamav.net/show_bug.cgi?id=11606 [15:25] bugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned] [15:26] nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839850 [15:26] Debian bug 839850 in src:clamav "clamav: FTBFS with LLVM 3.8" [Serious,Open] [15:26] caribou: ok, so those two combined :) [15:32] nacc: I like the upstream's comment "Please use './configure --enable-llvm=no' until this can be resolved." [15:33] caribou: pretty accurate ,but at least it's assigned to someone :) [15:39] jsalisbury: meh, I was hoping to grab a kernel from http://kernel.ubuntu.com/~jsalisbury/lp1627108/, but it's again gone after just 15 minutes :) [15:39] jsalisbury: (wanted to see if my bug report is a dupe or not) [15:40] pitti, sorry, I've been removing them after getting test results from om26er. I'll leave them around for others to test from now on :-) [15:40] pitti, I'll start putting them in sub directories, with the SAH1 as the name. [15:40] jsalisbury: cheers! I'll report on the bug once we have a "good" kernel [15:41] pitti, great, Thanks! [15:41] jsalisbury: I. e. I suppose I should start with testing a "good" one to even know if it's the same issue [15:42] pitti, good idea [15:42] pitti, I'll have the next kernel posted in 15 minutes or so [15:43] xnox, you mentioned earlier that s390x and armhf autopkgtests are run under LXD. did any other arch's switch to running under LXD recently as well? [15:44] doko_: xnox: slangasek: that's pretty much the latest status from upstream on clamav + llvm-3.8 : https://bugzilla.clamav.net/show_bug.cgi?id=11606 [15:44] bugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned] [15:44] coreycb: no, i386, amd64, and ppc64el run in OpenStack VMs (i. e. ~ qemu) [15:44] pitti, ok, thanks [15:44] LocutusOfBorg: can't remember, maybe didn't work with gold? [15:56] pitti: you're not gonna like this, but starting u-s-d with upstart seems to fix the problem. i'll attach some details to the bug in a sec... but assuming this is a workable fix, are you open to switching u-s-d back to upstart for yakkety (at least at release) since yakkety still has the upstart user session anyway? [15:57] jderose: nice discovery [15:57] jderose: well, that is "unexpected" and thus an interesting handle to debug [15:57] pitti: mostly a lucky guess i think :) thanks for all the pointers [15:57] jderose: might be a bit hard to properly order it against the other unity bits [15:58] pitti: ah, okay. so are there other things that will only interact with u-s-d correctly when it's started with systemd? [15:59] jderose: no, I just figure it's a side effect of the dbus user session somehow; I think when run with upstart it runs in the logind scope (and thus "session") while as a systemd service it runs outside [15:59] jderose: wrt. ordering: unity apparently wants to start after u-s-d [16:00] pitti: ah, okay. i haven't yet tried with systemd but without dbus-user-session. on that note, how difficult is it to undo the dbus-user-session stuff? not even knowing the details dbus-user-session, that sounds like a lot of work :D [16:00] jderose: which can be expressed if both run from upstart or both frmo systemd, but not with one here, one there [16:00] pitti: hmm, is this ordering problem easy to reproduce? things seem to work okay in the quick test i just did, but that's not a big sample size [16:00] jderose: can't work [16:01] okay, that makes sense [16:01] jderose: yeah, I guess it's not crucial, I figure it avoids flickering if u-s-d changes the theme while unity is already running, or something similar [16:01] jderose: so this still sounds like some polkit problem to me, that pkexec from within a session does soemthing else than from outside [16:01] pitti: okay, so it's not as bad as unity not starting at all or something like that, more just a UX issues? [16:02] jderose: right; good enough for local testing for sure, just not something I'd like to ship [16:02] pitti: is it still helpful for me to try it started under systemd, but purging dbus-user-session? [16:02] jderose: that was the "can't work" bit [16:02] right... but is it a useful hint possibly? [16:03] jderose: you can run dbus-user-session with upstart, but not "no user session" with systemd [16:03] jderose: yes, it's absolutely an useful hint [16:03] ah, okay, now it's making more sense i think [16:03] jderose: need to be off for a few hours for dinner and some family time, back in ~ 3 hours [16:04]