17:00:25 #startmeeting Fedora Packaging Committee 17:00:25 Meeting started Wed Apr 4 17:00:25 2012 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:28 #meetingname fpc 17:00:28 The meeting name has been set to 'fpc' 17:00:32 #topic Roll Call 17:00:48 * limburgher here 17:02:00 Hmmm. http://www.youtube.com/watch?v=1Cw1ng75KP0 17:02:14 * spot laughs 17:02:58 rdieter, geppetto, SmootherFrOgZ, abadger1999, tibbs|h: ping 17:03:08 here 17:03:39 wow, the 80s really threw up on that video 17:03:48 * abadger1999 here 17:03:56 Yeah. It's still no Total Eclipse of the Heart. 17:04:17 * abadger1999 has been talking to vondruch this morning... seing if he'll come in here. 17:04:26 Howdy. 17:04:27 abadger1999: ruby? 17:04:32 May I ask you guys to have a look at ticket 154 first, and see if it can be processed quickly? If you can't vote on it within, say, 15 minutes, then you may suspend it and do things in the order you otherwise would. 17:04:48 I'm here for the fourth Wednesday in a row, hoping that my proposal will be processed today. 17:04:49 yeah 17:05:03 * spot has 154 as item #1 on the agenda already 17:05:13 Great! 17:05:24 Cool, so if we get quorized we'll get on it. (lost count) 17:05:37 limburgher: we're at 5, so just barely. 17:05:58 * spot apologizes for missing last week, long string of events lead me to be without laptop. :/ 17:06:10 Goldberg'd! 17:06:17 Hi guys 17:07:00 okay guys, lets try to knock out 154 quickly 17:07:10 Don't call it a comeback. . . 17:07:16 #topic Ada Guidelines changes - https://fedoraproject.org/wiki/User:Rombobeorn/Ada_Guidelines_Changes 17:07:45 the only item in the proposal that i have any issue with is the one about permitting source packaging 17:07:55 i just don't see the point in packaging source files 17:08:13 spot: lzma-sdk? :) 17:08:30 (ducks) 17:08:31 limburgher: eh, thats a nasty case, but even that is a library and headers now 17:08:36 If it were C, those sousce files would be .h files. 17:08:38 spot: Fair point. 17:08:56 Rombobeorn: are other ada packages trying to use them in the same sort of way as .h files? 17:08:57 Rombobeorn: Can you elaborate? 17:09:01 And all could be used by my Ada app to build? 17:09:14 The full source of a library is required just to build something else? 17:09:59 How have we been getting by without that so far? 17:10:03 Ada programs using a library will need the .ads files, like a C program needs .h files. In some cases some .adb files are also needed. 17:10:34 Rombodeorn: at build or at runtime? 17:10:44 OK, that seems to be well described by the first bullet point under "Devel package". 17:10:53 * abadger1999 adds "respectively" to the gnatmake compilation change 17:11:10 The problem is that it's hard to manually keep track of exactly which .adb files are needed, so some makefiles just install them all.' 17:11:23 limburgher, at buld time. 17:11:43 Romboeorn: Ok. 17:11:48 hmm, okay 17:12:00 so i think i'm fine with the proposed wording change given that context 17:12:12 "Ada library packages MUST have a -devel subpackage containing all the files that are necessary for compilation of code that uses the library. This includes Ada specification files (*.ads), Ada body files (*.adb), Ada library information files (*.ali) and GNAT project files (*.gpr). (There is no requirement to include all body files. Typically only some body files are needed.) " 17:12:13 So BuildRequiring would involve splitting them out and it gets ickier from there, so this is probably better. 17:12:43 And which .adb is left to maintainer discretion? 17:12:49 limburgher: makes sense 17:13:18 So, I'm +1 here 17:13:34 Me too, +1. 17:13:56 The point is to just let the maintainer use the upstream buildsystem instead of forcing him to rewrite the whole thing. 17:14:23 Does anyone recall how we dealt with something similar to the gnat arches stuff before? 17:14:27 Rombobeorn: there may still be cases where the upstream buildsystem is throwing the kitchen sink into the filesystem 17:14:40 Rombobeorn: so we still expect maintainers to use common sense and nuke useless files 17:14:42 I think it was in regards to mono but it could have been ocaml, java, or something else. 17:15:00 spot: Yes, of course. 17:15:21 * abadger1999 can remember a lot of discussion but not whether we decided it was good to do that way or good to not do it that way 17:15:29 abadger1999: i think it was mono, and i think we okayed it 17:15:50 %{mono_arches} 17:16:29 Does any supported release have fedora-gnat-project-common < 2? 17:16:37 abadger1999, there are already several other *_arches macros. 17:16:59 tibbs|h: not in fedora 17:17:32 We have other rules about dropping version-dependent dependencies when there's no point, so.... 17:18:20 tibbs|h: yeah, that line could probably be dropped safely. 17:18:38 tibbs|h, OK, so: If the "directories" project is used, then the -devel package MUST have an explicit "Requires: fedora-gnat-project-common". 17:18:49 I note that the Note at the end was removed; did that change happen or does it not really matter? 17:18:49 Rombobeorn: *nod* 17:18:54 * spot ninja edits it in. 17:19:17 * rdieter back from lunch, sorry i'm late 17:19:28 Oh, doh, that's answered earlier in the document. 17:19:39 * spot sees +2 on the draft 17:20:00 +1 17:20:06 * rdieter reads quickly 17:20:10 I'm going through a visual diff. 17:20:14 * spot needs to teach the bot to handle voting 17:20:39 We should probably make a requirement to actually provide some sort of diff we can look at when folks propose guideline changes. 17:21:39 +1 worksforme 17:21:50 vote is at +4 17:21:54 +1 17:22:02 tibbs|h: Is there a better way than the diff that the wiki provides? 17:22:06 abadger1999: want to vote on the record? 17:22:08 +1 17:22:20 #action draft approved (+1:6, 0:0, -1:0) 17:22:27 Does the change of project_dir imply a rebuild? 17:22:32 Rombobeorn: sorry for the delay, thanks for your patience. :) 17:22:48 I guess that's not our domain, but otherwise I expect that things would be busted. 17:23:29 tibbs|h, yes, a rebuild of all Ada libraries, in Rawhide, but it can be done gradually. 17:23:30 And I don't really know of a better way to do a diff. Generally you copy the original document, edit it and give us a link to the diff. 17:24:53 okay, lets dive into ruby (again) 17:24:56 OK, thanks guys! 17:25:13 #topic Ruby guidelines - https://fedorahosted.org/fpc/ticket/134 - https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft 17:25:31 before we get too deep into this, i actually spent some time last week fixing some broken ruby packages 17:25:36 i am not a ruby guru by any means 17:25:46 Did this change from last time? Doesn't look like it. 17:25:48 but using the old model, i simply was unable to patch anything sanely 17:26:10 switching to toshio's draft model got it to a place where i could apply patches and get alexandria working again 17:26:16 Excellent. 17:26:25 tibbs|h: It hasn't from last week. 17:26:38 so, minor points of contention aside, this is a notable improvement from my perspective 17:26:48 spot: 17:26:56 is everyone on the same page now? I seem to recall seeing some mail back-n-forth onlist recently. 17:27:17 abadger1999: My vision went all blurry on the last few comments, does it need any more changes in light of that exchange? 17:27:18 So at the moment, vondruch (via IRC) and bkabrda (on the ml) have talked about the (I think it's the) last remaining point 17:27:21 (though I agree the draft is better than any other alternative atm) 17:27:38 Whether to special case the rubygem module and place it in its own special directory. 17:27:52 Is there any chance we could leave that for later? This whole thing has taken long enough. 17:27:59 abadger1999: as opposed to /usr/share/rubygem/ ? 17:28:03 Right. 17:28:23 What's the argumnt for special-casing, in a nutshell? 17:28:23 rubygem seems to just be a non-gem ruby library. 17:28:29 * spot thinks that is perhaps the most minor issue of them all (and i am aware that i may have originally raised it) 17:28:40 spot, alexandria is not gem if I am not mistaken 17:28:50 vondruch: no, but the three broken rubygem deps were. :) 17:28:51 That our ruby maintianers are actively working on to make interpreter independent (although it's not there yet and there's resistance from upstream). 17:28:59 Would not special-casing it introduce any potential bootstrapping issues? 17:29:24 since it's standard, there doesn't seem to be any reason not to just leave it in the ruby stdlib (or in vendorlib). 17:29:53 The arguments I've heard are that we'd have two copies of the same code on the filesystem. 17:30:31 Symlink? 17:30:38 Ugly hack? 17:30:52 limburgher, systematic solution? :) 17:30:53 abadger1999: does upstream prefer /usr/share/rubygems ? 17:31:07 vondruch: pfft. :) 17:31:11 or is that a fedora-ism? 17:31:13 spot, there have been no response 17:31:20 spot: afaict, and condruch might be able to tell more -- the answer is no. 17:31:29 *vondruch 17:31:47 it seems like they're perfectly happy with rubygem module living in the std library path. 17:31:54 where would it be if we moved it into the std lib path? 17:32:02 and would %{gem_dir} move too? 17:32:49 or is the whole issue here that "rubygems" is sitting in %{gem_dir} when it isn't a gem? 17:32:59 spot: We would like to convince upstream that optional placement of RubyGems is advantage 17:33:11 spot, This proposal was nor accepted nor rejected 17:34:10 if this is the only remaining contention in the draft, i say leave it as is, and if upstream rejects the placement in /usr/share/rubygems, we'll revisit it. 17:34:51 %{gem_dir} is different topic ... actually I am not sure if I am confused now or the abadger1999's draft is wrong? 17:34:59 the rest of the draft works very well and improves ruby packaging significantly (IMHO) 17:34:59 spot: --with-rubygemsdir='%{rubygems_dir}' \ controls where we place the rubygem module (this looks like it's added to ruby's configure by our patch) 17:35:06 spot: Given your experience using this as is. . .+1 17:35:21 +1 to the draft as is now 17:35:23 abadger1999, yes, somewhere close to the patch should be link to upstream issue 17:35:28 +1 17:35:28 Still +1 on this. 17:35:40 +1 to the draft. 17:35:41 * spot sees +4 on this draft 17:35:42 +1 17:35:49 spot, there again arose the issue with virtual provides on Ruby-SIG 17:36:20 spot: +1 on my own draft 17:36:36 http://lists.fedoraproject.org/pipermail/ruby-sig/2012-April/000954.html 17:36:55 vondruch: at this point, i think it would be most productive to have the ruby sig propose specific changes to the guidelines 17:37:03 I'm still willing to talk about this rubygems module path but... so far no one's presented an argument that seemed to warrant special casing. 17:37:13 I need to step away for a few minutes. 17:37:15 spot, ok, np 17:37:16 we've held up on this for long enough 17:37:18 vondruch: that way we can get the rest in practice. 17:37:29 #action Draft approved (+1:6, 0:0, -1:0) 17:37:57 playsound("Cork_pop.ogg"); 17:38:00 yah! 17:38:09 abadger1999, vondruch: thank you for the effort on this, not fun at all, i know. :) 17:38:35 #topic Clarification for bootstrap compilers - https://fedorahosted.org/fpc/ticket/157 17:38:42 * limburgher hoists abadger1999, vondruch on shoulders, runs around room, dumps gatorade on them 17:38:46 imho, this is obvious easyfix stuff. +1 17:39:02 vondruch: That looks like it could be something -- could you get me more information (maybe srpms of slimgems?) asap? 17:39:19 +1 17:39:20 +1 17:39:21 +1 to 157. 17:39:33 +1 17:40:27 * spot gives geppetto a moment to vote on 157 17:41:44 He might be rusty, it's been awhile since we discussed more than one or two tickets in a meeting. 17:42:06 +1 17:42:09 abadger1999, will try, but I have no better leverage then mailing list :) 17:42:24 Getting late here, so I'm leaving 17:42:27 bye 17:42:34 vondruch: (Quick look at slimgems -- it looks somewhat like python's setuptools vs distribute ... where we decided that for something so core we would need to 17:42:41 vondruch: just choose one or the other. 17:42:52 vondruch: Bye, thanks! 17:42:56 vondruch: (Curently python-setuptools ships distribute rather than setuptools) 17:43:17 vondruch: so I'll need to see a packaging implementation to start asking questions. 17:43:54 #action Draft approved (+1:6, 0:0, -1:0) 17:44:03 now, on to the fun one 17:44:24 #topic libexecdir guideline does not allow for /usr/lib/%{name} fallback 17:44:31 #topic libexecdir guideline does not allow for /usr/lib/%{name} fallback - https://fedorahosted.org/fpc/ticket/158 17:44:35 -1 17:44:50 well, here's the problem. 17:45:15 systemd is not using %{_libdir}/%{name} or %{_libexecdir}/%{name} 17:45:28 so either systemd is violating the guidelines or we need to permit this use case. 17:45:59 I'm not sure that systemd violating the guidelines has ever really been a concern for those involved. 17:46:09 It's likely systemd. 17:46:15 spot: Is there a compelling reason for systemd not to follow the guidelines here? 17:46:30 Obviously at least the unit stuff belongs in /usr/share, except of course that before there was no /share so /lib made (some) sense. 17:46:41 if i'm thinking back on past discussions correctly, I think this was argued about when systemd lived in "/" and there wasn't a /libexec 17:46:51 and wasn't a /share 17:46:55 limburgher: aside from kay's belief that everything should be in /usr/lib/%{name} instead of libexecdir or %{_libdir} 17:47:23 spot: So not really. 17:47:28 * spot refers to ticket 139 17:47:32 https://fedorahosted.org/fpc/ticket/139 17:48:07 From that ticket, from Kay: "Recommending %{_libdir}/%{name} is just utterly wrong. It must be %{_prefix}/lib/%{name}. Using /usr/lib64/foo/ for anything that is not *.so makes absolutely no sense at all. " 17:48:12 To be honest, I'm not sure that we have to do anything here. 17:48:25 yeh, well -1 on that too 17:48:34 well, the logical step would be to ask FESCo to fix systemd 17:48:42 The systemd folks will just keep right on doing whatever they feel like regardless of what we say. 17:48:53 Do we generally do that? 17:49:17 geppetto: this is the only case i can think of where someone has been aware of the guidelines and flagrantly disregarded them 17:49:25 geppetto: I think we generally open a bug -- if the bug is closed wontfix we/the bug reporter escalates to fesco. 17:49:37 abadger1999: we could ask the ticket reporter to do that. 17:49:44 abadger1999: really? … fair enough. 17:49:47 I'm not sure it's so flagrant when the pre-usermove history is considered. 17:49:49 spot: sounds like a plan :) 17:50:06 not saying whether that's a good way of doing business or not -- just that's how it usually happens. 17:51:05 okay, so i propose that we answer 158 with: "Based on the information available, systemd is violating Fedora Packaging Guidelines by placing compiled executables in /usr/lib/%{name}/ for all architectures as opposed to using %{_libdir}/%{name}. Please file a bug against systemd, and if they do not resolve the issue, then escalate it to FESCo." 17:51:34 +1 17:51:36 so probably the first question to be asked in excalation will be -- does this violation actually break anything. 17:51:39 +1 17:51:41 +1 17:51:54 abadger1999: Well, systemd pretty obviously can't be multiarch. 17:52:03 Unless I'm missing something. 17:52:16 abadger1999: lots of violations won't break things … 17:52:28 +1 17:52:39 +1 17:52:52 Personally I just don't see the point in picking another fight. 17:52:53 hehe, i can vote twice. (sorry) 17:53:13 tibbs|h: if fesco wants to give them an exception, they can. 17:53:17 * abadger1999 is with tibbs|h... 17:53:22 tibbs|h: we aren't … we are asking gholms to 17:53:41 he asked if it violated the guidelines and we're saying that it does. 17:53:52 I guess I'm willing to vote +1 here but someone else will need to champion it/explain the rationale if it escalates. 17:54:17 so, with abadger1999's +1, we're at +5 17:54:38 tibbs|h: want to go on the record? 17:54:44 I guess there's no harm in simply acknowledging the fact that systemd is doing whatever they like. 17:54:47 So +1. 17:55:16 #action resolution text approved (+1:6, 0:0, -1:0) 17:55:17 I suppose we could complicate matters by allowing /usr/lib/%{name} for pkgs that aren't multilib'd, but... meh. 17:55:45 159 came in right before the meeting 17:55:52 so i haven't had a chance to look at it at all 17:56:19 abadger1999: Since I'm also on FESCO, I could make the argument, that it's in violation and we don't have a compelling reason to allow it to. 17:56:52 spot: we can table it then, right?:) 17:56:54 limburgher: that would be my case. we know that using /usr/lib/%{name} universally is a bad idea. Just because it doesn't break in the systemd case isn't a valid rationale. 17:57:07 Well, more usermove-style disruption is kind of a reason. 17:57:28 Yeah, it came about when I was talking to vondruch about whether it was okay for ruby to have a copy of a library and jruby to have a separate copy of the same library. 17:57:29 spot: Right. 17:57:34 (ticket 159) 17:57:46 You can look at the diff to see what I changed. 17:57:54 https://fedoraproject.org/w/index.php?title=User%3AToshio%2FDuplication_of_System_Libraries_clarifications&action=historysubmit&diff=282441&oldid=282437 17:58:01 +1 159 17:58:04 abadger1999: okay. looking at the diff I'm +1 17:58:07 I think it looks straightforward, +1 17:58:24 +1 17:58:51 #topic Duplication of system library clarifications - https://fedorahosted.org/fpc/ticket/159 17:58:59 vote is at +4 17:59:11 geppetto, tibbs|h: ? 17:59:15 It doesn't break anything except the rules. 17:59:25 Erm, that was dumb 17:59:40 Scrolling back and then replying to the line at the bottom of the window. 17:59:46 ANyway, +1 to 159. 17:59:53 tibbs|h: hehe, i think i get what you were trying to say though. i still think if fesco wants to grant it an exception they can. 17:59:53 +1 too 18:00:08 tibbs|h: I think that's a terrible rationale 18:00:32 even if the exception is granted on the grounds of "fixing this will break the world, so we're letting their bad behavior continue as a one off" 18:00:43 It's not a rationale; it's just a statement of fact. 18:00:53 #action 159 changes approved (+1:6, 0:0, -1:0) 18:01:10 #topic Open Floor 18:01:14 Others might try to use it as rationale, I suppose. 18:01:24 i think we actually had a rather productive meeting today. :) 18:01:32 It was nice. 18:01:32 Indeed. 18:01:37 We certainly cleared a lot of tickets :-) 18:01:40 But we do need to talk about doing a time shift. 18:01:59 Personally I'm good with this time and will miss next week if we move up an hour. 18:02:02 oh, peter robinson emailed something to me 18:02:03 yeh, I assume we can follow DST ? 18:02:07 But normally it doesn't really matter. 18:02:28 apparently, cmake needs -DCMAKE_SKIP_RPATH:BOOL=ON for some packages to build without embedded rpaths 18:02:31 going back one hour is better for me 18:02:43 anyone have a problem with me adding that to the section on rpath? 18:02:45 Which direction is back? 18:02:52 Earlier or later? 18:02:55 tibbs|h: 1600 UTC would be back an hour 18:03:10 Earlier 18:03:17 Either is OK for me. 18:03:20 But now is also ok 18:03:21 spot: I thought that's already in the cmake page... lemme check 18:03:25 * abadger1999 can make either 18:03:31 But I thought it was really bad for racor 18:03:32 spot: Seems logical. 18:03:38 (arguably, any pkg requiring that is ... broken somewhere though) 18:04:08 here's another easy ticket: https://fedorahosted.org/fpc/ticket/157 18:04:20 I thought we had two members with mutually exclusive availability. 18:04:24 abadger1999: we did 157 today 18:04:26 I didn't start with the vanilla guideline, though, so there's no nice diff 18:04:35 abadger1999: i just didn't flip it to accepted 18:04:38 oh belagh 18:04:53 I should get out of this racket -- I don't even know what I'm voting on ;-) 18:05:05 ;) 18:05:15 You're no Admiral Stockdale. 18:05:17 rdieter: couldn't the -DCMAKE_SKIP_RPATH:BOOL=ON be included in the default %cmake macro? 18:05:19 we did 134, 154, 157, 158, 159. 18:05:22 spot: ok, guess not, http://fedoraproject.org/wiki/Packaging:Cmake, says not to use it. Either way, we do have a %{_cmake_skip_rpath} macro, available 18:05:27 kalev: no 18:05:33 And the powerball was 23. 18:05:39 kalev: it unconditionally disables rpath, even when it's needed 18:06:13 ah, that doesn't sound like a good default, indeed. 18:06:31 rdieter: thanks, that seems fine then as is. i'll just point peter to that doc 18:06:33 cmake is generally smart enough these days to not rpath system paths, and any pkg's buildsys that does usually is broken somehow 18:07:06 I'm still fighting a few upstreams to fix stuff like that. 18:07:10 okay, back to the timeshift 18:07:27 i'll send out an email to the fpc seeing if anyone has an issue with moving to 1600 UTC 18:07:38 if any cmake-based pkg requires -DCMAKE_SKIP_RPATH:BOOL=ON these days, poke me, and I'll take a look 18:08:30 rdieter: he didn't mention what package was broken to me, if you want to know, you might be better off just poking him 18:09:00 ok, though I was saying that for everyone's benefit not just you and probinson 18:10:16 if there are no other items of business, we'll close out in 2 minutes. 18:19:28 Looks like that's it then? 18:22:25 (taps mic) 18:23:47 \quit 18:24:09 spot: 18:24:25 Is this thing on? 18:34:12 #endmeeting 18:34:30 spot: need you to #endmeeting 18:36:03 .addchair #fedora-meeting-1 freenode abadger1999 18:36:03 nirik: Chair added: abadger1999 on (#fedora-meeting-1, freenode). 18:36:11 #endmeeting