16:00:35 <spot> #startmeeting Fedora Packaging Committee
16:00:35 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:39 <spot> #meetingname fpc
16:00:39 <zodbot> The meeting name has been set to 'fpc'
16:00:43 * geppetto is here
16:00:52 <spot> sorry about missing last week, i had emergency dentist visit. :/
16:00:56 <limburgher> ow.
16:00:59 <abadger1999> Ouch
16:01:10 <abadger1999> Hope that's been taken care of.
16:03:45 <spot> so far, it has
16:04:15 * spot counts 5 fpc members
16:04:52 <spot> gimme a minute to load up an agenda
16:06:02 <spot> so, i don't see any pending tickets except for the Gargoyle ticket
16:06:16 <spot> is there any status change on that to discuss?
16:06:30 <tibbs> No.
16:06:46 <spot> Then I suppose we'll just open the floor
16:06:49 <spot> #topic Open Floor
16:07:09 <tibbs> I want to do some work on the DistTag guideline, as it's... bad.
16:07:37 <spot> hey now, i wrote that ten years ago and i resemble that remark. ;)
16:07:43 <limburgher> What's the gist of your ideas for change there?
16:07:59 <tibbs> I started in with https://fedoraproject.org/wiki/User:Tibbs/DistTag
16:08:19 <tibbs> I mean, the thing talks about CVS and has lists of things going back to RHL but stopping at F13.
16:08:57 <tibbs> Does anyone know if there's any wiki magic to get the current Fedora release number?
16:08:59 <limburgher> Yeah, it's a bit dated.
16:09:21 * abadger1999 doesn't know of something
16:09:34 <tibbs> Because examples either get out of date, or you update them every release, or you talk about "Fedora 56".
16:09:37 <abadger1999> You could ask ianweller, though... I bet that could be/is setup as some sort of tempate
16:09:39 <spot> if anyone knows, it would be ianweller
16:09:41 <limburgher> 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 <limburgher> spot: <nods>
16:10:52 <tibbs> 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 <spot> the ones i wrote in the long-long-ago are known to work.
16:11:07 <spot> others involving == will need to be carefully tested
16:11:48 <tibbs> I will probably remove the mention of RPMForge.  I don't even remember what that was.
16:12:09 <ianweller> you mean a version template on the wiki?
16:12:26 <ianweller> http://fedoraproject.org/wiki/Template:FedoraVersion
16:12:44 <tibbs> Awesome.
16:13:03 <tibbs> I may go in and put that in a few places that we currently have to update manually.
16:13:59 <spot> RPMForge was the Dag + FreshRPMS + Dries repo.
16:14:06 <spot> I think it may now be called "RepoForge"
16:14:14 <geppetto> 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 <spot> geppetto: please just do it. :)
16:14:35 <geppetto> 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 <spot> geppetto: umm, okay, i suppose you could just change epoch.
16:15:48 <geppetto> 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 <spot> Do we want to say that either version or release should be incremented as well, depending on the situation?
16:16:20 <spot> the sourcerpm doesn't inherit epoch? weird.
16:16:22 <geppetto> Well "incremented" is bad … but "changed", yeh.
16:16:38 <geppetto> spot: It's the filename of the sourcerpm, so doesn't contain the epoch.
16:16:45 <spot> oh, you mean the macro.
16:16:55 <geppetto> spot: And the rpm header.
16:16:59 * spot nods
16:17:12 <spot> geppetto: draft it up, i think that will pass easily
16:17:49 <limburgher> likely.
16:18:08 <spot> any other items for today?
16:18:12 * spot will wait a minute or two
16:18:13 <abadger1999> UsrMove is causing issues.
16:18:30 <spot> abadger1999: our guidelines or the feature itself?
16:18:34 <abadger1999> Here's an example bug but there's been other cases: https://bugzilla.redhat.com/show_bug.cgi?id=856584
16:18:59 <abadger1999> I think we could update guidelines to require virtual Provides: and that might solve it.
16:19:10 <geppetto> 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 <geppetto> s well."
16:19:13 <abadger1999> but that would be somewhat icky
16:19:29 <abadger1999> and I'm not sure if the packaging team has some better idea
16:19:49 <tibbs> 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 <spot> well, fixing the autodeps to spit out both might be a fix
16:20:17 <geppetto> tibbs: it's that std.?
16:20:23 <tibbs> A lot of things that use $0 get pretty confused by that.
16:20:47 <tibbs> 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> [spot@wolverine ~]$ echo $PATH
16:21:04 <spot> /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/spot/.local/bin:/home/spot/bin
16:21:17 <geppetto> interesting
16:21:18 <spot> so, not before /usr/bin.
16:21:53 <abadger1999> hmm... I have it before /usr/bin too... /me checks on a vm
16:22:03 <geppetto> mind is the same as spot's.
16:22:07 <spot> 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 <geppetto> s/mind/mine/
16:22:17 * spot hasn't touched $PATH on this system
16:22:34 <limburgher> I have it after, no mods.  Fresh 17 install.
16:22:37 <geppetto> yeh, I think I just add to mine … so it's std.
16:22:43 <abadger1999> => /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 <abadger1999> that's from nirik's rawhide-test.scrye.com
16:23:01 <spot> on a fresh F18, i have /bin/ before /usr/bin
16:23:05 <spot> [spot@f18 ~]$ echo $PATH
16:23:05 <spot> /usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/spot/.local/bin:/home/spot/bin
16:23:22 <spot> so maybe this is fixed in new F18 installs?
16:23:43 <geppetto> 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 <tibbs> The problem is that you _don't_ want /bin before /usr/bin.
16:24:03 <geppetto> Or even just use realpath() on the answer?
16:24:14 <spot> tibbs: yeah, sorry, i was parsing it backwards
16:24:42 <geppetto> .local/bin … interesting :)
16:24:53 <tibbs> Obviously anything that cares is broken, but still.
16:25:07 <tibbs> scilab is one package in the distro that cares.
16:25:31 <geppetto> Well, yum has to care because it's just strings.
16:25:48 <geppetto> and /bin/foo != /usr/bin/foo
16:25:51 <spot> i think fixing rpm and then fixing the default pathing for new accounts is the best we can do
16:25:59 <tibbs> 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 <spot> we could pathmunge() in /etc/profile i suppose.
16:27:27 <spot> 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 <abadger1999> 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 <spot> geppetto: you're the token "packaging-team" person, can you make sure this lands on their radar?
16:29:42 <tibbs> If we need to get into doing virtual provides, though, than that would requires a guideline.
16:30:27 <limburgher> On sysv, it's /etc/init.d/functions.
16:31:02 <spot> limburgher: yeah, that's not it though, it may be hardcoded into the shells.
16:31:08 <abadger1999> <nod>  geppetto can toss it back to us if packaging-team rejects doing a fix in rpm.
16:31:14 <limburgher> spot: Good point.
16:31:35 <tibbs> 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 <geppetto> spot: abadger1999: Yeh, I'll ping Panu about it.
16:31:50 <spot> tibbs: the people who work on core packaging sw for Red Hat (RPM, yum, etc)
16:33:13 <limburgher> spot: Might it be hard-coded in systemd?
16:33:33 <spot> It's possible.
16:37:56 <spot> okay, well, i think we're all done here
16:37:59 <spot> thanks everyone
16:38:03 <spot> #endmeeting