16:02:48 <spot> #startmeeting Fedora Packaging Committee
16:02:48 <zodbot_> Meeting started Wed Sep  9 16:02:48 2009 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:48 <zodbot_> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:04 <spot> #topic Roll call
16:03:10 <spot> nirik: thanks
16:03:49 * limburgher here
16:04:24 <spot> abadger1999, rdieter, tibbs, racor, SmootherFrOgZ: ping
16:04:35 * tibbs here.
16:04:38 * abadger1999 here
16:04:57 <tibbs> Really need to get sound on this machine so I can hear the pings.
16:05:22 <spot> i don't see Rathann or hans on irc
16:07:08 <spot> well... thats 4 of us. :/
16:07:31 <limburgher> I could make a puppet. . .
16:07:48 <racor> pong
16:07:54 <spot> okay, with racor that's five.
16:07:59 <hircus> spot: regarding the use of XZ/LZMA-compressed archives, are we considering older supported releases (EPEL-4, EPEL-5, perhaps F-10)?
16:08:26 <spot> hircus: not my call, ask panu or ffesti
16:08:46 <spot> so, lets get started
16:08:57 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source
16:09:23 <abadger1999> Would rather see this on a tips and ricks page.
16:09:27 <spot> fwiw, this seems like common sense to me, but if people need to be told it...
16:10:00 <limburgher> spot: sense != common. . .
16:10:09 <spot> limburgher: apparently. :)
16:10:22 <hircus> there need to be documentation on which release supports which compression format too
16:10:54 <limburgher> hircus: Most definately.
16:10:56 <hircus> presumably it's OK to have 2 tarballs of the same source release, since we still save space on mirrors by having smaller SRPMs?
16:11:09 <tibbs> We will?
16:11:40 <tibbs> The SRPMs are compressed in any case; any savings are going to be pretty marginal.
16:11:59 <spot> every tarball format besides xz/lzma should be supported everywhere
16:11:59 <tibbs> Not saying it's a bad idea, but not sure it needs to be written into the guidelines.
16:12:20 <abadger1999> tibbs: I don't think they are.  I believe that since SRPMs mostly contain compressed tarballs, we don't do compression on top of that.
16:13:04 <hircus> RPM archives are really just CPIO archives, right?
16:13:10 <spot> hircus: yes
16:13:10 <abadger1999> I was doing some checking for possible rpm corruption a few weeks ago with a modified rpm2cpio and found that out.
16:14:41 <spot> well, there is some size benefit here, and i don't think anyone would say this is a wrong approach
16:15:07 <spot> given the amt of packages that ville fixed for this issue, i'd say that enough people were unaware of it that it merits a mention
16:15:47 <spot> I would reword it slightly to be a "SHOULD"
16:15:55 <abadger1999> How would people feel if this was a pull box on the Source URL page?
16:16:08 <tibbs> Wouldn't bother me.
16:16:11 <spot> abadger1999: define "pull box" ?
16:16:23 <abadger1999> {{admon/tip| When available in multiple compression formats.....}}
16:16:28 <spot> oh, yeah.
16:16:32 <spot> that seems logical.
16:16:32 <limburgher> Me likely.
16:16:36 <tibbs> Does F10 not handle xz-compressed tar files?  I no longer have F10 around.
16:16:45 <spot> tibbs: i'm pretty sure it does.
16:17:01 <abadger1999> Then it won't be a should or a must... just a tip for people looking to make better packages.
16:17:02 <spot> tibbs: rpm does a callout for the %setup unpack
16:17:09 <tibbs> If it does, then we don't have anything special to mention.
16:17:18 <spot> tibbs: well, EPEL
16:17:37 <tibbs> I thought we decided that EPEL would document EPEL-specific issues on EPEL-specific pages.
16:17:39 <spot> abadger1999: i'm okay with that
16:17:51 <spot> tibbs: yes, but we should still link to the EPEL entry on the EPEL page
16:18:18 <tibbs> I wish we wouldn't.
16:18:26 <tibbs> But, meh.
16:18:36 <spot> well, okay, lets just vote on this tip add.
16:18:41 <spot> +1 from me as a tip
16:18:45 <tibbs> It's just that essentially every guideline is going to acquire some epel-specific issue now.
16:18:55 <tibbs> +1 as a tip.
16:19:04 <limburgher> +1
16:19:23 <abadger1999> +1
16:19:40 <spot> racor?
16:19:42 <racor> 0 needs more investigations
16:19:56 <spot> needs more investigations how?
16:20:21 <racor> is xz stable enough (I recall a serious bug a couple of weeks ago)
16:20:58 <spot> racor: stable enough to unpack a tarball.
16:20:58 <racor> define "best", the proposal uses best in the sense of "size"
16:21:18 <tibbs> We kind of use it to compress every binary package.  If it's not stable, there are far bigger problems than this suggestion.
16:21:30 <tibbs> "yields the smallest source rpm".
16:21:33 <skvidal> racor: to be fair xz also uses cpu time, too
16:21:48 <skvidal> s/uses/uses less/
16:21:49 <hircus> do we have documentation on how to suggest to upstream that they provide efficiently-compressed sources?
16:21:52 <spot> i would argue that size is more important than "speed of decompression" for this point.
16:21:56 <racor> tibbs: The bug was such kind, xz corrupted certain files (Sorry, I don't recall the details)
16:22:03 <hircus> e.g. with Java packages, a lot of them are Zip-only or Zip and tgz at best
16:22:27 <spot> hircus: i'm not sure we want to spend a lot of time telling upstream how to compress their files
16:22:44 <racor> skvidal: The proposal uses "best" in the sense of "size"
16:23:02 <abadger1999> racor: The corruption actually affected 0 of our rpms.
16:23:04 <tibbs> The proposal explicitly says "yields the smallest source rpm".
16:23:07 <skvidal> racor: agreed - I just meant xz has some other advantages
16:23:15 <hircus> so I guess the xz issue is a bit theoretical right now, does any upstream developer use it yet?
16:23:37 <spot> hircus: few, if any.
16:23:40 <abadger1999> "best" == size here.  Although xz is also a rival of gzip in terms of decompression speed.
16:23:42 <tibbs> Judging from the number of packages already fixed to use the tar.xz, I'd say at least several.
16:24:03 <spot> tibbs: they were fixed to use "the best compression by size", not necessarily .xz
16:24:32 <tibbs> That doesn't really invalidate the proposal, does it?
16:24:38 <spot> not at all.
16:24:45 <racor> hircus: Several, the latest autotools can even generate them.
16:25:10 <spot> racor: any chance you would reconsider, especially since this is just a tip, not a requirement?
16:25:36 <tibbs> Or, perhaps detail which investigations you'd like to see done.
16:25:42 <racor> spot, tibbs: the reformulate it to use "size"/"smallest", not "best"
16:26:07 <spot> i have no issue with doing s/current best/smallest
16:26:38 <spot> s/best/smallest
16:26:45 <tibbs> Where does the actual text say best?
16:26:54 <tibbs> I guess "the next best would be" is the text you object to?
16:26:57 <spot> "current best in terms of compressed size and time taken to decompress."
16:27:07 <spot> "The next best would be..."
16:27:18 <abadger1999> Here's what it looks like reformatted as a tip: https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source
16:27:48 <tibbs> Perhaps just remove any mention of comparison between formats?
16:28:00 <tibbs> "Use whichever is the smallest"?
16:28:55 <hircus> that is a good point
16:29:04 <spot> i'm fine with that
16:29:27 <racor> tibbs: Agreed. Makes clear the intention is "size".
16:29:53 <tibbs> That's what the first sentence does.  If that's sufficient, the other two sentences are superfluous.
16:30:21 <racor> tibbs: Good idea - even better, IMHO.
16:30:29 <abadger1999> Okay -- alternate text: https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source
16:30:31 <spot> "If the upstream source archive is available in multiple formats it is best to use the smallest source archive available with regards to size. This ensure the smallest source rpm to save space on the mirrors and downloads of source RPM packages."
16:30:47 <racor> spot: +1
16:30:56 <spot> actually, i like abadger1999's draft too
16:31:09 <spot> "If the upstream source archive is available in multiple compression formats it's best to use the one that is smallest in size to save space on the mirrors and downloads of source RPM packages."
16:31:57 <hircus> that does not make it explicit that smallest tarball --> smallest RPM, though. I mean, it should be obvious, but why leave room for guessing
16:32:29 <spot> hircus: do you feel that my suggestion makes it more explicit?
16:33:00 <hircus> I think it does. and people who just read the first sentence will know what to do -- the second sentence just explains the reasoning
16:33:17 <spot> anyone else have an opinion here? :)
16:33:21 <abadger1999> "If the upstream source archive is available in multiple compression formats it's best to use the one that is smallest in size. This ensures the smallest source rpm to save space on the mirrors and downloads of source RPM packages."
16:33:22 <racor> spot: I'd rather not mention any format, because these occasionally change (remember lzma, it's rather new, but almost dead already)
16:33:32 <spot> racor: fair enough.
16:33:34 <hircus> abadger1999: nice
16:33:43 <spot> abadger1999: looks good
16:33:51 <spot> okay, lets vote on this revised tip text
16:33:53 <spot> +1
16:33:54 <abadger1999> Okay, I +1
16:33:57 <limburgher> +1
16:33:58 <tibbs> +1
16:34:05 <racor> +1
16:34:20 <spot> #agreed Revised tip text for smallest source passes.
16:34:48 <spot> #topic Move https://fedoraproject.org/w/index.php?title=SIGs/Games/Packaging into Packaging namespace
16:35:10 <tibbs> I'm amblvalent.
16:35:37 <racor> so am I.
16:35:39 <spot> well, for what it is worth, these guidelines conflict in a few places with our own
16:35:40 <abadger1999> I like some of the bullet points but others conflict with the general guidelines.
16:36:03 <spot> I'm inclined to let the Games SIG regulate itself here...
16:36:25 <tibbs> Most of these are just "tips for better game packaging".
16:36:27 <spot> it is worth noting that they do not consider these requirements, but "strong suggestions"
16:36:36 <tibbs> Which is fine as it is, I guess.
16:36:48 <spot> I think I'm -1 here. not because they're bad, but i don't see the need to drag them in
16:36:48 <abadger1999> Well, we could break it out similar to the language specific guidelines.
16:36:49 <limburgher> As a longtime SIG member, that's the way I've always taken them.
16:37:01 <tibbs> Well, the issue has come up in reviews.
16:37:26 <tibbs> The issue of conflicts with the main guidelines, though, does need to be addressed.
16:37:38 <abadger1999> But I wouldn't want to enforce all of these on packagers (like Group: Amusement/Games)  That's something the Games SIG can ask for but not something we should have in the general guidelines.
16:37:45 <spot> Well, the two conflicts i see is around the forced inclusion of the License file and the forced Group
16:38:06 <spot> neither of these items am i comfortable making a guideline
16:38:19 <tibbs> I understand why the License file thing is there.
16:38:29 <tibbs> Games tend to be the worst when it comes to licensing.
16:38:30 <spot> but at the same time, if a games packager wants to do it, i don't have an issue with it
16:38:52 <tibbs> Group: is just outdated info.
16:38:53 <spot> tibbs: yes, but it is possible that the packager gets it wrong and might expose themselves to possible liability
16:38:55 <limburgher> tibbs: Boy howdy.
16:39:01 <spot> albeit, unlikely liability, but still.
16:39:15 <tibbs> That page hasn't actually changed since it was imported from moin.
16:39:47 <tibbs> Really, if the Games SIG wants FPC to review its guidelines, that's fine.
16:39:52 <spot> I could see "strongly encouraging" inclusion of license files even when upstream does not, but i don't think we can make it a must
16:40:10 <spot> tibbs: yeah, i think that is a big point, they're not asking us to do that at this point
16:40:21 <tibbs> But right now  that page certainly can't move directly into the packaging guidelines even if we agreed it would be a good idea.
16:40:25 <spot> this request came in from rahul
16:40:31 <tibbs> Oh.
16:40:42 <tibbs> I guess that explains it.
16:40:59 <abadger1999> heh
16:41:08 <spot> so, as i said before, i'm inclined to -1 and let the Games SIG know that if they want to move these into the guidelines, we will reconsider.
16:41:20 <racor> IMO, enforcing /var/games/%{name} and /usr/share/man/man6 but disallowing %{_datadir}/games/%{name} is inconsistent.
16:41:30 <racor> also, I don't understand the GL stuff
16:41:33 <racor> => -1 from me
16:41:51 <tibbs> The GL stuff is actually nice for the users.
16:42:17 <tibbs> But our GL support is getting much better these says.
16:42:19 <tibbs> days.
16:42:22 <racor> Is it? How comes this GL stuff only applies to games and not to other GL packages
16:42:26 <limburgher> The GL stuff is good.  Let's say you're hardware shopping, you take a Games LiveCD to the store and try things out.  Make *sure* your favorite game works.
16:42:33 <tibbs> This document comes from the Games sig.
16:42:51 <tibbs> You can't expect them to write suggestions for things other than  games.
16:43:17 <limburgher> At least not in the docs for the SIG. . .
16:44:05 <spot> Well, with me and racor as -1
16:44:11 <spot> this does not pass.
16:44:12 <tibbs> -1 from me as well.
16:44:30 <limburgher> -1
16:44:36 <spot> #action Proposal to move Games/Packaging into Packaging namespace is voted down.
16:44:45 <tibbs> Maybe the games folks can take our comments as suggestions for improvement.
16:44:54 <spot> I'll send an email to the Games SIG
16:44:56 <tibbs> Not that they wanted this in the first place.
16:45:20 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData
16:45:30 <spot> this is a revision after we discussed this before
16:45:48 <tibbs> I have to admit, I still don't quite understand this.
16:45:52 <spot> also, i asked the author a few questions
16:46:07 <spot> Q: Are there any existing standards around voice data or its formats?
16:46:20 <spot> A: Currently, no, it appears each project has its own specifications.
16:46:43 <spot> Q: Are there any applications (in Fedora or otherwise) which can use this data in the format described?
16:46:52 <spot> A: Just gcin.
16:47:02 <tibbs> So what good is this guideline?
16:47:28 <spot> i suppose it is wishful thinking, to be honest.
16:47:33 <limburgher> If there's a slogh of software reviews incoming that will utilize this, then it's good.  But is that the case?
16:47:52 <spot> I think the individual who drafted this intends to start packaging voice data
16:48:10 <spot> he pointed at 517462
16:48:24 <tibbs> To be honest, we have no requirement for a specific number of package to use a guideline before we consider it.
16:48:33 <tibbs> Anyway, to specifics:
16:48:51 <tibbs> This endorses %description -l and such, which I understand is a stick issue.
16:48:56 <tibbs> sticky.
16:49:09 <limburgher> sticky how?
16:49:12 <tibbs> And I really dislike the raw sqlite calls in scriptlets.
16:49:18 <spot> well, it shows up in the example spec only
16:49:22 <tibbs> limburgher: There's the whole specspo issue.
16:49:38 <spot> and i don't think we actively discourage people from doing translated descriptions
16:49:39 <tibbs> Nobody's really decided where translations go.
16:50:10 <spot> fwiw, whenever someone offers to add one for one of my packages, i go ahead and put it in.
16:50:29 <tibbs> There's a difference between discouraging people and tacitly approving this method in a guideline.
16:50:36 <spot> i doubt anyone will see this in the example and interpret it as a requirement
16:50:40 <limburgher> tibbs: OIC
16:50:58 <spot> but, i also don't think the author cares about that point enough to complain if we drop it
16:51:08 <tibbs> Unless we want to actually have that discussion now, we should probably drop it.
16:51:17 <spot> it is worth noting that his native language is not english
16:51:49 <spot> i have no problem with dropping it from the example
16:51:56 <tibbs> Don't get me wrong, I wish someone would figure out the best way to do this.
16:52:08 <spot> the sqlite stuff is... not how i would have chosen to do it
16:52:13 <tibbs> In any case, the sqlite stuff bothers me more.
16:52:16 <abadger1999> scriptlets are wrong too.
16:52:26 <skvidal> tibbs: the translation stuff is something I'm interested in
16:52:27 <tibbs> At least hide this behind some shell scripts somewhere.
16:52:40 <abadger1999> they need to differentiate upgrade vs removal.
16:52:55 <skvidal> tibbs: maybe I'll write up the discussion james and I had about translations of description/summary tags for pkgs
16:53:06 <spot> skvidal: that would be interesting
16:53:31 <tibbs> Yes, it would be good to get some effort behind this.
16:53:48 <spot> is anyone interested in working with the author to turn his scriptlets into a shell script (possibly a macro file for rpm)?
16:53:52 <skvidal> tibbs: it more or less means moving all the translation stuff OUT of rpm
16:54:15 <skvidal> tibbs: and ignoring what it is specspo does very very badly
16:54:58 * spot watches everyone rush to volunteer
16:55:13 <tibbs> I'm still trying to understand what it's actually doing.
16:56:44 <tibbs> Honestly I don't know if it's worth it to talk about scripting this stuff until there's some idea of whether that's even a reasonable way to do it.
16:57:01 <spot> well, afaik, he's the only one interested in doing it
16:57:05 <limburgher> It looks like it's simply storing voice data in a unified way, somewhat like fonts, and then using a common sqlite db to store metadata, in a similar way to rpm and bdb.
16:57:48 <limburgher> Makes me a little nervous, not sure why each rpm couldn't put it's info in a text file somewhere and have whatever consumes the sqlite parse that.  One less thing to go wrong. . .
16:58:13 <spot> Yeah, i think the sqlite stuff is overkill too.
16:58:15 <tibbs> It just strikes me that metadata like that is up to the consuming package.
16:58:24 <tibbs> Or at least it should be.
16:58:57 <spot> Okay, let me take this back to him and see if he is willing to drop the sqlite db stuff
16:59:04 <abadger1999> limburgher: well -- a text file is harder to manage
16:59:11 <tibbs> That's true.
16:59:11 <spot> that should significantly simplify (or remove the need for) this draft.
16:59:15 <abadger1999> db and directories are easier for packagers to deal with
16:59:26 <spot> that is a point.
16:59:34 * spot is very much on the fence here
16:59:46 <spot> i think if this becomes a pain, we can always revise it later.
16:59:50 <limburgher> harder how?   Many languages have text file/conf file parsing available.  C++, python. .
16:59:54 <tibbs> It just seems that  this is basically asking FPC to define the format that applications (which aren't Fedora specific) are supposed to consume.
17:00:10 <abadger1999> The thing I don't like about the scriptlets is that they need to take upgrade vs removal vs install into account.  Otherwise I think they do what they're supposed to.
17:00:17 <abadger1999> tibbs: <nod> Agreed there.
17:00:18 <spot> tibbs: yeah, i would feel much more comfortable about it if something (gcin?) used that format.
17:00:19 <limburgher> tibbs:  Exactly.  Not really a packaging guidleline.
17:00:54 <abadger1999> I'm trying to figure out what the sqlite3 calls in %build are doing... Is the db they create used somewhere?
17:01:02 <limburgher> I don't like touching databases on install, upgrade or removal.  I know it's not a db server, but. . .
17:01:09 <spot> abadger1999: afaik, no.
17:01:20 <limburgher> abadger1999: owned by a common rpm perhaps?
17:01:29 <spot> abadger1999: would you be willing to talk with him about this to try to figure this out?
17:01:32 <tibbs> I guess that  database would be used by the application.
17:01:46 <spot> his english is decent. :)
17:02:01 <abadger1999> Well, AFAIK, it's a file voicedata.sqlite in the root of %{builddir}... that's not installed to the %{buildroot} so it's not being packaged.
17:02:25 <tibbs> Indeed.
17:02:27 <spot> %define voice_pkg_db %{_datadir}/voicedata/voicedata-package.sqlite
17:02:53 <spot> so, nothing owns it atm
17:03:00 <spot> (which is another concern)
17:03:37 <spot> abadger1999: willing? able?
17:03:48 <abadger1999> Trying to determine what we even wnat to know...
17:04:35 <abadger1999> 1) who uses the db (answered: just gcin) 2) Who uses the db?
17:04:47 <spot> well, to be fair, i'm not sure gcin uses the db
17:05:07 <abadger1999> Oops... 1) Who uses the data? (answered:  just gcin)
17:05:20 <tibbs> Honestly, this seems a good idea for a freedesktop.org project.
17:05:35 <abadger1999> 3) Who would be best to make a standard for this stuff?
17:06:10 <abadger1999> (If no idea, do you think freedesktop would be a common meeting ground for the participants?)
17:06:36 <spot> well, as is, i don't think this is approvable.
17:06:38 <limburgher> Sounds reasonable
17:06:45 <limburgher> spot: <nods>
17:06:53 <spot> abadger1999: would you take those issues to him and try to discuss it?
17:06:58 <abadger1999> 4) Implementation: Who owns the db on the filesystem?
17:07:14 <abadger1999> 5) Implementation: Scriptlets need to account for upgrade/removal/install
17:07:30 <abadger1999> 6) Implementation: what's this db created during the %build?
17:08:08 <racor> abadger1999: (3)) So far, I don't see any need for a standard. This all to me seems to be a very specialized package w/ a highly specific plugin system to me.
17:08:13 <abadger1999> That all our questions?
17:08:21 <spot> abadger1999: i think so.
17:08:35 <abadger1999> racor: Okay... except that the package doesn't even make use of the db yet...
17:08:44 <abadger1999> spot: Okay, Who is it that's pushing this?
17:08:51 <spot> Ding-Yi Chen
17:08:56 <spot> abadger1999: i sent you his info in email
17:09:04 <abadger1999> spot: k.  I'll take this.
17:09:12 <spot> abadger1999: thanks.
17:09:29 <spot> #action abadger1999 to talk to draft author
17:09:36 <spot> #topic Open Floor
17:09:50 <spot> any other items? we're at an hour and some change now.
17:10:03 <tibbs> Nothing from me.
17:10:34 <tibbs> There was that tab width strawman I wrote, but I really doubt it would pass.
17:11:06 <spot> yeah, i think you're right. :)
17:11:48 <spot> okay, then i'm closing this meeting out. thanks everyone.
17:11:50 <spot> #endmeeting