16:04:04 <abadger1999> #startmeeting fpc
16:04:04 <zodbot> Meeting started Thu May  8 16:04:04 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:04 <tibbs|w> May be in and out today as usual.
16:04:07 <abadger1999> #meetingname fpc
16:04:07 <zodbot> The meeting name has been set to 'fpc'
16:04:16 * limburgher here and all that.
16:04:20 <abadger1999> #chair geppetto RemiFedora Rathann tibbs|w
16:04:20 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs|w
16:04:41 * abadger1999 is examining a security issue in a package so somewhat distracted
16:04:50 <abadger1999> #topic Roll call
16:04:52 <limburgher> pfft.  Priorities.
16:04:56 * geppetto is here
16:05:01 <abadger1999> #chair limburgher
16:05:01 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbs|w
16:05:12 * RemiFedora still here
16:05:25 <abadger1999> spot, Smoother1rOgZ: FPC ping
16:05:27 * limburgher also still here.
16:05:35 * racor is here
16:05:40 * hughsie is here for any appdata questions... :)
16:05:45 <RemiFedora> quorum \o/
16:05:52 <abadger1999> And we do have quorum :-)
16:05:57 * abadger1999 pulls up the agenda
16:06:19 <abadger1999> #topic #339     software collections in Fedora
16:06:34 <abadger1999> geppetto: You were going to be doing some work related to this?
16:07:02 <geppetto> yeh, it's mostly done … but not 100%
16:07:27 <abadger1999> #chair racor
16:07:27 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher racor tibbs|w
16:07:32 <geppetto> enough that we can talk about it if you want … but also fine to delay another week, if you want to do some of the other 666 items
16:07:41 <abadger1999> Sounds good.
16:07:49 <abadger1999> A few things came up this week as well...
16:08:11 <abadger1999> (1) The SCL team seems to want to push SCL pacakges through without reviews.
16:08:17 <abadger1999> I
16:08:23 <abadger1999> m against that.
16:08:30 <abadger1999> Anyone here for it?
16:08:31 <limburgher> um. . .duh?  Yikes?
16:08:52 * abadger1999 digs up the releng ticket where the conversation happened
16:08:54 <Rathann> -1 obviously they can use copr for that
16:08:57 <geppetto> do they have any reasoning … other than, yeh free for all?
16:09:06 <tibbs|w> I can understand some motivations for skipping additional process, but I do think these things merit review.
16:09:20 <tibbs|w> But then don't they want to build scls and regular base packages out of the same spec?
16:09:28 <RemiFedora> I really think review are needed for the main packages... probably less usefull for other packages in collection
16:09:30 <tibbs|w> Or am I misunderstanding that.
16:10:20 <abadger1999> https://fedorahosted.org/rel-eng/ticket/5894#comment:7
16:10:24 <RemiFedora> I mean, for a perl collection, review the metapackage + the change to "perl" packages, but don't review the tons of perl-* modules
16:10:25 <geppetto> So … kind of related to this, given my XP so far … I'm not sure I'm for #419 … in that I'm not sure I see a great upside to shipping a ruby language stack on it's own.
16:10:37 <abadger1999> RemiFedora: I think that's what the SCL team wants.
16:10:46 <abadger1999> RemiFedora: But I'm against that.  The changes are too big too me.
16:11:32 <geppetto> Or a perl, or a python one.
16:11:50 <abadger1999> geppetto: okay.  What are you seeing?
16:12:17 <geppetto> abadger1999: so my project is to create a yum scl, so you can install it on f20, rhel6, rhel5, etc.
16:12:46 <geppetto> abadger1999: Which basically means shipping the python deps. inside the yum scl.
16:13:15 <geppetto> Having a python27 scl, which the yum scl deps. on … seems like way more work, and much less fun all round.
16:14:00 <abadger1999> <nod>
16:14:00 <geppetto> Which makes me wonder what use shipping a care python27 stack would be.
16:14:07 <geppetto> s/care/bare/
16:14:12 <RemiFedora> seems like building "yum" scl as a dependent collection of "python27" is the way which make sense
16:14:15 <geppetto> dito. perl/ruby/etc.
16:14:22 <abadger1999> But having python27 inside of hte yum scl means that we'd be maintaining multiple SCLs with python27.
16:14:44 <abadger1999> which seems to be the combinatorial explosion that nirik worried about at fesco.
16:14:54 <abadger1999> well... one aspect of combinatorial explosion..
16:15:01 <geppetto> RemiFedora: But if that's true … how far do you go?
16:15:41 <geppetto> RemiFedora: Just having yum scl and python27 scl seems like a very bad split.
16:15:54 <RemiFedora> why ?
16:16:33 <geppetto> RemiFedora: Because of the random python modules that yum deps. on. So you need a python-iniparse scl … and a pyxattr scl, and a pygpg scl
16:17:00 <geppetto> Basically almost every package that yum deps, on becomes an scl
16:17:39 <abadger1999> I would see it as Large SCL (python27 [certain compat guaranteed packages] + other python27 packages supporting yum [among others]) ; smaller SCL (yum compat guaranteed.  depends on the python27 SCL.  Maybe some other packages which yum depends on and wants to compat guarantee)
16:18:48 <abadger1999> I think the spirit of our guidelines are that we want those smaller (library-sized) things to be part of a larger SCL.
16:19:10 <abadger1999> We want SCLs main purposes to be framework and above sized.
16:19:16 <geppetto> abadger1999: but that hits reuse problems, right?
16:19:29 <abadger1999> geppetto: In what way?
16:20:13 <geppetto> abadger1999: Because you are saying that everything in the python27 universe is a single OS and can't do the random version dance (which is the whole point of SCLs).
16:21:19 <abadger1999> That
16:21:25 <abadger1999> 's correct.
16:21:41 <abadger1999> But we didn't wnat to have people doing random version dance I think.
16:22:03 <abadger1999> That was part of what I assumed when we approved the framework-size and above rule.
16:22:19 <geppetto> But, again, that's the whole point … think about if I want a rhel6 yum and a rhel7 yum scl
16:22:29 <abadger1999> OTOH, with python, I bet there's two ways we could still make random versions work.
16:22:38 <geppetto> Those need different versions of the rpm python module.
16:22:46 <abadger1999> (1) python already does parallel installation.  Do that inside of the scl.
16:23:34 <geppetto> #1 … yeh, party time, with more changes from how we do everything else.
16:23:48 <abadger1999> (2) The python library that's loaded depends on the order of directories inside PYTHONPATH so I bet you could design scl-utils so that the yum SCL's PYTHONPATH takes precedence over the python27 SCL's PYTHONPATH
16:24:41 <geppetto> #2 seems saner, but still more work and feels like it'd be more fragile.
16:25:09 <abadger1999> The whole technological underpinnings of SCLs are fragile.
16:25:23 <abadger1999> and a lot of work.
16:25:40 <geppetto> indeed … but the underpinning of … all your deps. live in a giant ball of mud inside your scl … is at least easy to understand, and deal with.
16:25:41 <abadger1999> and superfluous for things like pyhton
16:25:50 <Rathann> I'm still not completely sold on the SCL idea
16:26:16 <Rathann> I'd much rather work on fixing stuff to work with latest versions of other stuff
16:27:17 <tibbs|w> I understand that's not always possible, because we want to provide the means to run code we don't control that won't work with the latest versions of whatever.
16:27:22 <geppetto> Rathann: Well the main plus points of SCLs come when you do stuff like run latest yum on rhel6/rhel5 … where there is no process to change the OS itself.
16:27:24 <tibbs|w> But, hey, compat packages.
16:27:43 <abadger1999> Rathann: I'm not in love with the technology but it's addressing a necessary problem -- we can demand porting software within the distribution.  But we can't demand porting of software running on end user's ssytems.
16:27:46 <tibbs|w> But rhelX isn't really our concern.
16:27:55 <geppetto> Anyway … we are maybe getting a bit off topic.
16:28:17 <geppetto> It's probably enough to respond with "lol, no" to allowing unreviewed SCLs into the distro.
16:28:23 <Rathann> yeah, sorry
16:28:45 <geppetto> At the very least until we've done a few reviews.
16:30:00 <abadger1999> Alright, we're 30 minutes in.  Let's close this topic for now.
16:31:08 <abadger1999> Maybe we should talk about 419
16:31:18 <abadger1999> #topic 419 https://fedorahosted.org/fpc/ticket/419  RUby SCLs
16:32:12 * hughsie has to go in about 30 mins, so /414 would be appreciated today :)
16:32:15 <abadger1999> So there's three SCLs, interdependent being proposed here.
16:32:29 <limburgher> I thought. . .oh, never mind what I thought.
16:32:54 <abadger1999> hughsie: k.  I'll put that on in next.
16:32:59 <hughsie> thx
16:33:15 <abadger1999> The naming needs to be changed to conform with the guidelines.
16:34:25 <abadger1999> The compat guarantees need to specify what packages are being protected by the compat guarantees and how they can change.
16:34:35 <abadger1999> And v8 naming.... we need to fix that somehow.
16:34:48 <abadger1999> Other than those things, I think I'd be inclined to approve these.
16:35:38 <RemiFedora> have we approved the "naming" part of the SCl guideline ?
16:36:22 <abadger1999> RemiFedora: I remember voting on it.... don't recall if it was a straw poll or not, but I think it was for real.
16:36:43 <abadger1999> We could vote now if tyou want
16:37:04 <geppetto> my note in the schedule just says approval, retirement and /opt exception.
16:37:50 <Rathann> I notice software versions are not specified in ruby and v8 SCLs
16:38:11 <Rathann> I assume it's ruby 3.2 and v8 3.1.4, but it's not obvious from the description
16:38:47 <abadger1999> Hmmm.... I remember voting on "dots in name" but I don't see that we specifically mention dots in name in the draft.
16:38:55 <abadger1999> so perhaps it was a straw poll.
16:39:39 <abadger1999> Okay -- So we can move the meeting along, I'll write up that straw poll and finalize the naming section -- we can vote on that next week.
16:39:50 <geppetto> abadger1999: it shows it by example
16:40:18 <abadger1999> Is there anything else we either need finished in the draft to vote to approve the ruby scls or anything that we need them to change in the SCL Request?
16:40:22 <geppetto> I'm happy to +1 the naming section now, if you want … or did you want to do some edits?
16:40:38 <RemiFedora> hm...
16:41:15 <RemiFedora> the "vendor" prefix is not clear...
16:41:29 <geppetto> RemiFedora: in what way?
16:41:46 <RemiFedora> "Thus it is prefixed with a vendor string. In Fedora, the prefix is fdr" ... and later "scl-ruby1.9.3." (wihout fdr)
16:42:02 <abadger1999> RemiFedora: good catch -- that should be changed to fdr-ruby1.9.3
16:42:36 <geppetto> RemiFedora: There the vendor is "scl" (an upstream scl repo.)
16:42:44 <geppetto> Or that too
16:44:34 <abadger1999> RemiFedora: Changed.  If you see any other instances of this, let me know.
16:45:22 <geppetto> abadger1999: Do you want to change all instances of scl-foo into fdr-foo on the page?
16:45:28 <abadger1999> geppetto: yep
16:45:29 <geppetto> abadger1999: Eg. scl-rails3
16:45:38 <geppetto> abadger1999: in the compat. guarantees section
16:45:55 <geppetto> dito. scl-httpd2.4
16:47:17 <abadger1999> Got'em
16:47:34 <abadger1999> Okay, moving on
16:47:40 <abadger1999> https://fedorahosted.org/fpc/ticket/414
16:48:05 <abadger1999> #topic 414 Require AppData https://fedorahosted.org/fpc/ticket/419
16:48:40 <geppetto> https://fedorahosted.org/fpc/ticket/414 not https://fedorahosted.org/fpc/ticket/419 … right?
16:49:06 <geppetto> yeh
16:49:19 <abadger1999> #topic 414 Require AppData https://fedorahosted.org/fpc/ticket/414
16:49:22 <abadger1999> yeah
16:49:45 <abadger1999> So I'm sorry, I've been busy with packaging this week -- I had a followup on this last week.
16:49:48 * hughsie is ready for questions :)
16:49:54 <abadger1999> hughsie: So last week we discussed this
16:50:06 <abadger1999> and we thought it was similar to the desktop file guidelines.
16:50:26 <abadger1999> But we also decided that the spirit of what we wanted for the desktop file guidelines doesn't match the wording.
16:50:39 <abadger1999> hughsie: So how do you feel about:
16:50:41 <abadger1999> [Thu May 1 2014] [10:10:54 AM] <abadger1999>>---Okay -- I'll draft a change to the desktop guidelines that makes it clear that it should be applied if the packager wants it to appear in the menus (rather than if it's a GUI app).  Then I'll ask rhughes to propose a draft that follows the .desktop guidelines style with the gating factor being "if you want to appear in gnome software center"
16:50:59 <hughsie> abadger1999, the crucial bit is i want the packagers to write appdata and push it upstream if at all possible
16:51:01 <abadger1999> hughsie: Does that sound good to you?
16:51:19 <hughsie> abadger1999, i can sure do that
16:52:51 <abadger1999> hughsie: oh -- also at last week's meeting some members were uncomfortable with the idea that software center wouldn't show applications that do not have AppData.  But we decided that those were FESCo-level decisions, not FPC.
16:53:15 <abadger1999> hughsie: you might want to be proactive and bring that part of the conversation up with a ticket for them.
16:53:25 <hughsie> abadger1999, right. the "won't show" is the most extreme view, i'm sure i'll have to compromise somewhere
16:53:39 <hughsie> i wanted a big stick :)
16:54:56 <abadger1999> we're really just trying to document reality here.  So we'll change the wording of the guideline as appropriate to the compromise that's worked out.
16:55:21 <hughsie> abadger1999, if someone can change the desktop spec, then i'll write an appdata one
16:55:38 <abadger1999> Cool.  So next week, draft from me on .desktop files and revised draft from hughsie on appdata.
16:55:55 <hughsie> cool, thanks
16:56:44 <abadger1999> #topic  #411     proposal: migrate license files to %license instead of %doc
16:56:49 <abadger1999> https://fedorahosted.org/fpc/ticket/411
16:56:57 <abadger1999> Last week we started voting
16:57:40 <abadger1999> geppetto, limburgher, tibbs|w, abadger1999 +1 ; racor -1
16:58:05 <abadger1999> Rathann, RemiFedora, care to vote?
16:58:32 <Rathann> +1 from me
16:59:03 * RemiFedora reads
16:59:03 <abadger1999> #info Migrating licenses to use %license passed (+1:5, 0:0, -1:1)
16:59:15 <RemiFedora> for the record, I'm +0
16:59:22 <abadger1999> #undo
16:59:22 <zodbot> Removing item from minutes: INFO by abadger1999 at 16:59:03 : Migrating licenses to use %license passed (+1:5, 0:0, -1:1)
16:59:25 <abadger1999> #info Migrating licenses to use %license passed (+1:5, 0:1, -1:1)
16:59:30 <abadger1999> #topic #413     Bundling exception request for nodejs-shelljs
16:59:36 <abadger1999> https://fedorahosted.org/fpc/ticket/413
16:59:43 <abadger1999> We started voting on this one as well
17:00:20 <abadger1999> geppetto, limburgher, tibbs|w, abadger1999 +1  on the ground that these are forks.
17:00:32 <RemiFedora> +1
17:01:16 <Rathann> +1 as well
17:01:26 <racor> -1
17:01:26 <Rathann> look like forks to me, too
17:01:32 <abadger1999> #info Bundling request for files from wrench.js in shell.js granted o nthe basis that they're forks (+1:6, 0:0, -1:1)
17:01:49 <abadger1999> #topic #417     sha2 library bundling in clementine
17:01:54 <racor> the -1 was on %license
17:02:03 <abadger1999> #undo
17:02:03 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x13e4e9d0>
17:02:06 <abadger1999> #undo
17:02:06 <zodbot> Removing item from minutes: INFO by abadger1999 at 17:01:32 : Bundling request for files from wrench.js in shell.js granted o nthe basis that they're forks (+1:6, 0:0, -1:1)
17:02:28 <abadger1999> #info Bundling request for files from wrench.js in shell.js granted o nthe basis that they're forks (+1:6, 0:0, -1:0)
17:02:35 <abadger1999> #topic #417     sha2 library bundling in clementine
17:02:48 <abadger1999> https://fedorahosted.org/fpc/ticket/417
17:04:20 <abadger1999> So it seems like clementine upstream is saying that they're just trying to namespace the sha2 functions so that it doesn't conflict with potential use with openssl libraries.
17:04:46 <abadger1999> Which means that we probably want the packager to propose namespacing to the sha2 upstream,
17:04:58 <abadger1999> Does anyone read anything differently into that ticket?
17:05:07 <limburgher> That's what I see.
17:05:16 <geppetto> dito.
17:05:18 <Rathann> I'm there with you
17:05:53 <abadger1999> Okay -- I'll ask the package maintainer to do that in the ticket.
17:06:02 <abadger1999> #topic #418     Bundling exception for reaver-wps
17:06:08 <abadger1999> https://fedorahosted.org/fpc/ticket/418
17:06:42 <abadger1999> I haven't looked at the code but the ticket description sounds like a fork to me.
17:07:04 <tibbs|w> The very nature of the changes renders them not upstreamable.
17:07:15 <Rathann> I'd like to see at least some standard questions answered though
17:07:26 <Rathann> i.e. are they following wpa_supplicant upstream
17:07:32 <Rathann> and rebasing on a regular basis
17:07:33 <Rathann> ?
17:07:36 * limburgher concurs, forky, but yes, the questions should be answered.
17:08:12 <abadger1999> Rathann: okay -- is that the only standard question you're interested in?
17:08:31 <limburgher> It does sound like they're going opposite directions. . .
17:09:33 <abadger1999> Rathann: also... would it change our vote?
17:10:18 <abadger1999> wpa_supplicant is for connecting securely to a wireless network.  reaver-wps is for trying to gain access to a network where you don't know the secret key.
17:10:38 <Rathann> right, I guess it wouldn't
17:11:03 <Rathann> but it does affect one thing
17:11:40 <Rathann> if we require reaver-wps to have Provides for the bundled code
17:12:13 <abadger1999> ah, that's osmething I hadn't thought about.
17:12:38 <abadger1999> Okay, I'll say we're leaning towards allowing this but want to know about rebasing to know if we should create a provide for it.
17:12:54 <Rathann> just for tracking
17:13:10 <Rathann> I'm +1 in principle
17:14:19 <abadger1999> #topic #421     Update environment modules guidelines
17:14:25 <abadger1999> https://fedorahosted.org/fpc/ticket/421
17:15:48 <tibbs|w> Hmm, is the diff there between that and the previous version accurate?
17:17:55 <orionp> https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FEnvironmentModules&diff=376234&oldid=121116  should give you all of the changes
17:19:02 <tibbs|w> Yeah, that's what I was looking at.
17:19:18 <tibbs|w> With the previous version being five years old, I wasn't sure.  But I guess we haven't touched this in ages.
17:20:04 <RemiFedora> changes seems fine
17:21:30 <geppetto> +1
17:21:32 <abadger1999> orionp: One quesiton -- you mention lmod at the end.
17:21:53 <geppetto> I'm not super happy with the change from i386 examples to x86_64 examples creating noise … but, meh
17:21:56 <tibbs|w> Why does my browser misrender the "Lmod" links to include a bunch of space after them?
17:22:04 <abadger1999> and say "such files must not be installed /usr/share/modulefiles"
17:22:06 <abadger1999> orionp: Wehere shoulkd they be installed, then?
17:22:37 <tibbs|w> Hmm, because it's an https link.  Interesting.
17:23:27 <geppetto> tibbs: I think there is supposed to be an icon after the link, like for env. modules
17:23:39 <geppetto> but the icon isn't rendering
17:23:45 <orionp> Ah, they should go into some of the lmod directories, I can add that.
17:24:14 <abadger1999> orionp: Cool.
17:24:25 <abadger1999> With that addition, I'm +1 to the update.
17:25:28 <abadger1999> Proposal: Approve updated environment modules draft with addition of Lmod location.
17:25:29 <abadger1999> +1
17:25:44 <limburgher> +1
17:25:47 <geppetto> +1
17:25:48 <racor> +1
17:25:57 <tibbs|w> +1
17:26:21 <RemiFedora> +1
17:26:28 <abadger1999> #info Updated environment modules draft with addition of Lmod location. approved (+1:6, 0:0, -1:0)
17:26:38 <Rathann> +1 from me as well
17:26:43 <abadger1999> #undo
17:26:43 <zodbot> Removing item from minutes: INFO by abadger1999 at 17:26:28 : Updated environment modules draft with addition of Lmod location. approved (+1:6, 0:0, -1:0)
17:26:47 <abadger1999> #info Updated environment modules draft with addition of Lmod location. approved (+1:7, 0:0, -1:0)
17:26:57 <orionp> Instead install into /usr/share/lmod/lmod/modulefiles/Core
17:27:19 <abadger1999> I had a request to finish the icecat/firefox discussion since that was close to being done but we didn't quite get to it.
17:27:31 <Rathann> orionp: lmod twice in the path?
17:27:34 <abadger1999> #topic Exception for bundled libraries in icecat
17:27:42 <abadger1999> https://fedorahosted.org/fpc/ticket/391
17:27:53 <orionp> Rathann - second is a symlink to the versioned directory
17:28:02 <abadger1999> So status: we'd approved several guidelines that would seem to allow firefox and icecat to bundle.
17:28:29 <abadger1999> we were getting ready to vote on exceptions specifically for them.
17:28:37 <Rathann> I was +1 to temp exception as they work through unbundling, but I need to leave now
17:28:48 <abadger1999> but then there was the thought that we should make these temporary exceptions.
17:29:00 <Rathann> sorry and bye
17:29:02 <abadger1999> which means we need to define when they'll expire
17:29:15 <abadger1999> Rathann: okay.  Thanks for coming!
17:29:49 <tibbs|w> Two releases is what we generally do.
17:30:53 <abadger1999> <nod>  But I think we are we going to remove either firefox or icecat if they aren't unbundled in two releases?
17:31:01 <abadger1999> sorry...
17:31:11 <abadger1999> Needed to ^U in there somewhere
17:31:17 <abadger1999> are we going to remove either firefox or icecat if they aren't unbundled in two releases?
17:31:25 <geppetto> for sure not firefox … or we'd already have done so
17:32:00 <tibbs|w> I think the point is more that we occasionally need to take stock of the situation.
17:32:15 * geppetto shrugs … I have no real problem with that
17:32:15 <abadger1999> Okay.  So.  we'll re-evaluate after two releases.
17:32:32 <abadger1999> do we specify that we want to see progress?
17:32:49 <geppetto> If it's just to reevaluate, I'd guess not
17:33:08 <geppetto> other than to say generic "please try and make icecat better"
17:33:39 <geppetto> meh.
17:33:39 <geppetto> +1
17:33:47 <tibbs|w> We already said that firefox at least is too big to fail, but I think it changes often enough that we do have to keep track of it.
17:34:03 <tibbs|w> Hopefully the packagers would do it, but they haven't so far.
17:34:09 <tibbs|w> Icecat folks at least seem to be trying.
17:34:14 <tibbs|w> Anyway, +1
17:34:25 <abadger1999> Proposal:  firefox has a temporary bundling exception since it has an active security team tracking issues in their codebase. icecat has a temporary exception since it is a fork of firefox that closely tracks firefox's changes.   We'll re-evaluate this before F22.
17:34:28 <abadger1999> +1
17:34:38 <tibbs|w> +1
17:35:03 <limburgher> +1
17:35:04 <geppetto> +1
17:35:05 <racor> I regret, I have to quit now.
17:35:21 <abadger1999> okay.
17:35:23 <racor> +1 to abadger1999 "Proposal", above
17:35:26 <abadger1999> racor: care to vote before leaving?
17:35:28 <abadger1999> k
17:35:32 <abadger1999> thanks!
17:35:37 <RemiFedora> +1
17:36:08 * RemiFedora also have to quit soon
17:36:10 <abadger1999> #info firefox has a temporary bundling exception since it has an active security team tracking issues in their codebase. icecat has a temporary exception since it is a fork of firefox that closely tracks firefox's changes.   We'll re-evaluate this before F22.  Passed (+1:6, 0:0, -1:0)
17:36:19 <geppetto> abadger1999: +7, rathan voted before leaving
17:36:26 <abadger1999> #undo
17:36:26 <zodbot> Removing item from minutes: INFO by abadger1999 at 17:36:10 : firefox has a temporary bundling exception since it has an active security team tracking issues in their codebase. icecat has a temporary exception since it is a fork of firefox that closely tracks firefox's changes.   We'll re-evaluate this before F22.  Passed (+1:6, 0:0, -1:0)
17:36:31 <abadger1999> #info firefox has a temporary bundling exception since it has an active security team tracking issues in their codebase. icecat has a temporary exception since it is a fork of firefox that closely tracks firefox's changes.   We'll re-evaluate this before F22.  Passed (+1:7, 0:0, -1:0)
17:37:20 <abadger1999> kalev: Are you around?
17:37:33 <abadger1999> RemiFedora: If kalev's around, we might be able to do one more.
17:38:03 <limburgher> I lost count, do we still have quorum?
17:38:15 <geppetto> I think we sitll have 5
17:38:15 <abadger1999> Until RemiFedora leaves we do.
17:38:21 <limburgher> k, cool.
17:38:21 <tibbs|w> I'm still here.
17:38:28 <abadger1999> #topic systemd or systemd-units should not be required if a spec file does a %systemd_post command
17:38:32 <abadger1999> https://fedorahosted.org/fpc/ticket/425
17:38:52 <abadger1999> geppetto: So panu's comment seems like it'll work: https://fedorahosted.org/fpc/ticket/425#comment:5
17:39:11 <geppetto> yeh, it'll probably fix the ordering thing
17:39:23 <geppetto> but I'd still much prefer a better fix
17:39:29 <abadger1999> k
17:39:30 <tibbs|w> Interesting; in the email I got, it showed as "!OrderWithRequires" and I wondered what the exclamation mark was for.
17:39:45 <geppetto> tibbs: wiki link with no page
17:40:32 <abadger1999> So I think what we have on the table is "Changing Requires(post): systemd to OrderWithRequires: systemd" <= should that be OrderWithRequires(post)?  or
17:40:53 <tibbs|w> Ugh; does that even work?
17:42:09 <geppetto> AIUI it works identicallt to Requires
17:42:10 <abadger1999> give systemd a virtual provide.  Have a fakesystemd package with the same virtual provide (only in container images?).  Have packages require the virtual provide.
17:42:34 <geppetto> yeh, I'm heavily +1 on the later
17:42:55 <geppetto> Also note that the first workaround _also_ requires moving stuff to filesystem
17:43:01 <tibbs|w> There was some objection to having a fake package, wasn't there?
17:43:07 <geppetto> And any other workarounds, for other unknown things.
17:43:22 <tibbs|w> It seems to make the most sense to me, but...
17:43:31 <geppetto> AFAIK the only objection was "it's more work than just deleting the deps."
17:44:02 <tibbs|w> Ah, except that deleting the deps doesn't work, so...
17:46:24 <limburgher> Discovered I have to go in 10.
17:46:46 <abadger1999> I think I could work with either one but I'm persuaded that I like the fakesystemd package better.
17:47:22 <abadger1999> geppetto: You want to continue the discussion?  I think that if dwalsh agrees to the fake package we'd just have to update the guidelines to Requires(post): VirtProvide
17:47:29 <abadger1999> where we == FPC there.
17:47:54 * geppetto nods
17:48:02 <tibbs|w> Do we want to bikeshed what VirtProvide actually is?
17:48:16 <geppetto> but doesn't seem much discussion … or you just want me to ping dwalsh about if he can do the fakesystemd thing?
17:48:33 <geppetto> tibbs: Let someone else, we can approve whatever colour they come up with :)
17:48:41 <tibbs|w> Fine with me.
17:48:55 <limburgher> systemd-fuscia
17:49:13 <geppetto> +1 ;)
17:49:32 <abadger1999> geppetto: yeah -- ping dwalsh and get him to get the packaging work done.
17:49:34 <limburgher> I want to watch people try to say fuscia unitfile quickly.
17:50:34 <abadger1999> if he commits to that path we shouldn't have any problem updating the guidelines to match.
17:50:49 * geppetto nods
17:51:11 <abadger1999> #topic Open Floor
17:51:21 <abadger1999> Okay, anyone have anything they want to bring up?
17:51:34 <limburgher> Nope, have to run.  Bye!
17:51:39 <mbooth> I have a quick SCL question
17:51:49 <abadger1999> mbooth: go for it.
17:52:13 <mbooth> Will it mandatory for SCL-ized versions of mainstream Fedora packages to live in branches?
17:52:42 * mbooth already has some packages containing scl macros
17:53:07 <abadger1999> mbooth: Yeah, those packages will have to change so that the scl macros are only in the scl branches.
17:53:17 <abadger1999> mbooth: well... that's according to our straw poll anyhow.
17:53:45 <mbooth> Ok great, will there be a draft of guidelines available some place?
17:54:04 <abadger1999> mbooth: yeah -- the work in progress is here: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)
17:54:32 <mbooth> Thanks abadger1999 :-)
17:54:36 <abadger1999> mbooth: The bit about SCL macros being eparate from mainstream packages may not be in there yet ... there wasn't a natural place to put it when I first looked.
17:54:49 <geppetto> I was mostly happy with allowing people to leave packages sclized in the main branch, if they wanted too (but heavily against requiring it)
17:54:50 * abadger1999 writes that down as something he has to put in.
17:55:15 <geppetto> However … after seeing how invasive it is for all non-trivial packages, I'm less sure about that
17:55:24 <abadger1999> The more I've looked, the less I like that approach... it's pretty invasive.
17:55:27 <abadger1999> yeah.
17:56:25 <mbooth> Yeah, and if a package is in multiple SCLs and they all need different subsets of BR/Rs from the SCL... It will get messy
17:56:37 <abadger1999> yep :-/
17:56:38 <geppetto> "messy"
17:57:02 <abadger1999> Okay, if there's nothing else, I'll close in 60s
18:00:09 <abadger1999> #endmeeting