[03:40] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2771 Publishing packages
[03:54] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2771 Proposed pocket
[06:53] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2771 Release pocket
[06:54] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Currently building (artful/dpdk). Failed to build (artful/openvswitch)
[07:34] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Failed to build (artful/openvswitch). Pending binary packages (artful/dpdk)
[07:54] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Diff missing (artful/dpdk). Failed to upload (artful/openvswitch)
[09:34] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Diff missing (artful/openvswitch). Pending binary packages (artful/dpdk)
[09:47] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Generating diffs
[09:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Successfully built


[19:45] <take> hi, I noticed an issue at the wiki page https://wiki.ubuntu.com/Releases but the page is locked so I can't edit it
[19:46] <take> the link to Lunar Lobster under the column "Code name" in the table erroneously links to the page "LunarLobser" (missing the t)
[19:46] <take> that's all, just wanted to let somebody know so they can fix it.


[20:10] <unixbsd> I managed to cure ubuntu, from systemd, and all addons, and I made a devuan live also. here an example: "https://gitlab.com/openbsd98324/linux-ubuntu-groovy-standard/-/archive/master/linux-ubuntu-groovy-standard-master.zip"
[20:11] <unixbsd> I have fixed few things to make it working. Thank you unixbsd !
[21:47] <mwhudson> LocutusOfBorg: 1.16 sync/merge? i guess so, is it working in debian now?
[22:09] <kees> why is hirsute not listed in either https://changelogs.ubuntu.com/meta-release nor wiki.ubuntu.com ?
[22:12] <mwhudson> kees: https://www.reddit.com/r/Ubuntu/comments/mwa9ud/normal_upgrade_temporarily_disabled_for_ubuntu/ i think
[22:12] <mwhudson> a fixed shim will be along soon
[22:16] <kees> whoa. that's quite a big hammer.
[22:17] <kees> My debmirror keyed off of meta-release, so it wiped my hirsute mirror. :P
[22:17] <kees> oops.
[22:18] <kees> I've switched to scraping https://archive.ubuntu.com/ubuntu/dists/
[22:18] <kees> well, http, not https. but that's why I want an https-sane place to get distro lists from :P


[00:42] <mup> Bug #1515066 opened: failed to create C:/Juju/bin/juju-run.exe symlink <blocker> <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1515066>
[00:44] <cherylj> davecheney: I see bug 1465317 is assigned to you and InProgress.  Are you actually working that bug?
[00:44] <mup> Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:In Progress by dave-cheney> <juju-core 1.24:Triaged> <juju-core 1.25:Triaged> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317>
[01:49] <davecheney> cherylj: nope
[01:49] <davecheney> didn't even know about it
[01:49] <davecheney> sorry
[01:50] <davecheney> how long has it been assigned to me ?
[01:53] <cherylj> davecheney: thumper assigned it to you back on 22-9
[01:54] <mup> Bug #1496016 changed: jujud uses too much memory <juju-core:Triaged> <https://launchpad.net/bugs/1496016>
[01:54] <mup> Bug #1510533 changed: destroy-environment panics <destroy-environment> <juju-core:Invalid> <https://launchpad.net/bugs/1510533>
[02:05] <thumper> hmm
[02:05] <thumper> I seem to recall that it was part of the series / os work
[02:05] <thumper> at least I had assumed that
[02:31] <menn0> thumper: simple juju/utils addition https://github.com/juju/utils/pull/173
[02:32] <menn0> needed as part of fix to the machine agent symlink on windows issue
[02:32]  * thumper looks
[02:32] <menn0> (tested on Windows)
[02:33] <thumper> not sure why it isn't hooked up on review board
[02:33] <thumper> but +1
[02:35] <menn0> thumper: yeah, that's weird
[02:35] <menn0> but thanks
[03:07] <menn0> davecheney: what's the reasoning behind the network operation func move? I have no real problem with it, but I can understand that it might be the kinda of thing that's more widely used which is why it was put in utils
[03:07] <menn0> also, it should probably be based on thumpers juju/retry now (but that's beyond the scope of your change)
[03:13] <davecheney> menn0: i'm nuking the utils packge in juju
[03:13] <davecheney> there is no point in having both a utils repo and a utils package
[03:13] <menn0> right
[03:13] <davecheney> it's clear juju/utils is a dumping ground for things that people thought would be generally useful
[03:13] <davecheney> but in all cases have proven to be used in only one place
[03:14] <davecheney> possibly because they were hard to find ?
[03:14] <menn0> davecheney: I actually missed that this was being moved from the utils package in juju
[03:14] <menn0> all good
[03:14] <davecheney> not to mentino the dumping ground that is github.com/juju/utils
[03:14] <menn0> davecheney: ship it
[03:15] <davecheney> how's the build blockage going ?
[03:23] <menn0> davecheney: about to push the final PR. just doing final tests on Windows
[03:24] <davecheney> thank you
[03:31] <natefinch> is there a fix for bad record mac or do I just retry
[03:31] <natefinch> ?
[03:31] <natefinch> (re the landing bot)
[03:33] <menn0> natefinch: retry. it's a mongodb bug that's fixed in a later version than we use.
[03:35] <natefinch> menn0: boo
[03:36] <davecheney> natefinch: nah, just turn it off and on again
[03:57] <axw_> wallyworld: going to have some lunch, can we have a chat after to talk about what's next?
[03:57] <wallyworld> sure
[04:10] <natefinch> menn0: I was looking at that x509 cert signed by unknown authority bug... sounds like we're having problems reproducing it, but you suggested flipping mongo to secondary "at just the right time" to try to reproduce the problem.  What would be the right time?
[04:11] <natefinch> (https://bugs.launchpad.net/juju-core/+bug/1491688)
[04:11] <mup> Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority <bug-squad> <landscape> <logging> <rsyslog> <sts> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491688>
[04:31] <menn0> natefinch: well we see the problem happening just after the machine agent starts up
[04:32] <menn0> natefinch: around the time the "api" worker starts would be a good place I suspect
[04:33]  * thumper is done
[04:33] <thumper> done done
[04:34] <natefinch> menn0: ok, thanks
[05:12] <axw_> wallyworld: got time now? 1:1 hangout?
[05:14] <wallyworld> axw_: sure, giv eme 5
[05:14] <axw_> wallyworld: ok, poke when you're there
[05:22] <wallyworld> axw_: there now
[05:31] <axw_> wallyworld: one of us dropped
[09:15] <voidspace> dooferlad: wily hasn't [completely] fixed the vanishing windows problem
[09:15] <voidspace> dooferlad: just had it now
[09:42] <frobware> dimitern, have 10 mins for a quick HO?
[09:46] <rogpeppe> wallyworld: ping
[09:47] <dimitern> frobware, can it wait until standup?
[09:48] <frobware> dimitern, let's do it then or later
[09:48] <dimitern> frobware, ok
[09:53] <voidspace> dimitern: ping
[09:55] <dimitern> voidspace, pong
[09:55] <voidspace> dimitern: question about provider/maas/environ.go:providerSuite.makeEnviron
[09:55] <voidspace> dimitern: it looks to me like the call to coretesting.FakeConfig().Merge ought to use testAttrs not maasEnvAttrs
[09:56] <voidspace> dimitern: so I'm going to change it in my branch, just checking with you that's correct
[09:56] <dimitern> voidspace, let me have a look
[09:57] <voidspace> dimitern: all tests pass before and after the change
[09:57] <voidspace> dimitern: it implies that testAttrs is not really needed at all, maybe it's better to get rid of it
[09:58] <dimitern> voidspace, is testAttrs there just to set maas-server URL?
[09:58] <voidspace> dimitern: it looks like it to me
[09:59] <voidspace> dimitern: but it must not be needed as it isn't used!
[10:00] <dimitern> voidspace, yeah it looks like it - maybe the gomaasapi test server changed so it doesn't need it?
[10:00] <voidspace> dimitern: it looks to me like it has never been used...
[10:00] <dimitern> voidspace, all the better then - drop it :)
[10:01] <dimitern> voidspace, dooferlad, frobware, jam, fwereade, standup?
[10:01] <voidspace> omw
[10:01] <dooferlad> dimitern: was already there
[10:01] <fwereade> dimitern, I think I'm there too ;p
[10:02] <dooferlad> https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
[10:02] <dimitern> hmm
[10:21] <voidspace> dimitern: dooferlad: frobware: if you have time, super simple, http://reviews.vapour.ws/r/3116/
[10:22] <dimitern> voidspace, sure, will look in a bit
[10:36] <wallyworld> rogpeppe: hey
[10:40] <rogpeppe> wallyworld: just wondering if there's a feature branch around that's using charmrepo.v2-unstable
[10:40] <wallyworld> rogpeppe: yup, series-in-metadata
[10:42] <rogpeppe> wallyworld: thanks
[10:42] <wallyworld> np
[10:53] <frobware> voidspace, I built and ran tests for your change but some fail.
[10:53] <frobware> voidspace, they may not be related of course, just thought I'd try to see what happens.
[10:54] <frobware> voidspace, http://pastebin.ubuntu.com/13226255/
[11:01] <dimitern> voidspace, reviewed
[11:03] <voidspace> dimitern: it used to return false, why should it *now* return NotSupported
[11:04] <voidspace> dimitern: the error channel there is for things like an error contacting the maas server
[11:04] <voidspace> dimitern: otherwise there's no point in using a boolean
[11:04] <dimitern> voidspace, because that one slipped by me when frank added it I guess
[11:04] <voidspace> frobware: I'll look into it
[11:05] <voidspace> dimitern: "do you support x?" "error"
[11:05] <voidspace> dimitern: it seems to me that "no" is a much more logical response...
[11:05] <dimitern> voidspace, it can be "no", "yes", or "I failed to verify"
[11:05] <dimitern> voidspace, for the last case we need the error
[11:06] <voidspace> dimitern: no, you're suggesting I return "error" for the no case
[11:06] <dimitern> voidspace, but IIRC some of the places this gets called expects (and ignores) NotSupported error from that method
[11:06] <voidspace> dimitern: I do return an error for the "failed to verify" case
[11:06] <voidspace> dimitern: expects and ignores? I don't understand what that could mean.
[11:07] <voidspace> dimitern: and if so I'd rather fix those *callers* and have them properly check the bool result
[11:07] <frobware> voidspace, I believe the test failure are introduced by your change
[11:07] <voidspace> frobware: seems odd, but I'll look into it
[11:09] <dimitern> voidspace, ok, but if SupportsSpaces will return false, nil, please look into all places it gets called (incl. featuretests/ and the all the stubs around cmd/juju, api/ and apiserver/)
[11:11] <voidspace> dimitern: I'll check other similar provider methods
[11:11] <voidspace> dimitern: better to be consistent even if it's weird...
[11:11] <voidspace> dimitern: but it seems more obvious to me that a Supports* method returns true or false and only returns an error when there's an error...
[11:12] <dimitern> voidspace, yeah, seems reasonable to use the error return only when needed
[11:13] <dimitern> (that's the difference between "lets do a high-level spec" and "let's see how things should sensibly work together, based on that spec")
[11:13] <dimitern> voidspace, updated my review
[11:15] <voidspace> dimitern: cool, thanks
[11:27] <voidspace> hmmm... that state test consistently fails on the buildbot for my 1.25 branch
[11:27] <voidspace> testing with 1.25 merged into my branch
[11:27] <voidspace> Error: machine document does not have a "principals" field
[11:31] <voidspace> Doesn't fail on my machine.
[12:07] <voidspace> Weird, I really don't see how that error can arise.
[12:08] <voidspace> Principles is part of the machine document and the error indicates that it's missing.
[12:08] <voidspace> mgz_: ping
[12:09] <voidspace> mgz_: I don't suppose this error is familiar?
[12:09] <voidspace> mgz_: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5383/console
[12:09] <voidspace> mgz_: it doesn't happen on my machine and it's hard to see how it could be spurious
[12:09] <voidspace> but it's happened twice in a row
[12:33] <jam> rick_h__: ping
[12:33] <jam> frobware: sorry I missed the standup today. my meeting with Mark got expanded and went through the time. Anything I should be aware of?
[12:34] <frobware> jam: trying to land first commit on maas-spaces feature branch. :)
[12:35] <rick_h__> jam: pong
[12:35] <frobware> jam: I tried the kmaas.py script but could not get a node to register - will come back and look at why
[12:36] <jam> frobware: k. if you want some live feedback with me, just ping
[12:36] <jam> though I'm off in a few
[12:36] <jam> (30-60min)
[12:36] <jam> rick_h__:
[12:36] <jam> rick_h__: mark and I went over the Funding and Budgets stuff, and got pretty far.
[12:36] <jam> but we have a few things dangling. thought I might ping ideas off of you, if you're interested.
[12:37] <rick_h__> jam: sure thing, I talked to casey about it on monday and hadn't seen if he'd updated it yet
[12:37]  * rick_h__ loads it up
[12:37] <frobware> jam: OK, let me actually debug it a bit more; I tried, it "failed", I got sidetracked.
[12:37] <jam> frobware: :)
[12:38] <jam> rick_h__: I'm happy to hangout as a higher bandwidth mechanism for discussion
[12:38] <rick_h__> jam: sure thing
[12:38] <rick_h__> jam: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1
[13:15] <tvansteenburgh> can anyone tell me how to resolve this bootstrap error? http://pastebin.ubuntu.com/13226910/
[14:50] <mup> Bug #1514444 changed: Windows github.com/juju/juju/cmd/jujud/dumplogs/dumplogs.go:65: undefined <blocker> <ci> <regression> <windows> <juju-core:Fix Released by cmars> <https://launchpad.net/bugs/1514444>
[14:50] <mup> Bug #1515066 changed: failed to create C:/Juju/bin/juju-run.exe symlink <blocker> <ci> <regression> <windows> <juju-core:Fix Released by menno.smits> <https://launchpad.net/bugs/1515066>
[14:50] <mup> Bug #1515289 opened: bootstrap node does not use the proxy to fetch tools from streams.c.c <kanban-cross-team> <juju-core:New> <https://launchpad.net/bugs/1515289>
[14:51] <voidspace> frobware: I do have a failure, related to the removal of testAttrs I think
[14:51] <voidspace> fixing
[15:13] <voidspace> dimitern: hah, testAttrs *was* used
[15:14] <voidspace> dimitern: but only because creating a new reference to a map *doesn't* copy it
[15:14] <voidspace> dimitern: so modifying testAttrs mutates maasEnvAttrs
[15:14] <voidspace> dimitern: I'll change it to a proper copy
[15:15] <voidspace> dimitern: http://play.golang.org/p/O6H0HoQfzh
[16:01] <voidspace> dimitern: we can't stop using the legacy Subnets code as the new api doesn't have allocatableHigh and allocatableLow
[16:02] <voidspace> dimitern: or at least the new code also needs to fetch nodegroup interfaces in the same way as the current code
[16:02] <dimitern> voidspace, sorry, in a call, will get back to you soon
[16:03] <voidspace> dimitern: np, more FYI than requiring a response
[16:21] <dimitern> voidspace, good catch on testAttrs :)
[16:21] <dimitern> voidspace, about Subnets()
[16:21] <dimitern> voidspace, that only applies to the address allocation logic, right?
[16:21] <dimitern> voidspace, we don't need the allocatable high and low otherwise
[16:24] <dimitern> voidspace, I'd suggest keeping the legacy subnets implementation internally for now (unexported) and use it when the network-deployment-ubuntu is missing, otherwise use the new API and just don't populate the static ranges (until we need them)
[16:44] <voidspace> dimitern: well we need them for address allocation
[16:44] <voidspace> dimitern: which is currently the major use for Subnets
[16:44] <voidspace> and I don't want to move that code into address allocation
[16:46] <voidspace> mgz_: sinzui: test infrastructure (CI bots) seems to be in trouble
[16:50] <dimitern> voidspace, yeah, but for the demo we won't need address allocation, will we?
[16:52] <voidspace> dimitern: we won't need containers?
[16:52] <dimitern> voidspace, we won't need the address allocation feature flag
[16:52] <voidspace> dimitern: but if we break address allocation we can't merge back to master
[16:52] <voidspace> dimitern: and we'll have failing tests
[16:53] <voidspace> and we need tests to pass just to be able to develop
[16:53] <dimitern> voidspace, I'm thinking of dropping the current address allocation approach entirely
[16:53] <voidspace> it's easy enough to share that code between the two implementations of subnets (new api and legacy)
[16:53] <voidspace> (the code that figures out addressable range)
[16:53] <voidspace> so I don't see why not do it
[16:53] <voidspace> the new one just won't be as clean as we hoped
[16:54] <dimitern> voidspace, I'd rather ask maas to return the allocatable high/low (both  static and dhcp) using the subnets api
[16:54] <voidspace> we can do that too
[16:54] <dimitern> voidspace, yeah, since it's a new, yet-unreleased api, now's the time to make it saner than the old one
[16:55] <voidspace> I'll file an issue for it
[16:55] <dimitern> voidspace, cheers!
[21:19] <thumper> menn0: a pretty boring review: http://reviews.vapour.ws/r/3115/diff/#
[21:24]  * menn0 looks
[21:31] <menn0> thumper: ship it. just one tiny issue.
[21:32] <thumper> ta
[21:32] <thumper> menn0: my no tail bit isn't working as expected :-(
[21:32] <menn0> thumper: what's happening?
[21:32] <thumper> it isn't not tailing
[21:32] <thumper> ...
[21:32]  * thumper adding debugging
[21:33] <thumper> ha
[21:33] <thumper> found a missing bit
[21:34] <menn0> cool
[21:39] <mup> Bug #1515401 opened: destroy-environment leaving jujud on manual machines <blocker> <destroy-environment> <manual-provider> <regression> <juju-core:Triaged> <juju-core series-in-metadata:Triaged> <https://launchpad.net/bugs/1515401>
[21:43] <thumper> menn0: working now...
[21:43] <thumper> menn0: I missed the param conversion from the apiserver -> state struct
[21:44] <thumper> added tests :)
[21:47] <thumper> menn0: http://reviews.vapour.ws/r/3118/
[22:01]  * menn0 looks
[22:02] <menn0> thumper: have you checked what happens when you use the client that supports "no tail" with a server that doesn't?
[22:02] <thumper> no
[22:02] <thumper> poo
[22:02] <thumper> um...
[22:03]  * thumper thinks
[22:03] <thumper> it'll just ignore it
[22:03] <thumper> as it comes through as a post param
[22:03] <menn0> thumper: it might be a good idea to be sure :)
[22:03] <thumper> but we only check for some...
[22:03] <thumper> yeah
[22:03] <menn0> I'm sure you're right but....
[22:03] <thumper> worth confirming
[22:03] <thumper> for sure
[22:10] <menn0> thumper: so "NoTail" was added to api.DebugLogParams in an earlier PR? I don't see it here.
[22:10] <thumper> surprise
[22:11] <thumper> I needed to make some tests pass when removing the feature flag
[22:11] <menn0> thumper: that's fine :) just making sure the diff was complete and/or I wasn't missing something
[22:12] <menn0> thumper: ship it with one request
[22:48]  * perrito666 thinks that this day is lastimg more than it should
[22:49] <anastasiamac> perrito666: ?
[22:50] <perrito666> anastasiamac: still a lot of things before I EOD
[22:51] <anastasiamac> perrito666: ah... i usually get the feeling that days are not long enough \o/


