16:00:43 <abadger1999> #startmeeting FPC
16:00:43 <zodbot> Meeting started Thu Jun 12 16:00:43 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:48 <abadger1999> #topic Roll Call
16:01:11 * RemiFedora here
16:01:33 <tibbs> Howdy.
16:01:40 <abadger1999> #chair RemiFedora tibbs
16:01:40 <zodbot> Current chairs: RemiFedora abadger1999 tibbs
16:01:43 * Rathann here
16:01:47 <abadger1999> #chair Rathann
16:01:47 <zodbot> Current chairs: Rathann RemiFedora abadger1999 tibbs
16:02:00 * geppetto is here
16:02:08 <abadger1999> spot, SmootherFrOgZ: FPC ping
16:02:12 <abadger1999> #chair geppetto
16:02:12 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs
16:03:37 <abadger1999> #topic #339     software collections in Fedora
16:03:42 <abadger1999> https://fedorahosted.org/fpc/ticket/339
16:04:10 <abadger1999> I talked to the lsb guys and licquia said he'd be processing the lanana requests this week.
16:04:34 <abadger1999> If spot doesn't get a response about allocating the fedora name he can ping licquia next week to get movement on this.
16:04:58 <abadger1999> langdon: I think you're up... do you have some new proposals around naming?
16:05:52 * SmootherFrOgZ is around
16:06:11 <langdon> abadger1999: not "new" i don't think... i think what you have/we discussed works
16:06:11 <abadger1999> #chair SmootherFrOgZ
16:06:11 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto tibbs
16:06:58 <abadger1999> langdon: okay.  So to be clear, that includes SCL team being okay with dots in name?  Or do you not speak for them for that case?
16:07:52 <langdon> arggh.. i think i forgot to follow up with them on it..
16:07:57 <langdon> let me see if i can confirm
16:07:57 <abadger1999> okay.
16:08:40 <abadger1999> RemiFedora: Did you ever talk to people about the scldevel subpackage?
16:09:02 <RemiFedora> I know what it is used for => dependent package
16:09:14 <RemiFedora> this is just an helper
16:09:27 <RemiFedora> mostly defining 2 macros
16:09:50 <abadger1999> RemiFedora: yeah -- so I'm looking for a "bright line" definition of what macros belong in -scldevel vs what macros belong in -build
16:09:56 <abadger1999> Can you explain the difference?
16:10:08 <RemiFedora> -build is for package "in" the SCL
16:10:33 <RemiFedora> and -build override system macros
16:10:51 <RemiFedora> ex, with python27, %{_python} is the python path in SCL
16:11:05 <abadger1999> <nod>
16:11:40 <RemiFedora> if you build another SCL, that use python, you don't requires python27-build
16:12:11 <abadger1999> RemiFedora: meaning -- another SCL that requires the python27-scl version of python?
16:12:16 <RemiFedora> so you have to use the   %{python27_python} macros
16:12:22 <RemiFedora> yes
16:12:54 <abadger1999> k
16:13:02 <RemiFedora> to resume
16:13:18 <RemiFedora> python27-python-devel => defines %{python27_python}
16:13:47 <RemiFedora> python27-build => overrides %{_python} with value of  %{python27_python}
16:14:46 <RemiFedora> python27-scldevel => iirc only provides %{scl_python} = python27 (or name of the collection providing python
16:15:15 <RemiFedora> I think the idea, is to manage generic package for various SCL.
16:15:20 <geppetto> but the rpmbuild phase is usually done by scl enable python27 … then using %{_python} is within the scl, so maps. via. the chroot.
16:15:27 <geppetto> So what is the -build package for?
16:16:14 <RemiFedora> geppetto,  the idea is to use    scl enable %{scl_python}  ...    python
16:16:28 <RemiFedora> python being the one in the path, so the one in the collection
16:16:52 <RemiFedora> then if you put python27-scldevel , your package will use python27
16:17:07 <RemiFedora> then if you put python33-scldevel , your package will use python33 without any change
16:17:09 <geppetto> but the second python will be %{_python} … which will now map to the scl path, which won't exist within the scl chroot
16:17:42 <geppetto> Unless you are saying you build scls without the -build package?
16:17:49 <RemiFedora> that's why I say you must use "python"
16:17:49 <geppetto> But then wtf is the -build package for?
16:18:06 <abadger1999> I think the -build package is for building packages within the scl
16:18:12 <RemiFedora> yes
16:18:17 <abadger1999> So if you take the "simple" case of only a single scl.
16:18:20 <abadger1999> You would have
16:18:22 <geppetto> RemiFedora: So you have to change all the spec files to not use %{_python} anymore?
16:18:43 <abadger1999> fdr-python2.7-build which overrides macros like %{__python} to point to the pyhton in the fdr-python2.7 scl.
16:18:58 <abadger1999> Then you have a package inside of hte scl like fdr-python2.7-python-json
16:19:33 <RemiFedora> it will BR fdr-python2.7-build
16:19:53 <RemiFedora> well... this one have to be in the buildroot before srpm creation...
16:19:54 <abadger1999> That package would BR: fdr-python2.7-build and be able to use the %{__pyhton} and get /opt/fedora/scls/fdr-python2.7/root/usr/bin/python
16:20:01 <RemiFedora> yes
16:20:20 <abadger1999> RemiFedora: So it sounds like scldevel is for inter-SCL use.
16:20:26 <RemiFedora> exactly
16:20:46 <RemiFedora> if you buld a fdr-yum-4  SCL
16:21:26 <RemiFedora> each package will probably BR  fdr-yum-4-build and fdr-python2.7-scldevel
16:21:27 <abadger1999> RemiFedora: So question -- in your description, you talk about python27-python-devel having the underlying macro that defines the proper paths rather than python27-scldevel.... why is that?
16:21:54 <RemiFedora> humm... where us define %{_python} in system python
16:22:06 <abadger1999> RemiFedora: Also -- it soounds like fdr-yum4-build should simply Require: fdr-python2.7-scldevel.   Correct?
16:22:40 <RemiFedora> correct
16:22:51 <abadger1999> RemiFedora: Okay -- so if that's the case, why can't we just BR: fdr-python2.7-python-devel?  Why do we have to go through the -scldevel subpackage?
16:23:14 <RemiFedora> you can simply  BR: fdr-python2.7-python-devel
16:23:23 <abadger1999> okay...
16:23:30 <abadger1999> So why do we have the scldevel package?
16:23:36 <abadger1999> It sounds like it doesn't have any purpoes..
16:23:57 <RemiFedora> but is you want to be able to rebuild the "same" spec against python27 and 33, you can use the macro provided by python##-scldevel
16:24:38 <RemiFedora> this -scldevel is specially design to make you crazy ! ;)
16:24:50 <abadger1999> oh yuck.
16:25:11 <RemiFedora> just more "generic" more "complex" more "crazy"
16:25:59 <Rathann> RemiFedora: I don't understand that last part
16:26:04 <abadger1999> So..
16:26:09 <Rathann> <RemiFedora> but is you want to be able to rebuild the "same" spec against python27 and 33, you can use the macro provided
16:26:12 * abadger1999 has to type this out to make sure he understands
16:26:19 <Rathann> by python##-scldevel
16:26:19 <RemiFedora> Rathann, which part ? taht we just want to make abadger1999 crazy ?
16:26:23 <abadger1999> We now have the second SCL package.
16:26:27 <abadger1999> err
16:26:30 <abadger1999> Second SCL.
16:26:59 <abadger1999> A package within the second SCL is supposed to build using fdr-python27
16:27:22 <abadger1999> So what it does is have a BR: fdr-python2.7-scldevel
16:27:26 <abadger1999> Then it uses the macro
16:27:36 <Rathann> RemiFedora: what does -scldevel give us that plain fdr-sclname-package-devel doesn't?
16:27:59 <geppetto> Rathann: the -scldevel package provides the macro mapping scl => python27 … I think
16:28:02 <abadger1999> %{scl_python_python}  which expands to the python interpreter in fdr-pyhton2.7-pyhton
16:28:04 <abadger1999> and similarly
16:28:08 <RemiFedora> Rathann, imagine you have a fdr-yum4pythin27 SCL,    fdr-yum-4-pythn-2.7-build requires fdr-python-2.7
16:28:24 <RemiFedora> sorry
16:28:31 <RemiFedora> fdr-yum-4-pythn-2.7-build requires fdr-python-2.7-scldevel
16:28:31 <abadger1999> %{scl_python_pythonsitelib} which expands to the sitelib path inside of fdr-python2.7
16:28:32 <geppetto> Rathann: So then when you do stuff like: scl enable %scl … that does different stuff depending on which -scldevel
16:28:41 <RemiFedora> fdr-yum-4-pythn-3.3-build requires fdr-python-3.3-scldevel
16:29:15 <geppetto> ok
16:29:26 <RemiFedora> then package in theroy, can be build in both collection without any change
16:29:32 <abadger1999> Then the packager wants to build the package against fdr-python2.6 instead of python 2.7.
16:29:34 <RemiFedora> theory
16:29:58 <RemiFedora> fdr-yum-4-pythn-2.6-build requires fdr-python-2.6-scldevel
16:30:00 <geppetto> RemiFedora: so … why isn't that possible if the -scdevel stuff is in the -build package?
16:30:10 <Rathann> RemiFedora: wait, don't I need to specify different BRs to build in each collection?
16:30:16 <abadger1999> So they change the BR to BR: fdr-python2.6-scldevel and the macros that get pulled in should now point to the other location.
16:30:28 <RemiFedora> because -build define the scl_prefix, so you can only requires 1 -build
16:30:57 * abadger1999 is not sure we want to support this use case...
16:31:02 <RemiFedora> so in 1 collection you cannot BR the -build of an other collection
16:31:28 <RemiFedora> Rathann, in the SCL design the -build is in the default builtroot...
16:31:48 <geppetto> But you can require multiple -scldevel … why? how does that work?
16:31:52 <RemiFedora> so the same package can be build in 2 collection just playing with the default buildroot in koji
16:31:52 <abadger1999> (another observation: scldevel is overriding certain macros... but the macros they override are macros only used in packaging scls, not in packaging system packages)
16:31:54 <Rathann> ah, it's a separate koji target, isn't it?
16:32:12 <Rathann> ok, it sort of makes sense now
16:32:52 <geppetto> I understand the multiple buildroots part … but I still don't understand why the -build and -scldevel split
16:33:13 <geppetto> what thing is in one, that can't be in the other.
16:33:21 <dgilmore> Rathann: seperate koji tagets with different buildroots
16:33:30 <abadger1999> -build overrides macros that vanilla packages would also use (ex: %{_libdir}
16:33:43 <RemiFedora> yes for the current collection
16:33:49 <dgilmore> there is a bit of overhead in setting up and having an scl but we will deal
16:34:27 <abadger1999> -scldevel overrides macros that other scl packages would use (ex: %{scl_python_python}) which is an scl-specific version of %{__python}
16:34:32 <RemiFedora> dgilmore, yes more work for you... 1 buildroot per SCL... (this is how it works in brew)
16:34:34 <abadger1999> RemiFedora: ^ That correct?
16:34:44 <geppetto> abadger1999: But those aren't overrides … are they?
16:35:26 <dgilmore> RemiFedora: right and afaik we will need to tweak the minimal buildroot contents per scl
16:35:27 <abadger1999> Wellllll..... I guess in a sane world, the packager would specify BR such that only a single -scldevel package would define a certain macro
16:35:30 <geppetto> abadger1999: Stuff like python27_python … it's not used by vanilla packages, but then it also doesn't affect them so why not just ship it in -build and let them ignore it?
16:35:33 <RemiFedora> if you have 2 SCL, each one have a different %{_libdir} => the reason why you can't BR 2 -build packages
16:35:34 <dgilmore> but thats a one off thing setting up the scl
16:36:14 <abadger1999> geppetto: But We can't ship it in -build because the 2nd SCL has to be able to get python27_python without getting the overridden %{_libdir}.
16:36:27 <geppetto> RemiFedora: Again … this implies that you think people will be BR multiple -scldevel packages … so I ask again, why?
16:37:00 <abadger1999> geppetto: So we're talking here about interdependent scls....
16:37:03 <RemiFedora> you can't BR 2 scldevel like python27-scldevel and python33-scldevel
16:37:05 <abadger1999> I'm building an scl.
16:37:21 <abadger1999> That means my package has to Require: fdr-myscl-build
16:37:30 <geppetto> ok
16:37:38 <abadger1999> That pulls in fdr-myscl-scldevel via dependencies
16:37:41 <RemiFedora> but you can't if you are crazy enough  requires  python27-scldevel, ruby192-scldevel, php55-scldevel
16:37:43 <dgilmore> RemiFedora: i guess the question is how do you layer SCL's to depend on other SCL's
16:38:07 <abadger1999> Now -- in this hypothetical the package I'm building also depends on a 2nd scl
16:38:08 <geppetto> abadger1999: yeh, got that
16:38:30 <RemiFedora> <abadger1999> That means my package has to Require: fdr-myscl-build => you means BR ? yes (except if it is installed in the defautl buldroot)
16:38:50 <dgilmore> abadger1999: i would think you would want the macros for the target scl so only need one lot of definitions for building
16:38:52 <abadger1999> Let's say I'm building fdr-python2.7-python-mysql  and the mysql version I'm targetting is from fdr-mysql5.1-mysql
16:39:12 <abadger1999> RemiFedora: yeah, BR.  thanks
16:39:54 <RemiFedora> your package BR fdr-python2.7-build (main SCL), and possibly fdr-mysql5.1-devel (dependent SCL)
16:40:04 <abadger1999> geppetto: So then My package would also BR: fdr-mysql5.1-scldevel so that I could get a version of the macros for building against mysql that I need.
16:40:13 <RemiFedora> right
16:40:27 <geppetto> abadger1999: but that's just broken
16:41:07 <geppetto> abadger1999: you now have a package living in the fdr-python2.7  scl which requires fdr-mysql5.1
16:41:16 <abadger1999> yep.
16:41:28 <geppetto> abadger1999: But the fdr-mysql5.1 scl knows nothing about the other scl … how does that work
16:41:52 <geppetto> What about when someone wants a version of your package to use fdr-mysql6.1
16:42:03 <geppetto> This is the whole nested universes thing
16:42:32 <geppetto> AFAIK the only sane way to do your myscl thing is to include both fdr-mysql5.1 and fdr-python2.7 _inside_ your myscl
16:42:34 <abadger1999> I don't think fdr-mysql5.1 would need to know about the other scl.  None of its packages would require it.
16:42:43 <RemiFedora> 1 real example (in rhscl) we have httpd24 which is a SCL and php55 which is another SCL and depend on httpd24
16:43:17 <geppetto> RemiFedora: But doesn't that need to install mod_php stuff?
16:43:23 <RemiFedora> at build php time we enable the httpd24 scl to buid mod_php
16:43:43 <geppetto> RemiFedora: At which point you then can't install a php60 scl at the same time, or you'd break httpd24 scl
16:43:59 <geppetto> due to having two modules that are the same, etc.
16:44:18 <RemiFedora> as for system httpd, php and php54 both provides mod_php. both can be installed (only 1 willwork)
16:44:43 <Rathann> which brings me back to my original conclusion that SCLs are a bad idea :(
16:45:17 <RemiFedora> Rathann, same problem with base package. If you have mod_scgi for python 2 and mod_wsgi for python 3
16:45:30 <abadger1999> RemiFedora: Hmm... I've thought of a potential difficulty..... Say the fdr-mysql5.1 package is providing a python binding.  Then it would have to modify PYTHONPATH in order to have that loaded by the system python.
16:45:31 <RemiFedora> SCL doesn't change this
16:45:58 <geppetto> RemiFedora: right … system php and php54 work fine, because one uses the httpd24 scl and the other doesn't.
16:46:07 <RemiFedora> no
16:46:15 <geppetto> RemiFedora: But what about a different php60 scl which always wants to use the httpd24 scl
16:46:16 <Rathann> RemiFedora: it is a lot of work that doesn't solve this in either
16:46:19 <Rathann> so why do it
16:46:27 <RemiFedora> gepetto php54 provides modèphp for system httpd
16:46:29 <abadger1999> RemiFedora: But when we have the fdr-python2.7-python-mysql package, it would also wantto touch PYTHONPATH to be a different directory.
16:46:57 <langdon> abadger1999: isn't thta solved at runtime with "scl enable ..."
16:46:58 <RemiFedora> abadger1999, path order, so collection order
16:46:59 <geppetto> RemiFedora: wait, what? … why does it depend on http24 scl then?
16:47:22 <RemiFedora> php54 provides mod_php for system httpd, php55 provides mod_php for httpd24
16:47:23 <langdon> geppetto: i think we are mixing talking about examples and real world instances
16:47:52 <abadger1999> langdon: I don't think so.  We're doing the equivalent of "scl enable fdr-python2.7 && scl enable fdr-mysql5.1"  That could result in conflicts to the PATHs
16:47:58 <langdon> geppetto: sys php and the php54 scl both work with sys httpd... php55 works with scl-httpd24 on rhel
16:48:00 <RemiFedora> but I some time php54 provides mod_php for both httpd and httpd24, like php55
16:48:09 <geppetto> langdon: ok
16:48:45 <geppetto> langdon: so it's php55 that needs the dual -scldevel packages?
16:48:54 <RemiFedora> and when we have php54 with mod_php for httpd24 and php54 with mod_php for php55, it was working. No probleù
16:49:05 <langdon> abadger1999: see RemiFedora's comment .. it is order in scl enable.. you don't do what you wrote you do "scl enable scl1 scl2 bash" which sets the path priority order
16:49:20 <geppetto> langdon: … so to change my question then, what happens when a new scl php54/php60 or whatever is needed that wants to work against the httpd24 scl
16:49:26 <abadger1999> RemiFedora: that might work... what is the order that things are added to the PATHs?  What do we need to specify about that in the Guidelines?  (I guess probably all of it since packagers are responsible for writing the script that drives scl enable)
16:50:03 <geppetto> langdon: The -scldevel fix solves the building, but I don't see what solves the install side of the problem
16:50:11 <abadger1999> langdon: I don't understand your terminology or the relevant differences in what you and I wrote.
16:50:15 <RemiFedora> geppetto, the php60 can provide mod_php for httpd24. I don't see any problemù
16:51:12 <RemiFedora> php60 enable httpd24 at build time to find httpd-devel, and provides an .so for httpd 2.4
16:51:41 <langdon> abadger1999: i am clarifing that the "scl application" sets the order of paths based on the order you pass it names of collections.. the "scl application" may or may not do it in the same order as running "scl enable" multiple times.. that is the distinction i was making, although in practice I think they would be synonomous..
16:52:16 <geppetto> RemiFedora: I don't see how the multiple php scls co-ordinate on putting data in the http24 scl?
16:52:39 <langdon> geppetto: a guess as to the confusion: using pathing makes the httpd24 scl think that it has something in its conf dir from php...
16:52:55 <langdon> geppetto: we dont actually write the mod_php file in the conf dir
16:53:02 <RemiFedora> as for system file. When a SCL package put a file in base system tree (ex a systemd unit file), it have to be prefixed using the SCL name
16:53:14 <langdon> geppetto: theoretically .. (my spelling is rough today)
16:53:17 <geppetto> langdon: so … httpd24 needs to run from the php55 scl?
16:53:21 <abadger1999> langdon: k.  AFAIK, the scl application doesn't have any way to decide what order to set the paths... the paths are set by %{_scl_scripts}/enable for each scl.
16:53:25 <RemiFedora> so httpd.service and httpd24-httpd.service
16:53:58 <langdon> abadger1999: it runs the enable scripts in order (right now) .. so the last in the list would have the earliest paths...
16:54:12 <abadger1999> langdon: So I think the scl application can choose the order that the enable scripts are run but it can't do intelligent reordering of the env variables set by those scripts.
16:54:19 <RemiFedora> so for mod_php, you will have    php55-libphp.so,  php56-libphp.so... etc
16:54:48 <langdon> geppetto: so httpd24 scl needs to be run from the context of the php55 scl... scl enable php55 httpd24 bash (right RemiFedora ?)
16:55:08 <RemiFedora> hm... bad example... php scl doesn't need to be enabled....
16:55:20 <RemiFedora> it just work (c)(tm)
16:55:21 <abadger1999> So.. we're at the end of an hour.
16:55:23 <geppetto> langdon: ok, that makes some sense
16:55:36 <langdon> RemiFedora: the php55 one does need httpd24 .. right?
16:55:43 <abadger1999> I think we should find each other on IRC this week to continue discussing these things...
16:55:54 <RemiFedora> ok
16:55:56 <abadger1999> But I think we need to move on to other business within the meeting.
16:56:11 <langdon> abadger1999: yes, i think scl enable is still pretty dumb in that regard.. so it leaves it to the "operator" to order them correctly.. which is probably not brilliant..
16:56:11 <geppetto> abadger1999: I'm thinking we probably need a call, with some example rpm files we can look at?
16:56:27 * Rathann usually has time around 22:00 CEST, but I need to know a day in advance
16:56:31 <RemiFedora> php55 doesn't need http (or httpd24) except php55-php (mod_php) which, of course, requires httpd (or httpd24)
16:56:37 * abadger1999 also wonders if inter-scl packaging is just too compex to make it workable at this time.
16:56:48 <geppetto> abadger1999: right … that's my main worry
16:57:00 <abadger1999> geppetto: I don't know about a call but example files will help.
16:57:16 <abadger1999> I can update my python2.4 scl to try implementing -scldevel...
16:57:26 <langdon> RemiFedora: so.. ok.. may be a bad example.. spacing on the individual scl details.. but if php55 was scl-depends on httpd24 it would be a good example..
16:57:30 <RemiFedora> abadger1999, we can live without -scldevel...
16:57:31 <abadger1999> Right now the things that would be in -scldevel are in my python2.4-python-devel package.
16:57:47 <RemiFedora> yes php55 spec is an example
16:58:00 <RemiFedora> (which doesn't use -scldevel)
16:58:31 <abadger1999> RemiFedora: You mean... we don't need them in any Fedora packages?
16:58:39 <RemiFedora> yes
16:59:03 <RemiFedora> because when we create the php SCL, -scldevel doesn't exists
16:59:21 <RemiFedora> so php55-scldevel exists (but don't use httpd24-scldevel)
16:59:30 <abadger1999> k  I don't fully understand scldevel so that's tempting but similarly I don't fully understand -scldevel so I'm afraid to ban essential functionality.
17:00:18 <abadger1999> The real question is probably whether ruby1.9.3 requires it as that is the set of scl packages that will land in f21.
17:00:27 <RemiFedora> abadger1999, I will try to write a small example.... (with python if possible... bnut you know... I'm not a python expert)
17:01:25 <abadger1999> and actually... since there's scl interdependence there (rails requires (ruby and v8)) it probably does need scldevel?
17:01:50 <Rathann> guys, I need to go now, sorry
17:02:04 <abadger1999> Rathann: k.  Sorry for taking up the whole hour with one topic.
17:02:31 <abadger1999> Or I guess... scldevel just makes the dependencies "more generic" so it's not needed....
17:02:38 <abadger1999> Bah.  Have to think on this during the week.
17:02:48 <abadger1999> Let's move on.
17:03:03 <abadger1999> #topic #382     Go Packaging Guidelines Draft
17:03:07 <abadger1999> No update from vbatts
17:03:15 <abadger1999> #topic #414     Please consider requiring AppData for all desktop
17:03:19 <abadger1999> So there's a snag here.
17:03:50 <abadger1999> the AppData upstream specification only allows a subset of licenses for the metadata.
17:05:26 <abadger1999> I really don't want to make upstreams add new licenses to their code base and I'm not enthused about having to add more license information to the license tag either.
17:05:29 <RemiFedora> this seems really strange
17:05:40 <geppetto> I'm also confsued about what happens if they don't comply
17:05:49 <RemiFedora> so we are going to have at least 2 license in each package, 1 for the app, 1 for the appdata file
17:06:02 <abadger1999> Yeah, I'm not sure from the ticket what exactly is doing the validation.
17:06:09 <geppetto> Like if they just ship an AppData but it's default licensed the same way the rest of their code is
17:06:26 <geppetto> does the packager have to delete it, and/or clean room re-create it?
17:08:01 <RemiFedora> move the appdata to a subpackage with its own licence that nobody will install at it is absolutly uneeded at runtime
17:10:00 <geppetto> lol
17:10:09 <RemiFedora> geppetto, I was serious !
17:10:54 <rdieter> (it *might* be needed ondisk by some appstream consumers, so not installing it isn't a viable option yet, imho)
17:10:56 <geppetto> but that still doesn't solve how it gets (re-)created
17:11:13 <geppetto> They aren't installed in the traditional sense, AIUI
17:11:17 <RemiFedora> why do you want to create it ?
17:11:20 <geppetto> AIUI the package contains an appdata file
17:11:25 <RemiFedora> if upstream provides it, use it
17:11:33 <RemiFedora> else submit a patch to upstream
17:11:47 <geppetto> And then at createrepo time something thakes all those bits of data out of the packages and creates a repometdata file containing all of the data
17:12:08 <geppetto> And the appdata consumers use the metadata file
17:12:28 <rdieter> geppetto: not all do (yet)
17:12:34 <geppetto> but I'm still confused about what happens if upstream supplies an appdata file that doesn't "comply" with the licensing.
17:12:39 * RemiFedora thinks of setting this file as %doc
17:12:52 <RemiFedora> geppetto, file a bug
17:13:51 <abadger1999> RemiFedora: if and only if the file isn't used at runtime.
17:14:40 <RemiFedora> afaik it is not used
17:15:12 <geppetto> So … do we have any precedence on policy limiting licenses ues?
17:15:23 * geppetto can't think of any
17:16:12 <abadger1999> heh, the example on the draft has three errors
17:16:19 <geppetto> :)
17:16:32 <geppetto> that should probably be fixed then
17:16:40 <abadger1999> appdata-validate reports:
17:16:41 <abadger1999> • tag-invalid           : <metadata_license> is not valid
17:17:03 <abadger1999> I'm not sure if the extent of validation is that appdata-validate reports things
17:17:07 <geppetto> is appdata-validate really outputting in utf8?
17:17:16 <abadger1999> or if the appinstaller will also validate
17:17:25 <abadger1999> yes, yes it is.
17:17:42 <abadger1999> $ LC_ALL=C appdata-validate test.xml
17:17:44 <abadger1999> test.xml 4 problems detected:
17:17:46 <abadger1999> ? markup-invalid        : <id> does not have correct extension for kind
17:17:48 <abadger1999> and so on.. ;-)
17:17:50 <geppetto> :)
17:18:23 <geppetto> stuff that runs in %check outputting utf8 without needs seems stupid, but w/e
17:19:00 <geppetto> Anyway … I guess I'm -1 on examples that have errors, and requiring a subset of valid Fedora licenses
17:19:07 <geppetto> apart from that I'm +1
17:20:24 * abadger1999 agrees with geppetto
17:22:47 <abadger1999> Okay then... I'll write to the ticket that we discussed this today, found that the example didn't validate, that we weren't happy with non-ascii output but that's not a blocker, and we're not okay with the subset of licenses.
17:23:19 <geppetto> sure
17:23:22 <abadger1999> ruby scls I think we covered in the general scl discussion
17:23:32 <abadger1999> %py3dir...
17:23:42 <abadger1999> #topic #435     %py3dir not removed by rpmbuild --clean
17:23:46 <abadger1999> No response to this in ticket yet.
17:24:07 <geppetto> This seems like it should be fixed in python or rpmbuild
17:24:11 <abadger1999> I've pinged bkabrda and he's considering it... he only sees an array of "less bad" options though.
17:24:50 <geppetto> yeh, I just don't see why we are invovled … there's a bug, someone needs to fix it … people are doing crazy hack fixes atm.
17:25:13 <abadger1999> There seemed to be an ugly but workable solution in the linked bug but someone brought up that unittest harnesses doing test discovery could break (because it would attempt to test python3 code under pyhton2).
17:25:14 <geppetto> but we don't want to randomly pick one crazy hack fix for policy … just have python or rpmbuild fix it
17:25:41 <abadger1999> Anyhow... more work to discuss with bkabrda next week.
17:26:20 <abadger1999> #topic #409 Ruby guidelines update https://fedorahosted.org/fpc/ticket/409
17:26:31 <geppetto> 409??
17:26:35 <abadger1999> There were a few other minor changes asked for after we approved the main body of this
17:27:14 <geppetto> fair enough
17:27:31 <geppetto> so we are voting on: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=379237&oldid=376267 ?
17:28:16 <geppetto> no, more than that it looks like … that's just the final one
17:28:18 <abadger1999> I think this is the diff... https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FRuby&diff=379237&oldid=373557
17:28:38 * abadger1999 opens up the current Guidelines page to check
17:29:40 <geppetto> I'm +1 on that
17:29:51 <RemiFedora> +1
17:30:21 <abadger1999> +1
17:30:23 <geppetto> Are we generally ok with stuff like: {gem.build_complete,*.so} instead of using two lines?
17:30:45 <SmootherFrOgZ> +1
17:30:55 <RemiFedora> if often use {xx,yy}...
17:30:58 <RemiFedora> I
17:31:02 <abadger1999> I am in general as long as it remains readable.
17:31:04 <SmootherFrOgZ> geppetto: I'm
17:31:15 * geppetto nods ... fair enough
17:31:29 <abadger1999> We're at +4.
17:31:39 <geppetto> tibbs: ping?
17:31:40 <tibbs> +1
17:31:49 <geppetto> fast ;)
17:31:51 <abadger1999> Cool
17:32:11 <abadger1999> #info Further small updates to ruby guidelines approved (+1:5, 0:0, -1:0)
17:32:26 <abadger1999> #topic #436     Bundled code advise for shiboken
17:32:33 <abadger1999> https://fedorahosted.org/fpc/ticket/436
17:33:25 <geppetto> ok, I think I'm +1
17:34:17 <abadger1999> I think I
17:34:21 <abadger1999> 'm +1 as well.
17:34:33 <geppetto> I'mless clear on if they are shipping them though, or if shiboken is just using them in it's build
17:34:44 <RemiFedora> +1
17:34:47 <geppetto> If they are shipping them, it seems like they should be sub-package
17:34:52 <abadger1999> rdieter: Do you know anything about shiboken/apiextractor/
17:34:57 <geppetto> if it's just used in the build, bundling seems fine.
17:35:32 <rdieter> abadger1999: just a little
17:35:33 <geppetto> At the very least, if shipping them, shiboken should obsolete and provide the package names.
17:35:52 <RemiFedora> yes
17:35:56 <abadger1999> rdieter: I'm just wondering if really, the upstream devs of apiextractor have moved their code into the shiboken source or if the apiextractor devs are no longer around and shiboken devs have decided to bundle the code.
17:36:11 <SmootherFrOgZ> hmmm, if this part of shiboken why not provide them as subpackage?
17:36:11 <rdieter> I thought it was the former
17:36:15 <abadger1999> Cool.
17:36:26 <abadger1999> That's an easy one to say yes to, then.
17:36:54 <geppetto> rdieter: Ok, they are shipping apiextractor to the system at install time, right?
17:36:56 <rdieter> <nod>, I told jreznik not to bother with bothering you guys since I thought it obvious, but ... :)
17:37:18 <rdieter> geppetto: I do not believe so, it's only used during the build iirc
17:37:26 <abadger1999> It's always better to open the ticket... that way there's a record of precedent for the future :-)
17:37:37 <geppetto> rdieter: ok … yeh, then trivial +1 :)
17:37:50 <rdieter> I could be wrong, I only touched the pkg a bit
17:38:17 <geppetto> yeh, in this case as long as they do the obsoletes+provides I'm happy if they ship it too
17:38:23 <geppetto> so no big deal.
17:38:41 <abadger1999> I count +3 so far.
17:38:57 <abadger1999> SmootherFrOgZ, tibbs: Do you want to vote on this?
17:39:05 <SmootherFrOgZ> what geppetto said then +1
17:40:03 <RemiFedora> well... GLPI RPM works perfectly with SELInux enabled... but I'm afraid of mariadb
17:40:29 <RemiFedora> (sorry, bad paste)
17:40:38 <geppetto> RemiFedora: :)
17:40:56 <abadger1999> :-)
17:41:11 <abadger1999> Okay, I'll look for one more vote on ticket.
17:41:52 <abadger1999> #info Bundling exception for shiboken Need one more vote in ticket.  So far (+1: geppetto, abadger1999, RemiFedora, SmootherFrOgZ, 0:0, -1:0)
17:42:08 <abadger1999> #topic Open Floor
17:42:16 <abadger1999> Anyone have anything for open floor?
17:42:24 <abadger1999> Any old tickets that need looking at?
17:42:49 <RemiFedora> just like to heard your feeling about spec file license.
17:43:05 <abadger1999> RemiFedora: as in, what is the license of spec files?
17:43:07 <RemiFedora> I notice other distro ask for "explicit" license on each spec
17:43:22 <RemiFedora> we have a implicit MIT license (per CLA)
17:43:58 <RemiFedora> and sometime have thin implicit is bad (I'm now used to add an explicit license header in each of my spec)
17:44:12 <abadger1999> https://fedoraproject.org/wiki/Licensing:Main#License_of_Fedora_SPEC_Files
17:44:15 <RemiFedora> yes
17:44:24 <RemiFedora> what I call "implicit"
17:44:27 <abadger1999> <nod>
17:44:42 <abadger1999> I trust Fedora enough that I'd rather stick with this.
17:45:11 <RemiFedora> problem is not Fedora. Problem is people pulling our spec, cleaning the %changelog, and claiming this is their work
17:45:29 <RemiFedora> (in other distro / repo)
17:46:12 <RemiFedora> (ok, they can also clear the license header...)
17:46:28 <abadger1999> probably something to discuss when spot's around.
17:46:36 <RemiFedora> yes
17:47:02 <abadger1999> Anything else?
17:47:13 <abadger1999> If not I'll close in 60s
17:48:26 <abadger1999> #endmeeting