[14:03] <faa> hello after 22.3 (updated 21.4) have error E1: {'lock-passwd': False, 'name': 'root', 'passwd': '$6$A...', 'ssh-authorized-keys': ['ssh-ed25519 AAAA...']} is not valid under any of the given schemas (cloud-init schema --system)
[14:25] <waldi> faa: check for non-numeric uid, lists of sudo rules
[14:27] <waldi> err, it is called "ssh_authorized_keys" and "lock_passwd"
[14:30] <faa> ssh_authorized_keys not more uniq for user? lock_passwd not fix error message
[14:39] <waldi> faa: please make sure you use "_" (underline), not "-" (dash) in the key names
[14:45] <faa> yes if only fix lock_passwd, error exist if delete ssh-authorized-keys (move to root level), but this brocken individual user keys?
[14:55] <waldi> faa: and what happens if you use the correct name "ssh_authorized_keys"?
[15:08] <faa> yes my bad, old old legacy format templating, ssh_authorized_keys work fine, but validator not display error "ssh-authorized-keys" on root level


[07:39] <svij> is there no "snap update" command, or will it update automagically?
[07:40] <zyga> svij: it's snap refresh
[07:41] <svij> ah I see, is there no command to update all snaps, rather than one single with refresh? (I don't need it right now, just curious)
[07:43] <zyga> svij: it will be refresh, just not implemented yet
[07:43] <svij> zyga: ah okay
[07:43] <svij> thx
[07:57] <dholbach> kyrofa, sergiusens: once you're both up, can we chat about the snapcraft sessions at UOS and get them scheduled?
[08:02] <slvn> jdstrand, zyga, about SDL2 failling with UDEV for Initialization of INIT_Joystick. That happens when calling "udev_monitor_new_from_netlink", and apparmor says :  audit: type=1400 audit(1461830101.683:1127): apparmor="DENIED" operation="create" profile="snap.MyApp.app" pid=11228 comm="MyApp" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
[08:02] <slvn> (maybe I need to use the plug network ?)
[08:02] <zyga> slvn: I suspect that will stay denied for a while unless netlink support in apparmor is improved, for now I'd compile joystick support out
[08:03] <slvn> zyga, it's not blocking anyway.. joystick is just not initialized.. just report the issue
[08:03] <zyga> ah, ok
[08:06] <slvn> zyga, also audio was failing, but it's not *killing* the apps, it just stays not initialized.
[08:13] <slvn> zyga, just correcting myself, in fact, audio pulse if really failling (.shm_open() failed: Permission denied). So I need to desactivate it.
[08:17] <zyga> slvn: we know about audio, we'll get something supported, if you check the backlog we discussed this issue last night
[08:17] <zyga> slvn: there are still a few things to decide before that can happen but we do know about it
[08:19] <slvn> zyga, ok
[08:45] <ysionneau> about Mark shuttleworth's email : what's "GA" ?
[08:48] <zyga> ysionneau: general release?
[08:48] <ysionneau> A for Release ? :o
[08:51] <zyga> availability? :)
[08:54] <zyga> globally awesome release :)
[08:55] <Gunther_> hehe we also discussed the meaning of "GA" here :)
[08:59] <ysionneau> :)
[09:00] <vijaikumar> General Availability
[09:05] <ysionneau> thanks
[09:29] <Gunther_> latest allsnaps: sudo snap remove trionet error: can't remove "trionet": cannot find mounted snap "trionet" at revision 100001
[09:29] <Gunther_> :(
[09:31] <Gunther_> did work before, but at one time complained about: sudo snap remove trionet [-] Remove snap "trionet" from the system error: cannot perform the following tasks: - Remove snap "trio
[09:31] <Gunther_> and after reboot I am stuck
[09:32] <zyga> Gunther_: it's known broken for now
[09:32] <zyga> Gunther_: will be fixed with the next SRU
[09:32] <zyga> Gunther_: you can use my script to reset snap state: github.com/zyga/devtools
[09:33] <zyga> Gunther_: look at reset-state
[09:33] <Gunther_> ok thanks
[09:33] <zyga> Sorry for the bad experience
[09:33] <Gunther_> no problem, I am developer myself
[09:38] <Gunther_> zyga: worked great ;-) all snaps removed including the kernel (ooops)
[09:38] <zyga> Gunther_: ooops
[09:38] <zyga> Gunther_: this was tested on the desktop
[09:39] <zyga> Gunther_: it would need some love on devices
[09:39] <zyga> Gunther_: can you look at what would be needed to make it work there and fix it please
[09:39] <Gunther_> zyga: I ll try
[09:40] <dpm> oh, I just discovered a nice snap trick: https://bugs.launchpad.net/snappy/+bug/1574829/comments/1
[09:40] <dpm> snap without sudo
[09:53] <asac> pitti: where is the rename of wlan0 to wlxXXXXXX done? I couldnt find the matching rule in udev
[09:54] <pitti> asac: in xenial release it is still /lib/systemd/network/90-mac-for-usb.link
[09:55] <asac> ahh... /me was already thinking maybe its in systemd
[09:55] <pitti> asac: however, that will change soon (also in xenial) to /lib/udev/rules.d/73-special-net-names.rules due to bug 1574483
[09:55] <asac> ok gotcha... let me study the .link file a bit though so i know how that works
[09:56] <pitti> asac: see /usr/share/doc/udev/README.Debian.gz
[09:56] <pitti> that still refers to a wrong name (01- instead of 90-)
[09:57] <qengho> My gnome-disks UI looks pretty hilarious after using snappy for a while.
[10:53] <zyga> _morphis: hey, you should be able to rebase n-m interface on top of https://github.com/ubuntu-core/snappy/pull/1078 now
[10:53] <_morphis> zyga: awesome!
[10:53] <_morphis> will do, thanks a lot for that!
[10:54] <zyga> _morphis: https://github.com/ubuntu-core/snappy/pull/1078/files#diff-939866a2238749d2c6989a8a757f430f
[10:54] <keestu> Hi, I use ubuntu since last 5 years. I came across  about the snappy. I have dev embedded board, and i have a question now.  Is it possible to get ubuntu core into the this embedded device ?
[10:55] <zyga> keestu: yes, you need a kernel that works there and a supported bootloader
[10:55] <zyga> keestu: though right now devices (boards) are in rapid development after 16.04 release so expect a lot of changes in the next few weeks
[10:56] <keestu> zyga,  thanks, my knowledge is petty limited to this. I have a board, where we port android, linux with qt, how snappy is going to be different ?
[10:57] <zyga> keestu: if you have a working kernel, it should be not much different
[10:57] <zyga> keestu: the only requirement is a supported arch, what SoC
[10:57] <zyga> keestu: (you don't build snappy entirely from source,)
[10:58] <zyga> keestu: you just buld the kernel and gadget snaps, the rest is stock and shared by all devices
[10:58] <keestu> so, snappy is a way to get the customized desktop feel in embedded device ?
[10:58] <zyga> keestu: snappy has no desktop feel
[10:58] <zyga> keestu: anyway, please familiarize yourself with the documentation on snappy that's available on ubuntu.com now
[10:59] <keestu> zyga,  i am looking at the business perspective.  We see the customers demanding porting android to our embedded device.
[10:59] <keestu> zyga, sure.
[11:00]  * zyga -> lunch
[11:00] <keestu> :)
[11:00] <keestu> bon appetit
[11:15] <slvn> zyga, another issue snap+SDL2+x11. At first install (after reset-state), it doesn't connect to x11. I need to remove the snap, then reinstall it. then it can connect to x11. The syslog error was "apparmor="DENIED" operation="connect" profile="snap.MyApp.app" pid=22559 comm="MyApp" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none<EMAIL_ADDRESS>[11:15] <slvn> peer="unconfined"
[11:20] <ogra_> ppisati, have you seen bug 1574103 ?
[11:20] <ogra_> and bug 1574075 might also be interesting
[12:03] <sergiusens> dholbach I will have to rain check on that and ask for it to be in a couple of hours; both kyrofa and myself are unavailable right now
[12:08] <seb128> sergiusens, can parts/files have dynamic values?
[12:08] <seb128> like "somelib: /usr/lib/$(ARCH)/somelib"?
[12:08] <seb128> sergiusens, hey btw :-)
[12:19] <jdstrand> slvn: fyi, you need to plugs either unity7 or x11. did it not autoconnect?
[12:25] <slvn> jdstrand, both are in the plugs list (and also opengl) of the snapcraf.yaml file
[12:26] <slvn> maybe the reset-state script is incomplete ?
[12:26] <jdstrand> slvn: would you mind filing a bug for that? show your snapcraft.yaml, how you installed, the denial and the policy in /var/lib/snapd/apparmor/profiles/snap.MyApp.app
[12:27] <slvn> first install -> x11 doesn't work. then remove, and install again. it works
[12:27] <jdstrand> slvn: and please add that detail :)
[12:28] <slvn> jdstrand, yep. I go away now, but I will re-try that later and fill a report.
[12:28] <jdstrand> slvn: thanks. others have seen this but I don't think there is a bug
[12:29] <slvn> jdstrand, if first install always fail to launch, it's kind of problematic for me :)
[12:29] <jdstrand> slvn: very much indeed :)
[12:29] <bencc> can I package an erlang app with snappy and do hot code upgrade?
[12:30] <slvn> jdstrand, but i'll double check later and let you know! ++
[12:30] <bencc> upgrade the code while the app is till running?
[12:30] <dholbach> sergiusens, I'll have to leave at 16:00 or 16:15 UTC today - it'd be good if we could talk about it before
[12:42] <zyga> slvn: you can always connect manually but I'm wondering why auto-connect did not work
[12:42] <zyga> slvn: thanks, I'll investigate this
[13:05] <wesleymason> Snapcraft Q: is there a variable representing the install stage path that I can, for example, pass to a makefile to tell the target where to install into
[13:05] <wesleymason> ?
[13:07] <kgunn> zyga: just confirm, if i change something in snap, go build it and snapd, copy over and fire up snapd...i should see the change i made in snap?
[13:08]  * kgunn swears he saw this before, hopes he's not going crazy
[13:08] <zyga> kgunn: in a meeting, you need to copy snapd (and restart it, devtools helps)
[13:08] <zyga> kgunn: for security changes disconnect and reconnect
[13:08] <kgunn> zyga: was doing pkill -9 snapd, then starting
[13:08] <oparoz> wesleymason, $SNAPCRAFT_STAGE
[13:09] <zyga> not really
[13:09] <zyga> kgunn: try github.com/zyga/devtools
[13:09] <zyga> there are more bits and magic there
[13:09] <zyga> and it's all made for this use case
[13:09] <wesleymason> oparoz: great, cheers
[13:09] <kgunn> zyga: ok
[13:09] <kgunn> so i can't just go build snap/snapd, copy over?
[13:10] <zyga> you can but you need more, devtools does all that
[13:10] <zyga> and more :-)
[13:10] <zyga> try it
[13:10] <kgunn> ok, i may need help, cause my vm i use for mir isn't the standard one
[13:10] <zyga> syure
[13:10] <zyga> sure*
[13:10] <kgunn> mainly ssh  config i suppose
[13:11] <oparoz> Is there a recommended way to use start-stop-daemon in init scripts? Default policy doesn't allow scripts to call it
[13:12] <ogra_> first of all you would have to ship it in your snap :)
[13:13] <ogra_> (and then i dont think it would be accepted or used at all in the end ... given we use systemd in snappy )
[13:14] <oparoz> ogra_, I get "access denied", so it must be there, just not allowed. The way I understand it is that systemd calls whatever start script is given to it, so it shouldn't be an issue to call this command, no?
[13:15] <kgunn> zyga: actually...i got it....devtools talking to my vm, i see devtools.snap in there :)
[13:15] <kgunn> relying on magic now
[13:15] <ogra_> oparoz, it is a tool from sysvinit scripts ... it should really not be used at all in systemd envs
[13:16] <ssweeny> jdstrand, zyga, is there a recommended way to do service logging in snappy? My location-service snap is trying to create /var/log/location-service which obviously isn't going to work
[13:16] <zyga> kgunn: cool, just use refresh-bits (it has --help and is trivial to read)
[13:16] <zyga> ssweeny: I don't think there is one, maybe just let systemd manage logging
[13:16] <zyga> ssweeny: but I don't really know
[13:16] <ssweeny> zyga, ok, thanks
[13:16] <ogra_> ssweeny, "snappy service logs" used to do that ...
[13:16] <zyga> kgunn: I will gladly take patches for new features
[13:16] <kgunn> zyga: hmmm, with latest tools...do i have to sudo snap for such things as "snap list" ?
[13:16] <ogra_> i would expect that to be back once the snap service command comes back
[13:16] <zyga> kgunn: yes, because the socket is root-owned
[13:17] <zyga> kgunn: or chmod 666 /path/to/socket (/var/snapd.socket AFAIR)
[13:17] <zyga> kgunn: it's not handled by devtools because I was always lazy and using sudo
[13:17] <kgunn> that's right...i see a note
[13:17] <kgunn> ok, fully relying on devtools...and i still don't see my mod
[13:17] <zyga> kgunn: if you get it supported, just send me a patch please, I was annoyed by this once and there was one bug hidden by this already
[13:17] <zyga> kgunn: what's the mod about? policy change?
[13:18] <zyga> kgunn: you should connect/disconnect or remove/install the snap because there is no logic that detects interface implementation changes yet
[13:18] <zyga> kgunn: you should also check generated profiles (/var/lib/snapd/{apparmor,seccomp}/profiles
[13:19] <jdstrand> ssweeny: if you want your own log, you need to change the path to somewhere in SNAP_DATA
[13:19] <ssweeny> jdstrand, yeah that was my other thought
[13:20] <zyga> jdstrand: hey, gustavo recommended that we work on making n-m interface supported on the desktop; it would also unblock a bunch of prospective snaps; can you tell me if the current policy there is safe for desktop use?
[13:20] <jdstrand> ssweeny: (if you don't want systemd to handle it-- with systemd it will capture stdout and stderr and you can use journalctl to see the output from your service)
[13:20] <kgunn> jdstrand: isn't there a command line to list interfaces?
[13:20] <zyga> jdstrand: (just comment on the pull request anytime you have a moment to look at it)
[13:20] <kgunn> i thot i recalled that...couldn't find the email
[13:20] <zyga> kgunn: snap interfaces
[13:20] <kgunn> dang it...soo simple
[13:20] <kgunn> shoulda guessed
[13:20] <zyga> :-)
[13:21] <seb128> does anyone know if parts/files have dynamic values?
[13:21] <seb128>  like "somelib: /usr/lib/$(ARCH)/somelib"?
[13:21] <ssweeny> jdstrand, ah so I can just change logging to stdout and stderr and systmd will take care of it for me? cool
[13:21] <zyga> seb128: I don't think they do
[13:21] <seb128> :-(
[13:21] <zyga> seb128, kyrofa: or sergiusens would know
[13:21] <zyga> seb128: what are you trying to build?
[13:21] <seb128> they are not around though
[13:21] <seb128> a GTK app
[13:21] <zyga> seb128: you can use $SNAP_ARCH
[13:21] <zyga> seb128: it's an env variable we set
[13:21] <seb128> to install thing?
[13:21] <jdstrand> ssweeny: note, it will also show up in syslog, but yes
[13:21] <zyga> seb128: you'd have to do a wrapper for it though
[13:21] <zyga> (or patch gtk)
[13:21] <seb128> at build time?
[13:21] <zyga> seb128: no, at runtime
[13:22] <seb128> that doesn't interet me
[13:22] <zyga> seb128: for build-time i don't know
[13:22] <zyga> (I'm hacking on the other side)
[13:22] <zyga> seb128: I'd recommend starting with amd64, then working with snapcraft hackers to generalize
[13:22] <jdstrand> zyga: re nm-- we had a rather lengthy discussion on that at the eod yesterday but I didn't think we came to a conclusion. but to specifically answer your queston, no, the nm policy is not safe for confined apps-- it grants too much privilege
[13:23] <zyga> seb128: for the runtime part I think we should perhaps explore patching some bits to understand snap runtime layout
[13:23] <zyga> jdstrand: ok, could we do a simple version for now that still works on the desktop and land that, iterating on a broader one using some other ways (attributes, more ifaces)
[13:23] <seb128> zyga, I'm on i386 so starting with amd64 is not going to work for me :p
[13:23] <zyga> jdstrand: I think the key is to ensure that we don't leave the desktop as we progress
[13:24] <zyga> seb128: oh, sorry
[13:24] <zyga> seb128: i386 is fine though, it's just a suggestion to try to solve the simpler problem first
[13:24] <seb128> right
[13:24] <seb128> well I've the arch coded
[13:24] <seb128> but I wanted to push that so jdstrand and others can play with it
[13:24] <jdstrand> zyga: I feel like I am missing context. we left it yesterday that we need more discussion for the desktop case
[13:24] <seb128> but it sucks if everyone needs to sed the arch before building
[13:25] <zyga> jdstrand: I just talked about this in the standup, gustavo recommended that we ensure it works on the desktop before it lands
[13:25] <jdstrand> well, then I need to understand the direction
[13:25] <jdstrand> zyga: did niemeyer_ comment in the pr?
[13:25] <zyga> jdstrand: checking
[13:27] <zyga> jdstrand: nope
[13:27] <zyga> there's the community sync in 3 minutes
[13:27] <zyga> let's continue that after if you have time, otherwise let's do it by email
[13:28] <jdstrand> zyga: email is probably best so everyone has context
[13:31] <seb128> did anyone look at snap and translations?
[13:31] <seb128> what would be the right place to discuss the topic/put notes?
[13:31] <seb128> list? launchpad pad? spec?
[13:34] <ogra_> seb128, UOS ? :)
[13:39] <ppisati> ogra_: ack
[13:40] <seb128> ogra_, right, because that's going to be useful if nobody of the snappy team is interested and joining
[13:41] <seb128> is there any plan to mount some part of the snaps to normal system locations?
[13:41] <seb128> rather than trying to make everything reallocatable?
[13:42] <seb128> mvo, hey, do you know if it somebody discussed making locales part of the core image before?
[13:43] <ogra_> i think that was discussed and deemed to be to space hungry
[13:44] <ogra_> (given it was designed for embedded without actual users)
[13:44] <zyga> seb128: I doub't that
[13:44] <zyga> (not relocatable)
[13:44] <seb128> zyga, :-(
[13:44] <ogra_> seb128, i suspect we're moving into -pd territory ...
[13:44] <seb128> ogra_, are such gaps documented somewhere? launchpad bugs?
[13:44] <ogra_> not that i know of ...
[13:45] <zyga> seb128: I think that would be against the idea of snappy
[13:45] <ogra_> but i personally wouldnt see locales as something to have in core ...
[13:45] <seb128> ogra_, you would see each application needing to ship the libc locale definition?
[13:46] <seb128> + to patch glib to allow relocating those
[13:47] <caio1982> hi there, i am snapping a system monitor tool and i wonder what plugs would be necessary to access /proc/vmstat and a given /etc file like /etc/mtab... is there one?
[13:49] <ogra_> seb128, well, a snap *has to be* completely inependend from the core system,. they always need to be separately upgradeable ...
[13:49] <ogra_> thats one of the base definitions of snappy
[13:50] <seb128> ogra_, with, snaps don't have to ship their own libc, do they?
[13:50] <ogra_> they can
[13:50] <seb128> but don"t have to?
[13:50] <ogra_> thats the one thing they could use ... but nothing stops you to ship your own
[13:51] <seb128> well, shipping your translations, fine
[13:51] <seb128> having to ship the glibc locale definitions
[13:51] <seb128> I doubt it's something any appdev is going to want
[13:51] <seb128> also glibc doesn't support relocating those
[13:52] <ogra_> well, but shipping them in core means you add a dependency
[13:52] <seb128> depends to what?
[13:52] <seb128> snaps depends on the core anywhy
[13:52] <seb128> anyway
[13:52] <ogra_> between the system and the snap
[13:53] <ogra_> i.e. what if glibc locale handling code changes in incompatible ways in the system snap
[13:53] <ogra_> you would need something liek a versioned dependency
[13:59] <seb128> ogra_, you are saying "what if glibc changed in an incompatible way", but that's already an issue since you don't force snaps to ship a copy of glibc
[14:00] <ogra_> sure
[14:01] <seb128> if you have this stance it's fine, but then be consistent and force snaps to include a libc copy
[14:01] <dholbach> niemeyer, which time between 14 and 20 UTC would work for you for an interface session next week (3-5 May)?
[14:01] <dholbach> zyga, ^ too
[14:01] <seb128> if you allow them to rely on the core one there is no point to say that can only be for some parts of libc
[14:02] <zyga> dholbach: any except standups but I'm flexible
[14:02] <ogra_> seb128, right, the "it is useless on headless IoT systems without users" thing is still valid though ...
[14:02] <ogra_> we'd need two core setups
[14:02] <seb128> unsure
[14:03] <seb128> you might want your ls, etc to be in german
[14:03] <ogra_> which ls ?
[14:03] <seb128> your commands on the core
[14:03] <ogra_> on my router i only have that web UI :P
[14:03] <seb128> well, you might want that webui in german
[14:03] <ogra_> on my drone i even only have that mobnile app that talks to it
[14:03]  * zyga checks backlog
[14:04] <ogra_> sure, but for that i dont need glibc locales necessarily
[14:04] <seb128> right
[14:04] <seb128> we need frameworks :p
[14:04] <ogra_> good idea !
[14:04] <zyga> seb128: though ogra was spot on on pocket-desktop area, I think on personal the core snap could provide you with a gtk runtime interface
[14:04] <ogra_> uh
[14:04] <zyga> seb128: so if you want that runtime to be something you depend on, great, but I don't know if that's exactly what we want to do with gkt
[14:04] <ogra_> a whiole runtime is to much imho
[14:04] <zyga> seb128: perhaps for SDK runtime first
[14:05] <zyga> seb128: we don't need frameworks, we need interfaces
[14:05] <zyga> seb128: anything that a framework could do is doable with a new interface
[14:05] <seb128> can an interface snap add files to /var and /lib in your snap mount?
[14:06] <zyga> seb128: an interface can let a snap do this
[14:06] <zyga> seb128: we still don't have hooks, when we get them from new state engine we'll be able to react to all actions (connect, etc)
[14:06] <zyga> seb128: if you tell me more about the problem perhaps I could suggest a solution
[14:07] <seb128> zyga, trying to get translations working in my snap
[14:07] <seb128> which requires to have locales generated in /usr/lib/locale/locale-archive
[14:08] <seb128> that can be relocated
[14:08] <seb128> by then gettext tries to read from /usr/share/locale:/usr/share/langpack-locale
[14:08] <seb128> which can't be relocated
[14:08] <seb128> but as an appdev I don't want to have to learn how to generate libc locales
[14:09] <zyga> seb128: the appdev part should be solved with snapcraft support
[14:09] <seb128> I guess we could teach snapcraft to generate those though
[14:09] <seb128> that still doesn't solve the fact that glibc doesn't let you relocate/specify another dir to load the .mo
[14:10] <seb128> out of patching glibc's code and rebuilding glibc as part of your snap
[14:10] <zyga> seb128: doesn't textdomaindir do that?
[14:10] <seb128> no
[14:10] <seb128> it works only for the gettext command line
[14:10] <zyga> I mean
[14:10] <seb128> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114461
[14:10] <zyga> bindtextdomain
[14:10] <seb128> zyga, no
[14:10] <zyga> why not? it seems to do just that?
[14:11] <zyga> (assuming you build an app from source)
[14:11] <seb128> well
[14:11] <seb128> right, I'm repackaging a deb
[14:11] <zyga> ah, right
[14:11] <seb128> but then if you do that
[14:11] <zyga> for deb-repacking I agree
[14:11] <seb128> what if need also strings from libc
[14:11] <seb128> +you
[14:11] <zyga> what is the domain used by libc?
[14:11] <zyga> this feels like a SDK runtime problem
[14:11] <zyga> locale generation is perhaps more subtle
[14:12] <seb128> libc.mo
[14:12] <seb128> SDK sort of
[14:12] <zyga> but I think a snap developer should just end up with a bunch of .mo files
[14:12] <zyga> that they can even filter out if they want
[14:12] <seb128> gettext() is not specific to a SDK
[14:12] <zyga> yes, but SDK should just solve it for people
[14:12] <zyga> for just fishing parts of binary debs, it feels tricky
[14:12] <seb128> it could
[14:12] <zyga> so back to interfaces
[14:12] <zyga> we could design an interface that lets you do bind mounts and other magic
[14:13] <zyga> I just wonder if that's a solution (it doesn't feel like one)
[14:14] <seb128> yeah, maybe not
[14:14] <seb128> maybe we just make those part of pd
[14:14] <seb128> and declare that core users can't have translations
[14:14] <zyga> basic locales? I would say yes
[14:14] <zyga> core users will probably use webapps
[14:14] <zyga> and if not, they can bundle the world if they want a custom kiosk localized GUI
[14:15] <seb128> well, I guess as long as we provide easy tools to help them to bundle the world...
[14:15] <seb128> it still feels to me that locales are a base feature of the OS and shouldn't have to be bundle
[14:15] <zyga> I think we should explore both sides, patching sources to understand snap runtime layout and environment variables and reach for low-hanging fruit
[14:15] <seb128> but it's a good point that they take space and are not needed on a core
[14:16] <zyga> eventually I would hope that all important upstream projects have a getenv("SNAP") somewhere
[14:16] <seb128> is having the deb repackaging case working a goal
[14:16] <zyga> and that they just work
[14:16] <seb128> or just something hacking we play with?
[14:16] <zyga> that depends on if the upstreams support snap internally :)
[14:16] <seb128> yeah, I don't agree with that
[14:17] <zyga> I think our patches to n-m weren't merged
[14:17] <seb128> projects shouldn't have to getenv for platform specifc hacks
[14:17] <zyga> but if they were ,you could repackage nm (or be closer to) instead of having to build it
[14:17] <zyga> seb128: I somewhat disagree, this is a big shift
[14:17] <zyga> seb128: relocatability
[14:17] <zyga> seb128: nothing really supports that out of the box yet
[14:17] <zyga> perhaps it is not SNAP, perhaps SNAP Is in some common platform glue
[14:17] <morphis> sergiusens: ping
[14:18] <zyga> but patching upstreams for native relocatability would be worth-while IMHO
[14:22] <qengho> Spin up a new autopkgtest machine that uses "dpkg --instdir=/relocated/" to install.
[14:24] <popey> jdstrand: I have an app doing "Bad system call" inside a snap, in dmesg I see an apparmor failure with sig=31 arch=40000003 syscall=45 compat=1 ip=0xf77e3547 code=0x0 - is this something I can work around, a bug, or something else?
[14:24]  * zyga looks
[14:24] <qengho> Oh, popey. So innocent.
[14:25] <popey> wat wat wat
[14:25] <zyga> that's shmctl
[14:25] <ogra_> scmp_sys_resolver 45
[14:25] <ogra_> run that
[14:25] <jdstrand> popey: on the device do 'scmp_sys_resolver 45'
[14:25] <kyrofa> Hey seb128 dholbach I'm around now
[14:25] <ogra_> zyga, how do you know ? it varies between arches ;)
[14:25] <jdstrand> popey: it must be on the device/vm
[14:25] <zyga> ogra_: yes, true, I checked for amd64
[14:26] <popey> jdstrand: inside the snap?
[14:26] <zyga> brb
[14:26] <ogra_> :)
[14:26] <popey>  this is on my laptop
[14:26] <ogra_> zyga, it is brk on armhf
[14:26] <jdstrand> zyga, ogra_: note the syscall numbers are different depending on the arch
[14:26] <popey> (amd64)
[14:26] <jdstrand> popey: ok, on amd64 that should be recvfrom
[14:26] <popey> yes
[14:27] <jdstrand> popey: you need to plug one of network, x11 or unity7
[14:27] <jdstrand> popey: if you are, autoconnecting isn't working for you
[14:27] <popey> I have all 3
[14:27] <popey>     plugs: [x11, network, network-bind, unity7, opengl]
[14:27] <jdstrand> popey: right, my understanding is that removing and installing again will get it to connect
[14:27] <jdstrand> popey: otherwise you can manually connect
[14:28] <jdstrand> zyga: I asked slvn to file a bug for that, but I think he had to step away. do you have a bug for this? ^ is it known to you?
[14:28] <popey> jdstrand: removing "it" as in, the snap?
[14:28] <jdstrand> popey: yes
[14:29] <seb128> jdstrand, that's 32 bits code on amd64, unsure if that makes a difference?
[14:29] <jdstrand> zyga: in other news, I figured out why the unintended bluez change ended up in my branch and have adjusted my processes
[14:29] <seb128> if I understood popey correctly
[14:29] <jdstrand> seb128: I think you just confused me :)
[14:29] <jdstrand> he had a seccomp denial
[14:30] <seb128> right, I'm just saying that he's multiarching
[14:30] <jdstrand> so I just asked that he run scmp_sys_resolver on whatever architecture logged the denial
[14:30] <seb128> k
[14:30] <jdstrand> multiarch doesn't matter
[14:30] <seb128> I was mentioning in case
[14:30] <jdstrand> thanks
[14:30] <seb128> np
[14:31] <popey> bah! got into the state where I have to nuke and pave again :(
[14:31] <seb128> :-(
[14:31] <seb128> hey kyrofa
[14:32] <seb128> is there a way to tell snapcraft to rebuild without wipping out the deb cache?
[14:32] <popey> seb128: I ended up installing apt-cacher-ng on my laptop
[14:32] <seb128> popey, :-(
[14:32] <popey> seb128: feel free to point your apt at my laptop as a proxy ㋛
[14:32] <seb128> but thanks for the tip
[14:32] <kyrofa> seb128, you can clean individual steps of the lifecycle-- would that help?
[14:33] <popey> (I appreciate you may not want to)
[14:33] <kyrofa> seb128, instead of cleaning the pull, just clean back to build
[14:33] <seb128> kyrofa, I ended up reworking my yaml but that feels like a workaround
[14:33] <seb128> kyrofa, oh ok
[14:33] <kyrofa> seb128, essentially instead of cleaning everything, you say "don't wipe out the pulled stuff."
[14:33] <seb128> I ended up having 2 parts
[14:33] <seb128> and cleaning only one
[14:34] <seb128> I didn't know that my issue was due to "cleaning the pull"
[14:34] <seb128> or that was a thing
[14:34] <seb128> thanks
[14:34] <kyrofa> seb128, no problem! Yeah try `snapcraft clean -s build` (by default it cleans everything, including the pull step)
[14:34] <seb128> that sounds like a poor default :p
[14:34] <seb128> kyrofa, thanks!
[14:36] <dholbach> kyrofa, thanks... I was wondering if sergiusens, you and I could pick dates/times for the snapcraft UOS sessions
[14:37] <dholbach> we're still very much free to pick times between 14 and 20 UTC on 3-5 May
[14:37] <kyrofa> dholbach, yeah sounds good. sergiusens is running a few errands right now and I have a meeting in a few minutes, but after that I'm free all day
[14:43] <popey> Argh, "sudo snap install mylocalfoo.snap" on a clean box will download ubuntu core, fail to install it, fail to download my local snap from the store, but install my local one anyway, without ubuntu-core. So next time I try something it tries to download ubuntu-core again!
[14:43] <ogra_> uh
[14:44] <ogra_> popey, so your snap is i386 ?
[14:44] <ogra_> i wonder if it tries to download the matching core
[14:45] <popey> nope
[14:45] <ogra_> hmm, k
[14:45] <ogra_> i wonder why it fails then
[14:46] <popey> also, you have to remove snaps before installing them again, or you get a broken snap installed.
[14:46] <popey> repeatedly installing the same snap over and over leads to a non-functioning snap
[14:47] <jdstrand> popey: between those two and not autoconnecting, it sounds like you are hitting 3 bugs :\
[14:47] <popey> \o/
[14:47] <jdstrand> popey: 4 now :\
[14:47] <roadmr> a bug trifecta
[14:47] <jdstrand> popey: would you mind filing them?
[14:47] <popey> sure thing
[14:47] <jdstrand> I don't think any are filed
[14:47] <jdstrand> thanks!
[14:51]  * zyga confused signal number with syscall number
[14:51] <ogra_> mvo, ricmm, http://paste.ubuntu.com/16095818/ should we start with that ?
[14:52] <slvn> jdstrand, zyga : I have just retried this "auto-connect" issue with new package name, and it worked. then I did a "reset-state". the first new install was longer (installation of 64 MB ? whereas the snap is 2 Mo ...). and x11 didn't connect. re-install, it worked. To me, the issue seems something missing in the script "reset-state". Since this is non-official, should I make be a bug report ?
[14:52] <zyga> slvn: interesting
[14:52] <zyga> slvn: no, I'll experiment, thanks
[14:52] <zyga> slvn: the first time when you installed the snap it bundled ubuntu-core with it
[14:52] <zyga> slvn: when you installed the snap, was that side-loaded (locally on your FS) or from the store?
[14:52] <zyga> slvn: snap install ./foo.snap or snap install foo
[14:53] <zyga> ogra_, jdstrand: How do  you lookup syscalls?
[14:53] <ogra_> scmp_sys_resolver
[14:53] <jdstrand> zyga: signal vs syscall> easy to do
[14:53] <zyga> jdstrand: I know how to lookup signal numbers
[14:54]  * jdstrand wants to get to fixing snappy-debug to help people in this regard but has a few more things to tend to first
[14:54] <zyga> jdstrand: but not syscall numbers
[14:54] <jdstrand> scmp_sys_resolver ...
[14:54] <zyga> ahhh
[14:54] <jdstrand> (on the device)
[14:54] <jdstrand> always on the device :)
[14:54] <zyga> thanks!
[14:55] <jdstrand> (unless you know your archs are the same of course)
[14:55] <zyga> yeah, I had an index somewhere but I lost it now
[14:56] <jdstrand> seb128: hey, I saw you mention something about trying to get the tree together for me and others to test-- what is the status (just wondering if I should move to the next thing on my list and circle back or not-- no big rush)
[14:58] <seb128> jdstrand, I'm about to push
[15:00] <slvn> zyga, I have always installed the snap from my FS. I haven't played with the store yet.
[15:01] <dholbach> kyrofa, ok
[15:07] <jdstrand> seb128: thanks
[15:09] <seb128> jdstrand, ok, lp:~ubuntu-desktop/+junk/gnome-calculator-snap updated
[15:09] <jdstrand> seb128: thanks!
[15:09] <seb128> jdstrand, yw!
[15:10] <seb128> jdstrand, I'm going to file some bugs now about the issues we had/have and the workaround we did
[15:10] <seb128> jdstrand, btw got https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066 filed about the 32bits issue
[15:11] <zyga> jdstrand: just curious, what's the outlook on non-enforcing seccomp landing in the kernel?
[15:11] <seb128> jdstrand, "justincornack" says that updating libseccomp to 2.3.0 should fix it
[15:12] <jdstrand> zyga: I need to work with them on it. we have a good relationship with them, it is just devmode is a couple places down the list atm
[15:13] <zyga> jdstrand: sure understood
[15:13] <zyga> jdstrand: is there a place where I can look at the list?
[15:13] <jdstrand> zyga: at my list?
[15:13] <jdstrand> the security team trello board
[15:13] <zyga> jdstrand: do you have a link handy by any chance?
[15:14] <jdstrand> seb128: oh interesting
[15:14] <jdstrand> seb128: thanks!
[15:14] <seb128> jdstrand, yw!
[15:16] <seb128> jdstrand, I guess we should SRU https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435
[15:16] <seb128> desrt, ^
[15:16] <desrt> this won't help
[15:17] <seb128> oh :-(
[15:17] <desrt> this only helps if the C library is indeed calling those new functions
[15:17] <slvn> zyga, not sure you got the message : I have always installed the snap from my FS. I haven't played with the store yet.
[15:18] <zyga> slvn: ah, thanks
[15:18] <zyga> slvn: perhaps there's some interesting bug in that case, I'll give it a try
[15:18] <desrt> actually, i may take that back.  i have no idea what this does =)
[15:18] <desrt> and maybe it does contain/improve demuxing for that call, indeed
[15:18] <zyga> slvn: I know for a fact that there are plenty of related bugs fixed in master (to be released very soon)
[15:18] <zyga> slvn: perhaps tomorrow it will be in the archive
[15:19] <seb128> jdstrand, desrt, there are also other commits in trunk that might help in fact, our version is old
[15:19] <slvn> zyga, I used the same SDL2/snap of the other bug to test it.
[15:19] <ogra_> you have high hopes about our SRU process it seems :)
[15:19] <seb128> e.g https://github.com/seccomp/libseccomp/commit/d32c3bfa4b07add90dcd04292eb4ba278dd103ba
[15:20] <zyga> slvn: right, we had a bug that didn't auto-connect in some cases, I suspect it is that, I'll check again when I have power
[15:20] <seb128> though pitti backported some of those changes already it seems
[15:20] <zyga> slvn: I'll ping you tomorrow, after the release is out
[15:20] <slvn> zyga, I'll also tomorrow if there is some update:
[15:20] <desrt> https://github.com/seccomp/libseccomp/commit/983835f3e0fd000a42c8beaea9d7fbe726ffff65
[15:20] <desrt> this is the one that will really help
[15:21] <desrt> " + * Convert a multiplexed pseudo socket syscall into a direct syscall "
[15:21] <zyga> jdstrand: there's a micro task for home to auto-connect
[15:21] <zyga> jdstrand: do you think we should set it to auto-connect and let the store flag that for review?
[15:22]  * ogra_ wonders if we should prehaps grow the reviwers team
[15:23] <zyga> gahh, sorry, battery dies
[15:23]  * zyga orders a new battery, power cuts are annoying
[15:23] <zyga> ttyl
[15:26] <jdstrand> zyga: I think autoconnecting is fine-- the store currently flags for manual review. But the topic overall has an unclear path. sabdfl said to do one thing with x11/unity7 and niemeyer another. home to me is the same sort of thing.
[15:31] <mvo> ogra_: I like that, lets do it
[15:32] <ogra_> mvo, ok, will upload then
[15:33] <seb128> jdstrand, what's the right component to file the bug about "unity7 plug profile needs updating for menus"
[15:34] <jdstrand> seb128: snapd. add the snapd-interface tag
[15:34] <seb128> jdstrand, thanks
[15:37] <mvo> ogra_: nice, let us try to test today/tomorrow and see how it goes
[15:37] <ogra_> yeah
[15:37] <ogra_> well, we need someone who has a uboot gadget snap for i386
[15:37] <ogra_> i was hoping ricmm has something like that handy
[15:38] <seb128> jdstrand, bug #1576287
[15:46] <jdstrand> seb128: thanks
[15:53] <sborovkov> Hello, how do I enable classic shell now? snap enable-classic does not work
[15:57] <jdstrand> mvo: hey, does being a member of ubuntu-core on github give me commit access?
[16:02] <mvo> jdstrand: hm, I actually don't know, commit access to snappy on github? just create your branch and send a pull-request
[16:03] <jdstrand> mvo: I did that, but I also got an invite not long ago nad just accepted. my branch is tagged Reviewed. I wasn't sure if I should wait or commit and wanted to ask what the commit policy was
[16:04] <mvo> jdstrand: oh, ok. I think I saw that there was one outstanding question on the branch. or did that get resolved? if resolved one of us will merge it
[16:05] <jdstrand> mvo: I resolved it and made two reverts based on mailing list and bug feedback
[16:06] <mvo> jdstrand: nice, let me have a look then, I can merge it
[16:06] <mvo> jdstrand: usually (but not always) its branch-owner != person-who-merges
[16:06] <jdstrand> I see
[16:07] <mvo> jdstrand: we also have no separate branch for xenial and yakkety (love the name)
[16:07] <mvo> (yet)
[16:07] <jdstrand> ok
[16:07] <seb128> jdstrand, mvo, just for the record that's some bug reports about the issues we hit when playing with gnome-calculator https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue
[16:08] <jdstrand> nice
[16:09] <seb128> jdstrand, I guess there is already one for the gsettings proxy work?
[16:10] <seb128> or is it only in specs like https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement?
[16:12] <seb128> opened one, we can close it if needed
[16:13] <jdstrand> seb128: the proper confinement for gsettings is a separate thing. snaps on classic could utilize that, but we'll likely simply need to add it and say it is a limitation of the mediation (much like X is)
[16:14] <jdstrand> s/need to add it/need to add the rules for the global gsettings/
[16:14] <seb128> jdstrand, right, good, thank we can use bug #1576308
[16:15] <wililupy> Good morning ogra_, mvo.
[16:17] <ogra_> wililupy, good evening :)
[16:19] <seb128> jdstrand, the libseccomp issue, gnome-calculator on i386 hits the bug (it needs to download currency info from internet), I can test patchs if you want, just ping me with commits or debs
[16:21] <wililupy> I got the system to boot today after adding ahci to the initrd modules in snapcraft, but I still had to edit the grubenv file on /dev/sda2 to point to my kernel snap to boot up properly.
[16:22] <jdstrand> seb128: thanks
[16:24] <ogra_> wililupy, right, and that bit is out of my territory of knowledge ... mvo might be a better counterpart here
[16:25] <wililupy> ogra_ Thank you so much for your assistance on this. I now have a working Kernel snap with the modules in it, so now all I have to do is snap up the application and test it and I could be back on schedule. I still need to work on the grubenv so that install is easy and doesn't require user intervention.
[16:26] <mvo> wililupy: hm, is your kernel called vmlinuz and the initird.img ? the code currently assumes that
[16:26] <wililupy> mvo, do you know why the grubenv doesn't update with the snappy_kernel= variable?
[16:26] <mvo> wililupy: a symlink is probably fine
[16:26] <wililupy> let me check mvo.
[16:27] <mvo> wililupy: it should if the kernel snap is of type: kernel, could you paste your meta/snap.yaml please? I need to look what is going on
[16:27] <wililupy> definitely mvo.
[16:27] <mvo> wililupy: and please pastebin the output of grub-editenv right after you installed your kernel
[16:27] <wililupy> sure.
[16:27] <mvo> (but before you manually adjusted something)
[16:27] <mvo> cool, thank you!
[16:30] <wililupy> mvo: meta/snap.yaml: https://pastebin.canonical.com/155478/
[16:32] <ogra_> oha
[16:32] <wililupy> mvo: (hd,2)/EFI/ubuntu/grub.d/grubenv: https://pastebin.canonical.com/155479/
[16:33] <ogra_> why doesnt snapcraft set "type: kernel" ?
[16:33] <mvo> wililupy: could you please add "type: kernel" and see if that helps?
[16:33]  * ogra_ guesses there is your issue
[16:33] <mvo> aha ogra_ was faster :)
[16:33]  * mvo hugs ogra_
[16:33] <ogra_> heh
[16:33]  * ogra_ hugs mvo
[16:33] <wililupy> I can post my snapcraft.yaml
[16:34] <mvo> just add this one line first, that sounds very likely to be the culprit
[16:34] <ogra_> but it is weird, given the snapcraft kernel plugin was used
[16:34] <ogra_> i woudl actually expect that it sets that
[16:35] <wililupy> https://pastebin.canonical.com/155480/
[16:35] <wililupy> type: kernel before the parts: section?
[16:35] <ogra_> in meta/snap.yaml
[16:36] <wililupy> gotcha ogra_
[16:36] <ogra_> and then just "snapcraft snap" the dir
[16:37] <kyrofa> It seems /snap/bin is not in the PATH if I try to run with sudo. This worked in rolling-- is it a bug, or is it supposed to work this way?
[16:38] <sergiusens> popey I logged bugs about install/remove/install/remove/.../.../install
[16:38] <wililupy> snapcrafting now.
[16:39] <sergiusens> seb128 log a bug about the ARCH thing, we can support it easily
[16:39] <seb128> sergiusens, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576232
[16:40] <jdstrand> mvo: thanks for the merge. I'm not sure who is doing release notes, but one of those commits fixes bug #1575914
[16:42] <mvo> jdstrand: uh, thanks. a "Closes: LP#1575914" in the commit picks it up automatically
[16:43] <sergiusens> seb128 thanks, I love bugs! :-)
[16:43] <seb128> yw!
[16:43] <jdstrand> mvo: oh, whoops
[16:43] <jdstrand> mvo: I'll know for next time
[16:44] <wililupy> mvo, ogra_ same error, I have to modify the grubenv to boot up properly.
[16:44]  * jdstrand updates his notes for autoclosing snappy bugs
[16:45] <mvo> jdstrand: no worries, I will add it later manually
[16:47] <wililupy> weird, it didn't update the snap.yaml...
[16:47] <wililupy> I updated it in the snap directory and then re-ran snapcraft snap.... hmmmm
[16:47] <ogra_> E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors.
[16:47] <ogra_> P: Begin unmounting filesystems...
[16:47] <ogra_> P: Saving caches...
[16:47] <ogra_> GRRR !
[16:49] <wililupy> looks like snapcraft snap overwrote my meta/snap.yaml with the one without type:kernel.
[16:50] <ogra_> hmm, it shouldnt do that
[16:51] <kyrofa> wililupy, the snap folder it _output_, not input
[16:51] <kyrofa> is*
[16:52] <wililupy> kyroga, the snap directory, correct?
[16:52] <wililupy> kyrofa ^
[16:53] <kyrofa> wililupy, right
[16:53] <ogra_> kyrofa, we only wannt to check a one line change in snap.yaml .. and not re-build anything but the snap
[16:53] <om26er> stgraber, Hi! ChrisTownsendwas helping me debug an lxc container not starting, he suggested me to show the logs to you. Can you please take a look at these logs ? http://paste.ubuntu.com/16102061/
[16:54] <wililupy> I modified the snap/meta/snap.yaml there, then went back to my source directory and ran snapcraft snap.
[16:54] <kyrofa> ogra_, try `snapcraft snap snap` then?
[16:54] <kyrofa> ogra_, tell snapcraft to use the snap directory to create the snap rather than going through its lifecycle to do so
[16:54] <wililupy> I'll t ry that, can't hurt
[16:55] <ogra_> kyrofa, yeah, thats what i mean abover with <ogra_> and then just "snapcraft snap" the dir
[16:55] <ogra_> :)
[16:55] <ogra_> i should have written "snapcraft snap snap" :)
[16:55] <kyrofa> wililupy, ogra_ it's also worth noting that snapcraft will re-generate the meta/ directory each time, even if the rest of the lifecycle has already run
[16:55] <ogra_> oh
[16:55] <kyrofa> wililupy, ogra_ i.e. you don't need to rebuild the project just to change the meta/ dir
[16:56] <ogra_> well, he could just move the snapcraft.yaml away :)
[16:56] <ogra_> then it will just roll the dir into a snap
[16:56] <ogra_> without regenerating anything
[16:57] <wililupy> meta/snap/snap.yaml still has my changes after running snapcraft snap snap
[16:57] <wililupy> Another u-d-f and a burn in on the device...
[16:58] <ogra_> mvo, hmm, not sure why but seems my changes to live-build/ubuntu-core/hooks/15-remove-grub-common.chroot make the world explode (on all arches)
[16:59]  * ogra_ doesnt understand why ... very weird
[17:01] <ogra_> http://paste.ubuntu.com/16103786/
[17:01]  * ogra_ scratches head
[17:01] <wililupy> ogra_, mvo, kyrofa: That did it!!
[17:01] <ogra_> wililupy, well, we still dont know why snapcraft.yaml doesnt add the type field
[17:01] <ogra_> it should do that by default with the kernel plugin
[17:02] <wililupy> yeah, should I put in a bug?
[17:05] <ogra_> sergiusens, ^^^ is that a bug ? (kernel plugin not setting type: kernel in snap.yaml)
[17:06] <sergiusens> ogra_ you have to do that in your snapcraft.yaml
[17:07] <ogra_> sergiusens, https://pastebin.canonical.com/155480/
[17:07] <ogra_> does it need extra mentioning of type: kernel ?
[17:12] <sergiusens> ogra_ yes
[17:12] <ogra_> ah !
[17:12]  * ogra_ didnt know :)
[17:12] <sergiusens> ogra_ we have no contract for plugins changing top level things
[17:13] <ogra_> pfft :P
[17:13] <sergiusens> ogra_ it is a constant discussion we have internally as it would be ideal to also create apps and commands
[17:13] <ogra_> yeah
[17:13] <sergiusens> ogra_ but then what happens when the use wants to do something special :-)
[17:15] <ogra_> well, if it is set at the top level you dont touch it ... if nothing is set at the toplevel the plugin takes over
[17:15] <sergiusens> ogra_ what if you want to payload a kernel in a normal snap app?
[17:15] <sergiusens> for some weird reason
[17:16] <ogra_> notmal snaps dont have a type ?
[17:16] <ogra_> *normal
[17:17] <sergiusens> ogra_ implicit type 'app'
[17:24] <wililupy> sergiusens, so where in my snapcraft.yaml to I tell it that it is a type: kernel snap?
[17:25] <sergiusens> wililupy same level as name, summary, ...
[17:26] <wililupy> sergiusens: so after description: add type: kernel before parts:
[17:27] <sergiusens> wililupy order doesn't matter in yaml, just make it at the same level
[17:27] <wililupy> sergiusens: ack. Going to try it now.
[17:41] <sergiusens> ubottu hey
[17:42] <sergiusens> kyrofa hey, can you reach nodejs.org?
[17:42] <kyrofa> sergiusens, yessir
[17:42] <sergiusens> darn, what happened to my DNS?
[17:42]  * sergiusens reboots router
[18:10] <sergiusens> kyrofa here you go https://github.com/ubuntu-core/snapcraft/pull/490
[18:11] <sergiusens> kyrofa that is the one you thought of when you thought you thought incorrectly
[18:14] <sergiusens> elopio do you know the status of https://github.com/ubuntu-core/snapcraft/pull/480 ?
[18:17] <sergiusens> ogra_ so I push this (https://launchpad.net/snapcraft/+milestone/2.8.5) to yakety; wait for it to go in smoothly and then tag every bug in there to hint the SRU and then dput to xenial and wait?
[18:17] <sergiusens> is that it in a nutshell?
[18:17] <kyrofa> sergiusens, ah, you're right :P
[18:38] <ogra_> sergiusens, yeah
[18:38] <ogra_> there is a wikipage too for it
[19:00] <sergiusens> ogra_ I read the wiki page, twice; it assumes I know a bunch of things already :-)
[19:00] <sergiusens> ogra_ thanks
[19:00] <ogra_> heh
[19:00] <ogra_> bah ...
[19:01] <ogra_> so i cant remove /boot/grub on the os snap because there is a file in it !
[19:01] <ogra_> silly stuff ...
[19:01] <ogra_> unicode.pf2
[19:01]  * ogra_ removes it anyway
[19:09] <oparoz> Is there a particular reason the command wrapper changes the working dir to SNAP_DATA?
[19:09] <ogra_> it is the writable dir the snap provides ....
[19:09] <ogra_> (the default writable dir)
[19:10] <sergiusens> oparoz afaik it doesn't unless you tell it to
[19:10] <oparoz> Sure, but isn't it the user's responsibility to call commands from SNAP_DATA?
[19:10] <oparoz> sergiusens, maybe it's because I'm still on an older rolling Snappy then
[19:10] <ogra_> the user would call from SNAP_USER_DATA ;)
[19:11] <sergiusens> oparoz yeah, not seeing it http://paste.ubuntu.com/16118454/
[19:11] <ogra_> SNAP_DATA is somewhere in /var/lib ... it is the writable bit your snap knows about and if executed without any cotext that is the place where binaries can write
[19:11] <kyrofa> sergiusens, the wrapper cds into it
[19:12] <sergiusens> kyrofa not from what I am seeing here though
[19:12] <sergiusens> look at my pastebin
[19:12] <ogra_> if you execute a snap app in context of a user, then SNAP_USER_DATA is your place
[19:12] <sergiusens> unless you are talking about a daemon
[19:12] <oparoz> ogra_, let's say the user wants to wget something from a folder in SNAP_DATA, the files end up in the root of SNAP_DATA instead of the folder
[19:13] <sergiusens> kyrofa the qtlaunch script does iirc
[19:13] <sergiusens> but it is meant for UI apps, launched from a desktop file, so it should not really matter
[19:13] <kyrofa> sergiusens, oh, it was services with a workingdir I think
[19:13] <ogra_> oparoz, that shouldnt happen, the stuff should end up in SNAP_USER_DATA in such a scenario ...
[19:14] <ogra_> (i know it did in the past by default when i used my unconfined wget)
[19:14] <oparoz> ogra_, sergiusens that's the wrapper that gets created https://paste.ubuntu.com/16118505/
[19:15] <oparoz> Just before ubuntu-core-launcher, there is a cd $SNAP_DATA
[19:15] <oparoz> sergiusens, ogra_ could it be because of the security policy?
[19:15] <kyrofa> oparoz, probably an old version, I don't see it in the current: https://github.com/ubuntu-core/snappy/blob/master/snappy/binaries.go#L62
[19:15] <oparoz> I mean does it have an influence on the wrappers?
[19:15] <ogra_> it could well be that i'm not up to date ...
[19:16]  * zyga smells 15.04 snappy
[19:16] <ogra_> regarding my knowledge
[19:16] <zyga> oparoz: that's 15.04 right?
[19:16] <kyrofa> zyga, nah, not 15.04
[19:16] <oparoz> Thanks kyrofa
[19:16] <oparoz> zyga, thats the mvo image from february
[19:16] <zyga> ah
[19:16] <zyga> ancient stuff then
[19:16] <kyrofa> zyga, so rolling stable
[19:16] <oparoz> Indeed
[19:16] <zyga> SNAP_APP_doesn't exist anymore
[19:17] <ogra_> february  ?
[19:17] <ogra_> you should really update
[19:17] <kyrofa> ogra_, to what? A 16 image? :P
[19:17] <ogra_> yeah ...
[19:17] <oparoz> :)
[19:17] <ogra_> feb is definitely before 2.0
[19:17] <kyrofa> Indeed
[19:18] <zyga> oparoz: you can use my script to build a new image using mvo's udf
[19:18] <zyga> oparoz: github.com/zyga/devtools
[19:18] <ogra_> for 16.04 only the images from the last two weeks are actually ok
[19:18] <zyga> oparoz: though images are not fully supported now, you may have to re-flash periodically as we stabliize
[19:18] <zyga> ogra_: full of bugs, the next set will be okay (with next version of snapd)
[19:18] <oparoz> Thanks zyga, the problem is that all users of the ownCloud snap are still on that image, so I can't update yet
[19:19] <ogra_> sure, full of bugs, but up to date with the right concepts at least
[19:19] <ogra_> while all older images are simply broken
[19:19] <zyga> oparoz: I see
[19:19] <oparoz> But thanks for confirming that the change of dir doesn't happen any more
[19:19] <zyga> ogra_: I agree
[19:19] <zyga> there were more changes in the last month than in the year before
[19:20] <oparoz> ogra_, we have enough trouble getting people to test the image. If they need to re-flash every week, we're going to lose all of them
[19:20] <ogra_> yeah, understood
[19:20] <zyga> oparoz: it would be nice to at least switch to 2.0 snappy because that old image feels like tech debt personified, it's going to bite you more the longer you wait
[19:20] <oparoz> But yeah, it's problemtic because some problems don't apply any more
[19:20] <ogra_> it is just that any development you do on them is moot ... since the design of snappy changed a lot
[19:20] <zyga> you probably require an interface, you won't find that on that old image
[19:21] <kyrofa> zyga, still using old-security there. Fortunately the interfaces required are simple (network and network-bind)
[19:21] <zyga> I think you have a tough choice ahead
[19:21] <zyga> kyrofa: cool, nothing fancy to access hdds?
[19:21] <kyrofa> zyga, we're splitting partitions
[19:21] <zyga> kyrofa: ah, interesting
[19:22] <oparoz> We're going to have to switch in the next 2 weeks anyway
[19:22] <kyrofa> So the upgrade path is actually pretty easy. It's just that 16 a) isn't stable and b) doesn't seem to support preinstalling snaps so we can't generate a factory image
[19:23] <kyrofa> Unless mvo's new u-d-f fixed the --install and it works on 16
[19:23] <zyga> we're working on making udf saner again but it's still a roadmap
[19:23] <ogra_> i thought that was fixed a while ago
[19:23] <zyga> I mean a permanent fix
[19:23] <zyga> not another layer of duct tape
[19:24]  * ogra_ doesnt know what everyone has against duct tape ...
[19:24]  * oparoz agrees :D
[19:25] <oparoz> except when it comes to software development ;)
[19:25] <zyga> I'd hear what you say if I dind't have duct tape over my ears ;)
[19:25] <ogra_> well, at least you'll get rid of these hairs in your ears then :P
[19:26] <kyrofa> zyga, anyway, we'd love to jump to 16. But we need those things
[19:26] <kyrofa> So rolling stable is at least giving people something to test
[19:26] <zyga> kyrofa: those things?
[19:26] <kyrofa> stability and preinstalled snaps
[19:27] <zyga> kyrofa: I'm not sure I know what you refert to now
[19:27] <zyga> ah
[19:27] <zyga> stability as in debian stable, that I understand
[19:27] <zyga> preinstalled snaps, soon :)
[19:27] <zyga> ish
[19:27]  * zyga loves 'ish'
[19:27]  * ogra_ used to work for "ish"
[19:27] <oparoz> zyga, weeks?
[19:27] <zyga> oparoz: ask me after the next sprint
[19:27] <oparoz> zyga, OK
[19:28] <zyga> oparoz: now I can reliably predict by looking at coffee leftovers or other wizardy
[19:28] <kyrofa> oparoz, which is in 10 days
[19:28] <zyga> ish
[19:28] <zyga> yep
[19:28] <ogra_> https://de.wikipedia.org/wiki/Ish_%28Unternehmen%29
[19:28] <ogra_> (not even available in english )
[19:28] <kyrofa> ogra_, wait.. you were serious? :P
[19:28] <zyga> LOL
[19:28] <ogra_> yeah :)
[19:28] <zyga> that explains a lot ;)
[19:28] <zyga> hehe
[19:29] <zyga> lovely company name
[19:29] <ogra_> that was my last job before canonical ...  leading a tech team of 15 ppl
[19:29]  * zyga recalls the company that makes light bulbs "osram", which is very popular in poland despite the name
[19:29] <ogra_> cable internet was the new thing in germany back then
[19:29] <kyrofa> I can hear the promo now: "Stable... fast.. _ish_"
[19:30] <oparoz> (kyrofa, 10 days is good, we can make a decision then)
[19:43] <kyrofa> Hey sergiusens I figured out what was wrong with the ROS example
[19:44] <kyrofa> sergiusens, it's a locale issue-- setting LC_ALL=C fixes it
[19:44] <kyrofa> sergiusens, I guess something changed on xenial?
[19:44] <ogra_> should be C.UTF-8 nowadays
[19:44] <ogra_> (and iirc thats the default fallback in xenial)
[19:45] <kyrofa> ogra_, setting that works too, but without it it barfs
[19:45] <kyrofa> ogra_, but my ignorant american self doesn't know very much about locales :(
[19:45] <ogra_> yeah, you're i ascii-land
[19:47] <ogra_> wow, snapcraft grew some solid dependencies ...
[19:47]  * ogra_ notes while reading image build logs that it pulls in 30 packages and eats 10MB nowadays
[19:48] <ogra_> (50MB installed)
[19:56] <oparoz> IF I want to add "reload to a daemon, I simply add reload-command to the "app" in the yaml?
[19:57] <zyga> oparoz: not sure
[19:57] <zyga> gimme a sec
[19:57] <oparoz> https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
[19:57] <oparoz> No mention or reload, so I gues not...
[19:59] <zyga> one sec :)
[19:59] <zyga> checking now
[19:59] <oparoz> Thanks zyga :)
[20:00] <zyga> oparoz: so there's restart condition
[20:00] <zyga> but there is no restart command
[20:00] <zyga> wait
[20:00] <zyga> checking services
[20:00] <oparoz> zyga, I've noticed that restart works out of the box, but reload doesn't, so I thought I needed to add something to the yaml
[20:01]  * ogra_ sighs ... livecd-rootfs doesnt like me today
[20:01] <zyga> there are ExecStop
[20:01] <zyga> ExecStopPost
[20:01] <zyga> ExecStart
[20:01] <zyga> and that's it
[20:01] <oparoz> :(
[20:01] <zyga> there's also Restart
[20:01] <zyga> what are you looking for exactly?
[20:02] <ogra_> cant you send a HUP to the process if it is in the same snap ?
[20:02] <oparoz> zyga, in quite a few situations, you just want to reload a config without having to bring everything down and up again
[20:02] <zyga> oparoz: do what ogra_ said
[20:03] <oparoz> OK, I will give it a go
[20:16] <oparoz> pkill didn't work, but kill did, thanks ogra_
[20:17] <ogra_> good
[20:22] <wililupy> ogra_ adding the type: kernel to the snapcraft.yaml makes it work as designed!
[20:22] <ogra_> yay
[20:22] <wililupy> No need to change anything manually.
[20:22] <ogra_> good you finally got everything working :)
[20:23] <wililupy> Yes!
[20:23] <wililupy> Now on to building the app snap. This should be a little more straight forward.
[20:23] <zyga> oparoz: pkill would need /proc access
[20:24] <wililupy> Thank you so much ogra_, mvo, sergiusens, kyrofa!
[20:24] <zyga> morphis: any updates on https://github.com/ubuntu-core/snappy/pull/1036
[20:24] <ogra_> np
[20:24] <oparoz> Ah, thanks zyga. That was a question I had. Any daemon requesting access to /proc is hutdown, correct?
[20:24] <zyga> oparoz: not really, just denied access to pkill wound't be able to find all the details probably
[20:24] <zyga> oparoz: (depending on how pkill is written)
[20:25]  * zyga should finish the current post on snappy security
[20:26] <oparoz> zyga, OK, so denied access which some "app" may not be too happy about
[20:40] <ogra_> yay, finally ...
[20:40]  * ogra_ has the images building again
[20:43] <zyga> ogra_: cool :-)
[20:43] <ogra_> silly stuff ...
[20:43] <ogra_> something like:
[20:43] <ogra_> [ -d /boot/grub ] && rm -f /boot/grub
[20:44] <ogra_> makes everything explode ...
[20:44] <ogra_> because on all arches where that dir doesnt exist the test exits non-zero and tears down live-build
[20:45]  * ogra_ hates that common sense doesnt apply in some cases ...
[20:46] <zyga> ogra_: like almost always?
[20:46] <ogra_> heh
[20:46] <zyga> ogra_: note that common sense is just that, common, it's not really always sensible :)
[20:46] <kgunn> zyga: i was just wondering, when hacking on snap/snapd and using your tools...i was just doing refresh-bits snap/snapd/run-snapd...but should i be doing 'refresh-bits setup' first ?
[20:46] <ogra_> so true
[20:47] <kgunn> i'm still not seeing any of my changes applied when i run the tools
[20:47] <kgunn> fwiw, i did try doing refresh-bits setup...but didn't make a diff
[20:48] <zyga> kgunn: setup is needed once per vm boot
[20:48] <zyga> kgunn: it ensures that regular snapd doesn't start by accident
[20:48] <zyga> kgunn: I run setup snapd run-snapd; then only snapd run-snapd
[20:49] <zyga> kgunn: what were you hoping to happen?
[20:50] <zyga> kgunn: what changes?
[20:52] <zyga> kgunn: after you push the new snapd to your VM you should uninstall/reinstall your mir snap
[20:52] <zyga> kgunn: and observe interfaces reported by snap interfaces
[20:52] <zyga> kgunn: and observe generated apparmor/seccomp profiles
[20:53] <kgunn> zyga: so question...if i don't install mir snap at all, and only run the mod'd snapd...and i type snap interfaces...i should see the mod correct?
[20:53] <zyga> what mod?
[20:53] <kgunn> zyga: mod== addition of an interface called mir
[20:53] <zyga> what were you expecting to see exactly, from what I remember from your branch you woundn't see anything new
[20:54] <zyga> there is no way to see the list if interfaces
[20:54] <zyga> just the list of plugs and slots
[20:54] <zyga> those come from snaps
[20:54] <zyga> note that the OS snap would *not* offer the mir slot
[20:54] <zyga> it would be offered by mir itself
[20:54] <zyga> so you'd have to install new snapd, install mir (snap) and see what the rsult is
[20:54] <kgunn> ok
[20:55] <zyga> does that make sense?
[20:55] <zyga> snapd would contain the implementation of mir interface
[20:55] <zyga> but that would only show up when you install the mir snap
[20:55] <zyga> normally snappy logs and ignores unknown interfaces on snaps
[20:56] <zyga> but with your patches, mir snap would really gain the mir slot
[20:56] <zyga> and would really gain the permanent permissions resulting from that slot
[20:56] <zyga> right?
[20:56] <kgunn> zyga: ok, maybe i've been trying to see something that simply won't happen
[20:57] <kgunn> i'll fiddle a bit more later with this...good to know on the setup run first time on vm tho
[21:46] <sergiusens> kyrofa sadly saying please is mandatory
[21:49] <ogra_> you could also friendly say please though
[21:49] <ogra_> :P
[21:55] <sergiusens> ogra_ not to a build system that decides to fail :-P
[21:55] <sergiusens> ogra_ imagine saying please to livecd rootfs ;-)
[21:55] <ogra_> i did, it helped !
[22:15] <thekeymaker> if you are building snaps using snapcraft on ubuntu 16.04, is there a easy way to try(run) them instead of installing them with the command snap install ./my-snap?
[22:53] <zyga> thekeymaker: not yet
[22:54] <zyga> thekeymaker: though installing them is very lightweight
[22:54] <zyga> thekeymaker: we just copy and mount them
[22:54] <zyga> there are plans to add a new command that will be even better but that's not finalized
[22:55] <zyga> thekeymaker: and also note that unless you run master you should remove the snap first, this will avoid hitting a number of known, fixed but (not released) bugs
[23:10] <oparoz> zyga are symlinked followed when a snap is removed or purged?
[23:10] <oparoz> *symlinks
[23:10] <zyga> I'm not sure, probably
[23:10] <zyga> but I don't really know and it's rather too late for me to check now
[23:11] <zyga> (and give you an accurate answer)
[23:11] <oparoz> yeah, no worries, was surprised to still see you here ;)
[23:11]  * zyga is writing a very long article
[23:11] <oparoz> Ah :)
[23:44] <Domi> Hello, does anyone use Python in a snap?


