[04:52] <scoopex> the rocketchat snap package is missing two rules (https://github.com/RocketChat/Rocket.Chat/issues/14562). how can i add them?
[04:52] <scoopex> sorry, i mean apparmor rules
[04:56] <jamesh> scoopex: rebuilding the snap with the network-observe plug would probably do the trick.
[04:57] <jamesh> that exposes a lot more though.
[05:23] <mborzecki> morning
[06:23] <zyga> Hello
[06:24] <mborzecki> zyga: hey
[06:31] <zyga> How are you?
[06:31] <zyga> We had first rain in weeks
[06:31] <zyga> It is still raining now
[06:42] <zyga> Hey mvo
[06:42] <mvo> hey zyga
[06:46] <mborzecki> mvo: hey
[06:47] <mvo> hey mborzecki ! thanks for your decompile of the bpf in the performance thread
[06:49] <mborzecki> mvo: sure, do you have the link to the image you used with volatility?
[06:50] <mborzecki> mvo: i'm inclined to try rebuilding a couple of versions of libseccomp, check the bpf they generate and how it impacts the performance
[06:50] <mvo> mborzecki: i used http://amnesia.gtisc.gatech.edu/~moyix/ds_fuzz_hidden_proc.img.bz2
[06:50] <mvo> mborzecki: it was more or less a random choice in their example image section
[06:51] <mvo> (its one of the smaller ones though)
[06:51] <mborzecki> mvo: hah, i could probably write a small benchmark but we could equally well use volatility :)
[06:55] <mvo> mborzecki: yeah, volatility is nice as it exhibits the issue easily
[07:05] <zyga> Wimpress: hello
[07:05] <zyga> Wimpress: please ping me when you are working, we need to sync
[07:07] <zyga> https://github.com/snapcore/snapd/pull/7062 is green and needs a 2nd review (re-enabling test)
[07:11]  * zyga is a little sleepy after uberlong day
[07:11] <zyga> on the upside the new bed is ok
[07:14] <zyga> pstolowski|afk: neat stuff
[07:14] <pstolowski> mornings, hey zyga
[07:15] <zyga> hey :)
[07:15] <zyga> good morning
[07:15] <zyga> pstolowski: it was raining all night
[07:15] <zyga> every bit of soil and plant around here needed that
[07:18] <pstolowski> zyga: it has been rainy and cloudy here as well for over a week.. and it's actually a little chilly
[07:19] <zyga> pstolowski: I kind of miss that now
[07:27] <zyga> brb
[07:36] <zyga> coffee and back to work soon
[07:36] <zyga> pstolowski: I'll reivew your PR first
[07:36] <pstolowski> ty
[07:41] <zyga> pstolowski: thanks!
[07:42] <zyga> coffee-in-hand, review mode :-)
[07:42] <pstolowski> yw
[07:43] <pedronis> jamesh: hi,  could you work to try to land 6959 ?
[07:52] <mborzecki> pstolowski: little chilly, 16C right now here :/
[07:57] <zyga> mborzecki: wow
[07:57] <zyga> pstolowski: can you help me understand the code in the PR please
[07:57] <zyga> pstolowski: what sets skip-setup-profiles?, I cannot see it
[07:57] <zyga> EDIT: d'oh
[07:57] <zyga> sorry, typo in search
[07:57] <zyga> I should finish that coffee, I see it now
[07:58] <pedronis> pstolowski: I moved some cards related to the interface connection work, doesn't seem you have a card in doing about it though
[08:03] <pstolowski> zyga: good
[08:04] <pstolowski> pedronis: indeed, thanks
[08:10] <zyga> pstolowski: I'd like to run a scenario by you,
[08:14] <zyga> pstolowski: (still assembling the scenario, I'll get back to you)
[08:14] <mborzecki> mvo: i'm experimenting a bit with versions of libseccomp, so the impact is marginal
[08:15] <mborzecki> mvo: i've checked 2.4.1, 2.3.3, latest master and the binary tree branch
[08:18] <mvo> mborzecki: I wonder if we could do a lookup table or if bpf is too limited
[08:18] <mborzecki> mvo: with ebpf yes, cbpf is limited
[08:18] <mborzecki> mvo: sadly seccomp is cbpf
[08:21] <mborzecki> mvo: if you're interested, this is the profile with 2.4.1 https://paste.ubuntu.com/p/wRTDmq39Sw/ and this one is with binary tree patches https://paste.ubuntu.com/p/Q9VYyhchRR/
[08:40] <Wimpress> zyga: Morning
[08:41] <zyga> Wimpress: hello
[09:06] <pstolowski> pedronis: i'm removing ...== "snapd" checks; wondering what to do about client-side filtering and special-casing around connections/interfaces
[09:16] <pedronis> pstolowski: we are mostly interested about places that were using .Type for anything else
[09:17] <pedronis> pstolowski: client side, not sure, we had a lot of back and forth there
[09:17] <pedronis> pstolowski: what's the special casing around connections/interfaces ?
[09:18] <pstolowski> pedronis: it's mostly about system nickname afaiu
[09:18] <pedronis> pstolowski: that goes through the mapper, no?
[09:18] <pedronis> the mapper decision could use the type now
[09:20] <pstolowski> pedronis: maybe, but that may not solve everything, e.g. cmd_connections uses different format for system snaps, i.e. it omits snap name for system snaps, and uses just the name match
[09:21] <pedronis> pstolowski: if we do things correctly, selectInterfaceMapper  can use the type
[09:21] <pedronis> pstolowski: maybe I wasn't clear,  the issue is not that we compare with the name in general
[09:21] <pedronis> the issue is places that were checking the type of snapInfo for most things
[09:21] <pedronis> but the  name for snapd
[09:22] <pedronis> but I'm probably still confused what the problem is
[09:23] <pedronis> pstolowski: are you talking about places that use SystemSnapName ?
[09:23] <pstolowski> pedronis: isn't the goal to support snapd snap whatever its name might be in the future?
[09:24] <pedronis> pstolowski: not really
[09:24] <pedronis> never said that
[09:24] <zyga> NOTE: the client side checks were there because some parts of the API did not return enough information AFAIK
[09:24] <pedronis> pstolowski: the goal is to make decision sensitive based on the type
[09:24] <pstolowski> pedronis: allright. wrong assumption on my side then. there is no issue then.
[09:27] <mborzecki> mvo: added a note about compiled bpf with 2.4.1 and the binary tree branch: https://forum.snapcraft.io/t/concerns-about-performance/12194/8
[09:27] <pedronis> pstolowski: you are talking about isSystemSnap in cmd_connections ?
[09:28] <pstolowski> pedronis: yes. and there is some special-casing in cmd_interfaces as well. although they're both irrelevant in the light of what you just clarified
[09:29] <pedronis> we might want to do something about that, but is not a priority
[09:32] <Chipaca> pedronis: what should I do wrt the code for snaps with no health?
[09:32] <Chipaca> in info
[09:33] <Chipaca> pedronis: I don't have a strong opinion on this :)
[09:33] <Chipaca> having a code seems more uniform, but this being snap and not snapd it's purely cosmetic
[09:38]  * Chipaca proposes snapd-health-is-a-state-of-complete-physical-mental-and-social-well-being-and-not-merely-the-absence-of-disease-or-infirmity
[09:41] <mvo> mborzecki: thank you
[09:43] <pedronis> Chipaca: no code please, it's the unknown unknown case
[09:45] <pedronis> Chipaca: also, code are optional, we should embrace that, not give the impression they aren't
[09:46] <pedronis> Chipaca: if you think the code really adds value, then we should always set in the api, and not leave the field empty
[09:46] <pedronis> there
[09:46] <pedronis> but I don't think it's worth it/makes a lot of sense
[09:48] <Chipaca> agreed then, no code in this case
[09:53] <Chipaca> break time!
[09:53]  * Chipaca dances
[09:53] <Chipaca> https://www.youtube.com/watch?v=otCpCn0l4Wo obvs
[09:58]  * zyga -> breakfast
[10:30] <zyga> back
[10:37] <zyga> pstolowski: I sent a partial review earlier; I cannot poke any holes in it
[10:40] <pstolowski> zyga: ty, i saw you comment. i think it's no different (in terms of risk) to anything else we do; fwtw if we made any error in that logic, we would end up with less persmissions, not more (initial setup-profiles is always done before auto-connect and link-snap). we just need to be careful as always
[10:52] <mborzecki> pstolowski: left some comments under https://github.com/snapcore/snapd/pull/7081
[10:54] <pstolowski> thanks
[11:31] <zyga> Walk
[11:39] <zyga> re
[12:21] <zyga> oho
[12:21] <zyga> splits
[12:22] <zyga> mborzecki: one last python patch https://github.com/snapcore/snapd/pull/7082
[12:31]  * zyga switches to reviews
[12:56] <jdstrand> mborzecki: r cbpf> for some definition of sadly, ebpf would give us a lot of grief due to spectre (and its mitigations)
[12:57] <jdstrand> (cc mvo) ^
[12:58] <mborzecki> jdstrand: as in https://seclists.org/oss-sec/2019/q1/106 ?
[12:59] <jdstrand> mborzecki: if we're looking to ease the pain of the lookup, trying to push oracle's patch forward is likely the way forward. we could do experimental builds and determine if it is good enough, then vendor libseccomp with that patch if it seemed ok
[13:02] <jdstrand> mborzecki: yes. some are disabling ebpf entirely. everyone else says only root can use it (if not running under seccomp already iirc)
[13:07] <jdstrand> mborzecki: I see you post that bintree didn't help. we could try to tweak libseccomp to put common syscalls like openat sooner.
[13:08] <jdstrand> mborzecki: and then send that upstream
[13:08] <mborzecki> jdstrand: yeah, the cost seems to be better on average, but lower number syscall seem to fare worse
[13:09] <jdstrand> and vendor it in the meantime. before vendoring or sending upstream, we'd need to run through the tests I wrote for the daemon user though...
[13:09] <jdstrand> mborzecki: I suspect if you posted your findings to the bintree one, people would try to come up with a compromise approach
[13:09] <mborzecki> jdstrand: actually that is interesting whether we should aim for all syscalls be similarly impacted by seccomp filter, rather than favoring some and penalizing others
[13:10] <jdstrand> mborzecki: since the goal is spead up when it actually slowed down
[13:10] <mborzecki> jdstrand: right, but if you do say, recvmsg/sendmsg a lot you'd see gains :)
[13:12] <jdstrand> mborzecki: well, seccomp is always going to have a measurable impact ime. what we can do to soften that... it seems plausible to put massively used ones earlier (like recvmsg/sendmsg). one would think that openat would be at the end though-- read/write/lseek at the beginning since you tend do that more than opens.
[13:13] <jdstrand> mborzecki: which means that we're always going to be slow in some pathological cases
[13:14] <jdstrand> mborzecki: if you are right about python compiling modules, shouldn't it be shipping pyc files?
[13:20] <jdstrand> mborzecki: the fact that we do a lookup at all, for volatility, it seems difficult to imagine doing better than bintree. I mean, read is very high in the list with only 6 syscalls before it, and lseek only 14. they are highly prioritized already
[13:22] <zyga> jdstrand: we can  LD_PRELOAD and translate all the syscalls  to open + mmap + caching  (don't close and reopen)
[13:23] <zyga> jdstrand: we can  perhaps do some tricks with multiple profiles, hand written,  that use bitmasks to quickly ACK numbers that are high up the call  frequency and then offset the cost for the NACK syscalls, maybe some sort of bloom filter approach crafted out of multiple filters that are all attached together
[13:24] <mborzecki> jdstrand: sorry for delayed replies, we're in the standup currently
[13:24] <mborzecki> jdstrand: mvo posted some info about -m compileall, but I did not apply it locall
[13:26] <jdstrand> mborzecki: it is unclear to me the frequency of the syscalls for volatility. the table tells my with <2.4, read has 0 syscalls before RET and with 2.4, 6, but how often is read called? (we know read will be high, but perhaps there is some frequently used syscall that could reasonably moved up the list)
[13:27] <jdstrand> mborzecki: mvo mentioned lseek and mmap...
[13:28] <mborzecki> jdstrand: let me grab a summary from strace
[13:29] <mborzecki> jdstrand: http://paste.ubuntu.com/p/F8PSHcscDg/
[13:31] <jdstrand> zyga: I'm not clear on your LD_PRELOAD proposal. you are saying you want to modify program behavior to sidestep the issue?
[13:31] <mborzecki> jdstrand: so read, lseek, mmap, munmap, fstat should already be handled rather early
[13:31] <mborzecki> jdstrand: openat is probably an artifact of snap-confine and perhaps python module compilation (?)
[13:32] <jdstrand> mborzecki: how easy it for you to put lseek first in the list with 2.4 and rerun?
[13:32] <mvo> mborzecki: just to double check - you also see the problem go away once you add @unrestricted into the .src file and compile that, right?
[13:32] <mborzecki> mvo: yes, @unrestricted is ~14s vs 20 with seccomp set up
[13:34] <mborzecki> jdstrand: where's the list?
[13:36] <jdstrand> mvo: it's always been known there is overhead with syscall filtering. a map would sure be nice here... lseek is already prioritized and towards the top of the list. we knew pathological cases would be problematic (eg, opening lots of files over and over, etc)
[13:36] <jdstrand> mborzecki: well, yes, then I guess that is already putting it towards 'not easy' (I don't know otoh)
[13:38] <jdstrand> mvo: but volatility is executing lseek nearly a million times...
[13:38] <mvo> jdstrand: yeah, I think this forum post hit exactly this pathological case
[13:38] <mborzecki> jdstrand: i'll look into how libseccomp generates bpf, i see there's some syscall sorting happening early on so that's probably the right spot :)
[13:38] <mvo> jdstrand: its fine, if we can't do anything we can't do anything :) I was mostly trying to understand the details
[13:40] <jdstrand> mborzecki: it looks like there is a priority field looking at gen_bpf.h
[13:40] <jdstrand> err gen_bpf.c
[13:41] <jdstrand> mborzecki: iirc, upstream said there was more that could be done in this area, separate from bintree
[13:42] <zyga> I think that given the number of system calls it is silly a seccomp program cannot have a small array that has “yes, no, compute” action. Vast majority of times a simple lookup is sufficient
[13:43] <zyga> Maybe we need to invest in a kernel patch
[13:43] <mvo> zyga: I was wondering the same - it seems the bpf machine is very limited here (maciej mentioned this earlier here)
[13:44] <jdstrand> mborzecki: db.c talks about the priority field, and talks about 'user hints'
[13:44] <jdstrand> mborzecki: which is... interesting...
[13:44] <zyga> Ebpf seems to have everything we want though. Maps arrays jumps. It is just out of reach :-(
[13:45] <zyga> But even regular bot we could use some tricks with bit mask
[13:45] <zyga> a/bot/bpf
[13:46] <mvo> yeah, was wondering that too
[13:47] <jdstrand> zyga: once we have the daemon user tests in place, perhaps we could consider using ebpf on systems that have it available. I mean, snap-confine is running as root. it will have CAP_SYS_ADMIN for using bpf()...
[13:48] <jdstrand> zyga: it wouldn't be something we would want to rush and we'd have to really justify it in my mind, cause the entire industry is using libseccomp. if we go out on our own and get it wrong, that would be, let's shall we say, less than ideal
[13:49] <jdstrand> (cc mvo) ^
[13:49] <mborzecki> jdstrand: hm seccomp_syscall_priority()
[13:49] <zyga> jdstrand: but seccomp does not do eBPF, or does it?
[13:49] <mborzecki> jdstrand: let's see if i can tweak the code to call it and make it prioritize lseek
[13:50] <jdstrand> I'd much prefer to see mborzecki's findings as feedback in the bintree pr
[13:50] <jdstrand> zyga: no, it would need to be a new LSM
[13:51] <jdstrand> zyga: there are some patches for seccomp to use ebpf. that would definitely need to be evaluated :)
[13:51] <zyga> Understood
[13:53] <jdstrand> anyway, I suspect bintree is going to help lift everything, even if some pathological cases remain
[13:56] <jdstrand> mborzecki: yes, look at that, a C api and everything. huh. so, assuming that can make things better, it is theoretically possible for snapd to expose some knobs to tune the filter
[13:58] <jdstrand> mborzecki: eg, seccomp_syscall_priority(ctx, SCMP_SYS(lseek), 220); seccomp_syscall_priority(ctx, SCMP_SYS(read), 219);
[13:59] <jdstrand> mborzecki: with knobs, we could perhaps make pathological cases not so bad...
[14:00]  * jdstrand is a little concerned what that might do to the added tests for snap_daemon since that whole thing was so brittle prior to 2.4 (and its defaults)
[14:03] <jdstrand> mborzecki: I of course made up 220 and 219. I don't know what the current prio is for either. maybe for your 'quick' test, 255 and 254 is best since volatility is dominated by those two
[14:06] <mborzecki> jdstrand: heh, https://paste.ubuntu.com/p/CPZ6cGkt8q/ shaved off ~1s
[14:08] <mborzecki> jdstrand: fwiw scmp_bpf_sim tells me it's fewer instructions now for those syscalls
[14:10] <jdstrand> mborzecki: hmm, only one second. that suggests the act of filtering at all causes a fairly significant slowdown (at least when calling a function a million times), with the ordering being an additional factor
[14:10] <mborzecki> jdstrand: fwiw i could possibly come up with a trace to measure how much it takes
[14:13] <mborzecki> jdstrand: had to fix the unrestricted time in the forum note, idk why i had 14s instead of 18s
[14:14] <mborzecki> jdstrand: so fiddling with bintree branch or the regular branch, we can gain a bit, but not much tbh
[14:14] <jdstrand> mborzecki: it might be interestinng for completeness since we were talking about sort order so much and that a map would help (which these finding suggest perhaps not)
[14:14] <jdstrand> mborzecki: re gain> right
[14:17] <mborzecki> jdstrand: a map of what? or an eBPF map?
[14:18] <mborzecki> jdstrand: fwiw http://paste.ubuntu.com/p/DHV5tfChq6/ disassembly output with prioritized syscalls
[14:20] <zyga> that has to be optimizable
[14:23] <jdstrand> mborzecki: I was saying that your run might suggest that the filtering code in the kernel is what is slow. if lseek is at the top of the list then sort order is essentially taken out of the equation for that syscall. so a(n ebpf) map isn't going to help that
[14:23] <jdstrand> mborzecki: perhaps the kernel could be improved to do caching of a previous lookup... that is likely memory intensive though
[14:25] <jdstrand> mborzecki: however, your 18s:20.5s vs 14s:20.5 is a big deal. I think we can live with that overhead for the foreseaable future. we can pull back bintree in the fullness of time and lift everyone a bit. with higher priority items out of the way, we could consider adding seccomp_syscall_priority() to the mix
[14:27] <mborzecki> jdstrand: w8, that's 18s with @unrestricted, vs 20.<closer to 0> with bintree or priorized vs 20.<closer to 1> with 2.4.1
[14:27] <jdstrand> mborzecki: even better
[14:27] <jdstrand> mborzecki: point is, the delta between unrestricted and restricted is not great
[14:28] <mborzecki> jdstrand: right, the penalty is there and it's measurable
[14:29] <jdstrand> it is there, it is measurable. we knew that (we just didn't measure it). my point is that a 10% slowdown for a pathological case is not terrible
[14:29] <mborzecki> jdstrand: also, we probably need a better benchmark
[14:30] <jdstrand> and that perhaps in the future, we can get that to 5% with seccomp_syscall_priority() if that bubbles up to a roadmap item
[14:30] <jdstrand> mborzecki: re benchmark> absolutely
[14:39] <zyga> mborzecki: some of the rain got here :)
[14:41] <zyga> even storm
[14:41] <zyga> finally colder though
[14:53] <zyga> lots of thunder and rain here, if I don't respond it may that my network got knocked outu
[14:53] <zyga> *out
[15:00] <jdstrand> mborzecki: fyi, I see you are responding-- I just responded again with my thoughts (perhaps you want to consider/agree/refute them in your response)
[15:02] <pedronis> mborzecki: did another pass on 6890, still not super clear why the calls to checkpointPrefix and rollbackPrefix are not more symmetric
[15:14] <mborzecki> pedronis: hm must have missed that in your previous review, will take a look
[15:15] <mborzecki> jdstrand: left a note with results from more runs, so only conclusions at this point are: @unrestricted has no overhead and we need a better benchmark
[15:17] <jdstrand> mborzecki: thanks! those are concrete conclusions. I think an important additional conclusion is that sort order isn't everything and there is overhead in mediating it at all. that is useful and can guide us going forward
[15:18] <jdstrand> mborzecki: I also think that there is reasonable hope that bintree will help non-pathological cases, but that needs measuring
[15:21] <jdstrand> mborzecki: it is interesting that bintree/prioritized is slower with the averages than straight 2.4.1
[15:21]  * jdstrand updates his math
[15:31] <jdstrand> mborzecki: I wonder if it makes sense for when bintree is available, to make it chooseable. ie, add an api call to opt into/out of bintree... it seems that the upstream patch doesn't make this tunable. it only looks at MIN_SYSCALLS_TO_USE_BINTREE
[15:33] <jdstrand> mborzecki: fyi, our default template uses 368 syscalls today
[16:08] <pstolowski> degville: hey, thanks for debug timings doc tweaks! one typo there: "snapd stores up to 100 measurements with the oldest dropped to for new measurements"; did you mean "to make room for.." ?
[16:10] <degville> pstolowski: no problem, and yes, you're right.
[16:21]  * zyga food
[16:31] <pstolowski> mvo: btw, #7016 needs 2nd review
[16:40] <mvo> pstolowski: yes, will do
[16:41] <pstolowski> mvo: thanks
[19:00] <cmatsuoka> mvo: oh well it seems that govendor doesn't like pull requests
[19:08] <cmatsuoka> has anyone used govendor with an unmerged PR?
[20:26] <zyga> cmatsuoka: what do you mean?
[20:27] <cmatsuoka> zyga: I have code that depends on a go-tpm PR
[20:27] <zyga> you have to update govendor's  json thing
[20:27] <zyga> we rarely do that though
[20:27] <zyga> you may also need to check if debian has that as a package
[20:27] <zyga> or otherwise part of CI will fail
[20:28] <zyga> similar thing for fedora (sorry)
[20:28] <cmatsuoka> zyga: you mean, by hand? because the govendor utility ignores the package
[20:28] <zyga> no, not by hand
[20:28] <zyga> I forgot how to useit
[20:28] <zyga> AFAIK you need to "go get" it
[20:28] <zyga> and tell govendor to add it
[20:28] <zyga> which will update the json
[20:28] <zyga> look at the history for vendor.json, maybe there are some clues
[20:28] <zyga> I honestly don't remember how to use it
[20:29] <cmatsuoka> if you govendor add the package (that's already positioned at the right branch) it's ignored, govendor doesn't add it
[20:29] <cmatsuoka> but if it's a "normal" package it works
[20:36] <cmatsuoka> aha, I can tell govendor to use the downstream tree with the upstream name
[20:37] <cmatsuoka> ok, that will solve the problem (hopefully)
[20:51] <cmatsuoka> yay, it worked!
[20:54] <cmatsuoka> thanks zyga for making me read the FAQ again :D


 Now that Github teams are free (and Github is better than Gitlab), I may very well move them again.
[10:41] <Unit193> bluesabre: Yes, I'm finding out with Salsa that I really don't like it. :/
[10:44] <Unit193> bluesabre: I made wireguard-linux-compat syncable from Debian!
[10:46] <brainwash> is this a debian packaging issue? https://bugzilla.xfce.org/show_bug.cgi?id=16696
[10:47] <brainwash> libexo-helpers.install does this:
[10:47] <brainwash> https://salsa.debian.org/xfce-team/desktop/exo/-/blob/debian/master/debian/libexo-helpers.install
[10:50] <brainwash> thunderbird.desktop helper file contains this:
[10:50] <brainwash> X-XFCE-CommandsWithParameter=/usr/share/xfce4/exo/exo-compose-mail mozilla-remote %B "mailto:%s";/usr/lib/x86_64-linux-gnu/xfce4/exo/exo-compose-mail mozilla %B "mailto:%s";
[10:50] <brainwash> second part is wrong
[10:51] <Unit193> Wouldn't it make sense to have those in libexec?
[10:52] <brainwash> but this looks right:
[10:52] <brainwash> https://git.xfce.org/xfce/exo/tree/exo-helper/helpers/thunderbird.desktop.in.in
[10:52] <brainwash> so
[10:53] <brainwash> this is wrong? https://git.xfce.org/xfce/exo/tree/exo-helper/helpers/Makefile.am#n64
[10:56] <brainwash> but it looks right in archlinux
[10:56] <brainwash> X-XFCE-CommandsWithParameter=/usr/lib/xfce4/exo/exo-compose-mail mozilla-remote %B "mailto:%s";/usr/lib/xfce4/exo/exo-compose-mail mozilla %B "mailto:%s";
[10:59] <brainwash> Unit193: you got an explanation for that? :)
[10:59] <brainwash> it has to be something with the debian packaging if it's not broken in archlinux
[11:00] <Unit193>         sed -i -e '/X-XFCE-CommandsWithParameter=.*exo-compose-mail/ s#lib/$(DEB_HOST_MULTIARCH)#share#' \
[11:00] <Unit193>                 debian/tmp/usr/share/xfce4/helpers/*.desktop
[11:00] <Unit193> > no g
[11:01] <Unit193> One letter would fix this, awesome.
[11:01] <Unit193> brainwash: Nice catch.
[11:04] <brainwash> great
[11:08] <Unit193> (I can't do an upload right now.)
[11:32] <bluesabre> Unit193: do you think you will be able to do an upload today? Final Freeze is tomorrow, so planning on tackling a few things if I can.
[11:33] <Unit193> Should be.
[11:41] <bluesabre> Awesome
[11:44] -BottyMcBotFace:#xubuntu-devel- ATTN: Xubuntu Core 20.04 - amd64 - amd64 built.
[11:50] <ochosi> and xfwm4 4.14.1?
[11:50] <ochosi> will that one make it?
[19:10] <albinard> Installed the Xubuntu Core ISO dated 04/15 on HP p7-1010, AMD64, BIOS, 6GB RAM.  Clean install, very quick, currently running well.
[21:06] <ochosi> good to hear
[21:09] <bluesabre> ochosi: possibly, need to package and test it
[21:10] <ochosi> contains quite a few niceties
[21:45] <Unit193> bluesabre: Err...exo doesn't build without any changes.
[21:46] <Unit193> Updating chroot, will re-try.
[21:51] <Unit193> Sweet, bad gcc.
[22:00] <Unit193> http://paste.openstack.org/show/uH1u8QCjLep3WGSyRHOt/
[22:50] <surveyor3[m]> Do I have to create only reproducible butg?
[23:00] <bluesabre> Unit193: shew
[23:01] <Unit193> Some pretty good errors too.
[23:01] <bluesabre> surveyor3[m]: Ideally. If we can’t reproduce it, it’s hard for us to fix it.
[23:28] <bluesabre> Unit193: thanks for packaging that exo fix
[23:48] <bluesabre> ochosi: want to test something?
[23:53] <bluesabre> Nevermind, I was apparently due for a reboot
[23:56] <bluesabre> xfwm looks good to me


[11:15] <pianopete1> Hi.  I'm trying to edit the Zenbook Prime Community wiki page to add information about module params for the centrino n advanced 6235 wifi card, but even though I have an Ubuntu One account and I am logged in, I can't seem to get to an edit page.  The page displays "Immutable page".
[12:48] <belkinsa> pianopete1, did you log in and come back to the page?  If not, that's what you need to do.  Or can just refresh the page you want to edit.
[12:49] <belkinsa> Oh, the person left....
[16:27]  * pianopete closed laptop and disconnected! oops.
[16:33] <pianopete> belkinsa: saw your message.  I tried this.  I even tried adding "?action=edit" to the end of the URL but I get "Vous n'êtes pas autorisé à modifier cette page."
[16:34] <pianopete> Do I need to be authorised by someone to edit a wiki page ?
[16:35] <pianopete> Also, it isn't totally clear to me if I should be seeing an edit button or similar.  The "More Actions" drop down menu doesn't have anything immediately obvious
[17:37] <petepiano1960> Is it possible that if a page has "Immutable" that the ordinary Joe like me can't edit it ?
[17:40] <pleia2> petepiano1960: very unlikely, it's usually a caching issue
[17:40] <ahoneybun> anyone know the ubuntu help app's package name?
[17:41] <pleia2> petepiano1960: the ubuntu help wiki uses very aggressive caching, so this problem is sadly common, if you clear your browser cache it usually helps
[17:49] <petepiano1960> should I see a specific 'edit' button on the page ?  or do I use the <url>?action=edit syntax ?
[17:51] <pleia2> petepiano1960: Immutable will be replaced with Edit
[17:54] <PaulW2U> petepiano1960: here's what I see - http://files.pcw.me.uk/snapshot2.png
[17:55] <PaulW2U> and yes, I can edit the page :)
[18:00] <petepiano1960> Hmmm. OK clearly my problem.  Just quit chrome, tried an incognito window, cleared cache..., refreshed with CTRL-SHIFT-R ...
[18:00] <petepiano1960> but still no joy.
[18:00] <petepiano1960> going to try another browser
[18:03] <petepiano1960> same problem with firefox.
[18:03] <petepiano1960> I am definitey logged in as I now have a 'logout' button at the tope of the page.
[18:04] <petepiano1960> :-(
[18:05] <PaulW2U> and your username is also there?
[18:05] <pleia2> that also happens with the caching issues
[18:05] <pleia2> there is a ticket oustanding with Canonical for all this, but it's pretty much ignored :\ they really struggle with keeping this wiki even running
[18:09] <petepiano1960> PaulW2U: nope - username not there.  Just the logout button.
[18:11] <pleia2> petepiano1960: aha, do you have a launchpad account linked to your Ubuntu One account?
[18:11] <pleia2> the username comes from launchpad.net
[18:13] <petepiano1960> Ahh - I think so.  Hang n.
[18:16] <petepiano1960> I have a launchpad account linked to a different email address (my work address).
[18:17] <petepiano1960> don't think I have another launchpad account.
[18:17] <pleia2> so you'll either want to use that account to edit the wiki, or create another launchpad account to link with your ubuntu one account
[18:17] <pleia2> https://help.ubuntu.com/community/WikiGuide/Registration <-- some instructions about doing this
[18:18] <pleia2> thanks for being patient, I'll follow up on the ticket once we get you sorted (just dug it up, it's from May of 2014)
[18:18] <petepiano1960> lovely. will try one or the other a bit later. need to go and make supper now.
[18:19] <petepiano1960> nice to get back into using irssi as well - been a few years!
[18:19] <pleia2> enjoy
[18:19] <pleia2> yay :)
[20:03] <petepiano1960> Yay - that was the solution.
[20:04] <petepiano1960> Logged into the launchpad account and I can now see the edit button.
[20:04] <pleia2> glad to hear it, sorry for all the trouble
[20:04] <petepiano1960> Thanks for the help.
[20:04] <petepiano1960> Heh - no need to apologise.
[20:04] <petepiano1960> Would it be useful to add something to the wiki editing page about that ?
[20:06] <pleia2> we include it on the Registration page
[20:06] <pleia2> https://help.ubuntu.com/community/WikiGuide/Registration
[20:06] <pleia2> but a lot of folks can't find that, not sure how to make it more discoverable
[20:07] <pleia2> just updated the ticket with Canonical, so hopefully they can look at it again
[20:23] <petepiano1960> What about adding something to the page that comes up when you click on 'Login' (the Personal Data Request page) ?
[20:24] <petepiano1960> BTW - edited the Zenbook Prime help page now as well.  A good days work. ;-)
[20:29] <pleia2> perhaps, if the sysadmins can't get to the bottom of the actual problem, that may help folks find their way
[22:18] <belkinsa> petepiano1960, do you have a launchpad account?
[22:19] <belkinsa> Oh, I see.
[22:19] <belkinsa> Nevermind.
[22:52] <petepiano1960> belkinsa: yeah - i had an Ubuntu One account and a Launchpad account - the Ubuntu One login didn't work. The Launchpad one was perfect.


[19:10]  * balloons awaits to pounce on veebers :-)
[19:12] <thomi> anything I can help with?
[19:14] <balloons> thomi, just curious about the autopilot release.
[19:16] <balloons> Also, I assume https://code.launchpad.net/~acerisara/autopilot/move-to-object/+merge/247524 can be top-approved?
[19:22]  * balloons pounces
[19:23] <balloons> good morning veebers. Once you've had ample time to awaken and sort yourself, ping me
[19:23] <veebers> balloons: sure, I'll ping you after the standup meeting that happening soon :-)
[19:30] <thomi> balloons: sorry, got distracted
[19:31] <thomi> balloons: veebers: I'm disturbed by the deletion of the docstring in that MP
[19:31] <thomi> but... it's veebers's baby now, so I'll let him decide
[19:32] <veebers> thomi: I'm not sure which docstring you're talking about
[19:32] <thomi> in https://code.launchpad.net/~acerisara/autopilot/move-to-object/+merge/247524
[19:32] <balloons> thomi, ohh right, the see blah
[19:32] <balloons> is there a more elegant way to do it, while still avoiding double documentation?
[19:33] <thomi> are te two methods identical?
[19:33] <balloons> mm.. I suppose it should actually have a docstring.. a unique one
[19:33] <balloons> meh
[19:33] <thomi> yeah
[19:33] <thomi> and make that function public, and give it a docstring too
[19:33] <balloons> I was thinking it was a duplication, but it's not purely one
[19:34] <thomi> that way the docstring can say "moves the cursor to the center point of the object. See `autopilot.input.get_center_point` for  details on how the center point is calculated'
[20:15] <veebers> thomi: can I get your opinion on this bug please? https://bugs.launchpad.net/autopilot/+bug/1422797
[20:16] <thomi> looking
[20:16] <veebers> I'm pretty sure it's not an autopilot issue (we haven't changed anything recently)
[20:16] <veebers> balloons: hey, what's the haps?
[20:17] <balloons> veebers, hey.. just wondering how the autopilot release was progressing
[20:17] <thomi> veebers: well, it might not be an issue in the autopilot _code_ :D
[20:17] <thomi> but it's still an issue with autopilot
[20:17] <veebers> balloons: currently it's not. Are you blocked on it not being released?
[20:17] <thomi> veebers: elopio's suggestion sounds plausible - I'd recommend following that up (make sure it's the case), and then maybe talk to the mir team about it
[20:18] <balloons> veebers, the apdocs re-work is blocked on it persay, but it would be nice
[20:18] <thomi> if elopio is correct, then this will affect users as well
[20:18] <veebers> thomi: ack, thanks
[20:18] <veebers> balloons: is or isn't?
[20:18] <thomi> balloons: <pedant>"per se"</pedant> :P
[20:18] <thomi> <-- studied latin
[20:18] <veebers> balloons: can it wait until next week?
[20:19] <balloons> veebers, wow, my sentence. No it is not blocked. The task to get the docs autoupdating is
[20:19] <balloons> and yes, as mhall is heading to scale for the rest of the week, it matters not this week :-)
[20:19] <veebers> balloons: right, ok :-) The blocked task, is that something that I'm blocking or elsewhere?
[20:20] <veebers> thomi: did balloons make a bit of a 'fox paz' ;-)
[20:20] <thomi> haha
[20:20] <balloons> thomi, yes.. wow, I don't usually type persay
[20:21] <balloons> odd thing that
[20:21] <thomi> you can butcher French all you like :D
[20:21] <balloons> more fun with sentences ^^
[20:21] <veebers> (balloons this is where you say you did it on purpose to annoy thomi :-))
[20:21] <veebers> balloons: Autopilot release is on the backlog for the sprint starting next week. So early next week we'll have a release
[20:21] <veebers> sorry again for the delay
[20:24] <balloons> veebers, I'm pretty sure the IOU balance is still in your favor.
[20:24]  * balloons debits 1 IOU from veebers account
[20:25] <balloons> and yes, messing with thomi is good fun. It's especially good fun now that he is on CI, and thus his ability to hit me back is lessened :-)
[20:25] <thomi> *cough*
[20:26] <thomi> you like having your CI jobs turned off for inexplicable reasons, do you? :P
[20:32] <veebers> heh, 'why are my CI jobs failing with the error 'Incorrect use of latin words' all of a sudden
[21:22] <veebers> elopio: hey, if you get time this week can you confirm if fixtures.Timeout will do what want for this bug? https://bugs.launchpad.net/autopilot/+bug/1408374


[00:39] <sdeziel> I'm looking at a problem involving LXD, Apparmor and mount rules and I'd appreciate if someone could help me :)
[00:39] <sdeziel> what I'm seeing suggest that mount options *ordering* would be relevant
[00:39] <sarnold> you should pick easier problems :)
[00:39] <sdeziel> https://github.com/lxc/lxd/blob/master/lxd/apparmor/instance_lxc.go#L177: mount options=(ro,remount,bind,noatime) /[^spd]*{,/**},
[00:39] <sdeziel> https://github.com/lxc/lxd/blob/master/lxd/apparmor/instance_lxc.go#L194: mount options=(ro,remount,noatime,bind) /[^spd]*{,/**},
[00:40] <sdeziel> sarnold: haha
[00:40] <sdeziel> are the above 2 rules redundant and LXD devs were overly zealous? Or is AppArmor really that picky?
[00:41] <sdeziel> or maybe a past version of AppArmor was had a bug forcing this kind of workaround?
[00:42] <sdeziel> sarnold: I don't think I pick problems, they seem to pick me </victim>
[00:46] <sarnold> sdeziel: I'm pretty sure those compile to the same thing..
[00:47] <sarnold> oh ffs .. I overlooked that these dump output to stderr, no stdout..
[00:48] <sdeziel> sarnold: if you are positive those compile to the same, I'll send a PR killing this madness ;)
[00:48] <sarnold> https://termbin.com/qpfjo
[00:49] <sdeziel> sarnold: thanks for checking and teaching me how to do, much appreciated (as always)
[00:50] <sarnold> sdeziel: it'd be reassuring if you fiddled with it a bit and saw similar things to convince you :) hehe
[00:54] <sdeziel> sarnold: I intend to compare 2 dumps of the lxd generated profiles, one as-is and the other with the order alternations removed. I'd do this once on 18.04 and another on 20.04. Does that sound like a good test? Or should I throw in something more modern in terms of AA version?
[00:55] <sarnold> sdeziel: that sounds like an excellent approach :)
[00:55] <sdeziel> awesome, thanks again!
[00:55] <sarnold> sdeziel: it might also be possible / better to compare the binary blobs from the cache directories, but I don't know for sure that they're going to be deterministic ;(
[00:55] <sarnold> I sure expect them to be..
[00:58] <sdeziel> yeah, good point
[03:36] <sdeziel> sarnold: let's hope I did it right: https://github.com/lxc/lxd/pull/9342
[17:07] <sarnold> sdeziel: woot! nice :) thanks


[14:44] <MichealH> Omega, Ping from like 2 d=ats go is now ponged
[14:44] <MichealH> :D
[20:15] <Omega> MichealH: pong