[00:51] <tripelb> Help, I got a bad install and got stuck in grub recovery. Can't get to windows. Maybe I did something wrong in partition, I gave it one partition, figured swap and whatever would be carved out of the 20G.
[00:52] <tripelb> Right now I want to do one small thing in windows.
[00:54] <tripelb> Oops wrong room
[07:03] <jibel> good morning
[07:15] <pitti> bonjour jibel, comment vas-tu?
[07:16] <jibel> pitti, hey, i'm fine but really tired, 3rd day of insomnia :(
[07:21] <pitti> jibel: ugh, 3 days? that sounds pretty far away from "fine"
[07:52] <dholbach> good morning
[12:12] <zyga> retoaded: ping
[12:13] <zyga> retoaded: could you fix permissions so that I can rename (apparently that needs delate, silly jenkins there)
[12:13] <zyga> retoaded: and add support for git if you don't mind (probably requires a jenkins plugin, not sure really)
[13:12] <retoaded> zyga, your permissions have been modified and git (and the git plugin for git) has been installed
[13:15] <zyga> retoaded: thanks a lot!
[13:16] <retoaded> zyga, np
[13:21] <zyga> retoaded: I have issues with git clones, is the lab firewalled in a way that simple git clone from git:// url won't work?
[13:22] <retoaded> zyga, it depends upon what the URL is; most are blocked (and I have no control over that).
[13:23] <retoaded> If you need/require access to a specific URL or set of URLs you will need to submit an RT to IS to get that opened up.
[13:23] <zyga> retoaded: are there any 'safe' things, like http/https
[13:23] <retoaded> Unfortunately, the access from the lab to the world is severely limited.
[13:25] <retoaded> We are working on getting a subnet from the lab connected to an unfettered link to the world but that has not been fully connected yet (it's in IS hands atm).
[13:29] <zyga> retoaded: could you configure git plugin to work: currently it fails on stuff like: http://10.97.5.22:8080/job/plainbox-unit-tests/6/console
[13:29] <zyga> retoaded: I have no idea why jenkins wants to tag things there
[13:30] <retoaded> zyga, let me see what I can do
[13:31] <zyga> thanks, IIRC it's in the plugin config page
[13:37] <zyga> retoaded: could you please look at http://10.97.5.22:8080/job/plainbox-unit-tests/7/label=precise/console
[13:38] <zyga> retoaded: it seems that slaves don't have the required packages installed, I got similar errors for bzr
[13:38] <zyga> retoaded: how can I install bzr/git on slaves?
[13:38] <retoaded> zyga, the git configuration consists of telling jenkins where the git executable it located. The user jenkins needed (it appears) to have run 'git config'; a generic setup has been added. Also added the links to the proxy server that may or may not allow access to some of the http/https sites you require access to.
[13:38] <retoaded> zyga, I can handle that for you; give me a few minutes.
[13:40] <zyga> retoaded: thanks
[13:48] <zyga> retoaded: that seem to have fixed it, thanks!
[17:51] <balloons> alesage, ping
[17:51] <alesage> balloons, hallo
[17:51] <balloons> :-)
[17:52] <SergioMeneses> morning!
[18:02] <balloons> hello SergioMeneses
[18:03] <SergioMeneses> hey hey balloons how are you?
[18:03] <balloons> good, yourself?
[18:03] <SergioMeneses> balloons, pretty well! I have good internet connection now :)
[18:04] <SergioMeneses> so Im working on some loco-bugs
[18:05] <cprofitt> hello all
[18:06] <SergioMeneses> cprofitt, hi!
[18:07] <balloons> cprofitt, the UF stuff is exciting ;-) getting some feedback on the doodle poll?
[18:08] <cprofitt> balloons: yes... I am getting feedback
[18:08] <cprofitt> it seems half of the interested parties are GMT+1
[18:08] <cprofitt> and the other half are GMT-5
[18:08] <cprofitt> so we have a 6 hour swing
[18:09] <balloons> ah.. well not so bad.. timezones are at least consistent
[18:09] <cprofitt> we also have bugs getting filed
[18:09] <cprofitt> yeah
[18:09] <cprofitt> question -- is there an online tool for doing a GUI mockup?
[18:09] <balloons> I've used.. oh what is it
[18:10] <balloons> http://www.balsamiq.com/products/mockups
[18:10] <cprofitt> some folks have made suggestions for improvement, but I think we need to have everyone be able to visualize them
[18:10] <cprofitt> I am thinking we will want to have a few UDS sessions this spring
[18:10] <balloons> that site has a webapp which is nice
[18:11] <balloons> the desktop app works on linux, and they give a free license for anyone doing open source work
[18:11] <balloons> I'm sure there are others.. google is your friend there ;-)
[18:11] <cprofitt> nice
[18:12] <balloons> http://support.balsamiq.com/customer/portal/articles/105924
[18:13] <cprofitt> thanks... will look in to that more after work today
[18:13] <balloons> np
[18:14] <cprofitt> mike is excited to be working on this stuff again
[18:14] <cprofitt> so there is a great deal of excitement
[18:15] <balloons> :-)
[18:32] <SergioMeneses> lunch time
[18:52] <cprofitt> balloons: does myBalsamic also offer free options?
[19:05] <balloons> cprofitt, what do you mean/
[19:05] <balloons> they give open source licenses for myBalsamic as well, but there's a few requirements
[19:06] <balloons> you can use the web app without worry
[19:09] <cprofitt> cool... I was looking at myBalsamic because of the team based nature of it
[19:13] <balloons> ahh.. i've not used it
[19:43] <balloons> hello primes2h letozaf_  :-)
[19:43] <letozaf_> Hi balloons :)
[19:43] <primes2h> Hi balloons! :-)
[19:43] <primes2h> balloons: how are u?
[19:43] <letozaf_> balloons, sorry I didn't know it was holiday yesterday in the US
[19:45] <balloons> no worries.. I didn't realize it myself :-)
[19:45] <balloons> but when I did, I took the opportunity to go outside and be away from my pc :-)
[19:45] <balloons> I'm doing well.. I trust this evening finds both of you well also
[19:46] <balloons> so, I wanted to chat about a few things
[19:46] <balloons> the first is the classroom sessions, we'd like someone to give a session on laptop/hardware testing ;-)
[19:47] <letozaf_> primes2h, you had to ask balloons about the firs one right?
[19:48] <primes2h> letozaf_: let balloons finish the list please, I think all things could be connected in some way
[19:48] <primes2h> ;-)
[19:48] <balloons> the second is the hw compatibility db.. basically what we spoke about @ UDS.. hexr, ubuntu friendly, etc
[19:50] <balloons> so yes, shoot :-)
[19:51] <balloons> the classroom session  basically requires you to put together a little script, and then via IRC give some instruction about what is invovled, how to help, etc
[19:51] <primes2h> balloons: well, as I thought and I've just said, the two things are connected.
[19:52] <primes2h> balloons: my doubt is about the first part of the session, how to create an hardware profile.
[19:53] <balloons> primes2h, ahh yes.. things are in flux on that aspect aren't they?
[19:54] <primes2h> balloons: sure. :-) UF is not the best choice right now, not anymore I think.
[19:55] <primes2h> balloons: I mean,
[19:57] <balloons> yes, from a hw compatibility perspective we're leaning towards hexr. I haven't heard a timeline from david about getitng us a hexr instance though :-(
[19:57] <balloons> I've sent him off another email. But yes since cprofitt and dkessel are helping re-start ubuntu friendly, our interests are similar
[19:58] <balloons> friendly however is interested in maintaining a list of usable systems, while we're looking to have a list of people's machines willing to test..
[19:58] <primes2h> balloons: in fact it has never been the best way to have an hardware profile because of the delay in having the profile itself on the UF site.
[19:59] <balloons> the tools to profile a machine however, can certainly be shared. I believe hexr was going to move away from the tool they used to utilized checkbox
[19:59] <balloons> yes, the delay problems are a big issue.. and probably one of the first they will attempt to solve
[19:59] <balloons> but in our case, we would still use checkbox, but submit the results to hexr instead
[20:00] <primes2h> balloons: that would be great.
[20:00] <primes2h> wouldn't be, letozaf_?
[20:01] <letozaf_> yeah sure!
[20:01] <balloons> :-p That's my understanding.. so it's on me to get ahold of david to get our instance up
[20:01] <primes2h> balloons: one question,
[20:02] <balloons> but I want to make sure you stay in the loop on friendly because I believe checkbox will have a role in both systems
[20:02] <balloons> primes2h, sure
[20:04] <primes2h> balloons: is checkbox the only tool used right now to send data to hexr?
[20:04] <primes2h> I mean, is it a modified version of checkbox?
[20:05] <balloons>  primes2h last I used it, they were still using there original script
[20:05] <balloons> let me look
[20:05] <balloons> yes, it appears to still be that way
[20:07] <balloons> primes2h, so on the classroom session, your concerned because of the hw profile?
[20:08] <letozaf_> balloons, yes
[20:08] <balloons> ok, so why don't we do something in the interim
[20:09] <balloons> can we instruct folks to paste the output of a script or something similar?
[20:09] <balloons> I know it's not ideal at all
[20:10] <letozaf_> balloons, maybe we could just explain how it has to be done now
[20:10] <balloons> zyga, are you about?
[20:10] <cprofitt> primes2h: I believe there is a desire to change the way data gets to UF
[20:10] <letozaf_> balloons, when modifications come on we can have another classroom session to explain the changes
[20:10] <zyga> balloons: yes
[20:11] <primes2h> balloons: I mean, I thought hexr thing could be ready, so I could run the session in that direction.
[20:11] <cprofitt> I think mike wanted to have the data go directly to UF
[20:12] <balloons> zyga, is there a way to profile a piece of hardware and get a text representation of it? What I am wondering is that even though uploads to ubuntu friendly are failing, could we still somehow get the profile and manually have someone place it somewhere for reference
[20:12] <cprofitt> it sounds like hexr and UF could have synergy... or end up being the same thing - where can I find more information on hexr?
[20:12] <cprofitt> balloons: there is a place they are stored on LP, but I have not been able to figure out where they are stored
[20:12] <zyga> balloons: so yes
[20:12] <cprofitt> there is also a file that is generated by checkbox that is on the local machine
[20:13] <balloons> cprofitt, https://launchpad.net/~nskaggs/+hwdb-submissions
[20:13] <zyga> balloons: it's still a bit of a moving target
[20:13] <zyga> balloons: but the very same code that generates the so-called submission to checkbox server side pieces works just fine
[20:13] <zyga> balloons: in the coming weeks we are going to have support for that in the checkbox cleanup rewrite - plainbox
[20:14] <balloons> zyga, ah-hah.. that's what I was wondering about :-)
[20:14] <zyga> balloons: so far, I'm not 100% sure that it's true, I believe that all the hardware data is just the resource jobs being starte
[20:14] <zyga> roadmr: ^^
[20:14] <zyga> balloons: so the very same jobs could be started, packaged without any test data, and sent somewhere
[20:14]  * roadmr reads backlog
[20:14] <primes2h> cprofitt: balloons zyga: that would be really nice.
[20:14] <zyga> balloons: are you aiming at hexer or the new certification site?
[20:15] <balloons> zyga, we (as a quality community team) want a hw testing database, and we looked at having a hexr instance to do this
[20:15] <zyga> I really encourage you to look at checkbox rewrite
[20:15] <zyga> it's very very well documented
[20:15] <zyga> and well tested
[20:15] <zyga> and we (I) would love community feedback and contributions
[20:15] <primes2h> balloons: and what we really need for the laptot testing hardware profile.
[20:15] <balloons> my assumption was that we would utilize it for generating a profile.. but it's dependent on what hexr would support
[20:15] <cprofitt> will hexr and UF still be two different things or would they end up doing the same thing?
[20:16] <roadmr> you can either create a whitelist with only the resource jobs, or deselect all jobs and run it that way
[20:16] <zyga> cprofitt: I'm not sure, I heard some talks about making the data they manage the same
[20:16] <balloons> zyga, yes as primes2h mentions.. for today, right now, without a testing db online, we really need a way to make a hardware profile
[20:16] <roadmr> it will run the resource jobs anyway, that *should* be enough information about the hardware
[20:16] <balloons> and then a place to store and link to it, so our current process can utilize it
[20:16] <zyga> balloons: ok, so that's something that is probably easy to do today
[20:16] <cprofitt> I just want to make sure if they are going to be mostly the same that we get community support to work on both of them and not compete
[20:16] <roadmr> it will create a submission.xml file that's easy to parse, and that's what gets uploaded to launchpad
[20:17] <cprofitt> with one another for contributors
[20:17] <zyga> balloons: using just plainbox codebase, you would run a sequence of jobs that poke at the hardware and save the results, the only missing pieces that are needed are
[20:17] <zyga> balloons: support for so-called attachment jobs
[20:17] <zyga> balloons: support for saving the old .xml file (if that's what you want to keep)
[20:17] <zyga> balloons: attachments will materialize within 2 weeks
[20:17] <zyga> balloons: xml likely so as well
[20:17] <zyga> balloons: but as far as the interface is concerned you could start hacking today
[20:17] <balloons> primes2h, please jump in here as to what you think is needed
[20:18] <zyga> balloons: and as those two features get added, you will just take advantage of them transparently
[20:18] <zyga> balloons: one caveat: you have to work in the checkbox source tree, plainbox has no stable internal API, and we have no public api at this time
[20:18] <zyga> balloons: in practice it should not be a big deal
[20:19] <zyga> balloons: this way when we break something, we'll update your code
[20:19] <primes2h> balloons: one min., on the phone :-(
[20:20] <cprofitt> so... hexr is going to be more of a component level view vs. specific model/manufacturer
[20:20] <balloons> cprofitt, on the uf and hexr thing, yes.. it's why I want everyone involved to know about each other and be on the same page.. we can certainly use the same tools to process machines, even though the focus will be different.
[20:20] <balloons> cprofitt, if you haven't seen hexr, it basically is a very testing focused view of machine profiles.. allows you to group, search and look at machines from a testing perspective
[20:21] <cprofitt> I know some of the UF interested people were trying to pull that kind of data as well... which Nvidia cards were working, etc.
[20:21] <cprofitt> yeah, I have not seen it... but would be interested at seeing it
[20:21] <balloons> cprofitt, yes, yes.. So some things are very similar, but for our purposes of the hw testing db, we'd want to ping people with specific bits of hw and ask them to test things
[20:21] <balloons> we would be less concerned with cataloging what works and what does
[20:22] <balloons> *doesn't
[20:22]  * cprofitt nods
[20:22] <cprofitt> I understand I think
[20:22] <cprofitt> not about what works, but getting tests of specific hardware
[20:22] <balloons> right.. at the same time, it's possible for them to be 2 views on the same data :-)
[20:22] <balloons> that I guess we'll have to see..
[20:22] <cprofitt> yep
[20:23] <zyga> if any of you wants to start experimenting with the client-side side of things, ping me please
[20:23] <cprofitt> I do that all the time with the DBs I use
[20:23] <zyga> I'll gladly help everyone get started
[20:24] <cprofitt> gotta run for home now... be back on in a little bit
[20:24] <balloons> k
[20:24] <balloons> ok, so it sounds like for hw profiles primes2h we can do two things today
[20:25] <balloons> correct me if I'm wrong.. have people run checkbox with all jobs deselected, and then post there submission.xml file someplace (since the upload is failing :-()
[20:25] <balloons> 2) write a job for plainbox to run the hw tests and submit them somewhere for us
[20:25] <roadmr> balloons: upload failing? to uf?
[20:25] <zyga> balloons: do you want to have a separate database/server backend?
[20:25] <roadmr> balloons: remember, they first go to launchpad, they all go through, then uf slurps them, this is the phase that's failing
[20:25] <balloons> roadmr, yes, seemingly somewhere in the process submissions aren't making it
[20:26] <roadmr> balloons: but we can leverage what's already in launchpad
[20:26] <primes2h> here I am. sorry.
[20:26] <balloons> roadmr, yes, so uf might be fine ;-) it mightbe getting lost in lp..
[20:26] <roadmr> balloons: here's every submission I've ever done: https://launchpad.net/~roadmr/+hwdb-submissions
[20:26] <zyga> balloons: if so, then 2) is probably saner out of the box as you can control what you send trivially from plainbox (you can send custom blobs, json, custom xml, etc)
[20:27] <balloons> zyga, what do you mean by seperate db/server backend
[20:27] <zyga> balloons: using the existing db is only a good option when it is not a problem for you (it won't block you instantly) and you can somehow take the crappy data out (which is a problem in itself)
[20:27] <zyga> balloons: well, I know of hexer,ubuntu  the certification site, and friendly (wherever that lives)
[20:28] <primes2h> zyga: I agree.
[20:28] <balloons> roadmr, yes, so perhaps we have them submit, then go to that page and manually link there pfoile? the thing is they are bzipped
[20:28] <roadmr> balloons: yep, need to bunzip them :/
[20:29] <roadmr> balloons: but that's easy, right?
[20:29] <zyga> there is also LAVA but I think for ubuntu you could use checkbox/plainbox to get stuff you want faster (lava has it's own server side parts and custom hardware profile collector)
[20:29] <primes2h> roadmr: I think the problem could be to find the profile you've just sent.
[20:29] <primes2h> roadmr: in launchpad I mean
[20:29] <balloons> the ultimate goal for the current process is to have a link on the web with a readout of the hw profile
[20:29] <roadmr> balloons: I also think there's either a place where you can get *all* submissions, or some sort of API access to the thing, I remember cr3 slurping all the submissions via some weird magic
[20:29] <zyga> balloons: can launchpad provide that today?
[20:30] <balloons> traditionally, ubuntu friendly was providing this, right primes2h ?
[20:30] <primes2h> balloons: exactly, we juust need a simple hw profile
[20:30] <primes2h> somewhere
[20:30] <zyga> roadmr: I read that code, it will never (sorry cr3) scale beyond "let me download record X", if you want to do any kind of analytics on top you need to mirror the whole dataset
[20:30] <primes2h> :-)
[20:30] <roadmr> zyga: indeed, that's what cr3 did :) (and had a laptop downloading all submissions for a while)
[20:31] <primes2h> balloons: yes, but it was release-related
[20:31] <zyga> and lastly, there are privacy concerns to mention, but those should be minimal in practice, with what is currently being submitted (probably?) by checkbox
[20:31] <primes2h> balloons: it is I mean
[20:31] <primes2h> balloons: e.g. https://friendly.ubuntu.com/12.10/Acer/Aspire%202930/I:BvKMKi:Jfp:Co4:I8g:FO:BEfp:EZU:I8g:BM0:I8g/
[20:32] <zyga> balloons, primes2h so my bit of advice would be to decide where you want to store data, can you freely change the friendly DB if you take over the project? can you just use the infrastructure and existing code as a starting point -- if so, that's a good reason to reuse it
[20:32] <balloons> yes, the simpliest way to get a link (literally a link) to a page that provides hw output lke that is what the hw testing folks want in the interim
[20:32] <balloons> long term is the goals around hexr
[20:32] <primes2h> balloons: the big issue right now is that you must run checkbox from a stable release to have your profile on UF site.
[20:32] <zyga> if not, I would prototype something away from the current codebase, just make sure you can consume a subset of the data, to get you started
[20:33] <zyga> and worry about how to connect to hexer later
[20:33] <primes2h> balloons: with the delay problem as well
[20:33] <zyga> probably linking at a web-app level is better in practice (so a link from friendly might bring you over to hexer) as two separate projects just won't in practice agree on enough of the lower level bits to share a db
[20:34] <balloons> zyga, we're trying to be as simple as possible, to basically fix what is a bug in the process
[20:34] <balloons> namely that we can't link to a hw profile
[20:34] <zyga> balloons: then patching the codebase is probably the quickest option, assuming that is possible in the desing (I don't know how friendly works)
[20:34] <cr3> zyga: don't apologize to me, you're supposed to slurp from launchpad which is where you should slurp submissions from
[20:35] <zyga> cr3: yeah but for doing any kind of 'big data' analysis you have to mirror each record so the api is really rsync
[20:35] <zyga> cr3: for accessing data casually, it's good
[20:36] <balloons> hmm... so cprofitt took off, but I wonder if it would be possible to get friendly to work sooner rather than later
[20:36] <cr3> balloons: you need to be a member of the ~hwdb-team to access the launchpad hwdb api, which you might already be a member through ~canonical-ubuntu-platform
[20:36] <balloons> that would, as zyga says, keep the current process intact enough to keep going, while the bigger picture stuff around hexr and uf happen
[20:37] <zyga> balloons: I'm not sure anything happens around uf at this time
[20:37] <cr3> zyga: same for the launchpad api, same for the hexr api, big data analysis is either hard to get right or should be done with map-reduce scripts
[20:37] <zyga> cr3: I agree
[20:38] <primes2h> zyga: I agree with balloons, we just need a simple way to fix the hw profile bug in the laptop testing tracker...
[20:38] <zyga> cr3: I just say that any kind of remote-data is flawed without a solution to this problem, unless both servers have 10G links and are in one rack
[20:38] <zyga> primes2h: ok, anything I can help you with on the checkbox side, to get you going, just ask me
[20:42] <primes2h> zyga: to sum up, do you think that the 2) option is the simpler way to achieve the result?
[20:42] <zyga> primes2h: if you need to send the current submission xml then no, for the moment keep using checkbox as we don't have that feature reimplemented yet
[20:43] <zyga> primes2h: your part of the problem is to figure out which things to "run" (tests / jobs)
[20:43] <zyga> primes2h: later on you can just call a different tool / library to do that
[20:43] <zyga> primes2h: as plainbox is not about changing everything, just making it more reliable and easy to use
[20:46] <zyga> primes2h: one thing that's not clear to me -- do you want to have interactive tests in friendly, or just automated hardware scraping?
[20:47] <primes2h> zyga: in my opinion, a very simple script to get just hw data and submit them somewhere to have it available immediately ("live" )should be enough ;-)
[20:47] <zyga> primes2h: well, once you stabilize your selection of checkbox jobs to execute, ping me :)
[20:48] <primes2h> zyga: I mean, that's what is needed now.
[20:48] <zyga> primes2h: it's _almost_ trivial to do that in plainbox (apart from local jobs that kind of mess the high-level API, that will be refactored ijn the next few weeks)
[20:48] <zyga> primes2h: I understand
[20:48] <zyga> primes2h: but I don't know which parts of the checkbox submission you want, that's controlled by the job selection
[20:48] <primes2h> zyga: something like this
[20:49] <primes2h> https://friendly.ubuntu.com/12.10/Acer/Aspire%202930/I:BvKMKi:Jfp:Co4:I8g:FO:BEfp:EZU:I8g:BM0:I8g/
[20:49] <primes2h> just an hw profile on a site
[20:49] <zyga> cr3: ^^ is that just udevresource at work?
[20:49] <zyga> roadmr: ^^
[20:49] <zyga> if so I can write you a script like that in 10 minutes, it will just save json for now, as xml output is not implemented (patches really welcome)
[20:50] <roadmr> zyga, primes2h : yes, mostly udev_resource
[20:50] <zyga> (and maybe some kind of dmi data, unless "acer aspire" is magic data from somewhere else
[20:50] <zyga> primes2h: if you work with roadmr to finalize the selection of jobs, I'll write the relevant tool now
[20:51] <primes2h> zyga: roadmr: sure, lsusb -vv lspci lshw as well etc.
[20:52] <balloons> dmidecode might in there as well
[20:53] <roadmr> zyga, primes2h : that's kinda easy, bzr branch lp:checkbox && cd checkbox && head -33 data/whitelists/default.whitelist
[20:53] <roadmr> that's everything that's not an actual test job (i.e. the system data collection stuff)
[20:54] <zyga> k
[20:54] <primes2h> roadmr: interesting...
[20:54] <zyga> give me a sec
[20:55] <roadmr> primes2h: heeh :)
[20:57] <primes2h> roadmr: it's simple, when you know "where" to look... ;-)
[20:59] <primes2h> zyga: roadmr: but there is still the "where to submit data" issue I think.
[21:00] <roadmr> primes2h: well ask us for pointers on where to look, we're always happy to help
[21:00] <primes2h> to have it available immediately as a link
[21:01] <primes2h> roadmr: I'll surely do, thank you :-)
[21:01] <zyga> primes2h: I cannot help with that issue, sorry
[21:01] <roadmr> primes2h: as-is, it can't be done, because there are two layers of processing between the upload and the actual appearance of the submission in UF
[21:02] <roadmr> primes2h: so when you upload, there's no way of knowing a priori where your report will be visible
[21:03] <primes2h> roadmr: ehhh, that is the big problem we've had with UF so far.
[21:03] <roadmr> primes2h: yes, and I'm afraid without some massive architectural redesign it's not going to improve
[21:06] <cr3> zyga: sorry for the lag, glad to see roadmr is still quicker than me :)
[21:07] <roadmr> cr3: haha I do my best, plus you're busy with important stuff while I'm just vulturing here
[21:21] <primes2h> mmh, bad connection. :-/
[21:23] <primes2h> zyga: roadmr: thanks a lot, then I'll have  a look at checkbox first.
[21:23] <roadmr> primes2h: ok, checkbox is a complex piece of machinery, do let us know if you need help figuring out the innards
[21:24] <primes2h> letozaf_: do you have questions about that?
[21:24] <letozaf_> primes2h, no, you guys have figured out everything :)
[21:24] <primes2h> roadmr: ok, thanks :-)
[21:25] <letozaf_> balloons, what about the classroom sessions, I've never held any, and so I think also primes2h we will need some help :)
[21:26] <balloons> primes2h, letozaf_ heh ;-)
[21:26] <balloons> yes, I will be around so you won't be alone
[21:26] <primes2h> balloons: sure, that was the next question. :-D
[21:26] <balloons> let me link you to the page that talks about running  a session
[21:26] <balloons> there will also be people from the classroom team there
[21:27] <balloons> I'd never used the classroom bot before, but they made it wasy
[21:27] <balloons> in a nutshell, you just need to have prepared 15-20 mins of material to cover.. Typing up some of what you want to say in advance (at least notes) isn't a bad ida
[21:28] <balloons> you then talk about the subject via IRC chat in the classroom channel
[21:28] <balloons> so in your case, the agenda could look something like this
[21:29] <balloons> 1) What is hw testing? 2) Why do we do it? 3) Discuss tools/setup needed 4) Submit a result 5) Discuss how the result is used, and when testing occurs 6) Q & A
[21:29] <balloons> that was literally off the top of my head.. but the jist is to have you cover hw testing.. the goal is to get more people interested in helping test, and understand how to do so
[21:30] <balloons> make sense?
[21:30] <letozaf_> balloons, yes
[21:30] <primes2h> balloons: absolutely
[21:30] <balloons> https://wiki.ubuntu.com/Classroom/Guidelines
[21:31] <balloons> they also allow you to have slides
[21:31] <balloons> apparently they are helpful and useful.. I didn't have any, but not a bad idea for you to make some
[21:32] <balloons> and yes, you can tackle the session together if you wish
[21:32] <balloons> that answer the questions? Just need to pick a day and time, and then let liz know..
[21:33] <primes2h> balloons: what about Sergio? Does he want to give a hand?
[21:33] <letozaf_> balloons, how do the slides work, I mean must we put them somewhere and then write the link in chat or is there something different?
[21:34] <balloons> letozaf_, you can ask the team for more info directly
[21:34] <balloons> basically provide them a pdf file
[21:34] <balloons> they need it the day beforehand
[21:34] <letozaf_> balloons, ok thanks we will see if we need some
[21:35] <balloons> I'm unsure of how the slides work then.. you can join #ubuntu-classroom-backstage at any time and ask them about it
[21:35] <balloons> they will be the ones helping you out with those technical details
[21:35] <balloons> primes2h, Sergio was interested, but didn't want to steal your thunder ;-)
[21:42] <primes2h> balloons: noo, no problem for me, his help is very welcome, we could manage to split arguments, there could be a lot of things to say.
[21:44] <balloons> primes2h, ok, I'll leave you 3 to it then
[21:44] <primes2h> balloons: letozaf_ and I should first talk about topics and how to organize the session.
[21:45] <balloons> could you please just update the wiki page and let everyone on the thread know once you have a date and time picked
[21:45] <balloons> that's the most important thing
[21:45] <balloons> i want to promote the event :-)
[21:45] <balloons> and the others need to plan it
[21:45] <balloons> plan for it, I should say
[21:45] <balloons> you have to plan the content, lol :-)
[21:45] <letozaf_> balloons, :)
[21:46] <plars> balloons: aiui, there were some hw enablement changes dropping into 12.04.2 and assuming we have rc builds starting soon, the idea was to give extra time before release for testing. Do you have plans already for doing a call for testing centered around this?
[21:46] <letozaf_> balloons, I will pick a date with Sergio and Sergio and put it on the wiki :)
[21:46] <balloons> letozaf_, ty
[21:46] <primes2h> balloons: sure, I think it won't be in January, probably at the start of February
[21:47] <balloons> the hw stuff -- I only know about the boot stuff and kernel stuff
[21:47] <balloons> is there anything more?>
[21:48] <zyga> balloons: done
[21:48] <zyga> roadmr, primes2h ^^ :-)
[21:48] <roadmr> wha? that was quik\
[21:49] <balloons> zyga, <3
[21:50] <primes2h> balloons: plars: let us know, we can start a laptop testing instance on the tracker if so.
[21:51] <zyga> roadmr: I had to refactor some things to make it cleaner
[21:51] <roadmr> cleanr is good
[21:52] <plars> balloons: I don't have details, but the idea is that we'd like a lot of people to try it on their hardware given the nature of the changes
[21:53] <balloons> plars, ok, well.. as primes2h if the changes are invasive and wide-spread enough we can simply do a hw smoke test run
[21:53] <balloons> otherwise, we can target the kernel and boot packages
[21:53] <zyga> let me commit that quickly
[21:53] <balloons> plars, I guess a post on ubuntu-release should clear the air
[21:56] <letozaf_> good night guys. I'm going to bed :)
[21:57] <primes2h> me too! it's late here. ;-) good night!
[21:59] <zyga> roadmr: some of those jobs need attachment support
[21:59] <zyga> roadmr: so I'm just adding that
[22:00] <roadmr> zyga: oh cool! is it easy?
[22:02] <zyga> roadmr: yes
[22:03] <zyga> roadmr: obviously it will need some time to properly mature, get tests and other stuff written
[22:03] <zyga> roadmr: but it mostly works already
[22:03] <roadmr> yay :)
[22:05] <balloons> plars, I sent something into the ether that is the mailing list
[22:05]  * zyga wishes sylvain worked at night
[22:07] <roadmr> he's an early bird :/
[22:19] <zyga> ok
[22:19] <zyga> attachments work
[22:20] <zyga> I need a moment to create a few temporary commits
[22:20] <zyga> sudo support is not implemented, sadly, so a few things are missing
[22:30] <roadmr> zyga: I think sudo (or pkexec) support is scheduled for our next iteration, so yay!
[22:30] <roadmr> oh that'll be SO fun
[23:07] <zyga> balloons: ping me tomorrow for 'plainbox friendly' demo and code
[23:08] <balloons> zyga, ohh nice
[23:08] <zyga> if you want to play with it today:
[23:08] <zyga> https://code.launchpad.net/~zkrynicki/checkbox/friendly-hardware-profile
[23:08] <zyga> also on github at https://github.com/zyga/checkbox/tree/launchpad/friendly-hardware-profile
[23:09] <zyga> balloons: to use, see plainbox/README.md
[23:09] <zyga> balloons: then run plainbox friendly
[23:09] <zyga> balloons: it should take a few days for this to get cleaned up and then properly get into trunk (and subsequent release and ppa)
[23:09] <zyga> balloons: I'd appreciate some feedback though
[23:10] <zyga> balloons: and we still need the patch for .xml output
[23:10] <zyga> balloons: the full diff is here: https://github.com/zyga/checkbox/compare/launchpad;friendly-hardware-profile
[23:10] <balloons> ok great
[23:10]  * balloons looks quickly
[23:14] <zyga> balloons: one thing that I worry about just now is that the 'current' xml format is really suited for certification
[23:14] <zyga> balloons: and it probably carries a few 'odd' fields that make no sense
[23:14] <zyga> balloons: such as the hardware identifiers we use for certification
[23:15] <zyga> balloons: I would encourage you to start a discussion on how friendly should work
[23:15] <zyga> balloons: ideally on a public forum, so that everyone can join (maybe a small mailing list)
[23:15] <zyga> balloons: and do blog about it please
[23:15] <balloons> having yourself working on plainbox is very nice
[23:18] <zyga> balloons: the patch is bigger than it should be because I also added support for attachment jobs
[23:18] <zyga> balloons: also, example submission from my machine:
[23:20] <zyga> the submission, currently, is 1.4M for me
[23:20] <zyga> probably way bigger than it needs to be, can be gzipped too
[23:20] <zyga> http://paste.ubuntu.com/1561090/
[23:20] <zyga> balloons: that's it, I'm off today
[23:23] <balloons> zyga, good stuff
[23:23] <balloons> ty