[02:23] <liuxg> can anyone tell me why the "hello-world" example snap does not have the wrapper files after installation?
[02:27] <liuxg> elopio, ping
[04:32] <mup> Bug #1604964 opened: huge download for nothing - snap does not exist <Snappy:New> <https://launchpad.net/bugs/1604964>
[05:49] <zyga> good morning
[05:53] <e^1> good morning :)
[05:54] <e^1> zyga: looks like you are closer to my TZ
[05:55]  * e^1 reboots
[06:05] <didrocks> good morning
[07:06] <dholbach> hey hey
[08:43] <zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1360199 :)
[08:49] <lpotter> :)
[08:51] <Son_Goku> zyga: check it again :)
[08:52] <zyga> Son_Goku: I just saw, thank you :)
[08:52] <zyga> Son_Goku: btw, you are up early ;)
[08:52] <zyga> Son_Goku: are you jetlagged?
[08:52] <Son_Goku> yep
[08:53] <Son_Goku> my coworkers were all freaked because I was cheery as hell when I got in at 9am
[08:53] <Son_Goku> because I'm usually more sour in the morning
[08:53] <Son_Goku> looks like it'll be the same today...
[08:53] <ogra_> lol, thats awesome !
[08:59] <Son_Goku> zyga, I think I've addressed all the things I noticed in the ticket
[09:00] <Son_Goku> so take a stab at resolving them, please :)
[09:02] <zyga> Son_Goku: with pleasure
[09:13] <Son_Goku> zyga, more feedbacks :)
[09:14] <zyga> Son_Goku: THANK YOU, the feedback you get is immensly valuable
[09:14] <zyga> Son_Goku: let me spend some time on iterating now
[09:15] <zyga> Son_Goku: snap-confine is "easy" but the C conventions for packaging are a new thing there
[09:15] <Son_Goku> :)
[09:15] <dpm> hi Son_Goku, did you get back home allright? :)
[09:15] <Son_Goku> yep
[09:15] <dpm> excellent
[09:15] <Son_Goku> €160 poorer due to emergency taxi to FRA, but managed it :)
[09:16] <dpm> argh, glad you made it in any case
[09:16] <Son_Goku> thank god I had the foresight to enable my credit cards in Europe
[09:16] <Son_Goku> otherwise I would have been really screwed
[09:17] <dpm> good thinking :)
[09:18] <Son_Goku> only reason I needed to do it was because I woke up too late :/
[09:18] <Son_Goku> I missed my shuttle and the next one would have been far too late
[09:18] <Son_Goku> made it to the plane with 10 minutes left on the clock
[09:18] <cking> hi there, how long does it take for a snap name registration to take to be reviewed? I've had one pending review since yesterday
[09:21] <Son_Goku> I definitely enjoyed being in Germany for the sprint though
[09:36] <Son_Goku> zyga, in regards to C conventions for packaging, at least for RPM based distros as long as you're using the correct macros, it should just "agree"
[09:37] <Son_Goku> SUSE defines %_libexecdir as /usr/lib, while Mageia defines it as %_libdir
[09:37] <Son_Goku> provided you pass the macro parameters to snapd, it should agree with snap-confine
[09:42] <zyga> Son_Goku: I revertee back to just plain %configure for now
[09:42] <zyga> Son_Goku: we can change it once it actually matters
[09:42] <Son_Goku> right
[09:43] <Son_Goku> afaik, plain %configure should define --libexecdir
[09:44] <Son_Goku> then your autoconf stuff can just automatically install to the subdirectories it creates in %_libexecdir
[09:46] <Son_Goku> yep, rpm -E %configure indicates as much
[09:55] <sergiusens> cking registering snap names should be instant
[09:56] <sergiusens> cking uploads of snaps can get blocked
[09:56] <sergiusens> cking or did you claim a name
[09:56] <cking> I claimed a name
[09:56] <cking> and that's "pending review"
[09:57] <cking> considering it's a package that I own anyhow in Debian and Ubuntu, I thought it would be trivially fast to get it reviewed and accepted
[09:59] <noise][> cking: I can look into that for you, we are still ironing out processes around these things
[09:59] <cking> noise][, ok, thanks!
[10:01] <noise][> cking: approved!  sorry for the delay
[10:02] <cking> thanks \o/
[10:07] <stgraber> zyga: https://bugs.launchpad.net/snappy/+bug/1606510
[10:07] <mup> Bug #1606510: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
[10:07] <mup> PR snapd#1577 closed: daemon, cmd/snap: refresh --devmode <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1577>
[10:07] <mup> Bug #1606510 opened: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
[10:31] <hades|2> can i upgrade my ubuntu core 15.04 kernel to 16.04 ?
[10:31] <hades|2> using ubuntu-core-upgrader ?
[10:42] <hades|2> is it possible to use ubuntu-core-upgrader to upgrade an existing ubuntu-corehost using  an img file ?
[10:45] <ogra_> hades|2, nope
[10:46] <ogra_> hades|2, snapd manages upgrades of snap packages ... upgrading the system is just "snap refresh"
[10:46] <ogra_> that will upgrade all snap packages including kernel and rootfs
[10:47] <Chipaca> what is ubuntu-core-upgrader?
[10:48] <ogra_> that package that carries do-release-upgrade
[10:48] <ogra_> (update-manager for headless systems)
[10:48] <hades|2> my host doesnt have snap refresh
[10:49] <Chipaca> ogra_, is it anything to do with snap?
[10:49] <ogra_> nope
[10:49] <Chipaca> sigh
[10:49] <ogra_> it is for classic installs
[10:49] <hades|2> starting from 16.04 ?
[10:50] <ogra_> Chipaca, would be trivial to make it call "snap refresh" at the end of the upgrade though :)
[10:50] <ogra_> but i guess thats kind of pointless given snaps refresh themselves
[10:50] <Chipaca> ogra_, 15.04 is so long ago, i'm pretty sure 'snap refresh' wasn't a thing then
[10:51] <hades|2> what about old ubuntu-core based on vivid/15.04 , how to upgrade to 16.04 ?
[10:51] <ogra_> oh, i missed the 15.04 part above
[10:51] <ogra_> (just rebooted to switch my session to unity8 ... backklog slipped through)
[10:51] <ogra_> hades|2, you cant
[10:51] <Chipaca> hades|2, wait, are you asking about *snappy* ubuntu core, or classic ubuntu core?
[10:51] <hades|2> snappy
[10:52] <ogra_> the image setup has changed in incompatible ways
[10:52] <Chipaca> and we don't have blessed core images yet anyway
[10:52] <ogra_> (as has the snap format and other things)
[10:52] <ogra_> right, there are no 16.04 images yet ...
[10:53] <hades|2> ok thx
[10:54] <ogra_> i assume that wont happen anymore though ... series 16 snap images should be upgradeable to series 18 snap installs later on
[10:54] <ogra_> 15.04 was kind of special in that regard, nothing was really finalized back thn
[10:54] <ogra_> *then
[10:55] <mup> PR snapd#1580 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1580>
[10:55] <mup> PR snapd#1586 opened: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by chipaca> <https://github.com/snapcore/snapd/pull/1586>
[10:55] <ogra_> uh... bamf ... thats still alive ?
[10:56] <Chipaca> ogra_, as much as unit7 is
[10:56] <Chipaca> :-)
[10:56] <ogra_> heh
[10:56] <hades|2> ill reflash a host using a series 16 img then
[10:56] <Chipaca> ogra_, I think we do want to support 15.04->16 upgrades, but it's definitely not there yet
[10:57] <Chipaca> hades|2, there are no official 16 core images yet
[10:57] <ogra_> Chipaca, yeah, i was talking about 16->18 :)
[10:57] <hades|2> so is it safe to keep my current snappy 15.04 host ?
[10:58] <ogra_> until we announce official 16 series images you should better keep it, yeah
[10:59] <hades|2> using snappy update / snap refresh i might be ablke later on to upgrade "safely" too ?
[11:00] <Chipaca> hades|2, that is the plan as i understand it
[11:00] <Chipaca> hades|2, no reverts of that refresh though
[11:01] <Chipaca> hades|2, or in 15.04 parlance, no rollbacks of that upgrade
[11:01] <Chipaca> *update
[11:01] <Chipaca> :-)
[11:01] <hades|2> it should be fine for me although
[11:17] <kalikiana> Hrm. What is normally supposed to update snaps? Because of a blog post I "snap refresh"ed vlc, it evidently didn't update automatically. Am I missing some package for that?
[11:18] <ogra_> nope, there is a system service (systemd timer) that does the automated snap refresh runs
[11:19] <ogra_> not sure on what schedule that runs on classic installs though
[11:19] <ogra_> Chipaca, might know
[11:37] <mup> PR snapd#1529 closed: snap: rework the output after a snap operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1529>
[11:45] <stokachu> sergiusens: could we invoke any parts this way before the npm install takes place? https://www.irccloud.com/pastebin/5m23iw2R/
[11:46] <stokachu> the hook could be preinstall
[11:47] <Cavan> I disconnected so I dont know if my messege sent (Sorry if It did): I still cant get Karaf to write to files, my wrapper is '#!/bin/sh set -e set -x  export KARAF_DATA="$SNAP_DATA" export KARAF_HOME="$SNAP"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH $KARAF_HOME/bin/karaf r
[11:50] <ogra_> Cavan, $SNAP_DATA is not user writable, is that a service or a binary a user would execute ?
[11:51] <ogra_> in case of the second you would have to use SNAP_USER_DATA
[11:51] <ogra_> (also setting HOME to SNAP if your app tries to write to its home wont work, $SNAP is readonly)
[11:58] <mup> PR snapd#1563 closed: Interfaces: hardware-observe <Created by cwayne18> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1563>
[12:04] <Cavan> ogra_, So is this how it should be? 'export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_DATA"'
[12:05] <ogra_> i would point both to SNAP_USER_DATA actually
[12:05] <ogra_> if thats an enduser app that a user executes
[12:14] <Cavan> ogra_, Im still getting 'mkdir: cannot create directory ‘/snap/karaf/x17/data/log’: Read-only file system' any idea what I could do?
[12:15] <ogra_> thats $SNAP
[12:15] <ogra_> so whatever you use in that mkdir should point to $SNAP_USER_DATA
[12:15] <ogra_> (and your config shoul point to that dir)
[12:19] <mup> PR snapcraft#686 opened: Add missing dependencies <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/686>
[12:27] <Cavan> ogra_, so like this? export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances"
[12:27] <ogra_> yeah
[12:28] <Cavan> ogra_, anychance you could check out my stack overflow quickly if I link it?
[12:29] <ogra_> sure, just paste it on paste.ubuntu.com
[12:30] <Cavan> ogra_, thanks http://paste.ubuntu.com/20997635/
[12:31] <Cavan> ogra_, it hasnt been updated since you told me thye should both have SNAP_USER_DATA, so assume they're there
[12:31] <ogra_> heh
[12:31] <ogra_> i thoght you had a stak to look at, sorry
[12:32] <ogra_> that wouldnt have needed a pastebin :)
[12:32] <Cavan> Ah right aha, also I just noticed my wrapper is more up to date than that now 'set -e set -x  export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH exec "$SNAP/bin/karaf" "$@"'
[12:32] <mup> PR snapd#1587 opened: store: deal with 404 froms the SSO store properly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1587>
[12:34] <ogra_> Cavan, have a look at https://github.com/ogra1/jtiledownloader
[12:34] <ogra_> that ships a wrapper script
[12:35] <ogra_> (though this executes a jar )
[12:36] <ogra_> so far your wrapper looks ok though
[12:36] <ogra_> so what happens if you try to run it ?
[12:42] <ogra_> zyga, uuuh, is the base snap still public in the store ? can you please unpublish it ?
[12:42] <Cavan> ogra_, basically when I try to run the ./karaf I get
[12:42] <Cavan> mkdir: cannot create directory ‘/snap/karaf/x18/data/log’: Read-only file system WARN: can't update etc/config.properties with the generated command shutdown. We advise to manually add the karaf.shutdown.command property. Unable to update instance pid: Unable to create directory /snap/karaf/x18/instances /snap/karaf/x18/data/log/karaf.log (No such file or directory) Unable to update instance pid: Unable to create directory /snap/kar
[12:43] <ogra_> when you run ./karaf ?
[12:43] <ogra_> you mean you execute something inside $SNAP manually ?
[12:43] <ogra_> that cant work
[12:44] <ogra_> you need to use /snap/bin/karaf ... or just karaf ... (since /snap/bin should be in your PATH(
[12:44] <Cavan> I go into the /bin and execute karaf? I thought you had to boot it the normal way after the snap is installed, in the directory of course
[12:44] <ogra_> else you miss one layer of wrappers
[12:45] <ogra_> well, try /snap/bin/karaf ... see what that does
[12:45] <mup> PR snapd#1579 closed: snapstate: add daemon-reload to fix autopkgtest on yakkety <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1579>
[12:46] <Cavan> ogra_, I get the same result
[12:54] <ogra_> Cavan, well, the mkdir errors look like your wrapper has not been updated
[12:55] <ogra_> the mkdir seems to still point to the wrong dir
[12:56] <ogra_> Cavan, are you use the karaf binary actually uses these $KARAF_* vars at all ?
[12:57] <ogra_> or does it just try to write to ./ by default
[12:57] <ogra_> then you would need to add a "cd $SNAP_USER_DATA" to your wrapper before the exec line
[12:58] <Cavan> ogra_, If i go into the bin folder there is a setenv file which has the '# export EXTRA_JAVA_OPTS # Additional JVM options # export KARAF_HOME # Karaf home folder # export KARAF_DATA # Karaf data folder # export KARAF_BASE # Karaf base folder # export KARAF_ETC  # Karaf etc  folder' so I assumed thye would be the binaries?
[12:59] <ogra_> well, the binary doesnt seem to use the vars ...
[12:59] <ogra_> try the cd ... that might work around it
[13:00] <Cavan> ogra_, Okay, do I literally put it the line before the exec?
[13:00] <ogra_> a line above the exec line, yes
[13:06] <Cavan> ogra_, again same result. But for a test I ran the wrapper in /bin and I got '+ export KARAF_DATA= + export KARAF_HOME= + mkdir -p /data/logs mkdir: cannot create directory ‘/data’: Permission denied' If that is any help?
[13:07] <ogra_> well, that is if you execute /snap/bin/karaf ?
[13:07] <ogra_> (literally that string)
[13:07] <Cavan> No, thats if I execute /snap/bin/wrapper
[13:07] <ogra_> uh
[13:07] <ogra_> dont
[13:08] <ogra_> and how did wrapper get into /snap/bin ?
[13:08] <ogra_> your wrapper should live inside your snap ... not in the /snap/bin system dir of your host system
[13:09] <Cavan> When I've looked at online examples a few have created wrappers in the /bin, is that incorrect?
[13:09] <ogra_> as i said before, when you install the snap there are more layers of wrappers added automatically
[13:09] <ogra_> the top level wrapper (according to your snapcraft.yaml) will be /snap/bin/karaf
[13:10] <ogra_> and only that is what you should ever execute
[13:10] <mup> PR snapd#1582 closed: debian: move snapd.refresh.timer into timers.target <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1582>
[13:10] <ogra_> do not exec anything in /snap/karaf/$version/ directly
[13:10] <ogra_> that can not work
[13:12] <Cavan> So where should I install the wrapper? Also to atempty to run karaf I go /snap/karaf/current/bin/karaf Should I not be doing that aswell?
[13:12] <ogra_> you should install the wrapper where your snapcraft.yaml expects it
[13:13] <ogra_> looking at your stackoverflow post it is all correct
[13:13] <ogra_> just leave it like that
[13:13] <ogra_> just dont try to runanything else but /snap/bin/karaf
[13:14] <Cavan> If I do that I get this though '/snap/bin/karaf: No such file or directory'
[13:15] <ogra_> that cant really be ... your snapcraft.yaml defines it
[13:15] <ogra_> if you built your snap with that snapcraft yaml and snap installed it this commmand must be there
[13:16] <Cavan> i'll install it again to make sure
[13:16] <ogra_> oh
[13:16] <ogra_> wait !
[13:16] <Cavan> Okay
[13:16] <ogra_> why do you define "daemon: simple"
[13:16] <ogra_> thats for system daemons ... and will definitely not create the user binary in /snap/bin
[13:16] <Cavan> What should I do instead?
[13:16] <ogra_> but will instead create a systemd unit and install it
[13:17] <ogra_> just drop that one line
[13:17] <ogra_> and rebuild your snap
[13:17] <ogra_> (unless indeed ... your app is actually a system daemon)
[13:17] <ogra_> (but then you cant start it ... systemd will handle it)
[13:17] <ogra_> s/start/run it as a user/
[13:18] <Cavan> So I'm re-installing it back to my Stackoverflow post and dropping that one line correct?
[13:18] <ogra_> yes
[13:19] <ogra_> if karaf is actually something a user can run then thats the right way
[13:32] <Cavan> ogra_, okay now I'm getting 'Error: Could not find or load main class org.apache.karaf.main.Main' when typing /snap/bin/karaf
[13:32] <ogra_> you might need to set some app options then ...
[13:33] <ogra_> you said something about EXTRA_JAVA_OPTS  above
[13:33] <mup> Bug #1606574 opened: SSH Interface is missing <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606574>
[13:33] <ogra_> so whatever java needs (i'm really not a java specialist, i know how to make it exec a .jar ... thats about it)
[13:34] <Cavan> should I get the MakeFile to install the .jar?
[13:34] <ogra_> well, if you have a jar, just look at my jtiledownloader branch (linked above)
[13:34] <ogra_> that should get you going
[13:35] <Cavan> ogra_, thanks so much for your help, although you'll probably be hearing from me soon with another problem aha
[13:36] <ogra_> heh, well, good luck for now
[13:40] <Chipaca> jdstrand: on #1592696 I think you meant 16.04 not 14.04 :-)
[13:40] <mup> Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Invalid> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu Xenial):Confirmed> <ubuntu-core-launcher (Ubuntu
[13:40] <mup> Xenial):Incomplete> <https://launchpad.net/bugs/1592696>
[13:41] <timothy> I think it's fixed on new snap-confine
[13:42] <Chipaca> timothy: so do i :-) and jdstrand says as much in his latest update to that bug; i'm pointing out a typo in that comment, is all
[13:44] <mup> PR snapd#1585 closed: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1585>
[13:52] <ogra_> hmm
[13:53] <ogra_> so how do i access any packages owned by the shared store account now that it is locked
[13:53] <ogra_> i know all packages were shared with me ...
[13:53] <ogra_> but i dont see them in my myapps.d.u.c page
[14:00] <zyga> ogra_: I cannot, I didn't publish it
[14:00] <ogra_> zyga, crap ... and i cant see it and the shared account is locked down
[14:01] <ogra_> zyga, is mvo anywhere near you ? he might know
[14:05] <zyga> ogra_: I bet he did it
[14:05] <ogra_> did what ? unpublish ?
[14:05] <ogra_> i still find it with snap find
[14:05] <Pharaoh_Atem> morning all
[14:06] <ogra_> zyga, i'm happy to do the unpublishing if someone tells me how we access the shared packages now ... we all should be able to since heidelberg
[14:06] <ogra_> but my myapps page simply doesnt show it
[14:09] <mup> PR snapd#1588 opened: tests: added spread find private test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1588>
[14:09] <mup> Bug #1605003 changed: cannot communicate with server - openSUSE Tumbleweed <Snappy:Invalid by zyga> <openSUSE:Confirmed for zyga> <https://launchpad.net/bugs/1605003>
[14:10] <jdstrand> Chipaca: yes, thanks
[14:12] <zyga> ogra_: I'm sorry, I don't know that; I never used the shared account
[14:12] <ogra_> zyga, well ...
[14:12] <zyga> jdstrand: hey, we will need to have snapd manage groups and users
[14:12] <zyga> jdstrand: for the case of lxd
[14:13] <zyga> jdstrand: so that ldx snap will be able to create the ldx socket that is not world writable
[14:13] <zyga> jdstrand: I'm just letting you know
[14:14]  * ogra_ vomits
[14:14] <ogra_> so mvo tied all the shared packages to<EMAIL_ADDRESS>... which is not assigned to my U1 account at all
[14:15] <Pharaoh_Atem> O.o
[14:15] <ogra_> trying to add the new address to U1 while being in a unity8 session breaks because launchpad is to dumb to show me the capcha !!!
[14:16] <ogra_> (it considers the webbrowser appp as not capable to use captchas ... sigh)
[14:16] <ogra_> so silly
[14:19]  * Pharaoh_Atem sighs
[14:20] <Pharaoh_Atem> zyga: looks like F25 branching is starting
[14:20] <Pharaoh_Atem> you accidentally don't have F25 commit power: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-mvo5-goconfigparser/
[14:21]  * Pharaoh_Atem sighs
[14:21] <Pharaoh_Atem> time to prepare for messages about my entire world branching for F25...
[14:24] <chile> hi snappers
[14:25] <Cavan> orga_, How would I extract org.apache.karaf.main-4.0.5.jar fromthe make file, when I try it just places the file instead of extracting it
[14:25] <sergiusens> ogra_ heh, oSoMoN has a bug for that already
[14:26] <ogra_> great
[14:27] <ogra_> hmpf ... so i see a "core" package that was shared with all of us ... but there is no "base" package anywhere
[14:27] <ogra_> and that core package is also unpublished properly
[14:28] <ogra_> MVOOOOO !!!
[14:29] <ogra_> Cavan, well, you dont want to extract it ... look at my jtiledownloader snap
[14:29] <ogra_> (i gave you the github url above)
[14:29] <ogra_> just copy the exec line and replace my jar with yours in there
[14:31] <jdstrand> zyga: I saw that. note that in 15.04 what we did instead as a quick workaround was to add the lxd group to the system
[14:31] <jdstrand> zyga: tyhicks and I should be involved in the designs surrounding adding groups to the system via snaps
[14:31] <ogra_> uh
[14:32] <jdstrand> zyga: and possibly a memnber of foundations (slangasek or someone he assigns)
[14:32] <ogra_> adding system groups sounds slightly scary with libnss-extrausers in place and using a readonly /etc/groups
[14:33] <ogra_> (how do you make sure the GID doesnt clash if somme package added the same GID to the readonly side at core snap build time)
[14:34] <ogra_> (it would just come with the next oos snap update)
[14:34] <ogra_> *os
[14:34] <jdstrand> it indeed sounds scary since it would be easy for a snap to pick a group to add (eg, 'ogra')
[14:34] <ogra_> well, not only that
[14:34] <ogra_> you dont know what comes down the drain from the store
[14:34] <jdstrand> so maybe it wouldn't be arbitrary groups, but rather, the snappy interface says (ok, we'll set up this group)
[14:34] <ogra_> so you cant really predict if a GID will clash
[14:34] <Pharaoh_Atem> ogra_: mvo isn't even here, so he can't really hear you.... :/
[14:35] <ogra_> Pharaoh_Atem, there are enough people at his sprint ... i guess he is stuck in some session ;)
[14:35]  * Pharaoh_Atem shrugs
[14:35]  * ogra_ relies on mouth propaganda with that one ;)
[14:36] <chile> any body
[14:36] <chile> with some idea on native apps in jquery+php+html experience
[14:37] <ogra_> jdstrand, well, i guess we'd need to define some range that cant get touched by image builds ... iirc we already define that system groups have to be below 1000 ... so we'd need a range ... say 1000-2000 that gets reserved for extra groups ... and make sure that user accounts only get created from 2000 onwards ... or something like that
[14:38] <ogra_> but thats fiddly to implement for sure
[14:45] <chile> any body with ubuntu cloud here
[14:58] <zyga> Pharaoh_Atem: hey
[14:58] <zyga> Pharaoh_Atem: why do you have two IRC nicknames
[14:58] <Pharaoh_Atem> zyga: yo
[14:58] <Pharaoh_Atem> this self is my workstation at work
[14:58] <Pharaoh_Atem> my other self (Son_Goku) is my laptop
[14:58] <zyga> Pharaoh_Atem: I've updated the snap-confine.spec
[14:59] <zyga> Pharaoh_Atem: pushed updates to fedorapeople
[14:59] <Pharaoh_Atem> this guy is persistent, the other one shows up when I'm away :)
[14:59] <zyga> Pharaoh_Atem: magic :)
[14:59] <zyga> Pharaoh_Atem: should I just indicate the changes on the bug report?
[14:59] <Pharaoh_Atem> yes
[14:59] <Pharaoh_Atem> always do that, as it's for the benefit of me, you, and others potentially watching
[14:59] <zyga> Pharaoh_Atem: you can also check what I did by looking at github (for all the real details)
[14:59] <zyga> ok, will do
[14:59] <Pharaoh_Atem> right
[15:05] <zyga> Pharaoh_Atem: I could use a hint that tells me how to do a fedkpg build against something from koji (the gopkg.in/check.v1 thing)
[15:07] <Pharaoh_Atem> you need to create the buildroot override
[15:07] <Pharaoh_Atem> https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages
[15:07] <Pharaoh_Atem> it would automatically be in effect for builds you do from your user with koji (via fedpkg)
[15:08] <Pharaoh_Atem> you should be able to build from F25 and Rawhide with no problems, though
[15:08] <Pharaoh_Atem> since both will have check in there already
[15:10] <elopio> stevebiscuit: why don't you ship your patched go plugin in snapweb in parts/plugin/x-go.py ?
[15:10] <elopio> that way we don't have to wait for a new release.
[15:12] <Pharaoh_Atem> zyga: I've approved snap-confine
[15:13] <zyga> Pharaoh_Atem: I'll do the change to the remaining two pkgconfig files
[15:13] <zyga> Pharaoh_Atem: I'm somewhat exhausted by the sprint and I'm very glad and I very much appreciate your detailed review
[15:14] <stevebiscuit> elopio: that's an option, I'd already mentioned godeps to kyrofa and he created the bug on LP
[15:17] <Pharaoh_Atem> zyga: that's why we do these in Fedora :)
[15:17] <Pharaoh_Atem> one more set of eyes tends to help at times
[15:18] <zyga> Pharaoh_Atem: I hope to get more so that we can have a day off sometime ;)
[15:22] <zyga> Pharaoh_Atem: I'll work on fedpkg builds now
[15:22] <zyga> Pharaoh_Atem: but it does look like we are down to snapd now :)
[15:22] <zyga> Pharaoh_Atem: I didn't check go-flags yet, is the update also going to f23+?
[15:22] <Pharaoh_Atem> yes
[15:22] <Pharaoh_Atem> it's going everywhere
[15:22] <zyga> that's good then
[15:23] <zyga> We had a release just now, 2.11 :)
[15:23] <Pharaoh_Atem> zyga: https://bodhi.fedoraproject.org/updates/?packages=golang-github-jessevdk-go-flags
[15:23] <zyga> I'll do COPR but I'm super happy I will be moving closer to fedora :)
[15:23] <Pharaoh_Atem> you can try out those packages and see if they work
[15:23] <zyga> Pharaoh_Atem: nice, I see
[15:23] <Pharaoh_Atem> and leave feedback :)
[15:23] <zyga> Pharaoh_Atem: yes, I will download them
[15:23] <zyga> Pharaoh_Atem: is there a better way rather than just to get them from bodhi?
[15:24] <zyga> Pharaoh_Atem: I will build against it in my local repo
[15:24] <Pharaoh_Atem> http://koji.fedoraproject.org/koji/packageinfo?packageID=20509
[15:25] <Pharaoh_Atem> you grab them from Koji
[15:25] <Pharaoh_Atem> looks like an override is already in place for go-flags
[15:25] <Pharaoh_Atem> it might "Just Work"
[15:25]  * Pharaoh_Atem shrugs
[15:34] <ahoneybun> tsimonq2, heard of KDE Connect?
[15:34] <tsimonq2> ahoneybun: no clue what it is
[15:35] <ahoneybun> you can send and recieve files between phone and PC
[15:35] <ahoneybun> also control mouse and keyboard
[15:35] <ahoneybun> it pulls a lot in from KDE in Libs
[15:35] <ahoneybun> so it would be cool to snap it
[15:45] <Cavan> ogra, I did exec $SNAP/org.apache.karaf.main-4.0.5.jar (Which I'm hoping is what you meant before) and I keep getting '/snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: 1: /snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: Syntax error: word unexpected (expecting ")")''  '
[15:46] <qengho> ogra_: WAT
[15:48] <qengho> I mean, not ogra_.
[15:48] <qengho> Cavan: That is very very wrong.
[15:49] <Cavan> qengho, which part, the exec?
[15:49] <Cavan> or the return im getting from the terminal?
[15:49] <qengho> Cavan: A jar file is a kind of zipfile that is specific to Java. You can't ask the linux kernel to just execute it. It's not a java virtual machine.
[15:49] <qengho> Cavan: So, "exec jarfile" is wrong.
[15:51] <qengho> Cavan: you probably want to read up on what to do with the jarfile, and how one runs karaf. It's joing to have something to do with the program "java", though.
[15:53] <Cavan> qengho, Yeah I figured, I'm trying to figure out where its meant to go, ogra gave me fantasic advice earlier but im to terrible at this to figure it out aha
[15:55] <qengho> Cavan: I am guessing you should have in your snapcraft "command: wrappernamesomethingyouinvented", and in your wrapper, a shell script, you set up some variables and execute  java -Dhomesomethingsomething -classpath $SNAP/something jarfilesomething classnametobootstrap
[15:57] <qengho> Cavan: stop with the snap part for a while. Figure out how you run that. Once you have a firm grasp how it NORMALLY starts up, come put those commands in a snap.
[15:57] <mup> PR snapd#1581 closed: asserts: remove/disable comma separated lists and their uses <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1581>
[15:58] <qengho> Cavan: You only have problems that have nothing to do with snappy so far. We're going to be terrible at answering those. :(
[15:59] <Cavan> qengho, ah thats fair enough, I'll give it a good go aha, thanks!
[16:01] <qengho> Cavan: We'd love to help. Don't be shy about questions, but realize I have never even heard of karaf before your questions.
[16:02]  * qengho Zzzz
[16:08] <ogra_> Cavan, https://github.com/ubuntu/snappy-playpen/blob/master/jtiledownloader/launcher
[16:08] <ogra_> Cavan, see the last line
[16:08] <ogra_> you want that
[16:08] <ogra_> (indeed with a path to *your* .jar
[16:08] <ogra_> )
[16:14] <zyga> Pharaoh_Atem: so what is the "there might be more..." comment about
[16:14] <zyga> Pharaoh_Atem: is there anything I should fix in snap-confine packaging?
[16:14] <Pharaoh_Atem> forgot to run fedora-review
[16:14] <Pharaoh_Atem> it has a checklist of things
[16:14] <zyga> oh, I will do it
[16:14] <zyga> thank you
[16:21] <zyga> Pharaoh_Atem: I must say fedora-review -n seems to assume SRPMs are in ~/rpmbuild/SPECS which is odd, I'll try it with the bug number
[16:24] <Pharaoh_Atem> zyga: I have to run it, and I posted the results in the bug
[16:24] <Pharaoh_Atem> though it's useful for you to do while crafting the spec
[16:26] <zyga> Pharaoh_Atem: I have a call now, I'll review it after that
[16:27] <Pharaoh_Atem> okay
[16:28] <zyga> I just saw the report, very useful!
[16:35] <Pharaoh_Atem> zyga: yeah, unfortunately I can't run it for golang stuff because it throws too many errors to be useful
[16:35] <Pharaoh_Atem> but it's a good blueprint regardless
[16:36] <Pharaoh_Atem> we make too many exceptions for golang that we do reviews for those differently
[16:43] <kyrofa> elopio, stevebiscuit indeed, sorry for moving slowly on the godeps plugin. I actually have one locally, but I need to clean it up and push. There were some things that needed to happen before then, but Fridays are my only snapcraft days currently so things take a sad amount of time
[17:10] <stevebiscuit> kyrofa, elopio: grand, I'll remind you about it during Friday's standup ;)
[17:26] <wililupy> Are there plans to have a docker snap?
[18:17] <mhall119> zyga: how do give a snap access to certain hardware?
[18:17] <mhall119> I'm getting Log: apparmor="ALLOWED" operation="open" profile="snap.arduino.arduino" name="/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial" pid=18376 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[18:17] <mhall119> File: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial (read)
[18:17] <mhall119> Suggestion:
[18:17] <mhall119> * use gadget hardware assign to access '/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial'
[18:18] <mhall119> also in the arduino IDE: can't open device "/dev/ttyACM0"; Permission denied
[18:31] <ahoneybun> mm I'm wondering about getting code from git
[18:33] <ahoneybun> mhall119, I'm thinking about making a snap on KDEConnect
[18:47] <jdstrand> mhall119: I think you want to use the serial-port interface
[18:47] <jdstrand> mhall119: you might be the first user of that interface so please file 'snapd-interface' bugs if you see them
[18:50] <Dubstar_04> Is there anynew on a fix for running OpenGL snaps on Nvidia systems?
[18:50] <Dubstar_04> *news
[19:05] <timothy> Dubstar_04: for example? on which distro? with nvidia or nouveau?
[19:07] <Dubstar_04> timothy: I'm on 16.04, snaps work with nouveau but no with Nvidia.
[19:07] <Dubstar_04> this is the output: http://paste.ubuntu.com/21041858/
[19:08] <timothy> using the snap-confine from proposed worked to me
[19:13] <ahoneybun> mm franz does not want to launch as a snap
[19:13] <ahoneybun> tsimonq2, ^
[19:13] <Croepha> so, on the ubuntu site, it says that Snappy uses delta's to reduce bandwidth, how does that work? like does it use vcdiff? does the server have all the diffs handy?
[19:16] <timothy> iirc it's need to be re-added
[19:17] <Croepha> timothy, the functionality was there, but isn't now
[19:17] <Croepha> ?
[19:17] <timothy> Croepha: http://askubuntu.com/a/789634
[19:19] <Croepha> timothy: thanks
[19:19] <Dubstar_04> timothy: i have installed that. now I am getting: multiple nvidia drivers detected, this is not supported
[19:20] <timothy> maybe you have multiple nvidia drivers installed?
[19:21] <Dubstar_04> Umm, I have been switching between nouveau and nvidia while testing snaps. maybe something got messed up.
[19:22] <ahoneybun> let's try this again
[19:23] <mhall119> jdstrand: is serial-port interface in snapd on xenial?
[19:24] <mhall119> because I don't see it in `snap interfaces`
[19:27] <jdstrand> mhall119: it is and has been for a long time. I'm not sure why it doesn't show up. that may be one of the bugs (it was implemented a very long time ago)
[19:28] <Croepha> if I deployed with 16/rolling/edge would there be a clear upgrade path once 16 comes out as stable? without having to reflash?
[19:28] <mhall119> jdstrand: where do I file bugs for it? has that moved to github too?
[19:29] <jdstrand> bugs are still LP
[19:29] <mhall119> jdstrand: lp:snappy ?
[19:29] <jdstrand> https://bugs.launchpad.net/snappy/+filebug
[19:29] <ahoneybun> could anyone look at these errors http://pastebin.ubuntu.com/21044760/
[19:29] <jdstrand> add the 'snapd-interface' tag
[19:30] <ahoneybun> it's complaining about gtk but I have desktop gtk in the yaml
[19:30] <Dubstar_04> timothy: I only have one nvidia driver installed
[19:30] <ahoneybun> yaml: http://pastebin.ubuntu.com/21044876/
[19:32] <jdstrand> mhall119: a super-cursory reading of the test code indicates that slot implementation should define the serial ports and then you would plugs what it exports. that doesn't sound like it will do what you are looking for since classic and the os snap don't do any of that atm
[19:33] <jdstrand> s/test code/serial_port*.go code/
[19:33] <jdstrand> I think this was implemented thinking a gadget snap would 'slots: ...' and then snaps would plug into that
[19:33] <jdstrand> (which would make sense)
[19:34] <jdstrand> and/or the os/core snap would auto-detect these ports and supply implied slots
[19:34] <jdstrand> (which would also make sense)
[19:35] <jdstrand> but that today, there is no gadget snap on classic and snapd is not detecting the serial ports to provide an implied slot
[19:35] <jdstrand> I *think* the hooks work may in part be for this sort of thing, but would need zyga to confirm
[19:35] <mup> Bug #1606674 opened: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
[19:36] <mhall119> jdstrand: https://bugs.launchpad.net/snappy/+bug/1606674
[19:36] <mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
[19:36] <jdstrand> I see that, thanks
[19:37] <jdstrand> zyga, can you take a look at bug #1606674 when you have a moment?
[19:37] <mhall119> otherwise my arduino IDE snap is fully functional
[19:37] <mhall119> with the exception of being able to, you know. function :)
[19:38] <jdstrand> that interface is absolutely what you should be using
[19:39] <timothy> mhall119: I think you can access /dev/ttyACM0 without using snap :P
[19:39] <jdstrand> but I think the implementation hasn't been revisited since classic was a focus and other things got prioritized over the gadget/all snaps finishing touches
[19:39] <jdstrand> timothy: well, he can also use --devmode
[19:40] <timothy> "However, it is unable to access the board, even in devmode."
[19:40] <jdstrand> ah, I didn't read the bug yet. that is weird
[19:41] <jdstrand> mhall119: what are the permissions on /dev/ttyACM0 ?
[19:42] <jdstrand> mhall119: I suspect devmode isn't working right cause of that. /dev is listed as a source mount in snap-confine, so that shouldn't be it (are you using snap-confine from proposed?)
[19:44] <jdstrand> mhall119: is the output the same regardless of if you are in devmode or not or is the output different? if different, you should list that in the bug. I suspect there are two different bugs
[19:44] <timothy> mhall119: can you do an ls /dev/ttyACM0? maybe it's using some acl, that you can see with getfacl /dev/ttyACM0
[19:45] <timothy> ls -l*
[19:47] <mhall119> jdstrand: from within the snap, or normally?
[19:47] <mhall119> crw-rw---- 1 root dialout 166, 0 Jul 26 14:15 /dev/ttyACM0
[19:47] <mhall119> oh, hangon, I seem to recall needing to make my user part of the dialout group to use the arduino ide
[19:48] <timothy> yes, you need dialout group
[19:48] <timothy> sudo gpasswd -a $USER dialout
[19:49] <jdstrand> right
[19:49] <jdstrand> so that should make it work in devmode
[19:49] <timothy> yep
[19:49] <jdstrand> (please comment in the bug if it does)
[19:49] <timothy> ofc you need to reload or to do su - $USER
[19:56] <mhall119> sure enough, getting into the dialout group lets it work in --devmode
[19:56] <ahoneybun> tsimonq2, did you see the links?
[19:57] <tsimonq2> ahoneybun: what links?
[19:57] <ahoneybun> I'm trying to work on Franz snap anyway
[19:57] <ahoneybun> getting some gtk errors when running it
[19:59] <mup> Bug #1574114 opened: snapd should not conflic with mediaplayer snappy <amd64> <apport-bug> <xenial> <One Hundred Papercuts:Confirmed for mvo> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed for mvo> <https://launchpad.net/bugs/1574114>
[20:00] <ahoneybun> this darn connection today is back
[20:01] <timothy> let's try apparmor with confinement on archlinux with nvidia drivers :)
[20:01] <timothy> s/apparmor/snap/
[20:02] <Dubstar_04> Anyone using snappy with Nvidia cards?
[20:03] <Dubstar_04> I have purged all nvidia drivers and I still get this message: http://paste.ubuntu.com/21048959/
[20:03] <timothy> Dubstar_04:
[20:03] <timothy> ls /usr/lib/nvidia-[1-9][0-9][0-9]
[20:04] <Dubstar_04> timothy: how do i remove those?
[20:05] <timothy> did you installed those by installing the driver by hand?
[20:05] <Dubstar_04> http://paste.ubuntu.com/21049367/
[20:06] <Dubstar_04> I have only ever installed through ubuntu drivers, I think
[20:06] <Dubstar_04> can i just rm -rf /usr/lib/nvidia*
[20:07] <timothy> dpkg -S /usr/lib/nvidia-346/libnvidia-fbc.so.1
[20:07] <dz0ny> Dubstar_04: purge will not help since it rewrites gl load paths
[20:08] <Dubstar_04> Its working!!!
[20:08] <Dubstar_04> timothy: thanks!!
[20:08] <Dubstar_04> My snap works at last!!
[20:08] <timothy> you're welcome, you are like I studied snap-confine last week :P
[20:08] <timothy> lucky*
[20:08] <ahoneybun> Dubstar_04, I have NVIDIA but it's using the Intel atm
[20:09] <ahoneybun> I'm just trying snaps today
[20:09] <ahoneybun> first time working with snapcraft lol
[20:09] <Dubstar_04> I might try and reboot and reinstall nvidia drivers before i get too excited...
[20:10] <ahoneybun> I have Intel and NVIDIA
[20:10] <ahoneybun> but I have not install the driver for the Nivida
[20:10] <mup> PR snapd#1589 opened: interfaces: miscelleneous policy updates for default, mount-observe, opengl and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1589>
[20:12] <Dubstar_04> Are there snap channels, like alpha, beta, stable?
[20:14] <timothy> http://snapcraft.io/ search for channels
[20:15] <Dubstar_04> timothy: perfect, thanks.
[20:18] <timothy> Dubstar_04: works?
[20:18] <Dubstar_04> I switched back to Nvidia drivers and i'm still getting the opengl errors
[20:18] <Dubstar_04> :(
[20:21] <timothy> sorry I have to go
[20:58] <mhall119> sergiusens: you around?
[21:14] <mup> PR snapcraft#687 opened: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
[21:23] <mup> PR snapcraft#688 opened: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
[21:29] <ahoneybun> wonders
[21:39] <mup> PR snapd#1590 opened: interfaces: add process-control interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1590>
[23:17] <thurston> I'm getting this error in my Snap package:
[23:17] <thurston> X Error: BadValue
[23:17] <thurston> Request Major code 154 (GLX)
[23:17] <thurston> Request Minor code 3 ()
[23:17] <thurston> Value 0x0
[23:17] <thurston> Error Serial #23
[23:17] <thurston> Current Serial #24
[23:22] <thurston> any help?


[02:51] <Eickmeyer> All missing flavor newsfeeds have been re-added to Planet Ubuntu.
[02:59] <guiverc> :)  thanks (again) Eickmeyer
[02:59] <Eickmeyer> :) guiverc
[03:40] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Restricted unprivileged user namespaces are coming to Ubuntu 23.10 @ https://ubuntu.com//blog/ubuntu-23-10-restricted-unprivileged-user-namespaces
[03:40] -ubottu:#ubuntu-news- ::planet:: Alan Pope: Boot to BBC BASIC: Agon Edition @ https://popey.com/blog/2023/10/boot-to-bbc-basic-agon-edition/
[03:40] -ubottu:#ubuntu-news- ::planet:: Stéphane Graber: Releasing Incus 0.1 @ https://stgraber.org/2023/10/09/releasing-incus-0-1/
[03:40] -ubottu:#ubuntu-news- ::planet:: The Fridge: Ubuntu Weekly Newsletter Issue 808 @ https://fridge.ubuntu.com/2023/10/09/ubuntu-weekly-newsletter-issue-808/
[05:12] -ubottu:#ubuntu-news- ::planet:: Kubuntu General News: Ubuntu 22.10 (Kinetic Kudu) End of Life reached on July 20, 2023 @ https://kubuntu.org/news/ubuntu-22-10-kinetic-kudu-end-of-life-reached-on-july-20-2023/
[05:12] -ubottu:#ubuntu-news- ::planet:: Lubuntu Blog: Lubuntu 22.04 Backports PPA Released With LXQt 1.3 @ https://lubuntu.me/jammy-backports-22-04-3-lxqt-1-3/
[05:12] -ubottu:#ubuntu-news- ::planet:: Ubuntu Studio: A Message from the Project Lead @ https://ubuntustudio.org/2023/09/a-message-from-the-project-lead/
[05:12] -ubottu:#ubuntu-news- ::planet:: Lubuntu Blog: Lubuntu 23.10 (beta) Released! @ https://lubuntu.me/mantic-released/
[05:12] -ubottu:#ubuntu-news- ::planet:: Ubuntu Studio: Ubuntu Studio 23.10 Beta Released @ https://ubuntustudio.org/2023/09/ubuntu-studio-23-10-beta-released/
[05:12] -ubottu:#ubuntu-news- ::planet:: Ubuntu MATE: Ubuntu MATE 23.10 Release Notes @ https://ubuntu-mate.org/blog/ubuntu-mate-mantic-minotaur-release-notes/
[07:35] -ubottu:#ubuntu-news- ::fridge:: Ubuntu Weekly Newsletter Issue 808 @ https://fridge.ubuntu.com/2023/10/09/ubuntu-weekly-newsletter-issue-808/
[15:05] <Eickmeyer> Wow, look at all those feeds coming through finally.


