FESCo meeting summary for 2009-07-31

Friday, 31 July 2009

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting...

--------

16:59:31 <jds2001> #startmeeting FESCo meeting 7/31/09
16:59:33 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
16:59:40 * nirik is here.
16:59:51 * pingou around
16:59:53 * sharkcz here
17:00:05 * jwb is here
17:00:14 <Kevin_Kofler> Present.
17:01:00 <jds2001> sorry for the false alarm re: lunch
17:01:02 * dgilmore is here
17:01:07 * skvidal is here
17:01:09 <jds2001> got the food to go :)
17:01:17 <jds2001> anyhow, let's get started
17:01:35 <jds2001> #topic mikeb as sponsor
17:01:40 <jds2001> .fesco 211
17:01:52 <jds2001> looks like he withdrew his request.
17:01:52 <dgilmore> +1
17:01:52 * notting is here
17:02:26 <nirik> I disagree that we should base this on quantity. I
think that him doing more reviews to gain visibility and prove his
understanding would be good too tho.
17:02:29 <jds2001> but that being said, I'd still be +1
17:02:32 <dgilmore> because of the nosie made about it
17:02:47 <jds2001> yes, same here, i dont think that quantity is a
good indicator.
17:03:14 <jwb> he withdrew his request
17:03:22 <dgilmore> he did
17:03:25 <jds2001> he also mentioned a desire to work on the backlog
17:03:26 <dgilmore> move on
17:03:26 <nirik> so, lets ask him to reapply in a month or something...
17:03:31 <jds2001> yeah
17:03:33 <Kevin_Kofler> Well, feedback from the sponsors list was
overwhelmingly negative.
17:03:45 <jds2001> based on quantity
17:03:49 <Kevin_Kofler> If you think sponsors are basing their
feedback on the wrong criteria, we need to get the criteria fixed.
17:03:52 <jds2001> based on flawed criteria.
17:04:17 <tibbs> Please don't ask our opinions if you don't like the
answers you receive.
17:04:17 <Kevin_Kofler> Or rather, clearly defined, because it seems
they aren't.
17:04:36 <jds2001> they aren't.  And they shouldn't be.
17:04:57 <jds2001> it's a subjective thing, really
17:05:01 <Kevin_Kofler> I agree with tibbs, it's ridiculous to ask for
feedback from the sponsors and then to ignore it.
17:05:02 <tibbs> So you won't define criteria, but yet you can easily
say that someone else's criteria are flawed?
17:05:02 * nirik notes there was only one -1
17:05:04 <jwb> jds2001, then you can't really say their criteria is flawed
17:05:10 <tibbs> That's really a poor method of argumentation.
17:05:30 <Kevin_Kofler> And saying they're basing their decision on
flawed criteria doesn't make sense when there are no criteria defined
at all.
17:05:42 <jds2001> tibbs: sorry, I meant that other things should be
taken into account
17:05:49 <nirik> there was one -1 (from someone who thinks quantity is
important) and a bunch of discussion about the process from various
other people.
17:05:51 <Kevin_Kofler> So I stay with my -1 vote.
17:05:54 * jds2001 notes the feedback was based on quantiy of reviews.
17:06:07 <jds2001> solely, and nothing else.
17:06:17 <skvidal> umm
17:06:27 <skvidal> why are we discussing a withdrawn item?
17:06:29 <Kevin_Kofler> nirik: What you call "discussion" was "I
agree" to the person saying -1.
17:06:30 <skvidal> let's move along
17:06:44 <jds2001> agreed.
17:06:49 <Kevin_Kofler> And I think I've seen more than one explicit
-1 too, but I may be remembering wrong.
17:07:07 <jds2001> #topic Fedora packages as canonical upstreams
17:07:11 <nirik> Kevin_Kofler: I just reread the thread. Thats the
only -1. ;) anyhow...
17:07:11 <jds2001> .fesco 210
17:07:29 <tibbs> This was proposed to FPC, but it's not really FPC's
decision.
17:07:45 <jds2001> so there's some sticky situations here.
17:07:46 <Kevin_Kofler> -1 to removing the exception, it makes no sense.
17:07:58 <jds2001> If there is code, then the exception needs to be removed.
17:08:07 <jwb> jds2001, huh?
17:08:14 <Kevin_Kofler> There are plenty of upstreams with no
tarballs, only some SCM, some SRPMs or other source packages etc.
17:08:16 <jds2001> If there's not, then it can stay (I particularly
looked at basesystem)
17:08:18 <nirik> what would be valid as a upstream here? a fedorapeople link?
17:08:32 <jds2001> nirik: or a fedorahosted project
17:08:36 <jds2001> nothing extravagant
17:08:38 <Kevin_Kofler> There are also plenty of upstreams which just
dump a tar.bz2 into some directory.
17:08:43 <jds2001> but basesystem has nothing.
17:08:45 <nirik> so this is saying that every package needs a Source0:
that is a url?
17:08:51 <jwb> Kevin_Kofler, those aren't want this is about...
17:08:51 <Kevin_Kofler> If we do that, is that really more helpful
than just having it in the SRPM?
17:08:55 <jds2001> nirik: thats how i read it.
17:08:56 <tibbs> We complain when suse makes you pull sources out of
one of their packages.
17:09:04 <jwb> Kevin_Kofler, ah, i see where you are going
17:09:07 <Kevin_Kofler> jwb: Why should we be held to higher standards
than other upstreams?
17:09:13 <jwb> right, got it now
17:09:28 <nirik> I see advantages of this, but it could cause issues too.
17:09:39 <jds2001> at the time the exception was drafted, we didnt
have something like fedorahosted.
17:09:54 <jds2001> pointing to a git repo is imo valid.
17:10:02 <jds2001> or an ftp site, or whatever
17:10:07 <jwb> ok, i have 3 issues with this
17:10:13 <jwb> 1) it's scoped to RH when it shouldn't be
17:10:13 <nirik> not wanting to wade thru a flamefest, I would like to
defer this till next week and ask for feedback on fedora-devel.
Perhaps there are situations here that we need to deal with?
17:10:32 <notting> still, i'm not sure that making people open up FH
projects just to have a place to dump tarballs is efficient
17:10:32 <jwb> 2) i agree with Kevin_Kofler that it doesn't really
seem to be needed
17:10:40 <jwb> and 3) what notting just said
17:10:49 <jwb> so i'm -1
17:11:01 <tibbs> To be fair, I guess Rahul should be asked why he
thought this was necessary.
17:11:03 <jds2001> notting: they could put it on fedorapeople.
17:11:14 <jwb> jds2001, how is that better?
17:11:17 <nirik> jds2001: but thats true of anything right?
17:11:25 <jds2001> right
17:11:25 <notting> jds2001: do we have an example package?
17:11:35 <tibbs> He submitted the original draft.  FPC has no opinion
on the issue.
17:11:44 <notting> obviously, any $foo-filesystem that's just a spec
doesn't count
17:11:49 <jds2001> i looked at basesystem last night.  It has nothing
17:12:01 <tibbs> basesystem needs to just go away anyway.
17:12:05 <jds2001> it would stand to lose from removing this exception actually
17:12:07 * j-rod finally starts paying attention
17:12:09 <Kevin_Kofler> kde-settings has a fedorahosted.org SVN these
days, but no tarballs.
17:12:17 <jds2001> tibbs: i agree...
17:12:22 <jds2001> Kevin_Kofler: that's fine.
17:12:23 <nirik> there are a number of packages that don't use a url.
For various reasons.
17:12:28 * skvidal tries to understand which direction to vote
17:12:36 <tibbs> I don't believe tarballs are in any way required in any case.
17:12:37 <jds2001> it's a tricky issue
17:12:38 <skvidal> are we voting to remove the exception?
17:12:42 <nirik> perhaps we should ask the submitter to rewrite?
17:12:44 <Kevin_Kofler> We export from SVN and make new-sources with
the resulting tarball.
17:12:47 <jds2001> skvidal: i say defer
17:12:51 <jds2001> NEEDINFO
17:12:51 <skvidal> if I vote +1 am I in favor of the exception or in
favor of removing the exception
17:12:59 <jds2001> Why is this necessary?
17:13:04 <skvidal> jds2001: agreed - and I don't think this is
particularly pressing
17:13:07 <jds2001> skvidal: youre in favor of removing it.
17:13:08 <dgilmore> +1 to removing the exception,  there is no excuse
not to publish tarballs
17:13:19 <tibbs> jds2001: I can't answer why it's necessary, sorry.
17:13:29 <tibbs> I don't know why Rahul wants this to go away.
17:13:33 <notting> Kevin_Kofler: you publish tarballs at
http://cvs.fedoraproject.org/lookaside/pkgs/kde-settings/
17:13:34 <j-rod> +1, no exception, you're not that special. :)
17:13:59 <jwb> j-rod, for RH packages, or anything?
17:14:03 <j-rod> ("you" being nebulous, not anyone in particular...)
17:14:09 <jwb> it's flawed as written
17:14:14 <jwb> it needs clarification at best
17:14:20 <Kevin_Kofler> notting: Sure, but that's the case for the
packages covered by that exception as well. :-)
17:14:25 <jds2001> it is, if there's an exception it shouldnt be limited to RH
17:14:33 <j-rod> I probably need to re-read, I only vaguely recall details
17:14:40 <Kevin_Kofler> You necessarily have something in the
lookaside cache to build your SRPM.
17:14:43 <tibbs> I don't believe the current exception is limited to Red Hat.
17:14:57 <tibbs> Red Hat is used by way of example.
17:15:13 <tibbs> Rahul's draft is simply incorrect on that point,
which I mentioned in the FEESo ticket.
17:15:36 <nirik> it would also be nice to have a list of affected
packages or how to identify them (can they be identified)?
17:15:42 <jwb> tibbs, i know you noted it.  i don't want to vote on
something that has noted incorrect information
17:15:53 <jds2001> i tried last night, but it's hard :(
17:15:55 <nirik> anyhow, I am 0 on this now, I want more info on it's
goals and if it's RH specific, etc.
17:16:12 <tibbs> nirik: I don't believe it's easy to find packages
which do this.
17:16:21 <jds2001> anyhow, shall we move on?
17:16:30 <tibbs> Technically they need a comment about it, but I doubt
they all do and I doubt there's anything you could grep for.
17:16:36 <nirik> right. Since no url could be us repackaging the
source, or a vcs checkout, or other.
17:16:43 * notting is -1. i don't feel setting up a FH tarball repo is
really any improvement over pointing people at
cvs.fp.o/looksaide/<name>
17:17:24 <notting> though i'll laugh at the first package that
actually puts that URL in their spec file
17:17:35 <jds2001> so let's defer.
17:17:38 <jds2001> notting: huh?
17:17:40 <j-rod> oh, hrm, if people can just fetch the tarball there...
17:18:03 <jds2001> notting: Source0 is supposed to be
http://<wherever>/<whatever>/tarball.tar.gz
17:18:06 <tibbs> Well, the source has to be in the package regardless,
so sure, you can grab it from the lookaside.
17:18:22 <tibbs> jds2001: Only when that actually makes sense.
17:18:24 * j-rod gets it :)
17:18:31 <notting> jds2001: using the lookaside URL as the URL tag in
their spec file
17:18:36 <nirik> it could be that the intent here is to move projects
to fedorahosted not just for the tar download, but for bugtracker,
wiki, more active community, etc.
17:18:51 <jwb> jds2001, and that url can be
cvs.fp.org/lookaside/pkgs/<package>/<tarball>
17:18:51 * nirik votes we ask mether to re-write and move on for now.
17:18:59 <jds2001> notting: oh yeah, I'd laugh at that to :)
17:19:08 <notting> nirik: yes, but forcing that on any project that
may not have a current upstream is a bit out of our scope, i think
17:19:09 <jds2001> sounds good
17:19:15 <nirik> notting: agreed.
17:19:17 <jwb> jds2001, it illustrates how really silly this all is
17:19:29 <Kevin_Kofler> FWIW, another case where a URL doesn't make
sense is kde-apps.org/kde-look.org where they have
strange?url=s&with=parameters. You can't give such a URL and have it
be a valid Source0...
17:19:34 <Kevin_Kofler> But that's already covered by the guidelines.
17:19:52 <jds2001> #agreed Proposal is deferred until additional
information can be obtained.
17:20:04 <jds2001> I'll update the ticket with the concerns later
17:20:10 <j-rod> ok, so clarification on what upstreams this should
actually apply to definitely needed
17:20:21 <jds2001> yep
17:20:29 <jds2001> #topic FPC report
17:20:33 <jds2001> .fesco 232
17:21:13 <jds2001> i need to read these....
17:21:37 <notting> one at a time?
17:21:40 <jds2001> yeah
17:21:46 <jds2001> dos2unix im +1 on
17:21:51 <notting> https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix
17:21:55 <sharkcz> +1
17:21:56 <nirik> +1 on dos2unix. No brainer.
17:22:00 * notting is +1 to this.
17:22:10 <Kevin_Kofler> +1 from me too, makes a lot of sense and FC3 is dead.
17:22:11 <skvidal> +1 dos2unix
17:22:13 <jwb> +1
17:22:45 <j-rod> +1
17:23:13 <skvidal> ? on the autoprovides/req filtering
17:23:18 <skvidal> the summary says
17:23:30 <skvidal> MUST: When filtering automatically generated RPM
dependency information, the filtering system implemented by Fedora
must be used, except where there is a compelling reason to deviate
from it.
17:23:37 <notting> #agreed dos2unix draft is approved
17:23:43 <skvidal> how will a "compelling reason" be defined?
17:23:49 <jds2001> skvidal: that means the macros below
17:23:59 <jds2001> skvidal: reviewer discretion, I guess
17:24:02 <Kevin_Kofler> I'm confused by the "These filtering macros
MUST only be used with packages which meet the following criteria:
..." part.
17:24:24 <Kevin_Kofler> There are several packages currently using
Provides/Requires filtering which don't fulfill those criteria.
17:24:26 <Kevin_Kofler> For example xchat.
17:24:52 <tibbs> The issue is that you break multilib when you disable
the internal dependency generator.
17:25:13 <Kevin_Kofler> Also some packages which should use such
filtering, like the KDE packages with plugins which are mentioned in
the rationale.
17:25:19 <notting> as i understand it, until we have a solution that
honors multiarch coloring, this is not recommended for any package
that may end up needing it, just to avoid things breaking by accident
17:25:36 <notting> you could do it in xchat, as long as you know
enough to know that the subpackages that put things in %{_bindir} will
never be multilib
17:25:50 <jwb> i need to step away for a few min
17:25:54 <notting> but that's hard to put in a guideline, so it's more
conservative by default
17:26:12 <notting> now, my concern is that by limiting it to noarch,
you'll have no takers :)
17:26:29 <tibbs> Perl needs this all the time.
17:26:37 <Kevin_Kofler> What do we do about the KDE packages with
plugins? Just ignore the bogus Provides as we've always done until we
have a solution for the multiarch coloring problem?
17:26:57 <tibbs> Any such solution is going to have to come from the RPM folks.
17:27:05 <tibbs> Or at least will require changes in RPM itself.
17:27:12 <Kevin_Kofler> Understood.
17:27:45 <notting> so, i think the 'compelling reason' needs to
explicitly list 'package does not meet the criteria listed below'. as
i don't want to make those people *stop* filtering
17:27:53 <Kevin_Kofler> "<notting> you could do it in xchat" ->
But
the guideline says I MUST NOT do it. :-(
17:28:30 <Kevin_Kofler> Well, it says the macros are banned, but what
xchat does now is the same done by hand.
17:29:18 * nirik wonders if the first MUST there could just be fixed
by rpm only adding provides to .so's in the library path...
17:29:29 <tibbs> So you somehow know that xchat will never ever be multilib?
17:29:54 <tibbs> If you can tell us how you know that, we can modify the draft.
17:30:01 <Kevin_Kofler> Well, there's no xchat-devel, but some people
have asked for one to build plugins.
17:30:18 <Kevin_Kofler> So we could end up with a mess.
17:30:34 <tibbs> Input given to FPC didn't indicate that a -devel
package was required for something to be multilib.
17:31:09 <notting> tibbs: i, like kkofler, am concerned about the
'must'-ness of the proposal - i don't want to ban\ the people who
cannot use it now
17:31:14 <tibbs> I suppose we could say it's acceptable if the package
can never be multilib, without stating just how you'd know this.
17:31:21 <Kevin_Kofler> It's trivial to remove the Provides filtering
from xchat, but then we'll have xchat providing perl.so and python.so
and xchat-tcl providing tcl.so.
17:31:53 <Kevin_Kofler> (That's why the filtering got added in the first
place.)
17:32:27 * nirik has another case in 'heartbeat'. :( It's not
currently filtering, but perhaps it should be.
17:32:45 <tibbs> People generally don't like it when those things are
in guidelines, but I don't think more than a couple of people actually
understand the multilib driteria.
17:32:50 <tibbs> criteria.
17:32:54 <nirik> can't we get rpm to not add those when the .so's are
not in a 'standard' place? then people who need to add them in weird
places could be the exception.
17:32:55 <Kevin_Kofler> I think there are several affected packages
which probably should be doing filtering.
17:33:06 <Kevin_Kofler> E.g. pretty much any KDE packages including
KParts or other KDE plugins.
17:33:09 <dgilmore> nirik: likely
17:33:29 <Kevin_Kofler> (That's most of the core KDE modules and a few
third-party KDE applications.)
17:33:48 <tibbs> And you're certain that none of those packages will
ever be multilib?
17:34:02 <Kevin_Kofler> Most definitely not.
17:34:06 <tibbs> If you're not, the work needs to be directed at rpm
to fix the underlying issue.
17:34:11 <notting> nirik: ld.so.conf.d could contain a file which
magically makes your libraries part of the ystem
17:34:12 <Kevin_Kofler> That's exactly how this solution is failing us.
17:34:27 <tibbs> So you know of a better solition?
17:34:29 <Kevin_Kofler> So on one hand, we MUST filter and on the
other hand we MUST NOT filter as we break multilib.
17:34:48 <nirik> heartbeat is multilib.
17:35:17 <tibbs> The draft as presented avoids that issue.  It is not
as useful as the utopian solution that does not exist.  If you wish to
vote against it based on that, you have the option.
17:35:24 <Kevin_Kofler> nirik: Some of the affected KDE packages are,
too, at least the -libs subpackages are.
17:35:51 <tibbs> Maybe FESCo has the power to get the rpm folks to
offer a better solution.  FPC doesn't.
17:36:04 <jds2001> tibbs: that'd be nice :)
17:36:11 <jds2001> but unlikely to happen :)
17:36:44 <tibbs> So are there any unanswered questions relating to
this draft that I could help with?
17:36:45 <Kevin_Kofler> Has rdieter commented on the KDE plugins (in
partly-multilib packages) issue during the FPC discussion?
17:36:45 <jds2001> We can certaintly request that the RPM folks tell
us their preferred solution, though
17:37:52 <tibbs> I do not recall any discussion relating to KDE in the
discussion.
17:38:09 <tibbs> redundandancy.
17:38:16 <notting> tibbs: is it possible to say 'mandatory to use this
if your packages meet the criteria. if they do not, use this only if
you Really Know What You're Doing"?
17:38:27 <notting> lame, i know.
17:38:32 <tibbs> It is certainly possible to do that.
17:38:38 <tibbs> Or what I suggested earlier.
17:39:12 <tibbs> But I believe that any allowance of this with
multilib packages, or packages that could ever become multilib, can
break the distro.
17:39:16 <Kevin_Kofler> The rationale mentions KDE plugins as an
example of stuff which should be filtered though (which is how that
issue caught my attention).
17:39:25 <notting> yeah, a 'as long as none of your subpackages will
ever be mutilib' is a fine clarification
17:40:02 <notting> with that, i'm +1
17:40:02 <Kevin_Kofler> If you define every multilib conflict as
"breaking the distro", our distro is very "broken". ;-)
17:40:14 <tibbs> The problem, as I understand it, is that a package
can become multilib even though no changes are made to it via
dependencies that are multilib.
17:40:15 <Kevin_Kofler> There are still plenty of unfixed multilib
conflicts. :-(
17:40:29 * nirik grumbles again about slaying multilib, then shuts up
since that will never happen.
17:41:11 <Kevin_Kofler> And as multilibs are not installed by default
nowadays unless some 32-bit app requires them, most people don't
notice most conflicts.
17:42:42 <nirik> I guess I am +1 with the clarification... but we
should press rpm devs for more changes there to help this.
17:42:48 <skvidal> Kevin_Kofler: umm
17:42:52 <skvidal> Kevin_Kofler: that's incorrect
17:42:53 <Kevin_Kofler> nirik: Same here.
17:43:02 <skvidal> the default is to only install the "best" arch for
the platform
17:43:08 <skvidal> that's been the default for quite some time
17:43:23 <Kevin_Kofler> skvidal: That's what I mean.
17:43:36 <skvidal> multilibs are not installed by default
17:43:40 <skvidal> if I am on x86_64
17:43:44 <skvidal> and I run yum install foo
17:43:45 <Kevin_Kofler> If you install e.g. wine or some proprietary
app, it'll drag in the 32-bit libs, otherwise it won't.
17:43:56 <skvidal> and there exists foo.i386 and foo.x86_64
17:44:01 <skvidal> yum will not install foo.i386
17:44:04 * nirik thinks this is digressing.
17:44:07 <Kevin_Kofler> I know.
17:44:09 <skvidal> and wine is i386 only
17:44:21 <j-rod> +1 begrudgingly, a la nirik
17:44:37 <sharkcz> same here, +1
17:44:42 <jds2001> +1 i guess
17:45:23 <j-rod> that's at least 5 +1
17:45:36 * jds2001 was still counting, thanks j-rod :)
17:45:48 <Kevin_Kofler> As for killing multilibs, a proposal for next
week: restrict multilibs to wine, redhat-lsb and their dependencies.
Rationale: way too much stuff which will never be needed multilib is
multilib. The people who really need that stuff should just use the
i?86 repo and deal with the conflicts.
17:46:08 <nirik> Kevin_Kofler: write up a proposal. ;)
17:46:25 <jds2001> #agreed AutoProvidesAndRequiresFiltering is approved
17:46:31 <nirik> next?
17:46:36 <j-rod> yes please
17:46:40 <jds2001> +1 to the clarifications on no bundled libraries
17:46:42 <tibbs> With clarification; I will submit this to FPC on wednesday.
17:47:01 <j-rod> +1 on no bundled libs
17:47:07 <Kevin_Kofler> #info With clarification; tibbs will submit
this to FPC on wednesday.
17:47:28 <nirik> +1 no bundled libs. Makes sense and is good to note
in the guidelines with rationale, etc.
17:47:30 <notting> +1 on no bundled libs, although the formatting on
the list items has gone wonky
17:47:34 <sharkcz> +1
17:47:43 <Kevin_Kofler> IMHO it should be clarified to allow
significantly modified libraries.
17:48:02 <Kevin_Kofler> It's an unacceptable burden to force packages
using such libraries to be ported to the system version.
17:48:03 <nirik> it would be nice to have some way to identify
existing packages with them, but I suppose we will just need to file
the bugs as we see them.
17:48:09 <Kevin_Kofler> Sometimes it's just even plain impossible.
17:48:15 <Kevin_Kofler> Changes are made to libraries for a reason.
17:48:22 <jwb> Kevin_Kofler, why can't those be packaged as forks?
17:48:26 <nirik> Kevin_Kofler: you mean forked libraries ?
17:48:34 <dgilmore> +1 i think there is no reason for any app to
bundle libraries
17:48:36 <Kevin_Kofler> nirik: Significantly-forked ones.
17:48:50 <skvidal> ugh
17:48:53 <skvidal> stop forking the libraries
17:48:56 <jwb> Kevin_Kofler, so package the forked library for fedora...
17:49:05 <Kevin_Kofler> jwb: What's the point of libfoo-fork-for-app1,
libfoo-fork-for-app2 etc. packages?
17:49:14 <Kevin_Kofler> (if nothing else uses the respective fork)
17:49:19 <jwb> maybe people will stop forking shit then?
17:49:21 <nirik> Kevin_Kofler: did you read the page? do you see why
this is bad?
17:49:24 <dgilmore> Kevin_Kofler: to make it clear people are doing dumb things
17:49:27 <jwb> sorry, i redact my shit comment
17:49:45 * jwb hall monitors himself
17:50:01 <Kevin_Kofler> nirik: The problem is that it's not our (the
packagers') decision to fork the libraries.
17:50:24 <jwb> Kevin_Kofler, it is their decision to package the
package though.  it's part of being a maintainer
17:50:25 <Kevin_Kofler> And application developers are not going to
let us interfere with how they develop stuff.
17:50:29 <nirik> Kevin_Kofler: true, but we should work hard with
upstream to fix things... not just blindly ship the forked internal
copy.
17:50:31 * jds2001 sets jwb -v :D
17:50:35 <Kevin_Kofler> They'll just end up in some third-party
repository or we'll miss out on them entirely.
17:51:04 <Kevin_Kofler> jwb: How do you "fix" such a package?
17:51:20 <j-rod> educate upstream
17:51:24 <Kevin_Kofler> If it requires a forked library because it
really requires the changes in the library, how do you suggest a
packager handles that.
17:51:26 <j-rod> get them to send patches to the lib
17:51:28 <nirik> you talk with both upstream for the package and the
base library.
17:51:32 <Kevin_Kofler> j-rod: Upstream won't let themselves be educated.
17:51:39 <jwb> package the forked library as a fork, make the package
use that.  if they don't want to do that, try to work with upstream.
if upstream doesn't care, then the burden is on them as the maintainer
17:51:41 <Kevin_Kofler> They'll just go to another repository or
ignore Fedora entirely.
17:51:42 <j-rod> that's not universally true
17:51:49 <jds2001> Kevin_Kofler: i think you have a very narrow world view here.
17:51:52 <nirik> Kevin_Kofler: do you have a specific example? or are
you just playing devils advocate here?
17:52:07 <Kevin_Kofler> Some packages with forked libs are already in Fedora.
17:52:13 <Kevin_Kofler> Audacity has a forked PortAudio.
17:52:20 <Kevin_Kofler> It will not work at all without the patches.
17:52:20 <jds2001> they are, and they need to be repaired.
17:52:24 <nirik> are bugs filed?
17:52:27 <jwb> sounds like an audit is required
17:52:32 <tibbs> I note that this draft includes only rationale.
17:52:38 <tibbs> It's not changing any policy at all.
17:52:44 <jds2001> yes, nothing is actually changing.
17:52:47 * nirik nods.
17:52:49 <Kevin_Kofler> nirik: I filed a bug, it was closed as NOTABUG
as it cannot be fixed.
17:52:59 <jds2001> was effort made to resolve it?
17:53:04 <Kevin_Kofler> And PortAudio's upstream is almost dead.
17:53:04 <jds2001> with both upstreams?
17:53:05 <jwb> well, that is an incorrect resolution
17:53:17 <nirik> Kevin_Kofler: it should be reopened and blocking the
bug in the page there.
17:53:19 <j-rod> maintainer fail
17:53:20 <Kevin_Kofler> jwb: Well, it could be CANTFIX too.
17:53:32 <nirik> then they should request an exception from fesco.
17:53:33 <jwb> also an incorrect resolution
17:53:50 <Kevin_Kofler> PortAudio didn't reply to my patch to support
non-mmap ALSA at all either.
17:53:55 <Kevin_Kofler> Fedora is now carrying that as a patch.
17:53:59 <Kevin_Kofler> Upstream is basically dead.
17:54:08 <Kevin_Kofler> Good luck getting them to merge Audacity's
invasive patch.
17:54:10 <jwb> the correct resolution for someone that is not
following guidelines because it would incur additional work is
CLOSED->LAZY
17:54:28 <Kevin_Kofler> jwb: It doesn't just incur additional work, it
is IMPOSSIBLE.
17:54:35 <jwb> no it's not
17:54:37 <Kevin_Kofler> The application just plain WILL NOT WORK with
the unpatched library.
17:54:38 <nirik> bug 471782
17:54:39 <buggbot> Bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=471782 medium,
medium, ---, gemi, CLOSED NOTABUG, Please build audacity against the
system portaudio
17:54:51 <jwb> Kevin_Kofler, so the maintainer packages the forked
library and makes the package use that
17:54:55 <jwb> that is not IMPOSSIBLE
17:55:07 <Kevin_Kofler> The name, soname etc. will conflict.
17:55:09 <notting> portaudio is dead upstream? so, why not just drop it
17:55:15 * jds2001 doesnt get the point of the discussion about adding
a few paragraphs of reasoning.\
17:55:21 <jwb> Kevin_Kofler, not if properly forked
17:55:24 <Kevin_Kofler> Unless they make it static only, then only
-devel will conflict, but that's also against the guidelines.
17:55:25 <jds2001> we are WAY off topic.
17:55:42 <Kevin_Kofler> The point is that libraries forked by
applications are NEVER properly forked.
17:55:47 <Kevin_Kofler> They won't change the name or anything.
17:55:55 <Kevin_Kofler> They just patch it and link it in statically
in one way or the other.
17:55:57 <nirik> there will be times when nothing can be done. Then
the package should be removed or a exception granted by fesco
17:56:15 <nirik> but all other avenues should be followed first.
17:56:22 <jds2001> Shall we vote on adding the few paragraphs?
17:56:31 <j-rod> upstream portaudio seems to not be dead from what I can see
17:56:34 <jds2001> +1
17:56:44 <nirik> +1, makes sense I agree with it.
17:56:45 <j-rod> they had some issues, but look to be moving again
17:56:47 <Kevin_Kofler> We shall vote to remove the "clarifications"
on forking and explicitly allowing forked libs instead.
17:56:58 <jds2001> -1
17:57:01 <Kevin_Kofler> s/allowing/allow/
17:57:27 <nirik> allowing forked bundled libs should be the very very
very last resort.
17:57:35 <jwb> what are we voting on
17:57:52 <jds2001> jwb: adding the paragraphs.
17:57:54 <skvidal> jwb: I have no idea at this point
17:57:57 <jds2001> to which im +1
17:58:09 <skvidal> jds2001: but you just said -1
17:58:11 <nirik> the FPC rationale at:
https://fedoraproject.org/wiki/No_Bundled_Libraries
17:58:12 <skvidal> didn't you?
17:58:18 <jds2001> skvidal: to Kevin_Kofler's proposal
17:58:20 <dgilmore> +1 allowing forked/bundled libs should not happen.
 at least not without a plan to unfork/unbundle
