15:00:46 <spot> #startmeeting Fedora Packaging Committee
15:00:46 <zodbot> Meeting started Wed Nov 23 15:00:46 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:50 <spot> #meetingname fpc
15:00:50 <zodbot> The meeting name has been set to 'fpc'
15:00:59 <spot> #topic Roll Call (gobble gobble)
15:01:14 * limburgher is here, running to get coffee back in literally like 2 minutes.
15:02:45 <spot> geppetto, tibbs|h, rdieter, SmootherFrOgZ: ping ?
15:03:12 <rdieter> hi ( limburgher has killer idea, ditto)
15:03:25 * gomix lurking :)
15:03:59 <tibbs|h> Oh, wasn't sure we were going to try and meet today.
15:04:25 <spot> well, if we don't have quorum, i suppose we won't. :)
15:05:03 <limburgher> rdieter: The spiece must flow.
15:05:10 <limburgher> s/spiece/spice/
15:05:13 <rdieter> slurp
15:05:28 * geppetto is here
15:06:35 <tibbs|h> The Dr. Pepper must flow.
15:06:45 <spot> so, i see limburgher, rdieter, geppetto, tibbs, and racor.
15:07:01 <spot> so that's 6 of us.
15:07:31 <spot> #topic SHOULD for ipv6 - https://fedorahosted.org/fpc/ticket/116
15:07:31 <limburgher> tibbs|h: Oh, certainly, but after lunch.
15:08:13 <limburgher> WRT Dr. P, not ipv6, BTW.
15:08:20 <spot> yeah. ;)
15:08:28 <limburgher> I think ipv6 before lunch is perfectly acceptable.
15:08:46 <spot> so, i have a bad taste in my mouth about having this be a passive/aggressive SHOULD
15:09:12 <limburgher> Do you have an alternative to suggest?
15:09:25 <spot> but i don't know that this should be a MUST, and if it gets people to enable ipv6 when they otherwise wouldn't...
15:09:36 <spot> I almost want to say that it should be a MUST
15:10:10 <limburgher> Its not like the service'll be enabled by default.  You'll have ipv4 and ipv6 off by default, instead of just ipv4 off by deafult.
15:10:15 <limburgher> MUST makes sense.
15:10:16 <spot> "If an application natively supports both ipv4 and ipv6, support for ipv4 and ipv6 must be enabled in the Fedora package."
15:10:19 <tibbs|h> Can't say I disagree, though who knows, there may be some problem with some package when ipv6 is enabled.
15:10:37 <spot> tibbs|h: yeah, but that falls into the (if the guideline can
15:10:40 <rdieter> spot: yes, but my spidey-sense tingles that smells more like policy fesco should be deciding, rather than a packaging guideline, no?
15:10:45 <limburgher> tibbs|h:  I can't think of a case where that wouldn't merit an upstream BZ.
15:10:49 <spot> tibbs|h: yeah, but that falls into the (if the guideline can't be met for legit technical reasons)..."
15:11:00 <geppetto> spot: I think some clarification on wording might be better … I don't want people enabling beta ipv6 support, just because they think they have to.
15:11:07 <abadger1999> hey
15:11:15 <spot> geppetto: that is a good point
15:11:16 <limburgher> You mean like some sort of ipv6 exceptions  list?
15:11:19 <geppetto> And ipv6 has what, 3 users?
15:11:52 <spot> "If an application contains native and stable support for both ipv4 and ipv6, support for ipv4 and ipv6 must be enabled in the Fedora package."
15:11:55 <limburgher> geppetto:  I have a tunnel I don't use, thanks fly-by-night ISP that doesn't support it.
15:12:02 <limburgher> *COUGH*AT&T*COUGH*
15:12:11 <geppetto> limburgher: So that's 3.5 users then ?;)
15:12:13 <limburgher> spot: +1 to adding stable
15:12:21 <tibbs|h> So, basically, this guideline is to force a resolution to https://bugzilla.redhat.com/show_bug.cgi?id=450853
15:12:26 <limburgher> geppetto: ;)
15:12:37 <tibbs|h> even though the "technical reasons" exemption just might apply?
15:12:38 <spot> rdieter: i hear you about this being FESCo's call though.
15:13:11 <rdieter> not that I mind pushing this (aka common sense) where we can get away with it
15:13:31 * spot is happy to toss this to fesco, with proposed wording even.
15:13:34 <geppetto> "If an application contains native and stable support for both ipv4 and ipv6, and support for ipv6 does not negatively affect ipv4 then both must be enabled in the Fedora package."
15:13:36 <limburgher> vsftpd is major, high quality software, and having it support ipv6 out of the box helps both ipv6 and Fedora
15:13:58 <spot> geppetto: sounds fine to me.
15:14:05 <rdieter> geppetto: +1
15:14:09 <tibbs|h> I'm pretty sure that FESCo already decided that complete ipv6 support was a goal.
15:14:16 <abadger1999> I don't know -- I know we tossed this to fesco last time but it does seem like a packaging guideline.
15:14:17 <spot> nirik: around?
15:14:20 <rdieter> tibbs|h: worksforme
15:14:35 <nirik> yeah, I think we were all in general for ipv6 where it doesn't break ipv4.
15:14:58 <spot> okay then.
15:15:10 * nirik is fine with geppetto's idea, FWIW...although it does read a bit long. ;)
15:15:17 <spot> lets just vote on it on those grounds. I propose geppetto's wording.
15:15:22 <spot> +1
15:15:24 <rdieter> +1
15:15:25 <tibbs|h> +1
15:15:30 <racor> I thought we had a rule of "all non-ipv6 packages will have to die" rule effective since Fedora #0
15:15:30 <geppetto> +1, obv. :)
15:15:33 <limburgher> +1
15:15:42 <abadger1999> +1
15:15:45 <spot> racor: perhaps, but no one wrote it down until...
15:15:55 <tibbs|h> Though when we write this up, we should take care to refer to any previous FESCo decision about this.
15:16:04 <nirik> there was a bugtracker/bugs filed a long time ago for 'you should support ipv6' on a bunch of things.
15:16:30 <racor> => -1, having ipv6 is a must, these days.
15:16:40 <nirik> but in many cases thats really an upstream feature add, not something a fedora maintainer should patch/code in.
15:16:47 <spot> racor: umm, it is worded as a must
15:17:08 <limburgher> Maybe MUSTMUST?
15:17:19 <geppetto> spot: I think he means with no exceptions … but, as nirik said…
15:17:23 <racor> spot: I thought we were voting on "ipv6 if no negative impact on ipv4"?
15:17:30 <spot> racor: yes, that is true.
15:17:31 <racor> this is to weak for me.
15:17:35 <limburgher> nirik:  I think this wording is good for that, it doesn't make me hack in 6 support where it isn't already.
15:17:35 <spot> racor: okay.
15:17:45 <nirik> limburgher: yeah.
15:17:58 <spot> #action Revised proposal approved (+1:6, 0:0, -1:1)
15:17:59 <racor> my standpoint: packages without ipv6 will have to be removed
15:18:20 <limburgher> racor:  When, and do you have examples?
15:19:24 <racor> limburgher: ASAP. No I don't have an example, but I thought is the case this proposal is explicitly addressing.
15:19:55 <racor> "If negative impact on ipv4, disabling ipv6 is allowed"
15:21:21 <limburgher> How about a grace period, where an upstream bug is filed, and then dropping the package after X time without a response, or if the answer is no?
15:21:34 * abadger1999 notes he'd still be +1 if some of the caveats were removed from the guideline
15:21:42 <tibbs|h> I don't see why we'd be dropping packages.
15:22:28 <abadger1999> I think that fesco would be dropping packages.
15:22:37 <tibbs|h> Well, even then.
15:22:44 <abadger1999> and they could drop any packages they want for guidelines violations.
15:22:48 <tibbs|h> But look, let's tighten things down gradually.
15:22:57 <abadger1999> really all we're doing is backing up people who want to open bugs.
15:23:07 * SmootherFrOgZ finally here
15:23:08 <limburgher> Right.  I see no rush.
15:23:29 <tibbs|h> The bugs should still be opened, and they now have to make a technical argument if they wish to not comply.
15:23:42 <abadger1999> tibbs|h: +1
15:23:44 <tibbs|h> And that gives us a set of packages to consider the next time we want to tighten the rule.
15:25:16 <abadger1999> racor: If you'd like to make a revised, stricter proposal we can vote on it.
15:25:40 <abadger1999> My line is forcing a packager to provide ipv6 if upstream does not.
15:25:47 <geppetto> Yeh, I don't see a problem with people opened bugs … but I don't see any point in people making things worse just so we can say "the entire package set is ipv6".
15:25:57 <abadger1999> I'll vote for the guideline with or without any of the other caveats.
15:26:26 <abadger1999> but i won't vote for the guideline without that caveat.
15:26:48 <limburgher> abadger1999: Right.  That's nuts.  Most people aren't qualified to write that code.
15:27:29 <limburgher> geppetto: Agreed.  Especially if flagship things like httpd, bind, sendmail, postfix, do.
15:30:09 <abadger1999> racor: so... could you make a proposal?  Otherwise, we'll just go with what we've approved.
15:30:14 <racor> abadger1999: Well I feel this proposal is weakening Fedora and opens room to letting pass though ipv6 disabled packages. Provided ISPs are switching to ipv6 in large numbers, such step are inappropriate, these days.
15:30:24 <abadger1999> Sure
15:30:32 <tibbs|h> Wait, this is weaker than what we have now, which is nothing?
15:30:39 <abadger1999> racor: So make a counter proposal, please,
15:31:33 <racor> tibb|h: we had (written or unwritten, I don't know) rule condensing to "all packages must support ipv6 and  have it enabled"
15:31:49 <tibbs|h> Erm, no.
15:31:56 <rdieter> unwritten, it seems
15:32:28 <limburgher> Ergo, this is stronger.
15:32:56 <abadger1999> unwritten, but I think it's more like what nirik had in the original request (except a must): If an application supports both ipv4 and ipv6, that support must be enabled in the Fedora package.
15:34:26 * spot is waiting for any other proposals
15:34:38 <geppetto> racor: Do you want to propose different wording, and we can vote … or just leave it as what we've voted on?
15:34:43 <spot> personally, i'm inclined to leave what we approved alone, but i'm happy to consider others.
15:35:11 <rsc> ...no clue which meeting that is and if I'm allowed to suggest...but I would prefer that applications that support both must be compiled/build/... that way in Fedora to support both, too.
15:35:12 <racor> Leave it for now. but I am willing to investigate ... this topic ranges back to the very beginnings of Fedora.
15:35:34 <limburgher> rsc:  That's essentially what we've just done.
15:35:42 <abadger1999> rsc: You are allowed to suggest, just not vote.  (Fedora Packaging Comittee meeting)
15:35:51 <spot> racor: okay, feel free to bring this up at a later point if you want to suggest a change.
15:35:53 <tibbs|h> I'm inclined to revisit the issue in a release or two when hopefully someone has a more complete list of which packages would be affected by a stricter rule.
15:36:14 <spot> Lets move on to the next landmine in our queue
15:36:45 <spot> #topic /usr move - https://fedorahosted.org/fpc/ticket/118
15:37:32 <spot> honestly, i still fail to see the value in this change, aside from introducing odd bugs, but fesco approved it, so we need to figure out how to change the guidelines
15:38:12 <spot> the feature page says: "Change the ~260 RPM packages with files in /bin, /sbin, /lib, /lib64 to install into /usr, and add Conflicts: filesystem < 3. "
15:38:38 <spot> So, there is an implication that we should not permit new packages to install files into /bin, /sbin, /lib, or /lib64.
15:38:54 <limburgher> I'm with spot, I see no benefit.  What is "cleaner"?  It seems like this is a job for a PATH setting in your bash config. . .
15:39:00 <tibbs|h> Personally I'd be happy to get back to being able to use a separate /usr partition, but I still don't get why all of this is necessary to get that.
15:39:32 <limburgher> tibbs|h:  My reading was that this say that's never going to work again, so let's do this thing.
15:39:37 <abadger1999> tibbs|h: Right, it seems from the Feature that separate /usr is possible with the initramfs which isn't new to the feature.
15:39:42 <geppetto> Yeh … apart from adding wording saying "you must not put a file of the same name in /bin and /usr/bin … do we have to do anything?
15:39:53 <tibbs|h> abadger1999: Indeed, that was my real problem with all of this.
15:40:18 <jsmith> my problem too, to be honest
15:40:20 <nirik> well, I would like to know if there are any parts of this FPC feels break standards or should be avoided.
15:40:20 <haraldh> I would recommend: " not permit new packages to install files into /bin, /sbin, /lib, or /lib64."
15:40:29 <limburgher> "less toplevel directories"  Is this seriously a common end-user complaint?
15:40:33 <abadger1999> So doesn't seem like there's much compelling in the feature.  Thatsaid, I think moving to /usr is okay acording to FHS but merging bin and sbin is not.
15:40:40 <spot> I hesitate to even bring this up, but i suppose we could toss this back to fesco and ask for some sort of technical rational.
15:40:45 <spot> rationale, rather.
15:40:53 <tibbs|h> I don't see the point.
15:40:53 <haraldh> abadger1999, we removed the sbin/bin merge
15:40:53 <mjg59> spot: The rationale is in the feature page
15:40:57 <geppetto> abadger1999: AIUI the merging of sbin and bin is not part of this
15:40:57 <mjg59> spot: And we agreed
15:41:06 <spot> mjg59: "cleanliness" is not a technical reason, sir. ;)
15:41:08 <tibbs|h> I mean, I don't see the point in asking for rationale.
15:41:16 <nirik> mjg59: you mean a majority agreed. ;)
15:41:28 <abadger1999> haraldh: Ah Excellent.
15:41:31 <tibbs|h> I mean, the guidelines changes seem simple.  Packages can't put stuff in several directories and should use /usr/whatever instead.
15:41:45 <limburgher> spot: +1
15:42:02 <limburgher> Agreed, they're clear changes, but. . .why?
15:42:07 <mjg59> spot: The FAQ has a large number of technical points
15:42:15 <tibbs|h> Is that really relevant to our discussion?
15:42:17 <abadger1999> haraldh: What's stopping the migration script from being implemented in lua and put in filesystem's scriptlet instead of just a warning?
15:42:19 <spot> i read the FHS and it is worded loosely enough that I think it permits this behavior.
15:42:44 <haraldh> abadger1999, it's a little bit more complex to make it failsafe
15:42:47 <tibbs|h> We can go back and forth with FESCo asking them "why?" to everything, but our function isn't to hold up decisions that they want to implement.
15:42:47 <mjg59> nirik: Well, yeah, but that's true of a large number of cases where we approve things :)
15:42:54 <haraldh> abadger1999, can't be simply done in lua
15:43:00 <limburgher> tibbs|h: True.
15:43:02 <tibbs|h> It's to modify the guidelines to follow suit with the technical decisions they make.
15:43:19 <spot> tibbs|h: a valid point.
15:43:29 <tibbs|h> So, are there any FHS issues with this?
15:43:51 <haraldh> I can't see any with the sbin/bin merge removed
15:43:54 <tibbs|h> It does mandate varios things in /bin.
15:43:54 <abadger1999> haraldh: Okay -- however, at our level, we try (and in fact, thus far have never) done things that rely on things outside packaging to work.
15:43:54 <spot> tibbs|h: i do not believe so, assuming that the hierarchy of /bin, /sbin, /lib* never goes away.
15:44:01 <limburgher> No more than with adding sbin to the default PATH
15:44:12 <abadger1999> haraldh: I don't see the migration script attached, do you have it handy?
15:44:14 <tibbs|h> It does not explicitly say that /bin cannot be a symlink.
15:44:20 <spot> the magic script worries me, i think it will break rpm -V
15:44:27 <tibbs|h> It does explicitly say that things in /bin can be symlinks.
15:44:39 <limburgher> Thus allowing busybox.
15:45:04 <tibbs|h> Sorry, it does explicibly allow /bin or the other top level directories to be symlinks.
15:45:16 <spot> tibbs|h: yeah, everything (dirs and files) can be symlinks
15:45:23 <haraldh> abadger1999, https://docs.google.com/document/pub?id=1FoEr07UPOz4mVoEsIDGbwa81YGq4vucUAYa8DdgI47k
15:45:25 <tibbs|h> So... probably no FHS issues here.
15:45:52 <abadger1999> right.
15:45:56 <abadger1999> that was my reading
15:46:20 <tibbs|h> To be honest I have no particular issues with any of this.
15:46:27 <spot> Do we want this "no /bin|/sbin/lib*" to apply to all packages, or just new ones?
15:46:58 <tibbs|h> To be honest, that's never been something we've considered in the past.
15:46:59 <SmootherFrOgZ> If we do have to go with something for guideline, just new ones
15:47:05 <haraldh> spot, we have spec file patches for the old ones
15:47:11 <tibbs|h> Since there's no enforcement of guidelines except at new package time.
15:47:35 <spot> tibbs|h: we have given consideration for existing packages on major changes before
15:47:38 <geppetto> spot: If we want to be "nice" to older packages … we could say "nothing should put stuff in /bin (etc.) and nothing must put something of the same name in /bin and /usr/bin"
15:47:44 <abadger1999> $ rpm -V tcsh                                                                                                                                                                                                (07:47:32):1033
15:47:45 <abadger1999> ....L....    /bin/tcsh
15:47:49 <tibbs|h> I need to read up on how this works around rpm's problems with turing directories into symlinks.
15:47:57 <abadger1999> spot: So I confirm your complaint that it will break rpm -V
15:48:11 <abadger1999> Actually....
15:48:14 <geppetto> abadger1999: rpm does that when /bin is a symlink?
15:48:17 * abadger1999 not testing the right thing
15:48:22 <abadger1999> geppetto: yeah
15:48:22 <limburgher> tibbs|h:  Pour yourself something strong first.  See gallery2.
15:48:27 * abadger1999 checks that situation
15:48:40 <rdieter> limburgher: ++
15:48:58 <geppetto> Interesting … pretty sure yum verify will be fine, and I don't see how rpm could be unhappy
15:48:59 <limburgher> rdieter:  I *knew* you'd say that. :)))
15:49:18 <tibbs|h> Oh, my.
15:49:29 <haraldh> I am doing a local mock rebuild for the 402 fedora packages currently, which have files in /lib* /bin or /sbin
15:49:41 <haraldh> We changed all the specfiles :)
15:50:01 <geppetto> haraldh: See notting's last comment on: https://fedorahosted.org/fesco/ticket/690
15:50:10 <haraldh> this includes moving /lib/systemd and /lib/udevd to /usr
15:50:30 <haraldh> we really want "rpm -V" to report the correct thing
15:50:37 <tibbs|h> Have to step away for a few minutes.
15:50:45 <abadger1999> spot: Okay, so rpm -V should *not* be a problem --   Tested by: mv /root to /usr/root  && ln -s /usr/root / && rpm -V rootfiles
15:50:48 * spot would prefer that we A) migrate all packages to the new layout for f17+ B) have anaconda setup the symlink layout for new installs C) Provide an optional script for users to manually run if they wish to change to the new layout from an old install.and D) Update all the rpm macros to stop using the deprecated directories.
15:51:06 <haraldh> or "rpm -qf"
15:51:34 <pingou> abadger1999: rpm -ql works fine to ?
15:51:45 <haraldh> B) is already set with the new "filesystem" package
15:51:56 <pingou> (for this you'll need a modified rpm I guess)
15:51:57 <geppetto> spot: AIUI they are forcing the manual run of the script … so no yum updates, but I'm not sure any of that has anything to do with us as such
15:52:10 <spot> i suppose it does not
15:52:13 <haraldh> http://harald.fedorapeople.org/downloads/usrmove/filesystem-usrmove.patch
15:52:14 <geppetto> spot: I guess if you want A, then we should change the wording to must now
15:52:23 <abadger1999> pingou: for some definition of fine -- ie rpm's behaviour has always been to use a path when it makes that list whether or not parts of the path are symlinks
15:52:32 <spot> geppetto: i think that's all we can do.
15:52:39 <abadger1999> pingou: /etc/init.d vs /etc/rc.d/init.d was one of those in the past.
15:53:07 <limburgher> geppetto:  Meaning we're breaking yum update from f16->f17?
15:53:12 <geppetto> Personally I'd prefer to let packages install into /bin until F17 dies … but it's not the end of the world if you'd rather they all migrate now.
15:53:28 <geppetto> limburgher: Yes
15:53:40 <geppetto> limburgher: anaconda and preupgrade will have special logic.
15:53:42 <limburgher> geppetto:  Not.  Happy.
15:54:05 * spot does not like this proposal a lot. a ton of pain, package changes, and we get... i'm still not sure what.
15:54:26 <limburgher> geppetto: Will we have this logic posted somewhere so those of use who yum update for distro upgrades can manually do the needful?
15:54:43 <limburgher> spot: +1
15:54:53 <abadger1999> geppetto: well....it sorta does concern us as traditionally, we tell people who want to special case things to be run by anaconda -- you must do it in packaging instead.
15:54:53 <spot> geppetto: is there any chance we can make a yum plugin to handle this "feature" ?
15:54:54 <tibbs|h> Back.
15:55:43 <abadger1999> Is pjones still one of the anaconda maintainers?
15:55:49 <spot> abadger1999: yes
15:55:52 <geppetto> spot: Not entirely obvious … in theory I guess
15:55:53 <abadger1999> and was he one of the +1 or -1 in fesco?
15:56:15 <haraldh> +1
15:56:26 <spot> geppetto: it seems like something that is worth doing as part of this feature.
15:56:33 <limburgher> spot: +50
15:56:41 <abadger1999> at least part of our traditional "You must do it in packaging" was because the anaconda team didn't want special cases in their code.
15:57:08 <abadger1999> so if he's on board, that particular argument would have less merit to me.
15:57:20 * spot also knows this is going to break for out of distro packages, the nvidia driver immediately comes to mind
15:57:35 <spot> which is outside of FPC scope, but still
15:57:36 <geppetto> spot: One problem is that we'll need to get the plugin onto everyone's system
15:57:38 <haraldh> the anaconda part is easier than our script, because root is not used
15:57:38 <abadger1999> spot: with the symlinks?
15:58:03 <limburgher> geppetto:  If only there were a way to Require it. :)
15:58:04 <spot> abadger1999: maybe. i don't know.
15:58:12 <abadger1999> hmm.. looking through the fesco log I realize that the fesco vote came before the script.
15:58:15 <geppetto> spot: If you want it to happen automatically, then the script should be called from filesystem's %pre …
15:58:45 <limburgher> geppetto:  Assuming there's no case in which you wouldn't want it to run, +1.
15:58:47 <geppetto> limburgher: Having deps. like "before you run the transaction, run this other transaction" … would get interesting _fast_ :)
15:58:47 <tibbs|h> That script couldn't call much.
15:58:48 <spot> geppetto: have the filesystem package which introduces the changes run a trigger to check for yum, and if present, install the plugin
15:58:57 * spot feels dirty for having even written that
15:59:05 <spot> but we're up to our necks in dirt as is.
15:59:20 <geppetto> spot: But then it'd need to restart yum
15:59:31 <geppetto> It's just so much fail.
15:59:36 <abadger1999> ie notting is the only one that voted on the final upgrade plan
15:59:36 <geppetto> So. So. Much.
15:59:40 <limburgher> geppetto: We tell people to update yum first anyway.
15:59:49 <haraldh> just don't do it from inside an rpm transaction
16:00:01 <pingou> limburgher: doesn't mean they all do :/
16:00:02 <geppetto> limburgher: How is that different to telling them to run some magic filesystem upgrade script?
16:00:04 <abadger1999> haraldh: your migration script.  When can it be run?
16:00:17 <spot> geppetto: yeah, i think if we have the plugin, and we have a way for the transaction to not succeed if the plugin isn't installed & loaded...
16:00:22 <haraldh> abadger1999, before the user upgraded his system
16:00:27 <haraldh> abadger1999, before the user upgrades his system
16:00:37 <limburgher> pingou: True.
16:00:41 <abadger1999> haraldh: Looks like it uses programs in the directories it's moving so it can't run just anytime.... am I wrong?
16:00:42 <tibbs|h> I note that it's 16Z now.
16:01:04 <spot> i dont know if the FUDCon meeting moved with DST or not
16:01:16 <limburgher> geppetto:  It's not, materially.  Whether it's in a yum plugin or a %post script. . .
16:01:19 * abadger1999 notes that this time is too early for him.
16:01:20 * spot is assuming that any conflicting meeting will speak up and ask for the room.
16:01:26 <haraldh> abadger1999, inbetween it uses absolute paths
16:01:35 <limburgher> spot: Or read the log and run away. :)
16:01:40 <abadger1999> haraldh:         restorecon /$dir
16:01:43 * spot wishes he could. :/
16:01:57 <abadger1999> haraldh:   find -L /usr/{bin,sbin,lib,lib64} -type l
16:02:00 <abadger1999> haraldh: etc.
16:02:03 <haraldh> abadger1999, then the new symlink already exists
16:02:08 <spot> haraldh: have you accounted for the necessary selinux policy changes?
16:02:13 <geppetto> limburgher: %post is a lot better … can't be disabled etc. … I'm not sure why the script can't just be in %pre really
16:02:26 <haraldh> spot, not yet, but it's on the list
16:02:29 <geppetto> haraldh: Is there a reason you don't want to put the script in filesystem's %pre?
16:02:30 <limburgher> spot: FPC: Making sure potentially silly things are done properly. :)P
16:02:46 <limburgher> geppetto: Or %pretrans?
16:02:55 <haraldh> geppetto, can "filesystem" carry a script??
16:03:07 <geppetto> haraldh: It can carry a lua one.
16:03:29 <geppetto> Just not bash/etc.
16:03:38 <haraldh> that's all to fragile
16:03:55 <haraldh> you really want to double check
16:03:56 <tibbs|h> So what can we reasonably do here?
16:04:12 <tibbs|h> We can say that packages aren't allowed to put things in /bin etc.
16:04:20 <geppetto> haraldh: Almost nobody is going to double check, no matter what you do
16:04:26 <spot> tibbs|h: we can forbid files in /bin, /lib, /lib64, and /sbin.
16:04:35 <tibbs|h> Does FPC involvement end there?
16:04:39 <spot> s/files/files and directories/
16:04:45 <abadger1999> tibbs|h: I think we review the script as well.
16:04:50 <haraldh> geppetto, although we could lua.access("script") && lua.system("script") :-)
16:04:53 <geppetto> haraldh: Even if it's just anaconda/preupgrade … it's just going to run the script without the user looking at the result.
16:04:56 <limburgher> geppetto:  It would be best to assume the stupidest possible user, if the consequences are serious.
16:05:28 <tibbs|h> Can we get the forbidding part out of the way and at least accomplish something?
16:05:41 <tibbs|h> Was there a guideline draft already?
16:05:44 <abadger1999> I'd rather not
16:05:50 <abadger1999> no guideline draft
16:05:56 <abadger1999> and I mean -- this is kind of a package
16:06:12 <abadger1999> we wouldn't want forbidding if we're not satisfied with the rest of it going in.
16:06:37 * abadger1999 notes that we have some other tickets that seemed easier than this.
16:06:41 <tibbs|h> Indeed.
16:06:46 <abadger1999> maybe we should try and deal with those quickly.
16:06:50 <geppetto> abadger1999: As tibbs|h said, I don't see how we can stop it going in … for better or probably worse, it's going in
16:07:08 <geppetto> We just need to vote on the wording changes so the packagers know what to do.
16:07:25 <tibbs|h> But I note that after punting on systemd migration, it's not as if we've just gone ahead without solving complicated distro-upgrade-related issues.
16:07:42 <spot> "To keep the filesystem layout clean and sparkly, packages may no longer place files or directories in /bin, /sbin, /lib or /lib64. /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used instead. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, respectively."
16:07:59 <abadger1999> tibbs|h: We've explicitly said that we've decided the case isn't worthwhile though :-)
16:08:02 <haraldh> spot, nice
16:08:03 <pingou> spot | mjg59: "cleanliness" is not a technical reason, sir. ;)
16:08:14 <abadger1999> spot: eh.
16:08:19 <geppetto> spot: Need a bigger break between the / dirs. list and the /usr dirs. list.
16:08:22 <abadger1999> I don't like the rationale there.
16:08:34 <abadger1999> I'd certainly not vote for that in FPC based on that rationale.
16:08:39 <spot> abadger1999: i have yet to see any other rationale. going with what i can see.
16:08:43 <geppetto> spot: Maybe just adding "The directories" after the "." would be enough.
16:08:51 <haraldh> spot, although things can go wrong, if you don't follow the rules
16:08:55 <abadger1999> I'd rather leave all rationale out
16:08:57 <tibbs|h> The guideline doesn't need rationale.
16:09:07 <spot> okay, so perhaps I was trolling a bit.
16:09:11 <tibbs|h> It just needs to say "fedora does not use these directories; don't put things there."
16:09:13 <geppetto> It's more amusing witht eh rationale
16:09:16 <limburgher> spot: :)
16:09:22 <abadger1999> or say due to the fesco policy that [...]
16:09:23 <spot> "Fedora packages may no longer place files or directories in /bin, /sbin, /lib or /lib64. /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used instead. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, respectively."
16:09:32 <limburgher> /europa
16:10:00 <haraldh> "Fedora packages may no longer place files or directories in /bin, /sbin, /lib or /lib64. Instead /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, respectively.
16:10:07 <geppetto> spot: Again, add some words after "/lib64." so it's easier to see it's a "." and not a ",".
16:10:20 <spot> geppetto: ah, i see what you mean
16:10:37 <spot> "Fedora packages may no longer place files or directories in the /bin, /sbin, /lib or /lib64 directories. /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used instead. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, respectively."
16:10:38 <limburgher> " to the foo foo foo directories, respectively"
16:10:45 <haraldh> geppetto, like my version?
16:10:51 <limburgher> Second sentence, too.
16:11:00 <geppetto> haraldh: Yeh, yours or spot's last one is +1
16:11:15 <abadger1999> has anyone run repoquery to determine the set of filenames in /{bin,sbin.lib,lib64} vs /usr{bin,sbin,lib,lib64} ?
16:11:20 <abadger1999> haraldh: ^
16:11:24 <haraldh> yes
16:11:31 <spot> abadger1999: given that haraldh has patched specs, i would assume so. ;)
16:11:51 <tibbs|h> To be needlessly picky, "may no longer place [..]. directories in /bin" implies that it was OK before, when FHS always prohibited it.
16:11:54 <spot> i would think that we'd have seen namespace conflicts before now though.
16:11:58 <tibbs|h> But that's needlessly picky.
16:12:14 <spot> tibbs|h: yeah.
16:12:24 <spot> we could say something like:
16:12:31 <abadger1999> haraldh: What was the result?  (You can leave out consolehelper stuff as that's known).
16:12:38 <tibbs|h> If we end up not doing this for some reason, we should consider a guideline banning namespace conflicts anyway.
16:12:41 <abadger1999> or leave it in if that's easier
16:13:08 <spot> "Fedora packages MUST NOT place files or directories in the /bin, /sbin, /lib or /lib64 directories. Instead /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64, respectively.
16:13:12 <limburgher> tibbs|h: We could do that either way.
16:13:45 <tibbs|h> spot: +1.
16:13:47 <limburgher> "Fedora packages MUST NOT place files or directories in the /bin, /sbin, /lib or /lib64 directories. Instead /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 must be used. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories, respectively."
16:14:09 <spot> limburgher: sure.
16:14:18 <haraldh> abadger1999, you want the files? I only queried the src.rpms
16:14:38 <geppetto> Super pendant: The "and" in the second list of dris. should also be "or", I think
16:14:40 <limburgher> We should also have a comma after Instead, but I'm a grammar-nazi.
16:14:40 <spot> although, i think we can safely drop "Fedora" from that, since we know other efforts use our guidelines (RPMFusion, EPEL, Mandriva, Suse (a bit)"
16:14:43 <geppetto> But … meh, +1
16:14:50 <abadger1999> haraldh: hmm.. whatever list you have handy -- I just want to make sure the problem is as small as I'm assuming it is :-)
16:15:29 <spot> "Packages MUST NOT place files or directories in the /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories must be used. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories, respectively."
16:15:48 <limburgher> spot: +!
16:15:54 <limburgher> Or +1 even.
16:16:05 <tibbs|h> +1
16:16:22 <spot> A reluctant +1
16:16:22 <geppetto> +1 … just don't complain when bash installs itself into four directories ;)
16:16:36 <rdieter> +1
16:16:38 <abadger1999> I still want to see the whole thing.
16:16:46 <abadger1999> I can definitely +1 that as part of the package though
16:16:51 <tibbs|h> Sure, I guess this gives this our draft.
16:17:08 <spot> well, we can add this to the ticket and wait for any other FPC items that go with it
16:17:10 <tibbs|h> But someone's going to have to show what an upgrade looks like.
16:17:12 <Rathann> hi, sorry for being late
16:17:13 * spot isn't sure what those are yet...
16:17:16 <abadger1999> <nod>
16:17:41 <tibbs|h> Do we agree that the onus is on the feature owner to provide a reasonable upgrade path here?
16:17:49 <Rathann> change to winter time means I'm commuting around the beginning of the meeting
16:17:50 <abadger1999> Rathann: we're having a long discussion of https://fedorahosted.org/fesco/ticket/690  -- you'll probably need to read the logs.
16:17:51 <tibbs|h> And will we need to write that upgrade stuff up in the guidelines?
16:17:58 <spot> tibbs|h: including yum upgrades? yes...
16:18:14 <tibbs|h> Rathann: Note that we're nearly 80 minutes into the meeting.
16:18:21 <Rathann> huh?
16:18:26 <haraldh> abadger1999, http://harald.fedorapeople.org/Package-list-root.txt
16:18:32 <tibbs|h> Started at 1500UTC.
16:18:32 * Rathann is confused
16:18:34 <abadger1999> tibbs|h: we need to confirm it working.  I don't know if we need to write out the scripts.
16:18:44 * spot will send out a whenisgood
16:18:47 <tibbs|h> It's 16:18UTC now.
16:18:51 <abadger1999> spot: thanks.
16:19:17 <Rathann> hm I set the reminder on my phone using gmt and it said the meeting was now :(
16:19:23 <spot> i see +6 on that proposal.
16:19:28 * Rathann blames Google
16:19:35 <haraldh> geppetto, converted bash: http://fpaste.org/B7NZ/
16:19:44 <SmootherFrOgZ> +1 from me now
16:19:45 <spot> is anyone opposed to marking this item as approved, and hold off on deploying it pending other fpc issues on the same feature?
16:19:48 <abadger1999> haraldh: oh -- actually what I was meaning was -- what's the set of packages that have filenames that conflict between / and /usr
16:20:01 <haraldh> abadger1999, ah :)
16:20:10 <abadger1999> haraldh: Which I assume is vanishingly small.
16:20:19 <haraldh> abadger1999, yes, I tried to get that list, but did not yet
16:20:20 <abadger1999> haraldh: but it would be pretty bad if I was wrong :-)
16:20:29 <haraldh> yes, it's a lot smaller
16:20:38 <geppetto> haraldh: yes, it was somewhat humourus based on the word "and" in the proposal
16:20:57 <tibbs|h> spot: I don't object.
16:21:16 <abadger1999> spot: I'm fine with that -- haraldh is that okay with you?
16:21:32 <geppetto> spot: I'm fine with that too
16:21:34 <abadger1999> it means that you still don't get to push the changes into rawhide
16:22:10 <haraldh> which issues are pending?
16:22:27 <haraldh> but sure, we still need some time do test everything
16:22:30 <tibbs|h> The whole upgrade issue?
16:22:36 <haraldh> to make it a smooth upgrade :)
16:22:47 <tibbs|h> We need to see what it all looks like.
16:22:48 <haraldh> or "as smooth as it can get"
16:23:01 <haraldh> personally I plan to make a live-cd
16:23:07 <haraldh> and installer DVD
16:23:23 <haraldh> and provide a repo, where we can do test upgrades
16:23:29 <limburgher> And make sure yum update works.
16:23:33 <tibbs|h> I want to be able to install an F16 system, enable your repo, yum upgrade and have a working system afterwords.
16:23:33 <abadger1999> upgrade script review; how to make yum upgrades seamless (or not to make them seamless); someone needs to test that the upgrade will work ;
16:23:53 <tibbs|h> And then we need to write up what packagers need to do to make that possible.
16:23:55 <haraldh> limburgher, with the convert script running just before the yum upgrade, it works fine
16:24:00 <limburgher> tibbs|h: +50
16:24:06 <spot> abadger1999: these items should be listed as conditions on the feature, right?
16:24:12 <limburgher> haraldh:  Awesome.
16:24:30 <tibbs|h> Requiring the running of that script is the problem here.
16:24:30 <abadger1999> spot: so here's the thing -- those are things FPC has checked for other things.
16:24:48 <abadger1999> spot: So I'm perfectly fine with us saying those are necessary
16:24:49 <haraldh> the only question is: "should we run this from within the filesystem package automatically? and how so?"
16:25:00 <abadger1999> spot: but the Feature can't go forward until they're resolved.
16:25:07 <tibbs|h> So there are pending questions, and we need those answers.
16:25:10 <spot> abadger1999: okay, i'm just trying to figure out exactly what we're waiting on so i can note it in the ticket
16:25:11 <limburgher> abadger1999: Agreed.
16:25:20 <abadger1999> so... where it belongs...?  big mess is all I can say :-)
16:25:48 <haraldh> abadger1999, ?
16:26:27 <abadger1999> haraldh: Just whether noting what still needs to be done is fpc business, fesco business, nobody's business...
16:26:44 <spot> * The upgrade script is reviewed and approved by the FPC;
16:26:44 <spot> * Documentation is provided showing how yum upgrades will be seamless (or not to make them seamless)
16:26:45 <spot> * Testing needs to be done to show that the upgrade will work
16:26:53 <spot> those are the three items i see, is that correct?
16:26:56 <abadger1999> We know what we think still should be done before going forward.
16:27:24 <abadger1999> second bullet:
16:27:36 <abadger1999> are we decided that this dhould be documentation?  Or a yum plugin?
16:27:53 <tibbs|h> I don't think we have enough information to decide that.
16:27:53 <spot> no, i meant "show us how yum upgrades will work"
16:28:01 <spot> document that. :)
16:28:16 <geppetto> abadger1999: I think a plugin is a bad idea … either use %pretrans or just document that it is broken, and give the workaround for everyone to manually do a pretrans themself.
16:28:25 <abadger1999> so implicit in it is if a yum plugin is decided on, then someone writes it.
16:28:53 <spot> maybe change the second bullet to * Explain to the FPC how yum upgrades will be handled.
16:29:07 * abadger1999 is fine with geppetto's idea
16:29:24 <abadger1999> thinks removing branches here is going to streamline things.
16:29:56 <haraldh> one more question for those who favor %pretrans.. where can we ship the move script and how do we pull this package in?
16:29:59 <abadger1999> For the first bullet are we decided whether to pursue a lua %pretrans script or not?
16:30:13 <tibbs|h> I don't think we're decided on any of it.
16:30:28 <geppetto> haraldh: Write it in lua … ship it in filesystem.
16:30:28 <tibbs|h> Feature owners need to provide the method so we can look at it.
16:30:38 <haraldh> haraldh, or can it be done with lua.system('/bin/bash -c "...."')
16:30:39 <haraldh> :)
16:30:51 <haraldh> s/haraldh//
16:30:58 <abadger1999> haraldh: kinda defeats the purpose there :-)
16:31:16 <haraldh> abadger1999, no, because we have to check, if we upgrade first
16:31:19 <geppetto> I guess you can probably cheat and have it work … as it /bin/bash doesn't exist then you don't need to run it
16:31:42 <haraldh> abadger1999, and we can't use the shell interpreter for that
16:31:43 <abadger1999> haraldh: ah.... okay, that might work then.
16:31:59 * spot is content to let someone smarter than me propose the actual method here.
16:32:01 <haraldh> if that works, I have no problem shipping it in %pretrans
16:32:23 <haraldh> would actually solve one more problem :-)
16:32:29 <haraldh> cool
16:32:50 <abadger1999> oh -- I had one more questoin from the feature page... are the proposed Conflicts adequate to ensure filesystem is upgraded early enough?
16:32:59 <haraldh> yes
16:33:00 <abadger1999> (feature ticket, notpage)
16:33:12 <haraldh> abadger1999, you mean, there is an ordering problem?
16:33:26 <haraldh> not if we use %pretrans
16:33:52 <spot> #action Wording marking /bin, /sbin, /lib, and /lib64 offlimits is approved (+1:7, 0:0, -1:0), however, we are holding on making it effective until: * The upgrade script is reviewed and approved by the FPC * An explanation is provided to the FPC to show how yum upgrades will be handled. * Testing needs to be done to show that the upgrade will work
16:34:14 <abadger1999> "If the user does a yum upgrade, are they assured that the transaction will abort in a place where they haven't changed their installation in disasterous ways?"
16:34:49 <haraldh> abadger1999, yes, we can fail.. as shown in the current filesystem %pre
16:35:06 <haraldh> abadger1999, http://harald.fedorapeople.org/downloads/usrmove/filesystem-usrmove.patch
16:35:43 <haraldh> abadger1999, and we keep the old directories until we are really save to remove them in the update script
16:35:56 <abadger1999> what I was getting at was what happens if some new packages install that expect, for instance /usr/lib64/ld.so.  but filesystem has not yet installed, and the next package errors out.
16:36:00 <haraldh> we can even leave them around
16:36:22 <haraldh> abadger1999, it's "%pretrans"
16:36:27 <haraldh> pre - transaction
16:36:37 <tibbs|h> Is there anything else we can get done today?
16:36:45 <spot> i don't think so.
16:36:54 <spot> haraldh: do you understand what we still need?
16:36:59 <haraldh> abadger1999, and the ld-linux.so loader still is hardcoded with "/lib"
16:37:03 <tibbs|h> There was a bundled lib request from the samba folks.
16:37:13 <abadger1999> haraldh: yeah -- so with %pretrans lua script invoking it, seems to take care of that.
16:37:23 <haraldh> yep
16:37:29 <abadger1999> haraldh: <nod>  example name pulled out of my... hat:-)
16:37:40 <spot> tibbs|h: yeah, that one seemed like it met the same criteria we approved for gdb
16:37:43 <limburgher> tibbs|h: Yeah, seemed pretty straightforward, but. . .
16:37:43 <haraldh> spot, your "action" makes sense
16:38:07 <spot> haraldh: every now and then, my actions make sense. ;)
16:38:13 <haraldh> spot, :)
16:38:22 <tibbs|h> I only bring it up because it was described to me as urgent.
16:38:43 <spot> okay. lets try to tackle it then
16:38:47 <limburgher> I say we discuss it then, at least long enough to +1 it or say next week, too complex.
16:38:57 <spot> #topic libreplace bundling exception - https://fedorahosted.org/fpc/ticket/120
16:39:23 <spot> +1 on the same grounds as the sourceware/gdb exception.
16:39:33 <rdieter> +1
16:39:50 <limburgher> +1, esp. since it seems potentially short-term.
16:39:50 <SmootherFrOgZ> +1
16:40:07 <abadger1999> +1  I have some questions to clarify the writeup though
16:40:41 <abadger1999> actually... I don't --misread the ticket.
16:41:06 <tibbs|h> +1, though does Linux actually need the stuff in libreplace?  I thought it was for portability to other systems.
16:41:09 <abadger1999> I do have some questions for the writeup of 109
16:41:17 <spot> i see +6 on this. anyone else want to vote? geppetto, Rathann?
16:41:50 <tibbs|h> I was actually thinking of ticket 119 when I brought this up; forgot he filed two.
16:41:51 <geppetto> blah, +1
16:41:58 <abadger1999> limburgher: there's actually 119 which may be short term and this one 120, which I think is forever.
16:42:21 <limburgher> abadger1999: Yeah, I just saw that.  #brainfail
16:42:46 <spot> #action Exception approved for libreplace on the same grounds as the sourceware exception. (+1:7, 0:0, -1:0)
16:43:34 <spot> 119 is a temporary exception...
16:43:40 <abadger1999> But...
16:43:49 <abadger1999> It sounded good until I read "2) it may end up that other samba4-derived packages may also need to bundle it at a different snapshot. "
16:44:12 <spot> #topic libtdb_compat and libccan bundling request - https://fedorahosted.org/fpc/ticket/119
16:45:15 <limburgher> abadger1999: Yeah, that's. . .icky.
16:45:48 <spot> i think i'm okay with granting temporary bundling exceptions for both libraries until libtdb 2.x releases, and then they expire.
16:45:53 <abadger1999> temporary is a note in favor.  That bundle a different snapshot is a note against... so I'm not convinced yet.
16:46:17 <abadger1999> but I could be still :-)
16:46:45 <sgallagh> Hello
16:46:49 <abadger1999> sgallagh: greetings
16:46:56 <geppetto> Yeh, this seems icky
16:47:03 <abadger1999> We approved 120 but we're concerned by 119.
16:47:06 <spot> sgallagh: the "other samba4-derived packages may also need to bundle it at a different snapshot." is giving us some heartburn.
16:47:22 <sgallagh> Not only you.
16:47:37 <limburgher> spot: Yeah, seems like there ought to be patches to those package to use the most recent, etc.
16:47:39 <spot> is that likely? or are you just future-proofing?
16:47:40 <sgallagh> The upstream process for releasing the tarballs of these libraries is... complex
16:48:11 <sgallagh> Basically, they snapshot a moment in time of the samba sources and then filter out only the source files necessary to build these libraries.
16:48:14 <limburgher> sgallagh: And the compelling technical reason against decomplexing it is. . .?
16:48:28 <limburgher> Gross.
16:48:33 <spot> limburgher: remember, today is "no technical reasons necessary" day. </troll>
16:48:38 <sgallagh> limburgher: Samba's build system is a dark cave filled with giant spiders?
16:48:45 <limburgher> spot: Sorry, I forgot. :)
16:49:00 <limburgher> sgallagh:  Is that the charitable description?
16:49:09 <abadger1999> spot: Does that holiday always fall on teh Wed before Thanksgiving?  Or is it tied to a lunar calendar?
16:49:13 <sgallagh> That's the *very* charitable description
16:49:51 <sgallagh> I had a long conversation with upstream yesterday.
16:50:11 <sgallagh> They're committed to releasing both of these libraries eventually (the same way that libtevent, etc. are released).
16:50:17 <sgallagh> But right now they're in too much flux.
16:50:31 <sgallagh> They don't want to risk third-party apps linking against an unstable API
16:50:33 <abadger1999> So libtdb is also being produced by the samba upstream?
16:50:34 <spot> sgallagh: so, lets say the fpc grants a temporary exception for 119, until libtdb 2.x is released. the exception would expire then, since it should not be needed. you advise upstream to try not to be stupid here, and if they can't manage that when libtdb2 releases, we'll revisit whether the issue.
16:50:37 <sgallagh> Yes
16:50:51 <abadger1999> do we have a timeline for release?
16:50:53 <sgallagh> That was answering abadger1999
16:50:56 <abadger1999> <nod>
16:51:15 <spot> whether the issue should be reconsidered.
16:51:18 <sgallagh> We do not. libtdb2 just recently went in as experimental.
16:51:25 <sgallagh> Could be a few months.
16:51:35 <sgallagh> I have no idea if we're talking pre- or post-F17 release
16:52:11 <abadger1999> If we can narrow it down to say, no more than two release cycles, that would still be worthwhile.
16:52:14 <tibbs|h> I don't think post-F17 is the problem; it's post-F20 or whatever.
16:52:19 <abadger1999> yeah.
16:52:25 <sgallagh> I doubt it will go past F18
16:52:33 * abadger1999 doesn't like indefinite temporarily'ies
16:52:43 <sgallagh> And I'm going to be reminding them on a regular basis to fix it
16:52:45 <tibbs|h> I'm inclined to think this is OK.
16:53:04 <spot> so, lets say it expires at F18 GA or libtdb 2.x's release, whichever happens first.
16:53:21 <tibbs|h> Sure, although I'm a bit unclear on what "expires" means.
16:53:31 <tibbs|h> It's not as if we're going to pull Samba regardless of what happens.
16:53:40 <sgallagh> tibbs|h: I think it means that I'm vulnerable to a public shaming after that point :)
16:53:43 <spot> the exception goes away, and we revisit the issue.
16:54:01 <spot> if i'm lucky, raptors will have eaten me by then and i will not have to worry about it.
16:54:17 <sgallagh> spot: Careful what you wish for. Raptor attacks are on the rise these days.
16:54:19 * abadger1999 agrees with tibbs|h but is still  inclined towards approval
16:54:43 <limburgher> spot: A raptor once bit my sister.
16:54:59 <sgallagh> spot: My cousin actually got attacked by a hawk last year.
16:55:07 <abadger1999> I suppose we could say, samba must epoch back down to an old version but I highly doubt we'd do that either.
16:55:16 <spot> So, proposal: "Temporary bundling exception for libtdb_compat and libccan given until F18 GA or libtdb 2.x releases and the exception is no longer necessary."
16:55:25 <tibbs|h> +1
16:55:29 <spot> So, proposal: "Temporary bundling exception for libtdb_compat and libccan given until F18 GA or libtdb 2.x releases and the exception is no longer necessary, whichever comes first."
16:55:35 <sgallagh> abadger1999: Well, it's *samba4* not "samba"
16:55:38 <spot> (i forgot the whichever comes first)
16:55:40 <abadger1999> ah.
16:55:42 <sgallagh> There's a big distinction
16:55:59 <tibbs|h> Yeah, the world uses samba.  Much less of the world uses samba4.
16:56:00 <spot> +1
16:56:06 <tibbs|h> Still +1
16:56:07 <limburgher> +. . . .1
16:56:11 <SmootherFrOgZ> +1
16:56:17 <sgallagh> But openchange has deps on samba4 (for the record)
16:57:12 <abadger1999> sgallagh: does the exception still work for you if we restrict bundling to applications/packages from the samba4 project?
16:57:25 <spot> sgallagh: I would advise that the risks of wearing the bacon vest outside outweigh the fashion points, but that's just crazy talk.
16:57:41 <tibbs|h> Don the meat ponchos!
16:57:50 <sgallagh> abadger1999: I don't think that disagrees with my original request.
16:57:55 <abadger1999> k
16:58:04 <abadger1999> +1 from me with that addition to the proposal.
16:58:14 * spot is fine with the limiter on samba4
16:58:14 <tibbs|h> +1 either way.
16:58:14 * rbergeron will be butting in in a few minutes to go through the REALLY FUN TIME known as FUDCon subsidy granting meeting
16:58:19 <rbergeron> Unless you guys are in heated debates
16:58:25 <rbergeron> in which case i'll take it back to fudcon-planning channel
16:58:25 <tibbs|h> Almost done.
16:58:27 <spot> i see +5 on the table
16:58:36 * abadger1999 then it follows closely with our other recent copyllib approvals
16:59:06 <spot> #action Temporary bundling exception for libtdb_compat and libccan (for samba4 packages only) given until F18 GA or libtdb 2.x releases and the exception is no longer necessary, whichever comes first.
16:59:18 <spot> (+1:5, 0:0, -1:0)
16:59:27 <abadger1999> Real real quick
16:59:27 <sgallagh> Can we refer to that as 'samba4-derived'?
16:59:35 <limburgher> rbergeron:  You can have the room, but you may need to wash it first. :/
16:59:50 <tibbs|h> abadger1999: Type fast
16:59:53 <abadger1999> I had some questions when I tried to writeup https://fedorahosted.org/fpc/ticket/109#comment:6
16:59:58 <rbergeron> limburgher: no point. it's going to just get dirty again ;)
17:00:24 <sgallagh> spot: Because libtdb, libtalloc and friends come from the upstream samba4 source, but they *are* their own tarballs.
17:00:24 <abadger1999> people can answer me on #fedora-devel ... just want to clarify how to write it up properly
17:00:30 <spot> sgallagh: sure.
17:00:41 <sgallagh> (And appear in both their own tarball and the samba4 tarball)
17:00:46 * rbergeron waves at her WH
17:01:01 <spot> samba4 packages is henceforth defined as "packages in the samba4 family from the samba4 upstream"
17:01:04 <sgallagh> Thanks. Just don't want any semantic issues
17:01:15 <abadger1999> #endmeeting
17:01:21 <spot> hey, i get to say that
17:01:23 * abadger1999 apparently not chaired
17:01:24 <spot> #endmeeting