[02:04] <tedg> jdstrand, By chance are you around? I'd like to get a snap approved in the store.
[02:04] <tedg> (it's tiny)
[07:02] <fgimenez> good morning
[07:29] <davidcalle> Morning o/
[08:01] <longsleep> good morning all
[08:27] <longsleep> so - whats the state of images ? Can i fuse to 130 and then update to 131 and all should work?
[08:34] <ogra_> yes
[08:35] <olli> gm
[08:36] <mvo> longsleep: see also my comment in #1477657, something fishy is going on with the delta generation right now
[08:37] <ogra_> mvo, the same thing as always really ... and the reason why sergiusens switched to the versioned binary names
[08:38] <ogra_> if the file didnt change system-image will simply not put it into the delta
[08:39] <ogra_> also, the update seems to work fine despite the message
[08:41] <mvo> ogra_: yeah, its not a regression, still anoying
[08:44] <longsleep> ogra_: so the fix in the snappy tooling for rollback also fixed update?
[08:44]  * longsleep tries that
[08:44] <longsleep> 130 has the fixed tool right?
[08:45] <ogra_> ah, no, you need to copy the snappy binary over to 130 i think
[08:45] <ogra_> after upgrading to 131
[08:46] <ogra_> at least if you want to do multiple back and forth rollback tests
[08:46] <mvo> ogra_: fwiw, fake-upgrade worked for me, I got auto-upgraded and rollback also works, looks like we are good here
[08:46] <longsleep> well the problem i had was that the update never touched uboot.env and thus automatic boot into the new system did not work
[08:46] <ogra_> we definitely are
[08:47] <mvo> and re-upgrade too (all using fake versions though)
[08:47] <ogra_> ricardo already copied 131 to alpha
[08:47] <longsleep> ah
[08:47] <longsleep> let me try that - i am all busy with sharing the kickstarter campaign  ..
[08:47] <ogra_> heh, looking good already
[08:47] <longsleep> anyone who wants to help - please share https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc to make a cool Snappy device
[08:48] <ogra_> (but your goal is also easy to achieve ... would be surprising if you dont make it
[08:48] <ogra_> )
[08:49] <ogra_> did you send it to heise and golem.de ?
[08:49] <longsleep> well i hope so because i want the device for myself :D
[08:49] <longsleep> ogra_: i am not directly involved the the marketing
[08:49] <longsleep> thankfully :)
[08:49] <ogra_> and ?
[08:49] <ogra_> :P
[08:49] <longsleep> i leave that to others
[08:49] <longsleep> just spamming you guys here
[08:49] <ogra_> just report it as news via their reporting mail addresses :)
[08:50] <longsleep> yeah i suppose i can do that thanks
[08:50] <ogra_> if one of them picks it up you will have your goal in no time
[08:50] <longsleep> true - i am pretty sure that my colleagues are on that already - but more helps more :P
[08:51] <ogra_> yeah
[08:53] <conyoo> longsleep, https://www.reddit.com/r/Ubuntu/comments/3efbx7/secure_and_private_video_conferencing_with_ubuntu/
[08:53] <longsleep> conyoo: nice thanks !
[08:53] <conyoo> np :P
[09:04]  * longsleep just received a shipmempt of ODROID-XU4's (USB3 + Gigabit Ethernet, Oktacore Exynos ARM) yay!
[09:06] <davidcalle> conyoo, this looks excellent!
[09:06] <ogra_> davidcalle, spread it ... share it ;)
[09:13] <mvo_> longsleep: you are not in this video or are you?
[09:14] <ogra_> mvo_, he is at the bottom in the pics
[09:14] <mvo_> olli: thanks for the bugreport (and sorry for the delay, got disconnected)
[09:25] <Chipaca> mvo_: am looking at https://code.launchpad.net/~mvo/snappy/snappy-i18n-for-go-flags/+merge/264112
[09:26] <Chipaca> mvo_: is there a reason for not iterating over options and setting each option description to i18n.G of the description after the parse?
[09:26] <Chipaca> or even before, actually
[09:26] <JamesTait> Good morning all; happy Friday, and happy Tequila Day! 😃
[09:27] <Chipaca> mvo_: ah, maybe the concern is that xgettext won't find the strings that way
[09:27] <Chipaca> hmm
[09:28] <mvo_> Chipaca: I'm not sure I understand the question, but yes, the string must be marked with something like i18n.G() so that it can be found
[09:28] <mvo_> Chipaca: I think I understand the question now and yes, if the string is somehow marked this approach works fine
[09:29] <Chipaca> mvo_: actually my main beef with this approach is that you're iterating over a list of things multiple times instead of doing a single pass
[09:29] <Chipaca> mvo_: hmm :)
[09:30] <mvo_> Chipaca: oh, I see, hmmmm
[09:30] <Chipaca> ooooh! i see a bug :)
[09:31] <mvo_> Chipaca: fwiw, I tried to get upstream to make this easier but he was of the opinion its fine with the iterations
[09:31] <mvo_> Chipaca: meeeh, a BUG?
[09:31] <Chipaca> a buggy bug
[09:32] <Chipaca> btw, me thinks hw-(.*) should be hw $1
[09:33] <Chipaca> but anyways
[09:33] <mvo_> Chipaca: yes
[09:33]  * mvo_ waits patiently for the buggy bug
[09:34] <Chipaca> mvo_: line 422
[09:34] <Chipaca> of the diff
[09:35] <Chipaca> sorry, was reading the whole thing again to catch similar ones
[09:35] <Chipaca> mvo_: can't find any other
[09:35] <Chipaca> so, anyway
[09:36] <mvo_> yay, nice catch on r422
[09:36] <mvo_> l422
[09:36] <Chipaca> mvo_: this way works; most things don't have that many options for it to be problematic
[09:36] <Chipaca> mvo_: however, i was wondering
[09:37] <Chipaca> mvo_: maybe we can arrange it so that each cmd either defines a per-cmd dict or adds to a global dict, and main.go does work?
[09:37] <longsleep> mvo_: i am in the video
[09:38] <longsleep> mvo_: at 1:40 or something
[09:38]  * Chipaca gives it a poke
[09:39] <mvo_> Chipaca: sounds like a good idea, I'm not super worried about the overhead of the iterations, but I like the elgance of it
[09:39]  * mvo_ will ponder over lunch
[09:50] <conyoo> longsleep, https://news.ycombinator.com/item?id=9940909
[09:58] <Chipaca> mvo_: +1'ed your i18n flags branch; it needs a commit message though
[09:58] <Chipaca> mvo_: ditto your atomic branch
[10:02] <Chipaca> mvo_: and ditto your review tools branch
[10:07] <Chipaca> elopio: can i note that i disagree with you needsfixing things over % vs format? the recommendation of format is not even strong enough for pep8, and many people disagree
[10:07] <Chipaca> elopio: in particular, i think most of the time format only adds unreadableness for no benefit
[10:07] <longsleep> conyoo|AW: great thanks again!
[10:07] <Chipaca> elopio: also note i disagree in the -0 sense, not in the -1 sense
[10:08] <Chipaca> i mean, i can wade through unreadable code, and have done so for a living, so i don't worry too much about it
[10:08] <Chipaca> but ¯\_(ツ)_/¯
[10:14] <Chipaca> mvo_: what cna i do to help clear up the review queue?
[10:14] <Chipaca> it's massive
[10:21] <mvo_> Chipaca: cleanup> is there more to do other than doing reviews :) ? iirc it was just that, iirc stuff was addressed its just a mater of approving or setting to needs-fixing etc
[10:22]  * mvo_ sets commit message
[10:22] <mvo_> s
[10:31] <rsalveti> fgimenez: mvo_: ogra_: I'll do a bit more testing in a few, but alpha looks fine
[10:31] <rsalveti> we need to make sure that we can do 6->7->6
[10:31] <rsalveti> and that 3->7 can still work
[10:31] <ogra_> rsalveti, how would 6-7-6 help if we only release 7 to the stable channel ?
[10:31] <ogra_> or do you want to do two releases
[10:32] <rsalveti> because with 6->7->6 we can confirm that the next stable image will update successfully
[10:33] <ogra_> ah, k
[10:33] <rsalveti> without fs corruption :-)
[10:33] <fgimenez> rsalveti, ok i'll begin with 6->7->6, you mean amd64 right? this morning armhf tip was 8 iirc
[10:33] <ogra_> since we dont migrate people we should actually encourage a re-flash
[10:33] <rsalveti> hm, let me check
[10:33] <ogra_> else they stay with the fatwrite forever
[10:34] <rsalveti> fgimenez: ogra_: yeah, sorry, 7->8->7
[10:34] <fgimenez> rsalveti, ok
[10:34] <rsalveti> ogra_: right
[10:36] <longsleep> from that i understood, when the oem snap is updated boot resources are not written right? Is there any propsed way to update u-boot and consorts without reflashing?
[10:37] <ogra_> longsleep, yes, in rolling
[10:37] <ogra_> (only proposed afaik, not implemented yet)
[10:37] <fgimenez> Chipaca, thanks for the review! :)
[10:38] <mvo_> yeah, Chipaca rocks
[10:41] <zyga> hey, do you plan to support upgrades from dual partition to single partition layout?
[10:42] <rsalveti> eventually, yes
[10:42] <rsalveti> since that would be the layout used by the phone
[10:43] <ogra_> first we have to have the single partition layout :P
[10:43] <ogra_> we're not even at prototype stage with that :)
[10:43] <mvo_> longsleep: thats correct, only u-d-f deals with the boot-assets for now
[10:43] <mvo_> longsleep: we have no plan, no. some ideas, but its tricky as the potential for screwup is huge
[10:44] <mvo_> longsleep: as ogra_ pointed out the other day, powerfailure during uboot flash and its a brick
[10:45] <Chipaca> we can't just ship partitionmagic and let people sort it out?
[10:45] <Chipaca> i probably have it on a 3.5" somewhere
[10:45]  * ogra_ puts "floppy image" on his TODO
[10:45] <zyga> Chipaca: and cyanide, once they give up ;)
[10:47] <Chipaca> we could ship a script that just wrote 0s over everything, and call it partitionmagic
[10:47] <Chipaca> when partitionmagic failed, we'd say "ah well, we tried; you'll have to reflash"
[10:47] <Chipaca> \o/
[10:48]  * Chipaca should get lunch before he does anything *actually* crazy
[10:50] <longsleep> mvo_: yes - but that is the same as with all devices - i think it would be nice to have some means to flash only u-boot environment
[10:50] <longsleep> i mean i do that all the time
[10:50] <longsleep> (manually with dd)
[10:51] <Chipaca> mvo_: I am suspicious of a branch that has two typos in the branch name alone
[10:52] <Chipaca> mvo_: but other than that https://code.launchpad.net/~mvo/snappy/snapy-out-own-xgettext/+merge/263659 seems fine :)
[10:52] <mvo_> longsleep: good point indeed, so something like "snappy reflash"? or similar (well, name sucks) but essentially a snappy command to reinstall the bootloader?
[10:52] <mvo_> Chipaca: pff, typos
[10:52] <Chipaca> mvo_: it's got a silly conflict, if you could fix that it's good to go i think
[10:52]  * Chipaca still doing the *actual* review, but it looks good
[10:52] <mvo_> Chipaca: my only concern with that branch is that its a big hammer for the `` but the alternatives seemd worse
[10:53] <longsleep> mvo_: yes - with the oem snap as provided input
[10:53] <mvo_> longsleep: I like that idea a lot
[10:53] <Chipaca> it's a lovely bejewelled (glowing) (blessed) hammer of +2 i18nage
[10:53] <mvo_> Chipaca: rotfl (and I don't use that term lightly!)
[10:53]  * Chipaca helps mvo_ up
[10:54]  * mvo_ fires up nethack to get a real hammer
[10:55] <ogra_> you have been eaten by a grue
[10:56] <longsleep> mvo_: a tool like that could even gain a brain over time and check what is actually on the disk to do more complex migrations.
[10:56] <Chipaca> longsleep: i imagine that tool would come after the separation of the updater into its own thing
[10:56] <tbr> and then /dev/zombie comes by and eats it
[10:57] <Chipaca> longsleep: (so we can update the updater before updating the system)
[10:57] <Chipaca> which makes me think snappy would come in a .snap
[10:57] <Chipaca> which makes me think of the smalltalk type system
[10:57] <longsleep> Chipaca: well - i would see this as two things. One is for offline updater - doing a update like a new flash but without loosing data
[10:58] <longsleep> Chipaca: the other is on the system itself, making this possible without an extra PC
[10:58] <mvo_> longsleep: yes, if you don't mind, file a bug and  I will add it to the trello board
[10:58] <longsleep> mvo_: ok i can do that
[10:59] <mvo_> longsleep: thanks!
[11:03] <Chipaca> mvo_: https://code.launchpad.net/~mvo/snappy/snappy-atomic-write-once/+merge/264125 also needs deconflicting
[11:03] <Chipaca> man, i let the review queue be too big for too long. sorry y'awl
[11:04] <Chipaca> conflicts everywhere
[11:05] <longsleep> mvo_: bug #1477950 added
[11:05] <nothal> Bug #1477950: Add tool to write OEM snap boot-assets to existing media <Snappy:New> <http://launchpad.net/bugs/1477950>
[11:26] <fgimenez> rsalveti, i'm getting this when trying 7->8 http://paste.ubuntu.com/11929782/
[11:26] <rsalveti> right, might be the issue we had that the kernel wasn't updated between such versions
[11:26] <rsalveti> mvo_: ogra_: ^
[11:27] <ogra_> thats harmless
[11:27] <rsalveti> we need to fix that at the system-image side
[11:27] <ogra_> yeah
[11:27] <ogra_> but mainly cosmetic atm ... longsleep opened a bug for it yesterday
[11:28] <longsleep> yes - the update should work. But i think the tool would show a messsage that one should reboot if that error would not happen.
[11:28] <longsleep> similar to snappy list
[11:28] <ogra_> right
[11:29] <fgimenez> rsalveti, ogra_ longsleep yep http://paste.ubuntu.com/11929791/ rebooting now
[11:30] <rsalveti> hm, why is the oem 1.8?
[11:30] <longsleep> any chance that we can get a 132 edge 15.04 so i could test the upgrade path without replacing snappy tool in 130 ?
[11:30] <rsalveti> you should only use oem 1.8 when testing from 3->8 (fallback might fail)
[11:30] <rsalveti> and use latest oem when doing 7->8->7
[11:30] <rsalveti> which is 1.11
[11:30] <ogra_> yeah
[11:40] <fgimenez> rsalveti, ah ok, first time i tried --oem beagleblack it booted into debian, i'll try again now
[11:40] <rsalveti> fgimenez: oh, if you got debian installed you also need to remove your current bootloader
[11:40] <rsalveti> fgimenez: or just unplug and plug power again with the boot switch pressed
[11:40] <fgimenez> rsalveti, ok
[11:41] <ogra_> nah
[11:41] <ogra_> S2 should be enough ...
[11:41] <ogra_> you need to make it boot once from the SD and it will keep usign that
[11:41] <ogra_> (by holding the S2 button i mean)
[11:41] <rsalveti> right
[11:41] <rsalveti> or
[11:42] <rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
[11:42] <ogra_> yeah, but then you have no fallback if you want to debug on the board
[11:42] <rsalveti> well, we want to make sure people are always booting with our bootloader
[11:42] <rsalveti> otherwise we might have all sorts of issues
[11:42]  * ogra_ finds it pretty conveninet to be able to boot itno debian and mount the Sd partitions to check stuff
[11:43] <ogra_> right, indeed thats more for debugging
[12:30] <jdstrand> tedg: I'm here now
[13:00] <Chipaca> mvo_: what should service status output when no service is found?
[13:01] <tedg> jdstrand, Can you approve this app? It should be pretty straight forward, but I think you're the only one doing snaps today. https://myapps.developer.ubuntu.com/dev/click-apps/3195/
[13:08] <longsleep> mvo_: can i somehow force snappy update to fetch a specific version? I am currently on 131 and would like to update the other partition to 131 as well
[13:18] <mterry> elopio, why is format ({}) considered better than % in python strings?
[13:21] <mvo_> Chipaca: a good question, maybe simply nothing if there are none and the user did not specificy a search?
[13:21] <Chipaca> sounds fair
[13:21] <Chipaca> mvo_: and if the search is via webdm?
[13:22] <Chipaca> that is: is this a special case for the commandline only, or should i expose it to webdm too?
[13:22] <mvo_> longsleep: you can do that in u-d-f, after its installed you can manually edit /etc/system-image/channel.ini and /etc/writable/cache/etc/system-image/channel.ini
[13:22] <mvo_> Chipaca: I would say just return a empty list and no error?
[13:23] <mvo_> Chipaca: unless there is a good reason for something else of course
[13:23] <Chipaca> mvo_: nope, that sounds sane to me
[13:23] <mvo_> cool
[13:27] <jdstrand> tedg: ok, approved. You can of course fix the 'lint_description' warning easily enough. however I wonder why you are targetting amd64 if there are no binaries?
[13:28] <tedg> jdstrand, Because it seems that docker can only have one architecture per symbolic name. So that'll have to pull the amd64 image, and then I'll have to have a different name for arm, arm64, etc.
[13:28] <tedg> jdstrand, At some point I can probably script that, but I'm not there yet :-)
[13:41] <longsleep> mvo_: in u-d-f .. but my system is already installed and running. I would just want to a 'force update other to latest no matter what i have booted'
[13:42] <kickinz1> ted, you can look at owncloud package, it checks the arch, then pull the  corresponding image from registry.
[13:43] <longsleep> ogra_: what was the name of the tool again which creates snaps from deb files?
[13:43] <ogra_> there is deb2snap and there is snapcraft
[13:43]  * longsleep remembers that he wanted to look at that
[13:43] <longsleep> a snapcraft that was it
[13:43] <longsleep> thanks
[13:44] <longsleep> i guess http://www.snapcraft.net/ is not it :D
[13:44] <elopio> good morning.
[13:44] <longsleep> ok - ppa https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily is good to experiment with snapcraft?
[13:47] <zyga> hey
[13:49] <elopio> mterry: it has more features, some consider it cleaner (and I agree), and it's the new standard so all py3 should use it.
[13:49] <elopio> I find it cleaner specially because the strings tend to grow. You start with one argument, and it's common to end up with a string that has four arguments.
[13:49] <mterry> elopio, fair enough, just saw your link to the python2 docs about it
[13:50] <mterry> elopio, and it is nicer when you reuse the same argument.  Can just do {0}, {0} twice
[13:50] <elopio> also I find it nice to use things like !r to format the value. There are some things to format decimals and stuff, but I haven't used them yet.
[13:51] <zyga> mterry: format is also better on tuples where % may misbehave if you don't do it carefully enough
[13:51] <mterry> fair
[13:51] <elopio> mterry: even "{nicely_named_arg1}, {nicely_named_arg1}".format(nicely_named_arg1='value')
[13:51] <mterry> elopio, so verbose!  :)
[13:51] <rsalveti> longsleep: check https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 as well
[13:52] <rsalveti> we're still working on getting it in a proper shape for release
[13:52] <elopio> mterry: yes indeed. Oh I like python very much.
[13:52] <elopio> I find it hard to switch from python to go, where everything uses short terms. On python I usually name a var index instead of i :)
[13:53] <elopio> that's so much better for reading code with my bad english.
[13:54] <mterry> elopio, beware carpal tunnel, man!
[13:57] <elopio> mterry: I have a shiny kinesis keyboard. He takes care of me and I of him.
[13:57] <longsleep> rsalveti: ok great - that looks promising thanks
[13:58] <elopio> Chipaca: noted your disagreement.
[13:59] <elopio> as it's -0, I prefer to go with the docs suggestion.
[14:05] <elopio> fgimenez: hey, I didn't notice that we can now start throwing tarmac integration runs to an ip in canonistack.
[14:05] <elopio> we just have to set it up with autoupdates and autoreboots.
[14:05] <elopio> they will fail of course, but they will fail with real regressions.
[14:06] <fgimenez> elopio, you mean having a running instance there always up, right?
[14:07] <elopio> fgimenez: yup. While we are ready with our throwable instances.
[14:07] <rsalveti> elopio: mterry: seems the amd64 build of snapcraft is failing https://launchpadlibrarian.net/212453342/buildlog_ubuntu-vivid-amd64.snapcraft_0-0~105~ubuntu15.04.1_BUILDING.txt.gz
[14:07] <rsalveti> when running the tests
[14:07] <mterry> humph
[14:07] <mterry> will look
[14:08] <fgimenez> elopio, yes, sounds good :)
[14:08] <elopio> mterry: rsalveti: Please, set your name with the 'whoami' command.
[14:08] <elopio> not sure how to solve that. I did it manually on tarmac.
[14:09] <elopio> I guess we can have a setup command on the plainbox tests?
[14:09] <mterry> elopio, whoami in what context?  irc?
[14:09] <elopio> mterry: no, bzr whoami.
[14:09] <mterry> elopio, that is set for me
[14:09] <elopio> needed for the bzr commit that it's done in a couple of plainbox tests.
[14:10] <elopio> mterry: well, yes, on your machine you have it set for sure. But on the builders it's not.
[14:10] <mterry> elopio, I see what you're saying
[14:11] <mterry> elopio, stupid bzr shouldn't error out for that
[14:11] <elopio> or we could just put bzr whoami on the two tests, before bzr commit.
[14:11] <mterry> but i understand why it does
[14:11] <mterry> elopio, yeah easiest is just a quick dumb whoami in the tests
[14:11] <mterry> that way we don't rely on environment being configured right
[14:11] <elopio> mterry: sure. Will you do it or should I?
[14:11] <mterry> elopio, i will
[14:12] <elopio> tx
[14:13] <longsleep> mvo_: does the tutorial for snapcraft exist in some stage more than the stub in https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 :D
[14:13] <mvo_> longsleep: mterry will correct me if I'm wrong, but I think thats abot it right now, we are busy working on it thouhg and hope to have something more RSN
[14:13] <ogra_> not yet :)
[14:14] <longsleep> ah just found the examples in the repository - i guess i will get it with those
[14:14] <longsleep> (Spreed WebRTC is a go server after all)
[14:16] <longsleep> mvo_: where does the software for the plugins come from?
[14:17] <mvo_> longsleep: it can be various sources, launchpad, github, the archive, local
[14:18] <longsleep> mvo_: for example http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/plugins/go1.4.yaml - where does go1.4 come from / how does it know where to find it?
[14:18] <elopio> longsleep: are you working on spreedbox? that's nice!
[14:19] <longsleep> elopio: yeah i am
[14:20] <longsleep> mvo_: ok found it - it downloads it from https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz
[14:21] <longsleep> mvo_: i am not sure if i like that - means builds cannot be automated if the build environment has no internet
[14:21] <longsleep> mvo_: i think snapcraft plugins should come from normal deb packages
[14:22] <longsleep> mvo_: or rather the third party gear
[14:22] <ogra_> longsleep, why ? you could use a pluin (or wrtite one) that only uses debs ... and provide a local mirror
[14:22] <mvo_> longsleep: well, its one way of doing it, there are more, you could have a go1.4 plugin that takes it from you local system for example
[14:22] <ogra_> *plugin
[14:22] <longsleep> ah true - i can just provide my own plugins as python modules
[14:22] <mvo_> longsleep: snapcraft mandates no policy here, its fine to write plugins that use debs of course
[14:22] <longsleep> got it
[14:22] <mvo_> longsleep: and even plan to make it really easy to share them via some repository, so that other people benefit from your work
[14:22] <ogra_> well it mandates a policy ... somehow ... "Go Wild !!"
[14:23] <mvo_> haha, ok, it does
[14:23]  * longsleep likes 'wild' a lot
[14:24] <longsleep> ok i will be making a spreed-webrtc snap with snappcraft next week then - will let you know how it goes and probably ask stupid questions
[14:26] <elopio> fgimenez: well, only detail is that snappy rolling edge is still not booting on canonistack
[14:28] <Chipaca> elopio: not booting, or not getting network?
[14:28] <elopio> Chipaca: hard to tell as I have no way to know what's happening.
[14:28] <elopio> it doesn't leave a log.
[14:29] <Chipaca> elopio: i haven't used canonistack; can't you reset an instance? like, hard reboot it?
[14:29] <Chipaca> elopio: or, better, can't you connect to a serial console of an instance?
[14:29] <ogra_> or even mount the writable partition ?
[14:29] <ogra_> from the outside
[14:30] <elopio> Chipaca: I can hard reboot. That's in progress.
[14:30] <longsleep> other questions folks: how can i install snaps which are not in the store / say i have them as a .snap file
[14:30] <Chipaca> or that, although i can't imagine building an api for that :)
[14:30] <elopio> I think the log is what comes from the serial console, maybe? don't really know.
[14:30] <Chipaca> elopio: so, if you let it boot the first time (give it plenty of time), then hard reboot it, it should come up with network the second time
[14:30] <Chipaca> elopio: if everything is alright :)
[14:31] <elopio> ok, /me waits for it.
[14:31]  * longsleep just discovered that snappy install somefile.snap seems to work
[14:31] <Chipaca> there's an abundance of wishful thinking in that, but maybe :)
[14:31] <Chipaca> longsleep: what do you mean?
[14:32] <elopio> I think there's something else wrong, because the log of my other instances appear before the network is up. But lets see.
[14:32] <longsleep> Chipaca: when i built a snap for some software, how do i install it without the store
[14:32] <longsleep> Chipaca: just install from file ?
[14:32] <Chipaca> longsleep: yes
[14:33] <Chipaca> longsleep: it's called sideloading (your package will have origin: sideload)
[14:33] <longsleep> Chipaca: ok thats simple enough then
[14:33] <longsleep> Chipaca: all right - can i sideload during image creation in u-d-f as well?
[14:34] <ogra_> yeap
[14:34] <ogra_> use the --install option
[14:35] <longsleep> ok - so just ignore it is in the "Deprecated" section?
[14:35] <lool> elopio: funny that you bring this up, the integration tests fail if git config isn't set
[14:35] <lool> longsleep: heya
[14:35] <lool> longsleep: I'm sorry we didn't manage to finish our exchange
[14:35] <elopio> lool: I didn't see that error, but I suppose it would be the same, yes.
[14:35] <lool> longsleep: I see you've submitted a snap though  :-)  how did you end up approaching this?
[14:36] <longsleep> lool: no worries i had plenty of distraction here thanks
[14:36] <Chipaca> longsleep: where in "deprecated"? i see it under "development" here
[14:36] <lool> elopio: it was failing to me due to EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull
[14:37] <longsleep> lool: the snap i submitted - you mean the ODROID oem snap? I just built it - that was quite simple. I published all the gear at https://github.com/longsleep/snappy-odroidc - might be helpful for other devices as well.
[14:37] <lool> longsleep: oh I thought you had submitted a spreed snap
[14:37] <longsleep> lool: no - not yet
[14:37] <longsleep> lool: i did build one though - but that was just hacking around
[14:38] <ogra_> lool, we're keeping him busy with re-designing the uboot process
[14:38] <longsleep> yeah - but it turned out to be harder for you than it was for me i guess :)
[14:38] <lool> longsleep: ah there's a dummy spreed snap up for review, lol; I think it's just an empty one though
[14:38] <longsleep> lool: Who submitted that ?
[14:39] <longsleep> not me
[14:39] <lool> ogra_: eh, where's that happening?
[14:39] <ogra_> lool, in 15.04
[14:39] <lool> longsleep: no, mectors, I think it's something he threw together for iotworld, but I dont think he had time to touch it since
[14:39] <longsleep> lool: yes thats too - he sent me the details
[14:39] <ogra_> lool, we moved away from txt files and fatwrite to using a binary blob environment file and put everything into variables
[14:40] <longsleep> lool: i will try snappcraft first and see how it goes and then submit one next week
[14:40] <longsleep> either with snapcraft or manually crafted
[14:40] <lool> mterry: heya
[14:40] <longsleep> lool: do you have some time to discuss the entropy issue?
[14:40] <lool> longsleep: snapcraft is comign really well; it's already able to deliver quite complex combinations
[14:41] <lool> longsleep: yes, with pleasure
[14:41] <mterry> elopio, rsalveti: sorry!  my cafe internet expired.  I'm back in my host's apt (I'm in NYC briefly) with wifi.  trunk's use of whoami is fixed
[14:41] <mterry> lool, hi
[14:41] <lool> longsleep: TBH, I'm sleep deprived so my brain is quite in slow motion, but that kind of forces me to focus on one thing at a time like IRC or email
[14:42] <lool> mterry: would love to discuss some snapcraft bits when you have some time
[14:42] <longsleep> lool: ok great thanks - summary first - whenever a snappy device boots up first time it creates some stuff which requires entropy. On embedded devices there is essentially no entropy from standard kernel
[14:42] <mterry> lool, sure
[14:42] <longsleep> lool: means any key created on first boot is weak as it was created without entropy.
[14:42] <lool> longsleep: so what surprizes me is that this must be a common problem; how is this typically solved in other embedded systems?
[14:43] <longsleep> lool: it is a common problem yes - with embedded systems and with cloud systems as well
[14:43] <longsleep> lool: in embedded systems this is solved by having a HWRNG on chip which which feeds entropy into the kernel
[14:44] <elopio> mterry: lool mentioned we need to configure git too. "EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull"
[14:44] <longsleep> lool: for this to work, ususally a system service is run (eg rngd or haveged)
[14:45] <mterry> elopio, lool: that doesn't seem to break the tests.  is that just for correctness?
[14:45] <lool> mterry: so on the top of my mind: wanted to confirm the 2 branches I had submitted are now ready for review; I brought up the jre vs jdk thing in a bug report (and using host vs target deps/java runtime during build); then there are a couple of paper cuts I've hit; lastly, I have some feedback on the new copy/tarball plugins
[14:45] <longsleep> lool: for cloud stuff you folks at canonical implemented a rather scary entropy service providing random data over the network (managed by cloud-init)
[14:45] <lool> mterry: it broke the tests for me yesterday
[14:45] <lool> mterry: on a clean vm with no git config
[14:45] <mterry> lool, I saw your branches go by.  I can start reviewing them, but did you want to talk about something outside the branches?
[14:46] <lool> mterry: I had to set the usual env vars (or I could have set git-config) for the tests to pass
[14:46] <lool> mterry: this broke snapcraft pull on top with the git commit -m 1, -m 2 etc. test
[14:46] <lool> mterry: topics I've listed above
[14:46] <lool> mterry: in no particular order
[14:46] <mterry> lool, ok...  our buildd managed, but I guess it's a fragile thing
[14:47] <longsleep> lool: so to handle the problem, two things need to happen. Services which need entropy need to first start until there is sufficient entropy. On embeddded devices this usually means that rngd has been started. Only after, any private keys can be created.
[14:47] <longsleep> lool: or host keys for SSHD for that matter
[14:47] <tedg> I'm trying to install from the store and I'm getting "snappy package not found"
[14:47] <tedg> It shows up in "snappy list" though…
[14:47] <mterry> lool, right, but the topics you listed above seem like they are  a list of the branches you submitted.  I can look at them, but I haven't yet, so I may not have the context for the discussion that you want
[14:47] <tedg> Sorry snappy search
[14:47] <lool> longsleep: I'm scared by the entropy service in the cloud too; surprized there is no support from vm providers for this
[14:48] <lool> longsleep: the hardware generators feels like the msot natural
[14:48] <lool> longsleep: why does this need a daemon rather than the kernel just using it?
[14:48] <longsleep> lool: because there can be many sources for random data, and having them all in kernel space would be complicated
[14:48] <longsleep> lool: thus it is in user space
[14:48] <lool> longsleep: I remember a long debate upstream about using the Intel hw rng from Intel CPUs (and how the NSA could potentially use this), so seems it's already the case on x86?
[14:49] <longsleep> lool: see http://linux.die.net/man/8/rngd
[14:49] <lool> longsleep: makes sense
[14:49] <longsleep> lool: yes, the kernel uses some hardware rngs directly
[14:49] <lool> longsleep: so this seems like a rather core thing that should be there on all linuxes; how come we dont include it?
[14:49] <lool> mterry: the last topic was some feedback on tarball/copy plugins
[14:50] <lool> mterry: and the jre/jdk one is one which might need discussion
[14:50] <longsleep> lool: well - first of all most people do not care. Second, most PC's do not have a extra RNG hardware
[14:50] <longsleep> lool: there are USB dongles and such for it though
[14:50] <lool> mterry: otherwise, yes, the rest was just a heads up on branches I've pushed
[14:50] <mterry> lool, (I was off yesterday and will be off half today, so I've not had much time to review)
[14:51] <lool> longsleep: so on PCs, we use the CPU provided one, and on embedded systems there's often one and we just need rngd to use it
[14:51] <mterry> lool, lay your tarball/copy feedback on me  :)
[14:51] <lool> mterry: that's fine; it's just a FYI because I've pushed a number of times to the branches and I wanted to clarify I was done for now
[14:51] <mterry> lool, cool, ACK
[14:51] <longsleep> lool: essentially yes - though it might also not be wise to always use one as some of them are really bad quality as well
[14:52] <lool> mterry: so the copy stuff is too minimal and I find it's clumsy to list the filenames directly as yaml keys
[14:52] <longsleep> lool: it should be a decision of the OEM provider how random is best created for this particular hardware
[14:52] <lool> mterry: I wanted to copy a dir over and couldn't, I wanted to do a shell glob and couldn't
[14:52] <mterry> lool, you should be able to copy a dir over.... that's intended and (I thought) tested
[14:52] <lool> didn't work for me, I think it's not a cp -r
[14:52] <longsleep> lool: i mean it is easy to provide a rngd snap, but the problem is that whatever first start stuff is done in snaps needs to rely on it
[14:53] <mterry> lool, ok...  we could add a shell glob easily enough...  you lose the ability to specify the destination easily.  Unless it's a directory I guess
[14:53] <lool>             res &= self.run(["cp", "--preserve=all", src, dst], cwd=os.getcwd())
[14:53] <lool> that wont cp -r
[14:53] <mterry> lool, yup agreed.  It was intended to do a directory.  That got lost in the shuffle I guess
[14:54] <lool> longsleep: is rngd covering 98% of the use cases?
[14:54] <longsleep> lool: for example in the Spreedbox, we have 3 sources for entropy - SOC rng in the ARM chip, Linux Kernel interrupts and our own custom TRNG device. They all feed entropy in the kernel and only when there is say at least 300 bytes entropy any key can be created
[14:54] <longsleep> lool: yes - but only after it is started
[14:54] <longsleep> lool: trick is to not create anything before it is started
[14:55] <lool> longsleep: are all rngd providers upstream, or would one also need to configure/add providers?
[14:55] <lool> longsleep: is it just enabling a list or also configuring each differently
[14:55] <lool> longsleep: sounds like a typical boot job
[14:55] <longsleep> lool: one will want to add own ones - the device names are diffent, they could be connected by SPI, USB, on chip
[14:56] <lool> mterry: the tarball plugin, I wish we'd have a way to unpack to a subdir
[14:56] <lool> basically naming the toplevel now that we automatically strip it
[14:56] <mterry> lool, first you want to strip, now you don't!  ;)
[14:56] <lool> mterry: and then, I've got bitten again with the "post-processing" use case
[14:56] <lool> mterry: eh
[14:57] <lool> mterry: well, having apache-tomcat-8.4.0/* was bad, but having LICENSE, README etc. all spread around is also bad
[14:57] <mterry> lool, I understand, I was just poking fun  :)
[14:57] <lool> mterry: I guess ultimately we want some include/exclude between steps, but a dest dir is fine for now; it doesn't seem complex
[14:57] <ogra_> mterry, stop implanting distrubing pics in my brain !
[14:57] <lool> mterry: I kind of suspected you were  :-)
[14:57] <longsleep> lool: on the odroidc the SOC device is called /dev/hwrng - the Ubuntu packge for rng-tools has some auto detection
[14:58] <mterry> ogra_, poking fun?
[14:58] <ogra_> mterry, lool stripping
[14:58] <mterry> ogra_, haha
[14:58] <lool> longsleep: so I think the proper course of action is to propose this by default on Ubuntu
[14:58] <lool> perhaps only on some architectures
[14:58] <longsleep> lool: see http://paste.ubuntu.com/11930609/ for some examples
[14:58] <lool> it might have a consequence on boot time, and it needs a security review to go in main
[14:59] <lool> longsleep: but generally, it sounds like a piece of boot we are missing and which is quite important on some platforms
[14:59] <mterry> lool, yeah a prefix dir seems reasonable (it has been floated as a general thing for any given plugin, but such discussions are ongoing).  Doens't hurt to add it to a case like the tar_content plugin that needs it most
[14:59] <lool> like setting the clock frmo hwclck
[14:59] <Chipaca> mvo_: pushed fixes to service
[15:00] <lool> mterry: post-processing: I mean that I wanted to fix files around (permissions, remove some, replace some, patch some) and couldn't because: a) there's no hook b) if you're a part Y after part X, it's not particularly easy to access part X c) when merging from multiple parts, file conflicts are explicitly prevented
[15:01] <lool> mterry: I dont know if hooks are the right answer, I dont like code mixed with the mostly declarative nature of snapcraft, so perhaps solving b) or allowing for c) would help enough
[15:01] <longsleep> lool: well - the Linux kernel is supposed to handle it. Newer linux kernels are supposed to set urandom blocking (similar to OpenBSD) until there is entropy. So the problem on some kernels is not so critical. Though, most ARM stuff from China runs on Kernel 3.10 which does no such thing.
[15:01] <lool> also, the various tarball/copy options we've discussed would make things less painful
[15:01] <mterry> lool, I'll make your nits into bugs so they don't get lost
[15:02] <mterry> lool, post-processing is a whole thing though
[15:02] <lool> longsleep: oh I didn't know urandom became blocking
[15:02] <lool> I thought the main point over dev/random was to NOT be blocking  :-)
[15:02] <lool> I see where this is going though
[15:03] <lool> mterry: yup; sorry this is a bit unstructured, I wanted to share this while it's "fresh" in my mind if "fresh" can describe my current brain status
[15:03] <mterry> lool, :)
[15:04] <longsleep> lool: so for now i am looking for ways to include rngd in my image. Though i can do nothing about the weak SSH keys which get created on first boot
[15:04] <lool> longsleep: so this feels like a mature and simple daemon; I think we should consider it for Ubuntu boot sequence short term with a design on how sshd etc. would wait for that before generating keys; the longer term fix might be a systemd implementation, with slighlty more magic (e.g plugging an USB hw rng automatically adds it to the pool and such)
[15:05] <longsleep> lool: yeah sounds a good idea for all ARM based platforms if you ask me.
[15:05] <lool> longsleep: so I can't think of a fancy hook that could use; I can think of relatively heavy hacks
[15:05] <longsleep> hehe too bad
[15:06] <longsleep> well i am going to build my own rootfs - so i can even add more heavy hacks
[15:06] <lool> longsleep: what would seem the cleanest way would be to proof of concept this into the rootfs; either remounting yours rw, or building one from scratch; the heavy workaround would be to disable system services you dont want such as SSH and provide them yourself, but only after you've started your own copy of hw rng
[15:07] <longsleep> lool: well what would i give if snappy was using upstart :D
[15:07] <ogra_> +1
[15:07] <lool> haha
[15:07] <lool> I loved upstart
[15:07] <longsleep> me too
[15:08] <ogra_> we wont get rid of it :)
[15:08] <longsleep> well we have all the gear for that random stuff for upstart
[15:08] <lool> oh really
[15:08]  * ogra_ herad there are no plans to move the unity8 sessions over to systemd
[15:08] <lool> ok, I need to break away
[15:08] <longsleep> lool: yeah - a fistboot service which blocks
[15:08] <lool> I'm dead anyway
[15:09] <lool> longsleep: so I think next step is to engage in Ubuntu (and/or Debian!) discussions on enabling this on systemd systems and important services in the short term, and engaging with systemd upstream on a proper design
[15:10] <longsleep> lool: yes - i am still in the process on understanding the systemd boot and how it gets built into snappy rootfs
[15:13] <longsleep> lool: hacky but works just fine: http://paste.ubuntu.com/11930663/
[15:13] <ogra_> how do you mean "how it gets built into snappy rootfs"
[15:13]  * longsleep needs something similar for snappy
[15:13] <ogra_> we install debs in a chroot and then tar that up
[15:14] <longsleep> ogra_: yeah - and the device tree what happens with it?
[15:14] <ogra_> separate
[15:15] <longsleep> i mean i guess i could just use our current rootfs builder to build the rootfs - just need to make it to work with snappy
[15:15] <lool> longsleep: so I find it weird that you read a load of entropy; if it's to make sure that it's coming from rngd, why not read it after it started?
[15:15] <ogra_> for the supported arches we simply install the kernel deb into the chroot after the rootfs tarball was created ... and pick the bits out of the chroot into a device tarball
[15:16] <longsleep> lool: well yeah - this is just to make sure to get rid of any possible bad entropy
[15:16] <ogra_> but that has nothoing to do with systemd
[15:16] <longsleep> bad means not so random
[15:17] <lool> longsleep: right, so perhaps do that after starting the daemon
[15:17] <longsleep> lool: yeah true - i guess it would be better that way
[15:17] <lool> first, this has less chances of blocking, second, you wont have more bad entropy created between the time where you read it and the daemon being ready
[15:17] <longsleep> lool: correct
[15:21] <longsleep> lool: let me change that in the repo :)
[15:22] <longsleep> lool: but i think i made my points clear, cloud-init and such would have to run after entropy is available.
[15:22] <longsleep> lool: we wait for 200 bytes - which is quite a lot
[15:23] <longsleep> check your devices: cat /proc/sys/kernel/random/entropy_avail
[15:23] <lool> longsleep: I suspect this will have to be benchmarked by cloud folks working on the images for various cloud providers
[15:23] <longsleep> probably fine right now (but check then on boot)
[15:23] <lool> longsleep: (one other thing they care about is boot time)
[15:24] <ogra_> lool, lol
[15:24] <lool> sometimes, it's acceptable to have less security for not too valuable VMs or if the networking environment is closed
[15:24] <ogra_> lool, so they developed cloud-init to make the boot time more interesting ?
[15:24] <longsleep> lool: well yes - i think cloud-init is beyond repair and snappy should just drop it and implement the three four things instead
[15:24] <ogra_> longsleep, +1
[15:25] <longsleep> lool: also for cloud images, you have the entropy service - so it should be quick and rngd would make no sense
[15:25] <lool> ogra_: I suspect that demos where one creates 2000 containers or vms will get impacted if we add something which might block for a random number of seconds/minutes
[15:25] <lool> say, this cloud provider has a broken this or that rng implementation and it blocks his boot, we'll be in hot water
[15:25] <ogra_> lool, seriously, clud-init reliably adds 30-50 seconds to our boot process
[15:25] <ogra_> not sure where the speedup should be here
[15:26] <lool> ogra_: I dont understand the argument you're making
[15:26] <lool> it's ok to slow down the boot because they've slowed it down already?
[15:26] <longsleep> lool: yeah - true though i think most cloud providers pre seed their images with a seed file. So the kernel has entropy instantly.
[15:26] <lool> I'm not worried about a small impact on the boot, but more of a random boot delay in some configurations
[15:27] <lool> longsleep: wow, you've had some strong words against cloud-init
[15:27] <ogra_> lool, no, i'm sayin lets speed up the boot by getting rid of cloud-init ... i simpüly found your argument funny that cloud people care about bootspeed while we are constantly suffering from cloud-init doing exactly the opposite for us
[15:27] <ogra_> (not to mention that we have distro tolls for everything cloud-init does and could simply use them)
[15:27] <ogra_> *tools
[15:28] <longsleep> yeah it does a lot of things where only few will be used together - i guess it is valid for automatic deployments in clouds but i fail to see the need on embedded devices
[15:28] <longsleep> especially now that cloud init is the reason to ship python2 and python3
[15:28] <longsleep> (as far as i see)
[15:28] <ogra_> yes, that too
[15:29] <ogra_> my biggest concern is that it is a reinvention of existing distro tools that wokrs a lot slower and adds extra pain where we could use saner methods to achieve the same
[15:29] <longsleep> i just say leave cloud init to clouds and do not use it in embedded devices :)
[15:30] <ogra_> if the cloud peaople actually need images from us i would rather build an ubuntu-core-cloud rootfs then to have cloud-init everywhere
[15:30] <ogra_> (and no, i dont belive that rewriting it in go is better than using distro ways for the bits we need)
[15:32] <lool> longsleep, ogra_: FYI, there's a cloud-init rewrite underway but it's still young https://github.com/stackforge/cloud-init
[15:32] <ogra_> lool, yes :/
[15:32] <ogra_> not what i'm aiming for
[15:33]  * ogra_ wants it gone
[15:34] <longsleep> if i really have to build own rootfs i guess it will not include cloud-init if i can make it work without it
[15:36] <longsleep> ogra_: btw - i have other challenges on boot as well, i need to set certain sysctl stuff - some can be set late, but others need to be set during initrd - any idea how i could do that from the oem or device parts?
[15:36] <ogra_> not really, except for hacking the initrd ... which i wouldnt do
[15:37] <longsleep> ogra_: i am doing that already :D
[15:37] <ogra_> (will be a pain to keep in sync)
[15:37] <ogra_> and i want us to get to a generic initrd that nobody needs to change
[15:37] <ogra_> (like we use on the phone)
[15:38] <longsleep> ogra_: currently i am only removing lib/modules and lib/firmware from the initrd i extracted from the preinstalled tarball
[15:38] <ogra_> (sergio was working on that before he went on paternity leave)
[15:38] <longsleep> so i gess that is minimal
[15:38] <ogra_> yeah, and the generic one would have that inside
[15:38] <ogra_> *would not
[15:41] <longsleep> that would be ok, but i still have to add some scripts to init-top and init-bottom phases - how do you feel about that?
[15:42] <longsleep> i guess the other kernel settings could be made by a snap on boot (preferably the oem snap)
[15:42] <longsleep> can the oem snap provide services?
[15:43] <ogra_> why do you need them that early ?
[15:44] <longsleep> ogra_: because DHCP might fail otherwise
[15:44] <ogra_> uh ?
[15:44] <ogra_> then we need to fix DHCP on the rootfs
[15:44] <longsleep> yeah .. some chip issues with certain switches
[15:44] <longsleep> no its a kernel driver thing
[15:44] <longsleep> the DHCP client is not responsible
[15:44] <ogra_> hmm
[15:45] <longsleep> has todo with the interrupts which get used by default for the NIC
[15:45] <elopio> fgimenez: did you hit this one? https://bugs.launchpad.net/snappy/+bug/1477657
[15:45] <ogra_> so my idea is the following: http://paste.ubuntu.com/11930798/ ... theoretically you could also have an img file alongside that provides top or bottom scripts for the initrd to be loop mounted on demand
[15:46] <elopio> fgimenez: I'm seeing that message.
[15:46] <fgimenez> elopio, i've seen that this morning but it was updating anyway
[15:46] <longsleep> ogra_: sounds reasonable - though for me no modules are required in initrd
[15:47] <fgimenez> elopio, my current problem is that it refuses to boot in b...
[15:47] <longsleep> (i am not adding any modules or firmware)
[15:47] <elopio> fgimenez: well, but I would think that this bug leaves a corrupted b.
[15:47] <mterry> elopio, why in your format_strings1 branch, do you take setup_dirs() outside of the common test case class?
[15:47] <longsleep> ogra_: why would you put the system-a/b into squashfs images as well?
[15:48] <ogra_> longsleep, sure, but thats the generic bit ... i dont want to have porters to touch the initrd at all
[15:48] <ogra_> longsleep, saving space and being able to ship everything readonly on one partition
[15:48] <elopio> mterry: because not all tests need it. And when it is run, it will change the environment, so it needs a cleanup.
[15:48] <ogra_> actually it shoudl rather look like http://paste.ubuntu.com/11930813/
[15:48] <longsleep> ogra_: mhm ok - for this to work a general hook would be required so people can do things in initrd.
[15:49] <mterry> elopio, sure...  so you could do addCleanup eh?  I get about not all tests needing it.
[15:49] <elopio> mterry: so far there seems to be only one test needing it, so I put it there. If we need it in more places, we can make a specific test case for it
[15:49] <ogra_> longsleep, as i said... there could be init-top.img and init-bottom-img
[15:49] <ogra_> longsleep, so you would put your scripts inside and initrd would loop mount them in the respective script dirs
[15:49] <mterry> elopio, you also put a blank line before 'import yaml', I think under the belief that it's a local import?  But it's not
[15:49] <longsleep> ogra_: oh yeah got it - that would be nice
[15:50] <ogra_> that way you can provide your own script without having to mangle the default initrd
[15:50] <fgimenez> elopio, according to ogra_ and longsleep the update should work regardless of the error message, it's a cosmetic problem atm
[15:50] <ogra_> fgimenez, right, it suppresses the reboot message though
[15:50] <elopio> mterry: it's third party. From pep8, you should put the std python imports, a newline, the third party imports, a new line and then the local imports.
[15:51] <mterry> elopio, if the pep8 tool doesn't care, I have a hard time caring.  ;)  But sure, OK.  I get it
[15:52] <elopio> I should provide pep8-as-a-manual-service and make tons of money out of it.
[15:53] <mterry> elopio, or just fix the pep8 tool to catch this stuff  :)
[15:53] <mterry> (does it have a --pedantic mode?)
[15:54] <jdstrand> tyhicks: this is kinda annoying:
[15:54] <jdstrand> Jul 24 15:50:35 localhost kernel: [  261.778262] audit: type=1326 audit(1437753035.869:23): auid=1000 uid=1000 gid=1000 ses=1 pid=1016 comm="ls" exe="/bin/ls" sig=31 arch=c000003e syscall=41(socket) compat=0 ip=0x7f19462c40b7 code=0x0
[15:54] <elopio> mterry: https://github.com/PyCQA/pep8/issues/329
[15:54] <elopio> let's call it a --super-correct mode :)
[15:55] <jdstrand> tyhicks: I used 'ls -l <something>' in an app that didn't have 'network-client/networking' and got a socket() denial
[15:55] <jdstrand> seccomp arg parsing is getting to be more of a priority I think
[15:55] <mterry> elopio, in CommonTestCase.test_set_plugin, shouldn't you have an addCleanup?
[15:55] <tyhicks> probably so
[15:55] <tyhicks> I can't imagine why that would require a call to socket()
[15:55] <tyhicks> but it doesn't matter much
[15:56] <jdstrand> netlink?
[15:56] <tyhicks> possibly
[15:56] <jdstrand> yeah, I wasn't going to spend time looking at it. just mentioning that it is annoying
[15:56] <elopio> mterry: yes, I think I should have.
[15:56] <tyhicks> jdstrand: I agree that arg parsing is going to important soon
[15:57] <elopio> mterry: maybe, move that cleanup to the base TestCase ?
[15:57] <elopio> so it's always cleaned up even if it wasn't changed.
[15:58] <mterry> elopio, sure
[15:58] <mterry> elopio, it's going to look weird without the corresponding setup_dirs call, so maybe add a comment explaining why we don't do that call
[15:59] <elopio> ok.
[15:59] <elopio> mterry: I dislike this global var in the module. But I couldn't think of an alternative.
[16:00] <mterry> elopio, yeah the core of this code grew out of a prototype so some code barriers are a little loose
[16:01] <ash_charles> Hello.  I'm running into a bug with ubuntu-device-flash (https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1464054)
[16:01] <elopio> mterry: could we try to use plugins from the local dir, and if not found, go to /usr/share ?
[16:01] <ash_charles> it looks like the bug has been fixed but I'm looking for a debian package for this code that includes the fix
[16:02] <ash_charles> any way to track down such a package?
[16:03] <mterry> elopio, you mean always look at ../../share/snapcraft/plugins?  (where ../../ is relative path from wherever the python module for snapcraft is -- do we always know the install layout?)
[16:03] <mterry> whoops
[16:03] <mterry> I mean always look at ../../plugins
[16:03] <mterry> (that's the one for the bzr dir
[16:03] <jdstrand> tyhicks: erf, same with the 'id' command
[16:04] <ogra_> ash_charles, https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
[16:04] <mterry> elopio, ^  feels odd to go looking at what would be /usr/lib/python3/plugins
[16:04] <ogra_> (note that there might land things that had zero QA though
[16:04] <ogra_> )
[16:04] <elopio> mterry: yes. Always try. Like putting on get_plugindir:
[16:04] <elopio> if os.path.exists(os.path.join(topdir, "setup.py")):
[16:04] <elopio>    ../../plugins
[16:04] <elopio> else:
[16:04] <elopio>    /usr/hsare
[16:05] <ash_charles> ogra_: thanks---I'll give this a whirl
[16:06] <mterry> elopio, I suppose...  and then we can unit test that by mocking os.path.exists I guess
[16:06] <elopio> mterry: yes, I still find it weird. But I think I like better to delay the check, instead of having to run a previous setup_dirs step.
[16:06] <elopio> mterry: why don't we put the local plugins in ~/something, like bzr ?
[16:06] <mterry> elopio, ...  those aren't local plugins
[16:06] <mterry> elopio, that check is testing whether we're running from a bzr checkout or not
[16:06] <elopio> oh, right.
[16:07] <elopio> there was something in pkg_resources that I think we used once...
[16:08] <longsleep> ogra_: there is another tool i would like to see on snappy by default: http://linux.die.net/man/8/fbset - any thoughts on that?
[16:08] <elopio> It was like we could use pkg_resources to find stuff, either installed or relative to the module. I don't really remember.
[16:09] <fgimenez> have a nice weekend  o/
[16:09] <elopio> any way, this is weird. I think we can find a better way to handle it.
[16:09] <ogra_> longsleep, hmm, not really for embedded ... that soounds like something for snappy-personal
[16:09] <longsleep> ogra_: how do you control the framefuffer for bbb or rpi2 ?
[16:09] <davmor2> ogra_: so why am I getting guid and uid issues following your guide to install snappy desktop?
[16:09] <ogra_> we dont even enable graphical output on snappy devices yet
[16:10] <longsleep> ogra_: a that explains it then
[16:10] <davmor2> ogra_: http://paste.ubuntu.com/11929712/
[16:10] <longsleep> ogra_: i am showing a full screen logo now
[16:10] <ogra_> and i think you dont really want fbset on embedded setups
[16:10] <ogra_> davmor2, using the wily u-d-f ?
[16:11] <ogra_> (pre-wily cant build personal)
[16:11] <davmor2> ogra_: yes or it doesn't download at all :)
[16:11] <longsleep> ogra_: ok true - problem is that i need it in in initrd :/ so a snap would not help so much
[16:11] <mterry> lool, tar and tarfile don't handle evil paths automatically?  That's stunning
[16:11] <ogra_> longsleep, well, for that such a loop mounted img would serve as well :)
[16:12] <longsleep> ogra_: exactly
[16:12] <mvo_> tarfile even warns about this in its docs, but yes, its stunning
[16:12] <ogra_> davmor2, what version of u-d-f exactly ?
[16:12] <lool> mterry: yeah, it blew my mind too
[16:12] <davmor2> ogra_: I installed ubuntu-device-flash_0.27-0ubuntu1_amd64.deb which is the wily version right
[16:13] <ogra_> hmm, i'm even on 0.26 and it worked last time i tried personal
[16:13] <ash_charles> ogra_: thanks---this worked for me :)
[16:14] <davmor2> ogra_: I just grabbed it from packages.ubuntu.com under wily :)  http://paste.ubuntu.com/11930919/   see it has personal listed which the vivid one didn't
[16:14] <ogra_> davmor2, there is bug 1470727
[16:14] <ogra_> but no movement on it
[16:14] <elopio> rsalveti: were you following federico's issue with update from 7 to 8?
[16:15] <elopio> I've just reproduce it.
[16:15] <davmor2> ogra_: so this 9.1GB is crap then right which would explain why it doesn't run then right :)
[16:15] <ogra_> most likely, yes
[16:16] <rsalveti> elopio: not yet, which issue?
[16:16] <rsalveti> (still on call)
[16:16] <davmor2> ogra_: that's fine as long as I know it is not something else :)
[16:16] <ogra_> i would try to confirm, but i dont really feel like doing a 2h download right now
[16:16] <davmor2> ogra_: not a worry dude just wanted to be sure :)
[16:17] <ogra_> definitely a u-d-f thing i think
[16:17]  * mvo_ gets dinner, telegram if the world explodes
[16:17] <elopio> rsalveti: flash 15.04 alpha#7, update to #8, reboot. It returns to #7, but keeps #8 selected for the next reboot.
[16:18] <elopio> ogra_: was it you he was working on it? ^ I don't remember what he said.
[16:20] <davmor2> mvo_: telegram telegram telegram.......oh wait no your safe just some muppet letting of fireworks ;)
[16:20] <davmor2> you're even
[16:21] <ogra_> elopio, 7 has a broken snappy still
[16:21] <ogra_> i only tested on the edge channel from 130 to 131
[16:21]  * Chipaca just leaves this here: http://www.cnx-software.com/2015/07/22/odroid-c1-board-is-an-upcoming-upgrade-to-odroid-c1-board/
[16:22] <longsleep> ogra_: cant you guys just trigger a 132 so we could test a real update with uboot.env ?
[16:22] <ogra_> rsalveti, ^^^ what do you think ?
[16:23] <longsleep> Chipaca: yeah the Spreedbox will have the ODROID-C1+
[16:24] <mterry> elopio, you use {!r} for a path.  Why is repr preferred for a path?
[16:24] <rsalveti> ogra_: sure, just trigger it
[16:24] <elopio> mterry: not for a path. For a string that you want to keep quoted.
[16:25] <ogra_> longsleep, rsalveti ... build running
[16:25] <elopio> we have an inconsistent use of things that we keep quoted and things that we don't. But if we want quotes, !r makes it nicely.
[16:27] <mterry> elopio, that seems like a really backdoor way to get quotes.  repr is defined as a string that eval can consume.  It happens to have quotes for some things but maybe the object passed to format is a complex object whose str() and repr() are very different.  Isn't it more robust to just put the two ' quote strings in the message itself?  It's the same number of characters.  It also lets translators use language-specific quotes (some languages do << an
[16:27] <mterry> d >> right?)
[16:27] <mterry> elopio, (not that we translate snapcraft yet)
[16:30] <ogra_> rsalveti, oh, and i got the ok to seed ubuntu-fan now
[16:30] <ogra_> (and the dnsmasq dep is actually gone i was told)
[16:32] <elopio> mterry: I had the feeling that !r was better, but you broke it for me. I'll replace it.
[16:32] <mterry> elopio, actually, if you wanted to be REALLY fancy, you'd use unicode curved quotes too
[16:32] <mterry> :)
[16:37] <elopio> ツ
[16:40]  * longsleep cannot grep anything because the stuff has so many typos :/
[16:41] <longsleep> kernel get hdmimode form uboot is 720p
[16:41] <longsleep> of course i grepped for "from uboot" ...
[16:44] <longsleep> is there some snappy logo artwork (svg or similar) i can use to display on the odroid?
[16:44] <longsleep> now that i can display full screen logos whould be a shame to ship a oem snap without one
[16:45]  * ogra_ would just grab the one from the websire
[16:45] <ogra_> *site
[16:45] <longsleep> if i would find a svg
[16:46] <longsleep> svn source for this one would be nice: http://1.bp.blogspot.com/-WgJN2_s3n5s/Va02zVflRDI/AAAAAAAA944/Sfi8vpEqNgQ/s1600/Screenshot%252Bfrom%252B2015-07-20%252B12%25253A58%25253A17.png
[16:46] <ogra_> potrace ftw ;)
[16:46] <longsleep> err no :P
[16:54] <Rlyeh> Hello guys
[16:54] <Rlyeh> Ogra_, I want to install the "OS.js". It's not available in snappy store, but in uappexplorer.com! How Can I install it on BBB?
[16:55] <ogra_> Rlyeh, it wont be installable currently ... the format of snaps changed and i didnt find the time to port the os.js snap over
[16:56] <ogra_> http://people.canonical.com/~ogra/snappy/snaps/ you could try to sideload it ... but i'm pretty sure snappy will just error and tell you that snaps with namespace arent allowed
[16:56] <longsleep> ogra_: did you push the updated BBB oem snap to the store already?
[16:56] <ogra_> longsleep, mvo did
[16:56] <ogra_> shoudl be at 1.11
[16:56] <longsleep> ogra_: so it will just not work when you install that OEM with stable channel?
[16:57] <ogra_> longsleep, not until we released the rootfs
[16:57] <longsleep> ogra_: ok - so i suppose i can add this breakage too then
[16:58] <ogra_> Rlyeh, i'll try to get to that on the weekend and will produce a new OSjs snap
[16:59] <Rlyeh> ogra_, Greaaaaaaaaaaat. Thank you :)
[17:00] <ogra_> np, it was low on my prio list since i didnt actually expect any users :)
[17:00] <Rlyeh> It's an useful app for snappy
[17:00] <ogra_> yeah, ist a fun thing
[17:01] <longsleep> yeah autopilot just triggered
[17:03] <ogra_> oh, really ?
[17:03] <ogra_> i dont see the new rootfs on system-image yet
[17:03] <longsleep> yeah i also do not get what it actually did
[17:04] <longsleep> seems i am booted to 129 for some reason
[17:04] <ogra_> lovely
[17:04] <longsleep> probably changed to many vars manually
[17:04] <ogra_> yeah
[17:04] <ogra_> i had the same issue yesterday
[17:04] <ogra_> being on b while the system expected a
[17:04] <longsleep> exactly
[17:05] <longsleep> let my try to clean this up
[17:05]  * ogra_ just did a clean re-flash
[17:05] <ogra_> ah
[17:05] <longsleep> i guess i should do that too
[17:05] <ogra_> and there is 132
[17:06] <longsleep> at least now i am at 131
[17:06] <longsleep> so lets try update then
[17:07] <longsleep> so far so good - it replaced the old 129 - now reboot
[17:08] <longsleep> yah
[17:08] <longsleep> (ODROIDC)ubuntu@odroid:~$ snappy list -v
[17:08] <longsleep> Name        Date       Version Developer
[17:08] <longsleep> ubuntu-core 2015-07-24 132     ubuntu*
[17:08] <longsleep> ubuntu-core 2015-07-23 131     ubuntu
[17:08] <longsleep> odroidc     2015-07-23 0.3     *
[17:08] <longsleep> worked like a charm
[17:08] <longsleep> great job!
[17:09] <ogra_> :D
[17:09] <ogra_> was your job too ... dont underestimate how much you helped us :)
[17:10] <longsleep> ogra_: well i try to help myself and get need to get detail understanding how things work with snappy. And you guys are really helpful with that - i highly appreciate it
[17:38] <Rlyeh> How can I change timezone? I read about 'config' command, but I don't understand how to set the timezone!
[17:42] <Rlyeh> "(BeagleBoneBlack)ubuntu@localhost:~$ snappy config ubuntu-core" just returns values :(
[19:46] <lazyPower> question, if i need to modify the docker sandbox on the arm2 package, i should be able to just edit the snap in /apps/docker/current/meta/packageyaml and rebuild/isntall from this on the host correct?
[19:46] <lazyPower> s/arm2/armhf/


[19:59] <amblin> based on the website, I'm guessing this group is defunct?
[20:02] <Techman> I don't know
[20:02] <Techman> I don't know if this channel is dead or not


[03:08] <ortloffa> looking for help with internet connection sharing. tried  The network connections program and firestarter. no luck yet. would appreciate some direction.
[03:08] <ortloffa> looking for help with internet connection sharing.
[03:09] <LinoSP> does lubuntu 11.10 hsa support for i386 arch??
[03:09] <ortloffa> tried Network Connections and Firestarter.
[03:12] <ortloffa> hmm. started working without doing anything
[04:31] <kirua> hi
[04:31] <kirua> is lubuntu better than xubuntu ?
[04:31] <holstein> lol
[04:31] <holstein> thats an opinion... if you would like to talk facts, i can
[04:37] <kirua> if xubuntu lags and is slow on live cd, its most certainly going to lag once installed right ?
[04:37] <holstein> i think its safe to assume that *any* os will run slower from CD
[04:37] <holstein> and faster when installed
[04:38] <Unit193> What are your system specs?
[04:39] <holstein> any modern system should run lubuntu or xubuntu with no trouble
[05:41]  * LubuntuPowered is running on a 11+ year old system
[05:46] <bioterror> kirua, from my point of view it is, becouse I know how to configure Openbox ;)
[05:58] <JohnDoe_71Rus> bioterror: if i change gdm to lxdm this error http://postimage.org/image/o6vx11ikh/ then plug usb-flash
[05:59] <bioterror> you have something broken
[05:59] <JohnDoe_71Rus> if i try open mount flash in nautilus http://postimage.org/image/fdq3nko9x/ this error
[05:59] <bioterror> you have problems with policykit
[06:00] <JohnDoe_71Rus> http://pastebin.com/aT5sFZgh xsession-errors gdm
[06:01] <JohnDoe_71Rus> http://pastebin.com/7scSuBH3 xsession-errors lxdm
[06:01] <JohnDoe_71Rus> how to fix it?
[06:04] <bioterror> your system is really mixed up
[06:04] <bioterror> lubuntu wants to use xfce4-power-manager, you're using gnome-power-manager
[06:04] <bioterror> if that's 11.10
[06:06] <JohnDoe_71Rus> yesterday change gnome-power-manager
[06:06] <JohnDoe_71Rus> use 10.04
[06:06] <bioterror> 10.04, isnt that old? :)
[06:06] <JohnDoe_71Rus> it is lts
[06:06] <bioterror> is your computer i586?
[06:09] <bioterror> JohnDoe_71Rus, wakeup!
[06:09] <JohnDoe_71Rus> P4 2.40GHz
[06:09] <bioterror> then it's not lts for you
[06:09] <bioterror> :)
[06:09] <JohnDoe_71Rus> why?
[06:10] <bioterror> there's really no idea think that lubuntu 10.04 is LTS, devs have only promised to support it becouse of i586 support. and that's only becouse those are old computers
[06:10] <bioterror> but as your computer is 2005 >>, you can easily run the latest
[06:11] <bioterror> and as LXDE is rather new and under heavy development, you should run "the latest"
[06:11] <Unit193> But it's not recommended to run Pangolin yet
[06:12] <JohnDoe_71Rus> hm... update too much
[06:12] <bioterror> and 10.04 is freakin' ugly
[06:12] <pangolin> yeah, don't run me.
[06:12] <JohnDoe_71Rus> :)
[06:12] <bioterror> pangolin, dont you worry, he only ruins you
[06:13] <bioterror> JohnDoe_71Rus, give it a shot for 11.10 ;)
[06:13] <pangolin> bioterror: you mean to say it can get worse!
[06:13] <JohnDoe_71Rus> bioterror: if ubuntu 10.04 lts then ubuntu-minimal lts too? what different what kind de use ?
[06:14] <bioterror> JohnDoe_71Rus, I dunno if you've been reading mailing list, but the lubuntu 12.04 wont be LTS neither from the lubuntu point of view
[06:15] <Unit193> I must ping pangolin quite a lot...
[06:16] <bioterror> Unit193, what's that feeling in your chest? :)
[06:16] <Unit193> I know it's hair ON the chest...
[06:16]  * bioterror has no hair on chest
[06:17] <bioterror> Unit193, but you can still have moustaches! http://www.youtube.com/watch?v=q24pIUfPCUI
[06:17] <bioterror> I'm growing atm.
[06:18] <IAmNotThatGuy> Unit193, bioterror wrong channel :P
[06:18] <Unit193> No kidding
[06:23] <bioterror> no skidding, use the brakes!
[06:24] <bioterror> JohnDoe_71Rus, will you give a shot for the 11.10?-)
[06:24] <bioterror> wish I could leech it and dd if=lubuntu-11.10.iso of=/dev/sdb for you ;)
[06:25] <JohnDoe_71Rus> bioterror: 11.10 test livecd
[06:25] <JohnDoe_71Rus> may be reinstall
[06:26] <bioterror> ;)
[06:26] <wxl> anyone recommend a good video editor? must work with mpeg since that's what my video cam records in
[06:26] <bioterror> wxl, try them all and try to select the one that sucks less
[06:27] <wxl> gee, thanks
[06:27] <bioterror> http://en.wikipedia.org/wiki/List_of_video_editing_software#Open_source_software
[06:28] <bioterror> pitivi was horrible
[06:28] <bioterror> jimbo has once again wasted all the money on girls and booze and is asking for more
[09:28] <Mendru> Hello =) I have a question. I have removed 2 programms from my system, but the menu entry is still there. How to regenerate the lxdemenu?
[11:17] <maraz> bioterror: interestingly, your fix did completely disable the windows key menu. :)
[11:18] <bioterror> you still have it ;)
[11:18] <bioterror> was it ctrl+esc
[11:18] <maraz> yes
[11:19] <maraz> only launching the menu on keyup and if there were no other keys pressed would be the best behavior imo
[15:22] <wakejagr> is there a list somewhere of the packages that are on the lubuntu livecd?
[15:23] <iceroot> wakejagr: the packages-file from the cd
[15:28] <wakejagr> thanks.  good place for such a list.  i should have thought of that
[15:28] <stlsaint> wakejagr: we learn something new everyday ;)
[18:17] <Hot> Hi,I'm looking for a network monitor under lubuntu
[18:17] <Hot> can you suggest me something ? is there something already in the lubuntu distro ?
[18:17] <Hot> thanks
[18:18] <wxl> Hot: for lxpanel?
[18:18] <Hot> yes,if possible yes
[18:18] <Hot> also in text mode is fine
[18:18] <wxl> well not sure what to tell you about lxpanel
[18:19] <wxl> at least if you want something more than what network-manager is
[18:19] <wxl> you might look to conky or gkrellm
[18:19] <wxl> or if you want something for lxterminal, ntop
[18:19] <Hot> thanks a lot wxl,ntop is perfect
[18:20] <wxl> np
[18:20] <Hot> lubuntu is the best...
[18:20] <wxl> yes it is :D
[18:20] <Hot> you need to try it with a dual core.. is fast as light and it's complete... (I was with ubuntu before but after unity I stopped it)
[18:21] <Hot> lubuntu is done in a smart way
[18:22] <wxl> it's just what you need
[18:22] <Hot> wxl,yes I agree,for someone that uses the pc for work,it's perfect.did you try to install skype 64bit ? it takes a lot (that is the reason beause I was looking for a network monitor program)
[18:23] <wxl> no i haven't tho i did use 32bit
[18:24] <Hot> mmm,I can try to download the 32bit verson of skype instead of the 64 version...
[18:27] <Hot> aaaah ,it workssssss
[18:28] <Hot> just it takes a lot do download the files
[18:28] <Hot> amazing
[18:28] <wxl> that's microsoft for you
[18:30] <Hot> lubuntu is amazing...
[18:30] <Hot> really
[18:31] <bioterror> Hot, open terminal and install bmon
[18:31] <Hot> thanks bioterror
[18:31] <bioterror> it will draw you nice graphs about network usage
[18:32] <Hot> bioterror: is the program that i was looking for
[18:32] <Hot> perfect
[18:32] <Hot> thanks
[18:32] <Hot> also skype 64 works perfectly
[18:35] <wxl> box-look.org
[18:36] <wxl> although technically you want openbox themes
[18:36] <Hot> thanks!
[18:40] <wxl> when you find one you like, put it in ~/.themes (you'll need to create it), and then you should be able to select it in Preferences > Openbox Configuration Manager > Theme
[18:41] <Hot> thanks wxl
[18:41] <wxl> np
[19:18] <Speedfx> Do Openbox themes work with Lubuntu?
[19:18] <wxl> yep
[19:19] <wxl> when you find one you like, put it in ~/.themes (you'll need to create it), and then you should be able to select it in Preferences > Openbox Configuration Manager > Theme
[19:19] <wxl> box-looks.org should have what you're looking for
[19:20] <Speedfx> Oh Openbox configuration manager?
[19:20] <Speedfx> Not Appearences?
[19:20] <wxl> you can do the same in Preferences > Customize Look And Feel > Window Border
[19:21] <Speedfx> Yea I know I got some Openbox themes(2 with a .obt/ some not) but the taskbar doesn change
[19:21] <wxl> it won't
[19:21] <wxl> that's lxpanel
[19:21] <wxl> different
[19:22] <Speedfx> Ahh I see
[19:22] <wxl> right click lxpanel > Panel Settings > Appearance
[19:22] <wxl> you can try "system theme" but it may not in the end give you the results you want
[19:23] <wxl> might have to tweak font color, etc.
[19:23] <Speedfx> Ok
[19:24] <Speedfx> Mhmhmmh, can find lxpanel anywhere
[19:25] <wxl> um
[19:25] <wxl> it's the bottom bar
[19:25] <wxl> that's what you're talking about, right?
[19:25] <wxl> the "taskbar"
[19:26] <Speedfx> yup
[19:26] <wxl> well there you go
[19:26] <wxl> right click on it
[19:26] <Speedfx> NO I mean Panel Settings has no Appearance option
[19:26] <wxl> or if you want it super easy, type "lxpanelctl config" in lxterminal
[19:26] <Speedfx> No*
[19:26] <Speedfx> woopsadaisy nvm
[20:30] <elz89> I have installed RSSOwl from GetDeb, onto Lubuntu Oneiric. When I click an article I get: An error has occurred. See error log for more details.
[20:30] <elz89> Could not initialize class org.eclipse.swt.internal.gnome.GNOME
[20:31] <elz89> Does it just not work with LXDE?
[22:15] <david_j_r> Can anyone advise on editing the apps menu in Lubuntu 11.10?
[22:26] <david_j_r> I'll take it that's a "no", then! ;)
[22:54] <psychx-> Lubuntu is awesome!!
[23:18] <psychx-> I am having problems with activating my ATI drivers. I have had this problem on both Ubuntu and Lubuntu. The driver I am trying to activate is called "ATI/AMD Proprietary FGLRX graphics driver (post-release updates)". Can someone help me?
[23:21] <holstein> psychx-: the process will be the same for *buntu in general
[23:21] <psychx-> The error I get is "Sorry, installation of this driver failed. Please have a look at the log file for details: /var/log/jockey.log" - My jockey.log file is pasted here: http://pastebin.com/UD1AuFJn
[23:21] <holstein> check this out https://wiki.ubuntu.com/BinaryDriverHowto/ATI
[23:23] <psychx-> holstein: When I go to the ATI website to enter my graphics card details, any linux distro is not an option. Should I just check one of the Windows ones?
[23:24] <holstein> psychx-: no
[23:24] <holstein> you dont need a driver for windows
[23:24] <holstein> you should reference that wiki like i dropped earlier and let us konw if you have questions :)
[23:24] <psychx-> Ok, then the instructions do not help me. It states to enter my card information.
[23:24] <psychx-> I am.
[23:25] <psychx-> It references me to this website: http://support.amd.com/us/gpudownload/Pages/index.aspx
[23:25] <psychx-> Take a look, you will see it asks for operating system details.
[23:25] <holstein> i would just get the driver
[23:25] <holstein> move on to the next part
[23:25] <psychx-> ok
[23:26] <psychx-> Well the problem is, at the next part, it is telling me to do exactly as I have done - which is where I am at now, with an error message stating to see the log file.
[23:27] <psychx-> I go to Additional Drivers in Lubuntu. Then it finds the driver, and I hit activate. Then it gives me the error message.
[23:28] <holstein> psychx-: ? im reading errors about an nvidia driver?
[23:28] <wxl> scroll down holstein
[23:28] <wxl> near thebottom
[23:28] <wxl> look for the errors not the warnings
[23:28] <holstein> i see
[23:28] <holstein> wxl: feel free and just take over
[23:28] <wxl> 2011-11-16 18:15:38,414 ERROR: Package failed to install:
[23:28] <wxl> dpkg: error: dpkg status database is locked by another process
[23:28] <wxl> that's interesting
[23:28] <wxl> i'm not trying to take over per se, just trying to help
[23:29] <wxl> and i don't necessarily know what the issue is there either
[23:29] <psychx-> I JUST installed Lubuntu, the only other things I have done is do an update, and install Smuxi.
[23:29] <wxl> did you have synaptic or apt running at the time psychx- ?
[23:29] <holstein> loolks like it should be easy though
[23:29] <holstein> dpkg: error: dpkg status database is locked by another process
[23:29] <psychx-> lemme check
[23:29] <wxl> seems subsequent errors relate to things not being installed which points back at the dpkg error
[23:29] <holstein> or the update manager or something else doing pacakge managerment
[23:29] <wxl> i think that's the bugaboo
[23:29] <wxl> yep
[23:29] <wxl> gdebi
[23:30] <wxl> aptitude
[23:30] <psychx-> Synaptic was running. I'll try to activate again. :x
[23:30] <wxl> herp a derp
[23:30] <holstein> that would be easy :)
[23:31] <psychx-> lol
[23:31] <wxl> that was it, psychx- ?
[23:31] <psychx-> 1 sec
[23:31] <psychx-> "installing"
[23:32] <psychx-> it's just kind of sitting there, so either its working - or its not. lol
[23:33] <psychx-> Didn't work.
[23:33] <wxl> run lxtask and see what's going on
[23:33] <wxl> same issue?
[23:33] <wxl> pointing at jockey.log?
[23:33] <psychx-> yeah
[23:33] <psychx-> Want me to upload it again?
[23:33] <wxl> cat /var/log/jockey.log | grep ERROR
[23:34] <wxl> let's make it simple
[23:34] <psychx-> ok
[23:35] <psychx-> http://pastebin.com/MRKBYQ4E
[23:36] <wxl> ruh roh that's not right at all
[23:36] <wxl> ok, time to be a pita and ask for the whole darn thing :/
[23:36] <psychx-> lol ok 1 sec
[23:38] <psychx-> http://pastebin.com/Au0X5mr2
[23:38] <wxl> please enjoy game deaths while you wait https://www.youtube.com/watch?feature=player_embedded&v=gJ6APKIjFQY#!
[23:44] <psychx-> I'm gonna have a quick smoke.
[23:45] <wxl> before you go
[23:45] <wxl> i think you might be kind of screwed on this one
[23:45] <psychx-> yeah?
[23:45] <wxl> there's a confirmed bug in launchpad
[23:45] <wxl> https://bugs.launchpad.net/jockey/+bug/870560
[23:45] <wxl> no fixes released yet
[23:45] <psychx-> Hmm
[23:46] <psychx-> Do you think it would be eventually fixed?
[23:46] <wxl> absolutely
[23:46] <psychx-> Ok
[23:46] <wxl> i would add yourself to that one
[23:46] <psychx-> There is another driver I can install, but I figured that post-release would be better.
[23:46] <wxl> you can do "ubuntu-bug -u 870560" in lxterminal and it will add to that report
[23:47] <psychx-> ok
[23:47] <wxl> if for some reason it doesn't grab your jockey.log, post it up there
[23:48] <psychx-> I have to sign in?
[23:52] <psychx-> Ok, I signed up and signed in and gave this computer access to it. Now I'm getting an error that says, "You are not the reporter or subscriber of this problem report, or the report is a duplicate or already closed. Please create a new report using "apport-bug"."
[23:53] <psychx-> That's what happened when I typed this: mike@mike-lubuntu:~$ ubuntu-bug -u 870560
[23:53] <wxl> uh wtf
[23:53] <psychx-> after I had already signed up and signed in and gave permission.
[23:53] <wxl> ah it is a dupe
[23:53] <wxl> i'm a dork
[23:53] <wxl> https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/873058
[23:53] <psychx-> lol
[23:53] <wxl> use 873058 instead
[23:54] <psychx-> Just said the same thing =/
[23:55] <wxl> hm try clicking on "this bug affects you" in your browser and THEN try
[23:56] <psychx-> Ok, I did that. "This bug affects you and 49 other people."
[23:56] <psychx-> but I'm still gettin that error.
[23:56] <wxl> retarded
[23:56] <wxl> i'm gonna shake launchpad until it behaves
[23:56] <psychx-> lol
[23:57] <wxl> well you could always post your jockey.log and leave a comment at least :/
[23:58] <psychx-> yeah I'll do that


[01:06] <RTG> Hi
[01:08] <RTG> Ive not been using linux on a desktop machine (as opposed to, say, my Pi) in a while, is there a way to start a program with a low priority? Im having the problem that whenever i try to start utlimaker cura, it works allright - except it doesnt if i allready have any other application even a webbrowser open, then it locks up the system  and i can reach for the power button. Becouse starting that is just to much of a load for my
[01:08] <RTG> machine.
[01:10] <RTG> (my machine being a core2duo E5700 after my ryzen 3700 main rig died, no idea whats up with that, RIP, so, yes, that load is quite a bit for this machine)
[01:13] <tomreyn> RTG: "nice" is a utility to modify a processes' priority.
[01:17] <tomreyn> RTG: more swap *may* also help
[01:17] <tomreyn> or cgroups
[03:09] <keithzg> On Kubuntu you can also use KSysGuard as a GUI for seeing what processes are using what, and reprioritising them (it's very similar to the Task Manager on Windows). Although, on such a system, KSysGuard may be too much additional overhead itself :D
[04:51] <eelnice> whats up guys
[04:54] <eelnice> anyone have a inside on how to configure No Man's Sky on linux
[05:51] <keithzg> Frankly I'm lazy enough that if it doesn't work with Proton out of the box I generally don't bother, heh
[07:29] <keithzg> Finally noticed a problem after my upgrade to 21.04 a few days back: Gwenview no longer fits images right (ie. Zoom To Fit used to correctly maximize the image, now it makes it tiny in the middle of the area)
[07:32] <keithzg> There's a (new, I assume) option to "enlarge smaller images" that was unchecked and returns the behaviour to what it previously was, but that was quite surprising (especially in that it's contrary to what I expect from the term "zoom", haha)
[08:15] <maher> hello everyone
[08:16] <maher> thanks for kubuntu developer for the hard work and for the perfect OS thy offer
[08:17] <maher> i just want to say thanks awesome OS vary vary powerful
[08:40] <maher> i have Windows 10 but it is nun-comparable to kubuntu performance and feature
[08:40] <maher> wish you the best
[11:22] <lumo_e> heyo
[11:22] <lumo_e> I've switched from Gnome to KDE recently
[11:22] <lumo_e> for some reason my wifi download speed is extremely slow now
[11:23] <lumo_e> does kde use a different connection management compared to gnome?
[11:25] <lumo_e> btw I'm using the plasma 5.23 beta ppa
[11:25] <lumo_e> on 21.10
[11:33] <RikMills> lumo_e: no, Kubuntu uses the same underlying networking packages and config as main ubuntu
[11:34] <lumo_e> :(
[11:34] <lumo_e> any idea as to what I should look at to troubleshoot this?
[11:46] <maher> maybe you exceed your bandwidth limits
[11:53] <Mekaneck> is there still such a thing in 2021? Most providers give you unlimited bandwith these days.
[11:54] <maher> i dot know
[11:55] <maher> i add Ubuntu desktop on Ubuntu 20 04 and every thing is perfect
[11:55] <maher> try driver page in update tap
[11:56] <maher> maybe you find drivers is not installed or not in use
[12:30] <maher> sorry kubuntu
[12:55] <BluesKaj> Hi folks
[18:29] <Guest9905> helo
[18:35] <airsoftmodels_> is it a bad idea to add xscreensaver to kde?
[18:59] <mparillo> I have not tried it, but https://askubuntu.com/questions/1152896/how-to-use-xscreensaver-on-kubuntu-18-04-20-04-kde-plasma makes it look possible.
[20:35] <giuseppe_> ciao
[22:59] <franko> I'm not using it either, but I see no reason why xscreensaver in KDE woud be a bad idea...
[23:00] <franko> now that you mention it, I'm actually tempted to install it myself... XD
[23:01] <keithzg> Security, that's the issue. If you're not too worried about someone physically at your computer having perhaps an easier time getting into a locked session or seeing the state of your screen behind the screensaver, I don't know if there's any concerns, but that's where the concerns reside IIRC.
[23:02] <franko> I see. But how comes?
[23:02] <keithzg> Old stuff, is what it comes down to :D A lot of the same reasons why X11 is being replaced with Wayland.
[23:03] <franko> yeah, OK...
[23:04] <keithzg> To be fair I'm not sure xscreensaver was ever nearly as bad in this regard as Gnome's X11 screensaver stuff, but that's another story...
[23:04] <franko> I think Mate is still using it..
[23:07] <keithzg> As per https://www.jwz.org/xscreensaver/faq.html#gnome-screensaver, "Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.", okay I'll stop trying to stir up trouble now and go off for a walk :D
[23:08] <franko> anyway, last time I've used XScreensaver was as a cool backdrop for poetry reading I've had -- there is a lot of cool possibilities for showing text. But even then, it was not activated as the screensaver... So don't really know how it is when it comes to screenlocking these days.
[23:13] <franko> @keithzg Never seen that before... XD


[02:00] <kumool> anyway to make left click minimize a window?
[02:00] <kumool> more of an xfce question
[02:34] <krytarik> kumool: I'd hazard the notion that it's the default behavior of the Window Buttons plugin - if the concerning window already has focus.
[02:36] <kumool> Ah, fixed, finally!
[02:37] <krytarik> ಠ_ಠ
[02:37] <kumool> thanks!
[02:37] <krytarik> Welcome!
[15:56] <tsglove> Hello.  I am connecting to a Xubuntu installation, where I installed vnc4server.   In the ~/.vnc/xstartup    I have the    startxfce4 &      line.   Yet when I connect to that machine via VNC, I get the (I believe) X11 window (black/white little squares).
[15:56] <tsglove> Any idea what could be the problem here?
[17:35] <Kangarooo> Hello. To have new better comparison of all Ubuntu distros, im asking for crowdsourcing help of everyone working together to share knowledge together in one spreadsheet. At start 7 Ubuntu Flavors Compared: Kubuntu vs. Lubuntu vs. Xubuntu vs. MATE vs. Budgie vs. Studio  http://bit.do/UbuntuCompare Anyone can add more details for each distro


[20:04] <jimsky7> looking for MySQL advice in a new install where I'm changing the datadir for MySQL
[20:07] <jimsky7> done it a hundred times but it's failing on current Ubuntu 10.04 EC2 ami


[05:58] <mac_v> nemo: http://jimmac.musichall.cz/log/?p=177 , this is a good explanation of why the bigger sizes of the icons are needed ;)
[05:59] <mac_v> nemo: we did the 64px icons because UNR used the 64px icons in the menus , and rather than scaling the 48px icons  , we thought the icons if present in 64px would help make the appearance look better.
[06:00] <mac_v> we will also be adding more 128px icons sizes , for icons which are used in bigger sizes
[06:08] <mac_v> nemo: also the panel size depends on the font size and not the icon size , contrary to what you state above. Reduce the font size and the panel will also be smaller , I'm using a 19px panel
[06:10] <mac_v> reduce the application size and the panel will also allowed to be smaller
[06:10] <mac_v> application font size*
[10:33]  * ckontros waves
[10:35]  * SiDi doesn't.
[10:36] <ckontros> :(
[10:36]  * SiDi bounces instead
[10:48]  * thorwil is reminded of the bouncing ball intro of the old ghostbusters game
[10:48] <thorwil> http://www.youtube.com/watch?v=_Lh-xwAopy0
[11:51] <ckontros> Anyone know why GIMP.org is down?
[12:20] <thorwil> ckontros: the site is sad because the name "gimp" is being discussed on the list once more!
[12:20] <ckontros> What? The "name" is under discussion?
[12:22] <thorwil> ckontros: yes. though it is _very_ unlikely anything will happen. someone suggested to replace the Gnu with Perfect ... ;)
[12:22]  * thorwil leaves for a bicycle ride
[12:22] <ckontros> Ahh...
[16:38] <nemo> mac_v: I reduced font sizes
[16:38] <nemo> mac_v: and wasn't able to get the panel smaller
[16:38] <nemo> mac_v: the instant I shrank start-here.png the panel reduced in size
[16:39] <nemo> perhaps you're suggesting that what is forcing the 22px image instead of the 16px image is font dependant?
[16:39] <nemo> anyway. others have run into the same thing
[16:39] <nemo> the panel says it is 19px high, but is actually 24, until start-here is shrunk
[16:39] <nemo> I'd just as soon keep the font size I have though, with a smaller icon
[16:40]  * ckontros , with his fonts set to 8px can reduce the panel to 19pixels.
[16:40] <nemo> mac_v: if you want, I can show you a before/after by simply moving my ~/.icons dir w/ its labyrinth of symlinks
[16:40] <nemo> ckontros: did you measure the actual panel height? :)
[16:40] <nemo> screenshot plz!
[16:40] <nemo> anyway. 8px is way too small
[16:41] <nemo> ckontros: http://m8y.org/tmp/Screenshot.jpeg - my desktop w/ shrunken start-here
[16:42] <mac_v> nemo: humanity has a 16px icon , not sure why there was a need to shrink the icon
[16:43] <nemo> mac_v: well. that's why I asked if it was doing some crude trigger based on font size to shrink the panel icon
[16:43] <mac_v> btw  , 8px , is not too small ;p  ..
[16:43] <nemo> mac_v: my suspicion is "yes"
[16:43] <nemo> if you simply try to reduce the panel size to 20/19px it ignores you, and sticks with the larger icon
[16:43] <mac_v> i'v been using 8px , since i felt 10px was too big :)
[16:43] <nemo> unlike most things that scale correctly
[16:44] <ckontros> I run 1920x1200 w/8px.
[16:44] <nemo> however, if you lie to it and tell it the 16px is the 24px one
[16:44] <nemo> then it uses that, and the panel can now resize down correctly
[16:44] <mac_v> nemo : you can force the icon using gtkrc
[16:44] <nemo> oh? that'd be nice too?
[16:44] <nemo> where.
[16:44] <ckontros> nemo: You seem to just want more padding around the icon. So what you did is fine.
[16:44] <nemo> no
[16:44] <nemo> ckontros: I don't want more padding. I want the panel at 20px or 19px instead of 24px
[16:45] <nemo> ckontros: let me fire up the laptop and show you what happens if I remove the symlinks :)
[16:45] <nemo> panel gets taller due to start-here
[16:45] <nemo> ignoring the panel size
[16:45] <nemo> oooone sec
[16:45] <mac_v> nemo: in the gtk theme , you can force the icons size
[16:45] <nemo> btw, there are many ubuntu forum threads on this
[16:45] <mac_v> gtk-icon-sizes = "panel-menu=16,16"
[16:45] <nemo> mac_v: I just want to force *that* icon size. if you could show that, it'd be great
[16:45] <nemo> cool
[16:45] <nemo> I'll give that a shot
[16:45] <nemo> lemme dig up the laptop
[16:45] <mac_v> nemo: add that to the gtkdc of the theme
[16:46] <mac_v> gtkrc*
[16:47] <ckontros> AFAIK, you cant bet below 21 without going to a 8px font, editing the gtkrc or changing the icons. Which you have done.
[16:47] <nemo> well. of the 3, gtkrc is tidier.
[16:47] <mac_v> yup , i dont think you can without having smaller font ;)
[16:47] <nemo> although the .icons has advantage of being user specific
[16:47] <ckontros> But forcing that icon size with do it for everything in the panel or panel menu I believe.
[16:47] <nemo> oh. hum
[16:48] <nemo> ckontros: that would make icons smaller than 16 increase in size?
[16:48] <mac_v> nemo: AFAIK , you need to force for every applet on the panel
[16:48] <mac_v> the messaging menu uses a 22px icon
[16:48] <mac_v> there is not 16px icon size for that
[16:49] <mac_v> no*
[16:49] <ckontros> mac_v: I /think/ it can be panel-global or app-specific. Can't remember.
[16:53] <nemo> http://m8y.org/tmp/temp.txt - my overkill symlinks
[16:53] <nemo> ok. now to try the gtkrc suggestion
[16:53] <nemo> will move .icons somewhere
[16:56] <nemo> mac_v: where would I put gtk-icon-sizes ?
[16:56] <nemo> oh wait
[16:56] <nemo> I already did that
[16:56] <nemo> it didn't work
[16:57] <mac_v> nemo: is the theme in the .icons or  in usr/share?   [just taking a wild guess , since that option works when human theme uses it]
[16:57] <nemo> $ grep -Ev "^[[:space:]]*$|^[[:space:]]*#" .gtkrc-2.0
[16:57] <nemo> gtk-icon-sizes="gtk-menu=16,16"
[16:57] <nemo> gtk-icon-sizes="gtk-button=16,16"
[16:57] <nemo> gtk-icon-sizes="gtk-small-toolbar=16,16"
[16:57] <nemo> gtk-icon-sizes="gtk-large-toolbar=16,16"
[16:57] <mac_v> .themes*
[16:57] <nemo> gtk-icon-sizes="gtk-dnd=16,16" #don't know
[16:57] <nemo> gtk-icon-sizes="gtk-dialog=16,16" #don't know
[16:57] <nemo> gtk-icon-sizes="panel-menu=16,16:gtk-large-toolbar=20,20"
[16:57] <nemo> I've always had those in there
[16:58] <nemo> but I still need to do the ~/.icons thing
[16:58] <mac_v> nemo: hmm , what .icons thing?
[16:58] <nemo> hm. also my font size *is* 8!
[16:58] <nemo> how odd
[16:58] <mac_v> lol
[16:58] <nemo> mac_v: the symlink thing I referenced above
[16:58] <nemo> ok. so I'm clearly comfortable at 8. hmmm
[16:58] <nemo> so why does it work for you, but not for me
[16:59] <ckontros> Maybe you have things in your gtkrc messing with it?
[16:59] <nemo> ckontros: that's my entire gtkrc above
[16:59] <nemo> um. I can send you the theme gtkrc as well I guess
[16:59] <ckontros> No need.
[16:59] <nemo> (as opposed to user)
[17:00] <nemo> I see nothing in the Humanity gtkrc that seems likely - I did reduce the widths of things, I certainly didn't increase anything
[17:00] <nemo> anyway. I'm not the only one to resort to this :)
[17:00] <nemo> but it works ok. just a bit convoluted
[17:01] <nemo> I guess what would be a timesaver would be a "small display" theme :)
[17:01] <mac_v> nemo: in the *human* gtkrc it is in line 8
[17:01] <nemo> one that tightens everything up
[17:02] <nemo> gtk-icon-sizes = "panel-menu=24,24:gtk-button=16,16"
[17:02] <nemo> that one?
[17:02] <mac_v> yup ,
[17:02] <mac_v> but that was for 24,24 , so i gave you a 16,16 ;)
[17:02] <nemo> huh. that should have been overridden by my gtkrc personal
[17:02] <nemo> riiight
[17:02] <nemo> but my ~/.gtkrc-2.0 should specify the 16x16 override I pasted above
[17:03] <mac_v> nemo: check if there is anything in the gconf[panel options] , which forces any size
[17:03] <nemo> oh. and I'm using DarkRoom right now which has no such line
[17:05] <nemo> there is a default size of 24 - however I don't think that would force it since it clearly honours my resizing ... once I smack down start-here
[17:05] <mac_v> nemo: i thought you mentioned that you used a gtkrc ? oh ! so you didnt use it as a theme?
[17:05] <nemo> mac_v: I modified my ~/.gtkrc-2.0 - but I also modified the DarkRoom theme to tighten up scrollbars and such on that theme
[17:05] <nemo> no one else seems to like DarkRoom, so it only impacts me really :)
[17:06] <nemo> the grep above is from .gtkrc-2.0 - that's why I pasted the grep line :)
[17:06] <mac_v> ah , ok
[17:06] <nemo> current top panel size in gconf is set to 19
[17:06] <nemo> I'm pretty sure if I measure it it will actually be 20
[17:06] <nemo> due to other things getting in the way
[17:07] <nemo> btw, another annoying aspect of the start-here thing
[17:07] <nemo> if a user decides to reduce their panel from 24 to 19, they then discover gnome will spawn apps underneath the menu bar
[17:07] <nemo> which it now thinks is only 19px high
[17:08] <mac_v> nemo: i think the best for you is to use the autohide ;)
[17:08] <nemo> hm. it is 19px high
[17:08] <nemo> mac_v: naw. I like seeing my system stats
[17:08] <nemo> I interact w/ top bar too often to want autohide
[17:08] <nemo> actually, I've always found autohides annoying. dunno why
[17:08] <mac_v> nemo: you can force the autohide size to 16px
[17:09] <nemo> maybe 'cause they pop out at me when I least expect it just 'cause I moved my mouse wrong
[17:09] <nemo> hmmm
[17:09] <nemo> so it would only peek out a bit?
[17:09] <mac_v> nemo: so on autohide  16px willstill be displayed
[17:09] <nemo> I might still be able to read my stuff then
[17:09] <nemo> but then it would jitter.
[17:10] <nemo> well. I'll play w/ it. 19px works well enough.  Maybe I'll whip up a script for the poor souls on the ubuntu forum in same situation
[17:10] <mac_v> nemo: set the delay to very long
[17:10] <ckontros> In gconf: /apps/panel/toplevels/top_panel_screen0/auto_hide_size
[17:10]  * nemo tries
[17:10] <mac_v> nemo: set autohide delays it to 1 min or something , that way it wont move easily
[17:10] <nemo> 16, oddly, doesn't look like 16
[17:10] <nemo> everything is chopped in half
[17:10] <nemo> hm
[17:11] <nemo> maybe 8
[17:11] <nemo> interesting. 16 or 8 do exactly the same thing
[17:11] <nemo> ditto 24
[17:11] <nemo> ok. autosize is not working as expected :)
[17:12] <nemo> 1-9 work
[17:12] <nemo> above 9 the values are ignored
[17:13] <nemo> meh. no biggie. 19px is ok as noted.
[17:13] <nemo> I was just more curious about the SVGs and brought this nuisance up in passing :)
[17:14] <mac_v> nemo: that jimmac article mentions why svg is needed in all sizes
[17:15] <nemo> yeah. that makes sense
[17:15] <nemo> for small
[17:15] <nemo> it was the 48 and 64 I didn't understand
[17:15]  * nemo rereads what you said before
[17:16] <nemo> ah. hm
[17:16] <nemo> dunno. doesn't seem like it'd matter much. but hey, whatever :)
[17:16] <nemo> somehow seems you could get away w/ small and large or just small, medium and large, but you're the artists.
[17:17] <mac_v> nemo: well when you are wondering about 19/16 px... why wouldnt 48/64 px matter ;p
[17:17] <mac_v> the icons were added just to make the images more sharper
[17:19] <mac_v> nemo: also humanity-icon-theme is not very big download , it is nearly as big a human icon theme but has more the 4-5 time the number of icons... so size isnt a problem for us either
[17:22]  * mac_v gets back to cursing OOo... #$%#$
[21:12]  * thorwil has ubuntu-one fail at upload and uses dropbox instead