16:02:30 <geppetto> #startmeeting fpc
16:02:30 <geppetto> #meetingname fpc
16:02:30 <geppetto> #topic Roll Call
16:02:30 <geppetto> #chair mbooth
16:02:30 <zodbot> Meeting started Thu Jun  9 16:02:30 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:30 <zodbot> The meeting name has been set to 'fpc'
16:02:30 <zodbot> The meeting name has been set to 'fpc'
16:02:30 <zodbot> Current chairs: geppetto mbooth
16:02:30 <geppetto> Is the bot not here?
16:02:30 <geppetto> zodbot: hello?
16:02:31 <geppetto> nirik: Is there anyway to check if zodbot is alive?
16:02:31 <geppetto> Or turn it off and back on again
16:02:45 <geppetto> It is alive!
16:02:54 <nirik> :)
16:03:45 <mbooth> geppetto: Probably was busy in another channel disparaging us humans :-p
16:04:06 <geppetto> very possible
16:04:24 <geppetto> or helping take over the world, with the cats.
16:05:09 <geppetto> #chair racor
16:05:09 <zodbot> Current chairs: geppetto mbooth racor
16:06:02 <Rathann|Mobile> hi
16:07:39 <geppetto> #chair Rathann|Mobile
16:07:39 <zodbot> Current chairs: Rathann|Mobile geppetto mbooth racor
16:08:10 <geppetto> I really need to fix C-w, sigh
16:09:00 <geppetto> has anyone spoken to tibbs today?
16:09:38 <Rathann|Mobile> I think he was present in #fedora-devel earlier
16:09:49 <geppetto> Hey :)
16:09:54 <geppetto> #chair tibbs
16:09:54 <zodbot> Current chairs: Rathann|Mobile geppetto mbooth racor tibbs
16:10:09 <tibbs|w> Sorry, folks.
16:10:25 <geppetto> n/p
16:10:33 <geppetto> #topic Schedule
16:10:45 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/6XPLTOUDEASTLLXUGDUXZDVZPNVPYT4K/
16:10:56 <geppetto> #topic #629  Handling dirs. under /var/lock and /var/run in %files and images
16:11:01 <geppetto> .fpc 629
16:11:03 <zodbot> geppetto: #629 (Handling directories under /var/lock and /var/run in %files and base image) – fpc - https://fedorahosted.org/fpc/ticket/629
16:12:06 <linuxmodder> nb,   when you get a sec can you check message in -admin?
16:12:23 <tibbs|w> I think this is just a bug elsewhere.
16:13:44 <tibbs|w> In other words, something should make sure /run/lock and the /var/lock symlink exist.
16:13:47 <geppetto> So, I think .pid files should be ghost and not real.
16:14:00 <geppetto> Dirs. are pro bably better as real files, and then worked around for tmpfs breakage.
16:14:19 <geppetto> Yeh, that seems likely
16:14:44 <tibbs|w> I don't know that in general we can know at packaging time what lock files might be written.
16:16:46 <geppetto> yeh, those should also be like pid files I think
16:17:08 <geppetto> %ghost, where you can
16:17:31 <Rathann|Mobile> I'm +1 to rdieter_work's suggestion to use %ghost for lock files as well
16:17:41 <tibbs|w> Right, just to make sure that rpm -qf is useful as often as possible.
16:17:50 <Rathann|Mobile> but I'm not sure what's expected from the FPC in that ticket
16:17:56 * geppetto nods
16:18:44 <tibbs|w> Rathann|Mobile: at some level I think they want to confirm that /run/lock should always exist, so that it can be added to filesystem or whatever.
16:19:06 <tibbs|w> Currently, nothing actually owns /run/lock.
16:19:22 <Rathann|Mobile> I don't see that as a packaging guidelines issue, but as a bug somewhere
16:19:33 <tibbs|w> True, but we can still confirm.
16:19:43 <geppetto> sure, I'm happy to +1 both of those
16:20:00 <tibbs|w> Thing is, I don't know what would actually provide /run/lock.
16:20:31 <Rathann|Mobile> hm
16:20:45 <racor> filesystem ?
16:20:58 <tibbs|w> racor: That would be the obvious choice.
16:20:59 <Rathann|Mobile> +1
16:21:11 <tibbs|w> But currently it' appears to be created by /usr/lib/tempfiles.d/legacy.conf
16:21:20 <Rathann|Mobile> since it already owns /var/lock
16:21:20 <tibbs|w> Not sure what's legacy about /run/lock.
16:21:21 <geppetto> legacy?
16:21:23 <geppetto> yeh
16:21:49 <tibbs|w> filesystem itself does own /run.
16:22:12 <tibbs|w> But if it owned /run/whatever, that would just get mounted over when systemd creates the /run tmpfs filesystem.
16:22:38 <tibbs|w> So it's not really a simple thing.
16:24:18 <geppetto> Anyone got any ideas?
16:24:48 <tibbs|w> Anyway, I don't think it's entirely up to us to come up with the solution.  Honestly I don't know what containers are doing differently to cause this directory to not exist.
16:25:03 <geppetto> I wonder how much systemd would be happy re-creating the dir. structure under /run that is owned by packages
16:25:06 <Rathann|Mobile> does the issue in container images come from the fact that systemd-tmpfiles is not getting run?
16:25:06 <tibbs|w> If they don't have systemd doing its magic, then maybe having the dir in filesystem would work for them.
16:25:40 <geppetto> I assume this is before the container has been run for the first time, so yeh the tmpfiles stuff hasn't been run
16:26:14 <geppetto> So just adding it to filesystem might workaround the problem enough
16:27:00 <tibbs|w> I don't think we need to provide a solution, especially when we don't really understand at the moment why it's not working for them.
16:27:28 <geppetto> I guess that's fair :)
16:29:56 <tibbs|w> So, need a draft for %ghost'ing things when possible, and otherwise just suggest to them that /run/lock gets created properly.  If adding it to filesystem will help, I'll happily just do that.
16:30:07 <tibbs|w> My FPC TODO list is getting rather long at this point.
16:30:39 <geppetto> #action geppetto Draft for %ghost files when possible, on tmpfs.
16:30:46 <Rathann|Mobile> +1
16:30:48 <Rathann|Mobile> :)
16:31:18 <geppetto> #info /run/lock should just get fixed, maybe added to filesystem maybe somewhere else.
16:32:10 <Rathann|Mobile> ah hold on
16:32:19 <Rathann|Mobile> it fails at installation time (rpm -i)
16:32:30 <Rathann|Mobile> so yeah, it needs to be pre-created
16:32:42 <Rathann|Mobile> i.e. owned by filesystem or systemd
16:35:02 <Rathann|Mobile> looking at the linked bug https://bugzilla.redhat.com/show_bug.cgi?id=1341079 it'll get fixed in the affected package by moving the lock file one level up (to /run/opencryptopki)
16:35:40 <geppetto> that doesn't seem optimal
16:35:58 <racor> what? have these guys gone nuts?
16:36:03 <tibbs|w> Definitely suboptimal.
16:36:32 <tibbs|w> I guess they're trying to work around the issue in the packages they can change.
16:36:46 <tibbs|w> Personally I'd just own /var/lock in the package if I needed a workaround, but....
16:36:47 <geppetto> yeh
16:37:02 <tibbs|w> Or /run/lock.  Changing that habit is hard.
16:39:41 <geppetto> might want to mention that workaround in the BZ
16:39:46 <Rathann|Mobile> I have to step away for 5 mins
16:40:36 <geppetto> Anything else we want to try to do for this?
16:41:42 <tibbs|w> I don't think so.  We're kind of working on conjecture at this point because we don't know just what their container environment is or isn't running.
16:42:20 <tibbs|w> I'm sure someone, somewhere would complain if filesystem created a directory that will be hidden by an overmount in systemd, but.... these days we should be used to someone complaining.
16:43:12 <geppetto> yeh, whoever owns legacy should probably own the dir. too
16:43:34 <tibbs|w> To which "legacy" are you reverring?
16:43:53 <tibbs|w> You mean the tmpfiles.d legacy conf?  That's part of systemd.
16:43:58 <geppetto> the /usr/lib/tempfiles.d/legacy.conf
16:44:02 <Rathann|Mobile> ok I'm back
16:44:13 <geppetto> Yeh, so systemd should own that dir. then ... I think.
16:44:25 <tibbs|w> I think the lack of systemd is actually the problem here, but again, we don't really have all the info.
16:44:36 <tibbs|w> Maybe their container init process just needs to run tmpfiles.
16:44:51 <Rathann|Mobile> tibbs|w: the package fails to install
16:45:05 <tibbs|w> Rathann|Mobile: Yes, in a container that they've created.
16:45:36 <tibbs|w> If this was a general problem, how does anaconda ever get anything installed?
16:45:43 <tibbs|w> Or, am I really missing the point here?
16:46:21 <Rathann|Mobile> right, in a docker container
16:46:23 <tibbs|w> It's possible that hte problem is general, because they're the only package which actually owns a file in /run/lock so they're the first oones to run into some related problem.
16:46:27 <tibbs|w> Sorry for crap typing.
16:47:34 <geppetto> yeh
16:47:58 <tibbs|w> And if it's that, then note that we have kind of a weird problem.
16:48:03 <geppetto> I'd bet a lot of the old packages still use /var/lock ... I wouldn't be shocked if it was all of them
16:48:08 <tibbs|w> rpms can't really own files in an "ephemeral" filesystem.
16:48:49 <tibbs|w> So someone's going to have to look more deeply into this.  I don't think I can promise that I will be able to do it.
16:48:56 <geppetto> No, there are a few using /run/lock ... although it looks like more are still using /var/lock :)
16:49:57 <geppetto> Hmm ... a bunch of the ones using /run/lock also "own" /run/lock/
16:50:26 <geppetto> Actually, I think all the packages on f23 do
16:50:59 <geppetto> #info It appears all the packages using /run/lock/foo also own dir the "/run/lock/", which is a workaround for this issue.
16:51:33 <geppetto> Ok, hopefully someone can fix this.
16:51:38 <geppetto> #topic Open Floor
16:52:02 <tibbs|w> What was it?  Or did I miss something at the beginning?
16:52:24 <geppetto> ?
16:52:29 <geppetto> That was all the new tickets
16:52:42 <geppetto> We have the cassandra thing, and the resurrected ticket
16:52:51 <tibbs|w> Ah, OK, the thing I'm thinking of was just on the list.
16:53:07 <tibbs|w> The thing about the multilib fixed C headers.
16:53:14 <geppetto> #312?
16:53:21 <geppetto> Yeh, that's the zombie ticket
16:53:28 <tibbs|w> Ah, was that the one they resurrected?  Annoying.
16:53:32 <tibbs|w> I just closed the damn thing.
16:53:37 <geppetto> :)
16:54:09 <tibbs|w> Anyway, I believe I told them all they need to do.
16:54:38 <tibbs|w> They should make a separate package with their script and macro file, and if it is actually generally useful then I can add the dep to redhat-rpm-config.
16:56:35 <racor> tibbs|w: That's what they seem to be doing:https://bugzilla.redhat.com/show_bug.cgi?id=1344231
16:57:17 <tibbs|w> Then the resulting discussion about whether their method works or not should happen in that review, or in bugzilla tickets on that package after it's approved.
16:57:28 <tibbs|w> And once that's worked out, they can get back to us.
16:58:01 <tibbs|w> Or is someone waiting for us to tell them if their method works?  Because I'm not entirely sure we need to get involved with that.
16:58:11 <geppetto> sounds good
16:58:59 <tibbs|w> I know racor has run into this kind of thing before, so perhaps he has something to add.
17:00:00 <tibbs|w> And on another note, there was an edit which orionp made that nirik asked me to revert
17:00:19 <nirik> oh, there's more to that one...
17:00:21 <racor> tibbs|w: Yep, I've been dealing with this problem longer than Fedora exists ;)
17:00:43 <nirik> apparently sgallagh asked him to make it, but the link was supposed to go to a template in bugzilla but the bugzilla folks messed it up.
17:01:01 <tibbs|w> racor: Well, if you have opinions on how they're doing it, I guess it would be good to let them know before the issue gets back to us.
17:01:21 <tibbs|w> nirik: Well, if that gets worked out, just ping and I can un-revert the edit.
17:01:26 <nirik> sure
17:01:52 <jkurik> Hi FPC people, we are going to have F24 Final Go/No-Go meeting on this channel. When do you plan to end ?
17:02:15 <geppetto> jkurik: probably in the next 10 minutes
17:02:50 <geppetto> Does anyone want to talk about anything else?
17:03:35 <jkurik> geppetto: ok, thanks. We can wait for a while
17:04:37 <tibbs|w> jkurik: It does often take us two hours, but hopefully not today.
17:05:01 * nirik thinks the no-go won't take us long either
17:05:08 <jkurik> tibbs|w: we have this channel booked
17:05:15 <tibbs|w> I'm pretty much done.  Can someone update the various tiickets and bugzillas we're talked about?
17:05:28 <tibbs|w> I don't think I'll have time to do that until pretty late today.
17:07:06 <tibbs|w> Otherwise I'm done, and have another thousand things to do today, so I'm happy to roll this up.
17:07:26 <tibbs|w> But maybe one of us could look at the calendar and see why we don't have the channel booked for two hours.
17:07:34 <tibbs|w> Because I thought we did.
17:07:42 <Rathann|Mobile> me too
17:07:59 <tibbs|w> It could be a daylight savings time thing.
17:08:25 <geppetto> yeh, we should probably book for 2 hours
17:08:28 <geppetto> or at least 1.5
17:08:39 <geppetto> #action geppetto Book meeting channel for 2 hours
17:08:57 <geppetto> Ok, I'll end it in a minute then ... let jkurik have the channel
17:09:24 <jkurik> :)
17:09:43 <Rathann|Mobile> apparently the booking is for 1 hour only
17:10:30 <Rathann|Mobile> ok, I'm off, thanks
17:10:48 <geppetto> #endmeeting