=== himcesjf_ is now known as him-cesjf
[09:04] <IrcsomeBot> <RikMills> (New chat photo, 640x640) https://irc-attachments.kde.org/ErlANkF5/file_20190.jpg
[10:20] <IrcsomeBot> <Santa> @MichaelTunnell ↑
[10:20] <santa_> good morning everybody
[10:21] <santa_> RikMills: so ... I have been thinking about check-binpkg-names fixing, see below
[10:22] <santa_> - this is how it currently behaves: it takes the kubuntu_<latest_ubuntu_devel_release>_archive branch and the debian/master branch and it prints a summary fo the binary package names difference
[10:23] <RikMills> ok
[10:24] <santa_> - this is how it would behave after doing a number of changes: it would take the current branch you are in and another branch to compare, which would be by default "debian/master"
[10:24]  * RikMills glares at digikam
[10:26] <RikMills> seems ok
[10:26] <santa_> eaxmple: let's say you are in the kubuntu_focal_virtual pim branch and you want to compare with debian/experimental
[10:27] <santa_> you would checkout kubuntu_focal_virtual and you would execute "check-binpkg-names -o debian/experimental"
[10:28] <RikMills> right
[10:28] <santa_> btw
[10:29] <santa_> something I didn't draft in the wiki yet is which branches we should use to push the changes
[10:29] <santa_> we could either use the regular _staging branches or create dedicated branches
[10:29] <santa_> also the PPA we are going to use
[10:31] <santa_> we could either use a dedicated one or the regular staging one (we would need to wipe all the packages there fisrt if any)
[10:31] <RikMills> perhaps? https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/experimental
[10:31] <santa_> that one seems cool
[10:32] <santa_> currently it only contains clazy which is not going to interfere with our pim work
[10:32] <santa_> so yeah, we could use that one
[10:32] <santa_> what about the branches, do you have an opinion?
[10:32] <RikMills> clazy can go
[10:34] <RikMills> branches: creating a separate branch would be the approach. it would allow us to back out and try again if we needed to switch approach
[10:34] <RikMills> however, I don't think there is much doubt we have to go this way
[10:34] <RikMills> *would be the cautious approach
[10:35] <santa_> ok, looks good. so kubuntu_focal_virtualpim would be the name of the branch (y/n)?
[10:36] <RikMills> seems fine to me
[10:36] <santa_> ok, let me document that so we can discuss the last issue we didn't discussed yet...
[10:38] <RikMills> this reminds me. I still need to add the usual staging branches to the KCI auto merging code/jobs
[10:39] <RikMills> i.e. a push to those gets merged to kubuntu_stable or kubuntu_unstable
[10:39] <santa_> aha. documented PPA/branches we are going to use: https://phabricator.kde.org/w/kubuntu/black-operations/virtual-pim/
[10:40] <RikMills> :)
[10:40] <santa_> ok, so last topic we didn't touch yet: it's obvious we need to follow the build depends order (i.e. start with akonadi for instance)
[10:41] <santa_> so we would need a proper graph
[10:41] <santa_> so we would need to update the metadata to get ka-graph and friends working right
[10:42] <santa_> so we could make a virtualpim branch in ka-metadata, what do you think?
[10:42] <RikMills> again, seems sensible
[10:44] <santa_> sensible ~ reasonable? if so let's do that then
[10:44] <RikMills> both!
[10:44] <RikMills> yes
[10:45] <santa_> ok, let me note that in the wiki then...
[10:45] <RikMills> santa_: I have to go drive someone somewhere, so is there more? if so we can come back to this later
[10:46] <santa_> RikMills: we are done for now, thanks for your time!
[10:46] <santa_> and have a nice trip
[10:46] <RikMills> very unexciting trip :P
[10:50] <santa_> haha
[11:57] <BluesKaj> Hiyas all
[12:19] <IrcsomeBot> <Sick_Rimmit> Hey Folks 😁
[12:19] <BluesKaj> hey Sick_Rimmit
[12:20] <IrcsomeBot> <Sick_Rimmit> I'm working with a team who are evaluating some hardware, and they're planning to drop back to 19.04 for performance reasons. I thought I would share their findings.
[12:20] <IrcsomeBot> <Sick_Rimmit> In the interest of stability, we propose to ship Kubuntu 19.04 until 19.10 is stabilized. Here are some of the more critical issues we are seeing with 19.10: … 1. The CPU is pegged at max frequency and Intel Speed Shift (p-state) does not throttle down.  Earlier kernels worked great and normally idled all cores at 800Mhz. This problem only occurs after initial updates, and then is persistent.  (We believe this is withou
[12:20] <IrcsomeBot> backports repository, but must confirm). This kills battery life, heats up the device, and makes it noisy. … 2. The OS is reporting too many open concurrent files during normal use after update. … 3. Geekbench4 scores are too low. Before the update we were seeing ~5.5k / ~26k, now we see ~4.5 / ~13.5k. … We upgraded our prior generation (S76, Oryx Pro v5) to 19.10 (Pop!OS) and it has issues (1) and (2).  The Geekbench score remain
[12:20] <IrcsomeBot> but Pop!OS is shipping with a somewhat earlier kernel. … Tomorrow we will test Pop! OS 19.10 on an Oryx Pro v4 to determine the extent of the CPU issue. We will also run 19.04 on our chosen hardware to confirm it fixes the issues. If this goes well - and we are quite confident it will - we propose to ship with 19.04 with the backports repository enabled. We believe this is critical to provide a trouble-free user experience that our targ
[12:20] <IrcsomeBot> demographic demands.  … We should like to work with Kubuntu developers to help isolate and fix the issues and then upgrade to 19.10.  Your guidance there would be most helpful. … Sorry for the long note. What are your thoughts?
[12:27] <IrcsomeBot> <Sick_Rimmit> Hi @BluesKaj hope all is going well
[12:27] <BluesKaj> Sick_Rimmit, doing fine here, how about you?
[13:10] <IrcsomeBot> <Sick_Rimmit> All good here, been very busy, but I am back in the Kubuntu saddle now, and working on some good stuff to boost us 🥰
[13:17] <BluesKaj> cool, good to hear that,  Sick_Rimmit
=== markey_work is now known as markey
[19:07] <vip> hi there
[21:33] <IrcsomeBot> <RikMills> @Sick_Rimmit I don't think I ca help on those issues, as they seem waaaaaaay outside my/kubuntu control. However, shipping a new system with 19.04 which is due to go EOL in January is quite frankly nuts.
[22:04] <mamarley> For what it is worth, I support several Kubuntu Eoan systems and I haven't seen any issues like that.
[22:37] <IrcsomeBot> <Sick_Rimmit> @RikMills, Actually, I hadn't thought about that at all, really good point @RikMills