#ubuntu-meeting-2 2016-03-01
<pitti> o/
<mdeslaur> hi!
<pitti> sorry for being late
<mdeslaur> nothing has happened so far
<mdeslaur> do we actually have anything to discuss
<mdeslaur> ?
<pitti> not from my side really
<pitti> TB reelection hinges on Mark, thanks for pinging him
<mdeslaur> ok, doesn't look like we have anything to discuss, so I'm calling it: meeting cancelled
 * mdeslaur -> lunch
<pitti> o/
<slangasek> kees: meeting was called 8 minutes ago, cancelled because nothing to discuss + waiting on Mark for reelection
<kees> slangasek: suspected :)
#ubuntu-meeting-2 2017-02-28
<mdeslaur> hi
<mdeslaur> slangasek, kees, stgraber: hi!
<slangasek> mdeslaur: hello!
<slangasek> who's chairing?
<mdeslaur> I am
<slangasek> cool
 * slangasek leans his chair back
<mdeslaur> #startmeeting
<meetingology> Meeting started Tue Feb 28 17:03:37 2017 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
 * stgraber waves
<mdeslaur> [topic] Apologies
<mdeslaur> No apologies
 * mdeslaur looks around for infinity
<kees> hola
<mdeslaur> [topic] Action review
<mdeslaur> hrm
<mdeslaur> hi infinity
<infinity> Oh hai.
<infinity> Are you already in progress?
<mdeslaur> yep
<mdeslaur> we're at the action review, you've arrived just in time :)
 * infinity sits quietly in the corner.