[09:02] <TheMuso> amachu: Hey there.
[09:06] <amachu> hi
[09:07] <amachu> TheMuso:
[09:07] <amachu> elky: Hi
[09:07] <elky> amachu, hi
[09:07] <amachu> persia: elky: TheMuso: Hi
[09:07] <TheMuso> Hey elky.
[09:07] <amachu> long since we met
[09:07] <elky> w00t. quorum
[09:07] <amachu> persia: are you there?
[09:08] <amachu> we need persia
[09:08] <amachu> lifeless: Hi
[09:08] <elky> i mistook you addressing him as him being here, sorry
[09:08] <amachu> either lifeless or persia
[09:09] <lifeless> hi
[09:09] <lifeless> I forgot about the precise time; I need to go eat or I won't get dinner at all :(
[09:10] <amachu> Ooof
[09:10] <amachu> lifeless: lets check candidates' presence
[09:10] <amachu> MaWaLe: Hi
[09:10] <MaWaLe> hi all
[09:11] <amachu> MaWaLe: alone appear to be here
[09:11] <MaWaLe> i think so
[09:11] <amachu> lifeless: Will you be available or going out for dinner
[09:11] <amachu> elky: ok
[09:12] <amachu> elky: TheMuso: lifeless: Shall we start
[09:12] <TheMuso> sre
[09:12] <amachu> how about lifeless?
[09:12] <elky> amachu, i suspect he's off getting food
[09:13] <lifeless> amachu: I'm not at home, I'm at a colleagues; the only food is take out, so I need to walk out the door in the next 10 minutes tops
[09:13] <lifeless> or things are shut == no food
[09:13] <amachu> okie
[09:14] <lifeless> sorry :(
[09:14] <amachu> then persia?
[09:14] <lifeless> totally my fault
[09:14]  * lifeless waves bye
[09:14] <amachu> or can you be back by 30 min
[09:14] <amachu> I am Ok with it
[09:14] <amachu> how about elky and TheMuso
[09:14] <TheMuso> I'm here.
[09:14] <lifeless> I will be back in nearly an hour
[09:14]  * lifeless is really gone
[09:14] <elky> amachu, we still lack quorum until we have a fourth
[09:14] <amachu> an hour is too long
[09:15] <amachu> elky: Yes
[09:15] <elky> we dont have a choice.
[09:15] <amachu> i am looking for persia to wake up :-(
[09:15] <amachu> MaWaLe: Tought times for you!
[09:15] <TheMuso> Idle for over 4 days
[09:15] <TheMuso> He keeps odd hours as well, and is not always on IRC at regular times.
[09:19] <amachu> ok
[09:21] <amachu> TheMuso: elky: I suppose better luck next week..
[09:21] <TheMuso> Yeah, lets hope so.
[09:21] <elky> amachu, yep, see you then
[09:22] <amachu> elky: wait, you have any nominations for the board
[09:22] <amachu> TheMuso: you?
[09:22] <amachu> I do not have as of now
[09:22] <elky> ajmitch, none that i've spoken to, unfortunately
[09:22] <TheMuso> amachu: no
[09:22] <elky> er, amachu
[09:22] <amachu> okie
[09:22] <elky> although, ajmitch would be a perfect victim :P
[09:23] <elky> he qualifies by being in the right part of the globe anyway
[09:23] <amachu> elky: wiki of ajmitch?
[09:23] <elky> amachu, dunno. maybe we should ask him privately first
[09:23] <amachu> may be you can narrate about your nomination to the mailing list
[09:24] <amachu> so that we all can look at it
[09:24] <elky> amachu, how about we ask him first.
[09:24] <amachu> when others aren't aware, how can we?
[09:25] <amachu> may be he is here now
[09:25] <amachu> We can do so ;-)
[09:25] <elky> amachu, since it was not a planned nomination on my behalf, i've not had the chance to ask him myself. which i would do for anyone before putting forth to the council.
[09:26] <ajmitch> elky: whosit what?
[09:28] <elky> ajmitch, see PM
[09:28] <amachu> elky: ok
[09:29] <amachu> elky: you can elaborate to everyone on the list
[09:29] <amachu> fine
[09:29] <amachu> we will wind up then for this week..
[09:29]  * elky headdesks
[09:30] <amachu> If there isn't any clash, we will likely have our next meeting on March 3 at 1500 UTC
[09:30] <amachu> elky: TheMuso: bye bye
[09:30] <elky> amachu, cya
[09:31] <TheMuso> bye, and damn, I won't be at that one, too late for me.
[09:33] <elky> yeah, that's too late for all the aussies
[14:59] <dholbach> hey robbiew
[14:59] <robbiew> howdy :)
[15:00] <Keybuk> mdz, cjwatson: ping?
[15:00] <cjwatson> yo
[15:01] <cjwatson> are we expecting sabdfl?
[15:01] <Keybuk> he's a little like the Spanish Inquisition
[15:01] <robbiew> ?
[15:01] <Keybuk> robbiew: NOBODY EXPECTS THE SPANISH INQUISITION
[15:02] <dholbach> NOBODY EXPECTS THE SPANISH INQUISITION!
[15:02] <cjwatson> robbiew: please tell me you've seen monty python
[15:02] <mdz> Keybuk: hi
[15:02] <cjwatson> http://en.wikipedia.org/wiki/The_Spanish_Inquisition_(Monty_Python)
[15:02] <robbiew> heh
[15:02] <mdz> I passed sabdfl in a meeting room on the way here, he didn't look finished
[15:02] <robbiew> cjwatson: yes..I have
[15:02] <mdz> clan says he's coming though
[15:03] <mdz> cjwatson,Keybuk: randa is helping to manage the agenda, it should be up to date on the wiki now
[15:03] <mdz> what I would like is to have the agenda always reflect everything which is outstanding for the TB
[15:03] <mdz> and at each meeting we will checkpoint status on everything and close out items which are complete
[15:03] <cjwatson> wfm
[15:03] <mdz> does that sound reasonable to you?
[15:03] <Keybuk> it dods
[15:03] <Keybuk> does too
[15:04] <mdz> #startmeeting
[15:04] <MootBot> Meeting started at 09:04. The chair is mdz.
[15:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:04] <mdz> [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:04] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:05] <cjwatson> is the mailing list question an old one? I hadn't encountered it before
[15:05] <mdz> agenda is now up to date
[15:05] <cjwatson> although I remember that we discussed the same question on the Community Council some time back
[15:05] <mdz> cjwatson: it's a new one
[15:06] <Keybuk> I thought the reason we had it private was it allowed us to discuss developer applications without them being Google fodder for their future job applications?
[15:06] <cjwatson> that was the same kind of reason that we determined community-council@ should be private, yes
[15:06] <mdz> Keybuk: was that it?  I couldn't remember and it's come up again, so I added it to the agenda
[15:06] <Keybuk> mdz: I certainly remember that discussion in Oxford
[15:07] <mdz> it may have been long enough to revisit it :-)
[15:07] <cjwatson> what are the arguments for making it public?
[15:07] <cjwatson> just that we should have arguments for keeping it private? :-)
[15:07] <Keybuk> and where is the proposal to make it public?
[15:08] <mdz> right here :-)
[15:08] <dholbach> In the case of the CC there are a few cases where conflict resolution happens before it gets discussed in a public meeting. Not sure how relevant that is in the case of the TB.
[15:08] <mdz> [TOPIC] Should<EMAIL_ADDRESS>be public?
[15:08] <MootBot> New Topic:  Should<EMAIL_ADDRESS>be public?
[15:08] <sabdfl> -1
[15:09] <mdz> not calling for a vote, I'm looking for input
[15:09] <cjwatson> I would at minimum be concerned of the need to review existing content before blatting it into public view, since people were expecting privacy
[15:09] <Keybuk> we should iterate the reasons for making it public
[15:09] <Keybuk> and the reasons for keeping it private
[15:09] <mdz> motu-council@ serves many similar purposes and is public
[15:09] <cjwatson> I'm not sure that I've been on the board long enough to have a feel for the sorts of things typically posted there at the moment
[15:09] <sabdfl> i bet they have conversations off-list
[15:09] <mdz> cjwatson: I can send you the archives if it would help
[15:09] <Keybuk> on the private side is the desire that developer application discussions not be archived by google forever
[15:10] <cjwatson> I have the archives, I just haven't had time to read them all :-)
[15:10] <Keybuk> (we do cc the developer involved, so they're not private to them)
[15:10] <mdz> technical-board@ serves two purposes
[15:10] <mdz> 1. a contact address to reach the TB (and only the TB)
[15:10] <cjwatson> I actually have a specific concern about motu-council@ based on recent conversations I've had elsewhere
[15:10] <mdz> 2. a mailing list to discuss TB matters
[15:10] <mdz> for 1., private is appropriate, but for 2., it is not really
[15:10] <cjwatson> I'm concerned that there is *not enough* negative discussion of applications, because people are concerned about "being mean"
[15:10] <cjwatson> and I don't think that's appropriate for a neutral applications committeee
[15:10] <cjwatson> -e
[15:10] <sabdfl> +1
[15:11] <mdz> one reason this has come up (this time) is that there are various people who are helping out the TB
[15:11] <sabdfl> then cc them
[15:11] <mdz> we can't control who is CCed when people mail technical-board@
[15:11] <mdz> and for my part, I can't always keep up with the mail to forward things
[15:11] <Keybuk> are you thinking specifically of randa here
[15:11] <mdz> there's also the general principle of transparency
[15:11] <mdz> Keybuk: also jono
[15:11] <mdz> and dholbach
[15:12] <Keybuk> my concern is that I think that people should expect privacy when they mail TB
[15:12] <cjwatson> I would be happy with specific extra people being subscribed to technical-board@, personally
[15:12] <sabdfl> i agree that transparency has value, so would be +1 on a public list and private list, if folks didn't object to the irritation of having two lists
[15:12] <mdz> [LINK] http://www.ubuntu.com/community/processes/techboard
[15:12] <MootBot> LINK received:  http://www.ubuntu.com/community/processes/techboard
[15:12] <sabdfl> there needs to be a quick, easy and memorable way to talk privately to or among the TB
[15:13] <Keybuk> while the nature of such mails is probably less problematic than CC (we don't tend to tender "blah sucks and hates me" type mails), I don't think it's quite zero
[15:13] <sabdfl> i don't know if LP supports private mailing lists
[15:13] <mdz> The Technical Board is responsible for the following documents and processes: 1. The Ubuntu Package Policy, 2. Ubuntu Release Feature Goals, 3. Ubuntu Package Selection
[15:13] <mdz> none of that stuff should be private
[15:13] <cjwatson> the CC certainly gets private discussion of major social blow-ups, or used to, which isn't the case for us
[15:13] <mdz> the page doesn't talk about developer applications, though I agree with the arguments to keep those more confidential
[15:13] <cjwatson> there is a separate website bug about the out-of-date-ness of that web page :-)
[15:14] <mdz> cjwatson: ye
[15:14] <mdz> s
[15:14] <mdz> an old one
[15:14] <dholbach> in case you're not aware of it: everything related to developer applications (in the case of the MC) is public
[15:14] <mdz> [LINK] http://launchpad.net/bugs/248729
[15:14] <MootBot> LINK received:  http://launchpad.net/bugs/248729
[15:14] <cjwatson> dholbach: have you considered whether this is in fact desirable?
[15:14] <dholbach> cjwatson: we did not get any complaints or concerns about it yet
[15:15] <cjwatson> I heard a specific concern recently that somebody wanted to express negative feedback, and was told not to be mean
[15:15] <Keybuk> dholbach: have you considered that you won't get complaints or concerns if the compaints and concerns are public too?
[15:15] <mdz> perhaps the question I've asked is too broad; for my purposes it would be sufficient if TB delegates could be subscribed to the list
[15:15] <cjwatson> now, I haven't gone and looked into the history, but this is something that concerns me deeply
[15:15] <mdz> cjwatson: could we handle the question about motu-council as a separate agenda item?
[15:15] <cjwatson> certainly
[15:15] <dholbach> there's surely a middle ground of expressing concern or advising to "reapply again in a few weeks" without being mean
[15:15] <cjwatson> although I think it's germane to this point
[15:15] <mdz> cjwatson: agreed, just trying to steer to a conclusion
[15:16] <cjwatson> dholbach: there is, but in some cases the response simply ought to be negative
[15:16] <cjwatson> I realise that both of us tend towards the state of being nice to people where possible :-)
[15:16] <mdz> are there any objections to subscribing select people to the TB list who are participating but not actually on the TB?
[15:16] <cjwatson> I have no objection to that
[15:16] <Keybuk> I have no objections either
[15:17] <mdz> sabdfl: thoughts on that option?
[15:17] <sabdfl> +1
[15:17] <sabdfl> that should be transparent, though :-)
[15:17] <mdz> ok
[15:17] <mdz> thanks
[15:17] <mdz> separately, I'd like to reaffirm that where possible, we should shift discussion of public matters from t-b@ onto ubuntu-devel@
[15:18] <mdz> e.g. policy discussions
[15:18] <sabdfl> mdz, i think we could include delegates in private issues explicitly by cc
[15:18] <sabdfl> for example, jono or dholbach or jorge
[15:18] <sabdfl> or randa
[15:18] <sabdfl> where appropriate
[15:18] <cjwatson> on general principles we have usually said that anything in Ubuntu that can be public should be public, so that seems a reasonable statement to me
[15:18] <sabdfl> i think the majority of TB discussions could be public, which lends support to the idea that tb@ be public
[15:19] <cjwatson> by comparison we encourage discussion to move from #distro (irc.canonical.com) to #ubuntu-devel
[15:19] <mdz> I'm happy for it to stay private so long as we only use it for discussions which ought to be private, and nothing else
[15:19] <mdz> e.g. if someone emails technical-board@ and raises a technical concern, we must redirect that to ubuntu-devel@
[15:19] <sabdfl> fine by me
[15:20] <mdz> this is easy to forget to do, etc., but if we agree we can try to make the best of it
[15:20] <mdz> ok to move on?
[15:20] <mdz> [TOPIC] MOTU Council nominations (dholbach)
[15:20] <MootBot> New Topic:  MOTU Council nominations (dholbach)
[15:21] <mdz> dholbach: I put your name on this but just noticed it was persia who emailed t-b@
[15:21] <sabdfl> i propose we nominate dholbach, and two non-canonical candidates
[15:21] <Keybuk> this is a re-nomination of dholbach, right?
[15:21] <mdz> dholbach: can you represent MC here?
[15:21] <sabdfl> yes
[15:21] <dholbach> mdz: technically... I'm not on the MC right now :)
[15:22] <sabdfl> dholbach has expired
[15:22] <dholbach> soren, nixternal, persia: here? :)
[15:22] <sabdfl> (from the MC ;-))
[15:22] <soren> hm?
[15:22] <dholbach> I think it's a good idea to have more members on the MC
[15:22] <Keybuk> who are the proposed other nominees?
[15:24] <mdz> Keybuk: I don't think that's been publicly discussed, it's on t-b@ though
[15:24] <mdz> Subject: MOTU Council list of nominees for MOTU Council Election
[15:25] <Keybuk> are we not discussing them now?
[15:25] <Keybuk> I understood this agenda item to be "nominate people to the MOTU Council"
[15:25] <mdz> I just want to move the process forward; what's the next step?
[15:25] <mdz> is there an agreed process for how council nominations work?
[15:26] <mdz> (apart from TB and CC)?
[15:26] <Keybuk> there seems to be two obvious choices
[15:26] <Keybuk> the TB decides
[15:26] <Keybuk> the Developers decide
[15:26] <Keybuk> the latter seems more desirable to me
[15:26] <mdz> for the TB, it is "Appointments to the board are made by Mark Shuttleworth subject to confirmation by a vote amongst the maintainers"
[15:27] <dholbach> there's https://wiki.ubuntu.com/CommunityCouncil/Delegation and we made use of it in the past
[15:27] <mdz> dholbach: ah, that's useful, thanks
[15:27] <mdz> the CC has done a lot more official delegation than we have
[15:27] <sabdfl> i thought we were following https://wiki.ubuntu.com/CommunityCouncil/Delegation
[15:27] <mdz>     *
[15:27] <mdz>       The CC (and TB) will determine a shortlist of candidates and set up Launchpad polls accordingly so team members can vote.
[15:27] <mdz>     * The polls might take the form of confirmation votes or of a race between more candidates than the available seats on the Team Council.
[15:27] <sabdfl> and were already at the point of having proposed nominees, from the MC
[15:28] <sabdfl> i was suggesting that the TB put up three candidates for confirmation vote
[15:28] <mdz> so the questions are:
[15:28] <mdz> 1. how many slots do we need to fill?
[15:28] <mdz> 2. who are the nominees?
[15:28] <Keybuk> sabdfl: three candidates for how many seats?
[15:28] <sabdfl> three for three, confirmation not a race
[15:28] <sabdfl> dholbach asked that we have an odd number of seats
[15:28] <mdz> there is only one seat opening up, but it's been suggested that the council should be expanded
[15:29] <sabdfl> for quorum / voting reasons
[15:29] <mdz> I'm OK with three seats. keybuk? cjwatson?
[15:29] <Keybuk> +1
[15:29] <mdz> that's replacing the one which expired, and adding two
[15:29] <cjwatson> that would result in an even number of seats
[15:30] <cjwatson> oh, no it wouldn't
[15:30] <sabdfl> MC has been well organised, growing it gives an opportunity to develop more leadership talent
[15:30] <cjwatson> +1
[15:30] <mdz> sabdfl: I have some open questions about how the role of MC will change with ArchiveReorganisation
[15:30] <sabdfl> me too
[15:30] <cjwatson> so does CommunityCouncil/Delegation mean that this needs to be run past the CC too?
[15:31] <sabdfl> no
[15:31] <mdz> agreed, no
[15:31] <mdz> ok, so we're agreed on 3 seats
[15:31] <sabdfl> CC has already delegated this to TB, it's fine to redelegate
[15:31] <sabdfl> (wearing my CC hat)
[15:31] <Keybuk> did CC delegate this?
[15:31] <Keybuk> I thought this was a TB duty that the TB decided to delegate all on its own ;)
[15:31] <Keybuk> the CC delegates membership assignment to the TB
[15:32] <Keybuk> but that's orthogonal
[15:32] <dholbach> I was under the impression that because of the power to grant ubuntumembers membership the MC would report to CC and TB?
[15:32] <sabdfl> Keybuk: reference appointment process to the TB, i guess
[15:32]  * Keybuk makes delegation pancakes
[15:32] <sabdfl> nevertheless, i can say this is up to the TB
[15:32] <sabdfl> we can do it however the TB wants
[15:32] <dholbach> in any case there were no objections raised in the CC when the topic was brought up
[15:33] <sabdfl> this is entirely about how the ubuntu development team picks and organises itself
[15:33] <mdz> dholbach: right, so I think we're free to proceed
[15:33] <dholbach> I'd think so :)
[15:33] <mdz> so we have a list of suggestions from the MC itself, and need to decide on nominees
[15:33] <mdz> I'm happy with the suggestions sabdfl made on t-b@
[15:33] <sabdfl> my recommendation to exlcude one candidate is based purely on the fact that he now works for canonical
[15:33] <sabdfl> and we want to broaden representation outside canonical
[15:34] <mdz> in<EMAIL_ADDRESS>[15:34] <sabdfl> that may be unfair on the individual
[15:34] <sabdfl> i'm loosely attached to the idea
[15:34] <Keybuk> mdz: I agree, +1 on sabdfl's proposed list
[15:34] <mdz> cjwatson: ?
[15:34] <sabdfl> dholbach of course works for canonical, but i feel he's been *fantastic* in this role
[15:34] <dholbach> sabdfl: thanks a lot for the flowers
[15:34] <sabdfl> and so it's worthwhile to me to maintain the continuity, since dholbach nominated himself and says he enjoys it
[15:34] <cjwatson> I don't have any problem with the specific three people proposed
[15:35] <cjwatson> I don't know Nathan very well myself
[15:35] <mdz> I'm supportive of Canonical participating in the council, but agree we should aim to keep the ratio low
[15:35] <sabdfl> a run-off would be a more interesting poll
[15:35] <cjwatson> but he seems to have been effective in the limited interactions I've had with him
[15:35] <mdz> will the confirmation vote be among MOTU or all developers?
[15:35] <mdz> I suggest all developers
[15:35] <sabdfl> i'm easy
[15:35] <dholbach> me too
[15:35] <ScottK> All developers are MOTU.
[15:35] <cjwatson> ... I just made the MOTU team include ubuntu-core-dev ;-)
[15:36] <cjwatson> (as discussed on ubuntu-devel@)
[15:36] <sabdfl> well that solves that
[15:37] <mdz> ok
[15:37] <mdz> that sounds like consensus on the three nominees
[15:38] <mdz> they are: Daniel Holbach, Nathan Handler, and Jonathan Davies
[15:38] <mdz> sabdfl: will you set up the polls?
[15:38] <sabdfl> sure
[15:38] <mdz> [ACTION] sabdfl to set up Launchpad polls for MC nominee confirmations
[15:38] <MootBot> ACTION received:  sabdfl to set up Launchpad polls for MC nominee confirmations
[15:38] <mdz> [TOPIC] SRU guidelines for Landscape (robbiew)
[15:38] <MootBot> New Topic:  SRU guidelines for Landscape (robbiew)
[15:38] <cjwatson> so a poll of all developers will now include per-package uploaders (of whom the only current example is Stefan Bader)
[15:38] <cjwatson> just for the record
[15:38] <mdz> robbiew: are you here?
[15:38] <sabdfl> cjwatson: ~ubuntu-dev right?
[15:38] <cjwatson> assuming you use ~ubuntu-dev
[15:38] <robbiew> mdz: yes
[15:39] <robbiew> I placed the link to the LandscapeSRU process in the agenda.
[15:39] <mdz> so the decision at hand is whether to confirm an exception to the SRU process based on that document
[15:39] <robbiew> From what I understand, sometimes the Landscape client code must be updated to take advantage of improvements/updates to the Landscape server...and this is their reasoning for the need to be part of an SRU.
[15:40] <mdz> I understand from robbiew that the SRU team is OK with it and would like for the TB to make the final decision, is that correct?
[15:40] <ScottK> We have a lot of packages in the archive for which that is true.
[15:40] <cjwatson> we've been back-and-forwarding on this in ~ubuntu-sru for months
[15:40] <mdz> robbiew: right, that was the reason for asking
[15:40] <cjwatson> and feel we have finally reached agreement, after a lot of extra commitments made by the Landscape team
[15:40] <mdz> we asked that they provide an explanation of what processes they will follow in order to ensure their updates are free of  regressions
[15:40] <mdz> which is the purpose of the SRU process
[15:40] <cjwatson> I think those commitments could serve as a template for other projects, at least in principle
[15:41] <robbiew> +1
[15:41] <cjwatson> I absolutely do not want to make an exception for Landscape just because it's Landscape
[15:41] <mdz> cjwatson: agreed, though I also don't want to block it on generalizing the policy
[15:41] <cjwatson> I want it to be generalisable, not necessarily generalised
[15:41] <mdz> I'd like to propose we consider an exception for Landscape based on what has been provided, and then use that as a precedent when this comes up next
[15:42] <cjwatson> so the reasons why I think Landscape is suitable, given the negotiations to date, are:
[15:42] <mdz> if another project can meet the standard we set, then we should consider that as well
[15:42] <cjwatson>  * it has an extensive test suite (yes, like other packages in the archive)
[15:42] <cjwatson>  * its developers have committed to doing specific QA on a variety of upgrade and fresh-install combinations
[15:43] <cjwatson>  * it has very limited interactions with the rest of Ubuntu, that are straightforward to enumerate so that we can have a clear idea of regression potential
[15:43] <cjwatson>  * those interactions have been specifically called out in the mandatory QA process that each upgrade must go through
[15:43] <sabdfl> we must surely have a couple of other upstreams that meet any reasonable such standard
[15:43] <sabdfl> i would like to go out with a document that references more than just landscape
[15:43] <cjwatson>  * its developers have agreed to work within the Ubuntu update process
[15:43] <mdz> impact on non-Landscape users is pretty tightly constrained, and I think Landscape should be able to take responsibility for the impact on their own users
[15:44] <mdz> sabdfl: I fear that will delay what has already been a very drawn out process
[15:44] <ScottK> Landscape client is included by default on Server installs.
[15:44] <cjwatson> sabdfl: we already have a couple of other examples where we do micro-updates; I agree with mdz that I'd like to avoid blocking on having a general policy as long as we're broadly agreed that the principles are general
[15:44] <sabdfl> ok
[15:44] <cjwatson> ScottK: yes, this is true, and this is part of why it has taken so long to come to an agreement
[15:45] <mdz> this was originally raised by the Landscape developers in https://bugs.edge.launchpad.net/ubuntu/+source/landscape-client/+bug/306360
[15:45] <cjwatson> ScottK: however, it has rather limited actual functions for users who don't sign up for server access, which are called out in LandscapeUpdates (basically, update-motd)
[15:45] <mdz> which was filed 2008-12-08
[15:45] <cjwatson> this has been discussed for a lot longer than that
[15:46] <mdz> cjwatson: true
[15:46] <cjwatson> although, yes, I think that was probably the first public mention
[15:46] <ScottK> Which is fine, just that the potential impacts involve essentially all server installs.
[15:46] <ScottK> even if the risk is low
[15:46] <sabdfl> could we at least invite upstreams of other projects that want this to approach the TB?
[15:47] <mdz> ScottK: so we want assurance that the potential impact is limited, and that the testing conducted is sufficient to provide the level of assurance we expect for stable updates
[15:47] <ScottK> Yes.
[15:47] <cjwatson> ScottK: yes. It does concern me, but less than it might due to it being fairly self-contained
[15:47] <mdz> sabdfl: I suggest that we decide for Landscape initially, with a sufficiently detailed rationale that it can be generalized in the future
[15:47] <cjwatson> which is why the QA process suggested is a lot more stringent, and will be a lot more time-consuming for the Landscape team frankly, than most other SRU work
[15:48] <mdz> rather than require a general policy in order to decide on Landscape
[15:48] <mdz> we have made exceptions for several other packages already without a general policy
[15:48] <cjwatson> sabdfl: I'm concerned about inviting upstreams in general
[15:48] <cjwatson> sabdfl: every upstream, without exception to my knowledge, wants distributions to ship the newest available version
[15:48] <mdz> (kernel, app-install-data-commercial, tzdata, hal-info and mobile-broadband-provider-info, FYI)
[15:49] <cjwatson> sabdfl: I think we only have bandwidth to do this for limited high-quality high-value cases)
[15:49] <cjwatson> s/)$//
[15:49] <sabdfl> i think a landscape-only policy that doesn't convey our openness to doing this more generally would be send the wrong message and be poorly received
[15:49] <sabdfl> we are definitely *open* to doing this more generally, so we can say that
[15:49] <sabdfl> and i agree with cjwatson on bandwidth
[15:49] <cjwatson> yes, I think there's middle ground between "we're open to discussions" and "please come and bang down our door"
[15:50] <sabdfl> ok
[15:50] <cjwatson> so stepping back just a moment, if I have time
[15:50] <mdz> we have 10 minutes
[15:50] <cjwatson> kernel, hal-info, mobile-broadband-provider-info come under general category of hardware support (often due to new hardware being introduced)
[15:50] <cjwatson> app-install-data-commercial comes under the general category of enabling something outside the primary archive
[15:51] <cjwatson> tzdata comes under the general category of coping with external events that we can't ignore
[15:51] <cjwatson> (i.e. legislative environment)
[15:51] <cjwatson> landscape is approximately under the same category as app-install-data-commercial, to me
[15:52] <cjwatson> and in general, all of these could be grouped as "updates necessary to deal with changes outside the Ubuntu archive"
[15:52] <cjwatson> external events that we can't necessarily encapsulate in one nice stable release
[15:52] <mdz> it's similar to the various packages (mostly in universe) which are using web APIs or screen-scraping, and occasionally get broken by server-side changes
[15:52] <cjwatson> MSN, ICQ come to mind too
[15:52] <mdz> cjwatson: right
[15:53] <cjwatson> where everything is internal to the operating system (in the wide sense) that we release, I don't think that we should generally contemplate updates of this nature
[15:53] <sabdfl> anything which talks to unversioned web api's is going to get this problem
[15:53] <mdz> to try to move things ahead, it sounds like the main question is the extent to which this decision should be specific to Landscape vs. setting a general policy
[15:53] <sabdfl> liblaunchpad.py
[15:53] <mdz> are there any other concerns with the proposal?
[15:53] <mdz> we'll need to take this offline it looks like
[15:54] <Keybuk> I don't have any particular concerns
[15:54] <mdz> but I'd like to do so with a clear agenda so we can drive to a decision
[15:54] <cjwatson> ScottK raised a QA concern which is basically similar to what the SRU team raised when approached with this
[15:54] <sabdfl> i'm +1 on an a policy for landscape that outlines the criteria we used to make the decision and includes the sentence ("the TB will consider additional applications in due course following similar criteria")
[15:54] <sabdfl> or thereabouts
[15:54] <cjwatson> I'm happy to elaborate on that if requested, perhaps by mail
[15:54] <mdz> we've entrusted the SRU team to assess the QA aspect and will review that ourselves as well based on the document
[15:54] <cjwatson> but the body responsible for stable QA has now signed off
[15:55] <mdz> based on sabdfl's input, I think this requires more than a simple vote
[15:55] <mdz> we'll need to write up a formal decision with rationale which can be referred back to as precedent
[15:55] <mdz> cjwatson: new guy, want to take the action for that? ;-)
[15:55] <robbiew> ouch
[15:55] <cjwatson> yeah, I can do that
[15:56] <mdz> thank you
[15:56] <mdz> [ACTION] cjwatson to write up decision which we can then vote on
[15:56] <MootBot> ACTION received:  cjwatson to write up decision which we can then vote on
[15:56] <cjwatson> (or try, anyway)
[15:56] <mdz> [TOPIC] Upload permission for Romain Francoise for 'emacs-snapshot'
[15:56] <MootBot> New Topic:  Upload permission for Romain Francoise for 'emacs-snapshot'
[15:56] <mdz> I don't have any news here, but this remains open
[15:56] <mdz> Jono has been in touch with Romain
[15:57] <sabdfl> https://wiki.ubuntu.com/UbuntuDevelopers/PerPackageUploaders
[15:57] <sabdfl> do we have anything in writing to support him against those criteria?
[15:58] <dholbach> sabdfl: I did not roll it into UbuntuDevelopers yet - do you think we can make the "process" section a bit more explicit?
[15:58] <sabdfl> dholbach: sure
[15:59] <mdz> he is @gnu.org and @debian.org
[15:59] <Keybuk> sabdfl: my objection remains a simple one
[15:59] <dholbach> it'd be nice if they'd just use https://wiki.ubuntu.com/UbuntuDevelopment/DeveloperApplicationTemplate as normal and either let MC or the TB (you decide) know about it
[15:59] <Keybuk> Romain has only ever had one sponsored upload to Ubuntu
[15:59] <mdz> sabdfl: for my part, the simple (but unfortunate) answer is "I don't know"
[15:59] <sabdfl> https://edge.launchpad.net/ubuntu/+source/emacs-snapshot
[16:01] <ttx> o/
[16:01] <ttx> ^ Koon
[16:01] <cjwatson> ttx: sorry, TB meeting still underway
[16:01] <mdz> we have to wrap up and clear the channel for the next meeting
[16:01] <cjwatson> mdke's application was dealt with by mail
[16:01] <mdz> I'm behind on email, haven't even read it
[16:02] <mdz> but if the three of you agree I'm fine
[16:02] <cjwatson> Mark and I +1ed, I actioned
[16:02] <dholbach> mdz, sabdfl: shall I send you a proposal for the clarification of the per-package-uploader process by mail?
[16:02] <cjwatson> oh, which reminds me, better add mdke to ~ubuntu-dev then
[16:02] <mdz> codecs in ffmpeg, jono is working on
[16:02] <mdz> archive reorg governance I'm not sure of the status
[16:02] <mdz> is it blocked on the technical proposal?
[16:02] <sabdfl> implementation of
[16:02] <cjwatson> still on me to rework proposal following Berlin I think
[16:02] <cjwatson> (sorry)
[16:03] <mdz> sabdfl: I think we can decide the governance model before it's implemented, and should do so to avoid a chaotic transition
[16:03] <mdz> sounds like it's blocked on Colin
[16:03] <mdz> we need to wrap, I'll update the agenda
[16:03] <cjwatson> Daniel asked me for a call this week, will probably manage that a bit later
[16:03] <sabdfl> soyuz team is just laying the foundations, we can use them as we wish
[16:03] <mdz> [ACTION] cjwatson to rework archive reorg proposal to unblock governance work
[16:03] <MootBot> ACTION received:  cjwatson to rework archive reorg proposal to unblock governance work
[16:03] <mdz> #endmeeting
[16:03] <MootBot> Meeting finished at 10:03.
[16:03] <mdz> ttx: all yours
[16:04] <ivoks> \o/
[16:04] <zul> heylo
[16:04] <ttx> mdz: sorry for interrupting :)
[16:05] <mdz> ttx: no worries
[16:05]  * sommer is sortof here :)
[16:05] <ScottK> o/
[16:05] <dendrobates> o/
[16:05] <zul> \0
[16:05] <ttx> zul: "mine is bigger" ?
[16:06] <zul> ttx: yes it is
[16:06] <nealmcb> o/
[16:06] <ttx> mathiaz isn't available so I'll try to replace him
[16:06]  * ttx <-- the hacker formerly known as koon
[16:07] <ttx> #startmeeting
[16:07] <MootBot> Meeting started at 10:07. The chair is ttx.
[16:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:07] <ttx> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:07] <ttx> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090217
[16:08] <ttx> [TOPIC] Review ACTION points from previous meeting
[16:08] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:08]  * ttx frantically reads up last meeting minutes
[16:09] <ttx> Postfix and Dovecot integration: ivoks to create a wiki page for ideas about improving the mail server task post-jaunty
[16:09] <ivoks> here
[16:09] <ttx> ivoks: ?
[16:09] <ivoks> well, i've set up a wiki
[16:09] <ivoks> small, but a start
[16:09] <ivoks> https://wiki.ubuntu.com/ServerTeam/MailServer
[16:09] <ivoks> which is for karmic, so no much point in discussing now
[16:10] <soren> ivoks: cjwatson had concerns about the approach used in the dovecot/postfix integration. Were they adressed?
[16:10] <ivoks> soren: when? 2 weeks ago?
[16:10] <soren> ivoks: Think so, yes.
[16:10] <ivoks> soren: we've solved the whole thing according to his advice
[16:10] <dendrobates> we can address them at UDS, if not.
[16:11] <ivoks> unless there are some new
[16:11] <ivoks> which i'm unaware of :)
[16:11] <ttx> sounds good
[16:11] <soren> ivoks: No, nothing new.
[16:11] <ivoks> ok
[16:11] <ttx> Power management: kirkland to blog about using suspend/resume for servers.
[16:12] <dendrobates> ttx: he is not here, but is blocked on me.
[16:12] <soren> I was just checking. I haven't had a time to review it myself.
[16:12] <soren> ivoks: ^
[16:12] <dendrobates> I will give him approval as soon as I manage to talk to him.
[16:12] <ttx> ok.
[16:12] <ttx> [TOPIC] Roadmap review
[16:12] <MootBot> New Topic:  Roadmap review
[16:12] <ivoks> soren: test it, should be fully functional and i don't think there'll be anything else for jaunty
[16:13] <dendrobates> or if he reads these minutes, go ahead.
[16:13] <ttx> Anyone has a status report on part of the roadmap that would be assigned to himself ?
[16:14] <sommer> the doc.u.c site is updated and ready for reviews :)
[16:14] <ScottK> vorian has been doing some good work on the libdb consolidation.
[16:15] <ttx> The roadmap page looks a little... oudated
[16:15] <vorian> yes, slight snag with libdb4.4 though
[16:15] <ttx> outdated, even.
[16:16] <vorian> ldiskfsprogs seems to only want to build/work with libdb4.4
[16:17] <ttx> ok. Soren, want to do an update on the virtualization front ?
[16:17] <soren> I could. :)
[16:17] <soren> So, since we last saw each other, Eucalyptus entered the archive.
[16:18] <soren> This gives us a free implementation of EC2 and S3 that you can deploy on your own infrastructure.
[16:18] <soren> This is convenient for testing things before pushing them to the real EC2 or if you want to offer computing ressources internal in your organisation, but policies forbids putting data or code on something as public as EC2.
[16:19] <soren> Alpha testers are very welcome.
[16:20] <sommer> soren: what's need to test?
[16:20] <ttx> soren: is there any start page / instructions for first-time testers ?
[16:20] <soren> ttx: No, not yet. There's still some things that needs fixing before it's ready for mass testing.
[16:20] <ivoks> i might test that :)
[16:20] <soren> Once they're sorted out, I'll post a call for testing.
[16:21] <ttx> ok.
[16:21] <ivoks> soren: if i got you right, one can't offer S3 like service
[16:22] <ivoks> soren: but can use it inside it's own web project?
[16:22] <ivoks> s/it's/its/
[16:22] <soren> ivoks: Yes, you can offer this to other people as well.
[16:23] <ivoks> oh
[16:24] <ttx> soren: anything else ?
[16:24] <soren> No, I'm good.
[16:24] <ttx> ok. We are missing a lot of people, anyone else has a roadmap item he wants to give an update on, now that feature freeze is in effect ?
[16:25] <ScottK> I'll just toss out that clamav 0.95 is imminent.
[16:25] <ScottK> I expect an RC this week or next.
[16:25] <ScottK> It's known to break all the libclamav rdepends.
[16:25] <sommer> the last thing for the serverguide is the cloud stuff, can you ping me when it's ready to test soren?
[16:26] <ttx> ScottK: i suppose it was accepted as a FFe ?
[16:27] <ScottK> If we can get the rdepends working, I'm sure it will be.
[16:27] <ScottK> We'd really rather not release with an obsolete clamav.
[16:27] <soren> sommer: Yes, I will.
[16:27] <ttx> I agree with that.
[16:27] <sommer> soren: awesome, thanks :)
[16:27] <ivoks> +1 for clamav
[16:28] <ttx> ok, then lets' move on to:
[16:28] <ttx> [TOPIC] Open Discussion
[16:28] <MootBot> New Topic:  Open Discussion
[16:28] <ivoks> i have one thing...
[16:28] <ttx> Good.
[16:28] <ivoks> there are some users that complaing on our effort on supporting LTS
[16:29] <ttx> ivoks: as in: not SRUing enough ?
[16:29]  * kirkland is here now
[16:29] <ivoks> if we could give more love to LTS somehow, that would be great
[16:29] <ivoks> ttx: well, they do have a point with on thing
[16:29] <ttx> most complains I've seen are for backports
[16:29] <ScottK> As in wanting more?
[16:29] <ivoks> if we fix a bug in lts+ release, we don't backport that fix
[16:30] <ivoks> and we just mark bug as fixed
[16:30] <ivoks> while, in LTS it's not
[16:30] <ttx> ScottK: as in "please ship that new version, it's so good the LTS needs it"
[16:30] <ScottK> Well we do have backports for this.
[16:30] <ivoks> no, i'm against new versions
[16:30] <ttx> ScottK: that's my usual answer, but they usually don't like it.
[16:31] <ivoks> i'm for fixing bug in current and lts release, not just declaring it fixed since it is fixed in, for example, intrepid or jaunty
[16:31] <zul> yes well if thats the case then the backports need more testing that backports dont break things
[16:31] <ScottK> Which is why backports is great.  You don't have to have them.
[16:31] <ScottK> zul: backports very rarely break things.
[16:31] <dendrobates> and we don't have to include them in the point releases.
[16:31] <ScottK> Yes.
[16:32] <ivoks> (fwiw, i didn't talk about backports)
[16:32] <ScottK> OK
[16:32] <ttx> ivoks: so your point is that we lose sight of valid SRU bugs because their development-release task is Fix Released ?
[16:32] <ivoks> ttx: correct
[16:32] <ScottK> If any of you are MOTU and interested in getting involved in the backports process, we need more people to review backports requests.  Please contact me.
[16:33] <ivoks> i'm just saying, maybe we should pay more attention on these things
[16:34] <ttx> We could have a review of fixed bugs and decide if they make likely/badly-wanted/not wanted candidates for the SRU process
[16:34] <sommer> ivoks: is there a list of such bugs?  I can probably help with them
[16:34] <ivoks> or ask users what they think about LTS releases?
[16:34] <sommer> err help test anyway
[16:34] <ScottK> ivoks: Users generally don't find it OK to leave any bugs unfixed.
[16:34] <ivoks> sommer: i don't have a list, these were complaints on #ubuntu-server 2 days ago
[16:35] <ivoks> sommer: from couple of users
[16:35] <sommer> ivoks: okay, I may have missed them, I'll try and find them
[16:35] <ttx> I agree we tend to lose sight of the fixed-in-development-release bugs. And the nomination process doesn't really help.
[16:35] <ivoks> sommer: check sunday
[16:37] <ttx> any suggestion on a process we could use to better track that ?
[16:38] <sommer> could we add tags like hardy-needed, intrepid-needed, etc then remove them when the fix is committed?
[16:38] <ttx> like systematically nominating for relevant releases, and have a session where we look at them and accept/deny them ?
[16:38] <sommer> not sure if that fits, but just a suggestion
[16:38] <ttx> sommer: theorically that's what nominations are for
[16:39] <sommer> ttx: yep, that's better than :)
[16:39] <ivoks> right, nominations should be fine for that
[16:39] <ivoks> if bug is reported in LTS, then fix it in LTS and development-release
[16:39] <ivoks> not just development-release
[16:40] <ivoks> i'm just acting on users feedback :)
[16:40]  * ttx misses the LP-foo required to not losing sight of fixed-in-development-release bugs. Any way to get a list of "nominated for hardy" bugs ?
[16:41] <soren> ttx: Yes. Hang on.
[16:41] <ttx> hm.
[16:42] <ttx> we can't really nominate all relevant bugs and then jave a session of acceptance/denial
[16:42] <ttx> s/jave/have/
[16:42] <soren> https://bugs.edge.launchpad.net/ubuntu/hardy/+nominations I think.
[16:42] <ttx> since for people with superpowers, nominating also does accept the nomination.
[16:42] <soren> s/edge// if you're not cool enough for that.
[16:43] <ttx> :P
[16:43] <dendrobates> I can approve nonimations.
[16:43] <soren> It seems I can, too.
[16:43] <ivoks> i can too :)
[16:44] <dendrobates> soren: really?
[16:44] <dendrobates> hmm.
[16:44] <ivoks> wow, i have superpowers!
[16:44] <ttx> dendrobates: the problem is not really approving. Suppose a core-dev wants to say "this one affects hardy" but not really say "this is a good SRU candidate".
[16:44] <dendrobates> I thought it was restircted to drivers.
[16:44] <ivoks> :)
[16:44] <soren> dendrobates: That page I just linked to shows radio buttons that I can click on. I haven't tried it, but LP usually only shows you these things if you can actually change thenm.
[16:44] <ttx> if the core-dev nominates, it will be automatically accepted, no ?
[16:45] <soren> dendrobates: ubuntu-core-dev is listed as driver as well.
[16:45] <soren> dendrobates: https://edge.launchpad.net/ubuntu/hardy
[16:45] <dendrobates> ahh, I think that is new.
[16:45] <ttx> so you can't really say "affects hardy" and let the bug-reviewing department decide on SRU potential
[16:45] <soren> I do, too.
[16:46] <ttx> ivoks: that's a good point, I propose you add it as a proper agenda item for next week session.
[16:46] <ivoks> ok
[16:46] <ttx> and we can brainstorm during the week.
[16:46] <soren> ivoks: I'm curious why you can, though. You're not core-dev, are you?
[16:46] <ivoks> soren: i'm not
[16:46] <ttx> We could have some QA people joining us
[16:47] <soren> ivoks: *shrug*
[16:47] <ivoks> ttx: imho, we should reach to our users and ask them what they want; push brainstorm.u.c a bit more
[16:47] <ivoks> that's the easiest and best way to world domination :)
[16:47] <dendrobates> ivoks: but only if we are going to take the suggestions seriously.
[16:48] <ivoks> dendrobates: right
[16:48] <ttx> ACTION: ivoks to add to next week agenda an item about better SRU bugtracking
[16:48] <ttx> [ACTION] ivoks to add to next week agenda an item about better SRU bugtracking
[16:48] <MootBot> ACTION received:  ivoks to add to next week agenda an item about better SRU bugtracking
[16:49] <ttx> bah bot
[16:49] <ScottK> I'm somewhat reluctant to do this, but I'm going to bring up Bug 268447 - I think it makes a poor initial impression for new Ubuntu Server users.
[16:49] <ScottK> I'm not arguing what's there isn't allowable, just I don't think it's a good idea for Ubuntu.
[16:50] <ttx> ivoks: if you'er MOTU you can apparently accept nominations for universe packages.
[16:50] <ivoks> ttx: right
[16:51] <ivoks> ScottK: i understand you, and from community point of view, that might not be best thing to pop onto new users; but i personaly don't have anything against that line :|
[16:51] <ttx> ScottK: if it's not a bug, then that should be raised in more "discussion" channels, I guess
[16:51]  * ScottK didn't file it as a bug.
[16:52] <ttx> ScottK: I did ;)
[16:52] <ScottK> This would be doing that (raising it in discussion channels).
[16:52] <nealmcb> I agree with ScottK.
[16:53] <ScottK> Just consider if we want every package that writes to stdout to include links to proprietary add-ons?
[16:53] <ScottK> I'm pretty sure we don't, but as long as that's there, it's very hard to argue against it.
[16:53] <ivoks> like firefox on BBC?
[16:53] <ivoks> you have a link to launchpad inside every app on desktop
[16:53]  * ScottK gets his BBC news via email, so dunno.
[16:54] <ScottK> But Launchpad is used by Ubuntu for stuff.
[16:54] <ScottK> Landscape is a seprate product.
[16:55] <ScottK> At least for me the only Launchpad stuff I find in apps is about filing bugs.
[16:55] <dendrobates> This is outside of our realm of control.  But your opinion will be noted and report up.
[16:55] <nealmcb> What would be more appropraite for the MOTD would be a link to server documentation either on the web or via a local help application - I forget where that discussion ended up
[16:55] <dendrobates> We did our best to make it as innocous as possible, but I understand your concern.
[16:56] <ScottK> dendrobates: If it's in an Ubuntu Server package, I disagree.
[16:56] <ScottK> It is exactly in our realm of control.
[16:56] <ivoks> would 'Find out how to manager your server on http://www.ubuntu.com/manager' be better?
[16:56] <ivoks> and from there, offer canonical and 'community' solutions?
[16:56] <ScottK> Yes, I think it would if it offered both.
[16:57] <ivoks> but, we don't have community way of doing this :(
[16:57] <nealmcb> and launchpad doesn't cost money and will be open source within 6 months
[16:57] <dendrobates> ivoks: I agree, I will try and push that. We should discuss it briefly at UDS.
[16:57] <ivoks> s/manager/manage/ lol
[16:58] <ivoks> dendrobates: web site could provde more information about landscape, so should be even better for canonical
[16:58] <ttx> ok, let's wrap up
[16:58] <ScottK> If you scroll up to the tech board meeting just before us sabdfl made it clear when discussing Landscape that he didn't want it to get special priviledges because it was Landscape (and a Canonical product), but that it might be an example of more general cases.
[16:58] <ScottK> dendrobates: I'd like to see this resovled before release, so UDS is a bit late.
[16:58]  * ScottK stops
[16:59] <nealmcb> ivoks: good idea - it could combine my "help" idea and the more active management that motd readers might want
[16:59] <ttx> it's a complex subject for an open discussion item, I guess
[16:59] <ttx> [TOPIC] Agree on next meeting date and time
[16:59] <MootBot> New Topic:  Agree on next meeting date and time
[16:59] <ttx> next week, same time, same place ?
[16:59] <ivoks> +1
[16:59] <ttx> hopefully mathiaz won't lose network connection 5 minutes before the meeting starts.
[17:00] <ttx> and the meeting will look better prepared :)
[17:00] <ivoks> escuses :)
[17:00] <ivoks> excuses
[17:00] <ttx> #endmeeting
[17:00] <MootBot> Meeting finished at 11:00.
[17:01] <apw> #startmeeting
[17:01] <MootBot> Meeting started at 11:01. The chair is apw.
[17:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:01] <apw> This is the weekly kernel team meeting
[17:01]  * smb_tp waves
[17:01]  * apw looks important on his chair
[17:01]  * cking is here
[17:02] <apw> we seem to be pretty light on people generally, so probabally this will be a short one
[17:02] <apw> [TOPIC] Security & bugfix kernels
[17:02] <MootBot> New Topic:  Security & bugfix kernels
[17:02] <smb_tp> Yeah
[17:02] <apw> how is Intrepid?
[17:02] <smb_tp> Also not much new. I am klicking Hardy and Intrepid proposed through
[17:03] <apw> kicking?  as in kicking the tyres of ?
[17:03] <smb_tp> klicking a mixture between kicking and ... licking...
[17:03] <apw> nnngggg
[17:03] <apw> not a pleasant picture
[17:03] <apw> when are we likely to promote our -proposed candiated?
[17:04] <smb_tp> The Intrepid proposed is in the accept queue. I have to get it further
[17:04] <apw> anything else security related?
[17:05] <apw> rtg reported earlier that the LPIA Jaunty tree was now merged into our main tree
[17:05] <smb_tp> It will take some time. The buildds are just finishing off some packages for hardy. After thatI have to push linux-meta and after that maybe two to three weeks there
[17:05] <apw> and that the old trees are now archived
[17:05] <smb_tp> Nothing security related for now but this is comming soon
[17:06] <jro> Hi, I am worried about the old version of aufs under kernel/ubuntu/ dir. It may contain problems.
[17:06] <apw> jro can we hold that thought for a bit
[17:06] <jro> sure
[17:06] <apw> which release are you talking there?
[17:07] <apw> jro, ?
[17:07] <jro> jaunty
[17:07] <apw> anything else for older kernels?
[17:07] <smb_tp> Nothing. next week hopefully more
[17:07] <apw> [TOPIC] Jaunty Status
[17:07] <MootBot> New Topic:  Jaunty Status
[17:08] <jro> i guess all of them contain old aufs version
[17:08] <apw> ok ... jaunty is now feature frozen, so our tree is now in SRU mode
[17:08] <apw> remember you need more acks to get things in from here on in
[17:08] <cking> how many is "more"?
[17:09] <cking> 2, 3?
[17:09] <apw> i beleieve you need two acks other than yourself for SRU level stuff
[17:09] <amitk> two devs
[17:09] <smb_tp> more than 0?
[17:09] <apw> but we should confirm that with rtg and get him to mail that out
[17:09] <cking> good idea
[17:10] <apw> [ACTION] apw to confirm the ack requirements for jaunty
[17:10] <MootBot> ACTION received:  apw to confirm the ack requirements for jaunty
[17:10] <smb_tp> Generally in maintenance at least one other beside yourself.
[17:10] <apw> we also have Jaunty ALPHA-5 due the 26th (thursday)
[17:10] <apw> anything pending for that, that is not going to make it?
[17:11] <amitk> I have config changes for ixp4xx
[17:11] <apw> is that the changes to get the kernel smaller?  how scarey are they?
[17:11] <amitk> is there going to be another upload? rtg mentioned one yesterday.
[17:12] <amitk> yes, and scarey is relative since currently the device OOMs without the changes
[17:12] <apw> amitk, i would think if there was going to be an uplaod it would be today, i did
[17:12] <amitk> did what?
[17:13] <apw> think that the kernel was basically there, we would need to take action
[17:13] <apw> to get another one if its needed
[17:13] <apw> (typing indicators would be handy in this meeting)
[17:13] <amitk> ok
[17:13] <apw> amitk, can they wait till after the alpha or do we need to jump up and down
[17:14] <apw> smb_tp, presumably you could push the requisite buttons if we need to
[17:14] <amitk> mobile team really wants it for A5
[17:14] <apw> so we need to approach the release team and find out if its even possible at this stage
[17:14] <smb_tp> apw, I probably should be able
[17:14] <apw> [ACTION] amitk to find out if we can slip in another kernel with arm changes
[17:14] <MootBot> ACTION received:  amitk to find out if we can slip in another kernel with arm changes
[17:15] <amitk> ack
[17:15] <apw> the deadline is almost cirtainly basically now
[17:15] <apw> ok jro, aufs?  whats up with that?
[17:15] <amitk> yes, this final kernel test should tell us if it all works now
[17:15] <apw> amitk, cool
[17:16] <jro> old aufs version is known to have some problems
[17:16] <jro> can ubuntu kernel be ok with them?
[17:16] <apw> what are the nature of those problems.  it is unlikely we can get a new version into alpha-5
[17:17] <apw> but after that we could consider it.  we would need a patch against jaunty (i guess) and some
[17:17] <apw> information on what is broken, so we can make an informed decision
[17:17] <amitk> jro: is there a patch available against the version in ubuntu?
[17:17] <apw> jro would you be able to summarise the issues in an email to the kernel-team list perhaps?
[17:17] <jro> i will try developing a patch and send another mail, ok?
[17:17] <apw> and link us to any patches you think are applicable there
[17:18] <apw> jro sounds excellent
[17:18] <amitk> jro: thanks
[17:18] <apw> [ACTION] jro to summarise aufs issues and possible patches
[17:18] <MootBot> ACTION received:  jro to summarise aufs issues and possible patches
[17:18] <jro> ack
[17:18] <apw> anything else Jaunty?
[17:18] <apw> TOPIC] Suspend/Resume
[17:19] <apw> [TOPIC] Suspend/Resume
[17:19] <MootBot> New Topic:  Suspend/Resume
[17:19] <apw> ok we have done some new work on the suspend resume scirpting for server use
[17:19] <apw> ogasawara, i assume we will be pushing out a request for testing with Alpha-5
[17:20] <ogasawara> apw: yup, was just thinking that
[17:20] <apw> ogasawara, will get with you on/before thursday as there may be some instruction changes
[17:20] <ogasawara> apw: ok, sounds good
[17:20] <apw> perhaps to get people to try on servers for instance, kirkland may have some input there
[17:21] <ogasawara> apw: we should definitely make a note of it so people are at least aware
[17:21] <apw> on the incoming bugs side, we are seeing about 7 bugs a day reported by apport nwo
[17:21] <apw> seems pretty steady at the moment.  still no real feel for any patterns in them
[17:21]  * kirkland reads some scrollback
[17:21] <apw> ogasawara, ack
[17:21] <cking> apw: any bugs related to the extended suspend/resume bugs?
[17:21] <cking> s/bugs?/tests?/
[17:21] <IntuitiveNipple> Bug #331415 could bite us; I'm trying to analyse which devices/drivers are affected
[17:21] <kirkland> apw: cool, okay, yeah, so i have a blog entry drafted, with instructions and a call for testing
[17:21] <apw> [ACTION] apw ogasawara to revisit suspend/resume testing instructions
[17:21] <kirkland> apw: i'll publish that today
[17:21] <MootBot> ACTION received:  apw ogasawara to revisit suspend/resume testing instructions
[17:22] <apw> kirkland, ok cool
[17:22] <kirkland> apw:  it was embargoed on review of my manager ;-)
[17:22] <kirkland> apw: dendrobates approved it earlier this morning for publication
[17:22] <apw> cking, only seen one from extended testing and that was a first pass failure
[17:22] <ogasawara> IntuitiveNipple: I can help you scan through bug reports
[17:22] <apw> ok ... cool
[17:23] <apw> IntuitiveNipple, that souds like it needs investigating for sure
[17:23] <apw> let us know if you need any help on the kernel channels
[17:24] <IntuitiveNipple> ogasawara: Thanks. If it turns out to be responsible for resume delays/apparent failures, it looks like it could be a hard one to patch.
[17:24] <apw> yeah a tricky one if we are still in the fridge
[17:24] <apw> anything else suspend/resume?
[17:24] <IntuitiveNipple> I think the main thing is, when reviewing bugs for suspend/resume have it in mind, because it isn't obvious when someone reports "failed to resume" because they rebooted before the 60 second time-out.
[17:25] <apw> IntuitiveNipple, fair point
[17:25] <apw> [TOPIC] Vanilla Kernel Builds
[17:25] <MootBot> New Topic:  Vanilla Kernel Builds
[17:25] <apw> ok ... on the mainline builds these are now progressing nearly automatically
[17:26] <amitk> apw: any statistics on the uptake?
[17:26] <apw> hopefully by next week cron will be taking the strain and we will be off the hook
[17:26] <apw> nothing numerical.  i habe been thanked for them by a number of people who are
[17:26] <apw> using them for all sorts of unexpected things
[17:26] <IntuitiveNipple> They're coming out faster than I have chance to test them:)
[17:26] <apw> so i think generally they are a good thing.  now that they only take space and no people time
[17:26] <apw> still not had any time to try and PPA them, not a priority at this time
[17:27] <amitk> apw: I think we should mention this in some debian channels too
[17:27] <apw> yeah thats a good point.  i wonder if they would install on any debian based system.  presumably yes
[17:27] <ogasawara> apw: if and when they're ready for wider consumption, the community has offered to help advertise
[17:27] <ogasawara> s/community/community team/
[17:27] <apw> ogasawara, i think we are at the point where they are as good as they are going to get
[17:28] <apw> so we should be considering an annoucnement.  are you in the frame for that :)
[17:28] <ogasawara> apw: ok cool.  I'll write up a wiki too then.
[17:28] <apw> there are some wiki pages on it already
[17:28] <apw> https://wiki.ubuntu.com/KernelMainlineBuilds
[17:28] <apw> is a good starting point on consumption of the builds
[17:28] <ogasawara> apw: even better then.  I'll whip up an announcement.
[17:29] <apw> [ACTION] ogasawara to prepare annoucement for mainline builds
[17:29] <MootBot> ACTION received:  ogasawara to prepare annoucement for mainline builds
[17:29] <apw> ...
[17:29] <apw> any other projects anyone needs to report on?
[17:29] <apw> [TOPIC] ARM Tree
[17:29] <MootBot> New Topic:  ARM Tree
[17:30] <apw> amitk, anything other than the arm config changes you want in?
[17:30] <amitk> not for A5
[17:31] <apw> cool
[17:31] <apw> [TOPIC] LPIA Tree
[17:31] <MootBot> New Topic:  LPIA Tree
[17:31] <apw> the only thing i know of here is that the Jaunty tree is now officially merged
[17:31] <apw> sconklin, anything from you?
[17:32] <sconklin> not at the moment
[17:32] <apw> cool
[17:32] <sconklin> I'm looking at LPIA again
[17:32] <apw> [TOPIC] Incoming Bugs
[17:32] <MootBot> New Topic:  Incoming Bugs
[17:32] <apw> ogasawara, any horrors for us to run away from?
[17:33] <ogasawara> apw: nothing critical.  IntuitiveNipple already mentioned bug 331415
[17:33] <ogasawara> there's another regression, bug 327431
[17:34] <apw> smb_tp, ^
[17:34] <IntuitiveNipple> I was about to mention that one, as well
[17:34] <ogasawara> I'm just finishing up adding a regressions section to the bug list
[17:34] <smb_tp> apw, Not looked at this I think
[17:34] <apw> they both on our critical list
[17:35] <apw> ogasawara, thanks, we will find someone to look at those two then
[17:35] <smb_tp> apw, We might need to walk over the critical list and see whether we need to spit up between the two of us
[17:35] <apw> smb_tp, yeah lets get together after and review things, as reviewing the new ones is working well but the old ones are "in the past"
[17:36] <apw> [ACTION] smb_tp apw to review the critical bugs
[17:36] <MootBot> ACTION received:  smb_tp apw to review the critical bugs
[17:36] <ogasawara> smb_tp, apw:  some might be a bit stale (ie not tested with jaunty yet) so I'll sweep through and triage
[17:36] <IntuitiveNipple> I am in the process of setting up a test-bench here to review the WPA Enterprise issues. There have been several around the same basic scenario.
[17:36] <apw> IntuitiveNipple, sounds good.  keep us informed :)
[17:36] <apw> ogasawara, sounds like a plan, thanks
[17:37] <apw> [TOPIC] Open discussion
[17:37] <MootBot> New Topic:  Open discussion
[17:37] <apw> anything else?
[17:37] <IntuitiveNipple> I have a couple of things to mention, when everyone else is done :)
[17:37] <apw> it sounds pretty quiet out there, so go ahead
[17:38] <apw> IntuitiveNipple, ?
[17:38] <IntuitiveNipple> OK. quick backgrounder. I've been messing with kernel/ACPI for a while. Emailed Pete last week saying I'd like to get more involved in kernel-team proper. He thought I was after a job. Not. However, I want to spend full-time working on kernel. So, if there are issues that need looking at, let me know.
[17:39] <IntuitiveNipple> Second: ...
[17:40] <IntuitiveNipple> ... I've been working on a new PCI IOMEM allocation scheme for mainline, which will go to Jesse Barne's PCI tree soonish. After Jaunty is out, I'd welcome some local review before it goes to linux-pci
[17:40] <IntuitiveNipple> It'll make Linux's IOMEM allocation on a par with Windows
[17:40] <apw> IntuitiveNipple, always good to have people helping us out ... #ubuntu-kernel is our home, hastle us
[17:40] <apw> IntuitiveNipple, sounds interesting, cirtainly i would be happy to review
[17:41] <amitk> and kernel-team list is available for patch review discussions
[17:41] <IntuitiveNipple> I'm always there - and when I'm on IRC I am available. I don't leave the client logged in.
[17:41] <IntuitiveNipple> amitk: Yes, thanks. I don't want to drop anything until Jaunty is done and dusted
[17:41] <apw> we are never done and dusted, just on another release
[17:42] <IntuitiveNipple> relatively speaking
[17:42] <apw> ok ... anyone else got anything?
[17:42] <apw> else thats a wrap
[17:42] <apw> thanks to IntuitiveNipple and jro for your input ... come again!
[17:43] <apw> #endmeeting
[17:43] <MootBot> Meeting finished at 11:43.
[19:44] <Veselushko>  :D


