[01:57] <Logan_> what is the easiest way to remove a file from the .diff.gz?
[02:00] <RAOF> filterdiff?
[02:03] <Logan_> good call
[02:37]  * mdeslaur learns about filterdiff
[04:37] <pitti> bdmurray: known issue, duped to bug 1362496
[04:38] <pitti> sarnold: hm, nothing stuck, let me check
[04:39] <pitti> sarnold: ah yes, I think I see the problem; I'll look into it
[04:39] <pitti> Good morning
[05:12] <andrewrk> is utopic going to update to the official libav 11 release? current version in utopic is 11~beta1
[05:46] <pitti> sarnold: I'm afraid I need to rebuild the apt-ftparchive db on ddebs.u.c., which takes painfully long :( (about 24 hours); I'm afraid the retracers will stay broken until then
[06:03] <YokoZar> oops, I let this sync request stagnate: https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1361047
[06:07] <Logan_> stagnation is sad
[06:30] <thopre01> Hi there
[06:31] <thopre01> I submitted a Feature Freeze Exception on 1st September and I was wondering if there is any chance it's going to be processed before the release
[06:32] <thopre01> (given the short time remaining before release)
[06:32] <thopre01> The FFe in question is for the ARM embedded toolchain: https://bugs.launchpad.net/ubuntu/+source/gdb-arm-none-eabi/+bug/1363788 https://bugs.launchpad.net/ubuntu/+source/libstdc++-arm-none-eabi/+bug/1363790 https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1363791 https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1363792
[06:59] <dholbach> good morning
[07:00] <thopre01> Morning
[07:03] <LocutusOfBorg1> hi people
[08:06] <apachelogger> stgraber: more lxc problems :) http://paste.ubuntu.com/8416404/  <-  this from an unpriv container start done through a daemon (jenkins) that was sudo started from a user other than the one owning the container
[08:07] <apachelogger> the execution env in both cases is exactly the same except for jenkins job variables, so I am not quite sure why it happens or how to prevent it (short of not restarting the daemon from other users anyway)
[08:49] <cjwatson> andrewrk: Yeah, we always intended to.  I've thrown a sync into the queue.
[08:50] <Laney> thopre01: I'll look at thos thanks for the pointer
[08:51] <Laney> gremlins ate my "e,"
[08:51] <thopre01> Laney: Thanks a lot
[09:32] <caribou> before I go and make a mistake, now that I have PPU rights for sosreport & my fixes are in Utopic, all I have to do for my SRU is to upload (using dput) to trusty-proposed & subscribe ubuntu-sru to the bug, right ?
[09:33] <caribou> and the difference b/w uploading to debian & to ubuntu is that, with ubuntu I upload the *source.changes, no binary
[09:46] <RAOF> caribou: You don't actually need to subscribe ubuntu-sru to the bug; we'll process it from the unapproved queue.
[09:47] <caribou> RAOF: ah, ok. Old habbit
[09:47] <caribou> RAOF: so just the dput is enough
[09:47] <RAOF> Yup.
[09:48] <RAOF> Of course, you need to close the bugs from the changelog, but I presume you're doing that anyway :)
[09:49] <caribou> RAOF: yep, it was already in the utopic upload
[09:49] <caribou> hmm, rejected, no upload rights; looks like it has not been processed yet
[09:58] <pitti> caribou: upload rights are configured by release, I figure it was just forgotten to also add you to previous releases
[09:58] <pitti> (or maybe that's on purpose/by policy, I'm not sure)
[09:59] <caribou> pitti: maybe only because my PPU rights got voted on by the DMB monday & they did not have the time to act upon it
[09:59] <caribou> pitti: trying to upload was one way to check that out
[10:00] <caribou> pitti: & true, I did not try to upload to Utopic yet
[10:00] <pitti> caribou: ah, utopic is usually configured first; I thought the utopic upload worked and the trusty one didn't
[10:00] <pitti> caribou: so yes, probably not acted upon yet
[10:01] <caribou> pitti: no, it was sponsored to Utopic
[10:01] <caribou> pitti: but thanks for the details :)
[12:31] <smoser> cjwatson, i had a question for you at https://bugs.launchpad.net/curtin/+bug/1373137 .
[12:32] <smoser> basically, after blatting a tarball to disk, is there some way that i can know when i need to run update-grub. it seemed that dpkg-reconfigure would sometimes run it.
[12:37] <cjwatson> smoser: subscribing me to the bug gives me more chance of seeing the question in mail :)
[12:39] <smoser> cjwatson, i realized that i'd forgotten to subscribe you sometime in the middle of the night.
[12:41] <cjwatson> answered, anyway
[13:51] <smoser> cjwatson, so is just 'touch /boot/grub/grub.cfg' enough to convince dpkg-reconfigure to run update-grub ?
[13:51] <smoser> i do suspect that os_prober is what was slow (and i've disabled that when running it). but doing less is nicer if i can.
[13:59] <dholbach> pete-woods, everything all right? I'm not sure how I'm supposed to understand "Oh noes. The mod-bot got me!"? :)
[14:02] <cjwatson> smoser: err I'm not sure, I suppose so, seems weird but if it produces sane output ...
[14:02] <stgraber> apachelogger: can you pastebin /proc/self/cgroup? I suspect that your current user doesn't own the cgroup it's in and so can't create the cgroups required for lxc
[14:02] <cjwatson> it's just a test -e
[14:02] <cjwatson> smoser: I'm pretty sure os-prober can be sped up, that said :)
[14:03] <pete-woods> dholbach: oh, the auto moderation bot rejected it because of the accounts policy
[14:03] <cjwatson> I made a start on that last week, but I have ninety concurrent things to do so it hasn't got too far yet
[14:03] <pete-woods> dholbach: although I still got an email saying it was published
[14:03] <dholbach> beuno, ^
[14:03] <smoser> cjwatson, thats fine. this is low priority. i'm worried about saving a couple seconds. not a big deal. thanks for your help.
[14:03] <apachelogger> stgraber: earliest in 12 hours or so, assuming that is the case is there any way to make sure this doesn't happen?
[14:05] <cjwatson> smoser: it was annoying me because I was debugging a crash so running it over and over again ...
[14:05] <pete-woods> dholbach: I'm hoping you're still able to override the "accounts" failure, like happened the previews few times
[14:05] <dholbach> pete-woods, Approved version:1.0.12
[14:05] <dholbach> The last submitted upload (1.0.13) failed review.
[14:05] <dholbach> hum hum
[14:05] <dholbach> I can't see how to override it
[14:05] <beuno> pete-woods, I'll take a look
[14:05] <dholbach> thanks a bunch
[14:05] <pete-woods> :)
[14:05] <dholbach> beuno, if you'd prefer I ping somebody else about it, let me know
[14:06] <stgraber> apachelogger: your best bet is to fix the permissions of the cgroup before dropping privilege to that user, you can do that with something like:
[14:06] <stgraber> apachelogger: cgm create all <username>
[14:06] <beuno> pete-woods, link?
[14:06] <stgraber> apachelogger: cgm chown all <username> <uid> <gid>
[14:06] <stgraber> apachelogger: cgm movepid all <username> $$
[14:06] <apachelogger> it's a cgroup problem http://paste.ubuntu.com/8418342/
[14:07] <stgraber> apachelogger: that'll move the current process (your shell) into a newly created batch of cgroups that are owned by the user you'll be switching to
[14:07] <apachelogger> stgraber: I do wonder, shouldn't sudo su $user adjust the cgroup accordingly?
[14:07] <pete-woods> beuno: this is app number 971 (youtube scope). it's been uploaded to the store at version 1.0.13 and the auto moderation bot as failed it because it uses the accounts policy group
[14:07] <smoser> cjwatson, and for this particular use case, my solution of chmod -x is perfectly fine.
[14:07] <cjwatson> yep
[14:08] <stgraber> apachelogger: it's something we've been wondering and I believe it'd make sense but I guess that's not happening because sudo doesn't go through the right parts of the PAM stack and so logind never creates a new session
[14:08] <smoser> as i dont *want* it to find other operating systems. i just installed the one i want.
[14:08] <pete-woods> beuno: but dholbach can't seem to override this fail like has happened previously
[14:08] <smoser> thanks again
[14:08] <apachelogger> stgraber: I see
[14:08] <stgraber> apachelogger: so ultimately that's a logind problem and not one we felt confident working around in Ubuntu as it's probable that some stuff depends on that behavior
[14:08] <apachelogger> *nod*
[14:08] <pete-woods> beuno: if you're not familiar, the accounts profile group is only currently allowed for canonical / trusted scopes
[14:09] <stgraber> apachelogger: for one thing, if we were to do that, any process you spawn through sudo in your session will not be linked to your session anymore and so will not be killed at exit time (if you have that logind option enabled)
[14:09] <beuno> pete-woods, right, we're working out the kinks with these auto-reviews
[14:09] <beuno> sorry about that
[14:09] <beuno> let me fix this for you
[14:10] <pete-woods> beuno: the weird part, is that I still got an email saying my app had been published. even though the bot failed it
[14:10] <beuno> pete-woods, indeed, that sounds like a bug
[14:12] <cjwatson> smoser: (GRUB_DISABLE_OS_PROBER=true in /etc/default/grub or /etc/default/grub.d/foo is simpler, though.)
[14:13] <beuno> pete-woods, the email bug is known and in progress, I'll figure out why it was left as rejected, and how to approve it while we fix and deploy it
[14:14] <smoser> cjwatson, and that will work for 12.04 + ?
[14:14] <smoser> then that is great.
[14:16] <cjwatson> smoser: Yes.  Added in GRUB 1.98.
[14:16] <smoser> gracias. and do you recommend me doing that in /etc/default/grub
[14:16] <smoser> or in /etc/grub/default.d/file.conf
[14:16] <cjwatson> smoser: s/conf/cfg/, but I'd recommend the latter.
[14:17] <smoser> that is 12.04 also i think .right ?
[14:21] <beuno> pete-woods, I approved it
[14:21] <beuno> pete-woods, can you verify for me that the package you get on the phone is correct?
[14:21] <beuno> I did something... "innovative" to get around this bug
[14:22] <cjwatson> smoser: yes
[14:22] <cjwatson> smoser: (I SRUed that)
[14:24] <smoser> cjwatson, ok. last bother i promise. do you suggest updating GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub or putting that in default.d also
[14:25] <xnox> argh I hate gnutls =) specifically old gnutls https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1373422
[14:26] <xnox> looks like gnutls26 decides not to trust if intermediate certificate is not trusted, or some such. Any idea as how to best resolve that issue?
[14:26] <cjwatson> smoser: if you can keep /etc/default/grub pristine then that will cut down on swearing later
[14:26] <xnox> given that mass upgrading trusty to gnutls28 by default is not an option.
[14:26] <cjwatson> smoser: although for GRUB_CMDLINE_LINUX_DEFAULT I think the scripting is supposed to handle it ...
[14:27] <cjwatson> it's rather fragile though, it's really the one bit of the grub2 packaging I haven't yet summoned the fortitude to understand in totality
[14:27] <smoser> cjwatson, agreed. i've been through the swearing. and i figure i'll still have more at some point. but thank you for your advice.
[14:27] <cjwatson> smoser: but d-i updates GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub directly so we have to deal with that in any case
[14:28] <pete-woods> beuno: thanks, just going to have a look now
[14:30] <pete-woods> beuno: okay, cool, that looks good :)
[14:30] <beuno> pete-woods, sweet. We've found the bug (that check wasn't marked as a manual review step), we'll fix it and deploy tomorrow
[14:30] <beuno> so it shouldn't happen again
[14:31] <beuno> it won't get auto-approved as it requires a special permission
[14:31] <beuno> and we haven't gotten to whitelisting permissions
[14:31] <pete-woods> sure, that's fine, as long as it doesn't stop the manual moderators from overriding :)
[14:32] <beuno> jdstrand, I'm going to mark that one as a manual review in the scripts  ^
[14:48] <smoser> cjwatson, just fyi, this change is going to actually fix my issue with petiboot, i'm pretty sure.  i found about this because there was no /boot/grub/grub.cfg , and i'm pretty certain that petiboot was loading/parsing that file. so it did not know of my installation as that file wasn't getting created.
[14:50] <cjwatson> smoser: that would certainly make sense
[14:54] <juliank> Security people, please take a look at the privilege dropping in APT and tell us if you find any error; thank you: http://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc?h=debian/experimental#n2176
[14:55] <juliank> That's inspired by tor's switch_id code, but only checks for errors.
[14:55] <juliank> and does not log success
[14:56] <juliank> We'll probably also put it in a seccomp sandbox for even more security
[14:56] <juliank> (It = The methods fetching files)
[14:59] <RoyK> how can I get bug 1364091 fixed? the solution is there...
[15:00] <kdeuser56> cjwatson: os-prober does not detect ubuntu installs that have a btrfs root file system
[15:01] <kdeuser56> cjwatson: regardless if mounted or not
[15:03] <cjwatson> kdeuser56: yes, that's a bug, just not one it looks like I'm going to have time to fix
[15:06] <kdeuser56> cjwatson: remeber the bug number?
[15:06] <cjwatson> no, sorry
[15:06] <kdeuser56> cjwatson: maybe https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1294638 ?
[15:06] <cjwatson> I guess
[15:06] <cjwatson> I'm doing about five other things
[15:06] <kdeuser56> cjwatson: hm ... someone other with commit access and the skills to fix it?
[15:07] <cjwatson> commit access doesn't matter, send patches
[15:07] <kdeuser56> cjwatson: ok, one question though: did os-prober in ubuntu ever support detecting subvolumes on btrfs partitions?
[15:08] <cjwatson> I'm sorry I don't remember right now
[15:08] <kdeuser56> cjwatson: is there one common upstream for os-prober or does every distro develop their own?
[15:08] <cjwatson> I don't have the attention available to think about this
[15:08] <cjwatson> it's developed as part of the debian-installer project, in Debian
[15:08] <cjwatson> that is the one common upstream
[15:09] <kdeuser56> cjwatson: then I guess that fedora patch did never go upstream: https://bugzilla.redhat.com/attachment.cgi?id=676324&action=diff
[15:10] <cjwatson> I don't know, did they send it?
[15:10] <cjwatson> that's a fairly fearsomely large patch
[15:11] <kdeuser56> cjwatson: it seems not ... they changed the output format of os-prober (common.sh)
[15:11] <cjwatson> kdeuser56: looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688336
[15:13] <kdeuser56> cjwatson: ah thanks ... the patch is proposed there ... a shame no one integrated it :-(
[15:24] <kdeuser56> cjwatson: ok thanks again ... it seems fedora is using the patch already for its last two major releases ... I'll download and test fedora, afterwards report back on the debian bug report, thanks!
[15:31] <pete-woods> cjwatson: you're a distro-ish kinda person. so random question here. we noticed that the package libunity-core-6.0-9 is no-longer on the devel-proposed phone images, but it is on the RTM ones still
[15:31] <pete-woods> cjwatson: it provides some icons that the scopes use
[15:31] <pete-woods> so now it's gone, it means that some fallback icons (for albums with no art, for example) don't appear
[15:32] <cjwatson> shouldn't you depend on it if you need it?
[15:32] <pete-woods> do you know how I can find out why / where it went?
[15:32] <pete-woods> well that's a fair point
[15:32] <pete-woods> so we should install-depend on it, and it'll come back then, seems fair I guess
[15:32] <cjwatson> although its ABI keeps changing of course; icons shouldn't be in an ABI-versioned package like that
[15:32] <cjwatson> I don't know why it went away; I assume all its dependencies went away
[15:33] <cjwatson> all the packages that depend on it, that is
[15:33] <pete-woods> okay, just wanted to check it wasn't purged intentionally
[15:33] <cjwatson> this sort of thing is not generally micromanaged, it's controlled by dependencies
[15:33] <cjwatson> I can find out what happened if you really need it but it will take about half an hour to track it all down
[15:34] <pete-woods> no, that's fine, just wanted to check it wasn't on someone's kill list
[15:34] <cjwatson> doesn't work that way :)
[15:34] <cjwatson> looks like it first disappeared in http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140920/ if that helps
[15:35] <pete-woods> thanks for the info :)
[15:35] <cjwatson> hm, no, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140919.1/
[15:40] <cjwatson> pete-woods: actually, you know what, I got curious and that wasn't too hard to find.  It dropped out because of http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1276
[15:46] <pete-woods> cjwatson: awesome, thanks. turns out that we only need a single icon from that package. so would seem a bit nuts to pull it in just for that. (so we'll probably leave it out)
[15:46] <pete-woods> but again, thanks for the help!
[15:48] <cjwatson> np
[17:00] <infinity> pitti: Were those langpack uploads you?
[17:17] <stgraber> pitti: I just posted my updated init scripts patch to the mailing-list now
[17:54] <sarnold> pitti: thanks for tending to the retracers :)
[18:56] <seb128> jibel, I reassigned #1371651 to jodh, that doesn't seem to be a lightdm issue but an upstart/plymouth/udev/... one, I don't think desktop is going to tackle it
[18:58] <jibel> seb128, k
[19:11] <seb128> hum, the session indicator is listing hibernate for me in utopic, is that a known issue?
[19:11] <seb128> slangasek, pitti, whoever knows that stack, ^?
[19:11] <seb128> didn't we disable that by default some cycles ago?
[19:11] <slangasek> seb128: erm - I thought that was disabled at the level of the indicator itself
[19:11] <slangasek> so... it was desktop team ;)
[19:12] <seb128> slangasek, hum, I doubt we did
[19:13] <seb128> that would be tedious, it would mean patching the indicator, gnome-session, unity, lightdm, etc
[19:13] <slangasek> ok, I don't know then
[19:13] <seb128> didn't we change the polkit rights on the logind/upower actions?
[19:13] <seb128> http://ubuntuhandbook.org/index.php/2014/04/enable-hibernate-ubuntu-14-04/ suggests tweaking the polkit permissions to re-enable it
[19:13] <slangasek> I don't know, I wasn't involved
[19:14] <seb128> ok
[19:14] <seb128> I guess that's one for pitti then
[19:16] <seb128> slangasek, just for the record, http://launchpadlibrarian.net/83287567/policykit-desktop-privileges_0.7_0.8.diff.gz seems to be how it was done
[19:16] <seb128> there is also a similar change on the logind interface
[19:16] <slangasek> alright
[19:17] <seb128> that file still has
[19:17] <seb128> [Disable hibernate by default in logind]
[19:17] <seb128> Identity=unix-user:*
[19:17] <seb128> Action=org.freedesktop.login1.hibernate
[19:17] <seb128> ResultActive=no
[19:17] <seb128>
[19:17] <seb128> I wonder if systemd changed
[19:18] <seb128> pitti, ^ I guess you are off for today, but a topic for tomorrow if you have some spare cycles to discuss that ;-)
[22:13] <xnox> mdeslaur: you win! I owe you beverages of your choice next time you are in London =)
[22:15] <xnox> mdeslaur: if I prepare gnutls update for trusty, would you take that into security pocket or updates only? given that it's effectively false negatives?
[22:15] <xnox> mdeslaur: everything works as expected now, after flipping the certs around.
[22:16] <xnox> bug #1371651
[22:35] <cjwatson> hallyn: How do I get cgmanager to let go of a mount?  I have a stale half-created schroot session that I want to kill off, whose only reference appears to be in /proc/27583/mounts, where that pid is cgmanager
[22:45] <hallyn> cjwatson: is that cgmanager one that was started inside the schrot?
[22:46] <hallyn> cgmanager shouldn't have any references to anyone else's mounts...
[22:46] <hallyn> just doing 'stop cgmanager' should be fine, cgmangaer doesn't keep any state
[22:48] <cjwatson> hallyn: I don't think so, /proc/27583/root -> /
[22:48] <cjwatson> but thanks, will try stopping it
[22:48] <cjwatson> oh I should perhaps mention that pid 1 is currently systemd
[22:49] <hallyn> cjwatson: /proc/pid/root always says it points to '/' :)
[22:49] <hallyn> check under /proc/27583/root/proc to see if it's the same as /proc
[22:50] <cjwatson> eh, no, /proc/pid/root can say other things if it's chrooted and you're looking at it from outside the chroot
[22:50] <cjwatson> anyway, too late, "sudo systemctl restart cgmanager" has cleared it up
[22:50] <hallyn> systemd version 208?
[22:50] <cjwatson> yeah, utopic
[22:50] <hallyn> hm
[22:51] <hallyn> (i ask bc then at lesat systemd didn't make /sys/fs/cgroup ro)
[23:07] <mdeslaur> xnox: oh, cool...with the patch, or you got the certs changed on the server?
[23:11] <xnox> mdeslaur: certs ordering got changed on half the servers, so i'm still pondering about the patch. And I don't like the thing posted on the mailing list = the flags constants values are different from 3.x, off by one.
[23:12] <sarnold> it'd be worth fixing the ordering, I understand firefox still enforces proper certificate order
[23:12] <mdeslaur> sarnold: oh? I didn't think nss cared about cert order
[23:12] <xnox> which is dangerous since 3.x DO_NOT_ALLOW_OUT_OF_ORDER, would become ALLOW_OUT_OF_ORDER, if one uses bitmasks/values instead of contants names.
[23:12] <mdeslaur> xnox: I see
[23:13] <xnox> and the tests have not been backported as part of that patch.
[23:13] <mdeslaur> yeah, the patch probably needs work
[23:15] <xnox> sarnold: we are only discussing bug in missconfigured servers vs old-gnutls. I can trivially test with curl compiled against each of the libraries. openssl passed, gnutls passes with 3.x, didn't test nss
[23:16] <xnox> but i think it handles out of order certchains fine.
[23:17] <sarnold> a friend was whinging two days ago about firefox and gnutls26 enforcing order and complained that "everyone else" (chrome, gnutls28, openssl) supported random ordering just fine...
[23:23] <mdeslaur> sarnold: huh...firefox and chrome both use nss...I was definitely under the impression it was a gnutls26 only thing
[23:23] <sarnold> mdeslaur: wonder why he was upset then :)
[23:23] <mdeslaur> usually it's because of git :)
[23:24] <sarnold> hahahaha
[23:27] <xnox> it is git in my case