[02:18] <rhpot1991> Just pushed out the hdhomerun gui/config/library to the testing ppa, if anyone wants to kick them around let me know how they work out.  I'll be around later to work on them some more.
[02:37] <mazda01> can anyone help me figure out mythbuntu X11 server issues after an upgrade. I can't see the start menu (if I can call it that)
[02:48] <Technophil> rhpot1991:  Does that have anything to do with http://svn.mythtv.org/trac/ticket/7624 ?
[02:48] <rhpot1991> Technophil: nope, its the configuration utility.  http://www.silicondust.com/downloads/linux
[02:57] <Technophil>  rhpot1991: Sorry I don't think I can do that for you.
[03:08] <gotmilk82> I am having trouble with my machine and the latest kernel updates.  Dell says that it can be fixed with a bios update....no linux updater....only windows.   So I tried to create a bootable USB pen drive with wintoflash and that worked great but wanted to install win 7....I just want to install the BIOS update and be done with it...any ideas?
[03:10] <gotmilk82> I could never get it to get into anything that resembled dos and I could not find a way to start the DELLBIOSUPDATER.exe instead of the setup.exe they had.  I changed the autoblah, but no dice :(
[03:14] <tgm4883> gotmilk82, uh, how is that related to mythtv?
[03:14] <gotmilk82> its not, but it is related to ubuntu-mythtv
[03:15] <gotmilk82> ;)
[03:16] <tgm4883> gotmilk82, well, being that this is the primary support channel for Mythbuntu, I don't think so
[03:16] <tgm4883> you are probably looking for #ubuntu
[03:19] <gotmilk82>   I could never get it to get into anything that resembled dos and I could not find a way to start the DELLBIOSUPDATER.exe instead of the setup.exe they had. I changed the autoblah, but no dice :(I am having trouble with my machine and the latest kernel updates. Dell says that it can be fixed with a bios update....no linux updater....only windows. So I tried to create a bootable USB pen...
[03:19] <gotmilk82> ...drive with wintoflash and that worked great but wanted to install win 7....I just want to install the BIOS update and be done with it...any ideas?
[03:20] <iamlindoro> think he did those two things out of order
[03:20] <tgm4883> heh, yea I think so
[03:25] <tim-> anyone have a recommendation for a screen issue.. mythbuntu 9.10 box with an nvidia 9300 plugged into a 42" lcd.. the sides and top/bottom of the screen are all missing
[03:26] <tgm4883> tim-, screen wizard?
[03:26] <tim-> tgm4883: not familiar with that? what is it? i went through the nvidia-settings config
[03:27] <tgm4883> tim-, that would be in the mythtv frontend
[04:51] <bllz> Does anybody know how I can solve the opengl painter issue whereby my forntend menu fades to black after a few seconds?  I rather like the opengl effects, so if there's a fix, i'd like to use it
[04:51] <bllz> it's strange because I definitely see a functional menu for a few seconds before it fades
[04:58] <tgm4883> bllz, I didn't know there was an opengl issue about that. Fading to black sounds more like screensaver
[04:59] <bllz> tgm4883:  well it's triggered only on the frontend... and only when I have opengl painting enabled
[04:59] <bllz> and it happens within about 5 seconds
[04:59] <bllz> once it's faded to black hitting buttons does nothing, unless I hit stop enough times to bring up the prompt to quit the frontend
[05:00] <tgm4883> bllz, odd
[05:00] <tgm4883> never heard of it, sorry. I'm doing some video editing for the wifey or i'd help you. Do the logs say anything?
[05:00] <bllz> tgm4883:  haha no problem =)
[05:01] <bllz> tgm4883:  hmm good point, I should probably check those
[05:01] <bllz> mind if I pastebin them for you?
[05:01] <tgm4883> go ahead
[05:01] <tgm4883> I don't guarentee when I can look
[05:01] <bllz> tgm4883:  oh yeah I totally understand.  ok let me do that...
[05:22] <edizzle> Have an ssh problem I upgraded to 9.10 and now sshd does not work. I uninstalled and now cannot get installed:Errors were encountered while processing:
[05:22] <edizzle> :  /var/cache/apt/archives/openssh-client_1%3a5.1p1-6ubuntu2_i386.deb
[05:22] <edizzle> /var/cache/apt/archives/openssh-server_1%3a5.1p1-6ubuntu2_i386.deb
[05:22] <edizzle>  E: Sub-process /usr/bin/dpkg returned an error code (1)
[05:22] <edizzle> i tried clearing cache and other things i googled, but no luck so far. any one have ideas or same issue?
[05:26] <bllz> edizzle:  try #ubuntu
[05:26] <edizzle> bliz: what is difference?
[05:27] <bllz> edizzle:  more people, and it doesn't sound like you have a myhtbuntu-specific problem
[05:28] <edizzle> bliz: ok
[05:33] <edizzle> anyone is welcome to help if they would like :)
[06:07] <tralph> I just installed Mythbuntu 9.10 and was wondering what the root password is for mysql
[06:07] <tralph> it never prompted me, that I recall, during the installation process
[06:08] <tgm4883> tralph, should be the same as your main user
[06:09] <tralph> let me try that again
[06:10] <tralph> ran mysql -u root -p and entered the password that works for user mythtv but still failed
[06:10] <tralph> the mysql password for root and mythtv are different
[06:18] <tralph> reinstalled mysql-server which allowed me to change it
[06:18] <tralph> it's working now
[06:18] <tralph> thanks
[06:40] <bllz> Does anybody know how I can solve the opengl painter issue whereby my forntend menu fades to black after a few seconds?  I rather like the opengl effects, so if there's a fix, i'd like to use it
[06:40] <bllz> the strange thing is the problem doesn't appear until I reboot
[06:41] <bllz> logs are here:  http://mythbuntu.pastebin.com/f46465930
[06:53] <bllz> go figure... everybody is afk... =(
[06:56] <iamlindoro> you have media in the drive or flash drive which contains pictures, and you have the mediamonitor turned on
[06:56] <iamlindoro> it's switching to gallery display mode
[06:56] <iamlindoro> so turn off media monitor or remove the media
[06:56] <iamlindoro> has nothing to do with the painter, though
[06:57] <bllz> iamlindoro:  if this works, you are a god
[06:57] <bllz> iamlindoro:  any idea why it only happens with the painter turned on?
[06:58] <bllz> iamlindoro:  when you say I have media in the drive, do you mean on the local harddisk or in a cdrom bay?
[07:03] <bllz> iamlindoro:  i love you
[07:03] <bllz> i love you
[07:03] <bllz> it's fixed
[07:03] <bllz> *sigh*
[11:45] <MattMoose> !help
[11:45] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[11:46] <MattMoose> hello, newbie question: is MythTV suitable (or overkill) for capturing analog video then burning it to DVD?
[17:08] <bllz> MattMoose:  it depends... what video analog video source?  live tv?
[17:08] <bllz> or something else
[19:44] <rhpot1991> anyone paying attention?
[22:22] <darthanubis> anyone with the link to start mythtv with pulseaudio support?
[22:41] <darthanubis> PULSE_INTERNAL=1 mythfrontend
[22:41] <darthanubis> now I forget where to put this
[22:44] <darthanubis> export EXPERIMENTALLY_ALLOW_PULSE_AUDIO=1
[22:59] <mrand> !pulse
[22:59] <Zinn> Sorry I don't know about pulse
[22:59] <mrand> !pulse-audio
[22:59] <Zinn> Sorry I don't know about pulse-audio
[22:59] <mrand> !pulse audio
[22:59] <Zinn> Sorry I don't know about pulse audio
[22:59] <mrand> sigh
[22:59] <mrand> !pulse
[22:59] <mrand> !pulse%
[22:59] <Zinn> Sorry I don't know about pulse
[22:59] <mrand> yes you do
[22:59] <Zinn> Pulse Audio, aka kitten killer.  See http://en.wikipedia.org/wiki/PulseAudio for more information.  Pulse Audio seems to cause problems with MythTV.  If you are having trouble, see https://bugs.launchpad.net/bugs/460579 for potential work arounds
[22:59] <mrand> see, told you.
[23:45] <darthanubis> rhpot1991, which file to put export EXPERIMENTALLY_ALLOW_PULSE_AUDIO=1?
[23:47] <darthanubis> /usr/share/mythtv/mythfrontend.sh?
[23:57] <rhpot1991> darthanubis: https://bugs.launchpad.net/mythbuntu/+bug/460579


[13:13] <BradCrittenden> hi benji, gary_poster: i'm trying to use pdb to debug charmworldlib but it is terribly confused about where to find source files.  it tries to find them in /home/bac/projects/charm-tools/build/bdist.linux-x86_64/egg/charmworldlib/bundle.py which does not exist.  (the build directory is not present.)  any ideas on how to get it sane?
[13:14] <gary_poster> on call
[13:14] <bac> say hello for me
[13:14] <benji> bac: the problem might be that the .pyc files were built in one location and then moved, if so, removing all the .pyc files will get them regenerated with correct paths
[13:15] <bac> benji: tried that first.  'make clean' removes all pyc files from the tree and then i rebuilt.  same same.
[13:15] <bac> benji: if i manually import charmworldlib and then look at __file__ it is in a reasonable spot
[13:16] <benji> bac: I don't know for sure, but if make is getting them moved, then it will just recreate the problem; I'd to an 'rm **/*.pyc' (or equiv in your shell)
[13:16] <benji> I'm curious why it is doing such a strange thing.
[13:17] <bac> benji: i'm not sure what you mean.  'make clean' removes them.  i then verify they are gone.  are you saying manually remove them after building so the debugger has to recompile them as they are encountered?
[13:17] <benji> bac: exactly
[13:17] <bac> ok, will try that
[13:23] <bac> benji: doesn't work so well when accidentally removing *.py
[13:23] <benji> heh :(
[13:26] <gary_poster> Makyo, hatch, could you please apply local pressure to hazmat to have him merge https://code.launchpad.net/~hazmat/juju-deployer/refactor-placement-and-validate-feedback/+merge/195903 ?  veiled threats welcome ;-)  thank you
[13:26] <hatch> :) can do
[13:26] <Makyo> Hah.  otp w/ sabdfl, after
[13:27] <gary_poster> ok thanks :-)
[13:29] <gary_poster> rick_h_: AIUI you are not around and we should resched.  Lemme know if I'm wrong
[13:54] <rick_h_> gary_poster: I'm around now
[13:54] <rick_h_> gary_poster: so any time you're free
[14:00] <gary_poster> ack thanks rick_h_.  Probably will be 11:30-ish
[14:00] <rick_h_> gary_poster: rgr
[14:01] <benji> frankban: I figured out that wierd selenium error and the fix was just to upgrade, will you review the trivial branch for me? https://codereview.appspot.com/33230043
[14:02] <frankban> benji: sure, on it in a minute
[14:06] <hatch> gary_poster I never got the email in question so Makyo is forwarding it to me
[14:06] <frankban> benji: the branch looks good, it's weird that the I see the MP linked to an old one (Use a random service name for tests.)
[14:06] <benji> hrm, that is odd
[14:07] <frankban> benji: but the changes are pertinent to the selenium problem, so that's just an lbox oddity I guess
[14:08] <frankban> benji: or maybe you used the same "test-failure" branch name
[14:08] <benji> frankban: oh, I did use the same branch name
[14:10] <frankban> benji: are you going to create another MP?
[14:11] <benji> frankban: I guess so
[14:11] <frankban> benji: ok, I'll LGTM  there then
[14:35] <bac> benji: can we chat real quick?
[14:36] <benji> bac: sure
[14:36] <benji> bac: how about the team meeting hangout?
[14:36] <bac> sure
[14:37] <benji> bac: https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
[14:43] <rick_h_> gary_poster: friend of mine found a talk to get me interested in clojure hah https://www.youtube.com/watch?v=ShEez0JkOFw
[14:43] <gary_poster> :-) cool
[14:52] <hatch> cool I'll check it out as well
[14:53] <hatch> I've been looking for a lispy language to spend some time on
[15:35] <hatch> rick_h_ testing some CI stuff?
[15:36] <rick_h_> hatch: yea
[15:36] <hatch> ok just fyi there will be test failures but that's because the tests are bad
[15:36] <rick_h_> hatch: supposedly the github integration will allow someone on the team (juju org) to trigger tests for pull requests from someone not in the org
[15:36] <rick_h_> hatch: that's fine, just curious. Was looking at the repo and saw the pull request as a chance to see it it'd work
[15:36] <bac> hi marcoceppi i'm working on bug 1263112 for charmworld regarding bundle proofing and inheritance.  i see you made some changes in that area to charm-tools 1.2 which may solve the bug.  are you going to be releasing 1.2 soon?
[15:36] <_mup_> Bug #1263112: charmworld proof and ingest does not properly support inheriting bundles <charmworld:In Progress by bac> <https://launchpad.net/bugs/1263112>
[15:38] <hatch> rick_h_ oh yeah cool np
[15:39] <bac> gary_poster: did you see the guy behind lighttable is from chapel hill, now seattle?
[15:50] <Makyo> jujugui call in 10
[15:53] <marcoceppi> bac: I'll be cutting a release this week
[15:53] <marcoceppi> bac: but I think that already landed
[15:56] <hazmat> did we ever change charm lint/best practice rules to accomodate gui not supporting '.' in config keys?
[15:57] <marcoceppi> bac ah, it didn't make the 1.2.5 release, that will be in 1.2.6 on Friday
[15:58] <marcoceppi> hazmat: I don't see it in the config.yaml  lint rules, is that a "critical" thing?
[15:58] <bac> marcoceppi: i don't see any charm-tools from 1.2 on pypi
[15:59] <Makyo> jujugui call in 2
[15:59] <marcoceppi> bac: oh, I haven't been pushing to pypi for the 1.2.X releases. I'll rectify that. Either way the code hasn't landed yet
[15:59] <marcoceppi> bac: I forgot you guys don't use the package, I'll make sure that finds it's way back in to my release process
[16:00] <bac> marcoceppi: ok.  would like to get us on 1.2 any way.  thanks.
[16:00] <marcoceppi> bac: uploading the old releases atm
[16:00] <marcoceppi> or, trying to
[16:00] <bac> hey marcoceppi i also noticed the charmworldlib package on pypi has .pyc files in it, which really mess up debugging.  i think it is Not Good to include pyc in the package.  could you take a look at that?
[16:01] <marcoceppi> bac: can do
[16:01] <bac> cool, thanks
[16:01] <hazmat> marcoceppi, dunno, last i checked the gui had issues with that , but perhaps its been fixed.
[16:02] <hazmat> yeah.. still has issues with it afaics
[16:03] <marcoceppi> hazmat: I'll add it to the proof then, we should update the docs with this too - does juju have a problem with it?
[16:03] <hazmat> its fairly common for some of the java charms
[16:03] <hazmat> marcoceppi, no.. just gui
[16:03] <marcoceppi> hazmat: I'm not sure if we should consider the GUI rendering an ERROR or a WARN - I mean it's pretty much integral at this point, right?
[16:04] <Makyo> gary_poster: ping?
[16:04] <gary_poster> yeah sorry
[16:04] <gary_poster> trying to finish up
[16:04] <Makyo> np
[16:04] <hazmat> marcoceppi, prolly err, gui is an essential part of the ecosystem
[16:04] <marcoceppi> hazmat: ack, I'll update proof and let jcastro know
[16:04] <hazmat> marcoceppi, thanks
[16:06] <gary_poster> sorry sprry
[16:14] <marcoceppi> bac: 1.2.5 (latest) uploaded to pypi, 1.2.6 to land friday
[16:15] <bac> marcoceppi: thanks!
[16:15] <bac> gary_poster: i replied to the email as requested and will remove my face from the card
[16:15] <gary_poster> :-) ty
[16:20] <marcoceppi> bac: I'm trying to re-package charmworldlib for you, but it still includes .pyc for __init__ and version which are parsed at setup.py time. Is there something I can do to explicitly not allow .pyc files?
[16:21] <bac> marcoceppi: unsure.  benji, thoughts?
[16:24] <bac> marcoceppi: i've got to step out for a bit but can help in an hour or so.
[16:25] <marcoceppi> bac: np, thanks for everything so far
[16:25] <benji> bac and marcoceppi: I think there is a way to do that with some sort of inventory file that includes/excludes files but I don't know the details off the top of my head.
[16:26] <benji> it's somewhat bad form to import from the package itself in the setup.py because it can easily become impossible to do so (i.e., a compliled component isn't available at setup time)
[16:26] <benji> the version.pyc shouldn't be an issue
[16:27] <marcoceppi> benji: thanks, i've added a make clean rule to the project and will press a <IP_ADDRESS> that has a cleaner sdist
[16:30] <rick_h_> marcoceppi: http://stackoverflow.com/questions/8880661/getting-package-version-using-pkg-resources for versioning
[16:30] <rick_h_> if it reads something it should just be an empty text file
[16:31] <rick_h_> marcoceppi: and the version only exists in the setup.py file
[16:31]  * rick_h_ hasn't looked at the file in question and just going off irc conversation
[16:31] <marcoceppi> rick_h_: so, can I then, using this, read the version from within the module code?
[16:31] <gary_poster> rick_h_: https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 when you are ready. no rush
[16:31] <marcoceppi> rick_h_: since help and -v both spit out the software version for the python project
[16:32] <rick_h_> marcoceppi: yes
[16:33] <marcoceppi> rick_h_: awesome, thank you. I'll update the projects to use that instead!
[16:34] <rick_h_> marcoceppi: https://github.com/bookieio/breadability/blob/master/breadability/__init__.py for example
[16:34] <rick_h_> marcoceppi: that's in the package __init__.py and reads from setup.py
[16:36] <marcoceppi> rick_h_: <3 thanks
[16:44] <marcoceppi> bac: neither project will have pyc files in the sdist going forward
[16:44] <marcoceppi> bac: 0.1.4 fo charmworldlib uploaded to pypi with no pyc, charm-tools 1.2.6 will be clean
[16:55] <Makyo> https://github.com/juju/juju-gui/pull/63 jujugui quick review/qa
[16:57] <benji> Makyo: looks good
[16:57] <Makyo> benji: cheers, thanks.
[17:56] <bac> marcoceppi: hey that all sounds great.  thanks!
[18:33] <benji> Did someone put a bitcoin miner in the charm functional tests?  These things take forever.
[19:00] <jcastro> hey gary_poster
[19:00] <jcastro> what's the status of quickstart landing in the proper juju ppa?
[19:01] <gary_poster> jcastro: isn't it there now?
[19:02] <jcastro> gary_poster, oh I see, it just needs to be built for trusty
[19:03] <gary_poster> jcastro: ack.  juju itself doesn't really work for trusty yet, does it?
[19:03] <jcastro> it does, you just need to sudo for juju status
[19:03] <gary_poster> oh ok
[19:03] <jcastro> but thumper was going to bring it up at their meeting to start testing trusty
[19:04] <jcastro> so I figure, next time I see frankban just ask him to push a trusty build into the ppa?
[19:04] <jcastro> for quickstart I mean
[19:04] <gary_poster> jcastro: yeah +1.  Do you have any urgency?
[19:04] <jcastro> not really
[19:04] <jcastro> just pointing it out
[19:05] <gary_poster> :-) cool
[19:48] <jcastro> gary_poster, hey so, the changelog formatting still looks weird, but it's readable now
[19:48] <jcastro> so I guess good enough?
[19:48] <jcastro> heh
[20:02] <bac> hey marcoceppi it looks like you made changes to charmworldlib but didn't push them to launchpad.  could you do that please?
[20:02] <marcoceppi> bac: sorry about that, committed and pushed
[20:03] <bac> cool, thanks.
[20:13] <benji> gary_poster: I sent my MSDN email
[20:16] <benji> gary_poster: also, I entered a swap day (20th -> 16th) and a vacation day (17th)
[20:34] <gary_poster> benji, did you have an days held over from 2013?
[20:34] <gary_poster> any
[20:35] <benji> gary_poster: yep, 4; this is the first of them I'm using
[20:36] <gary_poster> benji, cool.  did you see my email about needing to schedule them very soon?
[20:36] <benji> I'm heading out to my appoitment now.  Later.
[20:36] <gary_poster> ok bye
[20:36] <benji> gary_poster: I understood "very soon" to be in the first quarter.  Is there a different definition I should be aware of?
[20:37] <gary_poster> benji, Jan
[20:37] <gary_poster> benji, should be used before March 31
[20:37] <gary_poster> scheduled before end of Jan
[20:37] <gary_poster> make sense?
[20:47] <jcastro> hey gary_poster
[20:47] <jcastro> so quickstart needs the bundle to be "bundles.yaml"
[20:47] <jcastro> but we export export.yaml
[20:47] <jcastro> and it also errors out because we include the -gui in the bundle, and asks me to remove it from the bundle
[20:47] <jcastro> should I file these as bugs?
[20:48] <jcastro> I was thinking maybe have the gui export "bundles.yaml", and not include itself in the export?
[20:48] <rick_h_> jcastro: does it do that on comingsoon?
[20:49] <rick_h_> jcastro: I thought we had a bug and fixed it for including gui itself
[20:49] <rick_h_> though maybe that's not in a release yet
[20:50] <jcastro> checking
[20:50] <rick_h_> jcastro: hmm, https://bugs.launchpad.net/juju-gui/+bug/1249039 is the bug
[20:50] <_mup_> Bug #1249039: Exporting from real environment exports juju-gui as well <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1249039>
[20:51] <rick_h_> so guess it's still an issue, jujst low on the -gui and high on quickstart
[20:51] <jcastro> rick_h_, nice! It comingsoon does the right thing
[20:51] <rick_h_> jcastro: ah, ok cool then
[20:51] <jcastro> ok
[20:52] <jcastro> so ... is making it so it export bundles.yaml a gui bug or should the bug be "quickstart/deployer should be able to deploy a yaml file, no matter what I name it"
[20:52] <jcastro> the 2nd one seems more correct to me
[20:52] <rick_h_> jcastro: yea, same to me. frankban is EOD but would ask him about it tomorrow. If there's any history for the mandate to make it so
[20:53]  * jcastro nods
[20:53] <jcastro> yeah so ... I just quickstarted in AWS and dragged over the brutal mongodb thing I am working on
[20:53] <jcastro> it's pretty much awesome
[21:47] <benji> yay charm tests passed
[21:47] <rick_h_> yay
[21:58] <huwshimi> Morning
[23:24] <gary_poster> morning huwshimi.  dinner not served here yet. mind if we start talking at the top of the hour?
[23:25] <huwshimi> gary_poster: Sure!
[23:25] <gary_poster> cool thanks.  talk to you then


