[00:08] <bdmurray> where can I find somebody to talk to about developing a unity webapp?
[04:04] <pitti> Good morning
[04:04] <JackYu> morning:)
[06:49] <dholbach> good morning
[07:27] <jibel> cjwatson, correct 'request' generates requests for direct reverse-dependencies. We could generate requests for deeper levels of dependencies, that'd trigger tests more often.
[07:28] <jibel> cjwatson, I'll check the upstart case
[08:05] <doko> seb128, Riddell, et al: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130614-saucy.html
[08:06] <doko> pitti, ^^^postgres ftbfs
[08:06] <seb128> doko, hey, thanks, is main done or is that build in progress list?
[08:06] <doko> in progress, now runs alphabetically
[08:06] <seb128> ok
[08:07] <seb128> sil2100, ^ compiz seems to be unhappy with boost in saucy
[08:08] <pitti> doko: ack, will care about this
[08:09] <seb128> doko, are all those gnome- only ftbfsing on armhf? or is that just that armhf is further down the build list? (if it is why e.g icon is built on i386 if the builders go in order?)
[08:09] <sil2100> seb128: uuh
[08:10] <wgrant> icon's urgency=medium
[08:10] <wgrant> That's probably why
[08:10] <seb128> oh, ok, so I guess the others one are just not tried on i386/amd64 then
[08:10] <seb128> wgrant, thanks
[08:11] <Laney> xnox: ^? emacs is on there ;-)
[08:11] <seb128> doko, can you retry gnome-contacts?
[08:11] <doko> seb128, armhf buildds are faster
[08:11] <seb128> doko, https://launchpadlibrarian.net/142371643/buildlog_ubuntu-saucy-armhf.gnome-contacts_3.8.2-0ubuntu2_FAILEDTOBUILD.txt.gz
[08:11] <seb128> "Setting up python2.7 (2.7.5-5ubuntu1) ...
[08:11] <seb128>   File "/usr/lib/python2.7/cookielib.py", line 483
[08:11] <seb128>     H¨°m            if k == "expires":
[08:11] <seb128>      ^
[08:11] <seb128> SyntaxError: invalid syntax"
[08:11] <seb128>  
[08:11] <seb128> doko, I guess it's a builder issue
[08:12] <doko> done
[08:12] <seb128> thanks
[08:12] <seb128> shrug
[08:13] <seb128> how come we demoted automake1.11 when it still has stuff in main build-depending on it?
[08:13] <seb128> don't we have a check or a rules to fix rdepends before demoting?
[08:14] <pitti> that should be called component-mismatches.txt ?
[08:14] <seb128> pitti, it's not showing on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt though
[08:15] <seb128> pitti, but https://launchpadlibrarian.net/142354253/buildlog_ubuntu-saucy-i386.libgadu_1%3A1.11.2-1_MANUALDEPWAIT.txt.gz
[08:17] <Laney> does c-m know about provides?
[08:18] <cjwatson> insofar as germinate does
[08:19] <seb128> Laney, is anything in main that provides automake1.11? or do you ask for a different reason? and if something does shouldn't the build just work rather than depwait?
[08:19] <cjwatson> automake was a bit of a special case though because Debian took a while to provide the automake1.11 package after uploading 1.13
[08:19] <cjwatson> And I think the new automake landed *before* that libgadu was changed to depend on 1.11
[08:20] <cjwatson> So neither c-m nor britney would have been able to know about it
[08:20] <cjwatson> In fact, even Debian doesn't have an automake1.11 yet
[08:20] <seb128> is component-mismatch relying on catching changes are a right time? (e.g not looking to the current archive state)?
[08:20] <cjwatson> None of this is component-mismatches' fault at all
[08:21] <cjwatson> libgadu has just started build-depending on something that doesn't exist yet
[08:21] <seb128> http://packages.qa.debian.org/a/automake1.11.html
[08:21] <seb128> in fact it was recently removed
[08:21] <cjwatson> That's source.
[08:21] <seb128> oh
[08:22] <cjwatson> The automake1.11 source package only built an automake binary, now superseded by automake1.13 source
[08:22] <cjwatson> Eric said he was going to upload a compat source, but apparently hasn't (yet?)
[08:22] <seb128> well that version of libgadu is in debian stable and built in ubuntu
[08:22] <seb128> it's year old
[08:22] <cjwatson> Ah, that's because the old automake provided automake1.11
[08:22] <cjwatson> But migration doesn't check build-depends
[08:22] <seb128> well, in any case I will just change it to use automake non versionned
[08:22] <seb128> I was more puzzled at why that was happening
[08:23] <cjwatson> That's probably the right answer; if it fails with 1.13 and is intractable to fix, switch it to automake1.10
[08:23] <seb128> cjwatson, thanks for the explanations
[08:23] <StevenK> Version numbers directly in source package names makes me sad. But automaken is all kinds of special.
[08:23] <cjwatson> Which is probably good enough for most purposes
[08:23] <pitti> seb128: note that automake 1.13 changes quite some things, so maybe that explicit 1.11 dep was deliberate?
[08:23] <cjwatson> StevenK: Mostly it isn't any more - it's legacy attitudes
[08:23] <seb128> pitti, I will try automake1.10
[08:24] <cjwatson> IME automake1.13 is only really an issue (not counting things that are trivial to fix up) if you're relying on the old serial test harness
[08:24] <StevenK> cjwatson: If both source and binary change, it can lead to fun migrations. But I said, automake is special, and switching versions may make your package go boom.
[08:24] <cjwatson> Right, just saying, that's a lot less common than it used to be with old automake
[08:25] <cjwatson> Even the big changes in 1.13 only managed to cause problems for one of my packages
[08:25] <pitti> cjwatson: or if your package uses gtk-doc, or VALAFLAGS, or forgot AM_PROG_AR
[08:25] <pitti> I have some commits in umockdev to make it work with 1.13
[08:25] <cjwatson> AM_PROG_AR is one of the trivial things
[08:25] <cjwatson> I wasn't counting that because it's so easy to fix up
[08:27] <cjwatson> These days I'm fairly strongly of the opinion that the net best answer is to b-d on dh-autoreconf, use that, and fix things up for newest automake where necessary; just because that frees you of having to patch generated files
[08:27] <cjwatson> But it does rely on the maintainer being awake :)
[08:39] <xnox> I'd be ok with parallel test harness (it is quicker), if dh_auto_test would somehow sort and echo the tests logs into the buildlog. Often there is useful and/or non-fatal output that can be relevant.
[08:40] <pitti> yeah, that's my main gripe with it
[08:40] <pitti> it spits out "3 failures", and nothing else, which is ridiculously unhelpful
[08:41] <pitti> so in every package you then had to go ahead and find and cat the test logs of failures -- a test runner just ought to do that by default
[08:41] <xnox> pitti: just check the relevant.log file, oh wait the buildd has deleted that already =)
[08:41] <pitti> xnox: but even locally, if I do "make check", it's an annoying extra step
[08:42] <cjwatson> xnox: I think Automake itself should do that on failures, not dh_auto_test.  Could you ask upstream about that?
[08:42] <cjwatson> (If it's not already a FAQ somewhere ...)
[08:43] <xnox> cjwatson: I would want that to happen on success as well. But yeah, upstream should provide a facility to do so (display logs) and/or provide relevant targets to achieve that.
[08:43] <tvoss> cjwatson, ping
[08:43] <cjwatson> Variable to choose whether you want it on success, perhaps.  I wouldn't normally
[08:43] <cjwatson> tvoss: No need to ping when I'm already talking
[08:44] <cjwatson> I'm clearly here :)
[08:44] <pitti> cjwatson: +1 (on being silent on success)
[08:44] <tvoss> cjwatson, fair point :) quick one: do we have NITZ support, yet?
[08:44] <cjwatson> What is NITZ?
[08:44] <cjwatson> http://en.wikipedia.org/wiki/NITZ ?
[08:44] <cjwatson> First I've heard of it
[08:45] <tvoss> cjwatson, let's discuss in #ubuntu-touch, sorry for the noise
[08:58] <cjwatson> jibel: Sorry, apparently I hadn't had enough coffee when I was looking at adt-britney's behaviour with upstart; I was looking at the dependencies from the previous package in the loop instead ...
[08:58] <cjwatson> So if you're scratching your head over that, you can stop :-)
[09:00]  * xnox now knows that NITZ is the thing that gets my time wrong in Latvia
[09:01] <jibel> cjwatson, thanks, I'm at my 3rd cup of coffee to find where the error was. Enough caffeine for today :)
[09:01] <jibel> meanwhile, I'm adding support for an arbitrary level of reverse dependencies.
[09:03] <cjwatson> jibel: Does http://paste.ubuntu.com/5764067/ look right to you?  Without that, is_newer_dependency never finds anything since self.depends hasn't been set
[09:03] <seb128> hum, some other automake1.11 depwaits: jack-audio-connection-kit jbig2dec ijs
[09:03] <xnox> ok about optional on success. E.g. procenv package want to display its output even on success, cause it's more or less the sole purpose of the package. I was more thinking along the lines of "how do I check that particular test did run, and which branch if it's conditional" in case of upstart it only has 17 test binaries, but for test_conf the output can be "no inotify available skipping half of test_conf.c"
[09:05] <cjwatson> xnox: I get the impression that the preferred way to handle the latter in current automake is to use TAP
[09:50] <jibel> cjwatson, with that change it would compare the version from the request file to the latest version in the archive. What we want is compare the version in the request file to the last version tested (i.e version in the status file)
[09:50] <jibel> I think is_newer_dependency should return True when self.depends is empty, that'd mean this is a new package.
[09:50] <jibel> We could even completely skip the version dependency check if the package has never been tested
[09:51] <jibel> cjwatson, do you agree with this?
[10:03] <seb128> @pilot in
[10:03] <shadeslayer> ogra_: stgraber android-tools are broken
[10:03] <shadeslayer> on saucy
[10:04] <ogra_> ?
[10:04] <ogra_> whats broken
[10:04] <shadeslayer> the upstart script to start adbd
[10:04] <ogra_> works fine here
[10:05] <shadeslayer> http://paste.kde.org/773486/
[10:06] <ogra_> oh, thats a packaging error i think
[10:06]  * ogra_ checks
[10:07] <ogra_> shadeslayer, you are in a chroot i assume ?
[10:07] <shadeslayer> ogra_: nope
[10:07] <shadeslayer> saucy install on my laptop
[10:07] <xnox> ogra_: i can fix it.
[10:08] <ogra_> shadeslayer, ugh, you *never ever* want to install that package on a non android device
[10:08] <shadeslayer> oh?
[10:08] <ogra_> android-tools-adbd is the daemon
[10:08] <ogra_> needs kernel support
[10:09] <shadeslayer> maje it unavailable on x86 then?
[10:09] <shadeslayer> *make
[10:09] <ogra_> why ?
[10:09] <ogra_> if we ever support x86 android devices we want to be able to use it
[10:09] <xnox> shadeslayer: android is available on x86, despite _us_ not making an x86 android images yet.
[10:09] <shadeslayer> oh good point
[10:09] <xnox> ogra_: i guess, it should just not start gracefully.
[10:10] <ogra_> that apt-get install is pretty blindly just installing everything
[10:10] <ogra_> xnox, yeah, dh_installinit --no-start is surely needed
[10:11] <ogra_> and probably a more verbose description ... i dont think it says that  you need android kernel support
[10:12] <xnox> ogra_: http://paste.ubuntu.com/5764221/ ?
[10:12] <ogra_> shadeslayer, note that there will soon be more packages prefixed with android- that will ship actual bionic based binaries
[10:12] <shadeslayer> ogra_: ack, will keep that in mind
[10:12] <ogra_> xnox, yeah, looks good
[10:13] <ogra_> we should still have --no-start though ... in case you roll a rootfs on an Ubuntu phone/tablet
[10:15] <ogra_> (or check if we are running inside a chroot or some such)
[10:16] <ogra_> xnox, btw, while i look at that job, do you know a way to have the pre-start script run as root but have adbd starting as an unprivileged user ?
[10:17] <ogra_> using setuid also makes pre-start run as that user
[10:17] <xnox> ogra_: can I just pretend that people that "roll a rootfs on an Ubuntu phone/tablet" or run "inside a chroot or some such" can figure out what they need to run where & properly use .override and/or not start any daemons =_
[10:18] <ogra_> well, we could tell them if they complain for sure :)
[10:18] <ogra_> i agree its a corner case
[10:20] <xnox> ogra_: often requested feature. atm setuid is for everything. One can use two jobs adbd-setup and adbd. Do you think adbd should be allowed to set those variables unconditionally? in that case next upstart has apparmor support and one could allow non-priviledged process write into those files (unless my apparmor understanding is horribly wrong)
[10:22] <ogra_> xnox, well, i'm not sure yet how we want adbd to be used at all ...  it would theoretically be good to have it start as nonprivileged user and if you call adb root on the host PC have it switch to root ... but i'm not sure if thats possible at all in our setup
[10:22] <ogra_> i'm not sure if we will keep adbd in a final image ...
[10:22]  * jdstrand is lacking context, but apparmor can't be used to elevate privileges beyond what DAC would allow
[10:23] <ogra_> if we do it would be good to mimic android behavior so exiting documentation works for us as well
[10:23] <xnox> jdstrand: ack, thanks.
[10:24] <ogra_> the bit i fear is that this works only  for a certain system user with a certain hardcoded PID (android uses such a scheme all over the place)
[10:25] <ogra_> (usually the kernel has such stuff hardcoded)
[10:25] <jdstrand> @pilot in
[10:25] <xnox> ogra_: http://paste.ubuntu.com/5764247/
[10:26] <xnox> ogra_: but, if you want "adb root" to work that means adbd will have root/sudo privileges. In that case you can simply do "echo 0 | sudo tee /sys/class/.../enable >/dev/null" and use setuid/setgid =)
[10:28] <ogra_> xnox, yeah, well, that patch would also need user creation and i fear the kernel has a PID or GID hardcoded for accessing that sysfs node
[10:28] <ogra_> so the user creation would have to force a UID ...
[10:28] <seb128> jdstrand, hey, what items of the queue are you looking at? (just to avoid conflicts)
[10:28] <ogra_> http://android-dls.com/wiki/index.php?title=Android_UIDs_and_GIDs
[10:28] <seb128> jdstrand, I'm doing the qt4x-11 one atm
[10:28] <ogra_> seems to actually be 1011
[10:29] <jdstrand> I am planning on looking at 'security' ones first, then there is an iptables merge that will be added to the list shortly
[10:29] <seb128> jdstrand, ok, no conflict then, thanks ;-)
[10:29] <ogra_> hmm, touch there is also 2000 (shell)
[10:29] <ogra_> *though
[10:29] <jdstrand> seb128: not atm, no :)
[10:29] <jdstrand> but if I move on I'll be sure to coordinate
[10:30] <seb128> jdstrand, thanks
[10:34] <shadeslayer> ogra_: just to make sure I have the right scripts, this is the live-build script used by the ubuntu-touch images for saucy right? https://bazaar.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet-saucy/view/head:/configure
[10:34] <ogra_> this is the jenkins live build script, right
[10:34] <shadeslayer> awesome
[10:34] <ogra_> (will be dropped soon)
[10:35] <shadeslayer> oh
[10:35] <shadeslayer> newer script?
[10:35] <ogra_> the ones we use for the official images (not called -preview) are in lvecd-rootfs
[10:36] <shadeslayer> I see
[10:36] <ogra_> (note that the hack scripts in the ubuntu-touch subfolder will all go away as well)
[10:40] <ogra_> xnox, want to upload the first fix ? i thing the user/privilege handling is a thing for later, once we know what we want
[10:41] <ogra_> s/thing/think/
[10:41] <xnox> ogra_: ack.
[10:41] <ogra_> thx
[10:44] <jdstrand> stgraber: hi! around? if so, can you change the status of https://code.launchpad.net/~sdeziel/ubuntu/raring/openvpn/fix-for-lp1184223/+merge/165760 to 'Rejected'
[10:45] <jdstrand> stgraber: and https://code.launchpad.net/~sdeziel/ubuntu/raring/mysql-5.5/fix-for-lp1185573/+merge/166379 as Merged?
[10:49] <pitti> jdstrand: can do
[10:49] <jdstrand> pitti: ah, thanks! :)
[10:49] <jdstrand> stgraber: nm
[11:07] <cjwatson> jibel: Ah, yes, I think that makes more sense - the thing I was observing was that adt-britney was never actually scheduling any requests.  It makes sense that adt-britney should be the thing that keeps track of what's last been tested
[11:27] <seb128> pitti, can you mark https://code.launchpad.net/~jm-leddy/ubuntu/precise/x11proto-core/micmute/+merge/167620 as merged?
[11:44] <seb128> pitti, can you mark https://code.launchpad.net/~le-businessman/ubuntu/raring/libcommoncpp2/fix-for-1176058/+merge/166377 work in progress as well?
[11:45] <pitti> seb128: bien sûr
[11:47] <pitti> seb128: let me consider it :)
[11:47] <pitti> seb128: hm, hang on, you can't set to WIP? that sounds wrong
[11:47] <pitti> (done)
[11:48] <seb128> pitti, I can't edit MRs targetted to stable series
[11:48] <seb128> pitti, danke
[11:48] <pitti> oh, for stables
[11:48] <seb128> pitti, that one is for raring
[11:52] <jdstrand> seb128: fyi, I plan to look at https://code.launchpad.net/~le-businessman/ubuntu/raring/libcommoncpp2/fix-for-1176058/+merge/166377 later
[11:58] <seb128> jdstrand, ok
[12:01] <jibel> cjwatson, r191 fixes a bug when a request file is provided. It processed all the packages with a testsuite not only those in the request file leading to a very weird list of dependencies in the generated request file.
[12:17] <cjwatson> jibel: Thanks
[12:26] <pitti> tseliot: FYI, I'm uploading a new u-d-common; it'll depwait, needs someone to review bug 1190926 first
[12:26] <pitti> tseliot: this fixes the test suite again
[12:28] <tseliot> pitti: ah, good, I'll have a look at the code, more out of curiosity as I'm not familiar with umockdev
[12:29] <pitti> tseliot: argh, forgot to port debian/tests/, will do that now
[13:04] <seb128> pitti, could you put https://code.launchpad.net/~pataquets/ubuntu/precise/avidemux/avidemux-bug-1041144/+merge/121341 as work in progress?
[13:15] <arges> jdstrand: hi. Just got your email. Thanks for the feedback, revewing the debdiff. Did you want me to run the QA tests on it now?
[13:15] <pitti> seb128: s4re
[13:15] <pitti> seb128: d6ne
[13:15] <seb128> pitti, th1nks
[13:16] <pitti> argh, that was numlock
[13:16] <pitti> not a feeble attempt at l33tsp34k :)
[13:16] <pitti> TGIF
[13:16] <seb128> lol
[13:16] <seb128> I was not sure, it's friday after all :p
[13:19] <seb128> pitti, https://code.launchpad.net/~jm-leddy/ubuntu/precise/x11proto-core/micmute/+merge/167620 as merged as well please? ;-)
[13:20] <pitti> seb128: done
[13:21] <seb128> pitti, danke
[13:28] <jdstrand> arges: feel free to do so for experience sake, but I already did it all and uploaded :)
[13:29] <jdstrand> arges: and thank *you* for the merge :)
[13:29] <arges> jdstrand: no problem, thanks for the review! i'll look through the QA info since I do want to learn it.
[13:31] <jdstrand> arges: I suggest reading scripts/README
[13:31] <jdstrand> arges: (for the qrt bits)
[13:32] <arges> jdstrand: will do.
[13:33] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment explains how to setup sbuild (which is useful in and of itself) but also umt, which is the tool the security team (and others) use for building packages
[13:34] <arges> ok I have a set of schroots for each series/arch on my machine, how does umt compare to just using sbuild?
[13:34] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Using_umt
[13:34] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Typical_package_build_procedure
[13:35] <jdstrand> it just makes automatable things automated, performs various checks and allows you to do things like compare build logs and binaries easily
[13:36] <jibel> pitti, WRT umockdev package test, when run from a source tree, adt-run builds the package in $TMPDIR/ubtree0-ubtree/real-tree/ but when run from a dsc it builds the package in $TMPDIR/dsc0-build/umockdev-0.2.6
[13:37] <pitti> jibel: ooh - that's why it fails in jenkins
[13:37] <pitti> jibel: thanks for pointing out
[13:37] <arges> jdstrand: cool thanks
[13:37] <jibel> pitti, IMO adt-run should cd to real-tree when build-needed is set and package is built from source
[13:37] <jdstrand> np
[13:37] <pitti> jibel: I agree
[13:37] <jibel> pitti, so if you change your hack to [ -d real-tree ] && cd real-tree
[13:37] <jibel> pitti, it should work in both cases
[13:55] <kenvandine> mardy, you mentioned you were going to review seb128's translations branch
[13:55] <kenvandine> mardy, are you working on that or do you want me to do it?
[13:55] <mardy> kenvandine: oops
[13:55] <mardy> kenvandine: please do it :-)
[13:55] <kenvandine> will do
[13:56] <kenvandine> mardy, i plan to do the same for ubuntu-system-settings-online-accounts too
[13:56] <seb128> kenvandine, mardy: whoever does win a free beer for next time we see each others, that made me waste quite some time since yesterday, I've 4 stacked branches and I screwed a few times keeping them in sync
[13:56] <mardy> kenvandine: makes sense
[13:56] <kenvandine> seb128, yay... i win :)
[13:56] <seb128> kenvandine, ;-)
[13:56] <mardy> seb128: I don't drink beer, that's why I let Ken win ;-)
[13:57] <kenvandine> haha :)
[13:57] <kenvandine> mardy, such a nice guy!
[13:57] <seb128> mardy, damn, what drink should I put on the table next time? ;-)
[13:58] <mardy> seb128: I'm not fond of any drink in particular. My weakness is ice-cream :-)
[13:58] <seb128> oh, that works too!
[13:58] <pitti> ooooh, ice cream!
[13:58] <pitti> c'est toujours l'heure du glace !
[13:59] <seb128> larsu swapped the beer he owned me for an icecream last time
[13:59] <seb128> that was nice as well
[13:59] <seb128> pitti, en effet ;-)
[13:59] <pitti> seb128: pas de glace à train ici :(
[13:59] <pitti> "dans le train"
[14:00] <seb128> pitti, ton train s'arrête à quelle heure ? peut être une glace après le voyage...
[14:01] <pitti> seb128: je vais arriver à 16:30 -- beaucoup de temps pour de glace :)
[14:06] <seb128> pitti, enjoy ;-)
[14:06] <pitti> seb128: I will :)
[14:17] <seb128> @pilot out
[14:17] <seb128> jdstrand, sponsoring queue is all yours ;-)
[14:18] <jdstrand> thanks!
[14:39] <chiluk>  infinity, jdstrand can I get some love on the precise unity upload?  I'm eagerly awaiting a fix for https://bugs.launchpad.net/compiz/+bug/1083186
[14:42] <chiluk> it looks like compiz changes might also be needed for that unity sru.
[14:42]  * jdstrand defers to a member of the sru team
[14:43] <jdstrand> chiluk: I could help get something uploaded, but a member of the sru team needs to approve it
[14:43] <chiluk> it's already in the upload queue
[14:43] <Laney> https://launchpadlibrarian.net/142376050/buildlog_ubuntu-saucy-amd64.db5.3_5.3.21-1ubuntu1_FAILEDTOBUILD.txt.gz ← what is going on here?
[14:43]  * jdstrand nods
[14:43] <chiluk> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
[14:43] <chiluk> just unapproved.
[14:44] <jdstrand> chiluk: yes, you need a member of ubuntu-sru. you happened to ping one a moment ago :)
[14:44] <Laney> The linker line looks correct... is it to do with the symbols being versioned?
[14:45] <Laney> I tried with gold and it built.
[14:45] <chiluk> really?  I thought once it got uploaded it was already approved by the sru team.
[14:45] <Laney> doko: ^?
[14:47] <jdstrand> chiluk: no, people can just upload whenever they want, but it goes into the unapproved queue. at that point a member of the sru team can review it and approve it
[14:47] <chiluk> alright, thanks for the clarification.  I'm still new to this process.
[14:47] <jdstrand> chiluk: of course, for them to notice it, the bug needs to be in a certain state. this is detailed in https://wiki.ubuntu.com/StableReleaseUpdates
[14:50] <jdstrand> @pilot out
[14:57] <GyrosGeier> hi
[14:57] <jbicha> seb128: simplejson is in depwait, can you upload this instead? http://paste.ubuntu.com/5764930/
[14:58] <GyrosGeier> I have a Debian package that should have different Build-Depends in Ubuntu
[14:59] <GyrosGeier> (Ubuntu has Mesa 9, Debian has Mesa 8, so EGL support on Debian does not work, hence a Build-Conflict to avoid the package finding it)
[14:59] <GyrosGeier> what is the sanest way to handle that?
[15:00] <bdmurray> Who could I ask about how to test a unity-webapp?
[15:02] <seb128> jbicha, will do later, I've to run for an hour or so, your diff has a conflict in debian/control and then I can't get debuild -S to work
[15:02] <seb128> 'build/scripts-3.3' does not exist -- can't clean it
[15:02] <seb128> /bin/sh: 1: python3.3-dbg: not found
[15:02] <seb128> E: pybuild:245: clean: plugin distutils failed with: exit code=127: python3.3-dbg setup.py clean
[15:03] <seb128> if anybody else wants to sponsor the fix feel free
[15:03] <seb128> otherwise I will have a look when I'm back
[15:04] <nicolacorti> Hi to everyone
[15:05] <JackYu> hi
[15:06] <nicolacorti> Just one question, i'm looking for some information on PyGTK but i think that http://www.pygtk.org/ is down
[15:07] <jbicha> seb128: yeah I don't know what's up with that, I had to install python2.7-dbg and python3.3-dbg outside mychroot for the clean step to work (and python-distutils-extra & sphinx-common)
[15:07] <cjwatson> GyrosGeier: Since it's in the .dsc, there's no real way to handle that dynamically if the package is precisely in sync; there'll have to be an Ubuntu-specific patch to the package which gets merged as you upload new versions to Debian
[15:07] <cjwatson> Assuming there's definitely no way to express the Build-{Depends,Conflicts} in a way that works on both
[15:09] <doko> Laney, link the library with -ldl
[15:09] <doko> afk now
[15:09] <Laney> it is
[15:10] <doko> no, that's the executable
[15:11] <Laney> hmm
[15:17] <GyrosGeier> cjwatson, if mesa 9 is available, use mesa 9 and libgbm 9; otherwise, conflict with libgbm
[15:17] <GyrosGeier> cjwatson, it could be done with | constructs, but I'm not sure whether buildds will stumble over that
[15:18] <cjwatson> GyrosGeier: One thing that's useful to know is that Debian's buildds (AFAIK) only ever look at the first entry in an |-list, while Ubuntu's buildds will attempt alternatives
[15:18] <pitti> cjwatson: btw, haskell-yasod is failing again; does "cabal: At least the following dependencies are missing: clientsession ==0.8.*" sound like a missing dependency or are packages out of sync?
[15:19] <ScottK> GyrosGeier: You could use a versioned conflicts perhaps.
[15:19] <cjwatson> It's sometimes possible to construct something that works both ways using that trick
[15:19] <GyrosGeier> hmm
[15:19]  * GyrosGeier tries
[15:20] <tvoss> seb128, ping
[15:21] <cjwatson> pitti: Looking
[15:22] <pitti> cjwatson: https://jenkins.qa.ubuntu.com/job/saucy-adt-haskell-yesod/11/ARCH=amd64,label=adt/ FYI
[15:22] <cjwatson> pitti: I think it's fixed upstream - I'll see if it's possible to upgrade
[15:30] <cjwatson> pitti: Yep, there was an upstream release that fixes just this and doesn't pull in other major stuff.  I'll package that in Debian
[15:30] <pitti> nice, thanks
[15:31] <pitti> I was just wondering because it succeeded a few days ago
[15:32] <cjwatson> Yeah, we had to upgrade haskell-clientsession in the interim
[15:32] <cjwatson> And the scaffolding stuff in haskell-yesod is unusual enough that it isn't caught by our scripts that check for coherency
[15:59] <GyrosGeier> Get: 87 http://ftp.ubuntu.com/ubuntu/ raring/main llvm-3.2-runtime amd64 3.2-2ubuntu5 [30.7 kB]
[15:59] <GyrosGeier> Get: 88 http://ftp.ubuntu.com/ubuntu/ raring/universe llvm-runtime amd64 1:3.2-16~exp1 [2388 B]
[16:00] <GyrosGeier> that smells fishy
[16:01] <infinity> GyrosGeier: What's fishy about it?
[16:04] <GyrosGeier> infinity, parts of llvm in main, parts in universe, and some with epoch (as in Debian), some without
[16:04] <infinity> GyrosGeier: Parts in main, parts in universe, is par for the course.
[16:04] <infinity> GyrosGeier: The epoch-and-not is because those come from two different source packages.
[16:05] <GyrosGeier> hmm
[16:06] <infinity> GyrosGeier: The bits that are in main are the bare minimum for the other things in main that require certain llvm bits.  We don't even pretend to support the entire clang/llvm toolchain.
[16:06] <GyrosGeier> ah okay
[16:06]  * GyrosGeier is going to have fun watching beignet burn then
[16:14] <chiluk> infinity what needs to happen in order to get the latest precise unity upload accepted?  I see you are part of the SRU team.  The bug I care about is https://bugs.launchpad.net/compiz/+bug/1083186
[16:15] <chiluk> but the unity team bundles bugs together into sru releases https://launchpad.net/unity/+milestone/5.20.0
[16:16] <infinity> chiluk: It just needs a queue review.  We'll get there.  I wasted a bunch of time reviewing raring unity SRUs yesterday that LP then rejected, so once I get over that grumpiness, I'll hit up the precise ones, which shouldn't suffer the same problems. :P
[16:17] <chiluk> awesome.
[16:17] <chiluk> thanks ...
[16:18] <chiluk> ah you probably approved the fix to mesa yesterday, that I finally have... thanks for that too.. It was getting annoying not being able to use the dash or alt-tab
[16:23] <barry> xnox: hi, are you around?  you were the last one to upload emacs24.  wondering if you had any problems building it locally? both the saucy version and my branch with a small fix fail
[16:25] <GyrosGeier> okay
[16:25] <GyrosGeier> evil hack, but works
[16:25] <GyrosGeier> (until doko uploads clang with an epoch)
[16:26]  * GyrosGeier wonders if there is or should be a package that can be used as a build-dep that takes little space and can never be installed on Ubuntu
[16:37] <sergiusens> xnox: hey, just learned that you will package android... my question is what should I apt-get to get the x-toolchain?
[16:40] <xnox> sergiusens: you can use the very dangerous ppa:ubuntu-toolchain-r/test ppa. I would recommend to create a chroot/schroot and enable that ppa inside there. And then you can get the gcc-arm-linux-androideabi from there.
[16:40] <xnox> sergiusens: be careful with that ppa, as it can have highly experimental / test toolchains which are not supported in any way or shape =)
[16:40] <xnox> it's doko's playground.
[16:42] <infinity> @pilot out
[16:42]  * infinity coughs.
[16:44] <sergiusens> xnox: thanks! Well I wanted to start checking it out to build without the packaging in the middle so you had an easier time with whatever errors may show up
[16:48] <seb128> tvoss, hey, pong (was out for some exercice)
[16:48] <tvoss> seb128, no worries, all good
[16:52] <seb128> tvoss, good ;-)
[16:57] <xnox> sergiusens: well, we don't know for sure if that cross-compiler builds anything sane yet =))))))
[16:57] <sergiusens> xnox: well, I'll be finding that out ;-)
[17:04] <hallyn_> psivaa: arges: Bit of a long shot, but I'm wondering whether the recent precise qemu-kvm precise SRU is causing the test failures in ceph and lxc
[17:04] <hallyn_> psivaa: I don't have admin rights on aldebaran, could we build a qemu-kvm package on it with the lastest change reversed, and see if tests pass?
[17:04] <hallyn_> arges: maybe i was wrong, and reversing that change *is* urgent...
[17:05] <arges> hallyn_: yea would be good to see if that's causing those failures
[17:06] <hallyn_> that's bad bad bad ifso
[17:06] <hallyn_> oh, no.
[17:07] <hallyn_> arges: psivaa: never mind, it's on the previous version of qemu
[17:07] <hallyn_> never mind, ignore me, thanks
[17:07] <arges> what kind of failure is it? corruption?
[17:09] <psivaa> hallyn_: ack :)
[17:10] <hallyn_> arges: seems like an inexplicable hang during testcases
[17:14] <hallyn_> could be python bug?
[17:14] <hallyn_>  2476 root      20   0 21232  11m  960 R  99.5  2.3 526:48.59 python
[17:14] <hallyn_> except when i try what it's doing (subprocess.cmd of debootstrap) it works fine...
[17:15] <hallyn_> it's just non-stop doing selects
[18:16] <rsalveti> slangasek: hey, would you mind approving https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-phablet-ubuntufication ?
[18:17] <rsalveti> don't think we have anyone in our team that's capable of approving blueprints for ubuntu
[18:18] <slangasek> rsalveti: done
[18:18] <rsalveti> slangasek: thanks
[18:26] <manish> ev: ping. please check your mail (@ubuntu.com one)
[19:34] <GyrosGeier> hi
[19:41] <mterry> pitti, why does umockdev use dh_auto_test || true?
[19:42] <mterry> pitti, ah yes, because it uses dep8 for the tests
[19:44] <slangasek> mterry: how does that explain?  surely it should still be wired up in such a way that dh_auto_test can pass successfully?
[19:45] <mterry> slangasek, well, it's not an explanation, but I believe I remember talking to him about this before.  There are tests that require installation, which are used in dep8.  During build, he runs tests anyway, but doesn't care about results.  It would be nicer if he just selectively ran some of the tests during build, but...
[19:46] <slangasek> right, agreed :)
[19:47] <Laney> I bet it's rather because the tests don't all pass on ppc ;-)
[19:50] <Laney> where's the script to synthesise the .pc directory?
[20:05] <GyrosGeier> does the import from Debian to universe work automatically, or does someone have to prod something?
[20:06] <jtaylor> GyrosGeier: its automatic for apckages without ubuntu diff
[20:17] <GyrosGeier> it has a diff, which no longer applies because I've tricked the control file to DTRT on Ubuntu
[20:18] <GyrosGeier> i.e. the diff is unneeded now
[20:20] <jtaylor> use requestsync
[20:21] <jtaylor> and describe why the delta can be dropped in the bug report it will create
[20:22] <jtaylor> its in the ubuntu-dev-tools package
[20:38] <GyrosGeier> mm
[20:38] <GyrosGeier> I'm on Debian
[20:38] <GyrosGeier> the only Ubuntu system I have is my pbuilder
[20:40] <GyrosGeier> The package in question is beignet, if anyone wants to do me a small favour :)
[20:40] <jtaylor> it works from debian
[20:40] <jtaylor> but you do need a lp account
[20:41]  * GyrosGeier installs
[20:42] <GyrosGeier> ah excellent
[20:43] <GyrosGeier> thanks
[20:43]  * GyrosGeier goes out, after all it is Friday