17:01:07 #startmeeting fpc 17:01:07 Meeting started Thu Jan 14 17:01:07 2016 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:07 The meeting name has been set to 'fpc' 17:01:07 #meetingname fpc 17:01:07 #topic Roll Call 17:01:07 The meeting name has been set to 'fpc' 17:01:14 Howdy. 17:01:16 Hey 17:01:18 #chair tibbs 17:01:19 Current chairs: geppetto tibbs 17:01:21 morning 17:01:25 #chair orionp 17:01:25 Current chairs: geppetto orionp tibbs 17:01:38 orionp: Where are you? 17:01:46 west coast? 17:02:17 Boulder Colorado 17:02:36 Hi 17:02:48 #chair mbooth 17:02:48 Current chairs: geppetto mbooth orionp tibbs 17:02:58 * racor is here 17:03:06 #chair racor 17:03:06 Current chairs: geppetto mbooth orionp racor tibbs 17:03:14 And then there were five ;) 17:04:09 orionp: Nice 17:04:38 I like it here... 17:05:19 * geppetto nods 17:05:36 West, but not too west … and pot ;) 17:06:01 #topic Schedule 17:06:11 hi 17:06:16 #chair Rathann 17:06:16 Current chairs: Rathann geppetto mbooth orionp racor tibbs 17:06:27 https://lists.fedoraproject.org/archives/list/packaging%40lists.fedoraproject.org/message/JIHUTVVX4FRAXUGJGQB7Q3TU2UMQHDNO/ 17:06:36 #topic #587 Node.js Guideline ExclusiveArch incorrect 17:06:39 .fpc 587 17:06:41 geppetto: #587 (Node.js Guideline ExclusiveArch incorrect) – fpc - https://fedorahosted.org/fpc/ticket/587 17:07:07 I think this is pretty simple? 17:07:27 Does anyone remember/know why noarch was added there in the first place? 17:07:51 I think the whole thing is broken... 17:08:17 The nodejs recommendations go against the main guidelines 17:08:33 that say that ExclusiveArch is just broken 17:08:55 Well, we approved them..... 17:09:13 You can't build locally without noarch listed, I'd be surprised if it built on koji without it 17:10:11 orionp: did anyone test? 17:10:22 I found this in Toshio's wiki: https://fedoraproject.org/wiki/User:Toshio/Noarch_with_unported_dependencies 17:10:40 koji will look at noarch in ExclusiveArch and say it can be built on any arch 17:10:41 I think that's because of portability of node.js is long term. problem, and unlikely to be fixed. 17:10:55 So any new arches added aren't going to work, etc. 17:11:40 orionp: there is other packages that have ExclusiveArch and BuildArch: noarch 17:12:34 the compose toolses use ExcludeArch/ExclusiveArch in those cases to filter what repos the packages get shipped in 17:13:00 I don't understand why rpmbuild fails locally without noarch but not in the builders... 17:13:07 if that is indeed the case 17:13:10 though it may be that we say you use ExcludeArch with BuildArch: noarch 17:13:24 but a side effect is you play koji roulette 17:13:29 We had to do this exact same thing with Java. 17:13:36 if it needs to build on a specifc arch 17:13:40 tibbs|w: right 17:13:57 koji has no way to say you can only build this package on this one arch 17:14:33 But the Java guidelines no longer have any mention of *arch. 17:14:45 tibbs|w: we have java everywhere now 17:14:53 except ppc in el6 17:15:02 Yeah, just makes it more difficult to see what we did say to use. 17:15:19 tibbs|w: pretty sure it was ExcludeArch: ppc 17:15:44 I can see why you would need to add noarch to the exclusiveArch list 17:15:54 rpm says its not in the list 17:16:12 but it does not take away that koji will send it to any arch in teh tag 17:16:39 it may just be pure luck that it has not been an issue before ppc64le was added 17:16:42 FYI - I've filed http://rpm.org/ticket/901 17:17:11 I can't see that exclude/exclusive was ever in the java guidelines, so maybe it was just something that people did to workaround what happened when you happened to get a ppc builder. 17:17:19 You almost certainly want that in BZ.redhat.com 17:17:39 it may just be that there is 8 ppc64le builders as opposed to 4 ppc64 17:17:49 I think https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies is fairly clear on the whole thing 17:17:49 there used to be only 2 ppc64 builders 17:19:17 Ok … so can we solve this for everything? 17:19:36 tibbs|w: if you got a ppc builder you just resubmit until you get a x86_64 one 17:19:38 Or do we have to break rpmbuild or have people randomly retry node.js packages? 17:19:39 sucks 17:19:44 but thats what you have to do 17:20:01 geppetto: the solution is to just resubmit 17:20:07 Yeh 17:20:16 I'm guessing people don't like that though, given the ticket :) 17:20:19 if they do not want to do that they have to make the packages archful 17:20:27 Builds fail without noarch listed: https://kojipkgs.fedoraproject.org//work/tasks/8730/12548730/build.log 17:20:48 orionp: givn the use of ExclusiveArch it makes sense 17:21:00 Nice to get a recommendation that doesn't work... 17:21:24 As far as I'm concerned, whatever works is good. 17:21:29 I guess this is a reject then, given their solution doesn't work. 17:21:41 Whatever doesn't work is not particularly good. 17:21:53 You need to use excludearch, which is a pain because that changes all the time 17:22:01 but perhaps with a macro... 17:22:05 Having to resubmit whatever portion of the billion nodejs packages which fail is not particularly good, either. 17:22:11 I thought we had a macro? 17:22:12 orionp: took some extra thought 17:22:16 #info That's just how koji works, noarch is needed for rpmbuild removing it doesn't fix the problem. Just have to resubmit until you get a correct arch. 17:22:45 If there's something we can recommend in the guidelines, we should do that. 17:22:47 orionp: there is two options, resubmit or make the packages archful 17:23:02 Is it really a problem to have them archful? 17:23:02 dgilmore: So excludearch also doesn't do anything? 17:23:04 tibbs|w: there is nothing really. other than expect pain 17:23:09 or use ExcludeArch, right? 17:23:12 geppetto: nope 17:23:19 ok 17:23:21 Besides duplication of, what, a thousand packages? 17:23:44 #info ExcludeArch also doesn't do anything. FWIW. The only other option is to make the packages arch. 17:23:56 geppetto: koji looks at the "BuildArch: noarch" and says we can send this to any bulder and get a noarch rpm out 17:24:07 ok 17:24:08 noarch == anyarch in this case 17:24:13 * geppetto nods 17:24:26 that people disagree on what noarch actually means does not help 17:24:27 I'm guessing that's not easy to fix? 17:24:35 not sure 17:25:10 I'm sure koji could be taught to have some extra per-package config, but that seems inefficient in any case as you'd have to do it for every nodejs package. 17:25:34 And I don't know how we can export any useful information from the srpm that koji could use. 17:25:55 It would be a horrible hack to reuse some other tag. 17:26:21 tibbs|w: koji would probably need to do extra processing on the spec/srpm and figure out that it has the ExcludeArch/ExclusiveArch list and send the build to one of the arches 17:26:35 and in the ExclusiveArch case filter out noarch 17:26:38 It really seems like koji should handle this better... 17:26:58 orionp: That may be the case, but we deal with the tools we have. 17:27:07 forever? 17:27:17 orionp: its not going to any time soon. I know when I brought it up with the mikes for java they felt that what was being done was wrong 17:27:29 maybe now the response would be different 17:27:35 Sure, unless someone from the committee actually is going to do the coding work _and_ that actually gets accepted and rolled out. 17:27:35 and we can get something in 17:27:41 In what way was it wrong, and what should it be? 17:27:41 but it will need a koji RFE 17:27:48 I'm guessing they thought it should be arched? 17:27:53 geppetto: that noarch == anyarch 17:27:59 so there should be no filtering on it 17:28:04 * geppetto nods 17:28:18 But, really, from our perspective, can't we just say that the packages should be archful and leave it at that? 17:28:29 tibbs: I once tried to setup a koji instance, that one time was once enough 17:28:30 I mean, file RFEs, sure. 17:28:54 But right now today, the nodejs maintainers seem to have two choices: 17:29:01 Yeh, archful or play the resubmit game 17:29:05 Right. 17:29:11 tibbs|w: I would suggest that a RFE be filed, but that in the interim if you do not want to play koji roulette you make the packages archful 17:29:14 And the later seems to have got a lot less fun 17:29:22 And the latter just isn't reasonable for the amount of packages and churn they have. 17:29:31 Their choice, I guess. 17:29:35 * geppetto nods 17:29:39 But nothing we can really do. 17:29:47 nada 17:29:48 Except edit the guidelines page. 17:30:13 https://fedorahosted.org/koji/ticket/210 17:32:20 Ok 17:32:26 I guess that's it then 17:32:33 #topic #567 Packaging Python 3 applications and modules for EPEL 7+ 17:32:38 orionp: so thats a rpm bug not koji 17:32:38 .fpc 567 17:32:39 geppetto: #567 (Packaging Python 3 applications and modules for EPEL 7+) – fpc - https://fedorahosted.org/fpc/ticket/567 17:32:44 Not sure we have anything to discuss here? 17:34:27 I think we still have https://fedoraproject.org/wiki/PackagingDrafts:Python that adds the link to the EPEL7 guidelines 17:34:28 Don't think so. There is a python-macros package now 17:34:57 * geppetto nods … so We can close the ticket? 17:35:02 Is that in a ticket? I thought I wrote up everything that was pending. Though I still need to announce something. 17:35:34 https://fedorahosted.org/fpc/ticket/567#comment:10 17:35:45 wow, comment 10 was a long time ago :) 17:35:53 Oh, sorry, it's not in writeup state so I didn't see it. 17:36:56 orionp: Is that diff still everything we want: https://fedoraproject.org/w/index.php?title=PackagingDrafts%3APython&diff=cur&oldid=422445 ? 17:37:09 orionp: https://pagure.io/koji/issue/19 17:37:09 I sure hope not. 17:38:00 no, really just the last EPEL7+ section 17:38:08 I don't think that corresponds with the macros we have currently in development in any case. 17:38:16 Ok, that seems trivial 17:38:33 which I guess still is a draft... 17:38:43 I'd probably just put it way up front or something. 17:38:53 * geppetto nods 17:38:53 orionp: Yeah, we all need to come together on that. 17:39:07 We're not going to know how well it works until we can actually convert something. 17:39:15 #action Incorporate the EPEL7 section of the draft from orionp 17:39:41 The macros shouldn't conflict, though, so it should be possible to add them to your macros package and work from there. If we wanted to do that. 17:42:08 * geppetto nods 17:42:11 $topic Open Floor 17:42:15 #topic Open Floor 17:42:25 That was easy. 17:42:27 Ok, anything anybody wants to bring up? 17:42:47 One thing to write up, and then I can press send on this announcement and close a bunch of tickets. 17:42:49 Any general thoughts/comments on the BLAS/LAPACK stuff? 17:42:57 One minor thing is that devconf is in a couple of weeks, so I'll miss at least one Thursday for that. 17:43:08 Also Fosdem 17:43:09 orionp: That ticket is kind of beyond me. 17:43:41 I will not be present for the meeting in the week before fosdem due to traveling 17:43:42 orionp: The only other suggestion I have is to maybe talk to the MPI people … as they had to go through similar things. 17:44:08 Yeah, I'm pretty much one of the MPI people too... :) 17:44:14 mbooth: Is FOSDEM at least somewhere nice and warm? 17:44:22 orionp: Ahh … you so LUCKY! 17:44:44 On a related subject, I note that Intel has their own distro which handles the per-cpu-family optimizations for this kind of library. 17:44:52 geppetto: Brussels, so only marginally further South than where I am now 17:44:53 I wonder how they do that, and why we can't do the same. 17:45:21 tibbs: Does it do it how glibc does it? 17:45:38 "function multiversioning" 17:45:42 https://clearlinux.org/ 17:45:49 Yeh, I'd assume so then 17:46:06 Although those two words could mean anything ;) 17:46:14 https://clearlinux.org/features/function-multiversioning-fmv 17:46:30 I think it's something their compiler does. 17:46:34 orionp: what blas/lapack stuff? 17:46:44 Which probably bones AMD just for fun. 17:46:51 Rathann: https://fedorahosted.org/fpc/ticket/588 17:46:59 Oh that seems to be an icc features 17:47:25 Yeh, not like what glibc does at all then 17:47:26 Oh well. 17:47:34 oh, it looks like I missed this one 17:48:06 I wish we could have drop-in blas/lapack implementations 17:48:58 * orionp still waiting for hdf5 to finish on arm.... 17:49:16 but yeah, I agree with deciding on one canonical implementation 17:49:24 is openblas available everywhere now? 17:50:41 looks like it is 17:50:42 nice 17:50:43 There are a couple of other random things we could talk about. 17:50:54 One is file triggers. 17:50:58 The other is that %license thing. 17:51:47 Rathann: still no ppc64 17:51:57 just ppc64le 17:52:12 ah 17:52:59 and no aarch64 17:53:58 tibbs: file triggers, still waiting on me to do a proposal … and rpm bugs to get fixed. 17:54:22 Do we know how those rpm bugs actually block the file triggers we want to use? 17:54:59 Or, are there any we could implement without having to worry about those bugs? And if not, what about the current uses of file triggers already in the distro? 17:55:05 AIUI … you move from scriptlets to file triggers and rpm doesn't call the file triggers when it should … then people get annoyed because you went from working to not working. 17:55:45 Yeh, I did wonder about the current users … if they'd just assumed they worked, and were used in cases where it wasn't obvious if the triggers weren't always called 17:55:47 You'd think that if they were that broken, the rpm folks would either be telling us not to use them, or working like crazy on fixes. 17:56:08 I don't even know how to debug them if they aren't working. I'm not sure rpm even tells you when they run. 17:56:19 rpm guys are busy on the rpmdb format change. 17:57:10 The rpm verbosity levels might tell you, but it didn't inspire confidence that the systemd guys were putting echo statements everywhere. 17:57:21 Right. 17:57:40 I did think the 1284645 bug would have been fixed by now though 17:57:47 Though not to be a dick, but maybe the rpm folks could debug one feature before getting super busy with another. 17:57:55 :) 17:58:16 Also, I was in a discussion somewhere about systemd never being able to use file triggers because they won't have enough information to do what is necessary. 17:58:38 huh … that's interesting … you know where it happened? 17:59:02 I think on one of the mailing lists. 17:59:06 :) 17:59:13 sorry, guys, but I have to drop off now 17:59:22 Rathann: no problem … almost done anyway, I think 17:59:26 See you next week. 17:59:28 take care, bye 17:59:44 It was on fedora-devel; "no systemd in containers: Requires -> Recommends" 17:59:55 December 17 or thereabouts. 18:00:03 #action geppetto Look for systemd can't use file triggers discussion. 18:00:15 #action geppetto Ping rpm people about 1284645. 18:00:23 tibbs: Thanks 18:00:49 Good luck finding that in the new archives. 18:02:36 I just want a subject list, not a highly paginated forum. 18:03:08 I email archive devel list locally 18:03:29 In theory I read it too … but usually only when someone points to something. 18:03:54 "Only the package scriptlets know whether some service is installed or upgraded and have enough information to properly support presets and restarts." 18:04:26 Ahh 18:04:34 Anyway, I guess the whole is too complicated to really do much work before F24 branches. 18:04:53 Well, yeh, given it still has bugs 18:05:38 I had hoped that there were at least some simple cases where it could be used. 18:05:47 * geppetto nods 18:05:54 I mean, ldconfig is about the simplest scriptlet of all. 18:05:57 As you said, we already have a few users 18:06:11 And the most used (besides probably the texlive scriptlet, because texlive). 18:06:55 Yeh, ldconfig could probably be converted anyway … even with the bugs 18:08:00 It's something that needs experimentation, I guess. 18:08:05 * geppetto nods 18:08:24 Anyway … anything else, or I'll close in a minute or so and let everyone get some lunch. 18:08:33 And the %license thing, can we just not deal with it until we see if I can get epel-rpm-macros in? 18:08:54 It's in EL6 stable now; I just need to file a ticket to get it in the buildroot. 18:09:10 I am doing mass rebuilds for testing, but I keep running into unrelated bugs. 18:09:28 Like I can kill the kernel keyring with all of my kerberos tickets from running builds on a pile of hosts. 18:09:47 Once that gets sorted, I can build EPEL6 in about an hour. 18:10:20 yeh, seems fine to me 18:18:42 Sorry, someone was at the door. 18:18:58 no problem … busy reading devel threads anyway 18:19:06 Anyway, any macro change has the potential to break something so that's why I'm testing. 18:19:11 Anyway … I think we are done here, right? 18:20:02 But since no mass builds are done, EPEL6 is in worse state than I'd hoped. 18:20:15 * geppetto nods 18:20:27 Anyway, yeah, I'm done. I really want to get the mass build and final analysis of EPEL6 done today. 18:20:34 Cool 18:21:56 #endmeeting