19:00:01 <nirik> #startmeeting FESCO (2010-05-04)
19:00:01 <zodbot> Meeting started Tue May  4 19:00:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:01 <nirik> #meetingname 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> The meeting name has been set to 'fesco'
19:00:01 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:11 <Kevin_Kofler> Present.
19:00:20 * skvidal is here
19:01:17 * pjones is here
19:01:38 * notting is here
19:01:50 * nirik waits another minute or two
19:02:19 * dgilmore is here
19:03:12 <nirik> ok, I guess we can go ahead and get started.
19:03:24 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:03:37 <nirik> cwickert and notting were going to work on comps groups? anything to report there?
19:03:51 <Kevin_Kofler> So KDE SIG came up with a list of critical KDE packages as you asked for.
19:03:53 <notting> i have patches. need to push them.
19:04:03 <nirik> Kevin_Kofler: cool.
19:04:28 <nirik> Kevin_Kofler: can you do a patch against comps? or have someone from kde sig do so and send to notting?
19:04:33 <Kevin_Kofler> Several of us had reservations about the usefulness of the process, but in the end a nonempty list was voted (for the record, I voted against it, I wanted the list to be empty).
19:04:53 <Kevin_Kofler> The list is: kdm, kdelibs and all their dependencies (which includes qt-x11 and qt in particular).
19:05:17 <nirik> ok.
19:05:22 <drago01> what about stuff like kdebase?
19:05:26 <dgilmore> Kevin_Kofler: stop just making noise
19:05:29 <Kevin_Kofler> We decided not to consider all of kdebase-workspace and its transitive closure to be critical at this time because it has too many dependencies.
19:05:56 <notting> Kevin_Kofler: kdm and kdelibs? thx.
19:05:57 <Kevin_Kofler> kdebase-workspace itself will be protected due to kdm being (it's a subpackage of kdebase-workspace).
19:06:15 <nirik> sounds good.
19:06:21 <Kevin_Kofler> dgilmore: How is this noise?
19:06:31 <Kevin_Kofler> I have been asked to bring this up in KDE SIG, I did.
19:06:34 <dgilmore> Kevin_Kofler: critical path should be the minimal package set to run a kde session
19:06:49 <dgilmore> Kevin_Kofler: adding unnessecary extra commentry
19:07:39 <nirik> anything else on updates implementation for now?
19:07:45 <Kevin_Kofler> If you had followed the KDE SIG meeting, you'd have noticed how factual my report is.
19:08:11 <notting> i'll get the changes pushed to comps-f14 today-ish
19:08:18 <nirik> notting: thanks.
19:08:26 <nirik> #topic #371 Change package owner of ddclient (as "subhodip" is nonresponsive)
19:08:26 <nirik> .fesco 371
19:08:27 <zodbot> nirik: #371 (Change package owner of ddclient (as "subhodip" is nonresponsive)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/371
19:09:06 <nirik> It's worth noting that rsc has all acls for this package and has updated it... he just wanted the primary owner changed.
19:09:18 * dgilmore thinks there is nothing for us to do here. we have a process for this that has not been followed
19:09:26 <dgilmore> it was recommended that it be started
19:09:37 <Kevin_Kofler> Well, this is a fasttrack nonresponsive request AFAICT.
19:10:00 <nirik> yeah, this is the fast track version of the non responsive maintainer process.
19:10:30 <nirik> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
19:10:30 * pjones isn't sure why this needs a fast track if somebody else has ACLs and is doing the work.
19:10:46 <Kevin_Kofler> Yeah, I don't see a big need for a fasttrack either here.
19:11:02 <Kevin_Kofler> Or are there other packages "maintained" by the same AWOL maintainer?
19:11:10 <dgilmore> pjones: i fully agree
19:11:23 <nirik> yes, he does maintain others.
19:11:48 <rsc> nirik: I started regular AWOL already with another bug report, but it will take some weeks of course.
19:12:00 <nirik> http://fpaste.org/6Nsh/
19:12:13 <dgilmore> there is no need to fast track it
19:12:20 <dgilmore> regualr process has started move on
19:12:22 <nirik> rsc: is there some urgency?
19:12:26 <rsc> nirik: nope.
19:12:55 <nirik> ok, then follow the regular procedure for now? ;)
19:13:15 <nirik> Any objections to that? moving on in a minute...
19:13:18 <rsc> nirik: already started doing so.
19:13:32 <rsc> nirik: (after cwickert pointed out that)
19:13:54 <ajax> (here now)
19:14:14 <skvidal> ajax: you didn't miss much :)
19:14:32 * nirik gets a page from dayjob.
19:14:40 <nirik> #topic #370 allow bundling libiberty
19:14:40 <nirik> .fesco 370
19:14:45 <zodbot> nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370
19:15:06 <ajax> worst library name ever
19:15:34 <mjg59> Hey, sorry
19:15:50 <dgilmore> where is its upstream?
19:15:55 * nirik may be slow to respond. If someone else could take over running things that would be great.
19:16:02 <pjones> dgilmore: gcc
19:16:20 <Kevin_Kofler> Sadly, libiberty is the perfect example of the GNU project being completely inept at following proper engineering practices such as shipping libraries as such instead of bundling. :-(
19:16:36 <mjg59> Got stuck in a meeting
19:16:47 <dgilmore> pjones: thanks found it
19:16:50 <dgilmore> #info http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using
19:16:51 <ajax> libiberty and gnulib are both like this.
19:16:52 <Kevin_Kofler> Other offenders from the same upstream are gnulib, and the many copies of junk generated by auto*.
19:16:53 <pjones> the documentation does explicitly recommend bundling it, so it seems like that's probably okay.
19:17:02 <pjones> (even if it is pretty silly.)
19:17:22 <Kevin_Kofler> It's extremely stupid. :-/
19:17:23 <dgilmore> indeed it seems pretty dumb
19:17:41 <ajax> much as i dislike the gnu project in general, and libiberty in specific, it's not something we should correct for.
19:17:42 <Kevin_Kofler> But I also strongly doubt we have any chance to convince upstream to change this.
19:17:50 <mjg59> The first question is whether binutils actually uses libiberty for anything on Linux
19:17:58 <Kevin_Kofler> We could require building against e.g. binutils-devel for libiberty.
19:18:08 <Kevin_Kofler> But that'd hardlock all the libiberty-using packages together.
19:18:13 <Kevin_Kofler> As there's obviously no ABI.
19:18:20 <Kevin_Kofler> Or even API.
19:18:29 <Kevin_Kofler> And it's static-only, too.
19:18:29 <pjones> well, there is API, but it's sortof a slow-moving target
19:18:58 <dgilmore> sadly i dont think the fsf will listen to reason on this
19:19:09 <pjones> having a stable API sortof defeats the whole point of the library
19:19:44 <ajax> dgilmore: gnu project not fsf, but either way.
19:20:08 <ajax> so, proposal: allow bundling of libiberty and gnulib
19:20:14 <ajax> (+1 from me)
19:20:15 <pjones> anyway, upstream says this is the recommended way of using this.
19:20:15 <skvidal> ajax: +1
19:20:17 <pjones> +1
19:20:32 <mjg59> +1 for pragmatic reasons
19:20:37 <Kevin_Kofler> How's this different from e.g. bundling JARs which we don't allow?
19:20:37 <pjones> mjg59: exactly.
19:20:44 <Kevin_Kofler> -1 from me.
19:20:49 <mjg59> I doubt there's any real way that anything in the libiberty paths would be a security issue
19:20:49 <dgilmore> +1  i dont think we should fight it at this point in time
19:21:10 <mjg59> Most of what it's used for will be native functionality on Linux anyway
19:21:13 <Kevin_Kofler> The upstreams of Java projects also often recommend bundling their JAR.
19:21:15 <pjones> Kevin_Kofler: it's really more akin to linking against libgcc_s, but...
19:21:16 <Kevin_Kofler> We still don't allow it.
19:21:28 <skvidal> that looks like 5 +1's to me
19:21:36 * notting_ is +1. if this gets through.
19:21:38 <pjones> Kevin_Kofler: mjg59 has a point - it's presence on a linux machine is basically eliminated during compilation.
19:21:47 <Kevin_Kofler> Parts of it, sure.
19:21:52 <pjones> notting_: duly noted.
19:21:55 <skvidal> 5 +1 == 's carries
19:21:58 <skvidal> we have 6 now
19:21:59 <skvidal> we're done
19:21:59 <Kevin_Kofler> But libiberty also has stuff like obstacks, a C++ demangler etc.
19:22:01 <skvidal> next subject?
19:22:19 <pjones> obstacks are also in glibc though
19:22:24 <Kevin_Kofler> E.g. kdesdk links to libiberty from binutils-static (NOT a bundled one) for the demangler.
19:22:25 <nirik> #topic #373: erlang provides/requires explosion
19:22:25 <nirik> .fesco 373
19:22:27 <zodbot> nirik: #373 (erlang provides/requires explosion) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/373
19:22:32 <Kevin_Kofler> pjones: The demangler is not.
19:22:42 <pjones> true, but again, more akin to libgcc_s
19:22:48 <pjones> anyway, 6 votes = done
19:23:02 <pjones> so, those erlang packages.  pretty crazy stuff.
19:23:09 <Kevin_Kofler> 6 votes based on false premises = "done", but not good.
19:23:11 <Kevin_Kofler> :-/
19:23:25 <Kevin_Kofler> Not all of libiberty effectively vanishes on GNU/Linux.
19:23:28 <Kevin_Kofler> Only large parts.
19:23:29 <pjones> have you ever considered not calling us all inept every chance you get?
19:23:33 <skvidal> we're moving on
19:23:42 <skvidal> erlang is the current subject
19:24:01 <Kevin_Kofler> So on the current subject: this is how things are, what are we discussing?
19:24:03 <Kevin_Kofler> Move on.
19:24:21 <dgilmore> so erlang autodeps really need to be looked at and fixed
19:24:28 <skvidal> the erlang pkgs are producing 32% of all of our provides
19:24:31 <ajax> skvidal: what _is_ it autoproviding?
19:24:38 <skvidal> every function
19:24:52 <skvidal> every function is a separate provide
19:24:59 <pjones> that's pretty bogus.
19:25:02 <notting> every used function is a separate require
19:25:02 <notting> etc.
19:25:09 <ajax> harden up guys.
19:25:11 <Kevin_Kofler> If that's how Erlang works, that's how it is.
19:25:11 <notting> this is a change in the current updates-testing packages, afaict
19:25:11 <skvidal> pjones: agreed
19:25:29 <skvidal> notting: yes. and it is b/c they added their own find-provs
19:25:30 <pjones> Kevin_Kofler: I could argue that that's how C works, but that doesn't make it a good way to package it.
19:25:35 <notting> the in-F13 packages (and in-f12, etc) aren't like that
19:25:49 <notting> and one of the co-maintainers has commented in the bug that he doesn't see the use of it either
19:25:54 <Kevin_Kofler> C is linked per shared object.
19:26:07 <Kevin_Kofler> I don't know how Erlang projects are linked.
19:26:09 <skvidal> I think we need to consider nacking these pkgs
19:26:12 <mjg59> Before we go any further with this, I'd like to see whether this is as-designed or a bug
19:26:30 <skvidal> mjg59: as designed, from the bug comments
19:26:49 <mjg59> Oh, sorry, I missed the buglink
19:27:03 <skvidal> mjg59: at the bottom of the fesco ticket
19:27:07 <mjg59> Yeah, got it now
19:27:08 <skvidal> mjg59: https://bugzilla.redhat.com/show_bug.cgi?id=564018
19:27:42 <skvidal> so - I brought the ticket up b/c I just wanted to make sure it has everyone's attention
19:27:59 <skvidal> but I thnk the proposal should be something like: erlang cannot make provides like this
19:28:08 <skvidal> and we nack the pkgs in updates-testing
19:28:42 <ajax> i have a very minor issue with forbidding prov/reqs like this if that's how the language actually works.  but i don't think it's how erlang actually works.
19:28:55 <Kevin_Kofler> -1, it's not our job to decide this without any input from the Erlang maintainers.
19:28:58 <pjones> Kevin_Kofler: C is not linked per shared object. If symbol resolution fails, the link fails.
19:29:05 <skvidal> ajax: well, if this is how the language actually works - then I think we need to ban the language from fedora
19:29:13 <mjg59> Kevin_Kofler: Where a maintainer's decision affects the rest of the project then it's exactly our job
19:29:13 <skvidal> ajax: or have a separate, optional, repo for it
19:29:28 <skvidal> ajax: b/c we're in deep shit if we have to have to deal with this all over the place
19:29:30 <mjg59> The question is whether this is the least worst solution or not
19:29:38 <skvidal> ajax: it's a big jump for our metadata size
19:29:43 <notting> Kevin_Kofler: https://bugzilla.redhat.com/show_bug.cgi?id=564018#c36 implies that there is a better way to do this
19:29:56 <ajax> skvidal: i'm not saying there wouldn't be technical issues.
19:30:00 <skvidal> ajax: and for depsolving it only impacts the erlang* pkgs - but it impacts everyone for download metadata
19:30:17 <ajax> certainly.
19:30:44 <ajax> as far as bailiwick goes, i'm pretty sure this is _exactly_ the sort of issue fesco is for.
19:30:47 <Kevin_Kofler> skvidal: Maybe we need a new metadata subset, like erlang.sqlite.bz2? :-)
19:30:56 <skvidal> also - from a use of resources standpoint it's unfair, if nothing else
19:31:13 <skvidal> .007% of the pkgs in the distribution consuming 6% of the metadata size seems 'unfair'
19:31:15 <notting> fwiw, this got noticed when i noticed an update transaction taking 1-2 minutes to depsolve
19:31:29 <skvidal> I know we have no obligation of fairness - but it seems like we should have _something_
19:31:47 <pjones> there's a nontrivial difference in e.g. seek time while reading the db here
19:31:55 <pjones> (which I think is probably at least related to what notting just said.)
19:31:55 <mjg59> proposal: We block these packages from migrating out of updates-testing until a full discussion of the impact on the rest of the distribution has been had and alternative implementations explored
19:32:10 <ajax> mjg59: +1
19:32:11 <dgilmore> mjg59: +1
19:32:12 <skvidal> mjg59: +1
19:32:14 <pjones> mjg59: +1 to that
19:32:19 <mjg59> (+1, obv)
19:32:36 * notting is +1 in theory, but notes we don't have infrastructure to *enforce* that
19:32:39 <skvidal> notting: iirc the transaction was full of erlang pkgs
19:32:46 <notting> skvidal: yes, it was
19:32:52 <mjg59> notting: Can we disable automigrate and ask the maintainers not to push?
19:33:14 <notting> ... we can always ask, sure
19:33:17 <mjg59> (I'm assuming that the maintainers aren't pathological)
19:33:34 <Kevin_Kofler> +1 to mjg59's proposal, but we need to allow for the possibility of the discussion being that this way is the right way.
19:33:45 <Kevin_Kofler> *the outcome of the discussion being
19:33:50 <mjg59> Kevin_Kofler: That leads to a different discussion, but yes
19:34:03 <mjg59> It may be that there is no better technical solution given the way Fedora currently works
19:34:11 <mjg59> Which then leads to policy discussion instead
19:34:23 <pjones> Kevin_Kofler: the bugzilla url notting pasted above pretty much discounts that, but sure, there's some chance it's wrong.
19:34:29 <skvidal> mjg59: and probably some technology discussions at the packaging level
19:34:37 <skvidal> mjg59: and repository metadata
19:35:19 <notting> so that's 6+1. who gets to do the notification?
19:35:32 <mjg59> I'll do it
19:35:39 <mjg59> Where do we want to have this discussion?
19:36:01 <skvidal> in the ticket?
19:36:05 <skvidal> or in the bug
19:36:07 <skvidal> ?
19:36:10 <notting> we can cc the maintainers on the fesco ticket. note that the submitter of the update is the co-maintainer, techncially
19:36:44 <mjg59> Ok
19:37:02 <notting> so, probably cc gemi, peter, and ndim
19:37:21 <skvidal> sounds good. thanks everyone
19:38:02 <skvidal> is that everything?
19:38:22 <skvidal> or did the network just esplode?
19:38:48 <mjg59> nirik had to drop off for a bit
19:39:04 <nirik> sorry, fighting a work fire...
19:39:14 <nirik> #topic Open Floor
19:41:34 <nirik> anything for open floor?
19:41:51 <ajax> nothing from me
19:41:52 <skvidal> doesn't look like it
19:42:00 <Kevin_Kofler> FYI, I'm not rerunning for FESCo.
19:42:07 <ajax> really.  you don't say.
19:42:11 <Kevin_Kofler> And everyone who follows the devel ML will know why. :-)
19:42:33 <nirik> ok, thanks for coming everyone.
19:42:37 <nirik> #endmeeting