16:00:06 <geppetto> #startmeeting fpc
16:00:06 <zodbot> Meeting started Thu Oct 20 16:00:06 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:06 <zodbot> The meeting name has been set to 'fpc'
16:00:06 <geppetto> #meetingname fpc
16:00:06 <geppetto> #topic Roll Call
16:00:06 <zodbot> The meeting name has been set to 'fpc'
16:00:32 <orionp> hello
16:00:35 <Rathann> hi
16:00:44 <geppetto> #chair orionp
16:00:44 <zodbot> Current chairs: geppetto orionp
16:00:47 <tibbs> Howdy.
16:00:47 <geppetto> #chair Rathann
16:00:47 <zodbot> Current chairs: Rathann geppetto orionp
16:00:50 <geppetto> #chair tibbs
16:00:51 <zodbot> Current chairs: Rathann geppetto orionp tibbs
16:01:00 <geppetto> Hey
16:01:24 <geppetto> #chair limburgher
16:01:24 <zodbot> Current chairs: Rathann geppetto limburgher orionp tibbs
16:03:53 <geppetto> #chair racor
16:03:53 <zodbot> Current chairs: Rathann geppetto limburgher orionp racor tibbs
16:04:48 <moto-timo> .hello ttorling
16:04:49 <zodbot> moto-timo: ttorling 'Tim Orling' <ticotimo@gmail.com>
16:04:56 <geppetto> Ok
16:05:01 <geppetto> #topic Schedule
16:05:04 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/R3O7PI5EMW7ARWVDEKS6N7M32OAWDI4I/
16:05:12 * limburgher here
16:05:27 <geppetto> limburgher: Yeh, I gottcha :)
16:05:32 <geppetto> #topic #655  meson buildsystem guidelines
16:05:37 <geppetto> .fpc 655
16:05:38 <zodbot> geppetto: #655 (meson buildsystem guidelines) – fpc - https://fedorahosted.org/fpc/ticket/655
16:06:27 <geppetto> ignatenkobrain: you here?
16:07:58 <geppetto> #topic #656  pre/post-release version guidelines need major simplification
16:08:02 <geppetto> .fpc 656
16:08:03 <zodbot> geppetto: #656 (pre/post-release version guidelines need major simplification for the git era) – fpc - https://fedorahosted.org/fpc/ticket/656
16:08:38 <geppetto> ok, tibbs and I have looked at this … it seems mostly cleanups, but everything is different if we approve the tilda guidlines
16:08:56 <geppetto> (That's https://fedorahosted.org/fpc/ticket/398)
16:09:12 <tibbs> Trying to ignore the cleanups for now, I think there are just two suggested changed.
16:09:16 <tibbs> changes.
16:09:26 * zbyszek is lurking
16:09:33 <tibbs> The thing is, I don't know how many versions of this document I can keep straight.
16:09:43 * geppetto nods :(
16:09:52 <tibbs> I'm completely redoing it already.
16:10:17 <tibbs> https://fedoraproject.org/wiki/User:Tibbs/VersioningCleanup
16:10:18 <limburgher> So maybe we should wait and discuss the fruit of your labours.
16:11:04 <tibbs> I'm trying to do a reorganization and cleanup without actually changing any policy, which is tough.
16:11:37 <limburgher> It's like refactoring, but in a human language.  What could possibly go wrong?
16:11:52 <tibbs> Anyway, basically, it's: say why we have a non-obvious scheme in some cases, then give the rule that most packages will follow.
16:12:00 <tibbs> Then... well, try to figure things out.
16:12:24 <tibbs> And I'm hampered by trying to figure out why we separate things into prerelease, postrelease and snapshots.
16:12:57 <tibbs> When it's really just prerelease and postrelease, each of which may be a snapshot you check out yourself instead of using a tarball upstream provides to you.
16:13:29 <tibbs> And the big difference is that prerelease uses the version number that the thing _will_ become, and a release tag < 1.
16:13:41 <limburgher> I think it was considering alphas, betas, rc and whatnot to be distint semi-blessed things as opposed to HEAD.
16:13:42 * geppetto nods
16:13:50 <limburgher> distinct.
16:13:54 <tibbs> Postrelease uses the version number that the thing used to be, and a release tag >= 1.
16:14:07 <limburgher> And honestly I don't think we need to make that distinction.
16:14:34 <tibbs> In the end those are the only two cases you need to consider; how you actually construct the stuff to put into the release tag is where you differentiate.
16:14:41 <tibbs> BTW, I'm lagging.
16:14:43 <limburgher> For some software a checkout or pre1 is super stable, while other software has shaky releases.
16:14:52 <limburgher> Right.
16:15:08 <moto-timo> tibbs++ for Versioning cleanup wiki
16:15:09 <zodbot> moto-timo: Karma for tibbs changed to 11 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:15:11 <tibbs> We certainly do not want to get into whether something is actually stable enough to package.
16:15:20 <limburgher> Oh heck no.
16:15:33 <tibbs> Really, though, all I've done is moved some stuff around and written two new sections.
16:15:36 <tibbs> So... not done.
16:15:58 <tibbs> I plan to incorporate the cleanups from 656 once I get down to the examples.
16:16:04 <limburgher> Thanks for diving into the morass, thought.
16:16:06 <limburgher> though.
16:16:20 <tibbs> The hard thing (besides English) is making sure I don't actually change policy anywhere.
16:16:42 <tibbs> Please search for XXX and see if you can answer any questions there.
16:16:58 <tibbs> For example, we do allow "1.23a" in a Version: tag, no problem.
16:17:21 <tibbs> Do I even need to think about "1b.23a"?  I'm hoping the answer is no.
16:17:34 <limburgher> I would think not.
16:18:15 <tibbs> One thing I've realized is that if we have a simpler guideline that does leave some cases unanswered, we may actually have better compliance than a complex guideline that covers every possibility.
16:18:32 <tibbs> Even if the people who hit the unanswered cases go nuts and make things up.
16:18:40 <tibbs> (instead of asking).
16:19:49 <limburgher> And for better or for worse there will always be some of that.
16:19:52 <tibbs> I will say that zbyszek was right that we need to consider the case where upstream has never chosen a version.
16:20:00 <limburgher> And 99% of the time stupid things are avoided.
16:20:24 <tibbs> limburgher: Yeah, my thought was that if the guideline is simpler then people will actually do less of it instead of giving up halfway through reading and making something up.
16:20:50 <tibbs> A long time ago I advocated using a version of "0.0.0" when upstream has never chosen one.
16:22:00 <zbyszek> Sometimes you know (or are planning) that some specific numbering scheme will be used, and then it's nicer to match it in the "0" version too.
16:22:04 <tibbs> I think we have an example that uses '0' but doesn't talk about it.
16:22:12 <zbyszek> Yes.
16:22:20 <zbyszek> kismet
16:22:29 <limburgher> That makes more sense that "1", which I see occasionally.  0.0.0 conveys the ambiguity I feel about this sort of software quite nicely, and allows for the use of versioning if upstream ever gets crazy and says 0.1.
16:22:29 <tibbs> I think that 0 is probably not good; I think you used 0.0.
16:22:39 <limburgher> Or 0.0.0.0
16:22:55 <tibbs> I think three zeroes is probably enough.
16:22:56 <limburgher> Or maybe 0.0.C if it's a beta
16:22:57 <moto-timo> and "1" implies a release...
16:23:13 <moto-timo> (to some people)
16:23:15 <limburgher> Maybe if we had it on a line. . .
16:23:36 <tibbs> We just have to pick something which is almost certain to be lower than anything an upstream might pick.
16:23:47 <tibbs> Note: I don't know if "0" is lower than "0.0"
16:23:55 <limburgher> And negative numbers would b0rk the parser.
16:23:57 <tibbs> under rpmvercmp's ordering.
16:24:12 <zbyszek> rpmdev-vercmp 0 0.0
16:24:12 <zbyszek> 0 < 0.0
16:24:20 <limburgher> Crud.
16:24:20 <zbyszek> So it seems 0 is the only safe bet.
16:24:25 <limburgher> I liked 0.0.0
16:24:49 <tibbs> The important thing is that we must say that if you do that, Verion: must be "0" and absolutely nothing else.
16:24:54 <tibbs> Version:
16:25:06 <limburgher> We could propose a patch to rpmdev-vercmp to hardcode "turtles" as the lowest possible value. . .
16:26:01 <tibbs> And the other concrete issue in zbyszek's proposal was about actually telling people how to pick the alphatag/checkout/whatever thing for their snapshots.
16:26:21 <tibbs> Instead of saying "you must have the date, followed by whatever you want".
16:26:30 <tibbs> Well, 13 characters of whatever you want.
16:26:44 <tibbs> And that opens up some other questions:
16:26:54 <tibbs> 1) Do we still want to mandate the date in there.  (I say yes.)
16:27:09 <tibbs> 2) Is it really important that we tell people the thing came from git?
16:27:16 <tibbs> (or cvn or whatever)?
16:27:16 <moto-timo> +1 for mandatory date
16:27:47 <tibbs> We've faced the date question and always ended up deciding to mandate it so I probably shouldn't even bring it up now.
16:27:53 <limburgher> 1) yes.  If date stops incrementing, we have larger issues. 2) not really, as long as a commit identifier is present.
16:28:04 <tibbs> But for the rest.... why do we say "git" again?
16:28:31 <tibbs> Why not just say "date.shorthash"?
16:28:36 <limburgher> To indicate that it's vcs and not rc, beta, or release.
16:28:38 <tibbs> (right, because not everything has a shorthash).
16:28:51 <geppetto> I don't mind dropping the git part
16:28:54 <Rathann> for svn there are rev numbers
16:28:58 <tibbs> limburgher: OK, that's good.
16:29:10 <tibbs> And yes, for SVN you'd do date.svnrev
16:29:15 <limburgher> I thing it should be date.hash/rev/commit/whatever.
16:29:30 <limburgher> because if it's just date it missed multiple commits in the same day.
16:29:30 <Rathann> for cvs each file has a separate version
16:29:32 <Rathann> so :(
16:29:41 <tibbs> And for CVS you'd... quit computing and take up an honest trade like carpentry.
16:29:47 <Rathann> LOL
16:29:55 <limburgher> Or chartered accountancy.
16:30:09 <tibbs> But note that we're actually talking about a big change here.
16:30:20 <limburgher> By dropping the name of the vcs?
16:30:27 <tibbs> Sadly yes.
16:30:29 <geppetto> Well it wouldn't be compatible
16:30:38 <geppetto> that's the only thing I could see.
16:30:46 <tibbs> compatible how?
16:30:51 <limburgher> Why not?  If people keep updating date, what comes after is irrelevant.
16:31:05 <geppetto> I guess
16:31:13 <limburgher> Failing that, bump rev.
16:31:17 <tibbs> Actually even the date doesn't matter.
16:31:32 <tibbs> Right, you always have the most significant digit.  It's kind of the nice thing about our scheme.
16:31:41 <tibbs> But anyway, those are the two issues.
16:31:53 <limburgher> But specify date as YYYYMMDD to that's always true. :)
16:32:13 <tibbs> Can we get agreement that "use Version: 0 if upstream has not chosen a version" is good policy?
16:32:15 <limburgher> No MMDDYYYY shenanigans, or MMDDYYYYY for Long Now members.
16:32:22 <geppetto> tibbs: sure
16:32:24 <limburgher> tibbs: Emphatically.
16:32:33 <moto-timo> +1
16:32:51 <tibbs> If I +1 then that gets us to 3, assuming we're actually voting.
16:33:11 * limburgher realizes with horror that YYYYMMDD isn't Y10k compliant.
16:33:11 <tibbs> I mean, we could just cover that bit of zbyszek's proposal right now.
16:33:39 <geppetto> limburgher: remind me in 7800 years
16:33:53 <tibbs> Basically I'm trying to knock off the parts of 656 that are policy changes so I can just put them in when I do my cleanup.
16:34:14 <geppetto> I have no problem with that
16:34:17 <tibbs> And then we can actually call that one done and get back to the other one once I'm done.
16:35:02 <tibbs> Or I could just go with the fact that we said use Version: 0 already with the kismet example.
16:35:23 <tibbs> Which still leaves the question of what to do with the bit after the date in the snapshot release value.
16:35:44 <limburgher> geppetto: We can just bump Epoch. . .literally. . .
16:35:58 <geppetto> limburgher: indeed
16:36:22 <limburgher> I say we drop the svn/cvs/git/darcs/postits string and do the equivalent of date.rev
16:37:26 <tibbs> I have no problem with that in general.  My concern is, basically, churn.
16:37:37 <limburgher> If we have to keep that string I say we change it to vcs.  It should sort.
16:37:50 <tibbs> I don't think sorting is a consideration here.
16:38:04 <limburgher> Wouldn't that imply people updating packages to meet the guidelines?
16:38:09 <tibbs> But that one change probably makes small waves all over the place.
16:38:15 <zbyszek> limburgher: it sorts the opposite way to what'd want
16:38:39 <tibbs> zbyszek: You couldn't change it anyway without bumping the main release value which is well to the left.
16:38:40 <limburgher> zbyszek: So it does.  It should go, then.
16:38:44 <tibbs> So sorting doesn't matter.
16:38:51 <zbyszek> Ack.
16:39:00 <Rathann> tibbs: +1 for 0 as default "no version" version
16:39:06 <tibbs> We can change the entire scheme to the right of the release and we're good.
16:39:11 <limburgher> People occasionally bump the vcs part of the release but not the initial integer.
16:39:23 <tibbs> Which obviously they should never do.
16:39:45 <tibbs> (And it's either an integer or "0." followed by an integer.)
16:39:49 <limburgher> I told you we should never have given humans commit access. . .
16:40:25 <limburgher> I've always thought of 0 as an integer. ;)P
16:40:37 <limburgher> For most values of 0.
16:40:53 <tibbs> I will make it clear with a big breaking prohibition that you must either increase the "release orderer" or increase the version and reset the "release orderer" to 1 or 0.1 whenever you make package changes.
16:41:07 <tibbs> 0.1 is decidedly not an integer.
16:41:08 <limburgher> Excellent.
16:41:21 <limburgher> Right.
16:41:29 <tibbs> I don't think we've actually really made it clear that "bumping release" is a mandatory thing.
16:41:55 <tibbs> Nor that you can't use a release of '0' in a Fedora package ever.
16:42:02 <limburgher> It should be common sense, but. . .you know. . .
16:43:07 <tibbs> So if we're voting for the explicit acceptance of using "Version: 0"  when upstream has not chosen a version, we're at +4.
16:43:31 <tibbs> (sadly I can't count moto-timo unless one of our other members changed their nick without me noticing).
16:44:50 <tibbs> I will basically proceed on the assumption that given the kismet example, we really did that a long time ago.
16:45:44 <tibbs> I don't know know where we stand on using "date.(vcs-commit-revision/hash/whatever)".
16:46:14 <limburgher> Surprisingly I'm +1.
16:46:19 <tibbs> I'm happy to do it and to change my stuff, but I certainly don't want to start on a cycle of churn that may or may not end in us adopting the tilde thing.
16:46:28 <tibbs> I'd rather change the whole thing at once.
16:46:32 <limburgher> Right.
16:46:42 <tibbs> Also... note that it's perfectly acceptable to use that now.
16:48:30 * geppetto nods
16:49:56 <geppetto> tibbs: So orionp and racor  to vote on your Version: 0 thing?
16:50:04 <geppetto> still to vote
16:50:42 <orionp> +1 for me
16:50:47 <racor> +1
16:51:11 <geppetto> #action Version of 0 should be used for packages with no upstream version (+1:6, 0:0, -1:0)
16:51:24 <geppetto> ok, done
16:52:42 <tibbs> Thanks.
16:53:02 <Rathann> what if upstream makes no formal releases but uses internal versioning anyway?
16:53:24 <tibbs> The idea is that you use upstream's versioning.
16:53:33 <tibbs> How you figure that out is up to you.
16:53:39 <Rathann> ok
16:54:10 <limburgher> 2d20 works.
16:54:20 <geppetto> ha
16:54:36 <geppetto> You can buy d120s now
16:54:39 <tibbs> If they have a point in the code that they call "2.0" and you package a snapshot that's beyond that, you  just do "2.0-1.20161020.commithash"
16:54:49 <tibbs> And get on with life.
16:55:05 * geppetto nods
16:55:07 <Rathann> tibbs: right
16:55:08 <limburgher> Great Caesar's ghost.
16:55:44 <tibbs> What I really want to do, eventually, is have one standard macro you use to provide the full commit hash.
16:56:00 <tibbs> And then to have everything else generated from that.
16:56:28 <geppetto> Can you create macros from within a macro?
16:56:30 <tibbs> Including having spectool or fedpkg or whatever understand that, and do your checkouts and make the tarball automatically.
16:56:45 <tibbs> geppetto: You can have macros with values depending on other macros.
16:56:54 <tibbs> And you can have macros that define other macros when you _call_ them.
16:57:16 <geppetto> Yeh, that's what I meant
16:57:17 <geppetto> ok
16:57:20 <tibbs> But you can't have the act of calling "%global foo abc" actually change the value of another macro.
16:57:41 <limburgher> So rpm macros aren't *quite* life forms.  Yet.
16:57:55 <tibbs> So basically if you have to do something really fancy, you make a macro that you call:
16:58:12 <tibbs> %githubpackage commithash
16:58:24 * geppetto nods
16:58:28 <tibbs> And, hell, everything else can exist from that.
16:58:42 <tibbs> Though in reality you'd have to provide more information.
16:59:00 <limburgher> If you found a way to reverse SHA you could get she source from that. :)
16:59:01 <tibbs> But this would be down to even giving you something to put in for your Source: URL.
16:59:17 <tibbs> Though probably not automatically adding it to the spec for you.
16:59:52 <tibbs> In any case, the important port there is that external tooling like spectool or fedpkg would learn how to deal with it.  It wouldn't save too much in the spec itself.
17:00:13 <tibbs> And for that we really do have to say: Include this line, and tools will do the work.
17:00:29 <tibbs> But, anyway, I'm off onto things I will probably never have the time to actually implement.
17:00:47 <geppetto> :)
17:00:59 <tibbs> Well, not completely.
17:01:05 * geppetto orders some roudtuits on amazon, shipped to tibbs
17:01:22 * Rathann looks that up
17:01:31 <tibbs> In the cleanup I'm going to go ahead and see how the simplified date.hash/rev thing looks.
17:01:32 <limburgher> roundtuits
17:01:58 <tibbs> Rathann: There's a common phrase "get around to it" which means finding the time to actually work on something.
17:02:03 <Rathann> ahh
17:02:19 <tibbs> So if you don't have enough round tuits, then you can't ever get any work done.
17:03:07 <tibbs> If we like the way that looks, then we can go with it then; otherwise I'll switch to something else.
17:03:21 <tibbs> (and yes, I'll exempt cvs).
17:03:30 <geppetto> tibbs: seems fine to me
17:03:52 <tibbs> I hope folks will read the parts of that thing I've written so far and let me know what's wrong with it.
17:05:13 <geppetto> tibbs: I read all of the simple versioning, and the intro. to complicated … and it all seemed fine
17:05:27 <geppetto> tibbs: but it's mostly just moving things around right?
17:05:51 <tibbs> Well, actually... those two sections are completely new.
17:06:08 <tibbs> The history starts with the original document if you want to diff.
17:06:18 <geppetto> Yeh, I meant after those bits :)
17:06:33 <tibbs> Oh, right, I haven't really done anything further down yet.
17:07:04 <tibbs> But the plan is to simplify it to just prerelease and postrelease and put the checkout naming at the bottom.
17:07:21 <tibbs> And try to make the examples as clean as I can get them.
17:07:37 <tibbs> Maybe collapsed, maybe in a separate document.  I'll have to try a few things to see how it looks.
17:07:46 * geppetto nods … sounds good … although moving stuff around will break diff. … but we can do it manually in our heads
17:08:16 <tibbs> That's why I'm trying not to change policy.
17:08:21 * geppetto nods
17:09:34 <tibbs> So you can "trust" that all you need to decide is whether the document is pretty and clean enough, not whether all of the random policy changes I made are also good.
17:09:53 <geppetto> Yeh
17:09:58 <tibbs> But of course that's hard if the policy is contradictory or wasn't well-designed.
17:10:07 <tibbs> Anyway, I guess that's enough of that.
17:10:22 <geppetto> :)
17:10:25 <geppetto> #topic #654     glibc file triggers
17:10:29 <geppetto> .fpc 654
17:10:30 <zodbot> geppetto: #654 (glibc file triggers) – fpc - https://fedorahosted.org/fpc/ticket/654
17:10:33 <tibbs> There was motion here.
17:10:40 <tibbs> I think there's agreement on what needs to happen.
17:10:49 <geppetto> yeh
17:10:53 <tibbs> From the glibc people.
17:11:06 <tibbs> I've basically volunteered us to do all of the actual work.
17:11:18 <limburgher> Yissss.
17:11:18 <tibbs> The important link is https://bugzilla.redhat.com/show_bug.cgi?id=1380878
17:11:38 <geppetto> yeh, I didn't comment again … but I'm basically +1 on your last two comments
17:11:46 <tibbs> But I don't know how to detect the "missing symlinks" thing.
17:11:54 <tibbs> If I knew how, I'd write the code today.
17:12:11 <tibbs> Also, what's this symdb thing they keep talking about?
17:12:23 <tibbs> And how do I access it?
17:12:28 <geppetto> I _think_ that's an internal tool
17:12:32 <tibbs> Oh, of course.
17:12:42 <geppetto> but maybe you can get access to it
17:12:51 <geppetto> I had never heard of it before
17:14:25 <tibbs> It sounds like they have it running over all of Fedora, and if so then it would be weird for Fedora not to have the means to run it.  But I'm just guessing.
17:14:36 <geppetto> I also think that the "seeing if symlinks are there is basically what ldconfig does"
17:15:16 <geppetto> So it might be viable to have a ldconfig --dry-run or something, which does nothing but have a 1/0 return value on if it would create a symlink if run without that arg.
17:15:52 <tibbs> Except that I'm not entirely sure that there aren't _other_ situations where ldconfig would make a symlink.
17:16:22 <geppetto> If so we'd want to ship those too anyway, right?
17:16:39 <tibbs> I honestly do not know.
17:16:43 <geppetto> :)
17:16:49 <tibbs> I'd really want to see an example of a broken package.
17:17:00 <tibbs> And how the packager would fix it.
17:17:17 <tibbs> And then set things up to detect that case.
17:17:58 <tibbs> I really am offering to do 100% of the work, including the actual glibc package changes, but I need to know how to do this one thing.
17:18:15 <tibbs> Anyway, its oinly been two days so I'm not going to complain about them not telling me yet.
17:18:17 <geppetto> Given the proposed change … I'm 99% sure the testcase is … if ldconfig creates any symlinks, those should be in a package.
17:19:01 <tibbs> So, looking at my system, whatever owns /usr/lib64/libwbclient.so.0 is not properly packaged, for example.
17:19:02 <geppetto> yeh, I will try to remember to ping them if they haven't replied by Monday
17:19:23 <geppetto> yeh
17:19:28 <limburgher> I hope it's more elegant than diffing two runs of find -type l . . .
17:20:10 <geppetto> libwbclient-4.4.6-1.fc24.x86_64 here
17:20:34 <geppetto> limburgher: yeh, that's why I suggested someone adding a --dry-run to ldconfig itself
17:21:31 <geppetto> tibbs: Running the rpm -qf thing here produced a few things that all looked like errors/problems to me
17:21:53 <tibbs> But now you're gating the work on having more glibc changes, and I have no idea how long that might take.
17:22:13 <geppetto> tibbs: but still a very small number given the number of libraries we have … and they were all doing something a bit strange, so it looked like all the normal cases were just correct.
17:22:16 <tibbs> But I guess we're not in a hurry or anything; it's just that I actually have the whole thing in my head currently.
17:22:42 * geppetto nods … I'm just hoping that adding a --dry-run would be easy to get into glibc
17:22:55 <geppetto> And I can't think of an easy way to do it without that
17:23:05 <tibbs> Note that we have binutils available.
17:23:25 <tibbs> Since it's a dependency of rpm-build.  So there might be something in there that's useful as well.
17:23:40 <geppetto> But then I'm also mostly happy to ship it without QA
17:24:03 <tibbs> Anyway, I was hoping you knew how to do it.
17:24:09 <tibbs> Bedcause then I'd just do it.
17:24:21 <geppetto> tibbs: Maybe. I know I looked at ldd a few years ago and there was a huge amount of logic inside glibc, that was private
17:24:31 <geppetto> tibbs: ldconfig might not be the same though
17:24:43 <tibbs> But I can probably do some fun things with ldconfig -r %buildroot
17:25:03 <tibbs> I mean, if you run that and it creates symlinks, then they'll appear as unpackaged files and your package won't build.
17:25:16 <tibbs> Unless you tweaked the magic setting to turn that check off as well.
17:26:00 <geppetto> oooh, that's true
17:26:26 <tibbs> But if that's really all it is, then I can make something work.
17:26:39 <geppetto> Yeh, just ldconfig -r -N might be enough
17:27:06 <tibbs> I guess I need to look into the ldconfig source.
17:27:22 <tibbs> It does have an -X option, so...
17:27:32 <tibbs> but still, finding a broken package and knowing the fix would be good.
17:27:50 <geppetto> yeh, I'm 99% sure that adding a --dry-run option would be easy
17:29:46 <tibbs> Wow, we have libraries using the alternatives system?
17:29:57 <tibbs> lrwxrwxrwx. 1 root root 40 Sep 29 14:48 /usr/lib64/libwbclient.so.0.12 -> /etc/alternatives/libwbclient.so.0.12-64*
17:30:03 <geppetto> Yeh, I saw
17:30:05 <tibbs> I had no idea that even worked.
17:30:24 <tibbs> I also have no idea whether that gets in the way of this ldconfig thing.
17:30:45 <tibbs> Oh, also, what am I missing about packages which add to /etc/ld.so.conf.d?
17:31:01 <tibbs> Why can't a %filetriggerin/postun pair take care of that?
17:31:12 <geppetto> I don't know
17:31:19 <Rathann> if they have compatible ABI then it should work
17:31:32 <geppetto> I think they were confused between filetriggerin and transfiletriggerin
17:31:43 <tibbs> I mean, it's far less important, sure, but either I've burned up all my capital with them and they're ignoring me, or I'm being so stupid that they're just not going to answer.
17:31:53 <geppetto> And were saying you couldn't wait until transfiletriggerin for the .conf changes.
17:32:17 <geppetto> But I may also be missing something
17:32:43 <tibbs> Well I can play with running ldconfig in __os_install_post to detect problems.
17:33:06 * geppetto nods
17:33:23 <geppetto> Ok, that's probalby it for that this week
17:33:28 <geppetto> Is there anything else?
17:33:46 <tibbs> I'm certainly out.
17:34:44 <limburgher> Not here.
17:35:40 <tomspur> Unfortunately, due to switching jobs and finding less and less time to work on issues and attend the meetings, I need to leave the FPC.
17:35:55 <tibbs> Damn, that's too bad.
17:36:02 <tibbs> And we still have so much python work to do....
17:36:03 * limburgher :(
17:36:07 <tomspur> My current commuting time from work back home is right in the meeting with an instable internet connection on the way.
17:36:17 <limburgher> Ick.
17:36:23 <tibbs> We could consider moving the meeting.  Would that help?
17:36:33 <tomspur> So I could help with the python stuff, but not taking part at the meetings or only at the end?
17:36:58 <tomspur> I can be 45 mins late or we move it one hour later?
17:37:13 <tibbs> Note that we're about to have a DST change anyway.
17:37:45 <tibbs> So everything's about to get screwed up for someone.  Personally I don't care; I will do what I can to make time, and for me this is right in the middle of the day.
17:37:45 <tomspur> I still remember the last daylight saving where we constantly had problems to find a new time
17:38:21 <geppetto> Yeh, I can do one hour later fine … but I think Rathann and racor have problems
17:38:30 <tomspur> Yes, I think so too
17:39:00 <Rathann> we have DST change in 10 days in Europe
17:39:01 <geppetto> #topic Open Floor
17:39:09 <racor> geppetto: yep. 1 hr later won't work for me.
17:39:16 <tomspur> We can try to do the python stuff at the end of the meetings and I skip the beginning?
17:39:42 <limburgher> We can just make sure to discuss tildes first, and that will happen organically. ;)
17:39:52 <tomspur> If it doesn't work out, I can still leave FPC in a few weeks
17:40:53 <geppetto> Sure, it can't hurt
17:41:26 <limburgher> That way we have a shot at retaining you.
17:41:42 <tibbs> tomspur: I don't mind; and of course you can always add info to tickets.
17:42:10 <tibbs> BTW, if you do have an opinion about the tilde in version thing, it would be great to hear your thoughts.
17:44:53 <tomspur> tibbs: I don't have a strong opinion on the tilde thing. I think it is quite confusing and breaking our old version styles (can be good can be bad)
17:46:12 <tomspur> I think adding a +/-1 on a ticket if there is one vote left can work fine. But only to gather new feedback/opinions I can try to do so also when not being part of FPC
17:47:09 <tomspur> So I'd prefer to directly take part at the meeting or leaving "officially" (I can still comment on the tickets anyway)
17:47:36 <tibbs> It's up to you, I think.  I doubt anyone here would pressure you to leave.
17:48:23 <tomspur> ok, then let's try, when I'm always late for the meetings, if that's fine for all of you
17:48:38 <geppetto> Sure :)
17:51:37 <tomspur> ok, great
17:51:41 <tibbs> I can be late, too.
17:51:54 <tibbs> Lately we've been doing two hour meetings pretty regularly.
17:52:35 <geppetto> yeh, I changed the calendar a few weeks back
17:52:46 <tibbs> Which misses racor at the end, sadly.  I think we all know there's no proper solution to this problem besides curing tiredness.
17:53:03 <geppetto> everyone wins the lottery?
17:54:25 <geppetto> ok, on that hopeful note I shall end the meeting :)
17:54:45 <tibbs> If I won the lottery I'd probably be here just about as much as I am now.
17:55:12 <limburgher> Me too.
17:55:30 <limburgher> I mean, Fedora would still be paying my just as much as now. . .
17:55:33 <limburgher> me
17:55:39 <geppetto> :)
17:55:51 <geppetto> #endmeeting