18:00:01 <sgallagh> #startmeeting FESCO (2015-07-22)
18:00:01 <zodbot> Meeting started Wed Jul 22 18:00:01 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <sgallagh> #meetingname fesco
18:00:01 <zodbot> The meeting name has been set to 'fesco'
18:00:01 <sgallagh> #chair ajax dgilmore hguemar jwb nirik paragan rishi thozza sgallagh
18:00:01 <sgallagh> #topic init process
18:00:02 <zodbot> Current chairs: ajax dgilmore hguemar jwb nirik paragan rishi sgallagh thozza
18:00:05 <sgallagh> .hello sgallagh
18:00:08 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:00:10 <jwb> present
18:00:12 <paragan> Hi
18:00:27 <dgilmore> hola
18:01:07 <ajax> howdy
18:02:07 <nirik> morning
18:02:52 <sgallagh> Sorry for the late agenda today, folks.
18:04:32 <sgallagh> OK, I guess we'll get started
18:04:40 <sgallagh> Follow-ups:
18:04:44 <sgallagh> #topic #1462 RPM Weak Dependencies and the install media compose process
18:04:44 <sgallagh> .fesco 1462
18:04:46 <zodbot> sgallagh: #1462 (RPM Weak Dependencies and the install media compose process) – FESCo - https://fedorahosted.org/fesco/ticket/1462
18:04:59 * nirik is fine with the proposal there.
18:05:41 * paragan also +1
18:05:51 <ajax> assuming "the proposal" there means the "advise" clause, yeah, me too
18:06:06 <sgallagh> ajax: See comment #3
18:06:09 <dgilmore> I spoke with james about how yum deals with things
18:06:27 <dgilmore> he was not opposed to adding support to yum to include reccomends and suggests
18:06:33 <dgilmore> or either
18:06:55 <jwb> that seems unlikely to land in time for f23 compose?
18:07:03 <sgallagh> That seems like an awfully big RFE for something that is effectively EOL
18:07:25 <dgilmore> jwb: for the first yes
18:07:39 <jwb> then it seems pointless if the eventual goal is to move the compsoe tools to use dnf
18:07:46 <dgilmore> but potentially Alpha but at worst Beta
18:07:47 <jwb> it's just going to delay that change over
18:08:00 <dgilmore> jwb: not at all
18:08:19 <jwb> your conversation style is confusing me today
18:08:20 <dgilmore> compose tools will not switch to dnf until f24 or f25
18:08:39 <dgilmore> we can take advantage of weak dependencies now
18:08:44 <sgallagh> I suppose a simplistic approach would be to just patch yum to treat Recommends: as synonymous with "Requires:": though
18:09:09 <dgilmore> jwb: it is no different to normal
18:09:17 <dgilmore> at least not intentionally different
18:09:58 <dgilmore> if we want to fully support weak deps in f23 we can
18:10:43 <nirik> it seems a lot of work for something thats just going to get replaced, but ok...
18:11:45 <sgallagh> /me sees if gepetto is around
18:13:36 <sgallagh> Doesn't seem like it
18:14:41 <sgallagh> OK, so how do we want to proceed here?
18:15:10 <sgallagh> If the yum maintainer wants to commit to adding this functionality by Beta release, I suppose I won't tell him not to
18:15:26 <ajax> well, let him if he wants
18:15:26 <jwb> i think it's irrelevant to the ticket tbh
18:15:32 <nirik> yeah.
18:15:50 <jwb> given the current proposal is "yeah, just tell people to watch out" if this lands it just means they have less to watch out for
18:15:50 <ajax> all that changes is the tone of the email from "this will be necessary" to "this may be necessary"
18:15:58 <sgallagh> jwb: Fair enough
18:16:05 <nirik> right. just note that possibility in the email.
18:16:47 * dgilmore does not matter much either way
18:16:53 <sgallagh> So... votes on the proposal from comment #3?
18:16:57 <jwb> +1
18:16:58 <ajax> +1
18:17:02 <sgallagh> +1
18:17:05 <paragan> +1
18:17:34 <dgilmore> 0
18:17:45 <sgallagh> Assuming nirik's +1 from earlier carries over: motion passes
18:18:07 <sgallagh> #agreed Draft a devel-announce list email describing the situation with weak dependencies and image generation and the workaround of explicitly adding missing dependencies into the spin kickstart file. (+5, 1, -0)
18:18:08 <nirik> sure, yeah, +1
18:18:34 <sgallagh> Can I get a volunteer to send that email (I'm on PTO for the rest of the week immediately following this meeting)
18:19:32 * nirik is swamped, but can try and do it anyhow.
18:19:45 <sgallagh> Anyone less swamped than nirik?
18:19:57 <sgallagh> (I know exactly how tough things are in Infra and Rel-eng today)
18:21:19 <ajax> sgallagh: i can
18:21:32 <ajax> have a lot of email to write anyway, what's one more
18:21:40 <sgallagh> ajax: Thanks
18:21:57 <sgallagh> #action ajax to send weak-dependency announcement
18:22:23 <nirik> thanks ajax
18:22:39 <sgallagh> New Business:
18:22:43 <sgallagh> #topic #1463 upgrades for F23 and beyond
18:22:43 <sgallagh> .fesco 1463
18:22:45 <zodbot> sgallagh: #1463 (upgrades for F23 and beyond) – FESCo - https://fedorahosted.org/fesco/ticket/1463
18:24:07 <sgallagh> So we're in kind of a transitional state here.
18:24:15 <nirik> I think the plugin is fine, but it needs either dnf folks willing to pull it in and maintain it, or someone else willing to maintain it seperately
18:24:28 <sgallagh> Fedup is effectively retired, but the dnf plugin is rather fresh out of the oven
18:24:39 <nirik> and has no real maintainer/isn't in fedora yet
18:24:43 <sgallagh> Right
18:24:49 * zbyszek is preparing a Package review request
18:25:25 * number80 waves
18:25:35 <sgallagh> zbyszek: By that, do you mean you plan to be the maintainer of the upgrade path?
18:25:37 <jwb> then we have the gnome people planning on doing their own thing
18:25:43 <jwb> so...
18:25:57 <sgallagh> They plan to have packagekit be able to handle this
18:26:11 <jwb> via gnome software
18:26:13 <zbyszek> sgallagh: I wouldn't say that much. I was hoping wwoods would continue doing that
18:26:21 <sgallagh> jwb: You have that backwards, I think
18:26:31 <jwb> zbyszek, it is my understanding that wwoods clearly said he wasn't
18:26:34 <sgallagh> GNOME Software would be a front-end on top of PackageKit API to do the work
18:26:43 <jwb> right.
18:26:54 <jwb> which is pretty much "their own thing"
18:26:56 <sgallagh> Hopefully, PackageKit will just pull in the implementation we do in DNF
18:27:13 <sgallagh> I'll be talking with cschaller and co. about that
18:27:18 <nirik> they didn't want to do that because they wanted "cross platform"
18:27:25 <jwb> correct
18:27:31 <nirik> sorry, 'cross distro'
18:27:55 <sgallagh> Sure, but if we can implement it as a plugin, maybe it still works.
18:28:05 <sgallagh> The conversation hasn't been had yet
18:28:24 <jwb> so maybe we should actually have it before we go deciding anything
18:28:30 <nirik> so, I think the next steps here are to talk with dnf folks... see if they want to maintain this in dnf-plugins-core or not.
18:28:37 <zbyszek> jwb: I thought that wwoods said that he is not willing to maintain fedup
18:28:47 <sgallagh> jwb: Sure, nothing says this has to be decided today.
18:28:57 <wwoods> yeah. no.
18:29:09 <sgallagh> wwoods: Could you clarify?
18:29:23 <sgallagh> "No you don't want to maintain" it or "No you didn't say that"
18:29:24 <wwoods> sgallagh: sure. did you read the email linked from the ticket?
18:30:09 <sgallagh> Yes, sorry. Paged out of my brain.
18:30:24 <sgallagh> OK, so fedup is dead, long live ???
18:30:25 <wwoods> I'm not going to spend any more time on fedup, if I can help it. It's broken by design, and any time spent on fedup would be better spent on a replacement.
18:31:26 <nirik> wwoods: are you able to spend any time on the replacement? (more than you already have that is)
18:31:29 <wwoods> well, dnf-plugin-fedup is the prototype replacement
18:31:58 <wwoods> it already works, mostly, although it turns out there's some rough edges around the Offline Updates spec
18:32:06 <sgallagh> I presume the problem with standardizing on PackageKit as the way forward is that the Workstation folks won't have it ready in time?
18:32:35 <nirik> sure, but are you able to help solve those issues/maintain it ? or you want to hand the prototype off to some others to do that?
18:32:39 <sgallagh> Because I'm not really thrilled with the idea of changing upgrade methods in F23 and again in F24
18:32:45 <wwoods> Here's a thread about offline updates from systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2015-July/033605.html
18:32:51 <nirik> sgallagh: right. they have no people to work on it this cycle
18:32:54 <wwoods> oh hey, that's zbyszek
18:33:48 <Rastus_Vernon> Is changing upgrade methods in F23 and then again in F24 better than using FedUp for one more release?
18:34:03 <sgallagh> So I guess my main question is whether it's worth hanging on to fedup for one more cycle until we have a single solution in PackageKit.
18:34:12 <gholms> That would involve someone maintaining fedup for another release.
18:34:14 <sgallagh> Rastus_Vernon: Exactly
18:34:22 <wwoods> here's where some stuff that dnf-plugin-fedup needed is going upstream:
18:34:23 <wwoods> https://github.com/rpm-software-management/dnf/pull/281
18:34:27 <wwoods> https://github.com/rpm-software-management/dnf/pull/313
18:34:46 * nirik isn't sure the packagekit solution will work for everyone, but I guess I dont know enough about it.
18:35:03 <nirik> I mean at least it would need a non gui version for headless/server machines.
18:35:14 <sgallagh> nirik: We already have a non-GUI packagekit on Fedora Server :)
18:35:16 <wwoods> I don't know about "standardizing on packagekit", but that's not what I'm talking about as a replacement
18:35:16 <dgilmore> nirik: I have the same thoughts
18:35:19 <sgallagh> And have since its inception
18:35:47 <nirik> sgallagh: yes, but this upgrade setup... needs gnome-software? do you have that installed too?
18:35:57 <sgallagh> wwoods: I don't like the idea of us shipping two competing replacements
18:36:10 <sgallagh> nirik: I don't think it does, or should.
18:36:22 <wwoods> as for hanging on to fedup: the design is flawed in such a way that it has seriously nasty problems that are very, very hard to debug
18:36:23 <sgallagh> I think g-s is going to be consuming a PackageKit API and making it pretty
18:36:25 <dgilmore> sgallagh: I am okay with trying a few options to see what sticks
18:36:26 <wwoods> mostly involving systemd
18:36:47 <wwoods> the systemd team is unwilling to support fedup's behavior
18:37:25 * nirik likes the idea of no longer making upgrade images.
18:37:31 <wwoods> and, having discussed it with them, I agree that it turns out that fedup *is* doing things completely wrong
18:37:37 <dgilmore> wwoods: is that fedup's fault? or systemd not being co-operative?
18:38:02 <sgallagh> wwoods: OK, so let's assume that fedup is gone, no matter what.
18:38:06 <wwoods> I'm not willing to spend weeks chasing down upgrade problems for F23
18:38:27 <sgallagh> Is it sensible for us to put a resource on the DNF plugin approach or to try to help the Workstation guys resource their solution sooner?
18:38:31 <wwoods> dgilmore: fedup's fault; upgrade.img is a bad idea
18:38:56 <sgallagh> And by "put a resource on" I mean "ask whoever is doing the work to adjust focus"
18:40:09 <wwoods> I don't really know who to talk to, or where to have the discussion, but it seems sensible to me that whatever tool handles system updates should also be responsible for upgrades
18:40:13 <jwb> that's the problem.  there is no "whoever" at the moment iirc
18:40:13 <dgilmore> wwoods: okay, I can see cases where we will need to run things in a newer environment. usrmove, or needs a newer kernel
18:40:34 <sgallagh> jwb: It sounded like zbyszek was volunteering at least to some degree.
18:40:40 <wwoods> dgilmore: usrmove was handled by scripts in dracut, which run during the first boot after the upgrade transaction completes
18:40:45 <wwoods> it worked just fine
18:40:48 <jwb> sgallagh, er... to work on packagekit?
18:40:51 <jwb> i don't think so
18:41:04 <sgallagh> jwb: No, volunteering to work on upgrades in some capacity.
18:41:25 <zbyszek> sgallagh: yes
18:41:36 <jwb> that doesn't necessarily map to "work on what workstation is planning"
18:41:39 <wwoods> the Offline Updates spec needs some honing to handle system upgrades
18:41:46 <sgallagh> jwb: You're twisting my words a bit.
18:42:09 <sgallagh> I'm not necessarily saying "do whatever WS wants". I mean that we should make sure there's only one final implementation to support
18:42:14 <jwb> you proposed a question with two solutions, then offered someone more likely to do only one
18:42:35 <sgallagh> And if their implementation *must* use PackageKit, then at least figure out how to make the implementation function as a backend
18:43:04 <nirik> I'm not sure how that could work.
18:43:07 <sgallagh> *backend for PackageKit
18:43:12 <wwoods> I'm willing to work on integrating dnf-plugin-fedup into DNF itself, or getting it to a place where it's supportable as the Official Upgrade Solution (for non-PackageKit systems, anyway)
18:43:26 <sgallagh> nirik: PackageKit already backends different depsolvers and different packaging formats. I doubt it's completely alien.
18:43:44 <nirik> sgallagh: yes, but if there's something tied to dnf, then it's unlikely to work on say... debian.
18:43:54 <nirik> which I gather is something they want
18:44:04 <jwb> i think packagekit uses hawkey, which is also what dnf uses, but it doesn't use dnf directly?
18:44:06 <nirik> anyhow, it's all handwavy
18:44:14 <jwb> at least in terms of depsolving.  i could be mistaken
18:44:15 <nirik> wwoods: sounds great to me. :)
18:44:29 <dgilmore> jwb: I believe you are right
18:44:55 <wwoods> one caveat though: I won't be the *maintainer* for this code, long-term
18:44:59 <sgallagh> jwb: I think it does, but I think that's also because it's convenient to do so. I think the plugin interface *could* use DNF directly if they wanted it to.
18:45:02 <nirik> wwoods: dnf-plugin-fedup uses distro-sync right? so it does downgrades too possibly?
18:45:07 <sgallagh> But using the API directly made more sense
18:45:19 <wwoods> nirik: it can use distro-sync, and yes, it could probably do downgrades if you wanted
18:45:25 <nirik> ok.
18:45:37 * nirik thinks it should, would solve a number of issues
18:45:56 <jwb> nirik, downgrades meaning... go from f23 -> f22?
18:46:18 <sgallagh> jwb: I think he means deal with cases where someone has newer packages on F22 than F23
18:46:26 <sgallagh> Like if they have updates-testing enabled, for example
18:46:41 <jwb> oh, so really "packager mistakes"
18:46:46 <wwoods> oh - doesn't DNF just do that by default anyway?
18:47:00 <sgallagh> jwb: That's not necessarily a packager mistake. Freezes can cause that
18:47:12 <nirik> jwb: no. yeah, that...
18:47:23 <nirik> if the f23 version is 'older' use it anyhow
18:47:30 <jwb> it's a shame that our tools cause such problems.  seems like something we could solve with software
18:47:49 <nirik> wwoods: no, only distro-sync, upgrade doesn't,, it just ignores the older ones.
18:47:56 <nirik> indeed
18:48:04 <wwoods> nirik: "should upgrades do distro-sync by default" is a question of policy, though
18:48:20 <nirik> sure, and a sidetrack, sorry
18:49:12 <wwoods> nirik: well, only partly a side-track; determining acceptance criteria for a fedup replacement means you have to know what that policy is
18:49:49 <sgallagh> OK, so given the availability of resources, I guess our only real approach for F23 must be to take the dnf plugin from PoC to production (whether it remains as a plugin or is mainlined is basically immaterial)
18:50:04 <nirik> sure. fedup did not distro-sync. I think a replacement should do so because it would prevent a number of problems I have seen people hit
18:50:13 <nirik> sgallagh: right
18:51:05 <sgallagh> I still plan to talk to the Workstation folks about seeing if they can try to work with this implementation (or develop a shared library, etc.) so they aren't building a completely divergent implementation and making it harder to support.
18:51:06 <wwoods> dnf-plugin-fedup has a --distro-sync flag, at least, but it's not the default
18:52:30 <zbyszek> Whether to use --distro-sync seems to be something which could be decided when we have more experience
18:52:31 <wwoods> it could probably upgrade from media, but there's not built-in support for that - you'd have to add the media as a repo
18:52:32 <jwb> we could just not support upgrades
18:52:37 <jwb> for one release
18:52:59 <sgallagh> jwb: -1
18:53:07 <nirik> wwoods: there's no media that would work for that, aside the server dvd...
18:53:09 <sgallagh> I think that would be too painful for our users
18:53:22 <nirik> jwb: or say 'use dnf distro-sync'
18:53:27 <jwb> nirik, right
18:53:37 <nirik> (but we have explicitly not wanted people to do that in the past)
18:53:55 <sgallagh> Sidebar: can we reuse the fedup binary to at least maintain the same UX for one release?
18:54:07 <sgallagh> Even if all it becomes is a script to execute the new approach
18:54:21 <wwoods> if dnf had an '--offline-updates' flag, dnf-plugin-fedup would be exactly equivalent to "dnf upgrade --releasever=23 --offline-update"
18:54:32 <wwoods> sgallagh: no
18:54:45 <jwb> sgallagh, definitely no
18:54:45 <wwoods> `fedup` uses yum as a backend, for one thing
18:54:57 <nirik> perhaps dnf-plugin-fedup could obsolete/provide fedup and have a small wrapper script ?
18:55:07 <sgallagh> nirik: That's pretty much what I was just trying to say
18:55:13 <wwoods> someone could certainly design a wrapper that provided the same CLI
18:55:51 <wwoods> or at least a similar one
18:55:52 <sgallagh> wwoods: Yeah, that's what I meant above. By "binary" I really just meant /usr/bin/fedup
18:56:03 <zbyszek> fedup has lots of options, might be better to just document the two simple replacement commands.
18:56:28 <wwoods> zbyszek: yeah, that was my opinion
18:56:33 <wwoods> that's why I didn't write one
18:57:23 <sgallagh> OK, so is there anything for FESCo to do here? We're coming to the top of the hour.
18:57:42 <sgallagh> It sounds like "Let wwoods and zbyszek do their thing" is our best path forwards for now.
18:57:45 <nirik> should we file a change on this?
18:57:57 <sgallagh> nirik: Yes, most definitely
18:57:57 <nirik> so it has press at least.
18:58:16 <wwoods> zbyszek: are you a DNF developer? I'd assumed you were mostly on systemd stuff
18:58:17 <jwb> sgallagh, you should probably rope stickster into your conversation, given he's the liasion
18:58:25 <sgallagh> jwb: Ack
18:58:39 <zbyszek> wwoods: no, not a dnf developer, so far.
18:59:24 <wwoods> because someone should ask the DNF team how/whether they are willing to integrate this into DNF
19:00:04 <paragan> generally user contributed plugins go to dnf-plugins-extras project
19:00:10 <wwoods> early discussion on the subject indicates at least one dev doesn't want 'fedup' in DNF: https://github.com/rpm-software-management/dnf/pull/281#issuecomment-106794683
19:00:37 <ajax> so we're at like the 40 minute mark here
19:01:11 <nirik> wwoods / zbyszek: can you talk with dnf maintainers and come back next week and let us know how discussions went?
19:01:14 <wwoods> OTOH rholy is amenable to offline-updates support in DNF: https://github.com/rpm-software-management/dnf/pull/281#issuecomment-106843869
19:01:17 <nirik> or would you like fesco to go talk to them?
19:01:30 <wwoods> I would like FESCo to do so!
19:01:54 <nirik> ok, anyone like to take that as an action?
19:01:57 <sgallagh> wwoods: Would you prefer to see this in DNF proper or as a plugin in dnf-plugins-core (which is shipped by default)?
19:03:13 <wwoods> sgallagh: that sounds like a question for the DNF team, but if I were designing it I'd probably implement offline updates inside DNF itself and ship a plugin that provides a 'system-upgrade' command
19:03:36 <sgallagh> ok
19:04:06 <sgallagh> If this can wait until Monday, I'll talk with them. If someone wants to do so sooner, be my guest
19:05:47 <wwoods> I'm happy to talk to DNF folks about designs and implementation but I don't really have any authority to say how/whether/where they should implement this. Someone might need to.. I don't know.. try to steer their engineering efforts
19:06:15 <sgallagh> OK, I'll take a note to discuss this with rholy and jzeleny on Monday
19:06:35 <sgallagh> #action sgallagh to talk with rholy and jzeleny about incorporating distribution upgrades into DNF
19:06:56 <nirik> thanks sgallagh
19:07:06 <sgallagh> #topic Open Floor
19:07:12 <sgallagh> Anything for Open Floor?
19:07:24 <nirik> I wanted to note progress in the passphrase policy change.
19:07:29 <nirik> see ticket for details.
19:08:18 <sgallagh> Yeah, looks like the libpwquality and anaconda folks are on the same page, which is a good sign
19:09:04 <sgallagh> #info Passphrase policy work is moving along
19:09:21 <sgallagh> #link https://fedorahosted.org/fesco/ticket/1455
19:09:31 <sgallagh> Anything else?
19:09:43 <zbyszek> I was installing F22 today, and I noticed that Legal:PrivacyPolicy has not been updated. There were some discussions on the mailing list, stickster was working on an update iirc, but nothing happened...
19:10:06 <sgallagh> zbyszek: Not updated where?
19:10:17 <zbyszek> https://fedoraproject.org/wiki/Legal:PrivacyPolicy
19:10:29 <sgallagh> Ah
19:10:30 <zbyszek> This page is displayed by initial gnome setup
19:10:42 <zbyszek> "This Privacy Statement was last amended on August 14, 2008. "
19:10:53 <sgallagh> #info Privacy Policy statement hasn't been updated with recent proposed changes.
19:11:04 <sgallagh> Can someone talk to spot and stickster about that?
19:11:05 <stickster> zbyszek: This is waiting for review by a Real Lawyer; I'll ping again to see if we can get this unstuck.
19:11:18 <zbyszek> Ah, thanks.
19:11:18 <sgallagh> OK, that works
19:11:33 <sgallagh> #undo
19:11:33 <zodbot> Removing item from minutes: INFO by sgallagh at 19:10:53 : Privacy Policy statement hasn't been updated with recent proposed changes.
19:11:44 <sgallagh> #info Privacy Policy statement hasn't been updated due to being blocked on legal review.
19:12:04 <sgallagh> #action stickster to check with the lawyers on unsticking the Privacy Policy update
19:13:08 <nirik> thanks stickster
19:13:31 <sgallagh> #topic Next week's chair
19:13:43 <sgallagh> (Forgot to do this before Open Floor)
19:13:48 <sgallagh> Who wants it
19:14:38 <nirik> well, next week we should be in freeze, so hopefully things will be less hectic for me, so I can do it.
19:15:12 <sgallagh> #info nirik to chair next week's meeting
19:15:14 <sgallagh> Thanks, nirik
19:16:05 <sgallagh> OK, setting the fuse for 120s
19:18:28 <sgallagh> #endmeeting