16:00:35 #startmeeting Fedora Packaging Committee 16:00:35 Meeting started Wed Sep 12 16:00:35 2012 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:35 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:39 #meetingname fpc 16:00:39 The meeting name has been set to 'fpc' 16:00:43 * geppetto is here 16:00:52 sorry about missing last week, i had emergency dentist visit. :/ 16:00:56 ow. 16:00:59 Ouch 16:01:10 Hope that's been taken care of. 16:03:45 so far, it has 16:04:15 * spot counts 5 fpc members 16:04:52 gimme a minute to load up an agenda 16:06:02 so, i don't see any pending tickets except for the Gargoyle ticket 16:06:16 is there any status change on that to discuss? 16:06:30 No. 16:06:46 Then I suppose we'll just open the floor 16:06:49 #topic Open Floor 16:07:09 I want to do some work on the DistTag guideline, as it's... bad. 16:07:37 hey now, i wrote that ten years ago and i resemble that remark. ;) 16:07:43 What's the gist of your ideas for change there? 16:07:59 I started in with https://fedoraproject.org/wiki/User:Tibbs/DistTag 16:08:19 I mean, the thing talks about CVS and has lists of things going back to RHL but stopping at F13. 16:08:57 Does anyone know if there's any wiki magic to get the current Fedora release number? 16:08:59 Yeah, it's a bit dated. 16:09:21 * abadger1999 doesn't know of something 16:09:34 Because examples either get out of date, or you update them every release, or you talk about "Fedora 56". 16:09:37 You could ask ianweller, though... I bet that could be/is setup as some sort of tempate 16:09:39 if anyone knows, it would be ianweller 16:09:41 would be a lovely thing, though. 16:10:18 * spot has no issue with tibbs's rewrite, just be very careful if you add new conditionals 16:10:38 spot: 16:10:52 I haven't changed much yet; not sure how much I'm going to actually change besides getting rid of mentions of CVS and outdated lists. 16:10:56 the ones i wrote in the long-long-ago are known to work. 16:11:07 others involving == will need to be carefully tested 16:11:48 I will probably remove the mention of RPMForge. I don't even remember what that was. 16:12:09 you mean a version template on the wiki? 16:12:26 http://fedoraproject.org/wiki/Template:FedoraVersion 16:12:44 Awesome. 16:13:03 I may go in and put that in a few places that we currently have to update manually. 16:13:59 RPMForge was the Dag + FreshRPMS + Dries repo. 16:14:06 I think it may now be called "RepoForge" 16:14:14 One really minor "just fix" thing is that http://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_Release links to http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version but it should be http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning 16:14:32 geppetto: please just do it. :) 16:14:35 Also … we don't explicitly say "you can't change epoch and not also change one of version/release" … that I can see. 16:15:05 geppetto: umm, okay, i suppose you could just change epoch. 16:15:48 spot: It's a bad idea to allow it IMO … there are a few cases where we don't have epoch, like sourcerpm. 16:15:59 Do we want to say that either version or release should be incremented as well, depending on the situation? 16:16:20 the sourcerpm doesn't inherit epoch? weird. 16:16:22 Well "incremented" is bad … but "changed", yeh. 16:16:38 spot: It's the filename of the sourcerpm, so doesn't contain the epoch. 16:16:45 oh, you mean the macro. 16:16:55 spot: And the rpm header. 16:16:59 * spot nods 16:17:12 geppetto: draft it up, i think that will pass easily 16:17:49 likely. 16:18:08 any other items for today? 16:18:12 * spot will wait a minute or two 16:18:13 UsrMove is causing issues. 16:18:30 abadger1999: our guidelines or the feature itself? 16:18:34 Here's an example bug but there's been other cases: https://bugzilla.redhat.com/show_bug.cgi?id=856584 16:18:59 I think we could update guidelines to require virtual Provides: and that might solve it. 16:19:10 So the "simple" change is to have the last paragraph of http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning be: "rpm's understanding of what package is newer comes from the values of the Epoch, Version, and Release tags. The next few sections explain what values to use in those tags to ensure that the EVR consistently increases. Note that you should never change just the Epoch value, at the very least increment the release a 16:19:10 s well." 16:19:13 but that would be somewhat icky 16:19:29 and I'm not sure if the packaging team has some better idea 16:19:49 Usrmove has caused me some weird problems, too. Maybe I'm just weird in that I had /bin and /sbin ahead of /usr/bin and /usr/sbin in my path. 16:20:11 well, fixing the autodeps to spit out both might be a fix 16:20:17 tibbs: it's that std.? 16:20:23 A lot of things that use $0 get pretty confused by that. 16:20:47 I don't know what's standard; I haven't changed my path in 20+ years. 16:21:02 * geppetto nods 16:21:04 [spot@wolverine ~]$ echo $PATH 16:21:04 /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/spot/.local/bin:/home/spot/bin 16:21:17 interesting 16:21:18 so, not before /usr/bin. 16:21:53 hmm... I have it before /usr/bin too... /me checks on a vm 16:22:03 mind is the same as spot's. 16:22:07 i wonder if fixing the path in rpm as pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=856584#c2 is sufficient. 16:22:10 s/mind/mine/ 16:22:17 * spot hasn't touched $PATH on this system 16:22:34 I have it after, no mods. Fresh 17 install. 16:22:37 yeh, I think I just add to mine … so it's std. 16:22:43 => /usr/lib64/qt-3.3/bin:/usr/lib64/mpich2/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/lib64/alliance/bin:/home/fedora/toshio/bin 16:22:55 that's from nirik's rawhide-test.scrye.com 16:23:01 on a fresh F18, i have /bin/ before /usr/bin 16:23:05 [spot@f18 ~]$ echo $PATH 16:23:05 /usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/spot/.local/bin:/home/spot/bin 16:23:22 so maybe this is fixed in new F18 installs? 16:23:43 spot: Yeh, that looks like a valid fix to me. The other one would be something that fixed up the paths inside rpm to remove symlinks which point to things that are also in the path. 16:23:59 The problem is that you _don't_ want /bin before /usr/bin. 16:24:03 Or even just use realpath() on the answer? 16:24:14 tibbs: yeah, sorry, i was parsing it backwards 16:24:42 .local/bin … interesting :) 16:24:53 Obviously anything that cares is broken, but still. 16:25:07 scilab is one package in the distro that cares. 16:25:31 Well, yum has to care because it's just strings. 16:25:48 and /bin/foo != /usr/bin/foo 16:25:51 i think fixing rpm and then fixing the default pathing for new accounts is the best we can do 16:25:59 Anyway, I'm not arguing for reverting usrmove; just that this is another unintended consequence that wasn't considered. 16:26:40 * spot has no idea where the default PATH gets set 16:26:58 we could pathmunge() in /etc/profile i suppose. 16:27:27 wait, no, that wouldn't work 16:29:01 * spot is afraid if keep poking down in this hole something awful and dusty will eat me 16:29:03 Well, if the fix seems to be in rpm+updated shell init scripts, I think we can leave it to packaging-team to figure out. 16:29:32 geppetto: you're the token "packaging-team" person, can you make sure this lands on their radar? 16:29:42 If we need to get into doing virtual provides, though, than that would requires a guideline. 16:30:27 On sysv, it's /etc/init.d/functions. 16:31:02 limburgher: yeah, that's not it though, it may be hardcoded into the shells. 16:31:08 geppetto can toss it back to us if packaging-team rejects doing a fix in rpm. 16:31:14 spot: Good point. 16:31:35 This is probably a dumb question, but just what is this "packaging-team"? 16:31:39 * spot doesn't see an obvious place where it is configured and inherited 16:31:43 spot: abadger1999: Yeh, I'll ping Panu about it. 16:31:50 tibbs: the people who work on core packaging sw for Red Hat (RPM, yum, etc) 16:33:13 spot: Might it be hard-coded in systemd? 16:33:33 It's possible. 16:37:56 okay, well, i think we're all done here 16:37:59 thanks everyone 16:38:03 #endmeeting