[00:25] <apachelogger> afiestas: didn't you have a patch for bug 898390
[00:41] <apachelogger> "Follow feature freeze"
[00:41] <apachelogger> I think I need to write you people a 101 on how to write work items :P
[00:42] <Kurdistan> hi channel
[00:43] <apachelogger> [kubuntu-members] Make sure https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting is up to date and easily found from kubuntu.org: TODO
[00:43] <apachelogger> [kubuntu-members] Document on above wiki page which packages are kubuntu specific: TODO
[00:43] <apachelogger> that is wrong
[00:43] <apachelogger> the reporting stuff should not be on the wiki to begin with
[00:43] <Kurdistan> gnumdk is netrunner repo?
[00:43] <Kurdistan> I think so
[00:43] <apachelogger> gnumdk?
[00:44] <Kurdistan> apachelogger, https://launchpad.net/~gnumdk/+archive/ppa
[00:44] <yofel> apachelogger: where should it be?
[00:45] <Kurdistan> apachelogger, it was dicsussion about gnumdk.
[00:45] <Kurdistan> and I think he have some to do with kubuntu based netrunner
[00:45] <yofel> ah, you mean ejat
[00:45] <Kurdistan> yofel, exactly.
[00:45] <yofel> yeah, looks like it was the package from there
[00:46] <apachelogger> yofel: help.ubuntu
[00:46] <yofel> apachelogger: well, *that* links to our page
[00:46] <apachelogger> wiki = contributors
[00:46] <apachelogger> help = users
[00:46] <yofel> ah wait
[00:46] <yofel> right
[00:46] <yofel> agreed
[00:46] <Kurdistan> I will be much more in kubuntu channel then before
[00:47] <Kurdistan> thats what I can give right now and easy packing
[00:47]  * yofel hugs Kurdistan
[00:47] <Kurdistan> only problem is uni :)
[00:47] <Kurdistan> but when I have time I will be here
[00:48] <Kurdistan> yofel, thats least I can do.
[00:48] <Kurdistan> kubuntu and kde is growing inside me
[00:48] <Kurdistan> I got loved with kde in 4.6.5
[00:49] <Kurdistan> if we can fix smal issue with kubuntu, it will på top of the top.
[01:12] <afiestas> apachelogger: mope
[01:12] <afiestas> *nope
[01:13] <apachelogger> afiestas: go fix it then :P
[01:13] <afiestas> nah
[01:13] <apachelogger> I mean, it worked before 4.8 (at least for markey) so the regression cannot that big
[01:13] <apachelogger> though rather annoying impact
[01:13] <afiestas> I didn't broke it :p
[01:15] <Kurdistan> what is the regression?
[01:16] <yofel> screen resolution getting reset on every login
[01:18] <Kurdistan> yofel, hmm. is it "kubuntu" specific or upstream?
[01:19] <yofel> upstream from what I know
[01:26] <Kurdistan> yofel, oki.
[01:26] <Kurdistan> hmm it seems one http://i.imgur.com/2u5qd.jpg is affected of this bug
[01:26] <Kurdistan> and this person does not use nvidia beta drivers
[01:26] <Kurdistan> latest stable nvidia with kde 4.8.0
[01:27] <Kurdistan> starting to think it can be kde/kubuntu bug
[01:28] <Kurdistan> problem accure when log in and log out
[01:44] <yofel> Kurdistan: hm, thinking of it, I've seen a black background issue in gtk apps sometimes, but it's like totally random and usually fixed by rebooting
[01:44] <yofel> it doesn't affetc Qt though
[01:44] <yofel> *affect
[01:47] <Kurdistan> yofel, yes it fixes with reboot
[01:47] <Kurdistan> or restarting x
[01:48] <Kurdistan> yofel, will try tomorrow if it effects qt
[02:44] <Kurdistan> bye channel. sleep.
[10:53] <Kurdistan> yofel, you hade right my friend this bug only effects gtk application.
[10:53] <yofel> lol
[10:53] <yofel> even ubuntu's software center agrees that KDE apps are supreme :D
[10:53] <yofel> http://people.ubuntu.com/~yofel/pics/softcent.png
[10:54] <Kurdistan> yofel, is there any bug-report about this?
[10:54] <yofel> no idea, I haven't filed one because I couldn't figure any way out how to reliably reproduce that
[10:55] <Kurdistan> yofel, I have just reproduce it.
[10:55] <Kurdistan> is seems 3 person include me are all nvidia users also
[10:55] <yofel> ...
[10:55] <yofel> well, same for me
[10:55] <Kurdistan> yofel, can you log in/out let say 3 time?
[10:56] <Kurdistan> this will happen then
[10:57] <yofel> hm, ok
[10:59] <yofel> oh fun, happened on first logout
[10:59] <yofel> now what to file a bug against.....
[10:59] <Kurdistan> yofel, then this is a kde bug and not nvidia
[10:59] <yofel> well, file it against oxygen-gtk, maybe they'll know where to look
[11:00] <yofel> except that this isn't theme specific at all
[11:00] <yofel> could be a bug in gtk as well
[11:01] <yofel> but then it would be gtk2 and gtk3
[11:01]  * yofel is clueless
[11:01] <Kurdistan> yofel, same here.
[11:02] <Kurdistan> yofel, only fix is restart computer or restarting x.
[11:02] <yofel> hm
[11:02]  * yofel kills kdm
[11:02] <Kurdistan> yofel, you think it can be kdm related?
[11:03] <yofel> fixed
[11:03] <yofel> hm
[11:03] <yofel> as I said, I don't know. It could be anything that's related to gtk rendering
[11:05] <Kurdistan> can some one with other gaphical card test it?
[11:05] <Kurdistan> let se if it is nvidia only
[11:05] <Kurdistan> yofel, you are also running kde 4.8.0?
[11:06] <yofel> 4.8 precise
[11:06] <yofel> ah wait, I've an intel card in my eeePC
[11:07] <Kurdistan> yofel, okey, this can be kde 4.8.0 bug
[11:07] <yofel> I don't think so
[11:07]  * yofel throws the nvidia driver off his system
[11:08] <Kurdistan> yofel, I am chatting with slackware user now. let see if he have the same issue.
[11:10] <Kurdistan> yofel, this bug did not effect your eeePC with intel?
[11:13] <yofel> now let's see if I can reproduce this with nouveau without locking my GPU up...
[11:14] <Kurdistan> yofel, hehe good luck.
[11:20]  * yofel files a bug against nvidia
[11:21] <Kurdistan> yofel, so this was nvidia specific?
[11:21] <Kurdistan> you are a angel
[11:22] <yofel> intel: unreproducable, nouveau: unreproducable, nvidia 290: breaks after 1 or 2 tries
[11:22] <Kurdistan> yofel, remenber to mention
[11:22] <Kurdistan> also latest nvidia beta driver 295.17 breaks it
[11:23] <yofel> hm....
[11:23] <yofel> now I need a working browser that I can file this with...
[11:23] <yofel> -.-
[11:24] <yofel> konqueror to the rescue :D
[11:25] <Kurdistan> yofel, hehe
[11:27] <yofel> hm
[11:27] <Kurdistan> yofel, same problem with konqueror?
[11:28] <yofel> no, but some Qt applications are affected after all
[11:28] <yofel> ksnapshot looks broken here
[11:29] <Kurdistan> yofel, hmm. that was intressting.
[11:30] <yofel> but I can't find a patter there. ksnapshot is rendered like dolphin from your snaphot, but everything else seems fine
[11:30] <yofel> *pattern
[11:30]  * yofel digs throug nvnews
[11:33] <Kurdistan> yofel, can not find anything useful from nvnews
[11:33] <yofel> hm, why am I getting an nspluginviewer crash when I don't even have the wrapper installed o.O
[11:34] <yofel> ah, that's part of konqueror-nsplugins
[11:38] <Kurdistan> yofel, did you write bug-report for this to nvidia (nvnews)?
[11:40] <yofel> sry, filed a bug about nspluginviewer firt
[11:40] <yofel> *first
[11:43] <Kurdistan> yofel, take your time.
[11:44] <Kurdistan> I wonder if this is nvidia+kde 4.8.0 specific or not.
[11:45] <yofel> IIRC I've seen that with 4.7 too, so I rather thing it's an issue with the recent nvidia blobs
[11:46] <yofel> trying an older one might work, but X in precise is too new for that I think
[11:46] <yofel> on oneiric you could have a chance
[11:46] <yofel> Kurdistan: I've given up on nvnews. I'm horrible with captchas, add what you want on bug 930614
[11:48] <Kurdistan> yofel, thx like I mention also 295.17 (beta) drivers are effected
[11:48] <yofel> sure, and set the bug to confirmed while you're at it
[11:49] <Kurdistan> yofel, will do. lets se my password for launchpad.
[12:01] <Kurdistan> yofel, so fixed my password. now I will confirmed.
[12:07] <Kurdistan> yofel, done.
[12:46] <shadeslayer> Quintasan: I'm moving the telepathy kde packages into the team ppa
[12:48] <yofel> now... what did I want to do again when I woke up...
[13:19] <BluesKaj> Hey folks
[13:19] <Kurdistan> hi BluesKaj
[13:19] <BluesKaj> hey Kurdistan
[13:19] <Kurdistan> BluesKaj, you had nvidia card?
[13:19] <BluesKaj> yes
[13:19] <Kurdistan> https://launchpad.net/bugs/930614
[13:22] <BluesKaj> I haven't had any problems Kurdistan , and I have nvidia on 2 pcs runnining 12.04
[13:24] <Kurdistan> BluesKaj, have you tried login out/in
[13:24] <Kurdistan> ? 2-3 times in road
[13:24] <BluesKaj> i did yesterday
[13:29] <Kurdistan> BluesKaj, okey intressting.
[13:29] <Kurdistan> it affects me, yofel and some user in swedish loco.
[13:30] <Kurdistan> we all have kde 4.8.0 and nvidia cards
[13:30] <yofel> BluesKaj: used any GTK stuff after that?
[13:30] <yofel> as this mostly affects gtk
[13:33] <BluesKaj> yofel,  yes , synaptic, it doesn't accept text in the qquick search box , so one has to use the seperate search , but otherwise I haven't noticed anyhing
[13:33] <Tm_T> afiestas hmmm
[13:34] <BluesKaj> I can try relogging in
[13:34] <schnelle> Kurdistan, yofel: I am using opensorce ati drivers and I don't have that problems.
[13:34] <BluesKaj> schnelle,  this is nvidia
[13:34] <schnelle> but for me logout on opensorce ati drivers doesn't work by default
[13:34] <yofel> schnelle: yeah, seems to be nvidia blob only
[13:34] <Kurdistan> schnelle, it seems not effecting intel and ati then.
[13:34] <Kurdistan> only blob so far
[13:35] <Tm_T> afieastas' appmenu-"hud" thingy doesn't seem to work here /:
[13:35] <BluesKaj> ok ,brb I hope
[13:35] <schnelle> yes, but i want to say, by default logout doesn't work for me since... mmm ever. I have to edit kdmrc file and uncomment "TerminateServer=true" line
[13:36] <schnelle> so you can try to uncomment that line, reboot for change to take effect, and then logout/login to see does this tweak helps
[13:36] <yofel> that'll help
[13:36] <yofel> as we know that killing X helps
[13:37] <schnelle> yofel: why kubuntu doesn't ship this line uncommented by default?
[13:37] <schnelle> for many ati opensource users (and intel) logout doesn't work by default
[13:38] <schnelle> untill TerminateServer=true is uncommented
[13:38] <yofel> rephrase that: why does KDE ship that with false as default
[13:38] <Kurdistan> is there a fix for this?
[13:38] <yofel> Kurdistan: well, see what schnelle just said, and tell that the other person that's affected
[13:38] <Kurdistan> yofel, will try that.
[13:39] <schnelle> KUrdistan: you have to reboot after uncommeting the "TerminateServer=true" line
[13:40] <BluesKaj> all seems fine here , but I don't use much GTK , so I guess I'm not much help :)
[13:42] <yofel> apachelogger: what happened to your plymouth stuff?
[13:42] <Kurdistan> schnelle, thx will do.
[13:44] <schnelle> will precise use kdm or lightdm?
[13:45] <yofel> kdm I guess
[13:45] <yofel> I have no idea what the progress on lightdm is
[13:45] <Kurdistan> it this will fix the issue should we have this from start in 12.04?
[13:46] <Kurdistan> *if this
[13:46] <yofel> well, I would have to talk to the kdm devs why this is false in the first place, then see if we can consider that
[13:48] <schnelle> in my experience, with ati and nvidia proprietary drivers, logout works, with opensource drivers i have to uncomment that line to make logout work
[13:48] <yofel> works fine with nouveau and intel
[13:48] <Kurdistan> schnelle, my uncomment you mean remove # and were is kdmrc?
[13:48] <schnelle> yes
[13:48] <yofel> kdmrc is /etc/kde4/kdm/kdmrc
[13:48] <Kurdistan> I can not find it in .kde
[13:49] <Kurdistan> I see wrong dire... :)
[13:50] <Kurdistan> schnelle, I do not even have TerminateServer=true in kdmrc
[13:51] <schnelle> very strange
[13:51] <yofel> Kurdistan: can you pastebin your kdmrc?
[13:51] <schnelle> i have it on all my installations
[13:51] <Kurdistan> yofel, I will do.
[13:53] <Kurdistan> yofel, http://paste.ubuntu.com/837832/
[13:55] <yofel> Kurdistan: add the setting to the [X-:*-Core] section
[13:56] <Riddell> ideas and mentors needed for KDE..
[13:56] <Riddell> 13:36 < Teo`> Everyone, GSoC 2012 ideas time! If you have an idea that you want to see implemented by a student during GSoC, don't keep it to  yourself :D Please add it to the Ideas page http://community.kde.org/GSoC/2012/Ideas
[13:56] <Kurdistan> yofel, why does not I have this but schnelle ?
[13:57] <yofel> Kurdistan: no idea, your file doesn't have much to do with the default one
[13:57] <yofel> Kurdistan: see mine: http://paste.kde.org/278678
[13:57] <Kurdistan> yofel, damn that was real different
[13:58] <shadeslayer> I added one
[13:58] <shadeslayer> :P
[13:59] <Kurdistan> yofel, http://paste.ubuntu.com/837840/
[13:59] <Kurdistan> it should like this?
[13:59] <schnelle> Kurdistan, yofel: yes mine looks line yofel's too
[13:59] <yofel> I think yes
[13:59] <schnelle> *like
[13:59] <Kurdistan> thats wierd yours like different from mine
[14:03] <Kurdistan> brb rebooting
[14:03] <Kurdistan> and testing :)
[14:06] <BluesKaj> yofel,  your looks like a conf file
[14:06] <BluesKaj> yours
[14:11] <Kurdistan> it worked
[14:11] <Kurdistan> like a charm
[14:12] <Kurdistan> :) log out/login several time. np anymore.
[14:12] <Kurdistan> schnelle, :) you fixed it.
[14:12] <schnelle> for me this is "must do" for years ;)
[14:12] <Kurdistan> schnelle, hehe okey.
[14:14] <schnelle> i hope someone ( yofel :)  ) get in touch with kdm devs, and if they say that "it is safe", kubuntu could ship this as default
[14:15] <schnelle> there is no kdm channel on freenode
[14:15] <schnelle> it seems...
[14:18] <Kurdistan> schnelle, that would be wonderful if thats happens.
[14:18] <Kurdistan> it seems to work perfect here
[14:18] <Kurdistan> and I thought first it was nvidia driver bug
[14:18] <Kurdistan> :P was hard against nvidia in there channel
[14:20] <schnelle> Kurdistan: well, kdm + opensorce ati driver = logout never worked by default
[14:20] <schnelle> gdm + ati driver = always worked
[14:20] <schnelle> so i think it is kdm issue
[14:20] <Kurdistan> schmidtm, okey. i think you have right.
[14:20] <Kurdistan> it most be kdm issue
[14:20] <schnelle> but i am totally noob about this, so i am just guessing... :)
[14:21] <PaulW2U> Hi all, I think you're describing launchpad bug #651294 which is marked as fix released.
[14:22] <Kurdistan> schnelle, :P not so noob if you could solve this.
[14:22] <PaulW2U> But I have to make the kdm modification each time I installed Kubuntu. :o(
[14:22] <Kurdistan> PaulW2U, mine problem is not really that x crashers.
[14:22] <schnelle> paulW2U: me too
[14:22] <Kurdistan> it is problem with rendering issue after login for gtk mainly and some qt
[14:22] <PaulW2U> No I don't see a crash either but if you look at the duplicate reports ...
[14:23] <schnelle> yes but the solution is the same: uncomment "TerminateServer=true" line
[14:23] <Kurdistan> PaulW2U, will read.
[14:24] <Kurdistan> PaulW2U, it is more a kdm bug then xorg-server I think.
[14:28] <Kurdistan> :( boring now I have only one bug left on my system.
[14:28] <Kurdistan> that is application that are closed there icon still shows up. not always.
[14:28] <Kurdistan> :( what should I do if that fixes also.
[14:29] <Kurdistan> *panel bug
[14:33] <yofel> go install precise in a VM, although that works resonable well here....
[14:33] <BluesKaj> Kurdistan,  that panel bug has been around since 11.04 on my pc
[14:33] <Kurdistan> BluesKaj, yeah I know. :(
[14:34] <schnelle> Kurdistan: it is Qt bug. There is a ppa with patched Qt: ppa:hrvojes/qt
[14:34] <schnelle> upgrade qt from this ppa and panel bugs go away! :)
[14:34] <Kurdistan> BluesKaj, it seems not effect ati user. my parents computer did not have that problem if I remenber right.
[14:35] <Kurdistan> schnelle, does it work for you?
[14:36] <Kurdistan> then we should apply that patch.
[14:36] <schnelle> i wrote last night to kubuntu-devel last night and asked kubuntu-devs to include patches in precise
[14:36] <schnelle> Kurdistan: it works perfect
[14:36] <Kurdistan> schnelle, what was the response?
[14:37] <schnelle> it should be in for precise
[14:37] <schnelle> https://lists.ubuntu.com/archives/kubuntu-devel/2012-February/005794.html
[14:38] <schnelle> so, i am using patched qt from ppa:hrvojes/qt, and all panel bugs are gone
[14:40] <Kurdistan> schmidtm, were is the patch?
[14:41] <Kurdistan> kubuntu 12.04 will be bugg free for me. :)
[14:43] <schnelle> read my message from kubuntu-devel (link above), i explained everything about patches there :)
[14:44] <Kurdistan> schnelle, will read.
[14:44] <Kurdistan> I am trying the patch
[14:46] <BluesKaj> Kurdistan,  ok, I have 2 pcs with nvidia , so didn't know it had to do with the nvidia module
[14:46] <schnelle> when you  upgrade qt from ppa:hrvojes/qt, you have to reboot
[14:47] <Kurdistan> schnelle, will do. :) will only add ppa
[14:48] <tsimpson> reboot?! I'm tempted to throw !language at you..
[14:51] <Kurdistan> schnelle, will restart the laptop :). lets hope it fix the problem for me.
[14:57] <shadeslayer> Riddell: oh awesome, I'll check it out on rekonq master ( re kde bug 238303)
[14:58] <Kurdistan> schnelle, it works great.
[14:59] <schnelle> Kurdistan: yay! :) for me only veromix plasmoid was broken after upgrade. so i removed it and then i reinstalled it.
[15:00] <schnelle> no more panel bugs! :)
[15:00] <Kurdistan> schnelle, thx again.
[15:00] <shadeslayer> apachelogger: I believe that is by design
[15:00] <shadeslayer> ( re rekonq making the back button available only after the page loads )
[15:01] <shadeslayer> whee deadlock in rekonq
[15:02] <shadeslayer> and book
[15:02] <shadeslayer> s/book/boom/
[15:02] <kubotu> shadeslayer meant: "and boom"
[15:05] <apachelogger> yofel: oh, right, I should upload that
[15:05] <apachelogger> shadeslayer: then the design is broken
[15:05] <apachelogger> page loading can take looong
[15:05] <shadeslayer> apachelogger: then please tell that to the rekonq mailing list :)
[15:05] <shadeslayer> lemme find the exact commit for you
[15:09] <shadeslayer> hmm ... can't seem to find it, but I remember this was discussed somewhere
[15:09] <BluesKaj> so where's the patch ?, all I get is links to other related bugs
[15:10] <Kurdistan> BluesKaj, do you mean panel bugg?
[15:11] <Kurdistan> you have the patches here: https://launchpad.net/~hrvojes/+archive/qt
[15:11] <BluesKaj> Kurdistan,  yes
[15:11] <BluesKaj>  sometimes launchpad is the most annoying page
[15:12] <Kurdistan> BluesKaj, +1
[15:12] <Kurdistan> it fixed the problem for me. now even application launches faster
[15:12] <Kurdistan> :)
[15:18] <BluesKaj> Kurdistan, good , updgrading now
[15:19] <Kurdistan> BluesKaj, restart your computer after.
[15:20] <yofel> logging out is probably enough...
[15:20] <yofel> probably
[15:28] <Kurdistan> I hope every thing went good for blueskaj
[15:34] <Kurdistan> BluesKaj, wb.
[15:35] <Kurdistan> did the patch work you? it worked here.
[15:36] <BluesKaj> yes , Kurdistan , schnelle ..works geat , thanks :)
[15:37] <BluesKaj> great
[15:37] <Kurdistan> BluesKaj, is only for me, or does application now open crazy fast? :)
[15:38] <Kurdistan> most be the bug that made application load slower to pop up
[15:39] <Kurdistan> :) it is so fast it feels to run lxde :P
[15:40] <BarkingFish> afternoon guys. Anyone about?  I think we have some problems on the latest set of updates.
[15:41] <BluesKaj> yes Kurdistan , seems quite bit faster , especially system settings that used to take quite a while
[15:41] <BarkingFish> I have 27 updates to put through, but apper is screaming about Unsigned packages, which I go to confirm that I want to download and install, I click yes - and it takes me back to the start of the install process and asks me the same question repeatedly, until i click no.
[15:42] <Kurdistan> BluesKaj, exactly. even firefox loads crazy fast.
[15:42] <yofel> could be that the ppa has some preload stuff on too
[15:42] <BarkingFish> This is what I get: "You are about to install unsigned packages that can compromise your system, as it is impossible to verify if the software came from a trusted source.  Are you sure you want to proceed with the installation?"
[15:43] <BarkingFish> if it's in our repositories, surely it's been put together with a signature, right?
[15:43] <BluesKaj> BarkingFish,  well, if you're on 12.04 , unsigned packages is probly the norm ...using a package manager with a dev OS is bound to give the package manager apps fits :)
[15:43] <BarkingFish> I'm not though, I'm on 11.10
[15:43] <BarkingFish> I'm not upgrading till 12.04 is released
[15:43] <yofel> usually you shouldn't get unsigned warnings
[15:44] <BarkingFish> I guess I need to install the remaining updates one by one, and find which one is unsigned...
[15:44] <yofel> file a bug againt apper somewhere and then check with apt-get update if you're missing some key
[15:45] <Kurdistan> BarkingFish, have you upgrade to kde 4.8.0?
[15:45] <BarkingFish> no, still on 4.7.4
[15:46] <BarkingFish> I don't see any updates to 4.8.0
[15:47] <Kurdistan> BarkingFish, does this help: sudo rm -rf /var/lib/apt/lists/* 2. sudo apt-get update 3. sudo apt-get upgrade
[15:47] <BarkingFish> I'll tell you in a sec :)
[15:50] <Kurdistan> BarkingFish, yppa manager is a good tool. it fixes a lot of stuff with repo and errors.
[15:51] <Kurdistan> BarkingFish, https://launchpad.net/~webupd8team/+archive/y-ppa-manager
[15:51] <Kurdistan> it works great with kubuntu
[15:51] <BarkingFish> let me see how this goes first :D
[15:52] <yofel> just btw., this is the -dev channel, support is still in #kubuntu
[15:52]  * yofel is gone for  a while
[15:52] <Kurdistan> yofel, thats true.
[15:52] <BarkingFish> I'm gonna go make some coffee, this is taking a while :)
[15:52] <Kurdistan> BarkingFish, we can take it #kubuntu
[15:54] <BarkingFish> I'll keep it here for now, thanks Kurdistan - if it does turn out to be an unsigned package, these guys will need to know which one
[15:54] <Kurdistan> BarkingFish, okey. did it help anything?
[15:55] <BarkingFish> It still wants to upgrade the remaining packages I didn't do in the one by one, so I have 23 to come down now
[15:55] <BarkingFish> I'll see if doing the upgrade in a terminal flags anything up
[15:57] <BarkingFish> I didn't realise the kernel had been updated too :)
[15:57] <BarkingFish> this is gonna take some time.
[16:00] <Kurdistan> will log out. take care all.
[16:09] <shadeslayer> apachelogger: poke
[16:33] <grmls> hi
[16:36] <BarkingFish> hi again guys, sorry about the long break.
[16:37] <BarkingFish> Right, everything went through in the terminal upgrade, and it was only the same packages that apper was trying to work on.
[16:37] <BarkingFish> So what I'm going to do is file a bug against apper, as suggested, and make sure that the KDE guys are aware that it's being a PITA.
[16:45] <BarkingFish> oh this is fun.  KDE's bug reporter won't submit my bug :)
[16:56] <BarkingFish> Right, I've had to pass the bug to one of KDE's team to file, as the bugzilla won't submit my bug for some reason, I think the browser might be busted.
[16:56] <BarkingFish> rindolf is going to try and file, and once he does, I'll paste the bug number in here
[17:13] <BarkingFish> Ok guys, for the record - the apper bug is filed at KDE 293848
[17:16] <EagleScreen> anyone know who is upstream of libreoffice-kde? where to send feedback about that package?
[17:31] <BarkingFish> right guys, I'm gonna scoot for a bit. See you all later.
[17:57] <yofel> EagleScreen: libreoffice
[17:57] <yofel> EagleScreen: what's the feedback btw.?
[17:58] <EagleScreen> dropdown menus are ugly in KDE, they have no border
[17:58] <yofel> ah, true
[18:01] <shadeslayer> Riddell: yup, that commit fixed the buildlog bug
[18:01] <shadeslayer> huzzah
[18:06] <Riddell> sweet
[18:06] <Riddell> just needs rekonq packaged now :)
[18:07] <yofel> might as well do that, I'm done with gtk
[18:07] <yofel> or rather stuck on 2 mirs
[18:07] <Riddell> yofel: pinged the mir team?
[18:08] <yofel> there are bugs filed and ubuntu-mir subscribed, anything else to do?
[18:08] <yofel> I doubt they'll do much on a weekend
[18:10] <apachelogger> shadeslayer: huh?
[18:10] <shadeslayer> apachelogger: I was wondering how one disables Werror in CMake
[18:11] <shadeslayer> apachelogger: but then cmake-qt-gui to the rescue
[18:12] <shadeslayer> yofel: if you're there, can you check if the Telepathy Integration Module is running for you in kded?
[18:12]  * yofel adds telepathy back to the panel
[18:14] <yofel> I have an Instant Messaging Approver running, but no TIM
[18:14]  * BluesKaj waits patiently for rekonq flash crash fix :)
[18:15] <shadeslayer> eeep
[18:15] <yofel> shadeslayer: if that's supposed to be in 'kde-telepathy-integration-module', that package is empty
[18:15] <shadeslayer> yeah
[18:15] <shadeslayer> yofel: fixing
[18:15]  * shadeslayer does not know how that slipped past
[18:16] <yofel> add proper long install files to the packages
[18:16] <yofel> otherwise that happens really easy
[18:17] <shadeslayer> fffuuuuuu
[18:17] <shadeslayer> yofel: yeah, install file was not renamed
[18:17] <yofel> bwahahaha
[18:17] <apachelogger> I lol'd
[18:17] <apachelogger> shadeslayer: why rename though?
[18:17] <shadeslayer> apachelogger: telepathy-kde-foo to kde-telepathy-foo
[18:18] <shadeslayer> apachelogger: following upstream changes
[18:18] <apachelogger> why does it have a name prefix though?
[18:18] <shadeslayer> name prefix?
[18:18] <apachelogger> isn't telepathy using atomic tarballs?
[18:18] <shadeslayer> I don't follow
[18:18] <apachelogger> foo.install rather than install
[18:19] <shadeslayer> as in, why does it have the install file?
[18:19] <apachelogger> no
[18:19] <apachelogger> why does the install file have a prefix
[18:22] <shadeslayer> apachelogger: I *really* don't understand what you're asking
[18:22] <apachelogger> perhaps you should RTFM then
[18:22] <apachelogger> then you will know what I mean
[18:23]  * shadeslayer brings up the new maintainers guide
[18:23] <yofel> I think you'll find that faster in the policy
[18:23] <apachelogger> the new maintainers guide is not the  manual for debian/install :P
[18:24] <apachelogger> Mamarok: is there going to be dinner or am I to raid the fridge for booty?
[18:24] <shadeslayer> I've never seen a debian/install file tbh
[18:24]  * apachelogger finds that hard to believe
[18:25] <shadeslayer> apachelogger: I've always seen files like foo.install
[18:26] <yofel> well, you usually have more than one binary package, and if you just install everything you theoretically need none
[18:26] <yofel> so it's a rare case
[18:26] <apachelogger> yofel: rare with kde because you people insist on manually doing dbg packages
[18:27] <yofel> well, we dropped those on the debian merge anyway
[18:27] <yofel> I'll try to hack pkgbinarymangler for 4.9 beta
[18:27] <apachelogger> so it should be fairly common :P
[18:27] <yofel> then we won't need them in the first place
[18:27] <apachelogger> that hardly belongs in there IMHO
[18:27] <shadeslayer> I still can't find it, but I'm guessing the debian/install file just specifies where to install stuff when you have a single binary package
[18:28] <apachelogger> yofel: pkg-kde-tools seems the more logical place
[18:28] <yofel> apachelogger: beta packages without debug symbols are useless, no matter how unlikely a bug is
[18:28] <yofel> ah, you meant that
[18:28] <yofel> ok
[18:28] <yofel> I'll look at that
[18:28] <apachelogger> dbg package generation is not really mangling as the symbols are stripped either way
[18:29] <apachelogger> with a dbg package they just do not get thrown away :)
[18:29] <apachelogger> !man dh_install
[18:29] <yofel> well, more like I need to take a closer look at pkg-create-dbgsym
[18:29] <apachelogger> awww
[18:29] <apachelogger> ubottu: u mad?
[18:30] <apachelogger> shadeslayer: http://manpages.ubuntu.com/manpages/precise/en/man1/dh_install.1.html
[18:30] <shadeslayer> looking
[18:30] <shadeslayer> <3 krunner
[18:30] <apachelogger> one would think you know which component processes the install files so you can look at the manual when apachelogger instructs you to rtfm :P
[18:31] <shadeslayer> apachelogger: man page lists debian/package.install under Files
[18:31] <shadeslayer> :P
[18:31] <shadeslayer> nothing about debian/install
[18:32] <shadeslayer> and yeah, I know about dh_install, but thought the debian policy would probably give me better details about this file
[18:33] <apachelogger> well
[18:34] <apachelogger> let's bring the thougth a step further
[18:34] <yofel> I thought so, but it seems it doesn't, as the install files are specific to debhelper
[18:34] <apachelogger> if you have only one package
[18:34] <apachelogger> do you need an install file
[18:34] <apachelogger> muahhahaa
[18:34] <shadeslayer> not really I guess
[18:38] <yofel> well, undocumented feature it seems
[18:39] <yofel> now where was I..
[18:39] <shadeslayer> indeed
[18:39] <yofel> ah, rekonq
[18:40] <shadeslayer> go go yofel
[18:40]  * shadeslayer needs to finish off this test
[18:40] <apachelogger> yofel: oh, btw, I am reasonable certain the maintainer guide would explain debian/install
[18:40] <Kurdistan> :) this channel is to active to be a dev channel. :P
[18:40] <Kurdistan> (its good)
[18:40] <apachelogger> IIRC that guide has a fairly complete list of all common files one can find in debian/
[18:41] <apachelogger> even the not so common ones (emacs anyone? S:)
[18:41] <yofel> Kurdistan: well, this is -dev, -dev-discuss, -dev-OT, -dev-look-out-of-the-window-to-see-blue-ponies, ...
[18:41] <shadeslayer> don't forget -dev-apachelogger-loves-nakid-pics
[18:42] <Kurdistan> yofel, I am impresed. thats why I comment.
[18:42] <Kurdistan> other dev channel people are sleeping
[18:42] <yofel> well, we're less than a week before feature freeze. The channel has it's quiet times too
[18:42] <yofel> *its
[18:43] <Kurdistan> yofel, how is it going 12.04?
[18:43] <yofel> so far, nice
[18:43] <apachelogger> yofel: yeah quite times between 6 and 10 utc :P
[18:44] <yofel> ^^
[18:48] <Kurdistan> is it important that we need to follow 6 month release cycle?
[18:48] <Kurdistan> can we not release a version when the team feels it is good enough
[18:52] <shadeslayer> Kurdistan: now that we are a community supported distro we can
[18:52] <shadeslayer> but it's always better to follow the Ubuntu cycle
[18:52] <Kurdistan> shadeslayer, thats good.
[18:52] <shadeslayer> iirc edubuntu has it's own cycle
[18:52] <Kurdistan> shadeslayer, I mean to release when its ready.
[18:53] <Kurdistan> shadeslayer, I do not care much about ubuntu cycle.
[18:53] <shadeslayer> righto
[18:53] <Kurdistan> I think even 1 week later can be positive for stable for our users
[18:54] <Kurdistan> I normally recommend people to install new buntu release 1 month after the release
[18:54] <Kurdistan> atlest
[19:00] <yofel> why, just why are we running KDE 4.8.00? (what's up with the double-0?)
[19:01] <yofel> probably the reason why it looks broken on the about page too
[19:01] <shadeslayer> yeah
[19:01] <shadeslayer> typo :P
[19:02] <yofel> ah well, 4.8.1 is in sight, so nvm
[19:03] <yofel> now, let's see if rekonq got any less broken
[19:04] <yofel> nope, although that's qtwebkit's fault
[19:08] <Kurdistan> yofel, it is still time to 4.8.1
[19:08] <rbelem> shadeslayer, Kurdistan, but to release at any time some packages would not go to the repos
[19:08] <Kurdistan> or am I wrong?
[19:08] <rbelem> would we use ppa?
[19:08] <yofel> well, 2 weeks IIRC, near enough
[19:08] <Kurdistan> rbelem, which package?
[19:08] <rbelem> Kurdistan, any package maintained by kubuntu
[19:09] <shadeslayer> rbelem: huh? I mean, you can easily get stuff into universe right?
[19:09] <yofel> rekonq up
[19:09] <shadeslayer> yofel++
[19:10] <Kurdistan> yofel, we will have it in backports when?
[19:11] <rbelem> shadeslayer, but not following the ubuntu release cycle we could not upload apcakges to the respos after some time, right?
[19:11] <yofel> Kurdistan: realase date or shortly after that
[19:11] <yofel> well, probably
[19:11] <yofel> well, I believe rbelem's right, so I don't think it's worth the hassle
[19:11] <shadeslayer> rbelem: not sure, I mean, we can surely release a couple of days later in order to fix critical bugs
[19:11] <yofel> except maybe delay release for a week if we need to fix stuff
[19:12] <Kurdistan> yofel, thats fast.
[19:12] <shadeslayer> I think what Kurdistan is trying to say is that we can now delay the release by a couple of days if we see show stopper bugs
[19:12] <yofel> Kurdistan: there's not much to do, just build and Q/A
[19:13] <Kurdistan> shadeslayer, exactly.
[19:13] <yofel> well, it's easy if you know what you do
[19:13]  * shadeslayer hates g_thread_new
[19:13]  * yofel hates any kind of object oriented naming in C
[19:14] <Kurdistan> it feels sometime ubuntu and other in buntu family hurry up to finish thing to release date
[19:14] <yofel> Kurdistan: we have more testing time for the LTS, but usually you're right
[19:14] <yofel> I remember being overworked in the days before oneiric final freeze
[19:15] <Kurdistan> I hope Kubuntu decided to release Kubuntu when critical bugs are fixed
[19:15] <Kurdistan> even if ubuntu have released
[19:16] <yofel> well, until now, we didn't have a choice
[19:16] <Kurdistan> that gives more time to all of kubuntu-dev
[19:16] <Kurdistan> yofel, yeah I know, but we can do that now. right?
[19:16] <yofel> probably, I'll tell you in half a year :P
[19:17] <Kurdistan> yofel, :( forgott thats after 12.04.
[19:20] <yofel> nah, for 12.04 the testing time is long enough
[19:20] <yofel> so I think we'll have enough time
[19:25] <shadeslayer> yay
[19:25] <shadeslayer> yofel: I just got your IM request
[19:25] <shadeslayer> :P
[19:25] <yofel> lol
[19:25] <schnelle> guys, plasma-nm still have broken buttons, this bug is fixed upstream. https://bugs.kde.org/show_bug.cgi?id=290964
[19:25] <shadeslayer> It was probably because of the daemon thing which was not there in the packages
[19:25] <schnelle> don't forget to update it ;)
[19:27]  * yofel can't say he's ever seen those artifacts
[19:28] <schnelle> yofel: i see it in oneiric with kde 4.8 and also in precise
[19:28] <yofel> probably theme specific, I use produkt
[19:28]  * yofel fires up a VM
[19:29] <schnelle> yofel: i see it with default theme, so it can't be a good thing ;)
[19:29] <yofel> agreed
[19:30] <schnelle> yofel: is it possible to update plasma-nm after fature freeze?
[19:31] <yofel> bug fixes are allowed till final freeze
[19:31] <yofel> just no new features
[19:31] <yofel> (without good reason)
[19:31] <schnelle> i can poke lamarque to ask him when he will realese new version of plasma-nm
[19:31] <schnelle> he is online now
[19:31] <yofel> ah, confirmed
[19:32] <schnelle> yofel: bug is not present in kde 4.7
[19:32] <yofel> I'll cherry pick that in case he doesn't make it
[19:32] <schnelle> only in 4.8
[19:32] <yofel> well, we ship an new pnm with 4.8 too
[19:36] <schnelle> yofel: if we want new (next) release of pnm in precise, can we update it after feature freeze (sorry i don't understand feture freeze very well)
[19:36] <yofel> sure, if it has only bugfixes
 hi lamarque. are you planing to release new version of plasma-nm soon?
 no. I am busy at work and trying to fix some crashes before the release.
[19:43] <Kurdistan> schnelle, are you responsible for plasma-nm package?
[19:43] <schnelle> no :)
[19:45] <schnelle> yofel: he'll probably doesn't make it. don't forget to cherry pick that (now i am going to google what "cherry picking" exacly means :)
[19:46] <schnelle> *he probably won't make it
[19:46] <yofel> well, really just: pick one commit out of a bowl full of commits
[21:28] <apachelogger> halp, I had too much too eat
[21:28] <apachelogger> waaah
[21:29] <apachelogger> [kubuntu-members] ditch kaccessible: TODO
[21:29] <apachelogger> someone plz explain
[21:29] <apachelogger> rbelem: is active foo in the archive yet?
[21:36] <yofel> apachelogger: so, what's the status of dragon3?
[21:37] <apachelogger> sleeping
[21:38] <Daskreech> There be dragons?
[22:00] <jussi> Daskreech: no... Here be dragons...
[22:03] <Daskreech> jussi: Umm I forgot umm my lunch ...
[22:03] <Daskreech> brb <_<
[22:05] <rbelem> apachelogger, i'm testing it currently
[22:05] <rbelem> apachelogger, i think i will upload it tomorrow
[22:28] <OffToHades> lemme just check, can anyone actually see me this time?
[22:40] <Riddell> oh well
[22:46] <Kurdistan> update of network manager (backport)
[22:46] <Kurdistan> what is the fix?
[22:46] <yofel> the buttons that schnelle talked about
[22:47] <Kurdistan> yofel, have you the log?
[22:48] <yofel> Kurdistan: http://irclogs.ubuntu.com/2012/02/11/%23kubuntu-devel.html#t19:25
[22:52] <Kurdistan> yofel, thx.
[22:52] <Kurdistan> yofel, you are a angel.
[22:52] <yofel> well, it *did* look bad
[23:43] <Riddell> Subject: [kde-packager] KDevelop 4.3 Beta 2 ready to be packaged
[23:56] <BarkingFish> yofel: By the way, did you manage to ever fix xsettings-kde?
[23:56] <yofel> me not, but the fedora folks fixed it themselves, I just didn't noticed that hey had fixed it -.-
[23:56] <BarkingFish>  evening all :) sorry, wrong way round!
[23:56] <BarkingFish> any indication as to what was wrong?
[23:57] <Kurdistan> yofel, what did they ix?
[23:57] <Kurdistan> *fix
[23:57] <yofel> BarkingFish: http://pkgs.fedoraproject.org/gitweb/?p=xsettings-kde.git;a=summary - last commit is fixing the patch
[23:58] <Kurdistan> yofel, is the xsetting fixed?
[23:58] <yofel> it is
[23:58] <BarkingFish> ah :)  I'll have a peek when I can get on the net, connection is so slow that if I go to the web, i'll ping out on IRC :)
[23:58] <Kurdistan> yofel, nice. kde-gtk-config :) is not needed then?
[23:59] <BarkingFish> the snow here is playing hell with wifi. I'm picking up signals from 2 streets away, but can't get a decent connection to a beacon 10 metres from my front door :P
[23:59] <yofel> Kurdistan: not for now, we'll probably get it from debian next release. xsettings is a bit friendlier to other desktop envs


[11:11] <cjwatson> pbek: can you file a bug to remind me and I'll look at it when it's not the weekend?
[12:18] <pbek> cjwatson: on https://bugs.launchpad.net/launchpad-buildd/+bugs?
[12:23] <pbek> cjwatson: I file a bug for you at https://bugs.launchpad.net/launchpad-buildd/+bug/1603755
[12:24] <pbek> thanks a lot for your help!


[09:05] <apollo13> hello, anyone around to help me with network configuration?
[09:05] <apollo13> my cloud-init on debian properly writes the config to /etc/network/interfaces.d/50-cloud-init.cfg
[09:05] <apollo13> but also generates a dhcp template in /run/network/interfaces.d which obviously takes precedence but won't work because of no dhcp server in that network
[09:06] <apollo13> any idea what is causing that?
[09:07] <apollo13> also I need to rename 50-cloud-init.cfg to 50-cloud-init that it works
[11:06] <apollo13> okay, I fixed that by upgrading cloud-init to > 19.2
[11:06] <apollo13> sadly that is not yet in the buster images, but apparently on it's way
[11:09] <apollo13> so, cloud-init network configuration configures dns-nameserver in /etc/interfaces yet the debian cloud images do not have resolvconf, how is that supposed to work?
[11:19] <tribaal> apollo13: just a heads up - most of the active cloud-initers are in US timezones (I don't know how to answer your question personally)
[11:20] <apollo13> I have opened https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/24
[11:20] <apollo13> tribaal: thanks, my bouncer will stay online :)
[11:24] <tribaal> apollo13: hehe ack :) I guess opening the bug report was the right reflex - it is a good asynchronous contact point as well.
[11:24] <apollo13> in all fairness I am surprised how badly cloud-init seems to work every time I try it :(
[11:25] <apollo13> I mean I guess it is probably my fault for using a static network configuration instead of DHCP and I fully understand that getting those things right is hard, but I fail massively every time I try cloud-init :(
[13:40] <Odd_Bloke> apollo13: What is creating the file in /run/network/interfaces.d?
[13:40] <apollo13> Odd_Bloke: the ifupdown-cloud-init-helper
[13:41] <apollo13> but it only does this because cloud-init wries 50-cloud-init.cfg int /etc/network/interfaces.d which is a invalid name
[13:41] <apollo13> so that part got fixed by upgrading to cloud-init > 19.2
[13:41] <Odd_Bloke> I'm not familiar with ifupdown-cloud-init-helper, what is that?
[13:42] <Odd_Bloke> Well, regardless, sounds like you're past that part of the issue.
[13:42] <apollo13> yes
[13:42] <apollo13> all that remains (and I also fixed that by remastering the debian cloud images) was DNS which got fixed by adding resolvconf to the image
[13:43] <Odd_Bloke> So it sounds like this is an issue with the mastering of the Debian cloud images more than it is with cloud-init?
[13:43] <apollo13> yes, seems like it
[13:43] <apollo13> hence I opened an issue at https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/24
[13:43] <apollo13> apparently they only test the dhcp boot cases, dunno…
[13:45] <Odd_Bloke> OK, cool, was just making sure I'd understood fully.  Thanks for bringing the issue here (even if you fixed it before the core team woke up ;).
[13:46] <apollo13> hehe, no issue after all…
[13:46] <apollo13> although one could argue that the cloud-init debian package should probably depend on resolvconf (or at least something that is able to write dns into resolv.conf or somewhere else)
[13:46] <apollo13> or can I use a different network renderer on debian that would work
[13:49] <apollo13> Open for suggestions if anyone has any
[13:52] <Odd_Bloke> I believe Debian package cloud-init themselves, so a Depends change would be a bugs.debian.org conversation.
[14:16] <apollo13> Odd_Bloke: yeah, or at least for the cloud-images, anyways thanks for trying to help! much appreciated. It works kinda lovely from proxmox now
[14:16] <apollo13> now if I were to figure out how to easily remove snap from the ubuntu server images, I could also use that :D
[14:18] <Odd_Bloke> You could potentially automate that with cloud-init user-data.
[14:20] <apollo13> sure, sadly proxmox cloud-init support is rather limited
[16:31] <kqkq95> hi all ! i hope you are well :) , is cloud-init ready for CentOS 8 ?
[18:38] <blackboxsw> kqkq95: cloud-init supports CentOS. tip of cloud-init has python3 support and looks like centos8 looks to be python3.6. We should be good there, though I see stock centos8 has a  dated cloud-init version 18.5 available
[18:39] <blackboxsw> we are at 20.1 now
[18:39] <blackboxsw> ~ 1.5 years of missing bugfixes/features
[18:40] <blackboxsw> rharper: Odd_Bloke here are the  use-cases our release tooling is trying to automate https://hackmd.io/VbmtcZLyR4650aqqmfMMYg
[18:40] <meena> blackboxsw: and how many bugs? have we introduced since then? :P
[18:42] <rick_h_> meena:  3 definitely 3
[18:43] <blackboxsw> haha!
[18:44] <blackboxsw> kqkq95: also you can get latest cloud-init development bits from https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[18:45] <Odd_Bloke> blackboxsw: Scanning through that now, thanks for putting it together!
[18:46] <Odd_Bloke> My first note: Feature Freeze only applies to the devel release, but the wording suggests that we should behave differently for non-devel series during FF.
[18:46] <blackboxsw> good pt Odd_Bloke changing
[18:47] <Odd_Bloke> Thanks!
[18:47] <blackboxsw> fixed
[18:50] <kqkq95> blackboxsw: ok i have the latest version ;)  i have a problem with my template vmware (OS : Centos 8)  with open-vm-tools and cloud-init) the network configuration is not set :(
[18:54] <blackboxsw> kqkq95: not quite sure, might be related to https://bugs.launchpad.net/cloud-init/+bug/1835205 maybe?
[19:02] <Odd_Bloke> So I am beginning to wonder if Robie's idea for a third git branch would be a cleaner way of handling this.  Currently, we merge `master -> release` and build from that.  If instead we merged `new_branch -> release` and then `master -> release`, we could (a) revert cherry-picks on `new_branch` as soon as we apply them to `release`, and (b) resolve any other merge conflicts in `new_branch` rather than
[19:02] <Odd_Bloke> `release`.  (The key here is that `new_branch` only need be updated when it's necessary to fix the builds, most of the time it won't need to be touched.)
[19:04] <kqkq95> blackboxsw: not really, at boot my network interfaces are disconnected, only with cloud-init, i test without cloud-init in my template that works well :(
[19:07] <Odd_Bloke> Basically `new_branch` is where we handle the munging required for `master` to cleanly merge into `release`.  This would be instead of us doing it in `release` (because doing it there is what leads us to have to think about popping cherry-picks etc.).
[19:10] <Odd_Bloke> (Oh and when I say "if instead we merged", I'm talking in the daily recipe build.)
[19:11] <rharper> Odd_Bloke: I guess I don't understand what's so objectionable to popping of cherry picks in the release branch;
[19:11] <rharper> s/of/off
[19:13] <rharper> my question with a third branch (or daily sub branch to the release branch is):  where do you land release changes first  (I want to make a change to debian/control on ubuntu/devel ) ; we will ultimately release this *eventually* but certainly we want daily to get it first ... so if we put in ubuntu/devel first, we have to remember to merge that into ubuntu/devel/daily (for example)  or reverse this, and we still need to remember to land the change
[19:13] <rharper> on two branches
[19:14] <rharper> if we are changing recipes, I would prefer the idea of having daily recipe "fix itself" by popping off cherry-picks, if any
[19:14] <Odd_Bloke> Well, we don't have to remember per se, daily builds will fail and then we can fix it (or they won't and we don't).
[19:14] <rharper> heh
[19:14] <rharper> we already have that today;
[19:15] <rharper> I was hoping to not have daily builds fail if we have a well-defined process for updating release branches and automatically cleaning up after releasing
[19:15] <rharper> at least now we have exactly one release branch to maintain  vs. two per release going forward
[19:16] <Odd_Bloke> From a practical perspective, popping off cherry-picks fails in (5) in Chad's doc.
[19:17] <Odd_Bloke> Having to reapply them to add another one, and then pop them all back off feels fragile.
[19:18] <Odd_Bloke> From a less directly practical perspective, having the release branches not represent what's actually in those releases is confusing (and annoying in a practical sense, `git diff ubuntu/devel` won't show me how my current tree differs from focal, for example).
[19:18] <rharper> hrm, I would suggest that if only the recipe build popped cherry-picks off; that seems the least fragile;    the release branch stays in it's "released" state;  daily reverts any cherry picks if present and builds it;
[19:19] <Odd_Bloke> Well, I don't believe that's an option in the recipe builder.
[19:20] <Odd_Bloke> And wouldn't help in the d/control scenario you laid out.
[19:20] <rharper> https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder   suggest that we can use run <shell code here>
[19:21] <Odd_Bloke> "Note: Launchpad does not support the run command."
[19:21] <rharper> ah I see, the bzr-builder did but lp doesn't
[19:21] <Odd_Bloke> Yep, for security reasons I believe/assume.
[19:21] <rharper> so forced to put what we'd run into a branch;  it does help in the d/control scenario as we merge in the release branch where the new d/control change was made, and then just need to pop off the cherry picks before building
[19:22] <rharper> due to the recipe build restrictions it sounds like we have to maintain a different branch if we don't want to push/pop for daily builds if the release has cherry picks
[19:22] <Odd_Bloke> "merge in the release branch" <-- merge from where into where?
[19:23] <rharper> master merges release into itself for recipe builds
[19:23] <rharper> it's git checkout master git merge <release>
[19:23] <rharper> that's daily ppa recipe
[19:24] <Odd_Bloke> Sure, just wasn't sure if that's specifically what you meant. :)
[19:24] <rharper> I wonder if we could test to see if a branch was present ...
[19:24] <blackboxsw> yes per recipe builder, I was trying to utilize the 'run ' command in the build recipe to do that popping for us. but it seems unsupported in git build recipes
[19:24] <rharper> it would be nice if the recipe would prefer ubuntu/devel/daily  if present, and if not fallback to ubuntu/devel
[19:25] <rharper> blackboxsw: yeah, lp does not support run for security reasons
[19:25] <Odd_Bloke> I guess the d/control case I'm thinking of is the pytest one: the daily build and the release build needed _different_ d/control values.
[19:25] <rharper> but we cherry picked in a d/control fix though IIUC
[19:25] <Odd_Bloke> So I would expect that if we merge in the correct order, `ubuntu/devel/daily` would not need to be kept up-to-date.
[19:25] <rharper> so it;s just one more cpick to pop off
[19:26] <Odd_Bloke> We accepted having both test frameworks in our Build-Depends for a while, I think.
[19:26] <rharper> Odd_Bloke: intersting  ...
[19:26] <rharper> tell me more  as there is multi branch merging  in the recipe
[19:26] <blackboxsw> hrm ahhh
[19:27] <blackboxsw> right so if all we care about for dailies is to drop debian/patches/cpicks- we could merge the ubuntu/devel/daily/debian/patches directory that only contains the base patches that matter for the release branch
[19:28] <Odd_Bloke> That isn't where I was going (which isn't to say that it isn't worth going there :p).
[19:28] <blackboxsw> so any cpick patches that we happen to apply to ubuntu/devel would be absent once ubuntu/devel/daily/debian/patches was 'merged' ontop
[19:29] <rharper> blackboxsw: I don't think you can merge away changes ...
[19:29] <rharper> unless the fix includes a commit that removes the files ..
[19:31] <Odd_Bloke> So essentially what we're trying to avoid when we pop cpicks back off is merge conflicts, right?
[19:31] <blackboxsw> right
[19:31] <rharper> Odd_Bloke: yes
[19:34] <rharper> so, if we create ubuntu/devel and ubuntu/devel/daily  at the same time;  then update our recipe to be:  lp:cloud-init master; merge ubuntu-pkg lp:cloud-init ubuntu/devel; merge ubuntu-pkg-fix  lp:cloud-init ubuntu/devel/daily ;  the last merge is no-op as all of the commits in daily are already merged ;; if that doesn't break
[19:34] <Odd_Bloke> I think we need to merge ubuntu-pkg-fix before ubuntu-pkg, so that it can resolve merge conflicts.
[19:34] <rharper> then if we added cpicks to ubuntu/devel and  update ubuntu/devel/daily with the same cpicks;  then we pop off on ubuntu/devel/daily and commit that
[19:35] <rharper> Odd_Bloke: maybe;  I'm weak around the ordering ...
[19:35] <Odd_Bloke> So my proposal is that we merge a third branch into `master` before `release`, which can resolve those merge conflicts.  When we have a conflict, we manually merge `master -> new_branch` and then `release -> new_branch` (which should cause the conflicts, which we can manually resolve).
[19:35] <Odd_Bloke> That would mean, in the immediate term, that the second merge in the recipe would be a noop.
[19:36] <Odd_Bloke> (The second merge being `release ->` the result of `new_branch -> master`.)
[19:37] <rharper> I think two steps here 1) sorting out the right recipe with the third branch  2) updating the tooling to keep daily recipe sub branch in sync when we modify the release branch ;  for (2)  I know if we cpick we need to copy and then revert in daily    for new changes to release branch; (like d/control)  it's not clear to me if we need to keep daily in sync or not
[19:38]  * blackboxsw was starting to document the possibility here https://hackmd.io/VbmtcZLyR4650aqqmfMMYg?both#proposed-build-recipe
[19:38] <blackboxsw> ahh but the 'merge' attempt of u/d/daily would result in merge conflicts
[19:39] <Odd_Bloke> So, to be clear, I'm proposing all three are full trees that are merged together fully.
[19:39] <Odd_Bloke> But there might be a better solution that doesn't do that.
[19:40] <rharper> why would there be merge conflicts; sorry I'm a little git merge slow
[19:41] <rharper> only if ubuntu/devel changes touched a file that is cpicked, right ?
[19:41] <blackboxsw> rharper: folowing Odd_Bloke's suggestion of 3 separate branches. I guess we wouldn't if we did the following during cherry-pick
[19:42] <blackboxsw> (from ubuntu/devel): cherry-pick mycommit; git push ubuntu/devel:ubuntu/devel/daily;  git checkout ubuntu/devel/daily; cherry-pick --pop-all;
[19:43] <blackboxsw> so we cherry pick into u/d; push to u/d and u/d/daily; checkout u/d/daily and pop-all;
[19:43] <blackboxsw> then we won't have merge conflicts; and we won't have to revert ubuntu/devel
[19:43] <rharper> Odd_Bloke:  we have master, we have ubuntu/devel which is a fork of master on which we keep the debian dir (and sync it up with master from time to time);  and ubuntu/devel/daily which is a fork of ubuntu/devel which is updated only when we modify ubuntu/devel and daily recipe would fail ; the cpick scenario  ;
[19:43] <rharper> blackboxsw: yes
[19:44] <rharper> and if ubuntu/devel has a new non-cpick commit to d/control, if we merge ubuntu/devel/daily over it;  there shouldn't be any conflicts AFAICT ;  daily is just behind ubuntu/devel but they don't overlap in changes
[19:45] <blackboxsw> rharper: right any non-cpick is present already in ubuntu/devel/debian/patches and untouched by the --pop-all
[19:46] <blackboxsw> so u/devel/daily would still contain the non-cpick debian/patches file
[19:46] <blackboxsw> ok I *think* this clarifies what we  can do in cherry-pick for me if we are ok with a separate ubuntu/series/daily branch that automatically is updated during new-upstream-snapshot and cherry-pick calls
[19:47] <blackboxsw> if cherry-pick/new-upstream-snapshot pushes to both ubuntu/<series> and ubuntu/<series>/daily then we don't have to any reverts in ubuntu/<series>
[19:48] <blackboxsw> and we don't have to manually maintain those two branches as it'll be hidden under the tooling
[19:48] <Odd_Bloke> Let's figure out what the behaviour should be (e.g. when applying a cherry-pick to ubuntu/$series, a corresponding revert should be pushed to ubuntu/$series/daily) before thinking about automating it.
[19:48]  * blackboxsw tries writing it out on the hackmd doc
[19:51] <blackboxsw> Odd_Bloke: rharper if we were ok supporting a seprate full ubuntu/<series>/daily branch anyway, there may be no reason to merge ubuntu/<series>/daily into ubuntu/series as ubuntu/<series>/daily should have all the commits it needs plus only the drop of any cpicks.
[19:51] <blackboxsw> so build recipe could remain simple. but I'm writing that out now
[19:55] <Odd_Bloke> OK, hang on, I'm a little confused: we haven't popped the latest round of cherry-picks, but daily builds are succeeding.
[19:57] <rharper> https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel
[19:57] <rharper> says no
[19:57] <Odd_Bloke> Oh haha, I was looking at bionic.
[19:57] <Odd_Bloke> Very smart.
[19:57] <rharper> blackboxsw: AFAIK we always want to merge ubuntu/devel/daily  ; it just may not have any content to add
[19:57] <rharper> unless we have cpicks
[19:57] <Odd_Bloke> OK, so the issue isn't really merge conflicts, actually, it's that quilt patches don't necessarily cleanly apply.
[19:58] <rharper> blackboxsw: we want a stable recipe that always works; and once we diverge a release branch then daily contains the "fixups"
[19:58] <rharper> Odd_Bloke: we can also put our refresh patches work on to daily
[20:01] <Odd_Bloke> Right, though we would probably just revert them there?
[20:02] <blackboxsw> rharper: if ubuntu/devel/daily has no cpicks to drop ubuntu/devel == ubuntu/devel/daily
[20:03] <blackboxsw> if we just always push ubuntu/devel -> ubuntu/devel daily with new-upstream-snapshot and cherry-pick, we never really have to merge
[20:03] <blackboxsw> I think I tried capturing this in https://hackmd.io/VbmtcZLyR4650aqqmfMMYg?view#proposed-branching-strategy
[20:04] <Odd_Bloke> That would require a force push to ubuntu/$series/daily, I think
[20:04] <Odd_Bloke> ?
[20:06] <rharper> I don't want to force push;  and I don't see why we need to push anything into daily except cpicks
[20:06] <Odd_Bloke> "tip of ubuntu/<series> plus commits to revert of any debian/patches/ named cpick-* or fix-cpick-*" implies force-pushing, I think.
[20:06] <rharper> daily only needs to hold refresh debian/patches  and cpick pop-all
[20:07] <blackboxsw> Odd_Bloke: I believe a force push would be required to daily right
[20:07] <rharper> why ?  we merge in cpicks from release branch to apply a revert ;
[20:07] <Odd_Bloke> Yeah, to have it be "tip + ..." it would have to be a force push.
[20:07] <rharper> and we hold changes to debian/patches needed for refreshing release branch patchs
[20:07] <Odd_Bloke> (Maybe I'm just getting hung up on the wording here.)
[20:08] <blackboxsw> rharper: because we reverted cpicks in u/$series/daily  but didn't revert in u/$series base branch
[20:08] <rharper> if I branch ubuntu/devel and then ubuntu/devel/dail from ubuntu/devel;   and Ihave master, merge in ubuntu/dlevel, and then merge in ubuntu/devel/daily
[20:08] <blackboxsw> so how do we update u/$series/daily from u/$series without a force push?
[20:08] <rharper> but the reverts play on top of the commits already merged in from ubuntu/delvel ?
[20:08] <Odd_Bloke> Merge?
[20:08] <blackboxsw> yeah I guess we could keep merging u/$series
[20:08] <rharper> daily only needs to apply on top of release
[20:09] <Odd_Bloke> We shouldn't really need to touch /daily all that often.
[20:09] <rharper> and it's "undo commits only"
[20:09] <rharper> yes
[20:09] <rharper> that's the idea
[20:09] <Odd_Bloke> (Not even for most releases, I would hope.)
[20:09] <rharper> normaly daily will be the same state as ubuntu/devel was at the start of the new series
[20:09] <rharper> Odd_Bloke: yes;
[20:11] <Odd_Bloke> I'm putting together a test recipe now.
[20:12] <rharper> nice
[20:14] <blackboxsw> yeah I think that recipe would be just this right? https://hackmd.io/VbmtcZLyR4650aqqmfMMYg?view
[20:14] <Odd_Bloke> Oh ubuntu/devel/daily is an invalid name because we have ubuntu/devel, I've gone for ubuntu/daily/devel for now.
[20:14]  * blackboxsw didn't understand that Odd_Bloke . why is that invalid?
[20:15] <blackboxsw> because the branch name we reference looks like a path under ubuntu/devel?
[20:15] <Odd_Bloke> Because `.git/refs/heads/ubuntu/devel` is already a file, so it can't also be a directory, basically.
[20:17] <blackboxsw> ahh righto
[20:18] <rharper> bummer
[20:33] <Odd_Bloke> OK, so I have a working prototype recipe here: https://code.launchpad.net/~daniel-thewatkins/+recipe/oddbloke-cloud-init-daily-devel
[20:34] <Odd_Bloke> My ubuntu/daily/devel has reverts of every cherry pick added since the previous release.
[20:34] <blackboxsw> nice. /me wonders why the order seems backwards
[20:35] <blackboxsw> I have the same understanding. if daily/devel
[20:35] <Odd_Bloke> You have to revert in reverse order.
[20:36] <blackboxsw> but I'd expect merge conflicts when you are merging ubuntu/devel into lp:cloud-init  on line 2
[20:36] <Odd_Bloke> The issue is not merge conflicts, the issue is patches failing to apply.
[20:36] <Odd_Bloke> And they aren't applied until the recipe is complete and both merges have happened.
[20:36] <blackboxsw> ahh right. right.
[20:36] <blackboxsw> +1
[20:36] <blackboxsw> yes that makes sense in my head now
[20:37] <Odd_Bloke> (I was earlier mistaken about this, so my earlier proposals presupposed that we needed to order the merges to be able to resolve conflicts.)
[20:37] <Odd_Bloke> (Which is why they expressed them in a different order.)
[20:37] <Odd_Bloke> blackboxsw: So I would suggest that we document this process and see how it works for us manually a couple of times before enshrining it in tools.
[20:38] <blackboxsw> but again, why couldn't we just drop the merge ubuntu-pkg lp:~daniel-thewatkins/cloud-init/+git/cloud-init ubuntu/devel
[20:38] <blackboxsw> as ubuntu/daily/devel will be devel + drops
[20:38] <Odd_Bloke> It is currently.
[20:39] <blackboxsw> I mean 'omit the line that says " merge ubuntu-pkg lp:~daniel-thewatkins/cloud-init/+git/cloud-init ubuntu/devel" in your recipe
[20:39] <Odd_Bloke> I understood.
[20:39] <Odd_Bloke> ubuntu/daily/devel is currently devel + drops.
[20:40] <Odd_Bloke> But we don't want to have to update ubuntu/daily/devel every time we update ubuntu/devel.
[20:43] <Odd_Bloke> OK, so I just did a `new-upstream-release master` and pushed to my repo and the build is now failing.
[20:43] <blackboxsw> ok Odd_Bloke I see. right we only need to update it when we cherry-pick or drop cherry-picks
[20:44] <blackboxsw> Odd_Bloke: I'd expect that if we aren't pushing to ubuntu/daily/devel every change to ubuntu/devel
[20:44] <Odd_Bloke> It looks like because the fix-cpick-* patch wasn't dropped automatically by new-upstream-release.
[20:44] <blackboxsw> Odd_Bloke: right that fix is also in my PR #45 on uss-tableflip
[20:44] <blackboxsw> fix-cpick* and cpick-* get handled
[20:44] <blackboxsw> s/handled/popped
[20:44] <blackboxsw> by both new-upstream-snapshot and cherry-pick --pop-all
[20:47] <Odd_Bloke> OK, with all patches dropped, the build succeeded.
[20:47] <Odd_Bloke> Without updating ubuntu/daily/devel.
[20:50] <blackboxsw> so Odd_Bloke if we only update ubuntu/daily/devel when cherry-picks are applied. then procedure looks like this maybe?:   git checkout ubuntu/devel; cherry-pick <upstream_cpick_commit>; git checkout ubuntu/daily/devel; git merge ubuntu/devel; git revert <local_cpick_commit>; git push ubuntu/daily/devel;
[20:51] <blackboxsw> so individually each time we cherry-pick, we git revert that local cherry-pick commit and push to ubuntu/daily/devel
[21:01] <Odd_Bloke> Something along those lines, yes.
[21:36] <rharper> Odd_Bloke: catching up;   "with all patches drop the build succeeded/Without updating ubuntu/daily/devel"   -- that exactly what I was hoping.  Excellent!
[22:03] <johnsonshi> Anybody have issues with running `tox -e pylint` recently? I constantly hit the "unable to import pytest" error, but when I try to do so through the py2/py3 console everything seems fine. This is on cloud-init master btw so unsure if this is a bug.
[22:06] <rharper> johnsonshi: I've not, let me see if I can reproduce
[22:09] <rharper> johnsonshi: tox -r -e pylint works for me
[22:09] <rharper> I used -r to recreate the env fresh which means pulling down the pip packages into the virtenv
[22:12] <johnsonshi> rharper: Yeah -r passed. Thanks!
[22:12] <rharper> cool!


[09:09] <popo> hi,
[09:10] <popo> how install conkyforecast on ubuntu17.04? thank for help
[18:54] <lafleurdubien> Do you guys know of any awesome .bashrc files? Preferably shared publicly via github etc.
[18:54] <Akuli> i just make my own :)
[18:55] <Akuli> here's what i have now if you're interested http://dpaste.com/2H90HAP
[19:01] <stanjr> Why are we losing our ability to be civil with one another???
[19:02] <stanjr> Strength through diversity is a powerful force.
[19:03] <stanjr> Do you believe in that force???
[19:03] <stanjr> What would you be willing to do to help?
[19:04] <stanjr> Can we all agree that we can respectfully disagree?
[19:05] <stanjr> Deep thoughts.....
[19:05] <stanjr> Shallow audience...
[19:08] <Akuli> lol


[14:53] <philballew> Hello, everyone doin good here?
[14:53] <smartboyhw_> yep
[14:53] <JoseeAntonioR> everything looks alrighty
[14:53] <ptl> hi
[14:54] <smartboyhw_> Community roundtable… what do we talk?
[14:54] <philballew> smartboyhw_, anything that you feel we need to discuss basically.
[14:55] <smartboyhw_> philballew: Hmm I can't watch or join in the Hangout…
[14:55]  * philballew should be set to join the hangout assuming JoseeAntonioR did not mess up my webcam setup
[14:55] <smartboyhw_> It starts!
[14:55] <JoseeAntonioR> :P
[14:56] <philballew> alright, I marked myself as very interested in attending, so does that mean I join the hangout?
[14:56] <philballew> JoseeAntonioR, ^
[14:56] <YoBoY> hi
[14:57] <smartboyhw_> philballew: dholbach will send you the link I thinj
[14:57] <smartboyhw_> *think
[14:57] <JoseeAntonioR> philballew: nope, that was for physical uds and auto-scheduling :)
[14:57] <JoseeAntonioR> philballew: you only get the link if you're marked as required
[14:58] <zvacet> is Ubuntu without community still topic here?
[14:58] <JoseeAntonioR> zvacet: I think there's no ubuntu without community :)
[14:59] <zvacet> JoseeAntonioR: you know what I mean  ;)
[14:59] <smartboyhw_> zvacey: The website?
[14:59] <YoBoY> tea time for me
[15:00] <SergioMeneses> YoBoY, wise move
[15:00] <zvacet> smartboyhw_:  http://ubuntuforums.org/showthread.php?t=2143971
[15:00] <cjohnston> can someone make me some tea?
[15:00] <elfy> smartboyhw_: the website is just one symptom - the latest one
[15:00]  * JoseeAntonioR gives cjohnston some tea
[15:00] <SergioMeneses> cjohnston, I think YoBoY can
[15:00] <tiagoscd-uds> about the community thing: http://design.canonical.com/2013/05/ubuntu-com-update/
[15:00] <smartboyhw_> zvacet: That's another session
[15:01] <SergioMeneses> tiagoscd, maybe you can put it on the work tiems
[15:01] <philballew> jonobacon, welcome
[15:01] <YoBoY> SergioMeneses, cjohnston sure :)
[15:01] <philballew> live
[15:01] <SergioMeneses> dholbach, and jono_ are here!
[15:01] <fisch246> yup
[15:01] <jcastro> yep!
[15:01] <philballew> yes
[15:01] <cjohnston> jono_: why stop at twice
[15:02] <philballew> Me
[15:02] <jcastro> I'd like to plop in
[15:02] <fisch246> me
[15:02] <philballew> if there is room of course
[15:02] <SergioMeneses> philballew, \o\
[15:02] <zvacet> smartboyhw_: ok I was interested in that one  bye
[15:03] <rrnwexec> good morning all.
[15:03]  * skellat shies away from the hangout
[15:03] <SergioMeneses> jono_, I cant I have not camera and microphone :S
[15:04] <smartboyhw_> zvacet: http://summit.ubuntu.com/uds-1305/meeting/21740/community-1305-ubuntu-website-planning/
[15:05] <zvacet> smartboyhw_: tnx for link  :)
[15:05] <fisch246> ben i believe i saw you talking about firefox os
[15:06] <tiagoscd-uds> dholbach: hey
[15:06] <smartboyhw_> fisch246: You are correct he did
[15:07] <YoBoY> I have raised the fact in the locoteams mailing list we still need a DVD cover art with the ISO, can we try to make this appen for the next ubuntu release ?
[15:07] <ptl> regarding the ARM architecture, is there any plan to help or support community-based initiatives for porting, e.g. "picUntu" for UG802 and MK802-III like "android" tv sticks?
[15:07] <smartboyhw_> YoBoY: For 14.04 LTS I think…
[15:07] <ptl> like, e.g. providing help to make Mir run on them
[15:08] <smartboyhw_> ptl: I think there is a porting session
[15:08] <ptl> ah, I didn't see the whole schedule
[15:08] <YoBoY> smartboyhw_, for 13.10 too, and every ISO, I just want some DIY artwork like the other releases
[15:10] <smartboyhw_> YoBoY: Hmm, probably ask the LoCo Council
[15:10] <ballock> What about company LoCos? I've got a couple of people contributing from inside company, any ideas for grouping that?
[15:10] <smartboyhw_> SergioMeneses: ^
[15:10] <smartboyhw_> ballock: Companies aren't LoCos, but then you guys can join in your country's LoCo
[15:10] <SergioMeneses> company?
[15:11] <SergioMeneses> we are not a company or something like that
[15:11] <smartboyhw_> SergioMeneses: Answer YoBoY :)
[15:11] <cjohnston> jono_: or anyone else on the hangout.. I can't be around on thursday, but I would like it if Summit were discussed during the round table on thursday.. just quick discussion/feedback from this UDS.. the changes, are they good, bad, what else needs to be done.. request for help... request for charmers
[15:11] <smartboyhw_> I am pointing at YoBoY not ballock:P
[15:11] <cjohnston> dholbach: jcastro ^^
[15:12] <jcastro> cjohnston: ack
[15:12] <cjohnston> ty
[15:12] <ballock> SergioMeneses: I don't mean Canonical or whatever, we've got a ubuntu community inside Tieto.
[15:13] <cjohnston> and it looks like you already put that in and I missed it JoseeAntonioR
[15:13] <cjohnston> sorry jono_ ^
[15:13] <skellat> YES
[15:13] <smartboyhw_> ballock: How big is Tieto? (Sounds like the Tokyo Metro)
[15:13] <YoBoY> (arg phone not stopping to ring T_T)
[15:13] <SergioMeneses> ballock, I see and what is Tieto?
[15:14] <ballock> A company, 20k employees, over 500 ubuntu users, mostly developers.
[15:14] <dholbach> is there anyone else who wants to get on the hangout?
[15:15] <SergioMeneses> dholbach, ask yo czajkowski
[15:15]  * SergioMeneses hides
[15:15] <czajkowski> can't at present have a deadline of stuff for today
[15:15]  * dholbach hugs czajkowski
[15:16] <JoseeAntonioR> urgh, I'm dropping :)(
[15:16] <JoseeAntonioR> :( *
[15:16] <smartboyhw_> ballock: Where is your company coming from?
[15:17] <skellat> jono: Left a hunk of text in the Etherpad in notes.
[15:17] <cprofitt> I agree with you Jono... I like the idea of allowing people to grow organicly... cities, states, etc...
[15:18] <YoBoY> doing like mozilla do now to their events ? people who wants a promotional pack have to fill a request with the details of the events, and have to write about the event before and after to promote it.
[15:18] <ballock> Finland is the main site, we have active people in Sweden, Poland and some active people from other Tieto sites too.
[15:19] <smartboyhw_> ballock: Hmm
[15:20] <ballock> ok, it might be difficult to get a group photo in these conditions...
[15:20] <smartboyhw_> SergioMeneses: czajkowski: Any ideas?
[15:20] <cjohnston> rrnwexec: can you mute please when your not talking.. background noise gets really loud
[15:20] <SergioMeneses> I want to add something ....
[15:20] <SergioMeneses> but in the reapproval process we can get a lot of information about our teams, and I think this is the best part of the process by instance https://wiki.ubuntu.com/EgyptTeam/ApprovalApplication2012 ...if we remove this process, we have think in a different way to get this information. imho
[15:21] <czajkowski> SergioMeneses: +1
[15:21] <czajkowski> the reapproval gives us a chance to show others what they are doing
[15:21] <czajkowski> just feels liek a lot of the work we've done is kinda gone to waste tbh
[15:23] <czajkowski> mails go to shippit - and they reach out to council already!
[15:23] <cprofitt> hate to leave this dicussion, but I have a doctors appointment
[15:23] <JoseeAntonioR> SergioMeneses, czajkowski: any of you can join? :)
[15:23] <cprofitt> good topic all
[15:23] <czajkowski> JoseeAntonioR: nope working :) and lack of notice on topic meant cant change
[15:23] <cprofitt> thanks for bringing this forward
[15:23] <SergioMeneses> besides, we work with the teams in another issues as you can see here https://bugs.launchpad.net/ubuntu-locoteams/+bug/1075848
[15:23] <udsbotu> Launchpad bug 1075848 in Ubuntu LoCo Teams "Re-approval, ubuntu-ca" [Critical,Fix released] - Assigned to Darcy Casselman (dscassel)
[15:24] <YoBoY> transform the reapprovals in healthcheck perhaps
[15:24] <SergioMeneses> JoseeAntonioR, I dont have camera or mic, I am not at home
[15:26] <skellat> jono: I've got no problem with you're notion.  I've been waiting on it to be executed since UDS-1303!
[15:27] <ballock> I'm trying to make sense of it. Is the LoCo discussion just a question of sending out CDs/perks?
[15:27] <philballew> Getting a conference is pretty easy currently the several times I have had to get one. I have a conference pack for a show I am doing in two weeks and I am going to take pictures of all the stuff I hand out and the talks. The pictures alone make great pr and are worth the cost of the pack.
[15:27] <philballew>  If the LoCo has gotten a conference pack before and not has a problem, it should be easy and not have to fill out as much paperwork.
[15:27] <philballew> Will we be giving away flash drives soon?
[15:27] <philballew> Distros like Fedora give those out
[15:28] <rrnwexec> +1 for deprecate
[15:28] <philballew> Inter LoCo is very needed
[15:29] <YoBoY> inter loco ?
[15:29] <skellat> dholbach: Can you join me in to the Hangout?  I finally found headphones now.
[15:29] <dholbach> skellat, sure
[15:29] <skellat><EMAIL_ADDRESS>[15:29] <philballew> +1 here
[15:30] <dscassel_> +1 deprecate.
[15:31] <elfy> +1
[15:31] <hggdh> +1
[15:34] <Cracknel> what about subteams?
[15:34] <elfy> from a forum point of view I'd agree with jorge
[15:34] <YoBoY> but these new team will be official teams or subteams of the actual loco/country/state teams ?
[15:37] <hggdh> I agree with Randall -- this would be more of a grassroots movement (which would help us)
[15:38] <dscassel_> +1 for in-person city teams. Online, I agree with Jorge. A city mailing list for our town would be dead, but the Canada list is good and helpful and I'd like to keep it that way.
[15:39] <SergioMeneses> dscassel_, sure! this is the same issue in a lot of counties
[15:40] <dholbach> grr, I just got dropped and rerouted to login.u.c - did the feed drop?
[15:41] <dholbach> jono_ (and everyone else): https://blueprints.launchpad.net/ubuntu/+spec/community-1305-enabling-local-subteams - will schedule it for thursday once it's in summit
[15:41] <dholbach> please subscribe to it if you're interested
[15:41] <fisch246> yea what sucks about minnesota is that our Loco team doesn't want to share power with anyone, and our local LUG is very um... xenophobic to put it lightly. so our events have been just one sponsored event, and just guys meeting for beers.
[15:41] <YoBoY> my experience with city teams (we have 5 in France) is they start great but they slow down fast for most of them
[15:42] <SergioMeneses> czajkowski, ↑↑↑
[15:42] <JoseeAntonioR> any opninion from the LC?
[15:43] <czajkowski> JoseeAntonioR: not all here tbh and not something that can just be resolved in 2 mins tbh, we've been looking for the last 3 months at a few options and it's not so simple so wanted to have a lot of tha facts and examples laid out to make things easy
[15:44] <YoBoY> +1 jcastro I join your locoteam now :D
[15:44] <fisch246> The sponsored event, and the beer, has nothing to do with the Loco team. The beer is me, and the sponsored event is our LUG.
[15:45] <fisch246> We did start a podcast, that is on hiatus right now. Again nothing to do with the Loco.
[15:46] <fisch246> My point is, that we have people who can lead, but our Loco team doesn't want anyone else to lead.
[15:46] <skellat> czajkowski: I'll be happy to contribute outside the UDS times and give reflections as necessary
[15:46] <czajkowski> skellat: thanks
[15:46] <JoseeAntonioR> same here
[15:47] <YoBoY> The french experience and position on city teams in France, is everyone can creat his city team, and we (the loco) try to help them with ressources (web, ML, goodies, advices…)
[15:47] <fisch246> ok i can go with that
[15:48] <srinath> hi guys
[15:48] <fisch246> cause i can take lead on the west metro side of things
[15:48] <YoBoY> but to work like that, we have to start with a well established loco
[15:50] <dshimer> Using Ohio as example, I can see local less formal groups just getting together then being a resource that "Ohio" could tap into.  They wouldn't need resources but could provide them.
[15:50] <jcastro> skellat<EMAIL_ADDRESS>is my contact info
[15:50] <dholbach> it's scheduled: http://summit.ubuntu.com/uds-1305/meeting/21812/community-r-sustainable-translations/
[15:50] <dholbach> 2013-05-16 15:05..16:00 in Community 2
[15:50] <YoBoY> skellat, if you pay the travel, I can send you some french members :D
[15:51] <dholbach> err sorry
[15:51] <dholbach> wrong link
[15:51] <dholbach> http://summit.ubuntu.com/uds-1305/meeting/21835/community-1305-enabling-local-subteams/ - here we go
[15:52] <srinath> when is the documentation team meeting??
[15:53] <srinath> sorry for barging right in
[15:54] <YoBoY> There is no possible way to really "track" the activity of a locoteam
[15:54] <dscassel_> +1 Absolutely I'll set up a city team on the LoCo directory, so long as I can keep the Ubuntu Canada mailing list, etc.
[15:55] <cprofitt> jonobacon: could there not be a way of automatically removing from 'display' teams that do not have activities scheduled on loco.ubuntu.com
[15:55] <cprofitt> some period of time -- 1 year, 2 years, etc...
[15:55] <cprofitt> I do not want the structure or formal stuff to inhibit team growth
[15:56] <YoBoY> we are not forced to use the loco portal
[15:56] <cprofitt> +1 on enabling organic growth
[15:56] <SergioMeneses> +
[15:56] <SergioMeneses> +0
[15:57] <DChapman> +1
[15:57] <commandoline> +1. My experience is teams do revive.
[15:58] <YoBoY> I'm afraid we will have a lot of empty teams in the future with that… and for users looking for a local help, it can be a problem to find an empty team…
[16:00] <balloons> for the next session, please speak up if you'd like to be in the video
[16:00] <balloons> http://summit.ubuntu.com/uds-1305/meeting/21714/community-s-quality-coverage/
[16:03] <balloons> please speak up if you'd like to be in the hangout for this session on Expanding QA community coverage
[16:03] <elfy> I'll be here and watching - as this IS the right time and place :)
[16:04] <bkerensa> balloons: \o if a slot is available but not essential
[16:04] <chilicuil> same as bkerensa
[16:05] <bkerensa> actually I will watch :)
[16:05] <cjohnston> balloons: I'm assuming you haven't started it?
[16:05] <balloons> anyone else?
[16:05] <balloons> no, I'll kick off in one moment
[16:05] <cjohnston> k
[16:05] <balloons> 5 mins is way too short
[16:06] <cjohnston> such a long way to walk
[16:06] <elfy> 5 minutes is fine from where I'm sitting with a cup of tea and my feet up :p
[16:06] <balloons> lol.. hosting sessions is a bit harder
[16:06] <elfy> :)
[16:07] <cjohnston> blah :-P
[16:07]  * thomi yawns
[16:08] <balloons> can you see the broadcast?
[16:08] <philipballew> yes!
[16:08] <elfy> balloons: nope
[16:08] <thomi> not yet
[16:08] <cjohnston> no
[16:08] <josepht_uds> no
[16:08] <balloons> try refreshing the page
[16:08] <elfy> how many times balloons
[16:08] <balloons> lol
[16:08] <balloons> my bad
[16:08]  * philipballew wonders why he can.
[16:08] <cjohnston> balloons: there aren't any urls in the db
[16:09] <balloons> whoops
[16:09] <balloons> i told you 5 mins wasn't enough
[16:09] <elfy> got it now
[16:09] <JoseeAntonioR> :P
[16:09] <cjohnston> now its there
[16:09] <thomi> me too :)
[16:09] <elfy> you might want to turn the echo off ...
[16:09] <brendand> balloons, can i hop in?
[16:10] <chilicuil> balloons: if you want I can share the link for you, so you can focus on the hangout
[16:11] <balloons> chilicuil, go for it
[16:12] <roadmr> super productive!
[16:14] <cjohnston> to those in the hangout, please use the lower third to identify yourself
[16:15] <thomi> It's worth pointing out that the 1.3 conversion is pretty trivial.
[16:15] <svwilliams> Its in the hangout toolbox
[16:15] <svwilliams> for people looking for lower third
[16:17] <svwilliams> Autopilot
[16:17] <svwilliams> balloons: wouldn't you consider autopilot one of our tools
[16:18] <balloons> svwilliams, indeed
[16:20] <chilicuil> we should add more manual testcases for all the default apps in all the ubuntu flavours
[16:21] <elfy> chilicuil: +1
[16:21] <svwilliams> chilicuil: +1
[16:21] <chilicuil> I think we should focus on that, and letting the depth coverage as a second priority
[16:22] <elfy> I didn't catch what you said balloons :)
[16:22] <svwilliams> If we had more initial coverage it might be easier for new people to help increase depth, like chilicuil at this time depth is a secondary priority
[16:22] <roadmr> do you want to be 95% sure that 5-10 apps work, or 50% sure that 50-100 apps work?
[16:23] <svwilliams> depends roadmr I'd like to be 95% sure that at least one browser works …
[16:24] <roadmr> svwilliams: ok so "variable depth" :) makes sense though
[16:24] <svwilliams> yup
[16:24] <svwilliams> :-D
[16:24] <elfy> flavors obviously have their own priorities :)
[16:26] <svwilliams> Where are we lacking, where do we feel we're lacking.   Do we have a good breadth at this point, because increasing breadth is easier (because its shallower) than increasing depth
[16:26] <svwilliams> if we have good breadth then its time to dig deep and go after depth
[16:27] <elopio> it's easier to add depth when there's already a simple test case to start with.
[16:27] <elopio> so for newcomers, adding depth is easier, if the experienced people is adding a bootstrapping set of tests.
[16:27] <svwilliams> balloons:
[16:27] <svwilliams> say that again
[16:27] <svwilliams> ?
[16:27] <balloons> elopio, true
[16:30] <svwilliams> sounds good to me
[16:30] <elopio> +1
[16:30] <Letozaf_> +1
[16:31] <svwilliams> Perhaps I'm ignorant about the methods for testing but what about Juju and Maas
[16:33] <phillw> I'm a server type person and will help out :)
[16:33] <svwilliams> I can try
[16:33] <svwilliams> too
[16:34] <Letozaf_> I can
[16:34] <chilicuil> I can help too
[16:36] <svwilliams> balloons:
[16:36] <balloons> crhrabal
[16:36] <svwilliams> fyi your sound has cut in and out
[16:37] <fisch246> i haven't had issues
[16:37] <roadmr> sound is OK here
[16:37] <elopio> I can hear you alright.
[16:38] <svwilliams> ok it may just be me :-)
[16:38] <elfy> fine here too
[16:39] <elopio> balloons: are we going to have an emulator to test touch?
[16:40] <chilicuil> that would be cool balloons
[16:40] <balloons> elopio, an emulator?
[16:41] <elopio> balloons: if somebody don't have a phone that runs ubuntu, how can he test ubuntu touch?
[16:42] <elopio> ok, thankss.
[16:43] <chilicuil> I think that just a system which could allow people to suscribe to new builds will be enough, nothing fancy to add to the qa system
[16:43] <chilicuil> lol
[16:43] <chilicuil> I though it was only for iso images
[16:46] <cjohnston> balloons: 15 minutes left
[16:47] <svwilliams> sounds good
[16:47] <svwilliams> +1
[16:54] <chilicuil> maybe sending a mail will work better on that balloons, I'd love to help, but I don't have the hardware
[16:56] <elopio> thank you balloons.
[16:56] <roadmr> \o/ thanks balloons !!
[16:56] <balloons> thank you everyone!
[16:57] <balloons> ohh is it lunchtime?
[16:57] <balloons> yay!
[16:57] <cjohnston> yup
[18:03] <balloons> k, hangout links all setup
[18:03] <balloons> please join if you'd like to express your opinion
[18:03] <balloons> without having to type so much :-)
[18:04]  * chilicuil say hello to everyone
[18:05] <philipballew> hola chilicuil
[18:05] <balloons> anyone want to join?
[18:06] <balloons> this is mainly a feedback session for you :-)
[18:07] <balloons> Letozaf_, chilicuil, phillw, philipballew, svwilliams care to hop in?
[18:07] <chilicuil> I'd like to enter balloons
[18:07] <balloons> https://plus.google.com/hangouts/_/67b89b7c84196026cc7e60116dd25e9bf09eade8?authuser=2&hl=en
[18:07] <balloons> for anyone who wishes
[18:07] <balloons> have at it
[18:07] <philipballew> gotta do a meeting in community 2
[18:08] <balloons> starting the broadcast
[18:08] <Letozaf_> ok for me
[18:12] <balloons> you'll want to mute the video from the page
[18:12] <balloons> Letozaf_, et la :-)
[18:12] <balloons> otherwise it makes for some massive delay
[18:12] <svwilliams> it's pretty funny
[18:12] <svwilliams> the delay
[18:13] <svwilliams> yeah between Hangout and the video on the UDS page
[18:13] <svwilliams> so mute the youtube video
[18:15] <Letozaf_> weired the delay :D
[18:15] <balloons> Letozaf_, yea, you have to kill the video page when you join the hangout
[18:15] <balloons> or otherwise stop the video from playing
[18:18] <Letozaf_> when I connect I start getting a delay even if I turn the video off
[18:18] <balloons> a delay from what? :-(
[18:18] <balloons> try turning everything off to audio only
[18:18] <Letozaf_> I hear you guys talk after  a while
[18:18] <fisch246> finally the kiwi is working now
[18:20] <chilicuil> not sure if I'm using the correct words =), I mean that the tracker should take more active actions to show in the testing tracker the bugs reported against the packages we're testing
[18:21] <chilicuil> yeah, a more verbose option
[18:22] <balloons> Letozaf_, after joining there's a button in the top right that looks like a phone reception icon
[18:22] <chilicuil> yeah, launchpad itself does a good job finding duplicates
[18:23] <Letozaf_> maybe we just need some classroom sessions on how to search bugs correclty
[18:23] <balloons> you can lower the bandwidth requirements to audio only
[18:23] <balloons> that should help
[18:25] <chilicuil> yeah or the most common
[18:25] <phillw> we are planning to re-run some of the classroom sessions from https://wiki.ubuntu.com/Testing/Activities/Classroom as some of our testing tools are now functioning better in 13.04
[18:26] <chilicuil> phillw: that'll be nice
[18:26] <sak> If we are talking about finding duplicate bug, could bugs of the same program are made, be put under one category?
[18:26] <Letozaf_> can you send me the link again I lost it
[18:26] <balloons> Letozaf_, https://plus.google.com/hangouts/_/67b89b7c84196026cc7e60116dd25e9bf09eade8?authuser=2&hl=en
[18:26] <balloons> and anyone else who wishes to join :-) https://plus.google.com/hangouts/_/67b89b7c84196026cc7e60116dd25e9bf09eade8?authuser=2&hl=en
[18:27] <chilicuil> we need to make emphasis in the fact that running tests and finding issues is a good thing, we don't need lots of tests without results
[18:28] <Letozaf_> when I connect its a mess, I lowered bandwidth and turned video and audio off
[18:30] <chilicuil> Letozaf_: =/, it's somekind slow here as well
[18:30] <Letozaf_> chilicuil: fiew! I was worried :D
[18:31] <balloons> sorry guys :-)(
[18:31] <balloons> feel free to participate via irc
[18:31] <balloons> no worries
[18:32] <Letozaf_> I think that maybe it's just a problem due to that people do not understand how to report a bug
[18:33] <Letozaf_> so I think the problem could be solved with some classrooms or hangouts on bug reporting
[18:33] <Letozaf_> maybe some tips and tricks on bug reporting
[18:33] <svwilliams> Do we have tips and tricks for offline bug reporting … how do I report about a machine that can't connect
[18:34] <svwilliams> A) do x to get log
[18:34] <Letozaf_> maybe a video is easier than reading an how to :D
[18:34] <Letozaf_> liek the ones done for testing ISO-s
[18:34] <chilicuil> that surely can help Letozaf_
[18:36] <roadmr> I would only resort to video if it's something hard to show on a document (like tying a bow tie)
[18:36] <roadmr> the reason is that most people can read and process faster than what a video can show - there, you're limited to the presenter's speed
[18:36] <Letozaf_> maybe someone good ad reporting bugs can have a kind of tips and tricks to avoid reporting duplicate bugs :D
[18:37] <balloons> roadmr, I agree.. I speed read, so I like text ;-)
[18:39] <Letozaf_> have some tips and tricks to avoid duplicate bugs
[18:39] <chilicuil> I dont think we need a desktop client
[18:39] <Letozaf_> audio is coming and going here :(
[18:42] <phillw> bzr is still on my to-do list :)
[18:42] <svwilliams> could you repeat your question
[18:43] <simosx> I suppose that people do not use the ISO tracker because it's a new thing to learn, and they would rather have a walkthrough document.
[18:43] <sak> Still need more training on merging a testcase. The bzr howto, is very technical
[18:43] <simosx> Is there a walkthrough document?
[18:43] <Letozaf_> I do not find the tracker difficult, but I do not know about the others
[18:43] <chilicuil> who has birds nearby ? =)
[18:44] <balloons> https://wiki.ubuntu.com/QATeam
[18:44] <phillw> the bzr one is at http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
[18:44] <Letozaf_> sounds better now
[18:44] <balloons> https://wiki.ubuntu.com/Testing/QATracker
[18:45] <balloons> https://wiki.ubuntu.com/QATeam/ContributingTestcases
[18:46] <simosx> thanks
[18:47] <chilicuil> idea: add the 'contribute an manual|automatic testcase' to the ubuntu accomplishment system
[18:47] <svwilliams> +1
[18:47] <svwilliams> maybe a couple accomplishments around testcases
[18:47] <brendand> svwilliams, there is a way to save the apport info for reporting later
[18:48] <chilicuil> I can do it balloons
[18:48] <Letozaf_> I also hear the birds :D
[18:49] <chilicuil> nooo! I enjoy the sound =)
[18:49] <svwilliams> brendand: I did that while testing maas and when I tried to grab it the report didn't save … should have submitted that as a bug but it was late
[18:49] <sak> What does the "accomplishment" do?
[18:49] <balloons> https://wiki.ubuntu.com/Accomplishments
[18:50] <brendand> svwilliams, what did you try exactly?
[18:50] <maclin> balloons: I have a question about how to show the testcases in Chinese on tracker? or is it needed?
[18:51] <Letozaf_> maybe put some links to the documentation in the tracker
[18:51] <sak> So the "accomplishments" it is a summary of your contributions?
[18:52] <svwilliams> oh man … balloons was helping I don't remember it was a way to save the system log to a location and I saved it to a root of one of my partitions but there was no file there when I logged in with my main partition
[18:52] <roadmr> wouldn't translations have to go both ways? unless you have someone who can read chinese "transcribing" the reports, if someone can't read english it's reasonable to assume they also can't write it, so translation would be needed twice
[18:52] <simosx> sak, "accomplishments" is a program that you run on Ubuntu, and whenever you perform one of the supported tasks, you get a badge/star that you have accomplished it.
[18:53] <chilicuil> maybe if we export the testcases as a package or something to launchpad, i18n teams could treat it as other packages languages, doing it possible to translate them, the spanish team for instance I'm almost sure could translate them in no time
[18:53] <Letozaf_> I find submitting results easy, maybe we should just make the documentation much easier to find by putting links in the tacker
[18:53] <sak> Thank. Good way to keep of what you have done and what need to be done
[18:54] <maclin> ok,thanks
[18:57] <chilicuil> thanks for the session =)
[18:57] <Letozaf_> audio keeps on coming and going her :(
[18:57] <balloons> thanks :-) Sorry the hangout didn't work out so well
[18:58] <balloons> was it me Letozaf_ ?
[18:58] <fisch246> i still have yet to have audio issues
[18:58] <roadmr> balloons, Letozaf_ : I don't think so, it was rock-solid on my end (watchiing the youtube stream)
[18:58] <balloons> or everyone? I suppose I was the one talking
[18:58] <Letozaf_> no I do not think so
[18:58] <sak> this was good
[18:58] <balloons> ok..
[18:58] <Letozaf_> I have had problems during
[18:58] <balloons> I just get nervous hearing it :-)
[18:58] <Letozaf_> the whole hangout
[18:58] <roadmr> thanks balloons !
[18:58] <balloons> thanks everyone!
[18:59] <Letozaf_> thank you balloons: