[00:16] <mdeslaur> Unit193: crud. Thanks, I'll prepare a regression fix for the regressions fix :)
[00:17] <Unit193> mdeslaur: Thank you very much.  Patch only needs changed offset.
[00:22] <chiluk> my squid-deb-proxy and squid3 seem to be in a fight to the death... and neither seems to function.
[00:55] <mdeslaur> Unit193: security update regressions suck. If someone pings me about them, they can be sure I'll prioritize fixing them quickly. Thanks!
[00:56] <Unit193> 'Welcome, and thanks again.
[03:41] <pitti> Good morning
[04:22] <pitti> doko_: lintian> whoops, fallout from python 3 porting; added test, fixed, pushed out, restarted test
[07:06] <dholbach> good morning
[07:28] <Noskcaj> could someone please merge libvirt?
[07:28] <Noskcaj> hallyn, ^
[07:44] <michagogo> infinity: KMS FTW?
[07:45] <michagogo> (re: VL activation)
[07:53] <dpm> morning pitti - I was going to approve the webbrowser-app template for utopic, but I've noticed that rather than uploading a single po/webbrowser-app.pot template, there seems to be one for each architecture -> https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot - would you have any idea why? It's the first time I've seen this in a template
[07:53] <pitti> hey dpm
[07:54] <dpm> hey :)
[07:54] <pitti> dpm: I don't have a definitive answer, did LP changed recently in that regard?
[07:54] <pitti> dpm: we indeed do build translation tarballs on every arch, but we've done so forever
[07:55] <dpm> I can't be 100% certain, but I wouldn't think LP has changed anything in translations recently
[07:56] <dpm> pitti, I don't seem to see it with other packages in the imports queue, seems to be something in that package only
[08:00] <pitti> dpm: another hypothesis is that it might differ between architectures?
[08:00] <pitti> most templates and po files should be identical on all arches
[08:00] <pitti> but maybe this does some magic and encodes the architecture in a translatable string or so
[08:01] <dpm> it shouldn't have any differences, afaik
[08:01] <dpm> but I guess I'll have to ask Olivier when he comes online
[08:02] <pitti> dpm: they are indential except for the POT-Creation-Date:
[08:39] <mardy> xnox: hi! About yesterday's signon-ui stuff: what is a dummy package? Is it just an entry in debian/control (with no files shipped) that just depends on the newer stuff?
[08:40] <xnox> mardy: yes.
[08:40] <xnox> mardy: apt-cache search dummy -> that should bring up plenty of examples.
[08:41] <mardy> xnox: oh right, good idea. Thanks!
[08:43] <Chipaca> ev: good morning to you sah
[08:43] <ev> morning!
[08:47] <Chipaca> ev: so. Should we store the whoopsie id on the filesystem after calculating it the first time?
[08:49]  * ev tries to find where we had that conversation last night, for review :)
[08:50] <Chipaca> ev: here :)
[08:50] <Chipaca> ev: but also, slangasek commented in the bug
[08:50] <Chipaca> bug 1328285 that is
[08:51] <ev> hm
[08:52] <ev> Chipaca: where are we even seeing this, now that we have IMEI support? Emulator?
[08:53] <Chipaca> ev: which of the "this"es?
[08:54] <ev> Chipaca: it looking at the MAC addresses
[08:54] <Chipaca> hmmmm
[08:55] <Chipaca> ev: the imei is appended to the mac, because it isn't big enough
[08:55] <Chipaca> ev: no mac, no whoopsie id
[08:55] <ev> ah right
[08:56] <Chipaca> ev: that's what my branch solves
[08:57] <Chipaca> ev: my quesiton was about the next step: currently the whoopsie id depends on interface ordering, which is not stable (and can change not only between boots but also during a single boot by e.g. loading stuff)
[08:57] <Chipaca> ev: so we should probably store the whoopsie id once we've gotten a 'known good' one
[08:59] <ev> well that's where I'm worried. A big point of this was to allow for an identifier that would span reflashes of the device or reinstalls of the OS
[08:59] <ev> but I'm struggling to think of an alternative off the top of my head
[09:01] <Chipaca> ev: so: you currently don't have that
[09:01] <Chipaca> ev: or rather, you have that more by accident than by design :)
[09:01] <ev> okay, so how about this. We stop using MAC addresses, which are hard to get consistent results from, and instead grab some other static information from the device in the case of phones (manufacturer, serial, etc).
[09:01] <mardy> jpds: hi! Do you have a minute to talk about bug 1329629
[09:02] <Chipaca> ev: and on non-phones?
[09:02] <ev> In the case where we don't have a phone and still don't have a dmi table to work with, we write "unidentified-system" or something like that
[09:02] <ev> and then we can at least see how big the problem is
[09:02] <ev> because big data
[09:02] <Chipaca> :)
[09:04] <ev> well maybe something a bit more granular than that
[09:04] <ev> unidentified-system-no-dmi-not-phone
[09:04] <ev> unidentified-system-bogus-dmi
[09:04] <ev> and so on
[09:05] <ev> (the latter case being xnox's crazy back of a van laptop)
[09:05] <ev> mpt: I don't suppose you have any thoughts on this? (What we do when we don't have enough stable unique information in the hardware to generate a system identifier)
[09:07] <mpt> ev, I do not :-)
[09:07] <ev> :)
[09:08] <ev> Chipaca, bdmurray, slangasek, tedg: are you happy with this plan? ^
[09:11] <Chipaca> ev: once concern: sounds like a lot of work
[09:12] <ev> probably less work than carefully managing a file on disk
[09:12] <ev> much less work if slangasek wouldn't mind us using libandroid-properties ;)
[09:15] <ev> I should help with this, but lately volunteering my time for hacking is a good way to have things take ages.
[09:16] <ev> I'll still try if no one else can pick it up
[09:16] <ev> (and if we're all in agreement that it's the right course)
[09:17] <Chipaca> I don't see libandroid-properties as being any worse than the current dmi thing
[09:25] <ev> yeah, I'm struggling to remember what Steve's concern was with it. I think he wanted that whole library dead.
[09:40] <darkxst> r0ckhoff9i5
[09:40] <diwic> darkxst, oops
[09:40] <diwic> darkxst, if that was a password you probably want to replace it now
[09:52] <infinity> ev: Why are you so against a file on disk?
[09:53] <infinity> ev: Getting enough sources to generate a unique ID implies it might not be perfectly stable.  Doing it once and storing it solves that for, at least, that install.
[09:53] <infinity> ev: And never having to do the work again until the next fresh install is also just saner at runtime.
[09:53] <ev> infinity: because files on disk do not persist across installs
[09:53] <infinity> ev: Sure, but how does that relate?
[09:54] <ev> because the identifier is there to identify machines, not installations
[09:54] <infinity> ev: If you come up with an algorithm that you think has a high probability of giving you the same result across two installs, having a file on disk is STILL BETTER than calculating at every boot, or every init of a library or whatever.
[09:55] <ev> ah, I just got angry and didn't read what you actually wrote. Oops?
[09:55] <shadeslayer> bdmurray: btw how big was the old tracker db ? :P
[09:55] <infinity> ev: Unless you're really concerned that someone's going to move a hard drive between machines and you think it should suddenly be a "new machine" because of that.
[09:55] <infinity> ev: But I'd argue that's the same machine, just with a bunch of new parts. :P
[09:55] <ev> infinity: I'm not against having a file there as a cache
[09:55] <shadeslayer> bdmurray: for errors.ubuntu.com
[09:55] <ev> shadeslayer: several terabytes
[09:56] <shadeslayer> whoa
[09:56] <ev> yeah, cassandra is pretty damn good for really big data
[09:56] <infinity> ev: Right, the file as cache thing was what both Steve and I were arguing for.  By all means, if you can make the algorithm (mostly) stable, go for it, but you're probably never going to get that perfect, so the file saves you there, plus it's just more efficient to have the cached ID.
[09:56] <ev> infinity: yeah, I was reading most of that inbetween walking home and making dinner, so apologies for missing the finer points
[09:57] <ev> for what it's worth, I'd rather us be as close to perfect as we can, discarding what we cannot be perfect about
[09:57] <ev> well not discarding, but lumping that together so we can know how much of an impact it would have
[10:00] <infinity> ev: Well, you'll always have the whitebox problem where many motherboard don't have model numbers or serial numbers.
[10:00] <infinity> ev: RAM often has serial numbers, but that's replaced probably as frequently as NICs.
[10:01] <ev> yeah, but that's what unidentified-system-bogus-dmi is for
[10:01] <infinity> ev: Right, I'm saying that I suspect that bucket will be larger than you think, but an interesting experiment.
[10:01] <ev> systems like xnox's, which as far as I can tell was bought by some shady character from the back of a van
[10:01] <ev> yes, so we make it big, then find ways to whittle it down
[10:01] <ev> bought off*
[10:02] <infinity> How badly this all falls over on !x86 is another interesting connundrum.
[10:02] <ev> ugh, I really need to ditch this mac keyboard for something decent. If only to prevent my hands from sweating to nothingness. Any recommendations?
[10:02] <infinity> Not talking phones, where you can be saved by an IMEI, but ARM servers, POWER servers, etc.
[10:03] <infinity> ev: Ducky keyboards are love.
[10:03] <ev> POWER? Pshh, who cares about /that/
[10:03] <pitti> I still swear on the Kinesis keyboards :)
[10:03] <xnox> ev Sculpt is the best http://www.microsoft.com/hardware/en-gb/p/sculpt-ergonomic-desktop/L5V-00006
[10:03] <infinity> Anything with cherry mechanical switches, really.
[10:03] <pitti> well, that might be ambiguous in English -- I mean I just love them
[10:04] <darkxst> diwic, only half, wonder what happened to the first half!
[10:04] <xnox> infinity: ev would be eaten alive if he brings mechanical keyboard into the office =)
[10:04] <ev> this yeah? http://www.amazon.co.uk/Ducky-DK9087-Shine3-Keyboard-DK9087S3-BUKPTYY1/dp/B00I47XNNM/ref=sr_1_6?s=computers&ie=UTF8&qid=1402653827&sr=1-6
[10:04] <infinity> xnox: There are cherry switches that don't make clicky noises.  I use brown, personally, quiet.
[10:05] <ev> xnox: I sit with IS now. I'm surrounded by James' laugh and the sound of the foosball table
[10:05] <ev> I bet you do.
[10:05] <infinity> ev: They make dozens.  This is the one I'm using right now: http://www.amazon.co.uk/Keyboard-Zero-Mech-Brown-Switch/dp/B00GJVA9XW/ref=sr_1_1?s=computers&ie=UTF8&qid=1402653916&sr=1-1&keywords=ducky+zero+brown
[10:06] <xnox> ev: any space for one more body near IS? =)
[10:06] <ev> yeah, come on down
[10:06] <ev> infinity: ooh, that's nice!
[10:06] <ev> thanks
[10:06] <ev> xnox: London is always happy to have you
[10:07] <infinity> ev: If you're considering a mechanical keyboard, researching the different switch "colours" is helpful, but brown is pretty office friendly, and a really nice feel.
[10:07] <ev> (if we were just on the other side of that bridge this joke would work on multiple levels)
[10:07] <infinity> ev: Reminds me of the old skool (PowerMac G3 and earlier) Mac keyboards, but a bit more travel, and much less prone to early demise.
[10:08] <davmor2> xnox: you'll note he didn't say he is always happy to have you ;)
[10:08] <ev> davmor2: shh you. He didn't pick up on that. :)
[10:09] <davmor2> ev: oh sorry I didn't realise it was a secret ;)
[10:09] <xnox> davmor2: i thought it was more of a stab that snob ev, doesn't consider SE3 to be in London =)
[10:09] <ev> I should bring in a PowerMac, if only to complain about how well Ubuntu works on it to IS
[10:09] <ev> and to look so awesomely retro
[10:09] <xnox> ev: can PowerMac do juju?
[10:09] <ev> It's not London!
[10:09] <xnox> ev: what's your post-code?
[10:09] <ev> Greenwich is at best "Greater London"
[10:09] <ev> NW5
[10:10] <ev> but just barely
[10:10] <ev> right on the NW3/5 edge
[10:10] <xnox> yeah but NW3 is much closer than SE3 though.
[10:11] <xnox> http://www.doogal.co.uk/images/london_postcode_map.gif
[10:11] <pitti> wow, I never realized these postcodes encode compass directions
[10:11] <xnox> pitti: for london they do.
[10:11] <xnox> pitti: elsewhere they don't.
[10:12] <ev> pitti: it's also how the gangs organise themselves
[10:12]  * Laney wonders what NG7 counts as
[10:12] <Laney> the badlands
[10:12] <ev> if Britain is anything, it's order.
[10:12] <xnox> pitti: otherwise it would have been impossible to navigate around london. Cause there are same street names in every postcode more or less.
[10:12] <ev> NG7?! Is that even a thing?
[10:12] <xnox> pitti: typically though the post-codes spiral out
[10:13] <xnox> ev: don't worry, it's outside of M25 =)
[10:13] <ev> There's land beyond the green belt?!
[10:13] <ev> No, I refuse to believe this.
[10:13] <xnox> pitti: with XX1 being the city-center.
[10:13] <pitti> clever
[10:14] <xnox> pitti: e.g. more traditional http://en.wikipedia.org/wiki/File:HU_postcode_area_map.svg
[10:15] <xnox> pitti: i used to live in HU16 which was considered "posh" as you are far away from the center, yet the post-code is small hence has expensive houses / subburbs.
[10:15] <xnox> well, expensive..... expensive for Hull, in northern england.
[10:15] <Laney> hahaha
[10:16] <Laney> you need to get further out into the villages to be actually posh
[10:16] <xnox> Laney: who shall I blame for packaging dbus headers really wrong?! =)
[10:17] <Laney> use the changelog?
[10:17] <xnox> Laney: doko: utter maddness - /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/dbus-arch-deps.h
[10:17] <jpds> mardy: I wasn't the last one that touched the LinkedIn plugin.
[10:17] <xnox> Laney: doko: utter maddness - /usr/include/x86_64-linux-gnu/dbus-1.0/dbus/dbus-arch-deps.h would be better.
[10:19] <Laney> the pcfile gets the right directory
[10:20] <davmor2> ev, xnox: within the sound of Bowe Bells is technically London if you ask a Cockney :)
[10:33] <xnox> Laney: yeah, but still ugly =)
[10:33] <Laney> go send a patch upstream :P
[10:35] <mardy> jpds: but you made the first merge proposal; what I wanted to ask you, is whether you registered the app key on your account, or if it was registered by IS
[10:36] <jpds> mardy: I remember that I asked people to register one.
[10:36] <jpds> mardy: Not sure how the code's progressed since then.
[10:37] <mardy> jpds: no, the code is still the same, and it's working OK, but we need some changes on the key. I'll ask IS to look into it, then
[11:39] <mdeslaur> Unit193: how are you getting xubuntu-docs to fail to build with the current libxml2 packages? It seems to build fine for me
[11:39] <mdeslaur> I'd like to figure out why it's failing so I can make sure I fix it properly
[11:40] <Unit193> How it's doing translations, so `make translate` should do it.
[11:41] <Unit193> It's also validate, which is what will be the clear indicator.
[11:47] <mdeslaur> Unit193: oh! ok, I see the errors now, thanks. I wasn't failing the build, but I should have looked at the log.
[11:50] <Unit193> Sure thing, whatever helps.
[12:30] <mvo> @pilot in
[12:31]  * dholbach hugs mvo
[12:38] <Sm21> ubuntu sux
[12:39] <mdeslaur> dad?
[12:39] <Sm21> i have the balls to say it
[12:39] <Sm21> ubuntu has lost touch
[12:39] <Sm21> unity sux
[12:40] <infinity> Sm21: Is any of this on topic for a development channel?
[12:40] <Sm21> yes
[12:40] <infinity> Sm21: Hint, this IRC channel isn't your personal soapbox.
[12:40] <Sm21> infinity, the truth hurts, hint.
[12:41] <ikonia> Sm21: I've just removed you from #ubuntu channels - do you want to leave here too ?
[12:41] <ikonia> if not - please stop with the random rants, and ask your development questions/input
[12:41] <Sm21> ok mark shuttleworth is all about making money and you are all his fanboys
[12:41] <infinity> Sm21: Ubuntu is a lot more than just Unity.  If you prefer other desktop environments, there are plenty of other flavours and, this being a development channel rather than a personal ranting channel, you could help work on one of them.
[12:41] <ikonia> Sm21: final warning
[12:42] <IdleOne> Enough is enough. Start a blog if you want to rant
[12:42] <pitti> thanks ikonia
[12:42] <ikonia> well that worked out well for him
[12:56] <michagogo> "Patch Pilots: mvo" <-- what does that mean?
[12:58] <mvo> michagogo: see https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=show&redirect=PatchPilot
[12:58] <mvo> michagogo: it basicly means that I will sponsor to upload fixes into the distro and/or land branches
[13:01] <infinity> mvo: And the equally important review and reject. :P
[13:05] <mvo> infinity: heh, true!
[13:06] <xnox> barry: hey! I'm trying to work through all the bugs you filed a while ago against system-image vs emulator
[13:06] <xnox> barry: so i have a couple of scripts that will let you boot emulator in both normal & recovery modes
[13:07] <xnox> but at the moment it fails downloading things.
[13:07] <xnox> aka bug #1261552
[13:08] <xnox> not sure who is suppose to normally create /android/cache/recovery
[13:10] <ogra_> xnox, android ... when you initially install the device with it
[13:11] <ogra_> xnox, all we do is to mount the cache partition under /android/cache
[13:12] <infinity> ogra_: My Android device doesn't have a recovery directory under /cache...
[13:13] <ogra_> infinity, then your android device doesnt need it ... and thats fine ... your nexus device would have it though
[13:14] <infinity> ogra_: This is a Nexus.
[13:14] <ogra_> oh ?
[13:14] <ogra_> id /cache actually mounted ?
[13:14] <ogra_> *is
[13:14] <barry> xnox: i saw the activity on those bugs - do you have something i can test?
[13:14] <infinity> ogra_: I would assume so...
[13:14] <ogra_> well, i have often seen it being only mounted on demand ...
[13:15] <infinity> Oh, maybe I can't read it as !root, and my file manager is being unclever and telling me it's empty.
[13:18] <pitti> seb128, dpm: do you happen to know any universe package which uses X-Ubuntu-Use-Langpack?
[13:18] <dpm> pitti, I think we tested it with synaptic at some point but we disabled it
[13:18] <pitti> seb128, dpm: On http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs I created a list of sources which are in universe, have translations, and are on the touch image
[13:19] <seb128> pitti, gnome-panel used to, let me check if it still does (I think it was reverted because it was buggy)
[13:19] <pitti> none f them use that
[13:19] <seb128> https://launchpad.net/ubuntu/+source/gnome-panel/1:3.6.0-0ubuntu2
[13:19] <xnox> barry: yeah, so if you have latest & greatest ubuntu-emulator it should have --recovery option.
[13:19] <seb128> hum, got reverted indeed
[13:19] <seb128> pitti, no, I don't
[13:19] <xnox> barry: ubuntu-emulator run --help to check
[13:20] <xnox> barry: with that you can create e.g. i386 emulator like so http://paste.ubuntu.com/7638850/
[13:20] <pitti> seb128: I was mostly wondering whether my grepping was wrong, but seems we indeed don't use it much
[13:20] <xnox> barry: with extra commands to get the recovery initrd "in the right way"
[13:20] <xnox> barry: i've picked revision 70 as arbitrary recent one, yet behind current. With a hope to "system-image upgrade it"
[13:21] <pitti> dpm: in case you are "unnamed", I already have a section for "skip these" :)
[13:21] <xnox> barry: use-raw-disk -> such that state is preserved across reboots.
[13:21] <dpm> pitti, damn you caught me! :)
[13:21] <xnox> barry: how i did start the emulator (with --memory 2048 to get it spin faster)
[13:21] <dpm> not sure why my name is not in there
[13:21] <seb128> pitti, http://ubuntu-codesearch.surgut.co.uk/search?q=X-Ubuntu-Use-Langpack
[13:21] <xnox> barry: and i get to the same as in the above bug -> /android/cache/recovery is missing and downloads file
[13:22] <xnox> barry: http://paste.ubuntu.com/7638863/
[13:22] <pitti> seb128: thanks; so my grepping was correct
[13:22] <xnox> barry: i'm running this as root and e.g. cd /android/cache/recovery; wget https://system-image.ubuntu.com/gpg/image-master.tar.xz does work
[13:22] <barry> xnox: is that utopic's ubuntu-emulator, or from a ppa?
[13:23] <xnox> barry: it's utopic's ubuntu-emulator. It should be safe to install on any releases. We compile it such that one can do binary copy and install it on e.g. precise
[13:23] <pitti> sil2100, dpm, seb128: so we should mark these 14 universe sources for langpack-ification; it's not a 5 minute script job due to citrain, or does that now automagically merge back from teh archive?
[13:23] <xnox> barry: i can compile it for your choice of distro =) what are you running?
[13:23] <pitti> i. e. what is less intrusive, mass-upload them with a script and sync back the bzrs, or propose 14 MPs?
[13:24] <barry> xnox: utopic of course! :)
[13:24] <xnox> barry: you are such a unicorn =)
[13:25] <dpm> pitti, I've added a note for the indicators - do you think it might be worth promoting those 2 packages to main instead? I don't have a preference, just mentioning it for the sake of consistency with the rest of indicators
[13:25] <seb128> pitti, I would go with "email the list and let the respective upstreams get that landed with their next changes"
[13:25]  * barry imagines a double-entendre off-color retort
[13:25] <xnox> barry: so i have no clue what system-image-cli is not liking about the emulator, but it should be all good to go
[13:26] <pitti> dpm: maybe; in fact I think *all* of those should be in main, and touch should only be built from main :)
[13:26] <sil2100> pitti: hard to say, I would use CITrain for that if those are bzr-enabled in overall, as in this case the landing should be quick
[13:26] <xnox> barry: and i believe everything is fixed now (channels are right, we have ability to boot into recovery with crutches, etc.)
[13:26] <barry> xnox: what we need is an interface to boot into recovery from inside the emulator, e.g. `reboot -f recovery` is what the phones do.  will that work?
[13:26] <pitti> sil2100: yeah, it's a purely mechanical change; so 14 MPs, leave them in approved, and fold them into the next uploads?
[13:26] <seb128> pitti, you can do mps and let respective lander handle the landings as well, if you feel like doing the mps
[13:26] <pitti> it's not like we need to immediately upload them
[13:26] <seb128> but I would just send the email
[13:27] <xnox> barry: that's in progress. I have a hacky way to get that working. Essentially i replace "reboot" binary with a script that does: nc 10.0.0.1 <<EOF
[13:27] <seb128> let teams include those
[13:27] <xnox> reboot recovery
[13:27] <xnox> EOF
[13:27] <pitti> seb128: can do as well
[13:27] <seb128> then do mps for the remaining ones in few weeks, if there are some that got ignored
[13:27] <xnox> barry: and that connects to the host, and reboots the emulator into recovery.
[13:27] <dpm> hi oSoMoN, I was asking pitti this morning, but you might know more as it's your app -> I was going to approve the webbrowser-app template for utopic, but I've noticed that rather than uploading a single po/webbrowser-app.pot template, there seems to be one for each architecture -> https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot - would you have any idea why? It
[13:27] <dpm> 's the first time I've seen this in a template
[13:27] <xnox> barry:  i can give you those scripts as well, we haven't integrated it yet into ubuntu-emulator proper.
[13:27] <dpm> or ogra_, as you were the last uploader ^
[13:28] <ogra_> huh ?
[13:28] <pitti> sil2100: a third option would be to just bzr commit the changes directly to trunk, but I guess we don't do that any more, as trunk == archive, not staged changes, right?
[13:28] <pitti> I mean s/trunk/the upstream branch/
[13:28] <ogra_> dpm, i never uploaded webbrowser-app in my life
[13:28] <xnox> barry: driving "ubuntu-emulator run" & "ubuntu-emulator run --recovery" externally should be enough to see what else we are missing. E.g. can we run system-image in download only mode? and externally validate download, & trigger reboot into recovery?
[13:28] <sil2100> pitti: yeah, I wouldn't propose that as it might confuse landers and upstreams
[13:28] <barry> xnox: yeah, that would be great.  i can write a reboot hook that does the low-level bits in the mean time.
[13:29] <sil2100> pitti: I would stick to MPs :)
[13:29] <pitti> sil2100: ok; so I guess I'll mail the list first
[13:29] <seb128> pitti, just do an email to phone with "upstream from those projects, can you include those small changes"
[13:29] <seb128> and wait
[13:29] <dpm> ogra_, ah, it seems to have your name and sil2100's in https://translations.launchpad.net/ubuntu/utopic/+source/webbrowser-app/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
[13:29] <ogra_> dpm, i think CI train is cheating you ...
[13:29] <seb128> then we can see what's remaining to do
[13:29] <xnox> barry: my crutches are in http://bazaar.launchpad.net/~xnox/+junk/killerd/files
[13:29] <dpm> ogra_, might well be :)
[13:29] <oSoMoN> dpm, no idea why, but I guess the files themselves are identical, maybe except for the generation timestamp
[13:29] <xnox> barry: i make emulator.conf upstart user session job (as one would naturally do)
[13:29] <xnox> barry: start killerd.go service on the host
[13:29] <dpm> oSoMoN, yes, they are identical except for the timestamp
[13:30] <ogra_> dpm, if i took a look at debian/control and changelog and ACKed that it might put my name into the upload field even though i dont know anything about the upstream code
[13:30] <xnox> barry: which does start/stop emulator and passes --recovery as needed.
[13:30] <xnox> barry: that's good for shutdown/reboot/reboot-recovery from the host
[13:30] <xnox> barry: but not good for shutdown/reboot/reboot-recovery from whilst booted into recovery as we have no "nc" there yet =)
[13:30] <xnox> whoops =) which i'm fixing
[13:31] <xnox> barry: the idea is to get "reboot -f recovery" work with dirty tricks behind the back.
[13:31] <mpt> ev, bdmurray: What happened to the graph?
[13:31] <barry> xnox: sounds good.  i'll play with this today if i get a chance
[13:32] <xnox> barry: kk
[13:33] <xnox> barry: if anything do shout and i'll try to respond asap =)
[13:34] <xnox> mpt: new cassandra database, starting from day 0.
[13:34] <xnox> mpt: it will be eventually "stitched" together
[13:34] <xnox> mpt: see email on ubuntu-devel about it
[13:35] <barry> xnox: awesome, thanks
[13:38] <kdeuser56> would you consider the following issue as a bug: when creating a /boot partition in ubiquity, the partition does not seems to have a UUID and is not mounted using UUID in fstad
[13:38] <kdeuser56> (using btrfs filesystem)
[13:38] <xnox> kdeuser56: why would it be?
[13:38] <kdeuser56> for ext2,3,4 it works
[13:39] <xnox> kdeuser56: ext doesn't use pools and subvolumes =)
[13:39] <kdeuser56> xnox: yeah but mounting using /dev/sdXY is not really good
[13:40] <kdeuser56> xnox: imagine I install in a virtual machine ... then /boot would be sda1, but when booting on the real setup it is /dev/sdb1
[13:40] <kdeuser56> xnox: thats what made me curious about that issue
[13:41] <xnox> kdeuser56: is it actually causing a problem for you, or you just dislike the generated /etc/fstab ?
[13:41] <xnox> e.g. did the install fail to boot?
[13:41] <kdeuser56> xnox: it causes problems and manual intervention
[13:41] <kdeuser56> xnox: no boot did not fail, just /boot was not mounted on the booted target system
[13:42] <kdeuser56> xnox: and it indicated that on the first boot (Failed to mount /dev/sda1 on /boot)
[13:42] <xnox> kdeuser56: please open a bug about that. with $ ubuntu-bug ubiquity
[13:42] <xnox> kdeuser56: which will attach all the right logs, and it doesn't attach, do attach the resultant /etc/fstab
[13:43] <kdeuser56> xnox: It is for sure a bug, because blkid does not find a btrfs boot partition generated by ubiquity
[13:43] <kdeuser56> xnox: btrfs root partitons are fine though ...
[13:44] <kdeuser56> xnox: what could result in a uuid not being there?
[13:45] <xnox> kdeuser56: sorry, i'm busy now. Did you open a bug report? what's the bug #?
[13:58] <hallyn> Noskcaj: zul is working on it.  zul, how's 1.2.5 coming?
[13:58] <hallyn> (libvirt, obv)
[13:58] <zul> hallyn:  its coming..will look at it today
[13:59] <mpt> xnox, so now we have three?
[14:00]  * mpt reads the mail
[14:00] <xnox> mpt: correct. this is the third incarnation
[14:06] <mpt> holy schmoly
[14:09] <doko> chrisccoulson, tvoss, Mirv: I see that qt5 is built in c++11 mode, and oxide-qt not. is this intended?
[14:10] <tvoss> doko, no idea
[14:21] <kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329794
[14:29] <kdeuser56> xnox: I mean though it has not been recommended to have btrfs for /boot, it should at least behave like any other filesystem in that function, right?
[14:35] <seb128> bregma, Saviq, tedg: logout on unity8 still doesn't work for me, using https://launchpad.net/~ci-train-ppa-service/+archive/landing-008
[14:35] <Saviq> seb128, heh
[14:35] <Saviq> seb128, can you try calling the interface directly?
[14:36] <seb128> Saviq, do you have a dbus command handy?
[14:36] <tedg> charles, ^
[14:38] <charles> +1 to Saviq's suggestion
[14:38] <Saviq> seb128, fraid not
[14:38] <seb128> charles, see my question to Saviq?
[14:38] <Saviq> 62	+ connection.registerService("com.canonical.Unity");
[14:38] <Saviq> 63	+ connection.registerObject("/com/canonical/Unity/Session", this,
[14:38] <charles> similar suggestion, can you monitor the dbus to see what i-session sends when you hit Logout
[14:39] <Saviq> and it's Logout and/or RequestLogout methods
[14:39] <seb128> shrug
[14:39] <charles> Saviq, there's no Logout
[14:39] <seb128> it's not easy to do "things" inunity8
[14:39] <seb128> unity8
[14:39] <charles> it should be RequestLogout in com.canonical.Unity.Session
[14:39] <seb128> like no d-feet
[14:39] <seb128> no alt-tab
[14:40]  * bregma misses alt-tab big time, it's on the list for 14.10
[14:40] <charles> dbus-monitor?
[14:40] <bregma> dbus-send?
[14:40] <seb128> charles, when doing what? picking logout in the indicator?
[14:41] <charles> seb128, right you could dbus-monitor to see what i-session calls
[14:41] <charles> it should be calling RequestLogout when in unity8
[15:00] <kdeuser56> xnox: what specific info should provide to help debug this problem?
[15:01] <xnox> kdeuser56: file a bug using $ ubuntu-bug ubiquity.
[15:01] <kdeuser56> xnox: I have linked you the bug already
[15:01] <xnox> kdeuser56: sorry, i have missed it.
[15:01] <kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329794
[15:02] <xnox> kdeuser56: tah.
[15:03] <xnox> kdeuser56: what do you mean suppose?! was the /boot mounted after rebooting the installed system or not?
[15:03] <kdeuser56> xnox: it was not mounted, but the system was bootable
[15:03] <xnox> kdeuser56: why are you conducting installation in qemu and transfering to hard ware later?
[15:04] <xnox> kdeuser56: that's not the only thing that will be borked.
[15:04] <kdeuser56> xnox: I installed in qemu using real storage
[15:04] <kdeuser56> xnox: there is nothing borked, it is just like I installed it on real hardware
[15:05] <kdeuser56> xnox: with the difference that it saves me time (reboot + time of install), as I can work besides the installation
[15:05] <xnox> kdeuser56: please open the bug with $ ubuntu-bug ubiquity -> that collects a whole bunch of debug logs and information from the system.
[15:06] <kdeuser56> xnox: how do I assign to an already existing report with that command?
[15:07] <kdeuser56> xnox: besides that, please do not forget that this has nothing todo with qemu, as I reproduced on real hardware with a manual install
[15:08] <kdeuser56> xnox: I will remove that qemu bit, because people always search for something that sounds unfamiliar with them and give that as a reason for it not working despite I already tested it out properly
[15:16] <xnox> kdeuser56 I'm sorry, without installer logs there is nothing i can debug
[15:26] <kdeuser56> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1329810
[15:28] <kdeuser56> xnox: but I guess nobody will need the debug information as I am sure everyone can reproduce the issue anyway
[15:35] <rbasak> mvo: around? Is it too late to ask for a change to hwe-support-status?
[15:36] <rbasak> mvo: sorry I'm late with this. I'd like to point the user to a URL, but I don't have much space to do it.
[15:36] <rbasak> mvo: so I'm wondering about a --print-url option or something like that which prints a URL to send the user to, as I've only released that it's release-specific.
[15:36] <kdeuser56> xnox: please ping me for further information. thanks very much for your cooperation and help
[15:36] <rbasak> If not, I can hardcode the URL for now, and fix it next LTS cycle.
[15:38] <michagogo> Hey ubottu, could you link me to bug 1314616?
[15:39] <michagogo> (How come that doesn't work in PM?)
[15:49] <rbasak> mvo: unping. I thought of a better way.
[15:49] <rbasak> (no changes at your end needed)
[16:48] <mdeslaur> mvo: thanks for the apt debdiffs!
[16:48] <mdeslaur> mvo: mind if I make the changelog a bit more verbose?
[19:14] <slangasek> ev: so, to circle around to the whoopsie id thing... I'm perfectly fine to have us prefer IMEI over MAC for system identifiers, according to xnox that's better for uniqueness anyway
[19:14] <slangasek> ev: however, that exacerbates the problem of finding the ID on boot, because of ofono becoming a startup dependency (and only on the phone)
[19:14] <ev> slangasek: what about padding that out with more persistent data from the system, like the serial
[19:15] <mvo> @pilot out
[19:15] <slangasek> how do you mean, "more persistent"? the IMEI is fixed
[19:15] <ev> is this not readable outside of ofono?
[19:15] <mvo> mdeslaur: not at all, ajust in any way needed
[19:15] <ev> as in IMEI + serial + manufacturer + whatever else
[19:15] <mdeslaur> mvo: thanks!
[19:15] <ev> sha512'ed
[19:15] <slangasek> we don't have any other sane interface for getting the IMEI
[19:15] <mvo> mdeslaur: thank you and sorry for the trouble :/
[19:15] <slangasek> ev: serial+manufacturer> redundant, the IMEI should already be unique
[19:16] <ev> but is it wide enough to create a decent hash?
[19:16] <ev> that was the concern before, I thought
[19:16] <slangasek> oh, was it?
[19:16] <ev> I thought? I remember someone kicking off about it. infinity and apw are the usual culprits for telling me I'm doing it wrong.
[19:16] <slangasek> infinity, apw: what is ev doing wrong
[19:16] <slangasek> ;)
[19:19] <slangasek> ev: so maybe they know something that I don't, but I can't see any way that serial+manufacturer gets you a better hash than just imei
[19:19] <ev> yeah, let's just call it a bogus claim
[19:19] <slangasek> unless the concern is that someone is going to create a rainbow table of all IMEIs...
[19:19] <ev> heh
[19:20] <ev> so I'm happy for caching to a file, so long as the aim is still to have something that's stable across reinstalls. I think we deal with the problem of not having enough persistent data to work with by marking those as obvious fails
[19:20] <ev> and then tracking the size of that bucket of IDs
[19:20] <ev> if it's small, we waste no time on it
[19:20] <ev> if it's big, we see what we can do
[19:21] <slangasek> (IMEI = 15 digits, 3.2bits/digit, so 48 bits of space - not impossible to rainbow table that)
[19:21] <slangasek> (though not for the casual attacker)
[19:21] <slangasek> yeah, that all sounds sane to me
[19:23] <slangasek> if we do want to prefer IMEI over MAC, which in principle is better because it more directly identifies a system rather than an interface, we still need to sort out the ofono stuff
[20:06] <arges> stgraber: hi. the open-vm-tools-lts-trusty upload. that was diffed against precise1. I'm not sure what you mean by missing changelog entry?
[20:07] <stgraber> arges: right, since precise1 never hit updates, you need to also include the precise1 entry in .changes
[20:08] <stgraber> arges: anyway, lamont also sponsored it to the queue and his upload was correct, so I just accepted that one instead
[20:08] <arges> stgraber: ok thanks
[21:03] <vicTROLLA> Does anyone know where I can find an reasonably up to date package for systemtap?
[21:21] <apw> ev, slangasek, i don't think in this case it was me complaining, though it does sound like me
[21:22] <slangasek> :-)
[21:39] <infinity> slangasek: "if we do want to prefer IMEI over MAC, which in principle is better"... See, the case where you *have* an IMEI (phones, tablets, and a select few laptops with GSM cards) is also the case where replacing your NIC is almost never (except for the laptop) an option.
[21:39] <infinity> slangasek: So, I'm not sure it's really any better than the MAC. :P
[21:40] <infinity> slangasek: Trying to use things other than MACs for the PC/server case might make sense, depending on what evan wants to consider "a system", but for the "I can't take it apart anyway, so meh" phone case, any unique ID is a unique ID.
[21:40] <infinity> slangasek: And bringing ofono into it certainly does seem to complicate things.
[21:40] <slangasek> infinity: except for the case where you plug a USB ethernet adapter in, or enable networking over bluetooth, or have a virtual bridge on your superphone for VMs, or
[21:40] <infinity> slangasek: And I can't really envision Ubuntu Phone being installed on anything that has a GSM radio but not WiFi.
[21:41] <infinity> slangasek: You can ask an interface what sort of interface it is.
[21:41] <slangasek> infinity: and all of the above are "ethernet"
[21:41] <infinity> (YOu can get more specific than ethernet)
[21:41] <slangasek> $ cat /sys/class/net/virbr0/type
[21:41] <slangasek> 1
[21:41] <vicTROLLA> out of curiosity, why do you need the identifier?
[21:42] <slangasek> vicTROLLA: devices need to be uniquely identified when they submit crash reports, so that a user can find their crash reports in the database
[21:42] <infinity> slangasek: Anyhow, I tend to agree that uniqueness is far more important in the phone case, especially if people are trying to piggyback push notifications on this (which seems like a mistake to me, but whatever), so IMEI is about the only thing we're sure will be stable and unique.
[21:42] <slangasek> (given that we explicitly don't associate crash reports with any sort of identifiable account information, for privacy reasons)
[21:43] <vicTROLLA> referencing IMEI will lead to problems. I'm not fully up to date on the how/why but I do know it makes cell carriers angry
[21:43] <vicTROLLA> this is why android/ios provide a device token
[21:43] <slangasek> we're not using this as part of a security interface
[21:44] <infinity> slangasek: If you ignore the part where people have talked about using this for push...
[21:44] <slangasek> infinity: that's still just an identifier
[21:44] <infinity> slangasek: Unless these are broadcast/anonymous/insecure push (like telling people about system updates), but I'd expect most/all of those usecases to be pull.
[21:45] <slangasek> I'm sure system updates won't be pull
[21:45] <infinity> Why?  They are for nearly everyone else.
[21:46] <slangasek> no, carriers do push notifications of OS updates
[21:46] <infinity> Waking a phone up to tell someone something that the phone could have found out itself ten minutes later is poor form when that something isn't time-sensitive.
[21:46] <infinity> Do they?  Maybe I've been using Nexus devices too long, but they poll.
[21:47] <slangasek> the nexus devices don't get their update info from the carrier
[21:47] <infinity> I assumed carriers just override the poll location.
[21:47] <infinity> For non-Nexus builds.
[21:48] <slangasek> given the frequency of OS updates, it's a much better use of the network resources overall to push ;)
[21:48] <infinity> slangasek: Yeah, that's true.
[22:20] <bdmurray> pitti: I've add some more information to bug 1328180
[22:46] <ScottK> infinity:  Also, since once you start the carrier update process, the phone is useless for 10 minutes anyway, so it's actually better to find out about it at a time you didn't want to use the phone.
[23:59] <infinity> bdmurray: Have you tested the utopic gdb against any of your bad backtrace reproducers?