[19:12] <daftykins> irl25519: fix your connection please
[19:18] <zxmpi> i just ignore non talking bouncers these days and only unignore if i see someone else mention them
[19:18] <daftykins> makes sense!
[19:19] <daftykins> ah another productive day down at the dentists
[19:19] <daftykins> now i'm tinkering with some backup options
[19:20] <zxmpi> those floppy disks you got out of a skip will fetch a few bob :-P
[19:20] <daftykins> \o/
[19:21] <daftykins> sliced my fingers up a bit today, assembling a B&Q set of steel shelves
[19:21] <zxmpi> the cheaper the sharper
[19:22] <zxmpi> i once carried my 399 quid pc to work using the internal metal cage as a handle. after a 20min walk there was blood everywhere
[19:24] <daftykins> D:
[19:24] <daftykins> the blood sacrifice is only necessary on the initial build!
[19:25] <zxmpi> these days i usally carry a strap in my bag that i can wrap around packages to give a handle
[19:47]  * penguin42 got his metal shelves from some shopfitting company online, you can chose all the bits
[19:48] <daftykins> ooh
[19:49] <daftykins> i read 'shoplifting' on first scan
[19:49] <daftykins> ;D
[19:49] <zxmpi> ditto, could imagine penguin42 and a very big trenchcoat whistling nonchantly leaving shop
[19:50] <penguin42> feathers mcgraw...


[00:12] <wgrant> wallyworld_: My branch APA branch has landed.
[00:17] <james_w> lifeless, get well soon
[00:24] <wallyworld_> wgrant:  thanks, will take a look
[00:50] <wallyworld_> wgrant: i just pointed chromium at https://launchpad.net/launchpad/+filebug and it works fine
[00:51] <wallyworld_> 18.0.1025.168
[00:54] <wgrant> wallyworld_: Ahh, indeed.
[00:54] <wgrant> the problem in fact affects both.
[00:55] <wgrant> wallyworld_: You have to get to the second step using non-AJAX
[00:55] <wallyworld_> wgrant: what project were you filing a bug against?
[00:55]  * wallyworld_ tries that
[00:55] <wgrant> That is, enter a summary and click Continue on the first step before the JS changes it to an AJAX Next.
[00:55] <wgrant> You have to be very quick
[00:55] <wallyworld_> hmmmm
[00:56] <wgrant> That then POSTs to +filebug to return the second step without AJAX
[00:56] <wgrant> Which presumably lacks some of the JS or something.
[00:56] <wgrant> "choices is undefined"
[00:56] <wallyworld_> corner case :-)
[00:57] <wgrant> Yeah.
[00:57] <wallyworld_> so i guess i should try disabling the button untill all ajax is loaded or something
[00:57] <wgrant> No.
[00:57] <wgrant> The JS on the second stage should just not crash :)
[00:57] <wgrant> Although it would be nice to solve the slowness on the first stage too.
[00:58] <wallyworld_> i'll see what can be done
[00:58] <wallyworld_> the trouble is doing the post before the ajax is loaded sort of violates the expected behaviour
[00:59] <wallyworld_> ie it was never designed to handle that use case
[01:00] <StevenK> Bleh, why does branch deletion always toss me to the "Please try again" page
[01:00] <wallyworld_> timeout?
[01:00] <wgrant> StevenK: The timeout is too low to delete all 80k branchrevisions
[01:01] <StevenK> DROP TABLE branchrevision;
[01:01] <wgrant> wallyworld_: The rest of the JS on the second step works fine...
[01:02] <wallyworld_> i need to look into it - the whole bug form setup is "complicated"
[01:02] <rick_h_> wallyworld_: wgrant which bug is this? (curious)
[01:03] <wallyworld_> bug 1008543
[01:03] <_mup_> Bug #1008543: ChoiceSources on +filebug are empty in Chromium <disclosure> <javascript> <regression> <ui> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1008543 >
[01:03] <rick_h_> oh sucky, hadn't seen that one
[01:04] <wgrant> It's actually nothing to do with Chromium. It just happened that I tested it slightly differently in Chromium and Firefox.
[01:04] <wgrant> Was apparently slightly slower in Firefox.
[01:04] <rick_h_> gotcha, well that's a good thing at least, consistant
[01:04] <wallyworld_> yep
[01:05] <rick_h_> is this combo loader related? did it work without it?
[01:05] <wgrant> Unrelated
[01:05] <wgrant> This is code that was new last week
[01:05] <rick_h_> k, cool
[01:05] <wallyworld_> rick_h_: we need to support devs running combo loader with un-minified js ie add filter: 'raw', to the config just for devs
[01:06] <rick_h_> wallyworld_: yea, agree. I've been doing it manually, but would be nice to have it in config
[01:06] <rick_h_> no real reason not to run ith with always raw for devs
[01:06] <wallyworld_> rick_h_: we do need devs to run minified if required
[01:06] <wallyworld_> for testing etc
[01:06] <rick_h_> yea, but really QA would blow up if minifying messed anything up
[01:06] <wallyworld_> but we can add a property to the view which used a feature flag
[01:07] <wallyworld_> liek we do for yui version
[01:09] <StevenK> I think we should just set raw for devmode
[01:10] <wgrant> devmode is evil
[01:10] <wgrant> use feature flag
[01:13] <lifeless> james_w: thanks
[04:10] <StevenK> Hmmm. Can't reproduce bug 919252 on dev :-(
[04:10] <_mup_> Bug #919252: blueprints: can't reset Assignee etc to 'None' via popup <disclosure> <person-picker> <regression> <specifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/919252 >
[04:21] <wgrant> StevenK: Privs?
[04:22] <StevenK> wgrant: I'm doing as owner, but I have no idea of the Linaro set up.
[04:29] <StevenK> wgrant: And he says he can do it via +people
[04:30] <wgrant> StevenK: It's possible that it's been accidentally fixed, I supposed. Have you tried both Firefox and Chromium?
[04:30] <StevenK> I don't have Chromium to try
[04:30] <StevenK> It works in Firefox at least
[04:36] <wgrant> sudo apt-get install chromium-browser
[04:36] <StevenK> wgrant: *sadface*
[04:36] <wgrant> You can't expect to work on a webapp without it.
[04:38] <StevenK> wgrant: What about IE, Opera and Konquerer? :-)
[04:39] <wgrant> Covering both WebKit and Gecko successfully makes it a lot more likely that Trident, Presto and KHTML will work.
[04:39] <wgrant> It's still nice to test in the other three
[04:39] <wgrant> But testing in two is far far better than testing in one.
[04:39] <wgrant> Particularly since they're the dominant browsers
[04:40] <StevenK> wgrant: I thought Trident was only 9? Wasn't the engine in 8 something different?
[04:41] <wgrant> StevenK: Nope, since IE4.
[04:41] <wgrant> Except for Mac OS versions
[04:48] <StevenK> Chromium has no Help->About
[04:49] <StevenK> I guess Google considers indentification too hard
[04:49] <StevenK> wgrant: Works for me on dev with Chromium too
[04:50] <wgrant> StevenK: Huh, it doesn't have a classical menubar at all.
[04:50] <wgrant> They must have added it for globalmenus.
[04:50] <wgrant> Click the in-window menu icon, then About Chromium.
[04:55] <StevenK> wgrant: I'm suspecting it's already fixed, but I don't have acess as a driver to stuff on prod
[04:56] <StevenK> wallyworld_: How is information_type ChoiceSource going?
[05:38] <wallyworld_> StevenK: it's done, i have to finished the tests. but the tests are breaking due to animation issues so i need to sort that out
[05:40] <wallyworld_> StevenK: the code (minus tests) if you are interested, https://code.launchpad.net/~wallyworld/launchpad/infotype-widget-1007984/+merge/108665
[07:49] <adeuring> good morning
[08:15] <wallyworld_> StevenK: i've finished updating the tests
[08:15] <wallyworld_> https://code.launchpad.net/~wallyworld/launchpad/infotype-widget-1007984/+merge/108665
[08:19] <StevenK> wallyworld_: Looks good.
[08:19] <wallyworld_> coolio. seems to work nicely
[08:22] <StevenK> wallyworld_: Approved.
[08:23] <StevenK> stub: https://code.launchpad.net/~stevenk/launchpad/spph-packageupload-index/+merge/108515 would love a review.
[08:25] <stub> StevenK: Your partial index WHERE clause is backwards
[08:25] <StevenK> Oh, IS NOT NULL
[08:25] <StevenK> Bleh
[09:25] <lifeless> stub: I'm not here today, sick - I may be a few days getting over this
[09:26] <lifeless> stub: the storm and sockets thing; I think my main concern is group abnormal stuff into magical storm handling codepaths
[09:26] <stub> lifeless: I think I have food poisoning, or some sort of stomach bug.
[09:26] <lifeless> stub: like IntegrityError we know the db is live; SocketError - thats kindof a WTF moment.
[09:26] <lifeless> stub: ugh.
[09:27] <lifeless> stub: my sympathies; I have horrid stomach cramps at the moment - side effect of the virus
[09:27] <lifeless> stub: anyhoo, just wanted to put that out there - I'm not totally hostile to storm capturing the error, if those risks are assessed.
[09:27] <lifeless> stub: probably we need two distinct bugs though:
[09:27] <lifeless>  - one for handling the error
[09:27] <lifeless>  - one for -why- is it occuring
[09:28] <stub> lifeless: The goal of the Storm code is to reconnect when the db dies or is uncontactable or whatever.  We log the DatabaseDisconnectionErrors. Trick is to make sure we are logging what we should be logging. I think this is handled by storm manipulating the psycopg2 base classes so the disconnection error we catch is actually a psycopg2 exception.
[09:30] <lifeless> StevenK: did I mention the razor blade throat with laryngitis ?
[09:31] <StevenK> lifeless: :-(
[09:31] <stub> lifeless: you sound worse than me. I'll probably take sick leave once I've investigated this landscape replication issue.
[09:31] <lifeless> stub: I leave it in your capable hands; my main concern is about the 2-bug separation, not one bug w/2 tasks
[09:31] <stub> yup
[09:31] <lifeless> stub: thanks!
[09:31] <lifeless> Lynne and Cynthia had this, seems to be a 5-day thing
[09:31] <stub> erm... u1 replication issue
[09:32] <lifeless> day 2 of it for me (yes, sick on a pub holiday... win)
[09:33] <StevenK> stub: That index has landed as r15360 on devel.
[10:44] <wgrant> StevenK: That index looks backwards
[10:44] <wgrant> It's packageupload IS NOT NULL, when we want to search for ones where it IS NULL.
[11:02] <stub> did he go an land the backwards version?
[11:43] <StevenK> wgrant: stub said it was backwards :-(
[11:49] <wgrant> StevenK: stub probably mistook it for the PackageUpload.changesfile != None
[11:55] <StevenK> And ENOSTUB
[11:55] <StevenK> Let me revert
[11:59] <wgrant> StevenK: Can't revert
[11:59] <wgrant> StevenK: Wasn't it applied live?
[12:00] <wgrant> (I don't know if it was, but it probably was)
[12:00] <StevenK> And we have no UK webops to check
[12:00] <wgrant> jjo is around now
[13:09] <deryck> Morning, everyone.
[13:44] <wgrant> rick_h_: Thanks.
[13:45] <wgrant> rick_h_: A scan of 22000ish rows is much quicker than a scan of 22000ish rows then a join through 5 multi-million row tables :)
[13:46] <rick_h_> wgrant: yea, just got beat into my head that LIKE was evil too much over the years
[13:47] <sinzui> Sweet. I just fixed a post-3-ui-cleanup bug. It only took 2.5 years
[13:47] <rick_h_> sad that regex was slow, but oh well
[13:47] <rick_h_> sinzui: ummm woooo!
[13:47] <wgrant> rick_h_: The regex is still pretty fast, but 3x slower so meh.
[13:48] <wgrant> rick_h_: (do note though that postgres 9.1 can use trigram indices to satisfy LIKE '%foo%' efficiently)
[13:48] <wgrant> It's just not worth it here.
[13:48] <rick_h_> yea, something tells me dropping an 8 table join is probably a good plan regardless of the new plan lol
[15:25] <jcsackett> sinzui: i'm looking at bug 1007208. do we want to change the character limits for all pickers, or just the person picker?
[15:25] <_mup_> Bug #1007208: Searching for 'ev' in the 'add a member' picker fails <disclosure> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1007208 >
[15:27] <sinzui> jcsackett, excellent question
[15:28] <sinzui> jcsackett, The crux of the issue is that Lp Ids can be 3 characters. Lp has a nasty habit of creating Lp-ids from user email addresses, which are often 2-characters.
[15:29] <sinzui> jcsackett, Thus person pickers/searches must support 2-characters.
[15:30] <jcsackett> sinzui: right, i totally agree with the ">1" constraint for person pickers. i assume the bug picker doesn't do any checking regarding length, b/c that would be silly. that leaves...branch pickers?
[15:30]  * jcsackett slaps head.
[15:30] <sinzui> jcsackett, I think we can say projects and distros are less of a problem because users name them,
[15:30] <jcsackett> sinzui: yeah. and as i just realized, branch pickers aren't an issue b/c of branch naming patterns.
[15:30] <jcsackett> so this probably is just a person picker issue.
[15:31] <sinzui> jcsackett, branch pickers are buggered by design. We might make them workable in a month when we optimise the slow queries to not blindly search all Lp
[15:31]  * sinzui is looking at projects
[15:33] <sinzui> jcsackett, we 204 2-character project names, and no complaints. Lets no touch projects
[15:34] <jcsackett> sinzui: sounds good to me. i'll leave them alone.
[15:39] <cjwatson> sinzui: of course the case at hand was one where the user deliberately changed his username to a two-character one, rather than it being automatically created from an e-mail address :-)
[15:42] <sinzui> cjwatson, I think that is fine. Email addresses and IRC nicks can be two characters, and Lp allows them. It was ridiculous to require users to enter 3 characters to search.
[17:01] <bdmurray> I've noticed that the list of subscribers is in reverse alphabetical order in the subscribers portlet and I've a fix for this
[17:02] <bdmurray> however it seems like this might have been intentional
[17:02] <bdmurray>              // With multiple subscribers being added to the same section,
[17:02] <bdmurray>             // the last one is listed first.
[17:03] <bdmurray> so before carrying on I wanted to see if it is intentional and if so find out why
[17:05] <bdmurray> oh well there is a bug about it - 912137 so it must be wrong
[18:36] <timrc> When I review commits in Launchpad I sometimes see 'Timothy R. Chavez <timothy.chavez@canonical.com?' and so no hyperlink is produced for my name... is there something I'm doing wrong?
[18:36] <beuno> timrc,
[18:36] <beuno><EMAIL_ADDRESS>[18:36] <beuno> wrong closing
[18:37] <beuno> >
[18:37] <beuno> need to fix bzr whoami
[18:37] <timrc> right, but where do I specify that... I'm using bzr launchpad-login timrchavez
[18:37] <timrc> hm ok
[18:38] <beuno> timrc, can't change it retroactively, btw
[18:38] <timrc> yeah, bummer
[18:38] <maxb> timrc: 'bzr whoami'
[18:38] <timrc> you sort of can with the last commit by uncommitting though
[18:38] <beuno> yeah
[18:38] <timrc> thanks for helping me with a bzr prob in the #launchpad-dev channel
[18:39] <beuno> it's 30 cents extra in here!
[18:44] <timrc> ;)
[22:04] <sinzui> wallyworld_, looks like mumble cannot connect properly
[22:06] <sinzui> wallyworld_, wgrant. I am having networking issues with mumble
[22:06] <wallyworld_> sinzui: should we try skype?
[22:07] <sinzui> I am killing UbuntuOne
[22:09] <sinzui> wallyworld_, your voice is 3 octaves lower.  I think our provider switched us to 1st gear
[22:26] <sinzui> StevenK, I think as a driver you can mess with this https://blueprints.launchpad.net/gdp/+spec/gdplaunchpad
[22:58] <wgrant> Hm
[22:59] <wgrant> Why is icon-sprites.png in the tree now...
[23:00] <StevenK> I just saw that too
[23:00] <wgrant> sinzui changed the filename and ignore rule, and I guess someone blindly added the unknown file.
[23:00]  * wgrant fixes.
[23:06] <wgrant> Except that buildbot-poller apparently hates me.
[23:16] <StevenK> wgrant: Has your fixed landed now?
[23:16] <wgrant> StevenK: No. i suspect that buildbot-poller will remain confused until devel finishes.
[23:17] <StevenK> Bleh
[23:24] <StevenK> wgrant: devel just finished.
[23:36] <StevenK> wgrant: Can haz fix landed?


