From Fedora Project Wiki
(Redirected from Packaging:IRCLog20060831)
(09:04:10) The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Thursday, August 31st, 2006 16:00 UTC
(09:04:15) thimm: Hi - 40 weeks? No he was once here.
(09:04:21) tibbs: Nickserv says it hasn't seen him: Last Seen: 39 weeks 6 days (10h 41m 44s) ago
(09:04:33) rdieter: jpo = Jose ?
(09:04:38) thimm: Maybe he used another nickname?
(09:05:07) tibbs: It is possible I'm confused about which nick he uses.
(09:05:51) tibbs: Stupid disconnect between email and the wiki and IRC...
(09:05:51) scop: he has done some CVS commits this week, so he's not entirely MIA
(09:06:16) abadger1999: Sorry I'm late.
(09:06:16) thimm: My logs show that he was on the meeting of 2006-07-20
(09:06:31) thimm: as jpo
(09:06:31) tibbs: thimm: Under the "jpo" nick?
(09:06:34) ***spot is here, had his head shoved in aurora for a moment. :)
(09:06:59) tibbs: Perhaps he just didn't identify himself o the server. Or it's screwed up, I guess.
(09:07:27) thimm: I think the C in IRC is for sCrewed-up
(09:08:03) thimm: Anyway let's get started, we're at least 7 active members chatting
(09:08:15) spot: sounds good
(09:08:28) spot: There is one more kernel module item we need to vote on
(09:08:46) spot: Do we want to permit kernel module packages in Fedora?
(09:08:55) thimm: That's not our call, is it?
(09:08:55) tibbs: Why is that our business?
(09:09:10) spot: we do say whether things can be in or not.
(09:09:23) rdieter: We, as a commitee can have an opinion certainly. (:
(09:09:25) spot: Right now, the guidelines say yes, assuming it is one of a list of kernel compat licenses.
(09:09:25) thimm: We're about the "how", not the "wheather" :)
(09:09:54) spot: we can pass this to the board if we don't think we're the right group.
(09:09:58) f13: I thought it was a board decision
(09:10:03) f13: since it was already posted to the board
(09:10:05) f13: to make the decision
(09:10:07) abadger1999: I thought it was already with the FPB.
(09:10:10) rdieter: fyi, I've asked the Board to take it up at th enext meeting.
(09:10:14) ***f13 had a nice chat w/ Max about this a week or so ago
(09:10:19) spot: ok. fair enough. we'll let the board deal with it. :)
(09:10:38) thimm: disttags for rawhide after FC6?
(09:10:55) tibbs: Can we cover the two "ratify" issues?
(09:11:08) cweyl left the room (quit: "Ex-Chat").
(09:11:12) spot: the two ratify issues were ldconfig and %makeinstall
(09:11:22) spot: did FESCO complain about either?
(09:11:41) rdieter: afaik, no.
(09:11:46) abadger1999: FESCo didn't complain
(09:11:54) spot: ok, sounds like these should be moved to writeup
(09:11:58) thimm: One looks incomplete
(09:12:14) scop: spot, could you lift the ACL on ReviewGuidelines?
(09:12:19) spot: thimm: thats because its a wording change on an existing item
(09:12:23) abadger1999: thimm: It segues into what's already in the Guidelines.
(09:12:28) thimm: OK
(09:12:40) spot: scop: sure. thought it was lifted already.
(09:12:44) thimm: Should we vote on both together on on each?
(09:12:44) spot: i'll do that after the meeting
(09:12:52) spot: thimm: we already voted on those
(09:12:59) scop: spot, thanks (and no, it's not lifted yet)
(09:13:02) thimm: So what needs to be done??? ;)
(09:13:10) spot: just needs to be written up
(09:13:24) spot: this is just a check to make sure FESCO didn't have a problem
(09:13:45) spot: OK, so lets talk about disttags for rawhide after FC6
(09:14:03) spot: thimm: this one is yours, feel free to drive. :)
(09:14:03) thimm: It's .fc7 vs .fc6.89
(09:14:28) thimm: Is this something than needs discussion?
(09:14:34) f13: .fc6.89 is confusing, will leak into the released tree, and doens't make any real sense inthe long term goal of the packages being geared toward fc7
(09:14:36) tibbs: Originally I had objections, but I thought about it a bit and won't object if there's really a need for this kind of thing.
(09:14:36) thimm: In a sense of something not being clear?
(09:14:37) spot: well, for starters, do we need it?
(09:14:54) spot: what advantage does it provide? devel is constantly in flux.
(09:14:56) thimm: leak into the released tree?
(09:15:12) spot: i'm not sure i see dist tags leaking. :)
(09:15:21) f13: thimm: something built in devel branch, never rebuilt in dist-fc6 branch.
(09:15:27) tibbs: It does conveniently eliminate this "needs.rebuild" business.
(09:15:32) rdieter: f13: I think that's part of the point of *using* it, to help avoid that kind of thing.
(09:15:40) thimm: You wouldn't csimply copy over rawhide bits w/o rebuilding?
(09:15:54) f13: thimm: we don't rebuild them for Core no.
(09:15:57) spot: it would help identify things that hadn't been rebuilt.
(09:16:08) spot: but what about things that don't need to be rebuilt?
(09:16:12) f13: spot: a packaging database woudl do that too
(09:16:13) abadger1999: tibbs: Although there are things that don't need rebuilds. With these tags we'd always have to do a post-test3 rebuild.
(09:16:24) tibbs: It also simplifies a plain rebuild because you don't have to bump the release.
(09:16:37) spot: tibbs: that is true
(09:16:51) thimm: It helps with mass rawhide rebuilds, too
(09:16:59) rdieter: hadn't we already concluded that rebuilds without changelog/release-bumps are bad?
(09:17:02) thimm: Better to rebuild one more than one less
(09:17:14) thimm: rdieter: no, why?
(09:17:29) rdieter: dunno exactly (:, I just remember have the discussion/debate.
(09:17:30) f13: rdieter: we went round and round on it, w/out a clear decision.
(09:17:50) abadger1999: We're starting the rebuild in FE earlier than test3 this time, will we be able to do that with the proposed disttags?
(09:17:57) thimm: I see some packages that have that many rebuild notes that the true changelog entries are drowned in
(09:18:01) f13: thimm: I'm pretty certain that Core will _not_ alter dist tags in the devel/ tree.
(09:18:06) spot: i think that rebuilds without a new e-n-v-r can lead to confusion. is this the package with the old dbus or the new dbus?
(09:18:08) f13: thimm: so Extras packages will not look the same as Core.
(09:18:18) thimm: abadget1999: FC6 can't be handled anymore that way
(09:18:27) thimm: because the disttag already is at fc6
(09:18:43) thimm: Had it been fc5.91 we could simply make it 5.92
(09:18:58) thimm: and all %{?dist} carriyng package would automagically rebuild
(09:19:01) spot: f13: well, if Core is unwilling to do this, then this point is seemingly moot (however, last time I checked, this committee had jurisdiction over both core and extras...)
(09:19:03) thimm: Out of the same src.rpm
(09:19:15) f13: spot: Core has the ability to veto, just like FESCO
(09:19:35) thimm: "if Core is unwilling": after all we make a suggestion and core/extras can shoot it down
(09:19:38) f13: thimm: the timing of the rebuild is never consistant, and many times things are rebuilt once during a devel/ cycle, and never again for that release.
(09:19:39) spot: yes, but we shouldn't ignore something just because Core might veto
(09:19:39) rdieter: then let them veto if they'd don't like it.
(09:19:48) tibbs: In any case, it wouldn't be up to us to tell Extras what to stick in their buildsys.
(09:20:05) abadger1999: thimm: I'm saying FE is rebuilding their proposed final packages for FC6 right now. So the disttag would have to be bumped to fc6 at this point rather than when Core goes to test3 or final.
(09:20:16) tibbs: Our function should be to decide whether these non-integer release tags break other guidelines. I don't think they do.
(09:20:25) rdieter: tibbs++
(09:20:29) spot: i don't think they break other guidelines.
(09:20:37) thimm: abadget1999: the disttag already is at fc6
(09:20:39) spot: but, we do own the dist tag guideline.
(09:20:49) thimm: It will either become fc7 or fc6.89
(09:20:49) spot: and changing that _IS_ in our domain
(09:20:59) spot: and it describes what valid dist tags will be
(09:21:00) tibbs: Of course.
(09:21:10) abadger1999: thimm: Substitute FC7 and FC7-1 in that sentence if it'll make it clearer.
(09:21:12) thimm: Let me list pros and cons, ok?
(09:21:26) spot: thimm: go ahead.
(09:21:35) thimm: (pros for fc.6.89/6.90/...)
(09:21:52) f13: I think its really inconsistant to have a tree of packages that would be int eh FE7 tree that could be any of .fc6.89 .fc6.90 .fc6.91 .fc6.92 .fc7
(09:21:53) spot: fc6.89, you mean?
(09:22:29) f13: unless you plan on rebuilding _everything_ just for the sake of haing a .fc7 disttag, which to me is just silly
(09:22:46) spot: f13: we do mass rebuilds already, don't we? :)
(09:22:52) thimm: pros: mass rebuilds automated, can identify build (pre-test1, post-test1, post-test2, ...) from name, doesn't miss a rebuild, no rebuild changelogs, no evr changes for mass rebuilds
(09:22:55) f13: spot: of targetted things.
(09:22:58) thimm: spot: yes, a typo
(09:23:05) f13: spot: only compiled packages should be built right now, not python or other noarch packages.
(09:23:21) scop: thimm, some of those can also be seen as cons
(09:23:28) f13: thimm: 'no rebuild changelogs' is a con IMHO
(09:23:50) spot: let thimm finish with his pros and cons
(09:23:51) thimm: cons: rebuilds all %{?dist} - may be too much, can break <major>%{?dist}<minor> for minor>=89
(09:24:42) thimm: and cosider for both pros and cons: it's only about rawhide
(09:24:42) f13: con: inconsistant with Core dist tagging
(09:24:57) thimm: it's incositent with extras, too
(09:24:59) f13: thimm: its only about rawhide, but rawhide BECOMES the next release
(09:25:07) thimm: Every change is inconstent to the previous state
(09:25:22) thimm: rawhide -> release disttag become disttag release
(09:25:26) thimm: no traces left behind
(09:25:32) thimm: => only affects rawhide
(09:25:51) thimm: pro & con: enforces mass-rebuilds policies for golden releases
(09:25:54) spot: I'm not sure that the value of the subdist tags outweigh the additional pain they cause. Remember, dist tags are optional, so lots of things are still going to be confusing.
(09:25:55) f13: no, it effects the many packages that will be built during development and not built after rawhide is branched for that rleease.
(09:25:58) thimm: (I see that as a pro)
(09:26:48) thimm: Anyway, should we proceed to voting? Or does someone has something that is unclear to him?
(09:27:08) tibbs: I wonder if we shouldn't talk to FESCo and see if there's any need for this.
(09:27:25) thimm: Ask fesco after the mass rebuild is over ...
(09:27:32) tibbs: What's the point of allowing something like this if they have no intention of using it?
(09:27:55) thimm: OK, ask fesco in 30 minutes
(09:28:05) thimm: But can we decide on it to close the loop?
(09:28:18) spot: perhaps we should vote next week after hearing from FESCO?
(09:28:41) thimm: I thought it was an urgent matter
(09:28:44) abadger1999: I think I'd vote for it here and then possibly vote to veto at FESCo :-)
(09:28:47) f13: COre wont use it, and if Fesco won't use it, whats the point in voting?
(09:28:47) thimm: That's how it closed last week
(09:28:48) tibbs: This wouldn't be used until after FC7 branches, so we do have some time.
(09:28:57) thimm: That it need to be decide soon upon
(09:28:58) scop: abadger1999, exactly my words
(09:29:04) abadger1999: I like the logical consistency but have some practical worries.
(09:29:20) spot: is anyone opposed to voting now?
(09:29:22) cweyl [n=cweyl] entered the room.
(09:29:25) spot: that will take it to fesco. :)
(09:29:40) thimm: Vote on voting? ;)
(09:29:48) tibbs: No opposition from me.
(09:29:50) thimm: Should I formulate a proposal?
(09:30:05) spot: I hear no one opposed. Let's vote on the item of adding subdists for test releases in devel/ :
(09:30:32) tibbs: +1
(09:30:33) rdieter: +1
(09:30:33) abadger1999: +1
(09:30:38) spot: +1
(09:30:46) thimm: +1
(09:30:48) f13: -1
(09:30:55) scop: 0
(09:31:18) spot: well, i think thats everyone
(09:31:22) spot: so it does not pass
(09:31:56) spot: Next item: Cross compilation
(09:32:08) tibbs: This needs a proposal.
(09:32:08) spot: I think we can at least tackle the naming schema here
(09:32:24) tibbs: Ralf has packages submitted; let me dig up the bugzilla numbers.
(09:32:26) spot: I propose cross-* as a prefix for cross compilers and tools
(09:32:27) rdieter: (too bad Ralf isn't here)
(09:32:32) abadger1999: racor isn't around, though.
(09:32:39) scop: what do other distros do?
(09:32:48) tibbs: We've been passing on this for some time now.
(09:33:08) tibbs: Here's one cross-compiler submission: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176697
(09:33:12) tibbs: It does not use cross- as a prefix.
(09:33:12) spot: it makes sense, matches existing schema (compat-*), and helps distinguish between the normal tools and cross tools
(09:33:28) tibbs: There was also a big flame war over this on extras-list, I think.
(09:33:36) tibbs: At least, Ralf was flaming everyone.
(09:33:44) f13: heh
(09:33:47) spot: yes, well, he seems good at that of late.
(09:34:22) spot: I think that cross-$crossarch-$name seems sane
(09:34:50) rdieter: Ralf was simply stronly in favor of _his_ scheme of using _arch_-_platform_-_name_
(09:35:12) tibbs: I think having unprefixed cross-compilers is a bad idea.
(09:35:17) rdieter: Ralf had a point that you need more than just $crossarch$ in tehere somewhere.
(09:35:37) spot: perhaps cross-arch-platform-name ?
(09:35:48) tibbs: His submission is for "i386-rtems4.7-binutils"
(09:36:16) tibbs: I strongly favor prefixing that with "cross-".
(09:36:27) spot: that seems sane to me.
(09:36:31) abadger1999: I agree with Ralf's naming as far as it goes. I like having "cross-" in front of it, though.
(09:36:50) thimm: Is it fair to vote on this w/o ralf?
(09:37:04) spot: well, its not his proposal
(09:37:08) thimm: ok
(09:37:13) thimm: thought it was
(09:37:24) spot: nope, its tibbs's.
(09:37:30) abadger1999: Do we want to formalize the proposal and vote on it on the list?
(09:37:32) tibbs: I brought it up.
(09:37:38) abadger1999: So ralf can have a say?
(09:37:41) spot: I think we can vote on the list.
(09:37:54) spot: tibbs: will you formalize it and ask for a vote?
(09:38:00) tibbs: Fine by me. But we have more to discuss thatn just naming.
(09:38:10) spot: I know. make it clear that we're just doing naming now
(09:38:20) tibbs: OK.
(09:38:35) spot: Next item: jpackage naming
(09:38:38) scop: by the way, regarding the previous vote
(09:38:46) spot: scop: yes?
(09:38:59) scop: do we want to give folks who aren't here today a chance to vote too?
(09:39:18) scop: we had 5* +1, 1 * 0, 1 * -1
(09:39:22) rdieter: snooze ya looze...?
(09:39:23) spot: scop: erm, my concern is that this will slow down the process
(09:39:46) spot: i think old issues can be brought up again for a new vote
(09:39:55) thimm: I'd rather not
(09:39:55) f13: spot: do we have a limit on that?
(09:40:03) f13: I don't want to revote on the same thing week after week.
(09:40:07) scop: my concern is that we don't have enough attendance on meetings
(09:40:21) spot: scop: perhaps that will motivate attendance? :)
(09:40:23) f13: scop: then kick out the folks that aren't showing up and get responsible people in.
(09:40:55) f13: spot: I'm still not getting _any_ feedback from the java folks. REfusal to speak to me because they're too busy.
(09:40:56) tibbs: We should consider that only after coming up with a new meeting time.
(09:41:10) f13: spot: they did recently change their naming to replace _ with .
(09:41:24) f13: so foobar-6.3-4jpp.5.fc6
(09:41:32) tibbs: Joy, more crap.
(09:41:40) f13: while still not quite what we'd like, its slightly better than the underscore crap
(09:41:43) rdieter: f13: maybe formally block all jpp updates until *this* is resolved, will get them talking. :)
(09:41:50) spot: I think we're all in agreement that we're not willing to change the guidelines for this
(09:41:59) spot: Does anyone disagree with that?
(09:42:07) f13: spot: correct. No new jpackage package should be approved w/out following our naming guidelines
(09:42:07) abadger1999: Not willing to change the guidelines to what they have now.
(09:42:16) tibbs: Certainly this stuff can't be allowed into Extras.
(09:42:20) tibbs: At least there's a review process for that.
(09:42:27) f13: tibbs: there is for new Core packages.
(09:42:36) f13: I won't be approving any new core package until they address this issue
(09:42:40) tibbs: True; I keep forgetting.
(09:42:45) abadger1999: I'd be willing to change the guidelines to some of the other proposals.
(09:43:15) f13: abadger1999: my proposal that they've yet to get back to me on requires no changes to our guidelines (:
(09:43:22) spot: the only proposal i have seen is from f13 which requires no changes.
(09:43:28) tibbs: But we could include an example.
(09:43:36) spot: so I don't think this needs to be an action item for us.
(09:43:49) rdieter: do we need to hire some packaging thugs, er, police to enforce our bidding?
(09:43:57) spot: Unless we want to address the core packages which are currently out of compliance?
(09:44:24) abadger1999: spot: There's a wiki page. Doesn't look like it ever got lnked to the schedule...
(09:44:37) abadger1999: http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming
(09:44:39) thimm: scop: Aren't you part of jpackage? Can you act as an man-in-the-middle?
(09:45:03) abadger1999: Has 4 proposals including f13's.
(09:45:40) f13: abadger1999: I don't think any of the others are seriously considered
(09:45:56) tibbs: So which one is the recommended one?
(09:46:12) tibbs: The first?
(09:46:39) spot: I think so.
(09:46:49) spot: its the one that does not require a guidelines change.
(09:46:57) scop: thimm, yep, I'm a jpackage member, but currently kind of hibernating
(09:46:58) f13: my proposal is the recommended one.
(09:46:59) abadger1999: tibbs: The last.
(09:47:20) tibbs: abadger1999: The last is "treat the jpackage version like a postrelease"
(09:47:30) abadger1999: Leave JPackage Information Out of the Name
(09:47:40) f13: mine is hte first
(09:47:43) f13: leave jpp out of the name
(09:47:44) tibbs: The recommended one seems to be "removal of jpp from release".
(09:48:03) spot: I think the difference is adding the Provides: jpackage(%name)
(09:48:05) abadger1999: Oops. Sorry. f13's right.
(09:48:08) tibbs: Can we at least include that as an example in the naming guidelines so there is no question as to what Java packages should look like?
(09:48:33) spot: tibbs: seems reasonable.
(09:48:40) rdieter: tibbs++
(09:48:56) tibbs: BTW, everyone's conveniently ignoring the fact that we don't seem to have Java packaging guidelines.
(09:49:09) spot: that is a point.
(09:49:20) tibbs: I know the jpackage guidelines seem to hold sway, but extras reviewers don't seem to have a way to know that.
(09:49:40) spot: Perhaps we should take the jpackage guidelines (excepting the jpp part) and adopt them?
(09:49:48) f13: I haven't looked at them at all
(09:49:58) spot: f13: can you look into that?
(09:49:59) scop: jpackage stuff needs work
(09:50:54) spot: ok, i've got to cut out a bit early (hooray for sales meetings)
(09:51:03) spot: are there any minor issues people want to bring up?
(09:51:04) thimm: discuss on new meeting time?
(09:51:04) tibbs: I've done several Java reviews, and have just used what's in http://fedoraproject.org/wiki/NativeJava as guidelines.
(09:51:06) scop: for example, multilib stuff is not addressed at all
(09:51:31) thimm: new meeting time?
(09:51:36) f13: question, are kernel module packagea pprovals on hold still?
(09:51:36) tibbs: Java seems to handle multilib pretty well as is.
(09:51:44) scop: in case everyone's not aware of it, a *lot* of conditional native build stuff is being fed upstream to jpackage nowadays
(09:51:48) spot: f13: that's a Q for the board
(09:51:57) abadger1999: racor doesn't like the one hour later timeslot.
(09:51:59) f13: spot: I was hoping one of you would know (:
(09:52:05) ***spot is not on the board
(09:52:34) f13: tibbs: not really. They just had to repackage a lot of stuff to move .so's out of the main package and into the -devel package so multilib would work right.
(09:52:41) scop: tibbs, jpackage's guidelines won't work if one wants to install i386 and x86_64 java on a x86_64 box
(09:52:46) rdieter: I think I can say with almost 100% certainly the Board is ok with kernel modules, and won't ban them.
(09:52:47) f13: abadger1999: I don't particuarly like the current time slot (:
(09:53:01) thimm: can we stay on one topic???
(09:53:17) thimm: it's java vs kernel modules vs new meeting time ... :/
(09:53:27) rdieter: battle royale!
(09:53:29) spot: ok, java is tabled. kernel modules are off topic.
(09:53:35) spot: new meeting time wins.
(09:53:50) spot: 1700 UTC conflicts with the FESCO meeting
(09:53:56) spot: i think thats a showstopper
(09:53:56) tibbs: Has everyone blocked in their times, or blocked out their unavailable times?
(09:54:01) abadger1999: (On this day.)
(09:54:12) tibbs: spot: Only if it's on Thursday.
(09:54:13) spot: abadger1999: ahh, ok, point
(09:54:22) spot: it also conflicts with ralf's dinner.
(09:54:26) rdieter: tibbs: I've done a wee bit. I'll go do more later today.
(09:54:26) thimm: I think we should block out Sat and Sun
(09:54:34) spot: yeah, Sat/Sun are right out for me.
(09:54:38) spot: my wife will KILL me.
(09:54:40) tibbs: thimm: +1. And probably friday as well.
(09:54:50) scop: tibbs++
(09:55:04) tibbs: I know I take many Fridays off.
(09:55:06) thimm: OK, looks like Tue or Wed
(09:55:23) thimm: Most entries are for Tue 17:00UTC
(09:55:24) tibbs: abadger1999: Where is that schedule page again?
(09:55:36) spot: Tue 1700 UTC works for me
(09:55:38) abadger1999: http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime
(09:56:01) thimm: blitz vote on Tue 1700 UTC?
(09:56:04) thimm: +1
(09:56:06) spot: +1
(09:56:08) f13: it blocks ralf's dinner time, but frankly, ralf hasn't been coming to a lot of these meetings.
(09:56:08) scop: anything Tue 1600-1900 would work for me
(09:56:11) f13: +1
(09:56:19) rdieter: +1
(09:56:36) scop: +1
(09:56:36) tibbs: f13: Ralf hasn't been coming because the time slot is not good for him.
(09:56:40) tibbs: That's the whole point of changing it.
(09:56:45) abadger1999: f13: He did inform us that he would have conflicts for a few weeks, though.
(09:56:47) f13: as a side topic, what do we do for Daylight Savings time?
(09:56:54) f13: abadger1999: true.
(09:56:55) ***spot has to go... sorry guys
(09:56:56) tibbs: +1 1700UTC is good for me.
(09:57:01) f13: tibbs: the current timeslot or the new timeslot?
(09:57:14) scop: f13, DST is covered in Wiki
(09:57:34) rdieter: did ralf post any good/bad times on the wiki (I don't think he did, not yet anyway)
(09:57:44) tibbs: f13: I think either timeslot is bad for him, but the current one prefents him from meeting.
(09:57:53) rdieter: oh, just a quick fyi folks (if you hadn't seen it yet), I just announced http://fedoraproject.org/wiki/RexDieter/openmotif
(09:57:54) thimm: OK, looks lika all 7 present members are for Tue 17:00 UTC (modulo DST)
(09:58:00) tibbs: The problem is that he hasn't included information on which slot is better, so all we can do is guess.
(09:58:12) thimm: Let's ask the other three on list, ok?
(09:58:21) rdieter: ok++
(09:59:00) tibbs: Adjourned?
(09:59:02) abadger1999: I'll update the wiki page with the times people added here.
(09:59:21) rdieter: ->FESCo
(09:59:28) scop: ditto
(09:59:37) abadger1999: (added|subtracted)
(10:01:23) thimm: Sent the mail
(10:02:32) thimm: rdieter: openmotif, maybe simply set needs.rebuild on these packages?
(10:02:52) thimm: (after removing openmotif from devel)
(10:03:02) rdieter: wouldn't hurt. (: I'll ask the FESCo folks about that.
(10:03:42) thimm: Maybe it should be a general guideline
(10:04:03) thimm: If a BR vanished for whatever reason the depending packages are "needs.rebuild"ed
(10:04:13) thimm: And if no action happens they get orphaned
(10:04:45) thimm: OK, good bye folks