[22:09] -queuebot:#ubuntu-quality- Builds: Netboot amd64 [Bionic Final] (20101020ubuntu538) has been added
[22:09] -queuebot:#ubuntu-quality- Builds: Netboot armhf [Bionic Final] (20101020ubuntu538) has been added
[22:09] -queuebot:#ubuntu-quality- Builds: Netboot ppc64el [Bionic Final] (20101020ubuntu538) has been added
[22:09] -queuebot:#ubuntu-quality- Builds: Netboot arm64 [Bionic Final] (20101020ubuntu538) has been added
[22:09] -queuebot:#ubuntu-quality- Builds: Netboot s390x [Bionic Final] (20101020ubuntu538) has been added
[22:09] -queuebot:#ubuntu-quality- Builds: Netboot i386 [Bionic Final] (20101020ubuntu538) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base amd64 [Bionic Final] (20180421.1) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base armhf [Bionic Final] (20180421.1) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base arm64 [Bionic Final] (20180421.1) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base i386 [Bionic Final] (20180421.1) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base ppc64el [Bionic Final] (20180421.1) has been added
[22:17] -queuebot:#ubuntu-quality- Builds: Ubuntu Base s390x [Bionic Final] (20180421.1) has been added
[22:41] -queuebot:#ubuntu-quality- Builds: Ubuntu Server amd64 [Bionic Final] (20180421.2) has been added
[22:41] -queuebot:#ubuntu-quality- Builds: Ubuntu Server ppc64el [Bionic Final] (20180421.2) has been added
[22:41] -queuebot:#ubuntu-quality- Builds: Ubuntu Server arm64 [Bionic Final] (20180421.2) has been added
[22:41] -queuebot:#ubuntu-quality- Builds: Ubuntu Server s390x [Bionic Final] (20180421.2) has been added
[23:07] -queuebot:#ubuntu-quality- Builds: Ubuntu Server armhf+raspi2 [Bionic Final] (20180421.1) has been added
[23:27] -queuebot:#ubuntu-quality- Builds: Lubuntu Alternate i386 [Bionic Final] (20180421.1) has been added
[23:27] -queuebot:#ubuntu-quality- Builds: Lubuntu Alternate amd64 [Bionic Final] (20180421.1) has been added
[23:37] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004438.html
[23:37] <tsimonq2> HEY, PEOPLE LURKING: If you are looking for a way to help, that's a super good way. :)
[23:48] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop i386 [Bionic Final] (20180421.1) has been added
[23:48] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
[23:49] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
[23:49] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop i386 [Bionic Final] (20180421.1) has been added
[23:55] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Bionic Final] (20180421.1) has been added
[23:57] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Bionic Final] (20180421) has been added
[23:58] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop i386 [Bionic Final] (20180421) has been added
[23:59] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop amd64 [Bionic Final] (20180421.1) has been added
[23:59] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop i386 [Bionic Final] (20180421.1) has been added


