=== work_alkisg is now known as alkisg
[05:10] <pitti> bdmurray: I'm sure it was just because I forgot to change it to utopic; I already wondered where my upload went
[05:10] <pitti> Good morning
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[05:56] <pitti> smoser: great, utopic cloud images exist now, thanks! do you know what's missing to generate a /current link in http://cloud-images.ubuntu.com/utopic/ ?
=== Ursinha is now known as Ursinha-afk
[06:40] <jibel> pitti, I pushed https://code.launchpad.net/~jibel/britney/fix_missing_results it fixes the problem with vanishing results and results that changed over time, detects regression and always failing tests and only block regressions, and adds some coloring to excuses
[06:41] <jibel> pitti, I didn't proposed a merge yet, I need to fix the testsuite because what was not considered before are now identified as "always failing" and promoted
[06:44] <pitti> jibel: yay, you rock
[06:56] <dholbach> good morning
[07:08] <smb> xnox, cjwatson, The way that bug 1313497 turns out I wonder whether there would be any way of helping people to make better decisions when selecting kernel package in preseeds. Maybe extending the example with some explanation in the comments? (help.ubuntu.com/14.04/installation-guide)
[07:08] <ubottu> bug 1313497 in linux (Ubuntu) "USB keyboard unresponsive on fresh install" [Undecided,Confirmed] https://launchpad.net/bugs/1313497
=== zigo_ is now known as zigo
[08:04] <pitti> infinity: mind if I steal your modemmanager merge?
[08:04] <pitti> infinity: (in fact, I'd like to try a sync first, and re-apply your -O2 workaround if it still fails)
[08:04] <pitti> darkxst: ^ FYI
[08:16] <rsalveti> xnox: updated bug https://bugs.launchpad.net/ubuntu/+source/android/+bug/1305315
[08:16] <ubottu> Launchpad bug 1305315 in gcc-i686-linux-android (Ubuntu) "Android container fails to start when built with the gcc-i686-linux-android toolchain" [Undecided,New]
[08:25] <pitti> xnox: we need to merge sysvinit so that invoke-rc.d works with systemd; are you already at it, shall I do it now, or is there a reason not to merge and I just cherry-pick these patches? (debian bug 683084 mostly)
[08:25] <ubottu> Debian bug 683084 in sysv-rc "Make invoke-rc.d/update-rc.d systemd-aware" [Wishlist,Fixed] http://bugs.debian.org/683084
[08:27] <pitti> doko, cjwatson: do we still care about "cell processor" and spu? (sysvinit delta)
[08:28] <doko> pitti, I removed all the compiler stuff now from the toolchain packages
[08:29] <cjwatson> pitti: I certainly don't
[08:29] <pitti> ok, so that seems obsolete; thanks for confirming!
=== alkisg is now known as work_alkisg
[09:09] <SpamapS> hrm, anybody have clues on the magic incantations to get trusty's kernel to boot without any graphics modes?
[09:09] <SpamapS> nofb nomodeset vga=normal is not doing it
[09:14] <smb> SpamapS, "text" ?
[09:15] <smb> Though that is not a kernel argument but one that upstart looks at
[09:15] <smb> iirc
[09:16] <SpamapS> smb: this is for a custom initrd
[09:16] <SpamapS> smb: trying  video=vesafb:off
[09:16] <smb> Oh and maybe needs to set grub to use console in /etc/default/grub
[09:16] <SpamapS> no grub, PXE boot
[09:17] <smb> ah
[09:17] <SpamapS> which is part of the problem.. using an ILO remote KVM which doesn't want to support VGA without "red tape"
[09:17] <SpamapS> support non-VGA text mode I Mean
[09:18] <smb> Yeah, not sure with pxe boot. for some bare-metal servers which don't like that for virtual KVMs either I use the grub console + nomodeset
=== MacSlow is now known as MacSlow|lunch
[10:17] <doko> infinity, https://launchpadlibrarian.net/174223989/buildlog_ubuntu-utopic-amd64.notmuch_0.18~rc0-1_FAILEDTOBUILD.txt.gz  can't reproduce this one locally
=== mbiebl_ is now known as mbiebl
[11:19] <hakermania> Can someone drop the link for a guide for pushing a package through the update manager?
[11:19] <hakermania> e.g. release an updated version of an existent package mid-release.
[11:21] <ogra_> https://wiki.ubuntu.com/StableReleaseUpdates
[11:21] <ogra_> ?
[11:39] <xnox> smb: what kernel should be used? in the bug report you recommend "linux-server" but that is transitional package, which is linux-generic?
[11:39] <xnox> smb: i believe in expert mode we offer a choice from generic & lts-backport kernels.... but one can preseed anything.
[11:40] <smb> xnox, Yeah, I think I mentioned that server and generic are only historical. But mainly not using linux-image-xxx and not -virtual if you install on real hardware.
[11:40] <xnox> smb: no idea where that user found linux-image-virtual as preseed value.
[11:40] <smb> xnox, The problem in that bug is that they use preseed and picked linux-image-virtual for some reason
[11:41] <smb> xnox, That is a very good question indeed. :-P
[11:45] <xnox> rsalveti: yeah, during platform build aosp does use -Wl,-shared,-Bsymbolic (libc.so generation et.al.)
[11:46] <xnox> rsalveti: do you want to just force those flags in Android.mk in the android build?
[11:47] <ogra_> would be good if we could do that differently (more globally) else it is another thing porters need to care about
[11:48] <ogra_> (though Android.mk sounds like a good last resort)
[11:48] <xnox> pitti: i'm not Merged-It-Last, but only tiny-patched-it-last =)
[11:48] <xnox> pitti: there are a few things from our sysvinit that should be pushed to debian, i'll look into those.
[11:49] <pitti> xnox: right, but as per the current TIL rules I'm supposed to ask you before I start on it
[11:50] <xnox> pitti: go for it.
=== MacSlow|lunch is now known as MacSlow
[12:39] <hakermania> ogra_, thanks a lot
=== work_alkisg is now known as alkisg
=== alkisg is now known as work_alkisg
[13:15] <smoser> pitti, bother utlemming about utopic images. i suspect /current would only get created when there was something with all arches output or possibly pushed to ec2.
[13:16] <pitti> smoser: ah, thanks
[13:17] <pitti> utlemming: ah, /current is blocked on getting buildable armhf cloud images, I suppose?
[13:17] <smoser> pitti, and ppc64el also at this point.
[13:17] <smoser> and arm64
[13:17] <smoser> stupid suporting to many archtectures!
[13:17] <pitti> ack, thanks
[13:18] <smoser> pitti the plan i think in this next cycle will be to decouple a lot of this.
[13:18] <pitti> so, I'll continue the regular "manually upgrade our VMs" morning exercise for the time being :)
[13:18] <smoser> so that you may have the simplestreams data update dfor a single product
[13:19] <smoser> ie com.ubuntu.cloud.daily:server:14.04:ppc64el from http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json
[13:19] <smoser> could get updated but com.ubuntu.cloud.daily:server:14.04:amd64 not
[13:31] <smb> stgraber, infinity Could one of you reject  	drbd8 2:8.4.3-0ubuntu0.12.04.2 from the unapproved queue. I would have a additional piece of fix to merge in
[13:31] <smb> Precise that is
[13:33] <infinity> smb: Sure.
[13:34] <infinity> pitti: Re: modemmanager, go nuts.
[13:35] <pitti> infinity: ack; synced
[13:36] <smb> infinity, thanks!
[13:38] <infinity> pitti: I see no evidence in the changelog that the bug would have been fixed, FWIW.
[13:39] <infinity> pitti: And I don't think I got around to filing a bug about the problem.
[13:39] <infinity> pitti: And, indeed, it just failed on ppc64el. :)
[13:39] <infinity> pitti: So, enjoy reapplying my 4-line diff. :)
[13:39] <pitti> meh
[13:39] <pitti> infinity: ack, will do :)
[13:41] <pitti> infinity: oh, so that's not actually an ICE or anything, just the -Werror=maybe-uninitialized
[13:42] <infinity> pitti: Right, but I didn't have the time to actually fix the code.  If you want to, please do and forward the patch back.
[13:46] <pitti> infinity: the chroots on porter, are they still the old-style "install packages and never remove cruft" things, or some sane ones with tarballs or overlays?
[13:47] <pitti> ah, apparently still rapt (which inconveniently fails, meh)
[13:47] <infinity> pitti: The former, sadly.  Someone needs to find time to mangle the DSA chroot stuff to work with lp-buildd tarball imports and hand off to IS, so we can have a nicer layout.
[13:47] <infinity> pitti: rapt is failing?
[13:47] <pitti> $ sudo apt-get build-dep modemmanager
[13:47] <pitti> AttributeError: 'apt_pkg.SourceRecords' object has no attribute 'Lookup'
[13:47] <infinity> build-dep has never worked in rapt.
[13:47] <infinity> dpkg-checkbuilddeps -B && transcribe by hand.
[13:47]  * pitti gives up and abuses one of his autopkgtest LXC containers then
[13:48] <infinity> But switching x86 to -O3 would expose the same bug, no need to test on PPC anyway.
[13:48] <pitti> infinity: ah, we build with -O3 by default on ppc64el?
[13:49] <infinity> pitti: Yeah.
[13:49] <infinity> pitti: Hence the s/-O3/-O2/ patch. :P
[13:51] <pitti> ah, so it does
[13:59] <Daviey> arges: Are you releasing openstack saucy sru?
[13:59] <arges> Daviey: Already did this morning
[13:59] <pitti> infinity: sent to https://bugzilla.gnome.org/show_bug.cgi?id=729267
[14:00] <ubottu> Gnome bug 729267 in ModemManager "Build failure: mm-modem-messaging.c:168:24: error: 'array' may be used uninitialized in this function" [Major,Unconfirmed]
[14:00] <pitti> infinity: this is actually quite serious
[14:00] <Daviey> arges: Ah yes, see it now.  Thanks
[14:00] <arges> np
[14:02] <infinity> pitti: And, yet, doesn't trip under -O2... I usually take that to mean some implicit initialization is being optimised out as a result of one of the extra optimizations.
[14:04] <mvo> infinity: build-dep never worked in rapt? hey, I'm here to help with that, tell me more please :)
[14:05] <infinity> mvo: Well, the solution isn't to fix rapt, it's to ditch it for dd-schroot-cmd.
[14:07] <pitti> yeah
[14:07] <pitti> these static permanent schroots are essentially useless once you clutter them with the first umpteen build deps
[14:08] <mvo> infinity: ok
[14:08] <pitti> chroot tarballs work quite well, and are ephemeral as they ought to be
[14:09] <seb128> mvo, don't be sad, if infinity doesn't have work for you I can find you stuff to work on *g*
[14:09] <infinity> pitti: Well, the other upshot of dd-schroot-cmd combined with pulling tarballs from LP is that you'd have an environment dangerously close to a real buildd.
[14:09] <mvo> seb128: haha, no worries, I don't get bored too soon :P
[14:09] <pitti> infinity: *nod*
[14:09] <seb128> mvo, ;-)
[14:15] <pitti> infinity: committed to Debian and uploaded a packaging git snapshot, so that we stay in sync
[14:16] <infinity> pitti: Cool, thanks.
=== TWWOC is now known as G
[14:22] <bdmurray> pitti: okay, I'll reject it then
[14:24] <pitti> bdmurray: someone already did
[14:26] <bdmurray> pitti: okay, thanks
[14:37] <bdmurray> mvo: Did you see https://errors.ubuntu.com/problem/70c1930688440b1818145db3346da61eb39a7ac8?
[14:39] <mvo> bdmurray: I didn't :/
[14:39] <xnox> Anyone has powerpc box to try out and see if this is a scilab regression or... openjdk? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/1314646
[14:39] <mvo> bdmurray: thanks a bunch, I prepare a fix
[14:39] <ubottu> Launchpad bug 1314646 in scilab (Ubuntu) "scilab fails to launch on powerpc" [Undecided,New]
[14:40] <bdmurray> mvo: you should have received an email from the phased updater (sent as me) about it
[14:40] <xnox> getfem++ could be build without scilab support on powerpc to unblock things.
[14:41] <mvo> bdmurray: indeed I did
[14:41] <jdstrand> xnox: I don't, but note that a new openjdk-7 was just pused to utopic-proposed a few minutes ago. might be worth seeing if the issue is still there
[14:43] <xnox> jdstrand: still a problem.
[14:43] <jdstrand> ah, too bad
[14:44] <sithlord48> can git-hg be used to import to launchpad?
[14:46] <infinity> sithlord48: Are you asking if a git-to-mercurial tool can be used to import a bzr project? :)
[14:46] <sithlord48> yes
[14:47] <infinity> I'll just leave that question there until it sinks in, then.
[14:47] <zyga> sithlord48: do you want git or hg?
[14:47] <sithlord48> the project uses hg
[14:48] <zyga> sithlord48: then if you get a git export then you gen get a bzr import on lp
[14:48] <xnox> sithlord48: http://blog.launchpad.net/notifications/mercurial-imports-will-end-on-october-5th
[14:48] <sithlord48> yeah i had seen that . so all i can do i get see if i can get the repo changeed to git or svn?
[14:49] <zyga> sithlord48: just use git
[14:49] <xnox> sithlord48: yeah, or host a git mirror somewhere. Maybe github offers hg->git mirroring?
[14:50] <sithlord48> ill have to see about the mirror then thanks.  i can't change it not my project . i am only trying to package for easier user testing.
[14:50] <xnox> jdstrand: fails in debian as well, i'll report to debian.
=== Ursinha-afk is now known as Ursinha
[15:04] <rsalveti> xnox: can we force it in the toolchain itself?
[15:05] <rsalveti> xnox: there's no way to force that flag just for the shared libraries it seems
[15:05] <rsalveti> we just have a global LDFLAGS
[15:05] <rsalveti> which then would be used for all the binaries, not only shared ones
[15:05] <xnox> rsalveti: i'm trying to figure out how. ANDROID_DEFAULT is set, and toolchain is using android linker script, which should give us -Bsymbolic.
[15:06] <xnox> rsalveti: doko pointed out that ubuntu build-flags maybe interracting negatively, but i've now did a rebuild with no dpkg-exported build-flags as well.
[15:06] <xnox> rsalveti: i'm doing a toolchain build using aosp ndk scripts. If that rebuild from source correctly & if that is using the right flags, i'll just upload that for now.
[15:07] <rsalveti> xnox: yeah, great then
[15:07] <rsalveti> thanks
[15:38] <jdstrand> pitti, jibel: hi! I just got a notification about this failure: https://jenkins.qa.ubuntu.com/job/utopic-adt-click-apparmor/1. Looking at the click-apparmor autopkgtest, this is what is failing: http://paste.ubuntu.com/7367050/
[15:39] <jdstrand> pitti, jibel: (this is in debian/tests/test_aa-clickhook, which uses /bin/sh)
[15:40] <pitti> jdstrand: hey
[15:41] <pitti> jdstrand: either detect a user by something like this: getent passwd | sort -t: -nk3 | awk -F: '{if ($3 >= 500) { print $1; exit } }'
[15:41] <pitti> jdstrand: or drop the "needs-root" and then your debian/tests/foo can do "sudo run/the/actual/test"
[15:42] <pitti> jdstrand: yeah, current machinery doesn't run tests through sudo any more (that was an internal implementation detail)
[15:42] <slangasek> ... "sudo run/the/actual/test"?  surely the adt interface doesn't guarantee that the running user has sudo access
[15:42] <pitti> no, it doesn't
[15:43] <pitti> it works on our qemu runner, not entirely sure about the LXC ones
[15:43] <pitti> so definitively better to pick an existing user, or even just hardcode "nobody" or so
[15:44] <pitti> or just call adduser in the test
[15:45] <jdstrand> pitti: ok, thanks
[15:49] <infinity> mvo_: If you need help speccing and testing that eol tool/script, you can bounce off me.
[15:49] <infinity> slangasek: ^
[15:50] <mvo_> infinity: thanks! I look into the details and then come back and ask for help I guess :)
=== seelaman` is now known as seelaman
=== bfiller is now known as bfiller_afk
[16:48] <rsalveti> xnox: any luck with your local i686 toolchain builds?
[16:57] <bdmurray> mvo_: do you want to upload ubuntu-release-upgrader for utopic?
=== negronjl is now known as negronjl-afk
[18:01] <mvo_> bdmurray: I have not prepared it yet, probably friday, but feel free to upload :)
[18:18] <hallyn> where do i get info on how we buidl the qemu images on which adt tests are run?
[18:19] <hallyn> looking at https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/1/?  and i can't reproduce on my own utopic i386 image...
[18:21] <xnox> hallyn: $ bzr branch lp:auto-package-testing; ./bin/prepare-testbed ./bin/run-adt-test ?
[18:22] <xnox> hallyn: it's a cloud image.
[18:22] <hallyn> xnox: thanks
=== dpm is now known as dpm-afk
=== roadmr is now known as roadmr_afk
[19:17] <zyga> hey
[19:17] <zyga> could someone please look at https://bugs.launchpad.net/ubuntu/+source/bzr-fastimport/+bug/1314771
[19:17] <ubottu> Launchpad bug 1314771 in bzr-fastimport (Ubuntu) "binary_stream cannot be imported from fastimport (the other project removed that function)" [Undecided,New]
[19:17] <zyga> I've attached a debdiff there
[19:17] <zyga> could someone please review that and upload it to utopic?
[19:18] <zyga> it breaks all bzr exports to othe version control formats
[19:19] <zyga> pitti: perhaps you? (sorry for poking)
=== bfiller_afk is now known as bfiller
[19:25] <cyphermox> I think I remember there was a workaround for msgmerge/msgfmt segfaulting in qemu/armhf for PPA builds. anyone remember what the workaround was? or am I misremembering this?
[19:34] <infinity> xnox: Say, do you want to look into why your no-change rebuild of devscripts fails autopkgtest?
[19:34] <infinity> xnox: I guess it migrated due to the nasty bug pitti and jibel are working on (or someone forced it), but it shouldn't have.
[19:34] <xnox> infinity: correct it should not have migrated.
[19:35] <xnox> infinity: also, last time i've looked all adt tests have not been retried on utopic before opening -> just those that happened to get triggered.
[19:35] <infinity> cyphermox: Do you have a specific build where this happens?
[19:35] <infinity> cyphermox: I'd be curious to try it out on one of the buildds where we upgraded qemu.
[19:35] <xnox> infinity: i've looked at devscripts failures, and i have -ENOCLUE
[19:35] <cyphermox> infinity: yeah: https://launchpadlibrarian.net/174263190/buildlog_ubuntu-utopic-armhf.urfkill_0.5.0%2B20140429.092522.b3b9563-0ubuntu1~mtrudel3_FAILEDTOBUILD.txt.gz
[19:35] <cyphermox> infinity: I expect it's probably fixed in a newer qemu yeah
[19:35] <infinity> cyphermox: Link to the build, not the log.
[19:36] <infinity> cyphermox: Pretty please.
[19:36] <cyphermox> just a second
[19:36] <cyphermox> https://launchpad.net/~mathieu-tl/+archive/ppa/+build/5964817
[19:36] <cyphermox> I just thought I had seen some kind of configure hack in the past to work around this, but my research has failed
=== ChickenCutlass_ is now known as ChickenCutlass
[19:55] <bdmurray> xnox: Do you mind uploading the fix for bug 1277706?
[19:55] <ubottu> bug 1277706 in ubiquity (Ubuntu Precise) "ubiquity in precise-updates, doesn't have tight enough dependency on python-apt leading to crashers" [High,Triaged] https://launchpad.net/bugs/1277706
[19:57] <infinity> cyphermox: Aww, no luck on qemu 2.0 fixing your segv.  It was worth a shot, though.
[20:00] <cyphermox> yup
[20:01] <cyphermox> well, it works on real hardware, I'll just have to look harder
=== roadmr_afk is now known as roadmr
[20:18] <xnox> bdmurray: i believe i did.... let me check.
[20:19] <xnox> bdmurray: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=ubiquity
[20:19] <bdmurray> xnox: oh, then let me approve it ;-)
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_