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