[02:21] <abentley> thumper, I can has review? https://code.edge.launchpad.net/~abentley/launchpad/append-distroseries/+merge/23728
[02:33] <wgrant> abentley: Appending just the distroseries name is very unusual.
[02:34] <wgrant> Was that was james_w suggested?
[02:34] <abentley> wgrant, it is.
[02:34] <wgrant> (normally something like ~series1 is used)
[02:35] <abentley> wgrant, okay, I may have gotten that bit wrong.
[02:38] <abentley> wgrant, thumper: changed and pushed.
[02:41] <wgrant> abentley: I'm not a fan of the s/distroseries/distroseries_name/, but from a packaging PoV that looks good. Thanks.
[02:42] <thumper> wgrant: please comment on the merge proposal :)
[02:43] <thumper> wgrant: in the future rather than just IRC
[02:43] <thumper> wgrant: otherwise we can miss it
[02:43] <abentley> wgrant, thanks for catching it.  I'd forgotten exactly what james_w suggested.
[02:43] <wgrant> thumper: True.  Will you get a chance to lok at my branch today?
[09:27] <noodles775> No problem if not, just trying to clear our kanban lane :)
[09:28] <henninge> oh, it's Tuesday ...
[09:28] <henninge> noodles775: sure, at some point ... ;)
[09:29] <noodles775> Great, thanks.
[10:53] <gmb> henninge, Good morning. Mind if I add https://code.edge.launchpad.net/~gmb/launchpad/reschedule-button-qafix-bug-558415/+merge/23698 to your queue?
[10:53] <henninge> gmb: ah, yes, but I am working on a critical bug atm
[10:54] <gmb> henninge, Okay. There's no rush; bac's reviewing this afternoon isn't he?
[10:54] <henninge> gmb: should be, yes
[10:54] <gmb> henninge, Okay. I'll put it on the queue but I'm not worried if you or bac don't get to it for a while.
[13:27] <adiroiban> danilos: when you have some time, can you take a look at the initial commit and have a pre-implementation chat for bug 146178?
[13:27] <mup> Bug #146178: Add links to latest full and delta language pack exported <ui> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/146178>
[13:39]  * bac looks at the queue.  girds himself for a long day of reviewing.
[13:43]  * noodles775 feels for bac :/
[13:43] <bac> don't mind me...just whining a bit
[14:32] <bac> noodles775: r=bac.  thanks.
[14:34] <noodles775> bac: Great, thanks.
[14:49] <danilos> adiroiban, I'm looking at it
[14:50] <adiroiban> danilos: I have created a preliminary MP for the branch ... if that helps
[14:59] <danilos> adiroiban, I've commented on the bug there, probably should have done it on MP as well :)
[15:00] <bac> danilos: are you doing the review?
[15:00] <adiroiban> danilos: ok. I will copy the commen. I have also commited a working implementation of IPerLanguagesWithStatistics https://code.edge.launchpad.net/~adiroiban/launchpad/512735/+merge/23759
[15:00] <danilos> bac, no, the preimp chat :)
[15:01] <danilos> adiroiban, that's the worst naming ever though :) I'll be happy to review that one
[15:01] <adiroiban> :)
[15:03] <jtv1> henninge, bac: can I put a small one on the queue?  https://code.launchpad.net/~jtv/launchpad/bug-567035/+merge/23742
[15:03] <adiroiban> danilos: for the language-packs links text, should we use UTC or user timezone?
[15:03] <henninge> bac, jtv1: I am sorry, but I won't be able to take any reviews today.
[15:04] <jtv1> henninge: still on that critical bug?
[15:04] <henninge> yup
[15:04] <jtv1> and that looks like a pretty full queue.
[15:04] <jtv1> So maybe I should wait until tomorrow, when I'm OCR.  :)
[15:04] <bac> henninge: ok
[15:04] <jtv> bac, need any help with that queue?
[15:05] <bac> jtv: i'm not going to say no
[15:05] <bac> jtv: but i have a long day ahead of me so it'll be ok
[15:06] <bac> adiroiban: so is your branch for bug 564852 read for review or are you still making changes?
[15:07] <jtv> bac: I'll see if I can steal a short one then.  :)
[15:07] <adiroiban> bac: is ready
[15:07] <bac> adiroiban: ok
[15:08] <adiroiban> bac: if a MP is not ready i'm setting its status to 'work in progress'
[15:08] <jtv> bac: I'm looking at the first one on the queue.
[15:08] <bac> adiroiban: right.  i was just concerned that it was ready for review but you and danilos seemed to be having an active discussion about the branch
[15:09] <bac> jtv: jdps?  if so, please remove it from the topic
[15:09] <adiroiban> bac: ah...my discussion with Danilo is about another branch
[15:09] <bac> adiroiban: ok.  thanks.
[15:11] <bac> adiroiban: +1 for using lp-send to create your MP.  much appreciated.
[15:12] <adiroiban> bac: I'm not using lp-send ... just the LP web ui. What are the advantages or using lp-send?
[15:12] <bac> adiroiban: it provides the skeleton you used in https://code.edge.launchpad.net/~adiroiban/launchpad/bug-564852/+merge/23612 and automatically includes the lint
[15:13] <bac> adiroiban: much easier than doing it by hand and ensures you don't just forget a section
[15:15] <adiroiban> bac: I see. Well I have a script that generates that output and copy it into the clipboard, but I will try to install lp-send and try to use it
[15:28] <bigjools> bac: hi, do you know Twisted?
[15:28] <bac> bigjools: i do not.
[15:29] <bigjools> bac: you're not going to like my branch then
[15:29] <bigjools> you can learn a bit if you want? :)
[15:29] <bac> bigjools: cool.  put it on the end of the queue...maybe i'll get to it, maybe i won't.  :)
[15:29] <bigjools> hah :)
[15:29] <bac> bigjools: i'd like to look at it.  if i have to punt i'm not shy
[15:30] <bigjools> bac: it's a complicated change in the buildd-manager
[15:30] <bigjools> bac: but I'm happy to explain over a call if you want
[15:31] <bac> bigjools: either way.  if you'd rather get a fellow soyuzian to look at it now i won't be offended
[15:31] <bigjools> bac: it's not partiocularly Soyuzy apart from the build farm aspect, which is not that soyuzy any more :)
[15:31] <bigjools> bac: I'm happy to wait
[15:31] <bigjools> thanks
[15:32] <bac> np
[15:34] <jpds> jtv: it was salgado who suggested the sendHeader() trick..
[15:34] <jtv> jpds: the trick itself is fine, just don't rely on a specific offset in the array!
[15:35] <jtv> jpds: you could also use an "in" check, but that's fragile because of the whitespace.
[15:35] <jtv> And since this is key/value pairs anyway...
[15:47] <bac> adiroiban: in language-views.txt there is the claim that Language.translators is monkey patched but I cannot find where that happens
[15:48] <adiroiban> there should be someting like "del Language.tranlators"
[15:48] <adiroiban> line 92
[15:54] <bac> adiroiban: ok, so that deletes the method.  i expected to see it replaced.
[15:59] <bac`> adiroiban: nm, i see it now
[15:59] <adiroiban> bac`: it is replaced at line 153
[15:59] <adiroiban> it is a property and I was not able to patch the object
[16:00] <adiroiban> as the property did not defined any "deleter"
[16:00] <bac> adiroiban: thanks
[16:19] <bac> hi mrevell
[16:19] <mrevell> hi bac
[16:20] <bac> mrevell: i'm looking at your MP and notice two things before starting the review.  one you are linked to a bug that is fix released, which is odd.  and second you're targeted to db-devel, not devel.  is that intended?
[16:22] <mrevell> bac, The bug -- I'll update, I forgot it was still in that state. I thought the fix had been released but when I looked at the tour it appeared that it hadn't.
[16:22] <mrevell> bac, As for db-devel, that is not intentional. Thank you for pointing that out.
[16:22] <bac> mrevell: i was burned by that last week...
[16:23] <bac> yet another reason i'm continually pimping 'bzr lp-send'
[16:24] <mrevell> bac, I haven't used lp-send yet, so I'll give that whirl.
[16:31] <bac> gmb: did you intend to target your MP to db-devel?
[16:32] <gmb> bac, Yes.
[16:32] <bac> ok
[16:32] <gmb> bac, Or... Maybe not, actually
[16:32] <gmb> Lemme check.
[16:32] <bac> gmb: i don't see why...
[16:34] <gmb> bac, Ah, yes. It's because there's a DBItem, BugWatchActivityStatuses, which has one more item on db-devel than on devel.
[16:34] <bac> oh, ok
[16:40] <bac> mrevell: did you intentionally omit mercurial from the list?
[16:40] <mrevell> bac, Yes, jelmer isn't happy for it to be mentioned publicly yet.
[16:41] <bac> ok
[16:41] <bac> shhh
[16:41] <mrevell> :)
[16:41] <mrevell> Well, let's say he doesn't want a song and dance yet.
[16:47] <bac> mrevell: is the tour to be written in en_US?
[16:48] <mrevell> bac, AFAIK the tour is written in en_GB.
[16:49] <bac> mrevell: alrighty.  i thought we'd decided the other for most things.  i don't care, just as long as it is consistent
[16:50] <mrevell> bac, The company styleguide requires en_GB these days, so over time I'll make sure everything I'm responsible for follows that. But I'm quite certain the tour was always en_GB.
[16:51] <bac> mrevell: oh, i didn't know about the styleguide specifying that.  goode to knouw.
[16:55] <mrevell> Yea verily
[17:02] <sidnei> bac, if im allowed to jump the queue, there's a trivial one-liner here: https://code.edge.launchpad.net/~sidnei/lazr-js/use-browser-console/+merge/23778
[17:03] <bac> sidnei: done
[17:03] <sidnei> bac, thanks!
[17:05] <bac> mrevell: your review is done.  remember if you use 'ec2 land' it's going to go directly to db-devel, which you don't want
[17:05] <mrevell> Thanks bac. I'll address the issues you've raised and then use pqm-submit, following a successful ec2 test.
[18:38] <bac> hi sinzui
[18:38] <sinzui> hi bac
[18:38] <bac> sinzui:  i'm curious why you chose 1 year for the period to not suggest packaging again.  i would've thought six months, matching the ubuntu release period, would make more sense.
[18:38]  * sinzui is on a call
[18:39] <bac> o
[18:39] <bac> k
[18:39] <bac> no rush
[18:43] <intellectronica> bac: can i add a branch to the queue?
[18:43] <bac> sure intellectronica
[18:43] <intellectronica> bac: great, thanks!
[19:02] <jml> could I please have a review for https://code.edge.launchpad.net/~jml/launchpad/better-subunit-attachment/+merge/23786
[19:03] <jml> bigjools, are you in the queue for https://code.edge.launchpad.net/~julian-edwards/launchpad/builder-reset-fail-bug-563353 ?
[19:03] <bigjools> jml: yes but I don't mind if you insert
[19:03] <jml> bigjools, actually, I was just going to review your branch if it's the one we were talking about earlier
[19:04] <jml> (and if LP ever loads the damn thing)
[19:04] <bigjools> jml: oh right!
[19:04] <bigjools> well, thanks :)
[19:17] <sinzui> bac: It takes more than 6 months for Ubuntu to diverge. Lucid +1 has the same packages as Lucid.
[19:18] <sinzui> bac: a year is a better time to ask again. I also think that the next time we ask, we should explain how the project can get packages in Ubuntu
[19:18] <bac> does lucid + 2 == lucid + 1 == lucid ?
[19:19] <sinzui> s+2 switches out main packages. s+3 adds new packages from the universe. beta (4-6) just add dependencies
[19:35] <jml> bigjools, done
[19:35] <bigjools> jml: cheers
[19:36] <jml> and with that, I'm off.
[19:39] <bigjools> will work on it in the morning, thanks
[20:31] <bac> intellectronica:  r=bac
[20:31] <intellectronica> bac: thanks!
[20:32] <bac> intellectronica:  i do hope your new algorithm is doing what you intend.
[20:33] <intellectronica> bac: yes, i hope too that this last batch of improvements will make heat more useful to more projects
[20:34] <bac> intellectronica:  previously you saw very little/almost no depreciation of the heat values?
[20:34] <bac> that's why it was not useful?
[20:35] <intellectronica> bac: more importantly, currently heat is not sensitive enough to activity. these new changes will make it respond to activity and inactivity in a much greater granularity, so new changes to a bug, or the lack of them, will reflect quickly in the bug's heat value
[20:36] <intellectronica> bac: our hope is that this will make heat more useful that now have a list of untouched but hot bugs at the top of the list
[20:37] <bac> intellectronica:  it'll be a nice feature when the kinks are worked out.  this should get you much closer.
[20:37] <intellectronica> bac: that's mostly a case of reality vs. ideology. intuitively, projects should work on their hot bugs and get them closed, but some don't.
[20:37] <intellectronica> indeed
[21:36] <EdwinGrubbs> bac: can you review this branch for me? https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-553384-deactivated-project-oops/+merge/23794
[21:41] <bac> EdwinGrubbs:  sure
[21:49] <sinzui> yeah
[22:19] <thumper> morning
[22:20] <thumper> EdwinGrubbs: are you going to UDS
[22:21] <EdwinGrubbs> thumper: bac was going for the Registry
[22:21] <thumper> EdwinGrubbs: was, or is?
[22:21] <EdwinGrubbs> thumper: is
[22:21] <sinzui> is
[22:22] <sinzui> bac: is pretty centered. He lives in the here and now. He is
[22:22] <sinzui> Though his nic implies he lives in the past, back never was, he just is
[22:22] <thumper> heh
[22:22] <sinzui> ah evo, how I hate you
[22:43] <bac> yes i is
[22:55] <abentley> mwhudson, when you need a break, could you review this? https://code.edge.launchpad.net/~abentley/launchpad/no-builds-recipe/+merge/23744
[22:57] <mwhudson> abentley: sure
[23:14] <bac> EdwinGrubbs:  i almost finished your branch but not quite.  i'll try to finish after dinner.
[23:15] <EdwinGrubbs> ok, thanks


