[22:01:44] *** Joins: jlec (~jlec@gentoo/developer/jlec) [22:01:53] here [22:01:53] tomka, you have notes! [17:16] thats a fun OSX error o_0 [18:46] how about moving the tatt source code to the arch-tools repository please?! [22:02:13] hi [22:02:59] let's wait another minute or so, although not sure we'll be so many of us [22:03:53] Actually the science channel looks quite full [22:04:32] may be we should switch the meeting there then [22:04:53] ok, let's start [22:05:06] I am supressing the join/part messages so I don't know when they all joined [22:05:06] 1. alternatives [22:05:26] Who is willing to work on that? [22:06:03] i'm working on an eselect fork, some fixes are already on github.com/gentoo-science/eselect.git [22:06:31] I'm mostly in maintenance mode, not going to take over new projects, sorry. [22:06:33] How much work do you think needs to be done until we can start merging it into the main eselect? [22:06:45] more fixes will follow this week end to do the alternatives_for into the eselect [22:07:04] is ulm following the changes? [22:07:15] these last fixes should be enough for ulm to review and pull [22:07:24] perfect. [22:07:41] That you are taking care of eselect. [22:07:45] then there is the ldscript issue, which i have not started [22:07:46] yep [22:08:12] yeah about the ldscript thing. [22:08:12] *** Joins: heroxbd (~user@gentoo/developer/heroxbd) [22:08:17] after those fixes the eclass will need to be rewritten, but it should be much more simple [22:08:31] sorry I'm late, it's 5am here. [22:08:44] no problem [22:08:48] we just started [22:08:55] ;) [22:09:07] bicatali: so we are waiting for you to fix eselect [22:09:21] so has anyone tried the eselect-9999 from the science overlay? [22:09:39] not yet, but I will switch to tomorrow [22:10:11] * heroxbd is wondering if it is about blas/atlas/gotoblas selection [22:10:19] i would like a tester for the current eclass/eselect with multiple blas [22:10:25] heroxbd: alternatives framework [22:10:32] I see [22:10:53] heroxbd: you need to unmask eselect-9999::science [22:11:13] bicatali: I'd like to be a tester, too. [22:11:19] the other issue is what we do with library sonames [22:11:31] right [22:11:43] But I still disagree with equalizing them [22:12:02] You are right we reduce the rebuilding when one implementation is drop [22:12:04] ped [22:12:07] so debian changes soname for atlas and openblas to blas [22:12:28] But we loose the ability to use different blas implementations for different programms [22:13:31] What do we gain in addition to the rebuilds to set all sonames to blas? [22:13:33] i don't think we want users to compile R against openblas-threaded and octave against atlas [22:13:49] Why not? [22:14:37] it's calling for bugs while rebuilding, and what do we do if the user removes one provider? [22:15:00] portage should catch that and preserve libs. [22:15:03] and truely, once you choose one, you don't move [22:15:25] Not that I would recommend using different blas for different apps [22:15:31] But it's about choice [22:15:35] we could do more eselect modules: blas-threads, blas-serial, blas-int64 [22:16:21] just to confirm, they cannot be made ABI at all. So we are exclued with this probability, is that true? [22:16:27] so instead of splitting into different providers, splitting into different types of implementation. [22:16:30] ABI-compatible I mean [22:16:59] bicatali: that sounds like a good idea [22:17:29] yes, so we would use the mutlibuild eclass for each, then add some use flags threads, int64, etc... for the dependent packages [22:18:02] bicatali: but what about the libs which are splitted in to different so files? How do you handle sonames there? [22:18:15] this makes sense: sometimes a threaded program does want a serial blas to avoid oversuscribing [22:18:38] same soname for a given eselect module? [22:19:20] right now i would suggest lets split, then later on let's worry about soname/ldscript [22:19:49] split what? [22:20:22] let's make several blas eselect modules: blas-serial, blas-threads, ... [22:20:59] and add use flags to virtual/blas [22:22:15] And would that look for different providers for e.g. blas-serial? [22:22:30] so atlas and reference are installed and provide serial [22:22:40] How can the user choose? [22:22:51] use flag? [22:23:19] threads? ( virtual/blas[threads] ) [22:23:56] so we have can do eselect blas-thread set atlas ? [22:23:59] the worry about this is: much work to change ebuilds [22:24:34] eselect blas-threads to select atlas-threads [22:24:47] eselect blas-serial to select atlas... [22:25:14] and what if want now reference ? [22:25:44] only on eselect blas-serial and virtual/blas with -threads [22:26:25] So you want to control everything over virtual/blas? [22:26:57] on the package level yes, or do several virtual/blas-* [22:27:30] it seems it needs more thinking, so let's set this for another time [22:27:56] yes fine. Perhaps you could write up a draft of your ideas [22:28:34] * heroxbd considers a written guideline for us and the users necessary [22:28:41] so actions: i'll finish the eselect, heroxbd will test the current builds with it [22:28:55] I will also test [22:29:13] sounds good [22:29:14] anyone wants to investigate multibuilds? [22:29:16] no problem [22:29:29] I've been googling for it [22:29:34] bicatali: I can take a look [22:29:49] but we need to have a chat about your exact ideas [22:30:08] yes. and let's start an alternatives wiki page [22:30:37] btw anyone with another word than 'alternatives' is welcome [22:31:05] * jlec slowly gets bicatali plan [22:31:39] time to switch to the 2. documentation [22:31:52] WE need more. [22:32:04] exactly [22:32:23] I am trying to work on the whole contribution/community part [22:32:43] And I am currently in progress to move the mpi.eclass/empi thing to the tree. [22:33:08] This also need more documentation, which is probably more a business of the clusterteam [22:33:31] Which other documentations are top priority? [22:33:33] regarding https://wiki.gentoo.org/wiki/Project:Science: it would be nice if everyone reads all the pages/subpages and resources [22:34:36] like the Gentoo Electronics project and herd are empty [22:34:49] but is it? [22:34:56] the mail alias is not [22:35:26] bicatali: I will go through it and send mails to the aliases. [22:35:57] !herd sci-electronics [22:36:00] jlec: (sci-electronics) calchan, rafaelmartins, tomjbe, xmw [22:37:38] And wee need to increase the staffing needs [22:37:45] As we really need staff [22:37:58] BTW please try to recruit [22:38:19] so let's push some jobs in the next gmn [22:38:19] we are super fast in recruiting currently so the process is really fast [22:38:28] good idea [22:39:10] who would like to review all the wiki pages to make them consistent? [22:39:30] I can, haven't read it carefully yet [22:39:32] i've tried quite a bit already, but it needs more reviewing [22:39:46] What's inconsistent? [22:39:57] jlec: want to ping the herds to include themselves in the wiki? [22:40:06] It seems to be quite consistent [22:40:12] herds, members and mail aliases [22:40:18] bicatali: ask for input on their pages [22:40:29] I will also go through it [22:41:04] Recruitment looks pretty much boilerplate. [22:41:09] It's the same on every sub-page. [22:41:23] But missing on sci-biology [22:41:27] just want to make sure we can get rid of http://www.gentoo.org/proj/en/science/index.xml [22:41:28] are they fully staffed? [22:41:42] which is still the first google result for gentoo science [22:43:08] I will first take a look that everything from the old xml site is covered by the wiki and then clean/improve the wiki pages. [22:43:12] so the task is to review the wiki to make sure it has the full coverage of proj/science/xml and then redirect it. [22:43:48] yes, the blas-lapack page i will start the rewrite with the alternatives [22:43:48] !herd sci-biology [22:43:49] heroxbd: (sci-biology) je_fro, jlec, weaver [22:44:05] !herd sci-geosciences [22:44:06] bicatali: (sci-geosciences) fordfrog [22:44:06] heroxbd: it's just me [22:44:20] ;) [22:44:32] so these sub-projects make sense? [22:44:59] you mean the packages in the wiki or the herd subdivision? [22:45:05] I think so, there would be more stuff. [22:45:36] we have both sub-herds and sub-projects [22:46:00] ok, let's keep it that way and get more people i guess [22:46:28] sub-projects don't make really sense. [22:46:33] sub-herds do [22:47:17] I think the sub-projects should be things like the alternative framework rather then different science fields [22:47:29] well we had this: http://www.gentoo.org/proj/en/science/electronics/ [22:48:09] so we can add the electronics test bench sub project [22:48:36] first make sure that electronics is active... [22:49:02] So I will ask the current sub-projects if they are willing to merge into the parent [22:49:14] or otherwise maintain their subpage [22:49:24] yes, and then re-organize the wiki [22:49:26] rafaelmartins: what about sci-electronics? [22:49:34] !seen rafaelmartins [22:49:37] jlec: rafaelmartins was last seen 4 hours, 44 minutes and 31 seconds ago, joining #gentoo-prefix [22:50:35] we can make alternative framework itself a subproject in parallel to the fields. [22:51:22] i'd rather see the alternatives part of the eselect, i'll talk to ulm [22:51:32] kk [22:52:00] jlec: hello [22:52:05] hi [22:52:08] * rafaelmartins jumps in the meeting [22:52:18] hi [22:52:21] I will send around mails [22:52:26] that's better [22:52:30] so, we are having low activity lately [22:52:31] actions: wiki review herobxd, jlec. wiki reorg: jlec?. alternatives write-up start: bicatali [22:52:37] rafaelmartins: oi [22:52:45] bicatali: oi :) [22:53:01] bicatali: I will take care of the wiki [22:54:14] finally: 3. new leader [22:54:21] i nominate jlec [22:54:46] * heroxbd nods [22:54:46] Thanks. I accept the nomination. [22:54:53] I second that. [22:54:59] about electronics, quickly: [22:55:33] I'am not doing a lot of work on this. mainly maintaining just the stuff I use to play for fun, not working with any eng-related stuff at this point [22:56:12] I assumed as lead mainly because calchan wasn't able to do it at that time, my plan is to schedule a subproject lead election soon [22:56:37] rafaelmartins: pushing for new recruits and updating the wiki should be enough for electronics to survive [22:56:42] rafaelmartins: I will take care of the wiki and do the rest by mail to the alias [22:56:50] so, the subproject still exists, but with quite low activity at this point [22:56:59] rafaelmartins: or would like to merge the sub project into science? [22:57:10] bicatali: yeah, we got some people interested, but they disappear :( [22:57:34] heroxbd: I'd like to hear calchan's opinion on this [22:57:52] rafaelmartins: ok [22:57:59] we can keep everything as is now, just migrating the project page to the wiki and decide on it later [22:58:05] rafaelmartins: could you help jlec merging the old page into https://wiki.gentoo.org/wiki/Project:Electronics [22:58:16] bicatali: of course [22:58:49] *** Joins: fbissey (~fbissey@132.181.64.206) [22:58:53] ok voting: i vote for jlec as new leader [22:59:08] +1 for jlec [22:59:10] Just in time for the vote [22:59:17] hey fbissey [22:59:23] I vote for jlec, too [22:59:27] fbissey: hi [22:59:39] no surprise that jlec is put in the driving seat [22:59:52] +1 for jlec [23:00:49] jlec: clearly you are our new leader, please someone kicks me out from this channel! [23:01:08] THank you everbody [23:01:12] bicatali: ;) [23:01:15] congrats! [23:01:50] ANd thank you bicatali doing the work the last years [23:01:55] jlec: hey you haven't voted yet [23:01:59] yeah thanks bicatali [23:02:24] thanks for putting up with us bicatali [23:02:50] bicatali: yeah, thanks. And may I ask why you stepped down and what's your plan with science herd next? [23:03:02] i'll try to clean up my leadership with a bug free alternatives [23:03:36] I remember jlec and I came to gentoo at the same time and he is lead and I haven't made it to developer yet [23:03:52] heroxbd: jlec is more involved than me. i'm going to work on an automated gentoo [23:04:07] fbissey: wow [23:04:38] I think we set some nice clean up for the next months. [23:04:39] bicatali: that's cluster deployment? [23:04:58] Getting the alternatives into the tree should be top priority. [23:05:11] jlec: agreed. [23:05:43] jlec: and as the wiki reorg/review overlaps, you can assign me some jobs in detail. [23:05:59] heroxbd: no, some minimal gentoo core + cvmfs ala coreos to automate stabilizing [23:06:20] anyone keeping logs? [23:06:31] I am logging [23:06:54] ain't there a 4. open floor? [23:07:15] just some FYI: first some news from roverlay. [23:07:18] heroxbd: yes you are right [23:08:27] I started co-maintaining the roverlay with calchan, it is automated generatedfrom cran. once it's mature, I'll write up some doc [23:08:49] that is good news [23:09:13] sorry, creepy internet connection [23:09:32] jlec: want to post meeting log on the wiki then? [23:09:48] bicatali: I will [23:09:56] heroxbd: can it take other R repo like bioconductor? [23:11:04] fbissey, I think it high possible, as the overlay generation tools are actively developed by another student. [23:11:13] *highly [23:11:32] it has been a google summer of code project [23:12:57] FYI2, among the Prefix users, many are from academic field. They submit bugs, and are good candidatesfor recruitment. [23:14:38] heroxbd: sounds great. [23:14:45] ok folks, thanks, i'm off the meeting [23:14:53] make them fix the quizzes and get them a bug [23:14:57] bye bicatali [23:15:05] bicatali thanks for all [23:15:07] bye [23:15:28] bicatali: see you [23:17:30] Okay guys, anymore more openfloor topics? [23:17:34] are we waiting for closing the meeting? [23:18:08] I have some stuff but I will probably post on list for discusion [23:18:19] If there is nothing else, I would close it [23:18:47] We can schedule the next meeting sooner, in 1-2 months or so [23:19:12] fbissey: Or do you want to discuss now. It is up to you. [23:19:31] I can introduce it. [23:19:58] blas/lapack setup in python package is horrible [23:20:26] motivated by work I am doing with people in sage I trying to get stuff to simplify that [23:20:27] We should wait for this a little [23:20:39] fbissey: python build system tries to do all the smart but wrong guessing [23:21:00] After bicatali fixed eselect and we decided about the soname thing, we shoudl have an ldscript [23:21:10] then it will become easier [23:21:13] there is a python module to interface with pkg-config that makes some things easier [23:21:22] good idea [23:21:42] fbissey: best would be to simply have libblas.so as ldscript [23:21:57] but that should be implemented after we fixed the rest [23:21:59] that make things easy agreed. [23:23:57] nothing more from me [23:24:05] fine [23:24:18] So I will close the meeting here. Thanks for attending. [23:24:29] I will post the meeting log on the wiki [23:24:36] Thanks all [23:24:47] thanks [23:25:30] *** Parts: fbissey (~fbissey@132.181.64.206) ("Konversation terminated!") [23:33:09] *** Quits: tomka (~tomka@gentoo/developer/tomka) (Quit: tomka) [23:44:50] *** Joins: Calchan (~calchan@gentoo/developer/calchan)