path: root/meeting-logs/20101026.txt

20:01  * ferringb bangs the gavel
20:01 <@scarabeus> btw guys i am sick have fever and lot of pills in me, so if i disappear in middle of meeting plz excuse me for falling asleep ;)
20:02 <@ferringb> heh
20:02 <@wired> no excuses! :Pp
20:02 <@ferringb> related, if I pop off for 5 minutes... pardon.  not a fever, imminent release and no proper cube space to keep people the hell out
20:03 <@jmbsvicetto> brb
20:03 <@ferringb> heh
20:03  * ferringb is counting 6 folk atm
20:04 <@scarabeus> Halcy0n: ping
20:04 <@Halcy0n> Sorry, here :)
20:04 <@jmbsvicetto> back
20:04 <@ferringb> !seen chainsaw
20:04 < willikins> ferringb: Chainsaw was last seen 1 day, 19 hours, 50 minutes and 25 seconds ago, quitting IRC (Quit: Leaving) and a moment before doing *Chainsaw leaves mr. Fire & mr. Viola to work this out amongst themselves* in
20:05 <@ferringb> so... number?
20:05 <@jmbsvicetto> Anyone willing to call?
20:06  * ferringb is willing, but can't
20:06 <@ferringb> better question is does anyone have the number
20:06 <@jmbsvicetto> I have it
20:07 <@jmbsvicetto> ok, I'll call him
20:07 <@scarabeus> Jorge - The secretary - comming to theater near you really soon
20:07 <@jmbsvicetto> :P
20:08 <@scarabeus> is few_ around?
20:08 <@scarabeus> for the future (about that eapi) :)
20:08 <@wired> !seen few_
20:08 < willikins> wired: few_ was last seen 1 hour, 15 minutes and 6 seconds ago, saying "good" in #gentoo-portage
20:09 <@jmbsvicetto> He should be around soon
20:09 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
20:09 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
20:09 <@Chainsaw> Sorry!
20:09 <@scarabeus> hi man
20:09 <@wired> ohai
20:09 <@ferringb> Chainsaw: 10 lashes!
20:09 <@Chainsaw> I know :(
20:09 <@jmbsvicetto> Chainsaw: I'm sorry but you'll have pay ice-cream for all of us!!! ;)
20:09 <@jmbsvicetto> +to
20:10  * Chainsaw runs into the kitchen to make every coffee & tea
20:10 <@wired> ice-cream? we have a machine for that, let him bring beer instead
20:10 <@ferringb> Chainsaw: wouldn't worry.  you're 10 minuts- that's significantly better than my turn around when I'm still stuck in a meeting and someone has to call ;)
20:10 <@wired> :P
20:10 <@jmbsvicetto> wired: I think you'll prefer than for FOSDEM ;)
20:11 <@jmbsvicetto> So, shall we start?
20:11  * ferringb supposes
20:11 <@Chainsaw> Yes, let us proceed.
20:11 <@ferringb> first, sorry for the clusterfuck of me not sending out the agenda/2 week notice- works been mildly hellish
20:12 <@ferringb> what we have on the schedule is namely .la files, and request by few/co. to look at eapi4 (approve what is implemented specifically)
20:12 <@ferringb> so... .la first I suppose.
20:12 <@scarabeus> yep
20:12  * ferringb yields the floor to whoever wants to first fling poo on the matter
20:13 <@scarabeus> jmbsvicetto: basically you nominated it so wanna start?
20:15 <@scarabeus> so ok, everyone of us knows what lafiles are and what are their disandvantages i guess
20:15 <@scarabeus> only thing we need to do is figure some global way how to get rid of them, because those @preserved-rebuild and lafilefixer runs are annoying :)
20:15 <@scarabeus> if i get it right
20:15 <@ferringb> and the given decision as to whether killing them off is even desired (presume yes, but it is a choice point)
20:16 <@scarabeus> well most apps use pkgconfig anyway :)
20:16 <@jmbsvicetto> ok
20:17 <@wired> has anyone presented any really important reason not to kill them? afaik there haven't been any really important arguments
20:17 <@jmbsvicetto> Does any of us (council) have any objections about killing la files (where appropriate) ?
20:17 <@Chainsaw> I believe not installing .la files should be the default.
20:17 <@Chainsaw> If you do install them, there should be a comment in your ebuild stating why.
20:17 <@ferringb> Chainsaw: same for me.
20:18 <@Chainsaw> Disagreement with comments can go through the usual commit reviews, which do happen.
20:18  * ferringb nods
20:18  * Chainsaw wouldn't want to say "Never! Thou shalt not install .la files under any circumstances"
20:18 <@ferringb> exactly
20:18 <@scarabeus> yes so agreed on their removal
20:19 <@Chainsaw> But "default off" and "comments mandatory"
20:19 <@ferringb> how to do the removal?
20:19 <@scarabeus> problem is process
20:19 <@ferringb> well, I see 2 issues
20:19 <@jmbsvicetto> Just to be clear, there are cases where we can't just remove them
20:19 <@ferringb> yep
20:19 <@ferringb> 1) the pruning itself, doing it without breaking the shit out of things while transitioning
20:19 <@jmbsvicetto> libtool and some particular packages
20:20 <@jmbsvicetto> Then there's the issue that Diego has identified at least one package with .la files that are not libtool archives
20:20 <@ferringb> 2) should the pruning be configurable?
20:21 <@ferringb> so... views?
20:21 <@Chainsaw> Can we make it part of the new EAPI? Have a dolafile?
20:21 <@jmbsvicetto> Chainsaw: there's no need for a new EAPI for this
20:21 <@jmbsvicetto> I like Diego's proposal:
20:22 <@Chainsaw> jmbsvicetto: There isn't a need, but it's a way.
20:22 <@Betelgeuse> jmbsvicetto: No but it could be useful down the road.
20:22 <@Chainsaw> Ah, the flaming eyes. What did they say?
20:22 <@Halcy0n> The problem is still the crap breaking as we get rid of them.  We need to have it automated so that things fix themselves.
20:22 <@jmbsvicetto> let's add to eutils.eclass the following function:
20:22 <@jmbsvicetto> delete_libtool_archives() { find "${@:$D}" -name '*.la' -delete
20:22 <@jmbsvicetto> }
20:22 <@jmbsvicetto> Halcy0n: In my view there's 2 issues
20:22 <@Chainsaw> jmbsvicetto: That still relies on people calling it though.
20:23 <@jmbsvicetto> 1. drop .la files from packages that don't need them
20:23 <@jmbsvicetto> 2. fix required .la files to use propper -l<lib> -L<path> instead of hardcoding library references
20:23 <@jmbsvicetto> The 2 is already being done on portage
20:23 <@jmbsvicetto> Chainsaw: yes, but that's the whole point
20:24 <@jmbsvicetto> Chainsaw: you can't just set a FEATURES="no-la-files" and have your system kill all .la files
20:25 <@jmbsvicetto> The above function would fix 1
20:25 <@jmbsvicetto> leio: around?
20:25 < leio> a bit
20:26 <@wired> can't we have FEATURES="keep-la-files" for those users who want them and another var that ebuilds can set to force la preservation if needed?
20:26 <@jmbsvicetto> leio: If we wait to get a stable version of portage with support for 2 and make sure we get the news item warning about 1, do you still have any objection with going forward with this?
20:26 <@jmbsvicetto> wired: that's what the static-libs use flag is being added for
20:26 < leio> I don't know what "this" is, need to be preoccupied 5 minutes and then read up
20:27 <@jmbsvicetto> The idea is that we're installing just shared libs by default and that anyone wanting to keep static libs enables the static-libs use flag
20:28 <@jmbsvicetto> leio: adding to eutils a function to drop the la files (so we have the same function being used all over the tree). That function will remove all la files in ${D} or just the list of files/dirs specified in an ebuild
20:29 <@jmbsvicetto> leio: The removal of la files in a package will still have to be discussed with the maintainers - I'm not suggesting someone jumps in the tree and touches all packages without talking to the maintainers
20:30 <@ferringb> jmbsvicetto: but that's fun!
20:31  * ferringb looks around; not much comments from folk
20:31 <@jmbsvicetto> So, does anyone have any objections to going this route?
20:32 <@Chainsaw> jmbsvicetto: Thinking about it, having a function in eutils makes it easier on maintainers.
20:32 <@ferringb> and easier to flip it off if someone wants to
20:32 <@ferringb> although I'm not convinced of a feature controlling that
20:33 <@jmbsvicetto> I think user's control should be about whether to install static libs or not
20:33 <@jmbsvicetto> That function should not be called if USE="static-libs"
20:34 -!- darkside_ [~darkside@gentoo/developer/darkside] has joined #gentoo-council
20:34  * ferringb nods
20:35 -!- dilfridge [~quassel@gentoo/developer/dilfridge] has joined #gentoo-council
20:35 <@jmbsvicetto> darkside_: you joined in a good time
20:35 <@jmbsvicetto> darkside_: are there any concerns from prefix about removing the la files?
20:35 <@jmbsvicetto> So, no objections, no agreement, no opinion? anyone?
20:36 <@Halcy0n> I never cared, so long as it was done in a way that would not cause headaches for users :)
20:36 <@wired> the function looks fine to me
20:36 -!- Zorry [~zorry@gentoo/developer/zorry] has joined #gentoo-council
20:36 < darkside_> jmbsvicetto: the only concern would be the archs that require static so a tunable param would be desired
20:37 < darkside_> (minor)
20:37 <@jmbsvicetto> darkside_: in those arches you could just force enable the static-libs use flag, right?
20:37 < darkside_> i think so. i haven't dug into the implementation details yet
20:37 < darkside_> grobian did reply to that thread on -dev and flameyees agreed while talking on irc
20:38 <@jmbsvicetto> darkside_: Do you have an idea of what prefix supported arches require static building?
20:39  * darkside_ looks abit
20:39 -!- blackace [~blackace@gentoo/developer/blackace] has joined #gentoo-council
20:40 < darkside_> http://archives.gentoo.org/gentoo-dev/msg_a39b16fbf70fd08a029c883d6e7f6aeb.xml <- grobian's comment on the thread
20:41 < leio> One primary reason of existence of libtool is for supporting non-ELF platforms, where even shared libraries might not record dependencies within themselves. I don't know of any such systems that we care about though, as apparently it's not an issue on PE
20:42 <@ferringb> adding an option when it's neeed isn't hard
20:42 <@ferringb> *needed
20:42 < darkside_> only one or two requires static and they are minor archs which i don't care about, but users do. apparantly there is this whole community has built up gentoo on atari (m68k-mint) =D
20:42 < leio> basically the idea in my mind has always also been doing it via an eclass, so you can tune it in a global place. Like have a variable that needs to be defined in make.conf for any deletion to be done
20:42  * ferringb nods
20:43 < leio> darkside_: this isn't about just static libs. Some systems don't have DT_NEEDED in shared libraries
20:43 <@jmbsvicetto> ok, my proposal is the following:
20:43 <@wired> leio: or a variable to be defined for deletion _not_ to be done
20:43 <@ferringb> point is, if the deletion is via an eutils func, wiping/overriding the .la removal is easy enough
20:43 <@jmbsvicetto> 1. add the function to the eutils eclass so that we use a consistent function everywhere
20:43 < leio> If it's a variable, then it could be set on new installs AND users have the possibility to opt-in to it at a point _they_ have time to actually deal with it
20:44 <@jmbsvicetto> 2. add a static-libs use flag for packages where we want to drop static libs and call that function only if the use flag isn't set
20:44 <@jmbsvicetto> 2.1. that means arches that don't support using just the shared lib use.force static-libs
20:45 <@jmbsvicetto> 3. halt any more ebuild work until a portage version with the lafilefixer like script that fixes .la files is marked stable
20:45 <@Halcy0n> How does this address the breakage during the transition period?....
20:45 <@Halcy0n> nvm :)
20:45 <@jmbsvicetto> 4. require the news item warning users about the chance and telling them how to fix any issues they face
20:46 <@wired> jmbsvicetto: that doesn't cover systems without DT_NEEDED in shared libraries that leio pointed out
20:46 <@jmbsvicetto> wired: just force static-libs on those systems
20:46 < leio> (I also said I don't know of any such systems we care about)
20:46 <@wired> ok
20:46 <@jmbsvicetto> wired: static-libs doesn't remove shared libs, it just forces building static libs as well and include .la files
20:46 < leio> (and they don't necessarily need static libraries, just listing of all shared libraries)
20:46 <@jmbsvicetto> leio: does this seem reasonable to you?
20:47 <@jmbsvicetto> leio: the best option for those would probably be .pc files, right?
20:47 < leio> yes, just not all libraries provide them yet
20:48 <@jmbsvicetto> so, do we want to have a vote on this subject or would it be best to take this proposal to the dev ml and if there aren't many objections have a council vote through mail in a few days?
20:48 <@Halcy0n> Take it to the ML and just let everyone have their chance to say yay or nay, then we can decide.
20:48 <@jmbsvicetto> ok, I agree
20:49 < leio> that's the main issue with libtool files - they only list all dependencies - indirect and direct. While really it should be indirect and direct separately, so that on ELF systems it would only look at the direct ones if needed in case of shared libs, and only look at indirect in those other cases. Either way, I don't think we care about those systems, and I'm not opposed to any proper .la file dropping, once the process is painless to users
20:49 <@Halcy0n> Do we have any timelines on when a version of portage will be going stable to fix the la-files?
20:49 <@jmbsvicetto> unless any of you wants to do it, I offer to write an email about this to the dev ml today or tomorrow
20:49 <@jmbsvicetto> Halcy0n: I think Zac was talking in around 1 month
20:49 < leio> As other random comments of the discussion above
20:50 < leio> * .la files are _required_ if they are for plugins or the like that are opened via libltdl
20:50 < darkside_> Halcy0n: FEATURES=fixlafiles is in portage-2.1.9*
20:51 < leio> * .la files should never be required for plugins and the like that are opened via dlopen, no need to not delete them really if user requested no deletion otherwise
20:51 <@wired> lets say that unless serious -currently unknown- issues arise, we'll vote [if needed] and proceed with this as soon as portage 2.1.9 is stable
20:52 -!- ssuominen [~ssuominen@gentoo/developer/ssuominen] has joined #gentoo-council
20:52 <@jmbsvicetto> darkside_: that's tied to a FEATURE? Doesn't sound the best option. Something else to talk in the ml
20:52 <@jmbsvicetto> wired: I agree
20:52 <@Halcy0n> I was just going to say the same thing.  It should just happen if necessary.
20:53 <@jmbsvicetto> ferringb: should we proceed?
20:53 <@ferringb> thus far it's your topic/your show ;)
20:53 <@Halcy0n> I also need to leave in about 5-10 minutes, so if we can wrap it up.... :)
20:53 <@jmbsvicetto> but you're the "hammer guy" tonight ;)
20:53 <@ferringb> my personal views is proceed
20:53 < leio> * the transition pain is about the .la files of libraries that other things link against. If lafilefixer --justfixit is made sure to be ran by users just once with a news item and from thereon out portage-2.1.9 with always enabled fixlafiles is used to prevent any future merges, I don't see a problem with deleting of those problematic .la files _after_ users have done all that
20:53 <@ferringb> if we're wrong, that's fine, we revisit (the council can be wrong and overrule itself after all)
20:54 < leio> (any future merges from having libtool files depend on other libtool files)
20:54 <@ferringb> so... vote?
20:54 <@jmbsvicetto> I thought we were going to move this to the ml?
20:54  * ferringb has the hammer :P
20:54 <@jmbsvicetto> hehe
20:55  * ferringb notes the ml suffices if folks want it, but it's not going to be a fast process
20:55 <@wired> [dodges the hammer] +1 here ftr :)
20:56 <@Halcy0n> I say just give it about 5 days to let people comment if we missed anything, and then we can just go ahead with it if nothing big is brought up.
20:56 <@jmbsvicetto> If we want to vote, I vote yes. I'm ready to work with people to get an implementation plan that addresses all concerns raised during this discussion
20:56 <@Halcy0n> We can do stuff on the mailing lists and not just in these meetings :)
20:56  * ferringb nods
20:56 <@jmbsvicetto> we've already decided we can vote through email at any time
20:57 <@ferringb> basically I'd like to get it decided today, then leave it to the next council run for the exact details of transitition plan to be worked out by then
20:57 <@jmbsvicetto> ok, in that case I vote yes
20:57 <@wired> yes
20:57 <@Betelgeuse> So we are voting on if we want to get rid of them?
20:57 <@Betelgeuse> or what?
20:57 <@ferringb> heh.
20:57 <@ferringb> punting them, specifically the eutils approach.
20:58 <@Betelgeuse> I have no desire or need for them so - yes
20:58 <@jmbsvicetto> ferringb: let's find a wording to point to
20:58 <@ferringb> jmbsvicetto: would be useful yes.
20:58 <@Chainsaw> I am in favour of deleting LA files where it makes sense, yes.
20:59 <@jmbsvicetto> The motion is to drop la files, when appropriate, through the use of a function in eutils that will only be called if the static-libs use flag is not set.
20:59 < ssuominen> .la files don't make sense with static archives if the package comes with pkg-config file
20:59 <@wired> la removal, handled by eutils function, added to ebuilds by their maintainers, controlled by static-libs
20:59 < ssuominen> so it can't be tied only to USE=static-libs, it simply doesn't make sense
21:00 <@jmbsvicetto> The motion also sets a halt on la file removal until a portage version with support to fix the la files is marked stable and a news item is published informing users on how to fix any issue arising from the transition
21:00 <@jmbsvicetto> ssuominen: The ebuild maintainer will add the function call where appropriate.
21:01 <@wired> ssuominen: perhaps we can have two functions, one that always removes the la files (your case) and a wrapper that only removes la files if ! use static-libs
21:01 < ssuominen> ok.
21:01 <@jmbsvicetto> ssuominen: the static-libs use flag just prevents the removal of .la files if set. Is that ok?
21:02 <@wired> jmbsvicetto: he's pointing out that you can have static-libs and still not need la files
21:02 < ssuominen> no, they should be removed if a working .pc file is provided
21:02 <@jmbsvicetto> ssuominen: ok, then let's add that exception
21:02 <@jmbsvicetto> new wording:
21:02 < ssuominen> and for libs that don't link to other libs (except libc itself) (no pkg-config file, but still no .la files required)
21:03 <@jmbsvicetto> The motion is to drop la files, when appropriate, through the use of a function in eutils that will only be called if the static-libs use flag is not set or unless the package relies on pkg-config.
21:03 <@wired> the function could have a force parameter
21:03 <@jmbsvicetto> ssuominen: better?
21:03 < ssuominen> see my last msg
21:04 < ssuominen> still doesn't cover all cases where they should be punted
21:04 <@jmbsvicetto> ok, we'll improve the wording in the ml
21:04 <@ferringb> yeah, time for the ml I suspect since halcy0n is likely gone by now.
21:04 <@jmbsvicetto> ferringb: the above can be used as a first draft to be improved in the ml. ok?
21:04  * ferringb nods
21:04 <@wired> ok
21:05 <@ferringb> jmbsvicetto: should just doc the thing up anyways, since the resulting doc folk will need to look at from a qa standpoint down the line
21:05 <@ferringb> not sure if we want to add it to devmanual or what, but you get the idea
21:05 <@jmbsvicetto> we should probably add to the QA project space - if QA wants it
21:05  * ferringb nods
21:05 <@jmbsvicetto> like the --as-needed doc
21:06 <@ferringb> jmbsvicetto: either way- guessing you'll take on that responsibility?
21:06 <@jmbsvicetto> yes
21:06 < ssuominen> the should be a "overlinking" page from which .la files -page and asneeded -page is linked to
21:06 < ssuominen> *there
21:06 < ssuominen> opensuse has one.
21:06 < ssuominen> :)
21:06 <@ferringb> jmbsvicetto: ok.
21:06 <@jmbsvicetto> ssuominen: seems we have an "inspiration source" ;)
21:07 <@ferringb> anyone care to be the next chairman also?  because I suck at it, and next month is going to be just as nasty as this month for me work wise ;)
21:07 <@wired> how about this first?
21:07 <@wired> <few_> what do you guys think about finalizing EAPI 4 with the stuff that is currently implemented in portage? there hasn't been much activity on the EAPI front in portage lately and I don't think this is going to change soon.
21:07 <@jmbsvicetto> ferringb: Do we still want to go over EAPI-4? I need to go check on my mother, so I'd prefer to leave in a bit
21:08  * ferringb will answer your question with a question
21:08 <@ferringb> sans <few_>, who hear can state exactly what is implemented in portage right now for eapi4?
21:08 <@jmbsvicetto> if no one wants to be the chair for next meeting, I'll do it
21:08 <@ferringb> preferably now, without going and asking or scraping through the source at the last minute ;)
21:09 <@ferringb> my point is, if eapi-4 is to be what's in portage now, patches needed, list of exactly what's in it's eapi4, etc, is needed
21:09 < ulm> ferringb: I think only "slot operator dependencies" and "profile defined IUSE injection" are missing. bug 273620 is the tracker for portage.
21:09 < willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 4 implementation"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
21:09 <@Betelgeuse> I support releasing everything that's both implemented and has PMS text ready as EAPI 4.
21:09 <@jmbsvicetto> about EAPI-4, I'm fine with going with whatever is done already, although a little discussion about desired features and current implementation could be useful. In the least it might help to start defining goals for the next EAPI
21:10  * ferringb generally does, but doesn't think we should be passing it last minute w/out folks going over it closely
21:11 <@jmbsvicetto> I agree. I'm not ready to vote now for the official EAPI without a complete spec
21:11 <@Betelgeuse> ferringb: the passing is done with a PMS tag any way
21:11 <@Betelgeuse> I don't think there's such a thing.
21:11 <@Betelgeuse> well commit to tag
21:12  * ferringb notes he needs to be disappearing pretty quickly...
21:13 <@jmbsvicetto> I also need to leave now
21:13 <@ferringb> jmbsvicetto: looks as though you're chairing the next round... exact date we'll figure out on the ml
21:13 <@jmbsvicetto> ok
21:13 <@jmbsvicetto> I'll shoot an email to the alias later asking for a date
21:13 <@jmbsvicetto> see you later
21:13  * ferringb nods
21:13 <@wired> sorry
21:13 <@wired> my net went down
21:14 <@ferringb> wired: mostly shifting over to the ml
21:14 <@wired> alrighty
21:14 <@ferringb> jmbsvicetto is chairing the next round, exact date will be figured out there
21:15  * ferringb disappears... back to the imminent release
21:16 <@wired> okie. ftr, the tracker has all the eapi 4 features implemented, only two bugs are open
21:16 -!- darkside_ [~darkside@gentoo/developer/darkside] has left #gentoo-council []
21:17 < ulm> wired: also we don't have PMS wording for all implemented features
21:19 <@Betelgeuse> ulm: are there any blockers on that front?
21:20 < ulm> Betelgeuse: would be nice if somebody provided a wording for REQUIRED_USE
21:20 <@Betelgeuse> ferringb: ^
21:26 -!- scarabeus [~quassel@gentoo/developer/flyingspaghettimonster/scarabeus] has quit [Quit: No Ping reply in 180 seconds.]
21:26 -!- scarabeus [~quassel@gentoo/developer/flyingspaghettimonster/scarabeus] has joined #gentoo-council
21:26 -!- mode/#gentoo-council [+o scarabeus] by ChanServ
21:39 <@ferringb> ulm: yeah, I can do so