19:59:29 jlec: Hi there
19:59:45 jlec: Should we beginn?
20:00:18 K_F: *is here*
20:00:23 jlec: *here*
20:00:25 ulm: *here*
20:00:31 WilliamH: *here*
20:01:04 rich0: *here*
20:01:11 jlec: dilfridge, blueness are you there?
20:01:15 blueness: here
20:01:26 blueness: yeah just got my espresso
20:01:45 blueness: and this time i coverted utc correct … i think i deserve a cookie
20:01:51 K_F: 
20:02:04 WilliamH: 
20:02:05 jlec: should we wait a little for dilfridge or just beginn?
20:02:07 K_F: all I have to offer are cigars..
20:02:14 K_F: jlec: I suggest waiting a few minutes
20:02:32 jlec: Hi has been around a couple of hours ago
20:02:38 jlec: creffett|irssi: ping
20:03:22 dilfridge: err
20:03:24 dilfridge: &/%/)&%
20:03:28 dilfridge: here
20:03:33 jlec: alright
20:03:35 blueness: fun!
20:03:44 jlec: 1) Further discussion on GLEP 67
20:03:48 dilfridge: (by accident... somehow daylight savings time has made a lasting impression)
20:03:53 mgorny: *around too*
20:03:57 jlec: https://wiki.gentoo.org/wiki/GLEP:67

https://archives.gentoo.org/gentoo-project/message/637270936c9f07e3bd2f10ee45264a42


