path: root/meeting-logs/20130813.txt

<ulm> 19:00 UTC, so let's start
<dilfridge> w00t
<blueness> k
<ulm> Agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2937
<ulm> dilfridge?
<dilfridge> yes?                                                        [21:01]
<ulm> why w00t?
<dilfridge> just like that
<dilfridge> :)
* blueness here
<ulm> roll call
* dilfridge here
* WilliamH here
<dberkholz> here                                                        [21:02]
<rich0> here
<ulm> scarabeus?
<scarabeus> her
<scarabeus> e
<ulm> I've one additional bug for agenda topic 4                        [21:03]
<ulm> bug 480408
<willikins> ulm: https://bugs.gentoo.org/480408 "Autobuilds go to
            /experimental and to /releases only when actually tested"; Gentoo
            Linux, Unspecified; CONF; mattst88:council
<dilfridge> k
<ulm> everyone o.k. if we add it?
<dilfridge> sure
<rich0> sure
<scarabeus> not a prob
<blueness> okay, but i'm not sure why that came to the council
* WilliamH thinks that should be a releng decision?                     [21:04]
<ulm> blueness: let's discuss this later ;)
<blueness> k
<ulm> topic 2, support for separate /usr partition
<ulm> WilliamH: your stage
<WilliamH> Here's the thing folks. The council's vote in 2012 was ambiguous.
                                                                        [21:05]
<WilliamH> The summary said one thing,
<WilliamH> but looking at the log, the intention was completely different.
<WilliamH> and, imo, the intention,  mandating support for separate /usr
           without a preboot mechanism, is a maintenance nightmare.
<rich0> WilliamH: sorry to interrupt - but I don't think we need to figure out
        the past intentions so much as define the policy moving forward
                                                                        [21:06]
<WilliamH> As you can see from the blog posts I cited from Flameeyes, what is
           needed in early boot is very difficult to define these days.
<WilliamH> Going forward, I would like for us to require some kind of preboot
           mechanism, e.g. initramfs or the sep-usr use flag on busybox, if
           folks have /usr and / on separate partitions.                [21:07]
<blueness> (let us know when your done with the presentation and can ask
           questions)                                                   [21:08]
<WilliamH> That also eliminates the concern about crossing the / -> /usr
           barrier, since /usr would always be mounted when / is.
<WilliamH> Ok, let's open for discussion.
<rich0> suggest that when we vote we perhaps do it progressively - policy for
        new pkgs, existing ones, etc.                                   [21:09]
<dberkholz> for anyone else who wants to quickly read up on busybox[sep-usr],
            here's a link:
            http://www.gossamer-threads.com/lists/gentoo/dev/252734
<WilliamH> rich0: there's not really a way to separate this into new vs
           existing...
<dberkholz> basically it's an init wrapper that mounts /usr etc then hands off
            to real init
<rich0> My feeling is that long-term we want to stop supporting separate /usr
        without an early-boot mechanism to mount it.  How we get there I think
        is open for debate.
<WilliamH> rich0: as soon as one package changes, everyone will be hit.
<dilfridge> there is another aspect of this, as far as I understand it, with
            the current systemd installation in Gentoo, having a separate /usr
            without early boot mechanism is impossible                  [21:10]
<WilliamH> rich0: most of tthe changes will be for base-system packages.
<rich0> For packages that are recent like systemd or such, I think we can just
        stick them in /usr and not worry about them.
<ulm> I had tried to summarise a bit and also suggested some successive votes
      here: http://article.gmane.org/gmane.linux.gentoo.project/2941
<blueness> rich0, i read the FHS 3.4 standards yesterday, and while there is
           no mention of early boot mechanism it is clear that a system must
           be able to boot off of just / without /usr
<rich0> For stuff that exists the question is when to de-support separate usr,
        assuming we're Ok with that general direction.
<WilliamH> rich0: that's a separate issue, sticking whole packages in /usr
           isn't what I'm talking about.
<rich0> blueness: I agree 100% that what I'm proposing is not FHS compliant.
                                                                        [21:11]
<blueness> there exist configuratons eg nfs mounts of /usr where mounting /
           and /usr at the same time are not possible
<rich0> Basically the question is whether we care.
<dilfridge> blueness: that's true... unfortunately here reality seems to have
            ignored FHS
<WilliamH> blueness: no it isn't.
<blueness> rich0, okay so what do we do about such systems?  i ran an entire
           lab like that till recently
<dberkholz> i don't think it should be our job to expend *significant* effort
            reworking build systems and such to follow fhs. only if it's
            relatively easy via configure flags, for example
<WilliamH> blueness: remember that in the latest standards, anything in / can
           be symlinks.
<blueness> and chainsaw runs a farm of similar servers
<ulm> blueness: same here
<rich0> Re NFS - why can't an initramfs mount both root and /usr?       [21:12]
<blueness> so i'm okay as long as we have solutions in place
<blueness> for such systems
<ulm> dberkholz: but we also shouldn't remove support where it currently
      exists
<blueness> rich0, no the / would boot first and hten nfs mount /usr
<blueness> ulm, agreed
<blueness> we should not remove support where it already exists
<ulm> e.g., I wouldn't remove gen_usr_ldscript from util-linux          [21:13]
<dberkholz> ulm: sure. i don't see that as controversial, to follow fhs
            wherever reasonable
<blueness> there is a similar problme with pxeboots
<rich0> blueness: the question isn't how it worked, but how it could work.
        Any reason an initramfs would not be possible, or a script that runs
        early from inittab?
