[00:33] hi all [00:33] does anyone know of a working qml app that does xmlhttp requests ? [00:35] or alternatively: does anyone know of a way to use it without apparmor messing it up [00:35] what are your DENIED lines? [00:37] hi sarnold hang on i'll chuck it in a pastebin [00:38] http://pastebin.com/xGXphnEi [00:39] i have to add that it only fails when i deploy the app to the phone. running it in the sdk on the desktop, it does great [00:40] heh I hadn't expected dbus errors... [00:41] matv1: could you file a bug against click-apparmor source package, include these lines, any DENIED lines from syslog, and perhaps a small copy/paste of the function that generated these errors? thanks [00:42] matv1: either 'ubuntu-bug click-apparmor' (if that works on the phone?) or https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+filebug [00:42] sarnold sure. no problem [00:43] sarnold are you canonical if i may ask? [00:43] matv1: I am [00:43] sarnold great thanks :) [00:44] matv1: you're welcome, I hope this helps sort it out ;) I don' tknow much about the wrappers around the apparmor policy, but I'm pretty sure filing a bug there will sort things out :) [00:45] hmm not sure about that :) but i will stay hopefull [00:47] i had been tinkering with this a while back. about 6 months ago. gave up on it then. hope it would have been better now. because there is a bug about this where at least jamie strandboge participated in, I recall [00:48] yeah, and he'll probably participate in this one too :) but the trick is there's a huge amount of qml/qt infrastructure and it doesn't all fit with our security goals. so some APis are allowed, some are forbidden, and mostly we only investigate adding ones as people run into them [00:49] there's some connectivity API with Qt that apparently allows way too much personally identifiable information or similar to be handed to confined apps, which is why we block it, but nothing prevents rewriting the APIs or services to expose only what's needed. the trouble is there's only so many hours per day and so many people to work on things.. [00:52] sarnold I appreciate that. I will do that bug report. let's see how it goes. Thanks again [00:52] thanks matv1 :) have fun === danjared_ is now known as danjared === tjaalton_ is now known as tjaalton [06:31] mdeslaur: is the "Ubuntu Wine Team" https://launchpad.net/~ubuntu-wine no more? === coreycb` is now known as coreycb [07:59] Good morning [08:01] pitti: I'm done with the rsyslog merge, just want a second look before uploading; hopefully today [08:01] caribou: yay, great [08:35] good morning === larsu_ is now known as larsu [09:57] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100, darkxst [10:08] * dholbach hugs sil2100 [10:10] * sil2100 hugs dholbach back [10:16] pitti: hey, could you consider retrying some https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html related results and maybe overriding kwin and/or hinting it not to try it together with the hybris update? and also i386 qtmir retry at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-023/excuses.html [10:16] I'm hearing rob_ru might be bringing "retry" button to those pages in a few weeks, which sounds wonderful [10:17] Mirv: retry button> that needs some legwork on my side first, but yes, we should do that [10:17] can somebody moderate my mail on u-d-a through? === asac` is now known as asac [10:20] Is it possible to get the armhf binary for julia 0.4.2-3 removed? it is holding up the suitesparse transition. i don't yet know why 0.4.3 FTBFS on armhf in ubuntu (debian is fine), and 0.4.2-3 now also FTBFS on armhf. [10:20] Mirv: I retried the armhf failures (xenial, will do vivid in a sec); but kwin passes in Ubuntu [10:21] Mirv: and that failure looks like some API change, not a transient issue? [10:21] dholbach: done [10:22] pitti: it's when it's tested with the new libhybris, not because of qtdeclarative changes [10:22] thanks pitti [10:22] pitti: thanks. [10:22] pitti: there are also older failures in archive when the new libhybris is being tested. [10:23] Mirv: qtmir retried for the vivid PPA [10:25] ginggs: yes, there are no reverse depends (just some reverse recommends from science-* metapackages) [10:25] Mirv: ah, I guess robru tests PPAs against all -proposed [10:26] Mirv: so, I don't want to override that in ubuntu as it's clearly a regression, and either libhybris or kwin needs to be updated [10:26] and by overriding we would let libhybris in and land the regression [10:26] pitti, ok, can you do remove it please, or shall i file a bug? [10:28] Mirv: so I'd recommend to just ignore that one failure for this landing [10:29] ginggs: removed [10:29] pitti: the problem is convincing QA to get that silo manually in to their consideration :) but I believe they might believe me if I quote you, and if the other non-overridden tests pass. thank you again. [10:29] pitti: thanks! [10:29] Mirv: yes, you have my blessing and you can quote me on that :) [10:30] Mirv: it would probably be better if we tested PPAs not against the entirety of -proposed, so that they are better isolated against such unrelated breakage [10:31] or, once someone fixes libhybris or kwin, we can retry it and then it'll work too [10:33] pitti: ok, robru could change the behavior so that not all of -proposed would be used [10:55] Mirv: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html looks better now [10:58] pitti: indeed it does! just waiting for the vivid i386 qtmir still. [11:03] ..and it updated [11:05] yay [11:16] hi, I've been working on a libnl sru into trusty (https://bugs.launchpad.net/ubuntu/trusty/+source/libnl3/+bug/1511735) ; the update is in trusty-proposed and the new package exposed a bug in NetworkManager (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1539634) which has been fixed and pushed into trusty-proposed as well; One of the users suggested that we add a Breaks: and release an update to libn [11:16] l with the Break to ensure that no users get the older networkmanager and the newer libnl; is network-manager (<< 0.9.8.8-0ubuntu7.3) sufficient ? and is this something we should do to ensure users install the newer NM before upgrading libnl ? [11:16] Launchpad bug 1511735 in libnl3 (Ubuntu Trusty) "libnl: fail to bind() netlink sockets" [Medium,Fix committed] [11:16] Launchpad bug 1539634 in network-manager (Ubuntu Trusty) "network-manager crashes when using libnl-3-200-3.21.1-1ubuntu1" [High,Fix committed] [11:17] rharper: Breaks sounds correct and sufficient [11:17] cjwatson: and should I limit the Breaks to the packages that NM depends upon ? [11:18] libnl provides more than just those 3 [11:18] rharper: I don't quite understand the question [11:18] in libnl debian/control, we list multiple binary packages, do I apply the Breaks: line to each of those or only the entries for the packages that NM actually depends up (and installs) [11:19] rharper: Put it at the root of the dependency hierarchy; since there is a root here, you only need it in a single place [11:19] cjwatson: ok, thanks! [11:19] rharper: That is, you only need it on libnl-3-200, not anywhere else [11:20] rharper: Well, strictly, it should be on the package where the actual code that breaks is shipped, but I'm guessing that's in the core library [11:20] ok [11:25] hey. i'm in need of some help. [11:25] https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/34/consoleFull [11:25] thats a log of a seeded install [11:25] my understanding is at that end of that install, it tries (reasonably) to unmount the target [11:26] i think that umount_active is asking us a question because it tried to unmount the target and failed [11:26] ie, the target was "active" because some process was running there and had open file handles. [11:29] can someone at least verifiy that my understanding of 'umount_active's purpose for that question is right ? [11:31] No, that isn't correct [11:31] ]o/! [11:31] Let me find you the code [11:31] thank you! [11:32] An important thing to understand is that this is during partitioning, not at the end of the installation process; processes shouldn't generally be running that aren't the installer (and there are no such process checks) [11:32] http://bazaar.launchpad.net/~ubuntu-core-dev/partman-base/ubuntu/view/head:/init.d/parted#L154 [11:33] The second comment there basically explains the idea [11:34] its not during the partitioning tough [11:34] look at that log, cjwatson [11:34] oh. maybe. [11:34] I have, and you are incorrect. [11:35] :) [11:35] The last menu item that is logged as selected is partman-base. [11:36] so what else would be mounted ? [11:36] So the question is ... that [11:36] this is a transient failure [11:36] that is what is really odd [11:37] and i'm pretty sure the input disk to the installer is full of zeros [11:37] (ie, no old filesystem or swap or antying like that that could possibly get mounted) [11:37] Is /var/log/partman from this install logged somewhere? [11:38] Can't see it directly in the build artifacts [11:39] well, that one got killed [11:40] smoser: This log seems to contain two runs of the installer [11:40] i dont know that the file is collected. [11:40] interesting. so it rebooted to the installer, and the second time then found a disk that got automatically mouinted or something [11:40] There are two hits for "Menu item 'partman-base' selected", and the first is followed by the installer doing more stuff after that [11:41] definitely [11:41] and 2 kernel boot logs [11:42] Yeah. Race in the reboot arrangements? [11:42] thank you colin. that is at least somethigng to look at === cpaelzer_ is now known as cpaelzer_afk [11:44] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst [11:48] smoser: I'm a little surprised by the automounting too, since the second install hasn't reached the point where it would do the automounting I'm aware of yet, and in any case that automounting is off by default ... but it could be somewhere else I'm not remembering, and who cares really since this is all in the land of consequential failures [11:53] * dholbach hugs sil2100 === _salem is now known as salem_ [12:06] ginggs: oh, I was going to say no, but it does look like mlankhorst uploaded to the ppa in december [12:06] (re: wine) [12:45] mdeslaur: i noticed the Ubuntu Wine Team PPA is no longer listed on the WineHQ download page, but instead a new team https://launchpad.net/~wine === cpaelzer_afk is now known as cpaelzer_ [13:02] tinoco, xnox: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8~+rc1-1~exp1 [13:03] cjwatson, are you sure it woudl be a mount ? if it would notice that lvm had holders and fail, thent that coudl be it. [13:12] smoser: yeah, that information is read from /proc/mounts if you look at the code, it has to be a mount [13:13] trying to build a source package (libnl) and getting an error from debuild -S, complaining: dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input data in general section of control info file (http://paste.ubuntu.com/14865920/) [13:13] xenial host [13:13] rharper: ignore [13:13] that's a warning not an error [13:13] ok, error further down [13:13] rharper: oh, you are seeing an error but it's not the one you summarised here [13:14] rharper: debuild -S -nc === marcusto_ is now known as marcustomlinson [13:14] rharper: you need to have the build-depends satisfied if you aren't using -nc; using -nc avoids that requirement but means you need to be more careful to ensure that your source tree is clean [13:14] ah [13:15] given that you just pulled a fresh source package here and modified it, -nc is safe (but remember to edit the changelog too!) [13:16] cjwatson: thanks for the tip; I though I had build-deps satisfied but I did not; yep will update changelog too [13:20] doko: o/ [13:22] doko: i dont think ocaml is available on s390 [13:25] tinoco, it is available. disabling lldb works around the build failure [13:25] cool! [13:59] doko, hi, do you plan to sync llvm-toolchain-3.8 from experimental? [13:59] I might give some time in fixing build failures [13:59] oh well, already there, sorry [14:01] amd64 failed for ENOSPACE [14:17] barry, hey, bug #1541407 seems due to your python3 changes, can you have a look? [14:17] bug 1541407 in apt-xapian-index (Ubuntu) "/usr/share/apt-xapian-index/update-apt-xapian-index-dbus:SyntaxError" [High,New] https://launchpad.net/bugs/1541407 [14:19] barry, bug #1541408 also seems to be due to the xapian update [14:19] bug 1541408 in sessioninstaller (Ubuntu) "/usr/bin/session-installer:AttributeError:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@38:/usr/bin/session-installer@23:/usr/lib/python3/dist-packages/sessioninstaller/core.py@53:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@39" [Undecided,New] https://launchpad.net/bugs/1541408 [14:19] 'xapian' has no attribute 'DatabaseOpeningError' [14:22] rbasak, is it normal that we have php5 and php5.6 packages which are both php 5.6? [14:24] xnox: it's 'normal' in that debian has it that way .... what's a bit weird is that php5.6' version is different than php5 [14:24] i believe php5.6 is a metapackage, as well [14:24] seb128: okay, thanks. i'll take a look [14:24] barry, thank you! [14:26] nacc, i shall slowly back away then =) [14:27] xnox: yeah, it's quite gross [14:27] xnox: hopefully, we'll just drop it all :) === NishanthMenon__ is now known as NishanthMenon [14:36] seb128: LP: #1541407 is an easy fix. LP: ##1541408 doesn't yet make sense ;) [14:36] Launchpad bug 1541407 in apt-xapian-index (Ubuntu) "/usr/share/apt-xapian-index/update-apt-xapian-index-dbus:SyntaxError" [High,New] https://launchpad.net/bugs/1541407 [14:37] LP: #1541408 [14:37] Launchpad bug 1541408 in sessioninstaller (Ubuntu) "/usr/bin/session-installer:AttributeError:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@38:/usr/bin/session-installer@23:/usr/lib/python3/dist-packages/sessioninstaller/core.py@53:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@39" [Undecided,New] https://launchpad.net/bugs/1541408 [14:37] barry, yeah, the syntax error looked like a simple one, thanks for fixing it! [14:37] seb128: if i can't figure out the session installer one before i have to start sprinting, i'll upload the fix for the first one and come back to it [14:37] barry, unsure about the other one, either there was an incompatible change in the bindings or something weird? [14:38] barry, yeah, it's less of an issue, I would say that can wait for after ff [14:38] seb128: that's the thing, from the cli the imports work fine [14:38] cool [14:38] k, don't bother for now then [14:38] the syntax error is the important one [14:38] it prevents that file to work at all [14:38] seb128: cool. let me upload that one right now then [14:38] thanks [14:38] cheers === s1aden is now known as sladen [14:44] Does anyone know if Ubuntu is planning a dynamic /etc/fstab similar to what has been done for /etc/motd? This would make it much easier to build cloud environments. [14:44] scaldwell: to what end, and how would it make it easier? [14:44] probably not soon ... [14:45] but i could imagin that we switch to systemd mount units at some day [14:45] pitti might know if there are any plans [14:46] not really a "plan", but you can do this today if you want [14:46] technically you can boot without fstab today already as long as you have a single partition setup .... ubuntu will happily boot using /dev/root [14:46] It would allow me to parameterize EFS volumes. [14:46] i. e. create .mount units instead of fstab entries [14:46] systemd itself does that via a generator which reads fstab and synthesizes .mount units in /run/systemd/generator/*.mount [14:46] true. I just was talking about the new dynamic /etc/motd and we started discussing IRL how it would be nice to have one way to rule them all. [14:47] pitti, cyphermox, we activate lvm volume groups with udev rules, by default, including inside d-i. Which when done on s390x dasd drive, make it impossible to format it. Should we disable udev rules that auto-activate lvm volumes in lvm2 udeb? [14:47] bug #1536664 [14:47] bug 1536664 in debian-installer (Ubuntu) "Installer cannot use DASD if it was used with LVM before" [High,New] https://launchpad.net/bugs/1536664 [14:47] for EFI systems systemd can also read their partition UUIDs, and as long as they are correct, auto-mount them [14:47] but to this date our installer still writes wrong UUIDs, so that doesn't work [14:47] oh [14:47] cyphermox: ^ which reminds me, we quickly talked about that ages ago, but never got around to it.. [14:47] pitti, i can fix the installer uuids, i think. [14:48] hum, what? [14:48] scaldwell: on ec2? [14:49] xnox: so you're installing on a system where the drives were used for LVM before, they got auto-activated, and now you can't remove the volumes to format the drives? [14:49] pitti: wrong UUIDs? [14:49] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs ← this [14:49] pitti, but that will only work with GPT [14:50] ah, jes [14:50] cyphermox: last time I checked, all GUID partitions that d-i created were of the generic type "Linux filesystem data", not "root partition", "home partition", "swap", etc. [14:50] the UUID for the EFI partition [14:50] ah [14:50] pitti, also parted doesnt know about GUIDs [14:50] ogra_: sure; there is no counterpart to do that with MBR, for that you need fstab [14:50] cyphermox, yes, and where "format" i mean "mainframe specific operation for dasd drive specifically to `format` them with dasdfmt before partman was even run" [14:50] pitti, i just had to move all of snappy to sgdisk thanks to that lack [14:50] cyphermox, aka re-initialise the drive [14:51] xnox: does it have to run before partman runs? [14:51] ogra_: indeed, it's annoying; I didn't find a good CLI way to change partition type UUIDs [14:51] ogra_: sgdisk does that? good to know [14:51] pitti, sgdisk ;) [14:51] xnox: how does it prevent formatting? You mean you want to re-format a PV into e. g. a plain ext4 partition? [14:51] ogra_: It kind of does, they're just mapped into parted-speak [14:51] And maybe not completely so [14:51] cyphermox, yes, otherwise partman will see gibberish on the disk, and will not be able to e.g. create a valid parition table on it, or write a valid partition table. [14:52] e.g. I'm pretty sure we do actually set a swap GUID [14:52] pitti, prevents "dasdfmt" to succeed, if one chooses to reinitialise the drive (dasdfmt) [14:52] cjwatson: I think that might be the only one [14:52] cjwatson, well, i needed to dynamically set them to certain values to create the proper boot setup for the dragonboard (each bootloader bit checks for the next piece to load by GUID there) [14:52] xnox: ah, and it's not an option to run vgremove/pvremove before either, I suppose? [14:52] xnox: in such a case, partman does not see the drives at all? [14:53] cyphermox: possibly, yes [14:53] xnox: if you remove the udev rules in d-i, then you can't re-install onto an existing LVM, or d-i needs to be modified to piece them together manually? [14:53] pitti, cyphermox - it's a step/udeb/menu before partman. [14:53] cjwatson, and i didnt find anything in parted itself for this ... [14:53] tricky though, because parted isn't really told about the purpose of the partition, only (at best, and probably not always) what FS type it's going to contain [14:53] pitti, no. as debian-installer has all that. E.g. in partman, you enter lvm menu, activate volume group, etc. [14:54] somebody should take this to parted-devel to discuss requirements [14:54] xnox: seems to me like it shouldn't care that there are LVM volumes, and that if it does it could just as well be told to disable then before doing whatever it does [14:54] xnox: question for you on one of your merges for bacula from 2013 :) [14:54] * ogra_ points to http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/partitioner.sh ... which uses http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt to create the bootloader setup required [14:54] cjwatson, in clearlinux, after partitioning, i would reset the part-type uuid with the "systemdish" ones, cause at that point i had the information "yeap, this will be rootfs partuuid". [14:55] it would perhaps be possible to do that in partman-target [14:55] it has the mount information [14:55] yeah [14:55] cyphermox, pitti - i think it's wrong to auto-activate lvm groups with udev, and thus interfeering with d-i state machine. [14:55] xnox: you know d-i much better than I, I trust your word :) [14:56] pitti, i wonder if desktop/ubiquity breaks if i change the udeb udev rules though =) [14:56] I wouldn't expect it to [14:56] xnox: what do you want to change there? [14:56] this is why we generally try to beat the udev rules into submission rather than removing them [14:56] xnox: (LVM auto-activation is in lvm, not udev) [14:56] to avoid having to have a different workflow in ubiquity [14:56] ude B i meant. [14:56] as in lvm2.udeb [14:57] debian/{dmsetup,lvm2}-udeb.install [14:57] xnox: so, that reduces one line of delta :) [14:57] oh. [14:58] seb128: fixed a couple other problems with -dbus while i was at it [14:58] two actually (one for each udeb) [14:58] barry, great :-) [14:59] pitti, well, debian doesn't have udev rules for lvm full stop. [14:59] xnox: right, this is an ancient delta of our's [14:59] xnox: these days they have a lot of fancy units, but I never looked at those in detail [15:00] pitti, surely we don't care about lvm on the phone, and we should drop this stuff and use something systemd-ish? a generator? [15:00] xnox: I suppose easiest thing might be to install Debian sid on LVM into a VM and see how it works there? [15:01] hm, yeah. [15:01] i. e. what puzzles together VGs there; it ships the units, but no udev rules [15:01] they still have some udev rules, but not the activation ones. [15:01] or maybe it's still just the scripts/units that run once on boot, but that'd be rather poor [15:01] pitti, i wonder if it's best to eg. look at upstream and/or fedora. [15:01] i. e. this ought to work for hotplugged drives too [15:01] xnox: specifically if you knew why the postgres dependency was bumped to 9.3 .. we're going to move bacula to universe, so it might be nice to remove that from the delta [15:03] nacc, if it builds and runs unmodified, and e.g. "libncurses-dev" and "liblzo2-dev" build depends are present in bacula. [15:03] nacc, one can just sync it, and demote it to universe. [15:04] nacc, as far as i can tell all our changes were done to make it suitable for main. [15:04] xnox: ok, i'll make a note of that; it seems like the upstream code has fixed the ncurses dependency [15:05] nacc, cool. [15:05] and liblzo2 is merged [15:05] upstream, i mean [15:06] pitti, looking at upstream alone, there is a systemd instance unit that binds to all block devices to scan and activate them. [15:07] pitti, which is nice, cause then one can stop the unit. [15:07] xnox: that unit gets activated via udev, I figure [15:07] which would fix the https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081 [15:07] Launchpad bug 1088081 in lvm2 (Ubuntu) "udev rules make it impossible to deactivate lvm volume group with vgchange -an" [High,Confirmed] [15:07] pitti, yeap, udev->systemd-> generate the fake .device units that these things bind to. [15:08] they aren't "fake" :) [15:08] which would still be ubuntu-ish "auto-enable all the lvm groups" but "without bugs" [15:08] if you tag an udev device with "systemd", you will get a systemd .device unit for it with proper state, and can then make that trigger services or other stuff [15:08] pitti, i'm also pointed at lvmetad thing [15:10] oooh lvmetad does nested lvm properly. [15:22] right, i think i have screwed up this d-i bad enough. let me reboot it. [15:23] cyphermox, pitti: i wonder if i should use the force, when doing dasdfmt. [15:23] and that's it. === tkamppeter_ is now known as tkamppeter [15:46] Laney: http://archive.ubuntu.com/ubuntu/dists/xenial/main/dep11/ etc. if you fancy having a look === cpaelzer_ is now known as cpaelzer_afk === kenvandine__ is now known as kenvandine [16:09] pitti: newest rsyslog has made it to the archive, you may want to update & retest your juju bug [16:17] caribou: cool, thanks === mnepton is now known as mneptok === cpaelzer_afk is now known as cpaelzer_ [17:03] dpm: hey, [17:05] whois dpm [17:05] d'oh [17:05] that'd be me :) [17:05] just making sur ei'm buggin ther ight person :) [17:05] but I'm on the phone [17:05] dpm: if you need help with cgmanger ping me when you're off the phone [17:05] awesome, thanks [17:11] cjwatson, back on that partman failure thing... [17:12] in d-i, if there was swap partition would boot magically use it and then d-i see it busy? i suspect not, but grasping at what would have mounted something on that disk [17:12] as that seems completely non-sensical (and is probably a bug) [17:23] smoser: that wouldn't show up in /proc/mounts, so cannot be relevant [17:29] does it dump /proc/mounts anywahere or could it ? [17:29] on failure to find a disk, that'd likely be useful. [17:38] smoser: I don't think it does right now; it would be a reasonably easy patch to partman-base to make it log that in the cases where it asks a question [17:40] yea. thanks for your help cjwatson [17:40] since you're here.... and you're last touch (in gutsy) [17:40] https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-drop-ppp/+merge/284941 [17:41] https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-ppp-to-server-ship/+merge/284943 [17:41] your thoughts are very appreciated there. [17:44] doko: i see you uploaded mpi-defaults recently, do we need debian bug #813494 fixed as well? [17:44] Debian bug 813494 in mpi-default-dev "mpi-default-dev: Please depend on openmpi (>= 1.10.2 -3 )" [Important,Open] http://bugs.debian.org/813494 [17:58] hallyn, so, to debug why apps don't start on unity 8, is it essentially these steps? http://pastebin.ubuntu.com/14868891 [17:58] smoser: I don't really have an opinion on that [17:59] dpm: the cgmanager debug step isn't quite right. but hold on, you're on xenial? [17:59] hallyn, yes I am [18:00] dpm: ok, libpam-cgfs is replacing libpam-cgm there. [18:00] we can still test with libpam-cgm, but... [18:01] dpm: your original failure was with libpam-cgfs installed? [18:01] tried both [18:02] dpm: and right now you have libpam-cgm installed? ok, lets proceed with that then. systemd is running, right? [18:03] hallyn, hold on, otp again, sorry [18:03] inthat case, do 'sudo systemctl stop cgmanager', then 'sudo /sbin/cgmanager -m name=systemd --debug' (in a term with scrollback or piping into a file) [18:03] dpm: np. anyway, ^ do that and then try again starting the app and pastebin the cgmanager debug output [18:09] * hallyn biab === cpaelzer is now known as cpaelzer_afk [18:42] hallyn, ok, back if you are around. I've got libpam-cgfs installed [18:53] cjwatson: thanks - now to find out why apt doesn't download it. :) [18:55] it knows about the indextarget and the URL seems right [18:56] juliank: if you're around, is it you who knows about IndexTargets? [18:57] dpm: ok, and it still fails? [18:57] with the new version? [18:57] (0.17-0ubuntu3) [18:58] juliank: I install appstream on xenial and update, and apt-get indextargets --no-release-info shows it with the right URL (without .gz but that appears to be correct), yet it's not downloaded [19:04] pitti: hey. who all has access to do autopkgtest retries for britney on silos? [19:05] I thuoght it was anyone who could upload the package or the triggers.. [19:05] dobey: those: ubuntu_archive:x:2552:cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney [19:05] sarnold: for ubuntu yes, but web retry isn't implemented yet for silos [19:06] ahhhh [19:06] oh, only archive admins? ok [19:06] dpm: libpam-cgfs does not use cgmanager at all. So if it fails with libpam-cgfs and with the '-c freezer' removed from the line in /etc/pam.d/common-session, that'll be very curious [19:07] sarnold: well, i don't have permissions to upload the package or the triggers, i don't think; but at least "any motu" would probably work for that situation [19:07] dpm: in that case we'll have to assume that libpam-cgfs is not being called, and look into why. (we'll have to verify that by having the app launcher sleep right before final exec of the app and look at /proc/pid/cgroup) [19:08] pitti: well, since you're here, can you rerun the unity-scope-click test on xenial armhf for silo 41? [19:10] $ run-autopkgtest -s xenial -a armhf --ppa ci-train-ppa-service/stable-phone-overlay --ppa ci-train-ppa-service/landing-042 --trigger pay-service/15.10+16.04.20160114-0ubuntu1 unity-scope-click [19:10] dobey: ^ done [19:10] pitti: 41 not 42 :) [19:10] but thanks [19:11] dobey: that cannot be -- 42 is TEH RIGHT ANSWER! [19:11] heh [19:11] (kicked the right one) [19:13] hallyn, ok, then I'll give libpam-cgfs another go and double-check sure I've got -c freezer removed [19:26] hallyn, so with libpam-cgfs installed, having removed '-c freezer', still same result: apps won't start [19:27] hallyn, installed libpam-c* packages -> http://pastebin.ubuntu.com/14870814 [19:28] and contents of /etc/pam.d/common-session -> http://pastebin.ubuntu.com/14870817 [19:30] Laney: Is it listed in the Release file? [19:31] No entry there, no fetching [19:33] * juliank is a little bit slow right now with writing as he just cut into his right thumb [19:35] dpm: ok, so let's try restarting cgmanager with --debug as i described above, and change the pam.d/common-session line from pam_cgfs to pam_cgm [19:36] Hmm, it seems to be listed [19:36] dpm: that way we can see whether any requests are being made of pam [19:36] juliank: Yeah, http://archive.ubuntu.com/ubuntu/dists/xenial/Release [19:36] Laney: But only the compressed dep11 files are listed in the xenial Release file, APT probably needs the uncompressed ones as well === mnepton is now known as mneptok [19:37] hallyn, would you mind re-pasting the cmanager restart command? I'm on my laptop now and don't have the scrollback [19:37] o rly? [19:38] dpm: 'sudo systemctl stop cgmanager; sudo cgmanager -m name=systemd --debug' [19:38] juliank: actually I don't even - Debian lists them in there but they don't exist? [19:39] Laney: Sure uncompressed Contents and Packages files don't exist either. [19:39] hallyn, and do I need to install libpam-cgm before changing the common-session file? [19:40] hallyn, it seems at least I need to install the 'cmanager' package to get the cmanager command [19:40] dpm: i thought you said you had libpam-cgm installed [19:40] yes. so install cgmanager and libpam-cgm i guess [19:41] actually maybe it would have been easier to strace -f -p pid-of-launcher (upstart?) and look at that strace [19:41] hallyn, no, I had -cgfs installed, IIRC (see pastebin above) [19:41] i was looking at http://pastebin.ubuntu.com/14870814/ [19:42] but no matter - actually can you do the strace first instead? it may tell us what we need [19:42] juliank: ok, so Launchpad should be generating this? [19:43] dpm: that's assuming you know which task fires off the app, which ia ssume you do. (upstart user session?) [19:43] Laney: I think so, yes [19:43] cjwatson: ^- apparently you need to list the files uncompressed too [19:43] back in 5 [19:43] cf Packages [19:43] hallyn, right, on http://pastebin.ubuntu.com/14870814 I've got -cgfs installed (just making sure I've got the right one) [19:43] hallyn, I've no clue which task fires the app, no [19:44] * juliank would also list checksum for uncompressed Contents files while at it [19:45] hallyn, nm, I need to run, thanks for the help and let's continue tomorrow [19:56] d'oh. who would know... [19:57] wish I could edit comments in launchpad [20:06] Laney: Ah, I wondered, but wanted to see whether it was needed [20:06] Laney: I came up with a plan for that, so I'll put that into practice later [20:07] juliank: that's a little more effort for reasons, but will see what I can do [20:08] I guess if I need it for Contents as well then maybe I should deal with it in the publisher itself rather than hacking around it in ubuntu-archive-publishing scripts as I'd initially planned [20:12] cjwatson: It will be needed for Contents for apt-file 3.0 to work [20:13] I suppose it's possible to hack around things by including .gz in the APT configuration and removing the setting to keep files compressed, but that's somewhat ugly. [20:13] That is, in the files shipped by appstream and apt-file 3 [20:18] * juliank is afk for 45 minutes === rcj` is now known as rcj [20:39] juliank: Yeah, historically we've hacked around it in a fairly ugly way for Packages (we generate uncompressed Packages and then remove them in postprocessing) but that isn't done for Contents and I think it's time to fix it in a more graceful way [20:39] bah, timing === salem_` is now known as _salem [20:50] infinity: ping [20:57] robert_ancell, hello! [20:57] robert_ancell, limba looks kinda nuts is all [20:57] mterry, hi! [20:58] mterry, yeah, thought that might be a little like that. Just say no in the MIR and we'll take it as a packaging issue. [20:58] robert_ancell, well I'm expecting security to say no. But that no might take a while to get to you, they're quite busy [20:59] mterry, thanks for the review [20:59] robert_ancell, I can review the packaging to try to find an early reason to say no :) [20:59] robert_ancell, or maybe just patch it out for now and if they come back and say it's fine after all, add it back [20:59] mterry, yeah [20:59] mterry, there's plenty of other MIRs that need doing first [20:59] truth [21:00] robert_ancell, I'd never heard of limba. Is it popular? [21:00] mterry, no, it's new [21:02] robert_ancell, is packagekit 1.0 being packaged shortly? [21:02] mterry, we're having issues tracking down all the loose ends. We may have to drop PK1.0 and work around it. [21:03] mterry, it is packaged in the sense that the Debian version is what we'd use [21:03] robert_ancell, gotcha [21:03] maybe I'm going to have to take a day and sort out the click native-dbus branch, since apparently nobody else is [21:04]