[02:31] <ricardoramirez> hi
[02:31] <ricardoramirez> I want to download the nvidia driver but there are too many options
[02:32] <ricardoramirez> can you help me? = http://i46.tinypic.com/34y4gzr.png
[02:33] <ricardoramirez> #ubuntu
[07:39] <Tm_T> moin
[19:58] <AlanBell> ubot5: join #juju
[19:58] <AlanBell> ubot5: whoami
[19:59] <AlanBell> @whoami
[19:59] <ubot2> AlanBell: I don't recognize you.
[19:59] <AlanBell> @login
[19:59] <AlanBell> @login
[19:59] <AlanBell> @login
[20:00] <AlanBell> any ideas?
[20:37] <tsimpson> @haveidentifymsg
[20:37] <tsimpson> lubotu3: identifymsg
[20:38] <tsimpson> ubot5: identifymsg
[20:38] <tsimpson> AlanBell: they should respond now
[20:43] <Tm_T> aww
[20:43] <Tm_T> @login
[20:43] <Tm_T> nice
[20:44] <k1l> where is the spambot :)
[20:45] <tsimpson> it's here, named "ubottu" :)
[20:59] <AlanBell> @login
[20:59] <AlanBell> thanks tsimpson
[20:59] <AlanBell> ubot5: join #juju
[21:00] <Unit193> Magic!


