/srv/irclogs.ubuntu.com/2016/10/06/#ubuntu-devel.txt

slangasek        // TODO:: fix alignment of src!00:23
slangasekyathink00:23
rbasakarmhf and alignment? :)00:25
rbasakI dealt with those in the past, but I got the impression our newer armhf kernels had traps to magically handle that.00:25
rbasakAt least, the same failures I saw in the past stopped happening.00:26
slangasekrbasak: 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 same00:28
rbasakAh, that makes sense.00:31
rbasakDoes /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
rbasak(well, "fix" it)00:33
tsimonq2bug 1556599 looks *fun*00:40
ubottubug 1556599 in kubuntu-meta (Ubuntu) "ISO images don't have valid partition tables" [Undecided,New] https://launchpad.net/bugs/155659900:40
slangasekrbasak: yeah, no /proc/cpu/alignment at least on porter-arm6400:46
slangasektsimonq2: 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 here00:49
tsimonq2slangasek: yeah, I was thinking PEBKAC00:49
tsimonq2hmm, 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 that01:30
tsimonq2(anybody familiar with that that has a half an hour to spare ;) )01:31
cyphermoxtsimonq2: just ask your question ;)02:02
tsimonq2oh yeah I should do that02:03
tsimonq2:P02:03
* tsimonq2 slips Lubuntu hat on02:03
tsimonq2let me find this bug...02:05
tsimonq2bug 151645402:05
ubottubug 1516454 in gnumeric (Ubuntu) "gnumeric menu ->help ->about gnumeric -> license button, does not work." [Low,Confirmed] https://launchpad.net/bugs/151645402:05
tsimonq2shouldn't it be as simple as mapping the button to the correct spot?02:05
sarnoldare any errors printed to stderr? or xsession errors?02:07
tsimonq2let me fire up my Lubuntu VM here...02:07
sarnoldyou might get lucky and see an error message with the exact cause :)02:07
tsimonq2good idea sarnold02:08
tsimonq2it's been a Lubuntu bug for a while now and it seems trivial enough02:08
sarnoldI 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:09
tsimonq2the only error-looking output that I don't know what it is is an error about not being able to connect to the Accessbility bus02:10
tsimonq2which I don't think would cause that?02:10
sarnoldprobably not02:10
tsimonq2if it was written in Qt, I'd be able to use Qt Creator's awesome little tools to figure it out02:12
tsimonq2but unfortunately it doesn't seem like there's anything like that for GTK02:12
tsimonq2the question is, where do I start?02:14
cyphermoxI'd look at the source code for where that button is defined02:17
tsimonq2ok02:18
cyphermoxusually what I do is rgrep through the source for keywords I'm looking for ("License" in this case), to have somewhere to start with02:18
tsimonq2what's the difference between grep and rgrep?02:18
cyphermoxrgrep is grep -r02:18
tsimonq2oh ok02:18
sarnoldmy 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:18
cyphermoxno, doesn't appear to be02:19
sarnoldbut I did giggle at "comments", _("Free, Fast, Accurate - Pick Any Three!"),02:19
cyphermoxI wonder if you're not seeing the about dialog rendering the contributors animation as a button02:19
sarnoldthe screenshot -really- looks like it's supposed to be a clickable button. heh.02:20
cyphermoxoh indeed02:21
cyphermoxbut also, oh, that looks like magic about dialog magic.02:21
tsimonq2seems like there's no definition for that in the code...02:21
tsimonq2I also need to update the bug to include the fact that Credits doesn't work either02:22
cyphermoxI bet GTK_TYPE_ABOUT_DIALOG does this automatically in some cases02:22
cyphermoxyep, that's deep in gtk02:24
sarnoldcyphermox: ha! that l9ooks like it02:24
sarnold"You can specify license information with the “license” property " https://developer.gnome.org/gtk2/stable/gtk-migrating-GtkAboutDialog.html02:25
tsimonq2so it might be a GTK bug?02:26
sarnoldwell02:27
sarnoldThey Probably Hoped[tm] that authors would set the properties and thus make the buttons useful02:27
cyphermoxtsimonq2: 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 object02:27
cyphermoxright02:27
cyphermoxit's not a GTK bug, but a property missing in gnumeric. as you mentioned, very straightforward to fix02:28
sarnoldyou could bicker and argue about whether itt's a good idea to show the buttons if the properties aren't set...02:28
tsimonq2ok, thanks guys for guiding me in the right direction :)02:28
cyphermoxsarnold: well, yeah, I suppose ;)02:33
cyphermoxtsimonq2: so the fix is a one-liner02:34
tsimonq2\o/02:34
sarnolddunno, I found GPL2 and GPL3 ilcense files there, that's a very long line :)02:34
cyphermoxsarnold: no02:34
cyphermoxyou can set it with a property which takes an enum ;)02:35
sarnoldoh! I got distracted by the mention of the type of dialog box it would show and their recommendation to use paragraphs02:35
cyphermoxright; I think it would suffice to set license_type; and from there things would work and be correct02:36
cyphermoxGnumeric says GPL2 or 3 at your choice, that reads to me as GPL2+02:36
tsimonq2so I might need a license property?02:39
cyphermoxI think it ought to be license_type02:39
tsimonq2I 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 obvious02:39
cyphermoxtsimonq2: yep02:40
cyphermoxtsimonq2: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license might help02:40
cyphermoxmy opinion would be to give you a chance to fix it yourself, and thus claim an upload (I'll be happy to sponsor)02:41
tsimonq2awesome, thanks :)02:42
tsimonq2cyphermox, 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
tsimonq2or even GPL-2+?02:50
sarnoldtsimonq2: I haven't studied it closely but GPL-2+ feels like a likely fit02:51
tsimonq2ok I'll assume that for the time being02:52
sarnoldtsimonq2: it might not hurt to check upstream gnumeric repo and see if they've already addressed it02:52
naccLocutusOfBorg: are you planning on uploading the fix for llvm-toolchain-3.6?02:52
tsimonq2sarnold: good stuff02:52
tsimonq2ok02:52
sarnoldtsimonq2: "cherrypick checkin ..." is a lot easier to review than new code :)02:53
tsimonq2+102:54
tsimonq2hmmm, seems like it's *not* upstream02:56
sarnoldamazing how a tiny thing turns into a medium thing quickly :)02:56
tsimonq2hmm, DuckDuckGo didn't return anything, so does this look right to you guys? http://paste.ubuntu.com/23282692/03:03
tsimonq2multi-line GTK properties03:03
sarnoldtsimonq2: it's probably better to set the license-type property isntead: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license-type03:04
sarnoldhttps://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkLicense03:05
tsimonq2ok got it03:05
tsimonq2sarnold, cyphermox: that didn't work :(03:17
tsimonq2and I should really go to bed03:18
tsimonq2good night everyone o/03:18
sarnoldgoodnight tsimonq2 :)03:21
pittiGood morning04:38
cpaelzergood morning05:49
LocutusOfBorgnacc, I can't, I'm not a core-dev, just let caribou upload it06:27
smbnacc, Thanks, I will have a look at the shutdown script issue06:54
Mirvdoko_: 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 for07:10
Mirvyakkety of course.07:10
Mirv(I'm sad that the search url there doesn't give any more entries of potential Qt side fixes)07:12
mardyMirv: do I understand correctly, that this is QML issue does not only affect tests, but also real apps?07:49
Mirvmardy: 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.07:52
mardyMirv: should we temporarily disable arm64 tests, or do you have some other tricks in the sleeve?08:11
cpaelzerpitti: 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:31
cpaelzerpitti: 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
pitticpaelzer: how did you create the image? you should normally use autopkgtest-buildvm-ubuntu-cloud for it08:32
cpaelzerpitti: 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
pitticpaelzer: 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 start08:32
pitticpaelzer: (-s can take something like "10G")08:33
pitticpaelzer: if you boot it in kvm with -serial stdio, do you see the boot messages and can log in?08:34
cpaelzerI didn't add any serial on my last try, the defaults worked08:34
cpaelzerlet me add -serial stdio08:34
cpaelzer-serial stdio fails as the default sclp console already grabbed stdio08:35
cpaelzershould I disable sclp08:35
cpaelzeror is that it boots just fine via sclp console proof enough?08:36
cpaelzerpitti: ^^08:36
pitticpaelzer: I don't know what sclp is08:36
pitticpaelzer: but if ttyS0 doesn't work for the console, then autopkgtest won't work with it08:36
cpaelzerit is "their" native console protocol08:37
cpaelzerand thereby what you get when you do nothing08:38
pitticpaelzer: 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 that08:39
cpaelzerpitti: the default console is sclp which is a line mode console, using -nographic that already is connected to stdio and working fine08:48
cpaelzerpitti: 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-char08:48
cpaelzerpitti: I'm not sure what that implies for the ttyS0 you need for autopkgtest08:48
pitticpaelzer: what it does is it connects to ttyS0 and waits for a "login: " prompt08:49
pitticpaelzer: 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 options08:50
pitticpaelzer: 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 -r08:50
cpaelzerpitti: yeah I agree, so that is what you do via the -serial unix:/tmp/autopkg... then right?08:51
pitticpaelzer: 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
pittiright08:51
cpaelzerI'll add one on my own and see if/what spawns there08:51
Mirvmardy: 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 hardware09:05
cpaelzerpitti: without further tweaking nothing seems to spawn on those extra consoles (and no /dev/tty* entries created)09:10
cpaelzerpitti: 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:10
pitticpaelzer: 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 env09:11
* pitti is still amazed how different everything is with s390x :)09:11
cpaelzerpitti: I'll dump and I'm sure xnox can give you access to some in instance your team if you need/want09:11
Mirvok collected the arm64 issue facts to bug #163090609:14
ubottubug 1630906 in ubuntu-push-qml (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/163090609:14
Mirvcjwatson: oSoMoN: doko_: bug #1630906 has the collected failures, happens on vivid + xenial + yakkety09:21
ubottubug 1630906 in webbrowser-app (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/163090609:21
oSoMoNthanks Mirv. LP times out when I want to mark myself affected :/09:23
pittixnox: can you please push your upstart commits to bzr? or want me to grab the diff from LP:10:00
pitti?10:00
pittixnox: I pushed it now10:15
=== alan_g_ is now known as alan_g
doko_caribou: please take this for Debian too: https://launchpad.net/ubuntu/+source/makedumpfile/1:1.6.0-2ubuntu110:48
cariboudoko_: ok, will do11:04
cpaelzerpitti: 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:06
cpaelzerpitti: I wonder if unblocking these just gets to the next hurdle or if it would run fine then11:07
xnoxpitti, i have them locally, did not upload upstart to the archive yet, hence did not push.....11:08
xnoxpitti, my question is who uploaded things =)11:09
pittixnox: 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 top11:10
xnoxcool, thanks.11:10
pitticpaelzer: 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 with11:10
cpaelzerpitti: ok, looking at virt/autopkgtest-virt-qemu atm11:11
xnoxsil2100, 2016-10-06 08:45:17 +0100 (sil2100) Publishing packages.11:12
xnoxit would be nice not to land my stuff for me =)11:12
xnoxsil2100, especially without autopkgtest results.11:13
xnoxanyway, it's superseeded now. so doesn't really matter at all.11:13
=== hikiko is now known as hikiko|ln
=== highvolt1ge is now known as highvoltage
sil2100xnox: ah, right, the yakkety one - yeah, sorry, prematurely published that one11:52
sil2100We wanted the xenial one badly and it was ok, so I insta-published the yakkety one without checking if all autopkgtests ran11:52
sil2100xnox: but the xenial one was fine, everything passed and was green11:53
xnoxsil2100, i thought you will copy xenial ppa into xenial overlay ppa (using copy-package, not release)11:53
xnoxbecause xenial one is now stuck in SRU queue, and will be probably rejected there (as there is no bug # reference)11:54
sil2100I did do a copy-package to the overlay, but I thought you wanted to have that released in xenial-updates too?11:54
xnoxexcellent then =)11:54
xnoxyeah, i do want it in xenial-updates, eventually11:54
sil2100My 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
sil2100Sorry for the issues anyway11:55
xnoxdesparate times, need desparate measures =)11:56
* xnox is struggling to escape from this island at the moment11:56
=== marcusto_ is now known as marcustomlinson
=== hikiko|ln is now known as hikiko
coreycbsil2100, 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:08
cjwatsonI thought that happened ages ago12:09
jbichaI 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 for12:09
jbicharobru or someone had to add to me to the access list since ~ubuntu-dev don't have rights to bileto by default12:11
cpaelzerinteresting, the create new tickets fails with a 401 instantly for me12:12
cjwatsonyou may just need to be added to bileto-users12:12
cjwatsonjbicha: bileto does archive.checkUpload in LP, so it should honour the usual permissions12:13
cpaelzeryeah, do requests to get added to bileto-users have a defined process a.k.a who should I bother?12:13
cjwatsonI guess sil2100 or robru could answer that12:15
sil2100Yeah, I can do that12:16
cpaelzersil2100: https://launchpad.net/~paelzer that would be me12:17
sil2100Yeah, the tricky part is... there is no fine grained ACL for bileto right now12:17
jdstrandpitti: hi! yesterday I uploaded click-apparmor 0.3.17 to fix an autopkgtest failure and it migrated (yay)12:17
cpaelzersil2100: to understand is that just membership of the normal LP group at https://launchpad.net/~bileto-users ?12:17
sil2100cpaelzer: yeah12:17
pittijdstrand: nice!12:17
cpaelzersil2100: that was the discussion before - is the ACL good enough to - once being member of the bileto-users - only push packages you are supposed to12:18
jdstrandpitti: apparmor-easyprof-ubuntu got hung up on click-apparmor 0.3.15 and 0.3.15 failures (boo :)12:18
cpaelzersil2100: and cjwatson referenced that it calls archive..checkUpload12:18
jdstrandpitti: 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 happen12:18
sil2100cpaelzer: yeah,  basically for the publish step that's true, but there is a problem elsewhere12:18
pittijdstrand: maybe you retried before 0.3.16 was published?12:19
jdstrandpitti: can you look at update_excuses.html and advise?12:19
pittijdstrand: I'd just try it again12:19
sil2100cpaelzer: 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 own12:19
jdstrandpitti: 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 it12:20
pittijdstrand: 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.1612:20
jdstrands/which took a while/which took a while to get fixed/12:20
pittijdstrand: yeah, we don't auto-retry failed tests12:20
jdstrandah12:20
jdstrandok, so that explains it12:20
sil2100cpaelzer: 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 landings12:20
pittijdstrand: I have a bug about that, but right now that doesn't happen12:20
jdstrandpitti: so, what should I do to get it migrating?12:20
pittijdstrand: just retry the test12:21
sil2100cpaelzer: will bring this up a few people and will get back to you if we can do something here12:21
sil2100*bring this up with a few12:21
jdstrandpitti: 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 versions12:21
pittijdstrand: the queue is currently veeeery long (glibc update), but I'll cut that off in a few hours12:21
pittijdstrand: retry the click-apparmor ones for a-e-u (i. e. the failing ones), that's the right thing12:22
jdstrandautopkgtest for click-apparmor/0.3.16: amd64: Regression12:22
pittijdstrand: a retry will always run against the latest version of the package (it doesn't have any other choice anyway :) )12:22
jdstrandretry that one ^12:22
pitticorrect12:22
jdstrand(and the other two?12:22
jdstrandok, thanks!12:22
pittijdstrand: so on a re-run you'll get a result for .1712:22
jdstrandok, 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
cpaelzerthanks 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 now12:23
coreycbsil2100, cpaelzer, thanks!12:24
sil2100cpaelzer, coreycb: I'll see what we can do, I'll poke you later today once I know more ;)12:24
pittijdstrand: I mean bug 149114512:24
ubottubug 1491145 in Auto Package Testing "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/149114512:24
sil2100In the end we'd like to make bileto 'the tool' for any Ubuntu related landing, but yeah, we're still not there yet12:25
* jdstrand nods12:25
jdstrandpitti: ok, retried. Thanks! :)12:25
pittijdstrand: actually no, that's something different12:25
jdstrandpitti: I'm not sure how often this happens, but perhaps a FAQ entry in https://wiki.ubuntu.com/ProposedMigration would make sense?12:26
pittijdstrand: sure (it hasn't come up by now)12:28
pitticpaelzer: thanks for bug 1630963! I can trivially reproduce with a VM that didn't have the setup-testbed bits installed12:35
ubottubug 1630963 in autopkgtest (Ubuntu) "issues using user and password in adt-virt-qemu" [Undecided,New] https://launchpad.net/bugs/163096312:35
pitticpaelzer: I still get a login failure though, looking into that now12:36
cpaelzerpitti: I didn't get it complete either, but I tohught those easy steps would help you to fix it12:39
pitticpaelzer: right; fixing was trivial, I just don't have automatic test cases for a VM without ttyS112:39
pitticpaelzer: I'm getting a timeout on VirtSubproc.expect(term, b'\nlogout', 10)12:40
pittii. e. --debug shows me it sent the password and the command, but it doesn't log out12:40
pitticpaelzer: same for you?12:40
* cpaelzer is rereading his console12:40
cpaelzertimeout on    VirtSubproc.expect(term, b'\nlogout', 10)12:41
cpaelzerpitti: yes12:41
pittigreat12:41
caribouLocutusOfBorg: nacc: sure I can upload12:43
LocutusOfBorgcaribou, you can grab from my ppa the changes, but I think your patch was already good, since it is just a copy-paste12:44
pitticpaelzer: oh, let me guess -- no passwordless sudo?12:44
caribouLocutusOfBorg: yeah, I got everything ready here, I was about to upload when nacc mentionned the other failures12:45
pitticpaelzer: I'm going to teach it $SUDO_ASKPASS12:45
LocutusOfBorgI can't reproduce the failures, don't know12:45
=== marcusto_ is now known as marcustomlinson
caribouLocutusOfBorg: ok, uploaded along with clamav12:50
LocutusOfBorgyep saw it :)12:52
LocutusOfBorgdoko_, what is this patch? http://launchpadlibrarian.net/254386710/llvm-toolchain-3.7_1%3A3.7.1-2ubuntu1_1%3A3.7.1-2ubuntu2.diff.gz12:53
LocutusOfBorgI don't see it applied on 3.8, neither forwarded in Debian12:53
=== _salem is now known as salem_
cpaelzerpitti: 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 before13:18
pitticpaelzer: yep, still debugging13:18
pitticpaelzer: I think it fails earlier, I see a "Password:" prompt which is from login, not from sudo13:18
pitticpaelzer: you can tell that this isn't the preferred/commonly used way to use VMs :)13:19
cpaelzerok, I let you do so - just read your closing comment as "without pw it should be good"13:19
pitticpaelzer: no chance to get that root shell on ttyS1 on s390x?13:19
pittii. e. what autopkgtest.service does13:20
cpaelzerpitti: oh I think it could work, I just don't know how yet :-)13:20
cpaelzerpitti: establishing the services you usually have for ttyS1 for hvc didn't work13:20
cpaelzeralthough I could have had minor issues that didn't throw errors, yet still blocked it from working13:21
cpaelzerpitti: I'll look at it once more and let you know if I get a root shell onto it13:24
pitticpaelzer: I'm making progress, but seems automatically logging in is rather flaky on ttyS013:25
cpaelzerpitti: I get closer step by step, it missed most of your setup-testbed in regard to consoles13:56
cpaelzerpitti: I now have spawned a root-something on my hvc113:56
cpaelzerand after a few issues I think I have that set up, running adt with that now13:57
cpaelzeran "id" on that console gives me root, so one step further13:57
barrydid something change with today's dist-upgrade to cause gpg-agent not to run in the session?13:59
pittibarry: there was a race condition, fixed in https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu3414:00
pittibarry: chances are that it's that14:00
pittibarry: still in -proposed, but feel free to grab that and test14:01
barrypitti: ack, thanks14:01
cpaelzerpitti: ok I'm over the login thing I think - only to hit "KVM_S390_MEM_OP failed: Cannot allocate memory"14:02
cpaelzerpitti: I'll enable more debugging to see what command caused that14:02
cpaelzerlikely around: <VirtSubproc>: failure: timed out on client shared directory setup14:03
cpaelzer9p supported at all there ?14:03
pitticpaelzer: maybe not in the s390x version of qemu?14:04
cpaelzerpitti: I'll ask people who know14:05
xnox9p is supported in s390x14:05
xnoxbut it has different name14:05
cpaelzerthere one is :-)14:05
cpaelzer10p14:05
xnoxonly 2.7 qemu fixed to have aliases which are arch independant14:05
pitticpaelzer: "10p"? /me isn't sure, joke or serious14:05
cpaelzermust-p would be a joke in the sense of the container p-hole :-)14:06
cpaelzerxnox: adt is currently adding "-virtfs local,id=autopkgtest,path=/tmp/autopkgtest-virt-qemu.84_ut07n/shared,security_model=none,mount_tag=autopkgtest" to qemu14:06
cpaelzerxnox: do you have at hand what the alternative is or shall I check docs to puzzle that together14:06
xnoxcpaelzer, that will not work, as -virtfs is not ported to use s390x device names14:07
xnoxone needs to spell out things with -device.14:07
cpaelzerI thought so14:07
xnoxlet me look it up for you.14:07
pittiif 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 slow14:07
cpaelzerpitti: the verbose syntax usually works usually everywhere arch-wise, but not back in time with some older versions14:08
pitticpaelzer: >= trusty should be fine, that's where I backport it to14:08
pitticpaelzer: ah, found out why the user/password login broke14:09
pittiapparently reading from the tty now reads one char at a time14:09
pittimeh, /me so doesn't want to implement his own line buffering14:09
pittiargh, that wasn't it even14:18
barrypitti: yep, upstart's -proposed fixes it for me.  thanks!  i love being west of you :)14:29
pittilol14:29
cpaelzerxnox: the 9p changes worked - thanks14:29
cpaelzerpitti: I updated bug 1630909 with the next stage that fails - if you have a pointer where I should look at let me know14:30
ubottubug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x" [Undecided,New] https://launchpad.net/bugs/163090914:30
cpaelzeractually the title isn't so much console anymore given what fixes we already documented in that bug :-)14:30
caribouLocutusOfBorg: 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.gz14:32
john_strying 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:34
pitticpaelzer: 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 why14:38
pitticpaelzer: I'll keep looking at user/password login, but might take a bit14:38
xnoxpitti, ttyS0 shouldn't exist.14:39
pittixnox: I'm debugging on x86 :)14:39
xnoxah14:39
xnox=)14:39
pittixnox: but yes, it should totally exist14:39
xnoxon s390x.... there is only one console, and one must use -no-defaults to specify where one wants it to be redirected. very obscure.14:40
cpaelzerxnox: so is the POP defining the machine14:44
xnox?14:44
cpaelzerxnox: that it has this kind of console14:44
* xnox doesn't know what POP means.14:44
cpaelzerPrinciples of Operation14:44
john_ssource is from ubuntu linux-source-4.4.0-xxx package. Vermagic on original module is 4.4.0-38, new module has 4.4.1914:44
john_sexisting kernel won't load it.14:45
xnoxin qemu s390x virtio-ccw machine type pre-defines a slcp console which one cannot modify using any command line option s=(14:45
cpaelzeryeah because that is in "the definition" of the machine14:45
cpaelzerxnox: still I couldn't agree more that it sucks in  virtual and Linux centric world14:45
cpaelzerto have such a console is an integral part of the architecture as defined - that is why it is in there IMO14:47
cpaelzerxnox: pop at http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a14:47
xnoxi'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 things14:47
xnoxafterall, the virtual machine only knows that there is slcp, and shouldn't care where it is connected to on the host side.14:48
cpaelzerxnox: I'd recommend to ask borntraeger and mihaijlov in ubuntu-s390x14:48
xnoxso POP is fine, machine definition is fine, but qemu args are limited.14:48
cpaelzerthey are the right persons to do so14:48
cpaelzerxnox: might be because it is line mode14:48
cpaelzerwhich makes it "different" (tm)14:48
xnoxit redirects just fine when i do -no-defaults, specify slcp by hand =)14:49
xnoxi don't think it is line mode in qemu though.14:49
xnoxit seems to be better than that.14:49
cpaelzerok, then the time is right to do so, really just catch borntraeger and mihajlov14:49
xnoxcause e.g. qemu VM window has colours and can run emacs14:49
cpaelzerI think this relation allows backward feature requests as well14:49
xnoxi might just email qemu mailing list and enquire, and add them to CC14:50
john_sthis 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:08
naccLocutusOfBorg: caribou: ack, thanks15:15
naccsmb: thanks!15:15
caribouLocutusOfBorg: slangasek was asking about moving away from llvm-3.6 in the foundation meeting minutes ago15:15
caribouLocutusOfBorg: in clamav I mean, you might not15:16
nacccaribou: 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:20
caribounacc: as LocutusOfBorg was saying yesterday, Debian is also transitioning to llvm-3.8 so it is an issue upstream as well15:23
nacccaribou: got it15:24
nacccaribou: tracked in llvm's issue tracker too?15:24
caribounacc: don't know where to check15:25
naccerr, i meant clamav's15:25
nacchttps://bugzilla.clamav.net/show_bug.cgi?id=1160615:25
ubottubugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned]15:25
caribounacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=83985015:26
ubottuDebian bug 839850 in src:clamav "clamav: FTBFS with LLVM 3.8" [Serious,Open]15:26
nacccaribou: ok, so those two combined :)15:26
caribounacc: I like the upstream's comment "Please use './configure --enable-llvm=no' until this can be resolved."15:32
nacccaribou: pretty accurate ,but at least it's assigned to someone :)15:33
pittijsalisbury: 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
pittijsalisbury: (wanted to see if my bug report is a dupe or not)15:39
jsalisburypitti, 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
jsalisburypitti, I'll start putting them in sub directories, with the SAH1 as the name.15:40
pittijsalisbury: cheers! I'll report on the bug once we have a "good" kernel15:40
jsalisburypitti, great, Thanks!15:41
pittijsalisbury: I. e. I suppose I should start with testing a "good" one to even know if it's the same issue15:41
jsalisburypitti, good idea15:42
jsalisburypitti, I'll have the next kernel posted in 15 minutes or so15:42
coreycbxnox, 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:43
cariboudoko_: xnox: slangasek: that's pretty much the latest status from upstream on clamav + llvm-3.8 : https://bugzilla.clamav.net/show_bug.cgi?id=1160615:44
ubottubugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned]15:44
pitticoreycb: no, i386, amd64, and ppc64el run in OpenStack VMs (i. e. ~ qemu)15:44
coreycbpitti, ok, thanks15:44
doko_LocutusOfBorg: can't remember, maybe didn't work with gold?15:44
jderosepitti: 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:56
pittijderose: nice discovery15:57
pittijderose: well, that is "unexpected" and thus an interesting handle to debug15:57
jderosepitti: mostly a lucky guess i think :) thanks for all the pointers15:57
pittijderose: might be a bit hard to properly order it against the other unity bits15:57
jderosepitti: ah, okay. so are  there other things that will only interact with u-s-d correctly when it's started with systemd?15:58
pittijderose: 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 outside15:59
pittijderose: wrt. ordering: unity apparently wants to start after u-s-d15:59
jderosepitti: 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 :D16:00
pittijderose: which can be expressed if both run from upstart or both frmo systemd, but not with one here, one there16:00
jderosepitti: 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 size16:00
pittijderose: can't work16:00
jderoseokay, that makes sense16:01
pittijderose: 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 similar16:01
pittijderose: so this still sounds like some polkit problem to me, that pkexec from within a session does soemthing else than from outside16:01
jderosepitti: okay, so it's not as bad as unity not starting at all or something like that, more just a UX issues?16:01
pittijderose: right; good enough for local testing for sure, just not something I'd like to ship16:02
jderosepitti: is it still helpful for me to try it started under systemd, but purging dbus-user-session?16:02
pittijderose: that was the "can't work" bit16:02
jderoseright... but is it a useful hint possibly?16:02
pittijderose: you can run dbus-user-session with upstart, but not "no user session" with systemd16:03
pittijderose: yes, it's absolutely an useful hint16:03
jderoseah, okay, now it's making more sense i think16:03
pittijderose: need to be off for a few hours for dinner and some family time, back in ~ 3 hours16:03
jderosepitti: k, enjoy. thanks again for the help!16:04
pittijderose: please leave a note in the bug as a reminder?16:04
jderosepitti: yup, will do16:05
pittijderose: thanks for the experiments!16:05
pittiunexpected results are always helpful :)16:05
LocutusOfBorgdoko_, I still don't get why you didn't fix llvm 3.8, and if the change needs to be propagated in Debian too16:06
doko_LocutusOfBorg: using cmake ...16:33
jderosepitti: another very interesting hint. seems like a bunch O stuff is getting restarted (or "re-triggered"?) every time you press a hotkey - https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/comments/2017:04
ubottuLaunchpad bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged]17:04
=== alexisb is now known as alexisb-afk
=== fginther` is now known as fginther
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
pittijderose: yes, that's why it's so slow -- every pkexec runs a full PAM session which includes a systemd --user; in xenial that didn't really do anything, but now we actually do have a bunch of user services19:11
pittijderose: which is why I proposed to use common-session-noninteractive, as it avoids all that overhead19:12
jderosepitti: yeah, sorry, i don't think that comment was very helpful in the end, still learning19:12
pittijderose: no worries :)19:13
pittijderose: I'm glad someone else starts to understand it too :)19:13
pittijderose: need to do some glibc handholding and then look into that19:13
jderosepitti: so i've been experimenting with common-session-noninteractive. it still seems perhaps i bit more expensive than when i start usd under upstart, but it's totally workable, just a small regression if any19:13
pittijderose: right, that would be the obvious (from my POV) fix; but it doesn't explain why it would be fast to run pkexec in the session instaed of from the user bus, hence my surprise19:14
jderosepitti: okay. one quick thing if you have a moment: why is including @common-session so much more expensive on yakkety than xenial? looking at /etc/pam.d/pollkit-1, it seems the same19:15
jderoseor, maybe that's what you just said above19:15
pittijderose: because pam_systemd now has a lot more things to do19:15
pittiwell, that would be by first guess19:15
pittiquite obviously I don't understand the full picture yet19:16
Unit193pitti: fwiw, tried usrmerge, but not in an encrypted install yet. :P19:16
jderosepitti: well, that makes me fell a little better because i *really* don't understand the full picture yet :)19:16
jderosepitti: if i go looking for packages that might get broken by "common-session-noninteractive", what exactly am i looking for? i'm not sure i understand the difference from the perspective of a pkexec consumer19:19
pittijderose: mostly between "is this more like running a new session (like su -) or just running a program in the same session but with different (root) privs19:20
pittijderose: interactive sessions get their own systemd --user, XDG_RUNTIME_DIR, pam_limits etc.19:20
jderosepitti: and by "session" you mean pam session?19:20
pittiyes, PAM specifically but also conceptually19:20
pittilike "is this like another user logging in" or more like a setuid root thing19:21
pittithe backlight helper is clearly the "suid root" category19:21
pittiand I suspect the same for most other users of pkexec19:21
jderoseyeah, i can't think of anything that doesn't fit that model... but there certainly could be19:21
pittiI was wondering if there is anything using pkexec that shoudl rather use something like "su -" or gksu19:21
=== alexisb-afk is now known as alexisb
pittijderose: wow, there are now millions of uevents like KERNEL[2471.462232] add      /kernel/slab/inode_cache/cgroup/inode_cache(4399:user@0.service) (cgroup)19:38
pittijderose: that rather smells like kernel 4.8 fallout, possibly related to bug 1626436 / bug 162710819:38
ubottubug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/162643619:38
ubottubug 1627108 in linux (Ubuntu Yakkety) "X1Carbon comes to a crawl during high CPU usage tasks" [High,In progress] https://launchpad.net/bugs/162710819:38
pittijderose: so testing under kernel 4.4 is another useful data point19:38
jderosepitti: okay, okay. so this is something that has made the bug worse since cking filed it then?19:39
pittijderose: I can explain the lot of usd-backlight-helper and systemd --user forkstats, but not why there are so many uevents and thus udevd workers, as that's all entirely system side (session doesn't have the privileges to trigger uevents)19:40
jderosepitti: how are your observing these events?19:41
pittijderose: udevadm monitor -e --udev19:41
pittipkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness8019:41
pittinow booting 4.4 to compare19:41
pittijderose: confirmed; 4.4 now, and zero uevents19:44
jderosepitti: so with 4.4, are the brightness keys noticeably slower still than on xenial?19:44
pittijderose: still feels like an 0.1 or 0.2 s delay, so I think yes19:45
pittinot bad enough to actually feel slow, but it's not instant reaction19:45
jderosepitti: but more or less workable? because i know with 4.8 right now, it's pretty darn bad :)19:45
pittiI don't have x here to compare19:45
pittijderose: right, but 4.8's boot speed is pretty darn bad too :)19:46
jderoseyeah19:46
pitti15 s vs. 1.5 with 4.419:46
pittiand I have a feeling this is related19:46
pittiif the creation of every new cgroup causes 3 uevents, then every service that starts up at boot will also cause tons of uevents19:46
pittiwhich might explain the boot speed regression and high loads19:46
pittijsalisbury: ^ does that ring a bell?19:47
pittihttps://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/comments/2119:49
ubottuLaunchpad bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged]19:50
jderosepitti: is there a reason starting unity-settings-daemon under upstart would prevent usd from being effected by these extra uevents?19:51
pittijderose: going to look at that next19:51
pittiwe only explained the uevent/udev bits so far19:51
jsalisburypitti, it doesn't ring a bell off hand, but sounds like something to look into.19:52
jderosepitti: also, please don't let me keep you from your glibc work :)19:52
pittijderose: just landing that, all good19:52
pittijsalisbury: it's at least plausible that genreating lots of uevents around cgroup creation would cause slower boot speed19:54
pittijderose: will poke for a bit and leave notes in the bug; impractical to re-join IRC between each session restart/reboot, and night anyway, so TTY tomorrow19:56
jderosepitti: with "common-session" and starting u-s-d with upstart, i'm still seeing as many uevents under 4.8... but it's crazy fast now, i'd say basically the same as X19:57
pittijderose: did you actually only start u-s-d under upstart, or the entire session?19:58
jderosepitti: er, when i comment out the systemd bits in /etc/X11/Xsession.d/00upstart... does that mean there's no systemd user session at all?19:58
pittijderose: correct19:58
jderoseokay, so that's what i did :)19:59
pittijderose: well, there's still a systemd --user, but it's not being used to start the unity session19:59
jderosepitti: is this a potential sort-term fix, or are there other consequences to doing this?19:59
pittijderose: it would throw us back from all the porting work; I think we left all the upstart bits in place20:01
jderosepitti: yeah, i have some stuff started by the upstart user session and it's still working fine with out-of-the-box yakkety. for what that data point's is worth :)20:02
jderosepitti: if reverting back to the upstart user session for yakkety is a reasonably low risk change, my vote would be to do so, then sort out the systemd user session stuff properly for Z;)20:10
pittijderose: haha, I know20:11
pittiit's also a reasonably low impact bug..20:11
jderosepitti: i guess, but it sure makes a bad first impression. especially if you just ordered a shiny new System76 laptop with shiny new Ubuntu 16.10 on it... for example :)20:13
pittijderose: hang on20:13
Unit193pitti: dbus-user-session is a requirement of systemd user sessions and is otherwise unrelated, correct?  x-d-s still depends on it.20:15
pittiUnit193: x-d-s?20:16
Unit193Erm, right.  xubuntu-default-settings.20:16
pittiUnit193: correct; but OTOH moving from session to user centric model actually caused the majority of regressions20:16
pittiless so the actual upstart → systemd move, as that's just mechanics of what tells unity et al to start20:16
Unit193So it's only been partially reverted, alright.20:17
pittiUnit193: does that slow backlight chnaging affect xubuntu too?20:18
jderosepitti: so currently dbus-user-session isn't used when you use the Upstart user session stuff, only with the systemd session stuff, right?20:18
pittithat would be a surprise20:18
pittijderose: it is, just less20:18
pittiin particular not for settings-daemon20:18
Unit193pitti: I don't know.20:18
Unit193bluesabre: ↑20:19
pittijderose: followed up to the bug, I now completely understand what's going on20:19
jderosepitti: awesome, reading...20:20
bluesabreI noticed the slow backlight in xubuntu yakkety, thought it was my laptop20:20
pittibluesabre: even after https://launchpad.net/ubuntu/+source/xubuntu-default-settings/16.10.2 ?20:21
bluesabrepitti, I believe so, can confirm in ~2 hours20:21
pittibluesabre: well then, however that happens, the fix should be the same20:21
jderosepitti: okay, that sounds very promising! what can i do to help confirm common-session-noninteractive wont cause problems? (i've already been experimenting with it on a few systems, nothing weird yet.)20:22
pittijderose: mostly that, testing20:22
pittijderose: but after that I'm actually reasonably sure that it doesn't regress, mostly because for all that time we did *not* start a full PAM session either :)20:23
pittiand the *only* difference between interactive and noninteractive is pam_systemd20:23
jderosepitti: yeah, the reasoning makes sense to me (even though i don't understand the details as well)20:23
pittipreparing upload now20:27
pittijderose: thanks for your help on this! this steered me into the right direction20:28
jderosepitti: happy to! glad my stumbling around was helpful :)20:29
=== rcj` is now known as rcj
=== rcj is now known as Guest46240
=== Guest46240 is now known as rcj
pittijderose: uploaded, now need to find someone to review20:40
jderosepitti: awesome20:40
LocutusOfBorgdoko_, is this failure a binutils fault? https://launchpadlibrarian.net/288571350/buildlog_ubuntu-yakkety-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu3_BUILDING.txt.gz21:17
LocutusOfBorgsecure-plt is something that llvm is not injecting21:18
Unit193If anyone is sync happy, geoip-database is a free sync. :321:52
=== infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: final freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
naccsmb: LP: #1546674 may also be worth fixing at the same time, if you do pick up that fix from LP: #159169522:37
ubottuLaunchpad bug 1546674 in libvirt (Ubuntu) "virt-aa-helper Apparmor profile missing rules for name resolution" [High,Triaged] https://launchpad.net/bugs/154667422:37
ubottuLaunchpad bug 1591695 in libvirt (Ubuntu) "libvirt-guest.sh will never sucessfully shutdown more than one virtual machine in my setup" [Medium,In progress] https://launchpad.net/bugs/159169522:37
nacccpaelzer_: --^ as well, in case you are coordinating with smb on libvirt bugs22:38
doko_LocutusOfBorg: please ask the powerpc maintainers23:40
naccdoko_: LocutusOfBorg: is it possibly related to: https://llvm.org/bugs/show_bug.cgi?id=20572 ?23:45
ubottullvm.org bug 20572 in Backend: PowerPC "PowerPC backend does not support secure PLT" [Normal,New]23:45
naccdoko_: LocutusOfBorg: ah no, it's presumably LP: #16112723:46
ubottuLaunchpad bug 161127 in mysql-dfsg-5.0 (Ubuntu Dapper) "Fix for MySQL Bug #22413 should be backported to LTS releases" [Medium,Fix released] https://launchpad.net/bugs/16112723:46
naccbah23:46
naccLP: #161122723:47
ubottuLaunchpad bug 1611227 in qtbase-opensource-src (Ubuntu) "Don't use gold linker on powerpc (GCC6)" [Undecided,Fix released] https://launchpad.net/bugs/161122723:47
naccLocutusOfBorg: fyi, fixed there with: http://paste.ubuntu.com/23286833/23:52
naccLocutusOfBorg: presumably something similar needed for llvm-toolchain-3.6?23:53
naccrbasak: at this point, should the vivid/wily tasks for LP: #1455818 be marked as won't fix and new tasks opened for xenial?23:56
ubottuLaunchpad bug 1455818 in mysql-5.6 (Ubuntu Wily) "[SRU] mysql-server-5.6.postrm fails when /usr/share/mysql-common/configure-symlinks doesn't exist" [High,Triaged] https://launchpad.net/bugs/145581823:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!