19:00:00 <nirik> #startmeeting FESCO (2010-05-11)
19:00:00 <zodbot> Meeting started Tue May 11 19:00:00 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:01 <nirik> #meetingname fesco
19:00:01 <zodbot> The meeting name has been set to 'fesco'
19:00:01 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:01 <nirik> #topic init process
19:00:01 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:19 <pjones> I AM HERE.
19:00:21 <pjones> honest.
19:00:21 <nirik> skvidal: yes. ;)
19:00:48 <Kevin_Kofler> Present.
19:00:48 * cwickert is here
19:00:56 <ajax> curiously enough, the only thing that went through the bowl of petunias' mind as it fell was "oh no, not again".
19:01:00 <mjg59> Hi
19:01:30 <nirik> notting / dgilmore: you guys around?
19:01:35 <notting> yes, sorry.
19:01:50 * skvidal is here
19:02:14 * dgilmore is here
19:02:14 <nirik> ok, I guess we can go ahead and start in.
19:02:19 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:02:19 <nirik> .fesco 351
19:02:21 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:02:28 <nirik> notting / cwickert: any news on the comps changes?
19:02:43 <notting> they're live in f-14. haven't wired up the critpath generation to them yet.
19:02:45 <nirik> also, stickster has asked us to note whats waiting and a schedule if possible.
19:03:09 <notting> there's a bit of an issue as to how to fix the tools to have per-release critpath, and where to automatically create and inject the list
19:03:15 <notting> (there's an open rel-eng ticket on this)
19:03:35 <nirik> ok. Could we gather the list of things we are waiting for on the wiki page/ticket?
19:03:56 <cwickert> I am fine with the Xfce and LXDE critpath packages. however the KDE critical path seems to be too little
19:04:26 <mjg59> cwickert: Given what we discussed last week, it's difficult to add more to the KDE critpath
19:04:30 <notting> *shrug* ... it's what they asked for
19:04:39 <mjg59> Since so many binaries come from one huge source package
19:04:42 <nirik> we can adjust it I think moving forward if need be.
19:04:42 <cwickert> mjg59: ok, sorry then, I was busy last week
19:04:49 <Kevin_Kofler> cwickert: Do you really want kdebase-workspace and all its dependencies on the critical path?
19:04:59 <mjg59> I don't think it's ideal, but there's no straightforward alternative
19:05:00 <Kevin_Kofler> mjg59: Even the binary packages are only minimally split.
19:05:01 <nirik> notting: would you be able to add info to the wiki page/ticket?
19:05:14 <nirik> I can ping about where autoqa and bodhi changes are.
19:05:16 <Kevin_Kofler> All of kdebase-workspace's dependencies include things like qzion, qedje and eet.
19:05:32 <notting> nirik: sure.
19:05:48 <Kevin_Kofler> kdelibs already has tons of deps like soprano etc.
19:05:48 <nirik> notting: thanks.
19:05:54 <cwickert> Kevin_Kofler: yes, because I think these are critical parts of KDE. the deps are not an excuse IMO, then you need more fine grained packaging
19:06:07 * dgilmore thinks that kdebase-workspace and its deps should be in critpath if they are required to get a basic kde shell
19:06:09 <cwickert> anyway, let's not dicuss this now given it was already discussed
19:06:10 <Kevin_Kofler> IMHO that's already way too much to scale, but of course a KDE critpath without kdelibs makes no sense in the first place.
19:06:50 <nirik> shall we move along? or discuss more?
19:07:31 <cwickert> move on please
19:07:43 <nirik> #topic #370 allow bundling libiberty
19:07:43 <nirik> .fesco 370
19:07:44 <zodbot> nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370
19:07:46 <Kevin_Kofler> kdm being on the critical path, we can't push a kdebase-workspace update without critpath scrutiny anyway as it's the same SRPM.
19:08:04 <nirik> This is an issue coming back from last week...
19:08:20 <nirik> abadger1999 wanted us to revisit this.
19:08:27 <dgilmore> i think ajax summed it up nicely
19:08:37 <Kevin_Kofler> There are some poins in ajax's reply which are just wrong.
19:08:46 <nirik> ajax's reasoning was for a static lib... this is for bundling though.
19:08:57 <dgilmore> We need to put heads with gnu project to get it fixed. and i dont think its a fight we need right now
19:09:05 <Kevin_Kofler> Re b, if we pick a soname major such as fedora14, that's not likely to conflic with upstream, ever.
19:09:08 <dgilmore> s/put/butt/
19:09:13 <Kevin_Kofler> Soname major numbers don't HAVE to be numeric.
19:09:24 <pjones> Kevin_Kofler: but what's the point?  that just means we're maintaining a fork.
19:09:30 <nirik> the issue here is BUNDLING. Not static lib.
19:09:32 <ajax> nirik: if you ignore d), no, it's not.
19:09:34 <Kevin_Kofler> Re c, it'd be the reviewer's job to scrutinize new packages for bundling libiberty.
19:09:44 <mjg59> Has libiberty's APi ever been well documented?
19:09:49 <ajax> mjg59: no.
19:09:49 <Kevin_Kofler> ajax: d is not even true!
19:09:53 <mjg59> The non-Linux aspects of it, that is
19:09:57 <Kevin_Kofler> kdesdk BRs binutils-devel for the C++ demangler.
19:09:59 <pjones> mjg59: sure.  it's the union of what non-linux has that linux doesn't.
19:10:00 <ajax> Kevin_Kofler: okay.
19:10:02 <pjones> (hahahaha)
19:10:03 * nirik goes to look at how many packages bundle this.
19:10:09 <ajax> Kevin_Kofler: i didn't see that in a repoquery.
19:10:17 <Kevin_Kofler> It's because it's a static lib only.
19:10:24 <Kevin_Kofler> So there's no runtime dep.
19:10:29 <Kevin_Kofler> There would be if it were properly shared.
19:10:54 <Kevin_Kofler> And I think it's actually binutils-static for Rawhide/F13.
19:11:02 <pjones> so once we fork it, make a dso of it, and fudge a soname for it, we have to go audit the entire repo for its use.
19:11:29 <Kevin_Kofler> But it's only static, so we don't need to apply for a static lib linking exception.
19:11:34 <Kevin_Kofler> # for libiberty (used by kmtrace for cp_demangle)
19:11:34 <Kevin_Kofler> BuildRequires:  binutils-devel
19:11:34 <Kevin_Kofler> %if 0%{?fedora} > 12
19:11:34 <Kevin_Kofler> # libiberty is only static, in F13+ it's only in -static
19:11:34 <Kevin_Kofler> BuildRequires:  binutils-static
19:11:34 <Kevin_Kofler> %endif
19:11:39 <mjg59> Ok. So this isn't a problem in F13.
19:12:04 <mjg59> And doing anything about it in F12 doesn't really make life better for anyone
19:12:09 <abadger1999> pjones: That's irrelevant -- this is about bundling, not static
19:12:10 <Kevin_Kofler> Well, I'm not sure whether it moved back or not.
19:12:29 <Kevin_Kofler> It's a guidelines interpretation problem: if a package provides both shared/static and static-only libs, where do the static-only libs go.
19:12:42 <pjones> abadger1999: maybe for you it is, but Kevin_Kofler keeps mentioning "if it were properly shared"...
19:12:44 <Kevin_Kofler> Some people read it as that they should go to -devel, others think it's -static.
19:12:49 <ajax> abadger1999: it's not irrelevant if you consider "not bundling" to be solved by "shared library"
19:12:59 <abadger1999> mjg59, Kevin_Kofler: Also irrelevant stuff... you're talking about static exceptions, not about bundling exceptions.
19:13:38 <mjg59> abadger1999: So you mean that rather than coming from binutils, it should be its own package?
19:13:41 <mjg59> abadger1999: I don't see what that buys us
19:13:51 * nirik wishes we had info on what other packages bundle this. It's not going to be super easy to find out tho.
19:14:06 <abadger1999> ajax: They're completely separate -- a month ago I talked to a maintainer about unbundling a shared library that came from a different package --- it was in a private dir in the package therefore it wasn't found before.
19:14:20 <abadger1999> mjg59: I think there's two aspects:
19:14:25 <skvidal> nirik: look for binutils BR then look throug hthe build process of each of those?
19:14:28 <skvidal> nirik: not fun
19:14:34 <ajax> skvidal: not even that.
19:14:38 <nirik> skvidal: no, if they are bundling, they would not BR anything.
19:14:41 <ajax> skvidal: make prep everythign in the OS
19:14:41 <notting> skvidal: no, if they're *bundling*, they wouldn't be using binutils-devel at all
19:14:41 <pjones> skvidal: won't help; stuff copy-and-pastes it
19:14:45 <mjg59> skvidal: That's not really adequate. Most libibrty consumers have it bundled.
19:14:59 <abadger1999> mjg59: 1) Till opened the bug because he thinks there's a different upstream tarball for libiberty -- I'm not sure if that's true or not.
19:15:03 <skvidal> I was just talking about finding the folks who snatch it from binutils
19:15:04 <skvidal> sorry
19:15:11 <pjones> basically you have to grep an exploded tree to find it.
19:15:11 <mjg59> abadger1999: Not meaningfully
19:15:20 <nirik> so far I see 5 packages
19:15:34 <abadger1999> mjg59: 2) Several packages are bundling libiberty (binutils, gcc, and gdb are listed on wikipedia but I haven't checked the tarballs yet.)
19:15:50 <abadger1999> mjg59: So those both can be addressed.
19:15:51 <pjones> well, we *know* those three do, they're why it exists.
19:15:55 <nirik> avr-gcc, msp430-binutils, avr-gdb, ghdl, mingw32-binutils
19:16:05 <pjones> and upstream is unlikely to consider fixing those three.
19:16:29 <mjg59> abadger1999: So, like I said, it's in binutils-static in F13 and rawhide
19:16:36 <mjg59> abadger1999: Which means this isn't an issue
19:16:55 <Kevin_Kofler> One problem is, they're all different versions of libiberty, and they might not support whatever version we unbundle. :-(
19:16:56 <mjg59> binutils is simply our canonical source of libiberty
19:17:06 <nirik> mjg59: it is for the packages that don't BR and link to that .a and instead include their own private copy of it.
19:17:10 <abadger1999> mjg59: Why do you continue to talk about shared-vs-static?
19:17:15 <mjg59> nirik: That's an issue with those packages, not with binutils
19:17:22 <mjg59> abadger1999: Please indicate where I made that distinction
19:17:28 <abadger1999> mjg59: Okay -- that's fine for me me.  But then that means, you are not granting an excpetion here.
19:17:42 <mjg59> abadger1999: The library is bundled with binutils, and binutils provides it for anyone else
19:17:48 <abadger1999> mjg59: Sorry -- you just took too long between your first and second line.
19:17:52 <nirik> or an exception is granted for binutils, and nothing else.
19:18:13 <abadger1999> mjg59: I typed my response to your first line before your second line came through.
19:18:34 <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically.
19:18:37 <pjones> well, so far we've only granted the (bundling) exception for binutils.
19:18:44 <mjg59> Frankly, I see libiberty as being an equivalent of libegg
19:18:48 <pjones> or rather, what notting said.
19:19:11 <mjg59> It's a pile of code with poor API and ABI guarantees that's explicitly intended to be cut and paste into code
19:19:15 <mjg59> It's ugly, but that's what it is
19:19:32 <mjg59> If people want to make use of the binutils version then that's fine, but otherwise it's reasonable for this to be bundled
19:19:40 <abadger1999> mjg59: We don't allow that anywhere else.
19:19:48 <mjg59> abadger1999: libegg
19:20:00 <abadger1999> mjg59: Not true -- propose it if you want.
19:20:04 <mjg59> If you'd like to pretend that we don't allow it, that's fine
19:20:07 <mjg59> But reality disagrees
19:20:20 <abadger1999> mjg59: it jsut means that no one has discovered it and brought it up yet.
19:20:20 * notting wonders if libiberty is older than various fesco members
19:20:23 <pjones> we haven't agreed upon an exception for it, but back in the real world it's being done.
19:20:37 <mjg59> There's simply no benefit to the projec tin being religious about this
19:20:42 <abadger1999> mjg59: If you use those criteria I have plenty of other libraries to bring up.
19:20:43 <mjg59> What benefit would refusing an exception give us?
19:21:05 <skvidal> quick question
19:21:11 <mjg59> Weigh that against the effort to ensure that every app that currently uses it works correctly with a shared static library
19:21:22 <skvidal> from the exception it seems like we don';t want any MORE bundled copies of this, if we can avoid it, correct?
19:21:27 <ajax> mjg59: s/shared/common/
19:21:40 <mjg59> ajax: Yes, that's clearer
19:21:45 <Kevin_Kofler> pjones: That means that all the packages bundling that crap are broken and should have release blocker bugs filed against them.
19:22:01 <ajax> skvidal: it would be pleasant to avoid more, i suppose.
19:22:01 <Kevin_Kofler> (F14Blocker, it's too late for F13)
19:22:02 <abadger1999> mjg59: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
19:22:05 <pjones> Kevin_Kofler: yes, that's what not granting other packages the exception means
19:22:10 <nirik> abadger1999: so we don't know if there is a seperate upstream release/tar of this?
19:22:11 <skvidal> okay
19:22:24 <skvidal> so - could we make it a review criteria check?
19:22:34 <pjones> Kevin_Kofler: it means we want the others to do what they can to link against the binutils-static copy in the future.
19:22:39 <abadger1999> nirik: I don't -- which is one reason I don't know if I want to say it must be separate from everything including binutils.
19:22:51 <mjg59> nirik: It's not available as a separate release
19:22:52 <skvidal> so grant the exceptions for current pkgs as per notting's proposal and add a review criteria to grep for it
19:22:55 <Kevin_Kofler> This applies to libiberty, gnulib, libegg etc. all alike.
19:22:59 <abadger1999> nirik: The other being that this is so far down in the tool chain that I don't know if it really is "special' in some way.
19:23:15 <skvidal> it won't necessarily keep it out but it might help
19:23:18 <nirik> mjg59: if it's not, then I think the exception here is ok.
19:23:22 <mjg59> I'm still asking this question
19:23:25 <mjg59> What's the benefit?
19:23:38 <pjones> skvidal: yeah, adding it to the review criteria does have some merit
19:23:42 <nirik> mjg59: being able to fix stuff in one place?
19:23:50 <mjg59> nirik: Fix what things?
19:24:02 <ajax> i'm not super thrilled with moving code duplication check into review criteria in general
19:24:06 <nirik> security / serious bugs?
19:24:07 <abadger1999> mjg59: [12:22:02] <abadger1999> mjg59: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
19:24:16 <abadger1999> ajax: It's already in the guidelines:
19:24:31 <nirik> so, we are at 15min here. ;)
19:24:32 <mjg59> nirik: If we have a system-wide version then we fix it, rebuild everything that depends on it and then find that three packages are now subtly broken because there's no API or ABI guarantees
19:24:39 <abadger1999> ajax: MUST: Packages must NOT bundle copies of system libraries.[11]
19:24:40 <ajax> abadger1999: okay, then i feel the guidelines overprescribe
19:24:49 <nirik> who wants to continue?
19:24:51 <pjones> abadger1999: it's not a system library.
19:24:55 <halfline> it would never make sense to package libegg fwiw
19:25:01 <pjones> it's almost exactly the opposite of a system library.
19:25:02 <halfline> it's designed to be cut-and-paste
19:25:03 <mjg59> Except we only find that out months later
19:25:06 <halfline> that's the whole point of it
19:25:12 <pjones> halfline: yes.
19:25:16 <abadger1999> pjones: It is according to the definition being used by the guidelines.
19:25:19 * nirik bangs a gavel. We need to decide if we keep going or not.
19:25:23 <ajax> nirik: continue
19:25:36 <nirik> I'd like to keep going for a few more minutes myself.
19:25:36 <pjones> nirik: I'm for continuing
19:25:38 * notting is ok to continue
19:25:41 <mjg59> Ok
19:25:43 <mjg59> Proposal:
19:25:54 <abadger1999> pjones: I mean,  we had this same discussion over php libraries.
19:25:57 <mjg59> libiberty is not a system library and therefore the packaging guidelines restricting the bundling do not apply
19:26:17 * nirik doesn't like that at all.
19:26:20 <Kevin_Kofler> halfline: JARs, Mono DLLs etc. are also often designed to be pasted into apps.
19:26:22 <pjones> abadger1999: the php libraries you discussed weren't designed to be cut-and-pasted, right?
19:26:32 <abadger1999> mjg59: That doesn't work.  That would have to go to the FPC to decide.
19:26:40 <pjones> Kevin_Kofler: you mean bundled, which is subtly different, right?
19:26:42 <Kevin_Kofler> There's also minizip which is designed to be pasted into apps, but we're building it as a subpackage of zlib and requiring stuff to link the system copy.
19:26:51 <halfline> Kevin_Kofler: libegg is a staging area for apis to eventually be brought into a real library
19:26:58 <Kevin_Kofler> Minizip is often outright pasted and linked as regular source files.
19:27:03 <Kevin_Kofler> We still require it unbundled.
19:27:10 <halfline> Kevin_Kofler: nothing goes in libegg that isn't slated for e.g. glib or gtk eventually
19:27:25 <Kevin_Kofler> Oh, librandomcrap? Joy!
19:27:30 <abadger1999> pjones: I didn't audit them all so I don't know -- some were and some weren't ... and other people would argue that all php libraries are made to be cut and pasted.
19:27:31 <halfline> yes that's exactly what is
19:27:36 <halfline> librandomcrap
19:27:38 <nirik> I think if there's no seperate upstream release, and this comes with binutils, we should grant the exception for binutils. Other packages should be on a case by case basis, usually on the side of 'no, use binutils-static'
19:27:40 <mjg59> abadger1999: I don't believe that the reasons provided in the no bundled libraries page are usefully relevant to this issue
19:28:01 <halfline> "we need code, we haven't figured out the interface yet, we put it here for real world usage before dumping it into a supported library"
19:29:00 * notting isn't sure about mjg59's proposal.
19:29:28 <notting> 'system library' is so vague that i'd rather not try and redefine it in terms of each request that comes to fesco
19:29:37 * nirik is +1 to nottings proposal, unless the library is available as a seperate tar/project, which it doesn't sound like.
19:29:38 <Kevin_Kofler> halfline: Interestingly, KDE does fine without something like that…
19:29:39 <pjones> yeah, it's very vague
19:29:53 <pjones> OTOH, a naive conception of it doesn't really fit with what libiberty does
19:29:59 <Kevin_Kofler> We've had a kdelibs-experimental in 4.3, but it was a shlib, just with an ABI guaranteed only for 4.3.x.
19:30:07 <abadger1999> nirik: I like that -- if there's a rationale for gcc gdb, etc, I'm still willing to write the rationale for those in as well.
19:30:11 <halfline> Kevin_Kofler: *shrug* it is what is. i didn't invent it or anything
19:30:14 <Kevin_Kofler> 4.4 no longer has that, that API got finalized into kdelibs.
19:30:40 <halfline> but from its inception was designed to be cut-and-paste and explicitly never installed
19:30:47 <Oxf13> lets not let this devolve into a gnome vs kde thing.  that's not helpful.
19:30:53 <pjones> Kevin_Kofler: the rationale for those is probably along the lines of "gcc isn't supposed to have to depend on gnu binutils"
19:31:01 <pjones> er
19:31:04 <nirik> yeah, how about we vote on notting or mjg59's proposals? or add another ?
19:31:06 <pjones> that was supposed to be at abadger1999
19:31:40 <nirik> pjones: it could do something different on some other platform, surely we can have it do the right thing in fedora? ;)
19:31:58 <pjones> nirik: kindof ignoring what libiberty is for there, don't you think?
19:32:10 <pjones> the whole point of it is that it won't really do much on this platform, but it's part of the code anyway
19:32:21 <Kevin_Kofler> There's stuff which is still uses.
19:32:22 <Kevin_Kofler> *used
19:32:42 <nirik> pjones: well, if gcc had some compelling need they could get an exception?
19:32:53 <Kevin_Kofler> It's part of the problem, this is a big messy mix of portability junk for broken systems and generic utility functions such as the C++ demangler.
19:32:58 <abadger1999> pjones: I can write that in but it's kind of silly as it's a build time dep and we're building a Linux distro that currently doesn't have a non-binutils provided linker.
19:32:58 <pjones> but their "need" is "this is why we wrote it"
19:33:11 <Kevin_Kofler> The C++ demangler is not in any other system library.
19:33:20 <pjones> abadger1999: sure, but the question is about the code, not the result
19:33:24 <Kevin_Kofler> kmtrace wouldn't require libiberty if it weren't the only place this code is in.
19:33:28 <mjg59> In the real world, convincing GNU to sort out libiberty properly isn't going to happen
19:33:34 <Kevin_Kofler> Well, it could copy it too, but ugh!
19:33:50 <nirik> I thought the question was the fedora package... ;)
19:34:02 <dgilmore> notting: what is your proposal?
19:34:06 <pjones> nirik: you want us to fork gcc over libiberty?
19:34:11 <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically.
19:34:13 <nirik> nope.
19:34:18 <abadger1999> mjg59: That's not a good argument -- FESCo has denied zsync and wordpress even though they've used that same upstream won't fix it argument.
19:34:22 <notting> (those are glob wildcards)
19:34:41 <pjones> notting: I'm generally in favor of that, though that's fairly close to what we decided last week IIRC.
19:34:44 <nirik> oh, I misread nottings proposal.
19:35:30 <dgilmore> notting: I think thats probably the sanest,  we can start to work with gnu to try get them to release it propperly
19:35:32 <mjg59> abadger1999: We can ship a distribution without zsync and wordpress. We can't ship a distribution without gcc and binutils.
19:35:33 <pjones> abadger1999: I hate to put it this way, but we need wordpress's cooperation to build the distro just a *tad* less than gcc's.
19:35:42 <abadger1999> mjg59: We also denied rsync.
19:35:47 <pjones> and again
19:35:51 <notting> abadger1999: not in any meaningful way.
19:35:56 <pjones> we've shipped a distro without rsync before.
19:36:08 <pjones> also forking rsync to get rid of a static lib isn't nearly the same kind of pain.
19:36:23 <Oxf13> nor the same potential damage if we do it wrong
19:36:28 <nirik> s/static/bundled and forked/
19:36:44 <ajax> i've been biting my tongue about something here, which is that we're only noticing the duplication because it happens to be named libsomething
19:37:06 <pjones> ajax: freetype is a really nice software package, isn't it?
19:37:06 <mjg59> abadger1999: If FPC want us to insist that the entire toolchain be forked from upstream, we can
19:37:09 <ajax> getting all righteous about that while ignoring all the other copypasta in the world is... inconsistent.
19:37:22 <mjg59> abadger1999: But I don't think that's a useful position for fesco to take. I don't think it benefits the distribution. I don't think it saves anyone time.
19:37:57 <pjones> also there are very rarely security implications from gcc using a library that's got a bug in it.
19:38:02 <Kevin_Kofler> So one question is: how much work would it be to unbundle libiberty from e.g. GCC?
19:38:08 <skvidal> ajax: isn't that just an issue of dealing with what you know about
19:38:12 <pjones> not that it can't happen, but the theoretical position against that is a bit of a strawman here
19:38:17 <Kevin_Kofler> I must say I'm not sure.
19:38:29 <abadger1999> mjg59: I'm wanting 1) a vote on whether bundling of libiberty is allowed and 2) the rationale for that exception that I can write into the guidelines and it won't be so silly that everyone else comes running up to say their software should fit in under the same exception.
19:38:31 <nirik> ok, we are at another 15min I think...
19:38:32 <pjones> Kevin_Kofler: you're really talking about forking gcc.
19:38:53 <Kevin_Kofler> But in principle, GCC and Binutils can be built from combined trees, doesn't that also mean building GCC against the libiberty from Binutils?
19:39:03 * cwickert got distracted by the telephone and tries to catch up...
19:39:06 <Kevin_Kofler> Or are there 2 copies of libiberty in such a combined tree?
19:39:17 <nirik> votes to continue? shall we vote? or table and gather more info? or continue?
19:39:21 <Kevin_Kofler> pjones: Patching, not forking.
19:39:32 <pjones> perpetually maintaining a patchset is called "forking".
19:39:34 <Oxf13> one in the same.
19:39:36 <ajax> right, because those are different things.
19:39:40 <Kevin_Kofler> If it has to be forked outright (or patched with a multi-MB patch or so), of course it doesn't make sense.
19:39:49 <cwickert> nirik: are there already proposals to vote on?
19:39:56 <nirik> cwickert: two so far:
19:39:58 <pjones> Kevin_Kofler: and... I think yes, you get 2 libiberty builds if you build them the way you're talking about
19:40:09 <abadger1999> cwickert: [12:34:12] <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically.
19:40:19 <nirik> <notting> proposal: an exception for bundling libiberty is granted for binutils, *gcc*, and *gdb*. others must use the binutils-devel copy statically.
19:40:35 <notting> (or binutils-static. wherever it is.)
19:40:42 <pjones> notting: frankly, I like your proposal, but I can see the benefit to a slightly weaker "must".
19:40:46 <notting> 'the static binutils copy.'
19:40:47 <Kevin_Kofler> I think that doesn't make sense.
19:40:55 <Kevin_Kofler> If we allow those packages to bundle it, we should allow all.
19:41:16 <cwickert> nirik: thanks, and the second one? same as 1. plus grep during review?
19:41:24 * nirik is looking for the other one.
19:41:24 <ajax> i'm fine with allowing it bundled in general, sure.
19:41:32 <Kevin_Kofler> Either it's hard to unbundle or it's not.
19:41:40 <ajax> i mean, to the extent i'm okay with libiberty at all
19:41:53 <ajax> but i'm trying not to let my simmering gnu resentment bubble through here
19:42:07 <pjones> Kevin_Kofler: and that's why I see the benefit of a weaker "must".
19:42:12 <nirik> <mjg59> libiberty is not a system library and therefore the packaging guidelines restricting the bundling do not apply
19:42:43 <mjg59> I support my proposal on the grounds that libiberty is obviously not a system library
19:42:52 <abadger1999> nirik: that one isn't a proposal to me -- that's a Guidelines change that would need to go to FPC.
19:43:06 <notting> mjg59: you support your proposal on the grounds of the first clause of your proposal?
19:43:27 <cwickert> thanks nirik
19:43:30 <mjg59> notting: Yup
19:43:46 <Kevin_Kofler> abadger1999: It's a statement of fact (which may or may not be true), not a guideline.
19:43:51 <nirik> proposal: exception is granted for binutils because there is no seperate upstream release. Other packages should use binutils-static, or ask for an exception.
19:43:57 <Kevin_Kofler> Now who is entitled to make such statements is the question.
19:44:30 <nirik> The fact that there is a binutils-static package makes me think it should be usable for other packages.
19:44:31 <cwickert> nirik: what about gcc and gdb then?
19:44:46 <notting> not to stifle discussion, but should we actually vote on the various proposals to see if any pass?
19:44:52 <pjones> nirik: and it probably is - especially for new packages that decide they need libiberty
19:44:57 <nirik> cwickert: they would need to ask us for an exception. Perhaps they can use binutils static? perhaps they have a good reason not to. I don't know off hand.
19:45:04 <pjones> nirik: for packages already using it, that's not necessarily so useful.
19:45:08 <ajax> notting: i'd kind of like a repo sweep to see who else is bundling it
19:45:14 <Kevin_Kofler> Proposal: somebody should look into how much work it is to get GCC and/or GDB to build against binutils-static's libiberty.
19:45:17 <ajax> notting: which would take rather more time than i'm willing to wait.
19:45:19 <nirik> ajax: +1
19:45:29 <ajax> (which i will happily do)
19:45:30 <nirik> anyhow, I am +1 for my own proposal.
19:45:33 <Kevin_Kofler> And next week or whenever we have the data, we can make a sane decision.
19:45:36 <cwickert> nirik: I doubt maintainting a forked gcc is realistic
19:45:50 <nirik> cwickert: I don't think it is either. I didn't say we should.
19:45:52 <notting> so, table for next week; ajax will perform some investigation?
19:46:12 <ajax> +1 table
19:46:12 <mjg59> Ok
19:46:12 <skvidal> notting: +1 to that
19:46:15 <pjones> okay
19:46:23 <nirik> The question before us is binutils, and I think its ok to bundle... I don't know about gcc or gdb or whatever off hand.
19:46:29 <Kevin_Kofler> +1 to tabling for next week after investigation (notting's latest proposal).
19:46:35 <nirik> ok, thats fine too.
19:46:37 <cwickert> I'm happy with the three exceptions, but I would like to see what else is affected. so +1 for the table
19:47:06 <nirik> #agreed ajax will see what packages are currently bundling this and we will revisit next week.
19:47:20 <nirik> #topic #373: erlang provides/requires explosion
19:47:21 <nirik> .fesco 373
19:47:22 <zodbot> nirik: #373 (erlang provides/requires explosion) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/373
19:47:26 <nirik> skvidal: any news on this?
19:47:31 <skvidal> yah
19:47:32 <skvidal> in the bug
19:47:33 <notting> didn't this sort itself out?
19:47:37 <skvidal> sorta
19:47:46 <dgilmore> cwickert: really our gcc is forked now.  its not the same as gnu's gcc
19:48:07 * nirik looks at the bug
19:48:08 <skvidal> 1. the erlang pkger peter lemenkov reduced the prov/reqs down to what is required and to point to the right pkg - rather than the giant function-list
19:48:12 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=564018
19:48:13 <skvidal> 2. but read his last comment
19:48:34 <skvidal> comment #50
19:48:44 * nirik tries to parse it.
19:48:44 <Oxf13> looks like they still want FESCo to make a decision here
19:49:12 <notting> proposal: what they were doing? don't do that.
19:49:21 <skvidal> notting: no kidding
19:49:43 <notting> that should probably be phrased better/nicer
19:49:45 <nirik> function level provides/requires info in repo data seems way overboard to me.
19:50:13 <skvidal> esp when they're STILL incomplete
19:50:22 <pjones> yeah.
19:50:22 <skvidal> since they don't talk about arguments to the functions
19:50:30 <nirik> automatic generation is fine, but not at a function level.
19:50:43 <nirik> so, do we need to vote on something here?
19:50:44 <pjones> skvidal: for the love of god, don't tell them that, they might get ideas.
19:50:52 <skvidal> pjones: it's already come up
19:52:01 <notting> Proposal: Automatically generated provides/requires must be kept to a reasonable level. Per-library function provides/requires are not reasonable. If you have questions about what is, contact FESCo and/or FPC. ?
19:52:24 <skvidal> notting: I tink that sounds fine
19:52:26 <nirik> +1 sounds fine to me.
19:52:31 <skvidal> +1
19:52:32 <cwickert> +1
19:52:40 <Kevin_Kofler> The problem is, the Erlang dependency generator still doesn't support being sane.
19:52:42 <mjg59> +1
19:52:46 <Kevin_Kofler> The packages they fixed, they fixed manually.
19:52:55 <cebbert> they do put the number of args to the function in the deps
19:52:57 <Kevin_Kofler> And they're saying they can't do that for all packages, only for the worst offenders.
19:53:05 <pjones> +1
19:53:06 <notting> Kevin_Kofler: it's "require the packages that contain the libraries you use". it's... essentially what we do for python, no?
19:53:07 <ajax> notting: +1
19:53:33 <pjones> cebbert: void * is your friend, eh?
19:53:40 <nirik> #agreed Automatically generated provides/requires must be kept to a reasonable level. Per-library function provides/requires are not reasonable. If you have questions about what is, contact FESCo and/or FPC
19:53:53 <nirik> so, we need to fix the Erland autoprovides/requires as well?
19:53:54 <skvidal> notting: maybe we could augment a bit with: if the number of provides you create is more than 2 orders of magnitude beyond the number of pkgs you create then you're doing it wrong
19:53:55 <notting> oof. that should be 'Per library function'
19:53:58 <nirik> Erlang.
19:54:01 <Kevin_Kofler> FWIW, I vote -1, IMHO it's the Erlang maintainers' decision what to do with their packages.
19:54:02 <Oxf13> Kevin_Kofler: sounds like they need to work more on the generator before turning it live.
19:54:22 <pjones> Kevin_Kofler: that'd be true if it didn't impact other things, but it does.
19:54:25 <Oxf13> Kevin_Kofler: by that argument, FESCo shoudln't exist at all.
19:54:38 <notting> Oxf13: that may be his next suggestion ;)
19:54:38 <Kevin_Kofler> That wouldn't necessarily be a bad thing. ;-)
19:54:40 <mjg59> Kevin_Kofler: When a maintainer's packages interfere with the rest of the distribution, it's a problem
19:54:45 <pjones> Oxf13: overgeneralizing a bit there ;)
19:54:49 <nirik> so, do we need to task someone with fixing this? or ask the maintainer to?
19:55:07 <skvidal> nirik: right now - there's nothing to fix
19:55:17 <skvidal> the pkgs in updates-testing only have a handful of provides/requires
19:55:20 <skvidal> so - it's FINE
19:55:29 <nirik> skvidal: the autoprov/autoreq generator still does the wrong thing.
19:55:32 <ajax> i sure do wish i could do req/prov filtering without breaking rpm color
19:55:34 <skvidal> but it doesn't RUN
19:55:34 <nirik> they just manually fixed the package.
19:55:38 <Kevin_Kofler> skvidal: Well, those are done manually and by disabling the dep generator.
19:55:49 <pjones> disabling it is a fine fix.
19:55:54 <notting> skvidal: so we might want to inform them to disable it/not ship it
19:55:54 <skvidal> nirik: if I disable a section of code b/c it doesn't  work I've still fixed it
19:55:56 <dgilmore> +1 TO NOTTING
19:55:59 <dgilmore> gahh
19:56:00 <nirik> sure, we are fine now, until someone turns it on, or a new erlang package lands with it?
19:56:01 <skvidal> no problem informing them
19:56:12 <skvidal> nirik: which is true of EVERY pkg
19:56:15 <skvidal> not just erlang
19:56:16 <Kevin_Kofler> nirik: Right, so it shouldn't be there in the first place.
19:56:21 <skvidal> nirik: hey
19:56:31 <skvidal> nirik: how about a proposed rpmguard/autoqa test
19:56:33 <nirik> ok. If folks are happy with leaving it at that, then thats ok I guess.
19:56:39 <skvidal> if the number of provides is, say, more than 200
19:56:42 <skvidal> we throw a flag?
19:56:50 <nirik> skvidal: that sounds like a great idea. In fact I think there is one already... for changes in provides/requires.
19:56:54 <skvidal> I'll check
19:56:55 <Oxf13> Kevin_Kofler: so first, we should allow them to do whatever they want with the package, and now we should force them to remove the code instead of just turning it off?
19:57:16 <nirik> ok, shall we move on then? or anything further on this topic?
19:57:39 <nirik> #topic #374 Modify Cloture rule
19:57:39 <nirik> .fesco 374
19:57:40 <zodbot> nirik: #374 (Modify Cloture rule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/374
19:57:40 <Kevin_Kofler> skvidal: Um, kdebase-workspace has 199 Provides.
19:57:46 <Kevin_Kofler> And 30 in kdebase-workspace-libs.
19:57:51 <nirik> Kevin_Kofler: just under the line. ;)
19:57:52 <Kevin_Kofler> kdelibs has 150.
19:58:07 <nirik> anyhow, I got the idea for this from abadger1999. It would in fact have saved us time today...
19:58:15 <notting> Kevin_Kofler: but that's roughly one-per-shared-lib, no?
19:58:23 <Kevin_Kofler> nirik: 4.5 might push it over 200. :-)
19:58:24 <nirik> (well, if we had stopped sooner)
19:58:40 <mjg59> I'm happy enough with this proposal
19:58:43 <dgilmore> skvidal: i think a better chack is did the number of provides increase by more than 5 or 10
19:58:47 <dgilmore> check
19:58:47 <Kevin_Kofler> notting: Yeah, plus some mimehandler(foo) stuff.
19:58:50 <ajax> i'm now no longer sure how this rule counts as cloture at all, but the proposal sounds fine
19:58:56 <skvidal> dgilmore: well, you'd need to avoid the first import, obviously
19:59:00 <nirik> yeah, sorry... probibly doesn't.
19:59:07 <pjones> ajax: it wasn't ever cloture, but that's sortof beside the point
19:59:07 <skvidal> dgilmore: but 200 was just a random number - call it 300 or 500
19:59:44 <notting> i'm fine with this proposal. +1
19:59:56 <skvidal> +1, too
19:59:58 <ajax> +1
19:59:59 <pjones> I think this is worth being an optional thing - we vote continue/writeup/stop
19:59:59 <Kevin_Kofler> +1 to the changed cloture rule.
20:00:02 <dgilmore> im ok with it +1
20:00:16 <pjones> (but I'm basically okay with it as written)
20:00:19 <ajax> pjones: it does say "then ask"
20:00:22 <Kevin_Kofler> It makes sense to give people time to write things up rather than forcing a rushed decison.
20:00:24 <Kevin_Kofler> *decision
20:00:32 <pjones> ajax: it says "instead".
20:01:00 <nirik> #agreed proposal is accepted.
20:01:07 <cwickert> +1
20:01:08 <nirik> #action nirik will writeup change.
20:01:21 <nirik> #topic #375: Bundled library exception for Zikula
20:01:21 <nirik> .fesco 375
20:01:21 <Kevin_Kofler> Either things are important and so they should be discussed fully in the meeting, or they are not, then they can wait a week.
20:01:23 <zodbot> nirik: #375 (Bundled library exception for Zikula) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/375
20:01:29 <ajax> pjones: check notting and kevin's comments.
20:01:41 <pjones> ajax: ah, indeed.
20:01:44 <nirik> pjones: yeah, it should be if we decide not to keep going.
20:02:46 <Kevin_Kofler> +1 to this exception because 1. the library is modified and can't be built against as is and 2. this will be fixed very soon anyway (but the update needs to go out ASAP due to security fixes).
20:03:00 <nirik> I'm ok with this exception... but I would like to make sure we revisit it and make sure it goes away at some point.
20:03:18 <notting> given that upstream is 1) aware of the bundling and 2) working on using stock upstream ... i'm fine with letting them bundle it in this release
20:03:26 <ajax> yeah, fine with me too
20:03:29 <dgilmore> notting: same
20:03:31 <pjones> I think a temporary exception is fine
20:03:38 <dgilmore> as a temporary thing i think its ok
20:03:40 <Kevin_Kofler> I wonder whether they'll really use stock upstream or reinvent their own translation system.
20:03:44 <nirik> how can we properly track revisiting this ?
20:03:56 <pjones> Kevin_Kofler: hard to say, but let's not penalize them for their future actions.
20:03:59 <dgilmore> nirik: leave the ticket open
20:04:03 <cwickert> I think this is different from the wordpress case as upstream wants to fix it. +1 for a timely limited exception
20:04:06 <dgilmore> and revist until fixed
20:04:26 <nirik> dgilmore: yeah, might work.
20:04:59 <nirik> #agreed a temporary exception is granted. Will revisit and make sure 1.3.0 happens without the bundled lib.
20:05:10 <nirik> #topic #376 change provenpackager, sponsor acceptance procedure
20:05:10 <nirik> .fesco 376
20:05:11 <zodbot> nirik: #376 (change provenpackager, sponsor acceptance procedure) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/376
20:05:17 <nirik> notting: this was yours I think.
20:05:34 <notting> technically, it was kevin's original proposal. i modified it some and tossed it in trac
20:05:49 <nirik> ah, true.
20:06:19 <notting> the idea is that sponsors can manage provenpackager and/or sponsor more directly themselves, and objections are escalated to fesco
20:06:44 <nirik> notting: how would we track things?
20:07:17 <Oxf13> as the driving person behind provenpackager, I don't necessarily have a problem with this.
20:07:23 <nirik> at least it would require an admin in the packager group to make sure there were sufficent votes and no objections and changing the user.
20:07:25 <Oxf13> with the second version that is
20:07:28 <notting> we could use the same fesco tickets as a first step.
20:07:44 <nirik> just not make them meeting items unless there is an issue?
20:07:51 <notting> if someone in sponsors wants to make something different, more power to them.
20:07:53 <notting> nirik: yeah
20:08:12 <Kevin_Kofler> notting: Your changes are to make it harder to become provenpackager, as hard as sponsor.
20:08:30 <Kevin_Kofler> I don't see why it's needed to have more than just one sponsor approving somebody for provenpackager.
20:08:40 <notting> how so? the requirements are now 'a fesco vote'
20:08:45 <cwickert> Kevin_Kofler: I think a single +1 is not enough, no matter if proven packager or sponsor
20:08:50 <Kevin_Kofler> Harder compared to my original proposal.
20:08:56 <notting> oh, yes.
20:09:09 <nirik> I also don't think ignoring objections is a good idea.
20:09:49 <cwickert> who says they should be ignored? did I miss something?
20:09:50 <Kevin_Kofler> It'd reduce the number of FESCo votes compared to having one vote for each provenpackager application which is being objected to.
20:09:59 <nirik> cwickert: in Kevin_Kofler's orig proposal.
20:10:21 <nirik> " provenpackager should take 1 sponsor to approve and no possibility to object or veto"
20:10:22 <Kevin_Kofler> (In what I proposed on the ML, this would be only the case for sponsor applications, not provenpackager.)
20:10:32 <nirik> I think thats a bad idea.
20:10:50 <Kevin_Kofler> My proposal was: provenpackagers are sponsored like packagers, 1 sponsor approves and then it's done.
20:11:00 <nirik> I'm +1 to nottings proposal.
20:11:00 <notting> i don't think 3 acks is too much to ask for
20:11:05 <Kevin_Kofler> Sponsors take 3 sponsors and no objections or a FESCo vote.
20:11:19 <cwickert> nirik: ah, for proven packagers... this is a bad idea and I don't see a rationale to treat sponsor and +packager differently
20:11:26 <cwickert> so +1 to notting
20:11:47 <Kevin_Kofler> IIUC, notting's proposal is basically the same as mine for sponsors, but also to apply the same for provenpackagers.
20:11:54 * nirik nods. yep.
20:12:05 <nirik> further votes? comments?
20:12:20 <Kevin_Kofler> Well, I vote +1 for notting because it's a step in the right direction.
20:12:34 <Kevin_Kofler> Though IMHO still too weak and will lead to FESCo having to vote too often.
20:13:00 <ajax> +1 to notting's amended proposal
20:13:05 <Kevin_Kofler> (also because it's not a given that we'll get 3 ACKs for every provenpackager application)
20:13:13 <cwickert> we have 4 +1 atm
20:13:19 <Kevin_Kofler> Still, it's better than the current status quo where FESCo ALWAYS has to vote.
20:13:45 * skvidal reads backscroll
20:13:46 <skvidal> one moment
20:14:36 <skvidal> I can agree with this
20:14:36 <skvidal> +1
20:14:42 <nirik> #agreed nottings proposal is approved.
20:14:48 <mjg59> Yeah, I'm +1
20:15:03 <nirik> notting: you want to mail sponsors on the new procedure and update the wiki? or would you like me to do so?
20:15:43 * pjones +1 as well, for the record
20:16:20 <nirik> I suppose we need: wiki updated, sponsors notified, and a devel-announce to notify maintainers about the change.
20:16:27 <notting> if you're offering... :)
20:16:29 <ardchoille> nirik: I'm free and can update the wiki if someone tells what to add/remove to which page.
20:16:43 <nirik> ok, I can try and do so...
20:16:55 <nirik> ardchoille: thanks. Can I talk with you after the meeting or later today?
20:17:01 <ardchoille> Sure
20:17:19 <nirik> #action nirik will try and update wiki and sponsors and announce to devel-announce.
20:17:21 <dgilmore> +! for notting
20:17:24 <nirik> #topic Fedora Engineering Services tickets
20:17:30 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
20:17:35 <nirik> mmcgrath: you have any updates?
20:17:53 * nirik notes mmcgrath is off on site, and probibly not available.
20:18:11 <nirik> more work on broken deps and cleaning up things.
20:18:29 <nirik> https://fedorahosted.org/fedora-engineering-services/ticket/24
20:18:42 <nirik> This is the ticket to do a 'most active bugs' roundup.
20:18:56 <nirik> Looks like the bugzilla XMLRPC can't handle this query.
20:19:09 <nirik> so, it's back to scraping a query, or just forgetting it. ;(
20:19:40 <nirik> if anyone has ideas on that, post them to the bug.
20:20:53 <nirik> Also, additional ideas on https://fedorahosted.org/fedora-engineering-services/ticket/17 would be welcome.
20:21:24 <nirik> This is the ticket to add support links to our desktops... I think it's going to need coordination with some package like fedora-release-notes, or be a seperate fedora-support-links or something.
20:21:47 <nirik> anyhow, ideas, new tickets, etc welcome.
20:21:54 <nirik> #topic Open Floor
20:22:02 <Kevin_Kofler> The support links idea has come up quite often.
20:22:14 <Kevin_Kofler> One problem is that #fedora requires registration. :-/
20:22:15 <nirik> I have one item for open floor: I will not be around next week. If someone would step up to run the meeting, that would be great. ;)
20:22:25 <Kevin_Kofler> This sucks for being able to provide a quick IRC support link.
20:22:28 <Oxf13> it's just needed time and code to complete it
20:22:29 <nirik> Kevin_Kofler: yeah, of course so does the forum or mailing list to post.
20:22:46 <Kevin_Kofler> They had it turned off at some point, then it got enabled again due to the spam attack and then it got left on.
20:22:51 * notting was noticing complaints about #fedora via the interwebs yesterday
20:22:59 <Kevin_Kofler> nirik: But a forum has obvious registration links.
20:23:04 <nirik> yeah, we decided to leave it on...
20:23:07 <Kevin_Kofler> On IRC registration is very much non-obvious.
20:23:15 <nirik> notting: oh? do tell... here or in private.
20:23:15 <Kevin_Kofler> IMHO registration should not be required on #fedora.
20:23:26 <Kevin_Kofler> #fedora-kde doesn't require registration and it's not a problem at all.
20:23:29 <Oxf13> Kevin_Kofler: those that run #fedora really have the say on that.
20:23:45 <Oxf13> the #fedora-* channels are far less of a target than #fedora itself.
20:23:48 <nirik> Kevin_Kofler: it redirects you to #fedora-unregistered. A entry message, bot and topic all show you how to register. Also, some people stay active there and help people who can't register.
20:24:12 <nirik> it has VASTLY cut down on drive by junk.
20:24:34 <nirik> when people see they have to register to join they are less tempted to troll.
20:25:28 <Kevin_Kofler> The registration requirements for MLs are also a PITA, FWIW, IMHO there ought to be a better way to filter spam than this whitelisting system. :-/
20:25:32 <nirik> anyhow, for anyone who would like it to change, come to the irc-support-sig meeting thursday mornings in this very channel to provide your view. ;)
20:26:03 <nirik> anyone willing to run the meeting next week, let me know. Any other open floor items?
20:26:31 <skvidal> i do not think I can do it next week
20:26:43 <skvidal> I may not be able to make the meeting due to drs appt
20:27:19 <notting> looks like i can
20:27:43 <nirik> notting: thanks very much. There's a slight chance I might be back in time, but I don't think I will.
20:28:06 <nirik> ok, will close out the meeting in a minute if nothing else comes up.
20:28:12 <nirik> oh.
20:28:33 <nirik> #info everyone should read https://fedoraproject.org/wiki/F14_elections_questionnaire and attend town halls, and VOTE.
20:29:08 <nirik> #endmeeting