[12:19] <BenC> mkrufky: there's a new bcm43xx driver I want to test and include
[12:19] <BenC> jbailey: sorry, I'd just do the upload
[12:19] <BenC> it probably wont be until after UBZ that I do the first upload
[12:21] <jbailey> BenC: Cool.  WAnted to make sure that it wouldn't RoyallyScrewAnything(tm)
[12:50] <infinity> BenC : Dang, really?... I was hoping to get new kernel testing pre-UBZ, so while we're all stuck in meetings for 2 weeks, users can file a mess of bug reports.
[02:05] <zul> heylo
[06:59] <dilinger> sigh.
[06:59] <dilinger> /home/dilinger/cml26x20050104_<IP_ADDRESS>/carmel.c:119:19: hosts.h: No such file or directory
[06:59] <dilinger> so close...
[08:45] <dilinger> anyone have a breezy machine i can use to compile a driver on?
[08:45] <dilinger> er, amd64 breezy machine, that is
[08:46] <dilinger> oh, actually, i can probably setup a chroot on mouth.  nm.
[08:48] <Mithrandir> dilinger: else, I can provide you with an account on ravel.
[08:50] <dilinger> thanks.  let's see if this works..
[08:54] <dilinger> argh
[08:54] <dilinger> need a 64bit kernel, don't i?
[08:54] <dilinger> root@mouth:~# chroot /home/dilinger/breezy mount -t proc proc /proc
[08:54] <dilinger> Mithrandir: yea, an account on ravel would help
[08:55] <dilinger> er, chroot: cannot run command `mount': Exec format error
[08:55] <dilinger>   was what i meant to paste
[08:55] <Mithrandir> yup, you need a 64 bit kernel
[08:55] <dilinger> actually
[08:55] <Mithrandir> drop a mail to<EMAIL_ADDRESS>cc<EMAIL_ADDRESS>ask for access to ravel, include SSH key and preferred username and please gpg sign the mail.
[08:55] <dilinger> http://mouth.voxel.net/~dilinger/cml.tar.gz
[08:56] <dilinger> can you see if that'll compile against amd64-generic headerS?
[08:56] <dilinger> it should generate SATAIIS150.ko
[08:57] <dilinger> if it works, that's all i need to do this install
[08:57] <dilinger> hopefully the promise folks kept it 64bit clean..
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c: In function `cml_normal_response':
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c:1825: error: structure has no member named `mapping'
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c:1826: error: structure has no member named `len'
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c: In function `cml_queue':
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c:4656: error: structure has no member named `mapping'
[08:59] <Mithrandir> /home/tfheen/tmp/cml26x20050104_<IP_ADDRESS>/carmel.c:4657: error: structure has no member named `len'
[08:59] <Mithrandir>  make KERNEL_SOURCE_DIR=/u
[08:59] <Mithrandir> sr/src/linux-headers-2.6.12-9-amd64-generic
[08:59] <Mithrandir> is what I used
[09:04] <dilinger> i'm not sure how that managed to compile on i386
[09:05] <Mithrandir> heh :-)
[09:06] <dilinger> oh right
[09:06] <dilinger> i386 #defines that bit of code away, x86_64 actually attempts to use it
[09:22] <dilinger> Mithrandir: ok, that should be fixed
[09:48] <Mithrandir> ook
[11:53] <makx> salut fabbione
[11:57] <fabbione> hey makx
[12:12] <makx> fabbione: i'm enclined to drop the often discussed sparc klibc patch, as the debian gcc defaults to 32 according to trave11er..
[12:12] <makx> needs to move on into testing.. :)
[12:13] <fabbione> makx: go ahead and do it
[12:13] <fabbione> i default to 32 too
[12:13] <fabbione> it was a manual mistake to build it at 64
[12:14] <fabbione> this patch looks like a question of life&death
[12:14] <fabbione> just do what you think is right
[12:14] <fabbione> and i will sync it
[12:14] <fabbione> a patch that was born by a mistake
[12:14] <makx> fabbione: hehe, ok thanks.
[12:14] <makx> we have lots of yaird proponents and i don't want to make them the gift of not letting intramfs-tools into testing.
[12:19] <fabbione> what's yaird?
[12:24] <makx> an initramfs generator based on perl modules.
[12:24] <makx> produces a very slim initramfs.
[12:25] <makx> with all the bonus and bad sides, svenl loves it because of this. i'm more inclined to see that as dev syndrom.
[12:27] <fabbione> they are all the same at the end
[12:29] <makx> well hopefully ;)
[03:20] <zul> heylo
[03:46] <dilinger> Mithrandir: if you get bored, could you re-download that tarball and give it another try compiling against amd64-generic?
[03:46] <dilinger> http://mouth.voxel.net/~dilinger/cml.tar.gz
[03:47] <Mithrandir> Driver for knerle 2.6.12-9-amd64-generic has been built done
[03:48] <Mithrandir> apart from the obvious typo, seems to compile fine at least.
[03:52] <dilinger> Mithrandir: can you put SATAIIS150.ko online for me somewhere please?
[03:58] <Mithrandir> http://err.no/tmp/SATAIIS150.ko
[04:02] <dilinger> thanks
[04:03] <dilinger> breezy's installer/partitioner still doesn't see any disks, despite 8 devices now showing up in /dev/discs.  wtf. :(
[05:14] <Mithrandir> you might need something like the sd_mod module or so?
[05:48] <dilinger> Mithrandir: that's loaded beforehand
[05:49] <dilinger> there are symbols in sd_mod that it requires in order to load
[05:49] <dilinger> afaict, the driver is working fine..
[05:51] <dilinger> i guess i'll try w/ the i386 installer, see where that gets me
[07:09] <dilinger> hm, no fabbione
[07:09] <dilinger> ah well, just created the OpenAFSSupport spec
[09:45] <jbailey> mjg59: Hey, looking at -rc5-mm1 it looks like akpm might have suspend/resume with usb suckage under control.  Any idea if it's real?>


[10:58] <dholbach> popey, pleia2, technoviking, nixternal: around?
[11:00] <popey> yup
[11:01] <dholbach> mako is not on freenode, or he is somebody else or something and sabdfl can't make it, mdke probably neither
[11:01] <dholbach> I just had a look at https://wiki.ubuntu.com/CommunityCouncilAgenda and it seems that every topic is a 21 UTC topic
[11:02] <dholbach> I realise that mdke's and my item has been on it for a very long time, so I'll try to take if off of there (as I normally can't make the 21 UTC times) and try to figure out something via email
[11:03] <popey> ok
[11:03] <dholbach> Emmet's item depends on the DMB election, so it'll need to wait a bit until the DMB election was closed
[11:03] <popey> fastest meeting ever
[11:03] <dholbach> do you have anything that needs to be discussed?
[11:03] <dholbach> or does anybody else have anything?
[11:03] <popey> i dont
[11:04] <dholbach> let's wait a few ticks then to see if anybody else does :)
[11:05] <dholbach> alrightie... I'll write something quick up for the team report then
[11:05] <czajkowski> does this meeting time ever work ?
[11:05] <dholbach> czajkowski: usually it does :)
[11:05] <czajkowski> hmm ok
[11:05] <dholbach> it's just that we didn't have much to discuss this time :)
[12:17] <persia> Um, my item was covered in the last meeting, and passed by a majority.  Sorry to not remove it from the agenda for this time.
[13:00] <NCommander> #startmeeting
[13:00] <MootBot> Meeting started at 07:00. The chair is NCommander.
[13:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:00]  * JamieBen1ett waves
[13:00] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100119
[13:00] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100119
[13:00]  * ogra coughs
[13:00]  * GrueMaster opens a weary eye.
[13:01] <NCommander> [link] http://piware.de/workitems/mobile/lucid/report.html
[13:01] <MootBot> LINK received:  http://piware.de/workitems/mobile/lucid/report.html
[13:01]  * cooloney1 waves
[13:01] <NCommander> [topic] Action Item review
[13:01] <MootBot> New Topic:  Action Item review
[13:01] <asac> hi
[13:01] <NCommander> [topic] asac, ogra, persia to make sure .32 backporting for imx51 kernels is documented somewhere (c/o).
[13:01] <MootBot> New Topic:  asac, ogra, persia to make sure .32 backporting for imx51 kernels is documented somewhere (c/o).
[13:01] <persia> It's documented somewhere.  It's just not very complete.
[13:01] <asac> ok
[13:01] <persia> https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100112/FSLKernelBackport
[13:02] <NCommander> persia, do we need a c/o on this one?
[13:02] <cooloney1> yeah, i updated some on it
[13:02] <persia> Needs more input from the people wo haven't finished (JamieBennet, cooloney)
[13:02]  * JamieBennett got sidetracked this week
[13:02] <persia> NCommander: Better would be to have specific action for JamieBennet on bootspeed (or reassign)
[13:02] <JamieBennett> leave it with me
[13:02] <asac> i will ping dtchen again
[13:03] <NCommander> [action] JamieBennett to complete imx51 backportng documentation on bootspeed.
[13:03] <MootBot> ACTION received:  JamieBennett to complete imx51 backportng documentation on bootspeed.
[13:03] <NCommander> [topic] [topic] asac to discuss with dmart how to best tackle the list and assign packages to team members etc.
[13:03] <MootBot> New Topic:  [topic] asac to discuss with dmart how to best tackle the list and assign packages to team members etc.
[13:03] <persia> cooloney1: Are there really only two patches of interest in kernel/ubuntu?
[13:03] <asac> yes, we started to go through the list
[13:03] <cooloney1> persia: actually, i am not sure about the requirement.
[13:03] <asac> added more variables for prioritization (e.g. number of rdepends)
[13:03] <asac> and section
[13:03] <asac> so thats done
[13:03] <asac> its work in progress
[13:03] <asac> we will assign bugs for the important ones etc.
[13:04] <cooloney1> just got that requests from ogra before, than looked at those feature and backported and built the kernel
[13:04] <NCommander> asac, do we need any action items for actually opening the bugs?
[13:04] <ogra> cooloney1, requirement is that most or all HW i plug into my laptop should work the same way on my babbage
[13:04] <asac> no
[13:04] <asac> thats part of the thumb2 spec imo
[13:04] <asac> already covered
[13:04] <NCommander> [topic] dmart to investigate test procedures at ATM which may work on dove
[13:04] <MootBot> New Topic:  dmart to investigate test procedures at ATM which may work on dove
[13:05] <ogra> cooloney1, and that features we develop in-house should not be broken due to linux-imx being behind
[13:05] <asac> dmart: did you find anything=
[13:05] <asac> ?
[13:05] <asac> is that actually still relevant?
[13:05] <dmart> Unfortunately, I didn't come up with much useful.  Most of our tests are hardware-level, and can't be used on real silicon.
[13:05] <asac> yeah
[13:06] <dmart> Running things like the GCC bootstrap / testsuite seems a good idea if not done already
[13:06] <dmart> Was there any progress on that?
[13:06] <NCommander> dmart, negative, board is too unstable to even get that far
[13:06] <asac> who had that item?
[13:06] <asac> me?
[13:06] <cooloney1> ogra: heh, that needs go through all the .32 kernel patches, a hugh task
[13:06] <asac> dmart: or doko ?
[13:06] <NCommander> [topic] ericm, NCommander, GrueMaster to work on dove kernel debugging
[13:06] <persia> cooloney1: Yep.
[13:06] <MootBot> New Topic:  ericm, NCommander, GrueMaster to work on dove kernel debugging
[13:07] <ogra> cooloney1, nah, not *all* ... focus should be on in-hoouse development we do (apparmor, aufs ... and kernel/ubuntu )
[13:07] <ericm> seems I joined the right moment
[13:07] <asac> hi ericm
[13:07] <GrueMaster> Not much I could do, as once the system locks, nothing is logged.
[13:07] <NCommander> ericm, indeed :-)
[13:07] <NCommander> So, based on conversations with Marvell, we have an actual silicon bug, not a kernel bug.
[13:07] <dmart> asac: test / boostrap wasn't a formal action.  I can't do it because I don't have the board though ;)
[13:07] <ericm> well, here are some updates
[13:07] <cooloney1> ogra: ok, got you, will go through all our Ubuntu lucid .32 master kernel patches
[13:07] <asac> dmart: ok lets talk afterwards so i understand what this involves
[13:08] <dmart> OK
[13:08] <ericm> I was in Marvell Shanghai office and helped them test a little bit on their X0 board
[13:08] <dmart> For my understanding, is this purely a kernel issue, or userspace? (or both?)
[13:08] <ericm> so far so good, no system freeze issue (once ever been observed though not sure if it's the same symptom as in Y1)
[13:09] <asac> ericm: could you reproduce the issue in front of them with YX?
[13:09] <asac> Y1
[13:09] <ericm> yet gnome-panel still respawns and ubiquity failed when partitioning
[13:09] <ogra> or Y0
[13:09] <ericm> asac, yes they know the issues
[13:09] <ogra> ericm, thats a general bug (ubiquity)
[13:09] <NCommander> ericm, the ubiquity fails with partitioning is a code bug, not a thumb2 bug :-)
[13:10] <ericm> ogra, well I guess this doesn't happen on imx51?
[13:10] <ogra> it does apparently
[13:10] <dmart> It does :(
[13:10] <asac> ericm: ok. what about the emulation front. do they know which instructions trigger this?
[13:10] <ogra> i havent seen it, but i didnt test with manual partitioning
[13:10] <ericm> but gnome-panel also respawns again and again on imx51?
[13:10] <asac> no
[13:10] <ogra> afaik it even happened on x86
[13:10] <asac> for me it feels related
[13:10] <ogra> the panel issue seems related, yes
[13:11] <ogra> partitioning doesnt
[13:11] <asac> right
[13:11] <ericm> asac, what you mean by emulation front and instructions trigger this?
[13:11] <NCommander> [action] eric and NCommander to investigate what causes the gnome-panel crash/restart cycle
[13:11] <MootBot> ACTION received:  eric and NCommander to investigate what causes the gnome-panel crash/restart cycle
[13:12] <asac> ericm: i thought we think that some thumb2 instruction triggers this
[13:12] <asac> do we know which one
[13:12] <asac> ?
[13:13] <ericm> asac, ah yes - it's VLDR
[13:13] <ericm> and only when VLDR in thumb2 mode
[13:13] <ericm> it's actually not a thumb2 instruction, but a VFP register load instruction
[13:13] <dmart> Is there any bug report or other info I could look at?
[13:13] <ericm> but if that instruction happens in thumb2 mode, incorrect alignment fault happens
[13:13] <NCommander> ericm, can't we use the kernel to trap and rewrite the thumb2 instruction so we shift back to ARM mode during the VFP register load?
[13:14] <ericm> NCommander, they already provided the workaround and was merged in karmic, otherwise will be overwhelmed in alignment faults error messages
[13:14] <asac> so we can pull that workaround?
[13:14] <ericm> NCommander, and the workaround works almost same as you mentioned
[13:15] <NCommander> ericm, if the workaround is in karmic, then why do we still see such broken behavior? We merged previous thumb2 patches which helped
[13:15] <dmart> Might this be connected with the other instability?
[13:15] <asac> ericm: ?
[13:15] <asac> probably
[13:15] <asac> (instability)
[13:15] <ericm> I'll say the patch doesn't work all the time
[13:15] <asac> ericm: my question is: qhy isnt that workaround in karmic
[13:15] <ogra> you mean lucid
[13:15] <ericm> asac, it's already in karmic-proposed
[13:15] <asac> yeah
[13:15] <asac> sorry
[13:15] <asac> lucid
[13:16] <ericm> it's there
[13:16] <ogra> but its not sufficient apparently
[13:16] <ericm> ogra, exactly
[13:16] <NCommander> ogra, likely another instruction or two has issues
[13:16] <ogra> right
[13:16] <asac> thats what you say NCommander  .... ericm didnt say that
[13:17] <asac> he said tits just that instruction
[13:17] <ericm> NCommander, either another instruction or the workaround doesn't solve the issue in some corner cases
[13:17] <ericm> yet I guess the latter is more likely
[13:17] <asac> ok. how serios is this worked on at marvell side?
[13:17] <ericm> since I don't see system freezing on X0 (once - but not confirmed it's related to this)
[13:17] <asac> do we need to elevate priority on their side?
[13:17] <asac> would that help?
[13:18] <NCommander> ericm, try and build GCC and other large packages as a stability test on X0
[13:18] <ericm> asac, they are already aware of the issues - and provide some suggestions as could be seen from the mails I get you CC'ed
[13:18] <ericm> but nothing really made progress
[13:19] <asac> ok. just want to understand if we need to ensure that this gets top priority for them.
[13:19] <asac> but lets talk after meeting
[13:19] <ericm> by now, I guess we need to push Marvell to provide some more X0 boards to us
[13:20] <NCommander> [action] asac, ericm, and NCommander to talk about Thumb2 issues after the meeting and report back
[13:20] <MootBot> ACTION received:  asac, ericm, and NCommander to talk about Thumb2 issues after the meeting and report back
[13:20] <asac> ericm: our primary objective would be to get it worked around in X1
[13:20] <asac> Y1
[13:20] <asac> or 0
[13:20] <ericm> asac, I agree we need to make sure they know this as top priority
[13:20] <NCommander> [topic] ogra to care for seed changes to get oo.o off the image
[13:20] <MootBot> New Topic:  ogra to care for seed changes to get oo.o off the image
[13:20] <asac> ericm: right
[13:20] <ogra> NCommander, wasnt needed
[13:20] <asac> that turned out to be a non-issue
[13:20] <NCommander> cool
[13:21] <NCommander> [topic] Standing Items
[13:21] <MootBot> New Topic:  Standing Items
[13:21] <asac> oh
[13:21] <asac> wait
[13:21] <asac> that url is wrong now
[13:21] <asac> [LINK] http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[13:21] <MootBot> LINK received:  http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[13:21] <asac> thats the new one
[13:21] <asac> the trend line will be set to 145
[13:21] <NCommander> asac, thanks
[13:21]  * asac updates
[13:21] <asac> wiki
[13:21] <ogra> shriek
[13:21] <NCommander> [topic] Kernel Status (cooloney, ericm)
[13:21] <MootBot> New Topic:  Kernel Status (cooloney, ericm)
[13:22] <asac> NCommander: sop ;)
[13:22] <asac> stop
[13:22] <asac> so
[13:22] <cooloney1> i got a new fsl bsp from ogra
[13:22] <asac> the work items seems quiet a lot
[13:22] <cooloney1> that introduces 30+ kernel patches.
[13:22] <asac> i would reall like to see everyone going through it and checking the count of workitems and see if there are things that are reall off for alpha-3
[13:23]  * ogra hands asac two y's
[13:23] <asac> NCommander: can you please wait before moving on in general?
[13:23] <NCommander> asac, sorry
[13:23] <asac> you never ask if a topic was done
[13:23] <asac> doesnt matter now ;)
[13:23] <cooloney1> asac: yeah, i stopped, heh
[13:24] <asac> so move on. just include that prominently in the meeting notes
[13:24] <NCommander> [topic] Kernel Status (cooloney, ericm)
[13:24] <MootBot> New Topic:  Kernel Status (cooloney, ericm)
[13:24] <ogra> asac, what are canonical-mobile workitems ?
[13:24] <asac> ogra: thats a pool of items anyone can claim ;)
[13:24] <asac> team specs ;)
[13:25] <asac> you can claim items by adding [ogra] before them
[13:25] <ogra> given the amount of personal items we already all have i think its unlikely anyone would do that
[13:25] <asac> not sure that applies for everyone
[13:25] <ogra> yeah, probably not
[13:26] <JamieBennett> I suppose if no-one claims them asac can distribute them ;)
[13:26] <NCommander> heh
[13:26] <asac> yeah
[13:26] <ogra> yes, but we should set a deadline for that
[13:26] <asac> anyway. you can also pick such items if you are blocked or something
[13:26] <ogra> else they will likely just be lost
[13:26] <ogra> and make us look bad
[13:27] <asac> the deadline is the milestone
[13:27] <NCommander> so are we done with the burndown charts?
[13:27] <asac> the items there will not make us look bad if all other items are done :)
[13:27]  * ogra is
[13:27] <asac> NCommander: why? that url has a burndown too
[13:27] <asac> http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[13:27] <MootBot> LINK received:  http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[13:27] <ogra> well, they add to the overall statistic :)
[13:28] <asac> http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html
[13:28] <NCommander> asac, I know.
[13:28] <MootBot> LINK received:  http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html
[13:28] <asac> ok
[13:28] <asac> yes, that topic is over i hope
[13:28] <NCommander> ericm, cooloney1 anything else you want to bring up on the topic of the ARM kernels?
[13:28] <asac> if anyone has something we can move that to AOB
[13:28] <cooloney1> NCommander: yeah
[13:28] <cooloney1> continue my words.
[13:28] <asac> ok lets focus on kernel ;)
[13:29] <ericm> asac, nothing from my side
[13:29] <cooloney1> i already tested the Alpha2 kernel + 30+ new kernel patch
[13:29] <cooloney1> it works fine.
[13:29] <ogra> the existing patches didnt change in the new BSP ?
[13:29] <cooloney1> and for the NEON issue, I provided 2 solution kernels
[13:29] <asac> what do such tests involve? are you running a full image?
[13:30] <cooloney1> asac: i just build the kernel and replace it on my board
[13:30] <cooloney1> installed the kernel on my board
[13:30] <ogra> the package i guess ?
[13:30] <asac> ok
[13:30] <cooloney1> and will post the package to you guys to test
[13:30] <asac> curious about the NEON things ;)
[13:30] <ogra> yeah
[13:30] <asac> what approaches?
[13:30] <cooloney1> yeah, NEON things, i provided 2 packages
[13:31] <cooloney1> 1 disable NEON defaultly
[13:31] <cooloney1> 2 a kernel side dynamic checking
[13:31] <cooloney1> i think dmart tested all of them on bb2.5
[13:31] <dmart> cooloney1, is that the patch you worked on last week?  I tested on babbage 2.0, bug I think ogra or someone had a problem on 2.5?
[13:31] <ogra> wehat made me curious is the different revisions we see in /proc/cpuinfo
[13:32] <cooloney1> but as we discussed before, method 2 might not be very safe for all the solution
[13:32] <ogra> dmart, i didnt test that kernel yet
[13:32] <ogra> must be someone else
[13:32] <ogra> (likely plars)
[13:32] <dmart> hmmm
[13:32] <cooloney1> yeah, JamieBennett tested that ,
[13:32] <ogra> ah
[13:32] <asac> cooloney1: what does t method 2 base the decision to enable thumb on?
[13:32] <dmart> ogra, I think you're right
[13:32] <cooloney1> but from JamieBennett's cpuinfo, i was confused
[13:32] <JamieBennett> yes but revision numbers seem to be different from expected
[13:32] <ogra> yes, thats what i meant above
[13:32] <cooloney1> the cpuinfo of his JamieBennett's BB3 is the same as my BB2.5
[13:33] <ogra> and mine seems totally different from all of them
[13:33] <ogra> (i noted mine in the bug)
[13:33] <cooloney1> ogra: yeah, i have no idea about that
[13:33] <dmart> cooloney1, ugh :P
[13:33] <dmart> That's a problem...
[13:34] <ogra> cant the kernel find out about that on a different (lower) level ?
[13:34] <cooloney1> ogra: yeah i was told bb3 should be 51130
[13:34] <dmart> Look at the implementation of the BSP's "get revision" function?
[13:34]  * ericm wonders what is 51130 ...
[13:35] <cooloney1> ericm: the revision of the chip
[13:35] <cooloney1> ericm: sorry, the board,
[13:35] <asac> so we probably cannot detect reliably if NEON is stable enough?
[13:35] <ogra> looking at the different outputs it seems the last two numbers are what counts
[13:35] <dmart> Maybe not... I have a conf call with David Mandala later today about what the high-level strategy should be for CONFIG_NEON in general
[13:35] <ogra> but that still doesnt explain why JamieBennett's ends in 20
[13:35] <cooloney1> dmart: yeah, agree. need to discuss that
[13:36] <cooloney1> asac and ogra, what's you guys suggestion?
[13:36] <cooloney1> method 1 disable NEON for all
[13:36] <ogra> well, if there is another way to determine the revision, we should go for that one
[13:36] <cooloney1> or method 2 dynamic check that
[13:36] <ogra> if not, drop NEON for now if possible
[13:37] <ogra> cpuinfo surely doesnt seem reliable enough
[13:37] <asac> dynamic check if we can do it reliably
[13:37] <asac> otherwise NO
[13:37] <ogra> ++
[13:37] <cooloney1> ogra and asac, understand.
[13:37] <cooloney1> agree.
[13:38] <JamieBennett> I can double check everything after the meeting with cooloney1
[13:38] <NCommander> Is that everything on the imx51 kernel to talk about here?
[13:38] <cooloney1> please add me an action about 'ping fsl for more reliable chip rev checking method'
[13:38] <cooloney1> one more thing is i am working on suspend/resume
[13:38] <cooloney1> and pinged fsl about suspend, they did not reply yet
[13:38] <asac> NCommander: action please.
[13:38] <NCommander> [action] cooloney1 to ping fsl for more reliable chip rev checking method
[13:38] <MootBot> ACTION received:  cooloney1 to ping fsl for more reliable chip rev checking method
[13:39] <ogra> for me in former tests suspend worked
[13:39] <NCommander> [action] cooloney1 to ping fsl about suspend
[13:39] <MootBot> ACTION received:  cooloney1 to ping fsl about suspend
[13:39] <cooloney1> is that possible davidm to help that.
[13:39] <NCommander> ogra, what action do you need?
[13:39] <ogra> cooloney1, we can bring it up in the weekly call
[13:39] <ogra> NCommander, none
[13:39] <cooloney1> NCommander: sorry, i ping fsl about suspend before. heh
[13:39] <NCommander> May I move on?
[13:39] <cooloney1> ogra: thanks a lot
[13:39] <cooloney1> yeah,
[13:39] <asac> yes. thanks ericm and cooloney1
[13:39] <NCommander> [topic] ARM Application status (JamieBennett, dyfet)
[13:39] <MootBot> New Topic:  ARM Application status (JamieBennett, dyfet)
[13:39] <ogra> cooloney1, my issue was that i couldnt find a methid to wake it up
[13:40] <cooloney1> not problem asac
[13:40] <cooloney1> ogra: ok, your board is different with magic rev? ;))
[13:40] <ogra> well, its a 2.5 :)
[13:41] <NCommander> dyfet, JamieBennett, ping?
[13:41] <ogra> anyway, thats details we can discuss out of meeting
[13:41] <JamieBennett> I have nothing to report on package issues
[13:41] <JamieBennett> although I see the FTBFS list has some important packages failing
[13:41] <NCommander> JamieBennett, indeed, we'll get there in a moment :_)
[13:41] <JamieBennett> Haven't looked into them though
[13:41] <NCommander> JamieBennett, can I move on?
[13:42] <JamieBennett> yes from me
[13:42] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, dyfet)
[13:42] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[13:42] <NCommander> as JamieBennett said, we do have a few FTBFS'es that need to be resolved (evolution being the big one my list this morning)
[13:42] <ogra> looks like a give back to me
[13:42] <NCommander> Over all, there is a general trend of improvement on this, so we're goingthe right way
[13:42] <NCommander> ogra, cool (I hadn't looked at the log yet)
[13:43] <ogra> i havent looked either
[13:43] <ogra> but evo, ampathy and evo-couchdb are ususally give back candidates
[13:43] <asac> NCommander: can you help dyfet a bit on his ftbfs'es?
[13:43] <NCommander> asac, sure
[13:43] <asac> i would hope that you could work together in a pair-programming approahc
[13:43] <ogra> they rely on arch all packages
[13:43] <NCommander> asac, pair-programming?
[13:43] <asac> ... usually you get same or better throughput than doing alone
[13:43] <dyfet> I am waiting on one ftbfs to be updated in debian, but I will coordinate this week on ftbfs with NCommander to get high priority ones done
[13:44] <asac> NCommander: yes, try to work with him on a shared pool of tasks. taking about the steps, ideas etc.
[13:44] <NCommander> asac, ah
[13:44] <persia> plymouth just needs a rebuild, pending a fix for libdrm (in sponsors queue)
[13:44] <NCommander> dyfet, mind if I move on, or do you have other things to add?
[13:44] <dyfet> nope
[13:44] <NCommander> [topic] ARM Image Status (ogra, persia)
[13:44] <MootBot> New Topic:  ARM Image Status (ogra, persia)
[13:45] <persia> I'm having issues finding the logs that I don't get in mail, so I'm not entirely sure about current state of kubuntu or xubuntu.
[13:45] <ogra> hmm, se didnt get images since 13th
[13:45] <persia> Ubuntu livefs needs evolution help.
[13:45] <ogra> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/
[13:45] <MootBot> LINK received:  http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/
[13:45] <ogra> i'll check clementine ... guess she's unhappy again
[13:45] <persia> ogra: I was looking there, but no recent updates that I saw (but I have newer logs in email)
[13:46] <ericm> regarding the image status - found package xorg not properly named in pool/main/x/xorg/ in alternate image (looks like a DOS name error to me)
[13:46] <ogra> well, if logs dont show up there its very likely that clementine hangs
[13:46]  * NCommander grumbles
[13:46] <persia> ogra: It's not clementine: the processes are running.  Check how the logs are published, perhaps?
[13:46] <NCommander> [action] NCommander to investigate ericm's xorg naming bug.
[13:46] <MootBot> ACTION received:  NCommander to investigate ericm's xorg naming bug.
[13:46] <ogra> ericm, hmm, i thought NCommander fixed that
[13:46] <NCommander> ogra, I did. xorg might have broke it again :-/
[13:46]  * persia is getting livefs build failure notifications
[13:46] <ogra> persia, i'll look on clementine dircetly fiurst
[13:46] <persia> OK.
[13:47] <NCommander> persia, ogra ok to proceed?
[13:47] <persia> Yes.
[13:47] <asac> so is that an mtools bug again=?
[13:47] <persia> asac: No.
[13:47] <ogra> NCommander, yup
[13:47] <NCommander> [topic] Ubuntu Liquid
[13:47] <MootBot> New Topic:  Ubuntu Liquid
[13:47] <ogra> asac, looks like to me
[13:48] <persia> rbelem and I worked on packaging some of the outstanding interface stuff on Saturday and Sunday.
[13:48] <asac> great.
[13:48] <persia> Unfortuantely we both fell simultaneously and unrelatedly ill, and didn't get everything compelted.
[13:48] <persia> We're hoping to push the rest of the missing packages this week.
[13:48] <asac> how many packages are needed?
[13:48] <asac> just rough estimate
[13:49] <ian_brasil_> plasma-mobile, ubuntu liquid metapackage and liquid default settings to start
[13:49] <persia> I can't find the list right now.
[13:50] <asac> ian_brasil_: thanks.
[13:50] <asac> so anyone feels that this is at risk?
[13:50] <NCommander> persia, anything else, or can I go onto AOB?
[13:50] <persia> It's a couple plasma widgets + kdm-mobile and kwin-mobile (as we can't integrate the stuff upstream for lucid)
[13:50] <asac> or needs a push?
[13:50] <persia> Oh right, and -default-settings and -meta :)
[13:51] <asac> persia: Riddell offered to helkp on the plasma bits
[13:51] <asac> afaik
[13:51] <asac> so tap him to get the packaging going :)
[13:51] <persia> rbelem and I get back in touch about an hour back, and feel we can make good progress this week.  We might ask for help to get REVU advocations for some of the new stuff.
[13:51] <asac> yes.
[13:51] <ogra> persia, FYI, seems the logs are missing due to rookery reorganization
[13:51] <persia> asac: Riddell has been helping a lot :)
[13:51] <asac> ok cool.
[13:51] <persia> ogra: That makes sense.  Let's get that sorted :)
[13:51] <ogra> yep
[13:51] <asac> persia: ping me and ogra for revu review
[13:51] <persia> NCommander: I'm done, unless ian_brasil_ has something else (rbelem couldn't make it today)
[13:52] <asac> and NCommander ... i guess
[13:52] <NCommander> ian_brasil_, can I go ahead?
[13:52] <ian_brasil_> yes..persia if you can help with kwin-mobile that would be great
[13:52] <asac> yes
[13:52] <NCommander> [topic] Any Other Business
[13:52] <MootBot> New Topic:  Any Other Business
[13:52] <asac> did we skip QA status?
[13:52] <plars_> yep
[13:52] <persia> ian_brasil_: We're planning that for tonight, if we can.
[13:52] <asac> ok
[13:53] <asac> intentionally?
[13:53] <asac> plars_: NCommander: ?
[13:53] <NCommander> oh, whoops
[13:53] <NCommander> [topic] QA Status (GrueMaster, plars)
[13:53] <MootBot> New Topic:  QA Status (GrueMaster, plars)
[13:53]  * NCommander is still somewhat out of it
[13:53] <plars_> We had pretty good coverage for images during the iso testing
[13:53] <asac> good to hear
[13:53] <plars_> all images (including alts) were tested
[13:54] <plars_> pretty much everything that could be tested, was tested
[13:54] <asac> really? were alternates tested before the release?
[13:54] <plars_> could use some more testers though, if anyone has hardware and spare cycles to do it on A3, would be really helpful
[13:54] <ScottK> NCommander: qt4-x11 4.6.1 is out, so expect several days this week where you can't build Qt stuff on armel because armel is out of sync with the arch all bits of the package.
[13:54] <asac> ok. noted
[13:54] <plars_> asac: yes
[13:54] <asac> plars_: pleesa raise that the  week before next alpha
[13:54] <asac> e.g. more testers
[13:54] <persia> plars_: Can people with non-supported hardware (e.g. Beagle) help in any way with milestone testing?
[13:55] <persia> ScottK: Thanks for the warning.  Any idea when it will be uploaded?
[13:55] <ogra> not really
[13:55] <asac> plars_: so will we do the all-pairs testing now during this test cycle? maybe creating a talbe on the wiki that gruemaster can fill during the cycle would be good
[13:55] <plars_> persia: not really, since the milestones are targetted to the images for these supported platforms, however package testing can always be helpful, and can be done regardless of hardware
[13:55] <ScottK> persia: Not for sure.  I'd say likely today, maybe tomorrow.
[13:55] <ogra> yeah
[13:55] <persia> plars_: Makes sense.
[13:55] <plars_> asac: yes, plan on getting on that now that we have A2 behind us
[13:56] <ogra> persia, the kernels might miss features we use ...
[13:56] <persia> ScottK: OK.  We'll watch that before pusing the liquid stuff then.
[13:56] <asac> plars_: right. just thinking that we dont really need to block on the iso tracker getting the testcases
[13:56] <asac> we can use something else until that happens ...
[13:56] <asac> thanks!
[13:56] <asac> ok. thanks.
[13:56] <NCommander> [topic] Any Other Business
[13:56] <MootBot> New Topic:  Any Other Business
[13:57] <GrueMaster> asac: The problem wasn't iso.tracker.
[13:57] <asac> err ... i didnt speak about any problem ;)
[13:57] <ogra> why !
[13:57] <ogra> :)
[13:57] <asac> i was talking about all-pair testing now that A2 is out
[13:57] <GrueMaster> The problem was the alt images came out at 8am UTC, midnight my time.  You started asking why  I wasn't testing at 3am my time.
[13:58] <GrueMaster> ok
[13:58] <asac> GrueMaster: right. thats not an issue. i dont see a problem with how the alt images were tested. actually happy that we now did a first run
[13:58] <asac> my point was about organiing all-pair testing during a2 -> a3 dev cycle
[13:58] <ogra> but we should see that we roll something testable earlier next round
[13:58] <asac> and said that we dont need to wait for iso tracker getting those pairs to start testing them
[13:58] <ogra> so GrueMaster has a chance to get it done on regular worktime
[13:59] <asac> yes
[13:59] <ogra> alternated for x86 are usually there very early
[13:59] <ogra> even before desktop
[13:59] <asac> alt images were the first time. we should have those available beginning of freeze period
[13:59] <GrueMaster> speaking of which. meeting schedule.
[13:59] <plars> they are on the blueprint wiki, as well as the qa wiki for the tests themselves.  I have access enough now I think to add them to the db
[13:59] <ogra> asac, they are there ... we build dailies since jaunty :P
[13:59] <asac> plars: cool. so lets just add them and use tracker
[14:00] <ogra> asac, they are just not on the tracker until someone tells slangasek to add them
[14:00] <asac> let me know when you added them
[14:00] <asac> ogra: even better
[14:00] <asac> ;)
[14:00] <plars> asac: that's the plan, just going to have someone walk me through it the first time since it appears to be fairly manual, and I don't want to muck it up
[14:00] <ogra> but they can be tested nontheless
[14:00] <NCommander> We're over time
[14:00] <ogra> (and should be)
[14:00] <asac> plars: thanks. sounds good
[14:00] <NCommander> Any last minute tihngs to bring up before I close the meeting?
[14:00] <asac> NCommander: we are on time ;) ...
[14:00] <GrueMaster> meeting schedule!
[14:00] <asac> lets adjourn
[14:00] <NCommander> #endmeeting
[14:00] <MootBot> Meeting finished at 08:00.
[14:01] <NCommander> \o/
[14:01] <NCommander> Thanks all
[14:01] <asac> GrueMaster: ok
[14:01] <cooloney1> cool
[14:01] <ogra> thanks
[14:01] <asac> GrueMaster: we can do that in the call ... you want to rorate it?
[14:01] <cooloney1> thanks,
[14:01] <asac> rotate?
[14:01] <GrueMaster> It is now 6am my time.  Yes, I would like to rotate again.
[14:02] <asac> i think we said to have 2 month same schedule
[14:02] <asac> then rotate
[14:02] <asac> how long is this schedule now?
[14:02] <GrueMaster> We've been on this schedule since August.
[14:02] <asac> hmm. actually i think we never talked about the meeting ... just the call
[14:02] <persia> Are we discussing meeting schedules?
[14:02] <persia> If so, I'll volunteer to be a recipient: all parties interested in attending the meeting, mail me with your UTC offset.  I'll find a couple candidates times that are least bad for the fewest people.
[14:02] <asac> ok
[14:03] <persia> NCommander: Please [ACTION] me with being a recipient in the meeting minutes.
[14:03] <asac> i think the public meeting shouldnt rotate every 2 month though. easier for community to keep tstuff
[14:03] <persia> And I'll report next week (at this time).
[14:03] <asac> but it was since august, so fine.
[14:03] <asac> lets discuss
[14:54] <pitti> hello
[14:55] <persia> Hey pitti.  It appears http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_ea7519273c82ed12 aren't available yet, so we don't know who is supposed to attend this meeting :)
[14:55] <pitti> exactly
[14:55] <pitti> I pinged mdz, but apparently he's in the FFA timezone
[14:55] <pitti> (far far away)
[14:56] <pitti> so we might need to skip this one
[14:56] <persia> 3:00 there, I believe
[14:57] <kees> \o
[14:57] <persia> We may as well run through it.  I suspect we'll want to have the same continuity-preserving attendance next time.
[14:57] <persia> As long as no binding decisions are taken, all should be fine.
[15:01] <cjwatson> here
[15:02] <kees> pitti_: you're here twice.  :)
[15:02] <pitti> I know; I'm at my grandpa's at a very shitty mobile->proxoid->corkscrew->ssh tunnel connection
[15:03] <cjwatson> so can we actually do anything other than action review?
[15:03] <pitti> and having one remote and one local client, just to cover the disconnects :)
[15:03] <kees> pitti: ah-ha, cool.
[15:04] <pitti> we have one pending request from Martin-Eric Racine for per-package upload
[15:04] <pitti> other than that I just see https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[15:05] <pitti> with the team membership being in limbo, I'd actually prefer to postpone the voting
[15:05] <persia> I don't think the pending request can be processed today.
[15:05] <cjwatson> agreed, our terms have expired
[15:05] <cjwatson> which is regrettable, but not much we can legally do
[15:05] <kees> yeah
[15:06] <cjwatson> we need the returning officer to get out of bed
[15:06] <pitti> the outstanding actions don't look to me as if we could do something about them right now?
[15:06] <persia> The first item is essentially waiting for the poll to be closed.
[15:06] <persia> The second item has been approved by the CC, pending assembly of the new DMB, so also waiting on the poll to be closed.
[15:07] <cjwatson> and the third item I was hoping to get done this morning but spent it yak-shaving instead
[15:09] <persia> chair for the next meeting?
[15:10] <pitti> I'll be at the next meeting, anyway
[15:10] <cjwatson> same resolution as last time
[15:10] <pitti> it'll be during the platform sprint, but should be early enough to participate
[15:10] <cjwatson> 15:22 <persia> I was thinking someone could volunteer to chair, and if they didn't happen to be on the board, act as a facilitator for that meeting alone.
[15:10] <cjwatson> 15:23 <cjwatson> I can do that
[15:10] <cjwatson> 15:23 <mdz> I think the "old" board should turn up at the next meeting regardless, to help with continuity
[15:11] <cjwatson> 15:23 <mdz> at least some of us
[15:11] <cjwatson> 15:23 <mdz> I will be traveling to a time zone which would make participation difficult
[15:11] <cjwatson> 15:24 <pitti> I'm happy to join that meeting
[15:11] <cjwatson> 15:24 <mdz> [agreed] cjwatson and pitti will participate in the next DMB meeting regardless of the election outcome
[15:11] <cjwatson> 15:24 <MootBot> AGREED received:  cjwatson and pitti will participate in the next DMB meeting regardless of the election outcome
[15:11] <cjwatson> 15:24 <mdz> you can work out what to do about a chair between yourselves ;-)
[15:11] <cjwatson> I won't be on Pacific time yet; getting up at 7am will not be a problem
[15:11] <pitti> same here
[15:13] <cjwatson> any other business that we can usefully transact?
[15:14] <pitti> seems not
[15:15] <pitti> see you in two weeks then?
[15:15] <cjwatson> then I think we're done; sorry this is rather unsatisfying
[15:15] <kees> cool, see everyone then.  :)
[17:00] <bjf> Roll Call
[17:00]  * cking waves
[17:00]  * rtg waves
[17:00]  * ogasawara waves
[17:01] <bjf> I believe that manjo, sconklin and amitk are probably not making this meeting
[17:01]  * jjohansen waves
[17:01]  * JFo waves
[17:01]  * smb arrives
[17:02] <bjf> waiting for apw
[17:02]  * apw is here
[17:02] <bjf> #startmeeting
[17:02] <MootBot> Meeting started at 11:02. The chair is bjf.
[17:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[17:02] <bjf> NOTE: '..' indicates that you are finished with your input.
[17:03] <bjf> skipping the open item, it's for amitk
[17:03] <bjf> [TOPIC] Lucid Release Status: Bugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs
[17:03] <MootBot> New Topic:  Lucid Release Status: Bugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs
[17:03] <ogasawara> Release Meeting Bugs (1 bug, 3 blueprints) - https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[17:03] <ogasawara> Alpha 3 Milestoned Bugs (29 bugs) - https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=21445
[17:03] <ogasawara>  * 3 linux kernel bugs - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bugs?field.milestone%3Alist=21445
[17:03] <ogasawara>  * 2 linux-fsl-imx51 bugs - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-fsl-imx51/+bugs?field.milestone%3Alist=21445
[17:03] <ogasawara>  * 0 linux-ec2 bug - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-ec2/+bugs?field.milestone%3Alist=21445
[17:03] <ogasawara>  * 2 linux-mvl-dove bugs - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-mvl-dove/+bugs?field.milestone%3Alist=21445
[17:03] <bjf> [TOPIC] Lucid Release Status: Milestoned Features
[17:03] <MootBot> New Topic:  Lucid Release Status: Milestoned Features
[17:04] <ogasawara> Release Targeted Bugs (97 bugs) https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs
[17:04] <ogasawara>  * 8 linux kernel bugs - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux
[17:04] <ogasawara>  * 3 linux-fsl-imx51 bugs - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-fsl-imx51
[17:04] <ogasawara>  * 1 linux-ec2 bug - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-ec2
[17:04] <ogasawara>  * 2 linux-mvl-dove bug - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-mvl-dove
[17:04] <ogasawara> Milestoned Features - https://edge.launchpad.net/ubuntu/+milestone/ubuntu-10.04
[17:04] <ogasawara>  * 1 blueprint - https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-new-kernel-on-lts
[17:04] <ogasawara> ..
[17:04] <bjf> [TOPIC] Lucid Release Status: New metric (apw, ogasawara)
[17:04] <MootBot> New Topic:  Lucid Release Status: New metric (apw, ogasawara)
[17:04] <ogasawara> Bugs with patches attached . . .
[17:04] <ogasawara> In collaboration with the community team, it was thought that bugs with patches attached would be a good target for issues which we could likely fix quickly and therefore close.  It was requested we add this info to our weekly meeting
[17:04] <ogasawara> 119 bugs with patches - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[17:04] <ogasawara> http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[17:04] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[17:05] <ogasawara> ..
[17:05] <apw> i assume the plan is to include these in general stats above
[17:05] <apw> and we continue to focus bug days on them?
[17:05] <ogasawara> yup, that's what I had in mind
[17:05] <bjf> apw, you asked for a specific agenda item
[17:06] <apw> yeah i think for this meeting we wanted it out there as an item, we can evaluate if thats useful
[17:06] <apw> as we move forward.
[17:06] <bjf> ack
[17:06] <apw> I think we should be pointng out that if yuou have spare
[17:06] <bjf> [TOPIC] Blueprints: kernel-lucid-bug-handling (ogasawara)
[17:06] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling
[17:06] <MootBot> New Topic:  Blueprints: kernel-lucid-bug-handling (ogasawara)
[17:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling
[17:06] <apw> cycles they may be sensible ones to look at.
[17:06] <apw> ..
[17:06] <ogasawara> I'm going to work on completing some of my work items this week.  For ex detect staging drivers.
[17:06] <ogasawara> ..
[17:07] <apw> we need to get our stuff together
[17:07] <apw> for JFO too, so he can get the arsenal going regular.  at the next sprint if not before
[17:07] <apw> ..
[17:07] <ogasawara> apw: yes, was going to ask if you'd had time to merge your arsenal bits?
[17:07] <JFo> +1 .. :)
[17:07] <apw> no i'd forgotten, i'll add to my list
[17:08] <bjf> [TOPIC] Blueprints: kernel-lucid-review-of-ubuntu-delta (apw)
[17:08] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-review-of-ubuntu-delta
[17:08] <MootBot> New Topic:  Blueprints: kernel-lucid-review-of-ubuntu-delta (apw)
[17:08] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-review-of-ubuntu-delta
[17:08] <apw> shalle we have an item for sprnt too to review/complete the arsenal automation
[17:08] <ogasawara> apw: I think that'd be good
[17:08] <apw> Nothing to report here.
[17:08] <apw> ..
[17:08] <ogasawara> apw: I'll also plan to go over arsenal bits with JFo next week
[17:08] <apw> good stuff ..
[17:08] <bjf> [TOPIC] Blueprints: kernel-lucid-kernel-config-review (apw)
[17:08] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review
[17:08] <MootBot> New Topic:  Blueprints: kernel-lucid-kernel-config-review (apw)
[17:08] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review
[17:09] <apw> We are going to review whether we should have all sub-systems builtin rather than as modules now that module probing is faster.  As a specific example we have just pulled out bluetooth as it will shortly be included in compat-wireless.
[17:09] <apw> ..
[17:09] <bjf> [TOPIC] Blueprints: kernel-lucid-kms (sconklin)
[17:09] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms
[17:09] <MootBot> New Topic:  Blueprints: kernel-lucid-kms (sconklin)
[17:09] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms
[17:10] <apw> Lots of work on i915 leading to us switching i915.powersave=0 by default as we are seeing nasty twitching and blanking issues, as well as some suspend hangs.
[17:10] <apw> ..
[17:10] <bjf> [TOPIC] Blueprints: kernel-lucid-apparmor-development (jjohansen)
[17:10] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development
[17:10] <MootBot> New Topic:  Blueprints: kernel-lucid-apparmor-development (jjohansen)
[17:10] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development
[17:10] <jjohansen> fixed regression Bug #507069
[17:11] <apw> am i expecting an update for that, am planning on uploading 'now'
[17:11] <jjohansen> debugging dfa optimization
[17:11] <jjohansen> apw: okay
[17:11] <cking> at least I now know what dfa optimisation is
[17:12] <jjohansen> dfa optimization isn't tweeked yet but is giving about 40% size savings and 50% speedup
[17:12] <jjohansen> :)
[17:12] <apw> we still looking to get something committed this week on that?
[17:12] <jjohansen> yep
[17:12] <apw> cool
[17:12] <jjohansen> its just working out a couple bugs
[17:13] <bjf> [TOPIC] Blueprints: kernel-lucid-boot-performance (apw, csurbhi)
[17:13] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance
[17:13] <MootBot> New Topic:  Blueprints: kernel-lucid-boot-performance (apw, csurbhi)
[17:13] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance
[17:13] <csurbhi1> csurbhi ..
[17:13] <apw> we have regressed some since we gained plymouth in the initramfs
[17:14] <apw> not sure if that is its final resting place yet, need to confirm with keybuk as to plan going forward
[17:14] <apw> .
[17:14] <apw> ..
[17:14] <bjf> [TOPIC] Other Release Tasks: Lucid Audio Support (bjf)
[17:14] <MootBot> New Topic:  Other Release Tasks: Lucid Audio Support (bjf)
[17:14] <bjf> Nothing new to report
[17:14] <bjf> ..
[17:14] <bjf> [TOPIC] Other Release Tasks: EC2 Lucid Kernel Status (jjohansen)
[17:14] <MootBot> New Topic:  Other Release Tasks: EC2 Lucid Kernel Status (jjohansen)
[17:14] <jjohansen> I need to finish an update to EC2 today
[17:15] <jjohansen> and include the missing patches dir
[17:15] <jjohansen> ..
[17:15] <bjf> [TOPIC] Status: Lucid (apw)
[17:15] <MootBot> New Topic:  Status: Lucid (apw)
[17:15] <apw> Be aware a bunch of work items have appeared out of the woodwork.  It seems that we were losing some foreign items in the burndown charts.  I will be reviewing those once the new charts are up and running correctly and will try and summarise those which appear new.
[17:15] <apw> We are just uploading a kernel update to <IP_ADDRESS> which also includes a bunch of patches from the mailing list.
[17:16] <apw> ..
[17:16] <bjf> [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb)
[17:16] <MootBot> New Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb)
[17:16] <smb> Dapper:     2.6.15-55.81 (security)
[17:16] <smb> Hardy:      2.6.24-26.64 (security)
[17:16] <smb> -LBM:       2.6.24-26.35 (proposed)[40]  0/ 1 verifications done
[17:16] <smb> -LUM:       2.6.24-26.44 (proposed)[40]  0/ 1 verifications done
[17:16] <smb> Intrepid:   2.6.27-16.44 (security)
[17:16] <smb> Jaunty:     2.6.28-17.58 (security)
[17:16] <smb> Karmic:     2.6.31-18.55 (proposed)[11]  4/12 verifications done
[17:16] <smb> -LBM:       2.6.31-18-20 (proposed)[11]  0/ 2 verifications done
[17:16] <smb> There is work going on for a security update on the kernel and on updating
[17:16] <smb> the Karmic kernel to <IP_ADDRESS>(final).
[17:16] <smb> We are now also get close to the cutoff date for Karmic SRU patches to the
[17:16] <smb> kernel. If there are upstream patches anybody wants to get SRU'ed into Karmic,
[17:16] <smb> make sure to send them to the kernel-team list before Feb-12.
[17:17] <smb> ..
[17:17] <bjf> [TOPIC] Incoming Bugs: Regressions (ogasawara)
[17:17] <MootBot> New Topic:  Incoming Bugs: Regressions (ogasawara)
[17:17] <ogasawara> Current regression stats (broken down by release):
[17:17] <ogasawara> == regression-potential (up 5) ==
[17:17] <ogasawara> 31 lucid bugs
[17:17] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-potential+lucid&field.tags_combinator=ALL
[17:17] <ogasawara> == regression-update (up 2)==
[17:17] <ogasawara> 9 karmic bugs
[17:17] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-update+karmic&field.tags_combinator=ALL
[17:17] <ogasawara> 5 jaunty bugs
[17:17] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-update+jaunty&field.tags_combinator=ALL
[17:17] <ogasawara> 2 intrepid bugs
[17:17] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-update+intrepid&field.tags_combinator=ALL
[17:17] <ogasawara> 1 hardy bug
[17:17] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-update+hardy&field.tags_combinator=ALL
[17:18] <ogasawara> == regression-release (up 2)==
[17:18] <ogasawara> 60 karmic bugs
[17:18] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-release+karmic&field.tags_combinator=ALL
[17:18] <ogasawara> 22 jaunty bugs
[17:18] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-release+jaunty&field.tags_combinator=ALL
[17:18] <ogasawara> 12 intrepid bugs
[17:18] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-release+intrepid&field.tags_combinator=ALL
[17:18] <ogasawara> 4 hardy bugs
[17:18] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-release+hardy&field.tags_combinator=ALL
[17:18] <ogasawara> == regression-proposed (no change)==
[17:18] <ogasawara> 1 karmic bug
[17:18] <ogasawara>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-proposed+karmic&field.tags_combinator=ALL
[17:18] <ogasawara> ..
[17:19] <apw> ogasawara, perhaps we could put all the links on the meeting page only, and just point one link there and just have the numbers
[17:19] <ogasawara> apw: sounds much saner to me.  will have Jfo do this next week.
[17:19] <JFo> yep
[17:19] <bjf> [TOPIC] Incoming Bugs: Bug day report (ogasawara)
[17:19] <MootBot> New Topic:  Incoming Bugs: Bug day report (ogasawara)
[17:20] <ogasawara> Just a gentle reminder if you have a few spare cycles today:
[17:20] <ogasawara> https://wiki.ubuntu.com/KernelTeam/BugDay/20100119
[17:20] <ogasawara> http://qa.ubuntu.com/reports/ogasawara/kernel-bugday/20100119.html
[17:20] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ogasawara/kernel-bugday/20100119.html
[17:20] <ogasawara> ..
[17:20] <bjf> [TOPIC] Open Discussion or Questions: Anyone have anything?
[17:20] <MootBot> New Topic:  Open Discussion or Questions: Anyone have anything?
[17:20] <bjf> ..
[17:20]  * ogasawara raises hand
[17:20] <bjf> ogasawara, go
[17:21] <ogasawara> We should have probably done this in the beginning, but I wanted to formally introduce JFo as our new Kernel QA/Triage person
[17:21] <JFo> O/
[17:21] <ogasawara> ..
[17:21] <apw> welcome aboard JFo
[17:21]  * apw heaps lots of work on you
[17:21]  * JFo would like to thank the Academy...
[17:21] <smb> Don't be too quick :)
[17:21] <JFo> heh
[17:22] <JFo> ..
[17:22] <bjf> anyone else have anything?
[17:22] <bjf> once ....
[17:22] <bjf> twice ....
[17:22] <bjf> thanks everyone
[17:22] <bjf> #endmeeting
[17:22] <MootBot> Meeting finished at 11:22.
[17:22] <cking> thanks bjf
[17:22] <apw> bjf, thanks
[17:22] <JFo> thanks bjf
[19:59] <czajkowski> Aloha :)
[20:00] <czajkowski> Anyone here for the LoCo Council meeting ..
[20:00] <cjohnston> o/
[20:02] <cjohnston> big crowd
[20:02] <czajkowski> I'll give it a few
[20:02]  * popey puts the dinner on simmer
[20:02] <czajkowski> Agenda is https://wiki.ubuntu.com/LoCoCouncilAgenda
[20:02] <popey> thanks czajkowski
[20:05] <czajkowski> popey: in case my net/irc dies can someone other than me chair this as I'm not sure how stable my connection is
[20:05] <popey> ok
[20:05] <huats> czajkowski, I am here too
[20:06] <czajkowski> huats: hey
[20:08] <huats> popey, what is a simmer ?
[20:08] <huats> (I am curious)
[20:08] <cjohnston> low basically
[20:08] <popey> low heat
[20:08] <popey> so it can stay there and not burn
[20:08] <cjohnston> keep it warm
[20:08] <huats> ok
[20:08] <huats> :)
[20:08] <huats> thanks for my knowledge :)
[20:10] <czajkowski> shall we start?
[20:10] <popey> ya
[20:11] <huats> just the 3 os us ?
[20:11] <huats> s/os/of/
[20:11] <czajkowski> JanC: itnet7: ping
[20:11] <huats> I mean from the council ?
[20:11] <czajkowski> seems to be for now
[20:12] <huats> ok
[20:12] <popey> yeah
[20:12] <popey> lets crack on
[20:13] <popey> ok, so lucid roadmap is first
[20:13] <popey> https://wiki.ubuntu.com/Roadmaps/Lucid/LoCoCouncil
[20:14] <popey> first thing was define a list of teams for re-approval
[20:14] <popey> thats done...
[20:14] <czajkowski> done  makes bacon happy :)
[20:14] <popey> do you have the link?
[20:14] <huats> :)
[20:14] <popey> https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:14] <czajkowski> https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:14] <popey> got it
[20:15] <popey> so basically all of those teams _except_ the ones approved in 2009
[20:15] <czajkowski> nods
[20:15] <huats> sounds good to me
[20:16] <popey> "OBJECTIVE: Define a list of teams that the LoCo Council can target for re-approval."
[20:16] <czajkowski> I have a rough mail drafted it needs to be looked over and tweeked
[20:16] <popey> done, yes?
[20:16] <czajkowski> DONE
[20:16] <popey> "OBJECTIVE: Re-approve an agreed set of LoCo Teams"
[20:16] <popey> in progress?
[20:16] <popey> i.e. we havent got to that yet, but will will real soon now!
[20:16] <huats> yep
[20:16] <popey> cool
[20:17] <popey> "OBJECTIVE: Better implement and document the re-approval process"
[20:17] <popey> https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval  has that
[20:17] <popey> shall we say "In progress" until we have mailed loco-contacts and let everyone pick it apart?
[20:17] <huats> sounds at like in progress to me
[20:17] <huats> agreed
[20:17] <czajkowski> ok
[20:18] <popey> "OBJECTIVE: Improve awareness of the LoCo team re-approval process."
[20:18] <popey> same :)
[20:18] <huats> :)
[20:18] <jono> sorry I am late
[20:18] <huats> (+1)
[20:18] <popey> once the mail goes to loco-contacts.. we can blog it perhaps?
[20:18] <popey> np jono
[20:18] <huats> mister jono you are forgave
[20:18] <czajkowski> popey: aye and get it on the fridge?
[20:18] <jono> huats, lol
[20:18] <jono> :)
[20:19] <huats> popey, I do agree also on the blog post
[20:19] <popey> czajkowski: yup, if we agree the mail (in a bit - next item)
[20:19] <popey> we can then blog and fridge it!
[20:19] <popey> then we can consider it DONE :)
[20:19] <popey> so right now, In progress with a view to being done very very soon
[20:20] <popey> happy?
[20:20] <czajkowski> delighted!
[20:20] <jono> :)
[20:20] <popey> czajkowski: will you be ok to update the status on the blueprints at the end of the meeting?
[20:20] <czajkowski> yes will do
[20:20] <popey> win!
[20:20] <jono> what was the current status on the teams?
[20:20] <jono> for re-approval :)
[20:20] <czajkowski> most are inprogres
[20:20] <czajkowski> and will be done by end of week
[20:20] <popey> jono: we havent mailed any yet
[20:21] <popey> the 1.2.3 is this..
[20:21] <czajkowski> thats on the to do list this week
[20:21] <jono> can I suggest they are broken up over the cycle
[20:21] <jono> the teams on https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans
[20:21] <popey> 1. we mail loco contacts with a mail which czajkowski has drafted
[20:21] <popey> 2. we mail the teams on that list
[20:21] <popey> well, some of them?
[20:21] <popey> first 5-10?
[20:21] <popey> 3. ???
[20:21] <popey> 4. Profit!
[20:22] <czajkowski> grin
[20:22] <czajkowski> ah yes that's what I wanted to clarify
[20:22] <jono> popey, czajkowski I recommend you break the cycle up into weeks
[20:22] <jono> and then spread them out and then it doesnt feel like too much work
[20:22] <czajkowski> popey: re approval does that take place in meeting, or on emaik ?
[20:22] <jono> make sense?
[20:22] <czajkowski> jono: aye it does, there are 30 teams and 6 of us, so we had hoped to break it down a bit already
[20:23] <jono> czajkowski, indeed
[20:23] <popey> I'm happy to go with that, yes
[20:23] <jono> I would recommend as an output from this session that you divide it into week, spread the teams out and allocate them to council members
[20:23] <popey> suggestions on breaking up the list? just grab 5 at a time?
[20:23] <jono> if they are not allocated, the cynical side of my brain thinks they may not be done :-)
[20:23] <popey> ok, after the meeting I'll split the list up and allocate
[20:23] <jono> popey, yeah, I don't think the order matters
[20:23] <jono> popey, rock and roll
[20:24] <popey> we need to update the list on the blueprint
[20:24] <popey> we have a list on the wiki which is "better", we need to add that back
[20:24] <popey> will do that once divided up
[20:24] <popey> anything else on the topic of re-approvals?
[20:24] <jono> thanks popey
[20:24] <czajkowski> popey: I had thought just go 1,2,3..6 and repeat going through the list
[20:24] <jono> one final thing
[20:24] <czajkowski> avoding each council members loco
[20:25] <jono> you should check progress of the current allocated teams in each meeting
[20:25] <jono> will help identify blockers :)
[20:25] <huats> I agree with czajkowski
[20:25] <popey> yes
[20:25] <popey> we have a table on the wiki to track progress
[20:25] <popey> https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:25] <popey> maybe we should just move that to the blueprint? and track it there?
[20:26] <popey> the wiki gives better formatting
[20:26] <jono> wiki is fine, just updated outcomes on the BP
[20:26] <jono> such as approved or rejected
[20:26] <popey> ah, ok
[20:26] <czajkowski> ah you mean the locos
[20:26] <czajkowski> I see
[20:26] <czajkowski> you want them updated on the BP also ?
[20:26] <popey> just the overall end result czajkowski
[20:26] <popey> not the ongoing communication status
[20:26] <czajkowski> ok
[20:27] <popey> that right jono?
[20:27] <jono> yep
[20:27] <jono> then BP subs can see the general progress
[20:27] <popey> cool
[20:28] <popey> so can we look at the mail laura wrote and just give a yay/nay to sending that to loco contacts?
[20:28] <huats> ok it was not my understanding but it great too
[20:28] <huats> (I mean the usage of the BP)
[20:29] <popey> the usage of BP is just to let jono keep track on us ;)
[20:29] <popey> I dont mind updating that from the wiki myself
[20:29] <jono> :)
[20:29] <popey> http://etherpad.com/DWoSGJB7cy  is the mail we should be sending to loco-contacts to let them know we are re-approving
[20:30] <popey> jono: / huats ^ click
[20:30]  * jono reads
[20:30] <huats> popey, I read it this morning it is good to me
[20:30] <popey> oh, cool!
[20:31] <jono> perfect :)
[20:31] <jono> great work czajkowski :-)
[20:31] <popey> win
[20:32] <popey> https://wiki.ubuntu.com/LoCoCouncilAgenda
[20:32] <popey> nothing else on the agenda
[20:32] <jono> maybe we can get the list of teams for reapproval hammered out?
[20:32] <jono> before we do that
[20:32] <jono> can I follow up on a few actions in the blueprint?
[20:33] <jono> [popey] Make sure all approved teams on the wiki teams list are in the locoteams-approved Launchpad team: TODO
[20:33] <popey> DONE
[20:33] <jono> [effie-jayx] Determine the list of teams that are in locoteams-approved that have not been through the re-approval process: TODO
[20:33] <popey> DONE, on the wiki and in the BP
[20:33] <jono> [popey] Assign re-approvals across the council members: TODO
[20:33] <popey> thats the list we have at https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:33] <popey> that one I will do tonight
[20:34] <popey> after this meeting
[20:34] <jono> cool
[20:34] <jono> [popey] Document how a council member performs the re-approval process: TODO
[20:34] <popey> DONE
[20:34] <popey> https://wiki.ubuntu.com/Roadmaps/Lucid/LoCoCouncil
[20:34] <jono> [dpm] Invite translators to translate the overview document into different languages: TODO
[20:34] <jono> I will assign dpm to this
[20:34] <jono> hmm
[20:34] <jono> one sec
[20:34] <jono> on:
[20:34] <jono> [popey] Document how a council member performs the re-approval process: TODO
[20:34] <popey> sorry, https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:34] <jono> I would not say the roadmap is really documentation
[20:34] <jono> ahh!
[20:34] <popey> posted wrong url
[20:35] <jono> great
[20:35] <jono> [popey] Write up blog entries to explain how the process works and why: TODO
[20:35] <popey> todo after the mail has gone to loco-contacts
[20:35] <popey> i expect some mails back and forth about it
[20:35] <popey> so blogs would follow based on feedback from loco contacts
[20:35] <czajkows1i> bah
[20:36] <jono> ok cool, popey, can you go and mark the ones that are DONE as DONE
[20:36] <huats> popey, I think it is a good choice to wait for the first exchanges
[20:36] <jono> on https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans
[20:36] <czajkows1i> jono: I'm in the middle of edting that now
[20:36] <jono> thanks czajkows
[20:36] <popey> yay
[20:36] <popey> i am on sucky 3g at the moment
[20:36] <jono> popey, np :)
[20:36] <czajkows1i> popey: my net died again
[20:37] <czajkows1i> popey: did you see my two questions re In progress??
[20:37] <popey> n o
[20:37] <jono> awesome, thanks folks
[20:37] <jono> I have to run to catch a plane
[20:37] <jono> speak to you in a bit
[20:37] <popey> fly jono fly!
[20:37] <jono> great work, you are rocking the LoCo Council!
[20:37] <czajkows1i> jono: toodles
[20:37] <czajkows1i> 20:32 < czajkowski> popey: am I right in say so [popey] Assign re-approvals across the council members: INPROGRESS
[20:37]  * jono all smiles :)
[20:37] <huats> enjoy your trip
[20:37] <czajkows1i> 20:33 < czajkowski> and Document how a council member performs the re-approval process: INPROGRESS
[20:37] <jono> thanks folks!
[20:38] <popey> first one yes, second one done
[20:38] <popey> the second one is effectively what we have on https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[20:38] <czajkows1i> any updates on
[20:38] <czajkows1i> [popey] Make sure all approved teams on the wiki teams list are in the locoteams-approved Launchpad team: TODO
[20:38] <czajkows1i> [effie-jayx] Determine the list of teams that are in locoteams-approved that have not been through the re-approval process: TODO
[20:39] <popey> first is done
[20:39] <popey> second done
[20:39] <huats> guys the French team is not on the reapproval list,is it normal ?(I think I have already asked that but I forgot the answer)
[20:39] <czajkows1i> blue print is looking good now :D
[20:41] <popey> huats: its fine, there are lots that are not on the list
[20:41] <popey> we just picked 30 at random
[20:41] <popey> you were lucky this time :)
[20:41] <czajkows1i> so I've a quick question
[20:41] <popey> go
[20:41] <huats> popey, ok
[20:42] <czajkows1i> when we send out the mails to the LoCo for reapproval
[20:42] <popey> ya
[20:42] <czajkows1i> do we send it to the point of contact on launchpad ?
[20:42] <popey> yes
[20:42] <czajkows1i> grand
[20:42] <czajkows1i> tick
[20:42] <huats> popey, next time I see you, you'll get a drink for the good choice
[20:42] <popey> if you like.. i can fill the table with points of contact
[20:42] <popey> huats: effie chose, not me :)
[20:42] <popey> but I'll have his drink anyway :)
[20:42] <czajkows1i> popey: if you have to do it manually, then no
[20:42] <popey> czajkows1i: i want to make te list easy
[20:43] <popey> by linking to lp page, wiki page etc
[20:43] <popey> just like when we have a meeting
[20:43] <huats> popey, the council member will do it by him(her)self...
[20:43] <popey> true
[20:43] <popey> good idea
[20:43] <czajkows1i> aye I think that's best
[20:43] <czajkows1i> I just want it for the email for locoteams
[20:43] <huats> ok
[20:43] <popey> i think we might need to be careful who we contact
[20:44] <huats> indeed
[20:44] <popey> perhaps also look at the administrator of their mailman lists?
[20:44] <popey> because (for example) the contact for the uk team isn't the admin of the lp team
[20:44] <popey> although the loco team list page does list the contact for each team...
[20:44] <czajkows1i> aye
[20:44] <popey> ah, we'll worry about that when we get bounces ;)
[20:45] <czajkows1i> should we also add a column to note when we made contact on the wiki ?
[20:45] <popey> thats kinda what the "status" column is for
[20:45] <huats> czajkows1i, good idea
[20:45] <popey> free text to show what's been done
[20:45] <huats> ok
[20:45] <popey> sorry, not status, progress
[20:45] <czajkows1i> ah ok so I can add mail sent DATE
[20:46] <czajkows1i> ok
[20:46] <popey> yeah
[20:46] <huats> +1
[20:46] <popey> 2nd mail sent, DATE..
[20:46] <popey> 3rd mail sent, date..
[20:46] <huats> yep
[20:46] <popey> etc
[20:46] <czajkowski> ok I think that;s all of the headings covered on the agenda so
[20:46] <czajkowski> bp, roadmap and reapproval.
[20:46] <popey> anything else you can think of we need to talk about czajkowski / huats ?
[20:47] <huats> popey, nope
[20:47] <czajkowski> ye
[20:47] <czajkowski> yes
[20:47] <popey> ooo
[20:47] <czajkowski> todays email to the loco teams list
[20:47] <huats> yep
[20:47] <popey> yup
[20:47] <huats> you are right
[20:47] <huats> :)
[20:47] <popey> what about it?
[20:47] <czajkowski> how many contacts are required per team
[20:48] <czajkowski> > Recently we have created the Ubuntu Colombian Council in order to divide
[20:48] <czajkowski> > > responsabilities in the administration. We currently have 5 members of the
[20:48] <czajkowski> > > council, including myself, the LoCo contact.
[20:48] <czajkowski> > >
[20:48] <czajkowski> > > At the last meeting of the council they asked me that which scenario
[20:48] <czajkowski> > > may delegate more than a LoCo conctact? under which circumstances?
[20:48] <czajkowski> > > or if it exist some restriccion to have more than one official contact per
[20:48] <czajkowski> > > team. I have no found an answer so I ask the question here in the list.
[20:48] <czajkowski> I don't know if there is an official answer to this but my personal
[20:48] <czajkowski> view is that a LoCo contact should be an individual as the whole point
[20:48] <czajkowski> of the role is to have an individual who can be contacted when
[20:48] <czajkowski> necessary. I believe that not every local team does things this way
[20:48] <czajkowski> now while it;s a bit early to vote/come to agreement I thought we could discuss it if we had a few mins
[20:48] <czajkowski> though. It would be quite good to have the LoCo Council clarify the
[20:48] <czajkowski> issue.
[20:49] <popey> i think each team should run as it sees fit, but ensuring that it's possible to contact someone
[20:49] <popey> huats: french team is big right? Do you have exactly one person who is the contact for the team?
[20:49] <huats> from my point of view, there no common rules, and each team can run as it want
[20:50] <czajkowski> it seems many locos operate so differnetly, some have just a point of contact (Ireland) others have teams , management and councils
[20:50] <huats> popey, actually we are quite big
[20:50] <czajkowski> huats: really you don't say 5000 people at a release party!
[20:50] <popey> :)
[20:50] <huats> :)
[20:50] <popey> i dont think we should dictate this
[20:50] <popey> each team has cultural differences and background
[20:50] <popey> some prefer one contact person, some like a team
[20:50] <huats> we have a many lists for different actions
[20:50] <czajkowski> thats what I thought and seeing as the mail came in today from Mathew East I thought I'd bring it up in here
[20:50] <popey> whatever works best for them
[20:50] <huats> we have a few contacts currently on the wiki page
[20:51] <huats> but on our website (for the french people) we point a few (3 IIRC)
[20:51] <popey> it makes sense in terms of volunteers to have multiple people
[20:51] <popey> because people get
[20:51] <popey> * get busy, go on holiday etc
[20:51] <huats> exactly...
[20:52] <czajkowski> nods
[20:52] <popey> so long as it doesnt lead to confusion or lack of communication between members of the "leadership"
[20:52] <czajkowski> makes sense
[20:52] <huats> popey, that is the idea..
[20:52] <popey> happy with that czajkowski ?
[20:53] <czajkowski> happy as larry!
[20:53] <czajkowski> Ddorda: do you want to say something?
[20:53] <Ddorda> czajkowski: sure
[20:53] <Ddorda> we have a problem in our LoCo in the way things are going
[20:54] <Ddorda> the LoCo leaders are the owners of the LoCo, and there's is no discussion about anything with the community
[20:54] <czajkowski> Ddorda: I know you;ve mentioned this in -locoteams, but you may need to explain it to huats and to popey
[20:55] <Ddorda> czajkowski: okay
[20:55] <huats> czajkowski, I have read the email but it is always good to hear again
[20:55] <popey> I am going to have to disappear and come back later..
[20:55] <Ddorda> there was 2 LoCo leaders so far, Shezif and Beni. Beni wasn't active for about 2 years
[20:55] <Ddorda> and Shezif was being the only owner of the community
[20:56] <popey> czajkowski / huats I will action the items in a bit, when my connection is back
[20:56] <czajkowski> popey: grand
[20:56] <huats> popey, ok
[20:56] <Ddorda> if someone had an idea to imporve the community that he didn't like, he just said no, and if you were trying to do it anyway you got banned
[20:56] <czajkowski> Ddorda: see there is no owner of a community
[20:56] <Ddorda> czajkowski: well, he is the owner, notthe LoCo leader
[20:57] <Ddorda> as should be
[20:57] <huats> Ddorda, how can he be the "owner" of the community ?
[20:57] <huats> what do you mean ?
[20:58] <Ddorda> huats: he do w/e he wants, it's more Shezif's Community about Ubuntu than an Israeli LoCo
[20:58] <huats> ok
[20:58] <Ddorda> for ex. he made a project with an university in the south
[20:58] <huats> Ddorda, it is not really the idea of an Ubuntu LoCo we want to push
[20:59] <Ddorda> didn't tell anything about us until maybe an half month before it
[20:59] <huats> (from my point of view)
[20:59] <Ddorda> huats: I knowm that is my complaint
[20:59] <czajkowski> Has you loco had a meeting and tried to talk to him , possibly showing and discussing the leadership role http://www.ubuntu.com/community/leadership-conduct
[21:00] <Ddorda> czajkowski: I tried to organize a meeting as you suggested, but there was no response, I belive it went down in the forums before anyone saw it
[21:00] <Ddorda> anyway, for now he chose 2 new managers
[21:00] <Ddorda> because he's going to the army
[21:01] <czajkowski> Ddorda: can you clarify, your LoCo holds all it's meetings on forums ??
[21:01] <czajkowski> do you have any IRC meetings?
[21:01] <czajkowski> make your minutes public and send to your mailing list
[21:01] <Ddorda> czajkowski: no. the managers have discussions on the managers forum
[21:02] <czajkowski> that's not very open or ideal
[21:02] <Ddorda> and yes, only forums meetings
[21:02] <czajkowski> huats: what do you think ?
[21:02] <Ddorda> the chat is for support (as much as the forums are)
[21:03] <huats> czajkowski, I agree
[21:03] <huats> czajkowski, IRC meeting a really for discussion
[21:03] <mhall119|work> Ddorda: would the members be willing and able to do an IRC meeting?
[21:03] <huats> czajkowski, Ddorda IRC meeting are almost needed for discussion
[21:03] <czajkowski> Ddorda: I think the loco council will most likely contact the loco team and see if they will talk over email with us, possibly an irc meeting
[21:04] <Ddorda> mhall119|work: I guess so, but time should be choosed, and Im not sure if i;m supposed to ask in the forums what os the best time, or just give a date and hour
[21:04] <czajkowski> Ddorda: thanks for bringing this up
[21:04] <Ddorda> huats: there is no discussion between the community and the managers
[21:04] <czajkowski> I might do a blog post on suggestions to help locos do certain things, while they are not mandatroy they are best case examples
[21:04] <Ddorda> they manage and they ask for supoort or write guides. that's how it works
[21:05] <huats> Ddorda, I think the time will be choose by the council and the contacts
[21:05] <czajkowski> in the mean time, the loco council will discuss and drop the israel team an email, ok ?
[21:05] <huats> czajkowski, agreed
[21:05] <czajkowski> Ddorda: is that ok?
[21:05] <czajkowski> as I'd like more people present for the discussion if possible.
[21:05] <mhall119|work> would someone from the LC moderate an IRC meeting if one is held?
[21:05] <Ddorda> czajkowski: sure. btw, one of the new managers is very open thinking, and I beliebe he will help you
[21:06] <Ddorda> called Akiva
[21:06] <huats> czajkowski, may be we can proceed that by email in the LC
[21:06] <czajkowski> Ddorda: ok, thank you
[21:06] <czajkowski> huats: yes
[21:06] <Ddorda> mhall119|work: I guess so
[21:06] <czajkowski> Does anyone elese have any other loco council issues?
[21:07] <mhall119|work> I have a request of the lc
[21:07] <czajkowski> mhall119|work: shoot
[21:07] <mhall119|work> http://growingupfree.org:8000/ is the upcoming changes to the loco directory
[21:07] <mhall119|work> with event tracking
[21:07] <czajkowski> <3 event tracking :D
[21:08] <mhall119|work> since LC members have the magical ability to add/manage global events, your help in testing it would be much appreciated
[21:08] <mhall119|work> that's all
[21:08] <mhall119|work> and thanks
[21:08] <czajkowski> so you;'d like the 6 of us to go and have a play with it and let you know how it goes
[21:08] <czajkowski> ok
[21:08] <czajkowski> :)
[21:08] <czajkowski> mhall119|work: thank you for your work on this
[21:08] <czajkowski> and to the others
[21:08] <czajkowski> I for one am thrilled for such a feature
[21:09] <huats> mhall119|work, may be send an email to the LC ...
[21:09] <czajkowski> mhall119|work: would you mind also dropping us an email
[21:09] <mhall119|work> sure, what's the address?
[21:09] <czajkowski> but I'll poke folks also about it
[21:09] <czajkowski> loco-council<at>lists.ubuntu.com
[21:09] <czajkowski> :)
[21:10] <czajkowski> ok well if that's it
[21:10] <mhall119|work> cool, it'll have to wait until I get home, smtp is blocked here at work
[21:10] <czajkowski> I think we'll call the meeting to an end
[21:10] <czajkowski> Thanks folks for coming and taking part
[21:10] <huats> thanks czajkowski
[21:10] <huats> and everyone else
[21:10] <mhall119|work> thank you
[22:47] <czajkowski> yes


 valorie: Yep, I have a passport :)
 I just need to write an email to the KC asking- unless anyone else from Kubuntu would like to go. For example, I'd give up my seat for Rik
 I can do something remotely, but I can't get over their for those dates. Happy to support Simon of course
 I won't be able to go (re @tsimonq2: I just need to write an email to the KC asking- unless anyone else from Kubuntu would like to go. For example, I'd give up my seat for Rik)


[14:14] <dekatch> hi, i am currently banned on #ubuntu due to some verbal insults i suppose even tho they were in pm's as far as i remember and i would like to know if that ban can be lifted
[14:16] <dekatch> even got the backlog here on hexchat. so i got banned by bazhang as it seems. and i first got quited due to some cursing against some company. but now it seems i am banned without any further actions on my side
[16:12] <hggdh> @mark #ubuntu-ops dekatch returned with no memory of what happened
[17:00] <hggdh> Pici: ^ I cannot @mark?
[17:00] <Pici> eh?
[17:02] <Pici> hggdh: ubottu was rebooted recently, make sure that it still recognizes you (use @login)
[17:15] <dax> hggdh: once you're logged in, "/msg ubottu hostmask add *!*@ubuntu/member/hggdh" may be useful
[17:15] <dax> tends to cut down on ubottu randomly deciding you're not logged in
[17:16] <hggdh> ack, thank you
[17:16] <hggdh> @login
[17:16] <hggdh> @btlogin
[17:16] <dax> (that command is from memory, lmk if i typo'd it but we need to do similar for staff stuff so i think it's right)
[17:21] <hggdh> dax: works with an "@hostmask ...". Otherwise ubottu (1) complains it is not intelligent, and (2) states "The operation succeeded"
[17:22] <dax> ah, right. thx.
[17:24] <hggdh> anyway...
[17:24] <hggdh> @mark #ubuntu-ops dekatch returned with no memory of what happened
[17:25] <hggdh> ah. sehr gut
[17:44] <Pici> dax: thanks


[10:36] <LinDol> hi all
[10:58] <LinDol> hello i am korean, any one, could explain to me about what different "give A B" and "give A to B" ?
[10:59] <LinDol> is this having same meaning?
[11:00] <LinDol> oh sorry, "give A B" and "give B to A"
[11:14] <LinDol> oh I found it on google :)
[11:25] <pchoo> well that was on topic...


[08:57] <psivaa> cjwatson: xnox: ogra: Raring server installations fail with 'linux-server : Depends: linux-generic (= <IP_ADDRESS>.33) but it is not going to be installed'. Although, it was possible to install this version of the kernel with 20130412.1. But the later versions of d-i fail (again) for the same kernel version.
[09:01] <psivaa> the d-i failed first with this kernel version on 20130412, came back to installable with 20130412.1 but then started failing with 20130413
[09:02] <ogra_>  linux 3.8.0-18.28 was uploaded on thursday
[09:06] <psivaa> ok, the second set of images (20130412.1) were installing <IP_ADDRESS>.33 on Friday though
[09:24] <cjwatson> jetole: use 'tasksel tasksel/skip-tasks string standard' to avoid the default installation of the standard task
[09:24] <cjwatson> psivaa: yeah, after leaving to be entirely away from computers from the weekend I realised I'd forgotten to update seeds
[09:24] <cjwatson> hmm, but my debian-installer change didn't reach raring yet.  I'll have to investigate
[09:31] <psivaa> cjwatson: ok, thanks. was confused not knowing .17.33 having a short stay in the archive
[09:34] <cjwatson> psivaa: I think I've now properly fixed the cdimage problem where it was incorrectly building against -proposed
[09:35] <cjwatson> psivaa: but the right fix is to get the new d-i in, so I'll see about that this morning
[09:42] <psivaa> cjwatson: ack


[23:23] <papamoose1> Anyone know what the package name for the 'first run wizard' (no idea what its called) that launches when you boot up a machine preinstalled with ubuntu?
[23:35] <maxb> I do not, but I'd guess the name would start with 'oem-'
[23:36] <maxb> oem-config seems possible
[23:58] <cjwatson> ubiquity is the source package
[23:58] <cjwatson> it used to be oem-config (and that's still the binary package) but they were merged, so for the purposes of bugs you want ubiquity


[07:03] <n0p_> damn, just got bit by a combination of `unattended-upgrades`, a prod server missing a pin, and http://www.ubuntu.com/usn/usn-2881-1/
[07:03] <n0p_> unattended-upgrades just restarted a prod mysql instance ;_;
[07:05] <n0p> (takes 20 min to restart a mysql server with our load)
[11:59] <cscheib_> n0p: ouch
[13:37] <cmaloney> n0p: Ugh
[13:50] <rick_h_> good news is it's back up? :)
[13:52] <jrwren> wow, 20min sql server restarts?!? wtf? what would cause that? Locks?
[14:35] <n0p> jrwren: even on a clean shutdown, it still needs to look at every db/table for some strange reason
[14:36] <n0p> mind you we have thousands of DBs each with >hundred tables
[14:37] <jrwren> with many TPS?
[14:37] <jrwren> zomg, I just asked for TPS report.
[14:39] <n0p> NR reports ~5k/queries per second, not sure how many are writes
[14:42] <jrwren> still, that is enough to make slowness understandable.
[14:42] <jrwren> sounds like a fun problem to solve! :)
[14:42] <n0p> it's pretty smooth right now as long as we move traffic *before* a db restart
[14:43] <n0p> honestly, the system fails gracefully, it's just annoying to shuffle in the middle of the night
[16:47] <cmaloney> blergh
[16:48] <rick_h_> that good eh?
[16:51] <cmaloney> It's fun to play with production systems that are akin to magic boxes that nobody wants to offend.
[16:52] <cmaloney> Lest they incur wrath and stop performing.
[16:52] <rick_h_> hah
[16:52] <rick_h_> yea, the whole 'production is not like anything else' is the 'someone please kill me' of the world
[16:52] <rick_h_> which jrwren knows even we deal with :P
[16:53] <cmaloney> Well, we're using a platform which folks don't quite understand
[16:53] <rick_h_> always helpful
[16:53] <cmaloney> which apparently has a hang-up when you create two IDs that match
[16:53] <cmaloney> and we're not sure how to clear out data in there
[16:54] <cmaloney> for an eventual "go-live"
[16:54] <cmaloney> which from my perspective is rather broken if the answer isn't "truncate that mo-fo"
[16:55] <cmaloney> So I have no less than three different ways to denote that this record is indeed "test"
[16:55] <cmaloney> because adding a new field is easier than bending a system to our will.
[16:55] <rick_h_> hah
[16:56] <cmaloney> and previous system used integers, so appending "test" does bad things.
[16:56] <cmaloney> prepending rather
[16:56] <jrwren> we are dealing with it right now exactly... even though staging is almost exactly like production... it still doesn't have teh load that production has. We almost need something to put load on staging similar to the load production has.
[16:56] <cmaloney> And they wonder why I listen to angry music and drink coffee
[16:56] <cmaloney> because I can't drink on the job.
[16:56] <jrwren> so really... its almost always true, production is not like anything else.
[16:57] <rick_h_> jrwren: yea, interesting there though. We could 'simulate' load by just mirroring apache logs over to production with a diff charm watching that
[16:57] <rick_h_> jrwren: that'd be interesting to try out sometime
[16:57] <rick_h_> near real-time duplication with a url rewrite rule and curl
[17:00] <jrwren> rick_h_: something to watch the logs and create the same requests?  yeah, that would be awesome.
[17:00] <jrwren> rick_h_: gets a little more tricky with http bodies for POST/PUT requests
[17:00] <rick_h_> jrwren: true enough
[17:01] <rick_h_> jrwren: just an interesting replay idea, you're right that it's not that simple
[17:01] <jrwren> rick_h_: would make a SWEET cross model charm
[17:01] <rick_h_> jrwren: :)
[17:02] <cmaloney> https://plus.google.com/+CarlosSanchezMusic4Life/posts/J26drRFDfob
[17:07] <mrgoodcat> what time is chc tonight?
[17:07] <rick_h_> mrgoodcat: 7pm
[17:08] <mrgoodcat> thanks
[17:08] <rick_h_> np
[17:08] <mrgoodcat> think i might make it tonight
[17:08] <mrgoodcat> i hope
[17:08] <mrgoodcat> haven't been in months
[17:08] <rick_h_> party
[17:10] <cmaloney> Sweet
[17:12] <rick_h_>  /join #snappy
[17:12] <rick_h_> doh
[17:12] <cmaloney> heh
[17:13] <mrgoodcat> at least its just a leading space. i frequently type bash commands into my irc client
[18:06] <ColonelPanic001> I hate when I do sql in the terminal
[18:06] <ColonelPanic001> after having done db stuff for a while
[18:06] <ColonelPanic001> instead of ls I start typing "select" and just stop and feel bad
[18:07] <jrwren> select * from files;
[18:09] <ColonelPanic001> where the_one_i_need = 1;
[18:10] <jrwren> i don't pipe ls to grep very often
[18:40] <mrgoodcat> i do
[18:41] <mrgoodcat> anybody know how you would disable usb except for keyboards?
[19:07] <n0p> s/keyboards/keyboard/ + superglue :-P
[19:08] <n0p> mrgoodcat: https://github.com/dkopecek/usbguard ? no recommondation, just googled
[19:10] <n0p> found via query: https://www.google.com/search?q=whitelist%20usb%20devices%20with%20dbus
[19:34] <cmaloney> mrgoodcat: I'm curious what you're attempting? :)
[19:35] <cmaloney> One theory: Make it so the USB key can't be removed once inserted
[19:36] <cmaloney> eg: some physical clamp. :)
[19:38] <mrgoodcat> cmaloney: http://grizzhacks.com
[19:38] <jrwren> mrgoodcat: modern windows kernels have group policy which can do it. are you asking on linux?
[19:39] <mrgoodcat> one project idea was to make a door lock that uses yubikey as the key
[19:39] <mrgoodcat> but the problem is that USB isn't really somethign we want to expose to the outside world
[19:39] <mrgoodcat> jrwren: yea would likely run on a raspberry pi zero
[19:39] <jrwren> mrgoodcat: remove all usb kernel modules except hsb_hid
[19:39] <jrwren> *usb_hid
[19:39] <jrwren> that should get you to KB/Mouse only
[19:39] <mrgoodcat> i guess that's reasonable
[19:40] <mrgoodcat> i was thinking there was probably a way to do it with modprobe but removing the drivers sounds simpler
[19:42] <cmaloney> Not sure that would prevent an attack though
[19:42] <cmaloney> just reduce the overall footprint
[19:43] <mrgoodcat> right because you still have to prevent problems that can be caused with the keyboard
[19:43] <mrgoodcat> catching signals is the obvious thing
[19:43] <mrgoodcat> but you have to make sure there's no way to shell out
[19:44] <jrwren> you could write some dbus module to bind first inserted kb and ignore all other usb ids
[19:44] <mrgoodcat> run the program under a user with no shell is also obvious
[19:46] <mrgoodcat> the other idea was to make the brain an arduino and just implement only the functionality we need
[19:46] <mrgoodcat> greatly reduced attack surface
[19:48] <mrgoodcat> also greatly improved lifespan on the battery backup in case of power failure
[19:49] <cmaloney> Yeah, that's a better approach
[19:49] <cmaloney> have the Arduino communicate with the RPi
[19:49] <cmaloney> That way the Arduino presents a flattened surface and communicates in a secure way with the RPi
[19:51] <mrgoodcat> well it would elminate the rpi
[19:51] <mrgoodcat> once you have an arduino the rpi doesn't have a need
[20:03] <cmaloney> Au contraire
[20:03] <cmaloney> the RPi serves the internet connectivity need. ;)
[20:04] <cmaloney> because having your door lock as a hacking target is the goal. ;)
[20:04] <jrwren> i never grocked the whole paring arduino and rpi
[20:05] <jrwren> i'd always use one
[20:05] <jrwren> if I need inet, i'd use an rpi and no arduino
[20:06] <mrgoodcat> cmaloney: ha that does appear to be the goal
[20:15] <cmaloney> Today is when I wish I wasn't afraid of clowns so I could have joined the circus.
[20:15] <cmaloney> jrwren: Arduino is great for analog data entry
[20:15] <cmaloney> and certain shields work better on ARduino
[20:15] <jrwren> isn't rpi GPIO good for analog?
[20:16] <cmaloney> so it can do the data collection and send the input to the RPi proper
[20:16] <jrwren> ah, so part availability, that makes sense
[20:25] <mrgoodcat> and the rpi is easier to actually process the data on
[20:26] <mrgoodcat> for this particular application though i think the arduino will be sufficient
[20:35] <cmaloney> But it makes it less interesting. :)
[20:35] <mrgoodcat> i'd argue that it makes it more interesting
[20:46] <jrwren> i can imagine processing data on an arduino being very limited
[20:52] <mrgoodcat> eh well obviously you're memory limited
[20:52] <mrgoodcat> but a yubikey isn't exactly a ton of data
[20:52] <mrgoodcat> and you have to write everything in c afaik
[20:53] <mrgoodcat> and you want to watch out for external dependencies in libraries and whatnot
[20:53] <mrgoodcat> the real problem is data storage though. arduino doesn't have persistent storage for programs afaik
[20:59] <jrwren> slow clock is what I was thinking.
[21:00] <mrgoodcat> oh like it would process too slowly
[21:02] <mrgoodcat> I don't see that being a problem with aes (the encryption used by the yubikey)
[21:19] <cmaloney> AES is supposed to be gentle on the CPU
[21:19] <cmaloney> at least it shows up a lot in hardware-based crypto
[21:20] <jrwren> for some definition of gentle, but aren't a lot of arduinos like 1Mhz?
[21:21] <jrwren> 1Mhz 8bit at that, so to do AES with it its gonna take many clocks to do 256bit math
[21:21] <mrgoodcat> 128 bit key
[21:21] <mrgoodcat> for yubikey
[21:22] <mrgoodcat> 32 bytes of encrypted data
[21:22] <mrgoodcat> the crypto++ library requires 16 cycles per byte plus 1041 to set up the key
[21:23] <mrgoodcat> so 512 cycles for the decryption
[21:23] <mrgoodcat> 1553 total including key setup
[21:23] <mrgoodcat> obviously that's on a 64 bit system though so it's easier to do the math
[21:24] <mrgoodcat> as long as the decryption time is under a quarter of a second though i doubt it would be bothersome
[21:40] <cmaloney> https://github.com/DavyLandman/AESLib
[21:41] <cmaloney> Not sure if yubikey is 128bit
[21:42] <cmaloney> There's another library that will handle 128 - 256bit
[21:42] <cmaloney> http://forum.arduino.cc/index.php?topic=88890.0
[22:00] <jrwren> cool
[23:05] <mrgoodcat> yubikey is 128
[23:05] <mrgoodcat> already got that cloned down to play with heh
[23:06] <mrgoodcat> fun fact of the day: sending a string to an arduino to be decrypted and reading the result back is in fact _not_ the fastest way to decrypt aes encrypted data
[23:07] <mrgoodcat> it's actually not as slow as you might think though
[23:48] <gamerchick02> cmaloney, guess who just got a pebble time round?