<mdeslaur> infinity to follow up with maas SRU exception
<mdeslaur> infinity: what's the status on your action items?
<infinity> Defer on MAAS, defer (but working on this week) seed/maint-check.
<mdeslaur> ack
<mdeslaur> slangasek: how about yours?
<slangasek> defer :/
<mdeslaur> ack
<mdeslaur> doko has an agenda item about a freeze exception for python2.6 and openjdk-9
<doko> that should be 3.6
<mdeslaur> doko: I'm a bit confused by the request...you want a freeze exception for zesty?
<mdeslaur> or do you want to upload what's in zesty to xenial and yakkety?
<doko> no, I want standing exceptions for python3.6 and openjdk-9 in xenial and yakkety
<doko> yes, exactly
<infinity> "Not used by any package builds" as in, there aren't any python3.6 extensions built in the archive?
<doko> correct. the only one I plan to do is python3-stdlib-extensions, just adding the tk and gdbm extensions from the standard lib for 3.6
<doko> this will be a space penalty of about 100k for 3.5 users
<infinity> This probably technically belongs more to the SRU team to ACK/NACK, but if there are no rdeps in the archive to worry about *and* no regressions in upstream tests, it's likely fine.
<mdeslaur> the new SRU process should handle updating to new versions
<doko> I'm fine to follow that one as well. just thought to get approval for the updates here
<infinity> Well, a couple of the people here are also there. :P
<infinity> And with that other hat on, I'm fine with it, so long as upstream tests don't regress.
<slangasek> yes, given that the TB previously punted these things to the SRU team as a whole, from my side the preferred process now is: 1) create a wiki page detailing the exception, 2) get the SRU team to review it
<doko> well, xenial has pre-releases ... so until the upload of the first upstream release, these could regress
<slangasek> sample exception wiki page: https://wiki.ubuntu.com/SnapcraftUpdates
<infinity> doko: I get your point, but it also seems like it would be poor form for an upstream test to regress between a pre-release and the final version. :P
<doko> well, then call it snapshots ... these are not even pre-releases ...
<infinity> (upstream BEHAVIOURs could change, and I acknowledge that's an issue, but not a huge one for non-default versions)
<doko> but let's see for the first run of the tests ...
<infinity> Upstream behaviours changing or not, though, I'm inclined to agree that an LTS should ship a proper upstream release, not a snapshot of who-knows-what.
 * slangasek nods
<mdeslaur> ok, next topic?
<infinity> [Add new agenda items above this line - include your name]
<infinity> Could be contentious.
<mdeslaur> hehe
<mdeslaur> [topic] Mailing list archive
<mdeslaur> rbasak asked on the list if the SRU team can accept NEW packages in stable releases
<infinity> Oh, yeah.  I didn't see that until just now.
<infinity> Notwithstanding Mark's attempt to take a 90 degree turn there, the answer is "it has to be an AA because permissions".
<infinity> Which I'd highlight rbasak on, but he's not in here.
<mdeslaur> I agree with sabdfl's response as a general recommendation, but there are a few packages there that are required in the archive
<kees> that's been fine in the psst, for some things
 * slangasek nods
<mdeslaur> infinity: so there is a permissions issue there?
<infinity> mdeslaur: Yeah, you just plain can't manipulate the NEW queue without ~ubuntu-archive.
<infinity> Quite intentionally.
<mdeslaur> ok, so I guess that answers the question
<mdeslaur> infinity: can you tell rbasak?
<mdeslaur> oh, you already are
<mdeslaur> ok, next topic
<mdeslaur> [topic] Community bugs
<mdeslaur> no open bugs
<mdeslaur> [topic] AOB
<mdeslaur> anybody have anything else they would like to discuss?
 * tsimonq2 waves
<tsimonq2> Just a quick thing.
<tsimonq2> Hey TB, I just wanted to shoot a quick question your way. You may have heard that Lubuntu is thinking about and working on moving to LXQt. Is this something that requires review and acceptance by the TB once we have something to work with, or can we just continue as is? We had a team member that dragged his feet on it and stopped progress, but I'm heading the subproject now, so anything the TB h
<tsimonq2> ad to say on it before might be outdated.
<mdeslaur> Is the move controversial where the TB needs to get involved?
<infinity> We don't need to be involved.  Framework changes happen.
<infinity> See KDE's move to plasma, etc.
<tsimonq2> Not necessarily, but it's essentially an overhaul of the whole DE.
<tsimonq2> Like, moving underlying framework.
<tsimonq2> infinity: Ok, that makes sense.
<slangasek> yeah, I don't think there's any sort of charter statement w/ the TB that defines Lubuntu must be "this" :)
<tsimonq2> Ok that's cool :)
<slangasek> if you said "we're going to make Lubuntu's metapackage a clone of Kubuntu's", I would go "um"
<tsimonq2> Yeah :P
<slangasek> but technologies change
<tsimonq2> Alright, fair enough. :)
<tsimonq2> Thanks for your time. :) o/
<mdeslaur> tsimonq2: thanks!
<mdeslaur> Anybody have anything else they would like to discuss?
<infinity> tsimonq2: Massive bonus points if you can eliminate --no-follow-recommends while you're at it.
<infinity> tsimonq2: It's a huge pain in the butt.
<tsimonq2> infinity: Where is this? :P
<stgraber> mdeslaur: I don't
<infinity> tsimonq2: Your seeds don't follow recommends.  You're the only flavour that doesn't now.  We can discuss out of band another time.
<mdeslaur> [topic] Next chair
<mdeslaur> slangasek with stgraber as backup
<slangasek> ack
<mdeslaur> that's all folks!
<mdeslaur> #endmeeting
<meetingology> Meeting ended Tue Feb 28 17:30:34 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2017/ubuntu-meeting-2.2017-02-28-17.03.moin.txt
 * infinity read that as "slangasek with stgraber as backpack", which was quite the mental image.
<mdeslaur> thanks everyone
<mdeslaur> infinity: lol :)
<slangasek> heh
<kees> *wave* thanks!
<stgraber> thanks!
#ubuntu-meeting-2 2018-02-27
<mdeslaur> \o
 * slangasek waves
<slangasek> I think we have some topics this week
<slangasek> hopefully we also have a chair
<mdeslaur> hi infinity!
 * slangasek waves
<infinity> Oh look, I'm the chair.
<infinity> #startmeeting Ubuntu Technical Board
<meetingology> Meeting started Tue Feb 27 20:01:21 2018 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<infinity> So, who's here?  Do we have quorum?
 * stgraber waves
