[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 <IP_ADDRESS> <<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?


[15:03] <jcastro> Hello everyone!
[15:03] <mbruzek> hello
[15:03] <jose> what the heck is juju?
[15:03] <jcastro> welcome to getting started with juju!
[15:03] <leftyfb> hello
[15:03] <garheade> Hello
[15:03] <kentb> hola
[15:03] <marcoceppi> o/
[15:04] <mbruzek> https://juju.ubuntu.com/docs/getting-started.html
[15:04] <kentb> yes
[15:08] <mbruzek> juju quickstart for the WIN!
[15:09] <mbruzek> If you have any questions please prefix them with QUESTION
[15:10] <mbruzek> https://juju.ubuntu.com/docs/config-local.html
[15:11] <therealmarv> https://juju.ubuntu.com/docs/config-LXC.html does not mention "juju init". Does "juju generate-config" does the same??
[15:12] <therealmarv> QUESTION https://juju.ubuntu.com/docs/config-LXC.html does not mention "juju init". Does "juju generate-config" does the same?
[15:12] <mbruzek> therealmarv, yes They are the same
[15:12] <mbruzek> init is just shorthand for that command
[15:13] <mbruzek> $ juju help generate-config
[15:13] <mbruzek> usage: juju init [options]
[15:13] <mbruzek> purpose: generate boilerplate configuration for juju environments
[15:13] <mbruzek> Jorge was giving a pro-tip to save you typing!
[15:14] <therealmarv> ok... confusing for beginners ;) thanks
[15:16]  * jose can read ok in a 360p resolution, which is default :)
[15:20] <marcoceppi> therealmarv: which makes more sense to you? juju init or juju generate-config ?
[15:20] <kentb> sudo lxc-ls?
[15:21] <kentb> oh nm I see
[15:21] <mbruzek> kentb, the --fancy switch is nice
[15:21] <therealmarv> LXC: It takes some time on local... also here... especially on precise. Trusty is faster on local.
[15:23] <kentb> mbruzek: indeed.  lots more informative :)
[15:25] <therealmarv> marcoceppi: juju init
[15:25] <marcoceppi> therealmarv: thanks for the feedback!
[15:27] <leftyfb> QUESTION: does 'juju quickstart' start up 2 completely new nodes?
[15:33] <therealmarv> QUESTION More status on precise LXC would be useful. First two times I thought Juju does not work on precise. It takes really about 5 minutes
[15:33] <jose> QUESTION: how do I deploy an specific type of instance on AWS?
[15:34] <bmullan> is there an easy way to deploy onto a Cloud (AWS, hp etc) but deploy juju-gui etc and on that Cloud deploy juju charms into lxc containers as you would in local provider??
[15:34]  * jose deploys ALL the things on jcastro's gui!
[15:34] <marcoceppi> bmullan: yes, you can deploy charms on to a cloud in LXC containers on machines in that cloud
[15:40] <leftyfb> QUESTION: so it's not really possible to deploy multiple cluster packages/services that share services (mysql, apache, etc) since each once is going to use default names (mysql)?
[15:40] <mbruzek> jose,  $ juju help constraints
[15:40] <jose> mbruzek: wanna keep that on video :) /me uses constraints daily
[15:40] <jose> for the aws free tier, they're awesome!
[15:40] <mbruzek> jose sure, we will talk about it
[15:41] <jose> :)
[15:42] <mbruzek> jose what constraints do you use to get an AWS micro?
[15:42] <jose> "cpu-power=0 mem=512M"
[15:43] <marcoceppi> jcastro: flirts with danger by doing deploy --to with two php applications
[15:43] <marcoceppi> OH GOOD, he used LXC, whew
[15:43] <jcastro> <3
[15:45] <therealmarv> QUESTION: How do I get juju pprint ? Which package is needed? Unrecognized command here
[15:46] <mbruzek> https://juju.ubuntu.com/docs/charms-constraints.html
[15:48] <marcoceppi> therealmarv: it's part of juju plugins
[15:48] <marcoceppi> therealmarv: https://github.com/juju/plugins/
[15:50] <leftyfb> QUESTION: What exactly does expose do? I there a locked down iptables ruleset in the cloud images and expose opens up ports?
[15:50] <jose> jcastro: expose mediawiki
[15:51] <mbruzek> leftyfb, I believe expose uses AWS security settings to allow access to that node from the Internet
[15:51] <marcoceppi> leftyfb: in case they run out of time, expose will open the ports the charm author has specified as required in the firewaller for the cloud provider
[15:51] <leftyfb> mbruzek: ah, it uses the cloud services rulesets. Not the local node
[15:52] <marcoceppi> leftyfb: right, so local provider and maas don't have firewallers and as such all ports are always open
[15:52] <leftyfb> marcoceppi: so with MAAS, there's no need to ever expose anything?
[15:52] <marcoceppi> leftyfb: technically, yes, there's no need to expose anything
[15:52] <leftyfb> can someone answer my 2nd question above regarding cluster packages?
[15:53] <leftyfb> QUESTION: so it's not really possible to deploy multiple cluster packages/services that share services (mysql, apache, etc) since each once is going to use default names (mysql)?
[15:53] <marcoceppi> but if you deployed openstack on maas, and use openstack as your provider for services, openstack has a firewaller (their eq of security groups) and it iwll work
[15:53] <marcoceppi> leftyfb: you can actually share the same service
[15:53] <marcoceppi> so you can have one MySQL service shared between all your services
[15:53] <marcoceppi> and each service will get its own MySLQ database and user, etc
[15:53] <marcoceppi> however, there's a limitation with bundles at the moment, where if you're deploying a bundle
[15:53] <leftyfb> marcoceppi: it errored out for jcastro when he tried to deploy hadoop cluster package after he already had mysql
[15:54] <marcoceppi> and you have a service with that name already deployed it chokes
[15:54] <marcoceppi> this is just a juju-gui/bundles issue
[15:54] <marcoceppi> if you deploy bundles from teh command line it won't have this issue and will just re-use that mysql instance
[15:56] <marcoceppi> Everyone, feel free to join #juju to continue the juju discussion!
[15:56]  * marcoceppi thanks jcastro and mbruzek for presenting!
[16:09] <tbr> moo
[17:59] <jamespage> o/
[18:00] <jcastro> hello?
[18:00] <marcoceppi> o/
[18:00] <jamespage> o/
[18:00] <jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYdk_oApTaoYDWAv5eeR9zK3n8oUHTI8sE1WL4RptTN0lOaLpQ?authuser=0&hl=en
[18:00] <jcastro> if anyone wants to hang out
[18:01]  * lazyPower pulls up the track link
[18:14] <marcoceppi> https://wiki.ubuntu.com/ServerTeam/CloudArchive/
[18:16] <sparkiegeek> did jamespage just use "lifecycle" as a verb?
[18:16] <sparkiegeek> I need my buzzword bingo card ;)
[18:18] <jose> sparkiegeek: http://ubingo.libertus.co.uk/
[18:19] <sparkiegeek> jose: fantastic!
[18:30] <jose> jcastro: I just did a quick review on reviewboard and looks good to me!
[18:31] <sparkiegeek> \o/
[18:31] <sparkiegeek> I'm addressing jose's nitpicks whilst listening to the session :)
[18:32] <jose> http://ec2-107-21-20-155.compute-1.amazonaws.com/ admin:ubuntu
[18:36] <marcoceppi> Also, https://code.launchpad.net/charms/bundles has a list of bundles
[18:37] <jcastro> https://jujucharms.com/bundle/~charmers/mongodb/5/cluster/
[18:39] <jamespage> https://code.launchpad.net/~james-page/charms/bundles/openstack-on-openstack/bundle
[18:45] <jcastro> sorry guys, plugin crash
[19:03] <mbruzek> https://juju.ubuntu.com/docs/troubleshooting-local.html
[19:05] <marcoceppi> http://www.youtube.com/watch?v=UuqFaTASBTE&list=UUm7OifwnZoMCChidCJZQruQ
[19:05] <jcastro> https://www.youtube.com/watch?v=UuqFaTASBTE
[19:06] <marcoceppi> NINJA'D!!!!
[19:06] <marcoceppi> HEEEYA
[19:08] <marcoceppi> http://pad.ubuntu.com/uos-1406-charm-schools-and-other-events
[19:09] <jose> jcastro: ^
[19:09] <jose> jcastro: summit looks like it's broken
[19:10]  * jose hates delay
[19:26] <jose> jcastro: can you host that charm school tomorrow at UoA?
[19:26] <jcastro> yes I would prefer that actually!
[19:26] <jose> I can schedule that and set you up