[01:37] <YankDownUnder> chuckmcm: I've the same basic problem, however, it was resolved with using "arandr" to deal with my dual displays, and also turned off the "power saving" overall.
[05:41] <chuckmcm> interesting YankDownUnder I've got a script that I run (which manually invokes xrandr to move things back into place) but its annoying that the miniDP port seems to turn off for its own reasons
[08:27] <glitchd> how would i go about installing a pae kernel?
[08:29] <OerHeks> Ubuntu 12.10 (Quantal) and onwards: The generic default kernel already has PAE enabled.
[08:29] <glitchd> im on 16.04.1
[08:30] <glitchd> Linux ubuntu16041 4.4.0-34-generic
[08:30] <glitchd> thats the kernel thats running
[08:30] <glitchd> its only using 3 of my 8 gigs of ram
[08:31] <OerHeks> ... Ubuntu 12.10 (Quantal) and onwards .....
[08:31] <glitchd> ...if it was pae enabled, it would show i have 8 gigs of ram..
[08:32] <knome> or maybe some of your ram isn't working?
[08:32] <glitchd> its working fine
[08:32] <OerHeks> grep --color=always -i PAE /proc/cpuinfo
[08:32] <glitchd> if i boot a 64 bit live usb, it shows 8 gigs
[08:33] <Unit193> OerHeks: Or check the kernel config in /boot/config-4.4.0-34-generic
[08:33] <glitchd> its in the first line
[08:33] <glitchd> grep --color=always -i PAE /proc/cpuinfo
[08:33] <glitchd> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
[08:33] <glitchd> but that doesnt make sense
[08:34] <glitchd> it would show in system monitor i thought
[08:34] <glitchd> althought free -m makes me think it does see it
[08:35] <glitchd> free -m
[08:35] <glitchd>               total        used        free      shared  buff/cache   available
[08:35] <glitchd> Mem:           7972        4263        1079         619        2629        2368
[08:35] <glitchd> Swap:          4095           0        4095
[08:35] <glitchd> so maybe it does already see it
[08:35] <glitchd> hmpf
[08:35] <OerHeks> :-)
[08:39] <glitchd> thanks for the info OerHeks
[08:39] <glitchd> adios
[10:31] <drumcode303> when starting a shell script from home directory: what could cause this error?  Syntax error: ")" unexpected
[10:32] <knome> the script has a syntax error.
[10:33] <drumcode303> it runs fine on many other distros. could it be it's a 32/64bit thing?
[10:33] <knome> i don't think so
[10:33] <knome> are you giving some parameters to the script? how are the quoted/escaped?
[10:34] <knome> *they
[10:34] <drumcode303> no parameters when launching it, want me to upload it to dpaste?
[10:35] <knome> sure, i can take a quick look (though i don't have too much time)
[10:36] <drumcode303> http://dpaste.com/0EVQGXA
[10:38] <knome> hmm, no ideaw
[10:38] <knome> -w
[10:38] <drumcode303> thanks for taking the time though :)
[10:38] <knome> it's *very* unlikely it's related to 32/64-bit
[10:39] <drumcode303> ok. should any ideas cross your mind, please let me know :D
[10:39] <knome> you could try asking #ubuntu if somebody knew there
[10:39] <Unit193> Does it say what line?
[10:39] <drumcode303> i think so: 1
[10:39] <knome> or you could try asking Unit193, who always has good ideas
[10:40] <drumcode303> :)
[10:40] <drumcode303> looks like an L but it's probably a one
[10:47] <drumcode303> it doesn't have to start like #!/bin/bash does it? instead of ../sh?
[11:21] <drumcode303> could it be installation error, so that the shell doesn't operate as it should?


 (Document) https://telegram.lubuntu.me/kTDlGQFC/file_4155.png