[06:32] <cjwatson> mwharris: on demand
[06:33] <cjwatson> will poke it later today
[18:05] <mwharris> cjwatson: woo! thanks.
[22:51] <mwharris> cjwatson: any word on the netboot update?


[00:06] <TheMuso> NCommander: when you did your ia64 shuffle, you forgot to tweak the getabis script properly, so you can imagine what happened when I uploaded linux-ports last night for ia64...
[00:06] <TheMuso> s/properly//
[00:08] <TheMuso> of course I forgot to check, but anyway.
[01:10] <jbailey> NCommander, If you are going to care about hppa, can you take a look at: https://launchpad.net/~doko/+archive/toolchain
[01:10] <jbailey> the eglibc failure would probably block its adoption by other arches.
[01:10] <jbailey> If not, there's another good excuse to just pitch it.
[05:13] <lamont> NCommander: jaunty alternate?
[05:18] <lamont> jaunty/ia64 alternate that is
[15:39] <NCommander> lamont, I can build it, but the kernel won't be available, and after noon today, I won't have an ia64 to mess with
[15:39] <NCommander> lamont, (until after UDS)
[15:40] <NCommander> lamont, if you can give me modified metapackages that can pull in the necessary kernel, I'll spin a CD (I have an easy mechanism which to inject new packages into a CD image)
[15:51] <jbailey> NCommander, You could just put it on the internet.
[15:51] <jbailey> I can promise you that whatever security exploits people are using these days aren't targetted to ia64. =
[15:51] <jbailey> )
[15:51] <jbailey> If you feel really paranoid, setup an IPv6 tunnel and put it on that.
[15:51] <jbailey> Then you just use IPv6 at the conference to access it directly.
[15:56] <NCommander> jbailey, no, the problem is with the broken metapackage, the installer can't find a kernel to install
[15:57] <jbailey> Doesn't ia64 have Xen or kvm now?
[15:57] <jbailey> You could still do this remotely. =)
[15:57] <NCommander> If the ia64 has kvm, I'll leave it on while I travel
[15:57] <NCommander> jbailey, can you check for me? (I'm kinda packing ATM)
[15:58] <jbailey> NCommander, http://www.linux-kvm.org/page/Status
[15:58] <jbailey> IT's listed as "In Progress"
[15:58] <NCommander> bah
[16:02] <NCommander> jbailey, probably staying w/ Hardy until karmic comes out is the sanest move
[16:02] <jbailey> Eh, you're doing development on it.
[16:02] <jbailey> You want to be bleeding edge or karmic won't work either.
[16:03] <NCommander> jbailey, well, I'm going to fix karmic's kernel while I'm traveling
[16:03] <NCommander> But if I'm going to build CD images, I need to check it before we release
[16:03] <NCommander> jbailey, we do have a ia64/hardy image now anyway :-)


