17:02:43 <abadger1999> #startmeeting FPC
17:02:43 <zodbot> Meeting started Thu Jan 23 17:02:43 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:47 <sochotni> hah
17:02:47 <abadger1999> #meetingname FPC
17:02:47 <zodbot> The meeting name has been set to 'fpc'
17:02:51 <abadger1999> sochotni: Now :-)
17:02:52 * spot is here (for once)
17:02:54 * geppetto is here
17:02:55 <abadger1999> #topic Roll Call
17:02:59 <geppetto> spot: Hey!
17:03:05 <abadger1999> #chair spot geppetto RemiFedora
17:03:05 <zodbot> Current chairs: RemiFedora abadger1999 geppetto spot
17:03:11 <abadger1999> spot: Greetings!
17:03:13 <spot> Sorry about being all ghost-like. I've been busy and stuff.
17:03:18 <RemiFedora> spot, waouh !
17:03:22 * sochotni is here (to answer questions wrt java guidelines)
17:03:47 * spot idly wonders if there is an agenda, or if i should quickly whip one together
17:03:49 <abadger1999> SmootherFrOgZ, tibbs: FPC ping
17:04:00 <sochotni> spot: there was one posted to devel
17:04:14 <spot> aha
17:04:19 <sochotni> spot: https://lists.fedoraproject.org/pipermail/devel/2014-January/193637.html
17:04:31 <geppetto> spot: https://lists.fedoraproject.org/pipermail/devel/2014-January/194268.html
17:04:42 * geppetto is too slow
17:04:45 <abadger1999> Since sochotni is here, we should be sure to get to the java update :-)
17:04:50 * spot found it buried in the pile of "unread emails in the fedora-devel folder"
17:04:58 <spot> have i mentioned being busy and stuff? :)
17:05:33 * SmootherFrOgZ here
17:05:42 <RemiFedora> spot, Ctrl-A + del in your inbox ;)
17:05:58 <abadger1999> ah -- it's the second of those links
17:06:03 <abadger1999> #chair SmootherFrOgZ
17:06:03 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto spot
17:06:16 <abadger1999> and that's just enough for quorum.
17:06:47 <sochotni> yeah, sorry for the confusion :-)
17:06:56 <abadger1999> spot: would you like to run the meeting or would you like me to?
17:07:18 <abadger1999> Since you're here I'm always happy to weasel out of it ;-)
17:07:24 <spot> abadger1999: sure, i can fake it. ;)
17:07:38 <spot> #topic Followup item - https://fedorahosted.org/fpc/ticket/381
17:08:08 <spot> This is the python-matplotlib font exception ticket
17:08:32 * racor is here
17:08:42 * abadger1999 notes that he's just had a chance to update the followup tickets for the week.
17:08:46 <abadger1999> #chair racor
17:08:46 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto racor spot
17:09:56 <spot> The problem seems more complicated than "python-matplotlib can't find the stix fonts"
17:09:56 <abadger1999> The matplotlib exception, I propose we leave open for a week (since I didn't update it until today) and if there's no new information we close it next week.
17:10:06 <abadger1999> #chair Rathann
17:10:06 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto racor spot
17:10:06 <Rathann> sorry
17:10:14 <spot> It looks like the stix 1.1 fonts now in Fedora aren't compatible
17:11:42 <spot> This means that the options are A) port matplotlib to support the new fontset (not trivial, according to upstream), B) package up the old 1.0 fonts (probably unmaintained by stix upstream) or C) permit bundling of the 1.0 fonts until matplotlib supports the 1.1 fonts
17:12:15 <abadger1999> yeah, we can resolve the "have stix ship ttf" fairly easily but the changes to the font metrics means that code changes will be needed.
17:12:53 <spot> i'm inclined to support C in this case, and ask the maintainer to open a bug ticket with matplotlib for support of the 1.1 font
17:13:16 <abadger1999> What's the drawback of B?
17:13:35 <spot> abadger1999: i'd wager the filenames are identical
17:14:08 <spot> probably easy enough to workaround, but since matplotlib may be the only consumer, it could be confusing to the end user if both got installed.
17:14:55 * spot isn't expert in how fontconfig chooses which font is "Stix" in the user display
17:15:18 <geppetto> My default reaction is to assume that B > C … are you really sure that C > B?
17:16:10 <spot> geppetto: in the case of fonts, i think it might be.
17:16:20 <geppetto> I mean … at the outside, I'd prefer B where the fonts get installed into some weird place not used by anything by default … and then matplotlib uses them.
17:16:34 <abadger1999> I verify that we'd have filename conflicts to work around.
17:16:50 <spot> geppetto: okay, but if we're doing that, why not a hybrid, make matplotlib-stix-fonts-1.0
17:17:02 <spot> make it clear that these fonts aren't in the usual path
17:17:12 <geppetto> spot: Yeh, was just going to suggest that the fonts could be a subpackage … I'd +1 that, I guess.
17:17:15 <abadger1999> <nod>
17:17:32 <spot> so, permit bundling as long as the fonts are subpackaged, until the 1.1 fonts can be used?
17:17:36 <abadger1999> subpackage approach works for me... Maybe we should ask nim-nim about implementation?
17:17:42 <geppetto> yeh
17:17:53 <Rathann> exactly my thought
17:18:19 <abadger1999> #chair tibbs|w
17:18:19 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto racor spot tibbs|w
17:18:26 <tibbs|w> Thanks.
17:18:29 <tibbs|w> Sorry for being late.
17:18:38 <spot> #proposal Permit matplotlib to bundle the STIX 1.0 fonts until the system 1.1 fonts can be used. matplotlib should make a separate subpackage for the stix-1.0 fonts (e.g. python-matplotlib-stix-fonts-1.0)
17:19:02 <RemiFedora> +1
17:19:13 <spot> The fonts must be installed in a matplotlib local path (not in the system fonts dir).
17:19:19 <SmootherFrOgZ> +1
17:19:22 <Rathann> +1
17:19:34 <spot> +1
17:19:38 <tibbs|w> +1
17:19:42 <geppetto> +1
17:19:43 <abadger1999> maybe we should ask nim-nim for more info.
17:20:09 <spot> abadger1999: feel free to do that, i don't think we should block on that though.
17:20:13 <racor> 0 I'd prefer tabling until things are more clear
17:20:21 <spot> this is easy to undo (not a new package)
17:20:21 <abadger1999> For instance, does the automatic font installer in packagekit use the package name?
17:20:29 <tibbs|w> I wouldn't be opposed to getting the full status from the font experts, but from what I read in all of the various tickets a temporary exception seems OK.
17:21:00 <abadger1999> <nod> that's true... I am okay with a temporary exception.
17:21:15 <abadger1999> +1
17:21:29 <geppetto> abadger1999: no, there's font autodeps
17:21:30 <abadger1999> and we CC nim-nim so he can raise any objections on the ticket.
17:21:42 <spot> works for me.
17:21:51 <geppetto> I guess we need to tell them to make sure that autodeps. thing doesn't trigger
17:22:00 <geppetto> Because it's probably not path specific.
17:22:19 <spot> #action Permit matplotlib to bundle the STIX 1.0 fonts until the system 1.1 fonts can be used. matplotlib should make a separate subpackage for the stix-1.0 fonts (e.g. python-matplotlib-stix-fonts-1.0). The fonts must be installed in a matplotlib local path (not in the system fonts dir). Will CC nim-nim to make sure there are no objections.
17:22:33 <spot> #action (+1:7, 0:1, -1:0)
17:23:24 <spot> #topic New Java Packaging Guidelines - https://fedorahosted.org/fpc/ticket/384
17:23:39 <spot> Draft: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
17:24:12 <sochotni> it's considerably shorter than current guidelines but from rules POV there are not that many changes
17:24:31 <sochotni> I believe I mentioned the goal to simplify whole guidelines to set of basic rules
17:24:46 <sochotni> and move techniques/preferred macros etc into a different document
17:25:08 <tibbs|w> I'm generally happy with that.  It's the kind of thing I've wanted to do for years with the regular guidelines.
17:25:26 * spot agrees
17:26:03 <tibbs|w> The only real question is exactly where the line should be drawn between FPC-controlled content and stuff that lives outside the guidelines.
17:26:35 <sochotni> well I tried to keep all stuff affecting other packages in the guidelines
17:27:06 <spot> looking over it, it looks like the balance here is sensible.
17:27:34 <racor> can we have a diff? Otherwise, I feel unable to vote on this proposal.
17:27:46 <sochotni> racor: sure, but it's gonna be big :-)
17:29:32 <sochotni> racor: https://fedoraproject.org/w/index.php?title=User%3AAkurtakov%2FJavaPackagingDraftUpdate&diff=359145&oldid=323222
17:30:09 <sochotni> I didn't include the diff because it's too big due to cuts of big chunks of text
17:30:24 <sochotni> examples, macro documentation...that kind of thing
17:30:39 <sochotni> things that never really belonged in the guidelines
17:31:11 <spot> My only concern is that I would be unhappy if macro values changed in a non-compliant way.
17:31:34 <spot> (really, the only reason we required the definitions of macros to be in the guidelines)
17:31:37 <sochotni> spot: i.e. if what macro did changed to non-compliance?
17:31:58 <sochotni> ugh that wording...
17:32:00 <geppetto> the filenames => split jar files thing changed a lot of MUST to one SHOULD.
17:32:15 <sochotni> geppetto: yes, that's mentioned in summary of changes
17:32:25 <spot> sochotni: not saying that it has happened, just that if say, %{_jnidir} moved to /opt/foo/bar
17:32:40 <sochotni> spot: right but even current guidelines wouldn't prevent that
17:32:42 <spot> that would no longer require a guidelines update
17:32:51 <sochotni> indeed true
17:32:56 <geppetto> sochotni: You mean this line "Simplify filename naming guideline (and make it more lax) " ?
17:33:16 <geppetto> sochotni: Is there some reasoning to make it more lax?
17:33:20 <sochotni> spot: even currently I can change javapackages-tools configuration file and XMvn will start putting files in /yo-mamma/dir
17:33:21 <Rathann> geppetto: that SHOULD was there before
17:33:27 <Rathann> so that hasn't changed
17:33:35 <spot> sochotni: a valid point.
17:33:50 <sochotni> geppetto: sometimes it doesn't make sense, sometimes it's much easier...
17:34:08 * spot supposes we can trust the java people not to do anything silly (well, no sillier than packaging java in the first place... ;) )
17:34:11 <sochotni> geppetto: that MUST was observed in practice on best-effort basis
17:34:15 <sochotni> :-)
17:34:19 <geppetto> Rathann: Ahh, I see … it moved … in the diff. it looks like split jar files replaces filenames … but they are both there before and after.
17:34:32 <geppetto> sochotni: *nods* … fair enough.
17:34:34 <Rathann> I'd keep the section about jar filenames though
17:34:51 <sochotni> Rathann: it's there
17:35:08 <geppetto> I'm far from a Java knowledgable person … but it looks ok to me.
17:35:11 <Rathann> right, it just moved
17:35:14 <sochotni> Rathann: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Filenames
17:35:15 <sochotni> yeah
17:35:34 * spot is +1 on this draft. a lot of work clearly went into simplifying this and splitting it into rules and best practices.
17:35:36 <sochotni> hopefully future changes to guidelines will be more understandable
17:35:47 <abadger1999> I'm actually for keeping macro definitions.
17:36:04 <sochotni> abadger1999: we never had definitions
17:36:06 <abadger1999> sochotni: What's meant by  transitive Requires in the BuildRequires and  Requires section ?
17:36:08 <sochotni> just how to use them
17:36:13 <spot> abadger1999: i would be too, but the old java draft didn't have them. :)
17:36:16 <spot> abadger1999: so its not too fair for us to demand them now. :)
17:37:05 <sochotni> abadger1999: ugh, I wanted to get rid of that wording
17:37:07 <abadger1999> sochotni: but I mean what does the term mean?
17:37:10 <sochotni> abadger1999: gone now
17:37:10 <abadger1999> hehe :-)
17:37:14 * abadger1999 refreshes
17:37:18 <Rathann> what happened to "To satisfy this Fedora requirement of using "System.load()" instead of "System.loadLibrary()" section?
17:37:35 <abadger1999> sochotni: It's also a few lines above: Java binary packages MUST have transitive Requires (generated by RPM or manual) on:
17:37:40 <sochotni> Rathann: that was an example how to deal with JNI loading
17:38:09 <sochotni> abadger1999: right, that's meant that packages don't have to "Require: java[-headless]" themselves if a dependency depends on it
17:38:40 <Rathann> sochotni: yes, but wasn't it useful enough to keep?
17:38:42 <sochotni> i.e. if you have a build system (maven/ant) you only need to "BR: ant" instead of specifying everything
17:38:44 <tibbs|w> "This package or something in its dependency chain must have Requires: foo"
17:38:57 <tibbs|w> I think that's close to the standard wording we use.
17:39:23 * spot nods, that seems a bit clearer
17:39:31 <abadger1999> <nod>
17:39:40 <sochotni> tibbs|w: ok, how about "Java binary packages or their dependencies '''MUST''' have Requires (generated by RPM or manual) on:" ?
17:40:11 <spot> wfm
17:40:24 <sochotni> saved
17:41:26 <sochotni> Rathann: wrt example...I removed all of them from guidelines and we are expanding the HOWTO instead
17:41:31 <sochotni> Rathann: not everything is there yet
17:41:35 <spot> brb, going to refill my water.
17:41:37 <sochotni> https://fedorahosted.org/released/javapackages/doc
17:43:09 <abadger1999> regarding removing templates... we've had problems with external templates before.. the font templates.
17:43:31 <Rathann> sochotni: oh, ok
17:43:36 <Rathann> as long as it doesn't get lost
17:44:01 <sochotni> abadger1999: problems with them being agains guidelines or just out of sync?
17:44:16 <abadger1999> against guidelines.
17:44:38 <abadger1999> iirc they implemented the guidelines that were explicitly in that part of the guideline
17:44:46 <sochotni> tbt I can't promise there won't be mistakes, but certainly not intentionally...
17:44:47 <abadger1999> but they did not follow other guidelines
17:45:32 <sochotni> right, I believe we have wording somewhere that HOWTO is *always* overriden by guidelines
17:45:32 <spot> i think in the java case, this is far less likely to happen, given that the java templates have less room for ... improvisation.
17:45:52 <sochotni> spot: Maven ones don't but others are more prone...
17:45:59 <abadger1999> yeah.. I'm more okay with the templates being external than macros.
17:46:03 <spot> if it becomes a problem, we can always ask them to be pulled back in.
17:47:19 <abadger1999> sochotni: for the System.load() example... do you have that example externally documented?
17:47:29 <abadger1999> If so, that's something I think a direct link to would be hepful
17:47:40 <limburgher> Sorry, space cadet mode today.  Where are we?
17:47:40 <abadger1999> (it's about code rather than spec files)
17:47:44 <sochotni> abadger1999: not as of now
17:47:45 <abadger1999> #chair limburgher
17:47:45 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor spot tibbs|w
17:47:55 <sochotni> limburgher: Java guidelines
17:47:57 * spot points to topic, still in discussion
17:48:00 <limburgher> kthx
17:48:25 <abadger1999> sochotni: would you be willing to just throw that onto a non-Packaging: wiki page for now and point to that?
17:48:26 <sochotni> abadger1999: we didn't find a proper section to put it in yet :-)
17:48:45 <sochotni> abadger1999: sure why not
17:48:53 <abadger1999> Cool.  that part works for me.
17:49:20 <sochotni> and wrt macros I don't really have an answer I guess...yes their usage would be documented externally
17:49:29 <sochotni> we do have manpages for them anyway :-)
17:50:30 <abadger1999> sochotni:  Patching Maven pom.xml files  <= is this section no longer needed at all?
17:51:06 <abadger1999> If it's just moved externally, I think I'd like it to be pointed to externally.
17:51:09 <sochotni> abadger1999: nope, that was full of examples
17:51:22 <sochotni> abadger1999: there is
17:51:25 <sochotni> Maven pom.xml files
17:51:40 <sochotni> but I guess...yeah
17:53:07 <abadger1999> Yeah.. something like: for packaging we often have to modify pom files to [fill in a few use cases].  You can find instructions in [section of external java packaging doc]
17:53:35 <sochotni> abadger1999: refresh
17:53:35 <abadger1999> I think that commonly encountered packaging problems should be pointed out.
17:54:08 <abadger1999> sochotni: Cool -- can you also link to the external doc for that?
17:54:16 <sochotni> yeah, just realized that...
17:56:33 <abadger1999> sochotni: We probably need to keep the "java/jni is not multiarch/multilib" in here somewhere too... I don't think it's recorded anywhere else.
17:56:51 <abadger1999> and it's a policy/guideline rather than a packaging howto
17:57:02 <sochotni> abadger1999: %{_jnidir} usually expands into %{_prefix}/lib/java, even on 64-bit systems.
17:57:12 <sochotni> but that's just Macro expansions note
17:57:29 <spot> is that usually or "always" ? :)
17:58:26 <sochotni> spot: always (except few old fedoras - EOLed)
17:58:42 <spot> then perhaps we can say "always" now.
17:58:49 <spot> or just drop usually.
17:59:25 <spot> "This means that java/jni packages are not multiarch or multilib."
17:59:43 <abadger1999> yeah -- maybe add a sentence that says "Fedora's Java environment is not multilib-aware.  So we use %{_prefix}/lib even on 64bit systems."
17:59:59 <sochotni> spot, abadger1999: added that example and reworded that admonition
18:00:51 <abadger1999> okay, there's a lot of changes so I'm not sure I caught everything... but that's everything I saw.
18:01:51 <abadger1999> I won't block on macros not being there since they weren't before but I do think we should add them.
18:02:01 <abadger1999> At the least, path macros should be documented.
18:02:07 <sochotni> today's diff so far: https://fedoraproject.org/w/index.php?title=User%3AAkurtakov%2FJavaPackagingDraftUpdate&diff=368052&oldid=367001
18:02:20 * spot is still +1, with or without explicit macro defs
18:03:04 <tibbs|w> I'm +1 as well.  Maybe if something ends up going wrong we can revisit whether or not that's a good idea.
18:03:18 <sochotni> I am not completely against adding macro definitions (it's not like we change them that often)
18:03:21 <abadger1999> since that's a case where a maintainer says: "I ran $build-script install and it put files into /usr/lib/java/foo/bar.jar.  What macro do I need to use in %files to point to that?"
18:03:24 <abadger1999> +1
18:03:30 <limburgher> I think I'm +1 also.
18:03:33 <tibbs|w> But I'd prefer the various language groups to be able to evolve their packaging sensibly without having to go through us.
18:03:35 <limburgher> Thanks for the diff.
18:03:36 <geppetto> +1
18:03:40 <sochotni> meaning the path ones at least
18:03:49 <RemiFedora> +1
18:03:56 <abadger1999> sochotni: <nod>
18:04:10 <sochotni> next time perhaps...
18:04:19 <sochotni> it's gonna be easier :-)
18:04:21 <abadger1999> sochotni: <nod>  That's why I mention it ;-)
18:04:50 * spot looks for votes from racor, Rathann, SmootherFrOgZ
18:05:10 <Rathann> yeah, looks good to me
18:05:11 <Rathann> +1
18:06:04 <racor> +1
18:06:12 <spot> #action Revised java guidelines draft approved (+1:8, 0:0, -1:0)
18:06:36 <sochotni> thanks! if there's gonna be some issues I am sure we'll work them out...
18:07:05 <sochotni> it's not like we're gonna throw away everything just to screw with you :-)
18:07:53 <Rathann> guys, sorry, but I need to go now
18:07:59 <Rathann> baby calls
18:08:03 <abadger1999> Rathann: See you later!
18:08:23 <sochotni> sorry for prolonging this btw...
18:08:41 <sochotni> should've caught at least some of the issues earlier
18:08:43 <abadger1999> sochotni: And let me say, it's been a pleasure working with you in this meeting :-)
18:08:53 <spot> sochotni: nice work, thanks for doing it
18:09:00 <sochotni> appreciated
18:09:08 <spot> we're over an hour now, we can keep rolling or push to next week.
18:09:09 <spot> thoughts?
18:09:26 <abadger1999> Let's keep going until the second hour is up or we lose quoru
18:09:29 <limburgher> I can spend a bit more time.
18:09:30 <spot> okay.
18:09:32 <abadger1999> whichever comes first.
18:09:43 <spot> #topic Workarounds for rpm symlink <-> directory issue - https://fedorahosted.org/fpc/ticket/385
18:09:53 <abadger1999> I have one followup to SCls that we probably shold talk about since limburgher is here.
18:10:08 <limburgher> abadger1999:  Si?
18:11:10 <RemiFedora> why a lua script and not a simple bash one ?
18:11:36 <limburgher> Author knows lua better than bash?
18:11:39 <abadger1999> limburgher: as long as you'll be here, we can talk about it after the rpm file vs directory topic
18:11:49 <limburgher> k
18:11:51 <abadger1999> RemiFedora: I think bash might not yet be installed.
18:11:58 <abadger1999> (if it's happening in %pretrans)
18:12:05 <geppetto> RemiFedora: lua is a single process
18:12:09 <limburgher> abadger1999: That too.
18:12:23 <geppetto> RemiFedora: So if you alter libs. etc. you don't start dying half way through.
18:13:13 <limburgher> Kids, no sense of adventure these days.
18:13:49 * spot has only ever seen lua in %pretrans
18:13:56 <geppetto> ofc. saying that, I see that the lua script calls out to rm anyway … which is _maybe_ fine, but probably not.
18:14:35 <geppetto> in fact, I'm -1 on it until they fix that I think.
18:14:42 <limburgher> Isn't there a lua-ish way to say rm?  There's a pythonic way to do it.
18:15:03 * spot wonders if that is os.remove
18:15:13 <limburgher> Like maybe os.remove like in the second script?
18:15:15 <limburgher> jinx
18:15:23 <geppetto> os.remove() on it's own won't do the "-rf" bit.
18:15:44 <limburgher> it doesn't take params?
18:16:08 <abadger1999> ugh.
18:16:09 <geppetto> limburgher: It's just calling "man 3 remove" AIUI.
18:16:13 <abadger1999> Maybe we shouldn't do a remove
18:16:18 <abadger1999> Maybe a rename is better.
18:16:24 <limburgher> Maybe.
18:16:38 <spot> http://svn.wildfiregames.com/public/ps/trunk/build/premake/premake4/src/base/os.lua has a rmdir lua
18:16:58 <abadger1999> like /etc/application/MY_CONFIG_I_WORKED_HOURS_ON
18:17:06 <geppetto> abadger1999: :)
18:17:12 <limburgher> muhumuhahahahaaa
18:17:30 <SmootherFrOgZ> sorry, got side-tracked at office. +1 for the record.
18:17:31 <geppetto> abadger1999: Nest thing you'll be asking for undo in the package manager.
18:17:58 <abadger1999> :-)
18:18:15 <limburgher> Like some sort of unholy yum/puppet hybrid, with it's bucket o' changed files?
18:18:17 <geppetto> spot: Yeh, that looks fine … or rename, but then someone has to cleanup at some point.
18:18:26 <abadger1999> geppetto: Do you know if symlink to directory is just a bug?  Or is it also architecturally hard?
18:18:59 <geppetto> abadger1999: The later, people have asked Panu to fix it many times.
18:19:01 * abadger1999 thinks that directory => symlink is generalizable to directory => file
18:19:10 <abadger1999> k
18:19:52 <limburgher> I recall panu saying that it's really sticky to fix in a correct and robust way.
18:20:10 * spot isn't qualified to seriously propose lua changes
18:20:24 <spot> but that rmdir function looks sane to me.
18:20:55 <abadger1999> geppetto: k I just saw that the symlink to directory bug might not have been for the same reasons as the directory => symlink problem
18:21:09 <spot> i just dont think adding +100 lines of a lua in a pretrans is... sane.
18:21:56 <limburgher> You could add it to pre instead  <ducks>
18:21:58 <abadger1999> So... things I would want changed: * Change remove to rename.
18:21:59 <geppetto> abadger1999: AIUI they are both the same problem in that rpm likes to have all the files from old and new on disk at once … and symlink/dir changes screw that.
18:22:07 <abadger1999> <nod>
18:22:26 <limburgher> geppetto:  Yes, badly.
18:22:27 <abadger1999> okay, sounds like we need both then.
18:22:28 <tibbs|w> Could just have the lua do a rename and then actually clean up the directory afterwards.
18:22:55 <limburgher> tibbs|w:  That's what rdieter and I came up with for gallery2.
18:22:59 <abadger1999> * Add panu's warning admonition about it still being unsafe
18:23:22 <abadger1999> * Add panu's recommendation to avoid it by starting off with a symlink in the first place.
18:23:58 * spot agrees with abadger1999's proposals
18:24:02 <abadger1999> tibbs|w: yeah... if the directory is empty, I could see cleaning it.
18:25:01 <abadger1999> But don't want the script to get too complex... (ie: directory not empty... does the symlink point to a directory?  If yes, then mv files from the old directory to the new directory)
18:25:21 <abadger1999> and so on for out-of-space corner cases and so on.
18:25:22 <geppetto> spot: The only thing I'd worry about is that nothing in that rmdir seems to be checking for symlinks etc.
18:25:48 <geppetto> spot: But I've also written roughly 0 lines of lua
18:25:52 <limburgher> geppetto:  Yes, the stuff we have in bash in gallery2 is messier but a bit more robust in that regard.  If however imperfect.
18:26:39 * spot calls "not-it" on rewriting this draft. :)
18:27:24 <abadger1999> ugh.. there's some other "corner" cases too...
18:27:40 * limburgher also calls so, so not it.
18:27:52 <abadger1999> like foo-framework has /usr/lib/frameworkdir
18:28:10 <abadger1999> 20 packages install things into /usr/lib/foo-frameworkdir
18:28:24 <abadger1999> foo-framework-2 changes from a directory to a symlink.
18:28:42 <abadger1999> the other 20 packages are broken.
18:29:15 <abadger1999> spot: I think patches could do the update as long as we tell him what to include.
18:29:24 <abadger1999> he's been pretty active in writing drafts.
18:29:52 <spot> mmkay.
18:30:22 <spot> abadger1999: seems like you know most (all) of the things we need to add, can you update the ticket?
18:30:34 <abadger1999> I guess we either punt on that cornercase or we mention it along with the other warnings.
18:30:44 <abadger1999> spot: yep, I'll update the ticket with what we've mentioned here
18:30:59 <spot> #action abadger1999 will update the ticket with the requested changes
18:31:43 <racor> once again, my time's up for today. I've got to quit. Bye
18:31:47 <abadger1999> so.. scl thing
18:31:51 <abadger1999> racor: So long!
18:32:15 <spot> #topic /etc/shells needs to be considered - https://fedorahosted.org/fpc/ticket/386 - https://fedoraproject.org/wiki/User:Cicku/Drafts/Take_account_of_shells_file
18:32:34 <spot> feel free to talk the scl thing for a moment. :)
18:32:42 * spot just didn't want to forget that agenda item
18:32:53 <limburgher> This falls afoul of the "don't modify other packages' stuff" rule, but needs addressing.
18:33:19 <abadger1999> k
18:33:22 <abadger1999> So the scl thing
18:33:45 <abadger1999> One of our issues was the LSB /FHS definition of /opt
18:33:47 <geppetto> this feels like it'd be nice for something to provide post/postun macros.
18:34:05 <abadger1999> I wrote a patch that we talked about here as making it acceptable for scls to be shipped in /opt/
18:34:12 <abadger1999> (/opt/vendor/)
18:34:29 <abadger1999> LSB is kinda busy getting their next version out.
18:34:39 <abadger1999> But I got some feedback from one of the main LSB members
18:34:42 <limburgher> k
18:35:03 <abadger1999> It's in this comment: https://fedorahosted.org/fpc/ticket/339#comment:42
18:35:21 <abadger1999> Would we be okay voting a temporary exception based on that?
18:36:07 <geppetto> For the /opt thing … sure.
18:36:29 <abadger1999> Note -- here's my patch to the FHS if anyone wants to refresh their memory: https://bugs.linuxfoundation.org/attachment.cgi?id=432
18:36:51 <limburgher> Yeah, I guess I'm as persuaded as I'm likely to get, enough to +1 it.
18:37:00 <abadger1999> Cool.
18:37:06 <limburgher> Thanks for doing the legwork necessary to appease me. :)
18:37:32 <abadger1999> Proposal: Add a temporary FHS exception to allow scls to use /opt/$vendor subdirs
18:37:45 <abadger1999> +1
18:37:49 <spot> +1
18:38:13 <RemiFedora> +1
18:38:54 <spot> i see +4 on that (with limburgher's +1)
18:39:40 <limburgher> Yes, +1.
18:39:53 <abadger1999> geppetto, tibbs|w, SmootherFrOgZ: care to vote on the temporary fhs exception?
18:40:56 <geppetto> +1
18:41:09 <abadger1999> Thanks.  That's +5
18:41:38 <spot> #action Add a temporary FHS exception to allow scls to use /opt/$vendor subdirs (+1:5, 0:0, -1:0)
18:41:46 <abadger1999> That's all I have votable on SCLs for now.
18:41:49 <spot> okay, now to the shell scriptlets.
18:42:18 * spot made some cleanups to the draft, but i didn't change the scriptlets
18:42:32 <spot> they seem sensible, and given that there are not very many shell packages (< 10, i hope)
18:42:37 <spot> i think this is fine to leave as is
18:43:15 <abadger1999> Do we need to specify both %{_bindir}/$shell and /bin/$shell ?
18:44:06 <spot> I don't think so, the example just covers %{_bindir}/$shell, but the text above it makes it clear that relevant binary path should be used.
18:44:15 <limburgher> I'd rather this was fixed in setup, which owns /etc/shells, maybe with a /etc/shells.d/?
18:44:33 * RemiFedora nods
18:44:55 * spot doesn't disagree, but I'm not volunteering to untangle whatever depends on /etc/shells
18:44:56 <limburgher> Failing that, this is. . .less icky than some ideas, but it breaks rpm --verify for setup.
18:45:09 <limburgher> And will get clobbered if setup gets updated.
18:45:10 <abadger1999> I'm just wondering because I know we've run into issues before where something is using /bin/shell and since /usr/bin/shell was all that was in /etc/shells it was failing
18:45:26 <SmootherFrOgZ> craps, I really have bad timing today, i really am sorry. +1 for the record.
18:46:08 <abadger1999> limburgher: <nod>... yeah, I guess with this we'd have to update all shell packages to include this scriptlet.
18:46:34 <abadger1999> and have setup mark /etc/shells as %config(noreplace)
18:46:53 <spot> is someone willing to do the work to enable /etc/shells.d/ ?
18:46:55 <limburgher> And do we want to do that?
18:47:01 <abadger1999> (Although... is it already?  sysadmin should be able to modify /etc/shells)
18:47:02 <spot> if not, then i think this is the only viable option on the table.
18:47:25 <limburgher> checking
18:47:53 <abadger1999> %config(noreplace) %verify(not md5 size mtime) /etc/shells
18:48:00 <limburgher> Yes.
18:48:18 <limburgher> So this draft could sort of work.
18:49:17 <abadger1999> Looks like some shells are adding themselves already
18:49:28 <limburgher> swell.
18:49:32 * limburgher grumbles
18:49:39 <abadger1999> setup lists both /bin/ and /usr/bin/ for sh, bash, nologin
18:50:09 <abadger1999> On my system, /bin/ versions are added for zsh, csh, tcsh, dash
18:50:13 * spot is at his "hungry" point, where i stop being able to think sensibly, but i think if we add rules requiring that all binary paths included in a shell package must be handled with these scriptlets... it should be sufficient, right?
18:50:14 <abadger1999> and /usr/bin/ added for tmux
18:50:39 <limburgher> spot:  I think so.
18:50:42 <abadger1999> I like the draft if we add both %{_bindir}/$shell and /bin/$shell
18:50:59 <limburgher> abadger1999: Works for me.
18:51:24 <spot> Proposal: Draft + requirement for all binary shell paths to be handled with /etc/shells scriptlets
18:51:26 <spot> +1
18:51:40 <limburgher> +1
18:51:44 <RemiFedora> +1
18:51:46 <geppetto> +1
18:52:04 <SmootherFrOgZ> +1
18:52:10 <abadger1999> +1 if we add both %{_bindir}/$shell and /bin/$shell
18:52:30 <spot> #action Draft + requirement for all binary shell paths to be handled with /etc/shells scriptlets (+1:6, 0:0, -1:0)
18:52:45 <spot> someone want to volunteer to add the requirement wording?
18:52:50 <abadger1999> I'll do it.
18:52:56 <spot> abadger1999: thanks.
18:53:02 <spot> #topic Open Floor
18:53:27 <limburgher> Nada von mir.
18:53:37 * spot is very inclined to go find lunch, so nothing from me.
18:53:51 <abadger1999> spot: I need to ask you about LANANA registration but I can't tlak to you about that after you lunch.
18:53:57 <abadger1999> *I can talk
18:54:07 <spot> works for me.
18:54:07 <limburgher> abadger1999: Oh, I'm a hurdle now, am I? ;)
18:54:11 <abadger1999> it's apparently typing I can't do.
18:54:22 <abadger1999> limburgher: ;-)
18:55:04 <abadger1999> limburgher: seriously, I was perfectly fine to clarify that in FHS upstream ;-)
18:55:05 <spot> one minor note:
18:55:19 <spot> I'll be en route to Belgium next week (FOSDEM) so i won't be here.
18:55:37 <limburgher> abadger1999:  Uh huh.  Backpedal all you want. ;)
18:55:58 <spot> and with that, i think we're done, thanks everyone.
18:56:01 <spot> #endmeeting