[00:03] <stgraber> slangasek: /sys/class/net/*/address will get you that
[00:06] <stgraber> slangasek: if you want to make sure you've got an ethernet device (and therefore a MAC), check that /type == 1 too
[00:08] <slangasek> bdmurray: ^^ does that give you enough info to execute on this for whoopsie?
[00:11] <slangasek> (of course, traversing directories in C is only the most tedious thing ever, but well.)
[00:16] <stgraber> slangasek: well, compared to the networking syscalls, traversing directories is piece of cake :)
[00:18] <bdmurray> slangasek: I think so
[00:18] <sarnold> popen("ls -1"); /* run away */
[00:20]  * infinity throws tomatoes at sarnold.
[00:28] <xnox> slangasek: bdmurray: ha, chipaca and I were finding bugs in whoopsie system identifier today at code&coffee. So as I side note, ubuntu push notifications use whoopsie system identifier to send notications.
[00:28] <Chipaca> xnox: to receive them, rather
[00:28] <slangasek> oh, then all the more reason we should fix it so that the system identifier is persistent once chosen ;)
[00:28] <Chipaca> stgraber: wlan devices also have MACs, tho
[00:28]  * xnox still thinks it should do uuidgen instead.
[00:29] <slangasek> Chipaca: yes, and wlan is a subset of ethernet for these purposes
[00:29] <Chipaca> slangasek: wfm :)
[00:29] <Chipaca> xnox: could you send me the code that segfaulted in the bum test, btw? wasn't able to reproduce your issue on the train home
[00:30] <xnox> Chipaca: so for my ubuntu account, how do i get the same push notification both of my unity8 desktop & my phone? Do both desktop & phone must have different IDs? or on the contrary the same one?
[00:31] <Chipaca> xnox: push messages are sent to tokens that are associated with (device, user, application) triads
[00:31] <xnox> Chipaca: it's on my laptop, let me fetch it out and push. I got my select/channel strategy right. I think I will have just one channel, and "for range" across it. And close it when needed.
[00:31] <xnox> Chipaca: that would be sequential processing and "go-like" i believe.
[00:31] <Chipaca> xnox: and what about the process that died etc etc?
[00:32] <xnox> go func(cmd) {message_queue <- cmd.Run(); message_queue.close()}
[00:32] <Chipaca> slangasek: stgraber: so you're going to change whoopsie to read /sys instead of siocgifblessyouconf?
[00:33] <Chipaca> a'ight
[00:33] <xnox> the other one (the webserver) is really just go server(conn) {message_queue <- "restart or pass"} more-or-less.
[00:33] <slangasek> Chipaca: I think bdmurray is taking this (bug #1328285)
[00:34] <Chipaca> excellent. that'll trickle down and avoid us some workarounds in push
[00:34] <xnox> Chipaca: such that if process dies, and there was no api call to restart, I exit and die, otherwise restart the worker.
[00:35] <xnox> Chipaca: but my scheme is on paper only at the moment (back of the envelope on the train), I'll write it up properly and will push for you to review.
[00:41] <infinity> xnox: The point of not using uuidgen was to at least have a fighting chance for a reinstall to end up with the same ID, I thought.
[00:42] <infinity> xnox: Which sounds even more interesting for the push notification thing than for the errors thing.
[00:42] <infinity> (Though, I'd expect notifications to be tied to an account, not a machine...)
[00:43] <Chipaca> for most services, yes, and applications need to support transparently re-requesting a token
[00:43] <xnox> infinity: however for the push thing at the moment, multiple fresh machine installs end up with the same ID at the moment when they shouldn't.
[00:43] <Chipaca> so uuidgen would work for us :)
[00:45] <slangasek> entertainingly, uuidgen contains the same bug
[00:45] <xnox> *fun*
[00:45] <slangasek> ioctl(3, SIOCGIFCONF, [...])
[00:46]  * xnox goes to fixing IMEI in ubuntu-emulator then
[00:46] <slangasek> of course, 'uuidgen -t' generates a different one each time it's called, so that's not suitable for values you want to persist across reinstalls, regardless
[00:46] <slangasek> which therefore makes it reasonable for it to only look at up interfaces :)
[00:48] <slangasek> xnox: why IMEI?  whoopsie prefers mac address over imei
[00:50] <slangasek> so if we fix this bug that causes whoopsie to not actually find not-yet-configured network devices, that would seem to be the most straightforward
[00:50] <xnox> slangasek: IMEI has bigger range I can use vs QEMU registered MACs (or maybe those are just reserved)
[00:51] <slangasek> xnox: ok; but we're not finding imei reliably on boot due to race conditions, and I was proposing we sidestep that
[00:51] <xnox> right, but making emulator's SIM be realistic is also worthwhile.
[00:51] <xnox> not finding imei reliably on boot -> how come?
[00:51] <slangasek> xnox: if we think we *should* prefer IMEI, then that's a whole other set of code changes
[00:51] <slangasek> xnox: because you can't query the imei until ofono starts, and you can't make whoopsie start on started ofono because it's not phone-specific
[00:51] <xnox> it's a properly of the SIM modem
[00:52] <xnox> oh, it's using ofono to query that, hm, not nice.
[00:52] <slangasek> (you can shove a .override into the lxc-android-config package, but those overrides should eventually go away :P)
[00:52] <slangasek> xnox: if by "property" you mean an android property, we should not be koolaid-man'ing the abstraction layers to query it directly from either whoopsie or the push notification service
[00:53] <slangasek> (indeed, I think ev initially proposed having whoopsie query it via android libs and I argued him down :)
[00:54] <xnox> haha, no not android properties. I would have thought one can query modems direct from like /sys/ but i guess we have ofono precisely because phone modems are anything but standard.
[00:54] <slangasek> right
[00:54] <slangasek> the middleware should be the interface
[00:55] <slangasek> now, the other thing I don't understand here is how the push notification service is getting /whoopsie's/ system identifier... is it linking to libwhoopsie?
[00:55] <xnox> and it looks like in the emulator at the moment i have to do $ adb shell start ofono, cause otherwise it's not getting started. Haven't checked yet, what's going wrong.
[00:55] <xnox> slangasek: yeap, ubuntu-push notification imports a go package called "C" which allows to link & call C functions.
[00:56] <xnox> slangasek: and it links in libwhoopsie (probably static, together with glib i guess)
[00:56] <slangasek> xnox: right, I wasn't questioning the mechanics of linkage :), just wondering if libwhoopsie is what it's using for this - and wondering to myself if it's right that libwhoopsie own this
[00:56] <xnox> slangasek: imho whoopsie should provide a dbus api socket to query system id (possibly dbus activatable)
[00:57] <slangasek> blarg
[00:57] <xnox> zorg?
[00:57] <slangasek> why in the world should this go over dbus?
[00:58] <xnox> not dbus as in dbusd system/session bus, but as in "any IPC call"
[00:58] <slangasek> if the system ID should be persistent once determined, it should be written to the filesystem and everything else should just read it from there (with a suitable wrapper)
[00:58] <slangasek> yes, why involve two processes in what should be a simple file read
[00:58] <xnox> make kernel export one in /proc ?!
[00:58] <xnox> well, /sys
[00:58] <slangasek> am I being trolled
[00:58] <xnox> I may have a sun-stroke =)
[00:59] <xnox> i see your point, it should be a task to write out system-id somewhere well-known early in the boot when it is deterministingly known.
[01:01] <xnox> i think ev was against that though, cause e.g. errors uses that id per-machine, not per-user. And knowing system-id one can check crashes from the other user.
[01:01] <slangasek> er, but isn't that security through obscurity?
[01:02] <slangasek> because the system ID is still generated deterministically based on publically-visible host info
[01:02] <slangasek> anyone can compute the system ID by hand if they have access to the machine
[01:02] <slangasek> we just don't do a good job of making the computation deterministically ourselves ;)
[01:12] <psusi> xnox, hi there.. I realized recently that there are some changes that we have to dmraid and mdadm that need merged into debian ( since the corresponding changes to libparted already have been and cause some breakage ).. I noticed you filed an ITA on dmraid a while back and was wondering if you are still planning on doing that?
[01:14] <xnox> psusi: i've replied to your private message, yes I need to upload dmraid into debian with all the changes i have staged. It's not ready for sid, but i can upload it into experimental.
[01:15] <xnox> psusi: what specifically are you after to get added to dmraid?
[01:36] <psusi> xnox, the 'p' partition separator changes for one, and the whole dmraid vs. mdadm for isw second
[01:37] <psusi> Curtis Gedak has been testing a new gparted livecd release based on sid and found that both mdadm and dmraid are trying to activate isw arrays
[01:37] <psusi> and that libparted thinks there should be a 'p' before the partition number but dmraid does not
[01:38] <psusi> it's also still not using kpartx to activate the partitions so won't work with gpt
[01:39] <psusi> I submitted the patches to kpartx to debian today that our dmraid changes depend on
[01:43] <psusi> also I realized that I made kpartx-boot a hard depends of dmraid... but it should probably just be a recommends since if you just want to access a dmraid array but not boot from it, you don't need kpartx-boot
[02:29] <tedg> slangasek, If someone has access to the machine they can just ask whoopsie for the ID, we don't lock it down. No reason for them to compute it.
[02:29] <slangasek> tedg: right; thus there's no reason for us to compute it each time on boot (and sometimes get a different answer!) rather than recording it on disk.
[02:30] <tedg> slangasek, yeah, I'd agree.
[02:31] <tedg> But I do think computing it from well known addresses is better than a uuid.
[05:06] <pitti> Good morning
[05:10] <pitti> tkamppeter: FYI, latest cups regresses its tests: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-cups/lastBuild/ARCH=amd64,label=adt/console
[05:10] <pitti> tkamppeter: "Error - unable to access "/usr/share/cups/data/testprint" - No such file or directory"
[05:19] <Unit193> pitti: Howdy.
[06:10] <tkamppeter> pitti, /usr/share/cups/data/testprint is part of cups-filters. Is it possible to introduce a dependency only for these tests?
[06:16] <RAOF> tkamppeter: Sure, add it to the debian/tests/control file.
[06:18] <tkamppeter> RAOF, thanks.
[06:56] <dholbach> good morning
[07:15] <pitti> tkamppeter: right, what RAOF said
[07:16] <pitti> hey dholbach, wie gehts?
[07:18] <Unit193> pitti: Decided to have fun, I'm on systemd 213.
[07:19] <pitti> Unit193: oh, wow :) I have 208 locally, with the necessary merges with Debian
[07:20] <Unit193> I have a minimal set of merges needed.
[07:31] <dholbach> pitti, sehr gut - und Dir? auch am Schwitzen?
[07:54] <pitti> dholbach: re from meeting
[07:54] <pitti> dholbach: oh ja, Sommer :) it's going to be fun this afternoon, avoiding brain melt
[07:55] <dholbach> haha, yes - it's supposed to be 36°C in Berlin today
[07:56]  * pitti rolls down the shades everywhere
[09:01] <dpm> morning cjwatson, I'm trying to create an i386 click chroot, but the following does not work: 'click chroot create -a i386 -f ubuntu-sdk-14.10' - it complains about architecture not being specified. Any ideas?
[09:05] <dpm> cjwatson, nm, wrong command order
[09:41] <ypwong> xnox, hey, wonder if you have some time to look at the seed branch of ubuntu kylin?
[09:44] <xnox> ypwong: i have. They look ok. I don't know what the next steps are, e.g. upload meta src-package which uses germinate to generate meta-package and subsequently switch image building to use that.
[09:48] <ypwong> xnox, who knows the next step?
[09:50] <xnox> most recently Laney did it for desktop-next, and a few other people know about introducing need seeds into the image building infrastructure (e.g. cjwatson, infinity, etc) but I should learn / find out what's needed as well.
[09:58] <ypwong> ypwong, should I wait for you for the instructions of what to do next? :) or i ask laney?
[09:59] <xnox> well a new meta package will need to be uploaded, and clear NEW queue, before we can proceed switching the build to the new metapackage. So sponsoring to utopic is the next step, that I can do.
[10:00] <xnox> Once that is done, further changes can be implemented.
[10:00] <xnox> I'll try to get that sponsored today.
[10:03] <ypwong> that's cool
[10:03] <ypwong> thanks for that
[10:03] <Laney> xnox: did you try a local build?
[10:04] <xnox> Laney: good point, nope. How would I do that? I've never did livefs+cdimage build.
[10:05] <xnox> (only d-i which is as easy as debuild)
[10:05] <Laney> I didn't test the cdimage part, just with live-build
[10:05] <Laney> to make sure the seeds are ~right
[10:05] <Laney> when doing desktop-next, that is
[10:05] <xnox> using lp:livecd-rootfs   ?
[10:06] <Laney> you need to add a project there, or modify the existing kylin one I guess
[10:07] <Laney> then I used http://people.canonical.com/~laney/random-scripts/build-ubuntu-iso
[10:07] <Laney> upload your stuff (seed package + livecd-rootfs) to a PPA and change the PROJECT and PPA in there, then run that from a scratch directory
[10:08] <Laney> mostly stolen from ubuntu-defaults-builder, thanks pitti ;-)
[10:08] <pitti> Laney: note that this is probably outdated, e. g. I never tried it with UEFI
[10:10] <Laney> right, just for testing in a VM that the stuff is good enough to try inside cdimage
[10:25] <seb128> yeah, that script isn't UEFI friendly, it didn't boot on the inspiron 11
[10:26]  * Laney nod
[10:38] <xnox> Laney: can you re-kick off ubuntu-desktop live i386 & amd64 builds? I believe the webbrowser-app uninstallability has been resolved.
[10:40] <Laney> okay
[12:19] <shadeslayer> mhall119: hey, who's Svetlana
[12:21] <doko> bdmurray, cjwatson: please could you subscribe foundations to cm-super bug reports (for a MIR)?
[12:23] <xnox> jibel: hm, smoke-iso-validation do not pull iso images from cdimage.ubuntu.com, but instead  pull them from some other mirror?
[12:25] <jibel> xnox, I don't know this job. let me check
[12:25] <xnox> jibel: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/ it should be pulling 10.1 image, but instead pulls 9
[12:25] <xnox> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/37/console
[12:26] <xnox> what's tachash.ubuntu-ci?
[12:27] <jibel> xnox, apparently it pulls ISOs from a machine somewhere in the lab. There must be a cron that updates them from cdimage.u.c
[12:27] <jibel> psivaa, ^ do you know?
[12:28] <jibel> xnox, but this is green now with your fix https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Ubuntu/
[12:28] <xnox> jibel: ah, good. So those pull the latest images!
[12:28] <jibel> xnox, yes, they pull directly from pending/
[12:29] <pkern> Who could I assign a kernel bug to for triage? (Patch landed upstream, workaround known.)
[12:29] <xnox> jibel: so should the other iso-validation and preseed jobs, cause those block pending -> current migration.
[12:29] <xnox> jibel: i guess i'll have to wait.
[12:30] <psivaa> xnox: yea, the tests run on aldeberan which takes the image from jatayu
[12:30] <xnox> psivaa: why not take images from cdimage?
[12:30] <xnox> psivaa: and/or what's the propagation delay?
[12:31] <xnox> psivaa: e.g. static-validation did see 20140610.1 image and does asserts for the image to be that, yet it pulled 20140609 under test
[12:33] <psivaa> xnox: no idea, may be retoaded knows why not taken from cd image
[12:34] <psivaa> xnox: static validation gets triggered once the checksum in the local cache is updated and at that point cdimage and the local cache will be in sync
[12:34] <xnox> hm, ok.
[12:34] <psivaa> if you trigger it manually before the full sync then you'd see issues :)
[12:35] <xnox> psivaa: =))))) damn
[12:36] <psivaa> xnox: speaking of static validation, i *think bsdtar in trusty is causing the failure, test_vmlinuz
[12:36] <psivaa> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/job/utopic-desktop-amd64-smoke-iso-validation/36/console
[12:37] <jibel> xnox, the sync script runs every 2 hours, so you'll have to wait.
[12:37] <pitti> dpm, jamespage, xnox: tomorrow's sessions about "langpacks for touch devices" and "systemd plans for server" are in the same time slot, any chance to move either of them? otherwise I'll attend the langpack one; xnox and slangasek know enough about systemd anyway
[12:37] <dpm> cjwatson, when you've got a minute, do you think you could help us with bug 1328486 ? We're trying to recommend the emulator for core app developers, and this one is blocking us on compiled apps. Thanks!
[12:37] <xnox> pitti: i was hoping to have you as an expert panellist on systemd one.
[12:38] <dpm> pitti, ok, thanks for the heads up. I've got no permissions on the devel track, but I think slangasek can reschedule meetings there
[12:38] <pitti> xnox: heh; I'm not actually that much of an expert in systemd (the boot part), I'm pretty much learning as I go :)
[12:38] <shadeslayer> slangasek: ping
[12:39] <xnox> dpm: i thought that failure serguisens and I fixed when we were in malta.....
[12:40] <dpm> xnox, I don't know, both zbenjamin and I could reproduce it. I'm using trusty, if that makes a difference.
[12:40] <dpm> or is the fix pending upload?
[12:42] <xnox> dpm: how is that a bug with click, instead of the bug in cmake of that app?
[12:46] <dpm> xnox, it's not just that app, (which builds fine on non-click x386 and click armhf), it can also be reproduced in the other example attached to the bug
[12:48] <mhall119> shadeslayer: she's belkinsa on irc, very active community person
[12:48] <shadeslayer> cheers
[12:51] <pitti> dpm: I implemented the percentage treshold now: http://paste.ubuntu.com/7623368/
[12:51] <pitti> dpm: I used 50% as Chinese has 59% coverage (as the number of packages in the image is quite a bit higher than the apps+unity8 in your web app, 70% is too high)
[12:53] <cjwatson> doko,bdmurray: done
[12:54] <cjwatson> dpm: what version of click are you using?
[12:54] <CodePulsar> What is the password for joining the IRC channels? I've registered at LaunchPad. How can I join the sessions?
[12:55] <cjwatson> no password
[12:55] <pitti> ogra, dpm: so http://people.canonical.com/~pitti/tmp/langpack-touch/ have 65 MB Installed-Size in total
[12:56] <pitti> those are the languages with at least 50% coverage
[12:56] <CodePulsar> I always get redirected to #ubuntu-uds-platform-1 instead of the actual channel
[12:57] <cjwatson> I don't know what actual channel you're talking about
[12:57] <pitti> ogra_, dpm: whereas on today's phone build we have a total Installed-Size: 139736
[12:58] <pitti> for just 5 languages
[13:01] <CodePulsar> cjwatson: nevermind, fixed the problem
[13:02] <ogra_> pitti, wow !
[13:03] <pitti> dpm, ogra_: spec updated
[13:09] <pitti> mvo: did you see the aptdaemon test regression? that looks real
[13:09] <mvo> pitti: uh, I have seen it but failed to investigate in detail :/
[13:09] <pitti> mvo: nevermind, thanks; mostly want to check whether email notifications are working
[13:09] <mvo> pitti: I wanted to get a new upstream release out of the door but it seems we are not there yet
[13:10] <mvo> pitti: aha, now I do remember, it wasn't failing on my normal box :/ need to test with a schroot
[13:34] <dpm> cjwatson, sorry, I was on the phone. I'm using click 0.4.25-ubuntu1~0trusty1
[13:34] <dpm> awesome, thanks pitti!
[13:40] <dpm> pitti, one thing I'd like to discuss in the session is how to make the stats and cut-off more meaningful and filter out the packages that are not visible in the UI
[13:40] <dpm> so that there's not a disconnect between what we're asking the translators to focus on the web stats and the l-p-o-matic stats
[13:42] <cjwatson> dpm: ok, will take a while to build the chroot
[13:43] <rbasak> infinity: what's the next stop for the juju-core powerpc ftbfs please? Currently it's impacting landing some bugfixes in Trusty and unblocking juju-quickstart from being broken in Trusty.
[13:44] <rbasak> I'm wondering whether to ask for an exception to get an SRU landed to Trusty ahead of this to unblock that.
[13:50] <dpm> thanks cjwatson
[13:51] <dholbach> xnox, is http://summit.ubuntu.com/uos-1406/meeting/22303/how-to-get-your-path-into-debian-ubuntu/ your session?
[13:54] <cjwatson> if so it's misspelled ...
[14:02] <xnox> dholbach:  yes.
[14:02] <xnox> cjwatson: i've corrected the spelling in the title, but url persisted?!
[14:03] <mapreri> xnox: the origianl url stays there to avoid breaking existing link. http://summit.ubuntu.com/uos-1406/meeting/22303/how-to-get-your-patch-into-debian-ubuntu/ works fine too.
[14:04] <xnox> mapreri: ok, cool.
[14:04] <dholbach> xnox, ok... I just asked because there's "How code contributions make it into Ubuntu" later on that day as well (run by sil2100 and myself)
[14:04] <dholbach> xnox, is it going to be a demo/presentation?
[14:05] <mapreri> xnox: too be honest, you can put everything after the numbers let the links works. e.g http://summit.ubuntu.com/uos-1406/meeting/22303/wrghoet/ works fine too :)
[14:06] <xnox> dholbach: can be merged if you wish, and I'll join you.
[14:06] <xnox> dholbach: it was a request to steve to host a session, let me find an email about it.
[14:07] <xnox> dholbach: hm, mhall119 requested to lead a development getting things into ubuntu session. I was planning to run through bug -> patch -> (ubuntu sponsorship queue) / (debian BTS patch submission) -> done
[14:07] <xnox> dholbach: and then take questions.
[14:08] <xnox> dholbach: not quite a demo.
[14:09] <dholbach> xnox, ah ok... looks like I tried to do the same thing - first show/explain how patches get into Ubuntu and then let somebody (in this case sil2100) talk about how changes get into all our upstream projects, which then go through CI, and at some stage land on touch images
[14:09] <dholbach> xnox, I'm not sure if all in all it wouldn't be too much to cover in an hour :)
[14:10] <sil2100> xnox, dholbach: I wanted to only mention the path of CI Train to get packages into the archive
[14:12] <dholbach> xnox, sil2100: if you think all the content fits into one session just fine, I'd let you two do the talking and I pass on the questions and/or ask some stupid questions myself :)
[14:13] <cjwatson> dpm: OK, I see the problem, thanks.  It won't involve rebuilding chroots, fortunately
[14:14] <dpm> cjwatson, ah, excellent. Will it require new package uploads, or is there a workaround I can use? I'm asking as I'm running a UOS session tomorrow about using the emulator for app development
[14:14] <cjwatson> dpm: see bug comment
[14:15] <dpm> ok, reading
[14:24] <michagogo> cjwatson: btw, why is it reqorts? Shouldn't it be reports?
[14:24] <michagogo> (also, reports does work, but it redirects...)
[14:28] <vmlintu> Hi, I'm trying to understand the 3.13 kernel maintenance process. How the patches end up there? The tree here has seen no activity for some time: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog  Am I looking at the right place?
[14:28] <cjwatson> michagogo: some infrastructure problem at some point I believe, but I don't operate it and know nothing
[14:28] <michagogo> Heh
[14:28] <slangasek> shadeslayer: pong?
[14:29] <cjwatson> vmlintu: #ubuntu-kernel is probably a better place to ask
[14:29] <shadeslayer> slangasek: how do you want to do session notes on the platform track
[14:29] <vmlintu> cjwatson: thanks, I'll ask there
[14:29] <michagogo> Also: is there a log of completed SRUs somewhere?
[14:29] <michagogo> (I'd like to take a look and see if there's an average time for them to be done)
[14:30] <slangasek> shadeslayer: hmm.  An etherpad?
[14:32] <shadeslayer> slangasek: well, do we have a schedule on who's covering what?
[14:33] <slangasek> shadeslayer: I assumed that the track leads who approved the talks would be responsible for covering them (or soliciting notes from the session leads)
[14:33] <shadeslayer> ah ok
[14:34] <bulletxt> hi, Ubuntu 14.04 is shipping gutenprint 5.10 PRE2   but the final release came out some time ago. Do you think you can update it to latest release? Thanks a lot
[14:46] <pitti> dpm: yep, sounds good
[14:57] <dpm> cjwatson, thanks for investigating bug 1328486 - I understand this will need a fix in click and a subsequent upload. For my demo tomorrow, shall I go for the hack you're mentioning (despite the warning), though? Or do you think you might be able to come up with a branch I could use directly for the demo?
[14:59] <cjwatson> dpm: I have a mostly fairly quiet day, so I'll see what I can do between sessions
[14:59] <dpm> ok, thanks!
[15:00] <cjwatson> dpm: not sure I can get a landing through in time, so it might be "use this branch for now"
[15:01] <dpm> cjwatson, I think that'd be perfect
[15:31] <TuxRescue> friendly greetings. nobody on #ubuntu could answer the qestion why "apt-cache show" will not display tag information (debtags) and my google efforts leave me without usable results
[15:31] <TuxRescue> are tags not used at all in ubuntu?
[15:33] <CodePulsar> Ubuntu Login and Launchpad can have the same password?
[15:33] <CodePulsar> I've changed the password on my Ubuntu Login account and now I cannot login to LaunchPad
[15:35] <TuxRescue> CodePulsar: easy: try your old new and your old password?
[15:35] <TuxRescue> nvm
[15:35] <CodePulsar> The password is the same
[15:35] <CodePulsar> There is some mismatch somewhere
[15:36] <CodePulsar> ah found the culprit
[15:36] <CodePulsar> the password manager didn't change the password
[15:37] <CodePulsar> Also, Why I cannot login with Ubuntu Login to Launchpad, i.e. authorize Launchpad in Ubuntu Login, why do I have to provide the password in LaunchPad which is the same as Ubuntu One, or is this process doing exactly what I say?
[15:38] <CodePulsar> Ubuntu Login user/pass is the same as LaunchPad user/pass ?
[15:39] <rbasak> CodePulsar: try asking in #launchpad.
[15:39] <rbasak> TuxRescue: I have no idea, but askubuntu.com is a good place for that kind of question.
[15:40] <TuxRescue> okay, sorry
[15:46] <mterry> Is anyone familiar with starting hangouts for Ubuntu Online Week?  I get the error "Sorry, Hangouts On Air has been disabled by your domain administrator"
[15:46] <mterry> mhall119, ^
[15:47] <mhall119> mterry: several people are having that with their canonical account, please ask IS for help, there's nothing I can do there
[15:47] <CodePulsar> mhall119: do you have the browser plugin installed?
[15:47] <CodePulsar> mterry: ^
[15:47] <mterry> CodePulsar, I think so?  I've participated in hangouts before
[15:48] <CodePulsar> about:plugins
[15:51] <CodePulsar> mterry: are you logged in with the "right" Google account?
[15:51] <mterry> CodePulsar, yeah
[15:54] <dholbach> xnox, sil2100: so do we feel we can merge all this content into one hour or what should we do?
[15:54] <sil2100> dholbach: both sessions are tomorrow?
[15:55] <dholbach> as both sessions are tomorrow, it might be good to make any necessary change now, so folks have time to adapt to a changed schedule
[15:55] <Laney> I think you need more than an hour to cover both CI train and packaging and forwarding to Debian
[15:55]  * Laney both <three things>
[15:56] <dholbach> Laney, I guess you're right... we'll just leave everything as it is for now
[15:56] <dholbach> sil2100, xnox: ^
[15:56] <Laney> dholbach: Maybe make them concurrent?
[15:56] <Laney> not that I'm involved so feel free to ignore :)
[15:58] <Laney> I meant sequential not concurrent, sorry was reading something about threading at the same time...
[15:58]  * Laney goes away now
[15:58]  * dholbach hugs Laney
[15:58] <pitti> stgraber, infinity: reminder: TB meeting in #u-m-2 in 2 mins
[16:00] <mterry> bregma, are you able to start a canonical on air session?
[16:00] <mterry> bregma, neither seb128 nor I can start one due to technical problems with IS
[16:01] <bregma> doesn't look like it
[16:01] <mterry> :(
[16:02] <mterry> stgraber, can you by any chance?   ^
[16:02] <seb128> dholbach, mhall119: did other people had issues with their account being restricted?
[16:02] <stgraber> mterry: nope, I'm leading another session at the moment
[16:02] <dholbach> seb128, mhall119 said earlier to talk to IS about it - they should know more about what's wrong
[16:02] <mhall119> seb128: yes
[16:03] <mterry> stgraber, ah, OK.  well at least it works for someone  :)
[16:03] <mterry> dholbach, yeah I talked to IS.  They escalated the issue but weren't sure of ETA
[16:04] <dholbach> mterry, seb128: so nobody can run the desktop session now?
[16:04] <mterry> dholbach, looks like it
[16:04] <dholbach> let me see if I can
[16:05] <seb128> dholbach, I can't
[16:05] <seb128> google tels me that live hangouts are desactivated and I need to talk to my admin about it
[16:11] <mterry> bregma, can you join?
[16:15] <xnox> dholbach: well my session was going to be <<1h, and the ci-train/packaging has potential to overrun.
[16:15] <xnox> dholbach: can we have a 2h slot between all of us back-to-back
[16:15] <dholbach> sure... I don't know when exactly sil2100 has time
[16:16] <sil2100> dholbach, xnox: theoretically I have time all UOS, since I have to be around anyway :)
[16:17] <sil2100> So I'm fine with anything tomorrow I guess
[16:21] <dholbach> sil2100, would 15 UTC tomorrow work as well? that'd be right after xnox' session
[16:22] <dholbach> xnox, sil2100: do you feel we need to rename the sessions somewhat to make the difference clearer?
[16:22] <xnox> dholbach: sure call them "Kill Bill vol1" & "Kill Bill vol2"
[16:22] <sil2100> dholbach: that time is fine for me I guess
[16:22] <xnox> dholbach: or some more appropriate titles.
[16:22] <sil2100> dholbach: and don't listen to xnox !
[16:22] <dholbach> xnox, sounds great!
[16:22] <dholbach> I never saw the movies :)
[16:23] <xnox> dholbach: danke schon, meine freund!
[16:23] <xnox> sil2100: alles klar?! =)
[16:24] <sil2100> xnox: ja ;)
[16:25] <xnox> sil2100: fantastisch!
[16:27] <dholbach> xnox, sil2100: already - I moved the session
[16:28] <dholbach> sil2100, maybe we could call the session "from fix to phone: getting your fix on the Ubuntu phone" or some such? just to make it clearer and distinguish from the other session?
[16:29] <sil2100> dholbach: hm, since CI Train can be also used for desktop, I'm not sure if this completely fits my part of the session :)
[16:29] <dholbach> hum, ok
[16:30] <dholbach> I was just trying to come up with a catchy title ;-)
[16:30] <sil2100> Maybe 'from fix to image' instead? Then it could mean both phone and desktop ;)
[16:35] <dholbach> sil2100, works for me!
[16:40] <Laney> from my keyboard to your screen
[16:40]  * Laney is a marketing genius
[16:41] <dholbach> Laney, maybe you want to move to the comms team!
[16:41] <dholbach> xnox, sil2100: we're all set then :)
[16:42] <sil2100> dholbach: thanks for taking care of this :)
[16:42] <sil2100> Laney: hah! ;)
[16:42] <dholbach> no worries
[16:42] <Laney> A first in class patch distribution process bringing enterprise grade deployment strategies to the Ubuntu ecosystem
[16:43] <xnox> Laney: as seen on TV!
[16:44] <Laney> I'll take ten!
[16:46] <shadeslayer> jsalisbury: ping, got a moment to discuss https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310402
[16:46] <shadeslayer> jsalisbury: I have baloo upstream here too, so would be nice if you had a moment to sort it out
[16:47] <shadeslayer> s/it/this/
[16:47] <dholbach> Laney, I'd say our holistic strategy utilises user-centric processes to empower our users users to bring powerful synergy effects to Ubuntu. What do you think?
[16:48] <sarnold> I'm not sure you've really captured the idea that ubuntu is by and for the users though. could you mention them a bit more?
[16:49] <jsalisbury> shadeslayer, sure.  It might be better to discuss on #ubuntu-kernel
[16:49] <dholbach> sarnold, ok, you'll have the post of propaganda minister in our team - we'll have our first meeting on Monday
[16:49] <shadeslayer> vHanda: ^^ ok
[16:49] <sarnold> sweet. I'll polish up my medals.
[16:49] <xnox> rbasak, jamespage - i wonder if maybe you could help me. cgo is passing "-marm -march=armv7-a -mfloat-abi=hard" when compiling, which my compiler doesn't like, saying "gcc: error: unrecognized command line option '-marm'"
[16:50] <xnox> rbasak: jamespage: any idea, what's wrong? I do have GOARM=7 set in the environment.
[16:51] <rbasak> xnox: not really my department, sorry. I don't have any specific experience with cgo.
[16:52] <rbasak> xnox: but my immediate question is: you're calling gcc - native on amd64? Do you need it to be calling a cross compiler, or are you native on armhf already?
[16:52] <xnox> rbasak: hm, ok. I do wonder if installing gcc-multilib would resolve it.
[16:52] <xnox> rbasak: it's calling ["arm-linux-gnueabihf-gcc", "-E", "-dM", "-xc", "-marm", "-I", "/tmp/go-build772552266/runtime/cgo/_obj/", "-Wall", "-Werror", "-"]
[16:53] <xnox> from strace.
[16:53] <rbasak> Ah, OK. It's not that then.
[16:53] <xnox> it just shouldn't pass -marm, as the cross-compiler is not a multilib one and doesn't need "-marm" flag
[16:53] <rbasak> Yeah I did wonder that.
[16:53]  * xnox writes a shell wrapper that drops -marm flag....
[16:53] <rbasak> It's a little bit of an unusual situation though - with cross compiling. It wouldn't surprise me if you've hit an edge case not previously considered.
[16:53] <xnox> or should i recompile cgo
[16:53] <rbasak> Yeah I was going to suggest a wrapper :)
[16:54] <rbasak> Though I don't see why gcc shouldn't accept that flag anyway
[16:54] <xnox> rbasak: i'm guessing, doko would say it's a lie.
[16:55] <xnox> who is not online, hm.
[17:04] <cjwatson> dpm: There's a branch linked from the bug now.
[17:04] <cjwatson> https://code.launchpad.net/~cjwatson/click/native-dpkg-architecture/+merge/222690
[17:04] <cjwatson> mvo: ^- could you review that when you get a chance?
[17:04] <mvo> cjwatson: sure, let me have a look
[17:04] <cjwatson> oh damn wrong target
[17:05] <cjwatson> old habits die hard.  fixing
[17:05] <cjwatson> mvo: https://code.launchpad.net/~cjwatson/click/native-dpkg-architecture/+merge/222691
[17:05] <dpm> oh awesome, thanks cjwatson!
[17:06] <cjwatson> mvo: huh, mvo_ isn't you?  I was talking to that user in /msg and hadn't had a reply ...
[17:07] <mvo> cjwatson: it may just be a leftover connection
[17:07] <cjwatson> Not your usual /whois output
[17:07] <mvo> cjwatson: *ick*
[17:28] <brotoes> Hello all. I am creating an internal APT repository using reprepro and apache2. The distributions config file seems to want a paragraph for every release of ubuntu. is it necessary to add every distribution of ubuntu you want the repo to work with to the file?
[17:41] <cjwatson> mvo: thanks, fixed the mocking now
[17:42] <mvo> thanks cjwatson, its really a detail all the tests will be exercised on the buildds
[17:42] <cjwatson> ... and remembered to push
[17:42] <mvo> s/a/as/
[17:42] <cjwatson> yeah, it does make it easier locally though of course
[17:42]  * mvo nods
[17:42] <cjwatson> Crudest mock ever but hey
[17:46] <cjwatson> stgraber: Could you stick https://code.launchpad.net/~click-hackers/click/devel/+merge/222702 into the CI Train, please?
[17:48] <stgraber> robru: hey, I'm getting "stgraber is missing the Job/Build permission" again... is that related to the Jenkins problems?
[17:48] <mvo> cjwatson: heh, mock is fine, we have a fake-dpkg in the apt testsuite that is simlar
[17:48] <robru> stgraber, hm, i'll check
[17:49] <robru> stgraber, which job are you trying to run?
[17:49] <stgraber> robru: trying to assign a silo for cjwatson
[17:49] <robru> stgraber, ah indeed, the permissions I added got reverted
[17:49] <cjwatson> dpm: does bug 1328486 still need its non-click tasks?
[17:50] <robru> stgraber, ok try now
[17:50] <stgraber> robru: worked, thanks!
[17:50] <stgraber> cjwatson: you've got silo 14
[17:50] <robru> stgraber, now I'll try to make it really permanent ;-0
[17:50] <cjwatson> stgraber: thanks
[17:51] <cjwatson> stgraber: did you already hit build or shall I?
[17:51] <stgraber> cjwatson: I didn't hit build for you
[17:51] <cjwatson> ok, will do that
[17:56] <psusi> cjwatson: I'm trying out git-dpm to update the parted git repo and naturally there are conflics trying to rebase the patches... what I can't figure out is how to tell what patch is now half applied ( conflicted )?  all I can see is that these files have been changed and have conflicts, but I have no idea why.. any tips?
[17:57] <cjwatson> psusi: well it's just the usual things for git rebase, IIRC you normally get <<< >>> markers
[17:58] <psusi> yes, the conflicts are marked in the code, but what I'm looking for is the log describing what change I'm in trying to resolve
[17:58] <cjwatson> oh I remember that being awkward
[17:58] <cjwatson> there's a file somewhere under .git, I forget the name, you can pass it to "git show"
[17:58] <psusi> I thought it was supposed to be in .git/COMMIT_EDITMSG, but it seems to hold the previous correctly applied patch isntead
[17:58] <cjwatson> .git/rebase-apply/patch or something
[17:59] <cjwatson> https://stackoverflow.com/questions/2118364/how-to-identify-conflicting-commits-by-hash-during-git-rebase
[17:59] <psusi> dpm seems to be using rebase-merge rather than rebase-apply
[17:59] <cjwatson> some trivial variant of the above procedure worked the last time I needed this anyway
[18:00] <psusi> hrm... boy, what a pain
[18:01] <cjwatson> yeah, this could be easily improved in git rebase I suspect
[18:01] <psusi> you'd think that git status would tell you the name of the commit you are in the middle of trying to resolve
[18:01] <cjwatson> all it'd need to do is tell you the commit hash and first line of ... yeah
[18:03] <psusi> aha... git log --color -p -n 1 `cat .git/rebase-merge/current` does the trick
[18:04] <cjwatson> that sounds about right; I think you can even just pass the file name rather than `cat ...`
[18:05] <psusi> seems it wants the `cat ...`
[18:08] <cjwatson> ok
[18:32] <xnox> rbasak: tracked it down between the talks -> right compiler, wrong linker = caboom!
[18:37] <rbasak> xnox: nice :)
[18:47] <psusi> cjwatson: I think I found a bug in git-dpm.. been git rebase --skip'ing a lot of the patches since they are merged in the new upstream... but I got to one it won't let me get past... git rebase --skip just tries to apply the same patch over again
[18:49] <cjwatson> psusi: I had that once but could never reproduce it accurately.  But what makes you think it's a bug in git-dpm rather than in git rebase?
[18:49] <psusi> could be.. I'm not sure how git-dpm is actually interacting here
[18:49] <cjwatson> I think I ended up restarting the rebase from scratch and it went away
[18:50] <cjwatson>         gitcmd rebase -m --onto "$UPSTREAMREV" "$oldupstream" || ret=$?
[18:50] <cjwatson> really nothing especially special
[18:51] <cjwatson> if you can figure out an accurate reproducer then I'm sure git upstream would appreciate the report
[18:51] <cjwatson> maybe one that's a bit smaller than "rebase parted" :)
[18:51] <cjwatson> I think I hit it with password-store a while back
[18:52] <psusi> so there isn't any sort of hook that gets run in dpm until after you are completely finished with the rebase?
[18:53] <cjwatson> not afaik
[18:53] <cjwatson> it's all just plain git at this level
[18:54] <dpm> cjwatson, the fix for click works wonderfully, thanks :)
[18:54] <cjwatson> dpm: great - should be publishing at the moment so with any luck you'll have it in utopic in time for your session tomorrow
[18:55] <dpm> excellent
[18:55] <cjwatson> dpm: I don't maintain the trusty backport so you'll need to ask whoever does to update that
[18:55] <dpm> cjwatson, that's fine, I can take care of that
[18:55] <cjwatson> cool
[19:00] <psusi> well, other than this apparent git bug getting stuck and the lack of a simple/automatic description of what patch you are trying to resolve, which is just another git shortcoming, so far git-dpm seems pretty sweet
[19:01] <xnox> Chipaca: totally cross-compiled ubuntu-push-client.go. piece of cake 4 line invocation of "go build"
[19:01] <xnox> http://blog.surgut.co.uk/2014/06/cross-compile-go-code-including-cgo.html
[19:33] <cjwatson> mvo: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/lastBuild/?
[19:34] <mvo> thanks cjwatson
[19:47] <bharper> Does Ubuntu have any documentation for building packages for a third party repo?  Any special consideration like package naming converstions?
[19:47] <seb128> is there known multiarch issues on utopic?
[19:47] <seb128> http://pastebin.ubuntu.com/7625153/ is what seems to happen when trying to crossbuild ubuntu-system-settings
[19:47] <seb128> "                    Depends: libc6-dev:armhf but it is not going to be installed or" is in the log
[19:48] <cjwatson> apt's output tends to be misleading once things go wrong enough
[19:48] <cjwatson> has this package ever cross-built before?
[19:48] <seb128> pmcgowan, what happens if you try to apt-get install libc6-dev:armhf ?
[19:48] <cjwatson> if not, it probably needs additional things converted to multiarch in various ways
[19:48] <seb128> cjwatson, yes, it was working fine in trusty, Laney fixed issues with rdepends a few times
[19:49] <seb128> I guess something in utopic regressed there
[19:49] <cjwatson> I'm confident libc6-dev:armhf is a red herring
[19:49] <pmcgowan> seb128, Recommends: gcc:armhf but it is not going to be installed
[19:49] <seb128> do you have any tip debugging such issues?
[19:49] <cjwatson> you typically have to iterate on adding every mentioned package to a single large apt-get install call until you get more useful errors
[19:49] <cjwatson> and keep an eye out for anything that's nonsensical
[19:50] <seb128> pmcgowan, what about apt-get install gcc:armhf ?
[19:50] <cjwatson> quite often failures are because you end up trying to install host-arch versions of things that really should be tools (i.e. build arch)
[19:50] <cjwatson> gcc:armhf is one such nonsensical thing; you don't want that
[19:50] <seb128> cjwatson, is that normal that apt stops on recommends?
[19:50] <pmcgowan> seb128, just keeps chaining
[19:50] <cjwatson> seb128: --no-install-recommends
[19:51] <seb128> pmcgowan, does it work if you "apt-get build-dep --host-architecture=armhf --no-install-recommends  ubuntu-system-settings"
[19:51] <pmcgowan> seb128, no same thing
[19:52] <cjwatson> will need work, doubt I can debug this with twenty-questions on IRC
[19:52] <seb128> pmcgowan, ok, anyway it's not likely a local error but a bug, I'm going to try to have a look tomorrow
[19:52] <pmcgowan> seb128, thanks a lot
[19:52] <seb128> cjwatson, yeah, I was thinking the same, thanks for helping ;-)
[19:52] <cjwatson> oh I don't have a useful chroot for this right now
[19:53] <cjwatson> will build one after this session
[19:53] <seb128> cjwatson, don't worry, I can try debugging it tomorrow (might ping Laney for help if needed, he did some of that before ;-)
[19:53] <seb128> you already have enough to do
[20:00] <xnox> seb128: it could be transient, and
[20:01] <xnox> typing in the wrong window
[20:02] <xnox> seb128: pull-lp-source ubuntu-system-settings; sbuild --host armhf *.dsc cross-compiles fine. So (a) disable proposed, (b) it might not be a clean chroot.
[20:02] <seb128> pmcgowan, ^
[20:02] <xnox> pmcgowan: do you have a complete log of what's failing?
[20:02] <seb128> xnox, http://pastebin.ubuntu.com/7625153/
[20:03] <xnox> seb128: that's not a full sbuild run, e.g. with apt-get update and sources used etc.
[20:03] <pmcgowan> xnox, I did that earlier and had the same issue
[20:03] <pmcgowan> well
[20:04] <pmcgowan> I did an sbuild on a chroot I made, and it failed to get the deps
[20:04] <xnox> pmcgowan: it could have been transient, since there is new gcc in proposed.
[20:04] <pmcgowan> maybe my chroot is bad then
[20:04] <xnox> it does eventually FTBFS
[20:04] <cjwatson> certainly disabling -proposed is a good idea whenever you're expecting multiarch to work in any way whatsoever
[20:04] <xnox> /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
[20:04] <seb128> bah, what is "dpkg --add architecture armhf" doing? I did that and now my apt-get complains about invalid sources
[20:04] <cjwatson> since the arch skew in -proposed frequently causes failures and that's specifically something that proposed-migration guards us against
[20:05] <xnox> but that's 91% into compiling.
[20:05] <xnox> seb128: oh, you need to arch qualify all your sources.
[20:05] <cjwatson> seb128: just use mk-sbuild --target=armhf utopic
[20:05] <xnox> seb128: i hate that.
[20:05] <seb128> cjwatson, thanks
[20:05] <cjwatson> you don't want to add an architecture to your regular system for this kind of thing
[20:05] <cjwatson> it will just be a pain
[20:05] <pmcgowan> cjwatson, how do I disable proposed for the chroot?
[20:05] <seb128> well, that "regular system" is my test laptop
[20:05] <xnox> seb128: well, $ mk-sbuild --target=armhf --skip-proposed utopic
[20:05] <cjwatson> pmcgowan: edit /etc/apt/sources.list
[20:05] <cjwatson> seb128: even so
[20:06] <cjwatson> oh yeah --skip-proposed
[20:06] <pmcgowan> ah
[20:06] <cjwatson> pmcgowan: it's possible you already have stuff installed from there though; if you can easily recreate it from scratch with the mk-sbuild command above, then do
[20:06] <xnox> pmcgowan: seb128: https://wiki.ubuntu.com/Touch/CrossCompile
[20:06] <pmcgowan> cjwatson, yeah I will start over (again)
[20:06] <pmcgowan> yeah thats what I used
[20:07] <xnox> that has the 2-step guide, plus extra info
[20:07] <pmcgowan> simply didnt work for me
[20:07] <seb128> xnox, thanks, googling I found https://wiki.ubuntu.com/CrossBuilding which was not that useful
[20:07] <seb128> or maybe it was
[20:07] <cjwatson> feel free to add --skip-proposed to that :)
[20:08] <seb128> I just tried to add it to my normal system :p
[20:08] <seb128> e.g avoiding sbuild
[20:08] <xnox> seb128: well it has the same two steps down in the middle of the page.
[20:08] <seb128> right, just noticed
[20:08] <cjwatson> and maybe add sterner comments to it about how taking shortcuts probably won't help :)
[20:08] <seb128> but I didn't want to sbuild (maybe I was wrong)
[20:08] <xnox> seb128: your normal system will break, when you try to e.g. cross-compile something that pulls in armhf GLES and knocks out your GL (compiz/unity7....)
[20:09] <pmcgowan> cjwatson, so to be sure, how do I clear out my existing bad schroots
[20:09] <seb128> xnox, well, I don't care, that's my "test unity8 desktop session" test box
[20:09] <cjwatson> pmcgowan: make sure they're not in use (schroot -l --all-sessions), then you can just remove the relevant things from /var/lib/schroot/chroots/ and /etc/schroot/chroot.d/
[20:09] <cjwatson> seb128: more importantly it's just much more of a pain to debug anything not in a clean chroot
[20:09] <cjwatson> and there are some conflicts you hit when trying to do things in a full system + extra architecture that won't happen in a clean chroot
[20:10] <cjwatson> so I actively recommend against that approach
[20:10] <seb128> cjwatson, that's true, though often a real system is enough to hit installability issues and debug
[20:10] <seb128> noted
[20:10] <cjwatson> yeah, but seriously you get *loads* more
[20:10] <seb128> thanks ;-)
[20:10] <cjwatson> it will waste ridiculous amounts of time :)
[20:10] <cjwatson> at least used to
[20:10] <seb128> I somewhat got twisted habits because my laptop has a 80G disk and I'm avoiding extra chroots or vms there
[20:11] <cjwatson> you end up trying to make the whole desktop multiarch-compatible in ways that aren't otherwise necessary
[20:11] <cjwatson> pmcgowan: you might want to use the rm --one-file-system option for safety
[20:11] <pmcgowan> too late, all gone
[20:12] <cjwatson> ok, if your home dir is still there then I guess it's fine :)
[20:12] <pmcgowan> ;)
[20:12] <cjwatson> *cough*
[20:12] <pmcgowan> hmm good point
[20:13] <pmcgowan> but it is
[20:13] <cjwatson> checking for no active sessions first is usually enough
[20:13] <pmcgowan> I quit the session and nuked them first
[20:14] <cjwatson> dpm: click 0.4.26.1, will be in utopic after this publisher run
[20:15] <dpm> cjwatson, excellent. And perfect timing, I just got my first compiled app to build and run on an x86 emulator from Qt Creator :)
[20:16] <cjwatson> (informal version number format: backward-incompat.backward-compat for version of packaging format spec, then landing count, then optional brown-paper-bag count for landing failures)
[20:16] <cjwatson> dpm: great
[20:18] <mvo> cjwatson: sorry for the jenkins breakage, I'm fixing it now
[20:20] <cjwatson> np, thanks
[20:20] <pmcgowan> dpm, awesome, glad it worked
[20:21] <dpm> pmcgowan, yep, all ready for the demo session tomorrow
[20:28] <cjwatson> dpm: please can you delete the non-click tasks on that bug then, since it sounds like it was never a problem there?
[20:30] <dpm> cjwatson, sure, done
[20:30] <cjwatson> ta
[20:33] <hallyn> infinity: hey, you had said earlier that qemu upstream had aarch64 full emulation patches you wanted.  Could you check ppa:ubuntu-virt/virt-daily-upstream and see if that trusty package has what you need?  (i need to merge at least 2.0.0+dfsg-6, maybe git head into utopic soon)
[20:33] <hallyn> patches in https://github.com/susematz/qemu/commits/aarch64-1.6 are still noticably absent from upstream though
[20:34] <infinity> rbasak: How is an FTBFS in utopic blocking anything in trusty?  That sounds like a process failure I can't help with. :P
[21:05] <Chipaca> xnox: code or gtfo :)
[21:15] <Noskcaj> pitti, I think you can sync psqlodbc, the ubuntu delta is no longer needed (i think)
[21:17] <xnox> Chipaca: it's not that bad =) i'm sure you can wrap it in your makefile easily ;-)
[21:17] <Chipaca> xnox: why would i?
[21:18] <Chipaca> (serious question; is there a benefit?)
[21:18] <Chipaca> xnox: i guess building on my computer and testing the resulting binary on the phone?
[21:19] <xnox> Chipaca: yes, and a table of 15 people bugging me that "they can't build on the phone any more, cause dependencies don't fit to install" and they are using go with cgo and have no way to compile code locally anymore for testing
[21:20] <Chipaca> xnox: :) ok
[21:20] <xnox> Chipaca: and thus relying on e.g. 40minute feedback loops to get binaries from e.g. merge proposal.
[21:21] <Chipaca> hey, if dependencies for push fit on the phone, ... what dependencies are they trying to get that don't fit?
[21:21] <xnox> Chipaca: dunno, scopes go something
[21:22] <Chipaca> xnox: while you're in this neck of the woods, and seeing as how you have me thinking about this already, ...
[21:22] <Chipaca> xnox: how do i cross-compile the signing helper?
[21:23] <xnox> Chipaca: what is signing helper?
[21:23] <Chipaca> xnox: in ubuntu-push, under signing-helper
[21:23] <Chipaca> xnox: usually built with e.g. cmake && make
[21:24] <xnox> Chipaca: do that, but in a click chroot, or prefix cmake with $ dpkg-architecutre -aarmhf -c cmake && make
[21:24] <xnox> Chipaca: but since it uses Qt5, i'd do it in a click chroot.
[21:25] <Chipaca> xnox: pointers to read up on click chroots?
[21:25] <Chipaca> xnox: is that just a regular arm schroot? qt5 builds ok in there?
[21:25] <xnox> Chipaca: http://paste.ubuntu.com/7625572/
[21:26] <xnox> Chipaca: yeah, it's a regular amd64 chroot, with crossbuild-essential-armhf + installing most of ubuntu-sdk-libs-dev packages that are multiarch installable
[21:26] <Chipaca> neat
[21:27] <Chipaca> anyway, i came online to find an audiobook to listen to while ironing school uniforms
[21:27] <xnox> Chipaca: i don't know where are our click chroot docs, cause create needs funky args which I got wrong way around lately (as in it only installed stuff for like html5 apps, instead of cross-compiler to compile native binaries)
[21:28] <Chipaca> xnox: I'll look it up in a bit
[21:28] <Chipaca> xnox: thanks :)
[21:31] <xnox> Chipaca: I think $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 create
[21:31] <xnox> should do the right thing, and then
[21:31] <xnox> $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 run cmake .
[21:31] <xnox> $ click chroot -aarmhf -fubuntu-sdk-14.10-papi-dev1 run make
[21:32] <xnox> in the signing-tool folder should cross-compile everything the right way
[21:33]  * Chipaca obeys
[21:33] <Chipaca> hmm, create needs sudo
[21:33] <xnox> yeap.
[21:33] <xnox> damn fails
[21:33] <xnox> then i'd try
[21:34] <xnox> $ sudo click chroot -aarmhf -fubuntu-sdk-14.04-papi-dev -sutopic create
[21:34]  * Chipaca continues setting up his ironing space
[21:34] <xnox> which is do what 14.04 would do, but force use utopic
[21:35] <xnox> or maybe my click package is simply out of date
[21:35] <Chipaca> create still progressing, here
[21:35] <xnox> right good.
[21:35] <xnox> than it's just me.
[21:37] <xnox> blimey 1k of packages to update, didn't touch desktop in a while.
[21:37] <Chipaca> xnox: what did you need to do to make cgo cross-compile? anything?
[21:38] <xnox> Chipaca: install all the build-dependencies by hand & specifying an arch for native things (e.g. libglib2.0-dev:armhf but just golang-go-linux-arm)
[21:38] <xnox> Chipaca: and yes, pass environment for CC, GOPATH, PKG_CONFIG_LIBDIR, and linker
[21:39] <Chipaca> xnox: so, that's the code i meant. I'll add it to the makefile (including fetching the deps and all).
[21:39] <Chipaca> xnox: just probably not tomorrow :)
[21:39] <Chipaca> unless it's in patch form, that is
[21:39] <xnox> Chipaca: well i have patches against upstream go submitted to make that invocation more simple.
[21:40] <Chipaca> ooohh