[01:40] <qwexer> hey everyone
[01:53] <qwexer> \quit
[02:02] <qwexer> has anyone had an issue with creating users on a psql server giving the error "could not change directory to "{path}": Permission denied"?
[02:03] <qwexer> just installed lubuntu on this laptop, and installed a fresh postgresql, never had an issue with my setup before
[03:19] <qwexer> never mind, I was able to solve over in postgresql
 Hi everyone - Quick question.  Why is nvenc now not installed when nvidia drivers are installed like it was in 18.04 ?   Nvidia drivers installed via the ppa - OBS Studio insalled and yet nvenc is not available in OBS.  Check Discover and ffmpeg is not installed ?
[08:04] <wxl> for PPA's you should seek support of the maintainer of the PPA
[08:04] <wxl> they should be assumed to be unsupported
[08:05] <wxl> well, by Ubuntu
 hmmm it worked flawlessly in 18.04 - will test other 18.10 bases
[08:05] <wxl> what's the PPA URL?
[08:05] <wxl> i bet it's a problem with the PPA
 command I used  sudo add-apt-repository ppa:graphics-drivers/ppa
[08:06] <wxl> where did you get that from?
 from this website https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[08:06] <wxl> how did you get there?
 google search
[08:07] <wxl> yeah
[08:07] <wxl> well
[08:07] <wxl> there's your problem
[08:07] <wxl> from that URL:
[08:07] <wxl> "This PPA is currently in testing, you should be experienced with packaging before you dive in here"
 Just curious as it has worked flawlessly for me for a long long time
