[01:02] <cjwatson> YokoZar: It's actively in progress on the IS side (as in has somebody assigned to it and work is progressing), but the Launchpad team can't do a whole lot at this point beyond being responsive to any blockers we hear of.
[01:03] <YokoZar> cjwatson: ahh, reasurring.  Thanks :)   I do find it somewhat amusing that the 0.4 recipe format was made years ago but has been blocked by deployment issues and never made it into the wild :D
[01:04] <cjwatson> (On which note, there is one blocker I noticed last week currently staged for deployment in lp:launchpad-buildd - I should make time for QAing that before the Christmas break)
[01:42] <Noskcaj> What's the best way to merge stuff from experimental?
[06:03] <pitti> Good morning
[06:04] <RAOF> pitti: Good morning!
[07:53] <pitti> infinity: would you mind if I (or you) release the systemd-shim SRU now, to avoid doing that on a Friday before holidays?
[07:53] <pitti> (it's 8 days)
[07:53] <pitti> and systemd itself, too (I'm very confident in these fixes, and they got multiple verifications)
[08:10] <dholbach> good morning
[08:30] <RAOF> pitti: Normal marinating time would be 7 days? Is there some reason systemd-shim should wait longer?
[08:33] <RAOF> pitti: Oh, also - I got pinged about uploading colord 1.0.3 to Ubuntu, and that reminded me that we hadn't uploaded it to Debian, either.
[08:34] <RAOF> pitti: So I went and updated git to 1.0.5, and fixed all the autopkgtests. Would you kindly upload that to Debian sometime?
[08:41] <OdyX> RAOF: I can sponsor to Debian if you want.
[08:42] <RAOF> OdyX: That would be awesome, thanks.
[08:43] <OdyX> RAOF: point me to a dsc and make sure you fix enough Debian bugs :-)
[08:43] <RAOF> OdyX: git://anonscm.debian.org/git/collab-maint/colord.git contains the package; standard master/pristine-tar/upstream layout for git-buildpackage
[08:43] <OdyX> RAOF: Nice
[08:49] <OdyX> RAOF: HEAD commit from master isn't documented in debian/changelog, which commit do you want me to use as source for the package ?
[08:49] <RAOF> HEAD on master. I can document it in debian/changelog if you like.
[08:50] <OdyX> oh, actually, HEAD and HEAD^
[08:51] <OdyX> RAOF: well, it makes the "single-debian-patch" bigger without clear non-vcs explanation...
[08:51] <OdyX> (+ the dch release date is earlier to the latest changes)
[08:52] <RAOF> Yeah, it's clearly confusing.  I'm writing a changelog entry now.
[08:53] <OdyX> btw, that's why I prefer "commits don't change debian/changelog, git-dch generate a debian/changelog entry, make it beautiful, commit that" The changelog entry is then just an abstract from the VCS history. And that eases cherry-picks and reverts if you need to handle backports.
[08:54] <RAOF> OdyX: That's what I normally do; what happened here is I did that for 1.0.3, then forgot about uploading it :)
[08:55] <OdyX> he he
[08:55] <RAOF> OdyX: Now with changelog entries for those bits.
[08:57] <OdyX> RAOF: nice. The rest looks nice to me; I didn't check the upstream release diff. And if I where to nitpick, I'd insist on a manpage for cd-iccdump and a bump of Standards-Version + check.
[08:57] <OdyX> :)
[08:57] <RAOF> Hm. Why didn't lintian complain about Standards-Version?
[08:57] <OdyX> RAOF: ah, http://qa.debian.org/bls/packages/c/colord.html is more interesting.
[09:01] <RAOF> That page would be much more useful if it highlighted *where* it thought FORTIFY_SOURCE wasn't being passed in.
[09:01] <OdyX> yeah, I'm exactly at that point in the investigation too
[09:04] <OdyX> apparently some .c in the introspection
[09:05] <OdyX> anyway, not important enough, I'll build and upload if nothing else arises in between :)
[09:06] <RAOF> Ah, *there* it is, yes.
[09:07] <ara> hello!
[09:08] <GunnarHj> pitti: ping?
[09:11] <GunnarHj> Hello ara ;-)
[09:13] <pitti> hey GunnarHj
[09:13] <pitti> RAOF: no, I don't think it should wait longer, that's why I ask
[09:13] <pitti> RAOF: I just wouldn't like to release SRUs on a Friday
[09:13] <GunnarHj> pitti: Hi Martin!
[09:13] <pitti> RAOF: git?
[09:14] <pitti> RAOF: oh, you mean colord? my pleasure
[09:14] <GunnarHj> pitti: Do you possibly have any comments on https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037899.html ?
[09:14] <RAOF> pitti: Too slow, OdyX is already on it :)
[09:14] <pitti> RAOF: heh; sorry, was out for some errands
[09:14] <RAOF> No problem :)
[09:14] <pitti> RAOF: thanks for fixing the autopkgtest, that has been a long-standing wart
[09:14] <GunnarHj> pitti: I talked with slangasek. He seemed to be busy, but he said:
I haven't had a chance to think about it in any detail; there are tradeoffs regardless, profile only applies to shells and /etc/environment /etc/default/locale ~/.pam_environment only apply to PAM sessions.</quote>
[09:15] <GunnarHj> I'm not sure, but didn't he miss that /etc/profile and ~/.profile are sourced by the DMs?
[09:15] <pitti> GunnarHj: I think system-wide should be /etc/environment, and per-user ~/.profile
[09:16] <pitti> GunnarHj: /e/default/locale is indeed a very wrong place for generic env vars
[09:16] <GunnarHj> pitti: Ok - why /etc/environment before /etc/profile or /etc/profile.d ?
[09:17] <pitti> GunnarHj: /etc/environment is meant to be user-edited, while /etc/profile might get updated by newer package versions and has non-trivial default contents (thus easy to break it)
[09:18] <pitti> GunnarHj: I don't think that "only applies to PAM sessions" is a practical limitation; users always need to get through PAM to log into a machine
[09:18] <RAOF> pitti: Enjoy your systemd-shim update!
[09:18] <pitti> RAOF: thanks! systemd as well?
[09:19] <GunnarHj> pitti: Variable expansion seems not to work in /etc/environment, which would speak for one or more extra .sh files in /etc/profile.d/
[09:20] <pitti> GunnarHj: I have no objections against /etc/profile.d/ either
[09:20] <GunnarHj> pitti: Then I guess that both should be mentioned as suitable ways.
[09:20] <GunnarHj> pitti: Thanks for your input!
[09:20] <pitti> GunnarHj: thanks to you!
[09:21] <RAOF> pitti: And done.
[09:21] <pitti> \o/
[09:21] <pitti> RAOF: christmas cleanup :)
[09:34] <OdyX> RAOF: uploaded. I also pushed a signed tag to the repository.
[09:35] <RAOF> OdyX: Thanks muchly.
[09:35] <OdyX> RAOF: lintian reports hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/libcolordprivate.so.1.0.22 which might need investigation.
[09:36] <RAOF> I'm pretty sure that's a false-positive.
[09:36] <RAOF> Indeed, I thought I had a lintian override for that, because it was a false-positive?
[09:36]  * RAOF investigates.
[09:36] <OdyX> RAOF: overriding the flag if you can "prove" it is a valid response
[09:37] <OdyX> RAOF: there is an override in colord for libcolord_sensor_argyll
[09:37] <RAOF> Yeah.
[09:40] <OdyX> RAOF: btw, the libcolordprivate.so.1.0.22 name suggests it should not be in the standard path but rather under some specific colord directory no ?
[09:42] <RAOF> Not particularly; it's a low-dependency bunch of stuff that got split out from libcolord to be used in other parts; anything that links with libcolord needs it.
[09:42] <RAOF> It *could* be in a private path + an RPATH, but that's not a winner.
[09:44] <OdyX> yeah. As long as no -dev ships headers for it it's probably okay.
[09:56] <RAOF> Hey, cool. That hardening-check was a false-positive, but it looks like there *is* a bug there.
[10:10] <OdyX> cool indeed
[12:12] <amitk> cjwatson: slangasek: I've got a new haswell machine (samsung ativ 9 plus) which comes preloaded with Windows. I turned off "Secure mode" in the bios and changed "OS mode selection" to "CSM and UEFI OS" and was able to boot the ubuntu liveusb and install. But upon reboot, I booted back into Windows.
[12:13] <amitk> even though a EFI partition exists, it seems grub-pc was installed instead of the EFI version.
[12:13] <stgraber> amitk: that's most likely because you booted the install media using the BIOS and not EFI
[12:14] <stgraber> amitk: d-i and ubiquity basically check how the kernel was booted. If it was booted using EFI, you get a EFI install, otherwise you get good old BIOS.
[12:14] <stgraber> I suspect your firmware will first attempt to boot any native EFI entry it has before doing a fallback to their BIOS emulation, so that explains why it boots Windows for you
[12:15] <amitk> stgraber: hmm, that seems likely. Changing the "OS mode selection" to UEFI OS doesn't boot the Ubuntu Livecd anymore though :-/
[12:16] <stgraber> ah, then that's likely a firmware bug...
[12:16] <stgraber> the ubuntu desktop and server medias boot perfectly fine from EFI with secureboot enabled
[12:16] <stgraber> so you shouldn't have had to turn off secureboot or turn on csm to make it boot
[12:17] <amitk> stgraber: http://dotcommie.net/?id=167 claims the debian boots fine on this machine but he disabled UEFI. I can't find anybody who has booted the liveusb with secure mode on
[12:18] <stgraber> yeah... I know for a fact that our media are fine (since they work on all 3 of my uefi+sb systems without CSM and without disabling SB). But it's clearly not impossible for a manufacturer to mess up their firmware in a way that it won't do UEFI boot from CD/USB...
[12:19] <stgraber> anyway, what install media were you using? cdrom or usb key?
[12:19] <amitk> stgraber: usbkey
[12:19] <stgraber> ok, how did you make it?
[12:19] <amitk> stgraber: usb-creator-gtk
[12:19] <cjwatson> try just dding it to the stick instead
[12:19] <stgraber> right, that's what I was about to suggest :)
[12:20] <stgraber> I suspect usb-creator and some other of those tools may try to be too clever and either forget to copy efi/ or miss the magic partition table we have on the .iso
[12:21] <stgraber> (usb-creator usually segfaults for me, so all my test installs are done from USB using a dd of the iso to the stick)
[12:21] <amitk> stgraber: yeah, i get it running about once every 3-4 tries
[12:24] <amitk> stgraber: annoyingly, with secure mode ON, I only get the option of "Windows boot manager" in Boot options, so I'm not very hopeful, but I'll try dd anyways
[12:26] <stgraber> amitk: I'd expect the menu to only show entries it detected. So if your original stick was somehow missing /EFI or wasn't considered as readable by the firmware, it wouldn't appear in the list.
[12:27] <stgraber> though broken firmwares are known to exist too, so we'll see ;)
[12:28] <amitk> stgraber: no luck with the dd'ed stick, it doesn't show up in the list of devices,
[12:30] <amitk> the usb stick only shows up with secure mode disabled and OS mode set to CSM & UEFI
[13:12] <dholbach> sarnold, jdstrand: thanks a lot for looking into upstart-app-launch/click-apparmor!
[13:15] <dholbach> hey robru, do you know who needs to approve https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 so it can get landed?
[13:16] <xnox> dholbach: anyone in the Indicator Applet Developers team.
[13:17] <dholbach> thanks xnox
[13:18] <xnox> mpt: ^ =) feel like approving multiarch changes in the app launcher? =))))
[13:18] <mpt> wat
[13:19] <xnox> mpt: =))) merry christmas =) i'm kidding ;-) although, you can be our backdoor ;-) it's been reviewed and the changes are correct, yet somehow the developers who have rights to upload that don't have launchpad permissions to do so.
[13:19]  * mpt reads the diff
[13:19] <mpt> No, I am Donny. I am out of my element.
[13:20] <mpt> I mean, I know what an architecture is, but that’s about it.
[13:21] <Laney> mock tudor
[13:23] <mpt> Baroque
[13:27] <doko> jdstrand: could you have a look at bug #1262570 ? want to have this changed for the test rebuild tomorrow
[13:32] <jdstrand> doko: ok, I'll get to it today
[13:32] <doko> thanks!
[13:47] <jdstrand> dholbach: np. fyi, I have a landing ask for click-apparmor, so it should be uploaded today
[13:48] <dholbach> jdstrand, that's great! :-)
[13:48] <dholbach> good work!
[13:54] <jdstrand> thanks! :)
[15:02] <plars> jdstrand: I'm having some issues with https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1257149 - it's gotten stuck at the same place twice in a row
[15:05] <jdstrand> plars: the regression testsuite will take a while, but 23 hours seems too long. did it ever pass?
[15:05] <jamesh> sil2100: did you have a chance to look at the mediascanner packaging review?
[15:05] <plars> jdstrand: no, it never finishes - just gets stuck there
[15:06] <plars> jdstrand: I can ^c out of it at that point
[15:06] <jdstrand> plars: are you able to run commands on the device manually?
[15:07] <plars> jdstrand: yes
[15:07] <jdstrand> ok, give me a second
[15:07] <jdstrand> well, more like a couple minutes
[15:07] <jdstrand> plars: this is on quantal?
[15:08] <plars> jdstrand: yes
[15:17] <jdstrand> plars: can you give the output of the 'sudo make tests' from http://paste.ubuntu.com/6600201/?
[15:17] <jdstrand> plars: that is the command that is taking a long time
[15:17] <jdstrand> plars: when it seems to hang, talk to me or sbeattie
[15:17] <plars> jdstrand: will do
[15:18] <jdstrand> well, that is the command that I believe is hanging. we'll know soon enough if it is an earlier command :)
[15:23] <plars> jdstrand: I don't find qrt-test-apparmor.tar.gz anywhere in the kernel regression tests
[15:23] <plars> jdstrand: I see ubuntu-qrt-apparmor.tar.bz2 but it doesn't appear to be the same tarball
[15:24] <jdstrand> plars: you generating it by running ./scripts/make-test-tarball scripts/test-apparmor.py from with QRT
[15:24] <jdstrand> (the second command in the paste)
[15:24] <jdstrand> s/from with/from within/
[15:27] <plars> jdstrand: hmm, I found the qrt tarball here, and from panda:~/autotest/client/tests/qrt/qa-regression-testing I see a test-apparmor.py, but not a make-test-tarball
[15:29] <sn33zy> can someone help me figure out how to design a script that executes after logging in from suspend?
[15:29] <sn33zy> like after you type in your password and such...
[15:29] <sn33zy> the how tos are confusing me...
[15:35] <jdstrand> plars: the point of make-test-tarball is this: http://paste.ubuntu.com/6600303/
[15:35] <jdstrand> plars: if you have test-apparmor.py, testlib.py, install-packages and apparmor/, then you are ok
[15:36] <jdstrand> plars: cd to that directory instead, then go to the step at: udo ./install-packages ./test-apparmor.py
[15:36] <plars> jdstrand: I have all of those except install-packages
[15:37] <plars> jdstrand: this is, perhaps, a hacked up tarball for purposes of the regression tests? no idea where they got it from
[15:37] <sil2100> jamesh: in the middle of looking right now!
[15:37] <jdstrand> plars: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/install-packages
[15:37] <jdstrand> plars: I think the duplicate make-test-tarball and install-packages.py, but I'm not sure
[15:38] <jdstrand> s/think the/think they/
[15:38] <plars> jdstrand: if you'd prefer, I can just bzr branch lp:qa-regression-testing and start from that, but I'm concerned that what I'm seeing in the kernel git doesn't line up with what you expect and may not be comparing the same
[15:39] <jdstrand> plars: I don't think there is a need to do that. they point of my paste is to get you an unpacked source with all dependencies install so you can run make followed by sudo make tests
[15:40] <jdstrand> if you have another way to get there, that's fine :) (notice the paste doesn't actually run the testsuite code at all)
[15:41] <plars> jdstrand: ok, let me first just try jumping ahead to there. I would assume that at this point all the deps have been installed by previous attempts
[15:41] <plars> meh, maybe not
[15:41] <jdstrand> plars: look for QRT-Packages in test-apparmor.py
[15:42] <plars> jdstrand: I just grabbed it from the one you pointed at
[15:43] <jdstrand> that'll work too
[15:57] <plars> jdstrand: the make step is failing with ‘PAGE_SIZE’ undeclared
[15:57] <plars> http://paste.ubuntu.com/6600399/
[15:58] <jdstrand> plars: ok, cool. can you update the bug? sbeattie, can you look at bug #1257149? in 'make' of apparmor regression tests: clone.c:62:19: error: ‘PAGE_SIZE’ undeclared (first use in this function)
[15:58] <plars> jdstrand: you think that could cause the whole thing to just hang there? rather than error out?
[15:59] <jdstrand> plars: let me look at the qrt script
[16:00] <jdstrand> plars: qrt is checking the return code of make
[16:00] <jdstrand> rc, report = testlib.cmd(['make'])
[16:00] <jdstrand> expected = 0
[16:00] <jdstrand> result = 'Got exit code %d, expected %d\n' % (rc, expected)
[16:00] <jdstrand> self.assertEquals(expected, rc, result + report)
[16:01] <jdstrand> so maybe make isn't giving an error
[16:02] <jdstrand> plars: can you adjust the script to output 'rc' at line 1435 after the assertEquals?
[16:03] <jdstrand> plars: and then run 'sudo ./test-apparmor.py' and see what happens? if you want to more quickly get there, feel free to comment out the various self.addTest() calls in main()
[16:03] <jdstrand> plars: (of course, you'll need ApparmorTestsuites)
[16:04] <plars> jdstrand: you mean line 1435 of test-apparmor.py? That line for me is     def test_parser_testsuite(self):
[16:05] <jdstrand> plars: hrm, it is out of date. hold on
[16:05] <plars> there are two places in that file that would match         rc, report = testlib.cmd(['make'])
[16:05] <jdstrand> plars: test_regression_testsuite()
[16:06] <jdstrand> plars: after the first self.assertEquals(expected, rc, result + report)
[16:07] <jdstrand> plars: output rc-- if see the output, we know that it didn't fail like it should have, which is a bug in the build process
[16:09] <sil2100> jamesh: hey! You guys want it to be handled by daily-build, right?
[16:12] <doko> infinity, slangasek: looks like the hotspot crash on i386 is an alignment issue. https://sourceware.org/ml/libc-alpha/2013-08/msg00372.html  There is a hack to revert that change in glibc.
[16:14] <doko> so maybe just apply this hack before the test rebuild? https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1261897
[16:16] <xnox> doko: i wonder if it's the same error that is getting exposed by libarchive, it does mmapped files in the test-suite.
[16:17] <xnox> (i386 only as well)
[16:24] <jdstrand> doko: hotspot-- you mean the zero issue?
[16:26] <doko> jdstrand, no hotspot, not zero
[16:26] <doko> the not-rebuilt i386 hotspot does segfault with 2.18, java -version
[16:27] <jdstrand> ok
[16:27] <jdstrand> I was excited for a moment :)
[16:29] <doko> jdstrand, which issue do you mean?
[16:29] <jdstrand> doko: the one that is preventing openjdk-7 builds
[16:30] <jdstrand> 2.4
[16:30] <doko> jdstrand, ahh, that one is fixed too
[16:30] <jdstrand> doko: btw, it occurred to me that we should have in trust the same version that rhel has in their upcoming release
[16:30] <doko> but no arm assembler interpreter in 2.4
[16:30] <jdstrand> s/in trust/in trusty/
[16:30] <doko> and which version is this?
[16:30] <jdstrand> that would allow both distros to share resources
[16:31] <jdstrand> I'm not sure, let me see
[16:31] <jdstrand> doko: but they are committed to supported openjdk-6. but they are using 1.11 and we are on 1.12. I thought, esp if openjdk-7 doesn't get demoted, that we should try to avoid that
[16:32] <jdstrand> doko: cause presumably they will pick one openjdk-7 for the new rhel
[16:32] <jdstrand> (and stick with it for others)
[16:33] <jdstrand> actually, it would be RedHat, Debian and Ubuntu to share resources
[16:35] <jdstrand> doko: looks like rhel 6 is on 2.4
[16:35] <jdstrand> doko: an RHSA from october lists java-1.7.0-openjdk-1.7.0.45-2.4.3.2.el6_4
[16:37] <jdstrand> doko: so yeah, getting us up to 2.4 sounds like the right thing to do. you mentioned no arm assembler interpreter in 2.4-- how big of a problem is this in reality? I thought arm perf was poor with opendk and no one used, but maybe I am misremembering
[16:37] <plars> jdstrand: it didn't seem to make it to my output line, but got some other errors
[16:38] <doko> jdstrand, it would be 3-4 times slower
[16:38] <jdstrand> 3-4 times slower for 0 users? :P
[16:38]  * jdstrand has no actual metrics
[16:39] <plars> jdstrand:  http://paste.ubuntu.com/6600606/
[16:40] <plars> jdstrand: I think trying to get the source earlier messed it up, let me kill that directory and try again
[16:41] <jdstrand> plars: maybe-- I meant to do a 'cd /tmp' prior to the apt-get source in the paste, but since you were running it manually, I didn't mention it
 jakub, it's not just blobs. did see it with my openjdk-7 build, just calling java -version
