let's start then [21:00] *** dastergon (~dastergon@gentoo/developer/dastergon) has joined channel #gentoo-council agenda is here: http://article.gmane.org/gmane.linux.gentoo.devel.announce/1978 roll call here here here proxing for dberkholz here * scarabeus here dilfridge: pling [21:01] start without him? [21:02] let's see if I have his phone number I've sent a text message [21:03] ulm, any response? [21:04] no let's start then [21:05] k 2. Install functions, default src_install http://article.gmane.org/gmane.linux.gentoo.project/2976 it's all in that message, so I've nothing to add here I suggest that we discuss and vote about the two parts separately [21:06] ulm: my sense from the discussion is that there is no real need to make it retroactive. Is there somebody seeking that who I missed? Ie, nothing in-tree depends on the portage-specific behavior. first would be clarification of PMS wording for do* functions: http://article.gmane.org/gmane.linux.gentoo.pms/764 [21:07] rich0: right, we'll come to this in a minute anyone wants to discuss the first part? [21:08] ulm, the clarification would say that do* without arguments die? blueness: exactly portage could keep it's current behaviour for at least a transition time though, i.e. dodoc has only a QA warning [21:09] *its * scarabeus agree with making it fatal :-) Your wording seems fine to me. i'm for it If nothing in-tree now depends on this behavior suggest we keep it that way... [21:10] ok, then please vote for the wording in http://article.gmane.org/gmane.linux.gentoo.pms/764 * ulm yes yes yes [21:11] yes *** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 240 seconds yes scarabeus? *** jcallen (~quassel@gentoo/developer/jcallen) has joined channel #gentoo-council * scarabeus yes unanimously second part is a bit more tricky http://article.gmane.org/gmane.linux.gentoo.pms/766 [21:12] that would change default src_install for EAPI 4 and 5 retroactively but AFAIK it's not used in the tree [21:13] so I'm indifferent i'm not sure we need this retroactive I suggest not doing any retroactive changes if there isn't a need. But by all means keep this undocumented behavior out of portage. * WilliamH isn't sure about this either well what if someone tries this at EAPI=0. they would only get the QA warning. then later when bumping to EAPI=5 the ebuild would die. doesn't sound that bad to me. [21:14] if it is not used in main tree we can even do retroactive fix; but i would leave it to ulm to decide as it is his patch [21:15] scarabeus: that sounds reasonable... let's just vote then [21:16] k approve wording of http://article.gmane.org/gmane.linux.gentoo.pms/766 yes/no [21:17] ulm: what is the vote? I abstain from the vote retroactively changing an EAPI defeats the purpose of EAPIs, so I vote no i vote no to retroactively changing while src_install() is being discussed, I should have suggested looking at bug 459692 at the same time. i'm late as usual. :/ [21:18] https://bugs.gentoo.org/459692 "[Future EAPI] Provide a function, like dodocs(), to process DOCS= without calling `default`"; Gentoo Hosted Projects, PMS/EAPI; CONF; ssuominen:pms-bugs ok if we have 2 and rest indiferent it is no ssuominen: that's agenda topic 3 ulm: that link points to code, not a policy. If you're asking whether or not it should be retroactive, I say no for the stated reasons. ulm: cool! *** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264 seconds [21:19] * WilliamH votes no scarabeus: not sure what your vote was? so far I count 4 no votes, so it doesn't pass [21:20] indiferent thanks next topic [21:21] 3. einstalldocs() pre-approval for next EAPI http://article.gmane.org/gmane.linux.gentoo.project/2978 http://thread.gmane.org/gmane.linux.gentoo.devel/87642/focus=87803 mgorny: are you here? yes mgorny: can you shortly summarise it? [21:22] sure EAPI 4 default src_install() calls 'make install' and installs docs we'd like to split the doc-install part in EAPI 6 to a separate function [21:23] it'd likely be called einstalldocs and fix most of the issues that were pointed out *** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council however, since a lot of eclasses reimplement that doc-install in different ways already we'd like to also the same function to eutils.eclass for older EAPIs [21:24] (and use that consistently in all eclasses) so I'd like the Council to vote on the code i presented that would go into future EAPI 6, and into eutils.eclass *** pacho2 (~pacho@gentoo/developer/pacho) has quit: Quit: Leaving. that's the code in the second link that I've posted above [21:25] mgorny, eutils.eclass would have intelligence to know if eisntalldocs() is defined (ebcause of EAPI 6)? *** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council mgorny: why not just make it part of src_install for EAPI>=6 and add it to utils.eclass for older eapis? blueness: we already did it with something so yea we can do that *** pacho2 (~pacho@gentoo/developer/pacho) has quit: Read error: Connection reset by peer blueness: we already have some backports like this, the functions are inside 'if has $EAPI ...' WilliamH, i think that's what he's saying so i just wanted to be sure [21:26] WilliamH: to clean up most of the using eclasses, otherwise you would have to keep lots of stuff in eclasses WilliamH: that's what i said :) this makes quite lot of sense so I like it works for me, i'm for it mgorny: Oh, I thought you said make it a separate function in eapi 6. ;-) yes, there will be a separate function so people could use it in eclasses without calling 'make install' only one nitpick for the code as i read it now, you should detect the default files and warn if you put them manually to the array/list so we avoid duplication maybe? [21:27] implementation looks sane, and it makes sense to add it to eutils now, but preapprove the implementation for EAPI 6 scarabeus: sounds out of scope of PMS IMO *** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council mgorny: yea, but for the feature implementation which you want to put to eutils anyway... :P scarabeus: sure and i said nitpick, not critical stopper [21:28] I'd test for [[ ${#DOCS[@]} -gt 0 ]] not for [[ ${DOCS[@]} ]] but it's probably a matter of taste [21:29] so also not a stopper yea that is just taste ;-) so, just vote? * blueness yes * ulm yes [21:30] yes yes * WilliamH yes * scarabeus yes unanimous * scarabeus throws cookie on mgorny ;-) thanks yw :) next topic 4. Minor architectures stabilisation policy http://article.gmane.org/gmane.linux.gentoo.project/2984 http://thread.gmane.org/gmane.linux.gentoo.devel/87741 hwoarang: here? [21:31] /&%(/&%)/&%)(/& [21:32] i'm on many arch teams and imho, arch testing is a lot of work sorry lot of busywork dilfridge: hello the question is very simple: why would we not do it? so without the manpower, its hard to say if "stable" even means anything with that low a level of manpower also yea most stable on exotic archs is now "compilation tested" which beats me... is useless [21:33] mips is ~arch and yet hwoarang and mattst88 and I are doing a lot with mips blueness: agree - it just seems like keeping archs that can't keep up just weighs down everybody else, and doesn't really do any service to users of those archs. i spent a whole month last summer trying to get ppc and ppc64 up to date, and it nearly killed me and yet those are in "decent" shape do we have statements from the respective arch teams? [21:34] I've had experiences in the past (not recent past) where arch teams refuse to stabilize something unless users of that arch want the newer version stable. or is that only ago for all of them? WilliamH: wich is also bad ulm: isn't the respective arch teams just ago? ulm: I'm certainly interested in that - I believe I called for that in -dev and didn't hear anything. seems I arrived when the interesting stuff started scarabeus, correct because then packages deps get out of sync some arch team members commented [21:35] but noone from s390 or m68k which are the most critical points dilfridge: last I knew m68k was just vapier [21:36] (at least according to the metrics provided by hwoarang (I think)?) yea it is just mike afaik well even if it is just mike, he didnt comment and you're going to have a hard time interesting him in stabilizations [21:37] my only concern with minor arches is embedded systems, so maybe m68k is used in embedded blueness: still we have testing but its just a question of what we mean by "stable" and if there are not enough people to stable it, then... scarabeus, right i am all in favor of puting all of them to testing-only unless 4 people team is behind them [21:38] I'm going back to my question above: 19:32 < Calchan> the question is very simple: why would we not do it? any reasons? armin76 just blogged on planet.gentoo.org howto use m68k emulator as a arch build host and about stage3's for m68k for the purpose Calchan, that's hard to answer because we don't know what the user base is alpha and sparc are still supported by security not do what? at least that's what http://www.gentoo.org/security/en/vulnerability-policy.xml says scarabeus: I don't care how many are in the team - just that they keep up. If users of some arch hire a full-time dev to stabilize things, more power to them. blueness: true and not true at the same time, this kind of stabilization work doesn't bring any value [21:39] rich0: but it must not end like ago doing everything, he will eventually burn out... yes he will at some point for sure i'm surprised he hasn't yet i've also wondered if we can't automate stabilizations [21:40] ie create a tinderbox with a stabilization queue thats different topic * dilfridge spent a negligible time as amd64 arch tester and felt the pain quickly scarabeus, true yes but that is only good for build testing call the question? so should we vote to kill them and announce it and see the opposition that it rises to revisit it? I still believe that stable testing should be more [21:41] in any case, I agree with scarabeus - I'm inclined to yank them all since nobody really has committed to doing anything to keep them going. scarabeus: who's talking about "killing" them? so, do we vote on it? marking them testing how about, yank m68k and s390 stable and give the others warning? nah yank em all scarabeus: that's the kind of wording which will indeed rais trouble blueness: it's hard to reverse [21:42] s/yank/mark testing/ drop to testing * scarabeus agrees yes, mark them testing * blueness yes yes mark testing = "no stable keyword" which arch's though? let's vote on them separately? [21:43] ? let's be clear on which ones. why not leave them be and just change wording/policy to not list those arch's officially supported. the road from ~ to stable after testing they build/work on m68k and others has been long, so reverting that should not be taken lightly... s390 sh ia64 alpha m68k sparc separate votes yeah in alphabetical order ;) alpha: no more stable keyword? [21:44] * scarabeus yes * blueness yes guys please be careful, we're about to do something irreversible * dilfridge no yes * ulm abstains * WilliamH withdraws... dilfridge: it is revetable quite easily; you can later on pick them up yes folks, I want a way to do something as a maintainer... [21:45] yes easily? not dilfridge: how is this irreversable? it is if you do scrapper for deleted ebuilds too and just parse max subset of keywords and put them back as it compiles, and if you want to get stable arch you have to test it, not just stamp back what it had [21:46] WilliamH: it's hard to get an arch back into consistent state versions will progress after the stable keywords have been removed, everything will have to be retested to get a functioning deptree once you start dropping keywords dilfridge: exactly btw, has anybody tried to get feedback form users on this? not just devs? it helps if you use an arch where compiling is fast :D [21:47] Calchan: would you like to adopt the gentoostats project? AS a maintainer, I would like a policy like this: dilfridge: what's your point? if I have a stable request for a new version of a package and it has been open for 30-60 days or so and minor arch's do not respond or have any blockers on my stablereq, [21:48] knowing how many people really use an arch... we have e.g. ppc64 keywords on whole kde and I know of one user then I want to remove the older versions. looks like the topic needs more discussion [21:49] I don't really care how many users there are - only how well-maintained the stable keywords are. WilliamH: good point. as we've envisaged another meeting for this month anyway WilliamH: full agreement how about postponing the vote by a week? It's not just kids in basement -users, but actual production ... Should we vote on deferral vs immediate resolution? *** jcallen (~quassel@gentoo/developer/jcallen) has joined channel #gentoo-council dilfridge, if we can't maintain a stable set of stabilized ebuilds, we're worse off then dropping to testing and discuss in the mailing lists let's table it well ssuominen: so they can give back some resources or do something against it otherwise it is tough luck [21:50] ulm: it was already discussed * WilliamH agrees with blueness personally I would rather not table. ulm: but that's why I suggested "giving warning" for some arches, i.e. next month we drop if nothing changes it looks lie we don't have a clear view of the actual impact of dropping those to ~arch, so it is clearly premature to vote on this however, up to the majority - I suspect that nothing will happen if we table beyond two more weeks going by ok [21:51] we shouldn't table for long. please vote: defer the decision to next meeting no * blueness yes * dilfridge no which likely will be in september no * ulm yes * WilliamH yes as long as it is this month. yes to defering the vote to when we get enough informaiton to mak ethe decision [21:52] This should not go on forever. I count 4 yes and 3 no Calchan: that's as good as saying "never" forever = infinity times two weeks. :) so, vote will be in next meeting agree which means the alpha decision is scrapped? k next topic [21:53] dilfridge: no, no reply to a request for information is information 5. Specification of /var/db/pkg contents http://article.gmane.org/gmane.linux.gentoo.project/2995 Calchan: that is a data point we already have then. https://bugs.gentoo.org/show_bug.cgi?id=458866 blueness: your topic thanks so this came up because i wrote a utility called revdep-pax Calchan: if no arch team member replies to the discussion on the dev ml, that means it's already dead rich0: I'd disagree, to me it look slike no reasonable attempt at contacting users has been made and that's users we're interested in here, not devs [21:54] i needs a complete linkage map (ie what exes link against what libraries) of the whole system Calchan: speak for yourself, unless we're talking about users who want to be devs. :) this information is constructed by portage and saved in /var/db/pkgs in NEEDED.ELF.2 Caring about users won't help them - only fixing keywords. one can re-generate that info on the fly but it is very very long [21:55] there's lots of other utilities that can make use of NEEDED.ELF.2 info rich0: what I'm saying is we're speculating on the impact of a decision when we should actually research it, I'm not siding one way or the other Calchan: we're off-topic no and so we should probably expose the contents of /var/db/pkgs to other utilities that could use package info rich0: Calchan: please continue later [21:56] zac's comment says it all -> https://bugs.gentoo.org/show_bug.cgi?id=458866#c18 ok we have a couple of fundamental questions here so we need a PMS requirement that /dev/db/pkg information be made available to other usitilites that can use it A) we should decide whether (generically) database information of locally installed packages is within the scope of pms [21:57] the motion would be something like "document and add the contents of /var/db/pkg specified to the PMS specs for interoperability between utilities that need portage information" blueness: I'd say that we need to provide NEEDED.ELF.2 info to packages, not that we need to provide /var/db/pkg info. The latter is one particular implementation of a PM, not a specification. [21:58] rich0, okay we can start with NEEDED.ELF.2 that is the critical body of information because Ciaran claims this is not PMS business, and we can say yes or no Seems to me that what is needed is an API. eg you want to ask a question like "what executables link against this library" ... that's in NEEDED.ELF.2 blueness: I'd rather split it: 1. should we document /var/db/pkg, and 2. should it be in the scope of PMS in a rolling distro like gentoo, that info is critical [21:59] 0. should this be in pms at all? dilfridge, yes all package managers must provide this info for interoperability of utilities so the question does belong in pms, you might say no, but it does belong here I think that having a spec that is reasonable is fine - some kind of API. Call it PMS or not - that is just a title. PMS should really be called "EAPI specification", because that's its intent hehe [22:00] let's vote about renaming pms not now ;) the name is silly anyway ulm, regarding the split: i'm mostly interested in NEEDED.ELF.2 info [22:01] consider revdep-rebuild ... that takes forever because i recalculates this mapping on the fly the same can be done in seconds if NEEDED.ELF.2 info is read emerge @preserve-libs uses it ulm: but there is no connection between EAPI and database format, so renaming it eapi-specs does not cover what we want to add now [22:02] so if we want to write other utilities outside of portage that need the same info, we need to expose it in all package managers dilfridge: yes, that's exactly the point ulm, i would be happy with an abstraction layer to free up the db formate * WilliamH thinks the database format would be a completely separate document [22:03] not pms * scarabeus dont care about what document to put it to, but it should be documented and expected by all package managers and thats it so, how about a first vote if we want the VDB documented at all? ulm, the way you phrase it above pulls in too much [22:04] and a second vote if it should be part of PMS or a separate document (e.g. a GLEP) ulm: is having the VDB documented in PMS the only possiblity? can i try again? ah ok, sorry blueness: ++ agree on abstraction layer ulm: how about first a vote whether vdb information (independent of format) should be documented? (in pms) dilfridge: or that dilfridge: not so much documented, as made available (in a documented manner) yep better Ie, direct parsing of PM files isn't the interface motion: all package managers should export NEEDED.ELF.2 information for interoperability between utilities and portage k [22:05] how does that sound? blueness: like skipping ahead :) i'm not that worried about documenting all of vdb [22:06] ok other suggestion so i'd like the vote to concentrate on export NEEDED.ELF.2 info Coulda, woulda, shoulda. :) We can certainly suggest intended direction, but implementation will be up to the PMs to carry out. [22:07] rich0, exactly vote on "Making VDB information (independent of database format and package manager) available is within the scope of PMS" i'll live with whatever makes the maintainer's life easy dilfridge, no that is not the issue as i said it pulls in too much, NEEDED.ELF.2 is the critical piece [22:08] blueness: I know that, but let's squash possible resistance against the inclusion into specs first it doesn't squash the resistance anyway Are the portage/whatever maintainers willing to implement some kind of interface? I'm fine with saying that the council encourages this, but nothing will happen unless somebody is willing to do the work. how about we vote on blueness motion? rich0, zac is [22:09] and i'm okay with an intended direction without burdoning people blueness: thanks - then I'm all for encouraging the creation of a PM-neutral API for providing VDB info available to utilities. *** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 246 seconds *** jcallen (~quassel@gentoo/developer/jcallen) has joined channel #gentoo-council I think quite a bit of info is already available in APIs for both portage and paludis - just without any standardization between them, and I can't speak to NEEDED.ELF.2 in particular. [22:10] rich0, should it be all of VDB or just NEEDED.ELF.2, we can always revisit other vdb elements rich0, let's stick to my motion first and then see if there are other vdb elements that need exposure Suggest that we let the PM teams cooperate and expose what they can. agree to start with that one field. [22:11] how about this: "the council recommends that package managers export information NEEDED.ELF.2 information for interoperability between utilities" rich0, sure Would love to see a well-documented PM-neutral API for this stuff. oops ulm, works for me "the council recommends that package managers export the NEEDED.ELF.2 information for interoperability between utilities" rich0, so would i but that's a lot of work! blueness: vote on this? ulm, okay i accept that as a friendly amendment let's vote * blueness yes [22:12] * dilfridge yes can I votre "meh"? s/votre/vote/ (but I think it it's too soft a statement) well, it would be easier if there was a draft spec already [22:13] yes like a GLEP ulm: agree that really it needs a spec - this is more about intent/direction ok let's finish the vote yes but we're not going to bikeshed a spec on irc here * ulm yes * scarabeus yes [22:14] rich0: but we could try! Calchan: "meh" is an abstention? ;) the fact nobody ever done that should not stop us :D scarabeus: you can try - I have someplace to leave for in 5min :) * WilliamH doesn't think it is up to us to come up with the spec ulm: take it as what you want, but meh it is anyway, 6 yes votes so it's accepted [22:15] the intention could be fulfilled by a glep yippy! blueness: anything else on this topic? ulm, no just that i like the idea of a glep here but that's beyond us otherwise, it's 20:15 UTC [22:16] call it a meeting and continue next time? so I suggest that we proceed to open floor here and move the rest of topics to another meeting ok agree - I have to take off in any case yes, open floor now, next week another meeting [22:17] everyone o.k. with next tuesday, same time? fine with me wfm works for me *** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264 seconds wfm * blueness must feed my dog! brb *** jcallen (~quassel@gentoo/developer/jcallen) has joined channel #gentoo-council *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: 17 Sep 2013 at 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://www.gentoo.org/proj/en/council/" so, open floor [22:18] * ulm listens nothing, it seems [22:19] so let's close the meeting here [22:20] thank you everybody thank you for chairing ulm: thanks :) ah everyone o.k. with me chairing in one week? sure