<WilliamH> ulm: the /usr merge (separate subject) is fhs compliant.
<ulm> WilliamH: how that?
<blueness> rich0, okay if we can design an initramfs which can handle that
           then i'm okay
<WilliamH> Let's not get into the /usr merge here though, I was just siting it
           as an example.
<rich0> blueness: I'd think that dracut would work, but I'd have to see.
                                                                        [21:14]
<blueness> WilliamH, but people are worried about a slipper slope here
<ulm> WilliamH: well, it's the big question for the long term
<dilfridge> dracut is a documentation mess
<WilliamH> ulm: because newer fhs says that /{bin,sbin,lib*} can be symlinks
<rich0> Anybody doing PXE+nfs should know what they're doing in any case.
        Hardly a handbook install (I run one myself, but not with separate
        usr)
<dberkholz> someone wrote up a really small initramfs to do this (robbat2?),
            last time the discussion came up.
<ulm> WilliamH: pointer?
<dilfridge> we really badly need some *official installation documentation* on
            how to set up a system with an initrd                       [21:15]
<rich0> dilfridge: no argument there
<WilliamH> The thing about initramfs is that you can use the tools, or you can
           roll your own quite easily.
<blueness> okay so my position in a nutshell: okay to early boot mechanism
           with / and /usr separate provide we have working initramfs's (via
           genkernel say) for already existing setups
<rich0> I think we need to distinguish between where we are going and how we
        get there.
<blueness> +1 dilfridge,  we really badly need some *official installation
           documentation* on how to set up a system with an initrd
<rich0> If we're not ready to make the jump now, then we don't need to jump.
        However, a declaration of long-term intent will allow everybody to
        start migrating.
<blueness> rich0, yeah that might work too, so people start to work towards
           athat as a team                                              [21:16]
<blueness> but like ulm said -> <ulm> e.g., I wouldn't remove gen_usr_ldscript
           from util-linux
<WilliamH> rich0: this is the jump -- separate /usr with or without an
           initramfs... That is the most disruptive part of going forward
           whether we do the /usr merge or not.
<rich0> blueness: yup - right now everybody is playing tug of war.  Better to
        have them focusing on offering various solutions, docs, handbooks,
        whatever rather than fighting over whether it will happen.
<WilliamH> rich0: from what i see about it.
<blueness> it would be a disaster if one day people wok up and
           gen_usr_ldscript were dropped from util-linux
<WilliamH> blueness: only if they were not warned.                      [21:17]
<dilfridge> let me make another point (or repeat it) - systemd, separate usr &
            no initrd etc right now does already not work
<blueness> WilliamH, or if they were warned and didn't ahve a solution
<rich0> blueness, WilliamH: I think that might be the end result, but
        docs/handbook/etc maybe need to evolve to get there
<dilfridge> since (with the upcoming gnome) people will be moving to systemd,
            that makes these questions a bit more urgent
<WilliamH> blueness: my thought about gen_usr_ldscript is to first make it so
           you can turn it off in make.conf for testing.                [21:18]
<blueness> WilliamH, i still need a solution for currently supported
           configuratons
<rich0> dilfridge: good point.  One thing we could state is that
        non-legacy-packages can be /usr-dependent right away.
<rich0> I think the big concern is over openrc/sysvinit/udev and so on
<rich0> Anybody running systemd already is past this issue.
<blueness> rich0, correct                                               [21:19]
<ulm> rich0: right
<rich0> So let them just move on
<WilliamH> blueness: if we turn it off, everywhere, the solution would be to
           rebuild all affected packages, then before you reboot switch to an
           initramfs.
<WilliamH> or sep-usr busybox
<blueness> WilliamH, okay then we need to doc what needs to be done before the
           switch is thrown
<WilliamH> blueness: there would be a list out there of the packages.
<blueness> because today we'll have it on a use flag
<ulm> last time I checked, sep-usr busybox was fundamentally broken
<blueness> but tomorrow we'll want to drop the support
<ulm> as it didn't fsck /usr
<rich0> WilliamH: I'd set up the initramfs first before rebuilding half your
        system to depend on it.  The whole point of an initramfs is that it is
        smart enough to figure out how to boot your system either way.
<ulm> has that changed?                                                 [21:20]
<WilliamH> rich0: yes, that's true too, you could do it either way.
<blueness> ulm, i haven't check about sep-user busybox, but that it would
           surprise me
<blueness> you can build busybox without /usr
<blueness> everying in /bin and /sbin
<rich0> Honestly, I'm all for choice but I don't really get the initramfs
        hate.  I don't think it really matters though - we should document
        whatever practical choices exist and leave it to the user.
<WilliamH> sep-usr busybox is not fancy at all. its purpose is to just mount
           /usr then move on.
<ulm> blueness: yeah, but it mounts /usr
<WilliamH> if you want more that is when you need an initramfs.
<rich0> If you can install grub you can build an initramfs...           [21:21]
<dilfridge> rich0: I dont like it either, but that is mainly because of
            missing documentation
<WilliamH> dilfridge: http://www.gentoo.org/doc/en/initramfs-guide.xml
<rich0> dilfridge: yup - docs are definitely weak on the initramfs front.
        Maybe an area to focus on.
<blueness> rich0, the only argument against initramfs is just a cleaner boot,
           which might be an issue say on embedded systems
<dilfridge> rich0: and when I started with Linux, everyone recommended to use
            a separate /usr , always, everywhere
<dberkholz> like this? https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
            http://www.gentoo.org/doc/en/initramfs-guide.xml
