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