[07:20] <dhart> I'm looking for the correct place to file a bug. Subject would be "Remove confusing and inconsistent gnome- prefix from executables packaged with Ubuntu". Affects these packages: dpkg -S `locate "bin/gnome-"`
[08:38] <snamellit`> 13:34 *** bladernr_ JOIN
[15:53] <Teufelchen> i keep this bug open as per discussion from some time ago on this channel: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1079801
[15:53] <ubot2> Launchpad bug 1079801 in mesa (Ubuntu) "applications like Google Earth or Second Life do not work" [Undecided,New]
[15:55] <Teufelchen> forgot to add the comment, that i was not able to test install Ubuntu 13.04
[15:57] <Teufelchen> okay, updated
[15:58] <Teufelchen> i hope the bug report is not annoying due to the number of comments
[19:49] <TLoT> ohai!
[19:50] <TLoT> need someone else on bugcontrol/bugsquad/MOTU to consult with on https://bugs.launchpad.net/ubuntu/lucid/+source/znc/+bug/1088390
[19:50] <ubot2`> Launchpad bug 1088390 in znc (Ubuntu Lucid) "znc & znc-perl not to load perl module" [Undecided,New]
[19:50] <TLoT> according to upstream, this is an issue of "Stop trying to build stuff probably written for newer ZNC on older ZNC."
[19:50] <TLoT> which is pretty non-ubuntu of them to say, but entirely relevant here.
[19:50] <TLoT> suggestions on hwo to proceed with the bug?
[19:52] <micahg> TLoT: not a bug, if it was a shipped perl script that would be different
[19:52] <micahg> maybe we can backport the newer znc to lucid?
[19:52] <TLoT> micahg: not possible
[19:52] <micahg> hrm?
[19:52] <TLoT> issue is dependent on the "Backports cannot depend on backports" thing
[19:53] <micahg> we should get that fixed
[19:53] <TLoT> even then, i've tried backporting 0.206 to Lucid
[19:53] <TLoT> it fails completely.
[19:53] <TLoT> even with swig2.0 backported.
[19:53] <TLoT> (requirements are newer versions of software than lucid has)
[19:53] <TLoT> last time i tested, it'd require pretty much backporting most if not all build-deps from precise/oneiric -> lucid, and that... well...
[19:53] <TLoT> can cause issues...
[19:54] <micahg> TLoT: upstream codebase looks like it should build...
[19:54] <TLoT> (such as interference with other packages, and libraries, and numerous other FTBFS related potential issues)
[19:54] <TLoT> micahg: last time i tried backporting it wouldn't work
[19:54] <TLoT> and that was...
[19:54] <TLoT> oh...
[19:54] <TLoT> back when Oneiric just came out.
[19:54] <TLoT> s/oneiric/precise/
[19:55] <TLoT> micahg: in the mean time i'm going to mark that bug as invalid (unless you wouldn't mind doing that), but stay subscribed to it.
[19:56] <TLoT> micahg: and which upstream codebase're you looking at, 1.0 or 0.206?
[19:56] <TLoT> 0.206 is more likely to be backported if i go hacking at the codebase a bit, but 1.0 is... actually quite dependent on newer stuff.
[19:57] <micahg> oh, hrm, their README doesn't describe the deps well at all
[19:57] <TLoT> micahg: pull the list of deps from a 0.206 package
[19:57] <TLoT> i think... um...
[19:58] <TLoT> pre-backported for precise and quantal had 0.206
[19:58] <micahg> I was looking at the version in precise backports
[19:59] <TLoT> micahg: i'd not EVER request 1.0 to be backported to lucid
[19:59] <TLoT> too many... um... "issues"
[19:59] <TLoT> since the difference in timeframe is ~3 years of codebase changes and library changes between znc in lucid and znc in precise, as well as build-dep issues
[19:59] <TLoT> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/znc/quantal/view/head:/debian/control#L4  <--
[20:00] <TLoT> these are the MINIMUM build deps you'd nneed.
[20:00] <TLoT> need*
[20:00] <TLoT> and swig2.0 FTBFS if you backport it
[20:00] <micahg> TLoT: which isn't a problem is upstream was targeting the lowest common denominator (which they're not)
[20:00] <TLoT> (earliest it built on was Natty, and that was a pain to do)
[20:00] <TLoT> micahg: and now you know why i think znc on lucid is an idea riddled wtih stupidity
[20:00] <TLoT> no offense to the rest of the world, but...
[20:02] <TLoT> micahg: and upstream keeps syaing "Why don't they keep Ubuntu up to date with libraries and things?" to which i usually just don't respond to
[20:03] <TLoT> since in that respect, debian stable releases and ubuntu releases are similar: they don't really version-upgrade libraries without there being a very good reason for doing so.
[20:03] <TLoT> (security or otherwise)
[20:05] <TLoT> micahg: and the biggest of all these issues: swig2.0 doesn't exist in Lucid
[20:05] <TLoT> and doesn't really backport well
[20:05] <TLoT> and has been a build-dep for 0.206 and later
[20:07] <TLoT> so ideally two things would need to happen: (1) swig2.0 would need to be backported if possible to lucid, and (2) the bug on "Backports Can't Build-Dep on Backports" needs to be fixed, and that's i think an sbuild/archive-builders issue.,
[20:07] <TLoT> oh, and (3) debian/control: drop build-dep on swig (to fix a conflicts issue)
[20:08] <TLoT> micahg: mind if I quote you in the bug response when i invalid it?
[20:10] <micahg> TLoT: sure
[20:11] <TLoT> bleh forgot to include your statement.  but i paraphrased it and referred to the conversation here.
[20:11] <TLoT> micahg: also for reference, this is the backports can't depend on backports bug: https://bugs.launchpad.net/launchpad/+bug/888665
[20:11] <ubot2`> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged]
[20:12] <TLoT> its been in that state for a few years thus far
[20:12] <TLoT> so...
[20:12] <TLoT> (seemingly no progress?)
[20:12] <micahg> TLoT: I should follow up with infinity on that, he was going to do it, but got blocked again, I'm not quite sure on what
[20:16] <TLoT> micahg: i'd LOVE to know the status on that, since it would potentially break backports (not sure if it'd affect lucid, perhaps that should be checked?)
[20:18] <TLoT> I'll check back later.
[23:41] <TheLordOfTime> i don't even think this is valid... https://bugs.launchpad.net/ubuntu/+bug/1097969
[23:41] <ubot2`> Launchpad bug 1097969 in Ubuntu "Remina Remote Desktop Client cannot be minimized from fullscreen" [Undecided,New]
[23:41] <TheLordOfTime> i don't see Remina in the repos.
[23:41]  * TheLordOfTime did an apt-cache search for 'remina' so unless he missed something...
[23:52] <bdmurray> ith as 2 m's
[23:52] <TheLordOfTime> bdmurray, it does?
[23:52] <bdmurray> er, it has 2 m's
[23:52] <bdmurray> http://packages.ubuntu.com/search?keywords=remmina
[23:52] <TheLordOfTime> ah, so it does
[23:52]  * TheLordOfTime takes back his initial statement and reassigns the bug to the package
[23:55] <TheLordOfTime> would it hurt to ask them to apport-collect the bug as well?
[23:55] <TheLordOfTime> (to gather some info about the package and the system)


[16:10] <louiloui> Hi, I reported a bug, but I have no clue what package it affects (If I knew, I'd probably be able to fix it)
[16:10] <louiloui> URL https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1574073


[08:50] <DJones> Looks like Energy is up to their usual trolling in #ubuntu
[08:50] <DJones> 09:47 < Energy> hello little jew who take creation for african people because you are tightwad !!!
[09:25] <sveta> yes, he has been on it for the last couple days randomly
[09:26] <sveta> did anyone talk to him at all? given how weird other channels are, I suspect not…
[12:03] <DJones> sveta: I didn't speak to him, it was a one liner in #u, from past experience if anybody makes comment about it or to him, he follows up with another similar line, ignoring it seemed the safest bet rather than waving a red rag, that approach seemed to work, I didn't see any further comment before I went out
[12:04] <DJones> However I've seen bans/quiets/kline from physics/defocus/freenode over the last few days
[15:14] <DJones> Madeline21 link was to a porn website
[15:14] <bazhang> and klined
[15:14] <IdleOne> all the *21 nicks link to porn
[15:15] <IdleOne> I had banned *21!*@* but we got one user who complained (probably the one who runs the spam bots) and the ban was removed
[15:16] <k1l> yep. what about forward  that ban and see how many false positives we get?
[15:17] <IdleOne> we got only one, the complainer.
[15:17] <IdleOne> I think a straight up ban is all that is needed, no need to forward them here so we can see the link 20 times a day
[15:19] <k1l> thats what i would do. but i was told i ban/kick too much and too quick so the forward would be a midway solution
[15:21] <IdleOne> like I said, I already tried the forward and all it gave us was one user who complained and that resulted in the spam starting over. I have not seen one single user with a *21 nick say anything except post porn spam
[15:22] <IdleOne> but if you want to set a forward you are welcome to do so :)
[15:22] <k1l> iirc i did set a *18 forward with the same result
[15:22] <IdleOne> yup, they went from 18 to 21
[17:44] <Korkel> Can I apply my ban?
[17:46] <Korkel> I'm sorry 'bout what I did, learned a lesson.
[17:49] <Flannel> Korkel: Hi.  Let me take a look.
[17:49] <Korkel> Sure.
[17:49] <Flannel> Oh, ok.  What on earth were you thinking? :)
[17:51] <Korkel> No idea, I was wrong.
[17:52] <Flannel> Alright, I expect it won't happen again?
[18:01] <Korkel> Yes.
[18:01] <Korkel> It will not happen again
[18:03] <tomaw> do you guys want idoru in #ubuntu for a bit?
[18:03] <tomaw> it should kill the nick spam fairly quickly
[18:06] <tomaw> I joined it for now as it's getting a bit spammy. I'll remove it later but feel free to kick it
[18:17] <Korkel> Flannel, any information?
[18:17] <Flannel> Korkel: Hi, sorry.  Had some excitement elsewhere.
[18:17] <Korkel> No problem. :P
[18:17] <Flannel> Korkel: Can you please read and understand the IRC guidelines and let me know if you'll agree to follow them.
[18:17] <Flannel> !guidelines
[18:18] <Korkel> Readed it when I was banned, so yes understood and accept.
[18:19] <Flannel> Good, good.
[18:20] <Flannel> Alright, give me a minute to remove the ban.
[18:21] <Korkel> bans*
[18:23] <Flannel> Yes.  I think I got them.  Please join #ubuntu and say something to verify.
[18:26] <Korkel> »» Cannot join #ubuntu-nl (You are banned).
[18:27] <Flannel> I have no control over #ubuntu-nl (this channel doesn't cover the loco channels), you'll want to talk to the operators for that channel in #ubuntu-irc
[18:33] <Korkel> Ok
[18:33] <Korkel> ty
[22:57] <rww> ubottu: away > [AFK]def_anoch