17:58:32 <nirik> +1 to the PFC link above here.
17:58:39 <sharkcz> +1
17:58:54 <j-rod> +1 for the fpc thing
17:59:02 * notting reaffirms his +1 vote to the proposal
17:59:09 <skvidal> +1 for the fpc guidelines
17:59:12 <Kevin_Kofler> 0 - the clarifications are good in principle,
but I don't agree with the details on forking
17:59:16 <jds2001> #agreed Clarification on no bundled libraries is approved.
17:59:30 <jwb> +1 for the FPC guidelines
17:59:38 <jds2001> next for removing prebuilt binaries.
17:59:51 <jds2001> this proposal makes sense, +1
17:59:57 * jds2001 reads it as
17:59:58 <j-rod> yeah, seems sane
18:00:00 <j-rod> +1
18:00:04 <jds2001> 'remove them during %prep'
18:00:31 <Kevin_Kofler> +1
18:00:37 <jwb> so i have a dumb question
18:00:44 <nirik> it seems a bit odd to have FPC approve exceptions.
18:00:46 <jwb> does this include pre-generated configure scripts?
18:00:52 <jwb> because OMG pain...
18:00:54 <nirik> since fesco does all the other exceptions it seems like.
18:00:58 <jds2001> jwb: explicitly not
18:01:00 <jds2001> I think.
18:01:13 * jds2001 doesn't see that as a "program binary"
18:01:21 * nirik notes the BinaryFirmware link is broken/nonexistant there.
18:01:21 <jwb> configure is a program?
18:01:24 <notting> +1, this is much better than the one that was proposed before
18:01:32 <jds2001> but maybe tibbs can clarify on that
18:01:32 <notting> jwb: configure is PAIN
18:01:33 <Kevin_Kofler> configure is executable.
18:01:36 <pjones> jwb: not a very good one.
18:01:40 <dgilmore> +1
18:01:40 <Kevin_Kofler> "Is it executable? If so, it is probably a
program binary."
18:01:41 <sharkcz> +1
18:01:49 <jwb> notting, pjones: beside the point
18:01:54 <notting> jwb: configure is a shell script
18:02:07 <jwb> notting, look at the criteria in the proposal...
18:02:07 <tibbs> It certainly wasn't the intention to somehow force
removal of configure scripts.
18:02:12 <dgilmore> having prebuilt binaries and shard objects  is bad
18:02:15 <j-rod> perhaps there should be some additional guidance using
'file'
18:02:18 <jwb> "is it executable?  if so, it's probably a program
binary"
18:02:29 <Kevin_Kofler> The old guidelines weren't any different there though.
18:02:34 <dgilmore> Ive had sparc builds fail trying to link x86
objects to sparc ones
18:02:38 <Kevin_Kofler> (They just said "binary" instead of "program
binary".)
18:02:52 <notting> jwb: if someone wants to start arguing about
configure vs. configure.in and preferred form of modification, as to
whether you're building from source... let me know and i can take a
nap? (not to be too glib)
18:03:02 <j-rod> "is it executable and does the 'file' command believe
its binary data? if so, its probably a program binary"
18:03:20 <dgilmore> Kevin_Kofler: we could have the clarify it as .so
.a and arch specifc executables
18:03:27 <Kevin_Kofler> And Java classes.
18:03:39 <notting> 'executable compiled file'?
18:03:43 <Kevin_Kofler> (including JARs, which are just ZIPs thereof)
18:03:52 <nirik> tibbs: do you know why FPC wanted to do the
exceptions here? I guess I don't have an issue with it, but seems odd.
18:04:06 <nirik> otherwise I am +1 here.
18:04:20 <jwb> notting, it may be splitting hairs, but someone is
going to bitch about it and i don't see s/binary/program binary as
being too overly descriptive
18:04:32 <jwb> nirik, good question
18:04:34 <tibbs> nirik: I'm afraid I don't understand the question.
18:04:46 <jwb> tibbs, why is FPC changing this guideline?
18:05:00 <Kevin_Kofler> jwb: I think the idea is that a shell script
is not a binary because it's plain text.
18:05:03 <jds2001> a:colors darkblue
18:05:03 <jds2001> " * Search & Replace
18:05:03 <jds2001> " make searches case-insensitive, unless they
contain upper-case letters:
18:05:06 <jds2001> set ignorecase
18:05:09 <jds2001> set smartcase
18:05:11 <tibbs> It was submitted as a draft to us, and the committee
thought it was a good idea.
18:05:11 <jds2001> " show the `best match so far' as search strings are
typed:
18:05:14 <jds2001> set incsearch
18:05:15 <nirik> tibbs: in exceptions: " If you have a package which
meets this criteria, contact the Fedora Packaging Committee for
approval."
18:05:16 <jds2001> " assume the /g flag on :s substitutions to replace
all matches in a line:
18:05:20 <jds2001> set gdefault
18:05:22 <notting> jds2001: ????
18:05:22 <j-rod> uh
18:05:22 <jds2001> " * User Interface
18:05:25 <jds2001> " have syntax highlighting in terminals which can
display colours:
18:05:26 <dgilmore> jds2001:
18:05:27 <jds2001> "if has('syntax') && (&t_Co > 2)
syntax on
18:05:29 <jwb> Kevin_Kofler, big rats nest there
18:05:30 <jds2001> "endif
18:05:32 <jds2001> " have fifty lines of command-line (etc) history:
18:05:35 <jds2001> set history=50
18:05:37 <jds2001> " have command-line completion <Tab> (for
filenames, help topics, option names)
18:05:40 <jds2001> " first list the available options and complete the
longest common part, then
18:05:44 <jds2001> " have further <Tab>s cycle through the
possibilities:
18:05:46 <jds2001> set wildmode=list:longest,full
18:05:46 * jwb looks at jds2001
18:05:47 * nirik sighs.
18:05:49 <jds2001> " display the current mode and partially-typed
commands in the status line:
18:05:52 <jds2001> set showmode
18:05:55 <jds2001> set showcmd
18:05:57 <jds2001> " have the mouse enabled all the time:
18:06:00 <jds2001> "set mouse=a
18:06:03 <jds2001> " don't have files trying to override this .vimrc:
18:06:05 <jds2001> set nomodeline
18:06:07 <jds2001> gack!
18:06:10 <jds2001> nirik: that's what i was trying to paste
18:06:21 <jds2001> let me know when my spam is done
18:06:27 <jwb> i think it's done
18:06:38 * jds2001 is happy that was nothing secret :)
18:06:52 <jds2001> anyhow.
18:07:05 <jds2001> i was  trying to paste what nirik did
18:07:14 <Kevin_Kofler> Well, there's nothing more secret than your
choice of editor. ^^
18:07:20 <jds2001> :)
18:07:24 * notting notes we have 6 +1 votes for this
18:07:34 <nirik> tibbs: so, I was just asking why in this guideline
exceptions should be handled by FPC instead of FESCo which deals with
all the other ones that I can think of.
18:08:03 <notting> jwb: on the good side, if this fpc-written proposal
is unclear, it refers all questions as to what's a binary back to fpc
themselves
18:08:07 <jds2001> #agreed jds2001 is a moron
18:08:08 <tibbs> If FESCo wants to approve these then we can certainly
change it.
18:08:20 <jwb> notting, good point
18:08:31 <jds2001> #agreed No pre-built binaries proposal is approved
18:08:32 <tibbs> I'm not sure that we really considered which
committee should handle these things.
18:08:55 * nirik shrugs. I don't care much, but given that we meet
each week and FPC meets... sometimes... it might be better for us to
do them. Dunno.
18:09:55 <jds2001> next!
18:09:55 <abadger1999> Hmm... that line was in the old guideline as
well so we didn't look too closely.
18:10:13 <jds2001> #topic Raduko perl 6
18:10:19 <jds2001> .fesco 218
18:10:25 <jds2001> this was just to check status here
18:10:39 <nirik> it now has a package in the review bug...
18:11:10 <notting> but no reviewer
18:11:15 <nirik> hang on.
18:11:49 <Kevin_Kofler> Why is the review not assigned to a reviewer
yet? Wasn't there cwickert interested in the feature too? He's not the
submitter, so he should be doing the review if he wants the feature
in!
18:11:54 * nirik asked cwickert to drop in here... but then he dropped
off the net. ;(
18:12:05 * dgilmore says -1  the review should be complete by now
18:12:26 <nirik> if it will help, I could do the review today.
18:12:34 <nirik> there he is.
18:12:45 <cwickert> sorry, pidgin crashed
18:12:52 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=498390
18:12:53 <buggbot> Bug 498390: medium, medium, ---, nobody, NEW,
Review Request: rakudo - Rakudo - A Perl compiler for Parrot
18:13:01 <nirik> cwickert: so, whats the status of the review? it's
not assigned yet or reviewed. ;(
18:13:06 <cwickert> I'm just doing the review and so far it looks good
18:13:29 <jds2001> ok, you should assign it to yourself
18:13:31 <cwickert> one little problem that needs to be fixed, I just
called Gerd about it
18:13:33 <jds2001> and set fedora-review?
18:13:44 <cwickert> jds2001: mom, just came home from work
18:13:55 <cwickert> but I'm optimistic we can make it tonight
18:14:03 <jds2001> ok :)
18:14:49 <cwickert> ok, bug is updated
18:15:23 <cwickert> do we want to discuss this for half an hour again
or should Gerd and me just go to work?
18:15:27 <jds2001> k, do we want to give this til tonight?
18:15:32 <jds2001> just go work :)
18:15:37 <cwickert> thanks
18:15:58 <Kevin_Kofler> Please make sure there are no bogus
Provides/Requires which conflict with perl 5.
18:16:18 <cwickert> Kevin_Kofler: the only provide will be /usr/bin/perl6
18:16:38 <jds2001> k
18:16:47 <skvidal> cwickert: ?? the only explicit provide - but I
assume you're not turning off the autoprov generator
18:16:59 <cwickert> skvidal: not explicit
18:17:16 <cwickert> so we won't turn of autoprov
18:17:56 <skvidal> cwickert: right - then you'll get more provides
18:18:20 <skvidal> check those
18:18:22 <cwickert> skvidal: ok, will do
18:18:22 <skvidal> make sure it is not going to be pulled in instead
of perl5 for something
18:18:22 <skvidal> that's all of our concern is having it 'trickle'
onto systems and blow things up
18:18:22 <cwickert> will try in a vm
18:18:28 <skvidal> when in doubt
18:18:34 <cwickert> skvidal: I share you concerns ;)
18:18:36 <Kevin_Kofler> cwickert: rpm -qp --provides rakudo*.rpm
18:18:37 <jds2001> hold on, $WORK coworker here.
18:18:43 <skvidal> for line in rpm -qp --provides *.rpm
18:18:47 <skvidal> yum resolvdep $line
18:18:54 * nirik notes his review checklist always checks provides and requires.
18:19:53 <nirik> ok, so anything else on this? or shall we move on?
18:20:23 <Kevin_Kofler> If you break Perl, you'll break the KDE spin
and an angry Sebastian Vahl might show up at your door with a baseball
bat. ;-)
18:20:58 <cwickert> Kevin_Kofler: I guess you and Rex are coming, too ;)
18:21:30 * notting notes rex would have a slightly longer commute
18:22:52 <notting> i think we can move on?
18:23:13 <Kevin_Kofler> Move on++. :-)
18:23:56 <nirik> jds2001 is busy it seems.
18:24:02 <nirik> I think 209 is the next item.
18:24:21 <notting> #agreed this will be worked on today. will revisit
if it doesn't land.
18:24:52 <Kevin_Kofler> #topic #209 Request to become provenpackager - otaylor
18:24:52 <nirik> #topic Request to become provenpackager - otaylor -
https://fedorahosted.org/fesco/ticket/209
18:25:02 <nirik> oops. Sorry. ;)
18:25:17 * notting is +1 to owen
18:25:31 <Kevin_Kofler> +1 here too.
18:25:41 <nirik> +1 here. I think he knows his way around packaging,
and will help out with desktop packages nicely.
18:25:50 <skvidal> +1 to owen
18:25:53 <sharkcz> +1
18:26:15 <j-rod> +1
18:26:31 <jds2001> +1 to owen, sorry for the delay
18:26:32 <dgilmore> +1
18:26:53 <jwb> 0
18:27:00 * nirik notes that one thing mentioned recently was that we
do too many +1's without rationale. :) Might be good to note at least
a short thing on why you vote the way you do. ;)
18:27:09 <jwb> yes
18:27:09 <nirik> anyhow, this passes.
18:27:25 <nirik> #agreed otaylor approved for provenpackager.
18:27:43 <nirik> #topic Request to become provenpackager - pingou
18:27:49 <notting> nirik: ok, +1 to owen because i trust him to not
make stupid mistakes more than i trust myself
18:27:53 <nirik> .fesco 233
18:28:11 <jds2001> so there were objections here
18:28:21 <cwickert> although I'm not allowed to vote on that -1: to
many open bugs without any reaction
18:28:36 <dgilmore> 0, i dont know his work and there is no supporting
data to look it up
18:28:38 <notting> the one that gets me is "* 3 FTBFS with no reaction
for 6 weeks". on that basis alone, i'm -1.
18:28:47 <jds2001> yeah, i have to agree, -1
18:28:56 <nirik> yeah, he should be caught up on his packages/bugs
before fixing others.
18:29:04 <pingou> !
18:29:29 * jds2001 not sure what ! means
18:29:35 <Kevin_Kofler> pingou: Well, I have to agree that you should
fix your own packages first before worrying about other people's...
18:29:37 <pingou> Those packages need new dependancies that are not
ready yet (I know I'm late on those)
18:29:55 <cwickert> pingou: then you should at least write this in the bug
18:30:02 <pingou> cwickert: I will then
18:30:22 <Kevin_Kofler> And is there really no way to get the existing
packages to build for now (e.g. by a backported patch or something?).
18:31:00 <pingou> I should look more into this but I would prefer
bring the new one in
18:31:36 <pingou> but I accept whatever decision you make :)
18:31:56 <jds2001> how bout -1 for now, come back later?
18:32:13 <pingou> fine for me :)
18:32:43 <j-rod> yeah, do some housekeeping w/your own stuff, get that
all in order, then reapply
18:33:34 * nirik nods.
18:33:48 <Kevin_Kofler> I agree with that: -1 for now, will reconsider
when your own packages are sorted out.
18:34:15 * sharkcz also nods
18:34:38 <nirik> I think thats the last thing on the meeting agenda?
18:34:46 <jds2001> #agreed pingou provenpackager nomination is
declined for now, please reapply when packages are in order
18:34:51 <jds2001> #topic open floor
18:34:59 <jds2001> yep
18:35:02 <jds2001> anything else?
18:35:10 * dgilmore added an iteam but it should get discussion and be
considered next week
18:35:34 <jds2001> dgilmore: agreed
18:35:49 <jds2001> but that's more for rel-eng, when they present the
schedule to us, no?
18:36:04 <dgilmore> jds2001: i dont think so
18:36:08 <dgilmore> but maybe
18:36:15 <nirik> dgilmore: I think that may cut into devel time too much.
18:36:22 <dgilmore> nirik: how
18:36:23 <nirik> but we can discuss next week.
18:36:37 <dgilmore> nirik: its just having proposals in before feature freeze
18:36:51 <notting> i think there probably needs to be a sliding scale
where as time to freeze approaches, minimum percentage done must
increase. but we can talk more next week.
18:36:56 <nirik> well, do you know a month before freeze that
something will land in time for this cycle?
18:37:28 <dgilmore> nirik: maybe not. but having it as a feature makes
it visable. and FESCo or others can help toget it done
18:37:35 <nirik> true.
18:37:40 <dgilmore> throwing it there last minute makes it hard for
others to help
18:38:35 <jds2001> anyhoo
18:38:38 <jds2001> anything more?
18:39:03 <notting> alpha freeze next tuesday. please fix your bugs so
we can ship.
18:39:23 <jds2001> #info alpha freeze next tuesday. please fix your
bugs so we can ship.
18:39:48 <jds2001> #info slips are bad, mmkkkayyy?
18:40:06 <notting> #info Please remember to update your feature status as well.
18:40:16 <Kevin_Kofler> I think dgilmore's proposal should link to
KDE's soft freeze policy for comparison and credit.
18:40:39 <dgilmore> Kevin_Kofler: why for credit when thats not where
it came from
18:40:49 <dgilmore> Kevin_Kofler: i dont know what KDE's policies are
18:41:08 <dgilmore> Kevin_Kofler: but feel free to add it for comparison
18:42:10 <Kevin_Kofler> Hmmm, actually there's apparently no canonical
reference, it just shows up in their schedules.
18:42:21 <Kevin_Kofler> E.g.
http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule#April_16th.2C...
18:42:59 <jds2001> maybe KDE should do a better job about writing down
their policies.....
18:43:09 <jds2001> oh, wait a minute, maybe we should too :)
18:43:30 <notting> anything else for today?
18:43:36 * skvidal hopes no
18:43:40 <jds2001> nothing here
18:43:59 <jwb> i have something
18:44:00 * jds2001 ends the meeting and sends the log....
18:44:04 <jds2001> or not
18:44:09 <jds2001> whats up jwb
18:44:12 <jwb> unfortunately, skvidal will now hate me
18:44:25 <jwb> where are we with critical path?
18:44:47 <jds2001> good question, I thought you would know best :)
18:44:53 <skvidal> that one is on me
18:45:09 <skvidal> I was supposed to put the requirements in bodhi and
I completely blanked on it from wednesday
18:45:17 <skvidal> I'll take care of that today before I call it a day
18:45:56 <jds2001> anything else?
18:46:13 * jds2001 really ends the meeting
18:46:19 <jds2001> #endmeeting

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002