<WilliamH> docs have been out there for a long time.                    [21:22]
<dilfridge> looks good
<ulm> trying to keep this somewhat focused, should we take any decisions
      today?                                                            [21:23]
<rich0> So how about we propose that non-legacy pacakges (ie stuff that wasn't
        stable a year ago) don't have to support a separate /usr without an
        early boot mechanism.  For legacy packages our intent is to not
        require this support and do the transition over the next six months,
        with communications/docs/etc in place before we make the change.
<blueness> FYI, initramfs images can be embedded into a kernel image for one
           compact file --- this might be an issue in some pxe situations
<rich0> To whatever extent they already exist it is just a communications
        problem.
<blueness> rich0, it might be more than just communication though       [21:24]
<rich0> At the very least the handbook needs pointers and such
<blueness> it maybe technically difficult in certain exotic boot situations
<rich0> blueness: "To whatever extent they already exist..."
<blueness> yeah
<WilliamH> rich0: the handbook recommends not mounting with separate /usr.
<WilliamH> s/mounting/partitioning/
<ulm> rich0: thist implies that we express our intention to do the /usr merge?
                                                                        [21:25]
<WilliamH> The examples do not show doing that.
<ulm> *this
<rich0> WilliamH: might want to update this:
        http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
<WilliamH> ulm: not necessarily.
<rich0> Example there is a separate /usr
<WilliamH> That could be done in less than 6 months.
<rich0> (and the doc I followed umpteen years ago)                      [21:26]
<ulm> well, we should go for consistency
<rich0> WilliamH: Just suggest that it be sometime in the next six months -
        not a hard time limit.  We go when we're ready.
<ulm> so either FHS compliance
<dilfridge> so, let's say we make a statement of intent now (no sep-usr
            support required in half a year), strive to consolidate the
            documentation on initramfs etc, revisit in 2 months to see the
            status
<ulm> or /usr merge
<WilliamH> ulm: /usr merge is fhs compliant though.
<ulm> WilliamH: it isn't
<ulm> no way
<WilliamH> ulm: they aren't mutually exclusive.
<WilliamH> ulm: wait a sec                                              [21:27]
<ulm> "The contents of the root filesystem must be adequate to boot, restore,
      recover, and/or repair the system."
* WilliamH is getting the link
<rich0> ulm: I think we really need to think about doing the /usr merge, but I
        don't see that has having to be a dependency.  Somebody has to be
        willing to take that on.
<blueness> what do you mean by merge here -> <WilliamH> ulm: /usr merge is fhs
           compliant though.
<blueness> a sym link / -> /usr
<blueness> ?
<dilfridge> that would be funny
<ulm> blueness: moving everything from /bin /sbin /lib* to /usr         [21:28]
<dberkholz> i think going for consistency wherever feasible is different from
            requiring 100% consistency. the former is reasonable given the
            current state of reality, the latter is not.
<WilliamH> the /usr merg has symlinks in / for bin, sbin, lib* that go to
           their counerparts in  /usr
<blueness> ulm, that would be very bad
<blueness> we have to try to be faithful to this ->  "The contents of the root
           filesystem must be adequate to boot, restore, recover, and/or
           repair the system."
<blueness> as best we can
<blueness> eg
<blueness> suppose /usr is corrupt and needs repair                     [21:29]
<rich0> blueness: I think the issue is that upstream has basically abandoned
        that entirely.
<blueness> can we get / up and fsck from it?
<rich0> At least for upstream=systemd/udev
<blueness> rich0, which upstream?
<ulm> blueness: yeah, the question is exactly if we would give that up
<dberkholz> then you're screwed because you won't be able to boot anyway,
            unless you boot to busybox.
<WilliamH> ulm hang on I'm getting the fhs link for you to show what I was
           talking about.
<blueness> ulm, we cannot give that up
<rich0> That is what is driving this.
<WilliamH> ulm: http://www.linuxbase.org/betaspecs/fhs/fhs.html         [21:30]
<rich0> root is not sufficient as it stands if you're using something like a
        bluetooth keyboard, and the sense is that it will only get worse
<dilfridge> blueness: that exactly is the problem, on one hand people with
            dated server installations swear that / needs to be
            self-sufficient
<ulm> WilliamH: yes, and that says what I've quoted earlier
<dilfridge> blueness: on the other hand recent software sets do not really
            follow the constrictions for that anymore
<blueness> dilfridge, i'm one of them and there are lots of others, it would
           be bad
<dilfridge> blueness: meaning things break during upgrades without you
            noticing                                                    [21:31]
<blueness> yeah i know, we need to prevent that in so far as it is possible
<blueness> i'm okay with the initramfs solution but not with the merge
<rich0> I think we need to leave the merge aside for now.
<rich0> I think that is really a separate issue.                        [21:32]
<ulm> rich0: yes
<blueness> okay merge aside, let me get this clear
<rich0> There is a difference between allowing dependencies in /usr, and
        moving everything to /usr en masse.
<WilliamH> blueness:
           http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
<blueness> suppose / is fine and /usr is need of repair, would we be albe to
           affect the repairs using the proposed initramfs solution?
*** reavertm (~reavertm@gentoo/developer/reavertm) has joined channel
    #gentoo-council                                                     [21:33]
<ulm> blueness: you need your repair utils in the initramfs
<blueness> WilliamH, i've read it, and i think those guys need to seriously
           rethink their position
<rich0> blueness: greatly depends on the nature of the problem.  most
        initramfs will do basic fsck/etc automatically
