17:00:12 <abadger1999> #startmeeting fpc
17:00:12 <zodbot> Meeting started Thu Feb 20 17:00:12 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:15 <abadger1999> #meetingname fpc
17:00:15 <zodbot> The meeting name has been set to 'fpc'
17:00:19 <abadger1999> #topic Roll Call
17:00:24 <abadger1999> Hey all, who's here?
17:00:26 <tibbs|w> Finally here on time for once.
17:00:47 * limburgher here
17:01:26 <abadger1999> #chair tibbs|w limburgher
17:01:26 <zodbot> Current chairs: abadger1999 limburgher tibbs|w
17:01:34 * geppetto is here
17:02:02 <abadger1999> racor, SmootherFrOgZ, spot: FPC ping
17:02:06 <abadger1999> #chair geppetto
17:02:06 <zodbot> Current chairs: abadger1999 geppetto limburgher tibbs|w
17:02:32 <abadger1999> #topic #339     software collections in Fedora
17:02:36 <abadger1999> https://fedorahosted.org/fpc/ticket/339
17:02:42 <abadger1999> No action needed here today.
17:03:29 <abadger1999> Just an update: I've been talking with Jan Zeleny and he's going to change the fedora scl-utils package to use /var/opt and /etc/opt for statefiles and conffiles respectively.
17:03:41 * SmootherFrOgZ here
17:03:44 <rsquared_> I'm here to discuss the greenmail ticket (#392)
17:03:45 <abadger1999> And I've gotten the test SCLs I've been working on into some copr repos.
17:03:47 * Rathann here as well
17:03:53 <abadger1999> #chair SmootherFrOgZ Rathann
17:03:53 <zodbot> Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto limburgher tibbs|w
17:04:40 <abadger1999> http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/
17:04:50 <abadger1999> http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/
17:05:01 <abadger1999> Okay we have enough for quorum now :-)
17:05:13 <abadger1999> #topic #382     Go Packaging Guidelines Draft
17:05:19 <abadger1999> https://fedorahosted.org/fpc/ticket/382
17:06:28 * racor is here
17:06:31 <tibbs|w> It doesn't look like there was any real answer to what was brought up.
17:07:23 <tibbs|w> Does that mean the only viable thing is just hope dependencies are sufficient to figure out what rebuilds would be needed when things in the dep chain are updated?
17:08:49 <abadger1999> #chair racor
17:08:49 <zodbot> Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto limburgher racor tibbs|w
17:09:09 <tibbs|w> And is that really the only sticking point here?
17:10:59 <Rathann> I don't like using repository/project domain names as part of package name, but that's only my preference and I won't vote -1 because of it
17:12:22 <abadger1999> The version section doesn't follow the snapshot conventions (which make use of date)
17:12:34 <tibbs|w> I think that depends more on what people who intend to use the packages would expect to see.
17:13:14 <tibbs|w> Hmm, yeah, mentioning Release: there seems to co-opt the existing naming guidelines.
17:13:22 <tibbs|w> Probably should simply refer to them.
17:13:41 <abadger1999> <nod>
17:14:03 <tibbs|w> It's odd, because the draft links to "standard Fedora version conventions", but that goes to SourceURL, which seems wrong.
17:14:18 <tibbs|w> And then proceeds to actually ignore the standard version conventions.
17:14:19 <abadger1999> #info Have the version/release section simply point to the existing guidelines [propose updates to the existing guidelines if they should be clarified]
17:14:57 * Rathann notes that debian guidelines do mention versioning
17:15:17 <abadger1999> #info link to ""standard Fedora version conventions" is to the wrong page... should go to https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
17:15:19 <tibbs|w> I wish the bit about debuginfo and strip didn't have to be in there.
17:15:44 <abadger1999> <nod>  Would that be a place to mention that it will hcange when our tools catch up?
17:15:51 <tibbs|w> I wonder if bugs were filed against the appropriate other bits of the system.
17:16:33 <tibbs|w> And if running strip actually kills your binaries, aren't you doing something wrong.
17:16:36 <tibbs|w> ?
17:16:49 <abadger1999> #info debuginfo/strip => Note that guidelines will change when tools catch up.  Link to the bug reports for the tools doing the wrong thing.
17:17:06 <tibbs|w> That sort of points to a deeper issue, like you're putting things in debug sections that aren't actually for debugging.
17:17:16 <tibbs|w> Not that I know the details.
17:18:19 <Rathann> I'm +1 to the guidelines in general
17:19:12 <tibbs|w> Would prefer something to define the architectures instead of open-coding an arch list that could change in the future.
17:19:23 <tibbs|w> I think someone else already mentioned this, though.
17:19:45 <tibbs|w> Yeah, first comment in the FPC ticket.  Guess it just didn't get addressed yet.
17:20:35 <tibbs|w> I'm not opposed to these in general, assuming they address what's been discussed.
17:20:46 <racor> I don't like the package naming section - It might be useful for libraries, but I do not think it's useful for programs. The language a program is written in is widely irrelevant.
17:21:22 <tibbs|w> racor: They do say that, don't they?
17:21:33 <abadger1999> #info create a %go_arches macro as mentioned in https://fedorahosted.org/fpc/ticket/382#comment:1
17:21:37 <tibbs|w> Well, that statement is down in the "packaging binaries" section.
17:21:55 <Rathann> yes, should be merged into naming I guess
17:22:23 <tibbs|w> Yes, no point in stating one thing, and then a page later say "but....".
17:22:53 <abadger1999> #info either move the naming of programs section to the naming section or move the current naming section into the libraries section.
17:24:05 <racor> tibbs|w: Well, could be a language barrier thing, but I read this section as "all packages must be named golang-<foobar>. It's the old "c++-gcc", "perl-autoconf", python2-yum naming issue.
17:24:48 <tibbs|w> And then later is says that if it's an application, don't name it like that.
17:25:49 <abadger1999> #info In Packaging Libraries, prepend it with "At this time"... the tooling may eventually reach a point where we do encourage people to develop against the system packages.
17:30:25 <racor> abadger1999: Your remark touches another topic on Go: Is anybody around here able to confirm or refute the various claims on stripping, debug info etc.? I am not.
17:30:55 <abadger1999> racor: <nod>  Once we get a link to bug reports we should be able to judge that more accurately.
17:31:31 <abadger1999> #info @mattdm: we'd like more info on the strip issues, bug links might provide that.
17:33:29 <abadger1999> Seems like evreything we saw that isn't related to -source/static/dependencies?
17:34:57 <abadger1999> Do we have an idea of what to do with the static linking issue?
17:36:10 <tibbs|w> I think until the language actually gets sane, we're going to just have to accept it.
17:36:30 <tibbs|w> There should be enough dependency info to track what needs rebuilding.
17:37:11 <abadger1999> Okay... do we want to do anything to mitigate the issues?  Like specifying that packages have to include their full dep chain as BR?  (even though the libraries are already linked into a previous library)?
17:37:30 <abadger1999> Or just realize that the queries are going to have to be recursive.
17:37:36 <geppetto> I guess not … I guess we rely on chains
17:37:53 <geppetto> making sure all the BR are correct without automated testing is going to be a giant fail
17:37:58 <abadger1999> And that top level package owners may not be aware of a problem until the bottom dep contacts them.
17:38:09 <abadger1999> geppetto: <nod>
17:38:09 <tibbs|w> I think our tools can do the recursion; requiring it in the packages seems overkill.
17:38:41 <abadger1999> tibbs|w: The recipe in the guidelines  looks like the tools don't do the recursion.
17:38:59 <tibbs|w> I really thought repoquery could do all of that now.
17:39:05 <geppetto> yeh, no current tools can dtrt thing here without a lot of false positive/negative
17:39:12 <abadger1999> The maintainer has to invoke repoquery for each library and then any libraries it buildrequires (and then any libraries they buildrequire) manually
17:39:21 <geppetto> repoquery can tell you all the deps. down in a tree
17:39:37 <geppetto> but it can't easily do that just for the golang static deps.
17:39:46 <tibbs|w> I figured you just grepped them out.
17:39:54 <tibbs|w> Since they have a defined format.
17:41:38 <abadger1999> that's probably a better strategy.
17:42:12 <abadger1999> recording all of the dependent golang libraries and requerying for them manually would get tedious.
17:42:43 <abadger1999> geppetto: would that just be adding --alldeps to the first repoquery?
17:44:13 <abadger1999> related question.... do we care if we have to recompile all golang libraries if the golang compiler advances?
17:44:44 <tibbs|w> We have to do plenty of that for other things, including GCC.
17:44:51 <tibbs|w> I don't see why Go should be any different.
17:45:10 <abadger1999> it seems like the design of the golang compiler means we would try hard not to update it in a released fedora (updating it would break end user's compiled libraries)?  Or would end users never have compiled libraries laying around?
17:45:57 <Rathann> abadger1999: the guidelines say that libraries are packaged only for building programs and not meant to be used for development
17:46:07 <Rathann> so the latter
17:46:35 <abadger1999> tibbs|w: I didn't think that was necessary for minor releasers of gcc.
17:46:40 <abadger1999> am I wrong?
17:47:13 <abadger1999> Rathann: I guess what I'm asking is if I am working on building my own golang application
17:47:17 <tibbs|w> It isn't generally.
17:47:28 <tibbs|w> But I don't know if it's necessary for Go, either.
17:47:40 <abadger1999> I need to have some go lang libraries downloaded via "go get" and some of my own in-house libraries.
17:48:00 <tibbs|w> Seems pretty bad if a minor bugfix requires a complete tree recompilation.
17:48:02 <geppetto> abadger1999: not sure what you mean … just saying that you'll get a lot of deps. in the tree for stuff that isn't part of the need to rebuild the world (like /bin/sh)
17:48:06 <abadger1999> I've built this a few times so (I assume) those have compiled versions on disk.
17:48:15 <abadger1999> Fedora updates the golang compiler.
17:48:19 <abadger1999> What happens then?
17:48:32 <geppetto> abadger1999: as tibbs said you can kind of post process grep by hand it out … but realistically it'd be better to have a real tool that knew about this snafu
17:48:45 <geppetto> everything stops?
17:49:01 <abadger1999> Does it realize that the binaries won't work so it recompiles from source?  (Standard make wouldn't do that since it relies on timestamps)
17:51:18 <abadger1999> geppetto: I guess what I'm asking about the repoquery is would this work?  repoquery -q --alldeps --disablerepo='*' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires golang-$WHATEVER-devel |grep 'golang-'
17:52:07 <abadger1999> tibbs|w: From the Packaging Libraries section: "There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler"
17:52:21 <tibbs|w> Aww, crap.
17:53:01 <tibbs|w> Well, I guess the people who design these things think they're smart.
17:53:02 <limburgher> headdesk
17:53:17 <limburgher> "Works at my desk."
17:53:30 <tibbs|w> But if you want to package software written in a language that's actively hostile to you, I guess so.
17:53:53 <tibbs|w> Go people have to know they either have to deal with the pain of rebuilding the world all the time, or they don't update the compiler for any reason.
17:53:56 <racor> abadger1999: I think this needs to be verified. It at least doesn't match with what I have been told on other occasions.
17:54:06 <abadger1999> okay.
17:54:57 <abadger1999> #info @mattdm, Can you point us to documentation that verifies that prebuilt libraries are tied to the exact minor release of the golang compiler?
17:55:18 <abadger1999> Alright -- I think we have a few questions now for mattdm to reply to.
17:55:26 <abadger1999> Should we move on to some other tickets?
17:56:05 <abadger1999> #topic  #392     bundling expception for greenmail
17:56:08 <abadger1999> https://fedorahosted.org/fpc/ticket/392
17:56:18 <abadger1999> I'm going to jump ahead to this one since rsquared is here.
17:56:31 <rsquared> Thanks
17:57:05 <Rathann> standard questions are not answered
17:57:17 <geppetto> is this really forking and not just forking to create a new project with different goals?
17:57:28 <geppetto> is this really bundling, even
17:57:38 <abadger1999> <nod>
17:57:56 <Rathann> rsquared: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions
17:58:17 <abadger1999> From the descriptions of greenmail and foedus I'm wondering if greenmail could be a fork of foedus.
17:58:28 <abadger1999> Not sure whether the relation to james would also be the same.
17:58:51 <rsquared> foedus is an incomplete and dead upstream.
17:59:26 <abadger1999> a diff or summary of differences might also be helpful (but I don't think we have any java devs here)
18:00:02 <Rathann> and make sure the diff doesn't contain whitespace changes or reformatting
18:00:04 <rsquared> The code I looked at from James was heavily modified.  Class contents gutted and inheritance changed
18:00:06 <Rathann> if possible
18:02:37 <rsquared> Does it make sense to produce a diff against upstream Foedus?  It's dead, incomplete, and non-working for most cases according to upstream.  It doesn't seem like an independent Foedus package is of much use to anyone. :)
18:02:54 <rsquared> I can attach a diff of the included james code if that's a concern.
18:04:16 <SmootherFrOgZ> what would be the impact of using the modified Feodus as default package into fedora so you can not bundle it?
18:04:35 <SmootherFrOgZ> if upstream says it's dead
18:05:34 <Rathann> original foedus looks long dead (last release in 2002)
18:07:43 <abadger1999> Looking at how the foedus code is integrated into greenmail source, I think that portion could be considered a fork.
18:07:52 * abadger1999 grabs the james source
18:10:19 <rsquared> SmootherFrOgZ: I'm not sure the modified Feodus has much use to anyone as a standalone package. I'm not an experienced enough in the mail server space to know if anyone would want these mods.  The functionality is pretty basic iirc
18:11:05 * Rathann is leaning towards +1 for bundling foedus but -1 to bundling james
18:11:06 <rsquared> The inheritance is also modified to be all greenmail based
18:11:48 <rsquared> Rathann: The changes to the james code were pretty drastic when I looked.  entire classes gutted
18:12:41 <SmootherFrOgZ> well, i'm not sure that argument is valid not to make it default package. if we were thinking that way, all package would be bundled.
18:13:12 * SmootherFrOgZ brb, have to take a phone call
18:15:21 <rsquared> Rathann: Also, the mods to the bundled james bits create a mock e-mail server vs james being a real e-mail server.  Greenmail isn't an e-mail server, and if projects wanted a mock e-mail server for testing they could just use greenmail.
18:15:42 <abadger1999> james snapshot...240K... james last stable 9.4M
18:16:01 <Rathann> last stable probably contains binary jars
18:16:32 <abadger1999> well the snapshot only had one .java file... I hope the last stable contains a bit more source code ;-)
18:22:29 <abadger1999> rsquared: Ugh... What's the license of foedus and greenmail?
18:22:45 <rsquared> SmootherFrOgZ: Maybe I don't understand the question.  What do you mean by default package?
18:23:52 <rsquared> abadger1999: Greenmail is ASL2.0, Foedus is ASLv1.1
18:25:18 <rsquared> According to foedus's src tarball
18:27:57 * abadger1999 gets unsidetracked...
18:28:18 <abadger1999> I think a case could be made that james is also forked.
18:29:09 <abadger1999> rsquared: You might have a licensing issue though -- there's a mix of licenses in the code, including lgpl.
18:29:21 <rsquared> abadger1999: In Foedus you mean?
18:30:26 <abadger1999> rsquared: In greenmail
18:30:42 <abadger1999> grep -ri gpl in greenmail's source.
18:31:14 <rsquared> Ew
18:31:36 <abadger1999> rsquared: it's pretty strange... I'm not sure what the result of untangling that will be.
18:32:05 <racor> My time is up for today. I've got to leave, bye.
18:32:09 <abadger1999> But that's something thta will be resolved in package review... fpc really only needs to figure out whether it's okay to include the code.
18:32:11 <abadger1999> racor: later.
18:32:22 <willb> abadger1999, rsquared, I filed a ticket about that upstream as part of the review:  https://bugzilla.redhat.com/show_bug.cgi?id=1059805
18:34:00 <abadger1999> I'd propose we consider foedus a fork because it satisfies all of these conditions: * it's an application rather than a library.   * The consumer is only taking a portion of the code * The consumer is maintaining that portion independently of the foedus upstream.
18:34:22 <Rathann> abadger1999: +1 to that
18:34:23 <abadger1999> james seems to be a library.
18:34:47 <limburgher> abadger1999:  Seems reasonable.
18:34:51 <abadger1999> and I'm not sure whether the consumer is maintaining the portion it's including independently or not..
18:35:19 <abadger1999> But the use cases and code seem divergent enough that I think it could be a fork as well... I just don't know how to nail down the particulars.
18:36:26 <abadger1999> Let's vote on foedus since it seems likely to pass.
18:36:46 <abadger1999> Proposal: greenmail's use of foedus considered a fork (which is allowed)
18:36:49 <abadger1999> +1
18:37:31 <Rathann> +1
18:38:37 <abadger1999> limburgher geppetto tibbs|w SmootherFrOgZ spot we have some proposals
18:38:45 <tibbs|w> Yeah.
18:38:49 <limburgher> +1
18:38:57 <tibbs|w> +1 fo the foedus thing.
18:39:53 <abadger1999> Tha's four.  I think if geppetto comes back he'll vote to make it five.
18:40:21 <abadger1999> Let's take a vote on james being a fork to see if we can move on.. if it doesn't pass we can ask more questions.
18:40:41 <abadger1999> Proposal greenmail's use of james is considered a fork (which is allowed)
18:41:05 <abadger1999> +1
18:41:15 <geppetto> +1
18:41:24 <geppetto> to both
18:41:46 <abadger1999> #info greenmail's use of foedus considered a fork (which is allowed) (+1:5, 0:0, -1:0)
18:42:24 <abadger1999> Rathann, tibbs|w, limburgher: what say you to james being a fork?
18:43:27 <limburgher> I think so. +1
18:43:31 <Rathann> not sure without some further input - standard questions answered and a diff would necessary
18:43:57 <tibbs|w> I'm sort of in the same boat.  Surprised we even considered this without the usual information being present.
18:44:03 <abadger1999> <nod>
18:44:32 <limburgher> I'm happy with getting more info, as well.
18:44:34 <abadger1999> rsquared: Okay -- so for james, please answer the standard questions https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions
18:45:22 <abadger1999> rsquared: we're also interested in how divergent the code is (summary of changes or a diff can help here).
18:46:20 <abadger1999> rsquared: and in how the james' code that's within greenmail is being maintained (do they maintain it independently?  periodically rebase?  take changes from james when those changes seem to apply to what htey're doing?)
18:46:57 <abadger1999> We'll discuss more once that information is in.
18:47:13 <rsquared> abadger1999: I'll give it a shot.  Thanks
18:48:03 <abadger1999> #topic #390 Reserve static uid/gid for activemq
18:48:09 <abadger1999> https://fedorahosted.org/fpc/ticket/390
18:48:39 <abadger1999> This one looks justified (shared storage being used to scale out the service).
18:49:01 <abadger1999> +1 from me
18:49:25 <abadger1999> note however,
18:50:27 <abadger1999> nevermind.
18:50:34 <tibbs|w> Does sort of look like one of the very few instances where this might make sense.
18:50:41 <rsquared> abadger1999: For code comparious with james, which version of james should be used?  The latest?
18:50:50 <SmootherFrOgZ> sorry, took me more time than i thought on phone. i'm back now
18:50:54 <abadger1999> (I was going to say this is soft static -- but  I think we don't ever allocate hard static for new services)
18:51:43 <SmootherFrOgZ> rsquared: i'll comment on ticket for more clarification
18:51:54 <rsquared> SmootherFrOgZ: Thanks
18:52:01 <abadger1999> rsquared: it's usually "the most relevant". If I forked from version 1.0 and haven't synced since, then I'd compare to version 1.0... if there's periodic resyncs then compare to whatever one was last imported.
18:52:35 <geppetto> yeh, +1 on the activemq openshift thing
18:53:04 <Rathann> +1 as well
18:53:06 <SmootherFrOgZ> +1 from me
18:53:19 <tibbs|w> +1
18:55:09 <abadger1999> #info static uids for activemq approved (+1:5, 0:0, -1:0)
18:55:53 <abadger1999> I'll tkae care of opening the bug for setup package or commiting and update the ticket with the uid to use.
18:56:11 <abadger1999> five more minutes...
18:56:15 <abadger1999> #topic Open floor
18:56:31 <abadger1999> Anythhing someone wants to bring up or an open ticket they want to discuss now?
18:56:46 <willb> https://fedorahosted.org/fpc/ticket/395
18:57:22 <willb> ^ not a critical issue, obviously, but something I ran into doing a review
18:57:53 <limburgher> Could you write something up with what you think would be the best option, or pros/cons of all of them?
18:58:34 <willb> limburgher, sure, I'll think about it and append to the ticket
18:58:46 <willb> there's no clearly great option, IMHO
18:58:54 <willb> but I'm not a Mono expert
19:00:22 <abadger1999> Okay, if nothing else I'll close in 60s
19:01:13 <limburgher> willb: Thanks!
19:01:25 <willb> thank you!
19:01:29 <abadger1999> #endmeeting