[00:50] <qengho> chasinglogic: Enough of snappy was in 16.04 kernel and apparmor that it can run there. We're not backporting to something like the soon-to-expire-anyway 2015 releases.
[00:51] <chasinglogic> qengho: I didn't expect it to be backported, I was just looking for the newest version. But I also don't want to start playing with 15.04 if I can't upgrade it when 16.04 comes out
[00:56] <qengho> chasinglogic: Let's make sure we're talking about the same thing. Ubuntu 16.04 LTS was released in 2016-04. It had snappy functionality, but no official release of Snappy. I think(!) Ubuntu is releasing Snappy images for the first time, based off of Ubuntu 16.04 soon.
[00:56] <chasinglogic> I'm talking about Ubuntu Snappy Core the distribution
[00:57] <qengho> Okay. That doesn't exist yet. It's in progress.
[00:58] <chasinglogic> qengho: correct, that's the info that zyga gave me so I'm just waiting
[00:58] <chasinglogic> :D
[01:00] <qengho> chasinglogic: Though, installing "snapd" on a Ubuntu 16.04 gets you what it will look like, inside. You don't have to wait to get started. You have to wait to get an image to put on a embedded device.
[01:00] <qengho> ^embedded^small
[01:01] <chasinglogic> qengho: Yeah I've been playing with snaps and snapcraft on my desktop and laptop, I'm looking for something coreos-esque to make clusters out of. (and I'd like to convert my pi to snappy core)
[01:01] <qengho> Ah, right. Soon.
[01:41] <liuxg> elopio, ping
[01:42] <thomi> if a snapped command dumps it's core, any ideas where it ends up on disk?
[01:50] <liuxg>  in the tutorial at http://snapcraft.io/create/, it teaches us  to use "hello" to run the example, however, in the second example, it askes us to run it by using "hello-debug.hello" (package_name.<name under apps>.  Previously, the second one was the way for ubuntu core. what is the correct way to run an app?
[01:54] <mup> PR snapcraft#639 opened: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/639>
[01:54] <elopio> liuxg: hello
[01:55] <liuxg> elopio, I found a very strange problem. at the link http://snapcraft.io/create/, for the first tutorial, I can run the app using "hello", however, I cannot run it using "hello.hello"
[01:56] <liuxg> elopio, if I change the package name to "hello1" like http://paste.ubuntu.com/18752046/, then I can run it using "hello1.hello". However, hello does not run any more. is this a bug?
[01:57] <elopio> liuxg: if your command has the same name as the snap, then the command will not have the .
[01:58] <elopio> in the tutorial example, the snap should be only hello. Not hello.hello.
[01:58] <elopio> in your case when you renamed the snap, then hello1.hello is the right name for the command. So unless I misunderstood your comments, thats by design.
[01:59] <liuxg> elopio, is this a special case? the package name and name under "apps" are the same. we cannot use "."　to run it?
[01:59] <elopio> thomi: what do you mean with "dumps it's core"?
[02:00] <elopio> liuxg: yes. The no foo.foo, just foo.
[02:00] <liuxg> elopio, would you please point me to the design doc for it? thanks
[02:01] <liuxg> elopio, I want to have a better understanding about the design. As a tutorial, it is not inconsistent for the tutorials there, and it causes confusion to developers.
[02:04] <elopio> liuxg: no, sorry, that was too long ago.
[02:05] <elopio> I have no idea if there ever was a document.
[02:06] <liuxg> elopio, I think it is good to point out to developers. it is truly a little confusing. Anyway, I know it from you :) In fact, I tried to figure it out by playing it.
[02:08] <qengho> liuxg: When the app name is the same as the package name, only the package name is used to construct the executable name. When they're different, you prefix the app name with the package name and ".".
[02:08] <elopio> liuxg: oh, look, I found the PR: https://github.com/snapcore/snapd/pull/688
[02:08] <mup> PR snapd#688: snappy: support generation of short binary names  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/688>
[02:08] <liuxg> qengho, thanks. I know it now
[02:10] <liuxg> elopio, thanks for the help. we just need to document it somewhere.
[02:10] <elopio> sure. File a bug please.
[02:14] <liuxg> elopio, which project should I file against? would you please give me a link for it? thanks
[02:15] <elopio> liuxg: the link is at the bottom of the snapcraft.io page.
[02:15] <liuxg> elopio, ok. I got it. thanks
[02:16] <thomi> elopio: as in after a segfault
[02:16] <thomi> elopio: but I think I figured it out anyway
[02:37] <liuxg> when i am trying to install a snap, the very first installation seems to have errors. However, the second installation is successful http://paste.ubuntu.com/18754704/, what is the reason for it? thanks
[02:44] <mup> Bug #1600083 opened: 'snap' tool bash completion does not complete local file names <Snappy:New> <https://launchpad.net/bugs/1600083>
[02:50] <mup> Bug #1600085 opened: interface for making bpf syscalls <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1600085>
[03:02] <mup> Bug #1566604 changed: the snap command has no autocompletion <Snappy:Fix Released> <https://launchpad.net/bugs/1566604>
[03:30] <mup> PR snapcraft#639 closed: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/639>
[03:44] <liuxg> does anyone know how to stop a running snap service?
[03:50] <ljp> liuxg: sudo systemctl stop snapd.service snapd.socket
[03:51] <stevebiscuit> arges: client.Find() *only* returns the snaps available on the store, I've had to merge the result from that and client.List() to simulate the *old* behaviour for snapweb: https://github.com/snapcore/snapweb/pull/31 . We could maybe introduce something similar to the client lib if there's demand for apps other than snapweb
[03:51] <mup> PR snapweb#31: Show installed snaps in store listing <Created by stevenwilkin> <https://github.com/snapcore/snapweb/pull/31>
[03:52] <liuxg> lpotter, thanks. I have a webserver service like "hello-world-service". it has the port number 8000. how to stop it?
[03:54] <liuxg> lpotter, on ubuntu core, it used to have "snap services status",  and we can use "stop" or "start" command to manage it.
[03:58] <lpotter> might try something like systemctl stop snap.<snap_name>.<command>.service
[04:29] <17SAAMNLJ> lpotter, thanks, it works.
[05:13] <RyanTG> If I have vlc-2.2.2-5 via apt and vlc-daily via snap, why does the apt version take precedence when I go to launch it?
[05:30] <RyanTG> Is it a path ordering problem?
[05:33] <tsimonq2> RyanTG: try uninstalling vlc from apt
[05:45] <qengho> RyanTG: Yeah, you have two programs with the same name. If you want one, use its full path.  /snap/bin/vlcsomething or /usr/bin/vlcsomething
[06:02] <mup> PR snapd#1513 opened: tests: readd the fake store tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1513>
[06:10] <liuxg> when I am trying to build the example at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui on 16.04 desktop, my snapcraft version is 2.12. I get the error like :Error downloading stage packages for part 'cam': no such package'fswebcam' . what could be the problem for it? thanks
[06:12] <RyanTG> tsimonq2: I did uninstall vlc using apt-get purge, but i'm concerned about the day trying to remove an apt package wants to remove a lot of other stuff with it, or gets reinstalled if it's part of a meta-package like *-desktop
[06:20] <tsimonq2> RyanTG: I think it's fine :)
[06:25] <mup> PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514>
[06:34] <dholbach> hey hey
[06:35] <mup> PR snapd#1491 closed: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1491>
[06:36] <mup> PR snapd#1442 closed: many: allow removal of broken snaps, add spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1442>
[06:43] <qengho> RyanTG: Suggest something. You have two packages installed that provide the same program. What do you propose should happen?
[06:44] <qengho> Many service programs are rightly programmed to disallow running as root. What should we do for their snaps?
[06:46] <RyanTG> qengho: I'm not sure what should happen. When I first installed it, I knew I already had vlc from apt. I wanted to see what would happen.  I thought there would be a good chance of vlc showing up twice in my menu (maybe that happens in dash, but I don't use dash).
[06:47] <RyanTG> I use classicmenu-indicator
[07:59] <mup> PR snapd#1513 closed: tests: readd the fake store tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1513>
[08:04] <mup> Bug #1600136 opened: App indicator does not show icon for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600136>
[08:07] <mup> Bug #1600138 opened: App indicator does not show menu entries for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600138>
[08:11] <mup> PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1514>
[08:16] <Dubstar_04> Good Morning, I'm having issues with Nvidia drivers and snaps. If i use the Nouveau drivers it works fine. Is there anything I can do?
[08:19] <mup> Bug #1600140 opened: App indicator adds an entry for each snap launch <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600140>
[08:27] <mup> PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514>
[08:32] <mup> PR snapd#1515 opened: asserts,daemon: cross checks for account and account-key assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1515>
[08:35] <mcphail> Dubstar_04: gl errors? I get that too
[08:56] <mup> Bug #1600154 opened: Reading gsettings key don't work locally (writing does) <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600154>
[09:00] <zyga> Dubstar_04: hey
[09:00] <zyga> Dubstar_04: we're are aware of the issue, can you tell me which distribution you are using
[09:00] <zyga> Dubstar_04: on ubuntu the fix is not fully released yet
[09:19] <liuxg> didrocks, I just removed my snapcraft which was verion 2.12. Now, i want to try to install it again. do i need to add any ppa?
[09:19] <didrocks> liuxg: xenial?
[09:20] <liuxg> didrocks, yes
[09:20] <didrocks> liuxg: no, the version in the distro (2.12) should be the one you would use
[09:20] <liuxg> didrocks, I used the command "sudo apt-get install snapcraft",  but it complains "Unable to locate package snapcraft"
[09:21] <liuxg> didrocks, I am trying to isolate the problem, so I removed my previsous snapcraft
[09:21] <didrocks> it's in universe
[09:21] <didrocks> same than my answer on the ML
[09:21] <didrocks> you did remove universe, from your system
[09:21] <liuxg> didrocks, how can I add it back?
[09:22] <didrocks> liuxg: how did you remove it, you have two ways, command line (changing the sources.list file or UI)
[09:22] <liuxg> didrocks, i just did it by "apt remove snapcraft"
[09:22] <didrocks> no, you removed universe explicitely on your system I would say
[09:22] <didrocks> (that was before)
[09:23] <didrocks> in "update" (or whatever it is in english -> ensure that universe is ticked
[09:23] <liuxg> didrocks, I do not remember it clearly when I did that.
[09:24] <Dubstar_04> syga: i'm on ubuntu 16.04.
[09:24] <didrocks> liuxg: "software-properties-gtk"
[09:24] <didrocks> that's what you need to run
[09:24] <didrocks> ensure universe is checked
[09:24] <Dubstar_04> zyga: ^^
[09:24] <liuxg> didrocks, yes, it is on, then ...
[09:24] <didrocks> tick it off
[09:24] <didrocks> and then on
[09:24] <didrocks> but it can't be on from your output on the ML
[09:25] <didrocks> and the fact you are telling me you can't install snapcraft
[09:25] <liuxg> didrocks, is it the one "Community-maintained free and open-source software"?
[09:26] <didrocks> liuxg: exactly "(universe)" next to it
[09:27] <liuxg> didrocks, thanks. it is true. it was ticked off.
[09:27] <zyga> Dubstar_04: then this will be fixed with the next SRU
[09:27] <didrocks> ah, see! :)
[09:27] <Dubstar_04> zyga: superb. thanks.
[09:30] <liuxg> didrocks, is there any way to have an example for packaging a ubuntu phone app into snap?
[09:30] <liuxg> didrocks, I think this will be very useful to developers to show the convergence story.
[09:31] <liuxg> didrocks, one app runs on all platforms.
[09:31] <didrocks> liuxg: not yet, you can be the one creating it! :)
[09:31] <didrocks> liuxg: I think adding the right package deps + desktop/qt5 launcher should be enough
[09:32] <liuxg> didrocks, I have a little problem in building the ubuntu-clock example.
[09:32] <didrocks> from playpen?
[09:32] <liuxg> didrocks, yes
[09:32] <didrocks> that's the issue you mentioned on the ML, right?
[09:32] <didrocks> did you retry since you added universe?
[09:32] <didrocks> (as I told you, this was your problem there as well)
[09:33] <liuxg> didrocks, yes, I am now building it again to see what happens.
[09:35] <didrocks> keep me posted!
[09:35] <liuxg> didrocks, this time, I have a different issue http://paste.ubuntu.com/18772870/
[09:37] <didrocks> liuxg: this is a temporary failure from launchpad
[09:37] <didrocks> you need to apt get update
[09:37] <didrocks> and rerun
[09:37] <didrocks> (this can get 30 min to get sorted out)
[09:38] <liuxg> didrocks, OK. then I will wait and see. so, you are having the same problem with it?
[09:38] <didrocks> cjwatson: FYI, seems we can still have some hash sum mismatch (I thought they were all fixed) ^
[09:38] <didrocks> liuxg: no, it depends on your mirror
[09:38] <didrocks> liuxg: if you catch it at the wrong time
[09:38] <didrocks> so, try to sudo apt update
[09:38] <didrocks> and rerun a build
[09:38] <liuxg> didrocks, OK. I might need to change another one to see it. thanks
[09:38] <didrocks> if still failing the same way
[09:38] <didrocks> wait a little bit
[09:38] <didrocks> and redo :)
[09:38] <didrocks> keep us posted!
[09:39] <liuxg> didrocks, in fact, I did apt update before building the project.
[09:41] <liuxg> didrocks, I changed a mirror site, and it seemed better :)
[09:42] <liuxg> didrocks, thanks for your help
[09:42] <didrocks> liuxg: yw! :)
[09:43] <liuxg> didrocks, I am getting the .snap file :) it used to work for me. I think it was broken somehow.
[09:57] <cjwatson> didrocks: you can still have hash sum mismatches if sites have actual wrong content, yes.  that one isn't a problem with mirror structure
[09:58] <cjwatson> didrocks: (because files in pool/ have always had a unique mapping from URL->content - my recent fixes were about indexes because pool/ didn't need fundamental fixes)
[09:58] <cjwatson> didrocks: so no, that's *not* a temporary failure, and it's *not* a failure from Launchpad, it's just that one mirror being busted
[09:59] <cjwatson> didrocks: or possibly data corrupted in transit
[09:59] <mup> Bug #1600166 opened: Snap rely on dns-masq running on <IP_ADDRESS> instead of /etc/resolv.conf <Snappy:New> <https://launchpad.net/bugs/1600166>
[10:03] <mup> PR snapd#1516 opened: daemon: drop auther() <Created by chipaca> <https://github.com/snapcore/snapd/pull/1516>
[10:07] <didrocks> cjwatson: oh ok, I'm not expert enough to ensure those were valid corruptions or the races on the indexes we had. Ok, so now, we can only have valid mismatch, thanks for looking at it! :)
[10:08] <cjwatson> didrocks: right, you can tell it's not an index race just by seeing that the mismatch is on a file in pool
[10:08] <cjwatson> the previous hard case was always on something in dists
[10:10] <didrocks> ah ok, gotcha!
[10:11] <didrocks> TBH, I never looked closely than the error message, getting it now. (my bad)
[10:17] <Chipaca> dpm, good job on the notes snap work!
[10:17] <Chipaca> just saw the bugs and read all the pain :-)
[10:18] <dpm> Chipaca, thanks, kudos to didrocks to help me figuring them out! :)
[10:18] <Chipaca> ah, but we already know didrocks rocks. Oxymoronic, really.
[10:20] <didrocks> :-)
[11:28] <mup> PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1514>
[12:37] <szszsz> Hi! Is there any difference between installing snappy package with sudo and without it?
[12:38] <mup> PR snapd#1516 closed: daemon: drop auther() <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1516>
[12:44] <jdstrand> zyga: I see you merged 73 (good-- I was hoping you saw my comment that it was fine to merge :)
[12:44] <zyga> jdstrand: yep
[12:44] <zyga> jdstrand: I'm going to cut the release shortly, I just feel sleepy and I'm rading some suse manuals
[12:45] <zyga> jdstrand: I'll just do it now
[12:45] <jdstrand> I imagine that would do that to you :)
[12:45] <zyga> no, that's not related ;>
[12:45] <zyga> suse is pretty interesting, many new concepts
[12:46] <zyga> I should just sleep more ;)
[12:48] <Odd_Bloke> szszsz: I believe there is a difference, but I'm not a snappy person so I don't know exactly. :)
[12:49] <zyga> szszsz: no,
[12:50] <zyga> szszsz: it allows you to install the package if you are signed in
[12:50] <szszsz> Odd_Bloke: zyga: OK, thanks!
[12:55] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/76
[12:55] <mup> PR snap-confine#76: Drop the alternative to ROOTFS_IS_CORE_SNAP <Created by zyga> <https://github.com/snapcore/snap-confine/pull/76>
[12:56] <zyga> jdstrand: not critical, I'll cut the release now without this patch landing
[13:00] <jdstrand> zyga: commented
[13:00] <jdstrand> zyga: a welcome change :)
[13:03] <sborovkov> Hello, are there any news about ubuntu-image
[13:03] <zyga> sborovkov: not sure, try to ask slangasek
[13:04] <zyga> jdstrand: 1.0.36 is out
[13:05] <zyga> jdstrand: I'll do the packaging honors :)
[13:06] <sborovkov> slangasek: Hi, what's the status of ubuntu-image?
[13:06] <sborovkov> Also are there any news about gadget snap spec being finalized? I remember that was blocking for /dev/vchiq on RPI
[13:13] <jdstrand> zyga: cool, thanks!
[13:19] <zyga> jdstrand: BTW, your regression tests have some if ! something; then exit 1; fi lines
[13:19] <zyga> jdstrand: all of the script runs under set -e
[13:19] <zyga> jdstrand: so that is redundant, each failing line fails the test
[13:19] <jdstrand> zyga: I saw your review, I'll be going through that and all the interface PRs after I get through emails
[13:20] <zyga> jdstrand: thanks!
[13:20] <jdstrand> fyi, I'll be on holiday until Jul 20th starting Sat
[13:20] <zyga> jdstrand: I'll try to help with interfaces but I'm super slow lately
[13:20] <zyga> must be summer :/
[13:20] <zyga> ah, nice
[13:20] <zyga> I plan to have holiday early August
[13:20] <jdstrand> but tyhicks can do policy reviews in my absence. I'll send a Where's Jamie later today
[13:20] <jdstrand> zyga: nice! :)
[13:38] <ysionneau> is it possible when declaring systemd services in the snap, to setup dependencies between services?
[13:40] <didrocks> ysionneau: no, I think that goes with the bigger bug "enable setting up your own entries in the .service file"
[13:40] <didrocks> ysionneau: you aren't stuck and can hack it though :p
[13:41] <didrocks> (as the .service file is rw, you can change it after installing your snap)
[13:41] <didrocks> even from another service
[13:41] <didrocks> (yeah, it's a hack)
[13:42] <kyrofa> didrocks, dpm-bbiab thanks for tracking down the app indicator bug, it's been bothering me
[13:43] <didrocks> kyrofa: yw! I'm going to fix the apparmor policy, at least, we will have the menu appearing
[13:43] <didrocks> (and won't block process anymore)
[13:43] <didrocks> the icon one… I'm puzzled and unsure how we can fix it
[13:44] <kyrofa> didrocks, ah right, I meant the icon one. The other one should be a bit easier... the icon is tough
[13:44] <didrocks> because this file is generated just before sending the dbus call
[13:44] <didrocks> not at install time, not at startup time…
[13:44] <kyrofa> Indeed
[13:45] <kyrofa> And we definitely don't want to patch unity
[13:45] <didrocks> right, because, what about other shells?
[13:45] <didrocks> and other distros?
[13:45] <kyrofa> Exactly
[13:45] <kyrofa> Curious to hear jdstrand's thoughts on that one
[13:45] <didrocks> yep
[13:46] <mvo> mwhudson: hi, I heard rumors you have some clues about the yakkety autopkgtest failures? I'm super curious to learn more :)
[13:47] <jdstrand> I just responded to the bug actually. perhaps my comments might provide inspiration for a solution
[13:54] <ysionneau> didrocks: ok :)
[13:54] <kyrofa> Thanks for the thoughts jdstrand. So snaps can write to the system /run/shm/ ?
[13:54] <ysionneau> didrocks: another thing, it seems you can to daemon: oneshot, but then it fails because Restart=on-failure in the unit file
[13:55] <ysionneau> systemd wants Restart=no
[13:55] <ysionneau> but you cannot say restart-condition: no in the yaml, it is refused :x
[13:55] <jdstrand> kyrofa: they can write to<EMAIL_ADDRESS>[13:55] <kyrofa> ysionneau, indeed, I made a bug for that a week or two ago
[13:55] <ysionneau> you can say restart-condition: never, but this is not accepted by systemd
[13:55] <ysionneau> so 1°) oneshot is basically un usable, and 2°) Restart=no/never does not work
[13:55] <kyrofa> jdstrand, ah okay, but it's not namespaced like /tmp?
[13:56] <ysionneau> kyrofa: do you have the bug id please?
[13:56] <jdstrand> kyrofa: it doesn't matter if it is a file or a directory or a directory tree
[13:56] <kyrofa> jdstrand, the snap and system see the same /run/shm?
[13:56] <kyrofa> Nice, okay
[13:56] <jdstrand> kyrofa: it is namespaced (noticed SNAP_NAME) but it isn't mount namespaced. ie, it is in the global namespace
[13:57] <kyrofa> ysionneau, bug #1595661
[13:57] <mup> Bug #1595661: snapd uses "never" in systemd unit files when it should be using "no" <snapd (Ubuntu):New> <https://launchpad.net/bugs/1595661>
[13:57] <mup> PR snapd#1517 opened: wrappers: run update-desktop-database after add/remove of desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1517>
[13:57] <kyrofa> jdstrand, right, very good
[13:58]  * jdstrand notes that he always warned about a private /tmp would cause problems, but the /tmp problem is a difficult one
[13:59] <ysionneau> thanks kyrofa
[13:59] <kyrofa> jdstrand, the private tmp complicates things, but still makes sense I think
[14:00] <didrocks> jdstrand: interesting idea, I think that worth a shot
[14:01] <kyrofa> didrocks, is that icon stuff upstream Qt, or do we have ubuntu patches on top?
[14:01] <didrocks> kyrofa: it's upstream Qt in Qt5, we have sni-qt for qt4
[14:02] <kyrofa> Right, I remember that now
[14:02] <didrocks> (the indicator spec is based on KDE one)
[14:02] <didrocks> I worked on this years ago (not the main contributor), I have blurry memories of it, so, I don't know how much this is going to be easy
[14:02] <didrocks> it worthes a try at least
[14:04] <didrocks> jdstrand: oh btw, debugging the notes indicator, I'm going to add the apparmor profile needed updates for that, but debugging, I had another instance of messages that are in /var/log/syslog but not shown in scanlogs
[14:11] <mup> PR snapd#1518 opened: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1518>
[14:15] <kyrofa> didrocks, you've been doing amazing parts work, by the way
[14:15] <kyrofa> didrocks, very much appreciated
[14:18] <niemeyer> Hellos
[14:18] <niemeyer> ogra_: ping
[14:18] <ogra_> niemeyer, yo
[14:18] <niemeyer> ogra_: Heya
[14:19] <niemeyer> ogra_: Yesterday I went over a long trip on core images and initramfses
[14:19] <niemeyer> ogra_: One thing I learned is that our canonical-pc-linux doesn't currently support SCSI virtio.. we should fix that so we can support partvirtualization on those images
[14:19] <didrocks> kyrofa: thanks a lot :-)
[14:20] <ogra_> niemeyer, can you file a bug, i'll add it then
[14:20] <niemeyer> ogra_: Will do, and I have a question out of curiosity too
[14:20] <niemeyer> ogra_: our cmdline has init=/lib/systemd/systemd
[14:20] <ogra_> niemeyer, long term there is still the plan to have "two half initrds" ... but we first need images for this
[14:21] <ogra_> i assume that init= thing can go nowadays
[14:21] <ogra_> thats 15.04 legacy
[14:21] <niemeyer> ogra_: But that's inside partition 3, and under system-data
[14:21] <ogra_> well, it is on / after the initrd assmbled the rootfs
[14:21] <niemeyer> ogra_: Where do we tell the initramfs where to chroot to before running that
[14:22] <ogra_> we dont ... we assemble the rootfs first ... then we call run-init (which is another "pivot_root")
[14:22] <niemeyer> ogra_: Yeah, I understand there must be something pivoting into it.. the question is just where is that set
[14:22] <ogra_> assembly happens based on partition names
[14:24] <ogra_> not sure what you mean by "where is tha set" ... we assemble the rootfs under ... say /rootfs ... thats done by scripts in the initrd that look up the partiition names, mount teh right bits in the right places etc ... once that /rootfs is complete we pivot into it
[14:25] <jdstrand> didrocks: scanlog does not show dbus denials atm. there is a card for that
[14:26] <niemeyer> ogra_: Well, yeah, that's basically what an initrd is, isn't it :)
[14:26] <ogra_> (essentially it looks for the writable partiton, mounts the core snap in the target dir and then processes $target/etc/system-image/wriitable-paths to get the rw bind mounts in place ... relative to $target)
[14:26] <niemeyer> ogra_: The question is how that's expressed..
[14:27] <niemeyer> ogra_: How do we assemble that initrd so it does what we want.. there are a bunch of code there which is standard for every initrd, so I'm guessing this is not hand-coded every time, but rather has some proper configuration and conventions around it
[14:27] <ogra_> niemeyer, aah ...
[14:28] <ogra_> we use initramfs-tools from the distro ... and on top of that we use initramfs-tools-ubuntu-core ...
[14:28] <didrocks> jdstrand: ah, making sense. https://github.com/snapcore/snapd/pull/1519 btw
[14:28] <mup> PR snapd#1519: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519>
[14:28] <mup> PR snapd#1519 opened: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519>
[14:28] <niemeyer> Aha
[14:28] <ogra_> initramfs-tools itself has a hooks and scripts ability to override scripts and hooks with your own stuff
[14:28] <niemeyer> ogra_: Wheres the source of initramfs-tools-ubuntu-core?  I bet the answer to my questions are all there
[14:29] <ogra_> so initramfs-tools-ubuntu-core ships our assembly script that is run by the infra of initramfs-toools
[14:29] <ogra_> apt-get source ... there is no tree or anything
[14:29] <niemeyer> No repository?  Are we back at the 90s? :)
[14:30] <ogra_> you want scripts/ubuntu-core-rootfs http://paste.ubuntu.com/18789757/ ...
[14:30] <ogra_> nah, we're stuck in the 80s with that one ... 90s ... way to modern :P
[14:31] <ogra_> note that this script still carries 15.04 bits ... we need to drop them
[14:31] <niemeyer> Gotcha
[14:32] <ogra_> we were also discussing to drop all the bind mount bits from ubuntu-core and do everything in the initrd
[14:32] <ogra_> currently this is split in two ... i'd love to have the initrd give us an already properly set up rootfs instead (thats phone legacy we dont reall need anymore)
[14:33] <ogra_> and a third thing that we should talk about at the sprint is to perhaps split the core snap in two as well ...
[14:34] <ogra_> i know zyga is eager to actually only have the snap exec env in core ... we dont really need bits like systemd on classic ...
[14:34] <ogra_> so we might be able to have core and core-bootable ...
[14:35] <ogra_> oon classic you would onyl install core
[14:35] <ogra_> images would use core+core-bootable ... which would ship the bits to actually run it as rootfs
[14:36] <ogra_> (but thats sprint stuff that i'd like to discuss there)
[14:36] <niemeyer> Sounds good
[14:36] <niemeyer> I also recall seeing the idea flying that we might not need an initrd at all, but that's been a while ago and I have no context
[14:37] <ogra_> well, thet wouldnt work ... we need the rw bind mounts to appear somehow ... before init runs
[14:37] <ogra_> *that
[14:37] <ogra_> at least some of them
[14:42] <niemeyer> Yeah, I wouldn't worry at this point
[14:44] <ogra_> (no initrd would *massively* speed up our boot ... but i dont see a way to get along without one)
[14:48] <niemeyer> ogra_: There's nothing inside the initrd that cannot be on the image itself
[14:49] <ogra_> niemeyer, well, a) you need the modules to find your disk ... b) you need the bits that init expects
[14:49] <mup> Bug #1600260 opened: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260>
[14:49] <didrocks> niemeyer: I guess you are already aware of it, but the PR is failing in spread (can't access one of the test snap package), unsure it needs a rekick
[14:50] <mvo> didrocks: just rekick
[14:50] <mvo> didrocks: that got fixed ages ago (~7min or so)
[14:50] <didrocks> ahah :)
[14:50] <didrocks> sorry to not be on the edge!
[14:50] <mvo> didrocks: ;)
[14:50] <niemeyer> ogra_: There are straightforward solutions for those, I believe
[14:51] <didrocks> "This build can't be restarted
[14:51] <niemeyer> ogra_: But again, let's not worry for now
[14:51] <didrocks> mvo: mind doing it? ^
[14:51] <ogra_> i dont, but lets talk at the sprint
[14:51] <niemeyer> Yeah
[14:51] <didrocks> (I don't remember if "retest this please" rekicks travis CI as well)
[14:51] <niemeyer> ogra_: #1600260 filed
[14:51] <mup> Bug #1600260: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260>
[14:51] <ogra_> thx
[14:51] <niemeyer> didrocks: It doesn't
[14:52] <mvo> didrocks: sure, done
[14:52] <didrocks> yeah, that's what I thought, I don't have permissions to restart the build, that's weird, IIRC, travis CI don't show up the button in that case (but I got it)
[14:52] <niemeyer> ogra_: Thank you for looking into it
[14:52] <didrocks> anyway, thanks!
[14:52] <ogra_> np, should be an easy fix
[15:03] <dak__> hello. i have a question - i made a snap for angband and installed it, but when i run the command, it looks for /share/angband directory instead of $SNAP/share/angband, thus failing.  any additional step needed to make the snap point to the right location?
[15:09] <didrocks> dak__: hey! it really depends on the upstream build system, you can for some set --datadir= and point to something or having them relocatable
[15:09] <didrocks> the best is for the apps to see there is no /share and then, look to a relative path
[15:16] <jdstrand> niemeyer: fyi, finally responded to https://github.com/snapcore/snapd/pull/1405. going through other PRs now
[15:16] <mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
[15:16] <niemeyer> jdstrand: jd
[15:16] <niemeyer> jdstrand: Thanks!
[15:19] <mup> Bug #1600271 opened: snap install/remove multiple package names <Snappy:New> <https://launchpad.net/bugs/1600271>
[15:20] <joc_> jdstrand: thanks for response on zigbee-dongle, can i just check one point
[15:21] <joc_> jdstrand: if /dev/zigbee/ only contains symbolic links will the apparmor glob /dev/zigbee/* work
[15:22] <joc_> jdstrand: i was under the impression it wouldn't, and was the reason why some of the other interfaces I looked at dereference paths that include symbolic links (e.g. bool-file)
[15:25] <mup> PR snapd#1483 closed: many: migrate SnapSetup and SideInfo to use RealName <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1483>
[15:35] <jdstrand> joc_: no, it won't. apparmor resolves symlinks. as such, snappy will need to resolve those and add them like you said
[15:35] <jdstrand> joc_: for the no attributes case. for the with attributes case, that wouldn't be needed (since it is the device cgroup that does the enforcement)
[15:39] <joc_> jdstrand: thanks for confirmation
[15:40] <joc_> niemeyer: does that mean it's ok to land that PR as is? and work on jdstrand's suggestion for a version that uses attributes later
[15:40] <mhall119> is there a snap command to show info about a snap?
[15:40] <mhall119> something like "snap show foo"?
[15:40] <jdstrand> joc_: note, for 'as-is' it won't work til you resolve those symlinks
[15:41] <jdstrand> based on my understanding of what you said is in that dir anyway
[15:43] <joc_> jdstrand: the zigbeeDevPaths function evaluates the symlinks found in that dir and adds the resolved paths to the apparmor snippet
[15:45] <jdstrand> ah, cool
[15:46] <mup> PR snapd#1520 opened: tests: add locale-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1520>
[15:50] <mhall119> sergiusens: BTW, I'm still waiting on that snapcraft fix to be available for me to try in a cleanbuild, any update on that?
[15:50] <didrocks> mvo: interesting trick (about the reexec)
[15:50] <mhall119> "that snapcraft fix" being the pkg-config lookup changes for pantheon-mail
[16:01] <kyrofa> mhall119, not yet... ran into some CI issues that really delayed our release
[16:13] <joc_> mvo: so under the new update process, the "snap" exe would still be provided by the deb install but snapd would be updated with ubuntu-core snap?
[16:14] <cjwatson> dholbach: https://bugs.launchpad.net/bugs/1599786 - do you agree with the position in my follow-up comment at the end?
[16:14] <mup> Bug #1599786: Run snapcraft update before attempting a snap build <launchpad-buildd:In Progress by cjwatson> <https://launchpad.net/bugs/1599786>
[16:15] <dholbach> sergiusens, ^
[16:17] <kyrofa> dholbach, cjwatson agreed
[16:18] <cjwatson> right, will revert when I get a minute, thanks
[16:19] <mup> PR snapcraft#640 opened: Setup the FakeParts store for all unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/640>
[16:19] <kyrofa> cjwatson, worth pointing out that it's not quite released in snapcraft yet though
[16:19] <kyrofa> cjwatson, any chance you could delay the reversion for a few days? :P
[16:20] <cjwatson> kyrofa: well, I haven't rolled out the launchpad-buildd change either
[16:20] <cjwatson> kyrofa: and it would take a few days to do that ...
[16:20] <kyrofa> cjwatson, ah, scratch that then. We'll be SRUing very soon
[16:20] <kyrofa> cjwatson, go ahead and toast it
[16:20] <tsimonq2> hey kyrofa
[16:21] <cjwatson> right.  I mean, we can do virtual-builder-only rollouts just by getting IS to copy to a PPA, so it's not *that* hard, but I wouldn't want to do it late on a Friday
[16:21] <kyrofa> Indeed
[16:21] <kyrofa> Hey tsimonq2 :)
[16:23] <zyga> joc_: both snap and snapd would come from snaps
[16:23] <zyga> joc_: they both check and reexec the more up-to-date version
[16:23] <joc_> zyga: ok just checking, only snapd was mentioned :)
[16:27] <tsimonq2> kyrofa: I'm working hard on getting that coverage good to go :)
[16:27] <tsimonq2> kyrofa: I have everything but a checksum from a file and from a remote URL: https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L129
[16:27] <kyrofa> zyga, speaking of that, do you have any thoughts on bug #1599620?
[16:27] <mup> Bug #1599620: SNAP_REEXEC doesn't cover snap-exec <snapd (Ubuntu):New> <https://launchpad.net/bugs/1599620>
[16:28] <mup> PR snapcraft#641 opened: yield the correct exception when retries are out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/641>
[16:28] <kyrofa> tsimonq2, make sure you have an invalid checksum as well
[16:28] <tsimonq2> kyrofa: yep, covered
[16:28] <tsimonq2> kyrofa: I'm getting close ;)
[16:28] <kyrofa> tsimonq2, the format, I mean
[16:29] <kyrofa> tsimonq2, https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L154
[16:29] <kyrofa> tsimonq2, nice work!
[16:30] <tsimonq2> kyrofa: that's weird because I have https://github.com/snapcore/snapcraft/pull/619/files#diff-3ce6f0422479e72d9db0860efb0e7b42R238
[16:30] <mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
[16:31] <kyrofa> tsimonq2, that's not testing the format, that's just an incorrect checksum. Also a good test, but not the same
[16:31] <zyga> kyrofa: looking
[16:31] <kyrofa> tsimonq2, you need to have a checksum that doesn't match the _format_ of any others
[16:31] <mup> PR snapcraft#640 closed: Setup the FakeParts store for all unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/640>
[16:31] <tsimonq2> kyrofa: ohhh okay
[16:31] <ogra_> mvo, http://paste.ubuntu.com/18797420/ ... classic delta ;) ... (adds 5MB to the core snap)
[16:31] <tsimonq2> kyrofa: yeah I added that as sort of a "just in case" but I see
[16:31] <zyga> kyrofa: ah, I recall this issue now
[16:32] <zyga> kyrofa: so I think we should have a way to test snap-exec for sure
[16:32] <zyga> kyrofa: not sure if the environment variable is the way to go here
[16:32] <kyrofa> tsimonq2, if it's behavior you want to preserve (i.e. if it SHOULD work that way) you should cover it in a test so it can't regress
[16:32] <kyrofa> zyga, indeed. I had to use overlayfs just to test my dev version :P
[16:32] <zyga> kyrofa: I'd have to get more familiar with the current flow of events there
[16:33] <zyga> kyrofa: yeah, it's annoying, we had do to something similarly odd to test snap-confine
[16:33] <kyrofa> Yeah... really rough
[16:33] <zyga> kyrofa: I think that snap-exec is something we'd run from snap-confine, correct?
[16:33] <tsimonq2> kyrofa: it would be good for that not to regress... :)
[16:33] <zyga> kyrofa: if so, perhaps we could allow snap-confine to be built in test mode where this is divertable
[16:33] <zyga> kyrofa: otherwise I bet it would be a security risk
[16:34] <kyrofa> zyga, well, snap run invokes snap-confine requesting it to run snap-exec.... so not really
[16:34] <kyrofa> zyga, but kinda :P
[16:34] <zyga> kyrofa: the way I understand the flow is that we planned to skip the request so that snap-confine *always* ran snap-exec
[16:34] <kyrofa> zyga, that may be the final intention. mvo would need to clarify that. It's not the way it works currently
[16:34] <zyga> so that when you ask snap confine to do something it will never let you do that but run code under user's control
[16:35] <zyga> kyrofa: that's right
[16:35] <zyga> kyrofa: this was a phased upgrade process, we didn't implement it all the way
[16:35] <kyrofa> zyga, sounds about right
[16:35] <zyga> kyrofa: as long as there's an agreed plan and we all know it I'm sure we can figure out how to safely test snap-exec
[16:36] <kyrofa> zyga, very good. I guess I wanted to make sure someone knew about that bug so we could keep it in the back of our minds
[16:36] <zyga> kyrofa: I remember you mentioning this already; I was actually preparing for the switch more or less
[16:36] <zyga> kyrofa: with the change to snap-confine testing so that we can drop the old tests/ and use new unit tests and spread tests
[16:36] <kyrofa> zyga, indeed, I tried to mention it a few times but got no love :P
[16:36] <zyga> kyrofa: because I knew we won't be able to run arbitrary payload with arbitrary confinement soon
[16:37] <kyrofa> Nice
[16:45] <tsimonq2> hey kyrofa, can I please get a bit of help?
[16:45] <kyrofa> tsimonq2, sure, what's up?
[16:46] <tsimonq2> kyrofa: I'll push my code in like 30 secs, then I'll explain
[16:46] <tsimonq2> pushed
[16:46] <tsimonq2> okay, I'm expecting it to fail Travis BTW
[16:47] <tsimonq2> kyrofa: in my code I want to call the source_checksum function within the source_checksum_determine_type function
[16:47] <tsimonq2> kyrofa: the problem is, when I use self, it complains about not being in the TestTar and TestZip classes
[16:48] <tsimonq2> kyrofa: but I need a variable from source_checksum_determine type to pass to source_checksum
[16:48] <tsimonq2> kyrofa: (this is all in snapcraft/internal/sources.py )
[16:48] <tsimonq2> kyrofa: been working at this for an hour, trying different things, but it seems obvious
[16:52] <mup> PR snapcraft#641 closed: yield the correct exception when retries are out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/641>
[16:55] <mvo> ogra_: oh, nice
[16:55] <mvo> ogra_: is that available in edge now? thats cool
[16:58] <mvo> kyrofa: not sure I have all the context - snap run runs snap-confine and that runs snap-exec currently, in the future probably snap-confine will run snap-exec automatically but not yet because we need to transition to this first
[16:58] <kyrofa> mvo, very good, that's what we thought
[17:00] <mvo> kyrofa: cool
[17:00] <tsimonq2> kyrofa: so I don't know if you have any thoughts on my PR? :)
[17:01] <mvo> ogra_: really cool! and just 5mb because we skip on the man-pages I assuem (which is fine, just curious)
[17:02] <mvo> ogra_: is that in the latest  images? if so, I will be excited to bring back classic on monday :)
[17:03] <kyrofa> tsimonq2, sorry, on the phone... my move is suddenly going up in flames
[17:03] <tsimonq2> kyrofa: oh okay :)
[17:07] <ogra_> mvo, yeah, i still need to quieten the script a bit, but essentially it is done now
[17:08] <ogra_> mvo, it is in the latest cdimage snaps, we'll need to push them to the store eventually
[17:09] <ogra_> (there might also be more cleanup needed, i think the dpkg status file lists stuff we removed binaries from, but it is good enough for a start)
[17:11] <kyrofa> tsimonq2, okay, I'm back now. uhaul will be the death of me
[17:13] <mvo> ogra_: very nice, I will play with it monday and start with re-adding classic, this is huge, thank you!
[17:13] <ogra_> awesome ... :)
[17:13] <ogra_> and sorry it took so long (after all it was not really much code, but so much inspection work)
[17:15] <mvo> ogra_: no worries, if we can manage to make it work before the sprint (and I think we can) thats is good enough for me
[17:15] <ogra_> we definitely can
[17:16] <mvo> cool
[17:16] <mvo> ogra_: I call it a day, lets talk more later
[17:16]  * mvo waves
[17:17] <tsimonq2> kyrofa: heh, good luck with that :)
[17:17] <kyrofa> tsimonq2, my units pass...
[17:17] <kyrofa> tsimonq2, (for your branch)
[17:17] <kyrofa> tsimonq2, how do I reproduce the issue you're seeing?
[17:18] <tsimonq2> oh really?
[17:18] <tsimonq2> wait yeah
[17:18] <tsimonq2> weird, it should have failed lol
[17:18] <tsimonq2> but I guess it didn't
[17:18] <tsimonq2> which means it's my machine! \o/
[17:20] <tsimonq2> kyrofa: so, can you confirm my next steps?
[17:20] <tsimonq2>  - Remote URL checksum
[17:20] <tsimonq2>  - Invalid checksum
[17:21] <tsimonq2> kyrofa: that's it maybe?
[17:21] <tsimonq2> wait this is weird... https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L134
[17:22] <tsimonq2> so it never does the file thing?
[17:22] <mup> PR snapcraft#642 opened: Make maven plugin honour https_proxy and proxy authentication <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/642>
[17:22]  * tsimonq2 facepalms
[17:22] <tsimonq2> I NEVER COMMITED!
[17:23] <tsimonq2> kyrofa: *now* everything should break and it should be as described
[17:23] <niemeyer> joc_: It should at least do what I suggested in terms of using apparmor rather than globbing the FS at connection time
[17:24] <niemeyer> joc_: But it doesn't look like implementing what jdstrand suggested would be hard either
[17:24] <kyrofa> tsimonq2, heh
[17:24] <niemeyer> Why not just doing it quickly rather than postponing and risking having it like that for a long time?
[17:24] <tsimonq2> kyrofa: but does my checklist look good then?
[17:25] <kyrofa> tsimonq2, for units yeah that sounds about right
[17:25] <tsimonq2> kyrofa: anything else I might have to do?
[17:26] <kyrofa> tsimonq2, I've not reviewed it completely, so not that I know of but that doesn't mean "no" ;)
[17:27] <tsimonq2> kyrofa: alright :)
[17:34] <mcphail> When can we expect updating snaps to use binary deltas instead of downloading full packages? Is it on the horizon?
[17:35] <kyrofa> tsimonq2, do you know the difference between instance and class methods?
[17:36] <tsimonq2> kyrofa: vaguely, please refresh
[17:37] <kyrofa> tsimonq2, an instance method operates upon a specific method, mutates it in some way or at least utilizes information specific to that instance
[17:37] <kyrofa> tsimonq2, whereas class methods are not specific to instances-- they're available on the class itself without requiring an instantiation
[17:37] <tsimonq2> kyrofa: oh okay
[17:38] <kyrofa> tsimonq2, note that the functions you've written for checking the format etc. are not specific to the class upon which it's implemented at all
[17:38] <kyrofa> tsimonq2, does that make sense?
[17:39] <tsimonq2> kyrofa: I see, so do I need to call the specific class along with the function?
[17:39] <kyrofa> tsimonq2, with what you've written, a fix for test_non_matching_checksum is this: http://pastebin.ubuntu.com/18803040/
[17:40] <kyrofa> tsimonq2, however, notice how I have to instantiate a zip class just to check the checksum
[17:40] <kyrofa> tsimonq2, well, that's not specific to zip. It's not specific to any source
[17:40] <kyrofa> tsimonq2, so I suggest a small refactor-- pull those functions out of any class and implement them standalone
[17:41] <tsimonq2> kyrofa: what functions, in the tests or in the code for it?
[17:41] <kyrofa> tsimonq2, the code for them
[17:41] <kyrofa> tsimonq2, they shouldn't be in FileBase
[17:42] <tsimonq2> kyrofa: so I need to pull out of FileBase and not put it in any other class, you're saying?
[17:42] <kyrofa> tsimonq2, exactly
[17:43] <kyrofa> tsimonq2, then you can test them directly without needing to instantiate any classes
[17:43] <tsimonq2> kyrofa: cool, thanks, I can work with that :)
[17:43] <mup> PR snapcraft#643 opened: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643>
[17:45] <kyrofa> tsimonq2, typically when designing an API like this, you go through a decision-making process. You have four-ish options: do you make this function a public instance method, a private instance method, a class method, or standalone?
[17:46] <kyrofa> tsimonq2, you have to ask yourself a number of questions when determining the answer to that question
[17:47] <tsimonq2> kyrofa: welp, snapcraft#643 seems to say that my PR's not getting in
[17:47] <mup> PR snapcraft#643: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643>
[17:47] <kyrofa> tsimonq2, first you decide instance/non-instance. You ask "Is my function really specific to this class? Does it require access to its member variables?"
[17:47] <kyrofa> tsimonq2, not into this release anyway. You can hit the next one :)
[17:47] <tsimonq2> kyrofa: oh okay :)
[17:47] <tsimonq2> kyrofa: I'm reading what you're saying ;)
[17:48] <kyrofa> tsimonq2, if the answer is no, then you have to decide class method versus standalone. You'd ask "is this method still do something specific to this class? To subclasses need to be able to override it?"
[17:49] <kyrofa> tsimonq2, if the answer is no, then you prefer standalone functions. They're easy to test and easy to reuse
[17:49] <tsimonq2> kyrofa: I see, makes sense
[17:49] <kyrofa> tsimonq2, so typically, prefer standalone functions if it makes sense to implement things that way. It leads to a more modular and testable design
[17:50] <kyrofa> tsimonq2, applying that logic to your checksum functions, let's ask: "are they really specific to that given source? Does it require access to member variables?"
[17:50] <tsimonq2> kyrofa: I see, and with something like this, it's probably good to be a standalone :)
[17:50] <tsimonq2> yeah
[17:50] <tsimonq2> they aren't source-specific
[17:51] <kyrofa> tsimonq2, right. They don't meet the test for class methods either
[17:51] <tsimonq2> yeah
[17:52] <kyrofa> Anyway, that's my software spew for today :)
[17:53] <kyrofa> tsimonq2, one more thing: if you have a class instance and you want to call a method on it, even a method inherited from a parent class, just call self.method(), not MyParentClass.method(self)
[17:53] <tsimonq2> kyrofa: it's useful, I learned something new :)
[17:53] <tsimonq2> kyrofa: oh okay
[18:01] <tsimonq2> hey kyrofa
[18:01] <tsimonq2> kyrofa: one more thing
[18:02] <tsimonq2> wait hm
[18:03] <kyrofa> tsimonq2, hmm?
[18:04] <tsimonq2> kyrofa: yeah, so I have the teo classes, right? I still can't call one from another and I still can't get the variable from one to another
[18:05] <kyrofa> tsimonq2, I'm missing context here. Two classes-- zip and tar? One variable are you trying to get from one to the other?
[18:05] <kyrofa> s/One/What/
[18:05] <tsimonq2> kyrofa: check_checksum_determine_format and check_checksum
[18:06] <kyrofa> tsimonq2, those are what you're making standalone now, right?
[18:06] <tsimonq2> kyrofa: I need source_checksum and checkfile to hop from one to the other
[18:06] <tsimonq2> kyrofa: yes, pushed
[18:07] <kyrofa> tsimonq2, standalone functions have no "self," that's for instance methods
[18:08] <tsimonq2> kyrofa: so how do I call it then
[18:08] <tsimonq2> s/then/then?/
[18:08] <kyrofa> tsimonq2, just... directly. Like `check_checksum()`
[18:08] <kyrofa> No self at all
[18:08] <tsimonq2> oh!
[18:08] <tsimonq2> ok
[18:08] <tsimonq2> let me see
[18:10] <tsimonq2> kyrofa: well I think that fixed it, I don't know, because I have the following: def check_checksum_determine_format(self, source_checksum, checkfile): and I only pass source_checksum and checkfile, do I really need to pass self as well? what could that do?
[18:10] <tsimonq2> (I only pass those two variables in my tests)
[18:10] <kyrofa> tsimonq2, no, no self
[18:10] <kyrofa> tsimonq2, remove that as a param
[18:10] <kyrofa> tsimonq2, again, just for instance methods
[18:10] <kyrofa> tsimonq2, which these are no longer
[18:11] <tsimonq2> oh that's right! sorry, that was obvious :P
[18:55] <mup> PR snapd#1518 closed: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1518>
[18:59] <mhall119> is there a list of available interfaces for a snap to use?
[19:06] <niemeyer> mhall119: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
[19:42] <mup> PR snapd#1476 closed: overlord: make SyncBoot work again <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1476>
[19:48] <mhall119> thanks niemeyer
[19:54] <mhall119> is is necessary to include the gsettings plug in order for an app to access just it's own settings?
[20:18] <mup> PR snapd#1521 opened: many: removed authenticator, store gets a user instead <Created by matiasb> <https://github.com/snapcore/snapd/pull/1521>
[20:22] <tsimonq2> mhall119: or you could just do snap interfaces
[20:35] <mhall119> tsimonq2: I did, but I wasn't sure if that showed all of the ones in snapd, or just the ones with a slot or plug installed
[20:36] <tsimonq2> mhall119: mine has ones with no snaps in them
[20:39] <mhall119> thanks tsimonq2
[20:40] <tsimonq2> no problem mhall119 :)
[21:04] <mup> Bug #1592714 changed: snapd-interface application problem with systry icon <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592714>
[21:12] <cyphermox> where can I get the files I need to do porting; for instance the gadget and os snaps?
[21:15] <kyrofa> mhall119, I believe `snap interfaces` will show all interfaces that have slots on the system
[21:15] <kyrofa> mhall119, e.g. snapd may support more interfaces than are available on the given system
[21:15] <tsimonq2> kyrofa: that's what I said :)
[21:16] <tsimonq2> kyrofa: hello btw :)
[21:16] <kyrofa> tsimonq2, well, you said you see ones with no _plugs_ in them, no?
[21:16] <tsimonq2> kyrofa: yes
[21:16] <tsimonq2> $ snap interfaces | pastebinit
[21:16] <tsimonq2> http://paste.ubuntu.com/18823922/
[21:16] <kyrofa> tsimonq2, I'm saying `snap interfaces` will not show all interfaces
[21:17] <kyrofa> tsimonq2, just the ones with slots
[21:17] <tsimonq2> kyrofa: no it won't, see my pastebin
[21:17] <tsimonq2> :cups-control        -
[21:17] <tsimonq2> :firewall-control    -
[21:17] <tsimonq2> :gsettings           -
[21:17] <tsimonq2> (for example)
[21:17] <kyrofa> tsimonq2, those are slots
[21:18] <kyrofa> tsimonq2, with no corresponding plug
[21:18] <kyrofa> tsimonq2, I'm saying there's no way to see interfaces with no slots available
[21:18] <tsimonq2> kyrofa: oh
[21:19] <kyrofa> tsimonq2, i.e. snapd can support X interface, but if the system has no snaps installed providing the X slot, `snap interfaces` won't show it
[21:19] <tsimonq2> kyrofa: oh ok
[21:44] <tsimonq2> kyrofa: huh, for some reason only sha512 checksums work...while I hack on it, is there anything obvious you can point out?
[21:46] <tsimonq2> oh I'm stupid
[21:46] <tsimonq2> kyrofa: sorry for all the pings
[21:50] <mcphail> Is there a way to install snapd on a first-generation raspberry pi running raspian?
[23:52] <tsimonq2> kyrofa: I think my PR's ready, I'm pretty proud of my first comment :D https://github.com/snapcore/snapcraft/pull/619
[23:52] <mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>


[14:15] <ogra> woah, booting mid with the usb key attached to a 1.1 hub on the jax is really painful
[14:18] <ogra> hmm, to sad the partitioner doesnt fit the screen
[14:18] <ogra> the timezone map actually looks awesome
[14:22] <playya> ogra, should i restart the hildonized ubiquity?
[14:23] <lool> ogra: Yeah I love the TZ choser
[14:24] <ogra> its really only the partitioner thats not 100% perfect
[14:25]  * ogra is falling over that evtouch *just works* on UNR
[14:25] <ogra> thats how package management works :) break a package, dont look at it for the whole release and notice that everything is fine in final testing
[14:27] <persia> playya, It's really not worth it: better would be to work just on the partitioner component to try to make it fit in the resolution available.
[14:27] <persia> That also provides future-proofing to support non-hildon technologies for similar resolutions.
[14:27] <ogra> wow UNR is really sweet on the Q1
[14:29] <amitk> if we could only get the touchscreen working
[14:31] <ogra> amitk, it works here on the current UNR image
[14:32] <ogra> out of the box
[14:49]  * ogra_jax waves from a successfull MID install
[14:51] <lool> amitk: grep -rli HZ /etc/sysctl.* yields nothing
[14:51] <lool> amitk: Anything else I should collect before shutting down?  :-)
[14:52] <amitk> lool: upload the /etc/sysctl.conf to the bug
[14:57] <lool> amitk: I see buffer I/O errors no sr0
[14:58] <lool> That's probably the issue
[19:29] <plars> Anyone here have a netbook that you know not to work at all, or with really major problems under UNR?
[20:18] <cgregan> plars: dell mini12 should have some video issues
[20:19] <plars> cgregan: really? mine doesn't... do you have any details about it?
[20:19] <cgregan> plars: unless we have the vid driver in our restricted
[20:20] <plars> cgregan: oh wait, you're talking mini 12... didn't see that until now, I have a 9
[20:21] <plars> cgregan: is there a bug open on it?
[20:21] <plars> cgregan: just looking for more things to add to that page I showed you
[20:22] <cgregan> plars: no bug that I am aware of for distro....the shipping image has the proprietary driver
[20:39] <persia> cgregan, Is that poulsbo related?
[20:39] <persia> Or is there another video chip with issues?
[20:39] <cgregan> persia: yes..poulsbo
[21:28] <mkrufky> i think there's a memory leak in that poulsbo driver
[21:29] <mkrufky> try streaming video for more than just a few days, and then calling the system "sluggish" is an extreme understatement


[20:36] <Stengade> I cant not be both. Online and Offline. So maby i will write back or i will not write back. Give me 5 second
[20:39] <Stengade> I cant not be both. Online and Offline. So maby i will write back or i will not write back. Give me 5 second
[20:40] <Stengade> I cant not be both. Online and Offline. So maby i will write back or i will not write back. Give me 5 second


[09:54] <CamelRiderZ> hey
[09:56] <CamelRiderZ> i am trying to set up ikev2 via this guide https://nordvpn.com/tutorials/linux/ikev2ipsec/
[10:00] <tomreyn> maybe try wireguard instead, it should be easier: https://nordvpn.com/blog/nordlynx-protocol-wireguard/
[10:05] <CamelRiderZ> i just have one issue with ikev2
[10:05] <CamelRiderZ> when i open sudo nano /etc/ipsec.conf the second time
[10:06] <CamelRiderZ>  i am supposed to see conn NordVPN
[10:06] <CamelRiderZ>   keyexchange=ikev2
[10:06] <CamelRiderZ>   dpdaction=clear
[10:06] <CamelRiderZ>   dpddelay=300s
[10:06] <CamelRiderZ>   eap_identity="USERNAME"
[10:06] <guiverc> !pastebinit
[10:07] <CamelRiderZ> i don't see this config when i open the ipsec
[10:18] <CamelRiderZ> tomeryn when i use the nordvpn app via terminal i always get issues
[10:23] <tomreyn> CamelRiderZ: i suggest you seek support with this software with the organization providing it to you.
[10:27] <CamelRiderZ> it is just a step i am stuck at
[10:27] <CamelRiderZ> thought someone here might be using nord or ike2v
[14:54] <sweb> on rasperypi installation after apt update ... apt install lubuntu-desktop ... // unable to locate package
[14:54] <sweb> ubuntu 18.04.4
[14:55] <wxl> probably an internet issue. it's there https://packages.ubuntu.com/search?keywords=lubuntu-desktop
[14:55] <sweb> i use arm64
[14:56] <sweb> seems be only availble for armhf
[14:56] <wxl> huh i'll have to investigate that later.
[15:00] <wxl> nope
[15:00] <wxl> i mean they could. they should? :)
[15:01] <wxl> t's a debian tool soooooooooo
[15:01] <wxl> here it is mentioned in the manual https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html
[15:02] <wxl> i should point out that if you look at the control history in debian, you'll see the formatting was always the way it is in debian
[15:02] <wxl> that was introduced in 0.14.0
[15:03] <wxl> however, we went straight from 0.13.0-0ubuntu2 to 0.14.0-0ubuntu1 as a new upstream release
[15:03] <wxl> oops jeez wrong channel
[15:03] <wxl> wow
[15:03]  * wxl drinks more caffeine
[17:27] <katsumi_> hi
 hi
[17:31] <katsumi_> i'm running lubuntu eoan ermine 19.10 and i'm missing netselect-apt. :(
[17:32] <wxl> so is the entire ubuntu archive aparently https://packages.ubuntu.com/search?keywords=netselect-apt
 it says  no result
[17:34] <wxl> looks like it's been gone a long time https://bugs.launchpad.net/ubuntu/+source/netselect/+bug/337377
[17:37] <katsumi_> :(
 https://bugs.launchpad.net/ubuntu/+source/plasma-discover/+bug/1858011
 is this mean bug fixed?
[17:41] <wxl> no
[17:42] <wxl> that may not actually be "the error"
[17:42] <wxl> that whole thing is a real sticky thing i haven't been able to figure out yet
[17:43] <wxl> if you want to be super useful, you can test it out and try the `appstreamcli refresh` thing and see if it works
[17:43] <wxl> from what i remember it does not
 hmm, okay
[17:45] <wxl> could you try and report on that bug (https://bugs.kde.org/show_bug.cgi?id=406654) ?
 @wxl [<wxl> could you try and report on that bug (https://bugs.kde.org/show_bug.cgi?id …], im sorry to say but i dont have lubuntu at my system, i still like it, i did recommend it at yt video too
 (Photo, 1280x719) https://i.imgur.com/Z2y7wxi.jpg
[17:50] <wxl> this is why bugs don't get fixed :(
 well, it s easy to check it, i just need time to download updates after installing lubuntu vm
 btw did u notice i recommended lubuntu for both ssd and hdd and also for all ram capacities? :)
[17:53] <wxl> nice
 there s only lubuntu like that, not anyother
[21:13] <kenan> iyi akşamlar
[21:13] <kenan> hi everyone
 iyi akşamlar
 ingilizce de cevap verebilirim
 biliyorsan ingilizce konuşalım
[21:21] <tomreyn> !tr
 :D
 hmm
 #ubuntu-tr
[21:23] <tomreyn> not on your client, just on irc
 ahh
[22:17] <westwrlod> hello, I was wondering what the best way to rebind caps lock to control with lubuntu
[22:17] <westwrlod> so far I have found setxkbmap -option ctrl:nocaps works, but websites recommend putting it in an autostart file under ~/.config that I cannot find
[22:18] <westwrlod> also, I was wondering how to make the desktop open applications desktop specific (so I don't see the ones I opened on desktop 1 on desktop 3 for example)


[07:02] <MooDoo> morning all
[08:02] <sudodus> help with cloak: Hi, I'm an Ubuntu member and a moderator of the Ubuntu Forums. We intend to use #ubuntuforums-mods, and I need a cloak to be able to access it without an invitation each time. I'm a beginner so bear with me until I'm getting used to this way of communication. My Launchpad account is https://launchpad.net/~nio-wiklund, sudodus (nio-wiklund), If you know how to do it, please help me :-)
[09:47] <Fuchs> sudodus: well, now you are identified, that's a start. The rest is as I said: you need to wait in here (patience is the key) for a member of the IRCC
[09:47]  * Fuchs eyes AlanBell
[09:47] <Fuchs> sudodus: as soon as you found one, they need to get in touch with staff, then staff will ask you whether you want that cloak, if you confirm you'll have it.
[09:48]  * AlanBell can't help, sorry, I am not on the IRCC, but everything looks good for the cloak
[09:49] <Fuchs> Oh, sorry, thought you still were
[09:49] <Fuchs> who is, currently?
[09:49] <AlanBell> !ircc
[09:49] <AlanBell> erm, that didn't help
[09:49] <Fuchs> yeah, I'll check lolpad
[09:49] <AlanBell> these fine folk https://launchpad.net/~ubuntu-irc-council/+members
[09:49] <Fuchs> lovely, most of the realnames are new to me :p
[09:49] <Fuchs> yeah, found it
[09:50] <Fuchs> ah, there are the nicks, hggdh or Tm_T    would work :)
[09:51] <Tm_T> Fuchs: ack
[09:51] <Fuchs> Yay
[09:52] <Fuchs> Tm_T: could you request a mümber cloak for sudodus?  Thanks ♥
[09:52] <Tm_T> Fuchs: I request
[09:52]  * Tm_T is semibusy with semi-important stuff so he keeps comments at minimum, sorry
[09:53] <Fuchs> Sorry for disturbing and thanks ♥
[10:05] <sudodus> Fuchs; OK, I'll stay connected and waiting ... will be away from the keyboard for periods of time, but coming back. Thanks for helping :-)
[10:06] <Fuchs> u r wlcme


[20:44] <jj_> Has anyone successfully enabled lock screen functionality when using Fractional Scaling? I set mine to 125% so that my display is decent, but it disabled my ability to lock my screen unless I run "gsettings set org.gnome.desktop.lockdown disable-lock-screen false". The first time I ran that, it seemed to have lost the setting the next time I went to lock my screen. And when I got it to work the first time, it messed with the
[20:44] <jj_> placemenet of all of my windows and was just weird.
[20:50] <fossfreedom_> The lockscreen is deliberately disabled from being  enabled ... that's the message you see under the fractional scaling option in budgie control center - displays
[20:51] <fossfreedom_> And you should logout and login after enabling fractional scaling
[20:51] <jj_> Yeah, I saw. I guess I was looking for some kind of workaround. Not sure what else to do to secure my laptop when having to walk away from it
[20:52] <fossfreedom_> No workaround. The lockscreen needs reworking to support fractional scaling
[21:09] <jj_> Good info, thanks! I wish I was good enough to take that on. Hopefully someone does
[21:11] <fossfreedom_> It will be resolved when budgie moves to wayland. That will be hopefully in 24.10 timescales
[21:26] <jj_> Great!


[00:31] <ProfMac_> I'm having trouble getting access to a USB stick inside a virtual box.  Haven't run it yet.
[00:36] <CarlFK> oh hey.. do you have a 2nd box you can apt install qemu on, and then ssh to?
[00:36] <CarlFK> fb=false and -display curses ... should let you run it over ssh
[02:38] <ProfMac_> I have 1 physical box, and run VirtualBoxes on it.
[08:23] <prologon> I used Startup Disk Creator (usb-creator-gtk). Is there a better solution?
[10:01] <xnox> prologon, you can use dd
[10:01] <xnox> our images are enabled to be simply dd'ed onto usb sticks


[08:59] <JamesTait> Good morning all; happy International Lefthanders Day! :-D
[10:07] <davmor2> JamesTait: Yay it's my day
[10:07] <JamesTait> davmor2, I never knew you were keggy-handed.


[03:23] <Bashing-om> wildmanne39: Got an alarm set ?
[03:55] <Bashing-om> wildmanne39: Ears burning ?
[04:21] <Bashing-om> guiverc2: Heads up - I will be away the 23rd weekend, wildman says he can get 580 pushed out.
[04:22] <guiverc2> :)  i noted some of the discussion on forums
[04:25] <Bashing-om> guiverc2: Come this Monday I will warn again :P
[04:25] <guiverc2> :)   & extremely wise.
[12:16] -SwissBot:#ubuntu-news- ::Softpedia:: IPFire Linux-Based Hardened Firewall Gets New Intrusion Prevention System @ https://news.softpedia.com/news/ipfire-linux-based-hardened-firewall-gets-new-intrusion-prevention-system-526045.shtml (by Marius Nestor)
[14:30] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Podcast from the UK LoCo: S12E06 – International Karate+ @ http://ubuntupodcast.org/2019/05/16/s12e06-international-karate/
[16:21] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: How to Install Notepad++ in Ubuntu (One-Click Install) @ https://www.omgubuntu.co.uk/?p=142574 (by Joey Sneddon)
[16:37] -SwissBot:#ubuntu-news- ::Softpedia:: KDE Plasma 5.16 Desktop Environment Enters Beta with Many Enhancements @ https://news.softpedia.com/news/kde-plasma-5-16-desktop-environment-enters-beta-with-many-new-features-526064.shtml (by Marius Nestor)
[20:16] -SwissBot:#ubuntu-news- ::Planet:: Bryan Quigley: 2020 Presidential Tracker now live @ https://bryanquigley.com/posts/politics/2020-presidential-tracker-now-live.html


[07:09] <diplo> Morning all
[09:54] <brobostigon> morning boys and girls.
[10:37] <diplo> diddledan: have you created a snap that needs a web server yet ?
[11:07] <tomred> "Can't locate object method "countries_for_form" via package
[11:07] <tomred> Sorry wrong channel
[11:09] <Seeker`> have you tried down the back of the sofa?
[11:17] <zmoylan-pi> i'm surprised more databases don't fall back to searching there
[11:23] <zmoylan-pi> now i want you to sit down and breath deeply before clicking the link... http://www.telegraph.co.uk/technology/2017/09/29/commodore-64-coming-back-c64-mini-released-next-year/
[13:51] <diddledan> erhmagherd
[13:51] <diddledan> c64?!
[13:52] <ali1234> meh
[13:52] <ali1234> someone made a FPGA board in pi zero form factor that can emulate an amiga in hardware
[13:53] <ali1234> https://hackaday.io/project/13048-flea-ohm-fpga-project
[13:54] <ali1234> https://www.indiegogo.com/projects/fleafpga-ohm-fpga-experimenter-board-arduino#/
[14:10] <diddledan> I wonder how "turned-off" the military bits are.. as in could they be turned back on by a hacker? https://hackaday.com/2017/09/28/military-satellite-goes-civilian/
[14:12] <zmoylan-pi> might have been so secret we can initiate self destruct in case we ever saw a russian shuttle pull up along side in case type destroy important parts thing
[14:16] <diddledan> criminals totally need to look into ham radio
[14:17] <diddledan> what better way to middle-finger the establishment than to use unlicensed bands to communicate out of the prying eye of internet censorship/spying
[14:18] <zmoylan-pi> everyone monitors those frequencies
[14:18] <zmoylan-pi> plus very very low bandwidth
[14:20] <diddledan> do you need much bandwidth for a go order on robbing the granny on the corner of the street?
[14:22] <diddledan> that must be due to doppler - they list the frequency of the downlink on that sattelite as start-of-pass at 435.115MHz drifting to end-of-pass at 435.095MHz
[14:22] <diddledan> the uplink must have compensation inbuilt because it is static
[16:55] <diddledan> the internet isn't going to break https://www.theregister.co.uk/2017/09/28/internet_update_on_hold/
[17:26] <diddledan> sweet ooga mooga
[17:26] <diddledan> I've cleared my overdraft!!
[18:16] <diddledan> uk school lost their balloon and you'll never guess where it ended up! https://twitter.com/Raspberry_Pi/status/913763213195579392

[18:39] <Guest14552> #sdf3dfgd454
[18:51] <diddledan> omg, I was thinking exactly the same thing
[20:20] <daftykins> diddledan: \o
[20:20] <diddledan> o/
[20:20] <daftykins> well, good thing i read that Draytek's firmware update manual, it had one image which nukes your config and one that doesn't XD
[20:20] <diddledan> run them both :-p
[20:20] <daftykins> i also firmware updated an Oki MFP o0
[20:21] <daftykins> i think i might just enjoy progress bars or something
[21:31] <diddledan> puerto rico is an island. surrounded by water. https://twitter.com/nowthisnews/status/913837786280558592
[21:34] <daftykins> hrmm
[21:40] <aptanet> Anyone here running the 17.10 beta?
[21:43] <daftykins> what if they were?
[21:43] <daftykins> (usually best to just ask the question :) )
[21:44] <aptanet> good point, I'm clearly getting rusty with my irc etiquette!
[21:45] <aptanet> I've just upgraded a box to play with and logged into the standard Ubuntu version of Gnome desktop and there are no indicators.
[21:45] <aptanet> I'm sure they should be there, but I don't even have the Gnome legacy thing at the bottom left.
[21:46] <aptanet> Just wondering how they were setup so I could fix it - rather than just sorting it out myself and ending up with a completely non-standard solution.
[22:46] <daftykins> oops i forgot i read your query, i have no idea about desktop matters but i would probably take the simple approach of nuking my ~ gnome config to resolve any such surprises
[22:49] <aptanet> Good point, I did try Gnome on 17.04; although I did surgically remove all packages and purge the configurations it may well have left stuff in my home directory.
[22:50] <aptanet> Just need to work out what to nuke now.
[22:51] <daftykins> mmm i'd only be googling, but maybe .config/<something in here>
[22:53] <aptanet> found some . directories that may be related, nothing recent in them so I'll move them out the way (never delete, just in case - I've seen that mistake far too often) and see what happens.
[22:54] <daftykins> *nod*
[23:10] <aptanet> Well those made no difference. Nothing else looks likely so far.
[23:10] <aptanet> Time to sleep on it.
[23:11] <aptanet> Added quirks with Dash to Dock having ghost icons and the shutdown/sleep buttons not doing anything.
[23:11] <aptanet> Also managed to get Dash to Dock appearing in the lock screen somehow!
[23:11] <daftykins> ooh-err
[23:11] <daftykins> can you create another user to test?
[23:12] <daftykins> i'd start wondering about graphics hardware + driver in use in a way, assuming that's gnome3 - but i'm really rusty on desktop issues (used to give support but i stick to servers day to day)


[01:15] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 401 for the week January 19 - 25, 2015 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue401
[01:24] <pleia2> jose: think you can handle next weekend? I'll be at fosdem, trying to take it easy on trips because I always try to do too much :)
[01:59] <jose> pleia2: sure thing!
[21:59] <pleia2> aw, I didn't see this earlier https://twitter.com/silbs/status/557472188539105280
[21:59] <pleia2> yay us :)
[22:09] <imnichol> Woooo.  Swooped in to get some of the credit :D
[22:16] <imnichol> That was the first issue that I helped with
[22:26] <PaulW2U> I got http://bit.ly/1CKGg7n after my first week. Nice.
[23:28]  * wxl is sad his recent blogs didn't get in the news (despite being syndicated to planet)
[23:30] <pleia2> wxl: such as?
[23:30] <pleia2> and anyone can add to the google doc :)
[23:30] <wxl> yeah i've been busy
[23:30] <wxl> i just figured they would automagically get picked up on
[23:31] <wxl> this one http://polka.bike/blog/input-woes and this one http://polka.bike/blog/down-with-markup
[23:31] <wxl> and maybe this one http://polka.bike/blog/reddit-sprite-css-magic/
[23:31] <pleia2> hm, they don't look like Ubuntu news
[23:32] <pleia2> we only include a small subset of planet posts that are Ubuntu news-y
[23:32] <wxl> well they all relate to ubuntu in some way or another
[23:32] <wxl> i see
[23:33] <pleia2> we can't include all planet posts (people who want them all just subscribe to planet directly), we go through them and select ones that are news and we believe are of interest to newsletter readers
[23:33] <wxl> i've had some other ones that weren't news about ubuntu pop in there
[23:34] <wxl> oh well, it's fine
[23:34] <pleia2> but please, add it and let us know if you feel it should be included, we're not perfect either ;)
[23:34] <wxl> okie dokie
[23:34] <wxl> the one on input basically explained in an easy, readable way, how input works in linux through both the kernel and the gui
[23:35] <wxl> i spent a long time trying to figure out this mystery and thought someone would appreciate it
[23:35] <pleia2> yeah, we don't typically include how-tos unless they're related to new tech (like IoT tech)
[23:35] <wxl> the markup one is basically an explanation for why i hate moinmoin
[23:35] <pleia2> how-tos would expand the scope of the newsletter a lot
[23:35] <wxl> and why it's not really appropriate for ubuntu
[23:36] <wxl> neither are howtos
[23:36] <wxl> the reddit one is.
[23:36] <pleia2> ok
[23:36] <wxl> again, i'm not mad. i understand better why now :)
[23:37] <pleia2> it's still not very clear to me that you are trying to argue for Ubuntu to get rid of the wiki :\ but reading it that way now I can interpret it that way
[23:37] <pleia2> I thought it was a more general musing about markup things
[23:38] <wxl> well, it's more of an argument about getting rid of moinmoin's ridiculous markup


[06:23] <cpaelzer> doko_: hi, an update on one of the tasks by security reminded my of https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1889248 - I wanted to ping to check if this is still on your todo list?
[07:13] <cpaelzer> Laney: do you happen to now which tool/automation submits the retests that you can e.g. see in https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/s390x
[07:13] <cpaelzer> the long lists of pacakges that is  combines as trigger seems too long
[07:14] <cpaelzer> many of those tried already migrated
[07:14] <cpaelzer> not that the test would not be broken - it is - but how does it get to this particular list of triggers?
[07:15] <rbalint> Laney, cpaelzer i'm wondering about that, too, somehow the previous upload of glibc had a similarly long list of triggers
[07:19] <cpaelzer> in 1895576 (the systemd s390x fail that remains) I tried to chck this a bit
[07:19] <cpaelzer> some packages magically (so it seems to me) migrated
[07:19] <cpaelzer> and while they are shown as in -release, some tooling considers it not yet - and hence keeps them in this list
[07:19] <cpaelzer> well - all assumptions so far
[07:20] <cpaelzer> rbalint: btw the test on s390x really seems still broken
[07:20] <cpaelzer> we need either a fix or a test hint
[07:24] <rbalint> cpaelzer, i'm ok with the hint and i've retriggered the tests with cryptsetup and glibc to see if they still help
[07:25] <cpaelzer> ok rbalint, given you are the maintainer and you agree I think I'll prep a hint and once you ack there (for an audit trail) we can push it
[07:27] <rbalint> cpaelzer, thanks, i'm also working on the next systemd point release but it shows regressions so it will take a few days
[07:32] <cpaelzer> rbalint: here for you to +1 and merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-systemd-s390x-fails/+merge/390809
[07:55] <rbalint> cpaelzer, +1'd
[08:07] <Laney> cpaelzer: rbalint: Probably from proposed-migration itself. The code to do that is in the autopkgtest policy there, if you want to read it and see exactly what it does. But unless you know of an actual problem... ;)
[08:15] <rbalint> Laney, what i'm observing is that the glibc upload generated a long list of triggers, while i coud just use glibc/2.32-0ubuntu2, like in https://autopkgtest.ubuntu.com/packages/a/assimp/groovy/arm64
[08:24] <Laney> It's trying to work out what needs to be grouped together
[08:24] <Laney> what's the real problem here?
[08:27] <xnox> i have a few armhf tests that are /uknown and claim to have broken pipes and what not.
[08:27] <xnox> are armhf workers up? and is it safe for me to retry armhf failures that affect my uploads?
[08:28] <Laney> I'm retrying those weird ones daily
[08:28] <rbalint> Laney, the triggers may pull in more packages than needed, for example in last run of https://autopkgtest.ubuntu.com/packages/g/gst-omx/groovy/amd64 libglib is pulled from proposed while i believe glibc could migrate without it
[08:28] <Laney> bos02's network
[08:31] <rbalint> Laney, also it lists systemd/246.4-1ubuntu1 among the triggers while it is already in the release pocket for some time
[08:32] <rbalint> Laney, not terrible, but this seems new and makes it harded a bit to read the results
[08:34] <Laney> It is new(ish), but new isn't always bad. Previously we had many more packages which fell back to using all-proposed. It's right for proposed-migration to try to work out the groups and trigger those together.
[08:34] <Laney> If there's actual bugs, feel free to file those of course.
[08:36] <Laney> (upstream ideally :p)
[08:44] <xnox> rbalint:  having trigger on something in release is a no-op, no? so more or less, mostly harmless?
[08:46] <Laney> Yeah, but "too much" from -proposed could be a problem
[08:48] <Laney> I've retried all those "unknown" tests, and taken the dead nodes out of the rotation
[08:49] <Laney> Oh Boston, you used to be so reliable
[09:07] <cpaelzer> xnox: I have seen the "armhf broken pipe tests as well
[09:08] <cpaelzer> thanks for bringin it up here
[09:08] <cpaelzer> xnox: on which release did you see those?
[09:09] <cpaelzer> well - reading the backlog it seems it might be unrelated to the actual target release
[09:09] <cpaelzer> Thanks Laney, I'll probably just recheck results somewhen later today then
[09:13]  * Laney weeps
[09:13] <Laney> lxc just somehow broke on the worker machine
[09:14] <Laney> ubuntu@juju-prod-ues-proposed-migration-machine-12:~$ lxc list
[09:14] <Laney> error: Unable to decode the configuration: yaml: line 58: did not find expected key
[09:14] <Laney> all commands do this now
[09:14] <cpaelzer> outch
[09:24] <Laney> odd, the yaml got slightly corrupted
[09:24] <Laney> race condition?
[09:25] <Laney> but st_graber would tell me to stop using the xenial-updates version :-)
[09:46] <xnox> cpaelzer:  groovy.
[09:47] <Laney> TIL that vim's autopkgtests take 6 hours to run
[09:47] <Laney> that is one well exercised editor
[09:52] <xnox> it also tests embedding every single language for plugin bindings, no?
[09:52] <xnox> like vim-ruby, vim-python, etc/
[09:54] <Laney> I didn't click and look inside :>
[10:03] <paride> Laney, hi! I think probert-network should be included in main, as it's a direct dependency of probert, which is now seeded. See https://people.canonical.com/~ubuntu-archive/component-mismatches.html and https://bugs.launchpad.net/ubuntu/+source/probert/+bug/1830347
[10:03] <paride> are you the right person to ask? :)
[10:03] <paride> this will also unblock the probert migration
[10:07] <paride> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=fb93501a65eef2e90192d7a16845c6bdee4f99cc <- probert seed inclusion
[10:11] <Laney> paride: yeah, that's from the probert source package which is already in main, I can do that
[10:11] <paride> Laney, thanks!
[10:13] <Laney> done
[10:20] <cpaelzer> waveform: hiho, can you tell me something about rpi-eeprom in Debian?
[10:21] <cpaelzer> waveform: it seems to be non-existant - but the changelog of the package has Debian history
[10:22] <waveform> cpaelzer, I don't believe it's upstream in debian; we take it directly from raspbian
[10:22] <cpaelzer> waveform: so the changelog I see with Debian release entries is actually from raspbian
[10:22] <waveform> cpaelzer, correct
[10:22] <cpaelzer> ok, now what I see makes sense
[10:22] <cpaelzer> thanks waveform
[10:22] <waveform> np :)
[10:23] <cpaelzer> and also I see https://github.com/raspberrypi/rpi-eeprom has debian branches
[10:24] <cpaelzer> waveform: wow https://github.com/raspberrypi/rpi-eeprom/blob/debian/buster/debian/changelog moves from 7.11 to 9.0 in two weeks
[10:24] <cpaelzer> version number proliferation ...
[10:25] <cpaelzer> waveform: so to confirm you'll be syncing that avery no and then from there to Ubuntu
[10:25] <cpaelzer> so 7.8 in groovy now and (if the version bumps continue) 128.4 somewhen in 21.04 then
[10:26] <cpaelzer> waveform: final question the delta you add, does that make sense to upstream to that project?
[10:26] <cpaelzer> or will we carry all of that forever "just for us"
[10:43] <waveform> cpaelzer, correct - I'll be trying to keep up with it, but as you noted 9.0's just been released - I figured I'd hold off on that until the MIR was done for some vague stability during that process :)
[10:43] <waveform> cpaelzer, let me just refresh my memory on the delta...
[10:49] <waveform> cpaelzer, the only delta we've got is the python3 patch and there was quite a bit of discussion of that upstream (https://github.com/raspberrypi/rpi-eeprom/issues/43, https://github.com/raspberrypi/rpi-eeprom/issues/94, https://github.com/raspberrypi/rpi-eeprom/pull/199, https://github.com/raspberrypi/rpi-eeprom/pull/203) - the upshot is that they're sticking with their /usr/bin/env shebang but modifying it to /usr/bin/env python3 instead of /
[10:49] <waveform> usr/bin/env python - so I'm assuming we should continue patching that to /usr/bin/python3
[11:00] <doko> waveform: yes, python must not be called from packages
[11:03] <waveform> doko, yes - at the moment (7.8 and 8.0), the shebang they're using is #!/usr/bin/env python - in future (9.0+) they're going to use #!/usr/bin/env python3 - however, despite that calling python3, I'm assuming we don't want the /usr/bin/env portion either (I can't recall the reason /usr/bin/env is considered bad off the top of my head, but I'm reasonably sure there is one :)
[11:15] <cjwatson> The issue with /usr/bin/env is that it means that the package will end up using a stray Python installation from elsewhere on $PATH (e.g. /usr/local/bin) if it exists.  Whether you think that it should be possible for the sysadmin to override the packaged version in this way is to some extent a philosophical question, but it mostly seems to end up being a footgun in practice
[11:59] <gpiccoli> hey xnox, do you think it's possible to get systemd released with the patch in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746 ? That would fix the PPA memlock issues
[11:59] <gpiccoli> cjwatson ^
[11:59] <gpiccoli> we wouldn't even need to mess with PAM stuff, etc
[12:13] <rbalint> gpiccoli, SRUs are usually prepared and coordinated by ddstreet
[12:15] <xnox> gpiccoli:  normally we package systemd out of git tree mentioned in Vcs header. and yeah normally ddstreet uploads bionic srus. do check with him if there is anything in flight or not.
[12:15] <gpiccoli> ok rbalint/xnox, I was considering something a bit more agile just for one fix, in order to resolve our PPA builder stuff
[12:16] <gpiccoli> But certainly I can check with Dan, likely this fix can be merged in his next cycle
[12:16] <xnox> gpiccoli:  to quickly rebuild pid1 that runs on hundreds of millions of machines?
[12:16] <xnox> it's not like we have ability to push out optional updates
[12:17] <xnox> gpiccoli:  merge proposal of the patch alone to https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu-bionic would be preffered.
[12:17] <gpiccoli> xnox, I understand that the PPA bootstraps a new cloud image when available
[12:18] <gpiccoli> So, getting the fix to systemd is the 1st step..then the image builder will consume that and "soon" PPAs will be using the new systemd
[12:19] <xnox> gpiccoli:  yes lead time on getting this out is 3-5 weeks. but also it's not critical, apart from just the one build that trips it up at the moment?
[12:19] <xnox> (which should just have an upload to ignore that test case for now, or run it as autopkgtest)
[12:20] <gpiccoli> xnox, I antecipated that it'd take some time, so I manage to get another "fix" into the package (the alternative (b) in my email)
[12:20] <gpiccoli> So for cryptsetup it's not critical, indeed
[12:21] <xnox> gpiccoli:  this is not a risk free change either.
[12:22] <Laney> LocutusOfBorg: I purged your armhf requests out of the queue, a lot of them duplicated ones I already submitted, see above
[12:29] <gpiccoli> xnox, what change, systemd's or cryptsetup's?
[12:29] <gpiccoli> The cryptsetup change mimics the build process we've been following forever before August
[12:31] <LocutusOfBorg> thanks!
[14:33] <juliank> tjaalton: seeing graphics corruption on i195 again on the T480s, anything known?
[14:33] <juliank> Don't know when it started
[14:33] <juliank> but it's latest groovy
[14:33] <juliank> I see a kernel error with i915 trace
[14:33] <juliank> Sep 16 13:21:48 jak-t480s kernel: workqueue: PF_MEMALLOC task 131(kswapd0) is flushing !WQ_MEM_RECLAIM events_unbound:active_work [i915]
[14:34] <tjaalton> juliank: what is it like?
[14:34] <juliank> tjaalton: Red lines, white blocks around typed characters
[14:35] <tjaalton> which app?
[14:35] <juliank> tjaalton: system wide
[14:35] <juliank> it worked fine this morning
[14:35] <tjaalton> ah, not here
[14:35] <juliank> i left it alone for an hour to go cycling, then it got the error I suppose and stopped working
[14:36] <juliank> I have videos
[14:37] <juliank> I'll go reboot and guess it's gone then
[14:39] <juliank> Post reboot is good
[14:39] <juliank> I shall report a kernel bug for the kernel issue
[14:40] <tjaalton> which exact kernel version?
[14:40] <juliank> tjaalton: Ubuntu 5.8.0-18.19-generic 5.8.4
[14:41] <tjaalton> proposed has -19
[14:41] <tjaalton> which is also what I'm using
[14:42] <tjaalton> since it cuts power consumption by 40% or so
[14:42] <juliank> sweet
[14:42] <juliank> I'm docked all the time
[14:42] <juliank> It does not really matter much :D
[14:42] <tjaalton> well it was a regression
[14:42] <tjaalton> so back to normal now
[14:44] <juliank> Rebooting into it now
[14:47] <tjaalton> so you use an external monitor then?
[14:47] <tjaalton> if docked
[14:59] <juliank> tjaalton: I do, but I cross-check on internal monitor :)
[15:00] <juliank> It's docked to ThinkVision P24h-10 via USB, which offers charging, USB hub, and 1440p display
[15:00] <juliank> All via one neat USB-C cable
[15:03] <bdmurray> rbalint: I tested bug 1891657 some more and as I mention in comment #17 I think it is a systemd issue
[15:04] <rbalint> bdmurray, thanks, getting to that shortly
[15:09] <tjaalton> juliank: yeah, but having both is probably what triggers your bugs
[18:01] <arnatious> arnatious
[18:02] <arnatious> ^ ignore that command got stripped
[19:04] <wbn> could I bug someone to rebuild this package from `tags/2.26`? https://packages.ubuntu.com/focal/libpam-yubico
[19:05] <wbn> (ah. nevermind... i need to wait for them to cut 2.27)
[21:22] <abyssangel> hello
[21:27] <sarnold> wb abyssangel
[21:28] <abyssangel> hello sarnold
[22:52] <Unit193> BTW, thanks to whoever re-tried limnoria before I could! :)