<dberkholz> blueness: good luck on that one.
<ulm> blueness: busybox provides some of them
<rich0> most will also drop you to a shell, but what is available varies and
        is usually very limited
<blueness> ulm, that work, if the initramfs takes the place of /
<blueness> with documentation etc etc
<rich0> I think docs are a sticking point here.
<blueness> people who run servers need to have a repair path, if that's via
           initramfs tools  i'm oaky with that                          [21:34]
<rich0> hence I suggest we agree on intent, but allow some time for doc
        updates and revisit
<rich0> Honestly, if your /usr is really hosed the stuff in / isn't going to
        be sufficient.  You really need a rescue CD for serious work.
<WilliamH> blueness: that would be the repair path, yes.
<rich0> Much of the stuff in / is going to be in an initramfs.  Most initramfs
        allow arbitrary files to be bundled as well.
<blueness> rich0, i think ulm's idea of repair in intramfs is great
<WilliamH> The usr merge is a red herring that doesn't affect this vote
           really.
<blueness> that might be the point that will satisfy people             [21:35]
<blueness> like making the initramfs the new /
<dilfridge> I dont have much experience, but I *think* having fs repair
            utilities and basic network stuff (e.g. dhcpcd) in an initrd
            shoudl be possible
<WilliamH> blueness: you can very easily make your own initramfs too. That is
           a little bit more advanced but that level of customization is
           possible.
<blueness> in general
<rich0> Might not hurt to put that in the docs too - how to repair from an
        initramfs, or ensure your initramfs is configured to enable it
        (sometimes dropping to a shell is a config item for security - it is a
        root shell)
<blueness> WilliamH, i know :)
<blueness> i spend my time building firmware images                     [21:36]
<blueness> rich0, yeah if we can show how all FHS concerns are met in a
           slightly different way, then we have a very good middle path
<blueness> i can agree to the intent
<dberkholz> so my understanding now is, we will support separate /usr as long
            as people are using a mechanism to ensure it's mounted early.
            current methods include initramfs or busybox[sep-usr].
                                                                        [21:37]
<rich0> Is there anybody who has issues then with the long-term move, but
        before we do it we need to agree all docs/etc are in a row?
<ulm> so shall we do actual voting today, or go back to ML discussion? if we
      vote, I suggest that we do it in steps, as suggested by rich0
<dilfridge> ulm: vote today, but in steps                               [21:38]
<ulm> who wants to vote now?
<WilliamH> ml discussion is going to be a never-ending bikeshed I think.
<rich0> I suggest we at least vote on something around intent
<blueness> we can vote to the intent and get feedback on the mechanism
<blueness> the community make bring up tech issues we ahve not thought of
<WilliamH> If we are going to vote on intent, what does that mean in terms of
           base-system and toolchain working on legasy issues... like
           gen_usr_ldscript...                                          [21:39]
<ulm> WilliamH: I'd rather avoid micro-management
<WilliamH> ulm: ok, that's fine with me.
<rich0> Suggest we also vote that stuff that wasn't stable a year ago (eg
        systemd) can depend on /usr now.
<WilliamH> I would rather avoid micro-management as well.
<dilfridge> ok here's a suggestion for a vote:
<blueness> yeah me neither, because people will figure out what to do just
           knowing the goal                                             [21:40]
<WilliamH> One thing I think needs to be in the statement of intent is
<dilfridge> 1 "Since that particular setup may already be subtly broken today
            depending on the installed software, Council strongly suggests to
            use an early boot mount mechanism, e.g. initramfs, if /usr is on a
            separate partition."                                        [21:41]
<ulm> strike "strongly"
<WilliamH> dilfridge: go ahead...
<WilliamH> ulm: no
<dberkholz> s/strongly suggests to use/recommends using/
<ulm> dberkholz: +1
<blueness> dberkholz, yep
<WilliamH> dberkholz: ok
<dilfridge> ok
<blueness> strongly is overkill                                         [21:42]
<rich0> ++ - in general I've learned at work that any word ending in ly
        probably isn't necessary.  LIke the probably in my last sentece.
<dilfridge> 1a "Since that particular setup may already be subtly broken today
            depending on the installed software, Council recommends using an
            early boot mount mechanism, e.g. initramfs, if /usr is on a
            separate partition."
<rich0> seems good so far
<ulm> o.k., please vote on 1(a) as suggested                            [21:43]
<dilfridge> 1b "Since that particular setup may already be subtly broken today
            depending on the installed software, Council recommends using an
            early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
            is on a separate partition."
<dilfridge> sorry
<dilfridge> 1b please
<dilfridge> clearer
<dilfridge> (added "to mount /usr")
* WilliamH votes yes
* dilfridge yes
* scarabeus goes for yes
* blueness yes
<rich0> yes
* ulm yes on 1b
<WilliamH> Now there is one more thing.                                 [21:44]
<rich0> WilliamH: a few more things actually
<rich0> That's just part 1
<dberkholz> sure. although i'd go with "the council" vs "Council" as a proper
            noun
<WilliamH> If we start changing software based on that recommendation and bugs
           are opened wanting us to change it back...
<ulm> dberkholz: your vote?
<WilliamH> as I"m sure there will be...
<rich0> WilliamH: we haven't gotten that far
<dilfridge> dberkholz: is that yes?
<dberkholz> sure == yes                                                 [21:45]
<ulm> k
<rich0> 1b just is a recommenation to users, not green light to maintainers
<ulm> unanimous
<blueness> rich0, right thanks for that clarification
<ulm> dilfridge: any further suggestion for a vote?
<dilfridge> well
<rich0> 2a - "Over the next few months the intent is to not require
        maintainers to support a separate /usr without an early boot
        mechanism, once the Council agrees that the necessary docs/migration
        path is in place.                                               [21:46]