[16:54]  * OCboy Is away now Reason: (brb)
[16:54]  * OCboy Is back from (brb) & I was away for 5secs .
[19:28] <seiflotfy> hey guys


[15:00] <sil2100> o/
[15:00] <juliank> o?
[15:01] <rbalint> o/
[15:01] <rbalint> o!
[15:01] <waveform> o/
[15:01] <waveform> o~
[15:01] <juliank> o//
[15:01] <sil2100> o;
[15:02] <sil2100> #startmeeting Weekly Ubuntu Foundations team
[15:02] <meetingology> Meeting started Thu Sep 12 15:02:07 2019 UTC.  The chair is sil2100. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:02] <juliank> OoooooooooooooooooooOOOOOOOOOOOO
[15:02] <sil2100> #topic Lightning rounds
[15:02] <sil2100> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson juliank waveform)
[15:02] <sil2100> juliank rbalint vorlon tdaitx sil2100 mwhudson waveform bdmurray infinity xnox cyphermox doko
[15:02] <sil2100> juliank: o/
[15:02] <juliank> um
[15:02] <juliank> s
[15:03] <juliank> sorry system was freezing
[15:03] <juliank> - uploaded iptables revert to legacy
[15:03] <juliank> - verified the apt sru bugs
[15:04] <juliank> - some apt discussions
[15:04] <juliank> - fixed autopkgtest-cloud XSS issue and various follow ups on that one
[15:04] <juliank> (done)
[15:04] <rbalint> * prepared backports of wireshark 2.6.10 in ppa:rbalint/scratch2 for *-security
[15:04] <rbalint> * fixed libcec FTBFS through Debian
[15:04] <rbalint> * wrote scripts to easily rebuild package A and run autopkgtest of package B on it https://salsa.debian.org/rbalint/autopkgtest-bisector
[15:04] <rbalint> * updated script for updating systemd to any upstream commit https://salsa.debian.org/systemd-team/systemd/merge_requests/49
[15:04] <rbalint> * finished systemd 242 for Eoan LP: #1843755
[15:04] <rbalint> * working on systemd 243 to get into shape for FANIMAL
[15:04] <rbalint> (done)
[15:05] <sil2100> vorlon: o/
[15:05] <vorlon>  * short week, took Monday off
[15:05] <vorlon>  * out tomorrow (travel swap for sprint)
[15:05] <vorlon>  * proposed-migration: working through a lot of python NBS, openstack now almost done
[15:05] <vorlon>  * finalizing kick-off message for ia32 packages discussion
[15:05] <vorlon>  * filed a bug on autodep8 about it generating wrong python2 tests for python3-only packages, but not actually sure where autopkgtest pulls autodep8 from for running (https://bugs.debian.org/940001)
[15:05] <vorlon> (done)
[15:05] <sil2100> tdaitx: your turn, around?
[15:05] <vorlon> oh also I guess ghc transition finished in the last week :)
[15:06] <sil2100> Guess Tiago is gone?
[15:06] <sil2100> Anyway, I'll go now
[15:07] <sil2100> - SRU reviews and releases
[15:07] <sil2100> - Kernel reviews
[15:07] <sil2100> - FFe reviews
[15:07] <sil2100> - Identified and fixed eoan update-manager regression caused by recent ubuntu-release-upgrader
[15:07] <sil2100> - Reverted net-snmp in -updates due to a serious regression, fixed version now in -updates as well
[15:07] <sil2100> - Reviewed and sponsored livecd-rootfs changes from Rob regarding explicit artifacts
[15:07] <sil2100> - Merged the changes for adding the NoCloud datasource to all device-based ubuntu-image built images
[15:07] <sil2100> - Sponsored livecd-rootfs changes for imx6 support
[15:07] <sil2100> - Backported recent ubuntu-release-upgrader snap-handling changes to disco
[15:07] <sil2100> - Migrated the canonistack bot instance from lcy02 to bos01
[15:07] <sil2100> - Supported overriding EXTRA_SNAPS in livecd-rootfs via the environment
[15:07] <sil2100> - Started experimenting with language-pack sanity-testing
[15:07] <sil2100> - Discussed and prepared a spec for the ubuntu-image work needed for UC20 support
[15:07] <sil2100> - Booking stuff for the release sprint
[15:07] <sil2100> (done)
[15:07] <waveform> * delved into migration of boot configuration on older platforms and edge cases
[15:07] <waveform> * discovered various issues with ancient firmware (that shipped with bionic)
[15:07] <waveform> * deduced a new config that works on both old and new firmwares
[15:07] <waveform> * diagnosed an issue in livecd-rootfs: pi images no longer point the cloud-init seed to the boot partition (in the last hour - patch to be filed)
[15:07] <waveform> * diddled the u-boot patches around until they made a vague sort of sense for submission
[15:07] <waveform> * delighted in the production of a pi4 kernel by Hui Wang, and hence...
[15:08] <waveform> * ditched my own efforts on the pi4 kernel, but then...
[15:08] <waveform> * debated the possibilities of multiple kernels on an image with sil2100 and vorlon given that the new pi4 kernel efforts appear to be pi4 only (currently incompatible with older variants)
[15:08] <waveform> done ... with apologies to bdmurray
[15:08] <sil2100> hah!
[15:08] <sil2100> Too bad Brian's not around to fully appreciate this
[15:08] <sil2100> bdmurray is off today still I guess
[15:08] <waveform> that's why I figured someone should take his shtick ;)
[15:09] <sil2100> No infinity on the channel
[15:09] <sil2100> Ah, he's out this week too
[15:09] <sil2100> xnox is on plumbers I guess? Same for cyphermox?
[15:09] <waveform> yup
[15:09] <sil2100> doko: o/
[15:10] <vorlon> doko is at GNU cauldron so also maybe not available
[15:10] <doko> - started test rebuilds
[15:10] <doko> - filing bug reports for the test rebuild (in progress)
[15:10] <doko> - toolchain updates for linux 5.3
[15:10] <doko> - now in Montreal for the GNU Cauldron
[15:10] <doko> (done)
[15:11] <sil2100> \o/
[15:11] <sil2100> Any questions regarding status?
[15:11] <sil2100> #topic Release incoming bugs
[15:11] <sil2100> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html#foundations-bugs
[15:11] <rbalint> seems empty
[15:12] <sil2100> I guess nothing here
[15:12] <sil2100> For ee as well, everything prioritized
[15:12] <sil2100> No high+ bugs
[15:12] <sil2100> #topic Team proposed-migration report
[15:12] <sil2100> #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:12] <sil2100> Can't remember, the imagemagick is blocked on an MIR?
[15:13] <sil2100> *imagemagick upload
[15:13] <rbalint> sil2100, yes LP: #1827442
[15:13] <doko> sil2100: the incoming report will be pretty full tomorrow ... maybe look at https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190906-eoan.html for now
[15:14] <sil2100> doko: we can take a look at that after proposed-migration then
[15:14] <sil2100> So next is liberror-perl, and that's assigned to me
[15:14] <sil2100> Didn't have time to look at it yet though
[15:15] <sil2100> netplan.io, I'd assume cyphermox was looking at that, maybe I should look at it as well since I wanted to dive into netplan anyway
[15:15] <sil2100> Anyone looking at it right now or can I card it and assign it to myself?
[15:16] <rbalint> regarding imagemagick how about building it without libheif, getting that migrated, then picking up libheif again for 20.04?
[15:16] <vorlon> rbalint: there's nothing else of interest in the imagemagick in proposed *except* the libheif re-enablement
[15:16] <rbalint> hm, actually vorlon volunteered doing htat
[15:17] <vorlon> well, LocutusOfBorg had some further changed, but I pinged him asking about this and he didn't respond
[15:17] <vorlon> also it was a revert of a CVE fix so no
[15:18] <vorlon> anyway, I think leaving it blocked as-is on the MIR is best
[15:18] <rbalint> vorlon, ok, no toolchain update made it more secure?
[15:18] <vorlon> not afaik
[15:18] <doko> awaiting security review
[15:18] <rbalint> vorlon, ack, thanks
[15:19] <sil2100> Next would be openssh, also unsatisfiable depends
[15:20] <sil2100> Anyone looking at that? Anyone have any additional info?
[15:21] <vorlon> sil2100: runit is trash and we should remove all references to it from the package
[15:21] <vorlon> (it's a non-init service monitoring framework that we want nothing of in Ubuntu, we use systemd)
[15:22] <vorlon> so someone want to look at that?
[15:22] <vorlon> or did I just volunteer myself ;)
[15:23] <sil2100> Was wondering about the latest upload since Colin did it, but then I saw it's a sync from Debian
[15:24] <sil2100> vorlon: will you card it and assign it to yourself? ;)
[15:24] <vorlon> no, but I'll work on it
[15:25] <sil2100> ...that's more than good enough!
[15:25] <sil2100> Anyway, I guess that's it then
[15:25] <cjwatson> I'm going to be pretty unhappy if every future openssh change turns into a merge
[15:25] <sil2100> doko: you wanted us to look at the test rebuild results for eoan, right?
[15:25] <cjwatson> If you want to do that then please consider neutering dh-runit rather than modifying openssh
[15:26] <cjwatson> vorlon: ^-
[15:26] <vorlon> cjwatson: ack
[15:27] <cjwatson> (since presumably the same thing applies to anything else that's had dh-runit-based patches accepted in Debian, either now or in the future)
[15:27] <doko> sil2100: yes, because I just finished filing the ftbfs / rls-ee-incoming issues
[15:29] <vorlon> cjwatson: (we could also make dh_runit invocation conditional on dpkg-vendor?)
[15:29] <cjwatson> Could, but cumbersome
[15:29] <sil2100> There's 44 packages that need attention from what I see, should we set some time next week maybe to fix some of them?
[15:29] <sil2100> (from the eoan test rebuild)
[15:29] <sil2100> gaughen: what do you think? ^
[15:29] <cjwatson> And I don't see why it would be correct to do it that way if the reason is that it's a distribution-wide policy to avoid runit
[15:29] <gaughen> sil2100, yes, we should.
[15:30] <cjwatson> But let me know if there's some reason I haven't thought of that makes it necessary
[15:30] <doko> sil2100: fine with me, then they are visible in the incoming bugs as well
[15:30] <sil2100> doko, gaughen: let's maybe work on getting a time-slot next week to work on that and see how it goes then
[15:30] <sil2100> We can do that after the meeting
[15:31] <sil2100> In the meantime, let's proceed
[15:31] <sil2100> #topic AOB
[15:32] <sil2100> Any other business?
[15:32] <sil2100> ...timeout!
[15:33] <sil2100> #topic Next chair
[15:33] <sil2100> I choose... xnox !
[15:33] <sil2100> #endmeeting
[15:33] <meetingology> Meeting ended Thu Sep 12 15:33:47 2019 UTC.
[15:33] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-09-12-15.02.moin.txt
[15:33] <sil2100> Thanks everyone o/
[15:33] <rbalint> good choice! but for the week after next week! :-)


