Fix filenames.

1 files changed, 437 insertions, 0 deletions

diff --git a/meeting-logs/20160110.txt b/meeting-logs/20160110.txt
new file mode 100644
index 0000000..6d4ebd6
--- /dev/null
+++ b/meeting-logs/20160110.txt
@@ -0,0 +1,437 @@
+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!  {