<dilfridge> something like that would be the next question, indeed
<mattst88_> what happened to scarabeus? doesn't seem to have said anything
            since 19:03 UTC.
<scarabeus> why council, when the docs are in place can be checked by anyone
<mattst88_> ah :)
<WilliamH> Yes, the docs are already there.
<scarabeus> mattst88_: i voted, i just don't do much about the /usr :;-)
                                                                        [21:47]
<ulm> rich0: shouldn't we ask the inverted question?
<dilfridge> ulm: means what?
<ulm> i.e. maintainers are required to still support separate /usr for
      existing packages                                                 [21:48]
* WilliamH would vote no for that.
<ulm> (ones that are stable for at least one year)
<WilliamH> That's getting into micro-management.
<rich0> 2b - Once the Council agrees the necessary docs/migration path is in
        place maintainers will not be required to support booting with a
        separate /usr without an early boot mechanism (eg initramfs).
<ulm> until we revisit the issue
<blueness> rich0, can i suggest: 2a - "The intention is to eventually not
           require maintainers to support a separate /usr without an early
           boot mechanism once the Council agress that the necessary
           docs/migration path is in place."
<WilliamH> What is there to revisit?
<ulm> WilliamH: documentation mainly
<rich0> I'm fine with blueness's wording as well
<dilfridge> blueness: new wording -> new number please, otherwise things get
            confused                                                    [21:49]
<blueness> dilfridge, okay sorry
<dilfridge> s/number/letter/
<rich0> I don't think we'll get agreement that docs are in place now in the
        next 10 min
<blueness> 2c - "The intention is to eventually not require maintainers to
           support a separate /usr without an early boot mechanism once the
           Council agress that the necessary docs/migration path is in place."
<WilliamH> What docs can we even agree on? there are many ways to build an
           initramfs...
<rich0> unless we force a divided vote - and I'm not certain that is a great
        idea.  In any case, we need communications/etc to users before doing
        anything.
<ulm> any further changes to 2c wording?                                [21:50]
<WilliamH> There were docs sited in the meeting earlier...
<rich0> Suggest we vote on 2c
<dilfridge> yes vote on 2c
<ulm> please vote on 2c then
* blueness yes on 2c
<rich0> WilliamH: agree docs were cited, not sure they're sufficient.
<scarabeus> i would actually say that council should not need to agree on when
            to start migrate, we don't dicate when to put new stuff or remove
            old one; we can leave that to openrc/systemd guys when they are
            sattisfied
* rich0 yes on 2c
<WilliamH> paste 2c again?
<blueness> 2c - "The intention is to eventually not require maintainers to
           support a separate /usr without an early boot mechanism once the
           Council agress that the necessary docs/migration path is in place."
<rich0> scarabeus: only suggest council reviews due to the extreme sensitivity
        of the issue                                                    [21:51]
<dberkholz> s/agress/agrees
<rich0> normally I'd agree with you on that.
<ulm> dberkholz: already noted
* WilliamH votes yes
<scarabeus> its base system, the same applies for genkernel or kernel guys,
            who started to change genpatches to huge stuff
* ulm abstains on 2c
<WilliamH> I would like to say something though.                        [21:52]
* dilfridge abstains on 2c
<WilliamH> wait, I withdraw my vote
* WilliamH abstains
<ulm> dberkholz: scarabeus: ?
<WilliamH> The problem is that is too subjective.
<WilliamH> That's why I abstain
<rich0> Nothing subjective about it.  When the council votes, it votes.
                                                                        [21:53]
<scarabeus> nope from me for this, unless the docs are exactly listed (you can
            easily say its fine or otherwise)
<rich0> Intent is to end debate over direction and direct efforts to how we
        get there.
<ulm> WilliamH: it's a design decision, it will always be subjective
<dberkholz> i vote yes
<WilliamH> Which docs are we talking about though?
<ulm> I cound 3 yes, 1 no, 3 abstains
<blueness> i don't think we should overly define this actually that could be
           worse
<rich0> WilliamH: suggest we take the docs discussion to the lists/etc.
<ulm> *count
<WilliamH> the dracut docs, the genkernel docs, a how to roll your own doc?
<ulm> motion passed                                                     [21:54]
<rich0> WilliamH: whatever docs gives the council the warm fuzzies.  :)  I
        intend to pitch in though.
<blueness> WilliamH, you can always bring that up when we discuss the docs,
           right now its just to have the goal stated ... and 2c does that
<WilliamH> ok
* WilliamH votes yes then change my vote
<dberkholz> the key docs thing will be the handbook, mainly checking to make
            sure
            http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=7
            has everything we need.
<rich0> Suggest voting on 3a - "Packages not stable 1 year ago need not
        support a separate /usr without an early boot mechanism immediately."
<ulm> 4 yes, 1 no, 2 abstains
<ulm> rich0: what about package splits?                                 [21:55]
<dilfridge> strike "immediately"
<ulm> like netifrc
<WilliamH> ulm: irrelivent to this
<WilliamH> netifrc doesn't care about initramfs
<ulm> WilliamH: just an example ;)
<WilliamH> ;-)
<dilfridge> I guess there common sense applies... if part of something was
            stable a year ago, it counts as stable a year ago
