[02:25] <beuno> sergiusens, soon, but orthogonal to ssl/tls
[03:27] <dstokes> is there any way to install packages from file, without having to upload to canonical?
[04:28] <miken> dstokes: yes, you can side-load... let me find the relevant docs
[04:29] <tedg> dstokes, Yes, you just need to set --allow-unauthenticated to avoid it checking for the store key.
[04:29] <dstokes> tedg: what's the command / args for installing? cant find anything in the docs
[04:29] <miken> snappy-remote --url=ssh://you@device install ./hello-world_1.0.5_all.snap
[04:30] <miken> tedg: Is that correct? ^^ That's what I used, from
[04:30] <miken> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
[04:30] <tedg> I haven't used remote, but on the image it's just "snappy install --allow-unauthenticated foo.snap"
[04:30] <tedg> Well, sudo
[04:31] <dstokes> oic
[07:00] <dholbach> good morning
[07:00] <miken> Morning dholbach
[07:03] <fgimenez> good morning
[07:04] <dholbach> hi miken
[07:18] <dholbach> mvo_, sergiusens, rsalveti: do you think anyone of you can reply to seb128's mail on snappy-devel? he's still looking for a way to boot
[07:18] <seb128> dholbach, thanks! yeah, still failing to boot snappy on that uefi machine
[07:19] <seb128> which blocks me for working on the new unity8 desktop snappy iso
[07:29] <mvo_> seb128: I'm not sure what the status here is, we have wily images since yesterday that might help, but in any case I create a card and try to find if I have a machien with uefi bios
[07:31] <seb128> mvo_, hey! where can I get the wily image? I'm happy to try that
[07:31] <mvo_> seb128: sudo ubuntu-device-flash core rolling --channel edge --output wily.img
[07:32] <mvo_> seb128: that should be dd-able
[07:32] <mvo_> seb128: and I added a trello card
[07:32] <seb128> mvo_, ok, great, I'm going to give that a try in a bit and let you know how that works
[07:32] <seb128> thanks!
[07:34] <mvo_> yw
[07:50] <zyga> good morning
[08:06] <beowulf> morning
[08:33] <elopio> good morning.
[09:09] <JamesTait> Good morning all; happy Leave the Office Earlier Day! 😃
[09:09] <ogra_> lol
[09:13] <tbr> good moaning
[09:13] <dholbach> ogra_, in the node-snapper example it looks like the tool gets stuck in some point during the installation
[09:13]  * tbr starts to write a brief blog post on how to make snappy work on real x86 embedded hardware
[09:13] <dholbach> ogra_, http://pastebin.ubuntu.com/11516722/
[09:14] <ogra_> dholbach, it compiles
[09:14] <dholbach> then it's compiling for a very long time :)
[09:14] <ogra_> therr should be a spinner in the bottom left though
[09:14] <ogra_> tbr, wheee  !
[09:14] <dholbach> no spinner here
[09:14] <ogra_> then kill it and start over
[09:15] <dholbach> http://pastebin.ubuntu.com/11516757/ - I guess something is happening
[09:15] <ogra_> it uses qemu-arm-static, thats sometimes a little rough
[09:15] <ogra_> whats your host release ?
[09:16] <dholbach> 15.04
[09:16] <ogra_> (qemu-arm-static stability sadly varies ... it is rock solid in trusty, i saw issues sometimes in utopic and havent built under vivid yet)
[09:17] <ogra_> so if you dont see a spinner, kill it and start over i'd say
[09:17] <ogra_> (we should note that in the doc)
[09:20] <tbr> ogra_: luckily it's fairly simple. install version >x of toos, build image, boot image manually (or by adding startup.nsh), use efibootmgr to set boot order properly (and check on every boot)
[09:22] <dholbach> ogra_, now it succeeds :-/
[09:22] <ogra_> dholbach, right ...
[09:27] <dholbach> Chipaca, mvo_, do you have an idea what's happening here? http://pastebin.ubuntu.com/11516932/
[09:31] <dholbach> ogra_, https://code.launchpad.net/~dholbach/node-snapper/not-world-writable/+merge/260806
[09:32] <dholbach> Chipaca, mvo_: http://pastebin.ubuntu.com/11516978/
[09:32] <Chipaca> yep
[09:32] <ogra_> dholbach, cool., thanks ... i also noticed yesterday that snappy nor kills the symlinks in $arch/bin/ ... need to find a fix for that one (start-service.sh points to $arch/bin/node which is a symlink to $arch/bin/nodejs)
[09:32] <ogra_> s/nor/now/
[09:33] <Chipaca> dholbach: remember how we don't support things that are apps becoming frameworks, or viceversa?
[09:33] <Chipaca> dholbach: bottom line, remove the old webdm and install the new one, until we fix that
[09:34] <dholbach> ok
[09:34] <ogra_> for me "snappy update webdm" (on the 15.04 release kvm image) just works
[09:35] <dholbach> I can't quite remember which image it was I used back then
[09:40] <dholbach> "Tags are free form, but some can gain special use, such as an external/ui one which would be picked up by the webdm and used to open the application through the web."
[09:40] <dholbach> ^ is the above true right now?
[09:44] <beowulf> dholbach: what's the source?
[09:45] <beowulf> dholbach: as of this minute, webdm doesn't provide links to external ui, but i don't know what tags are
[09:46] <beowulf> s/but/and
[09:48] <dholbach> beowulf, that's in https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
[09:48] <dholbach> (just search for webdm)
[09:49] <beowulf> dholbach: ah right, so the 'ui' tag isn't working right now
[09:49] <dholbach> ok
[09:49] <beowulf> dholbach: it will be by end of today, and then it'll be available on the next version of webdm
[09:49] <dholbach> <3
[09:49] <elopio> fgimenez: ping, I can start the exploratory now. Are you ready?
[09:50] <beowulf> dholbach: that's much easier to read now :)
[09:50] <beowulf> dholbach: do you know why the icon section says "only SVG"?
[09:51] <dholbach> no, I don't
[09:51] <dholbach> davidcalle, ^ do you know why the icon section on https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ says "only SVG"?
[09:51] <beowulf> the store converts SVG to PNG, and I don't think we should allow SVG
[09:52] <fgimenez> elopio, yup, ready!
[09:53] <elopio> fgimenez: do you use firefox? want to try meeting using hello?
[09:53] <dholbach> ogra_, can you pull from lp:~dholbach/+junk/chatroom?
[09:53] <dholbach> (can't create an MP for a +junk branch)
[09:53] <davidcalle> dholbach, probably because the branch doc (eg. https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md) specify the svg format for icons (line25)
[09:54] <fgimenez> elopio, not tried yet, let me set it up
[09:55] <dholbach> davidcalle, ah ok... sorry - it says that in the 15.04 branch as well, just not as "only svg" which I couldn't find in there
[09:55] <dholbach> beowulf, looks like it's currently spec'ed that way, cf https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md and https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md
[09:56] <elopio> getting some water here and finding a good place. Give me a couple of minutes.
[09:56] <davidcalle> dholbach, beowulf, the doc itself is not from snappy trunk, it's one of the first doc uploaded with the initial snappy announcement, afair it has been reviewed to be kind-of up-to-date with the latest release
[09:58] <davidcalle> I don't know if snappy actually cares about the format, though :)
[09:59] <davidcalle> beowulf, do you know what the plan is for high-res screens and the store? Do we need (or will we need) several png sizes?
[10:03] <elopio> fgimenez: https://hello.firefox.com/zAxKYb3AqB8
[10:04] <fgimenez> elopio, ok give me a second..
[10:07] <beowulf> davidcalle: i don't know what the plan is, but the current icon size is 256x256, that's quite large already
[10:10] <elopio> fgimenez: http://pad.ubuntu.com/testing-snappy
[10:12] <ogra_> dholbach, oh, didnt i push that yet ? (i have the same on disk and in the store) ....
[10:12] <davidcalle> beowulf, thanks, can confirm, just tried at 3200x1800, various scalings, looking sharp :)
[10:12] <elopio> fgimenez and I will be doing exploratory testing on snappy here, in case somebody wants to join: https://hello.firefox.com/zAxKYb3AqB8
[10:19] <dholbach> ogra_, apparently not :)
[10:22] <Chipaca> mvo_: you around?
[10:22] <mvo_> Chipaca: yes
[10:22] <Chipaca> mvo_: hiya!
[10:22] <mvo_> Chipaca: good morning!
[10:22] <Chipaca> mvo_: what happens if a service has no description?
[10:22] <Chipaca> currently we're using the second line of the readme for that
[10:23] <mvo_> Chipaca: a good question - using that is probably not a great idea :/
[10:23] <Chipaca> but we're only storing it in the click manifest (and in the systemd service file)
[10:23] <Chipaca> until i got to that, i had high hopes of making things work without reverting the "limit click manifest use" branch
[10:23] <mvo_> Chipaca: maybe we should just generate something like "service for {pkgname} - {servicename}" or something
[10:24] <Chipaca> mvo_: "service {servicename} of {qualified name}"?
[10:25] <mvo_> Chipaca: yeah, much better
[10:25] <ogra_> dholbach, pushed this and other changes
[10:25] <Chipaca> k
[10:27] <dholbach> ogra_, and the node-snapper MP?
[10:27] <ogra_> dholbach, no, chatroom
[10:28] <Chipaca> mvo_: not qualified name; we don't know the origin in build :)
[10:28] <mvo_> Chipaca: my brain is still on this gccgo senfile failure, but I think I nailed it now, I feel a bit silly for not spotting the real problem earlier
[10:28] <Chipaca> mvo_: that's good, right?
[10:28] <mvo_> Chipaca: indeed you are right
[10:29] <mvo_> Chipaca: its good that its fixed, not good that I feel silly, but I guess I should relax and celebrate the fix instead :)
[10:29] <ogra_> dholbach, doing node-snapper now ... i'm just totally distracted by http://people.canonical.com/~alan/ogra_loading.gif
[10:29] <Chipaca> mvo_: feeling silly is good
[10:29] <Chipaca> mvo_: because it only happens *after* the "aha"
[10:29] <mvo_> lol
[10:29] <mvo_> very true
[10:29] <dholbach> ogra_, yes, I can imagine
[10:29] <elopio> fgimenez: still 10 minutes to download, it doesn't go down :(
[10:29] <dholbach> ogra_, take your time :)
[10:29] <elopio> and makes the video choppy. I'll go and get more water and the charger...
[10:31] <fgimenez> elopio, np, the video is frozen for me.. ping me when ready
[10:31] <ogra_> dholbach, merged and pushed
[10:32] <dholbach> ogra_, cool, I'll do another test run now
[10:32] <ogra_> wait one sec, i have another change
[10:32]  * dholbach waits
[10:33] <ogra_> dholbach, done
[10:33] <elopio> fgimenez: 2 mins.
[10:34] <ogra_> mvo_, http://bazaar.launchpad.net/~ogra/node-snapper/trunk/revision/7 ... why do my symlinks vanish when packaging the snap ? is that intentional ?
[10:34] <elopio> fgimenez: I can see you, but you can't hear me.
[10:34] <elopio> the download is ready.
[10:35] <elopio> I'll rejoin...
[10:35] <fgimenez> elopio, nope, and you are frozen
[10:35] <mvo_> ogra_: I suspect need a update version of snappy, symlinks got fixed by Chipaca some days ago
[10:35]  * ogra_ guesses that kind of goes against de-duplication :)
[10:35] <ogra_> ah, cool
[10:35] <mvo_> it was a silly bug
[10:35]  * mvo_ notices that its silly to use silly all the time
[10:35]  * ogra_ will revert that change once that migrated everywhere then ...
[10:35] <elopio> fgimenez: can you kick me or something?
[10:36] <elopio> It says I can't rejoin.
[10:36] <Chipaca> mvo_: giving up, reverting the manifest thing
[10:36] <fgimenez> elopio, i'm alone in the conversation
[10:36] <mvo_> Chipaca: meh, let me know if I can help in any way :(
[10:37] <Chipaca> unless...
[10:39] <elopio> fgimenez: crazy shit. Now I'm alone in the conversation :)
[10:39] <elopio> fgimenez: lets go to hangouts, this doesn't seem ready: https://plus.google.com/hangouts/_/grwijm4jm7pbk5vu6fg5dgiknaa?hl=es
[10:40] <mvo_> Chipaca: btw, if we ever decide to backport the cp_linux thing to 15.04 you will need to remind me that we need to port the upstream gccgo fix as well
[10:40] <Chipaca> mvo_: or, or, we could make the default non-cp_linux implementation be the fallback
[10:40] <Chipaca> mvo_: but then we'd never find these bugs :)
[10:41] <Chipaca> unless we printed a big fat warning before calling the fallback
[10:43] <mvo_> :
[10:43] <mvo_> :)
[10:50] <dholbach> ogra_, looks like chatroom doesn't start up after installation - do you know how I can debug this?
[10:51] <ogra_> dholbach, syslog ... and you can hack the start script "export NODE_DEBUG=*"
[10:51] <elopio> rsalveti: why is the image in http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ older than the one you get with ubuntu-device-flash?
[10:52] <ogra_> dholbach,  did you use the start script unmodified ?
[10:52] <ogra_> dholbach, it might point to node ... if you didnt re-run node-snapper with the last change thats a dead symlink
[10:52] <ogra_> point the script to nodejs instead
[10:56] <dholbach> ogra_, let me check
[11:00] <dholbach> ogra_, still no dice
[11:00] <dholbach> ogra_, how can I emulate the startup of the service?
[11:02] <ogra_> dholbach, show me your start-service.sh
[11:03] <dholbach> ./chatroom.sideload/current/start-service.sh: 27: ./chatroom.sideload/current/start-service.sh: /amd64/bin/nodejs: not found
[11:03] <ogra_> uh
[11:03] <dholbach> ogra_, could it be that "./amd64.." would help there?
[11:04] <ogra_> it uses $SNAPP_APP_PATH/$ARCH/bin/node $MY_EXECUTABLE
[11:04] <ogra_> try dropping a P there
[11:04] <ogra_> seems something changed in the ubuntu-core-launcher that doesnt set the variable anymore
[11:05] <ogra_> (i thought we'd keep that for backwards compatibility ... hmm)
[11:06] <dholbach> ./amd64/bin/nodejs: error while loading shared libraries: libcares.so.2: cannot open shared object file: No such file or directory
[11:06] <ogra_> geez
[11:06] <ogra_> what did you do
[11:06] <ogra_> you see that in syslog when starting it via systemctl ?
[11:08]  * ogra_ pushes a change for SNAPP vs SNAP to the branch
[11:11] <sergiusens> beowulf: dholbach yes, tags are true, if a package uses that, webdm will hint it in the package payload
[11:12] <dholbach> ogra_, does it work for you?
[11:12] <dholbach> no... I ran this:
[11:12] <dholbach> (amd64)ubuntu@localhost:/apps/chatroom.sideload/current$ ./amd64/bin/nodejs current/site/server.js
[11:12] <Chipaca> mvo_: do we still support setting apparmor in Integration?
[11:12] <dholbach> not sure if that was the wrong way to do it
[11:12] <ogra_> dholbach, i uploaded it to the store yesterday, yes
[11:12] <ogra_> dholbach, the path to the server.js is wrong ... drop the "current/" there
[11:13] <mvo_> Chipaca: I think we do, we could kill it
[11:13] <ogra_> dholbach, but you cant just run it withouth the ubuntu-core-launcher environment ... use systemctl and syslog
[11:13] <mvo_> i think
[11:13] <Chipaca> mvo_: meh. i've made a note.
[11:13] <dholbach> ogra_, ok, I'll have another look
[11:14] <ogra_> dholbach, also, show me your start-service.sh
[11:14] <dholbach> ogra_, I'll start from scratch - I was just following your instructions
[11:14] <ogra_> me too yesterday :)
[11:19] <dholbach> ogra_, it works! :)
[11:20] <dholbach> shipit!
[11:20] <ogra_> haha
[11:20] <ogra_> note it wonly works properly with chromium
[11:21]  * ogra_ just added that info to readme.md
[11:22] <Chipaca> mvo_: still needs tests, but http://bazaar.launchpad.net/~chipaca/snappy/mangle/revision/482?start_revid=482 fixes it; could you take a look and see if the approach seems sane to you?
[11:23] <Chipaca> mvo_: at question is whether i hate clickManifest too much :)
[11:28] <mvo_> Chipaca: looking
[11:30] <mvo_> Chipaca: oh, you can kill the createion of .snappy-systemd in handleServices entirely
[11:32] <mvo_> Chipaca: looks like a good approach, I assume you fix the names ;) ? we should probably do deprecation warnings if we encounter stuff we need to mangle
[11:37] <Chipaca> mvo_: i can? kill snappy-systemd i mean
[11:37] <mvo_> Chipaca: yes, that is only used by the snappy-systemd hook which is no longer in use at all
[11:39] <Chipaca> mvo_: so binaries and services look identical :)
[11:39] <mvo_> heh :) thats good, right?
[11:39] <Chipaca> yep
[11:55] <zyga> hey, is there an api for snappy
[11:55] <zyga> so that I can get stuff like 'snappy list' programmatically without screen-scraping
[11:59] <dholbach> ogra_, I guess there's no way around editing start-service.sh as root, right?
[11:59] <ogra_> dholbach, only by editing it before rolling the snap :)
[11:59] <dholbach> ogra_, the file is owned by root
[12:00] <dholbach> before the rolling of the snap, because node-snapper runs as root
[12:00] <ogra_> ah,. we can change that indeed
[12:01] <zyga> anyone?
[12:02] <zyga> (I'm just after a yes / no answer)
[12:02] <beuno> zyga, yes*
[12:02] <beuno> * sergiusens can tell you more
[12:02] <zyga> beuno: thanks!
[12:03] <zyga> sergiusens: any links on where I can find snappy API?
[12:03] <zyga> sergiusens: (for apps that want to talk to snappy and get data from it)
[12:04] <nessita> beuno, o/ so I mentioned to Sergio the goal to have every request to the store being oauth signed, and he replied that we should first decide on the ssl/tls front
[12:04] <nessita> Chipaca, o/ yes, for snappy
[12:04] <beuno> nessita, I think he's mixing topics
[12:06] <ogra_> zyga, there is work for some REST api ... not sure thats snappy itself or a webdm thing
[12:06] <zyga> ogra_: isn't webdm optional?
[12:06] <zyga> ogra_: I'm looking for alternative to parsing snappy list output
[12:07] <ogra_> zyga, it is optional .. for a remote API you need a webserver though ... which webdm conveniently ships
[12:07] <zyga> ogra_: is app-to-app IPC constrained?
[12:07] <beuno> zyga, the plan is for snappy to provide a rest api, which everything that wants to display data will use
[12:07] <zyga> ogra_: can I write an app that talks to webdm and it will not be broken down the line?
[12:07] <zyga> ok
[12:07] <ogra_> zyga, ask sergio, he designs that :)
[12:07] <beuno> webdm, the cli. etc
[12:08] <zyga> ogra_: will do, thanks!
[12:08] <zyga> sergiusens: I'll be the inner voice in your head
[12:08] <zyga> sergiusens: asking you questions ;)
[12:08] <zyga> ogra_: why is python2.7 on the snappy image btw? is it so that 2.7 webapps can be deployed easily or is there another reason?
[12:09] <ogra_> zyga, by accident ... cloud-init isnt fully ported yet
[12:09] <zyga> ogra_: ah, I see
[12:09] <ogra_> (final target is to get rid of languages )
[12:09] <zyga> ogra_: and down the line, do you see it becoming a framework of sorts, so that people can do 2.7 webapps?
[12:09] <ogra_> (in the core)
[12:09] <zyga> ogra_: or will it be killed
[12:09] <zyga> ogra_: I see
[12:10] <zyga> ogra_: so all runtimes (perl, pythons) go away and maybe move to frameworks
[12:10] <ogra_> i assume it can be a framework ... or you can just bundle it
[12:11] <zyga> ogra_: are frameworks well defined? is it okay for a framework to ship a language runtime?
[12:12] <ogra_> i'm not so sure :)
[12:12]  * ogra_ still hasnt looked at the exact framework definition
[12:12] <zyga> ogra_: is that discussion happening somewhere?
[12:12] <dholbach> ogra_, how do you want to change the permissions?
[12:12] <zyga> ogra_: who makes the calls?
[12:12] <ogra_> in hangouts :P
[12:12] <zyga> ogra_: ok, I'll start showing up in yours
[12:13] <dholbach> ogra_, or shall I just go and write the docs so people use 'sudo' to edit the file?
[12:13] <ogra_> dholbach, oh, i see why that happens, because you chaned world writability :)
[12:13] <ogra_> we could chown the dir to $USER i guess ... shouldnt do harm to the final snap
[12:14] <ogra_> (for the tarball contents and the start script)
[12:14] <ogra_> (snappy chowns everything to the clickpkg user at install time)
[12:16] <dholbach> ogra_, ah yes, that's right :)
[12:17] <dholbach> ogra_, so maybe just change it to $USER once node-snapper is done?
[12:18] <ogra_> yeah, for the arch tarballs before they get tarred up and for the three final files
[12:18] <ogra_> so that the user has all permissionns in case he wants to edit something inside these tarballs manually
[12:51] <dholbach> ogra_, https://developer.ubuntu.com/en/snappy/tutorials/node-to-snap/ - looking good? :)
[12:53] <ogra_> dholbach, in a meeting, gimme a bit
[12:54] <dholbach> ogra_, sure
[12:54] <dholbach> ogra_, I'll hold off of blogging about it for a bit
[12:55] <sturmflut2> https://i.imgur.com/rntFSWS.jpg Awww
[12:55] <beowulf> dholbach: the last paragraph hasn't formatted with a <p>
[12:55] <ogra_> sturmflut2, thats what you get with the intel snap ?
[12:55] <ogra_> cute :)
[12:56] <sturmflut2> ogra_: Yes, a webserver on port 8888 hosting a lot of JavaScript, and I think there's more
[12:57] <sturmflut2> I have to say it was surprisingly painless to boot the Snappy KVM image and install the package
[12:57] <dholbach> thanks beowulf - I'm not sure if I fixed the right way now(?)
[12:57] <ogra_> dholbach, i dont really like the hack in point 6 (where i mv the contents of chatroom/*) ... i wonder if we could make that more elegant
[12:58] <beowulf> dholbach: yep, fixed now :)
[12:58] <ogra_> (that was just a quick hack when elopio found an issue with the original howto, i never cleaned that up)
[12:58] <ogra_> dholbach, but thats only cosmetic, looks great otherwise !
[12:59] <dholbach> thanks beowulf
[12:59] <dholbach> ogra_, let me think about it
[13:00] <ogra_> it would need some serious re-ordering so we branch into package/
[13:00] <ogra_> not sure thats worth it
[13:02] <davidcalle> dholbach, do you mind if I make a small layout tweak to your tuto?
[13:02] <dholbach> davidcalle, I'd be happy if you'd do that :-D
[13:02] <davidcalle> dholbach, specifically code -> twelve-col
[13:03] <dholbach> <3
[13:03]  * dholbach writes a quick blog entry
[13:04] <jdstrand> Chipaca, mvo_: fyi, I made it so the review tools error when finding integration in the yaml. that will be in the 0.28 version I am preparing
[13:04] <Chipaca> niiice :)
[13:04] <jdstrand> so +1 on removing it from snappy
[13:08] <zyga> sergiusens: what is snapcraft?>
[13:09] <ogra_> zyga, a magic wand
[13:10] <ogra_> zyga, you want to interview tedg or mterry about it ;)
[13:10] <zyga> ogra_: I tried googling for it but the name kind of hits minecraft instead
[13:10] <tedg> It's a dream :-)
[13:10] <zyga> what is is, in one line?
[13:10] <ogra_> zyga, a magic wand
[13:10] <tedg> zyga, It's the tool we're working on to make building snaps really easy.
[13:10] <ogra_> (in one line ... no wraps)
[13:11] <tedg> zyga, Handle things like pulling in a runtime and packaging it along with your app.
[13:11] <zyga> ah, so ubuntu component store for snappy, kind of?
[13:11] <tedg> Eh, kinda. More like allowing you to use the component stores you're already happy with. Be it PIP or apt or npm.
[13:12] <zyga> sergiusens: quick question for the "by design", I get that security is there by design, I don't disupte that, I'm looking for what the recommendation is for us, should we just ignore confinement and run entirely unconfined or should we seek some options to work within the confinement?
[13:12] <zyga> tedg: is it reasonable to use snapcraft to pull in pulseaudio
[13:12] <zyga> tedg: and make it really work
[13:12] <zyga> tedg: (with hardware access and all the permissions)
[13:12] <zyga> tedg: so that my app can have some sound?
[13:12] <ogra_> sure
[13:12] <tedg> zyga, No, pulse should really be a framework. It's something that shares hardware.
[13:13] <ogra_> no need for snapcraft to do that
[13:13] <zyga> ok
[13:13] <ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
[13:13] <Chipaca> zyga: for a hardware testing tool, i'd expect it to be unconstrained or have a custom apparmor profile
[13:13] <ogra_> that has some hints about HW access
[13:13] <tedg> zyga, Frameworks are more about services that multiplex HW.
[13:13] <zyga> Chipaca, tedg: that both makes sense, thanks
[13:13] <ogra_> orm for system tests you might actually want unconfined, yeah
[13:14] <zyga> I have a feeling we should help drive this so that eg. pulse exists as a framework and we and use it for testing, that python exists as a framework and we can use it (or that snapcraft can bundle it)
[13:14] <ogra_> the latter will be what will happen
[13:14] <zyga> one other idea I had is to have a flag day and rewrite _everything_ on top of some qt api
[13:15] <ogra_> (snapcraft bundling stuff for you)
[13:15] <zyga> but I don't know if that's a good solution even if we did it (does qt really have an API for everything?)
[13:15] <Chipaca> zyga: just to be sure you understand it, frameworks are for hardware access, not for sharing libraries
[13:15] <Chipaca> zyga: having a library in a framework will not enable things that depend on that framework to use that library
[13:16] <zyga> Chipaca: yes, I get that, it's just not clear to me exactly if there will be exactly zero non-hardware frameworks as this seems to be up in the air a little
[13:16] <zyga> Chipaca: ok
[13:16] <davidcalle> dholbach, hah, nevermind, this break numbered lists... ¯\_(ツ)_/¯
[13:16] <zyga> Chipaca: is snapcraft something that I can try now?
[13:17] <mterry> zyga, no
[13:17] <Chipaca> zyga: snapcraft is in the design phase right now. Or vapourware if you will.
[13:17] <zyga> I see
[13:17] <zyga> so while python exists on the image it's not so critical
[13:18] <zyga> it's more important to understand what's down the line and how the roadmap looks like
[13:18] <ogra_> zyga, but if you use some mechanism to bundle your stuff, let the two guys know so they can take that into account in snapcraft :)
[13:18] <zyga> and to know how we plan to fit in
[13:19] <zyga> mterry, tedg: one mechanism we do use now, is to just have a package in a PPA or in the archive (and use known tooling for building it) and to extract bits and pieces from it (.so files) so that we don't have to worry about cross-compilation or daily builds
[13:20] <zyga> as there are no "ppas" for clicks or snaps and many people are working on the project we do rely on some kind of automatic build process
[13:20] <zyga> and limiting that to "run this script and it fetches and repackages stuff from the archive" does simplify it for us
[13:20]  * dholbach hugs davi
[13:20]  * dholbach hugs davidcalle
[13:20] <zyga> obviously we could rewrite that to build our stuff but then it's a bit more complicated (cross compiling) and time consuming
[13:22] <tedg> zyga, So basically our goal is to make the cross compiling and pulling in dependencies easy. So then you can do that all the time.
[13:23] <zyga> tedg: how do you plan on achieving that?
[13:25]  * ogra_ hugs dholbach
[13:25] <tedg> zyga, magic wand :-)
[13:25] <zyga> tedg: and in reality? :-)
[13:25] <zyga> tedg: one thing I'm interested in is this use case
[13:25] <zyga> tedg: you pip install somethig
[13:25] <zyga> tedg: that builds a .so file
[13:25] <zyga> tedg: how do you make that cross-compilable?
[13:26] <tedg> zyga, We plan on doing it by you providing us with a yaml file describing what you want and providing plugins that understand those cases and install them into a snap.
[13:26] <tedg> zyga, We build two of them in and put them in directories appropriate for the architecture they're built for.
[13:26] <zyga> tedg: hmm?
[13:27] <zyga> tedg: I mean, pip, do you plan to patch pip and python to make that work?
[13:27]  * dholbach hugs ogra_ back
[13:27] <zyga> tedg: I know theory that it can work, I want to understand if you have any concrete plans for specific cases
[13:27] <zyga> tedg: all python extension build natively so far
[13:27] <zyga> tedg: and it does seem like patch-the-world problem to me
[13:27] <tedg> zyga, We have concrete plans to make that work, we started writing code for it yesterday.
[13:28] <zyga> tedg: without a solution like qemu-arm-static or simiar
[13:28] <zyga> similar*
[13:28] <mterry> zyga, we plan to cross compile in chroots like the sdk does yeah
[13:28] <tedg> zyga, I'm hoping we don't have to patch pip, but if so, we'll work with upstream to make it handle cross-compiling better.
[13:29] <tedg> Honestly, I think that multi-architecture support is something everyone wants (upstreams too) but no one has the time to work on it. It's a priority for us.
[13:29] <zyga> mterry, tedg: I'd love to dogfood anything you can share, my use cases are stuff like python3-lxml2
[13:29] <zyga> tedg: I agree
[13:29] <zyga> tedg: it's ironic that only debian did it in any sensible capacity
[13:30] <tedg> zyga, Cool, we'll probably harass you in a couple weeks after we start to get things off the ground. We're working with simpler use cases right now to get the basics together.
[13:30] <zyga> tedg: gnu hello? :)
[13:32] <tedg> BSD Hello, we're not handling complex licensing yet ;-)
[13:33] <zyga> haha
[13:33] <zyga> tedg: note that an eula is hardly needed for gnu hello
[13:33] <zyga> tedg: no license needed
[13:40] <dholbach> ogra_, our names are put next to python tutorial thing - is that on your list of things to do right now?
[13:41] <ogra_> python tutorial  ? nope
[13:41] <ogra_> i thought barry did one
[13:41] <barry> ogra_: hello? :)
[13:41] <ogra_> i'll have tzo take care for the RPi image for the rest of the week
[13:44] <dholbach> ogra_, barry: I was looking at barry's blog post, but it looks like asac preferred ricmm's approach (https://code.launchpad.net/~ricmm/+junk/example-python-snap/) and we wouldn't have to require python 3.5
[13:45] <barry> dholbach: python 3.5 isn't required for my approach, it just enables some fancy debugging and hackery
[13:47] <barry> has ricmm published any articles or docs on his approach?
[13:47] <barry> (his is py27 based; i'm firmly py3 :)
[13:47] <barry> also, mine is more of a framework for providing py3 snaps, rather than just an example of one
[13:51] <dholbach> ok... I wasn't siding with any solution, just trying to figure out where to go next
[13:51] <barry> dholbach: sure.  let many flowers bloom :)  happy to help
[13:57] <asac> dholbach: yes ricmms approach is trivial... works everwhere, doesnt solve everything though, but for getting started its absolutely fine imo
[13:57] <asac> it solves the problem: how to assemble a complete python dependency tree easily. it doesnt solve the native libs etc. parts
[13:57] <asac> or the how to include the intepreter
[13:58] <asac> but since we have python in OS image having that approach as the _simple_ way of getting started sounds good
[14:01] <ogra_> asac, not at all ... if the interpreter is gone from the system all packages that foillowed such a howto will break
[14:02] <ogra_> asac, the point dholbach tries to solve if giving developers something in their hands right now
[14:02] <ogra_> so we either take barry's approach or actually finish ricmm's to pull in the interpreter etc
[14:10] <beowulf> @reviewlist
[14:10] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
[14:10] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
[14:10] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
[14:10] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
[14:10] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
[14:19] <dholbach> barry, ^ not sure if you saw the discussion above...
[14:26] <barry> dholbach: nope, thanks
[14:26] <ogra_> beowulf, does the description in webdm come from thr redme.md now (it used to come from the store UI description before)
[14:26] <ogra_> *the
[14:27] <barry> ogra_: that's why i emphasized py3 because it probably will be a while before it disappears, although if mvo_ does port the entire system-image infrastructure to the store + a new client, that will change of course
[14:28] <barry> plus...py2 blech
[14:28] <ogra_> yeah, i wouldnt suggest to anyone to rely on interpreters in the core image
[14:28] <ogra_> we should have a tool that bundles it properly for your snap
[14:29] <barry> ogra_: certainly that's the right long term solution.  plus it lets app developers ship whatever crazy configuration that's different than ubuntu's crazy configuration of their interpreter they want
[14:29] <barry> ogra_: there have been *lots* of upstream discussion around this approach
[14:29] <ogra_> i think it should also be the short term solution ...
[14:29] <barry> as it's not just applicable to snappy of course
[14:29] <barry> maybe
[14:30] <ogra_> if we once start allowin such a habit (relying on core bits) it will be really hard to get that gone again
[14:31] <barry> ogra_: it's just that i'd like to see upstream work continue.  i'd like us to drive that so our needs are addressed, but in a fashion that's generally useful, rather than we bake our on solution that's different than everyone elses
[14:32] <ogra_> well, i dont see a problem with that ... for the time being we should have a tool that fulfills the purpose, then gets merged into snapcraft as a plugin and once upstream work is done we can replace the plugin
[14:33] <ogra_> i just dont want to encourage using core components, thats all
[14:35] <beowulf> ogra_: still store, afaik
[14:35] <ogra_> hmm
[14:36] <beowulf> ogra_: maybe sergiusens looks in the readme if there's nothing in the store?
[14:36] <ogra_> well, there is a lot in the store for chatroom
[14:36] <ogra_> (like a full paragraph)
[14:36] <beowulf> ogra_: yes, so i see
[14:36] <ogra_> and i dont find the line that webdm displays in the sotre at all
[14:36] <ogra_> *store
[14:37] <beowulf> ogra_: yup, let me check what's happening there
[14:38] <jdstrand> beuno: fyi, r473 of the review tools is the *one* (aka, I'm cutting 0.28 now) :) feel free to pull that whenever
[14:42] <beowulf> sergiusens: hey, is 'description' in snappy/webdm package api coming from? (and if readme.ms, is it possible it's being truncated on the first newline)?
[14:42] <beowulf> sergiusens: *where
[14:56] <sergiusens> beowulf: ogra_ this is from early snappy days, beuno and mvo_ are the intellectual authors for readme.md; I think the store reads the first line and it's supposed to be char limited
[14:56] <sergiusens> in any case, I think it's bad that the store let's you override anything from package.yaml
[14:56] <ogra_> sergiusens, hmm, thats pretty bad now that we dont have a "click" way to get to the used ports
[14:56] <sergiusens> it should either be free form or part of the package
[14:57] <dholbach> asac, barry, ogra_: where do we go from here regarding the python tutorial? Jamie also added his suggestion to https://trello.com/c/vbQTdIYQ/5-development-snappy-tutorial-for-python-2-3
[14:57] <sergiusens> ogra_: there is a click way, beowulf just needs to hook to the ui, ogra_ did you add the 'ui' port?
[14:57] <ogra_> i.e. hos is the user supposed to know chatroom runs on port 6565 and only works under chrome/chromium
[14:57] <ogra_> *how
[14:57] <ogra_> sergiusens, yep, i did
[14:57] <beowulf> sergiusens: ogra_: https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833
[14:57] <ogra_> external ui ...
[14:58] <ogra_> ah, ood
[14:58] <sergiusens> ogra_: great, then http://webdm.local:4200/api/v2/packages/chatroom.ogra will have ui_port (I see it here)
[14:58] <ogra_> *good even
[14:58] <sergiusens> ogra_: just need to hook up in the js side which I guess is what beowulf's MP is all about
[14:59] <beowulf> ogra_: the only bit missing is the description to tell the user it's chromium only
[14:59] <beowulf> ogra_: which you have in the store
[14:59] <ogra_> beowulf, right
[14:59] <sergiusens> beowulf: ogra_ I guess we can add a http://webdm.local:4200/api/v2/packages/chatroom.ogra/documentation that exposes the readme.md
[15:00] <ogra_> +1
[15:00] <beowulf> sergiusens: why not the store description?
[15:00] <beowulf> oh, i know
[15:00] <barry> dholbach: not sure, but i subscribed to that card so i can follow the discussions.
[15:01] <ogra_> dholbach, i guess thats something for tomorrows community sync meeting
[15:02] <sergiusens> beowulf: 2 reasons; when you upload an app, readme.md pre fills the store description (it shouldn't allow you to change it IMO); second one is to use the installed resource instead of going over the web
[15:02] <beowulf> sergiusens: yeah, no 2 came back to my mind as i hit return
[15:02] <beowulf> sergiusens: on 1, the store needs to be able to set a description per store
[15:04] <barry> ogra_, dholbach should i attend that meeting?
[15:04] <ogra_> if you feel like ... 14:00 UTC (if my math isnt wrong)
[15:05] <barry> ogra_: that's doable.  where is it?
[15:07] <dholbach> sent you an invitation
[15:09] <dholbach> barry, ^
[15:10] <barry> dholbach: awesome, thanks
[15:24] <zyga> it seems that name/executable are not working quite well and assumptions are made that name is identical to executable
[15:26] <beowulf> what are 'caps'? https://developer.ubuntu.com/en/snappy/guides/security-policy/ are they described somewhere?
[15:28] <asac> dholbach: is there a proposed text already?
[15:28] <asac> for the tutorial i mean
[15:32] <dholbach> asac, I was starting to work from http://www.wefearchange.org/2015/04/creating-python-snaps.html
[15:33] <dholbach> asac, for ricmm's example we basically just have the code
[15:33] <asac> dholbach: that thing is far too complex imo
[15:33] <asac> super hard and not working for everything but 3.5... its clearly the future, but not the short term solution
[15:33] <asac> we should put out as the easy way to get started
[15:34] <ogra_> asac, right, but we should definitely not suggest to people to rely on the py interpreter in core
[15:34] <dholbach> asac, barry just clarified: the 3.5 bits are for additional debugging
[15:35] <jdstrand> beowulf: they are not documented yet (this is a todo). we want something like this: https://developer.ubuntu.com/en/publish/security-policy-groups/ for snappy
[15:35] <jdstrand> beowulf: well, they are sorta documented
[15:35] <jdstrand> let me get that
[15:35] <zyga> ogra_: why is /tmp restricted when we can just make /tmp private to the application?
[15:36] <ogra_> zyga, it sitn restricted ... you have /tmp/snaps/<appname> for your own convenience afaik
[15:36] <jdstrand> dholbach: curious-- is there a trello card for the docs team to do the tutorial I mentioned on the list and something for ^
[15:36] <ogra_> *isnt
[15:36] <zyga> ogra_: it seems pretty broken to make /tmp read only (and teach everything not to use it) if we can just put it in a private namespace
[15:36] <zyga> ogra_: well, it sure seems to be:
[15:36] <zyga> ogra_: FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/apps/stubbox.sideload/0.21.2']
[15:36] <zyga> ogra_: now I can patch that but I feel I should not have to
[15:36] <ogra_> zyga, only the toplevel is restricted, but TMPDIR always points to the app dir anyway
[15:36] <zyga> ogra_: yes, and that's what I'm talking about
[15:36] <seb128> mvo_, the command you gave me earlier, it complains that there is no channel named "edge"?
[15:36] <ogra_> the launcher should create it
[15:37] <zyga> ogra_: well, my question stands
[15:37] <ogra_> iirc there was a bug in older images with that, but i think that has been fioxed quite recently
[15:37] <zyga> ogra_: since we are using containers making a app-private /tmp seems obvious
[15:37] <ogra_> zyga, for more details ask the security team :)
[15:37] <jdstrand> beowulf: https://developer.ubuntu.com/en/snappy/guides/security-policy/ has quite a bit of detail. there are two caps now: network-client (which can also be referred to as 'networking') and 'network-service'
[15:37] <mvo_> seb128: oh, what version of ubuntu-device-flash are you using?
[15:37] <ogra_> zyga, who uses containers ?
[15:37] <zyga> ogra_: how many libraries need patches to make non-writable /tmp work?
[15:37]  * ogra_ hasnt used a container since he started playing with snappy
[15:38] <seb128> mvo_, I've vivid + the ppa updated on friday
[15:38] <zyga> ogra_: don't we use namespace for devices already?
[15:38] <jdstrand> beowulf: if you don't specify caps at all, you get 'networking' (aka, client networking)
[15:38] <beowulf> jdstrand: thanks, we should link the first 'caps' to one of this doc
[15:38] <zyga> ogra_: s/containers/namespaces/ (which is mostly the same thing)
[15:38] <seb128> mvo_, I need wily?
[15:38] <ogra_> zyga, container means to me its an independent system ...
[15:38] <ogra_> closer to a VM
[15:38] <jdstrand> fyi, we aren't using full blown containers
[15:38] <mvo_> seb128: hm, that should be ok - give me a sec to double check
[15:39] <jdstrand> nither a system container nor an app container
[15:39] <jdstrand> ie, we aren't reinventing docker. if you need an app container, use docker on snappy
[15:39] <mvo_> seb128: could you pastebin the ubuntu-device-flash version you are using?
[15:39] <jdstrand> we do use a few containery techniques though
[15:39] <seb128> mvo_, how do I get it?
[15:39] <dholbach> jdstrand, sorry, which tutorial?
[15:39]  * jdstrand ->meeting
[15:39] <zyga> ogra_: nomenclature aside, it is broken
[15:39] <jdstrand> dholbach: let me forward you the email in a bit
[15:39] <seb128> mvo_, oh, there is an update, let me try that
[15:39] <dholbach> thanks jdstrand
[15:40] <seb128> mvo_, sorry and I guess you meant package version, I though it was a binary bundled with other things ;-)
[15:40] <ogra_> zyga, talk to the security team ... i'm sure there is a rationale
[15:41]  * zyga looks at why python crashes there, it does seem to look at TMPDIR
[15:42]  * ogra_ would be surprised if it didnt
[15:42] <barry> dholbach: i'm not sure what's "too complex" about it.  i tried to make it super easy for people
[15:42] <zyga> jdstrand: a non-writable /tmp is rather harsh, is there a rationale for it?
[15:42] <zyga> jdstrand: (understanding app separation)
[15:43] <mvo_> seb128: no worries
[15:43] <seb128> mvo_, k, still not working
[15:43] <dholbach> barry, I didn't say it was "too complex"
[15:43] <jdstrand> zyga, ogra_: I didn't read all backscroll, but see the change to the launcher in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[15:43] <barry> sure, we want to not rely on the base interpreter, but that's tractable i think
[15:43] <barry> dholbach: oh, sorry, i think asac might have
[15:43] <seb128> mvo_, it gives me "Channel edge not found on server http://system-image.ubuntu.com"
[15:43] <seb128> mvo_, version is 0.20snappy7-0ubuntu1.2
[15:44] <jdstrand> zyga: the app is supposed to have a writable tmp area. that is why TMPDIR was set. apps should not be able to read each others temp files, so they are in different dirs. the change to the launcher now creates a private mount namespace for /tmp
[15:44] <zyga> ogra_: TEMPDIR is set but TMPDIR is not
[15:44] <zyga> it's set but doens't make it through
[15:44] <ogra_> sounds liek a bug
[15:44] <zyga> ogra_: yep
[15:45] <ogra_> file it then :)
[15:45] <zyga> lp:snappy?
[15:45] <ogra_> https://bugs.launchpad.net/snappy
[15:45] <ogra_> (as the topic says)
[15:45] <zyga> thanks
[15:45] <ogra_> though i guess its a launcher bug
[15:47] <mvo_> seb128: confusing http://paste.ubuntu.com/11523152/ seems to work for me - maybe I had a typo in my earlier command?
[15:47] <zyga> https://bugs.launchpad.net/snappy/+bug/1461146
[15:48] <jdstrand> zyga: is that for a systemd service or a cli command?
[15:48] <zyga> jdstrand: cli
[15:48] <ogra_> looks like cli
[15:48] <jdstrand> ok
[15:48] <zyga> jdstrand: I can give you the snap if you want to
[15:48] <jdstrand> no, that's ok
[15:48] <seb128> mvo_, http://paste.ubuntu.com/11523181/ here :-(
[15:49] <seb128> mvo_, do you use the same server?
[15:49] <jdstrand> I was thinking it might be another bug but if it is cli, then it isn't
[15:49] <mvo_> sergiusens: are there multiple  0.20snappy7-0ubuntu1.2  ubuntu-device-flash versions around :/ ?
[15:49] <ogra_> looks simply like a typoed var
[15:49] <mvo_> sergiusens: see seb128 question
[15:50] <beowulf> @reviewlist
[15:50] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
[15:50] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
[15:50] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
[15:50] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
[15:50] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
[15:50] <beowulf> mvo_: :)
[15:50] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | No reviews (6 days old)
[15:50] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (12 days old)
[15:50] <nothal> https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (41 days old)
[15:50] <seb128> mvo_, sergiusens, sorry, it works now after the upgrade
[15:50] <mvo_> ok
[15:51] <seb128> mvo_, sergiusens, I had the previous binary copied over to try something and I forgot about it :-/
[15:51] <seb128> mvo_, thanks and sorry again ;-)
[15:51] <mvo_> beowulf: bad luck, dinner time here
[15:51] <mvo_> seb128: no worries
[16:18] <seb128> mvo_, no luck with the wily iso, boots ok on an old laptop but is not recognized by my uefi laptop config
[16:26]  * zyga hopes snappy adopts git
[16:27] <zyga> bzr changes are pretty hard to follow
[16:27]  * tbr never really grok'd bzr nor hg
[16:28] <zyga> bzr/hg/git aside, readable patches are relevant
[16:30] <mvo_> seb128: meh
[16:32] <seb128> mvo_, yeah :-/
[16:47] <mvo_> seb128: maybe worth talking to slangasek about this, I might misremember but  I think he created uefi bootable image before for snappy
[16:47] <seb128> mvo_, k, thanks
[16:47] <seb128> slangasek, hey, do you have hints about how to get a snappy iso to boot on an uefi/secure boot laptop config? the standard iso seems to not do the job
[16:49] <slangasek> iso?
[16:50] <slangasek> seb128: iso, or disk image?
[16:54] <slangasek> seb128: assuming it's a disk image that you're booting from USB, my first question would be, what version of udf did you use to master the image.  The second question (assuming you're using a suitably recent udf with UEFI support) is what the contents of partition 2 are
[17:00] <seb128> slangasek, I created an iso today using u-d-f 0.20snappy7-0ubuntu1.2 calling udf core rolling --channel edge -o img and dd-ed that to an usb stick
[17:00] <slangasek> ok, so... not an iso
[17:00] <seb128> k, "image"
[17:00] <seb128> sorry ;-)
[17:01] <Chipaca> what's the "official" url for meta.md ?
[17:01] <seb128> you want details about one of the partitions?
[17:01] <zyga> sergiusens: https://lists.launchpad.net/checkbox-dev/msg00298.html
[17:01] <zyga> ogra_: quick question about shared libraries
[17:01] <zyga> ogra_: with rpath it's almost easy to get this to wrok
[17:02] <zyga> ogra_: but .sideload vs non-sideload thing makes it problematic to hard-code /apps/$name/current/lib as rpath
[17:02] <slangasek> seb128: I'm checking the changelog for 0.20snappy7-0ubuntu1.2 now, but to my knowledge, support for UEFI lands in ubuntu-device-flash 0.21
[17:02] <zyga> ogra_: I know $ORIGIN exists, I need to see if I can use it (will it be /usr/bin/ or /apps/$name/current (?)
[17:02] <zyga> sergiusens: that's plainbox on snappy
[17:02] <zyga> I kind of like snappy
[17:03] <zyga> I just wish it was 5 years later, when it's all mature
[17:03] <zyga> and tooling is good
[17:03] <zyga> :-)
[17:03] <seb128> slangasek, k, I'm using vivid + the ppa, maybe that's not uptodate enough
[17:04] <slangasek> seb128: confirmed, the last update to goget-ubuntu-touch in the production ppas was April 23, and UEFI support landed on May 8
[17:04] <slangasek> so the snappy team needs to update goget-ubuntu-touch in the beta and 15.04 ppas
[17:04] <seb128> mvo_, ^
[17:05] <slangasek> seb128: if you need it for testing, you can use the version in the tools ppa: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/
[17:06] <seb128> slangasek, k, I'm going to try that, thanks
[17:06] <mvo_> sergiusens: -^
[17:06] <mvo_> thanks slangasek and sorry for the noise
[17:07] <slangasek> mvo_: no worries :)
[17:09] <mvo_> sergiusens: tl;dr - could you please release ubuntu-device-flash with the uefi support? or is somethng blocking and if so, how can I help :)
[17:09] <mvo_> ?
[17:26] <sergiusens> mvo_: I was going to release it as soon as someone approved an MP I created on Saturday, it's unreviewed still
[17:27] <sergiusens> mvo_: also, I'm really scared of rebuilding now if we deviate from 15.04 compatibility in trunk
[17:33] <sergiusens> Chipaca: can you review https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/properDeviceFiltering/+merge/260646 ?
[17:34] <Chipaca> sergiusens: yes
[17:35] <Chipaca> sergiusens: no tests in this, no?
[17:37] <sergiusens> Chipaca: no
[17:37] <Chipaca> ok, off to make dinner for me
[17:37] <Chipaca> o/
[17:59] <mvo_> sergiusens: thanks and sorry for the lack of reviews
[19:28]  * rsalveti finally reads backlog
[19:55] <tedg> jdstrand, So it seems that by default we give access to sed but not xargs, which one of this is the mistake? :-)
[19:56] <jdstrand> tedg: xargs is the mistake. can you file a bug against ubuntu-core-security?
[19:56] <jdstrand> tedg: is this blocking you?
[19:57] <jdstrand> I mean, I know it literally is blocking access, but, I'd like to know how fast you need it
[19:57] <tedg> jdstrand, Naw, I'll just copy it into my package.
[19:58]  * tedg *snaps*
[19:58] <jdstrand> hehe
[19:58] <tedg> jdstrand, bug 1461243
[19:59] <jdstrand> great, thanks!
[20:04] <tedg> jdstrand, Is there a way we could give a utility access to a specific directory?
[20:04] <tedg> jdstrand, The use case is that we have this snapcraft tool which will call other plugins for a language. But they need to access the user's home directory for what they're building.
[20:05] <tedg> jdstrand, It'd be nice if we didn't have to give them full access to everything, but instead snapcraft could say "oh, now this guy can have this"
[20:05] <tedg> (for this run)
[20:30] <sergiusens> zyga: I don't really follow your email, but I may need to read it with more time to grab some context
[20:31] <sergiusens> zyga: and we will switch to git once we have a nice tarmac replacement (no need for fancy stuff, can be polling based even as tarmac is today)
[20:31]  * sergiusens isn't sure what the ETA for webhooks is
[20:31]  * sergiusens isn't sure the launchpad api can list MPs for git branches
[20:47] <zyga> sergiusens: tarmac/git is in progress
[20:47] <zyga> sergiusens: the mail is just my ramblings, sorry for making it hard to read
[20:47] <zyga> sergiusens: I just wanted to show you plainbox snappyified :)
[20:48] <zyga> sergiusens: and ask if the $name.sideload vs $name could be resolved somehow
[20:48] <zyga> sergiusens: so that libraries can be used by using rpath
[20:48] <zyga> sergiusens: webhooks are not needed, AFAIR the git stuff is not exposed in the api yet
[20:50] <zyga> sergiusens: have a nice evening, bye :-)
[20:50] <sergiusens> zyga: not really; you shoulnd't rely on that path not changing
[20:51] <sergiusens> bye
[20:56] <jdstrand> tedg: if the snapcraft tool were confined, it would be possible, yes
[20:56] <jdstrand> tedg: or, the snapcraft tool could be apparmor aware and change to a profile for the plugin
[20:58] <tedg> jdstrand, I was figuring the snapcraft tool would call a binary registered by the plugin.
[20:59] <tedg> jdstrand, So that'd be effectively confined by the core launcher
[20:59] <jdstrand> hmm, I may not understand how the snapcraft tool is supposed to work. it might make sense to schedule a meeting with me and tyhicks
[21:00] <tedg> Czech Stop in West ?
[21:01] <jdstrand> heh. that would be nice :)
[21:01] <tedg> jdstrand, I think we're determining how it could work. So, if you think it shouldn't work like that, it's fine.
[21:01]  * tyhicks was there 2 days ago
[21:01] <tyhicks> :)
[21:01] <tedg> I think that the thing we want is "super easy to make snaps" everything else is negotiable :-)
[21:04] <tedg> But I was thinking the language plugins could be "apps" in the traditional sense.
[21:04] <tedg> Hoping they'll have to be as little special as possible.
[21:06] <tyhicks> tedg: is there a design doc for snapcraft at this point?
[21:06] <tedg> tyhicks, We have more of an ideas document: https://docs.google.com/document/d/166fzfKp6YIZ839KyeNj2rO976ahLxWM35_fodwbPo1U/edit#heading=h.sta78u24yxr7
[21:07] <tyhicks> tedg: thanks - I'll read up on it
[21:14] <rsalveti> elopio: we're not yet automatically updating the image published at http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ (which I have an action to check why)
[21:36] <rsalveti> sergiusens: I should know more about webhooks in a few days, when we get stakeholders meeting for launchpad
[21:37] <rsalveti> zyga: who is porting tarmac to git?
[21:38] <rsalveti> zyga: and for python, kind of the idea we had is that we'd have a devpack (that gets consumed when creating your snap) that would bundle the interpreter (but you could as well bring your own interpreter)
[21:38] <rsalveti> zyga: we don't want to use interpreters as frameworks necessarily
[21:53] <rsalveti> sergiusens: is there any sort of incompatibility with current ubuntu-device-flash related with 15.04 and rolling?
[21:54] <rsalveti> sergiusens: saw you pushed to wily, wonder if that will get stuck in proposed since we got a ftbfs for powerpc
[23:07] <sergiusens> @reviewlist
[23:07] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old)
[23:07] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old)
[23:07] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old)
[23:07] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old)
[23:07] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old)
[23:07] <sergiusens> rsalveti: yeah, it's stuck http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[23:33] <sergiusens> rsalveti: oh, and no, there's incompat today yet... key word, yet ;-)
[23:33] <rsalveti> sergiusens: right :-)
[23:34] <rsalveti> good making the release anyway since it's easier to tell people that they should be using a more recent version
[23:51] <sergiusens> rsalveti: right, I'm not sure I should be just using the ppa, most of the people we care about are on trusty
[23:52] <rsalveti> sergiusens: right, but they are all using the ppa, right?
[23:52] <sergiusens> rsalveti: and I guess all the uefi confusion was because we never migrated to the beta ppa
[23:52] <sergiusens> rsalveti: yup, they all use the ppa
[23:52] <rsalveti> right
[23:52] <rsalveti> yeah, I'll fix this ppa confusion soon
[23:53] <sergiusens> rsalveti: do you know wha the ETA is on powerpc? Or can we just blanket it through?
[23:54] <rsalveti> sergiusens: it seems doko/foundations doesn't have the time to fix the ppc builds atm, so I believe we should just ask for an override for it
[23:54] <rsalveti> so it's not blocked in proposed
[23:54] <sergiusens> rsalveti: great, so is that #ubuntu-release or #ubuntu-devel?
[23:55] <rsalveti> sergiusens: #ubuntu-release should work


[09:29] <lool> persia: Wow flags: OC in /usr/share/binfmts/qemu-arm
[09:30] <lool> but flags: in /proc
[09:30] <lool> Pff someone typo-ed that
[09:36] <lool> persia: Just after fixing flags, it works
[09:36] <lool> persia: I can sudo
[09:37] <lool> No change needed to qemu
[09:40] <persia> Heh.  It takes a night's sleep to try the obvious :)
[11:00] <lool> persia: LP #519228
[11:00] <ubot4> Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519228
[11:01] <persia> I saw the discussion in -devel.  Looks promising :)
[11:01]  * persia presses the "me too" button
[11:01] <lool> (works here)
[11:03] <ogra> sudo worked for me yesterday btw ... i only had a hostname not found warning
[11:05] <persia> ogra: OK.  Were you root at the time?  Based on the docs I read 12 hours back, it couldn't have worked.
[11:06] <persia> Because all setuid bits are being dropped by the binfmt_misc handler.
[11:07]  * persia notes that opening a chroot whilst not being root can be tricky
[11:09] <ogra> persia, i have to be root to chroot :)
[11:09] <ogra> well, i usually dont use fakechroot or fakeroot :)
[11:09]  * persia uses schroot
[11:09] <ogra> ah, right
[11:10] <persia> The other option is to do something like sudo to some unprivileged user inside the chroot.
[11:10] <ogra> whoops, i just dropped off the canonical server
[11:11] <ogra> hmm, and LP doesnt respond
[11:11] <ogra> heh, that just looked like a loose cable in the DC ... all back :)
[11:21] <lool> ogra: Try su - someuser in your chroot, and then sudo something
[11:21] <lool> It wont work
[11:21] <lool> See above bug
[11:23] <ogra> yes, i just read it
[11:23] <ogra> lool, btw, do you see something like http://paste.ubuntu.com/371902/ trying to start any gtk apps in qemu ?
[11:24] <lool> ogra: Did you file a bug?
[11:24] <lool> I didn't try running gtk+ apps
[11:25] <ogra> not yet, i was researching oem-config and ran into it ... wanted to see if its only me or a missing dep in my minimal setup rootfs
[11:26] <lool> Would anybody be interested in doing the reverse of the cleanup I did to the qemu versatile config?
[11:27] <ogra> the reverse ?
[11:27] <lool> Basically there are some configs which I turned on and ended up being armel specific (or versatile specific; it's the same) but are useless and should be turned off again
[11:27] <lool> To minimize delta with other Ubuntu configs
[11:27] <lool> For instance CONFIG_MTD doesn't actually work with qemu/versatile, so could be turned off to reduce delta
[11:27]  * ogra doesnt really care as long as there are no lockups or other bad breakage
[11:28] <lool> Flags in debian.master/configs/armel/flavour.versatile should be examined
[11:28] <ogra> and i'm sure the kernel team wont care either unless they actually get a patch
[11:29] <ogra> if something gets in my way i'll research the issue and make a change, but if its just a silent delta i'm really not concerned
[11:32] <ogra> lool, i'm currently more worried about the glibc failure i have seen and start to suspect its caused by the v7 hack we use
[11:33] <ogra> since it only fakes the v7 CPU but doesnt actually add the features cpuinfo exposes (i.e. neon)
[11:33] <ogra> (not that i have run any neon capable apps, but you know what i mean i guess)
[11:39] <lool> cpuinfo doesn't matter for neon
[11:52] <lool> I just got the double free (fasttop) error when installing packages
[11:52] <lool> It's not specific to gtk+ apps
[11:53] <lool> It was during the ldconfig trigger
[11:55] <lool> startx segfaults in Xorg here
[12:04] <lool> I also get it with gtk-demo in Xorg
[12:08] <ogra> startx works for me if i just use xterm
[12:08] <ogra> as soon as i use a toolkit it breaks, plain X seems to work
[12:08] <lool> I get a segfault when Xorg quits
[12:08] <ogra> yay, imx51 with populate_rootfs \o/
[12:08] <lool> Try running startx, leaving  your session; do you have a segfault in /var/log/Xorg.0.log?
[12:08]  * ogra hugs ApOgEE__
[12:09] <ogra> opps
[12:09] <ogra> apw i meant :P
[12:09] <apw> ogra, ?
[12:09] <ogra> lool, only if i use toolkit based apps
[12:09] <apw> ogra, thank me if it boots for you
[12:09] <ogra> apw, <ogra> yay, imx51 with populate_rootfs \o/
[12:09] <ogra> i will as soon as i can get it from the archive :)
[12:10] <apw> heh, lets hope it builds in there :)
[12:10] <ogra> wow, that changelog looks like someone nearly rewrote ext4 :)
[12:11] <apw> heheh
[12:11] <ogra> lool, i have no segfault with an .xsession that just contains xterm
[12:12] <lool> apw: This is boot speedup work for imx51?
[12:12] <ogra> lool, for ubuntu in general
[12:13] <lool> Oh and it was borken on imx51?
[12:13] <ogra> it just didnt make it in yet
[12:13] <apw> its a rebase for security and stable updates, plus a couple of patches from brian for performance
[12:13] <apw> (boot performance)
[12:13] <ogra> we try to get all the sweetness from our mainline kernel backported now that the patches dont create any hassle
[12:14] <ogra> lool, the fsl patchset just applied smoothly this time so we actually have time for kernel improvements which we try pull in as many as we can from the ubuntu kernel
[12:14] <apw> dunno if you will gain anything with such cpu limited platforms, i assume brian tested it and measured it before asking for it
[12:14] <ogra> no weird forward porting makes everything so much easier
[12:15] <apw> shame they still frig about in usb, and then wonder why usb drives fail to work properly
[12:15] <ogra> well, the devtmpfs backport surely gained us a lot already
[12:16] <ogra> so i'm suspecting the populate_rootfs stuff will too
[12:16] <apw> ogra, 'surley' ... i am guessing noone tested
[12:16] <apw> ogra, in my experience its not a gain if you only have 1 cpu
[12:16] <ogra> i did and see 2-3 sec speedup
[12:16] <persia> apw: Note that there exists Ubuntu-compatible hardware for other architectures with even less CPU performance than most available ARMv7 hardware.
[12:16] <apw> persia, indeed, but we are not targetting any specific performance for them
[12:16] <ogra> are you talking celeron without L2 cache ? :)
[12:17]  * ogra has such a thing and its slower than my babbage board
[12:17] <lool> apw: I did test devtmpfs with 2.6.32 kernels in qemu, and I can say the MAKEDEV was taking more than 5 seconds in qemu
[12:17] <lool> apw: BTW, there are further MAKEDEVs on startup ATM, perhaps we could add more devices to devtmpfs and avoid one more call?
[12:18] <apw> saved about .2s on a real machine as i recall
[12:18] <lool> apw: /etc/init/mounted-dev.conf still calls /sbin/MAKEDEV fd in all cases
[12:18] <persia> ogra: That would be but one example of a large class :)
[12:18] <ogra> i dont think it was produced in large amounts actually
[12:18] <lool> apw: Also, I wonder whether we could avoid remounting devtmpfs on top of devtmpfs; that's probably not very long, but still...
[12:19] <apw> keybuk deals with all that side, i thought all devices were made which were registered in the kernel
[12:24] <lool> I get the glibc corruption with a minimal gtk+ program which does gtk_window_new + widget_show_all + gtk_main, but not without the window
[12:26] <lool> Setting MALLOC_CHECK_=0 I can actually run the app
[13:18] <asac> ericm_: -meeting?
[13:25] <lool> ogra: I definitely get the segfault when exiting from xterm
[13:26] <lool> "startx" startx an xterm, I ^D and I get a segfault
[13:26] <ogra> hmm, i didnt have one yesterday
[13:54] <lool> dmart: Hey
[13:54] <lool> dmart: I have this glibc errors which ogra mentionned
[13:55] <lool> dmart: I wrote a trivial gtk program which reproduces these
[13:55] <lool> and it aborts but, the backtrace is either useless or useless
[13:55] <lool> dmart: I've installed our -dbgsym packages for libc6, libx11-6, gtk, pango, and cairo
[13:55] <lool> I even got a gdb segfault at some point, but not consistently
[13:55] <lool> dmart: How would I track this down?
[13:56] <lool> I can break on main() in gdb, but when I get the actual abort, it's somewhere down the gtk internals, and it's hard to break on that
[13:58] <lool> Ah!  G_SLICE=always-malloc also fixes the bug
[13:58] <lool> So it's either a bug in glib'c gslice support on armel, or in glibc's memory checks on armel
[14:00] <dmart> Add some trace I guess, if you can't get a backtrace from the segfault/abort.
[14:00] <lool> What do you mean by add some trace?
[14:00] <dmart> Don't really have bright ideas here I'm afraid
[14:00] <lool> dmart: Do you find gdb useful on armel these days?
[14:00] <lool> It frequently crashes for me
[14:01] <dmart> Which version are you using?  lucid's gdb seems a lot more stable than karmic's gdb, but maybe I was lucky.
[14:01] <lool> lucid's latest
[14:01] <lool> 7.0 helped, but it's still crashy and frequently fails finding backtrace
[14:01] <lool> In this case, I get either a corrupted backtrace or an infinite loop
[14:02] <dmart> hmmm, is there any way you can reproduce the crash?  I often get no backtrace though.  I wondering whether some components are built in a way which nukes the backtrace; or maybe there's some broken unwind info support in gdb.
[14:03] <lool> The crash only happened one time out of 6 or so, but perhaps I will be able to reproduce it
[14:03] <lool> I suspect the versatile kernel under qemu might be having some issues of its own which don't help gdb
[14:03] <dmart> Maybe you can catch it with nested gdb
[14:04] <lool> dmart: So you gdb gdb?
[14:04] <dmart> I'm sure I've managed to do this in the past.  gdb has special support for this.
[14:05] <lool> Ok; never tride this
[14:07] <lool> A simple g_slice checks works
[14:07] <lool> Folks, the glib atomics patch was removed in january
[14:08] <dmart> Hmmm, maybe we need it back in?
[14:09] <lool> I suspect we do, that might explain my issue
[14:09] <dmart> Anyway why it was pulled out?
[14:09] <lool> Is https://bugs.launchpad.net/bugs/491342 the correct reference?
[14:09] <ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
[14:09] <lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[14:09] <lool>     - dropped since that patch was added without details nor reference
[14:09] <lool>       to a launchpad or upstream bug and it's not clear if it's still required
[14:09] <lool>       now with the change done upstream recently
[14:10] <lool> Seb, who removed the patch, had fixed it when syncing 2.23.1-1 over:
[14:10] <lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[14:10] <lool>     - change to fix the build for armel
[14:10] <dmart> If the change is upstream, it shouldn't be needed; maybe take a look at the patch and make sure the relevant changes are in the code?
[14:11] <lool> Yes; glib wouldn't build without it, would it?
[14:11] <dmart> Probably not... it was a swp issue
[14:11] <lool> It built on armel
[14:12] <lool> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 was forwarded at https://bugzilla.gnome.org/show_bug.cgi?id=603780
[14:12] <ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
[14:12] <lool> Which points at https://bugzilla.gnome.org/show_bug.cgi?id=531902 which is closed
[14:12] <ubot4> Gnome bug 531902 in general "Use GCC atomic buildins for g_atomic*" [Enhancement,Resolved: fixed]
[14:12] <lool>   Bug 531902 -  Use GCC atomic buildins for g_atomic*
[14:12] <lool> Summary: 	Use GCC atomic buildins for g_atomic*
[14:12] <ubot4> lool: Error: Bug #531902 not found.
[14:12]  * persia pets ubot4 for trying
[14:12] <dmart> :)
[14:13] <dmart> Looks like it was fixed upstream, so long as ubuntu's package is now based on the new enough version.
[14:13] <lool> It's merged in out glib2.0 ubuntu package
[14:13] <lool> checking whether to use assembler code for atomic operations... checking whether GCC supports build-in atomic intrinsics... yes
[14:13] <dmart> looks good
[14:14] <dmart> Perhaps your problems are caused by something else...
[14:14]  * dmart has do disappear for a bit
[14:14]  * dmart also can't spell
[14:15] <lool> I looked at the testsuite, there is one failure trying to create files in the non-writable home, another one on threadpool-test
[14:15] <lool> and there might be more since it doesn't complete
[14:16] <lool> slice-test does pass though
[14:16] <lool> So it could also be a gtk+ issue
[14:17] <lool> In gtk+, the only failing test is abicheck; again the testsuite might not be running all tests
[14:30] <ogra> lool, it couls also be a codesourcery issue, lets wait for the actual archive build of versatile
[14:31]  * ogra still thinks its kernel related
[14:33] <lool> I have the same issues with my own cross-gcc
[14:33] <lool> Which is based on a relatively recent FSF tree
[14:33] <ogra> hmm
[14:35] <lool> Hmm it's not the same error as with ldconfig
[14:35] <lool> ldconfig was on fasttop, gtk+ is on !prev
[14:36] <ogra> lets be patient and see what an in-archive kernel brings us :)
[14:40] <lool> There's an experimental-malloc in eglibc which takes another code path
[14:43] <lool> MALLOC_CHECK_=0 G_SLICE=debug-blocks doesn't catch the error
[14:54] <lool> Ah slice-test actually fail under my kernel
[14:54] <lool> dmart, ogra: Could one of you try on real hardware with lucid userspace?
[14:54] <lool> To check whether it's a toolchain or kernel regression
[14:55] <ogra> lool, i have no issues at all on imx51
[14:55] <ogra> since weeks
[14:55] <lool> just build slice-test from glib2.0
[14:55] <ogra> i'm not sure i can get to that today but will do so if nobody else does
[14:55] <ogra> my babbage is fully swamped today
[14:56] <dmart> I'll have a go... what's the easiest way to build just the affected test?
[14:56] <lool> dmart: unpack memchunks.c and slice-test.c from glib2.0's tests/
[14:57] <lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c memchunks.c
[14:57] <lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c slice-test.c
[14:57] <lool> dmart: And then basically gcc -o slice-test *.o `pkg-config --libs glib-2.0 gthread-2.0`
[14:57] <lool> (Sorry for the noise)
[14:58] <lool> So ./slice-test 1 c 100 works and ./slice-test 1 c 1000 fails
[14:58] <dmart> ok, I'll let you know what happens.
[14:58] <lool> It works up to 512 and fails starting at 513
[14:58] <lool> dmart, ogra: What's the kernel memory allocator on your kernel?
[14:59] <lool> It's SLAB on versatile
[14:59] <lool> I think ARM requires SLAB anyway
[15:00] <dmart>  /boot/config.blah says CONFIG_SLUB=y
[15:01] <ogra> yeah
[15:01] <dmart> dunno whether that's better though
[15:08] <lool> dmart: There was a recent post of slab versus slub on<EMAIL_ADDRESS>[15:08] <lool> I don't know whether it's better or worse, but I care that it works or not   :-)
[15:08] <lool> versatile_defconfig has SLAB=y instead
[15:09] <lool> lpia, i386, amd64 and ports have SLUB=y; pretty much only versatile has SLAB=y
[15:09]  * dmart is still updating his fs
[15:10] <dmart> The versatile is probably derived from the ARM kernel trees, which tend to use a more traditional/embedded style config (for whatever reason)
[15:10]  * lool tries turning on SLUB
[15:12] <lool> Ok; that worked, let's see if I can build a working kernel with it
[15:23] <lool> it built, but for some reason I'm missing disk drivers; /me tries again
[15:35] <lool> So it still fails
[15:35] <lool> I have CONFIG_SLUB=y
[15:36] <lool> Same symptoms
[15:37] <lool> dmart: Did you manage to test on real hardware?
[15:40] <dmart> not yet... trying to do too many things at the same time...
[15:41] <dmart> argh, more update problems
[15:41] <lool> What's the issue?
[15:42] <armin76> ricing
[15:42] <dmart> Any idea what's causing the contents of the archive to be broken at the moment?  I get a load of conflicts
[15:42] <lool> dmart: I don't have that
[15:42] <lool> dmart: Perhaps some packages you have are missing on armel; I have a minimal chroot
[15:42] <ogra> mono
[15:43] <lool> Yeah I was about to mention it
[15:43] <lool> Currently mono-runtime is older than mono-gac
[15:43] <ogra> mono breaks the world and the desktop team made half the world depend on it
[15:43] <lool> So you can't install mono or ubuntnu-desktop
[15:43] <ogra> so lots of stuff is outdated
[15:43] <ogra> asac, is working on the mono ftbfs
[15:43] <dmart> Hmm, I didn't even find that among the conflicts.  But trying to install/upgrade ubuntu-desktop is certainly broken right now.
[15:43] <ogra> right
[15:44] <ogra> laincpad-integration and all the indicator- stuff are broken
[15:44] <ogra> anything that uses either will likely fail to install
[15:44] <dmart> Is that really all caused by mono?
[15:44] <ogra> yes
[15:44] <dmart> argh
[15:44] <ogra> most of the indicator bits hard depend on mono now
[15:45] <lool> Oddly it took 2 hours to build in karmic and has been building since 3 hours in lucid
[15:45] <ogra> as well as LP-integration
[15:45] <lool> Looks like the build hanged in configure
[15:46] <ogra> oh, and nautilus depends on mono as well now
[15:46] <asac> mono is a mess
[15:46] <asac> it opens zillions of files ... but only on arm
[15:46] <lool> asac: Does the buildd output looks normal to you?
[15:46] <ogra> lool, forget about the buildd :)
[15:46] <lool> ogra: ?
[15:46] <asac> lool: what do you mean?
[15:46] <ogra> for now we'd be happy to be able to build on sane HW we have full access to
[15:46] <asac> lool: i tried it locally and found that we hit the 1024 open files barrier
[15:46] <lool> asac: https://launchpad.net/ubuntu/+source/mono/2.4.3+dfsg-1ubuntu1/+build/1477421
[15:47] <asac> lool: no. that doesnt look normal
[15:47] <dmart> lool, looks like a won't have time to try and reproduce your issues right now
[15:47] <asac> and isnt what usually happened
[15:47] <lool> dmart: Ok; thanks
[15:47] <lool> I'd love to know whether this is kernel specific or not
[15:47] <dmart> sorry
[15:47]  * ogra smells one of the regular buildd segfaults
[15:47] <asac> yeah
[15:47] <lool> Perhaps someone else could try it on real hardware with up to date lucid?>
[15:48] <ogra> asac, you gave it back today, didnt you ?
[15:48] <asac> i tried it on real hardare
[15:48] <asac> same issue ... open files barrier
[15:48] <asac> i am now going to debug that
[15:48] <ogra> asac, i think lool means the qemu issue
[15:48] <asac> unfortunately i trashed the build tree
[15:48] <lool> asac: Did you complete a build after bumping the open file limit?
[15:48] <asac> oh
[15:48] <asac> sorry
[15:48] <asac> lool: no it failed later on jocote
[15:48] <lool> Yeah, I have an issue with glib under qemu
[15:48] <asac> havent tried to finish it here ...
[15:48] <lool> asac: Ah so no mono anytime soon
[15:49] <lool> I wanted to look into the double binfmt issue
[15:49] <asac> will do that after confirming for the mono guy which mono it is
[15:49] <asac> which files are kept open
[15:49] <lool> config.status: creating mono/arch/s390x/Makefile
[15:49] <lool> make: *** wait: No child processes. Stop.
[15:49] <lool> make: *** Waiting for unfinished jobs....
[15:49] <lool> make: *** wait: No child processes. Stop.
[15:49] <lool> Session terminated, killing shell... ...killed.
[15:50] <ogra> yes, we see frequent random segfaults on the buildds since a while
[15:50] <asac> thats not the real issue. most likely just random buildd bustage as ogra said
[15:54] <lool> ogra: Is there a bug about the mono-runtime binfmt format that doesn't work with qemu?
[15:55] <ogra> no, there are plenty in debian i think
[15:55] <ogra> they all point to syscall 242 though which is nonsense
[15:56] <ogra> get_sched_affinity()
[15:57] <lool> ogra: could you file a launchpad bug?
[15:57] <ogra> lool, i filed the one on the possible use of binfmt_ vs non binfmt_
[15:57] <lool> What is that?
[15:57]  * ogra cant remember the number
[15:57] <ogra> lool, bug 427863
[15:57] <ubot4> Launchpad bug 427863 in linux (Ubuntu) (and 1 other project) "binfmt allows breaking out of chroots due to not respecting namespaces (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/427863
[15:58] <lool> ogra: That one is blocked on information on your side
[15:58] <lool> Upstream and Kees both asked you for more info
[15:58] <ogra> which i dont really have time for to gather atm
[15:58] <lool> Since September?
[15:58] <ogra> yes
[16:12] <ogra> dmart, btw, do you use update-manager ? my upgrade works fine here just removes some stuff i'd rather keep, but still
[16:13] <dmart> No, that was via apt-get dist-upgrade.  I should probably switch to apt-get upgrade so it doesn't unexpectedly uninstall half the system :P
[16:13] <ogra> you are not using netbook yet i guess
[16:14] <ogra> for me only two indicators, rhythmbox, nautilus and the netboot-meta package are removed
[16:14] <ogra> stuff i can live with until it comes back
[16:17] <lool> Gah karmic userspace doesn't boot with devtmpfs
[16:18] <lool> This so sucks
[16:18] <suihkulokki> iirc the problem with mono in qemu is that it uses boehm gc which reads /proc/self/maps
[16:18] <lool> suihkulokki: that's a good point
[16:18] <lool> suihkulokki: Do you have any clue on the slice-test issues I have (see above)
[16:19] <lool> It's under qemu-system-arm with a versatile kernel, not qemu-arm-static
[16:19] <suihkulokki> havent seen any such issues
[16:19] <lool> suihkulokki: You can run gtk+ apps fine under qemu-system-arm/versatile?
[16:20] <suihkulokki> well, haven't tried versatile for ages
[16:20] <lool> You're using OMAP?
[16:20] <suihkulokki> but on omap2/omap3 no problems with our gtk
[16:20] <ogra> is omap stable already ?
[16:21] <lool> yeah, I've been tempted to switch to OMAP kernels for qemu
[16:21] <lool> suihkulokki: So which tree do you use to run qemu/omap?  plain upstream, or do you need linux-omap for qemu too?
[16:21] <ogra> is there enough in upstream to make use of it for qemu ?
[16:23] <suihkulokki> so far I've just used linux-omap kernels.
[16:23] <lool> suihkulokki: You're using the maemo OMAP3 qemu support?
[16:23] <ogra> sad, no distro option for us atm
[16:24] <lool> I see some commits from you, so I guess you do  :)
[16:24] <lool> You probably develop it too
[16:25] <suihkulokki> yep
[16:26] <suihkulokki> ogra: ...didn't stop you from shipping mx51 and dove kernels ?
[16:27] <ogra> suihkulokki, no, but for other arm stuff we can only refer to mainline, for these two arches the kernel team made explicit exceptions
[16:28] <ogra> s/arches/subarches/ :)
[16:30] <persia> Does mainline linux-omap work on qemu cleanly?  Might be easier to align, rather than chasing -versatile.
[17:10]  * ogra files bug 519398
[17:10] <ubot4> Launchpad bug 519398 in oem-config (Ubuntu) "oem-config with debconf frontent goes into endless loop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519398
[17:11] <ogra> finally some progress ...
[17:11] <ogra> seems its actually an oem-config bug
[17:11] <ogra> phew
[17:15] <persia> Can you replicate with a normal desktop install, or does it only happen with rootstock?
[17:15] <ogra> no idea, i wont do any normal desktop install atm
[17:15] <ogra> since i a) dont have a spare desktop machine to test on and b) it takes extra time :)
[17:16]  * ogra wonders why others sponsor fixes to rootstock ... why dont file people bugs so i can sponsor it :P
[17:18] <ogra> persia, though given that the debconf frontend isnt used on desktops it would have to ba a server install i guess
[17:18] <ogra> *be
[17:19] <persia> Does -server support oem-config?
[17:19] <ogra> yes
[17:19] <persia> Aha.  Make them do the testing on !armel :)
[17:19] <ogra> you can do oem server installs nowadays apparently
[17:19] <ogra> how without HW and broken qemu ?
[17:20] <ogra> i guess they are using it very rarely :)
[17:20] <ogra> probably even only testing it on x86 for milestones
[17:22]  * ogra cant belive there is a thread in ubuntu-users about /bin/flase being to big
[17:22] <persia> I thought they had working kvm.
[17:22] <ogra> *false
[17:22] <persia> heh :)
[17:23] <ogra> its like 50 mails already
[17:23] <ogra> nearly beats the "OMG OO.o was dropped by canonical" one
[17:28] <ogra> rm /
[17:28] <ogra> oops
[17:32] <persia> Um, did you really mean to run that locally?
[17:32] <persia> That command is usually followed by a ping timeout
[17:34] <ogra> heh, no i hit tab and was on an SD card subdir in another term :)
[18:02] <lool> haha
[18:02] <lool> the slice-test issue doesn't affect karmic
[18:02] <lool> So it's either a toolchain regression or a qemu bug with thumb2
[18:02] <lool> suihkulokki: ^  :)
[18:02] <lool> suihkulokki: BTW do you use thumb2?
[18:03] <lool> I know you use NEON heavily, but I'm not sure you went through the thumb2 pain yet
[18:25] <lool> It's eglibc
[18:25] <lool> Well upgrading it breaks things at least
[18:27] <ogra> funny that we dont see it on real HW
[18:28] <lool> It might be a bug in qemu or linux/versatile with thumb2
[18:28] <ogra> yeah
[18:28] <ogra> i find versatile most likely
[18:28] <ogra> we just patch the CPU naming but nothing of the instruction set at all
[18:29] <ogra> anyway, break before the call
[19:20] <cwillu_at_work> there isn't a thermal sensor on the beagle is there?
[19:20] <ogra> use your thumb ?
[19:20] <ogra> :)
[19:20] <cwillu_at_work> I can't log my thumb :p
[19:23] <cwillu_at_work> also, when setting mpurate=720, how does one also bump the voltage, or is the recommendation to do that obsolete?
[20:02] <therealgalen> Hey, I'm looking for vendors who produce high-performance ARM CPUs for use with Linux... who's out there?
[20:02] <cwillu_at_work> like, ti?
[20:02] <ojn> therealgalen: depends on what you consider high performance to be. everything is relative.
[20:02] <ogra> freescale, marvell, qualcomm
[20:03] <therealgalen> I'll get clearer
[20:06] <therealgalen> I'm looking for ARM CPUs with PCI-Express support. Examples: Marvell 88F6282 (1.6-2 GHz), Marvell MV78200 (800 MHz - 1 GHz dual core), Cavium Networks CNS3420-700 (700 MHz dual core)
[20:07] <therealgalen> ojn, ogra, cwillu_at_work: does that give you a better idea the performance range I am looking at?
[20:08] <ojn> therealgalen: Marvell is the only provider with pci-express solutions to date, I think. most others are targeting mobile devices where there's less need for high-performance interconnects.
[20:08] <therealgalen> ojn: Cavium has PCI Express too
[20:08] <therealgalen> I'm trying to find if there are any others
[20:08] <ojn> Cavium makes ARM processors? I thought they were mips
[20:08] <therealgalen> Without wading through the 300+ ARM licensees
[20:08]  * ogra has only seen marvell boards with PCI
[20:09] <ojn> ogra: dove has pci-e
[20:09] <ogra> and i'm not even sure these ones were PCIe
[20:09] <therealgalen> hey, a few starting points are better than 300+ :)
[20:09] <therealgalen> ojn: what is dove?
[20:09] <ojn> therealgalen: if PCI-e is a hard requirement, and ARM is a soft requirement, take a look at Freescale's PPC offerings as well.
[20:10] <ojn> therealgalen: The eval board for marvell's armv7 chip
[20:10] <therealgalen> ah
[20:10] <therealgalen> ojn: is it at all price competitive?
[20:11] <ojn> therealgalen: I have no idea where any of the vendors price their parts
[20:11] <therealgalen> the CNS3420-700 costs like $17/unit in 1k quantities
[20:11]  * cwillu_at_work should stop asking beagle specific questions in #ubuntu-arm
[20:12] <cwillu_at_work> ogra's tongue-in-cheek response makes sense now :)
[20:13] <therealgalen> man, powerpc...
[20:13] <therealgalen> a blast from the bast
[20:13] <therealgalen> *past
[20:13] <ogra> cwillu_at_work, nah, there are ,many people using our userspace on beagle :)
[20:14] <cwillu_at_work> ogra, I know, I'm one of them :p
[20:14] <cwillu_at_work> I just didn't realize I was in this channel:  I don't expect hardware questions to get good answers here :p
[20:15] <therealgalen> i'll just take whatever i can find, haha
[20:15] <ogra> cwillu_at_work, pfft
[20:15] <cwillu_at_work> ogra, you told me to use my thumb when I asked about the thermal monitor :p
[20:17] <ogra> well its a reliable methot to measure ... at least in the blister/no blister area of precision ;)
[20:17] <ogra> *method
[20:22] <ogra> cwillu_at_work, but you are right, i could tell you more about imx51 than omap currently my beagle B3 is sitting on the shelf collecting dust
[21:10] <therealgalen> ojn: freescale's CPUs are very expensive!
[21:10] <therealgalen> at least the PPC line
[21:47] <persia> ogra: Did you ever find a good way to suppress the extensive "qemu: Ubsupported syscall:" lines?
[22:42] <lool> persia: Implement them?  :)
[22:44] <persia> lool: Well, that works too.  ogra was talking at some point about some way to collect them and report each one only once or something.


[00:00] <h00k> rrva: I just noticed my volume keys, as well as play/pause/ff/rw have no effect
[00:02] <rrva> h00k: ok, please add info to the bug
[01:00] <h00k> So, I keep having desktopcouch-service pegging a core.
[01:00] <h00k> I kill it, it starts again. Any protips?
[01:01] <h00k> granted, I ddin't even know it was freaking out until I saw byobu report my usage as 0.99, so I checked 'top' and there it was.
[03:24] <h00k> So, any protips on killing desktopcouch-service because it's consistently pegging 100% of one of my cores?  So what's the difference between "root" and "netroot" in the recovery console now?
[03:49] <alkisg> (apart from having dhclient ran twice :D)
[06:52] <ActionParsnip> Hey guys the last installing system takes a while here using dvd of oneiric alpha2. Is this normal?
[06:53] <ActionParsnip> HDD light is flashing and suchlike
[06:54] <ActionParsnip> Skip button is greyed out. Hmm
[07:00] <ActionParsnip> Ha. Killed the process in CTRL+ALT+F1 and it booted ok =D
[07:06] <elv> hi! every time i update udev on boot i get lots of errors and then on gdm screen i have no mouse o keyboard. in order to use them i have to delete /run/udev. i don't think that the procedure it's correct. But i get runtime error /run/udev not writable
[07:08] <elv> no ideas?
[07:09] <elv> oh gosh it's written above
[07:09] <elv> sorry very much
[07:09] <elv> knwn bug.
[07:10] <elv> what about lots of indicator packages i cannot upgrade them
[07:13] <genjix> http://ideone.com/Yvm5Z
[07:14] <genjix> works in natty
[07:14] <genjix> not in oneiric
[07:21] <genjix> http://ubuntuforums.org/showthread.php?t=1802522
[07:30] <Airon90> Hi you all! I just sudo aptitude safe-upgrade my pc and my keyboard and mouse are not recognized in Ubuntu (but I can use my keyboard in terminal). How could I fix this big problem?
[07:31] <Airon90> Sorry, I saw the link in the topic :S
[08:45] <ActionPa1snip> hey guys, does anyone using pidgin have random freezing? but then coming ok
[08:46] <Charybdis> ActionPa1snip: Occasionally, yes.
[08:51] <ActionPa1snip> Charybdis: cool, I'm not crazy :)
[08:51] <ActionPa1snip> Charybdis: thanks
[08:54] <Charybdis> ActionPa1snip: Nope.  I finally figured out for me that the problem was sounds.  Since I disabled the sounds in Pidgin, I haven't had any freezes.
[08:54] <Charybdis> Tools > Mute Sounds is all I did.
[08:56] <ActionPa1snip> Charybdis: yeah seems to be bug #162701
[08:57] <ActionPa1snip> let me test :)
[08:57] <Charybdis> That explains it.
[08:57] <Charybdis> :)
[08:58] <Charybdis> Thanks ubottu.   I love pidgin :)
[09:30] <Clipaca> guys, i'm X-less. Starting X kills keyboard and mouse. Help?
[09:32] <actionParsnip> Clipaca: is it a laptop or branded system?
[09:32] <Clipaca> actionParsnip: laptop
[09:32] <dupondje> Clipaca: upgrade to newest version
[09:32] <dupondje> udev got fixed
[09:32] <Clipaca> I pulled a new udev
[09:32] <actionParsnip> Clipaca: what make and model?
[09:32] <Clipaca> rebooted
[09:32] <Clipaca> still an issue
[09:33] <Clipaca> dupondje: what version of udev should I have?
[09:33] <Clipaca> actionParsnip: Latitude E6510, intel graphics, HD panel
[09:33] <dupondje> 172-0ubuntu2
[09:34] <actionParsnip> Clipaca: the video is of no value if the mouse and keyboard are at fault, are they?
[09:34] <Clipaca> dupondje: yep, got that
[09:35] <dupondje> Clipaca: you can mv /run/udev /run/udev.old
[09:35] <dupondje> should also do the trick
[09:35] <Clipaca> dupondje: and then reboot?
[09:36] <Clipaca> actionParsnip: the mouse and keyboard aren't at fault, and the fact that it's an HD panel on intel has indeed been the cause of similar problems in the past
[09:37] <dupondje> Clipaca: yea
[09:37] <actionParsnip> Clipaca: I had the same, did a clean install of Alpha 2 and it's ok now
[09:37] <actionParsnip> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/807306
[09:40] <Chipaca> dupondje: that fixed it, thanks
[09:41] <Chipaca> actionParsnip: yeah... doing a clean install is not fixing the issue, though
[09:41] <Chipaca> actionParsnip: thank you for the bug number though :)
[09:41] <actionParsnip> Chipaca: it makes the mouse and keyboardwork, thus a fix )
[09:41] <actionParsnip> ;)
[09:59] <ebischoff> Hi all. Since this morning's updates, X server does not react anymore to mouse nor keyboard. Keyboard still works in command line. Using nvidia driver. Rings any bell?
[10:00] <ebischoff> I can still ssh and do everything else normally, only no more mouse nor keyboard in X.
[10:00] <actionParsnip> ebischoff: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/807306
[10:01] <ebischoff> thanks (yet another time i'm reporting too late ;-) )
[10:02] <yofel> ebischoff: /topic
[10:03] <ebischoff> crazy! unplugging-replugging keyboard+mouse was enough as announced! while a reboot was not enough! How come unplug-replug can be more powerful than a reboot ?
[10:04] <ebischoff> topic ? what do you mean ?
[10:04] <actionParsnip> ebischoff: read the channel topic ;)
[10:05] <yofel> sry for posting that after actionParsnip, my connection's pretty bad here :/
[10:05] <actionParsnip> yofel: its all good, it's quiet :D
[10:06] <ebischoff> ah ok. I have read the topic 1st thing when i came here, but rightmost part was truncated ;-) limited window titlebar
[10:07] <ebischoff> btw it's the 1st problem in about a month. This oneiric alpha is hyper stable. Congrats
[10:07] <yofel> you're obviously not using the broken parts :P
[10:07] <ebischoff> and using it on a macintosh, so really calling for trouble ;-)
[10:17] <ebischoff> well, i wish everyone an excellent day, goodbye
[10:54] <xapel> I am testing Oneiric in Virtualbox 4.0.10. The host (Ubuntu 11.04 64 bit) crashes every time I shut down the guest machine. Is anyone else also experiencing this? Any workarounds perhaps?
[11:16] <BUGabundo> this was fun
[11:16] <BUGabundo> some update on Friday left me with no X input till today
[11:19] <airon90> op: you could change the topic: the known issue has been fixed (just update the pc)
[12:13] <BluesKaj> hey folks
[12:17] <BUGabundo> hey BluesKaj
[12:31] <xapel> I am testing Oneiric in Virtualbox 4.0.10. The host (Ubuntu 11.04 64 bit) crashes every time I shut down the guest machine. Is anyone else also experiencing this? Any workarounds perhaps?
[12:35] <BluesKaj> hi BUGabundo
[13:18] <Squall5668> Hello all, can i ask for help with 11.10 in here or forums only?
[13:18] <Pici> Squall5668: Thats what the topic says.
[13:18] <iceroot> Squall5668: this is the correct place
[13:19] <Squall5668> ah, great (why did i disable motds again...) well, i just upgraded and got dumped to a busybox prompt, is there a way to check logs from here, or should i go with a livecd?
[13:29] <yofel> Squall5668: if you're in busybox checking the output of 'dmesg' will usually tell you what's wrong
[13:30] <Squall5668> yofel: thanks ill give that a shot, never been in busybox before
[14:05] <BUGabundo> is it just me, or blue stop being blue ?
[14:06] <BUGabundo> my dark blue font is now light blue
[14:10] <h00k> I don't know, but I think desktopcouch-service at home is still probably killing a processor
[15:10] <BUGabundo> S$ sudo ntpdate -d pt.pool.ntpdate.org
[15:10] <BUGabundo> 12 Jul 16:10:20 ntpdate[17679]: no server suitable for synchronization found
[15:10] <BUGabundo> anybody else having probs with ntp?
[15:17] <BUGabundo> iFail :(
[15:18] <BUGabundo> there's not ntpdate.org
[15:18]  * BUGabundo facepalm
[15:37] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in 23 minutes in #ubuntu-classroom
[16:17] <hifi> so, I don't have keyboard in my Xorg anymore
[16:17] <hifi> that is kinda bad
[16:17] <Daekdroom> hifi, check the /topic
[16:17] <Daekdroom> There's a fix in comment #27 of the bug report.
[16:18] <Daekdroom> !info ibus-gtk3
[16:18] <hifi> uh, the topic was just perfectly cut I thought it wasn't longer
[16:18] <Daekdroom> !info ibus
[16:19] <hifi> mm, little troubling to use browser from the tty, what is the quick fix?
[16:19] <hifi> installing ibus?
[16:19] <Daekdroom> No.
[16:20] <Daekdroom> sudo mv /run/udev /run/udev.old
[16:20] <hifi> ah, thanks a lot
[17:09] <h00k> check it - Intel gets triple-buffered pageflips, will this land in Oneric? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7538be3315b8683b05e8f6b22023baadcc0bc4da
[17:16] <Daekdroom> h00k, nope.
[17:17] <h00k> d'aw.
[17:17] <Daekdroom> Hm. It's up for the next DDX release.
[17:19] <Daekdroom> Anyway, do you have compositing now?
[17:19] <h00k> I wonder why...
[17:19] <h00k> Daekdroom: yeah, the udev issue. moved udev to udev.old
[17:20] <h00k> Daekdroom: when is the next DDX release?
[17:20] <h00k> I'm not terribly familiar with the graphics stack :(
[17:20] <Daekdroom> I'm trying to check.
[17:21] <Daekdroom> The current 2.15 driver was released mid-April
[17:22] <Daekdroom> Before that was 2.14 early January.
[17:27] <h00k> SO, the newer DDX won't drop in time for Oneric
[17:29] <Daekdroom> The FeatureFreeze occurs in a month.
[17:29] <h00k> baw
[17:29] <Daekdroom> but I have the impression that X driver releases are unpredictable.
[17:30] <Daekdroom> and you'll still have Xorg-edgers to try if you wish, anyway.
[17:34] <h00k> that's true
[17:42] <bil21al> I have updated and my top pannel indicator  are vanished ,than i install the indicator session from the terminal by using  sudo apt-get install  indicator-session.  after this the terminal said that u have already install the newer version of indicator..now can any body help me to bring back the indicators??????
[17:47] <Daekdroom> bil21al, are you sing Unity 2D?
[17:47] <Daekdroom> *using
[17:48] <bil21al> yes i  m using unity 2d.  11.10
[17:48] <Daekdroom> bil21al, I believe Unity 2D currently uses the -gtk2 packages
[17:48] <Daekdroom> So you're after indicator-session-gtk2, I believe
[17:49] <bil21al> ok i try
[17:56] <bil21al> daekdroom; no bro the indicator dosent come..i use sudo apt-get install indicator-session-gtk2  , but the indicator dosent appear
[17:58] <Daekdroom> bil21al, have you restarted unity-2d?
[17:58] <bil21al> yes i have restart my whole system
[17:59] <Daekdroom> Hold on.
[17:59] <Daekdroom> does 'killall unity-2d-panel && unity-2d-panel &disown' on a terminal work?
[18:01] <bil21al> tell me what to run in terminal
[18:01] <bil21al> ??
[18:01] <bil21al> to do so
[18:01] <bil21al> i havent do this
[18:01] <Daekdroom> That command between '
[18:01] <Daekdroom> killall unity-2d-panel && unity-2d-panel &disown
[18:01] <Daekdroom> It should restart only the panel.
[18:04] <bil21al> now only my username and  logout.shut down button came now what i do for sound indicator,network connection and all other indicaors??
[18:06] <M4tic> How's 11.10 coming along
[18:06] <Daekdroom> Install the following packages: indicator-application-gtk2 indicator-appmenu-gtk2 indicator-datetime-gtk2 indicator-me-gtk2 indicator-messages-gtk2 indicator-sound-gtk2
[18:15] <h00k> Those indicators didn't show when I was on Unity2d, but they do now that I'm on Unity3d
[18:15] <Daekdroom> h00k, it's because Unity-2D still has to be updated for the new indicators.
[18:16] <Daekdroom> So it's using -gtk2
[18:16] <bil21al> daekdrom; thank you bro my problem is solved thankx
[18:18] <h00k> oho. Makes sense.
[18:52] <Daekdroom> Odd. Very odd. For one moment, Clementine showed up in the old tray in Unity 3D
[20:07] <Daekdroom> I can't wait until the new Gwibber is uploaded.
[23:07] <alex_mayorga> anyone else with Metacity crashes on startup?
[23:09] <pereba> how to open classic menu in ubuntu 11.10?
[23:10] <alex_mayorga> pereba: I think you need to  install gnome 1st
[23:10] <alex_mayorga> Just got bug #795952
[23:10] <alex_mayorga> should I file a duplicate?
[23:11] <Daekdroom> Of course not.
[23:11] <alex_mayorga> the current one says "Incomplete"
[23:12] <alex_mayorga> https://bugzilla.gnome.org/show_bug.cgi?id=652354
[23:12] <Daekdroom> It's marked incomplete specifically on GNOME's bugzilla.
[23:12] <pereba> flash instalation never finish
[23:12] <alex_mayorga> it says that they want a valgrind, can anyone help me get them one?
[23:13] <pereba> ok done