[07:49] <zyga> o/
[08:33] <davidcalle> didrocks: hey, can you have a quick look at https://github.com/ubuntu/snappy-playpen/pull/11 ? Thanks :)
[08:34] <didrocks> davidcalle: can you expand a little bit what you are trying to fix?
[08:35] <didrocks> ah, the Testing atom/parts/plugins
[08:35] <didrocks> because we have a custom plugin
[08:35] <didrocks> so subdir
[08:36] <didrocks> davidcalle: I think that can be done maybe in an easier way (don't like the double xargs)
[08:38] <davidcalle> didrocks: sure, note that if you just strip the second dir, you end up with duplicates, that was the shorter diff I could come up with :)
[08:40] <davidcalle> didrocks: also, not sure if you have noticed, but travis is trying to apt-get an older rev of a package, hence, all runs are failing since a couple days. (https://travis-ci.org/ubuntu/snappy-playpen/builds/133371927#L544)
[08:40] <didrocks> davidcalle: it's because I'm using sergiusens docker
[08:40] <didrocks> davidcalle: let me set up ours + daily refresh
[08:40] <didrocks> davidcalle: I'm playing with the regexp :)
[08:42] <didrocks> davidcalle: got it in a way shorter, do you want me to setup a branch you can review (or pull or whatever)?
[08:43] <davidcalle> didrocks: I'm fine with your branch replacing this one
[08:49] <didrocks> davidcalle: mind reviewing? https://github.com/ubuntu/snappy-playpen/pull/14
[08:52] <davidcalle> didrocks: hah, wfm :)
[08:53] <didrocks> davidcalle: we should specialized those changes in ci-run btw :)
[08:53] <davidcalle> didrocks: although... look at the ci-run :D
[08:53] <didrocks> davidcalle: yeah, it tries to run on the top_dir
[08:53] <didrocks> which was already the case
[08:53] <didrocks> Let me try to special-case this
[08:54] <davidcalle> didrocks: nope, yours considers the ci-run file as a folder
[08:54] <didrocks> davidcalle: yeah, because it doesn't care of file type
[08:54] <didrocks> we can just say "if file type == file" -> change is in the root dir
[08:55] <didrocks> I guess that's the best fix for other files in root
[08:57] <didrocks> davidcalle: refresh (see second commit)
[08:59] <davidcalle> didrocks: ty :)
[09:00] <didrocks> davidcalle: thanks for spotting it!
[09:01] <didrocks> davidcalle: so, I guess having our own docker image refreshed daily makes sense, right?
[09:02] <davidcalle> didrocks: sounds like a good solution, yes
[09:30] <didrocks> davidcalle: ok, master have most of the tests passing with my image (which is daily built)
[09:30] <didrocks> davidcalle: however, unsure who did merge ffmepg, but it seems to fail
[09:31] <didrocks> davidcalle: I'll push the docker image change first, then, we can iterate to get other fixed
[09:42] <davidcalle> popey: ^
[09:42] <davidcalle> Thanks didrocks
[09:45] <popey> eh?
[09:46] <popey> I did ffmpeg as a standalone snap.
[09:46] <popey> davidcalle merged them
[09:48] <davidcalle> popey: was just a heads up in case you had a fix. didrocks, do you have a log for ffmpeg? The original pr was fine afair.
[09:50] <popey> my snap worked fine, what did you do? :)
[09:51] <didrocks> davidcalle: I did a local ci-run
[09:51] <didrocks> it seems snapcraft can't find the ffmepg command (which is in bin/ffmepg)
[09:51] <didrocks> note that this can be an upstream issue with latest snapcraft :)
[09:54] <didrocks> popey: davidcalle: I did request cron enablement as well on Travis to build master regularly (the API token method don't work, despite saying success)
[09:55] <davidcalle> ok
[10:51] <vallettea> hello, I new to snappy and would like to know how can I monitor the the size of the update of my snap. I run a lot of sensors over 3G and the amount of data transfered is really important in my case
[12:40] <hathor008> can anyone shed some insights on this? would be greatly appreciated :) http://gamedev.stackexchange.com/questions/122197/how-do-i-create-an-ubuntu-snap-for-a-monogame-application
[12:42] <sborovkov> Hello. Are config interfaces back or still not?
[12:42] <ogra_> not yet
[12:44] <sborovkov> ogra_: is there some issue on launchpad for that? I did not find one :-(
[12:46] <didrocks> sborovkov: you're right, there is none: please file one https://bugs.launchpad.net/ubuntu/+source/snapd
[12:48] <sborovkov> Understood, thanks.
[12:48] <didrocks> hathor008: the issue is in your snapcraft.yaml
[12:48] <didrocks> you have:
[12:48] <didrocks> files:
[12:48] <didrocks>     "*":
[12:49] <didrocks> you need:
[12:49] <didrocks> files:
[12:49] <didrocks>     "*": '.'
[12:49] <didrocks> hathor008: but please, file a bug against https://bugs.launchpad.net/ubuntu/+source/snapcraft as the error message isn't obvious
[12:49] <hathor008> lol that's all it is? i figured it was something simple like that
[12:49] <hathor008> ok no problem
[12:50] <didrocks> hathor008: please copy your invalid snapcraft.yaml and mention "copy plugin" :)
[12:50] <didrocks> but yeah, that's all ;)
[12:50]  * didrocks still thinks that the copy plugin shouldn't require a files: parameter for such cases "copy all"
[12:55] <mhall119> hey guys,is there any known issue with running an OpenGL-using snap on proprietary graphics drivers?
[12:56] <mhall119> someone trying to run a Krita snap on proprietary nvidia is gettign this: http://pastebin.com/WsUfEj8J
[13:00] <mhall119> sergiusens: kyrofa: ^^ any help?
[13:03] <zyga> tyhicks: hey
[13:06] <noizer> Hi got a little problem with my snappy. is the tmp of the installation limited? error: cannot copy request into temporary file: write /tmp/snapd-sideload-pkg-130544461: no space left on device
[13:08] <hathor008> thanks for your help, didrocks. i really appreciate it :)
[13:08] <didrocks> hathor008: yw! :)
[13:09] <sborovkov> Hello. What's the current status of syslog on snappy? Is there some interface so that snap can configure it? Or how would I go about it when I need to configure it remotely?
[13:11] <didrocks> sborovkov: you have a log-observe interface, maybe give it a shot? (I don't think there anything for configuring it remotely yet)
[13:12] <jdstrand> tyhicks, sergiusens, sborovkov: hey, fyi, in my experience access to /proc/<pid>/mounts is almost always non-fatal (unless you are a disk usage analyzer or something). this constitutes a potential information leak, which is why it is not in the default profile (and in mount-observe)
[13:14] <jdstrand> sergiusens, sborovkov: fyi, tyhicks and I have been giving some thought to silencing logging of noisy denials
[13:15] <sborovkov> didrocks: thanks
[13:15] <sborovkov> jdstrand: is there a way to know what denial would be fatal?
[13:15] <jdstrand> sergiusens, sborovkov: we can do that now with an explicit deny of course, but that doesn't always work the way you want
[13:15] <sborovkov> jdstrand: since in the same log I had ldconfig run... I have no idea why, and don't know if it's fatal as well
[13:15] <jdstrand> sborovkov: run it in strict mode and see if your program runs ok
[13:17] <sborovkov> jdstrand: my program accesses /dev/vchiq as well, so it does not work in strict :-)
[13:17] <mhall119> jdstrand: davidcalle is helping me debug the krita snap with snappy-debug.security scanlog, but he gets this: http://paste.ubuntu.com/16863706/
[13:18] <davidcalle> Installing snappy-debug with --devmode helped http://paste.ubuntu.com/16863781/
[13:20] <didrocks> mhall119: jdstrand: confirmed, everytime an exception is raised, getting the stacktrace as well
[13:29] <noizer> what can I do with a snap thats not fits in the temporary dir while installing?
[13:30] <zyga> noizer: hmm?
[13:30] <zyga> noizer: how big is it?
[13:30] <zyga> noizer: report a bug first please
[13:30] <zyga> noizer: is your /tmp a tmpfs?
[13:31] <noizer> zyga: its my /tmp
[13:32] <noizer> zyga 250mb
[13:32] <noizer> zyga ps how can i manually make a snap?
[13:33] <noizer> zyga its for my armel build
[13:33] <ogra_> and your HDD doesnt have 250MB free ?
[13:33] <ogra_> (in /tmp)
[13:33] <zyga> noizer: just use mksquashfs
[13:33] <jdstrand> sborovkov: add '/dev/vchiq rw,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app
[13:33] <ogra_> uh
[13:33] <ogra_> no
[13:34] <ogra_> use "snapcraft snap $dir"
[13:34] <zyga> ogra_: that's less manual but non the less true :)
[13:34] <ogra_> (to make sure the proper options are used for mksquashfs)
[13:34] <ogra_> :)
[13:34] <jdstrand> sborovkov: that will allow that access and let you see if the other ones are ok. I know you have a bug open on /dev/vchiq and that zyga gave comments on how the interface can move forward
[13:35] <noizer> zyga ogra_ http://paste.ubuntu.com/16864020/
[13:35] <noizer> here you can see my diskspace
[13:36] <jdstrand> mhall119: that is the same error that we discussed last week. I submitted a PR to the log-observe interface and it was committed. it will be in the next snapd release
[13:36] <ogra_> noizer, well, /tmp is a tmpfs ... so buy more ram or change that to use the disk instead
[13:36] <noizer> heh its my raspi
[13:36] <mhall119> jdstrand: yup, for now he's got snappy-debug working in devmode
[13:36] <ogra_> oh, you are *on* snappy
[13:36] <mhall119> which revealed a syscall to 'bind' that was blocked
[13:36] <jdstrand> mhall119: let me find the commit and I can give you a workaround. yes, --devmode will work ok. when snapd 2.0.6 is out, it shouldn't be needed
[13:36] <noizer> ogra_:  yes ofc
[13:37] <mhall119> so running krita in --devmode gets it working for davidcalle
[13:37] <ogra_> hmm
[13:37] <mhall119> but someone else is having issues with OpenGL still, and running krita in --devmode doesn't help him
[13:37] <mhall119> davidcalle is using open-source gpu drivers, and the other guy has proprietary nvidia
[13:37] <jdstrand> mhall119: 774d721b0d4935fcdcb1146b8e38396eca67c17f (for snappy-debug)
[13:38] <jdstrand> mhall119: opengl is a mvo/zyga thing (iirc)
[13:38] <mhall119> mvo: zyga: can you guys help me debug this: http://pastebin.com/WsUfEj8J
[13:38] <ogra_> noizer, thats a tricky one indeed
[13:39] <jdstrand> mhall119: don't forget the socketcall workaround on i386. whoever hit that traceback you pasted likely will need to add socketcall to /var/lib/snapd/seccomp/profiles/snap.krita....
[13:39] <mhall119> it's not a confinement issue, he's run krita in --devmode and it has the same error, and snappy-debug.security scanlog doesn't show anything before the krita launch fails
[13:39] <mvo> mhall119: is that a nvidia (proprietary drive) system? or what HW do you use?
[13:39] <ogra_> noizer, and i guess worth a bug to tell snapd to use its own TMPDIR on disk ... as zyga said, file a bug
[13:39] <mhall119> jdstrand: he's on amd64
[13:39] <jdstrand> mhall119: not confinement> yes, I know, hence comment regarding mvo/zyga
[13:39] <mhall119> jdstrand: though I suspect that socketcall might be related to the bind denial that davidcalle sees
[13:40] <mhall119> mvo: proprietary driver, yes
[13:40] <noizer> ogra_: Is there for now a workaround?
[13:40] <jdstrand> mhall119: re bind> maybe. might just need network-bind
[13:40] <mvo> mhall119: do you happen to know what version?
[13:40] <jdstrand> snappy-debug in devmode will help you decide
[13:40] <mhall119> jdstrand: yeah, but it's a digital painting program, I don't see why it would need that in the first place
[13:40] <mhall119> mvo: of what?
[13:40] <ogra_> noizer, not that i know of ... ou could try remounting /tmp at runtime to disk manually but i guess that will break some bits that currently use the tmpfs /tmp
[13:41] <jdstrand> mhall119: it is surprising what apps not designed for confinement require
[13:41] <mhall119> mvo: let me get him in this channel, so I'm not passing messages around
[13:41] <mvo> mhall119: is that a system you have direct access to? what is the output of "ls -ld /usr/lib/nvidia-*" ?
[13:42] <jdstrand> mhall119: it could also be a kde think. bind is needed for binding to the server side of a unix socket too
[13:42] <jdstrand> thinkg*
[13:42] <jdstrand> err
[13:42] <jdstrand> thing*
[13:42] <mhall119> mvo: I don't, which is why I'm trying to get him to join in here
[13:42] <jdstrand> mhall119: kde has this whole ipc infrastructure which I predict it going to be challenging
[13:42] <mvo> mhall119: or tell me where he is and I join there, either way is fine
[13:42] <mhall119> jdstrand: hmmm, maybe. I can add network-bind to see if that allows davidcalle to run without --devmode
[13:43] <mhall119> mvo: he's in #krita
[13:43] <kyrofa> mhall119, do you know what computer he has?
[13:43] <mhall119> nick is  mattiasw
[13:43] <mhall119> kyrofa: only that it's amd64 and proprietary nvidia driver
[13:43] <kyrofa> Okay
[13:45] <kyrofa> zyga, do you know anything about https://askubuntu.com/questions/779875/cant-download-the-snap-packages ?
[13:47] <didrocks> kyrofa: swift is down
[13:48] <didrocks> impacted CI and the store
[13:48] <didrocks> impacting*
[13:48] <didrocks> (and hey!)
[13:48] <kyrofa> didrocks, oh. I guess that would do it! :P
[13:48] <kyrofa> didrocks, hey!
[13:48] <kyrofa> didrocks, that might also explain why my integration tests are having issues
[13:49] <didrocks> kyrofa: not for your local test run though :p (j/k)
[13:50] <noizer> ogra_: What is the difference between meta/snap.yaml and snapcraft.yaml
[13:54] <kyrofa> noizer, meta/snap.yaml is what snapd itself requires inside the snap itself
[13:55] <kyrofa> noizer, snapcraft.yaml is the "recipe" you give to snapcraft that tells it how to put the snap in question together, and it creates the meta/snap.yaml for you
[13:56] <ogra_> noizer, what kyrofa said :)
[13:57] <zyga> kyrofa: looking
[13:57] <kyrofa> Sorry zyga, didrocks informed me that it was likely a temporary store issue
[13:59] <noizer> hmmm ok but I can't snap my snap with snapcraft. So told me a few days earlier too snap it manualy but ... I don't understand it anymore
[14:00] <zyga> kyrofa: I also replied: http://askubuntu.com/questions/779875/cant-download-the-snap-packages/779917#779917
[14:00] <kyrofa> zyga, ah, good idea
[14:09] <mterry> tedg, looking at the unity8 lifecycle thread -- it's not just saving state, but also having apps that understand they will be frozen when not focused.  So apps need to use the correct Touch apis to do background stuff, etc.
[14:11] <popey> mhall119: do you know why the icon shows as a piece of paper for krita?
[14:11] <popey> I have made a snap and I wonder if perhaps the meta/gui/foo.png is no longer the right way to deliver an icon?
[14:11] <mhall119> it should be...it works for me anyway
[14:12] <mhall119> popey: is it in /snap/krita/current/meta/gui/ ?
[14:13] <popey> mhall119: yes
[14:14] <mhall119> what does the .desktop list for Icon?
[14:14] <popey> Icon=${SNAP}/meta/gui/calligrakrita.png
[14:14] <mhall119> then it should be working...
[14:14] <popey> $ file /snap/krita/current/meta/gui/calligrakrita.png
[14:14] <popey> /snap/krita/current/meta/gui/calligrakrita.png: empty
[14:14] <popey> that won't help
[14:15] <popey> zero byte file
[14:15] <mhall119> empty?
[14:15] <qengho> zyga: howdy!
[14:15]  * ogra_ hands popey a spare byte to add it to the file
[14:15] <mhall119> how the heck...
[14:15] <popey> what copies that file?
[14:15] <mhall119> davidcalle: can you $ file /snap/krita/current/meta/gui/calligrakrita.png
[14:15] <zyga> qengho: hey
[14:15] <tedg> mterry: Yes, I guess I see that as advanced usage. In that, they just need to know they're gonna be killed, if they want to work around that they can.
[14:15] <mhall119> popey: it's just in the setup/gui/ folder of the snapcraft directory
[14:16] <popey> setup/gui, not meta/gui?
[14:16] <mhall119> yeah, that's the snapcraft folder, it installs to meta/gui
[14:16] <ogra_> setup/gui jin the source
[14:16]  * zyga brb
[14:17] <popey> k
[14:17] <davidcalle> mhall119: /snap/krita/current/meta/gui/calligrakrita.png: empty
[14:17] <popey> wooot, mine works
[14:17] <popey> (once I put the png in the right place)  😃
[14:17] <mterry> tedg, not *so* advanced.  Lots of apps assume they run in background (irc etc).  But also maybe it implies a set of APIs that belong in that interface -- the download api, the push notification api, I dunno
[14:17] <mterry> Interfaces in Touch that let an app work in background, but the right way
[14:18] <mhall119> davidcalle: ok, something's gone wrong with upstream's build then....
[14:18] <tedg> So yes, I think those should all be in the unity8 interface. I think we might be agreeing?
[14:19] <davidcalle> mhall119: looks like it
[14:21] <mhall119> davidcalle: popey: that's probably my fault in how I submitted the patch upstream
[14:24] <mterry> tedg, yeah yeah we agree.  I was just trying to give you more ammo.  Seemed like things had focused just on OOM, but background processing is another uniquely-Touch set of problems
[14:25] <tedg> mterry: Makes sense, I think that this first PR is more about getting hello world off the ground. We're gonna need *a lot* more work after that. But I need a foothold to start attaching things like UAL to.
[14:26] <mvo> mhall119: do you think you could chase our nvidia packagers to include a systemd bind mount unit from "sudo mount -o bind /usr/lib/nvidia-361 /var/lib/snapd/lib/gl/" ?
[14:26]  * popey shoves a dosbox snapcraft to snappy-playpen
[14:26] <popey> probably the leanest snapcraft.yaml I've ever made
[14:26] <ogra_> popey, add doom too !!
[14:27] <popey> hah
[14:27] <mhall119> mvo: I don't even know who our nvidia packagers are...is that canonical, community, or nvidia?
[14:27] <popey> mhall119: tseliot iirc
[14:27] <ogra_> mhall119, tseliot
[14:27] <mhall119> thanks
[14:27] <popey> JINX
[14:27] <ogra_> :)
[14:27] <mhall119> will find him
[14:28] <popey> sounded a bit http://s2.quickmeme.com/img/b3/b397b33ced963be59c76e2566b24f0547aa2ae596f148ee1339f3c8e5c5b058c.jpg
[14:28] <ogra_> heh
[14:28] <popey> which seems harsh, despite it being nvidia
[14:29] <popey> didrocks: your jenkins is faulty... " g++: not found"
[14:29] <popey> didrocks: https://travis-ci.org/ubuntu/snappy-playpen/builds/134182006
[14:33] <mhall119> mvo: I assume the nvidia package fix needs to be SRU'd into 16.04's archives, it's not something that gets fixed in ubuntu-core images
[14:33] <mvo> mhall119: yeah, we need to get this SRUed
[14:33] <mvo> mhall119: not something we can fix in the image
[14:34] <ogra_> also, in the image the driver would have to live in the kernel snap
[14:34] <ogra_> (not in an nvidia package)
[14:34] <mvo> mhall119: thanks a lot for helping with the bind mount, really much appreciated
[14:35] <qengho> zyga, mvo: I do not remember anything in particular, but it's possible I pressed control-c during a "snap install" or "remove" before. Not to poison your debugging thoughts, but if nothing else seems obvious that might be a place to explore.
[14:35] <zyga> qengho: that wouldn't change anything
[14:35] <zyga> qengho: snapd carries the work, snap is just a rest client that says "do this please"
[14:36] <zyga> qengho: thanks for state.json
[14:36] <zyga> qengho: and for the syslog parts
[14:41] <zyga> qengho: can you still reproduce this issue?
[14:42] <zyga> qengho: and regardless, can you please pastebin the output of mount
[14:42] <zyga> qengho: and ls -l /snap/*
[14:43] <qengho> zyga: I'll try to reproduce now. mount is in the bug report already (|grep snap).
[14:46] <zyga> qengho: thanks
[14:51] <qengho> zyga: reproduced. Attached log.
[14:53] <qengho> Aw, man, and 2.0.3 is gone from APT. I can't downgrade now.
[14:57] <zyga> qengho: is there anything mounted under /snap/google-chrome/
[14:57] <zyga> qengho: under the directory (not there directly)
[15:00] <sethj> so, if one of my parts is a collection of bash and python scripts that uses an INSTALL file, what would I specify for a plugin? Or will I have to write my own? (there doesn't seem to be a list of included plugins anywhere)
[15:00] <qengho> zyga: you have my full mount list.
[15:00] <zyga> qengho: thanks, I'll check it out after this cal
[15:00] <zyga> call
[15:01] <qengho> lsof |grep chrome
[15:01] <qengho> (wrong terminal. gah.)
[15:02] <qengho> sethj: "Uses an INSTALL file"?
[15:02] <qengho> sethj: I'm guessing plugin: copy
[15:03] <sethj> qengho, https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install. copy does sound like it would be right. Lemme try. (and *is* there a list of these somewhere?)
[15:04] <qengho> sethj: yes.   $ snapcraft list-plugins
[15:04] <sethj> oh very nice.
[15:04] <sethj> someone needs to write a manpage :P
[15:07] <qengho> sethj: It's also very easy to put a file in parts/plugins/sethj.py, import snapcraft, class Anything(snapcraft.BasePlugin): def build(): super().build(); self.run(["something specific to you")
[15:07] <qengho> sethj: in your snapcraft.yaml, that's "plugin: sethj"
[15:08] <netphreak> I'm trying to install a snap via command line, and get the following error:
[15:08] <netphreak> - Make snap "ubuntu-core" available to the system (cannot set next boot: cannot determine bootloader)
[15:08] <netphreak> I'm on a RPI with ubuntu-core
[15:08] <qengho> netphreak: that's a known bug. Should be fixed soon.
[15:09] <netphreak> ... hopefully :)
[15:10] <qengho> netphreak: subscribe: https://bugs.launchpad.net/snappy/+bug/1580403
[15:12] <qengho> netphreak: wait, "with ubuntu core"? Is that from a ubuntu core testing image, or from regular 16.04 image with ubuntu core from snapd?
[15:17] <netphreak> Not quite sure what it is, got it setup a couple of weeks ago - don't seem to have the image file any more..
[15:17] <netphreak> Any command i can run to see which version?
[15:18] <qengho> netphreak: what's it look like to you? What do you see when you turn it on?
[15:19] <qengho> Does "apt" do anything?
[15:19] <netphreak> yes.. Apt is installed
[15:20] <netphreak> i used apt to install snapcraft and snap
[15:21] <joc_> zyga: i'm getting fails in the asserts section when executing run-checks, am I missing some setup?
[15:23] <zyga> joc_: can you be more specific please
[15:24] <joc_> zyga: yeah i'm running run-checks as per the README in snapd
[15:24] <sergiusens> didrocks we agreed a while ago to even deprecate `files` in the copy plugin and direct people to `filesets`, `organize`, `stage` and `snap`
[15:24] <joc_> zyga: it gets as far as github.com/jocave/snapd/asserts_test
[15:24] <joc_> zyga: then i get:
[15:25] <joc_> asserts/asserts_test.go:37: undefined: asserts.TestOnlyType
[15:25] <joc_> asserts/asserts_test.go:37: too many errors
[15:26] <qengho> netphreak: then you aren't using "ubuntu core", but ubuntu with snaps. And that is the bug here. snapd thinks it's the top OS, when it's not in your case and my case. And that bug is fixed in a few days.
[15:27] <netphreak> ahh.. ok.. thx for explanation.
[15:27] <netphreak> do you know the status of snappy classic-mode?
[15:27] <qengho> netphreak: "apt" doesn't exist in the Ubuntu Core world. It's a specialty-device kind of place. We get to piggy-back on all its goodness, though.  :)
[15:27] <netphreak> :)
[15:27] <joc_> zyga: i've only add an interace as you suggested so wasn't expecting to get errors from anywhere else
[15:28] <zyga> joc_: hmm, can you reproduce that on master?
[15:28] <zyga> joc_: anyway, ignore run-checks
[15:28] <zyga> joc_: just go test in interfaces/builtin initially
[15:28] <zyga> joc_: and open a pull request or show me your branch
[15:28] <zyga> tyhicks: hey
[15:28] <qengho> netphreak: Not much. I used it back in February, but it's probably changed a lot since.
[15:28] <zyga> jdstrand: hey :)
[15:28] <zyga> jdstrand: I wanted to sync about snap-confine
[15:29] <jdstrand> zyga: hey--ok, should tyhicks be here?
[15:29] <zyga> jdstrand: I think so
[15:29] <qengho> netphreak: it, like all of snap stuff, is in heavy development. To be released soon.
[15:29] <zyga> jdstrand: I have a few questions and I want to know what you are working on, e.g. if tyler will look at the bind mount interface and if you saw what's posted to the repository lately
[15:29] <popey> davidcalle: didrocks https://github.com/ubuntu/snappy-playpen/pull/15 - feel free to merge if you want :)
[15:30] <tyhicks> zyga: hi
[15:30] <zyga> tyhicks: hey, good to see you
[15:31] <joc_> zyga: thanks, i'll get tests passing then get back to you
[15:31] <jdstrand> zyga: currently I am not doing anything with the launcher. I am waiting for the seccomp arg filtering reviews (I saw you commented, waiting on tyhicks too). when that is done, I will start on trying to get that into xenial and then fix various bugs blocked on that
[15:31] <zyga> joc_: note that for all the integration tests to pass you need the patched ubuntu-device-flash
[15:31] <zyga> (in your path)
[15:31] <tyhicks> jdstrand: I completed my seccomp arg filtering review friday evening
[15:31] <jdstrand> setpriority is the big one, but others. I believe tyhicks is working on other things
[15:31] <jdstrand> awesome
[15:31] <zyga> jdstrand: note that we should be careful about releases of the code today
[15:31] <jdstrand> I'm still behind on email and will get to it today
[15:31] <zyga> jdstrand: as we're getting more and more snap-run/confine/exec story landed
[15:32] <zyga> jdstrand: and that needs coordination
[15:32] <jdstrand> zyga: yes, I was considering SRUing something as a patch to ubuntu-core-launcher for xenial and let all the other stuff be under your control
[15:32] <jdstrand> it just depends on the timing
[15:32] <zyga> jdstrand: that's sounds good, just let us know when this happens
[15:32] <zyga> jdstrand: note that there's been an upload to debian that's not reflected in either tree today
[15:33] <zyga> jdstrand: (the version is +1 there)
[15:33] <zyga> jdstrand: ubuntu@localhost:/etc/modprobe.d/modprobe.d$ ll
[15:33] <jdstrand> I'm getting asked every day though on when bug NNN will be fixed and I keep saying 'when seccomp arg filtering is there...)
[15:33] <zyga> er
[15:33] <zyga> bad paste
[15:33] <zyga> jdstrand: heh
[15:33] <tyhicks> zyga: I haven't started working on the bind mount support in interfaces - despite not having the time to work on it yet, it felt like a lot of things were in flux and I wasn't clear if plans had changed
[15:33] <zyga> jdstrand: yes, I see that this should land as soon as we can
[15:33] <zyga> tyhicks: can I ask you to review my chroot / pivot_root patch
[15:33] <zyga> tyhicks: I suspect we'll go ahead with that approach (just polish it more)
[15:34] <zyga> tyhicks: but I want a solid security review to preceed that
[15:34] <tyhicks> zyga: sure, I can review that patch but I thought we were told not to make that change right now?
[15:34] <zyga> tyhicks: yes, but the blocker is getting done :)
[15:34] <jdstrand> zyga: is what is in the debian +1 patch at least in trunk? if not, what is that?
[15:34] <zyga> tyhicks: and gustavo said that it should be the next thing after that
[15:34] <tyhicks> zyga: ack - i'll have a look
[15:35] <zyga> jdstrand: I think slangasek uploaded something to debian and there's a change that is not integrated anywhere
[15:35] <zyga> other than that I'm proposing some tooling changes (autotools)
[15:35] <jdstrand> http://metadata.ftp-master.debian.org/changelogs//main/u/ubuntu-core-launcher/ubuntu-core-launcher_1.0.29+1_changelog
[15:35] <jdstrand> it's not code changes
[15:36] <zyga> and I will have a few small patches that make lintian happier (lots of little issues), some of those are related to security so I'll poke you specifically on github
[15:36] <zyga> jdstrand: with native packages it is hard to see
[15:36] <jdstrand> zyga: if it's lintian, see slangasek's patch
[15:36] <zyga> jdstrand: perhaps I should just ask slangasek to send that to snap-confine :-)
[15:36] <zyga> slangasek: ^^
[15:36] <jdstrand> :)
[15:37] <zyga> tyhicks, jdstrand: are you both aware of what's changing to snap-run/confine/exec now?
[15:38] <tyhicks> zyga: no, I'm not fully aware
[15:38] <jdstrand> not really, no
[15:39] <zyga> okay, so the quick big picture is that snap run (a new subcommand of snap) will run snap-confine (which is the current C codebase), that will apply process confinement as it does today and then execute /usr/lib/snapd/snap-exec (xi style) which will in turn read all the yaml bits and figure out what to exec
[15:40] <zyga> that last program (snap-exec) will be written (is written by mvo actually) in go and will mainly do yaml parsing and environment setup
[15:40] <zyga> I just want to keep both of you in the loop so that you're aware of what is going on
[15:41] <jdstrand> zyga: xi style?
[15:41] <tyhicks> he means ix
[15:41] <zyga> yes
[15:41] <zyga> sorry
[15:41] <zyga> not changing the profile
[15:41] <jdstrand> I see
[15:41] <zyga> so snap-exec runs as the final application will
[15:41] <zyga> one thing we will get out of that is that snap-exec will also know how to run pre commands, post commands, and hooks
[15:41] <zyga> and that it will no longer have to get the command to run from command line, instead command line will just be the actual command line for the application being started
[15:42] <tyhicks> FWIW, I don't think snap-exec should run under the confinement of the application
[15:42] <tyhicks> it sounds like it'll be doing things that the application should not have access to do
[15:42] <tyhicks> but maybe I'm wrong
[15:42] <zyga> tyhicks: it will only read snap.yaml
[15:42] <zyga> tyhicks: and exec the executable of the application
[15:43] <tyhicks> zyga: you said pre/post commands and hooks
[15:43] <zyga> tyhicks: those are just commands to run that are written down in snap.yaml
[15:43] <jdstrand> so, instead of snap-confine exec'ing the binary, it executes snap-exec which executes the binary
[15:43] <zyga> tyhicks: e.g. snap run apache --command=post
[15:43] <zyga> jdstrand: yes
[15:43] <zyga> tyhicks: and that goes and reads what to really execute from snap.yaml
[15:44] <zyga> tyhicks: so that we don't have to pass it on the command line all the time
[15:44] <zyga> this approach also kills a lot of the wrappers
[15:44] <tyhicks> jdstrand: this is good - it moves code out of the setuid root launcher and the launcher won't need to learn how to read yaml
[15:44] <mvo> the long version is here: https://docs.google.com/document/d/1Afjs72T43nN0J5DK6qiaKmIthOjhK8_bvrac6E56Bcc/edit#
[15:44] <jdstrand> zyga: what is the motivation for this? does it provide snap-confine cleanups? (if so, what?) does it allow use to clean up other parts of the system? (if so, what?)
[15:44] <zyga> to the point that we may end up having no wrappers (and /snap/bin might just contain symlinks to /usr/bin/snap
[15:44] <zyga> jdstrand: it unlocks hook
[15:44] <zyga> hooks
[15:44] <mvo> tyhicks: yeah, the u-c-l (snap-confine) really now only needs to deal with the essential stuff, everything else is done in go
[15:44] <zyga> sidesteps environment
[15:44] <zyga> so that we can cleanly set environment for the process
[15:45] <zyga> and makes launchers mostly redundant
[15:45] <jdstrand> ah, that doc is helpful
[15:45] <jdstrand> is it up to date?
[15:45] <tyhicks> I hope the environment stuff isn't the main motivation
[15:45] <zyga> tyhicks: I don't actually know, I think the main motivation is to clean up the command line part
[15:45] <tyhicks> I'm about to SRU the apparmor changes that would allow the launcher to set up the environment
[15:45] <zyga> so snap run looks nice
[15:45] <jdstrand> tyhicks: it sounds like hooks is the price of admission
[15:45] <zyga> as do all the things after that
[15:45] <mvo> jdstrand: its up-to-date to the point of "previous dicussion"
[15:46] <ara> zyga, kudos to your post about first contribution to snapd <3
[15:46] <ara> zyga, maybe you can try to get the people at https://twitter.com/yourfirstpr to tweet about it
[15:46] <zyga> ara: :-) when I saw that bug I just said "this has to be something other people can contribute"
[15:47] <zyga> ara: will do
[15:49] <zyga> tyhicks, jdstrand: that's all I had
[15:49] <zyga> I think you are in the loop now :)
[15:49] <jdstrand> tyhicks: so, I think in terms of security, this is good, if a little twistier. it reduces the number of lines of setuid code a bit
[15:50] <jdstrand> but the setuid code is at least not twistier
[15:50] <tyhicks> jdstrand: reducing the amount of code in the setuid launcher's address space is a good thing
[15:50] <jdstrand> tyhicks: what was the env bits to the launcher you were talking about? the safe/unsafe stuff?
[15:51] <tyhicks> jdstrand: also, this alleviates the launcher from needing to continually expand to do more things (stuff can go into snap-exec)
[15:51] <jdstrand> well
[15:51] <jdstrand> some stuff
[15:52] <jdstrand> if it is root-stuff, then not so much
[15:52] <tyhicks> jdstrand: yes, the safe/unsafe stuff that should land in lp:apparmor today
[15:52] <tyhicks> sure
[15:52] <jdstrand> ie, this doesn't help your mount code
[15:52] <tyhicks> privileged stuff has to go into snap-confine
[15:52] <jdstrand> yeah
[15:52] <tyhicks> but stuff that doesn't require privs, such as parsing the yaml and/or setting up the env, can go into snap-exec
[15:52] <jdstrand> which is a lot of what we've been doing, but I realize it isn't all everyone's been doing
[15:53] <jdstrand> yes, that is good
[15:53] <jdstrand> of course, the safe/unsafe is unneeded now, correct? since snap-exec will do it all and it is after dropping and past the exec barrier
[15:54] <jdstrand> assuming I understand correctly-- if you can parse the yaml, you can setup the environment however you need to
[15:55] <jdstrand> which snap-exec is in the position to do
[15:55] <tyhicks> jdstrand: safe/unsafe is now unneeded for snappy but someone else will hit this issue during the life of 16.04 and the code is already finalized so I'm going to SRU it
[15:55] <jdstrand> tyhicks: yes, I agree. just trying to make sure I understand
[15:56] <slangasek> zyga: where is snap-confine, so that I might submit it?
[15:56] <zyga> slangasek: github.com/ubuntu-core/snap-confine
[15:57] <zyga> slangasek: it will move to snapcore later but just fork and submit away :)
[15:57] <jdstrand> tyhicks: so I think I understand the snap-confine to snap-exec attack surface (it isn't appreciably different-- we are already under confinement and actually, snap-confine should be able to lose exec on code in /snap
[15:57] <tyhicks> jdstrand: if snap-exec ends up getting its own profile, rather than using the profile of the app, then safe/unsafe would be required again
[15:57] <jdstrand> tyhicks: that is what I was trying to tease out
[15:58] <jdstrand> so today, we have the launcher that is confined calling the wrapper script
[15:58] <slangasek> zyga: thanks
[15:58] <jdstrand> with this, snap-run is unconfined, called snap-confine (confined) which changes profile to the confinement of the app and calling snap-exec <app>
[15:59] <jdstrand> s/called/calling/
[15:59] <jdstrand> snap-run doesn't need any provileges
[15:59] <zyga> correct
[15:59] <jdstrand> privileges beyond calling snap-confine
[15:59] <zyga> one complication is that snap-exec will be from the OS snap
[15:59] <zyga> not from the snapd package
[16:00] <zyga> unless we do bind mount trickery to prevent that but I think that's okay as it is pretty well defined
[16:00] <jdstrand> systemd unit's exec is still controlled (snap-run now instead of snap-confine). there is no wrapper, but the code needs to be written to make sure it call snap-confine with the correct args
[16:00] <zyga> jdstrand: it would call snap run
[16:00] <jdstrand> snap-confine if from the os snap
[16:01] <zyga> jdstrand: all systemd units would just say "snap run $snap.$app --command=..."
[16:01] <jdstrand> right, I get that
[16:01] <zyga> jdstrand: AFAIR that's the agreement but I may be missing bits
[16:01] <zyga> (it's not a big change)
[16:01] <jdstrand> I may not have said it clearly that I understood that
[16:01] <zyga> but yes, this has to migrate
[16:01] <zyga> sorry then :)
[16:01] <jdstrand> I'm trying to understand the attack surface
[16:01] <jdstrand> systemd unit's attack surface is unchanged
[16:02] <jdstrand> is all I meant
[16:03] <jdstrand> tyhicks: so, snap-run is resolving its argv[0] to decide how to invoke snap-confine
[16:05] <tyhicks> right
[16:05] <jdstrand> tyhicks: obviously the code has to be correct, but I don't see that as any different from being able to run the wrapper or more to the point, running ubuntu-core-launcher today
[16:05] <tyhicks> agreed
[16:05] <tyhicks> jdstrand: the user can still run snap-confine directly
[16:06] <jdstrand> right
[16:06] <tyhicks> jdstrand: snap-confine will still have to do checks to make sure the arguments passed to it are safe
[16:06] <jdstrand> and things running under snap-confine still can't run snap-confine, like today can't run ucl
[16:06] <jdstrand> tyhicks: of for sure
[16:07] <jdstrand> tyhicks: snap-confine needs to continue to be very carefully written
[16:07] <tyhicks> yep
[16:07] <jdstrand> and confined
[16:07] <tyhicks> agreed
[16:07] <jdstrand> but I don't see a reason to confine snap-run
[16:07] <zyga> do we have to change anything in the apparmor profile for snap-confine?
[16:07] <jdstrand> yes
[16:07] <tyhicks> jdstrand: I don't either
[16:07] <jdstrand> we can remove some stuff and need to add something to exec snap-exec
[16:08] <zyga> jdstrand: I did some experiments and I didn't have to add anything
[16:08] <zyga> jdstrand: is it possible that this is covered by /snap/** r, rule?
[16:08] <jdstrand> no
[16:08] <jdstrand> those would be symlinks
[16:08] <jdstrand> to snap-run
[16:09] <jdstrand> so you would've had to add a rule for snap-run to run those (which we will not)
[16:11] <zyga> I mean snap-confine executing snap-exec
[16:11] <zyga> I did an expeirment and I ended up with no permission chages required to do that
[16:11] <jdstrand> zyga: perhaps it is working for you because it is running unconfined? that would happen if you changed the name to /usr/bin/snap-confine but didn't change the profile to have: /usr/bin/snap-confine (attach_disconnected) {...
[16:11] <zyga> jdstrand: I was running out of master snap-confine (which currently uses snap-run)
[16:11] <zyga> (as the name)
[16:12] <jdstrand> I can't say why it worked for you. I can only speculate. you'll need snap-exec and we'll be able to remove several rules
[16:13] <zyga> in any case, baby steps, mvo has all of the hard work done and we can see when that lands, what is the next step
[16:13] <jdstrand> if you can come up with a reproducer for it working now when it shouldn't, I can walk through what is happening
[16:13] <zyga> jdstrand: can you check if the way I patched maintainer scripts to handle the launcher rename is correct?
[16:13] <jdstrand> zyga: where is that PR?
[16:14] <sethj> well thanks for the help qengho! copy worked and it snapped successfully.
[16:15] <zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c
[16:15] <sethj> now I just need to figure out how to include a font/theme so the text shows up..
[16:15] <jdstrand> boy
[16:16] <jdstrand> I wonder why people aren't using apparmor_parser there
[16:16] <zyga> jdstrand: apparmor_parser --remove didn't work because it wanted to parse the now-gone file
[16:16] <sborovkov> Hello, how can I get snap preinstalled on the image with snappy? Can that be done with ubuntu-device-flash? Or is it supposed to be done in some other way?
[16:17] <zyga> sborovkov: hey
[16:17] <zyga> sborovkov: not yet :)
[16:17] <zyga> sborovkov: it will be with ubuntu-image I'm working on with a few other brave souls
[16:17] <zyga> sborovkov: if you have some spare time help is appreciated
[16:17] <zyga> sborovkov: I can point you the way to the code and tell you where we are
[16:18] <jdstrand> zyga: it's wrong
[16:18] <sborovkov> zyga: understood I don't have a lot of time, need to get application we are doing working on snappy...
[16:18] <jdstrand> oh wait
[16:18] <zyga> jdstrand: mmm?
[16:19] <qengho> sethj: you're welcome! make awesome stuff!
[16:19] <zyga> sborovkov: no worries, we'll get to it in ~1/2 weeks
[16:19] <didrocks> sergiusens: when I do try to run integration tests, I always have issues with the 15.04 image creation
[16:19] <didrocks> sergiusens: any hint?
[16:20] <zyga> jdstrand: can you say what is wrong and how it should look like instead?
[16:21] <zyga> slangasek: https://github.com/ubuntu-core/snap-confine/pull/15
[16:22] <didrocks> kyrofa: elopio: hey, maybe you will know about snapcraft integration tests ^ (no way for me to run them locally due to u-d-f wanting to create the 15.04 image)
[16:22] <zyga> slangasek: and have a look at https://github.com/ubuntu-core/snap-confine/pull/14 please, I'd like to land it to iterate on top
[16:22] <zyga> didrocks: get mvo's udf and stick it in /usr/local/bin
[16:22] <didrocks> zyga: I'm pretty sure I tried this, but let me retry
[16:23] <zyga> didrocks: same issue as with snapd tests
[16:23] <jdstrand> zyga: yes it is wrong. See https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c#commitcomment-17681678
[16:23] <didrocks> zyga: still http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash, right?
[16:23] <zyga> didrocks: yes
[16:23]  * didrocks gives it a try
[16:23] <zyga> jdstrand: ah
[16:24] <jdstrand> zyga: what was committed won't match
[16:24] <zyga> jdstrand: that was a suggestion from tyhicks :)
[16:24] <zyga> jdstrand: I'll commit your version right away
[16:26] <zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/16
[16:28] <didrocks> zyga: yeah, so I'm getting:
[16:28] <didrocks> INFO:demos_tests.testbed:Creating a snappy image to run the tests.
[16:28] <didrocks> building 15.04 core images is no longer supported. Please use the ppa:snappy-dev/tools 15.04 version of this tool
[16:28] <didrocks> subprocess.CalledProcessError: Command '['sudo', 'ubuntu-device-flash', '--verbose', 'core', '15.04', '--channel', 'stable', '--output', '/tmp/tmpfu0iwno7/snappy.img', '--developer-mode']' returned non-zero exit status 1
[16:28] <didrocks> with $ sudo which ubuntu-device-flash
[16:28] <didrocks> /usr/local/bin/ubuntu-device-flash
[16:28] <didrocks> (mvo's version)
[16:28] <jdstrand> zyga: thanks, responded
[16:28] <zyga> didrocks: well, you still call it with 15.04 bits
[16:28] <jdstrand> zyga: also, thank you for getting tyhicks and me up to speed on the the changes
[16:29]  * tyhicks scratches his head
[16:29] <didrocks> zyga: snapcraft does…
[16:29] <zyga> didrocks: ah, then that's snapcraft to tweak then
[16:29] <didrocks> so I don't know how to run my integration tests on 16.04, which is issue
[16:29] <tyhicks> I tested that grep command that I provided
[16:29] <didrocks> I guess there is a reason they are calling out 15.04 :p
[16:29] <tyhicks> I must have pasted in the wrong command :/
[16:29] <zyga> tyhicks: is it possible that you got grep=egrep alias?
[16:29] <zyga> anyway, I'm glad this had more eyes on it :)
[16:29] <tyhicks> nope
[16:30] <tyhicks> I rarely use egrep and definitely didn't use it while testing
[16:30] <tyhicks> sorry for the screw up
[16:30] <jdstrand> maybe there was a way to do it without egrep... anyway, that one works
[16:30] <tyhicks> ah, the + needs to be escaped
[16:31] <tyhicks> $ sudo grep '^/usr/bin/ubuntu-core-launcher ([[:alpha:]]\+)$' /sys/kernel/security/apparmor/profiles
[16:31] <tyhicks> /usr/bin/ubuntu-core-launcher (enforce)
[16:31] <tyhicks> anyways, egrep is fine
[16:31] <sergiusens> didrocks no need to run udf for integration tests
[16:31] <sergiusens> didrocks for example tests, we support testing on classic
[16:31] <sergiusens> elopio ^
[16:32] <didrocks> sergiusens: is there any example for this?
[16:32] <sergiusens> didrocks but you can also just --skip-install
[16:32] <sergiusens> didrocks for integration_tests just ./runtests.sh integration
[16:32] <didrocks> sergiusens: yeah, I just wanted to run them in some way rather than sending that to the machinery everytime :)
[16:32] <didrocks> sergiusens: yeah, those are running, so your comment is that one integration test is failing, you think?
[16:33] <sergiusens> didrocks I really think so
[16:33] <didrocks> that's possible, the fact that we don't fake the terminal size…
[16:34] <zyga> joc_: hey, did you get past the testing issues?
[16:34] <sergiusens> didrocks `python3 -m unittest -v -b run integration_tests.test_list_plugins`
[16:34] <didrocks> sergiusens: ah yeah, there is one :)
[16:34] <didrocks> sergiusens: yep, will fix it and push
[16:34] <joc_> zyga: yes thanks, sorted now
[16:34] <didrocks> sergiusens: I need to think how we can have it in an terminal-independent size though
[16:34] <didrocks> sergiusens: as it will be different on jenkins
[16:34] <sergiusens> didrocks the ones that require u-d-f are the "demo" tests fwiw
[16:35] <didrocks> sergiusens: yeah, and "tour" one (soon ;))
[16:35] <sergiusens> didrocks `python3 -m demos_tests --help`
[16:35] <didrocks> ok, so --skip-install
[16:36] <didrocks> sergiusens: I'll fix and try to fine something to not be terminal-size dependent on the integration one
[16:36] <sergiusens> didrocks or `SNAPCRAFT_FROM_INSTALLED=1 python3 -m demo_tests`
[16:36] <sergiusens> didrocks that will install to classic
[16:36] <didrocks> oh nice :)
[16:36] <sergiusens> didrocks which is what we do in debian/tests/demostests
[16:36] <didrocks> ah, for the adt testbed
[16:37] <sergiusens> yup
[16:45] <didrocks> sergiusens: just pushed a fix, it seems to be independent already of terminal size, we'll have to see how it goes under jenkins though once the tests run
[16:47] <zyga> jdstrand, tyhicks: so how shall we call the new backend "modprobe" backend?
[16:54] <tyhicks> zyga: is that something we need? I don't know if I've heard about those plans yet
[17:11] <kyrofa> didrocks, are you still around?
[17:21] <sergiusens> didrocks maybe `isatty` and affect the result accordingly
[17:22] <sergiusens> but let's see
[17:35] <jdstrand> tyhicks: I'll explain. remember how iptable_filter and ip6table_filter don't autoload but once loaded netfilter modules load fine?
[17:36] <jdstrand> tyhicks: the backend zyga is talking about is an idea I had and presented to niemeyer and zyga that we agreed is a good idea. basically, there is an additional backend that an interface may implement but most would not
[17:37] <jdstrand> tyhicks: so in the case of firewall-control, it would implement this new module backend and when a snap connects to firewall-control, snapd looks at the backend for the list of modules to load for the interface to be at all useful
[17:38] <jdstrand> tyhicks: snapd will then drop a file into /etc/modules-load.d for reboots and load the modules on first connection
[17:38] <jdstrand> tyhicks: in this manner, snaps niether get to specify the modules to load themselves (or there options) nor have SYS_MODULE, etc
[17:39] <jdstrand> tyhicks: like with security policy, dbus policy and udev rules, snapd has a hardcoded list of what it will make sure is loaded
[17:40] <jdstrand> tyhicks: as it turns out, this is likely useful for modem-manager as well as firewall-control
[17:40] <zyga> tyhicks: yes, probably for modem manager
[17:41] <jdstrand> tyhicks: you may recall snappy config ubuntu-core allowed for the admin/gadget developer to specify modules to load on a particular device. I suspect that may still be useful, but integrating into interfaces in this manner has a way better user experience
[17:42] <jdstrand> tyhicks: the first iterations will only deal with a list of modules to load (ie, no options or other stuff). if we need that other stuff, we can look at it when requested
[17:43] <jdstrand> zyga: I was initially thinking that rather than trying to maintain a single file in /etc/modules-load.d, snapd would manage one file per interface (so, snap.firewall-control, snap.ppp (or something)). I'm not married to it, but it seems consistent with other parts of the system
[17:44] <zyga> jdstrand: I'll think about it, a single file might be easier on SD cards and it's all the same technically (otherwise)
[17:44] <jdstrand> zyga: that said, garbage collection would be something to consider (removing those files on snap disconnect) and perhaps that isn't the best approach
[17:44] <jdstrand> (just some random thoughts I had)
[17:44] <zyga> jdstrand: on disconnect or connect we always rewrite the file after computing the content it has to have
[17:44] <zyga> jdstrand: so it's not a problem to use one file unless that file would be huge but I don't think it is a problem here
[17:45] <jdstrand> that's true
[17:45] <jdstrand> probably actually easier in this case
[17:46] <jdstrand> zyga: I think I prefer 'kernelModules' instead of 'modprobe'
[17:47]  * tyhicks was lunching
[17:49] <tyhicks> jdstrand: so snaps will not be able to provide their own modules - it'll only be modules shipped by the kernel snap?
[17:50] <jdstrand> tyhicks: app snaps can't do anything with modules directly. all they can do is 'plugs: [ something ]' where the 'something' interface may define modules that snapd will load
[17:51] <jdstrand> tyhicks: and snaps can't influence what is loaded or how
[17:52] <nimoov> exit
[17:54] <tyhicks> jdstrand: ohhh, I understand now
[18:10] <ogra_> jdstrand, zyga, please dont forget about possible module options ;)
[18:11] <jdstrand> I mentioned that. at first it is just a list. when there is something that needs options, we can expand
[18:15] <zyga> jdstrand: ay, will do
[19:03] <almejo_> Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?
[19:03] <almejo_> like snap --forece remove <snap>
[19:04] <almejo_> i can not delete packages becouse they are mounted
[19:09] <almejo__> Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?
[19:22] <sergiusens> zyga ^
[19:22] <sergiusens> seems to be something widespread
[19:23] <sergiusens> maybe we should add mention of your branch to /topic
[22:17] <thibran> hello, someone there?
[22:19] <sergiusens> thibran what's up?
[22:19] <thibran> I solved a snap bitsize bug
[22:20] <thibran> and now I would like to get it merged, but have some questions
[22:21] <thibran> to sign the contributor agreement, I need a 'project contact'
[22:22] <thibran> how do I get one?
[22:22] <sergiusens> thibran let me check, but for starters you can start getting the PR up
[22:23] <sergiusens> kyrofa you've been dealing with CLAs lately, where should it go to?
[22:23] <sergiusens> thibran a review is not blocked by the CLA
[22:24] <thibran> k
[22:25] <thibran> than I upload the code
[22:26] <sergiusens> thibran yeah, get your toes in technically first, leave the paper work for last :-)
[22:29] <thibran> https://github.com/snapcore/snapd/pull/1249
[22:29] <thibran> I hope I got the i18n stuff right, my compiled bin works


[08:43] <pitti> seb128: BTW, that compiz startup bug
[08:43] <pitti> seb128: ... isn't one, I just haven't restarted my session in ages \o/
[08:43] <pitti> it works now
[08:43] <seb128> pitti: good ;-)
[08:43] <pitti> (just a very small bday present, I know...)
[09:04] <gicmo> seb128: yo
[09:04] <seb128> gicmo: hey hey
[09:04] <gicmo> seb128: just got the crasher again (trash) myself
[09:05] <seb128> it's a popular one ;-)
[09:05] <seb128> the number of dup was 93 when I looked yesterday
[09:05] <gicmo> seb128: I am thinking about adding a piece of code that might fix it
[09:05] <gicmo> seb128: I just wish I could reproduce it
[09:06] <seb128> right
[09:06] <seb128> gicmo: what piece of code and where?
[09:07] <gicmo> seb128: just add g_vfs_get_default () on the main thread
[09:07] <seb128> that would fix it? I though the issue was dbus used in threads
[09:07] <gicmo> calling that func will cause gio/gvfs to be initialized
[09:07] <gicmo> seb128: well, the issue is that we are initilizing gvfs from the second thread
[09:08] <gicmo> seb128: look at the stack traces, they all crash with gvfs_daemo_init () or g_vfs_get_default () in the second thread
[09:09] <gicmo> what was the lp bug?
[09:09] <gicmo> sorry for not remembering that
[09:09] <seb128> bug #252174
[09:09] <seb128> no problem ;-)
[09:11] <gicmo> This bug has 95 duplicates
[09:11] <gicmo> W T F
[09:13] <gicmo> seb128: since the crash itself is always in the mainloop
[09:13] <seb128> gicmo: that's only ubuntu unstable, I say you are lucky gnome-session 2.23 doesn't enable bug-buddy ;-)
[09:13] <gicmo> seb128: I am wondering if calling the dbus_integrate_with_main function causes the GSource to get invalid or something
[09:14] <seb128> hum, dunno
[09:14] <seb128> brb, I just need to restart my session
[09:18] <gicmo> seb128: sooo
[09:18] <seb128> re
[09:19] <gicmo> re
[09:19] <seb128> gicmo: I've no enough clue about that to tell you if that fixes the issue
[09:19] <gicmo> I am sorry if am distracting you
[09:19] <seb128> oh that doesn't distract me, I've just no good reply ;-)
[09:20] <seb128> I can push patches and wait for user feedback or see if bug reports stop though
[09:21] <seb128> I'm just not enough of a hacker to have a clue about this issue
[09:21] <gicmo> I am not sure the _g_dbus_connection_integrate_with_main () is prepared to handle more then one main integration
[09:24] <seb128> did you try to mail alex? maybe he has some clue about that too and could confirm your idea?
[09:26] <gicmo> seb128: not yet
[09:26] <gicmo> seb128: I am reading the glib dbus bindings right now to confirm my idea whats going on
[09:26] <gicmo> seb128: I think I have my finger at the right point now
[09:57] <pochu> good morning!
[09:58] <seb128> hello pochu
[10:00] <pochu> hi seb128. I did a few basic tests with nemiver 0.6.2
[10:00] <pochu> I think if crevette could test it too, we could sync it
[10:01] <seb128> alright
[10:26] <crevette> pochu: do yo have a package ?
[10:28] <pochu> crevette: yes, let me upload it somewhere
[10:29] <crevette> pochu: I'm in contact with the developers, and there shouldn't have a lot of changes
[10:29] <crevette> so it should work :)
[10:39] <pochu> crevette: http://emilio.pozuelo.org/~deb/
[10:40] <crevette> tx
[11:35] <seb128> mvo_: thanks for sending the gnome-keyboard-properties patch upstream
[11:35] <seb128> mvo_: I've assigned bug #268636 to you since it's in your changes
[11:46] <crevette> pochu: does setting a breakpoint works for you ?
[11:47] <crevette> nemiver doesn't open the source code window
[12:29] <mvo_> seb128: thanks, looking
[12:31] <mvo_> seb128: otherwise it looks good bugwise afaics
[12:38] <pochu> crevette: I haven't tried it yet. I can have a look later if you want
[12:40] <pitti> seb128: any regression reports about the deskbar SRU? (bug 255998)
[12:41] <pitti> seb128: at some point we should move that to -updates, but I'd like to see at least one confirmation "yes it works"
[12:46] <seb128> pitti: oh, it's still not moved? no, no regression bug
[12:47] <pitti> no feedback on the bug
[12:47] <seb128> pitti: the change is one commit to adapt for a website change
[12:48] <seb128> pitti: and is intrepid
[12:48] <seb128> and we got no bug since
[12:48] <seb128> I don't use this website but deskbar-applet was still working correctly when I tried
[12:49] <pitti> ok, thanks
[12:49] <pitti> good 'nuff
[12:49] <seb128> cool, thank you
[12:51] <crevette> I'll try to package latest bluez-gnome for blue 3.x this week end
[12:52] <pochu> seb128: I've connected an ipod in Intrepid. Nautilus shows it's mounted, but it doesn't open in rhythmbox, and if I double-click it in Nautilus it doesn't open. is this a known issue?
[12:54] <pochu> the ipod plugin is enabled, and it used to work
[12:55] <seb128> pochu: no, it works fine for me, it display the "what do you want to do" action which default to starting rhythmbox
[12:55] <seb128> pochu: what action is configured in nautilus?
[12:55] <pochu> Media>Music Player>Ask what to do
[12:55] <pochu> perhaps it's my profile, I can try with a new user
[12:56] <seb128> right
[12:56] <pochu> I have this in .xsession-errors:
[12:56] <pochu> x-session-manager[2806]: DEBUG(+): GsmXSMPClient: Client '0x9d30d60 [nautilus 1085cb869e1fb01e122114555464300900000028060051]' received SaveYourselfDone(success = True)
[12:56] <pochu> x-session-manager[2806]: DEBUG(+): GsmXsmpServer: sms_error_handler (0x9d5a210, FALSE, 3, 9, 32771, 0)
[12:56] <pochu> x-session-manager[2806]: DEBUG(+): GsmXsmpServer: ice_io_error_handler (0x9d595d8)
[12:56] <pochu> not sure if that's related to the ipod or it's a different issue
[12:56] <seb128> different one
[12:56] <pochu> hey pedro_!
[12:57] <pochu> seb128: ok, I'm going to try with a new user
[12:57] <pochu> thanks
[12:57] <pedro_> morning pochu!
[12:57] <seb128> hello pedro_
[12:57] <pedro_> salut seb128
[12:58] <lool> pochu: I can't mount USB keys in nautilus anymore
[12:59] <lool> pochu: I think you suffer from the same symptoms
[13:00] <seb128> mvo_: hum, bug #268636 no
[13:00] <seb128> mvo_: the duplicate is using 1:2.23.90-0ubuntu8
[13:00] <pochu> lool: lool right, just tried an usb stick and the same happens
[13:01] <pochu> i.e. it shows in Places, but if I try to open it nothing happens
[13:01] <pochu> even if I right-click and "open in new window", nothing
[13:02] <seb128> anything in /var/log/syslog or /var/log/message about that
[13:05] <lool> * Bug fixes: 546971 - rhythmbox crashed when ejecting an ipod device
[13:05] <lool> in gvfs 0.99.7
[13:08] <pochu> seb128: I lost the connection
[13:08] <pochu> http://pastebin.com/f5692120d
[13:08] <pochu> that's /var/log/messages
[13:08] <seb128> lool: what about it?
[13:08] <lool> Just a guess
[13:08] <seb128> pochu: nothing special there
[13:09] <lool> I had a gvfs update to <IP_ADDRESS> on the 9th, and now things are borken
[13:09] <seb128> lool: that was a ref counting issue, I doubt it breaks mounting
[13:09] <pochu> and syslog: http://pastebin.com/f570b3286
[13:09] <lool> I didn't downgrade, but it's first thing I'd suspect
[13:09] <pochu> (the output of "grep -A 10 -B 10 -i usb /var/log/syslog")
[13:09] <seb128> lool: and we had the patch in the previous version
[13:09] <lool> ok
[13:18] <pochu> could it be a kernel issue?
[13:19] <pochu> I can reboot into the new and shiny -3 ;)
[13:21] <seb128> hey mvo_
[13:21] <seb128> mvo_: did you read what I wrote before?
[13:26] <mvo_> seb128: no?
[13:26] <mvo_> seb128: sorry, dropped offline, the line is bad today
[13:26] <seb128> mvo_:   bug #268636, the duplicate uses 1:2.23.90-0ubuntu8, so you closed it wrongly
[13:27] <seb128> mvo_: and bug #269328 for you to sponsor, typo in the string you added
[13:27] <mvo_> thanks seb128, checking
[14:37] <andreasn> seb128: regarding https://wiki.ubuntu.com/IntrepidMenusReview, I fixed the xsane icon thing on my own system, but how do I forward these changes to you? diff the desktop file and send a patch?
[14:38] <andreasn> seb128: I more or less just changed one line of text
[14:38] <seb128> andreasn: what format is used for the icon? diff or attach the new icon to launchpad
[14:38] <seb128> andreasn: and subscribe the ubuntu-main-sponsors team too
[14:38] <andreasn> seb128: I just changed icon=xsane to icon=scanner
[14:39] <seb128> andreasn: ah, easy enough, so yes just the diff on a bug would be nice ;-)
[14:39] <andreasn> all right, will do
[14:39] <seb128> thanks!
[14:45] <mvo> seb128: just to clarify, gnome-session now uses gnome-wm again and that uses /desktop/gnome/applicatons/window_manager/default again?
[14:46] <seb128> mvo: yes
[14:46] <mvo> thanks
[14:46]  * mvo updates the g-c-c patch
[14:50] <seb128> mvo: what is wrong in the patch?
[14:51] <seb128> mvo: the code uses /desktop/gnome/session/required_components/windowmanager, not sure if we should rather change this one and update gnome-wm to use it too
[14:51] <seb128> vuntz: ^
[14:56] <vuntz> yes, use the upstream key if possible :-)
[14:57] <mvo_> seb128: the patch currently writes this location but that does not seem to be sufficient
[14:57] <mvo_> I don't mind either way
[14:58] <seb128> vuntz: what is the upstream key? the
[14:59] <seb128> mvo_: use the required_components one rather then
[14:59] <vuntz> seb128: /desktop/gnome/session/required_components/windowmanager,
[14:59] <seb128> ok, what I though, thanks
[14:59] <mvo_> will gnome-session run what is found there?
[15:00] <mvo_> or will gnome-session run gnome-wm regardless?
[15:00] <seb128> mvo_: arg, tricky
[15:00] <seb128> mvo_: gnome-session will run what is in /desktop/gnome/session/required_components/windowmanager
[15:00] <seb128> which is gnome-wm in intrepid
[15:00] <seb128> if we don't do that we don't have fallback working
[15:02] <seb128> now, not sure if the capplet should change this one
[15:02] <mvo_> hm, the fallback is part of the compiz startup script. or does gnome-session get confused when instead of compiz suddently metacity registers itself
[15:02] <seb128> or if we should always use gnome-wm and let do it the logic
[15:03] <seb128> mvo_: that should not be the case but gnome-wm handles lot of other case, openbox users for example
[15:03] <mvo_> ok, cool
[15:04] <seb128> "cool"? I'm still not clear what we should do ;-)
[15:08] <mvo_> "cool"> that gnome-session does not get confused
[15:08] <seb128> ;-)
[15:08] <mvo_> I have a look into the gnome-session source now
[15:10] <mvo_> ok, so the current patch in g-c-c writes to the wrong gconf location anyway :)
[15:10] <mvo_> that explains the issues I see
[15:13] <seb128> ok
[15:13] <mvo_> let go with modifiying /desktop/gnome/session/required_components/windowmanager in the appearance cpaplet
[15:13] <mvo_> I think that way users who are looking at the documentation to see where the window manager is set will find the right answer
[15:14] <mvo_> instead of having to go via gnome-wm to yet another location
[15:14] <mvo_> what do you think?
[15:23] <mvo> seb128: sorry, line dropped *again*
[15:23] <seb128> re mvo
[15:23] <mvo> seb128: I hit my router hard with a hammer now, should be better :)
 let go with modifiying /desktop/gnome/session/required_components/windowmanager in the appearance cpaplet
[15:23] <mvo>  I think that way users who are looking at the documentation to see where the window manager is set will find the right answer
[15:23] <mvo>  instead of having to go via gnome-wm to yet another location
 what do you think?
[15:23] <seb128> mvo: works for me
[15:23] <mvo> thanks!
[15:24] <seb128> thank *you* for looking at that ;-)
[15:28] <mvo> seb128: excellent, seems to work and is commited to bzr now \o/
[15:28] <seb128> mvo: good job ;-)
[15:41] <mpt> tedg, reasons for the status menu to be first: * Usually used more often, by those who use it at all. * Strengthens the connection between the icon in the menu and the icons for the status items. * Switching accounts and lock/shut down/etc are more closely related than changing status and lock/shut down/etc are.
[15:41] <tedg> mpt: http://people.ubuntu.com/~ted/fusa-screenie-2008091209.png
[15:42] <tedg> mpt: Yeah, I agree.
[15:42] <mpt> However...
[15:42] <tedg> I think it also means we could go back to indenting the names and having "Switch User" above them -- which I liked better.
[15:43] <mpt> tedg, reasons for the list of accounts to be first: * Applicable more often (assuming the guest account is on by default). * Strengthens the connection between the name in the menu title and the names of the other accounts. * It's possible that future versions will have more complex status stuff, e.g. a field for you to enter custom status text, or to do twittering, or whatever.
[15:43] <tedg> We need to solve the users with the same real name problem.
[15:44] <mpt> (By "applicable more often" I mean "applicable to more people", since not everyone uses IM.)
[15:44] <tedg> I don't have numbers, but I'm guessing that more people us IM than FUS.
[15:45] <tedg> Especially on the cases of "Single user laptop"
[15:45] <mpt> hmm, likely
[15:47] <tedg> We should make that into a term.  SUL.    They're discussing jockey terms.
[15:51] <mpt> tedg, I'm one of "they"
[15:53] <tedg> mpt: Sorry, you're a different color in that window :)
[15:55] <mpt> tedg, report a bug :-)
[15:57] <tedg> Heh, perhaps, but I'm trying to cut down on Karma. ;)
[16:02] <glatzor> mvo__, hi
[16:02] <mpt> tedg, this is the ideal menu for social climbers. It's all about status and power.
[16:04] <tedg> mpt: I think you should propose that for the name -- social climbing menu.
[16:08] <andreasn> tedg: is this ready for Ibex or the one after it? might be nice to use the same icons as Pidgin if for Ibex.
[16:09] <andreasn> to make the graphic connection stronger
[16:10] <tedg> andreasn: It's for Intrepid.  I don't know, I kinda want to push towards Empathy ;)
[16:10]  * andreasn should try to get these into the base icon set anyway
[16:11] <tedg> I used the icon naming spec names, so they'll probably get themed by everyone.
[16:11] <tedg> So I imagine it won't match Pidgin anyway in the end.
[16:11] <andreasn> how sneaky of you ;)
[16:12] <tedg> andreasn: Yeah, you know those artists, you have to manipulate them in subtle ways :)
[16:13] <andreasn> you mean like "crap, we want consistency at every cost, crap, might as well change the IM client!"? :)
[16:29] <tedg> mpt: What's you're plan?  Should I start something new, or wait for a quick turn around on some menu shuffles?
[16:29] <tedg> s/you're/your/
[16:32] <mpt> tedg, Mark has been in a meeting for a while so I wouldn't expect a quick turnaround
[16:33] <tedg> mpt: 'k, I'll break other things then :)
[16:34] <mpt> and now it's time for me to find problems with intrepidly exiting
[17:11] <pochu> seb128, lool: usb stick mounts fine now
[17:12] <andreasn> seb128: oh, I already sent a patch last year
[17:12] <pochu> I didn't have nautilus/gnome-panel/ubuntu-desktop installed
[17:12] <andreasn> https://bugs.launchpad.net/ubuntu/+source/xsane/+bug/129687
[17:12] <pochu> I've reinstalled them, and it works now
[17:17] <crevette> pochu: a I had that too yesterday
[17:17] <crevette> I was quite surprised
[17:21] <pochu> I think it's update-manager's fault
[17:31] <pochu> mvo__: wasn't there an update-manager bug about it removing essential packages with the partial upgrade thing?
[17:33] <pochu> ah, bug 219444
[18:07] <mpt> vuntz, hi, what's your preferred medium for small tweaks to make to the Log Out and Shut Down dialogs? E-mail message? b.g.o bug reports?
[18:07] <mpt> A single omnibus bug report?
[18:11] <johanbr> Speaking of which, I noticed that pressing the power button now only gives me the option to log out or switch users. That seems a little illogical.
[18:13] <vuntz> mpt: probably best to add comments to the upstream bug about this
[18:13] <vuntz> http://bugzilla.gnome.org/show_bug.cgi?id=507101
[18:19] <tedg> mpt: GNOME is in hard code freeze -- so if we want something for Ubuntu, we'll probably have to distro patch it.
[18:20] <mpt> joy
[18:49] <bertoldia> pitti? Axel here.
[18:49] <pitti> oh, hey bertoldia!
[18:49] <bertoldia> hey!
[18:49] <bertoldia> just got your last email after having sent mine.
[18:50] <bertoldia> I happy to travel to Portland or to to do it over the phone.
[18:51] <bertoldia> Whatever is more convenient for you.
[18:52] <pitti> bertoldia: sorry, X just crashed (doing some debugging); did you say anything after your mail ack?
[18:53] <bertoldia> I'm happy to travel to Portland or to do it over the phone.
[18:53] <bertoldia> Whatever is more convenient for you.
[18:53] <pitti> bertoldia: well, meeting in person is always nice, it just sounded like a lot of effort for an hour of talking :)
[18:55] <bertoldia> pitti: I'm happy to do it.
[18:55] <bertoldia> I also have friends there to visit.
[18:56] <pitti> bertoldia: ok, great! see you next Thursday then
[18:56] <bertoldia> Pitti: Great! See you then!
[18:56] <bertoldia> Cheers.
[19:04] <pochu> johanbr: there's two buttons/dialogs now, you were probably pressing the logout/switch users one ;)
[19:04] <james_w> I've just restarted my session and I don't get a functioning desktop back, I get a mouse pointer and the desktop background, but no panel etc.
[19:04] <james_w> has anyone seen this?
[19:05] <johanbr> pochu: I was pressing the physical power button on my laptop.
[19:05] <pochu> oh
[19:05] <pochu> james_w: yes, install ubuntu-desktop!
[19:05] <vuntz> tedg: the patch is not committed upstream, so we don't care about hard code freeze. It's just a patch in a bug
[19:05] <james_w> cripes! thanks pochu
[19:06] <pochu> james_w: bug 269409
[19:06] <james_w> thanks
[19:06] <pochu> james_w: thank pedro_ who helped me before :)
[19:06] <james_w> thanks pedro_ :-)
[19:07] <tedg> vuntz: Ah, okay.  mpt, also.
[19:07] <pedro_> you're welcome ;-)
[19:08]  * mvo goes to fix that
[19:08]  * pochu hugs mvo
[19:22] <mpt> vuntz, done
[20:22] <geser> does libgail-dev got merged into libgtk2.0-dev?
[20:40] <mvo> pochu: could you put your apt.log file somewhere? I'm curious what might have cause the removal of ubuntu-desktop for you


[16:33] <bdmurray> wxl: could you test bug 1442898 for me?
[16:57] <wxl> bdmurray: doing about 5 million things at once but will get to it or delegate and update the bug. btw if there was a bug in a seed, what package would i file against?
[16:59] <bdmurray> wxl: the relevenat metapackage is probably a good spot
[16:59] <wxl> bdmurray: oh i could probably use lubuntu-meta come to think of it
[17:00] <bdmurray> right


[04:19] <Laibsch> Can somebody please verify whether or not bug 379382 also occurs in oneiric?
[04:19] <ubot4> Launchpad bug 379382 in gnome-utils (Ubuntu) (and 1 other project) "gnome-screenshot (Alt-Printscreen) black/blanks out top of windows in multi monitor xinerama (affects: 16) (heat: 61)" [Low,Triaged] https://launchpad.net/bugs/379382
[07:02]  * stjohnmedrano is away: Away lang!.
[14:21] <njin> Hello can someone set status triaged importance medium for me, thanks
[14:22] <njin> bug 825238
[14:22] <ubot4> Launchpad bug 825238 in casper (Ubuntu) (and 1 other project) "screen reader does not start in a11y installation (affects: 1) (dups: 1) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/825238
[18:38] <hggdh> bug-controllers: please note we have an application to review
[21:43] <bigbash> I was looking to join BugSquad and was reading how to request a mentor, is the Ubuntu Wiki-page it's referring to in step 2 your information on Launchpad or am I missing something?


[03:06] <lotuspsychje> good morning
[16:40] <Kon-> Hi, I thought all the apt installing snaps were just aliases, but it looks like it pulls a snap install script from the repos :(
[16:40] <Kon-> Is there anything else that does this except Chromium?
[16:51] <oerheks> softwarecenter is mixed with deb and snap packages, see the description
[16:52] <Kon-> I know all about that. Not asking about softwarecenter
[16:53] <oerheks> so explain ' apt installing snaps were just aliases' ?
[16:53] <Kon-> Currently if the user opens the terminal and enters 'sudo apt install chromium-browser' it pings the ubuntu repositories as normal, and the repository sends back a snap install script
[16:53] <oerheks> chromium is available as snap AND deb
[16:54] <Kon-> What apt command do I need to enter to get the deb?
[16:55] <Kon-> It's described as a Transitional package - chromium-browser -> chromium snap
[16:55] <Kon-> https://packages.ubuntu.com/focal/chromium-browser
[16:57] <oerheks> oh, it is snap solely .. indeed > https://launchpad.net/ubuntu/+source/chromium-browser/80.0.3987.87-0ubuntu1
[16:57] <Kon-> But more importantly, I was wondering if there are any more of these "transitional packages" in the apt repositories
[16:57] <Kon-> of deb to snap
[16:57] <TJ-> it's becoming ridiculous tracking them
[16:58] <Kon-> That sounds like a yes then?
[17:02] <Kon-> tbh I'm not here to rag on Ubuntu but trying to figure out how this will impact community spins and/or my workflow if Ubuntu starts removing software from the apt repositories
[17:04] <oerheks> i think in the chromium situation, developers needed an universal distribution tool. laque of chromium supporters gave publishing delays of days/weeks
[17:07] <TJ-> says a lot about the bugginess of such packages though doesn't it? We've got used to frequent updates and don't think it a bad thing, when in fact it shows the applications are not well-engineered
[17:08] <oerheks> that is what the debian crew say too
[17:09] <Kon-> Fair, Chromium does require
[17:09] <Kon-> a lot of attention from the distro
[17:10] <Kon-> But again, can anyone name a similar decision regarding at least one package not directly tied to Chromium? TJ-'s comment seemed to suggest there were others
[17:11] <TJ-> Kon-: lxd, many of the gnome parts
[17:11] <oerheks> calculator is a standard snap, though gnome-calculator is in the repos
[17:12] <Kon-> Yes, I saw calculator is going back to deb as default. I think that was a good move
[17:13] <TJ-> on the ISOs:
[17:13] <TJ-> snap:core stable 8689
[17:13] <TJ-> snap:core18 stable 1668
[17:13] <TJ-> snap:gnome-3-34-1804 stable/ubuntu-20.04 21
[17:13] <TJ-> snap:gtk-common-themes stable/ubuntu-20.04 1474
[17:13] <TJ-> snap:snap-store stable/ubuntu-20.04 308
[17:25] <Kon-> Thanks TJ- but I wasn't concerned with the defaults on the ISO, just the apt repositories. I'm satisfied as long as deb access remains possible
[17:25] <Kon-> So I did look it up
[17:25] <Kon-> Packages currently removed from the repository include all packages covered by the snaps:
[17:25] <Kon-> chromium, chromium-ffmpeg, lxd, maas, snapcraft
[20:44] <feoh> Hi all.
[20:45] <feoh> Since we ship Thunderbird as the default GUI email clinet
[20:45] <feoh> Client
[20:46] <feoh> It's kind of a shame given how hard Ubuntu has worked to make the distro accessible, that Thunderbird itself is totally unusable for low vision people
[20:46] <feoh> Does anyone have a sense of where I should report that or who I should talk to?
[20:47] <feoh> Maybe I'll just poke around Launchpad and see where it gets me :)
[20:58] <Rounin> So, I've noticed one new change since upgrading to 20.04... I'm using KDE, right, and every GTK application has the numeric Unicode replacement font as its interface font
[20:58] <Rounin> Other fonts show just fine, but the GUI is exclusively in hex codes
[20:59] <Rounin> This is a great feature to earn hacker cred, obviously
[21:01] <Rounin> I wonder if it's the font "Sans" that's doing it... My IRC client was using it too, and text showed up as hex there too, until I switched
[21:01] <Rounin> I guess Sans isn't a thing anymore
[21:02] <feoh> Heh
[21:02] <feoh> Are you running Kubuntu?
[21:02] <feoh> (You can use KDE with mainline Ubuntu if you install the meta-package)
[21:03] <Rounin> Two seconds... I tried switching fonts again... Now it's all hex
[21:03] <Rounin> The problem seems to be URW Gothic L
[21:04] <Rounin> feoh: kubuntu-desktop is installed at least, so it seems to be that
[21:04] <feoh> You would have had to choose the Kubuntu ISOs :)
[21:05] <Rounin> I upgraded with upgrade-manager
[21:05] <Rounin> My original install was from stone tablets
[21:05] <feoh> What does lsb_release -a say?
[21:05] <Rounin> feoh: Ubuntu Focal Fossa
[21:06] <feoh> So you're running stock Ubuntu but installed the KDE meta package.
[21:06] <Rounin> Who knows at this point
[21:06] <Rounin> Hm... At the very least, the font URW Gothic L seems to now be called URW Gothic... So I guess I'm using that for the GUI, and it's falling back to hex codes for some reason
[21:07] <valorie> feoh: release-a will always say Ubuntu
[21:07] <valorie> mine does and I run stock kubuntu
[21:09] <Rounin> gtk-font-name=URW Gothic L, Book 10
[21:09] <Rounin> That seems to be it
[21:20] <Rounin> Phew
[21:20] <Rounin> Apparently, lxappearance from LXDE was what was needed to change the font