Meeting:Packaging IRC log 20070130

(09:00:01 AM) ***spot is here
(09:00:15 AM) tibbs: I'm here.
(09:00:20 AM) abadger1999: I'm here
(09:00:29 AM) racor: me too
(09:00:58 AM) abadger1999: lutter, f13: ?
(09:02:05 AM) scop [n=scop]  entered the room.
(09:02:53 AM) abadger1999: With scop, we're five
(09:03:11 AM) spot: scop: you here? :)
(09:03:36 AM) scop: yep, otoh talking on the phone right now
(09:03:59 AM) spot: ok, we'll get started, hopefully f13/lutter will slide in late
(09:04:06 AM) ***Rathann|work sits in the back row
(09:04:08 AM) spot: First item:
(09:04:10 AM) spot: https://www.redhat.com/archives/fedora-packaging/2007-January/msg00162.html
(09:04:32 AM) f13: I'm here, just beating on the test1 RC tree
(09:04:49 AM) spot: Basically, if you put your php Class files in /usr/share/php, it makes life much simpler for users.
(09:05:14 AM) spot: The proposal is that we mandate this as part of the php guidelines
(09:05:51 AM) XulChris: this is for non-pear php classes, pear classes still go under /usr/share/pear
(09:05:57 AM) f13: seems to make sense.  Are there any Core packages that don't follow this?
(09:06:15 AM) spot: f13: looks like php doesn't
(09:06:23 AM) XulChris: f13: php package needs to add /usr/share/php to the default include_path,
(09:06:47 AM) f13: so lets get the php maintainer to put in his input
(09:07:02 AM) tibbs: Is php-Smarty in core?
(09:07:11 AM) XulChris: Smarty is in extras
(09:08:28 AM) tibbs: Poor Joe; we keep coming up with new PHP changes.
(09:09:25 AM) spot: is joe back in the office?
(09:09:42 AM) f13: not sure
(09:09:46 AM) XulChris: i think this was discussed a long time ago when we were doing the pear guidelines, but im not sure what became of it, i think it got lost in the discussion
(09:10:00 AM) XulChris: joe just replied to the bugzilla entry 5 minutes ago
(09:10:20 AM) tibbs: We were waiting on some other PHP-related decision as well.
(09:10:47 AM) spot: Perhaps when joe adds it to the php package, we can amend the guidelines.
(09:11:05 AM) XulChris: response from joe:
(09:11:07 AM) XulChris: This seems like a good idea; php (actually php-common) would also have to
(09:11:10 AM) XulChris: package the directory of course.  If this is agreed by the packaging committee
(09:11:13 AM) XulChris: I'll do it.
(09:11:37 AM) XulChris: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225434#c3
(09:11:39 AM) f13: ok, great.
(09:11:57 AM) spot: ok, lets vote on the addition then
(09:11:57 AM) tibbs: Yes, if he's happy then I'm happy; this makes quite some sense.
(09:12:01 AM) spot: +1
(09:12:02 AM) tibbs: +1
(09:12:03 AM) abadger1999: +1
(09:12:44 AM) ***spot looks around
(09:12:50 AM) f13: +1
(09:13:16 AM) racor: +1
(09:13:27 AM) spot: ok, thats 5. it passes, i'll write it up.
(09:13:39 AM) XulChris: thanks guys
(09:13:40 AM) spot: Next item:
(09:13:41 AM) spot: http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires
(09:14:01 AM) spot: Basically, the proposal is that we mention mock in the BR section as a good way to test for missing BR
(09:14:39 AM) tibbs: This isn't really a guideline change.  I think the text could use a couple of tweaks, but the idea is sound.
(09:14:43 AM) spot: Again, this seems rather obvious to me, and it doesn't hurt to state it.
(09:15:11 AM) scop: there's also mach in FE, which I still feel more comfortable with than mock...
(09:15:22 AM) scop: (for local use, that is)
(09:15:27 AM) f13: +1 adding mock information
(09:15:32 AM) f13: or even linking to mock information
(09:15:34 AM) spot: scop: yes, but mock is what the buildsystem uses
(09:15:44 AM) scop: sure
(09:15:59 AM) scop: buildsys doesn't use rmdevelrpms, but it's still "suggested"
(09:16:07 AM) spot: fair enough. :)
(09:16:19 AM) scop: just thinking that mach deserves to be mentioned, nothing more
(09:16:46 AM) spot: scop: ok, do you have some suggested text?
(09:16:59 AM) ***spot doesn't want to imply that one is better than the other
(09:17:17 AM) scop: "Another mock-like tool, <bold>mach</bold> is available in the repository too."
(09:17:26 AM) spot: works for me.
(09:17:45 AM) spot: tibbs: the text seems ok to me, what would you change?
(09:18:11 AM) tibbs: Minor grammar bits; nothing of any significance.
(09:18:27 AM) spot: ok. then lets vote on the proposal, plus the mach line.
(09:18:33 AM) spot: +1
(09:18:41 AM) abadger1999: +1
(09:18:49 AM) tibbs: +1
(09:18:57 AM) racor: +1
(09:19:37 AM) ***spot aims the orbital laser at f13
(09:20:21 AM) spot: scop?
(09:20:30 AM) scop: +1
(09:20:38 AM) ***scop puts down the phone
(09:20:39 AM) f13: +1
(09:20:58 AM) spot: ok, passes. i'll update the list for it too.
(09:22:26 AM) spot: hold on sec guys, i need to dump this into a wiki draft
(09:23:36 AM) spot: ok
(09:23:39 AM) spot: Next item: http://fedoraproject.org/wiki/PackagingDrafts/MakeInstall
(09:24:13 AM) tibbs: Ah, this bit again.
(09:24:13 AM) lutter: hey guys .. I am here now. Sorry for being so late
(09:24:22 AM) spot: basically, Michael Schwendt didn't think we were making the point clear enough, and suggested this clarification
(09:25:08 AM) spot: we've already added that %makeinstall must not be used when make install DESTDIR=... works
(09:25:15 AM) tibbs: There's certainly nothing wrong with clarifying.
(09:25:36 AM) spot: i agree, and i don't think there are any inaccurate or offensive statements in his clarification
(09:25:43 AM) lutter: yeah, looks good to me, especially since it only explains, and doesn't add any new requirements
(09:25:50 AM) scop: hm
(09:26:03 AM) scop: http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002
(09:26:09 AM) scop: it's already in the guidelines?
(09:26:39 AM) tibbs: The texts aren't equal, though.
(09:26:43 AM) spot: well, his version adds more clarification
(09:27:10 AM) scop: a
(09:27:11 AM) scop: h
(09:27:21 AM) scop: looks good to me too
(09:27:29 AM) spot: ok, vote time
(09:27:30 AM) spot: +1
(09:27:37 AM) scop: +1
(09:27:40 AM) f13: +1
(09:27:43 AM) abadger1999: +1
(09:27:50 AM) racor: +1
(09:27:56 AM) tibbs: +1
(09:28:00 AM) spot: and, it passes.
(09:28:07 AM) spot: i'll add it to the list
(09:28:12 AM) lutter: +1
(09:28:24 AM) f13: ok, I need to run actually :/
(09:28:35 AM) spot: ok, let me step on a landmine
(09:28:41 AM) spot: Next: Buildroot default
(09:28:57 AM) tibbs: Can't we just get that into RPM and out of all of the specfiles?
(09:29:01 AM) spot: Right now, the guidelines are a bit...vague on what the BuildRoot should be.
(09:29:07 AM) spot: tibbs: that would be ideal
(09:29:35 AM) f13: tibbs: I'm not confident we can get _anything_ into rpm at this point :/
(09:29:47 AM) ***spot will take that up with the rpm maintainer and see what his thoughts on that are
(09:29:52 AM) f13: even so, we'll have to support older rpm versions, thus need to have guidelines for them.
(09:29:56 AM) tibbs: It's not something that can be specified in a macro, right?
(09:30:00 AM) scop: has the new rpm.org project already taken off, by the way?
(09:30:09 AM) f13: scop: define 'taken off'
(09:30:09 AM) Rathann|work: it would spare us the occasional argument between reviewer and submitter about the buildroot
(09:30:16 AM) f13: there is a wiki, and traffic on the ML...
(09:30:48 AM) scop: ok, looks like it meets what I thought about with "taken off"
(09:32:28 AM) scop: s/The preferred value for the BuildRoot tag is/One good value for the BuildRoot tag is/ ; done
(09:32:51 AM) f13: maybe some verbage WHY we prefer this buildroot tag
(09:32:59 AM) abadger1999: scop: :-)
(09:33:04 AM) f13: less "YOU MUST USE THIS" more "This is why we require you to use this"
(09:33:21 AM) racor: scop: I prefer ONE mandatory buildroot
(09:33:35 AM) racor: no matter what it is, simply consistent
(09:34:03 AM) racor: for the sake of simplicity, to avoid arguments and for the sake of determinism
(09:34:11 AM) abadger1999: f13: +1.  there's currently no explanation for why the buildroot should be that way.
(09:34:30 AM) f13: racor: I still don't buy "consistency" as a technical reason.
(09:34:48 AM) f13: there _is_ a technical reason for wanting a specific buildroot.
(09:34:55 AM) f13: and now I really must go, lunch plans :/
(09:34:57 AM) spot: i think it is is better to have a mandatory buildroot for everything as well
(09:35:25 AM) rdieter [n=rdieter]  entered the room.
(09:35:33 AM) spot: if only because it will keep the arguments to a minimum
(09:35:53 AM) racor: f13: I don't say, the current "recommendation is bad", axel's is.
(09:36:22 AM) racor: but we could argue endlessly for what would be "perfect"
(09:36:52 AM) tibbs: I think it's important that if we're going to allow buildroot values other than the recommended one,
(09:36:54 AM) lutter: unless any old value will do, we should just settle on one mandatory setting that works
(09:37:18 AM) tibbs: we have to specify some criteria or else people could try to use /tmp and reviewers wouldn't know if that's bad or not.
(09:37:59 AM) lutter: exactly
(09:38:06 AM) spot: I think it is safe to make the current buildroot mandatory
(09:38:16 AM) spot: some parts may be over kill, but better safe than sorry
(09:38:30 AM) abadger1999: Maybe: "This buildroot is designed to make our packages easy for people with different buildsystems and requirements to rebuild the package. The key requirement is to make the buildroot unique when multiple packages are being built. The %{name}-%{version}-%{release} tags make the package unique among package versions.   The %(%{__id_u} -n makes it unique among users on multiuser systems."
(09:39:06 AM) tibbs: Anyone know what thimm insists on and how it differs from this recommendation?
(09:39:40 AM) racor: he (and thias) are playing tricks from inside of .rpmrc
(09:40:21 AM) racor: they say .rpmrc/.rpmmacros is the way solve all abiguities
(09:40:31 AM) rdieter: tibbs: mostly not including the __id_u bit(s).
(09:40:46 AM) ***spot really isn't sure that macro magic is the way to go there
(09:41:15 AM) racor: rdieter: yup, they also say: uids are irrelevant to a buildsy
(09:41:28 AM) spot: well, that is true
(09:41:44 AM) racor: My problem with their approach is
(09:42:06 AM) racor: their approach not being safe in a multiuser environment
(09:42:36 AM) spot: yeah, i think we have some responsibility to people rebuilding SRPMS locally
(09:42:57 AM) racor: aborted jobs having been launched by ordinary users leave undeletable files behind in /var/tmp
(09:44:10 AM) spot: OK, is anyone here opposed to making the suggested buildroot mandatory? (Suggested buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) )
(09:44:19 AM) tibbs: From a reviewer's standpoint, I have absolutely no objection to strictly requiring one value, but I'm not sure it's fair to decide on anything without thimm present.
(09:44:40 AM) spot: tibbs: ok. we can table this until thimm is here
(09:44:54 AM) rdieter: tibbs: I think we can simply assume he would vote against any mandated buildroot. (:
(09:44:56 AM) spot: the only reason i brought it up now is because of the core review
(09:44:59 AM) abadger1999: tibbs: Didn't thimm bow out of the PC?
(09:44:59 AM) tibbs: No objection to taking a vote and passing it around the other committees, though.
(09:45:18 AM) tibbs: Crap, did he leave?  I simply don't remember.
(09:45:23 AM) racor: spot: that's why I am opposed to tableing this case.
(09:45:39 AM) racor: either take or leave it - now.
(09:45:45 AM) spot: well, we have enough people for a vote.
(09:45:49 AM) tibbs: Anyway, please record my +1 to this.
(09:45:58 AM) abadger1999: tibbs: +1 to helps reviewers.
(09:46:04 AM) racor: +1
(09:46:06 AM) abadger1999: spot: +1 to mandating
(09:46:09 AM) spot: +1
(09:46:19 AM) rdieter: +1 (and be done with it)
(09:46:40 AM) spot: ok, thats +5
(09:46:44 AM) lutter: +1
(09:46:48 AM) spot: i'll add it to the list.
(09:47:11 AM) spot: The next item isn't ready: JPackage Exception
(09:47:26 AM) spot: i need to reword it some, i'll send it to the list for email vote today
(09:48:03 AM) spot: are there any other proposals we should hit before the core review this weekend?
(09:48:16 AM) rdieter: DesktopFiles?
(09:49:04 AM) spot: ok, http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles
(09:49:46 AM) spot: the one issue in that draft is the SHOULD/MUST about following the desktop-entry-spec
(09:49:52 AM) spot: is that a should or a must?
(09:50:14 AM) rdieter: I was going to leave that up to the consensus of this committee to decide.
(09:50:21 AM) rdieter: I think last time we leaned toward MUST.
(09:50:24 AM) tibbs: This is highly contentious, isn't it?
(09:50:36 AM) abadger1999: spot: I think it should be a MUST with the possibility of an exception until Gnome is fixed.
(09:50:38 AM) rdieter: tibbs: not really.  Haven't heard any outcries.
(09:50:39 AM) spot: won't d-f-i scream if it doesn't follow the spec?
(09:50:47 AM) abadger1999: Assuming that the gnome maintainers agree that there's a bug.
(09:51:07 AM) spot: abadger1999: are you getting this confused with the image caching?
(09:51:12 AM) spot: s/image/icon ?
(09:51:15 AM) abadger1999: No.
(09:51:23 AM) spot: whats wrong with Gnome then?
(09:51:34 AM) abadger1999: generic name / name is contentious is it not?
(09:51:43 AM) rdieter: If folks on the Desktop team insist on using GenericNames for some default apps, they can argue for it as an exception in the package review.
(09:51:56 AM) scop: the proposal isn't very explicit that use of d-f-i is a must, nor contains the rationale why it is a must
(09:51:56 AM) rdieter: abadger1999: is that what you're talking about?
(09:52:03 AM) abadger1999: rdieter: Yep.
(09:52:06 AM) spot: so, they don't want to use GenericName? or they do?
(09:52:22 AM) rdieter: spot: they *do*, for some things (as they do now).
(09:52:36 AM) rdieter: spot: like calling gaim "Instant Messenger" instead of "gaim"
(09:52:37 AM) spot: this draft doesn't seem to say that they can't do that
(09:52:39 AM) abadger1999: spot: evince.desktop::
(09:52:44 AM) abadger1999: Name=Document Viewer
(09:52:51 AM) spot: in fact, the example in the draft uses it
(09:52:56 AM) abadger1999: GenericName=Document Viewer
(09:52:56 AM) spot: Name=Comical
(09:52:57 AM) spot: GenericName=Comic Archive Reader
(09:53:02 AM) rdieter: spot: It highlights the Name/GenericName, etc, should be used properly. (:
(09:53:25 AM) spot: is the example not a "proper" use? :)
(09:53:33 AM) rdieter: spot: yes.
(09:53:46 AM) abadger1999: To me the example is proper and evince.desktop is not.
(09:53:53 AM) spot: abadger1999: oh, i see, they use the generic name everywhere
(09:53:56 AM) rdieter: abadger1999++, exactly.
(09:54:02 AM) abadger1999: Everywhere... for some apps.
(09:54:15 AM) spot: yeah, i think this is a MUST
(09:54:18 AM) spot: this is an upstream spec
(09:54:20 AM) rdieter: ok, MUST it is.
(09:54:30 AM) spot: of which Owen is listed as an author
(09:54:40 AM) spot: we can always just point at him and suggest they take it upstream. :)
(09:54:56 AM) abadger1999: instead of having separate logic somewhere that says use generic name for evince, firefox, and oo-writer they munge the .desktop file.
(09:55:50 AM) spot: yeah. i'm sure we'll take flames on this one, but it makes sense to me
(09:56:14 AM) spot: rdieter: i do agree with scop, its not clear that using d-f-i is a must, and is missing rationale
(09:56:15 AM) rdieter: In this new age of multiple spins, at doesn't make as much sense to have single, default apps anymore either.
(09:56:32 AM) tibbs: Good point.
(09:57:10 AM) abadger1999: rdieter: Right.  If we have default apps it should be configurable rather than hardcoded in the .desktop.
(09:57:26 AM) rdieter: spot: OK, I'll reword the section of d-f-i usage to explictly mention it's mandatory usage.
(09:57:57 AM) spot: rdieter: and give some reasoning why it is mandatory (safety, spec compliance, etc)
(09:58:10 AM) scop: with those changes, +1
(09:58:16 AM) spot: +1 with the changes
(09:58:18 AM) abadger1999: .. current usage breaks kde...
(09:58:23 AM) abadger1999: +1 with changes
(09:58:26 AM) lutter: +1
(09:58:32 AM) tibbs: +1
(09:58:33 AM) rdieter: +1 me too (:
(09:58:37 AM) racor: +1
(09:58:51 AM) spot: rdieter: please send an email to the list when you've made those changes
(09:58:56 AM) rdieter: will do
(09:59:16 AM) spot: ok, anything else before we adjourn?
(09:59:23 AM) scop: one thing
(09:59:29 AM) tibbs: Did we ever finish the Conflicts: draft?
(09:59:30 AM) spot: (i think this has been our most productive meeting ever)
(09:59:41 AM) spot: we approved it
(09:59:46 AM) abadger1999: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
(09:59:47 AM) abadger1999: ?
(09:59:48 AM) spot: and i don't think anyone vetoed it
(10:00:01 AM) scop: does anyone remember if the debuginfo ratify item has been presented to fesco/core?
(10:00:05 AM) spot: so it just need to be written up
(10:00:15 AM) scop: ie. if the ratify status is correct, or should it be writeup?
(10:00:45 AM) abadger1999: Pretty sure it should move to writeup.
(10:00:52 AM) spot: i think it should be writeup
(10:00:59 AM) scop: me too
(10:01:01 AM) abadger1999: Same with "Group tag"
(10:01:29 AM) spot: i want to confirm with paul that he's still on target for that rpm change
(10:01:37 AM) spot: if he's not, i'd rather hold there
(10:02:01 AM) spot: i'm going to put that as "followup" and hold it until we see the commited patch
(10:02:29 AM) abadger1999: spot: Well -- I think the group tag changes we voted were "Get Paul to make changes to rpm"
(10:02:50 AM) abadger1999: Actually making it optional waits until we get an alternative method in place.
(10:03:13 AM) abadger1999: (Groups in PackageDB, secondary comps file, etc.)
(10:03:29 AM) spot: i agree, i just need to talk to paul
(10:03:35 AM) spot: i'll do that today
(10:03:47 AM) abadger1999: Can we possibly vote on SourceRequirement?
(10:04:06 AM) tibbs: One example related to SourceRequirement:
(10:04:07 AM) spot: i think the contention on SourceRequirement was the bootstrapping section
(10:04:19 AM) tibbs: source is available, but the compiler isn't free
(10:04:34 AM) tibbs: Obviously not acceptable for Fedora, but does it deserve an example?
(10:04:59 AM) spot: yikes, is there a real world example here?
(10:05:22 AM) tibbs: Yes, there's a game written in some commercial BASIC variant.
(10:05:26 AM) tibbs: The game itself is GPL.
(10:05:35 AM) tibbs: The BASIC compiler costs $99.
(10:06:07 AM) tibbs: http://www.lostlabyrinth.com/
(10:06:18 AM) racor: similar case: source is GPL, but building requires open-source tools which aren't buildable anymore
(10:06:19 AM) spot: ok, i think it wouldn't be hard to add a section about that
(10:06:19 AM) abadger1999: IIRC, racor, you had the issues with the bootstrapping section?
(10:06:43 AM) racor: abadger1999: Yes, and I am still having them.
(10:06:52 AM) spot: racor: fwiw, i would consider that bootstrapping (uses open source binary bits to get it going)
(10:07:01 AM) abadger1999: What do we need in bootstrapping to make it acceptable?
(10:07:34 AM) racor: bootstrapping simply is too specific
(10:07:48 AM) spot: ok. i tried to make it rather vague.
(10:07:58 AM) racor: my classic example is a cross-compiler's target libs
(10:08:04 AM) spot: would it be preferrable to say "Exceptions" ?
(10:08:22 AM) spot: and nuke all the wording for "bootstrapping"?
(10:08:26 AM) racor: eg. cygwin's libs underneath linux->cygwin cross compiler
(10:08:45 AM) spot: How about:
(10:08:48 AM) spot: Exceptions
(10:09:09 AM) racor: or x86_68 Fedora-glibc underneath a i386-Fedora->x86_64 cross-compiler
(10:09:20 AM) spot: Some software (usually related to compilers or cross-compiler environments) cannot be build without the use of a previous toolchain or development environment.
(10:10:01 AM) racor: spot: much better
(10:11:17 AM) racor: For completeness, don't forget about "emulators" roms and "BIOS-roms"
(10:12:05 AM) spot: those are treated as content
(10:12:15 AM) spot: thus, exempt
(10:13:34 AM) abadger1999: Essentially, we're clarifying that the target libs for cross-compilers can also be treated as content, correct?
(10:13:59 AM) racor: hmm, even roms to be uploaded to some periperial HW?
(10:14:28 AM) spot: racor: if it meets the binaryfirmware exception, yes.
(10:14:46 AM) racor: abadger1999: Good point - My way of looking at it, is "is it run on the native HW?".
(10:14:59 AM) scop: opinions, should Packaging/Debuginfo be merged into Packaging/Guidelines or just linked?
(10:15:27 AM) spot: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
(10:15:31 AM) ***spot updated the text
(10:16:20 AM) spot: I think cross compile libs are a rather special case
(10:16:25 AM) spot: since they are open source
(10:16:45 AM) abadger1999: scop: It's rather long.  I think a summary for people to understand what's expected with the link to get the details of why and how.
(10:17:02 AM) scop: ack
(10:17:03 AM) abadger1999: (We might want to do that with all the guidelines at some point.)
(10:18:54 AM) abadger1999: spot: BinaryFirmware is mentioned in the top section too.  Can probably merge the two.
(10:18:56 AM) spot: ok, one last cleanup
(10:19:02 AM) ***spot just merged it. :)
(10:19:05 AM) abadger1999: :-)
(10:19:16 AM) spot: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
(10:19:22 AM) spot: ok, that should cover all the bases.
(10:19:52 AM) abadger1999: Vote?
(10:20:05 AM) spot: +1 from me
(10:20:12 AM) abadger1999: +1
(10:20:46 AM) racor: +1
(10:20:58 AM) tibbs: +1
(10:21:17 AM) scop: +1
(10:21:24 AM) spot: scop? lutter? rdieter?
(10:21:37 AM) scop: spot, I already voted :)
(10:21:52 AM) spot: ah, ok.
(10:21:53 AM) spot: thats +5
(10:21:57 AM) spot: sorry, irc lag. :)
(10:22:22 AM) spot: most productive meeting ever, i think.
(10:22:24 AM) spot: thanks all.
(10:22:41 AM) spot: i'll email the jpackage exception this afternoon.