20:04:08 mgorny: jlec: that's outdated
20:04:21 K_F: https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67
20:04:28 mgorny: yes, thanks
20:04:33 jlec: mgorny: please give us a short update on you latest work
20:05:02 mgorny: well, everything looks pretty promising
20:05:16 mgorny: most of herds are either migrated to projects or marked for disbanding
20:05:32 mgorny: there's a few defunct herds left which we'll probably be dropping to other maintainers or maintainer-needed
20:05:48 mgorny: i've cleaned up the spec trying to make it more informative
20:05:59 mgorny: and added reference impl section on all related software in use
20:06:07 mgorny: projects.xml is already being generated by infra
20:06:21 mgorny: scripts to convert everything are ready and there's today's conversion on github
20:06:41 jlec: great, thanks for your work!
20:06:50 mgorny: is there anything else i should mention? ;-p
20:07:01 K_F: the update sounds good to me
20:07:02 jlec: Anything left open beside the last mapping things?
20:07:02 blueness: what’s the inheritance like
20:07:08 blueness: between project and subproject
20:07:10 blueness: N:M
20:07:43 mgorny: optionally parent project can copy members from subproject
20:07:55 mgorny: something like emacs = gnu-emacs + xemacs
20:08:01 mgorny: (+ extra members if needed)
20:08:16 ulm: mgorny: well, that doesn't really work
20:08:18 blueness: so a subproject can have serveral parents? correct?
20:08:26 ulm: because it's not transitive
20:08:33 mgorny: blueness: no
20:08:41 mgorny: emacs is parent in my example
20:09:36 ulm: I mean, it doesn't work in the wiki
20:10:02 blueness: okay
20:10:09 mgorny: ulm: wiki only provides the attribute
20:10:24 mgorny: we'd be doing 'inheritance' on top of xml ourselves
20:10:46 ulm: mgorny: I see
20:11:53 jlec: Are we satisfied with the way projects and subprojects are handled in the GLEP?
20:12:39 blueness: jlec: i wonder that
20:13:02 blueness: because something like the uclibc subproject or musl subproject could be subprojects of both base-system and hardened
20:13:10 dilfridge: what problems do you see? and are they problems now, or can they be fixed via an extension later?
20:13:44 blueness: but i can live with this, i’m not sure if this will become a problem
20:13:50 dilfridge: yeah but that's a problem with the wiki implementation, not with the glep
20:13:57 blueness: right
20:14:09 mgorny: if i recall right, i stated that the glep doesn't cover if it's 1:n or m:n
20:14:16 jlec: "It is undefined whether a project can have more than one parent project."
20:14:33 blueness: mgorny: its okay i don’t want to push it, but note it since we are discussing it
20:14:53 jlec: Do we need to define this now, or can we leave this open until we figure a slution for the wiki problem?
20:15:00 blueness: okay well i’m ready for the vote
20:15:16 blueness: jlec: nah, maybe NOTE that its unspecified
20:15:24 blueness: like opengroup does with POSIX
20:15:33 K_F: jlec: there is a 2nd alternative to keeping it unsepcified
20:15:42 jlec: go ahead
20:15:47 blueness: mgorny: did you specifiy in the glep that 1:n or n:m isn’t specified
20:16:03 K_F: and that is defining that it can have only one, but add an optionality that it later can be changed and how that would be communicated
20:16:40 mgorny: blueness: yes, jlec already quoted that
20:16:54 blueness: ah that’s what he was quoting, i’m good
20:17:10 mgorny: xml can handle m:n, and i guess the implementations won't care much
20:17:11 blueness: i thought he was quoting our last meeting
20:17:27 mgorny: since the idea is pretty much 'i see subproject with copy-members, i copy members'
20:17:27 blueness: mgorny: yeah we can leave it to the implementation constraints
20:17:34 jlec: So should we fix it now, with an optionally clause or leave it as is?
20:18:17 K_F: I'm in favor of specifying it
20:19:08 jlec: The only reason would be the wiki interaction, wouldn't it?
20:19:25 jlec: xml is fine as mgorny says.
20:20:14 blueness: K_F:  the advantage to not specifying it in the glep is that we don’t have to fight implementation contraints like the wiki
20:20:19 blueness: but we may want it
20:20:19 mgorny: probably
20:20:57 K_F: blueness: keeping a 1:n mapping initially with an optionality clause would make that update rather easy, though
20:21:18 dilfridge: why not leave it unspecified in the glep?
20:21:19 jlec: I would suggest we leave it open, as that is what reflects reality and seek for fixing tools (eg wiki) later.
20:22:00 K_F: if that is the general consensus I don't really feel too strongly about it, just a principle of undefined behavior is scary ..
20:22:11 blueness: whatever, i just want the issue noted and not bind the hands of those who are going to implement things
20:22:32 WilliamH: *agrees with leaving it open*
20:23:04 jlec: okay, let's vote then
20:23:06 jlec: Vote: The council approves GLEP 67 (with wording from https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67).
20:23:10 K_F: *aye*
20:23:14 jlec: *yes*
20:23:14 blueness: *yes*
20:23:22 dilfridge: *yes*
20:23:33 WilliamH: *yes*
20:23:40 ulm: *yes (wording as of 08:14, 10 January 2016)*
20:23:59 jlec: rich0?
20:23:59 rich0: *yes*
20:24:08 ulm: ^^ can we add this timestamp please?
20:24:19 jlec: ulm yes
20:24:40 blueness: ulm: sure
20:24:48 jlec: Vote: The council approves GLEP 67 (with wording from https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67 as of 08:14, 10 January 2016).
20:24:51 blueness: ie the latest i assume
20:24:56 jlec: *yes*
20:24:58 ulm: hm, not sure if that's utc
20:25:03 blueness: *yes*
20:25:11 ulm: *yes*
20:25:16 dilfridge: fine with me
20:25:17 dilfridge: https://wiki.gentoo.org/index.php?title=User:MGorny/GLEP:67&oldid=418278
20:25:18 mgorny: ulm: i think it's utc
20:25:19 ulm: blueness: yep, latest
20:25:23 dilfridge: ^ I guess that is what you really want
20:25:26 rich0: wfm
20:25:28 mgorny: it was after 9 my time 
20:25:29 dilfridge: *yes*
20:25:40 jlec: yes:7 no:0 abstained:0
20:25:51 jlec: mgorny, thanks again for your work.
20:25:55 mgorny: np
20:26:03 jlec: Next topic
20:26:04 mgorny: do we want to set some deadlines for herd maintainers to decide?
20:26:18 jlec: good idea
20:26:27 jlec: 2,3,4 weeks?
20:26:39 mgorny: i'd go for 2, most of the work is done
20:26:47 dilfridge: sounds good
20:26:54 mgorny: no point in delaying it forever
20:26:59 ulm: the more interesting question is what we intend to do if the deadline expires for a herd
20:27:07 K_F: since work is already started, I'm ok with 2 weeks
20:27:15 mgorny: jlec already suggested dropping to other maintainers or maintainer-needed
20:27:26 mgorny: we effectively have herds maintained only by MIA developers
20:27:26 jlec: ulm: m-n or create project from herd I would say
20:27:28 rich0: I agree, I think plenty of time has already elapsed
20:27:57 mgorny: creating dummy projects sounds bad, as we create an abstract entity that doesn't maintain the package and put the bug mail in /dev/null
20:28:20 K_F: yeah, if a new project isn't created (at least after having asked relevant herd), its better to drop to m-n
20:28:25 ulm: so m-n unless there are other maintainers
20:28:34 K_F: we have too many packages that are effectively not maintained but hidden already
20:28:42 K_F: ulm: I'd second that
20:28:43 mgorny: well, m-n is implicit now, so that's kinda implied 
20:29:22 mgorny: *should probably write some official announcement with quick notes on stuffs*
20:30:00 jlec: Vote: The council asks all remaining herds to be migrated to the new project structure by January 24th 2016. All remaining herds will be integrated into the maintainer-needed project
20:30:20 jlec: Is this what we want?
20:30:28 dilfridge: *yes*
20:30:51 jlec: *yes*
20:30:53 mgorny: there's no maintainer-needed project
20:30:56 blueness: *yew*
20:30:57 blueness: yes
20:31:04 rich0: *yes*
20:31:06 K_F: isn't maintainer-needed just defined as special case?
20:31:08 dilfridge: well, then just state "... will be dropped"
20:31:10 ulm: mgorny: I just wanted to ask that
20:31:14 jlec: mgorny: how are those packages handled?
20:31:26 mgorny: they simply have no maintainers
20:31:33 mgorny: i.e. zero <maintainer/> elements
20:31:59 WilliamH: What do we do about people who just want to follow the bugs for a package?
20:32:08 WilliamH: and aren't active maintainers?
20:32:23 mgorny: WilliamH: i think that's outside the scope, GLEP67 is focusing on responsibilities
20:32:40 mgorny: we really need something more specific for assigning bugs to packages rather than to people
20:33:25 jlec: Do you think we need to rephrase the vote?
20:33:35 mgorny: and i don't think metadata.xml can work for that since it requires commit access for gentoo.git
20:33:40 WilliamH: mgorny: so for udev for example: udev-bugs... there are folks there who aren't active maintainers.
20:33:42 ulm: maybe the old <herd> info should be kept commented out if the herd is dropped
20:33:42 K_F: jlec: I would keep "project" out of it, otherwise I'm good
20:33:51 jlec: Vote: The council asks all remaining herds to be migrated to the new project structure by January 24th 2016. All remaining herds will be dropped.
20:33:52 K_F: just "into maintainer-needed"
20:34:02 K_F: ok, that works too..
20:34:03 mgorny: WilliamH: aliases are independent, so people can just add themselves to the mail alias
20:34:04 K_F: *aye*
20:34:08 jlec: *yes*
20:34:10 zlg: If you save a search in Bugzilla, there's an optional Atom feed you can subscribe to. Just checked it myself. Not sure if that's relevant.
20:34:16 ulm: *yes*
20:34:19 WilliamH: *yes*
20:34:28 dilfridge: *yes*
20:34:39 rich0: *yes*
20:34:42 blueness: *yes*
20:34:48 mgorny: any more questions?
20:34:50 jlec: yes: 7 no: 0 abstained: 0
20:35:17 jlec: mgorny: Could you please write some reminder for the remaining herds?
20:35:29 mgorny: ping on bugs?
20:35:37 mgorny: kensington has volunteered to move things forward
20:35:50 mgorny: he's talking to people directly and doing the hard work for them
20:36:06 K_F: do we need to say anything about conversion from the defined mapping vs herds updating metadata themselves?
20:36:06 jlec: ping on bugs is enough I would say
20:36:26 K_F: do we have scripts in place that can automate it?
20:36:53 jlec: mgorny ^^
20:37:00 mgorny: K_F: could you rephrase?
20:37:46 K_F: mgorny: do herds/maintainers need to update the metadata themselves, or do we automate it based on the mapping after deadline so don't have to think about it
20:38:14 mgorny: it's all automated
20:38:27 K_F: what I thought, nice if that is stated in the communication
20:38:40 K_F: to avoid any confusion/discussion
20:38:49 jlec: Do we need to vote on the exact date of the switch, or do we consider the 2w as it?
20:38:51 mgorny: i will write an announcement today or tomorrow
20:39:06 mgorny: with explanation of what to do, what will change etc.
20:39:08 K_F: jlec: that should be clear enough
20:39:12 mgorny: so hopefully nobody will get confused
20:39:17 jlec: perfect
20:39:24 jlec: I would say that's it then
20:39:31 K_F: mgorny: thanks
20:39:37 jlec: Next topic: 2) Banning of EAPI 0 & 3 for new ebuilds
20:39:45 jlec: https://archives.gentoo.org/gentoo-project/message/bc0a1b7498c389bdbb0b0d52feb43391


