From Fedora Project Wiki
(09:02:18) spot: so, since i have very little time today (only 30 minutes or so), lets get started
(09:02:24) spot: first topic: changelog
(09:02:50) spot: i think that there is value in having the ver-release in the changelog
(09:02:55) racor: forget about it, f13 made it clear he is not interested
(09:03:02) spot: and it seems like people would like to have a set of templates
(09:03:18) spot: racor: ehh, thats not what he expressed before you joined the channel. :)
(09:03:37) racor: yes, i am fed up with this topic
(09:03:50) spot: f13 suggested the following two templates
(09:04:05) ***f13 has to go to lunch
(09:04:07) spot: * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
(09:04:07) spot: - And fix the link syntax.
(09:04:14) spot: ^^ Template 1
(09:04:35) spot: * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
(09:04:35) spot: - 0.6-4
(09:04:35) spot: - And fix the link syntax.
(09:04:41) spot: ^^ Template 2
(09:04:56) thimm: The difference is a newline?
(09:05:01) rdieter: yup
(09:05:02) spot: yes. a newline.
(09:05:05) lutter: yep
(09:05:09) f13: either would be acceptable.
(09:05:16) lutter: one is what the emacs rpm mode does, the other what seth wanted
(09:05:46) spot: shall we vote on making these the official changelog templates?
(09:05:53) scop: I say we put a SHOULD on the changelog in the first place, and recommend using one of the templates above
(09:06:13) thimm: The field tp the right is CHANGELOGNAME
(09:06:16) f13: scop: changelog itself is a MUST
(09:06:19) tibbs: I prefer MUST for all of it.
(09:06:37) racor: T1 is version in CHANGELOGNAME, T2 is version in CHANGELOGTEXT
(09:06:47) thimm: I feel a bit uncomfortable with abusing a field
(09:06:50) scop: okay, as I said on list, I won't object to a MUST
(09:06:53) racor: makes a substantial difference
(09:06:57) thimm: Can we ask rpm upstream to change the field's semantics?
(09:07:02) scop: I disagree on it being an abuse
(09:07:13) spot: thimm: there are no semantics for changelog, rpm just sees it as "block of text"
(09:07:22) lutter: afaik, the field is only used for human reading purposes anyway
(09:07:26) tibbs: At this point Red Hat doesn't follow upstream RPM.
(09:07:29) thimm: There are semantics between date/author/text
(09:07:36) f13: given its just a block of text, and can be very different, its unlikely anything would succesfully parse it anyway
(09:07:42) scop: thimm, it's not "author", it's "name"
(09:07:55) thimm: Yes, but it is reserved for the author
(09:07:57) f13: tibbs: not "completely". We do backport some good stuff.
(09:08:00) scop: says who?
(09:08:10) thimm: f13 & spot: It is not a block of text
(09:08:20) thimm: It is dismentled by rpm into three fields per entry
(09:08:24) rdieter: personally, I don't care about the format (the templates look fine to me), but IMO, %{ver}-%{rel} at least SHOULD be in there somewhere.
(09:08:25) spot: thimm: except for the required date and name, it is.
(09:08:47) racor: timm: Since when?
(09:08:56) thimm: Since rpm 3 at least
(09:08:58) spot: right now, you have to have a changelog entry for every ver-rel that you make
(09:09:14) spot: i think it makes sense that we include that ver-rel in the changelog entry
(09:09:20) thimm: I don't mind template1
(09:09:24) spot: and these two templates seem like the sanest way of standardizing it.
(09:09:26) racor: timm: Nope, there is DATE,NAME and a list of TEXTS
(09:09:31) thimm: It is just an abuse and we should get the semantics straight
(09:09:36) spot: it gives packagers a choice, and ends this really unimportant debate
(09:09:50) f13: spot: +1
(09:09:54) lutter: spot: +1
(09:09:58) thimm: +1
(09:09:58) rdieter: +1
(09:10:01) scop: +1
(09:10:01) spot: +1
(09:10:01) tibbs: +1
(09:10:17) spot: ok, its passed. i'll write it up.
(09:10:20) tibbs: So, language?
(09:10:26) scop: hey, one more thing:
(09:10:41) spot: scop: yes?
(09:10:50) scop: people will start nitpicking whether there's a " - " between the email and v-r in template1
(09:10:59) scop: (or just a " ")
(09:11:05) f13: I heard ONE nitpick
(09:11:11) f13: frankly I don't care.
(09:11:15) tibbs: +1 for "-".
(09:11:28) scop: if we say people MUST use one of them, there will definitely be more nitpicking
(09:11:31) f13: does it _really_ matter?
(09:11:41) f13: can't we allow for - or " " ?
(09:11:49) spot: i think we can allow either.
(09:11:52) scop: that's what I'm suggesting
(09:11:55) thimm: +1
(09:12:08) f13: I guess that makes 3 templates, but *shrug*
(09:12:17) spot: all in favor of the third template ?
(09:12:19) racor: f13: it doesn't matter, the format for the email address before of it matters.
(09:12:27) lutter: +1
(09:12:29) rdieter: +1
(09:12:31) f13: +1
(09:12:33) spot: +1
(09:12:41) scop: I'll look into taking that into account in rpmlint: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/23
(09:13:04) scop: +1
(09:13:05) spot: ... thats 4 votes
(09:13:08) spot: 5
(09:13:17) thimm: 6, I voted in advance ;)
(09:13:21) spot: ok. got it.
(09:13:24) tibbs: Yes, I see six.
(09:13:38) spot: language?
(09:13:58) tibbs: When writing this up, don't forget that some changelog entries might not correspond to a version bump.
(09:14:12) spot: tibbs: gotcha
(09:14:15) thimm: Shouldn't they?
(09:14:23) f13: Any changes made to a package require a changelog entry. This entry must use one of the following templates:
(09:14:34) spot: thimm: its possible i might make a change today, not commit, then make another one tomorrow.
(09:14:48) spot: the second change get the v-r, not the first.
(09:14:54) thimm: k
(09:15:07) f13: yeah, when the package is released is when the entry should go in, or at least when attempted to build.
(09:15:11) rdieter: spot: then just append another entry under the current changelog
(09:15:16) f13: but thats getting pretty deep into the subject.
(09:15:29) spot: rdieter: i'm not really going to tell people how to write their changelogs. :)
(09:15:43) f13: rdieter: spot: in these cases, I useually pre-bump the v-r, and continue to add changes until I spin the package.
(09:15:44) rdieter: but we already are... (:
(09:16:00) rdieter: f13: agreed.
(09:16:14) spot: i'll document it clearly.
(09:16:19) rdieter: ok.
(09:16:36) spot: tibbs: language?
(09:16:56) tibbs: We covered what I was going to ask.
(09:17:05) spot: ok.
(09:17:19) spot: next: drafts hierarchy
(09:17:40) ***f13 has to run to lunch
(09:17:42) spot: right now, we have some pending (but not approved) documents in PackagingDrafts
(09:17:46) spot: i'd like to make this official
(09:17:48) tibbs: I had started PackagingDrafts/Changelog.
(09:18:14) tibbs: +1 for PackagingDrafts, BTW.
(09:18:25) spot: +1
(09:18:26) abadger1999: +1
(09:18:29) rdieter: +1
(09:18:30) thimm: +1
(09:19:08) scop: is there more info about that somewhere? this is the first time I've heard of it
(09:19:17) thimm: http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
(09:19:19) spot: scop: its on the todo page.
(09:19:31) spot: but basically, we need a place to put pending and unapproved packaging standards documents
(09:19:45) spot: so that it is clear that these are works in progress, not approved standards
(09:19:48) scop: okay, +1
(09:19:50) lutter: +1
(09:20:01) spot: ok, it passes.
(09:20:09) spot: next issue: pkgconfig
(09:20:32) spot: it has been proposed that rpms that contain pkgconfig files should 'Requires: pkgconfig'
(09:20:41) scop: non-issue, already covered by the current guidelines
(09:20:48) scop: through dir ownership
(09:21:03) thimm: But that rather implicite :)
(09:21:23) spot: scop: i'm not sure about that
(09:21:29) scop: well, OTOH we want to make it a no-no for other packages than pkgconfig to own /usr/{lib*,share}/pkgconfig
(09:21:47) spot: scop: now _that_ should already be covered by the guidelines
(09:21:48) rdieter: scop: that too, of course.
(09:22:17) tibbs: So there shouldn't be any question, but there seems to be, which means things should at least be clarified.
(09:22:37) spot: well, lets focus on these issues separately
(09:22:50) spot: do we need to explicitly have a Requires:pkgconfig for packages with .pc files?
(09:23:05) thimm: We should
(09:23:10) tibbs: What's are the alternatives?
(09:23:20) thimm: Otherwise the consuming package would have to BuildRequires: pkgconfig
(09:23:22) tibbs: 1) Package requiires _libdir/pkgconfig instead?
(09:23:32) tibbs: 2) Package owns _libdir/pkgconfig?
(09:23:40) racor: actually we should have a R: <dir> where *.pc is to be installed
(09:24:10) scop: $ rpm -qf /usr/lib64/pkgconfig
(09:24:10) scop: gnome-python2-2.12.4-1
(09:24:10) scop: gtk2-engines-2.7.4-3
(09:24:17) thimm: What scop and racor are saying is that we already need to have a Requires:pkgconfig due to dir ownership
(09:24:39) spot: is it feasible that pkconfig will someday not provide _libdir/pkgconfig ?
(09:24:50) rdieter: hope not. (:
(09:24:55) racor: What I am trying to say is: Does a devel package depend on the "application" pkgconf or on the directory
(09:25:22) thimm: That's effectively the same
(09:25:22) tibbs: BTW:
(09:25:28) tibbs: > repoquery --whatprovides /usr/lib/pkgconfig|wc -l
(09:25:31) scop: no it's not
(09:25:32) tibbs: 55
(09:25:33) tibbs: Ouch.
(09:25:35) thimm: Unless you are thinking of renaming the package form pkgconfig to pkg-config
(09:25:46) racor: thimm: Nope
(09:26:07) thimm: aside from the 55 packages ;)
(09:26:22) thimm: Right, relying on the dir is currenlty faulty
(09:26:37) tibbs: Well, 54 of them are bad. One of them is pkgconfig.
(09:26:39) thimm: And fixing these 55 packages first for a guidline is overkill
(09:26:59) thimm: Let's simply use Rex' suggestion: Requires: pkgconfig in -devel
(09:27:07) spot: well, i have to go now, but i vote +1 on making the Requires: pkgconfig a MUST for -devel with .pc
(09:27:31) lutter: sounds sane, +1
(09:27:35) thimm: +1
(09:27:47) abadger1999: Rex's suggestion has the advantage of fixing the problem he reported
(09:27:47) tibbs: +1
(09:27:49) abadger1999: +1
(09:28:00) racor: +1
(09:28:10) rdieter: +1 (keeping in mind pkgs with .pc files aren't necessarily all -devel ones)
(09:28:18) scop: what about /usr/share/aclocal?
(09:28:24) thimm: That's 7, it seems to pass
(09:28:25) ***scop ducks
(09:28:27) scop: +1
(09:28:29) rdieter: similar issue. (;
(09:28:34) racor: exactly the same as with pkgconfig
(09:28:41) spot: ok, i gotta go, if someone is not logging, please start. :)
(09:29:02) tibbs: Konversation always logs everything....
(09:29:06) scop: not quite the same: $ rpm -qf /usr/share/aclocal
(09:29:06) scop: file /usr/share/aclocal is not owned by any package
(09:29:30) scop: (but should be treated the same way, agreed)
(09:29:32) tibbs: So pkgconfig passes. Can we add the aclocal issue to the schedule and discuss it next week?
(09:29:34) racor: scop: bug
(09:29:40) scop: racor, yes
(09:29:53) abadger1999: rpm -qf /usr/share/aclocal
(09:29:53) abadger1999: automake-1.9.6-2
(09:29:58) thimm: scop: I have several owners of /usr/share/aclocal
(09:30:16) racor: "automake" must be the owner
(09:30:22) scop: I have none, but I have several files there
(09:30:24) thimm: # rpm -qf /usr/share/aclocal
(09:30:24) thimm: automake16-1.6.3-5.1
(09:30:24) thimm: automake14-1.4p6-12.1
(09:30:24) thimm: automake-1.9.6-2
(09:30:25) thimm: automake17-1.7.9-6.1
(09:30:27) thimm: automake15-1.5-14
(09:30:28) tibbs: Note that two X packages own it.
(09:30:29) thimm: libXaw-devel-1.0.1-1.2
(09:30:31) thimm: xorg-x11-util-macros-1.0.1-1.2
(09:30:41) scop: thimm needs to run "sudo fedora-rmdeverpms -y" ;)
(09:30:54) scop: s/deve/devel/
(09:30:55) racor: Sharing /usr/share/aclocal between automake* is OK
(09:31:33) tibbs: Can we put this on the schedule and move on?
(09:31:34) thimm: scop: You mean that several packages palce files in there w/o requireing automake, then, right?
(09:31:55) scop: so in that case it should be R: /usr/share/aclocal in order to not force a specific version of automake
(09:32:00) scop: tibbs++
(09:32:07) tibbs: thimm: Any response from FHS regarding libexecdir?
(09:32:09) racor: scop: Yes.
(09:32:15) thimm: No, none at all :(
(09:32:30) thimm: I followed the contact protocolls on the pathname.com site
(09:32:41) tibbs: We'll give it more time.
(09:32:44) thimm: The mailing list seems rather dead. :/
(09:32:59) scop: the standard is ready ;)
(09:33:08) tibbs: That's all of the urgent and held over items.
(09:33:23) tibbs: I think we can all agree that PHP is not ready for a vote.
(09:33:39) tibbs: Lots more work to be done there.
(09:33:50) tibbs: thimm: Did you want to talk about kernel module stuff?
(09:34:31) cweyl left the room (quit: "Ex-Chat").
(09:34:45) thimm: What's the general idea of having a review on them?
(09:34:50) thimm: I know some people are worn out
(09:34:55) thimm: (on this subject)
(09:35:07) scop: they have been reviewed to death numerous times
(09:35:08) tibbs: I admit to not understanding the issues.
(09:35:09) thimm: but I think there are some importnant bits to fix
(09:35:43) thimm: If you agree, I can setup a page with the issues and the fixes
(09:35:53) thimm: It takes an age or two on irc
(09:36:04) tibbs: Yes, let's have something to read so we can discuss it later.
(09:36:53) tibbs: I'm not ready to discuss the cross-compilation issue.
(09:37:25) tibbs: Anything else anyone wants to deal with?
(09:37:32) thimm: disttags?
(09:37:38) thimm: for RHEL and Fedora Legacy?
(09:38:00) thimm: sorry for Fedora Legacy and rawhide
(09:38:00) tibbs: Yes.
(09:38:24) thimm: For rawhide: the disttags should follow "test" versioning
(09:38:36) tibbs: I don't follow.
(09:38:43) rdieter: use fc5.91
(09:38:45) thimm: E.g. now rawhide should be considered 5.80 <= rawhide < 5.81
(09:38:48) racor: -1
(09:39:02) thimm: 8x->9x, sorry
(09:39:15) tibbs: Dots already mean something in release, though.
(09:39:20) rdieter: I'm with thimm, that's much cleaner than doing the otherwise necessary artificial Release++ bump
(09:39:37) scop: that's not doable in current FE devel, we already have fc6 there
(09:39:48) thimm: Yes, for after FC6.
(09:40:02) rdieter: scop: Just do one more Release++, then it'll be fine. (:
(09:40:06) scop: I say we discuss it after FC6 then ;)
(09:40:13) thimm: When FC6 get released, devel should become fc6.89
(09:40:25) racor: .fc5.91 collides with current VR practice
(09:40:36) rdieter: racor: how so?
(09:40:37) thimm: How?
(09:40:51) racor: 1.fc5.91
(09:40:53) rdieter: so what if we add another '.', Who's counting?
(09:41:17) thimm: It's rawhide, there no beaty contest there ;)
(09:41:40) scop: so let's say at test3 time we get fc5.93
(09:41:58) scop: then, even if *nothing* affecting that package has changed between test3 and final
(09:42:10) tibbs: If you have 1.fc5 and you want to bump it without bumping devel, existing practise is to use 1.fc5.1
(09:42:10) scop: folks want rebuild solely for the release tag, no?
(09:42:44) thimm: Youreally thing there will *ever* be a test3 with only few rebuilds? :)
(09:43:03) thimm: Rebuilding doesn't hurt, if it did, the the release is a brown bag one
(09:43:17) rdieter: scop's got a point, we'll have a bunch of fc5.9x tags in the fc6 repo. ):
(09:43:20) scop: noarch...
(09:43:43) thimm: What about noarch?
(09:43:45) racor: no ABI/API changes ..
(09:43:45) rdieter: not that I see any real problem with that. it'll still work.
(09:44:21) scop: many noarch packages candidates for not needing a rebuild across many (final) distro versions
(09:44:48) thimm: If a noarch package is indeed completely distro agnostig it should not have a disttag to start with
(09:44:56) thimm: (e.g. fonts or similar)
(09:45:11) f13: .fc5 packages in the fc6 repo is fine
(09:45:14) f13: it happens.
(09:45:16) rdieter: else, you'll see a few fc5.9x tags in the fc6 repo, but that's mostly harmless.
(09:45:28) f13: likewise you see .fc3 packages in RHEL4
(09:45:28) thimm: Not it the final repo, though
(09:45:36) f13: and you'll probably see .fc6 packages in RHEL5
(09:45:49) spot left the room (quit: Connection timed out).
(09:45:54) f13: and the only reason you won't see any .fc5 packages in FC6 is we're doing a full rebuild for various reasons
(09:46:10) f13: libtool changes for much faster linking, get thigns built w/ our new build system, and possibly sha256summing all rpms
(09:46:27) thimm: Yes, consider the amout of work saved, if when gcc/glibc require rebuilds, you only tune one var at the buildsystem
(09:46:30) f13: if it weren't for those, there very well could be many .fc5 packages in the FC6 release. Not every package changes between every release.
(09:46:43) rdieter: f13: the difference being is that the full rebuilds can be much easier, just update dist tag, rebuild, instead of...
(09:46:51) rdieter: having to increment Release for *every* pkg.
(09:47:09) f13: rdieter: not every single package uses %{?dist} though
(09:47:20) thimm: These ones will still need your love :)
(09:47:26) f13: and we shoudln't force that either
(09:47:29) rdieter: f13: that's "their" problem/fault, then. (:
(09:47:33) scop: tuning the disttag doesn't write changelogs
(09:47:33) tibbs: Still, I'm not seeing the necessity of fc5.9x tags.
(09:47:41) f13: what scop said
(09:47:44) thimm: scop: That's a good thing!
(09:47:45) rdieter: OK, I guess if %{dist} isn't mandatory, then that won't work.
(09:47:49) scop: not that I'd see *that* much value in "- Rebuild."
(09:47:50) f13: you end up getting a build w/out a changelog. which is a nono
(09:48:06) rdieter: tibbs: not a necessity, but it'll be nice.
(09:48:26) rdieter: f13: bah, personally, I think the lamest changelog entries in existence are those that say:
(09:48:36) rdieter: "bump for rebuild".
(09:48:46) tibbs: I really don't like the conflict with existing 1.fc5.1 usage.
(09:48:48) thimm: I agree with rdieter, this is just noise
(09:49:09) f13: rdieter: you mean like all 900 changelog entries that have my name in them? (:
(09:49:10) rdieter: tibbs: *what* conflict?
(09:49:29) tibbs: [11:42] <tibbs> If you have 1.fc5 and you want to bump it without bumping devel, existing practise is to use 1.fc5.1
(09:49:32) rdieter: f13: nothing personal... (and you're certainly not the only one)
(09:49:41) thimm: Some packagers are using the space after the disttag for release versioning, too
(09:49:43) f13: rdieter: I had to put something in there (:
(09:49:48) scop: note that we have to be very careful with the wording here, we've just approved a "every change to the package MUST be accompanied by a changelog entry"
(09:50:08) f13: scop: wasn't that already in the guidelines?
(09:50:09) thimm: We didn't vote, did we? ;)
(09:50:12) lutter: ' .. except if it's just for bumping hte release tag' ??
(09:50:35) abadger1999: tibbs: It would take a large number of changes to trigger that but it is overloading a field...
(09:50:38) rdieter: scop: right, every change to the *package*, not for every rebuild.
(09:50:47) scop: oops, so it was there, but the EVR "clause" wasn't
(09:51:05) scop: rdieter, binary rpms are packages
(09:51:21) thimm: "Every change to source or specfiles of src.rpms"
(09:51:22) rdieter: imo, automated (or not) rebuilds without changing the spec, sources, or patches, doesn't count
(09:51:43) scop: rdieter, -1
(09:51:56) scop: that can happen in released distros too
(09:52:21) thimm: Let's focus on mass-rebuilds of rawhide
(09:52:35) thimm: We're only taking about rawhide disttags
(09:52:44) thimm: s/taking/talking/
(09:53:03) scop: ...and FL?
(09:53:08) thimm: Next is FL
(09:53:12) lutter: but if we want to avoid mass rebuilds, these can become tags in fedora-released, too
(09:53:18) tibbs: What would be the semantics of using fc5_90? Nasty?
(09:53:27) scop: same as 5.90
(09:53:38) scop: (IIRC)
(09:53:46) lutter: how about fc5, fc5rawhide, fc5testX ?
(09:53:47) thimm: From rpm's POV it's the same
(09:54:04) thimm: dlutter: The disttag should be rpm-ordable
(09:54:06) lutter: (it's a little weird since fc5testX packages would really be for FC6 test X)
(09:54:16) lutter: thimm: that is rpm orderable
(09:54:20) f13: eew.
(09:54:33) lutter: it treats the whole thing as one string and does lexicographic compare
(09:54:39) scop: -1 to fc5foo
(09:54:45) thimm: dlutter: On fc5testX packages: fctestX is 5.9(X-1)
(09:55:01) rdieter: lutter: let's keep it simple, stick with fc<foo> where foo matches fedora-release-foo
(09:55:18) f13: fc5.90
(09:55:23) f13: fc5.91
(09:55:24) thimm: yEs
(09:55:38) thimm: And before test1: 5.89
(09:56:06) thimm: And if you need a mass rebuild between test3 and final: fc5.99 or whatever
(09:56:16) thimm: (in rawhide)
(09:56:28) f13: thimm: I"d rather see 5.92.1
(09:56:32) f13: or 5.93
(09:56:34) tibbs: I have to -1 this. I'm just not seeing the problems with using fc6.
(09:56:35) thimm: The only issue is what tibbs said, mixed release/disttags
(09:56:41) f13: because what if we rebuild twice? (:
(09:56:54) thimm: f13: anything between 5.92 and 6, it's up to you
(09:57:00) racor: -1, this is trying to solve a non-issue by wrong means
(09:57:11) thimm: We do have an issue
(09:57:14) f13: honestly though, I don't like seeing dist tag (ab)used for mass rebuild purposes
(09:57:19) thimm: That is manual mass rebuilds of FE devel
(09:57:43) rdieter: thimm: but as f13 pointed out earlier, not everybody uses %{dist}.
(09:57:49) lutter: f13: what do you mean ?
(09:57:52) scop: 0 if this is strictly for devel/rawhide and no packages in released versions will have 5.90-like disttags, -1 otherwise
(09:57:53) thimm: But the ones that do are already saved
(09:57:56) f13: because if you're rebuilding, you're rebuilding for a reason, and that reason should be listed in the changelog
(09:57:57) thimm: Problem is smaller
(09:58:20) f13: -rebuild for libtool changes
(09:58:24) thimm: f13: "rdieter: I had to put something in there (:"
(09:58:25) f13: -rebuilt for sha256sum signing
(09:58:48) thimm: changelogs are for important information. A rebuild from FC5 to FC6 is not
(09:58:58) thimm: You should know where you got the package from :)
(09:59:02) f13: thimm: a rebuild should only happen for a specific reason.
(09:59:28) f13: thimm: if you're rebuilding from FC5 to FC6 it should be because something changed and requires a rebuild.
(09:59:36) f13: we don't just rebuild every package just because its fun.
(09:59:43) racor: f13: a package dep resolver would be "the right approach" (TM)
(09:59:48) thimm: In that case you don't ever catch all bugs.
(09:59:52) tibbs: There's no chance of this passing as is and FESCo meeting is due to start.
(10:00:04) f13: thimm: you don't ever catch all bugs anyway
(10:00:12) rdieter: agreed, probably need to table this one.
(10:00:16) tibbs: Can someone try to digest this log under PackagingDrafts so we can look over it for next week (or on the list).
(10:00:18) thimm: Take it over to fesco, they know that these mass rebuilds are pain
(10:00:33) lutter: might be good to come up with a list of problems that need to be addressed for this on the mailing list
(10:00:36) scop: f13 should know all about it too
(10:00:36) f13: thimm: if there is significant reason to rebuild. speed / security improvements, binary incompatability, then rebuild. Otherwise think of the bandwidth. think of the children.
(10:00:47) lutter: there seems to be some disagreement what the actual problem is
(10:00:47) thimm: in rawhide?
(10:01:01) f13: thimm: rawhide leads to the next release.
(10:01:16) thimm: Yes, and mass-rebuild/bandwidth is for rawhide consumer
(10:01:18) f13: thimm: we don't rebuild whats in rawhide for the next release just because its the next release.
(10:01:30) f13: thimm: no, its for people coming from FC5 and upgrading to FC6
(10:01:32) thimm: You do so when gcc/glibc changes, right?
(10:01:45) f13: thimm: why force them to redownload each and every single package for minimal to no changes?
(10:01:53) thimm: And FC has an officer running through all packages
(10:01:54) f13: thimm: we do it in the space of rawhide.
(10:02:07) thimm: FE has no officier bt needs to make a call to all packagers
(10:02:15) thimm: The larger FE become, the larger the problem
(10:02:15) f13: thimm: we don't have an officer.
(10:02:17) f13: we have me.
(10:02:24) thimm: That's the officer :)
(10:02:37) f13: and we have a person making a change saying "I'd like to see all these packages rebuilt for this reason"
(10:02:43) f13: thimm: FESCO is an officer too
(10:02:51) thimm: "why force them to redownload each and every single package for minimal to no changes"
(10:03:04) thimm: why bumb the dist tag in rawhide then?
(10:03:22) thimm: The disttag in rawhide is bumbed on special occasions that will require mass rebuilds
(10:03:27) f13: thimm: for new packages that get built into rawhide.
(10:03:50) f13: thimm: what will you bump it too?
(10:04:03) thimm: "FESCO is an officer too": There was much pain in previous mass rbeuilds and there will be again.
(10:04:06) f13: do you want foo-3.6.fc5.93 packages?
(10:04:13) thimm: FESCO doesn't run around and fix all packages
(10:04:19) thimm: It can only ask the packagers to do so.
(10:04:22) f13: thimm: mass rebuilds are painful. Always have been, always will be.
(10:04:32) thimm: Not with the proposed scheme
(10:04:47) f13: thimm: it will still be painful unless you FORCE every package to have a %{?dist} tag.
(10:04:53) f13: which I don't think is the right thing.
(10:05:04) thimm: BTW I'm using this for ATrpms, which is the only way to keep up with rawhide
(10:05:16) thimm: (and the rest of the released distros)
(10:05:23) f13: and then you still have the case where packages are getting rebuilt for a SIGNIFICANT reason and there is NO CHANGELOG for it.
(10:05:35) thimm: Mass rebuilds for ATrpms means simply changing the disttag in rawhide
(10:05:47) thimm: Then drink some tee, coffe, and so on ;)
(10:06:00) thimm: Which is the significant reason?
(10:07:00) f13: thimm: this time around it could be 3 reasons for Core packages. 1) libtool changes to significantly improve performance of opening of shared libraries, 2) sign rpms with sha256sum, 3) make sure every package is built through brew
(10:07:23) f13: thimm: last time it was for security improvements in gcc so all compiled packages needed to be rebuilt.
(10:07:34) thimm: Yes, and then it's a bump from say 5.89.4 to 5.89.5
(10:07:47) f13: and then there was a bug in gcc that hit certain ppc packages.
(10:07:54) f13: thimm: what goes in teh package changelog?
(10:07:56) thimm: So document the disttag matching globally somewhere isntead of micro documenting it
(10:08:10) f13: sorry, I don't buy that.
(10:08:24) thimm: Package changelog should contain _source_ relevant parts
(10:08:47) f13: thimm: no, SOURCE should contain SOURCE relvant changes.
(10:08:50) thimm: Otherwise the packages just fork for a rebuilt
(10:08:52) tibbs: I think it should be obvious that we've closed for today; I have to run FESCO meeting at the moment.
(10:08:58) f13: thimm: package changelogs contain PACKAGE related changes.
(10:09:12) tibbs: You guys hash this out and make sure something gets written up so a bonehead like me can understand what's up.
(10:09:26) thimm: f13: A src.rpm can be rebuil on several archs/dists etc.
(10:09:30) f13: tibbs: we're not going to come to an agreement.
(10:09:34) thimm: There is no non-src.rpm changelog
(10:09:58) tibbs: f13: Right, but I think it would be good to see the different points of view written down.
(10:10:03) f13: thimm: thats why you have branches for the dists. If there are changes going into one disst but not the other, that gets commented.
(10:10:26) thimm: so you have branches, because we don't want to fix the issue with a simple disttag?
(10:10:57) f13: thimm: lets say you have package A in dist-fc5 and dist-fc6. You want to rebuild it in dist-fc7, and the only reason is that we switched to say intel's compiler. Thats the ONLY change. You should probably comment that in the pacakge, '- rebuilt for intel compiler'
(10:11:15) thimm: We should work towards consolidating bits, not forking specfiles for changelog entries of no value (no offence!)
(10:11:35) f13: thimm: we have branches because trying to do a single spec for all supported releases is the path to insanity. It does not work, it will not work.
(10:11:37) thimm: intel compiler for the whole distro or for one package only?
(10:12:16) thimm: f13: So how does it work for a couple of thousand of packages at atrpms, dag, dries, rpmforge etc.?
(10:12:17) f13: thimm: the compiler is in the distro. The package was rebuilt to get built BY that compiler.
(10:12:31) thimm: One package or all of them?
(10:12:45) f13: thimm: thats depends. NOt every package gets compiled, so it woudl be some of them, not all of them.
(10:12:53) thimm: The pont is if it's a local cahnge you need to comment on it
(10:13:09) thimm: If it is something global that would not change the src.rpm then don't micro comment it
(10:13:30) f13: thimm: when you have to maintain a single spec for RHEL2.1 -> FC7 you start to get EXTREMELY ugly spec files with HUGE amounts of special casing that is very difficult to maintain and to pass off to another person. IT can not work. It is not maintainable.
(10:13:55) thimm: Please check ATrpms/rpmforge, this is being done since some years now
(10:14:11) thimm: So the proff is that it *is* maintainable.
(10:14:32) thimm: But I see that we'll have to agree on disagreeing
(10:14:39) thimm: Arent't you fesco, too?
(10:15:00) f13: thimm: no, I wished to no longer be in, so I was not a voting option.
(10:15:18) thimm: OK, thought I kept you from the meeting
(10:15:32) racor left the room (quit: "Sorry, out of time, got to leave").
(10:15:48) f13: having it in the changlog answers the simple question. Why was this package rebuilt for this distribution. Well, lookie here, it's right in the changelog. Much better than trying to look at the dates, trying to figure out what significant thing happened to the distro at that time that would possibly effect this package.
(10:16:02) f13: silent rebuilding w/out changeloging is not a good practice.
(10:16:26) thimm: I agree if it's a local change
(10:16:34) f13: its a change period
(10:16:38) f13: a change that will effect the binary package
(10:16:49) thimm: But if it's a distribution wide change then the user should check the release notes or something more globally visible
(10:17:18) thimm: Consider RHEL5 and FC7 sharing the same src.rpm
(10:17:33) thimm: You'll get a recing of release bumbs
(10:17:38) dmalcolm_laptop [n=david] entered the room.
(10:17:46) f13: 'recing' ?
(10:17:59) thimm: The user is more confused if foo-1.2.3-4.fc7 is releated anymore to foo-1.2.3-6.rhel5
(10:18:17) thimm: And probably both are the same as foo-1.2.3-fc6
(10:18:23) thimm: (source/spec wise)
(10:18:31) thimm: racing - > racing
(10:18:34) f13: I'm not following.
(10:18:34) dmalcolm_laptop left the room (quit: Client Quit).
(10:18:46) thimm: Sorry, again.
(10:18:58) thimm: At fc6 time it was foo-1.2.3-1.fc6
(10:19:09) thimm: Various beta/rawhide rebuilds made that:
(10:19:17) thimm: foo-1.2.3-4.fc7 in rawhide
(10:19:28) thimm: foo-1.2.3-6.rhel5 in rhel5 beta something
(10:19:38) thimm: But the specfile/sources/src.rpm are still identical
(10:20:11) f13: they wouldn't be 1.2.3-6.rhel5 and 1.2.3-4.fc7 if they were identical
(10:20:15) thimm: It's easier to identify the similarity if they all keep the part before the disttag the same
(10:21:06) f13: this is hyberbole though. RHEL5 is based on FC6 and will be frozen before FC6 releases, there wouldn't be any rawhide fc7 packages in there, only ported fixes to the RHEL-5 branch.
(10:21:39) thimm: No, the packages I quoted are in rawhide and rhel beta respectively, not in on at the same time
(10:22:10) f13: I'm still having trouble following logical paths to how you'd end up at that hyperbole
(10:22:12) thimm: Anyway, don't get hung up on the numbers, use rhel5 and fc6 if that serves the example better
(10:22:25) thimm: hyperbole?
(10:22:39) thimm: I would have to look it up, or you can use a synonym. :)
(10:22:51) f13: thimm: a theoretical situation crafted only to prove a point, which wouldn't really happen in reality
(10:22:59) thimm: Ah, OK
(10:23:06) thimm: Why wouldn't it happen?
(10:23:20) thimm: Check all fc6/fc5 packages released at the same time.
(10:23:25) thimm: dovecot comes to mind
(10:23:43) f13: I'm struggling to see what the problem is you're trying to point out
(10:23:44) thimm: They only differ because the had to due to trivial changelogs (again no offence)
(10:24:10) thimm: The problem is that FE devel needs to manually (250 packagers) organize mass rebuilds
(10:24:25) thimm: No bot to do that since every packager has an authority status
(10:24:44) thimm: every time this had to happen either it was a big waste of resources
(10:24:55) thimm: or it was postponed having broken packages in the devel repo
(10:25:11) thimm: It's not any issue with FC because there some gets assigned to fix it
(10:25:16) thimm: Useing script etc.
(10:25:31) f13: and why couldn't someone get assigned to fix it in Extras land?
(10:25:38) thimm: But FE has not yet soemthing like co-mainatiners or some special officer to do that
(10:25:49) thimm: That's probably politics
(10:25:54) f13: and solveabl3e
(10:25:57) f13: -3
(10:26:04) thimm: Noone wants to fix (and possibly break) the others' packages
(10:26:19) f13: somebody has to take responsibility
(10:26:24) thimm: Well, you've been on fesco when they had these discussion.
(10:26:48) f13: I broke a few people's packages along the way, and if stuff failed to build, I filed a bug against the package owner. If they didn't respond in a timely manner, I just fixed it.
(10:27:13) f13: thimm: I may not have been in that meeting. I was having trouble paying attention to fesco, which is why I wanted off.
(10:27:37) thimm: I haven't been on the meeting myself
(10:27:48) thimm: I'm just repeating what others say
(10:27:52) f13: AFAIK, nobody has offered to be that person.
(10:27:53) thimm: (from fesco)
(10:28:06) thimm: Would you offer?
(10:28:14) f13: I don't have the time.
(10:28:26) f13: if I had the time, I would think about it.
(10:28:32) f13: or team up with somebody
(10:28:42) thimm: Well that's probably the issue with everybody
(10:28:50) thimm: And the Fedora Extras space is growing
(10:28:57) thimm: So the problem becomes bigger and bigger
(10:29:28) thimm: Also some packagers work some time offline on their packages and commit back a newer version.
(10:29:44) f13: the same happens internally
(10:29:54) f13: they just have to deal with me coming along and bumping their package.
(10:30:06) f13: I give them warning, and I give them the opportunity to provide me a list of packages they'll bump themselves.
(10:30:12) thimm: That would probably be a large stumbling block in fedora extras
(10:30:13) f13: I black list them from automation.
(10:31:01) f13: if it is for something significant, like binary incompatability, you can build the packages into a new collection and those that don't get built don't get released for the next release, until they rebuild them. THye get left behind and dropped.
(10:31:03) thimm: Still, the problem is there, in Fedora Extras, and I don't think they will find someone to do the dirty work
(10:31:16) thimm: So, it's better to have this at least in part automated
(10:31:43) f13: but we're back to bumping a package for a significant reason w/out any changelog entry (:
(10:32:03) thimm: But it's again the difference between a global change and a local change
(10:32:10) thimm: local should be always documented
(10:32:20) thimm: global changes not really.
(10:32:53) thimm: (not in package's %changelogs)
(10:33:39) f13: we can agree to disagree.
(10:33:44) thimm: Out of Fedora/Red Hat space: If the rule for "any chance including rebuilds should always bring a changelog entry") was always used
(10:33:56) thimm: then ther would be no clones like SL or CentOS. :)
(10:34:03) thimm: Let's agree on that :)
(10:34:11) thimm: (disagreeing)
(10:34:34) thimm: I wouldn't mind if you try to persuade fesco to have a release officer like you in FE devel
(10:34:47) thimm: But I think they won't like it
(10:35:31) f13: thimm: not exactly. CentOS rebuilds are rebuilding using the same compiler and tool set. Now, if CentOS rebuilt using say the intel compiler set, they shoudl probably bump and changelog.
(10:36:12) thimm: Maybe they are using the gcc compiler but have removed the Red Hat from the version string ...
(10:36:12) f13: so my example of bump for brew may not need a changelog for it, but its a side effect or a bonus of the more important 'bump to be signed with sha256sum'
(10:36:20) thimm: (just a joke)
(10:36:56) thimm: sha256sum is just an explicit example of why to "rebuild"
(10:37:16) thimm: This will have been done by FC6, or not?
(10:37:52) f13: depends, we have to do some testing to see what it could break
(10:38:05) f13: when its set to the default and older built rpms are introduced
(10:38:15) thimm: Anyway, there will always be some reason to do mass rebuilds
(10:38:19) f13: we're not sure if we'll just make it as an available option, or rebuild every package for it.
(10:38:26) f13: thimm: not always.
(10:38:36) f13: thimm: there is no reason to mass rebuild between FC6 and RHEL5
(10:38:46) f13: there may not be any reasons between FC6 and FC7
(10:38:59) thimm: FC and RHEL are different branches, let's not mix that
(10:39:00) f13: and there was times I think between 2 adn 3 or 3 and 4 that didn't ahve a full rebuild.
(10:39:11) f13: thimm: no, they're not different branches right now
(10:39:14) thimm: And I do hope that every RHEL packages gets built in a RHEL environment
(10:39:21) f13: thimm: RHEL5 is composed of the current FC6 packages.
(10:39:32) f13: thimm: the 'rhel' environment _is_ the fc6 packages.
(10:39:52) thimm: yes, just like RHEL4 of FC3 and RHEL3 of RH9/FC1, but they still forked a bit.
(10:39:56) f13: up until the branch point, which is the very latest time possible. Then the only rebuilding that will happen is for bugfixes.
(10:40:08) thimm: RHEL5 and FC6 will also deviate at the very end
(10:40:10) f13: there won't be mass rebuilding though.
(10:40:42) f13: fc6 is to RHEL5 as rawhide is to fc6
(10:40:49) thimm: I know
(10:40:56) thimm: But also what the disttag is concerned?
(10:41:20) f13: thimm: as it currently stands, there is no problem with RHEL5 having .fc6 packages
(10:41:30) f13: thimm: they'll be re-signed with the RHEL gpg key though.
(10:41:41) thimm: So half of RHEL5 will ship packages with "fc6"?
(10:41:43) f13: just like RHEL4 has some FC3 packages.
(10:42:02) f13: thimm: correct. Only the packages rebuilt for specific reasons will change from a .fc6 to a .el5 tag.
(10:42:27) f13: the QA and bugfixes during the betas will be applied to the FC6 packages, not a rhel5 fork.
(10:43:16) thimm: We should then give RHEL5 a disttag of fc6.1 ;)
(10:44:34) f13: thimm: there are a few packages for RHEL that aren't in FC6
(10:44:39) f13: er FC/FE in general
(10:46:40) thimm: f13: what's the purpose from you POV of %{?dist} if your policy is to always fork of rawhide rebuilds?
(10:47:07) thimm: In your model we end up with several branches of different specfiles
(10:47:39) thimm: The point of having %{?dist} is to have one specfile for all distros
(10:47:49) thimm: And to have the same specfile in all branches
(10:48:02) thimm: (therefore the same changelog)
(10:48:39) thimm: So if we look back at FC3, FC4, FC5 etc, we will find mass rebuilds at every development phase
(10:48:57) scop left the room ("Leaving").
(10:49:16) thimm: So almost all packages would have to have differing changelogs (iff every rebuild generates a changelog and a release bump)
(10:49:34) thimm: So where would be the point in inventing %{?dist} in the first place?
(10:49:42) f13: thimm: %{?dist} is useful at times until the branch drifts
(10:49:54) thimm: Only for new incoming packages which are built for all distros the first time?
(10:50:10) thimm: My questions are rhethorical
(10:50:22) thimm: I very much value automated disttags
(10:50:24) f13: thimm: or until they change.
(10:50:50) thimm: Yes, but in your model, every package will change from release to release
(10:51:03) thimm: Since there is always some mass rebuilds scheduled in
(10:51:09) f13: also, when we branch, people don't have to re-write %{?dist}. if it was in devel/ as ".fc5" when it branches to FC-5, then they would have to rewrite teh devel's to ".fc6" or whatever. When its %{?dist} they can leave it as is.
(10:51:25) f13: thimm: there isn't always some mass rebuild. Sometimes there isn't.
(10:51:35) thimm: In your model %{?dist} is useless ...
(10:51:50) thimm: Name me one FC release which didn't have at least one mass rebuild in rawhide
(10:51:55) thimm: Statistics are against you ;)
(10:52:07) f13: and sometimes a change comes along that effects every branch, like a security update. At these times all the packages may sync back up to a given n-v-r.
(10:52:26) f13: thimm: I'm not sure, I've only been here since part way through the FC5 release (:
(10:52:42) thimm: Well, take my word on it ;)
(10:53:09) thimm: OK, I'll have to go.
(10:53:28) f13: also, if a packager decides to bring new upstream source into a package set, nvrs reset and could be the exact same across
(10:53:32) f13: ok, later.
(10:54:03) thimm: Let's discuss it on list, or at least give some summary
(10:54:25) thimm: I'll write something up including your arguments, OK?
(10:54:40) thimm: Also tibbs'
(10:56:29) f13: sounds good