[01:48] <snele> sgclark: I can test trusty backports when you finish it
[01:48] <snele> will it be in staging ppa?
[01:48] <sgclark> snele: yep, still one left to try and fix the build
[01:48] <sgclark> yeah staging-kdeapplications
[01:49] <sgclark> hush vivid, I will get to you
[04:20] <valorie> santa_: sorry for being non-responsive thus far
[04:20] <valorie> I'll read and respond to my email tonight
[04:27] <sgclark> snele: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-kdeapplications trusty applications ready for testing
[04:27] <sgclark> !testers
[04:27] <sgclark> ^^
[04:28]  * sgclark out
[04:35] <valorie> niters sgclark
[04:35] <valorie> thanks for your work!
[08:46] <snele>  sgclark: upgrade didn't go smooth. there are errors: https://paste.kde.org/phoidccyk
[08:49] <snele> sgclark: https://paste.kde.org/po6tolwyy
[10:23] <Mamarok> hm, we might have a packaging error for amarok 2.8.90, if I trust this guy https://bugs.kde.org/show_bug.cgi?id=323802#c18
[10:23] <Mamarok> amarok should drag in MySQL by default
[10:25] <Mamarok> and amarok should be removed if something else removes MySQL
[10:26] <Mamarok> so at least the user would get aware that this could cause havoc
[10:48] <yofel> needs investigation what exactly amarok uses from mysql. It does depend on libmysqlclient18, so any API calls should succeed, but if you do shell calls to mysql binaries then that's a different story
[11:05] <BluesKaj> Hiyas all
[11:50] <santa_> valorie: no prob
[13:10] <shadeslayer> jmux: ping
[13:11] <shadeslayer> jmux: is there going to be a Munich BSP this year
[13:42] <marco-parillo> sgclark: I upgraded my 14.04 VM (It has been a while), rebooted, then I added deb http://ppa.launchpad.net/kubuntu-ppa/staging-kdeapplications/ubuntu trusty main to my software sources. Looks like KDE Apps 4.14.3 are available.
[13:42] <marco-parillo> Is there some kind of signing issue? I get a warning (The following pieces of software cannot be verified. WARNING: Installing unverified software represents a security risk, as the presence of unverifiable software can be a sign of tampering. Do you wish to continue?)
[13:43] <marco-parillo> Of course, I click continue, like 99% of folks who get malware ;-)
[13:50] <marco-parillo> sgclark: I got an error: /var/cache/apt/archives/kde-window-manager-common_4%3a4.11.14-0ubuntu1~ubuntu14.04~ppa6_i386.deb trying to overwrite '/usr/share/doc/kde/HTML/en/kcontrol/windowbehaviour/index.cache.bz2', which is also in package kde-workspace-data 4:4.11.11-0ubuntu0.2
[13:51] <marco-parillo> It says a re-boot is required, so I will try that, and re-try from the command line (I had been using Muon Update Manager).
[14:07] <marco-parillo> Well, my Trusty VM is unusable after trying to upgrade the KDE apps. I had no windowing, so I had to ctrl alt F1 to get a tty. I logged in, tried to update && upgrade again, but got a ton of errors I could not paste.
[14:42] <jmux> shadeslayer: we were just talking today, that nobody made a plan yet - too busy
[14:43] <shadeslayer> oh :D
[14:44] <jmux> I would still make one end of next month - as every year - but I don't want to do the preparations for 5 people
[14:44] <jmux> people here felt we're already too late
[14:45] <shadeslayer> jmux: yeah it seems a bit late, but I'd still be in
[14:46] <jmux> If we can get a quick feedback of 10-15 people, who would come too Munich, I can probably still organizing a BSP
[14:46] <shadeslayer> as long as it's not between 16th to 18th :P
[14:46] <jmux> I know LibreOffice is doing an other hackfest 2nd - 4th December in Madrid
[14:46] <shadeslayer> jmux: I can come, as long as it's not those dates ^ :D
[14:46] <shadeslayer> jmux: oh :D
[14:46] <shadeslayer> jmux: could merge with that, I'd get to ride a train then :>
[14:47] <jmux> They had a hackfest in Hamburg two weeks ago
[14:49] <shadeslayer> jmux: send a email out I guess
[14:49] <shadeslayer> and find out
[14:53] <jmux> shadeslayer: hmm. kde-devel, kubuntu-devel...
[14:53] <shadeslayer> jmux: debian-qt-kde
[14:56] <jmux> Ok. Guess I should add a doodle to collect feedback.
[15:18] <yofel> count me in!
[15:27] <jmux> So I just re-checked, there is actually money :-) Still need to get some approval, which I should get on Wednesday.
[15:28] <jmux> Now for the mail and the doodle...
[15:52] <sgclark> marco-parillo: hmm that sounds terrible. got any apt logs I can look at?
[15:53] <clivejo> ok dolphin is crashing again when Im trying to open the menu to delete an item
[15:55] <marco-parillo> sgclark: Sorry, it blew away my VM and there was nothing I could do with it.
[15:55] <clivejo> https://paste.kde.org/pltbchtlb
[15:56] <marco-parillo> Not your fault; my noob.
[16:07] <mhall119> last call, is there anybody who can give an hour presentation of Plasma Mobile as the Ubuntu Online Summit next week?
[16:16] <jmux> shadeslayer, yofel: https://dudle.inf.tu-dresden.de/LiMux_Hackfest_2015/
[16:17] <shadeslayer> mhall119: one hour :S
[16:17] <shadeslayer> I don't think there's enough info for a hour
[16:20] <tsdgeos> shadeslayer: apol and me spoke about it 35 min the other day don't think 1h would be horrible tbh https://www.youtube.com/watch?v=9PtE8g8ldS0
[16:20] <shadeslayer> mhall119: I found your guys ^
[16:20] <shadeslayer> :P
[16:20] <tsdgeos> but i'm not doing it again :D
[16:21] <mhall119> shadeslayer: tsdgeos: someone in #plasma is also volunteering, perhaps you can all go in together on it?
[16:21] <shadeslayer> I'm already doing the CI thingamajig with sitter
[16:21] <tsdgeos> mhall119: i know nothing about plasma mobile ;D i'm just in that video as sparring asking questions
[16:26] <shadeslayer> k, cya on Monday
[16:27] <jmux> BTW - everybody else is also free to add themself, if they want to hack in Munich too: https://dudle.inf.tu-dresden.de/LiMux_Hackfest_2015/
[16:27] <sgclark> would love to, but no idea how I would get therre
[16:57] <ghostcube> oha weisswurst hacking event
[16:57] <ghostcube> :D
[16:58] <sgclark> kde-workspace updated. trusty needs further testing
[16:58] <sgclark> !testers
[16:58] <sgclark> ^^
[17:12] <pursuivant> muon (master) v5.4.2-154-g4b469ec * Aleix Pol: libmuon/backends/ApplicationBackend/Application.cpp
[17:12] <pursuivant> Fix build on Ubuntu
[17:12] <pursuivant> Too much replace
[17:12] <pursuivant> CCMAIL: jr@jriddel.org
[17:12] <pursuivant> http://commits.kde.org/muon/4b469ecc51795d5d76c7fc894f184e0242a582cc
[18:05] <pursuivant> muon (master) v5.4.2-155-ge3c5ce6 * Aleix Pol: discover/qml/MuonToolButton.qml
[18:05] <pursuivant> use tighter QtQuick dependency
[18:05] <pursuivant> http://commits.kde.org/muon/e3c5ce632805a52a2e5865e7685b5fc2d73aa9cd
[18:06] <pursuivant> muon (master) v5.4.2-156-g78a4813 * Aleix Pol: libmuon/backends/ApplicationBackend (2 files)
[18:06] <pursuivant> We already know if the process is running
[18:06] <pursuivant> No need to keep a variable to keep track of it.
[18:06] <pursuivant> http://commits.kde.org/muon/78a4813fa32cd69065e06fe7969186385c980560
[18:06] <pursuivant> muon (master) v5.4.2-157-g594f75c * Aleix Pol: libmuon/backends/ApplicationBackend/ApplicationNotifier.cpp
[18:06] <pursuivant> adopt new connect syntax
[18:06] <pursuivant> http://commits.kde.org/muon/594f75c55188705924231d86dcadf8c38a238b5b
[20:09] <valorie> sgclark: surely Ubuntu Community Fund would send you to Munich to fix bugs?
[20:11] <yofel> valorie: it would surely also send you over to motivate us all ;)
[20:11] <yofel> meh, it seems like quite a few people used geotagging in digikam
[20:12] <valorie> haha
[20:12] <valorie> that doesn't seem a wise use of the money
[20:13] <valorie> geotagging is useful!
[20:13] <yofel> yeah, except that we removed it in wily..
[20:13] <valorie> Munich sounds fun, for sure
[20:13] <valorie> oh, why?
[20:13] <yofel> because digikam is qt4 and marble qt5
[20:13] <valorie> ah
[20:13] <yofel> and we didn't upload another qt4 version of marble
[20:13] <valorie> that's a beast that needs porting
[20:14] <valorie> or well I guess updating the qt4 marble would be good enough?
[20:15] <yofel> we could put it in a PPA with a new digikam build, someone would need to package it though and make sure it doesn't conflict with marble(-qt5)
[20:16] <yofel> we need to packages digikam 4.14 as well (last qt4 release)
[20:17] <sgclark> oh yeah was reading that bug right nnow
[20:17] <sgclark> so why did we remove it?
[20:17] <sgclark> yeah need to package kdevelop last qt4 and new kf5 beta
[20:17] <yofel> because building both qt4 and qt5 marble from the same package doesn't work, and nobody had time to re-package a marble-qt4
[20:17] <sgclark> so much to do
[20:18] <sgclark> ah
[20:19] <sgclark> I am trying to debug my trusty updates and reproduce the explosion mparillo had.
[20:20] <sgclark> still have vivd backports too
[20:20] <yofel> problem with those is that we do a rather bad job at tracking moved files after multiple releases and multiple debian merges
[20:20] <yofel> let me install trusty in a VM
[20:20] <sgclark> yeah
[20:20] <sgclark> thanks
[20:22] <sgclark> well found problem one: libkdedecorationsabi1 
[20:23] <sgclark> so abi need breaks replaces?
[20:23] <sgclark> seems like that should be done by manager
[20:23] <yofel> if it contains anything other than the lib, yes
[20:23] <sgclark> okies fixing
[20:26] <sgclark> hmm there is a breaks replace in there
[20:29] <sgclark> ahh right ok, dummy me, have to do dist-upgrade due to the new dependencies
[20:29] <sgclark> mparillo: did you do dist-upgrade?
[20:30] <yofel> file overwrites are unrelated to the upgrade type though... let me read the error message again
[20:31] <sgclark> hmm shouldnt be any file overwrites , I fixed the one in kde-workspace
[20:34] <yofel> oh, that breaks/replaces is useless. trusty-updates has kde-workspace-data 4:4.11.11-0ubuntu0.2, the B/R is kde-workspace-data (<< 4:4.11.11)
[20:34] <yofel> 4:4.11.11-0ubuntu0.2 > 4:4.11.11
[20:35] <sgclark> hmm insstalled fine here
[20:35] <yofel> should be << 4:4.11.14~ or os
[20:35] <yofel> *so
[20:35] <yofel> yes, because the order in which apt upgrades packages is non-deterministic
[20:35] <sgclark> ok
[20:36] <yofel> it depends on how the algorithm orders the packages to resolve dependencies
[20:37] <yofel> which is why a simple upgrade test is not a sufficent test case for file overwrites, but to properly detect those you would need to read the whole install files diff
[20:37] <yofel> maybe one could integrate something like that into the CI with a simple hashmap file DB or so which checks if a file was already in a package in the past
[20:38] <yofel> that would then also catch files that moved between sources
[20:39] <sgclark> I think it is in CI, problem is trusty packages are not :(
[20:40] <yofel> yeah :/
[20:42] <sgclark> uploaded fixed kde-workspace
[20:42] <sgclark> will need testing after build
[20:46] <yofel> sgclark: what's supported as upgrade path? trusty -> new backports and trusty+old backports -> new backports?
[20:48] <sgclark> hmm not sure. I did trusty updates, then rebooted and added the ppa and then dist-upgrade with success
[20:48] <sgclark> did not try a path with backports
[20:48] <sgclark> though I reckon it needs to be tested
[20:49] <yofel> it does, as that's where the packages will end up, so all that have the backports enabled will go that path
[20:49] <yofel> I guess I'll start with that then
[20:49] <sgclark> thank you
[20:50] <sgclark> wait for kde-workspace to build though
[20:50] <yofel> will do, my VM is still installing anyway ^^
[20:50] <sgclark> :)
[21:00] <ahoneybun> mm 
[21:00]  * yofel sees ahoneybun and remembers that he forgot something
[21:00] <yofel> dangit
[21:01] <ahoneybun> lol
[21:01] <ahoneybun> I did not mean it like that 
[21:01] <yofel> XD
[21:02] <ahoneybun> but I'll take it lol
[21:05] <mparillo> sgclark: I first tried muon (which I assume does not do a dist-upgrade), but when I pretty much had no gui after a re-boot, I did update && upgrade && dist-upgrade from apt.
[21:06] <yofel> hm.. plasma2, so nostalgic :D
[21:07] <sgclark> lol
[21:07] <sgclark> hmm
[21:08] <sgclark> yofel: muon updater does not dist upgrade? that could be a problem
[21:09] <yofel> I don't know actually.. let me check
[21:09] <sgclark> though this is not the first mass updates, seems like this issue would have come up in the apst
[21:09] <sgclark> past
[21:09] <yofel> hm, if I just add the backports ppa, then muon-updater does ask me to remove 3 packages. That's a dist-upgrade
[21:09] <sgclark> mparillo: did you do a dpkg --force overwirte on that package that failed?
[21:10] <sgclark> ok cool, good to know
[21:10] <sgclark> so that is not it.
[21:10] <sgclark> seems like kde-workspace did not get installed, it has since been fixed
[21:11] <sgclark> which is why testing is so important!
[21:12] <mparillo> sgclark: I did not dpkg -- force; when I was on the commandline it said something like apt install -f, which I did try.
[21:13] <sgclark> ok so kde-workspace did not get installed, that is why your gui exploded
[21:13] <sgclark> that has been fixed, thanks to your testing, sorry for the loss of your VM 
[21:16] <mparillo> sgclark: My pleasure to help out. I actually miss 14.04 (and really miss 14.10), but I do not miss that VM. BTW, I am back home now, so I am re-creating the 14.04 VM on my work laptop, while I can IRC on my netbook (Kubuntu is the only Plasma5 distro that is happy on a 1GB netbook).
[21:16] <yofel> protip: use VM snapshots for testing ;)
[21:17] <snele> sgclark: did you get my messages about trusty backports?
[21:17] <sgclark> yeah I had snapshots at one point. really need to set that up again
[21:17] <sgclark> snele: hmm no
[21:20] <snele> sgclark: upgrade didn't go smooth. there are errors: https://paste.kde.org/phoidccyk
[21:20] <snele>  sgclark: https://paste.kde.org/po6tolwyy
[21:20] <sgclark> snele: kde-workspace is now fixed
[21:21] <sgclark> which is the source of that mess
[21:21] <sgclark> and thanks to testers it was caught and fixed!
[21:22]  * yofel kicks the publisher
[21:22] <yofel> it's in weekend mood -.-
[21:22] <sgclark> lol
[21:22] <soee_> yofel: this "bug" with notification spam when there are some updates its part of kde/plasma or ubuntu/kubuntu releated stuff /
[21:22] <yofel> "spam" ?
[21:22] <yofel> I only ever see one notification when there are updates
[21:23] <sgclark> snele: as soon as it publishes an apt update and dist-upgrade should sort it all out.
[21:23] <soee_> yofel: yes, when apt update command is fetching packages, and there are some updates, we see notification every few seconds
[21:23] <sgclark> I only see one
[21:23] <soee_> a bit annoying tbh
[21:23] <sgclark> I am on CI though so it must have been fixed upstream?
[21:23] <yofel> ah, that might be due to how apt-check works..
[21:24] <yofel> now the question is whether that's from muon-updater or kubuntu-notification-helper (I think it's the updater)
[21:24] <soee_> sgclark: always one time notification ?
[21:24] <sgclark> got one notification and have a red icon in tray
[21:26] <sgclark> snele: yofel updated kde-workspace has published
[21:26] <yofel> so, did an apt update. 3 updates before, 3 updates after it and no notification at all
[21:27] <soee_> yofel: 15.10 ?
[21:27] <yofel> yep
[21:27] <sgclark> oh hmm I have no updates and it is red, that is unexpected
[21:28] <mparillo> yofel: For VM snapshots, I think I would have to upgrade my VMware Player to Workstation. Fortunately my work laptop makes installation relatively quick. And re-start is complete. Step 1 is to upgrade, dist-upgrade 14.04 and re-boot?
[21:28] <clivejo> is red not bad?
[21:28] <sgclark> when I see red I expect attention is required
[21:28] <clivejo> ditto
[21:28] <yofel> red in the updates means security updates I believe
[21:29] <sgclark> that is what I would expect, but my system has no updates
[21:29] <sgclark> System up to date
[21:29] <clivejo> pending reboot?
[21:29] <sgclark> but red >.<
[21:29] <sgclark> oh hmm
[21:29] <clivejo> been a few kernel updates recently
[21:29] <sgclark> don't think so , but perhap, used to get another notification for that though
[21:30] <sgclark> rebooted today
[21:30] <soee_> sgclark: this is how it behaves now, if you do updates those icons stay in systray till reboot 
[21:30] <soee_> or also after reboot
[21:30] <sgclark> it remains red forever because I had security updates? that does not seem logical
[21:31]  * yofel might be wrong..
[21:31] <sgclark> ok rebooting to see for myself, I am now curious
[21:32] <yofel> hm, here updater doesn't seem quite in sync with apt
[21:32] <yofel> installed all 3 updates, now I still have a green symbol telling me that I have 3 pending updates
[21:34] <soee_> yofel: @ this notification spam, i think the slower connection/more time it need to fetch packages, the more the same notification we see
[21:34] <soee_> i remember on a slow connection i'v seen it like 20 times
[21:36] <yofel> which makes be really believe that this is related to apt-check. That can trigger multiple times during an update run
[21:38] <soee_> my top 3 'visual' bugs in 15.10: 1. missing nm/plasma-pa icon in systray (plasma devs tries to fix it, but no fix yet), 2. updates icon stays in systray when there are no updates, 3. updates notification spam :)
[21:40] <sgclark> ok reboot and now my updates icon is green and in the hidden icons panel
[21:40] <sgclark> which is fine
[21:40] <sgclark> but I have to enter my wifi password every time now. Which is exteremly annoying
[21:41] <snele> sgclark: i can confirm that apt update, apt install -f and apt dist-upgrade   fixed issue. Thank you for doing backports
[21:41] <sgclark> excellent, thanks for testing!
[21:43] <yofel> boom
[21:43] <yofel> Unpacking plasma-dataengines-workspace (4:4.11.14-0ubuntu1~ubuntu14.04~ppa8) over (4:4.11.11-0ubuntu0.2) ...
[21:43] <yofel> dpkg: error processing archive /var/cache/apt/archives/plasma-dataengines-workspace_4%3a4.11.14-0ubuntu1~ubuntu14.04~ppa8_amd64.deb (--unpack):
[21:43] <yofel>  trying to overwrite '/usr/share/kde4/apps/plasma/shareprovider/im9/metadata.desktop', which is also in package plasma-widgets-workspace 4:4.11.11-0ubuntu0.2
[21:43] <yofel> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[21:43] <snele> sgclark: about your wifi password problem, I usually fix it by removing connection and then connect again to that network
[21:43] <sgclark> will try thanks
[21:44] <sgclark> yofel: err ok fixing
[21:44] <sgclark> how much longer is trusty supported?
[21:44] <sgclark> this is clunky :(
[21:44] <yofel> april 2019
[21:44] <sgclark> ouch
[21:45] <yofel> well, that does not include our PPA, but it is nice to care about it. (And we usually do that until the next LTS is out)
[21:45] <yofel> so, april next year
[21:45] <sgclark> ok
[21:46] <soee_> http://www.phoronix.com/scan.php?page=news_item&px=Fedora-KDE-SIG-Loss
[21:46] <sgclark> I don't see kde putting out much more in qt4, though do you know if they will?
[21:46] <yofel> I don't think they will. Maybe the occasional security patch or so
[21:47] <yofel> oh right, I did want to upload that sddm CVE
[21:49] <mparillo> sgclark: My 14.04 VM is dist-upgraded. Ready for me to re-try the PPA?
[21:49] <sgclark> nah gotta wait again, yofel found another boom
[21:50] <sgclark> fixing now
[21:50] <mparillo> I can wait. Dinner soon however. BTW, can the PPA be applied by adding the source in Muon-updater, and using it? Or do I need to also apt dist-upgrade?
[21:51] <sgclark> muon will dist-upgrade
[21:51] <soee_> uh finally it has Critical importance https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1501041
[21:52] <mparillo> TY. So I will wait for the testers call then?
[21:52] <sgclark> yeah uploading now, but needs to build
[21:53] <valorie> may I just say: y'all rock
[21:53] <valorie> and I love you all
[21:53]  * sick_rimmit Waves, Nods and Grins
[21:53] <sick_rimmit> Yes.. Y'all do 
[21:53] <yofel> :)
[21:54] <sgclark> :)
[22:13] <mparillo> valorie: {{{hugs}}}
[22:14] <valorie> thank you mparillo!
[22:14] <valorie> {{{{{{{{{{hugs}}}}}}}}}}} to you as well
[22:14] <mparillo> P.S. During the drama, I tried Fedora 22 KDE. Not even close. 
[22:15] <valorie> I love that we are on the cutting (and even bleeding) edge
[22:15] <valorie> AND that we take care of our silent LTS users
[22:15] <valorie> all those people who never file a bug report or complain on IRC/lists/forums
[22:15] <yofel> Fedora has it's use cases, but it's more for devs I think
[22:16] <yofel> opensuse is usually the RPM user distro
[22:18] <sgclark> I have not really found a distro I hated. I have enjoyed most at one time or another. Community is what has kept me here the longest.
[22:19] <mparillo> yofel: True, but some RPMs that claim to be both for Fedora and OpenSUSE are only really tested on Fedora (I have been burned).
[22:19] <mparillo> sgclark: +1
[22:19] <valorie> so true, sgclark
[22:20] <valorie> same experience here
[22:23] <ScottK> Before I used Kubuntu, I tried OpenSUSE, which was a disaster (this was in 2006, so don't hold it against them).  I gave up when the attitude of the people that had broken the latest OpenSUSE release was that if I wanted it to work, I should be using SLED.
[22:24] <mparillo> And SLED (at least today) defaults to gnome.
[22:25] <ScottK> At the time, I don't think it did.
[22:25] <ScottK> Either way, it led to me having a requirement for a distro I used to not be a 'community edition' of the real product.
[22:27] <sick_rimmit> We have a brilliant community here, I have been hanging around Linux and Open Source since the Dark Ages. We have a special friendly environment.
[22:28] <sick_rimmit> I am really hoping to do my part in growing and developing that..
[22:28] <ScottK> As long as you keep your head down and don't get the CC annoyed at you, sure.
[22:29] <sick_rimmit> Well I think my contribution sits in Promotion, Advocacy and Talk..
[22:29] <sick_rimmit> I do lots of Talking
[22:29] <sick_rimmit> I like talking
[22:29] <sick_rimmit> and there is chance I might be good at it
[22:29] <sick_rimmit> I'm worried about packagers and release managers..
[22:30] <sick_rimmit> I've tried working on packaging. I can do it, but it takes a lot of focused time
[22:30] <sick_rimmit> This is something I have very little of, family, young children, work
[22:30] <sick_rimmit> So I run around saying
[22:31] <sick_rimmit> "Yay Kubuntu, try it. It's ACE!"
[22:31] <sick_rimmit> lol
[22:33] <ahoneybun> the community is +1 to me as well, openSUSE I find a big hard to get into
[22:34] <valorie> ScottK: that is a concern, since I think we all continue to object to the canonical IP policy
[22:34] <valorie> and I for one will not let that go
[22:35] <ScottK> I worry less about the fact that people are objecting and more about how the fact that the CC got tired of hearing about it was handled.
[22:35] <valorie> we aren't just "open source"
[22:35] <valorie> we're free and open
[22:35] <clivejo> are the KCC putitng out a statement about who is taking over from Jonathan?
[22:35] <ScottK> Need to decide first.
[22:35] <valorie> clivejo: should we?
[22:35] <ScottK> valorie: You need to pick a release manager.
[22:36] <sgclark> yofel and me as backup
[22:36] <valorie> it has to be one person?
[22:36] <ScottK> For a long time it's been JR and me as assistant.
[22:36] <valorie> I'd like to see a team
[22:36] <clivejo> I dunno, I thought thats what you guys do!
[22:36] <ScottK> valorie: Primary and alternate is great.
[22:36] <sgclark> yofel as main and me as backup!
[22:36] <ScottK> clivejo: release management is a technical function.  KC does is broader than that.
[22:36] <valorie> ok, as long as both people are trained
[22:36] <clivejo> I was expecting a statement following Jon's stepping down
[22:37] <valorie> KC is mostly about Kubuntu members
[22:37] <sgclark> trained?
[22:37] <sgclark> by whom?
[22:37] <yofel> right, that's the plan, we just didn't send a mail out yet. I'll talk to the release team over the weekend about how what where we should do that
[22:37] <ScottK> valorie: You also get to decide non-technical policy and stuff.
[22:37] <valorie> sgclark: I'm worried about the bus factor
[22:37] <sgclark> bus factor?
[22:37] <ScottK> I'm happy to assist/train.
[22:37] <valorie> life happens, as we've seen
[22:37] <valorie> ScottK: cool
[22:38] <sgclark> yofel and I already agreed to team it, he just is taking lead
[22:38] <valorie> bus factor = what happens when the expert gets hit by a bus?
[22:38] <valorie> thanks yofel
[22:39] <sgclark> I think more than two is too many cooks in the kitchen
[22:39] <valorie> I'm willing to write a press release if that is a useful thing
[22:39] <yofel> valorie: number of people that have to be hit by a bus for a project to die
[22:39] <valorie> sgclark: a small number is good if there is some documentation
[22:39] <valorie> IF
[22:40] <valorie> and I assume that the job has changed some over the years
[22:40] <valorie> yofel: yes, I've heard that version too
[22:40] <ScottK> One challenge both of you will have that neither JR nor I did is that you aren't on the ~ubuntu-release team.  That's not essential, but it does make some things easier.
[22:41] <ScottK> To up your chances of being on the team, you want to get core-dev.
[22:41] <sgclark> so we have yofel -> me -> and ScottK to assist, I think we will survive
[22:41] <yofel> right, but I think we'll manage still - we'll just be slower
[22:41]  * yofel aims for MOTU first, then I'll go from there
[22:41] <ScottK> Yeah.
[22:41] <sgclark> same
[22:41] <ScottK> Good plan.
[22:41] <yofel> I at least need new-source upload rights, otherwise things will get painful
[22:41] <sgclark> I am willing to put inn the effort to be on the necessary teams
[22:42] <sgclark> in
[22:43] <sgclark> kde-workspace is ready yofel mparillo
[22:43] <sgclark> please test :)
[22:44] <valorie> sgclark: what I meant by training was having someone to answer questions, and just learning on the job
[22:44] <valorie> shadeslayer can tell you about the joys of MOTU
[22:44] <valorie> :-)
[22:44] <sgclark> that depends , has Jonathan said anything about training yofel?
[22:44] <ScottK> yofel: You might want to consider just syncing Kf5 from Debian this cycle.  maxyz has been pretty quick about uploading new releases and it would make things easier.
[22:45] <valorie> ScottK: does that mean junking the CI work?
[22:45] <ScottK> I don't know.
[22:45] <yofel> I'm not sure how good that'll work out with our branches, but that would be a good idea probably
[22:45] <ScottK> It all comes out of the same git repositories, so it may just mean pointing at different branches.
[22:45] <sgclark> I do not wish to junk that, but I don't know that we have a server to keep it on
[22:45] <valorie> well, doesn't ubuntu now have CI?
[22:46] <yofel> OTOH, if we can do easy merges, then that would also be an idea
[22:46] <yofel> ubuntu uses CI for autopackagetests at least
[22:46] <sgclark> yeah but it does nt have the tololing harald worked on for kde specific stuff
[22:46] <sgclark> tooling
[22:46]  * sgclark can't type
[22:47] <sgclark> I could likely take it over , but I do not have the resources to host it
[22:47] <valorie> would be good to get that moved onto Ubuntu infra, IMO
[22:47] <valorie> or work out something with Harald/JR
[22:47] <valorie> not sure what they are up to, technically
[22:48] <yofel> I can help out with the hosting for the time being if we really need to set up our own
[22:48] <yofel> we'll see
[22:49] <sgclark> Mark ddid say to let him know if we need anything, so there is that
[22:50] <valorie> heh
[22:51] <valorie> hmmm, sitter isn't here -- I would value his insight
[22:51] <valorie> Riddell: anything to add?
[22:51] <maxyz> It shouldn't be that hard to merge the debian branches into the unstable ones. Feel free to ping me if you find a big divergence.
[22:51] <sgclark> thnas maxyz :)
[22:51] <sgclark> err thanks
[22:52] <yofel> it certainly not hard to merge them, I'm just curious if there's a reasonable way to automate it
[22:52] <yofel> *it's
[22:54] <maxyz> If you promise me that the person that signs the uploaded tags knows about them I'll consider to start merging them again...
[22:54] <sgclark> fiddle with this  https://github.com/apachelogger/kubuntu-repo-merge ?
[22:54] <maxyz> But right now I need to go to bed
[22:54] <sgclark> night :)
[22:55] <sgclark> signs the uploaded tags - what does that mean?
[22:56] <sgclark> afk
[23:04] <santa_> yofel: do-all git merge ... ?
[23:04] <yofel> right, I'm more wondering about how to handle conflicts (e.g. changelog)
[23:05] <santa_> I think there was something to handle that automagically
[23:06] <yofel> there is dpkg-mergechangelogs
[23:06] <yofel> need to look how to use that again
[23:07] <santa_> regarding the packaging, I don't think syncing packages from debian is a good solution, but merging the branches and upload the packages
[23:08] <santa_> I can help with that, my only problem, as usual, is the lack of permissions everywhere
[23:16] <ScottK> I'm sure the fact that you're banned from Debian Qt-KDE doesn't affect that opinion.
[23:20] <sgclark> well we need to do whatever results in the best end user experience while we rebuild our process
[23:22] <santa_> ScottK: well, banned or not I can help with the upload of new packages to kubuntu, however not having permissions to do things such as uploading to ppa's - for instance - limits my ability to help, obviously
[23:23] <sgclark> it is an LTS so stability is of great importance
[23:23] <sgclark> santa_: you  have to apply for kubuntu dev then
[23:23] <santa_> sgclark: yep, in process to get the kubuntu membership already
[23:24] <sgclark> ok
[23:27] <ScottK> I would find it surprising if your perspective on the usefulness of syncing from Debian wasn't colored by your experience there.
[23:28] <ScottK> Of course my perspective about Debian is also based on my experience with it.
[23:28] <sgclark> are we really that far diverged from them? I dont think we are
[23:28] <ScottK> Not where I've checked.
[23:28] <sgclark> and we need to do debian merges anyway
[23:29] <sgclark> dunno I think at least for this release it is a good idea. yofel and I still have alot of work with getting on teams and whatnot
[23:30] <sgclark> never ending backports
[23:30] <sgclark> and everything else
[23:30] <sgclark> we need more packagers >.<
[23:30] <santa_> well, I don't think withdrawing kubuntu's ability to upload its own packages is going to help in the long term
[23:31] <sgclark> oh we withdraw the ability to upload?
[23:31] <yofel> where did that come from?
[23:31] <sgclark> that does not sound right
[23:32] <yofel> I didn't hear about that, and I'm fairly certain that's not the plan
[23:32] <yofel> doesn't change the fact that we barley have any people left that can upload more than the kubuntu set
[23:32] <sgclark> I can only upload kubuntu and not even all of that
[23:33] <sgclark> so yeah I have to fix that
[23:36] <santa_> sgclark: but you can upload all of frameworks/plasma/apps?
[23:36] <sgclark> few lingering apps that I get rejects on
[23:37] <sgclark> but mostly yeah
[23:40] <santa_> ScottK: but indeed my opinions of debian are "coloured" by my experience there - such as the well known lack of manpower of the debian qt/kde team and other things
[23:41] <santa_> which I suffered in first person, and which was a problem before I joined, while I was in, and after I left
[23:44] <sgclark> well we are going to have that problem here. So we need to make do with what have and make the best of it.
[23:45] <santa_> that depends on the direction that the project takes
[23:46] <santa_> that's "terra incognita" for now
[23:47] <santa_> I think with the right people here, with a minimum of 3 packagers we have the thing saved
[23:48] <santa_> or even 1 XD
[23:48] <santa_> but I think there will be more than one I hope
[23:48] <santa_> we will see how the thing evolves