<infinity> We do!
<mdeslaur> wow! hi stgraber!
<infinity> #topic Action Review
<infinity> MaaS thingee: I've still entirely failed to review the current state.  I should make a personal TODO item to get that done.
<infinity> support-status thingee: Superseded by recent SRUs.
<infinity> slangasek: Bugs thingee?
<slangasek> infinity: continues to be backlogged
<infinity> Budgie LTS status, that seems to have been handled on-list, unless we want a quorum vote taken?
<mdeslaur> nah
<infinity> I'm +1 to mdeslaur and stgraber's cumulative +2
<slangasek> I had also +1'ed it, mind
<slangasek> I think we're good
<infinity> Kay.
<infinity> That brings up another topic, which is that we should probably send out a call for LTSiness and renew all the flavours.
<slangasek> under TB or Release Team hat?
<infinity> Yes.
<tsimonq2> Did I hear "flavor"? :)
<slangasek> is that an [action] for you? :)
<infinity> TB needs to approve them, but if we're okay with the status quo, then just release team.
<infinity> The one that I'm currently not okay with is kylin at 5y, since that used to be based on them being based on Ubuntu, which they aren't anymore.
<infinity> I think they're not Xubuntu based?
<infinity> IIRC.
<infinity> s/not/now/
<tsimonq2> (Ubuntu MATE)
<tsimonq2> UKUI is a fork of MATE
<infinity> Ahh, or that.
<infinity> Either way, they're now based on a 3y flavour, and unless they really think they can handle the extra 2y on their own (which I'd strongly discourage), we should drop them to 3y.
<slangasek> full ack
<slangasek> infinity: where are you seeing this as 5y, btw?
<infinity> slangasek: maintenance-check.py in lp:ubuntu-archive-publishing
<infinity>     DISTRO_NAMES = [
<infinity>         "ubuntu",
<infinity>         "ubuntukylin",
<infinity>         ]
<infinity>     DISTRO_NAMES_SHORT = [
<infinity>         "kubuntu",
<infinity>         "lubuntu",
<infinity>         "ubuntu-budgie",
<infinity>         "ubuntu-mate",
<infinity>         "ubuntustudio",
<infinity>         "xubuntu",
<infinity>         ]
<infinity> So, kylin should move to short for Bionic, and Budgie needs to be added.
<infinity> And we need to get everyone to confirm the current status.
<slangasek> budge is there
<slangasek> i
<infinity> So it is.
<tsimonq2> One thing; if Lubuntu Next 18.04 should be regarded as a 9m rather than a 3y, is there anything that needs to be done on the release team or TB end?
<infinity> I think I'll JFDI the kylin move, then do the confirmation thing.
<slangasek> infinity: +1
<slangasek> infinity: seems you already declared Budgie LTS in October, according to the commit history ;)
<infinity> tsimonq2: lubuntu-next has its own seeds, right?
<infinity> Or is it in the lubuntu seed set?
<tsimonq2> infinity: Correct, but it's under the same branch as the other Lubuntu ones.
<tsimonq2> Right.
<slangasek> tsimonq2: do you intend lubuntu-next to release, this time?  Given that it's been daily-only in the past
<tsimonq2> Correct, that's the goal.
<tsimonq2> So the *-share-* and the *-gtk-* seeds under the Lubuntu branch should be 3y as normal, and *-qt-* should be 9m.
<infinity> Yeah, that'll take a little bit of mangling of maintenance-check.
<tsimonq2> But is the TB OK with that plan?
<infinity> I'm honestly not sure I see the point in you releasing it as kinda-supported before you switch it over to being the new hotness.
<slangasek> do we have precedent for a flavor releasing a "next" image as a release image?
<slangasek> I'm trying to recall what Kubuntu did with plasma
<infinity> No.
 * slangasek nods
