[07:01] <zyga> Chipaca: good morning
[07:01] <Chipaca> zyga: morning
[07:03] <zyga> Chipaca: I'm seeing this error all the time:
[07:03] <zyga> src/github.com/snapcore/snapd/vendor/golang.org/x/crypto/ssh/test/test_unix_test.go:25:2: cannot find package "golang.org/x/crypto/ssh/testdata" in any of:
[07:03] <zyga> does it ring any bells? anything changed in how we vendor stuff?
[07:04] <Chipaca> zyga: i have never seen it before
[07:04] <morphis> zyga: I've seen this once in a fedora build where we missed to copy testdata into place
[07:05] <morphis> but actually that was for one of our packages not the ssh one
[07:05] <zyga> Chipaca: ok, separate topic, I asked mvo how we might go ahead with storing more data into sequence but he didn't reply; I was thinking about storing a 2nd sequence like object
[07:05] <zyga> hey morphis :)
[07:05] <morphis> zyga: hey!
[07:05] <zyga> Chipaca: so that we can get away without patching anything in the state
[07:05] <zyga> Chipaca: so sequence-ex could store more stuff (flags, path, side info)
[07:05] <zyga> Chipaca: wdyt?
[07:06] <Chipaca> zyga: type SuperInfo struct { *SideInfo }
[07:06] <morphis> zyga: do you have time for another review on https://github.com/snapcore/snapd/pull/3222 ?
[07:06] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[07:06] <zyga> morphis: yes, I'll focus on reviews today (again)
[07:06] <zyga> morphis: I was off yesterday (despite being here a little)
[07:07] <zyga> Chipaca: super info I like
[07:07] <Chipaca> zyga: and make Sequence be []SuperInfo (or []*SuperInfo)
[07:07] <zyga> Chipaca: hmm
[07:07] <zyga> Chipaca: though
[07:07] <zyga> maybe not sure, we risk clashing fields
[07:07] <zyga> Chipaca: why not just sequence-ex with dedicated fields?
[07:07] <zyga> (we can clean up when patches are live)
[07:08] <Chipaca> zyga: because then you have to keep to slices in sync?
[07:08] <zyga> yes
[07:08] <Chipaca> zyga: and decide how to handle drift
[07:08] <zyga> I planned to already
[07:08] <zyga> hmm
[07:09] <zyga> in case of rollbacks?
[07:09] <morphis> zyga: thanks
[07:09] <zyga> well, this is already equally hard, there is no required data currently, we'd have to add the data only to the new sequence
[07:09] <zyga> and this is only for snap try, it is still broken today in master (from this pov) so it'd not be a regression
[07:09] <Chipaca> zyga: i mean, what's the advantage of having a second sequence instead of adding to the existing?
[07:10] <Chipaca> zyga: you're seeing something there that I am not
[07:10] <zyga> Chipaca: the advantage is that the second sequence would not embed a go type so it cannot clash on field names there;
[07:10] <Chipaca> zyga: we could even add SnapPath to SideInfo
[07:12] <Chipaca> ogra_: ping?
[07:12] <zyga> Chipaca: hmm hmm
[07:12] <zyga> Chipaca: the problem is that we may need more than just snap path
[07:12] <zyga> Chipaca: what I think we need to capture in this particular case is the fact that it was on encrypted directory
[07:12] <zyga> Chipaca: more so than the fact than the actual path (which I would capture anyway)
[07:13] <Chipaca> zyga: it being on an encrypted directory is something that should be detected at runtime, fwiw
[07:14] <zyga> Chipaca: no, because it may not even be mounted :/
[07:14] <Chipaca> ok, wait
[07:14] <Chipaca> if it's not mounted, why do you need to know if it's encrypted?
[07:14] <zyga> Chipaca: have a look at the discussion here https://github.com/snapcore/snapd/pull/2837#discussion_r114855843
[07:14] <mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
[07:14] <zyga> Chipaca: because it was encrypted when the user is logged in
[07:14] <zyga> Chipaca: then she logs out
[07:14] <zyga> Chipaca: and snapd restarts
[07:14] <zyga> Chipaca: and needs to write the apparmor policy
[07:15] <zyga> Chipaca: :/
[07:15] <Chipaca> zyga: brb
[07:15] <zyga> no worries, I wanted to let you know about this to get you thinking
[07:15] <zyga> I'll try to fix it today but I want to agree on direction
[07:16]  * zyga -> breakfast
[07:20] <Chipaca> zyga: if the directory of a snap try goes away, the snap is removed
[07:28] <Chipaca> zyga: several rough edges here though
[07:29] <Chipaca> zyga: one is: if you snap install foo, and then snap try ./foo, you end up with a foo from the store and a foo from try. We don't handle this case well today at all (the whole snap is in "try mode")
[07:29] <Chipaca> zyga: and the question is, if the directory goes away in this case, what should happen? should it fall back to the non-try one?
[07:30] <Chipaca> i'd suggest we solve this by not allowing mixing try and non-try, at least for now
[07:31] <Chipaca> (any mixing of try and non-try can be made explicit with flags, later, where we don't mix them in state but copy config over or whatever)
[07:31] <Chipaca> this avoids all the uncomfortable corner cases of mixing the two modes
[07:32] <Chipaca> and makes the current approach of having 'trymode' on the snap (instead of the sequence) fine
[07:32] <Chipaca> and gives us an easy approach to getting the snap path, whichi is to add it next to trymode
[07:32] <Chipaca> the 'patch' code can look in changes for the snapsetup, or at the mount unit
[07:33] <Chipaca> (or we could look at the mount unit in runtime, but that feels 15.04ish :-) )
[07:40] <Chipaca> zyga: i'm creating a forum topic about this
[07:50] <Chipaca> zyga: https://forum.snapcraft.io/t/disallow-mixing-try-and-non-try-snap-installs/484
[08:02] <ogra_> Chipaca, yes ?
[08:02] <Chipaca> ogra_: two questions for you sah
[08:02] <Chipaca> ogra_: we nuke locale support from core, yes?
[08:02] <Chipaca> or have we added it back recently
[08:03] <Chipaca> ogra_: (good morning! how're you doing today?)
[08:03] <ogra_> Chipaca, nope, actually locale support was nuked everywhere now (ubuntu-base, cloud images etc)
[08:04] <Chipaca> ogra_: ok. 2nd question, what is the locale-control interface for, do you know?
[08:05] <ogra_> i guess nothing ... but since we never shipped locales thats fine i guess
[08:05] <ogra_> (thank you i'm fine :) )
[08:05] <Chipaca> ogra_: i mean, we even have a snap to test it works
[08:05] <ogra_> not on core
[08:05] <zyga> Chipaca: thank you!
[08:06] <ogra_> we never did to my knowledge
[08:06] <Chipaca> so /etc/default/locale is from "outside", on classic?
[08:06] <ogra_> thats a zyga question, not sure if snap-confine mounts it
[08:07] <Chipaca> zyga: ^ :-)
[08:08] <Chipaca> ogra_: by the way, it looks like core is currently shipping the locales for e2fsprogs
[08:08] <Chipaca> ogra_: i assume that's a bug
[08:09] <ogra_> hmm, i wonder how they get there
[08:09] <ogra_> yes
[08:10] <zyga> Chipaca: replied on the forum
[08:10] <ogra_> seems fwupdate too
[08:10] <zyga> Chipaca: mmm, /etc/default/locale is from classic
[08:10] <Chipaca> zyga: ok, good
[08:10] <Chipaca> ogra_: and is /etc/default/locale writable in core?
[08:10] <zyga> Chipaca: but also (this is an ogra topic :) on core we do some writable path magic I'm not fully versed in
[08:10]  * ogra_ hopes /usr/share/locale too
[08:11] <ogra_> Chipaca, i dont think so ... it should be hardcoded to C.UTF-8
[08:11]  * ogra_ checks
[08:11] <ogra_> ogra@pi3:~$ mount |grep locale
[08:11] <ogra_> ogra@pi3:~$ cat /etc/default/locale
[08:11] <ogra_> LANG="C.UTF-8"
[08:11] <ogra_> yep
[08:11] <Chipaca> if the idea of locale-control is to not work at all on core, we should probably check for that
[08:11] <Chipaca> ogra_: and non-writable?
[08:11] <ogra_> see the mount :)
[08:11] <ogra_> (yes, non-writable)
[08:12] <Chipaca> ah :-)
[08:12] <Chipaca> ok
[08:12] <ogra_> doesnt mean that wont change in case we get langpack snapsd or some such indeed
[08:12] <ogra_> *snaps
[08:13] <Chipaca> I'm pretty sure locale-control needs fixing to work on !debianish
[08:13] <Chipaca> morphis ^
[08:14] <ogra_> i'm pretty sure they dont have /etc/default on non-debian
[08:15] <zyga> Chipaca: I think the whole /etc design is broken today
[08:15] <zyga> Chipaca: we want to entirely stop sharing /etc
[08:15] <zyga> Chipaca: and share (or mirror) selective elements
[08:15] <Chipaca> all these locale questions are because of https://askubuntu.com/q/910514/711 btw
[08:17] <morphis> Chipaca: locale-control happy isn't "broken" on any !debian system today as we don't have confinement anywhere ..
[08:17] <Chipaca> morphis: it's broken in that it doesn't do what's intended
[08:17] <Chipaca> i.e. it doesn't change the default locale of the system
[08:17] <morphis> Chipaca: doesn't it just allow access to /etc/default/locale via AppArmor?
[08:18] <Chipaca> morphis: yes
[08:18] <Chipaca> exactly
[08:18] <Chipaca> that is not a thing in !debian, afaik
[08:18] <morphis> sure
[08:18] <morphis> but we don't have any AppARmor on anything else than Ubuntu today
[08:18] <Chipaca> ah, now i gotcha
[08:18] <Chipaca> ok
[08:18] <morphis> if we get AppArmor anywhere else I think we can easily add the right paths to the AppARmor snippet
[08:19] <ogra_> you can ship translations inside your snap and use them (not sure if the content interface would work here but i guess with the correct env set in your wrapper it should)
[08:20] <ogra_> there are env variables for this
[08:37] <AdamH_> Hello, is there a work around available for the problems with apt-get update on an arm board when running in classic snap on Ubuntu core?
[08:39] <zyga> Chipaca: so quick question about try, is that the current design that if the directory goes away try mode snap should uninstall itself?
[08:39] <zyga> AdamH_: hey, do you have some more details about the issue?
[08:40] <AdamH_> zyga: This is the bug I am experiencing https://bugs.launchpad.net/snappy/+bug/1670475
[08:40] <mup> Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475>
[08:42] <zyga> ogra_: ^ I had a look at the bug but I don't know anything about it
[08:42] <zyga> ogra_: do you know what the root cause is?
[08:42] <zyga> ogra_: ports vs non-ports archive?
[08:43] <ogra_> zyga, something with gnupg, i'm still not sure what ... has nothing to do with any archive servers, thats a local issue with the classic snap
[08:43] <zyga> ogra_: any idea why it is specific to arm?
[08:44] <zyga> ogra_: could it be some version of gpg that we've seeded into the images due to snappy?
[08:44] <zyga> ogra_: gnupg 1 vs 2
[08:45] <ogra_> zyga, that would be odd, i rather thing we remove to much when wrapping up the tarball for core
[08:45] <ogra_> *think
[08:47] <zyga> AdamH_: so there you go, I don't know anything more
[08:47]  * zyga reviews https://github.com/snapcore/snapd/pull/3222/files
[08:47] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[08:48] <AdamH_> zyga: Thank you
[08:49] <ogra_> AdamH_, the "workaround" is described in the bug though ... (turn off gpg checking)
[08:50]  * ogra_ glares at the first line of https://forum.snapcraft.io/t/failed-to-flush-stdout-permission-denied/485 and tries to wrap his head around that command
[08:50] <ogra_> wondering if he made a typo there or if there is actually a snap that calls apt install
[08:50] <Chipaca> zyga: I thought it was, but it isn't
[08:51] <Chipaca> zyga: (the current behaviour for snapd to remove a try that vanished)
[08:51] <Chipaca> it goes into broken state
[08:52] <AdamH_> zyga: Yes I tried sudo apt-get --allow-unauthenticated upgrade but still get the same error? Is there a better way to disable the check?
[08:53] <ogra_> AdamH_, upgrade ? you mean update, right ?
[08:53] <AdamH_> ogra: Yes sorry I mean update
[08:53] <ogra_> heh, k :)
[08:54] <ogra_> likewise you should be fine just typing Y on the question about unauthenticated packages
[08:59] <pachulo> yes kyrofa ! I'm looking at this: https://github.com/nextcloud/nextcloud-snap/issues/60 and was trying to compile the nextcloud-snap for my rbpi3, after hitting the out of RAM issue when compiling mysql I found out your post (https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way) but I the 3 builds I tried all failed:
[08:59] <pachulo> https://launchpadlibrarian.net/318427985/buildlog_snap_ubuntu_xenial_armhf_nextcloud-snap-pachulo_BUILDING.txt.gz
[08:59] <AdamH_> ogra: I don't get a prompt when trying to update, only when I am installing a package
[08:59] <ogra_> AdamH_, yeah, thats what i mean
[09:00] <ogra_> it should install afterwards
[09:00] <AdamH_> ogra: Yes it does
[09:14] <Chipaca> pachulo: I think it's about 2am for kyrofa; try in a few more hours
[09:17] <Chipaca> zyga: where does the decision to include or not include (say) unity7 in the core snap come from?
[09:19] <Chipaca> jdstrand: when you're around, i'd like to look at the issue of _filedir
[09:23] <zyga> Chipaca: in snap/implicit.go
[09:24] <Chipaca> aha, no wonder i couldn't find it in interfaces :-)
[09:24] <Chipaca> zyga: I think locale-control needs to move to implicitClassicSlots
[09:24] <pachulo> thanks Chipaca !
[09:24] <Chipaca> zyga: ogra_: right?
[09:25] <mup> PR snapd#3274 opened: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
[09:25] <zyga> Chipaca: I think some commercial products use that slot but if you guys say it does nothing on core we need to re-visit thi
[09:26] <morphis> Chipaca: if you move it somebody should query the store to see if there are any snaps which use that interface already
[09:29] <Chipaca> morphis: zyga: I can confirm that if a snap does use that interface, attempting to actually modify the locale fails
[09:29] <Chipaca> in core
[09:31] <morphis> Chipaca: yeah, however we need to ensure we don't break existing snaps which are installed on a core system today and use that interface
[09:32] <Chipaca> morphis: yep
[09:32] <morphis> Chipaca: if snapd handles that already nicely, then I am fine
[09:32] <Chipaca> sadly answering that question is harder than it should
[09:38] <Chipaca> cannot create lock directory /run/snapd/lock: Permission denied
[09:38] <Chipaca> pstolowski: ^ halp?
[09:38] <ogra_> Chipaca, yeah, i guess locale-control being classic only is fine
[09:39] <Chipaca> pstolowski: suspect version mismash but i don't know of what :-)
[09:40] <morphis> zyga: you got "cannot find package "golang.org/x/crypto/ssh/testdata"" fixed?
[09:40] <morphis> seeing that on travis now
[09:41] <pstolowski> Chipaca, where do you see that?
[09:41] <Chipaca> pstolowski: when trying to run any app
[09:41] <Chipaca> pstolowski: but i might have snap-confine from master and snapd from elsewhere
[09:41] <pstolowski> uh
[09:42] <Chipaca> so it's probably me (but please advise)
[09:42] <zyga> morphis: no
[09:42] <zyga> morphis: not sure what's going on really
[09:43] <pstolowski> Chipaca, how about checking the versions? dpkg -l|grep snap
[09:43] <zyga> Chipaca: snap-confine misalinged with profile
[09:43] <zyga> Chipaca: seems exactly the same what morphis ran into yesterday
[09:43] <Chipaca> pstolowski: i'm not running any of the things from the package at this point
[09:43] <zyga> Chipaca: are you playing around with development versions of snap-conifne?
[09:43] <Chipaca> snap-confine is from yesterday's master
[09:44] <Chipaca> snapd is snapd/2.24+git605.g2eda802.dirty
[09:44] <zyga> Chipaca: ok
[09:44] <zyga> Chipaca: how did you install it?
[09:44] <Chipaca> snap-confine? make hack
[09:44] <zyga> Chipaca: in general you need make hack + several bind mounts :/
[09:44] <zyga> Chipaca: one for the binary into core (or disable reexec)
[09:44] <zyga> Chipaca: one for the apparmor profile into core
[09:44] <Chipaca> snapd, built it by hand and run-snapd-srv
[09:45] <pstolowski> ok, i'm glad zyga jumped in, because i'd never have guessed :}
[09:45] <Chipaca> ¯\_(ツ)_/¯
[09:45] <zyga> Chipaca: the issue is that snap runs snap-confine from core and then the apparmor profile is in /etc/apparmor.d/snap.core.$number.usr.lib.snapd.snap-confine.real
[09:45] <zyga> Chipaca: and then that thing must match the one that was made by make hack
[09:45] <Chipaca> zyga: snap only runs snap-confine from core if it reexecs though
[09:45] <zyga> Chipaca: except for the paths (revision in core0
[09:45] <Chipaca> so maybe my snap is from package
[09:45] <zyga> Chipaca: maybe bug? check if you have snap
[09:45] <Chipaca> that might explain that
[09:45] <zyga> Chipaca: (built from source)
[09:46] <zyga> Chipaca: anyway, a dumb solution is just to bind mount the apparmor profile over that in core and restart snapd
[09:48] <Chipaca> zyga: pstolowski: updated snap (manually) and snap-confine (make hack) fixed it
[09:48] <Chipaca> no bind mounts needed
[09:48] <zyga> morphis: https://github.com/snapcore/snapd/pull/3222#pullrequestreview-36469425
[09:48] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[09:48] <zyga> morphis: reading rest
[09:49] <zyga> Chipaca: yep, this means that snap is honring reexec correctly!
[09:52] <mup> PR snapd#3275 opened: snap: move locale-control to only be present on classic <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275>
[10:12]  * zyga finds code review in gitk better/faster than on github
[10:12] <zyga> :/
[10:15] <ogra_> trying to debug that apt issue i get the feeling it is related to how we handle /tmp
[10:26] <zyga> ogra_: oh?
[10:26] <zyga> ogra_: how do we handle /tmp on classic?
[10:26] <zyga> it's just the regular tmp, right?
[10:26] <zyga> (regular in snap execution environment)
[10:26] <ogra_> we dont do anything at all
[10:27] <ogra_> what i see in the logs is http://paste.ubuntu.com/24516298/
[10:27] <ogra_> see how it tiresd to use /var/snap/classic/common/classic/tmp/fileutl.message.wopbff
[10:28] <zyga> wow
[10:28] <zyga> what an insane profile!
[10:28] <zyga> ah wait
[10:28] <zyga> name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff"
[10:28] <zyga> so /tmp is special!
[10:28] <ogra_> it is --devmode
[10:28] <zyga> it's a persistent /tmp in $SNAP_COMMON
[10:29] <ogra_> (classic)ogra@pi3:~$ touch /tmp/foo
[10:29] <ogra_> (classic)ogra@pi3:~$
[10:29] <ogra_> (in one terminal)
[10:29] <ogra_> ogra@pi3:~$ ls -l /var/snap/classic/common/classic/tmp/
[10:29] <ogra_> total 0
[10:29] <ogra_> -rw-r--r-- 1 ogra ogra 0 May  5 10:28 foo
[10:29] <ogra_> (in the other)
[10:29] <ogra_> so it actually writes there
[10:29] <ogra_> permissions and all seem fine too
[10:30] <ogra_> yet, apt prints exactly that line every time it spills the gpg error
[10:31] <zyga> ogra_: that?
[10:31] <ogra_> ?
[10:32] <zyga> ogra_: "that line", which line is that?
[10:32] <ogra_> the one from the paste above
[10:35] <zyga> ogra_: what is ="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff"
[10:35] <zyga> is that a socket?
[10:35] <zyga> mknod being the thing that is not normally allowed
[10:35] <zyga> maybe we can now allow it and use seccomp filtering
[10:35] <ogra_> well, --devmode ... so it is aloowed
[10:37] <ogra_> sigh .... i wish that log output would be somehow readable
[10:37] <zyga> ogra_: yeah
[10:37]  * zyga would like to understand what that profile name means
[10:37] <zyga> jjohansen: ^ if you can help me out
[10:37] <ogra_> these lines are way to long to even grasp them
[10:37] <zyga> to quote so that you don't have to hunt pastebins:
[10:37] <zyga> May  5 10:12:22 pi3 kernel: [ 7741.891667] audit: type=1400 audit(1493979142.467:148626): apparmor="ALLOWED" operation="mknod"
[10:37] <zyga> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common
[10:38] <zyga> /classic/usr/bin/apt-get" name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff" pid=12088 comm="apt-get" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[10:38] <ogra_> well, due to the ALLOWED it should technically work
[10:40] <zyga> yes
[10:40] <zyga> it does work
[10:40] <zyga> whatever happens it is something else that's broekn
[10:40] <zyga> broken*
[10:41] <ogra_> well, nothing in classic changed when it started to happen
[10:41] <ogra_> it must be releated to the surrounding env
[10:42] <ogra_> i see that /etc/apt/trusted.gpg is intact and contains the right keys ... i can also list them with apt-key list ...
[10:43] <ogra_> gnupg (1) is also installed fine and working otherwise
[10:44] <ogra_> (i can also add/remove keys with apt-key just fine)
[10:46]  * zyga has a crazy idea
[10:46] <zyga> to have a snapd that lives in an execution environment by itself
[10:46] <zyga> so snapd would run in a snapd namespace
[10:46] <zyga> that is consistent across distros more than the helper snapd outside
[10:48] <zyga> morphis: one more question on that PR
[10:48] <zyga> morphis: at the bottom
[10:48] <mup> PR snapd#3276 opened: tests: additional setup in docker test for core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3276>
[10:50] <zyga> Chipaca: hey
[10:50] <zyga> Chipaca: back to that sequence topic
[10:51] <zyga> Chipaca: do you think this is something worth tackling today or better next week when gustavo can voice his opinion?
[10:52] <Chipaca> zyga: well, there's a bunch of work to be done. Is there any you can tackle without his input?
[10:52] <Chipaca> zyga: e.g. the code to grab SnapPath from existing state, for the migration
[10:53] <Chipaca> zyga: the code to determine whether a directory is part of an ecrypt-encrypted volume
[10:53] <Chipaca> not volume. Tree? path? w/e
[10:54] <Chipaca> zyga: i'd start there, and that's probably fiddly enough to take you over to monday
[10:54] <zyga> Chipaca: that is actually easy (a simple extension of what I wrote yesterday) but I think it is stuck on a design decision: of how snaps behave when a volume is not mounted
[10:54] <Chipaca> zyga: currently, they go to 'broken' state
[10:55] <zyga> Chipaca: yeah but what do we _want_ to happen?
[10:56] <Chipaca> zyga: yeah, that's design -> involves gustavo
[10:56] <zyga> yeah
[10:56] <zyga> let's do it next week
[10:56] <zyga> ok next branch
[10:56] <Chipaca> (worse, it's design i don't have an opinion on myself :-) )
[10:57] <zyga> haha
[10:58] <pstolowski> zyga, are you working on a fix for https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464/4 ?
[10:59] <Chipaca> pstolowski: no, you were
[11:00] <pstolowski> Chipaca, I intended to, but then zyga commented in the topic saying he would make it happen ;)
[11:00] <Chipaca> pstolowski: (i mean, that's what you said yesterday in the standup? or did i misunderstand?)
[11:00] <Chipaca> ahh
[11:00] <Chipaca> see, ordering is important :-p
[11:00] <Chipaca> ok
[11:00] <Chipaca> pstolowski: maybe his intention was to make it happen by bossing you around
[11:01] <pstolowski> :D
[11:03] <zyga> pstolowski: not at present, I'm doing code reviews again
[11:04] <zyga> hahaha
[11:04] <zyga> pstolowski: I think I commented on that earlier but perhaps I'm mistaken :)
[11:04] <zyga> pstolowski: feel free to take it
[11:07] <Chipaca> zyga: With unity 8 going away, does adding online-accounts interface make sense?
[11:07] <Chipaca> zyga: should we instead nuke all the unity8 support interfaces?
[11:07] <Chipaca> as unity8-in-a-snap is prooobably not going to happen
[11:08] <zyga> Chipaca: I'd not nuke anything, people are free to hack on those
[11:08] <pstolowski> zyga, ok
[11:09] <Chipaca> zyga: but if nothing is using them (and nothing is afaik) then they bitrot
[11:09] <pstolowski> Chipaca, yeah, we talked about this some time ago on the standup.. unity8 may be developed by community, there is some interest in continuing the project
[11:11] <Chipaca> fair enough
[11:11] <Chipaca> brb (rebooting)
[11:14]  * zyga thinks that bitroot is an interesting problem
[11:38] <jjohansen> zyga: its a learning/complain mode profile. The name starts with the profile that caused the exec chain
[11:38] <jjohansen>   snap.classic.classic
[11:38] <jjohansen> and then each //null-  is a new layer of exec, so what ever was confined by snap.classic.classic did an exec of
[11:38] <jjohansen>   /usr/bin/systemd-run  which called
[11:38] <jjohansen>      /usr/sbin/chroot  which called
[11:38] <jjohansen>           /var/snap/classic/common/classic/bin/dash  which called
[11:38] <jjohansen>                /var/snap/classic/common/classic/usr/bin/script  which called
[11:38] <jjohansen>                    /var/snap/classic/common/classic/bin/bash  which called
[11:38] <jjohansen>                         /var/snap/classic/common/classic/usr/bin/sudo  which called
[11:38] <jjohansen>                               /var/snap/classic/common/classic/bin/bash  which called
[11:38] <jjohansen>                                     /var/snap/classic/common/classic/usr/bin/sudo   which called
[11:38] <jjohansen>                                           /var/snap/classic/common/classic/usr/bin/apt-get
[11:38] <jjohansen> that final descendant caused the log message
[11:39] <dragly> zyga: What is the status on OpenGL with Intel drivers? Should it work? I'm having trouble getting Qt an OpenGL context.
[11:39] <jjohansen> that is quite a call chain, under older versions of apparmor you would have only see null-XXX where XXX is a unique number instead of the actual exec names
[11:40] <jjohansen> which was far less useful but did result in smaller names
[11:45] <zyga> jjohansen: thank you for the description!
[11:46] <zyga> dragly: there's no magic in snapd for opengl on intel, we don't bring any drivers form any other place, whatever the snap ships will run (or not)
[11:46] <zyga> dragly: all openGL situation nees love
[11:47] <ogra_> GL surely works on clasic with intel for me
[11:48] <zyga> ogra_: sure but my point is that it depends on hardware *and* snap
[11:48] <zyga> ogra_: snapd should use opengl indirection helpers and load the right driver
[11:48] <ogra_> well, i only ever try witrh the krita snap
[11:48] <zyga> ogra_: but nobody implemented that yet
[11:48] <zyga> ogra_: and snaps should not ship drivers
[11:48] <zyga> ogra_: (except for driver snaps)
[11:48] <zyga> ogra_: but now none of that is true
[11:48] <ogra_> i know that makes havy use of GL ... so if you can install and run that one there is *some GL*
[11:49] <ogra_> (used to work also on my nvidia desktop)
[11:49] <zyga> ogra_: as I said, there is whatever the snap author bundles
[11:49] <zyga> ogra_: snapd doesn't help
[11:49] <ogra_> yeah
[11:50] <ogra_> yay ... ok, one issue found with the gpg stuff
[11:51] <ogra_> (we dont bundle /var/lib/apt/keyrings in the tarball ...)
[11:51] <dragly> zyga: Then I don't understand how it works to build on Travis (in a Docker container) and my own machines and run on Nvidia machines afterwards, but not Intel.
[11:51] <ogra_> but even putting the right thing there doesnt fix apt :/
[11:51] <zyga> dragly: we have some special handling for nvidia
[11:51] <zyga> dragly: but it's neither generic nor particularly good
[11:52] <dragly> Oh, that explains. Thanks!
[11:52] <dragly> Are there any examples that I could look at (Krita?) that solve this manually either in the wrapper or by shipping GL drivers?
[11:52] <zyga> dragly: no idea really, I can tell you what we do
[11:52] <dragly> I don't mind doing it manually, I just don't know what to look for :)
[11:53] <zyga> dragly: but ideally someone should use libglvnd all the way
[11:53] <zyga> dragly: a snap that is linked so that it doens't link to particular things but to libglvnd
[11:53] <zyga> dragly: and contains all the drivers (as a hack / demo)
[11:53] <zyga> dragly: and can find the right one using libglvnd
[11:53] <zyga> dragly: later on the drivers can be removed from the demo snap and moved elsewhere (TBD)
[11:53] <zyga> dragly: and if connected via content should still work
[11:54] <zyga> dragly: (as in, give you the right driver while the snap with the application code has none)
[11:55] <dragly> so libglvnd is a wrapper for whichever GL lib is installed?
[11:56] <zyga> dragly: libglvnd is an emerging way to do GL in a sane way on linux
[11:56] <zyga> dragly: everything else is terrible
[11:56] <zyga> dragly: (and deployed) ;-)
[11:56] <zyga> dragly: but there are many parts missing
[11:57] <zyga> dragly: improvements in snapd for the automatic driver installation, kernel parts, mouting the driver for the snap to see, working with libglvd to do the right thing, etc
[11:57] <dragly> I see
[11:57] <zyga> dragly: also build system improvements
[11:58] <zyga> dragly: so when people build whatever snap they don't have to hand-hold it to do the right thing (not ship drivers but ship glvnd)
[11:58] <dragly> we really want to use snaps to package our applications, but it sounds like its going to be a lot of work at the moment. Maybe its better to consider alternatives and wait for an "official" solution?
[11:58] <zyga> dragly: on each distro the compiled userspace parts be shipped in blessed snaps
[11:58] <zyga> dragly: but the kernel parts are an open problem
[11:58] <zyga> dragly: you can just ship it the way everyone does (inside snaps) by bundling the zoo of FOSS userspace drivers
[11:59] <zyga> dragly: and relying on the magic ubuntu+nvidia enablement
[11:59] <zyga> dragly: we'll improve the situation with time but this is not something we're working on at the time
[11:59] <zyga> dragly: what I gave you was the bleak reality about how it must be done to work correctly but what people do is very useful despite not having those things
[12:01] <dragly> do you happen to know where I can find the zoo of userspace drivers to bundle? I suppose most of them are available through apt?
[12:02] <ogra_> libgl1-mesa-dri and libgl1-mesa-glx should have them
[12:02] <dragly> ogra_: great, and they go in as stage-packages, right?
[12:03] <ogra_> installing into /usr/lib/x86_64-linux-gnu/mesa and /usr/lib/x86_64-linux-gnu/dri
[12:03] <ogra_> (on amd64 that is)
[12:05] <ogra_> zyga, so i clearly verified it is the execution environment causing the gpg error, not something missing in teh tarball ... when unpacking an ubuntu-base tarball over the chroot env for the classic snap the error persists
[12:06] <ogra_> i'm now pretty sure it is related to the mknod
[12:07] <zyga> ogra_: how sure?
[12:07] <zyga> ogra_: can you replace the apparmor profile for classic
[12:07] <zyga> ogra_: to allow everything?
[12:08] <pstolowski> zyga, question to the hooks timeout problem - you metnioned https://github.com/zyga/snapd/tree/feature/debian-9-qemu ; why do i need that - because this is an old snapd?
[12:08] <ogra_> gimme a moment ... (just uninstalled it to get a clean env again)
[12:08] <zyga> pstolowski: because at that time you have snapd tree where this problem is trivial to reproduce and when you can use the only place that (non-tests) lets it happen easily (debian where we have seccomp but not apparmor)
[12:09] <zyga> pstolowski: you can test this with unit tests with greater ease
[12:09] <zyga> pstolowski: by just putting stuff into state the way 2.21 would do
[12:09] <zyga> pstolowski: and starting the manager
[12:10] <pstolowski> zyga, thanks. unit tests are tempting. i'm not sure what 2.21 would do though
[12:11] <zyga> pstolowski: just not add the timeout field AFAIR
[12:11] <zyga> pstolowski: it is in HookSetup
[12:19] <ogra_> zyga, ok, back in business ... how do i allow everything again ?
[12:25] <zyga> ogra_: edit /var/lib/snapd/apparmor/profiles for classic
[12:25] <zyga> remove everything there (or set it aside) and place...
[12:25] <ogra_> zyga, yeah, that bit i knowe :)
[12:25] <ogra_> (what do i need to put in, how do i regenerate)
[12:26] <zyga> ogra_: you load with "apparmor_parser -r /path/to/that/file"
[12:26] <zyga> ogra_: as for the contents
[12:26] <jdstrand> that path is already allowed
[12:26] <zyga> ogra_: keep the initial part
[12:26] <zyga> ogra_: and inside the {  }
[12:27] <jdstrand> wait
[12:27] <zyga> jdstrand: oh :)
[12:27] <jdstrand> that path should already be allowed
[12:27] <Chipaca> popey: you around?
[12:27] <zyga> ogra_: jdstrand can give you better advice
[12:27]  * zyga runs for lunch
[12:27] <jdstrand> well, probably not, but I may have more information
[12:28] <ogra_> http://paste.ubuntu.com/24516694/ is the current profile
[12:28] <jdstrand> perfect
[12:28]  * jdstrand looks
[12:29] <ogra_> (but i'm also running in --devmode anyway)
[12:29]  * jdstrand understands
[12:30] <jdstrand> @{SNAP_NAME}="classic"
[12:30] <nothal> jdstrand: No such command!
[12:30] <jdstrand> /var/snap/@{SNAP_NAME}/common/** wl,
[12:30] <jdstrand> /var/snap/classic/common/classic/tmp/fileutl.message.wopbff
[12:30] <jdstrand> right, yes, there is a rule for that
[12:31] <ogra_> well /var/snap/classic/common/classic/tmp/fileutl.message.wopbff is rather dynamically created
[12:31] <jdstrand> ogra_: what is the output of 'snap info <the name of the kernel snap>'?
[12:32] <ogra_> http://paste.ubuntu.com/24516706/
[12:32] <ogra_> jdstrand, this is for Bug #1670475 BTW
[12:32] <mup> Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475>
[12:33] <jdstrand> interesting that beta and candidate have newer revisions than edge
[12:33] <ogra_> i verified that nothing is missing in the classic chroot by simply using an ubuntu-base tarball inside that env ... it exposes the same issue
[12:33] <jdstrand> ogra_: yes, I read backscroll. thank you for looking into this btw
[12:33] <ogra_> jdstrand, yeah, i need to sync again ... i can swithc the board to beta if that helps ... (i doubt it though)
[12:34] <ogra_> kernel team only releases to beta and candidate ... edge is for tinkering
[12:34] <ogra_> (i.e. manual uploads)
[12:34] <jdstrand> ogra_: what are the permissions of /var/snap/classic/common/, /var/snap/classic/common/classic/ and /var/snap/classic/common/classic/tmp/?
[12:34] <jdstrand> hmm
[12:35] <jdstrand> yes, answer that, but, the fact that this says ALLOWED is wrong because the rule is in the policy
[12:35] <jdstrand> I think this is a complain mode denial bug
[12:35] <ogra_> http://paste.ubuntu.com/24516718/
[12:35] <jdstrand> s/is/may be/
[12:35] <jdstrand> ogra_: can you use -ld
[12:36] <ogra_> http://paste.ubuntu.com/24516723/
[12:37] <ogra_> also a "touch /tmp/foo" from inside the running chroot shows up fine as /var/snap/classic/common/classic/tmp/foo
[12:37] <jdstrand> right ok
[12:37] <jdstrand> I think this is a complain mode denial bug
[12:38] <ogra_> so the mknod will be denied while it shouldnt ?
[12:38] <jdstrand> ogra_: can you boot into the highest revision available? iirc, there were some fixes for this sort of thing
[12:38] <ogra_> sure
[12:40] <jdstrand> ogra_: the bug (I suspect) is that even though there is a matching rule in the policy (the one I pasted), there is a bug that the file access isn't matching the rule (which is why we see ALLOWED). there is a second bug (my theory) that even though we are in complain mode, the kernel is still denying it
[12:41] <jdstrand> ogra_: the fact that non-dragonboard kernels aren't seeing this gives support to a kernel bug
[12:41] <ogra_> jdstrand, all arm kernels see it now
[12:41] <jdstrand> but not amd64/i386?
[12:41] <ogra_> (note i'm on a pi3)
[12:42] <ogra_> i havent tried x86 ... you claimed in the bug i386 works
[12:42] <jdstrand> ogra_: well, at the time, but at the time armhf worked too
[12:42] <jdstrand> so maybe everything is broken
[12:43] <ogra_> HA!
[12:43] <ogra_> works !!!
[12:43] <jdstrand> we are getting into jj territory here, but I'd like to have a simpler reproducer
[12:43] <ogra_> crazy
[12:43] <jdstrand> ok, good :)
[12:43] <jdstrand> well, no, we had complain mode bugs that jj fixed :)
[12:43] <jdstrand> so, it sounds like the pi3 kernel needs those fixes too
[12:44] <jdstrand> iirc, pi3 is stuck due to boot image stuff
[12:44] <ogra_> before: http://paste.ubuntu.com/24516746/ ... after: http://paste.ubuntu.com/24516747/
[12:44] <ogra_> right
[12:44] <ogra_> pi's are all stuck
[12:44] <jdstrand> ok
[12:44] <jdstrand> so now we have triaged the bug
[12:44] <jdstrand> let me add a comment
[12:45] <ogra_> there is another issue (we dont keep the keyring around in the tarball) but i'll fix that one today
[12:45] <jdstrand> when the pi's are all updated with latest apparmor (I think I tried on bbb), they should be fixed
[12:47] <jdstrand> ogra_: you went to beta?
[12:47] <ogra_> yep
[12:48] <jdstrand> ogra_: oh, that is a pi2-kernel. ok
[12:48] <mup> PR snapcraft#1223 closed: kernel plugin: check_config() and check_initrd() support <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1223>
[12:49] <ogra_> well, pi kernel
[12:49] <ogra_> (it is identical for 2 and 3
[12:49] <ogra_> )
[12:56] <jdstrand> ogra_: I thought there was a forum topic on the boot/gadget/kernel issue. can you give it to me or a bug?
[12:57] <ogra_> one sec
[12:57]  * jdstrand couldn't find it
[12:57] <ogra_> https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap/70
[12:57] <ogra_> just a serach for gadget reveals it
[12:57] <jdstrand> oh, I did look at that
[12:57] <jdstrand> but I thought that was different. ok thanks
[12:57] <zyga> re
[12:57] <ogra_> jdstrand, it is also supposed to be a hot topic at the current sprint
[12:58] <mup> PR snapcraft#1294 closed: meson plugin: Add plugin for meson build system <Created by JulianLiu> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1294>
[13:03] <zyga> ogra_: standup
[13:03] <ogra_> zyga, yeah
[13:03] <zyga> morphis: you are welcome to join us if you have no conflicts
[13:06] <mup> PR snapd#3277 opened: cmd/snap, client: add "whoami" command <Created by chipaca> <https://github.com/snapcore/snapd/pull/3277>
[13:13] <mup> PR snapcraft#1296 closed: rust snaps can now use source-subdir without failing on pull <Created by roxyd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1296>
[13:13] <mup> Bug #1670475 changed: apt-secure complaints with classic snap on arm <Snappy:Invalid> <https://launchpad.net/bugs/1670475>
[13:24] <jdstrand> Chipaca: hey, saw in backscroll you needed me, but not sure from backscroll if you still need me (fyi, I commented on locale-control PR)
[13:29] <Chipaca> jdstrand: yes!
[13:29] <Chipaca> jdstrand: about _filedir
[13:29] <Chipaca> jdstrand: I'm pretty sure I addressed the biggest issue already
[13:30] <Chipaca> jdstrand: the only place it trips up now is from the outside in
[13:30] <Chipaca> (so there's some mis-quoting going on but i'll have to dig)
[13:30] <Chipaca> but for example if something has spaces I correctly get back things that backslash the space
[13:31] <Chipaca> ie “Screenshot\ from\ ”
[13:31] <Chipaca> jdstrand: could you take a poke and see if you see the same?
[13:31] <AdamH_> Gents, I have been watching the comments and can see the issue with apt-get requires a newer kernel. Is there a how-to or guide anywhere on how to update to a new one?
[13:32] <Chipaca> AdamH_: I think as long as you can reflash, yes
[13:32] <jdstrand> Chipaca: you updated the PR for this?
[13:32] <Chipaca> AdamH_: ogra_ knows more
[13:32] <Chipaca> jdstrand: 1 sec
[13:33] <Chipaca> jdstrand: there was a bug in compopt
[13:34] <Chipaca> jdstrand: https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd
[13:34] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[13:34] <Chipaca> jdstrand: actually https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd#diff-96d0d48e1bd095153ade81afdb99f7ebR85
[13:34] <AdamH_> Chipaca: Yes I can reflash if needed
[13:35] <jdstrand> Chipaca: ah, cool. ok. gimme a bit and I can take a look later this morning
[13:35] <Chipaca> jdstrand: ok lurvely
[13:35] <jdstrand> oh, heh
[13:35]  * jdstrand just looked at the commit
[13:35] <Chipaca> yeah
[13:38] <morphis> zyga: sorry, got back to late from my lunch break
[13:39] <zyga> morphis: no worries
[13:39] <popey> Chipaca: sorry, was afk
[13:42] <popey> Chipaca: if this is about the thread on forum about my sign on being broken, I can't reproduce it, unless IS nukes the password on my store account (that's how you reproduce it)
[13:42] <popey> e.g. get your password leaked somewhere and IS pro-actively help you :)
[13:52] <Chipaca> popey: so what's your password?
[13:53] <Chipaca> popey: is it ********
[13:57] <spineau> zyga: hi, I'm testing the ability to run other snaps commands from checkbox snap. That's amazing
[13:57] <zyga> spineau: hey
[13:57] <zyga> spineau: is it working ok? :)
[13:58] <spineau> zyga: with core from beta yes, we can call them
[13:58] <spineau> zyga: but I'm facing a limitation
[13:58] <zyga> yes?
[13:58] <spineau> zyga: for example I have a tpm2 command with a -o parameter to save something to a file
[13:59] <spineau> zyga: it seems that the only allowed location is SNAP_USER_COMMON
[14:00] <spineau> zyga: I'm not sure if there's a way to share data between snaps
[14:00] <zyga> spineau: aha, interesting point
[14:00] <zyga> spineau: if your test snaps have the home interface then you can connect it and just share data this way
[14:00] <spineau> zyga: but SNAP_USER_COMMON which works is the one for the tpm2 snap (not the one fro mcheckbox of course)
[14:01] <popey> Chipaca: indeed, hunter2 all the way
[14:01] <spineau> zyga: ok, I'll try that. thanks for the tip
[14:01] <zyga> spineau: there are other ways but I'd recommend against them until the (dreaded) update-ns feature is finished
[14:08] <kyrofa> Oh man, pachulo, you and I are on very different timezones :P . This conversation might be best on a new issue against the snap
[14:11] <kyrofa> pachulo, something is weird there: why is the php part pulling in python? Please log a bug against the snap, let me see the changes you're trying to make, and we can troubleshoot asynchronously there :)
[14:12] <kyrofa> pachulo, thanks for taking a crack at that bug!
[14:16] <AdamH_> ogra: How did you update the kernel on your rPi3 to resolve the apt-get issue?
[14:17] <zyga> AdamH_: you have to rebuild the image and reinstall
[14:17] <zyga> AFAIK
[14:18] <AdamH_> zyga: By rebuilding do you mean grabing the latest daily build and re-imaging?
[14:19] <zyga> AdamH_: I think so
[14:19]  * zyga didn't try
[14:19] <AdamH_> zyga: Thanks, will give it a go
[14:19] <zyga> AdamH_: we're working on fixing the root issue but it will still take a while to plan/schedule
[14:20] <AdamH_> zyga: Yes understood
[14:41] <ogra_> zyga, huh ?
[14:42] <ogra_> AdamH_, if you use a stable image there is no way ... if you use a daily/edge image: snap refresh pi2-kernel --beta
[14:42] <ogra_> that will switch you over to the beta kernel
[14:43] <ogra_> (do not run that on a stable pi image, it wont boot anymore)
[14:43] <ogra_> (well, it will roll back ... but never boot into the new kernel)
[14:46] <zyga> ogra_: hm?
[14:46] <ogra_> zyga, why would he need to rebuild
[14:48] <zyga> ogra_: I thought because to boot one needs to get a fresh image with edge kernel
[14:48] <ogra_> zyga, if you are on an edge image you can just switch channels for the kernel via refresh
[14:49] <ogra_> i do that all the time ... in fact i usually install a daily and then switch kernel to beta and core to stable after first boot ;)
[14:49] <ogra_> thats the current way to keep a pi up to date
[14:52] <zyga> ogra_: wait, I must be missing something; if I start on a stable image, can I use edge kernel/core?
[14:57] <ogra_> zyga, you cant use an edge kernel on stable, no (wont boot and just roll back) ... you can use the edge core on stable ... and you can use edge/beta/candidate or whatever you want to all packages on a daily image
[14:58] <ogra_> so it always depends what image you started from ... rebuilding anything wont gain you anything though
[14:58] <ogra_> (stable gadget only goes with stable kernel ... nothing else will boot)
[15:38] <pachulo> ok kyrofa , I will do that!
[15:47] <mup> Bug #1621745 changed: snapd package is missing dependency on grub-common for grub-editenv <Snappy:Fix Released> <Ubuntu Image:Fix Released> <https://launchpad.net/bugs/1621745>
[15:53] <mup> Bug #1534154 changed: BootAssetFiles have new "Dst" key that we should support <Snappy:Invalid> <https://launchpad.net/bugs/1534154>
[15:55] <zyga> jdstrand: hey
[15:55] <zyga> jdstrand: I have something, an experiment of afternoon friday hacking
[15:55] <zyga> jdstrand: I was wondering if snapd could do the resolving on seccomp profiles
[15:55] <zyga> jdstrand: so snap-confine could be easier and more portable
[15:55] <zyga> jdstrand: so I came up with a way
[15:56] <zyga> jdstrand: interested? :-)
[15:59] <jdstrand> I'm not sure how it would be more portable. if this is something you are going to be pushing for, yes I definitely want to discuss it. however, my friday is completely booked for non-experimental stuff, so perhaps next week?
[15:59] <jdstrand> zyga: ^
[16:02] <zyga> jdstrand: perhaps portable is less iteresting; the point is that it would be smaller and would change less often
[16:02] <zyga> jdstrand: yeah, this is a total RFC and idea
[16:02] <zyga> jdstrand: I'll catch you next week
[16:02] <jdstrand> cool, thanks
[16:02] <jdstrand> Chipaca: fyi, I haven't forgot you. I'll get there
[16:02] <jdstrand> forgotten*
[16:02]  * Chipaca steps back from the ledge
[16:03] <jdstrand> lol :)
[16:03] <Chipaca> :-)
[16:03] <Chipaca> jdstrand: I'm in a maze of twisted error messages, all different
[16:03] <Chipaca> jdstrand: not busy-waiting on you
[16:03] <jdstrand> ok cool
[16:03] <jdstrand> well
[16:03] <Chipaca> (but yeah i could do with landing that branch today, which i will do if you confirm what i found)
[16:04] <jdstrand> nice that you aren't waiting on me. not so nice about the twisty maze
[16:04] <Chipaca> jdstrand: that's ok, i get to use a type called "stringish"
[16:07] <zyga> Chipaca: what are you hacking on?
[16:08] <Chipaca> zyga: store
[16:08] <Chipaca> zyga: some responses from sso are not what we expect
[16:09] <Chipaca> zyga: have you figured out the test breakage
[16:12] <zyga> Chipaca: no, I should probably have a look at that ...
[16:13] <Chipaca> zyga: only if you haven't EOW'ed
[16:13] <zyga> no, not yet, still digging
[16:15] <cjwatson> elopio: doesn't look too difficult to sort out a git:// proxy in launchpad-buildd, so I'm working on that
[16:15] <cjwatson> among the nineteen thousand other buildd patches I have queued ...
[16:16] <zyga> fg
[16:16] <Chipaca> zyga: fg: current: no such job
[16:18] <zyga> are you saying I'm slacking ;)
[16:23]  * zyga runs spread
[16:23] <zyga> I wonder if it fails locally
[16:32] <zyga> Chipaca: oddly it built fine locally (in qemu)(
[16:32] <zyga> Chipaca: I'll try linode next
[16:49] <elopio> cjwatson: thanks! I think for my case I can install phantomjs from the deb, but last time I tried that it ended in a mess. I'll try again.
[16:54] <cjwatson> I have a juju tentacled monstrosity on my laptop to make it easier to test this stuff
[17:02] <Chipaca> zyga: yeah i tried to say 'it works for me' in the standup but google hated me just then
[17:12]  * zyga goes to pick up kids
[17:44] <Chipaca> zyga: did you kick off the tests on snapd#3275 again?
[17:44] <mup> PR snapd#3275: snap: move locale-control to only be present on classic <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275>
[17:46] <cjwatson> elopio: OK, I think I have this working locally \o/
[17:47] <cjwatson> just waiting to see exactly how far it gets, since running snap builds behind slow ADSL isn't the quickest of experiences
[17:47] <elopio> cjwatson: awesome!
[17:48] <elopio> cjwatson: I'm happy you are done with that one, because, I have another one :( https://build.snapcraft.io/user/elopio/ipfs-snap/35231
[17:51] <cjwatson> what the heck is gx
[17:53] <elopio> cjwatson: it's a go package manager on top of ipfs.
[17:53] <elopio> but I think that when you don't have ipfs, like in this case, it just uses http.
[17:55] <cjwatson> elopio: anyway, it's 7pm on Friday, I'm unlikely to get to it today; can you file a bug on launchpad-buildd?
[17:55] <cjwatson> I have a bunch of stuff queued up that may help, but I'd need to check it
[17:56] <cjwatson> (particularly my local-snap-proxy branch which means we stop having to worry about client-specific support for authenticated proxies)
[17:57] <elopio> cjwatson: sure. Thanks a lot, and enjoy the weekend.
[18:04] <elopio> https://bugs.launchpad.net/launchpad-buildd/+bug/1688624
[18:04] <mup> Bug #1688624: ipfs fails to build: no such host <launchpad-buildd:New> <https://launchpad.net/bugs/1688624>
[18:41] <zyga> re
[18:41] <zyga> Chipaca: looking
[18:41] <zyga> Chipaca: no, I don't think I did
[18:41] <zyga> Chipaca: did you figure anything out?
[18:45] <Chipaca> zyga: no, but it came up green
[18:46] <Chipaca> zyga: in fact both 3275 and 3277 are green in travis
[18:49] <zyga> Chipaca: wasn't me
[18:49] <zyga> maybe mvo fixed something?
[18:51] <Chipaca> zyga: ogra left for the weekend and turned off his break-everything-inator
[18:52] <Chipaca> zyga: ogra's surname is doofenshmirtz
[18:52] <zyga> lol :)
[19:03]  * zyga runs his locally built snapd
[19:04] <zyga> Chipaca: this is why snapd should not become init ;-)
[19:06] <Chipaca> popey: https://github.com/snapcore/snapd/pull/3278
[19:06] <mup> PR snapd#3278: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278>
[19:06] <mup> PR snapd#3278 opened: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278>
[19:15] <zyga> surprisingly nothing explodes!
[19:18] <jdstrand> Chipaca: commented
[19:18] <jdstrand> Chipaca: I think you are good to go
[19:26] <popey> Chipaca: yay
[19:28] <cratliff_> kyrofa:  Have you had to do anything with adding rules to rosdep while making a snap?  Would any packages pointed to by custom rosdep rules need to be made as a part in the snap?
[19:56] <zyga> some failures on the nice password policy error branch
[19:58] <zyga> Chipaca: commented on the PR
[21:29] <Chipaca> zyga: my bad, will fix
[21:31] <zyga> Chipaca: hard to guess
[21:32]  * zyga runs another spread run and EOWs
[21:32] <Chipaca> zyga: guessing is super easy!
[21:32] <Chipaca> i do it all the time
[21:33] <mup> PR snapd#3150 closed: In-snap bash tab completion <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[21:33] <Chipaca> ladies ^
[21:33]  * zyga claps
[21:33] <zyga> That's some fine work there mate!
[21:33] <Chipaca> that was a cow of a thing, glad it's on the other side :-)
[21:33] <Chipaca> now i need to write something up to explain it a bit
[21:34] <Chipaca> also, chase down bugs i'm sure. But first i've got branches to polish.
[21:34]  * mcphail wakes up. Wow. Cheers Chipaca
[21:34] <Chipaca> zyga: jdstrand: thank you :-)
[21:36] <zyga> Chipaca: I ended this week with a small experiment, https://github.com/zyga/snapd/tree/feature/typed-syscalls
[21:36] <zyga> Chipaca: works OK though not the full potential, the output is still rather ugly, I'll make it sort by interface so that it is nicer to look at
[21:37] <Chipaca> huh
[21:37] <zyga> ?
[21:39] <zyga> anyway
[21:39] <zyga> beer time
[21:39] <zyga> and tomorrow
[21:39] <zyga> farm!
[21:39] <Chipaca> zyga: multiple iotas
[21:39] <Chipaca> i'd always seen it written as a single thing
[21:39] <Chipaca> like, const ( Foo = FooClass(iota); Bar; Baz; Quux )
[21:40] <zyga> Chipaca: yeah, I think I wanted that without the many iotas but it didn't do the thing I expected
[21:40]  * zyga tries
[21:41] <zyga> ah, I'm drunk, it works ok
[21:41] <Chipaca> as long as the type is on the expression, it works
[21:42] <zyga> Chipaca: yep, pushed
[21:42] <Chipaca> if instead you do const ( Foo FooClass = iota; Bar; Baz )
[21:42] <Chipaca> then i think just Foo is FooClass, the others are just ints
[21:42] <zyga> Chipaca: this branch might arguably fix the dreaded hrsearch_r failed :)
[21:42] <zyga> hsearch_r *
[21:42] <Chipaca> :-)
[21:42] <zyga> as it does the hard work so that snap-confine can be ... dumb
[21:42] <Chipaca> zyga: you need to sit down with jdstrand tho
[21:43] <zyga> yes, I think he may dislike it
[21:43] <Chipaca> zyga: then sit down with him before falling in love with this too much :-D
[21:43] <zyga> but I wanted to do it anyway, to show that with some parsing the seccomp profiles can be better (nicer, sorted, de-duplicated, described, etc)
[21:43] <zyga> Chipaca: well, it's a friday thing :)
[21:43] <zyga> on the slower week
[21:44] <Chipaca> yeah
[21:44] <Chipaca> maybe i should've worked on the progress bar / terminfo thing
[21:44] <Chipaca> :-)
[21:44] <zyga> ohh
[21:44] <zyga> terminal stuff is my other love
[21:44] <zyga> that's for weekend tho
[21:44] <Chipaca> proper colour support is _terrible_
[21:45] <zyga> why?
[21:45] <zyga> are you kidding me?
[21:45] <Chipaca> no, no i'm not
[21:45] <zyga> one sec
[21:45]  * Chipaca is having a beer as well
[21:45] <zyga> Chipaca: super ancient stuff I never landed https://github.com/zyga/guacamole/pull/15
[21:45] <mup> PR zyga/guacamole#15: Add terminal awareness ingredient <Created by zyga> <https://github.com/zyga/guacamole/pull/15>
[21:46] <zyga> Just scroll :D
[21:46] <zyga> https://github.com/zyga/guacamole/blob/master/examples/rainbow.py is also fun to look at
[21:46] <jdstrand> I'm about to head out but I can say a couple of things, drop the mic, then leave. the hsearch_r things should be fixed now with reexec so long as you build snap-confine and snapd and copy both over. I'm not 100% sure this is going to work the way you want by dropping the snapd binary anywhere. but more importantly, it makes policy development difficult cause the policy writer has to figure out the number to put in the policy
[21:47] <jdstrand> most importantly, snap-confine can't be that dumb and will have to parse at least some things
[21:47] <jdstrand> eg, the current real and effective user (for the user/groups branch I'm working on)
[21:47] <zyga> jdstrand: no, it's still optional; the way I made it it could even fail at build time (loudly) but now just gets forwarded to snap-confine as-is
[21:47] <zyga> jdstrand: sure, I know and I agree
[21:48] <zyga> jdstrand: I think I wanted to do this to make the generated profiles nicer
[21:48] <jdstrand> well, if you are trying to make snap-confine dumb, then it won't be optional
[21:48] <zyga> jdstrand: dumber, not fully dumb
[21:48] <zyga> jdstrand: it will not need a lot of those maps
[21:48] <zyga> jdstrand: but anyway, this is a secondary goal, I really wanted to make profiles more readable
[21:48] <zyga> jdstrand: right now they are a bit... well, mashed up
[21:49] <jdstrand> I don't like the sort either
[21:49] <zyga> jdstrand: (and FYI, I'm not fully happy with the output now, but it is better than before)
[21:49] <jdstrand> we want comments inline with the rules that are there
[21:49] <jdstrand> plus, the map stuff doesn't really look any prettier to me than then C
[21:49] <zyga> jdstrand: those stay
[21:49] <zyga> http://paste.ubuntu.com/24519406/
[21:50] <zyga> jdstrand: (this is still with relatively naive output, it can look nicer still)
[21:51] <jdstrand> I don't see how that output is any better... I see a bunch of comments explaining what you mapped to
[21:51] <zyga> jdstrand: mainly by keeping the flow of snippets, adding headers "# this is what interface FOO added:" etc
[21:51] <jdstrand> that is fine
[21:51] <zyga> jdstrand: the previou output was worse as it was totally (crappily) sorted on huge multi-line strings
[21:51] <jdstrand> but that is supposed to be at the top of the snippets for each interface anyway
[21:51] <jdstrand> anyway, I gotta go
[21:51] <zyga> jdstrand: oh, and one more thing, I didn't do it in this branch but the # description stuff really should not live in snippets
[21:52] <zyga> jdstrand: o/ enjoy the weekend, see you next week :)
[21:52] <jdstrand> you too! :)
[21:55] <Chipaca> wrt colour support being terrible, there is no good way of detecting whether a terminal supports 16M colours
[21:55] <Chipaca> terminfo have said they won't support it at all
[21:56] <Chipaca> and of the terminals that support it, they only support it from a certain version on (if compiled with the right flags), and only VTE exposes something you might use to guess (the VTE version)
[21:56] <Chipaca> so, you say, no problem, ignore 16M colours and use the paletted 256 colour support
[21:56] <Chipaca> which is much more prevalent, and detectable (terminfo knows)
[21:57] <Chipaca> but, but, it's a palette, and in some but not all terminals it's a _modifiable_ palette. And some of the terminals that let you modify it let you query it (in a horrible horrible way that involves termios things to read it back), but not all
[21:58] <Chipaca> so there's absolutely no sane way of saying "make this text be of colour #c0ffee"
[21:58] <Chipaca> you can say "make this be colour #2"
[21:59] <Chipaca> which will be something blue, or green, depending, but only if the user hasn't changed it to something else
[21:59] <zyga> Chipaca: yeah; hence I did the insane, locally see which terminal emulator is used ;D
[22:00] <zyga> Chipaca: but actually most things support the 16M colors fine
[22:00] <zyga> Chipaca: and the rest, well, screw that stuff
[22:00] <Chipaca> zyga: the problem is that some of the stuff that _doesn't_ is actually important
[22:00] <Chipaca> like, screen ant tmux
[22:00] <zyga> Chipaca: it's also compound by the fact that multiplexers and even ssh can make stuff crazy
[22:00] <zyga> Chipaca: ha, I know :)
[22:00] <Chipaca> heh, see :-)
[22:00] <zyga> Chipaca: I have a secret plan for that tho :)
[22:01] <zyga> Chipaca: long standing desire to fix that properly
[22:01] <Chipaca> so, I'm probably going to write something called schmerminfo
[22:01] <zyga> what would that do?
[22:01] <Chipaca> (it's half written in my head already)
[22:01] <Chipaca> zyga: be a very opinionated thing that does the same sort of thing as terminfo does, but just for the stuff i care about
[22:02] <Chipaca> alternatively i could make it fall back to terminfo (i mean, i already wrote _that_ one in go :) )
[22:02] <Chipaca> and just sprinkle colour magic on top
[22:02] <Chipaca> OTOH, i don't need all terminfo
[22:02] <Chipaca> so ...
[22:02] <zyga> Chipaca: how would the API look like?
[22:02] <Chipaca> it's there at the back of my head percolating
[22:03] <Chipaca> zyga: I've tried something like the terminfo api, and it's pretty nasty
[22:03] <Chipaca> zyga: so I'll be looking at doing something fmt-ish next, see how that one feels
[22:03] <zyga> Chipaca: yeah, I think that's the right intuition
[22:04] <zyga> Chipaca: I tried it myself too earlier and anything heavier or more typed was too annoying to use
[22:05] <Chipaca> anyway, that's backburner stuff for me
[22:05] <zyga> Chipaca: btw, the guacamole thing I linked to has one fun element: colorblind mode
[22:05] <Chipaca> and it's got so many branches, it never ends
[22:05] <zyga> Chipaca: lets you run your app with color emulation to see how specific kind of colorblindness might be perceived
[22:05] <Chipaca> zyga: ah, i'll look at that sometime then, as that was on my mind also
[22:06] <Chipaca> zyga: one of the branches of this problem space (i.e., "make progress bars pretty and functional") was progress bar for transformative io
[22:06] <zyga> Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py
[22:06] <Chipaca> ie a progress bar for decompressing something
[22:06] <Chipaca> where it tells you what it's read, and what it's decompressed
[22:06] <Chipaca> (or compressed)
[22:06] <zyga> Chipaca: I recommend you to look at RHEL 7 bootup
[22:07] <zyga> Chipaca: the progress bar is totally pretty
[22:07] <Chipaca> zyga: the textmode one?
[22:07] <Chipaca> haven't seen that
[22:07] <zyga> Chipaca: or any opensuse/fedora thing that boots in text mode
[22:07] <zyga> Chipaca: more crazy and fun stuff: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L404
[22:07]  * zyga loves verbose python
[22:08] <zyga> https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L500
[22:08] <zyga> some more craziness: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L635
[22:08] <Chipaca> zyga: guacamole seems to ignore the whole "paletted terms change their colours" thing :-)
[22:08] <zyga> https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L769
[22:09] <zyga> :D
[22:09] <zyga> Chipaca: ah, no
[22:09] <zyga> Chipaca: well
[22:09] <zyga> Chipaca: there are sets that change
[22:09] <zyga> Chipaca: and there are sets that don't change
[22:09] <AdamH_> Gents, I have a mir-kiosk app that builds and runs fine on Ubuntu core running in KVM but I get the following error when built using classic snap on rPi3 - mirserver: Rejected and disconnected a client (Unsupported protocol version) Any idea where the mirserver logs are? Trying to debug
[22:09] <zyga> Chipaca: if the programmer asked for a specific color then I use those that don't change
[22:09] <zyga> Chipaca: if you asked for symbolic indexed 8 element palette then those change
[22:09] <zyga> Chipaca: but...
[22:09] <zyga> Chipaca: bare with me :-D
[22:10] <zyga> Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L302
[22:10] <zyga> Chipaca: I also try to know what they were by default
[22:10] <zyga> Chipaca: I also looked at how I can ask the terminal for the real values at runtime
[22:10] <Chipaca> AdamH_: looks like your mir server and client have different libmirclients
[22:10] <zyga> (guacamole was more of an experiment to explore colors than practical tool)
[22:11] <zyga> Chipaca: this is fun because you can use gnome-terminal with guacamole to ask how your application would render on putty (color accurate) or apple's terminal emulator
[22:11] <AdamH_> Chipaca: Thanks, is there a quick way to tell?
[22:11] <zyga> Chipaca: using the right color mixer you can get that output
[22:11] <zyga> Chipaca: guacamole has one big flaw though, it is a python library, not something universal
[22:11] <zyga> Chipaca: slowly, I'm building a universal solution
[22:11] <Chipaca> zyga: nice
[22:12] <Chipaca> AdamH_: I'm not sure; check the soname?
[22:12] <zyga> Chipaca: where it is more like modern graphical stack than terminal stuff, but we'll see :)
[22:15] <AdamH_> Chipaca: Not sure what soname is, but you have given me something to read up on thanks
[22:16] <zyga> Chipaca: anyway, I'll think I'll stop typing now, enjoy your weekend :)
[22:18] <Chipaca> zyga: way ahead of you :-)
[22:38] <mup> PR snapd#3275 closed: snap: move locale-control to only be present on classic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3275>


[03:07] <Nacho> Hello
[03:07] <Nacho> help
[03:08] <Nacho> Need Help!
[03:10] <hyperair> /j #ubuntu.
[03:11] <Nacho> I need to unban
[03:11] <hyperair> oh
[03:11] <Nacho> I'm banned
[03:11] <hyperair> why are you banned?
[03:11] <hyperair> and unban from where?
[03:12] <Nacho> No cause
[03:12] <hyperair> what channel/nick?
[03:12] <Nacho> Channel: Ubuntu-es
[03:13] <Nacho> I'm banned from # ubuntu-es
[03:13] <hyperair> nickname?
[03:13] <Nacho> my nickname?
[03:13] <hyperair> it doesn't look like you're banned though
[03:14] <Nacho> view: == #ubuntu-es Cannot join channel (+b) - you are banned
[03:16] <hyperair> guampa tells me you've been disruptive there.
[03:17] <Nacho> But I did not!
[03:17] <guampa> Nacho wasn't willing to stop using caps, insulting other users and filling the channel with offtopic
[03:18] <guampa> i warned him many times, both in the channel and in private
[03:18] <Nacho> Sorry I left'm an airhead issue
[03:18] <guampa> even now he isn't willing to understand
[03:18]  * hyperair shrugs.
[03:19]  * hyperair goes back to eating breakfast
[03:19] <Nacho> I understand but not referred to understanding What is the meaning to understand!
[03:20] <guampa> Nacho: i think it's better you take the night time off and come back tomorrow eh? more calm
[03:20] <hyperair> guampa: was Nacho under a different irc handle before?
[03:20]  * hyperair doesn't see anything in the logs
[03:20] <guampa> yes, Ignacio
[03:20] <hyperair> aah
[03:20] <Nacho> Sorry
[03:21] <Nacho> If I take the night to think
[03:23] <Nacho> guampa: ping
[03:23]  * Nacho GUAMPA NO PENSE QUE ERAS ASI´!
[11:46] <Ignacio_> Hi
[11:46] <Ignacio_> need help
[11:47] <Tm_T> Ignacio_: hi, it would help if you would state the issue
[11:47] <Ignacio_> I need to unban
[11:48] <Ignacio> please
[11:49] <Tm_T> Ignacio: unban from which channel? and all related details of the ban would help too (:
[11:52] <Ignacio_> Yesterday I was very wrong in the ubuntu-channel
[11:53] <Ignacio_> need help
[11:53] <Ignacio_> please!!
[11:53] <LjL> Ignacio_: if it was #ubuntu, then please ask in #ubuntu-ops instead
[11:54] <Ignacio_> ubuntu-es
[11:54] <LjL> ah
[11:54] <Ignacio_> hablas español?
[11:55] <Ignacio> LjL: Speak spanish
[11:55] <LjL> un poquito
[11:55] <Ignacio> me desabenarias?
[11:56] <LjL> Ignacio: verdademente no puedo hacer eso, tienes que espechar a el operador que te ha banado
[11:59] <LjL> nachito: verdademente no puedo hacer eso, tienes que espechar al operador que te ha banado
[11:59] <nachito> es guampa
[12:01] <nachito> Ljl: Que canales le pertenecen?
[12:02] <LjL> soy operador en #ubuntu y #ubuntu-offtopic. en #ubuntu-es tengo +o pero no he sido allí de recente, no seria justo por mi de remover los bans de otros operadores
[12:08] <LjL> el taimàut del ping


[09:57] <qense> hello
[16:40] <qense> hello
[19:37] <mdke> ryanakca: the ~ubuntu-website team is currently bug supervisor for the kubuntu-webite project in Launchpad. Would it make sense to change that to the ~kubuntu-website team? I can't really do anything with kubuntu-website bugmail
[19:38] <ryanakca> mdke: most likely, I would, but I don't have any powers to change it...
[19:38] <ryanakca> mdke: who do I poke? Riddell?
[19:38] <mdke> ryanakca: I'm sure we can find something who can, hang on
[19:39] <mdke> ryanakca: yes, Riddell
[19:39] <ryanakca> *nod*, thanks :)
[19:39] <mdke> :)
[19:47] <thorwil> newz2000: https://wiki.ubuntu.com/Website/IntrepidCountdownBanners?action=AttachFile&do=get&target=tw_intrepid_countdown_04_spiral.png
[19:48] <thorwil> newz2000: you are not subscribed to that wiki page, right?
[19:48] <nand> thorwil: eh, nice countdowns :)
[19:48] <thorwil> nand: thanks
[19:49]  * thorwil heads to the shower to be back in a bit
[19:49] <mdke> wow, beautiful
[19:49] <nand> like the #2 series, especially the #2C
[19:49] <mdke> I like #A
[19:50] <Volans> thorwil: great job! Maybe having 2 series also for K/Xubuntu ?
[19:50] <mdke> thorwil: but the circling dots may be interpreted as ripping off the Debian logo a little bit, which might cause problems
[19:50] <Volans> so the users that will put the banner in their site can choose the "theme"
[19:51] <nand> mdke: this didn't struck me as a debian logo
[19:52] <mdke> nand: no, it's not identical. But it is close enough that it will strike some people
[19:52] <nand> well, if it's also some publicity for debian, it's even better :)
[19:53] <mdke> nand: I don't think that would be a possible effect. But we might get a few debian people complaining
[19:53] <Volans> also the "hand" series is very good for me
[19:54] <nand> I don't see why they would complain...
[20:20] <thorwil> thank you, mdke
[20:24] <thorwil> leaving out everything where a few people might complain would leave us with a white canvas ^^
[20:51] <mdke> thorwil: true, but we can also be sensitive to particular issues which affect our community
[20:53] <thorwil> well, the debian swirl faces the other direction. i wouldn't let them have sole rights to a spiral, anyway ;)
[21:03] <thorwil> good night!
[21:21] <ryanakca> Could someone with a pile web browsers help me test a few fixes to the kubuntu.org theme?


[11:22] <skull> hi
[11:23] <skull> gb
[04:31] <jetsaredim> how do I get the sun java plugins working in firefox?
[04:32] <jetsaredim> I know I have the sun jdk/jre 1.6 package installed, but for some reason I can't get firefox to recognize it
[04:32] <man-di_> jetsaredim: aptitude install sun-java6-plugin
[04:33] <jetsaredim> just ran that and like I said - its already installed
[04:33] <jetsaredim> I also tried using the config selection tool to change my system java to sun
[04:33] <jetsaredim> but that didn't seem to work either
[04:34] <jetsaredim> any suggestions on where to start with this?
[04:34] <jetsaredim> I really need a more recent java plugin than the blackdown one
[04:37] <man-di_> are the alternatives for the plugin pointing to the sun java6 plugin?
[04:37] <jetsaredim> o wait
[04:37] <jetsaredim> i just checked about:plugins
[04:37] <man-di_> jetsaredim: the problem is when you install several java runtimes the alternatives might get confused
[04:38] <jetsaredim> ok - so how do I get rid of the non-sun java runtimes
[04:38] <jetsaredim> about:plugins is showing both blackdown and sun
[04:40] <jetsaredim> i can just remove the j2re1.4 blackdown package right?
[04:40] <man-di_> when no other package on your system depend on it
[04:41] <man-di_> a probably better way is to use update-java-alternatives
[04:41] <man-di_> to set the sun java6 as defualt java runtime
[04:41] <jetsaredim> java-1.5.0-sun 53 /usr/lib/jvm/java-1.5.0-sun
[04:41] <jetsaredim> java-6-sun 63 /usr/lib/jvm/java-6-sun
[04:44] <jetsaredim> hmm
[04:44] <jetsaredim> i just got rid of the blackdown jre through adept
[04:44] <jetsaredim> nothing seems to depend on it
[04:44] <jetsaredim> other than the plugin
[04:52] <jetsaredim> a ha
[04:52] <jetsaredim> stupid stale pluginreg
[04:52] <jetsaredim> nevermind
[04:52] <jetsaredim> thanks for the suggestions tho


[03:14] <Rod_J> Is UbuntuOne available in Kubuntu?
[03:17] <Rod_J> OK ... found my answer here: https://wiki.ubuntu.com/UbuntuOne/FAQ/DoesUbuntuOneSupportKDE
[06:19] <sagaci> hi, I'm currently using ubuntu one on my android phone to download an album, it's about 100MB over WiFi, is there any way to check the status of the download to see how far it's through?
[18:01] <tntc> what's the deal with the playlist thing for android?
[18:04] <tntc> If it's a server issue, can I have my account deleted and recreated or something?
[18:04] <karni> tntc: Let me see if it works here.
[18:04] <tntc> I just tested it. Supposedly only SOME users are affected.
[18:07] <tntc> It's happening on two different android devices for me.
[18:07] <karni> tntc: First of all, hi! Could you please describe what exactly doesn't work for you?
[18:08] <tntc> oh! XD yeah, that might be good. Hi karni :)
[18:08] <karni> hi tntc :)
[18:08] <karni> Sorry to hear about the problem. I'd like to help.
[18:08] <karni> I'm logging into the U1M app right now.
[18:09] <tntc> Well, when I attempt to save a playlist on either of my android devices, it says "Saving playlist <Whatever name I gave it>", then it gives me an error: "Failed to save playlist, please try again later. A network error occured. Try again later."
[18:10] <karni> tntc: Thank you for the details. CardinalFang_, I've got two issues here. Not sure if you're here on Sunday.
[18:11] <karni> CardinalFang_: 1) first one has been described here by tntc
[18:11] <tntc> karni: It's been like this for a few months.
[18:11] <karni> CardinalFang_: 2) I can't reproduce the problem, because I can't log in to U1M (!!!?). SSO has been deployed recently to production. CardinalFang_ / beuno , could you please log out of U1M, and try logging in?
[18:12] <karni> tntc: ouch, I'm sorry to hear that. Have you installed Ubuntu One Music from the Android Market?
[18:12] <tntc> karni: yup!
[18:12] <karni> tntc: I did save playlists recently, with success. That's why ↑ I'm asking about this.
[18:12] <tntc> karni: I tried uninstalling and reinstalling the app just yesterday, still no dice.
[18:12] <tntc> Is there an apk I can just download and try?
[18:13] <tntc> a beta or something?
[18:13] <karni> tntc: It might be the case you're affected by a particular issue, that others aren't. It would be best for you to come tomorrow (Monday), or any other work day (Mon-Fri) and ask rye and CardinalFang_ about this. Maybe it's something with your Couch database.
[18:14] <karni> tntc: Not really. I mean, even if there was, the version from the Market should work (and did work). So perhaps it's just your and few other people.
[18:15] <karni> tntc: I feel bad that I can't help much, but I can't even log in to U1M, which is pretty scary, so I'll make sure to ping devs about this asap.
[18:16] <karni> tntc: I'd appreciate if you'd drop by in week minus {Saturday, Sunday}, and we could work on your issue.
[18:16] <tntc> where can't you log in to? Can I try?
[18:16] <tntc> karni: I absolutely will. is there a particular time of day? I work 9-5 EST
[18:17]  * karni checks timezones
[18:17] <tntc> (UTC -4/5)
[18:18] <tntc> New York TZ, if that helps
[18:19] <karni> tntc: after your work should be fine :)
[18:19] <tntc> ok, good!


[05:14] <ppisati> moin
[07:55] <ppisati> smb: morning
[07:56] <smb> ppisati, apw, morning
[08:13] <apw> smb, moin
[08:13] <apw> ppisati, morning
[08:13] <ppisati> apw: hi
[08:13]  * ppisati feels hungry again...
[09:36] <ppisati> brb
[09:39] <ara> hello
[09:39] <ara> maybe someone should be looking at this bug? https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1229611
[09:40] <ara> it looks like the apport hook for linux-lts-raring does not exist
[09:48] <apw> ara thanks for the heads up
[09:49] <ara> apw, np
[10:13] <ppisati> infinity: you need to add 'generic-lpae' to the Calxeda Highbank entry in flash-kernel/db/all.db
[10:14] <ppisati> infinity: since we switched from parsing /proc/cpuinfo to device-tree (/proc/device-tree/model)
[10:14] <ppisati> infinity: some entries have a different string id
[10:14] <ppisati> ubuntu@m00:~$ sudo flash-kernel
[10:14] <ppisati> Kernel suffix generic-lpae does not match any of the expected flavors (generic highbank), therefore not writing it to flash.
[10:14] <ppisati> ubuntu@m00:~$ cat /proc/device-tree/model
[10:14] <ppisati> Calxeda Highbankubuntu@m00:~$
[10:15] <ppisati> infinity: and yes, it's a midway box
[10:15] <ppisati> infinity: problem is that, this way, we can't distinguish between ecx1000 and ecx2000 now
[10:16] <ppisati> infinity: uhm...
[10:32] <ppisati> but do we care in some install an lpae kernel on a non-lpae hw? do we have any seat belt implemented on x86 for this kind of scenario? i think we should follow the same path...
[10:32] <ppisati> infinity: ^
[10:32] <ppisati> and with that said,
[10:32]  * ppisati -> off for a bit
[11:18]  * apw idly wonders how the heck we coped before VMs
[11:21] <ogra_> manpower
[11:22] <ogra_> lots of
[11:22] <apw> ogra_, heh perhaps so ... perhaps so
[14:51] <jsalisbury> **
[14:51] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:51] <jsalisbury> **
[14:55] <rtg> apw, pushed unstable, looks like its gonna build. I disabled overlayfs and lttng for FTBS (and dropped VESA modularization until I can fix it)
[14:55] <apw> rtg, ack
[16:07] <infinity> ppisati: No, we don't want that.  We want Calxeda to release their proper firmware that stops lying and pretending that Midway is Highbank.
[16:08] <ppisati> infinity: fine for me
[16:08] <infinity> ppisati: All the testing I've been doing on Midway for them involved a uboot fdt hack to fix the model.
[16:08] <infinity> ppisati: As instructed by Rob.
[16:08] <infinity> ppisati: I'm told their new firmware will happen this week.
[16:10] <robher> infinity, ppisati: why don't you look at capability flags indicating lpae is supported or not.
[16:11] <infinity> robher: Because that would be yet another mangling/rewrite of what flash-kernel does, a bit late in the cycle.
[16:11] <robher> model is a bad thing to look at to begin with. OEMs could put whatever crap they want there.
[16:12] <infinity> robher: But, sure, in the ideal utopia where all the kernels we carry are generic and generic-lpae, and no subarches matter anymore, that would be the sane thing to do, and we can scrap all this mess.
[16:13] <infinity> robher: I was told you guys are releasing your new firmware that stops pretending midway is highbank so, at least for you, this will be solved this week.
[16:14] <robher> infinity: yes that is right.
[16:14] <infinity> robher: For the bigger picture, I agree it's all a horrible mess, due to ARM's history of being horrible and messy, but we're not rewriting and solving all of that for this cycle.
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[19:04]  * rtg -> lunch


[00:06] <akgraner> :-/ yep
[00:07] <elky> There's a special place in the deepest reaches of hell reserved for that man.  First time I ever read anything from him and I am not familiar with Jono's comments or elky's blog post Sam is referring to. Seems to me like he is probably a jackass
[00:25] <elky> he's really no more a journalist than roy schetzowitz is. these days, his research is approximately on par quality wise.
[00:26] <valorie> :(
[00:26] <valorie> hopefully people ignore the acid
[00:26] <valorie> anyway, dinner.....
[00:27] <elky> if you go through his other writings, you can find the piece last week in which he decreed lucid unfit because "sudo apt-get update && apt-get upgrade" complained about lack of root for the second part of that command.
[00:28] <IdleOne> well if he understood what && does he may not complain
[00:29] <elky> he blamed the man pages for lying to him iirc
[00:29] <IdleOne> && if and when and only when the previous command completes run following command
[00:30] <IdleOne> the following command being an sudo command should ask for auth imho
[00:30] <IdleOne> s/an/a
[00:31] <elky> yes, but that's not how "ive been using debian for fifty million years" genius boy interpreted it.
[00:32] <elky> (*not actually real quote, but sure as heck real attitude)
[00:32] <elky> anyway, i'm tired of talking about him, lets move on
[00:32] <IdleOne> elky if I was you I wouldn't waste any more energy on it.
[00:32] <IdleOne> heh
[00:32] <IdleOne> you type faster then I do :P
[00:33] <IdleOne> ok 3 things left to do today: 1) call the kids 2) eat something 3) go to sleep
[00:33] <IdleOne> I'll be back later :P
[04:54]  * pleia2 hugs elky
[05:07] <elky> pleia2, speeeecial place in hell for that guy, srsly.
[05:08] <pleia2> yeah, I don't think anyone takes him seriously anymore
[05:09] <elky> my response to him was intended to make him seem as jackassy as possible, since I /knew/ he was going to do this.
[05:10] <elky> hence it was not a plead, it was a stern directive.
[05:10] <valorie> once he gets predictable, he'll lose readers even with his pot-stirring
[05:11] <elky> oh, he's been losing readers since he before he lambasted the intern that swore in a blog post in the direction of stallman
[05:12] <elky> and his recent outburst at matt garrett for quoting him... hilarious
[05:12] <elky> but srsly, his best so far has to be the sudo gaffe late last week
[05:12] <rww> I rarely see positive things in the comments on his articles. He doesn't have readers because people think he's a good journalist, he has readers because he generates controversy.
[05:13] <rww> elky: His reply in the article's comments makes no sense :(
[05:13] <elky> oh, he has a few fans. one tried to use my blog comments to spamzor his own blog around
[08:11] <dholbach> good morning
[09:51] <AlanBell> elky: http://www.theopensourcerer.com/2010/02/15/sam-varghese-got-it-wrong/ different subject, same trollumnist
[10:05] <elky> <3 adam williamson's response
[10:05] <elky> i want one of those tshirts
[10:05] <elky> i also belong to the elusive club that's also been trollumnist'd by sam's colleague
[10:06] <rww> "Varghese trolled me for ad money and all I got was this lousy t-shirt"
[14:16] <maco> elky: and directhex's comment?
[14:17] <elky> maco, yeah, but i see him say that in the actual site comments all the time
[14:18] <maco> haha
[14:36] <czajkowski> maco: nice link the other day
[14:36] <maco> czajkowski: the ireland link?
[14:37] <czajkowski> aye
[15:45] <akgraner> Woo Hoo new wireless card and now my computer can connect anywhere in my house - now if lightning doesn't take out the wifi receiver again this sound be a good day! :-)
[15:46] <nigelb> akgraner: great :)
[15:47] <akgraner> it's those little things in life that make me happy :-)  me gets back to my todo list - UW list will have about 5 emails hitting in about an hour  - finally - caught up :-)
[16:45] <akgraner> hey who all on the on the UW team is participating in a global Jam event?
[16:46] <nigelb> akgraner: depends, I'll be on IRC to help anyone who needs help
[16:47] <pleia2> I will be
[16:48] <MarkDude> I will at Jono's event.
[16:49]  * pleia2 has to work that day
[16:50] <pleia2> it being a weekday and all :)
[16:50] <pleia2> but I'll wander up to the berkeley one
[16:50] <akgraner> I was just thinking outload and before I took it to the list wanted to brainstorm  - maybe we as a team could pick an hour or so and hold an online jam?
[16:51] <nigelb> +
[16:51] <nigelb> +1
[16:52] <MarkDude> akgraner, some people are a little standoffish on bugs, but , maybe can help with trnslation. At least for Karmic, that language stuff was down the list
[16:52] <akgraner> I was thinking docs and we could clean up and add to our wiki's and stuff  - but that's just me
[16:53] <MichelleQ> Mike and I were just discussing Global jam
[16:54] <MichelleQ> I think we're going to be hosting a doc. jam, but I'm not 100% sure when
[16:54] <MarkDude> I have a small amount of moin skills & am willing to help with that
[20:25] <Pendulum> akgraner: did I just read correctly that our blueprint is done?
[20:25] <akgraner> yeppers
[20:25] <Pendulum> \o/
[20:25] <Pendulum> just in time to start discussing the next one, eh? ;-)
[20:26] <pleia2> hooray! :)
[20:26] <akgraner> yeppers :-)
[20:26] <akgraner> got stick some stuff on a wiki then send out the email :-)
[20:27] <Pendulum> btw, I'm sorry that I have failed to actually do my action item from the last meeting. have barely been able to use my right shoulder most of the time since :(
[20:27] <pleia2> mentoring docs
[20:27] <pleia2> ?
[20:27] <akgraner> Pendulum,  no worries :-)
[20:28] <pleia2> I can jump in and help out more
[20:28] <Pendulum> pleia2: yeah
[20:28] <pleia2> I should have some time tomorrow evening to get a plan together if you'd like
[20:28] <Pendulum> pleia2: possibly (depending on what sort of shape I'm in)
[20:29] <pleia2> no problem, if you're not available I'll just toss my ideas in an email and we can go from there :)
[22:19] <pleia2> regarding t-shirts, this was created a while ago: http://wiki.ubuntu-women.org/Ideas/TShirtDesigns
[22:38] <nhandler> pleia2: You might want to update the design to fit in with the new theme a bit more
[22:38] <pleia2> none of these are my designs :) they are from last year
[22:39] <nhandler> Ok
[22:39] <pleia2> was just a suggestion as a starting point for continued discussions
[22:58] <czajkowski> http://wiki.ubuntu-women.org/Roadmap-M here is the suggested items for the next cycle. We can work on these at the next IRC Meeting
[23:03] <MichelleQ> czajkowski: Area 4 is "Mentioning Program"...
[23:03] <MichelleQ> erm...  what might that be, 'zactly
[23:03] <MichelleQ> ?
[23:04] <pleia2> Mentoring?
[23:04] <czajkowski> aye
[23:04] <czajkowski> mentoring
[23:05] <MichelleQ> k.
[23:05] <czajkowski> fixed
[23:05] <czajkowski> done
[23:05] <MichelleQ> :D
[23:05] <MichelleQ> You're fantastic!
[23:05] <czajkowski> hah
[23:05] <czajkowski> no
[23:06] <pleia2> yes you are, darn it! :)
[23:06] <MichelleQ> oh, sure you are.
[23:07] <pleia2> oh, I guess that should have been "dang"
[23:07] <pleia2> I fail at akgranerspeak
[23:07] <czajkowski> lol
[23:08] <MichelleQ> rofl.
[23:08] <MichelleQ> pleia2: need some drawl lessons?
[23:08] <pleia2> I think so! :)
[23:12] <czajkowski> NN nutters
[23:12] <MichelleQ> NN nutters?
[23:12]  * MichelleQ blinks in confusion
[23:14] <akgraner> hehe
[23:15] <MichelleQ> oh, I need a nap.
[23:16] <akgraner> me too!
[23:16] <MichelleQ> See y'all in a bit - we're off to bathe children.
[23:17] <akgraner> Updated Agenda for next UW meeting - http://wiki.ubuntu-women.org/Meetings/March2010/Agenda
[23:18] <akgraner> it's needs cleaned up a bit - but that is the easy part :-)