[22:42] <Manav> hello teams
[22:43] <Manav> here i install ubuntu
[22:44] <Manav> on my laptop
[22:45] <Manav> so ubuntu install
[22:45] <Manav> but
[22:45] <Manav> boot
[22:45] <Manav> after display blank
[22:45] <Manav> or purpl color show
[22:46] <Manav> and mous point show
[22:46] <Manav> and proper desktop not
[22:46] <Manav> show
[22:47] <Manav> so plese guide me...
[22:47] <Na3iL> Manav, I would ask in #ubuntu 1st
[22:47] <Manav> yes
[22:49] <Manav> ok
[22:51] <Manav> #ubuntu 1st ???
[22:52] <Na3iL> You need to ask that question in this channel Manav #ubuntu
[22:53] <Na3iL> join it and ask there
[22:53] <Manav> ok
[22:53] <Manav> here i install ubuntu
[22:54] <Manav> on my laptop
[22:55] <Manav> so ubuntu install [04:15] <Manav> but [04:15] <Manav> boot [04:15] <Manav> after display blank [04:15] <Manav> or purpl color show [04:16] <Manav> and mous point show [04:16] <Manav> and proper desktop not [04:16] <Manav> show [04:17] <Manav> so plese guide me...
[22:58] <Manav> do you understand...???


