Packaging:Minutes20070327

Fedora Packaging Committee Meeting of {2007.03.27}

Present

The entire committee was present:

• AxelThimm (normally thimm)
• DavidLutterkort (lutter)
• JasonTibbitts (tibbs)
• JesseKeating (f13)
• RalfCorsepius (racor)
• RexDieter (rdieter)
• TomCallaway (spot)
• ToshioKuratomi (abadger1999)
• VilleSkyttä (scop)

Writeups

The following draft has been accepted by FESCO and is to be written into the guidelines:

• Guidelines for using cmake: PackagingDrafts/cmake

Votes

The following proposals were considered:

• Modifications to the Naming Guidelines for handling non-numeric post-releases PackagingDrafts/PostRelease
• Accepted (6 - 0).
• Voting for: f13 tibbs spot rdieter scop abadger1999
• Voting against: (none)

• Additional dist-related macros: PackagingDrafts/ExtraDistTagConditionalMacros
• Accepted (7 - 0).
• Voting for: f13 spot rdieter tibbs thimm lutter abadger1999
• Voting against: (none)

• Mandating that filenames in RPMs be utf8: PackagingDrafts/Utf8Filenames
• Accepted (7 - 0).
• Voting for: f13 spot lutter abadger1999 rdieter tibbs thimm
• Voting against: (none)

Other Discussions

The following additional items were discussed; see the logs for full details.

• Reviewing the guidelines to make sure that they are valid for EPEL. (For example, we need to make sure that none of the guidelines require RPM functionality that is not present in RHEL4.) EPEL should ping FPC when any issues of this nature come up.

• Making sure that rpmlint acquires checks for new guidelines when possible.

• Getting brp-python-bytecompile to perhaps hardlink *.pyc and *.pyo filee together when they do not differ; scop found this would save 9MB on his system.

IRC Logs