[07:41] <thelegace_> hi could someone tell me why im getting this error Hash sum mismath for gettext
[07:43] <twb> Probably because the hash sums don't match
[07:44] <twb> if this is during an apt-get run, that's usually because the mirror is broken or an http proxy is caching strangely, or even just because the connection was lost halfway through
[07:47] <scientes> yeah whenever you get that error, just run "apt-get update" again
[07:48] <scientes> and as long as you only have ubuntu sources, that works 100% of the time in my experience
[07:48] <scientes> oh wait, hash sum,
[07:48] <scientes> then you have to sudo rm /var/cache/apt/archive/<PACKAGE>
[07:48] <scientes> which is hella annoying
[07:48] <scientes> sometimes it works itsself out, but not always
[07:50] <thelegace_> ya scientes its not fixing the problem
[07:52] <thelegace_> could it be just be a mirror problem
[07:52] <thelegace_> oh ok
[07:52] <thelegace_> that fixed it
[07:53] <thelegace_> deleting it from the pool directory
[08:00] <scientes> yeah you have to do that some times
[08:00] <scientes> quite annoying
[08:00] <scientes> I have apt-cacher-ng too
[08:01] <scientes> and i've had to log into the acng server and delete it there as well
[08:20] <xnox> https://blueprints.launchpad.net/ubuntu/+spec/arm-q-platforms-emerging
[08:20] <xnox> I thought Raspberry Pi is not supported by current ubuntu arm[el?] port
[08:20] <ogra_> EEEK !
[08:20]  * ogra_ sighs deeeeeeeeply
[08:20]  * xnox maybe I should not comment on that blueprint....
[08:21] <twb> That blueprint boils down to "now that we have migrated to armv7 so everyone is happy, Pi comes out and we can sell to it so we should go back to armv5" ?
[08:22] <ogra_> twb, yeah, and there is also that openmoko platform ... and they all want to run unity on it :P
[08:22] <twb> IMO the answer is "no tough shit, you should have thought of that 18mo ago"
[08:23] <twb> "Why do you think it's $25 instead of $100?  Because it's an obsolete arch!"
[08:24] <twb> ogra_: we should create a 286 emulator in minecraft and then propose to make the i386 packages all support it OOTB
[08:25] <ogra_> ++
[08:25] <micahg> twb: you don't even have to go that far, i386 is i686 :)
[08:26] <twb> micahg: all of it?  I thought it was a hodge-podge of i386 i586 and i686
[08:26] <twb> Maybe that's only in debian land
[08:26] <twb> Also our emulated 286 would have no FPU or MMU
[08:26] <micahg> yeah, Debian's still targetting some 586 machines, I think we've been at 686 since at least maverick
[08:26] <twb> micahg: Okey dokeyt
[08:27] <micahg> and now pae is gone :)
[08:27] <micahg> err...non-pae :)
[08:27] <twb> micahg: soekris net5501 doesn't support PAE -- that bit me when I tried to put lucid server kernel on it :-/
[08:27] <twb> Fortunately I chucked that out because it couldn't handle our dirty power
[08:28] <micahg> I thought there was a non-pae lucid server kernel
[08:28] <twb> Shrug
[09:02] <twb> Urgh, the I/O on this TF101 is not noticable -- except in apt
[09:03] <twb> It takes like 30s just to read the sources lists out of /var and into memory
[09:03] <twb> Package installs are hugely slow too, even with unsafe-io in dpkg.cfg
[09:09] <djszapi> ogra_: hey...
[09:25]  * ppisati -> disappears for a bit
[09:35] <thelegace_> hi im trying to compile this library called gst-rtsp
[09:36] <thelegace_> when i run .configure it says configure: error: no gstreamer-1.0 >= 0.11.0
[09:36] <thelegace_> but gstreamer is installed
[09:38] <thelegace_> nvm i was using to new version of the library
[11:16] <ppisati> ogra_: "Ubuntu Configurations for Raspberry Pi and Other Emerging ARM Platforms"
[11:16] <ppisati> ogra_: http://summit.ubuntu.com/uds-q/2012-05-09/
[11:17] <ogra_> sigh
[11:17] <ppisati> ogra_: :)
[11:17] <ogra_> well, we apparently have to face it at least once :/
[13:53] <timholum> rcn-ee: thanks ( Also sorry about the late responce, my boss came in and needed me to go with him to work on something
[14:06] <lilstevie_> "Being that the Raspberry Pi hardware platform has recently released, it's likely that many will install Ubuntu on this device." <- um what
[14:12] <XorA> lilstevie_: you can install ubuntu on it
[14:12] <lilstevie_> since when
[14:12] <XorA> 8.04
[14:12] <lilstevie_> unless you are talking about karmic
[14:13] <XorA> ubuntu arm wasnt always armv7
[14:13] <lilstevie_> I know it wasn't
[14:13] <lilstevie_> wait, karmic was armv7 wasn't it
[14:14] <ogra_> nope, v6
[14:14] <ogra_> jaunty was v5
[14:14] <rcn-ee> lucid, was the first armv7, it was armv6 karmic, armv5 jaunty..
[14:14] <XorA> it only take a motivated individual with too many server class machine free to do an armv5 rebuild, can call it oldbuntu or something :-)
[14:14] <lilstevie_> ah
[14:15] <lilstevie_> but anyway, hardly seems relevant for UDS to talk about jaunty or karmic on the rpi
[14:16] <XorA> as someone else said, its like the i386 of arm boards
[14:16] <lilstevie_> heh
[14:16] <XorA> still anoying that my one machine that is different is the Sheeva, but its debian so no too much different
[14:17] <lilstevie> I was considering the pi
[14:17] <lilstevie> but I like my t2 desktop and t3 tablet too much to take a step backwards like that
[14:18] <XorA> my only regret with RPI is I didnt buy one then list it on ebay without opening it
[14:19] <XorA> lilstevie: still waiting for 100% working Transformer :-D
[14:19] <lilstevie> XorA: heh
[14:19] <lilstevie> it is getting there :)
[14:19] <lilstevie> how long did it take for the ac100?
[14:20] <lilstevie> to get to its state
[14:20] <XorA> no idea
[14:21] <lilstevie> working on getting the prime up to a basic working state
[14:22] <XorA> I didnt see enough in prime to upgrade
[14:22] <lilstevie> heh
[14:22] <lilstevie> tegra3
[14:23] <lilstevie> ^^ biggest reason to upgrade
[14:23] <XorA> for android I mean
[14:23] <XorA> I could see me upgrading for fully working Ubuntu
[14:23] <XorA> but normal transformer already plays videos at full speed and changes pages on pdfs/comics instantanrously
[14:23] <lilstevie> I thought that
[14:23] <lilstevie> then I got a prime
[16:58] <ahs3> ogra_: hey.  finally got around to booting my cubox; it came with lucid pre-installed :)
[16:59] <ogra_> ahs3, yeah, i heard so
[16:59] <ogra_> we had someone here instaling precise on it from ubuntu-core
[16:59] <ahs3> oh, nice.  that was going to be my next step
[17:29] <jonmasters_> hey, who owns the audit userspace binaries?
[17:33] <ogra_> jonmasters_, well, ubuntu has no package owners like debian does ...
[17:33] <ogra_> auditd is in universe, your best bet is probably #ubuntu-motu
[17:34] <jonmasters_> well, it's broken and there's a kernel patch coming soon you'll need to pick up too. Just wanted to let you guys know :)
[17:36] <infinity> jonmasters_: Time to join MOTU and contribute? ;)
[17:36] <infinity> jonmasters_: I'll trade you an ubuntu.com for a fedora.org.
[17:37] <ogra_> lol
[17:53] <jonmasters_> infinity: MOTU is "Masters of the Universe", right? I'm already a Masters of the Universe ;)
[18:21] <infinity> jonmasters_: :P
[18:33] <djszapi> ogra_: wow
[18:33] <djszapi> The _FPU_EXTENDED, _FPU_GETCW and _FPU_SETCW macros are not available on ubuntu-arm
[18:33] <djszapi> hefty; it causes the openal software break during the build.
[18:36] <djszapi> http://paste.kde.org/468116/ -> ohh, so it is there, just not by the default include path...
[18:43] <infinity> djszapi: /usr/include/<triplet>/ is on the default path.
[18:43] <infinity> djszapi: If it wasn't, pretty much nothing in the archive would build. :P
[18:43] <djszapi> /usr/include/<triplet>/ is on the default path.
[20:06] <ogra_> janimo`, yo ho ho ... will you ne at UDS ?
[20:06] <ogra_> *be
[20:07] <janimo`> ogra_, nope, not this one
[20:07] <ogra_> *sniff*
[20:07] <ogra_> have you seen my mail to the ac100 list ?
[20:07] <janimo`> regarding the armhf package build?
[20:07] <ogra_> we have hf drivers ... but apparently they need a 3.1 kernel
[20:07] <janimo`> I thought there was no 3.1 kernel from marvin24 yet
[20:08] <janimo`> or later for that matter
[20:08] <janimo`> just WIP
[20:08] <ogra_> i got them stable running now with marvins 3.1
[20:08] <janimo`> ah ok
[20:08] <ogra_> but have issues booting the kernel :P
[20:08] <infinity> Shame we never got a 3.2 kernel. :/
[20:08] <janimo`> how is it stable if the kernel does not boot :) ?
[20:08] <ogra_> i can only successfully boot if i add break=bottom ... and then kill the shell in the initrd
[20:08] <janimo`> ah
[20:09] <ogra_> something makes it hang otherwise ...
[20:09] <ogra_> there must be a bad race somewhere
[20:09] <janimo`> does it need 3.1 or >=3.1  ?
[20:09] <ogra_> (though just adding sleeps randomly to the scripts didnt help either)
[20:09] <janimo`> I thought a lot of tegra2 and ac100 bits were going into 3.3
[20:09] <ogra_> i think it uses 3.1.10
[20:10] <ogra_> not sure how many will and if the binary driver works with it
[20:12] <janimo`> afaik we used the earlier L4T drivers with kernels newer than what nvidia suggested and had in the SDK
[20:13] <ogra_> well, sure, but someone will have to test that
[20:13] <ogra_> i dont think there is any usable 3.3 tegra tree anywhere yet
[20:13] <ogra_> and i'm soure there will still be enough to add
[20:14] <infinity> If a lot of tegra stuff has been upstreamed in 3.3, perhaps 3.4 can be made to work? :P
[20:14] <infinity> And we could actually match the distro kernel...
[20:14] <ogra_> i think there are bits upstream wont accept easily
[20:15] <ogra_> similar to omap4
[20:15] <infinity> Well, sure, we can still carry a patchset.
[20:15] <infinity> Most of omap4 is upstream by now, AFAIK.
[20:15] <ogra_> thats what i mean ... it wont be for free like omap3
[20:15] <ogra_> and for omap4 the DSS code wont go upstream
[20:15] <ogra_> so if you want full display support you still need a patchset
[20:17] <marvin24_DT> well, you can try my for-next branch if you want to be at the bleeding edge
[20:17] <marvin24_DT> it has just 6 patches to enable kms driver
[20:17] <marvin24_DT> but I guess it's not much fun
[20:17] <ogra_> thats what version ? 3.3 ? 3.4 ? chromeos 3.something ?
[20:18] <marvin24_DT> -next
[20:18] <marvin24_DT> 3.4-rc5
[20:18] <marvin24_DT> mainline
[20:19] <marvin24_DT> but no suspend
[20:19] <ogra_> bah
[20:19] <marvin24_DT> and only basic powersave
[20:19] <ogra_> what else is broken ?
[20:19] <ogra_> bah, even worse
[20:19] <marvin24_DT> broken?
[20:19] <marvin24_DT> nothing
[20:19] <marvin24_DT> just "missing"
[20:19] <ogra_> well, suspend, powersave ...
[20:19] <ogra_> does sound work ?
[20:19] <marvin24_DT> yes
[20:19] <ogra_> display ... touchpad ... wlan
[20:19] <marvin24_DT> it is mainlined for a long time now
[20:19] <marvin24_DT> all working
[20:20] <ogra_> hmm. nice
[20:20] <ogra_> so only power mgmt and suspend ? thats not as bad as i thought
[20:20] <marvin24_DT> tegra folks invested much time into device tree conversion
[20:20] <ogra_> great
[20:20] <marvin24_DT> so not much is done on the hw support front
[20:21] <marvin24_DT> it seems all the board files will be removed next time
[20:21] <ogra_> so only DT then ?
[20:21] <marvin24_DT> yes
[20:21] <ogra_> good
[20:21] <marvin24_DT> so if you want to port to a new device, just add a text file ;-)
[20:21] <ogra_> yep
[20:22] <ogra_> intresting that its actually nvidia that got that far
[20:22] <marvin24_DT> I have no idea where omap is now
[20:22] <ogra_> if you look at other new things in technology ... i.e. kms ... it takes them a century to adapt
[20:22] <marvin24_DT> I also see a lot of patches from ti
[20:23] <ogra_> yeah, b ut thats likely rather for omap4
[20:23] <marvin24_DT> kms is not mainlined yet (therefore the 6 patches)
[20:23] <marvin24_DT> but they are very small though
[20:24] <ogra_> well, kms in general ... even on x86
[20:24] <marvin24_DT> I think alied already can live with them
[20:24] <ogra_> its like what ... 6 years old now ?
[20:24] <ogra_> and it took them this long to adapt their drivers
[20:24] <marvin24_DT> btw, is it possible to build a xf86-video-modesetting package?
[20:24] <marvin24_DT> for armhf?
[20:24] <ogra_> i dont see why not
[20:24] <marvin24_DT> I hate to build it myself all the time
[20:25] <marvin24_DT> I mean add it to the ubuntu distro
[20:25] <ogra_> file a bug, i'll talk to RAOF (org maintainer) next week
[20:25] <ogra_> s/org/xorg/
[20:25] <marvin24_DT> ogra_: against what?
[20:26] <ogra_> hmm., good question, can you build it from any source we laready have ?
[20:26] <ogra_> *already
[20:26] <ogra_> if not, just the ubuntu project
[20:26] <marvin24_DT> yes, basicly it is just one file
[20:27] <marvin24_DT> (and a man page)
[20:27] <marvin24_DT> eh, n
[20:27] <marvin24_DT> o
[20:27] <marvin24_DT> no source package yet
[20:27] <ogra_> right, just file it against ubuntu then
[20:39] <marvin24_DT> done
[23:12] <evolvdone> I'm having a problem with getting ubuntu loaded up on my pandaboard es. When I first boot up after loading the image on the SD card everything seems to be working then it reboots and I get a erro saying "Errors were found while checking the disk drive for /"
[23:12] <evolvdone> Anyone seen this before?
[23:15] <infinity> evolvdone: Your card's failing.
[23:15] <infinity> evolvdone: Not much else to say about that.
[23:15] <evolvdone> bummer I just got it
[23:15] <davecheney> if you just burnt the image onto the card, did you check the sha1sum ?
[23:16] <infinity> evolvdone: Assuming you wrote to the card correctly, the install is fairly foolproof after that.
[23:16] <davecheney> but it's most likely just burnt out
[23:16] <evolvdone> yeah I tried it both in windows and linux to see if it would make a difference
[23:17] <infinity> SD card quality (or lack thereof) is the reason I wish we'd stop doing the preinstalled images and just make people use external hard drives. :P
[23:17] <evolvdone> I have a external hd around I could use, I still need a working sd card to get that to work though, correct?
[23:17] <infinity> evolvdone: You need an SD that works siginificantly less robustly, though. :)
[23:18] <TypoNAM> infinity: aren't preinstalled images still useful for USB external hard drives?
[23:18] <infinity> evolvdone: Installing to an external HDD just means having a small 8MB vfat partition on a card.
[23:18] <evolvdone> Ha, guess I will give that working then
[23:18] <infinity> TypoNAM: using a d-i image to install directly to the hard drive is a lot less hassle in the end.
[23:18] <infinity> TypoNAM: And means you don't have to boot your entire OS from flash...
[23:19] <evolvdone> a d-i image?
[23:19] <infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/
[23:20] <infinity> Grab boot.img-fb.gz, zcat to a card, boot, enjoy.
[23:20] <infinity> (or -serial.gz, if you prefer using a serial terminal)
[23:20] <infinity> Granted, neither of those will install ubuntu-desktop by default, but that's an easy enough fix once you're done.
[23:20] <evolvdone> awesome stuff
[23:21] <infinity> (And given that they don't, they're also in a better position if you wanted to try, say, kubuntu-desktop or xubuntu-desktop or lubuntu-desktop instead)
[23:22] <davecheney> are there any dev boards that offer sata (or even pata?) as an option
[23:22] <evolvdone> thanks for the help, i'm going to mess with it now
[23:22] <infinity> davecheney: The i.MX53 QuickStart has SATA.
[23:22] <davecheney> i looked at that when i got my panda
[23:22] <infinity> davecheney: As does the Marvell ArmadaXP, though we don't talk about that one.
[23:23] <davecheney> either it wasn't in stock, or it had teeny tiny onboard ram
[23:23] <davecheney> and i knew the panda just worked (tm)
[23:23] <infinity> davecheney: In general, I'd recommend a Panda over the QuickStart just because the CPU is significantly speedier, but when the MX6 boards come out, they'll really be worth a look.
[23:23] <infinity> (I have both on my desk, I love my QuickStart, but an A8 just can't compete with a dual-core A9)
[23:24] <davecheney> in australia, i had to take what I could get
[23:24] <davecheney> everything else was backordered
[23:24] <davecheney> even then I had to priomse to Mouser that I wasn't going to make a bomb with it or something
[23:24] <infinity> ;)
[23:26] <davecheney> fwiw, i've been running a panda for about 6 months on a crap 8gb memory card I bought at the supermarket
[23:26] <davecheney> i host my /home on nfs and mount /tmp on a ramdisk
[23:27] <davecheney> so the card doesn't take much of a pounding
[23:27] <infinity> Certainly helps, yeah.
[23:27] <infinity> I've burned through a lot of cards doing development on these things.
[23:27] <infinity> THough I have a Lexar that Just Won't Die.
[23:27] <davecheney> i understand about sd frustration, but being able to gunzip the image, plug in my monitor and turn on
[23:28] <davecheney> was pretty bloody amazing
[23:28] <infinity> Yeah, it's a really neat tool for demoing.
[23:29] <davecheney> no serial cable jiggery pokery, or buying a dodgy jtag usb adapter (hello netgear stora) from a forum
[23:29] <infinity> Though I think it gives an unfairly poor user experince at times.
[23:29] <infinity> (Full Ubuntu desktop + Firefox off an SD, even a "nice" class 10, is... Slow)
[23:29] <davecheney> yeah
[23:33] <infinity> http://paste.ubuntu.com/965823/ <-- Says it all.
[23:33] <infinity> SATA > USB > SD
[23:34] <infinity> (All on the same board)
[23:34] <davecheney> whoa, that is crapz0r
[23:35] <davecheney> maybe I should netboot this board
[23:35] <davecheney> although that would be ~10Mb/s


