17:04:13 #startmeeting Fedora Packaging Committee 17:04:13 Meeting started Wed Dec 19 17:04:13 2012 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:04:16 #meetingname fpc 17:04:16 The meeting name has been set to 'fpc' 17:04:19 #topic Roll Call 17:04:26 * abadger1999 here 17:05:17 * limburgher here 17:05:51 Howdy. 17:06:05 FPC ping Smoother1rOgZ rdieter racor 17:06:25 * racor is here, but will likely have leave early 17:08:49 well, with racor that is 5 17:09:21 lets try to knock out an "easy" one 17:09:39 #topic Exception for cxxtest from requiring a devel subpackage - https://fedorahosted.org/fpc/ticket/239 17:09:55 Basically, cxxtest doesn't work without its headers. The -devel split makes no sense here. 17:10:03 Agreed. 17:10:07 Why is this even filed with us? 17:10:19 I have no idea, but lets just approve it and move on. 17:10:20 +1 17:10:24 +1 17:10:30 +1 17:10:34 +1 17:10:34 mschwendt files a bugzilla about it. 17:10:42 But why? 17:10:48 +1 17:10:49 but I didn't see a convincing explanation of why. 17:10:52 * abadger1999 looks up bz 17:10:59 some people enjoy bureaucracy, i guess. 17:11:10 According to the ticket, someone is using it as a bad example. 17:11:11 Rule 34. 17:11:21 "that package does it, so my package should be able to do it". 17:11:24 It would be news to me, if we require explict permissions in such cases ... 17:11:29 Common sense seems to have gone out the window. 17:11:36 https://bugzilla.redhat.com/show_bug.cgi?id=888509 17:12:01 Anyway, people are always welcome to ask us, I guess; it just seems that we're being used to settle a pointless argument. 17:12:15 "This matches the contents of the current cxxtest package. It would be perfectly valid to not create a "main package" but just a cxx-devel subpackage. And for namespace issues, it would also be legal to add to the -devel package a virtual "cxxtest" package definition." 17:12:35 #action No -devel package is required for cxxtest, due to the fact that cxxtest is useful without headers. The FPC notes that this sort of decision does not really require FPC intervention, as it is considered a package where the split does not make logical sense. (+1:5, 0:0, -1:0) 17:12:45 s/useful/not useful/ 17:13:39 okay, lets move on 17:13:54 #topic GitHub specific handling - https://fedorahosted.org/fpc/ticket/233 17:13:56 Hmm.. in that section we are explicit in mentining compilers (probably to the point where we aren't making a more general case) 17:14:12 * abadger1999 will look at a clarification later 17:14:41 abadger1999: yeah, we can probably restate it to include "packages which cannot function without the presence of their include/header files" 17:14:57 Is there a final draft of the github thing? Looks to me like discussion is still happening. 17:15:29 I can whip one up, but basically, i'm fine with all of abadger1999's suggested changes 17:16:12 and leamas's last comment about a lot of %{name}-0.tar.gz... I'm not too concerned about. 17:16:34 (reading) 17:16:56 I'm inclined to not be concerned about that last comment either. 17:17:06 Yeah, I'm on board. 17:17:30 We're generating the tarball after all... traditionally, all those tarballs would probably get named %{name}.tar.gz so I don't see this as a big change 17:17:42 +1 to spot's draft plus my two changes. 17:17:56 +1 as well. 17:18:36 abadger1999: this would be inacceptible to me. Tarball names need to be unique and their contents be deterministical, otherwise rpms will not be deterministically reproducable. 17:19:14 racor: But we can't force github upstreams to make tarballs. Dammit. 17:19:17 racor: they will be deterministically reproducible from the srpms 17:19:21 So, the only thought i have there is that the github tarball naming is basically an arbitrary random value 17:19:34 but we can force users to produce deterministic tarballs 17:19:35 racor: You don't even get that now. 17:19:37 or from our scm-sysem (since that uses both tarball name and cryptographic hash) 17:19:57 I mean, it is not uncommon for upstreams to change the tarballs without changing their names. 17:20:07 tibbs: Sadly. 17:20:16 So we lose precisely nothing by actually documenting this and gain plenty. 17:20:47 tibbs: ... building against the tarball de jour? ... Package fails, builds, fails ... 17:21:09 Which is exactly no different from the situation we have today. 17:21:15 so, to be honest, i have no issue with embedding the shortcommit into the tarball name 17:21:25 github will use _ANY_ name we ask it to in this URL 17:21:47 e.g. https://github.com/lmacken/liveusb-creator/archive/6e40c9d6cedd5b48cb7395bcd351f72a8afdfc6c/foo-bar.tar.gz 17:22:03 tibbs: Such upstreams need to be tought, they are doing it wrong and should change their behavior. 17:22:20 * abadger1999 doesn't have a problem with %{name}-%{version}-%{shortcommit}.tar.gz 17:22:25 I'm happy with this as is, I think, though I might be inclined the strengthen the note that if upstream produces tarballs, you should use them. 17:22:39 so by documenting %{name}-%{version}-%{shortcommit}.tar.gz here, we avoid unnecessary confusion, especially when version is always 0 17:22:40 tibbs: 17:24:11 so, i'd like to put forward my draft, +abadger1999's changes in comment 13, and the change to use %{name}-%{version}-%{shortcommit}.tar.gz in the Source URL. 17:24:19 * abadger1999 knows this general workflow would work for snapshots too... tries to think of wording that allows that. 17:26:37 "If the upstream does not create tarballs for releases, you can use this mechanism to produce them. If the upstream '''does''' create tarballs you should use them as tarballs provide an easier trail for people auditing the packages." 17:26:47 tibbs: ^ Does that satisfy you? 17:26:58 * spot is fine with that change as well 17:27:18 Sure, I have no problems with that. 17:27:40 racor: You would be our fifth vote at the moment. 17:28:03 i'm making a merged draft 17:28:04 one sec 17:29:52 +1, I am not convinced, but I also do want to block 17:30:32 https://fedoraproject.org/wiki/User:Spot/GitHub_Guidelines 17:30:40 please sanity check and lets revote 17:31:13 +1 from me 17:31:14 ... other distros/OSes demand checksums on tarballs. 17:31:36 So do we. 17:31:38 cat sources 17:31:53 But we all know you know that, so you must be talking about something different. 17:32:11 +1 17:32:19 +1 17:33:05 we're at +3 on the "final" draft text 17:33:11 +1 17:33:35 tibbs: I am still talking about reproduceable tarballs 17:33:36 +1 17:33:51 #action https://fedoraproject.org/wiki/User:Spot/GitHub_Guidelines approved (+1:5, 0:0, -1:0) 17:34:03 But that does prompt a dumb question: do we have any standard in the guidelines for writing something the packager must replace? Like $OWNER? 17:34:46 Probably not in the "style guide" sense. 17:34:53 But I use that syntax all the time. 17:34:58 We don't -- some guidelines use UPPERCASE others use $UPPERCASE. 17:35:18 as long as it is clear (explicitly or from context), I don't think it matters. 17:35:30 spot: we're mixing it here.. When you copy over, ​https://github.com/OWNER/PROJECT/tags => ​https://github.com/$OWNER/$PROJECT/tags 17:35:31 That said, if someone cares, feel free to just unify things. 17:35:46 oh. Thats silly. I'll make that edit. 17:35:48 The problem is that rpm has things in $UPPERCASE syntax that are real syntax and I know folks have gotten confused before. 17:36:00 17:37:42 among the many warcrimes RPM has committed... 17:38:03 Not that I care enough to rewrite everything. But I do wish we could discourage $RPM_BUILD_ROOT and $OPTFLAGS. 17:38:48 abadger1999: do you want to talk about sagemath? 17:39:02 * abadger1999 does want to get to https://fedorahosted.org/fpc/ticket/158 17:39:15 since it's on fesco's agnda for today. 17:39:22 * abadger1999 takes a look at sagemath 17:40:05 Okay, lets talk 158 for a bit 17:40:20 #topic systemd and /usr/lib/%{name} 17:40:28 * abadger1999 can stake out some positions about sagemath afterwards. 17:41:08 Even if FESCo explicitly states that systemd is not multilib 17:41:13 That ticket just pisses me off. 17:41:33 we still have the issue of every systemd service having a unit file in a weird place. 17:41:36 So revisiting this follows from our position on non-multilib packages being allowed to install into %{_prefix}/lib 17:41:38 To defend our position, piss off. 17:42:23 at one time, kay or lennart argued that the unit files were arch-specific data. 17:42:49 that seems to be a hell of a stretch. 17:43:00 If that's so, then I guess the services need to be declared non-multilib although that could be some broad general exception. 17:43:05 * spot has looked at hundreds of unit files now 17:43:13 and i can't think of one that was arch specific 17:43:27 otoh, I have never seen the example they were talking about in the wild. 17:44:17 yeah. 17:44:19 I think my stance here is that if FESCo wants to permit systemd (and its unit files) to live under /usr/lib, they need to override us (which they can do). 17:44:51 If they do, we'll amend the guidelines to reflect that systemd (and its unit files) are an explicit FESCo approved exception. 17:45:21 But I don't think I see any sort of more general guideline in this specific case, nor do I think the no-multilib exception applies. 17:45:46 are the two sets of things the same? (systemd's helper apps and systemd's unit files)? 17:46:02 abadger1999: no, but they use the same directory structure. 17:46:15 I can see how it would be awkward to change one but not the other 17:46:25 okay -- do the helper apps fall under the no-multilib exception but hte unit files do not? 17:46:53 (ie: according to the guidelines, they must change the location of the unit files... up to them if they change the helper apps at the same time)? 17:47:37 with my hat of +2 pedantry on... 17:47:57 (saving throw) 17:47:58 Yes. The helper apps probably fall under the no-multilib exception (should FESCo grant it), but the unit files would not. 17:47:59 * limburgher failed 17:48:06 Cool. 17:48:17 But I'd prefer it if FESCo didn't do that 17:48:26 okay. 17:48:40 I can't really disagree with any of that. 17:48:54 I'll report that at today's fesco meeting unless someone disagrees (soundds sensible to me). 17:49:01 I'd much prefer if FESCo just said "Systemd is a special case. Its helper apps and its unit files can live in /usr/lib/" 17:49:53 As would I. 17:49:59 (even if i disagree with that answer ideologically, i prefer it from a "please stop trying to shove your face through this loophole" perspective.) 17:50:30 * limburgher laughs, to keep from weeping 17:50:32 My problem is that I can't tell if the systemd folks are saying that both the whole multilib case and the /usr/share-/usr/lib* split are pointless, or if they have some other odd justification. 17:50:51 They just say "your requirements are misguided and we choose to ignore them" without actually making an argument. 17:50:53 tibbs: i am content to let them plead any case they wish to FESCo 17:51:08 they were not successful pleading one to us. 17:51:21 They don't really have to plead a case. Their stuff is in already. 17:51:33 tibbs: I says systemd has not matured enough and is suffering from being in an early stage. 17:51:43 tibbs: yes, i know. this is all a sort of dance of "mom! jimmy isn't following the rules!" 17:52:13 Don't lump me in with the systemd haters; I have no problems with it as a system. 17:52:15 abadger1999: ready for sagemath? 17:52:21 Ugh, sage. 17:52:35 yep. 17:52:58 #topic Sagemath bundles cpython, ipython, pexpect - https://fedorahosted.org/fpc/ticket/238 17:53:08 So to take each separately. 17:53:15 cython -- I'm heavily against bundling. 17:53:19 I would dearly love to have sage in the distro, but it's another example of someone layering almost an entire OS on top of your OS. 17:53:34 abadger1999: Nods 17:53:39 cython is a compiler of python-ish code to C. I'd like us to treat it like other compilers. 17:53:59 Didn't sage even bundle gcc at some point? 17:54:07 ie: stick with one major version for a Fedora release. all packages in distro need to port to that version for that release. 17:54:43 ipython is large and complex but there does seem to be a timeline for unbundling it. I could vote either way on this. 17:55:14 At some point, we should be able to say that if there's a timeline for unbundling, then just keep the package out of the distro until the unbundling happens. 17:55:36 pexpect is relatively small but it appears to me that they're just fixing a bug (and possibly creating a different bug when doing so) -- I'd rather that the patch went into upstream or into our downstream package if that's the case. 17:55:43 It really shouldn't be a huge thing to keep something in a side repo until it's actually ready. 17:56:15 i regret, I've got to leave now. I'll likely not be available for meeting through Jan 6. 17:56:25 racor: i doubt we will meet next week anyways 17:56:30 racor: thanks 17:56:45 spot: OK 17:56:55 merry X-mas, bye 17:57:17 so, we just lost quorum 17:57:40 but fwiw, i think we should be willing to be flexible with pcpa on sagemath here 17:57:47 he's done a LOT of work to unbundle stuff from it 17:58:22 to a point, yes. 17:58:44 so, my general thoughts here are +1 for 6 month exception on ipython, -1 for cython, -1 on pexpect, unless it is impossible to get the system pexpect fixed up 17:59:27 I could support that. Maybe we would vote in-ticket? 17:59:47 wfm 18:00:07 * spot can put that as a proposal in a ticket 18:00:17 then racor could potentially vote sooner. 18:00:35 others as well. 18:01:46 okay. Proposal is in the ticket, please vote in ticket. 18:02:18 And with that, I wish you all a Happy Holidays and call this meeting to an end. 18:02:26 Thanks spot 18:02:40 We will not meet next week, we'll pick things back up on January 7. 18:02:58 #endmeeting