[09:09] <Boscop> does the low latency kernel use more battery power?
[09:47] <zequence> Boscop: Probably, yes.
[09:47] <zequence> I haven't seen any numbers on that, so I'm just guessing.
[16:07] <berts> bonjour du canal
[16:40] <berts> bonne fin de jours @ chacun
[16:41] <cfhowlett> !fr | berts
[21:47] <magicguitarman> Evening everyone. Any free to help trying to get Pulseaudio to play nice with Jack? I am at my wits end.


[06:36] <orqcxha> hey folks its me having some trouble now, i got a dwm222 for mobile connection and it suddenly stopped working on jammy, i installed impish now and before it worked without any issue, now not even lsusb or mmcli lists it as a device, maybe it died in my backpack? how could i be sure?
[12:28] <orqcxha> holy cow
[12:28] <orqcxha> a piece of those silica gel beads got stuck in the adapter's usb port
[12:29] <orqcxha> nature is cruel


[03:25] <lotuspsychje> good morning to all
[03:26] <lotuspsychje> Bashing-om: very active yesterday, today also?
[03:27] <Bashing-om> lotuspsychje: steady .. no action however on my part to speak of .
[04:06] <neoncontrails> I'm a recent convert to Ubuntu from macOS. I'm curious if there's a plugin or module that supports Spotlight-like indexing of the filesystem for fast retrieval?
[04:10] <daftykins> https://www.omgubuntu.co.uk/2017/02/cerebro-is-a-spotlight-linux-equivalent
[04:11] <neoncontrails> daftykins: brilliant! This looks like exactly what I'm searching for
[04:12] <daftykins> google wins again
[04:22] <Bashing-om> Anddd .. that's a wrap for this un - \o
[06:17] <ducasse> good morning
[08:02]  * guiverc_d notes tomreyn deserves a truck full of cookies
[08:03] <ducasse> ...for not strangling that guy :)
[08:03] <tomreyn> :)
[08:04] <tomreyn> some day, i'll just burst forward with a huuuuge rooooar
[08:05] <tomreyn> not today, though, unless there are non virtual cookies
[08:05] <guiverc_d> :)
[08:14] <ducasse> !karma -200 jak2020
[08:14] <tomreyn> no karma here. also, karma requires intelligence, based on this output.
[08:16] <ducasse> was worth a shot ;)
[08:22] <tomreyn> say, do you think it's worth filing a bug report saying that esp partitions, if stored on applicable storage types, should be listed with 'discard' option in fstab?
[08:23] <tomreyn> s/partitions/file systems/
[08:23] <ducasse> probably, imo
[08:24] <tomreyn> just which package to file this against. it's probably something installer-ish
[08:25] <ducasse> try (s)ubiquity? the devs will correct it to the right package.
[08:26] <tomreyn> good point, thanks
[08:39] <EriC^^> sometimes i feel like a salesman in ubuntu
[08:39] <EriC^^> :D
[08:47] <tomreyn> hehehe
[08:48] <tomreyn> ducasse: does this look right? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1779443
[08:51] <ducasse> looks good to me
[08:51] <tomreyn> thanks for checking
[08:55] <ducasse> np
[09:13] <EriC^^> !info bikeshed
[10:24] <BluesKaj> Hiyas all
[13:46] <leftyfb> tomreyn: While I agree with you, I do think "hackers" is the appropriate term for most people in there. Considering we are hack on ubuntu prettymuch daily :)
[13:47] <tomreyn> indeed.
[13:50] <oerheks> I like hackers, and coffee, and xangua
[13:59] <xangua> Lol
[16:33] <oerheks> hmm gksu factoid should be editted
[16:33] <oerheks> !gksu
[18:07] <Nokaji> Hi - Does Ubuntu (v16.04) provide me with a free email account?
[18:15] <hggdh> Nokaji: no, it does not
[18:16] <Nokaji> okie, thanks hggdh - guess I'll have to part with some hard-earnt
[18:17] <hggdh> Nokaji: there are many free email providers out there...
[18:18] <Nokaji> Indeed, hggdh - I'm checking my options but paid gets me attachments included and the privacy and security of owning my own content
[18:19] <Nokaji> maybe even a cPanel thingy (not that I rememebr what one of those is)
[18:20] <hggdh> Nokaji: wait, you want host your own email server?
[18:21] <Nokaji> nope ... okie mebbe I don't need cPanel then
[18:21] <Nokaji> I just want MOARE functionality
[18:22] <Nokaji> bbl ... grubs up
[18:37] <lotuspsychje> good evening to all
[19:13] <lotuspsychje> just enabled starting up applications full list on ubuntu desktop with sudo sed -i 's/NoDisplay=true/NoDisplay=false/g' /etc/xdg/autostart/*.desktop
[19:14] <lotuspsychje> amazing what a gnome list starting up
[19:19] <lotuspsychje> https://imgur.com/a/PfuWxME
[20:50] <EriC^^> evening everyone
[20:51] <oerheks> hi Eric
[20:51] <EriC^^> hi oerheks
[20:58] <Bashing-om> EriC^^: \o
[20:59] <EriC^^> hey Bashing-om o/
[21:01] <Bashing-om> EriC^^: Slow day here for a Saturday .. Meant to get things done (ourside) but, do not have enough motivation :P
[21:05] <EriC^^> i see :D
[21:19] <hggdh> all my motivation to go outside melted.


[10:33] <tumbleweed> Laney: Think I've got a coherent complete upload history set. Ready to take it?
[14:30] <tumbleweed> meh, summer is here. It's still and hot :/
[14:30] <tumbleweed> highvoltage: getting well baked?
[14:46] <highvoltage> tumbleweed: staying mostly inside for the moment :)
[14:47] <tumbleweed> the curse of being bound to a computer...
[14:54] <highvoltage> I have to be careful, I get subnurnt really easy. (even in london in the winter once)
[15:03] <tumbleweed> heh
[20:31] <broder> ScottK, tumbleweed, micahg, Laney: i'm working on revamping the backports docs to try and do a better job of delineating "end-user" and "developer" targeted docs. what i have so far is at http://bit.ly/rNEOWc
[20:32] <broder> i'd like to split the docs between help.u.c (end-user) and wiki.u.c (dev)
[20:32] <broder> interested in your thoughts. also interested in how to avoid wall-of-text syndrome for the stuff i have drafted
[20:34] <ScottK> Avoiding wall of text isn't something I'm very good at.
[20:35] <ScottK> broder: Scanned it and I think it's good.  My only comment is to make clear that "developer" is anyone that wants to build/test a backport.
[20:35] <broder> i guess i'm hoping it will balance well as a reference against requestbackport's less verbose output
[20:36] <broder> ah, good catch
[20:36] <ScottK> It might even be better to call it tester instead of developer.  not sure.
[20:36] <broder> i don't think i actually use the word developer in the docs, just my title, which was more placeholder
[20:36] <ScottK> OK.
[20:37] <broder> but i should probably make it clear in the text
[20:37] <ScottK> There are really five states: Requester, Builder, Tester, Approver, User
[20:37] <ScottK> Approver is the only one that requires an ubuntu-dev type person.
[20:38] <ScottK> Builder is the only one that may need some technical/packaging knowledge.
[20:38]  * broder nods
[20:39] <ScottK> I think having information for requesting/building/testing as distinct things would be good as people can sometimes do one of those things and not the others.
[20:39] <ScottK> Going from Requesting -> Building/Testing would be a good bridge from h.u.c to w.u.c.
[20:40] <broder> i'm not sure we should encourage that, because you risk setting the expectation that requested backports will eventually get handled without any additional input from the requester, and that just doesn't happen in practice
[20:41] <ScottK> I think we should say that.
[20:41] <ScottK> You can file a request, but ...
[20:41] <broder> fiar
[20:41] <ScottK> There was a time when there were people who would test backports they didn't request.
[20:41] <ScottK> It might happen again if we get things ramped up a bit.
[20:42] <broder> yeah, and i still want to try to automate some of the testing, which will probably also help
[20:42] <broder> ok. i'll play with it some and see if i can tease those roles apart more
[20:42] <ScottK> Great
[21:22] <virusuy> hi everyone
[21:22] <virusuy> i'm trying to package a simple bash script
[21:23] <virusuy> and i need to modify $PATH
[21:23] <virusuy> where should i declare that in the package ?
[21:26] <tumbleweed> virusuy: that sounds wrong. Why do you need to modify $PATH?
[21:27] <CarlFK> once a .deb is on a stable repo (or maybe beta too) it won't be updated: a newer version may come out, but it will have a new file name.  right ?
[21:27] <tumbleweed> CarlFK: yes, but why are you asking?
[21:27] <virusuy> tumbleweed: but if i don't modify $PATH, how can i call the script without using the full path ?
[21:27] <CarlFK> trying to figure out if I should bother telling squid to expire debs
[21:29] <tumbleweed> virusuy: what are you trying to do?
[21:29] <CarlFK> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/squid-deb-proxy/oneiric/view/head:/squid-deb-proxy.conf#L52  refresh_pattern deb$   129600 100% 129600
[21:29] <CarlFK> 129600 min is 90 days.
[21:29] <CarlFK> made me wonder where 90 days came from
[21:30] <virusuy> tumbleweed: i have a bash script
[21:31] <tumbleweed> virusuy: so, put it in /usr/bin, so it'll be on people's paths
[21:31] <virusuy> tumbleweed: ok then
[21:51] <l3on> tumbleweed, around ? :)
[21:51] <l3on> I've solved this ftbfs:
[21:51] <l3on> https://launchpad.net/ubuntu/+source/clearsilver/0.10.5-1.2/+build/2930410
[21:51] <l3on> What's next step?... file a bug?
[21:53] <tumbleweed> l3on: yup, https://wiki.ubuntu.com/SponsorshipProcess
[21:53] <l3on> tumbleweed, well.. which info I have to report?
[21:53] <l3on> I mean.. I patched a source file
[21:53] <jtaylor> l3on: idealy file a bug vs upstream and debian
[21:54] <jtaylor> format-security issues are probably no reason to diverge from debian at this point
[21:54] <l3on> patch is:
[21:54] <l3on> -  cgi_error (cgi, s);
[21:54] <l3on> +  cgi_error (cgi, "%s", s);
[21:54] <l3on> directly to upstream ?
[21:55] <jtaylor> if upstream is affected yes
[21:55] <jtaylor> here an example bug I filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646350
[21:56] <jtaylor> In your case you would add the aptch too
[21:56] <l3on> ok jtaylor I'll do it :)
[21:57] <l3on> and in Ubuntu jtaylor I have to file a "merge bug" ?
[21:57] <jtaylor> ubuntu will get the fix automatically when debian fixes it
[21:58] <jtaylor> is there any info if this flag will stay enabled for precise?
[21:58] <l3on> I don't know how I can check it
[21:59] <l3on> I read this: http://en.wikipedia.org/wiki/Format_string_vulnerabilities
[21:59] <l3on> and applied patch
[21:59] <tumbleweed> jtaylor: I would assume it won't. Last I heard, we were waiting for the first rebuild to see how bad the fallout was
[21:59] <tumbleweed> but the rebuild won't happen until feature freeze
[21:59] <jtaylor> ok thx
[22:00] <jtaylor> l3on: in this case we will want to wait a bit before fixing the package in ubuntu
[22:00] <l3on> Ok, I'm going to file only bug debian.
[22:00] <jtaylor> carrying difference to debian is a maintenance overhead which might not be necessary in this case yet
[22:00] <l3on> Ok, I got it :)
[22:00] <jtaylor> debian does not enable that flag for the whole archive
[22:02] <jtaylor> but thanks for looking at it, your help will be much appreciated when ubuntu decides to keep the flag
[22:25] <l3on> ok bug filed in debian e upstream
[22:25] <l3on> debian 649322
[22:26] <tumbleweed> l3on: whoops, that doesn't have a subject
[22:26] <l3on> damn ...
[22:26] <jtaylor> no problam you can fix that easily
[22:26] <jtaylor> also you should add tags
[22:27] <jtaylor> it has a patch so the patch tag should be added, also these issues are tracked in so called usertags, "hardening-format-security hardening" for user<EMAIL_ADDRESS>[22:28] <l3on> I'm reading how to do it
[22:30] <jtaylor> l3on: mail this to http://paste.ubuntu.com/743693/<EMAIL_ADDRESS>[22:32] <tumbleweed> if you have working mail on your machine, there's a handy tool called bts in devscripts, for things like that
[22:32] <l3on> thank you jtaylor .. I was still reading retitle command :P
[22:33] <l3on> ah wow .. nice, I'm looking at manpage
[22:35] <jtaylor> you should also keep how to reproduce it in debian in the bug
[22:35] <jtaylor> in this case it is by enable the hardened build
[22:36] <l3on> The export+include ? :)
[22:36] <l3on> Ah ok, I'm making note about this ...
[22:36] <jtaylor> yes just helps to quickly test it
[22:37] <jtaylor> you quited the d-d-a mail it is in there, but adding cliffnotes is always nice
[22:38] <l3on> ok :)
[22:38] <jtaylor> don't forget to subscribe to the bug
[22:39] <jtaylor> the bts will not do that for you even when you file it
[22:40] <l3on> and in Ubuntu how people will know that there is a pending patch in Debian ?
[22:41] <jtaylor> during rebuilds bugs are filed in ubuntu
[22:41] <jtaylor> which you link and tag with the debian bugs
[22:41] <jtaylor> also when fixing issues you always look in debian if there is a fix already
[22:42] <l3on> Ok,thanks for this :)
[22:50] <l3on> Mmm.. I sent mail at control .. but nothing changes...
[22:50] <jtaylor> it takes a while
[22:51] <l3on> oki :)
[22:51] <jtaylor> the bts is not very fast, some parts are only updated every 15 minutes
[22:51] <l3on> this problem will be reported in the same way?
[22:51] <l3on> https://launchpadlibrarian.net/83733832/buildlog_ubuntu-precise-i386.libccscript3_1.1.7-1.1_FAILEDTOBUILD.txt.gz
[22:52] <jtaylor> yes looks like the same issue
[22:53] <jtaylor> before you file issues, check if it was already filed
[22:53] <jtaylor> I did a few of these a while back
[22:53] <jtaylor> also you should always check if debian is really affected
[22:54] <l3on> ok, I checked and it filed under debian 643417
[23:00] <l3on> another question :)
[23:00] <l3on> Why some builds seem to fail whet apply patch ?
[23:01] <l3on> and patch comes from debian
[23:01] <l3on> this for example:
[23:01] <l3on> https://launchpadlibrarian.net/85415333/buildlog_ubuntu-precise-i386.magics%2B%2B_2.12.9-5_FAILEDTOBUILD.txt.gz
[23:01] <jtaylor> that is a special case
[23:02] <jtaylor> the buildtool needs patching so it correctly handles the as-needed flag
[23:02] <jtaylor> because libtool sucks ;)
[23:02] <l3on> lol
[23:02] <jtaylor> so this package had a patch included in the it
[23:02] <jtaylor> but the underlying libtool was updated so the patch does not apply anymore
[23:02] <jtaylor> dh-autoreconf has gained the ability to do the patching now
[23:03] <jtaylor> which is more robust as it only needs one package to be up to date isntead of many
[23:03] <jtaylor> dh-autoreconf --as-needed
[23:09] <l3on> well.. I have to go.. thanks for all :)
[23:10] <l3on> bye


[03:35] <spreadsheet> hi
[03:36] <spreadsheet> do you guys remember someone named "X704" or "H264" who would go on here some times
[03:38] <spreadsheet> walter I believe
[03:39] <spreadsheet> wxl
[03:44] <spreadsheet> hm actually maybe not
[03:45] <spreadsheet> sorry not wxl
[03:47] <spreadsheet> tiwake
[05:02] <tiwake> X704, H264, tiwake, and WalterN are the same person