<infinity> active and plasma never got released officially until the switch.
<slangasek> so I'd say there's some healthy skepticism about this plan
<slangasek> maybe tsimonq2 should propose it on the mailing list and we should discuss it further?
<tsimonq2> slangasek: The TB mailing list or the Release Team one?
<infinity> That said, regardless of the plan, maint-check will need a bit of a mangle because you're building both from the same seed set, unlike kubuntu that used another.
<slangasek> tsimonq2: TB, I think
<tsimonq2> infinity: If this is approved by the TB, I'll volunteer to take that on.
<tsimonq2> slangasek: Sure, I can do that by the next TB meeting.
<slangasek> yeah, I was going to say, it'd be great to have tsimonq2 submit the patch for maint-check :)
<infinity> It's not a hard mangle, per se.  Just needs a filter on the SUPPORTED=all bit.
<tsimonq2> Right, I can take care of that. :)
<infinity> You'll want supported=(all-next) and then supported-not-much=next
<infinity> And not-much.length=9m
<infinity> All pseudocode, obviously.
<tsimonq2> Sure, and I can look into it more myself.
<tsimonq2> Thanks.
<infinity> #action tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan
<meetingology> ACTION: tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan
<infinity> #topic Ubuntu MATE Software Boutique
<flexiondotorg> o/
<infinity> flexiondotorg: Oh hai.
<slangasek> hello!
<infinity> slangasek: You want to drive this bit?
<infinity> Because context.
<slangasek> well, I think I've mostly laid out my concerns on the mailing list
<slangasek> infinity, mdeslaur, stgraber: did you have a chance already to read that thread?
<slangasek> I can summarize, regardless
<infinity> I'm reading now.  But a summary would be nice.
<stgraber> I've read the thread pretty quickly as they came in
<slangasek> Ubuntu MATE Software Boutique allows push-button installation of packages from a variety of sources
<slangasek> including ppas, and third-party sources
<slangasek> some of which are configured by downloading the gpg keys over plaintext http
<slangasek> and none of these details are surfaced to the user when they choose this software for installation
<slangasek> so the concern is that this does not align with the TB-approved archive policy https://wiki.ubuntu.com/ExtensionRepositoryPolicy
<mdeslaur> third-party sources?
<slangasek> mdeslaur: I'd have to dig into the code for details; but it includes obvious ones like the upstream Google Chrome repository, and some less obvious ones for repos somewhere in India
<mdeslaur> ooh :(
<flexiondotorg> Those packages that Boutique installs from 3rd parties are always the official apt repos of the vendor.
<slangasek> like, something called 'enpass' which is a 'cross-platform, complete password management solution [...]'; can't think of any reason anyone might have concerns about the gpg key used to authenticate /that/ repo being downloaded from http://repo.sinew.in/keys/enpass-linux.key
<slangasek> flexiondotorg: yes, and we do not have cryptographic trust to any of those upstream repos
<infinity> Yeah, so, there are multiple concerns here for sure.
<mdeslaur> and we can't update them or revoke them if they are compromised, etc.
<infinity> The first is that the user doesn't appear to be reasonably informed.
<slangasek> so that's my summary of the current state
<slangasek> flexiondotorg: anything else that I've missed?
<infinity> The second is that those keys should be shipped in the package, not downloaded on demand.  So there's at least some claim that the developer of the package has vetted the key is the right one.
<flexiondotorg> The source of the packages is available from the Details along side each package.
<flexiondotorg> We also provide a page where every source is presented to the user.
<slangasek> flexiondotorg: yes; this is not the same thing as an in-band confirmation from the user before they change the archive security properties of their system
<flexiondotorg> infinity: I'm happy to ship keys with Boutique.
<slangasek> flexiondotorg: do you also ship apt pins?
<flexiondotorg> I'm happy to present a more prominent indication to users that packages are coming from a 3rd party and not supported by Ubuntu.
<slangasek> (I'm asking because I think that would be a good idea; third-party apt repos have terrible security implications and apt pinning can mitigate against certain kinds of accidents, but not against a truly malicious repo)
<flexiondotorg> We are not adding random PPAs or 3rd party repos. They are being vetted.
<flexiondotorg> And some of those repos can be replaced with snaps from the same vendors now. The snap support is landing soon.
<slangasek> flexiondotorg: but they're not being vetted by either the TB on behalf of the Ubuntu Developers, or by the user when they select for installation, and that's the problem from my perspective :)
<slangasek> flexiondotorg: to be clear, I don't want to ask you to cripple any functionality here
<slangasek> but I do think the security implications need to be surfaced to the user
<stgraber> sure but any of them being taken over by a malicious third party and all your users are screwed with no way for you to fix them, downloading those keys over http then makes it even worse as it becomes pretty easy for someone to just feed you some other keys they'd like you to trust...
<flexiondotorg> I understand. I'm keen to retain the functionality is a fashion the TB is comfortable with.
<flexiondotorg> I just wanted to make it clear we are being careful with the 3rd poarty repos we select.
<stgraber> For deb packages, I expect the minimum would be to have the GPG key in question in your package, ship apt pinning config so that they can't push any package other than what you expect AND you should still show a very clear message to the user that they're effectively trusting vendor XYZ with root on their system.
<infinity> ^-- I think that about sums it up for me.
<slangasek> right, +1
<flexiondotorg> I wasn't aware Boutique was doing anything it shouldn't. My only intention was to provide the software user want with an easy install.
<infinity> And that message can't be a one-time "I trust you to do stupid things for me", but triggered on any new repo enablement.
<flexiondotorg> I'm happy to ship keys in the application, if that is desirable.
<infinity> "I explicitly trust Google Chrome's repo" one day and "I also explicitly trust Dave's Janky PPA" the next.
<flexiondotorg> Boutique is a snap now. So we do have a means to act quickly should a repo become compromised in some fashion.
<flexiondotorg> We can notify users and provide corrective action.
<infinity> flexiondotorg: Shipping keys in the package is the easiest way to maintain a reasonable trust path.  It also makes it easier for you to revoke them in an SRU.
<flexiondotorg> As I said, it will land as a snap so we can revoke them promptly via an update should the need arise.
<infinity> (Has anyone else found it very difficult to correctly type the word "trust" ever since, oh, October 2013 or so?)
<mdeslaur> heh
<flexiondotorg> So, ship keys. Apt pinning. Up front indication that 3rd party packages are not supported by Ubuntu.
<flexiondotorg> Shipping keys and upfront indication are quick work. Apt pinning will take a little longer.
<infinity> flexiondotorg: Not just lack of support, but also indicating each time someone enables a new repo that they are explicitly trusting that non-Ubuntu repository with root on their system.
<stgraber> it's really not just that they're not supported by Ubuntu, I mean universe packages would kinda fit that description, it's more "I'm trusting that vendor with full root access to my system"
<flexiondotorg> Understood.
<infinity> flexiondotorg: Anyhow, I think the next action here would be for you to come up with a design plan, toss it at the mailing list for review, and move this forward there.
<infinity> I expect there might be some iteration.
<infinity> Though, happy to be proven wrong.
<flexiondotorg> OK
<infinity> #action flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
<meetingology> ACTION: flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
<infinity> Aaaand, on we go.
<infinity> #topic Mailing List Archives
<infinity> So, other than the bits we just talked about, there's a Kylin repo revisiting thing, that I think can be addressed on-list.
<infinity> And a PPU request.  Did anyone action that?
<infinity> slangasek: Did.
<infinity> Minus the colon.
<slangasek> yeah, about 30 minutes ago ;)
<infinity> Heh.
<infinity> #topic Community Bugs
<infinity> GUYS WE HAVE ONE.
<slangasek> OMG
<mdeslaur> WAT?
<slangasek> who wants it? :)
<stgraber> can't be
<slangasek> it's just another edit-acl
<infinity> "Adding people to that packageset depends on team reorg in the set of teams for Ubuntu Budgie development (or the creation of a new team for it), the Developer Membership Board will take care of the following steps."
<infinity> Looks like it's spinning wheels waiting on that, though?
<infinity> I mean, a packageset with no members seems pointless.
<slangasek> if it avoids the DMB blocking on the TB, it's not pointless IMHO
<infinity> That's fair.
<infinity> slangasek: All yours, if you want to spend the copious amount of time verifying that copy-paste and pasting it.
<infinity> #topic Chext Nair
<slangasek> e... d... i.... r... shoot
<infinity> Looketh like iz kees, mit mdeslaur backup.
<mdeslaur> ack
<infinity> #topic AOB
 * mdeslaur gives stink-eye to kees
