[01:17] <mup> PR snapd#5294 opened: Update SELinux Policy <Created by kevinanderson1> <https://github.com/snapcore/snapd/pull/5294>
[05:04] <mborzecki> morning
[05:15] <Son_Goku> mborzecki, night :)
[05:15]  * Son_Goku is nearly about to go to sleep
[05:15] <mborzecki> Son_Goku: an goodnight :)
[05:15] <mborzecki> s/an/and/
[05:57] <zyga> good morning
[05:57]  * zyga is somewhat tied after yesterday
[05:58] <zyga> it is good that there is some rain this morning
[06:01] <mborzecki> zyga: hey
[06:01] <zyga> hi :)
[06:02] <mborzecki> it rained a bit here, pity it was the only rain in 2 weeks or so
[06:30] <zyga> it still rains here, forecast says it will all day
[06:33] <zyga> ok, kids off to school
[06:33] <zyga> first (or I forget) social security payment
[06:33] <zyga> then work
[06:45] <mvo> pstolowski|afk: 5288 has (ironically) an econnreset test failure :)
[06:45] <mvo> pstolowski|afk: might be yet another interessting corner case
[06:52] <mborzecki> mvo: hi
[06:52] <mvo> hey mborzecki
[06:53] <zyga> ok, all taxes and payments done
[06:53] <zyga> now back to patches
[06:56] <mup> PR snapd#5295 opened: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5295>
[06:56] <mborzecki> trivial PR ^^
[07:01] <mvo> mborzecki: do we do this in debian/postrm already? or does it need to be done there as well
[07:01] <mborzecki> mvo: snap-mgmt --purge is used on fedora, opensuse, arch
[07:01] <mvo> mborzecki: I know, I mean, do we need this on debian/ubuntu as well?
[07:02] <mvo> mborzecki: or did we add it there already
[07:02] <mborzecki> mvo: aah, let me check :) i automatically assumed that it's correct there
[07:02] <mvo> mborzecki: maybe it is :)
[07:05] <mborzecki> mvo: well it does rm -rf /var/lib/snapd
[07:05] <mvo> mborzecki: heh, that should cover it
[07:06] <mvo> mborzecki: thanks for checking
[07:06] <mborzecki> mvo: np
[07:06] <mborzecki> mvo: btw. do you have any idea why the repair timer may be getting stopped before the test?
[07:08] <mvo> mborzecki: no idea, that is a bit mysterious
[07:08] <mborzecki> mvo: i've restarted 5285 but the log on friday showed that snapd.snap-repair.timer was being stopped just before the test
[07:08] <mborzecki> (kudos to systemd guys for actually collecting and showing this in systemctl show ..)
[07:10] <pstolowski> morning
[07:10] <mvo> mborzecki: I did a quick git grep over the tests dir but nothing jump out that would touch the repair service
[07:11] <mborzecki> pstolowski: hey
[08:17] <mup> PR snapd#5294 closed: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
[08:17] <mup> PR snapd#5295 closed: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5295>
[08:17] <mborzecki> zyga: thanks!
[08:23] <mborzecki> when mounting a snap fails, does the journal contain anything useful?
[08:23] <zyga> mborzecki: as much as the kernel provides
[08:24] <abeato> hi, how can I get more information when I see this sort of trace?: "handlers.go:372: Reported install problem for "core" as 680c957c-6d4a-11e8-a5bb-fa163e839e11 OOPSID"
[08:24] <mborzecki> zyga: i'm wondering if we should try and grab the output of journalctl -u <failed-unit>.mount at least
[08:24] <zyga> abeato: this goes to errors.ubuntu.com
[08:24] <zyga> mborzecki: mmmmm
[08:24] <zyga> mborzecki: in tests or in general
[08:25] <mborzecki> zyga: in tests
[08:25] <zyga> I think in tests we do (by extension of capturing lots of output)
[08:25] <zyga> in general would be interesting
[08:25] <mborzecki> zyga: in test's we don't, the tests run journalctl -u snapd .. which will not include the mount unit stuff
[08:26] <abeato> zyga, ok, but there is no other information that can be looked into in the system?
[08:26] <zyga> I think you can see more in "snap changes"
[08:26] <zyga> and "snap tasks NNN"
[08:27] <abeato> zyga, got it, thanks
[08:28] <Chipaca> abeato: the error report is going to contain things that are in the log (before it talks about the error report), or in the tasks log
[08:28] <Chipaca> or general system info
[08:28] <abeato> great
[08:28] <Chipaca> abeato: otherwise, https://errors.ubuntu.com/oops/680c957c-6d4a-11e8-a5bb-fa163e839e11
[08:28] <mborzecki> zyga: pff, i see it now, there's something logged :/ but not much
[08:28] <zyga> Chipaca: heyo :)
[08:29] <Chipaca> zyga: 'sup
[08:29] <Chipaca> abeato: in particular: ERROR [--root / enable snap.network-manager.networkmanager.service] failed with exit status 1: Created symlink from /etc/systemd/system/multi-user.target.wants/snap.network-manager.networkmanager.service to /etc/systemd/system/snap.network-manager.networkmanager.service.
[08:29] <Chipaca> abeato: which is not particularly helpful :-)
[08:29] <Chipaca> abeato: no doubt you have better debug info locally
[08:29] <abeato> Chipaca, right, I just saw that in "snap change 1"
[08:30] <abeato> weird thing, then it retried and the second time it worked :/
[08:30] <Chipaca> also, whoa, 96 bogoMIPS
[08:30] <Chipaca> speed fiend
[08:31] <abeato> hehe, yes, it is a pretty slow processor
[08:31] <Chipaca> mborzecki: what're you trying to do?
[08:31] <zyga> 96 tail movements in turtle graphics
[08:31] <mborzecki> Chipaca: was wondering if there's something more to collect when we fail to mount a snap
[08:31] <Chipaca> zyga: tail *recursive*?
[08:32] <zyga> Chipaca: ouch ;)
[08:35] <Chipaca> mborzecki: AFAIK no
[08:36] <Chipaca> mborzecki: systemd doesn't even report the errno of the mount call
[08:36] <zyga> because there is none
[08:36] <zyga> I mean
[08:36] <mborzecki> Chipaca: right, that's the protocol part
[08:36] <zyga> not one, it uses libmount
[08:36] <zyga> lots of more complexity and features handled
[08:38] <Chipaca> ¯\_(ツ)_/¯
[08:39] <Chipaca> if you need to do foo, and you do it by using libfoo, that does not get you off the hook of handling foo errors properly
[08:39] <mborzecki> errors go to /dev/foo
[08:39] <Chipaca> I mean, you're responsible for the libraries you use as well as the code you write
[08:40] <Chipaca> mborzecki: only in 4.16.17 compiled on even days of the month though
[08:40] <zyga> mborzecki: /dev/foo?
[08:41] <mborzecki> zyga: s/f/p/ if you wish :)
[08:41] <zyga> ah
[08:41] <zyga> well
[08:41] <zyga> you are actually close ;)
[08:41] <zyga> there is a new kernel interface for mount errors
[08:41] <zyga> and it is a special device
[08:41]  * zyga looks for the patch
[08:41] <mborzecki> no wai
[08:41] <mborzecki> zyga: link?
[08:41] <Chipaca> mborzecki: too late
[08:42] <Chipaca> mborzecki: EVERYTHING IS ~~SPIDERS~~ block devices
[08:45] <mborzecki> btw. on friday i got my car back from the shop, the damage cost ~1800eur to fix, fortunately i'm not paying :P
[08:46] <zyga> I cannot find the patch
[08:46]  * zyga looks through bookmarks
[08:47] <Chipaca> mborzecki: whoa
[09:16] <pedronis> hi
[09:17] <zyga> hey :)
[09:19] <mup> PR snapd#5296 opened: daemon: paging is not a thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5296>
[09:25] <Chipaca> mvo: if I had a feature I needed to be in 2.34, what's the latest it can land on master?
[09:25] <Chipaca> (without causing undue work to other people i mean)
[09:28] <Chipaca> also, that pr ^ is the shortest I've done in ages :-)
[09:30] <Chipaca> popey: you should snap OpenNFSv3 just to confuse people
[09:30] <Chipaca> needs some care in writing the description so you don't really know if you're getting a filesystem or a racing game
[09:31] <popey> hah
[09:31] <Chipaca> 'from scratch rewrite of NFS with a focus on performance and interoperability', say
[09:51] <zyga> mborzecki: I think your PR is bigger
[09:51] <mup> PR snapd#5297 opened: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[09:52] <mborzecki> pedronis: just to be sure i'm not missing something, InstanceKey in snap action == InstanceKey in current snap in context right?
[09:54] <mvo> Chipaca: for 2.34 would be good to land this week or early next week
[09:54] <Chipaca> mvo: ok
[09:54] <Chipaca> mvo: thanks
[10:03] <mup> PR snapd#5296 closed: daemon: paging is not a thing <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5296>
[10:14] <pedronis> mborzecki: yes, for refreshes
[10:14] <mborzecki> pedronis: thx
[10:16] <mborzecki> pedronis: i'm close to finishing with the changes in store, once i push the patch, i'll send you a link for a quick review in case i did something overly stupid there
[10:42]  * zyga -> coffee
[11:08] <mup> PR snapd#5298 opened: store, image: have 'snap download' use v2/refresh action=download <Created by chipaca> <https://github.com/snapcore/snapd/pull/5298>
[11:09] <Chipaca> pedronis: ^ info inch-pebble
[11:12] <pedronis> Chipaca: thx, I'll look after the break
[11:12] <Chipaca> pedronis: somewhat trepidatious as it almost seemed to easy :-)
[11:12] <Chipaca> too*
[11:13] <Chipaca> in other news: you'll be shocked to hear snapd doesn't work in WSL
[11:14] <Chipaca> (there's a bug about it an' all)
[11:19] <zyga> Chipaca: is it snapd or general code around it that breaks?
[11:19] <Chipaca> zyga: WSL doesn't support daemons
[11:20] <Chipaca> zyga: WSL doesn't support systemd
[11:20] <zyga> daemons are supported
[11:20] <zyga> but systemd is not
[11:20] <Chipaca> zyga: ah, release notes I read said No, but that was a while ago
[11:20] <zyga> yeah, it is recent
[11:26] <mborzecki> well, snaps under wsl, on windows, that would be fun
[11:28] <zyga> mborzecki: well, once they support mount namespaces we could
[11:28] <zyga> drop all sandboxing
[11:28] <zyga> and handle mounting snaps with something else (unpack?)
[11:29] <Chipaca> zyga: fuse :-)
[11:29] <Chipaca> (does it even)
[11:29] <Chipaca> i mean, windows does have the idea of mounting stuff
[11:29] <zyga> Chipaca: WSL does some special things to windows filesystem
[11:29] <zyga> so not easily
[11:31] <Chipaca> zyga: if we really wanted to pursue this we might be able to get in touch with people at ms
[11:37] <zyga> mborzecki: hey look https://github.com/snapcore/snapd/pull/5297 is green now
[11:37] <zyga> I feel I should swap this review for your uber rename one
[11:37] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[11:38] <zyga> this needs a 2nd review https://github.com/snapcore/snapd/pull/5283 and is pretty short and simple
[11:38] <mup> PR #5283: snapstate: get rid of needsMaybeCore <Created by mvo5> <https://github.com/snapcore/snapd/pull/5283>
[11:39] <zyga> https://github.com/snapcore/snapd/pull/5230 needs a 2nd review and is otherwise ready
[11:40] <mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
[11:49]  * cachio afk
[11:55] <zyga> jdstrand: hello, can you please enqueue some time to look at this https://github.com/snapcore/snapd/pull/5170#issuecomment-396216845
[11:55] <mup> PR #5170: interfaces/builtin: add adb-support interface <Blocked> <Decaying> <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[11:59] <pedronis> Chipaca: I think we might have an ubuntu-image test using the fakestore, so it probably needs to learn about download
[12:00] <Chipaca> pedronis: only one spread error, and it seems unrelated to my change
[12:00] <zyga> mvo: can you please weigh in on https://github.com/snapcore/snapd/pull/4996
[12:00] <mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
[12:00] <zyga> is that ready for landing or is more stuff needed
[12:01] <pedronis> Chipaca: ok, I'm probably misremembering then
[12:01] <zyga> mvo: can you please add a reference to the apt bug on https://github.com/snapcore/snapd/pull/5122
[12:01] <mup> PR #5122: snap: add support for `snap advise-snap --from-apt` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5122>
[12:01] <Chipaca> pedronis: maybe fakestore implemented enough of v2 refresh for it to work :-)
[12:03] <Chipaca> pedronis: tests/main/snap-download talks to the real stores tho
[12:03] <pedronis> Chipaca: possibly,   no I remembered right:  /main/prepare-image-grub/task.yaml  seems to use the fakestore, maybe a double check that it works for semi-reasonable reasons would be good
[12:03] <Chipaca> ah, prepare-image
[12:04] <pedronis> ah, it uses the fakestore only for assertions
[12:04] <pedronis> Chipaca: anyway it probably is a good idea to make sure the fakestore could handle download
[12:04] <pedronis> given we are in the middle of introducing it
[12:06] <pedronis> Chipaca: but yes, seems it should just work, afaict there's just a Action == "refresh" in all the relevant cocde
[12:07] <Chipaca> pedronis: we could make it barf on unknown actions, or sth
[12:07] <Chipaca> seems fine as is though
[12:07] <mvo> zyga: re 4996> does it need a gustavo review to ensure names (e.g. ifaceRepokey) are agreed upon?
[12:08] <zyga> mvo: the name was changed since earlier reviews (AFAIR by pedronis) so .. not sure
[12:09] <pedronis> it was changed by mborzecki picking one of couple of suggestions
[12:09] <pedronis> I made I think
[12:10]  * Chipaca ~> lunch
[12:11] <mborzecki> right, i took over 4996 for a while and addressed all (most) comments
[12:12] <zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/4416
[12:12] <mup> PR #4416: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
[12:12] <zyga> you reviewed it before
[12:12] <zyga> and it's the only PR from 2017:D
[12:14] <pedronis> mvo: the choices were snap-interfaces or snap-profiles or snap-interface-profiles
[12:14] <mvo> pedronis: its fine with me, just want to ensure gustavo is happy about the naming as well
[12:14] <mvo> (as he usually cares a lot about this)
[12:15] <pedronis> mvo: then you need to wait, but it's been like this since forever
[12:15]  * zyga -> lunch
[12:17] <mvo> zyga: I looked at 4416 - it looks like your question ("how its supposed to be used") is not answered
[12:17] <pedronis> mvo: it's going to be used when we reload profiles
[12:18] <mvo> pedronis: yeah, sorry, I was replying to a different PR (the performance measure one)
[12:18] <pedronis> ah
[12:18] <mvo> pedronis: I will +1 the other one, one sec
[12:18] <pedronis> I saw the 4**6  I didn't read the middle number
[12:18] <pedronis> s
[12:18] <pedronis> it seems
[12:18] <mvo> pedronis: :) no worries
[12:18] <mvo> pedronis: just shows we still have too many open
[12:19] <pedronis> that is true
[12:21] <mvo> pedronis: looks like 5221 just needs this tiny tweak that pawel suggests and then it can go in as well(?)
[12:21] <pedronis> mvo: yes, I will do the change today
[12:21] <pedronis> I'm also working on actually using this
[12:22] <mvo> pedronis: nice
[12:25] <mvo> mborzecki: how did you create test-snapd-appstreamid? via a snapcraft file?
[12:27] <mvo> mborzecki: aha, nevermind, found it
[12:27] <mborzecki> mvo: yup ;) glad that you found it
[12:28] <mvo> mborzecki: I make it arch: all, it breaks on non amd64 tests right now:)
[12:28] <mborzecki> right, iirc i've only published amd64 snap
[12:29] <mvo> mborzecki: yeah, no worries, I take care of it
[12:29] <mborzecki> mvo: ok, great
[12:35] <mup> PR snapd#5299 opened: tests: publish test-snapd-appstreamid for any architecture <Created by mvo5> <https://github.com/snapcore/snapd/pull/5299>
[12:36] <pedronis> Chipaca: I did a pass over the download one
[12:39] <mvo> pedronis: if you have a spare cycle I would love to get an opinion on 5276
[12:44] <pedronis> mvo: it looks good, but I think we want like for core,base,kernel,gadget to make sure  snapd  is done first (even if seed.yaml order isn't what we expect)
[12:44] <pedronis> I added a comment there too
[12:48] <mup> PR snapd#5300 opened: tests: skip security-dev-input-event-denied on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/5300>
[13:35] <Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/unisex-optima-cougar-mountain-bike./1302194477
[13:35] <Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/gents-bike-ladies-bike/1302156061
[13:35] <mborzecki> Chipaca: those look legit
[13:36] <Chipaca> mborzecki: told you
[13:36] <Chipaca> not sure why but bikes have very low resale value in uk
[13:38] <mborzecki> Chipaca: hmm weird, it's like cars then, isn't it?
[13:38] <popey> also, gumtree -> stolen goods
[13:38] <zyga> my connection broke at around when cachio was talking so I just returned home then
[13:39] <Chipaca> popey: not always though
[13:39] <popey> Sure.
[13:39] <Chipaca> you do need a sketchometer though
[13:39] <Chipaca> sketchy-o-meter
[13:40] <zyga> hmmm
[13:40] <zyga> guys, does anyone have a theory why there are all the test failures recently?
[13:40] <zyga> any specific change that triggered it
[13:41] <Chipaca> zyga: I blame multicasts on broken packets
[13:41]  * Chipaca puts away his BOFH excuse generator
[13:42] <zyga> for instance, what broke
[13:42] <zyga> + systemctl is-active snapd.snap-repair.timer
[13:42] <zyga> inactive
[13:43] <zyga> mborzecki: can you please look at v
[13:43] <zyga> https://github.com/snapcore/snapd/pull/5297
[13:43] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[13:44] <Chipaca> mvo: #5294 confirmed wrt cla
[13:45] <mup> PR #5294: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
[13:46] <jdstrand> roadmr: hi! would you mind flipping on requash enforcement?
[13:46] <roadmr> jdstrand: sure! flipping now
[13:48] <jdstrand> roadmr: thanks!
[13:48] <roadmr> jdstrand: where "now" is now. I'ts just been flipped to ON
[13:48] <mvo> Chipaca: confirmed that the CLA is singed or not signed?
[13:49] <roadmr> jdstrand: also we'll get r1089 rolled out today \o/
[13:49] <jdstrand> roadmr: thanks! :)
[13:52] <jdstrand> roadmr: unrelated to that, fyi, this seems stuck: https://dashboard.snapcraft.io/snaps/inoxision-webclient/revisions/115/
[13:52] <jdstrand> roadmr: as does https://dashboard.snapcraft.io/snaps/falkon/revisions/45/
[13:53] <roadmr> jdstrand: let me unwedge them
[13:53] <jdstrand> thanks
[13:54] <roadmr> jdstrand: interesting, inoxision-webclient says "Task 47c953d4-cb72-4618-9df6-5de67275e931 failed. ". I'll unwedge for now but will have a closer look at that task id later
[13:54] <jdstrand> yeah, thanks
[13:54] <roadmr> jdstrand: falkon is ready to roll, inoxision-webclient should be in a couple of mins (it's a large snap)
[13:55] <mborzecki> off to pick up the kids
[13:55] <mborzecki> zyga: i'll take a look when i get back
[13:55] <zyga> thanks
[13:55] <zyga> jdstrand: hey :)
[13:56] <zyga> mvo: signed
[13:58] <zyga> jdstrand: you may find https://github.com/snapcore/snapd/pull/5297 interesting :)
[13:58] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[13:58] <mvo> zyga: cool, thanks
[14:01] <jdstrand> hey zyga :)
[14:08] <mup> PR snapd#4700 closed: interfaces: add the dvb interface <Created by ThyMYthOS> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4700>
[14:19] <Chipaca> mvo: signed
[14:19] <mup> PR snapd#5300 closed: tests: skip security-dev-input-event-denied on s390x/arm64 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5300>
[14:28] <popey> Wimpress: ping!
[14:28] <Wimpress> popey: Pong?
[14:28] <Chipaca> pedronis: do you remember offhand how to get the thing 'snap download' expects for auth?
[14:29] <pedronis> Chipaca: in which sense?
[14:29] <Chipaca> pedronis: UBUNTU_STORE_AUTH_DATA_FILENAME=~/.snap/auth.json doesn't work
[14:30] <pedronis> that doesn't work, because we don't store the store macaroons anymore there
[14:30] <pedronis> only the local one
[14:30] <Chipaca> pedronis: we didn't have a 'snap grab-the-auth' command?
[14:30] <pedronis> Chipaca: we don't yet
[14:30] <pedronis> Chipaca: but snapcraft export-login works
[14:30] <pedronis> one sec
[14:30] <Chipaca> ah there we go :-)
[14:32] <Chipaca> hm, looks like my snapcraft macaroni has expired or sth
[14:32] <pedronis> Chipaca: just give it  --acls  package_access
[14:33] <Chipaca> huh, export-login asks you to log in again?
[14:34] <pedronis> yes
[14:34] <pedronis> anyway as I said you need different acls than your usual login
[14:34] <pedronis> sorry, I mean, than the usual snapcraft macaroon
[14:35] <Chipaca> right
[14:36] <Chipaca> pedronis: wrt checking channel & revision, any reason not to let them through and have the store error?
[14:36] <Chipaca> is there a path in which we set both?
[14:37] <Chipaca> if we let them through, we get: error: cannot find snap "http": cannot download snap "http": Both revision and channel are present in the request for this Snap. It should be one or the other exclusively.
[14:37] <pedronis> Chipaca: you an do snap download --channel=foo --revision=#  no?
[14:37] <Chipaca> (and yes I'll drop the 'cannot find' thing)
[14:37] <pedronis> are you saying for this it's good enough?
[14:37] <Chipaca> pedronis: I'm saying it's weird to check it at this level
[14:37] <Chipaca> pedronis: better to check it in cmd_download
[14:37] <pedronis> ah, ok
[14:38] <Chipaca> and at this level just let it through
[14:38] <Chipaca> IOW, I'd drop the one in snapstate
[14:38] <Chipaca> rather than adding it to image
[14:38] <pedronis> please don't drop the one in snapstate
[14:38] <pedronis> if you do, you need to add checks in a lot of places
[14:38] <Chipaca> aw! you're no fun anymore
[14:39] <Chipaca> :-D
[14:39] <pedronis> not a lot, but enough that is hard to keep track
[14:39] <Chipaca> pedronis: my 2nd favourite thing would be to move it into store itself
[14:40] <Chipaca> unless your point is that we'd have to have that code in fakestore as well?
[14:40] <pedronis> ?
[14:40] <Chipaca> pedronis: ok to move it from snapstate to store?
[14:40] <pedronis> fakestore is a server
[14:40] <pedronis> Chipaca: yes, but remember this applies only to install and download
[14:41] <Chipaca> yes. what's the name of the thing that mocks Store though.
[14:41] <pedronis> ah, the other fake store
[14:41] <pedronis> but yes
[14:41] <pedronis> Chipaca: there's an argument to  do it both places tbh
[14:42] <pedronis> belt and suspenders
[14:42] <pedronis> as they say
[14:51] <mup> PR snapd#5301 opened: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[14:52] <mvo> mborzecki: there is an nmap netcat?
[14:53] <mvo> mborzecki: woah, I had no idea, fun
[15:04] <mborzecki> Son_Goku: fedora netcat comes from nmap right? cc mvo
[15:04] <Son_Goku> yes
[15:04] <mborzecki> Son_Goku: ack, thx
[15:04] <Son_Goku> redhat / fedora netcat is nmap's variant
[15:41] <ondra> kyrofa ping
[15:44] <zyga> mvo: FYI, https://github.com/snapcore/snapd/pull/5301#pullrequestreview-127623720
[15:44] <mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[15:47] <zyga> pstolowski: I need a 2nd review on https://github.com/snapcore/snapd/pull/5278
[15:47] <mup> PR #5278: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
[15:48] <zyga> it's a PR with one new simple function
[15:48] <kyrofa> Hey ondra, what's up?
[15:49] <ondra> kyrofa hey
[15:49] <ondra> kyrofa I've got problem with snapcraft on one machine
[15:49] <mvo> zyga: thank you, just replied and updated the test. thanks for noticing. I can look into doing this on apparmor init as well if you feel this is cleaner
[15:49] <ondra> kyrofa it gets stacked in pull stage on 99%
[15:50] <zyga> mvo: I had a look and I don't know how to do it easily
[15:50] <zyga> mvo: as we'd need the revno for core
[15:50] <zyga> mvo: in apparmor.Backend.Initialize
[15:50] <zyga> mvo: let me look at your patch first
[15:50] <kyrofa> ondra, every time? Have you run in debug mode?
[15:50] <mvo> zyga: aha, right
[15:51] <zyga> mvo: ah, debian 9
[15:51] <zyga> mvo: if this passes on Sid I'm happy then
[15:51] <zyga> mvo: the rest can be re-factored separately
[15:51] <ondra> kyrofa every time and on different projects now
[15:51] <zyga> mvo: any idea why it didn't fail before?
[15:52] <ondra> kyrofa I have wiped ~/.cache/snapcraft but some result
[15:52] <kyrofa> ondra, no errors, though? Is this pulling build- or stage-packages?
[15:52] <ondra> kyrofa I think stage packages
[15:52] <mvo> zyga: its a new test, I added it to check that things really work as we expect them to work
[15:53] <ondra> kyrofa https://paste.ubuntu.com/p/k3rfJT6RmG/
[15:53] <ondra> kyrofa and then it will sit here forever
[15:53] <zyga> mvo: https://github.com/snapcore/snapd/pull/5301/commits/e6eb26c46718747e7e328dba1db24958f45cda7f#r194454976
[15:53] <mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[15:53] <zyga> I see
[15:53] <kyrofa> ondra, huh, that's just fetching indexes
[15:54] <kyrofa> Er, indices
[15:54] <zyga> please make this modification and if it passes I'm +1
[15:54] <zyga> having no 2nd phase tasks would be a major simplification
[15:54] <pstolowski> zyga: looking
[15:54] <mvo> zyga: ok, will do tomorrow (or feel free to just tweak yourself). I need to go and play hockey now :)
[15:54]  * mvo waves
[15:54] <zyga> :)
[15:54] <ondra> kyrofa running apt-get update passes fine
[15:55] <ondra> kyrofa I do have multiple architectures on that machine though
[15:56] <kyrofa> ondra, hmm, that could make things a little odd. Try running `snapcraft pull --enable-geoip` as well
[15:56] <ondra> kyrofa so it was working fine, can't really say when it broke, not apparent reason there
[15:56] <ondra> kyrofa loads of errors with that option
[15:57] <ondra> kyrofa and indeed errors are related to arm64 and armhf
[15:59] <ondra> kyrofa interestingly I have another machine with similar setup, same errors there, but build still works
[16:00] <pstolowski> zyga: 1 comment
[16:01] <ondra> kyrofa OK so it looks like snapcraft is trying to be smarter and it's not actually following /etc/apt/sources.list
[16:01] <kyrofa> ondra, when you ctrl+c is while it's hung there, do you get a traceback?
[16:01] <ondra> kyrofa there I have correct setup for each arch
[16:03] <ondra> kyrofa https://paste.ubuntu.com/p/Mb9zBYFZY5/
[16:05] <zyga> pstolowski: thank you, looking now
[16:06] <zyga> pstolowski: replied now
[16:10] <Luke> how does snapcraft decide what to include in the install/stage after the build phase? Is it just any file or change that is applied outside of the build dir?
[16:11] <kyrofa> ondra, huh, it really is just the apt api sitting there
[16:13] <kyrofa> ondra, I'm really not sure what's happening there
[16:13] <kyrofa> ondra, what happens if you remove the multiarch stuff?
[16:14] <ondra> kyrofa then I won't be able to cross build :)
[16:14] <kyrofa> ondra, haha, you can't right now anyway ;)
[16:14] <mup> PR snapd#5278 closed: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5278>
[16:14] <ondra> kyrofa lol
[16:14] <kyrofa> I'm just throwing darts at the wall, trying to figure out what's causing it to get caught up
[16:15] <ondra> kyrofa fair point :P
[16:15] <zyga> thank you pawel!
[16:15] <ondra> kyrofa testing it now
[16:15] <ondra> kyrofa so I removed arches with dpkg, I left them in sources, which seems to be ignored somehow anyway
[16:16] <ondra> and that is same result, stacked at 99%
[16:17] <kyrofa> sergiusens, any idea what would cause the apt API to do that ^ ?
[16:17] <ondra> kyrofa and 'snapcraft pull --enable-geoip' passes without error
[16:17] <kyrofa> ondra, wait, that finishes the pull step?
[16:17] <ondra> kyrofa ha and now that continues to pulling other parts
[16:17] <kyrofa> Innnteresting
[16:18] <kyrofa> It sounds like one of the repos being used it having issues, then
[16:20] <ondra> kyrofa so calling snapcraft will hang, calling ''snapcraft pull --enable-geoip' will complete pull stage
[16:24] <kyrofa> ondra, yeah, by default it just uses archive.ubuntu.com, but with geoip will use your country prefix
[16:25] <ondra> kyrofa I'm running it in the cloud, so god knows what that actually is
[16:26] <kyrofa> Oh, fun
[16:26] <sergiusens> ondra: please post on the forum
[16:30] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:30] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:31] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:31] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:36] <zyga> jdstrand: do you think we could fast-track https://github.com/snapcore/snapd/pull/5297
[16:36] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[16:36] <zyga> and land it?
[16:37] <jdstrand> zyga: I'll move it to the top of the list, but the others need to wait. I owe morphis a review
[16:38] <zyga> ack
[16:38] <zyga> thank you
[16:38] <zyga> it's a large and very boring review
[16:38] <zyga> so I just want to land it to help me out and not conflict
[16:56] <ondra> sergiusens https://forum.snapcraft.io/t/snapcraft-getting-stacked-at-99-during-pull-stage/5876
[17:04]  * zyga explores a descriptor leak that makes no sense
[17:14] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[17:14] <mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[17:14] <mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[17:16] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[17:16] <mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[17:16] <mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[17:22] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[17:22] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[17:23] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[17:23] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[17:25]  * zyga found the bug but first walk
[17:50] <kyrofa> zyga, if I have an `environment:` keyword in the root of my YAML, that applies to all apps and hooks, right?
[18:05] <zyga> kyrofa: let me check
[18:05] <zyga> kyrofa: I'd say yes
[18:05] <zyga> but I'll look
[18:07] <zyga> kyrofa: ha
[18:07] <zyga> so it looks buggy
[18:08] <zyga> kyrofa: ah, sorry
[18:08] <zyga> it looks good
[18:08] <zyga> so yes,
[18:08] <kyrofa> zyga, alright, something odd is happening on my hook... still investigating
[18:08] <zyga> we take the global (snap-global) environment
[18:08] <kyrofa> Thanks for the quick check!
[18:08] <zyga> then take the per app environment
[18:08] <zyga> oh, hook you say?
[18:09] <zyga> kyrofa: curious
[18:09] <zyga> kyrofa: hooks don't take environment at all
[18:10] <zyga> kyrofa: yes, hooks just take the snap-level environment keys
[18:10] <zyga> and with that I'm off for another round of bicycling
[18:13] <roadmr> yeay zyga
[19:02]  * cachio afk
[20:22] <mup> PR snapd#5302 opened: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302>
[20:23] <kyrofa> zyga, that's ^ the problem I was hitting
[21:31] <zyga> kyrofa: I saw that just now. I will review it first thing tomorrow
[21:38] <kyrofa> Thanks zyga
[21:39] <zyga> Thank you x10 for the patch!
[22:50] <wililupy> question: what is '/var/lib/snapd/hostfs' used for?
[22:53] <zyga> wililupy: hey
[22:54] <wililupy> hi zyga!
[22:54] <zyga> wililupy: it is used at runtime to host the / of the host system
[22:54] <zyga> technically when a snap application runs it constructs some temporary directories and then makes moves all of the root filesystem (/) to /var/lib/snapd/hostfs, replacing the / with something else
[22:54] <zyga> then hostfs is used as a "view" to the rest of the filesystem
[22:56] <wililupy> zyga: thats what I thought. I have a weird apparmor error trying to confine my snap and the path.
[22:57] <wililupy> I created an interface with the rule: /var/lib/snapd/hostfs/{,*} rw,
[22:57] <zyga> what is the denial you are getting, exactly?
[22:58] <wililupy> Jun 11 22:52:36 dpdk-test kernel: [ 1408.757203] audit: type=1400 audit(1528757556.659:90): apparmor="DENIED" operation="open" profile="snap.dpdk-wililupy.testpmd" name="/var/lib/snapd/hostfs/mnt/huge/" pid=2546 comm="testpmd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[22:58] <zyga> Right
[22:58] <zyga> I think what we want instead is to mirror /mnt from the host
[22:59] <zyga> and add it to removable media or a new interface
[22:59] <zyga> there's a thread about that on the forum
[22:59] <wililupy> and mnt/huge is not there
[22:59] <zyga> I will make a patch for this tomorrow
[22:59] <zyga> (it's 1AM for me)
[23:00] <wililupy> zyga: no problem. Its for a hugepages interface I am working on (https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go)
[23:01] <zyga> I can quickly say that https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go#L35 is probably not going to fly
[23:01] <zyga> as this gives full write access to the host
[23:01] <zyga> why /mnt/huge? isn't there a standardised place for huge pages elsewhere?
[23:02] <wililupy> zyga: I'm following their testing documentation and that is the path they use in their example.
[23:02] <zyga> can you refer to that?
[23:03] <wililupy> zyga: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
[23:04] <zyga> mount | grep huge
[23:04] <zyga> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
[23:05] <zyga> unless dpkd requires that specific path
[23:06] <zyga> wililupy: could you open a forum thread about this effort? it will be easier to sync this way than on IRC
[23:06] <wililupy> Sure thing. Get some sleep.
[23:56] <mup> PR snapd#5297 closed: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5297>


[01:16]  * BUGabundo off to bed
[03:45] <rob2> Hello. I just triaged bug #394430. However I don't seem to have write access to the Importance property. Is this normal? The wiki indicates that Importance should be set when the bug is confirmed.
[03:45] <ubot4> Launchpad bug 394430 in x11-apps "xclock -twentyfour option ignored" [Undecided,Confirmed] https://launchpad.net/bugs/394430
[04:01] <nellery> rob2: you need to be in bugcontrol to set importance
[04:01] <nellery> see https://wiki.ubuntu.com/UbuntuBugControl
[04:52] <rob2> Thanks nellery, I did end up reading that and understand the requirements for joining that group.
[20:02] <BUGabundo> boas tardes
[20:05] <charlie-tca> Good evening, BUGabundo
[20:06] <BUGabundo> hey charl
[20:06] <BUGabundo> *
[20:06] <BUGabundo> hey charlie-tca
[20:06] <BUGabundo> ahh took me a while :)
[20:07] <charlie-tca> We all get there  ;-)
[20:10] <BUGabundo> its hard to balance a 13" laptop in two nees :)
[20:17] <charlie-tca> Even harder to only use 1, though ;-)
[20:18] <BUGabundo> not if you have square nees eheh
[20:19] <charlie-tca> Good point
[21:11] <kamusin> How can I mark some report that has reported an error for a package that was installed manually and is not in main repository (package is skype)
[21:12] <charlie-tca> Report it directly to the application developers
[21:12] <charlie-tca> !info skype
[21:12] <ubot4> charlie-tca: Package skype does not exist in jaunty
[21:13] <kamusin> exists if you have medibuntu sources
[21:13] <kamusin> but is not the case
[21:14] <BUGabundo> if the package was instaled from medibuntu repos
[21:14] <charlie-tca> Yes, you should report the bugs as indicated:
[21:14] <charlie-tca> Please report any bug to our bug tracker instead:
[21:14] <charlie-tca>  https://bugs.launchpad.net/medibuntu/+bugs
[21:14] <kamusin> because this user download from website
[21:14] <BUGabundo> then it's a bug for the medibuntu LP BTS accouny
[21:14] <BUGabundo> not ubuntu one
[21:14] <charlie-tca> Tells me that in Synaptic Package Manager
[21:14] <BUGabundo> charlie-tca: yeas
[21:14] <charlie-tca> Bugs in launchpad will be invalid
[21:15] <BUGabundo> no need to invalidate... just MOVE it
[21:15] <BUGabundo> that makes it send less noise to ubuntu subscrivers
[21:15] <BUGabundo> kamusin: what website? skype oficial? then its not *our* bug
[21:15] <charlie-tca> Oh, yeah, that too
[21:16] <kamusin> was download from skype website
[21:16]  * charlie-tca slaps head; got to remember to save work instead of creating noise
[21:16] <BUGabundo> kamusin: mark it as invalid and explain it to the user
[21:17] <kamusin> right
[21:38] <Zylstra555> Hello, I would like to report a bug, and quite frankly I am just too lazy to register to post it somewhere...
[21:39] <Zylstra555> In the Ubuntu 9.04 Add/Remove Application, the package: "Filezilla" can not be added, it claims that the program is incompatible with the system (i386). I manually downloaded and ran it, and it works fine.
[21:41] <BUGabundo> Zylstra555: please visit #ubuntu channel, and try to find another user having the same prob, and that want to report it
[21:41] <BUGabundo> thanks
[21:42] <BUGabundo> Zylstra555: plus having and Launchpad account my be useful for you next time, to allow you to report more bugs, or keep track of already submitted bugs
[21:42] <BUGabundo> and it also entitles you to a Ubuntu One cloud account ;)
[21:43] <cabrey> Zylstra555, I get the same thing
[21:43] <Zylstra555> BUGabundo: Personally, I'd rather just not have another account somewhere else... Why did Ubuntu switch to Launchpad? (I've never used the old bug system, which I think was the forum, right? Or Launchpad)
[21:43] <BUGabundo> Zylstra555: launchpad has been here since I joined
[21:44] <Zylstra555> BUGabundo: Hmm... I still don't recall.
[21:44] <BUGabundo> its the de facto plaform for us to track the project
[21:45] <Zylstra555> I'm surprised that FileZilla isnt working, and probably hasnt been in a long time.
[21:45] <cabrey> Zylstra555, I had it installed before
[21:45] <cabrey> on 9.04
[21:45] <Zylstra555> It is one of the best FTP clients out there, I tried nearly every single other FTP client in the Ubuntu Repositories... none of them even compared.
[21:46] <Zylstra555> cabrey: I downloaded the executable and just ran it from there, how distressing! (I rely on Synaptics far too much)
[21:46] <Zylstra555> BUGabundo: Well, if you think its worthwhile getting an account on Launchpad, I shall do so. I really want to see this fixed.
[21:46] <cabrey> it's probably a packaging error
[21:46] <BUGabundo> filezilla works for me, in karmic
[21:47] <cabrey> aptitude download filezilla d/l's the actual deb
[21:47] <BUGabundo> I remember having some trouble with filezilla during jaunty devel cycle. and then it got fixed
[21:49] <Zylstra555> I wonder, will Linux be around for the next 100 years?
[21:49] <cabrey> nothing wrong with the control file as far i see
[21:49] <BUGabundo> hope so
[21:50] <Zylstra555> ...how do I actually report the bug in Launchpad?
[21:50] <cabrey> ok it's definitely a synaptic issue
[21:50] <cabrey> i can install the deb manually via gdebi/dpkg
[21:51] <cabrey> and it starts up fine...
[21:52] <Zylstra555> cabrey: It works fine as well.
[21:52] <cabrey> i'm talking about the deb coming down from the ubuntu repos
[21:52] <BUGabundo> Zylstra555: best way: $ ubuntu-bug filezilla
[21:52] <Zylstra555> JFTP, "FTP", KFTP, Kasablaca, all of those clients... none of them were able to successfully transfer 54GB of data. Granted, FIleZilla hasnt finished yet, but its off to a good start.
[21:52] <cabrey> it's not a filezilla bug tho
[21:53] <cabrey> i would say file it under synaptic
[21:53] <BUGabundo> cabrey: Zylstra555 please try : $ sudo aptitude update && sudo aptitude install filezilla and pastebin any errors
[21:53] <BUGabundo> cabrey: synaptic is just an APT GUI
[21:54] <cabrey> yea i know
[21:54] <BUGabundo> the bug is most prob on apt or pdkg
[21:54] <BUGabundo> but MVO is not here
[21:54] <cabrey> not dpkg, because i just used dpkg
[21:54] <BUGabundo> try aptitude
[21:54] <BUGabundo> purge it, clearn your cache, and try again
[21:55] <cabrey> gotta be synaptic, just tried aptitude
[21:56] <Zylstra555> BUGabundo: It seems to be working under Aptitude
[21:56] <BUGabundo> did you clean your cache?
[21:56] <cabrey> & purged
[21:57] <cabrey> Zylstra555, if you post the lp bug url here I'll try to confirm it (if I can)
[21:58] <BUGabundo> Zylstra555: best way to report a bug: $ ubuntu-bug filezilla
[21:59] <Zylstra555> BUGabundo: Thats what I did :)
[22:00] <BUGabundo> great
[22:03]  * BUGabundo ok I'm getting my self an ice cream. back in a few minutes
[22:05] <Zylstra555> BUGabundo: Cabrey:https://bugs.launchpad.net/ubuntu/+source/filezilla/+bug/398267
[22:06] <ubot4> Launchpad bug 398267 in filezilla "FileZilla cano not be added by Add/Remove Applications program" [Undecided,New]
[22:06] <Zylstra555> * (Space Typo) BUGabundo: Cabrey: https://bugs.launchpad.net/ubuntu/+source/filezilla/+bug/398267
[22:07] <BUGabundo> typo
[22:07] <BUGabundo> cano not
[22:07] <Zylstra555> I can confirm it myself, it appears
[22:08] <cabrey> i just did :)
[22:08] <charlie-tca> Zylstra555: Please don't confirm your own bugs, wait for someone else to
[22:08] <BUGabundo> yep. don't do it!
[22:09] <cabrey> i did
[22:09] <cabrey> i'm going to upload a screenshot of the dialog
[22:09] <Zylstra555> charlie-tca: I know, I was just saying... (I just thought it was kind of an odd thing, allowing someone to confirm their own bugs..)
[22:09] <cabrey> Zylstra555, http://launchpadlibrarian.net/28919861/screenshot1.png
[22:10] <cabrey> is that what you're getting?
[22:10] <charlie-tca> It is allowed, but will only create extra messages since someone else will then unconfirm it and someone else will have to confirm it
[22:11] <charlie-tca> Launchpad doesn't have brains to say you reported this, and you should not confirm it. Devs are allowed to confirm some kinds of bugs when they report them.
[22:11] <cabrey> launchpad is self aware
[22:12] <charlie-tca> It does get smarter every day ;-)
[22:12] <cabrey> that can only lead to one thing.
[22:12] <cabrey> free pie.
[22:22] <Zylstra555> well, Ubuntu is being a pain to me right now... a file transfer crashed from Gnome, or Nautalis, or whatever, and now it won't do any other file transfers until it thinks it has transfered the first files... what a paradox.
[23:39] <kklimonda> from LP: "The certificate expired on 07/12/2009 12:37 AM."  ;)
[23:48] <charlie-tca> kklimonda: for launchpad?
[23:48] <BUGabundo> kklimonda: check your PC clock
[23:48] <BUGabundo> last time someone said that HERE he had a bad CMOS date
[23:48] <charlie-tca> I don't get that notice
[23:48]  * charlie-tca remembers that now
[23:49] <kklimonda> BUGabundo: well, everything else is fine :)
[23:49] <BUGabundo> kklimonda: $ date
[23:49] <charlie-tca> kklimonda: is it already the 12th there?
[23:49] <kklimonda> yeah
[23:49] <kklimonda> it's for edge LP
[23:50] <kklimonda> and from what I see e.l.n cert has just expired
[23:50] <kklimonda> the one from stable LP is valid for another year
[23:51] <charlie-tca> Might tell them on #launchpad
[23:51] <BUGabundo> edge here says 2010
[23:51] <kklimonda> good idea
[23:51] <kklimonda> hmm..
[23:51] <Nafallo> except #launchpad isn't the ones handling the certs...
[23:51] <kklimonda> BUGabundo: interesting
[23:52] <BUGabundo> its *.launchpad.net
[23:52] <BUGabundo> Nafallo: so who is?
[23:52] <kklimonda> BUGabundo: I got a *.edge.launchpad.net
[23:52] <Nafallo> BUGabundo: the sysadmins
[23:52] <BUGabundo> no one works on sundays at canonical :)
[23:52] <BUGabundo> kklimonda: interesting
[23:52] <BUGabundo> :)
[23:53] <BUGabundo> Nafallo: do you know one we can poke to check on this ?
[23:54] <Nafallo> BUGabundo: nope, but it's flagged in nagios for when they start on Monday :-)
[23:54] <kklimonda> :)
[23:54] <kklimonda> damn, we are gonna get dozens of bug reports till then ;)
[23:55] <BUGabundo> Nafallo: that will be a bit late :)