[08:07] <wxl> that's irrelevant, really, i'm sorry to say
 will uninstall and see what stock drivers do
[08:08] <wxl> what package is nvenc from?
 it's part of ffmpeg and usually had to be built until 18.04
[08:09] <wxl> where did you get it from?
[08:09] <wxl> !info nvenc
[08:09] <wxl> also no packages with nvenc in the filename
[08:09] <wxl> so probably another ppa
 nvenc is just the term for nvidia encoding
 no it was not a ppa - install any 18.04 buntu and it is there working ootb including lubuntu
[08:10] <wxl> so you're saying it's already packaged in the ffmpeg in the repos?
 it is in 18.04 yes
 but on this fresh install ffmpeg is not even installed ?
 according ot discover anyway
 I guess I should install ffmpeg - lol
[08:12] <wxl> if that's a requirement for you, sure
 just unusual its not installed by default - it used to be
[08:12] <wxl> so did LXDE XD
[08:12] <wxl> the question is this: what DOESN'T work because it's missing?
 ok well it installed and OBS still does not have nvenc as an option
 let me reboot - bbiab
[08:13] <wxl> its not windows man
 Lol well don't scaling did not work until rebooted
[08:14] <wxl> well you might need to manually reload modules but i doubt you need to reboot
 ok following reboot still not there - hmmm - let me try stock nvidia - but I am doubfull
