Meeting:Packaging IRC log 20060810

(08:58:59) abadger1999: I just added .pyo files to the schedule which I hope is another EasyFix. (08:59:59) tibbs: Is the issue well-understood now? I've been ghosting .pyo files for a long time now and requiring it of the packages I review. (09:00:10) rdieter: not sure we'll have enough attendee's to get much done, unfortunately. ): (09:00:10) scop [n=scop] entered the room. (09:00:35) slack_: I am here and have lurk mode turned off.  I'm Jack (09:00:43) tibbs: We know Ralf and Spot are out, but we can still get something done. (09:01:40) abadger1999: Ghosting seems to have two issues that I can see: 1) causes AVC denials in the log which it seems SELinux isn't able to selectively filter out. (09:02:55) abadger1999: 2) python won't currently overwrite .pyos so it's possible for a sys admin to "break" python apps by running python -OO [application] and not have an intuitive way to recover. (09:03:38) scop: how would that break? (09:05:03) tibbs: Don't forget 3) requires piling nasty crap into the specfile. (09:06:08) scop: I think 3) is solvable by a clever "find" (09:06:08) abadger1999: scop: If the python application depends on docstrings (09:06:35) tibbs: scop: It's still a lot worse than putting a single directory in %files. (09:06:47) scop: yep (09:06:58) abadger1999: -OO will remove the docstrings so the application will break. (09:07:13) f13: I'm here. (09:07:35) tibbs: I have no opposition to including .pyo as long as folks who know Python well say it's OK. (09:07:56) f13: Jeremy Katz is pretty knowledgable IMHO and thinks we should be packaging them. (09:07:59) tibbs: But remember that rpm will create .pyc and .pyo files for any file ending in .py that it finds, including in /bin. (09:08:18) scop: yep, that's a rpm bug :) (09:08:21) abadger1999: tibbs: Hmmm.. bug? (09:08:35) tibbs: Yes, and filed already some months ago. (09:08:46) scop: and closed, IIRC... (09:09:01) abadger1999: Do we want to write a note to rm the .pyc/.pyo in the Python Guidelines? (09:09:10) abadger1999: (The ones in bin) (09:09:14) scop: it doesn't help (09:09:30) abadger1999: Oh. Right because it happens after %install? (09:09:30) scop: can't be done, it's done by rpm after %install and before %files (09:09:44) abadger1999: %exclude? (09:09:52) scop: breaks if they're not there (09:10:07) rdieter: but they *will* be there... (: (09:10:11) tibbs: I maintain a package with this problem. (09:10:26) scop: rdieter, yes, until they one day won't (09:10:31) tibbs: I touch the files, then let RPM create them if it's going to. (09:10:35) tibbs: And then %exclude them. (09:10:49) scop: that works (09:11:17) abadger1999: What about renaming the files to not have an extension? (Seen that done in some Core packages) (09:11:23) scop: the bug is https://bugzilla.redhat.com/182498, btw (09:11:30) abadger1999: Which is the lesser evil? :-) (09:11:47) tibbs: Yep, just found it. Definitely not closed. (09:11:48) scop: abadger1999, yes, that's also suggested in #182498 and I don't think it's unreasonable at all (09:12:23) tibbs: Unreasonable if there's already an expectation that the files exist with those names. (09:13:01) f13: not so unreasonable if its a bug... (09:13:07) tibbs: I was maintaining my package before PRM picked up this bad habit... (09:13:31) f13: but we shouldn't hold up proper packaging because of an existing bug, its just more reason to fix the bug (09:13:40) f13: and patches are welcome (09:14:36) scop: abadger1999, so if *.pyo compiled with -O (not -OO) were shipped, apps that have docstring deps would work also with -OO? (09:15:51) f13: scop: well, running w/ -OO won't create new .pyo files (09:15:57) abadger1999: scop: Yes. Because of the python bug. (09:16:18) abadger1999: bug/feature. Have to file it upstream and see what they say. (09:16:34) rdieter: let me get this straight, so the proposal (for now) is to simply exclude *all* .pyo files (at least until python and/or rpm is fixed)? (09:16:50) scop: no, but to include all of them without %ghosting (09:17:01) rdieter: ok. (09:17:01) scop: or? (09:17:06) abadger1999: scop: And work in the sense that docstrings are all there. It doesn't work in the sense that -OO is then equivalent to -O. (09:17:19) tibbs: Except ones outside of libdir created due to rpm bugs, I think. (09:17:21) scop: abadger1999, thanks, got it (09:17:24) abadger1999: scop: correct. Include the .pyos instead of %ghost. (09:18:19) f13: Do we have enough people for a vote? (09:18:37) f13: All in favor of changing the guidelines to package your .pyo's instead of %ghosting them? (09:18:42) f13: +1 (09:18:43) abadger1999: +1 (09:18:49) lutter: +1 (09:18:59) rdieter: +1 (09:19:03) tibbs: +1 (09:19:18) scop: reluctant +1 (09:19:33) f13: thats 6, so it passes. (09:19:42) abadger1999: scop: Do you have a reason, or just gut feeling? (09:19:48) abadger1999: (For reluctance) (09:20:05) f13: abadger1999: you'll want to send something to fedora-maintainers about the change, so that we can get feedback during our week long timeout. That'll get Red Hat packagers attention too. (09:20:21) scop: it smells like a bug workaround (09:20:27) abadger1999: f13: Okay. I'll write it up and send it. (09:20:45) f13: scop: the reason we're doing this is because the system will get lots of AVC denies as users try to create files in /usr/ (09:21:12) f13: scop: so its better to provide the performance enhanced modules since we create them in our packages. (09:21:25) f13: I can't think of many cases were peopel don't want their system to run faster. (09:21:35) scop: yes, I understand, but pedantically thinking, it still doesn't sound like the correct fix to me (09:21:58) abadger1999: scop: Yep. To me too. The python issue might be fixed but there seems to be resistance to "fixing" the SELinux flexibility. (09:21:59) tibbs: I think it's quite reasonable to expect to see a .pyo wherever there's a .pyc; otherwise, python will just keep trying to create them when it can't. (09:22:04) rdieter: imo, the best long-term solution is to to what debian does, and (properly) generate .pyo files in %post and/or on demain (ie, as needed) (09:22:17) rdieter: s/demain/demand/ (09:22:31) tibbs: Doesn't debian neglect to create .pyc files as well? (09:22:37) f13: rdieter: on demand means users will be trying ot write to /usr/ all the time. (09:22:49) f13: LOTS of AVCs (09:22:58) rdieter: by demand, I meant not by users, but when/if ever needed (ie, on python upgrades) (09:23:07) lutter: and you don't want to leave .pyo files behind when the rpm is uninstalled (09:23:28) rdieter: lutter: of course, that solution requres %ghost'ing again. (09:23:42) rdieter: but we're not there yet... (09:23:47) f13: rdieter: and doens't help when a user would run with OPTIMIZATION (09:23:59) f13: for all the missing .pyo's you'd get an AVC (09:24:04) rdieter: f13: the .pyo files would already be there. (09:24:32) ***f13 gets confused (09:24:46) f13: oh, I see, do it in %post. (09:25:01) ***f13 isn't a huge fan of file creation in %post (09:25:21) rdieter: me neither, but that's the only robust way to do it (afaict) (09:25:31) scop: that needs to take read-only mounts into account (09:25:45) rdieter: scop: man, you and your read-only mounts... (: (09:25:51) scop: :) (09:25:57) scop: and I don't even use those myself :) (09:26:04) f13: scop: how could you install something to a read-only mount? (09:26:20) rdieter: that just seems wrong, you're installing rpms, but to ro mounts? (f13: ++) (09:26:21) scop: think %{_netsharedpath} (09:26:36) rdieter: yeah, I'm thinking it's a bad idea. (: (09:26:55) scop: not a big issue ATM for python because site-lib dirs are in /usr/lib(64), not /usr/share (09:27:13) rdieter: sorry, digressing... anything else to hash out today? (pyo is done, right?) (09:27:16) lutter: stateless has exactly that problem .. you install into an image somewhere and then mount that r/o on lots of clients (09:27:19) abadger1999: Anyone object to moving on? (09:27:27) f13: no objections (09:27:33) ***f13 hates that meeting is during lunch time (09:27:34) rdieter: move_on++ (09:27:36) abadger1999: Should we just go down the list? (09:27:48) abadger1999: lutter: Anything to report on Ruby Gems? (09:27:55) ***scop is afk for ~2 mins (09:28:19) lutter: abadger1999: nope, nothing .. for now, it's not a very pressing issue (09:28:51) abadger1999: Okay. Send an email when the draft is ready? (09:29:28) abadger1999: f13: What's going on with jpackage naming? (09:29:59) f13: abadger1999: -ENOFEEDBACK :/ (09:30:01) lutter: abadger1999: yeah, I'll bring it up when I got something .. we might just keep not allowing rubygems packages .. that's what debian does (09:30:14) f13: abadger1999: i've been told there are concerns, just not what they are. (09:31:16) abadger1999: f13: Lovely :-/ Well, as long as new java packages don't go in unless they follow the current naming standards they'll have to figure things out eventually. (09:31:16) rdieter: f13: no feedback means everyone is ok with your proposal to use X. (09:32:02) rdieter: (: (09:32:24) abadger1999: Moving on... (09:32:46) abadger1999: f13: Arch specific scripts? (09:33:22) f13: havne't gathered a lot of feedback on this either. (09:33:36) f13: needs more discussion on list (09:34:04) abadger1999: Did you talk to nasrat about it (I seem to recall we were going to get input from him.) (09:34:11) tibbs: I rethought my objections to this. (09:34:41) f13: I honestly don't recall (09:34:54) rdieter: for the record, I'm (atm) leaning toward making those arch-specific (ie, not noarch), it'll make life simpler (esp buildsystem-wise) (09:34:56) f13: I haven't thought about it in too long and need to rehash the issue. (09:35:31) scop: still regarding *.pyo, here's the corresponding spec template change: http://koti.welho.com/vskytta/pyspec.patch (09:35:51) scop: (includes similar comments as were recently added in the perl template) (09:36:18) f13: cool (09:36:21) f13: looks good (09:36:23) rdieter: scop: thanks, that makes things clearer. (09:36:44) abadger1999: scop: Looks great. (09:37:42) abadger1999: f13: Can you bring the script issue back up on the list when you have time and we can see if we still have objections to it? (09:37:54) f13: yep (09:38:34) abadger1999: tibbs: Directory ownership (09:39:02) abadger1999: Have we thought about this more, or not since the last meeting? (09:39:24) tibbs: I don't recall any additional discussion, (09:39:44) tibbs: and it would be pretty unfair to proceed when one of the major objectors to any changes (Ralf) isn't here. (09:40:03) abadger1999: Ah right. (09:40:08) tibbs: Although I could be misrepresenting Ralf's position; I admit to not fully understanding his objections. (09:40:50) lutter: even more reason to wait for him (09:41:00) rdieter: fair enough. (09:41:24) tibbs: I guess that should have changed from "easyfix". (09:41:32) abadger1999: Sounds good. (09:41:42) abadger1999: Okay. License Tags is next (09:42:12) tibbs: List discussion seemed to lean towards this being just a superficial description of the license. (09:42:32) tibbs: That we shouldn't try to get too specific with the license tags. (09:42:46) lutter: yeah, I don't see that ever being more than an indication (09:42:50) abadger1999: I tend to agree with that. (09:43:04) tibbs: So "GPL", not "GPLv2" and "GPLv3", etc. (09:43:21) abadger1999: The License field shouldn't be misleading, though. (09:43:24) tibbs: And "BSD", not "BSD with advertising". (09:44:10) abadger1999: So if GPLv2 and GPLv3 are different enough we would want to differentiate. (09:44:16) tibbs: And packagers should brave the rpmlint warning rather than lying about the license just to shut it up. (09:44:17) lutter: for GPL, I could go either way; if it's BSD with modifications, why not just 'BSD variation' (09:44:23) scop: rpmlint's explanation about the "invalid-license" message needs to be toned down a bit, will have a look (09:44:53) rdieter: how about s/invalid-license/unknown-license/ (09:45:01) abadger1999: scop: Thanks. That's one that I often have to write please ignore this warning. (09:45:40) scop: in general, it's not a good thing to change message identifiers (such as invalid-license) in rpmlint (09:45:46) scop: because it will break people (09:45:50) scop: 's filters (09:46:13) rdieter: ok (09:46:39) f13: people shouldn't have filters on rpmlint (: (09:47:07) scop: $ grep addFilter /usr/share/rpmlint/config # :) (09:47:38) rdieter: so is there a License tag proposal here somewhere? (: (09:47:59) f13: scop: sounds like a great way to hide issues :/ (09:48:20) scop: f13, yes, and non-issues :) (09:48:32) tibbs: No, I haven't written one up. (09:48:52) f13: scop: IMHO every rpmlint E/W is an issue until a reasonable excuse is given (09:48:57) abadger1999: It doesn't look like we have any current Guidelines about the Tag; just what rpmlint says. (09:49:48) tibbs: Then let's get a simple guideline in place and then get rpmlint fixed to match. (09:50:15) rdieter: sounds reasonable. (09:50:22) abadger1999: Sounds good. (09:50:28) tibbs: I'll write something up for next week and present it to the list. (09:50:38) abadger1999: Cross compilation needs Ralf. (09:50:41) f13: part of said guideline would be 'If your license is unknown, you must inlude the license in your %doc' ? (09:51:13) abadger1999: scop: Renaming and EOL (09:51:40) lutter: f13: I think teh guideline should be 'if upstream has an explicit license file, it must be included as %doc' (09:52:01) scop: there are rename cases where Provides: is not appropriate (09:52:09) abadger1999: lutter, f13: I think that portion is almost in the guidelines already. Maybe clarify that portion? (09:52:33) f13: lutter: I'm pretty sure there are guidelines to that effect already, however when the license is special, or rather unknown, we should manually include the license if it isn't already. (09:52:39) scop: actually, "superseded by" is that case (09:52:50) scop: assuming rename means just that (09:53:00) lutter: f13: I see what you're saying, yeah, makes sense (09:54:02) scop: the EOL things should be no-brainers, just process stuff (09:55:04) abadger1999: http://www.fedoraproject.org/wiki/PackagingDrafts/PackageEndOfLife (09:55:15) abadger1999: For the EOL process. (09:56:19) lutter: makes sense (09:56:32) tibbs: Shouldn't FESCo be doing a policy like that, though? (09:56:40) tibbs: It doesn't seem to have any relevance to Core. (09:57:11) f13: makes sense but yeah, doesn't seem much of a Packaging issue (09:57:19) scop: the Obsoletes/Provides part of the agenda item is a packaging thing (09:57:47) rdieter: tibbs: I *could* be relavent to Core as well, when/if an upstream product is EOL'd/renamed. (09:58:08) f13: we do things differently (09:58:25) f13: we have a package database that keeps track of what packages are in which collections, because trying to just use cvs modules for that is the path to insanity (09:58:28) rdieter: f13: good point. (: (09:58:44) tibbs: Core process stuff isn't and doesn't really have to be transparent to Extras folks. (09:58:54) abadger1999: Is the case just for "superseded"? Or for both superseded and rename? (09:59:01) f13: so when a package is removed from Core, we remove it from the collection in the database, then autmoated things just lookup in teh DB what packages should be pulled in. (09:59:25) scop: abadger1999, whenever something changes in a way that the new package is not a drop-in replacement, IMO (09:59:58) rdieter: FESCo is starting... (: (10:00:29) scop: okay, let's defer this (10:00:41) abadger1999: scop: do you want to write up the one or two lines that describe this? (10:00:55) scop: will do (10:00:58) abadger1999: I'm going to move it to the top of GuidelinesTodo for next week. (10:01:19) abadger1999: (Hey we nearly got through every item this week :-)