20:40:05 ulm: s/new/& and updating existing/
20:40:22 K_F: I'd request a security bump exception if there is a simple patch applied
20:40:36 blueness: ulm: uclibc.ebuilds might need some time for upgrading to 5
20:41:17 mgorny: i'm not convinced about that
20:41:39 mgorny: sometimes i do random qa fixes on random packages, and i don't really want to be responsible for eapi bumping something i have no clue about
20:42:00 jlec: The max exception I would accept are sec bugs.
20:42:24 blueness: mgorny: i’m not sure really because its still vapier’s package, but i think i’ll just do the rewrite, i don’t hitnk he’s too interested
20:42:25 rich0: jlec: ++
20:42:27 K_F: QA isn't time sensitive per se
20:42:35 K_F: a sec bug might be, and going into untested waters with it..
20:42:39 mgorny: like when i had to remove mirror://berlios from a lot of packages
20:42:40 jlec: mgorny: it's about updating EAPI in existing ebuilds, not ebuilds at all
20:43:18 ulm: it's just about extending the existing ban for EAPIs 1 and 2
20:43:23 ulm: to EAPIs 0 and 3
20:43:41 ulm: and I'm not aware of any issues with the 1/2 ban
20:44:19 rich0: Nobody even raised a concern to a 0/3 ban either.
20:45:16 jlec: Exception or not. What are your ideas?
20:45:31 mgorny: oh, sorry, i misunderstood 'updating existing'
20:46:18 ulm: should be "updating the EAPI in existing ebuilds"
20:46:44 K_F: to have it in the logs; https://qa-reports.gentoo.org/output/eapi_usage.txt
20:46:49 K_F: EAPI 0:    2705 ebuilds ( 6.94%)  ###
20:46:55 K_F: EAPI 3:     819 ebuilds ( 2.10%)  #
20:47:57 ulm: right, and EAPI 2 had about 3000 ebuilds at the time we banned it
20:49:25 WilliamH: *is ok with extending the ban*
20:49:37 dilfridge: *too*
20:49:49 WilliamH: to cover 0 and 3.
20:50:00 blueness: brb in 2 mins
20:50:06 jlec: How about the an security exception clause?
20:50:16 ulm: I have no strong opionion about it
20:50:21 ulm: but if asked I would say no
20:50:23 K_F: I'm OK with banning, but if we don't have a security exception it might result in package masking instead if maintainer doesn't update EAPI, which can potentially require more work
20:50:44 blueness: back
20:50:49 jlec: K_F: perhaps that would push to EAPI upgrades
20:50:57 WilliamH: *is with jlec there*
20:51:03 mgorny: jlec: afraid things don't work that way
20:51:16 WilliamH: If we don't push the eapi upgrades people will keep adding ebuilds with old eapis
20:51:17 mgorny: unless you expect security to handle that
20:51:20 jlec: How likely is that are blocked by an impossible EAPI bump?
20:51:41 jlec: some "we" is missing in that sentence
20:51:42 K_F: jlec: it is a larger change, so it can block fast stabilization at least
20:52:19 blueness: WilliamH: i’m okay with not allowing new eapi=0 commits but not remove the current ones like we did with 1/2
20:52:24 jlec: but how many packages are completely at these EAPI levels
20:52:30 ulm: if a package is still at eapi 0 and has security issues then maybe dropping it is the better option?
20:52:43 WilliamH: ulm: maybe
20:52:47 K_F: ulm: depends on what type of package it is
20:52:55 mgorny: ulm: i'd be worried about revdeps
20:53:16 K_F: can make the exception more fine-tuned to commonly used library or something
20:53:53 jlec: I don't think we can find a good wording for that
20:54:12 jlec: "commonly used" is very vague
20:54:22 WilliamH: *tends to agree with ulm, especially if the package hasn't been worked on in a while.*
20:54:26 ulm: K_F: I'm fine with an exception for security bumps
20:54:43 rich0: I'm fine either with or without an exception
20:54:55 jlec: Can we agree on the following?
20:54:56 jlec: Vote: "EAPIs 0 and 3 are banned. This ban includes both new ebuilds and updating the EAPI in existing ebuilds. Only exception is minor patching for security issues"
20:55:11 ulm: s/for security issues/by the security team/
20:55:12 rich0: *yes*
20:55:15 K_F: *aye*
20:55:28 dilfridge: *yes*
20:55:31 jlec: Amend or not?
20:55:33 WilliamH: *yes wth ulm's changed wording*
20:55:36 blueness: *yes*
20:55:38 dilfridge: *yes amended*
20:55:45 jlec: *amended *
20:55:51 ulm: *yes (amended)*
20:55:53 jlec: Vote: "EAPIs 0 and 3 are banned. This ban includes both new ebuilds and updating the EAPI in existing ebuilds. Only exception is minor patching by the security team"
20:55:58 blueness: *yes to the change*
20:56:03 jlec: result: all yes
20:56:09 jlec: nice
20:56:14 jlec: second
20:56:38 jlec: Amending the EAPI 1/2 ban
20:57:07 ulm: I'd suggest the following wording
20:57:10 ulm: "The exception that was added in the 2014-03-11 meeting for EAPI 1 will be dropped."
20:57:30 ulm: (that exception was: "In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround.")
20:57:43 jlec: lgtm
20:58:05 rich0: wfm
20:58:09 WilliamH: wfm
20:58:14 dilfridge: good wfm
20:58:20 K_F: wfm
20:58:23 jlec: Vote: "The exception that was added in the 2014-03-11 meeting for EAPI 1 will be dropped. (that exception was: "In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround.")"
20:58:28 rich0: *yes*
20:58:31 dilfridge: *yes*
20:58:32 jlec: *yes*
20:58:32 ulm: *yes*
20:58:33 K_F: *aye*
20:58:40 blueness: *yes*
20:59:03 jlec: result: all yes
20:59:14 jlec: good
20:59:17 jlec: next: Open bugs with council involvement