<infinity> Anyone have any OB to gab about?
<infinity> Other than the minor excitement over having an actual meeting with stuff in it for once?
<slangasek> I do have one thing more
<infinity> Excellent.  Thing away.
<infinity> #topic Steve has a thing
<slangasek> I started a thread on ubuntu-devel to discuss policy around snaps preinstalled on Ubuntu images
<slangasek> I think this should eventually go to TB for signoff
<infinity> That it should.
<mdeslaur> +1
<slangasek> any preference on what form that should take?
<slangasek> should I put it on agenda for next meeting, or would you prefer email?
<infinity> One with an explicit sign-off from Mark that our jobs are safe if we dislike the plan.
<infinity> *cough*
<mdeslaur> heh
<infinity> But yes, I think on agenda and real-time discussion.
<slangasek> (I still need to incorporate feedback from the mailing list thread before submitting to TB)
<slangasek> ok
<infinity> Any other any other any other bidness?
<infinity> 3
<infinity> 2
<infinity> 1
<infinity> #endmeeting
<meetingology> Meeting ended Tue Feb 27 20:51:22 2018 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.2018-02-27-20.01.moin.txt
<slangasek> thanks, all!
<mdeslaur> thanks everyone
<infinity> Wiki updated, and I'm out.
#ubuntu-meeting-2 2018-03-01
<bashfulrobot> Good day everyone.
<bashfulrobot> Just popping in for my Ubuntu membership interview. Standing by as needed.
<bashfulrobot> Oops - wrong channel
#ubuntu-meeting-2 2020-02-25
 * vorlon waves
<mdeslaur> hi!
<vorlon> so no quorum?
<mdeslaur> doesn't look like it