[07:03] <pstolowski|> mornings
[07:10] <zyga> good morning!
[07:10] <zyga> I'll start later as today is the market day so we need to go and buy groceries
[07:11] <zyga> and my wife should not carry and heavy things anymore so I need to help
[07:11] <zyga> hey Pawel :)
[08:02] <zyga> ok, I did most of the heavy lifting now
[08:15] <pstolowski> zyga: enumerating existing device as udev knows them is... problematic. now i understand why all the go udev implementations are cgo wrappers around libudev
[08:16] <pstolowski> zyga: and go-udev might be the only native go, except it doesn't really use udev stuff :/
[08:18] <pstolowski> zyga: parsing the output of `udevadm info -e` (exports udev database in a simple key=value format) might be one of the better options
[08:18] <zyga> pstolowski: can you tell me more please?
[08:18] <zyga> pstolowski: specifically what is problematic?
[08:21] <zyga> pstolowski: what is the format natively used by udev?
[08:36] <pstolowski> zyga: /var/run/udev/* has simple flat text files - one for every device/node it seems, and it's very bare. it doesn't have all devices it seems, e.g. when i plug a serial adapter it doesn't appear there, it seems udev keeps it in-memory only. to enumerate existing devices via udevadm you either query specific ones by names/paths, or just dump everything with `udevadm -e` and there is tons of logic in libudev when it
[08:36] <pstolowski> enumerates
[08:40] <zyga> pstolowski: and when you subscribed to the other netlink group and started to parse events, what kind of data was broadcast there?
[08:42] <pstolowski> zyga: only the devices that get plugged since i subscribed
[08:42] <zyga> aha, I see
[08:42] <pstolowski> zyga: so it's two worlds to deal with
[08:42] <zyga> so the problem is how to enumerate existing data set,
[08:42] <pstolowski> zyga: yes
[08:42] <zyga> I see
[08:42] <pstolowski> zyga: the way i see it for the moment:
[08:45] <pstolowski> zyga: we either subscribe to netlink for hotplug events, and parse udevadm to enumerate existing devices; or we just parse udevadm output for both cases (bonus is it's the same output format to parse then, then we don't actually need go-udev anymore); or we switch to some other go-udev implementation based on cgo+libudev
[08:45] <zyga> I think cgo+libudev is strongly undesired
[08:45] <zyga> because libudev has unstable protocol
[08:45] <zyga> and this would complicate re-exec seriously
[08:46] <zyga> we need to think how to approach the problem
[08:46] <zyga> can you look into what libudev C code does?
[08:46] <zyga> so that we understand the on-disk data format
[08:46] <zyga> and the current on the wire format
[08:48] <zyga> it seems that we could indeed run udevadm --monitor and just feed of that pipe
[08:48] <zyga> but not sure
[08:48] <zyga> this is something to discuss with gustavo IMO
[08:55] <pstolowski> zyga: yep, i'll look into libudev more. also, the parsing of netlink data from udev is questionable and might have potential to break. they have a custom header (a bunch of ints, one of them tells you the offset where actual data starts). this header is *private* to the libudev/udevdaemon, it means it's a contract between libudev/udev basically and can change at any time (they don't even care about endianess there). so
[08:55] <pstolowski> even monitoring via netlink has a risk of breaking
[08:55] <zyga> pstolowski: I think we need to (realistically) support every wire format used by udev since Ubuntu 14.04-era onwards
[08:56] <zyga> pstolowski: it is either that or parsing of (potentially equally fragile) text representation from udevadm
[08:56] <zyga> pstolowski: or writing our own udev and shoving it into early boot
[08:56] <zyga> (initrd)
[08:59] <pstolowski> oh noes
[09:00] <Chipaca> pstolowski: ?
[09:01] <pstolowski> Chipaca: that's in response to what zyga suggested re own udev
[09:04] <Chipaca> pstolowski: we'll write our own udev, with blackjack and hooks
[09:10] <pstolowski> zyga: fwtw the text repr of udevadm looks quite stable due to its simplicity. but yes, it's all fragile
[09:18] <zyga> pstolowski: yeah, all --porcelain
[09:18] <zyga> Chipaca: lol
[09:18] <zyga> Chipaca: on the other hand I'm very much happy to write one if we choose to
[09:24] <zyga> Chipaca: if we choose to do this we must mask it as something entirely non-udev like so that phoronix won't notice ;-)
[09:25] <pstolowski> :)
[09:26] <Chipaca> call it µdev
[09:27] <zyga> Chipaca: ooooh, I love it!
[09:27] <zyga> Chipaca: can I can I can I? :D
[09:27] <Chipaca> it looks like I'll never have time to do µubuntu, so, sure
[09:29] <zyga> moobuntu for livestock
[09:29] <zyga> but it would have to use apt for packaging, it is so apt
[09:33] <niemeyer> Mornings
[09:33] <zyga> hey hey
[09:34] <pstolowski> morning niemeyer !
[09:34] <niemeyer> pstolowski: Heya
[09:38] <pstolowski> niemeyer: some interesting findings re udev, go-udev etc., we will need to meet and take some decisions
[09:39] <niemeyer> pstolowski: Sounds good, let's try after the standup today
[09:39] <zyga> niemeyer: we have the core 18 meeting then
[09:45] <niemeyer> pstolowski: I'm hoping for a slightly shorter meeting as we have less people
[09:45] <zyga> ah, indeed
[09:45] <zyga> we should have plenty of time in between
[09:45] <pstolowski> sure
[10:27] <mup> PR snapd#5490 opened: store: make snap blobs be 0600 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5490>
[10:30] <Chipaca> ^ should be an easy one to review
[10:33] <zyga> done
[10:41] <pstolowski> Chipaca: +1, with a suggestion
[10:41] <Chipaca> pstolowski: your suggeestion wouldn't catch seeds though
[10:44] <pstolowski> Chipaca: right, i didn't know it was supposed to; $(find /var/lib/snapd/{cache,snaps,seed/snaps} then; but, nvm
[10:48]  * zyga is happy now
[10:48] <zyga> all the remapping is tested and can be proposed now
[10:48] <niemeyer> pstolowski: Have you seen the note on #5488?
[10:48] <mup> PR #5488: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488>
[10:50] <pstolowski> niemeyer: yes, thanks, will respond
[10:58] <pstolowski> replied and closed
[10:58] <mup> PR snapd#5488 closed: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5488>
[11:03] <niemeyer> pstolowski: What's the status of #4940?
[11:03] <mup> PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
[11:09] <pstolowski> niemeyer: i'm hitting various issues with it on existing spread tests; no clear pattern, various failures inluding kill timeouts. no idea why, there is no clear indication in the logs pointing at my changes (but oviously they are the suspect), and just re-runiing a failing test locally doesn't reproduce the failure
[11:10] <pstolowski> niemeyer: in any case, in the light of what i'd like to discuss today i might need to make changes
[11:12] <niemeyer> pstolowski: Are we seeing the same errors on master?
[11:14] <pstolowski> niemeyer: no, except ocasionally with flaky tests
[11:14] <niemeyer> pstolowski: We've seen kill timeouts on master before, but my understanding is that those were related to core and were fixed
[11:15] <pstolowski> niemeyer: yes. but not at the rate i see on my PR
[11:15] <pstolowski> niemeyer: i basically didn't have a succesful run on this PR yet
[11:15] <niemeyer> pstolowski: If you're wondering about whether it's your PR's fault, I suggest breaking it down into smaller chunks, and pushing it so we can review and merge until we hit something suspicious
[11:16] <niemeyer> pstolowski: In fact, given how long that's been up for review and the long history of merges, that might be a good idea either way
[11:16] <niemeyer> pstolowski: It feels like that's been blocked for months now
[11:16] <Chipaca> cp: not writing through dangling symlink 'squashfs-root/usr/bin/snapctl'
[11:17] <Chipaca> ^ anybody seen those before now?
[11:17] <niemeyer> Chipaca: No, but that's pretty nice actually
[11:18] <niemeyer> Chipaca: In terms of cp not doing that, I mean
[11:18] <pstolowski> niemeyer: the biggest suspect is plugging go-udev in.. which is the meat of this PR. I can probably split it into two PRs - some scaffolding, and then actually plugging it in
[11:18] <niemeyer> Chipaca: We've recently merged a PR from mvo that changed the way this worked..
[11:18] <niemeyer> Chipaca: It wasn't a symlink before
[11:18] <niemeyer> Chipaca: by recently I mean yesterday :)
[11:18] <niemeyer> pstolowski: I don't see go-udev in that RP
[11:18] <niemeyer> PR
[11:19] <niemeyer> pstolowski: Maybe that's why it's failing? :)
[11:19] <pstolowski> niemeyer: and it was blocked for long time by go-udev dependency.. which got resolved ~2 weeks ago by incorporating go-udev
[11:19] <pstolowski> niemeyer: no, go-udev package landed
[11:19] <niemeyer> pstolowski: Ah, ok
[11:19] <pstolowski> this PR actually makes use of it
[11:19] <niemeyer> pstolowski: Ok.. how about this.. can we close it and get smaller PRs in, oriented after whatever we discuss today?
[11:20] <niemeyer> pstolowski: We need to start flowing bits in
[11:20] <pstolowski> niemeyer: okay. fwtw a few small bits landed already
[11:21] <pstolowski> niemeyer: anyway.. the topic to discuss today might be a tough nut to crack for this entire story
[11:22] <Chipaca> niemeyer: hmm. I wonder if master is broken because of this, then. Pretty consistent anything-but-ubuntu-16+ broke in the same way with my pr (but maybe it's my pr)
[11:22]  * Chipaca running spread from master now
[11:24] <niemeyer> pstolowski: Cool
[11:24] <niemeyer> Chipaca: I received mixed broken/not-broken messages from Travis yesterday.. wouldn't be entirely surprising if something that got landed isn't entirely right given prior merges
[11:26] <niemeyer> Chipaca: This is the relevant PR: #5375
[11:26] <mup> PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
[11:27] <niemeyer> jdstrand: Gentle ping about #4951.. no rush, just want to make sure it's featured somewhere in your list still
[11:27] <mup> PR #4951: interfaces/screenshot: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
[11:33] <mup> PR snapd#5491 opened: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
[11:35] <Chipaca> niemeyer: yep, master broken
[11:36] <niemeyer> Chipaca: Well, at least it's a well known cause for once
[11:36] <mup> PR snapd#5492 opened: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[11:36] <Chipaca> niemeyer: grmbl grmbl grmbl
[11:36] <niemeyer> Chipaca: Any ideas given what you've seen?
[11:37] <Chipaca> niemeyer: replace «cp -a /usr/bin/snap /usr/bin/snapctl squashfs-root/usr/bin/» with something that's mindful of the symlink
[11:38] <niemeyer> Chipaca: Hmm
[11:38]  * zyga proposed the interface re-mapping integration PR and the first of the tree patches :)
[11:38] <niemeyer> Chipaca: The error is likely that we're doing that twice
[11:38] <niemeyer> Chipaca: I mean, that command, if done twice, will fail on /usr/bin/snapctl
[11:39]  * niemeyer tests the theory
[11:39] <zyga> niemeyer: didn't we change the base snap by now?
[11:39] <Chipaca> niemeyer: I don't think so, I think it's that core already has a symlink there
[11:39] <zyga> so maybe base and the test support is doing the same thing now
[11:40] <zyga> I can now start looking at existing PRs
[11:40] <niemeyer> Chipaca: Yeah, but there's something that doesn't smell right there
[11:40]  * zyga catches up with IRC
[11:40]  * Chipaca takes a shower
[11:41] <niemeyer> Chipaca: "cp -a" works on symlink over symlink
[11:41] <Chipaca> niemeyer: *dangling* symlink is key i think
[11:41] <niemeyer> Chipaca: This is copying a file over a symlink
[11:42] <zyga> pedronis: would you have time to review 5492, you did an earlier iteration of the idea
[11:42] <zyga> pedronis: I have it fully fleshed out now
[11:43] <pedronis> I'll look at it later today  (it's a couple of nights that I'm not sleeping well and it makes me a bit slow)
[11:43] <Chipaca> niemeyer: ok, so new hypothesis: coreutils change the behaviour of cp over dangling symlink, which is why it fails in 14.04 but not 16+, and presuambly fedora and opensuse have the old one
[11:43] <Chipaca> hmm, that sounds wrong, fedora usuallly ship bleeding edge coreutils
[11:43]  * Chipaca runs the test on fedora to check
[11:44] <pedronis> Chipaca: anyway , it's probably more complicated than that becausee if we have snapd and core18, we want to change snapd, not the symlink in core18
[11:44] <pedronis> I'm not quite sure how far we are in that
[11:44] <Chipaca> niemeyer: actually, in 16.04, cp -a refuses to copy over a dangling symlink
[11:44] <zyga> pedronis: thank you and take care, sleep is like credit, you have to pay back eventually
[11:45] <niemeyer> Chipaca: I don't get what changes in the last few days for this logic to be broken now, but the logic does look broken indeed
[11:45] <Chipaca> niemeyer: /usr/bin/snapctl became a symlink
[11:46] <Chipaca> niemeyer: you yourself told me :-D
[11:46] <niemeyer> Chipaca: I mean, the rm right above it removes snapctl from /usr/lib/snapd.. the follow up command then copies it into a different place
[11:46] <zyga> niemeyer: new core snap was built?
[11:46] <mup> PR snapd#4940 closed: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4940>
[11:46] <niemeyer> Chipaca: It's just inconsistent... I suggest fixing it by removing *both* /usr/bin/snapctl and /usr/lib/snapd/snapctl, and copying *both* back
[11:46] <niemeyer> Chipaca: The rm will likely have to be -f
[11:47] <Chipaca> niemeyer: I'll give you a clearer picture of the failure in a bit (test spinning up)
[11:47] <niemeyer> Chipaca: It's a bit uncertain because we're dealing with an external core
[11:48] <niemeyer> Chipaca: Actually, that's likely where the failure comes from
[11:48] <niemeyer> Chipaca: The passing code expected a previous core from edge.. once the PR was merged, the logic in the test became incompatible with the logic that was merged, somewhat ironically
[11:53] <Chipaca> niemeyer: so, snapctl needs to be in libexec, and the one in bin a symlink to it, right?
[11:53] <Chipaca> as per #5375
[11:54] <mup> PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
[12:01] <Chipaca> lynch! launch! lunch!
[12:06] <niemeyer> Chipaca: Not libexec, lib/snapd
[12:07] <Chipaca> niemeyer: http://paste.ubuntu.com/p/jq8nw6H8q2/
[12:07] <niemeyer> Ah, nevermind.. we put that in libexec in some distros
[12:08] <niemeyer> Chipaca: Typo in usrs
[12:08] <Chipaca> dammit
[12:08] <Chipaca> niemeyer: ta
[12:08] <niemeyer> Chipaca: No need for the -f I think.. I missed the fact it was a * when reading the output
[12:10] <niemeyer> Chipaca: Looks good
[12:25] <mup> PR snapd#5493 opened: tests: prepare needs to handle bin/snapctl being a symlink <Created by chipaca> <https://github.com/snapcore/snapd/pull/5493>
[12:41] <jdstrand> niemeyer: thanks for the reminder. I had it as blocked in the list so I fixed that
[12:42]  * zyga focuses on core18-tests3 for now
[12:55] <zyga> hey jdstrand
[12:56] <zyga> how are you doing?
[12:58] <zyga> jamesh: hey
[12:58] <zyga> I saw some tweets from the conference
[12:58] <zyga> how are you doing?
[12:58] <zyga> jamesh: anything interesting to share?
[12:58] <Chipaca> a curse on google:ubuntu-16.04-64:tests/main/interfaces-accounts-service
[12:59] <Chipaca> was anybody looking into that one?
[12:59] <jamesh> zyga: hi.  I had a chat with the flatpak/xdg-desktop-portal guys this morning during a BoF about improving support for snaps
[12:59] <zyga> Chipaca: mmmm, perhaps pstolowski but I don't remember for sure
[13:00] <Chipaca> jamesh: zyga: so much paella
[13:01] <jamesh> zyga: we want to provide more info about a snap to xdg-desktop-portal, but don't want to add a new dependency, so the current plan is to add a new "snap" sub-command that returns the info in a machine readable format (probably keyfile or yaml), and have xdg-desktop-portal call that
[13:01] <jamesh> zyga: probably passing the AppArmor security label as an argument, and maybe also process ID
[13:02] <jamesh> zyga: the extra info I want is the desktop file ID for the confined app, and whether it has the network interface plugged
[13:02] <jamesh> there might be more in future
[13:02] <Chipaca> zyga: https://github.com/tremby/imgur.sh
[13:03] <zyga> thank you!
[13:03] <jamesh> Chipaca: we did have paella at the beach party, yeah.
[13:03] <Son_Goku> jamesh, why would the AppArmor sec label matter?
[13:03] <zyga> jamesh: neat
[13:04] <Son_Goku> and that wouldn't be particularly useful when that isn't available (e.g. Fedora, CentOS)
[13:04] <Son_Goku> I'd also suggest using either keyfile or json
[13:04] <Son_Goku> those are a lot less brittle
[13:05] <jamesh> Son_Goku: at the moment, xdg-desktop-portal won't detect a snap as confined without the security label
[13:05] <Son_Goku> jamesh, could you do it in a more generic fashion?
[13:06] <Son_Goku> I don't understand why the AppArmor label is required specifically for this
[13:06] <Son_Goku> that defeats the abstraction between AppArmor and the sandboxing control
[13:07] <jdstrand> hey zyga. pretty good, how are you?
[13:08] <zyga> jdstrand: I'm good, enjoying the time with my family in the woods,
[13:08] <zyga> I'll be in Montreal next week, are you going?
[13:08] <jdstrand> nice! yes, I'll be there
[13:09] <zyga> jamesh: I'd love to know what your plans are after the event, let me know if you think it would be useful to sync _during_ the event so that you can still discuss ideas with the flatpak team
[13:10] <jamesh> Son_Goku: the AppArmor label was the most obvious way to detect that the application really was a confined snap (rather than a flatpak, or an unconfined app).  What would you suggest for systems without strict confinement?
[13:11] <Son_Goku> jamesh, snap-confine has "grades" of confinement, which could be passed to xdg-desktop-portal
[13:11] <zyga> jamesh: we could look at the root filesystem of the mount namespace
[13:12] <zyga> jamesh: and see if it is /var/lib/snapd/snap/* or /snap/*
[13:12] <zyga> jamesh: this could be used as a fallback in case the apparmor label is problematic in any way
[13:12] <jamesh> Son_Goku: for reference, this is the information dbus-daemon gives us to make the decision: https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials
[13:13] <jamesh> Son_Goku: I meant strict confinement as in what "snap debug confinement" prints
[13:14] <jamesh> Son_Goku: that will say "strict" on systems where we have MAC controlling file system access and mediated D-Bus communication
[13:14] <Son_Goku> that means it'll fail in partial confinement situations
[13:14] <Son_Goku> which is basically everyone except Ubuntu
[13:14] <Son_Goku> (and Solus)
[13:15] <jamesh> zyga: so I guess the solution to ever problem ends up being "parse the mountinfo file" :)
[13:15] <zyga> jamesh: no, you can really just read one symlink in proc
[13:15] <zyga> it's nicer than mountinfo :)
[13:16] <zyga> jamesh: AFAIR /proc/$PID/root
[13:16] <jamesh> oh
[13:16] <zyga> and then match against two patterns
[13:17] <zyga> thigh AFAIR the symlink value is dynamic depends on the POV of the beholder, so if you are "inside" it will always have a value of /snap/* (needs checking)
[13:17] <jdstrand> fyi, that's overstated-- there are quite a few distros that have it where snapd is supported. @popey provided me with a list recently
[13:17] <jamesh> zyga: hmm.  readlink() on that returns "/"
[13:17] <zyga> jamesh: ah, that's not useful then :/
[13:18]  * jdstrand is referring go "< Son_Goku> which is basically everyone except Ubuntu (and Solus)"
[13:18] <zyga> from the outside it would be different but it makes sense to be / on the inside
[13:18] <jdstrand> to*
[13:18] <Son_Goku> jdstrand, dbus mediation isn't upstream
[13:18] <jamesh> zyga: it is a magic proc symlink, so doing open() on it would give a dir fd for the confined root.  I'm not sure how to convert that to the root file system though
[13:18] <jdstrand> Son_Goku: dbus mediation *is* upstream in dbus. the kernel feature not yet, but is super close
[13:19] <zyga> jamesh: I see, well, I'm offering to help if you need to discuss something and think I could be useful
[13:20] <jdstrand> Son_Goku: I'm not arguing against your point of having to deal with partial confinement like Debian/OpenSUSE or devmode like Fedora, I was just clarifying your specific comment on 'only Ubuntu (and Solus)'
[13:20] <Son_Goku> for full confinement, that's it, though
[13:21] <jdstrand> Son_Goku: no, it isn't. that is my point. popey showed me a list recently
[13:21] <Son_Goku> and that list is?!
[13:22] <jdstrand> I'll let popey comment since I would have to dig around for it. if he doesn't have it at hand, I will do that
[13:22] <popey> It's just a list of distros I've booted in a vm and run hello-world.evil to see if confinement works
[13:23] <popey> i replied citing them in a thread on the forum
[13:24] <jamesh> zyga: if there's anything more you'd like me to bring up, there's still another day of the conf.  Getting the in-principle support for the "call snap as a subprocess" solution was a good start
[13:24] <jamesh> (and is probably the first step towards something that will work better on Fedora, etc too)
[13:25] <jamesh> given what's currently in xdg-desktop-portal relies exclusively on AppArmor security labels
[13:25] <zyga> jamesh: one thing that we can do that's simple
[13:25] <zyga> jamesh: snapctl
[13:25] <popey> jdstrand / Son_Goku https://forum.snapcraft.io/t/joystick-connection-request-for-xonotic/6244/7 the post in question
[13:25] <zyga> jamesh: snapctl uses a cookie to talk to snapd as a given snap
[13:25] <Son_Goku> popey, you proved my point
[13:25] <zyga> jamesh: so it could be there, regardless of confinement we would be able to present meta-data about the snap being executed
[13:25] <popey> Son_Goku: I don't know what point I proved :)
[13:25] <jamesh> zyga: where is the cookie?
[13:25] <zyga> jamesh: I think it is in the environment
[13:26] <Son_Goku> jdstrand, popey's list boils down to Ubuntu and Solus
[13:26] <zyga> jamesh: so running snapctl from inside a snap "authorizes" it as the snap
[13:26] <Son_Goku> all the various Ubuntu flavors are a distinction without a difference
[13:26] <popey> elementary, KDE Neon and Linux Mint are not flavours.
[13:27] <Son_Goku> but they are derived from Ubuntu and do not change anything about Ubuntu in that manner
[13:27] <Son_Goku> (Mint and Neon's irresponsibility about sec updates aside)
[13:27] <ogra_> mint also installs its own kernel by default
[13:27] <popey> (oh, and Zorin, which isn't in that list because that list if systems which do _not_ have GNOME Software by default).
[13:27] <popey> ogra_: uh, you may be on outdated info
[13:28] <ogra_> (which might or might not cause issues with snaps)
[13:28] <Son_Goku> ogra_, you're wrong
[13:28] <ogra_> oh, really ?
[13:28] <Son_Goku> Mint uses Ubuntu kernel
[13:28] <popey> yes, please check before claiming that again
[13:28] <Son_Goku> they've done that for at least a few years
[13:28] <ogra_> i know you can install the ubuntu kernel manually but their main reason for existance was always their own kernel
[13:28] <Son_Goku> no
[13:28] <popey> No
[13:28] <Son_Goku> their existence is for Cinnamon Desktop
[13:28] <Son_Goku> just like elementary's is Pantheon Desktop
[13:29] <ogra_> it used to be the kernel too
[13:29] <ogra_> good that this changed then
[13:29] <popey> Lets talk about today rather than the past
[13:29] <Son_Goku> anyway, point is, anything using Ubuntu AppArmor (aka Ubuntu or Solus kernel) has it
[13:29] <Son_Goku> no one else does
[13:30] <Son_Goku> one day, that situation will change (and I can stop calling it Ubuntu AppArmor then), but that day is quite a ways out
[13:32] <jamesh> zyga: if we resort to parsing /proc/$pid/env, we may as well just look for SNAP_NAME
[13:33] <jamesh> (as an indicator that it might be a snap app: the snap command could do a more rigorous check)
[13:38] <zyga> jamesh: yes, though that's easier to spoof
[13:38] <roadmr> jdstrand: hey! sorry for not announcing it earlier, reviewer-tools r1093 is live in the store (as of Friday I believe)
[13:40] <jamesh> zyga: right, but false positives are okay here.  It'd just mean we unnecessarily call the snap command, and get back an error saying it isn't really a snap confined app
[13:40] <zyga> jamesh: sure but if we are looking for anything and calling snap we could look at SNAP_COOKIE and run snapctl with some command, as a protocol it feels nice
[13:41] <jdstrand> roadmr: thanks! fyi, I may ask you to turn on resquash enforcement this week when the squashfs-tools make it through SRU
[13:41] <roadmr> jdstrand: great! sure, let me know. Remember we'll be in sprint mode next week, maybe to keep in mind.
[13:42] <roadmr> jdstrand: but of course I'm available that week if we need to flip it back quickly (and we'll mostly be in the same room so that might be a plus hehe)
[13:42] <jdstrand> roadmr: once they hit -updates, remind me, can we depend on -updates being applied immediately?
[13:42] <jdstrand> roadmr: yes, it would be nice to say at the sprint "we just turned on enforcement again and are keeping an eye on it"
[13:42] <roadmr> jdstrand: uhh great question. The safest bet would be to do an explicit upgrade, which I can do via an IS ticket request
[13:47] <roadmr> jdstrand: so when it hits -updates, it should be in the store units in the next 24 working hours
[13:47] <jdstrand> roadmr: ok, I'll keep that in mind
[14:03] <niemeyer> zyga: You coming?
[14:03] <zyga> yes
[14:27] <thresh> is it only me or the color picker in the snapped gimp select the one and only blue color? 007ffd?
[14:37] <Chipaca> thresh: wayland?
[14:39] <zyga> re, sorry I had to feed my dog
[14:45] <Chipaca> zyga: in soviet russia, something something something
[14:46] <zyga> Chipaca: so we dogfood our stuff, right?
[14:46] <Chipaca> zyga: isso
[14:46] <popey> I prefer "Drink our own champagne" :)
[14:47] <Chipaca> we've got enough verified developers i think i should work on the snap cli bit of that
[14:47]  * Chipaca looks
[14:47] <cwayne> popey: what you don't like dogfood?!
[14:47] <popey> only on wednesdays
[14:48] <cwayne> makes sense
[14:48] <zyga> popey: that is grose ;-)
[14:49] <zyga> my dog is grateful and returned for a hug
[14:50] <thresh> Chipaca, nope
[14:50] <thresh> i'm not that hip
[15:00] <zyga> Chipaca: tests are not happy today, are they?
[15:10] <zyga> Chipaca: that's a nice one
[15:10] <zyga> Chipaca: MATCH errors, opensuse download errors, mount errors
[15:10] <zyga> bonus combo
[15:12] <zyga> https://api.travis-ci.org/v3/job/402187098/log.txt
[15:12] <Chipaca> zyga: plz restart it
[15:12] <zyga> ack
[15:13] <zyga> done
[15:13] <Chipaca> taw
[15:13] <Chipaca> I'm going to have to reimplement tabwriter for this thing
[15:13] <Chipaca> fun :-)
[15:13] <zyga> which thing?
[15:23] <zyga> pedronis: replied on your comment
[15:23] <zyga> as for the incoming/outgoing terminology I'm open for changes but this is actually factually accurate representation of what happens
[15:24] <zyga> pedronis: to stop changeing snap.Info we need to patch the interfac API layer heavily (ish)
[15:24] <zyga> *changing
[15:24] <zyga> pedronis: on the up side those are not really full snap.Infos, those are just re-mapped on the outgoing path and are no longer linked to anything else in snapd
[15:27] <pstolowski> niemeyer: re talking to udev: no generic udev->dbus bridge (only udisks2 for storage devices). the most appealing to me is a proxy executable that both enumerates and monitors the devices, and links with libudev. for the prototype I could just wrap udevadm info & monitor in a script (or have a script that just outputs predefined events) and focus on business logic of snapd, once that works have a proper udev helper binary.
[15:28] <mup> PR snapcraft#2178 opened: lifecycle: pass commands to containerbuild, not steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2178>
[15:30] <zyga> pstolowski: I think the answer to your main comment is that those are not _really_ snap.Infos, we just use the type for that because certain things about it are the same
[15:30] <zyga> er
[15:30] <zyga> pedronis: ^
[15:30] <zyga> pedronis: if you want I can look at separating those types out completely
[15:34] <pedronis> zyga: I need to look a bit at code, but I'm close to eod
[15:34] <zyga> pedronis: ok, I'll prepare a small PR that shows what this would look like
[15:35] <zyga> pedronis: essentially interfaces.Info type needs to grow some counterparts for snap.{Plug,Slot}Info
[15:35] <zyga> pedronis: and then we need to copy the data out of snap.{Plug,Slot}Info into the new interfaces.{Plug,Slot}PartialInfo
[15:35] <zyga> so that there is no need to ever modify snap.{Plug,Slot}Info
[15:36] <zyga> the new interfaces.{Plug,Slot}Info would only be used in the response to /v2/interfaces (and perhaps partially to connections later)
[15:36] <zyga> but this doens't change the essence of the re-mapping, I think that is still correct
[15:42] <Chipaca> zyga: I shal name thee 'hitter of restart job'
[15:42] <Chipaca> zyga: (it just became green i think)
[15:42] <zyga> Chipaca: oooh
[15:42] <zyga> merge it pretty please
[15:42] <Chipaca> it's only got one  +1 :-)
[15:43] <zyga> Chipaca: I'm the serverless api server  that makes things work ;0
[15:43] <Chipaca> but, yeah, niemeyer reviewed it on irc :-)
[15:43] <zyga> pstolowski: we need a +1, can you spare a sec?
[15:43] <Chipaca> merged
[15:43] <Chipaca> done
[15:44] <mup> PR snapd#5493 closed: tests: prepare needs to handle bin/snapctl being a symlink <Critical> <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5493>
[15:44] <zyga> thanks!
[15:49] <pstolowski> #4767 needs a second review... (for the brave only)
[15:49] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[15:51] <Saviq> hi all I've been getting store release / upload failures (500) from Launchpad, is that known? anything I can help with? https://launchpad.net/~saviq/+snap/subsurface-edge/+build/274030 is the failed release
[15:51] <jdstrand> roadmr: hey, can you pull in r1095 of the review tools (adds 2.34 interfaces and an override)
[15:51] <roadmr> jdstrand: sure!
[15:51] <jdstrand> thanks!
[15:53] <Chipaca> cprov: ^ see Saviq's q
[15:58] <roadmr> mhh Saviq it looks like it was an error releasing only, for the arm64 upload
[15:58]  * roadmr dives into logs
[15:59] <zyga> pedronis: still here?
[15:59] <mup> PR snapd#5494 opened: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494>
[16:00] <Saviq> roadmr: I've been getting those in ~20% of the builds since the weekend, some of them upload failures, some release
[16:00] <roadmr> Saviq: let's see what log diving says :)
[16:00] <zyga> pedronis: this is roughly the kind of change we'd have to apply to stop sending snap.PlugInfo in api responses: http://paste.ubuntu.com/p/5YqMTm3j9P/
[16:00] <Saviq> roadmr: https://launchpad.net/~saviq/+snap/subsurface-edge/+build/273719
[16:00] <zyga> this is _just_ the patch to the interface repository
[16:01] <zyga> a small change along this vein is needed in api.go and in the mapper (to stop changing PlugInfo)(
[16:01] <zyga> I can polish this all the way and propose
[16:02] <Saviq> roadmr: 0324, 0701, 1016, 1037, 1544 today (all UTC)
[16:02] <Saviq> and ok, it's only been today, not since the weekend
[16:02] <roadmr> Saviq: nice, thanks!
[16:03] <zyga> pedronis: let me know what you think
[16:03] <zyga> I need to break to take the dog out while it is not raining
[16:08] <roadmr> Saviq: I think it's because of a problem we identified yesterday and a rollout is in progress to fix it (hopefully)
[16:08] <roadmr> Saviq: I'll let you know when done and after that please let me know if it happens again
[16:10] <Saviq> roadmr: ack, will do
[16:29] <niemeyer> pstolowski|afk: If udevadm is enough, why not just calling it?
[16:36] <niemeyer> pstolowski|afk: Send some notes on that forum message.. that should probably be an open thread, btw
[16:36] <niemeyer> (sounds generally interesting and worth archiving)
[16:52]  * zyga returns home wet
[16:52] <zyga> so the week of rain starts now
[16:53] <zyga> I also saved the home camera by wrapping it in one of the bags for dog poo, I was glad to have a few extras
[16:53]  * zyga -> hot shower
[17:13] <niemeyer> pstolowski|afk: Sorry, s/Send/Sent/ (but that was probably obvious)
[17:16]  * Chipaca eods
[17:20] <niemeyer> Have fun Chipaca
[17:20] <niemeyer> I'll step out to run some errands as well.. back later
[19:49] <jdstrand> roadmr: hey, what does this mean: "Store upload failed: The request is missing an Authorization header field containing a valid macaroon" - https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/274620
[19:49] <jdstrand> roadmr: a better question is, how do I fix that?
[19:50] <roadmr> jdstrand: macaroons have a hard expiration date of (I think) a year, is it possible this project has been pushing builds for a year or so?
[19:50] <jdstrand> roadmr: yes
[19:50] <jdstrand> roadmr: how do I regenerate the macaroon?
[19:51] <roadmr> jdstrand: does this use build.snapcraft.io? or just launchpad?
[19:51] <jdstrand> roadmr: just launchpad
[19:52] <jdstrand> roadmr: I wonder if 'Update snap package' would do it, if I change nothing else
[19:52] <jdstrand> (under 'Edit snap package')
[19:52] <roadmr> hmm maybe but let me check
[20:03] <roadmr> jdstrand: ok, so that should work, yes
[20:04] <roadmr> jdstrand: ideally you'd get sent to SSO for authentication, that would strongly suggest it's getting a new macaroon
[20:04] <roadmr> jdstrand: if not try changing some bogus value (and then back, like the channel for publishing)
[20:09] <jdstrand> ok
[20:10] <jdstrand> roadmr: chaning nothing didn't work. trying changing something now
[20:11] <roadmr> \o/
[20:12] <jdstrand> roadmr: chaning something, updating, changing back, updating didn't work for an existing build. will now try a new build
[20:12] <jdstrand> it'll be a few minutes
[20:13] <roadmr> O;/ sorry about that
[20:16] <jdstrand> roadmr: oh, I was sent an email to go to https://launchpad.net/~jdstrand/+snap/snappy-debug/+authorize
[20:16] <roadmr> interesting
[20:17] <roadmr> jdstrand: Colin would be the expert here, this explains my amazed face at most everything you're encountering
[20:17] <jdstrand> heh
[20:17] <jdstrand> I'm going to wait to see what happens with the build before clicking the url
[20:20] <roadmr> jdstrand: if you click on authorize you'll get a page "Authorize store uploads of fongo"
[20:20] <roadmr> jdstrand: after clicking the button and going through the flow, I see "Uploads of fongo to the store are now authorized."
[20:20] <roadmr> fongo is my snap :D
[20:21] <roadmr> jdstrand: if your build still doesn't upload, it seems very likely hitting /+authorize will work
[20:21] <jdstrand> roadmr: it didn't upload. hitting authorize
[20:22] <roadmr> fwiw I saw the same flow to authorize the uploads, because I was just creating the snap
[20:22] <roadmr> which is why I sent you on the wild goose chase :( sorry
[20:22] <jdstrand> roadmr: that took me through SSO
[20:22] <roadmr> \o/
[20:23] <jdstrand> roadmr: and I can upload again. thanks!
[20:24] <roadmr> whee
[20:24] <roadmr> jdstrand: TIL about +authorize by the way :)
[20:43] <mup> PR snapd#5495 opened: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <https://github.com/snapcore/snapd/pull/5495>


[08:55] <hyperair> ScottK: thoughts on https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331? if nobody's working on it, i could provide a debdiff
[08:59] <rbasak> hyperair: please get that fix into Debian. With no delta against Debian in postfix, I'd rather not have to maintain a delta for that bug.
[08:59] <hyperair> oh right
[08:59] <hyperair> rbasak: what about stable releases though?
[09:00] <hyperair> (after getting it into debian, of course)
[09:00] <rbasak> No objection, as long as it's OK under normal SRU policy, etc.
[09:03] <hyperair> right
[09:03] <hyperair> okay, actually taking a closer look, postfix does already does drop a script into /etc/network/if-up.d
[09:03] <hyperair> odd
[11:34] <cpaelzer> hi, anybody an idea of a meta package I could depend upon which gives me /vmlinuz cross arch for Debian&Ubuntu?
[11:35] <cpaelzer> haven't seen a linux-generic in Debian - is there an equivalent?
[12:06] <fossfreedom> sil2100: on the off-chance you haven't broken up for the holiday season (!) ... have you found any time to look at the lp:ubuntu-cdimage merge request?  TIA
[12:10] <sil2100> fossfreedom: hey! Not yet, got a bit preempted last week - let me deal with it in a minute
[12:17] <ScottK> hyperair: I have a theory about it.  It's on my list for this week.
[13:05] <hyperair> ScottK: oh okay
[13:36] <rbasak> infinity: may I have your opinion on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/38 please?
[14:46] <rbasak> smoser, lamont: let's coordinate here.
[14:47] <lamont> ok
[14:47] <rbasak> I'm not sure what to do about bug 1642679. If nobody affected can be bothered to test, maybe it's better not to disrupt others who might be relying on the current code path but don't know about the bug and push a revert through. I don't know.
[14:47] <rbasak> But let me see if that's the only blocker.
[14:48] <rbasak> smoser: maybe put a second call for testing in the bug, at least?
[14:48] <smoser> rbasak, i'm typing some stuff there now.
[14:49] <smoser> and have irc-pinged a contact who is involved in the hyperv-nova work also
[14:51] <rbasak> lamont: can I check I'm not missing anything? What's the full set of packages you need releasing?
[14:55] <lamont> open-iscsi, isc-dhcp, initramfs-tools, cloud-init, cloud-initramfs-tools, ifupdown
[14:55] <smoser> rbasak, gsamfira responded to me and he says he will test.
[14:58] <rbasak> lamont: can you comment in bug 1629972 explaining on what basis it's verification-done please? That is: have you tested it specifically, or are you relying on the test case somewhere else? What about the test case documented in that bug itself?
[14:59] <rbasak> lamont: thank you for the list
[14:59] <rbasak> smoser: great, thanks!
[15:01] <lamont> rbasak: doh.  added.
[15:02] <lamont> the lxc test case in the bug was actually the simplified version of what I tested.
[15:47] <sil2100> Is there any archive admin around to do a preNEW review in Bileto for a new source package? https://bileto.ubuntu.com/#/ticket/2278
[15:48] <sil2100> In theory this should go to the NEW queue normally (Bileto doesn't go around the source NEW queue), but I remember we had this practice of gettin a pre-ACK beforehand
[15:48] <sil2100> And besides, this will go straight to the overlay for xenial
[15:52] <smoser> rbasak, gsamfira updated https://bugs.launchpad.net/cloud-init/+bug/1642679
[15:53] <rbasak> Thanks!
[16:28] <lamont> smoser: bug 1611074 needs yakkety verrification, it would seem
[16:28] <lamont> smoser: ditto bug 1626243
[16:34] <infinity> rbasak: Added my two cents.
[16:36] <rbasak> infinity: thanks!
[16:37] <smoser> lamont, hm..
[16:38] <rbasak> infinity: in general I agree with you, but here specifically there's one additional thing, which is that dhclient can grab a UDP port that later userspace then can't grab. So I think the bug is that it is (effectively) impossible to host a UDP service on a static port when using DHCP.
[16:38]  * lamont has looked around and found zero asure ephemeral drives. :/
[16:38] <infinity> rbasak: Yes, and the bug was reported 3.5 years ago, trusty was released 2.5 years ago, and we now have a new LTS.
[16:39] <infinity> rbasak: If we'd fixed it 3 years ago, fine, yay, but we didn't, and there were really very few complaints.
[16:39] <infinity> rbasak: Is there an internal motivation for this that has escalated it, or did the itch just land on someone who found the old bug and decided it was suddenly dire?
[16:40] <rbasak> infinity: AIUI, someone new got hit and raised it with Canonical. So new motivation arrived.
[16:40] <slashd> infinity, UA customer filed a bug about it, but I do agree with upgrading to Xenial, this is what I told him at the first place, and then I start a discussion with caribou and rbasak if we could do more or not
[16:41] <slashd> infinity, rbasak, so final position is upgrade to Xenial and nothing more ?
[16:41] <nacc> rbasak: caribou: ack on the bug filed re: usd tag, i forgot to update documentation (for now, run `usd tag --format='logical/<explicit version>'
[16:41] <rbasak> infinity: IMHO, the point in having an EOL is that we fix things before EOL is reached. So I'm not convinced "there's a new LTS out" should be a reason.
[16:41] <infinity> slashd: HEY YOU.
[16:41] <infinity> slashd: You owe me a bug verification on debian-installer in xenial.
[16:41] <infinity> rbasak: We don't fix ALL things.
[16:41] <rbasak> infinity: but, if that's a -1, I think it carries more weight that my +1 on the principle (but not the method).
[16:42] <rbasak> than my
[16:42] <slashd> infinity, I know I change the tag to verification-done and update the lp bu about d-i
[16:42] <infinity> rbasak: There's a bar for what is and isn't appropriate to fix in an SRU.  This is pretty borderline.
[16:42] <rbasak> infinity: I agree it's borderline, but the observation that it makes it impossible to reliably run a UDP static port service swung it for me.
[16:42] <infinity> slashd: Oh, so you did.  Thanks.
[16:42] <nacc> rbasak: caribou: re: LP: #1651113 that is
[16:42] <slashd> infinity, tks for sending me a reminder
[16:43] <infinity> rbasak: I don't particularly love the behaviour, but I love any potential solution less.
[16:43] <nacc> rbasak: do you want to sit down today or tmrw and prioritize the (now many) importer issues?
[16:44] <rbasak> nacc: sure. Let me figure out when is best.
[16:44] <infinity> rbasak: Anything that involves package splitting or environment-driven behaviour or, really, anything that says "trusty now supports two behaviours" will imply supporting a smooth upgrade path to same.
[16:44] <infinity> rbasak: Which means isc-dchp upgrade suddenly doing the opposite of what they do today, or similar issues.
[16:45] <rbasak> infinity: I think the current proposal resolves that. No unexpected change in behaviour for anyone. The ugliness is in having to do an SRU to Xenial to ensure that.
[16:45] <infinity> The use-case that leads to the misfeature being a "bug" is clearly not a common one, or we'd have a ton of angry bugs about it.  So I really think "upgrade to Xenial" is the saner answer.
[16:46] <infinity> rbasak: Nope, the current proposal doesn't address the upgrade path.
[16:46] <rbasak> infinity: how so?
[16:46] <infinity> rbasak: Once you split to "foo" and "foo-nofeature", you're saying "installing foo gets you feature".  And then we can't have it both ways.  Either the upgrade needs to start including feature, which will make current users grumpy, or it needs to not, which breaks that implied contract.
[16:47] <infinity> The current proposal says "all upgrades get you nofeature".
[16:47] <infinity> Which is certainly the path of least surprise for me.  But not for someone who read "apt-cache show foo" and "apt-cache show foo-nofeature" in a post-SRU world and installed "foo" on purpose.
[16:48] <rbasak> you're saying...> I'm not sure I agree. We could make that clear in the package descriptions. I don't think anyone would be surprised by this any more than they are surprised today that "feature" disappears on upgrade to Xenial, which already happens.
[16:50] <rbasak> I'm just surprised that you object on the principle of the thing rather than the mechanism.
[16:50] <infinity> Alright, that's a reasonable fair argument.  If you take your proposal, and add "due to this package split being a late addition to trusty, upgrades to xenial will require manually installing foo-feature if you wanted feature" might work.
[16:50] <infinity> I still disagree with the principle. :P
[16:50] <infinity> It's a feature, not a bug.  It's a crap feature to have installed on basically all machines, but that still doesn't make it a bug.
[16:51] <infinity> If the behaviour were itself deemed buggy and incorrect, we'd remove foo-feature from xenial, not split it. :P
[16:51] <persia> Just as a note: if only one person is complaining, can they just have a package that works for them?  I like everything being in the distro, but some things are disruptive.
[16:52] <rbasak> infinity: well, there are always going to be cases where users depend on one aspect of a particular feature but another aspect is a bug and should be fixed, but that would disrupt the first because SRU patches can't read minds.
[16:52] <infinity> persia: People like me have given Canonical support a pretty strong mandate to *not* build one-off packages for customer bugfixes unless there's literally no other way to address something, because, well, that's super distro-unfriendly and just leads to chaos and extra maintenance burden.
[16:53] <infinity> persia: Also hi.
[16:53] <rbasak> infinity: I expect there are other less borderline cases where we'd have to do something similar. But I accept this this case is so borderline, the same reasoning can tip it over the edge to "no".
[16:53] <persia> infinity: Hi.  People like me tend to deliver working packages and work with distro if that won't break distro, but I strongly support your base position and apologise for complicating it.
[16:54] <infinity> rbasak: Anyhow, I'm not going to be the one to block it or not.  I was offering a "this really doesn't need fixing at all, maybe you should just tell the customer to upgrade" option because, well, I feel that's the sane option.
[16:54] <persia> (and, to be fair, I'm not much of a person-like-me in the sense above these days)
[16:55] <rbasak> infinity: so now we have two indecisions :-)
[16:55] <infinity> persia: Yeah, were I an independent contractor, I'd provide fixes today, push to distro tomorrow, and if distro rejects, I'd figure out how to charge the client for ongoing maintenance of the forked package I just gave them. :P
[16:55] <infinity> persia: Canonical's pricing structure for baseline support definitely doesn't support the latter part of that sentence, so letting our support guys back themselves into that corner is very bad. ;)
[16:56] <caribou> infinity: rbasak: slashd: wouldn't a backport of the Xenial bits to the backport archive sufficient for this single occurence ?
[16:56] <persia> infinity: Understood, and thank you for formally describing "people-like-me" in that context.
[16:56] <infinity> Thus, it should be "in the distro for everyone", "no bugfix for you", or "this customer pays us way more".
[16:57] <infinity> caribou: Perhaps, but that's an ongoing maintenance burden too.
[16:57] <rbasak> caribou: that feels like it ships in a behaviour change in through the back door. I'm not sure backports is really intended for that, but I suppose that depends on backports policy.
[16:57] <infinity> caribou: isc-dhcp doesn't have a perfect security record, by any stretch, so a backport as a bugfix would also mean needing to keep backports up to date.
[16:57] <caribou> infinity: we do not propose maintenance for the backports archive
[16:57] <rbasak> Certainly with users opting in it's not so bad from that perspective.
[16:58] <rbasak> caribou: might as well just use a PPA then?
[16:58] <infinity> caribou: Err.  You can't have it both ways.  If this is proposed as a bugfix, the fix can't be something buggier. :)
[16:58] <caribou> rbasak: PPA is a one-off in that sense and, like infinity, is strongly against them
[16:58] <infinity> And "here's a version frozen in time with no upgdates because we don't wanna" is buggier.
[16:59] <rbasak> caribou: at least a PPA makes it clear though.
[16:59] <infinity> No, please don't.
[16:59] <caribou> rbasak: then let's teach them how to build their own PPA & let _them_ maintain it
[16:59] <infinity> If the motivation is strong enough to put work in on this, do it right.
[16:59] <rbasak> I'm not sure backports should be a place to fire-and-forget in changes you don't want to maintain.
[16:59] <slashd> rbasak, won't be supported if they have other issue as per UA policy, they will need to go back to the pkg in -update if they want more support on the pkg , sec update, etc ...
[17:00] <slashd> rbasak, about the PPA ^
[17:01] <rbasak> So, as I see it, neither infinity nor I are prepared to commit to a +1, but won't block it either. So we're effectively at 0 from an SRU perspective. Ubuntu governance requires us to be decisive. So we can extend to the rest of ~ubuntu-sru to decide, or ask the TB. That's our path to a decision if you want one.
[17:01] <infinity> Doesn't need a TB decision.
[17:01] <rbasak> I suggest that in this case if we remain at 0 then the status quo should remain.
[17:02] <rbasak> infinity: we can ask the TB if ~ubuntu-sru can't decide, AIUI.
[17:02] <infinity> If the isc-dhcp-client desciption is amended with a note about the split being post-release and upgrades downgrading the feature again, I'm fine with rbasak's plan otherwise.  I don't love it, but I can get over it.  But it better be deemed worth the effort by the people putting in the time on this. :P
[17:02] <infinity> (hint, hint)
[17:03] <rbasak> Well, then I guess it's fine to do if slashd prepares it all. Because infinity said it's OK :-P
[17:05] <rbasak> nacc: got time for a hangout now?
[17:05] <rbasak> I have a hard stop in 55 minutes though.
[17:06] <slashd> rbasak, infinity, so it's a +1 for my -noddns proposal, even if I totally agree that ideally, upgrading to xenial the favourite solution.
[17:07] <rbasak> slashd: that's my understanding, yes. But see infinity's requirement above, and I also want the dpkg-divert clashing path I identified in comment 38 checked carefully.
[17:07] <caribou> nacc: ack on usd tag btw
[17:07] <rbasak> slashd: as well as the use cases we already identified, all being checked as part of SRU verification please.
[17:08] <slashd> rbasak, sure, will you be amenable to sponsor it once completed since you are aware of everything since almost day 1 ?
[17:08] <rbasak> slashd: I can't sponsor as I'll need to be available to provide the ~ubuntu-sru review, and I can't do both.
[17:08] <slashd> rbasak, make sense, ok will find another sponsor, no worries
[17:08] <rbasak> slashd: basically you need two reviews - one from me, and one from another person who can upload the package.
[17:09] <infinity> rbasak: If you sponsor, you can annoy me until I review.
[17:09] <slashd> rbasak, ack
[17:09] <rbasak> slashd: oh, you have a volunteer :-)
[17:09] <infinity> If both our waffling asses agree it's okay, that closes that hole. :P
[17:09] <caribou> infinity: rbasak: I'll sponsor it, that's not an issue
[17:09] <slashd> tks caribou
[17:09] <slashd> tks infinty and rbasak
[17:10] <slashd> infinity ^
[17:10] <infinity> caribou: I expect you to take your sponsorship duties very seriously and review like you hate the uploader, then. ;)
[17:10] <infinity> (Pretending to hate the uploader/committer is my default review strategy)
[17:10] <caribou> infinity: I'll try to do as well as you did for me ;)
[17:10] <caribou> infinity: ah, now I get it :-p
[17:11] <infinity> "THIS GUY VOTED WRONG, KICKS PUPPIES, AND DOESN'T UNDERSTAND HOW BREAKS WORKS, ARGH."
[17:11] <infinity> Oh, wait, no, just the dpkg thing.  But still valid!
[17:12] <slashd> infinity, 2 quebecers can't hate each other, it will be hard to caribou to hate me ;) lol
[17:12] <xnox> persia, can you vote in US elections and who did you vote for?
[17:13] <infinity> slashd: Maybe have a debate about separation, and if you both agree (which you probably do), one of you can play devil's advocate until the other is seething with rage.
[17:14] <slashd> infinity, lol as long as I have poutine, I don't mind being in Canada ;)
[17:14] <xnox> wales would be happy to become Quebec's overseas territory.
[17:14] <infinity> slashd: A solid position.
[17:15] <caribou> infinity: pls don't get me into that; I fleed to France to avoid those
[17:17] <infinity> slashd: I'm considering running for federal office to proposed poutine and maple syrup transfer payments.  That is, every time Quebec is net negative on the other type of transfer payments, they need to send a few thousand tonnes of squeaky cheese and a few thousand litres of maple syrup out west to say "thanks".
[17:17] <infinity> slashd: Sadly, as the oil industry self-destructs, this seems less likely to work in the future. :P
[17:17] <slashd> infinity ;p
[17:18] <persia> xnox: I don't generally believe democracy is a good model, but one of my favorite parts of how it works in the US is the double-blind system for matching whether one voted and how one voted.
[17:32] <nacc> rbasak: sorry, was afk -- i can talk for a few now, or we could try tmrw?
[17:32] <rbasak> nacc: short chat now?
[17:33] <nacc> rbasak: sounds good
[18:09] <smoser> lamont, all the cloud-init yakkety are now verification-done
[18:09] <lamont> rbasak: ^^ I think that's everything for yakkety to land
[18:13] <smoser> rbasak, i just saw your comment on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633479 wrt git noise on precise.
[19:40] <nacc> cyphermox: you asked for some input from submitter in LP: #1634689 but a different user responded (and did't change the bug state). Can you take a look at your convenience?
[19:52] <nacc> hallyn: would you be able to comment if the suggested fix in LP: #1618899 is appropriate?
[19:55] <infinity> nacc: Who/what is changing sudoers?
[19:58] <nacc> infinity: a fair question! i'll ask in the bug, it does seem like there must be some local modification to get that prompt
[19:59] <infinity> nacc: Commented.
[19:59] <infinity> See stuff in the vm-builder source like:
[19:59] <infinity>         logging.info("Running ec2 postinstall")
[19:59] <infinity>         self.install_from_template('/etc/ec2_version', 'ec2_version', { 'version' : self.context.ec2
[19:59] <infinity> _version } )
[20:00] <infinity>         self.install_from_template('/etc/ssh/sshd_config', 'sshd_config')
[20:00] <infinity>         self.install_from_template('/etc/sudoers', 'sudoers')
[20:00] <nacc> infinity: thanks!
[20:00] <nacc> yep
[20:00] <infinity> nacc: If vm-builder is altering conffiles (ick), then dist-upgrading over those altered conffiles won't exactly make things better.
[20:00] <nacc> infinity: absolutely agreed. Will see what the originator(s) say
[20:01] <infinity> nacc: In this case, what they say isn't super meaningful. ;)
[20:02] <nacc> infinity: yeah, i suppose that's true :)
[20:02] <infinity> nacc: You can see the templates in the source, and what they alter.  In the sudoers case, it's adding ubuntu=NOPASSWD, which should be a sudoers.d snippet instead.
[20:02] <infinity> nacc: In the sshd_config case, it's just gross.  Lots of changes, and no way to do that without mangling a conffile.
[20:03] <infinity> nacc: So, maybe the answer is to mangle conffiles *after* the dist-upgrade step, not before.  But even then, you're leaving end-users of the image with something that will prompt on upgrade, which sucks.
[20:04] <infinity> But, that bug seems to have existed pretty much forever, so meh.
[20:05] <nacc> right, it seems like the 'correct' fix to just the sudoer issue is probably sudoers.d?
[20:05] <infinity> Yeah.  But sshd_config will have exactly the same issue.
[20:05] <infinity> Oh, no it won't.
[20:05] <infinity> sshd_config isn't a conffile.
[20:06] <infinity> Handy.
[20:06] <nacc> heh
[20:06] <infinity> So, yeah.  Fixing the sudoers thing by slapping a snipper in .d would fix this bug.
[20:06] <infinity> snippet*
[20:06] <nacc> infinity: thanks for the help!
[20:07] <hallyn> nacc: fwiw the cloud image team are the ones afaik still using vmbuilder.  pushing gaughen to have her team maintain vmbuilder would seem prudent :)
[20:07] <hallyn> me, i tried to drop it for 14.04, but adt was at the time still using it.  presumably by now it has stopped.
[20:08] <nacc> hallyn: thanks! that was the context I was lacking (and poked you as the 'maintainer' in the package)
[20:08] <infinity> nacc: As an added bonus, it would modernize the sudoers in vm-builder images, which seem to have a template forked from forever ago.
[20:09] <infinity> hallyn: Do they, though?  All new releases at least use live-build/livecd-rootfs.
[20:09] <hallyn> infinity: last i knew yeah they were using it for something
[20:09] <nacc> gaughen --^ ?
[20:09] <gaughen> nacc, hallyn, infinity we are moving away from it
[20:09] <nacc> ok :)
[20:09] <gaughen> and the vmbuilder that is used is a rather old fork
[20:09] <hallyn> gaughen: toward livebuild?
[20:10] <hallyn> gaughen: there are no newer forks afaik :)
[20:10] <hallyn> nacc: so you could start with doing a fresh reverse depds check on vmbuilder,
[20:10] <hallyn> on the one hand it was a pretty clean solutoin and one day i think we'll want it back,
[20:10] <infinity> Well, even if we remove it from zesty, this bug is in xenial and trusty and needs fixing.
[20:10] <hallyn> but otoh it's unmaintained atm and (obviously) out of date
[20:11]  * infinity wonders if trusty's sudo speaks sudoers.d
[20:11] <hallyn> ok
[20:11] <hallyn> like i say i think we'll want it back someday (when cloud-images stop being a thing) :-)
[20:11] <infinity> It does.  Handy.
[20:12] <infinity> hallyn: Err, why would either of those things happen?
[20:12] <hallyn> i dunno, why would ubuntuone storage go away
[20:12] <infinity> Anyhow, I disagree heartily.
[20:12] <hallyn> we went from something the community could generate to something where community depends on someone else,
[20:12]  * nacc backs away slowly...
[20:12] <nacc> hallyn: infinity: gaughen: thanks for the help on this bug!
[20:12] <infinity> Even if we stopped producing the one thing that makes us more money than anything else, we'll be in a position to give people a way to do it "the way we did the official ones".
[20:13] <infinity> hallyn: Work is in place to make it a 1-command no-brainer to emulate our infra.
[20:13] <hallyn> agreed it seems unlikely, but the way we do the official ones is afaik secret sauce
[20:13] <hallyn> oh that'd be awesome
[20:13] <hallyn> no wait
[20:13] <hallyn> is it based on snappy?
[20:13] <infinity> No.
[20:14] <infinity> I mean, there will be snap-based images too, but that's not what I was refering to.
[20:14] <hallyn> cool, that'll be awesome to see
[20:15] <hallyn> then all the more reason i should offer nacc:  hey nacc, if you manage to drop vmbuilder from the archive before feb, and if you're in bruseels for fosdem, i'll buy you a beer and a waffle.
[20:15] <infinity> nacc: So, anyway, short story from my investigation: sudoers.tmpl in vm-builder is wildly out of date anyway, and sudo in both trusty and xenial supports sudoers.d, so drop the sudoers templates, add a template for /etc/sudoers.d/ubuntu that includes just the bottom bit of the template, test, win.
[20:16] <sarnold> a beer -and- a waffle? nice
[20:16] <infinity> nacc: And by all means, also file a removal request for vm-builder from zesty if no one cares to maintain it and gaughen is sure it's not being used in zesty.
[20:16] <gaughen> nacc, we can double check with Odd_Bloke so we're 200% sure
[20:43] <gaughen> nacc, will send a note and cc you.
[21:20] <nacc> hallyn: infinity: gaughen: ack on all that, thanks!
[23:24] <nacc> so is it just me, or is the current assignee of LP: #1299186 spam?


[06:59] <ikonia> @mark #ubuntu thisweekinlinux unacceptable quit message
[21:01] <oerheks> hi, please remove buzie from #u
[21:01] <SlidingHorn> lol we all joined.
[21:01] <SlidingHorn> ops call from ubottu didn't respond
[21:01] <leftyfb> Please remove bugzie. He is currently violating COC and is generally toxic to the support channel
[21:02] <SlidingHorn> huh??     What you want to do is try to steer whoever back on track, failing that generally calling ops/poking here/whatever, then fully disengage and ignore him.  That last step can even make whoever get bored and go away as
[21:13] <Unit193> they're getting no reaction.
[21:18] <leftyfb> Unit193: you don't get it. Go through the logs. Every single person in that channel who helps the most, about a dozen of us have tried to de-escalate, reminded of COC, asked to stop, been rediculed, called names and have all requested the removal of this person multiple times over the course of months. We have been told he is a known problem and there's nothing anyone is willing to do about it but to just ignore it. That's fine except this
[21:18] <leftyfb> kid is constantly swearing, and more importantly, giving VERY wrong and damaging advice to people who don't know better. But yeah, it's our problem. You're right. We'll just let him be. Nothing to see here. Move along.
[21:18] <valorie> baiting a troll is generally not a good idea
[21:18] <leftyfb> This is well beyond baiting a troll
[21:18] <leftyfb> WELL beyond it
[21:18] <Unit193> leftyfb: I never said you were the problem and not him...
[21:19] <leftyfb> I have been told this many timea by the ops innthi channel we every time I request his removal
[21:21] <SlidingHorn> just now in -discuss:  17:20 < bugzie> I will evade that ban btw
[21:21] <el> he will
[21:22] <el> and likely have a tantrum about this namespace outside of this namespace because people with staff cloaks removed him
[21:22] <el> there'll probably be more trolls join
[21:23] <SlidingHorn> I think the general point we're trying to make is that this wouldn't have been as bad had action been taken earlier
[21:23] <el> except it would have been
[21:23] <el> he tends to return more combative
[21:24] <leftyfb> el: so your solution to managing trolls is to do nothing because "there's always more where that came from" and "he'll just be back"
[21:24] <el> not at all.
[21:30] <el> opping is a balancing act, it's not about nitpicking and scolding people then banning them when they get defensive
[21:32] <SlidingHorn> I can understand that, but one could hardly call the recognition of that user's indiscretions "nitpicking" - it was constant and blatant disregard, as well as dangerous to users
[21:33] <leftyfb> el: that excuse does not apply when this troll is blatent, self-aditting, dangerous, consistent and you have received multiple reports from multiple reputable people over the course of months. He and everyone else is begging you yo ban him.
[21:34] <leftyfb> and yet
[21:34] <leftyfb> I have seen people come in for the first time, swear twice and been removed. This guy has been doing it for months and laughing in our faces and nothing happens
[21:35] <leftyfb> and that's just one problem with him
[21:35] <el> and he has been removed multiple times
[21:37] <leftyfb> please continue doing so. We are all begging you. Including him.
[21:37] <leftyfb> el: also, I've been in there for about a year and haven't seen him removed once.
[21:37] <el> he has definitely been removed multiple times
[21:38] <leftyfb> why won't you ban him now?
[21:38] <Unit193> (Note, he's gone by a few different names.)
[21:38] <leftyfb> can you just answer that?
[21:39] <leftyfb> I understand ban evading. This person, in the past year or so since I've been actively participating in #ubuntu, this particular person and their persona has not been banned.
[21:39] <leftyfb> After dozens of requests
[21:39] <leftyfb> from me, him and multiple others
[21:39] <el> he is banned now
[21:39] <el> unless he's returned and we're too engrossed by being told how much we fail
[21:40] <leftyfb> I apologize. I did not notice
[21:40] <leftyfb> I thank you very much
[21:41] <SlidingHorn> I'll continue any thoughts on the topic in -discuss - don't want to idle in here...
[21:41] <oerheks> good point
[21:41] <leftyfb> ditto. Thank you again
[21:42] <Unit193> They need to track bans better if they honestly think that..