[11:58]  * spot is here
[11:58]  <tibbs> I'm here.
[11:58]  * sereinity too
[11:59]  <abadger1999> I'm here
[12:01]  * mmcgrath not here
[12:02]  <rdieter> here
[12:02]  <abadger1999> f13, lutter, racor: ping
[12:02]  <spot> so, we're missing lutter, f13, racor, thimm, scop
[12:03]  --> scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[12:03]  <spot> scop: welcome!
[12:03]  <lutter> spot: I am on the phone, should be done in 10-15 mins
[12:03]  <racor> sorry, i've been distracted ... but due to DST shift am very short on time and will probably have to leave early
[12:04]  <tibbs> Odd, I though the meeting time for Europeans did not change.
[12:04]  <racor> it did last weekend
[12:05]  <abadger1999> k.  We should get started then.
[12:05]  <spot> item 1
[12:06]  <spot> cmake draft was ratified by FESCO
[12:06]  <spot> item 2
[12:06]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
[12:06]  <spot> Post Release Package guidelines
[12:07]  <tibbs> I made some comments on-list.
[12:08]  <scop> this is essentially what it was in the original fedora.us guidelines, and it was met with strong opposition when it got transferred to FE
[12:08]  <tibbs> Which part resulted in strong opposition?
[12:08]  <racor> I am missing %{?dist}
[12:08]  <spot> racor: dist goes on the end
[12:09]  <scop> tibbs, moving the non-numeric part to the release tag
[12:09]  <tibbs> I see no need to specifically mention dist in every section of the guidelines separatelyl.
[12:09]  <racor> then this postrelease won't work
[12:09]  <spot> racor: why not?
[12:09]  <tibbs> I fail to see now it won't work.
[12:09]  <tibbs> It works fine for prereleases where we use the same scheme.
[12:09]  <racor> 1.1.1-1.fc6
[12:10]  <rdieter> spot: looks good to me, I'm all for it.
[12:10]  <racor> post release of release
[12:10]  <racor> post-release or release?
[12:10]  <tibbs> scop: If we can't do that, then we can't use upstream versioning at all if it doesn't sort properly.
[12:10]  <rdieter> 1.1.1-2.GA1.fc6
[12:10]  <spot> 2 > 1
[12:10]  <tibbs> 1.1.1-2.GA1.fc6.1
[12:10]  <scop> tibbs, yes we can, we just bump the epoch in the extremely rare cases where there is a problem
[12:11]  <tibbs> The problem is that there are packages where this isn't an extremely rare case.
[12:11]  <scop> care to mention one by name?
[12:11]  <tibbs> You'd get an epoch bump rather often for those.
[12:11]  <tibbs> Fnasser mentioned at least one on-lis5t.
[12:12]  <tibbs> That was the reason this came up at all.
[12:12]  <spot> i'm not sure we can craft a generic solution to that other than "use epoch"
[12:12]  <rdieter> tibbs: imo, in cases where it's not rare, upstream needs some whacking.
[12:13]  <spot> i'd rather pound on upstream if it becomes a problem
[12:13]  <tibbs> Well, yes, but we know that there are cases where upstream does things on purpose just to screw with us.
[12:13]  <abadger1999> tibbs: Unfortunately true :-(
[12:13]  <f13> eep, I'm here.
[12:13]  <rdieter> exceptions can be dealt with.
[12:14]  <tibbs> If epoch is the answer, then great, we just need to at least mention it somewhere.
[12:14]  <spot> i'd like to get these ground rules in, we can add extra bits later as needed
[12:14]  <tibbs> spot: I think the issue is that scop objects to basically everything you're adding in your draft.
[12:15]  <spot> scop: do you?
[12:15]  <spot> alli saw was that he said it was the same as the old fedora.us guidelines and some people opposed it
[12:15]  <rdieter> and I didn't think "some people" = "scop". :)
[12:16]  <tibbs> So where is the "strong opposition"?
[12:16]  <scop> and I have no desire to be a part of re-igniting those flamewars
[12:16]  <spot> well, we're simply adding another option to the existing guidelines
[12:16]  <spot> we're not mandating that it be used.
[12:16]  <scop> ok, I missed that bit
[12:16]  <tibbs> This is a rule to cover the case of non-sorting upstream versioning.  It seems to me to be a sane enough way of dealing with non-sane upstreams.
[12:17]  <scop> if it's not a must, I won't object
[12:17]  <spot> but if you want the post-release tag in the n-v-r, these are the two ways to do it.
[12:17]  <spot> you don't have to have it at all.
[12:17]  <tibbs> spot: Perhaps add a note that you can use this, or just bump Epoch: when necessary.
[12:17]  <spot> i can add a one-liner for epoch.
[12:18]  <tibbs> I think the point is that there really aren't any other options.
[12:18]  <spot> tibbs: sure there is, don't put the post-release tag in the n-v-r. :)
[12:18]  <spot> can we vote on the draft + epoch line?
[12:18]  <abadger1999> I'd like to see a little tweaking of the wording: "More complicated versions" but I'm okay with the draft otherwise.
[12:18]  <tibbs> If that's a real option then it needs to be listed out as well, I think.
[12:19]  <spot> abadger1999: suggested alternative?
[12:19]  <tibbs> I wasn't aware that it was permitted to deviate from upstream versioning in that manner.
[12:19]  <spot> tibbs: we never said it wasn't.
[12:19]  <abadger1999> Something like: "When upstream tries to use versions that include abbreviations we can run into ordering problems"
[12:20]  <f13> spot: can we chnage ALPHATAG to POSTTAG ?
[12:20]  <scop> versioned self-obsoletes would be another alternative way to handle this, alas IIRC that doesn't work nowadays so it doesn't make sense to promote it
[12:20]  <f13> nit-picky but might save confusion.
[12:20]  <tibbs> So now I'm confused; are packagers under no obligation to follow upstream versioning?
[12:20]  <rdieter> tibbs: you should when you can (and it is sane).
[12:21]  <abadger1999> My wording wasn't that great either, but the essence is to answer the question "How does a novice packager tell when upstream is smoking the crack pipe?"
[12:21]  <rdieter> use of >1 non-numeric in version = crack-pipe
[12:22]  <tibbs> Use of anything besides real numbers = crack pipe.
[12:22]  <spot> ok, i just amended the draft. alphatag is now posttag, changed to abadger's wording, added two lines on epoch.
[12:22]  <tibbs> Hmmm.
[12:22]  * f13 refreshes
[12:23]  <spot> slow wiki, might not have gotten it yet, my browser is still waiting
[12:23]  <tibbs> I see it.
[12:23]  <abadger1999> rdieter: +1
[12:24]  <rdieter> got it, looks good to me.
[12:24]  <f13> I see it.
[12:24]  <f13> looks reasonable to me.
[12:24]  <scop> I would trim the prereleases from the example
[12:24]  <spot> scop: the only reason i left it in there was to make it clear how the whole process works
[12:24]  <spot> in my estimate, if they do post, they do pre too.
[12:24]  <abadger1999> I don't think my wording works quite right either.  For instance 1.0beta 1.0rc 1.0final
[12:25]  <abadger1999> Oops.  That's pre-release, not post release.
[12:25]  <spot> abadger1999: maybe "When upstream uses versions that either have or are likely to have ordering problems"
[12:26]  <abadger1999> "When upstream uses versions that attempt to have meaning to humans instead of being easy for a computer to order"
[12:26]  <spot> ooh, i like that
[12:27]  <abadger1999> "For instance, GA1, CR2, PR3"
[12:27]  <f13> I like that too
[12:27]  <f13> counting starts at 0 damnit!  (:
[12:27]  * rdieter liked "When upstream smokes crack-pipe" better, but oh well? :)
[12:27]  * spot commits that change
[12:27]  <spot> ok guys, lets vote on this draft.
[12:28]  <f13> +1
[12:28]  <tibbs> +1
[12:28]  <spot> +1
[12:28]  <rdieter> +1
[12:28]  <scop> +1
[12:28]  <abadger1999> +1
[12:29]  * spot isn't sure if racor is still here or not
[12:29]  <spot> but the vote passes
[12:29]  <scop> "For instance, GA1, CR2, PR3" -- CR2 and PR3 look like prereleases, not postreleases?
[12:29]  <spot> next item:
[12:29]  <spot> scop: believe it or not, they're post.
[12:29]  <spot> hooray for java crack.
[12:29]  <scop> ooh
[12:29]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros
[12:30]  <spot> Dag pointed this out on epel-list
[12:30]  <tibbs> I like these but I'm concerned that the syntax is even less pleasant than the %if bits.
[12:30]  <lutter> ok .. off the phone
[12:30]  <rdieter> I like it.
[12:30]  <tibbs> And there seems to be a general dislike of more RPM macros from some quarters.
[12:30]  <lutter> me too
[12:30]  <spot> tibbs: it seems pretty clean to me.
[12:31]  <rdieter> tiibs: then "those quarters" shouldn't use them.
[12:31]  * spot points out that all of these macros are optional
[12:31]  <lutter> tibbs: and we use %{?macro: ...} in quite a few otehr places
[12:31]  <spot> they're there if you want/need em
[12:31]  <tibbs> Does it work for multiline bits?
[12:31]  <scop> those macros are not available to people who rpmbuild --rebuild locally
[12:32]  <scop> if the packager has chosen to use those "optional" macros, the build will most likely be screwed
[12:32]  <rdieter> scop: mock, mock, baby.
[12:32]  <tibbs> I.e. can the "a", "b", etc. in the examples be multiline?
[12:32]  <spot> tibbs: i think so, but i'm not 100% sure there
[12:32]  <f13> scop: likewise if they depend on the existing %{fedora} or %{rhel} macros
[12:32]  <spot> they could always do:
[12:32]  <spot> %if "%el5"
[12:32]  <f13> or rely on something in %{?dist}
[12:33]  <spot> instead of %if "%rhel" == "5"
[12:33]  <scop> f13 yes, which is why I think it's a bad idea to use any of those macros
[12:33]  <f13> I don't think it's bad, I think they should be used with care.
[12:33]  <racor> spot: consider me gone, I can't follow today's meeting in reasonalbe manners. This time-slot isn't working for me :(
[12:33]  <rdieter> speaking of "local" builds (like scop's comment), why not put buildsys-macros in the main repo?
[12:33]  <f13> I really think we should start shipping buildsys-macros in say fedora-release though
[12:34]  <spot> racor: sorry. :(
[12:34]  <f13> so that these things WILL get resolved locally and they can override if need be (or use mock)
[12:34]  <spot> rdieter: +1
[12:34]  <rdieter> f13: :)
[12:34]  <f13> I know jeremy has had concerns with this possibly "surprising" people, but really I think they'd be more surprised if these macros /didn't/ resolve.
[12:35]  <spot> no macros are changing. we're just adding some new ones.
[12:35]  <spot> and we'll announce the change.
[12:35]  <scop> include the macros in redhat-rpm-config instead
[12:35]  <tibbs> So do we have buy-in from the maintainer of whatever package will contain these?  And what releases will be covered?
[12:35]  <spot> tibbs: fedora and rhel
[12:35]  <f13> who owns buildsys-macros?
[12:36]  <rdieter> I'd rather these continue to be packaged separately, but they get Require:'d by fedora-release or redhat-rpm-config.
[12:36]  <rdieter> I don't think anyone officially owns it (yet), who owns mock?
[12:36]  <-- giallu has left this server (Read error: 110 (Connection timed out)).
[12:36]  <spot> f13: dgregor
[12:36]  <tibbs> spot: The examples cover el2, though; surely we can't get updates going that far back.
[12:37]  <f13> spot: he owns that in Extras?  weird.
[12:37]  <spot> f13: oh, extras?
[12:37]  <f13> yeah
[12:37]  <scop> sure, pulling them in through a dependency in redhat-rpm-config would work as well
[12:37]  <spot> f13: i dont think its in FE
[12:38]  <spot> tibbs: the DistTag document mentions .el2
[12:38]  <f13> spot: how is it populating the Extras buildroots with these macros?
[12:38]  <lutter> afaik, they are just floating around out there, like on buildsys.fp.org
[12:38]  <rdieter> perhaps someone on FPC could/should own it?
[12:38]  <f13> interesting.
[12:38]  <f13> I can own them.
[12:38]  <f13> I own them internally or at least make the changes to them.
[12:38]  <spot> yeah, i think you should own them. :)
[12:38]  --> thimm has joined this channel (n=thimm@p54BD5D7C.dip.t-dialin.net).
[12:38]  <tibbs> spot: I'm not sure how that's relevant, though.  The example will never actually work, will it?
[12:39]  <spot> tibbs: not for any case we care about
[12:39]  * thimm is sorry, I couldn't make it in time :/
[12:39]  <spot> tibbs: but for dag, he might be using them somewhere else.
[12:39]  <spot> and there is really no reason EPEL couldn't support RHEL 2.1 someday
[12:39]  <spot> if they were feeling horribly masochistic.
[12:39]  <lutter> for general sanity, would probably be good if buildsys-macros was in fc proper
[12:40]  <f13> yeah, I want to run the idea again of having it available in the repo
[12:40]  <spot> f13: you look into owning it and making it get pulled in by redhat-rpm-config ?
[12:41]  <f13> yeah
[12:41]  <spot> ok. lets vote on the draft, with the knowledge that we're working on the buildsys-macros package issue
[12:41]  <f13> +1
[12:41]  <spot> +1
[12:41]  <thimm> URL?
[12:41]  <rdieter> +1
[12:41]  <scop> http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros
[12:42]  <tibbs> +1 although I do object to including an example that we don't intend to make work.
[12:42]  <thimm> Thanks, +1
[12:42]  <thimm> tibbs: which example?
[12:42]  <spot> thimm: el2
[12:42]  <f13> why wouldn't we make it work within EPEL?
[12:42]  <lutter> +1
[12:43]  <f13> we can populate the buildroots with whatever we want
[12:43]  <spot> abadger1999: would you like to vote? :)
[12:43]  <f13> %{?dist} tag was functional in Extras long before I enabled it in Core / RHEL
[12:43]  <tibbs> We actually have an el2 buildroot?
[12:43]  <thimm> Suggestion: Please add a comment that we actually discourage using these if features are being probed
[12:43]  <abadger1999> +1 if we get the macros into the distro.
[12:44]  <spot> thimm: seems reasonable.
[12:44]  <rdieter> thimm: define "feature probing"?
[12:44]  <thimm> Otherwise people would not prope for say selinux
[12:44]  <thimm> probe
[12:44]  <f13> tibbs: we don't as there isn't any demand.  Should there be demand, we just might do el2 buildroots.
[12:45]  <thimm> f13: demand for RHEL3 is already 1/20th of RHEL4
[12:45]  <thimm> So for RHEL2.1 it will be even smaller I guess
[12:45]  <spot> ok, the draft passes
[12:45]  <rdieter> point is, *we* shouldn't rule it out as a possibility.
[12:45]  <thimm> no, but we don't, do we?
[12:45]  <spot> next item: ruby gems
[12:46]  <spot> lutter: do you have anything new this week?
[12:46]  <lutter> spot: no, sorrry, didn't haevb time last week to look into the rubygems stuff we discussed
[12:46]  <spot> ok. we'll put that aside.
[12:46]  <lutter> hopefully next week
[12:46]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:47]  <spot> scop: is this ready to be looked at?
[12:47]  <scop> no
[12:47]  <spot> ok. we'll move on.
[12:47]  <scop> there's a "---" in the middle of the doc, stuff after that was added by Enrico
[12:47]  <tibbs> Should we talk about the fact that we're now to make policy for EPEL as well?
[12:48]  <scop> I haven't dug into it, but I have a feeling I don't personally agree with it
[12:48]  <spot> tibbs: i mentioned that last week
[12:48]  <spot> i'm pretty sure i did.
[12:48]  <thimm> spot: you did
[12:48]  <tibbs> Perhaps, but I don't recall discussing any changes we will have to make because of it.
[12:48]  <tibbs> For example, are all of our current guidelines appropriate for EPEL?
[12:48]  <thimm> We'll have to find out on the way I guess
[12:49]  <tibbs> Do we need to make a review of them?
[12:49]  <spot> no one has said that they aren't.
[12:49]  <thimm> I think the idea is to have EPEL ping us when something is wrong for EPEL
[12:49]  <f13> I'm sure many of our package specific macros don't work with RHEL4's rpm
[12:49]  <thimm> I'll package a helper package for that
[12:49]  <f13> and things like kmods may not work well at all.
[12:49]  * thl wonders if we need the explicit "python(abi)" stuff abck for EPEL < 5
[12:49]  <spot> f13: now now, no need to curse.
[12:50]  <f13> thimm: some of it is the rpm version itself, not just missing macros.
[12:50]  <f13> thimm: certain conditionals are not usable by RHEL4's rpm
[12:50]  <thimm> f13: which ones?
[12:50]  <rdieter> thl: yes, explicit python(abi) is/would-be required for epel < 5.
[12:50]  <f13> I can't remember which, I just noticed it came up a month or so back internally
[12:50]  <scop> %bcond_*
[12:50]  <thimm> That's a macro, f13 means something else
[12:51]  <thimm> f13: Could you dig it up and PM me? Thanks!
[12:51]  <scop> well, that's a conditional too, and not usable by RHEL4's rpmbuild :)
[12:51]  <f13> thimm: that may have been it.
[12:51]  <spot> ok, so there are a few items on the todo list that need some work
[12:51]  <thimm> scop: I will create a "fedora-compatibility-rpm-macro-package" for EPEL :)
[12:51]  <thl> rdieter, then I'd say we should add it back somewhere somehow; even I forgot how it works exactly...
[12:52]  <rdieter> thl: I think the python page still references it (somewhere).
[12:52]  <spot> specifically, i'm looking at arch specific script packages, user/group handling, cross compilations, license tags
[12:52]  <spot> if you own one of these (f13, rdieter, tibbs, scop)
[12:52]  <spot> well, not rdieter. sorry. ;)
[12:53]  * rdieter though he was getting drafted there for a minute.
[12:53]  <tibbs> I shouldn't be on cross-compilation any longer.
[12:53]  <spot> please either clean it up for consideration or pull it off the todo list
[12:53]  <tibbs> spot: I know you have something else going on with regards to licenses.
[12:53]  <spot> yeah, feel free to drop that item entirely for now
[12:54]  <rdieter> I'll pull the iconcache proposal from ToDo, since it is indefinitely tabled (someday maybe)
[12:54]  <thimm> Why?
[12:54]  <thimm> Weren't we about to approve it?
[12:54]  <scop> I'll try to beat UsersAndGroups into a discussion draft shape for next week's meeting
[12:54]  <spot> scop: you may want to run it past notting via email
[12:54]  <rdieter> thimm: talking to me?
[12:54]  <tibbs> spot: If you want to work on licenses, I'm game, but I'd like to know what you have planned at some point.
[12:55]  <spot> scop: he had a lot of thoughts on that
[12:55]  <scop> spot, ok, will do
[12:55]  <thimm> rdieter: yes, about iconchache
[12:55]  <spot> tibbs: no problem.
[12:55]  <f13> spot: hrm, I still have no good solution for the arch specific noarch script stuff.  :/
[12:55]  <scop> (and now, after having a look at stuff people have added to the current draft, a lot of those make perfect sense)
[12:55]  <f13> I think it requires changes to rpm, and well...
[12:56]  <abadger1999> If we're out of items to discuss, we could look at this: http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames
[12:56]  <rdieter> thimm: well, icon_cache is still a volatile subject to some, maybe giving it some time can garner a little more consensus.
[12:57]  <thimm> rdieter: Is anyone of the FPC volatile?
[12:57]  <thimm> I thought that "only" some package maintainers were against it
[12:57]  <rdieter> thimm:   f13 (by proxy) :)
[12:57]  <scop> utf8filenames: what's "convmv"? ASCII is UTF-8 compatible, so plain "Filenames must be encoded as utf8" suffices
[12:58]  <thimm> rdieter: But the proxy only promised to fix that in the far future
[12:58]  <tibbs> It's more of an issue that we can't use packaging guidelines to force Gnome to do anything.
[12:58]  <spot> utf8filenames seems ok to me.
[12:58]  <tibbs> I agree with utf8filenames.
[12:58]  <f13> I just continue to get pushback on enforcing any packaging guideline if we don't take their concerns into consideration and just force things down their throat. :/
[12:58]  <f13> +1 to utf8
[12:59]  <spot> +1 to utf8
[12:59]  <rdieter> tibbs: it's more of gnome forcing everyone else to use gtk-update-icon-cache. :)  But we've been down that road...
[12:59]  <lutter> +1 for utf8
[12:59]  <abadger1999> +1 utf8
[12:59]  <rdieter> +1 utf8.
[12:59]  <tibbs> +1 utf8.
[12:59]  <abadger1999> scop: convmv is a program that can rename files from one encoding to another.
[13:00]  <scop> needs a BuildRequires?
[13:00]  <tibbs> What package is it in?
[13:00]  <rdieter> f13 has a point about pushback, I'm willing to let the topic/issue simmer for awhile.
[13:00]  *** thl is now known as thl_afk.
[13:00]  <tibbs> Ah, the convmv package.
[13:01]  <tibbs> Does rpmlint complain about non-utf8 filenames?
[13:01]  <f13> if it, we can make it do so easily
[13:01]  <f13> and if we pass this we should.
[13:01]  <scop> s/use convmv in your %install/can use for example convmv in your %install/
[13:01]  <f13> actually, that brings up a good point.
[13:01]  <f13> one step in adding any new rule should be "can rpmlint check for this" and helping to create an rpmlint check if possible.
[13:01]  <spot> yes, rpmlint seems to.
[13:02]  <tibbs> What about the contrapositive?  "If it's not in the guidelines, rpmlint shouldn't complain about it."
[13:02]  <spot>                         if use_utf8 and not is_utf8(path):
[13:02]  <spot>                             printWarning(pkg, 'file-not-utf8', f)
[13:02]  <thimm> utf8-voting: -1
[13:02]  <thimm> Sorry
[13:02]  <scop> spot, that's for file contents
[13:02]  <thimm> +1
[13:02]  <spot> scop: ah, ok.
[13:02]  <scop> but bleeding edge svn rpmlint checks file names too: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1327
[13:02]  <f13> tibbs: erm... I'm not exactly comfortable with that.
[13:03]  <abadger1999> scop: Changed to " If upstream ships filenames that are not encoded in utf8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
[13:03]  <abadger1999> "
[13:03]  <tibbs> f13: Perhaps not, but it's an interesting question.  "mixed spaces and tabs", is a good example.
[13:03]  <scop> abadger1999, better, +1
[13:04]  <spot> ok, utf8 passes
[13:04]  <scop> abadger1999, or just "mv", eg. mv Skytt? Skyttä
[13:04]  <tibbs> Need EPEL branches and maintainer for convmv, I guess.
[13:04]  <f13> tibbs: sure.  I'm fine with objecting to specific rpmlint tests and adding it to a fedora specific filter.
[13:05]  <thimm> scop: Seems nice and KISS
[13:05]  <thimm> But rpmlint will probably thing specfile is non-utf8 ;)
[13:05]  <scop> no, the "?" is a literal question mark
[13:06]  <thimm> ah, OK :)
[13:06]  <spot> ok guys, any other issues? or are we done?
[13:06]  * spot has lots and lots to do today, so... ;)
[13:06]  <rdieter> done: +1
[13:07]  <spot> thanks all.
[13:07]  <thimm> spot working +1
[13:07]  <thimm> ;)
[13:07]  <thimm> bye all
[13:07]  <tibbs> I'll write up the minutes.
[13:07]  <abadger1999> Thanks tibbs
[13:07]  <tibbs> If anyone has any comments on the format, please let me know.
[13:07]  <abadger1999> scop: Hmm... I wonder how that works with multibyte characters.
[13:08]  <scop> nothing urgent, but food for thought: I came across PLD hardlinking *.pyc and *.pyo in binary packages whenever they're identical, and they are in a lot of cases
[13:08]  <scop> abadger1999, use * then :)
[13:08]  <f13> scop: I wonder how much space that saves
[13:09]  <abadger1999> scop: :-)
[13:09]  <scop> f13, not much in *.rpm sizes (surprisingly?) but of course some when installed
[13:09]  <tibbs> Something could run through and do that automatically for any identical files in a package.
[13:09]  <scop> yes, OTOH taking possible filesystem boundaries into account
[13:10]  <tibbs> Unfortunately that would restrict it to files in the same directory.  Or rpm needs to be able to break those links at install time.
[13:10]  <scop> yep
[13:10]  <scop> but in the *.pyc, *.pyo case, they are in the same dir
[13:10]  <scop> $ /usr/sbin/hardlink -nvc /usr/lib64/python2.4 2>&1 | tail -n 1
[13:10]  <scop> Would save 9859072
[13:11]  <tibbs> Unfortunately don't forget that rpmbuild compiles the files itself.  We have no hook to get in after that process, so rpmbuild would have to do the hardlinking itself.
[13:12]  <scop> yes, that could be done in the very same hook that compiles the files
[13:12]  <scop> (and should be done there, if it's seen something worth adopting in the first place)
[13:13]  <tibbs> Anything to save space, sure.
[13:14]  <tibbs> But I guess it's a discussion for the rpm maintainer.  (Or is that the python maintainer?)
[13:14]  <tibbs> brp-python-bytecompile is in rpm-build.
[13:15]  <spot> scop: draft it? :)
[13:17]  <scop> I'll post to fedora-devel sometime for discussion first
[13:18]  <scop> anyway I found it somewhat odd that it didn't save practically any space in *.rpm files
[13:18]  <scop> perhaps rpmbuild already does something like hardlinking internally when it composes the payload
[13:19]  <tibbs> Or the regular compression is taking care of it.
[13:21]  <-- thimm has left this channel.
[13:22]  <f13> would we lose out any functionality by making them hardlinks?
[13:22]  <f13> we _do_ care a lot about the size of the stuff once installed, for things like LiveCD and OLPC
[13:22]  <tibbs> I can't imagine how it could make any difference.  The system will just break the link if for some reason one of them gets modified.
[13:29]  <f13> tibbs: just covering the bases.