[00:00] <udsbotu> uds-gb-h: This session has ended.
[00:08] <SpamapS> o/
[00:10] <SpamapS> everybody knows Al Gore invented the cloud
[00:21] <SpamapS>  _________________________________________
[00:21] <SpamapS> / I typed juju deploy wordpress and all I \
[00:21] <SpamapS> \ got was this burning sheep              /
[00:21] <SpamapS>  -----------------------------------------
[00:21] <SpamapS>   \            .    .     .
[00:22] <SpamapS>    \      .  . .     `  ,
[00:22] <SpamapS>     \    .; .  : .' :  :  : .
[00:22] <SpamapS>      \   i..`: i` i.i.,i  i .
[00:22] <SpamapS>       \   `,--.|i |i|ii|ii|i:
[00:22] <SpamapS>            UooU\.'@@@@@@`.||'
[00:22] <SpamapS>            \__/(@@@@@@@@@@)'
[00:22] <SpamapS>                 (@@@@@@@@)
[00:22] <SpamapS>                 `YY~~~~YY'
[00:22] <SpamapS>                  ||    ||
[00:24] <SpamapS> chroot + network and pid namespacing
[00:30] <SpamapS> o/
[00:30] <SpamapS> juju set mysql dataset-size=xxxG  tunes it for your dataset
[00:31] <SpamapS> juju set mysql tuning-level=fast  <--- removes the brakes from the car
[00:33] <SpamapS> the charm *could* lock to a single version
[00:34] <SpamapS> IMO, charms *should* lock to a version in most cases, but this is not a universally held belief. :)
[00:35] <SpamapS> remove-unit always removes an explicit unit
[00:37] <SpamapS> common feature request:  juju remove-unit x/4 --terminate-machine
[00:42] <SpamapS> 8 charms for core openstack
[00:43] <SpamapS> mysql, rabbit, nova-cc, nova-compute, glance, swift, swift proxy, keystone
[00:43] <SpamapS> Suggests: apt-cacher-ng, lxc, libvirt-bin, zookeeper
[00:43] <txwikinger> Can you use juju on trystack.org?
[00:43] <SpamapS> zookeeper == java
[00:44] <SpamapS> txwikinger: that should work if trystack has S3 exposed
[00:44] <txwikinger> I have not figured that out yet
[00:44] <txwikinger> how do I configure juju for it?
[00:45] <SpamapS> There is but its haacky
[00:46] <SpamapS> yes, but you won't be able to use juju after that
[00:46] <SpamapS> no you can't shut it down because its address will change
[00:46] <SpamapS> each node gets the address of node 0 stored as a configuration
[00:47] <SpamapS> thats just an implementation detail .. we could make the bootstrap node discoverable by other means.
[00:47] <SpamapS> \o/ subway good!
[00:52] <SpamapS> I am!
[00:53] <SpamapS> unless I dreamed it ;)
[00:53] <SpamapS> yes, we'd have to put that charm in a different charm store though
[00:54] <udsbotu> uds-gb-h: 5 minutes left in this session!
[00:54] <SpamapS> If you guys come up with a charm that can only run on Solaris or BSD or something.. come talk to us, I want to see that and will help get that integrated w/ the charm store. :)
[00:55] <SpamapS> s3 is not properly abstracted for charms yet
[00:55] <SpamapS> planned feature for the future
[00:55] <udsbotu> uds-gb-h: 4 minutes left in this session!
[00:55] <SpamapS> it does have the abstraction in the provider
[00:55] <SpamapS> but there's no charm tool to access it
[00:56] <SpamapS> official images only please!
[00:56] <udsbotu> uds-gb-h: 3 minutes left in this session!
[00:57] <udsbotu> uds-gb-h: 2 minutes left in this session!
[00:57] <SpamapS>                               .sssssssss.
[00:57] <SpamapS>                         .sssssssssssssssssss
[00:57] <SpamapS>                       sssssssssssssssssssssssss
[00:57] <SpamapS>                      ssssssssssssssssssssssssssss
[00:57] <SpamapS>                       @@sssssssssssssssssssssss@ss
[00:57] <SpamapS>                       |s@@@@sssssssssssssss@@@@s|s
[00:58] <SpamapS>                _______|sssss@@@@@sssss@@@@@sssss|s
[00:58] <SpamapS>              /         sssssssss@sssss@sssssssss|s
[00:58] <SpamapS>             /  .------+.ssssssss@sssss@ssssssss.|
[00:58] <SpamapS>            /  /       |...sssssss@sss@sssssss...|
[00:58] <SpamapS>           |  |        |.......sss@sss@ssss......|
[00:58] <SpamapS>           |  |        |..........s@ss@sss.......|
[00:58] <SpamapS>           |  |        |...........@ss@..........|
[00:58] <SpamapS>            \  \       |............ss@..........|
[00:58] <SpamapS>             \  '------+...........ss@...........|
[00:58] <SpamapS>              \________ .........................|
[00:58] <SpamapS>                       |.........................|
[00:58] <udsbotu> uds-gb-h: 1 minute left in this session!
[00:58] <SpamapS>                      /...........................\
[00:58] <SpamapS>                     |.............................|
[00:58] <SpamapS>                        |.......................|
[00:58] <SpamapS>                            |...............|
[00:58] <SpamapS> Cheers folks!
[00:59] <udsbotu> uds-gb-h: This session has ended.
[16:02] <suihkulokki> hello everyone :)
[16:02] <SteveMcIntyre> hey folks
[16:02] <shirgall> 你好
[16:02] <suihkulokki> come closer to microphones, folk :)
[16:02] <SteveMcIntyre> yes
[16:03] <shirgall> better
[16:03] <suihkulokki> better yes
[16:03] <shirgall> still not hearing any 64-bit long words :)
[16:03] <rsalveti> SteveMcIntyre: are you able to do a hard ping on wookey?
[16:03] <rsalveti> :-)
[16:03] <SteveMcIntyre> rsalveti: I'll go look for him
[16:04] <wookey_> hello
[16:05] <wookey_> schedule moved :-)
[16:06] <wookey_> I can't hear yet
[16:06] <shirgall> wookey_: they want to know if the port is done yet?
[16:07] <wookey_> Not quite :-)
[16:07] <SteveMcIntyre> wookey_ had headphones on, dunno if he was actually connected to the audio
[16:07] <shirgall> wookey_: So, Friday then?
[16:07] <wookey_> OK. I'm here
[16:07] <SteveMcIntyre> wookey_: see the audio link in the topic!
[16:08] <chihchun_> can anyone share the link?
[16:08] <rsalveti> http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html
[16:08] <wookey_> people.linaro.org/~wookey/buildd/quantal/sbuild-ma/status.html
[16:08] <chihchun_> thanks
[16:08] <wookey_> status is very broken right now
[16:08] <wookey_> as libc doesn't seem to want to install
[16:09] <wookey_> yes we do
[16:09] <wookey_> sorry arm does, linaro doesn't
[16:09] <wookey_> And that toolchain is hacked from a bninary build
[16:09] <wookey_> sorry what ricardo?
[16:09] <SteveMcIntyre> it builds, but a lot of the patches need fixing for newer gcc
[16:10] <rsalveti> wookey_: the results of the cross buildd based on the new toolchain from arm
[16:10] <doko> can we get agreement about the multiarch triplet now?
[16:10] <SteveMcIntyre> doko: heh :-)
[16:12] <SteveMcIntyre> correct, no qemu for a while
[16:12] <SteveMcIntyre> there will be "issues" with adding support there
[16:12] <med_> who's providing the QEMU?
[16:12] <wookey_> no qemu means we need different cross-fixes for some things than on a qemu-having arch
[16:12] <wookey_> yes
[16:13] <wookey_> not at the moment, no
[16:13] <suihkulokki> is there some plan to work on qemu?
[16:13] <wookey_> main blockers are multiarchy deps for perl, python
[16:14] <SteveMcIntyre> suihkulokki: not that I know of, yet
[16:14] <rsalveti> suihkulokki: we'll have at linaro, but I believe it's probably something to start at Q4
[16:14] <SteveMcIntyre> arm64 is favourite, I think
[16:14]  * SteveMcIntyre nods infinity
[16:14] <wookey_> wookey nods too :-)
[16:15] <doko> wookey_, multiarchy deps?
[16:15] <wookey_> arm is using multiarch paths for linker and libs on internal toolchain, they are changing to linker in /lib and libs in /lib64
[16:15] <doko> SteveMcIntyre, favourite for what? gnu triplet, multiarch triplet?
[16:15] <SteveMcIntyre> doko: for the Debian/Ubuntu arch name
[16:16] <SteveMcIntyre> cjwatson: it's still an open question
[16:16] <wookey_> colin we need to argue upstream about that if we care
[16:16] <doko> SteveMcIntyre, and the gnu triplet is already defined?
[16:16] <SteveMcIntyre> the upstream glibc folks will whinge *again* if we try to push m-a
[16:16] <ramana> gnu triplet is already decided and upstream (aarch64-linux-gnu )
[16:16] <SteveMcIntyre> doko: yes
[16:16] <SteveMcIntyre> doko: aarch64-linux-gnu
[16:17] <doko> and this should be used foe the multiarch triplet too? looks a bit "generic"
[16:17] <wookey_> what happens on an amd64/aarch64 machine? what is /lib64 symlinked to?
[16:17] <SteveMcIntyre> the clear thing we have at least from the armhf mess is that we can have ld.so in /lib
[16:17] <SteveMcIntyre> as /lib/ld-linux-aarch64.so.X IIRC?
[16:17] <SteveMcIntyre> ramana: ?
[16:18] <ramana> SteveMcIntyre, the GNU triplet is already upstream isn't it ?
[16:18] <wookey_> ah. OK
[16:18] <SteveMcIntyre> ramana: yes, the triplet is
[16:18] <SteveMcIntyre> ramana: have we specced the linker name?
[16:18] <SteveMcIntyre> we have a lot of cross-build fixes already
[16:18] <SteveMcIntyre> but there's issues with getting them pushed upstream from within ARM :-(
[16:19] <wookey_> I have a big list of fixes and effort estimates
[16:19] <wookey_> 10% is aarch64. 50% is multiarch deps, 40% is assorted crossbuild
[16:19] <ramana> SteveMcIntyre, probably worth talking to marcus about. I haven't followed all those developments recently.
[16:19] <SteveMcIntyre> cjwatson: yes, agreed
[16:20] <SteveMcIntyre> this is a reason why wookey_ has got involved
[16:20] <wookey_> infinity yes, the prblem is that the best set of patches is ARMs and they won't let it out directly yet
[16:20] <wookey_> but I can still give you a summary
[16:20] <SteveMcIntyre> Peter was very good at coming up with patches, but not pushing them upstream
[16:20] <SteveMcIntyre> so a number of them rotted :-/
[16:21] <cjwatson> And what happened then was that the packaging moved on so they became irrelevant or unmergeable
[16:21] <SteveMcIntyre> yes
[16:21] <cjwatson> There were several cases near the end of precise where there was a patch somewhere but it didn't make sense any more so I just did it again from scratch
[16:21] <SteveMcIntyre> ack
[16:21] <wookey_> Where is the right venue to disucss crossfixes?
[16:21] <SteveMcIntyre> doko: you're quite quiet?
[16:22] <doko> SteveMcIntyre, as always ;)
[16:22] <wookey_> I sometimes need to ask and it's not obvious where...
[16:22] <cjwatson> any regular Ubuntu development channels are fine
[16:22] <cjwatson> #ubuntu-devel etc.
[16:22] <suihkulokki> many of the old cross-building patches are not quite valid in the multiarch world anymore
[16:22] <doko> SteveMcIntyre, just want to differentiate between cross build failure and package-needs-porting
[16:22] <SteveMcIntyre> yeah
[16:22] <cjwatson> Right
[16:23] <wookey_> the list is natty-based yes, but modified to include all that are fixed upstream
[16:23] <wookey_> and some pat bugs
[16:23] <wookey_> apt
[16:23] <wookey_> some are still OK
[16:24] <wookey_> but yes some are mostly useless
[16:24] <SteveMcIntyre> then there's still some *nasty* ones
[16:24] <SteveMcIntyre> perl \o/
[16:24] <cjwatson> cross-building perl isn't that hard, but making it multiarch-useful is
[16:24] <cjwatson> ditto python
[16:24] <SteveMcIntyre> ack
[16:24] <cjwatson> because a lot of that is defining rules for extensions
[16:25] <cjwatson> (where by "isn't that hard" I mean relative to the usual difficulty of building perl and python :-) )
[16:25] <wookey_> I am maintaining public status of issues here: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuildStatus
[16:25] <doko> working on python3.3 cross buildability. one more reason to switch to 3.3 ;)
[16:25] <SteveMcIntyre> cjwatson: *grin*
[16:25] <SteveMcIntyre> who's the perl maint in Ubuntu?
[16:25] <cjwatson> we keep it synced from Debian
[16:25] <SteveMcIntyre> I had a 5.12.x patch that worked, but would need m-a tweaks
[16:25] <doko> SteveMcIntyre, we only have a last upoader ...
[16:25] <cjwatson> so we don't have one
[16:25] <wookey_> (by hand, so often a few days out of date)
[16:25] <SteveMcIntyre> then 5.14.x happened before it was accepted
[16:25] <cjwatson> I'm happy to act as a stunt perl maintainer
[16:26] <SteveMcIntyre> we'd need to work on 5.14.x and 5.16.x and get upstream to play too, ideally
[16:26] <suihkulokki> I guess this cross-build perl/python modules is a thing to do at linaro connect
[16:26] <SteveMcIntyre> cjwatson: well volunteered :-)
[16:26]  * doko turns on the camera ...
[16:26] <wookey_> agreed
[16:26] <suihkulokki> so we can move back to aarch64 specific issues here
[16:26] <wookey_> The automatic build will be definitive
[16:27] <wookey_> but it's good for things like 'this apt bug breaksa thes 8 builds'
[16:28] <wookey_> We need agreement on the staged build/bootstrap stuff too
[16:28] <wookey_> to get it into dpkg/apt
[16:28] <cjwatson> I'm not sure we do
[16:28] <cjwatson> That's good for automatic bootstrapping, but it wouldn't be the end of the world to have some manual work involved in a handful of packages
[16:29] <cjwatson> it's still massively better than anything we had before
[16:29] <wookey_> true - depends if you want to bootstrap more than once
[16:29] <wookey_> which you do until there is some hardware...
[16:29] <wookey_> compiler bugs is one thing yes
[16:29] <doko> wookey_, well, the final bootstrap will be a native one anyway (the one where packages hit the archive)
[16:30] <wookey_> true
[16:30] <SteveMcIntyre> they're different, but the staged bootstrap helps both ways
[16:30] <wookey_> arm want to keep bootstapping due to toolchain issues
[16:30] <SteveMcIntyre> cjwatson: yes
[16:31] <SteveMcIntyre> we just need it to be pushed and working
[16:31] <wookey_> cjwatson: yes, but dpkg people want some evidence we are agreed
[16:31] <SteveMcIntyre> and then fix the issues when they arrive
[16:31] <wookey_> before putting it in
[16:31] <SteveMcIntyre> wookey_: who?
[16:31] <wookey_> There are bugs filed:
[16:32] <wookey_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661538
[16:32] <udsbotu> Debian bug 661538 in dpkg-dev "Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops" [Wishlist,Open]
[16:32] <wookey_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661537
[16:32] <udsbotu> Debian bug 661537 in apt "Support for staged/bootstrap builds to break cyclic build-dependencies" [Wishlist,Open]
[16:32] <wookey_> so eveyone pile in and say 'yes it's a good idea'
[16:33]  * SteveMcIntyre nods infinity again
[16:33] <SteveMcIntyre> it's up to the people *using* this to say what's needed
[16:33] <wookey_> OK
[16:33] <SteveMcIntyre> wookey_: any other patches?
[16:34] <SteveMcIntyre> e.g. sbuild and friends?
[16:34] <wookey_> OK I have a pyhton-debian patch
[16:34] <wookey_> and there is an xdeb
[16:34] <wookey_> just to recognise extra fields IIRC
[16:34] <SteveMcIntyre> and python-apt?
[16:35] <wookey_> well yes xdeb is mostly supeceded
[16:35] <wookey_> but there is a patch for people still using it
[16:35] <SteveMcIntyre> didn't catch that...?
[16:35] <wookey_> On toolchains we need to do gcc/glibc/libffi/binutils/gdb packaging
[16:35] <cjwatson> That's #669250?
[16:36] <wookey_> cjwatson: yes
[16:36] <SteveMcIntyre> we have a kernel for aarch64 inside ARM, yes
[16:36] <SteveMcIntyre> review is ongoing, will go public soon
[16:37] <SteveMcIntyre> pass :-)
[16:37] <wookey_> I did it once for maverick-vintage toolchain
[16:37] <SteveMcIntyre> rsalveti: yes
[16:37] <wookey_> arm lawyers are huge impediment to getting anything done
[16:38] <wookey_> an 'IP based business' finds contributing very difficult
[16:39] <wookey_> I have a half-arsed patch for adding aarch64 to toolchain packaging
[16:39] <SteveMcIntyre> it's all gone quiet...
[16:39] <wookey_> should I just send it to doko to update for current?
[16:39] <wookey_> Is someone going to add arm64/aarch64 line to dpkg?
[16:40] <SteveMcIntyre> multi-assed?
[16:40] <wookey_> hrw: OK
[16:40] <wookey_> it's a  one-line patch :-)
[16:41] <wookey_> cjwatson: it's alkmim's first patch so may not be perfect. It looked approx OK to me.
[16:41] <cjwatson> yep, I shall ponder it
[16:41] <doko> SteveMcIntyre, could you add the multiarch triplet to http://wiki.debian.org/Multiarch/Tuples ?
[16:41] <cjwatson> it obviously requires patched dpkg
[16:41] <SteveMcIntyre> doko: yes, will do
[16:41] <SteveMcIntyre> please add an action for that for me
[16:42] <wookey_> So are we bootstrapping in debian or ubuntu first?
[16:42] <SteveMcIntyre> wookey_: yes

[16:42] <SteveMcIntyre> infinity: I'm doing it *now* already
[16:43] <wookey_> planning to get it working this cycle?
[16:43] <SteveMcIntyre> we'll end up bootstrapping a few times anyway, I expect
[16:44] <rsalveti> wookey_: yup :-)
[16:44] <SteveMcIntyre> releasing before hw will be hard
[16:44] <SteveMcIntyre> infinity: compared to older models, they *are* fast
[16:44] <SteveMcIntyre> believe me!
[16:45] <SteveMcIntyre> imagine a few tens of MHz type of level
[16:45] <SteveMcIntyre> fast enough to run things, but not something you'd want to build on it...
[16:45] <wookey_> Oh yes - There is an alternate reduced packge list: http://people.linaro.org/~wookey/buildd/quantal/sbuild-ma/status-bootstrap.html
[16:45] <SteveMcIntyre> at least, that's my impression from others
[16:46] <SteveMcIntyre> not played directly yet
[16:46] <wookey_> which is basically the current targeteed package set
[16:46] <wookey_> can someone take a look and see why _no_ build-deps work currently
[16:46] <wookey_> that's just what arm used
[16:46] <SteveMcIntyre> infinity: the list we started with was *more* than bootstrap to start with
[16:46] <wookey_> becaasue they wanted apche to demo
[16:46] <SteveMcIntyre> people wanted to demo a simple LAMP stack
[16:47] <wookey_> click on any build-dep link there
[16:47] <wookey_> then go down to the bottom
[16:47] <wookey_> we can fix about 100 builds if that is unbunged :-)
[16:48] <wookey_> libc6-dev is m-a:same
[16:49] <suihkulokki> you need a cross-build-essential
[16:50] <SteveMcIntyre> it makes sense, yes
[16:50] <wookey_> yes, someone needs to do that
[16:50] <wookey_> I think ThibG was going to
[16:50] <wookey_> sbuild has it's own internal list for now
[16:50] <udsbotu> uds-gb-h: 5 minutes left in this session!
[16:50] <wookey_> but it has to chage from debian to ubuntu
[16:51] <SteveMcIntyre> hell yes
[16:51] <SteveMcIntyre> infinity: you at Connect too?
[16:51] <SteveMcIntyre> yay
[16:51] <udsbotu> uds-gb-h: 4 minutes left in this session!
[16:52] <SteveMcIntyre> :-)
[16:52] <rsalveti> anything else?
[16:52] <SteveMcIntyre> all done?
[16:52] <udsbotu> uds-gb-h: 3 minutes left in this session!
[16:52] <SteveMcIntyre> agreed
[16:52] <wookey_> doko: did you already fix M-A python?
[16:52] <wookey_> so we just have to try it?
[16:53] <wookey_> or is there more to do?
[16:53] <doko> wookey_, it should be, but I really didn't test anything with it
[16:53] <udsbotu> uds-gb-h: 2 minutes left in this session!
[16:53] <wookey_> well quantal if armhf
[16:54] <wookey_> precise was all armel
[16:54] <SteveMcIntyre> right, time to bail
[16:54] <SteveMcIntyre> have fun folks
[16:54] <udsbotu> uds-gb-h: 1 minute left in this session!
[16:54] <wookey_> Well, glad to hear you are all going to fix cross stuff :-)
[16:54] <rsalveti> thanks!
[16:55] <wookey_> I look forward to it
[16:55] <udsbotu> uds-gb-h: This session has ended.
[16:56] <wookey_> OK, cheers colin
[16:57] <wookey_> good - not just me then :-)
[17:11] <NMinker> I knew of the packaging guide on the wiki, but not this new one
[17:15] <bobweaver> I will more then willing help anywhere that I can just send a email.But I dont know if I am the best person but I def can help
[17:15] <bobweaver> josephjamesmills
[17:16] <bobweaver> https://launchpad.net/~josephjamesmills
[17:16] <bobweaver> np thank you :)
[17:23] <bobweaver> new packaging videos ?
[17:25] <NMinker> Update the old packaging videos (which were done with Hardy?), so they're more current for Precise/Quantal
[17:28] <bobweaver> is there anyway that you can turn up the mic ?
[17:31] <linuxtech> How about this idea, get Kahn Academy to do a session on creating and building a package?
[17:31] <NMinker> call for translators could be a milestone
[17:32] <bobweaver> what did you ask ?
[17:32] <bobweaver> I can here
[17:32] <bobweaver> hear
[17:33] <NMinker> I forgot
[17:39] <udsbotu> uds-gb-h: 5 minutes left in this session!
[17:40] <NMinker> Promise them cake
[17:40] <bobweaver> (WIKI)I would like too bring up that there is a team for ubuntu-wiki that is new I will tell them about this ?
[17:40] <udsbotu> uds-gb-h: 4 minutes left in this session!
[17:41] <udsbotu> uds-gb-h: 3 minutes left in this session!
[17:42] <udsbotu> uds-gb-h: 2 minutes left in this session!
[17:43] <bobweaver> I wrote code to make html too moinmoin
[17:43] <udsbotu> uds-gb-h: 1 minute left in this session!
[17:44] <udsbotu> uds-gb-h: This session has ended.
[17:45] <NMinker> quiet UDSbot
[17:52] <bobweaver> Thanks !!
[18:03] <gilir> I'm waiting 5 min to close the door and to start the session :)
[18:08] <gilir> hum, as usual, no many people in the room, but the chan is also quiet :-/
[18:08] <Unit193> \o
[18:08] <gilir> hey Unit193 :)
[18:09] <gilir> I feel less alone :)
[18:10] <IAmNotThatGuy> hey gilir
[18:10] <gilir> hi IAmNotThatGuy :)
[18:11] <valdur55> hey!
[18:12] <IAmNotThatGuy> Hello valdur55
[18:12] <gilir> do you want me to start talking, or could we cancel the session ? not sure it's really useful with the low number of people :(
[18:13] <bmoez> please keep it :)
[18:14] <IAmNotThatGuy> gilir, Important action items can be discussed at this time. People can look at the logs later I believe
[18:15] <Unit193> Yep.
[18:15] <gilir> the etherpad : http://summit.ubuntu.com/uds-q/meeting/20575/lubuntu-q-work-items/
[18:23] <Unit193> That's the one I switched out since I needed a timed option.
[18:31] <bmoez> if this is the right time: i think that "Menu" should get more futures. i mean that it should get two looks : one "simple" (as it is now) and other more complet but light (like in winXP)
[18:31] <bmoez> i mean "Menu" the applet in lxpanel
[18:31] <Unit193> Along the lines of menu, there was some sort of "LXmed" menu editor, but not in the repo.
[18:38] <valdur55> I use Synapse semantic launcher for launching programs :)
[18:41] <bmoez> i think "audacious" should have a more avanced applet for lxpanel if it will not use more Mo
[18:45] <Unit193> Translations of the site/wiki?
[18:47] <valdur55> Xfce 4.10 upgraded Application Finder. : http://xfce.org/about/tour . Maybe should have lxde desktop same runner?
[18:50] <udsbotu> uds-gb-h: 5 minutes left in this session!
[18:51] <udsbotu> uds-gb-h: 4 minutes left in this session!
[18:52] <udsbotu> uds-gb-h: 3 minutes left in this session!
[18:53] <bmoez> i'm not sure, but installing an other session like gnome-shell or unity with lubuntu will make lubuntu-session more slow (use more memory because some daemons of others sessions open in the lubuntu-session)
[18:53] <udsbotu> uds-gb-h: 2 minutes left in this session!
[18:53] <bmoez> or not?
[18:54] <udsbotu> uds-gb-h: 1 minute left in this session!
[18:55] <udsbotu> uds-gb-h: This session has ended.
[19:46] <xranby_ac100> i have come across some usb mimo monitors with integrated touchpad.  the device is basically a usb hub that connects to a usb hid input device for the touch   and a display link screen.. the hard part are how to associate the touchscreen orientation with the usb screen
[19:46] <xranby_ac100> can we support these kind of usb screens? and make the touch work?
[19:46] <xranby_ac100> hello
[19:46] <xranby_ac100> !!!
[19:47] <xranby_ac100> have a nice lunch
[19:54] <udsbotu> uds-gb-h: 5 minutes left in this session!
[19:55] <udsbotu> uds-gb-h: 4 minutes left in this session!
[19:56] <udsbotu> uds-gb-h: 3 minutes left in this session!
[19:57] <udsbotu> uds-gb-h: 2 minutes left in this session!
[19:58] <udsbotu> uds-gb-h: 1 minute left in this session!
[19:59] <udsbotu> uds-gb-h: This session has ended.
[22:54] <udsbotu> uds-gb-h: 5 minutes left in this session!
[22:55] <udsbotu> uds-gb-h: 4 minutes left in this session!
[22:56] <udsbotu> uds-gb-h: 3 minutes left in this session!
[22:57] <udsbotu> uds-gb-h: 2 minutes left in this session!
[22:58] <udsbotu> uds-gb-h: 1 minute left in this session!
[22:59] <udsbotu> uds-gb-h: This session has ended.