[08:16] <wxl> again, i'd talk to the provider of those drivers
[08:16] <wxl> something may have changed in what they did
[08:16] <wxl> or perhaps they don't really provide sufficient support for the development release yet
 possible
 time will tell
[08:16] <wxl> or asking
 ok so back on stock nvidia and still nvenc is not there - will investigate further and report back findings
 update - nvenc is not working in kubuntu 18.10 either
 Hey guys, i hope this is the right forum. I just tried to install the 18.10 beta an got a Python related error
 (Photo, 1280x720) https://i.imgur.com/7p8wfYE.jpg Here it is. Any ideas what i could do to fix this?
[13:04] <hateball> Dave, 18.10 is in #ubuntu+1
[13:05] <hateball> !18.10
[13:05] <hateball> hmmm
 @hateball [<hateball> Dave, 18.10 is in #ubuntu+1], No, not on the Telegram side.
 Lubuntu+1 is in https://telegram.lubuntu.me/development
[13:24] <hateball> oh
[13:24] <hateball> Sorry for spreading false information, it was not my intention
[13:24]  * hateball hasnt kept up
 Thank you! Will ask that question there :)
[22:26] <plujon> I would like to resize my chrome window to exactly 1280 x 600 before I take a screenshot.  How can I do this?
[22:28] <lyorian> http://openbox.org/wiki/Help:Contents is used internally by lubuntu do you need help to modify the xml of openbox and then run openbox --reconfigure after creating a keyboard shortcut
[22:29] <lyorian> plujon: ^
[22:31] <plujon> lyorian: Thanks; so, create a keyboard shortcut for resizing to exactly 1280 x 600, then invoke that shortcut?  I wonder if the keyboard shortcut part can be eliminated...
[22:31] <wxl> you can set your app to a specific size http://openbox.org/wiki/Help:Applications
[22:33] <wxl> go to the <applications> section here https://git.icculus.org/?p=mikachu/openbox.git;a=blob_plain;f=data/rc.xml;hb=master
[22:34] <wxl> basically, you would have something like:

