16:02:24 <spot> #startmeeting Fedora Packaging Committee
16:02:24 <zodbot> Meeting started Wed Sep 22 16:02:24 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:36 <spot> #topic Roll Call
16:02:49 <tibbs|h> Note that I am having a new air conditioning system installed in my house at the moment so I will be in and out.
16:03:02 <spot> tibbs|h: yeah, also, i think i forgot to announce this meeting via email
16:03:10 <spot> so, we may not end up with quorum anyways
16:03:35 <tibbs|h> I remember seeing discussion about it, but maybe it was at the end of the previous meeting.
16:03:54 <spot> yeah, it was mentioned at the last meeting
16:04:14 <spot> rdieter_work, abadger1999, SmootherFrOgZ: ping?
16:04:27 <rdieter_work> here
16:05:11 <kalev> hey, I just now updated https://fedorahosted.org/fpc/ticket/10 with a question I'd like to discuss
16:05:22 <kalev> damn trac ate all the nice formatting I had though
16:05:40 <Rathann|work> present
16:06:59 * Rathann|work pokes spot
16:07:33 <spot> yeah, yeah. :)
16:07:45 <spot> kalev: it looks okay in email though.
16:07:52 <spot> kalev: trac is wacky like that
16:08:27 <spot> i count tibbs, rdieter, Rathann|work, and me. which is not quorum. i'll wait for a few more minutes.
16:08:59 <kalev> Rathann|work: right before you came I said that I updated ticket #10 with something to discuss
16:09:09 <Rathann|work> kalev: yes, I see the e-mail
16:09:37 <spot> racor: here?
16:09:48 <racor> yep, sorry for being late.
16:09:53 <spot> racor: no worries
16:10:13 <spot> tibbs|h: if you have to go afk for a significant time, please indicate it so we're not waiting on you for a vote.
16:10:23 <tibbs|h> I'll try to let you know.
16:10:36 <spot> #action quorum reached
16:11:00 <spot> #topic Mozilla addon guidelines - https://fedorahosted.org/fpc/ticket/10
16:11:26 <spot> kalev has added some addition text for consideration around how to package Mozilla addons
16:11:31 <spot> additional, rather
16:11:34 * abadger1999 here late
16:12:44 <spot> kalev: so, in my reading, i would say that a mixed approach seems to make sense
16:13:20 <spot> kalev: if an extension/addon works in several products, it should be packaged in a way so that all products which support it can use that same package
16:13:45 <spot> as opposed to multiple binary packages with the same payload, targeted for different mozilla projects
16:14:05 <tibbs|h> I don't think the proposal was for the separate packages to have the same payload.
16:14:13 <tibbs|h> In fact, they'd just have some symlinks.
16:14:30 <spot> hm, okay
16:14:44 <tibbs|h> One thing that confuses me is whether the "single binary package" thing would require the use of triggers.
16:14:49 <abadger1999> If it's just symlinks but the actual code that's doing the work is the same, I'd think that one package would be better.
16:15:07 <tibbs|h> Because I think we'd be better off avoiding triggers if at all possible.
16:15:11 * spot nods
16:15:24 <abadger1999> MM... I agree with tibs's point
16:15:30 <spot> kalev: how often does the UUID for the mozilla projects change?
16:15:34 <kalev> not sure why we'd need triggers here
16:15:51 <tibbs|h> Install seamonkey, have existing extensions work with it.
16:15:53 <kalev> spot: there's one UUID assigned for each product which never changes
16:16:00 <abadger1999> kalev: Is there a %post script that needs to be run when an extension is installed?
16:16:12 <tibbs|h> How do you do that without triggering on browser installation?
16:16:16 <kalev> tibbs|h: we could just own all the directories leading up to that
16:16:26 <spot> tibbs|h: well, if the UUIDs are constant, we could just splat out all the symlinks
16:16:33 <kalev> abadger1999: no, no need to run a post script, just have to drop files (or symlinks) in the right place
16:16:41 <tibbs|h> So you just opportunistically install everything for every supported browser.
16:16:47 <abadger1999> Okay.  that sounds reasonable
16:16:52 <tibbs|h> If that works, great.
16:16:54 <spot> tibbs|h: opportunistically create symlinks, yeah
16:17:00 <Rathann|work> what about dependencies?
16:17:07 <spot> Rathann|work: my next question. :)
16:17:29 <spot> we could do some sort of a virtual provides thing here
16:17:46 <Rathann|work> I mean, the plugins should have something like Requires: npapi >= version and the browsers should have Provides: npapi = version
16:18:07 <kalev> Rathann|work: npapi is a completely different subject
16:18:20 <Rathann|work> oh
16:18:45 <spot> kalev: how should we ensure that a extension package is actually useful, e.g. what would it Require ?
16:19:01 <tibbs|h> I do think we'd want to hide the "every supported browser" thing behind macros.
16:19:24 <kalev> spot: if we go down the one package route, I think it shouldn't require anything
16:19:47 <spot> well, we could do that.
16:19:47 <kalev> if we choose to go for multiple packages, then each of the package should require the browser it's extending, I think
16:20:27 <spot> i suppose the argument of "no one will install mozilla-foo" and expect it to work without a mozilla family program holds water
16:20:57 <kalev> there was a recent package review where the submitter advocated for separate packages
16:21:10 <spot> kalev: what was the logic there?
16:21:18 <abadger1999> kalev: Was the codebase different or would it have been symlinks only?
16:21:18 <kalev> I think the reason was that he doesn't want to have the extension working for browser foo, but wants it in browser bar
16:21:33 <kalev> abadger1999: it would have been symlinks only
16:22:14 <spot> well, if we had a mozilla-extension-common and %{mozilla-client}-extension layout, it would solve the requires issue cleanly
16:22:16 * SmootherFrOgZ is around. Has to finish up with a $dayjob meeting
16:22:33 <spot> it would also permit packagers who knew that the extension didn't work with a specific %{mozilla-client} to omit it
16:23:05 <kalev> omitting is easy in any case: just don't install the symlinks
16:23:28 <kalev> allright, I looked up the package review
16:23:32 <spot> since the bits would be in the -common package, if they decided later to also install support for another client, they'd just pull down that subpackage with the new symlinks
16:23:58 <spot> there might be some confusion though about why it works in Firefox but not in Thunderbird/SeaMonkey/Whatever
16:23:59 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=583531#c17
16:24:19 <kalev> I tried to get the submitter to work on an official policy but he wasn't very interested in that :)
16:24:40 <kalev> so anyway, quoting: "I think forcing all mozilla applications to use it is just insane. For
16:24:43 <kalev> example, a user might need it for Thunderbird, but not for Firefox.
16:24:46 <kalev> "
16:25:28 <spot> i think i'm leaning towards the "-common with client specific subpackages" combined with helper macros to make the packaging simpler
16:25:53 <kalev> I should note that other existing extensions which we have in Fedora (addblockplus and noscript) install one binary package which makes it work in all supported browsers
16:26:15 <spot> kalev: are they just creating all the symlinks ?
16:26:20 <kalev> yeah
16:26:21 <Rathann|work> I kind of like the single package approach
16:26:25 <racor> kalev: Do all non-mozilla products ignore %{libdir}/mozilla/extensions/* or do they have it in their default extension search path?
16:26:28 <Rathann|work> for simplicity
16:26:43 <racor> Otherwise installing a mozilla extension would automatically activate the extension for all non-mozilla products, too.
16:27:15 <kalev> firefox uses extensions which are installed under %{libdir}/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ directory
16:27:20 <Rathann|work> racor: why would they even look for extensions there?
16:27:21 * abadger1999 leaning towards single package approach.
16:27:41 <kalev> thunderbird uses extensions under %{libdir}/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/
16:27:55 <racor> rathann: No idea, history, convention, ...
16:28:13 <spot> okay, so it sounds like people like the single package approach
16:28:19 <Rathann|work> if all the subpackages do is install some symlinks then I see little harm in having them in one package and just ensuring that at least one package that supports them is installed
16:28:25 <kalev> I don't really have a preference to use single or multiple packages; both have cons and pros
16:28:55 <kalev> Rathann|work: how do we ensure that at least one package is installed? We don't have Requires: thunderbird OR firefox OR seamonkey ...
16:28:56 <Rathann|work> and with virtual provides/requires we don't blow up the dependency tree needlesly
16:29:07 <kalev> ah, with virtual provides, yes.
16:29:14 <spot> kalev: can you work on a draft that does a single package approach, and include a section about when it is permissable for a packager to choose to omit a symlink for a client that is known not to work
16:29:32 <spot> bonus points if you come up with clever macros for the various UUIDs
16:29:39 <kalev> spot: I can, sure
16:29:49 <kalev> we'll need one exception I think
16:29:56 <spot> kalev: which is?
16:30:09 <kalev> if a package is known to work in only ONE mozilla product, it doesn't look good to have it in a common mozilla- namespace
16:30:19 <kalev> for example, thunderbird-lightning
16:30:37 <spot> kalev: what if it starts working in more later?
16:31:09 * spot wonders if that is likely enough that we care or not
16:31:23 <kalev> not sure what to do in that case.
16:31:35 <spot> i suppose we could go through a normal rename in that case.
16:31:54 <spot> kalev: okay, that exception seems to make sense to me, document it in the draft?
16:31:59 <kalev> will do
16:32:03 <spot> also, please make sure you list all the known clients and UUIDs
16:32:18 <abadger1999> I'd do mozilla-* and have a virtual provide for thunderbird-* at package maintainers discretion but... pkg name and virtual provide could be reversed in that thought.
16:32:44 <spot> abadger1999: i think reversing it might be less controversial
16:33:07 <abadger1999> <nod>
16:33:12 <kalev> we currently have two packages under thunderbird- namespace:
16:33:13 <kalev> thunderbird-enigmail-0:1.1.2-1.fc13.x86_64
16:33:13 <kalev> thunderbird-lightning-0:1.0-0.28.b2pre.fc13.x86_64
16:33:19 <kalev> (one of them might be from rpmfusion, not sure)
16:33:30 <spot> mmkay.
16:33:43 <spot> so, we'll revisit this issue when kalev works up that draft for us
16:33:48 <spot> kalev: thank you for your help here. :)
16:33:56 <mcepl> kalev: the former (the later is confusingly in component sunbird)
16:34:08 <kalev> no problem, glad to help
16:34:24 <spot> #topic $RPM_SOURCE_DIR revisit https://fedorahosted.org/fpc/ticket/12
16:34:59 <spot> as i'm sure you folks saw, there was some angry feedback on this item (which was approved in a previous meeting, but not yet written up)
16:35:01 <tibbs|h> Pushback?
16:35:16 <spot> I still believe the draft, as written, is correct and has merit.
16:35:18 <tibbs|h> It sounds like "I want to do what I want".
16:35:33 <spot> but as I said, I didn't want to be accused of "decision making by fiat"
16:35:35 <tibbs|h> Did we get an example of something you couldn't do without referencing sourcedir?
16:35:51 <spot> tibbs|h: no, merely that it was valuable for "readability"
16:35:59 <tibbs|h> To some degree I understand that.
16:36:23 <spot> tibbs|h: my rebuttal is that comments would resolve the issue without adding the risk of a broken package
16:36:35 <tibbs|h> I really wish we could have SOURCE-ABC macros where ABC was something descriptive instead of a number.
16:37:12 <spot> tibbs|h: well, you could do something like %global filefoo %{SOURCE2}
16:37:18 <spot> i think that would work
16:38:21 <spot> i have no problem with that, as it is still using the %{SOURCE#} macro
16:38:25 <tibbs|h> Is there an example of a package that uses the soon-to-be-banned notation that we could look at?
16:39:04 <tibbs|h> I'm really curious as to how readable it really is.
16:39:06 * spot looks, one sec
16:39:42 <tibbs|h> Because it seems to me that you still have to list out all of your SourceN: lines, but then can't find where they're actually used.
16:40:09 <tibbs|h> Now they're sawing holes in my ceiling for new ductwork.
16:41:34 <racor> tibbs: You gave an example in comment #1 in the ticket yourself: we'd loose wildcards/pattern matching.
16:41:54 <tibbs|h> That was purely theoretical.
16:42:03 <tibbs|h> And nobody demonstrated that you couldn't do it some other way.
16:42:20 <spot> racor: i couldn't come up with a practical example of where that wouldn't work by simply looping through the %{SOURCE#} items
16:42:22 <racor> not so: I have  local package which has several dozens of source files.
16:42:54 <tibbs|h> I do as well.
16:43:15 <tibbs|h> But that doesn't really argue against this rule.
16:43:16 * spot can't find an approved package that does this
16:43:21 <racor> It looks ugly with SOURCE#n, but ... it's much safer than it used to be with $RPM_SOURCE_DIR
16:44:46 <spot> So, i suppose the big question is: Does anyone feel like we should revise or revote on this draft?
16:45:33 <racor> Real world example: ftp://ftp.rtems.org/pub/rtems/linux/infrastructure/fedora/14/SRPMS/i586-pc-freebsd8.1-8.1-0.20100727.0.fc14.src.rpm
16:46:08 <racor> spot: no. I am in favor of enforcing SOURCE#n.
16:46:12 <Rathann|work> I think it's fine as it is
16:46:16 * spot pulls down 51M of SRPM just to see
16:46:49 <tibbs|h> I don't see the point in revising the guideline, but since its controversial perhaps we should run it by FESCo.
16:47:53 <spot> okay, seems sane.
16:48:14 <spot> #action $RPM_SOURCE_DIR requested to be sent to FESCo for ratification
16:48:14 <tibbs|h> I would still love for someone to come up with a way to iterate over SOURCEN values.
16:48:29 <spot> tibbs|h: its probably possible with some macro fun
16:48:53 <tibbs|h> I've never managed to figure it out, even after dropping down to lua.
16:48:55 <spot> probably very slow without rpm changes though
16:49:13 <spot> as i dont think you can know which are defined without brute force checking
16:49:23 <tibbs|h> I don't think speed is all that important when you just want to do the same thing to twenty SOURCEN files.
16:50:24 <spot> okay, lets move on
16:50:32 <spot> #topic New Java Guidelines - https://fedorahosted.org/fpc/ticket/13
16:50:47 * spot has not had time to diff this against the current guidelines
16:53:08 <rdieter_work> according to ml threads, it's mostly about -javadoc stuff.
16:53:44 <rdieter_work> and jni too
16:54:33 <spot> okay
16:54:38 <spot> so it all looks sensible to me
16:54:53 <abadger1999> http://toshio.fedorapeople.org/java.orig   http://toshio.fedorapeople.org/java.new
16:55:57 <rdieter_work> feedback on ml was good
16:56:51 <spot> okay, so i see no obvious "this is a bad idea" items in there
16:57:05 <spot> we can always revisit it if people find flaws in it
16:57:06 <Rathann|work> I notice that maven-based template doesn't have removal of binaries in %prep
16:57:18 <Rathann|work> like the ant-based one has
16:57:39 <abadger1999> misleading rewording:: ""Packages may declare release tags as defined by http://en.wikipedia.org/wiki/Special:Search?go=Go&search=Packaging/JPackagePolicy""
16:57:46 <spot> Rathann|work: i wonder if that is an omission.
16:57:55 <spot> accidental omission, rather
16:58:02 <tibbs|h> Do we really want to deal with jpackage stuff again?
16:58:07 <Rathann|work> spot: probably
16:58:27 <spot> The current text says "For now, refer to the Packaging/JPackagePolicy for release tags. That document should eventually be folded into this one. "
16:58:47 <spot> and JPackagePolicy was rewritten some time ago to drop the "jpp" extension
16:58:47 <Rathann|work> "Older JPackage packages contained %post scriptlets creating %ghost symlinks. These MUST not appear in Fedora Java packages and are actively being removed at JPackage."
16:58:54 <Rathann|work> what's the rationale for that? ^
16:58:58 <abadger1999> Right -- and that document says "no repotag"
16:59:10 <abadger1999> that's why I say the rewording is misleading.
16:59:27 <spot> abadger1999: gotcha
16:59:31 <spot> so, maybe something like:
17:00:05 <spot> "Java packages should follow the normal Fedora release guidelines. If a package is coming into Fedora from JPackage, please refer to Packaging/JPackagePolicy. "
17:00:33 <abadger1999> Yep
17:00:34 <spot> s/should/must
17:01:20 <spot> okay, so with that change and the addition of the binary removal lines in the maven template...
17:01:24 <spot> are there any other concerns?
17:01:39 <Rathann|work> spot: what I said 3 minutes ago
17:02:04 <spot> Rathann|work: dunno, but it isn't new
17:02:13 <spot> Rathann|work: it exists in the current Java guidelines
17:02:17 <Rathann|work> oh
17:02:36 <Rathann|work> well then no other concerns about the proposed changes
17:02:48 <spot> okay, gimme a moment to make these minor changes
17:03:00 <abadger1999> The filenames section is unclear... I can understand it by comparing to the previous version of the guideline
17:03:24 <abadger1999> But it's not clear what is being referred to when they say things like: If the package provides a '''single''' JAR and the filename provided by the build is <code>%{name}.jar</code> then this name '''MUST''' be used.
17:03:32 <abadger1999> %{name} MUST be used where?
17:04:19 <spot> abadger1999: i think the end of that line is clarified by saying "this filename '''MUST''' be used."
17:05:06 <abadger1999> Yeah -- kinda kinda redundant though?
17:05:24 <tibbs|h> Are all of those BuildRequires: lines in the maven template actually required?  Or is that just an example?
17:05:24 <abadger1999> The build spits out foo.jar.... why I owuld rename that to bar.jar?
17:05:32 <spot> yeah, but i suppose if people were renaming jar files, it might need to be stated.
17:05:36 <abadger1999> *why would I rename
17:06:00 <abadger1999> <nod>
17:06:16 <spot> i'm inclined to make that minor correction and leave it, even if it seems obvious
17:06:33 <abadger1999> So maybe add a sentence explaining what is this section for? (whether and how to rename jar files).
17:07:41 <spot> abadger1999: such as?
17:08:10 <abadger1999> spot: I can come up with something --- trying to review the rest of the document for other problems.
17:09:01 <spot> abadger1999: i just committed the minor changes we discussed already
17:10:35 * spot cleans up the Release Guidelines link
17:11:10 <spot> abadger1999: do you want to revisit this in the next meeting?
17:11:24 <spot> abadger1999: i'm happy to table this until then if you would like more time to consider it
17:11:26 <abadger1999> Is there a rush on this?
17:11:29 <spot> nope.
17:11:35 <abadger1999> If not, yeah, let's table 'til next meeting.
17:11:38 <spot> okay
17:11:48 <spot> #action minor cleanups made, draft tabled until next meeting
17:12:06 <spot> #topic Open Seat
17:12:23 <spot> I am going to send out the email with the candidates under consideration this afternoon
17:12:29 <abadger1999> :-)
17:12:31 <spot> please be sure to read it over and give feedback
17:13:01 <spot> #topic Open Floor
17:13:20 <spot> we're 12 minutes over the hour already, but the floor is open for any other topics
17:13:34 <abadger1999> I started work on the systemd guidelines.
17:13:46 <abadger1999> Not a rush since it's not the default for F14.
17:14:03 <abadger1999> notting said he'd look at them after the f14 busy-ness subsides.
17:14:14 <abadger1999> https://fedoraproject.org/wiki/Systemd_Packaging_Draft
17:14:25 <tibbs|h> Need to go afk now.
17:14:27 <spot> abadger1999: okay, please make sure you open a trac ticket so it isn't lost
17:14:32 <abadger1999> If anyone else knows about systemd, they're welcome to work on it -- I don't know anymore than is on that page.
17:15:05 * abadger1999 opens ticket now
17:16:19 <spot> okay, i'm going to close out the meeting in one minute, if there is no additional items raised.
17:17:31 <spot> Okay, thanks everyone.
17:17:33 <spot> #endmeeting