| === ScottK2 is now known as ScottK | ||
| Snow-Man | jdstrand: I don't suppose you have any idea when it'll drop...? | 00:03 |
|---|---|---|
| sarnold | Snow-Man: I'd suspect early next week at the soonest; openssl updates have had unwanted regressions in the past, we might do some wider testing of it before pushing. | 00:07 |
| Snow-Man | oh. | 00:07 |
| Snow-Man | hrmpf. | 00:07 |
| sarnold | imho, it's not likely the kind of update you want to push towards the end of a week unless there's active exploitation. admins need a fighting chance of not working on weekends. :) | 00:08 |
| Snow-Man | heh.. | 00:09 |
| * Snow-Man already upgraded all of the PG infrastructure | 00:09 | |
| Snow-Man | The DSA looked like an exploit would probably not be far off... | 00:09 |
| doko | bdrung, do you want to join the pythoneers team? | 00:13 |
| jtaylor | whats wrong here: checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no | 00:18 |
| jtaylor | package uses autotools_dev | 00:18 |
| jtaylor | so config.* should be fine? | 00:18 |
| mwhudson | apologies if this is a stupid question, but should a debdiff show changes in the rules file? | 00:45 |
| rbasak | mwhudson: yes, it should. | 00:45 |
| mwhudson | hmm | 00:45 |
| mwhudson | rbasak: what on earth are you doing online btw? :) | 00:45 |
| mwhudson | oh feck i just ran scons -c in the wrong directory :/ | 00:46 |
| rbasak | What, you mean that I shouldn't be online at 1am? | 00:46 |
| mwhudson | yes | 00:46 |
| mwhudson | that | 00:46 |
| rbasak | Better go then :) | 00:46 |
| rbasak | o/ | 00:46 |
| mwhudson | g'night | 00:47 |
| GunnarHj | robert_ancell: Hi Robert! | 00:51 |
| robert_ancell | GunnarHj, hi | 00:52 |
| GunnarHj | robert_ancell: http://people.ubuntu.com/~gunnarhj/shell-guest-session.html#disable is about to make it to Ubuntu Help. Yesterday you mentioned your plan to break out guest session to a separate binary package. I just wanted to point out that doing so would not make much of a difference with respect to how easy/difficult it is to disable guest session. But maybe you have other reasons. | 00:53 |
| cjwatson | jtaylor: that's out-of-date libtool.m4 (or libtool macros embedded in aclocal.m4 or similar) - needs dh_autoreconf rather than dh_autotools-dev_* | 01:46 |
| cjwatson | jtaylor: cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726404 | 01:47 |
| ubottu | Debian bug 726404 in libtool "libtool: Backport a new architecture (ppc64le) to Debian" [Wishlist,Fixed] | 01:47 |
| GunnarHj | robert_ancell: You disappeared... | 02:10 |
| robert_ancell | ? | 02:10 |
| GunnarHj | robert_ancell: Posting again: | 02:11 |
| GunnarHj | http://people.ubuntu.com/~gunnarhj/shell-guest-session.html#disable is about to make it to Ubuntu Help. Yesterday you mentioned your plan to break out guest session to a separate binary package. I just wanted to point out that doing so would not make much of a difference with respect to how easy/difficult it is to disable guest session. But maybe you have other reasons. | 02:11 |
| robert_ancell | GunnarHj, looks good | 02:12 |
| GunnarHj | robert_ancell: Tnx. | 02:13 |
| GunnarHj | robert_ancell: Are there other reasons for breaking out e.g. unity-guest-session.deb? | 02:21 |
| robert_ancell | GunnarHj, you might only want to have a unity guest session, and not a GNOME/KDE one. Each session might require different apparmor rules | 02:21 |
| GunnarHj | robert_ancell: Ok, I see. Just wanted to point it out, since you mentioned it in the context of how to disable the feature. | 02:23 |
| === Guest4645 is now known as LoganCloud | ||
| robert_ancell | RAOF, can I get you to move unity-control-center out of the new queue? | 03:57 |
| RAOF | robert_ancell: I've got the LP permissions required to do that, but I'm not an archive admin. Is it in the NEW queue because it's a new package, needing AA attention? | 03:58 |
| infinity | Sure looks like it. | 03:59 |
| robert_ancell | RAOF, yeah it's a new package. Are you not an AA anymore? | 04:00 |
| infinity | robert_ancell: Which version of g-c-c is this forked from, so I can do a lazy review? | 04:00 |
| robert_ancell | infinity, 3.6 | 04:00 |
| RAOF | robert_ancell: I've never been an AA; I got the launchpad permissions so that SRUs weren't hugely annoying. | 04:00 |
| robert_ancell | it's basically 3.6.3-0ubuntu49 with all the patches applied | 04:01 |
| robert_ancell | RAOF, oh, you're a fake ~ubuntu-archive member :) | 04:01 |
| infinity | ... with all the patches applied? You mean you've changed the source format, so I can't diff it? :P | 04:01 |
| RAOF | robert_ancell: Correct. My membership of ~ubuntu-archive just a technical workaround :) | 04:02 |
| robert_ancell | I also branched from the 3.6 upstream branch, so it has a few small bug fixes | 04:02 |
| robert_ancell | and then a bunch-o-renaming | 04:02 |
| infinity | RAOF: You shoudn't need to be in ~ubuntu-archive to do SRUs. | 04:02 |
| RAOF | infinity: I do if I want to accept SRUs from the NEW queue, right? | 04:03 |
| === Logan_ is now known as GroupContact | ||
| RAOF | (These exist, particularly in X land) | 04:03 |
| infinity | RAOF: Oh, possibly, yes. Silly LTS backports. | 04:03 |
| infinity | robert_ancell: Well, congrats on making this much harder to audit. :P | 04:04 |
| robert_ancell | infinity, yeah, it wont be trivial :) | 04:04 |
| infinity | (It could have been trivial if you'd just taken the g-c-c package and done the renames and pulled the upstream fixes you wanted...) | 04:04 |
| robert_ancell | infinity, then it would have been harder to merge from upstream though right? | 04:05 |
| infinity | Dunno. That depends on how you work, I guess. The desktop team clearly wasn't having issues with the package as it was. | 04:06 |
| infinity | Anyhow, you also ditched the entire changelog, which is a bit silly. | 04:06 |
| robert_ancell | Does it matter? | 04:07 |
| infinity | I suppose someone might have wanted to know the history of all the patches that you pre-applied... | 04:08 |
| robert_ancell | I added the info from the changelog to the commit messages | 04:09 |
| infinity | robert_ancell: I guess there are Reasons(tm) why we can't use g-c-c 3.8/3.10/whatever? | 04:14 |
| robert_ancell | infinity, yes, the newer versions have quite major changes that would take a lot of work for us to integrate and may not contain things we want. Since we're working on a Unity 8 replacement it's best to just hold with what we have and unblock the Ubuntu GNOME people to use the newer versions | 04:15 |
| infinity | robert_ancell: Fair enough. Accepted it. | 04:16 |
| robert_ancell | thanks! | 04:16 |
| Mirv | robotfuel: pong | 04:46 |
| === GroupContact is now known as Logan_ | ||
| === apachelogger_ is now known as apachelogger | ||
| pitti | Good morning | 05:51 |
| pitti | cjwatson: ah, many thanks for the varargs umockdev fix! nice that everything else works | 05:53 |
| pitti | cjwatson: I'll fix it upstream and in Debian, too | 05:53 |
| pitti | dobey: hm, last night the ubuntuone autopkgtest stack started failing, all on this weird "Failed to parse argument: ['order', 'o', None, 'Specify..." error; does that ring a bell? | 06:09 |
| === Sp4rKy_ is now known as Sp4rKy | ||
| === zigo_ is now known as zigo | ||
| RAOF | Huh. Why does libc6-armhf-cross install all its files in /usr/arm-linux-gnueabihf/lib/*.so, rather than /usr/lib/arm-linux-gnueabihf/*.so? | 07:36 |
| mlankhorst | RAOF: I'm guessing because you should install libc6:armhf if you want the latter | 07:37 |
| RAOF | mlankhorst: I guess | 07:37 |
| doko_ | the guess is correct | 07:37 |
| === doko_ is now known as doko | ||
| === Sp4rKy is now known as Sp4rKy_ | ||
| === Sp4rKy_ is now known as Sp4rKy | ||
| RAOF | Um... this is a new and shiny one on me: “/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0 inside” | 07:56 |
| RAOF | Oh, that's moderately terrible. | 07:59 |
| dholbach | good morning | 07:59 |
| mlankhorst | RAOF: should use the multiarch -dev packages I think :P | 08:02 |
| RAOF | mlankhorst: No; in this case what I need to not do is correctly specify the library link paths. | 08:03 |
| mlankhorst | ah | 08:03 |
| mlankhorst | bad raof :P | 08:03 |
| doko | RAOF, what are you trying to do? | 08:03 |
| RAOF | Because if I correctly specify the library link paths, then it picks up a broken ld script. | 08:03 |
| RAOF | doko: Link against libudev for the Mir android cross-compile. | 08:04 |
| doko | and libc:armhf is installed? | 08:04 |
| doko | libc6-dev:armhf | 08:04 |
| PublicStaticVoid | Devided to test 14.04 since 13.10 was giving me so many issues | 08:07 |
| PublicStaticVoid | Because of newer hardware | 08:07 |
| RAOF | doko: What's happening is that we unpack a bunch of debs into a kinda-sorta-but-not-really armhf chroot; if the build correctly specifies the linker paths, then the unpacked libc.so linker script gets used, which embeds an incorrect path. | 08:07 |
| RAOF | doko: This could be sorted much more simply by using an *actual* chroot. | 08:07 |
| mlankhorst | or no chroot, and using the multiarch dev packages.. | 08:08 |
| PublicStaticVoid | 13.10 didnt have cideo or udio working out of the box for me but so fat 14.04 has been perfect | 08:08 |
| RAOF | doko: Also, installing libc6-dev:armhf seems to want to remove such minor packages as g++, gcc, and multiarch-support | 08:08 |
| mlankhorst | who needs that, anyway | 08:08 |
| RAOF | mlankhorst: That would also work, but I'm pretty sure that at least some of our dependencies don't have multiarched dev packages. | 08:08 |
| RAOF | Anyway, it's dinner time here, and I've found what's wrong. | 08:09 |
| doko | RAOF, the installation works fine here | 08:09 |
| doko | is -proposed enabled? | 08:10 |
| PublicStaticVoid | Guys are really working hard on tablet support huh? | 08:10 |
| infinity | RAOF: If installing libc6-dev:armhf wants to remove multiarch-support:amd64, you have version skew between armhf and amd64. | 08:10 |
| infinity | RAOF: Or you're not actually using multiarch correctly... | 08:11 |
| PublicStaticVoid | Tell me what will be a good Tablet to purchase for Ubuntu early? | 08:11 |
| PublicStaticVoid | You guys testing on anything specific? | 08:11 |
| infinity | PublicStaticVoid: You probably want #ubuntu-touch | 08:11 |
| mlankhorst | doko: it recommends installing gcc:armhf | 08:12 |
| infinity | mlankhorst: apt-get --no-install-recommends? | 08:12 |
| mlankhorst | linux-libc-dev:armhf fails | 08:12 |
| doko | mlankhorst, you should disable installation of recommends for this kind of thing | 08:12 |
| mlankhorst | Replaces: dvb-dev (<< 1.0.1-6), libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), libdrm-dev, linux-kernel-headers | 08:13 |
| mlankhorst | Provides: linux-kernel-headers | 08:13 |
| mlankhorst | Conflicts: amd64-libs-dev (<= 1.1), dvb-dev (<< 1.0.1-6), libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), linux-kernel-headers | 08:13 |
| doko | mlankhorst, please start with a fresh chroot | 08:13 |
| PublicStaticVoid | infinity: I thought 14.04 was geared twrds x86/amd64 and armhf? | 08:13 |
| mlankhorst | doko: it attempts to uninstall a whole bunch of -dev packages anyway if I force linux-libc-dev:armhf | 08:14 |
| infinity | mlankhorst: It's multi-arch:same, the provides/conflicts don't matter, you can have both installed. | 08:14 |
| infinity | mlankhorst: Just like any library. | 08:14 |
| doko | mlankhorst, that's expected | 08:14 |
| infinity | (Again, unless you have version skew) | 08:14 |
| mlankhorst | hm *tries in a pbuilder chroot* | 08:14 |
| PublicStaticVoid | Touch isnt even close to desktp implmentations.. | 08:15 |
| infinity | PublicStaticVoid: 6 architectures, even, but you were asking about tablets, hence you want #-touch. | 08:15 |
| pitti | doko: wrt. https://launchpad.net/ubuntu/+source/libtool/2.4.2-1.6ubuntu1, this breaks package builds which b-dep on libtool | 08:16 |
| mlankhorst | fine I'll try in a pbuilder.. | 08:16 |
| pitti | doko: I think libtool needs to Depends: on libtool-bin, not just recommends | 08:16 |
| PublicStaticVoid | armhf is a tablet/phone arch lol but okay | 08:16 |
| PublicStaticVoid | I know where touch i at | 08:16 |
| PublicStaticVoid | is | 08:16 |
| infinity | pitti: The whole point was that most packages that build-dep on libtool do so for the aclocal bits, not the libtool binary. | 08:16 |
| doko | pitti, expected | 08:16 |
| PublicStaticVoid | Not what I am interested in | 08:16 |
| doko | pitti, if you see some, please tell me | 08:17 |
| pitti | infinity: eh? "libtool" is not libtool any more? | 08:17 |
| pitti | doko: I just ran into glom's | 08:17 |
| doko | pitti, libtoolize is used | 08:17 |
| infinity | pitti: Personally, I think the package split is pointless, and there's no reason for people to expect libtool to be cross-happy, but whatever. | 08:17 |
| mlankhorst | The following packages will be REMOVED: | 08:17 |
| mlankhorst | build-essential g++ g++-4.8 libc6-dev libstdc++-4.8-dev linux-libc-dev | 08:17 |
| mlankhorst | The following NEW packages will be installed: | 08:17 |
| mlankhorst | gcc-4.8-base:armhf libc6:armhf libc6-dev:armhf libgcc1:armhf linux-libc-dev:armhf | 08:17 |
| mlankhorst | in a fresh pbuilder chroot :p | 08:17 |
| pitti | doko, infinity: so can we fix libtool properly, or hunt down the FTBFS? for the latter, should they now b-dep on libtool-bin? | 08:18 |
| pitti | I'd really want to avoid that as that's not in Debian | 08:18 |
| infinity | I think the proper fix is just marking it M-A:allowed and undoing the split. | 08:18 |
| PublicStaticVoid | You guys are developing 14.04 right? | 08:18 |
| pitti | nor is a libtool-bin b-dep backportable | 08:19 |
| mlankhorst | doko: so should linux-libc-dev:armhf be coinstallable between amd64 and armhf? | 08:19 |
| mlankhorst | hm seems to not remove linux-libc-dev:amd64 at least | 08:19 |
| mlankhorst | weird | 08:19 |
| doko | pitti, was talking with Q_ about that, I'll look at glom what it is trying to do | 08:19 |
| doko | mlankhorst, yes | 08:19 |
| infinity | mlankhorst: They're all coinstallable for me just fine. | 08:19 |
| pitti | config.status: executing po/stamp-it commands | 08:20 |
| pitti | if [ -e ./libtool ]; then cp -f /usr/bin/libtool ./libtool; fi | 08:20 |
| pitti | cp: cannot stat '/usr/bin/libtool': No such file or directory | 08:20 |
| infinity | mlankhorst: http://paste.ubuntu.com/6713641/ | 08:20 |
| mlankhorst | infinity: I did pbuilder-dist trusty update; pbuilder-dist trusty login; http://paste.debian.net/74936/ | 08:20 |
| PublicStaticVoid | Just really wanted to tell you guys when I installed 14.04 the partitioner did not see anything but free space.. read the partition table incorrectly... | 08:20 |
| mlankhorst | dpkg --add-architecture armhf; apt-get update; apt-get install libc6-dev:armhf :s | 08:21 |
| doko | pitti, looking at it | 08:21 |
| infinity | mlankhorst: Ahh, you hadn't added the arch? | 08:21 |
| infinity | doko: I still think we should just back this out. No one's convinced me of the sanity of the split. | 08:21 |
| mlankhorst | infinity: that is the corect way to add the arch right? | 08:21 |
| mlankhorst | and my sources.list is correct too? | 08:22 |
| pitti | doko: I can't actually find that code ([ -e ./libtool ] etc.) in glom's source package, I suppose that's run from some intermediate program; investigating | 08:22 |
| doko | infinity, well, it is doing the wrong things for cross builds. not that I would care about glom | 08:22 |
| infinity | doko: People having bugs in cross-builds isn't a reason to do this. | 08:23 |
| infinity | doko: Packages with CC=gcc also cross incorrectly. That's a packaging bug, not a toolchain bug. | 08:23 |
| mlankhorst | odd, wonder how the version got skewed | 08:24 |
| mlankhorst | nm I have -proposed in trusty | 08:25 |
| pitti | doko: ah, it's from /usr/share/cdbs/1/class/autotools.mk | 08:25 |
| mlankhorst | false alarm | 08:25 |
| infinity | doko: It would DTRT if you made it Multi-Arch:allowed instead of foreign. | 08:25 |
| infinity | doko: See the table at https://wiki.ubuntu.com/MultiarchCross | 08:25 |
| pitti | glom does "DEB_AUTO_UPDATE_LIBTOOL := post" | 08:25 |
| mlankhorst | RAOF: downgrade linux-libc-dev to 3.12.0-7.15 :P | 08:25 |
| pitti | doko: (no idea whether that makes sense, but it's the way it is in the package ATM) | 08:26 |
| infinity | doko: That would get you exactly the behaviour you're after. Default to libtool:HOST_ARCH for regular build-deps, and get you libtool:BUILD_ARCH if you demand :native | 08:26 |
| infinity | mlankhorst: Erm, if you have proposed for both arches, it shouldn't be skewed. | 08:26 |
| mlankhorst | infinity: yeah but i disabled proposed for testing :s | 08:27 |
| === elky_ is now known as elky | ||
| mlankhorst | ok i guess it works just fine | 08:28 |
| mlankhorst | as long as i don't try to coinstall gstreamer0.10-plugins | 08:29 |
| infinity | doko: Sent a followup to the Debian bug on the matter. Will you be annoyed if I undo the split and switch the M-A header in Ubuntu? | 08:31 |
| infinity | I see zero point in creating fallout from this, or in adding new build-deps that we didn't have before. | 08:32 |
| doko | infinity, well, then please upload first a version to ubuntu-toolchain-r/test which supersedes your reversion | 08:32 |
| infinity | doko: Err, what? | 08:32 |
| infinity | doko: Why? Why would you care what fails to build without /usr/bin/libtool if we're not removing it? That'll just create a bunch of false positives that people will go "fixing" when they shouldn't. | 08:34 |
| seb128 | hum | 09:12 |
| zyga | hey | 09:13 |
| seb128 | virtualbox stopped working for me in trusty (was working before holidays) | 09:13 |
| * zyga wonders how to understand adt failures by looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-plainbox/ | 09:13 | |
| seb128 | " | 09:13 |
| seb128 | The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. " | 09:13 |
| seb128 | is that a known issue? | 09:13 |
| pitti | zyga: what in particular? | 09:13 |
| pitti | zyga: it seems the test doesn't output anything useful on failure, that ought to be fixed | 09:14 |
| pitti | zyga: i. e. printing an useful error message | 09:14 |
| zyga | pitti: the way DEP8 tests are defined I don't know how to provide any useful log file where I see what failed | 09:14 |
| pitti | zyga: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-plainbox/7/ARCH=i386,label=adt/console is the full output | 09:14 |
| zyga | pitti: how can I do that if all output must be RFC822? | 09:14 |
| pitti | zyga: not sure what you mean with RFC822, but it doesn't matter to autopkgtest | 09:14 |
| pitti | zyga: success == exit code 0 and no stderr (unless you define "Restrictions: allow-stderr") | 09:15 |
| zyga | pitti: ohhh/ | 09:15 |
| seb128 | apw, hey, any idea about my virtualbox issue? (I see you update it on monday) | 09:15 |
| zyga | pitti: I need to re-read dep8 testing spec, I read a guide that claimed otherwise | 09:15 |
| zyga | pitti: this is how my tests look like now http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/unit-tests?view=markup | 09:15 |
| pitti | zyga: ah, I guess you really want to drop the >/dev/null at least | 09:16 |
| pitti | zyga: if your test is *expected* to have stderr output, the "allow-stderr" is usually cleaner/easier, but 2>&1 works as well | 09:16 |
| zyga | pitti: so basically, can I drop the /dev/nul redirects and redirect stderr to stdout (logs sometimes go to stderr), as long as the exit code is okay, everything will work? | 09:16 |
| zyga | pitti: allow-stderr should go into control? | 09:16 |
| zyga | http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/control?view=markup | 09:17 |
| zyga | pitti: like 'allow-stderr: yes' | 09:17 |
| pitti | zyga: no, "Restrictions: allow-stderr" | 09:18 |
| zyga | ah, ok | 09:18 |
| zyga | pitti: and that applies to all tests? | 09:18 |
| pitti | zyga: only to the tests in that particular Tests: stanza | 09:18 |
| pitti | zyga: btw, "Depends: @" is the default, so if you don't need any additional deps you can just drop the Depends: line (just FYI, it's fine if you keep it) | 09:18 |
| pitti | zyga: @ expands to "all binaries from my source package" | 09:19 |
| zyga | pitti: yeah but I cannot use @ | 09:19 |
| zyga | http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/control?r1=26961&view=log | 09:20 |
| zyga | pitti: some packages conflict with each other | 09:20 |
| pitti | zyga: ah, I see | 09:20 |
| pitti | zyga: nevermind then | 09:20 |
| apw | seb128, hmmm no, the change i made was a simple V > 3.13 ignore this line of code jobbie, for the 3.13 kernel dropping in now | 09:23 |
| apw | i can't say i have ever tested it with 3.12 at all | 09:23 |
| seb128 | apw, do you have any idea how to debug that? | 09:23 |
| apw | is that with 3.12? if so i would try 3.13 first | 09:24 |
| apw | as it did load there for me i think | 09:25 |
| zyga | pitti: is there a way to subscribe to adt failures | 09:27 |
| zyga | pitti: or file bugs on an upstream project / packaging? | 09:27 |
| pitti | zyga: adt failures are mailed to the last uploader | 09:28 |
| zyga | pitti: I haven't see any emails, that package is synced from debian where it was uploaded by my sponsor | 09:29 |
| zyga | pitti: does that qualify? | 09:29 |
| seb128 | apw, 3.11.0-13 is what I'm running it seems, seems like I cleaned out "linux" when remove the few Gbs of old kernels I had around ...getting a newer kernel now, let's see | 09:30 |
| seb128 | though it's 3.12 ... is 3.13 supposed to be in trusty? | 09:30 |
| infinity | seb128: 3.13 *just* got published to trusty-release, should hit mirrors in about 2 minutes. | 09:31 |
| seb128 | infinity, thanks | 09:31 |
| xnox | jtaylor: "supports shared libraries... no" means you want dh-autoreconf (manual, it's dh addon, or cdbs snippet) to perform full autoreconf, with a goal to have "libtoolize" executed to uploade libtool with ppc64el support. | 09:42 |
| xnox | jtaylor: oh, colin replied to you =) | 09:43 |
| zyga | pitti: auto-package-testing seems to use x86_64 even if you ask it to build i368 vm | 09:49 |
| zyga | pitti: is there a way to fix that easily? I'm on i386 machine | 09:49 |
| pitti | zyga: hm, it should default to the host arch, it doesn't? | 09:50 |
| pitti | jodh: did you see that test_conf_preload.sh | 09:58 |
| pitti | jodh: ... started failing in upstart's autopkgtest? | 09:58 |
| jodh | pitti: hmm - that code hasn't changed for a long time and the problem is not recreatable locally. Has the jenkins env changed somehow recently do you know? | 10:10 |
| pitti | jodh: the host might have gotten upgraded to saucy | 10:11 |
| * pitti tries locally | 10:11 | |
| zyga | I've patched adt-prepare-testbed to support i386 | 10:15 |
| pitti | zyga: what did you change? | 10:20 |
| pitti | jodh: I get exactly the same failure locally (trusty host, trusty VM, amd64) | 10:20 |
| diwic | seb128, hi! | 10:20 |
| seb128 | diwic, hey, happy new year! | 10:20 |
| zyga | pitti: http://paste.ubuntu.com/6714054/ | 10:21 |
| zyga | pitti: not sure if that's fully working yet, i386 boxes are slooow | 10:21 |
| diwic | seb128, same to you! Do you have time for a chat about the what-did-you-plug-in dialog? | 10:21 |
| pitti | zyga: you probably still need the -enable-kvm for i386, too | 10:22 |
| seb128 | diwic, yes | 10:22 |
| pitti | zyga: otherwise it'll be slow indeed | 10:22 |
| pitti | zyga: those were the days when "kvm" just DTRT.. :/ | 10:22 |
| zyga | hehe :) | 10:22 |
| diwic | seb128, so, the progress is that after a few rounds with upstream PulseAudio, I ended up redoing the implementation as a separate program. | 10:23 |
| diwic | seb128, my ambition is still to try to upstream it into 14.04 somehow, maybe into gnome-settings-deamon? (Or has that forked into ubuntu-settings-daemon?) | 10:23 |
| seb128 | diwic, maybe we should discuss that on #ubuntu-desktop (I think larsu was following last time we discussed it) | 10:24 |
| zyga | pitti: with a few more changes it seems to be on a course for success, I'll send you patches for adt once I'm done | 10:47 |
| pitti | zyga: thanks | 10:55 |
| pitti | jodh: I get the same failure in a plain schroot during package build | 10:55 |
| pitti | jodh: (sbuild -d trusty -A upstart_1.11-0ubuntu1.dsc) | 10:55 |
| jodh | pitti: I'm trying again with a fresh local env. | 10:55 |
| pitti | jodh: so, no VM required | 10:56 |
| pitti | hallyn: I tried your recipe; if=none succeeds (but doesn't actually give me a drive), but with if=virtio (as in people.canonical.com/~serge/qrt-qemu.diff) I get "Can't hot-add drive to type 7" | 11:07 |
| pitti | hallyn: so with if=none I get a lot of dmesg, but no new block device | 11:10 |
| pitti | hallyn, jibel: ah, seems I got it: | 11:17 |
| pitti | drive_add auto file=/home/martin-scratch/adt/disks/pristine-trusty-amd64-20140108_073545.img,if=none,id=pristinevm | 11:17 |
| pitti | device_add virtio-blk-pci,id=pristinevm,drive=pristinevm | 11:17 |
| === Ursinha is now known as Ursinha-afk | ||
| seb128 | hum | 11:24 |
| seb128 | who should be pinged if somebody "vandalize" bugs on launchpad? | 11:26 |
| seb128 | e.g https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1238266 | 11:26 |
| ubottu | Ubuntu bug 1238266 in file-roller (Ubuntu Saucy) ""Error setting owner: Operation not permitted" when extracting Eclipse in saucy" [High,Fix released] | 11:26 |
| seb128 | see the description | 11:26 |
| cjwatson | seb128: revert it and notify https://answers.launchpad.net/launchpad | 11:27 |
| cjwatson | (esp if you happen to have the description diff to hand) | 11:28 |
| seb128 | cjwatson, I've the diff in my launchpad emails yes | 11:28 |
| seb128 | cjwatson, thanks | 11:28 |
| directhex | xnox, Laney, ok. i don't think the archive will be made significantly worse by pushing 3.2.3 into trusty. there might be a few FTBFSes - those can be fixed in debian & synced (mostly due to a re-renamed pcfile) | 11:42 |
| jodh | pitti: the env now seems to use overlayfs, leading to => bug 882147. Upstart do have a "pre-test" which checks for overlayfs, but the decision was taken to not error message, we just display a waring... except that that message isn't being output, I think due to recent nih changes. | 11:43 |
| ubottu | bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress] https://launchpad.net/bugs/882147 | 11:43 |
| === _salem is now known as salem_ | ||
| pitti | jodh: how does overlayfs come into play when running "make check" during build? | 11:43 |
| xnox | pitti: badly. | 11:43 |
| xnox | pitti: ditto eatmydata | 11:43 |
| jodh | pitti: the test in question needs to test that upstart can detect file changes using inotify... but inotify doesn't work with overlayfs. | 11:44 |
| pitti | I don't use overlayfs with my trusty schroot, it's a tarball | 11:44 |
| pitti | nor does run-adt-test | 11:44 |
| Laney | directhex: alright then | 11:44 |
| pitti | I have overlayfs with my precise/sid schroots (as I use them more often), all others are tarball | 11:44 |
| Laney | I think there's an archive rebuild coming up which should catch stuff | 11:44 |
| Laney | also we should finish dbus#2 at some point *cough* | 11:45 |
| jodh | pitti: auto-package-testing no longer works for me - unable to login to the kvm instance. Can you get any more details from that failing test in your env whilst I try to recreate with a modified schroot then? | 11:45 |
| pitti | jodh: does it hang on "making pristine VM available"? I just fixed that, please pull (recent qemu changes) | 11:45 |
| xnox | Laney: as long as mono makes it into -release before archive rebuild is kicked off. | 11:46 |
| pitti | jodh: but I think it's faster to debug in schroot or plain trusty | 11:46 |
| jodh | pitti: yes, love that bleeding edge :) | 11:46 |
| directhex | Laney, i also figured out how to make Ben work against Ubuntu, so i can keep an eye on things. it still totally fucks up the dependency ordering for mono stuff, mind you. | 11:46 |
| jodh | pitti: plain trusty works fine for me as originally noted :) | 11:46 |
| Laney | directhex: we already have ben | 11:46 |
| Laney | http://people.canonical.com/~ubuntu-archive/transitions/ | 11:46 |
| directhex | Laney, i mean locally, not needing coordination with ubuntu-archive | 11:47 |
| Laney | I can commit a .ben file if you want | 11:47 |
| xnox | Laney: yes please! | 11:47 |
| pitti | jodh: trying to build directly on my trusty now | 11:47 |
| Laney | what needs tracking here? | 11:47 |
| directhex | Laney, depending on corlib 4.5 is a measure of "was it definitely built using the new mono", i.e. it guarantees that the package doesn't ftbfs | 11:48 |
| directhex | Laney, strictly that's a transition. it's not a problem if packages aren't rebuilt (they're executed with 4.5 corlib regardless of the dependency) | 11:49 |
| Laney | ah, you mean like that - ok | 11:49 |
| directhex | i've done a handful of test rebuilds in a ppa | 11:49 |
| pitti | jodh: same thing on my plain trusty workstation | 11:49 |
| Laney | we should get much the same data from the archive rebuild then | 11:49 |
| xnox | jamespage: i only approve scons usage with clotted cream, honey & jam. all other usage of scons, is confusing and should be banned =) | 11:49 |
| Laney | feel free to go ahead if your initial tests look good | 11:49 |
| pitti | jodh: it doesn't seem to care much about VM, schroot, overlays, etc.; it consistently fails the same way everywhere I run it | 11:50 |
| jamespage | xnox, +1 | 11:50 |
| pitti | jodh: ah, hang on, that was a different failure (due to my non-English locale) | 11:51 |
| cjwatson | doko: sqlite build failure - given that you've merged tcl8.5 from experimental, could you please also look into tcltk-defaults/experimental? Having one but not the other means we don't have tclsh, which is kind of bad | 11:51 |
| cjwatson | doko: (sqlite's build-deps may still need to be tweaked, but I'd like to see tcltk-defaults updated first | 11:51 |
| cjwatson | ) | 11:51 |
| doko | cjohnston, ohh, I have a tclsh ... | 11:52 |
| doko | cjwatson even | 11:52 |
| cjwatson | doko: tcl8.5 and tcltk-defaults now have different ideas about whether it's supposed to be managed by alternatives or symlinks | 11:52 |
| doko | the merge wasn't very appealing :-/ | 11:52 |
| cjwatson | doko: this seems unlikely to end well - I think they need to be in sync | 11:52 |
| doko | yeah, will have to look ... | 11:53 |
| cjwatson | directhex: the ben package in trusty is basically what we use | 11:53 |
| pitti | jodh: ok, a local build succeeds; so it fails in schroot during package build and in run-adt-test | 11:53 |
| cjwatson | directhex: together with lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs | 11:53 |
| directhex | cjwatson, yeah, had to train myself on the syntax to run it on my desktop. seems the package in saucy uses sid sources by default | 11:54 |
| cjwatson | directhex: yeah, the package in saucy won't be very easy to get to work. I did the big merge with our previous fork in trusty | 11:54 |
| cjwatson | so it now has an Ubuntu template there | 11:55 |
| cjwatson | (not a big bag of fun since I don't speak ocaml) | 11:55 |
| jodh | pitti: no error in a current trusty schroot sans overlayfs. | 11:59 |
| pitti | jodh: hm, I wonder what's different on mine then; are you running trusty or saucy on your workstation? | 12:01 |
| pitti | jodh: (perhaps newer kernel or so?) | 12:01 |
| jodh | pitti: workstation is trusty. One difference is that I'm running 32-bit. | 12:01 |
| xnox | Laney: sudo didn't make a difference.... and adb launches bash as a login shell, so i'd expect it to have proper environment, but it doesn't =( | 12:02 |
| jodh | pitti: kernel=3.12.0-7-generic | 12:03 |
| Laney | xnox: I don't really know what controls whether pam is run or not :( | 12:04 |
| Laney | Maybe you can get away with sourcing the file ... | 12:05 |
| pitti | jodh: same here, so maybe i386 vs. amd64? | 12:05 |
| pitti | jodh: I built in an i386 schroot, but on amd64 host | 12:05 |
| jodh | pitti: hmm - but jenkins shows the failure on 32+64-bit. | 12:08 |
| cjwatson | jodh: 32-bit or 64-bit kernel? | 12:16 |
| cjwatson | jodh: jenkins might well be running everything on a 64-bit kernel even in the case of 32-bit tests | 12:17 |
| zyga | pitti: is there a way to control the timout of prepare-testbed without patching packages installed within the VM? | 12:23 |
| xnox | cjwatson: can click-user-hooks be racy? ocassionally emulator first boot get stuck with click-user-hooks not terminating and thus unity8 not starting with the following in the log http://paste.ubuntu.com/6714604/ | 12:43 |
| === Sweetsha1k is now known as Sweetshark | ||
| cjwatson | xnox: not afaik | 12:47 |
| cjwatson | xnox: I'm pretty sure this is the fault of some particular hook, not of the system in general | 12:47 |
| xnox | cjwatson: I see. How would I go debugging which hooks are running / failing / getting stuck ? Well I guess i should just follow the exec trails. | 12:51 |
| cjwatson | xnox: when I last looked at this there was one hook that really stood out as running for ages, easily visible using ps | 12:52 |
| cjwatson | I forget what it was called | 12:52 |
| cjwatson | or you could hack click hook to be chatty on stderr | 12:53 |
| pitti | cjwatson, jodh: the VMs have the "right" kernel, but qemu runs on an amd64 host | 12:59 |
| pitti | jodh: but, I get the failure in an i386 schroot and success on plain amd64 trusty, i. e. the other way round | 13:00 |
| pitti | zyga: not that I know of; why is it so slow for you, not using kvm? | 13:00 |
| zyga | pitti: i386 on atom | 13:02 |
| zyga | pitti: it's also too slow when you are on a particularly slow link | 13:02 |
| zyga | pitti: I'd vote for making it a parameter just like apt proxy | 13:02 |
| pitti | zyga: oh, atom doesn't do kvm either | 13:02 |
| zyga | pitti: I also bet it's too slow on armhf on small boards | 13:03 |
| zyga | pitti: IIRC some models do but mine does not | 13:03 |
| pitti | yeah, we don't run qemu on arm, way too slow | 13:03 |
| zyga | pitti: lxc I presume? | 13:03 |
| pitti | zyga: we don't run autopkgtests at all for arm ATM; we had done so for a while (on real iron, with reinstalling every time), but way too brittle | 13:04 |
| pitti | zyga: on such hardware (atom/arm) you are probably better off with the schroot or lxc runners rather than using run-adt-test | 13:05 |
| zyga | pitti: yeah, I know how hard that is from my LAVA days | 13:05 |
| pitti | but schroot/lxc don't provide sufficient virtualization for many tests | 13:06 |
| zyga | pitti: really? | 13:06 |
| rbasak | KVM on ARM isn't too far away now. | 13:06 |
| zyga | pitti: did you run into problems? | 13:06 |
| rbasak | It basically already works, AIUI - we just haven't got it fully upstreamed and in distro. | 13:06 |
| zyga | pitti: isn't it ready yet? on A15? | 13:06 |
| pitti | zyga: for things like upstart, udisks, gvfs, network-manager, etc. | 13:07 |
| pitti | zyga: i. e. everything which fiddles with devices or other low-level things | 13:07 |
| zyga | pitti: ah, I see | 13:07 |
| zyga | pitti: I thought lxc could run upstart tests | 13:08 |
| pitti | rbasak: would that work on the G4? or only on the big calxeda boxes? | 13:08 |
| rbasak | What's a G4? | 13:08 |
| zyga | pitti: on the other hand, I wonder if it's right for stuff like udisks to require full vms to run their testing | 13:08 |
| rbasak | It should in theory work on any A15. | 13:08 |
| pitti | zyga: perhaps; I'm not sure with upstart | 13:08 |
| pitti | rbasak: google nexus 4, sorry | 13:08 |
| pitti | (i. e. the phone that we support) | 13:08 |
| * zyga thougth about ppc g4 | 13:08 | |
| zyga | pitti: I just got my hands on oldish ppc with g4 and 1GB ddr, I'll slap server on it and see if I can run anything | 13:09 |
| pitti | zyga: for most tests they are just fine; I run a lot of them in the schroot runner, which make things really fast | 13:09 |
| rbasak | I'm not sure. /proc/cpuinfo might tell you, but I don't recall what the flag is right now. | 13:10 |
| zyga | pitti: ohh, schroot runner? where is it? | 13:10 |
| zyga | pitti: I only see run.lxc | 13:10 |
| pitti | zyga: it's part of autopkgtest | 13:10 |
| zyga | pitti: the project or the package? | 13:10 |
| pitti | $ adt-run -B python-boto_2.20.1-2.dsc --- adt-virt-schroot sid | 13:10 |
| pitti | something like that | 13:10 |
| pitti | zyga: in the package | 13:10 |
| zyga | pitti: thanks | 13:11 |
| pitti | zyga: for CI we use adt-virt-null in a VM (as we don't yet have an adt-virt-qemu, which would arguably be better) | 13:11 |
| zyga | pitti: I tried to run tests of a bunch of locally built packages but I kept hitting errors | 13:11 |
| pitti | zyga: you can use -null on your workstation for tests that don't damage your system, or -schroot or rbasak's nice -lxc runner | 13:11 |
| zyga | pitti: which works not that great if you try to test a fix yourself | 13:11 |
| zyga | pitti: is that all packaged or should I keep using source of lp:auto-package-testing? | 13:12 |
| pitti | but most often I just use run-adt-test with "-sU", as it's very fast on my system (I have apt-cacher-ng configured) | 13:12 |
| pitti | zyga: adt-run and adt-virt-* are from the autopkgtest package (which we use in production) | 13:12 |
| * zyga tries | 13:13 | |
| pitti | zyga: lp:a-p-t just has the prepare-testbed and run-adt-test wrappers, which basically start a VM, run adt-run adt-virt-null in that VM, and copy back the results | 13:13 |
| pitti | kind of inside out, but that's what it is right now | 13:13 |
| zyga | pitti: ok, so with adt-run itself, how do I test a *.deb I just built? | 13:14 |
| zyga | pitti: or with a source tree | 13:14 |
| zyga | pitti: that I did with something like svn-buildpackage --svn-export | 13:14 |
| pitti | zyga: do you want to test the binaries from the archive, or actually your locally built debs? | 13:14 |
| === Ursinha-afk is now known as Ursinha | ||
| zyga | pitti: my locally built fixes | 13:15 |
| zyga | pitti: specifically I want to fix something that is in the archive, broken, stuck in -proposed | 13:15 |
| pitti | zyga: adt-run --built-tree=. --binary foo1.deb --binary foo2.deb ... --- adt-virt-null | 13:16 |
| pitti | (for a built source tree), or | 13:16 |
| pitti | adt-run foo_*.dsc --binary foo1.deb --binary foo2.deb ... --- adt-virt-null | 13:16 |
| pitti | for a source package | 13:16 |
| zyga | pitti: thanks, let me try that | 13:16 |
| pitti | or use adt-virt-schroot <schroot name>, or adt-virt-lxc --ephemeral <container> | 13:16 |
| zyga | pitti: you should really blog about that more often, I keep finding useless docs when I google for adt help | 13:17 |
| zyga | pitti: basically blogging this log is probably best docs on adt that I found | 13:17 |
| pitti | well, the man page is supposed to explain all that | 13:17 |
| jibel | ev, there have been several crashes of ubiquity (libautopilot-gtk actually) uploaded to errors.ubuntu.com but they are not retraced. Would you know why? | 13:27 |
| jibel | ev, https://errors.ubuntu.com/problem/8ff8c9bfa3317b35d4a1af984e0e4208acd7af42 is the crash | 13:27 |
| pitti | ev: did errors get an update to its apt sources for the trusty ddebs? | 13:27 |
| ev | jibel: that's strange - that page indicates a retraced crash, but isn't showing the stack trace for it | 13:29 |
| ev | looks like a bug | 13:29 |
| ev | can you open one against lp:errors pointing at that? | 13:29 |
| jibel | ev, sure | 13:30 |
| ev | pitti: yes - lp:daisy retracer/config | 13:30 |
| ev | just confirming that revno is deployed | 13:31 |
| ev | yes, it is (r396 is deployed) | 13:32 |
| jibel | ev, bug 1267112 | 13:34 |
| ubottu | bug 1267112 in Errors "errors indicates a retraced crash but isn't showing a stack trace" [Undecided,New] https://launchpad.net/bugs/1267112 | 13:34 |
| zyga | re | 13:34 |
| zyga | pitti: the problem I found is that I didn't even install autopkgtests as a package, I followed earlier google hits and used the branch | 13:35 |
| pitti | zyga: you can do that as well; I added a "run-from-checkout" script recently for that | 13:36 |
| pitti | (that's what I use for autopkgtest development, and the test suite calls that) | 13:36 |
| ev | thanks | 13:39 |
| xnox | slangasek: I'd like to see your thoughts on bug #1267117 | 13:47 |
| ubottu | bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117 | 13:47 |
| infinity | doko: Why do you intentionally want more build failures in the rebuild test than you'd get in the archive? :P | 14:11 |
| === kfunk_ is now known as kfunk | ||
| === elopio_ is now known as elopio | ||
| hallyn | pitti: ah, i originally had the drive=, but had gotten an error msg from it. thanks. | 14:25 |
| stgraber | @pilot in | 14:25 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber | ||
| hallyn | pitti: so the two changes are 'drive_add auto" and add "drive=" to end of device_add right? | 14:25 |
| pitti | hallyn: I think the "auto" doesn't mean anything actually; I never saw a difference, you can put 0 or 2 or "dummy" there | 14:27 |
| pitti | hallyn: and drive=, yes | 14:27 |
| hallyn | and you're using virtio-blk-pci instead of virtio-scsi-pci | 14:28 |
| pitti | *nod* | 14:28 |
| pitti | hallyn: http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/269 is the final commit | 14:29 |
| pitti | hallyn: the id= is probably optional for device_add, but it's useful if you want to remove it again (drive_del pristinevm / device_del pristinevm) | 14:29 |
| hallyn | pitti: you needed the drive_del before device_del? | 14:30 |
| hallyn | hm, http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01381.html suggests the virtio-blk-pci and virtio-scsi-pci should be close. <shrug> | 14:31 |
| hallyn | this all needs documentation! | 14:31 |
| pitti | hallyn: I don't need it in the branch, I just used it for interactive experimentation until I figured out an invocation that works (so that I don't need to keep relaunching qemu) | 14:31 |
| hallyn | rharper: ^ is all this documented somewhere? | 14:31 |
| hallyn | pitti: thanks :) I never use this myself, just want to make sure this isn't forgotten before qa-regression-tests gets updated | 14:32 |
| pitti | I didn't find any documentation for it, just outdated docs for pci_add | 14:32 |
| hallyn | pitti: did you have any errors using virtio-scsi-pci? | 14:33 |
| tseliot | cjwatson, infinity: if I wanted to make a boot option from live-installer permanent (as in to be applied on the installed system) would I have to modify the grub package? Or would I have other options? | 14:33 |
| pitti | hallyn: well, not in dmesg, but that didn't create any block device | 14:33 |
| pitti | hallyn: or I didn't shuffle the options hard enough to make it work | 14:33 |
| hallyn | pitti: maybe that needed a cache= option. | 14:34 |
| hallyn | thanks pitti | 14:34 |
| cjwatson | tseliot: you don't have to touch grub. just put the option after the "--" argument on the command line used when booting the installer and it should be copied to the target system | 14:34 |
| pitti | hallyn: perhaps; TBH I don't understand what these two are doing, or what the difference is; I was quite happy that I found a working solution at last | 14:35 |
| tseliot | cjwatson: that's great news, thanks! | 14:36 |
| rharper | hallyn: reading... | 14:37 |
| dobey | pitti: no, it doesn't sound familiar. will have a look at the logs | 14:42 |
| zul | doko: ping kombu is ftbfs because python-beanstalkc is not in main https://launchpad.net/ubuntu/+source/kombu/3.0.7-1ubuntu1/+build/5421716 (MIR for python-beanstalkchttps://bugs.launchpad.net/ubuntu/+source/beanstalkc/+bug/1252372) | 14:42 |
| rharper | hallyn: what's the quesiton on usage of virtio-blk vs. virtio-scsi ? | 14:42 |
| ubottu | Ubuntu bug 1252372 in beanstalkc (Ubuntu) "[MIR] beanstalkc" [Undecided,Fix committed] | 14:42 |
| doko | zul, https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bug/1252374 | 14:43 |
| ubottu | Ubuntu bug 1252374 in beanstalkd (Ubuntu) "[MIR] beanstalkd" [Undecided,New] | 14:43 |
| dobey | pitti: was there a new twisted upload yesterday? that would have caused the tests to be run, and could result in the failure | 14:44 |
| pitti | dobey: yes, there was: https://launchpad.net/ubuntu/+source/twisted/13.2.0-1ubuntu1 | 14:44 |
| dobey | pitti: all i got was failure e-mails. it didn't tell me what upload caused the tests to run in the first place | 14:44 |
| pitti | dobey: yes, indeed; the notification emails don't say that; jibel, is there some way to put the reason in there? (i. e. "triggered by dependency libfoo") | 14:45 |
| zul | doko: cool | 14:46 |
| pitti | dobey: usually how it's supposed to work is that the new twisted (assuming that's what caused the regression) is held in proposed until the failures are fixed | 14:46 |
| dobey | pitti, jibel: i thought the errors were supposed to go to the person that uploaded the package that caused the tests to run, anyway? | 14:46 |
| pitti | dobey: but the ubuntuone packages don't directly depend on twisted, so this didn't happen | 14:46 |
| === NCommander is now known as Guest55180 | ||
| dobey | pitti: well, at least a couple of them depend directly on twisted | 14:47 |
| pitti | dobey: ideally, yes (they should go to both IMHO), but it's not quite that clever yet | 14:47 |
| dobey | pitti: hrmm, why wasn't twisted held in proposed? :-/ | 14:49 |
| hallyn | rharper: oh my main question is whether the drive_add+device_add is meticulously documented somewhere so someone can make sane decisions about arguments to pass | 14:49 |
| hallyn | (as opposed to looking for random examples and trying random combinations) | 14:50 |
| robotfuel | Mirv: ping | 14:50 |
| hallyn | i assume not, but also assumed that if there were you'd know | 14:50 |
| pitti | dobey: that's what I ask myself | 14:50 |
| rharper | hallyn: best place to see usage is in libvirt | 14:51 |
| hallyn | lol | 14:51 |
| hallyn | rharper: thanks. | 14:52 |
| rharper | hallyn: iirc, you need both, you want to define a new device (pci for virtio-blk) and then apply a drive on top of the device | 14:52 |
| rharper | qemu separates the guest visibile (pci device) from the drive (qemu side) | 14:52 |
| hallyn | rharper: yes, i mean things like the first arg to drive_add, | 14:52 |
| rharper | the id= parameter is used to tie the two together | 14:52 |
| hallyn | which pitti found can be any random string and *seems* to do nothing | 14:52 |
| hallyn | (0, auto, dummy, ) | 14:52 |
| rharper | hallyn: should be documented in hmp file | 14:52 |
| rharper | I assume you're still using hmp instead of qmp ? | 14:53 |
| rharper | akak human monitor | 14:53 |
| rharper | *aka* | 14:53 |
| hallyn | for my purposes yeah | 14:53 |
| pitti | I used -monitor and nc -U /path/to/.monitor | 14:53 |
| rharper | hallyn: qemu.git/hmp-commands.hx | 14:53 |
| hallyn | at least that *enumerates* the options, | 14:54 |
| rharper | lemme find my notes on the pci address format | 14:54 |
| hallyn | rharper: that would rock - would those be apporpriate for a wiki page? | 14:55 |
| rharper | possibly | 14:55 |
| rharper | hmp adding of drives is pretty odd | 14:55 |
| rharper | other than testing | 14:56 |
| rharper | hallyn: all of my notes are too old (aka, pci_add) but I'm seeing more documentation in qemu.git/doc/qdev-device-use.txt -- which explains the parameter formats ... next step would be to document some examples of those usages via hmp/qmp | 15:04 |
| jodh | pitti: still unable to recreate that test_conf_preload failure in adt/local 64-bit (2 different systems). Please can you send me logs or get me access to a system? | 15:09 |
| jodh | pitti: (to clarify, that's 32-bit adt btw :) | 15:10 |
| barry | pitti: hi, did the autopkgtest fix land on trunk? | 15:13 |
| smoser | stgraber, ping | 15:14 |
| smoser | wrt https://launchpad.net/bugs/1262951 | 15:14 |
| ubottu | Ubuntu bug 1262951 in Ubuntu "cloud-images /etc/network/interfaces shoud source-directory interfaces.d" [Medium,Triaged] | 15:14 |
| smoser | i'm interested in knowing if you would | 15:14 |
| smoser | a.) recommend putting the configuration for 'auto eth0' 'iface eth0 inet dhcp' in /etc/network/interfaces or in /etc/network/interfaces.d/ | 15:15 |
| smoser | and if in the interfaces.d directory, what would you recommend naming that file ? | 15:15 |
| smoser | i can see reasons why you'd want it named by mac address or pci location (which aren't known at the time of image build). | 15:16 |
| smoser | or simply just 'eth0' | 15:16 |
| pitti | jodh: just tried on the porter box, doesn't fail there (but they also run older kernel) | 15:22 |
| jodh | pitti: yeah, I'd already tried on a porter box. | 15:25 |
| stgraber | smoser: currently in a meeting, will reply in 30min or so | 15:28 |
| smoser | stgraber, you can just reply in the bug. | 15:29 |
| smoser | thanks. | 15:29 |
| slangasek | xnox: bug #1267117> I thought the phonedations team wanted us to move to using ssh for reasons like this? | 15:34 |
| ubottu | bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117 | 15:34 |
| xnox | slangasek: https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037674.html ? | 15:35 |
| xnox | slangasek: "we shall use adb" | 15:35 |
| xnox | slangasek: all current testing is done via adb, and it's most reliable one - e.g. ssh on emulator implies going via emulated 3G / qemu_pipe networking for which port-forwarding to the host machine is flacky. | 15:36 |
| xnox | slangasek: exec su - -c adb, does unblock me without getting entagled into ssh/adbd debates. | 15:37 |
| xnox | slangasek: don't we want correct pam_env, regardless? =) | 15:37 |
| directhex | what's the ubuntuish way to request package removal? it's so long since i've had to do it i've forgotten | 15:39 |
| xnox | directhex: file RM bug against the package and subscribe ubuntu-archive team. But one doesn't need to do that for packages that have been / or will be removed in Debian. | 15:40 |
| slangasek | xnox: ok. So it seems to me that each connection to adbd would ideally be its own PAM session, but as that would be an annoying patch to maintain, I'm ok with the su - -c adbd in the job | 15:40 |
| slangasek | xnox: you know that the autopilot test runners are all calling su - for us, right? | 15:41 |
| slangasek | xnox: and you should be using that test runner for any of your testing | 15:42 |
| xnox | slangasek: not consistently, and there are multiple test-runners at the moment (unrelated bug, tracked by qa/ci) | 15:43 |
| xnox | slangasek: not sure, why it was implemented on add hock basis in test-runner, instead of solving it for all $ adb shell, invocations. | 15:43 |
| slangasek | xnox: because the people solving the problem were not on the phonedations team ;) | 15:44 |
| slangasek | xnox: what are the multiple test runners? | 15:44 |
| xnox | slangasek: unity8, click, deb | 15:45 |
| xnox | and a special jenkins one. | 15:45 |
| slangasek | xnox: erm. why is phablet-test-run not the only one used for all of these? | 15:45 |
| xnox | one sets are recommended for app-dev, another for unity8 dev, and third one is actually used by jenkins.... | 15:45 |
| xnox | slangasek: i'm not sure. but there is a bug tracking & resolving this. | 15:46 |
| rharper | hallyn: pitti: I've applied a decoder ring to drive_add/device_add for qemu-1.5.0 -- not sure which version you have, but this should still work on the newer releases as well (http://paste.ubuntu.com/6715428/) | 15:47 |
| === juliank0 is now known as juliank | ||
| rharper | hallyn: pitti: the TL;DR for virtio-blk devices is drive_add 0 if=none,<drive options>,id=myid ; device_add virtio-blk-pci,drive=myid | 15:49 |
| pitti | rharper: indeed, that looks very close to what I used in http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/269 to replace pci_add | 15:51 |
| pitti | (but figuring that out was nontrivial) | 15:51 |
| rharper | indeed | 15:51 |
| slangasek | xnox: ok, well as far as I'm concerned phablet-test-run is the only one :-P | 15:51 |
| rharper | pitti: ideally, instead of dummy, you want the pci bus -- it works because there's only one pci bus by default, but someone could construct a machine with multiple, and the device-id on the virtio-blk-pci device should be separate from the drive-id , this allows querying via QMP for devices/drive etc. | 15:53 |
| hallyn | rharper: thanks. Can we put that into wiki.ubuntu.com/QemuDriveAddHmp or something? | 15:54 |
| pitti | rharper: ah; I wasn't sure about what these mean (instead of the "dummy" you can use just about anything without any noticeable difference); thans for the explanation | 15:54 |
| rharper | hallyn: yeah, it'd be worth walking through the scsi adapter version | 15:55 |
| rharper | hallyn: we should call is QemuDriveAdd and do both HMP and QMP version | 15:55 |
| rharper | lemme work up the qmp steps | 15:55 |
| rharper | should be the same, just all json'ed up | 15:55 |
| smoser | can someone nplease fix this! | 16:00 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1240977 | 16:00 |
| ubottu | Ubuntu bug 1240977 in unity (Ubuntu) "some modal dialog windows such as chromium-browser get stuck/lost/do not raise if on different desktop" [Undecided,New] | 16:00 |
| * smoser lost that chromium dialog window again | 16:00 | |
| xnox | slangasek: phablet-test-run, executes the tests, but doesn't do any preparation / rollback / gathering test results back to the host / making the output in .xml for jenkins etc. There are a lot more wrapper scripts on top of phablet-test-run. | 16:00 |
| slangasek | xnox: wrappers on top of phablet-test-run> ok, that's fine (well, ish); just wanted to make sure we are all actually using the central tool for environment setup | 16:05 |
| xnox | slangasek: i've based all my changes on top of lp:ubuntu-test-cases/touch, which is used by ci.ubuntu.com. With patches to adjust for emulator provisioning. However, I may not be hitting the same code-path =( | 16:07 |
| slangasek | xnox: does that mean lp:ubuntu-test-cases/touch is not using phablet-test-run? | 16:08 |
| ogra_ | dholbach, heh, i didnt even remember that you are an admin of canonical-arm-dev :) i was the one suggesting to chrisccoulson to use that PPA for builds :) | 16:11 |
| xnox | slangasek: from https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-friends-app-autopilot/107/console , jenkins.sh is used which eventually calls into utah testsuites, which invokes controlled settling of the device, runs tests, runs clean up. | 16:12 |
| xnox | slangasek: or in other words, things are different since e.g. phablet-test-run alone does not produce the same artifacts one can see on ci.ubuntu.com. | 16:12 |
| slangasek | xnox: hum. so where's the bug report for this and who's working on it? | 16:13 |
| ogra_ | dholbach, (for the oxide stuff that is) | 16:13 |
| xnox | slangasek: and i think at the moment i'm using more of a phablet-test-run based path, cause I do invoke phablet-test-run (via 2 wrappers) | 16:13 |
| xnox | slangasek: one sec. | 16:13 |
| xnox | slangasek: oh, and little did I know about otto in the mix =) https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1262879 | 16:14 |
| ubottu | Ubuntu bug 1262879 in Ubuntu CI Services "There should only be one, documented, way to run tests on devices" [Undecided,Confirmed] | 16:14 |
| slangasek | "otto"? | 16:14 |
| ogra_ | we dont use otto | 16:15 |
| ogra_ | we use utah | 16:15 |
| ogra_ | (for the image testing at least) | 16:15 |
| ogra_ | and utah uses phablet-test-run everywhere | 16:16 |
| xnox | ogra_: not as far as I could trace. | 16:17 |
| ogra_ | (but it also sets up the environment, sudos to the phablet user in advance etc) | 16:17 |
| ogra_ | http://ci.ubuntu.com/smokeng/trusty/touch/ ... all tests you see there are done by utah and use phablet-test-run | 16:17 |
| ogra_ | talk to plars for details, he knows that bit of infra pretty well | 16:18 |
| dholbach | ogra_, I'm not, you are | 16:18 |
| dholbach | ogra_, but it's taken care of, Victor did it - thanks | 16:18 |
| ogra_ | dholbach, oh, why did you get that mail then | 16:18 |
| xnox | ogra_: I'm executing commands from https://wiki.ubuntu.com/Touch/Testing#Running_Deb_tests and https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests and i get failures, that are pass on ci.ubuntu.com =) | 16:18 |
| ogra_ | ah | 16:18 |
| ogra_ | xnox, do you "sudo -u phablet -i" in advance ? | 16:19 |
| ogra_ | you need to be inside the upstart and dbus sessions of the user | 16:19 |
| barry | xnox: i think there's a problem with your emulator test script if i also have a device plugged in via usb: "error: more than one device and emulator" | 16:20 |
| barry | 16:20 | |
| ogra_ | *and* some tests require that the screen is unlocked and powerd is set top "always on" ... utah takes care of such stuff | 16:20 |
| barry | xnox: the fix *might* be Hey, just unplug the device, but it would be nice to fail fast in that case | 16:20 |
| xnox | ogra_: investigating the utah control lists it does: prepare-autopilot-test.sh, which installs packages, then there is unlock-screen.py executed with unlocks the screen & turns off power / screen shutdown, and then "autopilot-run address_book_app.tests.{}" is executed. | 16:21 |
| xnox | ogra_: there is no places where phablet-test-run is executed by utah that I can find. | 16:21 |
| rharper | hallyn: it appears that it'll be some time before drive_add appears in QMP; for now the only drive_add mechanism is via the HMP (which libvirt uses to do block hotplug as well) | 16:22 |
| xnox | ogra_: i don't execute "sudo -u phablet -i" I actually execute phablet-test-run, and that is doing all adb commands for me. | 16:23 |
| xnox | ogra_: and collects logs. | 16:23 |
| pitti | doko, infinity: heh, fun: libtool not being libtool any more also broke the upstart tests (thanks jodh for debugging) | 16:23 |
| xnox | barry: yeah, popey noticed that as well. For now, I can only recommend to unplug the phone, or export an environemnt variable. | 16:24 |
| hallyn | rharper: oh yeah, i remember noticing that when trying to debug device_remove's new behavior | 16:24 |
| xnox | barry: export ANDROID_SERIAL=emulator-5554, but not sure if that would make everything work. | 16:24 |
| xnox | pitti: ah, quite we use libtool directly. | 16:25 |
| xnox | pitti: i guess libtool-bin dependency is needed. | 16:25 |
| xnox | jodh: infinity: doko: ^ | 16:25 |
| pitti | xnox: no, that got dropped again; it's fixed again | 16:25 |
| pitti | (same with glom) | 16:25 |
| xnox | pitti: i'm so out of date =)))) | 16:25 |
| pitti | xnox: so is my schroot, which is why I got that upstart failure, but jodh didn't :) | 16:25 |
| xnox | clearly i'm not down with the kids =) | 16:25 |
| plars | doanac: iirc, the code is basically identical but we don't actually start using phablet-test-run until we enable the latest changes you were working on correct? | 16:26 |
| pitti | (i. e. my schroot updated this morning, before the reversion of libtool-bin) | 16:26 |
| doanac | plars: correct | 16:27 |
| plars | xnox: ^ | 16:27 |
| plars | xnox: is this about setting the testability config in preparation for running tests? | 16:28 |
| plars | xnox: if so, I was thinking something in phablet-config might be useful to do it if you are setting up for autopilot tests | 16:29 |
| plars | xnox: in fact, there's already an autopilot option for that script, that sets the click apparmor rules, might make sense to do it there | 16:30 |
| xnox | plars: it's about: test_results.xml being different, envrionment differences, screen-unlock & settle sequences different, also that -testability shouldn't be set. | 16:30 |
| xnox | plars: so at the moment the environment as is during the test under utah, is very different then under "just" phablet-test-run. | 16:30 |
| xnox | plars: and if you switch to phablet-test-run now, you will see regressions that I am seeing. | 16:30 |
| xnox | plars: i'll work on using jenkins.sh instead of phablet-test-run to match ci.ubuntu.com. But either get some things wrong. | 16:31 |
| xnox | plars: and a lot of people not aware of the differences. | 16:32 |
| plars | xnox: I'm trying to trace back through your lastlog but not sure I have the full context. if it's about the click-user-hooks, we are just using phablet-config autopilot --dbus-probe enable I think for that, which does aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules | 16:37 |
| plars | xnox: no matter what you are running, even phablet-test-run, this is required to run beforehand | 16:38 |
| xnox | plars: i know. but for example, under phablet-test-run - ubuntu-system-settings tests are executed without Locale set, under ci.ubuntu.com however there is locale set when ubuntu-system-settings tests are run. | 16:40 |
| xnox | plars: and instead of wrapping even more commands with "su - -c", I'm proposing to fix adbd across the board, to properly start/use a PAM session such that we can drop all "su - -c" hacks everywhere else. | 16:41 |
| plars | xnox: that sounds useful | 16:43 |
| xnox | plars: note that developers are adviced to use "just phablet-conf" and "phablet-test-run" and "manually unlock and turn the screen on", which is not what happens on ci.ubuntu.com and thus results are different between the two methods. | 16:43 |
| plars | xnox: yeah, it's that "manually unlock and turn the screen on" which isn't too nice for automation :) | 16:44 |
| === negronjl_ is now known as negronjl | ||
| xnox | plars: can you inject this onto the image: sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override" | 16:56 |
| xnox | plars: reboot the phone and execute representitive set of utah tests as done on ci.ubuntu.com? e.g. unity8 and a couple of core-apps? | 16:57 |
| xnox | plars: if that doesn't break anything, I'll land that change. | 16:58 |
| plars | xnox: sure, I'll try it locally in just a bit | 16:58 |
| ogra_ | xnox, hmm, sudo -u phablet -i should process ~/.pam_environment and set the locale | 16:59 |
| xnox | plars: thanks a lot. | 16:59 |
| ogra_ | i thought all our utah tests used that sudo prefix nowadays | 16:59 |
| ogra_ | hmm, in fact i think it is even inside phablet-test-run, not in utah | 16:59 |
| xnox | ogra_: $ adb shell locale; should work. And that's not just about locale, it's about LD_PRELOAD, QT_* variables, and everything else set in /etc/environment. | 17:00 |
| ogra_ | xnox, well, that should be hard set to C or en_GB/US | 17:01 |
| ogra_ | we dont really set system locales on the phone images iirc | 17:01 |
| ogra_ | only per user ones in ~/.pam_environment | 17:01 |
| xnox | ogra_: it is set in both /etc/environment & in /etc/default/locale, but not sourced in any way. Along with many other things. | 17:01 |
| ogra_ | right | 17:01 |
| ogra_ | because adbd calls bash directly | 17:01 |
| ogra_ | because it pretends to be a serial console | 17:02 |
| xnox | ogra_: serial tty, runs login, which has pam support. So serial tty is fine. adb simply runs "bash in login shell mode" which doesn't setup PAM session. (Not sure if that's a bash bug) | 17:03 |
| xnox | slangasek: should "bash --login" setup a PAM session? | 17:03 |
| ogra_ | xnox, serial *console* | 17:03 |
| ogra_ | :) | 17:03 |
| slangasek | xnox: no | 17:03 |
| xnox | slangasek: ok. | 17:03 |
| slangasek | for one thing, setting up a session may require privileges | 17:03 |
| xnox | ogra_: here is the diff between "adb shell" environment and a "su -" environment: http://paste.ubuntu.com/6715828/ | 17:04 |
| ogra_ | xnox, i would love to drop adb today, but there was mgmt concern that it needs to stay 100% android compatible for OEM tools to work etc | 17:04 |
| cjwatson | doko: I had to cancel an arm64 test build in order to get ofono-phonesim building, which is urgent to get through -proposed for touch - I've retried it | 17:04 |
| ogra_ | xnox, so i wouldnt add any login there since this will break exactly this assumption | 17:04 |
| cjwatson | (sorry for any inconvenience) | 17:04 |
| xnox | ogra_: there are many things that adb does that ssh doesn't, and nice versa. However having environment between "ssh" and "adb shell" is a carefully planted trap one can easily walk into, and is easily fixable. | 17:05 |
| xnox | s/nice versa/vice versa/ | 17:05 |
| ogra_ | xnox, right, i'm all for processing pam, but the behavior of the shell needs to stay the same | 17:06 |
| ogra_ | so that OEMs can use their exiting flash tools for android flashing etc | 17:06 |
| xnox | ogra_: at the moment "$ adb shell" has environment, as scrubbed by upstart. So pretty much nothing & UPSTART_* variables. Not even HOME set. | 17:07 |
| ogra_ | xnox, btw, i personally dont see any benefit of adb ... i would drop it, switch on rndis networking over USB and attach a ssh login ;) | 17:07 |
| xnox | ogra_: so i don't understand what needs to stay the same. | 17:08 |
| ogra_ | but i was denied because of the android compatibility | 17:08 |
| ogra_ | xnox, behavior, so if an OEM has mass flash tools that they use on android these work on our system too | 17:08 |
| xnox | ogra_: adb into the emulator is the only way to speak to emulator, and it does not rely on neither networking, usb networking, nor 3g emulated networking =) | 17:08 |
| ogra_ | yeah, thats the emulator :P | 17:08 |
| xnox | ogra_: flashing portions of adb, have nothing to do with "adb shell" portion of the tool set. | 17:09 |
| ogra_ | the discussion i had about this predates the emulator by months :) | 17:09 |
| xnox | ogra_: whilst personally you might not see any benefit of adb, ssh is not a superset of features that adb provides and never will be. | 17:10 |
| ogra_ | xnox, well, i was told we even need to run adbd as shell user (so that adb root is needed and work as expected) etc | 17:10 |
| ogra_ | xnox, no, i would have liked to replace adb shell with ssh | 17:11 |
| ogra_ | and have a login etc | 17:11 |
| ogra_ | but as i said, i wasnt allowed to for the above reasons | 17:11 |
| ogra_ | xnox, i meant to only disable the awful serial shell and replace it by an ssh login | 17:12 |
| ogra_ | anyway, thats long put to rest | 17:12 |
| ogra_ | xnox, making the shell user thing work and hook that somehow into pam might be of more benefit | 17:13 |
| ogra_ | (since thats pülanned for this cycle anyway) | 17:14 |
| xnox | ogra_: ... that's completely out of scope, and orthogonal to my current task. | 17:14 |
| ogra_ | why ? | 17:14 |
| ogra_ | it would be the phablet user in our case | 17:14 |
| ogra_ | that would even save you the sudoing | 17:15 |
| xnox | ogra_: i need root. | 17:15 |
| ogra_ | and enable you to *just run* the tests | 17:15 |
| xnox | ogra_: not user. | 17:15 |
| ogra_ | for running tests in the user env ? | 17:15 |
| ogra_ | (all our tests run in the user session) | 17:15 |
| ogra_ | s/run/need to run/ | 17:15 |
| plars | yeah, the tests need to run as phablet user | 17:16 |
| ogra_ | which is why we jump through awful hackish sudo loops atm in phablet-test-run and utah | 17:16 |
| xnox | ogra_: they do, but all the provisioning, setup, tear down, and log collection needs root to control hardware and system level things. | 17:16 |
| xnox | ogra_: my task at hand is to parallelise and run tests in the emulator, with as high pass / parity rate to the real devices as possible. And I'm on vacation from saturday. | 17:17 |
| xnox | ogra_: i have nothing to do with re-engineering our adb, user-sessions, and test frameworks ;-) | 17:17 |
| ogra_ | xnox, well, adbd will change to default to the shell user ... that will likely break your stuff if you dont add adb root to your code | 17:17 |
| ogra_ | for now, why cant you just source /etc/profile and /etc/environment after login ? | 17:18 |
| ogra_ | given the whole setup will change anyway | 17:18 |
| ogra_ | that should give you all you need | 17:20 |
| xnox | ogra_: no it will not give me all i need. at the moment it's not possible to run tests without root and without RW image. As one needs to install system-wide debs & disable apparmor. | 17:21 |
| xnox | ogra_: there is no "my stuff" only phablet-test-run, etc. and they do call "adb root" abeilt being pointless for the current setup. | 17:21 |
| * ogra_ doesnt get that "run tests with root" | 17:22 | |
| ogra_ | i understand that you need root to install the autopilot pieces ... but the tests are still run under sudo -u phablet -i | 17:22 |
| xnox | ogra_: provision a read-only phone and trying running click test-suit without using root, nor switching image to RW. | 17:23 |
| ogra_ | xnox, hmm, sergiusens worked on stuff there ... i know i can test all click packages without ever becoming root | 17:24 |
| ogra_ | but i suspect thats not what you mean when saying "click test suite" ? | 17:24 |
| ogra_ | xnox, we should probably consider just seeding what you need if it is not to intrusive, that would save the whole root/non-root stuff | 17:25 |
| xnox | ogra_: exec_with_adb_user() { | 17:26 |
| xnox | adb -s $ANDROID_SERIAL shell sudo -u $USER -i sh -lc \'"$@"\' | 17:26 |
| xnox | } | 17:26 |
| ogra_ | yeah | 17:26 |
| ogra_ | sudo loops :) | 17:27 |
| xnox | ogra_: http://paste.ubuntu.com/6715926/ which is missing half of the stuff from /etc/environment. | 17:27 |
| xnox | ogra_: so the problem with adb not sourcing /etc/environment is affecting phablet-test-run, which i'm using, which is causing build-failures not seen with ci.ubuntu.com because that is using utah, different setup/tear-down, and not using phablet-test-run. | 17:27 |
| ogra_ | utah definitely uses phablet-test-run | 17:28 |
| ogra_ | this is a requirement we made about 1 year ago | 17:28 |
| xnox | ogra_: =)))))) | 17:28 |
| ogra_ | and i see it called in all test logs | 17:28 |
| xnox | ogra_: which log? | 17:28 |
| ogra_ | (on the image tests) | 17:28 |
| ogra_ | http://ci.ubuntu.com/smokeng/trusty/touch/ | 17:29 |
| ogra_ | clickj one of the build numbers and click through to a test | 17:29 |
| xnox | ogra_: check again. e.g. the click apps test and deb tests. | 17:29 |
| xnox | console output. | 17:29 |
| === jasoncwarner__ is now known as jasoncwarner | ||
| xnox | and compare the outputs with locally running phablet-test-run for the same click app / deb. | 17:30 |
| ogra_ | plars, ^^^ can you clearify ? i'm sure we use phablet-test-run everywhere in utah | 17:31 |
| ogra_ | would be quite a policy breach if we didnt anymore | 17:32 |
| ogra_ | or doanac ^^^^ | 17:32 |
| xnox | ogra_: it doesn't matter what is used, apart from adbd having bad environment, which is the default one available to external users and it doesn't match the running environmnet from within the phone. | 17:34 |
| plars | ogra_: I believe we never have, but we've done quite a bit to make sure that what we're running is basically identical. This was due to a requirement to run tests individually at the time. However, the latest stuff doanac has been pushing in will get us to where we are really running with purely phablet-test-run, and most of it has already landed | 17:34 |
| ogra_ | plars, hmm, didnt we work heavily with asac back a few months to make sure phablet-test-run is used on utah too ? | 17:35 |
| doanac | ogra_: we've made strides to get to that point. we still have a little work left though and got preempted | 17:35 |
| ogra_ | oh sigh | 17:35 |
| plars | ogra_: that's what all this stuff has been about - it wasn't just a simple change though | 17:35 |
| ogra_ | xnox, ignore my noise then, i was convinced that was long done | 17:35 |
| xnox | ogra_: no worries. we are on the same page now =) | 17:36 |
| ogra_ | xnox, though sh -l *should* process the environment theoretically, no ? | 17:37 |
| plars | ogra_: a lot of the setup things needed were moved into phablet-config in phablet-tools though, and we use that, as does anyone running locally with phablet-test-run | 17:37 |
| seb128 | slangasek, mdeslaur, pitti: I'm not subscribed to the technical-board list to reply, but following the hibernate discussion, it would be useful to get https://code.launchpad.net/~jefferyto/ubuntu-docs/lp1232814/+merge/197782 merged (if somebody wants to point it, it was mentioned in some of the emails that we don't have instructions for user who want to re-enable it) | 17:37 |
| ogra_ | plars, yeah | 17:37 |
| ogra_ | xnox, i wonder what happens if you make that "bash -lc" instead, might be a limitation of dash here | 17:38 |
| ogra_ | (in exec_with_adb_user) | 17:38 |
| asac | doanac: what is left? :) | 17:39 |
| xnox | ogra_: well, i want to put one hack in one place in /etc/init/*adb.conf, without iterrating across correct options in every single script / framework / harness used for the ubuntu-touch today. | 17:39 |
| xnox | ogra_: or re-writtes of thereoff. | 17:40 |
| doanac | asac: the output of phablet-test-run is junit xml. we need to able to convert that to utah.yaml so that the dashboard will be able to report results | 17:40 |
| xnox | ogra_: plus aren't all tools rewritten in go anyway? thus making current incornation of phablet-* obsolete. | 17:40 |
| ogra_ | xnox, lol ... yes, some rewriting has started | 17:40 |
| ogra_ | i doubt all will be moved in trusty | 17:41 |
| asac | note that "every single framework" in this case means "two frameworks" and not hundreds :)... | 17:41 |
| ogra_ | that smells like a rather long process | 17:41 |
| asac | so if its really causing us pain, implementing it temporarily in two places should be a worthwhile option to consider | 17:41 |
| xnox | asac: well depends at which level of wrapper scripts one counts. "two matryoshka dolls" =))) | 17:42 |
| asac | yeah... :) | 17:42 |
| ogra_ | xnox, so looking at your bug, why do you want to use an override instead of modifying the exec line in the package | 17:42 |
| asac | but for me thats all just one tiny thing :) | 17:42 |
| ogra_ | xnox, seems we would simply benefit from having it set everywhere | 17:42 |
| asac | i think its a tradeoff of pain | 17:43 |
| xnox | ogra_: which bug? the unity8 override is only shipped in unity8-autopilot package and not in unity8. That override is specific to running unity under test, not under general operating conditions. | 17:43 |
| ogra_ | xnox, bug 1267117 | 17:44 |
| ubottu | bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117 | 17:44 |
| ogra_ | i would just fix the exec line in the package | 17:44 |
| asac | doanac: thats the only thing left? | 17:44 |
| ogra_ | we're out of sync with debian here anyway | 17:44 |
| xnox | ogra_: read carefully, i'm using .override now locally, but yeah i do intend to just change .conf if we agree to ship that by default. | 17:44 |
| ogra_ | xnox, if it is provenb to fix the issue, go for it | 17:44 |
| xnox | ogra_: i've requested for plars to execute tests under utah, before I "go for it". | 17:45 |
| xnox | ogra_: we test thing before landing. | 17:45 |
| ogra_ | good | 17:45 |
| doanac | asac: i think. we've been looking at getting autopilot to produce subunit for phablet-test-run. so we'd really write a filter to convert subunit to utah.yaml | 17:45 |
| ogra_ | pfft ... yeah. yeah, thats what you tell asac so he pays you drinks at the sprint :P | 17:45 |
| doanac | asac: the test-execution-service job i wrote actually uses phablet-test-run | 17:46 |
| doanac | we just don't have a qa-dashboard that can handle it yet | 17:46 |
| ogra_ | xnox, if you need someone to nod it off after testing feel free to ping | 17:46 |
| asac | doanac: why do we hook the fate of this up to the subunit conversion? | 17:46 |
| ogra_ | :) | 17:46 |
| asac | i would prefer to see it decoupled | 17:46 |
| xnox | ogra_: hm, not sure that's quite right. slangasek knows my preferences in bribes, but i don't think asac knows that yet ;-) | 17:47 |
| asac | whats the price? | 17:47 |
| asac | beer? | 17:47 |
| asac | :) | 17:47 |
| doanac | asac: we don't have to. you can deprioritize subunit. it was a request from the QA team. so if i'm writing a filter i just wanted to write it once and be done | 17:47 |
| ogra_ | xnox, we'll tech him :) | 17:47 |
| plars | xnox: I've been through 1 run of unity locally and saw a maliit-server crash and 2 failures which were not expected. I'm trying it without the .override now though, as it's been some time since I've tried this locally. So it could be something stupid on my host, but just want to check as that's certainly different from what we see in the lab | 17:47 |
| xnox | asac: i'm not gonna tell you that easy =) | 17:47 |
| ogra_ | asac, coctails | 17:47 |
| ogra_ | fancy ones even i guess :) | 17:47 |
| xnox | asac: it is on irclogs.ubuntu.com, in 2011-2013 years. | 17:47 |
| asac | xnox: you can send a gpg encrypted /msg :) | 17:47 |
| asac | lol | 17:47 |
| asac | my key is in my launchpad profile i believe | 17:48 |
| ogra_ | *giggle* | 17:48 |
| Laney | shakira greatest hits | 17:48 |
| Laney | or maybe shania | 17:48 |
| asac | hehe | 17:48 |
| xnox | asac: .... or bribe slangasek to tell you =)))) | 17:48 |
| asac | doanac: yeah, but when is subunit coming? | 17:50 |
| slangasek | seb128: well, "we don't have instructions" was only one of the concerns.... the other was "there should be a straightforward way to re-enable it" | 17:50 |
| slangasek | xnox, asac: heh | 17:51 |
| doanac | asac: it requires landing in distro for autopilot (its in trunk). landing a change to phablet-tools (not done). and fixing some proof-of-concept code i wrote | 17:51 |
| doanac | so its work. | 17:51 |
| asac | doanac: i mean, we have so much distraction because of this that there is almost no timeline that can justify not writing a throwaway filter. | 17:51 |
| doanac | asac: i can do junit->utah conversion. | 17:51 |
| asac | let me check something | 17:51 |
| doanac | we'll have to explain to QA why | 17:51 |
| doanac | and they might have subunit ready before I can write this filter | 17:52 |
| seb128 | slangasek, still, having the instructions updated (which that mp is doing) would be a step in the right direction ;-) (do we still have active people in the documentation team to review/approve it?) | 17:53 |
| slangasek | seb128: it does seem strange to me to have hibernate support blocked at the policykit layer, though | 17:54 |
| asac | doanac: ok after checking i highly recommend to not hook your fate up to autopilot | 17:54 |
| asac | doanac: autopilot hasnt landed for ages | 17:54 |
| asac | and afair has a bunch of big issues pending | 17:55 |
| doanac | asac: okay. we need to loop in ev and decide how to allocate my time towards this. | 17:55 |
| sergiusens | ogra_, xnox no need for root or rw for click | 17:55 |
| ogra_ | yeah, as i thought | 17:55 |
| ogra_ | only for non click tests | 17:55 |
| asac | doanac: sure, thats clear | 17:55 |
| asac | doanac: do you know if qmltest also produces subunit? | 17:56 |
| asac | or junit? | 17:56 |
| seb128 | slangasek, why? that makes the UI do the right thing (e.g hide the entry by default, show it if the permissions are granted/enabled) | 17:57 |
| asac | doanac: anyway. i think its best to kick a quick mail with you/ev/me/fginter/didrocks on this | 17:58 |
| asac | let me know if you send it | 17:58 |
| slangasek | seb128: because I don't think it's logical to treat this as an access constraint, it's not that the user isn't /allowed/, it's that it's broken and we want to hide it | 18:01 |
| seb128 | slangasek, I guess we could define a new gsettings key "show-hibernate-ui" and make the different clients use it | 18:02 |
| seb128 | slangasek, patches are welcome ;-) | 18:02 |
| slangasek | seb128: well, first I'd like to establish whether the design would be acceptable :) | 18:02 |
| seb128 | slangasek, the current solution was more "what's the easiest way to get the UI for hibernate hidden from the different components" I guess | 18:02 |
| === medberry is now known as med_ | ||
| === lfaraone_ is now known as lfaraone | ||
| === sraue_ is now known as sraue | ||
| arges | jamespage: hi. have some updates on the ovs 1.4.6 issues I've been seeing | 19:03 |
| arges | bug 1219788 | 19:03 |
| ubottu | bug 1219788 in openvswitch (Ubuntu Quantal) "[SRU] Update openvswitch to 1.4.6 stable release" [Medium,Fix committed] https://launchpad.net/bugs/1219788 | 19:03 |
| arges | Not exactly sure how to proceed, should the fix go on top of your 1.4.6 SRU? | 19:04 |
| arges | i'll update the bug | 19:07 |
| jdstrand | Snow-Man: fyi, mdeslaur is working on the openssl update now | 19:13 |
| Snow-Man | ok, thanks! | 19:14 |
| plars | xnox: I'm having trouble sorting much out locally, because unity keeps crashing on me, both with and without the override. I'm running it the same way as in the lab (albeit my host environment could be different since I'm running it off a desktop box here at my house) | 19:15 |
| plars | xnox: I did manage to make it through unity with no problems and the override was in place though | 19:16 |
| plars | xnox: and I just saw notes-app pass 100% with the override in place (and no crash this time) | 19:24 |
| PublicStaticVoid | Is it okay to report and discuss weird behavious in 14.04 here? I understand it is beta.. so didnt wanna ask in #Ubuntu | 19:36 |
| PublicStaticVoid | I just have one issue so far | 19:37 |
| rharper | hallyn: here's my first pass... https://wiki.ubuntu.com/QemuDiskHotplug I want to add the guest side output for these operations, but I need to install different ubuntu levels on a few systems before I can create the output. | 19:37 |
| PublicStaticVoid | Where the UI Unity or Xorg freezes and if I click it goes bloack for a about 10 to 15 seconds then returns to normal.. | 19:37 |
| PublicStaticVoid | I can post logs or dmesg or anything that may help, dunno if it is a bug, known issue, or my actual system.. | 19:38 |
| arges | PublicStaticVoid: your best bet would be to file a bug using 'ubuntu-bug'. You can read up more about how to do it here: https://help.ubuntu.com/community/ReportingBugs | 19:38 |
| PublicStaticVoid | Okay, I have filed a bug before, not sure if I was supposed to for 14.04 since it is a rc | 19:39 |
| PublicStaticVoid | Was hoping yu guys had heard of it and there was a quick fix or something haha | 19:39 |
| PublicStaticVoid | Is it true we are going Rolling release? | 19:40 |
| PublicStaticVoid | Also, when running 14.04 am I supposed to run apt-get distro-upgrade often? | 19:42 |
| hallyn | rharper: that's awesome, thanks. fwiw lp:qa-regression-testing scripts/test-qemu is where i'll need that. as it's our regression testsuite for qemu, you might be interestedin taking a look | 19:42 |
| hallyn | (and scripts/test-libvirt.py is the analogous libvirt testsuite) | 19:42 |
| === ryanakca_ is now known as ryanakca | ||
| jamespage | arges, i should think so yes | 19:50 |
| rharper | hallyn: cool, I'll take a good | 19:50 |
| smoser | wonder if anyone has thoughts on where this would come from | 19:50 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1267225 | 19:50 |
| arges | jamespage: ok creating the branch now | 19:50 |
| ubottu | Ubuntu bug 1267225 in cloud-initramfs-tools (Ubuntu) "initramfs in cloud-images does not contain crypt modules" [High,Confirmed] | 19:50 |
| smoser | utlemming, ^. something (either bug in build process or mkinitramfs) is making us miss crypto modules in the cloud images as they're shipped. | 19:51 |
| smoser | but running 'update-initramfs -u' gets them. | 19:51 |
| utlemming | smoser: interesting....I'm not sure what is happening there, but I'll take a look | 19:51 |
| arges | jamespage: would you prefer I dput the changes to ovs? | 19:53 |
| smoser | slangasek, you have thoughts on what we could be doing wrong there? how could an initramfs get generated without those modules ? | 19:55 |
| infinity | smoser: Generated without cryptsetup being installed? | 20:07 |
| infinity | Though, I guess that would fail a bit differently on boot. | 20:08 |
| smoser | right. the initramfs got generated without those modules. | 20:11 |
| smoser | but i'm not sure how. its not like there is code that says "maybe include crypto" | 20:12 |
| smoser | there is stuff in /usr/share/initramfs-tools/hook-functions for 'hidden_dep_add_modules' that specifically comments on crypt. | 20:12 |
| smoser | but that doesn't seem variable | 20:12 |
| Peace- | hello could someone test firefox here ? https://palava.tv/mio | 20:20 |
| Peace- | because firefox 26 on ubuntu doesn't work here on fedora seems it does | 20:21 |
| Peace- | i will log out and login | 20:24 |
| jcastro | stgraber, I am finding I need to sudo to use lxc-ls in trusty, is this normal or a bug? | 20:51 |
| jcastro | in saucy I didn't need sudo | 20:51 |
| stgraber | jcastro: normal. For two completely separate reasons. 1) We changed the permissions of /var/lib/lxc and /var/cache/lxc to 700 to avoid a security issue involving calling outdated setuid binaries. 2) Starting next week lxc-ls will list your user's containers unless it's run as root. | 20:53 |
| jcastro | thanks! | 20:56 |
| rharper | hallyn: the test-qemu could use some updating ... from my initial glance, it appears to be a host-side (qemu monitor) validation only -- is there any guest-side validation to go along with it ? | 20:58 |
| hallyn | rharper: I don't think so. it was written by security team, with host security and correctness as primary goal. | 21:00 |
| rharper | interesting | 21:00 |
| hallyn | it does install acpi, which is more than test-libvirt does | 21:00 |
| hallyn | rharper: certainly the pci-add tests need to be updated since pci_add is gone; oterh patches certainly will be welcome. do you know how to do merge requests in lp? | 21:01 |
| rharper | there's a huge hole in the device_add area -- I see exactly one (device_add usb-storage) -- when there are over 140 qemu devices that can be added -- I already had two segfaults testing today (qemu 1.5.0) with just simpel device_add driver=XXXX | 21:01 |
| rharper | hallyn: not yet | 21:01 |
| rharper | hallyn: % qemu -device ? 2>&1 | wc -l | 21:02 |
| rharper | 140 | 21:02 |
| rharper | s/over/exactly | 21:02 |
| hallyn | rharper: well, do keep in mind that any test we add, if the underlying support gets pulled out later then we have to deal with it | 21:02 |
| hallyn | so i would NOT want all 140 device types to be tested :) | 21:02 |
| rharper | it's not a support question | 21:02 |
| rharper | it's a does-it-segfault | 21:03 |
| rharper | even if the device doesn't work, trying to add it should segfault qemu | 21:03 |
| rharper | *shouldn't* | 21:03 |
| * Logan_ pokes cjwatson. Around? | 21:04 | |
| rharper | at least, I'm assuming that's what this sort of host-side testing would want to catch ? | 21:04 |
| === salem_ is now known as _salem | ||
| bdrung | doko: yes. | 21:07 |
| rharper | hallyn: I can take a stab at replacing the hotplug bugs (s/pci_{add.del}/device_{add,del}) | 21:08 |
| hallyn | rharper: great, thanks. (I've been holding off on my version at http://people.canonical.com/~serge/qrt-qemu.diff bc i was taking guesses at the right way)) | 21:11 |
| rharper | hallyn: np, should be able to fix up the nic hotplug too | 21:12 |
| hallyn | awesome | 21:12 |
| rharper | hallyn: I should get this working in a trusty vm, right? | 21:13 |
| hallyn | rharper: yup | 21:16 |
| hallyn | rharper: before running it, check README under scripts/qemu | 21:16 |
| rharper | k | 21:16 |
| smoser | xnox, ping | 22:03 |
| slangasek | smoser: looks to me like /usr/share/initramfs-tools/hooks/overlayroot makes the aes support conditional on: egrep -qswo "aes" /proc/cpuinfo && manual_add_modules aesni_intel || true | 22:13 |
| slangasek | smoser: so that looks like a wrong assumption that the initramfs will be built in an env where aes is supported | 22:13 |
| Netsnipe | hi everyone | 22:20 |
| Netsnipe | I'm a Cloud Support Engineer with Amazon Web Services these days | 22:20 |
| Netsnipe | does anyone anyone know who might be responsible for the AMIs? | 22:21 |
| stgraber | smoser, utlemming: ^ | 22:21 |
| Netsnipe | s/anyone// | 22:21 |
| utlemming | Netsnipe: that would be me | 22:21 |
| utlemming | Netsnipe: interesting to see an AWS person in a public place :) | 22:22 |
| Netsnipe | I used to be in #debian-devel about 10 years ago = P | 22:22 |
| Netsnipe | utlemming: is there an official process for us to engage with you guys? | 22:24 |
| Netsnipe | or would you prefer going through launchpad? | 22:24 |
| Netsnipe | we have customers requesting instance store backed HVM AMIs | 22:24 |
| utlemming | interesting request....do you know what releases? | 22:25 |
| utlemming | Netsnipe: a launchpad bug would be helpful | 22:26 |
| jtaylor | is pygtk working in trusty? | 22:42 |
| jtaylor | gtk3 via gi bindings | 22:42 |
| === hughhalf is now known as hugh_afk | ||
| cjwatson | Logan_: briefly | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!