<dberkholz> that double negative is killing me                          [21:56]
<rich0> 3b - Packages that were not stable on Aug 1st 2013 do not need to
        support a separate /usr.  No further council vote is needed for these
        packages."
<rich0> s/2013/2012
<blueness> rich0, i'm confused with respect to the intent/issue this is
           addressing
<scarabeus> Packages that did not have stable versions
<scarabeus> somebody could for sure get there "this version was not stable" :D
                                                                        [21:57]
<rich0> blueness: intent is that systemd/etc which already do not support a
        separate /usr can stay as they are
<rich0> Maybe just drop that issue entirely.
<rich0> Clearly we're not going to migrate that stuff to / only to migrate it
        back.
* WilliamH thinks this is getting into micromanagement.
<dilfridge> rich0: yes
<dberkholz> i would reword it
<dilfridge> but we should be wary that people interpret 2c as "it is required
            now"                                                        [21:58]
<ulm> we're over time already, I suggest we conclude the issue at this point
<ulm> continue next month if there's need for it
<rich0> ulm: I'm fine with that.
<blueness> ulm, i'm okay with ending now, let's just leave the two points
<blueness> that'll be enough
<dilfridge> ok, at least we have a nice policy statement
<dberkholz> more like 3c "Packages with any stable version on 1 Aug 2012
            should support a separate /usr if feasible."
* blueness puts on his fire proof vest
<dilfridge> dberkholz: nope                                             [21:59]
<ulm> topic 3, locale for build logs in bugzilla
<dilfridge> yep
<dilfridge> my baby
<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2926
<dilfridge> actually the discussion on the list was pretty much helpful
<chithead> bug 478382
<willikins> chithead: https://bugs.gentoo.org/478382 "Please set LC_MESSAGES=C
            in make.conf"; Gentoo Hosted Projects, Catalyst; CONF;
            chithanh:catalyst
<dilfridge> I would like to immediately propose a vote                  [22:00]
<dilfridge> but I have a slightly different suggestion
<rich0> dilfridge: ++ - suggest something
<ulm> dilfridge: just a comment from me
<ulm> https://wiki.gentoo.org/wiki/Bugzilla_HOWTO#Evaluating_emerge_Errors
      currently suggests LC_ALL=C                                       [22:01]
<ulm> so maybe we have to take care of this, too
<dilfridge> 4: "Make a news item, then add LC_MESSAGES=C to the base profile
            make.defaults"
<dilfridge> (this means anyone can override in make.conf easily, and still it
            goes into effect everywhere now)                            [22:02]
<blueness> this seems pretty straight forward, i see no problems here   [22:03]
<blueness> are we voting?
<ulm> not sure if make.defaults is the right place for it
<dilfridge> ulm: where else?
<ulm> bug reporting guide?
* WilliamH is wondering about forcing the setting too.
<scarabeus> people ignore that                                          [22:04]
<rich0> ulm: the intent is to have it someplace so that it becomes a default
        behavior.  I think it is either a profile or make.globals or the
        default make.conf
<dilfridge> well it's not really forcing it, it is just setting a sane default
<WilliamH> If I got a bug with logs in a language I couldn't read I would
           probably just close the bug as needinfo and explain that I couldn't
           read the logs.
<rich0> the profile is the simplest option I think
<dilfridge> if people insist to have russian gcc error messages, well, ...
<scarabeus> i read german and russian so i don't have to care, but i have half
            half bugs; localized/english
<scarabeus> and most will ignore you for the request to compile ie libreoffice
            for next 16 hours again... :-)                              [22:05]
<dilfridge> ulm: the intent is that the default will make your logs "bugzilla
            capable", and you need to actively do something to get away from
            that
<rich0> Oh, and I would also be willing to propose that maintainers are free
        to close bugs with non-english logs at their discretion.
<TomWij> ulm: That guide (https://gentoo.org/doc/en/bugzilla-howto.xml -->
         https://wiki.gentoo.org/wiki/Bugzilla_HOWTO) already lists LC_ALL=C.
<rich0> But we can still change the defaults
<dilfridge> rich0: that's a different item, we can talk about it afterwards
                                                                        [22:06]
<ulm> TomWij: yeah, that's why I've posted this URL above :p
<dilfridge> LC_ALL causes pain for the python guys
<scarabeus> most people don't even realize they override the locale until it
            is too late, so why not have some default to keep us happy
<chithead> if it is in make.conf, it will become default for all new installs.
           jer (who complained most in the past) was fine with it
<ulm> ok, let's vote on dilfridge's proposal then
<TomWij> dilfridge, ulm: Ah, I see the issue now; just the messages (for build
         logs) makes a lot more sense.                                  [22:07]
<ulm> LC_MESSAGES=C in make.defaults
* dilfridge yes
* rich0 yes
<dberkholz> k
* WilliamH yes
* ulm yes
* blueness yes
<ulm> 6 yes                                                             [22:08]
<ulm> scarabeus?
<scarabeus> yes
<ulm> unanimous
<ulm> docs need to be updated, too
<ulm> but that's self evident, no vote required I guess                 [22:09]
<ulm> next topic
<ulm> topic 4, open bugs with council involvement
<ulm> bug 477030
<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
            council meeting"; Doc Other, Project-specific documentation; CONF;
            ulm:council
<ulm> anyone has talked to betelgeuse?                                  [22:10]
<blueness> i looked for him but i never saw him
<scarabeus> didn't see him, just assign one guy to talk with him on the bug
<scarabeus> it is not something that needs to be fixed with upmost importance
<ulm> scarabeus: you've just volunteered? ;)
<ulm> and since we're at it                                             [22:11]
<scarabeus> fancy do i get a beer for it? :-)
<ulm> dilfridge: when do we get the summary for July?
<chithead> regarding topic #3 do note that vapier spoke out against having it
           in make.defaults
           http://archives.gentoo.org/gentoo-dev/msg_0cd6b1f0e0b0c156e51b498362ec96f2.xml