[09:44] <teddy-dbear> Morning peoples, critters and everything else
[19:32] <Pennth> Ubuntu updated the update-manager and update-notifier packages today. You know what that means, kids... :)
[20:03] <waltman> umm, no?
[20:33] <waltman> Do they do this before a new version comes out?
[20:35] <rmg51> they do that whenever they want
[20:38] <waltman> That's what I thought. So does it mean I have to reboot?
[20:38] <waltman> I think I have a new kernel waiting for me anyway.
[20:39] <rmg51> the updater will tell you if you need to reboot
[20:40] <waltman> I *think* it was telling me I needed to reboot just because I ran "apt auto-remove".
[20:41]  * waltman wonders what Pennth was getting at :(
[20:42] <rmg51> a new version of Ubuntu will be coming out in a few weeks
[20:48] <waltman> Yes, I know.
[20:49] <waltman> That's why I suggested it!
[21:05] <Pennth> waltman, rmg51 has it. 17.04 due soon. Though I'm staying on 16.04 :)
[21:08]  * waltman is confused


[11:04] <angs> I am trying to install a driver on ubuntu-desktop 12.04 on beagleboard-xm.  When I type "make", I get the following error http://pastebin.com/wRqt7X3R  that links to wrong directory. It links to ...arch/armv7l/Makefile directory instead of arch/arm/Makefile   .. This is the Makefile of the driver installation file (not .../arch/arm/Makefile directory) http://pastebin.com/s9TJ9uk2   . What line do I need to change in the makefile in order to fix t
[11:04] <angs> he link problem?
[11:04] <angs> or if I change the directory name ../arm/Makefile to /armv7l/Makefile by manual, would it cause further problems?
[14:00] <Chipaca> hi guys. Can anybody tell me why "runhaskell" is not in precise's ghc package on arm? and where i can find it?
[15:11] <steev> angs: ARCH=armv7l is wrong, the kernel only knows about arm
[15:20] <angs> steev: thank you, I solved it as you told by changing the make file
[15:20] <steev> angs: why not use the driver that's in the kernel (or compat-wireless)?
[15:26] <janimo> ogra_, has the daily image spinning stopped? I see latest is jun 29
[15:26] <ogra_> update-xapian-index errored out
[15:26] <ogra_> so all images failed for a while
[15:31] <angs> I am trying to use the usb doggle in the ad-hoc mode, I was able to connect to my access point without installing any extra package. However, I could not use it on the ad-hoc mode. I thought I should install the driver that came with the wifi dongle. But, I still cannot use it in the ad hoc mode. I am using these commands: http://pastebin.com/kTMkgCDx  I wonder if someone can tell me what is wrong with the settings or what can I do to use the wif
[15:31] <angs> i dongle in ad-hoc mode. the doggle is micronext mn-wd 152B that has RTL8188CUS chipset.
[15:33] <ogra_> not really an arm specific problem ... did you search the wiki for setting up ad-hoc ?
[15:34] <angs> I used this instruction https://help.ubuntu.com/community/WifiDocs/Adhoc
[15:36] <angs> it is not arm-related, I also tried it on my laptop (ubuntu 12.04), it did not work. maybe there is someone that has experience in setting the dongle in ad-hoc mode could advise me what to do
[15:36]  * ogra_ never used ad-hoc, sorry, cant help
[15:37] <angs> thank you, I will try my chance on #beagle
[15:44] <steev> same, i've been using wireless cards since way back when, never bothered with ad-hoc
[15:52]  * GrueMaster debates turning his beagle into a digital doorbell.
[15:59] <Chipaca> is python-matplotlib just not built for armhf?
[16:03] <ogra_> what source package would that be in ?
[16:28] <Chipaca> ogra_: matplotlib
[16:28] <Chipaca> i'm currently rebuilding ghc because it's missing some binaries on armhf, also
[16:28] <Chipaca> so can't really rebuild that too :)
[16:32] <janimo> Chipaca, did you find why ghc does not include runhaskell, oversight or intentional?
[16:32] <Chipaca> janimo: no
[16:32] <Chipaca> janimo: i'm just blindly rebuilding
[16:32] <Chipaca> janimo: because i couldn't really look into the packaging until tonight
[16:32] <Chipaca> so if it's done by tonight, i'll know more than if i didn't rebuild :)
[16:33] <janimo> Chipaca, unless it is an oversight the maintainers may have had a reason for it, ghc was not as well tested on ARM as elsewhere
[16:34] <Chipaca> janimo: i'm hoping it's an oversight, becaue it's not much use without that :)
[16:34] <janimo> Chipaca, precise or quantal?
[16:36] <Chipaca> janimo: precise
[16:55] <janimo> Chipaca, you may want to tweak mk/config.mk.in in the ghc package. It has ArchSupportsGHCi= which says which arch ghci and other commands are built on
[16:55] <janimo> runhaskell goes in only if there's an interpreter built
[16:55] <janimo> so you need to buld with armhf added there ans see if there's a bug
[16:55] <janimo> or just a historical ommission :)
[16:58] <Chipaca> janimo: awsome, thank you
[16:59] <janimo> Chipaca, hopefully it should just work and then a patch can be applied upstream :)
[17:00] <janimo> Chipaca, I just googled it an apparently ghci on arm is being worked on, so not yet
[17:06] <Chipaca> gah
[17:12] <Chipaca> janimo: so now i need to figure out how to build things which have runhaskell as the how-to-build
[17:12] <Chipaca> and i know just enough haskell to know that's not going to be fun
[17:12]  * Chipaca suddenly realized he knows haskellites at the university who own the same computer he has
[17:12]  * Chipaca runs to find them
[17:22] <Chipaca> huh
[17:22] <Chipaca> ghc --make
[17:24] <Chipaca> ogra_: any news re matplotlib?
[17:34] <scientes> where is the apckages.ubuntu.com for ports?
[17:34] <mythos> scientes, apt-get install apt-file
[17:35] <scientes> mythos, that is entirely differn't
[17:35] <mythos> different from what?
[17:35] <scientes> packages.ubuntu.com
[17:35] <mythos> ports.ubuntu.com is not indexed on packages.ubuntu.com. but you can use apt-file instead
[17:35] <scientes> oh shitty
[17:36] <scientes> even emdebian has a packages.debian.org alt
[17:36] <mythos> apt-file is a really neat tool. don't be shy, you are going to love it
[17:36] <scientes> i refuse to use it, cause i don't like extra databases
[17:36] <scientes> i use dpkg -S instead
[17:36] <scientes> and packages.debian.org/file:foo
[17:37] <scientes> also, rapt-file doesn't work
[17:37] <mythos> apt-file downloads only the contents.gz from your repo.
[17:38] <mythos> did you an apt-file update first?
[17:38] <mythos> then apt-file search <you name it>
[17:38] <scientes> the whole point of rapt-file is that it doesn't need a database
[17:38] <mythos> rapt-file?
[17:38] <scientes> its part of the apt-file package *remote*
[17:38] <mythos> yeah, ok
[17:39] <scientes> most of my uses of p.d.org etc are about getting up-to-date info
[17:39] <scientes> which is another reason apt-file just doesn't cut it
[17:39] <mythos> an apt-file update is so hard?
[17:39] <scientes> no, cause its backwards for what i'm doing
[17:40] <scientes> and it only works on the same arch and dist as your computer
[17:40] <mythos> ok... then you could set up an equivalent for packages.ubuntu.com for ports?
[17:40] <scientes> p.foo.bar works everwhere
[17:40] <mythos> no, that's nonsense
[17:40] <mythos> you can specifiy an sources.list and an cache folder
[17:40] <scientes> like, you can download a debian package from it, and use it on ubuntu , etc
[17:41] <scientes> oh for apt-file
[17:41] <mythos> don't know what you mean with "p.foo.bar works everywhere"
[17:50] <scientes> packages.debian|ubuntu.org|com
[17:50] <mythos> and what's with that?
[21:53] <Chipaca> can ppas be made to build armhf?