16:00:06 #startmeeting fpc 16:00:06 Meeting started Thu Jul 9 16:00:06 2015 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:06 #meetingname fpc 16:00:06 The meeting name has been set to 'fpc' 16:00:06 #topic Roll Call 16:00:10 Howdy. 16:00:13 hi 16:00:34 #chair tomspur 16:00:34 Current chairs: geppetto tomspur 16:00:36 #chair tibbs 16:00:36 Current chairs: geppetto tibbs tomspur 16:00:59 * tomspur won't be here next week 16:01:14 ok 16:01:19 Should I send a mail to the list or is an entry in the vacation calender enough? 16:01:20 #chair orionp 16:01:20 Current chairs: geppetto orionp tibbs tomspur 16:01:34 morning 16:01:51 tomspur: If you can reply to next weeks schedule, that's easiest … if you won't be near a computer the day before, then it doesn't matter … I'll probably remember :) 16:02:07 geppetto: ok :) 16:02:28 If we knew in advance that we wouldn't get quorum we could just postpone the meeting. 16:03:01 Would be super nice if everyone who couldn't make it would tell us that they couldn't make it. 16:03:11 yeh 16:03:44 We did have that nice stretch where we had plenty of people, but not much luck lately. 16:04:38 yeh 16:04:42 it is summer though 16:04:46 outside is nice and warm 16:04:56 Depends on where you are. 16:04:59 ha 16:05:03 not here - cold and rainy 16:05:06 This is the time of year when we don't go outside. 16:05:28 although that's not typical here 16:06:06 Right now it's only 31C but with 99.99999% humidity. 16:06:06 I think my TB calendar reminders are back to hiding again 16:06:37 I'm doing some more cleanup on the tickets and then I just need to write up all of the python stuff and I'll actually be caught up. 16:07:13 I cannot get python3 built on f22 otherwise I'd start with the updates to ship the macros... :/ 16:07:36 why doesn't it build? 16:07:37 I don't know whether to close the Go ticket or to keep bugging them. 16:07:42 Will ask the python folks to just disable the one failing test... 16:07:46 We do need guidelines but I sure as hell can't write them. 16:08:34 geppetto: one failing test in the testsuite. test_gdb is disabled on a lot of arches and maybe just count arm into it... 16:08:45 * geppetto nods 16:10:02 So.... 16:10:12 Yeh, I don't think we are going to get anymore people 16:10:26 I've tried to ping the other 4 (mbooth said he couldn't make it) 16:10:30 And nobody is on IRC 16:10:44 We could talk about the bundling ticket … but I'm not sure it's worth it 16:11:05 Any opinions on what I should do with the Go ticket? 16:11:18 https://fedorahosted.org/fpc/ticket/382 16:11:27 I'm not sure 16:11:44 It's been something like four months since there was any information there about the actual guidelines. 16:12:36 hmm, maybe ask on the devel list if there are some people interested in it and want to continue? 16:13:05 I added something. 16:13:34 Honestly I think we shouldn't have had a single Go package in the distribution without at least minimal guidelines. 16:13:38 But reviewers don't care. 16:16:20 yeh, I mean some might 16:16:35 But esp. with docker/etc. … there's a lot of push to get those in 16:16:51 And Fedora isn't traditionally good at saying no. 16:16:58 Then there should have been a lot of push to get guidelines in. 16:17:10 #chair Rathann 16:17:10 Current chairs: Rathann geppetto orionp tibbs tomspur 16:17:14 hello, sorry for being late 16:17:16 And then there were 5! 16:17:22 * Rathann is on vacation 16:17:26 Ahh 16:17:28 It wouldn't have been hard to have something minimal. "This is where your files go. Here's an example spec. Suggest using this utility to generate packaging.". 16:17:32 #topic Schedule 16:17:34 https://lists.fedoraproject.org/pipermail/packaging/2015-July/010808.html 16:17:53 #topic #550 Darktable and Rawspeed internal library 16:17:53 .fpc 550 16:17:53 https://fedorahosted.org/fpc/ticket/550 16:17:54 geppetto: #550 (Darktable and Rawspeed internal library) – fpc - https://fedorahosted.org/fpc/ticket/550 16:18:17 tibbs: Yeh, if we are going to just bless some minimal thing it might be easy to get someone to write that 16:18:39 tibbs: The main problem was that all of it was a giant static lib. joke. 16:18:45 IIRC 16:19:01 That's true, but if it was that bad the packages shouldn't be in there at all. 16:19:17 And if it's OK for the packages to be in there then there should at least be guidelines. 16:19:22 yeh, I agree, but see about about Fedora and saying no. 16:20:02 I think it's a giant mess waiting for a disaster to happen … but, meh. 16:20:19 "RawSpeed is not at the moment a separate library, so you have to include it in your project directly." It seems that's the only reason for this bundled library exception request 16:20:58 but sorry for interrupting :) 16:21:09 nah, it's fine … I did change the topic :) 16:21:26 Yeh, rawcode looks like it's fairly active … and huge. 16:21:34 rawspeed, even 16:22:11 * Rathann notes nobody filed a bug saying it should be buildable as a shared library 16:22:27 But pretty much anything can be built as some kind of library. 16:22:32 ah wait 16:22:33 Even static is an improvement. 16:22:36 https://github.com/klauspost/rawspeed/issues/109 16:22:43 wc -l *.cpp is like 30k 16:22:54 so lol on that being a copylib 16:23:31 another 10k in headers 16:24:07 cool the git repo. has static binaries in it 16:24:31 I don't understand what they mean with a "release" when reading the ticket above... 16:25:06 Users should to a git checkout and "support for their [...] releases" 16:25:38 if there are only new cameras added it doesn't sound like they would break anything else much 16:25:47 This seems to be what we're coming too, just mash everything together 16:26:51 tomspur: seems like general bug fixes etc. are happening 16:27:07 looking at github graphs, it's actively developed 16:27:12 So why call it "Raw Image Decoder *Library*"? 16:27:59 it's fine if they don't want to make releases or guarantee API/ABI stability, but the packager should explain to them that these things make users' and packagers' lives easier 16:28:19 so a static library is a minimum requirement in this case I'd say 16:28:57 yeh 16:29:08 "is extensively crash-tested on broken files." - this is encouraging, but doesn't mean there will be no security bugs 16:29:47 also, the readme says something about "Version 2" 16:29:48 yeh, esp. considering: https://github.com/klauspost/rawspeed/commit/ebfe0d82a89623dd04fdc3db2693a5b288175e8c 16:30:11 Yeah, sorry, there's just no way I'm going to go for this. 16:31:01 I assume you are fine with a static lib? 16:31:07 also, it looks like it bundles pugixml, which we have packaged 16:31:54 Yeah, static lib is less good but still better. 16:31:55 rawspeed or darktable? 16:32:10 rawspeed 16:32:15 ok 16:32:45 #action Rawspeed is way too big/active to be a copylib. Make a static library. 16:33:01 and educate upstream about the benefits of shared libraries 16:33:01 #action Also rawspeed needs to unbundle pugixml 16:33:02 But if it has to unbundle something, that forces it to be a shared lib. 16:33:15 and of making proper releases with API/ABI stabilit 16:33:16 y 16:33:18 Unless someone makes a pugixml static package. 16:33:35 We can't force upstream to make proper releases, though it would be nice. 16:33:43 yeh 16:34:00 I'm not saying force, but educate and if possible provide a patch 16:34:01 I'd like proper upstream releases and a shared lib. … also a unicorn ;) 16:34:04 hehe 16:34:13 I'd settle for a pony. 16:34:16 Or a Dr. Pepper. 16:34:20 :) 16:34:28 I believe upstream needs to grow a build system first 16:34:49 It would be nice, but not really relevant. 16:35:09 #topic #508 New GID for openstack-neutron 16:35:09 .fpc 508 16:35:09 https://fedorahosted.org/fpc/ticket/508 16:35:10 geppetto: #508 (New GID for openstack-neutron) – fpc - https://fedorahosted.org/fpc/ticket/508 16:35:11 It seems upstream doesn't know why we want to unbundle. Maybe they at least do some (moving) tags from time to time :) 16:35:13 Fedora has to adapt and force it into some reasonable shape for packaging, even if upstream never takes it. 16:35:17 Pretty sure there's nothing to do here 16:35:26 Yeah, I think we should just close this. 16:35:48 But I do need to get back to that fun hack I was talking about in that ticket. 16:36:16 * geppetto nods 16:36:29 I'm not sure about comment 3 16:36:47 I think he's just saying "this would be nice … because cloud" 16:37:01 But maybe I'm missing something 16:37:05 I agree. 16:37:23 They don't say what breaks. 16:37:44 Or why this is different to any other random service that runs on cloud 16:37:48 There's really no argument at all besides "someone thinks they need it". They haven't articulated why they need it. 16:38:02 Or how having a fixed gid will help anyone setup ldap. 16:38:28 Also, how did the openstack things get gids assigned in the 160-170 range? 16:38:43 I don't recall having that discussion, but there are plenty of things I don't recall these days. 16:39:13 322 and 396 are the ones I can find 16:39:28 both of which are closed as negatives 16:40:12 so it looks like someone just allocated a bunch of ones they wanted 16:40:19 "someone". 16:40:54 https://bugzilla.redhat.com/show_bug.cgi?id=902987 16:41:03 I don't want to get into the "disparaging Red Hat" business but we all know how this stuff happens. 16:41:05 that's for 165 16:41:19 Nice. 16:41:35 We could save a lot of time by not caring. 16:41:40 ha 16:41:48 https://bugzilla.redhat.com/show_bug.cgi?id=845078 16:41:54 187 16:41:57 If nobody else does, what's the point? 16:42:35 so … doesn't look like any of these openstack daemons need a static uid 16:42:39 https://bugzilla.redhat.com/show_bug.cgi?id=732442 16:43:09 160-162 16:43:11 geppetto: I agree, but they gave them out anyway. Maybe it's just not as big of a deal as we thought it was. 16:43:15 wow, the best reasoning yet 16:44:05 To be fair … did we always look at this? 16:44:07 either we should review all static uidgid assignments or none - a lot of them seem to have sneaked in via bugzilla 16:44:18 not always 16:44:31 No, we didn't always look at this. 16:44:37 * geppetto is trying to remember if this used to be just "whatever the setup maintainer felt like doing" before 2013ish 16:44:39 These days I follow commits to the setup package. 16:44:50 * geppetto nods 16:44:59 But fedmsg has really made it difficult to follow things now, unless you like mail. 16:45:22 You can't filter things? 16:45:29 If you can figure out the interface. 16:45:33 ahh 16:45:53 There's no real way to do "this is what I want to see". 16:46:27 Hmm, what do you try to filter? It took me a while, but seems working (mostly) 16:46:31 Essentially all of my mail is ABRT reports, and setting the ABRT filter either way still gets me the reports. I had just clicked "watchcommits" on the kernel package. 16:46:38 Anyway, offtopic. 16:47:24 I'm still not in favor of the GID thing, and think that the other openstack ones shouldn't have been granted, either. 16:47:31 Kind of getting back to just rubber stamping uid allocation requests 16:47:52 Is there anyone we want to ask if we should be a lot more rubber stampy about these? 16:48:00 fesco? 16:48:02 fpl? 16:48:03 FESCo, I guess. 16:48:33 I remember hearing someone say that our pool was large enough to accommodate a whole mess of allocations. 16:48:48 If that's the case, then no big deal. But I thought we had only tens left. 16:48:48 yeh 16:49:02 I thought we'd got a lot more than that 16:49:08 but I wouldn't bet a lot on it 16:49:14 * Corey84 listens from back row 16:49:23 Maybe someone decided to say "you have a user with uid 500? too damn bad." 16:49:32 The main thing was that we can't ever really get any back … so we should be conservative in allocating anyway 16:49:50 tibbs: Yeh, default is now 1000 for first user, right? 16:50:01 Not sure what happens when/if we hit 500 though 16:50:07 Yes, it's 1000 now. 16:50:11 I don't remember when that changed. 16:50:26 a lot of people are going to find out what backwards compat. means at that point I guess 16:50:40 A few years ago 16:50:40 RHEL5 has it at 500. 16:50:58 RHEL6 has it at 500. 16:51:06 ugh 16:51:14 RHEL7 has it at 1000. 16:51:15 would have bet el6 had 1000 16:51:24 so … super super recent then 16:52:51 And of course in that 500 we still have to squeeze the static pool as well as the dynamic pool. 16:53:28 so... getting back to #508, I'm -1 unless they provide some specific scenario where having in dynamically allocated breaks things 16:53:49 s/in/it/ 16:53:51 Yeah, they should always describe in detail what breaks. 16:54:08 "We need it because cloud" is not really sufficient. 16:54:30 "We need it because it makes some unspecified or unrelated thing easier" isn't either. 16:54:36 I think the problem is that nothing breaks 16:57:34 #action Looking at previous openstack uid/gids we wouldn't have approved any of them, so look at filing a FESCo ticket to see if we should pass a lot more of these that don't really need it. 16:57:39 #topic Open Floor 16:58:02 Anyone want to volunteer to open the fesco ticket ?;) 16:58:12 I have nothing. Still hoping that a python with the new macros makes it to F22 soon. 16:58:41 yeh, that's on tomspur … right? Should happen when the py3 stuff gets solved? 16:59:18 It is coming, so I think I'll just push the new guidelines over the next couple of days. 16:59:33 * geppetto nods 16:59:36 There's always going to be confusion when we change this much anyway. 16:59:43 yeh 16:59:54 geppetto: yes. I just pushed the python2 to testing just in case 17:00:07 Can obviously tweak some stuff if anything comes to light anyway 17:00:07 Will try to ping the python folks tomorrow if it is save to just disable the test 17:00:08 * geppetto nods 17:00:18 I don't think I should just disable it without them knowing 17:00:52 You can always turn it back on. 17:01:14 But, sure, telling people is never bad. 17:01:19 yeh, the way I've done stuff like that in my packages if have a %global variables that controls it 17:01:35 Then it's easy to turn off if upstream fixes the test/whatever 17:01:50 So we're really getting the ticket count down. 17:02:08 I have one procedure to write up and three python tickets. 17:02:13 I just needed to backport a fix to get it built with a newer openssl, so python was FTBFS right now... 17:03:03 I don't think anything will ever happen with the scintilla thing. I should file some bugs but I don't expect anything to happen. 17:03:22 * geppetto nods 17:03:29 And I think that kind of completes everything we have going that isn't needinfo. 17:03:43 yeh 17:03:48 well, at the very least they should add provides: bundled(scintilla) 17:03:51 report 12 and 13 are pretty much empty 17:03:54 I think we requested that 17:04:07 Rathann: I actually did that. 17:04:10 cool 17:04:59 Not really much we can do unless someone wants to maintain an actual scintilla package. 17:05:15 (And I sure don't want to do it by myself.) 17:05:19 So … s/unless.*// 17:05:35 rdieter had talked about it. 17:05:42 interesting 17:05:45 But he has enough to do. 17:06:49 yeh, just surprised someone was thinking about it 17:07:05 He said he was just waiting for a bit of free time, but that was a couple of months ago. 17:07:26 Ha, yeh I know how that goes 17:08:43 Ok, see everyone but tomspur next week :) 17:08:48 thanks for coming 17:08:53 Thanks for running. 17:09:02 thank you 17:09:44 tomspur: Do let me know if you happen to get the updated py3 out to F22. 17:10:35 #endmeeting