17:02:25 <abadger1999> #startmeeting fpc
17:02:25 <zodbot> Meeting started Thu Mar 27 17:02:25 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:30 <abadger1999> #meetingname fpc
17:02:30 <zodbot> The meeting name has been set to 'fpc'
17:02:34 <abadger1999> #topic Roll call
17:03:01 <danofsatx-work> aqui
17:03:11 <danofsatx-work> whoops, wrong meeting
17:03:15 <abadger1999> hehe :-)
17:03:17 * RemiFedora here
17:03:18 * danofsatx-work is not here
17:03:24 <abadger1999> #chair geppetto Rathann RemiFedora
17:03:25 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto
17:03:43 <abadger1999> spot, tibbs, racor, SmootherFrOgZ, limburgher: FPC ping
17:04:44 <tibbs|w> I'm around but being pulled in a few different directions.
17:05:02 <abadger1999> #chair tibbs|w
17:05:02 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto tibbs|w
17:05:04 <abadger1999> k
17:05:41 <abadger1999> tibbs|w: no worries, we'll see what we can do with you only partially here.
17:05:47 <abadger1999> So that's quorum.
17:05:54 <abadger1999> #topic SCLs.
17:05:59 <abadger1999> No movement on the bug report.
17:06:12 <abadger1999> I sent a status on this a few minutes ago to the devel list in rpely to mitr.
17:06:15 <RemiFedora> any news on the patch you have submitted upstream ?
17:06:30 <abadger1999> I'm going to try to wrap up as much as I can do in the next week or so.
17:06:45 <geppetto> on the upside, I should be doing trying to do a biggish yum scl soon
17:06:51 <abadger1999> Because I won't be available from April 7 to the 27th (and likely after that I'll be swamped with catching up)
17:06:52 <geppetto> or is that really an upside … hmmmm
17:07:31 <geppetto> abadger1999: ok, enjoy holiday :)
17:07:34 * limburgher here late
17:07:39 <abadger1999> geppetto: Will you be changing your nick to geppetto-insanity or geppetto-gibbering?
17:07:54 <abadger1999> #chair limburgher
17:07:54 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbs|w
17:07:54 <limburgher> :)
17:08:01 <geppetto> abadger1999: we'll see … maybe geppetto-insanley-biggering
17:08:02 <abadger1999> RemiFedora: that's the "no movement on the bug report"
17:08:14 * racor is here - just had a power failure :(
17:08:19 <abadger1999> #chair racor
17:08:19 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher racor tibbs|w
17:08:43 <abadger1999> #topic Go https://fedorahosted.org/fpc/ticket/382
17:08:53 <abadger1999> Also no information from vbatts to move this one along.
17:09:05 <abadger1999> #topic #391     Exception for bundled libraries in icecat
17:09:09 <abadger1999> https://fedorahosted.org/fpc/ticket/391
17:09:38 <abadger1999> So on this one... I talked with spot and mattdm and we have an idea for a new class of exceptions that would cover this
17:09:45 <abadger1999> but I don't know how everyone would feel about it.
17:09:52 * abadger1999 pulls it up and pastebins
17:10:49 <Rathann> hmm, if what I see in the last entry in that ticket is true, that's a big improvement over plain firefox already
17:11:17 <tibbs|w> Yes, I agree.
17:11:25 * spot apologizes for being late, is here now
17:11:32 <tibbs|w> But I guess we still need a list of what they want us to except.
17:11:54 <abadger1999> http://fpaste.org/89236/59403071/
17:11:57 <abadger1999> #chair cpot
17:11:57 <zodbot> Current chairs: Rathann RemiFedora abadger1999 cpot geppetto limburgher racor tibbs|w
17:12:34 <limburgher> I didn't know C came in pots.
17:12:47 <limburgher> ASCII, usually.
17:12:52 <geppetto> quick … register cpot nick!
17:13:00 <geppetto> get all the power
17:13:16 <abadger1999> #chair spot
17:13:16 <zodbot> Current chairs: Rathann RemiFedora abadger1999 cpot geppetto limburgher racor spot tibbs|w
17:13:41 <geppetto> I kind of understand the desire that the pastebin text is trying to get at
17:13:50 <geppetto> but it still feels horrible
17:13:51 <tibbs|w> I as well.
17:13:52 <limburgher> Yeah. . .
17:14:03 <abadger1999> limburgher: Actually C locale is what usually fills a .pots :-)
17:14:11 <limburgher> abadger1999: :)
17:14:12 <tibbs|w> It's more a guideline for what we should consider approving, but I can't imagine it would be an automatic thing.
17:14:39 <limburgher> And by demonstrated, what are we looking for, patched upstream bug reports, etc?
17:14:57 <geppetto> Might as well say "If you are a project called firefox, and do annoying bundling things … we'll let it go"
17:15:00 <limburgher> Because that may not exist if now flaw has been found in the bundled code.
17:15:11 <limburgher> s/now/no/
17:15:32 <geppetto> limburgher: I assume that's like historical record of response times to any security issues that are brought up
17:15:35 <limburgher> One would have to review the bundled version vs. the upstream and . . .oy.
17:15:42 <spot> it is worth noting that chromium would meet both criteria.
17:15:46 <limburgher> Right.
17:15:53 <spot> although I had no part in crafting this.
17:16:03 <abadger1999> tibbs|w: <nod>  It is true that there are quite a few of our "reasons we might allow you to bundle" that we don't consider automatic.
17:16:06 <limburgher> And the onus of demonstrating all of this is on the maintainer?
17:16:12 <abadger1999> technically all of them.
17:16:22 <geppetto> spot: Is bundling the only problem with chromium?
17:16:27 <limburgher> We can always say "no, because reasons".
17:16:29 <abadger1999> But some we're more "yep, fits that criteria" than others.
17:16:37 <spot> geppetto: no, it also doesn't build entirely from source right now.
17:16:50 <limburgher> Jeebus.
17:17:06 <spot> thats the main reason there hasn't been a recent chromium build from me in a while.
17:17:12 * geppetto nods
17:17:52 <geppetto> so, here's an example
17:18:05 <geppetto> PostgreSQL would fit that pastebin text
17:18:41 <geppetto> And I woudln't be shocked if they wanted to make their lives easier by bundling the same versions they ship other places, instead of using the system ones
17:18:45 <abadger1999> geppetto: Re: just firefox: there's also python3 (ensurepip),  and red hat's crash software is kinda bundling/forking gdb
17:19:03 <geppetto> So … do we want to say "sure, go ahead" … or "please $god, no"
17:19:18 <limburgher> Oooh!  Oooh!  B! B! B!
17:19:28 <geppetto> limburgher: :)
17:19:33 <limburgher> But we have to A, pragmatically.
17:19:47 <limburgher> sorry, MAY have to A.
17:19:54 <Rathann> I'd add "where unbundling is not feasible in short term because upstream requires an unreleased version of the bundled code or patches applied to bundled code are not yet accepted to bundled upstream
17:20:19 <limburgher> <nods>
17:20:31 <geppetto> yeh, I mean we could add some wording that implies there should be a test of how reasonable it is to unbundle
17:21:05 <abadger1999> yeah -- it gets hard because a "is it feasible" check encourages the maintainer to think up reasons that unbundling would be harder than it really is.
17:21:08 <limburgher> "I can't define reasonability, but I know it when I see it."  -Important dead person
17:21:32 <Rathann> I mean, I'd like to see active effort on the part of the project that's bundling to get bundled code unbundled
17:21:37 <geppetto> But I think that's going to be hard for more than a general guideline … putting into text "if we throw spot at it for 5 years and the problem still isn't solved, we'll give up and let you ship it" is probably close to what I'd be willing to ACK
17:22:09 <abadger1999> geppetto: heh -- are you saying we'll end up shipping chromium in place of firefox for the next five years? ;-)
17:22:12 * spot is not volunteering to be thrown at anything else.
17:22:14 <limburgher> Except spot isn't a renewable resource.  What if we've already hit Peak Spot?
17:22:38 <geppetto> abadger1999: I'm saying that I'd be willing to let spot bundle a big pile of stuff in chorimum … because of the last 5 years
17:22:40 <racor> i'm quite uncomfortable with this proposal. It more or less opens up all backdoors to bundling we've tried to kept closed.
17:23:18 <Rathann> racor: are you suggesting we remove firefox from Fedora because it breaches the guidelines?
17:23:19 <racor> Just claim apply some patches and claim to have to be active.
17:23:21 <geppetto> abadger1999: but there was a time I hoped he could get google to fix their %^$*
17:23:39 <abadger1999> :-)
17:23:43 <limburgher> As is, without this proposal, since we seem not to enforce guidelines too hard on active packages. . .the status quo could keep on quoing.
17:23:48 <tibbs|w> Well, I don't think anyone's really suggesting we stop at "claim".
17:24:06 <racor> Rathann: firefox has been a PITA, IMO, it's one of the worst maintained packages.
17:24:13 <Rathann> I know
17:24:23 <Rathann> but do we have any way to force the maintainer?
17:24:24 <racor> Rathann: It's only that they definitely have an active team
17:25:04 <tibbs|w> But it is perfectly possible for an upstream to bundle a patched version of something and do it in a way that doesn't create security exposure.  It's just difficult.
17:25:41 <abadger1999> <nod> -- although media libraries (which are playing content from the internet) doesn't seem like one of those.
17:26:25 <limburgher> Like I just found out that Wesnoth is bundling a bizarre Lua 5.1/5.2 hybrid.
17:26:38 * Rathann facepalms
17:26:47 <limburgher> Yeah.
17:26:49 <geppetto> bonus
17:27:08 <tibbs|w> I mean, if some bug in a video decoder crops up, I'd think that there's a good chance Google would have a fixed version of Chrome out before we could even get a fixed package built and into the update system.
17:28:07 <geppetto> That's mre than just bundling at that point though
17:28:18 <abadger1999> limburgher: but I wnat bitwise ops and not goto!
17:28:31 <geppetto> If we have to solve the problem of how to ship Chrome … I'm going for lunch :)
17:28:34 * limburgher chases abadger1999 with a shovel
17:28:55 <limburgher> geppetto:  Heck, I'm going for breakfast. . .
17:29:32 <abadger1999> So strawpoll: do we desire to allow firefox to bundle in some shape or form?
17:29:52 <tibbs|w> I'm just saying that even though I'd much prefer a zero bundling situation, there are times when an upstream can do it properly.  It's just really difficult, and while many upstreams might think they can do it right, in reality only a handful actually can.
17:30:01 <geppetto> desire … no … but if it's ship it with bundling or not, then I guess still ship it.
17:30:03 <limburgher> What tibbs|w said.
17:30:17 <limburgher> And what geppetto said.
17:31:05 <geppetto> and as for icecast, I'm willing to say it can have the same bundling as firefox … but if it wants more, then not ship it.
17:31:19 <tibbs|w> And at some point, even though I've been an ardent supporter of the whole zero-bundling ideal, we do have to consider other aspects of Fedora's users besides their security exposure.
17:31:48 <tibbs|w> I think at this point icecat is in a far better position than Firefox.
17:32:12 * geppetto nods
17:32:18 * Rathann nods as well
17:33:00 * limburgher reluctantly nods.
17:34:08 <tibbs|w> Anyway, with icecat specifically, I think they're still working on it and we're waiting for them to tell us just how far they got.
17:34:34 <spot> i worry that we spend too much time wringing our hands over bundling when no one else really does (Debian does in theory, but not so much in practice)
17:35:54 <racor> so, if I understand correctly, icecat could be granted a "temporary exception to avoid bundling if possible, but bundle what firefox bundles if necessary" ?
17:36:05 <tibbs|w> But even if we're going to allow more of it, we have the responsibility to at least asses the risk associated, and keep track of it.
17:36:10 <limburgher> That's what I'm getting.
17:36:16 <limburgher> we==whom?
17:36:33 <tibbs|w> Well, I guess that's us.
17:37:09 <tibbs|w> Well, as the gatekeepers, we should ask whoever is asking us to provide that information, and maintain the guidelines for how such bundling is indicated in the packaging metadata.
17:37:22 <tibbs|w> That didn't parse well.
17:37:26 <geppetto> limburgher: we=Fedora, I assume
17:37:44 <limburgher> geppetto:  I just meant, FPC, the maintainers, ???
17:37:45 <abadger1999> Im going to say +0.5
17:37:45 <abadger1999> If there's such a thing as too big to fail in a linux distro, firefox is probably one of those things.
17:37:46 <abadger1999> my hang up is finding a way to allow it that would be fair to other package maintainers.
17:37:46 <abadger1999> I take silence to mean everyone wishes that they could vote both +1 and -1 at the same time :-)
17:37:46 <abadger1999> So that doesn't seem like it will get us to move forward.
17:37:46 <abadger1999> How about this question:  Can we restrict the proposal to allow bundling if your project is big enough to have its own, active security team so that we could approve that?
17:38:13 <tibbs|w> Someone asks us "let me bundle", we say "provide all of this info about why you need the bundling, how upstream is prepared to handle issues that arise from it, and that sort of thing".
17:38:25 <limburgher> I could maybe consider that.
17:38:28 <tibbs|w> Which is sort of what we do now, only we say "no" a lot.
17:38:41 <Rathann> abadger1999: I'd stipulate an active effort to work with bundled code upstreams to unbundle
17:38:42 <tibbs|w> And we should still consider saying "no" quite a bit.
17:39:16 <Rathann> also, I'd be against a general permanent exception
17:39:21 <limburgher> tibbs|w: Oh, no worries there. :)
17:40:08 * abadger1999 seens to be lagging, apologies.
17:40:10 <tibbs|w> But at some point I think we have to admit we're not being particularly pragmatic, and are avoiding the conflict by pretending Firefox isn't something we're concerned about.
17:41:47 <spot> tibbs|w: agreed.
17:42:05 <spot> either the problem is serious enough that we'd pull firefox over it, or it isn't, and we need to stop having a double standard.
17:42:22 <tibbs|w> Pretty much, yeah.
17:42:48 <spot> fwiw, this is why i thought bundling belonged to FESCo, because that's really a policy decision, not a packaging one.
17:42:49 <racor> tibbs|w: May I remind you to recall why firefox is in the shape is it?
17:43:04 <racor> .. it is?
17:43:05 <tibbs|w> I admit this is a shift for me, but the firefox thing is starting to feel hypocritical.
17:43:28 <geppetto> spot: but as said, there is a double std. … we can't ship without firefox, but we could ship without wesnoth
17:43:38 <geppetto> or whatever
17:43:43 <limburgher> Right.
17:43:59 <tibbs|w> Well, that's "pragmatism"
17:44:08 <limburgher> I mean I can always ask for a bundling exception for wesnoth. . .probably will actually, but. . .
17:44:15 <tibbs|w> But we should at least come out and say that's what we're doing.
17:44:31 <limburgher> Call it a Police Action or something.
17:44:38 <geppetto> I'm fine with saying "If you are too big to fail, we'll just let you bundle"
17:44:54 <geppetto> because, users
17:44:59 <abadger1999> Rathann: I started trying to add some temporary exception language.  the only issue there is that it would require pulling the package from the repository if no action was being taken to unbundle.
17:45:13 <tibbs|w> I'm fine with saying that we want everyone to do the work, but that we may consider just how many users we screw by pulling or not having the software.
17:45:21 <abadger1999> which is not something we're known to be good at.
17:45:58 <geppetto> sure, that wording is fine too
17:47:12 <tibbs|w> Surely the firefox maintainers actually want to have a full accounting of everything the software is bundling, don't they?
17:47:29 <tibbs|w> I mean, who could argue that's a bad thing?
17:47:38 <limburgher> tibbs|w: One would think.
17:47:47 <spot> in theory, red hat cares about anything in Fedora that might end up in RHEL.
17:47:52 <spot> (in this context)
17:48:18 * spot is not allowed to speak for red hat in RHEL matter though, so take that with my community pants on.
17:48:28 <tibbs|w> Fine line to walk.
17:48:36 <tibbs|w> Anyway, what can we actually do here?
17:48:40 * limburgher wipes brow
17:48:44 <limburgher> thank god.
17:49:59 * spot has no productive suggestions. :)
17:50:04 <abadger1999> tibbs|w: okay.  So instead of (or in addition to) the "do you have an active security team", "are you popular enough that we pulling the software would be a major headache for our users?
17:50:05 <limburgher> What about getting an audit of everything ff/ic bundle and having them Provide(bundle), and list it on the wiki?  So it's at least tracked and we can edit it down as they improve.
17:50:12 <Rathann> can we refer to fesco, fab or FPL and have them get someone in RHEL to do the dirty work?
17:50:27 <tibbs|w> abadger1999: Basically, but more politically worded, sure.
17:50:43 <tibbs|w> limburgher: I think that's the end goal here.
17:50:58 <limburgher> I have a hard stop in 10min, FYI.
17:51:09 <abadger1999> Okay,
17:51:30 <abadger1999> I'll work on wording for a too big to fail criteria.
17:51:32 <tibbs|w> Well, crap, is there any business we could actually complete today?
17:51:44 <racor> abadger1999: non-workable, without definition of "big enough" and non-workable because sizes/activity are temporary (consider openoffice's history)
17:51:45 <abadger1999> Shoudl I include the security team idea in there?
17:51:48 <abadger1999> or leave it out?
17:52:18 <limburgher> I like it but wouldn't require it.  Prefer it.
17:52:19 <geppetto> abadger1999: I'd leave it … as I don't care if wesnoth has a security team
17:52:31 <abadger1999> geppetto: okee dokee.
17:52:32 <geppetto> abadger1999: So it's not really part of the criteria
17:52:44 <abadger1999> geppetto: oh -- so are you thinking wesnoth would fall under this criteria?
17:53:05 <abadger1999> geppetto: the way I was thinking of wording it, wesnoth probably wouldn't be justified.
17:53:51 <limburgher> Meaning it might get a regular exception but not a too big to fail exception?
17:53:58 <abadger1999> limburgher: correct.
17:54:07 <limburgher> Gotcha.
17:54:17 <tibbs|w> I mean, security's a tough issue and I'm not entirely qualified to judge just how much of an exposure something is.
17:54:57 <tibbs|w> Really most of the time we ask someone to come to us for an exception, we ask them to do pretty minimal work and they don't bother.
17:54:59 <Rathann> anything the processes user input or remote input is high-risk I'd say
17:55:32 <limburgher> tibbs|w: Nods.
17:55:43 <tibbs|w> But then how much do we really care about if the vast majority of people are never going to run the software anyway?
17:55:59 <tibbs|w> I mean "Wesnoth 0-day" is not a really huge attack surface.
17:56:05 <abadger1999> tibbs|w: yeah -- so we could look at a drastic redesign of the policy too....
17:56:08 <geppetto> abadger1999: right … that's what I menat, wesnoth isn't too big to fail, so no matter how good they tried to present the bundling, I'd be unlikely to care
17:56:19 <tibbs|w> It's a tough issue.
17:56:20 <abadger1999> risk-benefit
17:56:34 <tibbs|w> I'm still thinking back to the Gargoyle package.
17:56:46 <abadger1999> <nod>
17:56:59 <abadger1999> yeah, so gargoyle would be an example of "too small to care"
17:57:02 <tibbs|w> risk-benefit is tough because for something like Gargoyle it's so close to zero on both sides.
17:57:12 <limburgher> I'm off, let me know if you need my vote in a ticket somewhere. . .
17:57:24 <abadger1999> limburgher: will do.  Likely not on this one this week.
17:57:31 <tibbs|w> I guess we all need to think about this a little more.
17:57:34 <limburgher> Yeah.
17:57:55 * spot is personally inclined to support a "did you make changes that cannot go upstream for any reason (besides did not try)? If so, you're okay as long as you mark the bundling."
17:58:20 <abadger1999> geppetto, tibbs|w: I'll write up both a too big to fail and a too small to care.  We can think about whether to approve either or both of those next week.
17:58:59 <racor> I'll also have to quit within the next 10-15 minutes (I am expecting a phone call and then will have to quit)
17:59:00 <Rathann> bundling and modifying existing APIs instead of adding new ones would qualify as "too lazy to do the right thing" for me
17:59:02 <tibbs|w> spot: I'd like to think we can do a little better, like "can you actually justify and document those changes" but I understand the sentiment.
17:59:23 <abadger1999> spot: we could try that but from the sentiment here, I think we might have to restrict that somewhat.
17:59:38 <tibbs|w> It's free software; you're supposed to be able to fork it and steal from it.
17:59:38 <abadger1999> I mean -- if you look at rsync and zlib, that was the argument all these years.
18:00:11 <tibbs|w> But the thing is, didn't the end result of that rsync/zlib thing end up better in the long run?
18:00:12 <abadger1999> yet it turns out that once our package maintainers started working on the changes with zlib upstream they went in.
18:00:28 <racor> tibbs|w: My view: It's free SW, that's why you are supposed to "pay back" unless you're on an ego trip
18:00:37 * geppetto nods … although to be fair, I would classify rsync as too big to fail.
18:00:48 <abadger1999> geppetto: <nod> that's definitely true too.
18:00:55 <tibbs|w> I don't think anyone's not "paying back" in any of the instances we've discussed today.
18:01:41 <racor> tibbs|w: well, in this case, there should not be any need to bundle
18:01:56 <tibbs|w> Sure there is.
18:02:10 <abadger1999> #action abadger1999 to write up both "too big to fail" and "too small to care" criteria and we'll vote on those next week.
18:02:10 <tibbs|w> You "pay back" but the upstream doesn't want your contributions for pretty much any reason.
18:03:31 <racor> tibbs|w: Then upstream in on an ego-trip. The resort would be to fully fork (and hope others will pick it up) and not to bundle.
18:03:47 <tibbs|w> We want everyone to work together and should use what position we have to try and encourage that to happen.  We should try to protect our users from undue security exposure.  Besides that, I think we just have to be pragmatic.
18:04:07 <racor> tibbs|w: Just have a look at egcs/gcc or libavcodec vs. ffmpeg's history
18:05:25 <abadger1999> #topic #397     Please, choose an ID number for a new group called input
18:05:53 <abadger1999> I didn't write the question from the last meeting here.
18:05:54 <racor> tibbs|w: Provided what you say, we will soon have plenty of multi-medialibs, because these all for some reasons do not seem to be able to cooperate and everybody has its own forks.
18:06:00 <abadger1999> #topic #398     Tilde in version
18:06:05 <abadger1999> https://fedorahosted.org/fpc/ticket/398
18:06:50 <geppetto> I never got around to rplying to panu
18:07:24 <geppetto> but I don't think he's right about me being that weird … there are a lot of people who understand the old sorting system, and would be confused with ~
18:07:30 <tibbs|w> I really find our current versioning scheme to make quite some sense.
18:07:33 <abadger1999> Yeah.
18:07:41 <tibbs|w> And I have zero idea just how ~ is supposed to work.
18:07:49 <spot> tibbs|w: same here
18:07:55 <tibbs|w> And I read the documentation I could find on it and I _still_ don't understand how it's supposed to work.
18:07:59 <geppetto> tibbs: it's basically a magic "make this older" symbol
18:08:09 <abadger1999> The debian guidelines on tilde are even not very intelligible so they don't understand it very well either.
18:08:18 * geppetto nods
18:08:34 * racor nods
18:08:36 <tibbs|w> But from the discussion I get the impression I'm just completely missing something that the enlightened understand.
18:08:40 <geppetto> nobody wants to explain exactly what rpmvercmp does :)
18:08:41 <abadger1999> geppetto: that's probably the best way to express what tilde means :-)
18:08:58 <geppetto> abadger1999: Yeh :)
18:09:05 <Rathann> racor: I think you meant ffmpeg / libav (libavcodec is the codec library in both projects)
18:09:20 <Rathann> ok I have to go
18:09:33 <Rathann> I'll try to vote in any tickets later
18:09:36 <abadger1999> Rathann: Thanks for coming :-)
18:09:39 <tibbs|w> And one thing I've not understood is that don't you still have to have some kind of ordering on the stuff to the right of the tilde?
18:09:41 <geppetto> Saying that, if someone had a good usecase I could +1 … but so far everyone is "wah, I want to use rpm features"
18:09:56 <geppetto> tibbs: Yes
18:10:27 <tibbs|w> I understand that the tilde enforces some kind of "less than the empty string" in the version ordering, but that still doesn't solve the problem that our "just assign a damn integer that increments and care about that" solution does.
18:10:27 <racor> Rathann: Possibly. I meant the now widely ignored/dead (?) debian/ubuntu fork of ffmpeg.
18:10:44 <geppetto> tibbs: Basically if you are comparing "${foo}x" and "${foo}" then the first is "newer" because "more symbols = newer"
18:11:00 <tibbs|w> Right, and ~ inverts that.
18:11:04 <geppetto> yeh
18:11:17 <tibbs|w> But the stuff after ~ still matters, and you still have to order that, and all of these proposals ignore that.
18:11:39 <geppetto> tibbs: They don't ignore it … they just don't care.
18:12:13 <tibbs|w> Now, I think I'd like to see someone write something up that combines the two methods.
18:12:24 <geppetto> They want to be able to do: ${release_version}~${prerelease_version}
18:12:46 <tibbs|w> So you get ~${incrementing_integer}.${prerelease_version}.
18:12:51 <tibbs|w> And that I might be able to get behind.
18:12:53 <abadger1999> geppetto, tibbs|w: hmm... that is a good point.
18:12:59 <geppetto> And then just drop everything from ~ onwards after release, and have it be newer
18:13:32 <geppetto> tibbs: I'm not sure that's needed in most cases
18:13:44 <tibbs|w> None of this is needed in most cases.
18:13:49 <geppetto> tibbs: But it still has all the downsides of ~ being magic to me
18:14:29 <geppetto> including that ls (and html ls in apache) will show the wrong thing
18:15:10 <tibbs|w> Ah, right, sorting is kind of useful and our current scheme gets that exactly right.
18:15:16 <tibbs|w> Nice point.
18:15:18 <geppetto> so I'd like a good explanation of why they can't use the current release 0.<blah> solution
18:16:53 <tibbs|w> I guess because it's simply too difficult to do that in code.
18:17:27 <racor> I need to quit now.
18:17:29 <tibbs|w> I'm having trouble understanding that, really, but perhaps it's because I haven't tried to do it myself.
18:17:57 <racor> Should you be voting on ~, my current vote is -1
18:18:05 <racor> Bye
18:19:43 <tibbs|w> So, who is actually still here?
18:19:55 <abadger1999> So/// racor's -1 vote actually pushes us into "This does not pass territory"
18:19:56 * RemiFedora partially
18:20:06 <tibbs|w> I have to be on the phone in ten minutes but I don't have to leave my office.
18:20:34 <abadger1999> I'll try to summarize the discussion here for the ticket but it's not looking like this will pass.
18:20:49 <RemiFedora> for my test ~alpha, ~beta, ~rc1, ~rc2, ... works as expected
18:20:59 * spot is here, but I have to abstain on a proposal of "permit ~" without some better explanation of why.
18:21:18 <tibbs|w> RemiFedora: Because those happen to sort, I guess.
18:21:25 <RemiFedora> yep
18:21:33 <tibbs|w> Our guidelines are written for all of the cases, even where they don't sort.
18:21:49 <tibbs|w> Hence the incrementing integer.
18:21:51 <abadger1999> #info current votes on tilde in version (+1:0, 0:2, -1:4)
18:21:58 <RemiFedora> I still think ~ is a good idea as we have Version = upstream, Release = Packaging, which seems very more clear to me
18:22:13 <abadger1999> RemiFedora: except that it doesn't always work
18:22:19 <RemiFedora> abadger1999, so you can't count +1 from me
18:22:24 <RemiFedora> you CAN
18:22:26 <RemiFedora> sorry
18:22:40 <abadger1999> RemiFedora: for instance, libjpeg-1.2a libjpeg-1.2b
18:22:48 <abadger1999> post release rather than prerelease.
18:23:00 <RemiFedora> but ~ is only for pre release
18:23:11 <abadger1999> 1.0dev1  <= where does that order compared to 1.0 and 1.0a1 ?
18:23:28 <RemiFedora> 1.0~dev1 < 1.0 < 1.0a
18:23:34 <tibbs|w> I mean, it's not that I hate it.  It's just that the proposals don't handle the corner cases, and that giving up useful sorting doesn't appear to be worth it.
18:24:07 <abadger1999> and 1.0a1 vs 1.0alpha2Reright -- but that might not be correct.
18:24:18 <abadger1999> RemiFedora: right, but htat might not be correct.
18:25:46 <abadger1999> RemiFedora: Or 1.0~alpha1 1.0~a2
18:26:00 <abadger1999> #undo
18:26:00 <zodbot> Removing item from minutes: INFO by abadger1999 at 18:21:51 : current votes on tilde in version (+1:0, 0:2, -1:4)
18:26:09 <abadger1999> #info current votes on tilde in version (+1:1, 0:2, -1:4)
18:26:13 <RemiFedora> well... if upstream use stupid thing... and don't have any clear version scheme...
18:26:18 <tibbs|w> Oh, hey, that zodbot bug got fixed.  Nice.
18:26:49 <tibbs|w> We have never done particularly well with relying on upstreams to do the right thing, or the smart thing, or the useful thing.
18:26:53 * abadger1999 skips around to find some things we might finish today
18:27:04 <abadger1999> #topic #402     Promote /usr/lib/rpm/macros.d over /etc/rpm
18:27:09 <abadger1999> https://fedorahosted.org/fpc/ticket/402
18:27:20 <geppetto> 402 seems fine to me, +1
18:27:23 <abadger1999> +1
18:28:04 <tibbs|w> +1 on the concept.  Do we need to worry about EL<7 there or shift it off to EPEL guidelines?
18:28:55 <abadger1999> I'm willing to leave a note to check the epel guidelines.
18:29:06 <RemiFedora> +1
18:29:07 <abadger1999> but yeah -- it's become an epel concern rather than a fedora concern
18:29:23 <tibbs|w> Or we could just invert the sense and say "Additional RPM macros must be stored under /usr/lib/rpm/macros.d (/etc/rpm is also permitted for backwards compatibility with RPM versions)."
18:29:32 <abadger1999> note, to do this right, there's other places in the guidelines that need changing.
18:29:37 <tibbs|w> "older RPM versions", sorry.
18:29:52 <tibbs|w> Time for my phone call.  Will still be reading.
18:30:27 <spot> +1 from me
18:30:47 <abadger1999> #info Promote /usr/lib/rpm/macros.d over /etc/rpm Passed (+1:5, 0:0, -1:0)
18:31:29 <abadger1999> I'll either turn the notes in the ticket into the guideline or answer scop's questions so he can do it.
18:31:40 <abadger1999> #topic #404     Update python packaging guidelines
18:32:23 <geppetto> fwiw, this is the upstream commit for macros.d:
18:32:24 <geppetto> commit dcd261b9fe1e61e8ac3e99dbb443145bbf896886
18:32:24 <geppetto> Author: Panu Matilainen <pmatilai@redhat.com>
18:32:24 <geppetto> Date:   Fri Nov 9 08:21:51 2012 +0200
18:32:24 <geppetto> Add $RPM_CONFIGDIR/macros.d/ directory to default macro path (RhBug:846679)
18:32:46 <geppetto> so it should be in el7, but maybe didn't get into el6
18:32:50 <abadger1999> Hmm... we started voting on some of these but I'm not seeing them in zodbot's meeting logs
18:34:13 <tibbs|w> Well that was easy.
18:35:03 <geppetto> Yeh, the python one is just the py2 change
18:35:04 <geppetto> https://fedoraproject.org/w/index.php?title=User:Till/Python_Packaging&diff=372315&oldid=372311
18:35:16 <geppetto> I remember voting +1 on that
18:35:27 <abadger1999> Okay, for 404: We have +1 from abadger1999, limburgher, geppetto, RemiFedora
18:35:39 <abadger1999> tibbs|w and spot: Just need a +1 from either of you.
18:35:41 <geppetto> tibbs: you da man
18:36:04 <spot> +1
18:36:12 <tibbs|w> Uhh, yeah, that seems ogbvious.
18:36:13 <tibbs|w> +1
18:36:32 <abadger1999> #info python guidelines update (ticket 404) Passed (+1:6, 0:0, -1:0)
18:37:21 <abadger1999> #topic  #405 Downstream versioning of shared libraries.
18:37:54 <abadger1999> I'm inclined not to approve this one.
18:38:21 <abadger1999> but I'm not sure if there's something to tell the submitter they could do to make it acceptable
18:39:14 <abadger1999> I could also be convinced that his actually makes sense.
18:39:21 <tibbs|w> I think in the past I've recommended using foo.so.0.0.0 and incrementing the last digit.
18:39:51 <geppetto> abadger1999: why don't you like it?
18:39:59 <tibbs|w> The main problem is that if you're going to do this, you have to avoid the case where upstream decides to start versioning.
18:40:06 <geppetto> yeh
18:40:07 <abadger1999> tibbs|w: where normally the soname would simply be libfoobar.so.0?
18:40:18 <abadger1999> right.
18:40:39 <tibbs|w> Well, basically if you start versioning, you must be doing it for a reason.
18:40:47 <tibbs|w> And I appear to be lagging a bit myself.
18:41:09 <tibbs|w> So just picking a version of 0 doesn't help you; you might as well just leave it unversioned.
18:41:28 <tibbs|w> The issue comes up when you want to bump your artificial version for some reason.
18:41:44 <tibbs|w> What do you choose that's not '0' but is still lower than anything upstream might decide to use?
18:42:03 <abadger1999> <nod>
18:42:43 <abadger1999> okay -- question: are we okay if upstream starts versioning and their initial version is libfoobar.so.0 ?
18:42:55 <tibbs|w> I think not.
18:43:19 <tibbs|w> But I honestly don't know.
18:43:47 <abadger1999> Can we inject a namespace into the "name" portion of the soname?  Like SONAME: fedora-libfoobar.so.n ?
18:44:11 * abadger1999 thinks this gets harder and harder to do with standard libtools.
18:45:38 <abadger1999> I'll add these questions to the ticket.
18:46:00 <abadger1999> #topic #407     Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng
18:46:07 <abadger1999> https://fedorahosted.org/fpc/ticket/407
18:46:27 <abadger1999> *sigh*
18:46:39 <abadger1999> I know I analyzed this.... I must not have hit the submit button.
18:46:44 <tibbs|w> I think the question is why you want to version the library in the first place.
18:46:50 <tibbs|w> (crap, I never hit enter on that one).
18:47:33 <tibbs|w> I really, really wish we had just one standard tiny lib with md5 and sha1 with various useful calling conventions.
18:47:44 <RemiFedora> sorry, hard stop for me
18:48:07 <abadger1999> RemiFedora: so long
18:48:22 <abadger1999> RemiFedora: oh -- if you can move that SCL bug forward, that would be helpful.
18:48:31 * abadger1999 doesn't know how much influence you have.
18:49:03 <abadger1999> tibbs|w: yeah, agreed.
18:49:55 <abadger1999> So I did write some things in reply to sgallagh on the mailing list.https://lists.fedoraproject.org/pipermail/packaging/2014-March/010109.html
18:51:18 <abadger1999> Searching the web, I found that copyright notice attached to various other projects.  so it's widely bundled.
18:51:19 <tibbs|w> All of which I agree with.
18:51:35 <abadger1999> it's in some libraries, but none of them are lightweight
18:51:41 <abadger1999> (apr, for instance)
18:51:47 * geppetto nods
18:52:06 <tibbs|w> I think we pretty much have to agree with it unless someone steps forward to make the magical library.
18:52:23 <abadger1999> <nod>
18:53:26 <tibbs|w> At least that gets us tracking it.  I'm not sure we have the tools to do a search over all of the source in Fedora.
18:54:00 <tibbs|w> So we can't actually do much unless someone asks, but at least we can make things a little better.
18:54:15 <abadger1999> Proposal: Allow bundling of this sha1 implementation for the same reasons we allow md5 bundling.  Use virtual  Provides: bundled(sha1-hollerbach) to mark it
18:54:22 <tibbs|w> +1
18:54:22 <abadger1999> +1
18:55:09 <abadger1999> geppetto, spot: votes to allow sha1 bundling?
18:55:19 <spot> +1
18:55:39 * spot really needs to bounce in 5 minutes.
18:56:04 <abadger1999> #info Allow bundling of this sha1 implementation for the same reasons we allow md5 bundling.  Use virtual  Provides: bundled(sha1-hollerbach) to mark it presently at (+1:3, 0:0, -1:0)   will seek remaining votes in ticket
18:56:15 <abadger1999> #topic #408     Temporary jquery bundling exception for libserialport
18:56:22 <abadger1999> https://fedorahosted.org/fpc/ticket/408
18:56:27 <abadger1999> Let's try and make this the last one
18:56:57 <tibbs|w> Did I fall asleep when we removed the javascript exemption?
18:57:13 <abadger1999> I think we should just vote to allow bundling of jquery until jamielinux and patches get system-jquery ready for F21.
18:57:26 <abadger1999> tibbs|w: yeah -- the pair of web assets and javascript guidelines.
18:57:53 <tibbs|w> Well I remember that, but I didn't think we were actually at the forced unbundling stage.
18:58:02 <abadger1999> https://fedoraproject.org/wiki/Packaging:JavaScript
18:58:13 <abadger1999> tibbs|w: Well... these are new packages?
18:58:31 <abadger1999> Or is this an older one that had bug filed on it? /me checks
18:59:09 <tibbs|w> I know I got a bug for some bundled javascript in a package that I really wish I wasn't maintaining.
18:59:14 <geppetto> abadger1999: yeh, +1 for sha1
18:59:43 <abadger1999> geppetto: cool.  I'll add your vote when I update the ticket
19:00:55 <abadger1999> Proposal: Temporary bundling exception for anything to bundle jquery until the systemwide jquery feature is ready -- jamielinux and patches will inform everyone of its status
19:01:19 <abadger1999> tibbs|w: I don't think we grandfathered old packages.
19:01:34 <abadger1999> and we generally don't grandfather bundling non-compliance.
19:01:57 <abadger1999> so I can see someone filing a bug...
19:02:16 <geppetto> I guess +1
19:02:27 <abadger1999> not sure how pratical it is to unbundle in that specific case is at this time, though.... jquery is a large target with a coherent plan.
19:02:34 <abadger1999> +1
19:04:22 <abadger1999> Okay, we're at the end of two hours.
19:04:51 <abadger1999> #info General jquery exception until systemwide jquery feature is ready at (+1:2, 0:0, -1:0) will seek additional votes in the ticket.
19:04:56 <abadger1999> #topic Open floor
19:05:09 <abadger1999> If anyone has something to add, speak up
19:05:13 <abadger1999> otherwise I'll close in 60s
19:05:52 <tibbs|w> Ah, I'll add my +1 to that if it's really needed.
19:09:19 <abadger1999> Thanks tibbs
19:09:24 <abadger1999> #endmeeting