[01:30] <edsiper> is Ubuntu core already released for the Dragonboard _
[01:30] <edsiper> ?
[06:55] <zyga> good morning
[06:58] <shuduo> good morning.
[06:59] <shuduo> is there any plan to have classic dimension back? ;)
[06:59] <shuduo> should I expect snapcraft working in a chroot environment?
[07:01] <zyga> shuduo: I'm sure classic will work though I'm not quite sure when
[07:01] <zyga> shuduo: snapcraft and chroot, hmm, I heard that people had issues with kpartx
[07:01] <zyga> shuduo: you might be able to snapcraft in a chroot but only construct the squashfs manually or on the outside
[07:03] <shuduo> zyga: since no classic environment to build snap app for armhf target, i'm trying to run snapcraft in an armhf chroot. but got msg "Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path
[07:03] <shuduo> " when i build examples
[07:04] <zyga> shuduo: maybe try snapcraft from source, I don't know
[07:05] <shuduo> zyga: yes, i just pulled it from github and build/install it in chroot.
[07:05] <zyga> shuduo: you can also use launchpad to build snaps AFAIR but I haven't used this much
[07:06] <shuduo> zyga: sorry never heard of that. how?
[07:07] <zyga> I don't really know but from what I remember it's like a PPA
[07:07] <zyga> just builds snaps
[07:11] <shuduo> zyga: i looked at lp. seems only target amd64 and i386.
[07:11] <zyga> ah, too bad
[07:48] <dragly> Hi. I'm trying to package an app that is built using one of the newest versions of Qt (5.6 or 5.7). Because these are installed manually, I have written a plugin that copies all *.so libs and QML modules to the install folder. I was getting close to making this work when I encountered an annoying bug. After building and installing the snap 2-3 times, I
[07:48] <dragly> always get the following error when running the app:
[07:49] <dragly>  /bin/sh: 0: Can't open /snap/neuronify/100006/command-neuronify.wrapper
[07:49] <dragly> It goes away if I rename the snap and build/install again. Have anyone here seen this before?
[07:49] <zyga> dragly: yes, this is already (almost) fixed
[07:50] <zyga> dragly: though I don't know if my fix will land or if it will need larger changes
[07:50] <zyga> dragly: as a workaround, uninstall and install your snap each time
[07:50] <dragly> Oh, okay. I can live with that workaround while developing. Thanks!
[08:00] <dragly> That works. Now I just need to figure out how to get access to xkb working.
[08:01] <dragly> Do you know if I might be missing some "plugs" when I get this error?
[08:01] <dragly> xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
[08:01] <dragly> I already have "plugs: [unity7,opengl,x11,system-observe]"
[08:19] <zyga> dragly: you can consult generated apparmor profile but I suspect that nothing grants x11/xkb access
[08:19] <zyga> dragly: please open a bug with the details of your snap, I will be working on interfaces a lot this week,
[08:47] <dragly> zyga: ok, du you prefer bugs on launchpad or github?
[08:48] <zyga> dragly: I think we want launchpad
[08:49] <qengho> What's wrong with this?
[08:49] <qengho> echo -e 'name: xeyes\nversion: 1\ndescription: eyes\nsummary: toy\napps:\n snapxeyes:\n  command: usr/bin/xeyes\n  plugs: [ x11 ]\nparts:\n pkg:\n  plugin: nil\n  stage-packages: [ x11-apps ]' |tee snapcraft.yaml |cat -n
[08:57] <qengho> Okay, ignoring a wrapper problem.
[08:57] <qengho> $ /snap/bin/xeyes
[08:57] <qengho> Bad system call
[09:00] <zyga> qengho: try with --devmode
[09:00] <zyga> qengho: (remove the snap and install it with --devmode)
[09:01] <zyga> qengho: then observe syslog
[09:01] <zyga> qengho: also check if the x11 plug is connected
[09:01] <zyga> qengho: I had a few people report intersting bugs lately
[09:05] <qengho> zyga: https://pastebin.canonical.com/155116/
[09:06] <zyga> qengho: interesting, so you use encrypted home
[09:06] <zyga> qengho: you have to add the home plug and connect this
[09:06] <zyga> qengho: I'm not sure that it will suffice though
[09:07] <zyga> qengho: but please report a bug that snappy won't work at all with encrypted home directory
[09:12] <qengho> zyga: https://bugs.launchpad.net/snappy/+bug/1574526
[09:12] <zyga> qengho: thank you
[09:17] <zyga> qengho: can you snap install links
[09:18] <zyga> qengho: and run links successfully?
[09:20] <ara> qengho, I get the same dmesg, but the snap works fine
[09:20] <ara> qengho, I got the bad system call the first time (interfaces were disconnected), but uninstalling the snap and installing it agian, solved the issue
[09:21] <qengho> zyga: "links" snap works.
[09:22] <zyga>  qengho, thanks
[09:22] <zyga> so it's not encrypted home per se
[09:22] <zyga> qengho: is your snap trying to access regular home directory?
[09:23] <ara> qengho, if you try uninstalling the snap and reinstalling it, do you get the bad system call again?
[09:24]  * zyga wonders if the encrypted-home option is available in the installer anywhere
[09:24] <ara> zyga, you mean ubiquity?
[09:24] <ara> zyga, it is
[09:24] <zyga> ara: yes, I'm looking but all i see is encrypted /
[09:24] <ara> zyga, wait until it asks for your username
[09:24] <zyga> ara: ah, thanks
[09:24] <ara> zyga, it will have a radio button to encrypt your home
[09:25] <ara> qengho, was xeyes the first snap that you installed on your system?
[09:26] <qengho> ara: not the first.
[09:27] <qengho> $ sudo snap install ./xeyes_1_amd64.snap
[09:27] <qengho> [-] Make snap "xeyes" available to the system
[09:27] <qengho> $ /snap/bin/xeyes
[09:27] <qengho> Bad system call
[09:27] <qengho> cmiller@vetinari:/tmp$ sudo snap connect xeyes:x11 ubuntu-core:x11
[09:27] <qengho> [|] Connect xeyes:x11 to ubuntu-core:x11
[09:27] <qengho> cmiller@vetinari:/tmp$ /snap/bin/xeyes
[09:27] <qengho> Bad system call
[09:29] <zyga> qengho: and with devmode you get those messages about ~/.Private?
[09:29] <zyga> qengho: currently we don't get notices about seccomp denials in --devmode
[09:30] <ara> zyga, the .ecryptfs messages are always shown
[09:30] <ara> zyga, even without --devmode
[09:30] <ara> zyga, and even if the app works fine (like links)
[09:30] <ara> zyga, for me, if I launch links successfully, I still get those messages
[09:31] <zyga> odd
[09:31] <zyga> thanks!
[09:31] <qengho> Yes, "links" also causes four ecryptfs DENIED rw
[09:31] <qengho> But no crash
[09:32] <zyga> qengho: apparmor gives EPERM but seccomp gives you sigkill
[09:34] <ara> zyga, I thought that was going to change
[09:34] <zyga> ara: I don't think it did yet
[09:34] <qengho> Okay, so it's not dependent on ecryptfs.
[09:34] <zyga> ara: because seccomp needs kernel work
[09:34] <qengho> Is it?
[09:35] <qengho> Okay, so this bug is not dependent on ecryptfs?
[09:35] <zyga> qengho: it seems it's not
[09:35] <qengho> zyga: Your xeyes runs, then?
[09:36] <zyga> qengho: I'm still setting up an env
[09:36] <zyga> qengho: I'll try on my host
[09:42] <zyga> qengho: xeyes doesn't run
[09:44] <zyga> kwi 25 11:44:15 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1461577455.555:55): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16555 comm="xeyes" exe="/snap/xeyes/100001/usr/bin/xeyes" sig=31 arch=c000003e syscall=51 compat=0 ip=0x7f3da9445df7 code=0x0
[09:45] <zyga> that is getsockname
[09:45]  * zyga looks at snappy source
[09:46] <zyga> qengho: it doesn't work because x11 doesn't include that profile
[09:46] <zyga> qengho: unity7 will work
[09:48] <zyga> qengho: I just confirmed that it works with unity7 plug
[09:48] <zyga> qengho: I've updated the bug
[09:49] <zyga> with everything is a file/everything is over a socket, I find snappy interfaces related to networking rather limited
[09:49] <qengho> zyga: With devmode, it runs with no crash. Same dmesg output.
[09:50] <zyga> apparmor will need more work
[09:50] <zyga> qengho: change to "plugs: [unity7]"
[09:50] <zyga> qengho: then it works for me
[09:51]  * qengho boggles.
[09:51] <zyga> qengho: I've updated the bug
[09:51] <qengho> *Should* it have unity7 as plug?
[09:51] <zyga> qengho: no
[09:51] <zyga> qengho: it's just a bug
[09:54] <qengho> Okay, so I'm trying to figure out how to report it. "snappy's x11 plug doesn't work for 'getsockname' syscall"?
[09:54] <zyga> qengho: I renamed the existing bug
[09:54] <zyga> qengho: have a look
[09:55] <qengho> zyga: ah, perfect. Thank you.
[09:58] <qengho> zyga: I don't get that syscall=51 log message. Am I running stale software, or a different bug causes it to be missing?
[09:58] <zyga> qengho: it's a bug
[09:58] <zyga> qengho: that message says "getsockname is denied"
[09:58] <zyga> qengho: it's a bug in snappy
[09:59] <zyga> qengho: the message is obviously cryptic :/
[10:08] <qengho> I was just worried about *silence*.
[10:08] <qengho> Cryptic is fine. I've used linux since 1995. Cryptic, I got.
[10:10] <zyga> I reported https://bugs.launchpad.net/snappy/+bug/1574556
[10:22] <zyga> qengho: FYI: https://github.com/ubuntu-core/snappy/pull/1069
[10:22] <zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1069
[10:29] <dpm> hey all could someone ask this user on Ask Ubuntu? It seems their snappy system is locked due to errors (see the pastebin in the last comment) http://askubuntu.com/a/760782/9781
[10:29] <dpm> sorry, not *ask, I meant help
[10:30] <dpm> I'm just wondering what the way is to recover from those errors they see on the output of `snap changes`
[10:34] <zyga> dpm: snap changes errors are harmless
[10:34] <zyga> dpm: they are just a trace that something went wrong
[10:35] <zyga> dpm: it seems that people still install using "$snap.$origin" (instead of just $snap)
[10:36] <zyga> dpm: the error with revision 2 there seems interesting though
[10:36] <dpm> zyga, thanks. Not sure, in that case, they're saying the install command was `sudo snap install ubuntu-clock-app`
[10:36] <zyga> dpm: yes, that was the command that was tried next
[10:37] <dpm> ah, I see what you mean now
[10:38] <dpm> zyga, any ideas on what to recommend?
[10:38] <zyga> dpm: I'm responding on askubuntu now
[10:38] <dpm> awesome, thanks!
[10:47] <qengho> zyga: what's the answer? How does he recover? I tried 'strace'ing once to find out.
[10:47] <qengho> I think the strace didn't pass through launcher. I think.
[10:47] <zyga> qengho: I don't know what his problem is yet
[10:48] <zyga> qengho: I asked for additional information: http://askubuntu.com/a/762340/532607
[10:48] <zyga> qengho: at the end of the day it should be possible to wipe snappy state entirely
[10:52] <plars> zyga: not sure what josepht and popey were seeing, but even with your devtools script, I get a kernel oops on mount with xenial on my laptop, and on a trusty system I get this: failed to install "canonical-pc" from "edge": canonical-pc failed to install: [--root /tmp/diskimage700808732/system enable snap-canonical\x2dpc-5.mount] failed with exit status 0:
[10:55] <zyga> plars: odd, I just tested this (including booting) on 0a58844b8b48b2c5d08154b44edd182287e6c589
[10:55] <zyga> plars: seems like a bug in udf
[10:58] <plars> zyga: is that the sha1 of your udf? That's not what I have
[10:58] <popey> fails here too
[10:58]  * popey replied with pastebin to the list
[10:59] <plars> popey: do you get the oops also?
[11:00] <popey> yes
[11:00] <popey> http://paste.ubuntu.com/16046785/ is my dmesg
[11:01] <popey> gah, that mount process is unkillable
[11:04] <ogra_> sounds more like a kpartx bug
[11:07] <zyga> plars: no, that's the head of devtools I'm on
[11:07] <zyga> ouch [  588.493709] BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000010
[11:07] <zyga> kernel bugz
[11:10] <cjwatson> shuduo: LP, amd64/i386> No, that's not true.  amd64 and i386 are the default architectures, but you can use "Change details" on the snap to enable any architecture for which we have good virtualised sandboxing, so any of armhf/arm64/ppc64el.
[11:10]  * ogra_ notes we have working yakkety image builds
[11:14] <zyga> ogra_: snappy images? :)
[11:16] <ogra_> zyga, sure
[11:17] <zyga> ogra_: where are those published?
[11:17] <ogra_> nowhere atm ... you'd have to grab the snaps yourself
[11:17] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[11:20] <ogra_> (and i'm nt sure what we should do with these snaps ... we dont have a 16.10 channel in the store)
[11:28] <ara> zyga, autopilot.service execs "/usr/bin/snap refresh", but that command expects a snap name (or fails if it doesn't have it)
[11:28] <ara> zyga, known bug? or something missing?
[11:34] <zyga> ara: known bug
[11:34] <zyga> ara: (we knew about this before releae)
[11:35] <ara> zyga, but something that it is going to be addressed at some point? shall I file a bug as reminder?
[11:36] <zyga> ara: yes, certainly, we have a card for this, there's a bug as well somewhere AFAIR
[11:36] <ara> zyga, can you point me to the card, please?
[11:37] <zyga> ara: https://trello.com/c/l1EpwBoT/98-re-enable-auto-refreshing-autopilot
[11:37] <zyga> ara: here you go :)
[11:37] <ara> zyga, fantastic, thanks
[11:53]  * zyga refreshed the fix for bug https://github.com/ubuntu-core/snappy/pull/1049
[12:09] <kyrofa> Good morning
[12:12] <kyrofa> mcphail, not sure if you got your question answered, but the ownCloud snap isn't compatible with the desktop just yet
[12:13] <kyrofa> I hasn't been released for Snappy 16-- it's still using rolling
[12:19] <ssweeny> niemeyer, zyga, so what are next steps for https://github.com/ubuntu-core/snappy/pull/1037 ?
[12:21] <sergiusens> morning
[12:24] <dpm> JamesTait, beuno, in the store, what's the difference between 'Make private' and 'Unpublish' for a snap?
[12:24] <sergiusens> dragly in case our question hasn't been answered `export QT_XKB_CONFIG_ROOT=` to some path in your snap and maybe also stage-package xkb-data
[12:24] <sergiusens> zyga ^
[12:25] <JamesTait> dpm, "Make private" puts the package behind an ACL, whereas "Unpublish" removes it from the store.
[12:26] <JamesTait> I suspect your next question might be "How do I set up an ACL?" and I think the answer is that you have to share the package, but it's a part of the UI I'm not familiar with.
[12:30] <zyga> ssweeny: AFK, I'll reply in ~1 hour
[12:30] <ssweeny> zyga, ack
[12:34] <dpm> JamesTait, thanks. Actually, my next question was going to be... what's an ACL? :)
[12:34] <JamesTait> dpm, Access Control List. 😉
[12:34] <dpm> oh, ok
[12:35] <dpm> thanks
[12:35] <JamesTait> dpm, so you might use it, for example, to allow members of your QA team to download a binary from the edge channel to test it before promoting it to stable.
[12:36] <dpm> JamesTait, ok
[12:51] <mcphail> kyrofa: thanks!
[12:55] <dpm> nice one, thanks for the askubuntu answer on snap refresh ara!
[12:56] <beuno> dpm, private snaps are only available to ~canonical, I think
[12:56] <beuno> (atm)
[12:58] <dragly> sergiusens: Thanks! I'll try that out.
[12:59] <dholbach> sergiusens, kyrofa: when do we want to do the clinic?
[12:59] <kyrofa> dholbach, I thought it was tomorrow?
[12:59] <dholbach> did we say tomorrw at 15 UTC (the community Q&A slot)?
[13:00] <dholbach> just wanted to double-check, so I can announce it now :)
[13:12] <Unser> Hello, were do I get the builds for raspberry pi 3?
[13:14] <kyrofa> dholbach, yeah we didn't set a time, but I think 15 UTC works fine
[13:14] <dholbach> kyrofa, perfect
[13:14] <dholbach> sergiusens, ^ does that work for you too?
[13:17] <sergiusens> dholbach I guess; with our current state though I wish we could push it another week, not sure what kyrofa thinks about that :-P
[13:17] <sergiusens> anytime is good tomorrow fwiw
[13:17] <kyrofa> I don't mind pushing
[13:17] <kyrofa> That's a good point actually
[13:18] <dholbach> the week after is UOS
[13:18] <dholbach> that's a good time for demos and stuff anyway
[13:18] <kyrofa> dholbach, snappy 16 is not on ubuntu core yet-- weird situation
[13:18] <dholbach> kyrofa, I'm not sure I understand
[13:19] <zyga> ssweeny: I'll catch up with the conversation on that pull request now
[13:19] <kyrofa> dholbach, unless things have changed since I used edge, snappy on the desktop and snappy on ubuntu core are different
[13:19] <ssweeny> zyga, great, much appreciated :)
[13:20] <dholbach> sergiusens, ^ what do you think?
[13:20] <dholbach> do you think the week after things should be better?
[13:20] <sergiusens> kyrofa we only care about snaps on the desktop/server though (for now)
[13:21] <kyrofa> sergiusens, ah, okay good to know
[13:21] <sergiusens> dholbach I am +1, let's see what olli| thinks
[13:22] <kyrofa> sergiusens, what "state" were you referring to, then, regarding pushing?
[13:22]  * olli| scrolls
[13:22] <sergiusens> kyrofa producing a full fledged desktop snap
[13:22] <sergiusens> not enough interfaces ready yet
[13:23] <sergiusens> or known issues made known :-)
[13:23] <kyrofa> sergiusens, ah, true. None of your attempts worked out either, huh?
[13:24] <sergiusens> kyrofa not really; I will know more this after the group meeting
[13:24] <ogra_> well, it could be a developer desktop ;) installed with --devmode
[13:24] <kyrofa> ogra_, hahaha
[13:24] <sergiusens> kyrofa but the fact that most apps use network manager to get info about connectivity status brings down a lot of options
[13:25] <sergiusens> ogra_ hah
[13:48] <zyga> ssweeny: so looking at this I think we want to implement the per-connection thing better, I'll fork this and give you a patch
[13:48] <ssweeny> zyga, ok fair enough
[14:00] <zyga> ssweeny: quick question, how do you test this?
[14:01] <ssweeny> zyga, I do a smoke test in a vm with your devtools scripts then have someone with a snappy system w/ bluetooth hardware exercise it
[14:03] <ssweeny> zyga, I use this snap btw https://code.launchpad.net/~ssweeny/+snap/bluez
[14:03] <zyga> ssweeny: and the VM, I assume it doesn't have bluetooth, or does it?
[14:04] <ssweeny> zyga, it doesn't, so I only test that bluetoothctl can connect to the daemon
[14:04] <zyga> ok
[14:04] <zyga> ah, right
[14:04] <zyga> that's all I need, thanks!
[14:04] <ssweeny> yw
[14:08] <seb128> dpm, hey, is the store supposed to list things calculator? is it amd64 only or supposed to work on i386 as well?
[14:09] <seb128> is there a snap status command or equivalent?
[14:11] <popey> seb128: its an amd64 only build I believe
[14:11] <seb128> k, that explains -:/
[14:11] <seb128> :-/
[14:11] <seb128> popey, thanks
[14:11] <popey> despite it being qml only, it's got lots of binaries lobbed in to make it work
[14:12] <dpm> seb128, the x86 build does not work for some reason
[14:12] <seb128> I see you guys look down on us i386 users :p
[14:12] <dpm> seb128, you mean *user? :P
[14:13] <seb128> :-)
[14:13] <dpm> :)
[14:13] <seb128> k, next question
[14:13] <seb128> $ sudo snap install hello-world
[14:13] <seb128> error: can't install "hello-world": snap "ubuntu-core" has changes in progress
[14:13] <seb128> how do I figure out what's going on?
[14:13] <dpm> seb128, I actually did an x86 build, but gets a "Bad system call" message when executed on an x86 machine
[14:13] <seb128> there is no status command?
[14:13] <dpm> seb128, `snap changes` perhaps
[14:13] <dpm> and then `snap changes $CHANGEID` to zoom in
[14:14] <seb128> thanks
[14:15] <josepht> I'm having checksum mismatches when I build a snap on my rpi2 and try to upload it to the store.  I'm building in a chroot on the device itself.
[14:15] <popey> seb128: when I had the "changes in progress" issue, the only resolution I had was to nuke my snappy config (and apps) from orbit :(
[14:16] <seb128> popey, where do those live?
[14:16] <popey> so i had to stop the snapd service, umount /snap/*/* and rm all of /var/lib/snapd/* iirc
[14:16] <popey> then reinstall snapd and snap install ubuntu-core
[14:16] <josepht> seb128: reset-state from here should do it.  https://github.com/zyga/devtools
[14:16] <popey> it "fixed" it for me
[14:17] <popey> ooh, we even scripted it!
[14:17] <seb128> josepht, popey, thanks
[14:17] <josepht> seb128: my pleasure
[14:26] <olli|> sergiusens, let's chat in the team mtg
[14:44] <zyga> ssweeny: hey, this is a totally crude attempt at this
[14:44] <zyga> ssweeny: I'll build the snap next but I wanted to show you https://github.com/zyga/snappy/commits/bluez-fix-rules
[14:47] <zyga> ssweeny: one thing I could do is to look at all the apps in the slot
[14:47] <zyga> ssweeny: and let the sender (with the plug) talk to each of those apps specifically
[14:47] <zyga> ssweeny: I'm not sure we want that though
[14:47] <zyga> jdstrand: hey, are you around?
[14:54] <dragly> Is there a way to set LD_LIBRARY_PATH, or do I need to run a script that does this before executing a C++ executable?
[14:55] <zyga> dragly: AFAIR we set something, let me check
[14:55] <ogra_> the launcher does that automatically for a bunch of dirs ...
[14:55] <zyga> dragly: what do you need specifically?
[14:55] <ogra_> (just make sure your libs are in the right location inside the snap)
[14:56] <dragly> I'm trying to set the QT_XKB_CONFIG_ROOT you mentioned, which made me set up a script that does this first
[14:56] <dragly> this however, required me to set LD_LIBRARY_PATH, and now I get "Could not initialize GLX", which lead me to believe that I might have set something the wrong way that shadows the OpenGL libs.
[14:57] <zyga> dragly: opengl stuff is handled separately
[14:57] <zyga> one sec
[14:57] <ogra_> well, just make sure to always keep the existing LD_LIBRABRY_PATH if you actually append anything to it
[14:57] <zyga> dragly: we set SNAP_LIBRARY_PATH
[14:58] <zyga> to /var/lib/snapd/lib/gl:
[14:58] <zyga> looking what picks that up
[14:58] <zyga> the launcher is not
[14:58] <zyga> I guess you want your wrapper
[14:59] <dragly> I just need to set the QT_XKB_CONFIG env variable, so any way that enables me to do that without breaking OpenGL is what I need
[14:59] <dragly> seems like setting LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP_LIBRARY_PATH didn't help
[15:00] <dragly> I must have messed up something else
[15:01] <dragly> is there a way to set env variables in the yaml?
[15:01] <zyga> nope
[15:02] <dragly> is launching the app like this in my wrapper the right way to do it?
[15:02] <dragly> $SNAP/bin/neuronify
[15:03] <zyga> yep
[15:03] <zyga> that will work
[15:06]  * zyga finished meeting and returns to bluez interface and snap
[15:09] <josepht> sergiusens: are you able to build snaps with snapcraft on rpi2 and successfully upload to the store?
[15:09] <shuduo> cjwatson: let me try. thanks!
[15:10] <sergiusens> josepht what are you seeing? my rpi2 has been in the closet for a while; kyrofa has been playing with one though
[15:11] <sergiusens> josepht just in case you are missig the snap registration added last week (you need to go to the store and register the name yourself)
[15:11] <josepht> sergiusens: the snap fails to upload due to a checksum mismatch.  I have registered the name.
[15:12] <sergiusens> dragly $SNAP/bin is in PATH so just `command: neuronify` should be enough
[15:12] <sergiusens> josepht oh; don't know about that; the store guys wrote the upload code for us; so not deeply familiar with it; I'll check or maybe be lazy and ask vila
[15:13] <dragly> sergiusens: Thanks. Still getting the same error about it being unable to initialize GLX. I think it comes from Qt, but I don't know what its missing.
[15:13] <dragly> sergiusens: Adding the QT_XKB_CONFIG_ROOT helped me get a step further, though.
[15:14] <josepht> sergiusens: I don't think it's related to the store though.  I checked the last time I uploaded an rpi2 snap and I get a different checksum if I unsquashfs and resquashfs the snap using the commands from the snapcraft source (at the time)
[15:15] <dragly> Are there any OpenGL packages I should consider adding to stage-packages?
[15:15] <zyga> dragly: I don't think you should
[15:16] <sergiusens> dragly that I don't know, not a GUI person myself; I will fwd you to kgunn for the GLX question
[15:17] <kyrofa> josepht, sergiusens sorry guys, my rpi2 snap takes an entire day to build on the rpi so I started using the LP builders and uploading directly to myapps
[15:18] <sergiusens> kyrofa smart ;-)
[15:18] <vila> josepht: the upload doesn't (and won't) upload the checksum but I think the store checksums the /file/, not its content, but rebuilding the squashfs may change the resulting file
[15:19] <kyrofa> josepht, fails to upload, or fails review?
[15:19] <josepht> kyrofa: fails review
[15:22] <kgunn> dragly: sorry, can you briefly explain what you're up to? i presume building a qml app snap to  run on 16.04 desktop?
[15:23] <dragly> kgunn: I suppose I'm pushing the limits here. I'm building an app with Qt5.7 (we need QtCharts) and trying to pack it with snapcraft.
[15:24] <dragly> I have made a custom plugin that copies all QML modules and Qt libs to the install folder.
[15:25] <kgunn> dragly: hmm...are you digging into our example here as a guide/for instance?
[15:25] <kgunn> http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/
[15:25] <dragly> So far so good, I've gotten all errors about missing platforms, QML modules and libraries to go away, but now I'm stuck with the error "Could not initialize GLX".
[15:25] <kgunn> you can see the clock.wrapper has all the env set
[15:26] <kgunn> dragly: so, accessing gl drivers provided by the host system in ubuntu-core is a very new feature...
[15:26] <dragly> nice, I'll have a look at it and see if I can add anything I'm missing. Thanks!
[15:26] <kgunn> so if you'd be willing to share all your work, it's possible you're just hitting a bug or unforeseen iss
[15:26] <kgunn> dragly: yep, try to look at the example first...
[15:27] <kgunn> if you think you've got it...and still hitting it, then file a bug on ubuntu-core with your work
[15:27] <kgunn> thanks for being an early adopter
[15:29] <zyga> tyhicks: hey, have you seen jamie today?
[15:30] <kyrofa> zyga, I believe he's out today
[15:30] <zyga> ah
[15:30] <zyga> thanks
[15:31] <tyhicks> zyga: hey - he'll be back tomorrow
[15:31] <zyga> tyhicks: do you have time for a quick apparmor question?
[15:31] <tyhicks> zyga: sure
[15:32] <zyga> tyhicks: is it safe/okay to use #include statements inside a particular profile?
[15:32] <zyga> tyhicks: normally we include bits earlier
[15:32] <zyga> tyhicks: but one interface we're working on now does that per plug connection
[15:32] <tyhicks> zyga: are you asking if the #include has to happen at the top of the profile?
[15:33] <zyga> yep
[15:33] <tyhicks> zyga: #include's can go anywhere
[15:33] <zyga> ah, thanks!
[15:33] <tyhicks> no problem
[15:34] <tyhicks> zyga: the parser simply inserts the contents of the #included file right where the #include is found so you'll be fine as long as the inserted contents do not cause a compiler error
[15:38] <josepht> kyrofa: how do I use the LP builders to build my snap?
[15:39] <kyrofa> josepht, it's actually pretty easy. First of all, you need to have an LP project, and push your code there
[15:39] <kyrofa> josepht, are you hosting your code there already, or elsewhere?
[15:39] <josepht> kyrofa: nowhere yet :)
[15:39] <kyrofa> josepht, ah!
[15:40] <josepht> kyrofa: I'll setup a project and push my code there
[15:40] <kyrofa> josepht, yeah, create an LP project and either use bzr or git to get your code up there. Once you have that, come back and I'll continue walking you through :)
[15:43] <sergiusens> kyrofa josepht should even work from +junk
[15:45] <josepht> sergiusens, kyrofa: the builder uses 'architectures' from snapcraft.yaml?
[15:46] <cjwatson> josepht: not yet
[15:46] <josepht> okay
[15:46] <josepht> kyrofa: I've got my project pushed
[15:46] <cjwatson> josepht: https://bugs.launchpad.net/snapcraft/+bug/1533713
[15:47] <kyrofa> josepht, click on the branch you pushed
[15:47] <cjwatson> josepht: (i.e. currently that field does not appear to have the semantics we need)
[15:47] <kyrofa> josepht, and one of the options should be to "Creat a snap package"
[15:47] <kyrofa> with an e in there somewhere
[15:48] <josepht> kyrofa: check
[15:48] <cjwatson> kyrofa: as sergiusens says, you really don't need a full project, and a full project is likely inappropriate in most cases
[15:48] <kyrofa> cjwatson, sergiusens alright thanks :)
[15:48] <sergiusens> cjwatson https://lists.ubuntu.com/archives/snappy-app-devel/2016-April/000654.html in case you have an opinion; sorry I forgot to link that to the bug
[15:49] <cjwatson> I mean, not a project just for the snap stuff.  If there's an existing upstream project for the thing you're packaging then it would normally make sense to put the branch in there
[15:49] <kyrofa> josepht, so you have a snap, but I believe by default it'll only build for x86 and amd64
[15:49] <kyrofa> josepht, so select the snap package, and go to "Edit snap package"
[15:49] <kyrofa> josepht, select the archs you want
[15:50] <cjwatson> sergiusens: can't say I really care about the exact name :)
[15:50] <sergiusens> cjwatson ok; I was planning on fixing it last week but chasing  the snapd story consumed most of our time
[15:50] <kyrofa> josepht, then you should be able to hit "Request builds" on the snap package
[15:51] <cjwatson> sergiusens: sure; likewise probably won't get round to the LP side of it for a little bit, need to focus on the auto-upload-to-store story
[15:51] <cjwatson> sergiusens: but it would at least make it possible :)
[15:52] <kyrofa> cjwatson, what are the limitations on the snap name? Do they need to be unique? Unique to the project? Unique to the user?
[15:52] <josepht> kyrofa: ack.  My branch will need to have the source in it as well.  i.e. it can't pull from github.com?
[15:53] <oparoz> What's the easiest way to add a path to the Snap's LD_LIBRARY_PATH from Snapcraft?
[15:53] <kyrofa> josepht, ah, indeed. I host on github as well, but push to LP for building. Anything beyond that (auto-sync or whatever) is a question for cjwatson probably
[15:53] <kyrofa> oparoz, write a wrapper
[15:54] <josepht> pwd
[15:54] <josepht> :)
[15:54] <cjwatson> kyrofa: unique to the user
[15:54] <oparoz> kyrofa, It's already in a wrapper since it's in an init script, but I don't want to have to deal with the various paths used by various architectures
[15:55] <oparoz> kyrofa, so wondering if that path could be "built" while creating the snap
[15:55] <cjwatson> kyrofa: usual naming constraints for names of things on LP, basically alphanumeric plus [+.-], with the first character alphanumeric only
[15:56] <cjwatson> josepht: git-to-git imports are on the near-term plan; in the meantime, just mirror stuff to LP manually
[15:56] <kyrofa> cjwatson, can multiple branches be associated with the same snap?
[15:56] <josepht> cjwatson: ack, thanks
[15:56] <cjwatson> josepht: but I think both kyrofa and I misunderstood your question slightly
[15:57] <cjwatson> josepht: only the snapcraft.yaml needs to be in a branch hosted on LP; the rest can be pulled from github or wherever
[15:57] <josepht> cjwatson: oh! hrm, my amd64 build failed to clone the nmap repo from github
[15:57] <kyrofa> cjwatson, ah, good catch. josepht I assumed the repo you were referring to WAS the snapcraft.yaml
[15:58] <cjwatson> kyrofa: snapcraft.yaml can reference whatever it likes.  the only thing LP knows about directly is the branch that contains snapcraft.yaml, and it only makes sense for there to be one of those
[15:58] <cjwatson> josepht: URL?
[15:58] <josepht> cjwatson: https://launchpadlibrarian.net/256016424/buildlog_snap_ubuntu_xenial_amd64_nmap_BUILDING.txt.gz
[15:59] <kyrofa> cjwatson, I was more thinking for a little CI infrastructure around a snap being creating by multiple devs collaborating. I actually have PRs and stuff coming in for the owncloud snap, and I'd like to get snaps automatically building. Those are multiple branches
[16:00] <kyrofa> oparoz, you could make use of the SNAP_ARCH variable, or you could add it to a local plugin (or just a part with a Makefile) to generate it at build time
[16:00] <cjwatson> josepht: could you give me the URL that contains /+build/ instead?
[16:00] <kyrofa> The part with a Makefile would probably be easier
[16:00] <cjwatson> kyrofa: no, that doesn't exist.  you could fairly easily just create the necessary snap objects on the fly though.
[16:01] <kyrofa> cjwatson, just name then randomly, essentially?
[16:01] <kyrofa> cjwatson, or delete when done?
[16:01] <cjwatson> kyrofa: either
[16:01] <kyrofa> cjwatson, sounds good
[16:01] <oparoz> Thanks kyrofa. I'll give it a try. I'm currently using a nil plugin since it's just adding a deb
[16:02] <kyrofa> cjwatson, and I just noticed the web hooks there as well
[16:02] <josepht> cjwatson: https://code.launchpad.net/~joetalbott/+snap/nmap/+build/777
[16:02] <kyrofa> cjwatson, how long to the built snaps live before they're removed?
[16:04] <cjwatson> josepht: only http/https is proxied; you need to use https:// rather than git://
[16:05] <josepht> cjwatson: ah, thanks
[16:06] <cjwatson> kyrofa: there's actually no pruning right now, but there should be; expect no more than a couple of days
[16:06] <kyrofa> cjwatson, yeah that seems reasonable
[16:07] <sborovkov> Hi. I see this variable - "SNAP_USER_DATA=/root/snap/screenly-client/100001" -> Is this basically home directory for the snap?
[16:07] <kyrofa> sborovkov, a similar question was recently asked here: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
[16:09] <josepht> kyrofa: thanks a bunch for helping me
[16:09] <josepht> cjwatson: thank you for helping as well
[16:09] <cjwatson> np
[16:09] <kyrofa> josepht, hey any time. Thanks to cjwatson for putting it all in place!
[16:11] <sborovkov> kyrofa: cool, that's what I was interested in, thanks
[16:12] <cjwatson> kyrofa: (but we'll probably try to get auto-upload to the store working before we start pruning; there aren't so many snaps at the moment so we should be able to get away with that)
[16:13] <kyrofa> cjwatson, good to know, but I'll make sure I don't rely on it :)
[16:13] <kyrofa> Hey ogra_ I'm curious what magic you go through to create OS snaps. I don't suppose that's documented anywhere?
[16:15] <ogra_> kyrofa, livecd-rootfs/live-build builds a normal rootfs like you'd do for any other image ... at the point where that gets usually tarred up we intercept and create a snap meta dir and call snapcraft snap
[16:15] <dpm> wow, really nice answer kyrofa, thanks! -> http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
[16:15] <kyrofa> ogra_, oh that's pretty easy, okay
[16:15] <kyrofa> dpm any time!
[16:16] <ogra_> kyrofa, line 322-346 http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build#L322 is the code we actually use to snap it up
[16:17] <kyrofa> ogra_, excellent, thank you!
[16:17] <ogra_> if you want to set up your own build env, perhaps take a look at project-rootstock-ng (rather outdated, but the principle didnt change)
[16:17] <dpm> JamesTait, beuno, what exactly can I use the share link in a snap for? Which kind of access does it grant in the store to the people I send it to?
[16:20] <kyrofa> ogra_, isn't rootstock deprecated though? (https://wiki.ubuntu.com/ARM/RootStock) why use that instead of live-build?
[16:20] <ogra_> kyrofa, -ng ... it is deprecated, but -ng is a wrapper around live-build
[16:20] <kyrofa> ogra_, ahh
[16:21] <ogra_> just so you get an impression how your build chroot should be set up
[16:21] <ogra_> (and the env around it)
[16:21] <kyrofa> ogra_, gotcha, exactly what I was looking for, thank you :)
[16:22] <JamesTait> dpm, I'm not actually completely sure.  IIRC, it gives you permission to download the package from a device, so in that respect it's similar to having store reviewer permissions. I think it also gives you permission to manage the package through the web UI, as if it were your own.
[16:23] <dpm> JamesTait, ah, the latter is the bit I'm interested in, so I guess it's a way to have a team manage package uploads and editing metadata, right?
[16:23] <JamesTait> e.g. I have a snap package that someone shared with me, and I can upload a new revision, unpublish, make it private, and edit at least some of the metadata.
[16:23] <JamesTait> Exactly. ☺
[16:23] <dpm> ah, great, exactly what I was looking for :)
[16:33] <oparoz> Is it Snapcraft or the store which signs snaps?
[16:33] <kyrofa> oparoz, the store
[16:34] <oparoz> Thanks kyrofa
[16:36] <wililupy> Do any of you know of a way to actually see the package contents of a .snap?
[16:36] <oparoz> unsquashfs
[16:37] <wililupy> I didn't think of that. I'm trying to see why my kernel.snap says there is no kernel and yet is 74MB.
[16:37] <ogra_> All modules ? ;)
[16:40] <sergiusens> oparoz you will eventually be able to sign snaps as well
[16:40] <oparoz> Is there a helper in snappy which writes users to extrausers or do we need to echo users to those files?
[16:40] <oparoz> Thanks sergiusens
[16:41] <sergiusens> oparoz iirc adduser worked
[16:42] <sergiusens> ogra_ didn't I add a flag to write to extrausers, or maybe you did?
[16:43] <oparoz> sergiusens, it might be because I'm using an older version of core, but it fails
[16:43] <oparoz> groupadd: cannot lock /etc/group; try again later.
[16:51] <sergiusens> kyrofa one step further with electron; although nodejs is hurting my brain!
[16:51] <kyrofa> sergiusens, haha, I believe it!
[16:58] <ogra_> oparoz, yu need the --extrausers arg for adduser
[16:58] <ogra_> oparoz, though why would you even add users there at all ? your snap should surely not use the system password db
[16:59] <oparoz> ogra_, without adding any other flags, it still fails with: /usr/bin/chfn: unrecognized option '--extrausers'
[17:00] <oparoz> ogra_, but you're right, I may not need extra users. I'm testing things. It's for a Samba server
[17:00] <ogra_> you can ignore that bit (there is a bug open for it i need to SRU)
[17:00] <ogra_> (the chfn)
[17:00] <oparoz> ogra_, thanks for the heads up about the bug
[17:15] <kyrofa> sergiusens, elopio I totally lost track of time
[17:16] <sergiusens> kyrofa oh, me too, no worries; let's skip and keep on rolling desktop snaps
[17:16] <kyrofa> sergiusens, whew, okay sounds good
[17:16] <sergiusens> kyrofa any luck on your side?
[17:17] <edsiper> is Ubuntu core already released for the Dragonboard _
[17:17] <edsiper> ?
[17:18] <kyrofa> sergiusens, no. I finished fleshing out the indicators/notifications bug, now I'm hunting for another qt example to snap
[17:20] <kyrofa> sergiusens, I'm gonna go with the simple text editor. That shouldn't require any special interfaces
[17:23] <kyrofa> sergiusens, have you messed with .desktop files yet?
[17:58] <wililupy> I'm trying to clean-cache with the latest u-d-f and it keeps keeps saying unknown command. How do I clear the cache to get the latest builds?
[18:00] <ogra_> look under ~/.cache
[18:02] <wililupy> orgra_ any specific directory? There are 2 .fr-* directories with data.tar.xz, is that it?
[18:05] <kyrofa> zyga, is there any documentation about using .desktop files in meta/gui ?
[18:05] <zyga> kyrofa: not that I know of
[18:05] <zyga> kyrofa: I can tell you how it works
[18:05] <zyga> kyrofa: and how to use it
[18:05] <kyrofa> zyga, please do :)
[18:05] <zyga> kyrofa: but I don't think it's written down anywhere
[18:05] <zyga> kyrofa: desktop files from meta/gui are parsed, sanitized and placed in /var/lib/snapd/desktop
[18:06] <zyga> kyrofa: ${SNAP} is expanded (exactly ${SNAP}, nothing else) to point to the snap install/mound directory
[18:06] <zyga> kyrofa: the icon needs to refer to ${SNAP}/something (e.g. ${SNAP}/meta/gui/icon.png) to work
[18:06] <zyga> kyrofa: that's all I remember
[18:07] <kyrofa> zyga, when you say "sanitized" I assume that means there are limitations to what I can put in there?
[18:07] <zyga> you can put anything, we just filter out some things
[18:07] <zyga> and "allow" only certain things that are safe
[18:07] <zyga> e.g. no TryExec
[18:07] <zyga> it's pretty crude but the idea is that untrusted .destkop files are okay
[18:08] <kyrofa> Alright, thanks :)
[18:17] <sergiusens> kyrofa desktop files, just drop them in `setup/gui/<app>.desktop`
[18:17] <kyrofa> sergiusens, yeah, I was just curious about the parsing/sanitization
[18:32] <kyrofa> zyga, does the home interface not automatically connect?
[18:32] <ogra_> no
[18:33] <kyrofa> ogra_, is that a bug or is there a reason for that?
[18:33] <sergiusens> kyrofa on purpose
[18:34] <ogra_> security ;)
[18:35] <kyrofa> Huh. I wish `snap install` would have told me :P
[18:35] <ogra_> we can key-log all your Xorg keystrokes, but cant store them in your home dir ;)
[18:37] <zyga> kyrofa: no, it's super dangerous as you can steal almost all user data
[18:37] <kyrofa> zyga, and X isn't?
[18:37] <zyga> kyrofa: that's on a TODO list, we just basically had no way to do it lately
[18:37] <kyrofa> ogra_, yeah exactly, haha
[18:37] <ogra_> shhh
[18:38] <zyga> kyrofa: X is bad but then most apps don't work without X
[18:38] <zyga> kyrofa: but most apps *can* work without your real HOME
[18:38] <kyrofa> zyga, nah, I understand. Just caught me by surprise
[18:44] <kyrofa> sergiusens, alright, first (relative) success: https://github.com/kyrofa/qt-example-snaps/tree/master/application
[18:50] <kyrofa> zyga, is there a way to access the webcam via interfaces?
[18:59] <zyga> kyrofa: no, not today
[18:59] <zyga> kyrofa: we need hooks to make that sane
[19:00] <kyrofa> zyga, alright
[19:00] <zyga> kyrofa: as those are typically dynamic objects
[19:00] <kyrofa> zyga, right yeah, all that hw-assign stuff is
[19:02] <zyga> kyrofa: having said that, I was working on the pi2 camera iface a while ago
[19:02] <zyga> kyrofa: the interface itself wasn't hart, what was the problem at the time was lack of proper firmware and shared libs in the base image
[19:02] <zyga> kyrofa: I'm sure the next few weeks will see a rapid evolution of interfaces
[19:03] <kyrofa> zyga, rapid evolution + SRU = ? :P
[19:08] <sergiusens> kyrofa does it look good? is it in the store already? :-)
[19:09] <kyrofa> sergiusens, no, should I put it in the store? And yeah, it's not bad
[19:09] <sergiusens> kyrofa is it all your code or some upstream project?
[19:09] <kyrofa> sergiusens, upstream
[19:09] <kyrofa> sergiusens, they're qt examples
[19:10] <sergiusens> ah
[19:10] <sergiusens> kyrofa maybe get a gtk example in next ;-)
[19:10] <kyrofa> sergiusens, alright I've got one more qt one, then gtk
[19:13] <sergiusens> kyrofa heh, will and seb might take on gtk
[19:19] <Domi> Hello, where do I get the images for raspberry pi 3?
[19:30] <kallisti5> ...  is not of type 'object'
[19:30] <kallisti5> I don't get it.. I pretty much get that from snapcraft for everything
[19:31] <kyrofa> kallisti5, sounds like your YAML isn't right
[19:31] <kyrofa> kallisti5, want to put it in http://pastebin.ubuntu.com/ ?
[19:32] <kallisti5> http://pastebin.ubuntu.com/16055433/
[19:32] <kallisti5> err.. ignore r1scsi there... that should read "thing"
[19:34] <josepht> kallisti5: it looks like you're missing 'command:" in your app
[19:35] <kallisti5> heyyy
[19:35] <kallisti5> that did it
[19:37] <kyrofa> kallisti5, yeah that was just invalid YAML
[19:39] <dragly> when running "snapcraft", is it possible to specify that a part with "plugin: copy" should rerun (i.e. clean and then copy the files again)
[19:39] <dragly> cloning and building the rest of the project takes some time
[19:42] <kyrofa> dragly, yes, you can give snapcraft specific parts
[19:42] <kyrofa> dragly, e.g. snapcraft stage part1
[19:42] <kyrofa> dragly, you also don't need to clean completely
[19:42] <kyrofa> dragly, try cleaning only back to the build step: snapcraft clean -s build
[19:43] <kyrofa> dragly, or cleaning only part1 back to the build step: snapcraft clean part1 -s build
[19:43] <dragly> thanks!
[19:47] <dragly> is it possible to "chroot" into the snap to inspect the environment somehow?
[19:54] <dragly> kgunn: Thanks for showing me the example. I got a bit further now, but both with the example and my own package I get the following error:
[19:54] <dragly> libGL error: No matching fbConfigs or visuals found
[19:54] <kgunn> dragly: interesting, so if you build and sideload the example snap that occurs?
[19:55] <dragly> sorry, I don't know what sideload means
[19:55] <kgunn> dragly: sideload==you build it locally and did sudo snap install mylocallybuild.snap
[19:55] <kgunn> vs download/install from the snap store
[19:55] <dragly> yes
[19:55] <kgunn> oh ok, this is weird then
[19:55] <dragly> sudo snap install ubuntu-clock-app_3.6+snap2_amd64.snap; ubuntu-clock-app.clock
[19:56] <kgunn> i wouldn't have expected that
[19:56] <dragly> I have Nvidia drivers on my host system, if that matters
[19:56] <kgunn> dragly: it shouldn't...but possibly
[19:56] <kgunn> dragly: do you have a hybrid gpu system?
[19:57] <dragly> not on this machine, no
[19:57] <kgunn> like 2 gpus and drivers available at the same time ?
[19:57]  * kgunn thinks for a moment
[19:59] <kgunn> dragly: on your machine do you have something like /usr/lib/nvidia-<xxx>
[19:59] <kgunn> containing the nvidia drivers?
[20:01] <dragly> here are some findings, if they help:  /var/lib/snapd/lib/gl/ is empty on the host, /usr/lib/nvidia-361 exists on the host and has a libGL.so, but in the snap I only find libGL.so in ./usr/lib/x86.../mesa
[20:03] <dragly> looking at the older snaps I had for my own project, I see they copied nvidia-361 to ./usr/lib
[20:03] <kgunn> dragly: right, the idea implemeted was to permit the snap to leverage the libgl from the host system, rather than copy in...
[20:04] <dragly> this however stopped at some point (I realize now I should have used version control while working on this too)
[20:04] <kgunn> b/c otherwise you're stuck to that gpu/impl
[20:04] <dragly> that makes sense
[20:04] <kgunn> dragly: but like i say that was a very recent addition
[20:04] <kgunn> of a feature to ubuntu-core/snapd etc
[20:04] <dragly> I'm using snapcraft as installed with "sudo apt install" by the way
[20:05] <dragly> version 2.8.4
[20:05] <kgunn> dragly: i think that's fine...
[20:05] <kgunn> dragly: this is more about not being able to find the drivers at run
[20:06] <kgunn> dragly: interesting...someone else seemed to have a very similar prob last week
[20:06] <kgunn> http://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096
[20:06] <kgunn> so i'm wondering if there's just a niggly nvidia symbolic link issue going on
[20:07] <kgunn> what else is /usr/lib/nvidia-361 have inside?
[20:07] <dragly> seems reasonable, considering other's findings like here: https://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update
[20:08] <kgunn> dragly: :-/ bummer...but wonder if some sort of reinstall of those drivers might help?
[20:08] <kgunn> i don't have nvidia myself...i've asked someone in another channel, just to give it a go
[20:08] <dragly> http://pastebin.com/ABU2THVw
[20:09] <kgunn> i do know one of the snappy team guys tried the feature out building on intel/run on nvidia then vice/versa...and the feature worked...
[20:10] <dragly> I'll try reinstalling and doing a quick reboot
[20:11] <dragly> I can also try it on a machine with intel, just give me a couple of minutes
[20:12] <kgunn> dragly: hey, when did you start trying snapcraft and ubuntu-core on desktop?
[20:12] <kgunn> reason i ask, is at one point i ran into problems with an update...
[20:13] <kgunn> and  i did have to reinstall...but if you've only started in the last week or so...may be a red herring
[20:13] <kgunn> but at one point i had to run a script like this
[20:13] <kgunn> https://pastebin.canonical.com/155170/
[20:13] <kgunn> and then reinstall ubuntu-snappy-cli and ubuntu -core etc
[20:13] <kgunn> fwiw
[20:15] <dragly> I started yesterday
[20:16] <dragly> cannot access the pastebin
[20:16] <dragly> but I can try reinstalling those
[20:29] <dragly> moving the clock .snap to a laptop with intel produces the following error:
[20:29] <kgunn> dragly: sorry bout that
[20:29] <kgunn> http://pastebin.com/68FTk1gv
[20:30] <dragly> QXcbConnection: Could not connect to display :0
[20:32] <dragly> building and running on Intel laptop works
[20:32] <dragly> That is, it has Nvidia Prime, but I've disabled Nvidia and running only on Intel now.
[20:32] <dragly> I'll try moving it to the other machine.
[20:33] <dragly> same error, I'll try the script you sent now
[20:34] <kgunn> dragly: sorry, confused...so you did have success running on intel?
[20:34] <dragly> yes, building and running the clock example on intel works
[20:34] <dragly> building on intel, running on nvidia doesn't work
[20:34] <dragly> building on nvidia, running on either doesn't work
[20:35] <wililupy> I have a custom kernel snap and I build my image using u-d-f, and when I install it to my device and try to boot up, I get the following error: http://pastebin.ubuntu.com/16056244/ and it goes back to the grub menu.
[20:36] <wililupy> system will boot when using the stock snappy image, but I need custom modules so I build my kernel snap and it builds successfully, everything looks good in the .snap file, but I can't boot the device. Any pointers?
[20:40] <dragly> kgunn: After running the script and reinstalling snapd and snapcraft (should I have reinstalled others?), installing the package built on intel and running it on nvidia gives the QXcbConnection error (not seen on that machine before)
[20:41] <dragly> and, the same happens if I run the script once again and build the whole example from scratch. So still having some issues, but the error message changed.
[20:41] <pedronis> dragly: does the snap asks for unity7 and x11 plugs?
[20:42] <kgunn> pedronis: he's using the clock example i think
[20:42] <dragly> yes, it's the clock example. "plugs: [unity7,opengl]"
[20:43] <dragly> really strange, reinstalling the snap on the nvidia system (no rebuild) gives the previous "libGL error: No matching fbConfigs or visuals found"
[20:43] <dragly> I don't see how the reinstall changes anything
[20:43] <pedronis> mmh, this sounds more like the issue of security not being regenerated on updates
[20:43] <dragly> I'll diff the folders...
[20:43] <pedronis> (we are working on it)
[20:44] <kgunn> dragly: confirmed with another guy who has nvidia...he's seeing your libgl err
[20:44] <dragly> kgunn: ok, thanks
[20:44] <kgunn> so i think this might be a bug, we'll need to work with mvo on it tomorrow
[20:45] <pedronis> yes, that one seems a genuine different problem
[20:45] <pedronis> (the cannot access display more the security not setup on update one instead)
[20:46] <dragly> kgunn: Great. Let me know if I can help. I really like this project and would love to see it succeed.
[20:46] <sergiusens> kyrofa elopio telegram seems busted here, I get notifications but can't see messages
[20:47] <dragly> pedronis: Ok, thanks for letting me know. I'll keep that in mind when I see the error next time.
[20:58] <dragly> Is there a way to specify where snapcraft outputs the folders like "parts", "stage" and so on?
[20:58] <wililupy> I feel like I'm missing a module from my kernel config for loop in my snapcraft.yaml for the kernel_initrd_modules...
[21:03] <ogra_> wililupy, heh, no, that wouldnt help you with grub :)
[21:03] <ogra_> wililupy, you want loop support builtin
[21:04] <ogra_> if grub fails with a "cant find loop" error you are far before the initrd in your boot process
[21:09] <wililupy> ogra_ the funny thing is that I created an image using u-d-f with all the defaults, and it works, but when I change the --kernel=my-kernel.snap, it doesn't boot up.
[21:10] <ogra_> did you use snapcraft to create the kernel snap ??
[21:10] <wililupy> ogra_ yes.
[21:10] <ogra_> well, then the snap structure should be ok i guess
[21:11] <wililupy> ogra_ I verified it by unsquashfs and everything looks good.
[22:20] <zerwas> On Ubuntu 16.04 Desktop (upgraded from 15.10), the snap command does not work for me. It immediately exits with: "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?q=test&sources=store: dial unix /run/snapd.socket: connect: no such file or directory". What might cause this?
[22:23] <zerwas> I just realized it might have to do with me still using upstart instead of systemd.
[22:27] <ogra_> uuuh
[22:43] <Domi> Hello, i get the error "Unable to locate package snappy-tools" what is wrong?
[22:45] <zerwas> Domi: Do you need a package called snappy-tools?
[22:46] <Domi> yes I want to create a .snap with snapcraft
[22:48] <Domi> In the documentaion is written that I just have to "sudo apt install snappy-tools"
[22:51] <Domi> https://developer.ubuntu.com/en/snappy/build-apps/get-started/
[22:51] <oparoz> Domi, what happens if you jhust try to apt install snapcraft?
[22:52] <Domi> i think i need the other tools too. Do you use Snappy ?
[22:53] <oparoz> Domi, yes, I use Snapcraft
[22:53] <Domi> how did you install it?
[22:53] <oparoz> The link you gave me has either just been updated or is telling me to install snapcraft
[22:53] <oparoz> The old documentation required snappy-tools
[22:55] <oparoz> Domi: I followed this guide: https://github.com/owncloud/ubuntu-snap/wiki/Building-your-first-snap
[22:56] <oparoz> But that's to build snaps from within Snappy
[22:59] <Domi> did you install snapcraft on ubuntu core or on a deskop version of ubuntu?
[22:59] <oparoz> Domi on core
[23:01] <Domi> oh ok. I thought it would be possible to pack the snap on my normal deskop machine and then upload it to core
[23:02] <Domi> because it says "Once your Ubuntu host system is up and running, you can then install the snappy-tools package, which will in turn install the optimal selection of Snappy development software to your system."
[23:02] <oparoz> Domi, yes, it should be possible, but I haven't tried yet and if I'm not mistaken, core is a bit behind and unstable, so you may run into some surprises
[23:03] <Domi> ok I just want so python core running and use the GPIOs of the raspberry pi.
[23:03] <oparoz> whereas if you develop in a VM using core, you should be able to test things right away
[23:04] <oparoz> I use an amd64 vm for bigger stuff and develop straight on the Pi for lighter stuff
[23:04] <oparoz> It works pretty well, thanks to the launchpad builders
[23:07] <Domi> launchpad builders?
[23:07] <oparoz> If you push your git code to launchpad, you can ask LP to build snaps for various architectures
[23:08] <Domi> ok, but it is not possible to use any IDE on core or?
[23:09] <oparoz> What I do is push files from my workstation to the core VM, so I can use any desktop IDE I want
[23:10] <oparoz> It's probably possible to launch an IDE from core, if you can find one
[23:11] <Domi> so you write your code on the workstation and than move it to core. On core you make a .snap and than you install the .snap
[23:12] <oparoz> That reminds me that I'm able to use snapcraft on core because I still have classic mode, but that's been removed...
[23:14] <oparoz> There is one piece of the puzzle I'm missing. If I wanted to build from the desktop, how do I make sure I target core and not the desktop...
[23:15] <oparoz> Because if the latest images of snappy don't have classic mode, I don't know how you're going to build a snap
[23:17] <Domi> ok without classic mode there is no way to build the snap on core. Should I ask tomorrow someone on how to install snapcraft on desktop?
[23:18] <oparoz> Installing Snapcraft is not the problem
[23:18] <oparoz> just apt install
[23:19] <oparoz> but the documentation goes from install snapcraft to "your first snap"
[23:20] <Domi> no the documentation says install snappy-tools which is not available in apt
[23:20] <oparoz> No, that's the old documentation
[23:20] <oparoz> https://developer.ubuntu.com/en/snappy/build-apps/get-started/
[23:20] <oparoz> $ sudo apt install snapcraft
[23:20] <oparoz> That's the doc for 16.04
[23:22] <Domi> ok thank you, i read https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md which is for 16.04 too. very  confusing
[23:25] <Domi> I will follow this guide tomorrow. Thank you for your greate help
[23:27] <oparoz> You're welcome


[16:32] <coldzero> salam
[17:35] <A7med> salut coldzero_
[17:35] <coldzero_> salut cava?
[17:35] <A7med> yep
[17:35] <A7med> u ?
[17:36] <coldzero_> fine thks
[17:36] <A7med> new here ?
[17:36] <coldzero_> yes :)
[17:37] <A7med> welcome :)
[17:38] <coldzero_> i want to know about your activity
[17:38] <coldzero_> what  you do exactly?
[17:39] <Neo31> events, conferences, promoting Ubuntu and free software ..
[17:40] <Neo31> www.ubuntu-tn.org
[17:40] <coldzero_> are you one of the team?
[17:41] <Neo31> we are the community of Ubuntu Users in Tunisia, and an approved Ubuntu LoCo Team
[17:41] <coldzero_> good
[17:41] <Neo31> yes I am a member of this community
[17:41] <coldzero_> how can i be one of you?
[17:42] <Neo31> sign up to lanchpad and subscribe to our group on the launchpad
[17:42] <Neo31> sign up to our mailing list
[17:42] <Neo31> that's all
[17:43] <coldzero_> i do it
[17:43] <coldzero_> so?
[17:43] <Neo31> in addition to the mailing list u can find us here on irc or we have a groupon facebook too
[17:43] <Neo31> well everything is on www.ubuntu-tn.org
[17:44] <Neo31> https://wiki.ubuntu.com/TunisianTeam#Comment%20nous%20rejoindre
[17:44] <Neo31> :)
[17:45] <Neo31> l'll be here if u need any more information
[17:45]  * Neo31 brb
[17:45] <coldzero_> thank you man
[17:45] <coldzero_> ;)
[17:48] <coldzero_> now i'm one of your community how can i help?
[18:27] <ANIS> salam coldzero, crack3r et machour
[18:27] <crack3r> w salam ANIS
[18:27] <ANIS> :d
[18:27] <coldzero> cava?
[18:28] <coldzero> salam
[18:28] <ANIS> hmd, t'es nouveau coldzero?
[18:28] <coldzero> wi :)
[18:28] <ANIS> welcome :D
[18:28] <coldzero> thks
[18:35] <coldzero> chkoun ye5dem 3la ubuntu 11 ?
[18:36] <ANIS> me
[18:37] <coldzero> famma fare9 mabinou houwwa wel lucid?
[18:38] <ANIS> oui bien sûr.. il utilise Libre office à la palace de Oo et unitty pardéfaut à la place de gnome
[18:41] <coldzero> ena 5ofet lanbaddel min lucid lil 11
[18:41] <coldzero> hhhhhhhhhhhhhh
[18:41] <ANIS> 3léch?
[19:55] <Fanen> salem
[20:22] <Fanen> est ce que la communauté tunandroid a un chan IRC
[20:22] <Fanen> ?
[20:31] <crack3r> Fanen, ils ont une mailing liste et un fofo
[22:39] <biscraft> Yop
[22:59] <nizarus> yep
[23:02] <bemawi> re


[11:42] <harmw> ah great, my FreeBSD image has / mounted on the middle partition; making it impossible to resize
[21:38] <pquerna> smoser: https://github.com/pquerna/cloud-init/pull/1 -- mostly a heads up, don't intend it to be quite submitable to y'all yet, but it takes the JSON similiar to the one seen in https://review.openstack.org/#/c/85673/ to build a debian or rhel net conf.
[21:38] <pquerna> smoser: i'll get it into bzr, tests, etc in the next week i guess.