[20:01] <jussi> right, who is here?
[20:02] <jussi> topyli: tsimpson nhandler Pici?
[20:02] <topyli> heyhey!
[20:02]  * tsimpson is here
[20:03] <jussi> ok, we have quorum...
[20:03] <jussi> tsimpson: bout your turn for chair, right?
[20:04] <tsimpson> probably
[20:05] <tsimpson> #startmeeting
[20:05] <MootBot> Meeting started at 14:05. The chair is tsimpson.
[20:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[20:05] <tsimpson> [link] https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[20:05] <MootBot> LINK received:  https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[20:05] <tsimpson> [topic] Offtopic Guidelines
[20:05] <MootBot> New Topic:  Offtopic Guidelines
[20:06] <tsimpson> [link] https://wiki.ubuntu.com/BenjaminRubin/OfftopicGuidelines
[20:06] <MootBot> LINK received:  https://wiki.ubuntu.com/BenjaminRubin/OfftopicGuidelines
[20:06] <tsimpson> not sure if Pici is about
[20:06] <tsimpson> but it's been on the agenda a while now
[20:06] <jussi> that link basically says:
[20:06] <jussi> To be placed under the 'Language and Subject' heading in our guidelines
[20:06] <jussi> Our offtopic channels are designed to be places where people can be in company of others while talking about subjects that they enjoy. We realize that many of us enjoy figuring out computer problems, but we respectfully ask that if a conversation is turning into something that you would more likely see in our support channels, that you bring it there instead. That said, if someone asks you to move your support conversation into one of our
[20:06] <jussi> support channels, please do so.
[20:07] <jussi> Im +1 on this, no problems
[20:07] <topyli> i think the last sentence is the relevant one
[20:07] <topyli> the rest is dressing :)
[20:08] <jussi> Im happy to have a vote that we add this, if you like?
[20:08] <tsimpson> it's something that we have done before, this is just putting it into writing
[20:08] <topyli> yeah. let us vote
[20:09] <tsimpson> [vote] Add the above to IRC/Guidelines under Language and Subject
[20:09] <MootBot> Please vote on:  Add the above to IRC/Guidelines under Language and Subject.
[20:09] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[20:09] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[20:09] <jussi> +1
[20:09] <MootBot> +1 received from jussi. 1 for, 0 against. 0 have abstained. Count is now 1
[20:09] <tsimpson> +1
[20:09] <MootBot> +1 received from tsimpson. 2 for, 0 against. 0 have abstained. Count is now 2
[20:09] <topyli> +1
[20:09] <MootBot> +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3
[20:09] <jussi> excellent
[20:09] <tsimpson> [endvote]
[20:09] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[20:09] <tsimpson> so who wants to do that?
[20:09] <jussi> give it o Pici
[20:09] <tsimpson> [action] Pici to edit the guidelines wiki
[20:09] <MootBot> ACTION received:  Pici to edit the guidelines wiki
[20:10] <topyli> i would change the wording, but i can talk to Pici about it
[20:10] <tsimpson> [topic] Dealing with Ubuntu IRC Problem Users
[20:10] <MootBot> New Topic:  Dealing with Ubuntu IRC Problem Users
[20:12] <topyli> nhandler wanted to submit his document for review by the team. i'm happy with the content of it, but it's a bit meditative and needs to be formatted
[20:12] <ikonia> can you provide context of this document ?
[20:12] <ikonia> or background to the item ?
[20:13] <topyli> well
[20:13] <topyli> it aims to reduce trigger happiness
[20:13] <ikonia> great, more documentation and process
[20:14] <topyli> it tries to reinforce the guidelines we already have. first you +q and talk to the user, and so on. you don't declare people trolls right away and ban them
[20:14] <topyli> that sort of thing
[20:14] <ikonia> no
[20:14] <ikonia> there shouldn't be a first you do this, then you do that, it should be" you use common sense for the sitaution "
[20:15] <topyli> it's often not happening, so i do support documentation
[20:15] <ikonia> then speak to the people it's not happening with
[20:15] <ikonia> rather than put another document / process in place
[20:16] <jussi> I disagree, having guidelines are a good thing.
[20:16] <topyli> in fact it's already in the operator guidelines, as well as the leadership guidelines. assume best of the user, give them benefit of the doubt
[20:16] <ikonia> the guidelines are there, there doesn't need to be another document to backup the guidelines
[20:16] <tsimpson> if we do have a set of guidelines then we don't have to rely on an interpretation of what should be done
[20:16] <ikonia> you arleady have guidelines though, why is there a need for another document
[20:17] <tsimpson> we aren't planning to have something that says "you must do this...", but something that guides our general enforcement of the channel rules
[20:17] <ikonia> you arleady have guidelines though, why is there a need for another document
[20:18] <jussi> I think nhandler's intention is this will get merged nto the guidelines, but of that I am not certain.
[20:18] <topyli> if we followed the loose guidelines we already have, we shouldn't have a need for more precise documentation. but we seem to be failing
[20:18] <tsimpson> the other guidelines aren't really a policy, more a set of technical solutions
[20:18] <tsimpson> this one is intended to be more of a behaviour guide
[20:18] <ikonia> topyli: if people are not following the guide;omes. lets speak to them, instead of doing another doucment
[20:20] <topyli> yes we should do that as well
[20:20] <ikonia> you should do that, full stop
[20:20] <ikonia> one of the complaints/feedback to the council in the recent troubled times was due to not listening to the community, or communicting
[20:21] <ikonia> one of the things was too much process, not enough common sense
[20:21] <ikonia> and lack of communictaion
[20:21] <ikonia> communicate with people if you feel they are not in line with the guidelines
[20:21] <ikonia> stop making processes of processeses, of documents
[20:22] <ikonia> the team is small, most would welcome communication rather than another guidelines/policy being pushed at them
[20:23] <topyli> maybe you should look at the document though, once we decide to submit it for evaluation. then decide whether or not you like it
[20:23] <tsimpson> the current section on op behaviour is very terse, we are expanding on that
[20:23] <ikonia> topyli: I take the point, but I feel the council should stop working on documents like this and start actually gaining the confidence of the operators and community it serves
[20:23] <jussi> and submitting the document to you for evaluation and help is part of communicating and inclusion.
[20:24] <ikonia> jussi: same point, submitting a document that doesn't need changing, isn't what people want,
[20:24] <tsimpson> currently there really is near no policy on how ops should act, so users can not tell if an op is overstepping their bounds or acting inappropriately
[20:24] <jussi> We arent forcing changes, just saying, ok, this is happening, we are writing some stuff down, and allowing you to take part.
[20:24] <tsimpson> that is a cause of problems
[20:25] <ikonia> tsimpson: there are guidlines exactly the same as the users
[20:25] <tsimpson> operators have more requirements on their behaviour than users do
[20:25] <topyli> ikonia: operators have committed to much more than that
[20:26] <ikonia> topyli: yes, but those commitments/guildlines are called out in the same way as the users
[20:26] <IdleOne> IMO the problem is interpretation of the guidelines, one op will judge something to be a violation and an different op will not.
[20:26] <jussi> ikonia: so you object to us modifying the guideline?
[20:26] <ikonia> if you are going to call out specific operator rules/guidlines that an operator can be judged on, you need specific user rules that can be applied
[20:26] <ikonia> jussi: yes, at this time
[20:27] <nhandler> o/
[20:27] <jussi> Well until you read the document, when nhandler gets her...
[20:27] <tsimpson> hey nhandler :)
[20:27] <jussi> hi nhandler
[20:29] <topyli> nhandler: so. we were trying to decide whether or not to submit your draft for discussion, but the discussion started without it :)
[20:30] <topyli> i for one think it's a good base and should be submitted on the mailing list
[20:30] <nhandler> [LINK] https://docs.google.com/Doc?docid=0ASFFoXLMT-guZGhoZmZxNG1fNTYyaHB3NzNxZGM&hl=en&authkey=CNCQ__wP
[20:30] <MootBot> LINK received:  https://docs.google.com/Doc?docid=0ASFFoXLMT-guZGhoZmZxNG1fNTYyaHB3NzNxZGM&hl=en&authkey=CNCQ__wP
[20:31] <ikonia> I find the concept of this document not required, and I find the situation it will bring - users complaining it was not followed unacceptable
[20:32] <tsimpson> so you are saying that users should not be able to hold operators accountable?
[20:33] <topyli> users should complain right now if something goes against the spirit of that doc
[20:33] <ikonia> nope, I'm saying they should be judged on common sense
[20:33] <ikonia> not by a document
[20:33] <tsimpson> common sense seems vary wildly
[20:33] <ikonia> I don't think it does
[20:34] <ikonia> most people in the operator team are in agreement on most users behaviour and when it doesn't agree it talks it thorugh and it's resolved with the user
[20:34] <ikonia> I don't see an issue currently, if you do, we need to talk about it
[20:35] <ikonia> I really find the word "job" thorughout the document inappropriate, although I appreciate the context it's meant in
[20:35] <topyli> let's submit it to the mailing list. we need feedback from everyone in the team who wants to chip in, not the few who are here
[20:35] <tsimpson> we aren't deciding to implement the changes, we are only discussing the document at the moment
[20:35] <topyli> not useful debating details in the meeting. let's decide whethr or not submit it
[20:35] <tsimpson> comments and modification are welcome
[20:36] <ikonia> cat /dev/null > document
[20:36] <ikonia> send it to the list
[20:36] <nhandler> One thing we would also like is some help converting it to a nicer wiki format
[20:36] <nhandler> Bullets are much nicer than long documents :)
[20:36] <ikonia> can I ask the council to also outline a similar document for council jobs, commitments and behaviour please.
[20:37] <topyli> the irc council's duties and behavior are dictated by the community council, we can't really do that
[20:37] <nhandler> Which are outlined at https://wiki.ubuntu.com/IRC/IrcCouncil/Charter
[20:37] <ikonia> topyli: sure you can
[20:38] <ikonia> nhandler: that is not specific and does not call out specific behaviour rules, such as your document
[20:38] <ikonia> I'd like to see documentation for how the council should handle situations, that they can be judged on
[20:38] <tsimpson> situations such as?
[20:38] <ikonia> common things, like responding to email requests
[20:39] <ikonia> a council member must always be active in -ops to comply with nhandler suggestion of eslcation to a council member
[20:39] <ikonia> things like that,
[20:39] <ikonia> it is your job to respond to an email request within 2 working days, etc
[20:39] <IdleOne> I understand the need for a general "this is how you should handle a situation" document so all the ops can be on the same page. What worries me is that if we starts creating these documents without covering every possible situation they will end up being used against ops who don't follow them to the letter.
[20:40] <topyli> ikonia: please open an item for a council meeting, and discuss this. we are talking about nhandler's draft
[20:40] <ikonia> topyli: no, I'm asking the council members (one of them) to take an action for this
[20:41] <topyli> on what? being on call at all times on -ops?
[20:41] <ikonia> document the processes you follow for core issues,
[20:41] <nhandler> IdleOne: Which is at this point something that has not happened and can be dealt with when and if the time comes. The document does address several issues that have come up in the past
[20:41] <topyli> the email responsiveness request is certainly valid and true
[20:41] <ikonia> topyli: that's part of it, yes, a council member must be available in -ops at all times to fall in line with nhandler's documented and judged escalation path
[20:42] <nhandler> ikonia: Uh, where are you getting that from?
[20:42] <ikonia> nhandler: you're document
[20:42] <IdleOne> nhandler: at this time I am not against such documentation so current and future ops have a base line to follow. I will reserve judgment on the semi-final version when it is available
[20:43] <topyli> ikonia: the document suggests consulting other ops. if the issue persists, contact the council
[20:43] <nhandler> ikonia: Care to point me to the part where that is stated?
[20:43] <ikonia> yes, so there will need to be a council member available
[20:43] <tsimpson> ikonia: the document just says to contact a a member of the council, not that they need to be in -ops
[20:43] <topyli> it doesn't mean you should consult the council within 10 minutes of someone cursing on #ubuntu
[20:43] <tsimpson> we have our own council channel, and email
[20:43] <ikonia> tsimpson: ok, then a council member needs to be availabvle 24x7 for escalation
[20:43] <ikonia> by irc/email/whatever
[20:44] <ikonia> topyli: if there is an issue of persistant ban evasion, the path is to escalate to the council, the council must be available then to deeal with it
[20:44] <tsimpson> we need to be contactable 24/7, which we are
[20:44] <ikonia> that's not documented
[20:44] <tsimpson> neither is what you are saying
[20:44] <ikonia> tsimpson: that should go in your rules and behabvioru document I've requested
[20:45] <ikonia> tsimpson: it is, in nhandler's proposal
[20:45] <tsimpson> no, it says that you should contact a council member, not contact them directly and await a response before doing anything else
[20:45] <ikonia> tsimpson: yes, so if it goes to another op, they can't resolve it, it needs to go to the council, then the council need to be available
[20:46] <ikonia> that's the path the document says as a set of rules to be followed
[20:46] <topyli> exactly
[20:46] <topyli> which btw is how things are now
[20:46] <ikonia> if you are documenting an escalation path, they need to be available, more so as you are using this document to judge operator decisions
[20:46] <IdleOne> they are available, via irc and email
[20:46] <ikonia> topyli: no it's not, the council are not available 24x7 to deal with eslcation,
[20:46] <ikonia> no they are not
[20:47] <tsimpson> ikonia: well fortunately we are only asking for comments on the document now, not implementing it
[20:47] <ikonia> tsimpson: you're getting comments back
[20:47] <tsimpson> yes, I know
[20:47] <tsimpson> that's what I did mean there, sorry
[20:47] <ikonia> cool
[20:48] <IdleOne> ikonia: the ability to contact the council is already implemented, but we can't not expect anybody to be available 24/7 to resolve an issue immediately
[20:48] <IdleOne> can not*
[20:48] <topyli> we need more than one comment though. nhandler, would you action this by sending the email?
[20:48] <ikonia> IdleOne: yes you can if you are being judged on the escalation path
[20:48] <nhandler> topyli: Yes
[20:48] <ikonia> IdleOne: this document is to judge operators and assure they follow a procedure, if that procedure ends with passing the imediate issue over to the council, they need to be there to take it, which as irc is 24x7 they need to be hter
[20:49] <topyli> nhandler: great. meeting moves on :)
[20:49] <ikonia> what's the next item ?
[20:49] <nhandler> Giving me a formal [ACTION] ;)
[20:49] <topyli> :)
[20:50] <tsimpson> [action] nhandler to send the document to the IRC mailing list for discussion
[20:50] <MootBot> ACTION received:  nhandler to send the document to the IRC mailing list for discussion
[20:50] <IdleOne> ikonia: in a case like a persistent ban evader, if the council isn't around to act within 5 minutes we can continue to set bans/mute the problem user. I think you asking for anyone one of us (IRCC and ops team) to be here 24/7 to deal with an issue is unrealistic
[20:50] <ikonia> IdleOne: I agree it's unrealistic and uncalled for, but I'm not writing a document that says here is what you do
[20:51] <topyli> no new bugs on launchpad
[20:51] <ikonia> finished any of the other outstanding items ?
[20:51] <IdleOne> the document isn't a firm "this is how to do it" but more of a this is how you can handle a situation if unclear
[20:51] <ikonia> IdleOne: I find the doucment insulting
[20:51] <tsimpson> [topic] Any other business
[20:51] <ikonia> IdleOne: it IS a firm how you do it
[20:51] <MootBot> New Topic:  Any other business
[20:52] <ikonia> tsimpson: yup, finished any of the other outstanding items ?
[20:52] <ikonia> shell policy, long term problem user policy, etc ?
[20:52] <ikonia> you know the stuff that was raised months ago ?
[20:53] <ikonia> I've got quite a list here
[20:53] <topyli> status is at https://wiki.ubuntu.com/IRCCouncil/TeamReports , hoping it's up to date :)
[20:53] <IdleOne> ikonia: I don't mean to keep harping about it but I didn't read as a law that must be followed.
[20:53] <ikonia> IdleOne: then you didn't read it correct, it is a document showing how operators should act and be judged on it
[20:54] <ikonia> topyli: doesn't really explain that much
[20:54] <IdleOne> I will read it again.
[20:54] <topyli> nobody is being judged btw
[20:54] <ikonia> topyli: well, you are as you are saying operators are not following the guidelines so this document is to set out a clear policy that should be followed
[20:54] <ikonia> therefore if you don't follow it, there is room for judgment
[20:55] <topyli> it is a howto
[20:55] <ikonia> really, that wasn't what was said at the start, it was said people where not following the guidelines
[20:55] <IdleOne> ikonia: what worries me is that we will end up being judged by the problem users and they will use such documents as base to argue/fight op decisions
[20:55] <ikonia> IdleOne: I fully agree,
[20:55] <IdleOne> I am not worried about being judged by my peers
[20:55] <tsimpson> IdleOne: that's why there is an appeal process with humans managing the process
[20:55] <ikonia> ok, so back to the meeting
[20:56] <ikonia> can I again request the council members take an action to document there issue resolution process with timescales and commiemtns
[20:57] <topyli> which process is that? what we have done is we're making an effort to not have issues without an owner. i hope that will help
[20:58] <ikonia> topyli: you must have a process to follow for dealing with issues and requests including commiments to respond by $X time etc ?
[20:58] <ikonia> or is that process just common sense ?
[20:58] <topyli> since you don't want documentation, you must be trying to make a joke
[20:58] <ikonia> no, if you're pushing down documentation on how to behave, I want to see documented your behaviour and process commitments
[20:58] <ikonia> it's a two way street
[20:59] <ikonia> I'm still waiting for my actions to be implimented or responded too, yet  you all seem to find time to write some more documents for the operators to follow
[20:59] <tsimpson> we already have that in the charter
[20:59] <ikonia> so lets have it a two way street, lets document your processes and guidelines and commitments to be used
[20:59] <ikonia> tsimpson: no, the charter is vauge, it doesn't set out the processes or the time scale commitments
[20:59] <ikonia> tsimpson: the charter is as vague as the current operator guidlines that don't appear to be acceptable
[21:00] <ikonia> you want to get specific, I want to see specifcs for your commitments, process and behaviour too
[21:00] <tsimpson> we are not the directly user-facing IRC ops
[21:00] <ikonia> I don't feel the council has been living up to the charter, so I want to see it clearly agreed
[21:00] <topyli> we are right now trying to craft a document in concert with the whole team. we are not "pushing down" anything. please try and work on basis of reality, even when ranting
[21:00] <tsimpson> what part of the charter do you think we failed at?
[21:00] <ikonia> tsimpson: yes you are, and you are user facing to the IRC team (me)
[21:02] <tsimpson> ikonia: what part of the charter do you think we failed at?
[21:02] <ikonia> hello ?
[21:02] <IdleOne> yes
[21:03] <IdleOne> ikonia: ikonia_ I think you are lagged.
[21:03] <ikonia> sorry my connection is having an issue
[21:03] <ikonia> ok, it seems to be back, apologies
[21:04] <tsimpson> the meeting is overrunning
[21:04] <ikonia> then I'll drop it and take it to the list
[21:04] <ikonia> (I'm sure you can guess I'm not very happy with this)
[21:04] <tsimpson> [action] tsimpson to complete the fixed agenda items
[21:04] <MootBot> ACTION received:  tsimpson to complete the fixed agenda items
[21:05] <tsimpson> #endmeeting
[21:05] <MootBot> Meeting finished at 15:05.
[21:05] <topyli> if the council is not fulfilling the charter, that's important. ikonia, please do bring it up
[21:05] <IdleOne> thanks for the meeting.
[21:05] <ikonia> topyli: I've brought it up before
[21:05] <ikonia> I don't see change
[21:05] <ikonia> I see the same loop
[21:07] <topyli> i see abstract unhappiness, with no fixable issues or suggestions how to improve. might be a language issue though, mine's not perfect
[21:07] <ikonia> topyli: it's not, it's just total lack of faith with what the council are doing
[21:07] <ikonia> topyli: I'll raise it for the next meeting
[21:07] <topyli> good, thanks