[02:24] <ted> So, multi-arch question. How do I find out the arch I'm installing for in postinst ?
[02:24] <ted> I want to set one of my binaries to be setuid, but I don't know where it is.
[04:58] <pitti> Good morning
[06:59] <LocutusOfBorg1> Riddell, I honestly don't even remember :
[07:01] <LocutusOfBorg1> some patches were dropped and some new patches more robust are used instead
[07:01] <LocutusOfBorg1> but I agree that now we are too late in the release cycle
[07:10] <pitti> mlankhorst: since yesterday https://jenkins.qa.ubuntu.com/job/utopic-adt-ubuntu-system-settings-online-accounts/237/ARCH=i386,label=adt/console consistently crashes again, this seems to coincide with moving to llvm 3.5?
[07:10] <mlankhorst> huh weird
[07:10] <mlankhorst> I tested it locally on i386
[07:11] <mlankhorst> but yes seems to be the same bug
[07:11] <mlankhorst> I'm pretty sure I did run that test manually, and also tested a full piglit run
[07:13] <mlankhorst> hm seems to have been on my macbookpro
[07:13] <mlankhorst> I'll try my other laptops, see what cpu extensions are needed to trigger it
[07:13] <mlankhorst> doko_: ping?
[07:16] <mlankhorst> doko_: do we have anyone working on llvm?
[07:17] <pitti> mlankhorst: it only seems to happen on i386, amd64 works
[07:17] <pitti> mlankhorst: that's a run in trusty's QEMU, FTR
[07:18] <mlankhorst> yeah
[07:27] <mlankhorst> hm my oldest laptop is unaffected
[07:28] <ara> cjwatson, hello! I know it is not your SRU duty today, but I have been pinging other SRU members lately without luck :(
[07:28] <ara> cjwatson, we have been waiting for 3 weeks for these uploads to move to precise-proposed: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=fglrx
[07:28] <ara> cjwatson, and it solves a critical issue with fglrx in 12.04.5 affecting many systems
[07:29] <ara> cjwatson, I would appreciate if you could have a look to it
[07:42] <mlankhorst> pitti: yeah, I only seem to hit it in qemu now
[08:36] <seb128> cjwatson, hey, https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 is in the sponsoring queue for a while, do you think you could have a look?
[08:37] <seb128> Riddell, hey, do you think you could have a look to https://code.launchpad.net/~filip-sohajek/ubuntu/utopic/kile/fix-for-1360709/+merge/232247 ?
[08:44] <Riddell> seb128: gotcha
[08:49] <doko_> mlankhorst, no
[08:50] <seb128> Riddell, thanks
[08:51] <jodh> pitti: hi - I noticed the upstart upload. Please could you sync your changes to the bzr branch (there will be a changelog conflict I think as I'd prepared a change :)
[08:52] <pitti> jodh: whoops, sorry; doing
[08:53] <jodh> pitti: np, thanks.
[08:54] <pitti> jodh: should I push --overwrite for clean history, or just commit on top?
[08:55] <mlankhorst> doko: I'm just guessing, but it seems that from the information that llvm generates some invalid code based on arch
[08:55] <jodh> pitti: could you recommit once the conflict is resolved so that my changes are still pending?
[08:56] <pitti> jodh: yes, sure
[08:56] <pitti> jodh: I mean if you would mind bzr pull --overwrite, for clean history
[08:56] <pitti> jodh: or whether I should commit on top (clean pull, but wrong history)
[08:57] <jodh> pitti: oh - I guess overwrite should be ok as long as your branch was only 1 commit behind the ubuntu one?
[09:00] <pitti> jodh: done; please bzr pull --overwrite
[09:00] <jodh> pitti: thanks
[09:14] <pitti> mlankhorst: we already had that error before and reverted LLVM back to 3.4 due to it; why did it come back now?
[09:16] <mlankhorst> no idea, don't completely understand what is going on
[09:22] <mlankhorst> pitti: hey how do I pass -cpu host for qemu to adt-run?
[09:23] <pitti> mlankhorst: you can do adt-run ... --- qemu --qemu-options "-x -y -z" your_image
[09:23] <pitti> mlankhorst: however, I never did that; using an i386 image is enough to reproduce it
[09:24] <mlankhorst> doesn't work for -cpu host
[09:26] <pitti> mlankhorst: ah sorry, option parser quirk: --qemu-options="-x -y -z"
[09:26] <pitti> e. g. qemu --qemu-options='-cpu Opteron_G4' adt-utopic-amd64-cloud.img
[09:27] <mlankhorst> ah
[09:31] <cjwatson> ted: $DPKG_MAINTSCRIPT_ARCH
[09:34] <cjwatson> ara: maaaaaybe.  I'm *very* unfamiliar with fglrx and they can be subtle reviews
[09:36] <cjwatson> seb128: will look
[09:37] <seb128> cjwatson, thanks
[09:37] <seb128> mlankhorst, hey, could you review https://code.launchpad.net/~ubuntu-multiseat/xorg-server/trusty-matchseat/+merge/234316 ?
[09:38] <mlankhorst> looks sane
[09:39] <mlankhorst> but needs a sru template
[09:39] <Laney> might be better to type that into the mp ;-)
[09:41] <seb128> yeah, please comment on the merge request
[09:41] <mlankhorst> done
[09:41] <seb128> thanks
[09:41] <seb128> I added https://wiki.ubuntu.com/StableReleaseUpdates as a pointer as well
[09:43] <cjwatson> pitti: please can you remember to copy to 14.09-proposed rather than to 14.09?
[09:44] <cjwatson> slangasek: you too :)  if you need to force something past proposed-migration, there are hints for that
[09:57] <pitti> cjwatson: I thought I did -- what did I do wrong this time?
[09:57] <pitti> cjwatson: I copied umockdev to -proposed and the langpacks are dput (and thus should land in -proposed automatically)
[09:57] <cjwatson> pitti: probably left out --to-suite=14.09-proposed for cgmanager
[09:57] <pitti> $ copy-package -y --from ubuntu -s utopic --to ubuntu-rtm --to-suite 14.09-proposed umockdev
[09:58] <pitti> cjwatson: oh, that must have been ages ago, before your first warning
[09:58] <cjwatson> pitti: yeah I think your recent uploads are fine - ogra was citing you as an authority for it being OK to copy things directly to 14.09 :)
[09:58] <cjwatson> ah yes it was ages ago, sorry for the noise
[09:58] <pitti> cjwatson: no worries :)
[09:58] <pitti> yeah, it definitively makes sense to go via -proposed
[10:19] <mlankhorst> doko / infinity: I found a small testcase to reproduce the issue, https://mblankhorst.nl/etc/llvmpipe.bc -- compile with llc-3.5 -o - llvmpipe.bc . works with llvm:amd64, fails with llvm:i386
[10:20] <mlankhorst> llc-3.4 works on i386
[11:02] <Mirv> mlankhorst: "LLVM ERROR: Do not know how to split the result of this operator!" bug #1360241 would look like being back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/ARCH=i386,label=adt/console
[11:03] <Mirv> and that failing prevents qtbase from moving to -release pocket
[11:04] <Mirv> oh, funny, repeating also the fact that it'd look like being discussed already here
[11:06] <doko> mlankhorst, can you reproduce this with unstable? and if yes, file a bug report?
[11:06] <doko> and mention this is a regression
[11:12] <mlankhorst> sec
[11:13] <mlankhorst> doko: yeah happens there too, but i'm bisecting now
[11:13] <mlankhorst> lot easier now that my testcase no longer involves mesa
[11:18] <ockham> do any packages share packaging with debian though they are named differently there? like e.g. firfox/iceweasel, or thunderbird/icedove? or is packaging completely independent from debian in those cases?
[11:20] <maxb> Just look at the packagings you're interested in and compare them?
[11:27] <ockham> those examples i gave don't seem to share packaging. are there possibly any other ones?
[11:38] <mlankhorst> why is it important to you?
[11:53] <pitti> jodh: ah, new systemd with fixed ifup@ just made it into utopic
[11:54] <jodh> pitti: nice :)
[11:57] <pitti> Mirv: you should ask the release team to ignore the failure to promote qtbase-opensource-src ; it's quite clearly a regression in llvm, not in qtbase
[12:01] <pitti> zul: did you see the FTBFS of https://launchpad.net/ubuntu/+source/python-swiftclient/1:2.3.0-0ubuntu1 ?
[12:01] <zul> pitti:  yeah havent gotten to it yet
[12:04] <pitti> cjwatson: I think you synced https://launchpad.net/ubuntu/+source/celery/3.1.12-2, which is depwaiting on python3-kombu; i. e. we need to merge the new kombu from sid (or perhaps sync, didn't check yet); are you on it, or should I give a hand?
[12:04] <pitti> (trying to clean up -proposed a bit)
[12:05] <ahasenack> hi guys, I had this error in a package build on launchpad:
[12:05] <ahasenack> fr: /build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error
[12:05] <ahasenack> any clues? I'm *not* building qemu :)
[12:05] <ahasenack> https://launchpadlibrarian.net/186090122/buildlog_ubuntu-trusty-armhf.landscape-client_14.08%2Bbzr788-0ubuntu0~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[12:05] <ahasenack> scroll to the bottom
[12:05] <ahasenack> same for arm64
[12:06] <ahasenack> well, sort of same, I'm not sure what happened here: https://launchpadlibrarian.net/186090111/buildlog_ubuntu-trusty-arm64.landscape-client_14.08%2Bbzr788-0ubuntu0~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[12:06] <ahasenack> but it's also in the i18n section
[12:08] <ahasenack> transient error?
[12:18] <cjwatson> pitti: 2014-09-17.log:17:17 <cjwatson> jamespage: would you mind merging kombu?  needed for new celery version I synced into -proposed, which in turn is needed to fix a build failure
[12:18] <cjwatson> 2014-09-17.log:17:20 <jamespage> cjwatson, yes ok
[12:18] <pitti> cjwatson: ah, thanks
[12:18] <jamespage> cjwatson, ok so I suck
[12:18] <pitti> jamespage: are you still on it, or do you need a hand?
[12:18] <jamespage> sorry - I'll get to it today
[12:18] <pitti> jamespage: ack, thanks
[12:19] <cjwatson> ahasenack: threads involved on your end?
[12:19] <ahasenack> cjwatson: it's just a build, and it worked on utopic and precise
[12:19] <cjwatson> ahasenack: anyway you're basically screwed for the moment.  https://bugs.launchpad.net/launchpad-buildd/+bug/1350435
[12:20] <cjwatson> ahasenack: you might get lucky on a retry
[12:20] <ahasenack> cjwatson: that seems to be it, thanks
[12:20] <cjwatson> ahasenack: or you can see if you can dig into that bug any more, if you have some time ...
[12:24] <Mirv> pitti: ok
[12:27] <jamespage> cjwatson, pitti: merged, tested and uploaded
[12:27] <jamespage> apologies for the lag
[12:27] <jamespage> ...
[12:27] <pitti> jamespage: wow, that was fast; thanks :)
[12:28] <pitti> jamespage: and, FWIW, yay py3 :)
[12:28] <jamespage> pitti, indeed - I noticed that's been done now which is good
[12:28] <jamespage> maybe openstack on py3 for 16.04 ? well you never know
[12:35] <ockham> mlankhorst: mostly because of https://bugs.launchpad.net/bugs/545778 as there are icowl-i10n-* packages in debian, and i wondered if they could just be modified in debian to also cater for ubuntu
[12:36] <mlankhorst> I think that would be possible even with different packaging
[13:31] <chrisccoulson> pitti, are you around?
[13:32] <pitti> chrisccoulson: I am
[13:34] <chrisccoulson> hi pitti! So, I keep getting asked why renderer crashes in our browser don't get processed by apport. it turns out that it's because we hit this code path: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/data/apport#L276
[13:34] <chrisccoulson> renderer's have their own PID namespace, but the sandbox also chroot's to /proc/self (so there's no apport)
[13:35] <cjwatson> infinity: Can I upload http://paste.ubuntu.com/8466066/ to glibc?  It fixes the phone x86 emulator, which has just gone over the global dlopen limit in question.
[13:35] <chrisccoulson> is there any way we can fix this? :)
[13:38] <pitti> chrisccoulson: I don't have a quick answer/idea about this, I'm afraid; this code path is for containers, it doesn't handle this kind of mini-chroot/namespace yet
[13:39] <pitti> chrisccoulson: if there's a way to tell this apart from a real chroot or container, we can certainly fix it; but we don't want to try and build reports from containers/chroots without apport
[13:45] <chrisccoulson> pitti, I'm not sure of the best way to tell it apart from a real container. It has no /sbin/init, if that helps
[13:45] <infinity> cjwatson: Did Carlos commit that upstream?
[13:45]  * infinity looks.
[13:46] <pitti> chrisccoulson: chroots don't need to have /sbin/init either
[13:47] <infinity> cjwatson: He sure didn't.  Grr.  Anyhow, if that's blocking you Right Now, go ahead, otherwise I can queue it up for my next upload.
[13:48] <mlankhorst> infinity: almost done bisecting the llvm issue
[13:56] <chrisccoulson> pitti, actually, the /proc/$pid/root symlink in left dangling in these processes. Perhaps you could use that?
[13:59] <pitti> chrisccoulson: possibly; I think stgraber might have an idea, he's rather familiar with namespaces
[14:16] <slangasek> cjwatson: mm? what did I copy to to 14.09 instead of 14.09-proposed?
[14:18] <slangasek> ah, ubuntu-touch-meta... sorry about that
[14:25] <mlankhorst> infinity: for the love of god.. I think I found it..
[14:25] <mlankhorst> $ llc-3.4 -march=x86 -mcpu=generic ../../llvmpipe.bc -o -
[14:25] <mlankhorst>         .file   "../../llvmpipe.bc"
[14:25] <mlankhorst> LLVM ERROR: Do not know how to split the result of this operator!
[14:26] <mlankhorst> bisect seems to point towards removal of cpu features detection..
[14:26] <mlankhorst> and confirmed it by setting -mcpu=generic
[14:26] <mlankhorst> on llvm-3.4
[14:27] <mlankhorst> so the fix is setting the cpu to native in llvmpipe
[14:28] <mlankhorst> no idea how yet, but meh
[14:29] <cjwatson> infinity: Right, the emulator not working is a pretty terrible blocker, so I've gone ahead and uploaded; thanks
[14:36] <mlankhorst> infinity: I'm pretty sure llvm commit 6bb00df864ea4e2f74f47c088b65baaff962cca5 is the reason why llvmpipe is now failing on qemu
[14:36] <mlankhorst> aka https://llvm.org/svn/llvm-project/llvm/trunk@206094
[14:37] <mlankhorst> and this is also why llvmpipe is only failing on qemu, because it compares the vendor strings, which is only changed if you use -cpu qemu32
[14:43] <mlankhorst> I'll see if I can make a hack for it to revert
[14:50] <infinity> mlankhorst: That's a 404.
[14:50] <infinity> mlankhorst: But this is also why I never use qemu with the silly "QEMU CPU" thing, but instead emulate a Core2 or something.
[14:50] <infinity> mlankhorst: This isn't the first bit of software that checks the cpuid registers for AuthenticAMD or GenuineIntel.
[14:51] <infinity> *cough*glibc*cough*
[15:07] <pitti> jamespage: erk -- https://launchpad.net/ubuntu/+source/kombu/3.0.21-2ubuntu1/+build/6421574
[15:08] <pitti> jamespage: oh, that's just a binary promotion to main, doing now
[15:08] <jamespage> pitti, oh - that looks lie a binary promotion
[15:08] <jamespage> pitti, snap!
[15:08] <jamespage> thanks
[15:17] <mlankhorst> pitti: can you emulate something saner?
[15:19] <mlankhorst> else I'll probably hack the autodetection crap back into llvm
[15:19] <mlankhorst> doko: ^
[15:20] <pitti> mlankhorst: define "something saner"? i. e. which cpu?
[15:21] <pitti> mlankhorst: yeah, not a big problem to change it
[15:22] <mlankhorst> infinity: what's minimum for ubuntu, coreduo or something?
[15:22] <mlankhorst> anyway I'll try to fix llvm tomorrow morning :)
[15:25] <pitti> mlankhorst: so, just tell me the -cpu I should be using
[15:25]  * pitti needs to leave now, guest arrived
[15:28] <mlankhorst> coreduo or something? just a temporary workaround, I'll try to fix the real thing tomorrow
[15:31] <pitti> mlankhorst: ack
[15:32] <mlankhorst> do you have a bug for tracking?
[15:35] <rbasak> barry: around? Are you the right person to ask for help with dh_python2?
[15:35] <rbasak> I'm not sure if I'm hitting a bug, or whether I'm using it wrong.
[15:35] <barry> rbasak: possibly :)
[15:35] <infinity> mlankhorst: Minimum for i386 is i686 w/ cmov.
[15:35] <rbasak> I end p with a successful run but failure with the generated postinst/prerm
[15:36] <barry> i mean, i'm definitely around :)
[15:36] <rbasak> It's a bit of a special case. A package that ships Python stuff in /usr/lib/<package> but nothing else.
[15:36] <infinity> mlankhorst: So, basically, Pentium Pro.
[15:36] <rbasak> So we want to byte-compile them on postinst, that's all.
[15:37] <barry> rbasak: hmm, interesting
[15:37] <rbasak> I end up with "pycompile -p  /usr/lib/<package> -V 2.7" in the postinst, which makes no sense.
[15:37] <rbasak> (and that fails)
[15:37] <rbasak> AFAICT, I need to not have the -p in this case, but the -p is part of the template that dh_python2 uses.
[15:38] <rbasak> The prerm is even worse. "pyclean -p"
[15:38] <rbasak> This is from just:
[15:38] <rbasak> override_dh_python2: dh_python2 --compile-all
[15:38] <rbasak> (with a newline in the middle - paste error)
[15:38] <rbasak> (and a tab. etc)
[15:42] <rbasak> barry: any thoughts? Am I doing something wrong here? For just the byte-compile bit, I'm wondering if it's better to arrange to call pycompile/pyclean directly and ditch dh_python2.
[15:42] <barry> rbasak: sorry, i'm in 2 conversations atm
[15:42] <rbasak> np
[15:43] <barry> rbasak: man dh_python2 seems to say that --compile-all won't pass -p
[15:44] <rbasak> barry: /usr/share/debhelper/autoscripts/postinst-pycompile seems to be where it's coming from.
[15:44] <rbasak> which contains: pycompile -p #PACKAGE# #ARGS#
[15:45] <barry> rbasak: i wonder if this is a bug in dh_python2
[15:45] <barry> rbasak: fwiw, i've never had to do this, so i don't have an immediate answer
[15:46] <rbasak> barry: OK, thanks.
[15:46] <barry> rbasak: i would suggest getting on #debian-python (OFTC) and asking p1otr
[15:46] <rbasak> barry: I wondered if it is because I'm not specifying DIR_OR_FILE (because AIUI it defaults to looking in /usr/lib/<package> which is what I want)
[15:47] <rbasak> But even in that case -p would be forced by the template.
[15:47] <rbasak> OK, I'll hop over to #debian-python - thanks.
[15:47] <barry> rbasak: that's what it looks like, indeed
[15:47]  * barry will keep an eye on that conversation
[15:55] <pitti> stgraber, kees, mdeslaur, slangasek: reminder: TB meeting in 5 mins (infinity sent his apologlies)
[15:55] <mdeslaur> pitti: yep, thanks
[16:02] <pitti> mlankhorst: yay, ubuntu-system-settings-online-accounts is back to green; thanks for tracking this down!
[16:05] <mlankhorst> pitti: I will try to fix llvm autodetection tomorrow, but at least it's not urgent any more now :)
[17:05] <bdmurray> dannf: https://code.launchpad.net/~dannf/ubuntu/utopic/flash-kernel/moonshot-updates/+merge/223845 looks merged to me. Is that right?
[17:27] <ahasenack> ad
[18:06] <hallyn> feh.
[18:32] <roaksoax> arges: ping
[18:33] <roaksoax> arges: i've noticed that some SRU bugs that had already been verified were changed from verification-done to verification-needed. I'm guessing this is because there was na upload on top of the original one
[18:33] <roaksoax> arges: however, given that these were already verified, why are they being marked verificaiton-needed again
[18:38] <doko> mvo, https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1306682
[18:42] <arges> roaksoax: can you point me at a specific bug?
[18:46] <mvo> doko: thanks
[19:01] <roaksoax> arges: e.g. https://bugs.launchpad.net/maas/+bug/1315154
[19:06] <arges> roaksoax: so when you uplaoded the last maas update you must have referenced this old bug, so the script goes through and marks each one referenced as fix commited and asked for verifciation
[19:06] <arges> roaksoax: or whomever uploaded the last maas update
[19:28] <dannf> bdmurray: yeah, it was - thanks for marking it as such
[19:48] <doko> barry, "no longer have an i386 machine on which to test" are you serious?
[19:48] <doko> you can create i386 chroots
[19:48] <barry> doko: yes.  iirc the problem was *not* reproducible in chroots.
[19:49] <barry> i think i had to use a physical 32 bit machine to reproduce it and all my old ones are dead.  but i think i scrounged up a 32 bit laptop.  trying to see if i can get ubuntu installed on it
[19:50] <mapreri> I lack bug supervisor ability, could someone pleas set https://bugs.launchpad.net/bugs/1375445 as whishlist (and in the meantime re-set the status as triadged and tell that wlee753159 user to do not mess with bugs (there are also at least one other bug he touched badly, but I'll deal with it on my own)). TIA
[22:00] <Bluefoxicy> hum
[22:00] <Bluefoxicy> defunct.
[22:00] <Bluefoxicy> 26472 ?        00:00:00 chromium-browse <defunct>
[22:00] <Bluefoxicy> Can someone load up chromium and use the mouse wheel gratuitously on maps.google.com to zoom in and out?
[22:00] <Bluefoxicy> I want to see if anyone can reproduce destroying the browser (or your desktop--save everything, you may need a hard reboot)
[22:01] <bdmurray> slangasek: at one point in time you were working on improvements to whoopsie_upload_all right?
[22:01] <sladen> there is something buggy that happens with OSM when doing that in Friefox
[22:03] <Bluefoxicy> sladen:  my work-around is to use firefox
[23:58] <Noskcaj> Can someone retry python-swiftclient? It's building fine in a chroot locally