20:59:34 WilliamH: *yes to last*
20:59:58 jlec: oh. missed you
21:00:11 jlec: Missing log and summary for 20151025 council meeting
21:00:15 jlec: https://bugs.gentoo.org/show_bug.cgi?id=571490
21:00:51 jlec: dilfridge: ^^
21:00:58 ulm: who was chair?
21:01:03 ulm: ah
21:01:07 dilfridge: err
21:01:13 dilfridge: yes, ok, will dig it out
21:01:24 jlec: perfect thanks
blueness left the room (quit: Quit: blueness). (21:01:31)
21:01:32 K_F: you really got the short straw with that extended meeting 
21:01:38 jlec: https://bugs.gentoo.org/show_bug.cgi?id=569914
21:01:50 jlec: dilfridge as well 
21:02:08 dilfridge: at least there we have the log already.
21:02:28 jlec: https://bugs.gentoo.org/show_bug.cgi?id=503382 Meeting log from 20140225


21:02:30 dilfridge: sorry not much time recently, some things got forgotten
21:02:49 ulm: summary is here: https://projects.gentoo.org/council/meeting-logs/20140225-summary.txt
21:02:58 ulm: do we need to approve it?
21:03:16 jlec: why?
21:03:17 K_F: ulm: missing OpenPGP signature
21:03:32 ulm: K_F: what?
21:03:45 K_F: the summary is missing OpenPGP signature
21:03:49 dilfridge: that was never done in the past, only I did it recently
21:04:00 ulm: K_F: that's optional I think
21:04:07 K_F: hmm, ok, guess we have the git recording of it..
21:04:17 K_F: with sig..
21:04:32 K_F: but since it is offical record, I would recommend people to sign it
21:05:14 ulm: yeah, we can do that in the future
21:05:49 jlec: So is the bug fixed with this or do we need to do some thing?
21:05:58 K_F: looks resolved to me
21:06:19 K_F: thanks ulm
21:06:20 jlec: ulm: do you handle the rest in the bug?
21:06:37 ulm: jlec: yeah, I just closed it
21:06:41 ulm: finally 
21:06:55 jlec: ulm: thanks a bunch for doing the work
21:07:00 jlec: last bug
21:07:11 jlec: Update NEWS items to EAPI=5 
21:07:12 jlec: https://bugs.gentoo.org/show_bug.cgi?id=568068
21:07:28 jlec: The GLAP 42 test change is  https://bugs.gentoo.org/attachment.cgi?id=419948&action=diff
21:09:01 K_F: lgtm
21:09:07 blueness: testtest
21:09:08 blueness: sorry disconnected
21:09:10 blueness: 
21:09:23 jlec: Vote: "The council approves the changes of GLEP 42 for NEWS item format 1.1"
21:09:27 jlec: stop
21:10:03 jlec: Vote: "The council approves the changes [1] of GLEP 42 for NEWS item format 1.1. (1. https://bugs.gentoo.org/attachment.cgi?id=419948&action=diff)
21:10:15 blueness: jlec: i’m confused what does 1.1 bring ing
21:10:25 K_F: blueness: EAPI 5 atom specification
21:10:31 K_F: 1.0 use EAPI 0
21:11:20 blueness: oh okay
21:11:21 K_F: oh, and stopping to use the word "atom", but package dependency specification
21:11:23 blueness: got it
21:11:23 rich0: This didn't really go on the agenda on the lists, perhaps it should be discussed first?
21:12:09 K_F: the contra is it was brought up during open floor last meeting and deferred to this, and is a smaller change
21:12:21 K_F: I personally don't have a need to discuss it any more, but..
21:12:23 jlec: rich0: we discussed it here and during the news item which triggered this idea
21:12:45 jlec: I don't see any further discussion either
21:12:51 rich0: Sure, but was it announced on-list?
21:13:09 jlec: not really
21:13:11 rich0: a bug submitted to council and open floor doesn't really get many eyeballs.
21:13:16 ulm: I had the impression that there were no objections against the change in mailing list discussions
21:13:26 rich0: Was there a mailing list discussion?
21:13:31 rich0: That was really my question.
21:13:36 jlec: let me look it up
21:13:47 ulm: was discussed with one of the last news items
21:13:56 rich0: I have no reason to object, as long as it has gotten at least decent publicity.
21:14:34 K_F: its the python ABIFLAGS discussion
21:14:40 jlec: no real discussion
21:14:49 jlec: nobody had anything to add
21:15:19 K_F: 0.10.23-r3
21:15:23 K_F: https://archives.gentoo.org/gentoo-dev/message/6904e810caedf66d889458e6fd1cc552
21:15:28 jlec: thanks
21:15:30 K_F: starting there
21:16:26 K_F: https://archives.gentoo.org/gentoo-dev/message/200db7b2e8c1290aaed1723ee618086e is the update recommendation
21:16:26 jlec: rich0: is this enough?
21:17:15 ulm: also it's not such a world-shaking change 
21:17:27 rich0: I don't object, though really this sort of thing should go on the agenda, not just as a bug.
21:17:50 jlec: We can delay the vote to next meeting.
21:17:56 K_F: I principally agree, although this is minor one that has been brought up before at least
21:18:13 jlec: So let's vote
21:18:24 jlec: and be more careful next time
21:18:25 ulm: do we really need to be so bureaucratic for a minor change?
21:18:28 jlec: *is still learning*
21:18:43 jlec: Vote: "The council approves the changes [1] of GLEP 42 for NEWS item format 1.1. (1. https://bugs.gentoo.org/attachment.cgi?id=419948&action=diff)
21:18:50 K_F: *aye*
21:18:52 dilfridge: *yes*
21:18:53 blueness: *yes*
21:18:56 jlec: *yes*
21:18:57 ulm: *yes*
21:18:59 WilliamH: *yes*
21:19:03 rich0: *yes*
21:19:12 jlec: passed all yes
21:19:15 jlec: thanks
21:19:25 rich0: ulm: well, the whole point is that many eyes make bugs shallow, and just transparency in general.  I mean, this is a glep...
21:19:37 rich0: If it were THAT minor we wouldn't be voting on it.  
21:19:48 jlec: 4. Open floor
21:20:01 K_F: FOSDEM is comming up
21:20:06 blueness: yep
21:20:19 K_F: thank you for your work with regards to live media dilfridge
21:20:31 dilfridge: I have one quote already,
21:20:40 K_F: for those not in #-fosdem: there is an updated media if you want to test it
21:20:41 dilfridge: sent another e-mail to 5 relevant companies
21:20:51 K_F: http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso
21:20:56 dilfridge: http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso  << please test!
21:20:56 dilfridge: http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso.CONTENTS
21:20:56 dilfridge: http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso.DIGESTS
21:21:34 K_F: we have a funding request for it at https://bugs.gentoo.org/show_bug.cgi?id=569940
21:21:37 blueness: i’ve got to run guys, jlec are we done?
21:21:44 jlec: blueness: yes
21:21:46 dilfridge: likewhoa says it's coming along fine, plan is to send it to printing/burning real soon now
21:22:24 K_F: also we're getting banner and sticker up from berlin, likely by DHL (some 20-30 EUR ..)
21:22:25 dilfridge: I still need to pick up the list of packages/versions from likewhoa, would make a nice poster
21:22:55 dilfridge: (it's true bleeding edge kde 5 (as far as something like that exists))
21:23:12 K_F: I'm really looking forwards to FOSDEM 
21:23:36 rich0: One of these decades I'll make it out to one of those.  
21:23:44 jlec: I sadly cannot come this year
21:25:14 mrueg: btw. there's a list now: https://wiki.gentoo.org/wiki/FOSDEM_2016 feel free to add yourself
21:25:27 mrueg: *just copied the 2015 wiki page*
21:25:34 K_F: mrueg: nice, thanks
21:25:45 K_F: we also need to figure out how to do the stand schedule
21:25:57 K_F: might work with wiki page for that as well, we need 2 people there all time
21:26:06 K_F: but we'll take that discussion to #-fosdem
21:26:26 K_F: also we're participating at SCALE, but I'm not familiar with the details there
21:26:43 jlec: Nothing official to decide on?
21:26:49 K_F: no
21:26:53 K_F: just a nice to know kind of thing
21:26:53 jlec: I would close the meeting otherwise
21:27:02 K_F: anything else for open floor?
21:27:49 jlec: looks not
21:27:54 jlec: *bangs the gavel *
21:28:00 dilfridge: ++
21:28:02 dilfridge: thanks!
21:28:41 rich0: adios, jlec thanks for chairing!  {