[07:03] <ara> morning all :)
[09:02] <davmor2> ara: morning Totem is mostly written up.  I was going to add dvd playback but it turned out to be a pain
[09:03] <ara> davmor2: cool, thanks :)
[09:04] <davmor2> I'll do rhythmbox this afternoon.  If you get chance though could you add the slide show feature please I needed to lose my install and it's being a pain again :(
[09:05] <ara> davmor2: ok, I'll do it, don't worry
[09:05] <ara> davmor2: thanks !
[09:05] <davmor2> ara: ta
[12:20]  * davmor2 ->away
[14:48] <davmor2> Morning fader how are things states side?
[14:50] <fader> davmor2: Sunny and warm, for once. :)  How are things on your side of the pond?
[14:51] <davmor2> fader: Dull and grey nothing new there then :)
[14:51] <fader> davmor2: If it helps, "warm" is a relative term in Boston in February ;)
[14:54] <davmor2> Oh about 4.6 °
[14:54] <davmor2> C
[14:56] <davmor2> fader: So are you at lexington with cgregan?
[14:57]  * cgregan 's ears perk up
[14:57] <fader> davmor2: No, I'm at home... I'm about a 45 minute drive from lexington, so the weather is pretty similar.
[14:59] <davmor2> fader: Fair enough just wondered.  Don't worry cgregan talking about you not to you ;)
[14:59] <davmor2> cgregan: Hello by the way :)
[14:59] <fader> Hey, the only thing worse than being talked about is not being talked about, right?
[14:59] <cgregan> davmor2: :-) top of the morning
[15:00] <davmor2> Chris Gregan: It's mid afternoon Dude really I'd of thought you'd of got this international stuff by now :)
[16:32] <kirkland> cr3: schwuk: ping, regarding checkbox
[16:33] <robin_rowe> how do i install the latest dev version of ubuntu for testing?
[16:34] <charlie-tca> !daily
[16:34] <ubot4> Daily builds of the CD images of the current development version of Ubuntu are available at http://cdimage.ubuntu.com/daily/current/ and http://cdimage.ubuntu.com/daily-live/current/
[16:35] <robin_rowe> how do i upgrade existing?
[16:35] <charlie-tca> update-manager -d  in a terminal. But, you should read the release notes, too
[16:35] <schwuk> kirkland: hi
[16:36] <charlie-tca> robin_rowe: http://www.ubuntu.com/testing/jaunty/alpha5
[16:36] <kirkland> schwuk: hey dave, can you help answer this question:
[16:36] <cr3_> kirkland: pong, what's up?
[16:36] <robin_rowe> where are release notes?
[16:37] <kirkland> schwuk: cr3_: the background is this ...  http://blog.dustinkirkland.com/2009/02/ubuntu-server-suspendhibernateresume.html
[16:37] <kirkland> schwuk: cr3_: see the comments
[16:37] <kirkland> schwuk: cr3_: a poster asked if we were open sourcing our testing effort
[16:37] <kirkland> schwuk: cr3_: i said, "yes, in checkbox"
[16:38] <cr3_> kirkland: that's cool, thanks!
[16:38] <kirkland> schwuk: cr3_: the question came back:
[16:38] <kirkland> "Cool a comprehensive testing effort.
[16:38] <kirkland> Launchpad is going to collect the test results?
[16:38] <kirkland> Do you have the interaction defined on how would an upstream project developer will be able to pull relevant checkbox results out of lp?"
[16:38] <kirkland> schwuk: cr3_: can one of you guys field that?
[16:38] <cr3_> kirkland: there's a LP API for the hardware database
[16:38] <schwuk> kirkland: right now the only access to the LP HW data is through the API.
[16:39] <kirkland> cr3_: schwuk: is that API documented anywhere?
[16:39] <robin_rowe> where can i find latest release notes?
[16:40] <cr3_> kirkland: https://edge.launchpad.net/+apidoc/ and https://help.launchpad.net/API/
[16:41] <schwuk> kirkland: however it seems that LP is not exposing test results yet, just submissions and hardware.
[16:41] <charlie-tca> robin_rowe: http://www.ubuntu.com/testing/jaunty/alpha5
[16:41] <kirkland> schwuk: ?
[16:41] <schwuk> kirkland: bjorn and abel on the LP team are the ones to bug about the API.
[16:41] <cr3_> there are also sample scripts: lp:~adeuring/launchpadlib/hwdb-examples
[16:41] <kirkland> cr3_: schwuk: do either of you have a google id?  would you mind posting a response to that comment explaining that the API exists, etc?
[16:42] <schwuk> kirkland: sure
[16:42] <kirkland> schwuk: rock on, thanks dave
[16:43] <cr3_> I guess the "hwdb" in launchpad has taken its name quite literally for now, only exposing hardware :)
[21:00] <TheRedFox> Hello all
[21:17] <Guest54113> goodbye for now take care people
[21:22] <panattan> good night.


