15:59:49 <spot> #startmeeting Fedora Packaging Committee
15:59:49 <zodbot> Meeting started Thu May 23 15:59:49 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:53 <spot> #meetingname fpc
15:59:53 <zodbot> The meeting name has been set to 'fpc'
15:59:59 <spot> #topic Roll Call
16:00:14 <tibbs|w> Howdy.
16:00:15 * geppetto is here
16:00:27 * abadger1999 here
16:00:58 <abadger1999> but I'm not able to get to phx2 atm... which means I can see trac tickets but not the wiki or bugzilla.
16:01:09 <tibbs|w> Good to know that my phone is smart enough to accept an appointment in UTC and actually alert me at the right time.
16:01:38 * RemiFedora is here
16:01:44 <geppetto> tibbs: cool :)
16:02:05 <spot> geppetto: did we not have any agenda for today? :)
16:02:15 <tibbs|w> Short meeting.
16:02:53 <geppetto> spot: We didn't have any new tickets, or follow ups that I could see.
16:03:10 <geppetto> I wasn't sure if we'd skipped any tickets from last week.
16:03:14 <spot> the mingw ticket came in late, so we can do it
16:03:29 <tibbs|w> I haven't really had a chance to look over it properly.
16:03:36 <spot> https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FMinGWCrossCompiler&diff=337954&oldid=302743 is helpful
16:03:44 <tibbs|w> But conceptually the changes make sense.
16:04:47 <spot> Well, lets make it official, since i see 6 people. :)
16:05:14 <spot> #topic Updated MinGW Packaging Guidelines - https://fedorahosted.org/fpc/ticket/294 - https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FMinGWCrossCompiler&diff=337954&oldid=302743
16:05:21 <tibbs|w> Why am I remembering some weird legal issue related to mingw stuff?
16:05:48 <epienbro> hey everyone, I'm available to answer any questions you may have about the mingw draft
16:05:54 <spot> tibbs|w: its an old one, long since resolved.
16:06:08 <epienbro> tibbs, correct, last year we were waiting on red hat legal to approve the use of mingw-w64 in fedora
16:06:10 <tibbs|w> OK, good, it just popped into my mind for some reason.
16:06:23 <tibbs|w> I don't think about mingw terribly often, but seeing mingw64 must have triggered.
16:06:23 <abadger1999> I saw the summary of changes but am not able to look at the wiki links atm.  The only one I thought I needed to pay attention to was #6
16:07:15 <spot> abadger1999: executables?
16:07:21 <abadger1999> spot: yeah.
16:07:32 <geppetto> So the diff looks fine to me (with my tiny amount of mingw specific knowledge)
16:07:40 <tibbs|w> abadger1999: http://www.math.uh.edu/~tibbs/fpc/PackagingDrafts_MinGWCrossCompiler%20-%20FedoraProject.html
16:07:41 * spot is on the fence about this, but I think as long as they're built from source, i'm fine with them being packaged.
16:07:42 <tibbs|w> That's the diff.
16:07:52 <abadger1999> tibbs|w: Thanks!
16:08:06 <tibbs|w> Assuming you can reach my location, of course.
16:08:35 <geppetto> Not sure why the text exes have to be shipped in the main package.
16:08:38 <geppetto> s/text/test/
16:09:10 <spot> epienbro: thats a good question, why can't they be in a dependent subpackage?
16:10:50 * spot wonders if he's lagged out
16:11:05 <tibbs|w> Doesn't appear so.
16:11:22 <tibbs|w> Well, you haven't lagged out.  epienbro might have.
16:11:27 <epienbro2> my apologies, my other computer got stuck
16:11:40 <spot> epienbro2: thats a good question, why can't executables be in a dependent subpackage?
16:12:22 <epienbro2> that is one of the points where we (as a SIG) haven't made a final decision yet
16:12:34 <epienbro2> some people prefer to place executables in a separate -tools subpackage
16:12:46 <epienbro2> but most packagers already put everything in the main package
16:12:52 <spot> Perhaps something like "Executables should either be included in the main <code>mingw32-foo</code> / <code>mingw64-foo</code> subpackages (where the regular libraries and headers are also placed), or in a properly named (and dependent) subpackage."
16:13:13 <epienbro2> so we want to come up with a generic set of guidelines on what to do with executables
16:13:16 <racor> epienbro2: Let me broaden the question: What is the objective of the mingw packages?
16:13:19 <RemiFedora> I agree with spot
16:13:36 <racor> to provide a cross-compilation environment or a complete run-time environment?
16:13:56 <epienbro2> if the fpc prefers to have test/demo/helper executables in a separate subpackage that's also fine by me (although almost every current mingw package will have to updated in that case)
16:14:22 <epienbro2> racor, yes, our main target are developers
16:14:27 * spot doesn't really care if they are there, but I also don't want someone who wants to split out a "-test" or "-tools" subpackage to be able to do that.
16:14:39 <racor> In the former case, I don't see any use for mingw exes, in the latter case, banning info/man/aclocal + allowing exes seems inconsistent to me.
16:14:40 <spot> s/to be able/to _not_ be able
16:15:04 <epienbro2> developers can use the mingw toolchain to build their own packages and create redistributable installers for them
16:15:23 <abadger1999> epienbro2: related question -- do we want full fledged applications like bind to be includable under this policy? -- it seems like the current wording allows this.
16:16:23 <tibbs|w> If they're built from source, I don't really see why not.
16:16:35 <epienbro2> abadger1999, we don't allow cross-compiled end-user applications (like pidgin, firefox) to be introduced to fedora
16:16:48 <spot> i don't think it is likely someone will confuse mingw64-bind with bind.
16:16:48 <tibbs|w> I'm not sure what use they would have, though.
16:16:59 <tibbs|w> I mean, you could run them with wine or something.
16:17:06 <abadger1999> epienbro2: It is allowed to bundle all executables which built while compiling libraries in the binary rpms.
16:17:23 <tibbs|w> But this was kind of the expected result of having this mingw stuff in the first place, wasn't it?
16:17:45 <epienbro2> abadger1999, correct, that is the exact situation which we tried to document in the draft
16:17:48 <abadger1999> I think that sentence confuses the bind situation then :-)
16:18:29 <epienbro2> english is not my native language so perhaps some lines need to be rewritten to become more clear
16:18:39 <spot> epienbro2: what abadger1999 is trying to say is that bind builds libs and the bind daemon. This wording would permit the bind daemon to be packaged along with the libs.
16:19:01 <epienbro2> ah I see
16:19:11 <tibbs|w> The problem is that to allow any executable but to disallow "applications" you would have to somehow provide a way to distinguish an executable from an application.
16:19:24 <abadger1999> <nod>
16:20:12 <epienbro2> yeah, we tried to draw a line somewhere, but we failed to come to a generic guideline about this
16:20:57 <spot> Perhaps something like "Executables built for mingw32/mingw64 targets are not usually useful to package, however, it is left to the packager to determine if they are useful. If packaged, executables should either be in the matching target subpackage or in a new, dependent subpackage."
16:21:49 <RemiFedora> or "do you want you want with exe" ;)
16:21:55 <tibbs|w> I do think it's a fair question, though: what use is an executable in a mingw package?  Is the point that you'd somehow get them to a Windows machine?
16:22:22 <tibbs|w> (Keep in mind that I still don't understand what use a mingw package has in the first place.)
16:22:26 <racor> spot: I am opposed to this, because all these mingw-binaries do, is to add bloat to a developer's toolchain.
16:22:28 <spot> tibbs|w: the case i've seen is that you want to roll up the mingw bits into a "installer" that drops them onto a windows system.
16:22:47 <epienbro2> tibbs|w, there are situations where the executables are needed by libraries themselves (like gspawn-win32-helper.exe as used by glib2)
16:23:12 <epienbro2> so they need to bundled when redistributing the library
16:23:48 <racor> epienbro2: Used as part of a cross devel-toolchain? How are they used/run on Fedora-Linux?
16:23:59 <Ablu> (sorry if am interrupting (only wanted to watch): I for example use the exes to build windows installers with nsis on fedora
16:24:56 <racor> Ablu: Again, how do you use/run native mingw-executables on Fedora-Linux?
16:24:57 <epienbro2> tibbs|w: regarding 'why mingw on linux?': the major reason is performance and ease of use, when trying to use mingw (or more specifically msys) on a native windows environment then compiling binaries/libraries is really way slower and more error-prone
16:25:17 <tibbs|w> I didn't ask that question.
16:25:56 <Ablu> racor: i only wanted to give an example for a use of the exes. that was not related to your question
16:25:59 <tibbs|w> Anyway, is there a line to be drawn somewhere around "executables which are required by the libraries which are packaged"?
16:26:02 <epienbro2> racor, wine can be used for initial testing, but for real testing one has to copy everything over to a real windows environment
16:26:25 <tibbs|w> I mean, because I see the point that there's no point in building a windows version of firefox only to let people turn it into some kind of windows installer.
16:26:48 <tibbs|w> Or rather, there's no point in including the windows version of firefox in our distro for that purpose.
16:27:17 <tibbs|w> (I understand that firefox might not be the best example, as wine might need an HTML renderer.)
16:27:21 <racor> tibbs|w: IMO, there is no reason to put any windows version of anything in Fedora.
16:27:24 <abadger1999> spot: I'm okay with the concept of some windows executables being packaged. I think I'd be okay with your wording although it's less restrictive than I think epienbro is trying to capture... we can always update the guidelines later, though.
16:27:49 <spot> Just spitballing, but we could say "Executables which are required for proper functionality of the libraries must be packaged in the matching mingw32/mingw64 subpackage. All other executables are discouraged, but may be packaged in optional (dependent) subpackages at a packager's discretion."
16:27:51 <tibbs|w> racor: I can't disagree with you, but that decision was made some time ago and I'm trying not to be an obstructionist here.
16:28:19 <racor> abadger1999: Provided this rationale, we should start shipping arm-linux on x86 Linux and vice versa.
16:28:51 <epienbro2> spot, sounds good to me
16:29:03 <abadger1999> racor: if releng doesn't ask us to stop, then I might be okay with that too...
16:29:13 <racor> tibbs|w: I am referring to native windows executables. As they can not be run, they can not be used as part of a cross-toolchain.
16:29:27 <abadger1999> spot: +1
16:29:30 <spot> Okay, so I'll propose that: Draft + "Executables which are required for proper functionality of the libraries must be packaged in the matching mingw32/mingw64 subpackage. All other executables are discouraged, but may be packaged in optional (dependent) subpackages at a packager's discretion."
16:29:38 <abadger1999> +1
16:29:40 <spot> +1
16:30:01 <racor> Without the executables section in: -1
16:30:09 <geppetto> +1
16:30:23 <racor> Sorry, typo: With the executables section in -1
16:30:59 <tibbs|w> I guess I'd like more than discouragement, but I'm willing to see how long it takes for someone to decide some application needs to go in.
16:31:22 <tibbs|w> So +1 but I'll be happy to bring it up if I see craziness happening.
16:31:47 <RemiFedora> +1 (with tibbs comment)
16:31:50 <epienbro2> the fedora mingw sig is alive since 2009 and we've never seen any review requests for end-user applications yet
16:31:59 <spot> i see +1:5, 0:0, -1:1 on the proposal
16:32:01 <racor> tibbs|w: IMO. this section is phrased much too week and will be subject to discussions.
16:32:15 <tibbs|w> It could be the subject of endless discussions either way.
16:32:32 <racor> epienbro2: I hereby request you to ship a native windows: GNU-toolchain ;)
16:32:35 <tibbs|w> Currently there are no guidelines for this, so at least we have discouragement on the books.
16:32:56 <spot> since i think that is everyone we have present, i'll go ahead and mark it
16:33:15 <spot> #action Draft + "Executables which are required for proper functionality of the libraries must be packaged in the matching mingw32/mingw64 subpackage. All other executables are discouraged, but may be packaged in optional (dependent) subpackages at a packager's discretion." passes (+1:5, 0:0, -1:1)
16:33:33 <spot> epienbro2: i'll make that change before we do the writeup
16:33:39 <epienbro2> excellent, thank you
16:34:30 <spot> abadger1999: did any of the other python macros get cleared?
16:34:47 <abadger1999> spot: no -- I failed to pick up the thread that slavek started.
16:35:21 <abadger1999> I did take a look at the status of alternate ways of building... and I don't like how those will work with the proposed macros...
16:35:29 <abadger1999> So I do need to followup on that this week.
16:35:49 <abadger1999> spot: any idea if slavek and/or nick coghlin can make it to flock?
16:35:59 <spot> abadger1999: feel free to ask them directly
16:36:04 <abadger1999> spot: will do.
16:36:18 <spot> abadger1999: nick coghlan is at least pre-registered
16:36:49 <abadger1999> spot: ah... well, that's excellent -- I was thinking slavek might make it and nick might not (since he's in AU).
16:37:00 * abadger1999 will ping them
16:37:18 <abadger1999> there's quite a few python things that need to be updated in the next year or so.
16:37:44 * limburgher is here, but apparently not paying attention.
16:37:53 <spot> #topic LogFiles Guidelines - https://fedorahosted.org/fpc/ticket/142 - https://fedoraproject.org/wiki/User:Johannbg/Packaging/LogFiles
16:38:07 <spot> We tabled this ticket many eons ago because rsyslog was still being used.
16:39:56 <spot> Ignore the english spelling and grammar issues, i can clean them up before we push it
16:40:21 * abadger1999 can route to phx2 again, yay
16:41:00 <tibbs|w> I am not entirely happy with this.
16:41:14 <tibbs|w> What about daemons which rotate their own logfiles, for example?
16:41:21 <spot> tibbs|w: e.g. ?
16:41:31 <limburgher> Is that common?
16:41:38 <tibbs|w> It certainly used to be.
16:41:38 <abadger1999> definition of log file is circular. :-/
16:41:52 <tibbs|w> Not really sure how common they are now.
16:42:20 <abadger1999> supervisord rotates its own logs... at least some python web frameworks rotate their own logs -- I think that's built into the python stdlib logging package.
16:42:42 <limburgher> So maybe an "if not already rotating" caveat?
16:42:47 <spot> limburgher: *nod*
16:43:04 <tibbs|w> I'm also not sure we need four examples for minimal logrotate files.
16:43:27 <geppetto> the entire thing seems kind of "Meh" to me.
16:43:50 <limburgher> I'd keep the first, ditch the rest and say "hey, look at the man page".  Because honestly man logrotate is very good.
16:44:09 <tibbs|w> The entire thing seems like someone wanting to impose as many rules as possible, but I don't really disagree with the sentiment that things with endlessly-growing logfiles need to rotate them.
16:44:14 <spot> "Packages which generate log files must write out their logfiles in a package-specific (and package owned) directory under /var/log. Unless the software being packaged rotates its own logs, it must also ship a logrotation file to rotate its log file(s)."
16:44:27 <tibbs|w> But you could probably get that whole section down to a sentence, and maybe an example.
16:44:32 <spot> (as a replacement for everything in "Log Files on the filesystem"
16:44:52 <limburgher> Ideally though, if a ginormous logfile is a problem for someone and it usually gets fixed by adding logrotate support.  See privoxy in the last 24 hours.
16:44:57 <tibbs|w> And there's the one sentence.
16:45:30 <spot> tibbs|w: if you're referring to my text, that's technically two sentences. ;)
16:45:56 <limburgher> One string, though.
16:46:11 <tibbs|w> I put in an implicit semicolon to make it conform to my worldview.
16:46:15 <spot> Yep. I just don't see the value of mandating the dir naming, the .log extension, etc, etc.
16:46:34 * SmootherFrOgZ sorry, just finished a meeting at work, I've to head home. will scroll back for being in sync with you guys.
16:46:40 <spot> systemd doesn't care. rsyslog doesn't care. logrotate doesn't care. honey badger, well, you know.
16:47:41 <geppetto> I'm at best +0 on the entire thing … it seems like a mesh of "this is how it's normally done, so everyone must do it this way now" and "we want to hide rsyslog support, so mandate subpackages for it"
16:47:52 <abadger1999> the draft also mentions systemd journal persistance and that rsyslog is optional but doesn't really go into what that means...
16:48:12 <spot> geppetto: yeah. I think if FESCo mandated that rsyslog was no longer installed by default, this might make more sense.
16:48:15 <abadger1999> can packages simply not ship rsyslog config and systemd will take care of all their logging needs for them?
16:48:23 <tibbs|w> I can understand the idea of not wanting to drag an rsyslog dependency.
16:48:57 <geppetto> tibbs: But that could be argued about a lot of stuff … like libmicrohttpd ;)
16:49:09 <limburgher> Sigh.
16:49:25 <tibbs|w> That's a nuclear argument for another time, I guess.
16:49:39 <spot> is rsyslog still installed by default in Fedora 19?
16:49:39 <geppetto> Just not sure we should have policy saying "if you want to dep. on XYZ, you need to put it in a subpackage because that thing is a 2nd class package"
16:50:03 <tibbs|w> OK, so there are really two drafts here.
16:50:14 <tibbs|w> The log rotation stuff has nothing at all to do with syslog.
16:50:51 <limburgher> Right.  I'm OK with the simplified logrotate bits.
16:50:51 <tibbs|w> Can we just consider them separately?
16:50:54 <limburgher> Please.
16:51:07 <geppetto> Where do we want to put that?
16:51:50 <tibbs|w> I guess it deserves a new section in the main guidelines.
16:51:53 <spot> one sec, i'll whip it up
16:52:24 <tibbs|w> Should be very short; if we want more than a short example, we can push that out to a separate document.
16:52:25 <geppetto> I don't really #3 and #3.1 being somewhere … but it having it's own page seems a bit much.
16:52:33 <geppetto> "don't really mind"
16:52:35 <abadger1999> limburgher: we could either use the first example or the last example (and mark/explain that some of the lines are optional).
16:53:26 <limburgher> I prefer the first.
16:53:40 <abadger1999> people are probably just going to cut and paste.
16:53:57 <abadger1999> is th first sufficient for most packages/sysadmins/etc?
16:54:47 <geppetto> I think it's close enough, esp. to get started.
16:55:22 <abadger1999> <nod>  okee dokee
16:55:57 <RemiFedora> i think "standard" option should not be use in package logrotate config (ex compress)
16:56:48 <spot> https://fedoraproject.org/wiki/User:Spot/Packaging/LogFiles
16:56:50 <tibbs|w> Why is delaycompress even in there?
16:56:51 <spot> first pass.
16:57:32 * spot ninja edits one more cleanup
16:57:42 <tibbs|w> RemiFedora: Had to think about what you wrote, but I agree.
16:58:05 <tibbs|w> The stuff that's configured in /etc/logrorate.conf probably shouldn't be duplicated in the individual config files.
16:58:08 <RemiFedora> quite strange to have so much package with "compress", if it's usefull (and i think it is), should ne set in logrotate.conf, not in each package
16:58:32 <abadger1999> I don't like the definition of a log file as being a file under /var/log... it's circular with mandating that all log files must be written under /var/log.
16:58:35 <geppetto> tibbs: I assume because of how some daemon will write to the old file after a "rotate" for an indeterminate time, so it delays it
16:58:41 <limburgher> abadger1999: Agreed.
16:58:41 <tibbs|w> Well, of the nine logrotate.d files that happen to be on my system, only two have "compress".
16:58:50 <tibbs|w> But that's hardly scientific.
16:58:52 <spot> limburgher && abadger1999: okay, fix the wording. :)
16:59:19 <geppetto> Maybe more interesting is the lack of a default "rotate when file gets to be N MB" setting, but maybe that's more a global thing.
16:59:22 <spot> "a log file is defined as the text file output recording the operations and behavior of software" ?
16:59:23 <abadger1999> what is a log file?   :-)
16:59:40 <limburgher> don't hurt me, baby don't hurt me, no more. . .
16:59:44 <abadger1999> are systemd logs text files?
16:59:48 <abadger1999> do they count?
17:00:06 <abadger1999> we could also leave out the definition
17:00:38 * spot is fine with that
17:00:40 <tibbs|w> Also, I don't think the "Debugging" note needs to be there.
17:00:40 <abadger1999> iunless I'm the only one that thinks packagers should know what they are from experience.
17:00:41 <limburgher> That's probably better.  "I can't define a log file, but I know one when I see it"
17:01:28 <spot> okay, reload.
17:01:33 <spot> definition and debugging gone
17:01:48 <abadger1999> also, s!/var/!%{_localstatedir}/
17:01:53 <geppetto> So this bit "Packages which generate log files must write out their logfiles in a package-specific (and package owned) directory under /var/log" … we have to have a huge number of violators of that (random example: yum).
17:02:17 <spot> is /var really ever != %{_localstatedir}?
17:02:19 <tibbs|w> Personally I always use /var these days, because I dislike pointless typing.  But for consistency, sure.
17:03:09 <geppetto> I doubt anything works if we make it != /var … so I'm happy to just say /var :)
17:03:32 <abadger1999> spot: is %{_sysconfdir} ever really not /etc? :-)
17:03:45 <spot> abadger1999: point made.
17:04:18 <abadger1999> I mean, we could revisit the whole "macros must be used consisstently" guideline at some point... but maybe not today :-)
17:04:29 <RemiFedora> abadger1999, in scl ? ;)
17:04:43 * spot uses macros
17:04:48 <spot> reload! :)
17:04:53 <tibbs|w> The only one I ever use, I think %_libdir. Unless there's one other that actually saves typing.
17:05:22 <geppetto> spot: First sentence is still there … you really want that to be a "must" ?
17:05:28 <abadger1999> if we remove from the examples all the lines that are better set in the global logrotate conf file... what's left?
17:05:37 <spot> on the compress issue, I think it makes sense, and it is harmless to dupe. We should encourage the author to try to get the default changed.
17:06:07 <tibbs|w> Yeah, the mist screws, say, cron.  And yum.
17:06:15 <tibbs|w> "must".
17:06:15 <limburgher> abadger1999: I think for the present we need to stick to "is" rather than "should", unless we intend to file a BZ against logrotate to change them.
17:06:28 <spot> geppetto: okay, "should"
17:06:28 * spot edits
17:06:53 <tibbs|w> Not that I'd mind of those did move into subdirs of /var/log.
17:06:53 <geppetto> I guess +1 with the s/must/should/ change.
17:07:14 <tibbs|w> One other fun Q, though.
17:07:20 <tibbs|w> Should these be %config(noreplace)?
17:07:30 <RemiFedora> yes
17:07:32 <spot> they're config files. so yes.
17:07:33 <geppetto> Yeh
17:07:34 <tibbs|w> Obviously the answer is yes, but do we need to say that.
17:07:40 <geppetto> I'd hope not.
17:07:47 <geppetto> But I don't mind if we do.
17:08:00 <tibbs|w> I guess they're in /etc so rpmlint will complain either way.
17:08:06 * spot edits it in for good measure
17:08:13 <spot> since lately common-sense seems out of fashion
17:08:25 <abadger1999> yeah, those were in the templates that had the combined logrotate and rsyslog examples.
17:09:05 <geppetto> blah, +1
17:09:13 <spot> +1 on my draft text
17:09:16 <limburgher> spot: Indeed.
17:09:31 <abadger1999> +1
17:09:39 <limburgher> +1
17:09:49 <tibbs|w> +1
17:10:03 <RemiFedora> +1
17:11:00 <spot> #action Revised spot logfile draft approved (+1:6, 0:0, -1:0)
17:11:27 * spot doesn't really want to consider mandatory subpackaging for rsyslog until that is no longer the default.
17:11:44 <tibbs|w> Agreed.
17:12:51 <spot> #topic Open Floor
17:12:55 <tibbs|w> Is there something left to do on https://fedorahosted.org/fpc/ticket/190 ?
17:13:18 <tibbs|w> I guess that's not for us, but I'm not sure the proper bug got files.
17:13:40 <spot> that's a FESCo issue if anyone cares enough to raise it.
17:14:00 <tibbs|w> It's just that our ticket is still open, when it doesn't appear that we can do anything else.
17:14:35 <spot> tibbs|w: feel free to close it and ask any concerned parties to go to FESCo for resolution/enforcement.
17:15:31 * spot has a mostly working libxdiff fork to resolve the git bundling ticket, but it dropped down in my todo list a bit lately.
17:15:33 <spot> not forgotten though.
17:15:46 <tibbs|w> I guess we aren't the packaging police, but texlive sure caused some heartburn this week.
17:16:10 <spot> tibbs|w: yeah, that thing scares me. It's a FESCo concern though.
17:16:17 <abadger1999> The second part of the file permissions ticket could be looked at -- bress and halfie replied to me and I summarized in the ticket.
17:16:40 <spot> abadger1999: lets put it on the agenda for next week. my stomach is growling at me. :)
17:16:50 <abadger1999> No complaints from me :-)
17:16:50 <tibbs|w> Well, sort of.  I'm not sure anything in our guidelines works to prohibit what that package does with its spec.
17:17:02 <spot> tibbs|w: yep, i know.
17:17:15 * spot recognizes that texlive is a special sort of horror
17:17:34 <spot> So while it is not "illegal" it is tapdancing on the line.
17:18:15 <limburgher> spot:  It is a Great Old Package.
17:18:33 <tibbs|w> Maybe we should say that you should expect that people will come by and edit your spec file to fix issues, and that if you use some other system for creating your spec, you need to at least take care not to destroy changes made by others.
17:19:22 <tibbs|w> But to be honest, that package needs to at least have the big parts split out.  It's just not for us to say so.
17:19:27 <spot> tibbs|w: draft it up.
17:19:44 <tibbs|w> Sure, if anyone else thinks it's a good idea or even part of our domain.
17:20:36 <spot> it doesn't seem like a terrible idea.
17:20:45 <abadger1999> good idea +1, part of our domain... I kinda wish it was but I'm not sure.
17:20:48 <spot> but it might be fesco-land.
17:20:48 * spot is unsure.
17:21:11 <tibbs|w> I'll see what I can come up with that stays on our side of the divide.
17:21:11 <spot> maybe try it at fesco first and if they bounce it to us, it removes ambiguity. :)
17:21:25 <racor> tibbs|w, spot: Which aspect on texlive are you referring to? Am I missing something besides the monsterous split?
17:21:37 <tibbs|w> Well, there isn't a split.
17:21:39 <spot> racor: do a git checkout of the texlive package tree.
17:21:57 <spot> racor: there is a "spec" it uses, but it also includes a script that generates that spec.
17:21:59 <tibbs|w> It's all one package, with about 10000 separate upstreams, all with their own versions and release schedules, crammed into one packatge.
17:22:13 <tibbs|w> Acually it violates our bundling guidelines pretty hard.
17:22:16 <spot> tibbs|w: to be fair, the "texlive" upstream does the coordination.
17:22:39 * nirik submits a package review for a 'cpan-2013' package. runs.
17:22:46 <tibbs|w> And I'm sure xorg does their coordination, too, but they still have about 30 separate projects.
17:22:57 <spot> 30 is not 10000.
17:23:06 <tibbs|w> That only makes it worse, not better.
17:23:13 <spot> i didn't say it didn't.
17:23:22 <racor> OK, I am aware about this, however I feel the generated spilt itself is beyond reason (and broken in many details)
17:23:44 <tibbs|w> But really I'd only argue for them splitting out the biggest bits at first.
17:23:45 * spot points all texlive complaints (aside from specific bundling complaints) to FESCo
17:24:07 <tibbs|w> Does "texlive bundles all of texlive" count?
17:24:11 <spot> I'm not sure they are violating the bundling rules.
17:24:33 <racor> spot: https://bugzilla.redhat.com/show_bug.cgi?id=952263
17:24:34 <spot> all the other packages should be properly provides/obsoleted
17:24:36 <tibbs|w> Sure looks like it to me, but we're just blowing time at this point.
17:24:44 <racor> spot: https://bugzilla.redhat.com/show_bug.cgi?id=952283
17:25:05 <tibbs|w> "Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. " is the rule I'm looking at.
17:25:14 <racor> spot: Many more such issues are lurking if people would look into details.
17:25:30 <spot> tibbs|w: it could be argued that the texlive stuff is not multiple/separate.
17:25:43 <tibbs|w> By the same argument that all of Fedora is not separate.
17:25:44 <spot> while a substantial number have independent upstreams, a LOT of the tex components do not
17:26:22 * spot knows one thing for sure, tex and texlive give me a headache, and it will take some serious convincing for me to want to go into that snake pit again.
17:26:35 <tibbs|w> I mean, it's a tough issue, made tougher by the fact that nobody wanted to deal with 10000 new packages.
17:26:50 <spot> it may have also been practically impossible to do that way.
17:26:59 <tibbs|w> But I think there has to be a better medium to be reached; I just don't know how to reach it.
17:27:12 <tibbs|w> And the legal issues didn't help.
17:27:13 * nirik wonders if perhaps a dialog with jnovy would help?
17:27:56 <spot> anyways, this is all interesting, but lunch is calling me... so i'll end the official meeting and let this thread continue offlog.
17:28:00 <spot> Thanks everyone
17:28:02 <racor> spot: Did you try to use the current packaging? I have been spending hours to get some LaTeX/TeX docs building. Things are close to being unusable, IMO.
17:28:07 <tibbs|w> Yes, I think it's past time.
17:28:18 <spot> racor: yeah, it takes some patience.
17:28:26 <spot> #endmeeting'