<dberkholz> 10. Customs and Border Patrol knows of any time you have been
            arrested. I had read that the CBP’s background check is highly
            exhaustive, but I got the chance to witness the extent of their
            scrutiny. The applicant who had his appointment before mine began
            the process cordially, but their conversation quickly became
            heated. Apparently, this gentleman had his application denied due
            to an arrest 40 years ago. And according to him, the 
<ulm> scarabeus: when I see you next :)
<dberkholz> 10. Customs and Border Patrol knows of any time you have been
            arrested. I had read that the CBP’s background check is highly
            exhaustive, but I got the chance to witness the extent of their
            scrutiny. The applicant who had his appointment before mine began
            the process cordially, but their conversation quickly became
            heated. Apparently, this gentleman had his application denied due
            to an arrest 40 years ago. And according to him, the        [22:12]
<dberkholz> woops, sorry!
<dberkholz> middle click gone wild.
<blueness> dberkholz, what are you reading!
<dilfridge> hmm
<ulm> chithead: the post says that he's indifferent?                    [22:13]
<dberkholz> i was attempting to copy the link to vapier's thing and apparently
            failed with my two-button mouse
<chithead> ulm: indifferent to having it in make.conf, against having it in
           make.defaults
<dilfridge> ulm: soon
<ulm> ah, right
<rich0> chithead: not sure we want to re-open.  I'm on the fence about that,
        but make.conf doesn't impact existing users at all.
<ulm> that vote is closed for now                                       [22:14]
<blueness> chithead, i wish he'd given a reason
<dilfridge> chithead: dberkholz: if vapier does not bother to explain why,
            then we can't bother to take him serious
<rich0> I'd be fine with actually putting it in both places, to make it easy
        for new users to edit, have a comment to explain why it is set and not
        to submit bugs that are non-english, etc.
<ulm> we can revisit next month if there are good arguments
<rich0> sure
<ulm> next
<ulm> bug 480408
<willikins> ulm: https://bugs.gentoo.org/480408 "Autobuilds go to
            /experimental and to /releases only when actually tested"; Gentoo
            Linux, Unspecified; CONF; mattst88:council
