[11:54] <] GoldenDragon> no, just uses Netscape to access her gmail and yahoo accounts.
[11:54] <Stormx2> ] GoldenDragon: Seems odd to use netscape on ubuntu is all.
[11:54] <] GoldenDragon> : P
[11:54] <TGPO> ] -[erbie, yes, you need to add in libdvdcss
[11:54] <zerosmoke> holy crap it works
[11:54] <] -[erbie> TGPO: thnx
[11:54] <ubotu> Yum!
[11:54] <] GoldenDragon> i'm sure its nothing ubuntu related..
[11:54] <] GoldenDragon> prbbly more netscape.. but I dunno if they have an IRC channel xD
[11:54] <zerosmoke> thanks...except...now the sound hangs...
[11:54] <zerosmoke> lol
[11:55] <Stormx2> Well I wouldn't know. Using the netscape mail client right? Well I suppose it could be port issues, but I wouldn't have thought so. Gmail offers some excellent guides, has she followed them? Theres bound to be one on netscape...
[11:55] <zerosmoke> heard of this problem  beofre
[11:55] <socomm> zerosmoke: close out any other application and restart firefox.
[11:55] <Stormx2> ] GoldenDragon: XD, are you talking about netscape on windows?
[11:55] <Asc> Anybody know how to get ssh X forwarding working?  I'm getting a "cannot open display" error when trying to start a program.
[11:55] <Stormx2> ] GoldenDragon: Wrong channel mate...
[11:55] <Stormx2> ] GoldenDragon: Nah not really.
[11:55] <socomm> zerosmoke: another application might be accessing the sound card.
[11:55] <] GoldenDragon> heh
[11:55] <TGPO> ] -[erbie, http://www.debian-multimedia.org/pool/main/libd/libdvdcss/
[11:56] <] -[erbie> TGPO: great! thnx
[11:56] <socomm> I find it odd that on windows two applications can't read and write to a file at the same time, but more than one app can access the sound card.
[11:56] <zerosmoke> hmmm....you mean like gaim messenger?  lol
[11:56] <zerosmoke> seems to be working now
[11:56] <] GoldenDragon> funny, she just restarted her comp and it started working
[11:56] <] GoldenDragon> aight well.. thanks anyway Storm!
[11:56] <radioaktivstorm> Stormx2, thanks, Ill try this
[11:56] <zerosmoke> "I stole a baby!  That's just about as evil as it gets!"
[11:56] <socomm> On Unix various apps can access the same file, but no more than one app can access the sound card at once.
[11:56] <zerosmoke> thanks
[11:57] <zerosmoke> socomm
[11:57] <socomm> zerosmoke: NP.
[11:57] <zorba64> ] -[erbie: try installing libdvdread3 and then sudo /usr/share/doc/libdvdread3/install-css.sh
[11:58] <live> hola
[11:58] <nuts7> hi+
[11:59] <nuts7> anyone know where the .xsession files are located?
[11:59] <zorba64> ~
[11:59] <nuts7> zorba64: you sure.. theres nuffing there :(
[12:00] <socomm> nuts7: usually in your home directory. You can also set a global xsession under /etc/x11 or something.
[12:00] <radioaktivstorm> sladen, when i try fdisk, it says its unable to open hda
[12:01] <] -[erbie> zorba64: I am a newb... how do I install libdvdread3?


[02:32] <rsalveti> cooloney: hey!
[02:32] <rsalveti> cooloney: any news about the mem issue bug?
[02:44] <rsalveti> robclark: do you know if we're going to get the fb resize feature from the omap 4 x11 video driver?
[02:46] <robclark> rsalveti: I guess the new pvr driver eventually.. although it would help to get DRM support into the kernel in a sane way for non PCI systems..
[02:48] <cooloney> rsalveti: nothing new here.
[02:48] <cooloney> rsalveti: i got the same result like you
[02:49] <cooloney> 2G:2G split to disable highmem
[02:49] <rsalveti> robclark: that's for sure..
[02:49] <rsalveti> robclark: was thinking for maverick, how we're going to deal with people changing monitors, and even when we can't probe the correct edid when booting
[02:49] <rsalveti> the case of my monitor
[02:50] <rsalveti> cooloney: for me it's quite stable with 2G:2G, no highmem and using just one cpu, or no L2
[02:50] <cooloney> yeah, that's ture
[02:50] <GrueMaster> Need at least a sane default.
[02:50] <GrueMaster> for monitor resolutions.
[02:50] <cooloney> rsalveti: but one cpu might not be acceptable, i think
[02:50] <rsalveti> GrueMaster: for default there's a bug currently for monitors that turns off and on during probe (my case)
[02:51] <GrueMaster> I hit the same thing with my HDMI switchbox.
[02:51] <rsalveti> that the screens turns 640x480 initially and then it changes to the correct one
[02:51] <rsalveti> probably the same bug
[02:51] <rsalveti> I'm looking at it now..
[02:51] <GrueMaster> Except mine stays at 640x480.
[02:51] <robclark> yeah, probably same bug
[02:51] <rsalveti> cooloney: probably not, even without L2
[02:52] <robclark> GrueMaster: pls send your edid.. /sys/devices/omapdss/display0/edid
[02:52] <cooloney> L2 will have some impact to the performance
[02:52] <rsalveti> that's the problem ...
[02:52] <cooloney> rsalveti: so there is not good solution now,
[02:52] <robclark> yeah, disabling L2$ or 1 cpu is not ideal.. but 768m has been relatively stable for me so far..
[02:52] <rsalveti> GrueMaster: yeah, can you paste your edid when using the switchbox?
[02:52] <cooloney> rsalveti: i also applied the patches in <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS>
[02:53] <cooloney> from stable tree
[02:53] <cooloney> got the same result
[02:53] <rsalveti> if we get a correct edid then it's just timing issues when probing the edid
[02:53] <III> hey all... is current build having any issues?
[02:53] <rsalveti> just if you're using omap 4
[02:53] <GrueMaster> Erm, is there a tool for reading this?  It looks like garbage.
[02:53]  * III is using omap4
[02:53] <rsalveti> GrueMaster: yep, binary
[02:53] <rsalveti> parse-edid
[02:54] <rsalveti> III: currently when using 1GB we get build issues when building the kernel
[02:54] <rsalveti> with highmem you can easily get it, without highmem you get it some times
[02:54] <rsalveti> if we disable L2 or use just one cpu, everything works fine
[02:54] <rsalveti> another workaround is to use 768MB (the one we're using now)
[02:55]  * III moves to older build :D
[02:55] <rsalveti> and if we don't fix it for the release, this will probably be the way to go
[02:56] <rsalveti> cooloney: the problem is that it's quite hard to trace it, I'm out of ideas
[02:56] <cooloney> rsalveti: me either, i tried to enable ftrace with dynamic tracing
[02:57] <cooloney> but it took me lots of time to get some useless information
[02:57] <rsalveti> it works fine with all mem stress software I use, but breaks when building the kernel
[02:57] <rsalveti> cooloney: but were you able to get something?
[02:59] <cooloney> rsalveti: i get function tracing information from the abort handler
[02:59] <cooloney> and it changes every time before the abort handler
[02:59] <rsalveti> cooloney: hm, can you paste it?
[03:00] <cooloney> i think we need another simpler test case
[03:00] <cooloney> rsalveti: np, man. let me find it. paste it to you guys
[03:00] <rsalveti> cooloney: sure, but I tested a lot of mem stress software and unable to reproduce the issue
[03:00] <robclark> GrueMaster: can you email me the binary?
[03:00] <rsalveti> mem stress with disk io and etc, and nothing
[03:01] <cooloney> rsalveti: cool, what are those mem stress test cases?
[03:01] <GrueMaster> robclark: working on it.
[03:01] <robclark> k, thx
[03:01] <robclark> brb
[03:01] <rsalveti> the problem probably happens with mem + i/o + dma
[03:01] <GrueMaster> system is being real sluggish.
[03:02] <GrueMaster> (actually, all networked systems are).
[03:04] <cooloney> rsalveti: that combination is too complicated. sign
[03:04]  * cooloney brb
[03:04] <GrueMaster> http://paste.ubuntu.com/502398 - text version.
[03:04] <rsalveti> cooloney: maybe something at arch/arm/plat-omap/iodmm.c, uses l2...
[03:06] <GrueMaster> Gotta run.  I'm being drug away.
[03:06] <rsalveti> GrueMaster: the problem at bug 644714 is that the resolution is not changed at the x11 driver
[03:06] <ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
[03:07] <rsalveti> the fb is changed with latest code from robclark, but not x11
[04:07]  * rsalveti out
[05:41] <III> does anyone know of a good working build I can use? I just tried  20100926 and 20100927 but I am not able to boot.. anyone else seen this issue?
[05:41] <III> sorry that is for OMAP4
[05:48] <persia> What issue do you see booting?
[05:52] <III> seems to hang on boot
[05:54] <III> take that back... seems to boot in to busybox
[05:57] <persia> Ah, good.  Not booting is complex.  Any messages before being dumped to a busybox prompt?
[05:59] <III> no init found... I'm trying again but with a new card.
[05:59] <persia> I had that on an upgrade, and was certain it was PEBKAC (and it was omap3), but maybe it wasn't.
[06:02] <persia> ogra, So, it might be nice to have manifest files also for non-omap4 preinstalls :)
[06:07] <persia> III, Hrm.  Please let me know if it works/doesn't work with the new card.  Seems 20100927 has the latest upstart, sysvinit, initramfs-tools which are the bits that are immediately suspicious (but the changelogs don't show anything worrisome).
[06:07]  * persia waits for rsync for 20100927/omap for a parallel test
[08:19] <ogra> persia, ??
[08:20] <persia> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ : note the number of .manifest files
[08:20] <ogra> oh
[08:20] <ogra> did NCommander kill acorn again with extenbsive dove builds ? :=
[08:20] <persia> I thought you were the person who put them in, and don't happen to know which bit to frob for that
[08:20] <ogra> :P
[08:21] <ogra> persia, manifers files are installed some point around bootloader install ;)
[08:21] <persia> My issue isn't the lack of ...0928 images (although that's frustrating), but the lack of a manifest for the images that are posted.
[08:21] <persia> And bootloader is broken for omap?
[08:21] <ogra> the images without bootloader logically have no manifest (and no partition table either)
[08:21] <ogra> was broken
[08:21] <ogra> without a livefs i cant tell
[08:22] <ogra> i would expect that archive to have settled by now though
[08:22] <persia> On the 27th?  There *is* an omap livefs (or something using 509M compressed)
[08:22] <ogra> wintout bootloader partition
[08:23] <persia> Aha!
[08:23] <hrw> morning
[08:23] <ogra> just on a sidenote i have debian lenny running natively on the ac100 (with the existing kernly only somethin that old (and without update) works)
[08:23] <persia> Would that also be why III couldn't boot?
[08:24] <ogra> no, didnt affect omap4
[08:24] <persia> Excellent!
[08:24] <persia> Dunno then.
[08:24] <ogra> i cant ifup the wlan card though
[08:24] <ogra> something is blocking
[08:24] <persia> driver issue?
[08:24] <ogra> no, premission issue
[08:24] <ogra> *per
[08:24] <ogra> god, i cant type tofay
[08:25] <ogra> *today
[08:25] <NCommander> ogra: it was still running when it spit out hte last image
[08:25] <NCommander> ogra: I need a package merged :-)
[08:26] <ogra> NCommander, i was making a bad joke :)
[08:26] <NCommander> can you review the patch so I can get the feature freeze exception?
[08:26] <ogra> NCommander, post RC ?
[08:26] <NCommander> ogra: bah, now I know this is reality. the real ogra doesn't joke :-/
[08:26] <NCommander> ogra: its critical enough that I want to at least run it by the release team
[08:26] <NCommander> ogra: if it flops, it flops, but I have to at least *try*
[08:27]  * NCommander wants his ubiquity bug fixed :-/
[08:27] <ogra> you can start uibiquity from the terminal, right ?
[08:27] <NCommander> ogra: well, yes, but that's less than ideal
[08:27]  * ogra wants his "rootfs fillt to 100% wint encrypted home" bug fixed ... but i wouldnt risk RC for that
[08:28] <persia> ogra, Did you make a patch for that yet?
[08:28] <ogra> thats really something you can release note
[08:28] <ogra> persia, nope
[08:28] <persia> It's a trivial patch, if you want to test it.
[08:28] <ogra> but i expect to have one before end of the week
[08:28] <persia> Ah, OK.
[08:29] <ogra> oh,you worked on it already ?
[08:29] <persia> Only in the sense of the IRC session a few days ago.
[08:29] <ogra> sure i'll test :)
[08:29] <ogra> ah, k
[08:29] <persia> But it's < 15 lines of code :)
[08:29] <ogra> yep
[08:32] <ogra> NCommander, i'll review it (and nod it off if its ok) later today ... but i wouldnt push for getting it into RC (get it to the queue though)
[08:35] <ogra> NCommander, the changelog disagrees with the change in your branch
[08:35] <ogra> NCommander, scripts/casper/47une_ubiquity is missing completely
[08:35] <NCommander> ogra: argh, i readded tha tand push it
[08:35] <NCommander> Hold on
[08:36]  * NCommander goes to get pants so I can turn the Dove on
[08:36] <ogra> NCommander, also dont forget to check for executability (i cant see that in the LP UI) i dont remember which files need to be executable and which dont
[08:36] <ogra> is your dove on the balcony ?
[08:40] <NCommander> ogra: no, I'm just living in a place that if I walk to the room where the board is without pants, someone will scream
[08:40] <ogra> the board is without pants too ?!?
[08:40] <ogra> geez !
[08:40]  * NCommander decides to discontinue this line of conversation
[08:41] <ogra> check the quotes page :P
[08:42] <NCommander> damn it
[08:42] <NCommander> ogra: re-pushing. bzr hates me
[08:42] <NCommander> (I miss git)
[08:43] <ogra> bzr add isnt that hard :)
[08:44] <NCommander> ogra: I just forgot to bzr push
[08:44] <NCommander> ogra: its there and executable
[08:44] <hrw> NCommander: there is git-bzr-ng project on github to provide "git bzr" plugin
[08:44] <hrw> NCommander: I use it to manipulate bzr repos but so far failed to push with it
[08:47] <ogra> NCommander, so why do you apt-get remove ?
[08:47] <ogra> NCommander, i would bet it slows down booting a lot
[08:47]  * ogra would just have removed the diversion instead of waiting for the package DB
[08:48] <NCommander> ogra: because it also removes the desktop file oem-config installs asking to finalization the installation
[08:48] <NCommander> ogra: well, I wanted to remove it during image building :-P
[08:49] <ogra> NCommander, well, your call, butu i'D say it surely adds 10-20sec to the boot
[08:49] <ogra> and ubiquity will remove it anyway
[08:49] <NCommander> ogra: didn't see that bad, and ubiquity doesn't remove it until AFTER installation
[08:49] <NCommander> Kinda confusing to have it there before you install
[08:49] <NCommander> *seem
[08:50] <ogra> whats confusing about it ?
[08:50] <NCommander> if you want a livecd-rootfs patch, I already have one of those, though its not quite as tested (I can fix that though now)
[08:50] <ogra> the user never sees it
[08:50] <NCommander> ogra: er, yes theydo?
[08:50] <NCommander> Its right therein Settings.
[08:50] <ogra> no, i dont want to tinker with livecd-rootfs
[08:50] <ogra> NCommander, where do you test for the arch ?
[08:50] <ogra> i dont see any code for that
[08:51] <ogra> currently your patch breaks all oem installs
[08:51] <berco> good morning all
[08:51] <NCommander> ogra: no it won't, because OEM installs don't install eom-config until after installation which doesn't use casper.
[08:52] <ogra> the action should be arch (or even subarch) specific
[08:52] <ogra> NCommander, i dont think thats true
[08:52] <berco> anyone knows if there's a particular issue with building webkit on arm?
[08:52] <ogra> NCommander, did you talk to superm1 about that ? i bet you break all dell installations with that
[08:53] <persia> berco, Shouldn't be.  What issue are you seeing?
[08:53] <ogra> (note i dont talk about the OSG team here but about oem's using modified images)
[08:53] <berco> persia: It fails all the time
[08:53] <berco> persia: wondering if not enough memory would be the issue
[08:54] <NCommander> ogra: you can't hav eoem-config in the same image as installed ubiquity with the later working properly since it will hide the installer icon
[08:54] <ogra> doesnt seem to fail for us ... http://qa.ubuntuwire.org/ftbfs/
[08:54] <NCommander> ogra: I *wanted* to remove in livecd-rootfs, you said remove it in casper
[08:54] <ogra> NCommander, well, every thought why superm1 added that diversion ?
[08:54] <ogra> NCommander, no, i said remove the diversion
[08:54] <NCommander> ogra: er, I think ev wrote that diversion
[08:54] <NCommander> ogra: and that's the wrong bloody solution
[08:54] <ogra> well, from casper, but you know what i mean
[08:54] <NCommander> The package shouldn't be there
[08:55] <ogra> the packages are there in some setups
[08:55] <ogra> there is an OEM who uses an automated preseeded ubiquity to create images with oem-install
[08:56] <NCommander> ogra: oem-config however is installed on fht elfy if its needed
[08:56] <NCommander> That's why its in ship
[08:56] <ogra> anyway, make it arch specific and i'll approve
[08:56] <NCommander> Looking at oem-config code, the postinst doesn't handle the case if the diversion is already there
[08:57] <ogra> i dont care if you fiddle with the diversion ... but i do care if you make it a default for everyone
[08:57]  * NCommander will sit down at do it a bit later then
[08:57] <ogra> remove it or remove the diversion ... as you like
[08:58] <ogra> but make sure people explicitly installing oem-config dont get screwed by it
[09:00]  * persia vaguely wonders why there are both "webkit" and "webkitkde" packages
[09:00] <persia> berco, Seems to build on the buildds: https://launchpad.net/ubuntu/+source/webkit/1.2.4-1ubuntu1/+build/1948880
[09:00] <persia> Might be RAM, might be missing patch.  Might be different version.
[09:02] <ogra> looks like KDE needs an older version
[09:03] <persia> That's not a good reason, but potentially.
[09:04] <ogra> NCommander, was a meta uploaded for the dove kernel ?
[09:07] <NCommander> ogra: no idea
[09:07] <ogra> i though you'd care ... thats why i talked about it in the meeting yesterday
[09:07] <ogra> though if you dont ...
[09:07]  * ogra shrugs
[09:08] <berco> persia: I was looking at that page too :). Argh!
[09:08] <ogra> will probably break d-i though
[09:08] <ogra> on dove
[09:09] <persia> berco, My recommendation would be to compare your build log to the build log on LP and find the point at which they differ: this will probably be a hugely valuable hint to getting the build to work.
[09:09] <berco> persia: do you know the board hubbard?
[09:09] <persia> Never heard of it.
[09:09] <berco> armel package was built on this board
[09:10] <berco> on Launchpad
[09:10] <persia> Oh, you mean https://launchpad.net/builders/hubbard ?
[09:10] <berco> yes sorry
[09:11] <persia> I believe that's a Freescale Babbage 3.0 board, but I could be mistaken.  Should be ~800MHz, ~512MB unless someone did something special compared with other implementations of that SoC I've seen.
[09:12] <ogra> yes, all buildds are babbage 3.0
[09:13] <berco> thanks
[09:20] <NCommander> ogra: patch added and pushed via bzr. I can test a respun image you want to confirm the updated code
[09:23] <ogra> NCommander, if Riddell allows ... triger a full set of armel then please
[09:24] <NCommander> ogra: Riddell gave me permission to respin ARM at will
[09:24] <NCommander> ogra: I meant a locally respun image
[09:24] <ogra> oh, yeah, test it
[09:25]  * NCommander groans
[12:32] <ogra> http://pandaboard.org/
[12:37] <hrw> ogra: yep.
[13:24] <NCommander> ogra: the patch seems valid, but I'm having testing issues due to instability
[13:25] <NCommander> ogra: I am going to commit a slightly newer version, and ask you to merge and handle getting the RC freeze exception, but hold off on the actual upload until I can get someone beside myself to reconfirm the test results
[14:09] <persia> Does anyone still use redboot-imx?  Can it be dropped from the archive?
[15:46] <GrueMaster> persia: our Lucid imx51 images use it.
[15:47] <GrueMaster> afaik
[15:48] <persia> GrueMaster, But do we need/want it in maverick?
[15:49] <persia> III, Just FYI, there's a 0929 image that ought be in better shape.
[15:49] <GrueMaster> True.  imx51 was disabled sometime around alpha 2-3.
[15:49] <GrueMaster> iirc
[15:50] <III> persia: thanks... just downloaded it
[16:00] <mpoirier> ndec: do you think you could get me access to some ABE routing documentation ?
[16:02] <rlameiro> mpoirier: you know, now ther is a #igep channel, could be easier to find igep testers now
[16:03] <ndec> mpoirier: hi... sorry I saw your email, but didn't have too much time to digg into this.
[16:03] <mpoirier> rlameiro: indeed, but I would really need to get a board.
[16:03] <ndec> mpoirier: why do you need this info?
[16:03] <rlameiro> mpoirier: If i was rich, i would buy you one :D
[16:03] <ndec> mpoirier: I am not sure which document you would need in fact
[16:05] <mpoirier> ndec: we are bound to repeat the current sound investigation on our other omap3 boards.
[16:05] <mpoirier> ndec: omap4 too for that matter.
[16:05] <ndec> mpoirier: ABE is OMAP4 only, this is a complete different solution for audio h/w on OMAP3
[16:05] <mpoirier> ndec: the more I understand, the better I can give meaningful information to your team.
[16:05] <ndec> mpoirier: sure...
[16:05] <mpoirier> ndec: I suspected that much.
[16:06] <mpoirier> ndec: I'm mostly interested by the process berco took to produce the omap4_sound_config.sh script.
[16:07] <mpoirier> those commands come from some sound data somewhere and that's what I'm after.
[16:07] <ndec> mpoirier: this file is produced by the audio dev team, not us. I will reply to your email.
[16:08] <mpoirier> ndec: cool - you're my contact into that world.
[16:09] <mpoirier> ndec: if I'd have some clue on how omap4_sound_config.sh and the SDP4430.conf were generated, I could help on my side.
[16:27] <GrueMaster> rsalveti: RE:  Bug 644714  I have another edid output that essentially is blank.  THis is what I get when the system wakes and no monitor is attached.  The bad thing is, Xwindows is garbage, which is why I recommended 1024x768 as a fallback.
[16:27] <ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
[16:27] <GrueMaster> I'll try to add the data after RC testing.
[16:30] <rsalveti> GrueMaster: yep, this would explain the issue
[16:30] <rsalveti> boot with edid -> 1440x900
[16:31] <rsalveti> then when it gets back, finds no edid -> 640x480
[16:31] <rsalveti> but the x11 continues to think the fb is 1440x900
[16:31] <GrueMaster> Well, 640x480 is absolute garbage.  looks like 4 screens side by side only partially drawn.
[16:31] <GrueMaster> Can't get a screen capture atm.
[16:32] <rsalveti> GrueMaster: I get this with my monitor: http://www.flickr.com/photos/rsalveti/4932601965/
[16:33] <GrueMaster> That is actually usable.  Mine is much worse
[16:33] <GrueMaster> I'll try to get a capture during testing.  Heavily into RC atm.
[16:34] <rsalveti> GrueMaster: np
[16:53] <robclark> hrw: is there some trick to install your cross compiler packages on a lucid box?
[16:53] <robclark> Package libmpfr4 has no installation candidate
[16:53] <hrw> robclark: http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ for amd64
[16:54] <hrw> robclark: i386 in next few days
[16:54] <robclark> perfect, amd64 is what I need
[16:54] <hrw> robclark: libmpfr4 is in maverick
[16:54] <hrw> robclark: maverick pacakges on p.c.c. are obsolete anyway
[16:54] <robclark> yeah.. but I was trying to use your maverick PPA on lucid..
[16:54] <robclark> let me try this other site instead
[16:55] <hrw> ppa is also obsolete
[16:55] <hrw> I just keep both because some toold use them
[16:55]  * robclark can't keep track of what isn't obsolete
[16:56] <hrw> for maverick: use maverick archive. for lucid: use what i just gave you
[16:56] <robclark> k, will do
[16:58] <robclark> ohh..  I think it's working :-)
[16:59] <mpoirier> rsalveti: you have a significant head start on b644714 due to your previous work on EDID.  Do you have the cycles to work on it or you'd be happy to offload it ?
[17:21] <rsalveti> mpoirier: I'm working on it today
[17:21] <mpoirier> ok
[17:21] <rsalveti> first debugging the issue when booting and activating/deactivating the hdmi with my monitor
[17:21] <rsalveti> and then the x11 part
[17:31] <GrueMaster> mpoirier: on the omap4 sound issue, this should probably be changed to libasound2 instead of the kernel, as libasound2 contains all the /usr/share/alsa/cards/*.conf files.
[17:31] <GrueMaster> Thoughts?
[17:32] <GrueMaster> I have the same issues with Beagle (omap) and now Dove A0.
[17:32] <mpoirier> humm... there is also a kernel portion of it.
[17:32] <mpoirier> the TI patch for omap4, and some work to differentiate card on beagle and others.
[17:33] <mpoirier> as you said, there will be a libasound2 part of it.
[17:33] <GrueMaster> Ok.  Guess I should file separate bugs for each system then.
[17:34] <GrueMaster> Or should we just track them all centrally?
[17:34] <persia> Better to have multiple tasks for one bug.
[17:34] <persia> "Also affects distribution ..."
[17:34] <mpoirier> is there a way do link two bugs in lp ?  i.e this bug will only be completed if that bug is completed...
[17:34] <persia> I should say "Please file one bug per platform, with as many tasks for each bug as are required to address the issue."
[17:35] <persia> mpoirier, Intentionally not (although debate continues on this subject)
[17:35] <GrueMaster> We either have one main bug and list all the kernels & asound, or one bug for each kernel.
[17:35] <GrueMaster> Oh, ok
[17:35] <persia> I think we should have one bug for each *board*, and list asound & relevant kernel for each.
[17:35] <GrueMaster> persia: That makes the most sense.
[17:35] <persia> Potentially list multiple kernels for a single board if it's supported by multiple kernels and multiple kernel maintainers want to apply the same class of patch (e.g. for omap3)
[17:36] <mpoirier> GrueMaster: I also think we should have a bug per board.  Otherwise bugs never get closed.
[17:36] <mpoirier> as persia indicate, the fixes will span multiple kernels.
[17:37] <persia> mpoirier, Only in cases where multiple kernels support a given board.  For some hardware (e.g. imx51), there may only be one kernel available.
[17:38] <persia> Ideally, this is a short-term thing, until linaro fixes things so that there is only one true kernel.
[17:54] <prpplague> http://www.elinux.org/Panda_Bamboo
[17:54] <prpplague> for anyone that is interested, the deadline for features for the bamboo board is october 8th
[17:55] <robclark> prpplague: IR receiver?
[17:55] <robclark> (and lasers... sharks with lasers)
[17:55] <prpplague> robclark: hehe
[17:55] <prpplague> robclark: i have IR on my list to look at
[17:55] <robclark> cool
[18:03] <persia> Talk of SATA was for a different extender, right?
[18:05] <prpplague> persia: still trying to figure that out
[18:05] <prpplague> persia: i'm considering dropping the second sd/mmc in favor of a 32GB eMMC
[18:06] <persia> Unless you can find a way to boot off that, I'd rather see a second SD/MMC.
[18:06] <prpplague> persia: boots fine
[18:06] <persia> Off a secondary eMMC?
[18:06] <prpplague> yea, same as blaze
[18:07] <persia> Oh, please do that then.  I'd dearly like to return to having a sane "install" path.
[18:07] <persia> And I'll have good arguments to do that if the Bamboo works with it :)
[18:07] <persia> (extra benefit: the same codepath would work for both panda and blaze, etc.)
[18:08] <bjf> GrueMaster, did that fsl-imx51 kernel show up for you yet?
[18:08] <GrueMaster> Not sure, will check.
[18:09] <bjf> GrueMaster, https://launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-608.20/+build/1978184
[18:11] <GrueMaster> I know it is listed on launchpad.  But until it shows up in http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/, it is more difficult to deal with, and it still isn't there.
[18:11] <bjf> GrueMaster, ok, trying to figure out where it's hung up
[18:11] <persia> If it's not published by the turn of the next hour, might ask if the release team has the publisher on manual.
[18:12] <GrueMaster> persia: This is for lucid-proposed.  Shouldn't be affected afaik.
[18:12] <persia> bjf, I haven't checked current performance, but it used to take 43-103 minutes to get from "built" to "available in the archive"
[18:12] <persia> GrueMaster, it's the *same* publisher.
[18:12] <bjf> persia, thanks for the info
[18:12] <GrueMaster> ah
[18:13] <GrueMaster> Well, since I'm deep into Maverick RC testing, it will have to wait until Late tomorrow/Friday for testing.
[18:14] <bjf> GrueMaster, np, mostly i'm just trying to make sure its available to you when you are ready to work it
[19:05] <lool> ogra: Around?
[19:31] <GrueMaster> Well, now this is odd.  Attempted to change only the font in une-efl, the system seems to have completely changed themes.  Very unusual.
[19:39] <hans2> Question: Is there any progress being made with suspend on imx51?
[19:45] <GrueMaster> A new kernel was uploaded yesterday, but I'm not sure what was changed in it.  It is currently pending publication after Maverick RC freeze is lifted.
[19:45] <ogra_ac> rc freeze for a lucid SRU ?
[19:45] <ogra_ac> GrueMaster, it should just go in
[19:46] <ogra_ac> should be in -proposed for testing if it has build
[19:48] <GrueMaster> Well, that's what I have been told.  I'm too busy with RC to go hunting for it.
[19:49] <GrueMaster> And the kernel team just keeps sending me links to launchpad where the packages are sitting.  Need it in lucid-proposed for apt-get to pull.
[20:05] <persia> GrueMaster, The acceptance queue is different from the publisher.
[20:05] <ogra_ac> lool, yes (as long as this tegra WLAN stays stable)
[20:07] <GrueMaster> persia: I don't really care about the background processes and the mechanisms that they work through.  What I do care about is when I get an email requesting me to test a kernel update in lucid-proposed, and people asking me why it isn't there for apt-get to work.
[20:08] <persia> GrueMaster, That's fair: it's sensible for the uploader to take responsibility for ensuring the upload ends up being distributed in the repositories.
[20:09] <GrueMaster> my point exactly.  :P
[20:11] <persia> Anyway, I'll continue to explain workflows and background processes and mechanisms as long as people ask questions.  Appropriate folk (e.g. bjf) might want to chase up on things.
[20:13] <GrueMaster> explaining them is fine, as long as they are also addressed to the people that should be able to do something about the process when it doesn't work.
[20:13] <bjf> persia, i'm interested in the workflows and background processes so i appreciate the info
[20:14] <persia> GrueMaster, Sorry then, I'll try to read more carefully and not mis-highlight.
[20:14] <GrueMaster> Don't get me wrong, I too am interested.  Just not when I have 1 day to test multiple releases on multiple platforms.  :P
[20:17] <persia> bjf, So, anyway, once LP gets a build, it submits it to the queue (e.g. https://launchpad.net/ubuntu/lucid/+queue ).  The queue has a few states, and things can be in one or another depending.  Nothing will land in the archives until it gets to Accepted (NEW and UNAPPROVED need manual action by an archive-admin).  Stuff in Accepted will be pushed to the archive each publisher run (typically once an ho
[20:17] <persia> ur: sometimes set to manual for release management purposes).
[20:18] <persia> bjf, So, find out where your package is: if it's not anywhere in the queue (including DONE), then something is odd with the LP build.  If it's in the queue, but not ACCEPTED or DONE, you need an archive-admin (and likely some associated paperwork).
[20:18] <persia> best place to find archive admins is #ubuntu-devel
[20:19] <persia> If it's been in ACCEPTED for a couple of hours or more, and it's around some special time in the Ubuntu Release schedule, you might check with the folk in #ubuntu-release to make sure the publisher is running.
[20:19] <bjf> persia, there isn't a way for me to check if the publisher is running without asking?
[20:21] <persia> I think only LOSAs can check, but there may be some other interface exposed.  You could ask in #launchpad, but I generally just assume it's running except when it clearly hasn't for about 3 hours.
[20:46] <dcordes-lib> Hi. Is anybody aware of fast mirrors to the arm preinstalled daily builds ?
[20:48] <persia> I believe they are all private.
[20:50] <dcordes-lib> Hm. Currently only getting around 50kB/s from cdima.ubuntu.com
[20:50] <dcordes-lib> but it might be the library hating me
[20:53] <dcordes-lib> ah seems to be a local problem really
[20:53] <dcordes-lib> 3,3MB/s now
[20:57] <persia> That's a much better speed :)
[21:00] <dcordes-lib> Bye
[21:17] <Neko> persia, all ubuntu boxes shipped, exactly the numbers from the email
[21:18] <persia> Neko, Cool.  Thanks for the confirmation.  Please let me know if anything isn't happening to your satisfaction.
[21:19] <Neko> I expect about a month while people get used to it
[21:19] <Neko> they all shipped with maverick+xfce but I assume the kde guys etc. will wipe it immediately
[21:21] <persia> Shipping with maverick will make lots of folk happy.  I hear markos_ is coming to UDS, and I suspect people will be asking questions there.
[21:39] <robclark> so quick question.. does dkms log to somewhere, so I can see *why* it failed to rebuild some module?
[21:45] <lool> robclark: perhaps in /usr/src?
[21:46]  * robclark looks
[21:49] <robclark> hmm.. src is there.. but don't see a log..
[21:51] <robclark> ok.. well, I think I figured out how dkms is invoked, so I can do this manually..
[21:52] <rsalveti> robclark: yep, /var something, let me see it
[21:52] <rsalveti> had the same question when I created the sgx package
[21:53] <rsalveti> make.log, something like that
[21:53] <robclark> rsalveti: the sgx package is the one I'm having trouble with ;-)
[21:53] <rsalveti> in my case it was /var/lib/dkms/powervr-omap3/<IP_ADDRESS>/2.6.35-22-omap/armel/log/make.log
[21:54] <rsalveti> robclark: well, I created only the omap 3 one :-)
[21:54] <robclark> ahh,  perfect.. found the log.. thx rsalveti
[21:55] <rsalveti> np
[21:55] <robclark> hmm.. tho the log has no errors..  I wonder why dpkg thought it failed when I tried to install new kernel?
[21:56] <rsalveti> robclark: can you paste the error you got?
[21:56] <rsalveti> could be that it couldn't find the proper headers for your kernel
[21:57] <robclark> http://paste.ubuntu.com/502859/
[21:59] <ndec> robclark: it looks like you are installing the wrong headers. the OMAP4 kernel should be linux-headers-2.6.35-903
[21:59] <ogra_ac> robclark, you are building omap3 stuff
[22:00] <robclark> ahhh...
[22:00] <ogra_ac> apt-get install linux-headers-omap4 iirc
[22:00] <rsalveti> robclark: yep, that should be your problem
[22:00] <ogra_ac> (there is a metapackgae for everything ;) )
[22:00] <rsalveti> even a meta of the meta
[22:01] <robclark> heheh
[22:01] <ogra_ac> heh
[22:02] <ndec> robclark: you probably want to remove the omap3 kernel and headers packages as well.. that said it's probably a bug in our sgx omap4 package... it should not try to build/install on non supported kernel
[22:02] <robclark> ndec: well.. I was just trying to install a self-built kernel, and keep the sgx stuff working..
[22:03] <ogra_ac> ndec, well, it also was a bug that foreign headers were installed at all
[22:03] <ogra_ac> thats fixed since a few days
[22:03] <ndec> robclark: argh... self built, you mean as ubuntu packages? or just uImage.
[22:04] <ndec> ogra_ac: cool
[22:04] <robclark> ndec: .deb...  make CROSS_COMPILE=... ... deb-pkg
[22:05] <ndec> robclark: ok. you will need to generate the headers too.
[22:05] <robclark> well... I guess headers should be same as what I already have... I just git pull'd the kernel-ubuntu tree from d.oz.o..
[22:06] <robclark> hmm.. I guess I shouldn't have tried to reboot
[22:07] <ndec> robclark: the next problem... will be that sgx module will likely not natively build if your kernel has been cross compiled... just fyi: native kernel compilation as .deb should take ~2.5 h on panda
[22:07] <robclark> :-(
[22:08] <robclark> fwiw, I am using the linaro cross compile toolchain to build kernel.. so same gcc version
[22:12] <ndec> robclark: the compiler is not the problem... but the generated tools and makefile during kernel build will assume cross compile. when compiling module natively with dkms, it's causing issues. I don't know all the details, but rsalveti or sebjan might know
[22:13] <robclark> doh..
[22:13] <robclark> modules are such a pain
[22:13] <robclark> but ok... I can cross compile the modules too
[22:16] <Neko> var/cache/fontconfig/99e8ed0e538f840c565b6ed5dad60d56-mipsel.cache-2 <-- what does mipsel mean?
[22:17] <Neko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501700 REALLY? "fixed in latest fontconfig"??
[22:17] <ubot2> Debian bug 501700 in fontconfig "writes cache files with "mipsel" in name .. on armel" [Minor,Fixed]
[22:22] <Neko> well now it says le32d8 or so which I guess is less retarded but.. why would the cache file need to be so arch specific like that.
[22:49] <persia> "mipsel" is little-endian MIPS


[00:45] <fling> What is the proper way of figuring out which patches are for shiftfs and onionfs and other lxd stuff?
[00:45] <fling> Is there a branch for this somewhere? Or am I supposed to grep git log
[08:31] <klebers> fling, we don't have feature branches in our git repos, for some of the changes you can run git log on specific locations, e.g. fs/shiftfs.c
[08:32] <fling> klebers: this is what I do but I also want to get related unionfs patches and any others
[08:32] <fling> I want the proper way of discovering them
[08:33] <fling> Are you saying it is impossible to filter out lxd related commits?
[08:34] <klebers> fling, it's hard to filter out everything that affects lxd because we also apply a lot of patches from the upstream stable branches, which could affect lxd without us including the changes as explicit feature request or bug fix for lxd
[08:36] <fling> I have stable upstream applied too
[08:37] <klebers> it's not impossible, but you need to know where's the code that are lxd related and run git log on them
[08:37] <fling> this is what I do all the time
[08:38] <fling> But it is not the proper way :D
[08:40] <klebers> yeah, unfortunately we don't have a better way to get this kind of information from the repo
[08:55] <luna_> gpiccoli: my Ubuntu boots with the 5.9 kernel now and ZFS drivers :)
[08:55] <luna_> it fixed itself with todays updates
[08:55] <luna_> so closed the bug
[11:27] <sem2peie> can someone say something about my problem or do I have to be satisfied with workarounds for the next years?
[11:27] <sem2peie> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895333
[11:28] <sem2peie> maybe sfroschee ?
[11:31] <jeremy31> sem2peie: sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927710
[11:33] <sem2peie> yes exactly that seems to be the same
[11:38] <gpiccoli> Great luna_, thanks for the heads-up =)
[11:40] <sem2peie> the link also contains a matching patch from the openwrt git
[11:41] <jeremy31> sem2peie: I can look at ath10k source later and see if the 5.4 can be patched using dkms
[11:55] <sem2peie> where the patch also enables "Atheros dynamic user regulatory testing" if I see it right
[11:55] <sem2peie> https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
[12:40] <sem2peie>  jeremy31 yes well i opened the ticket because i think it would be better if the patch was in the ubuntu kernel, there are some cards with 0x0 in the eeprom
[12:40] <sem2peie> 0x0 should be considered a widlcard and region free, no idea why Qualcomm is bitching (in the past it was no problem)
[12:41] <sem2peie> at the end of the day this only causes problems (frequencies that cannot be used or a too high transmission power)
[12:42] <sem2peie> or the cards cannot be used as AP because of the IR flag
[12:43] <sem2peie> they are well tested and in used worldwide
[12:48] <luna_> no problem
[13:03] <fling> Which repository/branch for latest 5.4 and 5.10?
[15:18] <fling> Which tree for 5.10 ?
[15:33] <arighi> fling, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/, branch 'master'
[15:35] <fling> arighi: thanks!
[15:44] <arighi> yw
[16:08] <fling> arighi: how to flip a symbol in defconfig for every architecture?
[16:09] <fling> arighi: for example to enable shiftfs by the default
[16:10] <arighi> fling, hm.. shiftfs should be already enabled for all the supported architectures
[16:10] <arighi> fling, but you can take a look at debian.master/config/config.common.ubuntu
[16:11] <arighi> change the option there and the config should be updated during the build
[16:12] <fling> arighi: sure but what is the right place to switch the default symbol value without debian directory? For example for enabling zfs or disabling reiserfs etc
[16:13] <arighi> fling, if you're going to use make directly (skipping the debian/ubuntu stuff) you can simply run a `make menuconfig`, then press '/' to search for a specific config name and then you can change it
[16:14] <arighi> oh wait, I think I understand what you mean
[16:14] <fling> arighi: sure but I want to change it in the sources
[16:14] <fling> just don't know the proper paths :>
[16:15] <arighi> fling, for example for SHIFT_FS, edit fs/Kconfig
[16:15] <fling> ok, thanks
[16:15] <arighi> and add "default m" for example
[16:15] <arighi> below the tristate line
[16:15] <arighi> that will affect all the architectures
[16:16] <fling> got it!
[16:16] <fling> How to figure out which commits are related to lxd? Is not there a good list?
[16:16] <fling> I don't like grepping for UBUNTU and shiftfs and overlayfs
[16:23] <sem2peie> do I see it correctly that the patches are already included in the 5.8 kernel? https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/log/?h=hwe-5.8&qt=grep&q=ath10k
[16:37] <arighi> fling, I think that information should be documented somewhere in lxd
[16:39] <arighi> fling, there's something here https://lxd.readthedocs.io/en/latest/requirements/, even if it doesn't tell you exactly which config options are required
[17:04] <fling> arighi: I'm not asking about config options but about ubuntu patches
[17:04] <fling> arighi: for example I know lxd can use shiftfs and ubuntu adds shiftfs patches to the kernel for this and overlayfs patches for it to work with shiftfs
[17:06] <sem2peie> gets better and better with 5.8.0-25-generic #26~20.04.1-Ubuntu is missing the complete midband > https://pastebin.com/D2NYBxBR
[17:06] <arighi> fling, hm... then I think the best way is to look at the git log and try to identify the SAUCE patches that are required by lxd (unless someone has a better idea...)
[17:07] <fling> this is what I did…
[17:07] <fling> just looking for the proper way :D
[17:26] <arighi> yup, that is the most "proper" way that I can see :)
[17:36] <fling> What does 'noup' mean in 'UBUNTU: SAUCE: (noup)' ?
[17:59] <arighi> fling, it seems that they're missing a reference to the upstream patch/commit, so maybe noup means something like "not upstream"? But I'm not really sure about that, personally I've never used that in an UBUNTU: SAUCE patch (and I haven't seen it used recently)
[17:59] <arighi> so I would say if they have 'noup' they're likely old patches (and probably you don't need them)
[18:37] <fling> arighi: but they are in the repo
[19:21] <tyhicks> fling: this isn't fool proof but you could look for patches with "SAUCE" in the subject line as those are typically out-of-tree patches that have been applied for some specific use case that Ubuntu is interested in
[19:22] <tyhicks> fling: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/log/?qt=grep&q=SAUCE
[19:22] <fling> tyhicks: this is what I've been doing from the beginning
[19:23] <fling> I picked ones with namespace, cgroup, shiftfs, overlayfs in the description
[19:23] <tyhicks> you might keep an eye on the ones with apparmor in the description, as well
[19:24] <tyhicks> LXD makes heavy use of AppArmor for container confinement
[19:24] <fling> hmmm ok, thanks
[19:24] <fling> n=0001 ; for c in whatever ; do git format-patch -1 --start-number $n $c ; n=$(($n+1)) ; done
[19:24] <fling> I'm extracting patches like this ^
[19:25] <fling> ^ but what can I use instead of this n number?
[19:25] <fling> I want something more persistent
[19:25] <fling> so if the patch is going to get upstreamed
[19:25] <fling> all other patches will keep their numbers when I will be extracting them after
[19:25] <tyhicks> sorry, I don't understand what the number is signifying here
[19:26] <fling> just an incrementan number
[19:26] <fling> first patch is 0001, second patch is 0002 etc
[19:26] <tyhicks> the persistent part is the subject of the patch but that's also not very persistent because it could easily change during the upstreaming process
[19:27] <tyhicks> you're working with out-of-tree patches that are not yet upstream which, by definition, do not have persistence
[19:28] <fling> tyhicks: I thought I could use date instead of this number but dates are out of order too
[19:29] <tyhicks> fling: oh, you also want to keep an eye out for SAUCE seccomp patches as the container folks are making use of seccomp for various features
[19:30] <tyhicks> stuff like this is for LXD: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=965dde940df5444bdcff23dad0e7e14e185842a0
[19:30] <fling> good catch
[19:31] <tyhicks> if Christian Brauner wrote it and it is applied to the Ubuntu kerenl tree, you need to take a look at it because there's a good chance that it is LXD related
[19:37] <fling> ubuntu-focal/master-next has way much more related SAUCE stuff in it compared to ubuntu-unstable/master
[19:37] <fling> I should investigate ubuntu-focal/master-next better


[18:00] <IdleOne> ircc meeting?
[18:00] <nhandler> Meeting time. jussi, topyli, elky, tsimpson ?
[18:01] <tsimpson> \o
[18:01] <jussi> o/
[18:01] <topyli> o/
[18:02] <jussi> right, who is chairing this thime?
[18:02] <jussi> time even
[18:03] <nhandler> I can I guess
[18:03] <nhandler> #startmeeting
[18:03] <MootBot> Meeting started at 12:03. The chair is nhandler.
[18:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:03] <nhandler> [TOPIC] Add eir to #ubuntu
[18:03] <MootBot> New Topic:  Add eir to #ubuntu
[18:03] <nhandler> [LINK] https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[18:03] <MootBot> LINK received:  https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[18:03] <nhandler> I added a long explanation on the wiki that I would suggest reading if you haven't already: https://wiki.ubuntu.com/IRC/IrcCouncil/IRCteamproposal#Add%20eir%20to%20%23ubuntu
[18:04] <nhandler> [LINK] https://wiki.ubuntu.com/IRC/IrcCouncil/IRCteamproposal#Add%20eir%20to%20%23ubuntu
[18:04] <MootBot> LINK received:  https://wiki.ubuntu.com/IRC/IrcCouncil/IRCteamproposal#Add%20eir%20to%20%23ubuntu
[18:05] <nhandler> So any comments on adding eir? This is only for #ubuntu for now, but if we find it beneficial, we could discuss adding it to other core channels in the future
[18:06] <jussi> nhandler: could you tell us in dot point for the benefits of eir? Is it just the auto ban removal and nagging?
[18:06] <topyli> i certainly like the autoexpiring bans
[18:06] <jussi> Also, you mentioned it notices -ops - people may object to that... (speaking from experience...)
[18:07] <nhandler> jussi: The main benefit is that you can set a comment/expiration date for bans/quiets/certain mode changes. This would make it easy to have certain bans automatically get removed (or have eir nag you) after a certain period of time (to avoid banning and forgetting)
[18:07] <jussi> I like that a ot
[18:07] <jussi> lot*
[18:08] <jussi> Im worried about potential issues with notices (people have complained in the past)
[18:08] <nhandler> jussi: It can notice a person/channel of our choice. And personally, I still think that notices about bans are something our OPs should be able to put up with. They can adjust their own bans on a per-ban basis, and this will hopefully help keep us from forgetting and having to do a mass ban clear every few months
[18:08] <nhandler> It might also provde helpful with the FloodBot bans
[18:08] <ikonia> is this as a supliment to ubottu's BT capabilities, or in place of
[18:08] <nhandler> ikonia: Supplement
[18:08] <jussi> ikonia: supplement
[18:08] <jussi> hehe
[18:08] <nhandler> Ubottu would still be used for tracking users over long periods of time
[18:09] <ikonia> so what's the short benifit it does beyond what ubottu does already ?
[18:09] <ikonia> (or I can go and read the link if that's easier)
[18:09] <jussi> ikonia: auto ban removal and better nagging
[18:09] <nhandler> ikonia: I'd read the link, but ubottu just nags after a week. With eir, I could have it nag me after a day, or auto-remove the ban after a month.
[18:10] <ikonia> so would the nagging in ubottu be disabled ?
[18:10] <tsimpson> yes
[18:10] <ikonia> (reading link now)
[18:10] <tsimpson> for #ubuntu anyway
[18:10] <nhandler> We would hopefully also get it so ubottu could parse the ban comments set in eir so we have them in the BT
[18:11] <ikonia> so we would set the ban comments in eir now ?
[18:11] <tsimpson> the bot would parse the comments you give to eir and put it into the BT
[18:11] <ikonia> can it do that now ?
[18:11] <jussi> I think we eventually will have this all in ubottu, but for now, this is best case
[18:12] <ikonia> the only benifit I'm reading is that it can auto remove bans
[18:12] <jussi> ikonia: I think tsimpson will have it working in pretty short order
[18:12] <ikonia> jussi: then I don't think we should be implementing something until it is working
[18:12] <ikonia> the comments in BT are quite important
[18:13] <tsimpson> ikonia: it does nagging better than ubottu does now, and it does auto-removal
[18:13] <ikonia> does it send a better pm ?
[18:13] <jussi> ikonia: it wont be implemented until it does, but we need to take the decision to implement it
[18:13] <ikonia> tsimpson: how does it nag better ?
[18:13] <ikonia> jussi: then I suggest not implimenting it and carring on with ubottu development
[18:13] <tsimpson> ikonia: because ubottu just nags after one week, and that's all it can do
[18:13] <jussi> ikonia: it can nag in different intevals than the standard one week
[18:14] <ikonia> I don't want more nagging (personally)
[18:14] <nhandler> ikonia: You can adjust how long it waits before nagging. Then, once it nags you can decide whether to change the expiration so it nags agin in another few days. It also includes the comment that was set (so you know what the ban was about)
[18:14] <IdleOne> Can the good part of eir be implemented into ubottu ?
[18:14] <IdleOne> parts*
[18:14] <nhandler> IdleOne: There has been a bug open for a few years about that.
[18:14] <jussi> IdleOne: as we said, thats the plan
[18:14] <tsimpson> we need to decide if we want to go ahead with eir before ubottu is modified to work with it
[18:14] <jussi> IdleOne: but for now, making this work is best case
[18:14] <ikonia> I don't see the benifit to adding a bot to work with a bot, when we have a working bot that can be developed
[18:15] <jussi> ikonia: the fix forworking with eir is small, the adding capability is large
[18:15] <nhandler> For one thing, we shouldn't need to or want to re-invent the wheel for every new feature we want
[18:15] <ikonia> unless ubottu is failing at delivering something, I don't see the need to add another bot
[18:15] <nhandler> ikonia: It is failing at delivering this functionality currently
[18:15] <ikonia> nhandler: which functionaltiy ?
[18:15] <ikonia> sorry, I' missing what ubottu is failing to deliver on
[18:16] <topyli> the autoexpiry, the configurable nags, as stated
[18:16] <ikonia> I don't feel ubottu is faiing
[18:16] <tsimpson> it fails at configuring the notification period and it fails at having the ability to remove bans/quiets automatically
[18:16] <ikonia> I'd live to see more work on the floodbot replacemnt that we are being held to randsom with at the moment
[18:16] <nhandler> ikonia: Basically, as can be seen by our long ban lists and our need to do a mass-clear every few months, people are setting and forgetting about their bans. ubottu will nag once after a week or so, but that is it. People often simply ignore this if they aren't quite ready to remove the ban or can't remember what it is.
[18:16] <ikonia> I don't want a bot to auto remove my bans
[18:16] <tsimpson> with ubottu, you get nagged after 1 week, and that's it
[18:17] <tsimpson> it doesn't check if it's a long term ban
[18:17] <tsimpson> it doesn't check if it should nag again
[18:17] <ikonia> nhandler: I don't personally want more nagging,
[18:17] <nhandler> ikonia: You can adjust that on a per-ban basis
[18:17] <ikonia> I don't appreciate the current nagging so a bot that nags more isn't a benifit to me
[18:17] <topyli> ikonia: this doesn't interfere with the floodbot development
[18:17] <ikonia> topyli: great
[18:17] <tsimpson> especially in #ubuntu, it's important our ops remove unneeded bans
[18:17] <jussi> nhandler: perhaps its worth providing an example of eir and what you might give it
[18:18] <nhandler> jussi: Usage examples are on http://freenode.net/eir.shtml
[18:18] <nhandler> That shows the various commands and examples on using them
[18:19] <ikonia> up to you guys of course, but for me this is a waste of effort and adding another layer of complexity for no real benifit (for me personally)
[18:19] <IdleOne> nhandler: does using eir change how I use chanserv.py or auto_bleh?
[18:19] <nhandler> IdleOne: No. Although you might want to use /aq instead of /at in auto_bleh and then use eir to set when the quiet should be removed
[18:20] <nhandler> /aq is a quiet, /at is a quiet auto_bleh removes after a 15 minute period (or whatever the user set)
[18:20] <IdleOne> so basically instead of ubottu messaging me for comment eir will be doing it. I just need to learn the new syntax for eir.
[18:20] <jussi> Is anyone still unclear on what eir does?
[18:20] <jussi> IdleOne: yup
[18:20] <ikonia> the links nhandler has provider are quite solid
[18:21] <ikonia> provided even
[18:21] <jussi> IdleOne: it has a few more options ;)
[18:21] <bazhang> nags more and autoremoves bans
[18:21] <IdleOne> I don't like the idea of auto removal of bans after 24 hours. I would like to see it extended to 7 days.
[18:21] <topyli> bazhang: it can nag less if you like :)
[18:21] <jussi> bazhang: not more, (well can be) but more configurabe
[18:21] <tsimpson> IdleOne: it won't auto remove by default
[18:21] <nhandler> IdleOne: If you read the defaults I suggested, it would simply nag after 24 hours, not autoremove
[18:21] <IdleOne> ok
[18:21] <IdleOne> sounds good to me
[18:21] <tsimpson> IdleOne: and it'll be completely configurable per ban/quiet
[18:21] <bazhang> IdleOne, does it affect chanserv.py?
[18:21] <nhandler> bazhang: No
[18:22] <IdleOne> bazhang: not that I can see right now
[18:22] <bazhang> nhandler, thanks
[18:22] <tsimpson> chanserv.py doesn't do auto-removal anyway, so it won't
[18:22] <IdleOne> tsimpson: yes it does
[18:22] <tsimpson> and eir works even if you /quit
[18:22] <IdleOne> seveas added a timed q and b
[18:23] <IdleOne> tsimpson: there is that, with chanserv we have to be online
[18:23] <nhandler> It is also worth noting (if you haven't already noticed) that eir is used and developed by staff in #freenode and #defocus
[18:23] <tsimpson> well then the same as auto_bleh, just don't use auto-removal parts
[18:23] <IdleOne> ok. I'm ok with testing eir.
[18:23] <nhandler> Do the defaults I noted look sane?
[18:23] <jussi> nhandler: to me they do
[18:24] <jussi> Perhaps its worth a defaults review next meeting
[18:24] <topyli> yes. we'll tweak if needed
[18:24] <IdleOne> yeah.
[18:24] <jussi> ölölölölölölllllllllöööööööööllllllllö
[18:24] <nhandler> jussi: I'd prfer to give it a month
[18:24] <jussi> err oops
[18:24] <nhandler> It will take some time for OPs to get used to it and start really using it
[18:24] <jussi> nhandler: fair enough
[18:25] <IdleOne> ubottu's BT will still be used?
[18:25] <nhandler> [VOTE] Try eir in #ubuntu for a month (default expiration of 24h, notices to -ops, and nag instead of autoremove by default)
[18:25] <MootBot> Please vote on:  Try eir in #ubuntu for a month (default expiration of 24h, notices to -ops, and nag instead of autoremove by default).
[18:25] <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
[18:25] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[18:25] <nhandler> +1
[18:25] <MootBot> +1 received from nhandler. 1 for, 0 against. 0 have abstained. Count is now 1
[18:25] <topyli> +1
[18:25] <jussi> +1
[18:25] <MootBot> +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2
[18:25] <MootBot> +1 received from jussi. 3 for, 0 against. 0 have abstained. Count is now 3
[18:25] <tsimpson> IdleOne: yeah, the only part of ubottu eir will replace is the nagging part, which is poor anyway
[18:25] <tsimpson> +1
[18:25] <MootBot> +1 received from tsimpson. 4 for, 0 against. 0 have abstained. Count is now 4
[18:25] <ikonia> whoaaa
[18:25] <ikonia> notices to -ops ?
[18:26] <ikonia> I thought we'd been through the notices to -ops stuff as jussi called out ?
[18:26] <IdleOne> does eir send me notices or msg
[18:26] <nhandler> It is really no different than what OPs /should/ already be doing (notifying when they set/remove a ban)
[18:26] <nhandler> IdleOne: I can't remember. I can check in a minute
[18:26] <IdleOne> notices sometimes get lost with xchat.
[18:26] <ikonia> does it send notices to the channel, or pm's as ubottu does
[18:27] <tsimpson> a ban can, and should, be removed by another ops
[18:27] <tsimpson> people don't "own" bans
[18:27] <IdleOne> it is supposed to send to it's own window but doesn't always
[18:27] <ikonia> sorry, I didn't pickup on the notice to -ops stuff earlier, I thought jussi had covered it off
[18:28] <ikonia> (not seen any discussion on this on the mail list, have I missed it) ?
[18:28] <IdleOne> tsimpson: sometimes it is hard to decide if a ban set by another op can/should be removed as comments are not always available
[18:28] <tsimpson> eir will have the comment for the ban
[18:29] <IdleOne> tsimpson: what i mean is that not all ops comment bans
[18:29] <tsimpson> and other comments will still be in the BT
[18:29] <ikonia> sorry, I don't think this should be implemented until eir can sync with BT
[18:29] <ikonia> storing comments in two places is not good.
[18:29] <jussi> ikonia: it wont be!
[18:29] <ikonia> jussi: won't what ?
[18:30] <jussi> be implemented until that happens, but we need to decide to do the work
[18:30] <ikonia> apologies if I'm missing something obvious
[18:30] <ikonia> jussi: ah, now I see what you're saying, sorry
[18:30] <jussi> :)
[18:30] <tsimpson> I'm certainly not going to hack on ubottu if we aren't even going to use eir
[18:30] <ikonia> I thought you where suggesting it won't be implimented until the bot is implimented
[18:30] <jussi> aye ;)
[18:31] <ikonia> implemented even
[18:32] <niko> uBOTu-fr used something similar to eir
[18:33] <nhandler> Hello mquin. We were talking about adding eir in #ubuntu. One concern was that it uses notices to notify the OP channel instead of normal MSGs. I know there was a reason for that and was hoping you could explain
[18:33] <jussi> o/ mquin
[18:35] <mquin> nhandler: it uses notices when responding to events on irc - normal behaviour as per the original RFC
[18:36] <nhandler> Ah, ok. I thought it was something like that but I wasn't positive
[18:36] <IdleOne> so instead of the op who set the ban getting a notice, a generic notice to the channel will be sent and an active op can review the ban?
[18:36] <ikonia> jussi: so how does that fit in with the request from operators for ubottu to not notice the channels ?
[18:36] <nhandler> IdleOne: The OP setting the ban will get a message sent privately to them requesting a comment be set
[18:37] <IdleOne> nhandler: I am asking about when the ban "expires"
[18:37] <ikonia> ah, so the message won't go to the channel, cool
[18:38] <IdleOne> sorry if I am not understanding or making myself clear on what I am trying to understand :)
[18:38] <jussi> right, so shal we quickly now cover the standing items and move on? We can return to this at the tail end of the meeting
[18:38] <nhandler> [ENDVOTE]
[18:38] <tsimpson> we can just agree that in theory we want eir
[18:39] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[18:39] <tsimpson> and if we get the kings worked out, we'll use it
[18:39] <tsimpson> *kinks
[18:39] <tsimpson> there are no kings in eir ;)
[18:39] <nhandler> [AGREE] We want eir, but need to look into integration with ubottu and the notices
[18:39] <nhandler> [TOPIC] Standing Items
[18:39] <MootBot> New Topic:  Standing Items
[18:39] <nhandler> I don't see any new bugs
[18:40] <jussi> nor I.
[18:40] <topyli> i haven't done the stats, just realized
[18:41] <jussi> So, the bug parsing in #u?
[18:41] <nhandler> For actions, tsimpson was to enable bug parsing for #u, topyli was going to do stats for the trial period, elky was to send the email, jussi was to document some namespace limits, tsimpson was to update the wiki re:cloaks, send email, and talk to staff
[18:41] <tsimpson> done, done, done, and done
[18:42] <nhandler> Awesome tsimpson !
[18:42] <topyli> not done
[18:42] <jussi> I havent yet documented that, but Ive got thpoughts together. will attempt to get it don this week.
[18:42] <nhandler> [ACTION] jussi to document thoughts on namespace limits
[18:42] <MootBot> ACTION received:  jussi to document thoughts on namespace limits
[18:42] <nhandler> [ACTION] topyli to do stats for trial ubottu period (re: bug parsing in #ubuntu)
[18:43] <MootBot> ACTION received:  topyli to do stats for trial ubottu period (re: bug parsing in #ubuntu)
[18:43] <topyli> i figure i'll still do the stats for two weeks, as per the original plan
[18:43] <nhandler> Sounds good topyli
[18:43] <nhandler> And it looks like elky sent the email
[18:43] <tsimpson> topyli: just do the stats from enabling to now, a larger dataset gives more accurate results
[18:44] <topyli> true
[18:44] <nhandler> I'll handle the post-meeting tasks
[18:44] <nhandler> [ACTION] nhandler to do post-meeting tasks
[18:44] <MootBot> ACTION received:  nhandler to do post-meeting tasks
[18:44] <nhandler> [TOPIC] Change Ubuntu IRC Members to restricted
[18:44] <MootBot> New Topic:  Change Ubuntu IRC Members to restricted
[18:44] <nhandler> jussi: Care to summarize the issue breifly?
[18:45] <jussi> We have random people applying to the team, and no one putting names on the agenda. if people want to apply, the proceedure is put names on the agenda
[18:46] <jussi> No need to have it so randoms apply to the LP team
[18:46] <nhandler> I tend to agree. It is not too much work to manually add accepted members to the team afterwards
[18:46] <jussi> (as most know, there are people who randomy apply to lots of different teams)
[18:46] <jussi> nhandler: also, this is what we do for cloaks (almost)
[18:47] <nhandler> Yep
[18:47] <topyli> agreed
[18:47] <nhandler> Any other thoughts on this?
[18:47] <jussi> lets vote
[18:47] <nhandler> [VOTE] Make Ubuntu IRC Members team restricted
[18:47] <MootBot> Please vote on:  Make Ubuntu IRC Members team restricted.
[18:47] <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
[18:47] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[18:47] <nhandler> +1
[18:47] <MootBot> +1 received from nhandler. 1 for, 0 against. 0 have abstained. Count is now 1
[18:47] <jussi> +1
[18:47] <topyli> 01
[18:47] <MootBot> +1 received from jussi. 2 for, 0 against. 0 have abstained. Count is now 2
[18:47] <topyli> +1
[18:47] <MootBot> +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3
[18:48] <jussi> tsimpson: *prod*
[18:48] <tsimpson> +i
[18:48] <tsimpson> i?
[18:48] <tsimpson> +1
[18:48] <MootBot> +1 received from tsimpson. 4 for, 0 against. 0 have abstained. Count is now 4
[18:48] <topyli> :)
[18:48]  * tsimpson closes his codez
[18:49] <nhandler> [ENDVOTE]
[18:49] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[18:49] <nhandler> [AGREED] Make Ubuntu IRC Members Restricted
[18:49] <MootBot> AGREED received:  Make Ubuntu IRC Members Restricted
[18:49] <nhandler> Does someone want that action (and to update the wiki pages regarding getting membership)
[18:50] <tsimpson> we should also reject the pending members while we're at it
[18:50] <nhandler> tsimpson: +1
[18:50] <topyli> the !wannabeanop factoid (or similar) also refers to an old blog post of mine, which will now be inaccurate
[18:51] <nhandler> I can take this action I guess
[18:51] <bazhang> canibeanop
[18:51] <tsimpson> topyli: that's different thing though
[18:51] <nhandler> [ACTION] nhandler to change Ubuntu IRC Members Team to restricted, reject pending members, and update wiki and factoids
[18:51] <MootBot> ACTION received:  nhandler to change Ubuntu IRC Members Team to restricted, reject pending members, and update wiki and factoids
[18:51] <tsimpson> IRC Member Vs IRC Operator
[18:51] <topyli> oh yeah
[18:52] <bazhang> what's the distinction?
[18:52] <nhandler> bazhang: IRC Members are Ubuntu Members but you get membership via the IRCC
[18:52] <jussi> bazhang: member is ubuntu member through irc contributions
[18:52] <tsimpson> nhandler: but not IRC operators
[18:53] <tsimpson> just making that clear from the above
[18:53] <nhandler> [TOPIC] Document expected behavior of people wearing ubuntu/member/* cloaks
[18:53] <MootBot> New Topic:  Document expected behavior of people wearing ubuntu/member/* cloaks
[18:53] <bazhang> so no membership for non-member ops
[18:53] <bazhang> ie restricted
[18:53] <nhandler> rww doesn't appear to be here
[18:53] <jussi> So looks like rww isnt about. do we have background on whats being asked here?
[18:53] <tsimpson> bazhang: all restricted means is that people who want to join have to do it properly, rather than just applying to the team and nothing else
[18:53] <IdleOne> I think I can talk a little about it
[18:53] <tsimpson> like people randomly joining LP teams
[18:53] <bazhang> tsimpson, okay thanks
[18:54] <nhandler> Not really. But my feelings tend to be that if someone is not acting appropriately with an Ubuntu Member cloak, it might be best to have the CC involved.
[18:54] <IdleOne> basically what rww asked was what the expected behaviour of an @ubuntu/member is when not in Ubuntu forums/IRC/Email
[18:55] <nhandler> It looks like topyli can present rww's item, but he has to run to the store. So we are going to quickly swap the last two items
[18:55] <nhandler> [TOPIC] #ubuntu-ops-team creation
[18:55] <MootBot> New Topic:  #ubuntu-ops-team creation
[18:55] <tsimpson> well, as an Ubuntu member in general, you have signed the CoC and agreed to abide by it
[18:55] <tsimpson> but we aren't going to police other IRC channels
[18:55] <tsimpson> remember that you *are* representing Ubuntu though
[18:55] <nhandler> jussi: You are up
[18:55] <IdleOne> tsimpson: the question is how far does that accountability extend
[18:56] <nhandler> IdleOne, tsimpson: We will come back to this
[18:56] <IdleOne> k
[18:56] <jussi> nhandler: I think this has been pretty well discussed on the ML, and has had enough time there
[18:56] <jussi> also discussed in -ops iirc
[18:57] <IdleOne> it was
[18:57] <nhandler> I'm still against this item. I think instead of moving the innappropriate comments to a private channel, we should be encouraging ours OPs to step away from the keyboard when they feel the desire to make such a comment
[18:57] <jussi> Unless there are objections, Im happy to just vote on it.
[18:58] <bazhang> nhandler, indeed
[18:58] <ikonia> nhandler: do freenode have any private channels ?
[18:58] <bazhang> its fine to feel frustrated, natural even.
[18:58] <ikonia> nhandler: (for staff to discuss issues)
[18:58] <tsimpson> it's more of the case where trolls are actively reading the -ops log to bait our ops
[18:58] <bazhang> but going off should be discouraged
[18:59] <tsimpson> the new channel will be CoC compliant at all times, and still logged, but not publicly
[18:59] <IdleOne> tsimpson: and will be ops only/
[18:59] <IdleOne> ?
[18:59] <IdleOne> by ops I include ircc and cc
[19:00] <ikonia> if the known problem users where just dismissed without the whole sham of discussing their "ban removal" this issue can be dropped
[19:00] <jussi> IdleOne: ops + selected others (such as representatives from large loco chans)
[19:00] <tsimpson> yeah, but not just core channel ops
[19:00] <nhandler> So if such a channel were to be made, it wouldn't be used as a place for OPs to simply make inappropriate comments about trolls/other users that they just want to keep out of the public logs and it would simply be used for private OP-related discussions?
[19:00] <tsimpson> it will be +i (as I understand it)
[19:00] <IdleOne> jussi: I would like to suggest inviting a rep from each approved loco
[19:00] <jussi> yes
[19:00] <bazhang> no need for such a channel.
[19:00] <ikonia> nhandler: if it's used for stupid comments as you are suggesting then it's failed
[19:01] <jussi> nhandler: thats the point of having it logged for the CC
[19:01] <ikonia> bazhang: there wouldn't be if you could say "$X is being a problem again" without 10 known problem users emailing the CC to say "look at the bias, remove this op now"
[19:01] <IdleOne> I would hope we don't resort to "stupid" comments but for actual discussion on how to handle a problem user.
[19:02] <nhandler> I'd be willing to try it on the condition that if it really isn't being used appropriately (i.e. turns into an OP social channel or channel for making inappropriate comments or something similar) that we shut it down
[19:02] <bazhang> the problem is people staying up / moderating too many hours consecutively and getting short fuses
[19:02] <ikonia> I'm sure that can be part of it
[19:02] <bazhang> just take a break when it reaches that point.
[19:02] <IdleOne> bazhang: that is part of the problem
[19:03] <ikonia> bazhang: re-read what I put
[19:03] <ikonia> (or read if it was lagging)
[19:03] <IdleOne> but the log readers who msg you to instigate and bait don't help
[19:03] <ikonia> there is a larger issue that known problems users aren't just dismiseed
[19:04] <bazhang> ikonia, yes, I saw, but root4rded et all will pick on people no matter what we say. so best to step away when it gets to be too much
[19:04] <bazhang> we need to react less to said bait then.
[19:04] <jussi> nhandler: I dont have a probem with that - either shutting it down or removing those who refuse to comply with the rules.
[19:04] <ikonia> bazhang: it's not just about protecting the individual, I'd like to be able to warn you of a situation without the IRCC being mailed about it as showing bias, or some other silly issue that then has to be investigated according to policy
[19:04] <nhandler> bazhang: +1
[19:05] <bazhang> ikonia, fair point.
[19:05] <jussi> any other concerns?
[19:05] <IdleOne> also ircc should expect an email about r00t4rd3d being mentioned in this meeting
[19:06] <bazhang> who cares.
[19:06] <IdleOne> but that has nothing to do with anything
[19:06] <ikonia> IdleOne: that's a seperate issue that we have to go through these dances with these users knowing their intention
[19:06] <ikonia> bazhang: I'd love to say "agreed" but policy has to be followed
[19:06] <nhandler> [VOTE] #ubuntu-ops-team creation (with review of channel 2 weeks after creation)
[19:06] <MootBot> Please vote on:  #ubuntu-ops-team creation (with review of channel 2 weeks after creation).
[19:06] <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
[19:06] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:06] <jussi> +1
[19:06] <MootBot> +1 received from jussi. 1 for, 0 against. 0 have abstained. Count is now 1
[19:06] <topyli> +1
[19:06] <MootBot> +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2
[19:07] <IdleOne> plus1
[19:07] <nhandler> +1
[19:07] <MootBot> +1 received from nhandler. 3 for, 0 against. 0 have abstained. Count is now 3
[19:07] <tsimpson> +1
[19:07] <MootBot> +1 received from tsimpson. 4 for, 0 against. 0 have abstained. Count is now 4
[19:07] <nhandler> [ENDVOTE]
[19:07] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[19:07] <bazhang> so no idlers there either? or completely secret and hidden
[19:07] <nhandler> [AGREED] #ubuntu-ops-team creation (with review of channel 2 weeks after creation)
[19:07] <MootBot> AGREED received:  #ubuntu-ops-team creation (with review of channel 2 weeks after creation)
[19:07] <jussi> tsimpson: are you able to take care of the logging via ubottu?
[19:07] <nhandler> bazhang: The plan was +i
[19:07] <tsimpson> bazhang: invite only
[19:08] <tsimpson> jussi: I think so
[19:08] <nhandler> Who wants the actions to get this channel sorted out and send out the relevant emails?
[19:08] <nhandler> tsimpson: ?
[19:08] <jussi> me
[19:08] <nhandler> That works too ;)
[19:08] <topyli> :)
[19:08] <nhandler> [ACTION] jussi to get channel sorted out and send out necessary announcements
[19:08] <jussi> nhandler: tsimpson can take care of the logging
[19:08] <MootBot> ACTION received:  jussi to get channel sorted out and send out necessary announcements
[19:08] <bazhang> thanks for addressing my concerns.
[19:08] <nhandler> [ACTION] tsimpson to sort out the channel logging
[19:08] <MootBot> ACTION received:  tsimpson to sort out the channel logging
[19:09] <nhandler> Let's go back to rww's item
[19:09] <topyli> ok
[19:09] <nhandler> [TOPIC] Document expected behavior of people wearing ubuntu/member/* cloaks
[19:09] <MootBot> New Topic:  Document expected behavior of people wearing ubuntu/member/* cloaks
[19:09] <topyli> http://irclogs.ubuntu.com/2011/02/25/%23ubuntu-ops.html#t06:32
[19:09] <MootBot> LINK received:  http://irclogs.ubuntu.com/2011/02/25/%23ubuntu-ops.html#t06:32
[19:09] <topyli> rww requests an update to IRC/Cloaks on behaviour *outside* our namespace while wearing cloaks
[19:10] <nhandler> If it is outside our namespace, I would think the issue would fall to the CC rather than the IRCC (it is the same as an Ubuntu Member acting inappropriately on a non-Ubuntu website)
[19:11] <nhandler> If they decide the user is not acting appropriately and revoke the membership, we would obviously also revoke the cloak
[19:11] <tsimpson> I'd just say, be mindful that you are representing Ubuntu while wearing the cloak
[19:11] <topyli> i agree that cloak-wearing members do represent ubuntu in general though, even though this is not an irc issue as such. a reminder on the wiki page wouldn't hurt
[19:11] <ikonia> are you kidding me /
[19:11] <ikonia> half the developers wear ubuntu cloaks and swear in the ubuntu channels ?
[19:12] <tsimpson> it's really nothing more than just being an Ubuntu member, or using your @ubuntu.com address
[19:12] <nhandler> There is nothing that says you can't swear. It really depends on the context ikonia.
[19:12] <ikonia> you're worried about people outside our name space when it's actually going on within the name space
[19:12] <topyli> ikonia: obviously we behave appropriately to each channel
[19:12] <ikonia> really ?
[19:13] <ikonia> so there are ubuntu channels that allow bad language ?
[19:13] <ikonia> that's acceptable ( I thought the requirements for an official ubuntu channel where being drawn up)
[19:13] <tsimpson> #ubuntu channels are only required to abide by the CoC
[19:13] <nhandler> ikonia: Yes, just saying a swear does not violate the CoC. The closest thing iirc is the 'Be Respectful' part
[19:13] <tsimpson> everything else is opt-in
[19:13] <IdleOne> so if #ubuntu-* has a culture of cursing it's ok?
[19:13] <ikonia> really ?
[19:13] <ikonia> so if I say "fucking cool" now, that's acceptable ?
[19:13] <ikonia> as I think it's cool
[19:14] <ikonia> (I don't)
[19:14] <nhandler> ikonia: In what channel?
[19:14] <ikonia> this channel
[19:14] <jussi> No.
[19:14] <topyli> this is a public meeting :)
[19:14] <ikonia> how about in #ubuntu-devel
[19:14] <ikonia> topyli: apologies, it's an example
[19:14] <jussi> Id like to point out the language and subject part on the IRC guidelines
[19:14] <IdleOne> so what are the irc guidelines for?
[19:14] <ikonia> jussi: I know, that's why I'm so surprised
[19:14] <nhandler> Those are enforced in the core channels
[19:14] <tsimpson> randomly swearing in channels is not being respectful
[19:14] <nhandler> The CoC is for all channels
[19:14] <ikonia> nhandler: is this a core channel ?
[19:14] <nhandler> Yes
[19:15] <jussi> ikonia: its up to the chanops - there can be leeway given
[19:15] <ikonia> tsimpson: I agree, so again I ask #ubuntu-devel
[19:15] <ikonia> ooh my word how weak
[19:15] <tsimpson> I haven't seen anyone in there just random start swearing just because "they can"
[19:15] <topyli> ikonia: it's sad if -devel has a bad culture on that issue
[19:15] <ikonia> topyli: using swearing in conversation is not respectul
[19:15] <ikonia> oops, that was for tsimpson
[19:16] <jussi> We put the guidelines up, and to a large extent, we expect them followed. But just as some chans accept paastes, others have different tolerences on language,
[19:16] <ikonia> topyli: I agree, I just wonder why we are worried about representation outside out namespace but don't hold it inside
[19:16] <topyli> ikonia: let's hold it then. i'm not an op on -devel
[19:16] <nhandler> ikonia: Read what was said. The CC would be the folks to really deal with that
[19:16] <ikonia> nhandler: even inside out name space ?
[19:17] <ikonia> are the ubuntu IRC council responsiable for the whole of the ubuntu-* name space, or just core channels ?
[19:18] <tsimpson> the current issue is about behaviour outside of the namespace
[19:18] <ikonia> that doesn't stop you responding to my question
[19:18] <ikonia> as I'm raising the fact that we do not control behaviour within the name space
[19:19] <topyli> that's a different failure
[19:19] <tsimpson> ikonia: this has been explained to you a few times, the IRC council coordinate with other councils and their channels
[19:19] <nhandler> ikonia: We have the delegation from the CC and freenode for all of the namespace, but we also delegate some authority to the individual channel OPs
[19:19] <ikonia> or shall I drop it and we can move on
[19:19] <tsimpson> I'm not going to explain it yet again
[19:19] <ikonia> tsimpson: clearly you need to as it conflicts with nhandler's statment
[19:20] <ikonia> you ARE responsible
[19:20] <nhandler> ikonia: No it doesn't
[19:20] <topyli> hi rww :)
[19:20] <ikonia> I'll drop this then as it's clear you don't want to address it
[19:20] <tsimpson> if you think the IRCC should act without care or concern for another governing council, then I can only say I disagree
[19:20] <ikonia> tsimpson: not at all, I don't think that at all, but overall ownership is the council
[19:21] <topyli> rww: good timing. we were just discussing your item before moving on to ircc metaphysics
[19:21] <nhandler> So do we want to add a small reminder to the wiki page?
[19:21] <tsimpson> the CC owns everything Ubuntu, we are delegated from them to look after IRC land
[19:22] <ikonia> tsimpson: ok, that's as I understood it also
[19:22] <IdleOne> So how does the CC feel about swearing in some irc channels and not others?
[19:22] <rww> hey all, sorry I'm late >.>
[19:22] <tsimpson> the CC are mainly concerned with CoC compliance
[19:22] <ikonia> ok is bad language a Coc compliance ?
[19:22] <nhandler> Depends on the situation
[19:22] <ikonia> does it ??
[19:23] <ikonia> language is offensive or not
[19:23] <charlie-tca> I thought swearing was wrong if any person indicates they are offended by the language
[19:23] <tsimpson> it does, there have times where it has clearly been used to attack others been issues brought to them about
[19:23] <nhandler> charlie-tca: That is a big factor
[19:23] <ikonia> in what situation is "fuck" acceptable ?
[19:23] <tsimpson> ikonia: in #ubuntu, never, but that's because we chose to make it not acceptable there
[19:23] <bazhang> the programming language presumably
[19:24] <ikonia> in any ubuntu channel, what situation would "fuck" be acceptable
[19:24] <IdleOne> if a person appears to be really stressed out and needing of release I could tell them "Go fuck yourself" ?
[19:24] <nhandler> ikonia: If you have a particular situation you were offended by, we would be glad to review it (or refer it to the CC if necessary)
[19:24] <tsimpson> charlie-tca: indeed, if someone in the channel asks you to stop, you should respect that
[19:24] <ikonia> bazhang: touche'
[19:24] <ikonia> nhandler: I'm offended by any bad language in any ubuntu channel
[19:24] <bazhang> lets not abuse the rhetoric please
[19:25] <IdleOne> not trying to abuse I am asking a question to a specific circumstance
[19:25] <jussi> Peopes, I have other places to be, are we almost done?
[19:25] <topyli> i'm offended by the poor treatment rww's agenda item is getting
[19:25] <ikonia> topyli: agreed, I apologise
[19:25] <nhandler> Can I get an answer to my previous question about if we want to add the comment to the wiki page?
[19:25] <ikonia> and of course to rww
[19:26] <tsimpson> we choose in the support channels to not allow it, this is in addition to enforcing the CoC
[19:26] <IdleOne> nhandler: I think a comment to the wiki about remembering we represent Ubuntu as members would be fine
[19:26] <jussi> nhandler: ++1
[19:26] <tsimpson> I'm not going to get into a debate about which words may or may not be acceptable in a certain channel under an certain situation and in what context
[19:27] <ikonia> tsimpson: I'll drop it, carry on as normal, my apologies
[19:27] <nhandler> tsimpson, topyli: What do you think?
[19:27] <topyli> i think a general reminder about being a representative of ubuntu is in order
[19:27] <tsimpson> sure, that sounds good
[19:28] <topyli> rww: do you have anything in particular in mind for the page?
[19:28] <nhandler> [VOTE] Add note about representing Ubuntu as a member to the wiki page
[19:28] <MootBot> Please vote on:  Add note about representing Ubuntu as a member to the wiki page.
[19:28] <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
[19:28] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:28] <nhandler> +1
[19:28] <MootBot> +1 received from nhandler. 1 for, 0 against. 0 have abstained. Count is now 1
[19:28] <topyli> +1
[19:28] <MootBot> +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2
[19:28] <tsimpson> +1
[19:28] <MootBot> +1 received from tsimpson. 3 for, 0 against. 0 have abstained. Count is now 3
[19:28] <rww> I'm missing scrollback here, but I was originally told that CoC applies throughout freenode to people wearing ubuntu/member/* cloaks, hence the agenda item appearing. If /that's/ the case, it's rather more strong than a general reminder would imply (and if it's not the case, apologies for my lack of scrollback again)
[19:29] <MootBot> Private +1 vote received. 4 for, 0 against, 0 have abstained. Count is now 4
[19:29] <nhandler> [ENDVOTE]
[19:29] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[19:29] <tsimpson> rww: as an ubuntu member, you signed and agreed to abide by the CoC when representing Ubuntu
[19:29] <nhandler> [AGREED] Add note about representing Ubuntu as a member to the wiki page
[19:29] <MootBot> AGREED received:  Add note about representing Ubuntu as a member to the wiki page
[19:29] <nhandler> Who wants to add the note?
[19:29] <topyli> i can do it
[19:29] <rww> tsimpson: k, that works then.
[19:29] <nhandler> [ACTION] topyli to update wiki page
[19:29] <MootBot> ACTION received:  topyli to update wiki page
[19:30] <topyli> possibly with help from rww :)
[19:30] <nhandler> :)
[19:30] <tsimpson> suggestions for wording are appreciated :)
[19:30] <jussi> ok, Im off. Sorry to leave you all.
[19:30] <rww> I'll have a think once I stop juggling scrollback :)
[19:30] <nhandler> For the eir issue of notices, we will discuss this a bit more (as well as work on the ubottu integration). We'll send out an email before it gets added to the channel though.
[19:31] <topyli> jussi: we're through the agenda, so feel free :)
[19:31] <nhandler> Thanks for coming
[19:31] <bazhang> eir seems very uncontroversial at this point
[19:31] <nhandler> #endmeeting
[19:31] <MootBot> Meeting finished at 13:31.


[17:03] <CarlFK> installer-amd64 seems to be missing from http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/
[17:04] <CarlFK> it is in http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/ and http://archive.ubuntu.com/ubuntu/dists/artful-updates/main/installer-amd64/
[22:12] <cjwatson> That's simply because there haven't been any SRUs of debian-installer to bionic yet.
[22:12] <cjwatson> Compare https://launchpad.net/ubuntu/+source/debian-installer
[22:14] <CarlFK> cjwatson: got it.  thanks.