[22:34] <wxl>  <application KEYTYPE="KEYVALUE">
[22:34] <wxl>   <size>
[22:35] <wxl>    <width>1280</width>
[22:35] <wxl>    <height>600</width>
[22:35] <wxl>   </size>
[22:35] <wxl>  </application>

[22:35] <wxl> you'll have to read the applications page on how to get those KEY bits
[22:36] <wxl> tl;dr use obxprop
[22:36] <wxl> you can use as many values as you want like:
[22:36] <plujon> wxl: Thanks.  Doesn't seem to affect an already open window...
[22:36] <wxl>  <application KEY1="KEYVALUE"
[22:37] <plujon> I'm kinda surprised there's no generic linux / X11 way to do this.
[22:37] <wxl>               KEY2="KEYVALUE">
[22:37] <wxl> etc.
[22:37] <wxl> and yeah like lyorian you'll need to restart openbox for it to hit go
[22:38] <wxl> that said you can use wmctrl in a more general way
[22:38] <wxl> you'll want to start with `wmctrl -l`
[22:39] <wxl> add -G if you want to see the existing information
[22:40] <wxl> then do `wmctrl -r <WIN> -e gravity,X,Y,width,height`
[22:40] <wxl> you can read in the man page about possibilities for <WIN> but the name should do the trick
[22:41] <wxl> like "chrome" alone will likely do it, even without proper casing
[22:44] <wxl> TIL wmctrl is not compatibile with all window managers (doesn't work in kwin)
[22:44] <wxl> hm, it's supposed to tho....
[22:47] <plujon> wxl: Thanks; wmctrl -r 0x0320001a -e 0,1,1,1280,600 # works for me
[22:57] <wxl> good plujon :)


[08:52] <zetheroo> I would like to benchmark the CPU performance on a server running Ubuntu 16.04. I have installed the phoronix-test-suite but I am not sure which of the many processor benchmark tests are "best".
[11:19] <otisolsen70> On my Ubuntu servers, I seem to have an endless stream of these type of audit messages in auth.log: https://paste.yt/p24403.html
[11:19] <otisolsen70> Does Ubuntu Server by default log every program executed on a system?
[11:19] <otisolsen70> Is there a way to disable this?
[12:06] <konstruktoid> it's configured via auditd
[13:53] <ahasenack> kanashiro[m]: what does this statement mean:
[13:53] <ahasenack> "The latest docker.io version in Lunar requires Golang 1.18 to be backported to Focal."
[13:54] <ahasenack> in #1977860
[13:54] <ahasenack> is that preparing focal for the next future containerstack backport?
[14:23] <ahasenack> kanashiro[m]: around? I have some more questions
[14:24] <kanashiro[m]> ahasenack: to backport current docker.io in lunar we need go 1.18
[14:25] <kanashiro[m]> And we do not have it in focal and bionic, that's the SRU
[14:28] <ahasenack> kanashiro[m]: question about the dh-golang breaks
[14:29] <ahasenack> kanashiro[m]: it's my understanding the new version of golang needs GOCACHE set to a writable directory
[14:29] <ahasenack> that's what dh-golang >= 1.40 does
[14:29] <ahasenack> we won't backport that
[14:29] <ahasenack> so, will the version of dh-golang in bionic break? It sets GOCACHE to "off"
[14:29] <kanashiro[m]> ahasenack: yes, that's one thing. Also correctly set GO111MODULE
[14:30] <ahasenack> or in other words, packages that use dh-golang, *and* golang 1.18, will have to set that var manually? Or just break?
[14:30] <kanashiro[m]> We need to set it manually in d/rules
[14:31] <kanashiro[m]> Otherwise the package will not build
[14:31] <ahasenack> so when you backport the containerstack, or adsys, or whatever that needs golang 1.18, it will also likely need that adjustment, which is done automatically by newer dh-golang
[14:31] <kanashiro[m]> exactly
[14:31] <ahasenack> ok
[14:32] <ahasenack> kanashiro[m]: don't you also need to remove it from d/control.in? The breaks?
[14:34] <kanashiro[m]> ahasenack: I could do that, yes. It was not an issue because we do not regenerate d/control pre or during build time automatically
[14:34] <ahasenack> it was done so in the golang-1.16 case
[14:34] <ahasenack> I think it would be consistent
[14:34] <kanashiro[m]> I can fix that if you want
[14:34] <ahasenack> yes please
[14:34] <kanashiro[m]> ack
[14:34] <ahasenack> I'll reject the one that is there now then
[14:35] <ahasenack> use the same version
[14:38] <kanashiro[m]> ok
[14:48] <kanashiro[m]> ahasenack: uploaded the fixed version
[14:49] <ahasenack> thanks
[17:13] <mdeslaur> cpaelzer: any objection to me merging exim4?
[17:17] <mdeslaur> oh, maybe bryceh is doing it
[17:17] <mdeslaur> bryceh: are you still working on merging exim4? want me to do it?
[17:51] <mdeslaur> whoops too late :)
[18:00] <bryceh> mdeslaur, that's fine by me if you do it.  We sometimes use it for new hires to practice with, but not sure if we're doing that this time
[18:00] <bryceh> in any case, there are frequent updates so someone needing merge experience will likely have other opportunties :-)
[18:00] <mdeslaur> thanks bryceh, I just uploaded it, it fixes a security issue
[18:00] <mdeslaur> I figured you two wouldn't mind
[18:05] <ahasenack> kanashiro[m]: does the jammy task still make sense for this bug? https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1977860
[18:05] -ubottu:#ubuntu-server- Launchpad bug 1977860 in golang-1.18 (Ubuntu Jammy) "Backport 1.18.1 to 18.04, 20.04 and 22.04 LTS" [Undecided, Incomplete]
[18:05] <ahasenack> jammy has 1.18.1, which the other releases are getting via the SRU
[18:05] <ahasenack> I think if someone wants 1.18.3 in jammy, for other reasons, that needs to be a different bug
[18:30] <kanashiro[m]> ahasenack: I hijacked that bug, initially the goal was jammy :)
[18:30] <ahasenack> that's where the 1.18.3 upload came from, right?
[18:31] <ahasenack> but it was removed now, and the reason is that 1.18 *is* the default golang in jammy, so updating it there isn't so trivial
[18:31] <ahasenack> concerns about rebuild failures and such, and I would also want to know if all apps already built with 1.18.1 would need to be rebuilt with 1.18.3 to benefit from the 1.18.3 updates
[18:54] <kanashiro[m]> Likely a bunch of them
[22:02] <Woet> is there a way to install google chrome or chromium on ubuntu 20 arm64 *without* snap?
[22:07] <Odd_Bloke> Woet: Your best bet is probably to see if the Debian package works (i.e. https://askubuntu.com/questions/1179273/how-to-remove-snap-completely-without-losing-the-chromium-browser/1206502#1206502)
[22:08] <Woet> hm, I saw that, it didn't seem ideal
[22:08] <Woet> but I guess it's the only option left
[22:09] <sarnold> you could probably stuff the debian packaging into a ppa or opensuse build service
[22:09] <Odd_Bloke> Regrettably, yes, as Canonical have decided against providing supported debs.
[22:14] <Woet> Odd_Bloke:  chromium : Depends: libwebpmux3 (>= 0.6.1-2.1) but 0.6.1-2ubuntu<IP_ADDRESS> is to be installed
[22:14] <Woet> looks like it no longer works on the current versions
[22:15] <Woet> i guess i can backport it
[22:15] <Woet> to be fair, that answer was january 2020. by now, debian stable is bullseye, not buster
[22:16] <Woet> i wonder if i change the apt repos to buster it will work
[22:17] <Woet> yup, that works
[22:17]  * Odd_Bloke takes notes
[22:46] <JanC> that seems like a bad idea
[22:47] <JanC> better build it in a PPA
[22:47] <JanC> (or maybe there already is one?)
[22:50] <Woet> JanC: I wasn't able to find a PPA that works on arm64 20.04
[22:54] <JanC> Woet: https://launchpad.net/~phd/+archive/ubuntu/chromium-browser seems to have them?
[22:54] <Woet> hmm
[22:54] <JanC> (not my PPA or by someone I know, so use with care as always)
[23:23] <JanC> seems like he's an active FLOSS community member, so it's _probably_ okay  :)