[00:11] <infinity> hallyn: No objections from me, except that you gave mwhudson all the credit. ;)
=== Spads_ is now known as Spads
[00:39] <smoser> pitti, i'd appreciate your thoughts on bug https://bugs.launchpad.net/maas/+bug/1391354
[00:39] <ubottu> Ubuntu bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete]
[01:19] <hallyn> infinity: d'oh, i thought it was purely his.  that won't fly.  who exaclty is Ben?
[01:19] <infinity> hallyn: Ben Collins.
[01:19] <hallyn> thx
[01:19] <infinity> hallyn: I was mostly kidding, I don't think Ben and I care about the credit, we have more than enough.
[01:20] <infinity> hallyn: But if you're trying to be accurate, go for it. :)
[01:22] <infinity> Okay, seriously brain, WTF?  Why did you just start humming 'Total Eclipse of the Heart'?
[01:24] <hallyn> infinity: damn you
[01:24] <hallyn> were i only too young to know that song
[01:25] <infinity> hallyn: I've already moved on from humming it to singing it.  Send help.  I'm scared.
[01:25] <hallyn> maybe tych0 can help with a meshugga link
[01:25] <hallyn> anyway, package built fine and looks good on th eporter box
[01:25] <infinity> \o/
[01:25] <hallyn> so what the heck, pushing.  thanks again
[01:26] <hallyn> (but no thanks for the crap now in my head)
[01:26] <tych0> https://www.youtube.com/watch?v=DHdFTxu5M38
[01:26] <tych0> at your service
[01:26] <infinity> We'll let that bake in vivid for a short while and see if anyone whines about it being crap, then I'd like to SRU that changeset back to T and U.
[01:26] <infinity> hallyn: I'd also like the qemu-slof dep in a trusty SRU, but that depends on me first getting a newer SLOF in -updates and promoting it to main.
[01:27] <infinity> hallyn: And actually, forget I mentioned that, cause it should also go hand-in-hand with getting IBM to backport some LE fixes to that qemu version, which hasn't happened yet.
[01:27] <hallyn> well at least i got the libvirt bit needed to giver permission to read slof into t,u sru
[01:27] <hallyn> ah
[01:27] <hallyn> tych0: thanks.  i'm on a hotspot.  trying to decide how precious this is to me.
[01:28] <hallyn> pretty precious...
[01:29] <infinity> I have to be in just the right mood for metal this metal.
[01:30] <infinity> I might settle for a middleground of Soundgargen's Badmotorfinger as a palate cleanser.
[01:30]  * tych0 sets mood to awesome
[01:31] <tych0> the mood is always right for the best band in the world
[01:32] <infinity> tych0: I agree, but seems odd, given that no one mentioned the Tea Party yet.
[01:32] <hallyn> this conversation is starting to soar over my head
[01:33] <tych0> or into the political gutter (:
[01:33]  * tych0 ducks
[01:33] <infinity> tych0: Wrong Tea Party. ;)
[01:34] <tych0> i figured, but the joke was just right there
[01:34] <infinity> tych0: It sure was.
=== vrruiz_ is now known as rvr_
=== rvr_ is now known as rvr
[04:08] <dobey> mhall119: it's the same spammer on -discuss again. how many times do you need to ban him?
[04:11] <slangasek> well, mikeeusa is habitually immune to social pressure, so.
[04:46] <mhall119> dobey: once for every email address he has it seems
[05:13] <Mirv> pitti: is there a way for normal people to re-run autopkgtest? there's one amd64 autopkgtest that would probably like a rerun: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
[05:32] <infinity> pitti: Is there a way to specify that a DEP-8 test should only be triggered for rdeps, not for the package itself?
[05:33] <infinity> pitti: It makes about 0 sense for glibc's rebuild test to run immediately after I just proved glibc can build from source by uploading it.
[05:35] <infinity> pitti: Err, for deps, not rdeps.  But you know what I mean.
[05:43] <Mirv> now it got re-run and passed
[05:57] <Mirv> oh, not, it was for another package
[06:13] <Unit193> pitti: Good morning.
[06:15] <pitti> Good morning
[06:16] <pitti> Mirv: yes, it's actually quite simple: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test shows how we do this in CI, and /usr/share/doc/autopkgtest/README.running-tests.html shows all scenarios
[06:17] <pitti> Mirv: apparently someone already re-ran, or it fixed itself
[06:18] <pitti> infinity: not at the moment, I'm afraid
[06:18] <pitti> infinity: we might teach britney about such exceptions of course (glibc, gcc, and  binutils would be the only ones, I think)
[06:27] <Mirv> pitti: I mean, re-run it on jenkins? I've done bookmarks on how to reproduce locally if needed.
[06:27] <Mirv> pitti: it seems it run again for glibc, and tested the new qtbase at the same time so both were marked as Passed
[06:27] <pitti> Mirv: you should be able to log in at http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/ and re-run them
[06:28] <Mirv> pitti: right, I think I can. so they always run against whole -proposed or something, there doesn't need to be a parameter "run package xyz tests for getting it pass for package zyx migration?"
[06:28] <pitti> Mirv: right, they need to succeed in -proposed, nothing to parameterize
[06:29] <Mirv> then that's easy. I'll make a note. thanks!
[06:29] <pitti> and meh, our testbeds are totally overloaded
[06:34] <pitti> smoser, infinity: wolfe-09 is AWOL; reboot, s'il vous plaît ?
[06:34] <pitti> smoser, infinity: wolfe-07 too
[06:35] <smoser> pitti, i will bounce.
[06:36] <smoser> this is possibly outcome of over commit there.
[06:36] <pitti> smoser: wolfe-06 is really slow; is that maybe a problem on the host (and thus that needs reboot), or did the VMs crash independently?
[06:36] <pitti> or overcommitting?
[06:36] <pitti> ah
[06:36] <pitti> smoser: so if you dial them down to 4 GB RAM, might that help?
[06:37] <smoser> maybe
[06:39] <RAOF> Oh, is this why my CI is going really slowly? :)
[06:39] <Noskcaj> Can someone please retry din on all arches? It needed a newer version of libircclient (which we now have)
[06:40] <pitti> RAOF: this is ppc64el only; x86 CI is really slowly as our 4 static testbeds are aching under the doubled number of tests since utopic (and they were aching already there..)
[06:40] <pitti> Noskcaj: yeah, will do
[06:40]  * RAOF thought everything was on ScalingStack now. Or is that just the buildds?
[06:40] <Noskcaj> ty
[06:41] <pitti> RAOF: just the buildds; still working on moving autopkgtests to Bootstack
[06:43] <smoser> pitti, wolfe-07 and wolfe-09 rebooted. console logs
[06:44] <smoser> wolfe-07: http://paste.ubuntu.com/8957820/
[06:44] <smoser> wolfe-09: http://paste.ubuntu.com/8957823/
[06:44] <pitti> smoser: "Unable to handle kernel paging request for data" -- that does sound related to overcommitting?
[06:45] <smoser> i dont know. itspossible i'm just doing something stupid on the host.
[06:46] <smoser> pitti, i'm really sorry, but i have to fall asleep.
[06:46] <pitti> smoser: no worries, thanks
[06:46] <Mirv> hey, I'd need help from core-dev since I don't have upload rights to the Qt's "-gles" packages.
[06:46] <pitti> smoser: I'll ask infinity once he comes back, the others are really slow and failing too
[06:46] <smoser> pitti, https://bugs.launchpad.net/maas/+bug/1391354 . if you have a right way  to solve that, i'd appreciate it.
[06:46] <ubottu> Ubuntu bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete]
[06:46] <pitti> smoser: yep, will look at that and comment on the bug
[06:47] <Mirv> apt-get source qtlocation-opensource-src-gles , edit debian/control's line 61 to be << 5.3.2-0~ instead of 5.3.2-2~
[06:47] <smoser> see the bug referenced there for mroe contex.t
[06:47] <smoser> good night all.
[06:47] <Mirv> I was able to decipher http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt and realized there's a wrong Breaks
[06:49] <Mirv> debdiff http://pastebin.ubuntu.com/8958003/
[06:51] <Mirv> oh... unping, it's in universe unlike the normal variant!
[06:51] <Mirv> sorry for the noise
[06:53] <pitti> Mirv: confused -- that debdiff wouldn't do anything AFAICS
[06:53] <pitti>  qtdeclarative5-qtlocation-plugin-gles | 5.3.2-0ubuntu2 | vivid-proposed/universe | all
[06:53]  * Mirv gets more coffee
[06:53] <pitti> oh, ok, the new version is in -proposed
[06:54] <Mirv> pitti: it's blocking proposed migration since the new transitional package cannot be installed since the qml module's Breaks has too high version
[06:54] <pitti> Mirv: right; and you are saying that you can just upload it yourself?
[06:54] <Mirv> pitti: yes, I just did since I'm MOTU nowadays.
[06:57]  * pitti yays at jenkins just breaking a gazillion tests with some java exception
[06:58] <pitti> die, jenkins, die!
[07:05] <infinity> smoser: Err, are you overcommitting RAM, or just CPU?
[07:05] <infinity> smoser: CPU overcommit works quite well, RAM overcommit will lead to nothing but pain.
[07:06] <pitti> hey infinity  -- btw, please hold on with rebooting wolfes; that causes tons of x86 jobs to fail with a jenkins error due to the braindead way jenkins handles its jobs
[07:06] <pitti> and the x86 ones are stalled enough without me having to retry a gazillion jobs :/
[07:06] <infinity> pitti: I hadn't intended to reboot anything.
[07:06] <infinity> pitti: I'm not really here.
[07:06] <pitti> infinity: right, but I asked for that above
[07:07] <pitti> infinity: ah, I must not be fully awake yet then, talking to an illusion :)
[07:34] <Noskcaj> I don't have the internet quality to test built, but we can probably sync jocaml
[07:34] <pitti> smoser: I responded to the bug
[07:38] <ari-tczew> seb128: I've prepared a merge of gimp, it means I stole your merge. Hope you're not angry :-)
[07:46] <seb128> ari-tczew, no worry, thanks for doing it
[07:58] <Noskcaj> elkcode should build after a retry
[07:58] <Noskcaj> seb128, What's required for gtk 3.14 to land?
[07:59] <seb128> Noskcaj, work
[07:59] <Noskcaj> Anything i can help with?
[07:59] <seb128> Noskcaj, http://pad.ubuntu.com/gtk-update-v
[07:59] <seb128> Noskcaj, feel free to work on some of the bugs
[07:59] <seb128> bugs/issues
[07:59] <Noskcaj> ok. I'll see if there's anything i can do
[08:00] <seb128> thanks
[08:00] <seb128> if you work on something please note it down, or let #ubuntu-desktop know at least, to not duplicate work
[08:02] <didrocks> Riddell: hey, kind reminder about http://summit.ubuntu.com/uos-1411/meeting/22332/update-to-bluez-5/ today at 3PM UTC, some KDE input will be appreciated
[08:02] <didrocks> cyphermox: as well ^
[08:18] <Noskcaj> seb128, What version of gnome-disk-utility was the issue found?
[08:19] <seb128> Noskcaj, not sure, I'm not the one who wrote that one down, the one in vivid I think
[08:20] <Noskcaj> It sounds like upstream fixed the issue in the latest point release, so i was hoping that it was an older version and it wasn't an issue
[08:21] <seb128> could be, check with Laney when he gets online, I think he's the one who wrote that one down
[08:21] <Noskcaj> ok
[08:22] <darkxst> seb128, inspector requires libgtk-3-dev to be installed for the keybindings to work
[08:23] <seb128> I think that's a larsu's item, maybe say that on #ubuntu-desktop rather?
=== Spads_ is now known as Spads
[09:06] <Laney> Noskcaj: seb128: yeppers, that is fixed in 3.12
[09:06] <Laney> DELETE!
[09:06] <seb128> :-)
[09:37] <Mirv> Qt 5.3.2 has migrated now to release pocket except for one small package which requires Ubuntu specific change (transitional package until 16.04 LTS...)
[11:03] <cjwatson> RAOF: gnome-do's failing to build; it seems to be looking for dbus-sharp.dll in the wrong directory for some reason (/usr/lib/mono rather than /usr/lib/cli).  Do you know what's up here?
[11:20] <Mirv> qtgraphicaleffects migrated now too
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== Trevinho_ is now known as Trevinho
=== MacSlow is now known as MacSlow|lunch
=== MacSlow is now known as MacSlow|lunch
[13:30] <highvoltage> F/win 34
[13:46] <LocutusOfBorg1> cjwatson, you rock man :)
=== dpm_ is now known as dpm
[13:47] <LocutusOfBorg1> two or three transitions in a row :D
[14:01] <ebel> packages.ubuntu.com isn't working well for me. Not showing me utopic packages, even when I directly access it http://packages.ubuntu.com/search?suite=utopic&keywords=postgresql-9.4 ?
[14:02] <ebel> google cache is showing previews which don't match actual page, e.g. http://packages.ubuntu.com/utopic/nodejs
=== adam_g` is now known as adam_g
=== oSoMoN is now known as oSoMoN|afk
[14:49] <cjwatson> doko: Is it intentional that "java -client" no longer works on ppc64el?
[14:50] <cjwatson> doko: (causes java-gnome to FTBFS)
[14:53] <mardy> tedg: hi! Does upstart (or libubuntu-app-launch) check that the APP_URIS are actually valid URIs, or can I pass any parameter there?
[14:55] <tedg> mardy, There's light checking, which you could probably easily trick. But I'd recommend avoiding that. What are you trying to do?
[14:58] <mardy> tedg: I need to pass a simple string (with no spaces) and then the address of a unix socket; I can easily prepend some scheme:// to them, if needed
[14:59] <tedg> mardy, From where to where? For an application?
[14:59] <tedg> mardy, Not sure how the launcher would know to pass those?
[15:00] <mardy> tedg: ah, sorry, I didn't tell you the context: from a trusted helper to an untrusted helper; something like the pay service is doing
[15:01] <mardy> tedg: one of the parameters is indeed the mir socket address
[15:01] <pitti> infinity: glibc is a valid candidate now; *phew* (I overrode three regressions which are not due to glibc)
[15:02] <caribou> slangasek: I still haven't found sponsoring for the libnss-ldap merge. SRU for all existing unbuildable pkgs are waiting for that (LP: #1387594)
[15:02] <ubottu> Launchpad bug 1387594 in libnss-ldap (Ubuntu) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594
[15:02] <caribou> the merge bug is LP: #1389152
[15:02] <ubottu> Launchpad bug 1389152 in libnss-ldap (Ubuntu) "please merge libnss-ldap 265-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1389152
[15:03] <tedg> mardy, Ah, so we do far less checking in that case. We expect the pre-start helper to do the work there.
[15:03] <infinity> pitti: Thanks for babysitting.
[15:04] <pitti> the giant x86 queue is done, too
[15:05] <pitti> mkdir: cannot create directory ‘/var/cache/autopkgtest/’: Read-only file system
[15:05] <pitti> argh, seriously? /var/cache is r/o on touch?
[15:06] <barry> pitti: hi.  would you have some time today to chat about running adt tests on the phone?
[15:06] <pitti> rhuddie: so, I was fixing the first half of reboot support for tests on the phone
[15:06] <pitti> rhuddie: but now I found that, and need to now ponder how I work around that :/
[15:06] <pitti> barry: sure, what's up?
[15:07] <rhuddie> pitti, ah, thanks for the update. so it's not as simple as it first seemed :)
[15:08] <barry> pitti: i have several questions.  after discussing with qa, i want to turn this test plan into dep 8 tests: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-image
[15:08] <pitti> rhuddie: yeah, touch images breaking the file system in just about every way requires a lot of workarounds :/
[15:08] <barry> pitti: i know how to write code to flex each of these test plans, but i have a few problems.  i can't even get the basic adt-run ... --- ssh -s adb to run tests
[15:08] <barry> pitti: it just does some stuff then exits
[15:09] <pitti> barry: which version are you using?
[15:09] <mardy> tedg: cool, thanks
[15:09] <pitti> barry: also, "some stuff" -> I'd need the full output log, preferrably with -d
[15:09] <barry> % dpkg-query -W autopkgtest
[15:09] <barry> autopkgtest	3.7git3
[15:09] <barry>  
[15:09] <pitti> barry: I usually start with trying to run the calculator tests, so perhaps start with that?
[15:09] <barry> (i think adt-run doesn't have a --version)
[15:10] <pitti> barry: adt-run -o /tmp/out --click com.ubuntu.calculator --- ssh -s adb -- -ps3kr1t
[15:10] <pitti> barry: unless your password is 0000, then you can leave out the -p bit
[15:10] <pitti> barry: if that fails, please pastebin /tmp/out/log
[15:10] <barry> pitti: yep, i can generate that for you (the debug output).  another question, is adt-run over a _amd64.changes file supposed to work?  i can't get that to work either
[15:11] <barry> pitti: let me try that
[15:11] <pitti> barry: yes, but only on a r/w target (QEMU, schroot, etc.), not on a r/o phone for obvious reasons
[15:11] <barry> pitti: yep sure.  okay, let me break each step down and give you output and we'll see if we can make this work (or fix my misunderstandings ;)
[15:12] <pitti> barry: right; start with the calculator tests, and we'll work from there
[15:12]  * barry nods
[15:12] <pitti> barry: the initial phone setup always give most of the worries/variability
[15:15] <rhuddie> pitti, for bootspeed testing I was using one of the cloud images from adt-buildvm-ubuntu-cloud, but that doesn't have a UI, so I'm missing various log files expected by the tests
[15:15] <rhuddie> pitti, so I'm wondering how I can get adt-run to work with a standard ubuntu qemu image?
[15:18] <pitti> rhuddie: do an install into a VM, then copy /usr/share/autopkgtest/adt-setup-vm into that VM, run it (with sudo)
[15:18] <pitti> rhuddie: after that the VM should be prepared
[15:18] <pitti> rhuddie: (disclaimer: I haven't tried that myself yet)
[15:19] <barry> pitti: calculator click tests ran.  they failed but they ran.  let me see if i can reproduce my problem from yesterday
[15:19] <rhuddie> pitti, ooh, thanks, I'll give that a go :)
[15:19] <pitti> rhuddie: but looking at the script I see nothing that should fail
[15:19] <pitti> rhuddie: that script is supposed to be the common "turn something into an adt capable image" script, for vmdebootstrap, cloud-init based images, nova boot, etc.
[15:20] <arges> tych0: hey for bug 1384751 why did you make the version ubuntu3.14.10.1 instead of ubuntu3.1?
[15:20] <ubottu> bug 1384751 in lxc (Ubuntu Utopic) "checkpoint restore fails with /usr/lib/x86_64-linux-gnu/lxc/lxc-restore-net: not found" [High,Triaged] https://launchpad.net/bugs/1384751
[15:20] <pitti> barry: I have one or two failures as well, but some 30 successes; or do yo mean they all failed?
[15:20] <barry> pitti: no, just a few failed
[15:20] <pitti> barry: you shoudl see some numbers being auto-typed in and the UI moving, not just calculator stopping and starting all the time
[15:20] <tych0> arges: probably because i don't know anything about packaging :)
[15:20] <pitti> barry: ok good, that's expected
[15:20] <tych0> arges: should i update it?
[15:20] <tych0> arges: or, what's the best way to proceed
[15:21] <arges> tych0: i mean it _really_ doesn't matter, but i'd probably use ubuntu3.1
[15:21] <tych0> arges: oh, actually, perhaps hallyn can elaborate?
[15:22] <tych0> arges: i'm happy to change it, though
[15:22] <arges> yea if hallyn's ok with that version that's fine too. just wondering
[15:24] <barry> pitti: here is my ..._amd64.changes file.  would you expect this to work: adt-run system-image_3.0-0ubuntu1_amd64.changes --- qemu adt-vivid-i386-cloud.img
[15:24] <barry> pitti: http://paste.ubuntu.com/8966156/
[15:25] <pitti> barry: no, because you didn't include teh source there
[15:25] <mitya57> Does anybody know why texlive-extra can't migrate? update_excuses tells it's a valid candidate.
[15:25] <pitti> barry: a Debian .changes has both the .dsc and the .debs in the .changes, thus it includes all information
[15:25] <pitti> barry: like that you additionally need to specify the .dsc (or the source tree) after the .changes
[15:26] <pitti> mitya57: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says it makes texlive-full uninstallable
[15:26] <barry> pitti: okay, that makes sense.  i'm not sure why sbuild isn't producing rith right .changes file, but okay
[15:26] <pitti> mitya57: at that point you need a chroot or chdist with -proposed and see what's broken if you try to install them both
[15:26] <mitya57> Oh, one more page to look at. Thanks pitti!
[15:26] <pitti> barry: $build_source = 0 in ~/.sbuildrc?
[15:26] <pitti> barry: I have that, as for ubuntu builds it's generally what I want
[15:27] <pitti> barry: so, adt-run foo.changes foo.dsc
[15:27] <pitti> barry: which is equivalent to adt-run foo1.deb foo2.deb ... foo.dsc
[15:27] <barry> pitti: nope, but i'll bet that's the default
[15:27] <pitti> barry: i. e. it just expands all the .debs and the .dscs in the .chagnes and pretends you would have specified them individually
[15:27] <barry> pitti: so no different from say: adt-run -B *.deb foo.dsc
[15:28] <pitti> barry: correct; just more convenient to say adt-run foo.changes to test a debian upload
[15:28] <pitti> barry: right, and -B
[15:28] <barry>        BUILD_SOURCE
[15:28] <barry>               BOOL type.  By default, do not build a source  package  (binary
[15:28] <barry>               only  build).   Set to 1 to force creation of a source package,
[15:28] <barry>               but note that this is inappropriate for binary NMUs, where  the
[15:28] <barry>               option will always be disabled.
[15:28] <barry>  
[15:28] <pitti> barry: ah ;)
[15:28] <barry>               Default:
[15:28] <barry>  
[15:28] <barry>               $build_source = 0;
[15:28] <barry>  
[15:28] <barry> pitti: :)  okay, the world makes sense again
[15:29] <barry> pitti: thanks.  let me run with this for a bit and i'll ping you again if i get stuck
[15:29] <barry> pitti: i will definitely have questions about adt-run and device reboots
[15:30] <pitti> barry: yeah, that's what I'm currently working on; reboot works fine for qemu, but touch makes that a little harder
[15:30] <pitti> (testing a fix now)
[15:30] <pitti> or, rather, "workaround"
[15:30] <barry> pitti: ack, nice
[15:33] <hallyn> tych0: arges: this is about the lxc version for sru?
[15:33] <tych0> hallyn: yeah
[15:33] <arges> hallyn: yup
[15:33]  * hallyn waits on a slow rmadison...
[15:33] <hallyn> come on ...
[15:34] <arges> hallyn: 'rmadison -a source lxc' is a bit faster
[15:34] <hallyn> ah
[15:34] <hallyn> ok, so yeah ubuntu3.1 sould be fine (though i don't knwo whwat ubuntu-rtm/14.09 pocket is),
[15:34] <arges> hallyn: its for the phone
[15:35] <hallyn> the 14.10.1 is required if there are more than 1 older release with the same version #
[15:35] <hallyn> arges: yes, but will it need a separate update, or will it be updated from the utopic pocket?
[15:35] <hallyn> if the former, then we do need ubuntu3.14.10.1 in utopic so rtm can uplaod something
[15:36] <hallyn> i guess this issue has died down since we have shortened the non-lts life cycle
[15:36] <hallyn> interesting
[15:36] <arges> hallyn: i'm not sure, but i generally haven't worried about it
[15:36] <hallyn> arges: i've definately seen it be a problem.  but not in awhile
[15:37] <hallyn> arges: do you wnat to chang eit to ubuntu3.1 inline?
[15:37] <hallyn> (dunno if you have that power :)
[15:37] <arges> hallyn: yea 3.1 would make the most sense. so reupload it and I'll accept the new one
[15:37] <hallyn> not sure i still have that
[15:37] <arges> hallyn:  i don't. you'll have to re-up or tych0 will
[15:38] <tych0> arges: just the debdiff with s/14.10.1/.1 ?
[15:38] <hallyn> i can't re-up.  i don't have it.
[15:38] <arges> tych0: yup
[15:39] <tych0> arges: ok, will do in a sec
=== oSoMoN|afk is now known as oSoMoN
[15:39] <hallyn> arges: are you sponsoring his directly then?
[15:45] <arges> hallyn: its easier if someone else sponsors so I can do my SRU magic
[15:45] <arges> otherwise we'll need another SRU team member to do the approval
[15:48] <tych0> arges: hallyn: hmm, i'm confused
[15:49] <tych0> the debdiff doesn't actually have "14.10" in it anywhere
[15:50] <arges> tych0: yea whomever sponsored it must have changed it
[15:50] <hallyn> tych0: pastebin the debdiff?
[15:50] <hallyn> or, people.canonical.com it :)
[15:51] <infinity> arges: That formality is a bit silly.  If you review someone else's upload and it's all good except for a spelling mistake or bad version or something, it's entirely reasonable to sponsor a fixed upload, triple check the diff between previous and current to make sure all you changed is the one thing, and accept it.
[15:51] <tych0> hallyn: http://files.tycho.ws/tmp/utopic.patch
[15:51] <infinity> arges: In general, I agree that you shouldn't accept your own uploads, but the rules don't exist for the sake of rules, they exist to stop you backdooring the process.
[15:52] <arges> infinity: gotcha.
[15:52] <arges> tych0: hallyn i'll sponsor it
[15:53] <hallyn> arges: but not as is
[15:54] <arges> hallyn: yea i'll fix it
[15:54] <hallyn> ok :)  thanks
[15:54] <pitti> rhuddie: ok, I'm over this, now hitting the next problem :)
[15:55] <tych0> arges: gracias
[15:55] <rhuddie> pitti, thank you! adt-setup-vm did the job  nicely
[15:55] <pitti> rhuddie: great
=== neunon_ is now known as neunon
[16:14] <mitya57> Can some archive admin please look at bug 1389841 and bug 1389843? Because of that, osm-gps-map is stuck in -proposed and thus the version in vivid is less than in trusty-updates.
[16:14] <ubottu> bug 1389841 in creepy (Ubuntu) "Remove creepy from vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1389841
[16:14] <ubottu> bug 1389843 in gpxviewer (Ubuntu) "Remove gpxviewer from vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1389843
[16:15] <mitya57> (also, that trusty SRU should not have been sponsored / migrated to updates without the equivalent utopic/vivid uploads)
[16:16] <barry> pitti: question: is there anything in d/t/control that can be used to limit certain dep 8 tests to only running on a device, and others to *not* run on a physical device?
[16:16] <pitti> barry: not in d/t/c, as it's whoever runs adt-run who decides where to run it
[16:17] <pitti> barry: however, you tests can of course detect what kind of environment they are running in, and skip themselves if they find an inappropriate one
[16:17] <pitti> barry: aside from that there are the "isolation-machine" and "isolation-container" restrictions which tests can declare to avoid e. g. getting run in a schroot
[16:17] <barry> pitti: ack, that's the way i'll probably do it.  some of the tests will require flashing the device, and it only makes sense to run some of the tests on a physical device
[16:17] <barry> (e.g. reboot, and then post-reboot verification)
[16:17] <pitti> barry: in the future we'll have a more fine-grained way of saying "we want these tests to run on this set of testbeds", but this will only be advisory
[16:18]  * barry nods
[16:18] <pitti> barry: eek
[16:18] <barry> pitti: yeah.  that makes it more fun
[16:18] <pitti> barry: right, then something like checking system-image-cli and if that fails, skip the test (i. e. print a message and exit 0) seems fine
[16:19] <pitti> barry: I'm sure this will fail in all sorts of interesting ways :)
[16:19] <barry> pitti: indeed :)
[16:20] <pitti> ogra_: oh, could it be that "SetProperty ssh true" is not persistant across reboots?
[16:20] <pitti> rhuddie: ^ (next reboot+touch error fixed, running into that now :)
[16:20] <ogra_> pitti, it definitely is persistent
[16:21] <pitti> ogra_: hm, doesn't seem to here, but I'll check more closely
[16:23] <pitti> ogra_: ah, I guess the bit that doesn't survive is the adb forward
[16:23] <ogra_> ah, yeah
[16:25] <pitti> ogra_: ah yes, that was it
[16:26]  * pitti ponders how to fix that
[16:26] <ogra_> pitti, you could dump somethin into dbus-property-service
[16:27] <pitti> ogra_: nah, I need to call adb forward again, I just need to remember somehow to which port I forward
[16:27] <ogra_> ah, k
[16:28] <pitti> rhuddie: ok, that's something for tomorrow then; I have a meeting now, and then EOD
[16:28] <pitti> rhuddie: but at least I have a successful reboot test on the phone now (just need to turn my hack for ^ into a proper solution)
[16:28] <rhuddie> pitti, good progress, no less, thank you :)
[16:32] <slangasek> caribou: I don't have time to review this merge at the moment, but a first glance shows that an awful lot of the Ubuntu delta has been dropped with no explanation in the changelog.  I don't think this is sponsorable as-is
[16:33] <caribou> slangasek: most probably because the ubuntu specific is now in the upstream (i.e. debian) patches
[16:33] <caribou> slangasek: I thought that it did not require a specific mention as it was now part of the upstream debian package but I can add specific details
[16:34] <slangasek> caribou: no, there are changes dropped on the floor here, and I want to know why :)
[16:34] <caribou> slangasek: and I was not expecting *youù
[16:34] <caribou> oups, you to do the merge
[16:35] <caribou> infinity had done a first pass but he's off & I don't want to bother him with that
[16:35] <slangasek> ok, then it's perhaps best left until he comes back
[16:36] <caribou> slangasek: as long as nobody rebuild the existing libnss-ldap package
[16:36] <caribou> slangasek: I sent him a detailed email with what I had done in the merge. So you're right, better to wait until he's back
[16:45] <caribou> slangasek: just checked; all changes are either kept or now in upstream patches. I'll adapt the changelog
[16:45] <caribou> slangasek: I'll see with infinity when he's back
[16:49] <slangasek> caribou: well, so far I've identified one change that was dropped from the delta: the build-dependency on po-debconf has been reintroduced.  But yes, better changelog explaining why things like debian/patches/fix-ethers-truncation.patch have been dropped would be useful
[16:49] <smoser> pitti, i updated bug 1391354.
[16:49] <ubottu> bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete] https://launchpad.net/bugs/1391354
[16:49] <smoser> oh. and you responded already
[16:49] <smoser> :)
[17:01] <caribou> slangasek: will do; fix-ethers-truncation.patch is now fixed upstream
=== dholbach__ is now known as dholbach
=== dpm is now known as dpm-afk
[19:39] <ChrisTownsend> hallyn: stgraber:  Hey Guys!  I'm getting an error when using a Vivid LXC on a Trusty host:
[19:39] <ChrisTownsend> ** (process:851): WARNING **: Unable to get PID list from cgroup manager: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: invalid request
[19:39] <ChrisTownsend> Works fine with a Utopic host.
[19:39] <ChrisTownsend> Just wondering if either of you are familiar with this and what may need to be done to support this in Trusty?
[19:41] <stgraber> ChrisTownsend: what's giving you that error? some LXC command, a python3-lxc script, ... ?
[19:42] <ChrisTownsend> stgraber: It's when I try to start an app in the Unity 8 LXC, so it might be u-a-l.
[19:42] <ChrisTownsend> stgraber: A recent change to u-a-l uses GetTaksRecursive.  Could that possibly have any bearing on this?
[19:43] <stgraber> quite likely, yeah
[19:43] <ChrisTownsend> stgraber: So GetTasksRecursive is not supported in Trusty?
[19:44] <stgraber> correct, you need cgmanager 0.32 for that
[19:44] <ChrisTownsend> stgraber: Dang, oh well, I ended up breaking my own stuff.  Ok, thanks!
[19:44] <hallyn> but lxc is supposed to detect that
[19:45] <stgraber> hallyn: yeah, it's not LXC, it's his code ;)
[19:45] <hallyn> and only call the gettaskrecursive if it is supported
[19:45] <hallyn> oh!  ok :)
[19:45] <stgraber> LXC indeed does check the API version and has a fallback :)
[19:46] <ChrisTownsend> Yeah, u-a-l explicitely call GetTasksRecursive.  Should probably put a fallback in there as well.
=== timrc is now known as timrc-afk
[19:49] <ChrisTownsend> hallyn: stgraber: I suppose there are no plans to add support in Trusty for GetTasksRecursive, right?  More of a feature I suppose.
[19:50] <hallyn> yup
[19:50] <hallyn> well, i've considered trying,
[19:51] <stgraber> ChrisTownsend: it'd indeed be a feature update to a stable release and we usually try to stay away from that
[19:51] <hallyn> this could be a special case it's not something that will continue to be developed - it just got cut off during initial development by trusty release
[19:51] <hallyn> so if we're going to continue this with partial support for 5 years, it may be worthwhile pushing it so we can simplify other code (like lxc)
[19:51] <stgraber> if absolutely necessary and if we can provide very good test results showing there wouldn't be any regression, it may be negotiable with the SRU team
[19:52] <hallyn> but it's not something we have time for right now :)
[19:53] <ChrisTownsend> hallyn: stgraber:  Well, we need to check PIDs recursively for legacy X app support in Unity 8 and we want to support development of Unity 8 for Trusty users, so *something* needs to be worked out.  I'll see if I can get u-a-l to work properly for this.
[19:54] <ChrisTownsend> Too many dang variables when trying to develop for the latest and greatest but still worry about Trusty users.
[19:55] <stgraber> ChrisTownsend: ListChildren() and GetTasks() both existed in trusty I believe
[19:56] <ChrisTownsend> stgraber: GetTasks does, so maybe using a combo of both I can accomplish the same thing.
[19:56] <ChrisTownsend> stgraber: hallyn:  Thanks guys!
[19:56] <stgraber> not ideal obviously as you'll have to do a ton of calls to get the same as GetTasksRecursive but still, doable
[19:57] <ChrisTownsend> stgraber: It will be a fallback only if GetTasksRecursive fails and hopefully tedg won't frown too much on it:)
[19:58] <stgraber> ChrisTownsend: instead of calling GetTasksRecursive and failing, please check api_version instead :)
[19:58] <ChrisTownsend> stgraber: Even better!
[19:58] <tedg> stgraber, I'd rather fail, as that means in the standard case we have two calls.
[19:59] <ChrisTownsend> tedg: Well, whatever you want, sir!  I just need *something* to work as Trusty users are dead in the water right now.
[19:59] <stgraber> is that a longstanding process? because if so, querying api_version at startup should be reasonable
[20:00] <ChrisTownsend> And we publicized the unity8-lxc package just today at UOS.
[20:00] <tedg> stgraber, We make a connection each time, last time we connected to a private bus provided by nih-dbus for a long time bad things happened.
[20:00] <stgraber> tedg: sure, but you can still cache the cgmanager api_version, it's not going to change :)
[20:01] <tedg> stgraber, I believe I just saw a demo of a container frozen and moved while playing doom ;-)
[20:02] <hallyn> ChrisTownsend: if you really need it, that raises priority, and we can pursue sru :)
[20:02] <hallyn> tedg: haha, yes.  so it could change, indeed
[20:04] <ChrisTownsend> hallyn: It will certainly make life easier, but snails move faster than the SRU process, so I'm not sure what the best path is right now.  Wait on SRU or hack up u-a-l???
[20:05] <ChrisTownsend> hallyn: Currently, Trusty users using the latest Ubuntu Next desktop image cannot open apps, so it's useless.
[20:08] <ChrisTownsend> hallyn: We do have a PPA for the unity8-lxc stuff, so we could always upload a version of lxc that supports GetTasksRecursive and when the SRU hits the archive, it will supersede the PPA.
[20:09] <ChrisTownsend> hallyn: How long would it take to backport that support after we have a go ahead from the SRU team that the change is OK?
[20:09] <ChrisTownsend> hallyn: And how does my request stack up as a priority for the other work you guys are doing?
[20:10] <mwhudson> hallyn: woo for qemu updates
[20:11] <hallyn> ChrisTownsend: well right now i basically think it's something we could spend some time doing next week.  depending on how many high-level mtgs we get roped into
[20:11] <hallyn> ChrisTownsend: I think the best would be to take the 0.33 version verbatim and push it into trusty.  no backporting, bc that will only risk more regressions
[20:11] <hallyn> but, i expect a long SRU team fight
[20:13] <ChrisTownsend> hallyn: Ok, sounds like the coding part is pretty straight forward.  It's just getting it approved that may be the blocker.
[20:14] <ChrisTownsend> hallyn: I'd like to get an OK before moving forward.
=== timrc-afk is now known as timrc
[20:26] <barry> pitti: i don't suppose you're still around?
[22:13] <kgunn> mhall119: hey, i know it's last minute is there any way to move the unity8 session to 1pm my time tomorrow (i believe that's one hour later, 19:00 utc) ?
[22:26] <kgunn> mhall119: nvmd, i'll make it work
[23:38] <RAOF> cjwatson: Bug isn't in gnome-do, it's in libdbus2.0-cil-dev; the pkg-config file points to nonexistent files in /usr/lib/mono.