<mattst88_> (I'm here if anyone has questions)                          [22:15]
<blueness> ulm, why is this on the floor?
<mattst88_> I can answer that.
<blueness> shoot
<ulm> should we discuss this today, given that we're way behind schedule?
<blueness> ulm, let's start
<ulm> jmbsvicetto: are you here?
<dilfridge> who cares about schedule...
<mattst88_> I'd be happy to have someone else engage jmbsvicetto on the bug.
*** NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has quit: Quit:
    what, what, what, what, what, what, what, what, what, what.  Only 10 Watts
    Neddy ?  Thats not very bright!!                                    [22:16]
<mattst88_> I've been unsuccessful it seems, and have apparently insulted him.
            :\
<mattst88_> anyway, I thought this proposal was uncontroversial (it received
            only positive comments on gentoo-dev), but jmbsvicetto objects.
<scarabeus> i dont get whats the problem, jorge tries hard, and we could put
            anything automatic there too (if somebody is interested) otherwise
            it is pointless, hand testing is weird                      [22:17]
<mattst88_> and I haven't been able to understand what he disagrees with.
<blueness> mattst88_, i'm on the bug cc, i'm just not sure why he's taken the
           position he has, but i don't feel comfortable bringing it to the
           council before its been discussed with releng lead (who is that?)
<mattst88_> blueness: I don't think we have one.
*** xmw (~michael@gentoo/developer/xmw) has joined channel #gentoo-council
<WilliamH> That is jmbsvicetto  (acting lead)
<mattst88_> the releng page doesn't say that.                           [22:18]
<blueness> mattst88_, i spoke with him briefly about it, but just to thank him
           for his hard work, and he *does* work  very hard
<blueness> i'd like to table this pending my having a discussion with him
<blueness> jmbsvicetto, ^^^^
<ulm> there's obviously a social problem in addition to the technical one, and
      we cannot solve this without further information
<mattst88_> blueness: could we do it in public?
<blueness> mattst88_, are you okay with that
<mattst88_> blueness: if we do it in the bug -- yes.
<rich0> I would like to hear jmbsvicetto explain his position.
<blueness> mattst88_, i'm not against public debate                     [22:19]
<ulm> rich0: yes, we shouldn't take a decision without that
<dberkholz> just a guess, but i'm thinking it may be manual vs automated
            testing
<WilliamH> mattst88_: No, it doesn't, that's what I was told personally
           though...
<rich0> I've run into build issues a few times in the last year.  They have
        been improving, and I'm sure it is hard work.  Would love to see build
        issues addressed, but would like releng's input as far as best way to
        accomplish that.
<WilliamH> but I do find it odd that agaffney is still there.
<dberkholz> if we could come up with an automated test suite, that would be
            probably go over well
<WilliamH> maybe just the page hasn't been updated in a while?
<blueness> mattst88_, he may need help                                  [22:20]
<blueness> testing etc
<dberkholz> we used to do manual testing, fixes, etc and it was incredibly
            effort-intensive
<ulm> so, let's refer this back to bugzilla?
<WilliamH> right.
<mattst88_> fine by me.
<scarabeus> agree                                                       [22:21]
<rich0> Somebody want to volunteer with the inquiry?
<rich0> I don't mind
<ulm> rich0: k
<scarabeus> dberkholz: writting that openqa thing is quest for one afternoon
<rich0> I have some interest in this.
<ulm> topic 5, open floor
<blueness> yeah back to bugzilla, and since i'm part of releng i'll try to
           nudge this foward
<rich0> blueness: I'm fine with you taking the lead on that.            [22:22]
* ulm listening for open floor topics
<dberkholz> scarabeus: does it run on gentoo?                           [22:23]
<scarabeus> dberkholz: i said on the bug
<xmw> does the council favor git migration?
<scarabeus> dberkholz: it does
<blueness> scarabeus, i've never used openqa is that something you can easily
           set up?
<blueness> automate etc
<scarabeus> dberkholz: i did use gentoo at work to run it (without the web
            interface it is lame) that is bit rougher
<ulm> xmw: seriously?
<WilliamH> xmw: it isn't council that is stopping that; it is infra issues.
                                                                        [22:24]
<scarabeus> blueness: you basically say write x write z; enter; and then at
            specific points you say do_screenshot() later in web interface you
            just create "needle" which is part of the screen you compare to
<scarabeus> if it match test passed
<scarabeus> otherwise, problem is in place
<xmw> ulm: so, can you repeat your position, for us to nag infra, please?
<dberkholz> not a huge fan of things that require a web interface, really.
            they tend to fail hard in gentoo
<scarabeus> blueness:
            http://openqa.opensuse.org/results/openSUSE-Factory-GNOME-Live-i686-Build0658-live
                                                                        [22:25]
<scarabeus> blueness: the green squared ones are the tested parts
<scarabeus> (you can test even sounds if you are nuts like opensuse :D)
<ulm> xmw: not sure how the council should accelerate this
<blueness> scarabeus, looks like serious setup though                   [22:26]
<rich0> I'm all for the git migration, and robbat2 actually stepped down from
        trustees to give it more attention
<dberkholz> xmw: we definitely favor it, it's more of a matter of people doing
            the work
<rich0> I intend to help with docs, and xmw if you want to help out we can try
        to work with you.
<xmw> ulm: just eliminate any doubt, aka "there isn't even a clear standpoint
      from/of the council".
<rich0> infra has to do some back-end work though - on stuff that generally
        isn't accessible
<dilfridge> xmw: definitely in favour, but dont really know how to help since
            the rest is "work inside infra stuff"                       [22:27]
<blueness> xmw, yeah totally in favor of a git migration
<blueness> cvs is killing me, its such a resource hog
<TomWij> ulm: Even s/should/could/, because it still depends on people doing
         work and you can't really do much about that (and as pointed out
         robbat2 makes more time free for it); unless you put more people to
         the work, but then again, I doubt if the amount of people is really
         the problem (and it is known that adding people slows things down due
         to lack of knowledge and extra communication).
<ulm> xmw: I'm in favour of course, but as others said, statements of
      intention won't help much
<blueness> i think this has always been about resources                 [22:28]
<blueness> i don't know anyone who is against a git migration
<xmw> thanks for the statement.
<dberkholz> xmw:
            http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt
<dberkholz> "The council also urges individual developers to join the effort
            to move the tree to git.
<dberkholz> "
<xmw> it's hard to get the semi-public infra code, maybe another attempt may
      help.
<ulm> dberkholz: there we go
<ulm> thanks :)
<blueness> dberkholz, i don't see how individual developers outside of infra
           could help here                                              [22:29]
<ulm> I see no further topics brought forward to the council
<rich0> Well, there are other things that can be done in terms of docs/etc.
                                                                        [22:30]
<blueness> who's chair next time?
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: 10 Sep 2010 at 19:00 UTC |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
    http://www.gentoo.org/proj/en/council/"
<ulm> blueness: me again
<scarabeus> blueness: note that the frontend is not technically needed, it is
            just easier to write result comparison that way, but you can do it
            without frontend and just execute the os-autoinst in loop
<dberkholz> blueness: check the tracker, there's opportunities to help:
            https://bugs.gentoo.org/show_bug.cgi?id=333531
<blueness> ulm, okay i have an issue
<ulm> the meeting is closed
<ulm> thank you everybody                                               [22:31]
<WilliamH> ulm: ^^
<mattst88_> does the /topic say 2010, or is my irc client confused?
<dilfridge> ulm: blueness wanted to say something
<ulm> oops
<xmw> thanks. affirmative on the 2010.
<WilliamH> ulm: should we re-open?
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: 10 Sep 2013 at 19:00 UTC |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
    http://www.gentoo.org/proj/en/council/"
<rich0> ulm: thank you!                                                 [22:32]
<TomWij> blueness: Issue for council discussion or not?
<ulm> next meeting 10th of september
<blueness> dilfridge, its okay i'll just email him
*** Hawk777 (~Hawk777@ritchie.cs.ubc.ca) has left channel #gentoo-council:
    #gentoo-council
<scarabeus> i liked the 2k10
<blueness> ulm, i'll email you an issue
<ulm> blueness: sorry
<blueness> np
<ulm> missed your line :(
*** TomWij (~TomWij@gentoo/developer/tomwij) has left channel #gentoo-council:
    "WeeChat 0.4.1"                                                     [22:33]
<blueness> ulm, really no problem, its easier via email