[00:01] <styol> xnox: and then yeah, doesn't work on boot
[00:02] <xnox> styol: i meant make the job file (a.conf) minimal, start with just e.g. "script \n initctl emit prepared \n end script"
[00:02] <xnox> styol: and log every line somewhere.
[00:03] <styol> will do now
[00:03] <xnox> and bit by bit increase it. check the environment, upstart cleanses the environment, thus no typical variables are available. re-declare them.
[00:03] <xnox> styol: e.g. $HOME is _not_ set.
[00:04] <styol> xnox: that is one thing I came across with b.conf, decided to just provide the otherwise used environment variable as an argument
[00:07] <xnox> initctl emit prepared FOO=bar
[00:07] <xnox> can pass variables.
[00:09] <styol> xnox: ah right, but the wrapper script being ran by initctl was relying on an environment variable set like so `echo "export AQUA_CONFIG=$CONFIG" >> "/etc/profile.d/aqua.sh"`
[00:10] <styol> seems it is indeed not available, so i'll just have to dynamically create the upstart job with the config file specified as part of the command
[00:12] <xnox> styol: i think it's supported to have .override files. e.g. keep you main job as is, but e.g. have "env FOO=bar \n env FOO" in a.override
[00:12] <styol> xnox: crapola, it must be the NAS mounting because that is the bare minimum.. trying without it now, probably will work
[00:12] <styol> interesting! that would be nice
[00:12] <styol> will try that indeed
[00:13] <xnox> styol: this way you can do e.g. $ start a FOO=different, and FOO will be overriden with value "different" _and_ available inside all stanzas in a, _and_ due to export be part of events emitted from within it.
[00:13] <xnox>  "env FOO=bar \n export FOO" in a.override (that is)
[00:14] <styol> xnox: but without providing the argument it should take on bar?
[00:14] <xnox> check man 5 init, to see if .override file is support, env and export keys.
[00:14] <xnox> styol: correct.
[00:14] <styol> delicieus, will check as soon as it done rebooting
[00:14] <styol> also delicious
[00:14] <styol> i no can englishes today
[00:16] <styol> xnox: nutty, never reaches the emitted event http://pastie.org/9009721
[00:17] <xnox> styol: try "initctl emit --no-wait prepared"
[00:17] <styol> en route
[00:17] <xnox>        --no-wait
[00:17] <xnox>               Applies to the start, stop, restart and emit commands.
[00:17] <xnox>               Normally  initctl  will  wait  for  the  command  to finish before
[00:17] <xnox>               returning.
[00:18] <xnox>               For the emit  command,  finishing  means  that  all  of  the  jobs
[00:18] <xnox>               affected  by the event are running (or have finished for tasks) or
[00:18] <xnox>               have been fully stopped.
[00:18] <xnox> thus e.g. if prepared event blocks then your job just gets stuck there.
[00:19] <xnox> e.g. if there is a job "start on prepared and anotherevent" then you are blocked waiting for "anotherevent" which might never happen.
[00:19] <xnox> good night.
[00:19] <styol> xnox: thank you so so so very much
[00:19] <styol> it is very much appreciated
[00:19] <styol> sleep well <3
[02:12] <styol> xnox: so, I ended up moving the NAS mounting to /etc/fstab where it probably should be, and then within the upstart script I am using while and sleep to perpetually check for the existence of the expected file, which does seem to be working. Many thanks again.
[11:54] <Trevinho> Hey, one question
[11:54] <Trevinho> is the dbus service activation (https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html) still working (also in a session)?
[11:54] <Trevinho> as I can't find a service that seems to use it
[12:02] <xnox> Trevinho: in recent ubuntu that has been disabled, there are plans to get that back, but it's not back in yet.
[12:03] <Trevinho> xnox: mh I se... so a workaround might be to use upstart init something as the exec for that dbus service or that won't work?
[12:05] <xnox> Trevinho: there are plenty of system jobs that start a daemon which happens to export itself on dbus. So yeah - start on started dbus \n exec foobard
[12:06] <xnox> Trevinho: recent upstarts have upstart-dbus-bridge such that events are generated when things appear/disappear from dbus and one can start/stop jobs according to those events. but that's reactive.
[12:10] <Trevinho> xnox: well, the fact is that I want the service to start not on dbus, but on name activation
[12:11] <Trevinho> xnox: so say you can org.foo.bar then the service starts, handled by upstart, so that I can also stop it
[12:11] <xnox> Trevinho: that's not currently handled.
[12:12] <xnox> Trevinho: it used to be, and there are plans to introduce it.
[12:12] <xnox> Trevinho: do it manually =)
[12:12] <Trevinho> xnox: yes, manually... and to do to do that, can I just add into the dbus .service file an exec= string such as initctl start my-service or that won't work?
[12:13] <xnox> Trevinho: you can do that.
[12:14] <Trevinho> xnox: ok
[17:51] <styol> Hmm.. any ideas why post-stop might be running on `start on runlevel [2345]? There is also `stop on runlevel [06]`, but from what I understand those run levels should be for halt and reboot
[23:27] <xnox> styol: post-stop is run as part of the job life-cycle, e.g. after the main process has terminated (because it crashed, exited normally, or the job is being stopped)
[23:27] <xnox> styol: start on / stop on -> are simply the event trigger that cause changes to the job life-cycle: e.g. do whatever needs to happen to get the job from dormant to running; or from running to dormant again
[23:28] <styol> xnox: aha, that would explain it since it is somewhat of a wrapper script. Crapola. That being the case, a normal script definition doesn't work for stops which is what post-stop was supposed to solve since it calls the same wrapper script called to start
[23:28] <xnox> styol: post-stop is always executed when the job is stopped, irregardless as to /why/ the job is stopping.
[23:28] <styol> totally makes sense
[23:29] <styol> *since it calls the same wrapper script to stop that was used to start
[23:29] <xnox> styol: you may be need / want "post-start" and "post-stop" scripts.
[23:30] <xnox> styol: and read the cookbook to see which states the job go through (normal and task jobs) and which snippets of the job are executed when.
[23:31] <styol> xnox: gotcha, post-start won't apply to the stop cycle which makes it work like desired, correct?
[23:32] <styol> start is indeed script end script and therein lies the problem that post-start should solve.. awesome idea


[01:10] <charlie-tca> All of xubuntu is done. everything passes on hardware
[01:11] <charlie-tca> good night.
[13:22] <brendand> gema - do you reckon it would be good to have an 'introductory' email for people like besi, who 'announce' themselves on the list?
[13:23] <gema> brendand: what do you mean?
[13:23] <brendand> gema - i could respond with a few suggestions for him, but it would be good to have a uniform response which we can improve upon
[13:23] <brendand> gema - something like:
[13:23] <brendand> * irc channels
[13:23] <brendand> * wiki resources
[13:23] <brendand> * current activities (e.g. if alpa testing is running atm)
[13:24] <brendand> just a suggestion
[13:24] <gema> brendand: by all means, have a go at writing it :) our wiki is poor at the moment, make that clear, though, that one of the tasks in our list is to improve it :D
[13:25] <gema> brendand: I am relying on whoever jono hires to be the QA community coordinator to start putting those things together :D
[13:30] <gema> brendand: looks really good, like a small starter's guide, thanks
[13:32] <brendand> gema - no problem. it would be good to keep it somewhere and update it with extra stuff
[13:32] <brendand> gema - as i recall from my Symbian days, mailman supports a 'introduction email'. who controls the ubuntu-qa list?
[13:33] <gema> brendand: no idea
[13:33] <brendand> gema - i bet it's hggdh
[13:33] <gema> brendand: we can ask him when he comes online
[13:34] <brendand> jibel - i know you're a very busy man at the moment, but do you have admin access to ubuntu-qa mailing list?
[13:41] <jibel> brendand, yes why  ?
[13:42] <brendand> jibel - ^
[13:43] <brendand> jibel - i wanted to know if there's an 'introduction mail' option in the mailman interface
[13:43]  * jibel looking
[13:45] <jibel> hggdh, can you help, I lost access again
[13:51] <jibel> brendand, sorry I eat the password again, we'll have to wait for Sir Carlos
[13:54] <hggdh> brendand, jibel: I have never seen an 'introduction email', or similar, in mailman
[13:54] <hggdh> jibel: just a sec, and I will get the passphrase
[14:05] <jibel> brendand, gema mailman has an autoresponder feature but nothing powerful
[14:06] <brendand> jibel - ok then
[14:21] <brendand> has anyone seen that the 'camera' function of the profile picture chooser doesn't work if the installer is launched in the live session? maybe it's just my hardware
[16:49] <cr3> nerochiaro: welcome to #ubuntu-testing! :)
[16:49] <nerochiaro> cr3: :)
[16:50] <cr3> salem_: you too, I didn't recognize your nick :)
[16:50] <roadmr> hey folks!
[16:51] <salem_> cr3, hey, thanks! sorry about the conference. My internet connection is for some reason loosing some packages, so I couldn't hear you very well.
[16:52] <nerochiaro> salem_: ah, different nick on here :)
[16:52] <nerochiaro> salem_: you're tiagosh on canonical's servers
[16:52] <cr3> salem_: that's alright, roadmr did most of the talking so I'm not offended at all :)
[16:52] <roadmr> hehe no problem
[16:52] <salem_> nerochiaro, yes, this is an old nick from freenode. i think tiagosh is already taken here
[16:53] <cr3> roadmr: should one of us follow up by email about the next steps, just to keep a paper trail to which we can point... and laugh, of course
[16:53] <roadmr> cr3: sure, I'm working on it right now :)
[16:53] <cr3> salem_: if you decide to pick a more permanent nick on freenode, you might like to register it with nickserv to prevent the same thing from happening again
[16:53] <nerochiaro> and keep everyone of us in the meeting in CC
[16:56] <nerochiaro> so roadmr it looks like salem_ didn't get hear most of the meeting. i briefly recapped it for you, but it'd be great if you guys can go ahead and discuss what's missing here
[16:57] <salem_> nerochiaro, ok, thanks
[16:57] <roadmr> nerochiaro, salem_ ok
[16:59] <salem_> I am taking a look at the mockups and check if it is doable with the current code layout
[17:02] <roadmr> salem_: it's just a general idea, the mockups are based on ubuntu-one-client
[17:03] <roadmr> salem_: some of the stuff there is no longer needed, for instance, the "only system information" checkbox is probably no longer needed as it generates non-useful submissions
[17:03] <cr3> roadmr: does the backend support the concepts illustrated in the mockups yet?
[17:03] <roadmr> salem_: also the document I posted (let me know if you don't have it) has some use cases we'd like the UI to cover, these are not obvious from looking at the mockups
[17:04] <roadmr> cr3: there are some that aren't supported :( like the global progress indicator
[17:04] <roadmr> cr3: some are just setting properties (like how we preseed the launchpad email account)
[17:05] <salem_> roadmr, I dont have it yet I guess. can you send me?
[17:05] <cr3> roadmr: I'd make sure to clarify what can be implemented now compared to what might be blocked by future implementation to make life easier on salem_
[17:05] <roadmr> cr3: and some may need both backend and UI support (like the submission saving feature)
[17:05] <roadmr> salem_: no problem: https://docs.google.com/a/canonical.com/document/d/1gr8NiC_d2E5kuh1NVCdwIXLnm3HQZiwrl3nbYDLSCSg/edit?authkey=CLC2698I&hl=en_US
[17:05] <cr3> roadmr: I don't think the UI interface supports setting properties either and it would be sad if each UI set properties its own way
[17:06] <cr3> roadmr: otherwise, if I set my launchpad email in the GTK interface I probably won't get it in the Qt inteface... unless the backend provides that functionality through the user interface layer
[17:06] <roadmr> cr3: ok so maybe we will have to extend the interface :(
[17:07] <roadmr> cr3: how does the current gtk interface handle e.g. setting the launchpad id?
[17:07] <roadmr> cr3: I guess I could go look at the code :)
[17:07] <cr3> roadmr: we will, but my concern is to avoid asking salem to implement features that are currently incomplete which makes development rather difficult
[17:07] <roadmr> cr3: well yep, you're right about that...
[17:08] <cr3> roadmr: would a reasonable first step to get a Qt interface at par with the current GTK interface, or do you think that would be a waste of time?
[17:08] <cr3> err, would it be a reasonable...
[17:09] <roadmr> cr3: well it depends, if it'll take salem_ a month it may not be worth it, we could ask him I guess :)
[17:09] <roadmr> cr3: it could be useful for him to get acquainted with how to interface with checkbox
[17:10] <cr3> roadmr: for the launchpad email, the user interface layer just has a show_entry method which takes text and a default value as parameter and returns the entered launchpad email
[17:10] <cr3> roadmr: in other words, it's a generic method for prompting the user for text, not specific to the launchpad email at all
[17:11] <cr3> roadmr: exactly, I think just getting at par would be a nice acquaintance step
[17:11] <cr3> salem_: have you had an opportunity to look at checkbox a bit, at checkbox_gtk/gtk_interface.py in particular?
[17:12] <roadmr> salem_: does this sound reasonable to you? come up with a feature-equivalent UI of the current checkbox-gtk but using Qt?
[17:12] <salem_> cr3, yes, I created a qtinterface already
[17:12] <salem_> cr3, dummy, but seems to work
[17:12] <roadmr> salem_: warning: the current gtk_interface.py uses a dialog as its main window, and I think we should change that, as the dialog has been a bit troublesome as of late :) we should use a window as the top-level element
[17:12] <cr3> salem_: awesome, would you mind pushing those, perhaps to lp:~tiagosh/checkbox/qt
[17:13] <salem_> cr3, implemented just the show_info() and seemed to work
[17:13] <roadmr> yay, salem_  is the man!
[17:13] <cr3> salem_: how do you feel about the design so far, straightforward enough to work on?
[17:13] <salem_> roadmr, haha, no, it was just a prototype, not the whole implementation :)
[17:15] <cr3> salem_: once you implement all the show_* methods, the interface should be feature complete
[17:15] <salem_> cr3, well, my only concern is that, if I understood correctly, the backend controls the UI, and not the other way round, so depending on the new interface, we would need to change some bits.
[17:16] <cr3> salem_: very perceptive but I have to admit I'm not sure how the new interface will work, ie whether the backend will continue driving or whether the interface will take over
[17:16] <salem_> cr3, sure, I can push to a branch
[17:16] <cr3> salem_: for now, I think it would be safest to assume the backend is driving until we know for sure what will happen next
[17:16] <cr3> roadmr: ^^^ sound reasonable to you?
[17:17] <roadmr> cr3: sure
[17:18] <cr3> salem_: by the way, I came up with this separation between backend and frontend specifically to support multiple frameworks, originally gtk and command line but I was also thinking about qt back then.
[17:18] <salem_> cr3, I can implement the full qt interface, no problem. but if the goal is to have a different concept of UI, maybe all could use the time to define the new UI, and check what needs to be changed. But this is up to you.
[17:19] <cr3> salem_: I tried really hard to inspire myself from other projects which might have the same requirements but I couldn't find any, so I came up with my own design for separating the backend and frontend.
[17:19] <cr3> salem_: if you happen to know of a project that does a good job of this kind of separation, please let me know because I would certainly like to learn from other people's experience
[17:20] <roadmr> cr3: maybe coming up with a way to let the UIs set config values would cover most of the extra functionality we need? that may not be so intrusive to the current contract
[17:20] <salem_> cr3, yes, I must say this is a nice UI abstraction idea, but if the UI is going to control the data flow, and not the opposite, maybe we would need to do some adjustments.
[17:20] <cr3> roadmr: indeed, this is something I can easily see being specific to graphical interfaces and the command line interface would keep working, modulo setting properties which are typically done in configuration files anyways
[17:21] <cr3> salem_: we'll have to see, but maybe we can just add one method for the frontend to call the backend for setting properties as suggested by roadmr, and that might cover everything planned for 12.04
[17:21] <skaet> Alpha 1 is released now.   Just wanted to say thank you to everyone who's helped with testing it out and getting it ready to release.  :)
[17:22] <salem_> cr3, are you still going to need many UI's? or the idea is to drop the others UI abstractions (gtk, urwid)?
[17:22] <cr3> salem_: in other words, it is most likely that the work we plan to invest in the Qt interface will remain as such in the foreseeable future
[17:22] <cr3> salem_: unless we can find one UI to rule them all, the plan is to keep the other ones
[17:22] <roadmr> cr3: other than that, exposing the job store (for the progress bar), and some way of handling submission saving/renaming, and submitting an existing .xml
[17:23] <cr3> salem_: I've been toying with the idea of using the SDL with pygame as a UI to rule them all, but that hasn't been received very well by some :)
[17:23]  * roadmr likes the pygame idea
[17:23] <cr3> roadmr: those are likely to be implemented as methods *in addition to* the existing UI methods, which might result in minor changes
[17:24] <salem_> cr3, got it, so in that case, the current layout is good. We just need maybe to extend/modify some methods of the api, and adjust the others frontends accordingly
[17:24] <cr3> roadmr: please consider changing the current design between the backend and frontend, I don't necessarily want to force the current design by making it painful to move forward :(
[17:25] <salem_> the best way to do that is to implement a passive backend, that responds to UI commands
[17:25] <roadmr> cr3: sure, if some feature needs interface changes I think it's ok
[17:25] <cr3> salem_: exactly, and this is likely to happen incrementally feature by feature. for example, we'll eventually add a feature to save the output in a specific location, so we'll then have to extend/modify the interfaces accordingly
[17:27] <cr3> salem_: agreed, so I suspect we'll have a passive interface to enable the frontend to drive the backend and keep the current active interface, for lack of a better word, to continue having the backend drive the workflow of the frontend
[17:28] <salem_> roadmr, how complex is the backend? what are the jobs the backend is in charge of? running the selected scripts, get the output of each one? what else?
[17:30] <cr3> salem_: the backend does a fair amount of work
[17:30] <roadmr> salem_: most of the behavior is implemented through plugins that register methods to be fired on events
[17:31] <cr3> roadmr: I was thinking that the frontend could interact with the backend by firing its own events, which seems to work well because both graphical interface and the backend are event driven
[17:32] <roadmr> cr3: hmm that might work, so we'd need to pass the manager thingy to the UI as well?
[17:33] <roadmr> salem_: so most of the work is done by the plugins: collecting information about the system, building the list of jobs to execute, ordering them and resolving dependencies
[17:33] <cr3> roadmr: very astute, which is not somethign I'm very comfortable doing because it's such a high level object, but certainly feasible
[17:34] <roadmr> salem_: actually running the jobs depending on which plugin they specify to use
[17:34] <roadmr> salem_: and several plugins take care of building the final report and submitting that info to (potentially several) places
[17:34] <cr3> roadmr: I might be more comfortable passing a callback method, which might seem more native to event driven systems
[17:34] <roadmr> cr3: oh that'd be nicer!
[17:34] <cr3> roadmr: the callback would obviously point to the manager's fire method
[17:34] <salem_> roadmr, hm, ok, but can this be triggered by the UI, instead of the backend?
[17:35] <cr3> err, manager's reactor's fire method :)
[17:35] <roadmr> salem_: potentially with what cr3 is suggesting, which would require some changes to the UI methods
[17:36] <salem_> roadmr, yes, would requires some work, but in the end I think the layout will be flexible enough to build a nice UI
[17:36] <roadmr> salem_: cr3 has a nice graph of how messages travel around checkbox, but we fear it may drive you insane :(
[17:37] <salem_> roadmr, no problem, I am interested to see this graph
[17:37] <cr3> salem_: these are the messages exchanged between checkbox plugins: http://people.canonical.com/~cr3/checkbox-message-graph.png
[17:38] <cr3> salem_: you can identify where the user interface is being called because those messange handler methods are consistently prefixed with prompt_*
[17:47] <roadmr> argh, I don't see anything pyqt-related in main :(
[17:47] <salem_> roadmr, python-qt4 ?
[17:48] <salem_> apt-cache says it is in main
[17:48] <roadmr> salem_: I don't see it in Precise's manifest from the CD, but I may be doing something wrong :)
[17:50] <cr3> roadmr: python-qt4 may or may not be on the CD which is probably not a huge deal for now, as long as we at least depend on packages from main: http://archive.ubuntu.com/ubuntu/pool/main/p/python-qt4/
[17:50] <roadmr> cr3: ok cool :)
[17:51]  * roadmr apologizes heh
[17:51] <cr3> roadmr: I find the shipit use case of getting a cool ubuntu cd and trying it in a store far more likely than someone downloading and burning a kubuntu image to try it in a store
[17:52] <roadmr> oh yes, kubuntu
[17:52] <cr3> roadmr: however, with friendly.ubuntu.com, I find it equally likely for someone on either ubuntu or kubuntu to want to try checkbox where instructions should be updated accordingly
[17:52] <roadmr> cr3: yep
[17:53] <cr3> roadmr: hm, if you were looking at germinate for the ubuntu cd, it might be possible that python-qt4 is on the kubuntu cd which would just be a bonus :)
[17:53] <roadmr> cr3: I'm still unsure on what to do about the gstreamer dep on kubuntu, maybe some kubuntuer can tell us how it's done on their side
[17:54] <cr3> roadmr: if the tests are optional, we can either have those tests require gstreamer or, if the tests are mandatory, we could consider rewriting them to have a lower level dependency like pulse
[17:55] <roadmr> cr3: they're mandatory, maybe we could have two sets of tests: ones depending on gstreamer and others depending on whatever kde uses
[17:55] <cr3> roadmr: either way, I don't think it would be a huge undertaking
[17:55] <cr3> roadmr: that would work too
[17:55] <roadmr> cr3: jedimike can surely frob things so that it considers either set of tests as valid
[17:55] <cr3> roadmr: however, I was wondering what would happen if both requires are met; you'd get two sets of audio tests :)
[17:55] <roadmr> cr3: yep, so I'll stop worrying too much about it
[17:55] <roadmr> cr3: but that would require some wacko having gstreamer on kubuntu
[17:56] <cr3> roadmr: if our assumptions can be broken, they will
[17:56] <roadmr> cr3: well it's ok, what would be baffling is if one set of tests passed *and* the other failed :)
[17:57] <cr3> roadmr: that's when I wished we had electrocuting keyboards so, when someone answers tests inconsistently: zap!
[17:59] <brendand> cr3 - actually i've always thought about checkbox being able to specify more complicated logic for 'requires'
[17:59] <brendand> cr3 - errr, i mean depends
[17:59] <brendand> cr3 - such as 'wireless_after_suspend' depends: suspend_advanced or suspend_advanced_auto
[18:00] <brendand> cr3 - so audio_gstreamer could depends: not audio_pulseaudio :)
[18:00] <roadmr> that'd rock :)
[18:00] <brendand> and vice versa
[18:01] <cr3> brendand: agreed, I've also seen use cases for depending on something to fail rather than implicitly something to pass
[18:01] <cr3> brendand: oh wait, that's what you meant by "not audio_pulseaudio", nevermind :)
[18:02] <brendand> cr3 - well, depends means ran and passed right?
[18:02] <brendand> cr3 - or just ran?
[18:02] <cr3> brendand: passed
[18:02] <brendand> cr3 - that's what i thought
[18:02] <brendand> cr3 - that would also be useful, but maybe harder to specify.
[18:03] <cr3> brendand: the original motivation is the build a dependency tree which would spare the user from answering redundant questions, like to test the number of packets that can be transfered over the network when the network test failed in the first place
[18:03] <brendand> depends: suspend_advanced:fail
[18:03]  * brendand needs to become au fait with the depends code
[18:04] <brendand> it's a little tricksy. didn't neimeyer write it? or am i thinking of something else?
[18:04] <cr3> the distinction seems to be that where we used to want a dependency tree, we now seem to want a decision tree
[18:04] <roadmr> hmm
[18:05] <cr3> brendand: sadly, I wrote the dependency code but I'd love to blame niemeyer for it :)
[18:05] <brendand> cr3 - hey, he's not on this channel - so feel free!
[18:06] <roadmr> heheheh
[18:06] <brendand> cr3 - do you reckon it would be a big change from how things work at the moment?
[18:06] <alourie> hello
[18:07] <cr3> brendand: it would be a much needed rewrite, so I'd be receptive
[18:07]  * cr3 steps out for lunch
[18:07] <alourie> what is this splash of users on QA list lately? Was there any event that I missed where QA was introduced?...
[18:07] <alourie> s/introduced/PR-ed/
[18:08] <brendand> alourie - i only just joined ubuntu-qa (not sure why i wasn't on it before, considering that ubuntu QA is my job :P)
[18:08] <brendand> alourie - is it abnormal?
[18:08] <alourie> brendand: well
[18:08] <alourie> let me just say that I haven't seen "hello" letters for about a year?
[18:09] <brendand> gema - did we do anything to push the ubuntu-qa list recently?
[18:09] <alourie> and now there have been, how many? about 5 this week?
[18:09] <gema> brendand: we changed the format of the meeting and sent the minutes
[18:10] <gema> alourie: it is great, isn't it? we are taking off
[18:10] <gema> alourie: a lot of exciting work to do
[18:10] <alourie> gema: bring it on!!
[18:10] <salem_> cr3, ok, so, for now I should ignore those mockups and implement just a qtinterface just like the gtk one, right?
[18:10] <gema> alourie: I am on it, I need three days to write it all down in an email!
[18:12] <alourie> sure
[18:12] <alourie> gema: maybe you should not put everything in one mail? split some?
[18:12] <gema> alourie: and I think we are going to have a QA community coordinator soon too, that will bring joy to the list
[18:13] <gema> alourie: maybe I will create a wiki and point to it from the mail, that makes more sense
[18:13] <alourie> gema: we know we're going to have one
[18:13] <gema> alourie: cool :)
[18:13] <alourie> yea, wiki would be better. But once again, not everything on one page
[18:14] <gema> alourie: ok, I will see how it comes along, I need one place to dump all the ideas and then we can flesh them out as required
[18:15] <alourie> yea, split to parts
[19:38] <cr3> _salem: sorry for the delayed response, I stepped out for lunch. to answer your question: right, just ignore the mockups for now