[16:41] <doko> * clm (~chatzilla@pool-71-248-177-155.bstnma.fios.verizon.net) hat #gcc betreten
 doko: then openjdk violates the ABI
 monoid is right that with old gccs you could get broken code too with certain options, but I doubt that is the case here
 anyhow glibc fixed it in git for 2.19, just imo their response time was incredibly slow
[16:42] <doko> infinity, ^^^didn't look what they did fix
[16:43] <infinity> doko: Yeah, I'm catching up on various pastes here.  I'll have to see if I can find out what the fix was.
 monoid, is this https://sourceware.org/git/?p=glibc.git;a=commit;h=584b18eb and https://sourceware.org/git/?p=glibc.git;a=commit;h=1818483b15d22016b0eae41d37ee91cc87b37510
 doko: yes
[16:46] <doko> infinity, ^^^
[16:46] <infinity> doko: Yeah, I just saw that in my git pull.  Deleted files tend to put up flags.
[16:47] <infinity> doko: I'll grab that, and the matching amd64 commit and do a little bit of testing here and upload.
[17:04] <doko> barry, for the test rebuild, I'll upload a dh_python2 which doesn't move the files to pyshared and symlinks these. will see what needs fixing in the packaging
[17:05] <doko> barry, I don't have the time to check for the 3.4 as supported version
[17:08] <mitya57> doko: http://codesearch.debian.net/search?q=pyshared+path%3Adebian%2F has some examples of packages relying on pyshared
[17:09] <mitya57> i.e. lsb, libxml2, libxslt, python-numpy, boost1.49, speech-dispatcher, liblinear
[17:09] <mitya57> on the first page
[17:26] <plars> jdstrand: http://paste.ubuntu.com/6600794/ has the latest output - I guess just adding print for the rc wasn't enough to make it through, but it *did* run to completion and reported the same PAGE_SIZE bug problem in the end
[17:41] <xnox> mitya57: some of them are red-herring
[17:41] <jdstrand> plars: cool. can you add the failed output to the bug?
[17:41] <mitya57> Yeah, I just wanted to note that there are still really buggy packages
[17:42] <mitya57> (buggy wrt the /usr/share/pyshared stuff)
[17:42] <plars> jdstrand: I added the pastebin link
[17:42] <jdstrand> that's cool
[17:43] <jdstrand> sbeattie: fyi, I added a qrt task to bug #1257149 and assigned it to you
[17:44] <jdstrand> plars: to be clear-- this test has never failed on any linux-ti-omap4 quantal kernel?
[17:44] <jdstrand> plars: rather, it never passed?
[17:44] <jdstrand> plars: or is this a new failure
[17:45] <plars> jdstrand: as far as I can recall it used to pass, psivaa do you recall seeing issues with the qrt-apparmor test before on quantal/omap4?
[17:46] <jdstrand> plars, psivaa: oh, if it used to pass, then maybe there is a regression. we should try with the last kernel
[17:46] <psivaa> plars: let me look
[17:47] <jdstrand> sbeattie: actually, I meant to do that against apparmor (though there is a qrt bug too with ppox)
[17:48] <plars> psivaa, jdstrand: I see in http://q-jenkins:8080/view/Kernel/view/Quantal-kernelSRU/job/sru_kernel-quantal-generic-armhf_omap4_panda_ES-serial/128/console as passing
[17:48] <doko> mitya57, thanks. a lot of fals positives too
[17:48] <plars> that was with 3.5.0-235.51-omap4 3.5.7.23
[17:48] <jdstrand> plars: does that show the apparmor version used?
[17:48] <psivaa> plars: i dont recon seeing this type of failure before.. looks pretty new
[17:48]  * sbeattie waves hello
[17:49] <jdstrand> sbeattie: there may be nothing for you to do
[17:49] <jdstrand> sbeattie: and hi!
[17:49] <sbeattie> hey jdstrand
[17:51] <plars> jdstrand: not that I can see
[17:51] <jdstrand> plars: what revision of qrt is that?
[17:51] <plars> jdstrand: no idea, whatever is currently in the kernel testsuite
[17:51] <jdstrand> plars: where is the kernel testsuite?
[17:52] <plars> jdstrand: the tests themselves are at git://kernel.ubuntu.com/ubuntu/autotest-client-tests.git
[17:52]  * jdstrand is curious about the AF_PPPOX test. tyhicks made a change in r1978 for it
[17:52]  * tyhicks looks
[17:53] <plars> jdstrand: looks like in the git log it was updated on Dec 9, but it doesn't say to which version
[17:54] <plars> jdstrand: the snapshot script he uses just does bzr branch lp:qa-regression-testing, so should be whatever was latest in trunk as of dec 9
[17:54] <jdstrand> plars: so, apparmor in quantal hasn't been updated since april. seems like there is some sort of non-apparmor regression happening with that kernel
[17:55] <jdstrand> plars: (for the PAGE_EXEC)
[17:55] <sbeattie> jdstrand: qrt/scripts/apparmor/patches/clone_test-define_pagesize.patch should be fixing the PAGE_SIZE issue
[17:56] <jdstrand> I'm checking git
[17:58] <doko> bah, mklanghorst did overwrite my mesa upload :-/
[17:59] <jdstrand> plars: when you ran the test manually, we didn't apply the patch sbeattie just mentioned ^
[17:59] <doko> mlankhorst, ^^^
[17:59] <mlankhorst> oh just fix it, EOW :P
[17:59] <jdstrand> plars: but when you ran test-apparmor.py, it should have done it for you
[17:59] <mlankhorst> doko: please learn to use xsf.git ;)
[18:00] <doko> mlankhorst, please no. will do it again, and then you have to keep it once llvm-3.3 is demoted ;p
[18:01] <plars> jdstrand: odd, I don't see anything under scripts/apparmor/patches
[18:01] <jdstrand> plars: oh, well, their git import is not picking up our patches
[18:01] <mlankhorst> sigh I'll take a look
[18:01] <jdstrand> s/is not/must not/
[18:03] <plars> indeed
[18:05] <plars> jdstrand: checking with bjf, but I don't see anything in their snapshot script that should prevent that directory I don't think... it's grabbing the whole apparmor dir from what I can tell
[18:08] <doko> mlankhorst, if you don't want to upload now, then please prepare a package for upload and point jdstrand or me to it, so we can upload once the llvm-3.4 b-d's are promoted
[18:10] <mlankhorst> ok sure
[18:10] <mlankhorst> doko: funnily I already considered doing it :P
[18:13] <mlankhorst> doko: but please let me know that in advance, mesa packaging is closely in sync with debian, so if we change it I should change it there too.
[18:15] <mlankhorst> doko: also why is llvm-3.4 dev enabled on powerpc, but debian/rules doesn't enable llvm for powerpc?
[18:15] <doko> mlankhorst, in mesa?
[18:15] <mlankhorst> yeah
[18:15] <doko> I never did check
[18:15] <mlankhorst> tsk
[18:16] <doko> mlankhorst, find a powerpc machine and test it ...
[18:16] <mlankhorst> (>= 1:3.3-4)
[18:16] <mlankhorst> for llvm-3.4-dev? :P
[18:16] <doko> not wrong
[18:16] <mlankhorst> how come
[18:21] <mlankhorst> anyway, re-uploaded :P
[18:42] <plars> jdstrand: ok, I was running from the qrt directory rather than the ubuntu_qrt_apparmor (both of which seem to be qrt... not sure why that's all necessary)
[18:42] <plars> jdstrand: but the patches dir is here for sure on this other tarball, and I'm thinking this is the one responsible for those tests so it's the right one to retry by hand
[18:43] <plars> s/by-hand/ with the test-apparmor script/
[18:44] <jdstrand> ok
[19:10] <tyhicks> plars: I ran the latest version of test-apparmor.py on an updated quantal amd64 VM and the test_domain test passed
[19:11] <tyhicks> plars: so the failure must be specific to armhf_omap4_panda
[19:14] <plars> tyhicks: I'm running it right now, and will give it some more time, but it takes forever. Hard to tell if it's hung or if it's just slow because of panda
[19:15] <sbeattie> tyhicks, plars: the PAGE_SIZE issue definitely an omap4 only issue
[19:15] <tyhicks> plars: the test failure that I'm talking about isn't the one that hangs, though
[19:16] <tyhicks> plars, sbeattie: search plars' earlier paste (http://paste.ubuntu.com/6600794/) for AF_PPPOX
[19:16] <tyhicks> that's the failure that I'm looking at
[19:16] <plars> sbeattie: for that, I was running from a bad location that lacked the patches dir
[19:16] <plars> sbeattie: I've corrected that now
[19:17] <sbeattie> tyhicks: ah, okay
[19:48] <plars> jdstrand: ok, it finally finished, and test-apport passed for me when I ran it here, so I have no idea why it's erroring out there
[19:48] <plars> or rather hanging
[19:48] <plars> something farther along?
[19:53] <jdstrand> yeah, I don't know :\
[21:59] <bdmurray> hallyn_: there are 3 uploads of cgroup-lite in the precise proposed queue
[22:05] <hallyn_> bdmurray: yes, please drop the first two (i explained it in the related bug :).  sorry about that.
[22:05] <hallyn_> yup
[22:05] <hallyn_> (that 'yup' was to another window)
[22:20] <hallyn_> all right ssh is really being annoying lately, giving me 'Too many authentication failures' if i have a few ssh keys loaded
[22:22] <stgraber> hallyn_: that's normal, you can only send a fixed number of keys per session, if you have more keys defined for a given session than that, only the first 3 (I believe) are sent
[22:22] <stgraber> so you need to define host or domain specific config in .ssh_config so it only selects keys that should actually work for the target host
[22:24] <hallyn_> stgraber: for things like amazon hosts that gets problematic
[22:24] <hallyn_> and in cases where i then have to go through an ssh proxy, i get to where i don't know how to get around it
[22:25] <stgraber> You can have multiple matching sections in ~/.ssh/config, so you can have something that says Host *.canonical.com => IdentityFile ...
[22:25] <stgraber> and then have a section which matches those and a few others and set the ProxyCommand
[22:26] <stgraber> (it just becomes hard for a human being to parse the resulting file ;))
[22:50] <hallyn_> stgraber: ok, and so i'm doing 'ssh -p 5820 ubuntu@localhost'
[22:50] <hallyn_> the ubuntu@localhost is a password-protected account only, no ssh key
[22:50] <hallyn_> how can i say 'dont try any $(*&%($*&% ssh keys for this one' ?
[22:51] <hallyn_> sure i suppose i can *give* it a ssh key.  but there's no ssh port open to it from te outside world, seems a waste...
[22:52] <hallyn_> fine.  it's cheesy.  i hate it.  but i did it.
[22:56] <xnox> doko: hm, i'm spotting triplet-qualified python-config binaries, is that indication that I can cross-compile python extensions, or not really yet?
[23:08] <stgraber> hallyn_: I'd define a "Host localhost-5820" entry that's an alias for localhost with Port set to 5820 and setting the authentication as wanted
[23:08] <stgraber> hallyn_: specifically:
[23:08] <stgraber> Host localhost-5820
[23:08] <stgraber>     HostName localhost
[23:08] <stgraber>     Port 5820
[23:09] <stgraber>     User <something if you want>
[23:09] <stgraber> ...
[23:09] <stgraber> then just "ssh localhost-5820" and that'll work
[23:13] <hallyn_> stgraber: (1) what is the bit that says 'i want kbd auth' ?
[23:13] <hallyn_> stgraber: (2) this is all very static, my env is not very static :)
[23:14] <hallyn_> now maybe i should be passing -osomething...
[23:14] <hallyn_> but i've added the ssh key, so for the moment i'm good.  though i still usually have >3 keys in mykeyring...
[23:14] <stgraber> hallyn_: you can also do localhost-* in the config and then use %h (not sure all variables support it though)
[23:15] <stgraber> hallyn_: for password auth, I think you want PubkeyAuthentication no
[23:15] <stgraber> hallyn_: that way ssh won't send any of your public keys and will just fallback to whatever other mechanism you have (including password auth)
[23:16] <stgraber> hallyn_: (man ssh_config for the whole list of options and variables)
[23:17] <hallyn_> stgraber: so yeah i think 'ssh -opubkeyauthentication=no' might have worked for me.  i'll have to remmeber that.
[23:17] <hallyn_> it just would be easier if ssh didn't balk so quickly :)
[23:18] <stgraber> hallyn_: I guess it's the server cutting the connection on the client. The client would need to have a way of pooling auth methods and batching them 3 by 3 (or whatever many the server accepts), so it'd be slow (because of renegociating a connection x many times) but it'd at least work.
[23:19] <stgraber> I guess people with crazy amount of keys probably also have complex .ssh/config that avoids that kind of problem so there wasn't enough people nagging them to get something like that implemented
[23:34] <doko> xnox, it can. see zope.interface, python-stdlib-extensions
[23:35] <mlankhorst> doko: it's dep-waiting on llvm-3.4-dev..
[23:35] <mlankhorst> it - > mesa
[23:37] <xnox> doko: sweet, let me do this for boost =))))
[23:39] <xnox> doko: also what do you think about boost-python, shipping unversioned libboost-python.so in /usr/lib/pythonX.Y/config-X.YN-triplet/ dirs? it's kind of like c++ api to write python extensions (so not an extension by itself) and needs to be compiled per python version/config (normal, debug, etc)
[23:40] <doko> mlankhorst, known. waiting for jdstrand to review my MIR report
[23:41] <doko> xnox, you have to look if it does do the right thing. it relies on using the sysconfig module for the target.  if too many bits from the sys module are used for the configuration, it gets it wrong
[23:42] <xnox> doko: ack.